idnits 2.17.1 draft-blb-mpls-tp-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1113. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1124. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1131. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1137. 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 Copyright Line does not match the current year -- 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Address' on line 261 == Unused Reference: '16' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1016, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-05 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-cosfield-def-05 ** Obsolete normative reference: RFC 4447 (ref. '12') (Obsoleted by RFC 8077) == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-08 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-01 == Outdated reference: A later version (-01) exists of draft-jenkins-mpls-mpls-tp-requirements-00 == Outdated reference: A later version (-01) exists of draft-vigoureux-mpls-tp-oam-requirements-00 == Outdated reference: A later version (-03) exists of draft-gray-mpls-tp-nm-req-01 -- Obsolete informational reference (is this intentional?): RFC 4379 (ref. '23') (Obsoleted by RFC 8029) == Outdated reference: A later version (-03) exists of draft-bryant-filsfils-fat-pw-02 == Outdated reference: A later version (-02) exists of draft-busi-mpls-tp-oam-framework-00 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-09 == Outdated reference: A later version (-01) exists of draft-sprecher-mpls-tp-survive-fwk-00 Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 10 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: May 4, 2009 Cisco Systems 6 L. Levrau, Ed. 7 Alcatel-Lucent 8 October 31, 2008 10 A Framework for MPLS in Transport Networks 11 draft-blb-mpls-tp-framework-01 13 Status of This Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 4, 2009. 38 Abstract 40 This document specifies an archiectectural framework for the 41 application of MPLS in transport networks. It describes a profile of 42 MPLS that enables operational models typical in transport networks 43 networks, while providing additional OAM, survivability and other 44 maintenance functions not currently supported by MPLS. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC2119 [1]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Motivation and Background . . . . . . . . . . . . . . . . 3 56 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Summary of Requirements . . . . . . . . . . . . . . . . . . . 5 59 3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 5 60 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.4. Operations, Administration and Maintenance (OAM) . . . . . 9 64 3.4.1. Generic Associated Channel (G-ACH) . . . . . . . . . . 13 65 3.4.2. Generic Alert Label (GAL) . . . . . . . . . . . . . . 15 66 3.5. Control Plane . . . . . . . . . . . . . . . . . . . . . . 16 67 3.5.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 18 68 3.5.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 18 69 3.6. Static Operation of LSPs and PWs . . . . . . . . . . . . . 19 70 3.7. Survivability . . . . . . . . . . . . . . . . . . . . . . 19 71 3.8. Network Management . . . . . . . . . . . . . . . . . . . . 21 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 79 1. Introduction 81 1.1. Motivation and Background 83 Existing transport technologies (e.g. SDH, ATM, OTN) have been 84 designed with specific characteristics: 86 o Strictly connection oriented 88 * Long-lived connections 90 * Manually provisioned connections 92 o High level of protection and availability 94 o Quality of service 96 o Extended OAM capabilities 98 The development of MPLS-TP has been driven by the carriers needing to 99 evolve SONET/SDH networks to support packet based services and 100 networks, and the desire to take advantage of the flexibility and 101 cost benefits of packet switching technology. 103 There are three objectives: 105 1. To enable MPLS to be deployed in a transport network and operated 106 in a similar manner to existing transport technologies. 108 2. To enable MPLS to support packet transport services with a 109 similar degree of predictability to that found in existing 110 transport networks. 112 3. To create a common set of new functions that are applicable to 113 both MPLS networks in general, and those blonging to the MPLS-TP 114 profile. 116 MPLS-TP defines a profile of MPLS targeted at transport applications. 117 This profile specifies the specific MPLS characteristics and 118 extensions required to meet transport requirements. An equipment 119 conforming to MPLS-TP must support this profile. An MPLS-TP 120 conformant equipment MAY support additional MPLS features. A carrier 121 may deploy some of those additional features in the transport layer 122 of their network if they find them to be beneficial. 124 Figure 1 illustrates the range of services that MPLS-TP is intended 125 to address. Networks supporting MPLS-TP are intended to support a 126 range of layer 1,layer 2 and layer 3 services, and are not limited to 127 layer 3 services only. 128 MPLS-TP Solution exists 129 over this spectrum 130 |<-------------------------------->| 132 cl-ps Multi-Service co-cs & co-ps 133 (cl-ps & co-ps) (Label is 134 | | service context) 135 | | | 136 |<------------------------------|--------------------------------->| 137 | | | 138 L3 Only L1, L2, L3 Services L1, L2 Services 139 Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP 141 Figure 1: MPLS-TP Service Spectrum 143 1.2. Scope 145 This document specifies the high-level functionality of MPLS-TP 146 required for adding transport-oriented capabilities to MPLS 148 1.3. Terminology 150 Term Definition 151 ------- ----------------------------------------- 152 LSP Label Switched Path 153 MPLS-TP MPLS Transport profile 154 SDH Synchronous Digital Hierarchy 155 ATM Asynchronous Transfer Mode 156 OTN Optical Transport Network 157 cl-ps Connectionless - Packet Switched 158 co-cs Connection Oriented - Circuit Switched 159 co-ps Connection Oriented - Packet Switched 160 OAM Operations, Adminitration and Maintenance 161 G-ACH Generic Associated Channel Header 162 GAL Generic Alert Label 163 MEP Maintenance End Point 164 MIP Maintenance Intermediate Point 165 APS Automatic Protection Switching 166 SCC Signaling Communication Channel 167 MCC Management Communication Channel 168 EMF Equipment Management Function 169 FM Fault Management 170 CM Configuration Management 171 PM Performance Management 173 2. Summary of Requirements 175 This section summarizes the requirements for the MPLS transport 176 profile. Such requirements are specified in more detail in [20], 177 [21], and [22]. 179 Solutions MUST NOT modify the MPLS forwarding architecture. 181 Solutions MUST be based on existing pseudowire and LSP constructs. 183 New mechanisms and capabilities added to support transport networks 184 must be able to interoperate or interwork with existing MPLS and 185 pseudowire control and forwarding planes. 187 Point to point LSPs MAY be unidirectional or bi-directional. It MUST 188 be possible to construct congruent Bi-directional LSPs. Point to 189 multipoint LSPs are unidirectional. 191 MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR. It is 192 possible to detect that a merged LSP has been created. 194 It MUST be possible to forward packets solely based on switching the 195 MPLS or PW label. It MUST also be possible to establish and maintain 196 LSPs and/or pseudowires both in the absence or presence of a dynamic 197 control plane. When static provisioning is used, there MUST be no 198 dependency on dynamic routing or signaling. 200 OAM, protection and forwarding of data packets MUST be able to 201 operate without IP forwarding support. 203 It MUST be possible to monitor LSPs and pseudowires through the use 204 of OAM in the absence of control plane or routing functions. In this 205 case information gained from the OAM functions is used to initiate 206 path recovery actions at either the PW or LSP layers. 208 3. Transport Profile Overview 210 3.1. Architecture 212 The architecture for a transport profile of MPLS (MPLS-TP) is based 213 on the MPLS-TE [2], pseudowire [3], and multi-segment pseudowire [4] 214 architectures, as illustrated in Figure 2. The primary constructs of 215 the transport profie for MPLS are LSPs, while PWs are the primary 216 client layer. 218 Native |<------------Pseudowire-------------->| Native 219 Service | PSN PSN | Service 220 (AC) | |<--cloud->| |<-cloud-->| | (AC) 221 | V V V V V V | 222 | +----+ +-----+ +----+ | 223 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 224 | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | 225 | CE1| | | | | | | | | |CE2 | 226 | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | 227 +----+ | | |===========| |==========| | | +----+ 228 ^ +----+ ^ +-----+ ^ +----+ ^ 229 | | | | 230 | TE LSP TE LSP | 231 | | 232 | | 233 |<---------------- Emulated Service ----------------->| 235 Figure 2: MPLS-TP Architecture 237 The MPLS-TP forwarding plane is a profile of the MPLS LSP PW, and 238 MS-PW forwarding architecture as detailed in section Section 3.3. 240 MPLS-TP supports a comprehensive set of OAM and protection-switching 241 capabilities for packet transport applications, with equivalent 242 capabilities to existing SONET/SDH OAM and protection, as described 243 in sections Section 3.4 and Section 3.7. MPLS-TP may be operated 244 with centralized Network Management Systems with or without the 245 support of a distributed control plane as described in sections 246 Section 3.5 and Section 3.8. 248 MPLS-TP defines mechanisms to differentiate specific packets (e.g. 249 OAM, APS, MCC or SCC) from those carrying user data packets on the 250 same LSP. These mechanisms are described in sections Section 3.4.2 251 and Section 3.4.1. 253 3.2. Addressing 255 MPLS-TP distinguishes between adressing used to identify nodes in the 256 network, and identifiers used for demultiplexing and forwarding. 257 This distinction is illustrated in Figure 3. 259 NMS Control/Signalling 260 ..... ..... 261 [Address]| | [Address] 262 | | 263 +-----+---------+------+ 264 Address = Node | | | | 265 ID in forwarding plane | V V | 266 | | 267 | MEP or MIP | 268 | dmux | 269 | svcid | 270 | src | 271 +--^-------------------+ 272 | 273 OAM: OAM | 274 dmux= [GAL/GACH]........... 275 or ________________________________________ 276 IP (________________________________________) 277 svc context=ID/FEC PWE=ID1 278 SRC=IP . 279 . 280 IDx 282 Figure 3: Addressing in MPLS-TP 284 Ediror's note: The figure above arose from discussions in the MPLS-TP 285 design team. It will be clarified in a future verson of this draft. 287 IPv4 or IPv6 addresses are used to identify MPLS-TP nodes by default 288 for network management and signaling purposes. 290 In the forwarding plane, identfiers are required for the service 291 context (provided by the FEC), and for OAM. OAM requires both a 292 demultiplexer and an address for the source of the OAM packet. 294 For MPLS in general where IP addressing is used, IPv4 or IPv6 is used 295 by default. However, MPLS-TP must be able to operate in environments 296 where IP is not used in the forwarding plane. Therefore, the default 297 mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the 298 generic associated channel. Forwarding based on IP addresses for 299 user or OAM packets is NOT REQUIRED for MPLS-TP. 301 RFC 4379 [23]and BFD for MPLS LSPs [24] have defined alert mechanisms 302 that enable a MPLS LSR to identify and process MPLS OAM packets when 303 the OAM packets are encapsulated in an IP header. These alert 304 mechanisms are based on TTL expiration and/or use an IP destination 305 address in the range 127/8. These mechanisms are the default 306 mechanisms for MPLS networks in general for identifying MPLS OAM 307 packets when the OAM packets are encapsulated in an IP header. 308 MPLS-TP must not rely on these mechanisms, and thus relies on the 309 GACH/GAL to demultiplex OAM packets. 311 3.3. Forwarding 313 MPLS-TP LSPs use the MPLS label switching operations defined in [2]. 314 These operations are highly optimized for performance and are not 315 modified by the MPLS-TP profile. 317 During forwarding a label is pushed to describe the processing 318 operaton to be performed at the next hop at that level of 319 encapsulation. A swap of this label is an atomic operation in which 320 the contents of the packet after the swapped label are opaque to the 321 forwarder. The only circumstance that disrupts a swap operation is 322 TTL expiry, in which case the packet may be discarded or subjected to 323 further scrutinity within the LSR. Operations on a packet with an 324 expired TTL are asynchronous to the other packets in the LSP. Thus 325 the only way to cause a P (intermediate) LSR to inspect a packet (for 326 example for OAM purposes) is to set the TTL to expiry at that LSR. 328 MPLS-TP PWs support the PW and MS-PW forwarding operations defined in 329 [3] and [4]. 331 The Traffic Class field (former MPLS EXP field) follows the 332 definition and processing rules of [5] and [6]. Only the pipe and 333 short-pipe models are supported in MPLS-TP. 335 The MPLS encapsulation format is as defined in RFC 3032[7]. Per- 336 platform or the per-interface label space can be selected. Standard 337 PW encapsulation mechanisms are applicable to the different client 338 layers as defined by the IETF PWE3 WG. 340 MPLS-TP LSPs can be unidirectional or bidirectional point-to-point. 341 As for MPLS, point-to-multipoint MPLS-TP LSPs are unidirectional. 343 Point-to-multipont PWs are currently in definition in the IETF and 344 may be incorporated in MPLS-TP if required. 346 It MUST be possible to configure an MPLS-TP LSP such that the forward 347 and backward directions of bidirectional MPLS-TP LSPs congruent: i.e. 348 they follow the same path. The pairing relationship between the 349 forward and the backward directions must be known at each MEP, MIP or 350 segment protection endpoint on a bidirectional LSP. 352 Per-packet equal cost multi-path (ECMP) load balancing is not 353 applicable to MPLS-TP LSPs, however PWs or LSPs that emulate link 354 bundles may be employed, for example [25] 355 Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default. 356 The applicability of PHP to both MPLS-TP LSPs and MPLS networks in 357 general providing paket transport services will be clarified in a 358 future version of this draft. 360 Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270 361 [6]. 363 3.4. Operations, Administration and Maintenance (OAM) 365 MPLS-TP requires [21] that a set of OAM capabilities is available to 366 perform fault management (e.g. fault detection and localization) and 367 performance monitoring (e.g. signal quality measurement) of the 368 MPLS-TP network and the services. These capabilities are applicable 369 at the section, LSP and PW layer. The framework for OAM in MPLS-TP 370 is specified in [26]. 372 OAM and monitoring in MPLS-TP is based on the concept of maintenance 373 entities, as described in [26]. A Maintenance Entity can be viewed 374 as the association of two (or more) Maintenance End Points (MEPs) 375 (see example in Figure 4 ). The MEPS that form an ME should be 376 configured and managed to limit the OAM responsibilities of an OAM 377 flow within a network or sub-network in the specific layer network 378 that is being monitored and managed. Each OAM flow is associated to 379 a unique ME. Each MEP within an ME resides at the boundaries of that 380 ME. An ME may also include a set of zero or more Maintenance 381 Intermediate Points (MIPs), which reside within the Maintenance 382 Entity. Maintenance end points (MEPs) are capable of sourcing and 383 sinking OAM flows, while maintenance intermediate points (MIPs) can 384 only sink or respond to OAM flows. 386 ========================== End to End LSP OAM ============================ 387 ..... ..... ..... ..... 388 -----|MIP|---------------------|MIP|---------|MIP|------------|MIP|----- 389 ''''' ''''' ''''' ''''' 391 |<-------- Carrier 1 --------->| |<----- Carrier 2 ----->| 392 ---- --- --- ---- ---- --- ---- 393 NNI | | | | | | | | NNI | | | | | | NNI 394 -----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |----- 395 | | | | | | | | | | | | | | 396 ---- --- --- ---- ---- --- ---- 398 ==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM === 399 (Carrier 1) LSP OAM (Carrier 2) 400 (inter-carrier) 401 ..... ..... ..... .......... .......... ..... ..... 402 |MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP| 403 ''''' ''''' ''''' '''''''''' '''''''''' ''''' ''''' 405 Note: MEPs for End-to-end LSP OAM exist outside of the scope of this figure. 407 Figure 4: Example of MPLS-TP OAM 409 Editor's note: The above diagram will be clarified in the next 410 version of this draft. 412 The OAM architecture for MPLS-TP is illustrated in Figure 5. 414 Native |<-------------------- PW15 --------------------->| Native 415 Layer | | Layer 416 Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service 417 (AC1) V V LSP V V LSP V V LSP V V (AC2) 418 +----+ +-+ +----+ +----+ +-+ +----+ 419 +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ 420 | | | |=========| |=========| |=========| | | | 421 |CE1|--------|........PW1........|...PW3...|........PW5........|-----|CE2| 422 | | | |=========| |=========| |=========| | | | 423 +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ 424 +----+ +-+ +----+ +----+ +-+ +----+ 426 |<- Subnetwork 123->| |<- Subnetwork XYZ->| 428 .------------------- PW15 PME -------------------. 429 .----- PW1 TPME ----. .---- PW5 TPME -----. 430 .---------. .---------. 431 PSN13 LME PSNXZ LME 433 .--. .--. .--------. .--. .--. 434 Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME 436 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 437 TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z 439 .---. ME . MEP ==== LSP .... PW 441 SME: Section Maintenance Entity 442 LME: LSP Maintenance Entity 443 PME: PW Maintenance Entity 445 Figure 5: MPLS-TP OAM archtecture 447 The following MPLS-TP MEs are specified in [26]: 449 o A Section Maintenance Entity (SME), allowing monitoring and 450 management of MPLS-TP Sections (between MPLS LSRs). 452 o A LSP Maintenance Entity (LME), allowing monitoring and management 453 of an end-to-end LSP (between LERs). 455 o A PW Maintenance Entity (PME), allowing monitoring and management 456 of an end-to-end SS/MS-PWs (between T-PEs). 458 o An LSP Tandem Connection Maintenance Entity (TLME), allowing 459 monitoring and management of an LSP Tandem Connection (or LSP 460 Segment) between any LER/LSR along the LSP. o A MS-PW Tandem 461 Connection Maintenance Entity (TPME), allows monitoring and 462 management of a SS/MS-PW Tandem Connection (or PW Segment) between 463 any T-PE/S-PE along the (MS-)PW. 465 Individual MIPs along the path of an LSP or PW are addressed by 466 setting the appropriate TTL in the label for the OAM packet, as per 467 [27]. Note that this works when the location of MIPs along the LSP 468 or PW path is known by the MEP. There may be cases where this is not 469 the case in general MPLS networks e.g. following restoration using a 470 facility bypass LSP. 472 The following is a high level summary of the classes of OAM functions 473 that MPLS-TP supports. These are intended to be applicable to any 474 layer defined within MPLS- TP, i.e. MPLS Section, LSP and PW: 476 o Continuity Check 478 o Connectivity verification 480 o Performance monitoring 482 o Alarm suppression 484 o Remote Integrity 486 For all of the above listed functions except alarm suppression, both 487 "continuous" and "on-demand" operation SHOULD be supported. 489 Performance monitoring includes means for both "packet loss 490 measurement" and "delay measurement". 492 It is REQUIRED that MPLS-TP OAM packets share the same fate as their 493 corresponding data packets and that a means exists to identify OAM 494 packets. The document[8] proposes specific mechanisms relying on the 495 combination of the 'Generic Alert Label (GAL)' and Generic Associated 496 Channel Header for MPLS Sections and LSPs and using the Generic 497 Associated Channel Header only for MPLS PWs. This is described in 498 more detail elsewhere in this document Section 3.4.1 and 499 Section 3.4.2. 501 The MPLS-TP OAM toolset needs to be able to operate without relying 502 on a dynamic control plane or IP functionality in the datapath. In 503 the case of MPLS-TP deployment with IP functionality, all existing 504 IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used. 505 This does not preculde the use of other OAM tools in an IP 506 addressable network. 508 One use of OAM mechanisms is to detect link failures, node failures 509 and performance outside the required specification which then may be 510 used to trigger recovery actions, according to the requirements of 511 the service. 513 3.4.1. Generic Associated Channel (G-ACH) 515 MPLS-TP makes use of a generic associated channel (G-ACH) to support 516 Fault, Configuration, Accounting, Performance and Security (FCAPS) 517 functions by carrying packets related to OAM, APS, SCC, MCC or other 518 packet types in band over LSPs or PWs. The G-ACH is defined in 519 [8]and it is similar to the PWE3 Associated Channel, which is used to 520 carry OAM packets across pseudowires. The G-ACH is indicated by a 521 generic associated channel header, similar to the PWE3 VCCV control 522 word, and this is present for all LSPs and PWs making use of FCAPS 523 functions supported by the G-ACH. 525 The G-ACH MUST only be used for channels that are an adjunct to the 526 data service. Examples of these are OAM, APS, MCC and SCC, but the 527 use is not resticted to those names services. The G-ACH MUST NOT be 528 used to carry additional data for use in the forwarding path, i.e. it 529 MUST NOT be used as an alternative to a PW control word, or to define 530 a PW type. 532 The messages transfered over the G-ACH MUST conform to the security 533 and congestion considerations described in [8]. They must also take 534 into consideration the throughput, latency and congestion 535 requirements of the main data channel. 537 Figure 1 shows the reference model depicting how the control channel 538 is associated with the pseudowire protocol stack, as per [9]. 540 +-------------+ +-------------+ 541 | Layer2 | | Layer2 | 542 | Emulated | < Emulated Service > | Emulated | 543 | Services | | Services | 544 +-------------+ +-------------+ 545 | | VCCV/PW | | 546 |Demultiplexer| < Associated Channel > |Demultiplexer| 547 +-------------+ +-------------+ 548 | PSN | < PSN Tunnel > | PSN | 549 +-------------+ +-------------+ 550 | Physical | | Physical | 551 +-----+-------+ +-----+-------+ 552 | | 553 | ____ ___ ____ | 554 | _/ \___/ \ _/ \__ | 555 | / \__/ \_ | 556 | / \ | 557 +--------| MPLS/MPLS-TP Network |---+ 558 \ / 559 \ ___ ___ __ _/ 560 \_/ \____/ \___/ \____/ 562 Figure 6: PWE3 Protocol Stack Reference Model including the PW 563 Associated Control Channel 565 PW associated channel messages are encapsulated using the PWE3 566 encapsulation, so that they are handled and processed in the same 567 manner (or in some cases, an analogous manner) as the PW PDUs for 568 which they provide a control channel. 570 Figure 2 shows the reference model depicting how the control channel 571 is associated with the LSP protocol stack. 573 +-------------+ +-------------+ 574 | | | | 575 | Payload | < Service > | Payload | 576 | Services | | | 577 +-------------+ +-------------+ 578 | | LSP | | 579 |Demultiplexer| < Associated Channel > |Demultiplexer| 580 +-------------+ +-------------+ 581 | GAL | | GAL | 582 +-------------+ +-------------+ 583 | PSN | < LSP > | PSN | 584 +-------------+ +-------------+ 585 | Physical | | Physical | 586 +-----+-------+ +-----+-------+ 587 | | 588 | ____ ___ ____ | 589 | _/ \___/ \ _/ \__ | 590 | / \__/ \_ | 591 | / \ | 592 +--------| MPLS/MPLS-TP Network |---+ 593 \ / 594 \ ___ ___ __ _/ 595 \_/ \____/ \___/ \____/ 597 Figure 7: MPLS Protocol Stack Reference Model including the LSP 598 Associated Control Channel 600 LSP associated channel messages are encapsulated using a generic 601 associated control channel header (G-ACH). The presence of the GE- 602 ACH is indicated by the inclusion of an additional 'Generic Alert 603 Label (GAL)'. This arrangement means that both normal data packets 604 and packets carrying an ACH are carried over LSPs in a similar 605 manner. 607 Note that where a traffic engineered LSP is used the paths will be 608 identical. If for any reason a non-traffic engineered path (for 609 example an LDP path) were to be used the ECMP behaviour may be 610 modified by the presence of the GAL. 612 3.4.2. Generic Alert Label (GAL) 614 For correct operation of the OAM it is important that the OAM packets 615 fate share with the data packets. In addition in MPSL-TP it is 616 necessary to indicate that the payload carried over an LSP is not 617 user data. For example the packet may contain Signaling 618 Communication Channel (SCC), or Automatic Protecton Switching (APS) 619 data. The presence of the ACH indicates that the packet is not user 620 data and identifies its type. 622 PWE3 uses the first nibble of the control word to provide the initial 623 discrimination between data packets and "other" packets [10]. When 624 the first nibble of a pseudwire packet has a value of one, then the 625 first 32 bits that follow the bottom of stack have a defined format 626 called an ACH, and which further defines the content of the 627 pseudowire packet. For MPLS-TP this mechanism is further generalized 628 to apply to also apply to LSPs and MPLS sections [8]. 630 When the OAM, or a similar message is carried over an LSP, rather 631 than over a pseudowire, it is necessary to provide an indication in 632 the packet that the payload is something other than a regular data 633 packet. This is acheived by including ia new reserved label in the 634 label stack. This reserved label is referred to as the 'Generic 635 Alert Label (GAL)', and is defined in [8]. When a GAL is found 636 anywhere within the label stack it indicates that the payload begins 637 with an ACH. Note however that MPLS-TP forwarding follows the normal 638 MPLS model, and that a GAL is invisible to an LSR unless it is the 639 label being popped. The only circumstance under which the label 640 stack may be inspected for a GAL is when the TTL has expired. Any 641 MPLS-TP component which intentionally triggers this inspection must 642 assume that the inspection to be asynchronous with respect to the 643 forwarding of other packets. 645 In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the 646 bottom of the label stack (i.e. S bit set to 1), however this does 647 not preclude its use elsewhere in the label stack in other 648 applications. 650 3.5. Control Plane 652 The MPLS-TP may utilize a distributed control plane to enable fast, 653 dynamic and reliable service provisioning in multi-vendor and multi- 654 domain environments using standardized protocols that guarantee 655 interoperability. 657 Figure 8 illustrates the relationshop between the MPLS-TP control 658 plane, the forwarding plane, the management plane, and OAM. 660 +------------------------------------------------------------------------+ 661 | | 662 | Network Management System and/or | 663 | | 664 | Control Plane for Point to Point Connections | 665 | | 666 +------------------------------------------------------------------------+ 667 | | | | | | 668 ............|......|..... ....|.......|.... ....|....|............... 669 +---+ | : : +---+ | : : +---+ | : 670 : |OAM| | : : |OAM| | : : |OAM| | : 671 : +---+ | : : +---+ | : : +---+ | : 672 : | | : : | | : : | | : 673 \: +----+ +----------+ : : +----------+ : : +----------+ +----+ :/ 674 --+-|Edge|<->|Forwarding|<---->|Forwarding|<----->|Forwarding|<->|Edge|-+-- 675 /: +----+ | | : : | | : : | | +----+ :\ 676 : +----------+ : : +----------+ : : +----------+ : 677 ''''''''''''''''''''''''' ''''''''''''''''' '''''''''''''''''''''''' 679 Note: 680 1) NMS may be centralised or distributed. Control plane is distributed 681 2) 'Edge' functions refers to those functions present at the edge of 682 a PSN domain, e.g. NSP or classification. 683 3) OAM functions are described in more detail below. 685 Figure 8: MPLS-TP Control Plane Architecture Context 687 The MPLS-TP control plane is based on a combination of the MPLS 688 control plane for pseudowires and the GMPLS control plane for MPLS-TP 689 LSPs, respectively. More specifically, LDP is used for PW signaling 690 and GMPLS based RSVP-TE for LSP signaling. The distributed MPLS-TP 691 control plane provides the following basic functions: 693 o Signaling 695 o Routing 697 o Traffic engineering and constraint-based path computation 699 In a multi-domain environment, the MPLS-TP control plane may provide 700 different types of interfaces at domain boundaries or within the 701 domains such as UNI, I-NNI, and E-NNI where different policies are in 702 place that control what kind of information is exchanged across these 703 different types of interfaces. 705 Editor's note: Isn't the following a managment plane operation. I 706 can't think of a routing protocol triggering an OAM message. Or do 707 we mean that the control plane is capable of reacting to OAM events? 708 Control plane and OAM are independent. 710 The MPLS-TP control plane is capable of activating MPLS-TP OAM 711 functions as described in the OAM section of this document 712 Section 3.4 e.g. for fault detection and localization in the event of 713 a failure in order to efficiently restore failed transport paths. 715 The MPLS-TP control plane supports all MPLS-TP data plane 716 connectivity patterns that are needed for establishing transport 717 paths including protected paths as described in the survivability 718 section Section 3.7 of this document. Examples of the MPLS-TP data 719 plane connectivity patterns are LSPs utilizing the fast reroute 720 backup methods as defined in [11] and ingress-to-egress 1+1 or 1:1 721 protected LSPs. 723 Moreover, the MPLS-TP control plane needs to be capable of performing 724 fast restoration in the event of network failures. 726 The MPLS-TP control plane provides features to ensure its own 727 survivavbility and to enable it to recover gracefully from failures 728 and degredations. These include graceful restart and hot redundant 729 configurations. The MPLS-TP control plane is largely decoupled from 730 the MPLS-TP data plane such that failures in the control plane do not 731 impact the data plane and vice versa. 733 3.5.1. PW Control Plane 735 An MPLS-TP packet transport network provides many of its transport 736 services in the form of single-segment or multi-segment pseudowires 737 following the PWE3 architecture as defined in [3] and [4] . The 738 setup and maintenance of single-segment or multi- segment pseudowires 739 is based on the Label Distribution Protocol (LDP) as per [12] and the 740 use of LDP in this manner is applicable to PWs used to provide MPLS 741 transport services. 743 It shall be noted that multi-segment pseudowire signaling is still 744 work in progress. The control plane supporting multi-segment 745 pseudowires is based on [13]. 747 3.5.2. LSP Control Plane 749 Editors note: The following must be reviewed by a CP specialist. Lou 750 will review and provide comments. 752 MPLS-TP provider edge nodes aggregate multiple pseudowires and carry 753 them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP 754 LSPs). The generalized MPLS (GMPLS) protocol suite already supports 755 packet-switched capable (PSC) technologies and is therefore used as 756 control plane for MPLS-TP transport paths (LSPs). The LSP control 757 plane includes: 759 o RSVP-TE for signalling 761 o OSPF-TE for routing 763 o ISIS-TE for routing 765 RSVP-TE signaling in support of GMPLS as defined in [14]is used for 766 the setup, modification, and release of MPLS-TP transport paths and 767 protection paths. It supports unidirectional, bi-directional and 768 multicast types of LSPs. The route of a transport path is typically 769 calculated in the ingress node of a domain and the RSVP explicit 770 route object (ERO) is utilized for the setup of the transport path 771 exactly following the given route. GMPLS based MPLS-TP LSPs must be 772 able to interoperate with RSVP-TE based MPLS-TE LSPs, as per [28] 774 OSPF-TE routing in support of GMPLS as defined in [15] is used for 775 carrying link state information in a MPLS-TP network. 777 For routing scalability reasons, parallel physical links in an MPLS- 778 TP network are typically bundled into TE-links as defined in [16]and 779 the OSPF-TE routing protocol disseminates link state information on a 780 TE-link basis. 782 3.6. Static Operation of LSPs and PWs 784 Where a control plane is not used to set up and manage PWs or LSPs, 785 the following considerations apply. Static configuration of the PW 786 or LSP, either by direct configuration of the PEs/LSRs, or via a 787 network management station must take care that loops to not form on 788 an active LSP. The OAM would normally detect a break in end to end 789 connectivity as a consequence of a loop, and withdraw the LSP from 790 use. However the colateral damage that a loop can during the time 791 taken to detect the failure is severe. Therefore an LSP should not 792 be brought into operation until it certain that loops do not exist. 794 3.7. Survivability 796 Survivability requirements for MPLS-TP are apecified in [29]. 798 A wide variety of resiliency schemes have been developed to meet the 799 various network and service survivability objectives. For example, 800 as part of the MPLS/PW paradigms, MPLS provides methods for local 801 repair using back-up LSP tunnels ([11]), while pseudowire redundancy 802 [17]supports scenarios where the protection for the PW can not be 803 fully provided by the PSN layer (i.e. where the backup PW terminates 804 on a different target PE node than the working PW). Additionally, 805 GMPLS provides a set of control plane driven well known protection 806 and restoration mechanisms [14]. Finally, as part of the transport 807 networks and applications paradigms, APS-based linear and ring 808 protection mechanisms are defined in [18]and [30]. 810 These schemes have different scopes. They are protecting against 811 link and/or node failures and can be applied end-to-end or on a 812 segment of the considered connection. 814 These protection schemes propose different levels of resiliency (e.g. 815 1+1, 1:1, shared). 817 The applicability of any given scheme to meet specific requirements 818 is outside the current scope of this document. 820 MPLS-TP resiliency mechanisms characteristics are listed below 822 o Linear, ring and meshed protection schemes are supported. 824 o As with all network layer protection schemes, MPLS-TP recovery 825 mechanisms (protection and restoration), rely on OAM mechanisms to 826 detect and localize network faults or service degenerations. 828 o APS-based protection mechanisms (linear and ring) rely on MPLS-TP 829 APS mechanisms to coordinate and trigger protection switching 830 actions. 832 o MPLS-TP recovery schemes are designed to be applicable at various 833 levels (MPLS section, LSP and PW), providing segment and end-to- 834 end recovery. 836 o MPLS-TP recovery mechanisms support means for avoiding race 837 conditions in switching activity triggered by a fault condition 838 detected both at server layer and at MPLS-TP layer. 840 o MPLS-TP recovery mechanisms can be data plane, control plane or 841 management plane based. 843 o MPLS-TP allows for revertive and non-revertive behavior 845 o Multiple resiliency mechanisms can be applied to any connection 847 3.8. Network Management 849 The network management architecture and requirements for MPLS-TP are 850 specified in [22]. It derives from the generic specifications 851 described in ITU-T G.7710/Y.1701 [19]for transport technologies. It 852 also leverages on the OAM requirements for MPLS Networks [31] and 853 MPLS-TP Networks [21]and expands on the requirements to cover the 854 modifications necessary for fault, configuration, performance, and 855 security. 857 The Equipment Management Function (EMF) of a MPLS-TP NE provides the 858 means through which a management system manages the NE. The 859 Management Communication Channel (MCC), realized by the G-ACH, 860 provides a logical operations channel between NEs for transferring 861 Management information. For the management interface from a 862 management system to a MPLS-TP NE, there is no restriction on which 863 management protocol should be used. It is allowed to provision and 864 manage an end-to-end connection across a network where some segments 865 are create/managed, for examples by Netconf or SNMP and other 866 segments by XML or CORBA interfaces. It is allowed to run 867 maintenance operations on a connection which is independent of the 868 provisioning mechanism. An MPLS-TP NE is not required to offer more 869 than one standard management interface. In MPLS-TP. the EMF MUST be 870 capable of statically provisioning LSPs for an LSR or LER, and PWs 871 for a PE, as per Section 3.6. 873 The Fault Management (FM) functions within the EMF of an MPLS-TP NE 874 enable the supervision, detection, validation, isolation, correction, 875 and alarm handling of abnormal operation of the MPLS-TP network and 876 its environment. Supervision for transmission (such as continuity, 877 connectivity, etc.), software processing, hardware, and environment 878 are essential for FM. Alarm handling includes alarm severity 879 assignment, alarm suppression/aggregation/correlation, alarm 880 reporting control, and alarm reporting. 882 Configuration Management (CM) provides functions to exercise control 883 over, identify, collect data from, and provide data to MPLS-TP NEs. 884 In addition to general configuration for hardware, software 885 protection switching, alarm reporting control, and date/time setting, 886 the EMF of the MPLS-TP NE also supports the configuration of 887 maintenance entity identifiers (such as MEP ID and MIP ID). The EMF 888 also supports configuration of the OAM parameters as part of 889 connectivity management to meet specific operational requirements, 890 such as whether one-time on-demand or periodically based on a 891 specified frequency. 893 The Performance Management (PM) functions within the EMF of an MPLS- 894 TP NE supports the evaluation and reporting upon the behaviour of the 895 equipment, NE, and network with the objective of providing coherent 896 and consistent interpretation of the network behaviour, in particular 897 for hybrid network which consists of multiple transport technologies. 898 Packet loss measurement and delay measurement are collected so that 899 they can be used to detect performance degradation. Performance 900 degradation is reported via fault management for corrective actions 901 (e.g. protection switch) and via performance monitoring for Service 902 Level Agreement (SLA) verification and billing. The performance data 903 collection mechanisms should be flexible to be configured to operate 904 on-demand or proactively. 906 4. Security Considerations 908 The introduction of MPLS-TP into transport networks means that the 909 security considerations applicable to both MPLS and PWE3 apply to 910 those transport networks. Furthermore, when general MPLS networks 911 that utilise functionality outside of the strict MPLS-TP profile are 912 used to support packet transport services, the security 913 considerations of that additional functionality also apply. 915 Specific security considerations for MPLS-TP will be detailed in 916 documents covering specific aspects on the MPLS-TP architecture. 918 5. IANA Considerations 920 IANA considerations resulting from specific elements of MPLS-TP 921 functionality will be detailed in the documents specifying that 922 functionality. 924 This document introduces no additional IANA considerations in itself. 926 6. Acknowledgements 928 The editors wish to thank the following for their contribution to 929 this document: 931 o Dieter Beller 933 o Italo Busi 935 o Hing-Kam Lam 937 o Marc Lasserre 939 o Vincenzo Sestito 941 o Martin Vigoureux 943 7. References 945 7.1. Normative References 947 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 948 Levels", BCP 14, RFC 2119, March 1997. 950 [2] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label 951 Switching Architecture", RFC 3031, January 2001. 953 [3] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge 954 (PWE3) Architecture", RFC 3985, March 2005. 956 [4] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment 957 Pseudowire Emulation Edge-to-Edge", 958 draft-ietf-pwe3-ms-pw-arch-05 (work in progress), 959 September 2008. 961 [5] Andersson, L. and R. Asati, ""EXP field" renamed to "Traffic 962 Class field"", draft-ietf-mpls-cosfield-def-05 (work in 963 progress), October 2008. 965 [6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., 966 Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol 967 Label Switching (MPLS) Support of Differentiated Services", 968 RFC 3270, May 2002. 970 [7] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, 971 D., Li, T., and A. Conta, "MPLS Label Stack Encoding", 972 RFC 3032, January 2001. 974 [8] Vigoureux, M., Bocci, M., Ward, D., Swallow, G., and R. 975 Aggarwal, "MPLS Generic Associated Channel", 976 draft-bocci-mpls-tp-gach-gal-00 (work in progress), 977 October 2008. 979 [9] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 980 Connectivity Verification (VCCV): A Control Channel for 981 Pseudowires", RFC 5085, December 2007. 983 [10] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 984 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use 985 over an MPLS PSN", RFC 4385, February 2006. 987 [11] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to 988 RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 990 [12] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, 991 "Pseudowire Setup and Maintenance Using the Label Distribution 992 Protocol (LDP)", RFC 4447, April 2006. 994 [13] Martini, L., Bocci, M., Bitar, N., Shah, H., Aissaoui, M., and 995 F. Balus, "Dynamic Placement of Multi Segment Pseudo Wires", 996 draft-ietf-pwe3-dynamic-ms-pw-08 (work in progress), July 2008. 998 [14] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 999 Extensions in Support of End-to-End Generalized Multi-Protocol 1000 Label Switching (GMPLS) Recovery", RFC 4872, May 2007. 1002 [15] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of 1003 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, 1004 October 2005. 1006 [16] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in 1007 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 1009 [17] Muley, P. and M. Bocci, "Pseudowire (PW) Redundancy", 1010 draft-ietf-pwe3-redundancy-01 (work in progress), 1011 September 2008. 1013 [18] "ITU-T Recommendation G.8131/Y.1382 (02/07) " Linear protection 1014 switching for Transport MPLS (T-MPLS) networks"", 2005. 1016 [19] "ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment 1017 management function requirements"", 2005. 1019 7.2. Informative References 1021 [20] Niven-Jenkins, B., Brungard, D., Betts, M., and N. Sprecher, 1022 "MPLS-TP Requirements", 1023 draft-jenkins-mpls-mpls-tp-requirements-00 (work in progress), 1024 July 2008. 1026 [21] Vigoureux, M., Ward, D., Betts, M., Bocci, M., and I. Busi, 1027 "Requirements for OAM in MPLS Transport Networks", 1028 draft-vigoureux-mpls-tp-oam-requirements-00 (work in progress), 1029 July 2008. 1031 [22] Mansfield, S., Lam, K., and E. Gray, "MPLS TP Network 1032 Management Requirements", draft-gray-mpls-tp-nm-req-01 (work in 1033 progress), October 2008. 1035 [23] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label 1036 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 1038 [24] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD 1039 For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), 1040 June 2008. 1042 [25] Bryant, S., Filsfils, C., and U. Drafz, "Load Balancing Fat 1043 MPLS Pseudowires", draft-bryant-filsfils-fat-pw-02 (work in 1044 progress), July 2008. 1046 [26] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and 1047 Overview", draft-busi-mpls-tp-oam-framework-00 (work in 1048 progress), October 2008. 1050 [27] Nadeau, T., Metz, C., Duckett, M., Bocci, M., Balus, F., and L. 1051 Martini, "Segmented Pseudo Wire", 1052 draft-ietf-pwe3-segmented-pw-09 (work in progress), July 2008. 1054 [28] Kumaki, K., "Interworking Requirements to Support Operation of 1055 MPLS-TE over GMPLS Networks", RFC 5146, March 2008. 1057 [29] Sprecher, N., Farrel, A., and V. Kompella, "Multiprotocol Label 1058 Switching Transport Profile Survivability Framework", 1059 draft-sprecher-mpls-tp-survive-fwk-00 (work in progress), 1060 July 2008. 1062 [30] "Draft ITU-T Recommendation G.8132/Y.1382, "T-MPLS shared 1063 protection ring", 1064 http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0501/en", 2005. 1066 [31] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 1067 Matsushima, "Operations and Management (OAM) Requirements for 1068 Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, 1069 February 2006. 1071 Authors' Addresses 1073 Matthew Bocci (editor) 1074 Alcatel-Lucent 1075 Voyager Place, Shoppenhangers Road 1076 Maidenhead, Berks SL6 2PJ 1077 United Kingdom 1079 Phone: +44-207-254-5874 1080 EMail: matthew.bocci@alcatel-lucent.com 1081 Stewart Bryant (editor) 1082 Cisco Systems 1083 250 Longwater Ave 1084 Reading RG2 6GB 1085 United Kingdom 1087 Phone: +44-208-824-8828 1088 EMail: stbryant@cisco.com 1090 Lieven Levrau (editor) 1091 Alcatel-Lucent 1092 7-9, Avenue Morane Sulnier 1093 Velizy 78141 1094 France 1096 Phone: +33-6-33-86-1916 1097 EMail: lieven.levrau@alcatel-lucent.com 1099 Full Copyright Statement 1101 Copyright (C) The IETF Trust (2008). 1103 This document is subject to the rights, licenses and restrictions 1104 contained in BCP 78, and except as set forth therein, the authors 1105 retain all their rights. 1107 This document and the information contained herein are provided on an 1108 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1109 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1110 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1111 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1112 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1113 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1115 Intellectual Property 1117 The IETF takes no position regarding the validity or scope of any 1118 Intellectual Property Rights or other rights that might be claimed to 1119 pertain to the implementation or use of the technology described in 1120 this document or the extent to which any license under such rights 1121 might or might not be available; nor does it represent that it has 1122 made any independent effort to identify any such rights. Information 1123 on the procedures with respect to rights in RFC documents can be 1124 found in BCP 78 and BCP 79. 1126 Copies of IPR disclosures made to the IETF Secretariat and any 1127 assurances of licenses to be made available, or the result of an 1128 attempt made to obtain a general license or permission for the use of 1129 such proprietary rights by implementers or users of this 1130 specification can be obtained from the IETF on-line IPR repository at 1131 http://www.ietf.org/ipr. 1133 The IETF invites any interested party to bring to its attention any 1134 copyrights, patents or patent applications, or other proprietary 1135 rights that may cover technology that may be required to implement 1136 this standard. Please address the information to the IETF at 1137 ietf-ipr@ietf.org.