idnits 2.17.1 draft-ietf-mpls-tp-framework-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2010) is 5098 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-05) exists of draft-fang-mpls-tp-security-framework-01 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-mpls-tp-cp-framework-01 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-06 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-tp-rosetta-stone-01 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-survive-fwk-05 == Outdated reference: A later version (-10) exists of draft-ietf-opsawg-mpls-tp-oam-def-04 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-02 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Bocci, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational S. Bryant, Ed. 5 Expires: November 6, 2010 D. Frost, Ed. 6 Cisco Systems 7 L. Levrau 8 Alcatel-Lucent 9 L. Berger 10 LabN 11 May 5, 2010 13 A Framework for MPLS in Transport Networks 14 draft-ietf-mpls-tp-framework-12 16 Abstract 18 This document specifies an architectural framework for the 19 application of Multiprotocol Label Switching (MPLS) to the 20 construction of packet-switched transport networks. It describes a 21 common set of protocol functions - the MPLS Transport Profile 22 (MPLS-TP) - that supports the operational models and capabilities 23 typical of such networks, including signaled or explicitly 24 provisioned bidirectional connection-oriented paths, protection and 25 restoration mechanisms, comprehensive Operations, Administration and 26 Maintenance (OAM) functions, and network operation in the absence of 27 a dynamic control plane or IP forwarding support. Some of these 28 functions are defined in existing MPLS specifications, while others 29 require extensions to existing specifications to meet the 30 requirements of the MPLS-TP. 32 This document defines the subset of the MPLS-TP applicable in general 33 and to point-to-point transport paths. The remaining subset, 34 applicable specifically to point-to-multipoint transport paths, is 35 outside the scope of this document. 37 This document is a product of a joint Internet Engineering Task Force 38 (IETF) / International Telecommunication Union Telecommunication 39 Standardization Sector (ITU-T) effort to include an MPLS Transport 40 Profile within the IETF MPLS and PWE3 architectures to support the 41 capabilities and functionalities of a packet transport network as 42 defined by the ITU-T. 44 This Informational Internet-Draft is aimed at achieving IETF 45 Consensus before publication as an RFC and will be subject to an IETF 46 Last Call. 48 [RFC Editor, please remove this note before publication as an RFC and 49 insert the correct Streams Boilerplate to indicate that the published 50 RFC has IETF Consensus.] 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on November 6, 2010. 69 Copyright Notice 71 Copyright (c) 2010 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 87 1.1. Motivation and Background . . . . . . . . . . . . . . . . 4 88 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 90 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6 91 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 92 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7 93 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7 94 1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8 95 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 9 96 1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 9 97 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10 98 1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10 99 1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10 100 1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10 101 1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11 102 1.3.13. Additional Definitions and Terminology . . . . . . . . 11 103 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11 104 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 11 105 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 11 106 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 12 107 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 13 108 3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14 109 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15 110 3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16 111 3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16 112 3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17 113 3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18 114 3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25 115 3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28 116 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33 117 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33 118 3.7. Operations, Administration and Maintenance (OAM) . . . . . 35 119 3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 37 120 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 38 121 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39 122 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 39 123 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 39 124 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40 125 3.10. Interdomain Connectivity . . . . . . . . . . . . . . . . . 42 126 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 42 127 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 43 128 3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 44 129 3.14. Network Management . . . . . . . . . . . . . . . . . . . . 46 130 4. Security Considerations . . . . . . . . . . . . . . . . . . . 47 131 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 132 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 133 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 134 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50 135 7.2. Informative References . . . . . . . . . . . . . . . . . . 53 137 1. Introduction 139 1.1. Motivation and Background 141 This document describes an architectural framework for the 142 application of MPLS to the construction of packet-switched transport 143 networks. It specifies the common set of protocol functions that 144 meet the requirements in [RFC5654], and that together constitute the 145 MPLS Transport Profile (MPLS-TP) for point-to-point transport paths. 146 The remaining MPLS-TP functions, applicable specifically to point-to- 147 multipoint transport paths, are outside the scope of this document. 149 Historically the optical transport infrastructure - Synchronous 150 Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical 151 Transport Network (OTN) - has provided carriers with a high benchmark 152 for reliability and operational simplicity. To achieve this, 153 transport technologies have been designed with specific 154 characteristics: 156 o Strictly connection-oriented connectivity, which may be long-lived 157 and may be provisioned manually, for example by network management 158 systems or direct node configuration using a command line 159 interface. 161 o A high level of availability. 163 o Quality of service. 165 o Extensive Operations, Administration and Maintenance (OAM) 166 capabilities. 168 Carriers wish to evolve such transport networks to take advantage of 169 the flexibility and cost benefits of packet switching technology and 170 to support packet based services more efficiently. While MPLS is a 171 maturing packet technology that already plays an important role in 172 transport networks and services, not all MPLS capabilities and 173 mechanisms are needed in, or consistent with, the transport network 174 operational model. There are also transport technology 175 characteristics that are not currently reflected in MPLS. 177 There are thus two objectives for MPLS-TP: 179 1. To enable MPLS to be deployed in a transport network and operated 180 in a similar manner to existing transport technologies. 182 2. To enable MPLS to support packet transport services with a 183 similar degree of predictability to that found in existing 184 transport networks. 186 In order to achieve these objectives, there is a need to define a 187 common set of MPLS protocol functions - an MPLS Transport Profile - 188 for the use of MPLS in transport networks and applications. Some of 189 the necessary functions are provided by existing MPLS specifications, 190 while others require additions to the MPLS tool-set. Such additions 191 should, wherever possible, be applicable to MPLS networks in general 192 as well as those that conform strictly to the transport network 193 model. 195 This document is a product of a joint Internet Engineering Task Force 196 (IETF) / International Telecommunication Union Telecommunication 197 Standardization Sector (ITU-T) effort to include an MPLS Transport 198 Profile within the IETF MPLS and PWE3 architectures to support the 199 capabilities and functionalities of a packet transport network as 200 defined by the ITU-T. 202 1.2. Scope 204 This document describes an architectural framework for the 205 application of MPLS to the construction of packet-switched transport 206 networks. It specifies the common set of protocol functions that 207 meet the requirements in [RFC5654], and that together constitute the 208 MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport 209 paths. The remaining MPLS-TP functions, applicable specifically to 210 point-to-multipoint transport paths, are outside the scope of this 211 document. 213 1.3. Terminology 215 Term Definition 216 ---------- ---------------------------------------------------------- 217 AC Attachment Circuit 218 ACH Associated Channel Header 219 Adaptation The mapping of client information into a format suitable 220 for transport by the server layer 221 APS Automatic Protection Switching 222 ATM Asynchronous Transfer Mode 223 BFD Bidirectional Forwarding Detection 224 CE Customer Edge 225 CL-PS Connectionless - Packet Switched 226 CM Configuration Management 227 CO-CS Connection Oriented - Circuit Switched 228 CO-PS Connection Oriented - Packet Switched 229 DCN Data Communication Network 230 EMF Equipment Management Function 231 FCAPS Fault, Configuration, Accounting, Performance and Security 232 FM Fault Management 233 G-ACh Generic Associated Channel 234 GAL G-ACh Label 235 LER Label Edge Router 236 LSP Label Switched Path 237 LSR Label Switching Router 238 MAC Media Access Control 239 MCC Management Communication Channel 240 ME Maintenance Entity 241 MEG Maintenance Entity Group 242 MEP Maintenance Entity Group End Point 243 MIP Maintenance Entity Group Intermediate Point 244 MPLS Multiprotocol Label Switching 245 MPLS-TP MPLS Transport Profile 246 MPLS-TP P MPLS-TP Provider LSR 247 MPLS-TP PE MPLS-TP Provider Edge LSR 248 MS-PW Multi-Segment Pseudowire 249 Native The traffic belonging to the client of the MPLS-TP network 250 Service 251 OAM Operations, Administration and Maintenance (see 252 [I-D.ietf-opsawg-mpls-tp-oam-def]) 253 OSI Open Systems Interconnection 254 OTN Optical Transport Network 255 PDU Protocol Data Unit 256 PM Performance Monitoring 257 PSN Packet Switching Network 258 PW Pseudowire 259 SCC Signaling Communication Channel 260 SDH Synchronous Digital Hierarchy 261 S-PE PW Switching Provider Edge 262 SPME Sub-Path Maintenance Element 263 T-PE PW Terminating Provider Edge 264 VCCV Virtual Circuit Connectivity Verification 266 1.3.1. Transport Network 268 A Transport Network provides transparent transmission of client user 269 plane traffic between attached client devices by establishing and 270 maintaining point-to-point or point-to-multipoint connections between 271 such devices. The architecture of networks supporting point-to- 272 multipoint connections is outside the scope of this document. A 273 Transport Network is independent of any higher-layer network that may 274 exist between clients, except to the extent required to supply this 275 transmission service. In addition to client traffic, a Transport 276 Network may carry traffic to facilitate its own operation, such as 277 that required to support connection control, network management, and 278 Operations, Administration and Maintenance (OAM) functions. 280 See also the definition of Packet Transport Service in Section 3.1. 282 1.3.2. MPLS Transport Profile 284 The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions 285 that meet the requirements in [RFC5654]. Note that MPLS is defined 286 to include any present and future MPLS capability specified by the 287 IETF, including those capabilities specifically added to support 288 transport network requirements [RFC5654]. 290 1.3.3. MPLS-TP Section 292 MPLS-TP Sections are defined in [I-D.ietf-mpls-tp-data-plane]. See 293 also the definition of "section layer network" in Section 1.2.2 of 294 [RFC5654]. 296 1.3.4. MPLS-TP Label Switched Path 298 An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a 299 subset of the capabilities of an MPLS LSP in order to meet the 300 requirements of an MPLS transport network as set out in [RFC5654]. 301 The characteristics of an MPLS-TP LSP are primarily that it: 303 1. Uses a subset of the MPLS OAM tools defined as described in 304 [I-D.ietf-mpls-tp-oam-framework]. 306 2. Supports 1+1, 1:1, and 1:N protection functions. 308 3. Is traffic engineered. 310 4. May be established and maintained via the management plane, or 311 using GMPLS protocols when a control plane is used. 313 5. Is either point-to-point or point-to-multipoint. multipoint-to- 314 point and multipoint-to-multipoint LSPs are not supported. 316 6. It is either unidirectional, associated bidirectional, or co- 317 routed bidirectional (i.e. the forward and reverse components of 318 a bidirectional LSP follow the same path and the intermediate 319 nodes are aware of their association). These are further defined 320 in [I-D.ietf-mpls-tp-data-plane]. 322 Note that an MPLS LSP is defined to include any present and future 323 MPLS capability, including those specifically added to support the 324 transport network requirements. 326 See [I-D.ietf-mpls-tp-data-plane] for further details on the types 327 and data-plane properties of MPLS-TP LSPs. 329 The lowest server layer provided by MPLS-TP is an MPLS-TP LSP. The 330 client layers of an MPLS-TP LSP may be network layer protocols, MPLS 331 LSPs, or PWs. The relationship of an MPLS-TP LSP to its client 332 layers is described in detail in Section 3.4. 334 1.3.5. MPLS-TP Label Switching Router 336 An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider 337 Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP, 338 as defined below. The terms MPLS-TP PE router and MPLS-TP P router 339 describe logical functions; a specific node may undertake only one of 340 these roles on a given LSP. 342 Note that the use of the term "router" in this context is historic 343 and neither requires nor precludes the ability to perform IP 344 forwarding. 346 1.3.5.1. Label Edge Router 348 An MPLS-TP Label Edge Router (LER) is an LSR that exists at the 349 endpoints of an LSP and therefore pushes or pops the LSP label, i.e. 350 does not perform a label swap on the particular LSP under 351 consideration. 353 1.3.5.2. MPLS-TP Provider Edge Router 355 An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts 356 client traffic and encapsulates it to be transported over an MPLS-TP 357 LSP. Encapsulation may be as simple as pushing a label, or it may 358 require the use of a pseudowire. An MPLS-TP PE exists at the 359 interface between a pair of layer networks. For an MS-PW, an MPLS-TP 360 PE may be either an S-PE or a T-PE, as defined in [RFC5659] (see 361 below). A PE that pushes or pops an LSP label is an LER for that 362 LSP. 364 The term Provider Edge refers to the node's role within a provider's 365 network. A provider edge router resides at the edge of a given 366 MPLS-TP network domain, in which case it has links to another MPLS-TP 367 network domain or to a CE, except for the case of a pseudowire 368 switching provider edge (S-PE) router, which is not restricted to the 369 edge of an MPLS-TP network domain. 371 1.3.5.3. MPLS-TP Provider Router 373 An MPLS-TP Provider router is an MPLS-TP LSR that does not provide 374 MPLS-TP PE functionality for a given LSP. An MPLS-TP P router 375 switches LSPs which carry client traffic, but does not adapt client 376 traffic and encapsulate it to be carried over an MPLS-TP LSP. The 377 term Provider Router refers to the node's role within a provider's 378 network. A provider router does not have links to other MPLS-TP 379 network domains. 381 1.3.5.4. Pseudowire Switching Provider Edge Router (S-PE) 383 RFC5659[RFC5659] defines an S-PE as: 385 "A PE capable of switching the control and data planes of the 386 preceding and succeeding PW segments in an MS-PW. The S-PE 387 terminates the PSN tunnels of the preceding and succeeding 388 segments of the MS-PW. It therefore includes a PW switching point 389 for an MS-PW. A PW switching point is never the S-PE and the T-PE 390 for the same MS-PW. A PW switching point runs necessary protocols 391 to set up and manage PW segments with other PW switching points 392 and terminating PEs. An S-PE can exist anywhere a PW must be 393 processed or policy applied. It is therefore not limited to the 394 edge of a provider network. 396 "Note that it was originally anticipated that S-PEs would only be 397 deployed at the edge of a provider network where they would be 398 used to switch the PWs of different service providers. However, 399 as the design of MS-PW progressed, other applications for MS-PW 400 were recognized. By this time S-PE had become the accepted term 401 for the equipment, even though they were no longer universally 402 deployed at the provider edge." 404 1.3.5.5. Pseudowire Terminating Provider Edge Router (T-PE) 406 RFC5659[RFC5659] defines a T-PE as: 408 "A PE where the customer- facing attachment circuits (ACs) are 409 bound to a PW forwarder. A terminating PE is present in the first 410 and last segments of an MS-PW. This incorporates the 411 functionality of a PE as defined in RFC 3985." 413 1.3.6. Customer Edge (CE) 415 A Customer Edge (CE) is the client function sourcing or sinking 416 native service traffic to or from the MPLS-TP network. CEs on either 417 side of the MPLS-TP network are peers and view the MPLS-TP network as 418 a single link. 420 1.3.7. Transport LSP 422 A Transport LSP is an LSP between a pair of PEs that may transit zero 423 or more MPLS-TP provider routers. When carrying PWs, the transport 424 LSP is equivalent to the PSN tunnel LSP in [RFC3985] terminology. 426 1.3.8. Service LSP 428 A service LSP is an LSP that carries a single client service. 430 1.3.9. Layer Network 432 A layer network is defined in [G.805] and described in [RFC5654]. A 433 layer network provides for the transfer of client information and 434 independent operation of the client OAM. A layer network may be 435 described in a service context as follows: one layer network may 436 provide a (transport) service to a higher client layer network and 437 may, in turn, be a client to a lower-layer network. A layer network 438 is a logical construction somewhat independent of arrangement or 439 composition of physical network elements. A particular physical 440 network element may topologically belong to more than one layer 441 network, depending on the actions it takes on the encapsulation 442 associated with the logical layers (e.g., the label stack), and thus 443 could be modeled as multiple logical elements. A layer network may 444 consist of one or more sublayers. 446 1.3.10. Network Layer 448 This document uses the term Network Layer in the same sense as it is 449 used in [RFC3031] and [RFC3032]. Network layer protocols are 450 synymous with those beloging to layer 3 of the Open System 451 Interconnect (OSI) network model [X.200]. 453 1.3.11. Service Interface 455 The packet transport service provided by MPLS-TP is provided at a 456 service interface. Two types of service interfaces are defined: 458 o User-Network Interface (UNI) (see Section 3.4.3.1). 460 o Network-Network Interface (NNI) (see Section 3.4.3.2). 462 A UNI service interface may be a layer 2 interface that carries only 463 network layer clients. MPLS-TP LSPs are both necessary and 464 sufficient to support this service interface as described in section 465 3.4.3. Alternatively, it may be a layer 2 interface that carries 466 both network layer and non-network layer clients. To support this 467 service interface, a PW is required to adapt the client traffic 468 received over the service interface. This PW in turn is a client of 469 the MPLS-TP server layer. This is described in section 3.4.2. 471 An NNI service interface may be to an MPLS LSP or a PW. To support 472 this case an MPLS-TP PE participates in the service interface 473 signaling. 475 1.3.12. Native Service 477 The native service is the client layer network service that is 478 transported by the MPLS-TP network, whether a pseudowire or an LSP is 479 used for the adaptation (see Section 3.4). 481 1.3.13. Additional Definitions and Terminology 483 Detailed definitions and additional terminology may be found in 484 [RFC5654] and [I-D.ietf-mpls-tp-rosetta-stone]. 486 2. MPLS Transport Profile Requirements 488 The requirements for MPLS-TP are specified in [RFC5654], 489 [I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req]. 490 This section provides a brief reminder to guide the reader. It is 491 not normative or intended as a substitute for these documents. 493 MPLS-TP must not modify the MPLS forwarding architecture and must be 494 based on existing pseudowire and LSP constructs. 496 Point-to-point LSPs may be unidirectional or bidirectional, and it 497 must be possible to construct congruent bidirectional LSPs. 499 MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it 500 must be possible to detect if a merged LSP has been created. 502 It must be possible to forward packets solely based on switching the 503 MPLS or PW label. It must also be possible to establish and maintain 504 LSPs and/or pseudowires both in the absence or presence of a dynamic 505 control plane. When static provisioning is used, there must be no 506 dependency on dynamic routing or signaling. 508 OAM, protection and forwarding of data packets must be able to 509 operate without IP forwarding support. 511 It must be possible to monitor LSPs and pseudowires through the use 512 of OAM in the absence of control plane or routing functions. In this 513 case information gained from the OAM functions is used to initiate 514 path recovery actions at either the PW or LSP layers. 516 3. MPLS Transport Profile Overview 518 3.1. Packet Transport Services 520 One objective of MPLS-TP is to enable MPLS networks to provide packet 521 transport services with a similar degree of predictability to that 522 found in existing transport networks. Such packet transport services 523 exhibit a number of characteristics, defined in [RFC5654]: 525 o In an environment where an MPLS-TP layer network is supporting a 526 client layer network, and the MPLS-TP layer network is supported 527 by a server layer network then operation of the MPLS-TP layer 528 network must be possible without any dependencies on either the 529 server or client layer network. 531 o The service provided by the MPLS-TP network to a given client will 532 not to fall below the agreed level as a result of the traffic 533 loading of other clients. 535 o The control and management planes of any client network layer that 536 uses the service is isolated from the control and management 537 planes of the MPLS-TP layer network, where the client network 538 layer is considered to be the native service of the MPLS-TP 539 network. 541 o Where a client network makes use of an MPLS-TP server that 542 provides a packet transport service, the level of co-ordination 543 required between the client and server layer networks is minimal 544 (preferably no co-ordination will be required). 546 o The complete set of packets generated by a client MPLS(-TP) layer 547 network using the packet transport service, which may contain 548 packets that are not MPLS packets (e.g. IP or CLNS packets used 549 by the control/management plane of the client MPLS(-TP) layer 550 network), are transported by the MPLS-TP server layer network. 552 o The packet transport service enables the MPLS-TP layer network 553 addressing and other information (e.g. topology) to be hidden from 554 any client layer networks using that service, and vice-versa. 556 These characteristics imply that a packet transport service does not 557 support a connectionless packet-switched forwarding mode. However, 558 this does not preclude it carrying client traffic associated with a 559 connectionless service. 561 3.2. Scope of the MPLS Transport Profile 563 Figure 1 illustrates the scope of MPLS-TP. MPLS-TP solutions are 564 primarily intended for packet transport applications. MPLS-TP is a 565 strict subset of MPLS, and comprises only those functions that are 566 necessary to meet the requirements of [RFC5654]. This includes MPLS 567 functions that were defined prior to [RFC5654] but that meet the 568 requirements of [RFC5654], together with additional functions defined 569 to meet those requirements. Some MPLS functions defined before 570 [RFC5654] such as Equal Cost Multi-Path, LDP signaling when used in 571 such a way that it creates multipoint-to-point LSPs, and IP 572 forwarding in the data plane are explicitly excluded from MPLS-TP by 573 that requirements specification. 575 Note that MPLS as a whole will continue to evolve to include 576 additional functions that do not conform to the MPLS Transport 577 Profile or its requirements, and thus fall outside the scope of 578 MPLS-TP. 580 |<============================== MPLS ==============================>| 581 { Post-RFC5654 } 582 { non-Transport } 583 { Functions } 584 |<========== Pre-RFC5654 MPLS ===========>| 585 { ECMP } 586 { LDP/non-TE LSPs } 587 { IP fwd } 589 |<======== MPLS-TP ============>| 590 { Additional } 591 { Transport } 592 { Functions } 594 Figure 1: Scope of MPLS-TP 596 MPLS-TP can be used to construct packet networks and is therefore 597 applicable in any packet network context. A subset of MPLS-TP is 598 also applicable to ITU-T defined packet transport networks, where the 599 transport network operational model is deemed attractive. 601 3.3. Architecture 603 MPLS-TP comprises the following architectural elements: 605 o A standard MPLS data plane [RFC3031] as profiled in 606 [I-D.ietf-mpls-tp-data-plane]. 608 o Sections, LSPs and PWs that provide a packet transport service for 609 a client network. 611 o Proactive and on-demand Operations, Administration and Maintenance 612 (OAM) functions to monitor and diagnose the MPLS-TP network, as 613 outlined in [I-D.ietf-mpls-tp-oam-framework]. 615 o Control planes for LSPs and PWs, as well as support for static 616 provisioning and configuration, as outlined in 618 [I-D.ietf-ccamp-mpls-tp-cp-framework]. 620 o Path protection mechanisms to ensure that the packet transport 621 service survives anticipated failures and degradations of the 622 MPLS-TP network, as outlined in [I-D.ietf-mpls-tp-survive-fwk]. 624 o Control plane based restoration mechanisms, as outlined in 625 [I-D.ietf-mpls-tp-survive-fwk]. 627 o Network management functions, as outlined in 628 [I-D.ietf-mpls-tp-nm-framework]. 630 The MPLS-TP architecture for LSPs and PWs includes the following two 631 sets of functions: 633 o MPLS-TP native service adaptation 635 o MPLS-TP forwarding 637 The adaptation functions interface the native service (i.e. the 638 client layer network service) to MPLS-TP. This includes the case 639 where the native service is an MPLS-TP LSP. 641 The forwarding functions comprise the mechanisms required for 642 forwarding the encapsulated native service traffic over an MPLS-TP 643 server layer network, for example PW and LSP labels. 645 3.3.1. MPLS-TP Native Service Adaptation Functions 647 The MPLS-TP native service adaptation functions interface the client 648 layer network service to MPLS-TP. For pseudowires, these adaptation 649 functions are the payload encapsulation described in Section 4.4 of 650 [RFC3985] and Section 6 of [RFC5659]. For network layer client 651 services, the adaptation function uses the MPLS encapsulation format 652 as defined in [RFC3032]. 654 The purpose of this encapsulation is to abstract the client layer 655 network data plane from the MPLS-TP data plane, thus contributing to 656 the independent operation of the MPLS-TP network. 658 MPLS-TP is itself a client of an underlying server layer. MPLS-TP is 659 thus also bounded by a set of adaptation functions to this server 660 layer network, which may itself be MPLS-TP. These adaptation 661 functions provide encapsulation of the MPLS-TP frames and for the 662 transparent transport of those frames over the server layer network. 663 The MPLS-TP client inherits its Quality of Service (QoS) from the 664 MPLS-TP network, which in turn inherits its QoS from the server 665 layer. The server layer therefore needs to provide the necessary QoS 666 to ensure that the MPLS-TP client QoS commitments can be satisfied. 668 3.3.2. MPLS-TP Forwarding Functions 670 The forwarding functions comprise the mechanisms required for 671 forwarding the encapsulated native service traffic over an MPLS-TP 672 server layer network, for example PW and LSP labels. 674 MPLS-TP LSPs use the MPLS label switching operations and TTL 675 processing procedures defined in [RFC3031], [RFC3032] and [RFC3443], 676 as profiled in [I-D.ietf-mpls-tp-data-plane]. These operations are 677 highly optimised for performance and are not modified by the MPLS-TP 678 profile. 680 In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW 681 forwarding operations defined in [RFC3985] and [RFC5659]. 683 Per-platform label space is used for PWs. Either per-platform, per- 684 interface or other context-specific label space [RFC5331] may be used 685 for LSPs. 687 MPLS-TP forwarding is based on the label that identifies the 688 transport path (LSP or PW). The label value specifies the processing 689 operation to be performed by the next hop at that level of 690 encapsulation. A swap of this label is an atomic operation in which 691 the contents of the packet after the swapped label are opaque to the 692 forwarder. The only event that interrupts a swap operation is TTL 693 expiry. This is a fundamental architectural construct of MPLS to be 694 taken into account when designing protocol extensions (such as those 695 for OAM) that require packets to be sent to an intermediate LSR. 697 Further processing to determine the context of a packet occurs when a 698 swap operation is interrupted in this manner, or a pop operation 699 exposes a specific reserved label at the top of the stack, or the 700 packet is received with the GAL (Section 3.6) at the top of stack. 701 Otherwise the packet is forwarded according to the procedures in 702 [RFC3032]. 704 MPLS-TP supports Quality of Service capabilities via the MPLS 705 Differentiated Services (DiffServ) architecture [RFC3270]. Both 706 E-LSP and L-LSP MPLS DiffServ modes are supported. 708 Further details of MPLS-TP forwarding can be found in 709 [I-D.ietf-mpls-tp-data-plane]. 711 3.4. MPLS-TP Native Service Adaptation 713 This document describes the architecture for two native service 714 adaptation mechanisms, which provide encapsulation and demultiplexing 715 for native service traffic traversing an MPLS-TP network: 717 o A PW 719 o An MPLS LSP 721 MPLS-TP uses IETF-defined pseudowires to emulate certain services, 722 for example Ethernet, Frame Relay, or PPP/HDLC. A list of PW types 723 is maintained by IANA in the the "MPLS Pseudowire Type" registry. 724 When the native service adaptation is via a PW, the mechanisms 725 described in Section 3.4.4 are used. 727 An MPLS LSP can also provide the adaptation, in which case any native 728 service traffic type supported by [RFC3031] and [RFC3032] is allowed. 729 Examples of such traffic types include IP, and MPLS-labeled packets. 730 Note that the latter case includes TE-LSPs [RFC3209] and LSP based 731 applications such as PWs, Layer 2 VPNs [RFC4664], and Layer 3 VPNs 732 [RFC4364]. When the native service adaptation is via an MPLS label, 733 the mechanisms described in Section 3.4.5 are used. 735 3.4.1. MPLS-TP Client/Server Layer Relationship 737 The relationship between the client layer network and the MPLS-TP 738 server layer network is defined by the MPLS-TP network boundary and 739 the label context. It is not explicitly indicated in the packet. In 740 terms of the MPLS label stack, when the native service traffic type 741 is itself MPLS-labeled, then the S bits of all the labels in the 742 MPLS-TP label stack carrying that client traffic are zero; otherwise 743 the bottom label of the MPLS-TP label stack has the S-bit set to 1. 744 In other words, there can be only one S-bit set in a label stack. 746 The data plane behaviour of MPLS-TP is the same as the best current 747 practice for MPLS. This includes the setting of the S-bit. In each 748 case, the S-bit is set to indicate the bottom (i.e. inner-most) label 749 in the label stack that is contiguous between the MPLS-TP LSP and its 750 payload, and only one LSE contains the S (Bottom of Stack) bit set to 751 1. Note that this best current practice differs slightly from 752 [RFC3032] which uses the S-bit to identify when MPLS label processing 753 stops and network layer processing starts. 755 The relationship of MPLS-TP to its clients is illustrated in 756 Figure 2. Note that the label stacks shown in the figure are divided 757 between those inside the MPLS-TP Network and those within the client 758 network when the client network is MPLS(-TP). They illustrate the 759 smallest number of labels possible. These label stacks could also 760 include more labels. 762 PW-Based MPLS Labelled IP 763 Services Services Transport 764 |------------| |-----------------------------| |------------| 766 Emulated PW over LSP IP over LSP IP 767 Service 768 +------------+ 769 | PW Payload | 770 +------------+ +------------+ (CLIENTS) 771 |PW Lbl(S=1) | | IP | 772 +------------+ +------------+ +------------+ +------------+ 773 | PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP | 774 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 775 |PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)| 776 +------------+ +------------+ +------------+ +------------+ 777 |LSP Lbl(S=0)| . . . 778 +------------+ . . . (MPLS-TP) 779 . . . . 780 . 781 . 783 ~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary 785 Figure 2: MPLS-TP - Client Relationship 787 3.4.2. MPLS-TP Transport Layers 789 An MPLS-TP network consists logically of two layers: the Transport 790 Service layer and the Transport Path layer. 792 The Transport Service layer provides the interface between Customer 793 Edge (CE) nodes and the MPLS-TP network. Each packet transmitted by 794 a CE node for transport over the MPLS-TP network is associated at the 795 receiving MPLS-TP Provider Edge (PE) node with a single logical 796 point-to-point connection at the Transport Service layer between this 797 (ingress) PE and the corresponding (egress) PE to which the peer CE 798 is attached. Such a connection is called an MPLS-TP Transport 799 Service Instance, and the set of client packets belonging to the 800 native service associated with such an instance on a particular CE-PE 801 link is called a client flow. 803 The Transport Path layer provides aggregation of Transport Service 804 Instances over MPLS-TP transport paths (LSPs), as well as aggregation 805 of transport paths (via LSP hierarchy). 807 Awareness of the Transport Service layer need exist only at PE nodes. 808 MPLS-TP Provider (P) nodes need have no awareness of this layer. 809 Both PE and P nodes participate in the Transport Path layer. A PE 810 terminates (i.e., is an LER with respect to) the transport paths it 811 supports, and is responsible for multiplexing and demultiplexing of 812 Transport Service Instance traffic over such transport paths. 814 3.4.3. MPLS-TP Transport Service Interfaces 816 An MPLS-TP PE node can provide two types of interface to the 817 Transport Service layer. The MPLS-TP User-Network Interface (UNI) 818 provides the interface between a CE and the MPLS-TP network. The 819 MPLS-TP Network-Network Interface (NNI) provides the interface 820 between two MPLS-TP PEs in different administrative domains. 822 When MPLS-TP is used to provide a transport service for e.g. IP 823 services that are a part of a Layer 3 VPN, then packets are 824 transported in the same manner as specified in [RFC4364]. 826 3.4.3.1. User-Network Interface 828 The MPLS-TP User-Network interface (UNI) is illustrated in Figure 3. 829 The UNI for a particular client flow may or may not involve signaling 830 between the CE and PE, and if signaling is used, it may or may not 831 traverse the same attachment circuit that supports the client flow. 833 : User-Network Interface : MPLS-TP 834 :<-------------------------------------->: Network <-----> 835 : : 836 -:------------- --------------:------------------ 837 : | | : Transport | 838 : | | Transport : Path | 839 : | | Service : Mux/Demux | 840 : | | Control : -- | 841 : | | Plane : | | Transport| 842 : ---------- | Signaling | ---------- : | | Path | 843 :|Signaling |_|___________|_|Signaling | : | | ---------> 844 :|Controller| | | |Controller| : | | | 845 : ---------- | | ---------- : | | ---------> 846 : :......|...........|......: : | | | 847 : | Control | : | | Transport| 848 : | Channel | : | | Path | 849 : | | : | | ---------> 850 : | | : | | -+----------->TSI 851 : | | Transport : | | | ---------> 852 : | Client | Service : | | | | 853 : | Traffic | Data Plane : | | | | 854 : ---------- | Flows | -------------- | | |Transport| 855 :|Signaling |-|-----------|-|Client/Service|-| |- Path | 856 :|Controller|=|===========|=| Traffic | | | ---------> 857 : ---------- | | | Processing |=| |===+===========>TSI 858 : | | | -------------- | | ---------> 859 : |______|___________|______| : | | | 860 : | Data Link | : | | | 861 : | | : -- | 862 : | | : Transport | 863 : | | : Service | 864 : | | : Data Plane| 865 --------------- --------------------------------- 866 Customer Edge Node MPLS-TP Provider Edge Node 868 TSI = Transport Service Instance 870 Figure 3: MPLS-TP PE Containing a UNI 872 --------------From UNI-------> : 873 -------------------------------------------:------------------ 874 | | Client Traffic Unit : | 875 | Link-Layer-Specific | Link Decapsulation : Service Instance | 876 | Processing | & : Transport | 877 | | Service Instance : Encapsulation | 878 | | Identification : | 879 -------------------------------------------:------------------ 880 : 881 : 882 -------------------------------------------:------------------ 883 | | : Service Instance | 884 | | : Transport | 885 | Link-Layer-Specific | Client Traffic Unit : Decapsulation | 886 | Processing | Link Encapsulation : & | 887 | | : Service Instance | 888 | | : Identification | 889 -------------------------------------------:------------------ 890 <-------------To UNI --------- : 892 Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages 894 Figure 4 shows the logical processing steps involved in a PE both for 895 traffic flowing from the CE to the MPLS-TP network (left to right), 896 and from the network to the CE (right to left). 898 In the first case, when a packet from a client flow is received by 899 the PE from the CE over the data-link, the following steps occur: 901 1. Link-layer specific preprocessing, if any, is performed. An 902 example of such preprocessing is the PREP function illustrated in 903 Figure 3 of [RFC3985]. Such preprocessing is outside the scope 904 of MPLS-TP. 906 2. The packet is extracted from the data-link frame if necessary, 907 and associated with a Transport Service Instance. At this point, 908 UNI processing has completed. 910 3. A transport service encapsulation is associated with the packet, 911 if necessary, for transport over the MPLS-TP network. 913 4. The packet is mapped to a transport path based on its associated 914 Transport Service Instance, the transport path encapsulation is 915 added, if necessary, and the packet is transmitted over the 916 transport path. 918 In the second case, when a packet associated with a Transport Service 919 Instance arrives over a transport path, the following steps occur: 921 1. The transport path encapsulation is disposed of. 923 2. The transport service encapsulation is disposed of and the 924 Transport Service Instance and client flow identified. 926 3. At this point, UNI processing begins. A data-link encapsulation 927 is associated with the packet for delivery to the CE based on the 928 client flow. 930 4. Link-layer-specific postprocessing, if any, is performed. Such 931 postprocessing is outside the scope of MPLS-TP. 933 3.4.3.2. Network-Network Interface 935 The MPLS-TP NNI is illustrated in Figure 5. The NNI for a particular 936 transport service instance may or may not involve signaling between 937 the two PEs, and if signaling is used, it may or may not traverse the 938 same data-link that supports the service instance. 940 : Network-Network Interface : 941 :<--------------------------------->: 942 : : 943 ------------:------------- -------------:------------ 944 | Transport : | | : Transport | 945 | Path : Transport | | Transport : Path | 946 | Mux/Demux : Service | | Service : Mux/Demux | 947 | -- : Control | | Control : -- | 948 | | | : Plane |Sig- | Plane : | | | 949 |TP | | : ---------- | naling| ---------- : | | TP| 950 <--- | | :|Signaling |_|_______|_|Signaling |: | | ---> 951 TSI<-+- | | :|Controller| | | |Controller|: | | | 952 <--- | | | : ---------- | | ---------- : | | ---> 953 | | | | : :......|.......|......: : | | | 954 | | | | : |Control| : | | | 955 |TP | | | : |Channel| : | | TP| 956 <--- | | | : | | : | | ---> 957 | | | | : | | : | | -+->TSI 958 <--- | | | : Transport | | Transport : | | | ---> 959 | | | | : Service |Service| Service : | | | | 960 | | | | : Data Plane |Traffic| Data Plane : | | | | 961 | | | | ------------- | Flows | ------------- | | | | 962 |TP -| |-| Service |-|-------|-| Service |-| |- TP| 963 <--- | | | Traffic | | | | Traffic | | | ---> 964 TSI<=+===| |=| Processing |=|=======|=| Processing |=| |===+=>TSI 965 <--- | | ------------- | | ------------- | | ---> 966 | | | : |______|_______|______| : | | | 967 | | | : | Data | : | | | 968 | -- : | Link | : -- | 969 | : | | : | 970 -------------------------- -------------------------- 971 MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node 973 TP = Transport Path 974 TSI = Transport Service Instance 976 Figure 5: MPLS-TP PE Containing an NNI 977 : 978 --------------From NNI-------> : 979 --------------------------------------------:------------------ 980 | | Service Traffic Unit : | 981 | Link-Layer-Specific | Link Decapsulation : Service Instance | 982 | Processing | & : Encapsulation | 983 | | Service Instance : Normalisation | 984 | | Identification : | 985 --------------------------------------------:------------------ 986 : 987 : 988 --------------------------------------------:------------------ 989 | | : Service Instance | 990 | | : Identification | 991 | Link-Layer-Specific | Service Traffic Unit : & | 992 | Processing | Link Encapsulation : Service Instance | 993 | | : Encapsulation | 994 | | : Normalisation | 995 --------------------------------------------:------------------ 996 <-------------To NNI --------- : 998 Figure 6: MPLS-TP NNI Service Traffic Processing Stages 1000 Figure 6 shows the logical processing steps involved in a PE for 1001 traffic flowing both from the peer PE (left to right) and to the peer 1002 PE (right to left). 1004 In the first case, when a packet from a transport service instance is 1005 received by the PE from the peer PE over the data-link, the following 1006 steps occur: 1008 1. Link-layer specific preprocessing, if any, is performed. Such 1009 preprocessing is outside the scope of MPLS-TP. 1011 2. The packet is extracted from the data-link frame if necessary, 1012 and associated with a Transport Service Instance. At this point, 1013 NNI processing has completed. 1015 3. The transport service encapsulation of the packet is normalised 1016 for transport over the MPLS-TP network. This step allows a 1017 different transport service encapsulation to be used over the NNI 1018 than that used in the internal MPLS-TP network. An example of 1019 such normalisation is a swap of a label identifying the Transport 1020 Service Instance. 1022 4. The packet is mapped to a transport path based on its associated 1023 Transport Service Instance, the transport path encapsulation is 1024 added, if necessary, and the packet is transmitted over the 1025 transport path. 1027 In the second case, when a packet associated with a Transport Service 1028 Instance arrives over a transport path, the following steps occur: 1030 1. The transport path encapsulation is disposed of. 1032 2. The Transport Service Instance is identified from the transport 1033 service encapsulation, and this encapsulation is normalised for 1034 delivery over the NNI (see Step 3 above). 1036 3. At this point, NNI processing begins. A data-link encapsulation 1037 is associated with the packet for delivery to the peer PE based 1038 on the normalised Transport Service Instance. 1040 4. Link-layer-specific postprocessing, if any, is performed. Such 1041 postprocessing is outside the scope of MPLS-TP. 1043 3.4.3.3. Example Interfaces 1045 This section considers some special cases of UNI processing for 1046 particular transport service types. These are illustrative, and do 1047 not preclude other transport service types. 1049 3.4.3.3.1. Layer 2 Transport Service 1051 In this example the MPLS-TP network is providing a point-to-point 1052 Layer 2 transport service between attached CE nodes. This service is 1053 provided by a Transport Service Instance consisting of a PW 1054 established between the associated PE nodes. The client flows 1055 associated with this Transport Service Instance are the sets of all 1056 Layer 2 frames transmitted and received over the attachment circuits. 1058 The processing steps in this case for a frame received from the CE 1059 are: 1061 1. Link-layer specific preprocessing, if any, is performed, 1062 corresponding to the PREP function illustrated in Figure 3 of 1063 [RFC3985]. 1065 2. The frame is associated with a Transport Service Instance based 1066 on the attachment circuit over which it was received. 1068 3. A transport service encapsulation, consisting of the PW control 1069 word and PW label, is associated with the frame. 1071 4. The resulting packet is mapped to an LSP, the LSP label is 1072 pushed, and the packet is transmitted over the outbound interface 1073 associated with the LSP. 1075 The steps in the reverse direction for PW packets received over the 1076 LSP are analogous. 1078 3.4.3.3.2. IP Transport Service 1080 In this example the MPLS-TP network is providing a point-to-point IP 1081 transport service between CE1, CE2, and CE3, as follows. One point- 1082 to-point transport service instance delivers IPv4 packets between CE1 1083 and CE2, and another instance delivers IPv6 packets between CE1 and 1084 CE3. 1086 The processing steps in this case for an IP packet received from CE1 1087 are: 1089 1. No link-layer-specific processing is performed. 1091 2. The IP packet is extracted from the link-layer frame and 1092 associated with a Service LSP based on the source MAC address 1093 (CE1) and the IP protocol version. 1095 3. A transport service encapsulation, consisting of the Service LSP 1096 label, is associated with the packet. 1098 4. The resulting packet is mapped to a tunnel LSP, the tunnel LSP 1099 label is pushed, and the packet is transmitted over the outbound 1100 interface associated with the LSP. 1102 The steps in the reverse direction, for packets received over a 1103 tunnel LSP carrying the Service LSP label, are analogous. 1105 3.4.4. Pseudowire Adaptation 1107 MPLS-TP uses pseudowires to provide a Virtual Private Wire Service 1108 (VPWS), a Virtual Private Local Area Network Service (VPLS), a 1109 Virtual Private Multicast Service (VPMS) and an Internet Protocol 1110 Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are 1111 described in [RFC4664]. VPMS is described in 1112 [I-D.ietf-l2vpn-vpms-frmwk-requirements]. 1114 If the MPLS-TP network provides a layer 2 interface, that can carry 1115 both network layer and non-network layer traffic, as a service 1116 interface, then a PW is required to support the service interface. 1117 The PW is a client of the MPLS-TP LSP server layer. The architecture 1118 for an MPLS-TP network that provides such services is based on the 1119 MPLS [RFC3031] and pseudowire [RFC3985] architectures. Multi-segment 1120 pseudowires may optionally be used to provide a packet transport 1121 service, and their use is consistent with the MPLS-TP architecture. 1122 The use of MS-PWs may be motivated by, for example, the requirements 1123 specified in [RFC5254]. If MS-PWs are used, then the MS-PW 1124 architecture [RFC5659] also applies. 1126 Figure 7 shows the architecture for an MPLS-TP network using single- 1127 segment PWs. Note that, in this document, the client layer is 1128 equivalent to the emulated service described in [RFC3985], while the 1129 Transport LSP is equivalent to the Packet Switched Network (PSN) 1130 tunnel of [RFC3985]. 1132 |<----------------- Client Layer ------------------->| 1133 | | 1134 | |<-------- Pseudowire -------->| | 1135 | | encapsulated, packet | | 1136 | | transport service | | 1137 | | | | 1138 | | Transport | | 1139 | | |<------ LSP ------->| | | 1140 | V V V V | 1141 V AC +----+ +-----+ +----+ AC V 1142 +-----+ | | PE1|=======\ /========| PE2| | +-----+ 1143 | |----------|.......PW1.| \ / |............|----------| | 1144 | CE1 | | | | | X | | | | | CE2 | 1145 | |----------|.......PW2.| / \ |............|----------| | 1146 +-----+ ^ | | |=======/ \========| | | ^ +-----+ 1147 ^ | +----+ ^ +-----+ +----+ | ^ 1148 | | Provider | ^ Provider | | 1149 | | Edge 1 | | Edge 2 | | 1150 Customer | | P Router | Customer 1151 Edge 1 | TE LSP | Edge 2 1152 | | 1153 | | 1154 Native service Native service 1156 Figure 7: MPLS-TP Architecture (Single Segment PW) 1158 Figure 8 shows the architecture for an MPLS-TP network when multi- 1159 segment pseudowires are used. Note that as in the SS-PW case, 1160 P-routers may also exist. 1162 |<--------------------- Client Layer ------------------------>| 1163 | | 1164 | Pseudowire encapsulated, | 1165 | |<---------- Packet Transport Service ------------->| | 1166 | | | | 1167 | | Transport Transport | | 1168 | AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC | 1169 | | V V V V V V | | 1170 V | +----+ +-----+ +----+ +----+ | V 1171 +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ 1172 | |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| | 1173 |CE1| | | | | X | | | | | | |CE2| 1174 | |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| | 1175 +---+ ^ | |===============/ \=====| |==========| | | ^+---+ 1176 | +----+ ^ +-----+ +----+ ^ +----+ | 1177 | | ^ | | 1178 | TE LSP | TE LSP | 1179 | P-router | 1180 Native Service Native Service 1182 PW1-segment1 and PW1-segment2 are segments of the same MS-PW, 1183 while PW2-segment1 and PW2-segment2 are segments of another MS-PW 1185 Figure 8: MPLS-TP Architecture (Multi-Segment PW) 1187 The corresponding MPLS-TP protocol stacks including PWs are shown in 1188 Figure 9. In this figure the Transport Service Layer [RFC5654] is 1189 identified by the PW demultiplexer (Demux) label and the Transport 1190 Path Layer [RFC5654] is identified by the LSP Demux Label. 1192 +-------------------+ /===================\ /===================\ 1193 | Client Layer | H OAM PDU H H OAM PDU H 1194 /===================\ H-------------------H H-------------------H 1195 H PW Encap H H GACh H H GACh H 1196 H-------------------H H-------------------H H-------------------H 1197 H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H 1198 H-------------------H H-------------------H H-------------------H 1199 H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H 1200 \===================/ \===================/ \===================/ 1201 | Server Layer | | Server Layer | | Server Layer | 1202 +-------------------+ +-------------------+ +-------------------+ 1204 User Traffic PW OAM LSP OAM 1206 Note: H(ighlighted) indicates the part of the protocol stack considered 1207 in this document. 1209 Figure 9: MPLS-TP label stack using pseudowires 1211 PWs and their associated labels may be configured or signaled. See 1212 Section 3.11 for additional details related to configured service 1213 types. See Section 3.9 for additional details related to signaled 1214 service types. 1216 3.4.5. Network Layer Adaptation 1218 MPLS-TP LSPs can be used to transport network layer clients. This 1219 document uses the term Network Layer in the same sense as it is used 1220 in [RFC3031] and [RFC3032]. The network layer protocols supported by 1221 [RFC3031] and [RFC3032] can be transported between service 1222 interfaces. Support for network layer clients follows the MPLS 1223 architecture for support of network layer protocols as specified in 1224 [RFC3031] and [RFC3032]. 1226 With network layer adaptation, the MPLS-TP domain provides either a 1227 uni-directional or bidirectional point-to-point connection between 1228 two PEs in order to deliver a packet transport service to attached 1229 customer edge (CE) nodes. For example, a CE may be an IP, MPLS or 1230 MPLS-TP node. As shown in Figure 10, there is an attachment circuit 1231 between the CE node on the left and its corresponding provider edge 1232 (PE) node which provides the service interface, a bidirectional LSP 1233 across the MPLS-TP network to the corresponding PE node on the right, 1234 and an attachment circuit between that PE node and the corresponding 1235 CE node for this service. 1237 The attachment circuits may be heterogeneous (e.g., any combination 1238 of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads 1239 arrive at the service interface encapsulated in the Layer1/Layer2 1240 encoding defined for that access link type. It should be noted that 1241 the set of network layer protocols includes MPLS and hence MPLS 1242 encoded packets with an MPLS label stack (the client MPLS stack), may 1243 appear at the service interface. 1245 The following figures illustrate the reference models for network 1246 layer adaptation. The details of these figures are described further 1247 in the following paragraphs. 1249 |<------------- Client Network Layer --------------->| 1250 | | 1251 | |<----------- Packet --------->| | 1252 | | Transport Service | | 1253 | | | | 1254 | | | | 1255 | | Transport | | 1256 | | |<------ LSP ------->| | | 1257 | V V V V | 1258 V AC +----+ +-----+ +----+ AC V 1259 +-----+ | | PE1|=======\ /========| PE2| | +-----+ 1260 | |----------|..Svc LSP1.| \ / |............|----------| | 1261 | CE1 | | | | | X | | | | | CE2 | 1262 | |----------|..Svc LSP2.| / \ |............|----------| | 1263 +-----+ ^ | | |=======/ \========| | | ^ +-----+ 1264 ^ | +----+ ^ +-----+ +----+ | | ^ 1265 | | Provider | ^ Provider | | 1266 | | Edge 1 | | Edge 2 | | 1267 Customer | | P Router | Customer 1268 Edge 1 | TE LSP | Edge 2 1269 | | 1270 | | 1271 Native service Native service 1273 Figure 10: MPLS-TP Architecture for Network Layer Clients 1275 |<--------------------- Client Layer ------------------------>| 1276 | | 1277 | | 1278 | |<---------- Packet Transport Service ------------->| | 1279 | | | | 1280 | | Transport Transport | | 1281 | AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC | 1282 | | V V V V V V | | 1283 V | +----+ +-----+ +----+ +----+ | V 1284 +---+ | | PE1|===============\ /=====| PE2|==========| PE3| | +---+ 1285 | |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----| | 1286 |CE1| | | | | X | | | | | | |CE2| 1287 | |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----| | 1288 +---+ ^ | |===============/ \=====| |==========| | | ^+---+ 1289 | +----+ ^ +-----+ +----+ ^ +----+ | 1290 | | ^ ^ | | 1291 | TE LSP | | TE LSP | 1292 | P-router | | 1293 Native Service (LSR for | Native Service 1294 T'port LSP1) | 1295 | 1296 LSR for Service LSPs 1297 LER for Transport LSPs 1299 Figure 11: MPLS-TP Architecture for Network Layer Adaptation, showing 1300 Service LSP Switching 1302 Client packets are received at the ingress service interface. The PE 1303 pushes one or more labels onto the client packets which are then 1304 label switched over the transport network. Correspondingly the 1305 egress PE pops any labels added by the MPLS-TP networks and transmits 1306 the packet for delivery to the attached CE via the egress service 1307 interface. 1309 /===================\ 1310 H OAM PDU H 1311 +-------------------+ H-------------------H /===================\ 1312 | Client Layer | H GACh H H OAM PDU H 1313 /===================\ H-------------------H H-------------------H 1314 H Encap Label H H GAL (S=1) H H GACh H 1315 H-------------------H H-------------------H H-------------------H 1316 H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H 1317 H-------------------H H-------------------H H-------------------H 1318 H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H 1319 \===================/ \===================/ \===================/ 1320 | Server Layer | | Server Layer | | Server Layer | 1321 +-------------------+ +-------------------+ +-------------------+ 1323 User Traffic Service LSP OAM LSP OAM 1325 Note: H(ighlighted) indicates the part of the protocol stack considered 1326 in this document. 1328 Figure 12: MPLS-TP Label Stack for IP and LSP Clients 1330 In the figures above, the Transport Service Layer [RFC5654] is 1331 identified by the Service LSP (SvcLSP) demultiplexer (Demux) label 1332 and the Transport Path Layer [RFC5654] is identified by the Transport 1333 (Trans) LSP Demux Label. Note that the functions of the 1334 Encapsulation label (Encap Label) and the Service Label (SvcLSP 1335 Demux) shown above may alternatively be represented by a single label 1336 stack entry. Note that the S-bit is always zero when the client 1337 layer is MPLS-labelled. It may be necessary to swap a service LSP 1338 label at an intermediate node. This is shown in Figure 11. 1340 Within the MPLS-TP transport network, the network layer protocols are 1341 carried over the MPLS-TP network using a logically separate MPLS 1342 label stack (the server stack). The server stack is entirely under 1343 the control of the nodes within the MPLS-TP transport network and it 1344 is not visible outside that network. Figure 12 shows how a client 1345 network protocol stack (which may be an MPLS label stack and payload) 1346 is carried over a network layer client service over an MPLS-TP 1347 transport network. 1349 A label may be used to identify the network layer protocol payload 1350 type. Therefore, when multiple protocol payload types are to be 1351 carried over a single service LSP, a unique label stack entry needs 1352 to be present for each payload type. Such labels are referred to as 1353 "Encapsulation Labels", one of which is shown in Figure 12. 1354 Encapsulation Label may be either configured or signaled. 1356 Both an Encapsulation Label and a Service Label should be present in 1357 the label stack when a particular packet transport service is 1358 supporting more than one network layer protocol payload type. For 1359 example, if both IP and MPLS are to be carried, then two 1360 Encapsulation Labels are mapped on to a common Service Label. 1362 Note: The Encapsulation Label may be omitted when the service LSP is 1363 supporting only one network layer protocol payload type. For 1364 example, if only MPLS labeled packets are carried over a service, 1365 then the Service Label (stack entry) provides both the payload type 1366 indication and service identification. 1368 Service labels are typically carried over an MPLS-TP Transport LSP 1369 edge-to-edge (or transport path layer). An MPLS-TP Transport LSP is 1370 represented as an LSP Transport Demux label, as shown in Figure 12. 1371 Transport LSP is commonly used when more than one service exists 1372 between two PEs. 1374 Note that, if only one service exists between two PEs, the functions 1375 of the Transport LSP label and the Service LSP Label may be combined 1376 into a single label stack entry. For example, if only one service is 1377 carried between two PEs then a single label could be used to provide 1378 both the service indication and the MPLS-TP transport LSP. 1379 Alternatively, if multiple services exist between a pair of PEs then 1380 a per-client Service Label would be mapped on to a common MPLS-TP 1381 transport LSP. 1383 As noted above, the layer 2 and layer 1 protocols used to carry the 1384 network layer protocol over the attachment circuits are not 1385 transported across the MPLS-TP network. This enables the use of 1386 different layer 2 and layer 1 protocols on the two attachment 1387 circuits. 1389 At each service interface, Layer 2 addressing needs to be used to 1390 ensure the proper delivery of a network layer packet to the adjacent 1391 node. This is typically only an issue for LAN media technologies 1392 (e.g., Ethernet) which have Media Access Control (MAC) addresses. In 1393 cases where a MAC address is needed, the sending node sets the 1394 destination MAC address to an address that ensures delivery to the 1395 adjacent node. That is the CE sets the destination MAC address to an 1396 address that ensures delivery to the PE, and the PE sets the 1397 destination MAC address to an address that ensures delivery to the 1398 CE. The specific address used is technology type specific and is not 1399 specified in this document. In some technologies the MAC address 1400 will need to be configured. 1402 Note that when two CEs, which peer with each other, operate over a 1403 network layer transport service and run a routing protocol such as 1404 IS-IS or OSPF, some care should be taken to configure the routing 1405 protocols to use point-to-point adjacencies. The specifics of such 1406 configuration is outside the scope of this document. See [RFC5309] 1407 for additional details. 1409 The CE to CE service types and corresponding labels may be configured 1410 or signaled . 1412 3.5. Identifiers 1414 Identifiers are used to uniquely distinguish entities in an MPLS-TP 1415 network. These include operators, nodes, LSPs, pseudowires, and 1416 their associated maintenance entities. MPLS-TP defined two type of 1417 sets of identifiers: Those that are compatible with IP, and another 1418 set that is compatible with ITU-T transport-based operations. The 1419 definition of these sets of identifiers is outside the scope of this 1420 document and is provided by [I-D.ietf-mpls-tp-identifiers]. 1422 3.6. Generic Associated Channel (G-ACh) 1424 For correct operation of OAM mechanisms it is important that OAM 1425 packets fate-share with the data packets. In addition in MPLS-TP it 1426 is necessary to discriminate between user data payloads and other 1427 types of payload. For example, a packet may be associated with a 1428 Signaling Communication Channel (SCC), or a channel used for a 1429 protocol to coordinate path protection state. This is achieved by 1430 carrying such packets in either: 1432 o A generic control channel associated to the LSP, PW or section, 1433 with no IP encapsulation. e.g. in a similar manner to 1434 Bidirectional Forwarding Detection for Virtual Circuit 1435 Connectivity Verification (VCCV-BFD) with PW ACH encapsulation 1436 [I-D.ietf-pwe3-vccv-bfd]). 1438 o An IP encapsulation where IP capabilities are present. e.g. PW 1439 ACH encapsulation with IP headers for VCCV-BFD 1440 [I-D.ietf-pwe3-vccv-bfd], or IP encapsulation for MPLS BFD 1441 [I-D.ietf-bfd-mpls]. 1443 MPLS-TP makes use of such a generic associated channel (G-ACh) to 1444 support Fault, Configuration, Accounting, Performance and Security 1445 (FCAPS) functions by carrying packets related to OAM, a protocol used 1446 to coodinate path protection state, SCC, MCC or other packet types 1447 in-band over LSPs, PWs or sections. The G-ACh is defined in 1448 [RFC5586] and is similar to the Pseudowire Associated Channel 1449 [RFC4385], which is used to carry OAM packets over pseudowires. The 1450 G-ACh is indicated by an Associated Channel Header (ACH), similar to 1451 the Pseudowire VCCV control word; this header is present for all 1452 sections, LSPs and PWs making use of FCAPS functions supported by the 1453 G-ACh. 1455 As specified in [RFC5586], the G-ACh must only be used for channels 1456 that are an adjunct to the data service. Examples of these are OAM, 1457 a protocol used to coodinate path protection state, MCC and SCC, but 1458 the use is not restricted to these services. The G-ACh must not to 1459 be used to carry additional data for use in the forwarding path, i.e. 1460 it must not be used as an alternative to a PW control word, or to 1461 define a PW type. 1463 At the server layer, bandwidth and QoS commitments apply to the gross 1464 traffic on the LSP, PW or section. Since the G-ACh traffic is 1465 indistinguishable from the user data traffic, protocols using the 1466 G-ACh need to take into consideration the impact they have on the 1467 user data with which they are sharing resources. Conversely, 1468 capacity needs to be made available for important G-ACh uses such as 1469 protection and OAM. In addition, the security and congestion 1470 considerations described in [RFC5586] apply to protocols using the 1471 G-ACh. 1473 Figure 13 shows the reference model depicting how the control channel 1474 is associated with the pseudowire protocol stack. This is based on 1475 the reference model for VCCV shown in Figure 2 of [RFC5085]. 1477 +-------------+ +-------------+ 1478 | Payload | < FCAPS > | Payload | 1479 +-------------+ +-------------+ 1480 | Demux / | < ACH for PW > | Demux / | 1481 |Discriminator| |Discriminator| 1482 +-------------+ +-------------+ 1483 | PW | < PW > | PW | 1484 +-------------+ +-------------+ 1485 | PSN | < LSP > | PSN | 1486 +-------------+ +-------------+ 1487 | Physical | | Physical | 1488 +-----+-------+ +-----+-------+ 1489 | | 1490 | ____ ___ ____ | 1491 | _/ \___/ \ _/ \__ | 1492 | / \__/ \_ | 1493 | / \ | 1494 +--------| MPLS-TP Network |---+ 1495 \ / 1496 \ ___ ___ __ _/ 1497 \_/ \____/ \___/ \____/ 1499 Figure 13: PWE3 Protocol Stack Reference Model showing the G-ACh 1501 PW associated channel messages are encapsulated using the PWE3 1502 encapsulation, so that they are handled and processed in the same 1503 manner (or in some cases, an analogous manner) as the PW PDUs for 1504 which they provide a control channel. 1506 Figure 14 shows the reference model depicting how the control channel 1507 is associated with the LSP protocol stack. 1509 +-------------+ +-------------+ 1510 | Payload | < FCAPS > | Payload | 1511 +-------------+ +-------------+ 1512 |Discriminator| < ACH on LSP > |Discriminator| 1513 +-------------+ +-------------+ 1514 |Demultiplexer| < GAL on LSP > |Demultiplexer| 1515 +-------------+ +-------------+ 1516 | PSN | < LSP > | PSN | 1517 +-------------+ +-------------+ 1518 | Physical | | Physical | 1519 +-----+-------+ +-----+-------+ 1520 | | 1521 | ____ ___ ____ | 1522 | _/ \___/ \ _/ \__ | 1523 | / \__/ \_ | 1524 | / \ | 1525 +--------| MPLS-TP Network |---+ 1526 \ / 1527 \ ___ ___ __ _/ 1528 \_/ \____/ \___/ \____/ 1530 Figure 14: MPLS Protocol Stack Reference Model showing the LSP 1531 Associated Control Channel 1533 3.7. Operations, Administration and Maintenance (OAM) 1535 The MPLS-TP OAM architecture supports a wide range of OAM functions 1536 to check continuity, to verify connectivity, to monitor path 1537 performance, and to generate, filter and manage local and remote 1538 defect alarms. These functions are applicable to any layer defined 1539 within MPLS-TP, i.e. to MPLS-TP sections, LSPs and PWs. 1541 The MPLS-TP OAM tool-set is able to operate without relying on a 1542 dynamic control plane or IP functionality in the datapath. In the 1543 case of an MPLS-TP deployment in a network in which IP functionality 1544 is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD 1545 and VCCV, may be used. Since MPLS-TP can operate in environments 1546 where IP is not used in the forwarding plane, the default mechanism 1547 for OAM demultiplexing in MPLS-TP LSPs and PWs is the Generic 1548 Associated Channel (Section 3.6). Forwarding based on IP addresses 1549 for user or OAM packets is not required for MPLS-TP. 1551 [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined 1552 alert mechanisms that enable an MPLS LSR to identify and process MPLS 1553 OAM packets when the OAM packets are encapsulated in an IP header. 1554 These alert mechanisms are based on TTL expiration and/or use an IP 1555 destination address in the range 127/8 for IPv4 and that same range 1556 embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the 1557 OAM packets are encapsulated in an IP header, these mechanisms are 1558 the default mechanisms for MPLS networks in general for identifying 1559 MPLS OAM packets, although the mechanisms defined in [RFC5586] can 1560 also be used. MPLS-TP is able to operate in environments where IP 1561 forwarding is not supported, and thus the G-ACh/GAL is the default 1562 mechanism to demultiplex OAM packets in MPLS-TP in these 1563 environments. 1565 MPLS-TP supports a comprehensive set of OAM capabilities for packet 1566 transport applications, with equivalent capabilities to those 1567 provided in SONET/SDH. 1569 MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of 1570 OAM capabilities is available to perform fault management (e.g. fault 1571 detection and localisation) and performance monitoring (e.g. packet 1572 delay and loss measurement) of the LSP, PW or section. The framework 1573 for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. 1575 MPLS-TP OAM packets share the same fate as their corresponding data 1576 packets, and are identified through the Generic Associated Channel 1577 mechanism [RFC5586]. This uses a combination of an Associated 1578 Channel Header (ACH) and a G-ACh Label (GAL) to create a control 1579 channel associated to an LSP, Section or PW. 1581 OAM and monitoring in MPLS-TP is based on the concept of maintenance 1582 entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A 1583 Maintenance Entity (ME) can be viewed as the association of two 1584 Maintenance Entity Group End Points (MEPs). A Maintenance Entity 1585 Group (MEG) is a collection of one or more MEs that belongs to the 1586 same transport path and that are maintained and monitored as a group. 1587 The MEPs that form an ME limit the OAM responsibilities of an OAM 1588 flow to within the domain of a transport path or segment, in the 1589 specific layer network that is being monitored and managed. 1591 A MEG may also include a set of Maintenance Entity Group Intermediate 1592 Points (MIPs). MEPs are capable of sourcing and sinking OAM flows, 1593 while MIPs can both react to OAM flows received from within a MEG and 1594 originate notifications to the MEPs as a result of specific network 1595 conditions. 1597 A G-ACh packet may be directed to an individual MIP along the path of 1598 an LSP or MS-PW by setting the appropriate TTL in the label stack 1599 entry for the G-ACh packet, as per the traceroute mode of LSP Ping 1600 [RFC4379] and the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw]. 1601 Note that this works when the location of MIPs along the LSP or PW 1602 path is known by the MEP. There may be circumstances where this is 1603 not the case, e.g. following restoration using a facility bypass LSP. 1604 In these cases, tools to trace the path of the LSP may be used to 1605 determine the appropriate setting for the TTL to reach a specific 1606 MIP. 1608 Within an LSR or PE, MEPs and MIPs can only be placed where MPLS 1609 layer processing is performed on a packet. The MPLS architecture 1610 mandates that MPLS layer processing occurs at least once on an LSR. 1612 Any node on an LSP can send an OAM packet on that LSP. Likewise, any 1613 node on a PW can send OAM packets on a PW, including S-PEs. 1615 An OAM packet can only be received to be processed at an LSP 1616 endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the 1617 LSP or PW label stack entry. 1619 3.8. Return Path 1621 Management, control and OAM protocol functions may require response 1622 packets to be delivered from the receiver back to the originator of a 1623 message exchange. This section provides a summary of the return path 1624 options in MPLS-TP networks. Although this section describes the 1625 case of an MPLS-TP LSP, it is also applicable to a PW. 1627 In this description, U and D are LSRs that terminate MPLS-TP LSPs 1628 (i.e. LERs) and Y is an intermediate LSR along the LSP. Note that U 1629 is the upstream LER and D is the downstream LER with respect to a 1630 particular direction of an LSP. This reference model is shown in 1631 Figure 15. 1633 LSP LSP 1635 U ========= Y ========= D 1637 LER LSR LER 1639 ---------> Direction of user plane traffic flow 1641 Figure 15: Return Path reference Model 1643 The following cases are described for the various types of LSPs: 1645 Case 1 Return path packet transmission from D to U 1647 Case 2 Return path packet transmission from Y to U 1649 Case 3 Return path packet transmission from D to Y 1651 Note that a return path may not always exist (or may exist but be 1652 disabled), and that packet transmission in one or more of the above 1653 cases may not be possible. In general the existence and nature of 1654 return paths for MPLS-TP LSPs is determined by operational 1655 provisioning. 1657 3.8.1. Return Path Types 1659 There are two types of return path that may be used for the delivery 1660 of traffic from a downstream node D to an upstream node U. Either: 1662 a. The LSP between U and D is bidirectional, and therefore D has a 1663 path via the MPLS-TP LSP to return traffic back to U, or 1665 b. D has some other unspecified means of directing traffic back to 1666 U. 1668 The first option is referred to as an "in-band" return path, the 1669 second as an "out-of-band" return path. 1671 There are various possibilities for "out-of-band" return paths. Such 1672 a path may, for example, be based on ordinary IP routing. In this 1673 case packets would be forwarded as usual to a destination IP address 1674 associated with U. In an MPLS-TP network that is also an IP/MPLS 1675 network, such a forwarding path may traverse the same physical links 1676 or logical transport paths used by MPLS-TP. An out-of-band return 1677 path may also be indirect, via a distinct Data Communication Network 1678 (DCN) (provided, for example, by the method specified in [RFC5718]); 1679 or it may be via one or more other MPLS-TP LSPs. 1681 3.8.2. Point-to-Point Unidirectional LSPs 1683 Case 1 If an in-band return path is required to deliver traffic from 1684 D back to U, it is recommended for reasons of operational 1685 simplicity that point-to-point unidirectional LSPs be 1686 provisioned as associated bidirectional LSPs (which may also 1687 be co-routed) whenever return traffic from D to U is 1688 required. Note that the two directions of such an LSP may 1689 have differing bandwidth allocations and QoS characteristics. 1690 The discussion for such LSPs below applies. 1692 As an alternative, an out-of-band return path may be used. 1694 Case 2 In this case only the out-of-band return path option is 1695 available. However, an additional out-of-band possibility is 1696 worthy of note here: if D is known to have a return path to 1697 U, then Y can arrange to deliver return traffic to U by first 1698 sending it to D along the original LSP. The mechanism by 1699 which D recognises the need for and performs this forwarding 1700 operation is protocol-specific. 1702 Case 3 In this case only the out-of-band return path option is 1703 available. However, if D has a return path to U, then in a 1704 manner analogous to the previous case D can arrange to 1705 deliver return traffic to Y by first sending it to U along 1706 that return path. The mechanism by which U recognises the 1707 need for and performs this forwarding operation is protocol- 1708 specific. 1710 3.8.3. Point-to-Point Associated Bidirectional LSPs 1712 For Case 1, D has a natural in-band return path to U, the use of 1713 which is typically preferred for return traffic, although out-of-band 1714 return paths are also applicable. 1716 For Cases 2 and 3, the considerations are the same as those for 1717 point-to-point unidirectional LSPs. 1719 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs 1721 For all of Cases 1, 2, and 3, a natural in-band return path exists in 1722 the form of the LSP itself, and its use is preferred for return 1723 traffic. Out-of-band return paths, however, are also applicable, 1724 primarily as an alternative means of delivery in case the in-band 1725 return path has failed. 1727 3.9. Control Plane 1729 A distributed dynamic control plane may be used to enable dynamic 1730 service provisioning in an MPLS-TP network. Where the requirements 1731 specified in [RFC5654] can be met, the MPLS Transport Profile uses 1732 existing standard control plane protocols for LSPs and PWs. 1734 Note that a dynamic control plane is not required in an MPLS-TP 1735 network. See Section 3.11 for further details on statically 1736 configured and provisioned MPLS-TP services. 1738 Figure 16 illustrates the relationship between the MPLS-TP control 1739 plane, the forwarding plane, the management plane, and OAM for point- 1740 to-point MPLS-TP LSPs or PWs. 1742 +------------------------------------------------------------------+ 1743 | | 1744 | Network Management System and/or | 1745 | | 1746 | Control Plane for Point-to-Point Connections | 1747 | | 1748 +------------------------------------------------------------------+ 1749 | | | | | | 1750 .............|.....|... ....|.....|.... ....|.....|............ 1751 : +---+ | : : +---+ | : : +---+ | : 1752 : |OAM| | : : |OAM| | : : |OAM| | : 1753 : +---+ | : : +---+ | : : +---+ | : 1754 : | | : : | | : : | | : 1755 \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/ 1756 --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+-- 1757 /: +----+ |ing | : : |ing | : : |ing | +----+ :\ 1758 : +--------+ : : +--------+ : : +--------+ : 1759 ''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' 1761 Note: 1762 1) NMS may be centralised or distributed. Control plane is 1763 distributed. 1764 2) 'Edge' functions refers to those functions present at 1765 the edge of a PSN domain, e.g. NSP or classification. 1766 3) The control plane may be transported over the server 1767 layer, an LSP or a G-ACh. 1769 Figure 16: MPLS-TP Control Plane Architecture Context 1771 The MPLS-TP control plane is based on existing MPLS and PW control 1772 plane protocols, and is consistent with the Automatically Switched 1773 Optical Networks (ASON) architecture [G.8080]. MPLS-TP uses 1774 Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473]) 1775 for LSPs and Targeted LDP (T-LDP) [RFC4447] 1776 [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] for 1777 pseudowires. 1779 MPLS-TP requires that any control plane traffic be capable of being 1780 carried over an out-of-band signaling network or a signaling control 1781 channel such as the one described in [RFC5718]. Note that while 1782 T-LDP signaling is traditionally carried in-band in IP/MPLS networks, 1783 this does not preclude its operation over out-of-band channels. 1784 References to T-LDP in this document do not preclude the definition 1785 of alternative PW control protocols for use in MPLS-TP. 1787 PW control (and maintenance) takes place separately from LSP tunnel 1788 signaling. The main coordination between LSP and PW control will 1789 occur within the nodes that terminate PWs. The control planes for 1790 PWs and LSPs may be used independently, and one may be employed 1791 without the other. This translates into the four possible scenarios: 1792 (1) no control plane is employed; (2) a control plane is used for 1793 both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs; 1794 (4) a control plane is used for PWs, but not LSPs. The PW and LSP 1795 control planes, collectively, need to satisfy the MPLS-TP control 1796 plane requirements reviewed in the MPLS-TP Control Plane Framework 1797 [I-D.ietf-ccamp-mpls-tp-cp-framework]. When client services are 1798 provided directly via LSPs, all requirements must be satisfied by the 1799 LSP control plane. When client services are provided via PWs, the PW 1800 and LSP control planes operate in combination and some functions may 1801 be satisfied via the PW control plane while others are provided to 1802 PWs by the LSP control plane. 1804 Note that if MPLS-TP is being used in a multi-layer network, a number 1805 of control protocol types and instances may be used. This is 1806 consistent with the MPLS architecture which permits each label in the 1807 label stack to be allocated and signaled by its own control protocol. 1809 The distributed MPLS-TP control plane may provide the following 1810 functions: 1812 o Signaling 1814 o Routing 1816 o Traffic engineering and constraint-based path computation 1818 In a multi-domain environment, the MPLS-TP control plane supports 1819 different types of interfaces at domain boundaries or within the 1820 domains. These include the User-Network Interface (UNI), Internal 1821 Network-Network Interface (I-NNI), and External Network-Network 1822 Interface (E-NNI). Note that different policies may be defined that 1823 control the information exchanged across these interface types. 1825 The MPLS-TP control plane is capable of activating MPLS-TP OAM 1826 functions as described in the OAM section of this document 1827 Section 3.7, e.g. for fault detection and localisation in the event 1828 of a failure in order to efficiently restore failed transport paths. 1830 The MPLS-TP control plane supports all MPLS-TP data plane 1831 connectivity patterns that are needed for establishing transport 1832 paths, including protected paths as described in Section 3.12. 1833 Examples of the MPLS-TP data plane connectivity patterns are LSPs 1834 utilising the fast reroute backup methods as defined in [RFC4090] and 1835 ingress-to-egress 1+1 or 1:1 protected LSPs. 1837 The MPLS-TP control plane provides functions to ensure its own 1838 survivability and to enable it to recover gracefully from failures 1839 and degradations. These include graceful restart and hot redundant 1840 configurations. Depending on how the control plane is transported, 1841 varying degrees of decoupling between the control plane and data 1842 plane may be achieved. In all cases, however, the control plane is 1843 logically decoupled from the data plane such that a control plane 1844 failure does not imply a failure of the existing transport paths. 1846 3.10. Interdomain Connectivity 1848 A number of methods exist to support inter-domain operation of 1849 MPLS-TP, including the data plane, OAM and configuration aspects, for 1850 example: 1852 o Inter-domain TE LSPs [RFC4726] 1854 o Multi-segment Pseudowires [RFC5659] 1856 o LSP stitching [RFC5150] 1858 o back-to-back attachment circuits [RFC5659] 1860 An important consideration in selecting an inter-domain connectivity 1861 mechanism is the degree of layer network isolation and types of OAM 1862 required by the operator. The selection of which technique to use in 1863 a particular deployment scenario is outside the scope of this 1864 document. 1866 3.11. Static Operation of LSPs and PWs 1868 A PW or LSP may be statically configured without the support of a 1869 dynamic control plane. This may be either by direct configuration of 1870 the PEs/LSRs, or via a network management system. Static operation 1871 is independent for a specific PW or LSP instance. Thus it should be 1872 possible for a PW to be statically configured, while the LSP 1873 supporting it is set up by a dynamic control plane. When static 1874 configuration mechanisms are used, care must be taken to ensure that 1875 loops are not created. Note that the path of an LSP or PW may be 1876 dynamically computed, while the LSP or PW itself is established 1877 through static configuration. 1879 3.12. Survivability 1881 The survivability architecture for MPLS-TP is specified in 1882 [I-D.ietf-mpls-tp-survive-fwk]. 1884 A wide variety of resiliency schemes have been developed to meet the 1885 various network and service survivability objectives. For example, 1886 as part of the MPLS/PW paradigms, MPLS provides methods for local 1887 repair using back-up LSP tunnels ([RFC4090]), while pseudowire 1888 redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the 1889 protection for the PW cannot be fully provided by the underlying LSP 1890 (i.e. where the backup PW terminates on a different target PE node 1891 than the working PW in dual homing scenarios, or where protection of 1892 the S-PE is required). Additionally, GMPLS provides a well known set 1893 of control plane driven protection and restoration mechanisms 1894 [RFC4872]. MPLS-TP provides additional protection mechanisms that 1895 are optimised for both linear topologies and ring topologies, and 1896 that operate in the absence of a dynamic control plane. These are 1897 specified in [I-D.ietf-mpls-tp-survive-fwk]. 1899 Different protection schemes apply to different deployment topologies 1900 and operational considerations. Such protection schemes may provide 1901 different levels of resiliency, for example: 1903 o Two concurrent traffic paths (1+1). 1905 o one active and one standby path with guaranteed bandwidth on both 1906 paths (1:1). 1908 o one active path and a standby path the resources of which are 1909 shared by one or more other active paths (shared protection). 1911 The applicability of any given scheme to meet specific requirements 1912 is outside the scope of this document. 1914 The characteristics of MPLS-TP resiliency mechanisms are as follows: 1916 o Optimised for linear, ring or meshed topologies. 1918 o Use OAM mechanisms to detect and localise network faults or 1919 service degenerations. 1921 o Include protection mechanisms to coordinate and trigger protection 1922 switching actions in the absence of a dynamic control plane. 1924 o MPLS-TP recovery schemes are applicable to all levels in the 1925 MPLS-TP domain (i.e. section, LSP and PW), providing segment and 1926 end-to-end recovery. 1928 o MPLS-TP recovery mechanisms support the coordination of protection 1929 switching at multiple levels to prevent race conditions occurring 1930 between a client and its server layer. 1932 o MPLS-TP recovery mechanisms can be data plane, control plane or 1933 management plane based. 1935 o MPLS-TP supports revertive and non-revertive behaviour. 1937 3.13. Sub-Path Maintenance 1939 In order to monitor, protect and manage a portion (i.e. segment or 1940 concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be 1941 instantiated. A hierarchical LSP is instantiated for this purpose is 1942 called a Sub-Path Maintenance Element (SPME). Note that by 1943 definition an SPME does not carry user plane traffic as a direct 1944 clident. 1946 An SPME is defined between the edges of the portion of the LSP that 1947 needs to be monitored, protected or managed. The SPME forms an 1948 MPLS-TP Section [I-D.ietf-mpls-tp-data-plane] that carries the 1949 original LSP over this portion of a network as a client. OAM 1950 messages can be initiated at the edge of the SPME and sent to the 1951 peer edge of the SPME or to a MIP along the SPME by setting the TTL 1952 value of the LSE at the corresponding hierarchical LSP level. A P 1953 router only pushes or pops a label if it is at the end of a SPME. In 1954 this mode, it is an LER for the SPME. 1956 For example in Figure 17, two SPMEs are configured to allow 1957 monitoring, protection and management of the LSP concatenated 1958 segments. One SPME is defined between LER2 and LER3, and a second 1959 SPME is set up between LER4 and LER5. Each of these SPMEs may be 1960 monitored, protected, or managed independently. 1962 |<============================= LSP =============================>| 1964 |<---- Carrier 1 ---->| |<---- Carrier 2 ---->| 1966 |LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6| 1968 |====== SPME =========| |====== SPME =========| 1969 (Carrier 1) (Carrier 2) 1971 Note 1: LER2, LER3, LER4 and LER5 are with respect to the SPME 1972 Note 2: The LSP terminates in LERs outside of Carrier 1 and 1973 Carrier 2, for example LER1 and LER6. 1975 Figure 17: SPMEs in Inter-Carrier Network 1977 The end-to-end traffic of the LSP, including data traffic and control 1978 traffic (OAM, Protection Switching Control, management and signaling 1979 messages) is tunneled within the hierarchical LSP by means of label 1980 stacking as defined in [RFC3031]. 1982 The mapping between an LSP and a SPME can be 1:1, in which case it is 1983 similar to the ITU-T Tandem Connection Element [G.805]. The mapping 1984 can also be 1:N to allow aggregated monitoring, protection and 1985 management of a set of LSP segments or concatenated LSP segments. 1986 Figure 18 shows a SPME which is used to aggregate a set of 1987 concatenated LSP segments for the LSP from LERx to LERt and the LSP 1988 from LERa to LERd. Note that such a construct is useful, for 1989 example, when the LSPs traverse a common portion of the network and 1990 they have the same Traffic Class. 1992 The QoS aspects of a SPME are network specific. 1993 [I-D.ietf-mpls-tp-oam-framework] provides further considerations on 1994 the QoS aspects of OAM. 1996 |LERx|--|LSRy|-+ +-|LSRz|--|LERt| 1997 | | 1998 | |<---------- Carrier 1 --------->| | 1999 | +-----+ +---+ +---+ +-----+ | 2000 +--| |---| |---| |----| |--+ 2001 |LER1 | |LSR| |LSR| |LER2 | 2002 +--| |---| |---| |----| |--+ 2003 | +-----+ +---+ + P + +-----+ | 2004 | |============ SPME ==============| | 2005 |LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd| 2007 Figure 18: SPME for a Set of Concatenated LSP Segments 2009 SPMEs can be provisioned either statically or using control plane 2010 signaling procedures. The make-before-break procedures which are 2011 supported by MPLS allow the creation of a SPME on existing LSPs in- 2012 service without traffic disruption, as described in 2013 [I-D.ietf-mpls-tp-survive-fwk]. A SPME can be defined corresponding 2014 to one or more end-to-end LSPs. New end-to-end LSPs which are 2015 tunneled within the SPME can be set up, which may require 2016 coordination across administrative boundaries. Traffic of the 2017 existing LSPs is switched over to the new end-to-end tunneled LSPs. 2018 The old end-to-end LSPs can then be torn down. 2020 Hierarchical label stacking, in a similar manner to that described 2021 above, can be used to implement sub-path maintenance entities on 2022 pseudowires. 2024 3.14. Network Management 2026 The network management architecture and requirements for MPLS-TP are 2027 specified in [I-D.ietf-mpls-tp-nm-framework] and 2028 [I-D.ietf-mpls-tp-nm-req]. These derive from the generic 2029 specifications described in ITU-T G.7710/Y.1701 [G.7710] for 2030 transport technologies. They also incorporate the OAM requirements 2031 for MPLS Networks [RFC4377] and MPLS-TP Networks 2032 [I-D.ietf-mpls-tp-oam-requirements] and expand on those requirements 2033 to cover the modifications necessary for fault, configuration, 2034 performance, and security in a transport network. 2036 The Equipment Management Function (EMF) of an MPLS-TP Network Element 2037 (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through 2038 which a management system manages the NE. The Management 2039 Communication Channel (MCC), realised by the G-ACh, provides a 2040 logical operations channel between NEs for transferring Management 2041 information. For the management interface from a management system 2042 to an MPLS-TP NE, there is no restriction on which management 2043 protocol is used. The Network Management System (NMS) is used to 2044 provision and manage an end-to-end connection across a network where 2045 some segments are created/managed by, for example, Netconf [RFC4741] 2046 or SNMP [RFC3411] and other segments by XML or CORBA interfaces. 2047 Maintenance operations are run on a connection (LSP or PW) in a 2048 manner that is independent of the provisioning mechanism. An MPLS-TP 2049 NE is not required to offer more than one standard management 2050 interface. In MPLS-TP, the EMF needs to support statically 2051 provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any 2052 associated MEPs and MIPs, as per Section 3.11. 2054 Fault Management (FM) functions within the EMF of an MPLS-TP NE 2055 enable the supervision, detection, validation, isolation, correction, 2056 and alarm handling of abnormal conditions in the MPLS-TP network and 2057 its environment. FM needs to provide for the supervision of 2058 transmission (such as continuity, connectivity, etc.), software 2059 processing, hardware, and environment. Alarm handling includes alarm 2060 severity assignment, alarm suppression/aggregation/correlation, alarm 2061 reporting control, and alarm reporting. 2063 Configuration Management (CM) provides functions to control, 2064 identify, collect data from, and provide data to MPLS-TP NEs. In 2065 addition to general configuration for hardware, software protection 2066 switching, alarm reporting control, and date/time setting, the EMF of 2067 the MPLS-TP NE also supports the configuration of maintenance entity 2068 identifiers (such as Maintenance Entity Group Endpoint (MEP) ID and 2069 MEG Intermediate Point (MIP) ID). The EMF also supports the 2070 configuration of OAM parameters as a part of connectivity management 2071 to meet specific operational requirements. These may specify whether 2072 the operational mode is one-time on-demand or is periodic at a 2073 specified frequency. 2075 The Performance Management (PM) functions within the EMF of an 2076 MPLS-TP NE support the evaluation and reporting of the behaviour of 2077 the NEs and the network. One particular requirement for PM is to 2078 provide coherent and consistent interpretation of the network 2079 behaviour in a hybrid network that uses multiple transport 2080 technologies. Packet loss measurement and delay measurements may be 2081 collected and used to detect performance degradation. This is 2082 reported via fault management to enable corrective actions to be 2083 taken (e.g. protection switching), and via performance monitoring for 2084 Service Level Agreement (SLA) verification and billing. Collection 2085 mechanisms for performance data should be capable of operating on- 2086 demand or pro-actively. 2088 4. Security Considerations 2090 The introduction of MPLS-TP into transport networks means that the 2091 security considerations applicable to both MPLS and PWE3 apply to 2092 those transport networks. When an MPLS function is included in the 2093 MPLS transport profile, the security considerations pertinent to that 2094 function apply to MPLS-TP. Furthermore, when general MPLS networks 2095 that utilise functionality outside of the strict MPLS Transport 2096 Profile are used to support packet transport services, the security 2097 considerations of that additional functionality also apply. 2099 For pseudowires, the security considerations of [RFC3985] and 2100 [RFC5659] apply. 2102 MPLS-TP nodes that implement the G-ACh create a Control Channel (CC) 2103 associated with a pseudowire, LSP or section. This control channel 2104 can be signaled or statically configured. Over this control channel, 2105 control channel messages related to network maintenance functions 2106 such as OAM, signaling or network management are sent. Therefore, 2107 three different areas are of concern from a security standpoint. 2109 The first area of concern relates to control plane parameter and 2110 status message attacks, that is, attacks that concern the signaling 2111 of G-ACh capabilities. MPLS-TP Control Plane security is discussed 2112 in [I-D.ietf-mpls-mpls-and-gmpls-security-framework]. 2114 A second area of concern centers on data-plane attacks, that is, 2115 attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh 2116 mechanisms are subject to additional data-plane denial-of- service 2117 attacks as follows: 2119 An intruder could intercept or inject G-ACh packets effectively 2120 disrupting the protocols carried over the G-ACh. 2122 An intruder could deliberately flood a peer MPLS-TP node with 2123 G-ACh messages to deny services to others. 2125 A misconfigured or misbehaving device could inadvertently flood a 2126 peer MPLS-TP node with G-ACh messages which could result in denial 2127 of services. In particular, if a node has either implicitly or 2128 explicitly indicated that it cannot support one or all of the 2129 types of G-ACh protocol, but is sent those messages in sufficient 2130 quantity, it could result in a denial of service. 2132 To protect against these potential (deliberate or unintentional) 2133 attacks, multiple mitigation techniques can be employed: 2135 G-ACh message throttling mechanisms can be used, especially in 2136 distributed implementations which have a centralized control-plane 2137 processor with various line cards attached by some control-plane 2138 data path. In these architectures, G-ACh messages may be 2139 processed on the central processor after being forwarded there by 2140 the receiving line card. In this case, the path between the line 2141 card and the control processor may become saturated if appropriate 2142 G-ACh traffic throttling is not employed, which could lead to a 2143 complete denial of service to users of the particular line card. 2144 Such filtering is also useful for preventing the processing of 2145 unwanted G-ACh messages, such as those which are sent on unwanted 2146 (and perhaps unadvertised) control channel types. 2148 A third and last area of concern relates to the processing of the 2149 actual contents of G-ACh messages. It is necessary that the 2150 definition of the protocols using these messages carried over a G-ACh 2151 include appropriate security measures. 2153 Additional security considerations apply to each MPLS-TP solution. 2154 These are discussed further in [I-D.fang-mpls-tp-security-framework]. 2156 The security considerations in 2157 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] apply. 2159 5. IANA Considerations 2161 IANA considerations resulting from specific elements of MPLS-TP 2162 functionality will be detailed in the documents specifying that 2163 functionality. 2165 This document introduces no additional IANA considerations in itself. 2167 6. Acknowledgements 2169 The editors wish to thank the following for their contribution to 2170 this document: 2172 o Rahul Aggarwal 2174 o Dieter Beller 2176 o Malcolm Betts 2178 o Italo Busi 2180 o John E Drake 2182 o Hing-Kam Lam 2184 o Marc Lasserre 2186 o Vincenzo Sestito 2188 o Nurit Sprecher 2190 o Martin Vigoureux 2192 o Yaacov Weingarten 2194 o The participants of ITU-T SG15 2196 7. References 2197 7.1. Normative References 2199 [G.7710] "ITU-T 2200 Recommendation 2201 G.7710/Y.1701 2202 (07/07), "Common 2203 equipment 2204 management 2205 function 2206 requirements"", 2207 2005. 2209 [G.805] "ITU-T 2210 Recommendation 2211 G.805 (11/95), 2212 "Generic 2213 Functional 2214 Architecture of 2215 Transport 2216 Networks"", 2217 November 1995. 2219 [RFC3031] Rosen, E., 2220 Viswanathan, A., 2221 and R. Callon, 2222 "Multiprotocol 2223 Label Switching 2224 Architecture", 2225 RFC 3031, 2226 January 2001. 2228 [RFC3032] Rosen, E., Tappan, 2229 D., Fedorkow, G., 2230 Rekhter, Y., 2231 Farinacci, D., Li, 2232 T., and A. Conta, 2233 "MPLS Label Stack 2234 Encoding", 2235 RFC 3032, 2236 January 2001. 2238 [RFC3270] Le Faucheur, F., 2239 Wu, L., Davie, B., 2240 Davari, S., 2241 Vaananen, P., 2242 Krishnan, R., 2243 Cheval, P., and J. 2244 Heinanen, "Multi- 2245 Protocol Label 2246 Switching (MPLS) 2247 Support of 2248 Differentiated 2249 Services", 2250 RFC 3270, 2251 May 2002. 2253 [RFC3473] Berger, L., 2254 "Generalized 2255 Multi-Protocol 2256 Label Switching 2257 (GMPLS) Signaling 2258 Resource 2259 ReserVation 2260 Protocol-Traffic 2261 Engineering 2262 (RSVP-TE) 2263 Extensions", 2264 RFC 3473, 2265 January 2003. 2267 [RFC3985] Bryant, S. and P. 2268 Pate, "Pseudo Wire 2269 Emulation Edge-to- 2270 Edge (PWE3) 2271 Architecture", 2272 RFC 3985, 2273 March 2005. 2275 [RFC4090] Pan, P., Swallow, 2276 G., and A. Atlas, 2277 "Fast Reroute 2278 Extensions to 2279 RSVP-TE for LSP 2280 Tunnels", 2281 RFC 4090, 2282 May 2005. 2284 [RFC4385] Bryant, S., 2285 Swallow, G., 2286 Martini, L., and 2287 D. McPherson, 2288 "Pseudowire 2289 Emulation Edge-to- 2290 Edge (PWE3) 2291 Control Word for 2292 Use over an MPLS 2293 PSN", RFC 4385, 2294 February 2006. 2296 [RFC4447] Martini, L., 2297 Rosen, E., El- 2298 Aawar, N., Smith, 2299 T., and G. Heron, 2300 "Pseudowire Setup 2301 and Maintenance 2302 Using the Label 2303 Distribution 2304 Protocol (LDP)", 2305 RFC 4447, 2306 April 2006. 2308 [RFC4872] Lang, J., Rekhter, 2309 Y., and D. 2310 Papadimitriou, 2311 "RSVP-TE 2312 Extensions in 2313 Support of End-to- 2314 End Generalized 2315 Multi-Protocol 2316 Label Switching 2317 (GMPLS) Recovery", 2318 RFC 4872, 2319 May 2007. 2321 [RFC5085] Nadeau, T. and C. 2322 Pignataro, 2323 "Pseudowire 2324 Virtual Circuit 2325 Connectivity 2326 Verification 2327 (VCCV): A Control 2328 Channel for 2329 Pseudowires", 2330 RFC 5085, 2331 December 2007. 2333 [RFC5586] Bocci, M., 2334 Vigoureux, M., and 2335 S. Bryant, "MPLS 2336 Generic Associated 2337 Channel", 2338 RFC 5586, 2339 June 2009. 2341 7.2. Informative References 2343 [G.8080] "ITU-T 2344 Recommendation 2345 G.8080/Y.1304, 2346 "Architecture for 2347 the automatically 2348 switched optical 2349 network (ASON)"", 2350 2005. 2352 [I-D.fang-mpls-tp-security-framework] Fang, L. and B. 2353 Niven-Jenkins, 2354 "Security 2355 Framework for 2356 MPLS-TP", draft- 2357 fang-mpls-tp- 2358 security- 2359 framework-01 (work 2360 in progress), 2361 March 2010. 2363 [I-D.ietf-bfd-mpls] Aggarwal, R., 2364 Kompella, K., 2365 Nadeau, T., and G. 2366 Swallow, "BFD For 2367 MPLS LSPs", draft- 2368 ietf-bfd-mpls-07 2369 (work in 2370 progress), 2371 June 2008. 2373 [I-D.ietf-ccamp-mpls-tp-cp-framework] Andersson, L., 2374 Berger, L., Fang, 2375 L., Bitar, N., 2376 Takacs, A., 2377 Vigoureux, M., 2378 Bellagamba, E., 2379 and E. Gray, 2380 "MPLS-TP Control 2381 Plane Framework", 2382 draft-ietf-ccamp- 2383 mpls-tp-cp- 2384 framework-01 (work 2385 in progress), 2386 March 2010. 2388 [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., 2389 JOUNAY, F., Niven- 2390 Jenkins, B., 2391 Brungard, D., and 2392 L. Jin, "Framework 2393 and Requirements 2394 for Virtual 2395 Private Multicast 2396 Service (VPMS)", d 2397 raft-ietf-l2vpn- 2398 vpms-frmwk- 2399 requirements-02 2400 (work in 2401 progress), 2402 October 2009. 2404 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] Fang, L. and M. 2405 Behringer, 2406 "Security 2407 Framework for MPLS 2408 and GMPLS 2409 Networks", draft- 2410 ietf-mpls-mpls- 2411 and-gmpls- 2412 security- 2413 framework-09 (work 2414 in progress), 2415 March 2010. 2417 [I-D.ietf-mpls-tp-data-plane] Frost, D., Bryant, 2418 S., and M. Bocci, 2419 "MPLS Transport 2420 Profile Data Plane 2421 Architecture", dra 2422 ft-ietf-mpls-tp- 2423 data-plane-02 2424 (work in 2425 progress), 2426 April 2010. 2428 [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. 2429 Swallow, "MPLS-TP 2430 Identifiers", draf 2431 t-ietf-mpls-tp- 2432 identifiers-01 2433 (work in 2434 progress), 2435 March 2010. 2437 [I-D.ietf-mpls-tp-nm-framework] Mansfield, S., 2438 Gray, E., and H. 2439 Lam, "MPLS-TP 2440 Network Management 2441 Framework", draft- 2442 ietf-mpls-tp-nm- 2443 framework-05 (work 2444 in progress), 2445 February 2010. 2447 [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and 2448 K. Lam, "MPLS TP 2449 Network Management 2450 Requirements", dra 2451 ft-ietf-mpls-tp- 2452 nm-req-06 (work in 2453 progress), 2454 October 2009. 2456 [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, 2457 I., Niven-Jenkins, 2458 B., Fulignoli, A., 2459 Hernandez- 2460 Valencia, E., 2461 Levrau, L., Mohan, 2462 D., Sestito, V., 2463 Sprecher, N., 2464 Helvoort, H., 2465 Vigoureux, M., 2466 Weingarten, Y., 2467 and R. Winter, 2468 "MPLS-TP OAM 2469 Framework", draft- 2470 ietf-mpls-tp-oam- 2471 framework-06 (work 2472 in progress), 2473 April 2010. 2475 [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M. and 2476 D. Ward, 2477 "Requirements for 2478 OAM in MPLS 2479 Transport 2480 Networks", draft- 2481 ietf-mpls-tp-oam- 2482 requirements-06 2483 (work in 2484 progress), 2485 March 2010. 2487 [I-D.ietf-mpls-tp-rosetta-stone] Helvoort, H., 2488 Andersson, L., and 2489 N. Sprecher, "A 2490 Thesaurus for the 2491 Terminology used 2492 in Multiprotocol 2493 Label Switching 2494 Transport Profile 2495 (MPLS-TP) drafts/ 2496 RFCs and ITU-T's 2497 Transport Network 2498 Recommendations", 2499 draft-ietf-mpls- 2500 tp-rosetta-stone- 2501 01 (work in 2502 progress), 2503 October 2009. 2505 [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and 2506 A. Farrel, 2507 "Multiprotocol 2508 Label Switching 2509 Transport Profile 2510 Survivability 2511 Framework", draft- 2512 ietf-mpls-tp- 2513 survive-fwk-05 2514 (work in 2515 progress), 2516 April 2010. 2518 [I-D.ietf-opsawg-mpls-tp-oam-def] Andersson, L., 2519 Helvoort, H., 2520 Bonica, R., 2521 Romascanu, D., and 2522 S. Mansfield, 2523 ""The use of the 2524 OAM Acronym in 2525 MPLS-TP"", draft- 2526 ietf-opsawg-mpls- 2527 tp-oam-def-04 2528 (work in 2529 progress), 2530 April 2010. 2532 [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., 2533 Bocci, M., Balus, 2534 F., Bitar, N., 2535 Shah, H., 2536 Aissaoui, M., 2537 Rusmisel, J., 2538 Serbest, Y., 2539 Malis, A., Metz, 2540 C., McDysan, D., 2541 Sugimoto, J., 2542 Duckett, M., 2543 Loomis, M., 2544 Doolan, P., Pan, 2545 P., Pate, P., 2546 Radoaca, V., Wada, 2547 Y., and Y. Seo, 2548 "Dynamic Placement 2549 of Multi Segment 2550 Pseudo Wires", dra 2551 ft-ietf-pwe3- 2552 dynamic-ms-pw-10 2553 (work in 2554 progress), 2555 October 2009. 2557 [I-D.ietf-pwe3-redundancy] Muley, P. and V. 2558 Place, "Pseudowire 2559 (PW) Redundancy", 2560 draft-ietf-pwe3- 2561 redundancy-02 2562 (work in 2563 progress), 2564 October 2009. 2566 [I-D.ietf-pwe3-segmented-pw] Martini, L., 2567 Nadeau, T., Metz, 2568 C., Bocci, M., 2569 Aissaoui, M., 2570 Balus, F., and M. 2571 Duckett, 2572 "Segmented 2573 Pseudowire", draft 2574 -ietf-pwe3- 2575 segmented-pw-14 2576 (work in 2577 progress), 2578 April 2010. 2580 [I-D.ietf-pwe3-vccv-bfd] Nadeau, T. and C. 2582 Pignataro, 2583 "Bidirectional 2584 Forwarding 2585 Detection (BFD) 2586 for the Pseudowire 2587 Virtual Circuit 2588 Connectivity 2589 Verification 2590 (VCCV)", draft- 2591 ietf-pwe3-vccv- 2592 bfd-07 (work in 2593 progress), 2594 July 2009. 2596 [RFC3209] Awduche, D., 2597 Berger, L., Gan, 2598 D., Li, T., 2599 Srinivasan, V., 2600 and G. Swallow, 2601 "RSVP-TE: 2602 Extensions to RSVP 2603 for LSP Tunnels", 2604 RFC 3209, 2605 December 2001. 2607 [RFC3411] Harrington, D., 2608 Presuhn, R., and 2609 B. Wijnen, "An 2610 Architecture for 2611 Describing Simple 2612 Network Management 2613 Protocol (SNMP) 2614 Management 2615 Frameworks", 2616 STD 62, RFC 3411, 2617 December 2002. 2619 [RFC3443] Agarwal, P. and B. 2620 Akyol, "Time To 2621 Live (TTL) 2622 Processing in 2623 Multi-Protocol 2624 Label Switching 2625 (MPLS) Networks", 2626 RFC 3443, 2627 January 2003. 2629 [RFC3471] Berger, L., 2630 "Generalized 2631 Multi-Protocol 2632 Label Switching 2633 (GMPLS) Signaling 2634 Functional 2635 Description", 2636 RFC 3471, 2637 January 2003. 2639 [RFC3945] Mannie, E., 2640 "Generalized 2641 Multi-Protocol 2642 Label Switching 2643 (GMPLS) 2644 Architecture", 2645 RFC 3945, 2646 October 2004. 2648 [RFC4364] Rosen, E. and Y. 2649 Rekhter, "BGP/MPLS 2650 IP Virtual Private 2651 Networks (VPNs)", 2652 RFC 4364, 2653 February 2006. 2655 [RFC4377] Nadeau, T., 2656 Morrow, M., 2657 Swallow, G., 2658 Allan, D., and S. 2659 Matsushima, 2660 "Operations and 2661 Management (OAM) 2662 Requirements for 2663 Multi-Protocol 2664 Label Switched 2665 (MPLS) Networks", 2666 RFC 4377, 2667 February 2006. 2669 [RFC4379] Kompella, K. and 2670 G. Swallow, 2671 "Detecting Multi- 2672 Protocol Label 2673 Switched (MPLS) 2674 Data Plane 2675 Failures", 2676 RFC 4379, 2677 February 2006. 2679 [RFC4664] Andersson, L. and 2680 E. Rosen, 2681 "Framework for 2682 Layer 2 Virtual 2683 Private Networks 2684 (L2VPNs)", 2685 RFC 4664, 2686 September 2006. 2688 [RFC4726] Farrel, A., 2689 Vasseur, J., and 2690 A. Ayyangar, "A 2691 Framework for 2692 Inter-Domain 2693 Multiprotocol 2694 Label Switching 2695 Traffic 2696 Engineering", 2697 RFC 4726, 2698 November 2006. 2700 [RFC4741] Enns, R., "NETCONF 2701 Configuration 2702 Protocol", 2703 RFC 4741, 2704 December 2006. 2706 [RFC5150] Ayyangar, A., 2707 Kompella, K., 2708 Vasseur, JP., and 2709 A. Farrel, "Label 2710 Switched Path 2711 Stitching with 2712 Generalized 2713 Multiprotocol 2714 Label Switching 2715 Traffic 2716 Engineering (GMPLS 2717 TE)", RFC 5150, 2718 February 2008. 2720 [RFC5254] Bitar, N., Bocci, 2721 M., and L. 2722 Martini, 2723 "Requirements for 2724 Multi-Segment 2725 Pseudowire 2726 Emulation Edge-to- 2727 Edge (PWE3)", 2728 RFC 5254, 2729 October 2008. 2731 [RFC5309] Shen, N. and A. 2732 Zinin, "Point-to- 2733 Point Operation 2734 over LAN in Link 2735 State Routing 2736 Protocols", 2737 RFC 5309, 2738 October 2008. 2740 [RFC5331] Aggarwal, R., 2741 Rekhter, Y., and 2742 E. Rosen, "MPLS 2743 Upstream Label 2744 Assignment and 2745 Context-Specific 2746 Label Space", 2747 RFC 5331, 2748 August 2008. 2750 [RFC5654] Niven-Jenkins, B., 2751 Brungard, D., 2752 Betts, M., 2753 Sprecher, N., and 2754 S. Ueno, 2755 "Requirements of 2756 an MPLS Transport 2757 Profile", 2758 RFC 5654, 2759 September 2009. 2761 [RFC5659] Bocci, M. and S. 2762 Bryant, "An 2763 Architecture for 2764 Multi-Segment 2765 Pseudowire 2766 Emulation Edge-to- 2767 Edge", RFC 5659, 2768 October 2009. 2770 [RFC5718] Beller, D. and A. 2771 Farrel, "An In- 2772 Band Data 2773 Communication 2774 Network For the 2775 MPLS Transport 2776 Profile", 2777 RFC 5718, 2778 January 2010. 2780 [X.200] "ITU-T 2781 Recommendation 2782 X.200, 2783 "Information 2784 Technology - Open 2785 Systems 2786 Interconnection - 2787 Basic reference 2788 Model: The Basic 2789 Model"", 1994. 2791 Authors' Addresses 2793 Matthew Bocci (editor) 2794 Alcatel-Lucent 2795 Voyager Place, Shoppenhangers Road 2796 Maidenhead, Berks SL6 2PJ 2797 United Kingdom 2799 Phone: 2800 EMail: matthew.bocci@alcatel-lucent.com 2802 Stewart Bryant (editor) 2803 Cisco Systems 2804 250 Longwater Ave 2805 Reading RG2 6GB 2806 United Kingdom 2808 Phone: 2809 EMail: stbryant@cisco.com 2811 Dan Frost (editor) 2812 Cisco Systems 2814 Phone: 2815 Fax: 2816 EMail: danfrost@cisco.com 2817 URI: 2819 Lieven Levrau 2820 Alcatel-Lucent 2821 7-9, Avenue Morane Sulnier 2822 Velizy 78141 2823 France 2825 Phone: 2826 EMail: lieven.levrau@alcatel-lucent.com 2828 Lou Berger 2829 LabN 2831 Phone: +1-301-468-9228 2832 Fax: 2833 EMail: lberger@labn.net 2834 URI: