Technical Summary
RFC 3270 defines how to support the Diffserv architecture in MPLS
networks, including how to encode Diffserv Code Points (DSCPs) in
an MPLS header. RFC 3270 makes no statement about how Explicit
Congestion Notification (ECN) marking might be encoded in the
MPLS header. This draft defines how an operator might define
some of the EXP codepoints for explicit congestion notification,
without precluding other uses.
Working Group Summary
This document touches on subjects that fall into both the MPLS
and TSVWG working groups. The agreement between the WGs was that
the work would occur in TSVWG due to its expertise with ECN,
with a joint Last Call in both working groups. This approach was
followed.
Document Quality
This document has been reviewed in both the MPLS and TSVWG working
groups. The document shepherd is not aware of any existing
implementations.
Personnel
Lars Eggert <lars.eggert@nokia.com> reviewed this document for
the IESG.
RFC Editor Note
Prior to the publication of draft-ietf-tsvwg-ecn-mpls-02.txt as
an RFC, please make the following editorial changes:
- expand ECMP on first use (section 2), i.e. replace the text
"(ECMP)" with "(equal cost multi-path - ECMP)"
- In the first paragraph of section 9.2, fix two typos by
replacing "support ECN for single PHB" with "support ECN for a
single PHB" and "accomplished by simply allocated" with
"accomplished by simply allocating"
- In the Security Considerations section, replace the final
paragraph with the following slightly longer and, we hope,
clearer version:
An ECN sender can use the ECN nonce [RFC3540] to detect a
misbehaving receiver. The ECN nonce works correctly across an
MPLS domain without requiring any specific support from the
proposal in this draft. The nonce does not need to be present in
the MPLS shim header to detect a misbehaving receiver. As long as
the nonce is present in the IP header when the ECN information is
copied from the last MPLS shim header, it will be overwritten if
congestion has been experienced by an LSR. This is all that is
necessary for the sender to detect a misbehaving receiver. If
there were a need for an ECN nonce in the MPLS shim header (e.g.
to detect if one LSR was erasing the markings of an upstream LSR
in the same domain), we believe this proposal does not preclude
the later addition of an ECN nonce capability for specific DSCPs,
just as it does not preclude any other use of the EXP codepoints.