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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 3.2.3) -->
<?rfc comments="yes"?>
<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">
  <!-- xml2rfc v2v3 conversion 3.27.0 version="3" updates="" obsoletes="" xml:lang="en">

  <front>

<!--[rfced] We note that the abbreviated title for this document is
     currently "PLE".  We have updated this to "PLE over PSNs" to more
     closely match the full title.  Please let us know any objections.
     -->
  <front>

    <title abbrev="PLE">Private abbrev="PLE over PSNs">Private Line Emulation over Packet Switched Networks</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-pals-ple-15"/> 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="February" day="12"/> month="June"/>
    <area>RTG</area>
    <workgroup>pals</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 308?>
      <t>This document expands the applicability of virtual private wire services 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 (PSN).</t> Packet Switched Networks (PSNs).</t>
    </abstract>
  </front>
  <middle>
    <?line 314?>

<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 Ethernet-connected Customer Edge (CE) devices and the need for Synchronous Ethernet <xref target="G.8261"/> 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 PDU-based carrier Ethernet services, beyond the behavior definitions of Metro Ethernet 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 demultiplexing and multiplexing and demultiplexing 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, In other words, PLE does provide provides an independent layer network underneath the SONET/SDH layer network, whereas CEP does operate 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 Time Division Multiplexing (TDM) TDM over Packet (SAToP) defined (defined in <xref target="RFC4553"/>. target="RFC4553"/>). The applicability is expanded beyond the narrow set of Plesiochronous Digital Hierarchy (PDH) interfaces (T1, E1, T3 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="GR253"/>/<xref target="G.707"/> target="G.707"/>), and OTN <xref target="G.709"/> at gigabit speeds. The signals are treated as bit-stream payload payload, which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in Sections <xref target="RFC3985"/> sections 3.3.3 target="RFC3985" sectionFormat="bare" section="3.3.3"/> and 3.3.4.</t> <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 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL" "<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>

<!--[rfced] We had a few notes about the titles in Section 3:

a) Please note that we have updated the title of Section 3 to use
plural "Models" as it appears that more than one model is discussed in
Section 3.2 (or at least repeated from RFC 4197).  Please review and
let us know any objections.

b) Please note that we have updated the title of Section 3.1 to
"Abbreviations" as all terms in that section seem to be expansions.
Please let us know any concerns.
    -->

    <section anchor="terminology-and-reference-model">
      <name>Terminology and Reference Model</name> Models</name>

<!-- [rfced] We note that [RFC3985] does not contain the term "Virtual
     Private Wire Service" or the abbreviation "VPWS".  Please review
     this citation for accuracy.

Original:
   VPWS -  Virtual Private Wire Service [RFC3985]
-->
<section anchor="terminology">

        <name>Terminology</name>
        <ul spacing="normal">
          <li>
            <t>ACH - Associated
        <dl spacing="normal" newline="false">
            <dt>ACH:</dt><dd>Associated Channel Header <xref target="RFC7212"/></t>
          </li>
          <li>
            <t>AIS - Alarm target="RFC7212"/></dd>
            <dt>AIS:</dt><dd>Alarm Indication Signal</t>
          </li>
          <li>
            <t>AIS-L - Line AIS</t>
          </li>
          <li>
            <t>AS - Autonomous System</t>
          </li>
          <li>
            <t>ASBR - Autonomous System Border Router</t>
          </li>
          <li>
            <t>MS-AIS - Multiplex Signal</dd>
            <dt>AIS-L:</dt><dd>Line AIS</dd>
            <dt>MS-AIS:</dt><dd>Multiplex Section AIS</t>
          </li>
          <li>
            <t>BITS - Building AIS</dd>
            <dt>BITS:</dt><dd>Building Integrated Timing Supply <xref target="ATIS-0900105.09.2013"/></t>
          </li>
          <li>
            <t>CBR - Constant target="ATIS-0900105.09.2013"/></dd>
            <dt>CBR:</dt><dd>Constant Bit Rate</t>
          </li>
          <li>
            <t>CE - Customer Edge</t>
          </li>
          <li>
            <t>CEP - Circuit Rate</dd>
            <dt>CE:</dt><dd>Customer Edge</dd>
            <dt>CEP:</dt><dd>Circuit Emulation over Packet <xref target="RFC4842"/></t>
          </li>
          <li>
            <t>CSRC - Contributing SouRCe target="RFC4842"/></dd>
            <dt>CSRC:</dt><dd>Contributing Source <xref target="RFC3550"/></t>
          </li>
          <li>
            <t>DEG - Degradation</t>
          </li>
          <li>
            <t>ES - Errored Second</t>
          </li>
          <li>
            <t>FEC - Forward target="RFC3550"/></dd>
            <dt>DEG:</dt><dd>Degradation</dd>
            <dt>ES:</dt><dd>Errored Second</dd>
            <dt>FEC:</dt><dd>Forward Error Correction</t>
          </li>
          <li>
            <t>ICMP - Internet Correction</dd>
            <dt>ICMP:</dt><dd>Internet Control Message Protocol <xref target="RFC4443"/></t>
          </li>
          <li>
            <t>IEEE - Institute target="RFC4443"/></dd>
            <dt>IEEE:</dt><dd>Institute of Electrical and Electronics Engineers</t>
          </li>
          <li>
            <t>INCITS - InterNational Engineers</dd>
            <dt>INCITS:</dt><dd>INternational Committee for Information Technology Standards</t>
          </li>
          <li>
            <t>IWF - InterWorking Function</t>
          </li>
          <li>
            <t>LDP - Label Standards</dd>
            <dt>IWF:</dt><dd>Interworking Function</dd>
            <dt>LDP:</dt><dd>Label Distribution Protocol <xref target="RFC5036"/>, <xref target="RFC8077"/></t>
          </li>
          <li>
            <t>LF - Local Fault</t>
          </li>
          <li>
            <t>LOF - Loss target="RFC8077"/></dd>
            <dt>LF:</dt><dd>Local Fault</dd>
            <dt>LOF:</dt><dd>Loss Of Frame</t>
          </li>
          <li>
            <t>LOM - Loss Frame</dd>
            <dt>LOM:</dt><dd>Loss Of Multiframe</t>
          </li>
          <li>
            <t>LOS - Loss Multiframe</dd>
            <dt>LOS:</dt><dd>Loss Of Signal</t>
          </li>
          <li>
            <t>LPI - Low Signal</dd>
            <dt>LPI:</dt><dd>Low Power Idle</t>
          </li>
          <li>
            <t>LSP - Label Idle</dd>
            <dt>LSP:</dt><dd>Label Switched Path</t>
          </li>
          <li>
            <t>MEF - Metro Ethernet Forum</t>
          </li>
          <li>
            <t>MPLS - Multi Protocol Path</dd>
            <dt>MEF:</dt><dd>MEF Forum</dd>
            <dt>MPLS:</dt><dd>Multiprotocol Label Switching <xref target="RFC3031"/></t>
          </li>
          <li>
            <t>NOS - Not Operational</t>
          </li>
          <li>
            <t>NSP - Native target="RFC3031"/></dd>
            <dt>NOS:</dt><dd>Not Operational</dd>
            <dt>NSP:</dt><dd>Native Service Processor Processing <xref target="RFC3985"/></t>
          </li>
          <li>
            <t>ODUk - Optical target="RFC3985"/></dd>
            <dt>ODUk:</dt><dd>Optical Data Unit k</t>
          </li>
          <li>
            <t>OTN - Optical k</dd>
            <dt>OTN:</dt><dd>Optical Transport Network</t>
          </li>
          <li>
            <t>OTUk - Optical Network</dd>
            <dt>OTUk:</dt><dd>Optical Transport Unit k</t>
          </li>
          <li>
            <t>PCS - Physical k</dd>
            <dt>PCS:</dt><dd>Physical Coding Sublayer</t>
          </li>
          <li>
            <t>PDH - Plesiochronous Digital Hierarchy</t>
          </li>
          <li>
            <t>PDV - Packet Sublayer</dd>
            <dt>PDV:</dt><dd>Packet Delay Variation</t>
          </li>
          <li>
            <t>PE - Provider Edge</t>
          </li>
          <li>
            <t>PLE - Private Variation</dd>
            <dt>PE:</dt><dd>Provider Edge</dd>
            <dt>PLE:</dt><dd>Private Line Emulation</t>
          </li>
          <li>
            <t>PLOS - Packet Emulation</dd>
            <dt>PLOS:</dt><dd>Packet Loss Of Signal</t>
          </li>
          <li>
            <t>PLR - Packet Signal</dd>
            <dt>PLR:</dt><dd>Packet Loss Ratio</t>
          </li>
          <li>
            <t>PMA - Physical Rate</dd>
            <dt>PMA:</dt><dd>Physical Medium Attachment</t>
          </li>
          <li>
            <t>PMD - Physical Attachment</dd>
            <dt>PMD:</dt><dd>Physical Medium Dependent</t>
          </li>
          <li>
            <t>PSN - Packet Dependent</dd>
            <dt>PSN:</dt><dd>Packet Switched Network</t>
          </li>
          <li>
            <t>PTP - Precision Network</dd>
            <dt>PTP:</dt><dd>Precision Time Protocol</t>
          </li>
          <li>
            <t>PW - Pseudowire Protocol</dd>
            <dt>PW:</dt><dd>Pseudowire <xref target="RFC3985"/></t>
          </li>
          <li>
            <t>PWE3 - Pseudo target="RFC3985"/></dd>
            <dt>PWE3:</dt><dd>Pseudo Wire Emulation Edge-to-Edge <xref target="RFC3985"/></t>
          </li>
          <li>
            <t>P2P - Point-to-Point</t>
          </li>
          <li>
            <t>QOS - Quality Of Service</t>
          </li>
          <li>
            <t>RDI - Remote target="RFC3985"/></dd>
            <dt>RDI:</dt><dd>Remote Defect Indication</t>
          </li>
          <li>
            <t>RSVP-TE - Resource Indication</dd>
            <dt>RSVP-TE:</dt><dd>Resource Reservation Protocol Traffic Engineering <xref target="RFC4875"/></t>
          </li>
          <li>
            <t>RTCP - RTP target="RFC4875"/></dd>
            <dt>RTCP:</dt><dd>RTP Control Protocol <xref target="RFC3550"/></t>
          </li>
          <li>
            <t>RTP - Realtime target="RFC3550"/></dd>
            <dt>RTP:</dt><dd>Real-time Transport Protocol <xref target="RFC3550"/></t>
          </li>
          <li>
            <t>SAN - Storage Area Network</t>
          </li>
          <li>
            <t>SAToP - Structure-Agnostic Time Division Multiplexing (TDM) over Packet <xref target="RFC4553"/></t>
          </li>
          <li>
            <t>SD - Signal Degrade</t>
          </li>
          <li>
            <t>SES - Severely target="RFC3550"/></dd>
            <dt>SD:</dt><dd>Signal Degrade</dd>
            <dt>SES:</dt><dd>Severely Errored Second</t>
          </li>
          <li>
            <t>SDH - Synchronous Seconds</dd>
            <dt>SDH:</dt><dd>Synchronous Digital Hierarchy</t>
          </li>
          <li>
            <t>SID - Segment Hierarchy</dd>
            <dt>SID:</dt><dd>Segment Identifier <xref target="RFC8402"/></t>
          </li>
          <li>
            <t>SPE - Synchronous Payload Envelope</t>
          </li>
          <li>
            <t>SR - Segment target="RFC8402"/></dd>
            <dt>SR:</dt><dd>Segment Routing <xref target="RFC8402"/></t>
          </li>
          <li>
            <t>SRH - Segment target="RFC8402"/></dd>
            <dt>SRH:</dt><dd>Segment Routing Header <xref target="RFC8754"/></t>
          </li>
          <li>
            <t>SRTP - Secure Realtime target="RFC8754"/></dd>
            <dt>SRTP:</dt><dd>Secure Real-time Transport Protocol <xref target="RFC3711"/></t>
          </li>
          <li>
            <t>SRv6 - Segment target="RFC3711"/></dd>
            <dt>SRv6:</dt><dd>Segment Routing over IPv6 Dataplane <xref target="RFC8986"/></t>
          </li>
          <li>
            <t>SSRC - Synchronization SouRCe target="RFC8986"/></dd>
            <dt>SSRC:</dt><dd>Synchronization Source <xref target="RFC3550"/></t>
          </li>
          <li>
            <t>SONET - Synchronous target="RFC3550"/></dd>
            <dt>SONET:</dt><dd>Synchronous Optical Network</t>
          </li>
          <li>
            <t>TCP - Transmission Network</dd>
            <dt>TCP:</dt><dd>Transmission Control Protocol <xref target="RFC9293"/></t>
          </li>
          <li>
            <t>TDM - Time target="RFC9293"/></dd>
            <dt>TDM:</dt><dd>Time Division Multiplexing</t>
          </li>
          <li>
            <t>TTS - Transmitter Multiplexing</dd>
            <dt>TTS:</dt><dd>Transmitter Training Signal</t>
          </li>
          <li>
            <t>UAS - Unavailable Second</t>
          </li>
          <li>
            <t>VPWS - Virtual Signal</dd>
            <dt>UAS:</dt><dd>Unavailable Seconds</dd>
            <dt>VPWS:</dt><dd>Virtual Private Wire Service <xref target="RFC3985"/></t>
          </li>
          <li>
            <t>VC - Virtual Circuit</t>
          </li>
          <li>
            <t>VT - Virtual Tributary</t>
          </li>
        </ul>
        <t>The target="RFC3985"/></dd>
        </dl>
        <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>
      </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 does rely relies on PWE3 pre-processing, preprocessing, in particular the concept of a Native Service Processing (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>

<!--[rfced] Can you clarify the use of "whereas" in this text?

Original:
   PLE embraces the minimum intervention principle outlined in
   Section 3.3.5 of [RFC3985] whereas the data is flowing through the
   PLE encapsulation layer as received without modifications.

Perhaps:
   While PLE embraces the minimum intervention principle outlined in
   Section 3.3.5 of [RFC3985], in this case, the data is flowing through the
   PLE encapsulation layer as received without modifications.

-->

        <t>PLE embraces the minimum intervention principle outlined in <xref section="3.3.5" sectionFormat="of" target="RFC3985"/> whereas the data is flowing through the PLE encapsulation layer as received without modifications.</t>
        <t>For some service types types, the NSP function is responsible for performing operations on the native data received from the CE. Examples are terminating Forward Error Correction (FEC), terminating the OTUk layer for OTN OTN, or dealing with multi-lane processing. After the NSP, the IWF is generating the payload of the VPWS 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 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 work, the difference between clock A and clock C (locked to I) MUST <bcp14>MUST</bcp14> be explicitly transferred from PE1 to PE2 using the timestamp inside the RTP header.</t>
        <t>For

<!--[rfced] In the following, does PE1 generate the clock difference
     transferred?  Or should the last part of this sentence be passive
     voice (i.e., "is transferred" instead of "transferred")?

Original:
   For the reverse direction PE1 does generate the attachment circuit
   clock J and the clock difference between G and D (locked to I)
   transferred from PE2 to PE1.
-->

        <t>For the reverse direction, PE1 generates the attachment circuit clock J and the clock difference between G and D (locked to I) 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, but document; however, there are already several well-established concepts for achieving clock synchronization, commonly synchronization (commonly also referred to as frequency synchronization, "frequency synchronization") available.</t>
        <t>While using external timing inputs (aka BITS <xref target="ATIS-0900105.09.2013"/>) or synchronous Ethernet as (as defined in <xref target="G.8261"/> target="G.8261"/>), the characteristics and limits defined in <xref target="G.8262"/> have to be considered.</t>
        <t>While relying on precision time protocol (PTP) as (as defined in <xref target="G.8265.1"/>, 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 Section 3.3.3 Sections <xref target="RFC3985" sectionFormat="bare" section="3.3.3"/> and Section 3.3.4 <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 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> 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>IEEE
        <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 Physical Coding Sublayer (PCS).</t>
        <t>Over time time, many different Ethernet interface types have been specified in <xref target="IEEE802.3"/> with a varying set of characteristics characteristics, such as optional vs versus mandatory FEC and single-lane vs versus multi-lane transmission.</t>
        <t>Ethernet interface types with backplane physical media dependent (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 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 (defined in section Section 36 of <xref target="IEEE802.3"/> 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 but auto-negotiation; however, it is responsible to detect 1000BASE-X specific 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 being L bit set, the CE-bound NSP function MAY <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 (defined in section Section 49 and 25GBASE-R defined in section Section 107 of <xref target="IEEE802.3"/> target="IEEE802.3"/>) are based on a 64B/66B code.</t>
          <t><xref target="IEEE802.3"/> sections
          <t>Sections 74 and 108 do of <xref target="IEEE802.3"/> define an optional FEC layer, layer; if present present, the PSN-bound NSP function MUST <bcp14>MUST</bcp14> terminate the FEC and the CE-bound NSP function MUST <bcp14>MUST</bcp14> generate the FEC.</t>
          <t>The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to detect 10GBASE-R and 25GBASE-R specific attachment circuit faults such as LOS and sync loss.</t>
          <t>The PSN-bound IWF is mapping maps the scrambled 64B/66B code stream into the basic PLE payload.</t>
          <t>The

<!--[rfced] Is there an "and" relationship between the items in the
     lists like those found in Section 4.2.2 (and elsewhere)?

Original:

   The CE-bound NSP function MUST perform</t> perform

   *  PCS code sync (section 49.2.9 of [IEEE802.3])

   *  descrambling (section 49.2.10 of [IEEE802.3])

   in order to properly

   *  transform invalid 66B code blocks into proper error control
      characters /E/ (section 49.2.4.11 of [IEEE802.3])

   *  insert Local Fault (LF) ordered sets (section 46.3.4 of
      [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE
      packets are received with the L-bit being set

Perhaps:

   The CE-bound NSP function MUST perform:

   *  PCS code sync (Section 49.2.9 of [IEEE802.3]) and

   *  descrambling (Section 49.2.10 of [IEEE802.3])

   in order to properly:

   *  transform invalid 66B code blocks into proper error control
      characters /E/ (section 49.2.4.11 of [IEEE802.3]) and

   *  insert Local Fault (LF) ordered sets (Section 46.3.4 of
      [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE
      packets are received with the L bit set.

-->

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

            </li>
          </ul>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, packets or if the far-end PSN-bound NSP function did set not setting sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>When sending the bit stream to the CE, the CE-bound NSP function MUST <bcp14>MUST</bcp14> also perform</t> perform:</t>
          <ul spacing="normal">
            <li>
              <t>scrambling of the 64B/66B code (section (Section 49.2.6 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>block distribution (section (Section 82.2.6 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>alignment marker
              <t>alignment-marker insertion (sections (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 (defined in section Section 119 of <xref target="IEEE802.3"/> 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 stream, the PSN-bound NSP further MUST perform</t> <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>alignment lock and de-skew (section (Section 119.2.5.1 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>PCS Lane reordering and de-interleaving (section (Section 119.2.5.2 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>FEC decoding (section (Section 119.2.5.3 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>post-FEC interleaving (section (Section 119.2.5.4 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>alignment marker
              <t>alignment-marker removal (section (Section 119.2.5.5 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>descrambling (section (Section 119.2.5.6 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>reverse transcoding from 256B/257B to 64B/66B (section (Section 119.2.5.7 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>Further
          <t>Further, the PSN-bound NSP MUST <bcp14>MUST</bcp14> perform rate compensation and scrambling (section (Section 49.2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF is mapping 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 66-byte-long rate compensation blocks are inserted every X*20479 number of 66B client blocks. For 200GBASE-R 200GBASE-R, the value of X is 16 and 16; for 400GBASE-R 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 detect 200GBASE-R and 400GBASE-R specific attachment circuit faults such as LOS and loss of alignment.</t>
          <t>The CE-bound NSP function MUST perform</t> <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>PCS code sync (section (Section 49.2.13 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>descrambling (section (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>rate compensation block removal</t>
            </li>
          </ul>
          <t>in order to properly</t> properly:</t>
          <ul spacing="normal">
            <li>
              <t>transform invalid 66B code blocks into proper error control characters /E/ (section (Section 119.2.3.9 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>insert Local Fault (LF) ordered sets (section (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 being L bit set</t>
            </li>
          </ul>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, packets or if the far-end PSN-bound NSP function did set not setting sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>When sending the bit stream to the CE, the CE-bound NSP function MUST <bcp14>MUST</bcp14> also perform</t> perform:</t>
          <ul spacing="normal">
            <li>
              <t>transcoding from 64B/66B to 256B/257B (section (Section 119.2.4.2 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>scrambling (section (Section 119.2.4.3 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>alignment marker
              <t>alignment-marker insertion (section (Section 119.2.4.4 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>pre-FEC distribution (section (Section 119.2.4.5 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>FEC encoding (section (Section 119.2.4.6 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>PCS Lane distribution (section (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"/> does define defines the optional Low Power Idle (LPI) capability for Ethernet. Two modes are defined</t> 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 Hence, there is no support for LPI for 10GBASE-R services across PLE.</t>
          <t>When in
          <t>In fast wake mode mode, the CE transmits /LI/ control code blocks instead of /I/ control code blocks and therefore 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"/> and 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 to detect SONET/SDH interface specific for detecting attachment circuit faults specific to SONET/SDH such as LOS, LOF 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 being L bit set, the CE-bound NSP function is responsible for generating the</t> the:</t>
        <ul spacing="normal">
          <li>
            <t>MS-AIS maintenance signal defined (defined in section Section 6.2.4.1.1 of <xref target="G.707"/> target="G.707"/>) for SDH services</t>
          </li>
          <li>
            <t>AIS-L maintenance signal defined (defined in section Section 6.2.1.2 of <xref target="GR253"/> target="GR253"/>) for SONET services</t>
          </li>
        </ul>
        <t>at client frame 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 time, many different Fibre Channel interface types have been specified with a varying set of characteristics such as optional vs versus mandatory FEC and single-lane vs versus multi-lane transmission.</t>
        <t>Speed negotiation is not supported by PLE.</t>
        <t>All Fibre Channel services are leveraging leverage the basic PLE payload payload, and interface specific interface-specific mechanisms are confined to the respective service specific service-specific NSP functions.</t>
        <section anchor="gfc-2gfc-4gfc-and-8gfc">
          <name>1GFC, 2GFC, 4GFC 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"/> do define 4GFC and 8GFC.</t>
          <t>The PSN-bound NSP function is responsible to detect Fibre Channel specific for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
          <t>The PSN-bound IWF is mapping maps the received 8B/10B code stream as is directly into the basic PLE payload.</t>
          <t>The CE-bound NSP function MUST <bcp14>MUST</bcp14> perform transmission word sync in order to properly</t> properly:</t>
          <ul spacing="normal">
            <li>
              <t>replace invalid transmission words with the special character K30.7</t>
            </li>
            <li>
              <t>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being L bit set</t>
            </li>
          </ul>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets.</t>
          <t><xref target="FC-PI-5am1"/> does define defines the use of scrambling for 8GFC, 8GFC; in this case case, the CE-bound NSP MUST <bcp14>MUST</bcp14> also perform descrambling before replacing invalid transmission words or inserting NOS ordered sets. And before  Before sending the bit stream to the, the CE, the CE-bound NSP function MUST <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 a an optional FEC layer.</t>
          <t>If FEC is present present, it must be indicated via transmitter training signal (TTS) during when the attachment circuit bring is brought up. Further Further, the PSN-bound NSP function MUST <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 to detect Fibre Channel specific for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
          <t>The PSN-bound IWF is mapping maps the received scrambled 64B/66B code stream as is into the basic PLE payload.</t>
          <t>The CE-bound NSP function MUST perform</t> <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>transmission word sync (section (Section 49.2.13 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>descrambling (section (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>in order to properly</t> properly:</t>
          <ul spacing="normal">
            <li>
              <t>replace invalid transmission words with the error transmission word 1Eh</t>
            </li>
            <li>
              <t>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being L bit set</t>
            </li>
          </ul>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, packets or if the far-end PSN-bound NSP function did set not setting sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>Before sending the bit stream to the CE, the CE-bound NSP function MUST <bcp14>MUST</bcp14> also scramble the 64B/66B code stream (section (Section 49.2.6 of <xref target="IEEE802.3"/>).</t>
        </section>
        <section anchor="gfc-and-4-lane-128gfc">
          <name>32GFC and 4-lane 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 MUST perform</t> <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>descrambling (section (Section of 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>FEC decoding (section (Section 91.5.3.3 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>reverse transcoding from 256B/257B to 64B/66B (section (Section 119.2.5.7 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <!--
HIDDEN COMMENT: per FC-FS-4, same RS-FEC as 100GE but transcoder from 200GE and 400GE (802.3 section 119) where first 5 bits are not scrambled.
-->

<t>Further

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

-->

<t><xref target="FC-PI-7"/> specifies 64GFC with a mandatory FEC layer.</t>
          <t>To gain access to the 64B/66B code stream stream, the PSN-bound NSP further MUST perform</t> <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>alignment lock (section (Section 134.5.4 of <xref target="IEEE802.3"/> modified to single FEC lane operation)</t>
            </li>
            <li>
              <t>FEC decoding (section (Section 134.5.3.3 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>alignment marker
              <t>alignment-marker removal (section (Section 134.5.3.4 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>reverse transcoding from 256B/257B to 64B/66B (section (Section 91.5.3.5 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>Further
          <t>Further, the PSN-bound NSP MUST <bcp14>MUST</bcp14> perform scrambling (section (Section 49.2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF is mapping maps the same into the basic PLE payload.</t>
          <t>The PSN-bound NSP function is also responsible to detect Fibre Channel specific for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
          <t>The CE-bound NSP function MUST perform</t> <bcp14>MUST</bcp14> perform:</t>
          <ul spacing="normal">
            <li>
              <t>transmission word sync (section (Section 49.2.13 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>descrambling (section (Section 49.2.10 of <xref target="IEEE802.3"/>)</t>
            </li>
          </ul>
          <t>in order to properly</t> properly:</t>
          <ul spacing="normal">
            <li>
              <t>replace invalid transmission words with the error transmission word 1Eh</t>
            </li>
            <li>
              <t>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being L bit set</t>
            </li>
          </ul>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, packets or if  the far-end PSN-bound NSP function did set not setting sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>When sending the bit stream to the CE, the CE-bound NSP function MUST <bcp14>MUST</bcp14> also perform</t> perform:</t>
          <ul spacing="normal">
            <li>
              <t>transcoding from 64B/66B to 256B/257B (section (Section 91.5.2.5 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>alignment marker
              <t>alignment-marker insertion (section (Section 134.5.2.6 of <xref target="IEEE802.3"/>)</t>
            </li>
            <li>
              <t>FEC encoding (section (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 MUST <bcp14>MUST</bcp14> terminate the FEC and replace the OTUk overhead in row 1 1, columns 8-14 with an all-zeros pattern which pattern; this results in a an extended ODUk frame as illustrated in <xref target="extodukframe"/>. The frame alignment overhead (FA OH) in row 1 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 to detect OTUk specific for detecting attachment circuit faults specific to OTUk such as LOS, LOF, LOM LOM, and AIS.</t>
        <t>The PSN-bound IWF is mapping maps the extended ODUk frame into the byte aligned 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 generates generating the FEC.</t>
        <t>When the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being L bit set, the CE-bound NSP function is responsible for generating the ODUk-AIS maintenance signal defined in section Section 16.5.1 of <xref target="G.709"/> at client frame 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 the <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 imply suggest any specific technology to be used for implementing the VPWS demultiplexing and PSN layers.</t>
        <t>The total size of a PLE packet for a specific PW MUST NOT <bcp14>MUST NOT</bcp14> exceed the path MTU between the pair of PEs terminating this PW.</t>
        <t>When a an MPLS PSN layer is used, a VPWS label provides the demultiplexing mechanism as (as described in <xref section="5.4.2" sectionFormat="of" target="RFC3985"/>. target="RFC3985"/>). The PSN tunnel can be a simple best path best-path Label Switched Path (LSP) established using LDP (see <xref target="RFC5036"/> target="RFC5036"/>) or Segment Routing (SR) (see <xref target="RFC8402"/> target="RFC8402"/>); or it can be a traffic engineered traffic-engineered LSP established using RSVP-TE (see <xref target="RFC3209"/> target="RFC3209"/>) or SR policies (see <xref target="RFC9256"/>.</t> target="RFC9256"/>).</t>
        <t>When a an SRv6 PSN layer is used, a an SRv6 service segment identifier Segment Identifier (SID) as (as defined in <xref target="RFC8402"/> does provide target="RFC8402"/>) provides the demultiplexing mechanism and definitions of <xref section="6" sectionFormat="of" target="RFC9252"/> do apply. Both SRv6 service SIDs with the full IPv6 address format defined in <xref target="RFC8986"/> and compressed SIDs (C-SIDs) with the format defined in <xref target="I-D.draft-ietf-spring-srv6-srh-compression"/> target="RFC9800"/> can be used.</t>
        <section anchor="new-srv6-behaviors">
          <name>New SRv6 Behaviors</name>
          <t>Two new encapsulation behaviors behaviors, H.Encaps.L1 and H.Encaps.L1.Red H.Encaps.L1.Red, are defined in this document. The behavior procedures are applicable to both SIDs and C-SIDs.</t>
          <t>The H.Encaps.L1 behavior encapsulates a frame received from an IWF in a an IPv6 packet with an 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 MUST <bcp14>MUST</bcp14> be set to TBA1.</t> 147.</t>
            </li>
            <li>
              <t>The insertion of the SRH MAY <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>

<!--[rfced] We note that RFC-to-be 9800
     (draft-ietf-spring-srv6-srh-compression-27) uses Destination
     Address field.  Please review the following and let us know if
     updates are necessary:

Original:
The first SID is only placed in the destination IPv6 address field.
-->

              <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 IPv6 address field.</t>
            </li>
            <li>
              <t>The insertion of the SRH MAY <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 "End.DX1", "End.DX1 with NEXT-CSID NEXT-CSID", and End.DX1 "End.DX1 with REPLACE-CSID REPLACE-CSID" are defined in this document. These new behaviors are variants of End.DX2 defined in <xref target="RFC8986"/> target="RFC8986"/>, and they all have the following procedures in common.</t> common:</t>
          <t>The End.DX1 SID MUST <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>
          <artwork><![CDATA[
          <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. }
]]></artwork>
]]></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>
          <artwork><![CDATA[
          <sourcecode type="pseudocode" markers="false"><![CDATA[
S01. If (Upper-Layer header type == TBA1 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 RFC8986}} RFC 8986}}
S06. }
]]></artwork>
]]></sourcecode>
        </section>
      </section>
      <section anchor="ple-header">
        <name>PLE Header</name>
        <t>The PLE header MUST <bcp14>MUST</bcp14> contain the PLE control word (4 bytes) and MUST <bcp14>MUST</bcp14> include a fixed size fixed-size RTP header <xref target="RFC3550"/>. The RTP header MUST <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 Associated Channel Header (ACH) from an IP packet or Ethernet frame. The first nibble MUST <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>
          <ul spacing="normal">
            <li>
              <t>L</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>Set
          <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 MUST <bcp14>MUST</bcp14> send appropriate replacement data. The NSP MAY <bcp14>MAY</bcp14> inject an appropriate native fault propagation signal.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>R</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>Set 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 MUST <bcp14>MUST</bcp14> be cleared by the PE once the packet loss state or fault indication has cleared.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>RSV</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>These cleared.</dd>
              <dt>RSV</dt>
              <dd>These bits are reserved for future use. This field MUST <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>FRG</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>These receiver.</dd>
              <dt>FRG</dt>
              <dd>These bits MUST <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver as PLE does not use payload fragmentation.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>LEN</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>In fragmentation.</dd>
              <dt>LEN</dt>

<!--[rfced] Please clarify "to detect malformed packets the default":
     does this mean "to detect malformed packets by default" or is
     another rephrasing necessary?

Original:
To detect malformed packets the default, preconfigured or signaled
payload size MUST be assumed.
-->

              <dd>In accordance to with <xref section="3" sectionFormat="of" target="RFC4385"/> target="RFC4385"/>, the length field MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be assumed.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>Sequence number</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>The assumed.</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 MUST <bcp14>MUST</bcp14> be generated in accordance with the rules defined in <xref section="5.1" sectionFormat="of" target="RFC3550"/> and MUST <bcp14>MUST</bcp14> be incremented with every PLE packet being sent.</t>
            </li>
          </ul> sent.</dd>
          </dl>
        </section>
        <section anchor="rtp-header">
          <name>RTP Header</name>
          <t>The RTP header MUST <bcp14>MUST</bcp14> be included to explicitly convey timing information.</t>
          <t>The RTP header as (as defined in <xref target="RFC3550"/> target="RFC3550"/>) is reused to align with other bit-stream emulation pseudowires defined by <xref target="RFC4553"/>, <xref target="RFC5086"/> target="RFC5086"/>, and <xref target="RFC4842"/> and to allow PLE implementations to reuse pre-existing 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, RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Real-time Transport Protocol (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>
          <ul spacing="normal">
            <li>
              <t>V: Version</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
          <dl spacing="normal" newline="true">
            <dt>V:</dt><dd><t>Version</t>
              <t>The version field MUST <bcp14>MUST</bcp14> be set to 2.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>P: Padding</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
            </dd>
            <dt>P:</dt><dd><t>Padding</t>
              <t>The padding flag MUST <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>X: Header
            </dd>
            <dt>X:</dt><dd><t>Header extension</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>The X bit MUST <bcp14>MUST</bcp14> be set to zero by sender and ignored by receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>CC: CSRC
            </dd>
            <dt>CC:</dt><dd><t>CSRC count</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>The CC field MUST <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>M: Marker</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
            </dd>
            <dt>M:</dt><dd><t>Marker</t>
              <t>The M bit MUST <bcp14>MUST</bcp14> be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>PT: Payload
            </dd>
            <dt>PT:</dt><dd><t>Payload type</t>
            </li>
          </ul>
          <ul empty="true">
            <li>

<!--[rfced] Please review this use of "both":

Original:
      The same PT value MAY be reused both for direction and between
      different PLE VPWS.

Perhaps A:
      The same PT value MAY be reused for both directions and between
      different PLE VPWS.

Perhaps B:
     The same PT value MAY be reused both for directionality and
     between different PLE VPWS.

-->

              <t>A PT value MUST <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 MAY <bcp14>MAY</bcp14> be reused both for direction and between different PLE VPWS.</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>The PT field MAY <bcp14>MAY</bcp14> be used for detection of misconnections.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>Sequence number</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>When
            </dd>
            <dt>Sequence number</dt>
              <dd>When using a 16 bit 16-bit sequence number space, the sequence number in the RTP header MUST <bcp14>MUST</bcp14> be equal to the sequence number in the PLE control word. When using a sequence number space of 32 bit, bits, the initial value of the RTP sequence number MUST <bcp14>MUST</bcp14> be 0 and incremented whenever the PLE control word sequence number cycles through from 0xFFFF to 0x0000.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>Timestamp</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>Timestamp 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 Gbps, the frequency of the clock used for generating timestamps MUST <bcp14>MUST</bcp14> be 125 MHz based on a the common clock I. For bit-streams above 200 Gbps Gbps, the frequency MUST <bcp14>MUST</bcp14> be 250 MHz.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>
              <t>SSRC: Synchronization MHz.</dd>
            <dt>SSRC:</dt><dd><t>Synchronization source</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>The SSRC field MAY <bcp14>MAY</bcp14> be used for detection of misconnections.</t>
            </li>
          </ul>
            </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 size, which MUST <bcp14>MUST</bcp14> be defined during VPWS setup, MUST <bcp14>MUST</bcp14> be the same in both directions of the VPWS VPWS, and MUST <bcp14>MUST</bcp14> remain unchanged for the lifetime of the VPWS.</t>
      <t>All PLE implementations MUST <bcp14>MUST</bcp14> be capable of supporting the default payload size of 1024 bytes. The payload size SHOULD <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
        <name>Byte-Aligned Payload</name>
        <t>The PLE payload is filled in a byte aligned 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 MUST <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
        <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) 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
        <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.draft-schmutzer-bess-bitstream-vpws-signalling"/> target="I-D.schmutzer-bess-bitstream-vpws-signalling"/> and for LDP in <xref target="I-D.draft-schmutzer-pals-ple-signaling"/>.</t> 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
          <name>PSN-Bound Encapsulation Behavior</name>
          <t>After the VPWS is set up, the PSN-bound IWF does perform performs the following steps:</t>
          <ul spacing="normal">
            <li>
              <t>Packetize the data received from the CE is into PLE payloads, all of the same configured size</t>
            </li>
            <li>
              <t>Add PLE control word and RTP header with sequence numbers, flags 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</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
          <name>CE-Bound Decapsulation Behavior</name>
          <t>The CE-bound IWF is responsible for removing the PSN and VPWS demultiplexing headers, PLE control word 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 MUST <bcp14>MUST</bcp14> be implemented where the PLE packets are stored upon arrival. The size of this buffer SHOULD <bcp14>SHOULD</bcp14> be locally configurable to allow accommodation of specific PSN packet delay variation (PDV) expected.</t>
          <t>The CE-bound IWF SHOULD <bcp14>SHOULD</bcp14> use the sequence number in the control word to detect lost and misordered packets. It MAY <bcp14>MAY</bcp14> use the sequence number in the RTP header for the same purposes. purpose. The CE-bound IWF MAY <bcp14>MAY</bcp14> support re-ordering reordering of packets received out of order. If the CE-bound IWF does not support re-ordering reordering, it MUST <bcp14>MUST</bcp14> drop the misordered packets.</t>
          <t>The payload of a lost or dropped packet MUST <bcp14>MUST</bcp14> be replaced with an equivalent amount of replacement data. The contents of the replacement data MAY <bcp14>MAY</bcp14> be locally configurable. By default, all PLE implementations MUST <bcp14>MUST</bcp14> support generation of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xAA" pattern does ensure ensures clock synchronization is maintained and and, for 64B/66B code based services 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 MUST <bcp14>MUST</bcp14> inject the appropriate native downstream fault indication fault-indication signal.</t>
          <t>Whenever a VPWS comes up, the CE-bound IWF enters will enter the intermediate state, will start receiving PLE packets packets, and will store them in the jitter buffer. The CE-bound NSP function will continue to inject the appropriate native downstream fault indication fault-indication signal until a pre-configured preconfigured number of payload s stored in the jitter buffer.</t>
          <t>After the pre-configured preconfigured amount of payload is present in the jitter buffer buffer, the CE-bound IWF transitions to the normal operation state state, and the content of the jitter buffer is streamed out to the CE in accordance with the required clock. In this state state, the CE-bound IWF MUST <bcp14>MUST</bcp14> perform egress clock recovery.</t>
          <t>Considerations for choosing the pre-configured preconfigured amount of payload required to be present for transitioning into the normal state:
* Typically state:</t>
	  <ul>

<li>Typically set to 50% of the de-jitter buffer size to equally allow compensating for increasing and decreasing delay
* Choosing a delay</li>
<li>A compromise between the maximum amount of tolerable PDV and delay introduced to the emulated service</t> service</li></ul>
          <t>The recovered clock MUST <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"/> 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 packet, the CE-bound NSP function SHOULD <bcp14>SHOULD</bcp14> inject the appropriate native downstream fault indication fault-indication signal instead of streaming out the payload.</t>
          <t>If the CE-bound IWF detects loss of consecutive packets for a pre-configured preconfigured 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. 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 declared, the CE-bound NSP function MUST <bcp14>MUST</bcp14> inject the appropriate native downstream fault indication fault-indication signal. If the emulated service does not have a an appropriate maintenance signal defined, the CE-bound NSP function MAY <bcp14>MAY</bcp14> disable its transmitter instead. Also Also, the PSN-bound IWF SHOULD <bcp14>SHOULD</bcp14> set the R bit in the PLE control word of every packet transmitted.</t>
          <t>The CE-bound IWF does change changes from the PLOS to normal state after the pre-configured preconfigured amount of payload has been received similarly 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 packet, the PLE performance monitoring statistics SHOULD <bcp14>SHOULD</bcp14> get updated.</t>
        </section>
      </section>
      <section anchor="ple-performance-monitoring">
        <name>PLE Performance Monitoring</name>
        <t>Attachment circuit performance monitoring SHOULD <bcp14>SHOULD</bcp14> be provided by the NSP. The performance monitors are service specific, documented in related specifications specifications, and beyond the scope of this document.</t>
        <t>The PLE IWF SHOULD <bcp14>SHOULD</bcp14> provide functions to monitor the network performance to be inline with expectations of transport network operators.</t>

<!--[rfced] Please confirm that the following uses of PLE should not
     be flipped in their expansions:

Original:

   *  ES-PLE : PLE Errored Seconds

   *  SES-PLE : PLE Severely Errored Seconds

   *  UAS-PLE : PLE Unavailable Seconds

Perhaps:

   *  ES-PLE : Errored Seconds PLE

   *  SES-PLE : Severely Errored Seconds PLE

   *  UAS-PLE : Unavailable Seconds PLE

-->

        <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/DEG defect SHALL <bcp14>SHALL</bcp14> be counted as an ES-PLE. Each second with a PLR greater than 15% or a PLOS/DEG defect SHALL <bcp14>SHALL</bcp14> be counted as an SES-PLE.</t>
        <t>UAS-PLE SHALL <bcp14>SHALL</bcp14> be counted after a configurable number of consecutive SES-PLE SES-PLEs have been observed, and no longer counted after a configurable number of consecutive seconds without an SES-PLE have been observed. Default The default value for each is 10 seconds.</t>
        <t>Once unavailability is detected, ES and SES counts SHALL <bcp14>SHALL</bcp14> 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 <bcp14>SHALL</bcp14> be added to the ES and SES counts.</t>
        <t>A PLE far-end performance monitor is providing 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> target="G.826"/>.</t>
        <t>Performance monitoring data MUST <bcp14>MUST</bcp14> be provided by the management interface and SHOULD <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 specific, and are documented in relevant section of <xref target="emulated-services"/>.</t>
        <t>The two PLE faults, PLOS and DEG DEG, are detected by the IWF.</t>
        <t>Faults MUST <bcp14>MUST</bcp14> be time stamped timestamped as they are declared and cleared and fault related cleared; fault-related information MUST <bcp14>MUST</bcp14> be provided by the management interface and SHOULD <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 constant bit-rate (CBR) flows that cannot respond to congestion in a TCP-friendly manner as (as described in <xref target="RFC2914"/> target="RFC2914"/>) and are sensitive to jitter, packet loss loss, and packets received out of order.</t>

<!--[rfced] Please review our edits to the following to ensure we have
     captured your intended meaning.

Original:
 Possible options, but not exhaustively, are a Diffserv-enabled
 [RFC2475] PSN with a per domain behavior [RFC3086] supporting
 Expedited Forwarding [RFC3246].  Traffic-engineered paths through the
 PSN with bandwidth reservation and admission control applied.  Or
 capacity over-provisioning.

Current:
Possible options, but not exhaustively, are as follows:

* a Diffserv-enabled (see [RFC2475]) PSN with a per-domain behavior (see [RFC3086]) supporting Expedited Forwarding (see [RFC3246]),

* traffic-engineered paths through the PSN with bandwidth reservation and admission control applied, or

* capacity over-provisioning.

-->

      <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 a as follows</t>
      <ul>
	<li>a Diffserv-enabled <xref target="RFC2475"/> PSN with a per domain per-domain behavior (see <xref target="RFC3086"/> target="RFC3086"/>) supporting Expedited Forwarding (see <xref target="RFC3246"/>. Traffic-engineered target="RFC3246"/>),</li>
	<li>traffic-engineered paths through the PSN with bandwidth reservation and admission control applied. Or capacity over-provisioning.</t> 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 MUST <bcp14>MUST</bcp14> be prevented by following best practices for the isolation of the PSN. These protections are described in the considerations in <xref section="3.4" sectionFormat="of" target="RFC4381"/>, <xref section="4.2" sectionFormat="of" target="RFC5920"/> in target="RFC5920"/>,  <xref section="8" sectionFormat="of" target="RFC8402"/> 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 do decrease the chance of a spoofing attack being successful.</t>
      <t>A data plane attack may force PLE packets to be dropped, re-ordered 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>

<!--[rfced] Please confirm the use of "threads" (and not "threats") in
     the following:

Original:
   Clock synchronization leveraging PTP is sensitive to Packet Delay
   Variation (PDV) and vulnerable to various threads and attack vectors.

-->

      <t>Clock synchronization leveraging PTP is sensitive to Packet Delay Variation (PDV) and vulnerable to various threads 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
        <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 a an emulated bit-stream. IANA is requested to assign 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">TBA1</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">this align="left">This document</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 is requested to assign has assigned identifier values in the "SRv6 Endpoint Behaviors" sub-registry 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">this align="left">This document</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">this align="left">This document</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">this align="left">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Alexander Vainshtein, Yaakov Stein, Erik van Veelen, Faisal Dada, Giles Heron, Luca Della Chiesa and Ashwin Gumaste for their early contributions, review, comments and suggestions.</t>
      <t>Special thank you to</t>
      <ul spacing="normal">
        <li>
          <t>Carlos Pignataro and Nagendra Kumar Nainar for giving the authors new to IETF guidance on how to get started</t>
        </li>
        <li>
          <t>Stewart Bryant for being our shepherd</t>
        </li>
        <li>
          <t>Tal Mizahi, Joel Halpern, Christian Huitema, Tony Li, Tommy Pauly for their reviews and suggestions during last call</t>
        </li>
        <li>
          <t>Andrew Malis and Gunter van de Velde for their guidance through the process</t>
        </li>
      </ul>
    </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>
        <reference anchor="RFC3985">
          <front>
            <title>Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</title>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <author fullname="P. Pate" initials="P." role="editor" surname="Pate"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3985"/>
          <seriesInfo name="DOI" value="10.17487/RFC3985"/>
        </reference>
        <reference anchor="RFC3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="S. Casner" initials="S." surname="Casner"/>
            <author fullname="R. Frederick" initials="R." surname="Frederick"/>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
            <date month="July" year="2003"/>
            <abstract>
              <t>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="64"/>
          <seriesInfo name="RFC" value="3550"/>
          <seriesInfo name="DOI" value="10.17487/RFC3550"/>
        </reference>
        <reference anchor="RFC3551">
          <front>
            <title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="S. Casner" initials="S." surname="Casner"/>
            <date month="July" year="2003"/>
            <abstract>
              <t>This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="65"/>
          <seriesInfo name="RFC" value="3551"/>
          <seriesInfo name="DOI" value="10.17487/RFC3551"/>
        </reference>
        <reference anchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC9252">
          <front>
            <title>BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)</title>
            <author fullname="G. Dawra" initials="G." role="editor" surname="Dawra"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="July" year="2022"/>
            <abstract>
              <t>This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9252"/>
          <seriesInfo name="DOI" value="10.17487/RFC9252"/>
        </reference>
        <reference anchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t>SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <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"/>

<!-- [IEEE802.3] -->
        <reference anchor="IEEE802.3" target="https://standards.ieee.org/ieee/802.3/10422/"> target="https://ieeexplore.ieee.org/document/9844436">
          <front>
            <title>IEEE Standard for Ethernet</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2022" month="May"/> month="July"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.3-2022"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9844436"/>
        </reference>

<!-- [G.707] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2007" month="January"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.707"/>
        </reference>

<!-- [G.709] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2020" month="June"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.709"/>
        </reference>

<!-- [G.823] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.823"/>
        </reference>

<!--  [G.825] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.825"/>
        </reference>

<!-- [rfced] Reference [G.824] was flagged as not being cited anywhere in the text. Please review and let us know where it should be cited or if the reference entry should be removed.-->
        <reference anchor="G.824" target="https://www.itu.int/rec/T-REC-G.824">
          <front>
            <title>The control of jitter and wander within digital networks which are based on the 1544 kbits hierarchy</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.824"/>
        </reference>

<!--  [G.783] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2006" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.783"/>
        </reference>

<!--  [G.8251] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2022" month="November"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8251"/>
        </reference>

<!-- [G.8261] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2019" month="August"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8261"/>
        </reference>

<!-- [rfced] [G.8262] This ITU-T Recommendation was superseded in
     October 2024.  We have updated this reference to use the most
     current version.  Please let us know if you have any
     objections.-->

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

<!--  [G.8261.1] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2012" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8261.1"/>
        </reference>

<!-- [G.8265.1] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2022" month="November"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8265.1"/>
        </reference>

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

<!-- [GR499] -->
        <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>

<!-- [IANA-Proto] -->
        <reference anchor="IANA-Proto" target="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1"> target="https://www.iana.org/assignments/protocol-numbers">
          <front>
            <title>IANA "Assigned
            <title>Assigned Internet Protocol Numbers" sub-registry</title> Numbers</title>
            <author>
              <organization>IETF</organization>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

<!--  [IANA-SRv6-End] -->
        <reference anchor="IANA-SRv6-End" target="https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors"> target="https://www.iana.org/assignments/segment-routing">
          <front>
            <title>IANA "SRv6
            <title>SRv6 Endpoint Behaviors" sub-registry</title> Behaviors</title>
            <author>
              <organization>IETF</organization>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </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"/>

<!-- [RFC9800] draft-ietf-spring-srv6-srh-compression-23 companion doc.
-->

<reference anchor="I-D.draft-ietf-spring-srv6-srh-compression"> anchor="RFC9800" target="https://www.rfc-editor.org/info/rfc9800">
  <front>
      <title>Compressed SRv6 Segment List Encoding (CSID)</title>
      <author initials="W." surname="Cheng" fullname="Weiqiang Cheng" initials="W." surname="Cheng"> role="editor">
         <organization>China Mobile</organization>
      </author>
      <author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author fullname="Zhenbin Li" initials="Z." surname="Li"> surname="Li" fullname="Zhenbin Li">
         <organization>Huawei Technologies</organization>
      </author>
      <author fullname="Bruno Decraene" initials="B." surname="Decraene"> surname="Decraene" fullname="Bruno Decraene">
         <organization>Orange</organization>
      </author>
      <author initials="F." surname="Clad" fullname="Francois Clad" initials="F." surname="Clad"> role="editor">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <date day="6" month="February" year="2025"/>
            <abstract>
              <t>   Segment Routing over IPv6 (SRv6) is the instantiation of Segment
   Routing (SR) on the IPv6 dataplane.  This document specifies new
   flavors for the SRv6 endpoint behaviors defined in RFC 8986, which
   enable the compression of an SRv6 segment list.  Such compression
   significantly reduces the size of the SRv6 encapsulation needed to
   steer packets over long segment lists.

   This document updates RFC 8754 by allowing a Segment List entry in
   the Segment Routing Header (SRH) to be either an IPv6 address, as
   specified in RFC 8754, or a REPLACE-CSID container in packed format,
   as specified in this document.

              </t>
            </abstract> month='June' year='2025'/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-compression-23"/> name="RFC" value="9800"/>
  <seriesInfo name="DOI" value="10.17487/RFC9800"/>
</reference>

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

<!-- [T11] -->
        <reference anchor="RFC4197"> anchor="T11" target="https://www.incits.org/committees/t11">
          <front>
            <title>Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks</title>
            <author fullname="M. Riegel" initials="M." role="editor" surname="Riegel"/>
            <date month="October" year="2005"/>
            <abstract>
              <t>This document defines the specific requirements
            <title>T11 - Fibre Channel</title>
            <author>
              <organization>INCITS</organization>
            </author>
          </front>
        </reference>

<!-- [rfced] [FC-PI-2] The original URL for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of this reference -
https://webstore.ansi.org/standards/incits/incits4042006 - leads to an
error page on the Plesiochronous Digital Hierarchy as well as ANSI webstore.  We found the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned following URL that
points to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references most recent version of this INCITS document. We have
updated this reference to use that URL. We have also updated the generic requirements date
for PWE3 where applicable and complements them by defining requirements originating this reference from specifics of TDM circuits. This memo provides 2006 to 2016 to match the information for at the Internet community.</t>
            </abstract>
URL. Please let us know if you have any objections. -->
        <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="RFC" value="4197"/>
          <seriesInfo name="DOI" value="10.17487/RFC4197"/> name="INCITS" value="404-2006 (S2016)"/>
        </reference>
        <reference anchor="RFC4381">
          <front>
            <title>Analysis of the Security

<!-- [rfced] [FC-PI-5] A more recent version of BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author fullname="M. Behringer" initials="M." surname="Behringer"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This this INCITS document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.</t>
              <t>The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for
avaialable here:
https://webstore.ansi.org/standards/incits/incits4792011s2021. May we
update this reference to use the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4381"/>
          <seriesInfo name="DOI" value="10.17487/RFC4381"/>
        </reference> most current version?-->
        <reference anchor="RFC5920"> anchor="FC-PI-5" target="https://webstore.ansi.org/standards/incits/incits4792011">
          <front>
            <title>Security Framework for MPLS and GMPLS Networks</title>
            <author fullname="L. Fang" initials="L." role="editor" surname="Fang"/>
            <title>Information Technology - Fibre Channel - Physical Interface-5 (FC-PI-5)</title>
            <author>
              <organization>INCITS</organization>
            </author>
            <date month="July" year="2010"/>
            <abstract>
              <t>This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract> year="2011"/>
          </front>
          <seriesInfo name="RFC" value="5920"/>
          <seriesInfo name="DOI" value="10.17487/RFC5920"/> name="INCITS" value="479-2011"/>
        </reference>
        <reference anchor="RFC4385">
          <front>
            <title>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word

<!-- Note: XML for Use over an MPLS PSN</title>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="L. Martini" initials="L." surname="Martini"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes the preferred design most current version of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over [FC-PI-5] if an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields update is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4385"/>
          <seriesInfo name="DOI" value="10.17487/RFC4385"/>
        </reference>
     chosen:

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

<!-- [rfced] [FC-PI-5am1] A more recent version of this INCITS
     document is avaialable here:
     https://webstore.ansi.org/standards/incits/incits4792011am2016r2021. May
     we update this reference to use the most current version?-->

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

<!-- Note: XML for most current version of [FC-PI-5am1] if an update is chosen.

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

<!-- [rfced] For [FC-PI-6]: A more recent version of this INCITS
     document is avaialable here:
     https://webstore.ansi.org/standards/incits/incits5332016r2021. May
     we update this reference to use the most current version?-->

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

<!-- Note: XML for most current version of [FC-PI-6] if an update is chosen.

        <reference anchor="FC-PI-6" target="https://webstore.ansi.org/standards/incits/incits5122015"> 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="2015"/> year="2020"/>
          </front>
          <seriesInfo name="INCITS" value="512-2015 (R2020)"/>
        </reference>

-->

<!-- [rfced] [FC-PI-6P]: A more recent version of this INCITS document
     is avaialable here:
     https://webstore.ansi.org/standards/incits/incits5332016r2021. May
     we update this reference to use the most current version?-->

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

<!-- Note: XML for most current version of [FC-PI-6P]:

        <reference anchor="FC-PI-7" target="https://webstore.ansi.org/standards/iso/isoiec141651472021"> anchor="FC-PI-6P" target="https://webstore.ansi.org/standards/incits/incits5332016r2021">
          <front>
            <title>Information Technology – - Fibre Channel - Physical Interfaces 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>INCITS</organization>
              <organization>ISO/IEC</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="ISO/IEC" value="14165-147:2021"/>
        </reference>

<!-- [G.826] -->
        <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>International Telecommunication Union (ITU)</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2002" month="December"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.826"/>
        </reference>

<!--  [ATIS-0900105.09.2013] -->
        <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="2013"/>
          </front>
        </reference>
        <reference anchor="RFC4553">
          <front>
            <title>Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)</title>
            <author fullname="A. Vainshtein" initials="A." role="editor" surname="Vainshtein"/>
            <author fullname="YJ. Stein" initials="YJ." role="editor" surname="Stein"/>
            <date month="June" year="2006"/>
            <abstract>
              <t>This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4553"/>
          <seriesInfo name="DOI" value="10.17487/RFC4553"/>
        </reference>
        <reference anchor="RFC4906">
          <front>
            <title>Transport of Layer 2 Frames Over MPLS</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="N. El-Aawar" initials="N." role="editor" surname="El-Aawar"/>
            <date month="June" year="2007"/>
            <abstract>
              <t>This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4906"/>
          <seriesInfo name="DOI" value="10.17487/RFC4906"/>
        </reference>
        <reference anchor="RFC4448">
          <front>
            <title>Encapsulation Methods for Transport of Ethernet over MPLS Networks</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="N. El-Aawar" initials="N." surname="El-Aawar"/>
            <author fullname="G. Heron" initials="G." surname="Heron"/>
            <date month="April" year="2006"/>
            <abstract>
              <t>An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4448"/>
          <seriesInfo name="DOI" value="10.17487/RFC4448"/>
        </reference>
        <reference anchor="RFC4842">
          <front>
            <title>Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)</title>
            <author fullname="A. Malis" initials="A." surname="Malis"/>
            <author fullname="P. Pate" initials="P." surname="Pate"/>
            <author fullname="R. Cohen" initials="R." role="editor" surname="Cohen"/>
            <author fullname="D. Zelig" initials="D." surname="Zelig"/>
            <date month="April" year="2007"/>
            <abstract>
              <t>This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4842"/>
          <seriesInfo name="DOI" value="10.17487/RFC4842"/>
        </reference>
        <reference anchor="RFC7212">
          <front>
            <title>MPLS Generic Associated Channel (G-ACh) Advertisement Protocol</title>
            <author fullname="D. Frost" initials="D." surname="Frost"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="M. Bocci" initials="M." surname="Bocci"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7212"/>
          <seriesInfo name="DOI" value="10.17487/RFC7212"/>
        </reference>
        <reference anchor="RFC4443">
          <front>
            <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="M. Gupta" initials="M." role="editor" surname="Gupta"/>
            <date month="March" year="2006"/>
            <abstract>
              <t>This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="89"/>
          <seriesInfo name="RFC" value="4443"/>
          <seriesInfo name="DOI" value="10.17487/RFC4443"/>
        </reference>
        <reference anchor="RFC5036">
          <front>
            <title>LDP Specification</title>
            <author fullname="L. Andersson" initials="L." role="editor" surname="Andersson"/>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei"/>
            <author fullname="B. Thomas" initials="B." role="editor" surname="Thomas"/>
            <date month="October" year="2007"/>
            <abstract>
              <t>The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5036"/>
          <seriesInfo name="DOI" value="10.17487/RFC5036"/>
        </reference>
        <reference anchor="RFC8077">
          <front>
            <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/>
            <date month="February" year="2017"/>
            <abstract>
              <t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.</t>
              <t>This document is a rewrite of RFC 4447 for publication as an Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="84"/>
          <seriesInfo name="RFC" value="8077"/>
          <seriesInfo name="DOI" value="10.17487/RFC8077"/>
        </reference>
        <reference anchor="RFC3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="January" year="2001"/>
            <abstract>
              <t>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3031"/>
          <seriesInfo name="DOI" value="10.17487/RFC3031"/>
        </reference>
        <reference anchor="RFC4875">
          <front>
            <title>Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
            <author fullname="R. Aggarwal" initials="R." role="editor" surname="Aggarwal"/>
            <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
            <author fullname="S. Yasukawa" initials="S." role="editor" surname="Yasukawa"/>
            <date month="May" year="2007"/>
            <abstract>
              <t>This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.</t>
              <t>There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4875"/>
          <seriesInfo name="DOI" value="10.17487/RFC4875"/>
        </reference>
        <reference anchor="RFC8754">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <date month="March" year="2020"/>
            <abstract>
              <t>Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8754"/>
          <seriesInfo name="DOI" value="10.17487/RFC8754"/>
        </reference>
        <reference anchor="RFC3711">
          <front>
            <title>The Secure Real-time Transport Protocol (SRTP)</title>
            <author fullname="M. Baugher" initials="M." surname="Baugher"/>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="M. Naslund" initials="M." surname="Naslund"/>
            <author fullname="E. Carrara" initials="E." surname="Carrara"/>
            <author fullname="K. Norrman" initials="K." surname="Norrman"/>
            <date month="March" year="2004"/>
            <abstract>
              <t>This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3711"/>
          <seriesInfo name="DOI" value="10.17487/RFC3711"/>
        </reference>
        <reference anchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author fullname="D. Awduche" initials="D." surname="Awduche"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="D. Gan" initials="D." surname="Gan"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <date month="December" year="2001"/>
            <abstract>
              <t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
            </abstract> year="2023"/>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
          <refcontent>ATIS-0900105.09.2013(S2023)</refcontent>
        </reference>
        <reference anchor="RFC9256">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <date month="July" year="2022"/>
            <abstract>
              <t>Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</t>
              <t>This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>
        <reference anchor="RFC5086">
          <front>
            <title>Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)</title>
            <author fullname="A. Vainshtein" initials="A." role="editor" surname="Vainshtein"/>
            <author fullname="I. Sasson" initials="I." surname="Sasson"/>
            <author fullname="E. Metz" initials="E." surname="Metz"/>
            <author fullname="T. Frost" initials="T." surname="Frost"/>
            <author fullname="P. Pate" initials="P." surname="Pate"/>
            <date month="December" year="2007"/>
            <abstract>
              <t>This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals
        <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"/>

<!-- [I-D.schmutzer-bess-bitstream-vpws-signalling]
draft-schmutzer-bess-bitstream-vpws-signalling-02
IESG State: I-D Exists as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5086"/>
          <seriesInfo name="DOI" value="10.17487/RFC5086"/>
        </reference>
        <reference anchor="RFC8214">
          <front>
            <title>Virtual Private Wire Service Support in Ethernet VPN</title>
            <author fullname="S. Boutros" initials="S." surname="Boutros"/>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <author fullname="S. Salam" initials="S." surname="Salam"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="August" year="2017"/>
            <abstract>
              <t>This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8214"/>
          <seriesInfo name="DOI" value="10.17487/RFC8214"/>
        </reference> 03/05/25.
-->

<reference anchor="I-D.draft-schmutzer-bess-bitstream-vpws-signalling"> 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 fullname="Steven Gringeri" initials="S." surname="Gringeri"> surname="Gringeri" fullname="Steven Gringeri">
         <organization>Verizon</organization>
      </author>
      <author fullname="Jeremy Whittaker" initials="J." surname="Whittaker"> surname="Whittaker" fullname="Jeremy Whittaker">
         <organization>Verizon</organization>
      </author>
      <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" initials="C." surname="Schmutzer"> role="editor">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author fullname="Bharath Vasudevan" initials="B." surname="Vasudevan"> surname="Vasudevan" fullname="Bharath Vasudevan">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author fullname="Patrice Brissette" initials="P." surname="Brissette"> surname="Brissette" fullname="Patrice Brissette">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <date day="18" month="October" year="2024"/>
            <abstract>
              <t>   This document specifies the mechanisms to allow for dynamic
   signalling of Virtual Private Wire Services (VPWS) carrying bit-
   stream signals over Packet Switched Networks (PSN).

              </t>
            </abstract> day="18" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-schmutzer-bess-bitstream-vpws-signalling-02"/> value="draft-schmutzer-bess-bitstream-vpws-signalling-02" />
</reference>

<!-- [I-D.schmutzer-pals-ple-signaling]
draft-schmutzer-pals-ple-signaling-02
IESG State: I-D Exists as of 03/05/25.
-->

<reference anchor="I-D.draft-schmutzer-pals-ple-signaling"> 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" initials="C." surname="Schmutzer"> role="editor">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <date day="20" month="October" year="2024"/>
            <abstract>
              <t>   This document defines extension to the Pseudowire Emulation Edge-to-
   Edge (PWE3) control protocol [RFC4447] required for the setup of
   Private Line Emulation (PLE) pseudowires in MPLS networks.

              </t>
            </abstract> day="20" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-schmutzer-pals-ple-signaling-02"/> value="draft-schmutzer-pals-ple-signaling-02" />

</reference>
        <reference anchor="RFC2914">
          <front>
            <title>Congestion Control Principles</title>
            <author fullname="S. Floyd" initials="S." surname="Floyd"/>
            <date month="September" year="2000"/>
            <abstract>

        <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"/>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="include">
      <name>Acknowledgements</name>
      <t>The goal of this document is to explain the need for congestion control in the Internet, and authors would like to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="41"/>
          <seriesInfo name="RFC" value="2914"/>
          <seriesInfo name="DOI" value="10.17487/RFC2914"/>
        </reference>
        <reference anchor="RFC2475">
          <front>
            <title>An Architecture for Differentiated Services</title>
            <author fullname="S. Blake" initials="S." surname="Blake"/>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <author fullname="M. Carlson" initials="M." surname="Carlson"/>
            <author fullname="E. Davies" initials="E." surname="Davies"/>
            <author fullname="Z. Wang" initials="Z." surname="Wang"/>
            <author fullname="W. Weiss" initials="W." surname="Weiss"/>
            <date month="December" year="1998"/>
            <abstract>
              <t>This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2475"/>
          <seriesInfo name="DOI" value="10.17487/RFC2475"/>
        </reference>
        <reference anchor="RFC3086">
          <front>
            <title>Definition of Differentiated Services Per Domain Behaviors 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 Rules <contact fullname="Ashwin Gumaste"/> for their Specification</title>
            <author fullname="K. Nichols" initials="K." surname="Nichols"/>
            <author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
            <date month="April" year="2001"/>
            <abstract>
              <t>This document defines and discusses Per-Domain Behaviors in detail early
      contributions, review, comments, and lays out the format suggestions.</t>
      <t>Special thank you to:</t>
      <ul spacing="normal">
        <li><t><contact fullname="Carlos Pignataro"/> and required content <contact
        fullname="Nagendra Kumar Nainar"/> for contributions to giving the Diffserv WG authors new-to-the-IETF
        guidance on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3086"/>
          <seriesInfo name="DOI" value="10.17487/RFC3086"/>
        </reference>
        <reference anchor="RFC3246">
          <front>
            <title>An Expedited Forwarding PHB (Per-Hop Behavior)</title>
            <author fullname="B. Davie" initials="B." surname="Davie"/>
            <author fullname="A. Charny" initials="A." surname="Charny"/>
            <author fullname="J.C.R. Bennet" initials="J.C.R." surname="Bennet"/>
            <author fullname="K. Benson" initials="K." surname="Benson"/>
            <author fullname="J.Y. Le Boudec" initials="J.Y." surname="Le Boudec"/>
            <author fullname="W. Courtney" initials="W." surname="Courtney"/>
            <author fullname="S. Davari" initials="S." surname="Davari"/>
            <author fullname="V. Firoiu" initials="V." surname="Firoiu"/>
            <author fullname="D. Stiliadis" initials="D." surname="Stiliadis"/>
            <date month="March" year="2002"/>
            <abstract>
              <t>This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended how to provide a building block get started</t></li>
        <li><t><contact fullname="Stewart Bryant"/> for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3246"/>
          <seriesInfo name="DOI" value="10.17487/RFC3246"/>
        </reference>
        <reference anchor="RFC9055">
          <front>
            <title>Deterministic Networking (DetNet) Security Considerations</title>
            <author fullname="E. Grossman" initials="E." role="editor" surname="Grossman"/>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <author fullname="A. Hacker" initials="A." surname="Hacker"/>
            <date month="June" year="2021"/>
            <abstract>
              <t>A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates being our
        shepherd</t></li>
        <li><t><contact fullname="Tal Mizahi"/>, <contact fullname="Joel
        Halpern"/>, <contact fullname="Christian Huitema"/>, <contact
        fullname="Tony Li"/>, and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken <contact fullname="Tommy Pauly"/> for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.</t>
              <t>This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.</t>
              <t>This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9055"/>
          <seriesInfo name="DOI" value="10.17487/RFC9055"/>
        </reference>
        <reference anchor="RFC7384">
          <front>
            <title>Security Requirements of Time Protocols in Packet Switched Networks</title>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <date month="October" year="2014"/>
            <abstract>
              <t>As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP)
        reviews and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, suggestions during Last Call</t></li>
        <li><t><contact fullname="Andrew Malis"/> and <contact
        fullname="Gunter van de Velde"/> for their guidance through the dependencies between other security services and time synchronization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7384"/>
          <seriesInfo name="DOI" value="10.17487/RFC7384"/>
        </reference>
      </references>
    </references>
        process</t></li>
      </ul>
    </section>

    <section anchor="contributors" numbered="false" toc="include" removeInRFC="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>

<!--[rfced] Please review instances in which a slash character "/" is
     used and consider if "and", "or", or "and/or" might be clearer
     for the reader. -->

<!--[rfced] We had the following questions related to terminology used throughout the document:

a) We see multiple similar forms of the following terms.  Please let us know if/how they should be made consistent:

bit stream vs. bit-stream
lane vs. Lane

-->

<!-- ##markdown-source:
H4sIAAAAAAAAA+19a3cbx7Hgd/6KjnzuXTIBQAAk+NC5zjUFghITkkIISHbO
7iZnCDTICQczuDMDUrDpPfsf9h/uL9l69WMeIClLsp2NmROZnOnprq6urndX
N5vNjUkyDePrl2qZz5oHGxvZ8moeZlmYxOPVQr9Up4PxycZGHuYR/DFMw7sg
1+osjLUazJdRkENDldzpVA2Dya3O1eg+zCc3eqoudH6fpLfZRnB1leo7+Phs
sDFNJnEwh56maTDLm6GGQRdBlDUXkW52ehsT6P06SVcvVZZPN8JF+lLl6TLL
u+32YbsL0OVBPP17ECUx9LHS2cYifKn+e55MGipL0jzVswx+W835l0kyn+s4
z/7nxkawzG+S9OWGUk34v1JhnL1Uo5Z6ncLkdRrSQwZtlOs7HRffJClg6D38
9X0S04OvMhhM5y+lu68mYb5yfyRT7f2xjPPUvVzcEPD8l54HYYSTxSFb1zLk
N3c8UgsmUIT4Ty317U2Y58GtTj2Q/6RTPV+VXn1hmP9BY7buzZjrgb5oqTO9
mgdx7IF8EU6SKAgLbwjiY73MM6AgNdaRvqW+PjfoFy0Z9Zucx2hNdRHkfkuN
JjfzZf59Ac/9mzTM8jCIS28J8H6YTRI1WsFizoH4TuNJi16mCW4dPQ3zJP0C
k5lkDMo3Exy/in2Yyqs0uY/L0/CeCvg6DlQ/SRdJStv6S8B6hWMCpDAUQQrc
Bz4Kr5Z5ZXMeAdzL9NYD+yiepjrI3GOCu/PvHaTyDDhH9AVADnjQ1hUM+s08
uAZ+ElTI5aSljoNp4MF6EoRZELmnBOrR+fEXgHBGQ7WmMNQ3wXxapYDXQMzz
IIr0dQDsxQPytU6DaFp5+bORw3XGI3sEUQB80FJ3sNfea9ilPv0O0vC2/IYR
HM7vsMfVFwAWuNttCwa9ozG/CcxQVbDPgBp0FAH2bkKd+VRxtpwE1XePco/P
O4loioNPbtYxC2DVF0EYBz7Tu0CiB3mt/rycB6n//mcEPA7CWxz+ES43DK/j
IA/SxOd0QRolWekVgf0qWmp1otMYaDzOllEOovdLcLwFD/3NNf4tcNu3DN43
CMsMQIHXFpSNjTCeJekc9t6dRtZ4edLf7Rzum193Djrya++w23ZPe/jruEMv
lRK9Df5WTXUSgiIGhAeCT1il04oEL0Ecfk+7HRS/i/7peMS9BOk1YuQmzxfZ
y+3t+/v7VhgDYrIWfLONahYoAVpn23mnA1+c9JvD02a3AMKpmQ3oi2M9uYmT
KLlelaFSw5tVFk6Ac57GuU5nwURn0KarNqXPrU+CW19lIGh0K4izkEAnfTJI
p9k2z0f+s9veBY1zjzqZgmB5qeRPhqL3U2bWrJlbs2cm1vuZJrYPxEJr5Cbm
LVkvmHc+19zgYW/7CPTvKergqmNnun103vlZZwuTgv8UV7PjVnPvM854z8xy
7+eZYa/Thbn0ilPruakNP+fchnZyw59pdjs7jy3c/nMm93//9/95xvSQyeyb
6e1/udllCf4/1JPObmev19nd77a7xd3Y7eBf8Oh166BbJM1BPG3mSRN2FCgj
aZKqBQCPc45hfRZBChIPppOhyqqSq3/oCYqOTEETkJHwJibggwgN4xiBytVV
mDdTtOin4XWYA0YWQX7DPUCbGLuApk+jw++eDDeUCcsYkEzr8S7GfzdPx++2
1HqJki9BquTbqZ5sj5uXg36TUFBkwt1mpwtPjsano2b7sN3utHut9mEL6GKn
gKvRKp7cpEmcLDP1dpHTaotHQm2O3l4Mxluw5ObJINLEpMbhHGQvTd90IHN8
EgUI0UfTA3zL/8hU2sivdjKggp0i0e8QUWxsxCWNYOeQBT7+2uu13a9GOTg4
PNiTXw+7va55utumX08Hg8FBu9sq4g6fqpEASeQzyG9gfXX+NCHAp7VYsHNu
hVprQgP+sk2jb3dA3na3i/ug22z3aBvst4sb3SxaDLoYEzYxKIQTwFSZt/KG
qkHXToN0crOCtT9+84zt/aXoGeZSpOf9ZrsjszwssTPLmszMEqHjPAVSArMs
VzGj4pecz2Fx1dpN0pNw5xaJagwTIGM/iVQyU/9AhTGlnXYP/8Cv92F+E8Z2
yWRqmbq/CSc3KgAGfhVkGjhbTMjotncP1C3wr+3MLe8vyaiKO7YNiNgRRPS+
KCJ+1fQOk6+iRXkSbveL4qbT290lIvmV0MjuY8jYPyjuGNBX0mACsKDLcZIh
Qp6x1kr/1zJckDSbLeOJzOIqSiaApl+QURyU9sdeiRB6nZ9ECY/yRbX5dnzx
y1J/SbkD9aVjdLvShJ3qkRVVDxVkC1DEMpB1oJ5RkMXQ/S+qmJWsyMNm+8BM
rVs3tcnj9OzoNouCO1h9JNlfdILd4gQP/LVrFVdPgl9THQUrdRekIY9u6DAC
DMACBotFBIBdRVrliaxlkxkWqO43yTQDEyQFROh4siqTwS9KxzjhIjZAPesa
bPTK2ICPQwwhwoM5mCZpkicT2Mg5g4QPZmHEKtts3Xx/0en2Wms27mW3VzI0
0JZQY8t6xBEKxkUfoAEAXusYSH6i+mmItB88OS+YySRJp9KyDLTgsInewVb8
j6leJHkLB8iyJG4BwW1nME5zch1uh9Nke5pMshb88Z+nx193O53OPtgSO3uj
wdFl/82/H7/tvzsfXIy/fn3ZhHkVGfRhs9Mm5ny5e1hUTauTNXO8xE2cki0F
pDwevb7ccojwX/5KkQAzrSChg0g4Pbo4ag6RjotKOjxWL46yLLyOYRMzRQIf
GBqKv1jOr8Akf6Gy5VUz1dfA+tJnaCAYc19LsUEckP0U0LCEzm2zxZoxD1h5
0Ppwk8+jr8qPmx0zudHl3V5zEE9r5oev0PmwSGCnqFf6JrgLk59hUpm+xl+a
abJEl3j5b5lSlgLgWqBrXhnoNkiz2ECjudlsqgCMcJQ+8Of4JgTtKZksSdjo
DwuQuRkpEoY/h1GYr1A+3YVpvkSviOQ93AP9qkyndyHaZZvvh9+OtsiHgjGD
ABhbsIqSAHq70qsEJPkY2d9xeMfM8Bxd+4tIf0BpuDk+Pt9SONkgYocLrM1d
OIV+F5leThMay6k0qO9gQgN8D4Dwd/Ia1F7kn5SFIQpCZrIwrIa8ORxdbLUE
G/NwOo00/PEV0myaTJcT1jQAjPMkx8kiBy6hCmCbpOEVQBiIvFITDIFN1+WF
bA7PBlvE5QHAYJHRc5h7nOSgoUerj8BP5qP5vSyLGfZbRNWIl8WsyqM5KYIN
mDysO0wRiDhIpw0V5oJi5mBGKJuJT1EF++GH/8RIS6+38+OPLUGRtlPOlp6g
J+dZA4wTDfBNgjRd4cwsczgO8gClFPLK4fG7bAunOdWzMC6MdNje+/FH2Ezm
793dA/gbRkU0atCdrm8aamFcmqCAwMTr6IPmSSx4Sgs9xeFJAgeknwFygQyW
qThVFqnOJb1nRrtjyPSZqsH0GtA8hKW9T5bRFIhdUSgMv2FSutOAmbdAC/pD
gOgkXW8JFtoElB0EBJbBOpWMpxHA6i+zPJnbIfowxFTzZkOIEYpYa/ZJ+R4+
29UPP7C2gghbaA5cA3z5vdZkK8xpHwH/oL5onnMNUgaIaDiwY7FTSWM2DiIo
mE5TDXwJddgknsBIAM4VduJPgUwVp+r4mEdwYYHFNkVCCLVzqlmG0jBsA2Ez
jIwJIiRSQjSeaxjIfXuSpMu52jwfnMBmATMhnBm6gxU4AgqBdnYV7HIFapQn
aQA4PoINZbYFbbvR0QXYkB9yHWcF3MGCEcFMNCIna6m3jF+0WXLo0Nuekb7T
kQLOkNyz8yrwnMm2x6JTXhhWZtfHXwPifUG8MpRY/NTifK7BxIjDbO520dUK
SGLc6dBWPYqypMEK2zaYyriu29M0Wai5YTzoPQd4J2mSZU2BOYMFQ6gZIker
awFFCOc+K7Mbi6nYsmQHb0sRGwmRs97qFdj2YCKx8Y6WQj9MJ8BX1mTcwTYZ
btXwjYPdLmwDZj5TXYAIwSg8CInJEWuADkDxgu5hYN5DGgMNouj6u27I0g5U
A1hvaArEg0wBOzcceky5PUG6ArY83kLcIuLN2z7smgCgTuFtH9jxKAhp/EDo
9j5YNTBtEEQQikXmP/AW2oDKBzIfpRIzPGNpLdE5EOtA1sEtdqGZ8GRgt4A7
7t1MNWDWkAUgmYSQUTZrcTk81itJA10kQ09w5AVhOktwf6BmEU9wGTLg2fMw
CgjvI0MxzaPrOEFz+WlRWSCJ0dE4qSUKFlvkXilqOyjFSBXCXePYUAzMCsDM
oFPYfEOAM0wsARyLC+qNc0EN0QUVOt/15rjTUAP4/3iHEDnY2cIJEnOgAZyG
gzJCxP0sBStxjjt+Gs5gbyHCchPTCxFXKEwCx/gbRZ7g73IQCWi0/fjjNgqH
/fY+bAqE5O34QvGTQ3ySq+vwGpCRIxvV04xxZPUP0sWArFB2ZjUqn3gg74sS
nMQmaXOso7gNjAIOg3kiS79FvCAKwWwxMhig+52EeADATGJxaqcF/6MZ4G+7
LdLiCobXRZJb/U0TPwHqBDXmxfm70fhFg/+rLt7S75eDv7w7vRwc4++jN0dn
Z/YX02L05u27s2P3m/uy//YcLKdj/hieqtKj86O/wn8Q1Bdvh+PTtxdHZy+q
O4Fwm1gOi3oHY7mwe171h6qzKzgBIw4Xjf846OzvMqOLeTBSLflPWIAVEroO
UmIsUQTcfIFEC9IWhshukvtYIS9oIRrHoA6EEjjGni41ER9olefJVEfQpNBm
Y+P36qj/BkxcMAGTSUjkYcTSGx0gF+V9t9/tADPG5qcjbA77fA7a59T4KkZE
Z/y+eQYtSJOGP/ARfbHMYc/Ncdex0U0vXl3WvVKvmIFfgnjSKTQ8HzV5XMs2
QFtm6cJDvDod4+tXyzDCZHAyZK9Tmo4470ZL4BYoTOsirzSzPgHTN5HlV7CT
LqEHfDPAFwXVjp4O8fGjos2XZPjJ6LLPY3DOKAGWLC/7WlpiDJRaHg9eQ8Nj
nMSU98Lv1QCnOMDAOUwL5g8sDp6eDLBLUKPuMdhJrzHrMWX8QIPT/jkCam37
vqh656ASogZl1XmrnjM+KIqK3wH7zmEhkL8NIug2JT2dmCH9mcToDR3E17Dk
oIDgp5RdYAa9MC6uvsmzIqVqTb6DidtSP9+emE6+Ff3uRGIC8PbsGOd1FlwB
sR6jDU8ohd5KM+q1d8AAachfB+39fZrfGfZ9luBcTgKgK3z0lp9lmXo7UyeY
kEBPz72nRIIz+2rkvbKb4Gx4So/v1TC5B2o4RWMVHo8cwNakG4KoRxIf4NB1
yjG+HJ5Z6nez8ztC1AgJtXc6NL8Lgg14qdF0EwbugqC4oCi8NTqhU5B2GRlp
jmlD67fH726huUlBsCafusWXIILcO+dWE32cWhQ+d01sH8P+yM9o6dNpDtiu
V6SaYINjZFBPSm5q+R5b8tY7Jlf2e+PKxtdIzkUjEJ+e8eM6BwC9JjRKp5WV
Hp5dlt5e4pf45vzIn9c5WGlg6BzleTC5QbFBTY5rmhwbzRBbjC5c92UvAL4f
Dwl4464mJcsQCL7/Fl87d0xpcVFs2waPSvjyh10alzxW0IR+gcd/IVz9BVRj
1MgQT0xe8OryGLfEpZ4ngOVjEEuT3JMf2GD0ftgcD6hRlixTIEr4Bb4Pinsa
SGgGNqLlN47ydw/2GbrLcR/BuwTkGGZXYgmWz14SAi91EJGn39Hnug/AvIQP
6qxPeglaK73+NPXX13WxWyQTJjkRCYjREcmDEaj4qQbJVhEMI9o3vr1T2TTY
6pQ6Z88kMCr4F0xwK/cx0YZhoN3zmPWEjS69vi7Zy1np6PJNTaOCsgHruCtt
aXlgSqhRPmOV9jsd+fBur2YUwvHpEN4hH1tEQWwEL6YZ8ZcsokvZU2ukNJuU
zceStaAVUyMBLSfT1pHlYfeQVxwoAj9ZSzPYhASs9ErBZfg9jIl5Gu70jlSv
d3FwF4BlhmE7Sx3oZIR3j3oiS5v+fd/7QPQefDz2Hlt7mXV3dE+x/L4vyW+1
CcJ9C622JfqUQH822jIZHeXQPzwMcs8Lq8mGUWzDkMMrIU7O7mP2U4j9kuIO
yTBDUHQiGMnrpvxVqim5EDdwYQyyU74qa9QZzzO1T+f4lB1m0DH6RKJoia77
3Jix0Pbv1ErsOGwTRyh3rH1e7q5gBhvNd7fVQZXMrlDLeRqIISDTRP4O9khz
weIdFqDBUfgUiHRJxjrnKUz0ggzYYI1iQHwKNIctuzLrgOq2ukWwNjb+F/xI
SMX9PPwHOvIX3YU6674fXhgnomo2//hQbVx+4L1a0xj6R+mZL9GYgT7XNL7z
/i0/LDT+Q9P8/KHY2HtR+ABHHA4wG/bh68IPv+hWwMGO/rB+BHq94Td4UBdm
srUYsK/lo40HMFo66oH+elAjeIsa9kMLf5Ah0C/yEF9Lwz4A++BG/ht2PXx8
ZHr9Nzey3+A582TcILQ2MIDdrfv5myIgTVscziVWVqEsQ+zariFTjo8AsTsq
/SQyDawaWGnoXhW7n4ihWfMjr3if/fBSfWVZDMdBv36BnKHEuV78uLGBj/X8
KiVPF7l9QYDMQQclhNyhLgB72rr4FIjRqLrn0Y3TK+x5653EPsnrDkxuFoEO
CmwkB0m5vGZGRwC40Bp0xg7JAHnYRAMjcn5qmJAXHFAbG2AdqQxMcrso+Woh
80AbxzIqihuBvhBn4ZUkbUjiOekExjjKTNJdzByQ4LZQkEcP3/YHLTXgeIS4
1cifwpGEdWa42gQzfatRaIudkXnEU0aw0J6iiAko0MYbT27uJqkqjou31NEM
Rb7MlfxEtG1hrteYy+CGMP49CT2Q3GdfX5hJKGeq7sIAWL/jl+gJ9p2clMtk
urAeT9wPEqcj95fpLaD4g13gaTIHxYTcV15YKUfvuEi7iDFufODl/LGyOKTg
n15EyYrTrSY6BjMvWUOeu0CeRiThATQUu6n2c5mwP3zEzjT6GN22f6dZr5dg
Sv2p5tkjPKDy8/oTv69yIPy+lrcqVfOcJFzp8R2wfVDomiWhhXKLn1c63FCe
zDU/LFTW/fgN3UxEPPlzGXoPiHTt826xIcsoB4nt/49PQOI1dJBUUPUUTqxs
Kgs8X2g9tTBuOUtE8DfVr3yk1DF37r46Kr5fR0kPxa9qgWlaUVzQegbrvir0
/4xGfygpS2t6On1uX072uZ1rhN+l4S/m4MXIMAz2DaMkRCU+Il9gkk1AZQ/A
wM8A6xgzAhJEDnHMf3SJVWD/bLYEVKUD+AyPeSpBNE/CG8nNDQYej+YAL/bJ
DNgGi0IAhJujOQL2y8okrIQ+O4ThWX8vAIBSiEMU8J4mTGJY+p5oG8HmD474
tBT93lebbmanW4oCLVeYBoHMEtC5Yg4OPaVGKCJ+0PqCWSwzI3XQTs9ykJJ4
uhmDnvgQrfkbMvRbLL3rzTPskMwYgyXObVqH0D/Z1Ar+u2air2UBi5OrmUmX
Z9KxkVDCubFQqfsJZ6L3pcvaJcAlRpUFI4ITDCyT5PRiRg11xSkcKIjw/xGo
S9MVaDJ3WNJA3esoaiICr6IwQ5efmGiSjjC5CfUdpXPQeCV52RBoYLGCKEuY
XlKh1mx9wmpDWT8BzP/bG8xw5RXFdIqU5DwHU8J4scSkn+A24NDLurAKRcyz
ukSXcqaQTXshbJYyrRHVkoJc/QiTBG4w4VqUkIQIDuaLOiLPAu1h0vVQma1P
7d0cjofV/CWTS4vhA07eKeRD18wA264BhwKdA2NJjEwW3g9fGeuiaRJpfpS0
rEJCjJe+hqC4lC2kMtMZ0XEAmiNsuRQLYhDpeZHnhg09j4/PG+vjz6yNNiRY
bB0tuJzGuTn13zRKuPONA472+k92ESzfvdQi54pJw0Wt0biOaSNeey+Mto/J
JrGfoEVZRxaiev8Eg1N0m2xsvKMTGcRlsmw5X3Deyo2kUvQHzatkCTMQBRvT
1soGBYb6DWBm1Zxp0eD8IgMZ+lmgPbE2yc0xqrPjoP6URYdnrpRqBqJo5ABd
Z5yWIbxfoBG3VSVXa2Oj8oh1YAQepU+Q6cxgtXbJ1yN4t+wAolDijUcghs+R
6ZMVjmhyd/ZgJy6Qi0mEJs9F0rbIwDEOgs3hm79ucZcNsBRSLZsdnWHSdl2Y
Cb7tjzC79C16iIkzlLI3PPCMr4DNTdrrVyhlZN0NRrwpSAIYHqwgPiTZKGU2
Z3ZmshDX512GYExRGVlRoJdO10APkWaLEBs4+zD3XMxI1mthJnCugsktu8At
BimVULnUpM3h+fEWHweJxT26tk8GlNZlmSfNWF8nuZwi2dQfyL/Yabfbr4Cu
mt9tEa0VRKQlXCMjKeEtqlIu619EQNdms1wFWXGriAPYgGi3pJfbhN0Ad2aC
FDGO25qPnVd3s7/dxBv8FU/paDRofkd8CoOZTFAwL/fO3yqZ2Sh7zAN9MoHZ
2+N/B6+2O+1XCgu2iDYC5rkwosLOJ1UJeRI5SIxJLW4LcmKIl9m3vVEVKC8T
qiQlXwm55TGjx5+MxUiNSjbDSLqjZAyemhNhoD5lGSkWnMpa4auAHIq2gtqD
2QYppcAU/fOpLvqFqJ+zJjKlKy07q1HsvICr86O/Ym4iWf0owHMvfBIQUw0W
oBIsUsqoRbdFDqYCqpLi6PDzo5BiPbSAJo9r6SjjNb24JAR0e/LXRpFOMiYU
07SGTnYPix3Utem096vEVDhMGqi93Vfbe3uWoIptbXLW/i6N1mkfAF3JUChm
LUtCLiQsNpxZqZOvJ08yIYzfi1V5w8keWSf8qKD+wzePbwNUB1jbrSff2tX4
VFouwiN0PAcaMowJNLZgfoVHDHz8GwlKYata/oXse/w4esSHqTYkiYI7RuA2
He20uq3DCmls4SekTSJsFNopfNFp133i59XiHtFpRAlkbEYhJGF8F0QhTNVM
U07t0jT5Eyn8YdLNrQTM1PZguwTGbqvTqYcdbEqd5n7yjto8O9li+Ei9QOvE
drbnNE6/J+YvX5ATwdJcJDnVQqhHDEhOlLuon6ARSMYCG2dWoS2CRvPG3lMN
onvCRT/YwR7z2QT4DGgz94ElZT7k7mZBSvVX1smSkJDHZMSmOnkRYCGmS9pP
0JK92sRDcSfTiuJmeKVnCR0viqdWLjttUSi9P3iUPyNh0zY2G4ca1+2dIq3s
lda2xUx412z7huoVOADw7UcY8u6atnW896DLOZszb4Q6Fr2z81Es2hNNU85b
MPnuCnW27EkWftj5dXLwRF1jNCCYYCjDUMXjbLIOtpQS7H1GiIzhqs4f4kjl
oIvcrVvPVJgEYjxr0Mxu9X35s+r6FT9LNbGfAjvlL2t4zyeIsmfQ9E8RayjR
yDKN5Pzis8QbHgiOwu/lRNZT0m4SLS1rsONAh+ktbrxHpOHnEIaPLn4ZGsD9
PLlDo7L4ee+fUJgS5DtrAPlYYXrQ+YWE6b+WLCUj6fNIUo89ekQqKCns07JI
rSWXK3Gye/nWRUpb811lh8kCeN9n3ME+c7OdHZNLVO4MJXu3XeB9u4/K87WN
ayV1p6oxPy2p8TeJB3V7e6+2u7198xoZ+XQ5YSmIohyJgY+wBbdA+Ukyl1OG
BWfPWmH5aSLSrQMtJMfSSwIPUAC477XWqN+I3LOSyJN+yOUS6eCuwAhNf2uY
L1L+VHMd/+pHa+TuAnZmE798fMha2fscfm86+CiObz5aswdMrMtQDH5LHntH
MrDGZn0rvVaNfOj1RNa5SgEFwcjO5mS+0HEW2LPya6VWzQSAFZN+nz+pFODR
w0eF+WUFmFDOnKO8SZzrnaA2rApQAtyc9pnHDY3nHAOpnHHZ6x5sY90sikFy
2CZB3TXCz/wePbYA28/jCsZbfH7kog3Gl9hS3ykuPoHd7O3BwDnGg1GQVKYl
simg83DI7gBQTeHc737fbe/uHxa6gi0NGMCqlvQZB3I9IBEmoNElTeA7nGpn
j5ZxVgS/2m6n21JVpHvQGbc/85WKPoEIWy20an9ot3l1MG6hYWlB3l6hHoj5
5OITu1rVSVun79BWIzqaf4pLZz1T/4za72fwv6wzHD5aZ/z9OgKzzOvn1SuZ
Le2sczD9plf+y+iVFXlmRBh06URbiXB216kD6wXr7jpl4BnKpe1ijUaAafKk
iNRqtubjNdoA4Tiu12B212kDVo16fMiDdSrwINbp9UoN8DhUWIhRbkJbaGRi
svvVLjhqJN4h0kuNe6h4ahG27PB0C88cm3P2fqy2pcb3CSVl8mYTbZq5m16o
LIJ/4Y9ZkGG6563e2Di2z+k7E09HpgYcDemVNirljS61o0k1QWmDRFsIcr7h
PCgvKp4tF3Q0COHEc5gcpbGiwQYROUcVxjG7AnanhZNhk5GNJw7Y39nptmOL
BeaZ5ZqTbLfXNBF3WcpKlKgqgTkeBvMMcxH4PV+s3YTXqN3VwN2g6WGkn2fM
Z84p7ac0D6NcTSS1BxMCXH2Bkc0IcM++fEoAjuKVWfCox2TTuEoHfMzq0dZc
IeFTA6WPRkAddmriys/SNBp0wJhqN7w9AViPCxnmojbVqtY0z3UKtc2Qx4yF
4B4DvJq1GQcyHVj+paOvNYn4pWT1DXfYvyb4WmOs73GcyFiqhmpmUqjFZbuY
ygTP77Zj5JMQF3dKpOi6RU2YdXbCsKJZB2CQmPNixVI/bq+Vqgd98f2G+wJv
UaFcMEr2sLeeYFM5sf9Ejk4BaD5vJmVnMmMznfSbHUmBIDtBEjV0tra6kZ/q
80gCThFhz8nC+QWSboCvYfEV5adViIRzXJotVUlveYQOfgU5LpTI8Pqk31Bd
+ncX/qVhD+AXjEDJrTYYfxK8Z/QBh9nhl5YyjXrCze3fwbxDiohRQwqdP2kZ
1jPpEjq/cHTfckMvWcdszYDKYXFWM4jkzxLq92mNauIwuOuMPjFArMlX+Txz
bNwyHbM91J932q19z5ArVZJQmxdvRyVr7ue21Wom9POYay1H+5aMi/r0kj/0
bBlkoAe0i0wFIeq9Ii4rFlbRUyBeOIaWk7HXIiNJvflhPRB/tVp4H6Hp7lGT
8El7sBCsr+4Fw0j2cIN7mKtnCLxpV9Kc/cocxK6JYePmOZ3R32Fmg9kwgfky
y7kkE9WYkDNufr5Xbo7LixqwOR4DPU+X7M6uMowrerFcgJa+1uX6aTFzgvmj
s55+VYzw8Qgw88TPlvW0hh1+Iffb5+Cy7Firwt0Z3PzGaf+Fk5cq5GaySHe6
hgnusrrZ6R4UueheQfdy7e37YaFBoZsG2Cuw/kQElqXS11hdxHhSmCisTkyb
9AsEJus3JGZjPeYSr48dHnYwcLjOW/glwnD/8btmU228OT0+HlwoLiI4fkl1
R2EZTkbN3QbHxS5H5GUETojpOgM+B2YCyKmAQW9MUGOgNmkYP0C9JWVRZ2EK
26Wn6IYY3IZkaRgeDCvVbP7x2SHCXygY+JMDQJ9dxH0mscN0sreO+n4TPL8J
nn+yiEx9eIOYbLeeHdZHcdbnFZGw29slrwKy0kc4aY/bscVl3EuGr/aQX1oP
hu8fK/HQnd0NZo5GTu4XxCQPIR6kojvI2h0/Q3bOpgdvbTKLVEVh7w47qQTI
WLvzh49l2VDHa0XlM/JkpIM1YbWfKGtFgNeG234TZz+rOPvNivpNmP1TCTOR
S2tC9c9KFSCetjaVdU20Xz6qlYcYCsLqTi4AhH99+bAPjvJUmPXwqcDpI84s
s23xGRWzsvmtWKgkuVcdoOhoOcfc3mZnVyRqFDW/12mS4W3NWFlCClIBXyTG
RpWi6AoPzPWjCsQcXQtqyilCu2S6vKUG5mYAaW1X2gK1eXKk3lKB/xJwneY+
7vtbPKaMo2AceH3dp+IP96G+ooYdfravDui/MOVO7+kSNvizc9DdVa74kF9+
x6/DY35Uq6VqHlNdnc6DUjRT9aCOANnt7OPKSq0D42P62EhVtzrox1W3Suo+
+Lgu7tUOfEA0ZKngI7v46tOhUGr307tQVTL4OMJwRZL8TWPKJA0KG46Kn5vK
SD9JnyF28BMSJBpUcB2Zy9Hp6DnO5zpO4VQ0zM4lToC11p95pOgeuIypvMSs
DXu+Wkmeq4nm5I+xGqk+WwSurpygNzGctPH/Z14A4NedtIEz+4iUjc6eO1ng
3V7yWBoFzWhQqBN5RtXhaQ1ZC5eL4/hOAS7Z5FLCbWU/hBdkBnblCvvV7aLC
zlGKiqfiD9ZIpAuCsBjdsZ4vPxS28//Y8Hb1Jtbt38Za1FvlXf/HQkcbT7EC
er+tZEAulp19FNwIOuDCFJ7+FvXlAtzP6Izhhl4YgALUWNtLiniXoH5Gz00f
TEVXb4xY0yl1VkCvrUBewRSCye+eidlnwuj4JxKQX1y1hjiReYLWVyEYr/K7
WcjyPYUmUS2c450lVFvI8NHc3ZTBBaaI0nFXhubeP7MvacSai7MQIk7qESaY
J1gVPgu/11wC2vEPOZdkRx9+q8zdOwqLumgOZy7wuqrz8Tv/pjp4GKZcMi8r
1T2FuQ6/NWwt4NstLFCmJDjWTKIZRHTNhb1cErsuTcomvFQu3XHacc94t7zC
TyJZpOapKcUU4EVWeM76SoMRRVOrubJDbZ5hNWy/RhvXbsJbSfx7R+jOsFId
+s3R5VahLj7d0od2Dl1toOVqA+gTrwypjmHuSpBy9F3ioTjOpVokWKgPy4pJ
RfneHjE6wTUVxq/FNb2xCUECcOjuA9gcnR5XC6T9zk2hcMfZ46tkYvruVkC3
UHuySAA590q5q6uWeoWhqgKUAJHnFZgtQWhTcX+579DIgirAVOyfyx4mc0wa
wD1EvW32m/jfLe62toPT5nFrCiuVN0Odz5oZlke+btItrll60zQ9wlxgDKEp
RLJkQVzoe56FvYcWNuF9omJ4XiyFbK+CVW9azF9aZ1yK0vu7damnZbOuWEaJ
yNzexkg1hKd8l1+xCi6yE0Ix4gFHYVQIj/BBsJ0V6vEHIruLOg7MX87/BLw4
wljkSkRLaXInrngccIe82WLQvf5INcCLk4UPlGobIwq9MVpoq4/p+YfcdAy0
HNkP8C4K0eMiTJl210ZKa5NQYupgomME8DR+ddSxvTv/gdcrFhqC9okUcFjo
tEh71vNEpECbdsW52xO+UxAzud0+tMnjkuROl4iiKybTJB5mUXANShz+A/MZ
n703mRRlSrFLx9XzMKFmbsokCPh1K02TLffFp1p5JSLgWbCgHgZA+QIJ4R34
51gl3jcSmqm/EXPdvZEEdnIqWB0aWHoe8kXppQ2Oi/lrXwhaiVQzeb6w11DT
BnA3UZgTmd7NfIVbPF947EAuLYauWsff4fWE/At3eTH4btzsIzKpXJv/6nIw
PDsCLZ/fPsUzMobYDYtf2FpwgGLuu/sof8UL67gaJq4zXRmJ9OBxIfRaUrlS
YTQGYoTRbDu7Qa1cQmShuBvSgvG1eeS0wQqO5iY7Cd8UjKbTliJReGH4CjIu
4UlMZ7yg7FIf8ZWmXBnYg6wB35O8K0zrpdgTo3ZHRiEg33BqGtVuh85/UNCg
C3ShTmfA53hGYP7qWa5+97Vqb3GLnRbppyN01SITxVvchgGyQExeG6YJ8Gzr
VB3xhUlHsi+cy4pQ0MdQVFttYlX6WGMZ1gIzRFcm3X6sp1vep6QqJuQ8NHyP
hioATD00vK+ofbpc5Aap/tUjJPjDbIIl8pl/E5/G6e7idH+EX3r4C906wgsh
3wuDd4w8jL0u4Lu9FnxO6Gddx43rPt18twAG0CT1fMt0RCqvAAvSns37QJ2c
4nHjPF3x6lMKL90MGJpLNGFVPo4kcL09CAwAdLL2669JqqhNxwC2FJCCoRW6
Okv2EV2LyJxQujBuVSpqV5ZimaUmcz0Bp+zNJf9RvEC8vLRHeD1+VIMImMAP
ZlHMXTA4d+aj3lU09jIauUmpsCBffeWbjezRgb8FeNrlwm05AgfvzBEqCuxs
7pIfJ+O7eak9F5NBbX0WfsB4DlovrsB04aYmljLeS+5hLjdn44GpxF51UB5c
1Lay8cyzEAVR5E0FbvbQFO/2uV6GU/KQuDttdw5MKqzvqvjhh8m981G0a2zX
Ts2zbs2zHfi6A2921K7qgYKNzulD9RHPwDz+xP9tPLQV/e/h7OHyAeyXh5PL
12h7nw0uPLsd+Z0Ev+RgvLXTPwMM1nyf3Pu2u7+sxuNJCVXtFofFnfYSh1d0
YURqVcE2eTxd3fZcgniOCEAPWH+76uZR/82W05SHhhH5BXFpf/qakkBRUkrb
8HNFBwkl5VlJGYXQ8nsSZgXgyvacDSbJbmbaFNHMl1oTy88M/y32loo/wusW
LOfk/iXqaGcbG3+E9c3tSbdBFVq+ol1KOlgWz1o+7SYOpEokElC2zq/M+JrC
XhJtCkbjXHUSqF6Vz3Iclb+kdALQHcP4H+jMxpG8b+SKGBqJwtjBNatw7PYk
lfRSleZbBKZmoZj76g/AXEPcA5mhBqpOYF3GaL6zWwbv6EnFlMdyvsTcGajQ
3c3rJ8YzRmFywhMpqmgIaRLpIPVOIg5UIqdrC4BYZ3NlJDw+Jp0wCkbvEQes
TNocxZSudRSv1WxJt0UD1cgd8qyTlGgbo4UGLFxAyVIFZCcewKLRsbUC/KU0
9if1iSRt71dD3xxq/IYyYYeSUkRYoNGBreHop5QdBFsjkOsa1u0w34jyMBBE
98EqKwPNFytZG2QB5hDpLNOpO+XlfHiAVxuTmQcRiiw0hCQ+wPYVrWSD6mXj
abFrCjhjrXciZ2rOMyUxaxBJxdJlqUt8W1CvshI757l5t/4Zh5G9RmP4rfmI
dBMThoA546UIzFlylxxMmQ7mVI46dcTsrtgIC4vgLtlbRnoN9+u5q/VIgXBq
B50omfBF5cbC4IIuntPUxFWoighpD847zpy0rItwt6jQEFK86zZgPe70yl28
YO9MblV6qvPNCfwUxDEop2AVg84c3bM53a0CC3trbOm8pruatGEdndbe8y+8
ZmPZXCNFkRjjopYLt6gYDG2kVDf1BzyRiddeJeltqdQ9xZUIrNw74Y8OP5x/
nizkdgMa0t7p4A5CulsPBFdWR84aLMLMddxy9ewmXtW9BapbhtuCN1ij/kbZ
Tbxudqvhr4TnA2w85/bSTbzoFLrQ+aTVsHncRd8c4o/u6KvTPL2xyQT2tcg0
X/x/pEa+/7r7MHz4DtTFPt6J9HAuYbmxqlcjLz6/GvlYSGls771Z//O5Yai5
q5ZIeEQk7F3p+5lhcNcN5jYW5hgdatK/V+9fqvdggQJYRiLc8Z/1cr5LsmT4
Ug15y5mPjIhD99pn0A2+e2n0b8sHzEjfFTSi0hD13Re67vdfKuQdinwqpleg
1c+l15y/VOeUuGb6Pn8M4o/oeDh+aSOq6JLA/o9wY3EpMSv0I/SH5H4Og71o
ZrqKg3k44S/WyNY9J1k7UlRBgwbv3f+UuJsKWUulpFsHCHt0RZ5RyAI7cd+T
G1UCka5+gMc/GW/QoawJd2gDqQX9Yh5m4oGVI/G1qg55nDg2F2BRNsrVK6k+
GWgHcpS2/ErU8hqtABry9YqPfFbxWBTBqYUDp7bTRTgZIorFYfEDUzbOwFP+
2gDWluoDni4Eg2qTMFNxhZT7mawmETnL+DJQoqX2hxP4IVv2A1qz7Nk3HJXW
zbJXITFrcT6q5PkRVOt2Mb4hrLnjNCDQTBfEidpt9fpqIe48e2WWYIbv3bIU
4yfEGAidvdHp9tT5m+/9+qFsOVdvbfPhCK7Q37cGDtN3t9fGvpkuge28rEgD
VmgM0dP15j+F7CUJxzAISb858nXHUq2aQh6BuOLZV1cwJjj108zHsAw5hk0J
AMDSlotGIRggafi8++3Oz3zW4XR29nRi2vINMqqpzd2KwpkmlcznOFyWo05b
tWYyFsPiK6dEFTVOZjGkihNM8IKPrngwWyLOvPejN2/fnR3LXWFke9lwLHBb
+dVEvGwmBuPVLPJUR8GK69Cb/DN0I0xyc1susdE5xo0yvxRJAZAQj70ImOSz
fcXHGySTxrptPX/MLKRIFK0u8IKEjBQythN7H5chD9gVjCkrN+Zou6GJSXec
xTbEEOmg9AL5qalyZG5U43SWlUuRro4p0yikAD49G4pVF/IG5+izSxty6JJc
8KmEDnwHFaFOUXI8JsxNzZkgzIPh9sywqz6rFpoVGRgK5FYiBAoyLbLqHF2Y
pkjC04eghOgKkhGXeJlhGcmSD+OhpGjsx2SFXcM0XM1SQyzCHexxC8J7nxlc
X9aLSRF5hhHFJjuimuACCF9SiSLZEMyWUr8kjlflhiI47KqQ4CKZVS17VIgu
AytcmOfTJX2YyciSMMhR6CTjpEcbJM7vk5qFKPEdR4nEpvzbqdXm237nsNtw
FekamD7ZJdNvy15E7G6BY9XHWxPqhaxcb5HEdWbQGWfkv8GCF+sQScUwcAs+
B4s4Pl3SrKdWqFsj21nSSFUu++mgvb/PWUmD98OLJqFG3nQ7u1JS+4kbwPAO
M9f9rNBXQPe7geWfWaHuMnMyWKBlDkpw8wq4Jia78mI37xb3WZMnibMUJwXV
CgTI13ezAAppgjhoWgSRTW0iW+i3LRD/V17KcjE30KT9wEawV3jThOjOvlyh
qBMvrxe25uQqUwaoEEvPcr3IyME+FJkg6Vfr7i+3NTg8usL7G4GZ+HTreQKR
xqiE2nRa1ewQgZ7mSrKgpO1B72i5SRFEpyGZA2B8Vor7t/jw0sfEekHHtwlp
omYoxVzElMGzI0S44tm0ydvwGavtuToj7rcuzGg12Bpey9oRZTmhiDcdXj6v
Q5JqlERQk8Fd8a2L09A2Pdb1BESWZam/cq42ndc03KSQi1pKzxPENp5cYGf2
GdqSCZgiL3gUsXgEzLBa3O6G8zA6akQhSoipbv6Dq/RcLdGAc15So5OxwWGO
bJYS3rOcrNzlApXtNA3BWBAVSBQyYjPStdO/TKC/rIexAxPNCxBoU3fpqs2K
BbTaFBJUxChLho+UDY/fb4kupiuHDnDNZPillIJaY+MVFsSdsSDvN90kEGbm
ZGPBGQ46/hM9+ysrejFt/8UyRd4qumMBZOzVOGFT3bR3AABOzCpY2hAOT20o
AyIv92YjKnVdGs/GFDgFC6zqRBmpXi5gwHhBmwY+WzgKNVQkIT/jv/+vJVII
pXfN0WuDfdRHBXEZdOwEfuUMphhVdZTUAkXUhVqCx4wMgwljVzK9vWh/ODp6
gd7deuCCiG5pZje2d4a0zXy3Y6GWjszhO1oAVhrqL5Rmyy6kBA09tRKzcNKd
jVt7oJF89hyrLRwkxd1pIzPoqMDrmQ23SJZ5LVYbNjZKB3MoHxgW+SaJpnwz
ls0shp1hAHV2umQ/W0ZspC3SXOIOCEOfRvY+cjZV4sGkkVcDwl6ItxIctaFh
C4wkuHM+a2VsigXHVHadPTSYRM8ZKywmGowOUvdlwxkN1jLDeGoayfH2udn3
Bf5a2uTVw1BI+GHMUfdPRQFY4nkYYdIV7HRPy3BmhdVtDSevhdnXoEpduX3s
mXelIHhRwFRQT4eOQxunwvcxxlwiRzMSCbfXzzNzMLus2D9qd4QV4YmusPU6
zxWyJZwL0zCGkvle59ycwS3yZP9Yv74mZ8FELgegc2wrwFfRFKNNPLlJEmtt
PIlFCxR7JwqXTlt8caCyiDOC+iUqbfa8u3iqe+1/MxirSH0S1xgPRS8oXWeP
gthdgCDn8MgLydXB+WiB/ZPEMXrlzSwDjs2BbY1ZAd5plXnwIZwv596c8yTS
rAKADJeOUbiHKIkx89nG2s397Yb9sUASvJsVNGludKTHrrLMl/ZpQG56QTHn
WBZDgGSBov2HMq6iODUKF1CTQcCX0vc4Uvu6tX+wY8O0+MIWNT5+I62l0rE0
udw9PPTrHrsu94zr3kgKTCo1CUveyKbZ2/FFiQmLJs42zzr9mWS5VSU8d+J6
Ji3q1CfzKK+iO7f0BZQ7Q1qr0IipYO4UmXiuHcOY+VzV2v1GXslN407Ei15A
8QGLNcP8jOlWA/UikQ2+9bCJh0G3PLYUeN4o3g8zRAva2HoSSZ7OY3MICv0T
48BRLrfEPR0UlWVGXnMKDCjAC8VGx1vo4tcZymqZdOEDN2UfS50mT5SFHqgR
mT9jZhU4gujYx4PXHzlp9oUfN2EmHnziPzE+aE5znaBudu0xZrMqnOXR6f0b
JWNdZUm0zG2iFEX/OMEJ+koVQBsDk0jNDQpS1p8Kfbr6DC01NC4niW/M+B4W
ixmLENKkui2sslKBbJ+UjDAyxtHbUQ0OvriiY5T9Mnd0Cj8dDAieunJbluOn
XustG7mljqIsqfGsCMPIhKs8btADnXK2j+FD7pLWOtuOZspRBy99D9cDuLkv
GVXwfE0Gk+yo0rkruhoCcwjQj2KEhJXFPGxBdywNXdaOLz+ZMdOfrInQOs5B
JQA1jn1VQCJcd13wfk0ur2nAGDT+tKH3+bn9HBS+qmNmzUjOqpcMMxv0tsmP
NV+K+6BUFr1hPZKsihpfqHkv6hTHnVeJqIPs1DTOBuvTdJEHj/pMFpyrXIaW
DMPEahSoKkl6W4CZdbAwdvnlfsyHRrapRuZ71l2xWI8cEIu1lAOqxYZ/1T2C
TEcGM3E+stNxMGrim5d8Rh8LAeFZSmLf5KUbFRqMkM4w476m5bsjv+W7OLgL
gKxxT9tGAwx2iGzgkGIugQw8pOVEVc4JsrjVtkE6GPY3enN0dsaRtmUspzgY
vJaqdq1QOoAmHfDWBOFgmP2zOpaJw4KbiVVb0a4viURnBvmM36DRXXSQXHEa
LR+rAYMb76Cj5LOP7pynndkQ2/rBWupYhAxnCtj0DdRR2qYjLDyEdLQ0a8hX
B4UmdxOBHsgJq8GIIc4cesL4JgQmRB48w9Lk0Jx1+ZW6vg8yNoQRxDVj871z
xaEp8zqZTJYpMVu6xo8dB7AvyJus0zCZOtgKSbaVObRMeGu2flfJaTDY72wo
gZi7yZ3BVCwIwhwVelPYmzlnMroQd6Zjp4ULSoULNy+PT33BXMqrr3B145ol
EeAxKvJSrOWW6KkrRBj8o901xq1YED/+uLExrOfd7EkTX12ZfUNrUMfkFKC5
+4JWwXD8Df+TQP316OI13YMkPmD3d5GBU9jv8XiUE1B8n925haVWNEmBm2oe
J6ONd4Inlhq10sdGBStCSN9hPNerlPzDD0bZahpPnD28gaFLpkwEqsFqCHaN
bKwOIKA/jKDyHGzyBRomFL1hJgcNV/K1qJV0ql4OEpCnkDBlRKaXwPwJK6y+
6AqrvySMmT4y1Iy+lKxfW42I9tLKuNtog8wDvgpzecWKc4KbS75v+X1Nql6Y
4bdmL9UWr9jjYnZe6QoOytK4qXaOLY2nZIFkcIhcgv1NMjI2+6/AaJuh2Fbm
Ak/UwcVOKoLLKRDj/rA5w5MoU5DXnAJRU2ADI7rdQ47oCqFmmrTPO6J39nA0
CnYkx68fixQ4RDtWaRKS7pCfG9/NcAAAsc/Z1i4htKCajK4j9muj38jzteCf
VCmT6EV/CPBshAuF8xkm5KhPqXNyjfMKzIIkutMSdAzxvJY15fjWCthyWOsb
ca4/3ATLDBEUrRpS9/E4nM1wz4LUCOj+BMHs7j6eDkFEiFKCJy+nCWU02cP8
ktDGafheTtIA9MEpCVI5+YkPTdGQ3T06Gck1R5pezREseeIy80zckIa/gune
h9P8Rg7xuHPrwdTUtTQiRe7zBXGcUsrUBJcN8dOkJc3YU8g7jnLk8X0lWSQz
GRle6gfH/zNPvbVrZ/IrpbvSVnOkK6cjDvnkZaEQhiQ8WCtVxzckoDhFDi/H
caLODuRLR5HSS3TnRcwjUGCfEhcMydVvZDTg1SO7GZfUSFdEMA3Ot8HuWcUL
lvBNnBtmZoPLxinrbRqqPMUVYbD4FB+Lx7M6YjTkKdCfMGiaA9ArCbBbdLDc
3yTChOm4BWoegOZk5h0bsuoK8cJkicfI+TZgsMPp+LfRMEQQSYqK4/kAeizS
xuUycMkdxDHtaBOQDLPEpe74GhAdHUlyk/5XYaHilvdpoFQz01TM3N056LCf
1B1qNvWCeoddOkTjf3lgjjtz8Rv2mJqXhy1zuour2AhJIZfPbohDLrOJhlUW
5ZSyJb3whz1605QbGWhpvHAOxnTvgYvrQvjLuotmXLcniIh2HicjEgaMOOBH
yaKQ0hohzAbTcw3WwTR7HmOkW77jKTkfKLXYqzJSzQ4xqZyVULeJrbgodQNI
8xZo4zZO7uPmIiKH0Yfc4ohyvTDtO5zgMdCNjXM/ldXLcnVJVpQUCyNtoyQe
F0vE+Kd6KAWOYgva5JyEUajFFueUWS/NijZXMjdX1GF+vI4BE81kZtQztXmc
jLYM7HhHN6IMA8c3Cew7mzhgM+oTE91gCCY3huMEvEXt3UW35hTakqqTz5YR
Kg1HrFsvqDy4tEPpBSs+KaZRMJ+Q+HnDxuT5WCAFQnTB2xGFmIlTU7H4vyHb
LYZ1QDvk7BAQzyEGDQru3CR1nkLmJUaB8rcxaAuRO1xApa7aPcvM1XWSYLSK
cv8nyNL7tYFtT6gMYaHJ6+XpLpxQBSYvxn3el5I6cHnvllGsbZ4Ipn1gIAQ9
ysGUt6sg+Q6WkbwuT05jf+cAdanshpgq8mog91hSqidkZrLMPD26OKrIS0x3
dfk2F7gx5KTLmI50FAvN2VAWOvqx2Asb9V5hOeGhtRWUgrhQgwIdI/GqWkPJ
GKC02YJCAIUPpFsHsZe4y7Mjox14BckqnH+GPmE2ia3MsML4xRG9hqanaDbg
0Xl7wo6PgWUvoL9rvG2ZLp6EIZrUgjj0A+ZZhegXfVB/1itiPw+uhweerM1H
NHh9UJeGzNQDdEJVPB7Uq9Nxc3D+Dn9z6zGwKagP6q/w/6Iq+cAX82IdIlsl
yC8Stm7pcltdqPitrdzzODa9Gm/CZWTRX6wB5QXaOE2LSNJzoHGxxl0V09hb
E3oTZL8nUnsANH6AfyujVPDa6R3AMzwYcjjgD6jyShWJ2PTQND3xmpbKI9V+
udeWL4/a5S8L1ZNq1g625NEEpRJo72y+ZqyQocBFZ8k97egovJVgbhDfqqMI
jA9C4HusNXWTA9NuqL8GwW1yp0b81yANgYHAbnuvweaHBydBmAGZHgPHbKjX
IZ5weaNT1BjPlpMA2VUUqP4NqJoB19HNbmCnqNfLOViHxurFrHRNQQN3/pWs
FNDMQn3foPMpHIRGOba8FtuQPMcjqVXOk1glS5gRnX6DDhNQ2TFykwd4VB1D
NaBIxtM0UH8GAFL4M4wDTja7Dm1qokESkjFg53QwPnGlUpCZJPT8mvIMyc9H
zuVc32P2y6t0FUi8jcVesgQpcqMXIFyo4RiAPQeufxM21J8SrL8RRKCzA8r6
N3QTLKD3zRJMpTmgdJwAHzsL8Zf5fAVSYBmtPKwxgip4MWdWqFAVpjhQRitM
HGZ0DvoPf/CaKi3Rck41rGg09RfEzti3vqSS0cb/A73VRVft5gAA [rfced] We had the following questions related to abbreviations
     used throughout the document:

a) FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correct use.

b) We cut abbreviations from the list in Section 3.1 that were not
used in the document after that list.  Please let us know any
objections.

c) We see multiple expansions for the same abbreviation in the list
below.  Please let us know the correct expansion:

VC - Virtual Container and Virtual Circuit
PMD - Physical Medium Dependent and Physical Media Dependent

d) We have made some slight updates to the list of abbreviations in
Section 3.1 in order to more closely match their cited references or
to more closely match the expansions used in RFCs generally.  Please
review carefully and let us know if any further updates are necessary.

e) Please let us know how you would like to expand the abbreviation
"OOF".  Should it be "Out of Frame"?

f) We will cut repeat expansions from abbreviations after first use
(to match the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev) for the
following unless we hear objection:

TDM
LF
ACH
CBR
LSP
NOS
PDV
PLR
PMD
PTP
RTCP
SRTP
SD
SID
CSID
TTS
NSP
FEC
PCS
LPI
PLOS
DEG

-->

<!-- [rfced] FYI - We updated artwork to sourcecode with the type
     "pseudocode" in Section 5.1.1.  Please confirm that this is
     correct.

In addition, please consider whether the "type" attribute of any
sourcecode element should be set and/or has been set correctly.

The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->

<!-- [rfced] Please review whether any of the notes in this document
     should be in the <aside> element. It is defined as "a container
     for content that is semantically less important or tangential to
     the content that surrounds it"
     (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->

<!-- [rfced] Some author comments are present in the XML. Please
     confirm that no updates related to these comments are
     outstanding. Note that the comments will be deleted prior to
     publication.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

For example, please consider whether the following should be updated:

native
-->

</rfc>