Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH)
draft-ietf-sfc-nsh-ecn-support-02
INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Futurewei Technologies
Bob Briscoe
Independent
Andrew Malis
Futurewei Technologies
Expires: June 31, 2020 January 1, 2020
Explicit Congestion Notification (ECN) and Congestion Feedback
Using the Network Service Header (NSH)
<draft-ietf-sfc-nsh-ecn-support-02.txt>
Abstract
Explicit congestion notification (ECN) allows a forwarding element to
notify downstream devices of the onset of congestion without having
to drop packets. Coupled with a means to feed back information about
congestion to upstream nodes, this can improve network efficiency
through better congestion control, frequently without packet drops.
This document specifies ECN and congestion feedback support within a
Service Function Chaining (SFC) domain through use of the Network
Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX,
draft-ietf-tsvwg-tunnel-congestion-feedback).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the SFC Working Group mailing list <sfc@ietf.org> or to the
authors.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
D. Eastlake, B. Briscoe, & A. Malis [Page 1]
INTERNET-DRAFT NSH ECN & Congestion Feedback
Table of Contents
1. Introduction............................................3
1.1 NSH Background.........................................3
1.2 ECN Background.........................................5
1.3 Tunnel Congestion Feedback Background..................5
1.4 Conventions Used in This Document......................7
2. The NSH ECN Field.......................................8
3. ECN Support in the NSH.................................10
3.1 At The Ingress........................................11
3.2 At Transit Nodes......................................12
3.2.1 At NSH Transit Nodes................................12
3.2.2 At an SF/Proxy......................................13
3.2.3 At Other Forwarding Nodes...........................13
3.3 At Exit/Egress........................................13
3.4 Conservation of Packets...............................14
4. Tunnel Congestion Feedback Support.....................15
5. IANA Considerations....................................16
6. Security Considerations................................17
7. Acknowledgements.......................................17
Normative References......................................18
Informative References....................................19
D. Eastlake, B. Briscoe, & A. Malis [Page 2]
INTERNET-DRAFT NSH ECN & Congestion Feedback
1. Introduction
Explicit congestion notification (ECN [RFC3168]) allows a forwarding
element to notify downstream devices of the onset of congestion
without having to drop packets. Coupled with a means to feed back
information about congestion to upstream nodes, this can improve
network efficiency through better congestion control, frequently
without packet drops. This document specifies ECN and congestion
feedback support within a Service Function Chaining (SFC [RFC7665])
domain through use of the Network Service Header (NSH [RFC8300]) and
IP Flow Information Export (IPFIX [TunnelCongFeedback]).
It requires that all ingress and egress nodes of the SFC domain
implement ECN. While congestion management will be the most effective
if all interior nodes of the SFC domain implement ECN, some benefit
is obtained even if some interior nodes do not implement ECN. In
particular, congestion at any bottleneck where ECN marking is not
implemented will be unmanaged.
Show full document text