diff options
Diffstat (limited to 'doc/rfc/rfc5960.txt')
| -rw-r--r-- | doc/rfc/rfc5960.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5960.txt b/doc/rfc/rfc5960.txt new file mode 100644 index 0000000..7770b7d --- /dev/null +++ b/doc/rfc/rfc5960.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Frost, Ed. +Request for Comments: 5960 S. Bryant, Ed. +Category: Standards Track Cisco Systems +ISSN: 2070-1721 M. Bocci, Ed. + Alcatel-Lucent + August 2010 + + + MPLS Transport Profile Data Plane Architecture + +Abstract + + The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the + set of MPLS protocol functions applicable to the construction and + operation of packet-switched transport networks. This document + specifies the subset of these functions that comprises the MPLS-TP + data plane: the architectural layer concerned with the encapsulation + and forwarding of packets within an MPLS-TP network. + + This document is a product of a joint Internet Engineering Task Force + (IETF) / International Telecommunication Union Telecommunication + Standardization Sector (ITU-T) effort to include an MPLS Transport + Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge + (PWE3) architectures to support the capabilities and functionalities + of a packet transport network. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5960. + + + + + + + + + + + + +Frost, et al. Standards Track [Page 1] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. MPLS-TP Packet Encapsulation and Forwarding . . . . . . . . . 4 + 3. MPLS-TP Transport Entities . . . . . . . . . . . . . . . . . . 5 + 3.1. Label Switched Paths . . . . . . . . . . . . . . . . . . . 5 + 3.1.1. LSP Packet Encapsulation and Forwarding . . . . . . . 6 + 3.1.2. LSP Payloads . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.3. LSP Types . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. MPLS-TP Generic Associated Channel . . . . . . . . . . . . . . 10 + 5. Server-Layer Considerations . . . . . . . . . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + +Frost, et al. Standards Track [Page 2] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + +1. Introduction + + The MPLS Transport Profile (MPLS-TP) is the set of functions that + meet the requirements [RFC5654] for the application of MPLS to the + construction and operation of packet-switched transport networks. + MPLS-based packet-switched transport networks, and the overall + architecture of the MPLS-TP, are defined and described in [RFC5921]. + It is assumed that the reader is familiar with that document. + + This document defines the set of functions that comprise the MPLS-TP + data plane: the architectural layer concerned with the encapsulation + and forwarding of packets within an MPLS-TP network. This layer is + based on the data plane architectures for MPLS ([RFC3031] and + [RFC3032]) and for pseudowires [RFC3985]. + + This document is a product of a joint Internet Engineering Task Force + (IETF) / International Telecommunication Union Telecommunication + Standardization Sector (ITU-T) effort to include an MPLS Transport + Profile within the IETF MPLS and PWE3 architectures to support the + capabilities and functionalities of a packet transport network. + +1.1. Scope + + This document has the following purposes: + + o To identify the data plane functions within the MPLS Transport + Profile; and + + o To indicate which of these data plane functions an MPLS-TP + implementation is required to support. + + This document defines the encapsulation and forwarding functions + applicable to packets traversing an MPLS-TP Label Switched Path + (LSP), pseudowire (PW), or section (see Section 3 for the definitions + of these transport entities). Encapsulation and forwarding functions + for packets outside an MPLS-TP LSP, PW, or section, and mechanisms + for delivering packets to or from MPLS-TP LSPs, PWs, and sections, + are outside the scope of this document. + + + + + + + + + + + + + +Frost, et al. Standards Track [Page 3] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + +1.2. Terminology + + Term Definition + ------- ------------------------------------------- + ACH Associated Channel Header + G-ACh Generic Associated Channel + GAL G-ACh Label + LER Label Edge Router + LSE Label Stack Entry + LSP Label Switched Path + LSR Label Switching Router + MPLS-TP MPLS Transport Profile + OAM Operations, Administration, and Maintenance + PW Pseudowire + QoS Quality of Service + S-PE PW Switching Provider Edge + T-PE PW Terminating Provider Edge + TTL Time To Live + + Additional definitions and terminology can be found in [RFC5921] and + [RFC5654]. + +1.3. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. MPLS-TP Packet Encapsulation and Forwarding + + MPLS-TP packet encapsulation and forwarding SHALL operate according + to the MPLS data plane architecture described in [RFC3031] and + [RFC3032] and to the data plane architectures for single-segment + pseudowires and multi-segment pseudowires (see Section 3.3), except + as noted otherwise in this document. The MPLS-TP data plane + satisfies the requirements specified in [RFC5654]. + + Since an MPLS-TP packet is an MPLS packet as defined in [RFC3031] and + [RFC3032], it will have an associated label stack, and the 'push', + 'pop', and 'swap' label processing operations specified in those + documents apply. The label stack represents a hierarchy of Label + Switched Paths (LSPs). A label is pushed to introduce an additional + level of LSP hierarchy and popped to remove it. Such an additional + level may be introduced by any pair of LSRs, whereupon they become + adjacent at this new level, and are then known as Label Edge Routers + (LERs) with respect to the new LSP. + + + + + +Frost, et al. Standards Track [Page 4] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + In contrast to, for example, Section 3.10 of [RFC3031], support for + Internet Protocol (IP) host and router data plane functionality by + MPLS-TP interfaces and in MPLS-TP networks is OPTIONAL. + + MPLS-TP forwarding is based on the label that identifies an LSP or + PW. The label value specifies the processing operation to be + performed by the next hop at that level of encapsulation. A swap of + this label is an atomic operation in which the contents of the packet + (after the swapped label) are opaque to the forwarding function. The + only event that interrupts a swap operation is Time To Live (TTL) + expiry. + + At an LSR, S-PE, or T-PE, further processing to determine the context + of a packet occurs when a swap operation is interrupted by TTL + expiry. If the TTL of an LSP label expires, then the label with the + S (Bottom of Stack) bit set is inspected to determine if it is a + reserved label. If it is a reserved label, the packet is processed + according to the rules of that reserved label. For example, if it is + a Generic Associated Channel Label (GAL), then it is processed as a + packet on the Generic Associated Channel (G-ACh); see Section 4. If + the TTL of a PW expires at an S-PE or T-PE, then the packet is + examined to determine if a Generic Associated Channel Header (ACH) is + present immediately below the PW label. If so, then the packet is + processed as a packet on the G-ACh. + + Similarly, if a pop operation at an LER exposes a reserved label at + the top of the label stack, then the packet is processed according to + the rules of that reserved label. + + If no such exception occurs, the packet is forwarded according to the + procedures in [RFC3031] and [RFC3032]. + +3. MPLS-TP Transport Entities + + The MPLS Transport Profile includes the following data plane + transport entities: + + o Label Switched Paths (LSPs) + + o sections + + o pseudowires (PWs) + +3.1. Label Switched Paths + + MPLS-TP LSPs are ordinary MPLS LSPs as defined in [RFC3031], except + as specifically noted otherwise in this document. + + + + +Frost, et al. Standards Track [Page 5] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + +3.1.1. LSP Packet Encapsulation and Forwarding + + Encapsulation and forwarding of packets traversing MPLS-TP LSPs MUST + follow standard MPLS packet encapsulation and forwarding as defined + in [RFC3031], [RFC3032], [RFC5331], and [RFC5332], except as + explicitly stated otherwise in this document. + + Data plane Quality of Service capabilities are included in the + MPLS-TP in the form of Traffic Engineered (TE) LSPs [RFC3209] and the + MPLS Differentiated Services (Diffserv) architecture [RFC3270]. Both + E-LSP and L-LSP MPLS Diffserv modes are included. The Traffic Class + field (formerly the EXP field) of an MPLS label follows the + definition of [RFC5462] and [RFC3270] and MUST be processed according + to the rules specified in those documents. + + Except for transient packet reordering that may occur, for example, + during fault conditions, packets are delivered in order on L-LSPs, + and on E-LSPs within a specific ordered aggregate. + + The Uniform, Pipe, and Short Pipe Diffserv tunneling and TTL + processing models described in [RFC3270] and [RFC3443] MAY be used + for MPLS-TP LSPs. Note, however, that support for the Pipe or Short + Pipe models is REQUIRED for typical transport applications in which + the topology and QoS characteristics of the MPLS-TP server layer are + independent of the client layer. Specific applications MAY place + further requirements on the Diffserv tunneling and TTL processing + models an LSP can use. + + Per-platform, per-interface, or other context-specific label space + [RFC5331] MAY be used for MPLS-TP LSPs. Downstream [RFC3031] or + upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP + LSPs. The requirements of a particular LSP type may, however, + dictate which label spaces or allocation schemes LSPs of that type + can use. + + Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on + an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate + over a server layer that supports load-balancing, but this load- + balancing MUST operate in such a manner that it is transparent to + MPLS-TP. This does not preclude the future definition of new MPLS-TP + LSP types that have different requirements regarding the use of ECMP + in the server layer. + + Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP + LSPs. + + + + + + +Frost, et al. Standards Track [Page 6] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + +3.1.2. LSP Payloads + + The MPLS-TP includes support for the following LSP payload types: + + o Network-layer protocol packets (including MPLS-labeled packets) + + o Pseudowire packets + + The rules for processing LSP payloads that are network-layer protocol + packets SHALL be as specified in [RFC3032]. + + The rules for processing LSP payloads that are pseudowire packets + SHALL be as defined in the data plane pseudowire specifications (see + Section 3.3). + + The payload of an MPLS-TP LSP may be a packet that itself contains an + MPLS label stack. This is true, for instance, when the payload is a + pseudowire or an MPLS LSP. In such cases, the label stack is + contiguous between the MPLS-TP LSP and its payload, and exactly one + LSE in this stack SHALL have the S (Bottom of Stack) bit set to 1. + This behavior reflects best current practice in MPLS but differs + slightly from [RFC3032], which uses the S bit to identify when MPLS + label processing stops and network-layer processing starts. + +3.1.3. LSP Types + + The MPLS-TP includes the following LSP types: + + o Point-to-point unidirectional + + o Point-to-point associated bidirectional + + o Point-to-point co-routed bidirectional + + o Point-to-multipoint unidirectional + + Point-to-point unidirectional LSPs are supported by the basic MPLS + architecture [RFC3031] and are REQUIRED to function in the same + manner in the MPLS-TP data plane, except as explicitly stated + otherwise in this document. + + A point-to-point associated bidirectional LSP between LSRs A and B + consists of two unidirectional point-to-point LSPs, one from A to B + and the other from B to A, which are regarded as a pair providing a + single logical bidirectional transport path. + + + + + + +Frost, et al. Standards Track [Page 7] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + A point-to-point co-routed bidirectional LSP is a point-to-point + associated bidirectional LSP with the additional constraint that its + two unidirectional component LSPs in each direction follow the same + path (in terms of both nodes and links). An important property of + co-routed bidirectional LSPs is that their unidirectional component + LSPs share fate. + + A point-to-multipoint unidirectional LSP functions in the same manner + in the data plane, with respect to basic label processing and packet- + switching operations, as a point-to-point unidirectional LSP, with + one difference: an LSR may have more than one (egress interface, + outgoing label) pair associated with the LSP, and any packet it + transmits on the LSP is transmitted out all associated egress + interfaces. Point-to-multipoint LSPs are described in [RFC4875] and + [RFC5332]. TTL processing and exception handling for point-to- + multipoint LSPs is the same as for point-to-point LSPs and is + described in Section 2. + +3.2. Sections + + Two MPLS-TP LSRs are considered to be topologically adjacent at a + particular layer n >= 0 of the MPLS-TP LSP hierarchy if there exists + connectivity between them at the next lowest network layer, and if + there is no MPLS layer processing at layer n between the two LSRs + (other than at the LSRs themselves). Such connectivity, if it + exists, will be either an MPLS-TP LSP (if n > 0) or a data-link + provided by the underlying server layer network (if n = 0), and is + referred to as an MPLS-TP section at layer n of the MPLS-TP LSP + hierarchy. Thus, the links traversed by a layer n+1 MPLS-TP LSP are + layer n MPLS-TP sections. Such an LSP is referred to as a client of + the section layer, and the section layer is referred to as the server + layer with respect to its clients. + + The MPLS label stack associated with an MPLS-TP section at layer n + consists of n labels, in the absence of stack optimization + mechanisms. In order for two LSRs to exchange non-IP MPLS-TP control + packets over a section, an additional label, the G-ACh Label (GAL) + (see Section 4) MUST appear at the bottom of the label stack. + + An MPLS-TP section may provide one or more of the following types of + service to its client layer: + + o Point-to-point bidirectional + + o Point-to-point unidirectional + + o Point-to-multipoint unidirectional + + + + +Frost, et al. Standards Track [Page 8] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + The manner in which a section provides such a service is outside the + scope of the MPLS-TP. + + An LSP of any of the types listed in Section 3.1.3 may serve as a + section for a client-layer transport entity as long as it supports + the type of service the client requires. + + A section MUST provide a means of identifying the type of payload it + carries. If the section is a data-link, link-specific mechanisms + such as a protocol type indication in the data-link header MAY be + used. If the section is an LSP, this information MAY be implied by + the LSP label or, if the LSP payload is MPLS-labeled, by the setting + of the S bit. Additional labels MAY also be used if necessary to + distinguish different payload types; see [RFC5921] for examples and + further discussion. + +3.3. Pseudowires + + The data plane architectures for single-segment pseudowires [RFC3985] + and multi-segment pseudowires [RFC5659] are included in the MPLS-TP. + + Data plane processing procedures for pseudowires are defined and + described in a number of IETF documents. Some example pseudowire + data plane procedures include: + + o Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over + an MPLS PSN [RFC4385] + + o Encapsulation Methods for Transport of Ethernet over MPLS Networks + [RFC4448] + + o Structure-Agnostic Time Division Multiplexing (TDM) over Packet + (SAToP) [RFC4553] + + o Encapsulation Methods for Transport of PPP/High-Level Data Link + Control (HDLC) over MPLS Networks [RFC4618] + + o Encapsulation Methods for Transport of Frame Relay over + Multiprotocol Label Switching (MPLS) Networks [RFC4619] + + o Encapsulation Methods for Transport of Asynchronous Transfer Mode + (ATM) over MPLS Networks [RFC4717] + + o Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer + Mode (ATM) Transparent Cell Transport Service [RFC4816] + + o Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/ + SDH) Circuit Emulation over Packet (CEP) [RFC4842] + + + +Frost, et al. Standards Track [Page 9] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + o Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation + Service over Packet Switched Network (CESoPSN) [RFC5086] + + o Time Division Multiplexing over IP (TDMoIP) [RFC5087] + + o Encapsulation Methods for Transport of Fibre Channel frames Over + MPLS Networks [FC-ENCAP] + + This document specifies no modifications or extensions to pseudowire + data plane architectures or protocols. + +4. MPLS-TP Generic Associated Channel + + The MPLS Generic Associated Channel (G-ACh) mechanism is specified in + [RFC5586] and included in the MPLS-TP. The G-ACh provides an + auxiliary logical data channel associated with MPLS-TP sections, + LSPs, and PWs in the data plane. The primary purpose of the G-ACh in + the context of MPLS-TP is to support control, management, and + Operations, Administration, and Maintenance (OAM) traffic associated + with MPLS-TP transport entities. The G-ACh MUST NOT be used to + transport client layer network traffic in MPLS-TP networks. + + For pseudowires, the G-ACh uses the first four bits of the PW control + word to provide the initial discrimination between data packets and + packets belonging to the associated channel, as described in + [RFC4385]. When this first nibble of a packet, immediately following + the label at the bottom of stack, has a value of '1', then this + packet belongs to a G-ACh. The first 32 bits following the bottom of + stack label then have a defined format called an Associated Channel + Header (ACH), which further defines the content of the packet. The + ACH is therefore both a demultiplexer for G-ACh traffic on the PW, + and a discriminator for the type of G-ACh traffic. + + When the control message is carried over a section or an LSP, rather + than over a PW, it is necessary to provide an indication in the + packet that the payload is something other than a client data packet. + This is achieved by including a reserved label with a value of 13 at + the bottom of the label stack. This reserved label is referred to as + the G-ACh Label (GAL) and is defined in [RFC5586]. When a GAL is + found, it indicates that the payload begins with an ACH. The GAL is + thus a demultiplexer for G-ACh traffic on the section or the LSP, and + the ACH is a discriminator for the type of traffic carried on the + G-ACh. MPLS-TP forwarding follows the normal MPLS model, and thus a + GAL is invisible to an LSR unless it is the top label in the label + stack. The only other circumstance under which the label stack may + be inspected for a GAL is when the TTL has expired. Normal packet + + + + + +Frost, et al. Standards Track [Page 10] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + forwarding MAY continue concurrently with this inspection. All + operations on the label stack are in accordance with [RFC3031] and + [RFC3032]. + + An application processing a packet received over the G-ACh may + require packet-specific context (such as the receiving interface or + received label stack). Data plane implementations MUST therefore + provide adequate context to the application that is to process a + G-ACh packet. The definition of the context required MUST be + provided as part of the specification of the application using the + G-ACh. + +5. Server-Layer Considerations + + The MPLS-TP network has no awareness of the internals of the server + layer of which it is a client; it requires only that the server layer + be capable of delivering the type of service required by the MPLS-TP + transport entities that make use of it. Note that what appears to be + a single server-layer link to the MPLS-TP network may be a + complicated construct underneath, such as an LSP or a collection of + underlying links operating as a bundle. Special care may be needed + in network design and operation when such constructs are used as a + server layer for MPLS-TP. + + Encapsulation of MPLS-TP packets for transport over specific server- + layer media is outside the scope of this document. + +6. Security Considerations + + The MPLS data plane (and therefore the MPLS-TP data plane) does not + provide any security mechanisms in and of itself. Client layers that + wish to secure data carried over MPLS-TP transport entities are + REQUIRED to apply their own security mechanisms. + + Where management or control plane protocols are used to install + label-switching operations necessary to establish MPLS-TP transport + paths, those protocols are equipped with security features that + network operators may use to securely create the transport paths. + + Where enhanced security is desirable, and a trust relationship exists + between an LSR and its peer, the LSR MAY choose to implement the + following policy for the processing of MPLS packets received from one + or more of its neighbors: + + Upon receipt of an MPLS packet, discard the packet unless one of + the following two conditions holds: + + + + + +Frost, et al. Standards Track [Page 11] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + 1. Any MPLS label in the packet's label stack processed at the + receiving LSR, such as an LSP or PW label, has a label value + that the receiving LSR has distributed to that neighbor; or + + 2. Any MPLS label in the packet's label stack processed at the + receiving LSR, such as an LSP or PW label, has a label value + that the receiving LSR has previously distributed to the peer + beyond that neighbor (i.e., when it is known that the path + from the system to which the label was distributed to the + receiving system is via that neighbor). + + Further details of MPLS and MPLS-TP security can be found in + [RFC5921] and [RFC5920]. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, January 2001. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, + P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- + Protocol Label Switching (MPLS) Support of Differentiated + Services", RFC 3270, May 2002. + + [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing + in Multi-Protocol Label Switching (MPLS) Networks", + RFC 3443, January 2003. + + [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, + "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word + for Use over an MPLS PSN", RFC 4385, February 2006. + + [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, + "Encapsulation Methods for Transport of Ethernet over + MPLS Networks", RFC 4448, April 2006. + + + +Frost, et al. Standards Track [Page 12] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time + Division Multiplexing (TDM) over Packet (SAToP)", + RFC 4553, June 2006. + + [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, + "Encapsulation Methods for Transport of PPP/High-Level + Data Link Control (HDLC) over MPLS Networks", RFC 4618, + September 2006. + + [RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation + Methods for Transport of Frame Relay over Multiprotocol + Label Switching (MPLS) Networks", RFC 4619, + September 2006. + + [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., + Brayley, J., and G. Koleyni, "Encapsulation Methods for + Transport of Asynchronous Transfer Mode (ATM) over MPLS + Networks", RFC 4717, December 2006. + + [RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, + "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous + Transfer Mode (ATM) Transparent Cell Transport Service", + RFC 4816, February 2007. + + [RFC4842] Malis, A., Pate, P., Cohen, R., and D. Zelig, + "Synchronous Optical Network/Synchronous Digital + Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)", RFC 4842, April 2007. + + [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, + "Extensions to Resource Reservation Protocol - Traffic + Engineering (RSVP-TE) for Point-to-Multipoint TE Label + Switched Paths (LSPs)", RFC 4875, May 2007. + + [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream + Label Assignment and Context-Specific Label Space", + RFC 5331, August 2008. + + [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, + "MPLS Multicast Encapsulations", RFC 5332, August 2008. + + [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label + Switching (MPLS) Label Stack Entry: "EXP" Field Renamed + to "Traffic Class" Field", RFC 5462, February 2009. + + [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic + Associated Channel", RFC 5586, June 2009. + + + + +Frost, et al. Standards Track [Page 13] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + + [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., + and S. Ueno, "Requirements of an MPLS Transport Profile", + RFC 5654, September 2009. + +7.2. Informative References + + [FC-ENCAP] Black, D. and L. Dunbar, "Encapsulation Methods for + Transport of Fibre Channel frames Over MPLS Networks", + Work in Progress, June 2010. + + [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- + Edge (PWE3) Architecture", RFC 3985, March 2005. + + [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. + Pate, "Structure-Aware Time Division Multiplexed (TDM) + Circuit Emulation Service over Packet Switched Network + (CESoPSN)", RFC 5086, December 2007. + + [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, + "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, + December 2007. + + [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- + Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, + October 2009. + + [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. + Berger, "A Framework for MPLS in Transport Networks", + RFC 5921, July 2010. + + + + + + + + + + + + + + + + + + + +Frost, et al. Standards Track [Page 14] + +RFC 5960 MPLS-TP Data Plane Architecture August 2010 + + +Authors' Addresses + + Dan Frost (editor) + Cisco Systems + + EMail: danfrost@cisco.com + + + Stewart Bryant (editor) + Cisco Systems + + EMail: stbryant@cisco.com + + + Matthew Bocci (editor) + Alcatel-Lucent + + EMail: matthew.bocci@alcatel-lucent.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Frost, et al. Standards Track [Page 15] + |