text:
draft-ietf-tsvwg-ecn-mpls-02.txt
rfc5129.txt
Network Working Group B. Davie Network Working Group B. Davie
Internet-Draft Cisco Systems, Inc. Request for Comments: 5129 Cisco Systems, Inc.
Intended status: Standards Track B. Briscoe Category: Standards Track B. Briscoe
Expires: April 6, 2008 J. Tay J. Tay
BT Research BT Research
October 4, 2007 January 2008
Explicit Congestion Marking in MPLS Explicit Congestion Marking in MPLS
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
time. It is inappropriate to use Internet-Drafts as reference
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 6, 2008.
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). This document specifies an Internet standards track protocol for the
improvements. Please refer to the current edition of the "Internet
and status of this protocol. Distribution of this memo is unlimited.
RFC 3270 defines how to support the Diffserv architecture in MPLS RFC 3270 defines how to support the Diffserv architecture in MPLS
networks, including how to encode Diffserv Code Points (DSCPs) in an networks, including how to encode Diffserv Code Points (DSCPs) in an
MPLS header. DSCPs may be encoded in the EXP field, while other uses MPLS header. DSCPs may be encoded in the EXP field, while other uses
of that field are not precluded. RFC3270 makes no statement about of that field are not precluded. RFC3270 makes no statement about
how Explicit Congestion Notification (ECN) marking might be encoded how Explicit Congestion Notification (ECN) marking might be encoded
in the MPLS header. This draft defines how an operator might define in the MPLS header. This document defines how an operator might
some of the EXP codepoints for explicit congestion notification, define some of the EXP codepoints for explicit congestion
without precluding other uses. notification, without precluding other uses.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
[Note to RFC Editor: This section to be removed before publication]
Changes in this version (draft-ietf-tsvwg-ecn-mpls-02.txt) relative
to the last (draft-ietf-tsvwg-ecn-mpls-01.txt):
o Added new text about misordering considerations in Section 6.
o Swapped order of Section 8 and Section 9.
o Explained more fully the example of congestion-based traffic
engineering in Section 9.3.
o Trimmed the example of PCN in Section 9.4 and updated to latest
preferred PCN terminology in PCN appendix.
Changes in draft-ietf-tsvwg-ecn-mpls-01.txt relative to
draft-ietf-tsvwg-ecn-mpls-00.txt:
o Moved the detailed discussion of marking procedures for Pre-
Congestion Notification (PCN) to an appendix.
o Removed PCN as a motivation for the efficient code-point usage in
o Clarified the rationale for preferring the ECT-checking approach
over the approach of [Floyd] in Section 8.1.
o Updated discussion of relationship to RFC3168 in Section 7
o Removed discussion of re-ECN from Security Considerations.
o Fixed typos and nits.
draft-davie-ecn-mpls-00:
o Corrected the description of ECN-MPLS marking proposed in
[Shayman], which closely corresponds to that proposed in this
o Pre-congestion notification (PCN) marking is now described in a
way that does not require normative references to PCN
specifications. PCN discussion now serves only to illustrate how
the ECN marking concepts can be extended to cover more complex
scenarios, with PCN being an example.
o Added specification of behavior when MPLS encapsulated packets
cross from an ECN-enabled domain to a domain that is not ECN-
o Clarified that copying MPLS ECN or PCN marking into exposed IP
header on egress is not mandatory
o Fixed typos and nits
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 7 2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 5
3. Per-domain ECT checking . . . . . . . . . . . . . . . . . . . 9 3. Per-Domain ECT Checking . . . . . . . . . . . . . . . . . . . 7
4. ECN-enabled MPLS domain . . . . . . . . . . . . . . . . . . . 9 4. ECN-Enabled MPLS Domain . . . . . . . . . . . . . . . . . . . 8
4.1. Pushing (adding) one or more labels to an IP packet . . . 10 4.1. Pushing (Adding) One or More Labels to an IP Packet . . . 8
4.2. Pushing one or more labels onto an MPLS labelled packet . 10 4.2. Pushing One or More Labels onto an MPLS Labeled Packet . . 8
4.3. Congestion experienced in an interior MPLS node . . . . . 10 4.3. Congestion Experienced in an Interior MPLS Node . . . . . 8
4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 10 4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 8
4.5. Popping an MPLS label (not the end of the stack) . . . . . 11 4.5. Popping an MPLS Label (Not the End of the Stack) . . . . . 9
4.6. Popping the last MPLS label in the stack . . . . . . . . . 11 4.6. Popping the Last MPLS Label in the Stack . . . . . . . . . 9
4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 11 4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 10
5. ECN-disabled MPLS domain . . . . . . . . . . . . . . . . . . . 12 5. ECN-Disabled MPLS Domain . . . . . . . . . . . . . . . . . . . 10
6. The use of more codepoints with E-LSPs and L-LSPs . . . . . . 12 6. The Use of More Codepoints with E-LSPs and L-LSPs . . . . . . 10
7. Relationship to tunnel behavior in RFC 3168 . . . . . . . . . 12 7. Relationship to Tunnel Behavior in RFC 3168 . . . . . . . . . 11
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
8.1. Marking non-ECN Capable Packets . . . . . . . . . . . . . 13 8.1. Marking Non-ECN-Capable Packets . . . . . . . . . . . . . 11
8.2. Non-ECN capable routers in an MPLS Domain . . . . . . . . 14 8.2. Non-ECN-Capable Routers in an MPLS Domain . . . . . . . . 12
9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. RFC3168-style ECN . . . . . . . . . . . . . . . . . . . . 14 9.1. RFC 3168-Style ECN . . . . . . . . . . . . . . . . . . . . 13
9.2. ECN Co-existence with Diffserv E-LSPs . . . . . . . . . . 15 9.2. ECN Co-Existence with Diffserv E-LSPs . . . . . . . . . . 13
9.3. Congestion-feedback-based Traffic Engineering . . . . . . 15 9.3. Congestion-Feedback-Based Traffic Engineering . . . . . . 14
9.4. PCN flow admission control and flow termination . . . . . 16 9.4. PCN Flow Admission Control and Flow Termination . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Extension to Pre-Congestion Notification . . . . . . 16
Appendix A. Extension to Pre-Congestion Notification . . . . . . 17 A.1. Label Push onto IP Packet . . . . . . . . . . . . . . . . . 16
Appendix A.1. Label Push onto IP packet . . . . . . . . . . . . . 18 A.2. Pushing Additional MPLS Labels . . . . . . . . . . . . . . 16
Appendix A.2. Pushing Additional MPLS Labels . . . . . . . . . . . 18 A.3. Admission Control or Flow Termination Marking Inside
Appendix A.3. Admission Control or Flow Termination Marking MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . 17
inside MPLS domain . . . . . . . . . . . . . . . . . 18 A.4. Popping an MPLS Label (Not End of Stack) . . . . . . . . . 17
Appendix A.4. Popping an MPLS Label (not end of stack) . . . . . . 18 A.5. Popping the Last MPLS Label to Expose IP Header . . . . . . 17
Appendix A.5. Popping the last MPLS Label to expose IP header . . 19 Normative References . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Informative References . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
1.1. Background 1.1. Background
[RFC3168] defines Explicit Congestion Notification for IP. The [RFC3168] defines Explicit Congestion Notification (ECN) for IP. The
primary purpose of ECN is to allow congestion to be signalled without primary purpose of ECN is to allow congestion to be signalled without
dropping packets. dropping packets.
[RFC3270] defines how to support the Diffserv architecture in MPLS [RFC3270] defines how to support the Diffserv architecture in MPLS
in the MPLS header. in the MPLS header.
This draft defines how an operator might define some of the EXP This document defines how an operator might define some of the EXP
codepoints for explicit congestion notification, without precluding codepoints for explicit congestion notification, without precluding
other uses. In parallel to the activity defining the addition of ECN other uses. In parallel to the activity defining the addition of ECN
to IP [RFC3168], two proposals were made to add ECN to MPLS to IP [RFC3168], two proposals were made to add ECN to MPLS
[Floyd][Shayman]. These proposals, however, fell by the wayside. [Floyd][Shayman]. These proposals, however, fell by the wayside.
With ECN for IP now being a proposed standard, and developing With ECN for IP now being a proposed standard, and developing
interest in using pre-congestion notification (PCN) for admission interest in using pre-congestion notification (PCN) for admission
control and flow termination [I-D.ietf-pcn-architecture], there is control and flow termination [PCN], there is consequent interest in
consequent interest in being able to support ECN across IP networks being able to support ECN across IP networks consisting of MPLS-
consisting of MPLS-enabled domains. Therefore it is necessary to enabled domains. Therefore, it is necessary to specify the protocol
specify the protocol for including ECN in the MPLS shim header, and for including ECN in the MPLS shim header and the protocol behavior
the protocol behavior of edge MPLS nodes. of edge MPLS nodes.
We note that in [RFC3168] there are four codepoints used for ECN We note that in [RFC3168], there are four codepoints used for ECN
marking, which are encoded using two bits of the IP header. The MPLS marking, which are encoded using two bits of the IP header. The MPLS
EXP field is the logical place to encode ECN codepoints, but with EXP field is the logical place to encode ECN codepoints, but with
only 3 bits (8 codepoints) available, and with the same field being only 3 bits (8 codepoints) available, and with the same field being
used to convey DSCP information as well, there is a clear incentive used to convey DSCP information as well, there is a clear incentive
to conserve the number of codepoints consumed for ECN purposes. to conserve the number of codepoints consumed for ECN purposes.
Efficient use of the EXP field has been a focus of prior drafts Efficient use of the EXP field has been a focus of prior documents
[Floyd] [Shayman] and we draw on those efforts in this draft as well. [Floyd] [Shayman], and we draw on those efforts in this document as
We also note that [RFC3168] defines default usage of the ECN field We also note that [RFC3168] defines default usage of the ECN field,
but allows for the possibility that some Diffserv PHBs might include but it allows for the possibility that some Diffserv Per Hop
different specifications on how the ECN field is to be used. This Behaviors (PHBs) might include different specifications on how the
draft seeks to preserve that capability. ECN field is to be used. This document seeks to preserve that
capability.
1.2. Intent 1.2. Intent
Our intent is to specify how the MPLS shim header [RFC3032] should Our intent is to specify how the MPLS shim header [RFC3032] should
denote ECN marking and how MPLS nodes should understand whether the denote ECN marking and how MPLS nodes should understand whether the
transport for a packet will be ECN capable. We offer this as a transport for a packet will be ECN capable. We offer this as a
building block, from which to build different congestion notification building block, from which to build different congestion-notification
systems. We do not intend to specify how the resulting congestion systems. We do not intend to specify how the resulting congestion
notification is fed back to an upstream node that can mitigate notification is fed back to an upstream node that can mitigate
congestion. For instance, unlike [Shayman], we do not specify edge- congestion. For instance, unlike [Shayman], we do not specify edge-
to-edge MPLS domain feedback, but we also do not preclude it. to-edge MPLS domain feedback, but we also do not preclude it.
Nonetheless, we do specify how the egress node of an MPLS domain Nonetheless, we do specify how the egress node of an MPLS domain
should copy congestion notification from the MPLS shim into the should copy congestion notification from the MPLS shim into the
encapsulated IP header if the ECN is to be carried onward towards the encapsulated IP header if the ECN is to be carried onward towards the
IP receiver. But we do NOT mandate that MPLS congestion notification IP receiver; but we do *not* mandate that MPLS congestion
must be copied into the IP header for onward transmission. This notification must be copied into the IP header for onward
draft aims to be generic for any use of congestion notification in transmission. This document aims to be generic for any use of
MPLS. Support of [RFC3168] is our primary motivation; some congestion notification in MPLS. Support of [RFC3168] is our primary
additional potential applications to illustrate the flexibility of motivation; some additional potential applications to illustrate the
our approach are described in Section 9. In particular, we aim to flexibility of our approach are described in Section 9. In
support possible future schemes that may use more than one level of particular, we aim to support possible future schemes that may use
congestion marking. more than one level of congestion marking.
1.3. Terminology 1.3. Terminology
This document draws freely on the terminology of ECN [RFC3168] and This document draws freely on the terminology of ECN [RFC3168] and
MPLS [RFC3031]. For ease of reference, we have included some MPLS [RFC3031]. For ease of reference, we have included some
definitions here, but refer the reader to the references above for definitions here, but refer the reader to the references above for
complete specifications of the relevant technologies: complete specifications of the relevant technologies:
o CE: Congestion Experienced. One of the states with which a packet o CE: Congestion Experienced. One of the states with which a packet
may be marked in a network supporting ECN. A packet is marked in may be marked in a network supporting ECN. A packet is marked in
this state by an ECN-capable router, to indicate that this router this state by an ECN-capable router to indicate that this router
was experiencing congestion at the time the packet arrived. was experiencing congestion at the time the packet arrived.
o ECT: ECN-capable Transport. One of the ECN states which a packet o ECT: ECN-capable Transport. One of the ECN states that a packet
may be in when it is sent by an end system. An end system marks a may be in when it is sent by an end system. An end system marks a
packet with an ECT codepoint to indicate that the end-points of packet with an ECT codepoint to indicate that the endpoints of the
the transport protocol are ECN-capable. A router may not mark a transport protocol are ECN-capable. A router may not mark a
packet as CE unless the packet was marked ECT when it arrived. packet as CE unless the packet was marked ECT when it arrived.
o Not-ECT: Not ECN capable transport. An end system marks a packet o Not-ECT: Not ECN-capable transport. An end system marks a packet
with this codepoint to indicate that the end-points of the with this codepoint to indicate that the endpoints of the
transport protocol are not ECN-capable. A congested router cannot transport protocol are not ECN-capable. A congested router cannot
mark such packets as CE, and thus can only drop them to indicate mark such packets as CE, and thus it can only drop them to
congestion. indicate congestion.
o EXP field. A 3 bit field in the MPLS label header [RFC3032] which o EXP field. A 3-bit field in the MPLS label header [RFC3032] that
may be used to convey Diffserv information (and is also used in may be used to convey Diffserv information (and is also used in
this draft to carry ECN information). this document to carry ECN information).
o PHP. Penultimate Hop Popping. An MPLS operation in which the o PHP. Penultimate Hop Popping. An MPLS operation in which the
penultimate Label Switching Router (LSR) on a Label Switched Path penultimate Label Switching Router (LSR) on a Label Switched Path
(LSP) removes the top label from the packet before forwarding the (LSP) removes the top label from the packet before forwarding the
packet to the final LSR on the LSP. packet to the final LSR on the LSP.
2. Use of MPLS EXP Field for ECN 2. Use of MPLS EXP Field for ECN
We propose that LSRs configured for explicit congestion notification We propose that LSRs configured for explicit congestion notification
should use the EXP field in the MPLS shim header. However, [RFC3270] should use the EXP field in the MPLS shim header. However, [RFC3270]
already defines use of codepoints in the EXP field for differentiated already defines use of codepoints in the EXP field for differentiated
services. Although it does not preclude other compatible uses of the services. Although it does not preclude other compatible uses of the
EXP field, this clearly seems to limit the space available for ECN, EXP field, this clearly seems to limit the space available for ECN,
given the field is only 3 bits (8 codepoints). given the field is only 3 bits (8 codepoints).
[RFC3270] defines two possible approaches for requesting [RFC3270] defines two possible approaches for requesting
differentiated service treatment from an LSR. differentiated service treatment from an LSR:
o In the E-LSP approach, different codepoints of the EXP field in o In the EXP-Inferred-PSC LSP (E-LSP) approach, different codepoints
the MPLS shim header are used to indicate the packet's per hop of the EXP field in the MPLS shim header are used to indicate the
behavior (PHB). packet's per hop behavior (PHB).
o In the L-LSP approach, an MPLS label is assigned for each PHB o In the Label-Only-Inferred-PSC LSP (L-LSP) approach, an MPLS label
scheduling class (PSC, as defined in [RFC3260], so that an LSR is assigned for each PHB scheduling class (PSC, as defined in
determines both its forwarding and its scheduling behavior from [RFC3260], so that an LSR determines both its forwarding and its
the label. scheduling behavior from the label.
If an MPLS domain uses the L-LSP approach, there is likely to be If an MPLS domain uses the L-LSP approach, there is likely to be
space in the EXP field for ECN codepoint(s). Where the E-LSP space in the EXP field for ECN codepoint(s). Where the E-LSP
approach is used, then codepoint space in the EXP field is likely to approach is used, codepoint space in the EXP field is likely to be
be scarce. This draft focuses on interworking ECN marking with the scarce. This document focuses on interworking ECN marking with the
E-LSP approach as it is the tougher problem. Consequently the same E-LSP approach, as it is the tougher problem. Consequently, the same
approach can also be applied with L-LSPs. approach can also be applied with L-LSPs.
We recommend that explicit congestion notification in MPLS should use We recommend that explicit congestion notification in MPLS should use
codepoints instead of bits in the EXP field. Since not every PHB codepoints instead of bits in the EXP field. Since not every PHB
will necessarily require an associated ECN codepoint it would be will necessarily require an associated ECN codepoint, it would be
wasteful to assign a dedicated bit for ECN. (There may also be cases wasteful to assign a dedicated bit for ECN. (There may also be cases
where a given PHB might need more than one ECN-like codepoint; see where a given PHB might need more than one ECN-like codepoint; see
Section 9.4 for an example.) Section 9.4 for an example).
For each PHB that uses ECN marking, we assume one EXP codepoint will For each PHB that uses ECN marking, we assume one EXP codepoint will
be defined meaning not congestion marked (Not-CM), and at least one be defined as not congestion marked (Not-CM), and at least one other
other codepoint will be defined meaning congestion marked (CM). codepoint will be defined as congestion marked (CM). Therefore, each
Therefore, each PHB that uses ECN marking will consume at least two PHB that uses ECN marking will consume at least two EXP codepoints,
EXP codepoints. But PHBs that do not use ECN marking will only but PHBs that do not use ECN marking will only consume one.
consume one.
Further, we wish to use minimal space in the MPLS shim header to tell Further, we wish to use minimal space in the MPLS shim header to tell
interior LSRs whether each packet will be received by an ECN-capable interior LSRs whether each packet will be received by an ECN-capable
transport (ECT). Nonetheless, we must ensure that an end-point that transport (ECT). Nonetheless, we must ensure that an endpoint that
would not understand an ECN mark will not receive one, otherwise it would not understand an ECN mark will not receive one, otherwise it
will not be able to respond to congestion as it should. In the past, will not be able to respond to congestion as it should. In the past,
three solutions to this problem have been proposed: three solutions to this problem have been proposed:
o One possible approach is for congested LSRs to mark the ECN field o One possible approach is for congested LSRs to mark the ECN field
in the underlying IP header at the bottom of the label stack. in the underlying IP header at the bottom of the label stack.
Although many commercial LSRs routinely access the IP header for Although many commercial LSRs routinely access the IP header for
other reasons (ECMP), there are numerous drawbacks to attempting other reasons (equal cost multi-path - ECMP), there are numerous
to find an IP header beneath an MPLS label stack. Notably, there drawbacks to attempting to find an IP header beneath an MPLS label
is the challenge of detecting the absence of an IP header when stack. Notably, there is the challenge of detecting the absence
non-IP packets are carried on an LSP. Therefore we will not of an IP header when non-IP packets are carried on an LSP.
consider this approach further. Therefore, we will not consider this approach further.
o In the scheme suggested by [Floyd] ECT and CE are overloaded into o In the scheme suggested by [Floyd], ECT and CE are overloaded into
one bit, so that a 0 means ECT while a 1 might either mean Not-ECT one bit, so that a 0 means ECT while a 1 might either mean Not-ECT
or it might mean CE. A packet that has been marked as having or it might mean CE. A packet that has been marked as having
experienced congestion upstream, and then is picked out for experienced congestion upstream, and then is picked out for
marking at a second congested LSR, will be dropped by the second marking at a second congested LSR, will be dropped by the second
LSR since it cannot determine whether the packet has previously LSR since it cannot determine whether the packet has previously
experienced congestion or if ECN is not supported by the experienced congestion or if ECN is not supported by the
transport. transport.
While such an approach seemed potentially palatable, we do not While such an approach seemed potentially palatable, we do not
recommend it here for the following reasons. In some cases we recommend it here for the following reasons. In some cases, we
wish to be able to use ECN marking long before actual congestion wish to be able to use ECN marking long before actual congestion
(e.g. pre-congestion notification). In these circumstances, (e.g., pre-congestion notification). In these circumstances,
marking rates at each LSR might be non-negligible most of the marking rates at each LSR might be non-negligible most of the
time, so the chances of a previously marked packet encountering an time, so the chances of a previously marked packet encountering an
LSR that wants to mark it again will also be non-negligible. In LSR that wants to mark it again will also be non-negligible. In
the case where CE and not-ECT are indistinguishable to core the case where CE and not-ECT are indistinguishable to core
routers, such a scenario could lead to unacceptable drop rates. routers, such a scenario could lead to unacceptable drop rates.
If the typical marking rate at every router or LSR is p, and the If the typical marking rate at every router or LSR is p, and the
typical diameter of the network of LSRs is d, then the probability typical diameter of the network of LSRs is d, then the probability
that a marked packet will be chosen for marking more than once is that a marked packet will be chosen for marking more than once is
1-[Pr(never marked) + Pr(marked at exactly one hop)] = 1- [(1-p)^d 1-[Pr(never marked) + Pr(marked at exactly one hop)] = 1- [(1-p)^d
+ dp(1-p)^(d-1)]. For instance, with 6 LSRs in a row, each + dp(1-p)^(d-1)]. For instance, with 6 LSRs in a row, each
marking ECN with 1% probability, the chances of a packet that is marking ECN with 1% probability, the chances of a packet that is
already marked being chosen for marking a second time is 0.15%. already marked being chosen for marking a second time is 0.15%.
The bit overloading scheme would therefore introduce a drop rate The bit-overloading scheme would therefore introduce a drop rate
of 0.15% unnecessarily. Given that most modern core networks are of 0.15% unnecessarily. Given that most modern core networks are
sized to introduce near-zero packet drop, it may be unacceptable sized to introduce near-zero packet drop, it may be unacceptable
to drop over one in a thousand packets unnecessarily. to drop over one in a thousand packets unnecessarily.
o A third possible approach was suggested by [Shayman]. In this o A third possible approach was suggested by [Shayman]. In this
scheme, interior LSRs assume that the endpoints are ECN-capable, scheme, interior LSRs assume that the endpoints are ECN-capable,
but this assumption is checked when the final label is popped. If but this assumption is checked when the final label is popped. If
an interior LSR has marked ECN in the EXP field of the shim an interior LSR has marked ECN in the EXP field of the shim
header, but the IP header says the endpoints are not ECN capable, header, but the IP header says the endpoints are not ECN-capable,
the edge router (or penultimate router, if using penultimate hop the edge router (or penultimate router, if using penultimate hop
popping) drops the packet. We recommend this scheme, which we popping) drops the packet. We recommend this scheme, which we
call `per-domain ECT checking', and define it more precisely in call `per-domain ECT checking', and define it more precisely in
the following section. Its chief drawback is that it can cause the following section. Its chief drawback is that it can cause
packets to be forwarded after encountering congestion only to be packets to be forwarded after encountering congestion only to be
dropped at the egress of the MPLS domain. The rationale for this dropped at the egress of the MPLS domain. The rationale for this
decision is given in Section 8.1. decision is given in Section 8.1.
3. Per-domain ECT checking 3. Per-Domain ECT Checking
For the purposes of this discussion, we define the egress nodes of an For the purposes of this discussion, we define the egress nodes of an
MPLS domain as the nodes that pop the last MPLS label from the label MPLS domain as the nodes that pop the last MPLS label from the label
stack, exposing the IP (or, potentially non-IP) header. Note that stack, exposing the IP (or, potentially non-IP) header. Note that
such a node may be the ultimate or penultimate hop of an LSP, such a node may be the ultimate or penultimate hop of an LSP,
depending on whether penultimate hop popping (PHP) is employed. depending on whether penultimate hop popping (PHP) is employed.
In the per-domain ECT checking approach, the egress nodes take In the per-domain ECT checking approach, the egress nodes take
responsibility for checking whether the transport is ECN capable. responsibility for checking whether the transport is ECN-capable.
This draft does not specify how these nodes should pass on congestion This document does not specify how these nodes should pass on
notification, because different approaches are likely in different congestion notification because different approaches are likely in
scenarios. However, if congestion notification in the MPLS header is different scenarios. However, if congestion notification in the MPLS
copied into the IP header, the procedure MUST conform to the header is copied into the IP header, the procedure MUST conform to
specification given here. the specification given here.
If congestion notification is passed to the transport without first If congestion notification is passed to the transport without first
passing it onward in the IP header, the approach used must take passing it onward in the IP header, the approach used must take
similar care to check that the transport is ECN capable before similar care to check that the transport is ECN-capable before
passing it ECN markings. Specifically, if the transport for a passing it ECN markings. Specifically, if the transport for a
particular congestion marked MPLS packet is found not to be ECN- particular congestion marked MPLS packet is found not to be ECN-
capable, the packet MUST be dropped at this egress node. capable, the packet MUST be dropped at this egress node.
In the per-domain ECT checking approach, only the egress nodes check In the per-domain ECT checking approach, only the egress nodes check
whether an IP packet is destined for an ECN-capable transport. whether an IP packet is destined for an ECN-capable transport.
Therefore, any single LSR within an MPLS domain MUST NOT be Therefore, any single LSR within an MPLS domain MUST NOT be
configured to enable ECN marking unless all the egress LSRs configured to enable ECN marking unless all the egress LSRs
surrounding it are already configured to handle ECN marking. surrounding it are already configured to handle ECN marking.
We call a domain surrounded by ECN-capable egress LSRs an ECN-enabled We call a domain surrounded by ECN-capable egress LSRs an ECN-enabled
MPLS domain. This term only implies that all the egress LSRs are MPLS domain. This term only implies that all the egress LSRs are
ECN-enabled; some interior LSRs may not be ECN-enabled. For ECN-enabled; some interior LSRs may not be ECN-enabled. For
instance, it would be possible to use some legacy LSRs incapable of instance, it would be possible to use some legacy LSRs incapable of
supporting ECN in the interior of an MPLS domain as long as all the supporting ECN in the interior of an MPLS domain as long as all the
egress LSRs were ECN-capable. Note that if PHP is used, the egress LSRs were ECN-capable. Note that if PHP is used, the
"penultimate hop" routers which perform the pop operation do need to "penultimate hop" routers that perform the pop operation do need to
be ECN-enabled, since they are acting in this context as egress LSRs. be ECN-enabled since they are acting in this context as egress LSRs.
4. ECN-enabled MPLS domain 4. ECN-Enabled MPLS Domain
In the following subsections we describe various operations affecting In the following subsections, we describe various operations
the ECN marking of a packet that may be performed at MPLS edge and affecting the ECN marking of a packet that may be performed at MPLS-
core LSRs. edge and core LSRs.
4.1. Pushing (adding) one or more labels to an IP packet 4.1. Pushing (Adding) One or More Labels to an IP Packet
On encapsulating an IP packet with an MPLS label stack, the ECN field On encapsulating an IP packet with an MPLS label stack, the ECN field
must be translated from the IP packet into the MPLS EXP field. The must be translated from the IP packet into the MPLS EXP field. The
Not-CM (not congestion marked) state is set in the MPLS EXP field if Not-CM (not congestion marked) state is set in the MPLS EXP field if
the ECN status of the IP packet is "Not ECT" or ECT(1) or ECT(0). the ECN status of the IP packet is Not-ECT or ECT(1) or ECT(0). The
The CM state is set if the ECN status of the IP packet is "CE". If CM state is set if the ECN status of the IP packet is CE. If more
more than one label is pushed at one time, the same value should be than one label is pushed at one time, the same value should be placed
placed in the EXP value of all label stack entries. in the EXP value of all label stack entries.
4.2. Pushing one or more labels onto an MPLS labelled packet 4.2. Pushing One or More Labels onto an MPLS Labeled Packet
The EXP field is copied directly from the topmost label before the The EXP field is copied directly from the topmost label before the
push to the newly added outer label. If more than one label is being push to the newly added outer label. If more than one label is being
pushed, the same EXP value is copied to all label stack entries. pushed, the same EXP value is copied to all label-stack entries.
4.3. Congestion experienced in an interior MPLS node 4.3. Congestion Experienced in an Interior MPLS Node
If the EXP codepoint of the packet maps to a PHB that uses ECN If the EXP codepoint of the packet maps to a PHB that uses ECN
marking and the marking algorithm requires the packet to be marked, marking, and the marking algorithm requires the packet to be marked,
the CM state is set (irrespective of whether it is already in the CM the CM state is set (irrespective of whether it is already in the CM
state). state).
If the buffer is full, a packet is dropped. If the buffer is full, a packet is dropped.
4.4. Crossing a Diffserv Domain Boundary 4.4. Crossing a Diffserv Domain Boundary
If an MPLS-encapsulated packet crosses a Diffserv domain boundary, it If an MPLS-encapsulated packet crosses a Diffserv domain boundary, it
may be the case that the two domains use different encodings of the may be the case that the two domains use different encodings of the
same PHB in the EXP field. In such cases, the EXP field must be same PHB in the EXP field. In such cases, the EXP field must be
rewritten at the domain boundary. If the PHB is one that supports rewritten at the domain boundary. If the PHB is one that supports
ECN, then the appropriate ECN marking should also be preserved when ECN, then the appropriate ECN marking should also be preserved when
the EXP field is mapped at the boundary. the EXP field is mapped at the boundary.
If an MPLS-encapsulated packet that is in the CM state crosses from a If an MPLS-encapsulated packet that is in the CM state crosses from a
domain that is ECN-enabled (as defined in Section 3) to a domain that domain that is ECN-enabled (as defined in Section 3) to a domain that
is not ECN-enabled, then it is necessary to perform the egress is not ECN-enabled, then it is necessary to perform the egress
checking procedures at the egress LSR of the ECN-enabled domain. checking procedures at the egress LSR of the ECN-enabled domain.
This means that if the encapsulated packet is not ECN capable, the This means that if the encapsulated packet is not ECN-capable, the
packet MUST be dropped. Note that this implies the egress LSR must packet MUST be dropped. Note that this implies the egress LSR must
be able to look beneath the MPLS header without popping the label be able to look beneath the MPLS header without popping the label
stack. stack.
The related issue of Diffserv tunnel models is discussed in The related issue of Diffserv tunnel models is discussed in
Section 4.7. Section 4.7.
4.5. Popping an MPLS label (not the end of the stack) 4.5. Popping an MPLS Label (Not the End of the Stack)
When a packet has more than one MPLS label in the stack and the top When a packet has more than one MPLS label in the stack and the top
label is popped, another MPLS label is exposed. In this case the ECN label is popped, another MPLS label is exposed. In this case, the
information should be transferred from the outer EXP field to the ECN information should be transferred from the outer EXP field to the
inner MPLS label in the following manner. If the inner EXP field is inner MPLS label in the following manner. If the inner EXP field is
Not-CM, the inner EXP field is set to the same CM or Not-CM state as Not-CM, the inner EXP field is set to the same CM or Not-CM state as
the outer EXP field. If the inner EXP field is CM, it remains the outer EXP field. If the inner EXP field is CM, it remains
unchanged whatever the outer EXP field. Note that an inner value of unchanged whatever the outer EXP field. Note that an inner value of
CM and an outer value of not-CM should be considered anomalous, and CM and an outer value of not-CM should be considered anomalous, and
SHOULD be logged in some way by the LSR. SHOULD be logged in some way by the LSR.
4.6. Popping the last MPLS label in the stack 4.6. Popping the Last MPLS Label in the Stack
When the last MPLS label is popped from the packet, its payload is When the last MPLS label is popped from the packet, its payload is
exposed. If that packet is not IP, and does not have any capability exposed. If that packet is not IP, and does not have any capability
equivalent to ECT, it is assumed Not-ECT and treated as such. That equivalent to ECT, it is assumed Not-ECT, and it is treated as such.
means that if the EXP value of the MPLS header was CM, the packet That means that if the EXP value of the MPLS header is CM, the packet
MUST be dropped. MUST be dropped.
Assuming an IP packet was exposed, we have to examine whether that Assuming an IP packet was exposed, we have to examine whether or not
packet is ECT or not. A Not-ECT packet MUST be dropped if the EXP that packet is ECT. A Not-ECT packet MUST be dropped if the EXP
field is CM. field is CM.
For the remainder of this section, we describe the behavior that is For the remainder of this section, we describe the behavior that is
required if the ECN information is to be transferred from the MPLS required if the ECN information is to be transferred from the MPLS
header into the exposed IP header for onward transmission. As noted header into the exposed IP header for onward transmission. As noted
in Section 1.2, such behavior is not mandated by this document, but in Section 1.2, such behavior is not mandated by this document, but
may be selected by an operator. may be selected by an operator.
If the inner IP packet is Not-ECT, its ECN field remains unchanged if If the inner IP packet is Not-ECT, its ECN field remains unchanged if
the EXP field is Not-CM. If the ECN field of the inner packet is set the EXP field is Not-CM. If the ECN field of the inner packet is set
to ECT(0), ECT(1) or CE, the ECN field remains unchanged if the EXP to ECT(0), ECT(1), or CE, the ECN field remains unchanged if the EXP
field is set to Not-CM. The ECN field is set to CE if the EXP field field is set to Not-CM. The ECN field is set to CE if the EXP field
is CM. Note that an inner value of CE and an outer value of not-CM is CM. Note that an inner value of CE and an outer value of not-CM
should be considered anomalous, and SHOULD be logged in some way by should be considered anomalous, and SHOULD be logged in some way by
the LSR. the LSR.
4.7. Diffserv Tunneling Models 4.7. Diffserv Tunneling Models
[RFC3270] describes three tunneling models for Diffserv support [RFC3270] describes three tunneling models for Diffserv support
across MPLS Domains, referred to as the uniform, short pipe, and pipe across MPLS Domains, referred to as the uniform, short pipe, and pipe
models. The differences between these models lie in whether the models. The differences between these models lie in whether the
Diffserv treatment that applies to a packet while it travels along a Diffserv treatment that applies to a packet while it travels along a
particular LSP is carried to the last hop of the LSP and beyond the particular LSP is carried to the ingress of the last hop, to the
last hop. Depending on which mode is preferred by an operator, the egress of the last hop, or beyond the last hop. Depending on which
EXP value or DSCP value of an exposed header following a label pop mode is preferred by an operator, the EXP value or DSCP value of an
may or may not be dependent on the EXP value of the label that is exposed header following a label pop may or may not be dependent on
removed by the pop operation. We believe that in the case of ECN the EXP value of the label that is removed by the pop operation. We
marking, the use of these models should only apply to the encoding of believe that, in the case of ECN marking, the use of these models
the Diffserv PHB in the EXP value, and that the choice of codepoint should only apply to the encoding of the Diffserv PHB in the EXP
for ECN should always be made based on the procedures described value, and that the choice of codepoint for ECN should always be made
above, independent of the tunneling model. based on the procedures described above, independent of the tunneling
5. ECN-disabled MPLS domain 5. ECN-Disabled MPLS Domain
If ECN is not enabled on all the egress LSRs of a domain, ECN MUST If ECN is not enabled on all the egress LSRs of a domain, ECN MUST
NOT be enabled on any LSRs throughout the domain. If congestion is NOT be enabled on any LSRs throughout the domain. If congestion is
experienced on any LSR in an ECN-disabled MPLS domain, packets MUST experienced on any LSR in an ECN-disabled MPLS domain, packets MUST
be dropped, NOT marked. The exact algorithm for deciding when to be dropped; they MUST NOT be marked. The exact algorithm for
drop packets during congestion (e.g. tail-drop, RED, etc.) is a local deciding when to drop packets during congestion (e.g., tail-drop,
matter for the operator of the domain. RED, etc.) is a local matter for the operator of the domain.
6. The use of more codepoints with E-LSPs and L-LSPs 6. The Use of More Codepoints with E-LSPs and L-LSPs
[RFC3270] gives different options with E-LSPs and L-LSPs and some of [RFC3270] gives different options with E-LSPs and L-LSPs, and some of
those could potentially provide ample EXP codepoints for ECN. those could potentially provide ample EXP codepoints for ECN.
However, deploying L-LSPs vs E-LSPs has many implications such as However, deploying L-LSPs vs. E-LSPs has many implications, such as
platform support and operational complexity. The above ECN MPLS platform support and operational complexity. The above ECN MPLS
solution should provide some flexibility. If the operator has solution should provide some flexibility. If the operator has
deployed one L-LSP per PHB scheduling class, then EXP space will be a deployed one L-LSP per PHB scheduling class, then EXP space will be a
non-issue and it could be used to achieve more sophisticated ECN non-issue, and it could be used to achieve more sophisticated ECN
behavior if required. If the operator wants to stick to E-LSPs and behavior if required. If the operator wants to stick to E-LSPs and
uses a handful of EXP codepoints for Diffserv, it may be desirable to uses a handful of EXP codepoints for Diffserv, it may be desirable to
operate with a minimum number of extra ECN codepoints, even if this operate with a minimum number of extra ECN codepoints, even if this
comes with some compromise on ECN optimality. See Section 9 for comes with some compromise on ECN optimality. See Section 9 for
discussion of some possible deployment scenarios. discussion of some possible deployment scenarios.
We note that in a network where L-LSPs are used, ECN marking SHOULD We note that in a network where L-LSPs are used, ECN marking SHOULD
NOT cause packets from the same microflow but with different ECN NOT cause packets from the same microflow, but with different ECN
markings to be sent on different LSPs. As discussed in [RFC3270], markings, to be sent on different LSPs. As discussed in [RFC3270],
packets of a single microflow should always travel on the same LSP to packets of a single microflow should always travel on the same LSP to
avoid possible misordering. Thus, ECN marking of packets on L-LSPs avoid possible misordering. Thus, ECN marking of packets on L-LSPs
SHOULD only affect the EXP value of the packets. SHOULD only affect the EXP value of the packets.
7. Relationship to tunnel behavior in RFC 3168 7. Relationship to Tunnel Behavior in RFC 3168
[RFC3168] defines two modes of encapsulating ECN-marked IP packets [RFC3168] defines two modes of encapsulating ECN-marked IP packets
inside additional IP headers when tunnels are used. The two modes inside additional IP headers when tunnels are used. The two modes
are the "full functionality" and "limited functionality" modes. In are the "full functionality" and "limited functionality" modes. In
the full functionality mode, the ECT information from the inner the full functionality mode, the ECT information from the inner
header is copied to the outer header at the tunnel ingress, but the header is copied to the outer header at the tunnel ingress, but the
CE information is not. In the limited functionality mode, neither CE information is not. In the limited functionality mode, neither
ECT nor CE information is copied to the outer header, and thus ECN ECT nor CE information is copied to the outer header, and thus ECN
cannot be applied to the encapsulated packet. cannot be applied to the encapsulated packet.
skipping to change at page 13, line 26
termination marking mechanism proposed for PCN works by only termination marking mechanism proposed for PCN works by only
considering packets for marking that have not already been marked considering packets for marking that have not already been marked
upstream. Unless existing flow termination marking is copied from upstream. Unless existing flow termination marking is copied from
the inner to the outer header at tunnel ingress, the mechanism the inner to the outer header at tunnel ingress, the mechanism
doesn't terminate enough traffic in cases where anomalous events hit doesn't terminate enough traffic in cases where anomalous events hit
multiple domains at once. [RFC3168] does not give any reasons multiple domains at once. [RFC3168] does not give any reasons
against conveying CE information from the inner header to the outer against conveying CE information from the inner header to the outer
in the "full functionality" mode. Furthermore, [RFC4301] specifies in the "full functionality" mode. Furthermore, [RFC4301] specifies
that the ECN marking should be copied from inner header to outer that the ECN marking should be copied from inner header to outer
header in IPSEC tunnels, consistent with the approach defined here. header in IPSEC tunnels, consistent with the approach defined here.
[I-D.briscoe-tsvwg-ecn-tunnel] discusses this issue in more detail. [BRISCOE-ECN] discusses this issue in more detail. In summary, the
In summary, the approach described in Section 4 appears to be both a approach described in Section 4 appears to be both a sound technical
sound technical choice and consistent with the current state of choice and consistent with the current state of thinking in the IETF.
thinking in the IETF.
8. Deployment Considerations 8. Deployment Considerations
8.1. Marking non-ECN Capable Packets 8.1. Marking Non-ECN-Capable Packets
What are the consequences of marking a packet that is not ECN- What are the consequences of marking a packet that is not ECN-
capable? Even if it will be dropped before leaving the domain, capable? Even if it will be dropped before leaving the domain,
doesn't this consume resources unnecessarily? doesn't this consume resources unnecessarily?
The problem only arises if there is congestion downstream of an The problem only arises if there is congestion downstream of an
earlier congested queue in the same MPLS domain. Downstream earlier congested queue in the same MPLS domain. Congested LSRs
congested LSRs might forward packets already marked, even though they downstream might forward packets already marked, even though they
will be dropped later when the inner IP header is found to be Not-ECT will be dropped later when the inner IP header is found to be Not-ECT
on decapsulation. Such packets might cause the downstream LSRs to on decapsulation. Such packets might cause the downstream LSRs to
mark (or drop) other packets that they would otherwise not have had mark (or drop) other packets that they would otherwise not have had
to. to.
We expect congestion will typically be rare in MPLS networks, but it We expect congestion will typically be rare in MPLS networks, but it
might not be. The extra unnecessary load at downstream LSRs will not might not be. The extra unnecessary load at downstream LSRs will not
be more than the fraction of marked packets from upstream LSRs, even be more than the fraction of marked packets from upstream LSRs, even
in the worst case where no transports are ECN capable. Therefore the in the worst case where no transports are ECN-capable. Therefore,
amount of unnecessary marking (or drop) on an LSR will not be more the amount of unnecessary marking (or drop) on an LSR will not be
than the product of its local marking rate and the marking rate due more than the product of its local marking rate and the marking rate
to upstream LSRs within the same domain - typically the product of due to upstream LSRs within the same domain -- typically the product
two small (often zero) probabilities. of two small (often zero) probabilities.
This is why we decided to use the per-domain ECT checking approach - This is why we decided to use the per-domain ECT checking approach --
because the most likely effect would be a very slightly increased because the most likely effect would be a very slightly increased
marking rate, which would result in very slightly higher drop only marking rate, which would result in very slightly higher drop only
for non-ECN-capable transports. We chose not to use the [Floyd] for non-ECN-capable transports. We chose not to use the [Floyd]
alternative which introduced a low but persistent level of alternative, which introduced a low but persistent level of
unnecessary packet drop for all time, even for ECN-capable unnecessary packet drop for all time, even for ECN-capable
transports. Although that scheme did not carry traffic to the edge transports. Although that scheme did not carry traffic to the edge
of the MPLS domain only to be dropped on decapsulation, we felt our of the MPLS domain only to be dropped on decapsulation, we felt our
minor inefficiency was a small price to pay. And it would get minor inefficiency was a small price to pay; and it would get smaller
smaller still if ECN deployment widened. still if ECN deployment widened.
A partial solution would be to preferentially drop packets arriving A partial solution would be to preferentially drop packets arriving
at a congested router that were already marked. There is no solution at a congested router that were already marked. There is no solution
to the problem of marking a packet when congestion is caused by to the problem of marking a packet when congestion is caused by
another packet that should have been dropped. However, the chance of another packet that should have been dropped. However, the chance of
such an occurrence is very low and the consequences are not such an occurrence is very low, and the consequences are not
significant. It merely causes an application to very occasionally significant. It merely causes an application to very occasionally
slow down its rate when it did not have to. slow down its rate when it did not have to.
8.2. Non-ECN capable routers in an MPLS Domain 8.2. Non-ECN-Capable Routers in an MPLS Domain
What if an MPLS domain wants to use ECN, but not all legacy routers What if an MPLS domain wants to use ECN, but not all legacy routers
are able to support it? are able to support it?
If the legacy router(s) are used in the interior, this is not a If the legacy router(s) are used in the interior, this is not a
problem. They will simply have to drop the packets if they are problem. They will simply have to drop the packets if they are
congested, rather than mark them, which is the standard behavior for congested, rather than mark them, which is the standard behavior for
IP routers that are not ECN-enabled. IP routers that are not ECN-enabled.
If the legacy router were used as an egress router, it would not be If the legacy router were used as an egress router, it would not be
able to check the ECN capability of the transport correctly. An able to check the ECN-capability of the transport correctly. An
operator in this position would not be able to use this solution and operator in this position would not be able to use this solution and
therefore MUST NOT enable ECN unless all egress routers are ECN- therefore MUST NOT enable ECN unless all egress routers are ECN-
capable. capable.
9. Example Uses 9. Example Uses
9.1. RFC3168-style ECN 9.1. RFC 3168-Style ECN
[RFC3168] proposes the use of ECN in TCP and introduces the use of [RFC3168] proposes the use of ECN in TCP, and it introduces the use
ECN-Echo and CWR flags in the TCP header for initialization. The TCP of ECN-Echo and Congestion Window Reduced (CWR) flags in the TCP
sender responds accordingly (such as not increasing the congestion header for initialization. The TCP sender responds accordingly (such
window) when it receives an ECN-Echo (ECE) ACK packet (that is, an as not increasing the congestion window) when it receives an ECN-Echo
ACK packet with ECN-Echo flag set in the TCP header), then the sender (ECE) ACK packet (that is, an ACK packet with ECN-Echo flag set in
knows that congestion was encountered in the network on the path from the TCP header), then the sender knows that congestion was
the sender to the receiver. encountered in the network on the path from the sender to the
receiver.
It would be possible to enable ECN in an MPLS domain for Diffserv It would be possible to enable ECN in an MPLS domain for Diffserv
PHBs like AF and best efforts that are expected to be used by TCP and PHBs like AF and best efforts that are expected to be used by TCP and
similar transports (e.g. DCCP [RFC4340]). Then end-to-end similar transports (e.g., DCCP [RFC4340]). Then, end-to-end
congestion control in transports capable of understanding ECN would congestion control in transports capable of understanding ECN would
be able to respond to approaching congestion on LSRs without having be able to respond to approaching congestion on LSRs without having
to rely on packet discard to signal congestion. to rely on packet discard to signal congestion.
9.2. ECN Co-existence with Diffserv E-LSPs 9.2. ECN Co-Existence with Diffserv E-LSPs
Many operators today have deployed Diffserv using the E-LSP approach Many operators today have deployed Diffserv using the E-LSP approach
of [RFC3270]. In many cases the number of PHBs used is less than 8, of [RFC3270]. In many cases, the number of PHBs used is less than 8,
and hence there remain available codepoints in the EXP space. If an and hence there remain available codepoints in the EXP space. If an
operator wished to support ECN for single PHB, this can be operator wished to support ECN for a single PHB, this could be
accomplished by simply allocated a second codepoint to the PHB for accomplished by simply allocating a second codepoint to the PHB for
the "CM" state of that PHB and retaining the old codepoint for the the CM state of that PHB and retaining the old codepoint for the
"not-CM" state. An operator with only four deployed PHBs could of not-CM state. An operator with only four deployed PHBs could, of
course enable ECN marking on all those PHBs. It is easy to imagine course, enable ECN marking on all those PHBs. It is easy to imagine
cases where some PHBs might benefit more from ECN than others - for cases where some PHBs might benefit more from ECN than others -- for
example, an operator might use ECN on a premium data service but not example, an operator might use ECN on a premium data service but not
on a PHB used for best effort internet traffic. on a PHB used for best-effort Internet traffic.
As an illustrative example of how the EXP field might be used in this As an illustrative example of how the EXP field might be used in this
case, consider the example of an operator who is using the aggregated case, consider the example of an operator who is using the aggregated
service classes proposed in [I-D.ietf-tsvwg-diffserv-class-aggr]. He service classes proposed in [TSVWG]. He may choose to support ECN
may choose to support ECN only for the Assured Elastic Treatment only for the Assured Elastic Treatment Aggregate, using the EXP
Aggregate, using the EXP codepoint 010 for the not-CM state and 011 codepoint 010 for the not-CM state and 011 for the CM state. All
for the CM state. All other codepoints could be the same as in other codepoints could be the same as in [TSVWG]. Of course, any
[I-D.ietf-tsvwg-diffserv-class-aggr]. Of course any other other combination of EXP values can be used according to the specific
combination of EXP values can be used according to the specific set set of PHBs and marking conventions used within that operator's
of PHBs and marking conventions used within that operator's network. network.
9.3. Congestion-feedback-based Traffic Engineering 9.3. Congestion-Feedback-Based Traffic Engineering
Shayman's traffic engineering [Shayman] presents another example Shayman's traffic engineering [Shayman] presents another example
application of ECN feedback in an MPLS domain. Shayman proposed the application of ECN feedback in an MPLS domain. Shayman proposed the
use of ECN by an egress LSR feeding back congestion to an ingress LSR use of ECN by an egress LSR feeding back congestion to an ingress LSR
to mitigate congestion by employing dynamic traffic engineering to mitigate congestion by employing dynamic traffic engineering
techniques such as shifting flows to an alternate path. It proposed techniques, such as shifting flows to an alternate path. It proposed
a new RSVP message which was sent by the egress LSR to the ingress a new Resource Reservation Protocol (RSVP) message, which was sent by
LSR (and ignored by transit LSRs) to indicate congestion along the the egress LSR to the ingress LSR (and ignored by transit LSRs) to
path. Thus, rather than providing the same style of congestion indicate congestion along the path. Thus, rather than providing the
notification to endpoints as defined in [RFC3168], [Shayman] limits same style of congestion notification to endpoints as defined in
its scope to the MPLS domain only. This application of ECN in an [RFC3168], [Shayman] limits its scope to the MPLS domain only. This
MPLS domain could make use of the ECN encoding in the MPLS header application of ECN in an MPLS domain could make use of the ECN
that is defined in this document. encoding in the MPLS header that is defined in this document.
9.4. PCN flow admission control and flow termination 9.4. PCN Flow Admission Control and Flow Termination
[I-D.ietf-pcn-architecture] proposes using pre-congestion [PCN] proposes using pre-congestion notification (PCN) on routers
notification (PCN) on routers within an edge-to-edge Diffserv region within an edge-to-edge Diffserv region to control admission of new
to control admission of new flows to the region and, if necessary, to flows to the region and, if necessary, to terminate existing flows in
terminate existing flows in response to disasters and other anomalous response to disasters and other anomalous routing events. In this
routing events. In this approach, the current level of PCN marking approach, the current level of PCN marking is picked up by the
is picked up by the signalling used to initiate each flow in order to signaling used to initiate each flow in order to inform the admission
inform the admission control decision for the whole region at once. control decision for the whole region at once. For example,
For example, extensions to RSVP [I-D.lefaucheur-rsvp-ecn] and NSIS extensions to RSVP [LEFAUCHEUR] and Next Steps in Signaling (NSIS)
[I-D.ietf-nsis-rmd], [I-D.arumaithurai-nsis-pcn] have been proposed. [NSIS], [ARUMAITHURAI] have been proposed.
If LSRs are able to mark packets to signify congestion in MPLS, PCN If LSRs are able to mark packets to signify congestion in MPLS, PCN
marking could be used for admission control and flow termination marking could be used for admission control and flow termination
across a Diffserv region, irrespective of whether it contained pure across a Diffserv region, irrespective of whether it contained pure
IP routers, MPLS LSRs, or both. Indeed, the solution could be IP routers, MPLS LSRs, or both. Indeed, the solution could be
somewhat more efficient to implement if aggregates could identify somewhat more efficient to implement if aggregates could identify
themselves by their MPLS label. Appendix A describes the mechanisms themselves by their MPLS label. Appendix A describes the mechanisms
by which the necessary markings for PCN could be carried in the MPLS by which the necessary markings for PCN could be carried in the MPLS
header. header.
10. IANA Considerations 10. Security Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
We believe no new vulnerabilities are introduced by this draft. We believe no new vulnerabilities are introduced by this document.
We have considered whether malicious sources might be able to exploit We have considered whether malicious sources might be able to exploit
the fact that interior LSRs will mark packets that are Not-ECT, the fact that interior LSRs will mark packets that are Not-ECT,
relying on their egress LSR to drop them. Although this might allow relying on their egress LSR to drop them. Although this might allow
sources to engineer a situation where more traffic is carried across sources to engineer a situation where more traffic is carried across
an MPLS domain than should be, we figured that even if we hadn't an MPLS domain than should be, we figured that even if we hadn't
introduced this feature, these sources would have been able to introduced this feature, these sources would have been able to
prevent these LSRs dropping this traffic anyway, simply by setting prevent these LSRs dropping this traffic anyway, simply by setting
ECT in the first place. ECT in the first place.
An ECN sender can use the ECN nonce [RFC3540] to detect a misbehaving An ECN sender can use the ECN nonce [RFC3540] to detect a misbehaving
receiver. The ECN nonce works correctly across an MPLS domain receiver. The ECN nonce works correctly across an MPLS domain
without requiring any specific support from the proposal in this without requiring any specific support from the proposal in this
draft. The nonce does not need to be present in the MPLS shim document. The nonce does not need to be present in the MPLS shim
header. As long as the nonce is present in the IP header when the header to detect a misbehaving receiver. As long as the nonce is
ECN information is copied from the last MPLS shim header, it will be present in the IP header when the ECN information is copied from the
overwritten if congestion has been experienced by an LSR. This is last MPLS shim header, it will be overwritten if congestion has been
all that is necessary for the sender to detect a misbehaving experienced by an LSR. This is all that is necessary for the sender
receiver. 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 were
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.
12. Acknowledgments 11. Acknowledgments
Thanks to K.K. Ramakrishnan and Sally Floyd for getting us thinking Thanks to K.K. Ramakrishnan and Sally Floyd for getting us thinking
about this in the first place and for providing advice on tunneling about this in the first place and for providing advice on tunneling
of ECN packets, and to Sally Floyd, Joe Babiarz, Ben Niven-Jenkins, of ECN packets, and to Sally Floyd, Joe Babiarz, Ben Niven-Jenkins,
Phil Eardley, Ruediger Geib, and Magnus Westerlund for their comments Phil Eardley, Ruediger Geib, and Magnus Westerlund for their comments
on the draft. on the document.
Appendix A. Extension to Pre-Congestion Notification Appendix A. Extension to Pre-Congestion Notification
This appendix describes how the mechanisms decribed in the body of This appendix describes how the mechanisms described in the body of
the document can be extended to support PCN the document can be extended to support PCN [PCN]. Our intent here
[I-D.ietf-pcn-architecture]. Our intent here is to show that the is to show that the mechanisms are readily extended to more complex
mechanisms are readily extended to more complex scenarios than ECN, scenarios than ECN, particularly in the case where more codepoints
particulary in the case where more codepoints are needed, but this are needed, but this appendix may be safely ignored if one is
appendix may be safely ignored if one is interested only in interested only in supporting ECN. Note that the PCN standards are
supporting ECN. Note that the PCN standards are still very much still very much under development at the time of writing; hence, the
under development at the time of writing, hence the precise details precise details contained in this appendix may be subject to change,
contained in this appendix may be subject to change, and we stress and we stress that this appendix is for illustrative purposes only.
that this appendix is for illustrative purposes only.
The relevant aspects of PCN for the purposes of this discussion are: The relevant aspects of PCN for the purposes of this discussion are:
o PCN uses 3 states rather than 2 for ECN - these are referred to as o PCN uses 3 states rather than 2 for ECN -- these are referred to
admission marked (AM), termination marked (TM) and not marked (NM) as admission marked (AM), termination marked (TM), and not marked
states. (See Section 9.4 for further discussion of PCN and the (NM) states. (See Section 9.4 for further discussion of PCN and
possibility of using fewer codepoints.) the possibility of using fewer codepoints).
o A packet can go from NM to AM, from NM to TM, or from AM to TM, o A packet can go from NM to AM, from NM to TM, or from AM to TM,
but no other transition is possible. but no other transition is possible.
o The determination of whether a packet is subject to PCN is based o The determination of whether a packet is subject to PCN is based
on the PHB of the packet. on the PHB of the packet.
Thus, to support PCN fully in an MPLS domain for a particular PHB, a Thus, to support PCN fully in an MPLS domain for a particular PHB, a
total of 3 codepoints need to be allocated for that PHB. These 3 total of 3 codepoints need to be allocated for that PHB. These 3
codepoints represent the admission marked (AM), termination marked codepoints represent the admission marked (AM), termination marked
(TM) and not marked (NM) states. The procedures described in (TM), and not marked (NM) states. The procedures described in
Section 4 above need to be slightly modified to support this Section 4 above need to be slightly modified to support this
scenario. The following procedures are invoked when the topmost DSCP scenario. The following procedures are invoked when the topmost DSCP
or EXP value indicates a PHB that supports PCN. or EXP value indicates a PHB that supports PCN.
Appendix A.1. Label Push onto IP packet A.1. Label Push onto IP Packet
If the IP packet header indicates AM, set the EXP value of all If the IP packet header indicates AM, set the EXP value of all
entries in the label stack to AM. If the IP packet header indicates entries in the label stack to AM. If the IP packet header indicates
TM, set the EXP value of all entries in the label stack to TM. For TM, set the EXP value of all entries in the label stack to TM. For
any other marking of the IP header, set the EXP value of all entries any other marking of the IP header, set the EXP value of all entries
in the label stack to NM. in the label stack to NM.
Appendix A.2. Pushing Additional MPLS Labels A.2. Pushing Additional MPLS Labels
The procedures of Section 4.2 apply. The procedures of Section 4.2 apply.
Appendix A.3. Admission Control or Flow Termination Marking inside MPLS A.3. Admission Control or Flow Termination Marking Inside MPLS Domain
The EXP value can be set to AM or TM according to the same procedures The EXP value can be set to AM or TM according to the same procedures
as described in [I-D.briscoe-tsvwg-cl-phb]. For the purposes of this as described in [BRISCOE-CL]. For the purposes of this document, it
document, it does not matter exactly what algorithms are used to does not matter exactly which algorithms are used to decide when to
decide when to set AM or TM; all that matters is that if a router set AM or TM; all that matters is that if a router would have marked
would have marked AM (or TM) in the IP header, it should set the EXP AM (or TM) in the IP header, it should set the EXP value in the MPLS
value in the MPLS header to the AM (or TM) codepoint. header to the AM (or TM) codepoint.
Appendix A.4. Popping an MPLS Label (not end of stack) A.4. Popping an MPLS Label (Not End of Stack)
When popping an MPLS Label exposes another MPLS label, the AM or TM When popping an MPLS Label exposes another MPLS label, the AM or TM
marking should be transferred to the exposed EXP field in the marking should be transferred to the exposed EXP field in the
following manner: following manner:
o If the inner EXP value is NM, then it should be set to the same o If the inner EXP value is NM, then it should be set to the same
marking state as the EXP value of the popped label stack entry. marking state as the EXP value of the popped label stack entry.
o If the inner EXP value is AM, it should be unchanged if the popped o If the inner EXP value is AM, it should be unchanged if the popped
EXP value was AM, and it should be set to TM if the popped EXP EXP value was AM, and it should be set to TM if the popped EXP
value was TM. If the popped EXP value was NM, this should be value was TM. If the popped EXP value was NM, this should be
logged in some way and the inner EXP value should be unchanged. logged in some way, and the inner EXP value should be unchanged.
o If the inner EXP value is TM, it should be unchanged whatever the o If the inner EXP value is TM, it should be unchanged whatever the
popped EXP value was, but any EXP value other than TM should be popped EXP value was, but any EXP value other than TM should be
logged. logged.
Appendix A.5. Popping the last MPLS Label to expose IP header A.5. Popping the Last MPLS Label to Expose IP Header
When popping the last MPLS Label exposes the IP header, there are two When popping the last MPLS Label exposes the IP header, there are two
cases to consider: cases to consider:
o the popping LSR is NOT the egress router of the PCN region, in o the popping LSR is *not* the egress router of the PCN region, in
which case AM or TM marking should be transferred to the exposed which case AM or TM marking should be transferred to the exposed
IP header field; or IP header field; or
o the popping LSR IS the egress router of the PCN region. o the popping LSR *is* the egress router of the PCN region.
In the latter case, the behavior of the egress LSR is defined in In the latter case, the behavior of the egress LSR is defined in
[I-D.ietf-pcn-architecture] and is beyond the scope of this document. [PCN] and is beyond the scope of this document. In the former case,
In the former case, the marking should be transferred from the popped the marking should be transferred from the popped MPLS header to the
MPLS header to the exposed IP header as follows: exposed IP header as follows:
o If the inner IP header value is neither AM nor TM, and the EXP o If the inner IP header value is neither AM nor TM, and the EXP
value was NM, then the IP header should be unchanged. For any value was NM, then the IP header should be unchanged. For any
other EXP value, the IP header should be set to the same marking other EXP value, the IP header should be set to the same marking
state as the EXP value of the popped label stack entry. state as the EXP value of the popped label stack entry.
o If the inner IP header value is AM, it should be unchanged if the o If the inner IP header value is AM, it should be unchanged if the
popped EXP value was AM, and it should be set to TM if the popped popped EXP value was AM, and it should be set to TM if the popped
EXP value was TM. If the popped EXP value was NM, this should be EXP value was TM. If the popped EXP value was NM, this should be
logged in some way and the inner IP header value should be logged in some way and the inner IP header value should be
unchanged. unchanged.
o If the IP header value is TM, it should be unchanged whatever the o If the IP header value is TM, it should be unchanged whatever the
13. References Normative References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
Label Switching Architecture", RFC 3031, January 2001. "Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label
Encoding", RFC 3032, January 2001. Stack Encoding", RFC 3032, January 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
of Explicit Congestion Notification (ECN) to IP", Addition of Explicit Congestion Notification (ECN) to
RFC 3168, September 2001. IP", RFC 3168, September 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Vaananen, P., Krishnan, R., Cheval, P., and J.
Protocol Label Switching (MPLS) Support of Differentiated Heinanen, "Multi-Protocol Label Switching (MPLS)
Services", RFC 3270, May 2002. Support of Differentiated Services", RFC 3270,
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
13.2. Informative References Informative References
[Floyd] "A Proposal to Incorporate ECN in MPLS", 1999.
Work in progress. http://www.icir.org/floyd/papers/
draft-ietf-mpls-ecn-00.txt
[I-D.arumaithurai-nsis-pcn] [ARUMAITHURAI] Arumaithurai, M., "NSIS PCN-QoSM: A Quality of
Arumaithurai, M., "NSIS PCN-QoSM: A Quality of Service Service Model for Pre-Congestion Notification (PCN)",
Model for Pre-Congestion Notification (PCN)", Work in Progress, September 2007.
draft-arumaithurai-nsis-pcn-00 (work in progress),
September 2007.
[I-D.briscoe-tsvwg-cl-phb] [BRISCOE-CL] Briscoe, B., "Pre-Congestion Notification Marking",
Briscoe, B., "Pre-Congestion Notification marking", Work in Progress, October 2006.
draft-briscoe-tsvwg-cl-phb-03 (work in progress),
[I-D.briscoe-tsvwg-ecn-tunnel] [BRISCOE-ECN] Briscoe, B., "Layered Encapsulation of Congestion
Briscoe, B., "Layered Encapsulation of Congestion Notification", Work in Progress, July 2007.
Notification", draft-briscoe-tsvwg-ecn-tunnel-00 (work in
progress), July 2007.
[I-D.ietf-nsis-rmd] [Floyd] Ramakrishnan, K., Floyd, S., and B. Davie, "A
Bader, A., "RMD-QOSM - The Resource Management in Diffserv Proposal to Incorporate ECN in MPLS", Work in
QOS Model", draft-ietf-nsis-rmd-11 (work in progress), Progress, June 1999.
[I-D.ietf-pcn-architecture] [LEFAUCHEUR] Faucheur, F., Charny, A., Briscoe, B., Eardley, P.,
Eardley, P., "Pre-Congestion Notification Architecture", Barbiaz, J., and K. Chan, "RSVP Extensions for
draft-ietf-pcn-architecture-00 (work in progress), Admission Control over Diffserv using Pre-congestion
August 2007. Notification (PCN)", Work in Progress, June 2006.
[I-D.ietf-tsvwg-diffserv-class-aggr] [NSIS] Bader, A., Westberg, L., Karagiannis, G., Cornelia,
Chan, K., "Aggregation of DiffServ Service Classes", C., and T. Phelan, "RMD-QOSM - The Resource
draft-ietf-tsvwg-diffserv-class-aggr-04 (work in Management in Diffserv QOS Model", Work in Progress,
progress), August 2007. November 2007.
[I-D.lefaucheur-rsvp-ecn] [PCN] Eardley, P., "Pre-Congestion Notification
Faucheur, F., "RSVP Extensions for Admission Control over Architecture", Work in Progress, November 2007.
Diffserv using Pre-congestion Notification (PCN)",
draft-lefaucheur-rsvp-ecn-01 (work in progress),
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust
Congestion Notification (ECN) Signaling with Nonces", Explicit Congestion Notification (ECN) Signaling with
RFC 3540, June 2003. Nonces", RFC 3540, June 2003.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340,
[Shayman] "Using ECN to Signal Congestion Within an MPLS Domain", [Shayman] Shayman, M. and R. Jaeger, "Using ECN to Signal
2000. Congestion Within an MPLS Domain", Work in Progress,
Work in progress. http://www.ee.umd.edu/~shayman/papers.d/ [TSVWG] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
draft-shayman-mpls-ecn-00.txt DiffServ Service Classes", Work in Progress,
Authors' Addresses Authors' Addresses
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Mass. Ave. 1414 Mass. Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: bsd@cisco.com EMail: bsd@cisco.com
Bob Briscoe Bob Briscoe
B54/77, Sirius House B54/77, Sirius House
Adastral Park Adastral Park
Martlesham Heath Martlesham Heath
Ipswich Ipswich
Suffolk IP5 3RE Suffolk IP5 3RE
Email: bob.briscoe@bt.com EMail: bob.briscoe@bt.com
June Tay June Tay
Email: june.tay@bt.com EMail: june.tay@bt.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at line 907
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.32 (of http://xml.resource.org/) from a source in
RFC-2629 XML format.
End of changes. 128 change blocks.
428 lines changed or deleted
331 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/


text:
import React from 'react';

const imgSrc = require('./images/deploy_dependencies.png');

export default class Slide extends React.Component {
  render() {
    return (

the problem: cross deploy dependencies

    );
  }
}

redpajama_set_name: RedPajamaGithub


text:
var pg = require('./../middleware/pg/install');

exports.actions = function(req, res, ss) {

  req.use('session');

  return {

    init: function () {
      pg.init(function (started) {
        if (started) {
          ss.publish.all('dbStatus', 'success');
        } else {
          ss.publish.all('dbStatus', 'failed');
        }
        return res(started);
      });
    },

    destroy: function () {
      if (ss.env !== 'production') {
        pg.dropEverything(function (success) {
          if (success) {
            ss.publish.all('dbStatus', 'destroyed');
          } else {
            ss.publish.all('dbStatus', 'destroyFailed');
          }
          return res(success);
        });
      }
    },

    checkDb: function () {
      pg.DbCreated(function (success) {
        return res(success);
      });
    }

  };

};


Age is just a number, but, at least for Madonna, it's also an excuse to party. With every passing year, the pop icon's birthday extravaganzas have become increasingly more decadent, and her 59th was no exception. To celebrate her birthday, which is today, August 16, Madonna not only threw yet another blow out, she did made it a destination. Continuing with her theme of jet-set birthday parties — last year's unforgettably went down in Cuba — Madonna headed to Puglia, Italy. Which seems to be the city of the summer, after all.
In typical Madonna birthday fashion, she was joined by equally fabulous company. Madonna rang in her 59th alongside her twins Stella and Esther — who have made adorable cameos on her Instagram as of late — as well as her longtime friends and collaborators Mert Alas and Riccardo Tisci, who has been living his best life in Italy all summer long. "Night of the Gypsies 💃 amazing night last night 💥⚡💥 tonite is the night of the Bday girl @madonna #family #icon," Alas wrote in an Instagram of the host.
Meanwhile Tisci shared a couple of snaps of the evening on his own account, including a photo of himself with the caption "Back to the roots #love #puglia."
He also shared a video of the evening's entertainment: dancing.
That may have been secondary, though, to Madonna herself, who also took the dance floor.
The real highlight of the evening happened even before the dancing, when Madonna arrived. Madonna being Madonna, she didn't just walk into her own party. Instead, she trotted in atop a white horse à la Bianca Jagger. Thankfully, for those who didn't receive an invite, Madonna shared moments from her surreal entrance on Instagram. "Because A Leo...," she cheekily wrote in the caption. Of course, we all already know that Madonna loves horses.
"Likes to make an Entrance!!," she added in the following photo caption.
As for her attire, Madonna opted for a bohemian vibe with a signature top hat and a flowy floral lace dress.
The party wasn't Madonna's first summer trip to Puglia though. The pop artist visited last July for a friend's wedding and, possibly, for the pizza as she posted a photo of herself to Twitter in front of one with the caption, "The Pizza we Ate.....,..........🍕🍕🍕 We love you Puglia❣❣❣Ciao Italia🇮🇹🇮🇹🇮🇹."
Considering she has an even bigger birthday coming up next year — her diamond one — her Puglia party is likely only the warmup.


text:
To continue ensuring that Caltech remains the destination of choice for the brightest and most creative STEM students from all backgrounds, experiences, and viewpoints, the Institute is announcing several updates to its admissions practices.
First, the Institute will extend its moratorium on the requirement of SAT and ACT test scores as part of the undergraduate admissions process for two additional years. This will allow the Institute to continue to assess the value of these metrics in the admissions process and to determine whether standardized test scores are informative of students' long-term success at Caltech. The Institute will not consider those test scores, even if they are submitted.
This decision extends the two-year moratorium announced by the Institute in June 2020 to five years. The original moratorium had been issued in response to the COVID-19 pandemic and its impact on access to standardized exams for students worldwide.
The current decision to extend the testing moratorium to five years is supported by a rigorous internal analysis of the academic performance of the last seven undergraduate first-year cohorts, representing classes that matriculated before and after the moratorium went into effect. The study, conducted by members of the Caltech faculty supported by professional staff, indicates that standardized test scores have little to no power in predicting students' performance in the first-term mathematics and physics classes that first-year students must take as part of Caltech's core curriculum. Further, the predictive power of standardized test scores appears to dissipate as students progress through the first-year core curriculum. The extension will allow for the collection of additional data from students enrolled under the moratorium, including one class that will have graduated from the Institute, and will facilitate a more extensive examination of academic performance and its relationship to standardized test scores.
"A consensus has developed among faculty and professional staff involved in admissions at Caltech. That is, that numerous other key attributes of applications serve as stronger indicators of the potential for student success here," says Jared R. Leadbetter, professor of environmental microbiology and chair of the first-year admissions committee that recommended the extension to the Institute's faculty board and senior leadership.
"The moratorium on our evaluation of standardized test scores has reinforced our intention to read deeply and review all substantive materials provided in applications. It is critical that we reach a deep and broad understanding of applicants, including their STEM interests, aspirations, and potential for continued intellectual growth, should they be admitted to Caltech," he says.
Jarrid Whitney, Caltech's assistant vice president for student affairs, enrollment, and career services, adds that the Institute's adoption of the moratorium was bolstered by practices that were already in place.
"Caltech has a well-established holistic admission process in which all aspects of an applicant's life and experiences are considered when assessing their preparation and potential performance in Caltech's rigorous academic environment. While standardized testing has been an element of the evaluation of applicants, it was never the sole metric or distinguishing factor for admissions," Whitney says. "Additionally, both the original and current moratorium removed standardized testing as a financial and logistical barrier to applying to Caltech."
As a second update, the Institute is adopting a new Restrictive Early Action (REA) model of admissions, effective fall of 2022. REA will replace the Institute's current Early Action program. REA, a model used by other colleges and universities, is a nonbinding option that limits the number of schools to which an applicant may apply during the early period but in return provides a student the opportunity to receive an offer of admission from their first-choice school. Students offered admission to Caltech through this process will not be required to accept immediately. Rather, they can wait until the Regular Decision processes at other colleges have been completed, giving them the opportunity to consider and compare financial aid offers from all schools at one time.
Restrictive Early Action applications will be due November 1; students will be notified of REA admissions decisions (admit, defer, or deny) by mid-December. Admitted students will then have until May 1, 2023, to decide which offer they will accept.
"In the last couple of years, Caltech's applicant pool has more than doubled. However, lowering our admit rate is not a goal for Caltech," says Ashley Pallie, director of undergraduate admissions. "We believe moving to a restrictive early admissions process is responsive to our applicants' desire to identify Caltech as their first choice while still giving them the flexibility to consider all financial aid packages. Additionally, we will reserve most of our admissions offers for Regular Decision, which is when the majority of applicants apply to Caltech."
Students who choose to apply to Caltech REA this fall may not apply Early Action nor Early Decision to any other institution with the following exceptions:
In a third update, Caltech has changed its policy on international students applying for financial aid. International students (defined as students who are non-U.S. citizens or permanent residents attending secondary school outside of the United States) interested in applying for financial aid are now eligible to participate in Caltech's newly announced REA admissions program. Previously, international students in need of financial aid were only allowed to apply for aid during the Regular Decision process.
"Our goal at Caltech is to recruit and enroll the best STEM students from all around the world regardless of their financial circumstances; updating our policy to allow international students who need financial aid to apply during REA allows us to achieve this goal and to work toward more equitable admissions practices," says Pallie.
Caltech has also updated its testing requirements for international applicants. These students may now meet the English proficiency requirement through either the TOEFL, the IELTS, or the Duolingo English Test.
For more information on undergraduate admissions at Caltech, including the Institute's admissions deadlines and a Restrictive Early Action FAQ, visit https://www.admissions.caltech.edu/apply/first-year-freshman-applicants/deadlines.

redpajama_set_name: RedPajamaCommonCrawl


text:
MUH-TAY-ZIK / HOF-FER, San Francisco Advertising Agency
Sunnier Side of the Office – August 6th, 2019
*|MC:SUBJECT|*
"I was terrified that once the original show was over, my career was going to be over. The candle that burns twice as bright only burns half as long. But youth is a funny thing. With age and perspective and hindsight, you have the nostalgia for it all. Coming back to it now is actually a lot of fun." - Jason Priestley
Convenience and the climate crisis
By: Ben Thomas
We live in a time where we've been trained to expect convenience. We have most things we could ever want at our fingertips – from clothes to groceries, transport to food.
But convenience comes with consequence.
The race for ever-faster deliveries creates a huge carbon footprint, ride-sharing can actually add to traffic congestion, and the convenience of grocery shopping has led to a mindless waste mentality. If studies and science are anything to go by, we're at a tipping point. Behavior needs to change before there's no turning back. It's an alarming idea that's making its way to the mainstream, and forward-thinking brands and services are innovating to meet demand for more sustainable convenience.
For example, Returnr, an Australian start-up, wants to do away with plastic take away packaging by allowing people to borrow and return or buy and reuse tin containers from their favorite restaurants. Further up the food cycle, restaurants like Nolla in Helsinki are taking strides to reduce their waste to close to zero at every point of the journey, from supplier to plate.
It's a collective effort. And it's not easy. But by making it easier for people, brands and services can call themselves part of the solution to a problem that has become a crisis.
Instagram Updates: Goodbye to Influencers
By: Ben Evangelista
Rumors have been swirling for the past few weeks that Instagram is planning on rolling out a new wave of updates, testing a feature that would hide the number of likes on users' photos. A trial run is currently underway in Australia -- hiding the official count of likes on each photo visible to the public. While users can still see the number of likes on the back-end, their total will be invisible to everyone else.
Instagram officials say they're hoping to reduce the pressure around posting content, encouraging people to "focus on sharing things [they] love." Analytic tools for businesses will still be available on the back-end, however, and brands will still be able to measure engagement.
What feels like a simple way to rid Instagram of some of its toxic traits is seen as a death threat to many influencers. The universe of "public" figures that has evolved in the past 10 years is very highly measured on numbers- likes, comments, subscriptions. For an App at the forefront of this market to get rid of their main metric is a challenge to "their career."
While influencers are worried about this change, a large part of the applications' users are excited by the idea of returning to Insgratam's initial foundations, getting back to the basics and sharing photos with friends. While the trial is not set to go into permanent effect anytime soon, the initial roll-out is shedding public light on many negative side effects that have evolved with the application's rise in popularity.
Facebook Rumored to Launch TV Streaming Device
By: Arthi Veeraragavan
Last week reports surfaced that Facebook was getting ready to release a TV streaming device by the end of 2019. Reports state the social network has met with top streaming providers including Netflix, Hulu, and Amazon about including their apps on the device.
The streaming device may build off of Facebook's video-chat product, Portal, as rumors show Facebook is working on a "camera that can plug into a TV and double as a video-streaming device a la Roku or Fire TV."
Facebook has not confirmed the rumors.
A streaming offering could provide marketers with another way to reach their target audience as well as the ability to drive cross-exposure between streaming TV and social media. We expect to hear more about this new device in the trades very soon.
Hillary Swank was fired from the original Beverly Hills 90210. She's gone on to win two Oscars.
BH90210 premiers this Wednesday, August 7th on Fox.
Copyright © 2019 M/H VCCP, All rights reserved.
220 Sansome Street, 15th Floor
This email was sent to *|EMAIL|*
*|LIST:ADDRESSLINE|*
*|REWARDS|*
220 Sansome St.
Privacy Policy © 2020 MTZHF


Why did they make the rule that the ball has to leave the penalty area on a free kick or the kick has to be retaken?
In the same way as for a goal kick and it has been that way for a very long time. Some thought that the rule only applied to goal kicks.
The principle behind it in my opinion was to clear players out of a congested area. The lawmakers knew that once players grouped in numbers in an area that it had the potential to cause problem for the game.
Somewhat the same on a throw in where the law tries to keep players a distance away from the throw.
Looking at the minutes of the IFAB meetings around the time this was introduced, it seems to me that the reason was to prevent the ball being passed directly to the goalkeeper who would then pick the ball up (there was no 'back-pass rule' at the time) and kick it downfield.