draft-ietf-tsvwg-ecn-encap-guidelines-06.txt   draft-ietf-tsvwg-ecn-encap-guidelines-07.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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: January 9, 2017 P. Thaler Expires: January 9, 2017 P. Thaler
Broadcom Corporation Broadcom Corporation
July 8, 2016 July 8, 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-06 draft-ietf-tsvwg-ecn-encap-guidelines-07
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 24, line 35 skipping to change at page 24, line 35
Finally, attempting to add ECN to a subnet technology in feed- Finally, attempting to add ECN to a subnet technology in feed-
backward mode is deprecated except in special cases, due to its backward mode is deprecated except in special cases, due to its
likely sluggish response to congestion. likely sluggish response to congestion.
11. Acknowledgements 11. Acknowledgements
Thanks to Gorry Fairhurst for extensive reviews. Thanks also to the Thanks to Gorry Fairhurst for extensive reviews. Thanks also to the
following reviewers: Richard Scheffenegger, Ingemar Johansson, Piers following reviewers: Richard Scheffenegger, Ingemar Johansson, Piers
O'Hanlon and Michael Welzl, who pointed out that lower layer O'Hanlon and Michael Welzl, who pointed out that lower layer
congestion notification signals may have different semantics to those congestion notification signals may have different semantics to those
in IP. in IP. Thanks are also due to the tsvwg chairs, TSV ADs and IETF
liaison people such as Eric Gray, Dan Romascanu and Gonzalo Camarillo
for helping with the liaisons with the IEEE and 3GPP. And thanks to
Georg Mayer and particularly to Erik Guttman for the extensive search
and categorisation of any 3GPP specifications that cite ECN
specifications.
Bob Briscoe was part-funded by the European Community under its Bob Briscoe was part-funded by the European Community under its
Seventh Framework Programme through the Trilogy project (ICT-216372) Seventh Framework Programme through the Trilogy project (ICT-216372)
for initial drafts and through the Reducing Internet Transport for initial drafts and through the Reducing Internet Transport
Latency (RITE) project (ICT-317700) subsequently. The views Latency (RITE) project (ICT-317700) subsequently. The views
expressed here are solely those of the authors. expressed here are solely those of the authors.
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
skipping to change at page 26, line 22 skipping to change at page 26, line 22
[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.briscoe-tsvwg-rfc6040bis] [I-D.briscoe-tsvwg-rfc6040bis]
Briscoe, B., "Propagating Explicit Congestion Notification Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft- Across IP Tunnel Headers Separated by a Shim", draft-
briscoe-tsvwg-rfc6040bis-00 (work in progress), July 2016. briscoe-tsvwg-rfc6040bis-00 (work in progress), July 2016.
[I-D.eastlake-trill-ecn-support] [I-D.eastlake-trill-ecn-support]
Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit 3rd, D. and B. Briscoe, "TRILL: ECN (Explicit Congestion
Congestion Notification) Support", draft-eastlake-trill- Notification) Support", draft-eastlake-trill-ecn-
ecn-support-00 (work in progress), March 2016. support-00 (work in progress), March 2016.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J. and I. Ganga, "Geneve: Generic Network Gross, J. and I. Ganga, "Geneve: Generic Network
Virtualization Encapsulation", draft-ietf-nvo3-geneve-01 Virtualization Encapsulation", draft-ietf-nvo3-geneve-01
(work in progress), January 2016. (work in progress), January 2016.
[I-D.ietf-nvo3-gue] [I-D.ietf-nvo3-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-nvo3-gue-04 (work in progress), Encapsulation", draft-ietf-nvo3-gue-04 (work in progress),
July 2016. July 2016.
skipping to change at page 30, line 49 skipping to change at page 30, line 49
an example of a well-design protocol that does not need an an example of a well-design protocol that does not need an
indication of ECN support in the wire protocol. indication of ECN support in the wire protocol.
* Encapsulation Guidelines: In the case of a Not-ECN-PDU with a * Encapsulation Guidelines: In the case of a Not-ECN-PDU with a
CE outer, replaced SHOULD be dropped, with explanations of when CE outer, replaced SHOULD be dropped, with explanations of when
SHOULD or MUST are appropriate. SHOULD or MUST are appropriate.
* Feed-Up-and-Forward Mode: Explained examples more carefully, * Feed-Up-and-Forward Mode: Explained examples more carefully,
referred to PDCP and cited UTRAN spec as well as E-UTRAN. referred to PDCP and cited UTRAN spec as well as E-UTRAN.
* Added the people involved in liaisons to the acknowledgements.
* Updated references. * Updated references.
* Marked open issues as resolved, but did not delete Open Issues * Marked open issues as resolved, but did not delete Open Issues
Appendix (yet). Appendix (yet).
From ietf-04 to ietf-05: From ietf-04 to ietf-05:
* Explained why tightly coupled shim headers only "SHOULD" comply * Explained why tightly coupled shim headers only "SHOULD" comply
with RFC 6040, not "MUST". with RFC 6040, not "MUST".
 End of changes. 4 change blocks. 
5 lines changed or deleted 12 lines changed or added

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