One document matched: draft-cheung-mpls-tp-mesh-protection-00.txt
MPLS Working Group Tae-sik Cheung
Internet Draft Jeong-dong Ryoo
Intended status: Standards Track ETRI
Created: March 1, 2010
Expires: September 1, 2010
MPLS-TP Mesh Protection
draft-cheung-mpls-tp-mesh-protection-00.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 mesh protection mechanism
enables multiple recovery paths to share protection resources for the
protection of working paths by coordinating protection switching
operations according to the priority assigned to each 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 September 1, 2010.
Cheung, et al. Expires September 1, 2010 [Page 1]
Internet-Draft MPLS-TP Mesh Protection March 2010
Copyright Notice
Copyright (c) 2010 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
3. Mesh Protection............................................... 4
3.1. Protection Switching Priority............................ 5
3.2. Shared Start and End Nodes............................... 5
3.3. Bridge and Selector in Mesh Protection................... 6
3.4. Shared Mesh Protection Planning.......................... 7
3.5. Mesh Protection Switching................................ 7
3.5.1. Protection State Change Notification................... 7
3.5.2. Protection Locking..................................... 9
4. Operation of Mesh Protection..................................10
5. Manageability Considerations..................................12
6. Security Considerations.......................................12
7. IANA Considerations...........................................12
8. References....................................................12
8.1. Normative References.....................................12
8.2. Informative References...................................12
Cheung, et al. Expires September 1, 2010 [Page 2]
Internet-Draft MPLS-TP Mesh Protection March 2010
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 recovery 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
recovery path to protect n working paths. This improves overall
network utilization, but the resource (bandwidth) allocated to a
recovery 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 recovery 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 points of the working path must be
shared with the recovery path. The same applies in 1:n protection
where all pairs of end nodes of the n working paths are the same, and
the recovery path must also share the same end points.
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 protection domains 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 September 1, 2010 [Page 3]
Internet-Draft MPLS-TP Mesh Protection March 2010
In mesh protection, network resources may be shared to provide
protection for working paths that do not share end points 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.
This document defines a mesh protection mechanism which coordinates
the use of shared protection resource based on the protection
switching priority assigned to each protection domain. The mechanism
builds on the Protection State Coordination (PSC) messages introduced
in [I-D.ietf-mpls-tp-linear-protection].
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].
3. Mesh Protection
Figure 1 shows a simple case of 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. In both cases, 1:1 or 1+1 protection may be used.
However, it can be seen that, if 1:1 protection is used for both
paths, the network segment PQR carries no traffic if there are no
failures affecting either of the two working paths. Furthermore, in
the event of only one failure, the segment PQR carries traffic from
only one of the working paths.
Thus, it is possible for the network resources on the segment PQR to
be shared by the two recovery paths. In this way, 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 September 1, 2010 [Page 4]
Internet-Draft MPLS-TP Mesh Protection March 2010
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
Figure 1 : A Mesh Protection Topology
The remainder of this document sets out some of the challenges
introduced by mesh protection, and describes solutions built on the
Protection State Coordination (PSC) messages introduced for 1:1
linear protection in [I-D.ietf-mpls-tp-linear-protection].
3.1. Protection Switching Priority
A Protection Switching Priority needs to be defined for each
protection domain that has a recovery path sharing the same
protection resource. According to the priority, a recovery path can
displace the other recovery path already using the shared protection
resources and protect its own working path.
The Protection Switching Priority should be provisioned by the
network management system. By default, equal priority is assumed
resulting in first-come first-served recovery.
3.2. Shared Start and End Nodes
A Shared Start Node is the first node of a shared protection segment.
For example, in Figure 1, node P is a Shared Start Node on recovery
paths APQRE and VPQRZ. A Shared Start Node acts as a Maintenance
Intermediate Point (MIP) node for each recovery path sharing the same
protection resources.
Similarly, a Shared End Node is the last node of a shared protection
segment (for example, node R in Figure 1). Shared End Nodes are also
MIPs on the recovery paths that share the protection resources.
Cheung, et al. Expires September 1, 2010 [Page 5]
Internet-Draft MPLS-TP Mesh Protection March 2010
A------B------C D------E------F
\ / \ /
\ / \ /
\ / \ /
P-----Q----------R-----S
/ \
/ \
/ \
G--------------H---------------J
Figure 2: A More Complex Mesh Protection Example
Figure 2 shows a more complex example of mesh protection. Three
working paths ABC, DEF, and GHJ are protected by the recovery paths
APQC, DRSF, and GPQRSJ, respectively.
In this example, the recovery path GPQRSJ shares resources with two
other recovery paths, and both P and R are Shared Start Nodes, while
Q and S are Shared End Nodes.
3.3. Bridge and Selector in Mesh Protection
Figure 3 shows some example bridges and selectors for nodes in the
mesh protection topology shown in Figure 2. At the top of the figure
we see the bridge and selector at node A. Traffic is normally sent
and received to/from node B, but in the event of a protection
switch, the traffic is sent and received to/from node P.
Further down the figure we see the bridge and selector at Node P.
Node P is a Shared Start Node of the protection segment PQ. Normally
it sees no traffic and the settings of the selector and bridge are
not important. However, depending on the protection actions, the
selector can be set to send the traffic from node A or G to node Q,
and the bridge can also be set to send the traffic from node Q to
node A or G.
--<----
| To/From B
Bridge -----+------>
--->------o---> |
-----+---
| | Bridge and Selector
| | at Node A
<---- |
<---------o---- |
Selector <--------+---
| To/From P
-->
Cheung, et al. Expires September 1, 2010 [Page 6]
Internet-Draft MPLS-TP Mesh Protection March 2010
---->--
To/From A |
<------+----- Bridge
| <---o------
---+-----
| | To/From Q Bridge and Switch
| | at Node P
| ---->
| ----o----->
---+--------> Selector
To/From G |
<--
Figure 3 : Examples of Bridges and Selectors
for Mesh Protection
3.4. Mesh Protection Planning
Mesh protection will typically be subject to careful network
planning. This will include:
- Determining which working paths are disjoint and so will not be
subject to common failures.
- Assigning priorities to the working paths so that the recovery
paths can be activated correctly.
- Ensuring that working paths of high protection priority do not
share resources on their recovery paths in such a way that would
mean that one of them could not be protected.
- Enabling the necessary MIP functions at the Shared Start and End
Nodes.
In many networks, it may provide a considerable simplification of
mesh protection to divide the network into distinct protection
domains, however, more effective operation of mesh networks examines
the working paths separately and does not impose a protection domain
model.
Note also that some control plane features of GMPLS may be used to
dynamically install mesh protection. These features are out of scope
for this document which focuses on the operation of mesh protection
switching once it has been installed.
3.5. Mesh Protection Switching
3.5.1. Protection State Change Notification
Cheung, et al. Expires September 1, 2010 [Page 7]
Internet-Draft MPLS-TP Mesh Protection March 2010
If an end node of a working path detects a failure condition, it
triggers the protection switching by exchanging PSC messages with its
peer end node at the other end of the working/recovery path.
Coordination must also be achieved with all of the Shared Nodes
(Shared Start Nodes and Shared End Nodes) along the recovery path to
ensure that:
- the resources allocated to the recovery path are available, and
- any lower priority traffic is displaced from the shared protection
resources before they are allocated to the new recovery path.
Similarly, when protection switching has completed, all Shared Nodes
along the path must be notified.
Protection state change is notified using the PSC messages defined in
[I-D.ietf-mpls-tp-linear-protection]. These messages are sent
from one end of a recovery path to the other, and are intercepted by
the Shared Nodes.
The PSC messages are carried as OAM messages in the GACh. Such
messages are usually targeted specifically at MIPs or MEPs. This
means there are two possible ways that the PSC message could be
delivered to the Shared Nodes.
o Option 1: Use a P2P message
The end node of the recovery path that is becoming active sends
messages directly to each Shared Node along the recovery path (each
Shared Node acts as a MIP). This is done by properly setting the TTL
values of the messages for each MIP. This requires N messages to be
sent if N Shared Nodes exist on the recovery path. Furthermore, it
requires that the end nodes of the recovery path know about all of
the Shared Nodes - this is perfectly possible in simple
configurations or through the use of a dynamic control plane.
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 MIPs in the Shared Nodes. When a
Shared Node 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 a PSC message itself may be transferred using a pre-
provisioned P2MP LSP. In this option, the end node becomes a root
node and all Shared Nodes and the peer end node become leaf nodes.
Cheung, et al. Expires September 1, 2010 [Page 8]
Internet-Draft MPLS-TP Mesh Protection March 2010
An additional, optional stage in the coordination of protection state
involves notifying the end points of recovery paths that could use
the shared resources that the resources are now in use at a
particular priority and that the working paths may no longer be
protected. This feature is for future study.
3.5.2. Protection Locking
If a Shared Node receives a message notifying that a recovery path
needs to use the shared protection resources, it compares the
priority of the recovery path with the priority of the recovery
path (if any) currently using the resources.
If the current use of the shared protection resources has an equal or
higher priority, the Shared Node does nothing. If it has a lower
priority or there is no current use of the shared protection
resources, then the Shared Node locks the protection resources to
disable the current recovery path from accessing the shared
protection resources or prohibit any further protection switching by
a lower priority recovery path.
When the Shared Node receives a message notifying the clearance of
protection state, it unlocks the protection resources.
There are two options on how to lock the protection resources.
o Option 1: Use a PSC Lockout message
A Lockout message defined in [I-D.ietf-mpls-tp-linear-protection] can
be used as a lock message for mesh protection. When two end nodes of
a protection domain receive a Lockout message, it will be the highest
priority request and the protection switching is locked.
This option will also need to consider how to deal with the messages
generated by each end node. In the current version of [I-D.ietf-mpls-
tp-linear-protection], it will not affect the mesh protection
operation because each end node will generate the same messages when
it receives a Lockout from the far-end node (actually from the Shared
Nodes). For other protection types, further considerations will be
discussed in future versions of this document.
o Option 2: Use an OAM Lock message
A Lock instruction message defined in [I-D.ietf-mpls-tp-oam-
framework] may be used as a lock message for mesh protection. When
two end nodes of a protection domain receive a Lock message, they
will consider that the recovery path is unavailable.
In this option, the OAM Lock message may be sent periodically to
maintain the lock state.
Cheung, et al. Expires September 1, 2010 [Page 9]
Internet-Draft MPLS-TP Mesh Protection March 2010
Mesh protection should support both unidirectional and bidirectional
protection. A shared protection resource may be available to provide
bidirectional protection for some working paths, and unidirectional
protection for other working paths. Further considerations for these
requirements will be included in future versions of this document.
4. Operation of Mesh Protection
In Figure 4, the following assumptions are made:
a. There are three working paths WA (ABC), WD (DEF), and WG (GHJ)
with protection priorities PA, PD, and PG, respectively.
b. Protection switching priority is PA > PG > PD. (PA is the highest
protection priority.)
c. All working paths are protected by 1:1 bidirectional protection
switching which utilizes the PSC protocol as described in
[I-D.ietf-mpls-tp-linear-protection]. Since it uses a 1-phase PSC
protocol, no confirmation from the peer node is required.
WA(PA) WD(PD)
A------B------C D------E------F
\ / \ /
\ / \ /
\ / \ /
P-----Q----------R-----S
/ \
/ \
/ WG(PG) \
G------xx------H---------------J
SF on G<-H
Figure 4 : Mesh Protection Example 1
If a failure occurs between nodes G and H as shown in Figure 4, mesh
protection will operate as follows:
a. G detects a failure on the working path WG.
b. G sends a message notifying the protecting state to the Shared
Nodes P, Q, R, and S.
c. Shared Nodes P and Q compare the priority PA with PG and do
nothing (PA > PG), but Shared Nodes R and S compare the priority
PD with PG and send lock messages to end nodes D and F (PD < PG).
Cheung, et al. Expires September 1, 2010 [Page 10]
Internet-Draft MPLS-TP Mesh Protection March 2010
d. WD (i.e., nodes D and F) locks its recovery path and changes its
state from normal to unavailable (i.e., unprotected). (Protection
switching for WD is then prohibited.)
SF on A<-B
WA(PA) WD(PD)
A--xx--B------C D------E------F
\ / \ /
\ / \ /
\ / \ /
P-----Q----------R-----S
/ \
/ \
/ WG(PG) \
G------xx------H---------------J
SF on G<-H
Figure 5 : Mesh Protection Example 2
Figure 5 shows a progression from Figure 4. While WG is in protecting
state with its traffic following the recovery path GPQRSJ, another
failure occurs on the link AB affecting WA. Mesh protection will
operate as follows:
a. Node A detects a failure on the working path WA.
b. A sends a message notifying the protecting state to P and Q.
c. P and Q compare the priority of PG (currently using the shared
protection resources) with PA, and sends a lock message to G and
J.
d. WG locks its recovery path and changes its state from protecting
to unavailable. (The previous protection state is now overruled.)
e. G and J send messages notifying the clearance of protecting state
to Shared Nodes P, Q, R, and S.
f. R and S send unlock messages to D and F.
g. WD unlocks its recovery path and changes its state from
unavailable to normal.
When WG is forced to lock its recovery path, 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.
Cheung, et al. Expires September 1, 2010 [Page 11]
Internet-Draft MPLS-TP Mesh Protection March 2010
5. Manageability Considerations
To be added in future version.
6. Security Considerations
To be added in future version.
7. IANA Considerations
To be added in future version.
8. References
8.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.
8.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.
[I-D.ietf-mpls-tp-linear-protection] Bryant, S., Sprecher, N.,
Van Helvoort, H., Fulignoli, A. and Weingarten, Y.,
"MPLS-TP Linear Protection",
draft-ietf-mpls-tp-linear-protection, work on progress.
Cheung, et al. Expires September 1, 2010 [Page 12]
Internet-Draft MPLS-TP Mesh Protection March 2010
[I-D.ietf-mpls-tp-oam-framework] Busi, S., Niven-Jenkins, B. and
Allan, D., "MPLS-TP OAM Framework",
draft-ietf-mpls-tp-oam-framework, work on progress.
Cheung, et al. Expires September 1, 2010 [Page 13]
Internet-Draft MPLS-TP Mesh Protection March 2010
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 September 1, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:30:57 |