Private Line Emulation over Packet Switched Networks

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 CEs and the need for synchronous ethernet operation between them without the intermediate PEs interfering or addressing concerns about ethernet control protocol transparency for carrier ethernet services, beyond the behavior definitions of 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 CEP defined in 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 principals similar to but expanding the applicability beyond the narrow set of PDH interfaces (T1, E1, T3 and E3) and allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH / and OTN at gigabit speeds by treating them as bit-stream payload defined in sections 3.3.3 and 3.3.4 of .

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 interpreted as described in BCP14 when, and only when, they appear in all capitals, as shown here.

Terminology and Reference Model

Terminology

ACH - Associated Channel Header
AIS - Alarm Indication Signal
CBR - Constant Bit Rate
CE - Customer Edge
CSRC - Contributing SouRCe
ES - Errored Second
FEC - Forward Error Correction
IWF - InterWorking Function
LDP - Label Distribution Protocol
LF - Local Fault
MPLS - Multi Protocol Label Switching
NSP - Native Service Processor
ODUk - Optical Data Unit k
OTN - Optical Transport Network
OTUk - Optical Transport Unit k
PCS - Physical Coding Sublayer
PE - Provider Edge
PLE - Private Line Emulation
PLOS - Packet Loss Of Signal
PSN - Packet Switched Network
P2P - Point-to-Point
QOS - Quality Of Service
RSVP-TE - Resource Reservation Protocol Traffic Engineering
RTCP - RTP Control Protocol
RTP - Realtime Transport Protocol
SAN - Storage Area Network
SES - Severely Errored Seconds
SDH - Synchronous Digital Hierarchy
SPE - Synchronous Payload Envelope
SRTP - Secure Realtime Transport Protocol
SRv6 - Segment Routing over IPv6 Dataplane
SSRC - Synchronization SouRCe
SONET - Synchronous Optical Network
TCP - Transmission Control Protocol
UAS - Unavailable Seconds
VPWS - Virtual Private Wire Service
VC - Virtual Circuit
VT - Virtual Tributary

Similar to and 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 generic reference model defined in and does apply to PLE. Further the model defined in and in particular the concept of a Native Service Processing (NSP) function defined in does apply to PLE as well. The resulting reference model for PLE is illustrated in

PLE Reference Model | | | | |<-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 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) or terminating the OTUk layer for OTN. After the NSP the IWF is generating the payload of the VPWS which is carried via a PSN tunnel.

Relative Network Scenario Timing |.............................|--------->| | +-----+ |- - -|=================|- - -| +-----+ ^ +-----+<-------+------->+-----+ | | ^ A +-+ | |I| E +-+ ]]> To allow the clock of the transported signal to be carried across the PLE domain in a transparent way the network synchronization reference model and deployment scenario outlined in is applicable. As illustrated in , the attachment circuit clock E is generated by PE2 via a differential clock recovery method in reference to a common clock I. For this to work the difference between clock I and clock A MUST be explicitly transferred between the PE1 and PE2 using the timestamp inside the RTP header. For the reverse direction PE1 does generate the clock J in reference to clock I and the clock difference between I and G. The way the common clock I is implemented is out of scope of this document. Well established concepts for achieving frequency synchronization in a PSN have already been defined in and can be applied here as well.

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

Generic PLE Service The generic PLE service is an example of the bit stream defined in . 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 structure bit stream defined in . IEEE has defined several layers for ethernet in . Emulation is operating at the physical (PHY) layer, more precisely at the Physical Subcoding Layer (PCS). Over time many differnet ethernet interface types have been specified in with a varying set of characteristcs such as optional vs mandatory FEC and single-lane vs multi-lane transmission. Having said that all ethernet services are leverging the basic PLE payload and interface specific mechanisms are confined to the respective service specific NSP functions.

10GBASE-R and 25GBASE-R The PCS layers of 10GBASE-R defined in clause 49 and 25GBASE-R defined in clause 107 of are based on a 64B/66B code. clauses 74 and 108 do define a 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 circuits faults such as LOS and sync loss. The PSN-bound IWF is mapping the scrambled 64B/66B data 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 farend 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.

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 are based on a 64B/66B code transmitted over multiple lanes. clauses 74 and 91 do define a 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 the PSN-bound NSP further MUST perform

block synchronization
PCS lane deskew
PCS lane reordering

The PSN-bound NSP function is also responsible to detect 40GBASE-R, 50GBASE-R and 100GBASE-R specific attachment circuits faults such as LOS and sync loss. 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 farend 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 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 the PSN-bound NSP further MUST perform

alignment lock and deskew
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 circuits faults such as LOS and sync loss. 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 farend 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
aligment marker insertion
pre-FEC distribution
FEC encoding
PCS Lane distribution

SONET/SDH Services SONET/SDH services are special cases of the structured bit stream defined in . SDH interfaces are defined in and SONET interfaces are defined in . 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 for SDH services
AIS-L maintenance signal defined in clause 6.2.1.2 of for SONET services

Fibre Channel Services TO BE ADDED

ODUk OTN Services ODUk services are special cases of the structured bit stream defined in . OTN interfaces are defined in . The PSN-bound NSP function MUST terminate the FEC and present to the IWF an extended ODUk including a valid frame alignment overhead. Further OTN interface specific attachment circuit faults such as LOS are to The PSN-bound NSP function is also responsible to detect OTUk specific attachment circuits faults such as LOS, LOF, LOM, AIS and DEG. For ODUk services the PSN-bound IWF MUST use the byte aligned PLE payload. The CE-bound NSP function will recover the ODUk by searching for the frame alignment overhead and generate 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 .

PLE Encapsulation Layer The basic packet format used by PLE is shown in the .

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 . The PSN tunnel can be a simple best path Label Switched Path (LSP) established using LDP or Segment Routing or a traffic engineered LSP established using RSVP-TE or SR-TE . When PLE is applied to a SRv6 based PSN, the mechanisms defined in and the End.DX2 endpoint behavior defined in do apply.

PLE Header The PLE header MUST contain the PLE control word (4 bytes) and MUST include a fixed size RTP header . 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 and is shown in .

PLE Control Word 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 . The other fields in the control word are used as defined below:

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.

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.

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

These bits MUST be set to zero by the sender and ignored by the receiver.

In accordance to 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 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 .

RTP Header

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.

PT: Payload type

A PT value MUST be allocated from the range of dynamic values defined by 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 qual 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 . 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. All PLE implementations MUST support the transport of OTN bit-streams using the byte aligned payload.

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 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 a signaling protocol PLE related control protocol extensions to PWE3 and EVPN-VPWS are out of scope of this document and are described in .

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:

and for SDH
for SONET
for synchronous ethernet
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. Possible values for the SD-PLR threshold are between 1..100% with the default being 15%. Possible values for consecutive intervals are 2..10 with the default 7. While either a PLOS or DEG 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

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 . Hence the PSN providing connectivity for the PLE VPWS between PE devices MUST be Diffserv enabled and MUST provide a per domain behavior 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 and are applicable.

IANA Considerations Applicable signaling extensions are out of the scope of this document, hence there are no new requirements from IANA.

Acknowledgements The authors would like to thank Andreas Burk for reviewing this document and providing useful comments and suggestions.

Contributors Contributors' Addresses