RFC 9801

Private Line Emulation over Packet Switched Networks

📅 published July 2025, from ietf

RFC 9801: Private Line Emulation over Packet Switched Networks 💖

okay bestie, RFC 9801 is a Standards Track doc from the IETF, dated July 2025, and it's giving "we're making private lines work over packet networks" 🦋. The authors are S. Gringeri, J. Whittaker, and N. Leymann, plus C. Schmutzer (editor) and C. Brown. They're from Verizon, Deutsche Telekom, Cisco Systems, Inc., and Ciena Corporation. Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🌸

Abstract ✨

okay so this doc takes VPWS bit-stream payloads and makes them work way beyond TDM signals. The result is pseudowire transport with complete signal transparency over Packet Switched Networks (PSNs). no cap, it's iconic 👑

Status of This Memo 📜

this is an Internet Standards Track document 💅

it comes from the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check out Section 2 of RFC 7841.

for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9801 🌈

Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. please read them carefully, because they explain your rights and restrictions for this doc 🫶

if you pull Code Components out of this doc, they must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions. they come with no warranty, as the Revised BSD License describes ⭐

Table of Contents 🧚

1.  Introduction and Motivation
2.  Requirements Notation
3.  Terminology and Reference Models
  3.1.  Abbreviations
  3.2.  Reference Models
4.  Emulated Services
  4.1.  Generic PLE Service
  4.2.  Ethernet Services
    4.2.1.  1000BASE-X
    4.2.2.  10GBASE-R and 25GBASE-R
    4.2.3.  40GBASE-R, 50GBASE-R, and 100GBASE-R
    4.2.4.  200GBASE-R and 400GBASE-R
    4.2.5.  Energy Efficient Ethernet (EEE)
  4.3.  SONET/SDH Services
  4.4.  Fibre Channel Services
    4.4.1.  1GFC, 2GFC, 4GFC, and 8GFC
    4.4.2.  16GFC
    4.4.3.  32GFC and 4-Lane 128GFC
    4.4.4.  64GFC
  4.5.  OTN Services
5.  PLE Encapsulation Layer
  5.1.  PSN and VPWS Demultiplexing Headers
    5.1.1.  New SRv6 Behaviors
  5.2.  PLE Header
    5.2.1.  PLE Control Word
    5.2.2.  RTP Header
6.  PLE Payload Layer
  6.1.  Basic Payload
  6.2.  Byte-Aligned Payload
7.  PLE Operation
  7.1.  Common Considerations
  7.2.  PLE IWF Operation
    7.2.1.  PSN-Bound Encapsulation Behavior
    7.2.2.  CE-Bound Decapsulation Behavior
  7.3.  PLE Performance Monitoring
  7.4.  PLE Fault Management
8.  QoS and Congestion Control
9.  Security Considerations
10. IANA Considerations
  10.1.  Bit-Stream Next Header Type
  10.2.  SRv6 Endpoint Behaviors
11. References
  11.1.  Normative References
  11.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction and Motivation ✨

okay so this doc describes Private Line Emulation (PLE), a method that encapsulates not only Time Division Multiplexing (TDM) signals but also other signals, as bit-stream Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN). it's the bestie of [RFC4553], since it complements what that one does 💜

this emulation is for situations where carrying Protocol Data Units (PDUs) as defined in [RFC4906] or [RFC4448] isn't enough. when you need physical layer signal transparency, and the Provider Edge (PE) interpreting the data or framing structure would be counterproductive, PLE is the move 🍓

one example is two Ethernet-connected Customer Edge (CE) devices that need Synchronous Ethernet operation (see [G.8261]) between them. the intermediate PE devices shouldn't interfere, and there's no need to worry about Ethernet control protocol transparency for PDU-based carrier Ethernet services, beyond the behavior definitions of MEF Forum (MEF) specifications. it's giving no drama 🙈

another example is Storage Area Networking (SAN) extension between two data centers. operating at a bit-stream level means you can connect Fibre Channel switches without interfering with any of the Fibre Channel protocol mechanisms defined by [T11] 🔥

then there's SONET/SDH add/drop multiplexers or cross-connects (Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH)). they can be interconnected without interfering with the multiplexing structures and network mechanisms. this is the key difference from Circuit Emulation over Packet (CEP), defined in [RFC4842]. CEP needs multiplexing and demultiplexing so it can operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT), or SDH Virtual Container (VC). PLE instead provides an independent layer network underneath the SONET/SDH layer network, while CEP operates at the same level as, and peers with, the SONET/SDH layer network 🦋

PLE follows principles similar to Structure-Agnostic TDM over Packet (SAToP), defined in [RFC4553]. the applicability is expanded beyond the narrow set of Plesiochronous Digital Hierarchy (PDH) interfaces (T1, E1, T3, and E3). now it can carry signals from many technologies, like Ethernet, Fibre Channel, SONET/SDH ([GR253] / [G.707]), and Optical Transport Network (OTN) [G.709], at gigabit speeds. these signals are treated as bit-stream payload, which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in Sections 3.3.3 and 3.3.4 of [RFC3985] 🌸

2. Requirements Notation 💅

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. so if you see them in caps, that's the official spec language, and if they're lowercase, they're just regular words 🫶

3. Terminology and Reference Models 🧚

3.1. Abbreviations 🌈

here's the glossary, bestie. these are the abbreviations the doc uses, with their expansions and any references that come with them:

  • ACH: Associated Channel Header [RFC7212]
  • AIS: Alarm Indication Signal
  • AIS-L: Line AIS
  • MS-AIS: Multiplex Section AIS
  • BITS: Building Integrated Timing Supply [ATIS-0900105.09.2013]
  • CBR: Constant Bit Rate
  • CE: Customer Edge
  • CEP: Circuit Emulation over Packet [RFC4842]
  • CSID: Compressed SID
  • CSRC: Contributing Source [RFC3550]
  • DEG: Degradation
  • ES: Errored Second
  • FEC: Forward Error Correction
  • ICMP: Internet Control Message Protocol [RFC4443]
  • IEEE: Institute of Electrical and Electronics Engineers
  • INCITS: INternational Committee for Information Technology Standards
  • IWF: Interworking Function
  • LDP: Label Distribution Protocol [RFC5036], [RFC8077]
  • LF: Local Fault
  • LOF: Loss Of Frame
  • LOM: Loss Of Multiframe
  • LOS: Loss Of Signal
  • LPI: Low Power Idle
  • LSP: Label Switched Path
  • MEF: MEF Forum
  • MPLS: Multiprotocol Label Switching [RFC3031]
  • NOS: Not Operational
  • NSP: Native Service Processing [RFC3985]
  • ODUk: Optical Data Unit k
  • OOF: Out Of Frame
  • OTN: Optical Transport Network
  • OTUk: Optical Transport Unit k
  • PCS: Physical Coding Sublayer
  • PDV: Packet Delay Variation
  • PE: Provider Edge
  • PLE: Private Line Emulation
  • PLOS: Packet Loss Of Signal
  • PLR: Packet Loss Rate
  • PMA: Physical Medium Attachment
  • PMD: Physical Medium Dependent
  • PSN: Packet Switched Network
  • PTP: Precision Time Protocol
  • PW: Pseudowire [RFC4664]
  • PWE3: Pseudo Wire Emulation Edge-to-Edge [RFC3985]
  • RDI: Remote Defect Indication
  • RSVP-TE: Resource Reservation Protocol Traffic Engineering [RFC4875]
  • RTCP: RTP Control Protocol [RFC3550]
  • RTP: Real-time Transport Protocol [RFC3550]
  • SD: Signal Degrade
  • SES: Severely Errored Seconds
  • SDH: Synchronous Digital Hierarchy
  • SID: Segment Identifier [RFC8402]
  • SR: Segment Routing [RFC8402]
  • SRH: Segment Routing Header [RFC8754]
  • SRTP: Secure Real-time Transport Protocol [RFC3711]
  • SRv6: Segment Routing over IPv6 [RFC8986]
  • SSRC: Synchronization Source [RFC3550]
  • SONET: Synchronous Optical Network
  • TCP: Transmission Control Protocol [RFC9293]
  • TDM: Time Division Multiplexing
  • TTS: Transmitter Training Signal
  • UAS: Unavailable Seconds
  • VPWS: Virtual Private Wire Service [RFC3985]

and here's a note from the doc, verbatim:

   |  Note: The term Interworking Function (IWF) is used to describe
   |  the functional block that encapsulates bit-streams into PLE
   |  packets and in the reverse direction decapsulates PLE packets
   |  and reconstructs bit-streams.

more parts are coming, so stay tuned for part 2 🎀💖

3.2. Reference Models 🧚

okay so the reference model for PLE is shown in Figure 1, and it lines up with the one in Section 4.1 of [RFC3985]. PLE leans on PWE3 preprocessing, especially the concept of an NSP function from Section 4.2.2 of [RFC3985] 💅

                   |<--- p2p L2VPN service -->|
                   |                          |
                   |     |<-PSN tunnel->|     |
                   v     v              v     v
               +---------+              +---------+
               |   PE1   |==============|   PE2   |
               +---+-----+              +-----+---+
   +-----+     | N |     |              |     | N |     +-----+
   | CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 |
   +-----+  ^  | P |     |              |     | P |  ^  +-----+
            |  +---+-----+              +-----+---+  |
     CE1 physical  ^                          ^  CE2 physical
      interface    |                          |   interface
                   |<--- emulated service --->|
                   |                          |
               attachment                 attachment
                circuit                    circuit

                       Figure 1: PLE Reference Model

PLE follows the minimum intervention principle from Section 3.3.5 of [RFC3985], which basically means the data flows through the PLE encapsulation layer exactly as it was received, no edits, no drama 🫶

For some service types, the NSP function is the one doing the work on the data that comes in from the CE. Examples include terminating FEC, terminating the OTUk layer for OTN, or dealing with multi-lane processing. After the NSP, the IWF generates the payload of the VPWS, which then rides over a PSN tunnel 🦋

To let the clock of the transported signal travel across the PLE domain transparently, the relative network synchronization reference model and deployment scenario from Section 4.3.2 of [RFC4197] apply, and they're shown in Figure 2 ⏰

                     J
                     |                                           G
                     |                                           |
                     | +-----+                 +-----+           v
      +-----+        v |- - -|=================|- - -|          +-----+
      |     |<---------|.............................|<---------|     |
      | CE1 |          | PE1 |       VPWS      | PE2 |          | CE2 |
      |     |--------->|.............................|--------->|     |
      +-----+          |- - -|=================|- - -| ^        +-----+
           ^           +-----+                 +-----+ |
           |              ^ C                   D ^    |
           A              |                       |    |
                          +-----------+-----------+    E
                                      |
                                     +-+
                                     |I|
                                     +-+

                 Figure 2: Relative Network Scenario Timing

The local oscillators C of PE1 and D of PE2 are locked to a common clock I 🔒

The attachment circuit clock E is generated by PE2 using a differential clock recovery method, referenced to the common clock I. For this to work, the difference between clock A and clock C (locked to I) MUST be explicitly transferred from PE1 to PE2 using the timestamp inside the RTP header 🧠

In the reverse direction, PE1 generates the attachment circuit clock J, and the clock difference between G and D (locked to I) is transferred from PE2 to PE1 🔄

How C and D get locked to the common clock I is out of scope for this document. That said, there are already several well-established concepts for clock synchronization (also often called "frequency synchronization") out there, so you're not starting from zero 🌈

When using external timing inputs (aka BITS [ATIS-0900105.09.2013]) or synchronous Ethernet (as defined in [G.8261]), the characteristics and limits defined in [G.8262] have to be considered 📏

When relying on PTP (as defined in [G.8265.1]), the network limits defined in [G.8261.1] have to be considered 🕰️

4. Emulated Services ✨

This specification covers emulating services from a wide range of technologies, like TDM, Ethernet, Fibre Channel, or OTN. They can be emulated as bit-streams or structured bit-streams, as defined in Sections 3.3.3 and 3.3.4 of [RFC3985] 🎀

4.1. Generic PLE Service 🍓

The generic PLE service is an example of the bit-stream defined in Section 3.3.3 of [RFC3985] 💜

Assuming the CE-bound IWF isn't responsible for any service-specific operation, a bit-stream of any rate can be carried using the generic PLE payload 🚀

There is no NSP function present for this service 🙅‍♀️

4.2. Ethernet Services 🌸

Ethernet services are special cases of the structured bit-stream defined in Section 3.3.4 of [RFC3985] 💖

The IEEE has defined several layers for Ethernet in [IEEE802.3]. Emulation operates at the physical (PHY) layer, more precisely at the PCS 🔧

Over time, a lot of different Ethernet interface types have been specified in [IEEE802.3], each with its own mix of characteristics, like optional versus mandatory FEC and single-lane versus multi-lane transmission. It's a whole zoo 🦁

Ethernet interface types with backplane PMD variants, and Ethernet interface types mandating auto-negotiation (except 1000Base-X), are out of scope for this document 🚫

All Ethernet services leverage the basic PLE payload, and interface-specific mechanisms are confined to the respective service-specific NSP functions 🫧

4.2.1. 1000BASE-X 🌟

The PCS layer of 1000BASE-X (defined in Section 36 of [IEEE802.3]) is based on 8B/10B code 🧩

The PSN-bound NSP function does not modify the received data and is transparent to auto-negotiation. However, it is responsible for detecting attachment circuit faults specific to 1000BASE-X, such as LOS and sync loss 👀

When the CE-bound IWF is in PLOS state, or when PLE packets are received with the L bit set, the CE-bound NSP function MAY disable its transmitter, since no appropriate maintenance signal was defined for 1000BASE-X by the IEEE 🙈

4.2.2. 10GBASE-R and 25GBASE-R 👑

The PCS layers of 10GBASE-R (defined in Section 49 of [IEEE802.3]) and 25GBASE-R (defined in Section 107 of [IEEE802.3]) are based on a 64B/66B code 💅

Sections 74 and 108 of [IEEE802.3] define an optional FEC layer. If it's present, the PSN-bound NSP function MUST terminate the FEC, and the CE-bound NSP function MUST generate the FEC 🔥

The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 10GBASE-R and 25GBASE-R, such as LOS and sync loss 🚨

The PSN-bound IWF maps the scrambled 64B/66B code stream into the basic PLE payload 🗺️

The CE-bound NSP function MUST perform:

  • PCS code sync (Section 49.2.9 of [IEEE802.3]) and
  • descrambling (Section 49.2.10 of [IEEE802.3])

in order to properly:

  • transform invalid 66B code blocks into proper error control characters /E/ (Section 49.2.4.11 of [IEEE802.3]) and
  • insert LF ordered sets (Section 46.3.4 of [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or the far-end PSN-bound NSP function setting sync headers to 11 due to uncorrectable FEC errors. 🧐

Before sending the bit-stream to the CE, the CE-bound NSP function MUST also scramble the 64B/66B code stream (Section 49.2.6 of [IEEE802.3]) 🔐

4.2.3. 40GBASE-R, 50GBASE-R, and 100GBASE-R 🦋

The PCS layers of 40GBASE-R and 100GBASE-R (defined in Section 82 of [IEEE802.3]), and of 50GBASE-R (defined in Section 133 of [IEEE802.3]), are based on a 64B/66B code transmitted over multiple lanes 🛤️

Sections 74 and 91 of [IEEE802.3] define an optional FEC layer. If it's present, the PSN-bound NSP function MUST terminate the FEC, and the CE-bound NSP function MUST generate the FEC 🔥

To gain access to the scrambled 64B/66B code stream, the PSN-bound NSP further MUST perform:

  • block synchronization (Section 82.2.12 of [IEEE802.3]),
  • PCS lane de-skew (Section 82.2.13 of [IEEE802.3]), and
  • PCS lane reordering (Section 82.2.14 of [IEEE802.3]).

The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 40GBASE-R, 50GBASE-R, and 100GBASE-R, such as LOS and loss of alignment 🔍

The PSN-bound IWF maps the serialized and scrambled 64B/66B code stream, including the alignment markers, into the basic PLE payload 🧵

The CE-bound NSP function MUST perform:

  • PCS code sync (Section 82.2.12 of [IEEE802.3]),
  • alignment-marker removal (Section 82.2.15 of [IEEE802.3]), and
  • descrambling (Section 49.2.10 of [IEEE802.3])

in order to properly:

  • transform invalid 66B code blocks into proper error control characters /E/ (Section 82.2.3.10 of [IEEE802.3]) and
  • insert LF ordered sets (Section 81.3.4 of [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors. 🧐

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

  • scrambling of the 64B/66B code (Section 49.2.6 of [IEEE802.3]),
  • block distribution (Section 82.2.6 of [IEEE802.3]), and
  • alignment-marker insertion (Sections 82.2.7 and 133.2.2 of [IEEE802.3]).

4.2.4. 200GBASE-R and 400GBASE-R ✨

Okay so the PCS layers of 200GBASE-R and 400GBASE-R (defined in Section 119 of [IEEE802.3]) are based on a 64B/66B code that gets transcoded into a 256B/257B code 🔥 Why? To cut down on overhead and make room for a mandatory FEC. Iconic engineering, honestly 💅

To get at the 64B/66B code stream, the PSN-bound NSP further MUST perform:

  • alignment lock and de-skew (Section 119.2.5.1 of [IEEE802.3]),
  • PCS lane reordering and de-interleaving (Section 119.2.5.2 of [IEEE802.3]),
  • FEC decoding (Section 119.2.5.3 of [IEEE802.3]),
  • post-FEC interleaving (Section 119.2.5.4 of [IEEE802.3]),
  • alignment-marker removal (Section 119.2.5.5 of [IEEE802.3]),
  • descrambling (Section 119.2.5.6 of [IEEE802.3]), and
  • reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of [IEEE802.3]).

Also, the PSN-bound NSP MUST perform rate compensation and scrambling (Section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF maps everything into the basic PLE payload 🎀

Rate compensation is the part that's giving math-brain energy 🤓 The rate of the 66B encoded bit-stream carried by PLE is 528/544 times the nominal bitrate of the 200GBASE-R or 400GBASE-R at the PMA service interface. X number of 66-byte-long rate compensation blocks get inserted every X*20479 number of 66B client blocks. For 200GBASE-R, the value of X is 16, and for 400GBASE-R, it's 32. These rate compensation blocks are special 66B control characters of type 0x00, so the CE-bound IWF can easily search for them and remove them 🦋

The PSN-bound NSP function is also responsible for detecting attachment circuit faults that are specific to 200GBASE-R and 400GBASE-R, like LOS and loss of alignment 👀

The CE-bound NSP function MUST perform:

  • PCS code sync (Section 49.2.13 of [IEEE802.3]),
  • descrambling (Section 49.2.10 of [IEEE802.3]), and
  • rate compensation block removal

so that it can properly:

  • transform invalid 66B code blocks into proper error control characters /E/ (Section 119.2.3.9 of [IEEE802.3]) and
  • insert LF ordered sets (Section 81.3.4 of [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
Note: Invalid 66B code blocks typically happen because the CE-bound IWF inserts replacement data when PLE packets get lost, or because the far-end PSN-bound NSP function doesn't set sync headers to 11 due to uncorrectable FEC errors. Plot twist, but it makes sense 🙈

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

  • transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of [IEEE802.3]),
  • scrambling (Section 119.2.4.3 of [IEEE802.3]),
  • alignment-marker insertion (Section 119.2.4.4 of [IEEE802.3]),
  • pre-FEC distribution (Section 119.2.4.5 of [IEEE802.3]),
  • FEC encoding (Section 119.2.4.6 of [IEEE802.3]), and
  • PCS lane distribution (Section 119.2.4.8 of [IEEE802.3]).

4.2.5. Energy Efficient Ethernet (EEE) 🌙

Section 78 of [IEEE802.3] defines the optional LPI capability for Ethernet. Two modes are defined:

  • deep sleep
  • fast wake

Deep sleep mode is not compatible with PLE, because the CE stops transmitting 😭 So there's no LPI support for 10GBASE-R services across PLE. Sad, but that's the vibe.

In fast wake mode, the CE transmits /LI/ control code blocks instead of /I/ control code blocks, so PLE doesn't even notice the difference 🧚 For 25GBASE-R and higher services across PLE, LPI is supported because only fast wake mode applies to them 💜

4.3. SONET/SDH Services 🍓

SONET/SDH services are special cases of the structured bit-stream defined in Section 3.3.4 of [RFC3985]. Cute and tidy.

SDH interfaces are defined in [G.707], and SONET interfaces are defined in [GR253].

The PSN-bound NSP function doesn't modify the received data. It's still responsible for detecting attachment circuit faults that are specific to SONET/SDH, like LOS, LOF, and OOF 🔍

Data received by the PSN-bound IWF gets mapped into the basic PLE payload with zero awareness of SONET/SDH frames. Chill, it just goes in 🫶

When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function is responsible for generating the:

  • MS-AIS maintenance signal (defined in Section 6.2.4.1.1 of [G.707]) for SDH services and
  • AIS-L maintenance signal (defined in Section 6.2.1.2 of [GR253]) for SONET services

at client-frame boundaries.

4.4. Fibre Channel Services 🌈

Fibre Channel services are special cases of the structured bit-stream defined in Section 3.3.4 of [RFC3985]. Same vibes as SONET/SDH, honestly 💅

The T11 technical committee of INCITS has defined several layers for Fibre Channel. PLE operates at the FC-1 layer, which leverages mechanisms defined by [IEEE802.3] ✨

Over time, a bunch of different Fibre Channel interface types have been specified, and they come with a whole mix of characteristics, like optional versus mandatory FEC and single-lane versus multi-lane transmission. So many options 💀

Speed negotiation is not supported by PLE.

All Fibre Channel services leverage the basic PLE payload, and the interface-specific mechanisms stay confined to the respective service-specific NSP functions 🦋

4.4.1. 1GFC, 2GFC, 4GFC, and 8GFC 🌸

[FC-PI-2] specifies 1GFC and 2GFC. [FC-PI-5] and [FC-PI-5am1] define 4GFC and 8GFC.

The PSN-bound NSP function is responsible for detecting attachment circuit faults that are specific to Fibre Channel, like LOS and sync loss.

The PSN-bound IWF maps the received 8B/10B code stream as is, straight into the basic PLE payload.

The CE-bound NSP function MUST perform transmission word sync so that it can properly:

  • replace invalid transmission words with the special character K30.7 and
  • insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
Note: Invalid transmission words typically happen because the CE-bound IWF inserts replacement data when PLE packets get lost. Relatable 🙈

[FC-PI-5am1] defines the use of scrambling for 8GFC. In this case, the CE-bound NSP MUST also perform descrambling before it replaces invalid transmission words or inserts NOS ordered sets. Before sending the bit-stream to the CE, the CE-bound NSP function MUST scramble the 8B/10B code stream 🔥

4.4.2. 16GFC 💜

[FC-PI-5] and [FC-PI-5am1] specify 16GFC and define an optional FEC layer.

If FEC is present, it must be indicated via TTS when the attachment circuit is brought up. Further, the PSN-bound NSP function MUST terminate the FEC, and the CE-bound NSP function must generate the FEC 🎀

The PSN-bound NSP function is responsible for detecting attachment circuit faults that are specific to Fibre Channel, like LOS and sync loss.

The PSN-bound IWF maps the received scrambled 64B/66B code stream as is into the basic PLE payload.

The CE-bound NSP function MUST perform:

  • transmission word sync (Section 49.2.13 of [IEEE802.3]) and
  • descrambling (Section 49.2.10 of [IEEE802.3])

so that it can properly:

  • replace invalid transmission words with the error transmission word 1Eh and
  • insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
Note: Invalid transmission words typically happen because the CE-bound IWF inserts replacement data when PLE packets get lost, or because the far-end PSN-bound NSP function doesn't set sync headers to 11 due to uncorrectable FEC errors.

Before sending the bit-stream to the CE, the CE-bound NSP function MUST also scramble the 64B/66B code stream (Section 49.2.6 of [IEEE802.3]) 🧚

4.4.3. 32GFC and 4-Lane 128GFC 🦋

[FC-PI-6] specifies 32GFC, and [FC-PI-6P] specifies 4-lane 128GFC. Both come with FEC layer and TTS support being mandatory, so no skipping that part 👑

To gain access to the 64B/66B code stream, the PSN-bound NSP further MUST perform:

  • descrambling (Section of 49.2.10 of [IEEE802.3]),
  • FEC decoding (Section 91.5.3.3 of [IEEE802.3]), and
  • reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of [IEEE802.3]).

Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF maps the same into the basic PLE payload.

The PSN-bound NSP function is also responsible for detecting attachment circuit faults that are specific to Fibre Channel, like LOS and sync loss.

The CE-bound NSP function MUST perform:

  • transmission word sync (Section 119.2.6.3 of [IEEE802.3]) and
  • descrambling (Section 49.2.10 of [IEEE802.3])

so that it can properly:

  • replace invalid transmission words with the error transmission word 1Eh and
  • insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
Note: Invalid transmission words typically happen because the CE-bound IWF inserts replacement data when PLE packets get lost, or because the far-end PSN-bound NSP function doesn't set sync headers to 11 due to uncorrectable FEC errors.

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

  • transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of [IEEE802.3]),
  • FEC encoding (Section 91.5.2.7 of [IEEE802.3]), and
  • scrambling (Section 49.2.6 of [IEEE802.3]).

4.4.4. 64GFC 🌟

[FC-PI-7] specifies 64GFC with a mandatory FEC layer. Big speed, big responsibilities ⚡

To gain access to the 64B/66B code stream, the PSN-bound NSP further MUST perform:

  • alignment lock (Section 134.5.4 of [IEEE802.3] modified to single FEC lane operation),
  • FEC decoding (Section 134.5.3.3 of [IEEE802.3]),
  • alignment-marker removal (Section 134.5.3.4 of [IEEE802.3]), and
  • reverse transcoding from 256B/257B to 64B/66B (Section 91.5.3.5 of [IEEE802.3]).

Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF maps the same into the basic PLE payload.

The PSN-bound NSP function is also responsible for detecting attachment circuit faults that are specific to Fibre Channel, like LOS and sync loss.

The CE-bound NSP function MUST perform:

  • transmission word sync (Section 49.2.13 of [IEEE802.3]) and
  • descrambling (Section 49.2.10 of [IEEE802.3])

so that it can properly:

  • replace invalid transmission words with the error transmission word 1Eh and
  • insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
Note: Invalid transmission words typically happen because the CE-bound IWF inserts replacement data when PLE packets get lost, or because the far-end PSN-bound NSP function doesn't set sync headers to 11 due to uncorrectable FEC errors.

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

  • transcoding from 64B/66B to 256B/257B (Section 91.5.2.5 of [IEEE802.3]),
  • alignment-marker insertion (Section 134.5.2.6 of [IEEE802.3]), and
  • FEC encoding (Section 134.5.2.7 of [IEEE802.3]).

4.5. OTN Services 🦋

okay so OTN services are basically special cases of the structured bit-stream from Section 3.3.4 of [RFC3985] 💅

OTN interfaces are defined in [G.709] 🌸

The PSN-bound NSP function MUST terminate the FEC and replace the OTUk overhead in row 1, columns 8-14 with an all-zeros pattern. bestie, this gives you an extended ODUk frame, which you can see in Figure 3 ✨ The frame alignment overhead (FA OH) in row 1, columns 1-7 stays exactly as it is 🫶

                                   column #
       1      7 8     14 15                                      3824
      +--------+--------+------------------- .. --------------------+
     1|  FA OH | All-0s |                                           |
      +--------+--------+                                           |
   r 2|                 |                                           |
   o  |                 |                                           |
   w 3|  ODUk overhead  |                                           |
   #  |                 |                                           |
     4|                 |                                           |
      +-----------------+------------------- .. --------------------+

                       Figure 3: Extended ODUk Frame

The PSN-bound NSP function is also in charge of detecting attachment circuit faults specific to OTUk, like LOS, LOF, LOM, and AIS 🔥

The PSN-bound IWF maps the extended ODUk frame into the byte-aligned PLE payload 🧚

The CE-bound NSP function recovers the ODUk by searching for the frame alignment overhead in the extended ODUk it gets from the CE-bound IWF, and then it generates the FEC 💜

When the CE-bound IWF is in PLOS state, or when PLE packets come in with the L bit set, the CE-bound NSP function is responsible for generating the ODUk-AIS maintenance signal defined in Section 16.5.1 of [G.709] at client-frame boundaries. it's giving responsibility 👑

5. PLE Encapsulation Layer 🧚

The basic packet format used by PLE is shown in Figure 4, and it's a whole vibe 🌈

   +-------------------------------+  -+
   |     PSN and VPWS Demux        |    \
   |          (MPLS/SRv6)          |     > PSN and VPWS
   |                               |    /  Demux Headers
   +-------------------------------+  -+
   |        PLE Control Word       |    \
   +-------------------------------+     > PLE Header
   |           RTP Header          |    /
   +-------------------------------+ --+
   |          Bit-Stream           |    \
   |           Payload             |     > Payload
   |                               |    /
   +-------------------------------+ --+

                     Figure 4: PLE Encapsulation Layer

5.1. PSN and VPWS Demultiplexing Headers 💖

ok so this document doesn't suggest any specific technology for implementing the VPWS demultiplexing and PSN layers. you get to pick 🎀

The total size of a PLE packet for a specific PW MUST NOT exceed the path MTU between the pair of PEs terminating this PW. no going over, periodt 🚫

When an MPLS PSN layer is used, a VPWS label provides the demultiplexing mechanism (as described in Section 5.4.2 of [RFC3985]). The PSN tunnel can be a simple best-path LSP set up using LDP (see [RFC5036]) or Segment Routing (SR) (see [RFC8402]). Or it can be a traffic-engineered LSP set up using RSVP-TE (see [RFC3209]) or SR policies (see [RFC9256]). so many options, it's giving buffet 🍓

When an SRv6 PSN layer is used, an SRv6 service SID (as defined in [RFC8402]) provides the demultiplexing mechanism, and the definitions of Section 6 of [RFC9252] apply. Both SRv6 service SIDs with the full IPv6 address format defined in [RFC8986] and CSIDs with the format defined in [RFC9800] can be used 🦋

5.1.1. New SRv6 Behaviors 🎀

Two new encapsulation behaviors, H.Encaps.L1 and H.Encaps.L1.Red, are defined in this document. The behavior procedures apply to both SIDs and CSIDs, so no extra work for you bestie 💅

The H.Encaps.L1 behavior encapsulates a frame received from an IWF in an IPv6 packet with a segment routing header (SRH). The received frame becomes the payload of the new IPv6 packet 🧚

  • The next header field of the SRH or the last extension header present MUST be set to 147.
  • The insertion of the SRH MAY be omitted per [RFC8986] when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.

The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior, and it's so efficient 🌸

  • H.Encaps.L1.Red reduces the length of the SRH by excluding the first SID in the SRH. The first SID is only placed in the Destination Address field of the IPv6 header.
  • The insertion of the SRH MAY be omitted per [RFC8986] when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.

Three new "Endpoint with decapsulation and bit-stream cross-connect" behaviors, called End.DX1, End.DX1 with NEXT-CSID, and End.DX1 with REPLACE-CSID, are defined in this document. These new behaviors are variants of End.DX2 defined in [RFC8986], and they all share the following procedures 🔥

The End.DX1 SID MUST be the last segment in an SR Policy, and it is associated with a CE-bound IWF I. When N receives a packet destined to S and S is a local End.DX1 SID, N does the following:

S01. When an SRH is processed {
S02.   If (Segments Left != 0) {
S03.     Send an ICMP Parameter Problem to the Source Address
         with Code 0 (Erroneous header field encountered)
         and Pointer set to the Segments Left field,
         interrupt packet processing, and discard the packet.
S04.   }
S05.   Proceed to process the next header in the packet
S06. }

When processing the next (Upper-Layer) header of a packet matching a FIB entry locally instantiated as an End.DX1 SID, N does the following:

S01. If (Upper-Layer header type == 147 (bit-stream) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Forward the remaining frame to the IWF I
S04. } Else {
S05.    Process as per {{Section 4.1.1 of RFC 8986}}
S06. }

5.2. PLE Header 🍓

The PLE header MUST contain the PLE control word (4 bytes) and MUST include a fixed-size RTP header [RFC3550]. The RTP header MUST immediately follow the PLE control word. the order is non-negotiable, bestie 🫶

5.2.1. PLE Control Word 💜

The format of the PLE control word is in line with the guidance in [RFC4385] and is shown in Figure 5 ✨

 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|L|R|RSV|FRG|   LEN     |       Sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5: PLE Control Word

The bits 0..3 of the first nibble are set to 0 to tell a control word or ACH apart from an IP packet or Ethernet frame. The first nibble MUST be set to 0000b to indicate that this header is a control word as defined in Section 3 of [RFC4385]. the zeros are doing the heavy lifting here 🙈

The other fields in the control word are used as defined below:

L: Set by the PE to indicate that data carried in the payload is invalid due to an attachment circuit fault. The downstream PE MUST send appropriate replacement data. The NSP MAY inject an appropriate downstream fault-indication signal. 😭

R: Set by the downstream PE to indicate that the IWF experiences packet loss from the PSN, or that a server layer backward fault indication is present in the NSP. The R bit MUST be cleared by the PE once the packet loss state or fault indication has cleared. 💀

RSV: These bits are reserved for future use. This field MUST be set to zero by the sender and ignored by the receiver. 🌙

FRG: These bits MUST be set to zero by the sender and ignored by the receiver, as PLE does not use payload fragmentation. no fragging here 🙅

LEN: In accordance with Section 3 of [RFC4385], the length field MUST always be set to zero, as there is no padding added to the PLE packet. The size of the PLE payload MUST be assumed to be as described in Section 6. If the actual packet size is inconsistent with this, the packet MUST be considered malformed. it's giving strict 😤

Sequence number: The sequence number field is used to provide a common PW sequencing function, as well as detection of lost packets. It MUST be generated in accordance with the rules defined in Section 5.1 of [RFC3550] and MUST be incremented with every PLE packet being sent. counting up, no skipping 🔢

5.2.2. RTP Header 🦋

The RTP header MUST be included to explicitly convey timing information. timing is everything, bestie ⏰

The RTP header (as defined in [RFC3550]) is reused to align with other bit-stream emulation pseudowires defined by [RFC4553], [RFC5086], and [RFC4842], and to allow PLE implementations to reuse preexisting work. why reinvent the wheel when you can just slay it 🛞

There is no intention to support full RTP topologies and protocol mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTCP, RTP header compression, SRTP, etc., as these are not applicable to PLE VPWS. we're keeping it lean 🌿

The format of the RTP header is as shown in Figure 6 💅

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Synchronization Source (SSRC) Identifier            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 6: RTP Header

V: Version

The version field MUST be set to 2. two, always two 👑

P: Padding

The padding flag MUST be set to zero by the sender and ignored by the receiver. 🙃

X: Header extension

The X bit MUST be set to zero by sender and ignored by receiver. no extensions, we're chill 🧊

CC: CSRC count

The CC field MUST be set to zero by the sender and ignored by the receiver. 0️⃣

M: Marker

The M bit MUST be set to zero by the sender and ignored by the receiver. 🤐

PT: Payload type

A PT value MUST be allocated from the range of dynamic values defined in Section 6 of [RFC3551] for each direction of the VPWS. The same PT value MAY be reused for both for directions and between different PLE VPWSs. 🎟️

The PT field MAY be used for detection of misconnections. 🕵️‍♀️

Sequence number: When using a 16-bit sequence number space, the sequence number in the RTP header MUST be equal to the sequence number in the PLE control word. When using a sequence number space of 32 bits, the initial value of the RTP sequence number MUST be 0 and incremented whenever the PLE control word sequence number cycles through from 0xFFFF to 0x0000. the rollover moment is literally iconic 🌈

Timestamp: Timestamp values are used in accordance with the rules established in [RFC3550]. For bit-streams up to 200 Gbps, the frequency of the clock used for generating timestamps MUST be 125 MHz, based on a the common clock I. For bit-streams above 200 Gbps, the frequency MUST be 250 MHz. ⏱️✨

SSRC: Synchronization source

The SSRC field MAY be used for detection of misconnections. 🕵️‍♀️💖

6. PLE Payload Layer 🎀

okay bestie, so the bit-stream gets packed into a PLE packet with a fixed payload size 🫶 That size MUST be defined during VPWS setup, MUST be the same in both directions of the VPWS, and MUST remain unchanged for the lifetime of the VPWS. no cap, it cannot wiggle around mid-call 💅

Every PLE implementation MUST be capable of supporting the default payload size of 1024 bytes ✨ The payload size SHOULD be configurable so it can match specific packetization delay and overhead expectations 🧚 The smallest payload size you can use is 64 bytes 🍓

6.1. Basic Payload

the payload just gets filled with incoming bits of the bit-stream, starting at the most significant bit and going down to the least significant bit. it doesn't care about any structure in the bit-stream, it's giving raw vibes 🌊

6.2. Byte-Aligned Payload

this one is more organized 🎀 The payload gets filled byte by byte, and the order of the payload bytes matches their order on the attachment circuit. Consecutive bits from the attachment circuit fill each payload byte, starting from the most significant bit and ending at the least significant bit. The PLE payload size MUST be an integer number of bytes 💖

7. PLE Operation 💜

7.1. Common Considerations

a PLE VPWS can be set up with manual configuration, or by using mechanisms from a signaling protocol ✨

emulating bit-stream signals with PLE only works when both attachment circuits of the VPWS are the same service type (OC192, 10GBASE-R, ODU2, etc.) and use the same PLE payload type and payload size. You can make sure of this with manual configuration or with the mechanisms of a signaling protocol 🔥

PLE-related control protocol extensions to LDP [RFC8077] or EVPN-VPWS [RFC8214] are out of scope for this document 🙈

Extensions for EVPN-VPWS are proposed in [EVPN-VPWS], and extensions for LDP are proposed in [LDP-PLE] 💅

7.2. PLE IWF Operation

7.2.1. PSN-Bound Encapsulation Behavior

after the VPWS is set up, the PSN-bound IWF does the following 🫶

  • Packetize the data received from the CE into PLE payloads, all of the same configured size,
  • Add a PLE control word and an RTP header, with sequence numbers, flags, and timestamps properly set,
  • Add the VPWS demultiplexer and PSN headers,
  • Transmit the resulting packets over the PSN,
  • Set the L bit in the PLE control word whenever the attachment circuit detects a fault, and
  • Set the R bit in the PLE control word whenever the local CE-bound IWF is in packet loss state.

7.2.2. CE-Bound Decapsulation Behavior

the CE-bound IWF is the one that removes the PSN and VPWS demultiplexing headers, the PLE control word, and the RTP header from the received packet stream, then sends the bit-stream out through the local attachment circuit 🦋

A de-jitter buffer MUST be implemented, and that's where PLE packets get stored when they arrive. Its size SHOULD be locally configurable so it can handle the specific PSN PDV you expect 🌸

The CE-bound IWF SHOULD use the sequence number in the control word to detect lost and misordered packets. It MAY use the sequence number in the RTP header for the same job. The CE-bound IWF MAY support reordering of packets that arrive out of order. If the CE-bound IWF does not support reordering, it MUST drop the misordered packets 👀

The payload of a lost or dropped packet MUST be replaced with an equal amount of replacement data. The contents of that replacement data MAY be locally configurable. By default, every PLE implementation MUST support generating 0xAA as replacement data. The alternating pattern of 0s and 1s in 0xAA keeps clock synchronization going and, for 64B/66B code-based services, makes sure no invalid sync headers get generated 🧠 While the replacement data is being sent out, the IWF applies a holdover mechanism to maintain the clock ⭐

Whenever the VPWS is not operationally up, the CE-bound NSP function MUST inject the appropriate downstream fault-indication signal 🚨

Whenever a VPWS comes up, the CE-bound IWF enters the intermediate state, starts receiving PLE packets, and stores them in the jitter buffer. The CE-bound NSP function keeps injecting the appropriate downstream fault-indication signal until a preconfigured number of payload is stored in the jitter buffer 🌈

Once the preconfigured amount of payload is sitting in the jitter buffer, the CE-bound IWF moves into the normal operation state, and the jitter buffer contents get streamed out to the CE according to the required clock. In this state, the CE-bound IWF MUST perform egress clock recovery 👑

Things to consider when choosing the preconfigured amount of payload needed to move into the normal state:

  • It's typically set to 50% of the de-jitter buffer size, so it can equally compensate for increasing and decreasing delay.
  • It's a compromise between the maximum amount of tolerable PDV and the delay introduced to the emulated service.

The recovered clock MUST comply with the jitter and wander requirements that apply to the type of attachment circuit, as specified in:

  • [G.825], [G.783], and [G.823] for SDH
  • [GR253] and [GR499] for SONET
  • [G.8261] for synchronous Ethernet
  • [G.8251] for OTN

Whenever the L bit is set in the PLE control word of a received PLE packet, the CE-bound NSP function SHOULD inject the appropriate downstream fault-indication signal instead of streaming out the payload 🙈

If the CE-bound IWF detects loss of consecutive packets for a preconfigured amount of time (the default is 1 millisecond), it enters the PLOS state and a corresponding defect is declared 😭

If the CE-bound IWF detects a PLR above a configurable SD threshold for a configurable number of consecutive 1-second intervals, it enters the DEG state and a corresponding defect is declared. The SD-PLR threshold can be defined as a percentage, with the default being 15%, or as an absolute packet count for finer granularity on higher-rate interfaces. Possible values for consecutive intervals are 2..10, with the default being 7 🫧

While the PLOS defect is declared, the CE-bound NSP function MUST inject the appropriate downstream fault-indication signal. If the emulated service doesn't have an appropriate maintenance signal defined, the CE-bound NSP function MAY disable its transmitter instead. Also, the PSN-bound IWF SHOULD set the R bit in the PLE control word of every packet it transmits 💀

The CE-bound IWF moves from the PLOS state back to the normal state once the preconfigured amount of payload has been received, similar to the move from intermediate to normal state 🦋

Whenever the R bit is set in the PLE control word of a received PLE packet, the PLE performance monitoring statistics SHOULD get updated 📊

7.3. PLE Performance Monitoring

attachment circuit performance monitoring SHOULD be provided by the NSP. The performance monitors are service-specific, documented in related specifications, and beyond the scope of this document 🧚

The PLE IWF SHOULD provide functions to monitor network performance so it lines up with what transport network operators expect 👑

The near-end performance monitors defined for PLE are:

  • ES-PLE : PLE Errored Seconds
  • SES-PLE : PLE Severely Errored Seconds
  • UAS-PLE : PLE Unavailable Seconds

Each second with at least one packet lost, or with a PLOS or DEG defect, SHALL be counted as an ES-PLE. Each second with a PLR greater than 15% or with a PLOS or DEG defect SHALL be counted as an SES-PLE 📉

UAS-PLE SHALL be counted after a configurable number of consecutive SES-PLEs have been observed, and it stops being counted after a configurable number of consecutive seconds without an SES-PLE have been observed. The default for each is 10 seconds ⏱️

Once unavailability is detected, the ES-PLE and SES-PLE counts SHALL be inhibited up to the point where the unavailability started. Once unavailability is removed, the ES-PLE and SES-PLE counts from the clearing period SHALL be added to the ES-PLE and SES-PLE counts 🌸

A PLE far-end performance monitor gives insight into the CE-bound IWF at the far end of the PSN. The statistics are based on the PLE-RDI indication carried in the PLE control word via the R bit 🫶

The PLE VPWS performance monitors are derived from the definitions in accordance with [G.826] ✨

Performance monitoring data MUST be provided by the management interface and SHOULD be provided by a YANG data model. The YANG data model specification is out of scope for this document 💜

7.4. PLE Fault Management

attachment circuit faults that apply to PLE are detected by the NSP, are service-specific, and are documented in Section 4 🔍

The two PLE faults, PLOS and DEG, are detected by the IWF 🚨

Faults MUST be timestamped as they are declared and cleared. Fault-related information MUST be provided by the management interface and SHOULD be provided by a YANG data model. The YANG data model specification is out of scope for this document 🫧

8. QoS and Congestion Control 🍓

the PSN carrying a PLE VPWS may be subject to congestion. Congestion considerations for PWs are described in Section 6.5 of [RFC3985] 🌊

PLE VPWS represent inelastic CBR flows. They can't respond to congestion in a TCP-friendly manner (as described in [RFC2914]), and they're sensitive to jitter, packet loss, and packets received out of order 😭

the PSN providing connectivity between the PE devices of a PLE VPWS has to ensure low jitter and low loss. The exact mechanisms used are beyond the scope of this document and may evolve over time. Possible options, though not an exhaustive list, are:

  • a Diffserv-enabled [RFC2475] PSN with a per-domain behavior (see [RFC3086]) that supports Expedited Forwarding (see [RFC3246]),
  • traffic-engineered paths through the PSN with bandwidth reservation and admission control applied, or
  • capacity over-provisioning 🚀

9. Security Considerations 🔐

okay bestie, PLE is using VPWS as its transport mechanism, so the security considerations in [RFC3985] totally apply 💅

PLE doesn't make the security of the underlying PSN better or worse 🫶 It leans on the PSN's own mechanisms for encryption, integrity, and authentication whenever those are needed.

The PSN (MPLS or SRv6) is assumed to be trusted and secure ✨ If an attacker manages to sneak spoofed packets into the PSN, they could easily mess up the PLE service 😭 This MUST be prevented by following best practices for isolating the PSN. You can find those protections in Section 3.4 of [RFC4381], Section 4.2 of [RFC5920], Section 8 of [RFC8402], and Section 9.3 of [RFC9252].

PLE PWs are susceptible to a bunch of pseudowire-layer attacks, same as everyone else 🥀 They'll use whatever confidentiality, integrity, and authentication mechanisms get developed for general PWs. Those methods are beyond the scope of this document, so that's a different story 📖

Random initialization of sequence numbers, in both the control word and the RTP header, makes known-plaintext attacks harder 🔒 Main character defense, honestly.

Misconnection detection using the SSRC and/or PT field of the RTP header can boost resilience against misconfiguration and some types of denial-of-service (DoS) attacks 🛡️ Randomly chosen expected values lower the chances of a spoofing attack working, which is so iconic.

A data plane attack can force PLE packets to be dropped, reordered, or delayed past the limit of the CE-bound IWF's dejitter buffer 💀 That can lead to degradation or a full service disruption. [RFC9055] is a really good reference for this one 📚

Clock synchronization using PTP is sensitive to PDV and vulnerable to a bunch of threats and attack vectors 😩 Keep the considerations in [RFC7384] in mind, and they should be taken into account 🫶

10. IANA Considerations 📋

10.1. Bit-Stream Next Header Type 🌸

This document introduces a new value for the next header field of an IPv6 header, or any extension header, that tells you the payload is an emulated bit-stream 🦋 IANA has assigned the following from the "Assigned Internet Protocol Numbers" registry [IANA-Proto].

+=========+=========+============+================+===========+
| Decimal | Keyword | Protocol   | IPv6 Extension | Reference |
|         |         |            | Header         |           |
+=========+=========+============+================+===========+
| 147     | BIT-EMU | Bit-stream | Y              | RFC 9801  |
|         |         | Emulation  |                |           |
+---------+---------+------------+----------------+-----------+

Table 1

10.2. SRv6 Endpoint Behaviors 🧚

This document introduces three new SRv6 Endpoint behaviors ✨ IANA has assigned identifier values for them in the "SRv6 Endpoint Behaviors" registry, under the "Segment Routing" registry group [IANA-SRv6-End].

+=======+========+===========================+===========+
| Value | Hex    | Endpoint Behavior         | Reference |
+=======+========+===========================+===========+
| 158   | 0x009E | End.DX1                   | RFC 9801  |
+-------+--------+---------------------------+-----------+
| 159   | 0x009F | End.DX1 with NEXT-CSID    | RFC 9801  |
+-------+--------+---------------------------+-----------+
| 160   | 0x00A0 | End.DX1 with REPLACE-CSID | RFC 9801  |
+-------+--------+---------------------------+-----------+

Table 2

11. References 📚

11.1. Normative References 💜

[G.707] ITU-T, "Network node interface for the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.707, January 2007, https://www.itu.int/rec/T-REC-G.707.

[G.709] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, June 2020, https://www.itu.int/rec/T-REC-G.709.

[G.783] ITU-T, "Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks", ITU-T Recommendation G.783, March 2006, https://www.itu.int/rec/T-REC-G.783.

[G.823] ITU-T, "The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy", ITU-T Recommendation G.823, March 2000, https://www.itu.int/rec/T-REC-G.823.

[G.825] ITU-T, "The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.825, March 2000, https://www.itu.int/rec/T-REC-G.825.

[G.8251] ITU-T, "The control of jitter and wander within the optical transport network (OTN)", ITU-T Recommendation G.8251, November 2022, https://www.itu.int/rec/T-REC-G.8251.

[G.8261] ITU-T, "Timing and synchronization aspects in packet networks", ITU-T Recommendation G.8261, August 2019, https://www.itu.int/rec/T-REC-G.8261.

[G.8261.1] ITU-T, "Packet delay variation network limits applicable to packet-based methods (Frequency synchronization)", ITU-T Recommendation G.8261.1, February 2012, https://www.itu.int/rec/T-REC-G.8261.1.

[G.8262] ITU-T, "Timing characteristics of synchronous equipment clocks", ITU-T Recommendation G.8262, October 2024, https://www.itu.int/rec/T-REC-G.8262.

[G.8265.1] ITU-T, "Precision time protocol telecom profile for frequency synchronization", ITU-T Recommendation G.8265.1, November 2022, https://www.itu.int/rec/T-REC-G.8265.1.

[GR253] Telcordia, "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", GR-253, October 2009, https://telecom-info.njdepot.ericsson.net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-253.

[GR499] Telcordia, "Transport Systems Generic Requirements (TSGR) - Common Requirements", GR-499, November 2009, https://telecom-info.njdepot.ericsson.net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-499.

[IANA-Proto] IANA, "Assigned Internet Protocol Numbers", https://www.iana.org/assignments/protocol-numbers.

[IANA-SRv6-End] IANA, "SRv6 Endpoint Behaviors", https://www.iana.org/assignments/segment-routing.

[IEEE802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022, DOI 10.1109/IEEESTD.2022.9844436, July 2022, https://ieeexplore.ieee.org/document/9844436.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, https://www.rfc-editor.org/info/rfc3550.

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, https://www.rfc-editor.org/info/rfc3551.

[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, https://www.rfc-editor.org/info/rfc3985.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, https://www.rfc-editor.org/info/rfc8402.

[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, https://www.rfc-editor.org/info/rfc8986.

[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, https://www.rfc-editor.org/info/rfc9252.

[RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, June 2025, https://www.rfc-editor.org/info/rfc9800.

11.2. Informative References 📚✨

Okay bestie, here's the reading list 🤓 These are the "good to know" refs, the ones the spec leans on for background but doesn't make you implement. Every one is listed with its full details, so you can go find it yourself 🔍

Acknowledgements 🫶

The authors want to thank Alexander Vainshtein, Yaakov Stein, Erik van Veelen, Faisal Dada, Giles Heron, Luca Della Chiesa, and Ashwin Gumaste for their early contributions, review, comments, and suggestions. Iconic squad 👑

Special thank you to:

  • Carlos Pignataro and Nagendra Kumar Nainar for giving the authors new-to-the-IETF guidance on how to get started 🌸
  • Stewart Bryant for being our shepherd 🐑
  • Tal Mizahi, Joel Halpern, Christian Huitema, Tony Li, and Tommy Pauly for their reviews and suggestions during Last Call 💅
  • Andrew Malis and Gunter van de Velde for their guidance through the process ✨

Contributors 🌈

  • Andreas Burk, 1&1 Versatel, Email: andreas.burk@magenta.de
  • Faisal Dada, AMD, Email: faisal.dada@amd.com
  • Gerald Smallegange, Ciena Corporation, Email: gsmalleg@ciena.com
  • Erik van Veelen, Aimvalley, Email: erik.vanveelen@aimvalley.com
  • Luca Della Chiesa, Cisco Systems, Inc., Email: ldellach@cisco.com
  • Nagendra Kumar Nainar, Cisco Systems, Inc., Email: naikumar@cisco.com
  • Carlos Pignataro, Blue Fern Consulting, Email: Carlos@Bluefern.consulting

Authors' Addresses 💌

  • Steven Gringeri, Verizon, Email: steven.gringeri@verizon.com
  • Jeremy Whittaker, Verizon, Email: jeremy.whittaker@verizon.com
  • Nicolai Leymann, Deutsche Telekom, Email: N.Leymann@telekom.de
  • Christian Schmutzer (editor), Cisco Systems, Inc., Email: cschmutz@cisco.com
  • Chris Brown, Ciena Corporation, Email: cbrown@ciena.com
📦 where this page comes from