idnits 2.17.1 draft-ietf-mpls-tp-framework-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 395 has weird spacing: '...Example a) [...' == Line 418 has weird spacing: '...Example a) [...' -- The document date (January 28, 2010) is 5195 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Ethernet' is mentioned on line 418, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-vpms-frmwk-requirements-02 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-tp-nm-framework-04 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-04 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-04 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-02 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-13 -- 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: 2 errors (**), 0 flaws (~~), 10 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: August 1, 2010 D. Frost 6 Cisco Systems 7 L. Levrau 8 Alcatel-Lucent 9 L. Berger 10 LabN 11 January 28, 2010 13 A Framework for MPLS in Transport Networks 14 draft-ietf-mpls-tp-framework-09 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 signalled or explicitly 24 provisioned bi-directional 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 paths. The remaining subset, applicable 34 specifically to point-to-multipoint paths, are out of scope of this 35 document. 37 This document is a product of a joint Internet Engineering Task Force 38 (IETF) / International Telecommunications Union Telecommunications 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 Status of This Memo 46 This Internet-Draft is submitted to IETF in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF), its areas, and its working groups. Note that 51 other groups may also distribute working documents as Internet- 52 Drafts. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 The list of current Internet-Drafts can be accessed at 60 http://www.ietf.org/ietf/1id-abstracts.txt. 62 The list of Internet-Draft Shadow Directories can be accessed at 63 http://www.ietf.org/shadow.html. 65 This Internet-Draft will expire on August 1, 2010. 67 Copyright Notice 69 Copyright (c) 2010 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 1.1. Motivation and Background . . . . . . . . . . . . . . . . 4 86 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 88 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6 89 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 90 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7 91 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7 92 1.3.5. MPLS-TP Label Switching Router (LSR) and Label 93 Edge Router (LER) . . . . . . . . . . . . . . . . . . 7 94 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8 95 1.3.7. Edge-to-Edge LSP . . . . . . . . . . . . . . . . . . . 8 96 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 8 97 1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 8 98 1.3.10. Additional Definitions and Terminology . . . . . . . . 8 99 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 9 100 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11 101 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12 102 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12 103 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13 104 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14 105 3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14 106 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15 107 3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16 108 3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17 109 3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 18 110 3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21 111 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25 112 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25 113 3.7. Operations, Administration and Maintenance (OAM) . . . . . 28 114 3.8. LSP Return Path . . . . . . . . . . . . . . . . . . . . . 30 115 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 31 116 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 31 117 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 32 118 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 32 119 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 32 120 3.10. Inter-domain Connectivity . . . . . . . . . . . . . . . . 34 121 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35 122 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 35 123 3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 36 124 3.13.1. Provisioning of PST . . . . . . . . . . . . . . . . . 37 125 3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 38 126 3.15. Network Management . . . . . . . . . . . . . . . . . . . . 38 127 4. Security Considerations . . . . . . . . . . . . . . . . . . . 39 128 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 129 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 130 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40 131 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 132 8.1. Normative References . . . . . . . . . . . . . . . . . . . 40 133 8.2. Informative References . . . . . . . . . . . . . . . . . . 43 135 1. Introduction 137 1.1. Motivation and Background 139 This document describes an architectural framework for the 140 application of MPLS to the construction of packet-switched transport 141 networks. It specifies the common set of protocol functions that 142 meet the requirements in [RFC5654], and that together constitute the 143 MPLS Transport Profile (MPLS-TP) for point-to-point paths. The 144 remaining MPLS-TP functions, applicable specifically to point-to- 145 multipoint paths, are out of scope of this document. 147 Historically the optical transport infrastructure - Synchronous 148 Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical 149 Transport Network (OTN) - has provided carriers with a high benchmark 150 for reliability and operational simplicity. To achieve this, 151 transport technologies have been designed with specific 152 characteristics: 154 o Strictly connection-oriented connectivity, which may be long-lived 155 and may be provisioned manually (i.e. configuration of the node 156 via a command line interface) or by network management. 158 o A high level of availability. 160 o Quality of service. 162 o Extensive OAM capabilities. 164 Carriers wish to evolve such transport networks to take advantage of 165 the flexibility and cost benefits of packet switching technology and 166 to support packet based services more efficiently. While MPLS is a 167 maturing packet technology that already plays an important role in 168 transport networks and services, not all MPLS capabilities and 169 mechanisms are needed in or consistent with the transport network 170 operational model. There are also transport technology 171 characteristics that are not currently reflected in MPLS. 173 There are thus two objectives for MPLS-TP: 175 1. To enable MPLS to be deployed in a transport network and operated 176 in a similar manner to existing transport technologies. 178 2. To enable MPLS to support packet transport services with a 179 similar degree of predictability to that found in existing 180 transport networks. 182 In order to achieve these objectives, there is a need to define a 183 common set of MPLS protocol functions - an MPLS Transport Profile - 184 for the use of MPLS in transport networks and applications. Some of 185 the necessary functions are provided by existing MPLS specifications, 186 while others require additions to the MPLS tool-set. Such additions 187 should, wherever possible, be applicable to MPLS networks in general 188 as well as those that conform strictly to the transport network 189 model. 191 This document is a product of a joint Internet Engineering Task Force 192 (IETF) / International Telecommunications Union Telecommunications 193 Standardization Sector (ITU-T) effort to include an MPLS Transport 194 Profile within the IETF MPLS and PWE3 architectures to support the 195 capabilities and functionalities of a packet transport network as 196 defined by the ITU-T. 198 1.2. Scope 200 This document describes an architectural framework for the 201 application of MPLS to the construction of packet-switched transport 202 networks. It specifies the common set of protocol functions that 203 meet the requirements in [RFC5654], and that together constitute the 204 MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport 205 paths. The remaining MPLS-TP functions, applicable specifically to 206 point-to-multipoint transport paths, are out of scope of this 207 document. 209 1.3. Terminology 211 Term Definition 212 ---------- ---------------------------------------------------------- 213 LSP Label Switched Path 214 MPLS-TP MPLS Transport Profile 215 SDH Synchronous Digital Hierarchy 216 ATM Asynchronous Transfer Mode 217 OTN Optical Transport Network 218 cl-ps Connectionless - Packet Switched 219 co-cs Connection Oriented - Circuit Switched 220 co-ps Connection Oriented - Packet Switched 221 OAM Operations, Administration and Maintenance 222 G-ACh Generic Associated Channel 223 GAL Generic Alert Label 224 MEP Maintenance End Point 225 MIP Maintenance Intermediate Point 226 APS Automatic Protection Switching 227 SCC Signalling Communication Channel 228 MCC Management Communication Channel 229 EMF Equipment Management Function 230 FM Fault Management 231 CM Configuration Management 232 PM Performance Management 233 LSR Label Switching Router 234 MPLS-TP PE MPLS-TP Provider Edge LSR 235 MPLS-TP P MPLS-TP Provider LSR 236 PW Pseudowire 237 Adaptation The mapping of client information into a format suitable 238 for transport by the server layer 239 Native The traffic belonging to the client of the MPLS-TP network 240 Service 241 T-PE PW Terminating Provider Edge 242 S-PE PW Switching provider Edge 244 1.3.1. Transport Network 246 A Transport Network provides transparent transmission of client user 247 plane traffic between attached client devices by establishing and 248 maintaining point-to-point or point-to-multipoint connections between 249 such devices. The architecture of networks supporting point to 250 multipoint connections is out of scope of this document. A Transport 251 Network is independent of any higher-layer network that may exist 252 between clients, except to the extent required to supply this 253 transmission service. In addition to client traffic, a Transport 254 Network may carry traffic to facilitate its own operation, such as 255 that required to support connection control, network management, and 256 Operations, Administration and Maintenance (OAM) functions. 258 See also the definition of Packet Transport Service in Section 3.1. 260 1.3.2. MPLS Transport Profile 262 The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions 263 that meet the requirements in [RFC5654]. Note that MPLS is defined 264 to include any present and future MPLS capability specified by the 265 IETF, including those capabilities specifically added to support 266 transport network requirements [RFC5654]. 268 1.3.3. MPLS-TP Section 270 An MPLS-TP Section is defined in Section 1.2.2 of [RFC5654]. 272 1.3.4. MPLS-TP Label Switched Path 274 An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a 275 subset of the capabilities of an MPLS LSP in order to meet the 276 requirements of an MPLS transport network as set out in [RFC5654]. 277 The characteristics of an MPLS-TP LSP are primarily that it: 279 1. Uses a subset of the MPLS OAM tools defined as described in 280 [I-D.ietf-mpls-tp-oam-framework]. 282 2. Supports 1+1, 1:1, and 1:N protection functions. 284 3. Is traffic engineered. 286 4. May be established and maintained via the management plane, or 287 using GMPLS protocols when a control plane is used. 289 5. Is either point-to-point or point-to-multipoint. Multipoint to 290 point and multipoint to multipoint LSPs are not permitted. 292 Note that an MPLS LSP is defined to include any present and future 293 MPLS capability, including those specifically added to support the 294 transport network requirements. 296 1.3.5. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER) 298 An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider 299 Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP, 300 as defined below. The terms MPLS-TP PE router and MPLS-TP P router 301 describe logical functions; a specific node may undertake only one of 302 these roles on a given LSP. 304 Note that the use of the term "router" in this context is historic 305 and neither requires nor precludes the ability to perform IP 306 forwarding. 308 1.3.5.1. MPLS-TP Provider Edge (PE) Router 310 An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts 311 client traffic and encapsulates it to be transported over an MPLS-TP 312 LSP. Encapsulation may be as simple as pushing a label, or it may 313 require the use of a pseudowire. An MPLS-TP PE exists at the 314 interface between a pair of layer networks. For an MS-PW, an MPLS-TP 315 PE may be either an S-PE or a T-PE, as defined in [RFC5659]. 317 1.3.5.2. MPLS-TP Provider (P) Router 319 An MPLS-TP Provider router is an MPLS-TP LSR that does not provide 320 MPLS-TP PE functionality for a given LSP. An MPLS-TP P router 321 switches LSPs which carry client traffic, but does not adapt client 322 traffic and encapsulate it to be carried over an MPLS-TP LSP. 324 1.3.5.3. Label Edge Router (LER) 326 An LSR that exists at the endpoints of an LSP and therefore pushes or 327 pops a label, i.e. does not perform a label swap on the particular 328 LSP under consideration. 330 1.3.6. Customer Edge (CE) 332 A Customer Edge (CE) is the client function sourcing or sinking 333 native service traffic to or from the MPLS-TP network. CEs on either 334 side of the MPLS-TP network are peers and view the MPLS-TP network as 335 a single point-to-point or point-to-multipoint link. 337 1.3.7. Edge-to-Edge LSP 339 An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit 340 zero of more provider LSRs. 342 1.3.8. Service LSP 344 A service LSP is an LSP that caries a single client service. 346 1.3.9. Layer Network 348 A layer network is defined in [G.805] and described in [RFC5654]. 350 1.3.10. Additional Definitions and Terminology 352 Detailed definitions and additional terminology may be found in 353 [RFC5654]. 355 1.4. Applicability 357 MPLS-TP can be used to construct packet transport networks and is 358 therefore applicable in any packet transport network context. It is 359 also applicable to subsets of a packet network where the transport 360 network operational model is deemed attractive. The following are 361 examples of MPLS-TP applicability models: 363 1. MPLS-TP provided by a network that only supports MPLS-TP LSPs and 364 PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or 365 LSRs), acting as a server for other layer 1, layer 2 and layer 3 366 networks (Figure 1). 368 2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs 369 and PWs (i.e. both LSPs and PWs that conform to the transport 370 profile and those that do not, exist between the PEs), acting as 371 a server for other layer 1, layer 2 and layer 3 networks 372 (Figure 2). 374 3. MPLS-TP as a server layer for client layer traffic of IP or MPLS 375 networks which do not use functions of the MPLS transport 376 profile. For MPLS traffic, the MPLS-TP server layer network uses 377 PW switching [RFC5659] or LSP stitching [RFC5150] at the PE that 378 terminates the MPLS-TP server layer (Figure 3). 380 These models are not mutually exclusive. 382 MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as 383 a server for other layer 1, layer 2 and layer 3 networks. 385 |<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->| 386 Only 388 MPLS-TP 389 +---+ LSP +---+ 390 +---+ Client | |----------| | Client +---+ 391 |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1| 392 +---+ | |----------| | +---+ 393 +---+ +---+ 395 Example a) [Ethernet] [Ethernet] [Ethernet] 396 layering [ PW ] 397 [-TP LSP ] 399 b) [ IP ] [ IP ] [ IP ] 400 [ Demux ] 401 [-TP LSP ] 403 Figure 1: MPLS-TP Server Layer Example 405 MPLS-TP LSP, provided by a network that also supports non-MPLS-TP 406 functions, acting as a server for other layer 1, layer 2 and 407 layer 3 networks. 409 |<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->| 411 MPLS-TP 412 +---+ LSP +---+ 413 +---+ Client | |----------| | Client +---+ 414 |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1| 415 +---+ | |----------| | +---+ 416 +---+ +---+ 418 Example a) [Ethernet] [Ethernet] [Ethernet] 419 layering [ PW ] 420 [-TP LSP ] 422 b) [ IP ] [ IP ] [ IP ] 423 [ Demux ] 424 [-TP LSP ] 426 Figure 2: MPLS-TP in MPLS Network Example 428 MPLS-TP as a server layer for client layer traffic of IP or MPLS 429 networks which do not use functions of the MPLS transport 430 profile. 432 |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| 433 Only 435 +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ 436 |CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2| 437 +---+ +----+ +----+ +----+ +----+ +---+ 438 (PW switching) (PW switching) 440 (a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ] 441 [ PW Seg ] [ PW Seg ] [ PW Seg ] 442 [ LSP ] [-TP LSP ] [ LSP ] 444 |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| 445 Only 447 +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ 448 |CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2| 449 +---+ +----+ +----+ +----+ +----+ +---+ 450 (LSP stitching) (LSP stitching) 452 (b) [ IP ] [ IP ] [ IP ] [ IP ] [ IP ] 453 [ LSP ] [-TP LSP ] [ LSP ] 455 Figure 3: MPLS-TP Transporting Client Service Traffic 457 2. MPLS Transport Profile Requirements 459 The requirements for MPLS-TP are specified in [RFC5654], 460 [I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req]. 461 This section provides a brief reminder to guide the reader and is 462 therefore not normative. It is not intended as a substitute for 463 these documents. 465 MPLS-TP must not modify the MPLS forwarding architecture and must be 466 based on existing pseudowire and LSP constructs. 468 Point to point LSPs may be unidirectional or bi-directional, and it 469 must be possible to construct congruent Bi-directional LSPs. 471 MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it 472 must be possible to detect if a merged LSP has been created. 474 It must be possible to forward packets solely based on switching the 475 MPLS or PW label. It must also be possible to establish and maintain 476 LSPs and/or pseudowires both in the absence or presence of a dynamic 477 control plane. When static provisioning is used, there must be no 478 dependency on dynamic routing or signalling. 480 OAM, protection and forwarding of data packets must be able to 481 operate without IP forwarding support. 483 It must be possible to monitor LSPs and pseudowires through the use 484 of OAM in the absence of control plane or routing functions. In this 485 case information gained from the OAM functions is used to initiate 486 path recovery actions at either the PW or LSP layers. 488 3. MPLS Transport Profile Overview 490 3.1. Packet Transport Services 492 One objective of MPLS-TP is to enable MPLS networks to provide packet 493 transport services with a similar degree of predictability to that 494 found in existing transport networks. Such packet transport services 495 inherit a number of characteristics, defined in [RFC5654]: 497 o In an environment where an MPLS-TP layer network is supporting a 498 client layer network, and the MPLS-TP layer network is supported 499 by a server layer network then operation of the MPLS-TP layer 500 network must be possible without any dependencies on either the 501 server or client layer network. 503 o The service provided by the MPLS-TP network to the client is 504 guaranteed not to fall below the agreed level regardless of other 505 client activity. 507 o The control and management planes of any client network layer that 508 uses the service is isolated from the control and management 509 planes of the MPLS-TP layer network, where the client network 510 layer is considered to be the native service of the MPLS-TP 511 network. 513 o Where a client network makes use of an MPLS-TP server that 514 provides a packet transport service, the level of co-ordination 515 required between the client and server layer networks is minimal 516 (preferably no co-ordination will be required). 518 o The complete set of packets generated by a client MPLS(-TP) layer 519 network using the packet transport service, which may contain 520 packets that are not MPLS packets (e.g. IP or CLNS packets used 521 by the control/management plane of the client MPLS(-TP) layer 522 network), are transported by the MPLS-TP server layer network. 524 o The packet transport service enables the MPLS-TP layer network 525 addressing and other information (e.g. topology) to be hidden from 526 any client layer networks using that service, and vice-versa. 528 These characteristics imply that a packet transport service does not 529 support a connectionless packet-switched forwarding mode. However, 530 this does not preclude it carrying client traffic associated with a 531 connectionless service. 533 Such packet transport services are very similar to Layer 2 Virtual 534 Private Networks as defined by the IETF. 536 3.2. Scope of the MPLS Transport Profile 538 Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are 539 primarily intended for packet transport applications. MPLS-TP is a 540 strict subset of MPLS, and comprises only those functions that are 541 necessary to meet the requirements of [RFC5654]. This includes MPLS 542 functions that were defined prior to [RFC5654] but that meet the 543 requirements of [RFC5654], together with additional functions defined 544 to meet those requirements. Some MPLS functions defined before 545 [RFC5654] such as Equal Cost Multi-Path, LDP signalling used in such 546 a way that it creates multipoint-to-point LSPs, and IP forwarding in 547 the data plane are explicitly excluded from MPLS-TP by that 548 requirements specification. 550 Note that MPLS as a whole will continue to evolve to include 551 additional functions that do not conform to the MPLS Transport 552 Profile or its requirements, and thus fall outside the scope of 553 MPLS-TP. 555 |<============================== MPLS ==============================>| 557 |<============= Pre-RFC5654 MPLS ================>| 558 { ECMP } 559 { LDP/non-TE LSPs } 560 { IP fwd } 562 |<================ MPLS-TP ====================>| 563 { Additional } 564 { Transport } 565 { Functions } 567 Figure 4: Scope of MPLS-TP 569 3.3. Architecture 571 MPLS-TP comprises the following architectural elements: 573 o A standard MPLS data plane [RFC3031] as profiled in 574 [draft-fbb-mpls-tp-data-plane]. 576 o Sections, LSPs and PWs that provide a packet transport service for 577 a client network. 579 o Proactive and on-demand Operations, Administration and Maintenance 580 (OAM) functions to monitor and diagnose the MPLS-TP network, such 581 as connectivity check, connectivity verification, performance 582 monitoring and fault localisation. 584 o Optional control planes for LSPs and PWs, as well as support for 585 static provisioning and configuration. 587 o Optional path protection mechanisms to ensure that the packet 588 transport service survives anticipated failures and degradations 589 of the MPLS-TP network. 591 o Network management functions. 593 The MPLS-TP architecture for LSPs and PWs includes the following two 594 sets of functions: 596 o MPLS-TP client adaptation 598 o MPLS-TP forwarding 600 The adaptation functions interface the native service to MPLS-TP. 601 This includes the case where the native service is an MPLS-TP LSP. 603 The forwarding functions comprise the mechanisms required for 604 forwarding the encapsulated client traffic over an MPLS-TP server 605 layer network, for example PW and LSP labels. 607 3.3.1. MPLS-TP Client Adaptation Functions 609 The MPLS-TP native service adaptation functions interface the client 610 service to MPLS-TP. For pseudowires, these adaptation functions are 611 the payload encapsulation described in Section 4.4 of [RFC3985] and 612 Section 6 of [RFC5659]. For network layer client services, the 613 adaptation function uses the MPLS encapsulation format as defined in 614 [RFC3032]. 616 The purpose of this encapsulation is to abstract the client service 617 data plane from the MPLS-TP data plane, thus contributing to the 618 independent operation of the MPLS-TP network. 620 MPLS-TP is itself a client of an underlying server layer. MPLS-TP is 621 thus also bounded by a set of adaptation functions to this server 622 layer network, which may itself be MPLS-TP. These adaptation 623 functions provide encapsulation of the MPLS-TP frames and for the 624 transparent transport of those frames over the server layer network. 625 The MPLS-TP client inherits its Quality of Service (QoS) from the 626 MPLS-TP network, which in turn inherits its QoS from the server 627 layer. The server layer must therefore provide the necessary QoS to 628 ensure that the MPLS-TP client QoS commitments can be satisfied. 630 3.3.2. MPLS-TP Forwarding Functions 632 The forwarding functions comprise the mechanisms required for 633 forwarding the encapsulated client over an MPLS-TP server layer 634 network, for example PW and LSP labels. 636 MPLS-TP LSPs use the MPLS label switching operations and TTL 637 processing procedures defined in [RFC3031] and [RFC3032]. These 638 operations are highly optimised for performance and are not modified 639 by the MPLS-TP profile. 641 In addition, MPLS-TP PWs use the SS-PW and MS-PW forwarding 642 operations defined in [RFC3985] and [RFC5659]. The PW label is 643 processed by a PW forwarder and is always at the bottom of the label 644 stack for a given MPLS-TP layer network. 646 Per-platform label space is used for PWs. Either per-platform, per- 647 interface or other context-specific label space [RFC5331] may be used 648 for LSPs. 650 MPLS-TP forwarding is based on the label that identifies the 651 transport path (LSP or PW). The label value specifies the processing 652 operation to be performed by the next hop at that level of 653 encapsulation. A swap of this label is an atomic operation in which 654 the contents of the packet after the swapped label are opaque to the 655 forwarder. The only event that interrupts a swap operation is TTL 656 expiry. This is a fundamental architectural construct of MPLS to be 657 taken into account when designing protocol extensions that require 658 packets (e.g. OAM packets) to be sent to an intermediate LSR. 660 Further processing to determine the context of a packet occurs when a 661 swap operation is interrupted in this manner, or a pop operation 662 exposes a specific reserved label at the top of the stack, or the 663 packet is received with the GAL Section 3.6 at the top of stack. 665 Otherwise the packet is forwarded according to the procedures in 666 [RFC3032]. 668 Point-to-point MPLS-TP LSPs can be either unidirectional or 669 bidirectional. 671 It must be possible to configure an MPLS-TP LSP such that the forward 672 and backward directions of a bidirectional MPLS-TP LSP are co-routed, 673 i.e. follow the same path. The pairing relationship between the 674 forward and the backward directions must be known at each LSR or LER 675 on a bidirectional LSP. 677 In normal conditions, all the packets sent over a PW or an LSP follow 678 the same path through the network and those that belong to a common 679 ordered aggregate are delivered in order. For example per-packet 680 equal cost multi-path (ECMP) load balancing is not applicable to 681 MPLS-TP LSPs. 683 Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default. 685 MPLS-TP supports Quality of Service capabilities via the MPLS 686 Differentiated Services (DiffServ) architecture [RFC3270]. Both 687 E-LSP and L-LSP MPLS DiffServ modes are supported. The Traffic Class 688 field (formerly the EXP field) of an MPLS label follows the 689 definition and processing rules of [RFC5462] and [RFC3270]. Note 690 that packet reordering between flows belonging to different traffic 691 classes may occur if more than one traffic class is supported on a 692 single LSP. 694 Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing 695 models described in [RFC3270] and [RFC3443] are supported in MPLS-TP. 697 3.4. MPLS-TP Native Services 699 This document describes the architecture for two types of native 700 service adaptation: 702 o A PW: PW Demultiplexer and PW encapsulation 704 o An MPLS Label (for example carrying a layer 2 VPN [RFC4664], a 705 layer 3 VPN [RFC4364], or a TE-LSP [RFC3209]) 707 o An IP packet 709 A PW provides any emulated service that the IETF has defined to be 710 provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A 711 registry of PW types is maintained by IANA. When the client 712 adaptation is via a PW, the mechanisms described in Section 3.4.2 are 713 used. 715 An MPLS LSP Label can also be used as the adaptation, in which case 716 any client supported by [RFC3031] is allowed, for example a MPLS LSP, 717 PW, or IP. When the client adaptation is via an MPLS label, the 718 mechanisms described in Section 3.4.3 are used. 720 3.4.1. MPLS-TP Client/Server Relationship 722 The MPLS-TP client server relationship is defined by the MPLS-TP 723 network boundary and the label context. It is not explicitly 724 indicated in the packet. In terms of the MPLS label stack, when the 725 client traffic type of the MPLS-TP network is an MPLS LSP or a PW, 726 then the S bits of all the labels in the MPLS-TP label stack carrying 727 that client traffic are zero; otherwise the bottom label of the 728 MPLS-TP label stack has the S bit set to one (i.e. there can only one 729 S bit set in a label stack). 731 The data plane behaviour of MPLS-TP is the same as the best current 732 practise for MPLS. This includes the setting of the S-Bit. In each 733 case, the S-bit is set to indicate the bottom (i.e. inner-most) label 734 in the label stack that is contiguous between the MPLS-TP server and 735 the client layer. Note that this best current practise differs 736 slightly from [RFC3032] which uses the S-bit to identify when MPLS 737 label processing stops and network layer processing starts. 739 The relationship of MPLS-TP to its clients is illustrated in 740 Figure 5. 742 PW-Based MPLS Labelled IP 743 Services Services Transport 744 |------------| |-----------------------------| |------------| 746 Emulated PW over LSP IP over LSP IP 747 Service 748 +------------+ 749 | PW Payload | 750 +------------+ +------------+ (CLIENTS) 751 |PW Lbl(S=1) | | IP | 752 +------------+ +------------+ +------------+ +------------+ 753 | PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP | 754 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 755 |PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)| 756 +------------+ +------------+ +------------+ +------------+ 757 |LSP Lbl(S=0)| 758 +------------+ (MPLS-TP) 760 ~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary 762 Note that in the PW over LSP case the client may omit its LSP Label if 764 penultimate hop popping has been agreed with its peer 766 Figure 5: MPLS-TP - Client Relationship 768 The data plane behaviour of MPLS-TP is the same as the best current 769 practise for MPLS. This includes the setting of the S-Bit. In each 770 case, the S-bit is set to indicate the bottom (i.e. inner-most) label 771 in the label stack that is contiguous between the MPLS-TP server and 772 the client layer. 774 Note that the label stacks shown above are divided between those 775 inside the MPLS-TP Network and those within the client network when 776 the client network is MPLS(-TP). They illustrate the smallest number 777 of labels possible. These label stacks could also include more 778 labels. 780 3.4.2. Pseudowire Adaptation 782 The architecture for an MPLS-TP network that provides PW emulated 783 services is based on the MPLS [RFC3031] and pseudowire [RFC3985] 784 architectures. Multi-segment pseudowires may optionally be used to 785 provide a packet transport service, and their use is consistent with 786 the MPLS-TP architecture. The use of MS-PWs may be motivated by, for 787 example, the requirements specified in [RFC5254]. If MS-PWs are 788 used, then the MS-PW architecture [RFC5659] also applies. 790 Figure 6 shows the architecture for an MPLS-TP network using single- 791 segment PWs. 793 |<--------------- Emulated Service ----------------->| 794 | | 795 | |<-------- Pseudowire -------->| | 796 | | encapsulated, packet | | 797 | | transport service | | 798 | | | | 799 | | |<------ LSP ------->| | | 800 | V V V V | 801 V AC +----+ +-----+ +----+ AC V 802 +-----+ | | PE1|=======\ /========| PE2| | +-----+ 803 | |----------|.......PW1.| \ / |............|----------| | 804 | CE1 | | | | | X | | | | | CE2 | 805 | |----------|.......PW2.| / \ |............|----------| | 806 +-----+ ^ | | |=======/ \========| | | ^ +-----+ 807 ^ | +----+ +-----+ +----+ | ^ 808 | | Provider Edge 1 ^ Provider Edge 2 | | 809 | | | | | 810 Customer | P Router | Customer 811 Edge 1 | | Edge 2 812 | | 813 | | 814 Native service Native service 816 Figure 6: MPLS-TP Architecture (Single Segment PW) 818 Figure 7 shows the architecture for an MPLS-TP network when multi- 819 segment pseudowires are used. Note that as in the SS-PW case, 820 P-routers may also exist. 822 |<----------- Pseudowire encapsulated ------------->| 823 | packet transport service | 824 | | 825 | | 826 | | 827 AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC 828 | V V V V V V | 829 | +----+ +-----+ +----+ +----+ | 830 +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ 831 | |---|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|---| | 832 |CE1| | | | | X | | | | | | |CE2| 833 | |---|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|---| | 834 +---+ | | |===============/ \=====| |==========| | | +---+ 835 ^ +----+ ^ +-----+ +----+ ^ +----+ ^ 836 | | ^ | | 837 | TE LSP | TE LSP | 838 | P-router | 839 | | 840 |<-------------------- Emulated Service ------------------->| 842 PW1-segment1 and PW1-segment2 are segments of the same MS-PW, 843 while PW2-segment1 and PW2-segment2 are segments of another MS-PW 845 Figure 7: MPLS-TP Architecture (Multi-Segment PW) 847 The corresponding MPLS-TP protocol stacks including PWs are shown in 848 Figure 8. In this figure protocol the Transport Service Layer 849 [RFC5654] is identified by the PW demultiplexer (Demux) label and the 850 Transport Path Layer [RFC5654] is identified by the LSP Demux Label. 852 +-------------------+ /===================\ /===================\ 853 | Client Layer | H OAM PDU H H OAM PDU H 854 /===================\ H-------------------H H-------------------H 855 H PW Encap H H GACh H H GACh H 856 H-------------------H H-------------------H H-------------------H 857 H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H 858 H-------------------H H-------------------H H-------------------H 859 H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H 860 \===================/ \===================/ \===================/ 861 | Server Layer | | Server Layer | | Server Layer | 862 +-------------------+ +-------------------+ +-------------------+ 864 User Traffic PW OAM LSP OAM 866 Note: H(ighlighted) indicates the part of the protocol stack we are 867 considering in this document. 869 Figure 8: MPLS-TP Layer Network using Pseudowires 871 PWs and their underlying labels may be configured or signaled. See 872 Section 3.11 for additional details related to configured service 873 types. See Section 3.9 for additional details related to signaled 874 service types. 876 3.4.2.1. Pseudowire Bases Services 878 When providing a Virtual Private Wire Service (VPWS) , Virtual 879 Private Local Area Network Service (VPLS), Virtual Private Multicast 880 Service (VPMS) or Internet Protocol Local Area Network Service (IPLS) 881 pseudowires must be used to carry the client service. VPWS, VLPS, 882 and IPLS are described in [RFC4664]. VPMS is described in 883 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 885 3.4.3. Network Layer Adaptation 887 MPLS-TP LSPs can be used to transport network layer clients. This 888 document uses the term Network Layer in the same sense as it is used 889 in [RFC3031] and [RFC3032]. The network layer protocols supported by 890 [RFC3031] and [RFC3032] can be transported between service 891 interfaces. Examples are shown in Figure 5 above. Support for 892 network layer clients follows the MPLS architecture for support of 893 network layer protocols as specified in [RFC3031] and [RFC3032]. 895 With network layer adaptation, the MPLS-TP domain provides either a 896 uni-directional or bidirectional point-to-point connection between 897 two PEs in order to deliver a packet transport service to attached 898 customer edge (CE) nodes. For example, a CE may be an IP, MPLS or 899 MPLS-TP node. As shown in Figure 9, there is an attachment circuit 900 between the CE node on the left and its corresponding provider edge 901 (PE) node which provides the service interface, a bidirectional LSP 902 across the MPLS-TP network to the corresponding PE node on the right, 903 and an attachment circuit between that PE node and the corresponding 904 CE node for this service. 906 The attachment circuits may be heterogeneous (e.g., any combination 907 of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads 908 arrive at the service interface encapsulated in the Layer1/Layer2 909 encoding defined for that access link type. It should be noted that 910 the set of network layer protocols includes MPLS and hence MPLS 911 encoded packets with an MPLS label stack (the client MPLS stack), may 912 appear at the service interface. 914 |<------------- Client Network Layer ------------->| 915 | | 916 | |<---- Pkt Xport Service --->| | 917 | | | | 918 | | |<-- PSN Tunnel -->| | | 919 | V V V V | 920 V AC +----+ +---+ +----+ AC V 921 +-----+ | |PE1 | | | |PE2 | | +-----+ 922 | | |LSP | | | | | | | | | 923 | CE1 |----------| |========X=========| |----------| CE2 | 924 | | ^ |IP | | ^ | | ^ | | | ^ | | 925 +-----+ | | | | | | | | | | | | +-----+ 926 ^ | +----+ | +---+ | +----+ | | ^ 927 | | Provider | ^ | Provider | | 928 | | Edge | | | Edge | | 929 Customer | 1 | P-router | 2 | Customer 930 Edge 1 | TE TE | Edge 2 931 | LSP LSP | 932 | | 933 Native service Native service 935 Figure 9: MPLS-TP Architecture for Network Layer Clients 937 At the ingress service interface the client packets are received . 938 The PE pushes one or more labels onto the client packets which are 939 then label switched over the transport network. Correspondingly the 940 egress PE pops any labels added by the MPLS-TP networks and transmits 941 the packet for delivery to the attached CE via the egress service 942 interface. 944 /===================\ 945 H OAM PDU H 946 +-------------------+ H-------------------H /===================\ 947 | Client Layer | H GACh H H OAM PDU H 948 /===================\ H-------------------H H-------------------H 949 H Encap Label H H GAL (S=1) H H GACh H 950 H-------------------H H-------------------H H-------------------H 951 H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H 952 H-------------------H H-------------------H H-------------------H 953 H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H 954 \===================/ \===================/ \===================/ 955 | Server Layer | | Server Layer | | Server Layer | 956 +-------------------+ +-------------------+ +-------------------+ 958 User Traffic Service LSP OAM LSP OAM 960 Note: H(ighlighted) indicates the part of the protocol stack we are 961 considering in this document. 963 Figure 10: Domain of MPLS-TP Layer Network for IP and LSP Clients 965 In this figure the Transport Service Layer [RFC5654] is identified by 966 the Service LSP (SvcLSP) demultiplexer (Demux) label and the 967 Transport Path Layer [RFC5654] is identified by the LSP Demux Label. 968 Note that the functions of the Encapsulation label and the Service 969 Label shown above as SvcLSP Demux may be represented by a single 970 label stack entry. Additionally, the S-bit will always be zero when 971 the client layer is MPLS labelled. 973 Within the MPLS-TP transport network, the network layer protocols are 974 carried over the MPLS-TP network using a logically separate MPLS 975 label stack (the server stack). The server stack is entirely under 976 the control of the nodes within the MPLS-TP transport network and it 977 is not visible outside that network. Figure 10 shows how a client 978 network protocol stack (which may be an MPLS label stack and payload) 979 is carried over a network layer client service over an MPLS-TP 980 transport network. 982 A label per network layer protocol payload type that is to be 983 transported is required. When multiple protocol payload types are to 984 be carried over a single service a unique label stack entry must be 985 present for each payload type. Such labels are referred to as 986 "Encapsulation Labels", one of which is shown in Figure 10. 987 Encapsulation Label may be either configured or signaled. 989 Both an Encapsulation Label and a Service Label should be present in 990 the label stack when a particular packet transport service is 991 supporting more than one network layer protocol payload type. For 992 example, if both IP and MPLS are to be carried, as shown in Figure 9, 993 then two Encapsulation Labels are mapped on to a common Service 994 Label. 996 Note: The Encapsulation Label may be omitted when the transport 997 service is supporting only one network layer protocol payload type. 998 For example, if only MPLS labeled packets are carried over a service, 999 then the Service Label (stack entry) provides both the payload type 1000 indication and service identification. 1002 Service labels are typically carried over an MPLS-TP LSP edge-to-edge 1003 (or transport path layer). An MPLS-TP edge-to-edge LSP is 1004 represented as an LSP Demux label as shown in Figure 10. An edge-to- 1005 edge LSP is commonly used when more than one service exists between 1006 two PEs. 1008 Note, the edge-to-edge LSP may be omitted when only one service 1009 exists between two PEs. For example, if only one service is carried 1010 between two PEs then a single Service Label could be used to provide 1011 both the service indication and the MPLS-TP edge-to-edge LSP. 1012 Alternatively, if multiple services exist between a pair of PEs then 1013 a per-client Service Label would be mapped on to a common MPLS-TP 1014 edge-to-edge LSP. 1016 As noted above, the layer 2 and layer 1 protocols used to carry the 1017 network layer protocol over the attachment circuits are not 1018 transported across the MPLS-TP network. This enables the use of 1019 different layer 2 and layer 1 protocols on the two attachment 1020 circuits. 1022 At each service interface, Layer 2 addressing must be used to ensure 1023 the proper delivery of a network layer packet to the adjacent node. 1024 This is typically only an issue for LAN media technologies (e.g., 1025 Ethernet) which have Media Access Control (MAC) addresses. In cases 1026 where a MAC address is needed, the sending node must set the 1027 destination MAC address to an address that ensures delivery to the 1028 adjacent node. That is the CE sets the destination MAC address to an 1029 address that ensures delivery to the PE, and the PE sets the 1030 destination MAC address to an address that ensures delivery to the 1031 CE. The specific address used is technology type specific and is not 1032 covered in this document. In some technologies the MAC address will 1033 need to be configured (Examples for the Ethernet case include a 1034 configured unicast MAC address for the adjacent node, or even using 1035 the broadcast MAC address when the CE-PE service interface is 1036 dedicated. The configured address is then used as the MAC 1037 destination address for all packets sent over the service interface.) 1038 Note that when two CEs, which peer with each other, operate over a 1039 network layer transport service run a routing protocol such as IS-IS 1040 or OSPF some care should be taken to configure the routing protocols 1041 to use point- to-point adjacencies .The specifics of such 1042 configuration is outside the scope of this document. See [RFC5309] 1043 for additional details. 1045 The CE to CE service types and corresponding labels may be configured 1046 or signaled . See Section 3.11 for additional details related to 1047 configured service types. See Section 3.9 for additional details 1048 related to signaled service types. 1050 3.5. Identifiers 1052 Identifiers are used to uniquely distinguish entities in an MPLS-TP 1053 network. These include operators, nodes, LSPs, pseudowires, and 1054 their associated maintenance entities. 1055 [I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are 1056 compatible with existing MPLS control plane identifiers, as well as a 1057 set of identifiers that may be used when no IP control plane is 1058 available. 1060 3.6. Generic Associated Channel (G-ACh) 1062 For correct operation of the OAM it is important that the OAM packets 1063 fate-share with the data packets. In addition in MPLS-TP it is 1064 necessary to discriminate between user data payloads and other types 1065 of payload. For example, a packet may be associated with a 1066 Signalling Communication Channel (SCC), or a channel used for 1067 Automatic Protection Switching (APS) data. This is achieved by 1068 carrying such packets on a generic control channel associated to the 1069 LSP, PW or section. 1071 MPLS-TP makes use of such a generic associated channel (G-ACh) to 1072 support Fault, Configuration, Accounting, Performance and Security 1073 (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC 1074 or other packet types in-band over LSPs or PWs. The G-ACh is defined 1075 in [RFC5586] and is similar to the Pseudowire Associated Channel 1076 [RFC4385], which is used to carry OAM packets over pseudowires. The 1077 G-ACh is indicated by a generic associated channel header (ACH), 1078 similar to the Pseudowire VCCV control word; this header is present 1079 for all Sections, LSPs and PWs making use of FCAPS functions 1080 supported by the G-ACh. 1082 For pseudowires, the G-ACh uses the first four bits of the pseudowire 1083 control word to provide the initial discrimination between data 1084 packets and packets belonging to the associated channel, as described 1085 in [RFC4385]. When this first nibble of a packet, immediately 1086 following the label at the bottom of stack, has a value of '1', then 1087 this packet belongs to a G-ACh. The first 32 bits following the 1088 bottom of stack label then have a defined format called an associated 1089 channel header (ACH), which further defines the content of the 1090 packet. The ACH is therefore both a demultiplexer for G-ACh traffic 1091 on the PW, and a discriminator for the type of G-ACh traffic. 1093 When the OAM or other control message is carried over an LSP, rather 1094 than over a pseudowire, it is necessary to provide an indication in 1095 the packet that the payload is something other than a user data 1096 packet. This is achieved by including a reserved label with a value 1097 of 13 in the label stack. This reserved label is referred to as the 1098 'Generic Alert Label (GAL)', and is defined in [RFC5586]. When a GAL 1099 is found, it indicates that the payload begins with an ACH. The GAL 1100 is thus a demultiplexer for G-ACh traffic on the LSP, and the ACH is 1101 a discriminator for the type of traffic carried on the G-ACh. Note 1102 however that MPLS-TP forwarding follows the normal MPLS model, and 1103 that a GAL is invisible to an LSR unless it is the top label in the 1104 label stack. The only other circumstance under which the label stack 1105 may be inspected for a GAL is when the TTL has expired. Any MPLS-TP 1106 component that intentionally performs this inspection must assume 1107 that it is asynchronous with respect to the forwarding of other 1108 packets. All operations on the label stack are in accordance with 1109 [RFC3031] and [RFC3032]. 1111 In MPLS-TP, the 'G-ACh Alert Label (GAL)' always appears at the 1112 bottom of the label stack (i.e. S bit set to 1). 1114 The G-ACh must only be used for channels that are an adjunct to the 1115 data service. Examples of these are OAM, APS, MCC and SCC, but the 1116 use is not restricted to these services. The G-ACh must not be used 1117 to carry additional data for use in the forwarding path, i.e. it must 1118 not be used as an alternative to a PW control word, or to define a PW 1119 type. 1121 At the server layer, bandwidth and QoS commitments apply to the gross 1122 traffic on the LSP, PW or section. Since the G-ACh traffic is 1123 indistinguishable from the user data traffic, protocols using the 1124 G-ACh must take into consideration the impact they have on the user 1125 data that they are sharing resources with. Conversely, capacity must 1126 be made available for important G-ACh uses such as protection and 1127 OAM. In addition, protocols using the G-ACh must conform to the 1128 security and congestion considerations described in [RFC5586]. 1130 Figure 11 shows the reference model depicting how the control channel 1131 is associated with the pseudowire protocol stack. This is based on 1132 the reference model for VCCV shown in Figure 2 of [RFC5085]. 1134 +-------------+ +-------------+ 1135 | Payload | < FCAPS > | Payload | 1136 +-------------+ +-------------+ 1137 | Demux / | < ACH for PW > | Demux / | 1138 |Discriminator| |Discriminator| 1139 +-------------+ +-------------+ 1140 | PW | < PW > | PW | 1141 +-------------+ +-------------+ 1142 | PSN | < LSP > | PSN | 1143 +-------------+ +-------------+ 1144 | Physical | | Physical | 1145 +-----+-------+ +-----+-------+ 1146 | | 1147 | ____ ___ ____ | 1148 | _/ \___/ \ _/ \__ | 1149 | / \__/ \_ | 1150 | / \ | 1151 +--------| MPLS/MPLS-TP Network |---+ 1152 \ / 1153 \ ___ ___ __ _/ 1154 \_/ \____/ \___/ \____/ 1156 Figure 11: PWE3 Protocol Stack Reference Model showing the G-ACh 1158 PW associated channel messages are encapsulated using the PWE3 1159 encapsulation, so that they are handled and processed in the same 1160 manner (or in some cases, an analogous manner) as the PW PDUs for 1161 which they provide a control channel. 1163 Figure 12 shows the reference model depicting how the control channel 1164 is associated with the LSP protocol stack. 1166 +-------------+ +-------------+ 1167 | Payload | < FCAPS > | Payload | 1168 +-------------+ +-------------+ 1169 |Discriminator| < ACH on LSP > |Discriminator| 1170 +-------------+ +-------------+ 1171 |Demultiplexer| < GAL on LSP > |Demultiplexer| 1172 +-------------+ +-------------+ 1173 | PSN | < LSP > | PSN | 1174 +-------------+ +-------------+ 1175 | Physical | | Physical | 1176 +-----+-------+ +-----+-------+ 1177 | | 1178 | ____ ___ ____ | 1179 | _/ \___/ \ _/ \__ | 1180 | / \__/ \_ | 1181 | / \ | 1182 +--------| MPLS/MPLS-TP Network |---+ 1183 \ / 1184 \ ___ ___ __ _/ 1185 \_/ \____/ \___/ \____/ 1187 Figure 12: MPLS Protocol Stack Reference Model showing the LSP 1188 Associated Control Channel 1190 3.7. Operations, Administration and Maintenance (OAM) 1192 MPLS-TP must be able to operate in environments where IP is not used 1193 in the forwarding plane. Therefore, the default mechanism for OAM 1194 demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated 1195 Channel (Section 3.6). Forwarding based on IP addresses for user or 1196 OAM packets is not required for MPLS-TP. 1198 [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined 1199 alert mechanisms that enable an MPLS LSR to identify and process MPLS 1200 OAM packets when the OAM packets are encapsulated in an IP header. 1201 These alert mechanisms are based on TTL expiration and/or use an IP 1202 destination address in the range 127/8 for IPv4 and that same range 1203 embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the 1204 OAM packets are encapsulated in an IP header, these mechanisms are 1205 the default mechanisms for MPLS networks in general for identifying 1206 MPLS OAM packets. MPLS-TP must be able to operate in an environments 1207 where IP forwarding is not supported, and thus the GACH/GAL is the 1208 default mechanism to demultiplex OAM packets in MPLS-TP. 1210 MPLS-TP supports a comprehensive set of OAM capabilities for packet 1211 transport applications, with equivalent capabilities to those 1212 provided in SONET/SDH. 1214 MPLS-TP defines mechanisms to differentiate specific packets (e.g. 1215 OAM, APS, MCC or SCC) from those carrying user data packets on the 1216 same transport path (i.e. section, LSP or PW). These mechanisms are 1217 described in [RFC5586]. 1219 MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of 1220 OAM capabilities is available to perform fault management (e.g. fault 1221 detection and localisation) and performance monitoring (e.g. packet 1222 delay and loss measurement) of the LSP, PW or section. The framework 1223 for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. 1225 MPLS-TP OAM packets share the same fate as their corresponding data 1226 packets, and are identified through the Generic Associated Channel 1227 mechanism [RFC5586]. This uses a combination of an Associated 1228 Channel Header (ACH) and a Generic Alert Label (GAL) to create a 1229 control channel associated to an LSP, Section or PW. 1231 OAM and monitoring in MPLS-TP is based on the concept of maintenance 1232 entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A 1233 Maintenance Entity can be viewed as the association of two 1234 Maintenance End Points (MEPs). A Maintenance Entity Group (MEG) is a 1235 collection of one or more MEs that belongs to the same transport path 1236 and that are maintained and monitored as a group. The MEPs that form 1237 an ME limit the OAM responsibilities of an OAM flow to within the 1238 domain of a transport path or segment, in the specific layer network 1239 that is being monitored and managed. 1241 An ME may also include a set of Maintenance Intermediate Points 1242 (MIPs). Maintenance End Points (MEPs) are capable of sourcing and 1243 sinking OAM flows, while Maintenance Intermediate Points (MIPs) can 1244 only sink or respond to OAM flows from within a MEG, or originate 1245 notifications as a result of specific network conditions. 1247 The following MPLS-TP MEs are specified in 1248 [I-D.ietf-mpls-tp-oam-framework]: 1250 o A Section Maintenance Entity (SME), allowing monitoring and 1251 management of MPLS-TP Sections (between MPLS LSRs). 1253 o A LSP Maintenance Entity (LME), allowing monitoring and management 1254 of an edge-to-edge LSP (between LERs). 1256 o A PW Maintenance Entity (PME), allowing monitoring and management 1257 of an edge-to-edge SS/MS-PWs (between T-PEs). 1259 o An LSP Tandem Connection Maintenance Entity (LTCME). 1261 A G-ACH packet may be directed to an individual MIP along the path of 1262 an LSP or MS-PW by setting the appropriate TTL in the label for the 1263 G-ACH packet, as per the traceroute mode of LSP Ping [RFC4379] and 1264 the vccv-trace mode of[I-D.ietf-pwe3-segmented-pw]. Note that this 1265 works when the location of MIPs along the LSP or PW path is known by 1266 the MEP. There may be circumstances where this is not the case, e.g. 1267 following restoration using a facility bypass LSP. In these cases, 1268 tools to trace the path of the LSP may be used to determine the 1269 appropriate setting for the TTL to reach a specific MIP. 1271 Within an LSR or PE, MEPs and MIPs can only be placed where MPLS 1272 layer processing is performed on a packet. The architecture mandates 1273 that this must occur at least once. 1275 MEPs may only act as a sink of OAM packets when the label associated 1276 with the LSP or PW for that ME is popped. MIPs can only be placed 1277 where an exception to the normal forwarding operation occurs. A MEP 1278 may act as a source of OAM packets wherever a label is pushed or 1279 swapped. For example, on an MS-PW, a MEP may source OAM within an 1280 S-PE or a T-PE, but a MIP may only be associated with a S-PE and a 1281 sink MEP can only be associated with a T-PE. 1283 The MPLS-TP OAM architecture supports a wide range of OAM functions 1284 to check continuity, to verify connectivity and to monitor the 1285 preformance of the path, to generate, filter and manage local and 1286 remote defect alarms. These functions are applicable to any layer 1287 defined within MPLS-TP, i.e. to MPLS-TP Sections, LSPs and PWs. 1289 The MPLS-TP OAM tool-set must be able to operate without relying on a 1290 dynamic control plane or IP functionality in the datapath. In the 1291 case of an MPLS-TP deployment in a network in which IP functionality 1292 is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD 1293 and VCCV, may be used. 1295 3.8. LSP Return Path 1297 Management, control and OAM protocol functions may require response 1298 packets to be delivered from the receiver back to the originator of a 1299 message exchange. This section provides a summary of the return path 1300 options in MPLS-TP networks. 1302 In this discussion we assume that A and B are terminal LSRs (i.e. 1303 LERs) for an MPLS-TP LSP and that Y is an intermediate LSR along the 1304 LSP. In the unidirectional case, A is taken to be the upstream and B 1305 the downstream LSR with respect to the LSP. We consider the 1306 following cases for the various types of LSPs: 1308 1. Packet transmission from B to A 1310 2. Packet transmission from Y to A 1312 3. Packet transmission from B to Y 1314 Note that a return path may not always exist, and that packet 1315 transmission in one or more of the above cases may not be possible. 1316 In general the existence and nature of return paths for MPLS-TP LSPs 1317 is determined by operational provisioning. 1319 3.8.1. Return Path Types 1321 There are two types of return path that may be used for the delivery 1322 of traffic from a downstream node D to an upstream node U either: 1324 a. D maintains an MPLS-TP LSP back to U which is specifically 1325 designated to carry return traffic for the original LSP, or 1327 b. D has some other unspecified means of directing traffic back to 1328 U. 1330 The first option is referred to as an "in-band" return path, the 1331 second as an "out-of-band" return path. 1333 There are various possibilities for "out-of-band" return paths. Such 1334 a path may, for example, be based on ordinary IP routing. In this 1335 case packets would be forwarded as usual to a destination IP address 1336 associated with U. In an MPLS-TP network that is also an IP/MPLS 1337 network, such a forwarding path may traverse the same physical links 1338 or logical transport paths used by MPLS-TP. An out-of-band return 1339 path may also be indirect, via a network management system; or it may 1340 be via one or more other MPLS-TP LSPs. 1342 3.8.2. Point-to-Point Unidirectional LSPs 1344 Case 1 In this situation, either an in-band or out-of-band return 1345 path may be used to deliver traffic from B back to A. 1347 In the in-band case there is in essence an associated 1348 bidirectional LSP between A and B, and the discussion for 1349 such LSPs below applies. It is therefore recommended for 1350 reasons of operational simplicity that point-to-point 1351 unidirectional LSPs be provisioned as associated 1352 bidirectional LSPs (which may also be co-routed) whenever 1353 return traffic from B to A is required. Note that the two 1354 directions of such an LSP may have differing bandwidth 1355 allocations and QoS characteristics. 1357 Case 2 In this case only the out-of-band return path option is 1358 available. However, an additional out-of-band possibility is 1359 worthy of note here: if B is known to have a return path to 1360 A, then Y can arrange to deliver return traffic to A by first 1361 sending it to B along the original LSP. The mechanism by 1362 which B recognises the need for and performs this forwarding 1363 operation is protocol-specific. 1365 Case 3 In this case only the out-of-band return path option is 1366 available. However, if B has a return path to A, then in a 1367 manner analogous to the previous case B can arrange to 1368 deliver return traffic to Y by first sending it to A along 1369 that return path. The mechanism by which A recognises the 1370 need for and performs this forwarding operation is protocol- 1371 specific. 1373 3.8.3. Point-to-Point Associated Bidirectional LSPs 1375 For Case 1, B has a natural in-band return path to A, the use of 1376 which is typically preferred for return traffic, although out-of-band 1377 return paths are also applicable. 1379 For Cases 2 and 3, the considerations are the same as those for 1380 point-to-point unidirectional LSPs. 1382 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs 1384 For all of Cases 1, 2, and 3, a natural in-band return path exists in 1385 the form of the LSP itself, and its use is typically preferred for 1386 return traffic. Out-of-band return paths, however, are also 1387 applicable. 1389 3.9. Control Plane 1391 A distributed dynamic control plane may be used to enable dynamic 1392 service provisioning in an MPLS-TP network. Where the requirements 1393 specified in [RFC5654] can be met, the MPLS Transport Profile uses 1394 existing standard control plane protocols for LSPs and PWs. 1396 Note that a dynamic control plane is not required in an MPLS-TP 1397 network. See Section 3.11 for further details on statically 1398 configured and provisioned MPLS-TP services. 1400 Figure 13 illustrates the relationship between the MPLS-TP control 1401 plane, the forwarding plane, the management plane, and OAM for point- 1402 to-point MPLS-TP LSPs or PWs. 1404 +------------------------------------------------------------------+ 1405 | | 1406 | Network Management System and/or | 1407 | | 1408 | Control Plane for Point to Point Connections | 1409 | | 1410 +------------------------------------------------------------------+ 1411 | | | | | | 1412 .............|.....|... ....|.....|.... ....|.....|............ 1413 : +---+ | : : +---+ | : : +---+ | : 1414 : |OAM| | : : |OAM| | : : |OAM| | : 1415 : +---+ | : : +---+ | : : +---+ | : 1416 : | | : : | | : : | | : 1417 \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/ 1418 --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+-- 1419 /: +----+ |ing | : : |ing | : : |ing | +----+ :\ 1420 : +--------+ : : +--------+ : : +--------+ : 1421 ''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' 1423 Note: 1424 1) NMS may be centralised or distributed. Control plane is 1425 distributed. 1426 2) 'Edge' functions refers to those functions present at 1427 the edge of a PSN domain, e.g. NSP or classification. 1428 3) The control plane may be transported over the server 1429 layer, an LSP or a G-ACh. 1431 Figure 13: MPLS-TP Control Plane Architecture Context 1433 The MPLS-TP control plane is based on existing MPLS and PW control 1434 plane protocols. MPLS-TP uses Generalized MPLS (GMPLS) signalling 1435 ([RFC3945], [RFC3471], [RFC3473]) for LSPs and Targetted LDP (T-LDP) 1436 [RFC4447] [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] 1437 for pseudowires. When T-LDP is used as the PW control protocol, 1438 MPLS-TP requires that it is capable of being carried over an out of 1439 band signalling network or a signalling control channel [RFC5718]. 1440 References to T-LDP in this document do not preclude the definition 1441 of alternative PW control protocols for use in MPLS-TP. 1443 Note that if MPLS-TP is being used in a multi-layer network, a number 1444 of control protocol types and instances may be used. This is 1445 consistent with the MPLS architecture which permits each label in the 1446 label stack to be allocated and signalled by its own control 1447 protocol. 1449 The distributed MPLS-TP control plane may provide the following 1450 functions: 1452 o Signalling 1454 o Routing 1456 o Traffic engineering and constraint-based path computation 1458 In a multi-domain environment, the MPLS-TP control plane supports 1459 different types of interfaces at domain boundaries or within the 1460 domains. These include the User-Network Interface (UNI), Internal 1461 Network Node Interface (I-NNI), and External Network Node Interface 1462 (E-NNI). Note that different policies may be defined that control 1463 the information exchanged across these interface types. 1465 The MPLS-TP control plane is capable of activating MPLS-TP OAM 1466 functions as described in the OAM section of this document 1467 Section 3.7, e.g. for fault detection and localisation in the event 1468 of a failure in order to efficiently restore failed transport paths. 1470 The MPLS-TP control plane supports all MPLS-TP data plane 1471 connectivity patterns that are needed for establishing transport 1472 paths, including protected paths as described in Section 3.12. 1473 Examples of the MPLS-TP data plane connectivity patterns are LSPs 1474 utilising the fast reroute backup methods as defined in [RFC4090] and 1475 ingress-to-egress 1+1 or 1:1 protected LSPs. 1477 The MPLS-TP control plane provides functions to ensure its own 1478 survivability and to enable it to recover gracefully from failures 1479 and degradations. These include graceful restart and hot redundant 1480 configurations. Depending on how the control plane is transported, 1481 varying degrees of decoupling between the control plane and data 1482 plane may be achieved. 1484 3.10. Inter-domain Connectivity 1486 A number of methods exist to support inter-domain operation of 1487 MPLS-TP, for example: 1489 o Inter-domain TE LSPs [RFC4216] 1491 o Multi-segment Pseudowires [RFC5659] 1493 o LSP stitching [RFC5150] 1495 o back-to-back ACs [RFC5659] 1497 An important consideration in selecting an inter-domain connectivity 1498 mechanism is the degree of layer network isolation and types of OAM 1499 required by the operator. The selection of which technique to use in 1500 a particular deployment scenario is outside the scope of this 1501 document. 1503 3.11. Static Operation of LSPs and PWs 1505 A PW or LSP may be statically configured without the support of a 1506 dynamic control plane. This may be either by direct configuration of 1507 the PEs/LSRs, or via a network management system. Static operation 1508 is independent for a specific PW or LSP instance. Thus it should be 1509 possible for a PW to be statically configured, while the LSP 1510 supporting it is set up by a dynamic control plane. When static 1511 configuration mechanisms are used, care must be taken to ensure that 1512 loops are not created. 1514 3.12. Survivability 1516 Survivability requirements for MPLS-TP are specified in 1517 [I-D.ietf-mpls-tp-survive-fwk]. 1519 A wide variety of resiliency schemes have been developed to meet the 1520 various network and service survivability objectives. For example, 1521 as part of the MPLS/PW paradigms, MPLS provides methods for local 1522 repair using back-up LSP tunnels ([RFC4090]), while pseudowire 1523 redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the 1524 protection for the PW cannot be fully provided by the underlying LSP 1525 (i.e. where the backup PW terminates on a different target PE node 1526 than the working PW in dual homing scenarios, or where protection of 1527 the S-PE is required). Additionally, GMPLS provides a well known set 1528 of control plane driven protection and restoration mechanisms 1529 [RFC4872]. MPLS-TP provides additional protection mechanisms that 1530 are optimised for both linear topologies and ring topologies, and 1531 that operate in the absence of a dynamic control plane. These are 1532 specified in [I-D.ietf-mpls-tp-survive-fwk]. 1534 Different protection schemes apply to different deployment topologies 1535 and operational considerations. Such protection schemes may provide 1536 different levels of resiliency, for example: 1538 o Two concurrent traffic paths (1+1). 1540 o one active and one standby path with guaranteed bandwidth on both 1541 paths (1:1). 1543 o one active path and a standby path the resources or which are 1544 shared by one or more other active paths (shared protection). 1546 The applicability of any given scheme to meet specific requirements 1547 is outside the current scope of this document. 1549 The characteristics of MPLS-TP resiliency mechanisms are as follows: 1551 o Optimised for linear, ring or meshed topologies. 1553 o Use OAM mechanisms to detect and localise network faults or 1554 service degenerations. 1556 o Include protection mechanisms to coordinate and trigger protection 1557 switching actions in the absence of a dynamic control plane. This 1558 is known as an Automatic Protection Switching (APS) mechanism. 1560 o MPLS-TP recovery schemes are applicable to all levels in the 1561 MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment 1562 and end-to-end recovery. 1564 o MPLS-TP recovery mechanisms support the coordination of protection 1565 switching at multiple levels to prevent race conditions occurring 1566 between a client and its server layer. 1568 o MPLS-TP recovery mechanisms can be data plane, control plane or 1569 management plane based. 1571 o MPLS-TP supports revertive and non-revertive behaviour. 1573 3.13. Path Segment Tunnels 1575 In order to monitor, protect and manage a portion of an LSP, a new 1576 architectural element is defined. This the Path Segment Tunnel 1577 (PST). A PST is an LSP defined and used for the purposes of OAM 1578 monitoring, protection or management of LSP segment or concatenated 1579 LSP segments, and based on MPLS hierarchical nested LSP defined in 1580 [RFC3031]. 1582 A PST is defined between the edges of the portion of the LSP that 1583 needs to be monitored, protected or managed. Maintenance messages 1584 can be initiated at the edge of the PST and sent to the peer edge of 1585 the PST or to an intermediate point along the PST setting the TTL 1586 value at the PST level accordingly. 1588 For example in Figure 14, three PSTs are configured to allow 1589 monitoring, protection and management of the LSP concatenated 1590 segments. One PST is defined between PE1 and PE2, the second between 1591 PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of 1592 these three PSTs may be monitored, protected, or managed 1593 independently. 1595 ========================== End to End LSP ============================= 1597 |<--------- Carrier 1 --------->| |<----- Carrier 2 ----->| 1599 ---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |--- 1601 |============= PST =============|==PST==|========= PST =========| 1602 (Carrier 1) (Carrier 2) 1604 Figure 14: PSTs in inter-carrier network 1606 The end-to-end traffic of the LSP, including data-traffic and control 1607 traffic (OAM, Protection Switching Control, management and signalling 1608 messages) is tunneled within the PST by means of label stacking as 1609 defined in [RFC3031]. 1611 The mapping between an LSP and a PST can be 1:1, in which it is 1612 similar to the ITU-T Tandem Connection element [G.805]. The mapping 1613 can also be 1:N to allow aggregated monitoring, protection and 1614 management of a set of LSP segments or concatenated LSP segments. 1615 Figure 15 shows a PST which is used to aggregate a set of 1616 concatenated LSP segments for the LSP from PEx to PEt and the LSP 1617 from PEa to PEd. Note that such a construct is useful, for example, 1618 when the LSPs traverse a common portion of the network and they have 1619 the same Traffic Class. 1621 |PEx|--|PEy|-+ +-|PEz|--|PEt| 1622 | | 1623 | |<---------- Carrier 1 --------->| | 1624 | +-----+ +---+ +---+ +-----+ | 1625 +--| |---| |---| |----| |--+ 1626 | PE1 | | P | | P | | PE2 | 1627 +--| |---| |---| |----| |--+ 1628 | +-----+ +---+ + P + +-----+ | 1629 | |============= PST ==============| | 1630 |PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd| 1632 Figure 15: PST for a Set of Concatenated LSP Segments 1634 3.13.1. Provisioning of PST 1636 PSTs can be either provisioned statically or using control plane 1637 signalling procedures. The make-before-break procedures which are 1638 supported by MPLS allow the creation of a PST on existing LSPs in- 1639 service without traffic disruption. A PST can be defined 1640 corresponding to one or more end-to-end tunneled LSPs. New end-to- 1641 end LSPs which are tunneled within the PST can be setup. Traffic of 1642 the existing LSPs is switched over to the new end-to-end tunneled 1643 LSPs. The old end-to-end LSPs can be tore down. 1645 3.14. Pseudowire Segment Tunnels 1647 Pseudowire segment tunnels are for further study. 1649 3.15. Network Management 1651 The network management architecture and requirements for MPLS-TP are 1652 specified in [I-D.ietf-mpls-tp-nm-framework] and 1653 [I-D.ietf-mpls-tp-nm-req]. These derive from the generic 1654 specifications described in ITU-T G.7710/Y.1701 [G.7710] for 1655 transport technologies. It also incorporates the OAM requirements 1656 for MPLS Networks [RFC4377] and MPLS-TP Networks 1657 [I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements 1658 to cover the modifications necessary for fault, configuration, 1659 performance, and security in a transport network. 1661 The Equipment Management Function (EMF) of an MPLS-TP Network Element 1662 (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through 1663 which a management system manages the NE. The Management 1664 Communication Channel (MCC), realised by the G-ACh, provides a 1665 logical operations channel between NEs for transferring Management 1666 information. For the management interface from a management system 1667 to an MPLS-TP NE, there is no restriction on which management 1668 protocol is used. The MCC is used to provision and manage an end-to- 1669 end connection across a network where some segments are created/ 1670 managed by, for example, Netconf [RFC4741] or SNMP [RFC3411] and 1671 other segments by XML or CORBA interfaces. Maintenance operations 1672 are run on a connection (LSP or PW) in a manner that is independent 1673 of the provisioning mechanism. An MPLS-TP NE is not required to 1674 offer more than one standard management interface. In MPLS-TP, the 1675 EMF must be capable of statically provisioning LSPs for an LSR or 1676 LER, and PWs for a PE, as well as any associated MEPs and MIPs, as 1677 per Section 3.11. 1679 Fault Management (FM) functions within the EMF of an MPLS-TP NE 1680 enable the supervision, detection, validation, isolation, correction, 1681 and alarm handling of abnormal conditions in the MPLS-TP network and 1682 its environment. FM must provide for the supervision of transmission 1683 (such as continuity, connectivity, etc.), software processing, 1684 hardware, and environment. Alarm handling includes alarm severity 1685 assignment, alarm suppression/aggregation/correlation, alarm 1686 reporting control, and alarm reporting. 1688 Configuration Management (CM) provides functions to control, 1689 identify, collect data from, and provide data to MPLS-TP NEs. In 1690 addition to general configuration for hardware, software protection 1691 switching, alarm reporting control, and date/time setting, the EMF of 1692 the MPLS-TP NE also supports the configuration of maintenance entity 1693 identifiers (such as MEP ID and MIP ID). The EMF also supports the 1694 configuration of OAM parameters as a part of connectivity management 1695 to meet specific operational requirements. These may specify whether 1696 the operational mode is one-time on-demand or is periodic at a 1697 specified frequency. 1699 The Performance Management (PM) functions within the EMF of an 1700 MPLS-TP NE support the evaluation and reporting of the behaviour of 1701 the NEs and the network. One particular requirement for PM is to 1702 provide coherent and consistent interpretation of the network 1703 behaviour in a hybrid network that uses multiple transport 1704 technologies. Packet loss measurement and delay measurements may be 1705 collected and used to detect performance degradation. This is 1706 reported via fault management to enable corrective actions to be 1707 taken (e.g. protection switching), and via performance monitoring for 1708 Service Level Agreement (SLA) verification and billing. Collection 1709 mechanisms for performance data should be capable of operating on- 1710 demand or pro-actively. 1712 4. Security Considerations 1714 The introduction of MPLS-TP into transport networks means that the 1715 security considerations applicable to both MPLS and PWE3 apply to 1716 those transport networks. Furthermore, when general MPLS networks 1717 that utilise functionality outside of the strict MPLS Transport 1718 Profile are used to support packet transport services, the security 1719 considerations of that additional functionality also apply. 1721 For pseudowires, the security considerations of [RFC3985] and 1722 [RFC5659] apply. 1724 Packets that arrive on an interface with a given label value should 1725 not be forwarded unless that label value is assigned to an LSP or PW 1726 to a peer LSR or PE that is reachable via that interface. 1728 Each MPLS-TP solution must specify the additional security 1729 considerations that apply. This is discussed further in 1730 [I-D.fang-mpls-tp-security-framework]. 1732 5. IANA Considerations 1734 IANA considerations resulting from specific elements of MPLS-TP 1735 functionality will be detailed in the documents specifying that 1736 functionality. 1738 This document introduces no additional IANA considerations in itself. 1740 6. Acknowledgements 1742 The editors wish to thank the following for their contribution to 1743 this document: 1745 o Rahul Aggarwal 1747 o Dieter Beller 1749 o Malcolm Betts 1751 o Italo Busi 1753 o John E Drake 1755 o Hing-Kam Lam 1757 o Marc Lasserre 1759 o Vincenzo Sestito 1761 o Nurit Sprecher 1763 o Martin Vigoureux 1765 o Yaacov Weingarten 1767 o The participants of ITU-T SG15 1769 7. Open Issues 1771 This section contains a list of issues that must be resolved before 1772 last call. 1774 o 1776 8. References 1778 8.1. Normative References 1780 [G.7710] "ITU-T Recommendation 1781 G.7710/Y.1701 (07/07), 1782 "Common equipment 1783 management function 1784 requirements"", 2005. 1786 [G.805] "ITU-T Recommendation G.805 1787 (11/95), "Generic 1788 Functional Architecture of 1789 Transport Networks"", 1790 November 1995. 1792 [RFC3031] Rosen, E., Viswanathan, A., 1793 and R. Callon, 1794 "Multiprotocol Label 1795 Switching Architecture", 1796 RFC 3031, January 2001. 1798 [RFC3032] Rosen, E., Tappan, D., 1799 Fedorkow, G., Rekhter, Y., 1800 Farinacci, D., Li, T., and 1801 A. Conta, "MPLS Label Stack 1802 Encoding", RFC 3032, 1803 January 2001. 1805 [RFC3270] Le Faucheur, F., Wu, L., 1806 Davie, B., Davari, S., 1807 Vaananen, P., Krishnan, R., 1808 Cheval, P., and J. 1809 Heinanen, "Multi-Protocol 1810 Label Switching (MPLS) 1811 Support of Differentiated 1812 Services", RFC 3270, 1813 May 2002. 1815 [RFC3471] Berger, L., "Generalized 1816 Multi-Protocol Label 1817 Switching (GMPLS) Signaling 1818 Functional Description", 1819 RFC 3471, January 2003. 1821 [RFC3473] Berger, L., "Generalized 1822 Multi-Protocol Label 1823 Switching (GMPLS) Signaling 1824 Resource ReserVation 1825 Protocol-Traffic 1826 Engineering (RSVP-TE) 1827 Extensions", RFC 3473, 1828 January 2003. 1830 [RFC3985] Bryant, S. and P. Pate, 1831 "Pseudo Wire Emulation 1832 Edge-to-Edge (PWE3) 1833 Architecture", RFC 3985, 1834 March 2005. 1836 [RFC4090] Pan, P., Swallow, G., and 1837 A. Atlas, "Fast Reroute 1838 Extensions to RSVP-TE for 1839 LSP Tunnels", RFC 4090, 1840 May 2005. 1842 [RFC4385] Bryant, S., Swallow, G., 1843 Martini, L., and D. 1844 McPherson, "Pseudowire 1845 Emulation Edge-to-Edge 1846 (PWE3) Control Word for Use 1847 over an MPLS PSN", 1848 RFC 4385, February 2006. 1850 [RFC4447] Martini, L., Rosen, E., El- 1851 Aawar, N., Smith, T., and 1852 G. Heron, "Pseudowire Setup 1853 and Maintenance Using the 1854 Label Distribution Protocol 1855 (LDP)", RFC 4447, 1856 April 2006. 1858 [RFC4872] Lang, J., Rekhter, Y., and 1859 D. Papadimitriou, "RSVP-TE 1860 Extensions in Support of 1861 End-to-End Generalized 1862 Multi-Protocol Label 1863 Switching (GMPLS) 1864 Recovery", RFC 4872, 1865 May 2007. 1867 [RFC5085] Nadeau, T. and C. 1868 Pignataro, "Pseudowire 1869 Virtual Circuit 1870 Connectivity Verification 1871 (VCCV): A Control Channel 1872 for Pseudowires", RFC 5085, 1873 December 2007. 1875 [RFC5462] Andersson, L. and R. Asati, 1876 "Multiprotocol Label 1877 Switching (MPLS) Label 1878 Stack Entry: "EXP" Field 1879 Renamed to "Traffic Class" 1880 Field", RFC 5462, 1881 February 2009. 1883 [RFC5586] Bocci, M., Vigoureux, M., 1884 and S. Bryant, "MPLS 1885 Generic Associated 1886 Channel", RFC 5586, 1887 June 2009. 1889 8.2. Informative References 1891 [I-D.fang-mpls-tp-security-framework] Fang, L. and B. Niven- 1892 Jenkins, "Security 1893 Framework for MPLS-TP", dra 1894 ft-fang-mpls-tp-security- 1895 framework-00 (work in 1896 progress), July 2009. 1898 [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., 1899 Nadeau, T., and G. Swallow, 1900 "BFD For MPLS LSPs", 1901 draft-ietf-bfd-mpls-07 1902 (work in progress), 1903 June 2008. 1905 [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F., 1906 Niven-Jenkins, B., 1907 Brungard, D., and L. Jin, 1908 "Framework and Requirements 1909 for Virtual Private 1910 Multicast Service (VPMS)", 1911 draft-ietf-l2vpn-vpms- 1912 frmwk-requirements-02 (work 1913 in progress), October 2009. 1915 [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, 1916 "MPLS-TP Identifiers", draf 1917 t-ietf-mpls-tp-identifiers- 1918 00 (work in progress), 1919 November 2009. 1921 [I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E., 1922 and H. Lam, "MPLS-TP 1923 Network Management 1924 Framework", draft-ietf- 1925 mpls-tp-nm-framework-04 1926 (work in progress), 1927 January 2010. 1929 [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, 1930 "MPLS TP Network Management 1931 Requirements", draft-ietf- 1932 mpls-tp-nm-req-06 (work in 1933 progress), October 2009. 1935 [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and B. 1936 Niven-Jenkins, "MPLS-TP OAM 1937 Framework", draft-ietf- 1938 mpls-tp-oam-framework-04 1939 (work in progress), 1940 December 2009. 1942 [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., 1943 and M. Betts, "Requirements 1944 for OAM in MPLS Transport 1945 Networks", draft-ietf-mpls- 1946 tp-oam-requirements-04 1947 (work in progress), 1948 December 2009. 1950 [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. Farrel, 1951 "Multiprotocol Label 1952 Switching Transport Profile 1953 Survivability Framework", d 1954 raft-ietf-mpls-tp-survive- 1955 fwk-03 (work in progress), 1956 November 2009. 1958 [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., 1959 Balus, F., Bitar, N., Shah, 1960 H., Aissaoui, M., Rusmisel, 1961 J., Serbest, Y., Malis, A., 1962 Metz, C., McDysan, D., 1963 Sugimoto, J., Duckett, M., 1964 Loomis, M., Doolan, P., 1965 Pan, P., Pate, P., Radoaca, 1966 V., Wada, Y., and Y. Seo, 1967 "Dynamic Placement of Multi 1968 Segment Pseudo Wires", draf 1969 t-ietf-pwe3-dynamic-ms-pw- 1970 10 (work in progress), 1971 October 2009. 1973 [I-D.ietf-pwe3-redundancy] Muley, P. and V. Place, 1974 "Pseudowire (PW) 1975 Redundancy", draft-ietf- 1976 pwe3-redundancy-02 (work in 1977 progress), October 2009. 1979 [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., 1980 Metz, C., Duckett, M., 1981 Bocci, M., Balus, F., and 1982 M. Aissaoui, "Segmented 1983 Pseudowire", draft-ietf- 1984 pwe3-segmented-pw-13 (work 1985 in progress), August 2009. 1987 [RFC3209] Awduche, D., Berger, L., 1988 Gan, D., Li, T., 1989 Srinivasan, V., and G. 1990 Swallow, "RSVP-TE: 1991 Extensions to RSVP for LSP 1992 Tunnels", RFC 3209, 1993 December 2001. 1995 [RFC3411] Harrington, D., Presuhn, 1996 R., and B. Wijnen, "An 1997 Architecture for Describing 1998 Simple Network Management 1999 Protocol (SNMP) Management 2000 Frameworks", STD 62, 2001 RFC 3411, December 2002. 2003 [RFC3443] Agarwal, P. and B. Akyol, 2004 "Time To Live (TTL) 2005 Processing in Multi- 2006 Protocol Label Switching 2007 (MPLS) Networks", RFC 3443, 2008 January 2003. 2010 [RFC3945] Mannie, E., "Generalized 2011 Multi-Protocol Label 2012 Switching (GMPLS) 2013 Architecture", RFC 3945, 2014 October 2004. 2016 [RFC4216] Zhang, R. and J. Vasseur, 2017 "MPLS Inter-Autonomous 2018 System (AS) Traffic 2019 Engineering (TE) 2020 Requirements", RFC 4216, 2021 November 2005. 2023 [RFC4364] Rosen, E. and Y. Rekhter, 2024 "BGP/MPLS IP Virtual 2025 Private Networks (VPNs)", 2026 RFC 4364, February 2006. 2028 [RFC4377] Nadeau, T., Morrow, M., 2029 Swallow, G., Allan, D., and 2030 S. Matsushima, "Operations 2031 and Management (OAM) 2032 Requirements for Multi- 2033 Protocol Label Switched 2034 (MPLS) Networks", RFC 4377, 2035 February 2006. 2037 [RFC4379] Kompella, K. and G. 2038 Swallow, "Detecting Multi- 2039 Protocol Label Switched 2040 (MPLS) Data Plane 2041 Failures", RFC 4379, 2042 February 2006. 2044 [RFC4664] Andersson, L. and E. Rosen, 2045 "Framework for Layer 2 2046 Virtual Private Networks 2047 (L2VPNs)", RFC 4664, 2048 September 2006. 2050 [RFC4741] Enns, R., "NETCONF 2051 Configuration Protocol", 2052 RFC 4741, December 2006. 2054 [RFC5150] Ayyangar, A., Kompella, K., 2055 Vasseur, JP., and A. 2056 Farrel, "Label Switched 2057 Path Stitching with 2058 Generalized Multiprotocol 2059 Label Switching Traffic 2060 Engineering (GMPLS TE)", 2061 RFC 5150, February 2008. 2063 [RFC5254] Bitar, N., Bocci, M., and 2064 L. Martini, "Requirements 2065 for Multi-Segment 2066 Pseudowire Emulation Edge- 2067 to-Edge (PWE3)", RFC 5254, 2068 October 2008. 2070 [RFC5309] Shen, N. and A. Zinin, 2071 "Point-to-Point Operation 2072 over LAN in Link State 2073 Routing Protocols", 2074 RFC 5309, October 2008. 2076 [RFC5331] Aggarwal, R., Rekhter, Y., 2077 and E. Rosen, "MPLS 2078 Upstream Label Assignment 2079 and Context-Specific Label 2080 Space", RFC 5331, 2081 August 2008. 2083 [RFC5654] Niven-Jenkins, B., 2084 Brungard, D., Betts, M., 2085 Sprecher, N., and S. Ueno, 2086 "Requirements of an MPLS 2087 Transport Profile", 2088 RFC 5654, September 2009. 2090 [RFC5659] Bocci, M. and S. Bryant, 2091 "An Architecture for Multi- 2092 Segment Pseudowire 2093 Emulation Edge-to-Edge", 2094 RFC 5659, October 2009. 2096 [RFC5718] Beller, D. and A. Farrel, 2097 "An In-Band Data 2098 Communication Network For 2099 the MPLS Transport 2100 Profile", RFC 5718, 2101 January 2010. 2103 Authors' Addresses 2105 Matthew Bocci (editor) 2106 Alcatel-Lucent 2107 Voyager Place, Shoppenhangers Road 2108 Maidenhead, Berks SL6 2PJ 2109 United Kingdom 2111 Phone: 2112 EMail: matthew.bocci@alcatel-lucent.com 2114 Stewart Bryant (editor) 2115 Cisco Systems 2116 250 Longwater Ave 2117 Reading RG2 6GB 2118 United Kingdom 2120 Phone: 2121 EMail: stbryant@cisco.com 2122 Dan Frost 2123 Cisco Systems 2125 Phone: 2126 Fax: 2127 EMail: danfrost@cisco.com 2128 URI: 2130 Lieven Levrau 2131 Alcatel-Lucent 2132 7-9, Avenue Morane Sulnier 2133 Velizy 78141 2134 France 2136 Phone: 2137 EMail: lieven.levrau@alcatel-lucent.com 2139 Lou Berger 2140 LabN 2142 Phone: +1-301-468-9228 2143 Fax: 2144 EMail: lberger@labn.net 2145 URI: