idnits 2.17.1 draft-blb-mpls-tp-framework-00.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 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 716. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 7, 2008) is 5771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (ref. '9') (Obsoleted by RFC 8077) == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-06 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-04 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-cosfield-def-03 == 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-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Matthew Bocci 2 Internet Draft Marc Lasserre 3 Intended status: Informational Alcatel-Lucent 4 Expires: January 2009 5 Stewart Bryant 6 Cisco Systems, Inc. 8 July 7, 2008 10 A Framework for MPLS in Transport Networks 11 draft-blb-mpls-tp-framework-00 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 other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 7, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 There is a requirement to use MPLS to provide a network layer to 44 support packet transport services. It is desirable that the operation 45 and maintenance of such an MPLS based packet transport network follow 46 operational models typical in optical transport networks, while 47 providing additional OAM, survivability and other maintenance 48 functions not currently supported by MPLS. This draft presents a 49 framework for an architectural and functional profile of MPLS in 50 order to support packet transport services. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [1]. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1. Motivation................................................3 62 1.2. Scope.....................................................3 63 1.3. Terminology...............................................3 64 2. Summary of Requirements........................................3 65 3. Transport Profile Overview.....................................4 66 3.1. Architecture..............................................4 67 3.2. Generic-ACH Label (GAL)...................................4 68 3.3. Generic Associated Channel Header(GE-ACH).................5 69 3.4. Forwarding................................................7 70 3.5. Operations and Management (OAM)...........................8 71 3.6. Control Plane.............................................9 72 3.6.1. PW Control Plane....................................10 73 3.6.2. LSP Control Plane...................................10 74 3.7. Survivability............................................11 75 3.8. Network Management.......................................12 76 4. Security Considerations.......................................13 77 5. IANA Considerations...........................................13 78 6. Acknowledgments...............................................13 79 7. References....................................................14 80 7.1. Normative References.....................................14 81 7.2. Informative References...................................15 82 Authors' Addresses...............................................16 83 Contributing Authors' Addresses..................................16 84 Intellectual Property Statement..................................17 85 Disclaimer of Validity...........................................17 87 1. Introduction 89 1.1. Motivation 91 Transport technologies (e.g. SDH, ATM, OTN) have been designed with 92 specific characteristics: 94 o Strictly connection oriented 96 Long-lived connections 98 Manually provisioned connections 100 o High level of protection and availability 102 o Quality of service 104 o Extended OAM capabilities 106 The development of MPLS-TP has been driven by carriers needing to 107 evolve SONET/SDH networks to support packet based services and 108 networks. 110 MPLS-TP defines a profile of MPLS targeted at transport applications. 111 This profile specifies the specific MPLS characteristics and 112 extensions required to meet transport requirements. 114 1.2. Scope 116 This document specifies the high-level functionality of MPLS-TP 117 required for adding transport-oriented capabilities to MPLS. 119 1.3. Terminology 121 2. Summary of Requirements 123 This section summarizes the requirements for the MPLS transport 124 profile. Such requirements are specified in more detail in [21], . 125 [22] and [23]. 127 Solutions MUST NOT modify the MPLS forwarding architecture, and MUST 128 be based on existing pseudowire and LSP constructs. Point to point 129 LSPs MAY be unidirectional or bi-directional. Bi-directional LSPs 130 MUST be congruent. Point to multipoint LSPs MUST be unidirectional. 132 There MUST NOT be any LSP merging. 134 OAM, protection and forwarding of data packets MUST be able to 135 operate without IP forwarding support i.e. it MUST be possible to 136 forward packets solely based on switching the MPLS or PW label. It 137 must also be possible to establish and maintain LSPs and pseudowires 138 both in the absence or presence of a dynamic control plane. When 139 static provisioning is used, there MUST be no dependency on dynamic 140 routing or signaling. 142 LSP and pseudowire monitoring is only achieved through the use of OAM 143 and MUST NOT rely on control plane or routing functions to determine 144 the health of a path. Information from OAM functions is solely 145 responsible for initiating path recovery actions. 147 Mechanisms and capabilities must be able to interoperate with 148 existing MPLS and pseudowire control and forwarding planes. 150 3. Transport Profile Overview 152 3.1. Architecture 154 The architecture for a transport profile of MPLS (MPLS-TP) is based 155 on the MPLS-TE and (MS-)PW architectures defined in RFC 3031 [2], 156 RFC 3985 [5] and [16]. 158 The MPLS-TP forwarding plane is a profile of the MPLS LSP and (MS-)PW 159 forwarding paradigm as detailed in section .3.4. 161 MPLS-TP supports a comprehensive set of OAM and protection-switching 162 capabilities for packet transport applications, similar to existing 163 SONET/SDH OAM and protection, as described in sections .3.5. and . 164 3.7. 165 MPLS-TP is operated with centralized Network Management Systems with 166 or without the support of a distributed control plane as described in 167 sections .3.6. and .3.8. 169 MPLS-TP defines mechanisms to differentiate specific packets (e.g. 170 OAM, APS, MCC or SCC) from those carrying user data packets. These 171 mechanisms are described in sections .3.2. and .3.3. 173 3.2. Generic-ACH Label (GAL) 175 MPLS-TP requires a mechanism to differentiate specific packets (e.g. 176 OAM) from others, such as normal user-plane ones. This special label 177 is referred to as the 'Generic-ACH Label (GAL)', as defined in [17]. 179 The 'Generic-ACH Label (GAL)' is a generic exception mechanism used 180 firstly to differentiate specific packets (e.g. OAM) from others, 181 such as normal user-plane ones, and secondly, to indicate that the 182 Generic Associated Channel Header (GE-ACH) appears immediately after 183 the bottom of the label stack. 185 Note that MPLS-TP OAM packets will not reside immediately after the 186 'Generic-ACH Label (GAL)' but behind the Generic Associated Channel 187 Header (GE-ACH). 189 In MPLS-TP, the 'Generic-ACH Label (GAL)' always appears at the 190 bottom of the label stack (i.e. S bit set to 1). 192 3.3. Generic Associated Channel Header(GE-ACH) 194 The MPLS transport profile makes use of a generic associated channel 195 (GE-ACH) to support Fault, Configuration, Accounting, Performance and 196 Security (FCAPS) functions by carrying packets related to OAM, APS, 197 SCC and MCC, over LSPs or PWs, carried in band. The GE-ACH is defined 198 in [18] and it is similar to the PWE3 Associated Channel, which is 199 used to carry OAM packets across pseudowires. The GE-ACH is indicated 200 by a generic associated channel header, similar to the PWE3 VCCV 201 control word, and this is present for all LSPs and PWs making use of 202 FCAPS functions supported by the GE-ACH. 204 The GE-ACH functionality for LSPs SHOULD be limited to only OAM, APS, 205 MCC and SCC channel data. 207 Figure 1 shows the reference model depicting how the control channel 208 is associated with the pseudowire protocol stack, as per RFC 5085 . 209 [15]. 211 +-------------+ +-------------+ 212 | Layer2 | | Layer2 | 213 | Emulated | < Emulated Service > | Emulated | 214 | Services | | Services | 215 +-------------+ +-------------+ 216 | | VCCV/PW | | 217 |Demultiplexer| < Associated Channel > |Demultiplexer| 218 +-------------+ +-------------+ 219 | PSN | < PSN Tunnel > | PSN | 220 +-------------+ +-------------+ 221 | Physical | | Physical | 222 +-----+-------+ +-----+-------+ 223 | | 224 | ____ ___ ____ | 225 | _/ \___/ \ _/ \__ | 226 | / \__/ \_ | 227 | / \ | 228 +--------| MPLS/MPLS-TP Network |---+ 229 \ / 230 \ ___ ___ __ _/ 231 \_/ \____/ \___/ \____/ 233 Figure 1 : PWE3 Protocol Stack Reference Model including the PW 234 Associated Control Channel 236 PW associated channel messages are encapsulated using the PWE3 237 encapsulation, so that they are handled and processed in the same 238 manner (or in some cases, an analogous manner) as the PW PDUs for 239 which they provide a control channel. 241 Figure 2 shows the reference model depicting how the control channel 242 is associated with the LSP protocol stack. 244 +-------------+ +-------------+ 245 | | | | 246 | Payload | < Service > | Payload | 247 | Services | | | 248 +-------------+ +-------------+ 249 | | LSP | | 250 |Demultiplexer| < Associated Channel > |Demultiplexer| 251 +-------------+ +-------------+ 252 | PSN | < LSP > | PSN | 253 +-------------+ +-------------+ 254 | Physical | | Physical | 255 +-----+-------+ +-----+-------+ 256 | | 257 | ____ ___ ____ | 258 | _/ \___/ \ _/ \__ | 259 | / \__/ \_ | 260 | / \ | 261 +--------| MPLS/MPLS-TP Network |---+ 262 \ / 263 \ ___ ___ __ _/ 264 \_/ \____/ \___/ \____/ 266 Figure 2 : MPLS Protocol Stack Reference Model including the 267 LSP Associated Control Channel 269 LSP associated channel messages are encapsulated using a generic 270 associated control channel header (GE-ACH). The presence of the GE- 271 ACH is indicated by the inclusion of an additional 'Generic-ACH Label 272 (GAL)'. This arrangement means that both normal data packets and 273 packets carrying an ACH are carried over LSPs in a similar manner. 274 Note that where a traffic engineered LSP is used the paths will be 275 identical. 277 3.4. Forwarding 279 MPLS-TP LSPs use the MPLS label switching operations defined in RFC 280 3031 [2]. The MPLS encapsulation format is as defined in RFC 3032 . 281 [3]. Per-platform or the per-interface label space can be selected. 283 MPLS-TP (MS-)PWs support the PW forwarding operations defined in . 284 [5]. Standard PW encapsulation mechanisms are applicable for 285 different client layers as defined by the IETF PWE3 WG. 287 MPLS-TP LSPs can be unidirectional or bidirectional point-to-point. 288 As for MPLS, point-to-multipoint MPLS-TP LSPs are unidirectional. 290 The forward and backward directions of bidirectional MPLS-TP LSPs are 291 congruent: they follow the same path and the pairing relationship 292 between the forward and the backward directions is known in each node 293 traversed by bidirectional LSPs. 295 Equal cost multi-path (ECMP) load balancing is not applicable to 296 MPLS-TP LSPs. MPLS-TP LSP merging is prohibited. 298 Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default. 300 Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270 301 [4]. 303 The Class of Service (CoS) field (former MPLS EXP field) follows the 304 definition and processing rules of [19] and RFC 3270 [4], only the 305 pipe and short-pipe models are supported in MPLS-TP. 307 3.5. Operations and Management (OAM) 309 MPLS-TP requires that a set of OAM capabilities is available to 310 perform fault management (e.g. fault detection and localization) and 311 performance monitoring (e.g. signal quality measurement) of the MPLS- 312 TP network and the services. 314 The following OAM functions are intended to be supported by MPLS-TP 315 and are intended to be applicable to any layer defined within MPLS- 316 TP, i.e. MPLS Section, LSP and PW: 318 o Continuity Check 320 o Connectivity verification 322 o Performance monitoring 324 o Alarm suppression 326 o Remote Integrity 328 For all of the above listed functions, (except alarm suppression) 329 both "continuous" and "on-demand" operations are envisaged. 331 Performance monitoring includes means for both "packet loss 332 measurement" and "delay measurement". 334 A requirement has been expressed for MPLS-TP OAM packets share the 335 same fate as of data packets and that a means exists to identify OAM 336 packets. The documents [17] and [18] propose specific mechanisms 337 relying on the combination of the 'Generic-ACH Label (GAL)' and 338 Generic Associated Channel Header for MPLS Sections and LSPs and 339 using the Generic Associated Channel Header only for MPLS PWs. 341 MPLS-TP OAM toolset is able to operate without IP functionality and 342 without relying on control and/or management planes. In the case of 343 MPLS-TP deployment with IP functionality, all existing IP-MPLS OAM 344 functions, e.g. LSP-Ping, BFD and VCCV, can be used. 346 OAM mechanisms are able to detect link and node failures and 347 performance degradations and trigger recovery actions, according to 348 the requirements of the service. 350 3.6. Control Plane 352 The MPLS Transport Profile utilizes a distributed control plane to 353 enable fast, dynamic and reliable service provisioning in multi- 354 vendor and multi-domain environments using standardized protocols 355 that guarantee interoperability. The MPLS-TP control plane is based 356 on the MPLS control plane for pseudowires and the GMPLS control plane 357 for MPLS-TP LSPs, respectively. More specifically, LDP is used for PW 358 signaling and RSVP-TE for LSP signaling. The distributed MPLS-TP 359 control plane provides the following basic functions: 361 o Signaling 363 o Routing 365 o Traffic engineering and constraint-based path computation 367 In a multi-domain environment, the MPLS-TP control plane provides 368 different types of interfaces at domain boundaries or within the 369 domains such as UNI, I-NNI, and E-NNI where different policies are in 370 place that control what kind of information is exchanged across these 371 different types of interfaces. 373 The MPLS-TP control plane is capable to activate MPLS-TP OAM 374 functions as described in the OAM section of this document (.3.5. ) 375 e.g. for fault detection and localization in the event of a failure 376 in order to efficiently restore failed transport paths. 378 The MPLS-TP control plane supports all MPLS-TP data plane 379 connectivity patterns that are needed for establishing multiple types 380 of transport paths including protected paths as described in the 381 survivability section (.3.7. ) of this document. Examples of the 382 MPLS-TP data plane connectivity patterns are LSPs utilizing the fast 383 reroute backup methods as defined in [6] and ingress-to-egress 1+1 384 or 1:1 protected LSPs. 386 Moreover, the MPLS-TP control plane is capable of performing fast 387 restoration in the event of network failures. 389 The MPLS-TP control plane provides its own survivability features and 390 recovers from control plane failures and degradations using graceful 391 operations. The MPLS-TP control plane is largely decoupled from the 392 MPLS-TP data plane such that failures in the control plane do not 393 impact the control plane and vice versa. 395 3.6.1. PW Control Plane 397 An MPLS-TP packet transport network provides many of its transport 398 services in the form of single-segment or multi-segment pseudowires 399 following the PWE3 architecture as defined in [5] and [16] . In 400 this context, the setup and maintenance of single-segment or multi- 401 segment pseudowires is based on the Label Distribution Protocol (LDP) 402 as per [9]. 404 It shall be noted that multi-segment pseudowire signaling is still 405 work in progress. The control plane supporting multi-segment 406 pseudowires is based on [13]. 408 3.6.2. LSP Control Plane 410 MPLS-TP provider edge nodes aggregate multiple pseudowires and carry 411 them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP 412 LSPs). The generalized MPLS (GMPLS) protocol suite already supports 413 packet-switched capable (PSC) technologies and is therefore used as 414 control plane for MPLS-TP transport paths (LSPs). The LSP control 415 plane includes: 417 o RSVP-TE for signalling 419 o OSPF-TE for routing 421 RSVP-TE signaling in support of GMPLS as defined in [11] is used for 422 the setup, modification, and release of MPLS-TP transport paths and 423 protection paths. It supports unidirectional, bi-directional and 424 multicast types of LSPs. The route of a transport path is typically 425 calculated in the ingress node of a domain and the RSVP explicit 426 route object (ERO) is utilized for the setup of the transport path 427 exactly following the given route. 429 OSPF-TE routing in support of GMPLS as defined in [8] is used for 430 carrying link state information in a MPLS-TP network. 432 For routing scalability reasons, parallel physical links in an MPLS- 433 TP network are typically bundled into TE-links as defined in [7] and 434 the OSPF-TE routing protocol disseminates link state information on a 435 TE-link basis. 437 3.7. Survivability 439 A wide variety of resiliency schemes have been developed to meet the 440 various network and service survivability objectives. As part of the 441 MPLS/PW paradigms, MPLS FRR [6] provides two methods for local 442 repair using back-up LSP tunnels, while PWE redundancy [14] supports 443 scenarios where the protection for the PW can not be fully provided 444 by the PSN layer (i.e. where the backup PW terminates on a different 445 target PE node than the working PW). Additionally, GMPLS provides a 446 set of control plane driven well known protection and restoration 447 mechanisms [11]. Finally, as part of the transport networks and 448 applications paradigms, APS-based linear and ring protection 449 mechanisms are defined in [10] and [24]. 451 These schemes have different scopes. They are protecting against link 452 and/or node failures and can be applied end-to-end or on a segment of 453 the considered connection. 455 These protection schemes propose different levels of resiliency (e.g. 456 1+1, 1:1, shared). 458 The applicability of any given scheme to meet specific requirements 459 is outside the current scope of this document. 461 MPLS-TP resiliency mechanisms characteristics are listed below 463 o Linear, ring and meshed protection schemes are supported. 465 o MPLS-TP recovery mechanisms (protection and restoration), rely on 466 OAM mechanisms to detect and localize network faults or service 467 degenerations. 469 o APS-based protection mechanisms (linear and ring) rely on MPLS-TP 470 APS mechanisms to coordinate and trigger protection switching 471 actions. 473 o MPLS-TP recovery schemes are designed to be applicable at various 474 levels (MPLS section, LSP and PW), providing segment and end-to- 475 end recovery. 477 o MPLS-TP recovery mechanisms support means for avoiding race 478 conditions in switching activity triggered by a fault condition 479 detected both at server layer and at MPLS-TP layer. 481 o MPLS-TP recovery mechanisms can be data plane, control plane or 482 management plane based. 484 o MPLS-TP allows for revertive and non-revertive behavior 486 o Multiple resiliency mechanisms can be applied to any connection. 488 3.8. Network Management 490 The network management architecture and requirements for MPLS-TP are 491 specified in [23]. It derives from the generic specifications 492 described in ITU-T G.7710/Y.1701 [12] for transport technologies. It 493 also leverages on the OAM requirements for MPLS Networks [20] and 494 MPLS-TP Networks [22] and expands on the requirements to cover the 495 modifications necessary for fault, configuration, performance, and 496 security. 498 The Equipment Management Function (EMF) of a MPLS-TP NE provides the 499 means through which a management system manages the NE. The 500 Management Communication Channel (MCC), realized by the GE-ACH, 501 provides a logical operations channel between NEs for transferring 502 Management information. For the management interface from a 503 management system to a MPLS-TP NE, there is no restriction on which 504 management protocol should be used. It is allowed to provision and 505 manage an end-to-end connection across a network where some segments 506 are create/managed, for examples by Netconf or SNMP and other 507 segments by XML or CORBA interfaces. It is allowed to run maintenance 508 operations on a connection which is independent of the provisioning 509 mechanism. An MPLS-TP NE is not required to offer more than one 510 standard management interface. 512 The Fault Management (FM) functions within the EMF of an MPLS-TP NE 513 enable the supervision, detection, validation, isolation, correction, 514 and alarm handling of abnormal operation of the MPLS-TP network and 515 its environment. Supervision for transmission (such as continuity, 516 connectivity, etc.), software processing, hardware, and environment 517 are essential for FM. Alarm handling includes alarm severity 518 assignment, alarm suppression/aggregation/correlation, alarm 519 reporting control, and alarm reporting. 521 Configuration Management (CM) provides functions to exercise control 522 over, identify, collect data from, and provide data to MPLS-TP NEs. 523 In addition to general configuration for hardware, software, 524 protection switching, alarm reporting control, and date/time setting, 525 the EMF of the MPLS-TP NE also supports the configuration of 526 maintenance entity identifiers (such as MEP ID and MIP ID). The EMF 527 also supports configuration of the OAM parameters as part of 528 connectivity management to meet specific operational requirements, 529 such as whether one-time on-demand or periodically based on a 530 specified frequency. 532 The Performance Management (PM) functions within the EMF of an MPLS- 533 TP NE supports the evaluation and reporting upon the behaviour of the 534 equipment, NE, and network with the objective of providing coherent 535 and consistent interpretation of the network behaviour, in particular 536 for hybrid network which consists of multiple transport technologies. 537 Packet loss measurement and delay measurement are collected so that 538 they can be used to detect performance degradation. Performance 539 degradation is reported via fault management for corrective actions 540 (e.g. protection switch) and via performance monitoring for Service 541 Level Agreement (SLA) verification and billing. The performance data 542 collection mechanisms should be flexible to be configured to operate 543 on-demand or proactively. 545 4. Security Considerations 547 To be covered in a future revision of this document. 549 5. IANA Considerations 551 To be covered in a future revision of this document. 553 6. Acknowledgments 555 To be covered in a future revision of this document. 557 7. References 559 7.1. Normative References 561 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 562 Levels", BCP 14, RFC 2119, March 1997. 564 [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label 565 Switching Architecture", RFC 3031, January 2001 567 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 568 January 2001 570 [4] Le Faucheur, F., et al., "Multi-Protocol Label Switching (MPLS) 571 Support of Differentiated Services", RFC 3270 May 2002 573 [5] Bryant, S., Pate, P. "Pseudo Wire Emulation Edge-to-Edge (PWE3) 574 Architecture", RFC 3985, March 2005 576 [6] Pan, P., Swallow, G., Atlas, A., "Fast Reroute Extensions to 577 RSVP-TE for LSP Tunnels", RFC 4090, May 2005 579 [7] Kompella, K. Rekhter, Y., Berger, L., " Link Bundling in MPLS 580 Traffic Engineering (TE)", RFC 4201 October, 2005 582 [8] Kompella, K. Rekhter, Y., "OSPF Extensions in Support of 583 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203 584 October 2005 586 [9] Martini, L. et al., "Pseudowire Setup and Maintenance Using the 587 Label Distribution Protocol (LDP)", RFC 4447, April 2006 589 [10] ITU-T Recommendation G.8131/Y.1382 (02/07) " Linear protection 590 switching for Transport MPLS (T-MPLS) networks" 592 [11] Lang, J.P., Rekhter, Y., Papadimitriou, D. (Editors), "RSVP-TE 593 Extensions in Support of End-to-End Generalized Multi-Protocol 594 Label Switching (GMPLS) Recovery", RFC 4872, May 2007 596 [12] ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment 597 management function requirements" 599 [13] Martini, L., Bocci, M., Balus, F., "Dynamic Placement of Multi 600 Segment Pseudo Wires", draft-ietf-pwe3-dynamic-ms-pw-06, 601 November 2007 603 [14] Muley, P., et al., "Pseudowire (PW) Redundancy", draft-muley- 604 pwe3-redundancy-02, November 2007 606 [15] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit 607 Connectivity Verification (VCCV): A Control Channel for 608 Pseudowires", RFC 5085, December 2007 610 [16] Bocci, M., Bryant, S., "An Architecture for Multi-Segment 611 Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch- 612 04, June 2008 614 [17] Vigoureux, M., Swallow, G., Aggarwal, R., "Assignment of the 615 Generic Associated Channel Header Label (GAL)", draft- 616 vigoureux-mpls-tp-gal-00, June 2008 618 [18] Bocci, M., Ward, D., "MPLS Generic Associated Channel", draft- 619 bocci-pwe3-mpls-tp-ge-ach-00, June 2008 621 [19] Andersson, L., ""EXP field" renamed to "CoS Field"", draft- 622 ietf-mpls-cosfield-def-03, July 2008 624 7.2. Informative References 626 [20] Nadeau, T., et al., "Operations and Management (OAM) 627 Requirements for Multi-Protocol Label Switched (MPLS) 628 Networks", RFC 4377, February 2006 630 [21] Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP 631 Requirements", draft-jenkins-mpls-mpls-tp-requirements-00, July 632 2008 634 [22] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 635 MPLS Transport Networks", draft-vigoureux-mpls-tp-oam- 636 requirements-00, July 2008 638 [23] Lam, H.-K., Mansfield, S., Gray, E., "MPLS TP Network 639 Management Requirements", draft-gray-mpls-tp-nm-req-00, July 640 2008 642 [24] Draft ITU-T Recommendation G.8132/Y.1382, "T-MPLS shared 643 protection ring", http://www.itu.int/md/T05-SG15-080211-TD- 644 PLEN-0501/en 646 Authors' Addresses 648 Matthew Bocci 649 Alcatel-Lucent 651 Email: matthew.bocci@alcatel-lucent.co.uk 653 Marc Lasserre 654 Alcatel-Lucent 656 Email: mlasserre@alcatel-lucent.com 658 Stewart Bryant 659 Cisco Systems, Inc. 661 Email :stbryant@cisco.com 663 Contributing Authors' Addresses 665 Dieter Beller 666 Alcatel-Lucent 668 Email: d.beller@alcatel-lucent.de 670 Italo Busi 671 Alcatel-Lucent 673 Email: italo.busi@alcatel-lucent.it 675 Hing-Kam Lam 676 Alcatel-Lucent 678 Email: hklam@alcatel-lucent.com 680 Lieven Levrau 681 Alcatel-Lucent 683 Email: llevrau@alcatel-lucent.com 684 Vincenzo Sestito 685 Alcatel-Lucent 687 Email: vincenzo.sestito@alcatel-lucent.it 689 Martin Vigoureux 690 Alcatel-Lucent 692 Email: martin.vigoureux@alcatel-lucent.com 694 Intellectual Property Statement 696 The IETF takes no position regarding the validity or scope of any 697 Intellectual Property Rights or other rights that might be claimed to 698 pertain to the implementation or use of the technology described in 699 this document or the extent to which any license under such rights 700 might or might not be available; nor does it represent that it has 701 made any independent effort to identify any such rights. Information 702 on the procedures with respect to rights in RFC documents can be 703 found in BCP 78 and BCP 79. 705 Copies of IPR disclosures made to the IETF Secretariat and any 706 assurances of licenses to be made available, or the result of an 707 attempt made to obtain a general license or permission for the use of 708 such proprietary rights by implementers or users of this 709 specification can be obtained from the IETF on-line IPR repository at 710 http://www.ietf.org/ipr. 712 The IETF invites any interested party to bring to its attention any 713 copyrights, patents or patent applications, or other proprietary 714 rights that may cover technology that may be required to implement 715 this standard. Please address the information to the IETF at ietf- 716 ipr@ietf.org. 718 Disclaimer of Validity 720 This document and the information contained herein are provided on an 721 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 722 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 723 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 724 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 725 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 726 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 728 Copyright Statement 730 Copyright (C) The IETF Trust (2008). 732 This document is subject to the rights, licenses and restrictions 733 contained in BCP 78, and except as set forth therein, the authors 734 retain all their rights. 736 Acknowledgment 738 Funding for the RFC Editor function is currently provided by the 739 Internet Society.