draft-ietf-mpls-ecmp-bcp-03.txt | rfc4928.txt | |||
---|---|---|---|---|
Network Working Group George Swallow | Network Working Group G. Swallow | |||
Internet Draft Cisco Systems, Inc. | Request for Comments: 4928 S. Bryant | |||
Category: Standards Track | BCP: 128 Cisco Systems, Inc. | |||
Expiration Date: August 2007 | Category: Best Current Practice L. Andersson | |||
Stewart Bryant | Acreo AB | |||
Cisco Systems, Inc. | ||||
Loa Andersson | ||||
Acreo | ||||
February 2007 | ||||
Avoiding Equal Cost Multipath Treatment in MPLS Networks | Avoiding Equal Cost Multipath Treatment in MPLS Networks | |||
draft-ietf-mpls-ecmp-bcp-03.txt | Status of This Memo | |||
Status of this Memo | ||||
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. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document specifies an Internet Best Current Practices for the | |||
and may be updated, replaced, or obsoleted by other documents at any | Internet Community, and requests discussion and suggestions for | |||
time. It is inappropriate to use Internet-Drafts as reference | improvements. Distribution of this memo is unlimited. | |||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | Copyright Notice | |||
http://www.ietf.org/1id-abstracts.html | ||||
The list of Internet-Draft Shadow Directories can be accessed at | Copyright (C) The IETF Trust (2007). | |||
http://www.ietf.org/shadow.html | ||||
Abstract | Abstract | |||
This document describes the Equal Cost Multipath (ECMP) behavior of | This document describes the Equal Cost Multipath (ECMP) behavior of | |||
currently deployed MPLS networks. This document makes best practice | currently deployed MPLS networks. This document makes best practice | |||
recommendations for anyone defining an application to run over an | recommendations for anyone defining an application to run over an | |||
MPLS network that wishes to avoid the reordering that can result from | MPLS network that wishes to avoid the reordering that can result from | |||
transmission of different packets from the same flow over multiple | transmission of different packets from the same flow over multiple | |||
different equal cost paths. | different equal cost paths. These recommendations rely on inspection | |||
of the IP version number field in packets. Despite the heuristic | ||||
nature of the recommendations, they provide a relatively safe way to | ||||
operate MPLS networks, even if future allocations of IP version | ||||
numbers were made for some purpose. | ||||
Contents | Table of Contents | |||
1 Introduction .............................................. 3 | 1. Introduction ....................................................2 | |||
1.1 Terminology ............................................... 3 | 1.1. Terminology ................................................2 | |||
2 Current ECMP Practices .................................... 3 | 2. Current ECMP Practices ..........................................2 | |||
3 Recommendations for Avoiding ECMP Treatment ............... 5 | 3. Recommendations for Avoiding ECMP Treatment .....................4 | |||
4 Security Considerations ................................... 6 | 4. Security Considerations .........................................5 | |||
5 References ................................................ 6 | 5. IANA Considerations .............................................5 | |||
5.1 Normative References ...................................... 6 | 6. References ......................................................6 | |||
5.2 Informative References .................................... 7 | 6.1. Normative References .......................................6 | |||
6 Authors' Addresses ........................................ 8 | 6.2. Informative References .....................................6 | |||
1. Introduction | 1. Introduction | |||
This document describes the Equal Cost Multipath (ECMP) behavior of | This document describes the Equal Cost Multipath (ECMP) behavior of | |||
currently deployed MPLS networks. We discuss cases where multiple | currently deployed MPLS networks. We discuss cases where multiple | |||
packets from the same top-level LSP might be transmitted over differ- | packets from the same top-level LSP might be transmitted over | |||
ent equal cost paths, resulting in possible mis-ordering of packets | different equal cost paths, resulting in possible mis-ordering of | |||
which are part of the same top-level LSP. This document also makes | packets that are part of the same top-level LSP. This document also | |||
best practice recommendations for anyone defining an application to | makes best practice recommendations for anyone defining an | |||
run over an MPLS network that wishes to avoid the resulting potential | application to run over an MPLS network that wishes to avoid the | |||
for mis-ordered packets. While disabling ECMP behavior is an option | resulting potential for mis-ordered packets. While disabling ECMP | |||
open to most operators, few (if any) have chosen to do so, and the | behavior is an option open to most operators, few (if any) have | |||
application designer does not have control over the behavior of the | chosen to do so, and the application designer does not have control | |||
networks that the application may run over. Thus ECMP behavior is a | over the behavior of the networks that the application may run over. | |||
reality that must be reckoned with. | Thus, ECMP behavior is a reality that must be reckoned with. | |||
1.1. Terminology | 1.1. Terminology | |||
ECMP Equal Cost Multipath | ECMP Equal Cost Multipath | |||
FEC Forwarding Equivalence Class | FEC Forwarding Equivalence Class | |||
IP ECMP A forwarding behavior in which the selection of the | IP ECMP A forwarding behavior in which the selection of the | |||
next-hop between equal cost routes is based on the | next-hop between equal cost routes is based on the | |||
header(s) of an IP packet | header(s) of an IP packet | |||
Label ECMP A forwarding behavior in which the selection of the | Label ECMP A forwarding behavior in which the selection of the | |||
next-hop between equal cost routes is based on the | next-hop between equal cost routes is based on the label | |||
label stack of an MPLS packet | stack of an MPLS packet | |||
LSP Label Switched Path | LSP Label Switched Path | |||
LSR Label Switching Router | LSR Label Switching Router | |||
2. Current ECMP Practices | 2. Current ECMP Practices | |||
The MPLS label stack and Forwarding Equivalence Classes are defined | The MPLS label stack and Forwarding Equivalence Classes are defined | |||
in [RFC3031]. The MPLS label stack does not carry a Protocol Identi- | in [RFC3031]. The MPLS label stack does not carry a Protocol | |||
fier. Instead the payload of an MPLS packet is identified by the | Identifier. Instead the payload of an MPLS packet is identified by | |||
Forwarding Equivalence Class (FEC) of the bottom most label. Thus it | the Forwarding Equivalence Class (FEC) of the bottom most label. | |||
is not possible to know the payload type if one does not know the | Thus, it is not possible to know the payload type if one does not | |||
label binding for the bottom most label. Since an LSR which is pro- | know the label binding for the bottom most label. Since an LSR, | |||
cessing a label stack need only know the binding for the label(s) it | which is processing a label stack, need only know the binding for the | |||
must process, it is very often the case that LSRs along an LSP are | label(s) it must process, it is very often the case that LSRs along | |||
unable to determine the payload type of the carried contents. | an LSP are unable to determine the payload type of the carried | |||
contents. | ||||
As a means of potentially reducing delay and congestion, IP networks | As a means of potentially reducing delay and congestion, IP networks | |||
have taken advantage of multiple paths through a network by splitting | have taken advantage of multiple paths through a network by splitting | |||
traffic flows across those paths. The general name for this practice | traffic flows across those paths. The general name for this practice | |||
is Equal Cost Multipath or ECMP. In general this is done by hashing | is Equal Cost Multipath or ECMP. In general, this is done by hashing | |||
on various fields on the IP or contained headers. In practice, | on various fields on the IP or contained headers. In practice, | |||
within a network core, the hashing is based mainly or exclusively on | within a network core, the hashing is based mainly or exclusively on | |||
the IP source and destination addresses. The reason for splitting | the IP source and destination addresses. The reason for splitting | |||
aggregated flows in this manner is to minimize the re-ordering of | aggregated flows in this manner is to minimize the re-ordering of | |||
packets belonging to individual flows contained within the aggregated | packets belonging to individual flows contained within the aggregated | |||
flow. Within this document we use the term IP ECMP for this type of | flow. Within this document, we use the term IP ECMP for this type of | |||
forwarding algorithm. | forwarding algorithm. | |||
For packets that contain both a label stack and an encapsulated IPv4 | For packets that contain both a label stack and an encapsulated IPv4 | |||
(or IPv6) packet, current implementations in some cases may hash on | (or IPv6) packet, current implementations in some cases may hash on | |||
any combination of labels and IPv4 (or IPv6) source and destination | any combination of labels and IPv4 (or IPv6) source and destination | |||
labels. | addresses. | |||
In the early days of MPLS, the payload was almost exclusively IP. | In the early days of MPLS, the payload was almost exclusively IP. | |||
Even today the overwhelming majority of carried traffic remains IP. | Even today the overwhelming majority of carried traffic remains IP. | |||
Providers of MPLS equipment sought to continue this IP ECMP behavior. | Providers of MPLS equipment sought to continue this IP ECMP behavior. | |||
As shown above, it is not possible to know whether the payload of an | As shown above, it is not possible to know whether the payload of an | |||
MPLS packet is IP at every place where IP ECMP needs to be performed. | MPLS packet is IP at every place where IP ECMP needs to be performed. | |||
Thus vendors have taken the liberty of guessing what the payload is. | Thus vendors have taken the liberty of guessing the payload. By | |||
By inspecting the first nibble beyond the label stack, existing | inspecting the first nibble beyond the label stack, existing | |||
equipment infers that a packet is not IPv4 or IPv6 if the value of | equipment infers that a packet is not IPv4 or IPv6 if the value of | |||
the nibble (where the IP version number would be found) is not 0x4 or | the nibble (where the IP version number would be found) is not 0x4 or | |||
0x6 respectively. Most deployed LSRs will treat a packet whose first | 0x6 respectively. Most deployed LSRs will treat a packet whose first | |||
nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP | nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP | |||
ECMP. | ECMP. | |||
A consequence of this is that any application which defines a FEC | A consequence of this is that any application that defines an FEC | |||
which does not take measures to prevent the values 0x4 and 0x6 from | that does not take measures to prevent the values 0x4 and 0x6 from | |||
occurring in the first nibble of the payload may be subject to IP | occurring in the first nibble of the payload may be subject to IP | |||
ECMP and thus having their flows take multiple paths and arriving | ECMP and thus having their flows take multiple paths and arriving | |||
with considerable jitter and possibly out of order. While none of | with considerable jitter and possibly out of order. While none of | |||
this is in violation of the basic service offering of IP, it is | this is in violation of the basic service offering of IP, it is | |||
detrimental to the performance of various classes of applications. | detrimental to the performance of various classes of applications. | |||
It also complicates the measurement, monitoring and tracing of those | It also complicates the measurement, monitoring, and tracing of those | |||
flows. | flows. | |||
New MPLS payload types are emerging such as those specified by the | New MPLS payload types are emerging, such as those specified by the | |||
IETF PWE3 and AVT working groups. These payloads are not IP and, if | IETF PWE3 and AVT working groups. These payloads are not IP and, if | |||
specified without constraint might be mistaken for IP. | specified without constraint, might be mistaken for IP. | |||
It must also be noted that LSRs which correctly identify a payload as | It must also be noted that LSRs that correctly identify a payload as | |||
not being IP, most often will load-share traffic across multiple | not being IP most often will load-share traffic across multiple | |||
equal-cost paths based on the label stack. Any reserved label, no | equal-cost paths based on the label stack. Any reserved label, no | |||
matter where it is located in the stack, may be included in the com- | matter where it is located in the stack, may be included in the | |||
putation for load balancing. Modification of the label stack between | computation for load balancing. Modification of the label stack | |||
packets of a single flow could result in re-ordering that flow. That | between packets of a single flow could result in re-ordering that | |||
is, were an explicit null or a router-alert label to be added to a | flow. That is, were an explicit null or a router-alert label to be | |||
packet, that packet could take a different path through the network. | added to a packet, that packet could take a different path through | |||
the network. | ||||
Note that for some applications, being mistaken for IPv4 may not be | Note that for some applications, being mistaken for IPv4 may not be | |||
detrimental. The trivial case where the payload behind the top label | detrimental. The trivial case being where the payload behind the top | |||
is a packet belonging to an MPLS IPv4 VPN. Here the real payload is | label is a packet belonging to an MPLS IPv4 VPN. Here the real | |||
IP and most (if not all) deployed equipment will locate the end of | payload is IP and most (if not all) deployed equipment will locate | |||
the label stack and correctly perform IP ECMP. | the end of the label stack and correctly perform IP ECMP. | |||
A less obvious case is when the packets of a given flow happen to | A less obvious case is when the packets of a given flow happen to | |||
have constant values in the fields upon which IP ECMP would be per- | have constant values in the fields upon which IP ECMP would be | |||
formed. For example if an ethernet frame immediately follows the | performed. For example, if an Ethernet frame immediately follows the | |||
label and the LSR does not do ECMP on IPv6, then either the first | label and the LSR does ECMP on IPv4, but does not do ECMP on IPv6, | |||
nibble will be 0x4 or it will be something else. If the nibble is | then either the first nibble will be 0x4, or it will be something | |||
not 0x4 then no IP ECMP is performed, but Label ECMP may be per- | else. If the nibble is not 0x4 then no IP ECMP is performed, but | |||
formed. If it is 0x4, then the constant values of the MAC addresses | Label ECMP may be performed. If it is 0x4, then the constant values | |||
overlay the fields that would have been occupied by the source and | of the MAC addresses overlay the fields that would have been occupied | |||
destination addresses of an IP header. As a result the ECMP algo- | by the source and destination addresses of an IP header. In this | |||
rithm would be feed a constant value and thus would always return the | case, the input to the ECMP algorithm would be a constant value and | |||
same result. | thus the algorithm would always return the same result. | |||
3. Recommendations for Avoiding ECMP Treatment | 3. Recommendations for Avoiding ECMP Treatment | |||
We will use the term "Application Label" to refer to a label that has | We will use the term "Application Label" to refer to a label that has | |||
been allocated with a FEC Type that is defined (or simply used) by an | been allocated with an FEC Type that is defined (or simply used) by | |||
application. Such labels necessarily appear at the bottom of the | an application. Such labels necessarily appear at the bottom of the | |||
label stack, that is, below labels associated with transporting the | label stack, that is, below labels associated with transporting the | |||
packet across an MPLS network. The FEC Type of the Application label | packet across an MPLS network. The FEC Type of the Application label | |||
defines the payload that follows. Anyone defining an application to | defines the payload that follows. Anyone defining an application to | |||
be transported over MPLS is free to define new FEC Types and the for- | be transported over MPLS is free to define new FEC Types and the | |||
mat of the payload which will be carried. | format of the payload that will be carried. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label | Exp |0| TTL | | | Label | Exp |0| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
. . . . . | . . . . . | |||
. . . . . | . . . . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label | Exp |0| TTL | | | Label | Exp |0| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Application Label | Exp |1| TTL | | | Application Label | Exp |1| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|1st Nbl| | | |1st Nbl| | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
In order to avoid IP ECMP treatment it is necessary that an applica- | In order to avoid IP ECMP treatment, it is necessary that an | |||
tion take precautions to not be mistaken as IP by deployed equipment | application take precautions to not be mistaken as IP by deployed | |||
that snoops on the presumed location of the IP Version field. Thus, | equipment that snoops on the presumed location of the IP Version | |||
at a minimum, the chosen format must disallow the values 0x4 and 0x6 | field. Thus, at a minimum, the chosen format must disallow the | |||
in the first nibble of their payload. | values 0x4 and 0x6 in the first nibble of their payload. | |||
It is strongly recommended, however, that applications restrict the | It is REQUIRED, however, that applications depend upon in-order | |||
first nibble values to 0x0 and 0x1. This will ensure that that their | packet delivery restrict the first nibble values to 0x0 and 0x1. | |||
traffic flows will not be affected if some future routing equipment | This will ensure that their traffic flows will not be affected if | |||
does similar snooping on some future version of IP. | some future routing equipment does similar snooping on some future | |||
version(s) of IP. | ||||
This behavior implies that if in the future an IP version is defined | ||||
with a version number of 0x0 or 0x1, then equipment complying with | ||||
this BCP would be unable to look past one or more MPLS headers, and | ||||
loadsplit traffic from a single LSP across multiple paths based on a | ||||
hash of specific fields in the IPv0 or IPv1 headers. That is, IP | ||||
traffic employing these version numbers would be safe from | ||||
disturbances caused by inappropriate loadsplitting, but would also | ||||
not be able to get the performance benefits. | ||||
For an example of how ECMP is avoided in Pseudowires, see [RFC4385]. | For an example of how ECMP is avoided in Pseudowires, see [RFC4385]. | |||
4. Security Considerations | 4. Security Considerations | |||
This memo discusses the conditions under which MPLS traffic associ- | This memo discusses the conditions under which MPLS traffic | |||
ated with a single top-level LSP either does or does not have the | associated with a single top-level LSP either does or does not have | |||
possibility of being split between multiple paths, implying the pos- | the possibility of being split between multiple paths, implying the | |||
sibility of mis-ordering between packets belonging to the same top- | possibility of mis-ordering between packets belonging to the same | |||
level LSP. From a security point of view, the worse that could result | top-level LSP. From a security point of view, the worse that could | |||
from a security breach of the mechanisms described here would be mis- | result from a security breach of the mechanisms described here would | |||
ordering of packets, and possible corresponding loss of throughput | be mis-ordering of packets, and possible corresponding loss of | |||
(for example, TCP connections may in some cases reduce the window | throughput (for example, TCP connections may in some cases reduce the | |||
size in response to mis-ordered packets). However, in order to create | window size in response to mis-ordered packets). However, in order | |||
even this limited result, a hacker would need to either change the | to create even this limited result, an attacker would need to either | |||
configuration or implementation of a router, or change the bits on | change the configuration or implementation of a router, or change the | |||
the wire as transmitted in a packet. | bits on the wire as transmitted in a packet. | |||
Other security issues in the deployment of MPLS are outside of the | Other security issues in the deployment of MPLS are outside the scope | |||
scope of this document, but are discussed in other MPLS specifica- | of this document, but are discussed in other MPLS specifications, | |||
tions such as RFCs 3031, 3036, 3107, 3209, 3478, 3479, 4206, 4220, | such as [RFC3031], [RFC3036], [RFC3107], [RFC3209], [RFC3478], | |||
4221, 4378, AND 4379. | [RFC3479], [RFC4206], [RFC4220], [RFC4221], [RFC4378], AND [RFC4379]. | |||
5. References | 5. IANA Considerations | |||
5.1. Normative References | IANA has marked the value 0x1 in the IP protocol version number space | |||
as "Reserved" and placed a reference to this document to both values | ||||
0x0 and 0x1. | ||||
[RFC3031] Rosen, E. et al., "Multiprotocol Label Switching | Note that this document does not in any way change the policies | |||
Architecture", RFC 3031, January 2001. | regarding the allocation of version numbers, including the possible | |||
use of the reserved numbers for some future purpose. | ||||
5.2. Informative References | 6. References | |||
[RFC3036] Andersson, L., et. al., "LDP Specification", RFC 3036, | 6.1. Normative References | |||
January 2001. | ||||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | ||||
Label Switching Architecture", RFC 3031, January 2001. | ||||
6.2. Informative References | ||||
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and | ||||
B. Thomas, "LDP Specification", RFC 3036, January 2001. | ||||
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in | [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in | |||
BGP-4", RFC 3107, May 2001. | BGP-4", RFC 3107, May 2001. | |||
[RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
LSP Tunnels", RFC 3209, December 2001. | and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | |||
Tunnels", RFC 3209, December 2001. | ||||
[RFC3478] Leelanivas, M., et. al., "Graceful Restart Mechanism for | [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful | |||
Label Distribution Protocol", RFC 3478, February 2003. | Restart Mechanism for Label Distribution Protocol", RFC | |||
3478, February 2003. | ||||
[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution | [RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label | |||
Protocol (LDP)", RFC 3479, February 2003. | Distribution Protocol (LDP)", RFC 3479, February 2003. | |||
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) | [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) | |||
Hierarchy with Generalized Multi-Protocol Label Switching | Hierarchy with Generalized Multi-Protocol Label Switching | |||
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. | (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. | |||
[RFC4220] Dubuc, M., et. al., "Traffic Engineering Link Management | [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering | |||
Information Base", RFC 4220, November 2005. | Link Management Information Base", RFC 4220, November | |||
2005. | ||||
[RFC4221] Nadeau, T., et. al., "Multiprotocol Label Switching (MPLS) | [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol | |||
Management Overview", RFC 4221, November 2005. | Label Switching (MPLS) Management Overview", RFC 4221, | |||
November 2005. | ||||
[RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol | [RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for | |||
Label Switching (MPLS) Operations and Management (OAM)", | Multi-Protocol Label Switching (MPLS) Operations and | |||
RFC 4378, February 2006. | Management (OAM)", RFC 4378, February 2006. | |||
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol | [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol | |||
Label Switched (MPLS) Data Plane Failures", RFC 4379, | Label Switched (MPLS) Data Plane Failures", RFC 4379, | |||
February 2006. | February 2006. | |||
[RFC4385] Bryant, S., et. al., "Pseudowire Emulation Edge-to-Edge | [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, | |||
(PWE3) Control Word for Use over an MPLS PSN", RFC 4385, | "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for | |||
February 2006. | Use over an MPLS PSN", RFC 4385, February 2006. | |||
6. Authors' Addresses | Authors' Addresses | |||
Loa Andersson | Loa Andersson | |||
Acreo | Acreo AB | |||
Electrum 236 | ||||
SE-146 40 Kista | ||||
Sweden | ||||
Email: loa@pi.se | EMail: loa@pi.se | |||
Stewart Bryant | Stewart Bryant | |||
Cisco Systems | Cisco Systems | |||
250, Longwater, | 250, Longwater, | |||
Green Park, | Green Park, | |||
Reading, RG2 6GB, UK | Reading, RG2 6GB, UK | |||
Email: stbryant@cisco.com | EMail: stbryant@cisco.com | |||
George Swallow | George Swallow | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
1414 Massachusetts Ave | 1414 Massachusetts Ave | |||
Boxborough, MA 01719 | Boxborough, MA 01719 | |||
Email: swallow@cisco.com | EMail: swallow@cisco.com | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2007). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | Intellectual Property | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any assur- | Copies of IPR disclosures made to the IETF Secretariat and any | |||
ances of licenses to be made available, or the result of an attempt | assurances of licenses to be made available, or the result of an | |||
made to obtain a general license or permission for the use of such | attempt made to obtain a general license or permission for the use of | |||
proprietary rights by implementers or users of this specification can | such proprietary rights by implementers or users of this | |||
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 ietf- | this standard. Please address the information to the IETF at | |||
ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Full Copyright Notice | ||||
Copyright (C) The IETF Trust (2007). This document is subject to the | Acknowledgement | |||
rights, licenses and restrictions contained in BCP 78, and except as | ||||
set forth therein, the authors retain all their rights. | ||||
This document and the information contained herein are provided on an | Funding for the RFC Editor function is currently provided by the | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | Internet Society. | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
End of changes. 50 change blocks. | ||||
164 lines changed or deleted | 187 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |