draft-ietf-tsvwg-ecn-tunnel-03.txt   draft-ietf-tsvwg-ecn-tunnel-04.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT Internet-Draft BT
Updates: 3168, 4301 July 24, 2009 Updates: 3168, 4301 October 24, 2009
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 25, 2010 Expires: April 27, 2010
Tunnelling of Explicit Congestion Notification Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-03 draft-ietf-tsvwg-ecn-tunnel-04
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 25, 2010. This Internet-Draft will expire on April 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 11 3. Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 11
3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 11 3.1. Encapsulation at Tunnel Ingress . . . . . . . . . . . . . 11
3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 12 3.2. Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 12
4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 13 4. New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 13
4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 13 4.1. Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 14
4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 14 4.2. Default Tunnel Egress Behaviour . . . . . . . . . . . . . 14
4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 16 4.3. Encapsulation Modes . . . . . . . . . . . . . . . . . . . 16
4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 17 4.4. Single Mode of Decapsulation . . . . . . . . . . . . . . . 18
5. Changes from Earlier RFCs . . . . . . . . . . . . . . . . . . 18 5. Updates to Earlier RFCs . . . . . . . . . . . . . . . . . . . 18
5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 18 5.1. Changes to RFC4301 ECN processing . . . . . . . . . . . . 18
5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 19 5.2. Changes to RFC3168 ECN processing . . . . . . . . . . . . 19
5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 19 5.3. Motivation for Changes . . . . . . . . . . . . . . . . . . 20
5.3.1. Motivation for Changing Encapsulation . . . . . . . . 20 5.3.1. Motivation for Changing Encapsulation . . . . . . . . 20
5.3.2. Motivation for Changing Decapsulation . . . . . . . . 21 5.3.2. Motivation for Changing Decapsulation . . . . . . . . 21
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23
6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 23 6.1. Non-Issues Updating Decapsulation . . . . . . . . . . . . 23
6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 23 6.2. Non-Update of RFC4301 IPsec Encapsulation . . . . . . . . 24
6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 24 6.3. Update to RFC3168 Encapsulation . . . . . . . . . . . . . 24
7. Design Principles for Future Non-Default Schemes . . . . . . . 24 7. Design Principles for Future Non-Default Schemes . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . . 29 13.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 31 Appendix A. Early ECN Tunnelling RFCs . . . . . . . . . . . . . . 31
Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 32 Appendix B. Design Constraints . . . . . . . . . . . . . . . . . 32
B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 32 B.1. Security Constraints . . . . . . . . . . . . . . . . . . . 32
B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 34 B.2. Control Constraints . . . . . . . . . . . . . . . . . . . 34
B.3. Management Constraints . . . . . . . . . . . . . . . . . . 35 B.3. Management Constraints . . . . . . . . . . . . . . . . . . 35
Appendix C. Contribution to Congestion across a Tunnel . . . . . 36 Appendix C. Contribution to Congestion across a Tunnel . . . . . 36
Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN . . . 36 Appendix D. Why Losing ECT(1) on Decapsulation Impedes PCN . . . 37
Appendix E. Why Resetting ECN on Encapsulation Impedes PCN . . . 38 Appendix E. Why Resetting ECN on Encapsulation Impedes PCN . . . 38
Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0) Appendix F. Compromise on Decap with ECT(1) Inner and ECT(0)
Outer . . . . . . . . . . . . . . . . . . . . . . . . 39 Outer . . . . . . . . . . . . . . . . . . . . . . . . 39
Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . . 40
Request to the RFC Editor (to be removed on publication): Request to the RFC Editor (to be removed on publication):
In the RFC index, RFC3168 should be identified as an update to In the RFC index, RFC3168 should be identified as an update to
RFC2481, RFC2401 and RFC2003. RFC4301 should be identified as an RFC2003. RFC4301 should be identified as an update to RFC3168.
update to RFC3168.
Changes from previous drafts (to be removed by the RFC Editor) Changes from previous drafts (to be removed by the RFC Editor)
Full text differences between IETF draft versions are available at Full text differences between IETF draft versions are available at
<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and <http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and
between earlier individual draft versions at between earlier individual draft versions at
<http://www.briscoe.net/pubs.html#ecn-tunnel> <http://www.briscoe.net/pubs.html#ecn-tunnel>
From ietf-02 to ietf-03 (current): From ietf-03 to ietf-04 (current):
* Functional changes: none
* Structural changes:
+ Added "Open Issues" appendix
* Textual changes:
+ Section title: "Changes from Earlier RFCs" -> "Updates to
Earlier RFCs"
+ Emphasised that change on decap to previously unused
combinations will propagate PCN encoding.
+ Acknowledged additional reviewers and updated references
From ietf-02 to ietf-03:
* Functional changes: * Functional changes:
+ Corrected errors in recap of previous RFCs, which wrongly + Corrected errors in recap of previous RFCs, which wrongly
stated the different decapsulation behaviours of RFC3168 & stated the different decapsulation behaviours of RFC3168 &
RFC4301 with a Not-ECT inner header. This also required RFC4301 with a Not-ECT inner header. This also required
corrections to the "Changes from Earlier RFCs" and the corrections to the "Changes from Earlier RFCs" and the
Motivations for these changes. Motivations for these changes.
+ Mandated that any future standards action SHOULD NOT use the + Mandated that any future standards action SHOULD NOT use the
skipping to change at page 15, line 47 skipping to change at page 16, line 19
previously was not used has started to be used for legitimate previously was not used has started to be used for legitimate
purposes such as a new standards action. An example is an ECT(0) purposes such as a new standards action. An example is an ECT(0)
inner combined with an ECT(1) outer, which is proposed as a legal inner combined with an ECT(1) outer, which is proposed as a legal
combination for PCN [I-D.ietf-pcn-3-in-1-encoding], so an operator combination for PCN [I-D.ietf-pcn-3-in-1-encoding], so an operator
that deploys support for PCN should turn off logging and alarms in that deploys support for PCN should turn off logging and alarms in
this case. this case.
The above logic allows for ECT(0) and ECT(1) to both represent the The above logic allows for ECT(0) and ECT(1) to both represent the
same severity of congestion marking (e.g. "not congestion marked"). same severity of congestion marking (e.g. "not congestion marked").
But it also allows future schemes to be defined where ECT(1) is a But it also allows future schemes to be defined where ECT(1) is a
more severe marking than ECT(0). This approach is discussed in more severe marking than ECT(0), in particular enabling the simplest
Appendix D and in the discussion of the ECN nonce [RFC3540] in possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding]. This
Section 9, which in turn refers to Appendix F. approach is discussed in Appendix D and in the discussion of the ECN
nonce [RFC3540] in Section 9, which in turn refers to Appendix F.
4.3. Encapsulation Modes 4.3. Encapsulation Modes
Section 4.1 introduces two encapsulation modes, normal mode and Section 4.1 introduces two encapsulation modes, normal mode and
compatibility mode, defining their encapsulation behaviour (i.e. compatibility mode, defining their encapsulation behaviour (i.e.
header copying or zeroing respectively). Note that these are modes header copying or zeroing respectively). Note that these are modes
of the ingress tunnel endpoint only, not the tunnel as a whole. of the ingress tunnel endpoint only, not the tunnel as a whole.
A tunnel ingress MUST at least implement `normal mode' and, if it A tunnel ingress MUST at least implement `normal mode' and, if it
might be used with legacy tunnel egress nodes (RFC2003, RFC2401 or might be used with legacy tunnel egress nodes (RFC2003, RFC2401 or
skipping to change at page 18, line 15 skipping to change at page 18, line 35
If no ECN-related mode is requested, a compliant tunnel egress MUST If no ECN-related mode is requested, a compliant tunnel egress MUST
continue without raising any error or warning as its egress behaviour continue without raising any error or warning as its egress behaviour
is compatible with all the legacy ingress behaviours that do not is compatible with all the legacy ingress behaviours that do not
negotiate capabilities. negotiate capabilities.
For 'forward compatibility', a compliant tunnel egress SHOULD raise a For 'forward compatibility', a compliant tunnel egress SHOULD raise a
warning alarm about any requests to enter modes it does not warning alarm about any requests to enter modes it does not
recognise, but it SHOULD continue operating. recognise, but it SHOULD continue operating.
5. Changes from Earlier RFCs 5. Updates to Earlier RFCs
5.1. Changes to RFC4301 ECN processing 5.1. Changes to RFC4301 ECN processing
Ingress: An RFC4301 IPsec encapsulator is not changed at all by the Ingress: An RFC4301 IPsec encapsulator is not changed at all by the
present specification present specification
Egress: The new decapsulation behaviour in Figure 4 updates RFC4301. Egress: The new decapsulation behaviour in Figure 4 updates RFC4301.
However, it solely updates combinations of inner and outer that However, it solely updates combinations of inner and outer that
have never been used on the Internet, even though they were have never been used on the Internet, even though they were
defined in RFC4301 for completeness. Therefore, the present defined in RFC4301 for completeness. Therefore, the present
skipping to change at page 28, line 34 skipping to change at page 29, line 6
that would otherwise be confounded by ambiguity. that would otherwise be confounded by ambiguity.
11. Acknowledgements 11. Acknowledgements
Thanks to Anil Agawaal for pointing out a case where it's safe for a Thanks to Anil Agawaal for pointing out a case where it's safe for a
tunnel decapsulator to forward a combination of headers it does not tunnel decapsulator to forward a combination of headers it does not
understand. Thanks to David Black for explaining a better way to understand. Thanks to David Black for explaining a better way to
think about function placement. Also thanks to Arnaud Jacquet for think about function placement. Also thanks to Arnaud Jacquet for
the idea for Appendix C. Thanks to Michael Menth, Bruce Davie, Toby the idea for Appendix C. Thanks to Michael Menth, Bruce Davie, Toby
Moncaster, Gorry Fairhurst, Sally Floyd, Alfred Hoenes, Gabriele Moncaster, Gorry Fairhurst, Sally Floyd, Alfred Hoenes, Gabriele
Corliano, Ingemar Johansson and David Black for their thoughts and Corliano, Ingemar Johansson, David Black and Phil Eardley for their
careful review comments. thoughts and careful review comments.
Bob Briscoe is partly funded by Trilogy, a research project (ICT- Bob Briscoe is partly funded by Trilogy, a research project (ICT-
216372) supported by the European Community under its Seventh 216372) supported by the European Community under its Seventh
Framework Programme. The views expressed here are those of the Framework Programme. The views expressed here are those of the
author only. author only.
12. Comments Solicited 12. Comments Solicited
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
skipping to change at page 29, line 34 skipping to change at page 30, line 4
[I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN [I-D.ietf-pcn-3-in-1-encoding] Briscoe, B. and T. Moncaster, "PCN
3-State Encoding Extension in a 3-State Encoding Extension in a
single DSCP", single DSCP",
draft-ietf-pcn-3-in-1-encoding-00 draft-ietf-pcn-3-in-1-encoding-00
(work in progress), July 2009. (work in progress), July 2009.
[I-D.ietf-pcn-3-state-encoding] Moncaster, T., Briscoe, B., and M. [I-D.ietf-pcn-3-state-encoding] Moncaster, T., Briscoe, B., and M.
Menth, "A PCN encoding using 2 Menth, "A PCN encoding using 2
DSCPs to provide 3 or more states", DSCPs to provide 3 or more states",
draft-ietf-pcn-3-state-encoding-00
(work in progress), April 2009. (work in progress), April 2009.
[I-D.ietf-pcn-baseline-encoding] Moncaster, T., Briscoe, B., and M. [I-D.ietf-pcn-baseline-encoding] Moncaster, T., Briscoe, B., and M.
Menth, "Baseline Encoding and Menth, "Baseline Encoding and
Transport of Pre-Congestion Transport of Pre-Congestion
Information", Information",
draft-ietf-pcn-baseline-encoding-04 draft-ietf-pcn-baseline-encoding-07
(work in progress), May 2009. (work in progress), September 2009.
[I-D.ietf-pcn-marking-behaviour] Eardley, P., "Metering and marking [I-D.ietf-pcn-marking-behaviour] Eardley, P., "Metering and marking
behaviour of PCN-nodes", behaviour of PCN-nodes",
draft-ietf-pcn-marking-behaviour-04 draft-ietf-pcn-marking-behaviour-05
(work in progress), June 2009. (work in progress), August 2009.
[I-D.ietf-pcn-psdm-encoding] Menth, M., Babiarz, J., Moncaster, [I-D.ietf-pcn-psdm-encoding] Menth, M., Babiarz, J., Moncaster,
T., and B. Briscoe, "PCN Encoding T., and B. Briscoe, "PCN Encoding
for Packet-Specific Dual Marking for Packet-Specific Dual Marking
(PSDM)", (PSDM)",
draft-ietf-pcn-psdm-encoding-00 draft-ietf-pcn-psdm-encoding-00
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth, [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., Menth,
M., and T. Taylor, "PCN Boundary M., and T. Taylor, "PCN Boundary
Node Behaviour for the Single Node Behaviour for the Single
Marking (SM) Mode of Operation", Marking (SM) Mode of Operation",
draft-ietf-pcn-sm-edge-behaviour-00 draft-ietf-pcn-sm-edge-behaviour-00
(work in progress), July 2009. (work in progress), July 2009.
[I-D.satoh-pcn-st-marking] Satoh, D., Maeda, Y., Phanachet, [I-D.satoh-pcn-st-marking] Satoh, D., Ueno, H., Maeda, Y., and
O., and H. Ueno, "Single PCN O. Phanachet, "Single PCN Threshold
Threshold Marking by using PCN Marking by using PCN baseline
baseline encoding for both encoding for both admission and
admission and termination termination controls",
controls", draft-satoh-pcn-st-marking-02 (work
draft-satoh-pcn-st-marking-01 (work in progress), September 2009.
in progress), March 2009.
[RFC2401] Kent, S. and R. Atkinson, "Security [RFC2401] Kent, S. and R. Atkinson, "Security
Architecture for the Internet Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., [RFC2474] Nichols, K., Blake, S., Baker, F.,
and D. Black, "Definition of the and D. Black, "Definition of the
Differentiated Services Field (DS Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998. Headers", RFC 2474, December 1998.
skipping to change at page 40, line 9 skipping to change at page 40, line 32
Superficially, the opposite case where the inner and outer carry Superficially, the opposite case where the inner and outer carry
different ECT values, but with an ECT(1) outer and ECT(0) inner seems different ECT values, but with an ECT(1) outer and ECT(0) inner seems
to require a similar compromise. However, because that case is to require a similar compromise. However, because that case is
reversed, no compromise is necessary; it is best to forward the outer reversed, no compromise is necessary; it is best to forward the outer
whether the transport expects the ECT(1) to mean a higher severity whether the transport expects the ECT(1) to mean a higher severity
than ECT(0) or the same severity. Forwarding the outer either than ECT(0) or the same severity. Forwarding the outer either
preserves a higher value (if it is higher) or it reveals an anomaly preserves a higher value (if it is higher) or it reveals an anomaly
to the transport (if the two ECT codepoints mean the same severity). to the transport (if the two ECT codepoints mean the same severity).
Appendix G. Open Issues
The new decapsulation behaviour defined in Section 4.2 adds support
for propagation of 2 severity levels of congestion. However
transports have no way to discover whether there are any legacy
tunnels on their path that will not propagate 2 severity levels. It
would have been nice to add a feature for transports to check path
support, but this remains an open issue that will have to be
addressed in any future standards action to define an end-to-end
scheme that requires 2-severity levels of congestion. PCN avoids
this problem, because it is only for a controlled region, so all
legacy tunnels can be upgraded by the same operator that deploys PCN.
Author's Address Author's Address
Bob Briscoe Bob Briscoe
BT BT
B54/77, Adastral Park B54/77, Adastral Park
Martlesham Heath Martlesham Heath
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
Phone: +44 1473 645196 Phone: +44 1473 645196
EMail: bob.briscoe@bt.com EMail: bob.briscoe@bt.com
URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ URI: http://bobbriscoe.net/
 End of changes. 24 change blocks. 
35 lines changed or deleted 65 lines changed or added

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