Liaison statement
Explicit Congestion Notification (ECN) and IEEE Protocols

State Posted
Posted Date 2014-12-02
From Group tsvwg
From Contact David Black
To Group IEEE-802
To Contacts Paul Nikolich - IEEE 802 Chair
CcGorry 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
Deadline 2015-02-20 Action Needed
Attachments (None)
Body
To:  "IEEE 802 – attn. Paul Nikolich, Chair" <p.nikolich@ieee.org> 
From:  "IETF TSVWG" <tsvwg-chairs@tools.ietf.org>
CC: "Martin Stiemerling" <mls.ietf@gmail.com>, "Spencer Dawkins"
<spencerdawkins.ietf@gmail.com>,
	"Pat Thaler" <pthaler@broadcom.com>, "Bob Briscoe" <bob.briscoe@bt.com>,
	"Glenn Parsons - IEEE 802.1 WG chair" <gparsons@ieee.org>,
	"Eric Gray" <eric.gray@ericsson.com>, "Dan Romascanu" <dromasca@avaya.com>,
	"Russ Housley" <housley@vigilsec.com>
 
==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
<mailto: tsvwg@ietf.org>. 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) <david.black@emc.com>