< draft-ietf-sfc-nsh-ecn-support-00.txt   draft-ietf-sfc-nsh-ecn-support-01.txt >
INTERNET-DRAFT Donald Eastlake INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Huawei Intended status: Proposed Standard Futurewei Technologies
Bob Briscoe Bob Briscoe
Independent Independent
Andrew Malis Andrew Malis
Huawei Futurewei Technologies
Expires: August 6, 2019 February 7, 2019 Expires: January 6, 2020 July 7, 2019
Explicit Congestion Notification (ECN) and Congestion Feedback Explicit Congestion Notification (ECN) and Congestion Feedback
Using the Network Service Header (NSH) Using the Network Service Header (NSH)
<draft-ietf-sfc-nsh-ecn-support-00.txt> <draft-ietf-sfc-nsh-ecn-support-01.txt>
Abstract Abstract
Explicit congestion notification (ECN) allows a forwarding element to Explicit congestion notification (ECN) allows a forwarding element to
notify downstream devices of the onset of congestion without having notify downstream devices of the onset of congestion without having
to drop packets. Coupled with a means to feed back information about to drop packets. Coupled with a means to feed back information about
congestion to upstream nodes, this can improve network efficiency congestion to upstream nodes, this can improve network efficiency
through better congestion control, frequently without packet drops. through better congestion control, frequently without packet drops.
This document specifies ECN and congestion feedback support within a This document specifies ECN and congestion feedback support within a
Service Function Chaining (SFC) domain through use of the Network Service Function Chaining (SFC) domain through use of the Network
skipping to change at page 5, line 14 skipping to change at page 5, line 14
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
added may be different in different regions of the SFC domain. For added may be different in different regions of the SFC domain. For
example, IP could be used for some SFF-to-SFF communication and MPLS example, IP could be used for some SFF-to-SFF communication and MPLS
used for other such communication. used for other such communication.
1.2 ECN Background 1.2 ECN Background
Explicit congestion notification (ECN [RFC3168]) allows a forwarding Explicit congestion notification (ECN [RFC3168]) allows a forwarding
element (such as a router or an Service Function Forwarder (SFF) or element (such as a router or a Service Function Forwarder (SFF) or
Service Function (SF)) to notify downstream devices of the onset of Service Function (SF)) to notify downstream devices of the onset of
congestion without having to drop packets. This can be used as an congestion without having to drop packets. This can be used as an
element in active queue management (AQM) [RFC7567] to improve network element in active queue management (AQM) [RFC7567] to improve network
efficiency through better traffic control without packet drops. The efficiency through better traffic control without packet drops. The
forwarding element can explicitly mark some packets in an ECN field forwarding element can explicitly mark some packets in an ECN field
instead of dropping the packet. For example, a two-bit field is instead of dropping the packet. For example, a two-bit field is
available for ECN marking in IP headers [RFC3168]. available for ECN marking in IP headers [RFC3168].
1.3 Tunnel Congestion Feedback Background 1.3 Tunnel Congestion Feedback Background
skipping to change at page 6, line 8 skipping to change at page 6, line 8
of some future traffic so that it avoids congested paths. Great of some future traffic so that it avoids congested paths. Great
care must be taken to avoid (a) significant re-ordering of care must be taken to avoid (a) significant re-ordering of
traffic in flows that it is desirable to keep in order and (b) traffic in flows that it is desirable to keep in order and (b)
oscillation/instability in traffic paths due to alternate oscillation/instability in traffic paths due to alternate
congestion of previously idle paths and the idling of previously congestion of previously idle paths and the idling of previously
congested paths. For example, it is preferable to classify congested paths. For example, it is preferable to classify
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
traffic into flows of a sufficiently coarse granularity that the traffic into flows of a sufficiently coarse granularity that the
flows are long lived and use a stable path per flow sending only flows are long lived and use a stable path per flow, then send
newly appearing flows on apparently uncongested paths. only newly appearing flows on apparently uncongested paths.
Figure 2 shows an example path from an origin sender to a final Figure 2 shows an example path from an origin sender to a final
receiver passing through an example chain of service functions receiver passing through an example chain of service functions
between the ingress and egress of an SFC domain. The path is also between the ingress and egress of an SFC domain. The path is also
likely to pass through other network nodes outside the SFC domain likely to pass through other network nodes outside the SFC domain
(not shown). The figure shows typical congestion feedback that would (not shown). The figure shows typical congestion feedback that would
be expected from the final receiver to the origin sender, which be expected from the final receiver to the origin sender, which
controls the load the origin sender applies to all elements on the controls the load the origin sender applies to all elements on the
path. The figure also shows the congestion feedback from the egress path. The figure also shows the congestion feedback from the egress
to the ingress of the SFC domain that is described in this document, to the ingress of the SFC domain that is described in this document,
skipping to change at page 10, line 26 skipping to change at page 10, line 26
uniform so that, if this document is applicable, all SFFs will uniform so that, if this document is applicable, all SFFs will
support ECN; however, some legacy SFs might not support ECN. support ECN; however, some legacy SFs might not support ECN.
ECN Propagation: ECN Propagation:
The specification of ECN tunneling [RFC6040] explains that an The specification of ECN tunneling [RFC6040] explains that an
ingress must not propagate ECN support into an encapsulating ingress must not propagate ECN support into an encapsulating
header unless the egress supports correct onward propagation of header unless the egress supports correct onward propagation of
the ECN field during decapsulation. We define Compliant ECN the ECN field during decapsulation. We define Compliant ECN
Decapsulation here as decapsulation compliant with either Decapsulation here as decapsulation compliant with either
[RFC6040] or an earlier compatible equivalent ([RFC4301], or full [RFC6040] or an earlier compatible equivalent ([RFC4301], or the
functionality mode of [RFC3168]). full functionality mode of [RFC3168]).
The procedures in Section 3.2.1 ensure that each ingress of the The procedures in Section 3.2.1 ensure that each ingress of the
large number of possible transport links within the SFC domain large number of possible transport links within the SFC domain
does not propagate ECN support into the encapsulating outer does not propagate ECN support into the encapsulating outer
transport header unless the corresponding egress of that link transport header unless the corresponding egress of that link
supports Compliant ECN Decapsulation. supports Compliant ECN Decapsulation.
Section 3.3 requires that all the egress nodes of the SFC domain Section 3.3 requires that all the egress nodes of the SFC domain
support Compliant ECN Decapsulation in conjunction with tunnel support Compliant ECN Decapsulation in conjunction with tunnel
congestion feedback, otherwise the scheme in this document will congestion feedback, otherwise the scheme in this document will
not work. not work.
ECN Marking: ECN Marking:
At transit nodes the marking behavior specified in 3.2.1 is At transit nodes the marking behavior specified in Section 3.2.1
recommended and if not implemented at such transit nodes, there is recommended and if not implemented at such transit nodes, there
may be unmanaged congestion. may be unmanaged congestion.
Detection of congestion will be most effective if ECN marking is Detection of congestion will be most effective if ECN marking is
supported by all potential bottlenecks inside the domain in which supported by all potential bottlenecks inside the domain in which
NSH is being used to route traffic as well as at the ingress and NSH is being used to route traffic as well as at the ingress and
egress. Nodes that do not support ECN marking, or that support egress. Nodes that do not support ECN marking, or that support
AQM but not ECN, will naturally use drop to relieve congestion. AQM but not ECN, will naturally use drop to relieve congestion.
The gap in the end-to-end packet sequence will be detected as The gap in the end-to-end packet sequence will be detected as
congestion by the final receiving endpoint, but not by the NSH congestion by the final receiving endpoint, but not by the NSH
egress (see Figure 2). egress (see Figure 2).
skipping to change at page 13, line 37 skipping to change at page 13, line 37
congestion in the proxy itself in the NSH that it returns to the congestion in the proxy itself in the NSH that it returns to the
SFF. The outer header used for the proxy to SF path uses Normal SFF. The outer header used for the proxy to SF path uses Normal
Mode. The outer head used for the proxy return to SFF path uses Mode. The outer head used for the proxy return to SFF path uses
Normal Mode based copying the NSH ECN field to the outer header. Normal Mode based copying the NSH ECN field to the outer header.
Thus congestion in the proxy will be managed. Congestion in the SF Thus congestion in the proxy will be managed. Congestion in the SF
will be managed only if the SF is ECN-aware implementing an AQM. will be managed only if the SF is ECN-aware implementing an AQM.
3.2.3 At Other Forwarding Nodes 3.2.3 At Other Forwarding Nodes
Other forwarding nodes, that is non-NSH forwarding nodes between NSH Other forwarding nodes, that is non-NSH forwarding nodes between NSH
forwarding nodes, such as IP routers, might also be potential forwarding nodes, such as IP routers, might also contain potential
bottlenecks. If so, they SHOULD implement an AQM algorithm to update bottlenecks. If so, they SHOULD implement an AQM algorithm to update
the ECN marking in the outer transport header as specified in the ECN marking in the outer transport header as specified in
[RFC3168]. [RFC3168].
3.3 At Exit/Egress 3.3 At Exit/Egress
First, any actions are taken based on Congestion Experienced such as First, any actions are taken based on Congestion Experienced, such as
forwarding statistics back to the ingress (see Section 4). If the forwarding statistics back to the ingress (see Section 4). If the
packet being carried inside the NSH is IP, when the NSH is removed packet being carried inside the NSH is IP, when the NSH is removed
the NSH ECN field MUST be combined with IP ECN field as specified in the NSH ECN field MUST be combined with IP ECN field as specified in
Table 3 that was extracted from [RFC6040]. This requirement applies Table 3 that was extracted from [RFC6040]. This requirement applies
to all egress nodes for the domain in which NSH is being used to to all egress nodes for the domain in which NSH is being used to
route traffic. route traffic.
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
+---------+---------------------------------------------+ +---------+---------------------------------------------+
skipping to change at page 17, line 18 skipping to change at page 17, line 18
For general NSH security considerations, see [RFC8300]. For general NSH security considerations, see [RFC8300].
For security considerations concerning tampering with ECN signaling, For security considerations concerning tampering with ECN signaling,
see [RFC3168]. For security considerations concerning ECN see [RFC3168]. For security considerations concerning ECN
encapsulation, see [RFC6040]. encapsulation, see [RFC6040].
For general IPFIX security considerations, see [RFC7011]. If deployed For general IPFIX security considerations, see [RFC7011]. If deployed
in an untrusted environment, the signaling traffic between ingress in an untrusted environment, the signaling traffic between ingress
and egress can be protected utilizing the security mechanisms and egress can be protected utilizing the security mechanisms
provided by IPFIX (see section 11 in RFC7011). provided by IPFIX (see Section 11 in [RFC7011]).
The solution in this document does not introduce any greater The solution in this document does not introduce any greater
potential to invade privacy than would have been possible without the potential to invade privacy than would have been possible without the
solution. solution.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank the following for their comments and The authors wish to thank the following for their comments and
suggestion: suggestion:
skipping to change at page 18, line 45 skipping to change at page 18, line 45
editor.org/info/rfc7567>. editor.org/info/rfc7567>.
[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <http://www.rfc-editor.org/info/rfc8174> 2017, <http://www.rfc-editor.org/info/rfc8174>
[RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300,
January 2018, <https://www.rfc-editor.org/info/rfc8300>. January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[TunnelCongFeedback] - Wei, X., Zhu, L., and L. Deng, "Tunnel [TunnelCongFeedback] - Wei, X., Li, Y., Boutros, S., and L. Deng,
Congestion Feedback", draft-ietf-tsvwg-tunnel-congestion- "Tunnel Congestion Feedback", draft-ietf-tsvwg-tunnel-
feedback, work in progress. congestion-feedback, work in progress.
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
Informative References Informative References
[RFC4301] - Kent, S. and K. Seo, "Security Architecture for the [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December
2005, <https://www.rfc-editor.org/info/rfc4301>. 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol",
skipping to change at page 20, line 10 skipping to change at page 20, line 10
[ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified [ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Ultra-Low Explicit Congestion Notification (ECN) Semantics for Ultra-Low
Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in
progress. progress.
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
Authors' Addresses Authors' Addresses
Donald E. Eastlake, 3rd Donald E. Eastlake, 3rd
Huawei Technologies Futurewei Technologies
1424 Pro Shop Court 1424 Pro Shop Court
Davenport, FL 33896 USA Davenport, FL 33896 USA
Tel: +1-508-333-2270 Tel: +1-508-333-2270
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
Bob Briscoe Bob Briscoe
Independent Independent
UK UK
Email: ietf@bobbriscoe.net Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
Andrew G. Malis Andrew G. Malis
Huawei Technologies Futurewei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
Copyright and IPR Provisions Copyright and IPR Provisions
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
 End of changes. 13 change blocks. 
19 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/