Private Line Emulation over Packet Switched Networks
Verizonsteven.gringeri@verizon.comVerizonjeremy.whittaker@verizon.comDeutsche TelekomN.Leymann@telekom.deCisco Systems, Inc.cschmutz@cisco.comCisco Systems, Inc.ldellach@cisco.comCisco Systems, Inc.naikumar@cisco.comCisco Systems, Inc.cpignata@cisco.comCiena Corporationgsmalleg@ciena.comCiena Corporationcbrown@ciena.comXilinxfaisald@xilinx.com
BESS Working Group
Internet Engineering Task ForcemplspleThis document describes a method for encapsulating high-speed bit-streams as virtual private wire services (VPWS)
over packet switched networks (PSN) providing complete signal transport transparency.
This document describes a method for encapsulating high-speed bit-streams as
VPWS over packet switched networks (PSN). This emulation suits applications where
complete signal transparency is required and data interpretation of the PE would be counter productive.
One example is two ethernet connected CEs and the need for synchronous ethernet operation between then without
the intermediate PEs interfering. Another example is addressing common ethernet
control protocol transparency concerns for carrier ethernet services, beyond the
behavior definitions of MEF specifications.
The mechanisms described in this document allow the transport of signals from many technologies such as ethernet,
fibre channel, SONET/SDH / and OTN by treating them as bit-stream payload defined in Section 3.3.3 of .
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 BCP
14 when, and only when, they appear in all
capitals, as shown here.
ACH - Associated Channel HeaderAIS - Alarm Indication SignalCBR - Constant Bit RateCE - Customer EdgeCSRC - Contributing SouRCeES - Errored SecondFEC - Forward Error CorrectionIWF - InterWorking FunctionLDP - Label Distribution ProtocolLF - Local FaultMPLS - Multi Protocol Label SwitchingNSP - Native Service ProcessorODUk - Optical Data Unit kOTN - Optical Transport NetworkOTUk - Optical Transport Unit kPCS - Physical Coding SublayerPE - Provider EdgePLE - Private Line EmulationPLOS - Packet Loss Of SignalPSN - Packet Switched NetworkP2P - Point-to-PointQOS - Quality Of ServiceRSVP-TE - Resource Reservation Protocol Traffic EngineeringRTCP - RTP Control ProtocolRTP - Realtime Transport ProtocolSES - Severely Errored SecondsSDH - Synchronous Digital HierarchySRTP - Secure Realtime Transport ProtocolSRv6 - Segment Routing over IPv6 DataplaneSSRC - Synchronization SouRCeSONET - Synchronous Optical NetworkTCP - Transmission Control ProtocolUAS - Unavailable SecondsVPWS - Virtual Private Wire Service
Similarly 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.
The generic models defined in are applicable to PLE.
PLE embraces the minimum intervention principle outlined in section 3.3.5 of
whereas the data is flowing through the PLE encapsulation
layer as received without modifications.
For some applications the NSP function is responsible for performing operations
on the native data received from the CE. Examples are terminating FEC in case of 100GE
or terminating the OTUk layer for OTN. After the NSP the IWF is generating
the payload of the VPWS which 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 network
synchronization reference model and deployment scenario outlined in section 4.3.2 of is applicable.
The attachment circuit clock E is generated by PE2 in reference to a common clock I.
For this to work the difference between clock I and 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 basic packet format used by PLE is shown in the below figure.
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 . 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.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.
The format of the PLE control word is inline with the guidance in and as shown in the below figure:
The first nibble is used to differentiate if it is a control word or
Associated Channel Header (ACH). The first nibble MUST be set to 0000b to indicate that this header is a control word as defined in section 3 of
.
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 (client signal failure). The downstream PE MUST play out an
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 except for
frame aligned payloads; see LEN
In accordance to section 3 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 for the RTP sequence number and MUST
be incremented with every PLE packet being sent.
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 the below figure:
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 sender and ignored by receiver.
PT: Payload Type
A PT value MUST be allocated from the range of dynamic values define 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 packet sequence number MUST continuously cycle from 0 to 0xFFFF. It is
generated and processed in accordance with the rules established in
. The PLE receiver MUST sequence packets according
to the Sequence Number field of the PLE control word and MAY verify correct
sequencing using RTP Sequence Number field.
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.
A bit-stream is mapped into a packet with a fixed payload size ignoring any structure being present.
The number of bytes 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.
For constant bit rate payloads the PLE packet is filled with incoming bits of the bit stream starting from the
most significant to the least significant bit.
All PLE implementations MUST be capable of supporting the default payload size of 1024 bytes.
For PCS based CE interface types supporting FEC the NSP function MUST terminate the FEC and pass the PCS encoded signal
to the IWF function.
For PCS based CE interface types supporting virtual lanes (i.e. 100GE) a PLE payload MUST carry information from all
virtual lanes in a bit interleaved manner after the NSP function has performed PCS layer de-skew and re-ordering.
A PLE implementation MUST support the transport of all service types except ODUk bit-streams
using the constant bit rate payload.
In case of an OTN bit-stream, the NSP function MUST present to the IWF an extended ODUk including a valid frame alignment overhead.
The IWF is performing byte-aligned mapping into PLE packets. The egress NSP function will recover the ODUk by
searching for the frame alignment overhead.
For byte aligned payloads PLE uses the following order for packetization: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 payload size of 1024 bytes.
All PLE implementations MUST support the transport of OTN bit-streams using the byte aligned payload.A PLE VPWS can be established using manual configuration or leveraging mechanisms of a signalling protocolFurthermore 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 signalling protocolExtensions to the PWE3 and EVPN-VPWS control protocols are described
in a separate document .After the VPWS is set up, the PSN-bound IWF does perform the following steps:
Packetise the data received from the CE is into a fixed size PLE payloadsAdd PLE control word and RTP header with sequence numbers, flags and timestamps properly setAdd the VPWS demultiplexer and PSN headersTransmit the resulting packets over the PSNSet L bit in the PLE control word whenever attachment circuit detects a faultSet R bit in the PLE control word whenever the local CE-bound IWF is in packet loss stateThe 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 (for example ODUk-AIS or ethernet LF).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 OTNWhenever 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 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 SecondsSES-PLE : PLE Severely Errored SecondsUAS-PLE : PLE Unavailable SecondsEach 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 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.
As PLE is leveraging VPWS as transport mechanism the security considerations
described in and are applicable.
Applicable signalling extensions are out of the scope of this document.
PLE does not introduce additional requirements from IANA.
The authors would like to thank Andreas Burk for reviewing this
document and providing useful comments and suggestions.Private Line Emulation VPWS SignallingIETFG.825: The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH)International Telecommunication Union (ITU)G.823: The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchyInternational Telecommunication Union (ITU)G.8261: Timing and synchronization aspects in packet networksInternational Telecommunication Union (ITU)G.8251: The control of jitter and wander within the optical transport network (OTN)International Telecommunication Union (ITU)G.709: Interfaces for the optical transport networkInternational Telecommunication Union (ITU)Segment Routing Policy ArchitectureIETFSRv6 Network ProgrammingIETFSONET Transport Systems : Common Generic CriteriaTelcordiaNetwork node interface for the synchronous digital hierarchy (SDH)ITU-TEnd-to-end error performance parameters and objectives for international, constant bit-rate
digital paths and connectionsITU-T