<?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.1 (Ruby 3.0.2) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schmutzer-pals-ple-signaling-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <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-00"/>
    <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="2023" month="October" day="23"/>
    <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>
    </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">0-80</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>
    </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+VaW1PjOBZ+96/QwAuZwUkI4dKpvaUhPU0tlyxJLzU7NdWl
2EpQ4VheS4HOAPvb9zuS7MQhgd7q3qcJ5cKWpaNz+c5FksMwDCIVy3TSYTMz
Do+DwEiTiA47P+2z3hcjUi1VqplRbDDLMpUb1s/lPTeCnctUsN50lnCDLmyn
f96rBXw0ysX9i+FjlTO8D2IVpXwK8nHOxybU0e10Zn4XeZjxRIdZIkItJylP
wFDYbAYR5pmofN5h2sSBzPIOM/lMm1az+a7ZCgJteBp/5olKQXIudJDJDvvV
qGiXabCai7HG3XzqbiI1nYrU6N+CgM/Mrco7AWMhLsZkqjvspM4GBUO21bF6
cptLbSRPV96qHEo7kTqCaubaiCmmOEujun2ZK1KiiKVRrve2BjvCdPyE25E0
88WDikXxEKlZakjkLgTNJXc9slsro+siplwmHRZ59f0tIibqEC8IZApVT2GR
e0HSXX84abfbh50gSFebj9stNAdhGDI+wkw8MkEwvJWawUgzUhSLxRg21kwU
hiQYmFvB+lrMYvUg82UA9OKJCI0K6T/QcNPbr0EYyKISluUKVsHN4+MPjqej
52eWi3/PQCO28CC6WphZxtT4VYyxrJxdw3Dson8+YKkwDyq/03Un0VTGcSIg
3jZMAg7iWWQJAC7sQhkijscgcOwctI6JnVuuGU9yweM505mI5FiCN1FxAuLy
nI9Ewk4lmWc0s3T7hXw7AH7tpTzoCg5muQj5JFVAU8SGpxcVSRYzQqbHx7+S
mg7295+fd5dHP3Do/I1hB83jQ4hDsg6uLnvDxuD0I4CaRzNplpSp7gWckkd3
wrCdk17/hWI9EwDK8zP0usEmy4OIuRWGfjgLT+tSILYULg5irIqzMW40hhPA
SL+IHRZ60li1kyBLVngFNee9CjuG3yGQsIqRidjj40A4POy1aFwpJSMEQN08
NzQwUzI1dYuiazepjR/sUhmPnyGmvxNzBuzFmm1dfBoMt3bdf3Z5Ze+ve//4
dHbdO6X7wcfu+Xl5U/QYfLz6dH66uFuMPLm6uOhdnrrBaGUrTRfdX/CPRNq6
6g/Pri6751ukdlNRL1kF0B0JvDIiz3JhoD2IGgsdAcLOVO9P+nttr6vW3t47
aMM9HO8dtfHwcCtSN5dKk7l/hPrnjGeZ4DnR4EnCIp5JA1Pv0gz6Vj2k7Fbk
wqlxKPKpTFWiJnP73L9hH3on1pKDZSsuAowunNTHjFgJ7QMTg8szM88IOWNL
SuXwD8pmrAdz3fOExD9JuCZ07WAmXQuCH9H1LLbzUhMwcFxD488iFTkyz+9Q
h2fLv35Xc4b+OVfg8OzUKoGAd0bqHPMIAZHnyBV4cj5AYY+DQ6tYLTK8heMM
z/9JWQhKEm48prE0iWG8fJ0uOkCHPYkOOcmL/1pUxQe3QAQZGu60wT/6N5o9
gEjBABFgw/ene3Z2mDJXGbKO8WCxXGQlF3WnCVK8SGPrH5pZtPMJ0lvhwZ6u
hcBIYbIYloycNzvWqQtpqnRmB1D/UmM6S8HPd+LTyAgBzM42slIReScTuAHu
dBGTbDThZfYh76wXyeClZn1xUgXd9ja7QoC8l+LB8bBOHWCWGy9HIu65jWVv
BCXqnSB3FAGypPvZ0tWfDR9RkAyCp3XssicUYqOQ4PLEzkU6gXaf2Kn15MwK
/4SBmLSBkN6gJNPn80TxmL2fG0z/xJpfmm38o+vxcUSNcKvVQe+lCa8JBbb/
Ef4duv7SEJarI9hV5mxrOx+UxJVr9p17HjAhPOiJINei/uFx0/aVMXVjwWOH
ba9XCbOV6Z+3rgtVrzPm1nNgbbdZAY/bTmZn1cy/ozamvWKLIsCFmSKRLXKI
jUEIcYr8BbEQ2CUr2+LC+Z9Mo2QW09AxcJiqNAQtPktMOaFGoGFSe9yTv9bZ
2dhFbuIB/9RUGuNChXOrtTQqTK5JtqXDIAoiH8SUfAVzVWLpjBu1VahEFrHc
TmM1+NnRsLXBf/ALWJO9/O2taWutadun4Xt4tQ/wHABtR+yYvftf2oKfwm/8
A0hL5xpSXHyyrHkvww/Pm1VF778DD1aV5AXLSi6w/6ahCP+W9Q5rB4Hn3N7/
xdrdoHRJWOLaYUsVGWHKoIyMOYNPYOlkC0TX6BLP5pk7RLtrc4L1ItR+SQxY
psoWUQ642gb5CnCXkP/SZ8v4A3f1Icc5LJ5Cm02/1lmB3Ivu5Wl3eHX9Sxnq
Vypd5AdEVjA0w5JvJCczNdPwa5nGkpagVgZuDMd6iyqKyNfSNkO94U6lIBs8
yQn3x/Ql+q3qytr2e/nS0+tTfM0cS/5YMdU6j1y19ZIzHi054+F3dcZSIu+H
YzXLNzsiN5zlrroD2KWbbS+8G2W64oRlSn/cLrK48z//9Lr7LZZX9f3qAqtI
RliEaHIlWkawcs9n1Tdfca4XjFT9yr/94/rVAvelKb8a81/vE1U1r/hEOfFL
dzj4f+Smcr71Galc9XhmeQUwqJU+RyL7vAqc13Cz7rfnuu55CO3jauM6wHWI
6wjXMa53uNb2g3XC8Juu4Kl7Nnj6dNl7uh72n3rvLzwiruFx+T1c9Ndm5/C3
Ag0LmOC+q+dpZIt1h6Pla9PPvrNmxf1wnz319i3GvlWKEmPrLbMBa4QxiL/L
IP8ugwJ2GTTgEDG0K+aRLJasfhGJtP+7yJUt3xGIFBUqo7lFChatQmIVCIyV
2rOkjkJaijpcUU0xntH2HBUz9VXa/+pdX63SXqJLYZyinnMMon3mqw5tWcAa
NvXR1C7VaTaSlyhiXN0+rHRyi8wXBZHfyWND+EUqHpxHLZa/K2Mqe0iWsR+x
uttnIXvPtYxcqHb1XPGyTS/J4RDMJ0Sm0seB69stQVlqeS35uI21o0tOy81F
XlhdkWESniTqwco9pZ3zUncxlpD2bl3eWUfb96imHhn/obPOhijxNg9vUPgp
aDRW2wqbsDNUOYZ2nXO2c89zSfsFtZXOjcb3zHyllYtAtAYfSwmPtjuWcl4r
PG59c9pbJ71LfbmtVfM5nRxQWYVhhVaKica5mgIb8IbjZjGl3TVES7EvvHHd
o7xPThWcvd9jqYr9Bi/t3Q8MNzPNTtCIorIPrio7uBAx4tru9cEp1TTjRhJj
5cquOAPQjg4djtG+kv21DtnO2lE1FzU20KZAVBSMr5I/skchIRXWiA0hgsMY
y8HcbivW7AnRYtlKt5UlIiph7Yw05jKZuW13oWn3SmpXeyyKW+hrIIzx5jEr
u5xFKLThEZUwbfvQBnu6zDrGlYy32c5ZkogJoHQSYk1Qc/b4pIvSv39TGAbo
ceHS750ub5NCfXkuaT/B9fXylYe4djf3JSQ02zknvmvlHnZ/cMl2rl3bgkiw
o4VYv09Vq7OBnMqEUzZNbRhGGjFziq78Hvq06L2XnHS/tIu8EIp54sXq46De
rtP5TlBir+b32OAFkAHAnIrolqdST2kWMc0SNRfxrtvAXSxKeshOaQxlQM5M
YBhfmdht+oJE/2aXMlm53lreT7fpboXF/fpBsT5qtw/BYMeeTyyOVy+VWTrW
wLtzFcHE3YUFioM9uMUEQNE1FHo2V7IPtFn46hDhRwxznuopWqpDYMNwzCOr
g5s3J1jpvYE2ygCWKPThzhPtftKN212nE1waXtjfboJmwnkfT3ZheT4pbb+k
f/RbOR2r7OrweyVjC3OKk6A7EuZB0MLzJchzQbF2UXjYFTOBujzKTniKKu+j
ehCoR3Zph/dNOXbObj7UCD4icbFBY+ErE+ExjIq5Qp0iK5fpivB8WWK7mKHj
Nq8MPlL3HmJUSfmDRFtXFUeYwNwsJ4dCnNEy9pQRoVdOY+3udgrc3XKQ5Omc
8TiWjgsmEVIjU5zz6IKkPYDSngt7KIKWka0TEa9C3EGjiyORmxfn1ov84A9q
upfdFUap0OMpf7YQKrYdivjrT9r8tkOTZvFnz4tvTEbAI9Xt9CUGn4b32YP2
n5uQm9NBu51VuiNmYY9oCD2aOjmftyW4S8n2zGzdfqLNrKSdLftlwpIzUy2g
t0B9Qt8OzJ2k3eguVQ+JiCfudDkIXIaB0gWqZvz+9EMYsr9fdy8uT69uLoHy
D73r3uVJbxAEdzmfxlR5ii8c0YvybS7GIhdphPtbYzLdaTQmAMtsRB+INCKY
qFGMCvNx1Dpsvfvqjo1RokaNKYdq8kYxZcN9y2PDeYSaPUSn6C788qU+vYsD
xgriUynu6mnSaDX3DkEjj24bzYPGFHd3IZYGhn8JCww2UNw46swe/XToMOzj
cNhHnXmiun27RG01m1R3tup04mRrMkrl4RQxl8zpUpx/IqNW1kOVroS5Yr6F
+mwoviw+m1m8qJ6Rey2g69ni05tKZ/qIYu9d62CpcxCGfwn+C04y/FF8JQAA

-->

</rfc>
