One document matched: draft-cheung-mpls-tp-mesh-protection-04.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="std" docName="draft-cheung-mpls-tp-mesh-protection-04.txt"
ipr="trust200902">
<front>
<title abbrev="MPLS-TP SMP">MPLS-TP Shared Mesh Protection</title>
<author fullname="Tae-sik Cheung" initials="T." surname="Cheung">
<organization>ETRI</organization>
<address>
<postal>
<street>161 Gajeong</street>
<region>Yuseong, Daejeon</region>
<code>305-700</code>
<country>South Korea</country>
</postal>
<phone>+82 42 860 5646</phone>
<email>cts@etri.re.kr</email>
</address>
</author>
<author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
<organization>ETRI</organization>
<address>
<postal>
<street>161 Gajeong</street>
<region>Yuseong, Daejeon</region>
<code>305-700</code>
<country>South Korea</country>
</postal>
<phone>+82 42 860 5384</phone>
<email>ryoo@etri.re.kr</email>
</address>
</author>
<author fullname="Yaacov Weingarten" initials="Y." 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>
<phone>+972-9-775 1827</phone>
<email>yaacov.weingarten@nsn.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="Daniel King" initials="D." surname="King">
<organization>Old Dog Consulting</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>United Kingdom</country>
</postal>
<email>daniel@olddog.co.uk</email>
</address>
</author>
<date year="2011" />
<workgroup>MPLS Working Group</workgroup>
<abstract>
<t>This document describes a mechanism to address the requirement to
support 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.</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>The MPLS Transport Profile (MPLS-TP) is a packet transport technology
based on a profile of the MPLS and Pseudowires (PW) as described in
<xref target="RFC3031" />, <xref target="RFC3985" />, and <xref
target="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
<xref target="RFC5654" />. </t>
<t>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 <xref
target="RFC5654" />, MPLS-TP must provide protection and restoration
mechanisms, and it must also be possible to protect 100% of the traffic
on the protected path (Requirement 58).</t>
<t>1+1 and 1:1 linear protection meets these requirements by reserving the
equivalent amount of network resources for the protection paths as is
allocated to the normal traffic that is being 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.</t>
<t><xref target="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 between the same two end-points.
This improves overall network utilization, but the resource (bandwidth)
allocated to a protection path is typically not sufficient to protect
multiple simultaneous failures on different working paths. If multiple
working paths require concurrent protection switching, the path with the
highest priority should be protected as described in <xref target="RFC6372" />.</t>
<t>In 1+1 and 1:1 protection, the end nodes of the working path must be
the same as those of the protection path. Similarly in 1:n protection 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.</t>
<t>Requirement 68 of <xref target="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.</t>
<t>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 type of protection can make very efficient use of
network resources, but requires coordination of several segments in order to
ensure that only a single traffic flow is switched to the protection resources
at any time. </t>
<t><xref target="RFC4428" /> defines two shared mesh recovery schemes named
(1:1)^n and (M:N)^n. The (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 any time. In this case, it achieves network utilization
similar to 1:n protection.</t>
<t>It should be noted that the (1:1)^n protection scheme described in <xref
target="RFC4428" /> differs with that defined in <xref target="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
the same end nodes.</t>
<t>This document defines a data-plane shared mesh protection mechanism based on
the concept of the (1:1)^n recovery scheme described in <xref target="RFC4428" />
and a protocol for coordination of the shared protection resources. The actual
protection switching is controlled by end-to-end linear protection, while the
usage of the shared resources is based on the protection switching priority
assigned to each pair of working and protection paths.</t>
<t>The shared mesh protection mechanism defined in this document utilizes the
existing MPLS-TP linear protection switching mechanism, 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 the 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.
However, the intermediate nodes that are part of the shared segments need to
coordinate the resource allocation on the shared nodes and this coordination
will be addressed by the protocol proposed in this document.</t>
</section>
<section title="Conventions Used in this Document">
<t>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 <xref target="RFC2119" />.</t>
<section title="Acronyms">
<texttable align="left" style="none">
<preamble>This draft uses the following acronyms:</preamble>
<ttcol align="left"></ttcol>
<ttcol align="left"></ttcol>
<c>G-ACh</c>
<c>Generic Associated Channel Header</c>
<c>LoP</c>
<c>Lockout of Protection</c>
<c>LP</c>
<c>Linear Protection</c>
<c>LSP</c>
<c>Label Switched Path</c>
<c>MIP</c>
<c>Maintenance Entity Group Intermediate Point</c>
<c>MPLS-TP</c>
<c>Transport Profile for MPLS</c>
<c>P2P</c>
<c>Point-to-point</c>
<c>P2MP</c>
<c>Point-to-multipoint</c>
<c>PW</c>
<c>Pseudowire</c>
<c>SEN</c>
<c>Shared End Node</c>
<c>SMP</c>
<c>Shared Mesh Protection</c>
<c>SMPG</c>
<c>Shared Mesh Protection Group</c>
<c>SPME</c>
<c>Sub-Path Maintenance Entity</c>
<c>SSN</c>
<c>Shared Start Node</c>
</texttable>
</section>
<section title="Definitions and Terminology">
<t>This document defines two protection domains as follows:</t>
<t><list style="symbols">
<t>End-to-end linear protection domain: A protection domain as defined
in <xref target="RFC6372"/> for protecting a P2P or P2MP LSP. It
consists of two or more end points at the boundary of the domain and a
working path and a protection path between the end nodes. An end-to-end
linear protection switching protocol runs within the domain.</t>
<t>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.</t>
</list></t>
<t>In addition, we define the following:</t>
<t><list style="symbols">
<t>Shared mesh protection group (SMPG): a protection group includes the
pairs of working and protection paths, whose working paths do not belong
to a single SRLG and whose protection paths share a single sub-segment.
Note that an LSP may belong to multiple protection groups.</t>
</list></t>
</section>
</section>
<section anchor="sec3" title="Shared Mesh Protection Architecture">
<t>The shared mesh protection domain shown in <xref target="Fig1" /> has
two end-to-end linear protection domains. One consists of the two end nodes
A and E and includes one working path, ABCDE, and one dedicated protection
path APQRE. The second consists of end nodes V and Z and one working path,
VWXYZ, and the dedicated protection path, VPQRZ. Those two domains share a
common segment PQR for their protection path. This illustrates a simple
configuration of shared mesh protection. Note that the two working paths,
ABCDE and VWXYZ, do not share end points so they cannot make use of 1:n
protection even though they also do not share any potential common points
of failure.</t>
<t>It is possible to apply linear protection to each of these working paths
individually. If there are no failures affecting either of the two working
paths, the network segment PQR carries no traffic (or only interruptible extra
traffic). In the event of only one failure, the segment PQR carries traffic
from the working path that detected the failure. Only in the event that there
are failures detected on both of the working paths is there a conflict over
the appropriate use of the shared PQR segment. It is important to note that
there are two distinct LSPs (i.e. APQRE and VPQRZ) that are signaled over the
shared segment, and that although we refer to the singular segment, the traffic
is actually being transported on separated transport paths.</t>
<t>Thus, it is possible for the network resources of 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 need to be reserved to provide
protection of the multiple paths within the same protection group.</t>
<figure anchor="Fig1" title="A Shared Mesh Protection Topology">
<artwork><![CDATA[
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
]]></artwork>
</figure>
<section title="Shared Mesh Protection Group">
<t>The two working paths in <xref target="Fig1" />, ABCDE and VWXYZ, are
considered a Shared Mesh Protection Group (SMPG). Such a group is defined
as the set of working paths whose protection path share the resources of a
single shared segment. As pointed out above, there are individual
protection LSP for each of the LP domains, however the resources that are
being shared are the nodes, ports, links and bandwidth of the segment.</t>
<t>The shared resources, for example bandwidth capacity, should be reserved
in partitions according to the different SMPGs at the particular segment.</t>
<figure anchor="Fig2" title="Shared Mesh Protection Groups">
<artwork><![CDATA[
A------B-------C D------E
\ / / \
\ / / \
F---G----H-----J------K-----L
/ / \ \
/ M----------N \
/ \
V-------W-------X-------Y-------Z
]]></artwork>
</figure>
<t>To further clarify, consider the mesh network in <xref target="Fig2" />.
In this figure we have the following working paths and corresponding
protection paths:</t>
<texttable align="left" style="full">
<ttcol align="center">Wx</ttcol>
<ttcol align="left">working path</ttcol>
<ttcol align="left">protection path</ttcol>
<c>W1</c>
<c>A-B-C</c>
<c>A-F-G-H-C</c>
<c>W2</c>
<c>D-E</c>
<c>D-J-K-L-E</c>
<c>W3</c>
<c>M-N</c>
<c>M-J-K-N</c>
<c>W4</c>
<c>V-W-X-Y-Z</c>
<c>V-G-H-J-K-L-Z</c>
</texttable>
<t>In this network we would define three SMPG - characterized by the three
shared segments -
<list style="numbers">
<t>S1 segment G-H – shared by W1 and W4</t>
<t>S2 segment J-K – shared by W2, W3, and W4</t>
<t>S3 segment K-L – shared by W2 and W4</t>
</list></t>
<t>The shared segment is always the smallest segment that is shared by multiple
protection paths. Therefore, even though segment J-K-L is shared by W2 and W4,
we split this into two shared segments - J-K and K-L, since W3 also shares the
resources of segment J-K.</t>
<t>In addition, this demonstrates that a single working path may be a member of
a number of SMPGs. Also a single SMPG may include more than two working paths.</t>
</section>
<section title="Shared Start and End Nodes">
<t>For the sake of the discussion of the SMP operation we designate the two end-
points of the shared protection segment as a Shared Start Node (SSN) and Shared
End Node (SEN). To simplify the discussion this designation is based on
referencing the protection path as a pair of unidirectional LSPs.</t>
<t>A SSN is the first node of a unidirectional shared protection segment. For
example, in <xref target="Fig1" />, node P is a SSN on unidirectional protection
paths A-P-Q-R-E and V-P-Q-R-Z. SSN may act as a Maintenance Entity Group
Intermediate Point (MIP) for each protection path sharing the same protection
resources.</t>
<t>Similarly, a 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). A SEN acts as a MIP on each protection path that shares
the protection resource.</t>
<t>Both end-points are involved in coordinating the use of the unidirectional shared
protection segment during the shared mesh protection operation.</t>
<t>Table 1 summarizes the relationship between SSN and SEN of the shared protection
segment and protection paths sharing it as illustrated in <xref target="Fig1" />.</t>
<texttable style="full">
<preamble>Table 1: SSN/SEN in Figure 1</preamble>
<ttcol align="center">Protection paths</ttcol>
<ttcol align="center">Shared protection segment</ttcol>
<ttcol align="center">SSN</ttcol>
<ttcol align="center">SEN</ttcol>
<c>A-P-Q-R-E, V-P-Q-R-Z</c>
<c>P-Q-R</c>
<c>P</c>
<c>R</c>
<c>E-R-Q-P-A, Z-R-Q-P-V</c>
<c>R-Q-P</c>
<c>R</c>
<c>P</c>
</texttable>
<t><xref target="Fig3" /> 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.</t>
<figure anchor="Fig3" title="A More Complex Mesh Protection Example">
<artwork><![CDATA[
A------B------C D------E------F
\ / \ /
\ / \ /
\ / \ /
P-----Q----------R-----S
/ \
/ \
/ \
G--------------H---------------J
]]></artwork>
</figure>
<texttable style="full">
<preamble>Table 1: SSN/SEN in Figure 3</preamble>
<ttcol align="center">Protection paths</ttcol>
<ttcol align="center">Shared protection segment</ttcol>
<ttcol align="center">SSN</ttcol>
<ttcol align="center">SEN</ttcol>
<c>A-P-Q-C, G-P-Q-R-S-J</c>
<c>P-Q</c>
<c>P</c>
<c>Q</c>
<c>C-Q-P-A, J-S-R-Q-P-G</c>
<c>Q-P</c>
<c>Q</c>
<c>P</c>
<c>D-R-S-F, G-P-Q-R-S-J</c>
<c>R-S</c>
<c>R</c>
<c>S</c>
<c>F-S-R-D, J-S-R-Q-P-G</c>
<c>S-R</c>
<c>S</c>
<c>R</c>
</texttable>
</section>
<section title="Connecting the end-points">
<t>The MPLS-TP Framework <xref target="RFC5921" /> defines the concept of a
Sub-Path Maintenance Entity (SPME) and together with <xref target="RFC5586" />
define the use of the Generic Associated Channel (G-ACh) for communication of
MPLS-TP control protocols between the end-points of a maintenance entity, While
the usual utility of a SPME is to allow tunneling of transport traffic while
monitoring the segment with in-band connectivity verification messages, it is
possible to use concept of a SPME to describe a LSP that is dedicated to carry
a control protocol over the G-ACh between the end-points of the shared protection
segment and the end-points of the protection paths within the SPMG.</t>
<t>For example, referring to the network in <xref target="Fig3" />, we would
configure the following SPME (without identifying the intermediate nodes): A-P,
G-P, P-Q, Q-C, D-R, G-R, S-F, S-J, R-S, and Q-J. These SPME are bidirectional
LSP that are not used to carry any data traffic, only the control traffic described
in <xref target="Protocol" />.</t>
<t>The connection between the end-points of the shared protection segment between
themselves and the end-points of the protection paths within the SPMG is to
coordinate the allocation of the shared segment to a single protection path during
a protection switching condition. This process is described more fully in <xref
target="SwOverview" /></t>
</section>
<section title="Network planning for SMP">
<t>Shared mesh protection will typically be dependent upon careful network
planning. This includes:</t>
<t><list style="symbols">
<t>Preparing the working and protection paths for the different services that
require protection.</t>
<t>Determining which working paths are disjoint and so will not be subject to
common failures. It should be clear that working paths within the same SRLG
should not be included in the same SMPG.</t>
<t>Identifying which protection paths share network resources and can constitute
a shared protection group. Signaling or configuring the proper path information
for the shared segment end-points to allow for communication between the
corresponding end points of the shared segment and the protection path.</t>
<t>Assigning Protection Switching Priority and a path identifier for each working
path within a shared protection group.</t>
<t>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 be unprotected.</t>
<t>Enabling the necessary shared mesh protection functions at the end-points of
the shared protection segments. This includes preparing the different SPME used
for communication between the corresponding end points of the shared segments and
the protection paths, as well as between the end-points of the shared protection
segment.</t>
</list></t>
<t>Note that some control plane features of GMPLS may be used to dynamically
configure 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 configured.</t>
</section>
<section anchor="PreemptRC" title="Preemption and race conditions">
<t>In the normal operation of SMP, when a working path triggers a protection
switch, and requests allocation of the shared resources, the process should
verify that the resources are available and allocate them to the requesting
protection path. There are some cases where the determination of the
availability is not simply determined.</t>
<t>Within the SMP protection domain there is a need to define a "Protection
Switching Priority" for each working path. This Protection Switching
Priority will be used to determine the use of the shared protection resources in
cases of possible preemption. When the shared resources are in use protecting the
traffic of a failed working path and a second working path fails, the SMP process
should compare the Protection Switching Priority of the two working paths and if
the priority of the second path is higher than the priority of the currently
protected traffic, then this second path will preempt the currently protected
traffic. If the second path has a lower or equal priority to the currently
protected traffic, then the second path is locked-out of the protection resources.</t>
<t>The Protection Switching Priority may be provisioned by the network management
system or configured by some other mechanism that is outside the scope of this
document.</t>
<t>There is an additional case where the SMP process needs to make a determination
of which working path should be allocated the shared resources. This is the case
of multiple working paths triggering a protection switch virtually simultaneously.
This may result in a race condition where the two end-points of the shared
protection segment ostensibly receive requests from two different working paths.
By default, working paths with equal priority results in first-come first-served
recovery. If multiple working paths request protection switching simultaneously,
a pre-defined identifier assigned to each working path in the SMP domain MUST be
used to determine the priority among them. The definition of the identifier is
for further study.</t>
</section>
<section anchor="SwOverview" title="SMP Protection Switching Overview">
<t>When a protection switching trigger is activated on any of the working
paths within a shared protection group, then the local linear protection
mechanism (in 1:1 protection mode) should cause a protection switch. If,
as a result of the protection switch action, there is a need to transmit
working data on the protection path then the protection path endpoint should
inform the endpoint of the shared segment of the allocation of the shared
resources.</t>
<t>At this point the shared segment endpoints should notify all of the other
protection paths in the shared protection group that the resources have been
allocated, which could affect the linear protection actions relative to future
triggers.</t>
<section title="LP Protocol extensions for shared protection">
<t>The shared mesh protection mechanism is designed to fully utilize the
existing end-to-end LP switching on the working paths. These LP domains
SHALL operate in revertive mode. The LP protocol should use the normal
procedures for LP without any changes except support for the following
additional functionalities:</t>
<t><list style="symbols">
<t>Function to generate a protection switching event message to the SEN
when a switching trigger occurs at the end-to-end linear protection
domain.</t>
<t>Function to take a protection locking message from the SEN, and
incorporate it as the Lockout of Protection (LoP) command.</t>
<t>Function to notify the SEN when the shared allocated resources may be
released, when the LP domain is reverting to normal state.</t>
</list></t>
</section>
<section title="Protection switching event">
<t>If the end point of a working path detects a switching trigger, it
triggers the protection switching and exchanges LP switching protocol
messages with far end-point. This operation is independent of the SMP
switching mechanism specified in this document.</t>
<t>At the same time, for the operation of SMP, the protection path end-point
notifies its protection switching event to SENs by sending a "protection
switching event" message.</t>
<t>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. The event message SHALL be transmitted over the SPME, that is
configured between the protection path end-point and the SEN, using the G-ACh.
When bidirectional protection switching is being used by the working path, both
end nodes will transmit the event messages to their corresponding SENs using the
properly configured SPME. When unidirectional protection switching and a
unidirectional failure is detected, only the detecting end-point will send the
messages to its corresponding SENs.</t>
<t>The end-point of the protection path that is becoming active (or released)
sends the messages directly to each SEN. This requires that N messages are sent,
where N is the number of SMPG that the working path is a member of. This, of
course, implies that the end-points are pre-configured with knowledge of all
SENs associated with the SPMG.</t>
</section>
<section title="Protection Locking">
<t>When a SEN receives the protection switching event notifying that protection
switching to the protection path has begun in an end-to-end LP domain and that the
shared resources are to be allocated, it compares the Protection Switching Priority
of the working path notifying the event with those of other LP domains in the
same SMPG.</t>
<t>The SEN determines which of the LP domains (within the SPMG) have a lower or
equal priority to that of the notifying LP domain. The SEN then sends a
notification to the end-points of these protection paths that is equivalent to a
"Lockout of Protection" operator command. This notification should
prevent any protection switching actions in those LP domains. For those LP
domains having higher priorities no notification is transmitted and those LP
domains may continue to perform protection switching actions.</t>
<t>When a protection path end point receives the protection locking message from
an SEN, it SHOULD react as if a LoP command was received, according to the
actions dictated by the LP protocol. Since the LoP command has the highest
priority in the LP switching protocol, it will inhibit any further protection
switching in the LP domain.</t>
<t>If the LP domain that received the protection locking message is currently
transmitting traffic on the protection path, it SHALL immediately stop transmitting
the traffic on the protection path and release the allocated resources.</t>
<t>When a SEN receives a protection switching event message indicating that the
shared protection resources are being released, i.e. the LP domain is reverting to
normal state, it sends a protection locking message to the end points of all the
protection paths in the SMPG that were previously locked (i.e. those with equal or
lower priority) to clear the LoP command. The end-point of the protection path
that receives this message SHALL react as if a Clear command was received.</t>
</section>
<section title="Messages between the SEN and SSN">
<t>As was pointed out in <xref target="PreemptRC" /> there are some cases, in
particular in unidirectional protection switching triggers, of simultaneous
protection switching that could cause race conditions. In these use-cases there
is a need for the two end nodes of the shared protection segment, i.e. the SEN
and the SSN, to coordinate the selection of the LP domain that will be allocated
the shared protection resources.</t>
<t>For this purpose, additional messages are defined that are transmitted on the
SPME that is defined between the end nodes of the shared protection segment.
When a SEN receives a protection switching event notification from a LP domain
indicating that protection switching to the protection path has begun, it SHALL
send a message to the SSN that the resources have been allocated, with an
indication of the working path identifier. This allocation needs to be confirmed
for cases where both end nodes report allocation to different working path
identifiers.</t>
</section>
</section>
</section>
<section anchor="Protocol" title="Protocol">
<section title="PDU Format">
<t>The shared mesh protection protocol messages MUST be sent over a G-ACh as
defined in <xref target="RFC5586" />.</t>
<t>The shared mesh protection protocol messages are as follows:</t>
<t><list style="symbols">
<t>Protection switching event message [sent from protection path to SEN]</t>
<t>Protection locking message [sent from SEN to protection path]</t>
<t>Protection release message [sent from SEN to protection path]</t>
<t>Resource allocation(working-path identifier) [sent from SEN to SSN]</t>
<t>Resource allocation acknowledge [sent from SSN to SEN]</t>
</list></t>
<t>The channel type in ACH is used to indicate that the message is a SMP protocol
message. The protocol message MUST follow the ACH.</t>
<figure anchor="Fig4" title="Shared mesh protection protocol message header">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Each protocol message includes the following fields:</t>
<t><list style="symbols">
<t>Version number</t>
<t>Identifier of the working path/LP domain - this is either the identifier
of the LP domain that is sending the message or the working path that was
allocated the resources (dependent upon the message)</t>
<t>Request/State field - identifies the message type as one of the messages
listed above (i.e. Protection Switching Event, Protection Locking, Resource
Allocation, Resource Allocation Ack)</t>
<t>Sub-request field - identifies the sub-function of the message (for example if
protection path is being switched to or released for the Protection Switching
Event message)</t>
</list></t>
</section>
<section title="Message Transmission">
<t>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.</t>
<t>If no valid message is received, the last valid received information
remains applicable.</t>
</section>
</section>
<section title="Operation of Shared Mesh Protection">
<t>This section illustrates the operation of the shared mesh protection
protocol based on the example illustrated in <xref target="Fig3" /> and the
following assumptions:</t>
<t><list style="symbols">
<t>The SMP domain consists of the following end-to-end LP domains (LPDs):
<list style="symbols">
<t>LPD1: Working path ABC (W1) / Protection path APQC (P1)</t>
<t>LPD2: Working path GHJ (W2) / Protection path GPQRSJ (P2)</t>
<t>LPD3: Working path DEF (W3) / Protection path DRSF (P3)</t>
</list></t>
<t>The SMP domain includes the following SMPG:
<list style="symbols">
<t>S1: LPD1 & LPD2</t>
<t>S2: LPD3 & LPD2</t>
</list></t>
<t>Protection Switching Priority is LPD1 > LPD2 > LPD3 (i.e. LPD1 has the
highest priority.)</t>
<t>All working paths are protected by 1:1 bidirectional protection switching.</t>
</list></t>
<t>If a unidirectional failure occurs on W2 in the direction from node H to
node G as shown in <xref target="Fig7" />, SMP will perform the following:
<list style="letters">
<t>Node G detects the failure, and initiates linear protection switching for
the failed W2.</t>
<t>At the same time, node G transmits the protection switching event message
notifying the SENs of the shared protection segments for S1 & S2, i.e.
P and R, that a protection switching event occured to node.</t>
<t>SEN P compares the protection switching priority of LPD2 with those of
other members of S1, i.e. LPD1. In this example, since the priority of LPD1
is higher than LPD2, SEN P does not send any message to node A.</t>
<t>SEN R compares the protection switching priority of LPD2 with those of
other members of S2, i.e. 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.</t>
<t>Node D takes the protection locking message as input to the LP switching,
and follows the LP procedure to process the end-to-end LoP command.</t>
<t>Since LPD2 operates in 1:1 bidirectional protection switching mode, node
J performs the switching operations (i.e. switches its bridge and selector
state) to synchronize with node G, and also transmits the protection switching
event message to node S and Q, which are SENs for G->H->J. Using a
parallel procedure to that described in steps c & d SEN S sends the
protection locking message to node F while the SEN Q does not take an action
to node C.</t>
</list></t>
<figure anchor="Fig7" title="Shared Mesh Protection Example 1">
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t><xref target="Fig8" /> shows a progression from <xref target="Fig7" />. While
LPD2 is in protecting state with its traffic transported on protection path P2,
another unidirectional failure occurs on W1 in the direction from node B to node A.</t>
<t>In this case, the shared mesh protection will operate as follows:
<list style="letters">
<t>Node A detects the failure, and initiates the linear protection switching
for the failed W1.</t>
<t>At the same time, node A transmits the protection switching event
message notifying SEN for S1, i.e. node P, that a protection switching
event occurred.</t>
<t>SEN P compares the protection switching priority of LPD1 with those of
the other members in S1, in this case LPD2. In this example, since the
priority of LPD2 is lower than LPD1, SEN P sends the protection locking
message requesting LoP to node G.</t>
<t>Node G accepts the protection locking message as input to linear
protection switching, and follows LP procedure to process the 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 may be
used for this, but this discussion is out of scope for this document.</t>
<t>As node G changes its bridge and selector states from protection to
working, it will transmit the protection switching event message to the SENs
of S1 & S2, i.e. P & R, notifying that the shared protection resources
should be released.</t>
<t>SEN P compares the protection switching priority of LPD2 with the other
members of S1, i.e. LPD1, and does not transmit any message to node A, but
SEN R sends the protection locking message requesting clearance of LoP to
node D, after comparing the protection switching priorities of the members of
S2.</t>
<t>Node D accepts the message as input to the linear protection switching, and
follows the LP procedures to clear the LoP command.</t>
</list></t>
<figure anchor="Fig8" title="Shared Mesh Protection Example 2">
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
<section title="Manageability Considerations">
<t>To be added in future version.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>To be added in future version.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To be added in future version.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--Begin inclusion reference.RFC.2119 -->
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization></organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
<seriesInfo name="BCP" value="14" />
</reference>
<!-- End inclusion reference.RFC.2119 -->
<!-- Begin inclusion reference.RFC5654 -->
<reference anchor="RFC5654">
<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="Tom Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="Carlos 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.RF5654 -->
</references>
<references title="Informative References">
<!-- Begin inclusion reference.RFC.3031 -->
<reference anchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author fullname="Eric Rosen" initials="E." surname="Rosen">
<organization></organization>
</author>
<author fullname="A.Viswanathan" initials="A." surname="Viswanathan">
<organization></organization>
</author>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization></organization>
</author>
<date month="January" year="2001" />
</front>
<seriesInfo name="RFC" value="3031" />
</reference>
<!-- End inclusion reference.RFC.3031 -->
<!--Begin inclusion reference.RFC.3985 -->
<reference anchor="RFC3985">
<front>
<title>Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</title>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="P. Pate" initials="P." surname="Pate">
<organization></organization>
</author>
<date month="March" year="2005" />
</front>
<seriesInfo name="RFC" value="3985" />
</reference>
<!-- End inclusion reference.RFC.3985 -->
<!-- Begin inclusion reference.draft.MPLS.TP.Framework -->
<reference anchor="RFC5921">
<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="July" year="2010" />
<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="RFC" value="5921" />
</reference>
<!-- End inclusion reference.RFC5921 -->
<!-- Begin inclusion reference.RFC.6372 -->
<reference anchor="RFC6372">
<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="Sept" year="2011" />
<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="RFC" value="6372" />
</reference>
<!-- End inclusion reference.RFC6372 -->
<!-- Begin inclusion reference.RFC.5085 -->
<reference anchor="RFC5085">
<front>
<title>Pseudo Wire (PW) Virtual Circuit Connectivity Verification ((VCCV): A
Control Channel for Pseudowires</title>
<author fullname="Tom Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Vigoureux" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="Dec" year="2007" />
</front>
<seriesInfo name="RFC" value="5085" />
</reference>
<!-- End inclusion reference.RFC.5085 -->
<!-- Begin inclusion reference.RFC.5586 -->
<reference anchor="RFC5586">
<front>
<title>MPLS Generic Associated Channel</title>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="Martin Vigoureux" initials="M." surname="Vigoureux">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
<seriesInfo name="RFC" value="5586" />
</reference>
<!-- End inclusion reference.RFC.5586 -->
<!-- Begin inclusion reference.RFC.4428 -->
<reference anchor="RFC4428">
<front>
<title>Analysis of Generalized Multi-Protocol Label Switching (GMPLS) based
Recovery Mechanisms (including Protection and Restoration) Recovery (Protection
and Restoration)</title>
<author fullname="Dimitri Papadimitriou" initials="D."
surname="Papadimitriou">
<organization></organization>
</author>
<author fullname="Eric Mannie" initials="E." surname="Mannie">
<organization></organization>
</author>
<date month="March" year="2006" />
</front>
<seriesInfo name="RFC" value="4428" />
</reference>
<!-- End inclusion reference.RFC.4428 -->
<!-- Begin inclusion reference.ITU-T.G.808.1 -->
<reference anchor="G.808.1">
<front>
<title>Generic Protection Switching - Linear trail and subnetwork protection</title>
<author fullname="ITU-T SG15" surname="SG15" />
<date month="Feb" year="2010" />
</front>
<seriesInfo name="ITU-T" value="G.808.1" />
</reference>
<!-- End inclusion reference.G.808.1.ITU -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:33 |