One document matched: draft-weingarten-mpls-tp-ring-protection-00.txt
Network Working Group S. Bryant, Ed.
Internet-Draft Cisco
Intended status: Informational Y. Weingarten, Ed.
Expires: January 8, 2010 N. Sprecher, Ed.
Nokia Siemens Networks
July 7, 2009
MPLS-TP Ring Protection
draft-weingarten-mpls-tp-ring-protection-00.txt
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 January 8, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes mechanisms to address the requirements for
Bryant, et al. Expires January 8, 2010 [Page 1]
Internet-Draft MPLS-TP LP July 2009
protection of ring topologies for Multi-Protocol Label Switching
Transport Profile (MPLS-TP) Label Switched Paths (LSP) and
Pseudowires (PW) on multiple layers. Ring topologies offer the
possibility of reducing the OAM overhead while providing a simplified
protection mechanism. The document analyzes two basic ring
protection schemes and explains how ring protection can be viewed as
an application of linear protection.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3
2. Ring Topologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Ring protection schemes . . . . . . . . . . . . . . . . . . . . 4
3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conclusions and Recommendations . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Bryant, et al. Expires January 8, 2010 [Page 2]
Internet-Draft MPLS-TP LP July 2009
1. Introduction
Multi-Protocol Label Switching Transport Profile (MPLS-TP) is being
standardized as part of a joint effort between the Internet
Engineering Task Force (IETF) and the International Telecommunication
Union Standardization (ITU-T). The specifications are based on the
requirements that were generated from this joint effort.
The requirements for MPLS-TP [MPLS-TP Reqs] inidcates that there is
requirement to support a network that may include sections that
constitute a MPLS-TP ring (either logical or physical). The support
for ring topologies as stated in the requirements is based on the
ability to demonstrate that this topology allows the network to
optimize either the protection or the number of Operations,
Administration & Maintenance (OAM) entities needed to maintain the
network.
This document will examine different proposed mechanisms for
protection of a ring in the context of MPLS-TP and try and determine
how they may optimize the protection and the OAM procedures for a
ring topology. Finally, we plan to show how the generic protection
mechanisms can be used to address the requirements in an optimized
manner.
1.1. Contributing Authors
2. Ring Topologies
The MPLS-TP Requirements [MPLS-TP Reqs] defines a ring as a topology
in which each LSR is connected to exactly two neighboring LSRs, each
via a single point-to-point birectional MPLS-TP capable link. A ring
provides certain advantages in transport networks, including:
o Configuration of point-to-multipoint paths around a ring are
easily accomplished.
o There are always two paths between any two LSRs on a ring that can
be easily identified and associated.
o It is believed that the number of OAM entities needed, in order to
detect faults and perform recovery actions, may be minimized in a
ring topology.
The following figure shows a MPLS-TP ring that is a segment that may
be traversed by numerous LSPs or PWs. In particular, the figure
shows that for all LSP that connect to the ring through LSR-B and
exit the ring from LSR-F we can define two paths through the ring
Bryant, et al. Expires January 8, 2010 [Page 3]
Internet-Draft MPLS-TP LP July 2009
(the first path along B-A-F, and the second B-C-D-E-F).
____
=========>/ LSR\
* \__B_/ *
* @ # *
* @ # *
__* @ # *___
/LSR\ @ #/LSR\
\_C_/ @ #\_A_/
* @ # *
* @ #*
_*_ @ #*_
/LSR\@ /LSR\========>
\_D_/@ \_F_/
* @ @*
* @ @*
* @@____@@*
*/ LSR\*
\__E_/
===> connected LSP *** physical link
### logical path @@@ secondary logical path
Figure 1: A MPLS-TP ring
3. Ring protection schemes
There are two classic mechanisms that have been proposed in various
forums to perform recovery of a topological ring network - "wrapping"
and "steering". The following sub-sections will examine these two
mechanisms.
3.1. Wrapping
The "easier" recovery architecture is "wrapping". This mechanism is
local to the LSRs that are neighbors to the detected fault. When a
fault is detected, the neighboring LSR "wrap" all data traffic around
the ring until arriving at the LSR that is on the opposite side of
the fault, at which point the traffic continues on the normal working
path until the egress from the ring segment.
Bryant, et al. Expires January 8, 2010 [Page 4]
Internet-Draft MPLS-TP LP July 2009
____
=========>/ LSR\
* \__B_/ *
* @@@@@@@# *
* @ @# *
___* @ @# *___
/LSR\ @ @#/LSR\
\_C_/ @ #\_A_/
* @ # *
* @ XX
_*_ @ #*_
/LSR\@ /LSR\
\_D_/@ @\_F_/
* @ @#*
* @ @@#*
* @@____@##*
*/ LSR\*
\__E_/========>
===> connected LSP *** physical link
### logical path @@@ Bypass tunnel
Figure 2: Wrapping protection
In this figure we have a ring with a LSP that enters the ring at
LSR-B and exits at LSR-E. The normal working path follows through
B-A-F-E. If a signal fault is detected on the link A<-->F, then
there is the need for configuring a bypass tunnel [FRR] between A &
F. The traffic will be transmitted over this bypass tunnel from A to
F, and then will continue on the normal working path from F->E.
Essentially, in this protection scheme, the traffic will follow the
path - B-A-B-C-D-E-F-E.
This protection scheme is simple in the sense that there is no need
for coordination between the different LSR in the ring - only the LSR
that detect fault must wrap the traffic, either via the bypass tunnel
(at the near-end) or back to the normal path (at the far-end).
When applying this scheme to a MPLS-TP ring topology segment there
are the following considerations:
o The OAM should be performed at either the link level (by defining
a TCME between each adjacent pair of LSR) and/or per LSR (by
defining a TCME between the LSR that are neighbors of the
protected LSR) when using node-level protection.
o For each protected TCME there is a need to define a bypass tunnel
that traverses the alternate path around the ring to connect
Bryant, et al. Expires January 8, 2010 [Page 5]
Internet-Draft MPLS-TP LP July 2009
between the two ends of the TCME. If protecting both the links
and the nodes, then, for a ring with N nodes, there is a need for
O(2N) bypass tunnels.
o Protection of point-to-multipoint paths is similar to the simple
protection since the data continues along the original path after
wrapping around the ring. The one exception is the case where the
failed node was one of the egress points for the data.
o When wrapping the data is transmitted over some of the links
twice, once in each direction. For example, in the figure above
the traffic is transmitted both B->A and then A->B, later it is
transmitted E->F and F->E. This means that there is additional
bandwith needed for this protection.
o The wrapping also involves greater latency in delivering the
packets, as a result of traversing the entire ring.
o The resource allocation for the bypass tunnels could be
problematic, since most of the tunnels will not be used
simultaneously. One possibility could be to allocate '0'
resources and depend on the NMS to allocate the proper resources
around the ring.
3.2. Steering
The second common scheme for ring protection redirects the traffic
from the ingress point to the alternate route around the ring to the
egress point. This is illustrated in Figure 1 above, where if a
Signal Fault is detected on the working path (B-A-F), then the
traffic is redirected by B to the secondary path (i.e. B-C-D-E-F).
When considering this mechanism it is almost identical to linear 1:1
protection. The two paths around the ring act as the working and
recovery paths. There is need to communicate to the ingress node the
need to switch over to the protection path and there is a need to
coordinate the switchover between the two end-points of the protected
path.
There is one aspect that this diverts from the basic linear
protection scheme - in the number of OAM sessions that would be
neccesary to detect faults in the protected domain. Whereas, using
generic linear protection would neccesitate a separate OAM session
per LSP that traverses the ring, when using ring protection there is
apossiblity of taking proper advantage of the realization that we are
dealing with a ring and reduce the number of OAM sessions. This is
done by defining a OAM session on the basis of a Path Segment Tunnel
(PST), i.e. between any two nodes of the ring. This would lead to
Bryant, et al. Expires January 8, 2010 [Page 6]
Internet-Draft MPLS-TP LP July 2009
the number of OAM sessions for a ring with N nodes to be O(N*N/2),
which could be very large. However, taking into consideration that
the required support of rings, is for rings with up-to 16 nodes -
this implies that the number of OAM sessions should be on the order
of (16*16/2) or 128.
This form of OAM would allow the ingress LSR to directly detect any
faulty situations and redirect traffic to the secondary path without
the need for any additional communication to the LSR.
The following observations can be drawn from using this protection
mechanism for MPLS-TP ring topologies:
o Steering can be based on linear protection for the protection of a
single ring. For cases of interconnected rings further study is
necessary.
o The number of OAM sessions can be greatly minimized, relative to
using plain linear protection, by running the OAM sessions and the
protection mechanisms on the ring segments for all LSPs that
traverse the ring over that specific segment, rather than running
a OAM session per LSP. This fulfills the objective presented in
[MPLS-TP Reqs].
o Point-to-multipoint paths through the ring would need further
consideration.
4. Conclusions and Recommendations
In order to fulfill the requirements for protection of ring
topologies for MPLS-TP networks, according to the conditions stated
in [MPLS-TP Reqs], the protection should be based on MPLS-TP 1:1
linear protection. This mechanism will cover the cases of a single
fault in a single ring topology.
When defining the OAM behavior of the ring nodes, they should define
a segment of all the LSPs that traverse a path within the ring. The
OAM should be executed for each ring path, i.e. PST, to detect
faults and trigger the protection switching within the ring.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Bryant, et al. Expires January 8, 2010 [Page 7]
Internet-Draft MPLS-TP LP July 2009
6. Security Considerations
This document does not by itself raise any particular security
considerations.
7. Acknowledgements
The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.
8. Informative References
[FRR] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Exensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[MPLS-TP Reqs]
Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements for the Trasport Profile of
MPLS", ID draft-ietf-mpls-tp-requirements-09, June 2009.
[MPLS-TP Surv Fwk]
Sprecher, N. and A. Farrel, "MPLS-TP Survivability
Framework", ID draft-ietf-mpls-tp-requirements-09,
April 2009.
Authors' Addresses
Stewart Bryant (editor)
Cisco
United Kingdom
Email: stbryant@cisco.com
Yaacov Weingarten (editor)
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Phone: +972-9-775 1827
Email: yaacov.weingarten@nsn.com
Bryant, et al. Expires January 8, 2010 [Page 8]
Internet-Draft MPLS-TP LP July 2009
Nurit Sprecher (editor)
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Phone: +972-9-775 1229
Email: nurit.sprecher@nsn.com
Bryant, et al. Expires January 8, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 09:52:24 |