One document matched: draft-jiang--mpls-tp-ring-fd-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:10:31 |