One document matched: draft-cheung-mpls-tp-mesh-protection-03.txt
Differences from draft-cheung-mpls-tp-mesh-protection-02.txt
MPLS Working Group Tae-sik Cheung
Internet Draft Jeong-dong Ryoo
Intended status: Standards Track ETRI
Created: April 25, 2011
Expires: October 25, 2011
MPLS-TP Shared Mesh Protection
draft-cheung-mpls-tp-mesh-protection-03.txt
Abstract
This document describes a mechanism to address the requirement for
protection of Label Switched Paths (LSPs) in an MPLS Transport
Profile (MPLS-TP) mesh topology. The shared mesh protection mechanism
enables multiple protection paths within a shared mesh protection
domain to share protection resources for the protection of working
paths by coordinating protection switching operations according to
the priority assigned to each end-to-end linear protection domain.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 25, 2011.
Cheung, et al. Expires October 25 2011 [Page 1]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
Copyright Notice
Copyright (c) 2011 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.
Table of Contents
1. Introduction.................................................. 3
2. Conventions used in this document............................. 4
2.1. Acronyms................................................. 4
2.2. Definitions and Terminology.............................. 5
3. Shared Mesh Protection........................................ 5
3.1. Protection Switching Priority............................ 6
3.2. Shared Start and End Nodes............................... 6
3.3. Bridge and Selector Models............................... 8
3.4. Shared Mesh Protection Planning.......................... 9
3.5. Shared Mesh Protection Switching......................... 9
3.5.1. Protection Switching Event.............................10
3.5.2. Protection Locking.....................................11
4. Protocol......................................................11
4.1. PDU Format...............................................11
4.1.1. Protection Switching Event Message.....................12
4.1.2. Protection Locking Message.............................12
4.2. Message Transmission.....................................13
5. Operation of Shared Mesh Protection...........................13
6. Manageability Considerations..................................16
7. Security Considerations.......................................16
8. IANA Considerations...........................................16
9. References....................................................16
9.1. Normative References.....................................16
9.2. Informative References...................................16
Cheung, et al. Expires October 25 2011 [Page 2]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
1. Introduction
The MPLS Transport Profile (MPLS-TP) is a packet transport
technology based on a profile of the MPLS and Pseudowires (PW)
[RFC3031], [RFC3985], and [RFC5085]. MPLS-TP is the application of
MPLS to the construction of packet-switched paths that are analogous
to traditional circuit-switched technologies. Requirements for MPLS-
TP are specified in [RFC5654].
An important feature of a transport network is its survivability
function and the ability to maintain or recover traffic following a
network failure or attack. According to Requirement 56 of [RFC5654],
MPLS-TP must provide protection and restoration mechanisms, and it
must also be possible to require protection of 100% of the traffic on
the protected path (Requirement 58).
1+1 and 1:1 protection can meet these requirements by reserving the
equivalent amount of network resources for the protection paths as is
used by the normal traffic to be protected. While those dedicated
protection mechanisms provide very good protection capabilities, they
are resource inefficient and will increase overall network resource
consumption. Deploying 1+1 and 1:1 protection mechanisms for all
services that require resiliency, dramatically increases network costs.
[RFC5654] also establishes that MPLS-TP should support shared
protection (Requirement 68). 1:n end-to-end protection uses one
protection path to protect n working paths. This improves overall
network utilization, but the resource (bandwidth) allocated to a
protection path is typically not sufficient to protect multiple and
simultaneous failures on different working paths. If multiple working
paths are required to be switched to a protection path concurrently,
the path with the highest priority should be protected first as
described in [I-D.ietf-mpls-tp-survive-fwk].
In 1+1 and 1:1 protection, the end nodes of the working path must be
the same as those of the protection path. The same applies in 1:n
protection where all pairs of end nodes of the n working paths are
the same, and the protection path must also have the same end nodes.
In the event that the MPLS-TP network scales up, the number of Label
Switched Paths (LSPs) having different end nodes will also increase.
The network utilization benefit for sharing protection resources
among multiple protected domains for such LSPs will increase
accordingly.
Requirement 68 of [RFC5654] specifies that MPLS-TP should support 1:n
shared mesh recovery, and Requirement 69 states that MPLS-TP must
support sharing of protection resources. It may be possible that some
working paths are sufficiently disjoint and would be unlikely to be
simultaneously affected by a single network failure. Typically, such
a scenario is hard to track in real network environments where new
services are often added and removed.
Cheung, et al. Expires October 25 2011 [Page 3]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
In mesh protection, network resources may be shared to provide
protection for working paths that do not share the same end nodes at
the edge of a protection domain. This form of protection can make very
efficient use of network resources, but requires careful
synchronization to ensure that only one set of traffic is switched to
the protection resources at any one time.
[RFC4428] defines two shared mesh recovery schemes named (1:1)^n and
(M:N)^n. (1:1)^n recovery scheme is a simple case of (M:N)^n recovery
scheme. In (1:1)^n protection, n working paths are protected by n
dedicated protection paths while sharing the same protection
bandwidth.
The protection bandwidth can be optimized to allow only one of the n
working paths to be protected at the same time. In this case, it
achieves same amount of network utilization with 1:n protection.
(1:1)^n protection defined in [RFC4428] differs with that defined in
[G.808.1] in that the former allows each n pairs of working and
protection paths to have different end nodes while the latter applies
to the case where all pairs have same end nodes.
This document defines a shared mesh protection mechanism based on
the concept of (1:1)^n recovery scheme defined in [RFC4428] and a
coordination to share protection resource based on the protection
switching priority assigned to each pair of working and protection
paths. Each working path is protected by its own end-to-end linear
protection protocol.
The shared mesh protection mechanism defined in this document
utilizes any existing MPLS-TP linear protection switching mechanisms
being developed in the context of MPLS-TP, and assumes that the
protection paths are established and ready to forward data prior to
a failure. Upon detection of a failure on a working path, only two
end nodes of the failed working path exchange their linear protection
protocol messages to switch data traffic. No explicit activation
procedure to switch data traffic to the protection path is needed in
the intermediate nodes along the protection path.
2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
2.1. Acronyms
This document uses the following acronyms:
LoP Lockout of Protection
LSP Label Switched Path
Cheung, et al. Expires October 25 2011 [Page 4]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
MIP Maintenance Entity Group Intermediate Point
MPLS-TP MPLS Transport Profile
P2MP Point-to-multipoint
P2P Point-to-point
PW Pseudowire
SEN Shared End Node
SSN Shared Start Node
2.2. Definitions and Terminology
This document defines two protection domains as follows:
o End-to-end linear protection domain: A protection domain as
defined in [I-D.ietf-mpls-tp-survive-fwk] for protecting a P2P or
P2MP LSP. It consists of two or more end nodes at the boundary of
the domain and a working path and a number of protection paths
between the end nodes. An end-to-end linear protection switching
protocol runs within the domain.
o Shared mesh protection domain: A protection domain for protecting
a number of P2P or P2MP LSPs. It consists of a number of end-to-
end linear protection domains. Each end-to-end linear protection
domain shares protection resources with other domains. The shared
protection resource may be a node, link, transport path segment or
concatenated transport path segment. A shared mesh protection
switching protocol runs within the domain.
3. Shared Mesh Protection
Figure 1 shows a simple case of shared mesh protection. Consider two
paths ABCDE and VWXYZ. These paths do not share end points so they
cannot make use of 1:n protection even though they also do not share
any common points of failure.
ABCDE may be protected by the path APQRE, and VWXYZ can be protected
by the path VPQRZ. For both cases, 1:1 protection may be used.
If there are no failures affecting either of the two working paths,
the network segment PQR carries no traffic. In the event of only one
failure, the segment PQR carries traffic from the working path that
experiences the failure.
Thus, it is possible for the network resources on the segment PQR to
be shared by the two protection paths. In this way, shared mesh
protection can substantially reduce the amount of network resources
that have to be reserved to provide protection of a 1:n nature.
Cheung, et al. Expires October 25 2011 [Page 5]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
Figure 1 : A Shared Mesh Protection Topology
The shared mesh protection domain shown in Figure 1 has two end-to-
end linear protection domains. One consists of two end nodes A and E
and one working path ABCDE and one dedicated protection path APQRE.
And the other consists of end nodes V and Z and one working path
VWXYZ and one dedicated protection path VPQRZ. Those two domains
share a protection segment PQR.
3.1. Protection Switching Priority
A ?Protection Switching Priority? needs to be defined for each end-
to-end linear protection domain that has a protection path sharing
the same protection resource. According to the Protection Switching
Priority, a protection path can displace the other protection path
already using the shared protection resources and protect its own
working path.
The Protection Switching Priority may be provisioned by the network
management system. By default, equal priority is assumed resulting
in first-come first-served recovery. If multiple end-to-end linear
protection domains request protection switching simultaneously, a
pre-defined identifier MUST be used to give priority among them.
The definition of the identifier is for further study.
3.2. Shared Start and End Nodes
A Shared Start Node (SSN) is the first node of a unidirectional
shared protection segment. For example, in Figure 1, node P is a SSN
on unidirectional protection paths A->P->Q->R->E and V->P->Q->R->Z.
In this version of document, SSN does not involve in the shared mesh
protection operation. SSN may act as a Maintenance Intermediate Point
(MIP) for each protection path sharing the same protection resources.
Similarly, a Shared End Node (SEN) is defined as the last node of a
unidirectional shared protection segment (for example, node R on
unidirectional protection paths A->P->Q->R->E and V->P->Q->R->Z in
Figure 1). SEN involves in the shared mesh protection operation for
coordinating the use of the unidirectional shared protection segment.
A SEN acts as a MIP on each protection path that shares the
protection resource.
Cheung, et al. Expires October 25 2011 [Page 6]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
Table 1 summarizes the relationship between SSN and SEN of the shared
protection segment and protection paths sharing it.
Table 1: SSN/SEN in Figure 1
+------------------+-------------------+-----+-----+
| Protection | Shared protection | SSN | SEN |
| paths | segment | | |
+------------------+-------------------+-----+-----+
| A->P->Q->R->E, | P->Q->R | P | R |
| V->P->Q->R->Z | | | |
+------------------+-------------------+-----+-----+
| E->R->Q->P->A, | R->Q->P | R | P |
| Z->R->Q->P->V | | | |
+------------------+-------------------+-----+-----+
Figure 2 shows a more complex example of the shared mesh protection
domain. Three working paths ABC, DEF, and GHJ are protected by the
protection paths APQC, DRSF, and GPQRSJ, respectively.
A------B------C D------E------F
\ / \ /
\ / \ /
\ / \ /
P-----Q----------R-----S
/ \
/ \
/ \
G--------------H---------------J
Figure 2: A More Complex Mesh Protection Example
In this example, the unidirectional protection path G->P->Q->R->S->J
shares resources with two other protection paths, and both P and R
are SSNs, while Q and S are SENs. (See Table 2.)
Table 2: SSN/SEN in Figure 2
+-------------------+-------------------+-----+-----+
| Protection | Shared protection | SSN | SEN |
| paths | segment | | |
+-------------------+-------------------+-----+-----+
| A->P->Q->C, | P->Q | P | Q |
| G->P->Q->R->S->J | | | |
+-------------------+-------------------+-----+-----+
| C->Q->P->A, | Q->P | Q | P |
| J->S->R->Q->P->G | | | |
+-------------------+-------------------+-----+-----+
| D->R->S->F, | R->S | R | S |
| G->P->Q->R->S->J | | | |
+-------------------+-------------------+-----+-----+
| F->S->R->D, | S->R | S | R |
| J->S->R->Q->P->G | | | |
+-------------------+-------------------+-----+-----+
Cheung, et al. Expires October 25 2011 [Page 7]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
3.3. Bridge and Selector Models
Figure 3 shows bridge and selector model for nodes in the shared
mesh protection topology shown in Figure 1. For simplicity, only end
nodes and shared nodes are modelled. Figure 3 illustrates that node
A and E send and receive normal traffic (1) through protection path
(1) and node V and Z send and receive normal traffic (2)through
working path (2).
+-------------------------+ +-------------------------+
|Node A | | Node E|
| bridge | | selector |
| >=============o o----------->--------------------o o===> |
| Normal \ | Working | / Normal|
| (1) o=+ | Path (1) | bridge +=o (1) |
| <===o o-----------|---------<----------o o=====|=======< |
| selector\ | | | / | |
| o=+ | | | +=o | |
+------------|---------|--+ +--|---------|------------+
| | | |
+------------|---------|--+ Protection +--|---------|------------+
|Node P | | | Path (1) | | | Node R|
| | +=========>========|=========+ |
| +===================<========+ |
| | | |
| +--------->------------------+ |
| +-------------------<--------+ | |
| | | | Protection | | | |
+------------|---------|--+ Path (2) +--|---------|------------+
| | | |
+------------|---------|--+ +--|---------|------------+
|Node V | | | | | | Node Z|
| | bridge | | | | | selector |
| >=======|=====o-o=|=========>========|=========|=o-o===> |
| Normal | | | Working | | | Normal|
| (2) | o-+ | Path (2) | | bridge +-o (2) |
| <===o-o=|===================<========|=o-o=============< |
| selector | | | | |
| o-+ | | +-o |
+-------------------------+ +-------------------------+
===: Normal traffics
Figure 3: Bridge and selector model of the example
mesh protection topology shown in Figure 1
Cheung, et al. Expires October 25 2011 [Page 8]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
Each end node has a bridge and selector to send and receive normal
traffic through its working or protection path. Shared nodes have no
bridge or selector and all the protection paths are pre-provisioned
and monitored.
The bandwidth occupied by each working path is B_Wi = B_Ni+B_OAM_Wi;
i.e., the bandwidth for the normal traffic signal #i, plus the
bandwidth for the OAM used to monitor the working path #i. The
bandwidth of the shared protection segment required to protect at
least one normal traffic signal among those flowing through n working
paths is calculated as:
B_P = MAX(B_N1,B_N2,...,B_Nn) + (B_OAM_P1+B_OAM_P2+...+B_OAM_Pn).
The bridge and selector model of shared mesh protection is similar to
that for (1:1)^n protection type defined in [G.808.1], but it differs
in that each working path connects different pair of end nodes, and
each protection path shares a same protection segment.
3.4. Shared Mesh Protection Planning
Shared mesh protection will typically be subject to careful network
planning. This will include:
o Determining which working paths are disjoint and so will not be
subject to common failures.
o Assigning Protection Switching Priority to each end-to-end linear
protection domain so that the protection paths can be activated
correctly.
o Ensuring that working paths of high Protection Switching Priority
do not share resources on their protection paths in such a way
that would mean that one of them could not be protected.
o Enabling the necessary shared mesh protection functions at SEN.
Note that some control plane features of GMPLS may be used to
dynamically install shared mesh protection. These features are out
of scope for this document which focuses on the operation of shared
mesh protection switching once it has been installed.
3.5. Shared Mesh Protection Switching
The shared mesh protection mechanism is designed to fully utilize
the existing end-to-end linear protection switching without any
changes except the following two additional functionalities:
Cheung, et al. Expires October 25 2011 [Page 9]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
o Function to generate a protection switching event message to the
SEN when a switching action occurs at the end-to-end linear
protection domain.
o Function to take a protection locking message from the SEN, and
incorporate it as the Lockout of Protection (LoP) command.
3.5.1. Protection Switching Event
If an end node of a working path detects a failure condition, it
triggers the protection switching and exchanges linear protection
switching protocol messages with its peer end node at the other end
of the working/protection path according to the operation defined in
its own linear protection switching, which is independent of the mesh
protection switching mechanism specified in this document.
At the same time, for the shared mesh protection, the end node
notifies its protection switching event to SENs by sending
a protection switching event message.
The protection switching event message MUST be transmitted immediately
when an end node changes its selector position either from working
to protection or vice versa.
If an end-to-end linear protection domain operates in a bidirectional
protection switching, both end nodes will change their bridge and
selector positions even when a unidirectional failure is detected on
one end node, and therefore, both end nodes will transmit the messages
to their corresponding SENs.
If an end-to-end linear protection domain operates in a unidirectional
protection switching and a unidirectional failure is detected, the end
node that detects the failure will change its selector position
and send the messages to its corresponding SENs.
There are two possible ways that the protection switching event
message could be delivered to SENs.
o Option 1 (Default): Use a P2P message
The end node of the protection path that is becoming active sends
messages directly to each SEN. The path from an end node to a SEN is
a segment of the protection path and the messages are delivered to
each SEN by properly setting the TTL values of the messages for each
SEN. This ensures fate sharing of the messages with other OAM or data
traffics. Alternatively, an end node may have dedicated paths to
communicate with each SEN. The option 1 requires N messages to be sent
if N SENs exist on the protection path. Furthermore, it requires that
the end nodes of the protection path know about all SENs - this is
perfectly possible in simple configurations or through the use of a
dynamic control plane.
Cheung, et al. Expires October 25 2011 [Page 10]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
o Option 2: Use a P2MP message
The end node sends a message similar to a route trace to the peer
end node. It will be passed to all SENs. When a SEN receives the
message, it will simultaneously take a copy of the message for
local use, and forward a copy to the next hop.
An on-demand OAM message like route trace may contain the required
information or the message itself may be transferred using a pre-
provisioned P2MP LSP. In this option, the end node becomes a root
node and all SENs and the peer end node become leaf nodes.
3.5.2. Protection Locking
If a SEN receives the protection switching event notifying that a
protection switching has begun in an end-to-end linear protection
domain, it compares the Protection Switching Priority of the
protection domain notifying the event with those of other protection
domains sharing the same protection segment.
The SEN does not take an action to the protection domains having
higher priorities, but for those having equal or lower priorities, it
sends protection locking messages to those end nodes to prevent any
protection switching to be occurred.
When an end node receives the protection locking message from SEN,
it will take the message as an input to the end-to-end linear
protection switching, and follows the linear protection switching
procedure to process end-to-end LoP command. Since the LoP command
has the highest priority in the linear protection switching protocol,
it will prohibit any further protection switching in the protection
domain. If a protection domain having lower priority currently uses
the shared protection segment, it will stop occupying the protection
bandwidth by the command.
When a SEN receives a protection switching event message notifying
the clearance of protection state from an end node, it sends a
protection locking message to the end node to clear the LoP command.
4. Protocol
4.1. PDU Format
The shared mesh protection protocol messages MUST be sent over a
G-ACh as defined in [RFC5586].
The shared mesh protection protocol messages are as follows:
o Protection switching event message and
o Protection locking message.
Cheung, et al. Expires October 25 2011 [Page 11]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
The channel type in ACH is used to indicate shared mesh protection
protocol. The shared mesh protection protocol does not use ACH TLVs,
therefore the protocol message MUST follow the ACH.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type = Shared Mesh P. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Mesh Protection Protocol Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Shared mesh protection protocol message header
4.1.1. Protection Switching Event Message
The protection switching event message format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection switching event message (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Protection switching event message format
In the message, following field will be provided:
o Version
o An Identifier of the end-to-end linear protection domain to which
the end node sending this message belongs
o Request/State identifying:
- protection path is occupied by normal traffic, or
- protection path is not occupied.
4.1.2. Protection Locking Message
The protection locking message format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection locking message (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Protection locking message format
Cheung, et al. Expires October 25 2011 [Page 12]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
In the message, following field will be provided:
o Version
o An identifier of the end-to-end linear protection domain to which
the end node receiving this message belongs
o Request/State identifying:
- protection lock requested or
- protection unlock requested.
4.2. Message Transmission
A new message must be transmitted immediately. The first three
messages should be transmitted as fast as possible so that fast
protection switching is possible even if one or two messages are lost
or corrupted. The interval of the first three messages should be less
than 3.3ms. Messages after the first three should be transmitted with
the interval of 5 seconds.
If no valid message is received, the last valid received information
remains applicable.
5. Operation of Shared Mesh Protection
This section illustrates the operation of the shared mesh protection
protocol for the exemplary topology shown in Figure 2 with following
assumptions:
o The shared mesh protection domain consists of following end-to-end
linear protection domains (LPDs):
- LPD1: Working path ABC (W1) / Protection path APQC (P1)
- LPD2: Working path GHJ (W2) / Protection path GPQRSJ (P2)
- LPD3: Working path DEF (W3) / Protection path DRSF (P3)
o Protection Switching Priority is LPD1 > LPD2 > LPD3. (LPD1 has the
highest priority.)
o All working paths are protected by 1:1 bidirectional protection
switching.
If a unidirectional failure occurs on the W2 in the direction from
node H to node G as shown in Figure 7, the shared mesh protection
will operate as follows:
a. Node G detects the failure, and initiates the linear protection
switching for the failed W2.
Cheung, et al. Expires October 25 2011 [Page 13]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
b. At the same time, node G generates the protection switching event
message saying that a protection switching event happened to node
P and R, which are SENs for J->H->G.
c. The SEN P compares the protection switching priority of LPD2 with
that of LPD1. In this example, as the priority of LPD1 is higher
than LPD2, SEN P does not take an action to node A.
The SEN R compares the protection switching priority of LPD2 with
that of LPD3. In this example, as the priority of LPD3 is lower
than LPD2, SEN R sends the protection locking message requesting
LoP to node D.
d. Node D takes the protection locking message as an input to the
linear protection switching, and follows the linear protection
switching procedure to process the end-to-end LoP command.
As LPD2 operates in a 1:1 bidirectional protection switching, node J
also changes its bridge and selector state to synchronize with node
G, thus it will generate the protection switching event message to
node S and Q, which are SENs for G->H->J. By the same procedure
described above, the SEN S sends the protection locking message to
node F while the SEN Q does not take an action to node C.
W1 W3
==A======B======C== ==D======E======F==
\ / \ /
\ LPD1 / \ LPD3 /
\ / \ / == : Normal traffic
P=====Q================R=====S
// \\
// LPD2 \\
// \\
==G------xx---------H------------------J==
SF on G<-H W2
Figure 7 : Shared Mesh Protection Example 1
Figure 8 shows a progression from Figure 7. While LPD2 is in
protecting state with its traffic following the protection path P2
(GPQRSJ), another unidirectional failure occurs on the W1 in the
direction from node B to node A.
In this case, the shared mesh protection will operate as follows:
a. Node A detects the failure, and initiates the linear protection
switching for the failed W1.
b. At the same time, node A generates the protection switching event
message saying that a protection switching event happened to node
P, which is SEN for C->B->A.
Cheung, et al. Expires October 25 2011 [Page 14]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
c. The SEN P compares the protection switching priority of LPD1 with
that of LPD2. In this example, as the priority of LPD2 is lower
than LPD1, SEN P sends the protection locking message requesting
LoP to node G.
d. Node G takes the protection locking message as an input to the
linear protection switching, and follows the linear protection
switching procedure to process the end-to-end LoP command.
When LPD2 is forced to lock its protection path P2, it may try to
find another available path. m:n protection or other recovery
mechanism can be used for this, but this discussion is out of
scope of this document.
e. As the node G changes its bridge and selector states from
protection to working, it will generate the protection switching
event message saying that a protection switching event has been
cleared to node P and R, which are SENs for J->H->G.
f. The SEN P compares the protection switching priority of LPD2 with
that of LPD1 and does not take an action to node A, but the SEN R
sends the protection locking message requesting clearance of LoP
to node D.
g. Node D takes the message as an input to the linear protection
switching, and follows the linear protection switching procedure
to clear the end-to-end LoP command.
SF on
A<-B W1 W3
==A-xx---B------C== ==D======E======F==
\\ // \ /
\\ LPD1 // \ LPD3 /
\\ // \ / == : Normal traffic
P=====Q---------------R-----S
/ \
/ LPD2 \
/ \
==G------xx---------H-----------------J==
SF on G<-H W2
Figure 8 : Share Mesh Protection Example 2
Cheung, et al. Expires October 25 2011 [Page 15]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
6. Manageability Considerations
To be added in future version.
7. Security Considerations
To be added in future version.
8. IANA Considerations
To be added in future version.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC5654] Brungard, D., Betts, M., Sprecher, N. and Ueno, S.,
"Requirements of an MPLS Transport Profile", RFC5654,
September 2009.
9.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A. and Callon, R.,
"Multiprotocol Label Switching Architecture", RFC3031,
January 2001.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC3985, March 2005.
[RFC5085] Nadeau, T. and Pignataro, C., "Pseudo Wire (PW) Virtual
Circuit Connectivity Verification ((VCCV): A Control
Channel for Pseudowires", RFC5085, December 2007.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and Farrel A.,
"Multiprotocol Label Switching Transport Profile
Survivability Framework",
draft-ietf-mpls-tp-survive-fwk, work on progress.
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and
subnetwork protection", Recommendation G.808.1, February
2010.
Cheung, et al. Expires October 25 2011 [Page 16]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
[RFC4428] Papadimitriou, D. and E. Mannie, "Analysis of
Generalized Multi-Protocol Label Switching (GMPLS) ?
based Recovery Mechanisms (including Protection and
Restoration) Recovery (Protection and Restoration)",
RFC 4428, March 2006.
Cheung, et al. Expires October 25 2011 [Page 17]
Internet-Draft MPLS-TP Shared Mesh Protection April 2011
Authors' Addresses
Tae-sik Cheung
ETRI
161 Gajeong, Yuseong, Daejeon, 305-700, South Korea
Phone: +82 42 860 5646
Email: cts@etri.re.kr
Jeong-dong Ryoo
ETRI
161 Gajeong, Yuseong, Daejeon, 305-700, South Korea
Phone: +82 42 860 5384
Email: ryoo@etri.re.kr
Cheung, et al. Expires October 25 2011 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 01:29:57 |