One document matched: draft-weingarten-mpls-tp-ring-protection-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!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-02.txt"
ipr="trust200902">
<front>
<title abbrev="MPLS-TP LP">MPLS-TP Ring Protection</title>
<author fullname="Yaacov Weingarten" initials="Y." role="editor"
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>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<region></region>
<code></code>
<country>United Kingdom</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region></region>
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Danielle Ceccarelli" initials="D." role="editor"
surname="Ceccarelli">
<organization>Ericsson</organization>
<address>
<postal>
<street>Via A. Negrone 1/A</street>
<city>Genova</city>
<region>Sestri Ponente</region>
<code></code>
<country>Italy</country>
</postal>
<email>daniele.ceccarelli@ericsson.com</email>
</address>
</author>
<author fullname="Diego Caviglia" initials="D." surname="Caviglia">
<organization>Ericsson</organization>
<address>
<postal>
<street>Via A. Negrone 1/A</street>
<city>Genova</city>
<region>Sestri Ponente</region>
<code></code>
<country>Italy</country>
</postal>
<email>diego.caviglia@ericsson.com</email>
</address>
</author>
<author fullname="Francesco Fondelli" initials="F." surname="Fondelli">
<organization>Ericsson</organization>
<address>
<postal>
<street>Via A. Negrone 1/A</street>
<city>Genova</city>
<region>Sestri Ponente</region>
<code></code>
<country>Italy</country>
</postal>
<email>francesco.fondelli@ericsson.com</email>
</address>
</author>
<author fullname="Marco Corsi" initials="M." surname="Corsi">
<organization>Altran</organization>
<address>
<postal>
<street>Via A. Negrone 1/A</street>
<city>Genova</city>
<region>Sestri Ponente</region>
<code></code>
<country>Italy</country>
</postal>
<email>marco.corsi@altran.it</email>
</address>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>4F,RD Building 2,Zijinghua Road</street>
<city>Nanjing</city>
<region>Yuhuatai District</region>
<code></code>
<country>P.R.China</country>
</postal>
<email>wu.bo@zte.com.cn</email>
</address>
</author>
<author fullname="Xuehui Dai" initials="X." surname="Dai">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>4F,RD Building 2,Zijinghua Road</street>
<city>Nanjing</city>
<region>Yuhuatai District</region>
<code></code>
<country>P.R.China</country>
</postal>
<email>dai.xuehui@zte.com.cn</email>
</address>
</author>
<date year="2009" />
<abstract>
<t>This document presents an applicability statement to address the
requirements for protection of ring topologies for Multi-Protocol Label
Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on
multiple layers. The MPLS-TP Requirements document <xref
target="TPReqs"></xref> specifies specific criteria for justification of
dedicated protection mechanism for particular topologies, including
optimizing the number of OAM entities needed, minimizing the number of
labels for protection paths, minimzing the number of recovery elements
in the network, and minimizing the number of control and management
transactions necessary. The document proposes a methodology for ring
protection based on existing MPLS-TP survivability mechanisms, without
the need of specification of new constructs or protocols.</t>
<t>This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.</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="TPReqs"></xref> indicates
a requirement to support a network that may include sub-networks that
constitute a MPLS-TP ring as defined in the requirements. There were no
requirements specific to a ring topology indicated in the requirements
document. However, the requirements state that specific protection
mechanisms aimed at ring topologies may be developed if these allow the
network to optimize:</t>
<t><list style="symbols">
<t>Number of OAM entities needed to trigger the protection</t>
<t>Number of recovery objects needed</t>
<t>Number of labels required</t>
<t>Number of control and management plane transactions during a
recovery operation</t>
<t>Impact of signaling and routing information exchanged, in
presence of control plane</t>
</list></t>
<t>This document will propose a set of basic mechanisms that could be
used for the protection of the data flows that traverse a MPLS-TP ring.
The mechanism is based on existing MPLS and MPLS-TP protection
mechanisms. We show that this mechanism provides the ability to protect
all of the basic conditions within a reasonable time frame and does
optimize the criteria set out in <xref target="TPReqs"></xref> as
summarized above.</t>
<section title="Problem statement">
<t>Ring topologies, as definied in <xref target="TPReqs"></xref>, are
used in transport networks due to their ability to easily support both
p2p and p2mp transport paths. When designing a protection mechanism
for a ring topology, there is a need to address both</t>
<t><list style="numbers">
<t>the simple case of a transport path that enters a MPLS-TP
capable ring at one node, the ingress node, and exits the ring at
a single egress node possibly continuing beyond the ring.</t>
<t>the case where the ring is being used as a branching point,
i.e. the transport path enters the MPLS-TP capable ring at the
ingress node and exits through a number of egress nodes, possibly
continuing beyond the ring.</t>
</list>Within the ring segment of the transport path there is the
need to address the following different cases -</t>
<t><list style="numbers">
<t>one of the ring links causes a fault condition. This could be
either a unidirectional or bidirectional fault, and should be
detected by the neighboring nodes.</t>
<t>one of the ring nodes causes a fault condition. This condition
is invariably a bidirectional fault (although in rare cases of
misconfiguration this could be detected as a unidirectional fault)
and should be detected by the two neighboring ring nodes.</t>
<t>administrator command is issued to a specific ring node. These
commands include a Manual Switch, Forced Switch, or Clear
operation.</t>
</list>The protection domain that will be addressed in this document
is limited to the traffic that is traversing the ring. Traffic on the
transport path prior to the ring ingress node or beyond the egress
nodes may be protected by some other mechanism.</t>
</section>
<section title="Terminology and Notation">
<t>The terminology used in this document is based on the terminology
defined in the MPLS-TP framework documents:</t>
<t><list style="symbols">
<t>MPLS-TP Framework<xref target="TPFwk"></xref></t>
<t>MPLS-TP OAM Framework<xref target="OAMFwk"></xref></t>
<t>MPLS-TP Survivability Framework<xref
target="SurvivFwk"></xref></t>
</list></t>
<t>In addition, we describe the use of the label stack in connection
with the redirecting of data packets by the protection mechanism. The
following syntax will be used to describe the contents of the label
stack:</t>
<t><list style="numbers">
<t>The label stack will be enclosed in square brackets ("[]")</t>
<t>Each level in the stack will be separated by the '|'
character</t>
<t>The bottom of the stack will be denoted by the string "BOS"</t>
<t>The label of an ingress LSP will be denoted by the string "LI"
and the label of the egress LSP will be denoted by the string
"LE"</t>
<t>The label for a PST will be denoted by Px(y) where x and y are
LSR identifiers and the intention is to the label for LSR-x to
transmit to LSR-y over the PST.</t>
</list></t>
<t>For example - the label stack [PB(G)|LI|BOS] denotes a stack whose
top-label is the PST label for LSR-B to transmit the data packet to
LSR-G, the packet originated from a LSP that arrived at the ring with
label LI.</t>
</section>
<section title="Contributing Authors">
<t>Akira Sakurai (NEC), Rolf Winter (NEC)</t>
</section>
</section>
<section anchor="sec2" title="P2P Ring Protection">
<t>Classically there are two protection architecture mechanisms for ring
topologies, based on SDH specifications <xref target="G.841"></xref>,
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>Wrapping is defined as a "local" protection architecture. This
mechanism is local to the LSRs that are neighbors to the detected
fault. When a fault is detected (either a link or node failure), the
neighboring LSR can identify that the fault would prevent forwarding
of the data along the data path. Therefore, in order to continue the
data along the path, there is need to "wrap" all data traffic around
the ring, on an alternate data path, until arriving at the LSR that is
on the opposite side of the fault. When this LSR also detects that
there is a fault condition on the LSP, it can identify that the data
traffic that is arriving on the alternate (protecting) data path is
intended for the "broken" LSP. Therefore, again taking a local
decision can wrap the data back onto the normal working path until the
egress from the ring segment.</t>
<figure anchor="figure1" title="Wrapping protection for p2p path">
<artwork><![CDATA[
____
=========>/ LSR\
* \__B_/ *
* @@@@@@@# *
* @ @# *
___* @ @# *___
/LSR\ @ @#/LSR\
\_C_/ @ #\_A_/
* @ # *
* @ XX
_*_ @ #*_
/LSR\@ /LSR\
\_D_/@ @\_F_/
* @ @#*
* @ @@#*
* @@____@##*
*/ LSR\*
\__E_/========>
===> connected LSP *** physical link
### working path @@@ wrapped data path
]]></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 the wrapping mechanism decides that LSR-A would wrap the traffic
around the ring, on a wrapped data path A-B-C-D-E-F, to arrive at
LSR-F (on the far side of the failed link). LSR-F would then wrap the
data packets back onto the working path F—>E to the egress
node. 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 onto the
wrapped data path (at the near-end) or back to the working path (at
the far-end). Coordination would only be needed to maintain co-routed
bidirectional traffic even in cases of a unidirectional fault
condition.</t>
<t>The following considerations should be taken into account when
considering use of wrapping protection:</t>
<t><list style="symbols">
<t>Detection of loss-of-continutiy or misconnectivity, should be
performed at the link level and/or per LSR when using node-level
protection. The configuration of the protection being performed
(either link protection or node protection) needs to be configured
a-priori, since the configuration of the proper protection path is
dependent upon this decision.</t>
<t>There is a need to define a data-path that traverses the
alternate path around the ring to connect between the two
neighbors of the detected fault. If protecting both the links and
the nodes of a LSP, then, for a ring with N nodes, there is a need
for O(2N) alternate paths.</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 resource allocation for the alternate-paths could be
problematic, since most of these alternate paths 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>
<t>Wrapping also involves greater latency in delivering the
packets, as a result of traversing the entire ring. This could be
very restrictive for large rings.</t>
</list></t>
</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 <xref target="figure2"></xref>,
where if a Signal Fault is detected on the working path (B-A-F), then
the traffic would be redirected by B to the alternate path (i.e.
B-C-D-E-F).</t>
<t>This mechanism is similar to linear 1:1 protection <xref
target="SurvivFwk"></xref>. 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 recovery path and there is
a need to coordinate the switchover between the two end-points of the
protected domain.</t>
<t>The following considerations must be taken into account regarding
the steering architecture:</t>
<t><list style="symbols">
<t>It is necessary for the ingress node to be "informed" of the
fault condition in order to perform the protection switching.</t>
<t>The process of "informing" the ingress node adds to the latency
of the protection switching process, after the detection of the
fault condition.</t>
<t>While there is no need for double bandwidth for the data path,
there is the necessity for the ring to maintain enough capacity
for all of the data in both directions around the ring.</t>
</list></t>
</section>
<section title="P2P ring protection with PST">
<t>The MPLS-TP Framework document <xref target="TPFwk"></xref> defines
a Path Segment Tunnel (PST) construct that can be defined between any
two LSRs of a MPLS-TP LSP. For MPLS-TP purposes, such a PST may be
configured as a bidirectional co-routed path. A PST may be used to
aggregate all LSP traffic that traverses the segment (from ingress LSR
to egress LSR) that is delineated by the PST. This PST may be
monitored using the OAM mechanisms as specified in the MPLS-TP OAM
Framework document <xref target="OAMFwk"></xref>.</t>
<t>When defining a MPLS-TP ring as a protection domain, there is a
need to design a protection mechanism that protects all the LSPs that
cross the MPLS-TP ring. For this purpose, we associate a (working) PST
with the segment of the transport path that traverses the ring. In
addition, we configure an alternate (protecting) PST that traverses
the ring in the opposite direction around the ring. The exact
selection of the two PSTs is dependent on the type of transport path
and protection that is being implemented and will be detailed in the
following sections.</t>
<t>Based on this architectural configuration for ring protection, it
is possible to restrict the number of alternate paths needed to
protect the data traversing the ring. Similarly, we can minimize the
number of OAM sessions needed to monitor the data traffic of the ring
- by monitoring the PSTs, rather than monitoring each individual
LSP.</t>
<t>The following figure shows a MPLS-TP ring that is part of a larger
MPLS-TP network. The ring could be used as a network segment that may
be traversed by numerous LSPs. In particular, the figure shows that
for all LSPs that connect to the ring at LSR-B and exit the ring from
LSR-F, we configure two PST through the ring (the first PST traverses
along B-A-F, and the second PST traverses B-C-D-E-F).</t>
<figure anchor="figure2" title="A MPLS-TP ring">
<artwork><![CDATA[
____
=========>/ LSR\
* \__B_/ *
* @ # *
* @ # *
__* @ # *___
/LSR\ @ #/LSR\
\_C_/ @ #\_A_/
* @ # *
* @ #*
_*_ @ #*_
/LSR\@ /LSR\========>
\_D_/@ \_F_/
* @ @*
* @ @*
* @@____@@*
*/ LSR\*
\__E_/
===> connected LSP *** physical link
### primary PST @@@ secondary PST
]]></artwork>
</figure>
<t>In all of the following subsections, we use 1:1 linear protection
<xref target="SurvivFwk"></xref> <xref target="LinProtect"></xref> to
perform protection switching and coordination when a signal fault is
detected. The actual configuration of the PSTs used may change
dependent upon the choice of methodology and this will be detailed in
the following sections. However, in all of these configurations the
mechanism will be to transmit the data traffic on the primary PST,
while using OAM functionlity to detect signal fault conditions on
either the primary or the secondary PST. If a signal fault is detected
on the primary PST, then the mechanism described in <xref
target="LinProtect"></xref> shall be used to coordinate a switch-over
of data traffic to the secondary PST.</t>
<t>Assuming that the PST is implemented as an hierarchial LSP, packets
that arrive at LSR-B with a label stack [L1|BOS] will have the PST
label pushed at LSR-B (i.e. the packet will arrive at LSR-A with a
label stack of [PA(F)|L1|BOS], arrive at LSR-F with [PF(F)|L1|BOS]).
The PST label will be popped by LSR-F and the LSP label will be
treated appropriately at LSR-F and forwarded along the LSP. This
scenario is true for all LSP that are aggregated by this primary
PST.</t>
<section title="Path PST for Steering">
<t></t>
<t>A p2p PST that traverses part of a ring has two Maintenance
Entity Group End Points (MEPs), each one acts as the ingress and
egress in one direction of the bidirectional PST. Since the PST is
traversing a ring we can take advantage of another characteristic of
a ring - there is always an alternative path between the two MEPs,
traversing the ring in the opposite direction. This alternative PST
can be defined as the protection path for the working path that is
configured as part of the LSP and defined as a PST.</t>
<t>For each pair of PSTs that are defined in this way, it is
possible to verify the connectivity and continuity by applying the
MPLS-TP OAM functionality to both the working and recovery PST. If a
discontinuity or mis-connectivity is detected then the MEPs will
become aware of this condition, and could perform a protection
switch of all LSPs to the alternate, recovery PST.</t>
<t>This protection mechanism is identical to application of 1:1
linear protection<xref format="default" target="SurvivFwk"></xref>
<xref target="LinProtect"></xref>to the pair of PSTs. Under normal
conditions, all LSP data traffic will be transmitted on the working
PST. If the linear protection is triggered, by either the OAM
indication, an other fault indication trigger, or an administrative
command, then the MEPs will select the recovery PST to transmit all
LSP data packets.</t>
<t>The recovery PST will continue to transmit the data packets until
the stable recovery of the fault condition. Upon recovery, the
ingress LSR could switch traffic back to the working PST, if the
protection domain is configured for revertive behavior.</t>
<t>The control of the protection switching, especially for cases of
administrative commands, would be covered by the protocol defined in
<xref target="LinProtect"></xref>.</t>
</section>
<section title="Wrapping with segment based PST">
<t>It is possible to use the PST mechanism to perform segment-based
protection. For each link in the ring, we define two PST - the first
is a PST between the two LSRs that are connected by the link, and
the second PST between these same two LSRs but traversing the entire
ring (except the link that connects the LSRs). In <xref
target="figure3"></xref> we show the primary PST that connects LSR-A
& LSR-F over a segment connection, and the secondary PST that
connects these same LSRs by traversing the ring in the opposite
direction.</t>
<figure anchor="figure3" title="Segment PSTs">
<artwork><![CDATA[
____
/ LSR\
* \__B_/ *
* @ @ *
* @ @ *
__* @ @ *___
/LSR\ @ @/LSR\
\_C_/ @ \_A_/
* @ #*
* @ #*
_*_ @ #*_
/LSR\@ /LSR\
\_D_/@ \_F_/
* @ @*
* @ @*
* @@____@@*
*/ LSR\*
\__E_/
*** physical link
### primary PST @@@ secondary PST
]]></artwork>
</figure>
<t>By applying OAM monitoring of these two PST (at each LSR), it is
possible to affect a wrapping protection mechanism for the LSP
traffic that traverses the ring. The LSR on either side of the
segment would identify that there is a fault condition on the link
and redirect all LSP traffic to the secondary PST. The traffic would
traverse the ring until arriving at the neighboring (relative to the
segment) LSR. At this point the LSP traffic would be redirected onto
the original LSP, quite likely over the neighboring PST.</t>
<t>Following the progression of the label stack through this
switching operation:</t>
<t><list style="numbers">
<t>The data packet arrives at LSR-A with label stack [LI|BOS]
(i.e. top label from the LSP and bottom-of-stack indicator)</t>
<t>In the normal case (no switching), LSR-A forwards the packet
with label stack [PA1(F)|LI|BOS] (i.e. push the label for the
primary PST from LSR-A to LSR-F).</t>
<t>When switching is in-effect, LSR-A forwards the packet with
label stack [PA2(F)|LI|BOS] (i.e. LSR-A pushed the label for the
secondary PST from LSR-A to LSR-F).</t>
<t>When the packet arrives at LSR-F, it will pop the PST label,
process the LSP label, and forward the packet to the next point,
possibly pushing a PST label if the next segment is likewise
protected.</t>
</list></t>
</section>
<section title="Wrapping node protection">
<t>Implementation of protection at the node level would be similar
to the mechanism described in the previous sub-section. The
difference would be in the PSTs that are used. For node protection,
the primary PST would be configured between the two LSR that are
connected to the node that is being protected (see PST between LSR-A
and LSR-E through LSR-F in <xref target="figure4"></xref>), and the
secondary PST would be configured between these same nodes, going
around the ring (see secondary PST in <xref
target="figure4"></xref>).</t>
<figure anchor="figure4" title="Node-protection PSTs">
<artwork><![CDATA[
____
/ LSR\
* \__B_/ *
* @ @ *
* @ @ *
__* @ @ *___
/LSR\ @ @/LSR\
\_C_/ @ \_A_/
* @ #*
* @ #*
_*_ @ #*_
/LSR\@ /LSR\
\_D_/@ \_F_/
* @ # *
* @ # *
* @@____ # *
*/ LSR\#*
\__E_/
*** physical link
### primary PST @@@ secondary PST
]]></artwork>
</figure>
<t>The protection mechanism would work similarly - based on 1:1
linear protection <xref target="SurvivFwk"></xref>, triggered by OAM
functions on both PSTs, and wrapping the data packets onto the
secondary PST at the ingress MEP (e.g. LSR-A in the figure) of the
PST and back onto the continuation of the LSP at the egress MEP
(e.g. LSR-E in the figure) of the PST.</t>
</section>
<section title="Wrapping for link and node protection">
<t>In the different types of wrapping presented in sections 2.3.2
and 2.3.3, there is a limitation that the protection mechanism must
a priori decide whether it is protecting for link or node failure.
In addition, the neighboring LSR, that detects the fault, cannot
readily differentiate between a link failure or a node failure.</t>
<t>It is possible to combine the link protection mechanism presented
in section 2.3.2 with the protection mechanism of section 2.3.3 to
give more complete coverage. For each segment, we configure both a
secondary link protection PST as well as a two secondary node
protection PST [one for each direction of the bidirectional segment
PST] (see <xref target="figure5"></xref>). When a protection switch
is triggered, the ingress LSR of the segment will examine the packet
ring destination. Only if this destination is for the LSR connected
to the secondary link PST, then the packets will be wrapped onto
this secondary PST. For all other cases, the data packets will be
wrapped onto the secondary node PST. In all cases the egress LSR for
the secondary PST will wrap the data traffic back onto the working
LSP/PST.</t>
<figure anchor="figure5" title="Segment & Node protection PSTs">
<artwork><![CDATA[
____
/ LSR\
* \__B_/ *
* @+$ +@ *
* @+$ +@ *
__* @+$ +@ *___
/LSR\ @+$ +@/LSR\
\_C_/ @+$ \_A_/
* @+$ #*
* @+$ #*
_*_ @+$ #*_
/LSR\@+$ /LSR\
\_D_/@+$ \_F_/
* @+$ $+*
* @+$ $+*
* @++$+$+$+*
*/ LSR\*
\__E_/
*** physical link
### primary PST @@@ secondary node#1 PST
$$$ secondary node#2 PST +++ secondary segment PST
]]></artwork>
</figure>
</section>
</section>
<section title="Analysis of p2p protection">
<t>Analyzing the mechanisms described in the above subsections we can
point to the following observations (based on a ring with N
nodes):</t>
<t><list style="symbols">
<t>Number of PST that need to be configured – for path PST
(sec 2.3.1) = O(2N^2) [two PST from each ingress LSR to each other
node in the ring], for segment PST (sec 2.3.4) = O(4N) [four PST
for each link in the ring]</t>
<t>Number of OAM sessions at each node – for path PST =
O(2N), for segment PST = 4</t>
<t>Bandwidth requirements – for path PST: single bandwidth
at each link, for segment PST: double bandwidth at links that are
between ingress and wrapping node and between second wrapping node
and egress.</t>
<t>Special considerations – for path PST: latency of OAM
detection of fault condition by ingress MEP [using Alarm-reporting
could optimize over using CC-V only], for segment PST: need to
examine data packet ring destination before selecting bypass
PST.</t>
</list></t>
</section>
</section>
<section title="P2MP protection">
<t><xref target="TPReqs"></xref> requires that ring protection must
provide protection for unidirectional point-to-multipoint paths through
the ring. Ring topologies provide a ready platform for supporting such
data paths. A p2mp LSP in an MPLS-TP ring would be characterized by a
single ingress LSR and multiple egress LSRs. The following sub-sections
will present methods to address the protection of the ring-based
sections of these LSP.</t>
<section title="Wrapping for p2mp LSP">
<t>When protecting a p2mp ring data path using the wrapping
architecture, the basic operation is similar to the description given,
as the traffic has been wrapped back onto the normal working path on
the far-side of the detected fault and will continue to be transported
to all of the egress points.</t>
<t>It is possible to optimize the performance of the wrapping
mechanism when applied to p2mp LSPs by exploiting the topology of ring
networks.</t>
<t>This improved mechanism, which we call Ring Optimized Multicast
Wrapping (ROM-Wrapping), behaves much the same as classical wrapping.
There is one difference – rather than configuring the recovery
LSP between the end nodes of a failed link (link protection) or
between the upstream and downstream node of a failed node (node
protection), the improved mechanism configures a recovery p2mp LSP
from the upstream (with respect to the failure) node and all egress
nodes (for the particular LSP) downstream from the failure.</t>
<t>Referring to <xref target="figure6"></xref>, it is possible to
identify the protected (working) LSP (A-B-[C]-[D]-E-[F]) and one
possible backup (protection) LSP. This protection LSP will be used to
wrap the data back around the ring to protect against a failure on
link B-C. This protection LSP is also a p2mp LSP that is configured
with egress points (at nodes F, D, & C) complimentary to the
broken working data path.</t>
<figure anchor="figure6" title="P2MP ROM Wrapping">
<artwork><![CDATA[
|
|
V Ingress
___ _V_ ___
/LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * *
@ * *
@ * XXXX Failure
@ * *
@_* ___ __*
/LSR\*************/LSR\**************/LSR\
\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
@ @
@ @
V V
*** working LSP @@@ protection LSP
]]></artwork>
</figure>
<t>Using this mechanism, there is a need to configure a particular
protection LSP for each node on the working LSP. In the table below,
"X's Backup" is the backup path activated by node X as a consequence
of a failure affecting node Y (downstream node with respect to X) or
link X-Y, and square brackets, in the path,indicate egress nodes.</t>
<texttable style="none">
<preamble>Protected LSP:
A–>B–>[C]–>[D]–>E–>[F]</preamble>
<preamble>—— LINK/NODE
PROTECTION——</preamble>
<ttcol width="35%" />
<ttcol align="left" />
<c>A's Backup:</c>
<c>A–>[F]–>E–>[D]–>[C]</c>
<c>B's Backup:</c>
<c>B–>A–>[F]–>E–>[D]–>[C]</c>
<c>C's Backup:</c>
<c>C–>B–>A–>[F]–>E–>[D]</c>
<c>D's Backup:</c>
<c>D–>C–>B–>A–>[F]</c>
<c>E's Backup:</c>
<c>E–>D–>C–>B–>A–>[F]</c>
</texttable>
<t>It should be noted that ROM-Wrapping is an LSP based protection
mechanism, as opposed to the PST based protection mechanisms that are
presented in other sections of this draft. While this may seem to be
limited in scope, the mechanism may be very efficient for many
applications that are based on p2mp distribution schemes. While
ROM-Wrapping can be applied to any network topology, it is
particularly efficient for interconnected ring topologies.</t>
<section title="Comparison of Wrapping and ROM-Wrapping">
<t>It is possible to compare the Wrapping and the ROM-Wrapping
mechanisms in different aspects, and show some improvements offered
by ROM-Wrapping.</t>
<t>When configuring the protection LSP for Wrapping it is necessary
to configure for a specific failure: link protection or node
protection. If the protection method is configured to protect node
failures but the actual failure affects a link, this could result in
failing to deliver traffic to the node, when it should be possible
to.</t>
<t>ROM-Wrapping however does not have this limitation, because there
is no distinction between node and link protection. Whether link B-C
or node C fail, in both cases the rerouting will attempt to reach C.
If the failure is on the link, the traffic will be delivered to C,
while if the failure is at node C, the traffic will be rerouted
correctly until node D, and will be blocked at this point. However,
all egress nodes upto the failure will be able to deliver the
traffic properly.</t>
<t>A second aspect is the number of hops needed to properly deliver
the traffic. Referring to the example shown in <xref
target="figure6"></xref>, where a failure is detected on link B-C,
the following table lists the set of nodes traversed by the data in
the protection:</t>
<texttable style="none">
<preamble>Basic Wrapping:</preamble>
<ttcol width="30%"></ttcol>
<ttcol align="left" width="35%"></ttcol>
<ttcol align="left"></ttcol>
<c>A-B</c>
<c>B-A-F-E-D-C</c>
<c>[C]-[D]-E-[F]</c>
<c>"Upstream" segment with respect to the failure</c>
<c>backup path</c>
<c>"Downstream" segment with respect to the failure</c>
</texttable>
<texttable style="none">
<preamble>ROM Wrapping:</preamble>
<ttcol width="30%"></ttcol>
<ttcol align="left" width="35%"></ttcol>
<ttcol align="left" width="35%"></ttcol>
<c>A-B</c>
<c>B-A-[F]-E-[D]-[C]</c>
<c>..</c>
<c>"Upstream" segment with respect to the failure</c>
<c>backup path</c>
<c></c>
</texttable>
<t>Comparing the two lists of nodes, it is possible to see that in
this particular case the number of hops crossed using the simple
Wrapping is significantly higher than the number of hops crossed by
the traffic when ROM-Wrapping is used. Generally, the number of hops
is always higher or at least equal for basic Wrapping as compared to
ROM-Wrapping. This implies a certain waste of bandwidth on all links
that are crossed in both directions.</t>
<t>Considering the ring network previously seen, it is possible to
do some bandwidth utilization considerations. The protected LSP is
set up from A to F clockwise and an M Mbps bandwidth is reserved
along the path. All the protection LSPs are preprovisioned
counterclockwise, each of them may also have reserved bandwidth M.
These LSPs share the same bandwidth in a SE (Shared Explicit) <xref
target="RSVP"></xref> style.</t>
<t>The bandwidth reserved counterclockwise is not used when the
protected LSP is properly working and could, in theory, be used for
extra traffic <xref target="RFC4427"></xref>. However, it should be
noted that <xref target="TPReqs"></xref> does not require support of
such extra traffic.</t>
<t>The two recovery mechanism require different protection
bandwidths. In the case of Wrapping, the bandwidth used is M in both
directions of many of the links. While in case of ROM-Wrapping, only
the links from the ingress node to the node performing the actual
wrapping utilize M bandwidth in both directions, while all other
links utilize M bandwidth only in the counterclockwise
direction.</t>
<t>Consider the case of a failure detected on link B-C as shown in
<xref target="figure6"></xref>. The following table lists the
bandwidth utilization on each link (in units equal to M), for each
recovery mechanism and for each direction (CW=clockwise,
CCW=counterclockwise).</t>
<texttable style="full">
<ttcol align="center"></ttcol>
<ttcol align="center">Wrapping</ttcol>
<ttcol align="left">ROM-Wrapping</ttcol>
<c>Link A-B</c>
<c>CW+CCW</c>
<c>CW+CCW</c>
<c>Link A-F</c>
<c>CCW</c>
<c>CCW</c>
<c>Link F-E</c>
<c>CW+CCW</c>
<c>CCW</c>
<c>Link E-D</c>
<c>CW+CCW</c>
<c>CCW</c>
<c>Link D-C</c>
<c>CW+CCW</c>
<c>CCW</c>
</texttable>
</section>
<section title="Multiple Failures Comparison">
<t>A further comparison between Wrapping and ROM-Wrapping can be
done with respect to their ability to react to multiple failures.
The wrapping recovery mechanism does not have the ability to recover
from multiple failures on a ring network, while ROM-Wrapping is able
to recover, from multiple failures.</t>
<t>Consider, for example, a double link failure affecting links B-C
and C-D shown in <xref target="figure6"></xref>. The Wrapping
mechanism is not able to recover from the failure because B, upon
detecting the failure, has no alternative paths to reach C. The
whole P2MP traffic is lost. The ROM-Wrapping mechanism is able to
partially recover from the failure, because the backup P2MP LSP to
node F and node D is correctly set up and continues delivering
traffic.</t>
</section>
</section>
<section title="Steering for p2mp paths">
<t>To take advantage of the ring topology in protecting the data
traffic over p2mp LSPs, we can configure two p2mp unidirectional PST
from each node on the ring that traverse the ring in both directions.
These PST will be configured with an egress at each ring node. For
every LSP that enters the ring at a given node the traffic will be
sent through one of these PST (the working PST) – pushing the
PST label onto the packet label stack. Each LSR on the ring will
forward a copy of the packet along the PST, but check the packet by
popping the PST label and examining the underlying LSP label. If this
LSR is an egress point for the LSP it will treat the data packet
appropriately. If the LSR is not an egress point for the LSP, the
packet will be silently dropped.</t>
<figure anchor="figure7" title="P2MP PSTs">
<artwork><![CDATA[
^ ^ ^
_|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/
+* <+++++++++*||
+* +*||
+* +*||
+* +*||
+*_ ++++++++ +++++++++*||
/LSR\********/LSR\********/LSR\
\_F_/<=======\_E_/========\_D_/
| | |
V V V
---> connected LSP *** physical link
=== primary p2mp PST +++ secondary p2mp PST
]]></artwork>
</figure>
<t>Using this PST architecture, we define a 1+1 linear protection
mechanism <xref target="SurvivFwk"></xref> for all protected data
traffic traversing the MPLS-TP ring. The data for a particular p2mp
LSP is transmitted on both the working and recovery PST, 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 packets from the recovery
PST.</t>
<t><xref target="figure7"></xref> shows the two unidirectional p2mp
PST that are configured from LSR-A with egress points at all of the
nodes on the ring. The clockwise PST (i.e. A-B-C-D-E-F) is configured
as the working PST, that will aggregate all traffic for p2mp LSPs that
enter the ring at LSR-A and must be sent out of the ring at any subset
of the ring nodes. The counter-clockwise PST (i.e. A-F-E-D-C-B) is
configured as the recovery PST. Applying 1+1 linear protection to
these two PST – a packet that arrives at LSR-A with a label
stack [LI|BOS] will be forwarded on the clockwise PST with a label
stack [PA1(F)|LI|BOS] and concurrently on the counter-clockwise PST
with a label stack [PA2(B)|LI|BOS].</t>
<t>Assume that the LSP "LI" has egress points at LSR-C & LSR-E.
When the packet arrives at LSR-B, LSR-D, and LSR-F, the LSR will
forward the data packet to continue along the PST, e.g. at LSR-D the
packet will be forwarded with label stack [PD1(F)|LI|BOS]. But in
addition LSR-D will retain a copy of the packet, pop the PST label and
examine the underlying LSP label. Since LSR-D is not an egress point
for LSP-LI, the packet will be dropped. At LSR-C the data packet will
be forwarded along the PST (with label stack [PC1(F)|LI|BOS], but when
the retained copy is examined (after popping the PST label) it will
determine that the packet is intended for this LSR as an egress point
and switch the LSP label forwarding this packet with the label stack
[LE|BOS].</t>
<t>If a fault condition is detected, then some of the nodes will cease
to receive the packets from the clockwise (working) PST. These LSR
should then begin to switch their selector bridge to accept the data
packets from the counter-clockwise PST (i.e. A-F-E-D-C-B), using a
similar logic to that presented in the previous paragraph.</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 title="Coordination protocol">
<t>The Survivability Framework <xref target="SurvivFwk"></xref>
indicates that there is a need to coordinate protection switching
between the end-points of the protected bidirectional domain. The
coordination is necessary for particular cases, in order to maintain the
co-routed nature of the bidirectional transport path. The particular
cases where this becomes necessary include cases of unidirectional fault
detection and use of administrative operator commands.</t>
<t>By using the same mechanisms defined in <xref
target="LinProtect"></xref>, for linear protection, to apply for ring
protection we are able to gain a consistent solution for this
coordination between the end-points of the protection domain. The
Protection State Coordination Protocol that is specified in <xref
target="LinProtect"></xref> provides coverage for all the coordination
cases, including support for administrative commands, e.g.
Forced-Switch.</t>
</section>
<section title="Interconnected rings">
<t>The Requirements document <xref target="TPReqs"></xref> 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>
<t><list style="symbols">
<t>Dual-node interconnect – when the interconnected rings are
interconnected by two nodes from each ring (see <xref
target="figure8"></xref>)</t>
<t>Single-node interconnect – when the connection between the
interconnected rings are through a single node (see <xref
target="figure9"></xref>)</t>
</list></t>
<t>The protection schemes presented in <xref target="sec2"></xref> 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="figure9"></xref>) is a single-point of failure and such an
interconnection scheme should be avoided. In the case of the dual-node
interconnect scheme in <xref target="figure8"></xref>, the connection
point over LSR-A<—>LSR-6 and LSR-F<—>LSR-5 could
use basic linear protection as defined in <xref
target="SurvivFwk"></xref> and <xref target="LinProtect"></xref> .</t>
<figure anchor="figure8" title="Dual-node interconnected rings">
<artwork><![CDATA[
____ ___
/ 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="figure9" title="Single-node interconnected rings">
<artwork><![CDATA[
____ ___
/ 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 title="Conclusions and Recommendations">
<t>Based on the use of the Path Segment Tunnel construct, defined in
<xref target="TPFwk"></xref> and <xref target="OAMFwk"></xref>, it is
possible to define a protection mechanism for MPLS-TP rings that is
based on linear protection <xref target="SurvivFwk"></xref>. This
mechanism would be based on 1:1 linear protection for bidirectional or
unidirectional p2p data paths, and 1+1 linear protection for
unidirectional p2mp paths. It has been shown that this protection
architecture and mechanism fulfills the criteria defined in <xref
target="TPReqs"></xref> for justification of designing a specific
protection mechanism for a ring topology.</t>
<t>It has also been shown that basing the ring protection on the
existing linear protection mechanisms defined in <xref
target="SurvivFwk"></xref> and <xref target="LinProtect"></xref>, the
operator has a choice of using either the wrapping or steering
methodology for protection of both p2p and p2mp data traffic. In
addition, there is no need to define any new coordination protocol to
complete this protection, instead depending upon the OAM functionality
[outlined in <xref target="OAMFwk"></xref> and specified in various
documents] and the coordination protocol specified for linear protection
in <xref target="LinProtect"></xref>.</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>To be added in future version.</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 fullname="P.Pan" initials="P." surname="Pan">
<organization></organization>
</author>
<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="A.Atlas" initials="A." surname="Atlas">
<organization></organization>
</author>
<date month="May" year="2005" />
<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 octets="116872"
target="ftp://ftp.isi.edu/in-notes/rfc4090.txt" type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4090 -->
<!-- Begin inclusion reference.draft.MPLS.TP.Reqs -->
<reference anchor="TPReqs">
<front>
<title>Requirements for the Transport Profile of MPLS</title>
<author fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="April" year="2009" />
<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 -->
<!-- Begin inclusion reference.draft.MPLS.TP.Framework -->
<reference anchor="TPFwk">
<front>
<title>MPLS-TP Framework</title>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization>Alcatel Lucent</organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Cisco</organization>
</author>
<author fullname="Dan Frost" initials="D." surname="Frost">
<organization>Cisco</organization>
</author>
<author fullname="Levan Levrau" initials="L." surname="Levrau">
<organization>Alcatel-Lucent</organization>
</author>
<date month="October" year="2009" />
<abstract>
<t>This document specifies an architectural framework for the
application of Multi Protocol Label Switching (MPLS) in transport
networks, by enabling the construction of packet switched
equivalents to traditional circuit switched carrier networks. It
describes a common set of protocol functions - the MPLS Transport
Profile (MPLS-TP) - that supports the operational models and
capabilities typical of such networks for point-to-point paths,
including signaled or explicitly provisioned bi-directional
connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration and Maintenance (OAM)
functions, and network operation in the absence of a dynamic
control plane or IP forwarding support. Some of these functions
exist in existing MPLS specifications, while others require
extensions to existing specifications to meet the requirements of
the MPLS-TP.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-framework-06" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Fwk -->
<!-- Begin inclusion reference.draft.MPLS.TP.OAM Framework -->
<reference anchor="OAMFwk">
<front>
<title>MPLS-TP OAM Framework</title>
<author fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="David Allan" initials="D." surname="Allan">
<organization></organization>
</author>
<author fullname="Italo Busi" initials="I." surname="Busi">
<organization></organization>
</author>
<date month="October" year="2009" />
<abstract>
<t>Multi-Protocol Label Switching (MPLS) Transport Profile
(MPLS-TP) is based on a profile of the MPLS and pseudowire (PW)
procedures as specified in the MPLS Traffic Engineering (MPLS-TE),
pseudowire (PW) and multi-segment PW (MS-PW) architectures
complemented with additional Operations, Administration and
Maintenance (OAM) procedures for fault, performance and
protection-switching management for packet transport applications
that do not rely on the presence of a control plane.</t>
<t>This document describes a framework to support a comprehensive
set of OAM procedures that fulfills the MPLS-TP OAM
requirements.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-oam-framework-04" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.OAM FWk -->
<!-- Begin inclusion reference.draft.MPLS.TP.Surviavbility Framework -->
<reference anchor="SurvivFwk">
<front>
<title>MPLS-TP Survivability Framework</title>
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher">
<organization></organization>
</author>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<date month="October" year="2009" />
<abstract>
<t>Network survivability is the network's ability to restore
traffic delivery following failure of network resources or an
attack on the network. It plays a critical role in the delivery of
guaranteed services in transport networks to meet the requirements
expressed in Service Level Agreements (SLAs).</t>
<t>The Transport Profile of Multiprotocol Label Switching
(MPLS-TP) is a packet transport technology based on the MPLS data
plane and re-using many aspects of the MPLS management and control
planes.</t>
<t>This document provides a framework for the provision of
survivability functions in the data plane of an MPLS-TP network
using tools provided by the management plane and the control plane
as well as techniques inherent in the data plane itself.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-survive-fwk-02" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Survivability FWk -->
<!-- Begin inclusion reference.draft.MPLS.TP.Linear Protection -->
<reference anchor="LinProtect">
<front>
<title>MPLS-TP Linear Protection</title>
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="Huub van Helvoort" initials="H."
surname="van Helvoort">
<organization></organization>
</author>
<author fullname="Annamaria Fulignoli" initials="A."
surname="Fulignoli">
<organization></organization>
</author>
<author fullname="Yaacov Weingarten" initials="Y."
surname="Weingarten">
<organization></organization>
</author>
<date month="October" year="2009" />
<abstract>
<t>The MPLS Transport Profile (MPLS-TP) being specified jointly by
IETF and ITU-T includes requirements documents and framework
documents. The framework documents define the basic architecture
that is needed in order to support various aspects of the required
behavior. This document addresses the functionality described in
the Survivability Framework document [11] and defines a protocol
that may be used to fulfill the function of the Protection State
Coordination for linear protection, as described in that
document.</t>
</abstract>
</front>
<seriesInfo name="ID"
value="draft-weingarten-mpls-tp-linear-protection-04" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Linear Protection -->
<!-- Begin inclusion reference.RFC.2205 -->
<reference anchor="RSVP">
<front>
<title>Resource ReSerVation Protocol (RSVP) - Functional
Specifications</title>
<author fullname="Bob Braden" initials="R." surname="Braden">
<organization></organization>
</author>
<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization></organization>
</author>
<author fullname="Steve Berson" initials="S." surname="Berson">
<organization></organization>
</author>
<author fullname="Shai Herzog" initials="S." surname="Herzog">
<organization></organization>
</author>
<author fullname="Sugih Jamin" initials="S." surname="Jamin">
<organization></organization>
</author>
<date month="September" year="1997" />
<abstract>
<t>This memo describes version 1 of RSVP, a resource reservation
setup protocol designed for an integrated services Internet. RSVP
provides receiver-initiated setup of resource reservations for
multicast or unicast data flows, with good scaling and robustness
properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2205" />
</reference>
<!-- End inclusion reference.RFC.2205 -->
<!-- Begin inclusion reference.RFC.2205 -->
<reference anchor="RFC4427">
<front>
<title>Recovery (Protection and Restoration) Terminology for
GMPLS</title>
<author fullname="Eric Mannie" initials="E." surname="Mannie">
<organization></organization>
</author>
<author fullname="Dimitri Papadimitriou" initials="D."
surname="Papadimitriou">
<organization></organization>
</author>
<date month="March" year="2006" />
<abstract>
<t>This document defines a common terminology for Generalized
Multi- Protocol Label Switching (GMPLS)-based recovery mechanisms
(i.e., protection and restoration). The terminology is independent
of the underlying transport technologies covered by GMPLS.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4427" />
</reference>
<!-- End inclusion reference.RFC.4427 -->
<!-- Begin inclusion reference.ITU-T.G.841 -->
<reference anchor="G.841">
<front>
<title>Types and characteristics of SDH network protection
architectures</title>
<date month="October" year="1998" />
<abstract>
<t>Describes different architecture architectures and protocol for
SDH networks.</t>
</abstract>
</front>
<seriesInfo name="ITU-T" value="G.841" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Linear Protection -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:33:28 |