Networking Working Group A. Jiang G. Liu X. Dai Internet Draft ZTE Intended status: Standard Track September 29, 2009 Expires: March, 2010 MPLS TP Ring Fault Detection and Localization draft-jiang--mpls-tp-ring-fd-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 March 2010. Abstract This document describes fault detection and localization mechanism for MPLS TP ring network using dedicated control node and bidirectional periodical status OAM message. The mechanism takes advantage of ring topology and greatly reduces OAM sessions and messages among nodes in the ring. Jiang Expires March, 2010 [Page 1] Internet-Draft RING FD September 2009 Table of Contents 1. Introduction............................................. ...2 2. Conventions used in this document............................3 3. Analysis of related documents................................3 4. Fault Detection and Localization Mechanism...................6 4.1. Topology............................................. ..6 4.2. OAM Message Format......................................7 4.3. Rules for Failure Localization..........................9 4.4. Single Ring Link Failure...............................12 4.5. Both Rings Link Failure................................16 4.6. Node Failure.......................................... 19 4.7. Node And Link Failure..................................20 5. Security Considerations.....................................23 6. IANA Considerations........................................ 23 7. Conclusions............................................. ...23 8. References............................................... ..24 8.1. Normative References...................................24 8.2. Informative References.................................24 9. Acknowledgments........................................... .24 1. Introduction MPLS-TP is joint effort of IETF and ITU to standardize MPLS as a transport technology. Ring is a common network topology and has its own characteristics. It is stated in [MPLS-TP Reqs] that there are interests among service providers to optimize OAM and other mechanisms for ring based topology. Ring is different from line in that it is closed, which means message sent by one node will go through other nodes and return back to the originating node. Another difference is that node can send information to other nodes via either of the 2 directions in the ring. We can take advantage of these features of ring to design different optimized solutions for failure detection, localization and protection. Jiang Expires March29, 2010 [Page 2] Internet-Draft RING FD September 2009 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]. 3. Analysis of related documents There are several works on ring based MSPL-TP protection mechanisms. 1) Multiprotocol Label Switching Transport Profile Ring Protection Analysis [draft-yang-mpls-tp-ring-protection-analysis]: This is analysis of 3 possible solutions discussed in IETF and ITU Joint Work Team (JWT) for MPLS-TP, namely Facility Bypass (1:N backup using label stack-outer label is for protection LSP and inner label is to distinguish which of the N protected LSP are inside the protection LSP), Detour (1:1 backup) and ITU-T G.8132. The first 2 methods are specified in [RFC 4090] (RSVP-TE FRR). ITU G.8132 itself also has 2 mechanisms, wrapping and steering. Wrapping is a local repair method similar to MPLS 1:1 backup but need switchover synchronization between nodes adjacent to failure. Steering is 1:1 head end protection mechanism that source and sink (destination) node switch to backup path after they learn failure via APS notification message sent out by node near the failure. 2) MPLS-TP Ring Protection [draft-weingarten-mpls-tp-ring-protection]: This is analysis of 2 protection ring mechanisms for MPLS-TP, namely wrapping and steering. Wrapping is local protection mechanism quite similar to MPLS Detour FRR, and its PLR (point of local repair) and MP (merge point) are the 2 nodes adjacent to the failure. Steering is similar to linear 1:1 protection in that it needs the coordination between ingress node and egress node. Ring Steering is different from generic linear protection in that the former uses OAM between any of the 2 nodes in the ring (full mesh) while the latter uses OAM per LSP. The full mesh is considered to be acceptable for ring with 16 nodes (16*16/2=128 sessions) or less and as an Jiang Expires March29, 2010 [Page 3] Internet-Draft RING FD September 2009 optimization as compared to per LSP OAM when LSP number is greater than 128. 3) Protection for P2MP Ring in MPLS-TP Networks [draft-dai-mpls-tp- p2mp-ring-protection]: This document proposes 2 similar protection solutions for P2MP traffic in ring topology. The common part of the 2 solutions is that detection OAM message is sent by root and received by leaf in ring, after root node knows there is failure somewhere in the ring, it will send multicast traffic in both directions of the ring. And if leaf node can receive detection OAM message from root, it uses working path to receive traffic, otherwise, it uses backup path for traffic. The difference between the 2 solutions is that in one solution detection OAM message is blocked at the last leaf node and root cannot receive it, leaf node notifies root node the failure. While in the other solution, detection OAM message is circled back to root node, root node detects failure by itself if cannot receive the detection OAM message. 4) P2MP traffic protection in MPLS-TP ring topology [draft- ceccarelli-mpls-tp-p2mp-ring]: This document proposes 2 ring protection solutions for P2MP traffic Unidirectional . One is to use local repair MPLS FRR specified in [RFC 4090]. The other is called ROM (Ring Optimized Multicast) FRR. This solution uses upstream node close to failure to redirect traffic to backup LSP that is set up along the other direction of the ring. This solution will change the sequence of receiving nodes. Although it is targeted at multicast protection, it can also be used for unidirectional unicast LSP protection. Below is a summary of the above analysis: +----------+--------+---------+----------+-------+------------------+ | Items | Backup | Fault | Switch | Label | Synchronization | | | | Detect | Control | Stack | (APS) | Jiang Expires March29, 2010 [Page 4] Internet-Draft RING FD September 2009 +----------+--------+---------+----------+-------+------------------+ | FRR | 1:1 |Node Near| Local | N | N | | Detour | | Failure | | | | +----------+--------+---------+----------+-------+------------------+ | FRR | 1:N |Node Near| Local | Y | N | | Facility | | Failure | | | | +----------+--------+---------+----------+-------+------------------+ | G.8132 | 1:1 |Node Near| Local | N | Y | | Wrapping | | Failure | | |Node Near Failure | +----------+--------+---------+----------+-------+------------------+ | G.8132 | 1:1 |Node Near| End Node | N |Nodes Near Failure| | Steering | | Failure | | | End Nodes | +----------+--------+---------+----------+-------+------------------+ |Weingarten| 1:1 |Node Near| Local | N | N | | Wrapping | | Failure | | | | +----------+--------+---------+----------+-------+------------------+ |Weingarten| 1:1 |End Nodes| End Node | N | Y | | Steering | |Full Mesh| | | | +----------+--------+---------+----------+-------+------------------+ | Dai P2MP | 1:1 | Leaf | Root | N | N | | Leaf | | | | | Leaf Notify Root | +----------+--------+---------+----------+-------+------------------+ | Dai P2MP | 1:1 | Root& | Root | N | N | | Leaf | | Leaf | | | | Jiang Expires March29, 2010 [Page 5] Internet-Draft RING FD September 2009 +----------+--------+---------+----------+-------+------------------+ |Ceccarelli| 1:1 | Local | Local | N | N | | FRR | | | | | | +----------+--------+---------+----------+-------+------------------+ |Ceccarelli| 1:1 | Local | Local | N | ? | | ROM | | | | | | +----------+--------+---------+----------+-------+------------------+ Solutions Analysis Existing solutions take advantage of ring for protection. We can also take advantage of ring for failure detection and localization. 4. Fault Detection and Localization Mechanism 4.1. Topology There are 2 unidirectional rings called inner ring and outer ring passing through each node in each ring, one is clockwise and the other is counter clockwise. There is a designated node that will send periodically fault detection OAM message in both rings, passing through each node in each ring and return to itself. If designated node receives detection OAM in each ring, it knows there is no fault. If it cannot receive the OAM in one ring, it knows there is fault in that ring. If there is not fault in ring, other nodes will receive detection OAM from designated node. If other nodes cannot receive detection OAM for some time in one of the or both rings, they know there is fault in corresponding direction, and will generate fault localization (alarm) OAM message, send it in both rings to designated node. Designated node will use these OAM to locate the fault and take actions. The actions taken will be discussed in other document. Jiang Expires March29, 2010 [Page 6] Internet-Draft RING FD September 2009 Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | | | | | ^ V ^ V | | | | | | | | Node------------>--------------Node---------------->------------Node 5 --------------<------------ 4 ---------------<------------ 3 Format of fault detection and localization (alarm) OAM message is shown in next section. 4.2. OAM Message Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Message Length |Message Type |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fault Detection and Localization (alarm) OAM Jiang Expires March29, 2010 [Page 7] Internet-Draft RING FD September 2009 Channel Type-----Fault Detection and Localization (Alarm) OAM Message Length---Length of the Message Message Type-----0: Fault detection OAM from designated node. 1: Fault localization (Alarm) OAM from other node. Other: For future use. S (Detection) ---0: Inner ring. 1: Outer ring. S (Localization)-0: Single ring. 1: Both rings. Node ID-----Identifier of node that sends the OAM message. Ring ID-----Identifier of the ring. When OAM is fault detection OAM from designated node, S is 0 for inner ring and 1 for outer ring. When OAM is fault localization (alarm) OAM, S is 0 for single ring only fault and 1 for fault in both rings. There is another design for S to be 2 bits. S (Detection) ---00: Reserved. 01: Inner ring. 10: Outer ring. 11: Reserved. S (Localization)-00: Reserved. 01: Inner ring. Jiang Expires March29, 2010 [Page 8] Internet-Draft RING FD September 2009 10: Outer ring. 11: Inner and outer ring. Both S field designs can locate the fault. 2 bits design is more intuitive while 1 bit design is more bit efficient. 4.3. Rules for Failure Localization Definitions Bidirectional Localization (Alarm) OAM: OAM that indicates fault in both rings (S is 11 for 2 bits design or 1 for 1 bit design). Unidirectional Localization (Alarm) OAM: OAM that indicates fault in only 1 ring (S is 01 or 10 for 2 bits design or 0 for 1 bit design). Alarm node: Node from which designated node receives Alarm OAM. Non Alarm node: Node from which designated node does not receives Alarm OAM. Alarm ring: Ring in which designated node receives Alarm OAM. Counter Alarm ring: Ring other than Alarm ring. This is a relative concept based on Alarm ring. Designated node may or may not receive Alarm OAM in this ring. Alarm path: Path in Alarm ring from alarm node to designated node. Counter Alarm path: Path in Alarm ring from designated node to alarm node. Alarm parallel path: Path parallel to Alarm path in Counter Alarm ring from designated node to alarm node. Counter Alarm parallel path: Path parallel to Counter Alarm Path in Counter Alarm ring from alarm node to designated node. Fault ring: Ring in which designated node cannot receive detect OAM. Counter Fault ring: Ring other than Fault ring. Reach path: Path in Fault ring from designated node to non alarm node. Counter Reach path: Path in Fault ring from non alarm node to designated node. Jiang Expires March29, 2010 [Page 9] Internet-Draft RING FD September 2009 Reach parallel path: Path in Counter Fault ring from non alarm node to designated node. Counter Reach parallel path: Path in Counter Fault ring from designated node to non alarm node. Rule 1: If Localization (Alarm) OAM is bidirectional, which means designated node can receive Alarm OAM in both directions. Then In Alarm ring There is no fault in Alarm path Reason: Designated node can receive Alarm OAM in this path. And there is fault in Counter Alarm path Reason: Fault in both rings->fault in Alarm ring + No fault in -Alarm path->result In Counter Alarm ring There is fault in Alarm parallel path Reason: Fault in both rings->Fault in Counter Alarm ring- >result Rule 2: If localization OAM is unidirectional Rule 2.1 If there are fault in both rings (designated node can not receive detection OAM in both rings) Then In Alarm ring Jiang Expires March29, 2010 [Page 10] Internet-Draft RING FD September 2009 There is no fault in Alarm path Reason: OAM takes this path There is fault in Counter Alarm Path Reason: Fault in both rings->fault in Alarm ring + No fault in -Alarm path->result In Counter Alarm ring There is no fault in Alarm parallel path Reason: If fault + Fault in Counter Alarm Path->Bidirectional Fault OAM->Contradiction to Unidirectional Fault OAM There is fault in Counter Alarm parallel path Reason: Fault in both rings->Fault in Counter Alarm ring + No fault in Alarm parallel path->Fault in Counter Alarm parallel path If there are fault in only 1 ring (designated node can not receive detection OAM in 1 ring) Rule 2.2 If Alarm ring is fault ring Then There is no fault in Alarm path and Counter Alarm ring And there is fault in Counter Alarm Path Rule 2.3 If Counter Alarm ring is Fault ring Then There is no fault in Alarm ring And there is fault in Alarm parallel path Jiang Expires March29, 2010 [Page 11] Internet-Draft RING FD September 2009 Reason: No fault in Alarm parallel path->No fault detected in alarm node->Contradiction Rule 3 If designated node detect error only in 1 ring (Fault ring) Then There is no fault in Counter Fault ring and reach path Reason: If error in reach path + other ring is OK> Non alarm node will send alarm OAM via other ring> Contradiction There is fault in Counter Reach path Reason: Error in Fault ring>Result 4.4. Single Ring Link Failure This includes single ring single link failure and single ring multiple links failure. Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | | | | | ^ V ^ V | | | | | | | | Node [X] Node---------------->------------Node 5 --------------<------------ 4 ---------------<------------ 3 Single Link Failure Jiang Expires March29, 2010 [Page 12] Internet-Draft RING FD September 2009 Inner ring 5>4 link is broken. (5>4 In) Node 1,2,3,4 can detect error in inner ring since they cannot receive detection OAM in that ring. Node 5, 6 will not detect error in inner ring since they can receive detection OAM in that ring. Node 2,3,4 will send via both rings unidirectional localization OAM to node 1. +----------+--------------+--------------+ | 5>4 In | Detection | Location | +----------+--------------+--------------+ | Node | Out | in | Out | in | +----------+--------------+--------------+ | 1 | | X | | | +----------+--------------+--------------+ | 2 | | X | in | in | +----------+--------------+--------------+ | 3 | | X | in | in | +----------+--------------+--------------+ | 4 | | X | in | in | +----------+--------------+--------------+ | 5 | | | | | +----------+--------------+--------------+ | 6 | | | | | +----------+--------------+--------------+ After receiving all the localization OAM, node 1 can apply previously introduced rules to determine fault location. Jiang Expires March29, 2010 [Page 13] Internet-Draft RING FD September 2009 Rule 2.2(In, 4): In 1>4 X This means to use rule 2.2. Inner ring is Alarm ring, node 4 is alarm node. Result is error in inner ring in path from 1 to 4. Rule 3(In, 5): In 1>6>5 OK This means to use rule 3. Inner ring is Fault ring, node 5 is non alarm node. Result is no error in inner ring in path from 1 to 5. : In 5>4 X This means result is error in inner ring in path from 5 to 4. Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | | | ^ X ^ V | | | | | | Node------------>--------------Node [X] Node 5 --------------<------------ 4 ---------------<------------ 3 Single Ring Multiple Links Failure Inner ring 6>5 and 4>3 links are broken. Node 1,2,3,4,5 can detect error in inner ring since they cannot receive detection OAM in that ring. Node 6 will not detect error in inner ring since it can receive detection OAM in that ring. Jiang Expires March29, 2010 [Page 14] Internet-Draft RING FD September 2009 Node 2,3,4,5 will send via both rings unidirectional localization OAM to node 1. Localization OAM by node 4,5 via inner ring cannot reach node 1 since inner ring 4>3 link is broken. ([in]) +----------+--------------+--------------+ | 6>5 In | Detection | Location | | 4>3 In | | | +----------+--------------+--------------+ | Node | Out | in | Out | in | +----------+--------------+--------------+ | 1 | | X | | | +----------+--------------+--------------+ | 2 | | X | in | in | +----------+--------------+--------------+ | 3 | | X | in | in | +----------+--------------+--------------+ | 4 | | X | in | [in] | +----------+--------------+--------------+ | 5 | | X | in | [in] | +----------+--------------+--------------+ | 6 | | | | | +----------+--------------+--------------+ Rule 2.2(In,3) In 1>3 X Rule 2.3(Out,5) In 1>5 X Rule 3(In,6) In 1>6 OK Jiang Expires March29, 2010 [Page 15] Internet-Draft RING FD September 2009 : In 6>5>4>3 X In this 2 links fault case, inner ring 5>4 link status is unknown to node 1. N links fault detection and localization in 1 ring is similar. 4.5. Both Rings Link Failure Links between node 4 and 5 are broken. Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | | | | | ^ V ^ V | | | | | | | | Node [X] Node---------------->------------Node 5 ---------------[X]---------- 4 ---------------<------------ 3 Both Rings N Links Failure +----------+--------------+--------------+ | 5>4 In | Detection | Location | | 4>5 Out | | | +----------+--------------+--------------+ | Node | Out | in | Out | in | +----------+--------------+--------------+ | 1 | X | X | | | Jiang Expires March29, 2010 [Page 16] Internet-Draft RING FD September 2009 +----------+--------------+--------------+ | 2 | | X | [in] | in | +----------+--------------+--------------+ | 3 | | X | [in] | in | +----------+--------------+--------------+ | 4 | | X | [in] | in | +----------+--------------+--------------+ | 5 | X | | Out |[out] | +----------+--------------+--------------+ | 6 | X | | Out |[out] | +----------+--------------+--------------+ Rule 2.1(In,4): In 1>4 X, 4>1 OK, Out 4>1 X,1>4 OK Rule 2.1(Out,5): In 5>1 X, 1>5 OK, Out 1>5 X,5>1 OK : In 5>4 X Out 4>5 X Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | | | | | ^ X ^ V | | | | | | | | Jiang Expires March29, 2010 [Page 17] Internet-Draft RING FD September 2009 Node---------------->----------Node---------------->------------Node 5 ---------------<------------ 4 ---------------[X]------------3 Both Rings N Links Failure +----------+--------------+--------------+ | 6>5 In | Detection | Location | | 3>4 Out | | | +----------+--------------+--------------+ | Node | Out | in | Out | in | +----------+--------------+--------------+ | 1 | X | X | | | +----------+--------------+--------------+ | 2 | | X | [in] | in | +----------+--------------+--------------+ | 3 | | X | [in] | in | +----------+--------------+--------------+ | 4 | X | X | Both | Both | +----------+--------------+--------------+ | 5 | X | X | Both | Both | +----------+--------------+--------------+ | 6 | X | | Out |[out] | +----------+--------------+--------------+ Rule 1(In,5): In 1>6>5 X 5>1 OK Rule 1(Out,4): Out 1>4 X 4>1 OK Rule 2.1(In,3): Out 3>4>1 X,1>3 OK Jiang Expires March29, 2010 [Page 18] Internet-Draft RING FD September 2009 Rule 2.1(Out,6): In 6>1 X, 1>6 OK : In 6>4 X Out 3>4 X 4.6. Node Failure Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | X X ^ V | | | | [Node 5] [X] Node---------------->------------Node [X] 4 ---------------<------------ 3 Node Failure +----------+--------------+--------------+ | Node 5 | Detection | Location | +----------+--------------+--------------+ | Node | Out | in | Out | in | +----------+--------------+--------------+ | 1 | X | X | | | +----------+--------------+--------------+ | 2 | | X | [in] | in | Jiang Expires March29, 2010 [Page 19] Internet-Draft RING FD September 2009 +----------+--------------+--------------+ | 3 | | X | [in] | in | +----------+--------------+--------------+ | 4 | | X | [in] | in | +----------+--------------+--------------+ | 5 | | | | | +----------+--------------+--------------+ | 6 | X | | Out |[out] | +----------+--------------+--------------+ Rule 2.1(In,4): Out 4>1 X,1>4 OK Rule 2.1(Out,6): In 6>1 X, 1>6 OK : In 6>5>4 X Out 4>5>6 X Actually, node 1 can only know all links to node 5 is broken. Multiple nodes failure detection and localization is similar. 4.7. Node And Link Failure Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | X X ^ V | | | | Jiang Expires March29, 2010 [Page 20] Internet-Draft RING FD September 2009 [Node 5] [X] Node-------------- [X]------------Node [X] 4 ---------------<------------ 3 Node and Link Failure +----------+--------------+--------------+ | Node 5 | Detection | Location | | 4>3 In | | | +----------+--------------+--------------+ | Node | Out | in | Out | in | +----------+--------------+--------------+ | 1 | X | X | | | +----------+--------------+--------------+ | 2 | | X | [in] | in | +----------+--------------+--------------+ | 3 | | X | [in] | in | +----------+--------------+--------------+ | 4 | | X | [in] | [in] | +----------+--------------+--------------+ | 5 | | | | | +----------+--------------+--------------+ | 6 | X | | Out |[out] | +----------+--------------+--------------+ Rule 2.1(In,3): Out 3>1 X,1>3 OK Rule 2.1(Out,6): In 6>1 X, 1>6 OK Jiang Expires March29, 2010 [Page 21] Internet-Draft RING FD September 2009 : In 6>5>4>3 X Out 3>4>5>6 X Although outer ring 3>4 link and node 4 are OK, we cannot know it because all feedback path for node 4 is broken. Node---------->--------------Designated---------->---------------Node 6 ----------<-------------- Node 1 ----------<----------------2 | | | | X X ^ V | | | | [Node 5] [X] Node--------------->-------------Node [X] 4 --------------[X]------------ 3 Node and Link Failure +----------+--------------+--------------+ | Node 5 | Detection | Location | | 4>3 In | | | +----------+--------------+--------------+ | Node | Out | in | Out | in | +----------+--------------+--------------+ | 1 | X | X | | | +----------+--------------+--------------+ | 2 | | X | [in] | in | Jiang Expires March29, 2010 [Page 22] Internet-Draft RING FD September 2009 +----------+--------------+--------------+ | 3 | | X | [in] | in | +----------+--------------+--------------+ | 4 | X | X | [Both]| Both | +----------+--------------+--------------+ | 5 | | | | | +----------+--------------+--------------+ | 6 | X | | Out |[out] | +----------+--------------+--------------+ Rule 1(In,4): In 1>4 X 4>1 OK Rule 2.1(In,3): Out 3>1 X,1>3 OK Rule 2.1(Out,6): In 6>1 X, 1>6 OK : In 6>5>4 X Out 3>4>5>6 X This case is different from previous one in that node 4 has a feedback path to node 1. Multiple nodes and links failure detection and localization is similar. 5. Security Considerations 6. IANA Considerations New GACH Channel Type for ring fault detection and localization OAM message is to be assigned by IANA. 7. Conclusions In this document, fault detection and localization mechanism for ring is discussed in details. It can detect and locate single link and node failure as well as multiple links and nodes failure. This mechanism is suitable for MPLS-TP ring protection requirement. After Jiang Expires March29, 2010 [Page 23] Internet-Draft RING FD September 2009 fault detection and localization, further actions like protection will be taken. 8. References 8.1. Normative References [RFC 2119] Bradner, S., Editor, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC 4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 8.2. Informative References [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. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Jiang Expires March29, 2010 [Page 24] Internet-Draft RING FD September 2009 Authors' Addresses Albert Jiang No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-52870000 Email: albert.john@zte.com.cn Guoman Liu No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-52870000 Email: liu.guoman@zte.com.cn Xuehui Dai No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-52870000 Email: dai.xuehui@zte.com.cn Full Copyright Statement 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. Jiang Expires March29, 2010 [Page 25]