idnits 2.17.1 draft-ietf-mpls-tp-framework-10.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 396 has weird spacing: '...Example a) [...' == Line 419 has weird spacing: '...Example a) [...' -- The document date (February 4, 2010) is 5193 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Ethernet' is mentioned on line 419, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-02) exists of draft-abfb-mpls-tp-control-plane-framework-01 -- No information found for draft-fang-mpls-tp-security-framework - is the name correct? == 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 (-06) exists of draft-ietf-mpls-tp-survive-fwk-03 == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-10 == 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 (~~), 13 warnings (==), 4 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 8, 2010 D. Frost, Ed. 6 Cisco Systems 7 L. Levrau 8 Alcatel-Lucent 9 L. Berger 10 LabN 11 February 4, 2010 13 A Framework for MPLS in Transport Networks 14 draft-ietf-mpls-tp-framework-10 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 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 8, 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 . . . . . . . . 9 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 . . . . . . . . . . . . . . . . 35 121 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35 122 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 35 123 3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 37 124 3.13.1. Provisioning of PST . . . . . . . . . . . . . . . . . 38 125 3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 38 126 3.15. Network Management . . . . . . . . . . . . . . . . . . . . 38 127 4. Security Considerations . . . . . . . . . . . . . . . . . . . 39 128 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 129 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 130 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41 131 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 132 8.1. Normative References . . . . . . . . . . . . . . . . . . . 41 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 G-ACh Label 224 MEP Maintenance End Point 225 MIP Maintenance Intermediate Point 226 APS Automatic Protection Switching 227 SCC Signaling 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 AC Attachment Circuit 238 Adaptation The mapping of client information into a format suitable 239 for transport by the server layer 240 Native The traffic belonging to the client of the MPLS-TP network 241 Service 242 T-PE PW Terminating Provider Edge 243 S-PE PW Switching provider Edge 245 1.3.1. Transport Network 247 A Transport Network provides transparent transmission of client user 248 plane traffic between attached client devices by establishing and 249 maintaining point-to-point or point-to-multipoint connections between 250 such devices. The architecture of networks supporting point to 251 multipoint connections is out of scope of this document. A Transport 252 Network is independent of any higher-layer network that may exist 253 between clients, except to the extent required to supply this 254 transmission service. In addition to client traffic, a Transport 255 Network may carry traffic to facilitate its own operation, such as 256 that required to support connection control, network management, and 257 Operations, Administration and Maintenance (OAM) functions. 259 See also the definition of Packet Transport Service in Section 3.1. 261 1.3.2. MPLS Transport Profile 263 The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions 264 that meet the requirements in [RFC5654]. Note that MPLS is defined 265 to include any present and future MPLS capability specified by the 266 IETF, including those capabilities specifically added to support 267 transport network requirements [RFC5654]. 269 1.3.3. MPLS-TP Section 271 An MPLS-TP Section is defined in Section 1.2.2 of [RFC5654]. 273 1.3.4. MPLS-TP Label Switched Path 275 An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a 276 subset of the capabilities of an MPLS LSP in order to meet the 277 requirements of an MPLS transport network as set out in [RFC5654]. 278 The characteristics of an MPLS-TP LSP are primarily that it: 280 1. Uses a subset of the MPLS OAM tools defined as described in 281 [I-D.ietf-mpls-tp-oam-framework]. 283 2. Supports 1+1, 1:1, and 1:N protection functions. 285 3. Is traffic engineered. 287 4. May be established and maintained via the management plane, or 288 using GMPLS protocols when a control plane is used. 290 5. Is either point-to-point or point-to-multipoint. Multipoint to 291 point and multipoint to multipoint LSPs are not permitted. 293 Note that an MPLS LSP is defined to include any present and future 294 MPLS capability, including those specifically added to support the 295 transport network requirements. 297 1.3.5. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER) 299 An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider 300 Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP, 301 as defined below. The terms MPLS-TP PE router and MPLS-TP P router 302 describe logical functions; a specific node may undertake only one of 303 these roles on a given LSP. 305 Note that the use of the term "router" in this context is historic 306 and neither requires nor precludes the ability to perform IP 307 forwarding. 309 1.3.5.1. MPLS-TP Provider Edge (PE) Router 311 An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts 312 client traffic and encapsulates it to be transported over an MPLS-TP 313 LSP. Encapsulation may be as simple as pushing a label, or it may 314 require the use of a pseudowire. An MPLS-TP PE exists at the 315 interface between a pair of layer networks. For an MS-PW, an MPLS-TP 316 PE may be either an S-PE or a T-PE, as defined in [RFC5659]. 318 1.3.5.2. MPLS-TP Provider (P) Router 320 An MPLS-TP Provider router is an MPLS-TP LSR that does not provide 321 MPLS-TP PE functionality for a given LSP. An MPLS-TP P router 322 switches LSPs which carry client traffic, but does not adapt client 323 traffic and encapsulate it to be carried over an MPLS-TP LSP. 325 1.3.5.3. Label Edge Router (LER) 327 An LSR that exists at the endpoints of an LSP and therefore pushes or 328 pops a label, i.e. does not perform a label swap on the particular 329 LSP under consideration. 331 1.3.6. Customer Edge (CE) 333 A Customer Edge (CE) is the client function sourcing or sinking 334 native service traffic to or from the MPLS-TP network. CEs on either 335 side of the MPLS-TP network are peers and view the MPLS-TP network as 336 a single point-to-point or point-to-multipoint link. 338 1.3.7. Edge-to-Edge LSP 340 An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit 341 zero or more provider LSRs. 343 1.3.8. Service LSP 345 A service LSP is an LSP that carries a single client service. 347 1.3.9. Layer Network 349 A layer network is defined in [G.805] and described in [RFC5654]. 351 1.3.10. Additional Definitions and Terminology 353 Detailed definitions and additional terminology may be found in 354 [RFC5654]. 356 1.4. Applicability 358 MPLS-TP can be used to construct packet transport networks and is 359 therefore applicable in any packet transport network context. It is 360 also applicable to subsets of a packet network where the transport 361 network operational model is deemed attractive. The following are 362 examples of MPLS-TP applicability models: 364 1. MPLS-TP provided by a network that only supports MPLS-TP LSPs and 365 PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or 366 LSRs), acting as a server for other layer 1, layer 2 and layer 3 367 networks (Figure 1). 369 2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs 370 and PWs (i.e. both LSPs and PWs that conform to the transport 371 profile and those that do not, exist between the PEs), acting as 372 a server for other layer 1, layer 2 and layer 3 networks 373 (Figure 2). 375 3. MPLS-TP as a server layer for client layer traffic of IP or MPLS 376 networks which do not use functions of the MPLS transport 377 profile. For MPLS traffic, the MPLS-TP server layer network uses 378 PW switching [RFC5659] or LSP stitching [RFC5150] at the PE that 379 terminates the MPLS-TP server layer (Figure 3). 381 These models are not mutually exclusive. 383 MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as 384 a server for other layer 1, layer 2 and layer 3 networks. 386 |<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->| 387 Only 389 MPLS-TP 390 +---+ LSP +---+ 391 +---+ Client | |----------| | Client +---+ 392 |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1| 393 +---+ | |----------| | +---+ 394 +---+ +---+ 396 Example a) [Ethernet] [Ethernet] [Ethernet] 397 layering [ PW ] 398 [-TP LSP ] 400 b) [ IP ] [ IP ] [ IP ] 401 [ Demux ] 402 [-TP LSP ] 404 Figure 1: MPLS-TP Server Layer Example 406 MPLS-TP LSP, provided by a network that also supports non-MPLS-TP 407 functions, acting as a server for other layer 1, layer 2 and 408 layer 3 networks. 410 |<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->| 412 MPLS-TP 413 +---+ LSP +---+ 414 +---+ Client | |----------| | Client +---+ 415 |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1| 416 +---+ | |----------| | +---+ 417 +---+ +---+ 419 Example a) [Ethernet] [Ethernet] [Ethernet] 420 layering [ PW ] 421 [-TP LSP ] 423 b) [ IP ] [ IP ] [ IP ] 424 [ Demux ] 425 [-TP LSP ] 427 Figure 2: MPLS-TP in MPLS Network Example 429 MPLS-TP as a server layer for client layer traffic of IP or MPLS 430 networks which do not use functions of the MPLS transport 431 profile. 433 |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| 434 Only 436 +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ 437 |CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2| 438 +---+ +----+ +----+ +----+ +----+ +---+ 439 (PW switching) (PW switching) 441 (a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ] 442 [ PW Seg ] [ PW Seg ] [ PW Seg ] 443 [ LSP ] [-TP LSP ] [ LSP ] 445 |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| 446 Only 448 +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ 449 |CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2| 450 +---+ +----+ +----+ +----+ +----+ +---+ 451 (LSP stitching) (LSP stitching) 453 (b) [ IP ] [ IP ] [ IP ] [ IP ] [ IP ] 454 [ LSP ] [-TP LSP ] [ LSP ] 456 Figure 3: MPLS-TP Transporting Client Service Traffic 458 2. MPLS Transport Profile Requirements 460 The requirements for MPLS-TP are specified in [RFC5654], 461 [I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req]. 462 This section provides a brief reminder to guide the reader and is 463 therefore not normative. It is not intended as a substitute for 464 these documents. 466 MPLS-TP must not modify the MPLS forwarding architecture and must be 467 based on existing pseudowire and LSP constructs. 469 Point to point LSPs may be unidirectional or bi-directional, and it 470 must be possible to construct congruent Bi-directional LSPs. 472 MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it 473 must be possible to detect if a merged LSP has been created. 475 It must be possible to forward packets solely based on switching the 476 MPLS or PW label. It must also be possible to establish and maintain 477 LSPs and/or pseudowires both in the absence or presence of a dynamic 478 control plane. When static provisioning is used, there must be no 479 dependency on dynamic routing or signaling. 481 OAM, protection and forwarding of data packets must be able to 482 operate without IP forwarding support. 484 It must be possible to monitor LSPs and pseudowires through the use 485 of OAM in the absence of control plane or routing functions. In this 486 case information gained from the OAM functions is used to initiate 487 path recovery actions at either the PW or LSP layers. 489 3. MPLS Transport Profile Overview 491 3.1. Packet Transport Services 493 One objective of MPLS-TP is to enable MPLS networks to provide packet 494 transport services with a similar degree of predictability to that 495 found in existing transport networks. Such packet transport services 496 inherit a number of characteristics, defined in [RFC5654]: 498 o In an environment where an MPLS-TP layer network is supporting a 499 client layer network, and the MPLS-TP layer network is supported 500 by a server layer network then operation of the MPLS-TP layer 501 network must be possible without any dependencies on either the 502 server or client layer network. 504 o The service provided by the MPLS-TP network to the client is 505 guaranteed not to fall below the agreed level regardless of other 506 client activity. 508 o The control and management planes of any client network layer that 509 uses the service is isolated from the control and management 510 planes of the MPLS-TP layer network, where the client network 511 layer is considered to be the native service of the MPLS-TP 512 network. 514 o Where a client network makes use of an MPLS-TP server that 515 provides a packet transport service, the level of co-ordination 516 required between the client and server layer networks is minimal 517 (preferably no co-ordination will be required). 519 o The complete set of packets generated by a client MPLS(-TP) layer 520 network using the packet transport service, which may contain 521 packets that are not MPLS packets (e.g. IP or CLNS packets used 522 by the control/management plane of the client MPLS(-TP) layer 523 network), are transported by the MPLS-TP server layer network. 525 o The packet transport service enables the MPLS-TP layer network 526 addressing and other information (e.g. topology) to be hidden from 527 any client layer networks using that service, and vice-versa. 529 These characteristics imply that a packet transport service does not 530 support a connectionless packet-switched forwarding mode. However, 531 this does not preclude it carrying client traffic associated with a 532 connectionless service. 534 Such packet transport services are very similar to Layer 2 Virtual 535 Private Networks as defined by the IETF. 537 3.2. Scope of the MPLS Transport Profile 539 Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are 540 primarily intended for packet transport applications. MPLS-TP is a 541 strict subset of MPLS, and comprises only those functions that are 542 necessary to meet the requirements of [RFC5654]. This includes MPLS 543 functions that were defined prior to [RFC5654] but that meet the 544 requirements of [RFC5654], together with additional functions defined 545 to meet those requirements. Some MPLS functions defined before 546 [RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a 547 way that it creates multipoint-to-point LSPs, and IP forwarding in 548 the data plane are explicitly excluded from MPLS-TP by that 549 requirements specification. 551 Note that MPLS as a whole will continue to evolve to include 552 additional functions that do not conform to the MPLS Transport 553 Profile or its requirements, and thus fall outside the scope of 554 MPLS-TP. 556 |<============================== MPLS ==============================>| 558 |<============= Pre-RFC5654 MPLS ================>| 559 { ECMP } 560 { LDP/non-TE LSPs } 561 { IP fwd } 563 |<================ MPLS-TP ====================>| 564 { Additional } 565 { Transport } 566 { Functions } 568 Figure 4: Scope of MPLS-TP 570 3.3. Architecture 572 MPLS-TP comprises the following architectural elements: 574 o A standard MPLS data plane [RFC3031] as profiled in 575 [I-D.fbb-mpls-tp-data-plane]. 577 o Sections, LSPs and PWs that provide a packet transport service for 578 a client network. 580 o Proactive and on-demand Operations, Administration and Maintenance 581 (OAM) functions to monitor and diagnose the MPLS-TP network, such 582 as connectivity check, connectivity verification, performance 583 monitoring and fault localisation. 585 o Optional control planes for LSPs and PWs, as well as support for 586 static provisioning and configuration. 588 o Optional path protection mechanisms to ensure that the packet 589 transport service survives anticipated failures and degradations 590 of the MPLS-TP network. 592 o Network management functions. 594 The MPLS-TP architecture for LSPs and PWs includes the following two 595 sets of functions: 597 o MPLS-TP client adaptation 599 o MPLS-TP forwarding 601 The adaptation functions interface the native service to MPLS-TP. 602 This includes the case where the native service is an MPLS-TP LSP. 604 The forwarding functions comprise the mechanisms required for 605 forwarding the encapsulated client traffic over an MPLS-TP server 606 layer network, for example PW and LSP labels. 608 3.3.1. MPLS-TP Client Adaptation Functions 610 The MPLS-TP native service adaptation functions interface the client 611 service to MPLS-TP. For pseudowires, these adaptation functions are 612 the payload encapsulation described in Section 4.4 of [RFC3985] and 613 Section 6 of [RFC5659]. For network layer client services, the 614 adaptation function uses the MPLS encapsulation format as defined in 615 [RFC3032]. 617 The purpose of this encapsulation is to abstract the client service 618 data plane from the MPLS-TP data plane, thus contributing to the 619 independent operation of the MPLS-TP network. 621 MPLS-TP is itself a client of an underlying server layer. MPLS-TP is 622 thus also bounded by a set of adaptation functions to this server 623 layer network, which may itself be MPLS-TP. These adaptation 624 functions provide encapsulation of the MPLS-TP frames and for the 625 transparent transport of those frames over the server layer network. 626 The MPLS-TP client inherits its Quality of Service (QoS) from the 627 MPLS-TP network, which in turn inherits its QoS from the server 628 layer. The server layer must therefore provide the necessary QoS to 629 ensure that the MPLS-TP client QoS commitments can be satisfied. 631 3.3.2. MPLS-TP Forwarding Functions 633 The forwarding functions comprise the mechanisms required for 634 forwarding the encapsulated client over an MPLS-TP server layer 635 network, for example PW and LSP labels. 637 MPLS-TP LSPs use the MPLS label switching operations and TTL 638 processing procedures defined in [RFC3031] and [RFC3032]. These 639 operations are highly optimised for performance and are not modified 640 by the MPLS-TP profile. 642 In addition, MPLS-TP PWs use the SS-PW and MS-PW forwarding 643 operations defined in [RFC3985] and [RFC5659]. The PW label is 644 processed by a PW forwarder and is always at the bottom of the label 645 stack for a given MPLS-TP layer network. 647 Per-platform label space is used for PWs. Either per-platform, per- 648 interface or other context-specific label space [RFC5331] may be used 649 for LSPs. 651 MPLS-TP forwarding is based on the label that identifies the 652 transport path (LSP or PW). The label value specifies the processing 653 operation to be performed by the next hop at that level of 654 encapsulation. A swap of this label is an atomic operation in which 655 the contents of the packet after the swapped label are opaque to the 656 forwarder. The only event that interrupts a swap operation is TTL 657 expiry. This is a fundamental architectural construct of MPLS to be 658 taken into account when designing protocol extensions that require 659 packets (e.g. OAM packets) to be sent to an intermediate LSR. 661 Further processing to determine the context of a packet occurs when a 662 swap operation is interrupted in this manner, or a pop operation 663 exposes a specific reserved label at the top of the stack, or the 664 packet is received with the GAL (Section 3.6) at the top of stack. 666 Otherwise the packet is forwarded according to the procedures in 667 [RFC3032]. 669 Point-to-point MPLS-TP LSPs can be either unidirectional or 670 bidirectional. 672 It must be possible to configure an MPLS-TP LSP such that the forward 673 and backward directions of a bidirectional MPLS-TP LSP are co-routed, 674 i.e. follow the same path. The pairing relationship between the 675 forward and the backward directions must be known at each LSR or LER 676 on a bidirectional LSP. 678 In normal conditions, all the packets sent over a PW or an LSP follow 679 the same path through the network and those that belong to a common 680 ordered aggregate are delivered in order. For example per-packet 681 equal cost multi-path (ECMP) load balancing is not applicable to 682 MPLS-TP LSPs. 684 Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default. 686 MPLS-TP supports Quality of Service capabilities via the MPLS 687 Differentiated Services (DiffServ) architecture [RFC3270]. Both 688 E-LSP and L-LSP MPLS DiffServ modes are supported. The Traffic Class 689 field (formerly the EXP field) of an MPLS label follows the 690 definition and processing rules of [RFC5462] and [RFC3270]. Note 691 that packet reordering between flows belonging to different traffic 692 classes may occur if more than one traffic class is supported on a 693 single LSP. 695 Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing 696 models described in [RFC3270] and [RFC3443] are supported in MPLS-TP. 698 3.4. MPLS-TP Native Services 700 This document describes the architecture for two native service 701 adaptation mechanisms, which provide encapsulation and demultiplexing 702 for native service traffic traversing an MPLS-TP network: 704 o A PW 706 o An MPLS Label 708 A PW provides any emulated service that the IETF has defined to be 709 provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A 710 registry of PW types is maintained by IANA. When the native service 711 adaptation is via a PW, the mechanisms described in Section 3.4.2 are 712 used. 714 An MPLS LSP Label can also be used as the adaptation, in which case 715 any native service traffic type supported by [RFC3031] and [RFC3032] 716 is allowed. Examples of such traffic types include IP, and MPLS- 717 labeled packets. Note that the latter case includes TE-LSPs 718 [RFC3209] and LSP based applications such as PWs, Layer 2 VPNs 719 [RFC4664], and Layer 3 VPNs [RFC4364]. When the native service 720 adaptation is via an MPLS label, the mechanisms described in 721 Section 3.4.3 are used. 723 3.4.1. MPLS-TP Client/Server Relationship 725 The MPLS-TP client server relationship is defined by the MPLS-TP 726 network boundary and the label context. It is not explicitly 727 indicated in the packet. In terms of the MPLS label stack, when the 728 client traffic type of the MPLS-TP network is an MPLS LSP or a PW, 729 then the S bits of all the labels in the MPLS-TP label stack carrying 730 that client traffic are zero; otherwise the bottom label of the 731 MPLS-TP label stack has the S bit set to 1 (i.e. there can only one S 732 bit set in a label stack). 734 The data plane behaviour of MPLS-TP is the same as the best current 735 practise for MPLS. This includes the setting of the S-Bit. In each 736 case, the S-bit is set to indicate the bottom (i.e. inner-most) label 737 in the label stack that is contiguous between the MPLS-TP server and 738 the client layer. Note that this best current practise differs 739 slightly from [RFC3032] which uses the S-bit to identify when MPLS 740 label processing stops and network layer processing starts. 742 The relationship of MPLS-TP to its clients is illustrated in 743 Figure 5. 745 PW-Based MPLS Labelled IP 746 Services Services Transport 747 |------------| |-----------------------------| |------------| 749 Emulated PW over LSP IP over LSP IP 750 Service 751 +------------+ 752 | PW Payload | 753 +------------+ +------------+ (CLIENTS) 754 |PW Lbl(S=1) | | IP | 755 +------------+ +------------+ +------------+ +------------+ 756 | PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP | 757 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 758 |PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)| 759 +------------+ +------------+ +------------+ +------------+ 760 |LSP Lbl(S=0)| 761 +------------+ (MPLS-TP) 763 ~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary 765 Note that in the PW over LSP case the client may omit its LSP Label if 767 penultimate hop popping has been agreed with its peer 769 Figure 5: MPLS-TP - Client Relationship 771 The data plane behaviour of MPLS-TP is the same as the best current 772 practise for MPLS. This includes the setting of the S-Bit. In each 773 case, the S-bit is set to indicate the bottom (i.e. inner-most) label 774 in the label stack that is contiguous between the MPLS-TP server and 775 the client layer. 777 Note that the label stacks shown above are divided between those 778 inside the MPLS-TP Network and those within the client network when 779 the client network is MPLS(-TP). They illustrate the smallest number 780 of labels possible. These label stacks could also include more 781 labels. 783 3.4.2. Pseudowire Adaptation 785 The architecture for an MPLS-TP network that provides PW emulated 786 services is based on the MPLS [RFC3031] and pseudowire [RFC3985] 787 architectures. Multi-segment pseudowires may optionally be used to 788 provide a packet transport service, and their use is consistent with 789 the MPLS-TP architecture. The use of MS-PWs may be motivated by, for 790 example, the requirements specified in [RFC5254]. If MS-PWs are 791 used, then the MS-PW architecture [RFC5659] also applies. 793 Figure 6 shows the architecture for an MPLS-TP network using single- 794 segment PWs. 796 |<--------------- Emulated Service ----------------->| 797 | | 798 | |<-------- Pseudowire -------->| | 799 | | encapsulated, packet | | 800 | | transport service | | 801 | | | | 802 | | |<------ LSP ------->| | | 803 | V V V V | 804 V AC +----+ +-----+ +----+ AC V 805 +-----+ | | PE1|=======\ /========| PE2| | +-----+ 806 | |----------|.......PW1.| \ / |............|----------| | 807 | CE1 | | | | | X | | | | | CE2 | 808 | |----------|.......PW2.| / \ |............|----------| | 809 +-----+ ^ | | |=======/ \========| | | ^ +-----+ 810 ^ | +----+ +-----+ +----+ | ^ 811 | | Provider Edge 1 ^ Provider Edge 2 | | 812 | | | | | 813 Customer | P Router | Customer 814 Edge 1 | | Edge 2 815 | | 816 | | 817 Native service Native service 819 Figure 6: MPLS-TP Architecture (Single Segment PW) 821 Figure 7 shows the architecture for an MPLS-TP network when multi- 822 segment pseudowires are used. Note that as in the SS-PW case, 823 P-routers may also exist. 825 |<----------- Pseudowire encapsulated ------------->| 826 | packet transport service | 827 | | 828 | | 829 | | 830 AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC 831 | V V V V V V | 832 | +----+ +-----+ +----+ +----+ | 833 +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ 834 | |---|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|---| | 835 |CE1| | | | | X | | | | | | |CE2| 836 | |---|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|---| | 837 +---+ | | |===============/ \=====| |==========| | | +---+ 838 ^ +----+ ^ +-----+ +----+ ^ +----+ ^ 839 | | ^ | | 840 | TE LSP | TE LSP | 841 | P-router | 842 | | 843 |<-------------------- Emulated Service ------------------->| 845 PW1-segment1 and PW1-segment2 are segments of the same MS-PW, 846 while PW2-segment1 and PW2-segment2 are segments of another MS-PW 848 Figure 7: MPLS-TP Architecture (Multi-Segment PW) 850 The corresponding MPLS-TP protocol stacks including PWs are shown in 851 Figure 8. In this figure the Transport Service Layer [RFC5654] is 852 identified by the PW demultiplexer (Demux) label and the Transport 853 Path Layer [RFC5654] is identified by the LSP Demux Label. 855 +-------------------+ /===================\ /===================\ 856 | Client Layer | H OAM PDU H H OAM PDU H 857 /===================\ H-------------------H H-------------------H 858 H PW Encap H H GACh H H GACh H 859 H-------------------H H-------------------H H-------------------H 860 H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H 861 H-------------------H H-------------------H H-------------------H 862 H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H 863 \===================/ \===================/ \===================/ 864 | Server Layer | | Server Layer | | Server Layer | 865 +-------------------+ +-------------------+ +-------------------+ 867 User Traffic PW OAM LSP OAM 869 Note: H(ighlighted) indicates the part of the protocol stack we are 870 considering in this document. 872 Figure 8: MPLS-TP Layer Network using Pseudowires 874 PWs and their associated labels may be configured or signaled. See 875 Section 3.11 for additional details related to configured service 876 types. See Section 3.9 for additional details related to signaled 877 service types. 879 3.4.2.1. Pseudowire Based Services 881 When providing a Virtual Private Wire Service (VPWS) , Virtual 882 Private Local Area Network Service (VPLS), Virtual Private Multicast 883 Service (VPMS) or Internet Protocol Local Area Network Service 884 (IPLS), pseudowires must be used to carry the client service. VPWS, 885 VLPS, and IPLS are described in [RFC4664]. VPMS is described in 886 [I-D.ietf-l2vpn-vpms-frmwk-requirements]. 888 3.4.3. Network Layer Adaptation 890 MPLS-TP LSPs can be used to transport network layer clients. This 891 document uses the term Network Layer in the same sense as it is used 892 in [RFC3031] and [RFC3032]. The network layer protocols supported by 893 [RFC3031] and [RFC3032] can be transported between service 894 interfaces. Examples are shown in Figure 5 above. Support for 895 network layer clients follows the MPLS architecture for support of 896 network layer protocols as specified in [RFC3031] and [RFC3032]. 898 With network layer adaptation, the MPLS-TP domain provides either a 899 uni-directional or bidirectional point-to-point connection between 900 two PEs in order to deliver a packet transport service to attached 901 customer edge (CE) nodes. For example, a CE may be an IP, MPLS or 902 MPLS-TP node. As shown in Figure 9, there is an attachment circuit 903 between the CE node on the left and its corresponding provider edge 904 (PE) node which provides the service interface, a bidirectional LSP 905 across the MPLS-TP network to the corresponding PE node on the right, 906 and an attachment circuit between that PE node and the corresponding 907 CE node for this service. 909 The attachment circuits may be heterogeneous (e.g., any combination 910 of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads 911 arrive at the service interface encapsulated in the Layer1/Layer2 912 encoding defined for that access link type. It should be noted that 913 the set of network layer protocols includes MPLS and hence MPLS 914 encoded packets with an MPLS label stack (the client MPLS stack), may 915 appear at the service interface. 917 |<------------- Client Network Layer ------------->| 918 | | 919 | |<---- Pkt Xport Service --->| | 920 | | | | 921 | | |<-- PSN Tunnel -->| | | 922 | V V V V | 923 V AC +----+ +---+ +----+ AC V 924 +-----+ | |PE1 | | | |PE2 | | +-----+ 925 | | |LSP | | | | | | | | | 926 | CE1 |----------| |========X=========| |----------| CE2 | 927 | | ^ |IP | | ^ | | ^ | | | ^ | | 928 +-----+ | | | | | | | | | | | | +-----+ 929 ^ | +----+ | +---+ | +----+ | | ^ 930 | | Provider | ^ | Provider | | 931 | | Edge | | | Edge | | 932 Customer | 1 | P-router | 2 | Customer 933 Edge 1 | TE TE | Edge 2 934 | LSP LSP | 935 | | 936 Native service Native service 938 Figure 9: MPLS-TP Architecture for Network Layer Clients 940 At the ingress service interface the client packets are received . 941 The PE pushes one or more labels onto the client packets which are 942 then label switched over the transport network. Correspondingly the 943 egress PE pops any labels added by the MPLS-TP networks and transmits 944 the packet for delivery to the attached CE via the egress service 945 interface. 947 /===================\ 948 H OAM PDU H 949 +-------------------+ H-------------------H /===================\ 950 | Client Layer | H GACh H H OAM PDU H 951 /===================\ H-------------------H H-------------------H 952 H Encap Label H H GAL (S=1) H H GACh H 953 H-------------------H H-------------------H H-------------------H 954 H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H 955 H-------------------H H-------------------H H-------------------H 956 H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H 957 \===================/ \===================/ \===================/ 958 | Server Layer | | Server Layer | | Server Layer | 959 +-------------------+ +-------------------+ +-------------------+ 961 User Traffic Service LSP OAM LSP OAM 963 Note: H(ighlighted) indicates the part of the protocol stack we are 964 considering in this document. 966 Figure 10: Domain of MPLS-TP Layer Network for IP and LSP Clients 968 In this figure the Transport Service Layer [RFC5654] is identified by 969 the Service LSP (SvcLSP) demultiplexer (Demux) label and the 970 Transport Path Layer [RFC5654] is identified by the LSP Demux Label. 971 Note that the functions of the Encapsulation label and the Service 972 Label shown above as SvcLSP Demux may be represented by a single 973 label stack entry. Additionally, the S-bit will always be zero when 974 the client layer is MPLS labelled. 976 Within the MPLS-TP transport network, the network layer protocols are 977 carried over the MPLS-TP network using a logically separate MPLS 978 label stack (the server stack). The server stack is entirely under 979 the control of the nodes within the MPLS-TP transport network and it 980 is not visible outside that network. Figure 10 shows how a client 981 network protocol stack (which may be an MPLS label stack and payload) 982 is carried over a network layer client service over an MPLS-TP 983 transport network. 985 A label per network layer protocol payload type that is to be 986 transported is required. When multiple protocol payload types are to 987 be carried over a single service a unique label stack entry must be 988 present for each payload type. Such labels are referred to as 989 "Encapsulation Labels", one of which is shown in Figure 10. 990 Encapsulation Label may be either configured or signaled. 992 Both an Encapsulation Label and a Service Label should be present in 993 the label stack when a particular packet transport service is 994 supporting more than one network layer protocol payload type. For 995 example, if both IP and MPLS are to be carried, as shown in Figure 9, 996 then two Encapsulation Labels are mapped on to a common Service 997 Label. 999 Note: The Encapsulation Label may be omitted when the transport 1000 service is supporting only one network layer protocol payload type. 1001 For example, if only MPLS labeled packets are carried over a service, 1002 then the Service Label (stack entry) provides both the payload type 1003 indication and service identification. 1005 Service labels are typically carried over an MPLS-TP LSP edge-to-edge 1006 (or transport path layer). An MPLS-TP edge-to-edge LSP is 1007 represented as an LSP Demux label as shown in Figure 10. An edge-to- 1008 edge LSP is commonly used when more than one service exists between 1009 two PEs. 1011 Note that the edge-to-edge LSP may be omitted when only one service 1012 exists between two PEs. For example, if only one service is carried 1013 between two PEs then a single Service Label could be used to provide 1014 both the service indication and the MPLS-TP edge-to-edge LSP. 1015 Alternatively, if multiple services exist between a pair of PEs then 1016 a per-client Service Label would be mapped on to a common MPLS-TP 1017 edge-to-edge LSP. 1019 As noted above, the layer 2 and layer 1 protocols used to carry the 1020 network layer protocol over the attachment circuits are not 1021 transported across the MPLS-TP network. This enables the use of 1022 different layer 2 and layer 1 protocols on the two attachment 1023 circuits. 1025 At each service interface, Layer 2 addressing must be used to ensure 1026 the proper delivery of a network layer packet to the adjacent node. 1027 This is typically only an issue for LAN media technologies (e.g., 1028 Ethernet) which have Media Access Control (MAC) addresses. In cases 1029 where a MAC address is needed, the sending node must set the 1030 destination MAC address to an address that ensures delivery to the 1031 adjacent node. That is the CE sets the destination MAC address to an 1032 address that ensures delivery to the PE, and the PE sets the 1033 destination MAC address to an address that ensures delivery to the 1034 CE. The specific address used is technology type specific and is not 1035 specified in this document. In some technologies the MAC address 1036 will need to be configured. (Examples for the Ethernet case include 1037 a configured unicast MAC address for the adjacent node, or even using 1038 the broadcast MAC address when the CE-PE service interface is 1039 dedicated. The configured address is then used as the destination 1040 MAC address for all packets sent over the service interface.) 1041 Note that when two CEs, which peer with each other, operate over a 1042 network layer transport service and run a routing protocol such as 1043 IS-IS or OSPF, some care should be taken to configure the routing 1044 protocols to use point-to-point adjacencies. The specifics of such 1045 configuration is outside the scope of this document. See [RFC5309] 1046 for additional details. 1048 The CE to CE service types and corresponding labels may be configured 1049 or signaled . See Section 3.11 for additional details related to 1050 configured service types. See Section 3.9 for additional details 1051 related to signaled service types. 1053 3.5. Identifiers 1055 Identifiers are used to uniquely distinguish entities in an MPLS-TP 1056 network. These include operators, nodes, LSPs, pseudowires, and 1057 their associated maintenance entities. 1058 [I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are 1059 compatible with existing MPLS control plane identifiers, as well as a 1060 set of identifiers that may be used when no IP control plane is 1061 available. 1063 3.6. Generic Associated Channel (G-ACh) 1065 For correct operation of the OAM it is important that the OAM packets 1066 fate-share with the data packets. In addition in MPLS-TP it is 1067 necessary to discriminate between user data payloads and other types 1068 of payload. For example, a packet may be associated with a Signaling 1069 Communication Channel (SCC), or a channel used for Automatic 1070 Protection Switching (APS) data. This is achieved by carrying such 1071 packets on a generic control channel associated to the LSP, PW or 1072 section. 1074 MPLS-TP makes use of such a generic associated channel (G-ACh) to 1075 support Fault, Configuration, Accounting, Performance and Security 1076 (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC 1077 or other packet types in-band over LSPs or PWs. The G-ACh is defined 1078 in [RFC5586] and is similar to the Pseudowire Associated Channel 1079 [RFC4385], which is used to carry OAM packets over pseudowires. The 1080 G-ACh is indicated by a generic associated channel header (ACH), 1081 similar to the Pseudowire VCCV control word; this header is present 1082 for all Sections, LSPs and PWs making use of FCAPS functions 1083 supported by the G-ACh. 1085 For pseudowires, the G-ACh uses the first four bits of the pseudowire 1086 control word to provide the initial discrimination between data 1087 packets and packets belonging to the associated channel, as described 1088 in [RFC4385]. When this first nibble of a packet, immediately 1089 following the label at the bottom of stack, has a value of '1', then 1090 this packet belongs to a G-ACh. The first 32 bits following the 1091 bottom of stack label then have a defined format called an associated 1092 channel header (ACH), which further defines the content of the 1093 packet. The ACH is therefore both a demultiplexer for G-ACh traffic 1094 on the PW, and a discriminator for the type of G-ACh traffic. 1096 When the OAM or other control message is carried over an LSP, rather 1097 than over a pseudowire, it is necessary to provide an indication in 1098 the packet that the payload is something other than a user data 1099 packet. This is achieved by including a reserved label with a value 1100 of 13 in the label stack. This reserved label is referred to as the 1101 'G-ACh Label (GAL)', and is defined in [RFC5586]. When a GAL is 1102 found, it indicates that the payload begins with an ACH. The GAL is 1103 thus a demultiplexer for G-ACh traffic on the LSP, and the ACH is a 1104 discriminator for the type of traffic carried on the G-ACh. Note 1105 however that MPLS-TP forwarding follows the normal MPLS model, and 1106 that a GAL is invisible to an LSR unless it is the top label in the 1107 label stack. The only other circumstance under which the label stack 1108 may be inspected for a GAL is when the TTL has expired. Any MPLS-TP 1109 component that intentionally performs this inspection must assume 1110 that it is asynchronous with respect to the forwarding of other 1111 packets. All operations on the label stack are in accordance with 1112 [RFC3031] and [RFC3032]. 1114 In MPLS-TP, the 'G-ACh Label (GAL)' always appears at the bottom of 1115 the label stack (i.e. its S bit is set to 1). 1117 The G-ACh must only be used for channels that are an adjunct to the 1118 data service. Examples of these are OAM, APS, MCC and SCC, but the 1119 use is not restricted to these services. The G-ACh must not be used 1120 to carry additional data for use in the forwarding path, i.e. it must 1121 not be used as an alternative to a PW control word, or to define a PW 1122 type. 1124 At the server layer, bandwidth and QoS commitments apply to the gross 1125 traffic on the LSP, PW or section. Since the G-ACh traffic is 1126 indistinguishable from the user data traffic, protocols using the 1127 G-ACh must take into consideration the impact they have on the user 1128 data that they are sharing resources with. Conversely, capacity must 1129 be made available for important G-ACh uses such as protection and 1130 OAM. In addition, protocols using the G-ACh must conform to the 1131 security and congestion considerations described in [RFC5586]. 1133 Figure 11 shows the reference model depicting how the control channel 1134 is associated with the pseudowire protocol stack. This is based on 1135 the reference model for VCCV shown in Figure 2 of [RFC5085]. 1137 +-------------+ +-------------+ 1138 | Payload | < FCAPS > | Payload | 1139 +-------------+ +-------------+ 1140 | Demux / | < ACH for PW > | Demux / | 1141 |Discriminator| |Discriminator| 1142 +-------------+ +-------------+ 1143 | PW | < PW > | PW | 1144 +-------------+ +-------------+ 1145 | PSN | < LSP > | PSN | 1146 +-------------+ +-------------+ 1147 | Physical | | Physical | 1148 +-----+-------+ +-----+-------+ 1149 | | 1150 | ____ ___ ____ | 1151 | _/ \___/ \ _/ \__ | 1152 | / \__/ \_ | 1153 | / \ | 1154 +--------| MPLS/MPLS-TP Network |---+ 1155 \ / 1156 \ ___ ___ __ _/ 1157 \_/ \____/ \___/ \____/ 1159 Figure 11: PWE3 Protocol Stack Reference Model showing the G-ACh 1161 PW associated channel messages are encapsulated using the PWE3 1162 encapsulation, so that they are handled and processed in the same 1163 manner (or in some cases, an analogous manner) as the PW PDUs for 1164 which they provide a control channel. 1166 Figure 12 shows the reference model depicting how the control channel 1167 is associated with the LSP protocol stack. 1169 +-------------+ +-------------+ 1170 | Payload | < FCAPS > | Payload | 1171 +-------------+ +-------------+ 1172 |Discriminator| < ACH on LSP > |Discriminator| 1173 +-------------+ +-------------+ 1174 |Demultiplexer| < GAL on LSP > |Demultiplexer| 1175 +-------------+ +-------------+ 1176 | PSN | < LSP > | PSN | 1177 +-------------+ +-------------+ 1178 | Physical | | Physical | 1179 +-----+-------+ +-----+-------+ 1180 | | 1181 | ____ ___ ____ | 1182 | _/ \___/ \ _/ \__ | 1183 | / \__/ \_ | 1184 | / \ | 1185 +--------| MPLS/MPLS-TP Network |---+ 1186 \ / 1187 \ ___ ___ __ _/ 1188 \_/ \____/ \___/ \____/ 1190 Figure 12: MPLS Protocol Stack Reference Model showing the LSP 1191 Associated Control Channel 1193 3.7. Operations, Administration and Maintenance (OAM) 1195 MPLS-TP must be able to operate in environments where IP is not used 1196 in the forwarding plane. Therefore, the default mechanism for OAM 1197 demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated 1198 Channel (Section 3.6). Forwarding based on IP addresses for user or 1199 OAM packets is not required for MPLS-TP. 1201 [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined 1202 alert mechanisms that enable an MPLS LSR to identify and process MPLS 1203 OAM packets when the OAM packets are encapsulated in an IP header. 1204 These alert mechanisms are based on TTL expiration and/or use an IP 1205 destination address in the range 127/8 for IPv4 and that same range 1206 embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the 1207 OAM packets are encapsulated in an IP header, these mechanisms are 1208 the default mechanisms for MPLS networks in general for identifying 1209 MPLS OAM packets. MPLS-TP must be able to operate in an environments 1210 where IP forwarding is not supported, and thus the G-ACh/GAL is the 1211 default mechanism to demultiplex OAM packets in MPLS-TP. 1213 MPLS-TP supports a comprehensive set of OAM capabilities for packet 1214 transport applications, with equivalent capabilities to those 1215 provided in SONET/SDH. 1217 MPLS-TP defines mechanisms to differentiate specific packets (e.g. 1218 OAM, APS, MCC or SCC) from those carrying user data packets on the 1219 same transport path (i.e. section, LSP or PW). These mechanisms are 1220 described in [RFC5586]. 1222 MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of 1223 OAM capabilities is available to perform fault management (e.g. fault 1224 detection and localisation) and performance monitoring (e.g. packet 1225 delay and loss measurement) of the LSP, PW or section. The framework 1226 for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. 1228 MPLS-TP OAM packets share the same fate as their corresponding data 1229 packets, and are identified through the Generic Associated Channel 1230 mechanism [RFC5586]. This uses a combination of an Associated 1231 Channel Header (ACH) and a G-ACh Label (GAL) to create a control 1232 channel associated to an LSP, Section or PW. 1234 OAM and monitoring in MPLS-TP is based on the concept of maintenance 1235 entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A 1236 Maintenance Entity can be viewed as the association of two 1237 Maintenance End Points (MEPs). A Maintenance Entity Group (MEG) is a 1238 collection of one or more MEs that belongs to the same transport path 1239 and that are maintained and monitored as a group. The MEPs that form 1240 an ME limit the OAM responsibilities of an OAM flow to within the 1241 domain of a transport path or segment, in the specific layer network 1242 that is being monitored and managed. 1244 An ME may also include a set of Maintenance Intermediate Points 1245 (MIPs). Maintenance End Points (MEPs) are capable of sourcing and 1246 sinking OAM flows, while Maintenance Intermediate Points (MIPs) can 1247 only sink or respond to OAM flows from within a MEG, or originate 1248 notifications as a result of specific network conditions. 1250 The following MPLS-TP MEs are specified in 1251 [I-D.ietf-mpls-tp-oam-framework]: 1253 o A Section Maintenance Entity (SME), allowing monitoring and 1254 management of MPLS-TP Sections (between MPLS LSRs). 1256 o A LSP Maintenance Entity (LME), allowing monitoring and management 1257 of an edge-to-edge LSP (between LERs). 1259 o A PW Maintenance Entity (PME), allowing monitoring and management 1260 of an edge-to-edge SS/MS-PWs (between T-PEs). 1262 o An LSP Tandem Connection Maintenance Entity (LTCME). 1264 A G-ACh packet may be directed to an individual MIP along the path of 1265 an LSP or MS-PW by setting the appropriate TTL in the label for the 1266 G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and 1267 the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw]. Note that this 1268 works when the location of MIPs along the LSP or PW path is known by 1269 the MEP. There may be circumstances where this is not the case, e.g. 1270 following restoration using a facility bypass LSP. In these cases, 1271 tools to trace the path of the LSP may be used to determine the 1272 appropriate setting for the TTL to reach a specific MIP. 1274 Within an LSR or PE, MEPs and MIPs can only be placed where MPLS 1275 layer processing is performed on a packet. The architecture mandates 1276 that this must occur at least once. 1278 MEPs may only act as a sink of OAM packets when the label associated 1279 with the LSP or PW for that ME is popped. MIPs can only be placed 1280 where an exception to the normal forwarding operation occurs. A MEP 1281 may act as a source of OAM packets wherever a label is pushed or 1282 swapped. For example, on an MS-PW, a MEP may source OAM within an 1283 S-PE or a T-PE, but a MIP may only be associated with a S-PE and a 1284 sink MEP can only be associated with a T-PE. 1286 The MPLS-TP OAM architecture supports a wide range of OAM functions 1287 to check continuity, to verify connectivity and to monitor the 1288 preformance of the path, to generate, filter and manage local and 1289 remote defect alarms. These functions are applicable to any layer 1290 defined within MPLS-TP, i.e. to MPLS-TP Sections, LSPs and PWs. 1292 The MPLS-TP OAM tool-set must be able to operate without relying on a 1293 dynamic control plane or IP functionality in the datapath. In the 1294 case of an MPLS-TP deployment in a network in which IP functionality 1295 is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD 1296 and VCCV, may be used. 1298 3.8. LSP Return Path 1300 Management, control and OAM protocol functions may require response 1301 packets to be delivered from the receiver back to the originator of a 1302 message exchange. This section provides a summary of the return path 1303 options in MPLS-TP networks. 1305 In this discussion we assume that A and B are terminal LSRs (i.e. 1306 LERs) for an MPLS-TP LSP and that Y is an intermediate LSR along the 1307 LSP. In the unidirectional case, A is taken to be the upstream and B 1308 the downstream LSR with respect to the LSP. We consider the 1309 following cases for the various types of LSPs: 1311 1. Packet transmission from B to A 1313 2. Packet transmission from Y to A 1315 3. Packet transmission from B to Y 1317 Note that a return path may not always exist, and that packet 1318 transmission in one or more of the above cases may not be possible. 1319 In general the existence and nature of return paths for MPLS-TP LSPs 1320 is determined by operational provisioning. 1322 3.8.1. Return Path Types 1324 There are two types of return path that may be used for the delivery 1325 of traffic from a downstream node D to an upstream node U either: 1327 a. D maintains an MPLS-TP LSP back to U which is specifically 1328 designated to carry return traffic for the original LSP, or 1330 b. D has some other unspecified means of directing traffic back to 1331 U. 1333 The first option is referred to as an "in-band" return path, the 1334 second as an "out-of-band" return path. 1336 There are various possibilities for "out-of-band" return paths. Such 1337 a path may, for example, be based on ordinary IP routing. In this 1338 case packets would be forwarded as usual to a destination IP address 1339 associated with U. In an MPLS-TP network that is also an IP/MPLS 1340 network, such a forwarding path may traverse the same physical links 1341 or logical transport paths used by MPLS-TP. An out-of-band return 1342 path may also be indirect, via a distinct Data Communication Network 1343 (DCN) (provided, for example, by the method specified in [RFC5718]); 1344 or it may be via one or more other MPLS-TP LSPs. 1346 3.8.2. Point-to-Point Unidirectional LSPs 1348 Case 1 In this situation, either an in-band or out-of-band return 1349 path may be used to deliver traffic from B back to A. 1351 In the in-band case there is in essence an associated 1352 bidirectional LSP between A and B, and the discussion for 1353 such LSPs below applies. It is therefore recommended for 1354 reasons of operational simplicity that point-to-point 1355 unidirectional LSPs be provisioned as associated 1356 bidirectional LSPs (which may also be co-routed) whenever 1357 return traffic from B to A is required. Note that the two 1358 directions of such an LSP may have differing bandwidth 1359 allocations and QoS characteristics. 1361 Case 2 In this case only the out-of-band return path option is 1362 available. However, an additional out-of-band possibility is 1363 worthy of note here: if B is known to have a return path to 1364 A, then Y can arrange to deliver return traffic to A by first 1365 sending it to B along the original LSP. The mechanism by 1366 which B recognises the need for and performs this forwarding 1367 operation is protocol-specific. 1369 Case 3 In this case only the out-of-band return path option is 1370 available. However, if B has a return path to A, then in a 1371 manner analogous to the previous case B can arrange to 1372 deliver return traffic to Y by first sending it to A along 1373 that return path. The mechanism by which A recognises the 1374 need for and performs this forwarding operation is protocol- 1375 specific. 1377 3.8.3. Point-to-Point Associated Bidirectional LSPs 1379 For Case 1, B has a natural in-band return path to A, the use of 1380 which is typically preferred for return traffic, although out-of-band 1381 return paths are also applicable. 1383 For Cases 2 and 3, the considerations are the same as those for 1384 point-to-point unidirectional LSPs. 1386 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs 1388 For all of Cases 1, 2, and 3, a natural in-band return path exists in 1389 the form of the LSP itself, and its use is typically preferred for 1390 return traffic. Out-of-band return paths, however, are also 1391 applicable, primarily as an alternative means of delivery in case the 1392 in-band return path has failed. 1394 3.9. Control Plane 1396 A distributed dynamic control plane may be used to enable dynamic 1397 service provisioning in an MPLS-TP network. Where the requirements 1398 specified in [RFC5654] can be met, the MPLS Transport Profile uses 1399 existing standard control plane protocols for LSPs and PWs. 1401 Note that a dynamic control plane is not required in an MPLS-TP 1402 network. See Section 3.11 for further details on statically 1403 configured and provisioned MPLS-TP services. 1405 Figure 13 illustrates the relationship between the MPLS-TP control 1406 plane, the forwarding plane, the management plane, and OAM for point- 1407 to-point MPLS-TP LSPs or PWs. 1409 +------------------------------------------------------------------+ 1410 | | 1411 | Network Management System and/or | 1412 | | 1413 | Control Plane for Point to Point Connections | 1414 | | 1415 +------------------------------------------------------------------+ 1416 | | | | | | 1417 .............|.....|... ....|.....|.... ....|.....|............ 1418 : +---+ | : : +---+ | : : +---+ | : 1419 : |OAM| | : : |OAM| | : : |OAM| | : 1420 : +---+ | : : +---+ | : : +---+ | : 1421 : | | : : | | : : | | : 1422 \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/ 1423 --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+-- 1424 /: +----+ |ing | : : |ing | : : |ing | +----+ :\ 1425 : +--------+ : : +--------+ : : +--------+ : 1426 ''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' 1428 Note: 1429 1) NMS may be centralised or distributed. Control plane is 1430 distributed. 1431 2) 'Edge' functions refers to those functions present at 1432 the edge of a PSN domain, e.g. NSP or classification. 1433 3) The control plane may be transported over the server 1434 layer, an LSP or a G-ACh. 1436 Figure 13: MPLS-TP Control Plane Architecture Context 1438 The MPLS-TP control plane is based on existing MPLS and PW control 1439 plane protocols. MPLS-TP uses Generalized MPLS (GMPLS) signaling 1440 ([RFC3945], [RFC3471], [RFC3473]) for LSPs and Targeted LDP (T-LDP) 1441 [RFC4447] [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] 1442 for pseudowires. 1444 MPLS-TP requires that any signaling be capable of being carried over 1445 an out-of-band signaling network or a signaling control channel such 1446 as the one described in [RFC5718]. Note that while T-LDP signaling 1447 is traditionally carried in-band in IP/MPLS networks, this does not 1448 preclude its operation over out-of-band channels. References to 1449 T-LDP in this document do not preclude the definition of alternative 1450 PW control protocols for use in MPLS-TP. 1452 PW control (and maintenance) takes place separately from LSP tunnel 1453 signaling. The main coordination between LSP and PW control will 1454 occur within the nodes that terminate PWs. The control planes for 1455 PWs and LSPs may be used independently, and one may be employed 1456 without the other. This translates into the four possible scenarios: 1457 (1) no control plane is employed; (2) a control plane is used for 1458 both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs; 1459 (4) a control plane is used for PWs, but not LSPs. The PW and LSP 1460 control planes, collectively, must satisfy the MPLS-TP control plane 1461 requirements reviewed in the MPLS-TP Control Plane Framework 1462 [I-D.abfb-mpls-tp-control-plane-framework]. When client services are 1463 provided directly via LSPs, all requirements must be satisfied by the 1464 LSP control plane. When client services are provided via PWs, the PW 1465 and LSP control planes operate in combination and some functions may 1466 be satisfied via the PW control plane while others are provided to 1467 PWs by the LSP control plane. 1469 Note that if MPLS-TP is being used in a multi-layer network, a number 1470 of control protocol types and instances may be used. This is 1471 consistent with the MPLS architecture which permits each label in the 1472 label stack to be allocated and signaled by its own control protocol. 1474 The distributed MPLS-TP control plane may provide the following 1475 functions: 1477 o Signaling 1479 o Routing 1481 o Traffic engineering and constraint-based path computation 1483 In a multi-domain environment, the MPLS-TP control plane supports 1484 different types of interfaces at domain boundaries or within the 1485 domains. These include the User-Network Interface (UNI), Internal 1486 Network Node Interface (I-NNI), and External Network Node Interface 1487 (E-NNI). Note that different policies may be defined that control 1488 the information exchanged across these interface types. 1490 The MPLS-TP control plane is capable of activating MPLS-TP OAM 1491 functions as described in the OAM section of this document 1492 Section 3.7, e.g. for fault detection and localisation in the event 1493 of a failure in order to efficiently restore failed transport paths. 1495 The MPLS-TP control plane supports all MPLS-TP data plane 1496 connectivity patterns that are needed for establishing transport 1497 paths, including protected paths as described in Section 3.12. 1498 Examples of the MPLS-TP data plane connectivity patterns are LSPs 1499 utilising the fast reroute backup methods as defined in [RFC4090] and 1500 ingress-to-egress 1+1 or 1:1 protected LSPs. 1502 The MPLS-TP control plane provides functions to ensure its own 1503 survivability and to enable it to recover gracefully from failures 1504 and degradations. These include graceful restart and hot redundant 1505 configurations. Depending on how the control plane is transported, 1506 varying degrees of decoupling between the control plane and data 1507 plane may be achieved. 1509 3.10. Inter-domain Connectivity 1511 A number of methods exist to support inter-domain operation of 1512 MPLS-TP, for example: 1514 o Inter-domain TE LSPs [RFC4216] 1516 o Multi-segment Pseudowires [RFC5659] 1518 o LSP stitching [RFC5150] 1520 o back-to-back attachment circuits [RFC5659] 1522 An important consideration in selecting an inter-domain connectivity 1523 mechanism is the degree of layer network isolation and types of OAM 1524 required by the operator. The selection of which technique to use in 1525 a particular deployment scenario is outside the scope of this 1526 document. 1528 3.11. Static Operation of LSPs and PWs 1530 A PW or LSP may be statically configured without the support of a 1531 dynamic control plane. This may be either by direct configuration of 1532 the PEs/LSRs, or via a network management system. Static operation 1533 is independent for a specific PW or LSP instance. Thus it should be 1534 possible for a PW to be statically configured, while the LSP 1535 supporting it is set up by a dynamic control plane. When static 1536 configuration mechanisms are used, care must be taken to ensure that 1537 loops are not created. 1539 3.12. Survivability 1541 Survivability requirements for MPLS-TP are specified in 1542 [I-D.ietf-mpls-tp-survive-fwk]. 1544 A wide variety of resiliency schemes have been developed to meet the 1545 various network and service survivability objectives. For example, 1546 as part of the MPLS/PW paradigms, MPLS provides methods for local 1547 repair using back-up LSP tunnels ([RFC4090]), while pseudowire 1548 redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the 1549 protection for the PW cannot be fully provided by the underlying LSP 1550 (i.e. where the backup PW terminates on a different target PE node 1551 than the working PW in dual homing scenarios, or where protection of 1552 the S-PE is required). Additionally, GMPLS provides a well known set 1553 of control plane driven protection and restoration mechanisms 1554 [RFC4872]. MPLS-TP provides additional protection mechanisms that 1555 are optimised for both linear topologies and ring topologies, and 1556 that operate in the absence of a dynamic control plane. These are 1557 specified in [I-D.ietf-mpls-tp-survive-fwk]. 1559 Different protection schemes apply to different deployment topologies 1560 and operational considerations. Such protection schemes may provide 1561 different levels of resiliency, for example: 1563 o Two concurrent traffic paths (1+1). 1565 o one active and one standby path with guaranteed bandwidth on both 1566 paths (1:1). 1568 o one active path and a standby path the resources or which are 1569 shared by one or more other active paths (shared protection). 1571 The applicability of any given scheme to meet specific requirements 1572 is outside the current scope of this document. 1574 The characteristics of MPLS-TP resiliency mechanisms are as follows: 1576 o Optimised for linear, ring or meshed topologies. 1578 o Use OAM mechanisms to detect and localise network faults or 1579 service degenerations. 1581 o Include protection mechanisms to coordinate and trigger protection 1582 switching actions in the absence of a dynamic control plane. This 1583 is known as an Automatic Protection Switching (APS) mechanism. 1585 o MPLS-TP recovery schemes are applicable to all levels in the 1586 MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment 1587 and end-to-end recovery. 1589 o MPLS-TP recovery mechanisms support the coordination of protection 1590 switching at multiple levels to prevent race conditions occurring 1591 between a client and its server layer. 1593 o MPLS-TP recovery mechanisms can be data plane, control plane or 1594 management plane based. 1596 o MPLS-TP supports revertive and non-revertive behaviour. 1598 3.13. Path Segment Tunnels 1600 In order to monitor, protect and manage a portion of an LSP, a new 1601 architectural element is defined called the Path Segment Tunnel 1602 (PST). A PST is a hierarchical LSP [RFC3031] which is defined and 1603 used for the purposes of OAM monitoring, protection or management of 1604 LSP segments or concatenated LSP segments. 1606 A PST is defined between the edges of the portion of the LSP that 1607 needs to be monitored, protected or managed. Maintenance messages 1608 can be initiated at the edge of the PST and sent to the peer edge of 1609 the PST or to an intermediate point along the PST by setting the TTL 1610 value at the PST level accordingly. 1612 For example in Figure 14, three PSTs are configured to allow 1613 monitoring, protection and management of the LSP concatenated 1614 segments. One PST is defined between PE1 and PE2, the second between 1615 PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of 1616 these three PSTs may be monitored, protected, or managed 1617 independently. 1619 ========================== End to End LSP ============================= 1621 |<--------- Carrier 1 --------->| |<----- Carrier 2 ----->| 1623 ---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |--- 1625 |============= PST =============|==PST==|========= PST =========| 1626 (Carrier 1) (Carrier 2) 1628 Figure 14: PSTs in inter-carrier network 1630 The end-to-end traffic of the LSP, including data traffic and control 1631 traffic (OAM, Protection Switching Control, management and signaling 1632 messages) is tunneled within the PST by means of label stacking as 1633 defined in [RFC3031]. 1635 The mapping between an LSP and a PST can be 1:1, in which case it is 1636 similar to the ITU-T Tandem Connection element [G.805]. The mapping 1637 can also be 1:N to allow aggregated monitoring, protection and 1638 management of a set of LSP segments or concatenated LSP segments. 1639 Figure 15 shows a PST which is used to aggregate a set of 1640 concatenated LSP segments for the LSP from PEx to PEt and the LSP 1641 from PEa to PEd. Note that such a construct is useful, for example, 1642 when the LSPs traverse a common portion of the network and they have 1643 the same Traffic Class. 1645 |PEx|--|PEy|-+ +-|PEz|--|PEt| 1646 | | 1647 | |<---------- Carrier 1 --------->| | 1648 | +-----+ +---+ +---+ +-----+ | 1649 +--| |---| |---| |----| |--+ 1650 | PE1 | | P | | P | | PE2 | 1651 +--| |---| |---| |----| |--+ 1652 | +-----+ +---+ + P + +-----+ | 1653 | |============= PST ==============| | 1654 |PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd| 1656 Figure 15: PST for a Set of Concatenated LSP Segments 1658 3.13.1. Provisioning of PST 1660 PSTs can be provisioned either statically or using control plane 1661 signaling procedures. The make-before-break procedures which are 1662 supported by MPLS allow the creation of a PST on existing LSPs in- 1663 service without traffic disruption. A PST can be defined 1664 corresponding to one or more end-to-end tunneled LSPs. New end-to- 1665 end LSPs which are tunneled within the PST can be set up. Traffic of 1666 the existing LSPs is switched over to the new end-to-end tunneled 1667 LSPs. The old end-to-end LSPs can then be torn down. 1669 3.14. Pseudowire Segment Tunnels 1671 Pseudowire segment tunnels are for further study. 1673 3.15. Network Management 1675 The network management architecture and requirements for MPLS-TP are 1676 specified in [I-D.ietf-mpls-tp-nm-framework] and 1677 [I-D.ietf-mpls-tp-nm-req]. These derive from the generic 1678 specifications described in ITU-T G.7710/Y.1701 [G.7710] for 1679 transport technologies. It also incorporates the OAM requirements 1680 for MPLS Networks [RFC4377] and MPLS-TP Networks 1681 [I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements 1682 to cover the modifications necessary for fault, configuration, 1683 performance, and security in a transport network. 1685 The Equipment Management Function (EMF) of an MPLS-TP Network Element 1686 (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through 1687 which a management system manages the NE. The Management 1688 Communication Channel (MCC), realised by the G-ACh, provides a 1689 logical operations channel between NEs for transferring Management 1690 information. For the management interface from a management system 1691 to an MPLS-TP NE, there is no restriction on which management 1692 protocol is used. The MCC is used to provision and manage an end-to- 1693 end connection across a network where some segments are created/ 1694 managed by, for example, Netconf [RFC4741] or SNMP [RFC3411] and 1695 other segments by XML or CORBA interfaces. Maintenance operations 1696 are run on a connection (LSP or PW) in a manner that is independent 1697 of the provisioning mechanism. An MPLS-TP NE is not required to 1698 offer more than one standard management interface. In MPLS-TP, the 1699 EMF must be capable of statically provisioning LSPs for an LSR or 1700 LER, and PWs for a PE, as well as any associated MEPs and MIPs, as 1701 per Section 3.11. 1703 Fault Management (FM) functions within the EMF of an MPLS-TP NE 1704 enable the supervision, detection, validation, isolation, correction, 1705 and alarm handling of abnormal conditions in the MPLS-TP network and 1706 its environment. FM must provide for the supervision of transmission 1707 (such as continuity, connectivity, etc.), software processing, 1708 hardware, and environment. Alarm handling includes alarm severity 1709 assignment, alarm suppression/aggregation/correlation, alarm 1710 reporting control, and alarm reporting. 1712 Configuration Management (CM) provides functions to control, 1713 identify, collect data from, and provide data to MPLS-TP NEs. In 1714 addition to general configuration for hardware, software protection 1715 switching, alarm reporting control, and date/time setting, the EMF of 1716 the MPLS-TP NE also supports the configuration of maintenance entity 1717 identifiers (such as MEP ID and MIP ID). The EMF also supports the 1718 configuration of OAM parameters as a part of connectivity management 1719 to meet specific operational requirements. These may specify whether 1720 the operational mode is one-time on-demand or is periodic at a 1721 specified frequency. 1723 The Performance Management (PM) functions within the EMF of an 1724 MPLS-TP NE support the evaluation and reporting of the behaviour of 1725 the NEs and the network. One particular requirement for PM is to 1726 provide coherent and consistent interpretation of the network 1727 behaviour in a hybrid network that uses multiple transport 1728 technologies. Packet loss measurement and delay measurements may be 1729 collected and used to detect performance degradation. This is 1730 reported via fault management to enable corrective actions to be 1731 taken (e.g. protection switching), and via performance monitoring for 1732 Service Level Agreement (SLA) verification and billing. Collection 1733 mechanisms for performance data should be capable of operating on- 1734 demand or pro-actively. 1736 4. Security Considerations 1738 The introduction of MPLS-TP into transport networks means that the 1739 security considerations applicable to both MPLS and PWE3 apply to 1740 those transport networks. Furthermore, when general MPLS networks 1741 that utilise functionality outside of the strict MPLS Transport 1742 Profile are used to support packet transport services, the security 1743 considerations of that additional functionality also apply. 1745 For pseudowires, the security considerations of [RFC3985] and 1746 [RFC5659] apply. 1748 Packets that arrive on an interface with a given label value should 1749 not be forwarded unless that label value is assigned to an LSP or PW 1750 to a peer LSR or PE that is reachable via that interface. 1752 Each MPLS-TP solution must specify the additional security 1753 considerations that apply. This is discussed further in 1754 [I-D.fang-mpls-tp-security-framework]. 1756 5. IANA Considerations 1758 IANA considerations resulting from specific elements of MPLS-TP 1759 functionality will be detailed in the documents specifying that 1760 functionality. 1762 This document introduces no additional IANA considerations in itself. 1764 6. Acknowledgements 1766 The editors wish to thank the following for their contribution to 1767 this document: 1769 o Rahul Aggarwal 1771 o Dieter Beller 1773 o Malcolm Betts 1775 o Italo Busi 1777 o John E Drake 1779 o Hing-Kam Lam 1781 o Marc Lasserre 1783 o Vincenzo Sestito 1785 o Nurit Sprecher 1786 o Martin Vigoureux 1788 o Yaacov Weingarten 1790 o The participants of ITU-T SG15 1792 7. Open Issues 1794 This section contains a list of issues that must be resolved before 1795 last call. 1797 o 1799 8. References 1801 8.1. Normative References 1803 [G.7710] "ITU-T Recommendation 1804 G.7710/Y.1701 (07/07), 1805 "Common equipment 1806 management function 1807 requirements"", 2005. 1809 [G.805] "ITU-T Recommendation 1810 G.805 (11/95), "Generic 1811 Functional Architecture 1812 of Transport Networks"", 1813 November 1995. 1815 [RFC3031] Rosen, E., Viswanathan, 1816 A., and R. Callon, 1817 "Multiprotocol Label 1818 Switching Architecture", 1819 RFC 3031, January 2001. 1821 [RFC3032] Rosen, E., Tappan, D., 1822 Fedorkow, G., Rekhter, 1823 Y., Farinacci, D., Li, 1824 T., and A. Conta, "MPLS 1825 Label Stack Encoding", 1826 RFC 3032, January 2001. 1828 [RFC3270] Le Faucheur, F., Wu, L., 1829 Davie, B., Davari, S., 1830 Vaananen, P., Krishnan, 1831 R., Cheval, P., and J. 1832 Heinanen, "Multi-Protocol 1833 Label Switching (MPLS) 1834 Support of Differentiated 1835 Services", RFC 3270, 1836 May 2002. 1838 [RFC3471] Berger, L., "Generalized 1839 Multi-Protocol Label 1840 Switching (GMPLS) 1841 Signaling Functional 1842 Description", RFC 3471, 1843 January 2003. 1845 [RFC3473] Berger, L., "Generalized 1846 Multi-Protocol Label 1847 Switching (GMPLS) 1848 Signaling Resource 1849 ReserVation Protocol- 1850 Traffic Engineering 1851 (RSVP-TE) Extensions", 1852 RFC 3473, January 2003. 1854 [RFC3985] Bryant, S. and P. Pate, 1855 "Pseudo Wire Emulation 1856 Edge-to-Edge (PWE3) 1857 Architecture", RFC 3985, 1858 March 2005. 1860 [RFC4090] Pan, P., Swallow, G., and 1861 A. Atlas, "Fast Reroute 1862 Extensions to RSVP-TE for 1863 LSP Tunnels", RFC 4090, 1864 May 2005. 1866 [RFC4385] Bryant, S., Swallow, G., 1867 Martini, L., and D. 1868 McPherson, "Pseudowire 1869 Emulation Edge-to-Edge 1870 (PWE3) Control Word for 1871 Use over an MPLS PSN", 1872 RFC 4385, February 2006. 1874 [RFC4447] Martini, L., Rosen, E., 1875 El-Aawar, N., Smith, T., 1876 and G. Heron, "Pseudowire 1877 Setup and Maintenance 1878 Using the Label 1879 Distribution Protocol 1880 (LDP)", RFC 4447, 1881 April 2006. 1883 [RFC4872] Lang, J., Rekhter, Y., 1884 and D. Papadimitriou, 1885 "RSVP-TE Extensions in 1886 Support of End-to-End 1887 Generalized Multi- 1888 Protocol Label Switching 1889 (GMPLS) Recovery", 1890 RFC 4872, May 2007. 1892 [RFC5085] Nadeau, T. and C. 1893 Pignataro, "Pseudowire 1894 Virtual Circuit 1895 Connectivity Verification 1896 (VCCV): A Control Channel 1897 for Pseudowires", 1898 RFC 5085, December 2007. 1900 [RFC5462] Andersson, L. and R. 1901 Asati, "Multiprotocol 1902 Label Switching (MPLS) 1903 Label Stack Entry: "EXP" 1904 Field Renamed to "Traffic 1905 Class" Field", RFC 5462, 1906 February 2009. 1908 [RFC5586] Bocci, M., Vigoureux, M., 1909 and S. Bryant, "MPLS 1910 Generic Associated 1911 Channel", RFC 5586, 1912 June 2009. 1914 8.2. Informative References 1916 [I-D.abfb-mpls-tp-control-plane-framework] Andersson, L., Berger, 1917 L., Fang, L., Bitar, N., 1918 Takacs, A., and M. 1919 Vigoureux, "MPLS-TP 1920 Control Plane Framework", 1921 draft-abfb-mpls-tp- 1922 control-plane-framework- 1923 01 (work in progress), 1924 July 2009. 1926 [I-D.fang-mpls-tp-security-framework] Fang, L. and B. Niven- 1927 Jenkins, "Security 1928 Framework for MPLS-TP", d 1929 raft-fang-mpls-tp- 1930 security-framework-00 1931 (work in progress), 1932 July 2009. 1934 [I-D.fbb-mpls-tp-data-plane] Frost, D., Bryant, S., 1935 and M. Bocci, "MPLS 1936 Transport Profile Data 1937 Plane Architecture", draf 1938 t-fbb-mpls-tp-data-plane- 1939 00 (work in progress), 1940 February 2010. 1942 [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, 1943 K., Nadeau, T., and G. 1944 Swallow, "BFD For MPLS 1945 LSPs", 1946 draft-ietf-bfd-mpls-07 1947 (work in progress), 1948 June 2008. 1950 [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F., 1951 Niven-Jenkins, B., 1952 Brungard, D., and L. Jin, 1953 "Framework and 1954 Requirements for Virtual 1955 Private Multicast Service 1956 (VPMS)", draft-ietf- 1957 l2vpn-vpms-frmwk- 1958 requirements-02 (work in 1959 progress), October 2009. 1961 [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, 1962 "MPLS-TP Identifiers", dr 1963 aft-ietf-mpls-tp- 1964 identifiers-00 (work in 1965 progress), November 2009. 1967 [I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E., 1968 and H. Lam, "MPLS-TP 1969 Network Management 1970 Framework", draft-ietf- 1971 mpls-tp-nm-framework-04 1972 (work in progress), 1973 January 2010. 1975 [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, 1976 "MPLS TP Network 1977 Management Requirements", 1978 draft-ietf-mpls-tp-nm- 1979 req-06 (work in 1980 progress), October 2009. 1982 [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and 1983 B. Niven-Jenkins, 1984 "MPLS-TP OAM Framework", 1985 draft-ietf-mpls-tp-oam- 1986 framework-04 (work in 1987 progress), December 2009. 1989 [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., 1990 and M. Betts, 1991 "Requirements for OAM in 1992 MPLS Transport Networks", 1993 draft-ietf-mpls-tp-oam- 1994 requirements-04 (work in 1995 progress), December 2009. 1997 [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. 1998 Farrel, "Multiprotocol 1999 Label Switching Transport 2000 Profile Survivability 2001 Framework", draft-ietf- 2002 mpls-tp-survive-fwk-03 2003 (work in progress), 2004 November 2009. 2006 [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., 2007 Balus, F., Bitar, N., 2008 Shah, H., Aissaoui, M., 2009 Rusmisel, J., Serbest, 2010 Y., Malis, A., Metz, C., 2011 McDysan, D., Sugimoto, 2012 J., Duckett, M., Loomis, 2013 M., Doolan, P., Pan, P., 2014 Pate, P., Radoaca, V., 2015 Wada, Y., and Y. Seo, 2016 "Dynamic Placement of 2017 Multi Segment Pseudo 2018 Wires", draft-ietf-pwe3- 2019 dynamic-ms-pw-10 (work in 2020 progress), October 2009. 2022 [I-D.ietf-pwe3-redundancy] Muley, P. and V. Place, 2023 "Pseudowire (PW) 2024 Redundancy", draft-ietf- 2025 pwe3-redundancy-02 (work 2026 in progress), 2027 October 2009. 2029 [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., 2030 Metz, C., Duckett, M., 2031 Bocci, M., Balus, F., and 2032 M. Aissaoui, "Segmented 2033 Pseudowire", draft-ietf- 2034 pwe3-segmented-pw-13 2035 (work in progress), 2036 August 2009. 2038 [RFC3209] Awduche, D., Berger, L., 2039 Gan, D., Li, T., 2040 Srinivasan, V., and G. 2041 Swallow, "RSVP-TE: 2042 Extensions to RSVP for 2043 LSP Tunnels", RFC 3209, 2044 December 2001. 2046 [RFC3411] Harrington, D., Presuhn, 2047 R., and B. Wijnen, "An 2048 Architecture for 2049 Describing Simple Network 2050 Management Protocol 2051 (SNMP) Management 2052 Frameworks", STD 62, 2053 RFC 3411, December 2002. 2055 [RFC3443] Agarwal, P. and B. Akyol, 2056 "Time To Live (TTL) 2057 Processing in Multi- 2058 Protocol Label Switching 2059 (MPLS) Networks", 2060 RFC 3443, January 2003. 2062 [RFC3945] Mannie, E., "Generalized 2063 Multi-Protocol Label 2064 Switching (GMPLS) 2065 Architecture", RFC 3945, 2066 October 2004. 2068 [RFC4216] Zhang, R. and J. Vasseur, 2069 "MPLS Inter-Autonomous 2070 System (AS) Traffic 2071 Engineering (TE) 2072 Requirements", RFC 4216, 2073 November 2005. 2075 [RFC4364] Rosen, E. and Y. Rekhter, 2076 "BGP/MPLS IP Virtual 2077 Private Networks (VPNs)", 2078 RFC 4364, February 2006. 2080 [RFC4377] Nadeau, T., Morrow, M., 2081 Swallow, G., Allan, D., 2082 and S. Matsushima, 2083 "Operations and 2084 Management (OAM) 2085 Requirements for Multi- 2086 Protocol Label Switched 2087 (MPLS) Networks", 2088 RFC 4377, February 2006. 2090 [RFC4379] Kompella, K. and G. 2091 Swallow, "Detecting 2092 Multi-Protocol Label 2093 Switched (MPLS) Data 2094 Plane Failures", 2095 RFC 4379, February 2006. 2097 [RFC4664] Andersson, L. and E. 2098 Rosen, "Framework for 2099 Layer 2 Virtual Private 2100 Networks (L2VPNs)", 2101 RFC 4664, September 2006. 2103 [RFC4741] Enns, R., "NETCONF 2104 Configuration Protocol", 2105 RFC 4741, December 2006. 2107 [RFC5150] Ayyangar, A., Kompella, 2108 K., Vasseur, JP., and A. 2109 Farrel, "Label Switched 2110 Path Stitching with 2111 Generalized Multiprotocol 2112 Label Switching Traffic 2113 Engineering (GMPLS TE)", 2114 RFC 5150, February 2008. 2116 [RFC5254] Bitar, N., Bocci, M., and 2117 L. Martini, "Requirements 2118 for Multi-Segment 2119 Pseudowire Emulation 2120 Edge-to-Edge (PWE3)", 2121 RFC 5254, October 2008. 2123 [RFC5309] Shen, N. and A. Zinin, 2124 "Point-to-Point Operation 2125 over LAN in Link State 2126 Routing Protocols", 2127 RFC 5309, October 2008. 2129 [RFC5331] Aggarwal, R., Rekhter, 2130 Y., and E. Rosen, "MPLS 2131 Upstream Label Assignment 2132 and Context-Specific 2133 Label Space", RFC 5331, 2134 August 2008. 2136 [RFC5654] Niven-Jenkins, B., 2137 Brungard, D., Betts, M., 2138 Sprecher, N., and S. 2139 Ueno, "Requirements of an 2140 MPLS Transport Profile", 2141 RFC 5654, September 2009. 2143 [RFC5659] Bocci, M. and S. Bryant, 2144 "An Architecture for 2145 Multi-Segment Pseudowire 2146 Emulation Edge-to-Edge", 2147 RFC 5659, October 2009. 2149 [RFC5718] Beller, D. and A. Farrel, 2150 "An In-Band Data 2151 Communication Network For 2152 the MPLS Transport 2153 Profile", RFC 5718, 2154 January 2010. 2156 Authors' Addresses 2158 Matthew Bocci (editor) 2159 Alcatel-Lucent 2160 Voyager Place, Shoppenhangers Road 2161 Maidenhead, Berks SL6 2PJ 2162 United Kingdom 2164 Phone: 2165 EMail: matthew.bocci@alcatel-lucent.com 2166 Stewart Bryant (editor) 2167 Cisco Systems 2168 250 Longwater Ave 2169 Reading RG2 6GB 2170 United Kingdom 2172 Phone: 2173 EMail: stbryant@cisco.com 2175 Dan Frost (editor) 2176 Cisco Systems 2178 Phone: 2179 Fax: 2180 EMail: danfrost@cisco.com 2181 URI: 2183 Lieven Levrau 2184 Alcatel-Lucent 2185 7-9, Avenue Morane Sulnier 2186 Velizy 78141 2187 France 2189 Phone: 2190 EMail: lieven.levrau@alcatel-lucent.com 2192 Lou Berger 2193 LabN 2195 Phone: +1-301-468-9228 2196 Fax: 2197 EMail: lberger@labn.net 2198 URI: