draft-ietf-tsvwg-ecn-encap-guidelines-04.txt   draft-ietf-tsvwg-ecn-encap-guidelines-05.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory Internet-Draft Simula Research Laboratory
Updates: 3819 (if approved) J. Kaippallimalil Updates: 3819 (if approved) J. Kaippallimalil
Intended status: Best Current Practice Huawei Intended status: Best Current Practice Huawei
Expires: April 10, 2016 P. Thaler Expires: September 22, 2016 P. Thaler
Broadcom Corporation Broadcom Corporation
October 8, 2015 March 21, 2016
Guidelines for Adding Congestion Notification to Protocols that Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP Encapsulate IP
draft-ietf-tsvwg-ecn-encap-guidelines-04 draft-ietf-tsvwg-ecn-encap-guidelines-05
Abstract Abstract
The purpose of this document is to guide the design of congestion The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure transport layer (L4). Following these guidelines should assure
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 10, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3. Guidelines in All Cases . . . . . . . . . . . . . . . . . . . 7 3. Guidelines in All Cases . . . . . . . . . . . . . . . . . . . 7
4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 7 4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 7
4.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 8 4.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 8
4.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 10 4.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 10
4.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 10 4.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 10
4.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion 5. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 12 Notification . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . 13 5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . 13
5.2. Wire Protocol Design: Indication of ECN Support . . . . . 14 5.2. Wire Protocol Design: Indication of ECN Support . . . . . 14
5.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 15 5.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 16
5.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 17 5.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 17
5.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 18 5.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 18
5.6. Reframing and Congestion Markings . . . . . . . . . . . . 19 5.6. Reframing and Congestion Markings . . . . . . . . . . . . 19
6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 20 Notification . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Feed-Backward Mode: Guidelines for Adding Congestion 7. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 21 Notification . . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations (to be removed by RFC Editor) . . . . . . 22 8. IANA Considerations (to be removed by RFC Editor) . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 4, line 11 skipping to change at page 4, line 11
However, until recently this was more due to the inability of TCP to However, until recently this was more due to the inability of TCP to
saturate the links. For many years, fixes such as window scaling saturate the links. For many years, fixes such as window scaling
[RFC1323] proved hard to deploy. And the New Reno variant of TCP has [RFC1323] proved hard to deploy. And the New Reno variant of TCP has
remained in widespread use despite its inability to scale to high remained in widespread use despite its inability to scale to high
flow rates. However, now that modern operating systems are finally flow rates. However, now that modern operating systems are finally
capable of saturating interior links, even the buffers of well- capable of saturating interior links, even the buffers of well-
provisioned interior switches will need to signal episodes of provisioned interior switches will need to signal episodes of
queuing. queuing.
Propagation of ECN is defined for MPLS [RFC5129], and is being Propagation of ECN is defined for MPLS [RFC5129], and is being
defined for TRILL [I-D.ietf-trill-rfc7180bis], but it remains to be defined for TRILL [RFC7780], [I-D.eastlake-trill-ecn-support], but it
defined for a number of other subnetwork technologies. remains to be defined for a number of other subnetwork technologies.
Similarly, ECN propagation is yet to be defined for many tunnelling Similarly, ECN propagation is yet to be defined for many tunnelling
protocols. [RFC6040] defines how ECN should be propagated for IP-in- protocols. [RFC6040] defines how ECN should be propagated for IP-in-
IP [RFC2003] and IPsec [RFC4301] tunnels. However, as Section 9.3 of IP [RFC2003] and IPsec [RFC4301] tunnels. However, as Section 9.3 of
RFC3168 pointed out, ECN support will need to be defined for other RFC3168 pointed out, ECN support will need to be defined for other
tunnelling protocols, e.g. L2TP [RFC2661], GRE [RFC1701], [RFC2784], tunnelling protocols, e.g. L2TP [RFC2661], GRE [RFC1701], [RFC2784],
PPTP [RFC2637] and GTP [GTPv1], [GTPv1-U], [GTPv2-C]. PPTP [RFC2637] and GTP [GTPv1], [GTPv1-U], [GTPv2-C].
Incremental deployment is the most delicate aspect when adding Incremental deployment is the most delicate aspect when adding
support for ECN. The original ECN protocol in IP [RFC3168] was support for ECN. The original ECN protocol in IP [RFC3168] was
skipping to change at page 7, line 41 skipping to change at page 7, line 41
initialised the values of all congestion notification fields in a initialised the values of all congestion notification fields in a
sequence of packets, before any are set to the congestion sequence of packets, before any are set to the congestion
experienced (CE) codepoint if they experience congestion further experienced (CE) codepoint if they experience congestion further
downstream. Typically the original data source at layer-4. downstream. Typically the original data source at layer-4.
3. Guidelines in All Cases 3. Guidelines in All Cases
RFC 3168 specifies that the ECN field in the IP header is intended to RFC 3168 specifies that the ECN field in the IP header is intended to
be marked by active queue management algorithms. Any congestion be marked by active queue management algorithms. Any congestion
notification from an algorithm that does not conform to the notification from an algorithm that does not conform to the
recommendations in [I-D.ietf-aqm-recommendation] MUST NOT be recommendations in [RFC7567] MUST NOT be propagated from a lower
propagated from a lower layer into the ECN field in IP (see also layer into the ECN field in IP (see also [RFC4774] on alternate uses
[RFC4774] on alternate uses of the ECN field). of the ECN field).
4. Modes of Operation 4. Modes of Operation
This section sets down the different modes by which congestion This section sets down the different modes by which congestion
information is passed between the lower layer and the higher one. It information is passed between the lower layer and the higher one. It
acts as a reference framework for the following sections, which give acts as a reference framework for the following sections, which give
normative guidelines for designers of explicit congestion normative guidelines for designers of explicit congestion
notification protocols, taking each mode in turn: notification protocols, taking each mode in turn:
Feed-Forward-and-Up: Nodes feed forward congestion notification Feed-Forward-and-Up: Nodes feed forward congestion notification
skipping to change at page 13, line 35 skipping to change at page 13, line 35
5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers 5.1. IP-in-IP Tunnels with Tightly Coupled Shim Headers
A common pattern for many tunnelling protocols is to encapsulate an A common pattern for many tunnelling protocols is to encapsulate an
inner IP header with shim header(s) then an outer IP header. In many inner IP header with shim header(s) then an outer IP header. In many
cases the shim header(s) always have to be tightly coupled to the cases the shim header(s) always have to be tightly coupled to the
outer IP header because they are not sufficient as outer headers in outer IP header because they are not sufficient as outer headers in
their own right. In such cases the shim header(s) and the outer IP their own right. In such cases the shim header(s) and the outer IP
header are always added (or removed) in the same operation. header are always added (or removed) in the same operation.
Therefore, in all such tightly coupled IP-in-IP tunnelling protocols, Therefore, in all such tightly coupled IP-in-IP tunnelling protocols,
the rules in [RFC6040] for propagating the ECN field between the two the rules in [RFC6040] for propagating the ECN field between the two
IP headers SHOULD be applied directly. IP headers SHOULD be applied directly. This is written as a 'SHOULD'
not a 'MUST' to allow for the possibility that it might not be
possible to apply the rules of RFC6040 retrospectively. For
instance, even though two (or more) tunnel headers are tightly
coupled, some tunnel implementations might process them on separate
devices.
Examples of tightly coupled IP-in-IP tunnelling protocols where Examples of tightly coupled IP-in-IP tunnelling protocols where
[RFC6040] can be applied directly are: [RFC6040] SHOULD be applied directly are:
o L2TP [RFC2661] o L2TP [RFC2661]
o GRE [RFC1701], [RFC2784] o GRE [RFC1701], [RFC2784]
o PPTP [RFC2637] o PPTP [RFC2637]
o GTP [GTPv1], [GTPv1-U], [GTPv2-C] o GTP [GTPv1], [GTPv1-U], [GTPv2-C]
o VXLAN [RFC7348]. o VXLAN [RFC7348].
5.2. Wire Protocol Design: Indication of ECN Support 5.2. Wire Protocol Design: Indication of ECN Support
This section is intended to guide the redesign of any lower layer This section is intended to guide the redesign of any lower layer
protocol that encapsulate IP to add native ECN support at the lower protocol that encapsulate IP to add native ECN support at the lower
layer. It reflects the approaches used in [RFC6040] and in layer. It reflects the approaches used in [RFC6040] and in
[RFC5129]. Therefore IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS [RFC5129]. Therefore IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS
encapsulations that already comply with [RFC6040] or [RFC5129] will encapsulations that already comply with [RFC6040] or [RFC5129] will
already satisfy this guidance. already satisfy this guidance.
skipping to change at page 16, line 20 skipping to change at page 16, line 27
subnet. This is necessary in addition to checking that an subnet. This is necessary in addition to checking that an
incoming PDU indicates an ECN-capable (L4) transport. Examples incoming PDU indicates an ECN-capable (L4) transport. Examples
of how this guarantee might be provided include: of how this guarantee might be provided include:
* by configuration (e.g. if any label switches in a domain * by configuration (e.g. if any label switches in a domain
support ECN marking, [RFC5129] requires all egress nodes to support ECN marking, [RFC5129] requires all egress nodes to
have been configured to propagate ECN) have been configured to propagate ECN)
* by the ingress explicitly checking that the egress propagates * by the ingress explicitly checking that the egress propagates
ECN (e.g. TRILL uses IS-IS to check path capabilities before ECN (e.g. TRILL uses IS-IS to check path capabilities before
using critical options [I-D.ietf-trill-rfc7180bis]) using critical options [RFC7780])
* by inherent design of the protocol (e.g. by encoding ECN * by inherent design of the protocol (e.g. by encoding ECN
marking on the outer header in such a way that a legacy egress marking on the outer header in such a way that a legacy egress
that does not understand ECN will consider the PDU corrupt and that does not understand ECN will consider the PDU corrupt and
discard it, thus at least propagating a form of congestion discard it, thus at least propagating a form of congestion
signal). signal).
2. Egress Fails Capability Check: If the ingress cannot guarantee 2. Egress Fails Capability Check: If the ingress cannot guarantee
that the egress will propagate congestion notification, the that the egress will propagate congestion notification, the
ingress SHOULD disable ECN when it forwards the PDU at the lower ingress SHOULD disable ECN when it forwards the PDU at the lower
skipping to change at page 22, line 41 skipping to change at page 22, line 41
The redesign of protocols that encapsulate IP in order to propagate The redesign of protocols that encapsulate IP in order to propagate
congestion signals between layers raises potential signal integrity congestion signals between layers raises potential signal integrity
concerns. Experimental or proposed approaches exist for assuring the concerns. Experimental or proposed approaches exist for assuring the
end-to-end integrity of in-band congestion signals, e.g.: end-to-end integrity of in-band congestion signals, e.g.:
o Congestion exposure (ConEx ) for networks to audit that their o Congestion exposure (ConEx ) for networks to audit that their
congestion signals are not being suppressed by other networks or congestion signals are not being suppressed by other networks or
by receivers, and for networks to police that senders are by receivers, and for networks to police that senders are
responding sufficiently to the signals, irrespective of the responding sufficiently to the signals, irrespective of the
transport protocol used [I-D.ietf-conex-abstract-mech]. transport protocol used [RFC7713].
o The ECN nonce [RFC3540] for a TCP sender to detect whether a o The ECN nonce [RFC3540] for a TCP sender to detect whether a
network or the receiver is suppressing congestion signals. network or the receiver is suppressing congestion signals.
o A test with the same goals as the ECN nonce, but without the need o A test with the same goals as the ECN nonce, but without the need
for the receiver to co-operate with the protocol for the receiver to co-operate with the protocol
[I-D.moncaster-tcpm-rcv-cheat]. [I-D.moncaster-tcpm-rcv-cheat].
Given these end-to-end approaches are already being specified, it Given these end-to-end approaches are already being specified, it
would make little sense to attempt to design hop-by-hop congestion would make little sense to attempt to design hop-by-hop congestion
skipping to change at page 25, line 16 skipping to change at page 25, line 16
interface", Technical Specification TS 29.060. interface", Technical Specification TS 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS Protocol User Plane (GTPv1-U)", Technical Specification TS
29.281. 29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)
Tunnelling Protocol for Control plane (GTPv2-C)", Tunnelling Protocol for Control plane (GTPv2-C)",
Technical Specification TS 29.274. Technical Specification TS 29.274.
[I-D.ietf-aqm-recommendation] [I-D.eastlake-trill-ecn-support]
Baker, F. and G. Fairhurst, "IETF Recommendations Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit
Regarding Active Queue Management", draft-ietf-aqm- Congestion Notification) Support", draft-eastlake-trill-
recommendation-11 (work in progress), February 2015. ecn-support-00 (work in progress), March 2016.
[I-D.ietf-conex-abstract-mech]
Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism and Requirements", draft-
ietf-conex-abstract-mech-13 (work in progress), October
2014.
[I-D.ietf-trill-rfc7180bis]
Eastlake, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "TRILL: Clarifications,
Corrections, and Updates", draft-ietf-trill-rfc7180bis-06
(work in progress), October 2015.
[I-D.ietf-tsvwg-circuit-breaker] [I-D.ietf-tsvwg-circuit-breaker]
Fairhurst, G., "Network Transport Circuit Breakers", Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-05 (work in progress), draft-ietf-tsvwg-circuit-breaker-13 (work in progress),
October 2015. February 2016.
[I-D.moncaster-tcpm-rcv-cheat] [I-D.moncaster-tcpm-rcv-cheat]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", draft- Allow Senders to Identify Receiver Non-Compliance", draft-
moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014. moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
[IEEE802.1Qah] [IEEE802.1Qah]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Virtual Bridged Local Area Networks--Amendment Networks--Virtual Bridged Local Area Networks--Amendment
6: Provider Backbone Bridges", IEEE Std 802.1Qah-2008, 6: Provider Backbone Bridges", IEEE Std 802.1Qah-2008,
skipping to change at page 28, line 5 skipping to change at page 27, line 31
DOI 10.17487/RFC6660, July 2012, DOI 10.17487/RFC6660, July 2012,
<http://www.rfc-editor.org/info/rfc6660>. <http://www.rfc-editor.org/info/rfc6660>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>. <http://www.rfc-editor.org/info/rfc7348>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<http://www.rfc-editor.org/info/rfc7567>.
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015,
<http://www.rfc-editor.org/info/rfc7713>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.
Appendix A. Outstanding Document Issues Appendix A. Outstanding Document Issues
1. [GF] Concern that certain guidelines warrant a MUST (NOT) rather 1. [GF] Concern that certain guidelines warrant a MUST (NOT) rather
than a SHOULD (NOT). Given the guidelines say that if any SHOULD than a SHOULD (NOT). Given the guidelines say that if any SHOULD
(NOT)s are not followed, a strong justification will be needed, (NOT)s are not followed, a strong justification will be needed,
they have been left as SHOULD (NOT) pending further list they have been left as SHOULD (NOT) pending further list
discussion. In particular: discussion. In particular:
* If inner is a Not-ECN-PDU and Outer is CE (or highest severity * If inner is a Not-ECN-PDU and Outer is CE (or highest severity
congestion level), MUST (not SHOULD) drop? congestion level), MUST (not SHOULD) drop?
 End of changes. 16 change blocks. 
34 lines changed or deleted 42 lines changed or added

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