draft-ietf-sfc-nsh-ecn-support-02.txt   draft-ietf-sfc-nsh-ecn-support-03.txt 
INTERNET-DRAFT Donald Eastlake INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Futurewei Technologies Intended status: Proposed Standard Futurewei Technologies
Bob Briscoe Bob Briscoe
Independent Independent
Andrew Malis Andrew Malis
Futurewei Technologies Independent
Expires: June 31, 2020 January 1, 2020 Expires: January 1, 2021 July 2, 2020
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-02.txt> <draft-ietf-sfc-nsh-ecn-support-03.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 3, line 5 skipping to change at page 2, line 35
4. Tunnel Congestion Feedback Support.....................15 4. Tunnel Congestion Feedback Support.....................15
5. IANA Considerations....................................16 5. IANA Considerations....................................16
6. Security Considerations................................17 6. Security Considerations................................17
7. Acknowledgements.......................................17 7. Acknowledgements.......................................17
Normative References......................................18 Normative References......................................18
Informative References....................................19 Informative References....................................19
Authors' Addresses........................................20
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
1. Introduction 1. Introduction
Explicit congestion notification (ECN [RFC3168]) allows a forwarding Explicit congestion notification (ECN [RFC3168]) allows a forwarding
element to notify downstream devices of the onset of congestion element to notify downstream devices of the onset of congestion
without having to drop packets. Coupled with a means to feed back without having to drop packets. Coupled with a means to feed back
information about congestion to upstream nodes, this can improve information about congestion to upstream nodes, this can improve
network efficiency through better congestion control, frequently network efficiency through better congestion control, frequently
without packet drops. This document specifies ECN and congestion without packet drops. This document specifies ECN and congestion
skipping to change at page 3, line 26 skipping to change at page 3, line 26
domain through use of the Network Service Header (NSH [RFC8300]) and domain through use of the Network Service Header (NSH [RFC8300]) and
IP Flow Information Export (IPFIX [TunnelCongFeedback]). IP Flow Information Export (IPFIX [TunnelCongFeedback]).
It requires that all ingress and egress nodes of the SFC domain It requires that all ingress and egress nodes of the SFC domain
implement ECN. While congestion management will be the most effective implement ECN. While congestion management will be the most effective
if all interior nodes of the SFC domain implement ECN, some benefit if all interior nodes of the SFC domain implement ECN, some benefit
is obtained even if some interior nodes do not implement ECN. In is obtained even if some interior nodes do not implement ECN. In
particular, congestion at any bottleneck where ECN marking is not particular, congestion at any bottleneck where ECN marking is not
implemented will be unmanaged. implemented will be unmanaged.
The subsections below in this is section provide background The subsections below in this section provide background information
information on NSH, ECN, congestion feedback, and terminology used in on NSH, ECN, congestion feedback, and terminology used in this
this document. document.
1.1 NSH Background 1.1 NSH Background
The Service Function Chaining (SFC [RFC7665]) architecture calls for The Service Function Chaining (SFC [RFC7665]) architecture calls for
the encapsulation of traffic within a service function chaining the encapsulation of traffic within a service function chaining
domain with a Network Service Header (NSH [RFC8300]) added by the domain with a Network Service Header (NSH [RFC8300]) added by the
"Classifier" (ingress node) on entry to the domain and the NSH being "Classifier" (ingress node) on entry to the domain and the NSH being
removed on exit from the domain at the egress node. The NSH is used removed on exit from the domain at the egress node. The NSH is used
to control the path of a packet in an SFC domain. The NSH is a to control the path of a packet in an SFC domain. The NSH is a
natural place, in a domain where traffic is NSH encapsulated, to note natural place, in a domain where traffic is NSH encapsulated, to note
skipping to change at page 4, line 46 skipping to change at page 4, line 46
. v +----+ . . v +----+ .
. +------+ . . +------+ .
. . .| Exit |. . . . . . . . . . . . . . . . . .| Exit |. . . . . . . . . . . . . . .
+------+ +------+
| |
v v
Figure 1. Example SFC Path Forwarding Nodes Figure 1. Example SFC Path Forwarding Nodes
Figure 1 shows an SFC domain for the purpose of illustrating the use Figure 1 shows an SFC domain for the purpose of illustrating the use
of NSH. Traffic passes through a sequence of Service Function of the NSH. Traffic passes through a sequence of Service Function
Forwarders (SFFs) each of which sends the traffic to one or more Forwarders (SFFs) each of which sends the traffic to one or more
Service Functions (SFs). Each SF performs some operation on the Service Functions (SFs). Each SF performs some operation on the
traffic, for example firewall or Network Address Translation (NAT), traffic, for example firewall or Network Address Translation (NAT),
and then returns it to the SFF from which it was received. and then returns it to the SFF from which it was received.
Logically, during the transit of each SFF, the outer transport header Logically, during the transit of each SFF, the outer transport header
that got the packet to the SFF is stripped, the SFF decides on the that got the packet to the SFF is stripped, the SFF decides on the
next forwarding step, either adding a transport header or, if the SFF next forwarding step, either adding a transport header or, if the SFF
is the exit/egress, removing the NSH header. The transport headers is the exit/egress, removing the NSH header. The transport headers
skipping to change at page 5, line 48 skipping to change at page 5, line 48
(1) Traffic throttling (policing), where the downstream traffic (1) Traffic throttling (policing), where the downstream traffic
flowing out of the ingress node is limited to reduce or eliminate flowing out of the ingress node is limited to reduce or eliminate
congestion. congestion.
(2) Upstream congestion feedback, where the ingress node sends (2) Upstream congestion feedback, where the ingress node sends
messages upstream to or towards the ultimate traffic source, a messages upstream to or towards the ultimate traffic source, a
function that can throttle traffic generation/transmission. function that can throttle traffic generation/transmission.
(3) Traffic re-direction, where the ingress node configures the NSH (3) Traffic re-direction, where the ingress node configures the NSH
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 with this option to avoid (a) significant re-
traffic in flows that it is desirable to keep in order and (b) ordering of traffic in flows that it is desirable to keep in
oscillation/instability in traffic paths due to alternate order and (b) oscillation/instability in traffic paths due to
congestion of previously idle paths and the idling of previously alternate congestion of previously idle paths and the idling of
congested paths. For example, it is preferable to classify previously congested paths. For example, it is preferable to
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
traffic into flows of a sufficiently coarse granularity that the classify traffic into flows of a sufficiently coarse granularity
flows are long lived and use a stable path per flow, then send that the flows are long lived and then use a stable path per
only newly appearing flows on apparently uncongested paths. flow, sending 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,
to control or balance load within the SFC domain. to control or balance load within the SFC domain.
.:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :. .:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :.
_||_ End-to-End Congestion Feedback || _||_ End-to-End Congestion Feedback ||
\ / || \ / ||
\/ || \/ ||
Inner Transport Header and Payload __ __ Inner Transport Header and Payload __
| | - - - - - - - - - - - - - - - ->- - - - - -- - - - - - - - | | | | ->- - - - - - - - - - - - - - ->- - - - - -- - - - - - ->- | |
| | | | | | | |
| | .:= = = = = = = = = = = = = = = = = = = = = =:. | | | | .:= = = = = = = = = = = = = = = = = = = = = =:. | |
| | _||_ Tunnel Congestion Feedback || | | | | _||_ Tunnel Congestion Feedback || | |
| | \ / || | | | | \ / || | |
| | \/ || | | | | \/ || | |
| | __ NSH __ | | | | __ NSH __ | |
| | | |-------------------------->--------------| | | | | | | |-------------------------->--------------| | | |
| |. . . | | ___ ___ ___ | |. . .| | | |. . . | | ___ ___ ___ | |. . .| |
| | | | OT1 | | OT4 | | . . . | | OTn | | | | | | | | OT1 | | OT4 | | . . . | | OTn | | | |
| | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | | | | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | |
skipping to change at page 11, line 17 skipping to change at page 11, line 17
3.1 At The Ingress 3.1 At The Ingress
When the ingress/Classifier encapsulates an incoming IP packet with When the ingress/Classifier encapsulates an incoming IP packet with
an NSH, it MUST set the NSH ECN field using the "Normal mode" an NSH, it MUST set the NSH ECN field using the "Normal mode"
specified in [RFC6040] (i.e., copied from the incoming IP header). specified in [RFC6040] (i.e., copied from the incoming IP header).
Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
set it to ECT(0). This indicates that, even though the end-to-end set it to ECT(0). This indicates that, even though the end-to-end
transport is not ECN-capable, the egress and ingress of the SFC transport is not ECN-capable, the egress and ingress of the SFC
domain are acting as an ECN-capable transport. This approach will domain are acting as an ECN-capable transport. This approach will
inherently support all known variatns of ECN, including the inherently support all known variants of ECN, including the
experimental L4S capability [RFC8311], [ecnL4S]. experimental L4S capability [RFC8311] [ecnL4S].
Packets arriving at the ingress might not use IP. If the protocol of Packets arriving at the ingress might not use IP. If the protocol of
arriving packets supports an ECN field similar to IP, the procedures arriving packets supports an ECN field similar to IP, the procedures
for IP packets can be used. If arriving packets do not support an ECN for IP packets can be used. If arriving packets do not support an ECN
field similar to IP, they MUST be treated as if they are Not-ECT IP field similar to IP, they MUST be treated as if they are Not-ECT IP
packets. packets.
Then, as the NSH encapsulated packet is further encapsulated with a Then, as the NSH encapsulated packet is further encapsulated with a
transport header, if ECN marking is available for that transport (as transport header, if ECN marking is available for that transport (as
it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the
skipping to change at page 13, line 26 skipping to change at page 13, line 26
If the SF is not NSH-aware, then an NSH proxy will be between the SFF If the SF is not NSH-aware, then an NSH proxy will be between the SFF
and the SF to avoid exposure of the NSH at the SF that does not and the SF to avoid exposure of the NSH at the SF that does not
understand NSHs. This is described in Section 4.6 of [RFC7665]. The understand NSHs. This is described in Section 4.6 of [RFC7665]. The
SF and proxy together look to the SFF like an NSH-aware SF. The SF and proxy together look to the SFF like an NSH-aware SF. The
behavior at the proxy and SF in this case is as below: behavior at the proxy and SF in this case is as below:
If such a proxy is not ECN-aware then congestion in the entire If such a proxy is not ECN-aware then congestion in the entire
path from SFF to proxy to SF back to proxy to SFF will be path from SFF to proxy to SF back to proxy to SFF will be
unmanaged. unmanaged.
If the proxy is ECN-aware the proxy uses an AQM to indicate If the proxy is ECN-aware, the proxy uses an AQM to indicate
congestion in the proxy itself in the NSH that it returns to the congestion within the proxy in the NSH that it returns to the SFF.
SFF. The outer header used for the proxy to SF path uses Normal The outer header used for the proxy to SF path uses Normal Mode.
Mode. The outer head used for the proxy return to SFF path uses The outer head used for the proxy return to SFF path uses Normal
Normal Mode based copying the NSH ECN field to the outer header. Mode based copying the NSH ECN field to the outer header. Thus
Thus congestion in the proxy will be managed. Congestion in the SF congestion in the proxy will be managed. Congestion in the SF will
will be managed only if the SF is ECN-aware implementing an AQM. 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 contain 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
skipping to change at page 20, line 25 skipping to change at page 20, line 25
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
Futurewei Technologies Independent
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) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
 End of changes. 11 change blocks. 
27 lines changed or deleted 30 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/