Internet Engineering Task Force S. Gringeri
Internet-Draft J. Whittaker
Intended status: Standards Track Verizon
Expires: January 13, 2021 C. Schmutzer, Ed.
L. Della Chiesa
N. Nainar, Ed.
C. Pignataro
Cisco Systems, Inc.
July 12, 2020

Private Line Emulation over Packet Switched Networks


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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 13, 2021.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction and Motivations

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 [GR253]/[G.707] and OTN [G.709] by treating them as bit-stream payload defined in Section 3.3.3 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 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology and Reference Model

3.1. Terminology

Similarly to [RFC4553] and [RFC5086] 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.

3.2. Reference Models

The generic models defined in [RFC4664] are applicable to PLE.

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

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

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 [RFC4197] is applicable.

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

Figure 2: Relative Network Scenario Timing

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.

4. PLE Encapsulation Layer

The basic packet format used by PLE is shown in the below figure.

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

Figure 3: PLE Encapsulation Layer

4.1. 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 [SRPOLICY].

When PLE is applied to a SRv6 based PSN, the mechanisms defined in [RFC8402] and the End.DX2 endpoint behavior defined in [SRV6NETPROG] do apply.

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

4.2.1. PLE Control Word

The format of the PLE control word is inline with the guidance in [RFC4385] and as shown in the below figure:

    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 4: PLE Control Word

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 [RFC4385].

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






Sequence Number

4.2.2. 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 the below figure:

       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 5: RTP Header

V: Version

P: Padding

X: Header Extension

CC: CSRC Count

M: Marker

PT: Payload Type

Sequence Number


SSRC: Synchronization Source

5. PLE Payload Layer

5.1. Constant Bit Rate Payload

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.

All PLE implementations MUST be capable of supporting the default payload size of 480 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.

5.2. ODUk Frame aligned Payload

In case of OTN PLE does only transport the ODUk layer to be bandwidth efficient. This means the OTUk layer which does include the FEC is terminated by NSP function. As OTN is performing frame alignment at the OTUk layer the bit-stream must be carried frame aligned.

A ODUk frame consists of 3824 columns and 4 rows which results in a frame size of 15296 bytes. As common PSN MTU sizes are in the range of at most 9200 bytes the ODUk frame has to be fragmented during PLE payload encapsulation. The used payload size has to be a integer fraction of the full 15296 bytes to allow for ODUk frame alignment. All PLE implementations MUST support the payload size of 478 bytes.

The two FRG bits in the PLE control word MUST be used to indicate first, intermediate, and last fragment of the encapsulated ODUk frame as described in section 4.1 of [RFC4623].

All PLE implementations MUST support the transport ODUk bit-streams using the frame aligned payload.

6. PLE Operation

6.1. Common Considerations

A PLE VPWS can be established using manual configuration or leveraging mechanisms of a signalling 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 signalling protocol

Extensions to the PWE3 [RFC4447] and EVPN-VPWS [RFC8214] control protocols are described in a separate document [PLESIG].

6.2. PLE IWF Operation

6.2.1. PSN-bound Encapsulation Behavior

After the VPWS is set up, the PSN-bound IWF does perform the following steps:

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

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 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 does perform egress clock recovery.

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 a pre-configured number of consecutive packets, the de-jitter buffer under- or over-runs, it enters packet loss (PLOS) state . While in this state 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 exits the packet loss state after a pre-configured amount of valid PLE packets have been received.

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

6.3. 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:

Each second that contains at least one lost packet defect SHALL be counted as ES-PLE. Each second that contains a PLOS 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]

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

7. Security Considerations

As PLE is leveraging VPWS as transport mechanism the security considerations described in [RFC7432] and [RFC3985] are applicable.

8. IANA Considerations

Applicable signalling extensions are out of the scope of this document.

PLE does not introduce additional requirements from IANA.

9. Acknowledgements

To be updated.

10. References

10.1. Normative References

[PLESIG] IETF, "Private Line Emulation VPWS Signalling"
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, DOI 10.17487/RFC3086, April 2001.
[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.
[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.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005.
[RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, DOI 10.17487/RFC4197, October 2005.
[RFC4385] Bryant, S., Swallow, G., Martini, L. and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T. and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, DOI 10.17487/RFC4447, April 2006.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, DOI 10.17487/RFC4623, August 2006.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006.
[RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J. and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J. and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017.

10.2. Informative References

[G.707] ITU-T, "Network node interface for the synchronous digital hierarchy (SDH)"
[G.709] International Telecommunication Union (ITU), "G.709: Interfaces for the optical transport network"
[G.826] ITU-T, "End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections"
[GR253] Telcordia, "SONET Transport Systems : Common Generic Criteria"
[RFC2913] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, DOI 10.17487/RFC2913, September 2000.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001.
[RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006.
[RFC5036] Andersson, L., Minei, I. and B. Thomas, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007.
[RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T. and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007.
[RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018.
[SRPOLICY] IETF, "Segment Routing Policy Architecture"
[SRV6NETPROG] IETF, "SRv6 Network Programming"

Authors' Addresses

Steven Gringeri Verizon EMail:
Jeremy Whittaker Verizon EMail:
Christian Schmutzer (editor) Cisco Systems, Inc. EMail:
Luca Della Chiesa Cisco Systems, Inc. EMail:
Nagendra Kumar Nainar (editor) Cisco Systems, Inc. EMail:
Carlos Pignataro Cisco Systems, Inc. EMail: