RFC 4905

Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks

📅 published June 2007, from ietf

RFC 4905: Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks 🎀

okay bestie, let's get into it 💅 this one is a Historic doc from June 2007 (so it's a throwback 🦋). Here's the lineup:

  • Authors: L. Martini (Ed.), E. Rosen (Ed.) from Cisco Systems, Inc., and N. El-Aawar (Ed.) from Level 3 Communications, LLC
  • Stream: Network Working Group
  • Category: Historic
  • Date: June 2007
  • Obsoletes / Updates: neither! It doesn't obsolete or update anything 🙈

Status of This Memo ✨

So this memo is a Historic Document for the Internet community. It is NOT an Internet standard of any kind, and it's totally fine to share it around, distribution is unlimited 🌸

Copyright (C) The IETF Trust (2007).

Abstract 🔮

okay so this doc walks through how to wrap up layer 2 frames (think Frame Relay, ATM, or Ethernet) so they can travel across an MPLS network 🚀 It's all about the so-called "draft-martini" protocol, and honestly it got iconically replaced by the Pseudowire Emulation Edge to Edge Working Group specs in RFC 4447 and friends 👑

Table of Contents 🧚

   1. Introduction ....................................................3
   2. Specification of Requirements ...................................3
   3. Special Note ....................................................4
   4. General Encapsulation Method ....................................4
      4.1. The Control Word ...........................................4
           4.1.1. Setting the Sequence Number .........................5
           4.1.2. Processing the Sequence Number ......................6
      4.2. MTU Requirements ...........................................6
   5. Protocol-Specific Details .......................................7
      5.1. Frame Relay ................................................7
      5.2. ATM ........................................................8
           5.2.1. ATM AAL5 CPCS-SDU Mode ..............................9
           5.2.2. ATM Cell Mode ......................................10
           5.2.3. OAM Cell Support ...................................12
           5.2.4. CLP bit to Quality of Service Mapping ..............12
      5.3. Ethernet VLAN .............................................12
      5.4. Ethernet ..................................................12
      5.5. High-Level Data Link Control (HDLC) .......................13
      5.6. PPP .......................................................13
   6. Using an MPLS Label as the Demultiplexer Field .................13
      6.1. MPLS Shim EXP Bit Values ..................................14
      6.2. MPLS Shim S Bit Value .....................................14
      6.3. MPLS Shim TTL Values ......................................14
   7. Security Considerations ........................................14
   8. Normative References ...........................................14
   9. Informative References .........................................16
   10. Co-Authors ....................................................16

1. Introduction 🦋

okay so in an MPLS network you can use control protocols like the ones in [RFC4906] to set up "emulated virtual circuits." These carry the Protocol Data Units (PDUs) of layer 2 protocols across the network 🌈 Lots of these emulated VCs can ride inside one single tunnel, and that means the layer 2 PDUs have to be encapsulated. There are three layers of this encapsulation to keep track of:

  • the "tunnel header" 🚇 This has the info needed to carry the PDU across the MPLS network. It belongs to the tunneling protocol, like MPLS, Generic Routing Encapsulation (GRE), or Layer 2 Tunneling Protocol (L2TP).
  • the "demultiplexer field" 🔑 This is how you tell individual emulated VCs apart inside one tunnel. The tunneling protocol has to understand this field too. It could be, for example, an MPLS label or a GRE key field.
  • the "emulated VC encapsulation" 💅 This holds the info about the enclosed layer 2 PDU that's needed to properly emulate the matching layer 2 protocol.

This doc spells out the emulated VC encapsulation for a bunch of layer 2 protocols. Different protocols need different info, but the whole vibe was to make the encapsulation as common as possible across all of them ✨

It also explains how the demultiplexer field gets added to the emulated VC encapsulation when an MPLS label is the demultiplexer field 🍓

Quality of service (QoS) stuff is NOT covered here, so don't look for it in this doc 🙈

For the purposes of this doc, R1 is the ingress router and R2 is the egress router. A layer 2 PDU gets received at R1, encapsulated at R1, transported, decapsulated at R2, and then transmitted out of R2 💖

2. Specification of Requirements 🫶

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

3. Special Note 🚨

This is the big one, so read it carefully 💀

This doc describes the so-called "draft-martini" protocol, which is used in tons of deployed implementations 🌸 The doc itself and its contents have since been superseded by the Pseudowire Emulation Edge to Edge Working Group specs: [RFC4447], [RFC4385], [RFC4448], [RFC4717], [RFC4618], [RFC4619], [RFC4553], [RFC4842], and related docs.

This doc is basically documentation of current implementations, so it MUST NOT be used for new implementations 😭 The PWE3 Label Distribution Protocol control protocol document [RFC4447] is backward compatible with this one, and it MUST be used for all new implementations of this protocol 👑

4. General Encapsulation Method 🌈

Most of the time you don't need to carry the layer 2 encapsulation across the network. Instead, the layer 2 header can be stripped at R1 and reproduced at R2 ✨ That works using info in the control word (more on that below), plus any info that may already have been signaled from R1 to R2 🧚

4.1. The Control Word 💜

There are three requirements that may need to be satisfied when you transport layer 2 protocols over an MPLS backbone:

  • -i. Sequentiality may need to be preserved.
  • -ii. Small packets may need to be padded so they can be sent on a medium where the minimum transport unit is bigger than the actual packet size.
  • -iii. Control bits carried in the header of the layer 2 frame may need to be transported.

The control word in this doc handles all three of these 🎀 For some protocols the control word is REQUIRED, and for others it's OPTIONAL. For protocols where it's OPTIONAL, implementations MUST support sending no control word, and they MAY support sending one too 🦋

No matter what, the egress router has to know whether the ingress router is going to send a control word over a specific virtual circuit. That can come from configuration of the routers, or from signaling, for example as defined in [RFC4906] 💅

Here's how the control word is laid out 👇

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsvd  | Flags |0 0|   Length  |     Sequence Number           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Looking at the diagram, the first 4 bits are reserved for future use 🔮 They MUST be set to 0 when transmitting, and they MUST be ignored upon receipt.

The next 4 bits are space for protocol-specific flags. Those are defined in the protocol-specific details later on 🍓

The next 2 bits MUST be set to 0 when transmitting 🙈

The next 6 bits are the length field, and it works like this ✨ If the packet's length (that's the length of the layer 2 payload plus the length of the control word) is less than 64 bytes, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to 0. If it's non-zero, the value of the length field can be used to remove any padding. When the packet reaches the service provider's egress router, it may be desirable to strip the padding before forwarding the packet 💖

The next 16 bits are a sequence number that can be used to guarantee ordered packet delivery. Processing the sequence number field is OPTIONAL 🫶

The sequence number space is a 16-bit, unsigned circular space. The sequence number value 0 is used to indicate an unsequenced packet 🌀

4.1.1. Setting the Sequence Number 🔢

For a given emulated VC, and a pair of routers R1 and R2, if R1 supports packet sequencing, then the following procedures should be used 💅

  • The initial packet transmitted on the emulated VC MUST use sequence number 1.
  • Subsequent packets MUST increment the sequence number by 1 for each packet.
  • When the transmit sequence number reaches the maximum 16 bit value (65535), the sequence number MUST wrap to 1.

If the transmitting router R1 does NOT support sequence number processing, then the sequence number field in the control word MUST be set to 0 😭

4.1.2. Processing the Sequence Number 🧠

If a router R2 supports receive sequence number processing, then the following procedures should be used 🌸

When an emulated VC is initially set up, the "expected sequence number" associated with it MUST be initialized to 1 ✨

When a packet is received on that emulated VC, the sequence number should be processed like this:

  • If the sequence number on the packet is 0, then the packet passes the sequence number check.
  • Else if the packet sequence number >= the expected sequence number and the packet sequence number - the expected sequence number < 32768, then the packet is in order.
  • Else if the packet sequence number < the expected sequence number and the expected sequence number - the packet sequence number >= 32768, then the packet is in order.
  • Otherwise, the packet is out of order.

If a packet passes the sequence number check or is in order, it can be delivered right away 🚀 If the packet is in order, the expected sequence number should be set using this algorithm:

expected_sequence_number := packet_sequence_number + 1 mod 2**16
if (expected_sequence_number = 0) then expected_sequence_number := 1;

Packets that are received out of order MAY be dropped or reordered at the discretion of the receiver 🦋

If a router R2 does NOT support receive sequence number processing, then the sequence number field MAY be ignored 🌈

4.2. MTU Requirements ✨

okay so the network MUST be set up with an MTU that's big enough to carry the largest encapsulation frames 🫶 if you're using MPLS as the tunneling protocol, it's likely to be 12 or more bytes bigger than the largest frame size. other tunneling protocols can have longer headers and need even bigger MTUs 📏

if the ingress router figures out that an encapsulated layer 2 PDU is bigger than the MTU of the tunnel it has to go through, the PDU MUST be dropped 💀 and if an egress router gets an encapsulated layer 2 PDU whose payload length (aka the length of the PDU itself without any of the encapsulation headers) is bigger than the MTU of the destination layer 2 interface, the PDU MUST be dropped too 🙈

5. Protocol-Specific Details 🦋

5.1. Frame Relay 💜

a Frame Relay PDU gets transported without the Frame Relay header or the Frame Check Sequence (FCS) 🧚 the control word is REQUIRED, but using it is OPTIONAL, although it's super desirable ✨ if you do use the control word, the ingress and egress Label Switching Routers (LSRs) follow the procedures below. if an ingress LSR decides not to use the control word, it MUST set the flags in the control word to 0. if an egress LSR decides to ignore the control word, it MUST set the Frame Relay control bits to 0 🌸

the BECN (Backward Explicit Congestion Notification), FECN (Forward Explicit Congestion Notification), DE (Discard Eligibility), and C/R (Command/Response) bits all get carried across the network in the control word 🎀 edge routers that implement this document MAY, when they're adding or removing the encapsulation, flip the BECN and/or FECN bits from 0 to 1 to show congestion in the network that the edge routers know about. they can also flip the D/E bit from 0 to 1 to show marking from edge policing of the Frame Relay Committed Information Rate 👑 the BECN, FECN, and D/E bits SHOULD NOT be changed from 1 to 0 💅

here's an example of a Frame Relay packet 🍓

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd  |B|F|D|C|    Length     |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Frame Relay PDU                          |
|                             "                                 |
|                             "                                 |
|                             "                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B ( BECN ) Bit 🌈

the ingress router, R1, SHOULD copy the BECN field from the incoming Frame Relay header into this field. the egress router, R2, MUST generate a new BECN field based on the value of the B bit 🫶

F ( FECN ) Bit 🌈

the ingress router, R1, SHOULD copy the FECN field from the incoming Frame Relay header into this field. the egress router, R2, MUST generate a new FECN field based on the value of the F bit 🫶

D ( DE ) Bit 🌈

the ingress router, R1, SHOULD copy the DE field from the incoming Frame Relay header into this field. the egress router, R2, MUST generate a new DE field based on the value of the D bit 💖

if the tunneling protocol has a field that can be set to specify a Quality of Service, the ingress router, R1, MAY consider the DE bit of the Frame Relay header when it works out the value of that field. the egress router MAY then consider the value of this field when it queues the layer 2 PDU for egress. BUT note that frames from the same VC MUST NOT be reordered 🚨

C ( C/R ) Bit 🌈

the ingress router, R1, SHOULD copy the C/R bit from the received Frame Relay PDU to the C bit of the control word. the egress router, R2, MUST copy the C bit into the output frame 🎀

5.2. ATM 🌸

two encapsulations are supported for ATM transport: one for ATM Adaption Layer 5 (AAL5) and another for ATM cells 🧚

the AAL5 Common Part Convergence Sublayer - Service Data Unit (CPCS-SDU) encapsulation consists of the REQUIRED control word and the AAL5 CPCS-SDU. the ATM cell encapsulation consists of an OPTIONAL control word, a 4-byte ATM cell header, and the ATM cell payload 💜

5.2.1. ATM AAL5 CPCS-SDU Mode 🦋

in ATM AAL5 mode, the ingress router is required to reassemble AAL5 CPCS-SDUs from the incoming VC and transport each CPCS-SDU as a single packet. no AAL5 trailer gets transported 🙅 the control word is REQUIRED, but using it is OPTIONAL, although desirable ✨ if you use the control word, the ingress and egress LSRs follow the procedures below. if an ingress LSR chooses not to use the control word, it MUST set the flags in the control word to 0. if an egress LSR chooses to ignore the control word, it MUST set the ATM control bits to 0 💅

the EFCI (Explicit Forward Congestion Indication) and CLP (Cell Loss Priority) bits get carried across the network in the control word 🎀 edge routers that implement this document MAY, when they're adding or removing the encapsulation, flip the EFCI bit from 0 to 1 to show congestion in the network that the edge routers know about, and flip the CLP bit from 0 to 1 to show marking from edge policing of the ATM Sustained Cell Rate. the EFCI and CLP bits MUST NOT be changed from 1 to 0 🚫

the AAL5 CPCS-SDU gets prepended by this header 🧁

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd  |T|E|L|C|    Length     |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     ATM  AAL5 CPCS-SDU                        |
|                             "                                 |
|                             "                                 |
|                             "                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

T (transport type) bit 🌈

bit (T) of the control word tells you whether the packet holds an ATM cell or an AAL5 CPCS-SDU. if it's set, the packet holds an ATM cell, encapsulated according to the ATM cell mode section below. otherwise, it holds an AAL5 CPCS-SDU. being able to carry an ATM cell in AAL5 mode is meant to give a way to enable Operations and Management (OAM) functionality over the AAL5 VC 🔥

E ( EFCI ) Bit 🌈

the ingress router, R1, SHOULD set this bit to 1 if the EFCI bit of the final cell of those that transported the AAL5 CPCS-SDU is set to 1, or if the EFCI bit of the single ATM cell being transported in the packet is set to 1. otherwise, this bit SHOULD be set to 0. the egress router, R2, SHOULD set the EFCI bit of all cells that transport the AAL5 CPCS-SDU to the value contained in this field 💖

L ( CLP ) Bit 🌈

the ingress router, R1, SHOULD set this bit to 1 if the CLP bit of any of the ATM cells that transported the AAL5 CPCS-SDU is set to 1, or if the CLP bit of the single ATM cell being transported in the packet is set to 1. otherwise, this bit SHOULD be set to 0. the egress router, R2, SHOULD set the CLP bit of all cells that transport the AAL5 CPCS-SDU to the value contained in this field 💖

C ( Command / Response Field ) Bit 🌈

when FRF.8.1 Frame Relay / ATM PVC Service Interworking [FRF.8.1] traffic is being transported, the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS-SDU may contain the Frame Relay C/R bit. the ingress router, R1, SHOULD copy this bit to the C bit of the control word. the egress router, R2, SHOULD copy the C bit to the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU 🫶

5.2.2. ATM Cell Mode 🦋

okay so in this mode the ATM cells get sent one at a time with no Segmentation and Reassembly (SAR) process 💅 The encapsulation is an OPTIONAL control word plus one or more ATM cells. Each cell is a 4-byte ATM cell header followed by the 48-byte ATM cell payload. That header comes from the FAST encapsulation [FAST] section 3.1.1, just without the trailer byte 🌸 The length of each frame, not counting the encapsulation headers, is a multiple of 52 bytes long ✨

How many cells can fit in one frame? Honestly, the only real limits are the network MTU and how well the egress router can process them 🔥 The ingress router MUST NOT send more cells than the egress router is willing to receive. That number can be configured on the ingress router, or it can be signaled, for example with the methods described in [RFC4906]. The number of cells in a frame can be figured out just from the frame length 🧚 And yep, the control word is OPTIONAL again.

Okay, the control word part is a big one, so listen up 👑 If you do use the control word, the flag bits in it are not used. They MUST be set to 0 when transmitting, and they MUST be ignored upon receipt. No exceptions, bestie 🫶

Now for the bits everyone keeps asking about, EFCI and CLP 💜 They travel across the network in the ATM cell header. Edge routers that implement this document MAY, when adding or removing this encapsulation, flip the EFCI bit from 0 to 1 to show congestion the edge router already knows about. They can also flip the CLP bit from 0 to 1 to mark traffic that edge policing has marked against the ATM Sustained Cell Rate. The EFCI and CLP bits SHOULD NOT be changed from 1 to 0. Please don't undo those marks, it's giving rude 🙈

Here's a diagram of an encapsulation with two ATM cells 🍓

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Control word ( Optional )                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          VPI          |              VCI              | PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ATM Payload ( 48 bytes )                     |
   |                          "                                    |
   |                          "                                    |
   |                          "                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          VPI          |              VCI              | PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ATM Payload ( 48 bytes )                     |
   |                          "                                    |
   |                          "                                    |
   |                          "                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Let's break down those fields 🎀

  • VPI (Virtual Path Identifier)

The ingress router MUST copy the VPI field from the incoming cell into this field. For particular emulated VCs, the egress router MAY generate a new VPI and ignore the VPI contained in this field.

  • VCI (Virtual Circuit Identifier)

The ingress router MUST copy the VCI field from the incoming ATM cell header into this field. For particular emulated VCs, the egress router MAY generate a new VCI.

  • PTI (Payload Type Identifier) & CLP ( C bit )

The PTI and CLP fields are the PTI and CLP fields of the incoming ATM cells. The cell headers of the cells within the packet are the ATM headers (without HEC) of the incoming cell.

5.2.3. OAM Cell Support 🌈

OAM cells MAY be transported on the VC LSP 💖 An egress router that doesn't support transporting OAM cells MUST discard frames that contain an ATM cell with the high-order bit of the PTI field set to 1. A router that does support OAM transport MUST follow the procedures outlined in [FAST] section 8 for mode 0 only, on top of the applicable procedures specified in [RFC4906].

5.2.4. CLP bit to Quality of Service Mapping ⭐

The ingress router MAY consider the CLP bit when it picks the value for the Quality of Service fields of the encapsulating protocol, like the EXP fields of the MPLS label stack. That gives the network visibility of the CLP bit, which is lowkey iconic 👑 Just note that cells from the same VC MUST NOT be reordered. Order matters, babe 💅

5.3. Ethernet VLAN 🌸

For an Ethernet 802.1q VLAN, the entire Ethernet frame without the preamble or FCS gets transported as a single packet ✨ The control word is OPTIONAL. If you use it, the flag bits are not used, and they MUST be set to 0 when transmitting and MUST be ignored upon receipt. The 4-byte VLAN tag is transported as is, and it MAY be overwritten by the egress router.

The ingress router MAY look at the user priority field [IEEE802.3ac] of the VLAN tag header when it picks the value for the Quality of Service field of the encapsulating protocol (like the EXP fields of the MPLS label stack). In a similar way, the egress router MAY look at the Quality of Service field of the encapsulating protocol when it queues the packet for egress 🦋 Ethernet packets with hardware-level Cyclic Redundancy Check (CRC) errors, framing errors, or runt packets MUST be discarded on input. Bye bye, bad frames 🗑️

5.4. Ethernet 💜

For simple Ethernet port to port transport, the entire Ethernet frame without the preamble or FCS is transported as a single packet 🧚 The control word is OPTIONAL. If it's used, the flag bits aren't used, and they MUST be set to 0 when transmitting and MUST be ignored upon receipt. Same vibe as the VLAN case: Ethernet packets with hardware-level CRC errors, framing errors, and runt packets MUST be discarded on input 🫶

HDLC mode gives you port to port transport of HDLC-encapsulated traffic 🔥 The whole HDLC PDU goes across, including the HDLC address, control, and protocol fields. What gets left out are the HDLC flags and the FCS. Bit/byte stuffing is undone. The control word is OPTIONAL. If you use it, the flag bits are not used, and they MUST be set to 0 when transmitting and MUST be ignored upon receipt.

This mode works well for port to port transport of Frame Relay User-Network Interface (UNI) or Network-Network Interface (NNI) traffic. Worth noting though: this mode is transparent to the FECN, BECN, and DE bits 🙈

5.6. PPP 🎀

PPP mode gives you point to point transport of PPP-encapsulated traffic, as specified in [RFC1661] 💖 The whole PPP PDU goes across, including the protocol field (whether it's compressed with PFC or not). What gets left out is any media-specific framing, like the HDLC address and control fields or the FCS. Since that framing isn't carried, the following options will not operate correctly if the PPP peers try to negotiate them:

  • Frame Check Sequence (FCS) Alternatives
  • Address-and-Control-Field-Compression (ACFC)
  • Asynchronous-Control-Character-Map (ACCM)

Also, VC LSP Interface MTU negotiation as specified in [RFC4906] is not affected by PPP Maximum Receive Unit (MRU) advertisement. So if a PPP peer sends a PDU longer than what was negotiated for the VC LSP, the ingress router will discard it 💀 The control word is OPTIONAL. If it's used, the flag bits are not used, and they MUST be set to 0 when transmitting and MUST be ignored upon receipt.

6. Using an MPLS Label as the Demultiplexer Field 🧚

To use an MPLS label as the demultiplexer field, a 32-bit label stack entry [RFC3032] is simply prepended to the emulated VC encapsulation. That means it shows up as the bottom label of an MPLS label stack 🦋 This label can be called the "VC label" ✨ The particular emulated VC that a given label value identifies must be agreed on by the ingress and egress LSRs, either by signaling (e.g., via the methods of [RFC4906]) or by configuration. The other fields of the label stack entry are set as follows.

6.1. MPLS Shim EXP Bit Values 💅

If you want to carry Quality of Service information, that information SHOULD be represented in the EXP field of the VC label. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack SHOULD also carry the same value.

6.2. MPLS Shim S Bit Value 👑

The ingress LSR, R1, MUST set the S bit of the VC label to a value of 1 to denote that the VC label is at the bottom of the stack. Bottom of the stack, top of the list 🌟

6.3. MPLS Shim TTL Values 🌸

The ingress LSR, R1, SHOULD set the TTL field of the VC label to a value of 2.

7. Security Considerations 🔥😭

Okay bestie, serious moment 🫶 This document specifies only encapsulations. It does NOT specify the protocols used to carry the encapsulated packets across the network. Each such protocol may have its own set of security issues, and those issues are not affected by the encapsulations specified here. For more detailed security considerations, see Section 8 of [RFC4447]. Please go read it, it's giving very important 💜

8. Normative References ✨

Okay, bestie, this is the shopping list of must-read docs the spec needs you to have open. Here it is, every single one, exact details included 💅

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
  • [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.
  • [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, April 2007.
  • [RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
  • [RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "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.
  • [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.
  • [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
  • [RFC4906] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed., "Transport of Layer 2 Frames Over MPLS", RFC 4906, June 2007.
  • [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
  • [FRF.8.1] Frame Relay Forum, "Frame Relay / ATM PVC Service Interworking Implementation Agreement", February 2000.
  • [FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport (FAST)", af-fbatm-0151.000, July 2000.
  • [IEEE802.3ac] IEEE 802.3ac-1998, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) frame extensions for Virtual Bridged Local Area Networks (VLAN) tagging on 802.3 networks".

9. Informative References 🧚

Just one for the "nice to know" pile, but it's a classic 🌸

  • [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

10. Co-Authors 🎀

Here's the whole squad who helped build this thing. Every name, every address, every email, exactly as they wrote them 🫶

Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK
EMail: giles.heron@tellabs.com


Dimitri Stratton Vlachos
Mazu Networks, Inc.
125 Cambridgepark Drive
Cambridge, MA 02140
EMail: d@mazunetworks.com


Dan Tappan
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: tappan@cisco.com


Jayakumar Jayakumar
Cisco Systems Inc.
225, E.Tasman, MS-SJ3/3,
San Jose, CA 95134
EMail: jjayakum@cisco.com
Alex Hamilton
Cisco Systems Inc.
285 W. Tasman, MS-SJCI/3/4,
San Jose, CA 95134
EMail: tahamilt@cisco.com


Steve Vogelsang
Laurel Networks, Inc.
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: sjv@laurelnetworks.com


John Shirron
Laurel Networks, Inc.
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: jshirron@laurelnetworks.com


Toby Smith
Network Appliance, Inc.
800 Cranberry Woods Drive
Suite 300
Cranberry Township, PA 16066
EMail: tob@netapp.com


Andrew G. Malis
Tellabs
90 Rio Robles Dr.
San Jose, CA 95134
EMail: Andy.Malis@tellabs.com


Vinai Sirkay
Redback Networks
300 Holger Way
San Jose, CA 95134
EMail: vsirkay@redback.com
Vasile Radoaca
Nortel Networks
600  Technology Park
Billerica MA 01821
EMail: vasile@nortelnetworks.com


Chris Liljenstolpe
Alcatel
11600 Sallie Mae Dr.
9th Floor
Reston, VA 20193
EMail: chris.liljenstolpe@alcatel.com


Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
EMail: dcooper@gblx.net


Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net

Authors' Addresses 📮

And here are the people who wrote the doc, with all their contact info 💖

Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
EMail: lmartini@cisco.com


Nasser El-Aawar
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO 80021
EMail: nna@level3.net


Eric Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔥

The IETF takes no position on whether any Intellectual Property Rights or other rights claimed to cover the technology in this document are valid or in scope, or on whether any licence under those rights might be available. It also doesn't claim to have made any independent effort to find such rights. Info on how RFC documents handle rights lives in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licences to be made available, or the result of an attempt to get a general licence or permission for implementers or users to use these proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶

📦 where this page comes from