One document matched: draft-ietf-mpls-multipath-use-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- xml2rfc is available at http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC4201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4201.xml">
<!ENTITY RFC4206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4206.xml">
<!ENTITY RFC4379 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC5462 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5462.xml">
<!ENTITY RFC5654 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5654.xml">
<!ENTITY RFC5714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5714.xml">
<!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">
<!ENTITY RFC5960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5960.xml">
<!ENTITY RFC6371 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6371.xml">
<!ENTITY RFC6374 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC6425 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6425.xml">
<!ENTITY RFC6790 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6790.xml">
<!ENTITY RFC6941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6941.xml">
<!ENTITY I-D.ietf-rtgwg-cl-requirement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-cl-requirement-15">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<rfc category="info" ipr="trust200902"
docName="draft-ietf-mpls-multipath-use-04">
<front>
<title abbrev="MPLS and MPLS-TP Multipath">
Use of Multipath with MPLS and MPLS-TP</title>
<author fullname="Curtis Villamizar"
initials="C." surname="Villamizar">
<organization>Outer Cape Cod Network Consulting</organization>
<address>
<email>curtis@occnc.com</email>
</address>
</author>
<date year="2014" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>composite link</keyword>
<keyword>link aggregation</keyword>
<keyword>ECMP</keyword>
<keyword>link bundling</keyword>
<keyword>multipath</keyword>
<keyword>MPLS-TP</keyword>
<abstract>
<t>
Many MPLS implementations have supported multipath techniques
and many MPLS deployments have used multipath techniques,
particularly in very high bandwidth applications, such as
provider IP/MPLS core networks. MPLS Transport Profile
(MPLS-TP) has strongly discouraged the use of multipath
techniques. Some degradation of MPLS-TP Operations,
Administration, and Maintenance (OAM) performance cannot be
avoided when operating over many types of multipath
implementations.
</t>
<t>
Using MPLS Entropy Labels (RFC6790),
MPLS Label Switched Paths (LSPs) can
be carried over multipath links while also providing a 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. The use of MPLS-TP LSPs as a server layer
for MPLS LSPs is also discussed.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Today the requirement to handle large aggregations of traffic
can be met by a number of techniques which we will
collectively call multipath. Multipath applied to parallel
links between the same set of nodes includes Ethernet Link
Aggregation <xref target="IEEE-802.1AX" />,
<xref target="RFC4201">link bundling</xref>, or other
aggregation techniques some of which could be vendor specific.
Multipath applied to diverse paths rather than parallel links
includes Equal Cost MultiPath (ECMP) as applied to OSPF, IS-IS,
or BGP, and equal cost Label Switched Paths (LSPs). Some
vendors support load splitting across equal cost MPLS LSPs where
the load is split proportionally to the reserved bandwidth of
the set of LSPs.
</t>
<t>
RFC 5654 requirement 33 requires the capability to carry a
client MPLS Transport Profile (MPLS-TP) or MPLS layer over a
server MPLS-TP or MPLS
layer <xref target="RFC5654" />.
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 by a network using multipath techniques, but
SHOULD NOT be carried by a single MPLS-TP LSP due to the
inherent MPLS-TP capacity limitation imposed by MPLS-TP
Operations, Administration, and Maintenance (OAM) fate-sharing
constraints and MPLS-TP LM OAM packet ordering constraints
(see <xref target="sect.tp-requirements" />). Instead,
multiple MPLS-TP LSPs SHOULD be used to carry a large MPLS LSP
(see <xref target="sect.tp-server-layer" />).
</t>
<t>
The term composite link is more general than terms such as
link aggregation (which is specific to Ethernet) or ECMP
(which implies equal cost paths within a routing protocol).
The use of the term composite link here is consistent with the
broad definition in <xref target="ITU-T.G.800" />. Multipath
is very similar to composite link as defined by ITU-T, but
specifically excludes inverse multiplexing.
</t>
<t>
MPLS LSPs today are able to function as a server layer and
carry client MPLS LSPs. When control plane signaling is used,
forwarding adjacency (FA) advertisements are used to inform
the set of LSR of Packet Switching Capable (PSC) LSP within
the MPLS topology <xref target="RFC4206" />. Client MPLS LSP
at a higher layer (lower PSC number) may signal their
intention to use PSC LSP as hops in the RSVP-TE Explicit Route
Object (ERO). LSR with no explicit support for RFC 4206 see
the PSC LSP as ordinary links and therefore use them.
</t>
<t>
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 bidirectional RSVP-TE LSP connectivity is
available, then LDP 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 existing MPLS-in-MPLS use.
MPLS LSPs may also make use of hierarchy that is configured
through the management plane rather than signaled using
RSVP-TE.
</t>
<t>
These existing forms of MPLS-in-MPLS may traverse multipath
hops such as Ethernet LAG <xref target="IEEE-802.1AX" /> or
MPLS Link Bundling <xref target="RFC4201" />. MPLS-TP brings
with it a new set of requirements not considered in past
deployments of the various forms of MPLS-in-MPLS where
multipath was in use. This document merely discusses use of
existing forwarding and protocol mechanisms that can support
the case where either the client layer LSPs or the server
layer LSPs are MPLS-TP and where multipath is used.
</t>
</section>
<section anchor="sect.def" title="Definitions">
<t>
Please refer to the terminology related to multipath
introduced in <xref target="I-D.ietf-rtgwg-cl-requirement" />.
The following additional terms are used in this document with
related terms grouped together.
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="Link Bundle"><vspace blankLines="0" />
Link bundling is a multipath technique specific to MPLS
<xref target="RFC4201" />. Link bundling supports two
modes of operations. 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. There is no
signaling defined which allows a per LSP preference
regarding load split, therefore whether to load split is
generally configured per bundle and applied to all LSPs
across the bundle.
</t>
<t hangText="All-Ones Component"><vspace blankLines="0" />
Within the context of link bundling,
<xref target="RFC4201" />
defines a special case where the same label is to be valid
across all component links. This case is indicated in
signaling by a bit value of "all ones" when identifying a
component link. Following the publication of RFC 4201, for
brevity this special case has been referred to as the
"all-ones component".
</t>
<t hangText="Equal Cost Multipath (ECMP)">
<vspace blankLines="0" /> 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 routing protocol. The
load may be split equally across all available links (or
available paths), or the load may be split proportionally
to the capacity of each link (or path).
</t>
<t hangText="Loop-Free Alternate Paths (LFA)">
<vspace blankLines="0" /> "Loop-free alternate paths"
(LFA) are defined in <xref target="RFC5714">RFC 5714,
Section 5.2</xref> as follows: "Such a path exists when a
direct neighbor of the router adjacent to the failure has
a path to the destination that can be guaranteed not to
traverse the failure." Further detail can be found in
<xref target="RFC5286" />. LFA as defined for
IP Fast Reroute (IPFRR) can
be used to load balance by relaxing the equal cost
criteria of ECMP, though IPFRR defined LFA for use in
selecting protection paths. When used with IP,
proportional split is generally not used. LFA use in load
balancing is implemented by some vendors though it may
be rare or non-existent in deployments.
</t>
<t hangText="Link Aggregation"><vspace blankLines="0" />
The term "link aggregation" generally refers
to Ethernet Link Aggregation as defined by the <xref
target="IEEE-802.1AX" />. Ethernet Link
Aggregation defines a Link Aggregation Control Protocol
(LACP) which coordinates inclusion of Link Aggregation
Group (LAG) members in the LAG.
</t>
<t hangText="Link Aggregation Group (LAG)">
<vspace blankLines="0" /> 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).
</t>
<t hangText="LAG Member"><vspace blankLines="0" />
Ethernet Link Aggregation as defined in <xref
target="IEEE-802.1AX" /> refers to 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 not use
the terms composite link or component link.
</t>
</list></t>
<t>
A small set of requirements are discussed. These requirements
make use of keywords such as MUST and SHOULD as described in
<xref target="RFC2119" />.
</t>
</section>
<section anchor="sect.mpls-server-layer"
title="MPLS as a Server Layer for MPLS-TP">
<t>
An MPLS LSP may be used as a server layer for MPLS-TP LSPs as
long as all MPLS-TP requirements are met.
<xref target="sect.tp-requirements" />
reviews the basis for requirements of a server layer that
supports MPLS-TP as a client layer. Key requirements include
OAM "fate-sharing", and the requirement that packets within an
MPLS-TP LSP are not reordered, including both payload and OAM
packets.
<xref target="sect.tp-over-mpls-soln" />
discusses implied requirements where MPLS is the server layer
for MPLS-TP client LSPs, and describes a set of solutions using
existing MPLS mechanisms.
</t>
<section anchor="sect.tp-requirements"
title="MPLS-TP Forwarding and Server Layer Requirements">
<t>
<!-- ref to RFC5960 suggested by Carlos -->
<xref target="RFC5960" />
defines the data plane requirements for MPLS-TP. Two very
relevant paragraphs in "Section 3.1.1 LSP Packet Encapsulation
and Forwarding" are the following:
<list style="hanging" hangIndent="4">
<t hangText="RFC 5960, Section 3.1.1, Paragraph 3">
<vspace blankLines="0" />
Except for transient packet reordering that may occur, for
example, during fault conditions, packets are delivered in
order on L-LSPs, and on E-LSPs within a specific ordered
aggregate.
</t>
<t hangText="RFC 5960, Section 3.1.1, Paragraph 6">
<vspace blankLines="0" />
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 operate over a server layer that
supports load-balancing, but this load-balancing MUST
operate in such a manner that it is transparent to
MPLS-TP. This does not preclude the future definition of
new MPLS-TP LSP types that have different requirements
regarding the use of ECMP in the server layer.
</t>
</list>
</t>
<t>
<xref target="RFC5960" />
Section 3.1.1, Paragraph 3 requires that packets within a
specific ordered
aggregate be delivered in order. This same requirement
is already specified by Differentiated Services
<xref target="RFC2475" />.
<xref target="RFC5960" />
Section 3.1.1, Paragraph 6 explicitly allows a server layer
to use ECMP
provided that it is transparent to the MPLS-TP client layer.
</t>
<t>
<xref target="RFC6371" />
adds a requirement for data traffic and OAM traffic
"fate-sharing". The following paragraph in Section 1
("Introduction") summarizes this requirement.
<list style="hanging" hangIndent="4">
<t hangText="RFC 6371, Section 1, Paragraph 7">
<vspace blankLines="0" />
OAM packets that instrument a particular direction of a
transport path are subject to the same forwarding
treatment (i.e., fate-share) as the user data packets and
in some cases, where Explicitly EXP-encoded-PSC LSPs
(E-LSPs) are employed, may be required to have common
per-hop behavior (PHB) Scheduling Class (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
traffic needs to be monitored, and therefore the OAM
packets have common PSC with the monitored traffic class.
</t>
</list>
</t>
<t>
<xref target="RFC6371" />
does not prohibit multilink techniques in "Section 4.6
Fate-Sharing Considerations for Multilink", where multilink is
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-TP compliant. The characteristic that
is to be avoided is contained in the following sentence in
this section.
<list style="hanging" hangIndent="4">
<t hangText="RFC 6371, Section 4.6, Paragraph 1, last sentence">
<vspace blankLines="0" />
These techniques frequently share the characteristic that
an LSP may be spread over a set of component links and
therefore be reordered, but no flow within the LSP is
reordered (except when very infrequent and minimally
disruptive load rebalancing occurs).
</t>
</list>
A declaration that implies that Link Bundling for MPLS yields
a partially MPLS-TP compliant network, is perhaps overstated
since only the Link Bundling all-ones component link has this
characteristic.
</t>
<t>
<!-- ref to RFC6374 from conversation with Dave Allan -->
<xref target="RFC6374" />
defines a direct Loss Measurement (LM) where LM OAM packets
cannot be reordered with respect to payload packets. This
will require that payload packets themselves not be reordered.
The following paragraph in Section 2.9.4 ("Equal Cost
Multipath") gives the reason for this restriction.
<list style="hanging" hangIndent="4">
<t hangText="RFC 6374, Section 2.9.4, Paragraph 2">
<vspace blankLines="0" />
The effects of ECMP on loss measurement will depend on the
LM mode. In the case of direct LM, the measurement will
account for any packets lost between the sender and the
receiver, regardless of how many paths exist between them.
However, the presence of ECMP increases the likelihood of
misordering both of LM messages relative to data packets
and of the LM messages themselves. Such misorderings tend
to create unmeasurable intervals and thus degrade the
accuracy of loss measurement. The effects of ECMP are
similar for inferred LM, with the additional caveat that,
unless the test packets are specially constructed so as to
probe all available paths, the loss characteristics of one
or more of the alternate paths cannot be accounted for.
</t>
</list>
</t>
</section>
<section anchor="sect.tp-over-mpls-soln"
title="Methods of Supporting MPLS-TP client LSPs over MPLS">
<t>
Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS
LSP server layer where the MPLS LSPs are making use of
multipath, requires special treatment of the MPLS-TP LSPs
such that those LSPs meet MPLS-TP forwarding requirements
(see <xref target="sect.tp-requirements" />). This implies
the following brief set of requirements.
<list counter="mp" hangIndent="4" style="format MP#%d">
<t>
It MUST be possible for a midpoint MPLS-TP Label
Switching Router (LSR) which is serving as ingress to a
server layer MPLS LSP to identify MPLS-TP LSPs, so that
MPLS-TP forwarding requirements can be applied, or to
otherwise accommodate the MPLS-TP forwarding
requirements.
</t>
<t>
The ability to completely exclude MPLS-TP LSPs from the
multipath hash and load split SHOULD be supported. If
the selected
component link no longer meets requirements, an LSP is
considered down which may trigger protection and/or may
require that the ingress LSR select a new path and
signal a new LSP.
</t>
<t>
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 load rebalancing operation. If the
selected component link no longer meets requirements,
another component link may be selected, however a change
in path SHOULD NOT occur solely for load balancing.
</t>
<t>
Where an Resource Reservation Protocol - Traffic
Engineering (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 determine at path selection
time whether a link or Forwarding Adjacency (FA, see
<xref target="RFC4206" />) within the topology can
support the MPLS-TP requirements of the LSP.
</t>
</list>
</t>
<t>
<!-- inspired by requests to make #1 more clear -->
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 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 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 specific client LSP
contained within it is MPLS or MPLS-TP.
<!-- new sentence added for clarity at Dave's suggestion -->
Multipath load splitting can be avoided for MPLS-TP LSPs if
at the MPLS server layer LSP ingress LSR an Entropy Label
Indicator (ELI) 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 <xref target="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 LSPs, per packet entropy below the top label must,
for practical reasons, be used to determine the entropy
label value. The resulting label stack contains the server
MPLS LSP label, ELI, EL and the client LSP label.
Requirement MP#1 simply states that there must
be a means to make this decision.
</t>
<t>
There is currently no signaling mechanism defined to support
requirement MP#1, though that does not preclude a new
extension being defined later. In the absence of a
signaling extension, MPLS-TP can be identified through some
form of configuration, such as configuration which provides
an MPLS-TP compatible server layer to all LSPs arriving on a
specific interface or originating from a specific set of
ingress LSRs.
</t>
<t>
Alternately, the need for requirement MP#1 can be eliminated
if every MPLS-TP LSP created by an MPLS-TP ingress
makes use of an Entropy Label Indicator (ELI) and Entropy
Label (EL) below the MPLS-TP label
<xref target="RFC6790" />.
This would require that all MPLS-TP LSR in a deployment
support Entropy Label, which may render it impractical in
many deployments.
</t>
<!-- discussing this with Stewart
There are other encapsulations that can be safely added at
the MPLS-TP LSP ingress if Entropy Label encapsulation is
not supported. For example, MPLS-TP LSP ingress can add
Ethernet Pseudowire (PW) encapsulation. This is a higher
overhead solution, requiring an MPLS-TP LSP encapsulation,
an Ethernet PW encapsulation, plus an additional MPLS
encapsulation. MPLS-TP OAM could be applied to the outer
MPLS encapsulation, with the fixed label stack and PW
Control Word ensuring that a single path is followed. The
MPLS-TP OAM fate-sharing requirement will not be violated as
long as the ingress provide the full label stack on OAM
packets and any Generic Associated Channel Label (GAL) is
not used in the load balance at intermediate nodes.
-->
<t>
Some hardware which exists today can support requirement
MP#2. 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 LSPs and link bundling using the
all-ones component for MPLS LSPs. This prevents MPLS-TP LSPs
from being carried within MPLS LSPs but does allow the
coexistance of MPLS-TP and very large MPLS LSPs.
</t>
<t>
When Entropy Label Indicator (ELIs) and Entropy Labels (ELs)
are not 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 layer LSP
pushes an Entropy Label Indicator (ELI) and Entropy
Label (EL) below the server layer LSP label(s) in
the label stack, just above the MPLS-TP LSP label entry
<xref target="RFC6790" />. The value of EL can be 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-TP LSPs to be carried as client LSPs within MPLS
LSPs and satisfies MPLS-TP forwarding requirements but
requires that MPLS LSRs be able to identify MPLS-TP LSPs
(requirement MP#1).
</t>
<t>
MPLS-TP traffic can be protected from degraded performance
due to an imperfect load split if the MPLS-TP traffic is given
queuing priority (using strict priority and policing or
shaping at ingress or locally or weighted queuing locally).
This can be accomplished using the Traffic Class (TC) field and
Diffserv treatment of traffic
<xref target="RFC5462" /><xref target="RFC2475" />. In the
event of congestion due to load imbalance, only
non-prioritized traffic will suffer as long as there is a
low percentage of prioritized traffic.
</t>
<t>
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 balancing is not required, or if MPLS-TP
LSPs use Traffic Class (TC) and Diffserv and the load rebalancing
implementation rebalances only the less preferred traffic.
Load rebalance is generally needed only when congestion
occurs, therefore restricting MPLS-TP to be carried only
over MPLS LSPs that are known to traverse only links which
are expected to be uncongested can satisfy requirement MP#3.
</t>
<t>
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 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 LSP must be the top level LSP,
except as noted above.
</t>
<t>
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 can be used with no restrictions on the
server layer MPLS use of multipath except that Entropy Label
must be supported along 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, except during
very infrequent transitions due to load balancing.
Since the Entropy Label Indicator and Entropy Label are
always placed above the Generic Associated Channel Label
(GAL) in the stack, the presence of GAL will not affect the
selection of a component link as long as the LSR does not
hash on the label stack entries below the Entropy Label.
</t>
<t>
An MPLS-TP LSP may not traverse multipath links on the path
where MPLS-TP forwarding requirements cannot be met. Such
links include any using pre- RFC 6790 Ethernet Link
Aggregation, pre- RFC 6790 Link Bundling using the all-ones
component link, or other form of multipath not supporting
termination of the entropy search at the EL as called for in
<xref target="RFC6790" />. An MPLS-TP LSP MUST NOT traverse
a server layer MPLS LSP which traverses any form of
multipath not supporting termination of the entropy search
at the EL. For this to occur, the MPLS-TP ingress LSR MUST
be aware of these links. This is the reason for requirement
MP#4.
</t>
<t>
Requirement MP#4 can be supported using administrative
attributes. Administrative attributes are defined in
<xref target="RFC3209" />. Some configuration is required to
support this.
</t>
<t>
In MPLS Link Bundling the requirement for bidirectional
co-routing can be interpreted as meaning that the same set
of LSR must be traversed or can be interpreted to mean that
the same set of component links must be traversed
<xref target="RFC4201" /><xref target="RFC3473" />.
Following the 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 labels are created in each
direction.
</t>
<t>
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-TP LSP over bidirectional co-routed
MPLS LSP can make use of administrative attributes [RFC3209]
to ensure that this occurs. If MPLS-TP are carried by
unidirectional MPLS LSP, the MPLS-TP OAM will be unaffected
as only the MPLS LSP endpoints will appear as MPLS-TP OAM
Maintenance Entity Group Intermediate Points (MIPs).
</t>
<t>
Two methods of adding an Entropy Label are described above.
The MPLS-TP ingress must have a means to determine which
links can support MPLS-TP in selecting a path (MP#4).
Administrative attributes can satisfy that requirement. If
the MPLS-TP LSR is capable of adding ELI/EL to the label
stack, this method is preferred. However equipment furthest
from a provider's network 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 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 require MPLS-TP treatment. There are numerous
ways to determine which client LSP are MPLS-TP LSP and which
are not. While this determination is out of scope and will
vary among deployments, configuration or the presence of
specific attribute affinities in RSVP-TE signaling are among
the likely means to do so.
</t>
</section>
</section>
<section anchor="sect.tp-server-layer"
title="MPLS-TP as a Server Layer for MPLS">
<t>
Carrying MPLS LSPs which are larger than a component link over
an MPLS-TP server layer requires that the large MPLS client
layer LSP be accommodated by multiple MPLS-TP server layer
LSPs. MPLS multipath can be used in the client layer MPLS.
</t>
<t>
Creating multiple MPLS-TP server layer LSPs places a greater
Incoming Label Map (ILM) scaling burden on the LSR. High
bandwidth MPLS cores with
a smaller amount of nodes have the greatest tendency to
require LSPs in excess of component links, therefore the
reduction in the number of nodes offsets the impact of increasing
the number of server layer LSPs in parallel. Today, only in
cases where deployed LSR ILMs are small would this be an issue.
</t>
<t>
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
efficiency of carrying the MPLS client layer. The service
which provides by far the largest offered load in provider
networks is Internet, for which the LSP capacity reservations
are predictions of expected load. Many of these MPLS LSPs may
be smaller than component link capacity. Using MPLS-TP as a
server layer results in bin packing problems for these smaller
LSPs. For those LSPs that are larger than component link
capacity, the LSP capacities need not be (and often are not)
integer multiples of convenient
capacity increments such as 10 Gb/s. Using MPLS-TP as an
underlying server layer greatly reduces the ability of the
client layer MPLS LSPs to share capacity. For example, when
one MPLS LSP is underutilizing its predicted capacity, the
fixed allocation of MPLS-TP to component 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
resources and may result in a less cost effective network.
</t>
<t>
No additional requirements beyond MPLS-TP as it is now
currently defined are required to support MPLS-TP as a server
layer for MPLS. It is therefore viable but has some
undesirable characteristics discussed above.
</t>
</section>
<section title="Summary">
<t>
MPLS equipment deployed in the core currently supports
multipath. For large service providers, core LSR must support
some form of multipath to be deployable. Deployed MPLS access
and edge equipment is often oblivious to the use of multipath
in the core. It is expected that at least first generation
MPLS-TP equipment will be oblivious to the use of multipath in
the core. This first generation MPLS-TP equipment is
deployable in a core using multipath, with no adverse impact
to RSVP-TE signaling, if the edge equipment can 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 indicates a particular attribute affinity or can identify
client MPLS-TP LSP through some other means.
</t>
<t>
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 equipment and some edge equipment can configure
an MPLS Link Bundle [RFC4201] over multiple component links
where the component links are themselves MPLS LSP. This
existing capability can be used to carry large MPLS LSP and
overcome the limited capacity of any single server layer
MPLS-TP LSP.
</t>
<t>
MPLS OAM and MPLS-TP OAM are unaffected in the following cases
proposed in this document:
<list style="numbers">
<t>
Where MPLS is carried over a single MPLS-TP all traffic
flows on one link, MPLS OAM is unaffected and need not use
multipath support in LSP Ping <xref target="RFC4379" />.
</t>
<t>
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 this case MPLS-TP OAM is unaffected.
</t>
<t>
Where MPLS is carried over MPLS (an existing case) or over
multiple MPLS-TP, the multipath support in LSP Ping is used
and LSP Ping operation is unaffected
<xref target="RFC4379" /><xref target="RFC6425" />.
</t>
</list>
</t>
</section>
<!-- Possibly an Acknowledgements or a 'Contributors' section ... -->
<section title="Acknowledgements">
<t>
Carlos Pignataro, Dave Allan, and Mach Chen provided valuable
comments and suggestions. Carlos suggested that MPLS-TP
requirements in RFC 5960 be explicitly referenced or quoted.
An email conversation with Dave led to the inclusion of
references and quotes from RFC 6371 and RFC 6374. Mach made
suggestions to improve clarity of the document.
</t>
</section>
<section title="Implementation Status">
<t>
Note: this section is temporary and supports the experiment
called for in draft-sheffer-running-code.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="sect.iana" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="sect.security" title="Security Considerations">
<t>
This document specifies use of existing MPLS and MPLS-TP
mechanisms to support MPLS and MPLS-TP as client and server
layers for each other. This use of existing mechanisms
supports coexistence of MPLS/GMPLS (without MPLS-TP) when used
over a
packet network, MPLS-TP, and multipath. The combination of
MPLS, MPLS-TP, and multipath does not introduce any new
security threats. The security considerations for MPLS/GMPLS
and for MPLS-TP are documented in <xref target="RFC5920" />
and <xref target="RFC6941" />.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5654;
&RFC5960;
&RFC6371;
&RFC6374;
&RFC6790;
</references>
<references title="Informative References">
&RFC2475;
&RFC3209;
&RFC3473;
&RFC4201;
&RFC4206;
&RFC4379;
&RFC5286;
&RFC5462;
&RFC5714;
&RFC5920;
&RFC6425;
&RFC6941;
&I-D.ietf-rtgwg-cl-requirement;
<reference anchor="IEEE-802.1AX"
target="http://standards.ieee.org/getieee802/download/802.1AX-2008.pdf">
<front>
<title>IEEE Std 802.1AX-2008 IEEE Standard for
Local and Metropolitan Area Networks - Link Aggregation</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2006" />
</front>
</reference>
<reference anchor="ITU-T.G.800"
target="http://www.itu.int/rec/T-REC-G/recommendation.asp?parent=T-REC-G.800">
<front>
<title>Unified functional architecture of transport
networks</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2007" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:08:25 |