Applicability of MPLS-TP Linear Protection for Ring Topologies
draft-ietf-mpls-tp-ring-protection-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6974.
Expired & archived
|
|
|---|---|---|---|
| Authors | Yaacov Weingarten , Stewart Bryant , Nurit Sprecher , Daniele Ceccarelli , Diego Caviglia , Francesco Fondelli , Marco Corsi , Bo Wu , Xuehui Dai | ||
| Last updated | 2012-11-05 (Latest revision 2012-04-29) | ||
| Replaces | draft-weingarten-mpls-tp-ring-protection | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6974 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-mpls-tp-ring-protection-02
Network Working Group Y. Weingarten
Internet-Draft
Intended status: Informational S. Bryant
Expires: October 31, 2012 Cisco
N. Sprecher
Nokia Siemens Networks
D. Ceccarelli
D. Caviglia
F. Fondelli
Ericsson
M. Corsi
Altran
B. Wu
X. Dai
ZTE Corporation
April 29, 2012
Applicability of MPLS-TP Linear Protection for Ring Topologies
draft-ietf-mpls-tp-ring-protection-02.txt
Abstract
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
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, minimizing 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,
specifically those defined in MPLS-TP Linear Protection, without the
need for specification of new constructs or protocols.
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Weingarten, et al. Expires October 31, 2012 [Page 1]
Internet-Draft MPLS-TP RP April 2012
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Weingarten, et al. Expires October 31, 2012 [Page 2]
Internet-Draft MPLS-TP RP April 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 7
2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. P2P ring protection using SPME . . . . . . . . . . . . . . 10
2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11
2.3.2. Wrapping with segment based SPME . . . . . . . . . . . 12
2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 13
2.3.4. Wrapping for link and node protection . . . . . . . . 14
2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 14
3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 15
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 17
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 19
3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 19
3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 20
3.2.2. Walkthrough using context labels . . . . . . . . . . . 22
4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 23
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. Informative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Weingarten, et al. Expires October 31, 2012 [Page 3]
Internet-Draft MPLS-TP RP April 2012
1. Introduction
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.
The requirements for MPLS-TP [TPReqs] indicates a requirement to
support a network that may include sub-networks that constitute a
MPLS-TP ring as defined in the requirements. The requirements
document does not identify any protection requirements specific to a
ring topology. However, the requirements state that specific
protection mechanisms aimed at ring topologies may be developed if
these allow the network to optimize:
o Number of OAM entities needed to trigger the protection
o Number of elements of recovery needed
o Number of labels required
o Number of control and management plane transactions during a
recovery operation
o Impact of signaling and routing information exchanged, in presence
of control plane
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 [TPReqs] as summarized
above.
A related topic in [TPReqs] addresses the required support for
interconnected rings. This topic involves various scenarios that
require further study and will be addressed in a separate document,
based on the principles outlined in this document.
1.1. Problem statement
Ring topologies, as defined in [TPReqs], 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 -
Weingarten, et al. Expires October 31, 2012 [Page 4]
Internet-Draft MPLS-TP RP April 2012
1. A point-to-point 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.
2. Where the ring is being used as a branching point for a point-to-
multipoint transport path, 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.
In either of these two situations, there is a need to address the
following different cases -
1. 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.
2. 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.
3. An operator command is issued to a specific ring node. A
description of the different operator commands is found in
Section 4.12 of [RFC4427]. Examples of these commands include
Manual Switch, Forced Switch, or Clear operations.
The protection domain 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.
1.2. Terminology and Notation
The terminology used in this document is based on the terminology
defined in the MPLS-TP framework documents:
o MPLS-TP Framework[TPFwk]
o MPLS-TP OAM Framework[OAMFwk]
o MPLS-TP Survivability Framework[SurvivFwk]
The MPLS-TP Framework document [TPFwk] defines a Sub-Path Maintenance
Entity (SPME) construct that can be defined between any two LSRs of a
MPLS-TP LSP. This SPME may be configured as a co-routed
bidirectional path. The SPME is defined to allow management and
monitoring of any segment of a transport path. This concept will be
used extensively throughout the document to support protection of the
Weingarten, et al. Expires October 31, 2012 [Page 5]
Internet-Draft MPLS-TP RP April 2012
traffic that traverses a MPLS-TP ring.
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:
1. The label stack will be enclosed in square brackets ("[]")
2. Each level in the stack will be separated by the '|' character.
It should be noted that the label stack may contain additional
levels however, we only present the levels that are germane to
the protection mechanism.
3. When applicable, the S-bit (signifying that a given label is the
bottom of the label stack) will be denoted by the string '+S'
within the label. If a label is not shown with '+S' that label
may or may not be the bottom label in the stack. '+S' is only
shown when it is important to illustrate that a given label is
definitely the last one in the label stack.
4. The label of the LSP at the ingress point to the ring will be
denoted by the string "LI" and the label of the LSP that is
expected at the egress point from the ring will be denoted by the
string "LE", and "LSE" will denote the label expected at the exit
LSR of a SPME (if it is different from the egress point from the
ring).
5. The label for a SPME will be denoted by Pxi(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 SPME whose index is i.
For example -
o the label stack [LI] denotes the label stack received at the
ingress node of the ring. This may have additional labels after
LI, e.g. a PW label however, this is irrelevant to the discussion
of the protection scenario.
o [PB1(G)|LE] denotes a stack whose top-label is the SPME-1 label
for LSR-B to transmit the data packet to LSR-G, the second label
is the label that would be used by the egress LSR to continue the
packet on the original LSP.
o If "LE" were the bottom label in the stack, then the label stack
would be shown as [PB1(G)|LE+S].
Weingarten, et al. Expires October 31, 2012 [Page 6]
Internet-Draft MPLS-TP RP April 2012
1.3. Contributing Authors
Akira Sakurai (NEC), Rolf Winter (NEC)
2. P2P Ring Protection
Classically there are two protection architecture mechanisms for ring
topologies, based on SDH specifications [G.841], 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.
2.1. Wrapping
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. Wrapping behavior is similar to
MPLS-TE FRR as defined in [RFC4090] using either bypass or detour
tunnels. It would be possible to wrap each LSP arounf the failed
links via a detour tunnel using a different label for each LSP or to
wrap all the LSPs using a bypass tunnel and a single label.
___ ######## ___ ######## ___
======>/LSR\********/LSR\***XX***/LSR\
\_B_/@@@@@@@@\_A_/ \_F_/
*@ #*
*@ #*
*@ #*
_*@ ___ #*_
/LSR\********/LSR\********/LSR\======>
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### working path @@@ wrapped data path
Figure 1: Wrapping protection for p2p path
Weingarten, et al. Expires October 31, 2012 [Page 7]
Internet-Draft MPLS-TP RP April 2012
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 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.
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.
The following considerations should be taken into account when
considering use of wrapping protection:
o Detection of loss-of-continuity or mis-connectivity, should be
performed at the link level and/or per LSR when using node-level
protection. Configuration of the protection being performed (i.e.
link protection or node protection) needs to be performed
a-priori, since the configuration of the proper protection path is
dependent upon this decision.
o 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.
o 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
bandwidth needed for this protection.
o If a double-fault situation occurs in the ring, then wrapping will
not be able to deliver any packets except between the ingress and
the first fault location. This is based on the need for wrapping
to connect between the neighbors of the fault location, and this
is not possible in the segmented ring.
o The resource allocation for the alternate-paths could be
problematic, since most of these alternate paths will not be used
Weingarten, et al. Expires October 31, 2012 [Page 8]
Internet-Draft MPLS-TP RP April 2012
simultaneously. One possibility could be to allocate '0'
resources and depend on the NMS to allocate the proper resources
around the ring.
o 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.
2.2. Steering
The second common scheme for ring protection, steering, takes
advantage of the ring topology by defining two paths from the ingress
point (to the ring) to the egress point going in opposite directions
around the ring. This is illustrated in Figure 2, where if we assume
that the traffic needs to enter the ring from node B and exit through
node F, we could define a primary path through nodes B-A-F, and an
alternate path through the nodes B-C-D-E-F. In steering the
switching is always performed by the ingress node (node B in
Figure 2). If a fault condition is detected anywhere 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).
This mechanism bears similarities to linear 1:1 protection
[SurvivFwk]. The two paths around the ring act as the working and
protection 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
domain.
The following considerations must be taken into account regarding the
steering architecture:
o Steering relies on a failure detection method that is able to
notify the ingress node of the fault condition. This may involve
different OAM functionality described in [OAMFwk], e.g. Remote
Defect Indication, Alarm reporting.
o The process of notifying the ingress node adds to the latency of
the protection switching process, after the detection of the fault
condition.
o 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.
Weingarten, et al. Expires October 31, 2012 [Page 9]
Internet-Draft MPLS-TP RP April 2012
2.3. P2P ring protection using SPME
The SPME concept was introduced by [TPFwk] to support management and
monitoring an arbitrary segment of a transport. However, an SPME is
essentially a valid LSP that may be used to aggregate all LSP traffic
that traverses the sub-path delineated by the SPME. An SPME may be
monitored using the OAM mechanisms as described in the MPLS-TP OAM
Framework document [OAMFwk].
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)
SPME with the segment of the transport path that traverses the ring.
In addition, we configure an alternate (protecting) SPME that
traverses the ring in the opposite direction around the ring. The
exact selection of the SPMEs is dependent on the type of transport
path and protection that is being implemented and will be detailed in
the following sub-sections.
Based on this architectural configuration for ring protection, it is
possible to limit the number of alternate paths needed to protect the
data traversing the ring. In addition, since we will perform all of
the OAM functionality on the SPME configured for the traffic, we can
minimize the number of OAM sessions needed to monitor the data
traffic of the ring - rather than monitoring each individual LSP.
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 SPME through the ring (the first SPME
traverses along B-A-F, and the second SPME traverses B-C-D-E-F).
___ ___ ___
======>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### primary SPME @@@ secondary SPME
Figure 2: A MPLS-TP ring
Weingarten, et al. Expires October 31, 2012 [Page 10]
Internet-Draft MPLS-TP RP April 2012
In all of the following subsections, we use 1:1 linear protection
[SurvivFwk] [LinProtect] to perform protection switching and
coordination when a signal fault is detected. The actual
configuration of the SPMEs 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 SPME, while applying OAM
functionality over both the primary and the secondary SPME to detect
signal fault conditions on either path. If a signal fault is
detected on the primary SPME, then the mechanism described in
[LinProtect] shall be used to coordinate a switch-over of data
traffic to the secondary SPME.
Assuming that the SPME is implemented as an hierarchical LSP, packets
that arrive at LSR-B with a label stack [LI] will have the SPME label
pushed at LSR-B and the LSP label will be swapped for the label that
is expected by the egress LSR (i.e. the packet will arrive at LSR-A
with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]).
The SPME label will be popped by LSR-F and the LSP label will be
treated appropriately at LSR-F and forwarded along the LSP, outside
the ring. This scenario is true for all LSP that are aggregated by
this primary SPME.
2.3.1. Path SPME for Steering
A p2p SPME 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 SPME. Since the SPME is
traversing a ring we can take advantage of another characteristic of
a ring - there is always an alternative path between the two MEPs,
i.e. traversing the ring in the opposite direction. This alternative
SPME can be defined as the protection path for the working path that
is configured as part of the LSP and defined as a SPME.
For each pair of SPMEs 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 protection SPME. 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, protection SPME.
This protection mechanism is identical to application of 1:1 linear
protection[SurvivFwk] [LinProtect] to the pair of SPMEs. Under
normal conditions, all LSP data traffic will be transmitted on the
working SPME. If the linear protection is triggered, by either the
OAM indication, an other fault indication trigger, or an operator
command, then the MEPs will select the protection SPME to transmit
all LSP data packets.
Weingarten, et al. Expires October 31, 2012 [Page 11]
Internet-Draft MPLS-TP RP April 2012
The protection SPME 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 SPME, if the
protection domain is configured for revertive behavior.
The control of the protection switching, especially for cases of
operator commands, would be covered by the protocol defined in
[LinProtect].
2.3.2. Wrapping with segment based SPME
It is possible to use the SPME mechanism to perform segment-based
protection. For each link in the ring, we define two SPME - the
first is a SPME between the two LSRs that are connected by the link,
and the second SPME between these same two LSRs but traversing the
entire ring (except the link that connects the LSRs). In Figure 3 we
show the primary SPME that connects LSR-A & LSR-F over a segment
connection, and the secondary SPME that connects these same LSRs by
traversing the ring in the opposite direction.
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *@
*@ *@
*@ *@
_*@ ___ _*@
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** physical link
### primary SPME @@@ secondary SPME
Figure 3: Segment SPMEs
By applying OAM monitoring of these two SPME (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 SPME. 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
SPME.
Following the progression of the label stack through this switching
operation (for a LSP that enters the ring at LSR B and exits the ring
Weingarten, et al. Expires October 31, 2012 [Page 12]
Internet-Draft MPLS-TP RP April 2012
at LSR E):
1. The data packet arrives at LSR-A with label stack [L1+S] (i.e.
top label from the LSP and bottom-of-stack indicator)
2. In the normal case (no switching), LSR-A forwards the packet with
label stack [PA1(F)|LSE+S] (i.e. swap the label for the LSP, to
be acceptable to the SPME egress, and push the label for the
primary SPME from LSR-A to LSR-F).
3. When switching is in-effect, LSR-A forwards the packet with label
stack [PA2(B)|LSE+S] (i.e. LSR-A pushed the label for the
secondary SPME from LSR-A to LSR-F, after swapping the label of
the lower level LSP). This will be transmitted along the
secondary SPME until LSR-E forwards it to LSR-F with label stack
[PE2(F)|LSE+S].
4. When the packet arrives at LSR-F, it will pop the SPME label,
process the LSP label, and forward the packet to the next point,
possibly pushing a SPME label if the next segment is likewise
protected.
2.3.3. Wrapping node protection
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 SPMEs that are used. For node protection, the
primary SPME would be configured between the two LSR that are
connected to the node that is being protected (see SPME between LSR-A
and LSR-E through LSR-F in Figure 4), and the secondary SPME would be
configured between these same nodes, going around the ring (see
secondary SPME in Figure 4).
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *#
*@ *#
*@ *#
_*@ ___ _*#
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** physical link
### primary SPME @@@ secondary SPME
Figure 4: Node-protection SPMEs
Weingarten, et al. Expires October 31, 2012 [Page 13]
Internet-Draft MPLS-TP RP April 2012
The protection mechanism would work similarly - based on 1:1 linear
protection [SurvivFwk], triggered by OAM functions on both SPMEs, and
wrapping the data packets onto the secondary SPME at the ingress MEP
(e.g. LSR-A in the figure) of the SPME and back onto the
continuation of the LSP at the egress MEP (e.g. LSR-E in the figure)
of the SPME.
2.3.4. Wrapping for link and node protection
In the different types of wrapping presented in Section 2.3.2 and
Section 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.
It would be possible to configure extra SPME to protect both for link
and node failures, arriving at a configuration of the ring that is
shown in Figure 5. Choosing the SPME to use for the wrapping would,
however, then involve considerable effort and could result in the
protected traffic not sharing the same protection path in both
directions.
___ ++++++++ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
$+*@ +*$
$+*@ +*$
$+*@ +*$
$+*@ ++++++++ ___ ++++++++ +*$
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
$$$$$$$$ $$$$$$$$
*** physical link
### primary SPME @@@ secondary node#1 SPME
$$$ secondary node#2 SPME +++ secondary segment SPME
Figure 5: Segment & Node protection SPMEs
2.4. Analysis of p2p protection
Analyzing the mechanisms described in the above subsections we can
point to the following observations (based on a ring with N nodes,
assumed to be not more than 16):
Weingarten, et al. Expires October 31, 2012 [Page 14]
Internet-Draft MPLS-TP RP April 2012
o Number of SPME that need to be configured - for steeing SPME
protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress
LSR to each other node in the ring], for wrapping based on SPME
either as described in Section 2.3.2 and Section 2.3.3 = O(2N)
[however, the operator must decide a priori on whether to protect
for link failures or node failures at each point]
o Number of OAM sessions at each node - for steering = O(2N), for
SPME wrapping = 3
o Bandwidth requirements - for SPME-based steering: single bandwidth
at each link, for wrapping: double bandwidth at links that are
between ingress and wrapping node and between second wrapping node
and egress.
o Special considerations - for SPME based steering: latency of OAM
detection of fault condition by ingress MEP [using Alarm-reporting
could optimize over using CC-V only], for SPME wrapping: at each
node must decide a priori whether protecting for link or node
failures. To protect for both node and link failures would
increase the complexity of deciding which protection path to use,
as well as, violating the co-routedness of the protected traffic.
Based on this analysis, using steering as described in Section 2.3.1
would be the recommended protection mechanism due to its simplicity,
even though it may involve the use of additional resources (i.e.
SPME) for monitorng the traffic. It should be pointed out that the
number of SPME involved in this protection could be reduced by
eliminating SPME between pairs of LSR that are not used as an ingress
and egress pair.
3. P2MP protection
[TPReqs] 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.
3.1. Wrapping for p2mp LSP
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
Weingarten, et al. Expires October 31, 2012 [Page 15]
Internet-Draft MPLS-TP RP April 2012
transported to all of the egress points.
It is possible to optimize the performance of the wrapping mechanism
when applied to p2mp LSPs by exploiting the topology of ring
networks.
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 protection 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 protection p2mp LSP from the
upstream (with respect to the failure) node and all egress nodes (for
the particular LSP) downstream from the failure.
Referring to Figure 6, 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.
|
|
V Ingress
___ _V_ ___
/LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * *
@ * *
@ * XXXX Failure
@ * *
@_* ___ __*
/LSR\*************/LSR\**************/LSR\
\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
@ @
@ @
V V
*** working LSP @@@ protection LSP
Figure 6: P2MP ROM Wrapping
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
Weingarten, et al. Expires October 31, 2012 [Page 16]
Internet-Draft MPLS-TP RP April 2012
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.
Protected LSP: A->B->[C]->[D]->E->[F]
---- LINK/NODE PROTECTION----
A's Backup: A->[F]->E->[D]->[C]
B's Backup: B->A->[F]->E->[D]->[C]
C's Backup: C->B->A->[F]->E->[D]
D's Backup: D->C->B->A->[F]
E's Backup: E->D->C->B->A->[F]
It should be noted that ROM-Wrapping is an LSP based protection
mechanism, as opposed to the SPME 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.
3.1.1. Comparison of Wrapping and ROM-Wrapping
It is possible to compare the Wrapping and the ROM-Wrapping
mechanisms in different aspects, and show some improvements offered
by ROM-Wrapping.
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.
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 fails, in either case 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 up-to the failure will be able to deliver the
traffic properly.
A second aspect is the number of hops needed to properly deliver the
traffic. Referring to the example shown in Figure 6, where a failure
is detected on link B-C, the following table lists the set of nodes
traversed by the data in the protection:
Weingarten, et al. Expires October 31, 2012 [Page 17]
Internet-Draft MPLS-TP RP April 2012
Basic Wrapping:
A-B B-A-F-E-D-C [C]-[D]-E-[F]
"Upstream" segment backup path "Downstream" segment
with respect to the with respect to the
failure failure
ROM Wrapping:
A-B B-A-[F]-E-[D]-[C] ..
"Upstream" segment backup path
with respect to the
failure
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 for
basic Wrapping is always higher or at least equal compared to ROM-
Wrapping. This implies a certain waste of bandwidth on all links
that are crossed in both directions.
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 pre-provisioned
counterclockwise, each of them may also have reserved bandwidth M.
These LSPs share the same bandwidth in a SE (Shared Explicit) [RSVP]
style.
The bandwidth reserved counterclockwise is not used when the
protected LSP is properly working and could, in theory, be used for
extra traffic [RFC4427]. However, it should be noted that [TPReqs]
does not require support of such extra traffic.
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.
Consider the case of a failure detected on link B-C as shown in
Figure 6. 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).
Weingarten, et al. Expires October 31, 2012 [Page 18]
Internet-Draft MPLS-TP RP April 2012
+----------+----------+--------------+
| | Wrapping | ROM-Wrapping |
+----------+----------+--------------+
| Link A-B | CW+CCW | CW+CCW |
| Link A-F | CCW | CCW |
| Link F-E | CW+CCW | CCW |
| Link E-D | CW+CCW | CCW |
| Link D-C | CW+CCW | CCW |
+----------+----------+--------------+
3.1.2. Multiple Failures Comparison
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 some multiple failures.
Consider, for example, a double link failure affecting links B-C and
C-D shown in Figure 6. 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.
3.2. Steering for p2mp paths
When protecting p2mp traffic that uses a MPLS-TP ring as its
branching point, i.e. it enters the ring at a head-end node and exits
the ring at multiple nodes, we can employ a steering mechanism based
on 1+1 linear protection [SurvivFwk]. We can configure two p2mp
unidirectional SPME from each node on the ring that traverse the ring
in both directions. These SPME will be configured with an egress at
each ring node. In order to be able to properly direct the LSP
traffic to the proper egress point for that particular LSP, we need
to employ context labeling as defined in [RFC5331]. The method for
using these labels is expanded in section 3.2.1.
For every LSP that enters the ring at a given node the traffic will
be sent through both of these SPME, each with its own context label
and the context-specific label for the particular LSP. The egress
nodes should select the traffic that is arriving on the working SPME.
In case there is a failure condition, the egress nodes should select
the traffic from whichever of the SPME that is arrives at that node,
i.e. since one of the two (presumably the working SPME) will be
blocked by the failure. In this way, all egress nodes are able to
receive the data traffic. While each node detects that there is
Weingarten, et al. Expires October 31, 2012 [Page 19]
Internet-Draft MPLS-TP RP April 2012
connectivity from the ingress point, it continues to select the data
that is coming from the working SPME. If a particular node stops
receiving the connectivity messages from the working SPME, it
identifies that it must switch its selector to read the data packets
from the protection SPME.
^ ^ ^
_|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/
+* <+++++++++*||
+* +*||
+* +*||
+* +*||
+*_ ++++++++ ___ +++++++++*||
/LSR\********/LSR\********/LSR\
\_F_/<=======\_E_/========\_D_/
| | |
V V V
---> connected LSP *** physical link
=== working SPME +++ protection SPME
Figure 7: P2MP SPMEs
3.2.1. Context labels
Figure 7 shows the two unidirectional p2mp SPME that are configured
from LSR-A with egress points at all of the nodes on the ring. The
clockwise SPME (i.e. A-B-C-D-E-F) is configured as the working SPME,
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 SPME (i.e. A-F-E-D-C-B) is configured
as the protection SPME.
[RFC5331] defines the concept of context labels. A context-
identifying label defines a context label space that is used to
interpret the context-specific labels (found directly below the
context- identifying label) for a specific tunnel. The SPME label is
a context- identifying label. This means that at each hop the node
that receives the SPME label uses it to point not directly to a
forwarding table, but to a LIB. As a node receives an SPME label it
examines it, discovers that it is a context label, pops off the SPME
label, and looks up the next label down in the stack in the LIB
indicated by the context label.
The label below this context-identifying label should be used by the
forwarding function of the node to decide the actions taken for this
Weingarten, et al. Expires October 31, 2012 [Page 20]
Internet-Draft MPLS-TP RP April 2012
packet. In MPLS-TP ring protection there are two context LIBs. One
is the context LIB for the working SPME and the other is the context
LIB for the P-SPME. All context LIBs have a behavior defined for the
e2e LSP label but the behavior at each node may be different in the
context of each SPME.
For example, using the ring that is shown in Figure 7, if the working
SPME is configured to have a context-identifying label of CW at each
node on the ring and the protection SPME is configured to have a
context-identifying label of CP at each node. For the specific LSP
we will designate the context-specific label used on the working SPME
as WL(x-y) to be the label used as node-x to forward the packet to
node-y. Similarly, for the context-specific labels on the protection
SPME would be designated PL(x-y). An explicit example of label
values appears in the next sub-section.
If we apply the 1+1 linear protection scheme outlined above for an
p2mp LSP that enters the ring at LSR-A and has egress points from the
ring at LSR-C and LSR-E using the two SPME shown in Figure 7 then a
packet that arrives at LSR-A with a label stack [LI+S] will be
forwarded on the working SPME with a label stack [CW | WL(A-B)]. The
packet should then be forwarded to LSR-C arriving with a label [CW |
WL(B-C)], where WL(B-C) should instruct the forwarding function to
egress the packet with [LE(C)] and forward a copy to LSR-D with label
stack [CW | WL(C-D)].
If a fault condition is detected, then some of the nodes will cease
to receive the packets from the clockwise (working) SPME. These LSR
should then begin to switch their selector bridge to accept the data
packets from the protection SPME. At the ingress point the packet
will be transmitted on both the working SPME and the protection SPME.
Continuing the example, if there is a failure on the link between
LSR-C and LSR-D then LSR-A will transmit one copy of the data to
LSR-B with stack [CW | WL(A-B)] and one copy to LSR-F with stack [CP
| PL(A-F)]. The packet will arrive at LSR-C from the working SPME
and egress from the ring. LSR-E will receive the packet from the
protection SPME with stack [CP | PL(F-E)] and the context-sensitive
label PL(F-E) will instruct the forwarding function to send a copy
out of the ring with label LE(E) and a second copy to LSR-D with
stack [CP | PL(E-D)]. In this way each of the egress points receive
the packet from the SPME that is available at that point.
This architecture has the added advantages that there is no need for
the ingress node to identify the existence of the mis-connectivity,
and there is no need for a return path from the egress points to the
ingress.
Weingarten, et al. Expires October 31, 2012 [Page 21]
Internet-Draft MPLS-TP RP April 2012
3.2.2. Walkthrough using context labels
In order to better demonstrate the use of the context labels we
present a walkthrough of an example application of the p2mp
protection presented in this section. Referring to Figure 8, there
is a p2mp LSP that traverses the ring, entering the ring at LSR-B and
branching off at LSR-D, LSR-E, and LSR-H and does not continue beyond
LSR-H. For purposes of protection two p2mp unidirectional SPME are
configured on the ring starting from LSR-B. One of the SPME, the
working SPME, is configured with egress points at each of the LSR -
C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is
configured with egress points at each of the LSR - A, K, J, H, G, F,
E, D, C.
^ ^ ^ ^ ^
_|_ xxxxxxxxx_|_ xxxxxxxxxX|_xxxxxxxxxX|_ xxxxxxxx_|_
xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/
*+ <+++++++++ +++++++ ++++++++*||x
*+ +*||x
*+ +*||x
*+ +*||x
_*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x
/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/
| | | |Xxxxxxxxxx |
V V V V V
xxx p2mp LSP (X LSP egress) *** physical link
=== working SPME +++ protection SPME
Figure 8: P2MP SPMEs
For this example we suppose that the LSP traffic enters the ring at
LSR-B with the label stack [99], leaves the ring at LSR-D with stack
[199], at LSR-E with stack [299], and LSR-H with stack [399].
While it is possible for the context-identifying label for the SPME
be configured as a different value at each LSR, for the sake of this
example we will suppose a configuration of 200 as the context-
identifying label for the working SPME at each of the LSR in the
ring, and 400 as the context-identifying label for the protection
SPME at each LSR.
Weingarten, et al. Expires October 31, 2012 [Page 22]
Internet-Draft MPLS-TP RP April 2012
For the specific connected LSP we configure the following context-
specific labels for each context:
+------+-----------------------------+------------------------------+
| node | W-context(200) | P-context(400) |
+------+-----------------------------+------------------------------+
| A | 65 {drop packet} | 165 {fwrd w/[400|190]} |
| C | 90 {fwrd w/[200|80]} | 190 {drop packet} |
| D | 80 {fwrd w/[200|75] + | 180 {egress w/[199]} |
| | egress w/[199]} | |
| E | 75 {fwrd w/[200|65] + | 175 {fwrd w/[400|180] + |
| | egress w/[299]} | egress w/[299]} |
| F | 65 {fwrd w/[200|55]} | 165 {fwrd w/[400|175]} |
| G | 55 {fwrd w/[200|45]} | 155 {fwrd w/[400|165]} |
| H | 45 {egress w/[399]} | 145 {fwrd w/[400|155] + |
| | | egress w/[399]} |
| J | 65 {drop packet} | 165 {fwrd w/[400|145]} |
| K | 65 {drop packet} | 190 {fwrd w/[400|165]} |
+------+-----------------------------+------------------------------+
When a packet arrives on the LSP to LSR-B with stack [99], the
forwarding function determines that it is necessary to forward the
packet to both the working SPME with stack [200|90] and the
protection SPME with stack [400|165]. Each LSR on the SPME will
identify the top label, i.e. 200 or 400, to be the context-
identifying label and use the next label in the stack to select the
forwarding action from the specific context table.
Therefore, at LSR-C the packet on the working SPME will arrive with
stack [200|90] and the 200 will point to the table in the middle
column above. After popping the 200 the next label, i.e. 90, will
select the forwarding action "fwrd w/[200|80]" and the packet will be
forwarded to LSR-D with stack [200|80]. In this manner, the packet
will be forwarded along both SPME according to the configured
behavior in the context tables. However, the egress points at LSR D,
E, & H, will all be configured with a selector bridge to only use the
input from the working SPME. If any of these egress points identify
that there is a connection fault on the working SPME, then the
selector bridge will cause the LSR to read the input from the
protection SPME.
4. Coordination protocol
The Survivability Framework [SurvivFwk] indicates that there is a
need to coordinate protection switching between the end-points of a
protected bidirectional domain. The coordination is necessary for
particular cases, in order to maintain the co-routed nature of the
Weingarten, et al. Expires October 31, 2012 [Page 23]
Internet-Draft MPLS-TP RP April 2012
bidirectional transport path. The particular cases where this
becomes necessary include cases of unidirectional fault detection and
use of operator commands.
By using the same mechanisms defined in [LinProtect], 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 [LinProtect] provides coverage for all the
coordination cases, including support for operator commands, e.g.
Forced-Switch.
5. Conclusions and Recommendations
Ring topologies are prevelant in traditional transport networks and
will continue to be used for various reasons. Protection for
transport paths that traverse a ring within a MPLS network can be
provided by applying an appropriate instance of linear protection, as
defined in [SurvivFwk]. This document has shown that for each of the
traditional ring protection architectures there is an application of
linear protection that provides efficient coverage, based on the use
of the Sub-Path Maintenance Entity (SPME), defined in [TPFwk] and
[OAMFwk]. For example,
o p2p Steering - Configuration of two SPME, from ring ingress to
ring egress, and 1:1 linear protection
o p2p Wrapping for link protection - Configuration of two SPME, one
for the protected link and the second using the long route between
the two neighboring nodes, and 1:1 linear protection.
o p2p Wrapping for node protection - Configuration of two SPME, one
between the two neighbors of the protected node and the second
between these two nodes on the long route, and 1:1 linear
protection.
o p2mp Wrapping - it is possible to optimize the performance of the
wrapping by configuring the proper protection path to egress the
data at the proper branching nodes.
o p2mp Steering - by combining 1+1 linear protection and
configuration of the SPME based on context-sensitive labeling of
the protection path.
It has been shown that this set of protection architecture and
mechanisms are optimized based on the criteria defined in [TPReqs]
for justification of designing a specific protection mechanism for a
Weingarten, et al. Expires October 31, 2012 [Page 24]
Internet-Draft MPLS-TP RP April 2012
ring topology. This thereby aleviates the necessity to create a new
mechanism or protocol to support the protection of ring topologies.
By basing the simple p2p ring protection on basic 1:1 linear
protection there is a very efficient way of implementing Steering
protection for the sections of a transport path that traverses the
ring. Steering should be the preferred mechanism for ring protection
since it reduces the extra bandwidth required when traffic doubles
through wrapped protection, and the ability to protect both against
link and node failures without complicating the fault detection or
the need to configure multiple protection paths. While this is true,
the possiblity remains to support either mechanism while depending
upon the OAM functionality [outlined in [OAMFwk] and specified in
various documents] and the coordination protocol specified for linear
protection in [LinProtect].
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
To be added in future version.
8. Acknowledgements
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.
9. Informative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, Aug 2008.
Weingarten, et al. Expires October 31, 2012 [Page 25]
Internet-Draft MPLS-TP RP April 2012
[TPReqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
"Requirements for the Transport Profile of MPLS",
RFC 5654, April 2009.
[TPFwk] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP
Framework", RFC 5921, May 2010.
[OAMFwk] Niven-Jenkins, B., Allan, D., and I. Busi, "MPLS-TP OAM
Framework", RFC 6371, May 2010.
[SurvivFwk]
Sprecher, N. and A. Farrel, "MPLS-TP Survivability
Framework", RFC 6372, June 2010.
[LinProtect]
Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A.,
and Y. Weingarten, "MPLS-TP Linear Protection", RFC 6378,
October 2009.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
Specifications", RFC 2205, September 1997.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for GMPLS", RFC 4427, March 2006.
[G.841] ITU, "Types and characteristics of SDH network protection
architectures", ITU-T G.841, October 1998.
Authors' Addresses
Yaacov Weingarten
34 Hagefen St.
Karnei Shomron, 4485500
Israel
Phone:
Email: wyaacov@gmail.com
Stewart Bryant
Cisco
United Kingdom
Email: stbryant@cisco.com
Weingarten, et al. Expires October 31, 2012 [Page 26]
Internet-Draft MPLS-TP RP April 2012
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Email: nurit.sprecher@nsn.com
Danielle Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
Email: diego.caviglia@ericsson.com
Francesco Fondelli
Ericsson
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
Email: francesco.fondelli@ericsson.com
Marco Corsi
Altran
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
Email: corsi.marco@gmail.com
Weingarten, et al. Expires October 31, 2012 [Page 27]
Internet-Draft MPLS-TP RP April 2012
Bo Wu
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Nanjing, Yuhuatai District
P.R.China
Email: wu.bo@zte.com.cn
Xuehui Dai
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Nanjing, Yuhuatai District
P.R.China
Email: dai.xuehui@zte.com.cn
Weingarten, et al. Expires October 31, 2012 [Page 28]