<?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.19 (Ruby 3.0.2) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schmutzer-pals-ple-signaling-02" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->
  <front>
    <title abbrev="LDP Extensions for PLE">LDP Extensions to Support Private Line Emulation (PLE)</title>
    <seriesInfo name="Internet-Draft" value="draft-schmutzer-pals-ple-signaling-02"/>
    <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>Austria</country>
        </postal>
        <email>cschmutz@cisco.com</email>
      </address>
    </author>
    <date year="2024" month="October" day="20"/>
    <abstract>
      <?line 33?>

<t>This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol <xref target="RFC4447"/> required for the setup of Private Line Emulation (PLE) pseudowires in MPLS networks.</t>
    </abstract>
  </front>
  <middle>
    <?line 37?>

<!--
TODO
fragmentation indicationin LDP?
https://datatracker.ietf.org/doc/html/rfc4623#section-4

-->

<section anchor="introduction-and-motivation">
      <name>Introduction and Motivation</name>
      <t><xref target="RFC5287"/> has already specified extensions to the Label Distribution Protocol (LDP) for the setup of structure-agnostic TDM pseudowires specified in <xref target="RFC4533"/>, structure-aware pseudowires specified in <xref target="RFC5086"/> and SONET/SDH Circuit Emulation over Packet (CEP) pseudowires in <xref target="RFC4842"/>.</t>
      <t>Private Line Emulation pseudowires are specified in <xref target="I-D.ietf-pals-ple"/>. This document focuses on the LDP definitions and extensions required for the setup of PLE pseudowires taking <xref target="RFC5287"/> and <xref section="12" sectionFormat="of" target="RFC4842"/> as a starting point.</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", and "OPTIONAL" in this document are to be interpreted as described in BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>to be added</t>
    </section>
    <section anchor="service-types">
      <name>Service Types</name>
      <t>The following sections list all possible service types that are supported by PLE and the proposed signalling mechanisms.</t>
      <section anchor="ethernet_types">
        <name>Ethernet Service Types</name>
        <table anchor="ethernet_service_table">
          <name>Ethernet Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1000Base-X</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">1,250,000</td>
            </tr>
            <tr>
              <td align="left">10GBASE-R</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">10,312,500</td>
            </tr>
            <tr>
              <td align="left">25GBASE-R</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">25,791,300</td>
            </tr>
            <tr>
              <td align="left">40GBASE-R</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">41,250,000</td>
            </tr>
            <tr>
              <td align="left">50GBASE-R</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">51,562,500</td>
            </tr>
            <tr>
              <td align="left">100GBASE-R</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">103,125,000</td>
            </tr>
            <tr>
              <td align="left">200GBASE-R</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">212,500,000</td>
            </tr>
            <tr>
              <td align="left">400GBASE-R</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">425,000,000</td>
            </tr>
          </tbody>
        </table>
        <!--
50GE has 4 lanes of 12,890625 Gb/s per clause 133.1.4 of IEEE802.3
200GE has 8 lanes of 26,5625 Gb/s per clause 119.1.4 of IEEE802.3
400GE has 16 lanes of 26,5625 Gb/s per clause 119.1.4 of IEEE802.3
-->

</section>
      <section anchor="fc_types">
        <name>Fibre Channel Service Types</name>
        <table anchor="fc_service_table">
          <name>Fibre Channel Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">1,062,500</td>
            </tr>
            <tr>
              <td align="left">2GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">2,125,000</td>
            </tr>
            <tr>
              <td align="left">4GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">4,250,000</td>
            </tr>
            <tr>
              <td align="left">8GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">8,500,000</td>
            </tr>
            <tr>
              <td align="left">10GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">10,518,750</td>
            </tr>
            <tr>
              <td align="left">16GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">14,025,000</td>
            </tr>
            <tr>
              <td align="left">32GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">28,050,000</td>
            </tr>
            <tr>
              <td align="left">64GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">57,800,000</td>
            </tr>
            <tr>
              <td align="left">128GFC</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">112,200,000</td>
            </tr>
          </tbody>
        </table>
        <!-- 
64GB is PAM4 which is 2 bits per symbol. hence 28900 megabaud = 2x28900=57800Mbps 

to be added in the future:
| 256GFC | {{I-D.ietf-pals-ple}} | TBD1 | 0x3 | 231,200,000 |
-->

</section>
      <section anchor="otn_types">
        <name>OTN Service Types</name>
        <table anchor="otn_service_table">
          <name>OTN Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ODU0</td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">1,244,160</td>
            </tr>
            <tr>
              <td align="left">ODU1</td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">2,498,775</td>
            </tr>
            <tr>
              <td align="left">ODU2</td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">10,037,273</td>
            </tr>
            <tr>
              <td align="left">ODU2e</td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">10,399,525</td>
            </tr>
            <tr>
              <td align="left">ODU3</td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">40,319,218</td>
            </tr>
            <tr>
              <td align="left">ODU4</td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">104,794,445</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="sonet_sdh_types">
        <name>SONET/SDH Service Types</name>
        <table anchor="sonet_sdh_service_table">
          <name>Ethernet Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">OC3/STM1</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">155,520</td>
            </tr>
            <tr>
              <td align="left">OC12/STM4</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">622,080</td>
            </tr>
            <tr>
              <td align="left">OC48/STM16</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">2,488,320</td>
            </tr>
            <tr>
              <td align="left">OC192/STM64</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">9,953,280</td>
            </tr>
            <tr>
              <td align="left">OC768/STM256</td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">39,813,120</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="pw-fec-for-setup-of-ple-pseudowires">
      <name>PW FEC for Setup of PLE Pseudowires</name>
      <t><xref target="RFC4447"/> does define two types of PW Forwarding Equivalent Classes (FECs)</t>
      <ul spacing="normal">
        <li>
          <t>PWId FEC (FEC 128)</t>
        </li>
        <li>
          <t>Generalized PW FEC (FEC 129)</t>
        </li>
      </ul>
      <t>The Group ID and the Interface Parameters are contained in separate TLVs, called the PW Grouping TLV and the Interface Parameters TLV.</t>
      <t>Either of these types of PW FEC MAY be used for the setup of PLE PWs with the PW type TBD1 and appropriate interface parameters.</t>
      <t>Using the generalized PW FEC allows for uniquely identifying both PW endpoints and misconnection detection.</t>
      <!--
do I need AGI and AI types?
https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-6
https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-8

should I be more specific about how to map between OTN TTI?
-->

<t>The two endpoints MUST agree on the PW type, as both directions of the PW are required to be of the same type.</t>
      <t>The Control bit MUST be set as PLE PW encapsulation uses a control word.</t>
    </section>
    <section anchor="interface-parameters-for-ple-pseudowires">
      <name>Interface Parameters for PLE Pseudowires</name>
      <section anchor="overview">
        <name>Overview</name>
        <t>The interface parameters that are relevant for the setup of PLE pseudowires are listed in <xref target="interface_params_table"/></t>
        <table anchor="interface_params_table">
          <name>Relevant Interface Parameters</name>
          <thead>
            <tr>
              <th align="left">Interface Parameter</th>
              <th align="left">Sub-TLV</th>
              <th align="left">Length</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">PLE/CEP/TDM Payload Bytes</td>
              <td align="left">0x04</td>
              <td align="left">4</td>
              <td align="left">
                <xref target="bytes"/></td>
            </tr>
            <tr>
              <td align="left">PLE/CEP/TDM Bit-Rate</td>
              <td align="left">0x07</td>
              <td align="left">6</td>
              <td align="left">
                <xref target="bitrate"/></td>
            </tr>
            <tr>
              <td align="left">PLE/CEP Options</td>
              <td align="left">0x05</td>
              <td align="left">4</td>
              <td align="left">
                <xref target="options"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="bytes">
        <name>PLE/CEP/TDM Payload Bytes</name>
        <t>The payload byte sub-TLV already defined in <xref target="RFC5287"/> does also apply to PLE and MAY be included if a non-default payload size is to be used. If this TLV is omitted then the default payload size defined in <xref target="I-D.ietf-pals-ple"/> MUST be assumed. The format of the PLE/CEP/TDM Payload Bytes sub-TLV is shown in <xref target="bytes_format"/>.</t>
        <figure anchor="bytes_format">
          <name>PLE/CEP/TDM Payload Bytes sub-TLV</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sub-TLV Type |     Length    |  PLE/CEP/TDM Payload Bytes    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 4</t>
        <t>Length : 4</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>PLE/CEP/TDM Payload Bytes :</t>
        <ul empty="true">
          <li>
            <t>A two byte field denoting the desired payload size to be used.</t>
          </li>
        </ul>
      </section>
      <section anchor="bitrate">
        <name>PLE/CEP/TDM Bit-Rate</name>
        <t>The bit-rate sub-TLV already defined in <xref target="RFC5287"/> is MANDATORY for PLE pseudowires in order to unambiguously indicate the attachment circuit type. The format of the PLE/CEP/TDM Bit-Rate sub-TLV is shown in <xref target="bitrate_format"/>.</t>
        <figure anchor="bitrate_format">
          <name>PLE/CEP/TDM Bit-Rate sub-TLV</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sub-TLV Type |     Length    |      PLE/CEP/TDM Bit-rate     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     PLE/CEP/TDM Bit-rate      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 7</t>
        <t>Length : 6</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>PLE/CEP/TDM Bit-rate :</t>
        <ul empty="true">
          <li>
            <t>A four byte field denoting the data rate in units of 1-kbps</t>
          </li>
        </ul>
      </section>
      <section anchor="options">
        <name>PLE/CEP Options</name>
        <t>The options sub-TLV already defined in <xref section="12.3" sectionFormat="of" target="RFC4842"/> MUST be present when signaling PLE pseudowires. The format of the PLE/CEP options sub-TLV is shown in <xref target="options_format"/>.</t>
        <figure anchor="options_format">
          <name>PLE/CEP Options sub-TLV</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sub-TLV Type |     Length    |         PLE/CEP Options       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 5</t>
        <t>Length : 4</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>PLE/CEP Options :</t>
        <ul empty="true">
          <li>
            <t>A two byte field with the format as shown in <xref target="ple_cep_options_format"/></t>
          </li>
        </ul>
        <figure anchor="ple_cep_options_format">
          <name>PLE/CEP Options</name>
          <artwork><![CDATA[
 0                                       1
 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|AIS|UNE|RTP|EBM|      Reserved [0:6]       |  PLE/CEP  | Async |
|   |   |   |   |                           |    Type   |T3 |E3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
        </figure>
        <t>AIS, UNE, RTP, EBM :</t>
        <ul empty="true">
          <li>
            <t>These bits MUST be set to zero and ignored by the receiver.</t>
          </li>
        </ul>
        <t>Reserved :</t>
        <ul empty="true">
          <li>
            <t>7-bit field for future use. MUST be set to ZERO and ignored by receiver.</t>
          </li>
        </ul>
        <t>CEP/PLE Type :</t>
        <ul empty="true">
          <li>
            <t>Indicates the connection type for CEP and PLE. CEP connection types are defined in <xref target="RFC4842"/>. Two new values for PLE are defined in this document:</t>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <ul spacing="normal">
              <li>
                <t>0x3 - Basic PLE payload</t>
              </li>
            </ul>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <ul spacing="normal">
              <li>
                <t>0x4 - Byte aligned PLE payload</t>
              </li>
            </ul>
          </li>
        </ul>
        <t>Async :</t>
        <ul empty="true">
          <li>
            <t>These bits MUST be set to zero and ignored by the receiver.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="ldp-status-codes">
      <name>LDP Status Codes</name>
      <t>Per <xref target="RFC4447"/> in case of incompatible bit-rate the LDP status code 0x00000026 (incompatible bit-rate) and in case of incompatible PLE options the LDP status code 0x00000027 (CEP-TDM mis-configuration) has to be used to indicate the reason of failure to establish the pseudowire.</t>
      <t>Setting of the Control bit to zero MUST result in an LDP status of 0x00000024 (Illegal C-Bit).</t>
    </section>
    <section anchor="using-the-pw-status-tlv">
      <name>Using the PW Status TLV</name>
      <t>The PLE PW control word carries status indications for both attachment circuits (L bit) and the PSN (R bit) indication
(see <xref target="I-D.ietf-pals-ple"/>). Similar functionality is available via use of the PW Status TLV (see <xref section="5.4.2" sectionFormat="of" target="RFC4447"/>). If the latter mechanism is employed, the signaling PE sends its peer a PW Status TLV for this PW, setting the appropriate bits (see <xref section="3.5" sectionFormat="of" target="RFC4446"/>):</t>
      <ul spacing="normal">
        <li>
          <t>Pseudowire Not Forwarding</t>
        </li>
        <li>
          <t>Local Attachment Circuit (ingress) Receive Fault</t>
        </li>
        <li>
          <t>Local Attachment Circuit (egress) Transmit Fault</t>
        </li>
        <li>
          <t>Local PSN-facing PW (ingress) Receive Fault</t>
        </li>
        <li>
          <t>Local PSN-facing PW (egress) Transmit Fault</t>
        </li>
      </ul>
      <t>As long as the TDM PW interworking function is operational, usage of the Status TLV is NOT RECOMMENDED in order to avoid contention between status indications reported by the data and control plane. However, if the TDM PW interworking function (IWF) itself fails while the PWE3 control plane remains operational, a Status TLV with all of the above bits set SHOULD be sent.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document does not have any additional impact on the security of PWs above that of basic LDP-based setup of PWs specified in <xref target="RFC4447"/>.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>As already indicated in section 10 of <xref target="I-D.schmutzer-bess-bitstream-vpws-signalling"/>, IANA is requested to assign a PW type (value TBD1) for PLE pseudowires from the "MPLS Pseudowire Types" registry.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>to be added</t>
      <!-- KRAMNDOWN REFERENCES

kramdown examples

references
https://github.com/cabo/kramdown-rfc2629
https://github.com/cabo/kramdown-rfc2629/blob/master/examples/draft-ietf-core-block-xx.mkd
  https://miek.nl/2016/march/05/mmark-syntax-document/

Example table:

| HTTP | CoAP |
| 200  | 2.05 |
{: #code-mapping}

The mapping is defined in {{code-mapping}}.

Example references:

* Normative reference {{RFC2119}} example
* Informative reference {{RFC1925}} example

-->

</section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <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="RFC4447">
          <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="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="N. El-Aawar" initials="N." surname="El-Aawar"/>
            <author fullname="T. Smith" initials="T." surname="Smith"/>
            <author fullname="G. Heron" initials="G." surname="Heron"/>
            <date month="April" year="2006"/>
            <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 (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4447"/>
          <seriesInfo name="DOI" value="10.17487/RFC4447"/>
        </reference>
        <reference anchor="RFC5287">
          <front>
            <title>Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks</title>
            <author fullname="A. Vainshtein" initials="A." surname="Vainshtein"/>
            <author fullname="Y(J). Stein" surname="Y(J). Stein"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5287"/>
          <seriesInfo name="DOI" value="10.17487/RFC5287"/>
        </reference>
        <reference anchor="I-D.ietf-pals-ple">
          <front>
            <title>Private Line Emulation over Packet Switched Networks</title>
            <author fullname="Steven Gringeri" initials="S." surname="Gringeri">
              <organization>Verizon</organization>
            </author>
            <author fullname="Jeremy Whittaker" initials="J." surname="Whittaker">
              <organization>Verizon</organization>
            </author>
            <author fullname="Nicolai Leymann" initials="N." surname="Leymann">
              <organization>Deutsche Telekom</organization>
            </author>
            <author fullname="Christian Schmutzer" initials="C." surname="Schmutzer">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Chris Brown" initials="C." surname="Brown">
              <organization>Ciena Corporation</organization>
            </author>
            <date day="18" month="October" year="2024"/>
            <abstract>
              <t>   This document describes methods and requirements for implementing the
   encapsulation of high-speed bit-streams into virtual private wire
   services (VPWS) over packet switched networks (PSN) providing
   complete signal transport transparency.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pals-ple-09"/>
        </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>
        <reference anchor="I-D.schmutzer-bess-bitstream-vpws-signalling">
          <front>
            <title>Ethernet VPN Signalling Extensions for Bit-stream VPWS</title>
            <author fullname="Steven Gringeri" initials="S." surname="Gringeri">
              <organization>Verizon</organization>
            </author>
            <author fullname="Jeremy Whittaker" initials="J." surname="Whittaker">
              <organization>Verizon</organization>
            </author>
            <author fullname="Christian Schmutzer" initials="C." surname="Schmutzer">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Bharath Vasudevan" initials="B." surname="Vasudevan">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Patrice Brissette" initials="P." surname="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>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-schmutzer-bess-bitstream-vpws-signalling-02"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC4446">
          <front>
            <title>IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)</title>
            <author fullname="L. Martini" initials="L." surname="Martini"/>
            <date month="April" year="2006"/>
            <abstract>
              <t>This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document. 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="116"/>
          <seriesInfo name="RFC" value="4446"/>
          <seriesInfo name="DOI" value="10.17487/RFC4446"/>
        </reference>
        <reference anchor="RFC4533">
          <front>
            <title>The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation</title>
            <author fullname="K. Zeilenga" initials="K." surname="Zeilenga"/>
            <author fullname="J.H. Choi" initials="J.H." surname="Choi"/>
            <date month="June" year="2006"/>
            <abstract>
              <t>This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4533"/>
          <seriesInfo name="DOI" value="10.17487/RFC4533"/>
        </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 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="RFC1925">
          <front>
            <title>The Twelve Networking Truths</title>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="April" year="1996"/>
            <abstract>
              <t>This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1925"/>
          <seriesInfo name="DOI" value="10.17487/RFC1925"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+VaWXPbyrF+x6+YY71ICcAFBCmSdU9OaIm2WdHCK9JXWSrl
GgJDCiUQQDBDyTyS8tvv1zNYuEl2cpyn0AULS09P79PdM47jWH4ShPGiz1Zq
7nQtS4UqEn12cT5mw69KxDJMYslUwiarNE0yxcZZ+MCVYBdhLNhwuYq4Agg7
Hl8MTyw+m2XiYW/4PMkYvltB4sd8CfRBxufKkf7dcqV+FZmT8kg6aSQcGS5i
HoEgp+FaPuZZJNm6z6QKrDDN+kxlK6ncRqOHz5ZUPA6+8CiJgXItpJWGffY3
lfg2kyA1E3OJu/XS3PjJciliJf9uWXyl7pKsbzHm4GIsjGWfndXYpCBIvzWk
nt1loVQhj3e+JhmEdhZKH6JZSyWWmGIU+zX9MUtIiCIIVWKgjyTIEaqfT3jk
h2pdPSSBKB78ZBUrYnkARrOQG4j0TvNoQMSSh1Gf+bn4/ugTETWwZ1lhDFEv
oZEHQdzdfDjzPK/Tt6x493XXc/HachyH8Rlm4r6yrOldKBmUtCJBsUDMoWPJ
RKFIMgN1J9hYilWQPIbZpgEMg4VwVOLQX1jD7bB1AmbASxKxNEugFdw8Pf1k
aDp9eWGZ+McKOAJtHoRXCrVKWTJ/08ZYWs4uoTh2Ob6YsFioxyS7lzXD0TIM
gkhY1v/8BAOfXp9fW/OML4gpgyiMg9DXt0AAW/3FulMqlf16PeAAgTDuRVYL
hZrXoOY6JFK/U8uons19r+O2jqTwabDj0XR/sKwjaB6MBiv9msEq2WWiiAc8
Wpbhuu12ies7LhmPMsGDNZOp8MN5CBGILV8jYVzwmYjYeUhWMFtpvONCjMeg
+WRfbAAFBatMOHwRJzBan03PL7cEVs0Izp+efiFttFutlxd7c/Qjh2q/Mazd
6HbADvE6ub4aTuuT80/wh8xfhWpDZ8mDgO+TQBU7PhuO9/SXEwF7fHmB+l5R
/eYgIm6HoJ9GzrnWVxlJgIxtm/McNxLDyY5JvghR2sJDpcVOjGxo4Q3jvBhu
kaP4PeIV21IyIXt6mhgzYU2XxpVcMrIAiJtnigamSRgrcA4rujGT6jDFrhKV
288U09+LNYOJB5K9u/w8mb6zzV92da3vb4b/+3l0Mzyn+8mnwcVFeVNATD5d
f744r+6qkWfXl5fDq3MzGG/ZzqvLwV/wh1h6dz2ejq6vBhfvSOxqS7ykFZju
TOCTElmaCQXpgdVASB8mbFT1/mzc9HJZuc1mD9IwD93mqYeHxzsRm7mSOFrn
jxD/mvE0FTwjHDyKmM/TUEHVNs0g75LHmN2JTBgxTkW2DOMkShZrLGiaJh4E
ItAfJyJ7CH3BpusUK4aW7TyJIigTusgdW7IIfqcnShMpw1lE+jfjFI0DSdyw
LM2yCO5ma20aRDvZC2IexuK9WdJoTWNL4d/xOJRLClRHR2wIwAyxa5so9nQk
8g9f9GwvlvW8BcKe2fi2vLsY1uFYO4918vz3oXIy8qZnIGg2Go33XArnz4Ca
vj9v4k/jawv/N2233bDxOYf7+H4wGTo3e2ANu9V07XYO57ZfgXPb9mmvabdy
OO81fN72vO3X4NpNu92p5gUfrxLYspuYvcDovgrpGj5KSO9VSM/gyyGf+qzS
TW4RXxQn+9CJ08/vDqv03Uu+GIHJoV4CPBZxWlwRGEBLt9fouG32cVaXLEXA
9COOWMWarVatWfMIaDQcDrsNt9ayiCuDo1vhcDskowMYmr19DF6Jodn5N1GY
Ze+IfQiR8CFH4nGM1WrXjOf+DzXgjx/O9k23sWEa7gEId8skvAMQ3pYZdg9A
dLeMBQ5ygJCG3W527dN2DtM5BOPZjQ1aWgfJ7dqNDWo6hwhun9rdTXrcQzQ3
YVaugTJ2C2UctNg3VFiYLbNAx3uGcD8eXHqIyqF/R08um4XKGAvS7FkS1RCF
Y4x2YdANhLsFn/FVwH5m7lf96uf2KSi/nKWSbUVms5wgEq8oAenr6JJL8PDi
vie2VrPgFjIprPN6erVnk4mKf6RRXp9/bmwS45l46nl2s9MoIJq7EK7t9WAs
p+0Cwt3DAV5ap7Z72ipBxAGYVq9nt90STWsXxKOY3bPdZrcA8faxeIjXnu15
7TzCkYgOmsqePMlAIOcqAdyVtkx0pAzufqjMz1r1yfSyuWfy7TaEkUv9rOkS
kLcL1HFdu9EtgLyuxtTZjxpet2u3KmQ9ja2zh65n99ot2y0RnnY0RpjvLmSr
Z3ebtEAVC0klm39xJUEWA6F9GJ7p5HSymZhWpZks6o682goSIfOSjqFYyvMY
GgZUSYaUn/oAbIgM9IFHlNGdRVxSwnyMmeSJZf0OoKNAz0uvKO6c4OVHEYsM
NfuvcOOcrPxz78TkVx+zBBSOzsvcaEQZ4pyDpzHPUGXjyaT1VDByUKgDghQp
1zqfXvwf1e9IooQZj2k0TiIYH9/GCwBkW8OQxEn84q8U2+yDWiS5FI1W8rWU
f3wr2SOQFAQQAqNgmh3ZKfI91Osqz381FWlJRQ3x7rMkemn4Yl9knFJQ0ylZ
xeE/VgLZbxhADeF8TcNmCaYGrIgDXTCYgmVJpT/itqkzAkyl72g2nW4ECRuh
OMY0g48jPWIwMqxXJe/j42Mt5DHXpS40jnRVFyD19FG0nIqF3efaV6qJj3be
Op3/FOKuZSHRX0UBWIKmlklVBvqMz5KVYqgDqAZZ8hQQ6lGIWC8B0+noF7Mm
kDWS8VdS1EUUX2RCFIVhrltdWWipB/CmvCww5kMgZK1ljWhWsvyjBMEaQ83M
d5Y3QbBUmtlm2rIIvbErUINyRhalri5Sedk7oaLPlDUHrTtvrW07Pi19DxQ1
xKOh4ZBJVjVMJiLxwHWJ/I1al6CpNCrq7hLvF41Xmgj2osP8AXIRBSermUMu
+8wuRLyAdJ/ZuS4QU808BdHNuD/m6yjhAXu/VpieQmlDL2s6MZjRS8oFrP3F
4kYvFgR/SkHfwIeK4sn2CHadGt1q4HaJPDGvNTBF68OsFsH6phDhISWZmH30
BmNPR4YXo600/0bvUGAagRU9IxPCi75H1XLQ8R35UUKxCMEDNlmUo3lsC2M/
Wulkaw77ipPYAS6+ilQ5oUREorzO2DPFwhobzU2hTzTgT7IMlTJh2LjLQRxb
RB5K3wpHQFhYLWkaU4dTk7J0slelVYgkLEp/PY2W4BeDQ7eS/omfxRps/9c8
8M498K5Fw5v41IJRtGFFp6i5ev/KO+v3zm/8B0stnSZPjOiXew9+eH5dVPT9
B9CgRUlesCnkwva/qSiyf016n3mWlVOu7/+g9a4SxSMWmffQZeIrocpgi2xk
BZ9IMtNPNC/Nov76zH3CPdCxXnvRPBRYOLCeJqpYhAMhdfDeMtwNy9/32TKu
wF3zUGIcdlZkp9/rrLDcy8HV+WB6ffOXMoTvNEYR9xExQdAq5stZuFglK0lJ
geldC80DV4r7d7r/5uetV73yfMOdSkZe8STD3H+nL9HvYOXxo3zp+e0pvmeO
DX/cUtUhj9zV9YYznm44Y+eHOmPJUe6H82SVve6IXHGWmcyZkl8zW9O5n6Vy
ywnLpRpVfL46G//Ln952v6obX2tt9+OLxSiF55ErUdeZlTuRu775hnPtEbLt
V/nX/16/quy+VOV32/z3+8S2mHd8opx43x3a/4m1qZzv8IpUVpQ5sXzLYJAr
ffFF+mXXcN6ym0O/pgFt5ibUwuXhauPq4DrF1cXVw3UQDtpxnN90Wc+D0eT5
89Xw+WY6fh6+v8wt4kZQ7wMu+rdGv/P3whoqM8H9QK5jX2fsxo42r9d++ptW
K+6nLfY8bGkb+61clDZ2WDOv2BrZGNi3Gfi3GQRgM0jAWMRUdyN0G3WzOMSy
/6vIEp2+IxAlmdlgIktBMSpCVHewsVJ6GtWpQyWmsSvKKUwzlZKZ2i7uvw5v
rndxb+ClME5RzzgG4R7lWYfUJGz0HHQbhGYjfgkjxtX0ww6QKR73EqJ845dN
4RexeDQeVZW1O2O2thw1Yb/T3TWHvecy9E2oNvlc8dGjj+RwCOYLQrMFY4zr
t2uC6nPaUZ4orlYSNX9AdfgYCdxWEw4s+FzqVgGqsWSZouSnKrJMIIudaWnw
0MkQKkv1z+2w44OjTgxxr+Amfot16U30p3qD3qH1exlKB/qbI+vMdFfiRG8X
Vdkx3W5lolhwpQmBcx5GK7MZLCQVyaE0Ia5aQyGwiVA6Achj5maTpJC41gIW
XKouads33iQd40rCPXY8iiKxQKA+c5B6nJh+SdVvG98WikFsNilD3nrZ7LJA
fFkWUtliYKtTIsYedTNoP+OW7PiC6D4p25DjyRU7vjHvKiTWsRTicDl8UmOT
cBlGnJw21j4Da1Vryh/4A+SpWw0PISfZbzShKqZYjrxIcto1r0anDqzS9k7y
Ul6wCDzAMMvNaJpFLNMoWYvANv2fKvcZwgniAMLQ+zwYxncmNj0j2hq6tclh
yrRusyWqvWqHxFatXaRhntcBgX3dYq7OFl0laqMzjW8XiQ8VDyoNFMdN4BYL
GIo8wXqiXZJ9oJ7Em0NEPmKa8Vgu8WZ7CHTozLmvZXD7zQl2oF/BjWjDogQw
3HiiLltvTXOOji/R8EL/uteSCuN9PLKheb4odb8hf8DtnNnYKh75QxIG2syp
lwy8RWP0gJFnojrKUCbmZNTlOS7aLK6xT8mjQNizqZH0TT6OR7cfTsh8RGRi
g6T9w0jkNoyFeQs7iFjyMN5hnm9yrHMmOpuRC4PPkofcxChg58dbdPguDtbA
5lYZORTijAyDHDMi9M4ZId1EQ2mCaAeUPF7T9mRoqGAhQqqvijaxLFDqPQSZ
U6F7qngz08sR4pWDOzoEUnZUb/dOU1XrQ97nHVwNdghFxUOd9BdtQkV1U8Tf
fLMkr24aNEu+aVodsJzBHik9oGOIfOk8pI/SqQ6m0PEvPWtoDj4J3eEl69Fd
e+PzeqU/Nhkv7XucHGxczLNkqeXzTh/M23Bns30F/As607amPQriduDfx8lj
JIKFOfe0e2In34H+083g8ur8+vYKlv5heDO8OhtOLOs+48uA0mXxlSOC0Zqb
ibnIaBNalhsRCxjMakYnJOs+1FQvRjnZ3Hc7bu+7AeuzKJnVlxziyerFlHVz
mFWHdB/pgQMg/975+rW2vA8sxgrky1Dc1+Ko7jaaHeDI/Lt6o11f4u7eQRai
+FensMO6ZQ0Ndqa7zH3qp3+aTsdIbM+Swbg43UKJrltrFPu2tJw7S8RdUqlZ
5vInUuxW6rUFSnZXzFeJT4fjq+LcaPVh+/RWLgWAjqqzp1vAdLyv2XPbG8B6
M+b/Af2TpPl9LAAA

-->

</rfc>
