idnits 2.17.1 draft-liu-mpls-tp-ring-protection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 25, 2010) is 4952 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MPLS-TP-22' is mentioned on line 626, but not defined == Unused Reference: 'IETF RFC4090' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'IETF RFC5654' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'IETF RFC5921' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC 5586' is defined on line 597, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5921 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group G. Liu 3 Internet-Draft J. Yang 4 Intended status: Standards Track l. Jiang 5 Expires: March 29, 2011 z. Fu 6 ZTE Corporation 7 September 25, 2010 9 Multiprotocol Label Switching Transport Profile Ring Protection 10 draft-liu-mpls-tp-ring-protection-01 12 Abstract 14 according to RFC 5654 MPLS-TP Requirement, there are two requirements 15 : requirement 56.B Recovery techniques used for P2P and P2MP should 16 be identical to simplify implementation and operation.another 17 requirement as section 2.5.6.1 describles: within the context of 18 recovery in MPLS-TP networks,the optimization criteria considered in 19 ring topologies are as follows: 1 minimize the number of OAM entities 20 that are needed to trigger the recovery operation; 2 Minimize the 21 number of elements of recovery in the ring; 3 Minimize the number of 22 labels required for the protection paths across the ring; 4 minimize 23 the amount of control and management plane transactions during 24 maintenance operation. this decument will describle and provide two 25 types of ring protection solutions. both solutions can satisfy these 26 requirements of recovery in mpls-tp ring network. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. This document may not be modified, 32 and derivative works of it may not be created, and it may not be 33 published except as an Internet-Draft. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 29, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. proposed ring protection solution . . . . . . . . . . . . . . 4 66 3.1. sub-path tunnel protection solution . . . . . . . . . . . 4 67 3.2. Extend Steering protection . . . . . . . . . . . . . . . . 8 68 3.2.1. P2P Service Protection . . . . . . . . . . . . . . . . 8 69 3.2.2. P2MP Service Protection . . . . . . . . . . . . . . . 10 70 3.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 this draft mainly describes two new ring protection solutions, 83 solution 1 is based on sub-path Tunnel protection solution to 84 implement to protect all kind of service by protecting sub-path when 85 there are a few faults or defects in the ring .and there are fewer 86 Sub-Path Tunnels to be set up in the ring network. while solution 2 87 is based on Steering protection solution of G.8132 to be able to 88 implement to protect P2P or P2MP service very quickly. at last it 89 provides the comparsion of the two ring protection solutions from the 90 view of a protection performance and effect. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC-2119. 98 OAM: Operations, Administration, Maintenance 100 LSP: Label Switched Path. 102 TLV: Type Length Value 104 LSR:Label Switching Router 106 P2MP:Point to Multi-Point 108 P2P:Point to Point 110 APS:Automatic Protection Switch 112 PSC:Protection Switching Coordination 114 SD:Signal Degrade 116 SF:Signal Fail 118 BFD:Bidirectional Forward Detection 120 MPLS:Multi-Protocol Label Switching 122 MPLS-TP:Multi-Protocol Label Switching Transport Profile 124 TTSI:Trail Termination Source Identifier_source LER ID+LSP ID 126 MEP:MEG End Point 127 LER: Label Edge Router 129 PST: Path Segment Tunnel 131 SPME: Sub-Path maintenace entity 133 3. proposed ring protection solution 135 this section mainly proposed two types of ring protection 136 solution.the two ring protection solutions need to detect and notify 137 the failure of the ring by OAM or APS functions,so that the source 138 node of working sub-path tunnel and LSP path will switch these 139 protected services into protecting sub-path tunnel and LSP path.but 140 the two ring protection solutions also have a few differences. 141 solution 1 provide protection of all failure LSP services of a 142 working sub-path tunnel by setting up protecting sub-path tunnel 143 ,while the later ring protection solution provides one dedicate 144 protection path for each working LSP path to protect and recovery all 145 failure services in the ring. 147 3.1. sub-path tunnel protection solution 149 This ring protection solution in MPLS-TP network mainly make use of 150 protecting sub-path tunnel to protect all LSP services of a failure 151 working sub-path tunnel .firstly two prime transfer nodes will be 152 selected for the ring. and the two prime transfer nodes would backup 153 for each other to ensure to transport service under the condition 154 that one prime transfer node has failure. and other nodes in the ring 155 need to pre-configured and set up two bidirectional sub-path tunnel 156 separately in the direction of clockwise and anticlockwise along the 157 ring to the two prime transfer nodes ; and there is CC or CV packet 158 to verify the connectivity of every sub-path tunnel.and each sub-path 159 Tunnel will reserve 50 percent bandwidth or capacity to use for 160 protecting another working sub-path tunnel. 162 when an end node of a working sub-path tunnel detects a failure in 163 its own sub-path tunnel by OAM fucntion, it will generate a State 164 notify message (APS or PSC) to send to another end node of the sub- 165 path tunnel through pre-configured relative protecting sub-path. and 166 the frame format of the state notify message is as the following: 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | 0001| 0000 | 00000000 | channel type (APS or PSC)| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 | state control message | 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 1 178 when another end node of the sub-path tunnel received State Notify 179 messgae from peer node, it would process the message and switch to 180 its relative protecting sub-path to transport all LSP Services of the 181 failure working sub-path tunnel. for example, there is the following 182 ring include A ,B, C,D,E,F node. and A and D node is configured as 183 two prime transfer nodes separately for the ring.while working and 184 protecting sub-path tunnel will be set up and pre-configured between 185 two primer transfer nodes A ,D and other nodes include B,C,D,E,F.it 186 will need to configure and set up 16 sub-path tunnel in the ring. for 187 C node, there need to set up four bidirectional sub-path 188 tunnels,which are separately working sub-path tunnel(A-B-C) 189 identified by signal (@) and protecting sub-path tunnel ( A-F-E-D-C) 190 identified by signal (#) between Prime node A and source node C . at 191 the same time, they are including bidirectional working sub-path 192 tunnel(C-D) identified by signal(*) and protecting sub-path tunnel(C- 193 B-A-F-E-D) identified by signal($) between prime node D and soure 194 node C, as the following figure. 196 Prime node 197 | 198 +---+ ######## +---+ 199 | F |-------------| A | 200 +---+ $ $ $ $ +---+ 201 #/$ $ \@ 202 #/$ $ \@ 203 #/$ $ \@ 204 +---+ +---+ 205 sink node----| E | | B | 206 +---+ +---+ 207 #\$ $ /@ 208 #\$ $ /@ 209 #\$ $ /@ 210 +---+ * * * * * +---+ 211 | D |-------------| C | 212 +---+ ###### +---+ 213 | source node 214 Prime node 216 NOTE: 217 @: working sub-path tunnel between A and C 218 #: protecting sub-path tunnel between A and C 219 *: working sub-path tunnel between C and D 220 $: protecting sub-path tunnel between C and D 222 Figure 2 224 For a LSP service from source node C to sink node E ,under normal 225 contidion,it would push into working sub-path tunnel (w)PCA|LC(A)|BOS 226 firstly,then it will pop sub-path tunnel label and swap LSP label in 227 the prime transfer node A .and then push into another sub-path tunnel 228 (w)PAE|LA(E)|BOS and transport to sink node E. here PXY denotes a 229 sub-path tunnel from LSR-X to LSR-Y , '|' can be used to separate 230 each level in label stack .LX(Y) denotes a LSP service from LSR-X to 231 LSR-Y. BOS denotes the bottom of label stack. when it detects a 232 failure in the working sub-path tunnel(C-B-A) by OAM function as the 233 following figure. 235 Prime node 236 | 237 +---+ # # # # +---+ 238 | F |-------------| A | 239 +---+ +---+ 240 #/ \@ 241 #/ \@ 242 #/ \@ 243 +---+ +---+ 244 sink node----| E | | B | 245 +---+ +---+ 246 #\ /@ 247 #\ X 248 #\ /@ 249 +---+ +---+ 250 | D |-------------| C | 251 +---+ # # # # +---+ 252 | source node 253 prime node 254 NOTE: 255 @: working sub-path Tunnel 256 #: protecting sub-path Tunnel 257 X: failure 259 Figure 3 261 for example, there is a failure in the link(C-B),all LSP services 262 which would be carried and sent between C and prime node A by working 263 sub-path tunnel(C-B-A) should switch to protecting sub-path tunnel(C- 264 D-E-F-A) and push into protecting sub-path tunnel(P)PCA|LC(A)|BOS and 265 be transported by the protecting sub-path tunnel if the protecting 266 sub-path tunnel has no failure at the same time. when it arrived at 267 the prime node A through the protecting sub-path tunnel, the outer- 268 top SPME label would be poped and swap LSP label in the prime 269 transfer node A, then the LSP service would push into another working 270 sub-path tunnel (w)PAE|LA(E)|BOS and be carried to sink node E .in 271 addtion, when the prime transfer node A is bad or the relative 272 protecting sub-path tunnel has failure too, another prime transfer 273 node D will become active prime transfer node for the LSP service. 274 All LSP services of working sub-path tunnel(C-B-A) would push into 275 working sub-path tunnel(C-D) (w)PCD|LC(D)|BOS to be sent to backup 276 prime node D, and then POP outer-top sub-path tunnel label and swap 277 LSP label.then the LSP serivce would push into another sub-path 278 tunnel (w) PDE|LD(E)|BOS and be carried and sent to sink node E. 280 From the number of configuring sub-path tunnel, if there are n nodes 281 in the ring , there only need to set up and configure (n-2)*2 working 282 sub-path tunnels and (n-2)*2 protecting sub-path tunnel. if 283 configuring one working sub-path tunnel and one protecting sub-path 284 tunnel between each node and other nodes of the ring , then there 285 need to set up and configure O(n^2) sub-path tunnels. so this 286 solution may solve the N square problem. 288 3.2. Extend Steering protection 290 This ring protection solution can extend G.8132 Steering protection 291 solution to simply , quickly and effectively protect LSP service 292 include p2p or p2mp in the MPLS-TP network ring. in order to protect 293 and restore all failure services when a failure has happened in the 294 ring. firstly each LSP path should configure one working LSP path and 295 one protecting LSP path in the ring. and the direction of the two LSP 296 path is reverse in the ring. when a failure has been detected by OAM 297 function of section layer, a state notify message packet will be 298 generated and sent to other nodes in the ring by control channel or 299 other channel very quickly for the first three packets. when other 300 nodes receive the state notify message packet, they would analysis 301 and judge which LSP service would be affected by the failure by state 302 notify message or PRO of each LSP in the node. 304 3.2.1. P2P Service Protection 306 if the LSP service affected by the failure is P2P service , the 307 source node of the LSP service would switch into its own protecting 308 LSP path to transport to the sink node. while the sink node of the 309 LSP service would select protecting LSP path to receive the service 310 .for example , now there is a LSP service from B to E as the 311 following figure. its working LSP path is B-A-F-E identified by 312 singal @, while its protecting LSP path is B-C-D-E, Under normal 313 state, the LSP service would be sent by the working LSP path in the 314 source node .while be received by selecting working LSP path in the 315 sink node . 317 +---+ @@@@@@@@ +---+ 318 | F |-------------| A | 319 +---+ +---+ 320 @/ \@ 321 @/ \@ 322 @/ \@ 323 +---+ +---+ 324 sink node --| E | | B |Source node 325 +---+ +---+ 326 #\ /# 327 #\ /# 328 #\ /# 329 +---+ +---+ 330 | D |-------------| C | 331 +---+ # # # # +---+ 333 NOTE: 334 @: working LSP path; 335 #: protecting LSP path; 337 Figure 4 339 if there is a failure in the working LSP path. for example a failure 340 happened in the link A-F as the following figure.node A or F would 341 detect a failure by section CC&CV packet firstly. then node A or F 342 would generate state notify message to other nodes in the ring. when 343 other nodes of the ring received the state notify message , they 344 would receive and process the state notify message. for the source 345 node B and sink node E of the LSP service, they would analysis and 346 judge whether the LSP service would be affected by the failure based 347 by state notify message and PRO of each LSP in the node. as the 348 link(A-F) failure would affect working LSP path of the LSP Service. 349 the source node B of the LSP service would switch to bridge to 350 protecting LSP path. At the same time, the sink node E of the LSP 351 Service would select protecting LSP path to accept service. 353 +---+ @@@@@@@@ +---+ 354 | F |-----X-------| A | 355 +---+ +---+ 356 @/ \@ 357 @/ \@ 358 @/ \@ 359 +---+ +---+ 360 sink node --| E | | B |Source node 361 +---+ +---+ 362 #\ /# 363 #\ /# 364 #\ /# 365 +---+ +---+ 366 | D |-------------| C | 367 +---+ # # # # +---+ 369 NOTE: 370 @: working LSP path; 371 #: protecting LSP path; 372 X: failure 374 Figure 5 376 when the failure is clear, node A or F would generate failure clear 377 notify message to other nodes of the ring . when the source node B 378 and the sink node E of the LSP service received the failure clear 379 notify message , they would restore to send and receive service 380 packet from working LSP path. 382 3.2.2. P2MP Service Protection 384 For P2MP service of the ring , it must be unidirectional path and 385 more than one egress nodes. it is difficult for source node or sink 386 node to judge and analysis which P2MP LSP service would be affected 387 by the failure only based by state notify message. so when a failure 388 has been detected by section CC&CV function, the nodes which detect 389 the failure would generate state notify message to send to other 390 nodes of the ring. when other nodes received the state notify 391 message,the source nodes of P2MP service firstly make their p2mp 392 services bridge to the working path and the protecting path and send 393 the service to its destination node along the directions of working 394 path and protecting path. if a node in the ring is destination node 395 for p2mp service. It will merge select a direction of path to accept 396 service packet. Then each sink node will detect whether the 397 direction of receive service packet is changable. if it happens, the 398 sink nodes will periodically generate the message of receiving state 399 changing and send to its source node for the p2mp service. when the 400 source node for the p2mp service receives all the messages from other 401 sink nodes and processes them, judge whether all sink nodes of the 402 p2mp service s in the same direreceive the service packetction 403 include working path or protecting path. the source node of the 404 service will select a path(working path or protecting path) to send 405 service packet. or else it will continue to send service packet in 406 the two path(working path and protecting path). when the failure is 407 clear, the nodes which detect free-failure will generate a free- 408 failure notify message and send to all other nodes in the ring. all 409 other nodes receive the free-failure notify message and stop sending 410 the message of receiving state changing periodically ,all service 411 packets will come back to be transported in the working path. at the 412 same time , each sink node for the service will select the direction 413 of working path to receive service packet as idle state condition. 415 the implement in detail as the following figure. for example, there 416 is a p2mp service from source node B to sink node F,E. and working 417 path is B-C-D-[E]-[F] identified by signal(#) ,while protecting path 418 is B-A-[F]-[E] identified by singal(@).under normal situation,the 419 service pakcet will be transported by working path B-C-D-[E]-[F]. 421 +---+ @@@@@@@@ +---+ 422 sink node 2--- | F |-------------| A | 423 +---+ +---+ 424 @/# \@ 425 @/# \@ 426 @/# \@ 427 +---+ +---+ 428 sink node 1--| E | | B |Source node 429 +---+ +---+ 430 \# # / 431 \# # / 432 \# # / 433 +---+ # # # # +---+ 434 | D |-------------| C | 435 +---+ +---+ 437 NOTE: 438 @: working path ; 439 #: protecting path; 440 Figure 6 442 when link C-D and link D-E failure happens, node C or node E that 443 detects a failure will generate a state notify message packet to send 444 to other nodes in the ring through control channel or other channel. 445 when other node C,B,A,F receive the state notify message packet, they 446 will make all source services bridge to working path and protecting 447 path firstly. eg. the service from B to E,F , node B firstly send the 448 service packet separately along its working path B-C-D-[E]-[F] and 449 its protecting path B-A-[F]-[E]. As there are the failures in C-D 450 link and D-E link, the sink node E ,F will not receive service packet 451 by its working path B-C-D-E-F. so the two sink nodes E ,F must merge 452 select its protectiong path B-A-[F]-[E] to receive the service 453 packet.at the same time. As the sink node E, F is sink nodes of the 454 p2mp service ,so the node E,F will generate the message of receiving 455 state changing and send to source node B of the p2mp service 456 periodically. so source node B will receive the message and process 457 the message. because both sink nodes receive service packet from 458 their protecting path. then the source node B will only select 459 protecting path to send its service packet as the following figure: 461 +---+ @@@@@@@@ +---+ 462 sink node 2--- | F |-------------| A | 463 +---+ +---+ 464 @/ \@ 465 @/ \@ 466 @/ \@ 467 +---+ +---+ 468 sink node 1--| E | | B |Source node 469 +---+ +---+ 470 \ / 471 X / 472 \ / 473 +---+ +---+ 474 | D |-----X------| C | 475 +---+ +---+ 477 NOTE: 478 @: transport service by protecting path 479 X: failure 481 Figure 7 483 when the failure is clear , the node C,E detect the failure state 484 have been clear up, the node C ,E will generate a free-failure notify 485 message and send to all other nodes in the ring. when other nodes 486 receive the free-failure notify message , each node will send and 487 receive its own service only by its own working path .eg,the p2mp 488 service from B to E,F will come back to working path B-C-D-[E]-[F] to 489 send and receive its own service packet as the following. at the same 490 time, all sink nodes of p2mp services would stop generating and 491 sending the message of receiving state changing at once. 493 +---+ 494 sink node 2--- | F |-------------| A | 495 +---+ +---+ 496 #/ \ 497 #/ \ 498 #/ \ 499 +---+ +---+ 500 sink node 1--| E | | B |Source node 501 +---+ +---+ 502 #\ /# 503 #\ /# 504 #\ /# 505 #\ /# 506 +---+ +---+ 507 | D |-------------| C | 508 +---+ # # # # # +---+ 510 NOTE: 511 #: transport service 512 X: failure 514 Figure 8 516 3.3. Comparison 518 The two ring protection solutions can fulfil MPLS-TP requirement of 519 ring recovery. but there are different protection and recovery 520 mechanism and different character, the detail is the following table: 522 +-----------------+----------+------------ 523 | Items |solution 1|solution 2 | 524 | | | | 525 +-----------------+----------+------------+ 526 | Amounts of the | Less | As many as | 527 | backup LSP | | the | 528 | | | protected | 529 | | | LSP | 530 +-----------------+----------+------------+ 531 | Bandwidth | lower | high | 532 | utilization | | | 533 | ratio | | | 534 +-----------------+----------+------------+ 535 | Bandwidth share | Support | Support | 536 +-----------------+----------+------------+ 537 | the number of | less | more | 538 | elements of , | | | 539 | recovery | | | 540 +-----------------+----------+------------+ 541 | the number of | less | more | 542 | OAM | | | 543 +-----------------+----------+------------+ 544 | complexity | simple | complex | 545 +-----------------+----------+------------+ 546 | Lable stack | Increase | Changeless | 547 | | one more | | 548 | | layer | | 549 +-----------------+----------+------------+ 550 | P2P and | Support | Support | 551 | P2MP | | | 552 | service | | | 553 +-----------------+----------+------------+ 554 | multi-failure | support | support | 555 | recovery | | | 556 | | | | 557 +-----------------+----------+------------+ 558 | time of | slow | fast | 559 | recovery | | | 560 +-----------------+----------+------------+ 562 Table 1: comparison of ring protection 564 Figure 9 566 4. Security Considerations 568 The security considerations for the authentication TLV need further 569 study. 571 5. IANA Considerations 573 TBD. 575 6. Acknowledgments 577 thank Huub van Helvoort ,Italo Busi, Yaacov Weingarten, malcolm.betts 578 and other experts providing some good comments and advices for this 579 draft. 581 7. References 583 7.1. Normative References 585 [IETF RFC4090] 586 IETF, "IETF RFC4090(Fast Reroute Extensions to RSVP-TE for 587 LSP Tunnels)", May 2005. 589 [IETF RFC5654] 590 IETF, "IETF RFC5654(Requirements of an MPLS Transport 591 Profile)", september 2009. 593 [IETF RFC5921] 594 IETF, "IETF RFC5921(A Framework for MPLS in Transport 595 Networks)", July 2010. 597 [RFC 5586] 598 IETF, "IETF RFC5586(MPLS Generic Associated Channel)", 599 June 2009. 601 7.2. Informative References 603 [ITUT-G.8132 Draft] 604 ITU-T, "Draft ITU-T Recommendation G.8132(T-MPLS shared 605 protection ring)", February 2008. 607 [MPLS TP Fault Management] 608 G. Swallow,A. Fulignoli,M. Vigoureux,S. Boutros,D. Ward , 609 "MPLS Fault Management OAM", July 2010. 611 [MPLS-TP Ring protection] 612 Y. Weingarten, S. Bryant, N. Sprecher, D. Ceccarelli,D. 613 Caviglia, F. Fondelli, M. Corsi, "MPLS-TP Ring 614 Protection", August 2010. 616 [MPLS-TP Ring protection switching] 617 Igor Umansky, Huub van Helvoort, "MPLS-TP Ring Protection 618 Switching (MRPS)", August 2010. 620 [MPLS-TP Survivability Framework] 621 N. Sprecher, A. Farrel, "Multiprotocol Label Switching 622 Transport Profile Survivability Framework", June 2009. 624 7.3. URL References 626 [MPLS-TP-22] 627 IETF - ITU-T Joint Working Team, "", 2008, 628 . 630 Authors' Addresses 632 Liu guoman 633 ZTE Corporation 634 No.68, Zijinghua Road, Yuhuatai District 635 Nanjing 210012 636 P.R.China 638 Phone: +86 025 52871606 639 Email: liu.guoman@zte.com.cn 641 Yang Jian 642 ZTE Corporation 643 5F,RD Building 3,ZTE Industrial Park,XiLi LiuXian Road 644 Nanshan District,Shenzhen 518055 645 P.R.China 647 Phone: +86 755 26773731 648 Email: yang_jian@zte.com.cn 649 Jiang lili 650 ZTE Corporation 651 No.68, Zijinghua Road, Yuhuatai District 652 Nanjing 210012 653 P.R.China 655 Phone: +86 025 52871745 656 Email: jiang.lili@zte.com.cn 658 Fu zhentao 659 ZTE Corporation 660 No.68, Zijinghua Road, Yuhuatai District 661 Nanjing 210012 662 P.R.China 664 Phone: +86 025 52877162 665 Email: fu.zhentao@zte.com.cn