idnits 2.17.1 draft-ietf-mpls-tp-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1132 has weird spacing: '...renamed to "T...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (June 29, 2009) is 5414 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Address' is mentioned on line 491, but not defined == Unused Reference: 'I-D.ietf-mpls-cosfield-def' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: 'RFC4201' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'I-D.bryant-filsfils-fat-pw' is defined on line 1249, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.7710' == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-06 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-ms-pw-arch (ref. 'I-D.ietf-pwe3-ms-pw-arch') == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-01 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-redundancy (ref. 'I-D.ietf-pwe3-redundancy') ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-nm-req-02 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-00 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-02 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-survive-fwk-00 == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-09 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-12 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 6 errors (**), 0 flaws (~~), 15 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: Standards Track S. Bryant, Ed. 5 Expires: December 31, 2009 Cisco Systems 6 L. Levrau 7 Alcatel-Lucent 8 June 29, 2009 10 A Framework for MPLS in Transport Networks 11 draft-ietf-mpls-tp-framework-01 13 Status of This Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 31, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document specifies an archiectectural framework for the 50 application of MPLS in transport networks. It describes a profile of 51 MPLS that enables operational models typical in transport networks 52 networks, while providing additional OAM, survivability and other 53 maintenance functions not currently supported by MPLS. 55 Requirements Language 57 Although this document is not a protocol specification, the key words 58 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 59 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 60 are to be interpreted as described in RFC2119 [RFC2119] and are to be 61 interpreted as instructions to the protocol designers producing 62 solutions that satisfy the architectural concepts set out in this 63 document.. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Motivation and Background . . . . . . . . . . . . . . . . 3 69 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 72 2. Introduction to Requirements . . . . . . . . . . . . . . . . . 6 73 3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 7 74 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 7 75 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3. MPLS-TP Forwarding Domain . . . . . . . . . . . . . . . . 10 77 3.4. MPLS-TP Transport Domain . . . . . . . . . . . . . . . . . 11 78 3.5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11 79 3.6. Operations, Administration and Maintenance (OAM) . . . . . 13 80 3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 17 81 3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 20 82 3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 22 83 3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 22 84 3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 23 85 3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 23 86 3.11. Network Management . . . . . . . . . . . . . . . . . . . . 24 87 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 92 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 94 1. Introduction 96 1.1. Motivation and Background 98 This document describes a framework for a Multiprotocol Label 99 Switching Transport Profile (MPLS-TP). It presents the architectural 100 framework for MPLS-TP, definining those elements of MPLS applicable 101 to supporting the requirements in [I-D.ietf-mpls-tp-requirements] and 102 what new protocol elements are required. 104 Bandwidth demand continues to grow worldwide, stimulated by the 105 accelerating growth and penetration of new packet based services and 106 multimedia applications: 108 o Packet-based services such as Ethernet, Voice over IP (VoIP), 109 Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP 110 Television (IPTV), Radio Access Network (RAN) backhauling, etc., 112 o Applications with various bandwidth and Quality of Service (QoS) 113 requirements. 115 This growth in demand has resulted in dramatic increases in access 116 rates that are, in turn, driving dramatic increases in metro and core 117 network bandwidth requirements. 119 Over the past two decades, the evolving optical transport 120 infrastructure (Synchronous Optical Networking (SONET)/Synchronous 121 Digital Hierarchy (SDH), Optical Transport Network (OTN)) has 122 provided carriers with a high benchmark for reliability and 123 operational simplicity. To achieve this, these existing transport 124 technologies have been designed with specific characteristics : 126 o Strictly connection-oriented connectivity, which may be long-lived 127 and may be provisioned manually or by network management. 129 o A high level of protection and availability. 131 o Quality of service. 133 o Extended OAM capabilities. 135 Carriers are looking to evolve such transport networks to support 136 packet based services and networks, and to take advantage of the 137 flexibility and cost benefits of packet switching technology. While 138 MPLS is a maturing packet technology that is already playing an 139 important role in transport networks and services, not all of MPLS's 140 capabilities and mechanisms are needed and/or consistent with 141 transport network operations. There are also transport technology 142 characteristics that are not currently reflected in MPLS. 144 The types of packet transport services delivered by transport 145 networks are very similar to Layer 2 Virtual Private Networks defined 146 by the IETF. 148 There are thus two objectives for MPLS-TP: 150 1. To enable MPLS to be deployed in a transport network and operated 151 in a similar manner to existing transport technologies. 153 2. To enable MPLS to support packet transport services with a 154 similar degree of predictability to that found in existing 155 transport networks. 157 In order to achieve these objectives, there is a need to create a 158 common set of new functions that are applicable to both MPLS networks 159 in general, and those blonging to the MPLS-TP profile. 161 MPLS-TP therefore defines a profile of MPLS targeted at transport 162 applications and networks. This profile specifies the specific MPLS 163 characteristics and extensions required to meet transport 164 requirements. An equipment conforming to MPLS-TP MUST support this 165 profile. An MPLS-TP conformant equipment MAY support additional MPLS 166 features. A carrier may deploy some of those additional features in 167 the transport layer of their network if they find them to be 168 beneficial. 170 1.2. Applicability 172 Figure 1 illustrates the range of services that MPLS-TP is intended 173 to address. MPLS-TP is intended to support a range of layer 1, layer 174 2 and layer 3 services, and is not limited to layer 3 services only. 175 Networks implementing MPLS-TP may choose to only support a subset of 176 these services. 178 MPLS-TP Solution exists 179 over this spectrum 180 |<-------------------------------->| 182 cl-ps Multi-Service co-cs & co-ps 183 (cl-ps & co-ps) (Label is 184 | | service context) 185 | | | 186 |<------------------------------|--------------------------------->| 187 | | | 188 L3 Only L1, L2, L3 Services L1, L2 Services 189 Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP 191 Figure 1: MPLS-TP Applicability 193 The diagram above shows the spectrum of services that can be 194 supported by MPLS. MPLS-TP solutions are primarily intended for 195 packet transport applications. These can be deployed using a profile 196 of MPLS that is strictly connection oriented and does not rely on IP 197 forwarding or routing (shown on the right hand side of the figure), 198 or in conjunction with an MPLS network that does use IP forwarding 199 and that supports a broader range of IP services. This is the multi- 200 service solution in the centre of the figure. 202 1.3. Scope 204 This document describes a framework for a Tranport Profile of 205 Multiprotocol Label Switching (MPLS-TP). It presents the 206 architectural framework for MPLS-TP, definining those elements of 207 MPLS applicable to supporting the requirements in 208 [I-D.ietf-mpls-tp-requirements] and what new protocol elements are 209 required. 211 This document describes the architecture for MPLS-TP when the LSP 212 client is a PW. The transport of IP and MPLS, other than carried 213 over a PW, is outside the scope of this document. This does not 214 preclude the use of LSPs conforming to the MPLS transport profile 215 from being used to carry IP or other MPLS LSPs by general purpose 216 MPLS networks. 218 1.4. Terminology 220 Term Definition 221 ------- ----------------------------------------- 222 LSP Label Switched Path 223 MPLS-TP MPLS Transport profile 224 SDH Synchronous Digital Hierarchy 225 ATM Asynchronous Transfer Mode 226 OTN Optical Transport Network 227 cl-ps Connectionless - Packet Switched 228 co-cs Connection Oriented - Circuit Switched 229 co-ps Connection Oriented - Packet Switched 230 OAM Operations, Adminitration and Maintenance 231 G-ACh Generic Associated Channel 232 GAL Generic Alert Label 233 MEP Maintenance End Point 234 MIP Maintenance Intermediate Point 235 APS Automatic Protection Switching 236 SCC Signaling Communication Channel 237 MCC Management Communication Channel 238 EMF Equipment Management Function 239 FM Fault Management 240 CM Configuration Management 241 PM Performance Management 243 Detailed definitions and additional terminology may be found in 244 [I-D.ietf-mpls-tp-requirements]. 246 2. Introduction to Requirements 248 The requirements for MPLS-TP are specified in 249 [I-D.ietf-mpls-tp-requirements], [I-D.ietf-mpls-tp-oam-requirements], 250 and [I-D.ietf-mpls-tp-nm-req]. This section provides a brief 251 reminder to guide the reader. It is not intended as a substitute for 252 these documents. 254 MPLS-TP MUST NOT modify the MPLS forwarding architecture and MUST be 255 based on existing pseudowire and LSP constructs. Any new mechanisms 256 and capabilities added to support transport networks and packet 257 transport services must be able to interoperate with existing MPLS 258 and pseudowire control and forwarding planes. 260 Point to point LSPs MAY be unidirectional or bi-directional, and it 261 MUST be possible to construct congruent Bi-directional LSPs. Point 262 to multipoint LSPs are unidirectional. 264 MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it 265 MUST be possible to detect if a merged LSP has been created. 267 It MUST be possible to forward packets solely based on switching the 268 MPLS or PW label. It MUST also be possible to establish and maintain 269 LSPs and/or pseudowires both in the absence or presence of a dynamic 270 control plane. When static provisioning is used, there MUST be no 271 dependency on dynamic routing or signaling. 273 OAM, protection and forwarding of data packets MUST be able to 274 operate without IP forwarding support. 276 It MUST be possible to monitor LSPs and pseudowires through the use 277 of OAM in the absence of control plane or routing functions. In this 278 case information gained from the OAM functions is used to initiate 279 path recovery actions at either the PW or LSP layers. 281 3. Transport Profile Overview 283 3.1. Packet Transport Services 285 The types of packet transport services provided by existing transport 286 networks are similar to MPLS Layer 2 VPNs. A key characteristic of 287 packet transport services is that the network used to provide the 288 service does not participate in the any IP routing protocols present 289 in the client, or use the IP addresses in client packets to forward 290 those packets. The network is therefore transparent to IP in the 291 client service. 293 MPLS-TP MUST use one of the Layer 2 VPN services defined in [PPVPN 294 architecture] to provide a packet transport service. 296 MPLS-TP LSPs MAY also be used to transport traffic for which the 297 immediate client of the MPLS-TP LSP is not a Layer 2 VPN. However, 298 for the purposes of this document, we do not refer to these traffic 299 types as belonging to a packet transport service. Such clients 300 include IP and MPLS LSPs. 302 3.2. Architecture 304 The architecture for a transport profile of MPLS (MPLS-TP) is based 305 on the MPLS [RFC3031], pseudowire [RFC3985], and multi-segment 306 pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as illustrated 307 in Figure 2. 309 |<-------------- Emulated Service ---------------->| 310 | | 311 | |<------- Pseudo Wire ------>| | 312 | | | | 313 | | |<-- PSN Tunnel -->| | | 314 | V V V V | 315 V AC +----+ +----+ AC V 316 +-----+ | | PE1|==================| PE2| | +-----+ 317 | |----------|............PW1.............|----------| | 318 | CE1 | | | | | | | | CE2 | 319 | |----------|............PW2.............|----------| | 320 +-----+ ^ | | |==================| | | ^ +-----+ 321 ^ | +----+ +----+ | | ^ 322 | | Provider Edge 1 Provider Edge 2 | | 323 | | | | 324 Customer | | Customer 325 Edge 1 | | Edge 2 326 | | 327 | | 328 Native service Native service 330 Figure 2: MPLS-TP Architecture (Single Segment PW) 332 Native |<------------Pseudowire-------------->| Native 333 Service | PSN PSN | Service 334 (AC) | |<--cloud->| |<-cloud-->| | (AC) 335 | V V V V V V | 336 | +----+ +-----+ +----+ | 337 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 338 | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | 339 | CE1| | | | | | | | | |CE2 | 340 | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | 341 +----+ | | |===========| |==========| | | +----+ 342 ^ +----+ ^ +-----+ ^ +----+ ^ 343 | | | | 344 | TE LSP TE LSP | 345 | | 346 | | 347 |<---------------- Emulated Service ----------------->| 349 MPLS-TP Architecture (Multi-Segment PW) 351 The above figures illustrates the MPLS-TP architecture used to 352 provide a point-to-point packet transport service, or VPWS. In this 353 case, the MPLS-TP forwarding plane is a profile of the MPLS LSP and 354 SS-PW or MS-PW forwarding architecture as detailed in section 355 Section 3.3. 357 This document describes the architecture for MPLS-TP when the LSP 358 client is a PW. The transport of IP and MPLS, other than carried 359 over a PW, is outside the scope of this document. This does not 360 preclude the use of LSPs conforming to the MPLS transport profile 361 from being used to carry IP or other MPLS LSPs by general purpose 362 MPLS networks. LSP hierarchy MAY be used within the MPLS-TP network, 363 so that more than one LSP label MAY appear in the label stack. 365 +---------------------------+ 366 | PW Native service | 367 /===========================\ 368 H PW Encapsulation H \ <---- PW Control word 369 H---------------------------H \ <---- Normalised client 370 H PW OAM H MPLS-TP channel 371 H---------------------------H / 372 H PW Demux (S=1) H / 373 H---------------------------H \ 374 H LSP OAM H \ 375 H---------------------------H / MPLS-TP Path(s) 376 H LSP Demultiplexer(s) H / 377 \===========================/ 378 | Server | 379 +---------------------------+ 381 Figure 3: Domain of MPLS-TP Layer Network using Pseudowires 383 Figure (Figure 3) illustrates the protocol stack to be used when 384 pseudowires are carried over MPLS-TP LSPs. 386 When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used 387 to carry a client service. For compatibility with transport 388 nomenclature, the PW may be referred to as the MPLS-TP Channel and 389 the LSP may be referred to as the MPLS-TP Path. 391 Note that in MPLS-TP environments where IP is used for control or OAM 392 purposes, IP MAY be carried over the LSP demultiplexers as per 393 RFC3031 [RFC3031], or directly over the server. 395 PW OAM, PSN OAM and PW client data are mutually exclusive and never 396 exist in the same packet. 398 The MPLS-TP definition applies to the following two domains: 400 o MPLS-TP Forwarding Domain 402 o MPLS-TP Transport Domain 404 3.3. MPLS-TP Forwarding Domain 406 A set of client-to-MPLS-TP adaptation functions interface the client 407 to MPLS-TP. For pseudowires, this adaptation function is the PW 408 forwarder shown in Figure 4a of [RFC3985]. The PW label is used for 409 forwarding in this case and is always at the bottom of the label 410 stack. The operation of the MPLS-TP network is independent of the 411 payload carried by the MPLS-TP PW packet. 413 MPLS-TP is itself a client of an underlying server layer. MPLS-TP is 414 thus bounded by a set of adaptation functions to this server layer 415 network. These adaptation functions provide encapsulation of the 416 MPLS-TP frames and for the transparent transport of those frames over 417 the server layer network. The MPLS-TP client inherits its QoS from 418 the MPLS-TP network, which in turn inherits its QoS from the server 419 layer. The server layer must therefore provide the neccesary Quality 420 of Service (QoS) to ensure that the MPLS-TP client QoS commitments 421 are satisfied. 423 MPLS-TP LSPs use the MPLS label switching operations defined in 424 [RFC3031]. These operations are highly optimized for performance and 425 are not modified by the MPLS-TP profile. 427 During forwarding a label is pushed to associate a forwarding 428 equivalence class (FEC) with the LSP or PW. This specifies the 429 processing operaton to be performed by the next hop at that level of 430 encapsulation. A swap of this label is an atomic operation in which 431 the contents of the packet after the swapped label are opaque to the 432 forwarder. The only event that interrupts a swap operation is TTL 433 expiry, in which case the packet may be inspected and either 434 discarded or subjected to further processing within the LSR. TTL 435 expiry causes an exception which forces a packet to be further 436 inspected and processed. While this occurs, the forwarding of 437 succeeding packets continues without interruption. Therefore, the 438 only way to cause a P (intermediate) LSR to inspect a packet (for 439 example for OAM purposes) is to set the TTL to expire at that LSR. 441 MPLS-TP PWs support the PW and MS-PW forwarding operations defined 442 in[RFC3985] and [I-D.ietf-pwe3-ms-pw-arch]. 444 The Traffic Class field (formerly the MPLS EXP field) follows the 445 definition and processing rules of [RFC5462] and [RFC3270]. Only the 446 pipe and short-pipe models are supported in MPLS-TP. 448 The MPLS encapsulation format is as defined in RFC 3032[RFC3032]. 449 Per-platform label space is used for PWs. Either per-platform or 450 per-interface label space may be used for LSPs. 452 Point to point MPLS-TP LSPs can be either unidirectional or 453 bidirectional. Point-to-multipoint MPLS-TP LSPs are unidirectional. 454 Point-to-multipont PWs are currently being defined in the IETF and 455 may be incorporated in MPLS-TP if required. 457 It MUST be possible to configure an MPLS-TP LSP such that the forward 458 and backward directions of a bidirectional MPLS-TP LSP are co-routed 459 i.e. they follow the same path. The pairing relationship between the 460 forward and the backward directions must be known at each LSR or LER 461 on a bidirectional LSP. 463 Per-packet equal cost multi-path (ECMP) load balancing is not 464 applicable to MPLS-TP LSPs. 466 Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default. 468 Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270 469 [RFC3270] 471 3.4. MPLS-TP Transport Domain 473 This document specifies the architecture when the client of the 474 MPLS-TP LSP is a PW. Note, however, that in MPLS-TP environments 475 where IP is used for control or OAM purposes, IP MAY be carried over 476 the the LSPs or directly over the server, as described in 477 Section 3.2. In this case, the MPLS-TP transport domain consists of 478 the PW encapsulation mechanisms, including the PW control word. 480 3.5. Addressing 482 Editor's note: This section will be updated after publication of the 483 MPLS-TP Addressing Architecture draft. 485 MPLS-TP distinguishes between adressing used to identify nodes in the 486 network, and identifiers used for demultiplexing and forwarding. 487 This distinction is illustrated in Figure 4. 489 NMS Control/Signalling 490 ..... ..... 491 [Address]| | [Address] 492 | | 493 +-----+---------+------+ 494 Address = Node | | | | 495 ID in forwarding plane | V V | 496 | | 497 | MEP or MIP | 498 | dmux | 499 | svcid | 500 | src | 501 +--^-------------------+ 502 | 503 OAM: OAM | 504 dmux= [GAL/GACH]........... 505 or ________________________________________ 506 IP (________________________________________) 507 svc context=ID/FEC PWE=ID1 508 SRC=IP . 509 . 510 IDx 512 Figure 4: Addressing in MPLS-TP 514 Editor's note: The figure above arose from discussions in the MPLS-TP 515 design team. It will be clarified in a future verson of this draft. 517 IPv4 or IPv6 addresses are used to identify MPLS-TP nodes by default 518 for network management and signaling purposes. 520 In the forwarding plane, identfiers are required for the service 521 context (provided by the FEC), and for OAM. OAM requires both a 522 demultiplexer and an address for the source of the OAM packet. 524 For MPLS in general where IP addressing is used, IPv4 or IPv6 is used 525 by default. However, MPLS-TP must be able to operate in environments 526 where IP is not used in the forwarding plane. Therefore, the default 527 mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the 528 generic associated channel. Forwarding based on IP addresses for 529 user or OAM packets is NOT REQUIRED for MPLS-TP. 531 RFC 4379 [RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have 532 defined alert mechanisms that enable a MPLS LSR to identify and 533 process MPLS OAM packets when the OAM packets are encapsulated in an 534 IP header. These alert mechanisms are based on TTL expiration and/or 535 use an IP destination address in the range 127/8. These mechanisms 536 are the default mechanisms for MPLS networks in general for 537 identifying MPLS OAM packets when the OAM packets are encapsulated in 538 an IP header. MPLS-TP must not rely on these mechanisms, and thus 539 relies on the GACH/GAL to demultiplex OAM packets. 541 3.6. Operations, Administration and Maintenance (OAM) 543 MPLS-TP supports a comprehensive set of OAM capabilities for packet 544 transport applications, with equivalent capabilities to those 545 provided in SONET/SDH. 547 MPLS-TP defines mechanisms to differentiate specific packets (e.g. 548 OAM, APS, MCC or SCC) from those carrying user data packets on the 549 same LSP. These mechanisms are described in RFC5586 [RFC5586]. 551 MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of 552 OAM capabilities is available to perform fault management (e.g. fault 553 detection and localization) and performance monitoring (e.g. packet 554 delay and loss measurement) of the LSP, PW or section. The framework 555 for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. 557 OAM and monitoring in MPLS-TP is based on the concept of maintenance 558 entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A 559 Maintenance Entity can be viewed as the association of two (or more) 560 Maintenance End Points (MEPs) (see example in Figure 5 ). The MEPs 561 that form an ME should be configured and managed to limit the OAM 562 responsibilities of an OAM flow within a network or sub- network, or 563 a transport path or segment, in the specific layer network that is 564 being monitored and managed. 566 Each OAM flow is associated with a single ME. Each MEP within an ME 567 resides at the boundaries of that ME. An ME may also include a set 568 of zero or more Maintenance Intermediate Points (MIPs), which reside 569 within the Maintenance Entity. Maintenance end points (MEPs) are 570 capable of sourcing and sinking OAM flows, while maintenance 571 intermediate points (MIPs) can only sink or respond to OAM flows. 573 ========================== End to End LSP OAM ============================ 574 ..... ..... ..... ..... 575 -----|MIP|---------------------|MIP|---------|MIP|------------|MIP|----- 576 ''''' ''''' ''''' ''''' 578 |<-------- Carrier 1 --------->| |<--- Carrier 2 ----->| 579 ---- --- --- ---- ---- --- ---- 580 NNI | | | | | | | | NNI | | | | | | NNI 581 -----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |----- 582 | | | | | | | | | | | | | | 583 ---- --- --- ---- ---- --- ---- 585 ==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM === 586 (Carrier 1) LSP OAM (Carrier 2) 587 (inter-carrier) 588 ..... ..... ..... .......... .......... ..... ..... 589 |MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP| 590 ''''' ''''' ''''' '''''''''' '''''''''' ''''' ''''' 591 <------------ ME ----------><--- ME ----><------- ME --------> 593 Note: MEPs for End-to-end LSP OAM exist outside of the scope of this figure. 595 Figure 5: Example of MPLS-TP OAM 597 Figure 6 illustrates how the concept of Maintenance Entities can be 598 mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS- 599 PWs. 601 Native |<-------------------- PW15 --------------------->| Native 602 Layer | | Layer 603 Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service 604 (AC1) V V LSP V V LSP V V LSP V V (AC2) 605 +----+ +-+ +----+ +----+ +-+ +----+ 606 +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ 607 | | | |=========| |=========| |=========| | | | 608 |CE1|--------|........PW1........|...PW3...|........PW5........|-----|CE2| 609 | | | |=========| |=========| |=========| | | | 610 +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ 611 +----+ +-+ +----+ +----+ +-+ +----+ 613 |<- Subnetwork 123->| |<- Subnetwork XYZ->| 615 .------------------- PW15 PME -------------------. 616 .---- PW1 PTCME ----. .---- PW5 PTCME ---. 617 .---------. .---------. 618 PSN13 LME PSNXZ LME 620 .--. .--. .--------. .--. .--. 621 Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME 623 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 624 TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z 626 .---. ME . MEP ==== LSP .... PW 628 SME: Section Maintenance Entity 629 LME: LSP Maintenance Entity 630 PME: PW Maintenance Entity 632 Figure 6: MPLS-TP OAM archtecture 634 The following MPLS-TP MEs are specified in 635 [I-D.ietf-mpls-tp-oam-framework]: 637 o A Section Maintenance Entity (SME), allowing monitoring and 638 management of MPLS-TP Sections (between MPLS LSRs). 640 o A LSP Maintenance Entity (LME), allowing monitoring and management 641 of an end-to-end LSP (between LERs). 643 o A PW Maintenance Entity (PME), allowing monitoring and management 644 of an end-to-end SS/MS-PWs (between T-PEs). 646 o An LSP Tandem Connection Maintenance Entity (LTCME), allowing 647 monitoring and management of an LSP Tandem Connection (or LSP 648 Segment) between any LER/LSR along the LSP. o A MS-PW Tandem 649 Connection Maintenance Entity (PTCME), allows monitoring and 650 management of a SS/MS-PW Tandem Connection (or PW Segment) between 651 any T-PE/S-PE along the (MS-)PW. Note that the term Tandem 652 Connection Monitoring has historical significance dating back to 653 the early days of the telephone network, but is equally applicable 654 to the two-level hierarchal architectures commonly employed in 655 todays packet networks. 657 Individual MIPs along the path of an LSP or PW are addressed by 658 setting the appropriate TTL in the label for the OAM packet, as per 659 [I-D.ietf-pwe3-segmented-pw]. Note that this works when the location 660 of MIPs along the LSP or PW path is known by the MEP. There may be 661 cases where this is not the case in general MPLS networks e.g. 662 following restoration using a facility bypass LSP. 664 MPLS-TP OAM packets share the same fate as their corresponding data 665 packets, and are identified through the Generic Associated Channel 666 mechanism [RFC5586]. This uses a combination of an Associated 667 Channel Header (ACH) and a Generic Alert Label (GAL) to create a 668 control channel associated to an LSP, Section or PW. 670 The MPLS-TP OAM architecture support a wide range of OAM functions, 671 including the following 673 o Continuity Check 675 o Connectivity Verification 677 o Performance monitoring (e.g. loss and delay) 679 o Alarm suppression 681 o Remote Integrity 683 These are applicable to any layer defined within MPLS- TP, i.e. MPLS 684 Section, LSP and PW. 686 The MPLS-TP OAM toolset needs to be able to operate without relying 687 on a dynamic control plane or IP functionality in the datapath. In 688 the case of MPLS-TP deployment with IP functionality, all existing 689 IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used. 690 This does not preculde the use of other OAM tools in an IP 691 addressable network. 693 One use of OAM mechanisms is to detect link failures, node failures 694 and performance outside the required specification which then may be 695 used to trigger recovery actions, according to the requirements of 696 the service. 698 3.7. Generic Associated Channel (G-ACh) 700 For correct operation of the OAM it is important that the OAM packets 701 fate share with the data packets. In addition in MPSL-TP it is 702 necessary to discriminate between user data payloads and other types 703 of payload. For example the packet may contain a Signaling 704 Communication Channel (SCC), or a channel used for Automatic 705 Protecton Switching (APS) data. Such packetets are carried on a 706 control channel associated to the LSP, Section or PW. This is 707 achieved by carrying such packets on a generic control channel 708 associated to the LSP, PW or section. 710 MPLS-TP makes use of such a generic associated channel (G-ACh) to 711 support Fault, Configuration, Accounting, Performance and Security 712 (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC 713 or other packet types in band over LSPs or PWs. The G-ACH is defined 714 in [RFC5586]and it is similar to the Pseudowire Associated Channel 715 [RFC4385], which is used to carry OAM packets across pseudowires. 716 The G-ACH is indicated by a generic associated channel header (ACH), 717 similar to the Pseudowire VCCV control word, and this is present for 718 all Sections, LSPs and PWs making use of FCAPS functions supported by 719 the G-ACH. 721 For pseudowires, the G-ACh use the first nibble of the pseudowire 722 control word to provide the initial discrimination between data 723 packets a packets belonging to the associated channel, as described 724 in[RFC4385]. When the first nibble of a packet, immediately 725 following the label at the bottom of stack, has a value of one, then 726 this packet belongs to a G-ACh. The first 32 bits following the 727 bottom of stack label then have a defined format called an associated 728 channel header (ACH), which further defines the content of the 729 packet. The ACH is therefore both a demultiplexer for G-ACh traffic 730 on the PW, and a discriminator for the type of G-ACh traffic. 732 When the OAM, or a similar message is carried over an LSP, rather 733 than over a pseudowire, it is necessary to provide an indication in 734 the packet that the payload is something other than a user data 735 packet. This is acheived by including a reserved label with a value 736 of 13 in the label stack. This reserved label is referred to as the 737 'Generic Alert Label (GAL)', and is defined in [RFC5586]. When a GAL 738 is found anywhere within the label stack it indicates that the 739 payload begins with an ACH. The GAL is thus a demultiplexer for 740 G-ACh traffic on the LSP, and the ACH is a discriminator for the type 741 of traffic carried on the G-ACh. Note however that MPLS-TP 742 forwarding follows the normal MPLS model, and that a GAL is invisible 743 to an LSR unless it is the top label iin the label stack. The only 744 other circumstance under which the label stack may be inspected for a 745 GAL is when the TTL has expired. Any MPLS-TP component that 746 intentionally performs this inspection must assume that it is 747 asynchronous with respect to the forwarding of other packets. All 748 operations on the label stack arein accordance with [RFC3031] and 749 [RFC3032]. 751 In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the 752 bottom of the label stack (i.e. S bit set to 1), however this does 753 not preclude its use elsewhere in the label stack in other 754 applications. 756 The G-ACH MUST only be used for channels that are an adjunct to the 757 data service. Examples of these are OAM, APS, MCC and SCC, but the 758 use is not resticted to those names services. The G-ACH MUST NOT be 759 used to carry additional data for use in the forwarding path, i.e. it 760 MUST NOT be used as an alternative to a PW control word, or to define 761 a PW type. 763 Since the G-ACh traffic is indistinguishable from the user data 764 traffic at the server layer, bandwidth and QoS commitments apply to 765 the gross traffic on the LSP, PW or section. Protocols using the 766 G-ACh must therefore take into consideration the impact they have on 767 the user data that they are sharing resources with. In addition, 768 protocols using the G-ACh MUST conform to the security and congestion 769 considerations described in [RFC5586]. . 771 Figure 7 shows the reference model depicting how the control channel 772 is associated with the pseudowire protocol stack. This is based on 773 the reference model for VCCV shown in Figure 2 of [RFC5085]. 775 +-------------+ +-------------+ 776 | Payload | < Service / FCAPS > | Payload | 777 +-------------+ +-------------+ 778 | Demux / | < CW / ACH for PWs > | Demux / | 779 |Discriminator| |Discriminator| 780 +-------------+ +-------------+ 781 | PW | < PW > | PW | 782 +-------------+ +-------------+ 783 | PSN | < LSP > | PSN | 784 +-------------+ +-------------+ 785 | Physical | | Physical | 786 +-----+-------+ +-----+-------+ 787 | | 788 | ____ ___ ____ | 789 | _/ \___/ \ _/ \__ | 790 | / \__/ \_ | 791 | / \ | 792 +--------| MPLS/MPLS-TP Network |---+ 793 \ / 794 \ ___ ___ __ _/ 795 \_/ \____/ \___/ \____/ 797 Figure 7: PWE3 Protocol Stack Reference Model including the G-ACh 799 PW associated channel messages are encapsulated using the PWE3 800 encapsulation, so that they are handled and processed in the same 801 manner (or in some cases, an analogous manner) as the PW PDUs for 802 which they provide a control channel. 804 Figure 8 shows the reference model depicting how the control channel 805 is associated with the LSP protocol stack. 807 +-------------+ +-------------+ 808 | Payload | < Service > | Payload | 809 +-------------+ +-------------+ 810 |Discriminator| < ACH on LSP > |Discriminator| 811 +-------------+ +-------------+ 812 |Demultiplexer| < GAL on LSP > |Demultiplexer| 813 +-------------+ +-------------+ 814 | PSN | < LSP > | PSN | 815 +-------------+ +-------------+ 816 | Physical | | Physical | 817 +-----+-------+ +-----+-------+ 818 | | 819 | ____ ___ ____ | 820 | _/ \___/ \ _/ \__ | 821 | / \__/ \_ | 822 | / \ | 823 +--------| MPLS/MPLS-TP Network |---+ 824 \ / 825 \ ___ ___ __ _/ 826 \_/ \____/ \___/ \____/ 828 Figure 8: MPLS Protocol Stack Reference Model including the LSP 829 Associated Control Channel 831 3.8. Control Plane 833 MPLS-TP should be capable of being operated with centralized Network 834 Management Systems (NMS). The NMS may be supported by a distributed 835 control plane, but MPLS-TP can operated in the absense of such a 836 control plane. A distributed control plane may be used to enable 837 dynamic service provisioning in multi-vendor and multi-domain 838 environments using standardized protocols that guarantee 839 interoperability. Where the requirements specified in 840 [I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport 841 profile uses existing control plane protocols for LSPs and PWs. 843 Figure 9 illustrates the relationshop between the MPLS-TP control 844 plane, the forwarding plane, the management plane, and OAM for point- 845 to-point MPLS-TP LSPs or PWs. 847 +------------------------------------------------------------------------+ 848 | | 849 | Network Management System and/or | 850 | | 851 | Control Plane for Point to Point Connections | 852 | | 853 +------------------------------------------------------------------------+ 854 | | | | | | 855 ............|......|..... ....|.......|.... ....|....|............... 856 +---+ | : : +---+ | : : +---+ | : 857 : |OAM| | : : |OAM| | : : |OAM| | : 858 : +---+ | : : +---+ | : : +---+ | : 859 : | | : : | | : : | | : 860 \: +----+ +----------+ : : +----------+ : : +----------+ +----+ :/ 861 --+-|Edge|<->|Forwarding|<---->|Forwarding|<----->|Forwarding|<->|Edge|-+-- 862 /: +----+ | | : : | | : : | | +----+ :\ 863 : +----------+ : : +----------+ : : +----------+ : 864 ''''''''''''''''''''''''' ''''''''''''''''' '''''''''''''''''''''''' 866 Note: 867 1) NMS may be centralised or distributed. Control plane is distributed 868 2) 'Edge' functions refers to those functions present at the edge of 869 a PSN domain, e.g. NSP or classification. 871 Figure 9: MPLS-TP Control Plane Architecture Context 873 The MPLS-TP control plane is based on a combination of the LDP-based 874 control plane for pseudowires [RFC4447] and the RSVP-TE based control 875 plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that 876 are required for LSP signaling for MPLS-TP are based on GMPLS. 878 The distributed MPLS-TP control plane provides the following 879 functions: 881 o Signaling 883 o Routing 885 o Traffic engineering and constraint-based path computation 887 In a multi-domain environment, the MPLS-TP control plane supports 888 different types of interfaces at domain boundaries or within the 889 domains. These include the User-Network Interface (UNI), Internal 890 Network Node Interface (I-NNI), and External Network Node Interface 891 (E-NNI). Note that different policies may be defined that control 892 the information exchanged across these interface types. 894 The MPLS-TP control plane is capable of activating MPLS-TP OAM 895 functions as described in the OAM section of this document 896 Section 3.6 e.g. for fault detection and localization in the event of 897 a failure in order to efficiently restore failed transport paths. 899 The MPLS-TP control plane supports all MPLS-TP data plane 900 connectivity patterns that are needed for establishing transport 901 paths including protected paths as described in the survivability 902 section Section 3.10 of this document. Examples of the MPLS-TP data 903 plane connectivity patterns are LSPs utilizing the fast reroute 904 backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or 905 1:1 protected LSPs. 907 The MPLS-TP control plane provides functions to ensure its own 908 survivability and to enable it to recover gracefully from failures 909 and degredations. These include graceful restart and hot redundant 910 configurations. Depending on how the control plane is transported, 911 varying degrees of decoupling between the control plane and data 912 plane may be achieved. 914 3.8.1. PW Control Plane 916 An MPLS-TP network provides many of its transport services using 917 single-segment or multi-segment pseudowires, in compliance with the 918 PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). The 919 setup and maintenance of single-segment or multi- segment pseudowires 920 uses the Label Distribution Protocol (LDP) as per [RFC4447] and 921 extensions for MS-PWs [I-D.ietf-pwe3-segmented-pw] and 922 [I-D.ietf-pwe3-dynamic-ms-pw]. 924 3.8.2. LSP Control Plane 926 MPLS-TP provider edge nodes aggregate multiple pseudowires and carry 927 them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP 928 LSPs). Applicable functions from the Generalized MPLS (GMPLS) 929 protocol suite supporting packet-switched capable (PSC) technologies 930 are used as the control plane for MPLS-TP transport paths (LSPs). 932 The LSP control plane includes: 934 o RSVP-TE for signalling 936 o OSPF-TE or ISIS-TE for routing 938 RSVP-TE signaling in support of GMPLS, as defined in [RFC4872], is 939 used for the setup, modification, and release of MPLS-TP transport 940 paths and protection paths. It supports unidirectional, bi- 941 directional and multicast types of LSPs. The route of a transport 942 path is typically calculated in the ingress node of a domain and the 943 RSVP explicit route object (ERO) is utilized for the setup of the 944 transport path exactly following the given route. GMPLS based 945 MPLS-TP LSPs must be able to interoperate with RSVP-TE based MPLS-TE 946 LSPs, as per [RFC5146] 948 OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used 949 for carrying link state information in a MPLS-TP network. ISIS-TE 950 routing in support of GMPLS as defined in [RFC5307] is used for 951 carrying link state information in a MPLS-TP network. 953 3.9. Static Operation of LSPs and PWs 955 A PW or LSP may be statically configured without the support of a 956 dynamic control plane. This may be either by direct configuration of 957 the PEs/LSRs, or via a network management system. The colateral 958 damage that loops can cause during the time taken to detect the 959 failure may be severe. When static configuration mechanisms are 960 used, care must be taken to ensure that loops to not form. 962 3.10. Survivability 964 Survivability requirements for MPLS-TP are specified in 965 [I-D.ietf-mpls-tp-survive-fwk]. 967 A wide variety of resiliency schemes have been developed to meet the 968 various network and service survivability objectives. For example, 969 as part of the MPLS/PW paradigms, MPLS provides methods for local 970 repair using back-up LSP tunnels ([RFC4090]), while pseudowire 971 redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the 972 protection for the PW can not be fully provided by the PSN layer 973 (i.e. where the backup PW terminates on a different target PE node 974 than the working PW). Additionally, GMPLS provides a well known set 975 of control plane driven protection and restoration mechanisms 976 [RFC4872]. MPLS-TP provides additional protection mechansisms that 977 are optimised for both linear topologies and ring topologies, and 978 that operate in the absense of a dynamic control plane. These are 979 specified in [I-D.ietf-mpls-tp-survive-fwk]. 981 Different protection schemes apply to different deployment topologies 982 and operational considerations. Such protection schemes may provide 983 different levels of resiliency. For example, two concurrent traffic 984 paths (1+1), one active and one standby path with guaranteed 985 bandwidth on both paths (1:1) or one active path and a standby path 986 that is shared by one or more other active paths (shared protection). 987 The applicability of any given scheme to meet specific requirements 988 is outside the current scope of this document. 990 The characteristics of MPLS-TP resiliency mechanisms are listed 991 below. 993 o Optimised for linear, ring or meshed topologies. 995 o Use OAM mechanisms to detect and localize network faults or 996 service degenerations. 998 o Include protection mechanisms to coordinate and trigger protection 999 switching actions in the absense of a dynamic control plane. This 1000 is known as an Automatic Protection Switching (APS) mechanism. 1002 o MPLS-TP recovery schemes are applicable to all levels in the 1003 MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment 1004 and end-to- end recovery. 1006 o MPLS-TP recovery mechanisms support the coordination of protection 1007 switching at multiple levels to prevent race conditions occuring 1008 between a client and its server layer. 1010 o MPLS-TP recovery mechanisms can be data plane, control plane or 1011 management plane based. 1013 o MPLS-TP supports revertive and non-revertive behavior. 1015 3.11. Network Management 1017 The network management architecture and requirements for MPLS-TP are 1018 specified in [I-D.ietf-mpls-tp-nm-req]. It derives from the generic 1019 specifications described in ITU-T G.7710/Y.1701 [G.7710] for 1020 transport technologies. It also incorporates the OAM requirements 1021 for MPLS Networks [RFC4377] and MPLS-TP Networks 1022 [I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements 1023 to cover the modifications necessary for fault, configuration, 1024 performance, and security in a transport network. 1026 The Equipment Management Function (EMF) of a MPLS-TP Network Element 1027 (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through 1028 which a management system manages the NE. The Management 1029 Communication Channel (MCC), realized by the G-ACh, provides a 1030 logical operations channel between NEs for transferring Management 1031 information. For the management interface from a management system 1032 to a MPLS-TP NE, there is no restriction on which management protocol 1033 should be used. It is used to provision and manage an end-to-end 1034 connection across a network where some segments are create/managed, 1035 for examples by Netconf or SNMP and other segments by XML or CORBA 1036 interfaces. Maintenance operations are run on a connection (LSP or 1037 PW) in a manner that is independent of the provisioning mechanism. 1039 An MPLS-TP NE is not required to offer more than one standard 1040 management interface. In MPLS-TP, the EMF must be capable of 1041 statically provisioning LSPs for an LSR or LER, and PWs for a PE, as 1042 per Section 3.9. 1044 Fault Management (FM) functions within the EMF of an MPLS-TP NE 1045 enable the supervision, detection, validation, isolation, correction, 1046 and alarm handling of abnormal conditions in the MPLS-TP network and 1047 its environment. FM must provide for the supervision of transmission 1048 (such as continuity, connectivity, etc.), software processing, 1049 hardware, and environment. Alarm handling includes alarm severity 1050 assignment, alarm suppression/aggregation/correlation, alarm 1051 reporting control, and alarm reporting. 1053 Configuration Management (CM) provides functions to control, 1054 identify, collect data from, and provide data to MPLS-TP NEs. In 1055 addition to general configuration for hardware, software protection 1056 switching, alarm reporting control, and date/time setting, the EMF of 1057 the MPLS-TP NE also supports the configuration of maintenance entity 1058 identifiers (such as MEP ID and MIP ID). The EMF also supports the 1059 configuration of OAM parameters as a part of connectivity management 1060 to meet specific operational requirements. These may specify whether 1061 the operational mode is one-time on-demand or is periodic at a 1062 specified frequency. 1064 The Performance Management (PM) functions within the EMF of an MPLS- 1065 TP NE support the evaluation and reporting of the behaviour of the 1066 NEs and the network. One particular requirement for PM is to provide 1067 coherent and consistent interpretation of the network behaviour in a 1068 hybrid network that uses multiple transport technologies. Packet 1069 loss measurement and delay measurements may be collected and used to 1070 detect performance degradation. This is reported via fault 1071 management to enable corrective actions to be taken (e.g. protection 1072 switching), and via performance monitoring for Service Level 1073 Agreement (SLA) verification and billing. Collection mechanisms for 1074 performance data should be should be capable of operating on-demand 1075 or proactively. 1077 4. Security Considerations 1079 The introduction of MPLS-TP into transport networks means that the 1080 security considerations applicable to both MPLS and PWE3 apply to 1081 those transport networks. Furthermore, when general MPLS networks 1082 that utilise functionality outside of the strict MPLS-TP profile are 1083 used to support packet transport services, the security 1084 considerations of that additional functionality also apply. 1086 The security considerations of [RFC3985] and 1088 [I-D.ietf-pwe3-ms-pw-arch] apply. 1090 Each MPLS-TP solution must specify the addtional security 1091 considerations that apply. 1093 5. IANA Considerations 1095 IANA considerations resulting from specific elements of MPLS-TP 1096 functionality will be detailed in the documents specifying that 1097 functionality. 1099 This document introduces no additional IANA considerations in itself. 1101 6. Acknowledgements 1103 The editors wish to thank the following for their contribution to 1104 this document: 1106 o Dieter Beller 1108 o Italo Busi 1110 o Hing-Kam Lam 1112 o Marc Lasserre 1114 o Vincenzo Sestito 1116 o Martin Vigoureux 1118 o Malcolm Betts 1120 7. References 1122 7.1. Normative References 1124 [G.7710] "ITU-T Recommendation G.7710/ 1125 Y.1701 (07/07), "Common 1126 equipment management function 1127 requirements"", 2005. 1129 [I-D.ietf-mpls-cosfield-def] Andersson, L. and R. Asati, 1130 "Multi-Protocol Label Switching 1131 (MPLS) label stack entry: "EXP" 1132 field renamed to "Traffic 1133 Class" field", 1134 draft-ietf-mpls-cosfield-def-08 1135 (work in progress), 1136 December 2008. 1138 [I-D.ietf-pwe3-ms-pw-arch] Bocci, M. and S. Bryant, "An 1139 Architecture for Multi-Segment 1140 Pseudowire Emulation Edge-to- 1141 Edge", 1142 draft-ietf-pwe3-ms-pw-arch-06 1143 (work in progress), 1144 February 2009. 1146 [I-D.ietf-pwe3-redundancy] Muley, P. and M. Bocci, 1147 "Pseudowire (PW) Redundancy", 1148 draft-ietf-pwe3-redundancy-01 1149 (work in progress), 1150 September 2008. 1152 [RFC2119] Bradner, S., "Key words for use 1153 in RFCs to Indicate Requirement 1154 Levels", BCP 14, RFC 2119, 1155 March 1997. 1157 [RFC3031] Rosen, E., Viswanathan, A., and 1158 R. Callon, "Multiprotocol Label 1159 Switching Architecture", 1160 RFC 3031, January 2001. 1162 [RFC3032] Rosen, E., Tappan, D., Fedorkow, 1163 G., Rekhter, Y., Farinacci, D., 1164 Li, T., and A. Conta, "MPLS 1165 Label Stack Encoding", RFC 3032, 1166 January 2001. 1168 [RFC3270] Le Faucheur, F., Wu, L., Davie, 1169 B., Davari, S., Vaananen, P., 1170 Krishnan, R., Cheval, P., and J. 1171 Heinanen, "Multi-Protocol Label 1172 Switching (MPLS) Support of 1173 Differentiated Services", 1174 RFC 3270, May 2002. 1176 [RFC3471] Berger, L., "Generalized Multi- 1177 Protocol Label Switching (GMPLS) 1178 Signaling Functional 1179 Description", RFC 3471, 1180 January 2003. 1182 [RFC3985] Bryant, S. and P. Pate, "Pseudo 1183 Wire Emulation Edge-to-Edge 1184 (PWE3) Architecture", RFC 3985, 1185 March 2005. 1187 [RFC4090] Pan, P., Swallow, G., and A. 1188 Atlas, "Fast Reroute Extensions 1189 to RSVP-TE for LSP Tunnels", 1190 RFC 4090, May 2005. 1192 [RFC4201] Kompella, K., Rekhter, Y., and 1193 L. Berger, "Link Bundling in 1194 MPLS Traffic Engineering (TE)", 1195 RFC 4201, October 2005. 1197 [RFC4203] Kompella, K. and Y. Rekhter, 1198 "OSPF Extensions in Support of 1199 Generalized Multi-Protocol Label 1200 Switching (GMPLS)", RFC 4203, 1201 October 2005. 1203 [RFC4385] Bryant, S., Swallow, G., 1204 Martini, L., and D. McPherson, 1205 "Pseudowire Emulation Edge-to- 1206 Edge (PWE3) Control Word for Use 1207 over an MPLS PSN", RFC 4385, 1208 February 2006. 1210 [RFC4447] Martini, L., Rosen, E., El- 1211 Aawar, N., Smith, T., and G. 1212 Heron, "Pseudowire Setup and 1213 Maintenance Using the Label 1214 Distribution Protocol (LDP)", 1215 RFC 4447, April 2006. 1217 [RFC4872] Lang, J., Rekhter, Y., and D. 1218 Papadimitriou, "RSVP-TE 1219 Extensions in Support of End-to- 1220 End Generalized Multi-Protocol 1221 Label Switching (GMPLS) 1222 Recovery", RFC 4872, May 2007. 1224 [RFC5085] Nadeau, T. and C. Pignataro, 1225 "Pseudowire Virtual Circuit 1226 Connectivity Verification 1227 (VCCV): A Control Channel for 1228 Pseudowires", RFC 5085, 1229 December 2007. 1231 [RFC5307] Kompella, K. and Y. Rekhter, 1232 "IS-IS Extensions in Support of 1233 Generalized Multi-Protocol Label 1234 Switching (GMPLS)", RFC 5307, 1235 October 2008. 1237 [RFC5462] Andersson, L. and R. Asati, 1238 "Multiprotocol Label Switching 1239 (MPLS) Label Stack Entry: "EXP" 1240 Field Renamed to "Traffic Class" 1241 Field", RFC 5462, February 2009. 1243 [RFC5586] Bocci, M., Vigoureux, M., and S. 1244 Bryant, "MPLS Generic Associated 1245 Channel", RFC 5586, June 2009. 1247 7.2. Informative References 1249 [I-D.bryant-filsfils-fat-pw] Bryant, S., Filsfils, C., Drafz, 1250 U., Kompella, V., Regan, J., and 1251 S. Amante, "Flow Aware Transport 1252 of MPLS Pseudowires", 1253 draft-bryant-filsfils-fat-pw-03 1254 (work in progress), March 2009. 1256 [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., 1257 Nadeau, T., and G. Swallow, "BFD 1258 For MPLS LSPs", 1259 draft-ietf-bfd-mpls-07 (work in 1260 progress), June 2008. 1262 [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, "MPLS 1263 TP Network Management 1264 Requirements", 1265 draft-ietf-mpls-tp-nm-req-02 1266 (work in progress), June 2009. 1268 [I-D.ietf-mpls-tp-oam-framework] Busi, I. and B. Niven-Jenkins, 1269 "MPLS-TP OAM Framework and 1270 Overview", draft-ietf-mpls-tp- 1271 oam-framework-00 (work in 1272 progress), March 2009. 1274 [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M. 1275 Betts, "Requirements for OAM in 1276 MPLS Transport Networks", draft- 1277 ietf-mpls-tp-oam-requirements-02 1278 (work in progress), June 2009. 1280 [I-D.ietf-mpls-tp-requirements] Niven-Jenkins, B., Brungard, D., 1281 Betts, M., Sprecher, N., and S. 1282 Ueno, "MPLS-TP Requirements", dr 1283 aft-ietf-mpls-tp-requirements-09 1284 (work in progress), June 2009. 1286 [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N., Farrel, A., and H. 1287 Shah, "Multiprotocol Label 1288 Switching Transport Profile 1289 Survivability Framework", draft- 1290 ietf-mpls-tp-survive-fwk-00 1291 (work in progress), April 2009. 1293 [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Bitar, 1294 N., Shah, H., Aissaoui, M., and 1295 F. Balus, "Dynamic Placement of 1296 Multi Segment Pseudo Wires", 1297 draft-ietf-pwe3-dynamic-ms-pw-09 1298 (work in progress), March 2009. 1300 [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz, 1301 C., Duckett, M., Bocci, M., 1302 Balus, F., and M. Aissaoui, 1303 "Segmented Pseudowire", 1304 draft-ietf-pwe3-segmented-pw-12 1305 (work in progress), June 2009. 1307 [RFC4377] Nadeau, T., Morrow, M., Swallow, 1308 G., Allan, D., and S. 1309 Matsushima, "Operations and 1310 Management (OAM) Requirements 1311 for Multi-Protocol Label 1312 Switched (MPLS) Networks", 1313 RFC 4377, February 2006. 1315 [RFC4379] Kompella, K. and G. Swallow, 1316 "Detecting Multi-Protocol Label 1317 Switched (MPLS) Data Plane 1318 Failures", RFC 4379, 1319 February 2006. 1321 [RFC5146] Kumaki, K., "Interworking 1322 Requirements to Support 1323 Operation of MPLS-TE over GMPLS 1324 Networks", RFC 5146, March 2008. 1326 Authors' Addresses 1328 Matthew Bocci (editor) 1329 Alcatel-Lucent 1330 Voyager Place, Shoppenhangers Road 1331 Maidenhead, Berks SL6 2PJ 1332 United Kingdom 1334 Phone: +44-207-254-5874 1335 EMail: matthew.bocci@alcatel-lucent.com 1337 Stewart Bryant (editor) 1338 Cisco Systems 1339 250 Longwater Ave 1340 Reading RG2 6GB 1341 United Kingdom 1343 Phone: +44-208-824-8828 1344 EMail: stbryant@cisco.com 1346 Lieven Levrau 1347 Alcatel-Lucent 1348 7-9, Avenue Morane Sulnier 1349 Velizy 78141 1350 France 1352 Phone: +33-6-33-86-1916 1353 EMail: lieven.levrau@alcatel-lucent.com