RFC 5960

MPLS Transport Profile Data Plane Architecture

📅 published August 2010, from ietf

RFC 5960: MPLS Transport Profile Data Plane Architecture 🦋 (part 1 of 3)

Okay bestie, here's the title block 💖 This is RFC 5960, called MPLS Transport Profile Data Plane Architecture, dated August 2010. It's a Standards Track doc, so it's an actual Internet standard, not just a suggestion 👑. The editors are D. Frost, Ed. and S. Bryant, Ed. (both from Cisco Systems) and M. Bocci, Ed. (from Alcatel-Lucent). The ISSN is 2070-1721 🌸. The title block doesn't list anything this RFC obsoletes or updates.

Abstract

So MPLS-TP is basically the set of MPLS functions you use to build and run packet-switched transport networks ✨. This doc picks out the part of those functions that makes up the MPLS-TP data plane, which is the layer that handles encapsulating and forwarding packets inside an MPLS-TP network 🎀.

It's also a joint IETF / ITU-T project, meant to bring an MPLS Transport Profile into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures so packet transport networks can do what they need to do 💅.

Status of This Memo

This is an Internet Standards Track document 🔥.

It comes from the Internet Engineering Task Force (IETF) 🌈. It reflects what the IETF community agrees on, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶. If you want more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc5960 🍓.

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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🧚.

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

1. Introduction 🌸

So MPLS-TP is the set of functions that meet the requirements in [RFC5654] for using MPLS to build and run packet-switched transport networks 💅. The MPLS-based networks and the overall MPLS-TP architecture are defined and described in [RFC5921], and this doc assumes you've already read that one 📖.

This doc defines the set of functions that make up the MPLS-TP data plane, which is the layer that handles encapsulating and forwarding packets inside an MPLS-TP network 🦋. This layer builds on the data plane architectures for MPLS ([RFC3031] and [RFC3032]) and for pseudowires [RFC3985] 🎀.

It's also a joint IETF / ITU-T effort to bring an MPLS Transport Profile into the IETF MPLS and PWE3 architectures, so packet transport networks get their capabilities and functionalities ✨.

1.1. Scope

This document has two main goals 🧚:

  • To identify the data plane functions within the MPLS Transport Profile; and
  • To indicate which of these data plane functions an MPLS-TP implementation is required to support.

It covers the encapsulation and forwarding functions for packets going through an MPLS-TP Label Switched Path (LSP), pseudowire (PW), or section (see Section 3 for the definitions of these transport entities) 💖. Encapsulation and forwarding for packets outside an MPLS-TP LSP, PW, or section are out of scope, and so are the mechanisms for delivering packets to or from MPLS-TP LSPs, PWs, and sections 🙈.

1.2. Terminology 🍓

Here's the glossary, so everyone's on the same page 💜:

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

More definitions and terminology live in [RFC5921] and [RFC5654] 🌈.

1.3. Requirements Language 🔥

Okay, this part is the one where the capital letters matter. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read 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) 🧚. You push a label to add another level of LSP hierarchy, and pop it to remove that level 💖. Any pair of LSRs may introduce such an extra level, and once they do, they become adjacent at that new level and are then known as Label Edge Routers (LERs) with respect to the new LSP 🌸.

Compared with, for example, Section 3.10 of [RFC3031], supporting Internet Protocol (IP) host and router data plane functionality on 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 tells the next hop which processing operation to perform at that level of encapsulation 🌈. A swap of this label is an atomic operation, and the contents of the packet after the swapped label are opaque to the forwarding function 🫶. The only event that interrupts a swap is Time To Live (TTL) expiry 😭.

At an LSR, S-PE, or T-PE, extra processing to figure out the context of a packet kicks in when a swap is interrupted by TTL expiry. If the TTL of an LSP label expires, the label with the S (Bottom of Stack) bit set gets inspected to see if it's a reserved label. If it is, the packet is handled according to that reserved label's rules. For example, if it's a Generic Associated Channel Label (GAL), the packet 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, the packet is checked for a Generic Associated Channel Header (ACH) sitting immediately below the PW label. If one is there, 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, the packet is processed according to the rules of that reserved label 🧚.

If none of these exceptions happen, the packet is forwarded according to the procedures in [RFC3031] and [RFC3032] 🎀.

3. MPLS-TP Transport Entities 🦋

The MPLS Transport Profile includes these data plane transport entities 💜:

  • Label Switched Paths (LSPs)
  • sections
  • pseudowires (PWs)

3.1. Label Switched Paths ✨

MPLS-TP LSPs are ordinary MPLS LSPs as defined in [RFC3031], except where this document specifically says otherwise 👑.

3.1.1. LSP Packet Encapsulation and Forwarding ✨

okay so encapsulation and forwarding for MPLS-TP LSPs MUST follow standard MPLS packet encapsulation and forwarding as defined in [RFC3031], [RFC3032], [RFC5331], and [RFC5332], except where this document explicitly says otherwise. just follow the classics 💅

Data plane Quality of Service is part of MPLS-TP through 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 in [RFC5462] and [RFC3270], and it MUST be processed according to the rules in those documents. obsessed with how neat that is 😭

Except for transient packet reordering that may happen 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, where 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 too. 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. no ECMP here, babe 🙅 MPLS-TP LSPs as defined in this document MAY operate over a server layer that supports load-balancing, but that 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 with different requirements regarding the use of ECMP in the server layer 🔮

Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP LSPs 🚫✨

3.1.2. LSP Payloads

the MPLS-TP supports these LSP payload types:

  • Network-layer protocol packets (including MPLS-labeled packets)
  • Pseudowire packets

for network-layer protocol packets, the processing rules SHALL be as specified in [RFC3032] 📦

for pseudowire packets, the processing rules 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 happens, for instance, when the payload is a pseudowire or an MPLS LSP. in these 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. ngl this is the best current practice in MPLS, but it's a tiny bit different from [RFC3032], which uses the S bit to figure out when label processing stops and network-layer processing starts 🤓💖

3.1.3. LSP Types

the MPLS-TP includes these LSP types:

  • Point-to-point unidirectional
  • Point-to-point associated bidirectional
  • Point-to-point co-routed bidirectional
  • Point-to-multipoint unidirectional

point-to-point unidirectional LSPs come from the basic MPLS architecture [RFC3031], and they are REQUIRED to work the same way in the MPLS-TP data plane, except where this document explicitly says otherwise 🦋

a point-to-point associated bidirectional LSP between LSRs A and B is two unidirectional point-to-point LSPs, one from A to B and one from B to A. they're treated as a pair that gives you one logical bidirectional transport path 🫶

a point-to-point co-routed bidirectional LSP is a point-to-point associated bidirectional LSP with one extra rule: its two unidirectional component LSPs, in each direction, follow the same path (in terms of both nodes and links). the big deal here is that the component LSPs share fate, so they go down together 💀

a point-to-multipoint unidirectional LSP works the same as a point-to-point unidirectional LSP for basic label processing and packet switching, with one difference: an LSR may have more than one (egress interface, outgoing label) pair for the LSP, and any packet it sends on the LSP goes out every associated egress interface 🌈 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 topologically adjacent at a particular layer n >= 0 of the MPLS-TP LSP hierarchy if there is 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). that 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). it's called an MPLS-TP section at layer n of the MPLS-TP LSP hierarchy. so the links traversed by a layer n+1 MPLS-TP LSP are layer n MPLS-TP sections 🧩 That LSP is called a client of the section layer, and the section layer is called 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, when there are no stack optimization mechanisms. so, for two LSRs to swap non-IP MPLS-TP control packets over a section, an extra 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 these service types to its client layer:

  • Point-to-point bidirectional
  • Point-to-point unidirectional
  • Point-to-multipoint unidirectional

how a section provides that service is outside the scope of MPLS-TP 🤷‍♀️

any LSP 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 needs 🦋

a section MUST provide a way 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 info MAY be implied by the LSP label or, if the LSP payload is MPLS-labeled, by the setting of the S bit. extra labels MAY also be used if needed to tell different payload types apart. see [RFC5921] for examples and more discussion 📚

3.3. Pseudowires

the data plane architectures for single-segment pseudowires [RFC3985] and multi-segment pseudowires [RFC5659] are included in MPLS-TP 🌷

data plane processing procedures for pseudowires are defined and described in a bunch of IETF documents. some example pseudowire data plane procedures include:

  • Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN [RFC4385]
  • Encapsulation Methods for Transport of Ethernet over MPLS Networks [RFC4448]
  • Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) [RFC4553]
  • Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks [RFC4618]
  • Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks [RFC4619]
  • Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks [RFC4717]
  • Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service [RFC4816]
  • Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) [RFC4842]
  • Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) [RFC5086]
  • Time Division Multiplexing over IP (TDMoIP) [RFC5087]
  • 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. nothing new here, the PW stuff stays exactly as it is 🧚✨

4. MPLS-TP Generic Associated Channel 🌈

the MPLS Generic Associated Channel (G-ACh) mechanism is specified in [RFC5586] and included in MPLS-TP. the G-ACh gives you an auxiliary logical data channel tied to MPLS-TP sections, LSPs, and PWs in the data plane 💜 Its main job in MPLS-TP is to carry control, management, and Operations, Administration, and Maintenance (OAM) traffic for MPLS-TP transport entities. the G-ACh MUST NOT be used to carry client layer network traffic in MPLS-TP networks 🙅‍♀️

for pseudowires, the G-ACh uses the first four bits of the PW control word to give the first discrimination between data packets and packets that belong to the associated channel, as described in [RFC4385]. when this first nibble of a packet, right after the label at the bottom of the stack, has a value of '1', that packet belongs to a G-ACh. the first 32 bits after the bottom-of-stack label then have a defined format called an Associated Channel Header (ACH), which says more about what the packet contains. so the ACH is 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 instead of a PW, the packet needs some way to say that its payload is something other than client data. that's done by including a reserved label with a value of 13 at the bottom of the label stack. this reserved label is the G-ACh Label (GAL), defined in [RFC5586] 🫶 When a GAL is found, it means the payload starts with an ACH. so the GAL is a demultiplexer for G-ACh traffic on the section or LSP, and the ACH is a discriminator for the type of traffic on the G-ACh. MPLS-TP forwarding follows the normal MPLS model, so a GAL is invisible to an LSR unless it's the top label in the label stack. the only other time the label stack may be inspected for a GAL is when the TTL has expired. normal packet forwarding MAY continue at the same time as this inspection 🌸 all operations on the label stack follow [RFC3031] and [RFC3032] 📐

an application processing a packet received over the G-ACh may need packet-specific context (like the receiving interface or the received label stack). so data plane implementations MUST provide adequate context to the application that is going 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 ✨

Okay bestie, so the MPLS-TP network has zero clue what's going on inside the server layer it's a client of 🙈 It only needs the server layer to be able to deliver the kind of service its MPLS-TP transport entities need, and that's it. 💅 Also, what looks like one single server-layer link from the MPLS-TP side can actually be a messy construct underneath, like an LSP or a bunch of links bundled together 🧚 When that's the setup, you'll want to be extra careful with network design and operation, no cap.

Encapsulating MPLS-TP packets for specific server-layer media is outside the scope of this doc, so we're not going there today 🌸

6. Security Considerations 🔥

Okay this section is SERIOUS, so pay attention 😭 The MPLS data plane (and therefore the MPLS-TP data plane) does not provide any security mechanisms in and of itself 💀 Any client layers that want to secure the data carried over MPLS-TP transport entities are REQUIRED to apply their own security mechanisms. No shortcuts, periodt 🫶

Where management or control plane protocols are used to install the label-switching operations needed to set up MPLS-TP transport paths, those protocols come with security features that network operators can use to create the transport paths securely ✨

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 processing MPLS packets received from one or more of its neighbors. This one is kind of iconic, so read it carefully 👑

Here's the policy. Upon receipt of an MPLS packet, discard the packet unless one of the following two conditions holds:

  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).

If you want more tea on MPLS and MPLS-TP security, check out [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.

[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.

[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.

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
📦 where this page comes from