Title: Explicit Congestion Notification (ECN) and IEEE Protocols Submission Date: 2014-11-24 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1364/ Please reply by 2015-02-20 From: Transport Area Working Group (David Black ) To: IEEE 802 (Paul Nikolich - IEEE 802 Chair ) Cc: Gorry Fairhurst ,James Polk , Martin Stiemerling ,Spencer Dawkins , Pat Thaler ,Bob Briscoe , Glenn Parsons - IEEE 802.1 WG chair ,Eric Gray , Dan Romascanu ,Russ Housley Response Contact: David Black Technical Contact: Bob Briscoe Purpose: For comment To: "IEEE 802 – attn. Paul Nikolich, Chair" From: "IETF TSVWG" CC: "Martin Stiemerling" , "Spencer Dawkins" , "Pat Thaler" , "Bob Briscoe" , "Glenn Parsons - IEEE 802.1 WG chair" , "Eric Gray" , "Dan Romascanu" , "Russ Housley" ==Background== In 2001, the IETF introduced explicit congestion notificiation (ECN) to the Internet Protocol as a proposed standard, see RFC 3168. The purpose of ECN was to notify congestion without having to drop packets. The IETF originally specified ECN for cases where buffers were IP-aware. However, ECN is now being used in a number of environments where some of the forwarding devices are solely layer-2 devices, where IEEE protocols encapsulate IP. Originally there was little if any guidance on how to add explicit congestion notification to lower layer protocols, nor on the interface between lower layers and ECN in IP. ==Notification== This liaison statement is addressed at IEEE 802, and particularly though not exclusively the 802.1 WG for congestion marking in bridges and other WGs for other forms of forwarding. The IETF wishes to notify relevant WGs that it has started work on guidelines for adding ECN to protocols that may encapsulate IP and interfacing these protocols with ECN in IP. Then IP may act in its role as an interoperability protocol over multiple forwarding protocols. This activity is led by the IETF's transport services working group (tsvwg). ==Requests== The IETF tsvwg kindly asks IEEE 802: 1) To inform the IETF tsvwg of which IEEE work-groups could be affected by this work. 2) To inform the IETF tsvwg of any specific IEEE specifications affected by this work. 3) to forward this liaison statement to these affected work-groups, and to invite them to review the latest draft of the guidelines, available here: - http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines Review comments are particularly welcome on: - comprehensibility for the IEEE community - usefulness and applicability - technical feasibility Review comments may be posted directly to the IETF tsvwg mailing list . Postings from non-subscribers may be delayed by moderation. Alternatively, subscription is open to all at: < https://www.ietf.org/mailman/listinfo/tsvwg>. ==Relevant IETF Specifications== The following IETF specifications or drafts are particularly relevant to this activity (the relevance of each of them is explained in the first item below): * draft-ietf-tsvwg-ecn-encap-guidelines - http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines * RFC3168 updated by RFC4301, RFC6040 (ECN in resp. IP/TCP, IPsec & IP-in-IP tunnels) - https://tools.ietf.org/html/rfc3168 - https://tools.ietf.org/html/rfc4301 - https://tools.ietf.org/html/rfc6040 * RFC6679 (ECN in RTP) - https://tools.ietf.org/html/rfc6679 * RFC5129 updated by RFC5462 (ECN in MPLS) - https://tools.ietf.org/html/rfc5129 - https://tools.ietf.org/html/rfc5462 * RFC4774 (Specifying alternative semantics for the ECN field) - https://tools.ietf.org/html/rfc4774 * draft-ietf-aqm-recommendation - http://tools.ietf.org/html/draft-ietf-aqm-recommendation Sincerely yours, -- David Black (IETF tsvwg co-chair)