Browse Prior Art Database

Tunnelling of Explicit Congestion Notification (RFC6040) Disclosure Number: IPCOM000201994D
Original Publication Date: 2010-Nov-01
Included in the Prior Art Database: 2010-Dec-01
Document File: 70 page(s) / 89K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Briscoe: AUTHOR


Explicit congestion notification (ECN [RFC3168]) allows a forwarding element (e.g., a router) to notify the onset of congestion without having to drop packets. Instead, it can explicitly mark a proportion of packets in the two-bit ECN field in the IP header (Table 1 recaps the ECN codepoints).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 3% of the total text.

Internet Engineering Task Force (IETF)                        B. Briscoe Request for Comments: 6040                                            BT Updates: 3168, 4301, 4774                                  November 2010 Category: Standards Track ISSN: 2070-1721

              Tunnelling of Explicit Congestion Notification


   This document redefines how the explicit congestion notification

   (ECN) field of the IP header should be constructed on entry to and

   exit from any IP-in-IP tunnel.  On encapsulation, it updates RFC 3168

   to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301

   IPsec ECN processing.  On decapsulation, it updates both RFC 3168 and

   RFC 4301 to add new behaviours for previously unused combinations of

   inner and outer headers.  The new rules ensure the ECN field is

   correctly propagated across a tunnel whether it is used to signal one

   or two severity levels of congestion; whereas before, only one

   severity level was supported.  Tunnel endpoints can be updated in any

   order without affecting pre-existing uses of the ECN field, thus

   ensuring backward compatibility.  Nonetheless, operators wanting to

   support two severity levels (e.g., for pre-congestion notification --

   PCN) can require compliance with this new specification.  A thorough

   analysis of the reasoning for these changes and the implications is

   included.  In the unlikely event that the new rules do not meet a

   specific need, RFC 4774 gives guidance on designing alternate ECN

   semantics, and this document extends that to include tunnelling


Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force    (IETF).  It represents the consensus of the IETF community.  It has    received public review and has been approved for publication by the    Internet Engineering Steering Group (IESG).  Further information on    Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,    and how to provide feedback on it may be obtained at

Briscoe                      Standards Track                    [Page 1]
 RFC 6040                     ECN Tunnelling                November 2010

 Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the    document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal    Provisions Relating to IETF Documents    ( in effect on the date of    publication of this document.  Please review these documents    carefully, as...