MPLS Working Group J. Yang
Internet-Draft H. Su
Intended status: Informational ZTE Corporation
Expires: April 30, 2009 October 27, 2008
Multiprotocol Label Switching Transport Profile Ring Protection Analysis
draft-yang-mpls-tp-ring-protection-analysis-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 30, 2009.
Abstract
The three potential solutions to the MPLS-TP ring protection were
addressed in the report of the IETF-ITU-T Joint Working Team(JWT).
Each solution has different attributes and advantages. This document
provides an analysis for MPLS-TP based on the ring protection.
Yang & Su Expires April 30, 2009 [Page 1]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Facility bypass . . . . . . . . . . . . . . . . . . . . . . . 4
4. Detours . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. ITU-T G.8132 . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Solutions analysis . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Capability analysis . . . . . . . . . . . . . . . . . . . 6
6.2. Requirements analysis . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
10.3. URL References . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Yang & Su Expires April 30, 2009 [Page 2]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
1. Introduction
Network survivability reflects the ability of a network to continue
to function during failures and recovery. The three potential
solutions to the MPLS-TP ring protection were addressed in the report
of the IETF - ITU-T Joint Working Team (JWT). Each solution has
different attributes and advantages. This document provides an
analysis for MPLS-TP-based ring protection.
These three potential solutions are:
- Facility bypass: A single facility bypass LSP protects all LSPs
over a specific link by wrapping traffic.
- Detours: A detour LSP can be used for optimal traffic delivery to
the egress point (without wrapping).
- ITU-T G.8132: It defines a ring protection that includes
additional capabilities to the MPLS protection schemes, by
supporting coordinated protection in case of multiple failures
(using single protection mechanism for all cases).
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.
The following terminologies were defined in [RFC4090].
LSR: Label-Switch Router.
LSP: An MPLS Label-Switched Path. In this document, an LSP will
always be explicitly routed.
PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a
detour LSP.
One-to-One Backup: A local repair method in which a backup LSP is
separately created for each protected LSP at a PLR.
Protected LSP: An LSP is said to be protected at a given hop if it
has one or multiple associated backup tunnels originating at that
hop.
Detour LSP: The LSP that is used to re-route traffic around a failure
in one-to-one backup.
Yang & Su Expires April 30, 2009 [Page 3]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing
over a common facility.
Backup Path: The LSP that is responsible for backing up one protected
LSP. A backup path refers to either a detour LSP or a backup tunnel.
MP: Merge Point. The LSR where one or more backup tunnels rejoin the
path of the protected LSP downstream of the potential failure. The
same LSR may be both an MP and a PLR simultaneously.
The following terminologies were defined in [ITU-T G.8132 draft].
APS channel: Automatic Protection Switch (APS) Channel is used to
carry information between the two ends of a linear protection group
to coordinate the head-end bridge with the tail-end selector for 1:n
protection, and to coordinate the selectors in both directions in the
case of bidirectional protection.
Bridge: The function that connects the normal and extra traffic
signals to the working and protection transport entities.
OAM: Operation, Administration and Maintenance.
SF: Signal Fail.
3. Facility bypass
The facility bypass is one of the backup methods defined in
[RFC4090]. It created a single LSP(bypass LSP tunnel) that serves to
back up a set of LSPs. The bypass tunnel must intersect the path of
the original LSP(s) somewhere downstream of the PLR.
The PLR built a bypass tunnel that protects against the failure of a
link or a node. When a failure occurs along a protected LSP, the PLR
redirects traffic into the appropriate bypass tunnel. If protected
link fails, the PLR will switch traffic received from upstream LSR on
the protected LSP onto the bypass tunnel. The label will be switched
for one which was assigned by MP to indicate the protected LSP, and
the bypass tunnel's label will then be pushed onto the label-stack of
the redirected packets. So there will be two levels of labels used
in the bypass tunnel. When MP receives the redirected packets, it
pops the label that it assigned for bypass tunnel and uses the label
that it assigned for protected LSP to forward the packet.
The Facility bypass technique provides that using the same bypass
tunnel protects many LSPs which traverse the same links or nodes.
Yang & Su Expires April 30, 2009 [Page 4]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
Link protection: The PLR and MP are connected through a direct link
and the primary LSP traverses this link.When the link fails, traffic
is switched to the backup LSP.
Node protection: The PLR and MP are connected through a device and
the primary LSP traverses this device. When the device fails,
traffic is switched to the backup LSP.
4. Detours
The detours one to one backup is the other method defined in
[RFC4090]. In the one-to-one backup method, a label-switched path is
established that intersects the original LSP somewhere downstream of
the point of link or node failure. A PLR computes a separate backup
LSP, called a detour LSP, for each LSP that the PLR protects.
When a failure occurs along the protected LSP, the PLR redirects
traffic onto the local detour, using the label received when PLR
created the detour. When MP receives traffic with the label provided
for PLR's detour, it will switch that traffic onto the original LSP,
using the label received from the node of MP's next hop. In the
detour mode, the depth of label stack will not increase.
It provides an optimized detour methord in [MPLS-TP JWT REPORT] to
protect an LSP that traverses N nodes only using one detour tunnel
without wrapping.
5. ITU-T G.8132
The T-MPLS Shared Protection Ring (TM-SPRing) protection switching
mechanisms are specified in [ITU-T G.8132 draft]. It provides the
protection connection as a ring topology to protect the working LSP.
Each section (span) in the ring is monitored by sending CV OAM with
periodicity of 3.3ms and Span failures are detected as absence of 3
consecutive CV frames. Each node has an APS controller that sends
and receives APS messages. These messages inform the states of the
ring.
When failure occurs, the nodes adjacent to the failure enter the
switching state and sends APS SF message to neighbor nodes. The
traffic is switching to the protection connection. When the other
nodes in the ring receive the SF message, they enter pass-through
state (i.e. allow forwarding on the protection LSP) and forward the
APS messages without modification.
The APS protocol and associated OAM functions shall accommodate the
Yang & Su Expires April 30, 2009 [Page 5]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
capability to upgrade the ring (node insertion /removal), limiting
the possible impact on existing traffic on the ring. The same
mechanism with a single protection connection restores all traffic
possible: p2p, p2mp connections, fiber or node failure, single or
multiple failures.
There are two solutions, the wrapping and the steering techniques in
TM-SPRing protection.
- The Wrapping technique: It implies that the node that detects a
failure sends a request through the APS protocol to the node
adjacent to the failure. When the node detects a failure or
receives a bridge request through APS protocol addressed to this
node, normal traffic transmitted towards the failed span is
switched to the opposite direction (away from the failure). This
traffic travels the long way around the ring to the other
switching node where it is switched back onto the working
direction. The switching nodes restore normal traffic flow when
the failure or APS protocol request is cleared.
- The Steering technique: It implies that the node that detects a
failure sends a request through the APS protocol to the node
adjacent to the failure and all nodes in the ring process this APS
information. In case of p2p connections, for each affected
connection the source node (that adds traffic to the ring) and the
sink node (that drops the traffic from the ring) perform switching
from working to the protection direction, and restore normal
traffic flow when the failure or APS protocol request is cleared.
6. Solutions analysis
As described in the sections above, the each solution has different
attributes and advantages. This section will provide an analysis for
MPLS-TP based ring protection.
6.1. Capability analysis
The table1 shows the capability analysis of the different solutions.
- Amounts of the backup LSP: The both Detour and G.8132 solutions
require the same amounts of the backup LSPs to the original LSPs.
However, the Bypass method can use the one backup LSP to protect
many original LSPs.
Yang & Su Expires April 30, 2009 [Page 6]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
- Bandwith utilization ratio: When protection occurs, the G.8132
steering method can bridge and switch directly at the nodes with
traffic ingress and egress. In the other sloutions including the
bypass, detour and G.8132 wrapping, the traffic in case of
protection travels the long way around the ring to the other
switching node where it is switched back onto the working
direction. So the G.8132 steering is the highest one of the
bandwidth utilization ratio.
- The complexity of configuration and APS: G.8132 needs the APS
protocol to implement the switch and the bridge.
- Packets disorder: There is a MP in the bypass and detour solution.
The merge operation may cause packets disorder.
+-----------------+----------+------------+------------+------------+
| Items | Bypass | Detour | G.8132 | G.8132 |
| | | | wrapping | steering |
+-----------------+----------+------------+------------+------------+
| Amounts of the | Less | As many as | As many as | As many as |
| backup LSP | | the | the | the |
| | | protected | protected | protected |
| | | LSP | LSP | LSP |
+-----------------+----------+------------+------------+------------+
| Bandwidth | The | The second | The third | The |
| utilization | third | one | one | highest |
| ratio | one | | | |
+-----------------+----------+------------+------------+------------+
| Bandwidth share | Support | Support | Support | Support |
+-----------------+----------+------------+------------+------------+
| Complexity | Simple | Simple | complex | The most |
| (configuration, | | | | complex |
| APS) | | | | |
+-----------------+----------+------------+------------+------------+
| Packets | Yes | Yes | No | No |
| disorder | | | | |
+-----------------+----------+------------+------------+------------+
| APS protocol | No need | No need | Need | Need |
+-----------------+----------+------------+------------+------------+
| Lable stack | Increase | Changeless | Changeless | Changeless |
| | one more | | | |
| | layer | | | |
+-----------------+----------+------------+------------+------------+
Table 1: solutions analysis
Yang & Su Expires April 30, 2009 [Page 7]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
6.2. Requirements analysis
The table2 shows the requirements analysis of the different
solutions. These requirements are based on the [MPLS-TP JWT REPORT]
and the [MPLS-TP Survivability Framework].
- Node failure: The all solutions support the node failure. But the
bypass method must establish as many as N bypass tunnels to
protect the N nodes in the protected LSP. And the other LSP
should be established in order to protect the link between the
protected node and its upstream node.
- Mutiple failures: One bypass tunnel can only protect single
failure of the protected LSP, a node or a link failure. It can't
provide the protection of multiple failures.
- External commands: External commands in the bypass and the detour
solution are not sufficient,should be extended to meet the
requirements.
- Bidirectional LSPs: The issue to force both ends pick same merge
point for each direction in detour methord is to be studied.
- Application to P2MP LSPs: P2MP LSP protection based on FRR is
covered in [RFC 4875], but if it could be used or not in ring
topology are to be studied.
- Operator's Qos objectives on protection path: In the bypass
solution, the many protected LSPs share one bypass tunnel. When
protection occurs, all the protected the traffic redirect onto the
bypass tunnel. EIR services from different protected LSPs can't
be distinguished. The Qos of these EIR services can't be
guaranteed.
+-----------------------+---------+---------+-----------+-----------+
| Items | Bypass | Detour | G.8132 | G.8132 |
| | | | wrapping | steering |
+-----------------------+---------+---------+-----------+-----------+
| Node failure | Support | Support | Support | Support |
+-----------------------+---------+---------+-----------+-----------+
| Multiple failures | Not | Support | Support | Support |
| | support | | | |
+-----------------------+---------+---------+-----------+-----------+
| External commands | Partial | Partial | Complete | Complete |
+-----------------------+---------+---------+-----------+-----------+
| Bidirectional LSPs | Support | TBD | Support | Support |
+-----------------------+---------+---------+-----------+-----------+
Yang & Su Expires April 30, 2009 [Page 8]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
+-----------------------+---------+---------+-----------+-----------+
| Application to P2MP | TBD | TBD | Support | TBD |
| LSPs | | | | |
+-----------------------+---------+---------+-----------+-----------+
| Protection ration of | Support | Support | Support | Support |
| 100% | | | | |
+-----------------------+---------+---------+-----------+-----------+
| Operator's QoS | Partial | Support | Support | Support |
| objectives on | | | | |
| protection path | | | | |
+-----------------------+---------+---------+-----------+-----------+
Table 2: solutions analysis
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Acknowledgments
TBD.
10. References
10.1. Normative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
10.2. Informative References
[ITUT-G.8132 Draft]
ITU-T, "Draft ITU-T Recommendation G.8132 (T-MPLS shared
protection ring)", November 2007.
[MPLS-TP JWT REPORT]
S.Bryant, L.Andersson, "JWT Report on MPLS Architectural
Considerations for a Transport Profile", July 2008.
Yang & Su Expires April 30, 2009 [Page 9]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
[MPLS-TP Survivability Framework]
N. Sprecher, A. Farrel, "Multiprotocol Label Switching
Transport Profile Survivability Framework", July 2008.
10.3. URL References
[MPLS-TP-22]
IETF - ITU-T Joint Working Team, "", 2008,
<http://www.example.com/dominator.html>.
Authors' Addresses
Jian Yang
ZTE Corporation
5F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road
Nanshan District,Shenzhen 518055
P.R.China
Phone: +86 755 26773731
Email: yang_jian@zte.com.cn
Hui Su
ZTE Corporation
5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road
Nanshan District,Shenzhen 518055
P.R.China
Phone: +86 755 26773673
Email: su.hui@zte.com.cn
Yang & Su Expires April 30, 2009 [Page 10]
Internet-Draft MPLS-TP Ring Protection Analysis October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Yang & Su Expires April 30, 2009 [Page 11]