idnits 2.17.1 draft-ietf-mpls-tp-data-plane-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2010) is 5047 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) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-fc-encap-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS D. Frost, Ed. 3 Internet-Draft S. Bryant, Ed. 4 Intended status: Standards Track Cisco Systems 5 Expires: January 2, 2011 M. Bocci, Ed. 6 Alcatel-Lucent 7 July 1, 2010 9 MPLS Transport Profile Data Plane Architecture 10 draft-ietf-mpls-tp-data-plane-04 12 Abstract 14 The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) 15 is the set of MPLS protocol functions applicable to the construction 16 and operation of packet-switched transport networks. This document 17 specifies the subset of these functions that comprises the MPLS-TP 18 data plane: the architectural layer concerned with the encapsulation 19 and forwarding of packets within an MPLS-TP network. 21 This document is a product of a joint Internet Engineering Task Force 22 (IETF) / International Telecommunication Union Telecommunication 23 Standardization Sector (ITU-T) effort to include an MPLS Transport 24 Profile within the IETF MPLS and PWE3 architectures to support the 25 capabilities and functionalities of a packet transport network. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 2, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. MPLS-TP Packet Encapsulation and Forwarding . . . . . . . . . 4 71 3. MPLS-TP Transport Entities . . . . . . . . . . . . . . . . . . 5 72 3.1. Label Switched Paths . . . . . . . . . . . . . . . . . . . 5 73 3.1.1. LSP Packet Encapsulation and Forwarding . . . . . . . 5 74 3.1.2. LSP Payloads . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.3. LSP Types . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3. Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 9 78 4. MPLS-TP Generic Associated Channel . . . . . . . . . . . . . . 10 79 5. Server Layer Considerations . . . . . . . . . . . . . . . . . 11 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The MPLS Transport Profile (MPLS-TP) is the set of functions that 90 meet the requirements [RFC5654] for the application of MPLS to the 91 construction and operation of packet-switched transport networks. 92 MPLS-based packet-switched transport networks, and the overall 93 architecture of the MPLS-TP, are defined and described in 94 [I-D.ietf-mpls-tp-framework]. It is assumed that the reader is 95 familiar with that document. 97 This document defines the set of functions that comprise the MPLS-TP 98 data plane: the architectural layer concerned with the encapsulation 99 and forwarding of packets within an MPLS-TP network. This layer is 100 based on the data plane architectures for MPLS ([RFC3031] and 101 [RFC3032]) and for pseudowires ([RFC3985]). 103 This document is a product of a joint Internet Engineering Task Force 104 (IETF) / International Telecommunication Union Telecommunication 105 Standardization Sector (ITU-T) effort to include an MPLS Transport 106 Profile within the IETF MPLS and PWE3 architectures to support the 107 capabilities and functionalities of a packet transport network. 109 1.1. Scope 111 This document has the following purposes: 113 o To identify the data plane functions within the MPLS Transport 114 Profile; 116 o To indicate which of these data plane functions an MPLS-TP 117 implementation is required to support. 119 This document defines the encapsulation and forwarding functions 120 applicable to packets traversing an MPLS-TP Label Switched Path 121 (LSP), Pseudowire (PW), or Section (see Section 3 for the definitions 122 of these transport entities). Encapsulation and forwarding functions 123 for packets outside an MPLS-TP LSP, PW, or Section, and mechanisms 124 for delivering packets to or from MPLS-TP LSPs, PWs, and Sections, 125 are outside the scope of this document. 127 1.2. Terminology 129 Term Definition 130 ------- ------------------------------------------ 131 ACH Associated Channel Header 132 G-ACh Generic Associated Channel 133 GAL G-ACh Label 134 LER Label Edge Router 135 LSE Label Stack Entry 136 LSP Label Switched Path 137 LSR Label Switching Router 138 MPLS-TP MPLS Transport Profile 139 OAM Operations, Administration and Maintenance 140 PW Pseudowire 141 QoS Quality of Service 142 S-PE PW Switching Provider Edge Node 143 T-PE PW Terminating Provider Edge Node 144 TTL Time To Live 146 Additional definitions and terminology can be found in 147 [I-D.ietf-mpls-tp-framework] and [RFC5654]. 149 2. MPLS-TP Packet Encapsulation and Forwarding 151 MPLS-TP packet encapsulation and forwarding SHALL operate according 152 to the MPLS data plane architecture described in [RFC3031] and 153 [RFC3032], and the data plane architectures for Single-Segment 154 Pseudowires and Multi-Segment Pseudowires (see Section 3.3), except 155 as noted otherwise in this document. The MPLS-TP data plane 156 satisfies the requirements specified in [RFC5654]. 158 Since an MPLS-TP packet is an MPLS packet as defined in [RFC3031] and 159 [RFC3032], it will have an associated label stack, and the 'push', 160 'pop', and 'swap' label processing operations specified in those 161 documents apply. The label stack represents a hierarchy of Label 162 Switched Paths (LSPs). A label is pushed to introduce an additional 163 level of LSP hierarchy and popped to remove it. Such an additional 164 level may be introduced by any pair of LSRs, whereupon they become 165 adjacent at this new level, and are then known as Label Edge Routers 166 (LERs) with respect to the new LSP. 168 In contrast to, for example, Section 3.10 of [RFC3031], support for 169 Internet Protocol (IP) host and router data plane functionality by 170 MPLS-TP interfaces and in MPLS-TP networks is OPTIONAL. 172 MPLS-TP forwarding is based on the label that identifies an LSP or 173 PW. The label value specifies the processing operation to be 174 performed by the next hop at that level of encapsulation. A swap of 175 this label is an atomic operation in which the contents of the packet 176 after the swapped label are opaque to the forwarding function. The 177 only event that interrupts a swap operation is Time To Live (TTL) 178 expiry. 180 At an LSR, S-PE, or T-PE, further processing to determine the context 181 of a packet occurs when a swap operation is interrupted by TTL 182 expiry. If the TTL of an LSP label expires, then the label with the 183 S (Bottom of Stack) bit set is inspected to determine if it is a 184 reserved label. If it is a reserved label, the packet is processed 185 according to the rules of that reserved label. For example, if it is 186 a Generic Associated Channel Label (GAL), then it is processed as a 187 packet on the G-ACh; see Section 4. If the TTL of a PW expires at an 188 S-PE or T-PE, then the packet is examined to determine if a Generic 189 Associated Channel Header (ACH) is present immediately below the PW 190 label. If so, then the packet is processed as a packet on the G-ACh. 192 Similarly, if a pop operation at an LER exposes a reserved label at 193 the top of the label stack, then the packet is processed according to 194 the rules of that reserved label. 196 If no such exception occurs, the packet is forwarded according to the 197 procedures in [RFC3031] and [RFC3032]. 199 3. MPLS-TP Transport Entities 201 The MPLS Transport Profile includes the following data plane 202 transport entities: 204 o Label Switched Paths (LSPs) 206 o Sections 208 o Pseudowires (PWs) 210 3.1. Label Switched Paths 212 MPLS-TP LSPs are ordinary MPLS LSPs as defined in [RFC3031] except as 213 specifically noted otherwise in this document. 215 3.1.1. LSP Packet Encapsulation and Forwarding 217 Encapsulation and forwarding of packets traversing MPLS-TP LSPs MUST 218 follow standard MPLS packet encapsulation and forwarding as defined 219 in [RFC3031], [RFC3032], [RFC5331], and [RFC5332], except as 220 explicitly stated otherwise in this document. 222 Data plane Quality of Service capabilities are included in the 223 MPLS-TP in the form of Traffic Engineered (TE) LSPs [RFC3209] and the 224 MPLS Differentiated Services (DiffServ) architecture [RFC3270]. Both 225 E-LSP and L-LSP MPLS DiffServ modes are included. The Traffic Class 226 field (formerly the EXP field) of an MPLS label follows the 227 definition of [RFC5462] and [RFC3270] and MUST be processed according 228 to the rules specified in those documents. 230 Except for transient packet reordering which may occur, for example, 231 during fault conditions, packets are delivered in order on L-LSPs, 232 and on E-LSPs within a specific ordered aggregate. 234 The Uniform, Pipe and Short Pipe DiffServ tunneling and TTL 235 processing models described in [RFC3270] and [RFC3443] MAY be used 236 for MPLS-TP LSPs. Note however that support for the Pipe or Short 237 Pipe models is REQUIRED for typical transport applications, in which 238 the topology and QoS characteristics of the MPLS-TP server layer are 239 independent of the client layer. Specific applications MAY place 240 further requirements on the DiffServ tunneling and TTL processing 241 models an LSP can use. 243 Per-platform, per-interface or other context-specific label space 244 [RFC5331] MAY be used for MPLS-TP LSPs. Downstream [RFC3031] or 245 upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP 246 LSPs. The requirements of a particular LSP type may, however, 247 dictate which label spaces or allocation schemes it can use. 249 Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on 250 an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate 251 over a server layer that supports load-balancing, but this load- 252 balancing MUST operate in such a manner that it is transparent to 253 MPLS-TP. This does not preclude the future definition of new MPLS-TP 254 LSP types which have different requirements regarding the use of ECMP 255 in the server layer. 257 Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP 258 LSPs. 260 3.1.2. LSP Payloads 262 The MPLS-TP includes support for the following LSP payload types: 264 o Network-layer protocol packets (including MPLS-labeled packets) 266 o Pseudowire packets 268 The rules for processing LSP payloads that are network-layer protocol 269 packets SHALL be as specified in [RFC3032]. 271 The rules for processing LSP payloads that are pseudowire packets 272 SHALL be as defined in the data plane pseudowire specifications (see 273 Section 3.3). 275 The payload of an MPLS-TP LSP may be a packet that itself contains an 276 MPLS label stack. This is true, for instance, when the payload is a 277 pseudowire or an MPLS LSP. In such cases, the label stack is 278 contiguous between the MPLS-TP LSP and its payload, and exactly one 279 LSE in this stack SHALL have the S (Bottom of Stack) bit set to 1. 280 This behaviour reflects best current practice in MPLS but differs 281 slightly from [RFC3032], which uses the S bit to identify when MPLS 282 label processing stops and network layer processing starts. 284 3.1.3. LSP Types 286 The MPLS-TP includes the following LSP types: 288 o Point-to-point unidirectional 290 o Point-to-point associated bidirectional 292 o Point-to-point co-routed bidirectional 294 o Point-to-multipoint unidirectional 296 Point-to-point unidirectional LSPs are supported by the basic MPLS 297 architecture [RFC3031] and are REQUIRED to function in the same 298 manner in the MPLS-TP data plane except as explicitly stated 299 otherwise in this document. 301 A point-to-point associated bidirectional LSP between LSRs A and B 302 consists of two unidirectional point-to-point LSPs, one from A to B 303 and the other from B to A, which are regarded as a pair providing a 304 single logical bidirectional transport path. 306 A point-to-point co-routed bidirectional LSP is a point-to-point 307 associated bidirectional LSP with the additional constraint that its 308 two unidirectional component LSPs in each direction follow the same 309 path (in terms of both nodes and links). An important property of 310 co-routed bidirectional LSPs is that their unidirectional component 311 LSPs share fate. 313 A point-to-multipoint unidirectional LSP functions in the same manner 314 in the data plane, with respect to basic label processing and packet- 315 switching operations, as a point-to-point unidirectional LSP, with 316 one difference: an LSR may have more than one (egress interface, 317 outgoing label) pair associated with the LSP, and any packet it 318 transmits on the LSP is transmitted out all associated egress 319 interfaces. Point-to-multipoint LSPs are described in [RFC4875] and 320 [RFC5332]. TTL processing and exception handling for point-to- 321 multipoint LSPs is the same as for point-to-point LSPs and is 322 described in Section 2. 324 3.2. Sections 326 Two MPLS-TP LSRs are considered to be topologically adjacent at a 327 particular layer n >= 0 of the MPLS-TP LSP hierarchy if there exists 328 connectivity between them at the next lowest network layer, and if 329 there is no MPLS layer processing at layer n between the two LSRs 330 (other than at the LSRs themselves). Such connectivity, if it 331 exists, will be either an MPLS-TP LSP (if n > 0) or a data-link 332 provided by the underlying server layer network (if n = 0), and is 333 referred to as an MPLS-TP Section at layer n of the MPLS-TP LSP 334 hierarchy. Thus, the links traversed by a layer n+1 MPLS-TP LSP are 335 layer n MPLS-TP sections. Such an LSP is referred to as a client of 336 the section layer, and the section layer as the server layer with 337 respect to its clients. 339 The MPLS label stack associated with an MPLS-TP section at layer n 340 consists of n labels, in the absence of stack optimisation 341 mechanisms. In order for two LSRs to exchange non-IP MPLS-TP control 342 packets over a section, an additional label, the G-ACh Label (GAL) 343 (see Section 4) MUST appear at the bottom of the label stack. 345 An MPLS-TP section may provide one or more of the following types of 346 service to its client layer: 348 o Point-to-point bidirectional 350 o Point-to-point unidirectional 352 o Point-to-multipoint unidirectional 354 The manner in which a section provides such a service is outside the 355 scope of the MPLS-TP. 357 An LSP of any of the types listed in Section 3.1.3 may serve as a 358 section for a client-layer transport entity as long as it supports 359 the type of service the client requires. 361 A section MUST provide a means of identifying the type of payload it 362 carries. If the section is a data-link, link-specific mechanisms 363 such as a protocol type indication in the data-link header MAY be 364 used. If the section is an LSP, this information MAY be implied by 365 the LSP label or, if the LSP payload is MPLS-labeled, by the setting 366 of the S bit. Additional labels MAY also be used if necessary to 367 distinguish different payload types; see [I-D.ietf-mpls-tp-framework] 368 for examples and further discussion. 370 3.3. Pseudowires 372 The data plane architectures for Single-Segment Pseudowires [RFC3985] 373 and Multi-Segment Pseudowires [RFC5659] are included in the MPLS-TP. 375 Data plane processing procedures for pseudowires are defined and 376 described in a number of IETF documents. Some example pseudowire 377 data plane procedures include: 379 o Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over 380 an MPLS PSN [RFC4385] 382 o Encapsulation Methods for Transport of Ethernet over MPLS Networks 383 [RFC4448] 385 o Structure-Agnostic Time Division Multiplexing (TDM) over Packet 386 (SAToP) [RFC4553] 388 o Encapsulation Methods for Transport of PPP/High-Level Data Link 389 Control (HDLC) over MPLS Networks [RFC4618] 391 o Encapsulation Methods for Transport of Frame Relay over 392 Multiprotocol Label Switching (MPLS) Networks [RFC4619] 394 o Encapsulation Methods for Transport of Asynchronous Transfer Mode 395 (ATM) over MPLS Networks [RFC4717] 397 o Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer 398 Mode (ATM) Transparent Cell Transport Service [RFC4816] 400 o Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/ 401 SDH) Circuit Emulation over Packet (CEP) [RFC4842] 403 o Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation 404 Service over Packet Switched Network (CESoPSN) [RFC5086] 406 o Time Division Multiplexing over IP (TDMoIP) [RFC5087] 408 o Encapsulation Methods for Transport of Fibre Channel Frames Over 409 MPLS Networks [I-D.ietf-pwe3-fc-encap] 411 This document specifies no modifications or extensions to pseudowire 412 data plane architectures or protocols. 414 4. MPLS-TP Generic Associated Channel 416 The MPLS Generic Associated Channel (G-ACh) mechanism is specified in 417 [RFC5586] and included in the MPLS-TP. The G-ACh provides an 418 auxiliary logical data channel associated with MPLS-TP Sections, 419 LSPs, and PWs in the data plane. The primary purpose of the G-ACh in 420 the context of MPLS-TP is to support control, management, and 421 Operations, Administration and Maintenance (OAM) traffic associated 422 with MPLS-TP transport entities. The G-ACh MUST NOT be used to 423 transport client layer network traffic in MPLS-TP networks. 425 For pseudowires, the G-ACh uses the first four bits of the PW control 426 word to provide the initial discrimination between data packets and 427 packets belonging to the associated channel, as described in 428 [RFC4385]. When this first nibble of a packet, immediately following 429 the label at the bottom of stack, has a value of '1', then this 430 packet belongs to a G-ACh. The first 32 bits following the bottom of 431 stack label then have a defined format called an Associated Channel 432 Header (ACH), which further defines the content of the packet. The 433 ACH is therefore both a demultiplexer for G-ACh traffic on the PW, 434 and a discriminator for the type of G-ACh traffic. 436 When the control message is carried over a section or an LSP, rather 437 than over a PW, it is necessary to provide an indication in the 438 packet that the payload is something other than a client data packet. 439 This is achieved by including a reserved label with a value of 13 at 440 the bottom of the label stack. This reserved label is referred to as 441 the G-ACh Label (GAL), and is defined in [RFC5586]. When a GAL is 442 found, it indicates that the payload begins with an ACH. The GAL is 443 thus a demultiplexer for G-ACh traffic on the section or the LSP, and 444 the ACH is a discriminator for the type of traffic carried on the 445 G-ACh. MPLS-TP forwarding follows the normal MPLS model, and thus a 446 GAL is invisible to an LSR unless it is the top label in the label 447 stack. The only other circumstance under which the label stack may 448 be inspected for a GAL is when the TTL has expired. Normal packet 449 forwarding MAY continue concurrently with this inspection. All 450 operations on the label stack are in accordance with [RFC3031] and 451 [RFC3032]. 453 An application processing a packet received over the G-ACh may 454 require packet-specific context (such as the receiving interface or 455 received label stack). Data plane implementations MUST therefore 456 provide adequate context to the application which is to process a 457 G-ACh packet. The definition of the context required MUST be 458 provided as part of the specification of the application using the 459 G-ACh. 461 5. Server Layer Considerations 463 The MPLS-TP network has no awareness of the internals of the server 464 layer of which it is a client, requiring only that the server layer 465 be capable of delivering the type of service required by the MPLS-TP 466 transport entities that make use of it. Note that what appears to be 467 a single server layer link to the MPLS-TP network may be a 468 complicated construct underneath, such as an LSP or a collection of 469 underlying links operating as a bundle. Special care may be needed 470 in network design and operation when such constructs are used as a 471 server layer for MPLS-TP. 473 Encapsulation of MPLS-TP packets for transport over specific server- 474 layer media is outside the scope of this document. 476 6. Security Considerations 478 The MPLS data plane (and therefore the MPLS-TP data plane) does not 479 provide any security mechanisms in and of itself. Client layers that 480 wish to secure data carried over MPLS-TP transport entities are 481 REQUIRED to apply their own security mechanisms. 483 Where management or control plane protocols are used to install label 484 switching operations necessary to establish MPLS-TP transport paths, 485 those protocols are equipped with security features and network 486 operators may use those features to securely create the transport 487 paths. 489 Where enhanced security is desirable, and a trust relationship exists 490 between an LSR and its peer, the LSR MAY choose to implement the 491 following policy for the processing of MPLS packets received from one 492 or more of its neighbours: 494 Upon receipt of an MPLS packet, discard the packet unless one of 495 the following two conditions holds: 497 1. Any MPLS label in the packet's label stack processed at the 498 receiving LSR, such as an LSP or PW label, has a label value 499 that the receiving LSR has distributed to that neighbour; or 501 2. Any MPLS label in the packet's label stack processed at the 502 receiving LSR, such as an LSP or PW label, has a label value 503 that the receiving LSR has previously distributed to the peer 504 beyond that neighbour (i.e., when it is known that the path 505 from the system to which the label was distributed to the 506 receiving system is via that neighbour). 508 Further details of MPLS and MPLS-TP security can be found in 509 [I-D.ietf-mpls-tp-framework] and 510 [I-D.ietf-mpls-mpls-and-gmpls-security-framework]. 512 7. IANA Considerations 514 This document introduces no new IANA considerations. 516 8. References 518 8.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 524 Label Switching Architecture", RFC 3031, January 2001. 526 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 527 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 528 Encoding", RFC 3032, January 2001. 530 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 531 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 532 Tunnels", RFC 3209, December 2001. 534 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 535 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 536 Protocol Label Switching (MPLS) Support of Differentiated 537 Services", RFC 3270, May 2002. 539 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 540 in Multi-Protocol Label Switching (MPLS) Networks", 541 RFC 3443, January 2003. 543 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 544 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 545 Use over an MPLS PSN", RFC 4385, February 2006. 547 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 548 "Encapsulation Methods for Transport of Ethernet over MPLS 549 Networks", RFC 4448, April 2006. 551 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 552 Division Multiplexing (TDM) over Packet (SAToP)", 553 RFC 4553, June 2006. 555 [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, 556 "Encapsulation Methods for Transport of PPP/High-Level 557 Data Link Control (HDLC) over MPLS Networks", RFC 4618, 558 September 2006. 560 [RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation 561 Methods for Transport of Frame Relay over Multiprotocol 562 Label Switching (MPLS) Networks", RFC 4619, 563 September 2006. 565 [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., 566 Brayley, J., and G. Koleyni, "Encapsulation Methods for 567 Transport of Asynchronous Transfer Mode (ATM) over MPLS 568 Networks", RFC 4717, December 2006. 570 [RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, 571 "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous 572 Transfer Mode (ATM) Transparent Cell Transport Service", 573 RFC 4816, February 2007. 575 [RFC4842] Malis, A., Pate, P., Cohen, R., and D. Zelig, "Synchronous 576 Optical Network/Synchronous Digital Hierarchy (SONET/SDH) 577 Circuit Emulation over Packet (CEP)", RFC 4842, 578 April 2007. 580 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 581 "Extensions to Resource Reservation Protocol - Traffic 582 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 583 Switched Paths (LSPs)", RFC 4875, May 2007. 585 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 586 Label Assignment and Context-Specific Label Space", 587 RFC 5331, August 2008. 589 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 590 Multicast Encapsulations", RFC 5332, August 2008. 592 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 593 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 594 Class" Field", RFC 5462, February 2009. 596 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 597 Associated Channel", RFC 5586, June 2009. 599 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 600 and S. Ueno, "Requirements of an MPLS Transport Profile", 601 RFC 5654, September 2009. 603 8.2. Informative References 605 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] 606 Fang, L. and M. Behringer, "Security Framework for MPLS 607 and GMPLS Networks", 608 draft-ietf-mpls-mpls-and-gmpls-security-framework-09 (work 609 in progress), March 2010. 611 [I-D.ietf-mpls-tp-framework] 612 Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 613 Berger, "A Framework for MPLS in Transport Networks", 614 draft-ietf-mpls-tp-framework-12 (work in progress), 615 May 2010. 617 [I-D.ietf-pwe3-fc-encap] 618 Black, D. and L. Dunbar, "Encapsulation Methods for 619 Transport of Fibre Channel frames Over MPLS Networks", 620 draft-ietf-pwe3-fc-encap-11 (work in progress), June 2010. 622 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 623 Edge (PWE3) Architecture", RFC 3985, March 2005. 625 [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. 626 Pate, "Structure-Aware Time Division Multiplexed (TDM) 627 Circuit Emulation Service over Packet Switched Network 628 (CESoPSN)", RFC 5086, December 2007. 630 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 631 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 632 December 2007. 634 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 635 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 636 October 2009. 638 Authors' Addresses 640 Dan Frost (editor) 641 Cisco Systems 643 Email: danfrost@cisco.com 644 Stewart Bryant (editor) 645 Cisco Systems 647 Email: stbryant@cisco.com 649 Matthew Bocci (editor) 650 Alcatel-Lucent 652 Email: matthew.bocci@alcatel-lucent.com