<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->


<rfc category="std" docName="draft-schmutzer-pals-ple-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="PLE">Private Line Emulation over Packet Switched Networks
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor -->

    <author fullname="Steven Gringeri" initials="S."
            surname="Gringeri">
      <organization>Verizon</organization>
      <address>
        <email>steven.gringeri@verizon.com</email>
      </address>
    </author>

    <author fullname="Jeremy Whittaker" initials="J."
            surname="Whittaker">
      <organization>Verizon</organization>
      <address>
        <email>jeremy.whittaker@verizon.com</email>
      </address>
    </author>

    <author fullname="Nicolai Leymann" initials="N."
            surname="Leymann">
      <organization>Deutsche Telekom</organization>
      <address>
        <email>N.Leymann@telekom.de</email>
      </address>
    </author>


    <author role="editor" fullname="Christian Schmutzer" initials="C."
            surname="Schmutzer">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>cschmutz@cisco.com</email>
      </address>
    </author>

    <author fullname="Luca Della Chiesa" initials="L."
            surname="Della Chiesa">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>ldellach@cisco.com</email>
      </address>
    </author>
    
    <author role="editor" fullname="Nagendra Kumar Nainar" initials="N."
            surname="Nainar">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>naikumar@cisco.com</email>
      </address>
    </author>

    <author fullname="Carlos Pignataro" initials="C."
            surname="Pignataro">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>cpignata@cisco.com</email>
      </address>
    </author>

    <author fullname="Gerald Smallegange" initials="G."
            surname="Smallegange">
      <organization>Ciena Corporation</organization>
      <address>
        <email>gsmalleg@ciena.com</email>
      </address>
    </author>

    <author fullname="Chris Brown" initials="C."
            surname="Brown">
      <organization>Ciena Corporation</organization>
      <address>
        <email>cbrown@ciena.com</email>
      </address>
    </author>

    <author fullname="Faisal Dada" initials="F."
            surname="Dada">
      <organization>Xilinx</organization>
      <address>
        <email>faisald@xilinx.com</email>
      </address>
    </author>


    <date/>

    <area>PALS Working Group</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
    IETF is fine for individual submissions.  
	If this element is not present, the default is "Network Working Group",
    which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>mpls</keyword>
    <keyword>ple</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>

      <t>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.
      </t>

    </abstract>
	
  </front>

  <middle>

<section title="Introduction and Motivations">
	<t>This document describes a method for encapsulating high-speed bit-streams as 
	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.
	</t>
	
	<t>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.
	</t>
	<t>
		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.
	</t>
	<t>
		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 <xref target="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.
	</t>
	
	<t>The mechanisms described in this document follow principals similar to <xref target="RFC4553" /> 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 <xref target="GR253" />/<xref target="G.707" /> and OTN <xref target="G.709" /> at gigabit speeds by treating them as bit-stream payload defined in Section 3.3.3 of <xref target="RFC3985" />.
	</t>
</section>

<section title="Requirements Notation">
	<t> 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 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when, they appear in all
   capitals, as shown here.
	</t>
    </section>

<section title="Terminology and Reference Model">
	<section title="Terminology">
		<t>
		<list style="symbols">
		<t>ACH - Associated Channel Header</t>
		<t>AIS - Alarm Indication Signal</t>
		<t>CBR - Constant Bit Rate</t>
		<t>CE - Customer Edge</t>
		<t>CSRC - Contributing SouRCe</t>
		<t>ES - Errored Second</t>
		<t>FEC - Forward Error Correction</t>
		<t>IWF - InterWorking Function</t>
		<t>LDP - Label Distribution Protocol</t>
		<t>LF - Local Fault</t>
		<t>MPLS - Multi Protocol Label Switching</t>
		<t>NSP - Native Service Processor</t>
		<t>ODUk - Optical Data Unit k</t>
		<t>OTN - Optical Transport Network</t>
		<t>OTUk - Optical Transport Unit k</t>
		<t>PCS - Physical Coding Sublayer</t>
		<t>PE - Provider Edge</t>
		<t>PLE - Private Line Emulation</t>
		<t>PLOS - Packet Loss Of Signal</t>
		<t>PSN - Packet Switched Network</t>
		<t>P2P - Point-to-Point</t>
		<t>QOS - Quality Of Service</t>
		<t>RSVP-TE - Resource Reservation Protocol Traffic Engineering</t>
		<t>RTCP - RTP Control Protocol</t>
		<t>RTP - Realtime Transport Protocol</t>
		<t>SAN - Storage Area Network</t>
		<t>SES - Severely Errored Seconds</t>
		<t>SDH - Synchronous Digital Hierarchy</t>
		<t>SPE - Synchronous Payload Envelope</t>
		<t>SRTP - Secure Realtime Transport Protocol</t>
		<t>SRv6 - Segment Routing over IPv6 Dataplane</t>
		<t>SSRC - Synchronization SouRCe</t>
		<t>SONET - Synchronous Optical Network</t>
		<t>TCP - Transmission Control Protocol</t>
		<t>UAS - Unavailable Seconds</t>
		<t>VPWS - Virtual Private Wire Service</t>
		<t>VC - Virtual Circuit</t>
		<t>VT - Virtual Tributary</t>
		</list>
		</t>
		<t>
		Similar to <xref target="RFC4553" /> and <xref target="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.
		</t>
		</section>

		<section title="Reference Models">
		<t>The generic models defined in <xref target="RFC4664" /> are applicable to PLE. 
		</t>
		<t>PLE embraces the minimum intervention principle outlined in section 3.3.5 of 
		<xref target="RFC3985" /> whereas the data is flowing through the PLE encapsulation 
		layer as received without modifications. 
		</t>
		<t>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.
		</t>
	
			<figure align="center" anchor="ref_model" title="PLE Reference Model">
				<artwork align="left"><![CDATA[

                |<--- 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

]]></artwork>
			</figure>

<t>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 <xref target="RFC4197" /> is applicable.
</t>	
	<figure align="center" anchor="diff_clock" title="Relative Network Scenario Timing">
		<artwork align="left"><![CDATA[
   
                    J
                    |                                         G
                    v                                         |
                    +-----+                 +-----+           v
   +-----+          |- - -|=================|- - -|          +-----+
   |     |<---------|.............................|<---------|     |
   | CE1 |          | PE1 |       VPWS      | PE2 |          | CE2 |
   |     |--------->|.............................|--------->|     |
   +-----+          |- - -|=================|- - -|          +-----+
        ^           +-----+<-------+------->+-----+
        |                          |              ^
        A                         +-+             |
                                  |I|             E
                                  +-+

]]></artwork>
	</figure>
<t>
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.</t>

<t>For the reverse direction PE1 does generate the clock J in reference to clock I and 
the clock difference between I and G.</t>

<t>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 <xref target="G.8261" /> and can be applied here as well.</t>

</section>
</section>


<section title="PLE Encapsulation Layer">
			<t>The basic packet format used by PLE is shown in the <xref target="encap" />.
			</t>
			
			<figure align="center" anchor="encap" title="PLE Encapsulation Layer">
				<artwork align="left"><![CDATA[
	+-------------------------------+  -+
	|     PSN and VPWS Demux        |    \
	|          (MPLS/SRv6)          |     > PSN and VPWS
	|                               |    /  Demux Headers
	+-------------------------------+  -+
	|        PLE Control Word       |    \
	+-------------------------------+     > PLE Header
	|           RTP Header          |    /
	+-------------------------------+ --+
	|          Bit Stream           |    \
	|           Payload             |     > Payload
	|                               |    /
	+-------------------------------+ --+

]]></artwork>
			</figure>
			
			<section title="PSN and VPWS Demultiplexing Headers">
				<t>This document does not imply any specific technology to be used for implementing 
				the VPWS demultiplexing and PSN layers.</t>
				
				<t> When a MPLS PSN layer is used. A VPWS label provides the demultiplexing
				mechanism as described in section 5.4.2 of <xref target="RFC3985" />. The PSN tunnel can be
				a simple best path Label Switched Path (LSP) established using LDP <xref target="RFC5036" />
				or Segment Routing <xref target="RFC8402" /> or a traffic engineered LSP established using
				RSVP-TE <xref target="RFC3209" /> or SR-TE <xref target="SRPOLICY" />.</t>
				
				<t>When PLE is applied to a SRv6 based PSN, the mechanisms defined in <xref target="RFC8402"/> and 
				the End.DX2 endpoint behavior defined in <xref target="SRV6NETPROG" /> do apply.</t>

			</section>
			
			<section title="PLE Header">
				<t>The PLE header MUST contain the PLE control word (4 bytes) and 
				MUST include a fixed size RTP header <xref target="RFC3550" />. The RTP 
				header MUST immediately follow the PLE control word.
				</t>			
				
			<section title="PLE Control Word">
				<t>The format of the PLE control word is in line with the guidance in <xref target="RFC4385" /> and as shown in <xref target="cw" />:
				</t>
				
				<figure align="center" anchor="cw" title="PLE Control Word">
					<artwork align="left"><![CDATA[
   
    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         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
				</figure>

				<t>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 
				<xref target="RFC4385" />.
				</t>
				
				<t> The other fields in the control word are used as defined below:
				</t>
				
				<t>L
					<list><t>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.
					</t>
					</list>
				</t>
				
				<t>R
					<list>
						<t>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.
						</t>
					</list>
				</t>
				
				<t>RSV
					<list>
						<t>These bits are reserved for future use. This field MUST be set to zero by the sender and ignored by 
						the receiver.
						</t>
					</list>				
				</t>
				
				<t>FRG
					<list>
						<t>These bits MUST be set to zero by the sender and ignored by the receiver.
						</t>
					</list>
				</t>
				
				<t>LEN
					<list>
						<t>In accordance to <xref target="RFC4385" /> 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.
						</t>
					</list>
				</t>
				
				<t>Sequence Number
					<list>
						<t>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 <xref target ="RFC3550" /> for the RTP sequence number and MUST 
						be incremented with every PLE packet being sent.
						</t>
					</list>
				</t>
			</section>
			
			<section title="RTP Header">
				<t>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.
				</t>
				
				<t>The format of the RTP header is as shown in <xref target="rtp" />:
				</t>
				
			<figure align="center" anchor="rtp" title="RTP Header">
				<artwork align="left"><![CDATA[
   
   
       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
			</figure>

	<t>V: Version
		<list>
			<t>The version field MUST be set to 2.
			</t>
		</list>
	</t>
	
	<t>P: Padding
		<list>
			<t>The padding flag MUST be set to zero by the sender and ignored by the 
			receiver.
			</t>
		</list>
	</t>
	
	<t>X: Header Extension
		<list>
			<t>The X bit MUST be set to zero by sender and ignored by receiver.
			</t>
		</list>
	</t>
	
	<t>CC: CSRC Count
		<list>
			<t>The CC field MUST be set to zero by the sender and ignored by the receiver.
			</t>
		</list>
	</t>
	
	<t>M: Marker
		<list>
			<t>The M bit MUST be set to zero by sender and ignored by receiver.
			</t>
		</list>
	</t>
	
	<t>PT: Payload Type
		<list>
			<t>A PT value MUST be allocated from the range of dynamic values define by <xref target="RFC3551" /> for each 
			direction of the VPWS.  The same PT value MAY be reused both for direction and between different PLE VPWS.
			</t>
		</list>
	</t>
	
	<t>Sequence Number
		<list>
			<t>The packet sequence number MUST continuously cycle from 0 to 0xFFFF.  It is 
			generated and processed in accordance with the rules established in 
			<xref target="RFC3550" />.  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.
			</t>
		</list>
	</t>
	
	<t>Timestamp
		<list>
			<t>Timestamp values are used in accordance with the
      rules established in <xref target="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.
			</t>
		</list>
	</t>
	
	<t>SSRC: Synchronization Source
		<list>
			<t>The SSRC field MAY be used for detection of misconnections.
			</t>
		</list>
	</t>
	
			</section>
			
		</section>
</section>





		
<section title="PLE Payload Layer">
	<t>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.
	</t>
	<t>All PLE implementations MUST be capable of supporting the default payload size of 1024 bytes.
	</t>

	<section anchor="structure_agnosic" title="Structure Agnostic Payload">

		<t>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.
		</t>
		<t>For PCS based attachment circuits supporting FEC the NSP function MUST terminate the FEC and pass the PCS encoded signal to the IWF function.
	</t>
	<t>For PCS based attachment circuits 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.
	</t>
		<t>A PLE implementation MUST support the structure agnostic payload for all bit-streams except the following:
		</t>
		<t>
			<list style="symbols">
				<t>OTN</t>
				<t>200GBASE-R ethernet</t>
				<t>400GBASE-R ethernet</t>
			</list>
		</t>
	</section>
	
	<section anchor="byte_aligned" title="Byte aligned Payload">
	
		<t>In case of OTN bit-streams, 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. 
		</t>
		<t>For byte aligned payloads PLE uses the following order for packetization:</t>
		<t><list style="symbols">
		<t>The order of the payload bytes corresponds to their order on the attachment circuit.</t>
		<t>Consecutive bits coming from the attachment circuit fill each payload byte starting from most 
		significant bit to least significant.</t>	
		</list></t>	
		<t>All PLE implementations MUST support the transport of OTN bit-streams using the byte aligned payload.</t>	
	</section>

	<section anchor="tentwoeightybit_aligned" title="10280bit-block aligned Payload">

		<t>In IEEE 802.3BS the PCS layer for 200GBASE-R and 400GBASE-R is defined with the functions shown in <xref target="twofourhungige" />. 
		</t>

	<figure align="center" anchor="twofourhungige" title="200GBASE-R and 400GBASE-R Functional Block Diagram">
					<artwork align="left"><![CDATA[
	   

	      Reconciliation Sublayer (RS)

            |                       ^
            v                       |
   +-----------------+     +-----------------+
   | encode and rate |     | decode and rate |
   |    matching     |     |     matching    |
   +-----------------+     +-----------------+
            v                       ^
   +-----------------+     +-----------------+
   |    256B/257B    |     |     reverse     |
   |    transcode    |     |    transcode    |
   +-----------------+     +-----------------+
            v                       ^            
   +-----------------+     +-----------------+  
   |     scramble    |     |    descramble   |  
   +-----------------+     +-----------------+  
            v                       ^             
   +-----------------+     +-----------------+
   |    alignment    |     |    alignment    |        
   |    insertion    |     |     removal     |    
   +-----------------+     +-----------------+       
            |                       ^              <-- IWF boundary
+-----------------------------------------------+        
|           v                       |           |
|  +-----------------+     +-----------------+  |
|  |     pre-FEC     |     |    post-FEC     |  |
|  |  distribution   |     |   interleave    |  |
|  +-----------------+     +-----------------+  |
|           v                       ^           |
|  +-----------------+     +-----------------+  |
|  |    FEC encode   |     |    FEC decode   |  |
|  +-----------------+     +-----------------+  |
|           v                       ^           |
|  +-----------------+     +-----------------+  |
|  |   distribution  |     |   lane reorder  |  |
|  |   & interleave  |     | & de-interleave |  |
|  +-----------------+     +-----------------+  |
|           |                       ^           |
|           |              +-----------------+  |
|           |              |  alignment lock |  |
|           |       NSP    |   lane deskew   |  |
|           |              +-----------------+  |
|           |                       ^           |
|           v                       |           |
|        Physical Medium Attachment (PMA)       |
+-----------------------------------------------+
	]]></artwork>
				</figure>

		<t>For 200GBASE-R and 400GBASE-R bit-streams, on ingress the NSP function will perform alignment lock and lane de-skew, lane order and de-interleave, FEC decode and post-FEC interleave as shown in <xref target="twofourhungige" />. After the post-FEC interleave the NSP function will create a stream of 10280 bit blocks (comprising of two 5140 code blocks).
		</t>
		<t>On the egress the IWF sends a stream of 10280 bit blocks to the NSP function and which performs pre-FEC distribution, FEC encode and distribute and interleave functions as shown in <xref target="twofourhungige" />.
		</t>
		<t>In the 10280 bit block stream, alignment markers exist every 4096, 10280 bit blocks (8192 code blocks) for 400GBASE-R and every 2048, 10280 bit blocks (4096 code blocks) for 200GBASE-R.
		</t>
		<t>On ingress the NSP must indicate to the IWF when a code word carries an alignment marker (or every n-th alignment marker where n is a multiple of 2). The IWF will create a PLE packet with the alignment marker bits at the beginning of the PLE payload. Considering the default PLE payload size of 1024 bytes, the PLE payload will contain the first 8096 bits (1024 bytes) of the 10280 bit block in the first packet. The following PLE packets will contain the remaining bits followed by the next 10280 bits.
		</t>
		<t>The egress NSP will recover the 10280 bit block by searching for the alignment markers at the beginning of PLE packets and recover the 10280 bit block stream.
		</t>
		<t>For the 10280 bit data streams the NSP will use the following order of packetization.
		</t>
		<t>
			<list style="symbols">
				<t>The first alignment bit of a 10280 bit block is always mapped to the first bit of a PLE payload</t>
				<t>The order of the bits corresponds to their order in the attached circuit</t>
				<t>Consecutive bits from the attached circuit are mapped directly into the PLE packet</t>
			</list>
		</t>
		<t>With the default payload size of 1024 bytes the alignment markers will be present at the start of every 5140-th PLE packet for 400GBASE-R and every 2570-th PLE packet for 200GBASE-R.
		</t>
		<t>Non-default payload sizes must be chosen so that alignment markers will always be at the start of every N-th packet.
		</t>
		<t>Alignment of the signal may use the alignment marker state machine defined in IEEE802.3BS.</t>

	</section>
</section>




<section title="PLE Operation">
	
	<section title="Common Considerations">
		<t>A PLE VPWS can be established using manual configuration or leveraging mechanisms of a signaling protocol</t>

		<t>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</t>

		<t>Extensions to the PWE3 <xref target="RFC4447"/> and EVPN-VPWS <xref target="RFC8214"/> control protocols are described
		in a separate document <xref target="PLESIG"/>.</t>
	</section>
	
	<section title="PLE IWF Operation">
	
	<section title="PSN-bound Encapsulation Behavior">
		<t>After the VPWS is set up, the PSN-bound IWF does perform the following steps:
		
		<list style="symbols">
			
			<t>Packetize the data received from the CE is into a fixed size PLE payloads</t>
				
			<t>Add PLE control word and RTP header with sequence numbers, flags and timestamps properly set</t>
				
			<t>Add the VPWS demultiplexer and PSN headers</t>

			<t>Transmit the resulting packets over the PSN</t>
			
			<t>Set L bit in the PLE control word whenever attachment circuit detects a fault</t>
			
			<t>Set R bit in the PLE control word whenever the local CE-bound IWF is in packet loss state</t>
		</list>
		</t>
	</section>
	
	<section title="CE-bound Decapsulation Behavior">
		<t>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.</t>
		
		<t>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.</t>
		
		<t>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.</t>
		
		<t>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.</t>
		
		<t>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).</t>
						
		<t>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.</t> 
		
		<t>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.</t>
		
		<t>The recovered clock MUST comply with the jitter and wander requirements applicable to the type of attachment 
		circuit, specified in:
		</t>
		<t><list style="symbols">
		<t><xref target="G.825" /> and <xref target="G.823" /> for SDH</t>
		<t><xref target="GR253" /> for SONET</t>
		<t><xref target="G.8261" /> for synchronous ethernet</t>
		<t><xref target="G.8251" /> for OTN</t>
		</list> 
		</t>
		
		<t>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.</t>
		
		<t>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.</t> 
		
		<t>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.
		</t>
		
		<t>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.
		</t>
		
		<t>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.
		</t>

		<t>Whenever the R bit is set in the PLE control word of a received PLE packet the PLE performance
			monitoring statistics SHOULD get updated.</t>
			
	</section>
	
	</section>
	

	<section title="PLE Performance Monitoring">
		<t>PLE SHOULD provide the following functions to monitor the network performance to be inline with expectations of transport
		network operators.</t>
		
		<t>The near-end performance monitors defined for PLE are as follows:
		<list>
		<t>ES-PLE : PLE Errored Seconds</t>
		<t>SES-PLE : PLE Severely Errored Seconds</t>
		<t>UAS-PLE : PLE Unavailable Seconds</t>
		</list>
		</t>
		<t>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.
		</t>
		<t>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.
		</t>
		<t>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.
		</t>
		<t>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.</t>

		<t>The PLE VPWS performance monitors are derived from the definitions in accordance with <xref target="G.826"/></t>
		
	</section>
	
	<section title="QoS and Congestion Control">
		<t>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 <xref target="RFC2913" />.
		</t>
		<t>Hence the PSN providing connectivity for the PLE VPWS between PE devices MUST be
		Diffserv <xref target="RFC2475" /> enabled and MUST provide a per domain 
		behavior <xref target="RFC3086" /> that guarantees low jitter and low loss. 
		</t> 
		<t>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.
		</t>
	</section>
	
	
</section>

<section anchor="Security" title="Security Considerations">

<t>As PLE is leveraging VPWS as transport mechanism the security considerations 
described in <xref target="RFC7432" /> and <xref target="RFC3985" /> are applicable.
</t>

    </section>

    <section anchor="IANA" title="IANA Considerations">

      <t>Applicable signaling extensions are out of the scope of this document.
      </t>
      <t>PLE does not introduce additional requirements from IANA.
      </t>

    </section>

    <section title="Acknowledgements">

      <t>The authors would like to thank Andreas Burk for reviewing this
   document and providing useful comments and suggestions.</t>

    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">
    	 <?rfc include="reference.RFC.8174"?>
    	 <?rfc include="reference.RFC.2119"?>
         <?rfc include="reference.RFC.3550"?>
         <?rfc include="reference.RFC.3551"?>        
	     <?rfc include="reference.RFC.3985"?>
   	     <?rfc include="reference.RFC.4664"?>
	     <?rfc include="reference.RFC.7432"?>
         <?rfc include="reference.RFC.4197"?>
         <?rfc include="reference.RFC.4385"?>
         <?rfc include="reference.RFC.4447"?>
         <?rfc include="reference.RFC.8214"?>
	     <?rfc include="reference.RFC.2475"?>
	     <?rfc include="reference.RFC.3086"?>

		<reference anchor="PLESIG" target="https://tools.ietf.org/html/draft-schmutzer-bess-ple-vpws-signalling">
    	<front><title>Private Line Emulation VPWS Signalling</title><author>
    	<organization>IETF</organization></author><date/></front>
    	</reference>
    	
    	<reference anchor="G.825" target="https://www.itu.int/rec/T-REC-G.825">
        <front><title>G.825: The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH)</title><author>
        <organization>International Telecommunication Union (ITU)</organization></author><date/></front>
		</reference>
		
		<reference anchor="G.823" target="https://www.itu.int/rec/T-REC-G.823">
        <front><title>G.823: The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy</title><author>
        <organization>International Telecommunication Union (ITU)</organization></author><date/></front>
		</reference>
		
		<reference anchor="G.8261" target="https://www.itu.int/rec/T-REC-G.8251">
        <front><title>G.8261: Timing and synchronization aspects in packet networks</title><author>
        <organization>International Telecommunication Union (ITU)</organization></author><date/></front>
		</reference>
		
		<reference anchor="G.8251" target="https://www.itu.int/rec/T-REC-G.8251">
        <front><title>G.8251: The control of jitter and wander within the optical transport network (OTN)</title><author>
        <organization>International Telecommunication Union (ITU)</organization></author><date/></front>
		</reference>
         
	  </references>

	<references title="Informative References">

    <?rfc include="reference.RFC.3209"?>
    <?rfc include="reference.RFC.4553"?>
    <?rfc include="reference.RFC.5036"?>
    <?rfc include="reference.RFC.5086"?>
    <?rfc include="reference.RFC.8402"?>
    <?rfc include="reference.RFC.4842"?>

	<reference anchor="G.709" target="https://www.itu.int/rec/T-REC-G.709">
        <front><title>G.709: Interfaces for the optical transport network</title><author>
        <organization>International Telecommunication Union (ITU)</organization></author><date/></front>
	</reference>

 	<reference anchor="SRPOLICY" target="https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy">
    	<front><title>Segment Routing Policy Architecture</title><author>
    	<organization>IETF</organization></author><date/></front>
    </reference> 
    
    <reference anchor="SRV6NETPROG" target="https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming">
		<front><title>SRv6 Network Programming</title><author>
		<organization>IETF</organization></author><date/></front>
	</reference> 
	
	<reference anchor="GR253" target="https://telecom-info.telcordia.com">
		<front><title>SONET Transport Systems : Common Generic Criteria</title><author>
		<organization>Telcordia</organization></author><date/></front>
	</reference> 
	
	<reference anchor="G.707" target="https://www.itu.int/rec/T-REC-G.707">
		<front><title>Network node interface for the synchronous digital hierarchy (SDH)</title><author>
		<organization>ITU-T</organization></author><date/></front>
	</reference>

	<reference anchor="G.826" target="https://www.itu.int/rec/T-REC-G.826">
		<front><title>End-to-end error performance parameters and objectives for international, constant bit-rate
			digital paths and connections</title><author>
		<organization>ITU-T</organization></author><date/></front>
	</reference>
	
	<?rfc include="reference.RFC.2913"?>

    </references>
    

  </back>
</rfc>