One document matched: draft-weingarten-mpls-tp-ring-protection-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-weingarten-mpls-tp-ring-protection-01.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="MPLS-TP LP">MPLS-TP Ring Protection</title>
<author fullname="Stewart Bryant" initials="S." role="editor"
surname="Bryant">
<organization>Cisco</organization>
<address>
<postal>
<street />
<region />
<code />
<country>United Kingdom</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Nurit Sprecher" initials="N." role="editor" surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region />
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Yaacov Weingarten" initials="Y." role="" surname="Weingarten">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region />
<code>45241</code>
<country>Israel</country>
</postal>
<email>yaacov.weingarten@nsn.com</email>
<phone>+972-9-775 1827</phone>
</address>
</author>
<date year="2009" />
<abstract>
<t>This document describes mechanisms to address the requirements for protection of
ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label
Switched Paths (LSP) and Pseudowires (PW) on multiple layers. Ring topologies offer
the possibility of reducing the OAM overhead while providing a simplified protection
mechanism. The document analyzes two basic ring protection schemes and explains how
ring protection can be viewed as an application of linear protection.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Multi-Protocol Label Switching Transport Profile (MPLS-TP) is being standardized
as part of a joint effort between the Internet Engineering Task Force (IETF) and the
International Telecommunication Union Standardization (ITU-T). These specifications
are based on the requirements that were generated from this joint effort.</t>
<t>The requirements for MPLS-TP <xref target="MPLS-TP Reqs" /> inidcates that there
is requirement to support a network that may include sections that constitute a
MPLS-TP ring (either logical or physical). The support for ring topologies as stated
in the requirements is based on the ability to demonstrate that this topology allows
the network to optimize either the protection or the number of Operations,
Administration & Maintenance (OAM) entities needed to maintain the network.</t>
<t>This document will examine different proposed mechanisms for protection of a ring
in the context of MPLS-TP and try and determine how they may optimize the protection
and the OAM procedures for a ring topology. Finally, we plan to show how the generic
protection mechanisms can be used to address the requirements in an optimized manner.
</t>
<section title="Contributing Authors">
<t>Akira Sakurai (NEC), Rolf Winter (NEC)</t>
</section>
</section>
<section title="Ring Topologies">
<t>The MPLS-TP Requirements <xref target="MPLS-TP Reqs" /> defines a ring as a
topology in which each LSR is connected to exactly two neighboring LSRs, each via
a single point-to-point birectional MPLS-TP capable link. A ring provides certain
advantages in transport networks, including:</t>
<list style="symbols">
<t>Configuration of point-to-multipoint paths around a ring are easily
accomplished.</t>
<t>There are always two paths between any two LSRs on a ring that can be easily
identified and associated.</t>
<t>It is believed that the number of OAM entities needed, in order to detect faults
and perform recovery actions, may be minimized in a ring topology.</t>
</list>
<t>The following figure shows a MPLS-TP ring that is a segment that may be traversed
by numerous LSPs or PWs. In particular, the figure shows that for all LSP that
connect to the ring through LSR-B and exit the ring from LSR-F we can define two
paths through the ring (the first path along B-A-F, and the second B-C-D-E-F).</t>
<figure anchor="figure 1" title="A MPLS-TP ring">
<artwork>
____
=========>/ LSR\
* \__B_/ *
* @ # *
* @ # *
__* @ # *___
/LSR\ @ #/LSR\
\_C_/ @ #\_A_/
* @ # *
* @ #*
_*_ @ #*_
/LSR\@ /LSR\========>
\_D_/@ \_F_/
* @ @*
* @ @*
* @@____@@*
*/ LSR\*
\__E_/
===> connected LSP *** physical link
### logical path @@@ secondary logical path
</artwork>
</figure>
<section title="Interconnected rings">
<t>The Requirements document <xref target="MPLS-TP Reqs" /> states that the ring protection
must support a single ring that may be interconnected to other rings. In addition, traffic
that traverses a number of rings within a network of interconnected rings must be protected
even if the interconnection nodes and links fail.</t>
<t>When interconnecting rings in a network there are two common interconnection schemes:</t>
<list style="symbols">
<t>Dual-node interconnect – when the interconnected rings are interconnected by
two nodes from each ring (see <xref target="figure 2" />)</t>
<t>Single-node interconnect – when the connection between the interconnected rings
are through a single node (see <xref target="figure 3" />)</t>
</list>
<t>The protection schemes presented in <xref target="section 3" /> are capable of protecting each
interconnected ring as a separate entity independent of the other rings in the network.
This protects the traffic that traverses the entire network, as each ring will continue
to transfer the traffic to the interconnection points, and from there to the next ring.</t>
<t>When the interconnection nodes or links fail, there is the need to protect these
connection points. Therefore, it should be noted that in the case of single-node
interconnect the interconnection node (LSR-A in <xref target="figure 3" />) is a
single-point of failure and such an interconnection scheme should be avoided. The
protection of the dual-node interconnect is essentially a linear-protection situation
and should be protected using appropriate protection mechanisms.</t>
<figure anchor="figure 2" title="Dual-node interconnected rings">
<artwork>
____ ___
/ LSR\ /LSR\
* \__B_/ * *\_1_/*
* * * *
* * * *
__* *___ _*_ * ___
/LSR\ /LSR\****/LSR\ /LSR\
\_C_/ \_A_/ \_6_/ \_2_/
* Ring #1 * * Ring #2 *
* * * *
_*_ *_ _*_ _*_
/LSR\ /LSR\ /LSR\ /LSR\
\_D_/ \_F_/****\_5_/ \_3_/
* * * *
* * * *
* ____ * * ____ *
*/ LSR\* */LSR \*
\__E_/ \__4_/
*** physical link
</artwork>
</figure>
<figure anchor="figure 3" title="Single-node interconnected rings">
<artwork>
____ ___
/ LSR\ /LSR\
* \__B_/ * *\_1_/*
* * * *
* * * *
__* *___ * * ___
/LSR\ /LSR\* /LSR\
\_C_/ \_A_/ \_2_/
* Ring #1 * * Ring #2 *
* * * *
_*_ _*_ * ___ _*_
/LSR\ /LSR\ */LSR\ /LSR\
\_D_/ \_F_/ \_5_/ \_3_/
* * * *
* * * *
* ____ * *___ *
*/ LSR\* /LSR\*
\__E_/ \_4_/
*** physical link
</artwork>
</figure>
</section>
</section>
<section anchor="section 3" title="Ring protection schemes">
<t>There are two classic mechanisms that have been proposed in various forums
to perform recovery of a topological ring network - "wrapping" and
"steering". The following sub-sections will examine these two
mechanisms.</t>
<section title="Wrapping">
<t>The "easier" recovery architecture is "wrapping". This
mechanism is local to the LSRs that are neighbors to the detected fault. When
a fault is detected, the neighboring LSR "wrap" all data traffic around the ring
until arriving at the LSR that is on the opposite side of the fault, at which
point the traffic continues on the normal working path until the egress from
the ring segment.</t>
<figure anchor="figure 4" title="Wrapping protection">
<artwork>
____
=========>/ LSR\
* \__B_/ *
* @@@@@@@# *
* @ @# *
___* @ @# *___
/LSR\ @ @#/LSR\
\_C_/ @ #\_A_/
* @ # *
* @ XX
_*_ @ #*_
/LSR\@ /LSR\
\_D_/@ @\_F_/
* @ @#*
* @ @@#*
* @@____@##*
*/ LSR\*
\__E_/========>
===> connected LSP *** physical link
### logical path @@@ Bypass tunnel
</artwork>
</figure>
<t>In this figure we have a ring with a LSP that enters the ring at LSR-B and
exits at LSR-E. The normal working path follows through B-A-F-E. If a signal
fault is detected on the link A<—>F, then there is the need for
configuring a bypass tunnel <xref target="FRR" /> between A & F. The traffic will be
transmitted over this bypass tunnel from A to F, and then will continue on
the normal working path from F->E. Essentially, in this protection scheme,
the traffic will follow the path - B-A-B-C-D-E-F-E.</t>
<t>This protection scheme is simple in the sense that there is no need for
coordination between the different LSR in the ring - only the LSRs that detect
the fault must wrap the traffic, either via the bypass tunnel (at the near-end)
or back to the normal path (at the far-end).</t>
<t>When applying this scheme to a MPLS-TP ring topology segment there are the
following considerations:</t>
<list style="symbols">
<t>The OAM should be performed at either the link level (by defining a TCME
between each adjacent pair of LSR) and/or per LSR (by defining a TCME between
the LSR that are neighbors of the protected LSR) when using node-level
protection.</t>
<t>For each protected TCME there is a need to define a bypass tunnel that
traverses the alternate path around the ring to connect between the two ends
of the TCME. If protecting both the links and the nodes, then, for a ring
with N nodes, there is a need for O(2N) bypass tunnels.</t>
<t>Protection of point-to-multipoint paths is similar to the simple protection
since the data continues along the original path after wrapping around the
ring. The one exception is the case where the failed node was one of the
egress points for the data.</t>
<t>When wrapping the data is transmitted over some of the links twice, once
in each direction. For example, in the figure above the traffic is transmitted
both B—>A and then A—>B, later it is transmitted E—>F
and F—>E. This means that there is additional bandwith needed for
this protection.</t>
<t>The wrapping also involves greater latency in delivering the packets, as a
result of traversing the entire ring.</t>
<t>The resource allocation for the bypass tunnels could be problematic, since
most of the tunnels will not be used simultaneously. One possibility could be
to allocate '0' resources and depend on the NMS to allocate the
proper resources around the ring.</t>
</list>
<section title="Optimization of wrapping">
<t>It may be possible to optimize the basic performance, in terms of bandwidth
utilization, of the Fast-reroute mechanism when protecting particular LSPs. However,
it is important to consider the basic criteria for ring protection, i.e. an
appreciable minimization of the number of OAM sessions necessarily or the protection
resources needed.</t>
<t>One suggestion for optimization is to define the bypass tunnel to wrap only
until the furthest egress point of the working LSP. This method reduces the number
of links that are traversed twice, in most cases, by not wrapping back to the working
path at the far-end of the signal fault. However, the method requires defining a
particular bypass tunnel for each LSP and cannot use the optimization of the OAM
sessions presented above to protect all LSPs with a single set of bypass LSPs.</t>
</section>
</section>
<section title="Steering">
<t>The second common scheme for ring protection redirects the traffic from the
ingress point to the alternate route around the ring to the egress point. This
is illustrated in Figure 1 above, where if a Signal Fault is detected on the
working path (B-A-F), then the traffic is redirected by B to the secondary
path (i.e. B-C-D-E-F).</t>
<t>When considering this mechanism it is almost identical to linear 1:1
protection. The two paths around the ring act as the working and recovery
paths. There is need to communicate to the ingress node the need to switch
over to the protection path and there is a need to coordinate the switchover
between the two end-points of the protected path.</t>
<t>There is one aspect that this diverts from the basic linear protection
scheme - in the number of OAM sessions that would be neccesary to detect faults
in the protected domain. Whereas, using generic linear protection would
neccesitate a separate OAM session per LSP that traverses the ring, when using
ring protection there is a possiblity of taking proper advantage of the
realization that we are dealing with a ring, and reduce the number of OAM
sessions. This is done by defining an OAM session on the basis of a Path Segment
Tunnel (PST), i.e. between any two nodes of the ring. This would lead to the number
of OAM sessions for a ring with N nodes to be O(N*N/2), which could be very
large. However, taking into consideration that the required support of
rings, is for rings with up-to 16 nodes - this implies that the number of
OAM sessions should be on the order of (16*16/2) or 128.</t>
<t>This form of OAM would allow the ingress LSR to directly detect any faulty
situations and redirect traffic to the secondary path without the need for
any additional communication to the LSR.</t>
<t>The following observations can be drawn from using this protection
mechanism for MPLS-TP ring topologies:</t>
<list style="symbols">
<t>Steering can be based on linear protection for the protection of a single
ring. For cases of interconnected rings further study is necessary.</t>
<t>The number of OAM sessions can be greatly minimized, relative to using plain
linear protection, by running the OAM sessions on the ring segments for
all LSPs that traverse the ring, rather than running a OAM session per
LSP. This fulfills the objective presented in [MPLS-TP Reqs].</t>
</list>
<section title="Point-to-Multipoint paths">
<t><xref target="MPLS-TP Reqs"/> requires that ring protection must provide
protection for unidirectional point-to-multipoint paths through the ring. As
was pointed out in section 1, ring topologies provide a ready platform for
supporting such data paths.</t>
<t>It is possible to create a protection architecture for p2mp within a MPLS-TP
ring topology, based on 1+1 linear protection by monitoring two p2mp uni-directional
PST from each ingress node on the ring with egress points at each node. The two
PST traverse the ring in opposite directions, i.e. one checks the clockwise path
and the second the counter-clockwise path.</t>
<t>The data for a particular p2mp LSP is transmitted on both the working and
protecting LSP, using a permanent bridge. While each node detects that there is
connectivity from the ingress point, it continues to select the data that is
coming from the working path. If a particular node stops receiving the
connectivity messages from the working path PST, it identifies that it must
switch its selector to read the data from the protecting path.</t>
<t>This architecture has the added advantages that there is no need for the
ingress node to identify the existence of the misconnectivity, and there is no
need for a return path from the egress points to the ingress.</t>
</section>
</section>
</section>
<section title="Conclusions and Recommendations">
<t>In order to fulfill the requirements for protection of ring topologies for
MPLS-TP networks, according to the conditions stated in [MPLS-TP Reqs], the
protection should be based on MPLS-TP 1:1 linear protection. This mechanism
will cover the cases of a single fault in a single ring topology.</t>
<t>When defining the OAM behavior of the ring nodes, they should define a
segment of all the LSPs that traverse a path within the ring. The OAM
should be executed for each ring path, i.e. PST, to detect faults and trigger
the protection switching within the ring.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not by itself raise any particular security
considerations.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the T-MPLS
Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS
Transport Profile.</t>
</section>
</middle>
<back>
<references title="Informative References">
<!--Begin inclusion reference.RFC.4090 -->
<reference anchor="FRR">
<front>
<title>Fast Reroute Exensions to RSVP-TE for LSP Tunnels</title>
<author initials="P." surname="Pan" fullname="P.Pan">
<organization />
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization />
</author>
<author initials="A." surname="Atlas" fullname="A.Atlas">
<organization />
</author>
<date year="2005" month="May" />
<abstract>
<t>This document defines RSVP-TE extensions to establish backup label
switched path (LSP) tunnels for local repair of LSP tunnels. These
mechanisms enable the re-direction of traffic onto backup LSP tunnels
in 10s of milliseconds, in the event of a failure.</t>
<t>Two methods are defined here. The one-to-one backup method creates
detour LSPs for each protected LSP at each potential point of local
repair. The facility backup method creates a bypass tunnel to protect
a potential failure point; by taking advantage of MPLS label stacking,
this bypass tunnel can protect a set of LSPs that have similar backup
constraints. Both methods can be used to protect links and nodes during
network failure. The described behavior and extensions to RSVP allow
nodes to implement either method or both and to interoperate in a
mixed network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4090" />
<format type="TXT" octets="116872" target="ftp://ftp.isi.edu/in-notes/rfc4090.txt" />
</reference>
<!-- End inclusion reference.RFC.4090 -->
<!-- Begin inclusion reference.draft.MPLS.TP.Reqs -->
<reference anchor="MPLS-TP Reqs">
<front>
<title>Requirements for the Transport Profile of MPLS</title>
<author initials="B." surname="Niven-Jenkins" fullname="Ben Niven-Jenkins">
<organization />
</author>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization />
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization />
</author>
<date year="2009" month="April" />
<abstract>
<t>Lists the requirements for MPLS-TP with cross reference </t>
</abstract>
</front>
<seriesInfo name="RFC" value="5654" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Reqs -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:30:02 |