Private Line Emulation over Packet Switched Networks
Internet-Draft draft-ietf-pals-ple-06
Steven Gringeri
Verizon
steven.gringeri@verizon.com
Jeremy Whittaker
Verizon
jeremy.whittaker@verizon.com
Nicolai Leymann
Deutsche Telekom
N.Leymann@telekom.de
Christian Schmutzer, Ed.
Cisco Systems, Inc.
cschmutz@cisco.com
Chris Brown
Ciena Corporation
cbrown@ciena.com
06 July 2024
This document describes methods and requirements for implementing the encapsulation of high-speed bit-streams into virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency.
Introduction and Motivation
This document describes a method called Private Line Emulation (PLE) for encapsulating high-speed bit-streams as Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN). This emulation suits applications where signal transparency is required and data or framing structure interpretation of the PE would be counter productive.
One example is two Ethernet connected CE devices and the need for Synchronous Ethernet operation between them without the intermediate PE devices interfering or addressing concerns about Ethernet control protocol transparency for carrier Ethernet services, beyond the behavior definitions of Metro Ethernet Forum (MEF) specifications.
Another example would be a Storage Area Networking (SAN) extension between two data centers. Operating at a bit-stream level allows for a connection between Fibre Channel switches without interfering with any of the Fibre Channel protocol mechanisms.
Also SONET/SDH add/drop multiplexers or cross-connects can be interconnected without interfering with the multiplexing structures and networks mechanisms. This is a key distinction to Circuit Emulation over Packet (CEP) defined in [RFC4842] where demultiplexing and multiplexing is desired in order to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual Container (VC). Said in another way, PLE does provide an independent layer network underneath the SONET/SDH layer network, whereas CEP does operate at the same level and peer with the SONET/SDH layer network.
The mechanisms described in this document follow principles similar to Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) defined in [RFC4553]. The applicability is expanded beyond the narrow set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are treated as bit-stream payload which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4.
Requirements Notation
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.
Terminology and Reference Model
Terminology
- ACH - Associated Channel Header
- AIS - Alarm Indication Signal
- AIS-L - Line AIS
- MS-AIS - Multiplex Section AIS
- BITS - Building Integrated Timing Supply
- CBR - Constant Bit Rate
- CE - Customer Edge
- CEP - Circuit Emulation over Packet
- CSRC - Contributing SouRCe
- DEG - Degradation
- ES - Errored Second
- FEC - Forward Error Correction
- ICMP - Internet Control Message Protocol
- IEEE - Institute of Electrical and Electronics Engineers
- INCITS - InterNational Committee for Information Technology Standards
- IWF - InterWorking Function
- LDP - Label Distribution Protocol
- LF - Local Fault
- LOF - Loss Of Frame
- LOM - Loss Of Multiframe
- LOS - Loss Of Signal
- LPI - Low Power Idle
- LSP - Label Switched Path
- MEF - Metro Ethernet Forum
- MPLS - Multi Protocol Label Switching
- NOS - Not Operational
- NSP - Native Service Processor
- ODUk - Optical Data Unit k
- 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 Ratio
- PMA - Physical Medium Attachment
- PMD - Physical Medium Dependent
- PSN - Packet Switched Network
- PTP - Precision Time Protocol
- PW - Pseudowire
- PWE3 - Pseudo Wire Emulation Edge-to-Edge
- P2P - Point-to-Point
- QOS - Quality Of Service
- RDI - Remote Defect Indication
- RSVP-TE - Resource Reservation Protocol Traffic Engineering
- RTCP - RTP Control Protocol
- RTP - Realtime Transport Protocol
- SAN - Storage Area Network
- SAToP - Structure-Agnostic Time Division Multiplexing (TDM) over Packet
- SD - Signal Degrade
- SES - Severely Errored Second
- SDH - Synchronous Digital Hierarchy
- SID - Segment Identifier
- SPE - Synchronous Payload Envelope
- SRH - Segment Routing Header
- SR-TE - Segment Routing Traffic Engineering
- SRTP - Secure Realtime Transport Protocol
- SRv6 - Segment Routing over IPv6 Dataplane
- SSRC - Synchronization SouRCe
- SONET - Synchronous Optical Network
- TCP - Transmission Control Protocol
- TDM - Time Division Multiplexing
- TTS - Transmitter Training Signal
- UAS - Unavailable Second
- VPWS - Virtual Private Wire Service
- VC - Virtual Circuit
- VT - Virtual Tributary
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.
Reference Models
The reference model for PLE is illustrated in Figure 1 and is inline with the reference model defined in Section 4.1 of [RFC3985]. PLE does rely on PWE3 pre-processing, in particular the concept of a Native Service Processing (NSP) function defined in Section 4.2.2 of [RFC3985].
PLE Reference Model

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

PLE embraces the minimum intervention principle outlined in Section 3.3.5 of [RFC3985] whereas the data is flowing through the PLE encapsulation layer as received without modifications.
For some service types the NSP function is responsible for performing operations on the native data received from the CE. Examples are terminating Forward Error Correction (FEC), terminating the OTUk layer for OTN or dealing with multi-lane processing. After the NSP the IWF is generating the payload of the VPWS which is carried via a PSN tunnel.
To allow the clock of the transported signal to be carried across the PLE domain in a transparent way the relative network synchronization reference model and deployment scenario outlined in Section 4.3.2 of [RFC4197] are applicable and are shown in Figure 2.
Relative Network Scenario Timing

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

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 via a differential clock recovery method in reference 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.
For the reverse direction PE1 does generate the attachment circuit clock J and the clock difference between G and D (locked to I) transferred from PE2 to PE1.
The method used to lock clocks C and D to the common clock I is out of scope of this document, but there are already several well established concepts for achieving frequency synchronization available.
While using external timing inputs (aka BITS) or synchronous Ethernet as defined in [G.8261] the characteristics and limits defined in [G.8262] have to be considered.
While relying on precision time protocol (PTP) as defined in [G.8265.1], the network limits defined in [G.8261.1] have to be considered.
Emulated Services
This specification does describe the emulation of services from a wide range of technologies such as TDM, Ethernet, Fibre Channel or OTN as bit stream or structured bit stream as defined in Section 3.3.3 of [RFC3985] and Section 3.3.4 of [RFC3985].
Generic PLE Service
The generic PLE service is an example of the bit stream defined in Section 3.3.3 of [RFC3985].
Under the assumption that the CE-bound IWF is not 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.
Ethernet services
Ethernet services are special cases of the structured bit stream defined in Section 3.3.4 of [RFC3985].
IEEE has defined several layers for Ethernet in [IEEE802.3]. Emulation is operating at the physical (PHY) layer, more precisely at the Physical Subcoding Layer (PCS).
Over time many different Ethernet interface types have been specified in [IEEE802.3] with a varying set of characteristics such as optional vs mandatory FEC and single-lane vs multi-lane transmission.
Ethernet interfaces types with backplane physical media dependent (PMD) variants and ethernet interface types mandating auto-negotiation (except 1000Base-X) are out of scope for this document.
All Ethernet services are leveraging the basic PLE payload and interface specific mechanisms are confined to the respective service specific NSP functions.
1000BASE-X
The PCS layer of 1000BASE-X defined in clause 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 but is responsible to detect 1000BASE-X specific attachment circuit faults 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 being set, the CE-bound NSP function MAY disable its transmitter as no appropriate maintenance signal was defined for 1000BASE-X by IEEE.
10GBASE-R and 25GBASE-R
The PCS layers of 10GBASE-R defined in clause 49 and 25GBASE-R defined in clause 107 of [IEEE802.3] are based on a 64B/66B code.
[IEEE802.3] clauses 74 and 108 do define an optional FEC layer, if 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 to detect 10GBASE-R and 25GBASE-R specific attachment circuit faults such as LOS and sync loss.
The PSN-bound IWF is mapping the scrambled 64B/66B code stream into the basic PLE payload.
The CE-bound NSP function MUST perform
- PCS code sync
- descrambling
in order to properly
- transform invalid 66B code blocks into proper error control characters /E/
- insert Local Fault (LF) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being 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 if the far-end PSN-bound NSP function did 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.
40GBASE-R, 50GBASE-R and 100GBASE-R
The PCS layers of 40GBASE-R and 100GBASE-R defined in clause 82 and of 50GBASE-R defined in clause 133 of [IEEE802.3] are based on a 64B/66B code transmitted over multiple lanes.
[IEEE802.3] clauses 74 and 91 do define an optional FEC layer, if 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
- PCS lane de-skew
- PCS lane reordering
The PSN-bound NSP function is also responsible to detect 40GBASE-R, 50GBASE-R and 100GBASE-R specific attachment circuit faults such as LOS and loss of alignment.
The PSN-bound IWF is mapping the serialized, scrambled 64B/66B code stream including the alignment markers into the basic PLE payload.
The CE-bound NSP function MUST perform
- PCS code sync
- alignment marker removal
- descrambling
in order to properly
- transform invalid 66B code blocks into proper error control characters /E/
- insert Local Fault (LF) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being 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 if the far-end PSN-bound NSP function did 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
- scrambling of the 64B/66B code
- block distribution
- alignment marker insertion
200GBASE-R and 400GBASE-R
The PCS layers of 200GBASE-R and 400GBASE-R defined in clause 119 of [IEEE802.3] are based on a 64B/66B code transcoded to a 256B/257B code to reduce the overhead and make room for a mandatory FEC.
To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform
- alignment lock and de-skew
- PCS Lane reordering and de-interleaving
- FEC decoding
- post-FEC interleaving
- alignment marker removal
- descrambling
- reverse transcoding from 256B/257B to 64B/66B
Further the PSN-bound NSP MUST perform rate compensation and scrambling before the PSN-bound IWF is mapping the same into the basic PLE payload.
Rate compensation is applied so that 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 are inserted every X*20479 number of 66B client blocks. For 200GBASE-R the value of X is 16 and for 400GBASE-R the value of X is 32. Rate compensation blocks are special 66B control characters of type 0x00 that can easily be searched for by the CE-bound IWF in order to remove them.
The PSN-bound NSP function is also responsible to detect 200GBASE-R and 400GBASE-R specific attachment circuit faults such as LOS and loss of alignment.
The CE-bound NSP function MUST perform
- PCS code sync
- descrambling
- rate compensation block removal
in order to properly
- transform invalid 66B code blocks into proper error control characters /E/
- insert Local Fault (LF) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being 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 if the far-end PSN-bound NSP function did 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
- scrambling
- alignment marker insertion
- pre-FEC distribution
- FEC encoding
- PCS Lane distribution
Energy Efficient Ethernet (EEE)
Section 78 of [IEEE802.3] does define the optional Low Power Idle (LPI) capability for Ethernet. Two modes are defined
- deep sleep
- fast wake
Deep sleep mode is not compatible with PLE due to the CE ceasing transmission. Hence there is no support for LPI for 10GBASE-R services across PLE.
When in fast wake mode the CE transmits /LI/ control code blocks instead of /I/ control code blocks and therefore PLE is agnostic to it. For 25GBASE-R and higher services across PLE, LPI is supported as only fast wake mode is applicable.
SONET/SDH Services
SONET/SDH services are special cases of the structured bit stream defined in Section 3.3.4 of [RFC3985].
SDH interfaces are defined in [G.707] and SONET interfaces are defined in [GR253].
The PSN-bound NSP function does not modify the received data but is responsible to detect SONET/SDH interface specific attachment circuit faults such as LOS, LOF and OOF.
Data received by the PSN-bound IWF is mapped into the basic PLE payload without any awareness of SONET/SDH frames.
When the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set, the CE-bound NSP function is responsible for generating the
- MS-AIS maintenance signal defined in clause 6.2.4.1.1 of [G.707] for SDH services
- AIS-L maintenance signal defined in clause 6.2.1.2 of [GR253] for SONET services
at client frame boundaries.
Fibre Channel Services
Fibre Channel services are special cases of the structured bit stream defined in Section 3.3.4 of [RFC3985].
The T11 technical committee of INCITS has defined several layers for Fibre Channel. Emulation is operating at the FC-1 layer.
Over time many different Fibre Channel interface types have been specified in FC-PI-x and FC-FS-x standards with a varying set of characteristics such as optional vs mandatory FEC and single-lane vs multi-lane transmission.
Speed negotiation is out of scope for this document.
All Fibre Channel services are leveraging the basic PLE payload and interface specific mechanisms are confined to the respective service specific NSP functions.
1GFC, 2GFC, 4GFC and 8GFC
[FC-PI-2] specifies 1GFC and 2GFC. [FC-PI-5] and [FC-PI-5am1] do define 4GFC and 8GFC.
The PSN-bound NSP function is responsible to detect Fibre Channel specific attachment circuit faults such as LOS and sync loss.
The PSN-bound IWF is mapping the received 8B/10B code stream as is into the basic PLE payload.
The CE-bound NSP function MUST perform transmission word sync in order to properly
- replace invalid transmission words with the special character K30.7
- insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set
Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets.
[FC-PI-5am1] does define the use of scrambling for 8GFC, in this case the CE-bound NSP MUST also perform descrambling before replacing invalid transmission words or inserting NOS ordered sets. And before sending the bit stream to the, the CE-bound NSP function MUST scramble the 8B/10B code stream.
16GFC and 32GFC
[FC-PI-5] and [FC-PI-5am1] specify 16GFC and define a optional FEC layer. [FC-PI-6] specifies 32GFC with the FEC layer and transmitter training signal (TTS) support being mandatory.
If FEC is present it must be indicated via TTS during attachment circuit bring 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 to detect Fibre Channel specific attachment circuit faults such as LOS and sync loss.
The PSN-bound IWF is mapping the received 64B/66B code stream as is into the basic PLE payload.
The CE-bound NSP function MUST perform
- transmission word sync
- descrambling
in order to properly
- replace invalid transmission words with the error transmission word 1Eh
- insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set
Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or if the far-end PSN-bound NSP function did 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.
64GFC and 4-lane 128GFC
[FC-PI-7] specifies 64GFC and [FC-PI-6P] specifies 4-lane 128GFC. Both specify a mandatory FEC layer. The PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function must generate the FEC.
To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform
- alignment lock and de-skew
- Lane reordering and de-interleaving
- FEC decoding
- post-FEC interleaving
- alignment marker removal
- descrambling
- reverse transcoding from 256B/257B to 64B/66B
Further the PSN-bound NSP MUST perform scrambling before the PSN-bound IWF is mapping the same into the basic PLE payload.
Note : the use of rate compensation is for further study.
The PSN-bound NSP function is also responsible to detect Fibre Channel specific attachment circuit faults such as LOS and sync loss.
The CE-bound NSP function MUST perform
- transmission word sync
- descrambling
in order to properly
- replace invalid transmission words with the error transmission word 1Eh
- insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set
Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or if the far-end PSN-bound NSP function did 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
- scrambling
- alignment marker insertion
- pre-FEC distribution
- FEC encoding
- Lane distribution
OTN Services
OTN services are special cases of the structured bit stream defined in 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 all-0s fixed stuff which results in a extended ODUk frame as illustrated in Figure 3. The frame alignment overhead (FA OH) in row 1 columns 1-7 is kept as it is.
Extended ODUk Frame

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

The PSN-bound NSP function is also responsible to detect OTUk specific attachment circuit faults such as LOS, LOF, LOM and AIS.
The PSN-bound IWF is mapping the extended ODUk frame into the byte aligned PLE payload.
The CE-bound NSP function will recover the ODUk by searching for the frame alignment overhead in the extended ODUk received from the CE-bound IWF and generates the FEC.
When the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set, the CE-bound NSP function is responsible for generating the ODUk-AIS maintenance signal defined in clause 16.5.1 of [G.709] at client frame boundaries.
PLE Encapsulation Layer
The basic packet format used by PLE is shown in the Figure 4.
PLE Encapsulation Layer

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

PSN and VPWS Demultiplexing Headers
This document does not imply any specific technology to be used for implementing the VPWS demultiplexing and PSN layers.
When a 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 Label Switched Path (LSP) established using LDP [RFC5036] or Segment Routing [RFC8402] or a traffic engineered LSP established using RSVP-TE [RFC3209] or SR-TE [RFC9256].
When a SRv6 PSN layer is used, a SRv6 service segment identifier (SID) as defined in [RFC8402] does provide the demultiplexing mechanism and definitions of Section 6 of [RFC9252] do apply. Both SRv6 service SIDs with the full IPv6 address format defined in [RFC8986] and compressed SIDs (C-SIDs) with format defined in [I-D.draft-ietf-spring-srv6-srh-compression] can be used.
Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are defined in this document. The behavior procedures are applicable to both SIDs and C-SIDs.
The H.Encaps.L1 behavior encapsulates a frame received from an IWF in a IPv6 packet with an segment routing header (SRH). The received frame becomes the payload of the new IPv6 packet.
- The next header field of the SRH MUST be set to TBA1.
- The push of the SRH MAY be omitted when the SRv6 policy only contains one segment.
The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.
- H.Encaps.L1.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. The first SID is only placed in the destination address field of the pushed IPv6 header.
- The push of the SRH MAY be omitted when the SRv6 policy only contains one segment.
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 all have the following procedures in common.
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 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 == TBA1 (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 RFC8986}}
S06. }

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.
PLE Control Word
The format of the PLE control word is in line with the guidance in [RFC4385] and is shown in Figure 5.
PLE Control Word

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         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The bits 0..3 of the first nibble are set to 0 to differentiate a control word or Associated Channel Header (ACH) 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 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 play out appropriate replacement data. The NSP MAY inject an appropriate native fault propagation signal.
- R
- Set by the downstream PE to indicate that the IWF experiences packet loss from the PSN or 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.
- LEN
- In accordance to Section 3 of [RFC4385] the length field MUST always be set to zero as there is no padding added to the PLE packet. To detect malformed packets the default, preconfigured or signaled payload size MUST be assumed.
- 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.
RTP Header
The RTP header MUST be included and is used for explicit transfer of timing information. The RTP header is purely a formal reuse and RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Transport Protocol (SRTP), etc., are not applicable to PLE VPWS.
The format of the RTP header is as shown in Figure 6.
RTP Header

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Synchronization Source (SSRC) Identifier            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- V: Version
- The version field MUST be set to 2.
- 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.
- CC: CSRC count
- The CC field MUST be set to zero by the sender and ignored by the receiver.
- 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 both for direction and between different PLE VPWS.
- Sequence number
- The Sequence number in the RTP header MUST be equal to the sequence number in the PLE control word. The sequence number of the RTP header MAY be used to extend the sequence number of the PLE control word from 16 to 32 bits. If so, 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.
- 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.
PLE Payload Layer
A bit-stream is mapped into a PLE packet with a fixed payload size which 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.
All PLE implementations MUST be capable of supporting the default payload size of 1024 bytes.
Basic Payload
The PLE payload is filled with incoming bits of the bit-stream starting from the most significant to the least significant bit without considering any structure of the bit-stream.
Byte aligned Payload
The PLE payload is filled in a byte aligned manner, where the order of the payload bytes corresponds to their order on the attachment circuit. Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant. The PLE payload size MUST be a integer number of bytes.
PLE Operation
Common Considerations
A PLE VPWS can be established using manual configuration or leveraging mechanisms of a signaling protocol.
Furthermore emulation of bit-stream signals using PLE is only possible when the two attachment circuits of the VPWS are of the same service type (OC192, 10GBASE-R, ODU2, etc) and are using the same PLE payload type and payload size. This can be ensured via manual configuration or via 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 [I-D.draft-schmutzer-bess-bitstream-vpws-signalling] and for LDP in [I-D.draft-schmutzer-pals-ple-signaling].
PLE IWF Operation
PSN-bound Encapsulation Behavior
After the VPWS is set up, the PSN-bound IWF does perform the following steps:
- Packetize the data received from the CE is into a fixed size PLE payloads
- Add PLE control word and 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 L bit in the PLE control word whenever attachment circuit detects a fault
- Set R bit in the PLE control word whenever the local CE-bound IWF is in packet loss state
CE-bound Decapsulation Behavior
The CE-bound IWF is responsible for removing the PSN and VPWS demultiplexing headers, PLE control word and RTP header from the received packet stream and play-out of the bit-stream to the local attachment circuit.
A de-jitter buffer MUST be implemented where the PLE packets are stored upon arrival. The size of this buffer SHOULD be locally configurable to allow accommodation of specific PSN packet delay variation expected.
The CE-bound IWF SHOULD use the sequence number in the control word to detect lost and mis-ordered packets. It MAY use the sequence number in the RTP header for the same purposes.
The payload of a lost packet MUST be replaced with equivalent amount of replacement data. The contents of the replacement data MAY be locally configurable. All PLE implementations MUST support generation of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xAA" pattern does ensure clock synchronization is maintained. While playing out the replacement data, the IWF will apply a holdover mechanism to maintain the clock.
Whenever the VPWS is not operationally up, the CE-bound NSP function MUST inject the appropriate native downstream fault indication signal.
Whenever a VPWS comes up, the CE-bound IWF enters the intermediate state, will start receiving PLE packets and will store them in the jitter buffer. The CE-bound NSP function will continue to inject the appropriate native downstream fault indication signal until a pre-configured amount of payloads is stored in the jitter buffer.
After the pre-configured amount of payload is present in the jitter buffer the CE-bound IWF transitions to the normal operation state and the content of the jitter buffer is played out to the CE in accordance with the required clock. In this state the CE-bound IWF MUST perform egress clock recovery.
The recovered clock MUST comply with the jitter and wander requirements applicable to the type of attachment circuit, specified in:
- [G.825] and [G.823] for SDH
- [GR253] 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 native downstream fault indication signal instead of playing out the payload.
If the CE-bound IWF detects loss of consecutive packets for a pre-configured amount of time (default is 1 millisecond), it enters packet loss (PLOS) state and a corresponding defect is declared.
If the CE-bound IWF detects a packet loss ratio (PLR) above a configurable signal-degrade (SD) threshold for a configurable amount of consecutive 1-second intervals, it enters the degradation (DEG) state and a corresponding defect is declared. The SD-PLR threshold can be defined as percentage with the default being 15% or absolute packet count for finer granularity for higher rate interfaces. Possible values for consecutive intervals are 2..10 with the default 7.
While the PLOS defect is declared the CE-bound NSP function SHOULD inject the appropriate native downstream fault indication signal. Also the PSN-bound IWF SHOULD set the R bit in the PLE control word of every packet transmitted.
The CE-bound IWF does change from the PLOS to normal state after the pre-configured amount of payload has been received similarly to the transition 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.
PLE Performance Monitoring
PLE SHOULD provide the following functions to monitor the network performance to be inline with expectations of transport network operators.
The near-end performance monitors defined for PLE are as follows:
- 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 a PLOS/DEG defect SHALL be counted as ES-PLE. Each second with a PLR greater than 15% or a PLOS/DEG defect SHALL be counted as SES-PLE.
UAS-PLE SHALL be counted after configurable number of consecutive SES-PLE have been observed, and no longer counted after a configurable number of consecutive seconds without SES-PLE have been observed. Default value for each is 10 seconds.
Once unavailability is detected, ES and SES counts SHALL be inhibited up to the point where the unavailability was started. Once unavailability is removed, ES and SES that occurred along the clearing period SHALL be added to the ES and SES counts.
A PLE far-end performance monitor is providing 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]
QoS and Congestion Control
The PSN carrying PLE VPWS may be subject to congestion, but PLE VPWS representing constant bit-rate (CBR) flows cannot respond to congestion in a TCP-friendly manner as described in [RFC2913].
Hence the PSN providing connectivity for the PLE VPWS between PE devices MUST be Diffserv [RFC2475] enabled and MUST provide a per domain behavior [RFC3086] that guarantees low jitter and low loss.
To achieve the desired per domain behavior PLE VPWS SHOULD be carried over traffic-engineering paths through the PSN with bandwidth reservation and admission control applied.
Security Considerations
As PLE is leveraging VPWS as transport mechanism, the security considerations described in [RFC7432] and [RFC3985] are applicable.
PLE does not enhance or detract from the security performance of the underlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.
A data plane attack may force PLE packets to be dropped, re-ordered or delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to either degradation or service disruption. Considerations outlined in [RFC9055] are a good reference.
Clock synchronization leveraging PTP is sensitive to Packet Delay Variation (PDV) and vulnerable to various threads and attacked vectors. Considerations outlined in [RFC7384] should be taken into account.
IANA Considerations
Bit-stream Next Header Type
This document introduces a new value to be used in the next header field of an IPv6 header or any extension header indicating that the payload is a emulated bit-stream. IANA is requested to assign the following from the "Assigned Internet Protocol Numbers" registry (see https://www.iana.org/assignments/protocol-numbers/).
Decimal | Keyword | Protocol | IPv6 Extension Header | Reference
TBA1 | BIT-EMU | Bit-stream Emulation | Y | this document
SRv6 Endpoint Behaviors
This document introduces three new SRv6 Endpoint behaviors. IANA is requested to assign identifier values in the "SRv6 Endpoint Behaviors" sub-registry under "Segment Routing Parameters" registry.
Value | Hex | Endpoint Behavior | Reference
158 | 0x009E | End.DX1 | this document
159 | 0x009F | End.DX1 with NEXT-CSID | this document
160 | 0x00A0 | End.DX1 with REPLACE-CSID | this document
Acknowledgements
The authors would like to thank all reviewers, contributors and the working group for reviewing this document and providing useful comments and suggestions.
References
Normative References
[RFC3550]

RTP: A Transport Protocol for Real-Time Applications
H. Schulzrinne
S. Casner
R. Frederick
V. Jacobson
July 2003
STD 64
RFC 3550
DOI 10.17487/RFC3550
[RFC3551]

RTP Profile for Audio and Video Conferences with Minimal Control
H. Schulzrinne
S. Casner
July 2003
STD 65
RFC 3551
DOI 10.17487/RFC3551
[RFC4385]

Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
S. Bryant
G. Swallow
L. Martini
D. McPherson
February 2006
RFC 4385
DOI 10.17487/RFC4385
[RFC8986]

Segment Routing over IPv6 (SRv6) Network Programming
C. Filsfils, Ed.
P. Camarillo, Ed.
J. Leddy
D. Voyer
S. Matsushima
Z. Li
February 2021
RFC 8986
DOI 10.17487/RFC8986
[RFC9252]

BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
G. Dawra, Ed.
K. Talaulikar, Ed.
R. Raszuk
B. Decraene
S. Zhuang
J. Rabadan
July 2022
RFC 9252
DOI 10.17487/RFC9252
[G.823]

The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy
International Telecommunication Union (ITU)
March 2000
[G.825]

The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH)
International Telecommunication Union (ITU)
March 2000
[G.826]

End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections
International Telecommunication Union (ITU)
December 2002
[G.707]

Network node interface for the synchronous digital hierarchy (SDH)
International Telecommunication Union (ITU)
January 2007
[G.709]

Interfaces for the optical transport network
International Telecommunication Union (ITU)
June 2020
[G.8251]

The control of jitter and wander within the optical transport network (OTN)
International Telecommunication Union (ITU)
November 2022
[G.8261]

Timing and synchronization aspects in packet networks
International Telecommunication Union (ITU)
August 2019
[G.8261.1]

Packet delay variation network limits applicable to packet-based methods (Frequency synchronization)
International Telecommunication Union (ITU)
February 2012
[G.8262]

Timing characteristics of synchronous equipment slave clock
International Telecommunication Union (ITU)
November 2018
[G.8265.1]

Precision time protocol telecom profile for frequency synchronization
International Telecommunication Union (ITU)
November 2022
[GR253]

SONET Transport Systems - Common Generic Criteria
Telcordia
October 2009
[IEEE802.3]

IEEE Standard for Ethernet
IEEE
May 2022
[FC-PI-2]

Information Technology - Fibre Channel Physical Interfaces - 2 (FC-PI-2)
INCITS
2006
[FC-PI-5]

Information Technology - Fibre Channel - Physical Interface-5 (FC-PI-5)
INCITS
2011
[FC-PI-5am1]

Information Technology - Fibre Channel - Physical Interface - 5/Amendment 1 (FC-PI-5/AM1)
INCITS
2016
[FC-PI-6]

Information Technology - Fibre Channel - Physical Interface - 6 (FC-PI-6)
INCITS
2015
[FC-PI-6P]

Information Technology - Fibre Channel - Physical Interface - 6P (FC-PI-6P)
INCITS
2016
[FC-PI-7]

Information Technology – Fibre Channel - Physical Interfaces - 7 (FC-PI-7)
INCITS
2021
[RFC8402]

Segment Routing Architecture
C. Filsfils, Ed.
S. Previdi, Ed.
L. Ginsberg
B. Decraene
S. Litkowski
R. Shakir
July 2018
RFC 8402
DOI 10.17487/RFC8402
[I-D.draft-ietf-spring-srv6-srh-compression]

Compressed SRv6 Segment List Encoding
Weiqiang Cheng
China Mobile
Clarence Filsfils
Cisco Systems, Inc.
Zhenbin Li
Huawei Technologies
Bruno Decraene
Orange
Francois Clad
Cisco Systems, Inc.
16 May 2024
Internet-Draft draft-ietf-spring-srv6-srh-compression-17
[RFC7432]

BGP MPLS-Based Ethernet VPN
A. Sajassi, Ed.
R. Aggarwal
N. Bitar
A. Isaac
J. Uttaro
J. Drake
W. Henderickx
February 2015
RFC 7432
DOI 10.17487/RFC7432
Informative References
[RFC3985]

Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
S. Bryant, Ed.
P. Pate, Ed.
March 2005
RFC 3985
DOI 10.17487/RFC3985
[RFC4197]

Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
M. Riegel, Ed.
October 2005
RFC 4197
DOI 10.17487/RFC4197
[RFC4842]

Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
A. Malis
P. Pate
R. Cohen, Ed.
D. Zelig
April 2007
RFC 4842
DOI 10.17487/RFC4842
[RFC4553]

Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)
A. Vainshtein, Ed.
YJ. Stein, Ed.
June 2006
RFC 4553
DOI 10.17487/RFC4553
[RFC5036]

LDP Specification
L. Andersson, Ed.
I. Minei, Ed.
B. Thomas, Ed.
October 2007
RFC 5036
DOI 10.17487/RFC5036
[RFC3209]

RSVP-TE: Extensions to RSVP for LSP Tunnels
D. Awduche
L. Berger
D. Gan
T. Li
V. Srinivasan
G. Swallow
December 2001
RFC 3209
DOI 10.17487/RFC3209
[RFC9256]

Segment Routing Policy Architecture
C. Filsfils
K. Talaulikar, Ed.
D. Voyer
A. Bogdanov
P. Mattes
July 2022
RFC 9256
DOI 10.17487/RFC9256
[RFC8077]

Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
L. Martini, Ed.
G. Heron, Ed.
February 2017
STD 84
RFC 8077
DOI 10.17487/RFC8077
[RFC8214]

Virtual Private Wire Service Support in Ethernet VPN
S. Boutros
A. Sajassi
S. Salam
J. Drake
J. Rabadan
August 2017
RFC 8214
DOI 10.17487/RFC8214
[I-D.draft-schmutzer-bess-bitstream-vpws-signalling]

Ethernet VPN Signalling Extensions for Bit-stream VPWS
Steven Gringeri
Verizon
Jeremy Whittaker
Verizon
Christian Schmutzer
Cisco Systems, Inc.
Bharath Vasudevan
Cisco Systems, Inc.
Patrice Brissette
Cisco Systems, Inc.
18 April 2024
Internet-Draft draft-schmutzer-bess-bitstream-vpws-signalling-01
[I-D.draft-schmutzer-pals-ple-signaling]

LDP Extensions to Support Private Line Emulation (PLE)
Christian Schmutzer
Cisco Systems, Inc.
18 April 2024
Internet-Draft draft-schmutzer-pals-ple-signaling-01
[RFC2913]

MIME Content Types in Media Feature Expressions
G. Klyne
September 2000
RFC 2913
DOI 10.17487/RFC2913
[RFC2475]

An Architecture for Differentiated Services
S. Blake
D. Black
M. Carlson
E. Davies
Z. Wang
W. Weiss
December 1998
RFC 2475
DOI 10.17487/RFC2475
[RFC3086]

Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification
K. Nichols
B. Carpenter
April 2001
RFC 3086
DOI 10.17487/RFC3086
[RFC9055]

Deterministic Networking (DetNet) Security Considerations
E. Grossman, Ed.
T. Mizrahi
A. Hacker
June 2021
RFC 9055
DOI 10.17487/RFC9055
[RFC7384]

Security Requirements of Time Protocols in Packet Switched Networks
T. Mizrahi
October 2014
RFC 7384
DOI 10.17487/RFC7384
Contributors
Andreas Burk
1&1 Versatel
andreas.burk@magenta.de
Faisal Dada
AMD
faisal.dada@amd.com
Gerald Smallegange
Ciena Corporation
gsmalleg@ciena.com
Erik van Veelen
Aimvalley
erik.vanveelen@aimvalley.com
Luca Della Chiesa
Cisco Systems, Inc.
ldellach@cisco.com
Nagendra Kumar Nainar
Cisco Systems, Inc.
naikumar@cisco.com
Carlos Pignataro
North Carolina State University
cmpignat@ncsu.edu