draft-ietf-mpls-multipath-use-01.txt   draft-ietf-mpls-multipath-use-02.txt 
MPLS C. Villamizar, Ed. MPLS C. Villamizar, Ed.
Internet-Draft Outer Cape Cod Network Internet-Draft Outer Cape Cod Network
Intended status: Informational Consulting Intended status: Informational Consulting
Expires: March 15, 2014 September 11, 2013 Expires: April 12, 2014 October 9, 2013
Use of Multipath with MPLS-TP and MPLS Use of Multipath with MPLS and MPLS-TP
draft-ietf-mpls-multipath-use-01 draft-ietf-mpls-multipath-use-02
Abstract Abstract
Many MPLS implementations have supported multipath techniques and Many MPLS implementations have supported multipath techniques and
many MPLS deployments have used multipath techniques, particularly in many MPLS deployments have used multipath techniques, particularly in
very high bandwidth applications, such as provider IP/MPLS core very high bandwidth applications, such as provider IP/MPLS core
networks. MPLS-TP has strongly discouraged the use of multipath networks. MPLS-TP has strongly discouraged the use of multipath
techniques. Some degradation of MPLS-TP OAM performance cannot be techniques. Some degradation of MPLS-TP OAM performance cannot be
avoided when operating over many types of multipath implementations. avoided when operating over many types of multipath implementations.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 15, 2014. This Internet-Draft will expire on April 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . . 5 3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . . 5
3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . . 6 3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . . 5
3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 7 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 6
4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . . 10 4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Today the requirement to handle large aggregations of traffic, can be Today the requirement to handle large aggregations of traffic, can be
handled by a number of techniques which we will collectively call met by a number of techniques which we will collectively call
multipath. Multipath applied to parallel links between the same set multipath. Multipath applied to parallel links between the same set
of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link
bundling [RFC4201], or other aggregation techniques some of which may bundling [RFC4201], or other aggregation techniques some of which
be vendor specific. Multipath applied to diverse paths rather than could be vendor specific. Multipath applied to diverse paths rather
parallel links includes Equal Cost MultiPath (ECMP) as applied to than parallel links includes Equal Cost MultiPath (ECMP) as applied
OSPF, ISIS, or BGP, and equal cost LSPs. Some vendors support load to OSPF, ISIS, or BGP, and equal cost LSPs. Some vendors support
split across equal cost MPLS LSPs where the load is split load split across equal cost MPLS LSPs where the load is split
proportionally to the reserved bandwidth of the set of LSPs. proportionally to the reserved bandwidth of the set of LSPs.
RFC 5654 requirement 33 requires the capability to carry a client RFC 5654 requirement 33 requires the capability to carry a client
MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654].
This is possible in all cases with one exception. When an MPLS LSP This is possible in all cases with one exception. When an MPLS LSP
exceeds the capacity of any single component link it may be carried exceeds the capacity of any single component link it MAY be carried
by a network using multipath techniques, but may not be carried by a by a network using multipath techniques, but MAY NOT be carried by a
single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation
imposed by MPLS-TP OAM fate sharing constraints and MPLS-TP LM OAM imposed by MPLS-TP OAM fate sharing constraints and MPLS-TP LM OAM
packet ordering constraints (see Section 3.1). packet ordering constraints (see Section 3.1).
The term composite link is more general than terms such as link The term composite link is more general than terms such as link
aggregation (which is specific to Ethernet) or ECMP (which implies aggregation (which is specific to Ethernet) or ECMP (which implies
equal cost paths within a routing protocol). The use of the term equal cost paths within a routing protocol). The use of the term
composite link here is consistent with the broad definition in composite link here is consistent with the broad definition in
[ITU-T.G.800]. Multipath is very similar to composite link as [ITU-T.G.800]. Multipath is very similar to composite link as
defined by ITU, but specifically excludes inverse multiplexing. defined by ITU-T, but specifically excludes inverse multiplexing.
2. Definitions 2. Definitions
Multipath Please refer to the terminology related to multipath introduced in
The term multipath includes all techniques in which [I-D.ietf-rtgwg-cl-requirement]. The following additional terms are
used in this document with related terms grouped together.
1. Traffic can take more than one path from one node to a
destination.
2. Individual packets take one path only. Packets are not
subdivided and reassembled at the receiving end.
3. Packets are not resequenced at the receiving end.
4. The paths may be:
a. parallel links between two nodes, or
b. may be specific paths across a network to a destination
node, or
c. may be links or paths to an intermediate node used to
reach a common destination.
Link Bundle Link Bundle
Link bundling is a multipath technique specific to MPLS Link bundling is a multipath technique specific to MPLS
[RFC4201]. Link bundling supports two modes of operations. [RFC4201]. Link bundling supports two modes of operations.
Either an LSP can be placed on one component link of a link Either an LSP can be placed on one component link of a link
bundle, or an LSP can be load split across all members of the bundle, or an LSP can be load split across all members of the
bundle. There is no signaling defined which allows a per LSP bundle. There is no signaling defined which allows a per LSP
preference regarding load split, therefore whether to load split preference regarding load split, therefore whether to load split
is generally configured per bundle and applied to all LSPs across is generally configured per bundle and applied to all LSPs across
the bundle. the bundle.
Link Aggregation All-Ones Component
The term "link aggregation" generally refers to Ethernet Link Within the context of link bundling, [RFC4201] defines a special
Aggregation [IEEE-802.1AX] as defined by the IEEE. Ethernet Link case where the same label is to be valid across all component
Aggregation defines a Link Aggregation Control Protocol (LACP) links. This case is indicated in signaling by a bit value of
which coordinates inclusion of LAG members in the LAG. "all ones" when identifying a component link. Following the
publication of RFC4201, for brevity this special case has been
Link Aggregation Group (LAG) referred to as the "all-ones component".
A group of physical Ethernet interfaces that are treated as a
logical link when using Ethernet Link Aggregation is referred to
as a Link Aggregation Group (LAG).
Equal Cost Multipath (ECMP) Equal Cost Multipath (ECMP)
Equal Cost Multipath (ECMP) is a specific form of multipath in Equal Cost Multipath (ECMP) is a specific form of multipath in
which the costs of the links or paths must be equal in a given which the costs of the links or paths must be equal in a given
routing protocol. The load may be split equally across all routing protocol. The load may be split equally across all
available links (or available paths), or the load may be split available links (or available paths), or the load may be split
proportionally to the capacity of each link (or path). proportionally to the capacity of each link (or path).
Loop Free Alternate Paths Loop Free Alternate Paths
"Loop-free alternate paths" (LFA) are defined in RFC 5714, "Loop-free alternate paths" (LFA) are defined in RFC 5714,
skipping to change at page 5, line 5 skipping to change at page 4, line 33
direct neighbor of the router adjacent to the failure has a path direct neighbor of the router adjacent to the failure has a path
to the destination that can be guaranteed not to traverse the to the destination that can be guaranteed not to traverse the
failure." Further detail can be found in [RFC5286]. LFA as failure." Further detail can be found in [RFC5286]. LFA as
defined for IPFRR can be used to load balance by relaxing the defined for IPFRR can be used to load balance by relaxing the
equal cost criteria of ECMP, though IPFRR defined LFA for use in equal cost criteria of ECMP, though IPFRR defined LFA for use in
selecting protection paths. When used with IP, proportional selecting protection paths. When used with IP, proportional
split is generally not used. LFA use in load balancing is split is generally not used. LFA use in load balancing is
implemented by some vendors though it may be rare or non-existent implemented by some vendors though it may be rare or non-existent
in deployments. in deployments.
Composite Link Link Aggregation
The term Composite Link had been a registered trademark of Avici The term "link aggregation" generally refers to Ethernet Link
Systems, but was abandoned in 2007. The term composite link is Aggregation [IEEE-802.1AX] as defined by the IEEE. Ethernet Link
now defined by the ITU in [ITU-T.G.800]. The ITU definition Aggregation defines a Link Aggregation Control Protocol (LACP)
includes multipath as defined here, plus inverse multiplexing which coordinates inclusion of LAG members in the LAG.
which is explicitly excluded from the definition of multipath.
Inverse Multiplexing
Inverse multiplexing either transmits whole packets and
resequences the packets at the receiving end or subdivides
packets and reassembles the packets at the receiving end.
Inverse multiplexing requires that all packets be handled by a
common egress packet processing element and is therefore not
useful for very high bandwidth applications.
Component Link Link Aggregation Group (LAG)
The ITU definition of composite link in [ITU-T.G.800] and the A group of physical Ethernet interfaces that are treated as a
IETF definition of link bundling in [RFC4201] both refer to an logical link when using Ethernet Link Aggregation is referred to
individual link in the composite link or link bundle as a as a Link Aggregation Group (LAG).
component link. The term component link is applicable to all
multipath.
LAG Member LAG Member
Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to
an individual link in a LAG as a LAG member. A LAG member is a an individual link in a LAG as a LAG member. A LAG member is a
component link. An Ethernet LAG is a composite link. IEEE does component link. An Ethernet LAG is a composite link. IEEE does
not use the terms composite link or component link. not use the terms composite link or component link.
load split
Load split, load balance, or load distribution refers to
subdividing traffic over a set of component links such that load
is fairly evenly distributed over the set of component links and
certain packet ordering requirements are met. Some existing
techniques better acheive these objectives than others.
A small set of requirements are discussed. These requirements make A small set of requirements are discussed. These requirements make
use of keywords such as MUST and SHOULD as described in [RFC2119]. use of keywords such as MUST and SHOULD as described in [RFC2119].
3. MPLS as a Server Layer for MPLS-TP 3. MPLS as a Server Layer for MPLS-TP
An MPLS LSP may be used as a server layer for MPLS-TP LSPs as long as An MPLS LSP may be used as a server layer for MPLS-TP LSPs as long as
all MPLS-TP requirements are met. Section 3.1 reviews the basis for all MPLS-TP requirements are met. Section 3.1 reviews the basis for
requirements of a server layer that supports MPLS-TP as a client requirements of a server layer that supports MPLS-TP as a client
layer. Key requirements include OAM "fate-sharing" the the layer. Key requirements include OAM "fate-sharing", and the
requirement that packets within an MPLS-TP LSP are not reordered, requirement that packets within an MPLS-TP LSP are not reordered,
including both payload and OAM packets. Section 3.2 discusses including both payload and OAM packets. Section 3.2 discusses
implied requirements where MPLS is the server layer for MPLS-TP implied requirements where MPLS is the server layer for MPLS-TP
client LSPs, and describes a set of solutions using existing MPLS client LSPs, and describes a set of solutions using existing MPLS
mechanisms. mechanisms.
3.1. MPLS-TP Forwarding and Server Layer Requirements 3.1. MPLS-TP Forwarding and Server Layer Requirements
[RFC5960] defines the date plane requirements for MPLS-TP. Two very [RFC5960] defines the date plane requirements for MPLS-TP. Two very
relevant paragraphs in "Section 3.1.1 LSP Packet Encapsulation and relevant paragraphs in "Section 3.1.1 LSP Packet Encapsulation and
skipping to change at page 8, line 5 skipping to change at page 7, line 12
server layer where the MPLS LSPs are making use of multipath, server layer where the MPLS LSPs are making use of multipath,
requires special treatment of the MPLS-TP LSPs such that those LSPs requires special treatment of the MPLS-TP LSPs such that those LSPs
meet MPLS-TP forwarding requirements (see Section 3.1). This implies meet MPLS-TP forwarding requirements (see Section 3.1). This implies
the following brief set of requirements. the following brief set of requirements.
MP#1 It MUST be possible for a midpoint MPLS-TP LSR which is serving MP#1 It MUST be possible for a midpoint MPLS-TP LSR which is serving
as ingress to a server layer MPLS LSP to identify MPLS-TP LSPs, as ingress to a server layer MPLS LSP to identify MPLS-TP LSPs,
so that MPLS-TP forwarding requirements can be applied, or to so that MPLS-TP forwarding requirements can be applied, or to
otherwise accommodate the MPLS-TP forwarding requirements. otherwise accommodate the MPLS-TP forwarding requirements.
MP#2 It SHOULD be possible to completely exclude MPLS-TP LSPs from MP#2 The ability to completely exclude MPLS-TP LSPs from the
the multipath hash and load split. If the selected component multipath hash and load split SHOULD be supported. If the
link no longer meets requirements, an LSP is considered down selected component link no longer meets requirements, an LSP is
which may trigger protection and/or may require that the considered down which may trigger protection and/or may require
ingress LSR select a new path and signal a new LSP. that the ingress LSR select a new path and signal a new LSP.
MP#3 It SHOULD be possible to insure that MPLS-TP LSPs will not be MP#3 It SHOULD be possible to insure that MPLS-TP LSPs will not be
moved to another component link as a result of a composite link moved to another component link as a result of a composite link
load rebalancing operation. If the selected component link no load rebalancing operation. If the selected component link no
longer meets requirements, another component link may be longer meets requirements, another component link may be
selected, however a change in path should not occur solely for selected, however a change in path should not occur solely for
load balancing. load balancing.
MP#4 Where an RSVP-TE control plane is used, it MUST be possible for MP#4 Where an RSVP-TE control plane is used, it MUST be possible for
an ingress LSR which is setting up an MPLS-TP or an MPLS LSP to an ingress LSR which is setting up an MPLS-TP or an MPLS LSP to
determine at path selection time whether a link or Forwarding determine at path selection time whether a link or Forwarding
Adjacency (FA, see [RFC4206]) within the topology can support Adjacency (FA, see [RFC4206]) within the topology can support
the MPLS-TP requirements of the LSP. the MPLS-TP requirements of the LSP.
The reason for requirement MP#1 may not be obvious. A MPLS-TP LSP The reason for requirement MP#1 may not be obvious. A MPLS-TP LSP
may be aggregated along with other client LSP by a midpoint LSR into may be aggregated along with other client LSPs by a midpoint LSR into
a very large MPLS server layer LSP, as would be the case in a core a very large MPLS server layer LSP, as would be the case in a core
node to core node MPLS LSP between major cities. In this case the node to core node MPLS LSP between major cities. In this case the
ingress of the MPLS LSP cannot through any existing signaling ingress of the MPLS LSP, being a midpoint LSR for a set of client
mechanism determine which client LSP contained within it as MPLS-TP LSP, has no signaling mechanism that can be used to determine if any
or not MPLS-TP. Multipath load splitting can be avoided for MPLS-TP specific client LSP contained within it is MPLS or MPLS-TP.
LSP if at the MPLS server layer LSP ingress LSR an Entropy Label Multipath load splitting can be avoided for MPLS-TP LSP if at the
Indicator (ELI) and Entropy Label (EL) are added to the label stack MPLS server layer LSP ingress LSR an Entropy Label Indicator (ELI)
[RFC6790]. For those client LSP that are MPLS-TP LSP, a single EL and Entropy Label (EL) are added to the label stack [RFC6790]. For
value must be chosen. For those client LSP that are MPLS LSP, per those client LSP that are MPLS-TP LSP, a single EL value must be
packet entropy below the top label must, for practical reasons, be chosen. For those client LSP that are MPLS LSP, per packet entropy
used to determine the entropy label value. Requirement MP#1 simply below the top label must, for practical reasons, be used to determine
states that there must be a means to make this decision. the entropy label value. Requirement MP#1 simply states that there
must be a means to make this decision.
There is currently no signaling mechanism defined to support There is currently no signaling mechanism defined to support
requirement MP#1, though that does not preclude a new extension being requirement MP#1, though that does not preclude a new extension being
defined later. In the absense of a signaling extension, MPLS-TP can defined later. In the absence of a signaling extension, MPLS-TP can
be identified through some form of configuration, such as be identified through some form of configuration, such as
configuration which provides an MPLS-TP compatible server layer to configuration which provides an MPLS-TP compatible server layer to
all LSP arriving on a specific interface or originating from a all LSP arriving on a specific interface or originating from a
specific set of ingress LSR. specific set of ingress LSR.
Alternately, the need for requirement MP#1 can be eliminated if evey Alternately, the need for requirement MP#1 can be eliminated if every
MPLS-TP LSP can be created by the MPLS-TP ingress makes use of an MPLS-TP LSP can be created by the MPLS-TP ingress makes use of an
Entropy Label Indicator (ELI) and Entropy Label (EL) below the Entropy Label Indicator (ELI) and Entropy Label (EL) below the
MPLS-TP label [RFC6790]. This would require that all MPLS-TP LSR in MPLS-TP label [RFC6790]. This would require that all MPLS-TP LSR in
a deployment support Entropy Label, which may render it impractical a deployment support Entropy Label, which may render it impractical
in many deployments. in many deployments.
Some hardware which exists today can support requirement MP#2. Some hardware which exists today can support requirement MP#2.
Signaling in the absense of MPLS Entropy Label can make use of link Signaling in the absence of MPLS Entropy Label can make use of link
bundling with the path pinned to a specific component for MPLS-TP LSP bundling with the path pinned to a specific component for MPLS-TP LSP
and link bundling using the all-ones component for MPLS LSP. This and link bundling using the all-ones component for MPLS LSP. This
prevents MPLS-TP LSP from being carried within MPLS LSP but does prevents MPLS-TP LSP from being carried within MPLS LSP but does
allow the co-existance of MPLS-TP and very large MPLS LSP. allow the co-existance of MPLS-TP and very large MPLS LSP.
MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP
if an Entropy Label Indicator (ELI) and Entropy Label (EL) is added if an Entropy Label Indicator (ELI) and Entropy Label (EL) is pushed
after the server layer LSP label(s) in the label stack, just above below the server layer LSP label(s) in the label stack, just above
the MPLS-TP LSP label entry [RFC6790]. The value of EL can be the MPLS-TP LSP label entry [RFC6790]. The value of EL can be
randomly selected at the client MPLS-TP LSP setup time and the same randomly selected at the client MPLS-TP LSP setup time and the same
EL value used for all packets of that MPLS-TP LSP. This allows EL value used for all packets of that MPLS-TP LSP. This allows
MPLS-TP LSP to be carried as client LSP within MPLS LSP and satisfies MPLS-TP LSP to be carried as client LSP within MPLS LSP and satisfies
MPLS-TP forwarding requirements but requires that MPLS LSR be able to MPLS-TP forwarding requirements but requires that MPLS LSR be able to
identify MPLS-TP LSP (requirement MP#1). identify MPLS-TP LSP (requirement MP#1).
MPLS-TP traffic can be protected from an degraded performance due to MPLS-TP traffic can be protected from degraded performance due to an
an imperfect load split if the MPLS-TP traffic is given queuing imperfect load split if the MPLS-TP traffic is given queuing priority
priority (using strict priority and policing or shaping at ingress or (using strict priority and policing or shaping at ingress or locally
locally or weighted queuing locally). This can be accomplished using or weighted queuing locally). This can be accomplished using the
the Traffic Class field and Diffserv treatment of traffic Traffic Class field and Diffserv treatment of traffic
[RFC5462][RFC2475]. In the event of congestion due to load [RFC5462][RFC2475]. In the event of congestion due to load
imbalance, other traffic will suffer as long as there is a minority imbalance, only non-prioritized traffic will suffer as long as there
of MPLS-TP traffic. is a low percentage of prioritized traffic.
If MPLS-TP LSP are carried within MPLS LSP and ELI and EL are used, If MPLS-TP LSP are carried within MPLS LSP and ELI and EL are used,
requirement MP#3 is satisfied only for uncongested links where load requirement MP#3 is satisfied only for uncongested links where load
balancing is not required, or if MPLS-TP LSP use TC and Diffserv and balancing is not required, or if MPLS-TP LSP use TC and Diffserv and
the load rebalancing implementation rebalances only the less the load rebalancing implementation rebalances only the less
preferred traffic. Load rebalance is generally needed only when preferred traffic. Load rebalance is generally needed only when
congestion occurs, therefore restricting MPLS-TP to be carried only congestion occurs, therefore restricting MPLS-TP to be carried only
over MPLS LSP that are known to traverse only links which are over MPLS LSP that are known to traverse only links which are
expected to be uncongested can satisfy requirement MP#3. expected to be uncongested can satisfy requirement MP#3.
skipping to change at page 12, line 46 skipping to change at page 12, line 8
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
9.2. Informative References 9.2. Informative References
[I-D.ietf-rtgwg-cl-requirement]
Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
Yong, "Requirements for Advanced Multipath in MPLS
Networks", draft-ietf-rtgwg-cl-requirement-11 (work in
progress), July 2013.
[IEEE-802.1AX] [IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/ Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>. download/802.1AX-2008.pdf>.
[ITU-T.G.800] [ITU-T.G.800]
ITU-T, "Unified functional architecture of transport ITU-T, "Unified functional architecture of transport
networks", 2007, <http://www.itu.int/rec/T-REC-G/ networks", 2007, <http://www.itu.int/rec/T-REC-G/
recommendation.asp?parent=T-REC-G.800>. recommendation.asp?parent=T-REC-G.800>.
 End of changes. 24 change blocks. 
107 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/