<?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.8 (Ruby 3.0.2) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schmutzer-pals-ple-signaling-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <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-01"/>
    <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="April" day="18"/>
    <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?>

<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>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>
            <tr>
              <td align="left">Endpoint-ID</td>
              <td align="left">TBD2</td>
              <td align="left">2-82</td>
              <td align="left">
                <xref target="id"/></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 anchor="id">
        <name>Endpoint-ID</name>
        <t>The Endpoint-ID sub-TLV MAY be included to allow for misconnection detection. The format of the Endpoint-ID sub-TLV format is shown in <xref target="id_format"/>.</t>
        <figure anchor="id_format">
          <name>Endpoint-ID 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    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
//                Endpoint Identifier (variable)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : TBD2</t>
        <t>Length : 2-82</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>Endpoint Identifier :</t>
        <ul empty="true">
          <li>
            <t>Arbitrary string of variable length from 0 to 80 octets used to describe the attachment circuit to the remote PE node.</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>
      <t>IANA is further requested to assign a sub-TLV type (value TBD2) for the Endpoint-ID sub-TLV from the "Pseudowire Interface Parameters Sub-TLV type" 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>
      <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="21" month="October" year="2023"/>
            <abstract>
              <t>   This document describes a method for encapsulating high-speed bit-
   streams as virtual private wire services (VPWS) over packet switched
   networks (PSN) providing complete signal transport transparency.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pals-ple-01"/>
        </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="23" month="October" year="2023"/>
            <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-00"/>
        </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+VaXXPbOpJ956/AjV/sGVIfFCVLqrmz69hK4lp/aC1lvDNT
UymIhGyWKVJDQHZ0be9v39MASZES5WQ2maerlGIKbDQa3acb3QAcx7H8JAjj
uyFbqbnTtywVqkgM2cXZmI2+KhHLMIklUwmbrJbLJFVsnIaPXAl2EcaCjRar
iCuQsMPxxejI4rNZKh53us+TlOG9FSR+zBdgH6R8rhzp3y9W6jeROkseSWcZ
CUeGdzGPIJDTals+xrlL0vWQSRVY4TIdMpWupHJbrUHLtSypeBx84VESg+Va
SGsZDtnfVeLbTELUVMwlntYL8+Ani4WIlfyHZfGVuk/SocWYgy9jYSyH7LTB
JrlAutWIenqfhlKFPN56m6RQ2mkofahmLZVYYIjz2G/ol2lCShRBqBJDfSAh
jlDDbMADP1TrzY8kEPkPP1nFiqZ8gommITcUy3s9R0MiFjyMhszP1PefPgnR
wPQsK4yh6gUs8ihodjcfTj3P6w0tK95u7nsumi3HcRifYSTuK8ua3oeSwUgr
UhQLxBw2lkzkhiQYqHvBxlKsguQpTMsAGAV3wlGJQ3+BhttR5wiTwVySiC3T
BFbBw/PzL0am49dXlop/rsAj0PAgvlKo1ZIl8zcxxpbF6BKGY5fjiwmLhXpK
0gfZMDNahEEQCUzvACaBBMHK1wwAF3aZKGKOn5ZlxOm6fRLnnkvGo1TwYM3k
UvjhPIRsouIEJOUFn4mInYVkntlK8x3n8zsE8I925wNSSLBKhcPv4gRo8tn0
7LIyk82ImNPz83+QmrqdzuurXe79xKHzb3Trtvo9TIfmOrm+Gk2bk7NPAGrq
r0JVUmbyKOCU3H8Qih2ejsY7is2EAFBeX6HXPTYpdyLhtgT65dw5a4QCsSV3
cTBjVZzN8SDRnQBG+kXs0NALlVY7TaRkhTdQczGqiKP4AwIJqxiZmD0/T4TB
Q9ulfsUsGSEA6uapoo7LJIxVQ6Poxgyq4we7SlSGnymGfxBrBuwFkr27/DyZ
vrPNX3Z1rZ9vRv/9+fxmdEbPk08nFxfFQ04x+XT9+eJs87TpeXp9eTm6OjOd
0cq2mi5P/oo/NKV31+Pp+fXVycU7UruqqJesAujOBF4pkS5ToaA9TDUQ0geE
janen47bXqYrt90eQBvmR7997OHH072IzVhJHK2zn1D/mvHlUvCUePAoYj5f
hgqmtmkEeZ88xexepMKocSrSRRgnUXK3xkqjZeJBIAL9ciLSx9AXbLpeIpRr
3c6TKIIxYQtpLCZZBL/TAy0TKcNZRPY3/RT1g0jcTFma9Qqzm601NEh2wguC
Efqi3aw1tNiwhfDveRzKBUWQgwM2AmGKoFIVij0fiOzFFz3aq2W9VEjYCxvf
Fk8XoyYca+tnkzz/faiclLzpBQzarVbrPZfC+R9QTd+ftfGn9bWD/9u2223Z
eJ3RfXx/Mhk5NztkLbvTdu1uRud299C5Xft40LY7GZ23j59XHbe7j67btru9
zbiYx14BO3Ybo+cc3b2UrplHQentpfQMv4zyecg2tskQ8UVxwofOaH59V2/S
dzDhn35BGoRJjvQS4LGI06qHwABZ+oNWz+2yj7OmZEsETD/iiFWs3ek02g2P
iM5Ho1G/5TY6Fs3K8OhveLg90lENh/Zgl4NXcGj3/p8sHOfPGsEfQmRiSF54
HGO12obx3P+pAP744XQXuq0SNNwaCrcCCa+GwqvAsF9D0a+ABQ5SI0jL7rb7
9nE3o+nV0Xh2qyRLp1bcvt0qSdOrE7h7bPfL8rh1MrcBK9dQGdzCGLWIfcOE
OWyZBTneM4T78cmlh6gc+vf0y2WzUBmwIP+dJVEDUThGbxeAbiHc3fEZXwXs
V+Z+1U2/do8h+eVsKVklMpvlBJF4RQnIUEeXTIP1i/uO2jrtfLbQSY7O6+nV
DiYTFf9MUF6ffW6VhfFMPPU8u91r5RTtbQrX9gYAy3E3p3B3eGAunWPbPe4U
JKKGpjMY2F23YNPZJvEoZg9st93PSbxdLh7itWd7XjeLcKSiWqjs6JMAAj1v
EsBtbctER8rg/qfq/LTTnEwv2zuQ73ahjEzrp22XiLxtop7r2q1+TuT1Nafe
btTw+n27s2E20Nx6O+wG9qDbsd2C4XFPcwR8tyk7A7vfpgUqX0g2uvkXVxJk
MVDah9GpTk4n5cR0UzPJvO7IyqAgETKrtRiqmCyPoW5glaRI+alAZyNkoI88
oozuNOKSEuZDjCSPLOsPID0P9LjURHHnCI0fRSxSFNO/wY0zsbLXgyOTX31M
E0h4flbkRueUIc455jTmKcpf/DJpPVVyHBLqgCDFkmubTy/+QoU1kihh+mMY
zZMExsu3+YIA2dYoJHXSfPFXiur0IS2SXIpGK7kv5R/fSvYEJrkAxMAYmEZH
dop8D4W0yvJfLcWykKJhNEGKF3GgU37JdALP71Cx50VJxldntbMEgwWwZJaS
GtGJhDRV1CcmimYvJYbTHLLxTrPKGGHajDbTsyL2Zk6QBqm0zMssXSDxoqCm
gqOR17e7ms32W6qgo7D7SIgVT0aGOnVs8udUROKR6/LsG3UWUVNantd8Bd8v
mq803vOqQ0yNuPDAyWrmEFxe2IWI76DdF3ami5Olnjw5cDnmjPk6SnjA3q8V
hic3bumQqhelGTXSOmTtBqobHaiI/pgCjqEPFWG52oNdL41tNXG3YJ6Y5ox4
lAHGgQfpmEKLhev0XU0bBno11BGlXiV5QLnJVV1nTBNXDt5QwPOBmbOx6jJ7
R20ogoxi830NE2by2nxTFusYhDU8IX9BeQfs5iVT5n9h7EcrnRDMgcM4iR3w
4qtIFQNKBBrKPQzuyV8b7HxuilGSAX+SRaiUCRXGrWp5VISsSzFyh0EURIkb
0H4C1Yq0w1U4415t5SoJ8/JUD6M1+MXw0Nsd/4uPxVps99OuaXNr2jrUvY1X
HYCnC7Qdoy4Y/Ctt1h+dH/wHkBbOlS3e9Mm8DB/83q8qev8TZNCqJC8oKznH
/jcNRfjXog+ZZ1mZ5Pr5z9ruKlE8YpFphy0TXwlVBGWsmCv4RJKaPS/TaBae
/SMPifeJXhO0F81DEQWAZZzofSEDXKmDfAW4JeTv+mwRf+CuWcgxDjvLM6jv
dVYg9/Lk6uxken3z1yLUb23eYX1AZIVAq5gvZuHdKllJ+HUYByHtqus5cKW4
f6/3iPxse1CvUN9wp2IiezzJTO736Uv0qc2Of5Yvvbw9xPeMUfLHiqnqPHLb
1iVnPC45Y++nOmMxo8wP58kq3e+IXHGWmuwOYA/NaG3nAaVsxQmLJR2VZraK
G//Lfr3tfpsd40anumecL0ZLeB65Eu2MsuIYa9s333CuHUGqfpW9/f361Qb3
hSm/G/Pf7xNVNW/5RDHwrjt0/x1rUzFe/YpUVD2ZsLwCGORKX3yx/LINnLdw
U/dpG9J2BqEOvh6+XXx7+B7j28d3gG8tHazjOD/0tV5Ozicvn69GLzfT8cvo
/WWGiBtB9Tlc9O+tYe8fORo2MMHziVzHvk7WDY7K330f/U6bFc/TDnsZdTTG
fnQWBcbqLbMHa4QxTN9mmL/NoACbQQMGEVNdMeutvnIRiWX/N5EmOn1HIEpS
cwhCSEHRKkJUgcBYoT3N6tihUtTginIKs+FHyUxjm/ffRjfX27xLfCmMU9Qz
jkG8z7OsQ2oRUMPGWTTVpTqNRvMljujX0D+2iEyRuZMQZYeTbAq/iMWT8ahN
+bvVp3IspgX7g94Bcth7LkPfhGqTz+UvPXpJDodgfkdsKjQGXD9uCX3iVKol
nw9QO5rFqdycrwvbFRkG4XROpue9oMsAhe4ClJD6qW7dqeOdUVSXnjD4Xa86
e6LEt2X4Boc/Ws3mdltuE3aOLEfRQXrKDh95GtJ+wdEWcbP5M1e+wsrFPucu
PkoLHm13lNY82vb44WWvbvZm6Ut1rpqu6TIEpVXolmslH2ieJgtgA97Qb+VD
6l1DtORH3XvrniTzyUUCZx+PWJwE2Zk1XUeYKK5Wkp2iEUnlGFJVdnAxRZ9L
vdcHp0wWS670yXRR2eXXGqThQ/d9aF9Jf9weO6ztdWSixh7eFIjyhPFN9sf6
dodDiTVig4PgMEc5mOptxSN91rgpW+mxUiIiE5bGSHMeRitzk0BI2r0Kpck9
Nskt9DURSmXmUVu7nHko1OERmTBt+9CdgbgsOvoVgnvs8DyKxB2gdOqgJjgy
9vgs89R/fJsbBugx4TLbOy1vk0J9aRrSfoKhzeZX3EvTu7m7kJDs8ILkPir2
sMeTK3Z4Y9o2TKxDKUT9PtVRg03CRRhxWk1jHYaxjKg1RVf+CH1q9D6GnHRf
2kXeTIplzPPqo9vwGnRlxSqwd5TtscELMAcAs7jJQKOIxTJK1iKwzQbupigZ
YXWKAyhDHxKiG98a2Gz60rnirU0rWVFvlffT9XK3JWKn0c3rI8/rQcChPp/Y
3Bi7SlTpWAPvLhIfJj7ZWCC/qwS3uANQ5BESPb1Wsg+0WfhmF5H1mKY8lgu0
VLvAhs6c+1oHt98cYIt6D2+kASxKQMONJ+r9pFuzu06X0qh7bn+9CboUxvt4
ZMPy/K6wfUn/oNu68FPZ1eGPSRhomFOcBN+ZUE+CCs9dkKdicw+mqJgJ1MXt
PLpp0GCfkieBfMSmHd5vzuPw/PbDEcFHRCY2SDp8jkSGYWTMFe4UWXkYb02e
l2esixm62JMpg8+SxwxilElld6N0XpXfygLmVik5FOKMDIOMMyL01gUzvbsd
A3f3HCx5vKaz7dBIwUKEVF/l5zwyZ6kPoGQmhT4UQctM54mIVw6e6AZRcSRy
u3MVb7M+ZAc1J1cnW4JSosdj/qohlG875PE3O2nLth1aNEp24r65NjsDHilv
p8ulfOE8Lp+ks7nVRHcH9aihuTUn9BENoUcSkfF5nYIfmjWZDs2OancU9dpK
+nmnr1uW3NmcfYL/HV2IXDeYZeVjzlepPtqrHzvPOLcEcDfXJ2vz00KQkgy1
Z2CTEv+SfNoWJ/5DnDxFIrgzV/q2L6Nllyv+6+bk8urs+vYKfvhhdDO6Oh1N
LOsBQwSUG4uvHPGVMoJUzEVK9yukda/UUg6bzTvAeTWjW7lNHyBq5r2cdO67
PXfw3YTNWZTMmgsOBabNfMimuUCtFxwfVYUDIv/B+fq1sXgILMZy5otQPDTi
qOm22j3wSP37ZqvbXODpwUHxovhXJ/eSJtIvw53pw6khHdd9mk7HyIRPk5Nx
fnGLMmO30cqvJFCy4SywKhDgzCKc/SIIVCq2Cil5RT7eRn16sbjK7ypvXlQv
JmZaAOn55r5zhZhurrYHbrdErO+e/B/tSKUK8S4AAA==

-->

</rfc>
