draft-ietf-mpls-ecmp-bcp-01.txt   draft-ietf-mpls-ecmp-bcp-02.txt 
Network Working Group George Swallow Network Working Group George Swallow
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Category: Standards Track Category: Standards Track
Expiration Date: January 2006 Expiration Date: March 2006
Stewart Bryant Stewart Bryant
Cisco Systems, Inc. Cisco Systems, Inc.
Loa Andersson Loa Andersson
Acreo Acreo
July 2005 September 2005
Avoiding Equal Cost Multipath Treatment in MPLS Networks Avoiding Equal Cost Multipath Treatment in MPLS Networks
draft-ietf-mpls-ecmp-bcp-01.txt draft-ietf-mpls-ecmp-bcp-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.
This document is an Internet-Draft and is in full conformance with Internet-Drafts are working documents of the Internet Engineering
all provisions of Section 5 of RFC3667. Internet-Drafts are working Task Force (IETF), its areas, and its working groups. Note that
documents of the Internet Engineering Task Force (IETF), its areas, other groups may also distribute working documents as Internet-
and its working groups. Note that other groups may also distribute Drafts.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
This document describes the Equal Cost Multipath (ECMP) behavior This document describes the Equal Cost Multipath (ECMP) behavior
of currently deployed MPLS networks and makes best practice of currently deployed MPLS networks and 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 and wishes to avoid such treatment. MPLS network and wishes to avoid such treatment.
Contents Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
1.1 Terminology ............................................... 3 1.1 Terminology ............................................... 3
2 Current EMCP Practices .................................... 3 2 Current ECMP Practices .................................... 3
3 Recommendations for Avoiding ECMP Treatment ............... 5 3 Recommendations for Avoiding ECMP Treatment ............... 5
4 Security Considerations ................................... 6 4 Security Considerations ................................... 6
5 References ................................................ 6 5 References ................................................ 6
5.1 Normative References ...................................... 6 5.1 Normative References ...................................... 6
6 Authors' Addresses ........................................ 6 6 Authors' Addresses ........................................ 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 and makes best practice recommenda- currently deployed MPLS networks and makes best practice recommenda-
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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 stack of an MPLS packet label stack of an MPLS packet
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
2. Current EMCP 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 Identi-
fier. Instead the payload of an MPLS packet is identified by the fier. Instead the payload of an MPLS packet is identified by the
Forwarding Equivalence Class (FEC) of the bottom most label. Thus it Forwarding Equivalence Class (FEC) of the bottom most label. Thus it
is not possible to know the payload type if one does not know the is not possible to know the payload type if one does not know the
label binding for the bottom most label. Since an LSR which is pro- label binding for the bottom most label. Since an LSR which is pro-
cessing a label stack need only know the binding for the label(s) it cessing a label stack need only know the binding for the label(s) it
must process, it is very often the case that LSRs along an LSP are must process, it is very often the case that LSRs along an LSP are
unable to determine the payload type of the carried contents. unable to determine the payload type of the carried contents.
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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 which correctly identify a payload as
not being IP, may still need to load-share this traffic across multi- not being IP, most often will load-share traffic across multiple
ple equal-cost paths. In this case a LABEL ECMP algorithm is equal-cost paths based on the label stack. Any reserved label, no
employed, where a hash is computed on all or part(s) of the label matter where it is located in the stack, may be included in the com-
stack. Any reserved label, no matter where it is located in the putation for load balancing. Modification of the label stack between
stack, may be included in the computation for load balancing. Modi- packets of a single flow could result in re-ordering that flow. That
fication of the label stack between packets of a single flow could is, were an explicit null or a router-alert label to be added to a
result in re-ordering that flow. That is, were an explicit null or a packet, that packet could take a different path through the network.
router-alert label to be 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 where the payload behind the top label
is a packet belonging to an MPLS IPv4 VPN. Here the real payload is is a packet belonging to an MPLS IPv4 VPN. Here the real payload is
IP and most (if not all) deployed equipment will locate the end of IP and most (if not all) deployed equipment will locate the end of
the label stack and correctly perform IP ECMP. 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 per-
formed. For example if an ethernet frame immediately follows the formed. 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 not do ECMP on IPv6, then either the first
nibble will be 0x4 or it will be something else. If the nibble is nibble will be 0x4 or it will be something else. If the nibble is
not 0x4 then no IP ECMP is performed, but Label ECMP may be per- not 0x4 then no IP ECMP is performed, but Label ECMP may be per-
formed. If it is 0x4, then the constant values of the MAC addresses formed. If it is 0x4, then the constant values of the MAC addresses
overlay the fields that would be occupied by the source and destina- overlay the fields that would be occupied by the source and destina-
tion addresses of an IP header. tion addresses of an IP header.
3. Recommendations for Avoiding ECMP Treatment 3. Recommendations for Avoiding ECMP Treatment
The field in the figure below tagged "Application Label" is a label We will use the term "Application Label" to refer to a label that has
of the FEC Type used/defined by the application. It is the bottom been allocated with a FEC Type that is defined (or simply used) by an
most label in the label stack. As such its FEC Type defines the pay- application. Such labels necessarily appear at the bottom of the
load which follows. Anyone defining an application to be transported label stack, that is, below labels associated with transporting the
over MPLS is free to define new FEC Types and the format of the pay- packet across an MPLS network. The FEC Type of the Application label
load which will be carried. defines the payload that follows. Anyone defining an application to
be transported over MPLS is free to define new FEC Types and the for-
mat of the payload which 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 | MPLS | Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . . . . . .
. . . . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |0| TTL | Label | Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Label | Exp |1| TTL | Stack | Application Label | Exp |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1st Nbl| | Payload |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 applica-
tion take precautions to not be mistaken as IP by deployed equipment tion take precautions to not be mistaken as IP by deployed equipment
that snoops on the presumed location of the IP Version field. Thus, that snoops on the presumed location of the IP Version field. Thus,
at a minimum, the chosen format must disallow the values 0x4 and 0x6 at a minimum, the chosen format must disallow the values 0x4 and 0x6
in the first nibble of their payload. in the first nibble of their payload.
It is strongly recommended, however, that applications restrict the It is strongly recommended, however, that applications restrict the
first nibble values to 0x0 and 0x1. This will ensure that that their first nibble values to 0x0 and 0x1. This will ensure that that their
skipping to change at page 7, line 7 skipping to change at page 7, line 7
Email: swallow@cisco.com Email: swallow@cisco.com
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Expiration Date Expiration Date
January 2006 March 2006
Disclaimer of Validity Disclaimer of Validity
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 15 change blocks. 
30 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/