idnits 2.17.1 draft-ietf-ccamp-mpls-tp-cp-framework-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 142: '...that "A solution MUST be provided to s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2011) is 4824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) ** Obsolete normative reference: RFC 5467 (Obsoleted by RFC 6387) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5787 (Obsoleted by RFC 6827) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Loa Andersson, Ed. (Ericsson) 2 Category: Informational Lou Berger, Ed. (LabN) 3 Expiration Date: August 7, 2011 Luyuan Fang, Ed. (Cisco) 4 Nabil Bitar, Ed. (Verizon) 5 Eric Gray, Ed. (Ericsson) 7 February 7, 2011 9 MPLS-TP Control Plane Framework 11 draft-ietf-ccamp-mpls-tp-cp-framework-06.txt 13 Abstract 15 The MPLS Transport Profile (MPLS-TP) supports static provisioning 16 of transport paths via a Network Management System (NMS), and 17 dynamic provisioning of transport paths via a control plane. This 18 document provides the framework for MPLS-TP dynamic provisioning, 19 and covers control plane addressing, routing, path computation, 20 signaling, traffic engineering, and path recovery. MPLS-TP uses 21 GMPLS as the control plane for MPLS-TP Label Switched Paths 22 (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for 23 Pseudowires (PWs). Management plane functions are out of scope of 24 this document. 26 This document is a product of a joint Internet Engineering Task Force 27 (IETF) / International Telecommunication Union Telecommunication 28 Standardization Sector (ITU-T) effort to include an MPLS Transport 29 Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge 30 (PWE3) architectures to support the capabilities and functionalities 31 of a packet transport network as defined by the ITU-T. 33 This Informational Internet-Draft is aimed at achieving IETF 34 Consensus before publication as an RFC and will be subject to an IETF 35 Last Call. 37 [RFC Editor, please remove this note before publication as an RFC and 38 insert the correct Streams Boilerplate to indicate that the published 39 RFC has IETF consensus.] 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/1id-abstracts.html 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html 62 This Internet-Draft will expire on August 7, 2011 64 Copyright and License Notice 66 Copyright (c) 2011 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1 Introduction ........................................... 3 82 1.1 Scope .................................................. 4 83 1.2 Basic Approach ......................................... 5 84 1.3 Reference Model ........................................ 6 85 2 Control Plane Requirements ............................. 9 86 2.1 Primary Requirements ................................... 9 87 2.2 MPLS-TP Framework Derived Requirements ................. 18 88 2.3 OAM Framework Derived Requirements ..................... 19 89 2.4 Security Requirements .................................. 24 90 2.5 Identifier Requirements ................................ 24 91 3 Relationship of PWs and TE LSPs ........................ 25 92 4 TE LSPs ................................................ 26 93 4.1 GMPLS Functions and MPLS-TP LSPs ....................... 26 94 4.1.1 In-Band and Out-Of-Band Control ........................ 26 95 4.1.2 Addressing ............................................. 28 96 4.1.3 Routing ................................................ 28 97 4.1.4 TE LSPs and Constraint-Based Path Computation .......... 28 98 4.1.5 Signaling .............................................. 29 99 4.1.6 Unnumbered Links ....................................... 29 100 4.1.7 Link Bundling .......................................... 29 101 4.1.8 Hierarchical LSPs ...................................... 30 102 4.1.9 LSP Recovery ........................................... 30 103 4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 31 104 4.2 OAM, MEP (Hierarchy), MIP Configuration and Control .... 31 105 4.2.1 Management Plane Support ............................... 32 106 4.3 GMPLS and MPLS-TP Requirements Table ................... 33 107 4.4 Anticipated MPLS-TP Related Extensions and Definitions . 36 108 4.4.1 MPLS-TE to MPLS-TP LSP Control Plane Interworking ...... 36 109 4.4.2 Associated Bidirectional LSPs .......................... 36 110 4.4.3 Asymmetric Bandwidth LSPs .............................. 37 111 4.4.4 Recovery for P2MP LSPs ................................. 37 112 4.4.5 Test Traffic Control and other OAM functions ........... 37 113 4.4.6 DiffServ Object usage in GMPLS ......................... 37 114 4.4.7 Support for MPLS-TP LSP Identifiers .................... 38 115 4.4.8 Support for MPLS-TP Maintenance Identifiers ............ 38 116 5 Pseudowires ............................................ 38 117 5.1 LDP Functions and Pseudowires .......................... 38 118 5.1.1 Management Plane Support ............................... 39 119 5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 39 120 5.3 Anticipated MPLS-TP Related Extensions ................. 42 121 5.3.1 Extensions to Support Out-of-Band PW Control ........... 42 122 5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 43 123 5.3.3 Support for Dynamic Transfer of PW Control/Ownership ... 43 124 5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 44 125 5.3.5 Support for PW Protection and PW OAM Configuration ..... 44 126 5.3.6 Client Layer and Cross-Provider Interfaces to PW Control ...45 127 5.4 ASON Architecture Considerations ....................... 45 128 6 Security Considerations ................................ 45 129 7 IANA Considerations .................................... 46 130 8 Acknowledgments ........................................ 46 131 9 References ............................................. 46 132 9.1 Normative References ................................... 46 133 9.2 Informative References ................................. 49 134 10 Authors' Addresses ..................................... 54 136 1. Introduction 138 The Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) 139 is defined as a joint effort between the International 140 Telecommunications Union (ITU) and the IETF. The requirements for 141 MPLS-TP are defined in the requirements document, see [RFC5654]. 142 These requirements state that "A solution MUST be provided to support 143 dynamic provisioning of MPLS-TP transport paths via a control plane." 144 This document provides the framework for such dynamic provisioning. 146 This document is a product of a joint Internet Engineering Task Force 147 (IETF) / International Telecommunications Union Telecommunications 148 Standardization Sector (ITU-T) effort to include an MPLS Transport 149 Profile within the IETF MPLS and Pseudo Wire Emulation Edge-to-Edge 150 (PWE3) architectures to support the capabilities and functions of a 151 packet transport network as defined by the ITU-T. 153 1.1. Scope 155 This document covers the control plane functions involved in 156 establishing MPLS-TP Label Switched Paths (LSPs) and Pseudowires 157 (PWs). The control plane requirements for MPLS-TP are defined in the 158 MPLS-TP requirements document [RFC5654]. These requirements define 159 the role of the control plane in MPLS-TP. In particular, Section 2.4 160 of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] 161 provide specific control plane requirements. 163 The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS 164 and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to 165 carry client signals other than IP or MPLS. The relationship between 166 PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs 167 in an MPLS Packet Switched Network (PSN). The PW encapsulation over 168 MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs 169 over MPLS in an MPLS network. MPLS-TP also defines protection and 170 restoration (or, collectively, recovery) functions, see [RFC5654] and 171 [RFC4427]. The MPLS-TP control plane provides methods to establish, 172 remove and control MPLS-TP LSPs and PWs. This includes control of 173 Operations, Administration and Maintenance (OAM), data plane, and 174 recovery functions. 176 A general framework for MPLS-TP has been defined in [RFC5921], and a 177 survivability framework for MPLS-TP has been defined in [TP-SURVIVE]. 178 These documents scope the approaches and protocols that are the 179 foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the 180 IETF protocols that serve as the foundation of the MPLS-TP control 181 plane. The PW control plane is based on the existing PW control 182 plane, see [RFC4447], and the PW end-to-end (PWE3) architecture, see 183 [RFC3985]. The LSP control plane is based on Generalized MPLS 184 (GMPLS), see [RFC3945], which is built on MPLS Traffic Engineering 185 (TE) and its numerous extensions. [TP-SURVIVE] focuses on the 186 recovery functions that must be supported within MPLS-TP. It does not 187 specify which control plane mechanisms are to be used. 189 The remainder of this document discusses the impact of the MPLS-TP 190 requirements on the GMPLS signaling and routing protocols that are 191 used to control MPLS-TP LSPs, and on the control of PWs as specified 192 in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC]. 194 1.2. Basic Approach 196 The basic approach taken in defining the MPLS-TP Control Plane 197 framework includes the following: 199 1) MPLS technology as defined by the IETF is the foundation for 200 the MPLS Transport Profile. 202 2) The data plane for MPLS-TP is a standard MPLS data plane 203 [RFC3031] as profiled in [RFC5960]. 205 3) MPLS PWs are used by MPLS-TP including the use of targeted 206 Label Distribution Protocol (LDP) as the foundation for PW 207 signaling [RFC4447]; and Open Shortest Path First with Traffic 208 Engineering (OSPF-TE), Intermediate System to Intermediate 209 System (IS-IS) with Traffic Engineering (ISIS-TE) or 210 Multiprotocol Border Gateway Protocol (MP-BGP) as they apply 211 for Multi-Segment Pseudowire (MS-PW) routing. However, the PW 212 can be encapsulated over an MPLS-TP LSP (established using 213 methods and procedures for MPLS-TP LSP establishment) in 214 addition to the presently defined methods of carrying PWs over 215 LSP-based packet switched networks (PSNs). That is, the MPLS-TP 216 domain is a packet switched network from a PWE3 architecture 217 perspective [RFC3985]. 219 4) The MPLS-TP LSP control plane builds on the GMPLS control plane 220 as defined by the IETF for transport LSPs. The protocols 221 within scope are Resource Reservation Protocol with Traffic 222 Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203][RFC5392], 223 and ISIS-TE [RFC5307][RFC5316]. Automatically Switched Optical 224 Network (ASON) signaling and routing requirements in the 225 context of GMPLS can be found in [RFC4139] and [RFC4258]. 227 5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group 228 Internet-Drafts should be reused wherever possible. 230 6) If needed, extensions for the MPLS-TP control plane should 231 first be based on the existing and evolving IETF work, secondly 232 based on work by other standard bodies only when IETF decides 233 that the work is out of the IETF's scope. New extensions may be 234 defined otherwise. 236 7) Extensions to the control plane may be required in order to 237 fully automate MPLS-TP LSP and PW related functions. 239 8) Control plane software upgrades to existing equipment is 240 acceptable and expected. 242 9) It is permissible for functions present in the GMPLS and PW 243 control planes to not be used in MPLS-TP networks. 245 10) One possible use of the control plane is to configure, enable 246 and generally control OAM functionality. This will require 247 extensions to existing control plane specifications which will 248 be usable in MPLS-TP as well as MPLS networks. 250 11) The foundation for MPLS-TP control plane requirements is 251 primarily found in Section 2.4 of [RFC5654] and relevant 252 portions of the remainder Section 2 of [RFC5654]. 254 1.3. Reference Model 256 The control plane reference model is based on the general MPLS-TP 257 reference model as defined in the MPLS-TP framework [RFC5921] and 258 further refined in MPLS-TP User-to-Network and Network-to-Network 259 Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP 260 framework [RFC5921], the MPLS-TP control plane is based on GMPLS with 261 RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both 262 cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic 263 routing within an MPLS-TP domain. 265 Note that in this context, "targeted LDP" (or T-LDP) means LDP as 266 defined in RFC 5036, using Targeted Hello messages. See Section 267 2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the 268 extended discovery mechanism is specified in [RFC4447] Section 5 269 ("LDP"). 271 From a service perspective, MPLS-TP client services may be supported 272 via both PWs and LSPs. PW client interfaces, or adaptations, are 273 defined on an interface technology basis, e.g., Ethernet over PW 274 [RFC4448]. In the context of MPLS-TP LSP, the client interface is 275 provided at the network layer and may be controlled via a GMPLS based 276 UNI, see [RFC4208], or statically provisioned. As discussed in 277 [RFC5921] and [TP-UNI], MPLS-TP also presumes an NNI reference point. 279 The MPLS-TP end-to-end control plane reference model is shown in 280 Figure 1. The Figure shows the control plane protocols used by MPLS- 281 TP, as well as the UNI and NNI reference points, in the case of a 282 single segment PW supported by an end-to-end LSP without any 283 hierarchical LSPs. (The MS-PW case is not shown.) Each service 284 provider node's participation in routing and signaling (both GMPLS 285 RSVP-TE and PW LDP) is represented. Note that only the service end 286 points participate in PW LDP signaling, while all service provider 287 nodes participate in GMPLS TE LSP routing and signaling. 289 |< ---- client signal (e.g., IP / MPLS / L2) -------- >| 290 |< --------- SP1 ---------- >|< ------- SP2 ----- >| 291 |< ---------- MPLS-TP End-to-End PW --------- >| 292 |< -------- MPLS-TP End-to-End LSP ------ >| 294 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 295 |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| 296 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 297 UNI NNI UNI 298 GMPLS 299 TE-RTG, |<-----|------|------|-------|------|----->| 300 & RSVP-TE 302 PW LDP |< ---------------------------------------- >| 304 Figure 1. End-to-End MPLS-TP Control Plane Reference Model 306 Legend: 307 CE: Customer Edge 308 Client signal: defined in MPLS-TP Requirements 309 L2: Any layer 2 signal that may be carried 310 over a PW, e.g. Ethernet. 311 NNI: Network to Network Interface 312 P: Provider 313 PE: Provider Edge 314 SP: Service Provider 315 TE-RTG: GMPLS OSPF-TE or ISIS-TE 316 UNI: User to Network Interface 318 Note: The MS-PW case is not shown. 320 Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". 321 These segments are present to support scaling, OAM and Maintenance 322 Entity End Points (MEPs), see [TP-OAM], within each provider domain 323 and across the inter-provider NNI. (H-LSPs are used to implement 324 Sub-Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The 325 MEPs are used to collect performance information, support diagnostic 326 and fault management functions, and support OAM triggered 327 survivability schemes as discussed in [TP-SURVIVE]. Each H-LSP may be 328 protected or restored using any of the schemes discussed in [TP- 329 SURVIVE]. End-to-end monitoring is supported via MEPs at the End-to- 330 End LSP and PW end points. Note that segment MEPs may be collocated 331 with MIPs of the next higher-layer (e.g., end-to-end) LSPs. (The MS- 332 PW case is not shown.) 333 |< ------- client signal (e.g., IP / MPLS / L2) ----- >| 334 |< -------- SP1 ----------- >|< ------- SP2 ----- >| 335 |< ----------- MPLS-TP End-to-End PW -------- >| 336 |< ------- MPLS-TP End-to-End LSP ------- >| 337 |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| 339 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 340 |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| 341 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 342 UNI NNI UNI 343 ..... ..... 344 End2end |MEP|--------------------------------------|MEP| 345 PW OAM ''''' ''''' 346 ..... ..... ..... ..... 347 End2end |MEP|----------------|MIP|---|MIP|---------|MEP| 348 LSP OAM ''''' ''''' ''''' ''''' 349 ..... ..... ..... ......... ......... ..... ..... 350 Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP| 351 LSP OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' ''''' 353 H-LSP GMPLS 354 TE-RTG |<-----|------|----->||<---->||<-----|----->| 355 &RSVP-TE (within an MPLS-TP network) 357 E2E GMPLS 358 TE-RTG |< ------------------|--------|------------>| 359 &RSVP-TE 361 PW LDP |< ---------------------------------------- >| 363 Figure 2. MPLS-TP Control Plane Reference Model with OAM 365 Legend: 366 CE: Customer Edge 367 Client signal: defined in MPLS-TP Requirements 368 E2E: End-to-end 369 L2: Any layer 2 signal that may be carried 370 over a PW, e.g. Ethernet. 371 H-LSP: Hierarchical LSP 372 MEP: Maintenance entity end point 373 MIP: Maintenance intermediate point 374 NNI: Network to Network Interface 375 P: Provider 376 PE: Provider Edge 377 SP: Service Provider 378 TE-RTG: GMPLS OSPF-TE or ISIS-TE 380 Note: The MS-PW case is not shown. 382 While not shown in the Figures above, the MPLS-TP control plane must 383 support the addressing separation and independence between the data, 384 control and management planes. Address separation between the planes 385 is already included in GMPLS. Such separation is also already 386 included in LDP as LDP session end point addresses are never 387 automatically associated with forwarding. 389 2. Control Plane Requirements 391 The requirements for the MPLS-TP control plane are derived from the 392 MPLS-TP requirements and framework documents, specifically [RFC5654], 393 [RFC5921], [RFC5860], [TP-OAM], and [TP-SURVIVE]. The requirements 394 are summarized in this section, but do not replace those documents. 395 If there are differences between this section and those documents, 396 those documents shall be considered authoritative. 398 2.1. Primary Requirements 400 These requirements are based on Section 2 of [RFC5654]: 401 1. Any new functionality that is defined to fulfill the 402 requirements for MPLS-TP must be agreed within the IETF through 403 the IETF consensus process as per [RFC4929] [RFC5654, Section 404 1, Paragraph 15]. 406 2. The MPLS-TP control plane design should as far as reasonably 407 possible reuse existing MPLS standards [RFC5654, requirement 408 2]. 410 3. The MPLS-TP control plane must be able to interoperate with 411 existing IETF MPLS and PWE3 control planes where appropriate 412 [RFC5654, requirement 3]. 414 4. The MPLS-TP control plane must be sufficiently well-defined to 415 ensure the interworking between equipment supplied by multiple 416 vendors will be possible both within a single domain and 417 between domains [RFC5654, requirement 4]. 419 5. The MPLS-TP control plane must support a connection-oriented 420 packet switching model with traffic engineering capabilities 421 that allow deterministic control of the use of network 422 resources [RFC5654, requirement 5]. 424 6. The MPLS-TP control plane must support traffic-engineered 425 point-to-point (P2P) and point-to-multipoint (P2MP) transport 426 paths [RFC5654, requirement 6]. 428 7. The MPLS-TP control plane must support unidirectional, 429 associated bidirectional and co-routed bidirectional point-to- 430 point transport paths [RFC5654, requirement 7]. 432 8. The MPLS-TP control plane must support unidirectional point-to- 433 multipoint transport paths [RFC5654, requirement 8]. 435 9. The MPLS-TP control plane must enable all nodes (i.e., ingress, 436 egress and intermediate) to be aware about the pairing 437 relationship of the forward and the backward directions 438 belonging to the same co-routed bidirectional transport path 439 [RFC5654, requirement 10]. 441 10. The MPLS-TP control plane must enable edge nodes (i.e., ingress 442 and egress) to be aware of the pairing relationship of the 443 forward and the backward directions belonging to the same 444 associated bidirectional transport path [RFC5654, requirement 445 11]. 447 11. The MPLS-TP control plane should enable common transit nodes to 448 be aware of the pairing relationship of the forward and the 449 backward directions belonging to the same associated 450 bidirectional transport path [RFC5654, requirement 12]. 452 12. The MPLS-TP control plane must support bidirectional transport 453 paths with symmetric bandwidth requirements, i.e. the amount of 454 reserved bandwidth is the same in the forward and backward 455 directions [RFC5654, requirement 13]. 457 13. The MPLS-TP control plane must support bidirectional transport 458 paths with asymmetric bandwidth requirements, i.e. the amount 459 of reserved bandwidth differs in the forward and backward 460 directions [RFC5654, requirement 14]. 462 14. The MPLS-TP control plane must support the logical separation 463 of the control plane from the management and data plane 464 [RFC5654, requirement 15]. Note that this implies that the 465 addresses used in the control plane are independent from the 466 addresses used in the management and data planes. 468 15. The MPLS-TP control plane must support the physical separation 469 of the control plane from the management and data plane, and no 470 assumptions should be made about the state of the data plane 471 channels from information about the control or management plane 472 channels when they are running out-of-band [RFC5654, 473 requirement 16]. 475 16. A control plane must be defined to support dynamic provisioning 476 and restoration of MPLS-TP transport paths, but its use is a 477 network operator's choice [RFC5654, requirement 18]. 479 17. The presence of a control plane must not be required for static 480 provisioning of MPLS-TP transport paths. [RFC5654, requirement 481 19]. 483 18. The MPLS-TP control plane must permit the coexistence of 484 statically and dynamically provisioned/managed MPLS-TP 485 transport paths within the same layer network or domain 486 [RFC5654, requirement 20]. 488 19. The MPLS-TP control plane should be operable in a way that is 489 similar to the way the control plane operates in other 490 transport-layer technologies [RFC5654, requirement 21]. 492 20. The MPLS-TP control plane must avoid or minimize traffic impact 493 (e.g. packet delay, reordering and loss) during network 494 reconfiguration [RFC5654, requirement 24]. 496 21. The MPLS-TP control plane must work across multiple homogeneous 497 domains [RFC5654, requirement 25], i.e., all domains use the 498 same MPLS-TP control plane. 500 22. The MPLS-TP control plane should work across multiple non- 501 homogeneous domains [RFC5654, requirement 26], i.e., some 502 domains use the same control plane and other domains use static 503 provisioning at the domain boundary. 505 23. The MPLS-TP control plane must not dictate any particular 506 physical or logical topology [RFC5654, requirement 27]. 508 24. The MPLS-TP control plane must include support of ring 509 topologies which may be deployed with arbitrarily 510 interconnection, support rings of at least 16 nodes [RFC5654, 511 requirement 27.A, 27.B and 27.C]. 513 25. The MPLS-TP control plane must scale gracefully to support a 514 large number of transport paths, nodes and links. That is it 515 must be able to scale at least as well as control planes in 516 existing transport technologies with growing and increasingly 517 complex network topologies as well as with increasing bandwidth 518 demands, number of customers, and number of services [RFC 5654, 519 requirements 53 and 28]. 521 26. The MPLS-TP control plane should not provision transport paths 522 which contain forwarding loops [RFC5654, requirement 29]. 524 27. The MPLS-TP control plane must support multiple client layers. 525 (e.g. MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.) [RFC5654, 526 requirement 30]. 528 28. The MPLS-TP control plane must provide a generic and extensible 529 solution to support the transport of MPLS-TP transport paths 530 over one or more server layer networks (such as MPLS-TP, 531 Ethernet, SONET/SDH, OTN, etc.). Requirements for bandwidth 532 management within a server layer network are outside the scope 533 of this document [RFC5654, requirement 31]. 535 29. In an environment where an MPLS-TP layer network is supporting 536 a client layer network, and the MPLS-TP layer network is 537 supported by a server layer network then the control plane 538 operation of the MPLS-TP layer network must be possible without 539 any dependencies on the server or client layer network 540 [RFC5654, requirement 32]. 542 30. The MPLS-TP control plane must allow for the transport of a 543 client MPLS or MPLS-TP layer network over a server MPLS or 544 MPLS-TP layer network [RFC5654, requirement 33]. 546 31. The MPLS-TP control plane must allow the autonomous operation 547 of the layers of a multi-layer network that includes an MPLS-TP 548 layer [RFC5654, requirement 34]. 550 32. The MPLS-TP control plane must allow the hiding of MPLS-TP 551 layer network addressing and other information (e.g. topology) 552 from client layer networks. However, it should be possible, at 553 the option of the operator, to leak a limited amount of 554 summarized information, such as Shared Risk Link Groups (SRLGs) 555 or reachability, between layers [RFC5654, requirement 35]. 557 33. The MPLS-TP control plane must allow for the identification of 558 a transport path on each link within and at the destination 559 (egress) of the transport network. [RFC5654, requirement 38 and 560 39]. 562 34. The MPLS-TP control plane must allow for the use of P2MP server 563 (sub)layer capabilities as well as P2P server (sub)layer 564 capabilities when supporting P2MP MPLS-TP transport paths 565 [RFC5654, requirement 40]. 567 35. The MPLS-TP control plane must be extensible in order to 568 accommodate new types of client layer networks and services 569 [RFC5654, requirement 41]. 571 36. The MPLS-TP control plane should support the reserved bandwidth 572 associated with a transport path to be increased without 573 impacting the existing traffic on that transport path provided 574 enough resources are available [RFC5654, requirement 42]. 576 37. The MPLS-TP control plane should support the reserved bandwidth 577 of a transport path to be decreased without impacting the 578 existing traffic on that transport path, provided that the 579 level of existing traffic is smaller than the reserved 580 bandwidth following the decrease [RFC5654, requirement 43]. 582 38. The control plane for MPLS-TP must fit within the ASON (control 583 plane) architecture. The ITU-T has defined an architecture for 584 Automatically Switched Optical Networks (ASON) in G.8080 585 [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An 586 interpretation of the ASON signaling and routing requirements 587 in the context of GMPLS can be found in [RFC4139] and [RFC4258] 588 [RFC5654, Section 2.4., Paragraph 2 and 3]. 590 39. The MPLS-TP control plane must support control plane topology 591 and data plane topology independence [RFC5654, requirement 47]. 593 40. A failure of the MPLS-TP control plane must not interfere with 594 the delivery of service or recovery of established transport 595 paths [RFC5654, requirement 47]. 597 41. The MPLS-TP control plane must be able to operate independent 598 of any particular client or server layer control plane 599 [RFC5654, requirement 48]. 601 42. The MPLS-TP control plane should support, but not require, an 602 integrated control plane encompassing MPLS-TP together with its 603 server and client layer networks when these layer networks 604 belong to the same administrative domain [RFC5654, requirement 605 49]. 607 43. The MPLS-TP control plane must support configuration of 608 protection functions and any associated maintenance (OAM) 609 functions [RFC5654, requirement 50 and 7]. 611 44. The MPLS-TP control plane must support the configuration and 612 modification of OAM maintenance points as well as the 613 activation/deactivation of OAM when the transport path or 614 transport service is established or modified [RFC5654, 615 requirement 51]. 617 45. The MPLS-TP control plane must be capable of restarting and 618 relearning its previous state without impacting forwarding 619 [RFC5654, requirement 54]. 621 46. The MPLS-TP control plane must provide a mechanism for dynamic 622 ownership transfer of the control of MPLS-TP transport paths 623 from the management plane to the control plane and vice versa. 624 The number of reconfigurations required in the data plane must 625 be minimized (preferably no data plane reconfiguration will be 626 required) [RFC5654, requirement 55]. Note, such transfers cover 627 all transport path control functions including control of 628 recovery and OAM. 630 47. The MPLS-TP control plane must support protection and 631 restoration mechanisms, i.e., recovery [RFC5654, requirement 632 52]. 634 Note that the MPLS-TP Survivability Framework document, [TP- 635 SURVIVE], provides additional useful information related to 636 recovery. 638 48. The MPLS-TP control plane mechanisms should be identical (or as 639 similar as possible) to those already used in existing 640 transport networks to simplify implementation and operations. 641 However, this must not override any other requirement [RFC5654, 642 requirement 56 A]. 644 49. The MPLS-TP control plane mechanisms used for P2P and P2MP 645 recovery should be identical to simplify implementation and 646 operation. However, this must not override any other 647 requirement [RFC5654, requirement 56 B]. 649 50. The MPLS-TP control plane must support recovery mechanisms that 650 are applicable at various levels throughout the network 651 including support for link, transport path, segment, 652 concatenated segment and end-to-end recovery [RFC5654, 653 requirement 57]. 655 51. The MPLS-TP control plane must support recovery paths that meet 656 the SLA protection objectives of the service [RFC5654, 657 requirement 58]. Including: 659 a. Guarantee 50ms recovery times from the moment of fault 660 detection in networks with spans less than 1200 km. 662 b. Protection of 100% of the traffic on the protected path. 664 c. Recovery must meet SLA requirements over multiple 665 domains. 667 52. The MPLS-TP control plane should support per transport path 668 Recovery objectives [RFC5654, requirement 59]. 670 53. The MPLS-TP control plane must support recovery mechanisms that 671 are applicable to any topology [RFC5654, requirement 60]. 673 54. The MPLS-TP control plane must operate in synergy with 674 (including coordination of timing/timer settings) the recovery 675 mechanisms present in any client or server transport networks 676 (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions 677 between the layers [RFC5654, requirement 61]. 679 55. The MPLS-TP control plane must support recovery and reversion 680 mechanisms that prevent frequent operation of recovery in the 681 event of an intermittent defect [RFC5654, requirement 62]. 683 56. The MPLS-TP control plane must support revertive and non- 684 revertive protection behavior [RFC5654, requirement 64]. 686 57. The MPLS-TP control plane must support 1+1 bidirectional 687 protection for P2P transport paths [RFC5654, requirement 65 A]. 689 58. The MPLS-TP control plane must support 1+1 unidirectional 690 protection for P2P transport paths [RFC5654, requirement 65 B]. 692 59. The MPLS-TP control plane must support 1+1 unidirectional 693 protection for P2MP transport paths [RFC5654, requirement 65 694 C]. 696 60. The MPLS-TP control plane must support the ability to share 697 protection resources amongst a number of transport paths 698 [RFC5654, requirement 66]. 700 61. The MPLS-TP control plane must support 1:n bidirectional 701 protection for P2P transport paths. Bidirectional 1:n 702 protection should be the default for 1:n protection [RFC5654, 703 requirement 67 A]. 705 62. The MPLS-TP control plane must support 1:n unidirectional 706 protection for P2MP transport paths [RFC5654, requirement 67 707 B]. 709 63. The MPLS-TP control plane may support 1:n unidirectional 710 protection for P2P transport paths [RFC5654, requirement 65 C]. 712 64. The MPLS-TP control plane may support the control of extra- 713 traffic type traffic [RFC5654, note after requirement 67]. 715 65. The MPLS-TP control plane should support 1:n (including 1:1) 716 shared mesh recovery [RFC5654, requirement 68]. 718 66. The MPLS-TP control plane must support sharing of protection 719 resources such that protection paths that are known not to be 720 required concurrently can share the same resources [RFC5654, 721 requirement 69]. 723 67. The MPLS-TP control plane must support the sharing of resources 724 between a restoration transport path and the transport path 725 being replaced [RFC5654, requirement 70]. 727 68. The MPLS-TP control plane must support restoration priority so 728 that an implementation can determine the order in which 729 transport paths should be restored [RFC5654, requirement 71]. 731 69. The MPLS-TP control plane must support preemption priority in 732 order to allow restoration to displace other transport paths in 733 the event of resource constraints [RFC5654, requirement 72 and 734 86]. 736 70. The MPLS-TP control plane must support revertive and non- 737 revertive restoration behavior [RFC5654, requirement 73]. 739 71. The MPLS-TP control plane must support recovery being triggered 740 by physical (lower) layer fault indications [RFC5654, 741 requirement 74]. 743 72. The MPLS-TP control plane must support recovery being triggered 744 by OAM [RFC5654, requirement 75]. 746 73. The MPLS-TP control plane must support management plane 747 recovery triggers (e.g., forced switch, etc.) [RFC5654, 748 requirement 76]. 750 74. The MPLS-TP control plane must support the differentiation of 751 administrative recovery actions from recovery actions initiated 752 by other triggers [RFC5654, requirement 77]. 754 75. The MPLS-TP control plane should support control plane 755 restoration triggers (e.g., forced switch, etc.) [RFC5654, 756 requirement 78]. 758 76. The MPLS-TP control plane must support priority logic to 759 negotiate and accommodate coexisting requests (i.e., multiple 760 requests) for protection switching (e.g., administrative 761 requests and requests due to link/node failures) [RFC5654, 762 requirement 79]. 764 77. The MPLS-TP control plane must support the association of 765 protection paths and working paths (sometimes known as 766 protection groups) [RFC5654, requirement 80]. 768 78. The MPLS-TP control plane must support pre-calculation of 769 recovery paths [RFC5654, requirement 81]. 771 79. The MPLS-TP control plane must support pre-provisioning of 772 recovery paths [RFC5654, requirement 82]. 774 80. The MPLS-TP control plane must support the external commands 775 defined in [RFC4427]. External controls overruled by higher 776 priority requests (e.g., administrative requests and requests 777 due to link/node failures) or unable to be signaled to the 778 remote end (e.g. because of a protection state coordination 779 fail) must be ignored/dropped [RFC5654, requirement 83]. 781 81. The MPLS-TP control plane must permit the testing and 782 validation of the integrity of the protection/recovery 783 transport path [RFC5654, requirement 84 A]. 785 82. The MPLS-TP control plane must permit the testing and 786 validation of protection/restoration mechanisms without 787 triggering the actual protection/restoration [RFC5654, 788 requirement 84 B]. 790 83. The MPLS-TP control plane must permit the testing and 791 validation of protection/restoration mechanisms while the 792 working path is in service [RFC5654, requirement 84 C]. 794 84. The MPLS-TP control plane must permit the testing and 795 validation of protection/restoration mechanisms while the 796 working path is out of service [RFC5654, requirement 84 D]. 798 85. The MPLS-TP control plane must support the establishment and 799 maintenance of all recovery entities and functions [RFC5654, 800 requirement 89 A]. 802 86. The MPLS-TP control plane must support signaling of recovery 803 administrative control [RFC5654, requirement 89 B]. 805 87. The MPLS-TP control plane must support protection state 806 coordination (PSC). Since control plane network topology is 807 independent from the data plane network topology, the PSC 808 supported by the MPLS-TP control plane may run on resources 809 different than the data plane resources handled within the 810 recovery mechanism (e.g. backup) [RFC5654, requirement 89 C]. 812 88. When present, the MPLS-TP control plane must support recovery 813 mechanisms that are optimized for specific network topologies. 814 These mechanisms must be interoperable with the mechanisms 815 defined for arbitrary topology (mesh) networks to enable 816 protection of end-to-end transport paths [RFC5654, requirement 817 91]. 819 89. When present, the MPLS-TP control plane must support the 820 control of ring topology specific recovery mechanisms [RFC5654, 821 Section 2.5.6.1]. 823 90. The MPLS-TP control plane must include support for 824 differentiated services and different traffic types with 825 traffic class separation associated with different traffic 826 [RFC5654, requirement 110]. 828 91. The MPLS-TP control plane must support the provisioning of 829 services that provide guaranteed Service Level Specifications 830 (SLS), with support for hard ([RFC3209] style) and relative 831 ([RFC3270] style) end-to-end bandwidth guarantees [RFC5654, 832 requirement 111]. 834 92. The MPLS-TP control plane must support the provisioning of 835 services which are sensitive to jitter and delay [RFC5654, 836 requirement 112]. 838 2.2. MPLS-TP Framework Derived Requirements 840 The following additional requirements are based on [RFC5921], [TP- 841 P2MP-FWK] and [RFC5960]: 843 93. Per-packet equal cost multi-path (ECMP) load balancing is 844 currently outside the scope of MPLS-TP [RFC5960 , section 845 3.1.1., paragraph 6]. 847 94. Penultimate hop popping (PHP) must be disabled on MPLS-TP LSPs 848 by default. [RFC5960 , section 3.1.1., paragraph 7]. 850 95. The MPLS-TP control plane must support both E-LSP and L-LSP 851 MPLS DiffServ modes as specified in [RFC3270] [RFC5960 , 852 section 3.3.2., paragraph 12]. 854 96. Both single-segment, see [RFC3985], and multi-segment PWs, see 855 [RFC5659], shall be supported by the MPLS-TP control plane. 856 MPLS-TP shall use the definition of multi-segment PWs as 857 defined by the IETF [RFC5921, section 3.4.4]. 859 97. The MPLS-TP control plane must support the control of PWs and 860 their associated labels [RFC5921, section 3.4.4]. 862 98. The MPLS-TP control plane must support network layer clients, 863 i.e., clients whose traffic is transported over an MPLS-TP 864 network without the use of PWs [RFC5921, section 3.4.5]. 866 a. The MPLS-TP control plane must support the use of network 867 layer protocol-specific LSPs and labels. [RFC5921, 868 section 3.4.5.] 870 b. The MPLS-TP control plane must support the use of a 871 client service-specific LSPs and labels. [RFC5921, 872 section 3.4.5.] 874 99. The MPLS-TP control plane for LSPs must be based on the GMPLS 875 control plane. More specifically, GMPLS RSVP-TE [RFC3473] and 876 related extensions are used for LSP signaling, and GMPLS OSPF- 877 TE [RFC5392] and ISIS-TE [RFC5316] are used for routing 878 [RFC5921, section 3.9]. 880 100. The MPLS-TP control plane for PWs must be based on the MPLS 881 control plane for PWs, and more specifically, targeted LDP (T- 882 LDP) [RFC4447] is used for PW signaling [RFC5921, section 3.9., 883 paragraph 5]. 885 101. The MPLS-TP control plane must ensure its own survivability and 886 to enable it to recover gracefully from failures and 887 degradations. These include graceful restart and hot redundant 888 configurations [RFC5921, section 3.9., paragraph 16]. 890 102. The MPLS-TP control plane must support linear, ring and meshed 891 protection schemes [RFC5921, section 3.12., paragraph 3]. 893 103. The MPLS-TP control plane must support the control of SPMEs 894 (hierarchical LSPs) for new or existing end-to-end LSPs 895 [RFC5921, section 3.12., paragraph 7]. 897 2.3. OAM Framework Derived Requirements 899 The following additional requirements are based on [RFC5860] and [TP- 900 OAM]: 902 104. The MPLS-TP control plane must support the capability to 903 enable/disable OAM functions as part of service establishment 904 [RFC5860, section 2.1.6., paragraph 1]. Note that OAM functions 905 are applicable regardless of the label stack depth (i.e., level 906 of LSP hierarchy or PW) [RFC5860, section 2.1.1., paragraph 3]. 908 105. The MPLS-TP control plane must support the capability to 909 enable/disable OAM functions after service establishment. In 910 such cases, the customer must not perceive service degradation 911 as a result of OAM enabling/disabling [RFC5860, section 2.1.6., 912 paragraph 1 and 2]. 914 106. The MPLS-TP control plane must support dynamic control of any 915 of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping 916 [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD 917 [RFC5885]) [RFC5860, section 2.1.4., paragraph 2]. 919 107. The MPLS-TP control plane must allow for the ability to support 920 experimental OAM functions. These functions must be disabled 921 by default [RFC5860, section 2.2., paragraph 2]. 923 108. The MPLS-TP control plane must support the choice of which (if 924 any) OAM function(s) to use and to which PW, LSP or Section it 925 applies [RFC5860, section 2.2., paragraph 3]. 927 109. The MPLS-TP control plane must allow (e.g., enable/disable) 928 mechanisms that support the localization of faults and the 929 notification of appropriate nodes. [RFC5860, section 2.2.1., 930 paragraph 1]. 932 110. The MPLS-TP control plane may support mechanisms that permit 933 the service provider to be informed of a fault or defect 934 affecting the service(s) it provides, even if the fault or 935 defect is located outside of his domain [RFC5860, section 936 2.2.1., paragraph 2]. 938 111. Information exchange between various nodes involved in the 939 MPLS-TP control plane should be reliable such that, for 940 example, defects or faults are properly detected or that state 941 changes are effectively known by the appropriate nodes 942 [RFC5860, section 2.2.1., paragraph 3]. 944 112. The MPLS-TP control plane must provide functionality to control 945 an End Point's ability to monitor the liveness of a PW, LSP, or 946 Section [RFC5860, section 2.2.2., paragraph 1]. 948 113. The MPLS-TP control plane must provide functionality to control 949 an End Point's ability to determine whether or not it is 950 connected to specific End Point(s) by means of the expected PW, 951 LSP, or Section [RFC5860, section 2.2.3., paragraph 1]. 953 a. The MPLS-TP control plane must provide mechanisms to 954 control an End Point's ability to perform this function 955 proactively [RFC5860, section 2.2.3., paragraph 2]. 957 b. The MPLS-TP control plane must provide mechanisms to 958 control an End Point's ability to perform this function 959 on-demand [RFC5860, section 2.2.3., paragraph 3]. 961 114. The MPLS-TP control plane must provide functionality to control 962 diagnostic testing on a PW, LSP or Section [RFC5860, section 963 2.2.5., paragraph 1]. 965 a. The MPLS-TP control plane must provide mechanisms to 966 control the performance of this function on-demand 967 [RFC5860, section 2.2.5., paragraph 2]. 969 115. The MPLS-TP control plane must provide functionality to enable 970 an End Point to discover the Intermediate (if any) and End 971 Point(s) along a PW, LSP or Section, and more generally to 972 trace (record) the route of a PW, LSP or Section [RFC5860, 973 section 2.2.4., paragraph 1]. 975 a. The MPLS-TP control plane must provide mechanisms to 976 control the performance of this function on-demand 977 [RFC5860, section 2.2.4., paragraph 2]. 979 116. The MPLS-TP control plane must provide functionality to enable 980 an End Point of a PW, LSP or Section to instruct its associated 981 End Point(s) to lock the PW, LSP or Section [RFC5860, section 982 2.2.6., paragraph 1]. 984 a. The MPLS-TP control plane must provide mechanisms to 985 control the performance of this function on-demand 986 [RFC5860, section 2.2.6., paragraph 2]. 988 117. The MPLS-TP control plane must provide functionality to enable 989 an Intermediate Point of a PW or LSP to report, to an End Point 990 of that same PW or LSP, a lock condition indirectly affecting 991 that PW or LSP [RFC5860, section 2.2.7., paragraph 1]. 993 a. The MPLS-TP control plane must provide mechanisms to 994 control the performance of this function proactively 995 [RFC5860, section 2.2.7., paragraph 2]. 997 118. The MPLS-TP control plane must provide functionality to enable 998 an Intermediate Point of a PW or LSP to report, to an End Point 999 of that same PW or LSP, a fault or defect condition affecting 1000 that PW or LSP [RFC5860, section 2.2.8., paragraph 1]. 1002 a. The MPLS-TP control plane must provide mechanisms to 1003 control the performance of this function proactively 1004 [RFC5860, section 2.2.8., paragraph 2]. 1006 119. The MPLS-TP control plane must provide functionality to enable 1007 an End Point to report, to its associated End Point, a fault or 1008 defect condition that it detects on a PW, LSP or Section for 1009 which they are the End Points [RFC5860, section 2.2.9., 1010 paragraph 1]. 1012 a. The MPLS-TP control plane must provide mechanisms to 1013 control the performance of this function proactively 1014 [RFC5860, section 2.2.9., paragraph 2]. 1016 120. The MPLS-TP control plane must provide functionality to enable 1017 the propagation, across an MPLS-TP network, of information 1018 pertaining to a client defect or fault condition detected at an 1019 End Point of a PW or LSP, if the client layer mechanisms do not 1020 provide an alarm notification/propagation mechanism [RFC5860, 1021 section 2.2.10., paragraph 1]. 1023 a. The MPLS-TP control plane must provide mechanisms to 1024 control the performance of this function proactively 1025 [RFC5860, section 2.2.10., paragraph 2]. 1027 121. The MPLS-TP control plane must provide functionality to enable 1028 the control of quantification of packet loss ratio over a PW, 1029 LSP or Section [RFC5860, section 2.2.11., paragraph 1]. 1031 a. The MPLS-TP control plane must provide mechanisms to 1032 control the performance of this function proactively and 1033 on-demand [RFC5860, section 2.2.11., paragraph 4]. 1035 122. The MPLS-TP control plane must provide functionality to control 1036 the quantification and reporting of the one-way, and if 1037 appropriate, the two-way, delay of a PW, LSP or Section 1038 [RFC5860, section 2.2.12., paragraph 1]. 1040 a. The MPLS-TP control plane must provide mechanisms to 1041 control the performance of this function proactively and 1042 on-demand [RFC5860, section 2.2.12., paragraph 6]. 1044 123. The MPLS-TP control plane must support the configuration of OAM 1045 functional components which include Maintenance Entities (MEs) 1046 and Maintenance Entity Groups (MEGs) as instantiated in MEPs, 1047 MIPs and SPMEs [TP-OAM, section 3.6]. 1049 124. For dynamically established transport paths, the control plane 1050 must support the configuration of OAM operations [TP-OAM, 1051 section 5]. 1053 a. The MPLS-TP control plane must provide mechanisms to 1054 configure proactive monitoring for a MEG at, or after, 1055 transport path creation time. 1057 b. The MPLS-TP control plane must provide mechanisms to 1058 configure the operational characteristics of in-band 1059 measurement transactions (e.g., CV, LM etc.) are 1060 configured at the MEPs (associated with a transport 1061 path). 1063 c. The MPLS-TP control plane may provide mechanisms to 1064 configure server layer event reporting by intermediate 1065 nodes. 1067 d. The MPLS-TP control plane may provide mechanisms to 1068 configure the reporting of measurements resulting from 1069 proactive monitoring. 1071 125. The MPLS-TP control plane must support the control of the loss 1072 of continuity (LOC) traffic block consequent action [TP-OAM, 1073 section 5.1.2., paragraph 4]. 1075 126. For dynamically established transport paths that have a 1076 proactive Continuity Check and Connectivity Verification (CC-V) 1077 function enabled, the control plane must support the signaling 1078 of the following MEP configuration information [TP-OAM, section 1079 5.1.3]: 1081 a. The MPLS-TP control plane must provide mechanisms to 1082 configure the MEG identifier to which the MEP belongs. 1084 b. The MPLS-TP control plane must provide mechanisms to 1085 configure a MEP's own identity inside a MEG. 1087 c. The MPLS-TP control plane must provide mechanisms to 1088 configure the list of the other MEPs in the MEG. 1090 d. The MPLS-TP control plane must provide mechanisms to 1091 configure the CC-V transmission rate / reception period 1092 (covering all application types). 1094 127. The MPLS-TP control plane must provide mechanisms to configure 1095 the generation of Alarm Indication Signal (AIS) packets for 1096 each MEG [TP-OAM, section 5.3., paragraph 9]. 1098 128. The MPLS-TP control plane must provide mechanisms to configure 1099 the generation of Locked Report (LKR) packets for each MEG [TP- 1100 OAM, section 5.4., paragraph 9]. 1102 129. The MPLS-TP control plane must provide mechanisms to configure 1103 the use of proactive Packet Loss Measurement (LM), and the 1104 transmission rate and Per-hop Behavior (PHB) class associated 1105 with the LM OAM packets originating from a MEP [TP-OAM, section 1106 5.5.1., paragraph 1]. 1108 130. The MPLS-TP control plane must provide mechanisms to configure 1109 the use of proactive Packet Delay Measurement (DM), and the 1110 transmission rate and PHB class associated with the DM OAM 1111 packets originating from a MEP [TP-OAM, section 5.6.1., 1112 paragraph 1]. 1114 131. The MPLS-TP control plane must provide mechanisms to configure 1115 the use of Client Failure Indication (CFI), and the 1116 transmission rate and PHB class associated with the CFI OAM 1117 packets originating from a MEP [TP-OAM, section 5.7.1., 1118 paragraph 1]. 1120 132. The MPLS-TP control plane should provide mechanisms to control 1121 the use of on-demand CV packets [TP-OAM, section 6.1]. 1123 a. The MPLS-TP control plane should provide mechanisms to 1124 configure the number of packets to be 1125 transmitted/received in each burst of on-demand CV 1126 packets and their packet size [TP-OAM, section 6.1.1, 1127 paragraph 1]. 1129 b. When an on-demand CV packet is used to check connectivity 1130 toward a target MIP, the MPLS-TP control plane should 1131 provide mechanisms to configure the number of hops to 1132 reach the target MIP [TP-OAM, section 6.1.1, paragraph 1133 2]. 1135 c. The MPLS-TP control plane should provide mechanisms to 1136 configure the PHB of on-demand CV packets [TP-OAM, 1137 section 6.1.1, paragraph 3]. 1139 133. The MPLS-TP control plane should provide mechanisms to control 1140 the use of on-demand LM, including configuration of the 1141 beginning and duration of the LM procedures, the transmission 1142 rate and PHB associated with the LM OAM packets originating 1143 from a MEP. [TP-OAM, section 6.2.1.] 1145 134. The MPLS-TP control plane should provide mechanisms to control 1146 the use of Throughput estimation [TP-OAM, section 6.3.1]. 1148 135. The MPLS-TP control plane should provide mechanisms to control 1149 the use of on-demand DM, including configuration of the 1150 beginning and duration of the DM procedures, the transmission 1151 rate and PHB associated with the DM OAM packets originating 1152 from a MEP. [TP-OAM, section 6.5.1.] 1154 2.4. Security Requirements 1156 There are no specific MPLS-TP control plane security requirements. 1157 The existing framework for MPLS and GMPLS security is documented in 1158 [RFC5920] and that document applies equally to MPLS-TP. 1160 2.5. Identifier Requirements 1162 The following are requirements based on [TP-IDENTIFIERS]: 1164 136. The MPLS-TP control plane must support MPLS-TP point to point 1165 tunnel identifiers of the forms defined in [TP-IDENTIFIERS, 1166 Section 5.1]. 1168 137. The MPLS-TP control plane must support MPLS-TP LSP identifiers 1169 of the forms defined in [TP-IDENTIFIERS, Section 5.2], and the 1170 mappings to GMPLS as defined in [TP-IDENTIFIERS, Section 5.3]. 1172 138. The MPLS-TP control plane must support Pseudowire path 1173 identifiers of the form defined in [TP-IDENTIFIERS, Section 1174 6.]. 1176 139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs 1177 as defined in [TP-IDENTIFIERS, Section 7.1.1]. 1179 140. The MPLS-TP control plane must support IP compatible MEG_IDs 1180 for LSPs and PWs as defined [TP-IDENTIFIERS, Section 7.1.2]. 1182 141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs 1183 of the forms defined in [TP-IDENTIFIERS, Section 7.2.1]. 1185 142. The MPLS-TP control plane must support IP based MEP_IDs for 1186 MPLS-TP LSP of the forms defined in [TP-IDENTIFIERS, Section 1187 7.2.2.1]. 1189 143. The MPLS-TP control plane must support IP based MEP_IDs for 1190 Pseudowires of the form defined in [TP-IDENTIFIERS, Section 1191 7.2.2.2]. 1193 3. Relationship of PWs and TE LSPs 1195 The data plane relationship between PWs and LSPs is inherited from 1196 standard MPLS and is reviewed in the MPLS-TP Framework [RFC5921]. 1197 Likewise, the control plane relationship between PWs and LSPs is 1198 inherited from standard MPLS. This relationship is reviewed in this 1199 document. The relationship between the PW and LSP control planes in 1200 MPLS-TP is the same as the relationship found in the PWE3 Maintenance 1201 Reference Model as presented in the PWE3 Architecture, see Figure 6 1202 of [RFC3985]. The PWE3 Architecture [RFC3985] states: "the PWE3 1203 protocol-layering model is intended to minimize the differences 1204 between PWs operating over different PSN types." Additionally, PW 1205 control (maintenance) takes place separately from LSP signaling. 1206 [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of 1207 LDP as the control plane for PWs. This control can provide PW 1208 control without providing LSP control. 1210 In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS 1211 RSVP-TE. While RSVP-TE could be extended to support PW control much 1212 as LDP was extended in [RFC4447], such extensions are out of scope of 1213 this document. This means that the control of PWs and LSPs will 1214 operate largely independently. The main coordination between LSP and 1215 PW control will occur within the nodes that terminate PWs, or PW 1216 segments. See Section 5.3.2 for an additional discussion on such 1217 coordination. 1219 It is worth noting that the control planes for PWs and LSPs may be 1220 used independently, and that one may be employed without the other. 1221 This translates into the four possible scenarios: (1) no control 1222 plane is employed; (2) a control plane is used for both LSPs and PWs; 1223 (3) a control plane is used for LSPs, but not PWs; (4) a control 1224 plane is used for PWs, but not LSPs. 1226 The PW and LSP control planes, collectively, must satisfy the MPLS-TP 1227 control plane requirements reviewed in this document. When client 1228 services are provided directly via LSPs, all requirements must be 1229 satisfied by the LSP control plane. When client services are 1230 provided via PWs, the PW and LSP control planes can operate in 1231 combination and some functions may be satisfied via the PW control 1232 plane while others are provided to PWs by the LSP control plane. For 1233 example, to support the recovery functions described in [TP-SURVIVE] 1234 this document focuses on the control of the recovery functions at the 1235 LSP layer. PW based recovery is under development at this time and 1236 may be used once defined. 1238 4. TE LSPs 1240 MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see 1241 [RFC3945], as the control plane for LSPs. The GMPLS control plane is 1242 based on the MPLS control plane. GMPLS includes support for MPLS 1243 labeled data and transport data planes. GMPLS includes most of the 1244 transport centric features required to support MPLS-TP LSPs. This 1245 section will first review the features of GMPLS relevant to MPLS-TP 1246 LSPs, then identify how specific requirements can be met using 1247 existing GMPLS functions, and will conclude with extensions that are 1248 anticipated to support the remaining MPLS-TP control plane 1249 requirements. 1251 4.1. GMPLS Functions and MPLS-TP LSPs 1253 This section reviews how existing GMPLS functions can be applied to 1254 MPLS-TP. 1256 4.1.1. In-Band and Out-Of-Band Control 1258 GMPLS supports both in-band and out-of-band control. The terms in- 1259 band and out-of-band, in the context of this document, refer to the 1260 relationship of the control plane relative to the management and data 1261 planes. The terms may be used to refer to the control plane 1262 independent of the management plane, or to both of them in concert. 1263 The remainder of this section describes the relationship of the 1264 control plane to the management and data planes. 1266 There are multiple uses of both terms in-band and out-of-band. The 1267 terms may relate to a channel, a path or a network. Each of these 1268 can be used independently or in combination. Briefly, some typical 1269 usage of the terms are as follows: 1271 o In-band 1272 This term is used to refer to cases where control plane traffic 1273 is sent in the same communication channel used to transport 1274 associated user data or management traffic. IP, MPLS, and 1275 Ethernet networks are all examples where control traffic is 1276 typically sent in-band with the data traffic. An example of this 1277 case in the context of MPLS-TP is where control plane traffic is 1278 sent via the MPLS Generic Associated Channel (G-ACh), see 1279 [RFC5586], using the same LSP as controlled user traffic. 1281 o Out-of-band, in-fiber (same physical connection) 1282 This term is used to refer to cases where control plane traffic 1283 is sent using a different communication channel from the 1284 associated data or management traffic, and the control 1285 communication channel resides in the same fiber as either the 1286 management or data traffic. An example of this case in the 1287 context of MPLS-TP is where control plane traffic is sent via the 1288 G-ACh using a dedicated LSP on the same link (interface) which 1289 carries controlled user traffic. 1291 o Out-of-band, aligned topology 1292 This term is used to refer to the cases where control plane 1293 traffic is sent using a different communication channel from the 1294 associated data or management traffic, and the control traffic 1295 follows the same node-to-node path as either the data or 1296 management traffic. 1298 Such topologies are usually supported using a parallel fiber or 1299 other configurations where multiple data channels are available 1300 and one is (dynamically) selected as the control channel. An 1301 example of this case in the context of MPLS-TP is where control 1302 plane traffic is sent along the same nodal path, but not 1303 necessarily the same links (interfaces), as the corresponding 1304 controlled user traffic. 1306 o Out-of-band, independent topology 1307 This term is used to refer to the cases where control plane 1308 traffic is sent using a different communication channel from the 1309 associated data or management traffic, and the control traffic 1310 may follow a path that is completely independent of the data 1311 traffic. 1313 Such configurations are a superset of the other cases and do not 1314 preclude the use of in-fiber or aligned topology links, but 1315 alignment is not required. An example of this case in the 1316 context of MPLS-TP is where control plane traffic is sent between 1317 controlling nodes using any available path and links, completely 1318 without regard for the path(s) taken by corresponding management 1319 or user traffic. 1321 In the context of MPLS-TP requirements, requirement 14 (see Section 2 1322 above) can be met using out-of-band in-fiber or aligned topology 1323 types of control. Requirement 15 can only be met by using Out-of- 1324 band, independent topology. G-ACh is likely to be used extensively 1325 in MPLS-TP networks to support the MPLS-TP control (and management) 1326 planes. 1328 4.1.2. Addressing 1330 MPLS-TP reuses and supports the addressing mechanisms supported by 1331 MPLS. The MPLS-TP Identifiers document, see [TP-IDENTIFIERS], 1332 provides additional context on how IP addresses are used within MPLS- 1333 TP. MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address 1334 families to identify MPLS-TP nodes by default for network management 1335 and signaling purposes. The address spaces and neighbor adjacencies 1336 in the control, management and data planes used in an MPLS-TP network 1337 may be completely separated or combined at the discretion of an MPLS- 1338 TP operator and based on the equipment capabilities of a vendor. The 1339 separation of the control and management planes from the data plane 1340 allows each plane to be independently addressable. Each plane may 1341 use addresses that are not mutually reachable, e.g., it is likely 1342 that the data plane will not be able to reach an address from the 1343 management or control planes and vice versa. Each plane may also use 1344 a different address family. It is even possible to reuse addresses 1345 in each plane, but this is not recommended as it may lead to 1346 operational confusion. As previously mentioned, the G-ACh mechanism 1347 defined in [RFC5586] is expected to be used extensively in MPLS-TP 1348 networks to support the MPLS-TP control (and management) planes. 1350 4.1.3. Routing 1352 Routing support for MPLS-TP LSPs is based on GMPLS routing. GMPLS 1353 routing builds on TE routing and has been extended to support 1354 multiple switching technologies per [RFC3945] and [RFC4202] as well 1355 as multiple levels of packet switching (PSC) within a single network. 1356 IS-IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], 1357 which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF 1358 extensions for GMPLS are defined in [RFC4203] and [RFC5392], which 1359 build on the TE extensions to OSPF defined in [RFC3630]. The listed 1360 RFCs should be viewed as a starting point rather than an 1361 comprehensive list as there are other IS-IS and OSPF extensions, as 1362 defined in IETF RFCs, that can be used within an MPLS-TP network. 1364 4.1.4. TE LSPs and Constraint-Based Path Computation 1366 Both MPLS and GMPLS allow for traffic engineering and constraint- 1367 based path computation. MPLS path computation provides paths for 1368 MPLS-TE unidirectional P2P and P2MP LSPs. GMPLS path computation 1369 adds bidirectional LSPs, explicit recovery path computation as well 1370 as support for the other functions discussed in this section. 1372 Both MPLS and GMPLS path computation allow for the restriction of 1373 path selection based on the use of Explicit Route Objects (EROs) and 1374 other LSP attributes, see [RFC3209] and [RFC3473]. In all cases, no 1375 specific algorithm is standardized by the IETF. This is anticipated 1376 to continue to be the case for MPLS-TP LSPs. 1378 4.1.4.1. Relation to PCE 1380 Path Computation Element (PCE)-based approaches, see [RFC4655], may 1381 be used for path computation of a GMPLS LSP, and consequently an 1382 MPLS-TP LSP, across domains and in a single domain. In cases where 1383 PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], 1384 will be used to communicate PCE related requests and responses. MPLS- 1385 TP specific extensions to PCEP are currently out of scope of the 1386 MPLS-TP project and this document. 1388 4.1.5. Signaling 1390 GMPLS signaling is defined in [RFC3471] and [RFC3473], and is based 1391 on RSVP-TE [RFC3209]. CR-LDP based GMPLS, [RFC3472] is no longer 1392 under active development within the IETF, i.e., it is deprecated, see 1393 [RFC3468], and must not be used for MPLS and consequently also MPLS- 1394 TP. In general, all RSVP-TE extensions that apply to MPLS may also 1395 be used for GMPLS and consequently MPLS-TP. Most notably this 1396 includes support for P2MP signaling as defined in [RFC4875]. 1398 GMPLS signaling includes a number of MPLS-TP required functions. 1399 Notably support for out-of-band control, bidirectional LSPs, and 1400 independent control and data plane fault management. There are also 1401 numerous other GMPLS and MPLS extensions that can be used to provide 1402 specific functions in MPLS-TP networks. Specific references are 1403 provided below. 1405 4.1.6. Unnumbered Links 1407 Support for unnumbered links (i.e., links that do not have IP 1408 addresses) is permitted in MPLS-TP and its usage is at the discretion 1409 of the network operator. Support for unnumbered links is included 1410 for routing in [RFC4203] for OSPF and [RFC5307] for IS-IS, and for 1411 signaling in [RFC3477]. 1413 4.1.7. Link Bundling 1415 Link bundling provides a local construct that can be used to improve 1416 scaling of TE routing when multiple data links are shared between 1417 node pairs. Link bundling for MPLS and GMPLS networks is defined in 1418 [RFC4201]. Link bundling may be used in MPLS-TP networks and its use 1419 is at the discretion of the network operator. 1421 4.1.8. Hierarchical LSPs 1423 This section reuses text from [RFC6107]. 1425 [RFC3031] describes how MPLS labels may be stacked so that LSPs may 1426 be nested with one LSP running through another. This concept of 1427 Hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of 1428 protocol mechanisms for the establishment of a hierarchical LSP that 1429 can carry one or more other LSPs. 1431 [RFC4206] goes on to explain that a hierarchical LSP may carry other 1432 LSPs only according to their switching types. This is a function of 1433 the way labels are carried. In a packet switch capable (PSC) network, 1434 the hierarchical LSP can carry other PSC LSPs using the MPLS label 1435 stack. 1437 Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to 1438 be treated as a single hop in the path of another LSP. This 1439 mechanism is also sometimes known as "non-adjacent signaling", see 1440 [RFC4208]. 1442 A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link 1443 created from an LSP and advertised in the same instance of the 1444 control plane that advertises the TE links from which the LSP is 1445 constructed. The LSP itself is called an FA-LSP. FA LSPs are 1446 analogous to MPLS-TP Sections as discussed in [RFC5960]. 1448 Thus, a hierarchical LSP may form an FA such that it is advertised as 1449 a TE link in the same instance of the routing protocol as was used to 1450 advertise the TE links that the LSP traverses. 1452 As observed in [RFC4206] the nodes at the ends of an FA would not 1453 usually have a routing adjacency. 1455 LSP hierarchy is expected to play an important role in MPLS-TP 1456 networks, particularly in the context of scaling and recovery as well 1457 as supporting SPMEs. 1459 4.1.9. LSP Recovery 1461 GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs 1462 recovery in [RFC4872], and segment recovery in [RFC4873] . GMPLS 1463 segment recovery provides a superset of the function in end-to-end 1464 recovery. End-to-end recovery can be viewed as a special case of 1465 segment recovery where there is a single recovery domain whose 1466 borders coincide with the ingress and egress of the LSP, although 1467 specific procedures are defined. 1469 The five defined types of recovery defined in GMPLS are: 1471 - 1+1 bidirectional protection for P2P LSPs 1472 - 1+1 unidirectional protection for P2MP LSPs 1473 - 1:n (including 1:1) protection with or without extra traffic 1474 - Rerouting without extra traffic (sometimes known as soft 1475 rerouting), including shared mesh restoration 1476 - Full LSP rerouting 1478 Recovery for MPLS-TP LSPs, as discussed in [TP-SURVIVE], is signaled 1479 using the mechanism defined in [RFC4872] and [RFC4873]. Note that 1480 when MEPs are required for the OAM CC function and the MEPs exist at 1481 LSP transit nodes, each MEP is instantiated at a hierarchical LSP end 1482 point, and protection is provided end-to-end for the hierarchical 1483 LSP. (Protection can be signaled using either [RFC4872] or [RFC4873] 1484 defined procedures.) The use of Notify messages to trigger protection 1485 switching and recovery is not required in MPLS-TP as this function is 1486 expected to be supported via OAM. However, its use is not precluded. 1488 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) 1490 The majority of GMPLS control plane related RFCs define the control 1491 plane from the context of an internal network-to-network interface 1492 (I-NNI). In the MPLS-TP context, some operators may choose to deploy 1493 signaled interfaces across user-to-network (UNI) interfaces and 1494 across inter-provider, external network-to-network (E-NNI), 1495 interfaces. Such support is embodied in [RFC4208] for UNIs and 1496 [RFC5787] for routing areas in support of E-NNIs. This work may 1497 require extensions in order to meet the specific needs of an MPLS-TP 1498 UNI and E-NNI. 1500 4.2. OAM, MEP (Hierarchy), MIP Configuration and Control 1502 MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM 1503 functions. The MPLS-TP control plane will not itself provide OAM 1504 functions, but it will be used to instantiate and otherwise control 1505 MPLS-TP OAM functions. 1507 Specific OAM requirements for MPLS-TP are documented in [RFC5860]. 1508 This document also states that it is also required that the control 1509 plane be able to configure and control OAM entities. This 1510 requirement is not yet addressed by the existing RFCs, but such work 1511 is now underway, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT]. 1513 Many OAM functions occur on a per-LSP basis, are typically in-band, 1514 and are initiated immediately after LSP establishment. Hence, it is 1515 desirable that such functions be established and activated via the 1516 same control plane signaling used to set up the LSP, as this 1517 effectively synchronizes OAM with the LSP lifetime and avoids the 1518 extra overhead and potential errors associated with separate OAM 1519 configuration mechanisms. 1521 4.2.1. Management Plane Support 1523 There is no MPLS-TP requirement for a standardized management 1524 interface to the MPLS-TP control plane. That said, MPLS and GMPLS 1525 support a number of standardized management functions. These include 1526 the MPLS-TE/GMPLS TE Database Management Information Base (MIB), [TE- 1527 MIB]; the MPLS-TE MIB, [RFC3812]; the MPLS LSR MIB, [RFC3813]; the 1528 GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803]. These MIB 1529 modules may be used in MPLS-TP networks. A general overview of MPLS- 1530 TP related MIB modules can be found in [TP-MIB]. Network management 1531 requirements for MPLS-based transport networks are provided in 1532 [RFC5951] 1534 4.2.1.1. Recovery Triggers 1536 The GMPLS control plane allows for management plane recovery triggers 1537 and directly supports control plane recovery triggers. Support for 1538 control plane recovery triggers is defined in [RFC4872] which refers 1539 to the triggers as "Recovery Commands". These commands can be used 1540 with both end-to-end and segment recovery, but are always controlled 1541 on an end-to-end basis. The recovery triggers/commands defined in 1542 [RFC4872] are: 1544 a. Lockout of recovery LSP 1546 b. Lockout of normal traffic 1548 c. Forced switch for normal traffic 1550 d. Requested switch for normal traffic 1552 e. Requested switch for recovery LSP 1554 Note that control plane triggers are typically invoked in response to 1555 a management plane request at the ingress. 1557 4.2.1.2. Management Plane / Control Plane Ownership Transfer 1559 In networks where both control plane and management plane are 1560 provided, LSP provisioning can be done either by control plane or 1561 management plane. As mentioned in the requirements section above, it 1562 must be possible to transfer, or handover, a management plane created 1563 LSP to the control plane domain and vice versa. [RFC5493] defines the 1564 specific requirements for an LSP ownership handover procedure. It 1565 must be possible for the control plane to provide the management 1566 plane, in a reliable manner, with the status or result of an 1567 operation performed by the management plane. This notification may 1568 be either synchronous or asynchronous with respect to the operation. 1569 Moreover, it must be possible for the management plane to monitor the 1570 status of the control plane, for example the status of a TE Link, its 1571 available resources, etc. This monitoring may be based on queries 1572 initiated by the management plane or on notifications generated by 1573 the control plane. A mechanism must be made available by the control 1574 plane to the management plane to log control plane LSP related 1575 operation, that is, it must be possible from the NMS to have a clear 1576 view of the life (traffic hit, action performed, signaling, etc.) of 1577 a given LSP. The LSP handover procedure for MPLS-TP LSPs is supported 1578 via [RFC5852]. 1580 4.3. GMPLS and MPLS-TP Requirements Table 1582 The following table shows how the MPLS-TP control plane requirements 1583 can be met using the existing GMPLS control plane (which builds on 1584 the MPLS control plane). Areas where additional specifications are 1585 required are also identified. The table lists references based on 1586 the control plane requirements as identified and numbered above in 1587 section 2. 1589 +=======+===========================================================+ 1590 | Req # | References | 1591 +-------+-----------------------------------------------------------+ 1592 | 1 | Generic requirement met by using Standards Track RFCs | 1593 | 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1594 | 3 | [RFC5145] + Formal Definition (See Section 4.4.1) | 1595 | 4 | Generic requirement met by using Standards Track RFCs | 1596 | 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1597 | 6 | [RFC3471], [RFC3473], [RFC4875] | 1598 | 7 | [RFC3471], [RFC3473] + | 1599 | | Associated bidirectional LSPs (See Section 4.4.2) | 1600 | 8 | [RFC4875] | 1601 | 9 | [RFC3473] | 1602 | 10 | Associated bidirectional LSPs (See Section 4.4.2) | 1603 | 11 | Associated bidirectional LSPs (See Section 4.4.2) | 1604 | 12 | [RFC3473] | 1605 | 13 | [RFC5467] (Currently Experimental, See Section 4.4.3) | 1606 | 14 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] | 1607 | 15 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] | 1608 | 16 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1609 | 17 | [RFC3945], [RFC4202] + proper vendor implementation | 1610 | 18 | [RFC3945], [RFC4202] + proper vendor implementation | 1611 | 19 | [RFC3945], [RFC4202] | 1612 | 20 | [RFC3473] | 1613 | 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | 1614 | | [RFC5151] | 1615 | 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | 1616 | | [RFC5151] | 1617 | 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1618 | 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1619 | 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | 1620 | | [RFC6107] | 1621 | 26 | [RFC3473], [RFC4875] | 1622 | 27 | [RFC3473], [RFC4875] | 1623 | 28 | [RFC3945], [RFC3471], [RFC4202] | 1624 | 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1625 | 30 | [RFC3945], [RFC3471], [RFC4202] | 1626 | 31 | [RFC3945], [RFC3471], [RFC4202] | 1627 | 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] | 1628 | 33 | [RFC3473], [RFC4875] | 1629 | 34 | [RFC4875] | 1630 | 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1631 | 36 | [RFC3473], [RFC3209] (Make-before-break) | 1632 | 37 | [RFC3473], [RFC3209] (Make-before-break) | 1633 | 38 | | 1634 | 38 | [RFC4139], [RFC4258], [RFC5787] | 1635 | 39 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1636 | 40 | [RFC3473], [RFC5063] | 1637 | 41 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] | 1638 | 42 | [RFC3945], [RFC3471], [RFC4202] | 1639 | 43 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1640 | 44 | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1641 | 45 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | 1642 | 46 | [RFC5493] | 1643 | 47 | [RFC4872], [RFC4873] | 1644 | 48 | [RFC3945], [RFC3471], [RFC4202] | 1645 | 49 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | 1646 | 50 | [RFC4872], [RFC4873] | 1647 | 51 | [RFC4872], [RFC4873] + proper vendor implementation | 1648 | 52 | [RFC4872], [RFC4873], [GMPLS-PS] | 1649 | 53 | [RFC4872], [RFC4873] | 1650 | 54 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] | 1651 | | Timers are a local implementation matter | 1652 | 55 | [RFC4872], [RFC4873], [GMPLS-PS] + | 1653 | | implementation of timers | 1654 | 56 | [RFC4872], [RFC4873], [GMPLS-PS] | 1655 | 57 | [RFC4872], [RFC4873] | 1656 | 58 | [RFC4872], [RFC4873] | 1657 | 59 | [RFC4872], [RFC4873] | 1658 | 60 | [RFC4872], [RFC4873], [RFC6107] | 1659 | 61 | [RFC4872], [RFC4873] | 1660 | 62 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | 1661 | 63 | [RFC4872], [RFC4873] | 1662 | 64 | [RFC4872], [RFC4873] | 1663 | 65 | [RFC4872], [RFC4873] | 1664 | 66 | [RFC4872], [RFC4873], [RFC6107] | 1665 | 67 | [RFC4872], [RFC4873] | 1666 | 68 | [RFC3473], [RFC4872], [RFC4873] | 1667 | 69 | [RFC3473] | 1668 | 70 | [RFC3473], [RFC4872], [GMPLS-PS] | 1669 | 71 | [RFC3473], [RFC4872] | 1670 | 72 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1671 | 73 | [RFC4426], [RFC4872], [RFC4873] | 1672 | 74 | [RFC4426], [RFC4872], [RFC4873] | 1673 | 75 | [RFC4426], [RFC4872], [RFC4873] | 1674 | 76 | [RFC4426], [RFC4872], [RFC4873] | 1675 | 77 | [RFC4426], [RFC4872], [RFC4873] | 1676 | 78 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation | 1677 | 79 | [RFC4426], [RFC4872], [RFC4873] | 1678 | 80 | [RFC4426], [RFC4872], [RFC4873] | 1679 | 81 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | 1680 | 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | 1681 | 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | 1682 | 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | 1683 | 85 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1684 | 86 | [RFC4872], [RFC4873] | 1685 | 87 | [RFC4872], [RFC4873] | 1686 | 88 | [RFC4872], [RFC4873], [TP-RING] | 1687 | 89 | [RFC4872], [RFC4873], [TP-RING] | 1688 | 90 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | 1689 | 91 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 1690 | 92 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] | 1691 | 93 | Generic requirement on data plane (correct implementation)| 1692 | 94 | [RFC3473], [NO-PHP] | 1693 | 95 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | 1694 | 96 | PW only requirement, see PW Requirements Table (5.2) | 1695 | 97 | PW only requirement, see PW Requirements Table (5.2) | 1696 | 98 | [RFC3945], [RFC3473], [RFC6107] | 1697 | 99 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + | 1698 | | [RFC5392] and [RFC5316] | 1699 | 100 | PW only requirement, see PW Requirements Table (5.2) | 1700 | 101 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | 1701 | 102 | [RFC4872], [RFC4873], [TP-RING] | 1702 | 103 | [RFC3945], [RFC3473], [RFC6107] | 1703 | 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1704 | 105 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1705 | 106 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1706 | 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 1707 | 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1708 | 109 | [RFC3473], [RFC4872], [RFC4873] | 1709 | 110 | [RFC3473], [RFC4872], [RFC4873] | 1710 | 111 | [RFC3473], [RFC4783] | 1711 | 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | 1712 | 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 1713 | 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 1714 | 115 | [RFC3473] | 1715 | 116 | [RFC4426], [RFC4872], [RFC4873] | 1716 | 117 | [RFC3473], [RFC4872], [RFC4873] | 1717 | 118 | [RFC3473], [RFC4783] | 1718 | 119 | [RFC3473] | 1719 | 120 | [RFC3473], [RFC4783] | 1720 | 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 1721 | 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 1722 | 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] | 1723 | 124 - | | 1724 | 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 1725 | 136a | [RFC3473] | 1726 | 136b | [RFC3473] + (See Sec. 4.4.7) | 1727 | 137a | [RFC3473] | 1728 | 137b | [RFC3473] + (See Sec. 4.4.7) | 1729 | 138 | PW only requirement, see PW Requirements Table (5.2) | 1730 | 139 - | | 1731 | 143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) | 1732 +=======+===========================================================+ 1734 Table 1: GMPLS and MPLS-TP Requirements Table 1736 4.4. Anticipated MPLS-TP Related Extensions and Definitions 1738 This section identifies the extensions and other documents that have 1739 been identified as likely to be needed to support the full set of 1740 MPLS-TP control plane requirements. 1742 4.4.1. MPLS-TE to MPLS-TP LSP Control Plane Interworking 1744 While no interworking function is expected in the data-plane to 1745 support the interconnection of MPLS-TE and MPLS-TP networking, this 1746 is not the case for the control plane. MPLS-TE networks typically 1747 use LSP signaling based on [RFC3209] while MPLS-TP LSPs will be 1748 signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies 1749 a set of solutions that are aimed to aid in the interworking of MPLS- 1750 TE and GMPLS control planes. [RFC5145] work will serve as the 1751 foundation for a formal definition of MPLS to MPLS-TP control plane 1752 interworking. 1754 4.4.2. Associated Bidirectional LSPs 1756 GMPLS signaling, [RFC3473], supports unidirectional, and co-routed 1757 bidirectional point-to-point LSPs. MPLS-TP also requires support for 1758 associated bidirectional point-to-point LSPs. Such support will 1759 require an extension or a formal definition of how the LSP endpoints 1760 supporting an associated bidirectional service will coordinate the 1761 two LSPs used to provide such a service. Per requirement 11, transit 1762 nodes that support an associated bidirectional service should be 1763 aware of the association of the LSPs used to support the service when 1764 both LSPs are supported on that transit node. There are several 1765 existing protocol mechanisms on which to base such support, 1766 including, but not limited to: 1768 o GMPLS calls, [RFC4974]. 1770 o The ASSOCIATION object, [RFC4872]. 1772 o The LSP_TUNNEL_INTERFACE_ID object, [RFC6107]. 1774 4.4.3. Asymmetric Bandwidth LSPs 1776 [RFC5467] defines support for bidirectional LSPs which have different 1777 (asymmetric) bandwidth requirements for each direction. This RFC can 1778 be used to meet the related MPLS-TP technical requirement, but this 1779 RFC is currently an Experimental RFC. To fully satisfy the MPLS-TP 1780 requirement this document will need to become a Standards Track RFC. 1782 4.4.4. Recovery for P2MP LSPs 1784 The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and 1785 [RFC4873], do not explicitly cover their interactions. MPLS-TP 1786 requires a formal definition of recovery techniques for P2MP LSPs. 1787 Such a formal definition will be based on existing RFCs and may not 1788 require any new protocol mechanisms but, nonetheless, must be 1789 documented. 1791 4.4.5. Test Traffic Control and other OAM functions 1793 [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related 1794 control extensions to GMPLS. These extensions cover a portion, but 1795 not all OAM-related control functions that have been identified in 1796 the context of MPLS-TP. As discussed above, the MPLS-TP control 1797 plane must support the selection of which (if any) OAM function(s) to 1798 use (including support to select experimental OAM functions) and what 1799 OAM functionality to run, including, continuity check (CC), 1800 connectivity verification (CV), packet loss and delay quantification, 1801 and diagnostic testing of a service. Such support may be included in 1802 the listed documents or in other documents. 1804 4.4.6. DiffServ Object usage in GMPLS 1806 [RFC3270] and [RFC4124] define support for DiffServ-enabled MPLS 1807 LSPs. While [RFC4124] references GMPLS signaling, there is no 1808 explicit discussion on the use of the DiffServ-related objects in 1809 GMPLS signaling. A (possibly Informational) document on how GMPLS 1810 supports DiffServ LSPs is likely to prove useful in the context of 1811 MPLS-TP. 1813 4.4.7. Support for MPLS-TP LSP Identifiers 1815 MPLS-TP uses two forms of LSP identifiers, see [TP-IDENTIFIERS]. One 1816 form is based on existing GMPLS fields. The other form is based on 1817 either the globally unique Attachment Interface Identifier (AII) 1818 defined in [RFC5003], or the M.1400 defined the ITU Carrier Code 1819 (ICC). Neither form is currently supported in GMPLS and such 1820 extensions will need to be documented. 1822 4.4.8. Support for MPLS-TP Maintenance Identifiers 1824 MPLS-TP defines several forms of maintenance entity-related 1825 identifiers. Both node unique and global forms are defined. 1826 Extensions will be required to GMPLS to support these identifiers. 1827 These extensions may be added to existing works in progress, such as 1828 [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent 1829 documents. 1831 5. Pseudowires 1833 5.1. LDP Functions and Pseudowires 1835 MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for 1836 emulated services over an MPLS Packet Switched Network (PSN). 1837 Several types of PWs have been defined: (1) Ethernet PWs providing 1838 for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2) 1839 HDLC/PPP PW providing for HDLC/PPP leased line transport over 1840 MPLS[RFC4618], (3) ATM PWs [RFC4816], (4) Frame Relay PWs [RFC4619], 1841 and (5) circuit Emulation PWs [RFC4553]. 1843 Today's transport networks based on PDH, WDM, or SONET/SDH provide 1844 transport for PDH or SONET (e.g., ATM over SONET or Packet PPP over 1845 SONET) client signals with no payload awareness. Implementing PW 1846 capability allows for the use of an existing technology to substitute 1847 the TDM transport with packet based transport, using well-defined PW 1848 encapsulation methods for carrying various packet services over MPLS, 1849 and providing for potentially better bandwidth utilization. 1851 There are two general classes of PWs: (1) Single-Segment Pseudowires 1852 (SS-PW) [RFC3985], and (2) Multi-segment Pseudowires (MS-PW) 1853 [RFC5659]. An MPLS-TP network domain may transparently transport a 1854 PW whose endpoints are within a client network. Alternatively, an 1855 MPLS-TP edge node may be the Terminating PE (T-PE) for a PW, 1856 performing adaptation from the native attachment circuit technology 1857 (e.g. Ethernet 802.1Q) to an MPLS PW which is then transported in an 1858 LSP over an MPLS-TP network. In this way, the PW is analogous to a 1859 transport channel in a TDM network and the LSP is equivalent to a 1860 container of multiple non-concatenated channels, albeit they are 1861 packet containers. An MPLS-TP network may also contain Switching PEs 1862 (S-PEs) for a multi-segment PW whereby the T-PEs may be at the edge 1863 of an MPLS-TP network or in a client network. In this latter case, a 1864 T-PE in a client network is a T-PE performing the adaptation of the 1865 native service to MPLS and an MPLS-TP network performs pseudowire 1866 switching. 1868 The SS-PW signaling control plane is based on targeted LDP (T-LDP) 1869 with specific procedures defined in [RFC4447]. The MS-PW signaling 1870 control plane is also based on T-LDP as allowed for in [RFC5659], 1871 [RFC6073] and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the same 1872 PW signaling protocols and procedures for placing SS-PWs and MS-PWs. 1873 This will leverage existing technology as well as facilitate 1874 interoperability with client networks with native attachment circuits 1875 or PW segments that are switched across an MPLS-TP network. 1877 5.1.1. Management Plane Support 1879 There is no MPLS-TP requirement for a standardized management 1880 interface to the MPLS-TP control plane. A general overview of MPLS- 1881 TP related MIB modules can be found in [TP-MIB]. Network management 1882 requirements for MPLS-based transport networks are provided in 1883 [RFC5951]. 1885 5.2. PW Control (LDP) and MPLS-TP Requirements Table 1887 The following table shows how the MPLS-TP control plane requirements 1888 can be met using the existing LDP control plane for Pseudowires 1889 (targeted LDP). Areas where additional specifications are required 1890 are also identified. The table lists references based on the control 1891 plane requirements as identified and numbered above in section 2. 1893 In the table below, several of the requirements shown are addressed - 1894 in part or in full - by the use of MPLS-TP LSPs to carry pseudowires. 1895 This is reflected by including "TP-LSPs" as a reference for those 1896 requirements. Section 5.3.2 provides additional context for the 1897 binding of PWs to TP-LSPs. 1899 +=======+===========================================================+ 1900 | Req # | References | 1901 +-------+-----------------------------------------------------------+ 1902 | 1 | Generic requirement met by using Standards Track RFCs | 1903 | 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) | 1904 | 3 | [RFC3985], [RFC4447] | 1905 | 4 | Generic requirement met by using Standards Track RFCs | 1906 | 5 | [RFC3985], [RFC4447], Together with TP-LSPs | 1907 | 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs | 1908 | 7 | [RFC3985], [RFC4447], + TP-LSPs | 1909 | 8 | [PW-P2MPR], [PW-P2MPE] | 1910 | 9 | [RFC3985], end-node only involvement for PW | 1911 | 10 | [RFC3985], proper vendor implementation | 1912 | 11 | [RFC3985], end-node only involvement for PW | 1913 | 12-13 | [RFC3985], [RFC4447], See Section 5.3.4 | 1914 | 14 | [RFC3985], [RFC4447] | 1915 | 15 | [RFC4447], [RFC3478], proper vendor implementation | 1916 | 16 | [RFC3985], [RFC4447] | 1917 | 17-18 | [RFC3985], proper vendor implementation | 1918 | 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation | 1919 | 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] | 1920 | | [RFC4842], [RFC5287] | 1921 | 28 | [RFC3985] | 1922 | 29-31 | [RFC3985], [RFC4447] | 1923 | 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6. | 1924 | 33 | [RFC4385], [RFC4447], [RFC5586] | 1925 | 34 | [PW-P2MPR], [PW-P2MPE] | 1926 | 35 | [RFC4863] | 1927 | 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 | 1928 | 38 | Provided by TP-LSPs | 1929 | 39 | [RFC3985], [RFC4447], + TP-LSPs | 1930 | 40 | [RFC3478] | 1931 | 41-42 | [RFC3985], [RFC4447] | 1932 | 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 | 1933 | 45 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs | 1934 | 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 | 1935 | 47 | [PW-RED], [PW-REDB] | 1936 | 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation | 1937 | 50-52 | Provided by TP-LSPs, and Section 5.3.5 | 1938 | 53-55 | [RFC3985], [RFC4447], See Section 5.3.5 | 1939 | 56 | [PW-RED], [PW-REDB] | 1940 | | revertive/non-revertive behavior is a local matter for PW | 1941 | 57-58 | [PW-RED], [PW-REDB] | 1942 | 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | 1943 | 82-83 | [RFC5085], [RFC5586], [RFC5885] | 1944 | 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | 1945 | 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation | 1946 | 96 | [RFC4447], [MS-PW-DYNAMIC] | 1947 | 97 | [RFC4447] | 1948 | 98 - | | 1949 | 99 | Not Applicable to PW | 1950 | 100 | [RFC4447] | 1951 | 101 | [RFC3478] | 1952 | 102 | [RFC3985], + TP-LSPs | 1953 | 103 | Not Applicable to PW | 1954 | 104 | [PW-OAM] | 1955 | 105 | [PW-OAM] | 1956 | 106 - | | 1957 | 108 | [RFC5085], [RFC5586], [RFC5885] | 1958 | 109 | [RFC5085], [RFC5586], [RFC5885] | 1959 | | fault reporting and protection triggering is a local | 1960 | | matter for PW | 1961 | 110 | [RFC5085], [RFC5586], [RFC5885] | 1962 | | fault reporting and protection triggering is a local | 1963 | | matter for PW | 1964 | 111 | [RFC4447] | 1965 | 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] | 1966 | 113 | [RFC5085], [RFC5586], [RFC5885] | 1967 | 114 | [RFC5085], [RFC5586], [RFC5885] | 1968 | 115 | path traversed by PW is determined by LSP path, see | 1969 | | GMPLS and MPLS-TP Requirements Table, 4.3 | 1970 | 116 | [PW-RED], [PW-REDB], administrative control of redundant | 1971 | | PW is a local matter at the PW head-end | 1972 | 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] | 1973 | 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | 1974 | 119 | [RFC4447] | 1975 | 120 - | | 1976 | 125 | [RFC5085], [RFC5586], [RFC5885] | 1977 | 126 - | | 1978 | 130 | [PW-OAM] | 1979 | 131 | Section 5.3.5 | 1980 | 132 | [PW-OAM] | 1981 | 133 | [PW-OAM] | 1982 | 134 | Section 5.3.5 | 1983 | 135 | [PW-OAM] | 1984 | 136 | Not Applicable to PW | 1985 | 137 | Not Applicable to PW | 1986 | 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] | 1987 | 139 - | | 1988 | 143 | [PW-OAM] | 1989 +=======+===========================================================+ 1991 Table 2: PW Control (LDP) and MPLS-TP Requirements Table 1993 5.3. Anticipated MPLS-TP Related Extensions 1995 Existing control protocol and procedures will be reused as much as 1996 possible to support MPLS-TP. However, when using PWs in MPLS-TP, a 1997 set of new requirements are defined which may require extensions of 1998 the existing control mechanisms. This section clarifies the areas 1999 where extensions are needed based on the PW Control Plane related 2000 requirements documented in [RFC5654]. 2002 Table 2 lists how requirements defined in [RFC5654] are expected to 2003 be addressed. 2005 The baseline requirement for extensions to support transport 2006 applications is that any new mechanisms and capabilities must be able 2007 to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 2008 [RFC3985] control and data planes where appropriate. Hence, 2009 extensions of the PW Control Plane must be in-line with the 2010 procedures defined in [RFC4447], [RFC6073] and [MS-PW-DYNAMIC]. 2012 5.3.1. Extensions to Support Out-of-Band PW Control 2014 For MPLS-TP, it is required that the data and control planes can be 2015 both logically and physically separated. That is, the PW Control 2016 Plane must be able to operate out-of-band (OOB). This separation 2017 ensures, among other things, that in the case of control plane 2018 failures the data plane is not affected and can continue to operate 2019 normally. This was not a design requirement for the current PW 2020 Control Plane. However, due to the PW concept, i.e., PWs are 2021 connecting logical entities ('forwarders'), and the operation of the 2022 PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part 2023 in the signaling exchanges: moving T-LDP out-of-band seems to be, 2024 theoretically, a straightforward exercise. 2026 In fact, as a strictly local matter, ensuring that targeted LDP (T- 2027 LDP) uses out-of-band signaling requires only that the local 2028 implementation is configured in such a way that reachability for a 2029 target LSR address is via the out-of-band channel. 2031 More precisely, if IP addressing is used in the MPLS-TP control plane 2032 then T-LDP addressing can be maintained, although all addresses will 2033 refer to control plane entities. Both, the PWid FEC and Generalized 2034 PWid FEC Elements can possibly be used in an OOB case as well. 2035 (Detailed evaluation is outside the scope of this document). The PW 2036 Label allocation and exchange mechanisms should be reused without 2037 change. 2039 5.3.2. Support for Explicit Control of PW-to-LSP Binding 2041 Binding a PW to an LSP, or PW segments to LSPs is left to nodes 2042 acting as T-PEs and S-PEs or a control plane entity that may be the 2043 same one signaling the PW. However, an extension of the PW signaling 2044 protocol is required to allow the LSR at signal initiation end to 2045 inform the targeted LSR (at the signal termination end) which LSP the 2046 resulting PW is to be bound to, in the event that more than one such 2047 LSP exists and the choice of LSPs is important to the service being 2048 setup (for example, if the service requires co-routed bidirectional 2049 paths). This is also particularly important to support transport path 2050 (symmetric and asymmetric) bandwidth requirements. 2052 For transport services, MPLS-TP requires support for bidirectional 2053 traffic which follows congruent paths. Currently, each direction of a 2054 PW or a PW segment is bound to a unidirectional LSP that extends 2055 between two T-PEs, S-PEs, or a T-PE and an S-PE. The unidirectional 2056 LSPs in both directions are not required to follow congruent paths, 2057 and therefore both directions of a PW may not follow congruent paths, 2058 i.e., they are associated bidirectional paths. The only requirement 2059 in [RFC5659] is that a PW or a PW segment shares the same T-PEs in 2060 both directions, and same S-PEs in both directions. 2062 MPLS-TP imposes new requirements on the PW Control Plane, in 2063 requiring that both end points map the PW or PW segment to the same 2064 transport path for the case where this is an objective of the 2065 service. When a bidirectional LSP is selected on one end to 2066 transport the PW, a mechanism is needed that signals to the remote 2067 end which LSP has been selected locally to transport the PW. This 2068 would be accomplished by adding a new TLV to PW signaling. 2070 Note that this coincides with the gap identified for OOB support: a 2071 new mechanism is needed to allow explicit binding of a PW to the 2072 supporting transport LSP. 2074 The case of unidirectional transport paths may also require 2075 additional protocol mechanisms as today's PWs are always 2076 bidirectional. One potential approach for providing a unidirectional 2077 PW based transport path is for the PW to associate different 2078 (asymmetric) bandwidths in each direction, with a zero or minimal 2079 bandwidth for the return path. This approach is consistent with 2080 Section 3.8.2 of [RFC5921] but does not address P2MP paths. 2082 5.3.3. Support for Dynamic Transfer of PW Control/Ownership 2084 In order to satisfy requirement 47 (as defined in section 2) it will 2085 be necessary to specify methods for transfer of PW ownership from the 2086 management to the control plane (and vice versa). 2088 5.3.4. Interoperable Support for PW/LSP Resource Allocation 2090 Transport applications may require resource guarantees. For such 2091 transport LSPs, resource reservation mechanisms are provided via 2092 RSVP-TE and the use of DiffServ. If multiple PWs are multiplexed into 2093 the same transport LSP resources, contention may occur. However, 2094 local policy at PEs should ensure proper resource sharing among PWs 2095 mapped into a resource guaranteed LSP. In the case of MS-PWs, 2096 signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable 2097 admission control of a PW segment over a resource-guaranteed LSP. 2099 In conjunction with explicit PW-to-LSP binding, existing mechanisms 2100 may be sufficient, however this needs to be verified in detailed 2101 evaluation. 2103 5.3.5. Support for PW Protection and PW OAM Configuration 2105 Many of the requirements listed in section 2 are intended to support 2106 connectivity and performance monitoring (grouped together as OAM) and 2107 protection conformant with the transport services model. 2109 In general, protection of MPLS-TP transported services is provided by 2110 way of protection of transport LSPs. PW protection requires that 2111 mechanisms be defined to support redundant Pseudowires, including a 2112 mechanism already described above for associating such Pseudowires 2113 with specific protected ("working" and "protection") LSPs. Also 2114 required are definitions of local protection control functions, to 2115 include test/verification operations, and protection status signals 2116 needed to ensure that PW termination points are in agreement as to 2117 which of a set of redundant Pseudowires are in use for which 2118 transport services at any given point in time. 2120 Much of this work is currently being done in drafts [PW-RED] and [PW- 2121 REDB] that define - respectively - how to establish redundant 2122 Pseudowires and how to indicate which is in use. Additional work may 2123 be required. 2125 Protection switching may be triggered manually by the operator, or as 2126 a result of loss of connectivity (detected using the mechanisms of 2127 [RFC5085] and [RFC5586]), or service degradation (detected using 2128 mechanisms yet to be defined). 2130 Automated protection switching is just one of the functions for which 2131 a transport service requires OAM. OAM is generally referred to as 2132 either "proactive" or "on-demand", where the distinction is whether a 2133 specific OAM tool is being used continuously over time (for the 2134 purpose of detecting a need for protection switching, for example) or 2135 is only used - either a limited number of times, or over a short 2136 period of time - when explicitly enabled (for diagnostics, for 2137 example). 2139 PW OAM currently consists of connectivity verification defined by 2140 [RFC5085]. Work is currently in progress to extend PW OAM to include 2141 bidirectional forwarding detection (BFD) in [RFC5885], and work has 2142 begun on extending BFD to include performance-related monitor 2143 functions. 2145 5.3.6. Client Layer and Cross-Provider Interfaces to PW Control 2147 Additional work is likely to be required to define consistent access 2148 by a client layer network, as well as between provider networks, to 2149 control information available to each type of network, for example, 2150 about the topology of an MS-PW. This information may be required by 2151 the client layer network in order to provide hints that may help to 2152 avoid establishment of fate-sharing alternate paths. Such work will 2153 need to fit within the ASON architecture, see requirement 39 above. 2155 5.4. ASON Architecture Considerations 2157 MPLS-TP PWs are always transported using LSPs, and these LSP will 2158 either have been statically provisioned or signaled using GMPLS. 2160 For LSPs signaled using the MPLS-TP LSP control plane (GMPLS), 2161 conformance with the ASON architecture is as described in Section 1.2 2162 ("Basic Approach"), bullet 4, of this framework document. 2164 As discussed above in Section 5.3, there are anticipated extensions 2165 in the following areas that may be related to ASON architecture: 2167 - PW-to-LSP binding (Section 5.3.2) 2168 - PW/LSP resource allocation (Section 5.3.4) 2169 - PW protection and OAM configuration (Section 5.3.5) 2170 - Client layer Interfaces for PW control (Section 5.3.6) 2172 This work is expected to be consistent with ASON architecture and may 2173 require additional specification in order to achieve this goal. 2175 6. Security Considerations 2177 This document primarily describes how existing mechanisms can be used 2178 to meet the MPLS-TP control plane requirements. The documents that 2179 describe each mechanism contain their own security considerations 2180 sections. For a general discussion on MPLS- and GMPLS-related 2181 security issues, see the MPLS/GMPLS security framework [RFC5920]. As 2182 mentioned above in Section 2.4., there are no specific MPLS-TP 2183 control plane security requirements. 2185 This document also identifies a number of needed control plane 2186 extensions. It is expected that the documents that define such 2187 extensions will also include any appropriate security considerations. 2189 7. IANA Considerations 2191 There are no new IANA considerations introduced by this document. 2193 8. Acknowledgments 2195 The authors would like to acknowledge the contributions of Yannick 2196 Brehon, Diego Caviglia, Nic Neate, Dave Mcdysan, Dan Frost, and Eric 2197 Osborne to this work. We also thank Dan Frost in his help responding 2198 to last call comments. 2200 9. References 2202 9.1. Normative References 2204 [RFC2210] Wroclawski, J., "The Use of RSVP with Integrated 2205 Services", RFC 2210, September 1997. 2207 [RFC2211] Wroclawski, J., "Specification of the Controlled Load 2208 Quality of Service", RFC 2211, September 1997. 2210 [RFC2212] Shenker, S., Partridge, C., and R Guerin, "Specification 2211 of Guaranteed Quality of Service", RFC 2212, September 2212 1997. 2214 [RFC3031] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol 2215 Label Switching Architecture", RFC 3031, January 2001. 2217 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 2218 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2219 Tunnels", RFC 3209, December 2001. 2221 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 2222 (GMPLS) Signaling Functional Description", RFC 3471, 2223 January 2003. 2225 [RFC3473] Berger, L. Ed., "Generalized Multi-Protocol Label 2226 Switching (GMPLS) Signaling Resource ReserVation 2227 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 2228 3473, January 2003. 2230 [RFC3478] Leelanivas, M, et al, "Graceful Restart Mechanism for 2231 Label Distribution Protocol", RFC 3478, February 2003. 2233 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 2234 Engineering (TE) Extensions to OSPF Version 2", RFC 2235 3630, September 2003. 2237 [RFC4124] Le Faucheur, F., Ed. "Protocol Extensions for Support of 2238 Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2239 2005. 2241 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 2242 Support of Generalized Multi-Protocol Label 2243 Switching(GMPLS)", RFC 4202, October 2005. 2245 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 2246 of Generalized Multi-Protocol Label Switching (GMPLS)", 2247 RFC 4203, October 2005. 2249 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 2250 Hierarchy with Generalized Multi-Protocol Label 2251 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, 2252 October 2005. 2254 [RFC4385] Bryant, S., et al, "Pseudowire Emulation Edge-to-Edge 2255 (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, 2256 February 2006. 2258 [RFC4447] Martini, L., Ed., "Pseudowire Setup and Maintenance 2259 Using the Label Distribution Protocol (LDP)", RFC 4447, 2260 April 2006. 2262 [RFC4448] Martini, L., Ed., "Encapsulation Methods for Transport 2263 Ethernet over MPLS Network", RFC 4448, April 2006. 2265 [RFC4842] Malis, A., et al, "Synchronous Optical Network/ 2266 Synchronous Digital Hierarchy (SONET/SDH) Circuit 2267 Emulation over Packet (CEP)", RFC 4842, April 2007. 2269 [RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", 2270 RFC 4863, May 2007. 2272 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE 2273 Extensions in Support of End-to-End Generalized Multi- 2274 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 2275 May 2007. 2277 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., 2278 "GMPLS Segment Recovery", RFC 4873, May 2007. 2280 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 2281 Multiprotocol Label Switching (MPLS) and Generalized 2282 MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 2283 4929, June 2007. 2285 [RFC4974] Papadimitriou, D., Farrel, A., "Generalized MPLS (GMPLS) 2286 RSVP-TE Signaling Extensions in Support of Calls", RFC 2287 4974, August 2007. 2289 [RFC5063] Satyanarayana, A., Ed., "Extensions to GMPLS Resource 2290 Reservation Protocol (RSVP) Graceful Restart", RFC 5063, 2291 September 2007. 2293 [RFC5287] Vainshtein, A. and Y. Stein, "Control Protocol 2294 Extensions for the Setup of Time-Division Multiplexing 2295 (TDM) Pseudowires in MPLS Networks", RFC 5287, August 2296 2008. 2298 [RFC5305] Smit, H. and T. Li, "IS-IS Extensions for Traffic 2299 Engineering", RFC 5305, October 2008. 2301 [RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in 2302 Support of Generalized Multi-Protocol Label Switching 2303 (GMPLS)", RFC 5307, October 2008. 2305 [RFC5316] Chen, M., Zhang, R., and Duan, X., "ISIS Extensions in 2306 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2307 Traffic Engineering", RFC 5316, December 2008. 2309 [RFC5392] Chen, M., Zhang, R., and Duan, X., "OSPF Extensions in 2310 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2311 Traffic Engineering", RFC 5392, January 2009. 2313 [RFC5151] Farrel, A., Ed., "Inter-Domain MPLS and GMPLS Traffic 2314 Engineering -- Resource Reservation Protocol-Traffic 2315 Engineering (RSVP-TE) Extensions", RFC 5151, February 2316 2008. 2318 [RFC5654] Niven-Jenkins, B., et al, "Requirements of an MPLS 2319 Transport Profile", RFC 5654, September 2009. 2321 [RFC5467] Berger, L., et al, "GMPLS Asymmetric Bandwidth 2322 Bidirectional Label Switched Paths (LSPs)", RFC 5467, 2323 March 2009. 2325 [RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC 2326 5586, June 2009. 2328 [RFC5860] Vigoureux, M., Ward, D., Betts, M., "Requirements for 2329 Operations, Administration, and Maintenance (OAM) in 2330 MPLS Transport Networks", RFC 5860, May 2010. 2332 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., Berger, 2333 L., "A Framework for MPLS in Transport Networks", RFC 2334 5921, July 2010. 2336 [RFC5960] Frost, D., Bryant, S., Bocci, M., "MPLS Transport 2337 Profile Data Plane Architecture", RFC 5960, August 2010. 2339 [TP-IDENTIFIERS] Bocci, M., Swallow, G., "MPLS-TP Identifiers", 2340 work in progress, draft-ietf-mpls-tp-identifiers. 2342 [TP-OAM] Busi, I., Ed., Allan, D., Ed., "Operations, 2343 Administration and Maintenance Framework for MPLS-based 2344 Transport Networks", work in progress, 2345 draft-ietf-mpls-tp-oam-framework. 2347 [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label Switching 2348 Transport Profile Survivability Framework", work in 2349 progress, draft-ietf-mpls-tp-survive-fwk. 2351 9.2. Informative References 2353 [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration 2354 Framework and Requirements for GMPLS RSVP-TE", 2355 work in progress, 2356 draft-ietf-ccamp-oam-configuration-fwk. 2358 [CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for 2359 MPLS-TP OAM Configuration", work in progress, 2360 draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext. 2362 [GMPLS-PS] Takacs, A., et al, "GMPLS RSVP-TE Recovery Extension 2363 for data plane initiated reversion and protection timer 2364 signalling", work in progress, 2365 draft-takacs-ccamp-revertive-ps. 2367 [TE-MIB] T Otani, et.al., "Traffic Engineering Database Management 2368 Information Base in support of MPLS-TE/GMPLS", work in 2369 progress, draft-ietf-ccamp-gmpls-ted-mib. 2371 [MS-PW-DYNAMIC] L. Martini, M Bocci, and F Balus "Dynamic 2372 Placement of Multi Segment Pseudo Wires", work in 2373 progress, draft-ietf-pwe3-dynamic-ms-pw. 2375 [ITU.G8080.2006] International Telecommunications Union, 2376 "Architecture for the automatically switched 2377 optical network (ASON)", ITU- T Recommendation 2378 G.8080, June 2006. 2380 [ITU.G8080.2008] International Telecommunications Union, 2381 "Architecture for the automatically switched 2382 optical network (ASON) Amendment 1", ITU-T 2383 Recommendation G.8080 Amendment 1, March 2008. 2385 [NO-PHP] Ali, z., et al, "Non PHP Behavior and out-of-band mapping 2386 for RSVP-TE LSPs", work in progress, 2387 draft-ietf-mpls-rsvp-te-no-php-oob-mapping 2389 [PW-RED] Muley, P., et al, "Pseudowire (PW) Redundancy", work in 2390 progress, draft-ietf-pwe3-redundancy. 2392 [PW-REDB] Muley, P., et al, "Preferential Forwarding Status bit 2393 definition", work in progress, 2394 draft-ietf-pwe3-redundancy-bit. 2396 [PW-OAM] Zhang, F., et al, "LDP Extensions for MPLS-TP PW OAM 2397 configuration", work in progress, 2398 draft-zhang-mpls-tp-pw-oam-config. 2400 [PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint 2401 Pseudo-Wire Encapsulation", work in progress, 2402 draft-raggarwa-pwe3-p2mp-pw-encaps. 2404 [PW-P2MPR] Jounay, F., et al, "Requirements for 2405 Point-to-Multipoint Pseudowire", work in progress, 2406 draft-ietf-pwe3-p2mp-pw-requirements. 2408 [RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label Switching 2409 (MPLS) Support of Differentiated Services", RFC 3270, 2410 May 2002. 2412 [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label 2413 Switching (MPLS) Working Group decision on MPLS 2414 signaling protocols", RFC 3468, February 2003. 2416 [RFC3472] Ashwood-Smith, P., Ed, Berger, L. Ed., "Generalized 2417 Multi-Protocol Label Switching (GMPLS) Signaling 2418 Constraint-based Routed Label Distribution Protocol 2419 (CR-LDP) Extensions", RFC 3472, January 2003. 2421 [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 2422 in Resource ReSerVation Protocol - Traffic Engineering 2423 (RSVP-TE)", RFC 3477, January 2003. 2425 [RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful 2426 Restart Mechanism for Label Distribution Protocol", RFC 2427 3478, February 2003. 2429 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 2430 "Multiprotocol Label Switching (MPLS) Traffic 2431 Engineering (TE) Management Information Base (MIB)", RFC 2432 3812, June 2004. 2434 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 2435 "Multiprotocol Label Switching (MPLS) Label Switching 2436 (LSR) Router Management Information Base (MIB)", RFC 2437 3813, June 2004. 2439 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 2440 (GMPLS) Architecture", RFC 3945, October 2004. 2442 [RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge- 2443 to-Edge (PWE3) Architecture", RFC 3985, March 2005. 2445 [RFC4139] Papadimitriou, D., et al, "Requirements for Generalized 2446 MPLS (GMPLS) Signaling Usage and Extensions for 2447 Automatically Switched Optical Network (ASON)", RFC4139, 2448 July 2005. 2450 [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 2451 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 2453 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, 2454 Y., "Generalized Multi-Protocol Label Switching 2455 (GMPLS) User-Network Interface (UNI) : Resource 2456 ReserVation Protocol-Traffic Engineering (RSVP-TE) 2457 Support for the Overlay Model", RFC 4208, October 2458 2005. 2460 [RFC4258] Brungard, D., et al, "Requirements for Generalized 2461 Multi-Protocol Label Switching (GMPLS) Routing for the 2462 Automatically Switched Optical Network (ASON)", RFC4258, 2463 November 2005. 2465 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 2466 Label Switched (MPLS) Data Plane Failures", RFC 4379, 2467 February 2006. 2469 [RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors, 2470 "Generalized Multiprotocol Label Switching (GMPLS) 2471 Recovery Functional Specification", RFC 4426, March 2472 2006. 2474 [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and 2475 Restoration) Terminology for Generalized Multi-Protocol 2476 Label Switching (GMPLS)", RFC4427, March 2006. 2478 [RFC4553] Vainshtein, A., Ed., and Stein, YJ., Ed.,"Structure- 2479 Agnostic Time Division Multiplexing (TDM) over Packet 2480 (SAToP)", RFC 4553, June 2006. 2482 [RFC4618] Martini, L., Rosen, E., Heron, G., and Malis, A., 2483 "Encapsulation Methods for Transport of PPP/High- Level 2484 Data Link Control (HDLC) over MPLS Networks", RFC 4618, 2485 September 2006. 2487 [RFC4619] Martini, L., Ed., Kawa, C., Ed., and Malis, A., Ed., 2488 "Encapsulation Methods for Transport of Frame Relay over 2489 Multiprotocol Label Switching (MPLS) Networks", 2490 September 2006. 2492 [RFC4655] Farrel, A., Vasseur, J.-P., Ash, J., "A Path Computation 2493 Element (PCE)-Based Architecture", RFC 4655, August 2494 2006. 2496 [RFC4783] Berger, L.,Ed., "GMPLS - Communication of Alarm 2497 Information", RFC 4763, December 2006. 2499 [RFC4802] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol 2500 Label Switching (GMPLS) Traffic Engineering Management 2501 Information Base", RFC 4802, February 2007. 2503 [RFC4803] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol 2504 Label Switching (GMPLS) Label Switching Router (LSR) 2505 Management Information Base", RFC 4803, February 2007. 2507 [RFC4816] Malis, A., Martini, L., Brayley, J., and Walsh, T., 2508 "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous 2509 Transfer Mode (ATM) Transparent Cell Transport Service", 2510 RFC 4816, February 2007. 2512 [RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S., 2513 "Extensions to Resource Reservation Protocol - Traffic 2514 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 2515 Switched Paths (LSPs)", RFC 4875, May 2007. 2517 [RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J., 2518 "Attachment Individual Identifier (AII) Types for 2519 Aggregation", RFC 5003, September 2007. 2521 [RFC5036] Andersson, L., I. Minei and B. Thomas, Editors, "LDP 2522 Specification", RFC 5036, October 2007. 2524 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 2525 Connectivity Verification (VCCV) : A Control Channel for 2526 Pseudowires", RFC 5085, December 2007. 2528 [RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS 2529 Migration", RFC 5145, March 2008. 2531 [RFC5440] Vasseur, JP., Le, JL., "Path Computation Element (PCE) 2532 Communication Protocol (PCEP)", RFC 5440, March 2009. 2534 [RFC5493] Caviglia, D., et al, "Requirements for the Conversion 2535 between Permanent Connections and Switched Connections 2536 in a Generalized Multiprotocol Label Switching (GMPLS) 2537 Network", RFC 5493, April 2009. 2539 [RFC5659] Bocci, M., and Bryant, B., "An Architecture for 2540 Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 2541 5659, October 2009. 2543 [RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions 2544 for ASON Routing", RFC 5787, March 2010. 2546 [RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., 2547 Bardalai, S., "RSVP-TE Signaling Extension for LSP 2548 Handover from the Management Plane to the Control Plane 2549 in a GMPLS-Enabled Transport Network", RFC 5852, April 2550 2010. 2552 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 2553 "Bidirectional Forwarding Detection (BFD) For MPLS 2554 Label Switched Paths (LSPs)", RFC 5884, June 2010. 2556 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional 2557 Forwarding Detection (BFD) for the Pseudowire 2558 Virtual Circuit Connectivity Verification (VCCV)", 2559 RFC 5885, June 2010. 2561 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 2562 Networks", RFC 5920, July 2010. 2564 [RFC5951] Lam, K., Mansfield, S., Gray, E., "Network Management 2565 Requirements for MPLS-based Transport Networks", RFC 2566 5951, September 2010. 2568 [RFC6001] Papadimitriou, D., et al, "Generalized Multi-Protocol 2569 Label Switching (GMPLS) Protocol Extensions for 2570 Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 2571 6001, October 2010. 2573 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., Aissaoui, M., 2574 "Segmented Pseudowire", RFC 6073, January 2011. 2576 [RFC6107] Shiomoto, K., Farrel, A., "Procedures for Dynamically 2577 Signaled Hierarchical Label Switched Paths", RFC 6107, 2578 February 2011. 2580 [TP-MIB] Farrel, A., King, D., Mahalingam, V., Ryoo, J., Koushik, 2581 K., "Multiprotocol Label Switching Transport Profile 2582 (MPLS-TP) MIB-based Management Overview", work in 2583 progress, draft-ietf-mpls-tp-mib-management-overview. 2585 [TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for 2586 Point-to-Multipoint MPLS in Transport Networks", 2587 draft-fbb-mpls-tp-p2mp-framework. 2589 [TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in 2590 progress, draft-weingarten-mpls-tp-ring-protection. 2592 [TP-UNI] Bocci, M., Levrau, L., Frost, D., "MPLS Transport Profile 2593 User-to-Network and Network-to-Network Interfaces", work 2594 in progress, draft-ietf-mpls-tp-uni-nni. 2596 10. Authors' Addresses 2598 Loa Andersson (editor) 2599 Ericsson 2600 Phone: +46 10 717 52 13 2601 Email: loa.andersson@ericsson.com 2603 Lou Berger (editor) 2604 LabN Consulting, L.L.C. 2605 Phone: +1-301-468-9228 2606 Email: lberger@labn.net 2608 Luyuan Fang (editor) 2609 Cisco Systems, Inc. 2610 300 Beaver Brook Road 2611 Boxborough, MA 01719 2612 USA 2613 Email: lufang@cisco.com 2615 Nabil Bitar (editor) 2616 Verizon 2617 117 West Street 2618 Waltham, MA 02451 2619 Email: nabil.n.bitar@verizon.com 2621 Eric Gray (editor) 2622 Ericsson 2623 900 Chelmsford Street 2624 Lowell, MA, 01851 2625 Phone: +1 978 275 7470 2626 Email: Eric.Gray@Ericsson.com 2627 Attila Takacs 2628 Ericsson 2629 1. Laborc u. 2630 Budapest, HUNGARY 1037 2631 Email: attila.takacs@ericsson.com 2633 Martin Vigoureux 2634 Alcatel-Lucent 2635 Email: martin.vigoureux@alcatel-lucent.fr 2637 Elisa Bellagamba 2638 Ericsson 2639 Farogatan, 6 2640 164 40, Kista, Stockholm, SWEDEN 2641 Email: elisa.bellagamba@ericsson.com 2643 Generated on: Thu, Feb 10, 2011 9:01:05 AM