<?xml version='1.0' encoding='utf-8'?>


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pals-ple-15" number="9801" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" updates="" obsoletes="" xml:lang="en">

  <front>
   
    
    <title abbrev="PLE over PSNs">Private Line Emulation over Packet Switched Networks</title>
    <seriesInfo name="RFC" value="9801"/>
    <author initials="S." surname="Gringeri" fullname="Steven Gringeri">
      <organization>Verizon</organization>
      <address>
        <email>steven.gringeri@verizon.com</email>
      </address>
    </author>
    <author initials="J." surname="Whittaker" fullname="Jeremy Whittaker">
      <organization>Verizon</organization>
      <address>
        <email>jeremy.whittaker@verizon.com</email>
      </address>
    </author>
    <author initials="N." surname="Leymann" fullname="Nicolai Leymann">
      <organization>Deutsche Telekom</organization>
      <address>
        <email>N.Leymann@telekom.de</email>
      </address>
    </author>
    <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>cschmutz@cisco.com</email>
      </address>
    </author>
    <author initials="C." surname="Brown" fullname="Chris Brown">
      <organization>Ciena Corporation</organization>
      <address>
        <email>cbrown@ciena.com</email>
      </address>
    </author>
    <date year="2025" month="July"/>
    <area>RTG</area>
    <workgroup>pals</workgroup>

    <abstract>
      <t>This document expands the applicability of Virtual Private Wire
      Service (VPWS) bit-stream payloads beyond Time Division Multiplexing
      (TDM) signals and provides pseudowire transport with complete signal
      transparency over Packet Switched Networks (PSNs).</t>
    </abstract>
  </front>
  <middle>

<section anchor="introduction-and-motivation">
      <name>Introduction and Motivation</name>
      <t>This document describes a method called Private Line Emulation (PLE) for encapsulating not only Time Division Multiplexing (TDM) signals as bit-stream Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN). In this regard, it complements methods described in <xref target="RFC4553"/>.</t>
      <t>This emulation suits applications, where carrying Protocol Data Units (PDUs) as defined in <xref target="RFC4906"/> or <xref target="RFC4448"/> is not enough, physical layer signal transparency is required and data or framing structure interpretation of the Provider Edge (PE) would be counterproductive.</t>
      <t>One example of such case is two Ethernet-connected Customer Edge (CE) devices and the need for Synchronous Ethernet operation (see <xref target="G.8261"/>) between them without the intermediate PE devices interfering or addressing concerns about Ethernet control protocol transparency for PDU-based carrier Ethernet services, beyond the behavior definitions of MEF Forum (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 defined by <xref target="T11"/>.</t>
      <t>Also, SONET/SDH (Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH)) add/drop multiplexers or cross-connects can be interconnected without interfering with the multiplexing structures and networks mechanisms. This is a key distinction to Circuit Emulation over Packet (CEP) defined in <xref target="RFC4842"/> where multiplexing and demultiplexing is desired in order to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual Container (VC). In other words, PLE provides an independent layer network underneath the SONET/SDH layer network, whereas CEP operates at the same level and peer with the SONET/SDH layer network.</t>
      <t>The mechanisms described in this document follow principles similar to Structure-Agnostic TDM over Packet (SAToP) (defined in <xref target="RFC4553"/>). The applicability is expanded beyond the narrow set of Plesiochronous Digital Hierarchy (PDH) interfaces (T1, E1, T3, and E3) to allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH (<xref target="GR253"/> / <xref target="G.707"/>), and Optical Transport Network (OTN) <xref target="G.709"/> at gigabit speeds. The signals are treated as bit-stream payload, which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in Sections <xref target="RFC3985" sectionFormat="bare" section="3.3.3"/> and <xref target="RFC3985" sectionFormat="bare" section="3.3.4"/> of <xref target="RFC3985"/>.</t>
    </section>
    <section anchor="requirements-notation">
      <name>Requirements Notation</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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 anchor="terminology-and-reference-model">
      <name>Terminology and Reference Models</name>

<section anchor="terminology">

        <name>Abbreviations</name>
        <dl spacing="normal" newline="false">
            <dt>ACH:</dt><dd>Associated Channel Header <xref target="RFC7212"/></dd>
            <dt>AIS:</dt><dd>Alarm Indication Signal</dd>
            <dt>AIS-L:</dt><dd>Line AIS</dd>
            <dt>MS-AIS:</dt><dd>Multiplex Section AIS</dd>
            <dt>BITS:</dt><dd>Building Integrated Timing Supply <xref target="ATIS-0900105.09.2013"/></dd>
            <dt>CBR:</dt><dd>Constant Bit Rate</dd>
            <dt>CE:</dt><dd>Customer Edge</dd>
            <dt>CEP:</dt><dd>Circuit Emulation over Packet <xref target="RFC4842"/></dd>
	    <dt>CSID:</dt><dd>Compressed SID</dd>
            <dt>CSRC:</dt><dd>Contributing Source <xref target="RFC3550"/></dd>
            <dt>DEG:</dt><dd>Degradation</dd>
            <dt>ES:</dt><dd>Errored Second</dd>
            <dt>FEC:</dt><dd>Forward Error Correction</dd>
            <dt>ICMP:</dt><dd>Internet Control Message Protocol <xref target="RFC4443"/></dd>
            <dt>IEEE:</dt><dd>Institute of Electrical and Electronics Engineers</dd>
            <dt>INCITS:</dt><dd>INternational Committee for Information Technology Standards</dd>
            <dt>IWF:</dt><dd>Interworking Function</dd>
            <dt>LDP:</dt><dd>Label Distribution Protocol <xref target="RFC5036"/>, <xref target="RFC8077"/></dd>
            <dt>LF:</dt><dd>Local Fault</dd>
            <dt>LOF:</dt><dd>Loss Of Frame</dd>
            <dt>LOM:</dt><dd>Loss Of Multiframe</dd>
            <dt>LOS:</dt><dd>Loss Of Signal</dd>
            <dt>LPI:</dt><dd>Low Power Idle</dd>
            <dt>LSP:</dt><dd>Label Switched Path</dd>
            <dt>MEF:</dt><dd>MEF Forum</dd>
            <dt>MPLS:</dt><dd>Multiprotocol Label Switching <xref target="RFC3031"/></dd>
            <dt>NOS:</dt><dd>Not Operational</dd>
            <dt>NSP:</dt><dd>Native Service Processing <xref target="RFC3985"/></dd>
            <dt>ODUk:</dt><dd>Optical Data Unit k</dd>
	    <dt>OOF:</dt><dd>Out Of Frame</dd>
            <dt>OTN:</dt><dd>Optical Transport Network</dd>
            <dt>OTUk:</dt><dd>Optical Transport Unit k</dd>
            <dt>PCS:</dt><dd>Physical Coding Sublayer</dd>
            <dt>PDV:</dt><dd>Packet Delay Variation</dd>
            <dt>PE:</dt><dd>Provider Edge</dd>
            <dt>PLE:</dt><dd>Private Line Emulation</dd>
            <dt>PLOS:</dt><dd>Packet Loss Of Signal</dd>
            <dt>PLR:</dt><dd>Packet Loss Rate</dd>
            <dt>PMA:</dt><dd>Physical Medium Attachment</dd>
            <dt>PMD:</dt><dd>Physical Medium Dependent</dd>
            <dt>PSN:</dt><dd>Packet Switched Network</dd>
            <dt>PTP:</dt><dd>Precision Time Protocol</dd>
            <dt>PW:</dt><dd>Pseudowire <xref target="RFC4664"/></dd>
            <dt>PWE3:</dt><dd>Pseudo Wire Emulation Edge-to-Edge <xref target="RFC3985"/></dd>
            <dt>RDI:</dt><dd>Remote Defect Indication</dd>
            <dt>RSVP-TE:</dt><dd>Resource Reservation Protocol Traffic Engineering <xref target="RFC4875"/></dd>
            <dt>RTCP:</dt><dd>RTP Control Protocol <xref target="RFC3550"/></dd>
            <dt>RTP:</dt><dd>Real-time Transport Protocol <xref target="RFC3550"/></dd>
            <dt>SD:</dt><dd>Signal Degrade</dd>
            <dt>SES:</dt><dd>Severely Errored Seconds</dd>
            <dt>SDH:</dt><dd>Synchronous Digital Hierarchy</dd>
            <dt>SID:</dt><dd>Segment Identifier <xref target="RFC8402"/></dd>
            <dt>SR:</dt><dd>Segment Routing <xref target="RFC8402"/></dd>
            <dt>SRH:</dt><dd>Segment Routing Header <xref target="RFC8754"/></dd>
            <dt>SRTP:</dt><dd>Secure Real-time Transport Protocol <xref target="RFC3711"/></dd>
            <dt>SRv6:</dt><dd>Segment Routing over IPv6 <xref target="RFC8986"/></dd>
            <dt>SSRC:</dt><dd>Synchronization Source <xref target="RFC3550"/></dd>
            <dt>SONET:</dt><dd>Synchronous Optical Network</dd>
            <dt>TCP:</dt><dd>Transmission Control Protocol <xref target="RFC9293"/></dd>
            <dt>TDM:</dt><dd>Time Division Multiplexing</dd>
            <dt>TTS:</dt><dd>Transmitter Training Signal</dd>
            <dt>UAS:</dt><dd>Unavailable Seconds</dd>
            <dt>VPWS:</dt><dd>Virtual Private Wire Service <xref target="RFC3985"/></dd>
          </dl>
	  <aside>
        <t>Note: 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></aside>
      </section>
      <section anchor="reference-models">
        <name>Reference Models</name>
        <t>The reference model for PLE is illustrated in <xref target="ref_model"/> and is inline with the reference model defined in <xref section="4.1" sectionFormat="of" target="RFC3985"/>. PLE relies on PWE3 preprocessing, in particular the concept of an NSP function defined in <xref section="4.2.2" sectionFormat="of" target="RFC3985"/>.</t>
        <figure anchor="ref_model">
          <name>PLE Reference Model</name>
          <artwork><![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>PLE embraces the minimum intervention principle outlined in <xref section="3.3.5" sectionFormat="of" target="RFC3985"/>, which means the data is flowing through the PLE encapsulation layer as received without modifications.</t>
        <t>For some service types, the NSP function is responsible for performing operations on the data received from the CE. Examples are terminating FEC, terminating the OTUk layer for OTN, or dealing with multi-lane processing. After the NSP, the IWF is generating the payload of the VPWS, which is carried via a PSN tunnel.</t>
        <t>To allow the clock of the transported signal to be carried across the PLE domain in a transparent way, the relative network synchronization reference model and deployment scenario outlined in <xref section="4.3.2" sectionFormat="of" target="RFC4197"/> are applicable and are shown in <xref target="diff_clock"/>.</t>
        <figure anchor="diff_clock">
          <name>Relative Network Scenario Timing</name>
          <artwork><![CDATA[
                  J
                  |                                           G
                  |                                           |
                  | +-----+                 +-----+           v
   +-----+        v |- - -|=================|- - -|          +-----+
   |     |<---------|.............................|<---------|     |
   | CE1 |          | PE1 |       VPWS      | PE2 |          | CE2 |
   |     |--------->|.............................|--------->|     |
   +-----+          |- - -|=================|- - -| ^        +-----+
        ^           +-----+                 +-----+ |
        |              ^ C                   D ^    |
        A              |                       |    |
                       +-----------+-----------+    E
                                   |
                                  +-+
                                  |I|
                                  +-+
]]></artwork>
        </figure>
        <t>The local oscillators C of PE1 and D of PE2 are locked to a common clock I.</t>
        <t>The attachment circuit clock E is generated by PE2 via a differential clock recovery method in reference to the common clock I. For this to work, the difference between clock A and clock C (locked to I) <bcp14>MUST</bcp14> be explicitly transferred from PE1 to PE2 using the timestamp inside the RTP header.</t>
	
        <t>For the reverse direction, PE1 generates the attachment circuit clock J and the clock difference between G and D (locked to I) is transferred from PE2 to PE1.</t>
        <t>The method used to lock clocks C and D to the common clock I is out of scope of this document; however, there are already several well-established concepts for achieving clock synchronization (commonly also referred to as "frequency synchronization") available.</t>
        <t>While using external timing inputs (aka BITS <xref target="ATIS-0900105.09.2013"/>) or synchronous Ethernet (as defined in <xref target="G.8261"/>), the characteristics and limits defined in <xref target="G.8262"/> have to be considered.</t>
        <t>While relying on PTP (as defined in <xref target="G.8265.1"/>), the network limits defined in <xref target="G.8261.1"/> have to be considered.</t>
      </section>
    </section>
    <section anchor="emulated-services">
      <name>Emulated Services</name>
      <t>This specification describes the emulation of services from a wide range of technologies, such as TDM, Ethernet, Fibre Channel, or OTN, as bit-streams or structured bit-streams, as defined in Sections <xref target="RFC3985" sectionFormat="bare" section="3.3.3"/> and <xref target="RFC3985" sectionFormat="bare" section="3.3.4"/> of <xref target="RFC3985"/>.</t>
      <section anchor="generic-ple-service">
        <name>Generic PLE Service</name>
        <t>The generic PLE service is an example of the bit-stream defined in <xref section="3.3.3" sectionFormat="of" target="RFC3985"/>.</t>
        <t>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.</t>
        <t>There is no NSP function present for this service.</t>
      </section>
      <section anchor="ethernet-services">
        <name>Ethernet Services</name>
        <t>Ethernet services are special cases of the structured bit-stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>The IEEE has defined several layers for Ethernet in <xref target="IEEE802.3"/>. Emulation is operating at the physical (PHY) layer, more precisely at the PCS.</t>
        <t>Over time, many different Ethernet interface types have been specified in <xref target="IEEE802.3"/> with a varying set of characteristics, such as optional versus mandatory FEC and single-lane versus multi-lane transmission.</t>
        <t>Ethernet interface types with backplane PMD variants and Ethernet interface types mandating auto-negotiation (except 1000Base-X) are out of scope for this document.</t>
        <t>All Ethernet services are leveraging the basic PLE payload and interface-specific mechanisms are confined to the respective service specific NSP functions.</t>
        <section anchor="base-x">
          <name>1000BASE-X</name>
          <t>The PCS layer of 1000BASE-X (defined in Section 36 of <xref target="IEEE802.3"/>) is based on 8B/10B code.</t>
          <t>The PSN-bound NSP function does not modify the received data and is transparent to auto-negotiation; however, it is responsible for detecting attachment circuit faults specific to 1000BASE-X such as LOS and sync loss.</t>
          <t>When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function <bcp14>MAY</bcp14> disable its transmitter as no appropriate maintenance signal was defined for 1000BASE-X by the IEEE.</t>
        </section>
        <section anchor="gbase-r-and-25gbase-r">
          <name>10GBASE-R and 25GBASE-R</name>
          <t>The PCS layers of 10GBASE-R (defined in Section 49 and 25GBASE-R defined in Section 107 of <xref target="IEEE802.3"/>) are based on a 64B/66B code.</t>
          <t>Sections 74 and 108 of <xref target="IEEE802.3"/> define an optional FEC layer; if present, the PSN-bound NSP function <bcp14>MUST</bcp14> terminate the FEC and the CE-bound NSP function <bcp14>MUST</bcp14> generate the FEC.</t>
          <t>The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 10GBASE-R and 25GBASE-R such as LOS and sync loss.</t>
          <t>The PSN-bound IWF maps the scrambled 64B/66B code stream into the basic PLE payload.</t>

	  
          <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>PCS code sync (Section 49.2.9 of <xref target="IEEE802.3"/>) and</t>
            </li>
            <li>
              <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>in order to properly:</t>
          <ul spacing="normal">
            <li>
              <t>transform invalid 66B code blocks into proper error control characters /E/ (Section 49.2.4.11 of <xref target="IEEE802.3"/>) and</t>
            </li>
            <li>
              <t>insert LF ordered sets (Section 46.3.4 of <xref target="IEEE802.3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
            </li>
          </ul>
	  <aside>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function setting sync headers to 11 due to uncorrectable FEC errors.</t></aside>
          <t>Before sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14> also scramble the 64B/66B code stream (Section 49.2.6 <xref target="IEEE802.3"/>).</t>
        </section>
        <section anchor="gbase-r-50gbase-r-and-100gbase-r">
          <name>40GBASE-R, 50GBASE-R, and 100GBASE-R</name>
          <t>The PCS layers of 40GBASE-R and 100GBASE-R (defined in Section 82 of  <xref target="IEEE802.3"/>) and of 50GBASE-R (defined in Section 133 of <xref target="IEEE802.3"/>) are based on a 64B/66B code transmitted over multiple lanes.</t>
          <t>Sections 74 and 91 of <xref target="IEEE802.3"/> define an optional FEC layer; if present, the PSN-bound NSP function <bcp14>MUST</bcp14> terminate the FEC and the CE-bound NSP function <bcp14>MUST</bcp14> generate the FEC.</t>
          <t>To gain access to the scrambled 64B/66B code stream, the PSN-bound NSP further <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>block synchronization (Section 82.2.12 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>PCS lane de-skew (Section 82.2.13 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>PCS lane reordering (Section 82.2.14 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>
          <t>The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 40GBASE-R, 50GBASE-R, and 100GBASE-R  such as LOS and loss of alignment.</t>
          <t>The PSN-bound IWF maps the serialized and scrambled 64B/66B code stream including the alignment markers into the basic PLE payload.</t>
          <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>PCS code sync (Section 82.2.12 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>alignment-marker removal (Section 82.2.15 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>in order to properly:</t>
          <ul spacing="normal">
            <li>
              <t>transform invalid 66B code blocks into proper error control characters /E/ (Section 82.2.3.10 of <xref target="IEEE802.3"/>) and</t>
            </li>
            <li>
              <t>insert LF ordered sets (Section 81.3.4 of <xref target="IEEE802.3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>

            </li>
          </ul>
	  <aside>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.</t></aside>
          <t>When sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14> also perform:</t>
          <ul spacing="normal">
            <li>
              <t>scrambling of the 64B/66B code (Section 49.2.6 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>block distribution (Section 82.2.6 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>alignment-marker insertion (Sections 82.2.7 and 133.2.2 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>
        </section>
        <section anchor="gbase-r-and-400gbase-r">
          <name>200GBASE-R and 400GBASE-R</name>
          <t>The PCS layers of 200GBASE-R and 400GBASE-R (defined in Section 119 of <xref target="IEEE802.3"/>) are based on a 64B/66B code transcoded to a 256B/257B code to reduce the overhead and make room for a mandatory FEC.</t>
          <t>To gain access to the 64B/66B code stream, the PSN-bound NSP further <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>alignment lock and de-skew (Section 119.2.5.1 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>PCS lane reordering and de-interleaving (Section 119.2.5.2 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>FEC decoding (Section 119.2.5.3 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>post-FEC interleaving (Section 119.2.5.4 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>alignment-marker removal (Section 119.2.5.5 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>descrambling (Section 119.2.5.6 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>
          <t>Further, the PSN-bound NSP <bcp14>MUST</bcp14> perform rate compensation and scrambling (Section 49.2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF maps the same into the basic PLE payload.</t>
          <t>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; 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.</t>
          <t>The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 200GBASE-R and 400GBASE-R such as LOS and loss of alignment.</t>
          <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>PCS code sync (Section 49.2.13 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>rate compensation block removal</t>
            </li>
          </ul>
          <t>in order to properly:</t>
          <ul spacing="normal">
            <li>
              <t>transform invalid 66B code blocks into proper error control characters /E/ (Section 119.2.3.9 of <xref target="IEEE802.3"/>) and</t>
            </li>
            <li>
              <t>insert LF ordered sets (Section 81.3.4 of <xref target="IEEE802.3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
            </li>
          </ul>
	  <aside>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.</t></aside>
          <t>When sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14> also perform:</t>
          <ul spacing="normal">
            <li>
              <t>transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>scrambling (Section 119.2.4.3 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>alignment-marker insertion (Section 119.2.4.4 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>pre-FEC distribution (Section 119.2.4.5 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>FEC encoding (Section 119.2.4.6 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>PCS lane distribution (Section 119.2.4.8 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>
        </section>
        <section anchor="energy-efficient-ethernet-eee">
          <name>Energy Efficient Ethernet (EEE)</name>
          <t>Section 78 of <xref target="IEEE802.3"/> defines the optional LPI capability for Ethernet. Two modes are defined:</t>
          <ul spacing="normal">
            <li>
              <t>deep sleep</t>
            </li>
            <li>
              <t>fast wake</t>
            </li>
          </ul>
          <t>Deep sleep mode is not compatible with PLE due to the CE ceasing transmission. Hence, there is no support for LPI for 10GBASE-R services across PLE.</t>
          <t>In fast wake mode, the CE transmits /LI/ control code blocks instead of /I/ control code blocks and, therefore, PLE is agnostic to it. For 25GBASE-R and higher services across PLE, LPI is supported as only fast wake mode is applicable.</t>
        </section>
      </section>
      <section anchor="sonetsdh-services">
        <name>SONET/SDH Services</name>
        <t>SONET/SDH services are special cases of the structured bit-stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>SDH interfaces are defined in <xref target="G.707"/>; SONET interfaces are defined in <xref target="GR253"/>.</t>
        <t>The PSN-bound NSP function does not modify the received data but is responsible for detecting attachment circuit faults specific to SONET/SDH such as LOS, LOF, and OOF.</t>
        <t>Data received by the PSN-bound IWF is mapped into the basic PLE payload without any awareness of SONET/SDH frames.</t>
        <t>When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function is responsible for generating the:</t>
        <ul spacing="normal">
          <li>
            <t>MS-AIS maintenance signal (defined in Section 6.2.4.1.1 of <xref target="G.707"/>) for SDH services and</t>
          </li>
          <li>
            <t>AIS-L maintenance signal (defined in Section 6.2.1.2 of <xref target="GR253"/>) for SONET services</t>
          </li>
        </ul>
        <t>at client-frame boundaries.</t>
      </section>
      <section anchor="fibre-channel-services">
        <name>Fibre Channel Services</name>
        <t>Fibre Channel services are special cases of the structured bit-stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>The T11 technical committee of INCITS has defined several layers for Fibre Channel. PLE operates at the FC-1 layer that leverages mechanisms defined by <xref target="IEEE802.3"/>.</t>
        <t>Over time, many different Fibre Channel interface types have been specified with a varying set of characteristics such as optional versus mandatory FEC and single-lane versus multi-lane transmission.</t>
        <t>Speed negotiation is not supported by PLE.</t>
        <t>All Fibre Channel services leverage the basic PLE payload, and interface-specific mechanisms are confined to the respective service-specific NSP functions.</t>
        <section anchor="gfc-2gfc-4gfc-and-8gfc">
          <name>1GFC, 2GFC, 4GFC, and 8GFC</name>
          <t><xref target="FC-PI-2"/> specifies 1GFC and 2GFC. <xref target="FC-PI-5"/> and <xref target="FC-PI-5am1"/> define 4GFC and 8GFC.</t>
          <t>The PSN-bound NSP function is responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
          <t>The PSN-bound IWF maps the received 8B/10B code stream as is directly into the basic PLE payload.</t>
          <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform transmission word sync in order to properly:</t>
          <ul spacing="normal">
            <li>
              <t>replace invalid transmission words with the special character K30.7 and</t>
            </li>
            <li>
              <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
            </li>
          </ul>
	  <aside>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets.</t></aside>
          <t><xref target="FC-PI-5am1"/> defines the use of scrambling for 8GFC; in this case, the CE-bound NSP <bcp14>MUST</bcp14> also perform descrambling before replacing invalid transmission words or inserting NOS ordered sets.  Before sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14> scramble the 8B/10B code stream.</t>
        </section>
        <section anchor="gfc">
          <name>16GFC</name>
          <t><xref target="FC-PI-5"/> and <xref target="FC-PI-5am1"/> specify 16GFC and define an optional FEC layer.</t>
          <t>If FEC is present, it must be indicated via TTS when the attachment circuit is brought up. Further, the PSN-bound NSP function <bcp14>MUST</bcp14> terminate the FEC and the CE-bound NSP function must generate the FEC.</t>
          <t>The PSN-bound NSP function is responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
          <t>The PSN-bound IWF maps the received scrambled 64B/66B code stream as is into the basic PLE payload.</t>
          <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>transmission word sync (Section 49.2.13 of <xref target="IEEE802.3"/>) and</t>
            </li>
            <li>
              <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>in order to properly:</t>
          <ul spacing="normal">
            <li>
              <t>replace invalid transmission words with the error transmission word 1Eh and</t>
            </li>
            <li>
              <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
            </li>
          </ul>
	  <aside>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.</t></aside>
          <t>Before sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14> also scramble the 64B/66B code stream (Section 49.2.6 of <xref target="IEEE802.3"/>).</t>
        </section>
        <section anchor="gfc-and-4-lane-128gfc">
          <name>32GFC and 4-Lane 128GFC</name>
          <t><xref target="FC-PI-6"/> specifies 32GFC and <xref target="FC-PI-6P"/> specifies 4-lane 128GFC, both with FEC layer and TTS support being mandatory.</t>
          <t>To gain access to the 64B/66B code stream the PSN-bound NSP further <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>descrambling (Section of 49.2.10 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>FEC decoding (Section 91.5.3.3 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>


<t>Further, the PSN-bound NSP <bcp14>MUST</bcp14> perform scrambling (Section 49.2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF maps the same into the basic PLE payload.</t>
          <t>The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to the  Fibre Channel such as LOS and sync loss.</t>
          <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>transmission word sync (Section 119.2.6.3 of <xref target="IEEE802.3"/>) and</t>
            </li>
            <li>
              <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>in order to properly:</t>
          <ul spacing="normal">
            <li>
              <t>replace invalid transmission words with the error transmission word 1Eh and</t>
            </li>
            <li>
              <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
            </li>
          </ul>
	  <aside>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.</t></aside>
          <t>When sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14> also perform:</t>
          <ul spacing="normal">
            <li>
              <t>transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>FEC encoding (Section 91.5.2.7 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>scrambling (Section 49.2.6 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>
        </section>
        <section anchor="gfc-1">
          <name>64GFC</name>

<t><xref target="FC-PI-7"/> specifies 64GFC with a mandatory FEC layer.</t>
          <t>To gain access to the 64B/66B code stream, the PSN-bound NSP further <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>alignment lock (Section 134.5.4 of <xref target="IEEE802.3"/> modified to single FEC lane operation),</t>
            </li>
            <li>
              <t>FEC decoding (Section 134.5.3.3 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>alignment-marker removal (Section 134.5.3.4 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>reverse transcoding from 256B/257B to 64B/66B (Section 91.5.3.5 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>
          <t>Further, the PSN-bound NSP <bcp14>MUST</bcp14> perform scrambling (Section 49.2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF maps the same into the basic PLE payload.</t>
          <t>The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
          <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>transmission word sync (Section 49.2.13 of <xref target="IEEE802.3"/>) and</t>
            </li>
            <li>
              <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>in order to properly:</t>
          <ul spacing="normal">
            <li>
              <t>replace invalid transmission words with the error transmission word 1Eh and</t>
            </li>
            <li>
              <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
            </li>
          </ul>
	  <aside>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or  the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.</t></aside>
          <t>When sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14> also perform:</t>
          <ul spacing="normal">
            <li>
              <t>transcoding from 64B/66B to 256B/257B (Section 91.5.2.5 of <xref target="IEEE802.3"/>),</t>
            </li>
            <li>
              <t>alignment-marker insertion (Section 134.5.2.6 of <xref target="IEEE802.3"/>), and</t>
            </li>
            <li>
              <t>FEC encoding (Section 134.5.2.7 of <xref target="IEEE802.3"/>).</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="otn-services">
        <name>OTN Services</name>
        <t>OTN services are special cases of the structured bit-stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>OTN interfaces are defined in <xref target="G.709"/>.</t>
        <t>The PSN-bound NSP function <bcp14>MUST</bcp14> terminate the FEC and replace the OTUk overhead in row 1, columns 8-14 with an all-zeros pattern; this results in an extended ODUk frame as illustrated in <xref target="extodukframe"/>. The frame alignment overhead (FA OH) in row 1, columns 1-7 is kept as it is.</t>
        <figure anchor="extodukframe">
          <name>Extended ODUk Frame</name>
          <artwork><![CDATA[
                                column #
    1      7 8     14 15                                      3824
   +--------+--------+------------------- .. --------------------+
  1|  FA OH | All-0s |                                           |
   +--------+--------+                                           |
r 2|                 |                                           |
o  |                 |                                           |
w 3|  ODUk overhead  |                                           |
#  |                 |                                           |
  4|                 |                                           |
   +-----------------+------------------- .. --------------------+
]]></artwork>
        </figure>
        <t>The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to OTUk such as LOS, LOF, LOM, and AIS.</t>
        <t>The PSN-bound IWF maps the extended ODUk frame into the byte-aligned PLE payload.</t>
        <t>The CE-bound NSP function will recover the ODUk by searching for the frame alignment overhead in the extended ODUk received from the CE-bound IWF and generating the FEC.</t>
        <t>When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function is responsible for generating the ODUk-AIS maintenance signal defined in Section 16.5.1 of <xref target="G.709"/> at client-frame boundaries.</t>
      </section>
    </section>
    <section anchor="ple-encapsulation-layer">
      <name>PLE Encapsulation Layer</name>
      <t>The basic packet format used by PLE is shown in <xref target="encap"/>.</t>
      <figure anchor="encap">
        <name>PLE Encapsulation Layer</name>
        <artwork><![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 anchor="psn-and-vpws-demultiplexing-headers">
        <name>PSN and VPWS Demultiplexing Headers</name>
        <t>This document does not suggest any specific technology be used for implementing the VPWS demultiplexing and PSN layers.</t>
        <t>The total size of a PLE packet for a specific PW <bcp14>MUST NOT</bcp14> exceed the path MTU between the pair of PEs terminating this PW.</t>
        <t>When an MPLS PSN layer is used, a VPWS label provides the demultiplexing mechanism (as described in <xref section="5.4.2" sectionFormat="of" target="RFC3985"/>). The PSN tunnel can be a simple best-path LSP established using LDP (see <xref target="RFC5036"/>) or Segment Routing (SR) (see <xref target="RFC8402"/>); or it can be a traffic-engineered LSP established using RSVP-TE (see <xref target="RFC3209"/>) or SR policies (see <xref target="RFC9256"/>).</t>
        <t>When an SRv6 PSN layer is used, an SRv6 service SID (as defined in <xref target="RFC8402"/>) provides the demultiplexing mechanism and definitions of <xref section="6" sectionFormat="of" target="RFC9252"/> apply. Both SRv6 service SIDs with the full IPv6 address format defined in <xref target="RFC8986"/> and CSIDs with the format defined in <xref target="RFC9800"/> can be used.</t>
        <section anchor="new-srv6-behaviors">
          <name>New SRv6 Behaviors</name>
          <t>Two new encapsulation behaviors, H.Encaps.L1 and H.Encaps.L1.Red, are defined in this document. The behavior procedures are applicable to both SIDs and CSIDs.</t>
          <t>The H.Encaps.L1 behavior encapsulates a frame received from an IWF in an IPv6 packet with a segment routing header (SRH). The received frame becomes the payload of the new IPv6 packet.</t>
          <ul spacing="normal">
            <li>
              <t>The next header field of the SRH or the last extension header present <bcp14>MUST</bcp14> be set to 147.</t>
            </li>
            <li>
              <t>The insertion of the SRH <bcp14>MAY</bcp14> be omitted per <xref target="RFC8986"/> when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.</t>
            </li>
          </ul>
          <t>The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.</t>
          <ul spacing="normal">
            <li>
	      
              <t>H.Encaps.L1.Red reduces the length of the SRH by excluding the first SID in the SRH. The first SID is only placed in the Destination Address field of the IPv6 header.</t>
            </li>
            <li>
              <t>The insertion of the SRH <bcp14>MAY</bcp14> be omitted per <xref target="RFC8986"/> when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.</t>
            </li>
          </ul>
          <t>Three new "Endpoint with decapsulation and bit-stream cross-connect" behaviors called "End.DX1", "End.DX1 with NEXT-CSID", and "End.DX1 with REPLACE-CSID" are defined in this document. These new behaviors are variants of End.DX2 defined in <xref target="RFC8986"/>, and they all have the following procedures in common:</t>
          <t>The End.DX1 SID <bcp14>MUST</bcp14> be the last segment in an SR Policy, and it is associated with a CE-bound IWF I. When N receives a packet destined to S and S is a local End.DX1 SID, N does the following:</t>
          <sourcecode type="pseudocode" markers="false"><![CDATA[
S01. When an SRH is processed { 
S02.   If (Segments Left != 0) { 
S03.     Send an ICMP Parameter Problem to the Source Address 
         with Code 0 (Erroneous header field encountered) 
         and Pointer set to the Segments Left field, 
         interrupt packet processing, and discard the packet. 
S04.   }
S05.   Proceed to process the next header in the packet
S06. }
]]></sourcecode>
          <t>When processing the next (Upper-Layer) header of a packet matching a FIB entry locally instantiated as an End.DX1 SID, N does the following:</t>
          <sourcecode type="pseudocode" markers="false"><![CDATA[
S01. If (Upper-Layer header type == 147 (bit-stream) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Forward the remaining frame to the IWF I
S04. } Else {
S05.    Process as per {{Section 4.1.1 of RFC 8986}}
S06. }
]]></sourcecode>
        </section>
      </section>
      <section anchor="ple-header">
        <name>PLE Header</name>
        <t>The PLE header <bcp14>MUST</bcp14> contain the PLE control word (4 bytes) and <bcp14>MUST</bcp14> include a fixed-size RTP header <xref target="RFC3550"/>. The RTP header <bcp14>MUST</bcp14> immediately follow the PLE control word.</t>
        <section anchor="ple-control-word">
          <name>PLE Control Word</name>
          <t>The format of the PLE control word is in line with the guidance in <xref target="RFC4385"/> and is shown in <xref target="cw"/>.</t>
          <figure anchor="cw">
            <name>PLE Control Word</name>
            <artwork><![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 bits 0..3 of the first nibble are set to 0 to differentiate a control word or ACH from an IP packet or Ethernet frame. The first nibble <bcp14>MUST</bcp14> be set to 0000b to indicate that this header is a control word as defined in <xref section="3" sectionFormat="of" target="RFC4385"/>.</t>
          <t>The other fields in the control word are used as defined below:</t>
          <dl spacing="normal" newline="true">
              <dt>L:</dt>
              <dd>Set by the PE to indicate that data carried in the payload is invalid due to an attachment circuit fault. The downstream PE <bcp14>MUST</bcp14> send appropriate replacement data. The NSP <bcp14>MAY</bcp14> inject an appropriate downstream fault-indication signal.</dd>
              <dt>R:</dt>
              <dd>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 <bcp14>MUST</bcp14> be cleared by the PE once the packet loss state or fault indication has cleared.</dd>
              <dt>RSV:</dt>
              <dd>These bits are reserved for future use. This field <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</dd>
              <dt>FRG:</dt>
              <dd>These bits <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver as PLE does not use payload fragmentation.</dd>
              <dt>LEN:</dt>

              <dd>In accordance with <xref section="3" sectionFormat="of" target="RFC4385"/>, the length field <bcp14>MUST</bcp14> always be set to zero as there is no padding added to the PLE packet. The size of the PLE payload <bcp14>MUST</bcp14> be assumed
      to be as described in <xref target="ple-payload-layer"/>; if the actual packet size is
      inconsistent with this, the packet <bcp14>MUST</bcp14> be considered
      malformed.</dd>
              <dt>Sequence number:</dt>
              <dd>The sequence number field is used to provide a common PW sequencing function as well as detection of lost packets. It <bcp14>MUST</bcp14> be generated in accordance with the rules defined in <xref section="5.1" sectionFormat="of" target="RFC3550"/> and <bcp14>MUST</bcp14> be incremented with every PLE packet being sent.</dd>
          </dl>
        </section>
        <section anchor="rtp-header">
          <name>RTP Header</name>
          <t>The RTP header <bcp14>MUST</bcp14> be included to explicitly convey timing information.</t>
          <t>The RTP header (as defined in <xref target="RFC3550"/>) is reused to align with other bit-stream emulation pseudowires defined by <xref target="RFC4553"/>, <xref target="RFC5086"/>, and <xref target="RFC4842"/> and to allow PLE implementations to reuse preexisting work.</t>
          <t>There is no intention to support full RTP topologies and protocol mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTCP, RTP header compression, SRTP, etc., as these are not applicable to PLE VPWS.</t>
          <t>The format of the RTP header is as shown in <xref target="rtp"/>.</t>
          <figure anchor="rtp">
            <name>RTP Header</name>
            <artwork><![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>
          <dl spacing="normal" newline="true">
            <dt>V:</dt><dd><t>Version</t>
              <t>The version field <bcp14>MUST</bcp14> be set to 2.</t>
            </dd>
            <dt>P:</dt><dd><t>Padding</t>
              <t>The padding flag <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</t>
            </dd>
            <dt>X:</dt><dd><t>Header extension</t>
              <t>The X bit <bcp14>MUST</bcp14> be set to zero by sender and ignored by receiver.</t>
            </dd>
            <dt>CC:</dt><dd><t>CSRC count</t>
              <t>The CC field <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</t>
            </dd>
            <dt>M:</dt><dd><t>Marker</t>
              <t>The M bit <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</t>
            </dd>
            <dt>PT:</dt><dd><t>Payload type</t>
	    
              <t>A PT value <bcp14>MUST</bcp14> be allocated from the range of dynamic values defined in <xref section="6" sectionFormat="of" target="RFC3551"/> for each direction of the VPWS. The same PT value <bcp14>MAY</bcp14> be reused for both for directions and between different PLE VPWSs.</t>
              <t>The PT field <bcp14>MAY</bcp14> be used for detection of misconnections.</t>
            </dd>
            <dt>Sequence number:</dt>
              <dd>When using a 16-bit sequence number space, the sequence number in the RTP header <bcp14>MUST</bcp14> be equal to the sequence number in the PLE control word. When using a sequence number space of 32 bits, the initial value of the RTP sequence number <bcp14>MUST</bcp14> be 0 and incremented whenever the PLE control word sequence number cycles through from 0xFFFF to 0x0000.</dd>
            <dt>Timestamp:</dt>
              <dd>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 <bcp14>MUST</bcp14> be 125 MHz based on a the common clock I. For bit-streams above 200 Gbps, the frequency <bcp14>MUST</bcp14> be 250 MHz.</dd>
            <dt>SSRC:</dt><dd><t>Synchronization source</t>
              <t>The SSRC field <bcp14>MAY</bcp14> be used for detection of misconnections.</t>
            </dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="ple-payload-layer">
      <name>PLE Payload Layer</name>
      <t>A bit-stream is mapped into a PLE packet with a fixed payload size, which <bcp14>MUST</bcp14> be defined during VPWS setup, <bcp14>MUST</bcp14> be the same in both directions of the VPWS, and <bcp14>MUST</bcp14> remain unchanged for the lifetime of the VPWS.</t>
      <t>All PLE implementations <bcp14>MUST</bcp14> be capable of supporting the default payload size of 1024 bytes. The payload size <bcp14>SHOULD</bcp14> be configurable to be able to address specific packetization delay and overhead expectations. The smallest supported payload size is 64 bytes.</t>
      <section anchor="basic-payload">
        <name>Basic Payload</name>
        <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>
      </section>
      <section anchor="byte-aligned-payload">
        <name>Byte-Aligned Payload</name>
        <t>The PLE payload is filled in a byte-aligned manner, where the order of the payload bytes corresponds to their order on the attachment circuit. Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant. The PLE payload size <bcp14>MUST</bcp14> be an integer number of bytes.</t>
      </section>
    </section>
    <section anchor="ple-operation">
      <name>PLE Operation</name>
      <section anchor="common-considerations">
        <name>Common Considerations</name>
        <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 service type (OC192, 10GBASE-R, ODU2, etc.) and are using the same PLE payload type and payload size. This can be ensured via manual configuration or via the mechanisms of a signaling protocol.</t>
        <t>PLE-related control protocol extensions to LDP <xref target="RFC8077"/> or EVPN-VPWS <xref target="RFC8214"/> are out of scope for this document.</t>
        <t>Extensions for EVPN-VPWS are proposed in <xref target="I-D.schmutzer-bess-bitstream-vpws-signalling"/> and for LDP in <xref target="I-D.schmutzer-pals-ple-signaling"/>.</t>
      </section>
      <section anchor="ple-iwf-operation">
        <name>PLE IWF Operation</name>
        <section anchor="psn-bound-encapsulation-behavior">
          <name>PSN-Bound Encapsulation Behavior</name>
          <t>After the VPWS is set up, the PSN-bound IWF performs the following steps:</t>
          <ul spacing="normal">
            <li>
              <t>Packetize the data received from the CE into PLE payloads, all of the same configured size,</t>
            </li>
            <li>
              <t>Add PLE control word and RTP header with sequence numbers, flags, and timestamps properly set,</t>
            </li>
            <li>
              <t>Add the VPWS demultiplexer and PSN headers,</t>
            </li>
            <li>
              <t>Transmit the resulting packets over the PSN,</t>
            </li>
            <li>
              <t>Set the L bit in the PLE control word whenever the attachment circuit detects a fault, and</t>
            </li>
            <li>
              <t>Set the R bit in the PLE control word whenever the local CE-bound IWF is in packet loss state.</t>
            </li>
          </ul>
        </section>
        <section anchor="ce-bound-decapsulation-behavior">
          <name>CE-Bound Decapsulation Behavior</name>
          <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 sending the bit-stream out via the local attachment circuit.</t>
          <t>A de-jitter buffer <bcp14>MUST</bcp14> be implemented where the PLE packets are stored upon arrival. The size of this buffer <bcp14>SHOULD</bcp14> be locally configurable to allow accommodation of specific PSN PDV expected.</t>
          <t>The CE-bound IWF <bcp14>SHOULD</bcp14> use the sequence number in the control word to detect lost and misordered packets. It <bcp14>MAY</bcp14> use the sequence number in the RTP header for the same purpose. The CE-bound IWF <bcp14>MAY</bcp14> support reordering of packets received out of order. If the CE-bound IWF does not support reordering, it <bcp14>MUST</bcp14> drop the misordered packets.</t>
          <t>The payload of a lost or dropped packet <bcp14>MUST</bcp14> be replaced with an equivalent amount of replacement data. The contents of the replacement data <bcp14>MAY</bcp14> be locally configurable. By default, all PLE implementations <bcp14>MUST</bcp14> support generation of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xAA" pattern ensures clock synchronization is maintained and, for 64B/66B code-based services, ensures no invalid sync headers are generated. While sending 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 <bcp14>MUST</bcp14> inject the appropriate downstream fault-indication signal.</t>
          <t>Whenever a VPWS comes up, the CE-bound IWF will enter 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 downstream fault-indication signal until a preconfigured number of payload s stored in the jitter buffer.</t>
          <t>After the preconfigured 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 streamed out to the CE in accordance with the required clock. In this state, the CE-bound IWF <bcp14>MUST</bcp14> perform egress clock recovery.</t>
          <t>Considerations for choosing the preconfigured amount of payload required to be present for transitioning into the normal state:</t>
	  <ul>
	    
<li>Typically set to 50% of the de-jitter buffer size to equally allow compensating for increasing and decreasing delay</li>
<li>A compromise between the maximum amount of tolerable PDV and delay introduced to the emulated service</li></ul>
          <t>The recovered clock <bcp14>MUST</bcp14> comply with the jitter and wander requirements applicable to the type of attachment circuit, specified in:</t>
          <ul spacing="normal">
            <li>
              <t><xref target="G.825"/>, <xref target="G.783"/>, and <xref target="G.823"/> for SDH</t>
            </li>
            <li>
              <t><xref target="GR253"/> and <xref target="GR499"/> for SONET</t>
            </li>
            <li>
              <t><xref target="G.8261"/> for synchronous Ethernet</t>
            </li>
            <li>
              <t><xref target="G.8251"/> for OTN</t>
            </li>
          </ul>
          <t>Whenever the L bit is set in the PLE control word of a received PLE packet, the CE-bound NSP function <bcp14>SHOULD</bcp14> inject the appropriate downstream fault-indication signal instead of streaming out the payload.</t>
          <t>If the CE-bound IWF detects loss of consecutive packets for a preconfigured amount of time (default is 1 millisecond), it enters PLOS state and a corresponding defect is declared.</t>
          <t>If the CE-bound IWF detects a PLR above a configurable SD threshold for a configurable amount of consecutive 1-second intervals, it enters the DEG state and a corresponding defect is declared. The SD-PLR threshold can be defined as a percentage with the default being 15% or absolute packet count for finer granularity for higher rate interfaces. Possible values for consecutive intervals are 2..10 with the default 7.</t>
          <t>While the PLOS defect is declared, the CE-bound NSP function <bcp14>MUST</bcp14> inject the appropriate downstream fault-indication signal. If the emulated service does not have an appropriate maintenance signal defined, the CE-bound NSP function <bcp14>MAY</bcp14> disable its transmitter instead. Also, the PSN-bound IWF <bcp14>SHOULD</bcp14> set the R bit in the PLE control word of every packet transmitted.</t>
          <t>The CE-bound IWF changes from the PLOS to normal state after the preconfigured amount of payload has been received similar 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 <bcp14>SHOULD</bcp14> get updated.</t>
        </section>
      </section>
      <section anchor="ple-performance-monitoring">
        <name>PLE Performance Monitoring</name>
        <t>Attachment circuit performance monitoring <bcp14>SHOULD</bcp14> be provided by the NSP. The performance monitors are service specific, documented in related specifications, and beyond the scope of this document.</t>
        <t>The PLE IWF <bcp14>SHOULD</bcp14> provide 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:</t>
        <ul spacing="normal">
          <li>
            <t>ES-PLE : PLE Errored Seconds</t>
          </li>
          <li>
            <t>SES-PLE : PLE Severely Errored Seconds</t>
          </li>
          <li>
            <t>UAS-PLE : PLE Unavailable Seconds</t>
          </li>
        </ul>
        <t>Each second with at least one packet lost or a PLOS or DEG defect <bcp14>SHALL</bcp14> be counted as an ES-PLE. Each second with a PLR greater than 15% or a PLOS or DEG defect <bcp14>SHALL</bcp14> be counted as an SES-PLE.</t>
        <t>UAS-PLE <bcp14>SHALL</bcp14> be counted after a configurable number of consecutive SES-PLEs have been observed, and no longer counted after a configurable number of consecutive seconds without an SES-PLE have been observed. The default value for each is 10 seconds.</t>
        <t>Once unavailability is detected, ES-PLE and SES-PLE counts <bcp14>SHALL</bcp14> be inhibited
   up to the point where the unavailability was started.  Once
   unavailability is removed, ES-PLE and SES-PLE that occurred along the
   clearing period <bcp14>SHALL</bcp14> be added to the ES-PLE and SES-PLE counts.</t>
        <t>A PLE far-end performance monitor provides 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>
        <t>Performance monitoring data <bcp14>MUST</bcp14> be provided by the management interface and <bcp14>SHOULD</bcp14> be
provided by a YANG data model. The YANG data model specification is out of scope for this document.</t>
      </section>
      <section anchor="ple-fault-management">
        <name>PLE Fault Management</name>
        <t>Attachment circuit faults applicable to PLE are detected by the NSP, are service specific, and are documented in <xref target="emulated-services"/>.</t>
        <t>The two PLE faults, PLOS and DEG, are detected by the IWF.</t>
        <t>Faults <bcp14>MUST</bcp14> be timestamped as they are declared and cleared; fault-related information <bcp14>MUST</bcp14> be provided by the management interface and <bcp14>SHOULD</bcp14> be provided by a YANG data model. The YANG data model specification is out of scope for this document.</t>
      </section>
    </section>
    <section anchor="qos-and-congestion-control">
      <name>QoS and Congestion Control</name>
      <t>The PSN carrying PLE VPWS may be subject to congestion. Congestion considerations for PWs are described in <xref section="6.5" sectionFormat="of" target="RFC3985"/>.</t>
      <t>PLE VPWS represent inelastic CBR flows that cannot respond to congestion in a TCP-friendly manner (as described in <xref target="RFC2914"/>) and are sensitive to jitter, packet loss, and packets received out of order.</t>
      
      
      <t>The PSN providing connectivity between PE devices of a PLE VPWS has to ensure low jitter and low loss. The exact mechanisms used are beyond the scope of this document and may evolve over time. Possible options, but not exhaustively, are as follows:</t>
      <ul>
	<li>a Diffserv-enabled <xref target="RFC2475"/> PSN with a per-domain behavior (see <xref target="RFC3086"/>) supporting Expedited Forwarding (see <xref target="RFC3246"/>),</li>
	<li>traffic-engineered paths through the PSN with bandwidth reservation and admission control applied, or</li>
	<li>capacity over-provisioning.</li></ul>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>As PLE is leveraging VPWS as transport mechanism, the security considerations described in <xref target="RFC3985"/> are applicable.</t>
      <t>PLE does not enhance or detract from the security performance of the underlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.</t>
      <t>The PSN (MPLS or SRv6) is assumed to be trusted and secure. Attackers who manage to send spoofed packets into the PSN could easily disrupt the PLE service. This <bcp14>MUST</bcp14> be prevented by following best practices for the isolation of the PSN. These protections are described in <xref section="3.4" sectionFormat="of" target="RFC4381"/>, <xref section="4.2" sectionFormat="of" target="RFC5920"/>,  <xref section="8" sectionFormat="of" target="RFC8402"/>, and <xref section="9.3" sectionFormat="of" target="RFC9252"/>.</t>
      <t>PLE PWs share susceptibility to a number of pseudowire-layer attacks and will use whatever mechanisms for confidentiality, integrity, and authentication that are developed for general PWs. These methods are beyond the scope of this document.</t>
      <t>Random initialization of sequence numbers, in both the control word and the RTP header, makes known-plaintext attacks more difficult.</t>
      <t>Misconnection detection using the SSRC and/or PT field of the RTP header can increase the resilience to misconfiguration and some types of denial-of-service (DoS) attacks. Randomly chosen expected values decrease the chance of a spoofing attack being successful.</t>
      <t>A data plane attack may force PLE packets to be dropped, reordered, or delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to either degradation or service disruption. Considerations outlined in <xref target="RFC9055"/> are a good reference.</t>
      
      <t>Clock synchronization leveraging PTP is sensitive to PDV and vulnerable to various threats and attack vectors. Considerations outlined in <xref target="RFC7384"/> should be taken into account.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="bit-stream-next-header-type">
        <name>Bit-Stream Next Header Type</name>
        <t>This document introduces a new value to be used in the next header field of an IPv6 header or any extension header indicating that the payload is an emulated bit-stream. IANA has assigned the following from the "Assigned Internet Protocol Numbers" registry <xref target="IANA-Proto"/>.</t>
        <table>
          <thead>
            <tr>
              <th align="left">Decimal</th>
              <th align="left">Keyword</th>
              <th align="left">Protocol</th>
              <th align="left">IPv6 Extension Header</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">147</td>
              <td align="left">BIT-EMU</td>
              <td align="left">Bit-stream Emulation</td>
              <td align="left">Y</td>
              <td align="left">RFC 9801</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="srv6-endpoint-behaviors">
        <name>SRv6 Endpoint Behaviors</name>
        <t>This document introduces three new SRv6 Endpoint behaviors. IANA has assigned identifier values in the "SRv6 Endpoint Behaviors" registry under the "Segment Routing" registry group <xref target="IANA-SRv6-End"/>.</t>
        <table>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Hex</th>
              <th align="left">Endpoint Behavior</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">158</td>
              <td align="left">0x009E</td>
              <td align="left">End.DX1</td>
              <td align="left">RFC 9801</td>
            </tr>
            <tr>
              <td align="left">159</td>
              <td align="left">0x009F</td>
              <td align="left">End.DX1 with NEXT-CSID</td>
              <td align="left">RFC 9801</td>
            </tr>
            <tr>
              <td align="left">160</td>
              <td align="left">0x00A0</td>
              <td align="left">End.DX1 with REPLACE-CSID</td>
              <td align="left">RFC 9801</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.schmutzer-bess-bitstream-vpws-signalling" to="EVPN-VPWS"/>
    <displayreference target="I-D.schmutzer-pals-ple-signaling" to="LDP-PLE"/>
 
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3985.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>


        <reference anchor="IEEE802.3" target="https://ieeexplore.ieee.org/document/9844436">
          <front>
            <title>IEEE Standard for Ethernet</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2022" month="July"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.3-2022"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9844436"/>
        </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 year="2007" month="January"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.707"/>
        </reference>


        <reference anchor="G.709" target="https://www.itu.int/rec/T-REC-G.709">
          <front>
            <title>Interfaces for the optical transport network</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2020" month="June"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.709"/>
        </reference>


        <reference anchor="G.823" target="https://www.itu.int/rec/T-REC-G.823">
          <front>
            <title>The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.823"/>
        </reference>


        <reference anchor="G.825" target="https://www.itu.int/rec/T-REC-G.825">
          <front>
            <title>The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.825"/>
        </reference>


        <reference anchor="G.783" target="https://www.itu.int/rec/T-REC-G.783">
          <front>
            <title>Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2006" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.783"/>
        </reference>


        <reference anchor="G.8251" target="https://www.itu.int/rec/T-REC-G.8251">
          <front>
            <title>The control of jitter and wander within the optical transport network (OTN)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2022" month="November"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8251"/>
        </reference>


        <reference anchor="G.8261" target="https://www.itu.int/rec/T-REC-G.8261">
          <front>
            <title>Timing and synchronization aspects in packet networks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2019" month="August"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8261"/>
        </reference>

        <reference anchor="G.8262" target="https://www.itu.int/rec/T-REC-G.8262">
          <front>
            <title>Timing characteristics of synchronous equipment clocks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2024" month="October"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8262"/>
        </reference>


        <reference anchor="G.8261.1" target="https://www.itu.int/rec/T-REC-G.8261.1">
          <front>
            <title>Packet delay variation network limits applicable to packet-based methods (Frequency synchronization)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2012" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8261.1"/>
        </reference>


        <reference anchor="G.8265.1" target="https://www.itu.int/rec/T-REC-G.8265.1">
          <front>
            <title>Precision time protocol telecom profile for frequency synchronization</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2022" month="November"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8265.1"/>
        </reference>


        <reference anchor="GR253" target="https://telecom-info.njdepot.ericsson.net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&amp;DOCUMENT=GR-253">
          <front>
            <title>Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria</title>
            <author>
              <organization>Telcordia</organization>
            </author>
            <date year="2009" month="October"/>
          </front>
          <refcontent>GR-253</refcontent>
        </reference>


        <reference anchor="GR499" target="https://telecom-info.njdepot.ericsson.net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&amp;DOCUMENT=GR-499">
          <front>
            <title>Transport Systems Generic Requirements (TSGR) - Common Requirements</title>
            <author>
              <organization>Telcordia</organization>
            </author>
            <date year="2009" month="November"/>
          </front>
          <refcontent>GR-499</refcontent>
        </reference>


        <reference anchor="IANA-Proto" target="https://www.iana.org/assignments/protocol-numbers">
          <front>
            <title>Assigned Internet Protocol Numbers</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>


        <reference anchor="IANA-SRv6-End" target="https://www.iana.org/assignments/segment-routing">
          <front>
            <title>SRv6 Endpoint Behaviors</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9800.xml"/>


      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4197.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4381.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml"/>


        <reference anchor="T11" target="https://www.incits.org/committees/t11">
          <front>
            <title>T11 - Fibre Channel</title>
            <author>
              <organization>INCITS</organization>
            </author>
          </front>
        </reference>

        <reference anchor="FC-PI-2" target="https://webstore.ansi.org/standards/incits/incits4042006s2016">
          <front>
            <title>Information Technology - Fibre Channel Physical Interfaces - 2 (FC-PI-2)</title>
            <author>
              <organization>INCITS</organization>
            </author>
            <date year="2016"/>
          </front>
          <seriesInfo name="INCITS" value="404-2006 (S2016)"/>
        </reference>

        <reference anchor="FC-PI-5" target="https://webstore.ansi.org/standards/incits/incits4792011s2021">
          <front>
            <title>Information Technology - Fibre Channel - Physical Interface-5 (FC-PI-5)</title>
            <author>
              <organization>INCITS</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="INCITS" value="479-2011 (S2021)"/>
        </reference>


        <reference anchor="FC-PI-5am1" target="https://webstore.ansi.org/standards/incits/incits4792011am2016r2021">
          <front>
            <title>Information Technology - Fibre Channel - Physical Interface - 5/Amendment 1 (FC-PI-5/AM1)</title>
            <author>
              <organization>INCITS</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="INCITS" value="479-2011/AM1-2016 (R2021)"/>
        </reference>



        <reference anchor="FC-PI-6" target="https://webstore.ansi.org/standards/incits/incits5122015r2020">
          <front>
            <title>Information Technology - Fibre Channel - Physical Interface - 6 (FC-PI-6)</title>
            <author>
              <organization>INCITS</organization>
            </author>
            <date year="2020"/>
          </front>
          <seriesInfo name="INCITS" value="512-2015 (R2020)"/>
        </reference>


        <reference anchor="FC-PI-6P" target="https://webstore.ansi.org/standards/incits/incits5332016r2021">
          <front>
            <title>Information Technology - Fibre Channel - Physical Interface - 6P (FC-PI-6P)</title>
            <author>
              <organization>INCITS</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="INCITS" value="533-2016 (R2021)"/>
        </reference>

        <reference anchor="FC-PI-7" target="https://www.iso.org/standard/80933.html">
          <front>
            <title>Information technology - Fibre channel - Part 147: Physical interfaces - 7 (FC-PI-7)</title>
            <author>
              <organization>ISO/IEC</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="ISO/IEC" value="14165-147:2021"/>
        </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 year="2002" month="December"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.826"/>
        </reference>


        <reference anchor="ATIS-0900105.09.2013" target="https://webstore.ansi.org/standards/atis/atis0900105092013s2023">
          <front>
            <title>Synchronous Optical Network (SONET) - Network Element Timing and Synchronization</title>
            <author>
              <organization>ATIS</organization>
            </author>
            <date year="2023"/>
          </front>
          <refcontent>ATIS-0900105.09.2013(S2023)</refcontent>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4553.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4906.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4448.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4842.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7212.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8077.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8214.xml"/>


<reference anchor="I-D.schmutzer-bess-bitstream-vpws-signalling" target="https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-bitstream-vpws-signalling-02">
   <front>
      <title>Ethernet VPN Signalling Extensions for Bit-stream VPWS</title>
      <author initials="S." surname="Gringeri" fullname="Steven Gringeri">
         <organization>Verizon</organization>
      </author>
      <author initials="J." surname="Whittaker" fullname="Jeremy Whittaker">
         <organization>Verizon</organization>
      </author>
      <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" role="editor">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author initials="B." surname="Vasudevan" fullname="Bharath Vasudevan">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author initials="P." surname="Brissette" fullname="Patrice Brissette">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <date month="October" day="18" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-schmutzer-bess-bitstream-vpws-signalling-02" />   
</reference>


<reference anchor="I-D.schmutzer-pals-ple-signaling" target="https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-02">
   <front>
      <title>LDP Extensions to Support Private Line Emulation (PLE)</title>
      <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" role="editor">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <date month="October" day="20" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-schmutzer-pals-ple-signaling-02" />
   
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2914.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/>
	        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml"/>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="include">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Alexander
      Vainshtein"/>, <contact fullname="Yaakov Stein"/>, <contact
      fullname="Erik van Veelen"/>, <contact fullname="Faisal Dada"/>,
      <contact fullname="Giles Heron"/>, <contact fullname="Luca Della
      Chiesa"/>, and <contact fullname="Ashwin Gumaste"/> for their early
      contributions, review, comments, and suggestions.</t>
      <t>Special thank you to:</t>
      <ul spacing="normal">
        <li><t><contact fullname="Carlos Pignataro"/> and <contact
        fullname="Nagendra Kumar Nainar"/> for giving the authors new-to-the-IETF
        guidance on how to get started</t></li>
        <li><t><contact fullname="Stewart Bryant"/> for being our
        shepherd</t></li>
        <li><t><contact fullname="Tal Mizahi"/>, <contact fullname="Joel
        Halpern"/>, <contact fullname="Christian Huitema"/>, <contact
        fullname="Tony Li"/>, and <contact fullname="Tommy Pauly"/> for their
        reviews and suggestions during Last Call</t></li>
        <li><t><contact fullname="Andrew Malis"/> and <contact
        fullname="Gunter van de Velde"/> for their guidance through the
        process</t></li>
      </ul>
    </section>
    
    <section anchor="contributors" numbered="false" toc="include">
      <name>Contributors</name>
      <contact initials="A." surname="Burk" fullname="Andreas Burk">
        <organization>1&amp;1 Versatel</organization>
        <address>
          <email>andreas.burk@magenta.de</email>
        </address>
      </contact>
      <contact initials="F." surname="Dada" fullname="Faisal Dada">
        <organization>AMD</organization>
        <address>
          <email>faisal.dada@amd.com</email>
        </address>
      </contact>
      <contact initials="G." surname="Smallegange" fullname="Gerald Smallegange">
        <organization>Ciena Corporation</organization>
        <address>
          <email>gsmalleg@ciena.com</email>
        </address>
      </contact>
      <contact initials="E." surname="van Veelen" fullname="Erik van Veelen">
        <organization>Aimvalley</organization>
        <address>
          <email>erik.vanveelen@aimvalley.com</email>
        </address>
      </contact>
      <contact initials="L." surname="Della Chiesa" fullname="Luca Della Chiesa">
        <organization>Cisco Systems, Inc.</organization>
        <address>
          <email>ldellach@cisco.com</email>
        </address>
      </contact>
      <contact initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
        <organization>Cisco Systems, Inc.</organization>
        <address>
          <email>naikumar@cisco.com</email>
        </address>
      </contact>
      <contact initials="C." surname="Pignataro" fullname="Carlos Pignataro">
        <organization>Blue Fern Consulting</organization>
        <address>
          <email>Carlos@Bluefern.consulting</email>
        </address>
      </contact>

    </section>
  </back>
</rfc>
