draft-ietf-mpls-multipath-use-04.txt   rfc7190.txt 
MPLS C. Villamizar Internet Engineering Task Force (IETF) C. Villamizar
Internet-Draft Outer Cape Cod Network Consulting Request for Comments: 7190 Outer Cape Cod Network Consulting
Intended status: Informational January 28, 2014 Category: Informational March 2014
Expires: August 01, 2014 ISSN: 2070-1721
Use of Multipath with MPLS and MPLS-TP Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)
draft-ietf-mpls-multipath-use-04
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 Transport Profile (MPLS-TP) has strongly discouraged networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged
the use of multipath techniques. Some degradation of MPLS-TP the use of multipath techniques. Some degradation of MPLS-TP
Operations, Administration, and Maintenance (OAM) performance cannot Operations, Administration, and Maintenance (OAM) performance cannot
be avoided when operating over many types of multipath be avoided when operating over many types of multipath
implementations. implementations.
Using MPLS Entropy Labels (RFC6790), MPLS Label Switched Paths (LSPs) Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths
can be carried over multipath links while also providing a fully (LSPs) can be carried over multipath links while also providing a
MPLS-TP compliant server layer for MPLS-TP LSPs. This document fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document
describes the means of supporting MPLS as a server layer for MPLS-TP. describes the means of supporting MPLS as a server layer for MPLS-TP.
The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also
discussed. discussed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 01, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7190.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . 5 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 . . . 7
4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . 10 4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
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
met by a number of techniques which we will collectively call met by a number of techniques that we will collectively call
multipath. Multipath applied to parallel links between the same set "multipath". Multipath applied to parallel links between the same
of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link set of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link
bundling [RFC4201], or other aggregation techniques some of which bundling [RFC4201], or other aggregation techniques, some of which
could be vendor specific. Multipath applied to diverse paths rather could be vendor specific. Multipath applied to diverse paths rather
than parallel links includes Equal Cost MultiPath (ECMP) as applied than parallel links includes Equal-Cost Multipath (ECMP) as applied
to OSPF, IS-IS, or BGP, and equal cost Label Switched Paths (LSPs). to OSPF, IS-IS, or BGP, and equal-cost Label Switched Paths (LSPs).
Some vendors support load splitting across equal cost MPLS LSPs where Some vendors support load splitting across equal-cost MPLS LSPs where
the load is split proportionally to the reserved bandwidth of the set the load is split proportionally to the reserved bandwidth of the set
of LSPs. 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 Transport Profile (MPLS-TP) or MPLS layer over a server MPLS-TP MPLS Transport Profile (MPLS-TP) or MPLS layer over a server MPLS-TP
or MPLS layer [RFC5654]. This is possible in all cases with one or MPLS layer [RFC5654]. This is possible in all cases with one
exception. When an MPLS LSP exceeds the capacity of any single exception. When an MPLS LSP exceeds the capacity of any single
component link it MAY be carried by a network using multipath component link, it MAY be carried by a network using multipath
techniques, but SHOULD NOT be carried by a single MPLS-TP LSP due to techniques, but it SHOULD NOT be carried by a single MPLS-TP LSP due
the inherent MPLS-TP capacity limitation imposed by MPLS-TP to the inherent MPLS-TP capacity limitation imposed by MPLS-TP
Operations, Administration, and Maintenance (OAM) fate-sharing Operations, Administration, and Maintenance (OAM) fate-sharing
constraints and MPLS-TP LM OAM packet ordering constraints (see constraints and MPLS-TP Loss Measurement OAM packet-ordering
Section 3.1). Instead, multiple MPLS-TP LSPs SHOULD be used to carry constraints (see Section 3.1). Instead, multiple MPLS-TP LSPs SHOULD
a large MPLS LSP (see Section 4). be used to carry a large MPLS LSP (see Section 4).
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-T, but specifically excludes inverse multiplexing. defined by ITU-T but specifically excludes inverse multiplexing.
MPLS LSPs today are able to function as a server layer and carry MPLS LSPs today are able to function as a server layer and carry
client MPLS LSPs. When control plane signaling is used, forwarding client MPLS LSPs. When control-plane signaling is used, forwarding
adjacency (FA) advertisements are used to inform the set of LSR of adjacency (FA) advertisements are used to inform the set of Label
Packet Switching Capable (PSC) LSP within the MPLS topology Switching Routers (LSRs) of Packet Switching Capable (PSC) LSPs
[RFC4206]. Client MPLS LSP at a higher layer (lower PSC number) may within the MPLS topology [RFC4206]. Client MPLS LSP at a higher
signal their intention to use PSC LSP as hops in the RSVP-TE Explicit layer (lower PSC number) may signal their intention to use PSC LSPs
Route Object (ERO). LSR with no explicit support for RFC 4206 see as hops in the RSVP-TE Explicit Route Object (ERO). LSRs with no
the PSC LSP as ordinary links and therefore use them. explicit support for RFC 4206 see the PSC LSPs as ordinary links and
therefore use them.
An MPLS LSP that has been set up using RSVP-TE appears to its ingress An MPLS LSP that has been set up using RSVP-TE appears to its ingress
LSR as a viable IP next hop to a distant LSR. If LDP is used and LSR as a viable IP next hop to a distant LSR. If LDP is used and
bidirectional RSVP-TE LSP connectivity is available, then LDP bidirectional RSVP-TE LSP connectivity is available, then LDP
signaling can be set up among the RSVP-TE LSP endpoints and LDP can signaling can be set up among the RSVP-TE LSP endpoints, and LDP can
make use of the RSVP-TE LSP as an LDP hop. This is another form of make use of the RSVP-TE LSP as an LDP hop. This is another form of
existing MPLS-in-MPLS use. MPLS LSPs may also make use of hierarchy existing MPLS-in-MPLS use. MPLS LSPs may also make use of hierarchy
that is configured through the management plane rather than signaled that is configured through the management plane rather than signaled
using RSVP-TE. using RSVP-TE.
These existing forms of MPLS-in-MPLS may traverse multipath hops such These existing forms of MPLS-in-MPLS may traverse multipath hops such
as Ethernet LAG [IEEE-802.1AX] or MPLS Link Bundling [RFC4201]. as Ethernet Link Aggregation Group (LAG) [IEEE-802.1AX] or MPLS Link
MPLS-TP brings with it a new set of requirements not considered in Bundling [RFC4201]. MPLS-TP brings with it a new set of requirements
past deployments of the various forms of MPLS-in-MPLS where multipath not considered in past deployments of the various forms of MPLS-in-
was in use. This document merely discusses use of existing MPLS where multipath was in use. This document merely discusses use
forwarding and protocol mechanisms that can support the case where of existing forwarding and protocol mechanisms that can support the
either the client layer LSPs or the server layer LSPs are MPLS-TP and case where either the client-layer LSPs or the server-layer LSPs are
where multipath is used. MPLS-TP and where multipath is used.
2. Definitions 2. Definitions
Please refer to the terminology related to multipath introduced in Please refer to the terminology related to multipath introduced in
[I-D.ietf-rtgwg-cl-requirement]. The following additional terms are [ADV-MULTIPATH-REQ]. The following additional terms are used in this
used in this document with related terms grouped together. document; related terms are grouped together.
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 that 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.
All-Ones Component All-Ones Component
Within the context of link bundling, [RFC4201] defines a special Within the context of link bundling, [RFC4201] defines a special
case where the same label is to be valid across all component case where the same label is to be valid across all component
links. This case is indicated in signaling by a bit value of links. This case is indicated in signaling by a bit value of
"all ones" when identifying a component link. Following the "all ones" when identifying a component link. Following the
publication of RFC 4201, for brevity this special case has been publication of RFC 4201, for brevity this special case has been
referred to as the "all-ones component". referred to as the "all-ones component".
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 (LFA) Loop-Free Alternate Paths (LFA)
"Loop-free alternate paths" (LFA) are defined in RFC 5714, "Loop-free alternate paths" (LFA) are defined in Section 5.2 of
Section 5.2 [RFC5714] as follows: "Such a path exists when a RFC 5714 [RFC5714] as follows: "Such a path exists when a direct
direct neighbor of the router adjacent to the failure has a path neighbor of the router adjacent to the failure has a path to the
to the destination that can be guaranteed not to traverse the destination that can be guaranteed not to traverse the failure."
failure." Further detail can be found in [RFC5286]. LFA as Further detail can be found in [RFC5286]. LFA as defined for IP
defined for IP Fast Reroute (IPFRR) can be used to load balance Fast Reroute (IPFRR) can be used to load balance by relaxing the
by relaxing the equal cost criteria of ECMP, though IPFRR defined equal-cost criteria of ECMP, though IPFRR defined LFA for use in
LFA for use in selecting protection paths. When used with IP, selecting protection paths. When used with IP, proportional
proportional split is generally not used. LFA use in load split is generally not used. LFA use in load balancing is
balancing is implemented by some vendors though it may be rare or implemented by some vendors, though it may be rare or non-
non-existent in deployments. existent in deployments.
Link Aggregation Link Aggregation
The term "link aggregation" generally refers to Ethernet Link The term "link aggregation" generally refers to Ethernet Link
Aggregation as defined by the [IEEE-802.1AX]. Ethernet Link Aggregation as defined by [IEEE-802.1AX]. Ethernet Link
Aggregation defines a Link Aggregation Control Protocol (LACP) Aggregation defines a Link Aggregation Control Protocol (LACP)
which coordinates inclusion of Link Aggregation Group (LAG) which coordinates inclusion of Link Aggregation Group (LAG)
members in the LAG. members in the LAG.
Link Aggregation Group (LAG) Link Aggregation Group (LAG)
A group of physical Ethernet interfaces that are treated as a A group of physical Ethernet interfaces that are treated as a
logical link when using Ethernet Link Aggregation is referred to logical link when using Ethernet Link Aggregation is referred to
as a Link Aggregation Group (LAG). as a Link Aggregation Group (LAG).
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".
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", and the layer. Key requirements include OAM "fate-sharing" and that packets
requirement that packets within an MPLS-TP LSP are not reordered, within an MPLS-TP LSP (including both payload and OAM packets) not be
including both payload and OAM packets. Section 3.2 discusses reordered. Section 3.2 discusses implied requirements where MPLS is
implied requirements where MPLS is the server layer for MPLS-TP the server layer for MPLS-TP client LSPs and describes a set of
client LSPs, and describes a set of solutions using existing MPLS solutions that use 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 data plane requirements for MPLS-TP. Two very [RFC5960] defines the data-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
Forwarding" are the following: Forwarding") are the following:
RFC 5960, Section 3.1.1, Paragraph 3 RFC 5960, Section 3.1.1, Paragraph 3
Except for transient packet reordering that may occur, for Except for transient packet reordering that may occur, for
example, during fault conditions, packets are delivered in order example, during fault conditions, packets are delivered in order
on L-LSPs, and on E-LSPs within a specific ordered aggregate. on L-LSPs, and on E-LSPs within a specific ordered aggregate.
RFC 5960, Section 3.1.1, Paragraph 6 RFC 5960, Section 3.1.1, Paragraph 6
Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed
on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY
operate over a server layer that supports load-balancing, but operate over a server layer that supports load-balancing, but
this load-balancing MUST operate in such a manner that it is this load-balancing MUST operate in such a manner that it is
transparent to MPLS-TP. This does not preclude the future transparent to MPLS-TP. This does not preclude the future
definition of new MPLS-TP LSP types that have different definition of new MPLS-TP LSP types that have different
requirements regarding the use of ECMP in the server layer. requirements regarding the use of ECMP in the server layer.
[RFC5960] Section 3.1.1, Paragraph 3 requires that packets within a [RFC5960], Section 3.1.1, Paragraph 3 requires that packets within a
specific ordered aggregate be delivered in order. This same specific ordered aggregate be delivered in order. This same
requirement is already specified by Differentiated Services requirement is already specified by Differentiated Services
[RFC2475]. [RFC5960] Section 3.1.1, Paragraph 6 explicitly allows a [RFC2475]. [RFC5960], Section 3.1.1, Paragraph 6 explicitly allows a
server layer to use ECMP provided that it is transparent to the MPLS- server layer to use ECMP, provided that it is transparent to the
TP client layer. MPLS-TP client layer.
[RFC6371] adds a requirement for data traffic and OAM traffic "fate- [RFC6371] adds a requirement for data traffic and OAM traffic "fate-
sharing". The following paragraph in Section 1 ("Introduction") sharing". The following paragraph in Section 1 ("Introduction")
summarizes this requirement. summarizes this requirement.
RFC 6371, Section 1, Paragraph 7 RFC 6371, Section 1, Paragraph 7
OAM packets that instrument a particular direction of a transport OAM packets that instrument a particular direction of a transport
path are subject to the same forwarding treatment (i.e., fate- path are subject to the same forwarding treatment (i.e., fate-
share) as the user data packets and in some cases, where share) as the user data packets and in some cases, where
Explicitly EXP-encoded-PSC LSPs (E-LSPs) are employed, may be Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be
required to have common per-hop behavior (PHB) Scheduling Class required to have common per-hop behavior (PHB) Scheduling Class
(PSC) End-to-End (E2E) with the class of traffic monitored. In (PSC) End-to-End (E2E) with the class of traffic monitored. In
case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of
traffic needs to be monitored, and therefore the OAM packets have traffic needs to be monitored, and therefore the OAM packets have
common PSC with the monitored traffic class. common PSC with the monitored traffic class.
[RFC6371] does not prohibit multilink techniques in "Section 4.6 [RFC6371] does not prohibit multilink techniques in Section 4.6
Fate-Sharing Considerations for Multilink", where multilink is ("Fate-Sharing Considerations for Multilink"), where multilink is
defined as Ethernet Link Aggregation and the use of Link Bundling for defined as Ethernet Link Aggregation and the use of Link Bundling for
MPLS, but does declare that such a network would be only partially MPLS, but it does declare that such a network would be only partially
MPLS-TP compliant. The characteristic that is to be avoided is MPLS-TP compliant. The characteristic that is to be avoided is
contained in the following sentence in this section. contained in the following sentence in that section.
RFC 6371, Section 4.6, Paragraph 1, last sentence RFC 6371, Section 4.6, Paragraph 1, last sentence
These techniques frequently share the characteristic that an LSP These techniques frequently share the characteristic that an LSP
may be spread over a set of component links and therefore be may be spread over a set of component links and therefore be
reordered, but no flow within the LSP is reordered (except when reordered, but no flow within the LSP is reordered (except when
very infrequent and minimally disruptive load rebalancing very infrequent and minimally disruptive load rebalancing
occurs). occurs).
A declaration that implies that Link Bundling for MPLS yields a A declaration that implies that Link Bundling for MPLS yields a
partially MPLS-TP compliant network, is perhaps overstated since only partially MPLS-TP-compliant network is perhaps overstated since only
the Link Bundling all-ones component link has this characteristic. the Link Bundling all-ones component link has this characteristic.
[RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets [RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets
cannot be reordered with respect to payload packets. This will cannot be reordered with respect to payload packets. This will
require that payload packets themselves not be reordered. The require that payload packets themselves not be reordered. The
following paragraph in Section 2.9.4 ("Equal Cost Multipath") gives following paragraph in Section 2.9.4 ("Equal Cost Multipath") gives
the reason for this restriction. the reason for this restriction.
RFC 6374, Section 2.9.4, Paragraph 2 RFC 6374, Section 2.9.4, Paragraph 2
The effects of ECMP on loss measurement will depend on the LM The effects of ECMP on loss measurement will depend on the LM
skipping to change at page 7, line 9 skipping to change at page 7, line 25
of how many paths exist between them. However, the presence of of how many paths exist between them. However, the presence of
ECMP increases the likelihood of misordering both of LM messages ECMP increases the likelihood of misordering both of LM messages
relative to data packets and of the LM messages themselves. Such relative to data packets and of the LM messages themselves. Such
misorderings tend to create unmeasurable intervals and thus misorderings tend to create unmeasurable intervals and thus
degrade the accuracy of loss measurement. The effects of ECMP degrade the accuracy of loss measurement. The effects of ECMP
are similar for inferred LM, with the additional caveat that, are similar for inferred LM, with the additional caveat that,
unless the test packets are specially constructed so as to probe unless the test packets are specially constructed so as to probe
all available paths, the loss characteristics of one or more of all available paths, the loss characteristics of one or more of
the alternate paths cannot be accounted for. the alternate paths cannot be accounted for.
3.2. Methods of Supporting MPLS-TP client LSPs over MPLS 3.2. Methods of Supporting MPLS-TP Client LSPs over MPLS
Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP
server layer where the MPLS LSPs are making use of multipath, server layer where the MPLS LSPs are making use of multipath requires
requires special treatment of the MPLS-TP LSPs such that those LSPs special treatment of the MPLS-TP LSPs such that those LSPs meet MPLS-
meet MPLS-TP forwarding requirements (see Section 3.1). This implies TP forwarding requirements (see Section 3.1). This implies the
the following brief set of requirements. following brief set of requirements.
MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching
Router (LSR) which is serving as ingress to a server layer MPLS Router (LSR) that is serving as ingress to a server-layer MPLS
LSP to identify MPLS-TP LSPs, so that MPLS-TP forwarding LSP to identify MPLS-TP LSPs, so that MPLS-TP forwarding
requirements can be applied, or to otherwise accommodate the requirements can be applied, or to otherwise accommodate the
MPLS-TP forwarding requirements. MPLS-TP forwarding requirements.
MP#2 The ability to completely exclude MPLS-TP LSPs from the MP#2 The ability to completely exclude MPLS-TP LSPs from the
multipath hash and load split SHOULD be supported. If the multipath hash and load split SHOULD be supported. If the
selected component link no longer meets requirements, an LSP is selected component link no longer meets requirements, an LSP is
considered down which may trigger protection and/or may require considered down, which may trigger protection and/or may
that the ingress LSR select a new path and signal a new LSP. require that the ingress LSR select a new path and signal a new
LSP.
MP#3 It SHOULD be possible to ensure that MPLS-TP LSPs will not be MP#3 It SHOULD be possible to ensure 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 load-
load rebalancing operation. If the selected component link no rebalancing operation for multipath. If the selected component
longer meets requirements, another component link may be link no longer meets requirements, another component link may
selected, however a change in path SHOULD NOT occur solely for be selected; however, a change in path SHOULD NOT occur solely
load balancing. for load balancing.
MP#4 Where an Resource Reservation Protocol - Traffic Engineering MP#4 Where a Resource Reservation Protocol - Traffic Engineering
(RSVP-TE) control plane is used, it MUST be possible for 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 ingress LSR that 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 the Adjacency (FA; see [RFC4206]) within the topology can support
MPLS-TP requirements of the LSP. the MPLS-TP requirements of the LSP.
The reason for requirement MP#1 may not be obvious. An MPLS-TP LSP The reason for requirement MP#1 may not be obvious. An MPLS-TP LSP
may be aggregated along with other client LSPs 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, being a midpoint LSR for a set of client ingress of the MPLS LSP, being a midpoint LSR for a set of client
LSPs, has no signaling mechanism that can be used to determine if any LSPs, has no signaling mechanism that can be used to determine
specific client LSP contained within it is MPLS or MPLS-TP. whether one of its specific client LSPs is using MPLS or MPLS-TP.
Multipath load splitting can be avoided for MPLS-TP LSPs if at the Multipath load splitting can be avoided for MPLS-TP LSPs if at the
MPLS server layer LSP ingress LSR an Entropy Label Indicator (ELI) MPLS server-layer LSP ingress LSR an Entropy Label Indicator (ELI)
and Entropy Label (EL) are added to the label stack by the midpoint and Entropy Label (EL) are added to the label stack by the midpoint
LSR for the client MPLS-TP LSP, at the ingress of the MPLS LSP LSR for the client MPLS-TP LSP, at the ingress of the MPLS LSP
[RFC6790]. For those client LSPs that are MPLS-TP LSPs, a single [RFC6790]. For those client LSPs that are MPLS-TP LSPs, a single
per-LSP EL value must be chosen. For those client LSPs that are MPLS per-LSP EL value must be chosen. For those client LSPs that are MPLS
LSPs, per packet entropy below the top label must, for practical LSPs, per-packet entropy below the top label must, for practical
reasons, be used to determine the entropy label value. The resulting reasons, be used to determine the entropy label value. The resulting
label stack contains the server MPLS LSP label, ELI, EL and the label stack contains the server MPLS LSP label, ELI, EL and the
client LSP label. Requirement MP#1 simply states that there must be client LSP label. Requirement MP#1 simply states that there must be
a means to make this decision. 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 absence 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 that provides an MPLS-TP-compatible server layer to all
all LSPs arriving on a specific interface or originating from a LSPs arriving on a specific interface or originating from a specific
specific set of ingress LSRs. set of ingress LSRs.
Alternately, the need for requirement MP#1 can be eliminated if every Alternatively, the need for requirement MP#1 can be eliminated if
MPLS-TP LSP created by an MPLS-TP ingress makes use of an Entropy every MPLS-TP LSP created by an MPLS-TP ingress makes use of an
Label Indicator (ELI) and Entropy Label (EL) below the MPLS-TP label Entropy Label Indicator (ELI) and Entropy Label (EL) below the MPLS-
[RFC6790]. This would require that all MPLS-TP LSR in a deployment TP label [RFC6790]. This would require that all MPLS-TP LSRs in a
support Entropy Label, which may render it impractical in many deployment support Entropy Label, which may render it impractical in
deployments. many deployments.
Some hardware which exists today can support requirement MP#2. Some hardware that exists today can support requirement MP#2.
Signaling in the absence of MPLS Entropy Label can make use of link Signaling in the absence of MPLS Entropy Labels can make use of link
bundling with the path pinned to a specific component for MPLS-TP bundling with the path pinned to a specific component for MPLS-TP
LSPs and link bundling using the all-ones component for MPLS LSPs. LSPs and link bundling using the all-ones component for MPLS LSPs.
This prevents MPLS-TP LSPs from being carried within MPLS LSPs but This prevents MPLS-TP LSPs from being carried within MPLS LSPs but
does allow the coexistance of MPLS-TP and very large MPLS LSPs. does allow the coexistence of MPLS-TP and very large MPLS LSPs.
When Entropy Label Indicator (ELIs) and Entropy Labels (ELs) are not When Entropy Label Indicators (ELIs) and Entropy Labels (ELs) are not
applied by MPLS-TP ingresses, MPLS-TP LSPs can be carried as client applied by MPLS-TP ingresses, MPLS-TP LSPs can be carried as client
LSPs within an MPLS server LSP if the ingress of the MPLS server LSPs within an MPLS server LSP if the ingress of the MPLS server-
layer LSP pushes an Entropy Label Indicator (ELI) and Entropy Label layer LSP pushes an Entropy Label Indicator (ELI) and Entropy Label
(EL) below the server layer LSP label(s) in the label stack, just (EL) 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 above 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 MPLS- EL value can be used for all packets of that MPLS-TP LSP. This
TP LSPs to be carried as client LSPs within MPLS LSPs and satisfies allows MPLS-TP LSPs to be carried as client LSPs within MPLS LSPs and
MPLS-TP forwarding requirements but requires that MPLS LSRs be able satisfies MPLS-TP forwarding requirements but requires that MPLS LSRs
to identify MPLS-TP LSPs (requirement MP#1). be able to identify MPLS-TP LSPs (requirement MP#1).
MPLS-TP traffic can be protected from degraded performance due to an MPLS-TP traffic can be protected from degraded performance due to an
imperfect load split if the MPLS-TP traffic is given queuing priority imperfect load split if the MPLS-TP traffic is given queuing
(using strict priority and policing or shaping at ingress or locally priority. For example, using (1) strict priority and policing,
or weighted queuing locally). This can be accomplished using the shaping at ingress, or per-LSP shaping locally, or (2) per-LSP
Traffic Class (TC) field and Diffserv treatment of traffic weighted queuing locally. This can be accomplished using the Traffic
[RFC5462][RFC2475]. In the event of congestion due to load Class (TC) field and Diffserv treatment of traffic [RFC5462]
imbalance, only non-prioritized traffic will suffer as long as there [RFC2475]. In the event of congestion due to load imbalance, only
is a low percentage of prioritized traffic. non-prioritized traffic will suffer as long as there is a low
percentage of prioritized traffic.
If MPLS-TP LSPs are carried within MPLS LSPs and ELI and EL are used, If MPLS-TP LSPs are carried within MPLS LSPs and ELI and EL are used,
requirement MP#3 is satisfied only for uncongested links where load requirement MP#3 is satisfied (1) for uncongested links where load
balancing is not required, or if MPLS-TP LSPs use Traffic Class (TC) balancing is not required, or (2) for MPLS-TP LSPs using Traffic
and Diffserv and the load rebalancing implementation rebalances only Class (TC) and Diffserv, where the load rebalancing implementation
the less preferred traffic. Load rebalance is generally needed only rebalances only the less preferred traffic. Load rebalance is
when congestion occurs, therefore restricting MPLS-TP to be carried generally needed only when congestion occurs; therefore, restricting
only over MPLS LSPs that are known to traverse only links which are MPLS-TP to be carried over MPLS LSPs that are known to traverse only
expected to be uncongested can satisfy requirement MP#3. links that are expected to be uncongested can satisfy requirement
MP#3.
An MPLS-TP LSP can be pinned to a Link Bundle component link if the An MPLS-TP LSP can be pinned to a Link Bundle component link if the
behavior of requirement MP#2 is preferred. An MPLS-TP LSP can be behavior of requirement MP#2 is preferred. An MPLS-TP LSP can be
assigned to a Link Bundle but not pinned if the behavior of assigned to a Link Bundle but not pinned if the behavior of
requirement MP#3 is preferred. In both of these cases, the MPLS-TP requirement MP#3 is preferred. In both of these cases, the MPLS-TP
LSP must be the top level LSP, except as noted above. LSP must be the top-level LSP, except as noted above.
If MPLS-TP LSPs can be moved among component links, then the Link If MPLS-TP LSPs can be moved among component links, then the Link
Bundle all-ones component link can be used or server layer MPLS LSPs Bundle all-ones component link can be used or server-layer MPLS LSPs
can be used with no restrictions on the server layer MPLS use of can be used with no restrictions on the server-layer MPLS use of
multipath except that Entropy Label must be supported along the multipath, except that Entropy Labels must be supported along the
entire path. An Entropy Label must be used to ensure that all of the entire path. An Entropy Label must be used to ensure that all of the
MPLS-TP payload and OAM traffic are carried on the same component, MPLS-TP payload and OAM traffic are carried on the same component,
except during very infrequent transitions due to load balancing. except during very infrequent transitions due to load balancing.
Since the Entropy Label Indicator and Entropy Label are always placed Since the Entropy Label Indicator and Entropy Label are always placed
above the Generic Associated Channel Label (GAL) in the stack, the above the Generic Associated Channel Label (GAL) in the stack, the
presence of GAL will not affect the selection of a component link as presence of a GAL will not affect the selection of a component link
long as the LSR does not hash on the label stack entries below the as long as the LSR does not hash on the label stack entries below the
Entropy Label. Entropy Label.
An MPLS-TP LSP may not traverse multipath links on the path where An MPLS-TP LSP may not traverse multipath links on the path where
MPLS-TP forwarding requirements cannot be met. Such links include MPLS-TP forwarding requirements cannot be met. Such links include
any using pre- RFC 6790 Ethernet Link Aggregation, pre- RFC 6790 Link any using pre-[RFC6790] Ethernet Link Aggregation, pre-[RFC6790] Link
Bundling using the all-ones component link, or other form of Bundling using the all-ones component link, or any other form of
multipath not supporting termination of the entropy search at the EL multipath that does not support termination of the entropy search at
as called for in [RFC6790]. An MPLS-TP LSP MUST NOT traverse a the EL as called for in [RFC6790]. An MPLS-TP LSP MUST NOT traverse
server layer MPLS LSP which traverses any form of multipath not a server-layer MPLS LSP that traverses any form of multipath that
supporting termination of the entropy search at the EL. For this to does not support termination of the entropy search at the EL. For
occur, the MPLS-TP ingress LSR MUST be aware of these links. This is this to occur, the MPLS-TP ingress LSR MUST be aware of these links.
the reason for requirement MP#4. This is the reason for requirement MP#4.
Requirement MP#4 can be supported using administrative attributes. Requirement MP#4 can be supported using administrative attributes.
Administrative attributes are defined in [RFC3209]. Some Administrative attributes are defined in [RFC3209]. Some
configuration is required to support this. configuration is required to support this.
In MPLS Link Bundling the requirement for bidirectional co-routing In MPLS Link Bundling the requirement for bidirectional co-routing
can be interpreted as meaning that the same set of LSR must be can be interpreted as meaning that the same set of LSRs must be
traversed or can be interpreted to mean that the same set of traversed or can be interpreted to mean that the same set of
component links must be traversed [RFC4201][RFC3473]. Following the component links must be traversed [RFC4201] [RFC3473]. Following the
procedures of Section 3 of RFC 3473 where Link Bundling is used only procedures of Section 3 of RFC 3473 where Link Bundling is used only
ensures that the same set of LSR are traversed and that acceptable ensures that the same set of LSRs are traversed and that acceptable
labels are created in each direction. labels are created in each direction.
When an MPLS-TP LSP is set up over a MPLS LSP, if the MPLS-TP LSP is When an MPLS-TP LSP is set up over a MPLS LSP, if the MPLS-TP LSP is
a bidirectional LSP, then providers who want to only set these MPLS- a bidirectional LSP, then providers who want to only set these MPLS-
TP LSP over bidirectional co-routed MPLS LSP can make use of TP LSPs over bidirectional co-routed MPLS LSPs can make use of
administrative attributes [RFC3209] to ensure that this occurs. If administrative attributes [RFC3209] to ensure that this occurs. If
MPLS-TP are carried by unidirectional MPLS LSP, the MPLS-TP OAM will MPLS-TP LSPs are carried by unidirectional MPLS LSPs, the MPLS-TP OAM
be unaffected as only the MPLS LSP endpoints will appear as MPLS-TP will be unaffected, as only the MPLS LSP endpoints will appear as
OAM Maintenance Entity Group Intermediate Points (MIPs). MPLS-TP OAM Maintenance Entity Group Intermediate Points (MIPs).
Two methods of adding an Entropy Label are described above. The Two methods of adding an Entropy Label are described above. The
MPLS-TP ingress must have a means to determine which links can MPLS-TP ingress must have a means to determine which links can
support MPLS-TP in selecting a path (MP#4). Administrative support MPLS-TP in selecting a path (MP#4). Administrative
attributes can satisfy that requirement. If the MPLS-TP LSR is attributes can satisfy that requirement. If the MPLS-TP LSR is
capable of adding ELI/EL to the label stack, this method is capable of adding ELI/EL to the label stack, this method is
preferred. However equipment furthest from a provider's network core preferred. However, equipment furthest from a provider's network
is the least likely to support RFC 6790 in the near term. For core is the least likely to support RFC 6790 in the near term. For
portions of the topology where an MPLS-TP is carried within a server portions of the topology where an MPLS-TP is carried within a server-
layer MPLS LSP the ingress of the server layer MPLS LSP can add ELI/ layer MPLS LSP, the ingress of the server-layer MPLS LSP can add ELI/
EL using a fixed EL value per client LSP, except those known not to EL using a fixed EL value per client LSP, except those known not to
require MPLS-TP treatment. There are numerous ways to determine require MPLS-TP treatment. There are numerous ways to determine
which client LSP are MPLS-TP LSP and which are not. While this which client LSPs are MPLS-TP LSPs and which are not. While this
determination is out of scope and will vary among deployments, determination is out of scope and will vary among deployments,
configuration or the presence of specific attribute affinities in configuration or the presence of specific attribute affinities in
RSVP-TE signaling are among the likely means to do so. RSVP-TE signaling are among the likely means to do so.
4. MPLS-TP as a Server Layer for MPLS 4. MPLS-TP as a Server Layer for MPLS
Carrying MPLS LSPs which are larger than a component link over an Carrying MPLS LSPs that are larger than a component link over an
MPLS-TP server layer requires that the large MPLS client layer LSP be MPLS-TP server layer requires that the large MPLS client-layer LSP be
accommodated by multiple MPLS-TP server layer LSPs. MPLS multipath accommodated by multiple MPLS-TP server-layer LSPs. MPLS multipath
can be used in the client layer MPLS. can be used in the client-layer MPLS.
Creating multiple MPLS-TP server layer LSPs places a greater Incoming Creating multiple MPLS-TP server-layer LSPs places a greater Incoming
Label Map (ILM) scaling burden on the LSR. High bandwidth MPLS cores Label Map (ILM) scaling burden on the LSR. High-bandwidth MPLS cores
with a smaller amount of nodes have the greatest tendency to require with a smaller amount of nodes have the greatest tendency to require
LSPs in excess of component links, therefore the reduction in the LSPs in excess of component links; therefore, the reduction in the
number of nodes offsets the impact of increasing the number of server number of nodes offsets the impact of increasing the number of
layer LSPs in parallel. Today, only in cases where deployed LSR ILMs server-layer LSPs in parallel. Today, only in cases where deployed
are small would this be an issue. LSR ILMs are small would this be an issue.
The most significant disadvantage of MPLS-TP as a server layer for The most significant disadvantage of MPLS-TP as a server layer for
MPLS is that the use of MPLS-TP server layer LSPs reduces the MPLS is that the use of MPLS-TP server-layer LSPs reduces the
efficiency of carrying the MPLS client layer. The service which efficiency of carrying the MPLS client layer. The service that
provides by far the largest offered load in provider networks is provides by far the largest offered load in provider networks is the
Internet, for which the LSP capacity reservations are predictions of Internet, for which the LSP capacity reservations are predictions of
expected load. Many of these MPLS LSPs may be smaller than component expected load. Many of these MPLS LSPs may be smaller than component
link capacity. Using MPLS-TP as a server layer results in bin link capacity. Using MPLS-TP as a server layer results in bin-
packing problems for these smaller LSPs. For those LSPs that are packing problems for these smaller LSPs. For those LSPs that are
larger than component link capacity, the LSP capacities need not be larger than component link capacity, the LSP capacities need not be
(and often are not) integer multiples of convenient capacity (and often are not) integer multiples of convenient capacity
increments such as 10 Gb/s. Using MPLS-TP as an underlying server increments such as 10 Gbit/s. Using MPLS-TP as an underlying server
layer greatly reduces the ability of the client layer MPLS LSPs to layer greatly reduces the ability of the client-layer MPLS LSPs to
share capacity. For example, when one MPLS LSP is underutilizing its share capacity. For example, when one MPLS LSP is underutilizing its
predicted capacity, the fixed allocation of MPLS-TP to component predicted capacity, the fixed allocation of MPLS-TP to component
links may not allow another LSP to exceed its predicted capacity. links may not allow another LSP to exceed its predicted capacity.
Using MPLS-TP as a server layer may result in less efficient use of Using MPLS-TP as a server layer may result in less efficient use of
resources and may result in a less cost effective network. resources and may result in a less cost-effective network.
No additional requirements beyond MPLS-TP as it is now currently No additional requirements beyond MPLS-TP as it is now currently
defined are required to support MPLS-TP as a server layer for MPLS. defined are required to support MPLS-TP as a server layer for MPLS.
It is therefore viable but has some undesirable characteristics It is therefore viable but has some undesirable characteristics
discussed above. discussed above.
5. Summary 5. Summary
MPLS equipment deployed in the core currently supports multipath. MPLS equipment deployed in the core currently supports multipath.
For large service providers, core LSR must support some form of For large service providers, core LSR must support some form of
multipath to be deployable. Deployed MPLS access and edge equipment multipath to be deployable. Deployed MPLS access and edge equipment
is often oblivious to the use of multipath in the core. It is is often oblivious to the use of multipath in the core. It is
expected that at least first generation MPLS-TP equipment will be expected that at least first-generation MPLS-TP equipment will be
oblivious to the use of multipath in the core. This first generation oblivious to the use of multipath in the core. This first-generation
MPLS-TP equipment is deployable in a core using multipath, with no MPLS-TP equipment is deployable in a core using multipath, with no
adverse impact to RSVP-TE signaling, if the edge equipment can adverse impact to RSVP-TE signaling, if:
support administrative attributes (RFC 3209) and the core equipment
can support ELI/EL and put a per-LSP fixed EL value on any LSP that 1. the edge equipment can support administrative attributes (RFC
indicates a particular attribute affinity or can identify client 3209),
MPLS-TP LSP through some other means.
2. the core equipment can support ELI/EL, and
3. the core equipment can put a per-LSP fixed EL value on any LSP
that indicates a particular attribute affinity or can identify a
client MPLS-TP LSP through some other means.
There are no issues carrying MPLS over MPLS-TP, except when the MPLS There are no issues carrying MPLS over MPLS-TP, except when the MPLS
LSP is too big to be carried by a single MPLS-TP LSP. Most MPLS core LSP is too big to be carried by a single MPLS-TP LSP. Most MPLS core
equipment and some edge equipment can configure an MPLS Link Bundle equipment and some edge equipment can configure an MPLS Link Bundle
[RFC4201] over multiple component links where the component links are [RFC4201] over multiple component links where the component links are
themselves MPLS LSP. This existing capability can be used to carry themselves MPLS LSP. This existing capability can be used to carry
large MPLS LSP and overcome the limited capacity of any single server large MPLS LSPs and overcome the limited capacity of any single
layer MPLS-TP LSP. server-layer MPLS-TP LSP.
MPLS OAM and MPLS-TP OAM are unaffected in the following cases MPLS OAM and MPLS-TP OAM are unaffected in the following cases
proposed in this document: proposed in this document:
1. Where MPLS is carried over a single MPLS-TP all traffic flows on 1. Where MPLS is carried over a single MPLS-TP, all traffic flows on
one link, MPLS OAM is unaffected and need not use multipath one link, MPLS OAM is unaffected and need not use multipath
support in LSP Ping [RFC4379]. support in LSP Ping [RFC4379].
2. Where MPLS-TP is carried over MPLS, all traffic for that MPLS-TP 2. Where MPLS-TP is carried over MPLS, all traffic for that MPLS-TP
LSP is carried over one link thanks to the fixed EL value. In LSP is carried over one link thanks to the fixed EL value. In
this case MPLS-TP OAM is unaffected. this case, MPLS-TP OAM is unaffected.
3. Where MPLS is carried over MPLS (an existing case) or over 3. Where MPLS LSPs are carried over MPLS LSPs (an existing case) or
multiple MPLS-TP, the multipath support in LSP Ping is used and over multiple MPLS-TP LSPs, the multipath support in LSP Ping is
LSP Ping operation is unaffected [RFC4379][RFC6425]. used and LSP Ping operation is unaffected [RFC4379] [RFC6425].
6. Acknowledgements 6. Acknowledgements
Carlos Pignataro, Dave Allan, and Mach Chen provided valuable Carlos Pignataro, Dave Allan, and Mach Chen provided valuable
comments and suggestions. Carlos suggested that MPLS-TP requirements comments and suggestions. Carlos suggested that MPLS-TP requirements
in RFC 5960 be explicitly referenced or quoted. An email in RFC 5960 be explicitly referenced or quoted. An email
conversation with Dave led to the inclusion of references and quotes conversation with Dave led to the inclusion of references and quotes
from RFC 6371 and RFC 6374. Mach made suggestions to improve clarity from RFCs 6371 and 6374. Mach made suggestions to improve the
of the document. clarity of the document.
7. Implementation Status
Note: this section is temporary and supports the experiment called
for in draft-sheffer-running-code.
This is an informational document which describes usage of MPLS and
MPLS-TP. No new protocol extensions or forwarding behavior are
specified. Ethernet Link Aggregation and MPLS Link Bundling are
widely implemented and deployed.
Entropy Label is not yet widely implemented and deployed, but both
implementation and deployment are expected soon. At least a few
existing high-end, commodity packet processing chips are capable of
supporting Entropy Label. It would be helpful if a few LSR suppliers
would state their intentions to support RFC 6790 on the MPLS mailing
list.
Dynamic multipath (multipath load split adjustment in response to
observed load) is referred to but not a requirement of the usage
recommendations made in this document. Dynamic multipath has been
implemented and deployed, however (afaik) the only core LSR vendor
supporting dynamic multipath is no longer in the router business
(Avici Systems). At least a few existing high-end, commodity packet
processing chips are capable of supporting dynamic multipath.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations 7. Security Considerations
This document specifies use of existing MPLS and MPLS-TP mechanisms This document specifies use of existing MPLS and MPLS-TP mechanisms
to support MPLS and MPLS-TP as client and server layers for each to support MPLS and MPLS-TP as client and server layers for each
other. This use of existing mechanisms supports coexistence of MPLS/ other. This use of existing mechanisms supports coexistence of MPLS/
GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and
multipath. The combination of MPLS, MPLS-TP, and multipath does not multipath. The combination of MPLS, MPLS-TP, and multipath does not
introduce any new security threats. The security considerations for introduce any new security threats. The security considerations for
MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941]. MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941].
10. References 8. References
10.1. Normative References 8.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.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile", and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009. RFC 5654, September 2009.
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Profile Data Plane Architecture", RFC 5960, August 2010. Profile Data Plane Architecture", RFC 5960, August 2010.
skipping to change at page 13, line 41 skipping to change at page 13, line 40
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011. RFC 6371, September 2011.
[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.
10.2. Informative References 8.2. Informative References
[I-D.ietf-rtgwg-cl-requirement] [ADV-MULTIPATH-REQ]
Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
Yong, "Requirements for Advanced Multipath in MPLS Yong, "Requirements for Advanced Multipath in MPLS
Networks", draft-ietf-rtgwg-cl-requirement-15 (work in Networks", Work in Progress, February 2014.
progress), January 2014.
[IEEE-802.1AX] [IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE IEEE, "IEEE Standard for Local and Metropolitan Area
Standard for Local and Metropolitan Area Networks - Link Networks - Link Aggregation", IEEE Std 802.1AX-2008, 2006,
Aggregation", 2006, <http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/download/
download/802.1AX-2008.pdf>. 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", ITU-T G.800, 2007, <http://www.itu.int/rec/
recommendation.asp?parent=T-REC-G.800>. T-REC-G/recommendation.asp?parent=T-REC-G.800>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
skipping to change at page 15, line 14 skipping to change at page 15, line 14
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013. Framework", RFC 6941, April 2013.
Author's Address Author's Address
Curtis Villamizar Curtis Villamizar
Outer Cape Cod Network Consulting Outer Cape Cod Network Consulting
Email: curtis@occnc.com EMail: curtis@occnc.com
 End of changes. 90 change blocks. 
270 lines changed or deleted 244 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/