draft-ietf-tsvwg-ecn-mpls-01.txt   draft-ietf-tsvwg-ecn-mpls-02.txt 
Network Working Group B. Davie Network Working Group B. Davie
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track B. Briscoe Intended status: Standards Track B. Briscoe
Expires: December 21, 2007 J. Tay Expires: April 6, 2008 J. Tay
BT Research BT Research
June 19, 2007 October 4, 2007
Explicit Congestion Marking in MPLS Explicit Congestion Marking in MPLS
draft-ietf-tsvwg-ecn-mpls-01.txt draft-ietf-tsvwg-ecn-mpls-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2007. This Internet-Draft will expire on April 6, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Change History Change History
[Note to RFC Editor: This section to be removed before publication] [Note to RFC Editor: This section to be removed before publication]
Changes in this version (draft-ietf-tsvwg-ecn-mpls-01.txt) relative Changes in this version (draft-ietf-tsvwg-ecn-mpls-02.txt) relative
to the last (draft-ietf-tsvwg-ecn-mpls-00.txt): 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- o Moved the detailed discussion of marking procedures for Pre-
Congestion Notification (PCN) to an appendix. Congestion Notification (PCN) to an appendix.
o Removed PCN as a motivation for the efficient code-point usage in o Removed PCN as a motivation for the efficient code-point usage in
Section 2. Section 2.
o Clarified the rationale for preferring the ECT-checking approach o Clarified the rationale for preferring the ECT-checking approach
over the approach of [Floyd] in Section 9.1. over the approach of [Floyd] in Section 8.1.
o Updated discussion of relationship to RFC3168 in Section 7 o Updated discussion of relationship to RFC3168 in Section 7
o Removed discussion of re-ECN from Security Considerations. o Removed discussion of re-ECN from Security Considerations.
o Fixed typos and nits. o Fixed typos and nits.
Changes in draft-ietf-tsvwg-ecn-mpls-00.txt relative to Changes in draft-ietf-tsvwg-ecn-mpls-00.txt relative to
draft-davie-ecn-mpls-00: draft-davie-ecn-mpls-00:
skipping to change at page 3, line 12 skipping to change at page 4, line 7
cross from an ECN-enabled domain to a domain that is not ECN- cross from an ECN-enabled domain to a domain that is not ECN-
enabled. enabled.
o Clarified that copying MPLS ECN or PCN marking into exposed IP o Clarified that copying MPLS ECN or PCN marking into exposed IP
header on egress is not mandatory header on egress is not mandatory
o Fixed typos and nits o Fixed typos and nits
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 6 2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 7
3. Per-domain ECT checking . . . . . . . . . . . . . . . . . . . 8 3. Per-domain ECT checking . . . . . . . . . . . . . . . . . . . 9
4. ECN-enabled MPLS domain . . . . . . . . . . . . . . . . . . . 8 4. ECN-enabled MPLS domain . . . . . . . . . . . . . . . . . . . 9
4.1. Pushing (adding) one or more labels to an IP packet . . . 9 4.1. Pushing (adding) one or more labels to an IP packet . . . 10
4.2. Pushing one or more labels onto an MPLS labelled packet . 9 4.2. Pushing one or more labels onto an MPLS labelled packet . 10
4.3. Congestion experienced in an interior MPLS node . . . . . 9 4.3. Congestion experienced in an interior MPLS node . . . . . 10
4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 9 4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 10
4.5. Popping an MPLS label (not the end of the stack) . . . . . 10 4.5. Popping an MPLS label (not the end of the stack) . . . . . 11
4.6. Popping the last MPLS label in the stack . . . . . . . . . 10 4.6. Popping the last MPLS label in the stack . . . . . . . . . 11
4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 10 4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 11
5. ECN-disabled MPLS domain . . . . . . . . . . . . . . . . . . . 11 5. ECN-disabled MPLS domain . . . . . . . . . . . . . . . . . . . 12
6. The use of more codepoints with E-LSPs and L-LSPs . . . . . . 11 6. The use of more codepoints with E-LSPs and L-LSPs . . . . . . 12
7. Relationship to tunnel behavior in RFC 3168 . . . . . . . . . 11 7. Relationship to tunnel behavior in RFC 3168 . . . . . . . . . 12
8. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 13
8.1. RFC3168-style ECN . . . . . . . . . . . . . . . . . . . . 12 8.1. Marking non-ECN Capable Packets . . . . . . . . . . . . . 13
8.2. ECN Co-existence with Diffserv E-LSPs . . . . . . . . . . 12 8.2. Non-ECN capable routers in an MPLS Domain . . . . . . . . 14
8.3. Congestion-feedback-based Traffic Engineering . . . . . . 13 9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.4. PCN flow admission control and flow pre-emption . . . . . 13 9.1. RFC3168-style ECN . . . . . . . . . . . . . . . . . . . . 14
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 9.2. ECN Co-existence with Diffserv E-LSPs . . . . . . . . . . 15
9.1. Marking non-ECN Capable Packets . . . . . . . . . . . . . 14 9.3. Congestion-feedback-based Traffic Engineering . . . . . . 15
9.2. Non-ECN capable routers in an MPLS Domain . . . . . . . . 15 9.4. PCN flow admission control and flow termination . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Extension to Pre-Congestion Notification . . . . . . 16 Appendix A. Extension to Pre-Congestion Notification . . . . . . 17
Appendix A.1. Label Push onto IP packet . . . . . . . . . . . . . 17 Appendix A.1. Label Push onto IP packet . . . . . . . . . . . . . 18
Appendix A.2. Pushing Additional MPLS Labels . . . . . . . . . . . 17 Appendix A.2. Pushing Additional MPLS Labels . . . . . . . . . . . 18
Appendix A.3. Admission Control or Pre-emption Marking inside Appendix A.3. Admission Control or Flow Termination Marking
MPLS domain . . . . . . . . . . . . . . . . . . . . 17 inside MPLS domain . . . . . . . . . . . . . . . . . 18
Appendix A.4. Popping an MPLS Label (not end of stack) . . . . . . 17 Appendix A.4. Popping an MPLS Label (not end of stack) . . . . . . 18
Appendix A.5. Popping the last MPLS Label to expose IP header . . 18 Appendix A.5. Popping the last MPLS Label to expose IP header . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22 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 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
skipping to change at page 4, line 27 skipping to change at page 5, line 27
how Explicit Congestion Notification (ECN) marking might be encoded how Explicit Congestion Notification (ECN) marking might be encoded
in the MPLS header. in the MPLS header.
This draft defines how an operator might define some of the EXP This draft 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 pre-emption [I-D.briscoe-tsvwg-cl-architecture], control and flow termination [I-D.ietf-pcn-architecture], there is
there is consequent interest in being able to support ECN across IP consequent interest in being able to support ECN across IP networks
networks consisting of MPLS-enabled domains. Therefore it is consisting of MPLS-enabled domains. Therefore it is necessary to
necessary to specify the protocol for including ECN in the MPLS shim specify the protocol for including ECN in the MPLS shim header, and
header, and the protocol behavior of edge MPLS nodes. the protocol behavior 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 drafts
[Floyd] [Shayman] and we draw on those efforts in this draft as well. [Floyd] [Shayman] and we draw on those efforts in this draft as well.
skipping to change at page 5, line 16 skipping to change at page 6, line 16
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 notification
must be copied into the IP header for onward transmission. This must be copied into the IP header for onward transmission. This
draft aims to be generic for any use of congestion notification in draft aims to be generic for any use of congestion notification in
MPLS. Support of [RFC3168] is our primary motivation; some MPLS. Support of [RFC3168] is our primary motivation; some
additional potential applications to illustrate the flexibility of additional potential applications to illustrate the flexibility of
our approach are described in Section 8. In particular, we aim to our approach are described in Section 9. In particular, we aim to
support possible future schemes that may use more than one level of support possible future schemes that may use more than one level of
congestion marking. 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:
skipping to change at page 6, line 38 skipping to change at page 7, line 38
approach is used, then codepoint space in the EXP field is likely to approach is used, then codepoint space in the EXP field is likely to
be scarce. This draft focuses on interworking ECN marking with the be scarce. This draft 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 8.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 meaning not congestion marked (Not-CM), and at least one
other codepoint will be defined meaning congestion marked (CM). other codepoint will be defined meaning congestion marked (CM).
Therefore, each PHB that uses ECN marking will consume at least two Therefore, each PHB that uses ECN marking will consume at least two
EXP codepoints. But PHBs that do not use ECN marking will only EXP codepoints. 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
skipping to change at page 8, line 6 skipping to change at page 9, line 6
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 9.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
skipping to change at page 11, line 31 skipping to change at page 12, line 31
[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 8 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
NOT cause packets from the same microflow but with different ECN
markings to be sent on different LSPs. As discussed in [RFC3270],
packets of a single microflow should always travel on the same LSP to
avoid possible misordering. Thus, ECN marking of packets on L-LSPs
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.
The behavior that is specified in Section 4 of this document The behavior that is specified in Section 4 of this document
resembles the "full functionality" mode in the sense that it conveys resembles the "full functionality" mode in the sense that it conveys
some information from inner to outer header, and in the sense that it some information from inner to outer header, and in the sense that it
enables full ECN support along the MPLS LSP (which is analogous to an enables full ECN support along the MPLS LSP (which is analogous to an
IP tunnel in this context). However it differs in one respect, which IP tunnel in this context). However it differs in one respect, which
is that the CE information is conveyed from the inner header to the is that the CE information is conveyed from the inner header to the
outer header. Our original reason for this different design choice outer header. Our original reason for this different design choice
was to give interior routers and LSRs more information about upstream was to give interior routers and LSRs more information about upstream
marking in multi-bottleneck cases. For instance, the flow pre- marking in multi-bottleneck cases. For instance, the flow
emption marking mechanism proposed for PCN works by only considering termination marking mechanism proposed for PCN works by only
packets for marking that have not already been marked upstream. considering packets for marking that have not already been marked
Unless existing pre-emption marking is copied from the inner to the upstream. Unless existing flow termination marking is copied from
outer header at tunnel ingress, the mechanism doesn't pre-empt enough the inner to the outer header at tunnel ingress, the mechanism
traffic in cases where anomalous events hit multiple domains at once. doesn't terminate enough traffic in cases where anomalous events hit
[RFC3168] does not give any reasons against conveying CE information multiple domains at once. [RFC3168] does not give any reasons
from the inner header to the outer in the "full functionality" mode. against conveying CE information from the inner header to the outer
Furthermore, [RFC4301] specifies that the ECN marking should be in the "full functionality" mode. Furthermore, [RFC4301] specifies
copied from inner header to outer header in IPSEC tunnels, consistent that the ECN marking should be copied from inner header to outer
with the approach defined here. [Briscoe] discusses this issue in header in IPSEC tunnels, consistent with the approach defined here.
more detail. In summary, the approach described in Section 4 appears [I-D.briscoe-tsvwg-ecn-tunnel] discusses this issue in more detail.
to be both a sound technical choice and consistent with the current In summary, the approach described in Section 4 appears to be both a
state of thinking in the IETF. sound technical choice and consistent with the current state of
thinking in the IETF.
8. Example Uses
8.1. RFC3168-style ECN
[RFC3168] proposes the use of ECN in TCP and introduces the use of
ECN-Echo and CWR flags in the TCP header for initialization. The TCP
sender responds accordingly (such as not increasing the congestion
window) when it receives an ECN-Echo (ECE) ACK packet (that is, an
ACK packet with ECN-Echo flag set in the TCP header), then the sender
knows that congestion was 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
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
congestion control in transports capable of understanding ECN would
be able to respond to approaching congestion on LSRs without having
to rely on packet discard to signal congestion.
8.2. ECN Co-existence with Diffserv E-LSPs
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,
and hence there remain available codepoints in the EXP space. If an
operator wished to support ECN for single PHB, this can be
accomplished by simply allocated a second codepoint to the PHB for
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
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
example, an operator might use ECN on a premium data service but not
on a PHB used for best effort internet traffic.
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
service classes proposed in [I-D.ietf-tsvwg-diffserv-class-aggr]. He
may choose to support ECN only for the Assured Elastic Treatment
Aggregate, using the EXP codepoint 010 for the not-CM state and 011
for the CM state. All other codepoints could be the same as in
[I-D.ietf-tsvwg-diffserv-class-aggr]. Of course any other
combination of EXP values can be used according to the specific set
of PHBs and marking conventions used within that operator's network.
8.3. Congestion-feedback-based Traffic Engineering
Shayman's traffic engineering [Shayman] proposed the use of ECN by an
egress LSR feeding back congestion to an ingress LSR to mitigate
congestion by employing dynamic traffic engineering techniques such
as shifting flows to an alternate path. It proposed a new RSVP
TUNNEL CONGESTION message which was sent to the ingress LSR and
ignored by transit LSRs.
8.4. PCN flow admission control and flow pre-emption
[I-D.briscoe-tsvwg-cl-architecture] proposes using pre-congestion
notification (PCN) on routers within an edge-to-edge Diffserv region
to control admission of new flows to the region and, if necessary, to
pre-empt existing flows in response to disasters and other anomalous
routing events. In this approach, the current level of PCN marking
is picked up by the signalling used to initiate each flow in order to
inform the admission control decision for the whole region at once.
As an example, a minor extension to RSVP signalling has been proposed
[I-D.lefaucheur-rsvp-ecn] to carry this message, but a similar
approach has also been proposed that uses NSIS signalling
[I-D.ietf-nsis-rmd].
If it is possible for LSRs to signify congestion in MPLS, PCN marking
could be used for admission control and flow pre-emption across a
Diffserv region, irrespective of whether it contained pure IP
routers, MPLS LSRs, or both. Indeed, the solution could be somewhat
more efficient to implement if aggregates could identify themselves
by their MPLS label. Appendix A describes the mechanisms by which
the necessary markings for PCN could be carried in the MPLS header.
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
service classes proposed in [I-D.ietf-tsvwg-diffserv-class-aggr]. He
may choose to support PCN only for the Real Time Treatment Aggregate,
using the EXP codepoint 100 for the not-marked (NM) state, 101 for
the Admission Marked (AM) state, and 111 for the Pre-emption Marked
(PM) state. All other codepoints could be the same as in
[I-D.ietf-tsvwg-diffserv-class-aggr]. Of course any other
combination of EXP values can be used according to the specific set
of PHBs and marking conventions used within that operator's network.
It might also be possible to deploy a similar solution using PCN
marking over MPLS for just admission control alone, or just flow pre-
emption alone, particularly if codepoint space was at a premium in
the MPLS EXP field. However, the feasibility of deploying one
without the other would require further study. We also note that an
approach to deploying PCN using only a single marking codepoint to
support both pre-emption and admission control has been
proposed[I-D.charny-pcn-single-marking].
9. Deployment Considerations 8. Deployment Considerations
9.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. Downstream
congested LSRs might forward packets already marked, even though they congested LSRs 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
skipping to change at page 15, line 19 skipping to change at page 14, line 28
smaller still if ECN deployment widened. smaller 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.
9.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.1. RFC3168-style ECN
[RFC3168] proposes the use of ECN in TCP and introduces the use of
ECN-Echo and CWR flags in the TCP header for initialization. The TCP
sender responds accordingly (such as not increasing the congestion
window) when it receives an ECN-Echo (ECE) ACK packet (that is, an
ACK packet with ECN-Echo flag set in the TCP header), then the sender
knows that congestion was 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
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
congestion control in transports capable of understanding ECN would
be able to respond to approaching congestion on LSRs without having
to rely on packet discard to signal congestion.
9.2. ECN Co-existence with Diffserv E-LSPs
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,
and hence there remain available codepoints in the EXP space. If an
operator wished to support ECN for single PHB, this can be
accomplished by simply allocated a second codepoint to the PHB for
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
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
example, an operator might use ECN on a premium data service but not
on a PHB used for best effort internet traffic.
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
service classes proposed in [I-D.ietf-tsvwg-diffserv-class-aggr]. He
may choose to support ECN only for the Assured Elastic Treatment
Aggregate, using the EXP codepoint 010 for the not-CM state and 011
for the CM state. All other codepoints could be the same as in
[I-D.ietf-tsvwg-diffserv-class-aggr]. Of course any other
combination of EXP values can be used according to the specific set
of PHBs and marking conventions used within that operator's network.
9.3. Congestion-feedback-based Traffic Engineering
Shayman's traffic engineering [Shayman] presents another example
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
to mitigate congestion by employing dynamic traffic engineering
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
LSR (and ignored by transit LSRs) to indicate congestion along the
path. Thus, rather than providing the same style of congestion
notification to endpoints as defined in [RFC3168], [Shayman] limits
its scope to the MPLS domain only. This application of ECN in an
MPLS domain could make use of the ECN encoding in the MPLS header
that is defined in this document.
9.4. PCN flow admission control and flow termination
[I-D.ietf-pcn-architecture] proposes using pre-congestion
notification (PCN) on routers within an edge-to-edge Diffserv region
to control admission of new flows to the region and, if necessary, to
terminate existing flows in response to disasters and other anomalous
routing events. In this approach, the current level of PCN marking
is picked up by the signalling used to initiate each flow in order to
inform the admission control decision for the whole region at once.
For example, extensions to RSVP [I-D.lefaucheur-rsvp-ecn] and NSIS
[I-D.ietf-nsis-rmd], [I-D.arumaithurai-nsis-pcn] have been proposed.
If LSRs are able to mark packets to signify congestion in MPLS, PCN
marking could be used for admission control and flow termination
across a Diffserv region, irrespective of whether it contained pure
IP routers, MPLS LSRs, or both. Indeed, the solution could be
somewhat more efficient to implement if aggregates could identify
themselves by their MPLS label. Appendix A describes the mechanisms
by which the necessary markings for PCN could be carried in the MPLS
header.
10. IANA Considerations 10. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
11. Security Considerations 11. Security Considerations
We believe no new vulnerabilities are introduced by this draft. We believe no new vulnerabilities are introduced by this draft.
skipping to change at page 16, line 31 skipping to change at page 17, line 24
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 draft.
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 decribed in the body of
the document can be extended to support PCN the document can be extended to support PCN
[I-D.briscoe-tsvwg-cl-architecture]. Our intent here is to show that [I-D.ietf-pcn-architecture]. Our intent here is to show that the
the mechanisms are readily extended to more complex scenarios than mechanisms are readily extended to more complex scenarios than ECN,
ECN, particulary in the case where more codepoints are needed, but particulary in the case where more codepoints are needed, but this
this appendix may be safely ignored if one is interested only in appendix may be safely ignored if one is interested only in
supporting ECN. Note that the PCN standards are still very much supporting ECN. Note that the PCN standards are still very much
under development at the time of writing, hence the precise details under development at the time of writing, hence the precise details
contained in this appendix may be subject to change, and we stress contained in this appendix may be subject to change, 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 as
admission marked (AM), pre-emption marked (PM) and not marked (NM) admission marked (AM), termination marked (TM) and not marked (NM)
states. (See Section 8.4 for further discussion of PCN and the states. (See Section 9.4 for further discussion of PCN and the
possibility of using fewer codepoints.) possibility of using fewer codepoints.)
o A packet can go from NM to AM, from NM to PM, or from AM to PM, 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), pre-emption marked codepoints represent the admission marked (AM), termination marked
(PM) 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 Appendix 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
PM, set the EXP value of all entries in the label stack to PM. 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 Appendix 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 Pre-emption Marking inside MPLS Appendix A.3. Admission Control or Flow Termination Marking inside MPLS
domain domain
The EXP value can be set to AM or PM 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 [I-D.briscoe-tsvwg-cl-phb]. For the purposes of this
document, it does not matter exactly what algorithms are used to document, it does not matter exactly what algorithms are used to
decide when to set AM or PM; all that matters is that if a router decide when to set AM or TM; all that matters is that if a router
would have marked AM (or PM) in the IP header, it should set the EXP would have marked AM (or TM) in the IP header, it should set the EXP
value in the MPLS header to the AM (or PM) codepoint. value in the MPLS header to the AM (or TM) codepoint.
Appendix A.4. Popping an MPLS Label (not end of stack) Appendix A.4. Popping an MPLS Label (not end of stack)
When popping an MPLS Label exposes another MPLS label, the AM or PM 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 PM if the popped EXP EXP value was AM, and it should be set to TM if the popped EXP
value was PM. 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 PM, 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 PM 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 Appendix 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 PM 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.briscoe-tsvwg-cl-architecture] and is beyond the scope of this [I-D.ietf-pcn-architecture] and is beyond the scope of this document.
document. In the former case, the marking should be transferred from In the former case, the marking should be transferred from the popped
the popped MPLS header to the exposed IP header as follows: MPLS header to the exposed IP header as follows:
o If the inner IP header value is neither AM nor PM, 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 PM if the popped popped EXP value was AM, and it should be set to TM if the popped
EXP value was PM. 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 PM, it should be unchanged whatever the o If the IP header value is TM, it should be unchanged whatever the
popped EXP value was, but any EXP value other than PM should be popped EXP value was, but any EXP value other than TM should be
logged. logged.
13. References 13. References
13.1. 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, "Multiprotocol
skipping to change at page 19, line 20 skipping to change at page 20, line 16
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[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 13.2. Informative References
[Briscoe] "Layered Encapsulation of Congestion Notification",
June 2007.
Work in progress.
[Floyd] "A Proposal to Incorporate ECN in MPLS", 1999. [Floyd] "A Proposal to Incorporate ECN in MPLS", 1999.
Work in progress. http://www.icir.org/floyd/papers/ Work in progress. http://www.icir.org/floyd/papers/
draft-ietf-mpls-ecn-00.txt draft-ietf-mpls-ecn-00.txt
[I-D.briscoe-tsvwg-cl-architecture] [I-D.arumaithurai-nsis-pcn]
Briscoe, B., "An edge-to-edge Deployment Model for Pre- Arumaithurai, M., "NSIS PCN-QoSM: A Quality of Service
Congestion Notification: Admission Control over a Model for Pre-Congestion Notification (PCN)",
DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 draft-arumaithurai-nsis-pcn-00 (work in progress),
(work in progress), October 2006. September 2007.
[I-D.briscoe-tsvwg-cl-phb] [I-D.briscoe-tsvwg-cl-phb]
Briscoe, B., "Pre-Congestion Notification marking", Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress), draft-briscoe-tsvwg-cl-phb-03 (work in progress),
October 2006. October 2006.
[I-D.charny-pcn-single-marking] [I-D.briscoe-tsvwg-ecn-tunnel]
Charny, A., "Pre-Congestion Notification Using Single Briscoe, B., "Layered Encapsulation of Congestion
Marking for Admission and Pre-emption", Notification", draft-briscoe-tsvwg-ecn-tunnel-00 (work in
draft-charny-pcn-single-marking-01 (work in progress), progress), July 2007.
March 2007.
[I-D.ietf-nsis-rmd] [I-D.ietf-nsis-rmd]
Bader, A., "RMD-QOSM - The Resource Management in Diffserv Bader, A., "RMD-QOSM - The Resource Management in Diffserv
QOS Model", draft-ietf-nsis-rmd-09 (work in progress), QOS Model", draft-ietf-nsis-rmd-11 (work in progress),
March 2007. August 2007.
[I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification Architecture",
draft-ietf-pcn-architecture-00 (work in progress),
August 2007.
[I-D.ietf-tsvwg-diffserv-class-aggr] [I-D.ietf-tsvwg-diffserv-class-aggr]
Chan, K., "Aggregation of DiffServ Service Classes", Chan, K., "Aggregation of DiffServ Service Classes",
draft-ietf-tsvwg-diffserv-class-aggr-02 (work in draft-ietf-tsvwg-diffserv-class-aggr-04 (work in
progress), March 2007. progress), August 2007.
[I-D.lefaucheur-rsvp-ecn] [I-D.lefaucheur-rsvp-ecn]
Faucheur, F., "RSVP Extensions for Admission Control over Faucheur, F., "RSVP Extensions for Admission Control over
Diffserv using Pre-congestion Notification (PCN)", Diffserv using Pre-congestion Notification (PCN)",
draft-lefaucheur-rsvp-ecn-01 (work in progress), draft-lefaucheur-rsvp-ecn-01 (work in progress),
June 2006. June 2006.
[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.
skipping to change at page 22, line 45 skipping to change at page 23, line 45
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.
Acknowledgment Acknowledgments
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). 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. 41 change blocks. 
216 lines changed or deleted 221 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/