RFC 6658

Packet Pseudowire Encapsulation over an MPLS PSN

📅 published July 2012, from ietf

RFC 6658: Packet Pseudowire Encapsulation over an MPLS PSN 🎀

Okay bestie, here's the title block tea ☕

  • Published by: the Internet Engineering Task Force (IETF) 🌈
  • Number: RFC 6658
  • Category: Standards Track
  • Date: July 2012
  • ISSN: 2070-1721
  • Authors: S. Bryant, Ed.; L. Martini; G. Swallow (Cisco Systems); A. Malis (Verizon Communications) 💅
  • Obsoletes / Updates: the title block doesn't list anything this doc obsoletes or updates 🦋

Abstract 💜

Okay so this doc describes a pseudowire mechanism that carries a packet service over an MPLS PSN. It's for when the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment 🧚. The mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. Main character energy ✨

Status of This Memo 🌸

This is an Internet Standards Track document, so it's officially a standard 🔥

This doc is a product of the IETF. It represents the consensus of the IETF community, and it went through public review before the Internet Engineering Steering Group (IESG) approved it for publication. If you want more info on Internet Standards, check Section 2 of RFC 5741. For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6658 💖

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc. Code Components extracted from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
2.  Network Reference Model  . . . . . . . . . . . . . . . . . . .  4
3.  Client Network-Layer Model . . . . . . . . . . . . . . . . . .  5
4.  Forwarding Model . . . . . . . . . . . . . . . . . . . . . . .  5
5.  Packet PW Encapsulation  . . . . . . . . . . . . . . . . . . .  7
6.  Ethernet and IEEE 802.1 Functional Restrictions  . . . . . . .  8
7.  Congestion Considerations  . . . . . . . . . . . . . . . . . .  8
8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
  11.2. Informative References . . . . . . . . . . . . . . . . . .  9
Appendix A.  Encapsulation Approaches Considered . . . . . . . . . 11
  A.1.  A Protocol Identifier in the Control Word  . . . . . . . . 11
  A.2.  PID Label  . . . . . . . . . . . . . . . . . . . . . . . . 12
  A.3.  Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . 13
  A.4.  Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . 13
  A.5.  Recommended Encapsulation  . . . . . . . . . . . . . . . . 14

1. Introduction 🌷

Okay, so there's a need for a way to carry a packet service over an MPLS PSN that keeps the two networks isolated from each other 🫶. The server MPLS network may be an MPLS network, or a network that conforms to the MPLS Transport Profile (MPLS-TP) [RFC5317]. The client may also be either an MPLS network or a network that conforms to the MPLS-TP. Using an MPLS network as a server for an MPLS-TP network is outside the scope of this doc, so we're not getting into that here 🙈

When the client equipment connects to the server equipment over a physical interface, the same data-link type must be used to attach the clients to the Provider Edge (PE) equipments. The PW has to be the same type as the data-link [RFC3985]. Interworking between different physical and data-link attachment types is specifically disallowed in the pseudowire architecture, and the reason is that it's a complex task and not a simple bit-mapping exercise 💀. Interworking isn't just about the physical and data-link interfaces and the state machines either. It also needs a compatible approach to forming adjacencies between the attached client network equipment. For example, think about how router adjacency formation differs on a point-to-point link versus a multipoint-to-multipoint interface like Ethernet 👑

Here's another thing: two adjacent MPLS Label Switching Routers (LSRs) don't just swap MPLS packets. They also exchange IP packets for adjacency formation, control, routing, label exchange, management, and monitoring 🧚. They may also exchange data-link packets as part of routing (like IS-IS Hellos and IS-IS Link State Packets), and for Operations, Administration, and Maintenance (OAM) purposes, such as the Link-Layer Discovery Protocol [IEEE.802.1AB.2009]. So the two clients need an attachment mechanism that can multiplex a bunch of protocols. On top of that, it's essential to the correct operation of the network layer that all of these protocols fate share, meaning they stay up or go down together 🔥

When the client LSR and server PE are co-located in the same equipment, the data-link layer can be simplified to a point-to-point Ethernet that multiplexes the various data-link types onto a pseudowire. That's the method this doc describes 💖

Appendix A covers alternative approaches to providing a packet PW that the PWE3 Working Group considered, plus the reasons this specification uses the method it does 📜

1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Read these carefully, bestie, they're the rules of the game 💅

2. Network Reference Model 🦋

The network reference model for the packet pseudowire operating in an MPLS network is shown in Figure 1. This is an extension of Figure 3 "Pre-processing within the PWE3 Network Reference Model" from [RFC3985] ✨

                  PW                            PW
               End Service                   End Service
                   |                            |
                   |<------- Pseudowire ------->|
                   |                            |
                   |          Server            |
                   |     |<- PSN Tunnel ->|     |
                   |     V                V     |
   -------   +-----+-----+                +-----+-----+   -------
          )  |     |     |================|     |     |  (
   Client  ) | MPLS| PE1 |      PW1       | PE2 | MPLS| ( Client
   MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN
           ) |     |     |                |     |     | (
          )  |     |     |================|     |     |  (
   -------   +-----+-----+                +-----+-----+   --------
                   ^                            ^
                   |                            |
                   |                            |
                   |<---- Emulated Service----->|
                   |                            |
            Virtual physical             Virtual physical
               termination                  termination

                Figure 1: Packet PW Network Reference Model

In this model, the LSRs (LSR1 and LSR2) are part of the client MPLS PSN. The PEs (PE1 and PE2) are part of the server PSN, which is used to provide connectivity between the client LSRs 🌸. The attachment circuit that connects the MPLS LSRs to the PEs is a virtual interface within the equipment. A packet pseudowire provides connectivity between these virtual interfaces. That packet pseudowire transports all of the required layer 2 and layer 3 protocols between LSR1 and LSR2 💜

3. Client Network-Layer Model 🧚

The packet PW looks like a single point-to-point link to the client layer 💖. Network-layer adjacency formation and maintenance between the client equipments follows the normal practice needed to support the required relationship in the client layer. The client layer decides the metrics for this point-to-point link. In a hop-by-hop routing network, the metrics would normally be assigned through appropriate configuration of the embedded client network-layer equipment (for example, the embedded client LSR) 🍓. If the client uses the packet PW as part of a traffic-engineered path, it's up to the operator of the client network to make sure the server-layer operator provides the necessary service-level agreement 👑

4. Forwarding Model ✨

okay so here's the packet PW forwarding model, shown in Figure 2 💖 It's kinda like a VPN: first a forwarding decision happens at the client layer, then an encapsulation gets slapped on, and then a second forwarding decision happens at the server layer 🎀

            +------------------------------------------------+
            |                                                |
            |  +--------+                        +--------+  |
            |  |        |   Pkt   +-----+        |        |  |
         ------+        +---------+ PW1 +--------+        +------
            |  | Client |    AC   +-----+        | Server |  |
     Client |  | LSR    |                        | LSR    |  | Server
    Network |  |        |   Pkt   +-----+        |        |  | Network
         ------+        +---------+ PW2 +--------+        +------
            |  |        |    AC   +-----+        |        |  |
            |  +--------+                        +--------+  |
            |                                                |
            +------------------------------------------------+

                   Figure 2: Packet PW Forwarding Model

A packet PW PE is made of three parts: the client LSR, a PW processor, and a server LSR. Heads up, [RFC3985] doesn't formally mention the server LSR because it doesn't deal with the server layer. Still, it's super useful to remember that the server LSR exists 🧚

Let's recall how a layer 2 PW works in this model, using an Ethernet PW [RFC4448] as the example 💅 There's no client LSR here. Packets arrive directly on the attachment circuit (AC) that's part of the client network. The PW function does any header processing if it's set up to do so, then optionally pushes the PW control word (CW), and finally pushes the PW label. Next, the PW function hands the packet to the LSR function, which pushes the label needed to reach the egress PE and sends the packet to the next hop in the server network. At the egress PE, the PW label is usually sitting at the top of the stack, so the packet lands on the right PW instance 🦋 That instance does any reconstruction it needs (using the CW if necessary), and then the packet goes straight out the attachment circuit.

Now let's look at client-layer MPLS traffic riding over a packet PW 🌈 An LSR from the client layer is tucked inside the PE equipment. This is a type of native service processing element [RFC3985]. The client LSR figures out the next hop in the client layer and pushes the label that next hop needs. Then it wraps the packet in an Ethernet header with the Ethertype set to MPLS, and passes the packet to the correct PW instance. That PW instance follows the Ethernet PW [RFC4448] process: it optionally pushes the control word, pushes the PW label, and finally hands the packet to the server-layer LSR, which delivers it to the egress PE in the server layer 🚀

At the egress PE in the server layer, the server LSR goes first. It uses the PW label to pass the packet to the correct PW instance. That PW instance processes the packet as described in [RFC4448]. The resulting Ethernet-encapsulated client packet then goes to the egress client LSR, which handles it in the normal way 💜

Note that although the description above is written in terms of how an MPLS LSR behaves, the processing model would be similar for an IP packet or any other protocol type 🌸

Note that the semantics of the PW between the client LSRs is a point-to-point link ⭐

5. Packet PW Encapsulation

Here's how a client network-layer packet gets encapsulated into a packet PW, shown in Figure 3 🎀

+-------------------------------+
|            Client             |
|          Network-Layer        |
|            Packet             |  n octets
|                               |
+-------------------------------+
|                               |
|          Ethernet             | 14 octets
|           Header              |
|               +---------------+
|               |
+---------------+---------------+
|    Optional Control Word      |  4 octets
+-------------------------------+
|          PW Label             |  4 octets
+-------------------------------+
|   Server MPLS Tunnel Label(s) |  n*4 octets (4 octets per label)
+-------------------------------+

                 Figure 3: Packet PW Encapsulation

This follows the PW protocol stack defined in [RFC4448]. The stack itself is pretty unremarkable, with one twist worth knowing about: it does not keep 32-bit alignment between the virtual Ethernet header and the PW optional control word (or the PW label, when the optional parts aren't there). Losing those 32 bits of alignment is necessary to stay backwards compatible with the Ethernet PW design [RFC4448] 🧐

Ethernet Raw Mode (PW type 5) MUST be used for the packet PW. 🔥

The PEs MAY use a local Ethernet address for the Ethernet header that wraps the client network-layer packet, or they MAY use the special Ethernet addresses "PacketPWEthA" or "PacketPWEthB", as described below 🦋

IANA has allocated two unicast Ethernet addresses [RFC5342] for this protocol, called "PacketPWEthA" and "PacketPWEthB". When [RFC4447] signaling is used to set up the PW, the LDP peers compare their IP addresses numerically. The LDP PE with the higher-value IP address uses PacketPWEthA, and the LDP peer with the lower-value IP address uses PacketPWEthB 👑

When no signaling PW protocol is used, suitable Ethernet addresses MUST be configured at each PE. 🙈

Even though this PW is a point-to-point connection, some client-layer protocols REQUIRED a multicast destination address in the Ethernet encapsulation 😭 So peers MUST be prepared to handle a multicast destination address in the Ethernet encapsulation. Yes, even on a point-to-point link 💀

6. Ethernet and IEEE 802.1 Functional Restrictions

Using Ethernet as the encapsulation between the server LSRs is a convenience, since there's already loads of hardware out there that supports it 🍓 For this application, there's no requirement for any Ethernet feature beyond its protocol multiplexing capability. So, for example, a server LSR is not required to implement Ethernet OAM. Main character energy 💅

The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q tagging between PEs is not supported. ❌

Point-to-multipoint and multipoint-to-multipoint operation of the virtual Ethernet is not supported. ❌

7. Congestion Considerations

A packet pseudowire is normally used to carry IP, MPLS, and their associated support protocols over an MPLS network 🌊 There are no congestion considerations beyond those that ordinarily apply to an IP or MPLS network. If the packet protocol being carried is neither IP nor MPLS, and the traffic volumes are bigger than what's ordinarily associated with the support protocols in an IP or MPLS network, then the congestion considerations developed for PWs apply [RFC3985] [RFC5659] ⚠️

8. Security Considerations

Okay, this part is serious bestie 🫶 The virtual Ethernet approach to packet PW introduces no new security risks. For a more detailed discussion of pseudowire security, check out [RFC3985], [RFC4447], and [RFC3916] 🔒

9. IANA Considerations

IANA has allocated two Ethernet unicast addresses from "IANA Unicast 48-bit MAC Addresses" 🌈

Address              Usage             Reference
-------------------  ----------------  ---------
00-00-5E-00-52-00    PacketPWEthA      [RFC6658]
00-00-5E-00-52-01    PacketPWEthB      [RFC6658]

10. Acknowledgements

The authors want to thank Sami Boutros, Giles Herron, Siva Sivabalan, and David Ward for their contributions to this document 🫶🎀

11. References

11.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [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.
  • [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
  • [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.

11.2. Informative References

  • [IEEE.802.1AB.2009] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks -- Station and Media Access Control Connectivity Discovery", IEEE Standard 802.1AB, 2009.
  • [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
  • [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
  • [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
  • [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.
  • [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
  • [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
  • [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.

Appendix A. Encapsulation Approaches Considered ✨

okay bestie, this appendix is the behind-the-scenes tea 🫖. the PWE3 Working Group looked at a bunch of ways to design a packet pseudowire (PW) 🎀, talked about them in IETF meetings and on the PWE3 list, and this section spills what they looked at and what technical stuff they weighed before landing on the approach in the main body. it's here so engineers who want to try alternative optimizations can see why the chosen one won 💅. receipts, basically 🧾✨

in a typical network, there are usually no more than four network-layer protocols that need support: IPv4, IPv6, MPLS, and Connectionless Network Service (CLNS) 🌸. but any solution has to scale to a bigger number of protocols 📈. all the approaches in this appendix clear that minimum, they just differ in how well they stretch to more protocols 🦋.

it's also beneficial if the whole set of protocols carried for a group of CE peers fate shares 🫶. it's also beneficial if one OAM session can monitor the whole set 🔍. people had a lot of opinions on where those benefits sit on the scale from "absolutely required" to "nice to have" 😭, but in the end they didn't factor into the conclusion 💀.

four candidate approaches got analyzed 👑:

  1. A protocol identifier (PID) in the PW control word (CW) 🌈
  2. A PID label 🏷️
  3. Parallel PWs - one per protocol 🧁
  4. Virtual Ethernet 💜

A.1. A Protocol Identifier in the Control Word 🎀

so this one puts a Protocol Identifier (PID) in the PW control word (CW) by tacking it onto the generic control word [RFC4385] to make a 6-byte CW ✨. (they thought about adding 2 reserved bytes for 32-bit alignment, but that got optimized out 🙈.) a variant is to just use a 2-byte PID with no control word at all 🍓.

it's a simple approach, basically a virtual PPP interface without the PPP control protocol 🦋. it has a smaller MTU than, say, a virtual Ethernet would need, BUT in forwarding terms it's not as simple as the PID label or multiple PW approaches, and it might not be deployable on a bunch of existing hardware platforms 😬.

A.2. PID Label 🏷️

here the PID gets indicated by putting a label after the PW label that says what protocol type it is, as shown in Figure 4 🖼️:

   +-------------------------------+
   |            Client             |
   |          Network-Layer        |
   |            Packet             |  n octets
   |                               |
   +-------------------------------+
   |    Optional Control Word      |  4 octets
   +-------------------------------+
   |        PID Label (S=1)        |  4 octets
   +-------------------------------+
   |          PW Label             |  4 octets
   +-------------------------------+
   |   Server MPLS Tunnel Label(s) |  n*4 octets (four octets per label)
   +-------------------------------+

               Figure 4: Encapsulation of a Pseudowire with
                     a Pseudowire Load-Balancing Label

in the PID label approach, a new Label Distribution Protocol (LDP) Forwarding Equivalence Class (FEC) element gets used to signal the mapping between protocol type and the PID label 📡. this approach complies with [RFC3031] ✅.

a similar approach to PID label is in Section 3.4.5 of [RFC5921] 🤝. there, when the client is a network-layer packet service like IP or MPLS, a service label and demultiplexer label (which may be combined) give the identifications needed to carry this traffic over an LSP 🛤️.

the authors surveyed hardware designs from a bunch of companies across the industry 🏭 and concluded that, while the approach complies with the MPLS architecture, it may conflict with a number of designers' interpretations of that architecture 🤔. that raised concerns it could cause unexpected difficulties later 😰. specifically, lots of designs assumed a forwarding decision should be made on the basis of a single label 🏷️. the approach is attractive, but many commodity chip sets can't support it 💔. it would need new hardware, which would bump up deployment cost and delay a packet PW service 💸.

A.3. Parallel PWs 🧁

in this approach, one PW gets built for each protocol type that has to be carried between the PEs 👯. so a complete packet PW is a bundle of PWs 🎁. from a forwarding point of view it's super simple and efficient 🏎️. the number of parallel PWs needed would normally be pretty small 🤏. (same story as before: no more than four network-layer protocols in a typical network, IPv4, IPv6, MPLS, and CLNS, and any solution still needs to scale to more protocols 📈.)

but there are some serious downsides 🚩:

  1. from an operational point of view, the lack of fate sharing between protocol types can cause complex faults that are really hard to diagnose 🕵️‍♀️.
  2. there's an undesirable trade-off in OAM related to that first point 😤. you'd have to run OAM on each PW and bind them together, which means serious protocol and software complexity and it doesn't scale well 📉. or, you could run a single OAM session on one of the PWs as a proxy for the others and then diagnose any more complex failures case by case 🧩. to some extent, the fate-sharing issue between protocols in the bundle (like the assumed fate sharing between CLNS and IP in IS-IS) can be mitigated with Bidirectional Forwarding Detection (BFD) 🔁.
  3. having to configure, manage, and synchronize a group of PWs as if they were a single PW bumps up control-plane complexity 🌀.

so the Parallel PW mechanism simplifies the forwarding plane, but only at the cost of a considerable increase in other parts of the design, especially how the PW gets operated 🫠.

A.4. Virtual Ethernet 💜

using a virtual Ethernet to provide a packet PW means PEs have to include a virtual (internal) Ethernet interface and then use an Ethernet PW [RFC4448] to carry the user traffic 🚌. it's conceptually simple and can be implemented today without any further standards action 🙌. there are a few applicability considerations worth bringing to the community's attention too 📣.

conceptually it's simple, and some deployed equipment can already do this 💅. but needing to run a complete Ethernet adjacency made the authors conclude they needed to find a simpler approach 😮‍💨. the packets encapsulated in an Ethernet header have a larger MTU than the other approaches, though that's not considered an issue on the networks that need to carry packet PWs 🤷‍♀️.

the virtual Ethernet mechanism was the first approach the authors considered, before the merits of the other approaches made them look more attractive 🔄. as we'll see below, though, the other approaches weren't without issues, and it looks like virtual Ethernet is the preferred way to provide a packet PW 🏆.

the operational complexity and the breaking of fate-sharing assumptions tied to the parallel PW approach suggest it's not something to keep pursuing 🚫.

the PID label approach raises concerns that it'll break implicit behavioral and label-stack size assumptions in lots of implementations 😬. those assumptions could be addressed with new hardware, but that would delay the tech so much that it's unlikely to gain acceptance against an approach that needs no new protocol design and already runs on lots of existing hardware platforms 🐢.

the PID in the CW leads to the most compact protocol stack, it's simple, and it needs minimal protocol work 🤩. however, it's a new forwarding design, and apart from the bigger packet header and the simpler adjacency formation, it offers no advantage over virtual Ethernet 🥱.

all of that brings us back to virtual Ethernet, which is a well-known protocol stack with a well-known (internal) client interface 🧸. it's already implemented on many hardware platforms, so it's readily deployable 🚀. after weighing a bunch of initially promising alternatives, the authors conclude that simplicity and existing hardware make virtual Ethernet the most attractive solution for the packet PW 👑✨.

Authors' Addresses 💌

Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park, Reading, Berks RG2 6GB UK

EMail: stbryant@cisco.com

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

EMail: lmartini@cisco.com

George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 USA

EMail: swallow@cisco.com

Andrew G. Malis Verizon Communications 60 Sylvan Rd. Waltham, MA 02451 USA

EMail: andrew.g.malis@verizon.com

📦 where this page comes from