idnits 2.17.1 draft-ietf-mpls-tp-data-plane-03.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 (May 12, 2010) is 5088 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-10 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: November 13, 2010 M. Bocci, Ed. 6 Alcatel-Lucent 7 May 12, 2010 9 MPLS Transport Profile Data Plane Architecture 10 draft-ietf-mpls-tp-data-plane-03 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 November 13, 2010. 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 . . . . . . . . . . . . . . 9 79 5. Server Layer Considerations . . . . . . . . . . . . . . . . . 10 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The MPLS Transport Profile (MPLS-TP) [I-D.ietf-mpls-tp-framework] is 90 the set of functions that meet the requirements [RFC5654] for the 91 application of MPLS to the construction and operation of packet- 92 switched transport networks. MPLS-based packet transport networks 93 are defined and described in [I-D.ietf-mpls-tp-framework]. 95 This document defines the set of functions that comprise the MPLS-TP 96 data plane: the architectural layer concerned with the encapsulation 97 and forwarding of packets within an MPLS-TP network. This layer is 98 based on the data plane architectures for MPLS ([RFC3031] and 99 [RFC3032]) and for pseudowires ([RFC3985]). 101 This document is a product of a joint Internet Engineering Task Force 102 (IETF) / International Telecommunication Union Telecommunication 103 Standardization Sector (ITU-T) effort to include an MPLS Transport 104 Profile within the IETF MPLS and PWE3 architectures to support the 105 capabilities and functionalities of a packet transport network. 107 1.1. Scope 109 This document has the following purposes: 111 o To identify the data plane functions within the MPLS Transport 112 Profile; 114 o To indicate which of these data plane functions an MPLS-TP 115 implementation is required to support. 117 This document defines the encapsulation and forwarding functions 118 applicable to packets traversing an MPLS-TP Label Switched Path 119 (LSP), Pseudowire (PW), or Section (see Section 3 for the definitions 120 of these transport entities). Encapsulation and forwarding functions 121 for packets outside an MPLS-TP LSP, PW, or Section, and mechanisms 122 for delivering packets to or from MPLS-TP LSPs, PWs, and Sections, 123 are outside the scope of this document. 125 1.2. Terminology 127 Term Definition 128 ------- ------------------------------------------ 129 ACH Associated Channel Header 130 G-ACh Generic Associated Channel 131 GAL G-ACh Label 132 LER Label Edge Router 133 LSE Label Stack Entry 134 LSP Label Switched Path 135 LSR Label Switching Router 136 MPLS-TP MPLS Transport Profile 137 OAM Operations, Administration and Maintenance 138 PW Pseudowire 139 QoS Quality of Service 140 S-PE PW Switching Provider Edge Node 141 T-PE PW Terminating Provider Edge Node 142 TTL Time To Live 144 Additional definitions and terminology can be found in 145 [I-D.ietf-mpls-tp-framework] and [RFC5654]. 147 2. MPLS-TP Packet Encapsulation and Forwarding 149 MPLS-TP packet encapsulation and forwarding SHALL operate according 150 to the MPLS data plane architecture described in [RFC3031] and 151 [RFC3032], and the data plane architectures for Single-Segment 152 Pseudowires and Multi-Segment Pseudowires (see Section 3.3), except 153 as noted otherwise in this document. The MPLS-TP data plane 154 satisfies the requirements specified in [RFC5654]. 156 Since an MPLS-TP packet is an MPLS packet as defined in [RFC3031] and 157 [RFC3032], it will have an associated label stack, and the 'push', 158 'pop', and 'swap' label processing operations specified in those 159 documents apply. The label stack represents a hierarchy of Label 160 Switched Paths (LSPs). A label is pushed to introduce an additional 161 level of LSP hierarchy and popped to remove it. Such an additional 162 level may be introduced by any pair of LSRs, whereupon they become 163 adjacent at this new level, and are then known as Label Edge Routers 164 (LERs) with respect to the new LSP. 166 In contrast to, for example, Section 3.10 of [RFC3031], support for 167 Internet Protocol (IP) host and router data plane functionality by 168 MPLS-TP interfaces and in MPLS-TP networks is OPTIONAL. 170 MPLS-TP forwarding is based on the label that identifies an LSP or 171 PW. The label value specifies the processing operation to be 172 performed by the next hop at that level of encapsulation. Note that 173 a swap of this label is an atomic operation in which the contents of 174 the packet after the swapped label are opaque to the forwarding 175 function. The only event that interrupts a swap operation is Time To 176 Live (TTL) expiry. 178 At an LSR, S-PE, or T-PE, further processing occurs to determine the 179 context of a packet occurs when a swap operation is interrupted by 180 TTL expiry. If the TTL of an LSP label expires, then the label with 181 the S (Bottom of Stack) bit set is inspected to determine if it is a 182 reserved label. If it is a reserved label, the packet is processed 183 according to the rules of that reserved label. For example, if it is 184 a Generic Associated Channel Label (GAL), then it is processed as a 185 packet on the G-ACh; see Section 4. If the TTL of a PW expires at an 186 S-PE or T-PE, then the packet is examined to determine if a Generic 187 Associated Channel Header (ACH) is present immediately below the PW 188 label. If so, then the packet is processed as a packet on the G-ACh. 190 Similarly, if a pop operation at an LER exposes a reserved label at 191 the top of the label stack, then the packet is processed according to 192 the rules of that reserved label. 194 If no such exception occurs, the packet is forwarded according to the 195 procedures in [RFC3031] and [RFC3032]. 197 3. MPLS-TP Transport Entities 199 The MPLS Transport Profile includes the following data plane 200 transport entities: 202 o Label Switched Paths (LSPs) 204 o Sections 206 o Pseudowires (PWs) 208 3.1. Label Switched Paths 210 MPLS-TP LSPs are ordinary MPLS LSPs as defined in [RFC3031] except as 211 specifically noted otherwise in this document. 213 3.1.1. LSP Packet Encapsulation and Forwarding 215 Encapsulation and forwarding of packets traversing MPLS-TP LSPs MUST 216 follow standard MPLS packet encapsulation and forwarding as defined 217 in [RFC3031], [RFC3032], [RFC5331], and [RFC5332], except as 218 explicitly stated otherwise in this document. 220 Data plane Quality of Service capabilities are included in the 221 MPLS-TP in the form of Traffic Engineered (TE) LSPs [RFC3209] and the 222 MPLS Differentiated Services (DiffServ) architecture [RFC3270]. Both 223 E-LSP and L-LSP MPLS DiffServ modes are included. The Traffic Class 224 field (formerly the EXP field) of an MPLS label follows the 225 definition of [RFC5462] and [RFC3270] and MUST be processed according 226 to the rules specified in those documents. 228 Note that, except for transient packet reordering which may occur, 229 for example, during fault conditions, packets are delivered in order 230 on L-LSPs, and on E-LSPs within a specific ordered aggregate. 232 The Uniform, Pipe and Short Pipe DiffServ tunneling and TTL 233 processing models described in [RFC3270] and [RFC3443] MAY be used 234 for MPLS-TP LSPs. Note however that support for the Pipe or Short 235 Pipe models is REQUIRED for typical transport applications, in which 236 the topology and QoS characteristics of the MPLS-TP server layer are 237 independent of the client layer. Specific applications MAY place 238 further requirements on the DiffServ tunneling and TTL processing 239 models an LSP can use. 241 Per-platform, per-interface or other context-specific label space 242 [RFC5331] MAY be used for MPLS-TP LSPs. Downstream [RFC3031] or 243 upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP 244 LSPs. Note that the requirements of a particular LSP type may 245 dictate which label spaces or allocation schemes it can use. 247 Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on 248 an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate 249 over a server layer that supports load-balancing, but this load- 250 balancing MUST operate in such a manner that it is transparent to 251 MPLS-TP. Note that this does not preclude the future definition of 252 new MPLS-TP LSP types which have different requirements regarding the 253 use of ECMP in the server layer. 255 Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP 256 LSPs. 258 3.1.2. LSP Payloads 260 The MPLS-TP includes support for the following LSP payload types: 262 o Network-layer protocol packets (including MPLS-labeled packets) 264 o Pseudowire packets 266 The rules for processing LSP payloads that are network-layer protocol 267 packets SHALL be as specified in [RFC3032]. 269 The rules for processing LSP payloads that are pseudowire packets 270 SHALL be as defined in the data plane pseudowire specifications (see 271 Section 3.3). 273 Note that the payload of an MPLS-TP LSP may be a packet that itself 274 contains an MPLS label stack. This is true, for instance, when the 275 payload is a pseudowire or an MPLS LSP. In such cases, the label 276 stack is contiguous between the MPLS-TP LSP and its payload, and 277 exactly one LSE in this stack SHALL have the S (Bottom of Stack) bit 278 set to 1. This behaviour reflects best current practice in MPLS but 279 differs slightly from [RFC3032], which uses the S bit to identify 280 when MPLS label processing stops and network layer processing starts. 282 3.1.3. LSP Types 284 The MPLS-TP includes the following LSP types: 286 o Point-to-point unidirectional 288 o Point-to-point associated bidirectional 290 o Point-to-point co-routed bidirectional 292 o Point-to-multipoint unidirectional 294 Point-to-point unidirectional LSPs are supported by the basic MPLS 295 architecture [RFC3031] and are REQUIRED to function in the same 296 manner in the MPLS-TP data plane except as explicitly stated 297 otherwise in this document. 299 A point-to-point associated bidirectional LSP between LSRs A and B 300 consists of two unidirectional point-to-point LSPs, one from A to B 301 and the other from B to A, which are regarded as a pair providing a 302 single logical bidirectional transport path. 304 A point-to-point co-routed bidirectional LSP is a point-to-point 305 associated bidirectional LSP with the additional constraint that its 306 two unidirectional component LSPs in each direction follow the same 307 path (in terms of both nodes and links). An important property of 308 co-routed bidirectional LSPs is that their unidirectional component 309 LSPs share fate. 311 A point-to-multipoint unidirectional LSP functions in the same manner 312 in the data plane, with respect to basic label processing and packet- 313 switching operations, as a point-to-point unidirectional LSP, with 314 one difference: an LSR may have more than one (egress interface, 315 outgoing label) pair associated with the LSP, and any packet it 316 transmits on the LSP is transmitted out all associated egress 317 interfaces. Point-to-multipoint LSPs are described in [RFC4875] and 318 [RFC5332]. TTL processing and exception handling for point-to- 319 multipoint LSPs is the same as for point-to-point LSPs and is 320 described in Section 2. 322 3.2. Sections 324 Two MPLS-TP LSRs are considered to be topologically adjacent at a 325 particular layer n >= 0 of the MPLS-TP LSP hierarchy if there exists 326 connectivity between them at the next lowest network layer, and if 327 there is no MPLS layer processing at layer n between the two LSRs 328 (other than at the LSRs themselves). Such connectivity, if it 329 exists, will be either an MPLS-TP LSP (if n > 0) or a data-link 330 provided by the underlying server layer network (if n = 0), and is 331 referred to as an MPLS-TP Section at layer n of the MPLS-TP LSP 332 hierarchy. Thus, the links traversed by a layer n+1 MPLS-TP LSP are 333 layer n MPLS-TP sections. Such an LSP is referred to as a client of 334 the section layer, and the section layer as the server layer with 335 respect to its clients. 337 Note that the MPLS label stack associated with an MPLS-TP section at 338 layer n consists of n labels, in the absence of stack optimisation 339 mechanisms. Note also that in order for two LSRs to exchange non-IP 340 MPLS-TP control packets over a section, an additional label, the 341 G-ACh Label (GAL) (see Section 4) MUST appear at the bottom of the 342 label stack. 344 An MPLS-TP section may provide one or more of the following types of 345 service to its client layer: 347 o Point-to-point bidirectional 349 o Point-to-point unidirectional 351 o Point-to-multipoint unidirectional 353 The manner in which a section provides such a service is outside the 354 scope of the MPLS-TP. 356 Note that an LSP of any of the types listed in Section 3.1.3 may 357 serve as a section for a client-layer transport entity as long as it 358 supports the type of service the client requires. 360 A section MUST provide a means of identifying the type of payload it 361 carries. If the section is a data-link, link-specific mechanisms 362 such as a protocol type indication in the data-link header MAY be 363 used. If the section is an LSP, this information MAY be implied by 364 the LSP label or, if the LSP payload is MPLS-labeled, by the setting 365 of the S bit. Additional labels MAY also be used if necessary to 366 distinguish different payload types; see [I-D.ietf-mpls-tp-framework] 367 for examples and further discussion. 369 3.3. Pseudowires 371 The data plane architectures for Single-Segment Pseudowires [RFC3985] 372 and Multi-Segment Pseudowires [RFC5659] are included in the MPLS-TP. 374 Data plane processing procedures for pseudowires SHALL be as defined 375 in the following documents and in any future pseudowire data plane 376 specifications: 378 o [RFC4717] 380 o [RFC4816] 382 o [RFC4385] 384 o [RFC4448] 386 o [RFC4619] 388 o [RFC4618] 390 o [RFC4553] 392 o [RFC4842] 394 o [RFC5087] 396 o [I-D.ietf-pwe3-fc-encap] 398 o [RFC5086] 400 This document specifies no modifications or extensions to pseudowire 401 data plane architectures or protocols. 403 4. MPLS-TP Generic Associated Channel 405 The MPLS Generic Associated Channel (G-ACh) mechanism is specified in 406 [RFC5586] and included in the MPLS-TP. The G-ACh provides an 407 auxiliary logical data channel associated with MPLS-TP Sections, 408 LSPs, and PWs in the data plane. The primary purpose of the G-ACh in 409 the context of MPLS-TP is to support control, management, and 410 Operations, Administration and Maintenance (OAM) traffic associated 411 with MPLS-TP transport entities. The G-ACh MUST NOT be used to 412 transport client layer network traffic in MPLS-TP networks. 414 For pseudowires, the G-ACh uses the first four bits of the PW control 415 word to provide the initial discrimination between data packets and 416 packets belonging to the associated channel, as described in 417 [RFC4385]. When this first nibble of a packet, immediately following 418 the label at the bottom of stack, has a value of '1', then this 419 packet belongs to a G-ACh. The first 32 bits following the bottom of 420 stack label then have a defined format called an Associated Channel 421 Header (ACH), which further defines the content of the packet. The 422 ACH is therefore both a demultiplexer for G-ACh traffic on the PW, 423 and a discriminator for the type of G-ACh traffic. 425 When the the control message is carried over a section or an LSP, 426 rather than over a PW, it is necessary to provide an indication in 427 the packet that the payload is something other than a client data 428 packet. This is achieved by including a reserved label with a value 429 of 13 at the bottom of the label stack. This reserved label is 430 referred to as the G-ACh Label (GAL), and is defined in [RFC5586]. 431 When a GAL is found, it indicates that the payload begins with an 432 ACH. The GAL is thus a demultiplexer for G-ACh traffic on the 433 section or the LSP, and the ACH is a discriminator for the type of 434 traffic carried on the G-ACh. Note however that MPLS-TP forwarding 435 follows the normal MPLS model, and that a GAL is invisible to an LSR 436 unless it is the top label in the label stack. The only other 437 circumstance under which the label stack may be inspected for a GAL 438 is when the TTL has expired. Note that normal packet forwarding MAY 439 continue concurrently with this inspection. All operations on the 440 label stack are in accordance with [RFC3031] and [RFC3032]. 442 An application processing a packet received over the G-ACh may 443 require packet-specific context (such as the receiving interface or 444 received label stack). Data plane implementations MUST therefore 445 provide adequate context to the application which is to process a 446 G-ACh packet. The definition of the context required MUST be 447 provided as part of the specification of the application using the 448 G-ACh. 450 5. Server Layer Considerations 452 The MPLS-TP network has no awareness of the internals of the server 453 layer of which it is a client, requiring only that the server layer 454 be capable of delivering the type of service required by the MPLS-TP 455 transport entities that make use of it. Note that what appears to be 456 a single server layer link to the MPLS-TP network may be a 457 complicated construct underneath, such as an LSP or a collection of 458 underlying links operating as a bundle. Special care may be needed 459 in network design and operation when such constructs are used as a 460 server layer for MPLS-TP. 462 Encapsulation of MPLS-TP packets for transport over specific server- 463 layer media is outside the scope of this document. 465 6. Security Considerations 467 The MPLS data plane (and therefore the MPLS-TP data plane) does not 468 provide any security mechanisms in and of itself. Client layers that 469 wish to secure data carried over MPLS-TP transport entities are 470 REQUIRED to apply their own security mechanisms. 472 Where management or control plane protocols are used to install label 473 switching operations necessary to establish MPLS-TP transport paths, 474 those protocols are equipped with security features and network 475 operators may use those features to securely create the transport 476 paths. 478 Where enhanced security is desirable, and a trust relationship exists 479 between an LSR and its peer, the LSR MAY choose to discard a packet 480 received from a particular neighbour unless one of the following two 481 conditions holds: 483 1. Any MPLS label processed at the receiving LSR, such as an LSP or 484 PW label, has a label value that the receiving LSR has 485 distributed to that neighbour; or 487 2. Any MPLS label processed at the receiving LSR, such as an LSP or 488 PW label, has a label value that the receiving LSR has previously 489 distributed to the peer beyond that neighbour (i.e., when it is 490 known that the path from the system to which the label was 491 distributed to the receiving system is via that neighbour). 493 Further details of MPLS and MPLS-TP security can be found in 494 [I-D.ietf-mpls-tp-framework] and 495 [I-D.ietf-mpls-mpls-and-gmpls-security-framework]. 497 7. IANA Considerations 499 This document introduces no new IANA considerations. 501 8. References 502 8.1. Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 508 Label Switching Architecture", RFC 3031, January 2001. 510 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 511 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 512 Encoding", RFC 3032, January 2001. 514 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 515 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 516 Tunnels", RFC 3209, December 2001. 518 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 519 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 520 Protocol Label Switching (MPLS) Support of Differentiated 521 Services", RFC 3270, May 2002. 523 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 524 in Multi-Protocol Label Switching (MPLS) Networks", 525 RFC 3443, January 2003. 527 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 528 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 529 Use over an MPLS PSN", RFC 4385, February 2006. 531 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 532 "Encapsulation Methods for Transport of Ethernet over MPLS 533 Networks", RFC 4448, April 2006. 535 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 536 Division Multiplexing (TDM) over Packet (SAToP)", 537 RFC 4553, June 2006. 539 [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, 540 "Encapsulation Methods for Transport of PPP/High-Level 541 Data Link Control (HDLC) over MPLS Networks", RFC 4618, 542 September 2006. 544 [RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation 545 Methods for Transport of Frame Relay over Multiprotocol 546 Label Switching (MPLS) Networks", RFC 4619, 547 September 2006. 549 [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., 550 Brayley, J., and G. Koleyni, "Encapsulation Methods for 551 Transport of Asynchronous Transfer Mode (ATM) over MPLS 552 Networks", RFC 4717, December 2006. 554 [RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, 555 "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous 556 Transfer Mode (ATM) Transparent Cell Transport Service", 557 RFC 4816, February 2007. 559 [RFC4842] Malis, A., Pate, P., Cohen, R., and D. Zelig, "Synchronous 560 Optical Network/Synchronous Digital Hierarchy (SONET/SDH) 561 Circuit Emulation over Packet (CEP)", RFC 4842, 562 April 2007. 564 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 565 "Extensions to Resource Reservation Protocol - Traffic 566 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 567 Switched Paths (LSPs)", RFC 4875, May 2007. 569 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 570 Label Assignment and Context-Specific Label Space", 571 RFC 5331, August 2008. 573 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 574 Multicast Encapsulations", RFC 5332, August 2008. 576 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 577 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 578 Class" Field", RFC 5462, February 2009. 580 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 581 Associated Channel", RFC 5586, June 2009. 583 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 584 and S. Ueno, "Requirements of an MPLS Transport Profile", 585 RFC 5654, September 2009. 587 8.2. Informative References 589 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] 590 Fang, L. and M. Behringer, "Security Framework for MPLS 591 and GMPLS Networks", 592 draft-ietf-mpls-mpls-and-gmpls-security-framework-09 (work 593 in progress), March 2010. 595 [I-D.ietf-mpls-tp-framework] 596 Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 597 Berger, "A Framework for MPLS in Transport Networks", 598 draft-ietf-mpls-tp-framework-12 (work in progress), 599 May 2010. 601 [I-D.ietf-pwe3-fc-encap] 602 Black, D., Roth, M., Tsurusawa, M., Solomon, R., and L. 603 Dunbar, "Encapsulation Methods for Transport of Fibre 604 Channel frames Over MPLS Networks", 605 draft-ietf-pwe3-fc-encap-10 (work in progress), 606 February 2010. 608 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 609 Edge (PWE3) Architecture", RFC 3985, March 2005. 611 [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. 612 Pate, "Structure-Aware Time Division Multiplexed (TDM) 613 Circuit Emulation Service over Packet Switched Network 614 (CESoPSN)", RFC 5086, December 2007. 616 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 617 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 618 December 2007. 620 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 621 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 622 October 2009. 624 Authors' Addresses 626 Dan Frost (editor) 627 Cisco Systems 629 Email: danfrost@cisco.com 631 Stewart Bryant (editor) 632 Cisco Systems 634 Email: stbryant@cisco.com 636 Matthew Bocci (editor) 637 Alcatel-Lucent 639 Email: matthew.bocci@alcatel-lucent.com