RFC 4619

RFC 4619: Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks 💖

okay bestie, let's get into RFC 4619 🦋 it's a Standards Track doc from September 2006 in the Network Working Group. the editors are L. Martini (Ed.) from Cisco Systems, Inc., C. Kawa (Ed.) from Oz Communications, and A. Malis (Ed.) from Tellabs. the title block doesn't list any Obsoletes or Updates entries, so it isn't replacing or changing anything else 🌸

Status of This Memo ✨

this doc is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 💅

Copyright Notice 📜

Copyright (C) The Internet Society (2006).

Abstract 🧚

okay so a frame relay pseudowire is basically a mechanism living between a provider's edge nodes 💜 it supports frame relay services as faithfully as it can over an MPLS packet switched network (PSN). this doc describes the detailed encapsulation needed to carry frame relay packets across an MPLS network 🔥

Table of Contents 🍓

1. Introduction ....................................................2
2. Specification of Requirements ...................................4
3. Co-authors ......................................................4
4. Acronyms and Abbreviations ......................................5
5. Applicability Statement .........................................5
6. General Encapsulation Method ....................................6
7. Frame Relay over MPLS PSN for the One-to-One Mode ...............7
7.1. MPLS PSN Tunnel and PW .....................................7
7.2. Packet Format over MPLS PSN ................................7
7.3. The Control Word ...........................................8
7.4. The Martini Legacy Mode Control Word .......................9
7.5. PW Packet Processing .......................................9
7.5.1. Encapsulation of Frame Relay Frames .................9
7.5.2. Setting the Sequence Number ........................10
7.6. Decapsulation of PW Packets ...............................11
7.6.1. Processing the Sequence Number .....................11
7.6.2. Processing of the Length Field by the Receiver .....11
7.7. MPLS Shim EXP Bit Values ..................................12
7.8. MPLS Shim S Bit Value .....................................12
7.9. Control Plane Details for Frame Relay Service .............12
7.9.1. Frame Relay Specific Interface Parameter Sub-TLV ...12
8. Frame Relay Port Mode ..........................................13
9. Congestion Control .............................................13
10. Security Considerations .......................................14
11. Normative References ..........................................14
12. Informative References ........................................15

1. Introduction 🦋

okay so in an MPLS or IP network, you can use control protocols like the ones in [RFC4447] to set up "pseudowires" (PWs) 💫 these carry the Protocol Data Units of layer 2 protocols across the network, and a bunch of these emulated PWs can ride in one single tunnel 🌈 the main jobs a Provider Edge (PE) has to handle for frame relay PWs are:

• encapsulating frame relay specific info in a suitable pseudowire (PW) packet 🎀
• moving that PW packet across the MPLS network so it reaches a peer PE 🚀
• pulling the frame relay specific info back out of the PW packet at the remote peer PE 🔍
• regenerating native frame relay frames to send out an egress port of the remote peer PE ✨
• doing any other operations needed to support frame relay service 💅

this doc specifies the encapsulation for the emulated frame relay VC over an MPLS PSN 🫶 different layer 2 protocols need different info in this encapsulation, but we tried to keep it as common as possible across all of them 💖 other layer 2 protocols live in separate docs. [ATM] [RFC4448] [RFC4618]

the figure below shows the reference models, derived from [RFC3985], that support the frame relay PW emulated services 👑

        |<-------------- Emulated Service ---------------->|
        |                                                  |
        |          |<------- Pseudowire ------->|          |
        |          |                            |          |
        |          |    |<-- PSN Tunnel -->|    |          |
        | PW End   V    V                  V    V  PW End  |
        V Service  +----+                  +----+  Service V
  +-----+    |     | PE1|==================| PE2|     |    +-----+
  |     |----------|............PW1.............|----------|     |
  | CE1 |    |     |    |                  |    |     |    | CE2 |
  |     |----------|............PW2.............|----------|     |
  +-----+  ^ |     |    |==================|    |     | ^  +-----+
        ^  |       +----+                  +----+     | |  ^
        |  |   Provider Edge 1         Provider Edge 2  |  |
        |  |       (PE1)                    (PE2)       |  |
  Customer |                                            | Customer
  Edge 1   |                                            | Edge 2
           |                                            |
           |                                            |
   Attachment Circuit (AC)                    Attachment Circuit (AC)
  native frame relay service                 native frame relay service

Figure 1. PWE3 frame relay PVC interface reference configuration

so there are two ways to map frame relay VCs onto pseudowires 🧚 the first is called "one-to-one" mapping, because each frame relay VC gets its own pseudowire 💜 the second is called "many-to-one" mapping, or "port mode", because multiple frame relay VCs on a port all get mapped onto one pseudowire 🌸 the "port mode" encapsulation is identical to High-Level Data Link Control (HDLC) pseudowire encapsulation, which is described in [RFC4618] 🦋

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 RFC 2119.

here are the definitions for the terms used all through the doc 💅 PWE3 definitions live in [RFC3916, RFC3985], and this section covers the terms that are specific to frame relay ✨

• Forward direction 🏃‍♀️: this is the direction the frame is headed in as it gets forwarded.
• Backward direction 🔙: in frame relay, this is the opposite way from the direction a frame is being forwarded (see also forward direction) 💫

3. Co-authors 🎀

the following are co-authors of this document 💖

Nasser El-Aawar           Level 3 Communications, LLC
Eric C. Rosen             Cisco Systems
Daniel Tappan             Cisco Systems
Thomas K. Johnson         Litchfield Communications
Kireeti Kompella          Juniper Networks, Inc.
Steve Vogelsang           Laurel Networks, Inc.
Vinai Sirkay              Reliance Infocomm
Ravi Bhat                 Nokia
Nishit Vasavada           Nokia
Giles Heron               Tellabs
Dimitri Stratton Vlachos  Mazu Networks,Inc.
Chris Liljenstolpe        Cable & Wireless
Prayson Pate              Overture Networks, Inc

4. Acronyms and Abbreviations 🌈

here's the acronym cheat sheet, no cap, you'll want to bookmark this 🔖

   BECN    Backward Explicit Congestion Notification
   CE      Customer Edge
   C/R     Command/Response
   DE      Discard Eligibility
   DLCI    Data Link Connection Identifier
   FCS     Frame Check Sequence
   FECN    Forward Explicit Congestion Notification
   FR      Frame Relay
   LSP     Label Switched Path
   LSR     Label Switching Router
   MPLS    Multiprotocol Label Switching
   MTU     Maximum Transfer Unit
   NNI     Network-Network Interface
   PE      Provider Edge
   PSN     Packet Switched Network
   PW      Pseudowire
   PWE3    Pseudowire Emulation Edge to Edge
   POS     Packet over SONET/SDH
   PVC     Permanent Virtual Circuit
   QoS     Quality of Service
   SVC     Switched Virtual Circuit
   UNI     User-Network Interface
   VC      Virtual Circuit

5. Applicability Statement 🔥

ngl, frame relay over PW service is not meant to perfectly copy the traditional frame relay service 🙈 but it works for apps that need frame relay transport service 💜

these are the notable differences between traditional frame relay service and the protocol in this doc:

• ordering can be kept using the OPTIONAL sequence field in the control word, but implementations are not required to support this feature 🧩
• the Quality of Service model for traditional frame relay can be emulated, but that's outside the scope of this doc 🌸
• a frame relay port mode PW doesn't process any frame relay status messages or alarms described in [Q922] [Q933] 🚫
• the frame relay BECN and FECN bits are transparent to the MPLS network, so they can't reflect the status of the MPLS network 🦋
• support for frame relay SVC and Switched Permanent Virtual Circuit (SPVC) is outside the scope of this doc 💅
• the frame relay Local Management Interface (LMI) is terminated locally in the PE connected to the frame relay attachment circuit 🫶
• support for PVC link integrity check is outside the scope of this doc ✨

6. General Encapsulation Method 💖

the general frame relay pseudowire packet format for carrying frame relay info (the user's payload and the frame relay control info) between two PEs looks like this 🧚

          +-------------------------------+
          |                               |
          |    MPLS Transport header      |
          |       (As required)           |
          +-------------------------------+
          |   Pseudowire (PW) Header      |
          +-------------------------------+
          |        Control Word           |
          +-------------------------------+
          |          FR Service           |
          |           Payload             |
          +-------------------------------+

Figure 2. General format of frame relay encapsulation over PSN

so the PW packet is made of a Control Word and a Payload, with the MPLS Transport and pseudowire headers sitting in front 🌈 here's what each field does:

• i. the MPLS Transport header is specific to the MPLS network 🚇 it's what switches the PW packet through the MPLS core.
• ii. the PW header has an identifier for multiplexing PWs inside an MPLS tunnel 🎀
• iii. the Control Word has protocol control info for providing a frame relay service 🔐 its structure is covered in the sections that follow.
• iv. what goes in the frame relay service payload field depends on the mapping mode 💫 generally, it holds the layer 2 frame relay frame 💜

7. Frame Relay over MPLS PSN for the One-to-One Mode 👑

7.1. MPLS PSN Tunnel and PW 🦋

okay so the MPLS tunnels are basically the LSPs (label switched paths) that run between PEs, and they're what the MPLS core uses to forward PW packets 🚇✨ A tunnel is the "PSN Tunnel" you see in Figure 1.

and here's the cute part: several PWs can be nested inside one MPLS tunnel 🪆 Each PW carries the traffic of a single frame relay VC, and the PW header in this case is an MPLS label called the PW label 💜

7.2. Packet Format over MPLS PSN 🎀

for the one-to-one mapping mode of frame relay over an MPLS network, the PW packet looks like Figure 3 below 👇

    +-------------------------------+
    |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
    +-------------------------------+
    |      PW label                 |  4 octets
    +-------------------------------+
    |       Control Word            |
    |      (See Figure 4)           | 4 octets
    +-------------------------------+
    |            Payload            |
    |      (Frame relay frame       |
    |       information field)      | n octets
    |                               |
    +-------------------------------+

          Figure 3.  Frame Relay over MPLS PSN Packet for the
                     One-to-One Mapping

so here's what each field is doing 🫶

• MPLS Tunnel label(s)

these correspond to the MPLS transport header from Figure 2 ✨ The label(s) are what MPLS LSRs use to forward a PW packet from one PE to the other, so they're the delivery crew 🚚

• PW Label

this one identifies a single PW (aka one LSP) assigned to a frame relay VC in one direction 🧚 It lines up with the PW header from Figure 2. Together, the MPLS Tunnel label(s) and the PW label form an MPLS label stack [RFC3032], which is literally the whole label sandwich 🥪

• Control Word

the control word holds protocol control information 💅 Its structure is shown in Figure 4.

• Payload

this is the X.36/X.76 frame relay frame information field, but with a few things stripped off: bit/byte stuffing, the frame relay header, and the FCS 🍓 Now, it is RECOMMENDED to support a frame size of at least 1600 bytes 🌈 And the maximum payload length MUST be agreed upon by the two PEs. The way to do that is the MTU interface parameter when the PW gets set up [RFC4447] 🔥

7.3. The Control Word 👑

this control word is REQUIRED for frame relay one-to-one mode, and honestly it's the MVP 🏆 It carries frame relay specific info that the egress PE needs in order to rebuild the frame relay frame. It also carries a sequence number, which can help keep things in order when frame relay is riding over an MPLS network 🌸 Here's the structure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0|F|B|D|C|FRG|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4.  Control Word structure for the one-to-one mapping mode

and the fields, bit by bit (see also [X36 and X76] for the frame relay bits) 🦋

• Bits 0 to 3

in the diagram above, the first 4 bits MUST be set to 0 to indicate PW data 🧸

• F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.
• B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit.
• D (bit 6) FR DE bit (Discard Eligibility) bit.
• C (bit 7) FR frame C/R (Command/Response) bit.
• FRG (bits 8 and 9): these bits are defined by [RFC4623] 💜
• Length (bits 10 to 15)

okay this one is giving padding energy 🧁 If the PW goes over a network link that needs a minimum frame size (Ethernet is the classic example), then padding is required to reach that minimum. If the frame's length (the layer 2 payload length plus the control word length) is less than 64 octets, the length field MUST be set to the PW payload length. Otherwise, the length field MUST be set to zero. When it's non-zero, the egress PE uses it to strip off the padding characters 🫧

• Sequence number (Bit 16 to 31)

sequence numbers are one possible way to make sure PW packets get delivered in order 🎀 Processing this field is OPTIONAL. The sequence number space is a 16-bit unsigned circular space, and the value 0 is used to say "the sequence number check algorithm is not in use" 🔄

7.4. The Martini Legacy Mode Control Word 🕰️

for backward compatibility with existing implementations, there's a second version of the control word, called the "martini mode CW" for frame relay 🫶 Look at how similar it is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0|B|F|D|C|FRG|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5.  Control Word structure for the frame relay martini mode

⚠️ the big twist: in this version the "B" and "F" bits are swapped. Note that the "B" and "F" bits are reversed, so don't mix them up, bestie 😭

this control word format is used for the PW type "Frame Relay DLCI ( Martini Mode )" 💅

7.5. PW Packet Processing ⚙️

7.5.1. Encapsulation of Frame Relay Frames 📦

the encapsulation process starts when a PE gets a frame relay frame from one of its frame relay UNI or NNI [FRF1] [FRF2] interfaces 🚀 The PE builds these control word fields from the matching fields of the frame relay frame:

• Command/Response (C/R or C) bit: the C bit is copied unchanged into the PW Control Word 🫶
• The DE bit of the frame relay frame is copied into the D bit field. However, if the D bit is not already set, it MAY be set as a result of ingress frame policing. If it isn't already set by the copy operation, setting this bit is OPTIONAL for a PE. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1) 🙅‍♀️
• The FECN bit of the frame relay frame is copied into the F bit field. However, if the F bit is not already set, it MAY be set to reflect a congestion situation the PE detected. If it isn't already set by the copy operation, setting this bit is OPTIONAL for a PE. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1) 🌊
• The BECN bit of the frame relay frame is copied into the B bit field. However, if the B bit is not already set, it MAY be set to reflect a congestion situation the PE detected. If it isn't already set by the copy operation, setting this bit is OPTIONAL for a PE. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1). 🌊
• If the PW packet length (the payload length plus the control word length) is less than 64 octets, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to zero. 📏
• The sequence number field is processed if the PW uses sequence numbers [RFC4385] 🔢
• The payload of the PW packet is the contents of the ITU-T Recommendations X.36/X.76 [X36] [X76] frame relay frame information field, with any bit or byte stuffing removed 🧼

7.5.2. Setting the Sequence Number 🔢

for a given PW and a pair of routers PE1 and PE2, if PE1 supports packet sequencing, then the procedures in [RFC4385], Section 4.1, MUST be followed 💖

7.6. Decapsulation of PW Packets 📬

when a PE receives a PW packet, it reads the fields of the control word so it can decapsulate the frame relay frame and send it to a CE on a frame relay UNI or NNI 💌 The PE does the following (not necessarily in this order) 🧚

• It generates these frame relay frame header fields from the matching fields of the PW packet.
• The C/R bit MUST be copied into the frame relay header.
• The D bit MUST be copied into the frame relay header DE bit.
• The F bit MUST be copied into the frame relay header FECN bit. If the F bit is set to zero, the FECN bit may be set to one, depending on the congestion state of the PE device in the forward direction. Changing the state of this bit by a PE is OPTIONAL. 🌬️
• The B bit MUST be copied into the frame relay header BECN bit. If the B bit is set to zero, the BECN bit may be set to one, depending on the congestion state of the PE device in the backward direction. Changing the state of this bit by a PE is OPTIONAL. 🌬️
• It processes the length and sequence fields, which are detailed in the following subsections.
• It copies the frame relay information field from the PW packet payload, after removing any padding. 🧹

once all of the above fields of an FR frame are processed, the standard HDLC operations get performed on the frame relay frame: the HDLC header gets added, any bit or byte stuffing is added as required, and the FCS is appended to the frame 🧵 Then the FR frame is queued for transmission on the chosen frame relay UNI or NNI interface 🚀

7.6.1. Processing the Sequence Number 🔢

if a router PE2 supports received sequence number processing, then the procedures in [RFC4385], Section 4.2, MUST be used 💜

7.6.2. Processing of the Length Field by the Receiver 📏

any padding octet in the payload field of a received PW packet MUST be removed before the data is forwarded. 🫧

• If the Length field is set to zero, then there are no padding octets following the payload field.
• Otherwise, if the payload is longer, then the padding characters are removed according to the length specified in the control word's length field.

7.7. MPLS Shim EXP Bit Values 🌈

if you want to carry Quality of Service information, the QoS info SHOULD be represented in the Experimental Use Bits (EXP) field of the PW MPLS label [RFC3032] ✨ And if the ingress LSR imposes more than one MPLS label, the EXP field of any labels higher in the stack SHOULD also carry the same value 🥰

7.8. MPLS Shim S Bit Value ⭐

the ingress LSR, PE1, MUST set the S bit of the PW label to a value of 1 to show that the PW label is at the bottom of the stack 🧱

7.9. Control Plane Details for Frame Relay Service 🧠

the PE MUST provide frame relay PVC status signaling to the frame relay network 📡 If the PE detects a service-affecting condition for a particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA FRF1.1, the PE MUST communicate the status of the PW that matches the frame relay DLCI status to the remote PE. The egress PE SHOULD generate the matching errors and alarms defined in [Q922] [Q933] on the egress frame relay PVC 🚨

there are two frame relay flag-to-control-word bit mappings. The legacy bit ordering scheme will be used for a PW of type 0x0001, "Frame Relay DLCI (Martini Mode)", and the new bit ordering scheme will be used for a PW of type 0x0019, "Frame Relay DLCI". The IANA allocation registry of "Pseudowire Type" is defined in [RFC4446] along with its initial allocated values 🗂️💖

7.9.1. Frame Relay Specific Interface Parameter Sub-TLV 🎀

okay so [RFC4447] is the doc that spills all the tea on the PW control and maintenance protocol, including the generic interface parameter sub-TLVs 💅. When the interface parameter info applies, it MUST be used to check that the PEs and the ingress and egress ports at the edges of the circuit actually have the capabilities they need to interoperate with each other ✨. The Interface parameter TLV is defined in [RFC4447], and the IANA registry with initial values for interface parameter sub-TLV types is in [RFC4446]. The frame relay specific sub-TLV types are these:

• 0x08 Frame Relay Header Length Sub-TLV

This is an optional 16-bit value that tells you the length of the FR Header, in octets 🍓. This OPTIONAL interface parameter Sub-TLV can have a value of 2, 3, or 4, and the default is 2. If the Sub-TLV isn't there at all, the default value of 2 is assumed 🧚.

8. Frame Relay Port Mode 🦋

The frame relay port mode PW shares the same encapsulation as the HDLC PW, and it's described in the respective document. [RFC4618]

9. Congestion Control 🌊

so as [RFC3985] explains, the PSN carrying the PW may get congested, and what that looks like depends on the PSN type, the network architecture, the configuration, and the loading 😭. During congestion the PSN may drop packets, and that can totally mess with the service running over the frame relay PW 💀. Also, frame relay PWs carry a whole variety of services across the PSN, including but not restricted to TCP/IP, so they may or may not behave in the TCP-friendly way that [RFC2914] lays out. When there are services that cut their transmission rate, frame relay PWs can end up hogging more than their fair share, and in that case they SHOULD be halted 🛑.

Whenever possible, frame relay PWs should be run over traffic-engineered PSNs that provide bandwidth allocation and admission control mechanisms 👑. IntServ-enabled domains providing the Guaranteed Service (GS), or DiffServ-enabled domains using EF (expedited forwarding), are examples of traffic-engineered PSNs. These PSNs will minimize loss and delay while also giving the frame relay PW some isolation from its neighboring streams, so its effects stay contained 🫶.

Note that when transporting frame relay, DiffServ-enabled domains may use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of EF, to put less burden on the network and get some extra statistical multiplexing advantage 🌈. Here's the tea: if the Committed Information Rate (CIR) of a frame relay VC is zero, then it's basically the same as a best-effort UDP over IP stream when it comes to congestion. The network is free to drop frames as needed. In that case, the "DF" Per Hop Behavior (PHB) would be the right fit in a diff-serv-TE domain 🎀. Alternatively, if the CIR of a frame relay VC is nonzero and the DE bit is zero in the FR header, then "AF31" would be appropriate to use. And if the CIR of a frame relay VC is nonzero but the DE bit is on, then "AF32" would be appropriate [RFC3270] ✨.

The PEs SHOULD monitor for congestion, either by using explicit congestion notification ([VCCV]) or by measuring packet loss, so the service using the frame relay PW can be kept up 💖. When a PE detects significant congestion while receiving the PW PDUs, the BECN bits of the frame relay frame transmitted on the same PW SHOULD be set. This lets the remote PE and the remote frame relay switch know the congestion situation is happening 🚨. On top of that, the FECN bits SHOULD be set in the FR frames sent out the attachment circuit, so the FR DTE gets a chance to adjust its transport layer advertised window, if it's possible for it to do so 🍓.

If the PW was set up using the protocol defined in [RFC4447], then the status notification procedures specified in [RFC4447] can be used to disable packet transmission on the ingress PE from the egress PE 🙅‍♀️. The PW may be restarted by manual intervention, or by automatic means after an appropriate waiting time 🧚.

10. Security Considerations 🔐

okay, this part is serious, bestie 😭. PWE3 provides no means of protecting the contents or the delivery of the PW packets on behalf of the native service 🚨. PWE3 may, however, leverage security mechanisms provided by the MPLS Tunnel Layer 🛡️. A more detailed discussion of PW security is given in [RFC3985, RFC4447, RFC3916] 💜.

11. Normative References 📚

• [RFC4447] Martini, L., 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.
• [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
• [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
• [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of Point to Point Protocol/High-Level Data Link Control (PPP/HDLC) over Multiprotocol Label Switching (MPLS) Networks", RFC 4618, September 2006.
• [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.

12. Informative References 🌸

• [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
• [VCCV] Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection Verification (VCCV)", Work in Progress, October 2005.
• [ATM] Martini, L., et al., "Encapsulation Methods for Transport of ATM Over MPLS Networks", Work in Progress, April 2005.
• [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
• [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2000.
• [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2002
• [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
• [X36] ITU-T Recommendation X.36, Interface between a DTE and DCE for public data networks providing frame relay, Geneva, 2000.
• [X76] ITU-T Recommendation X.76, Network-to-network interface between public data networks providing frame relay services, Geneva,2000
• [Q922] ITU-T Recommendation Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995
• [Q933] ITU-T Recommendation Q.933 Specification for Frame Mode Basic call control, ITU Geneva 2003
• [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
• [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.

Contributing Author Information 💕

Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089

EMail: kireeti@juniper.net


Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK

EMail: giles.heron@tellabs.com


Rao Cherukuri
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089


Dimitri Stratton Vlachos
Mazu Networks, Inc.
125 Cambridgepark Drive
Cambridge, MA 02140

EMail: d@mazunetworks.com


Chris Liljenstolpe
Alcatel
11600 Sallie Mae Dr.
9th Floor
Reston, VA 20193

EMail: chris.liljenstolpe@alcatel.com
Nasser El-Aawar
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021

EMail: nna@level3.net


Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719

EMail: erosen@cisco.com


Dan Tappan
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719

EMail: tappan@cisco.com


Prayson Pate
Overture Networks, Inc.
507 Airport Boulevard
Morrisville, NC, USA 27560

EMail: prayson.pate@overturenetworks.com


David Sinicrope
Ericsson IPI

EMail: david.sinicrope@ericsson.com


Ravi Bhat
Nokia

EMail: ravi.bhat@nokia.com


Nishit Vasavada
Nokia

EMail: nishit.vasavada@nokia.com
Steve Vogelsang
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205

EMail: stephen.vogelsang@ecitele.com


Vinai Sirkay
Redback Networks
300 Holger Way,
San Jose, CA 95134

EMail: sirkay@technologist.com

Authors' Addresses 🧑‍💻

Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112

EMail: lmartini@cisco.com


Claude Kawa
OZ Communications
Windsor Station
1100, de la Gauchetie`re St West
Montreal QC Canada
H3B 2S2

EMail: claude.kawa@oz.com


Andrew G. Malis
Tellabs
1415 West Diehl Road
Naperville, IL  60563

EMail: Andy.Malis@tellabs.com

Full Copyright Statement ⭐

Copyright (C) The Internet Society (2006).

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 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 regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).