<?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.6.24 (Ruby 3.0.2) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schmutzer-pals-ple-03" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="PLE">Private Line Emulation over Packet Switched Networks</title>
    <seriesInfo name="Internet-Draft" value="draft-schmutzer-pals-ple-03"/>
    <author initials="S." surname="Gringeri" fullname="Steven Gringeri">
      <organization>Verizon</organization>
      <address>
        <email>steven.gringeri@verizon.com</email>
      </address>
    </author>
    <author initials="J." surname="Whittaker" fullname="Jeremy Whittaker">
      <organization>Verizon</organization>
      <address>
        <email>jeremy.whittaker@verizon.com</email>
      </address>
    </author>
    <author initials="N." surname="Leymann" fullname="Nicolai Leymann">
      <organization>Deutsche Telekom</organization>
      <address>
        <email>N.Leymann@telekom.de</email>
      </address>
    </author>
    <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>cschmutz@cisco.com</email>
      </address>
    </author>
    <author initials="L." surname="Della Chiesa" fullname="Luca Della Chiesa">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>ldellach@cisco.com</email>
      </address>
    </author>
    <author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>naikumar@cisco.com</email>
      </address>
    </author>
    <author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>cpignata@cisco.com</email>
      </address>
    </author>
    <author initials="G." surname="Smallegange" fullname="Gerald Smallegange">
      <organization>Ciena Corporation</organization>
      <address>
        <email>gsmalleg@ciena.com</email>
      </address>
    </author>
    <author initials="C." surname="Brown" fullname="Chris Brown">
      <organization>Ciena Corporation</organization>
      <address>
        <email>cbrown@ciena.com</email>
      </address>
    </author>
    <author initials="F." surname="Dada" fullname="Faisal Dada">
      <organization>Xilinx</organization>
      <address>
        <email>faisald@xilinx.com</email>
      </address>
    </author>
    <date year="2023" month="March" day="02"/>
    <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>
  <middle>
    <section anchor="introduction-and-motivation">
      <name>Introduction and Motivation</name>
      <t>This document describes a method called Private Line Emulation (PLE) for encapsulating high-speed bit-streams as Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN). This emulation suits applications where signal transparency is required and data or framing structure interpretation of the PE would be counter productive.</t>
      <t>One example is two ethernet connected CEs and the need for synchronous ethernet operation between them without the intermediate PEs interfering or addressing concerns about ethernet control protocol transparency for carrier ethernet services, beyond the  behavior definitions of MEF specifications.</t>
      <t>Another example would be a Storage Area Networking (SAN) extension between two data centers. Operating at a bit-stream level allows for a connection between Fibre Channel switches without interfering with any of the Fibre Channel protocol mechanisms.</t>
      <t>Also SONET/SDH add/drop multiplexers or cross-connects can be interconnected without interfering with the multiplexing structures and networks mechanisms. This is a key distinction to CEP defined in <xref target="RFC4842"/> where demultiplexing and multiplexing is desired in order to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual Container (VC). Said in another way, PLE does provide an independent layer network underneath the SONET/SDH layer network, whereas CEP does operate at the same level and peer with the SONET/SDH layer network.</t>
      <t>The mechanisms described in this document follow principals similar to <xref target="RFC4553"/> but expanding the applicability beyond the narrow set of PDH interfaces (T1, E1, T3 and E3) and allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH <xref target="GR253"/>/<xref target="G.707"/> and OTN <xref target="G.709"/> at gigabit speeds by treating them as bit-stream payload defined in sections 3.3.3 and 3.3.4 of <xref target="RFC3985"/>.</t>
    </section>
    <section anchor="requirements-notation">
      <name>Requirements Notation</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 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-and-reference-model">
      <name>Terminology and Reference Model</name>
      <section anchor="terminology">
        <name>Terminology</name>
        <ul spacing="normal">
          <li>ACH - Associated Channel Header</li>
          <li>AIS - Alarm Indication Signal</li>
          <li>CBR - Constant Bit Rate</li>
          <li>CE - Customer Edge</li>
          <li>CSRC - Contributing SouRCe</li>
          <li>ES - Errored Second</li>
          <li>FEC - Forward Error Correction</li>
          <li>IWF - InterWorking Function</li>
          <li>LDP - Label Distribution Protocol</li>
          <li>LF - Local Fault</li>
          <li>MPLS - Multi Protocol Label Switching</li>
          <li>NSP - Native Service Processor</li>
          <li>ODUk - Optical Data Unit k</li>
          <li>OTN - Optical Transport Network</li>
          <li>OTUk - Optical Transport Unit k</li>
          <li>PCS - Physical Coding Sublayer</li>
          <li>PE - Provider Edge</li>
          <li>PLE - Private Line Emulation</li>
          <li>PLOS - Packet Loss Of Signal</li>
          <li>PSN - Packet Switched Network</li>
          <li>P2P - Point-to-Point</li>
          <li>QOS - Quality Of Service</li>
          <li>RSVP-TE - Resource Reservation Protocol Traffic Engineering</li>
          <li>RTCP - RTP Control Protocol</li>
          <li>RTP - Realtime Transport Protocol</li>
          <li>SAN - Storage Area Network</li>
          <li>SES - Severely Errored Seconds</li>
          <li>SDH - Synchronous Digital Hierarchy</li>
          <li>SPE - Synchronous Payload Envelope</li>
          <li>SRTP - Secure Realtime Transport Protocol</li>
          <li>SRv6 - Segment Routing over IPv6 Dataplane</li>
          <li>SSRC - Synchronization SouRCe</li>
          <li>SONET - Synchronous Optical Network</li>
          <li>TCP - Transmission Control Protocol</li>
          <li>UAS - Unavailable Seconds</li>
          <li>VPWS - Virtual Private Wire Service</li>
          <li>VC - Virtual Circuit</li>
          <li>VT - Virtual Tributary</li>
        </ul>
        <t>Similar to <xref target="RFC4553"/> and <xref target="RFC5086"/> the term Interworking Function (IWF) is used to describe the functional block that encapsulates bit streams into PLE packets and in the reverse direction decapsulates PLE packets and reconstructs bit streams.</t>
      </section>
      <section anchor="reference-models">
        <name>Reference Models</name>
        <t>The generic reference model defined in <xref section="4.1" sectionFormat="of" target="RFC4664"/> and <xref section="4.1" sectionFormat="of" target="RFC3985"/> does apply to PLE. Further the model defined in <xref section="4.2" sectionFormat="of" target="RFC3985"/> and in particular the concept of a Native Service Processing (NSP) function defined in <xref section="4.2.2" sectionFormat="of" target="RFC3985"/> does apply to PLE as well. The resulting reference model for PLE is illustrated in <xref target="ref_model"/></t>
        <figure anchor="ref_model">
          <name>PLE Reference Model</name>
          <artwork><![CDATA[
                |<--- p2p L2VPN service -->|
                |                          |
                |     |<-PSN tunnel->|     |
                v     v              v     v
            +---------+              +---------+
            |   PE1   |==============|   PE2   |
            +---+-----+              +-----+---+
+-----+     | N |     |              |     | N |     +-----+
| CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 |
+-----+  ^  | P |     |              |     | P |  ^  +-----+
         |  +---+-----+              +-----+---+  |
  CE1 physical  ^                          ^  CE2 physical
   interface    |                          |   interface 
                |<--- emulated service --->|
                |                          |
            attachment                 attachment
             circuit                    circuit
]]></artwork>
        </figure>
        <t>PLE embraces the minimum intervention principle outlined in <xref section="3.3.5" sectionFormat="of" target="RFC3985"/> whereas the data is flowing through the PLE encapsulation layer as received without modifications.</t>
        <t>For some service types the NSP function is responsible for performing operations on the native data received from the CE. Examples are terminating Forward Error Correction (FEC) or terminating the OTUk layer for OTN. After the NSP the IWF is generating the payload of the VPWS which is carried via a PSN tunnel.</t>
        <figure anchor="diff_clock">
          <name>Relative Network Scenario Timing</name>
          <artwork><![CDATA[
                    J
                    |                                         G
                    v                                         |
                    +-----+                 +-----+           v
   +-----+          |- - -|=================|- - -|          +-----+
   |     |<---------|.............................|<---------|     |
   | CE1 |          | PE1 |       VPWS      | PE2 |          | CE2 |
   |     |--------->|.............................|--------->|     |
   +-----+          |- - -|=================|- - -|          +-----+
        ^           +-----+<-------+------->+-----+
        |                          |              ^
        A                         +-+             |
                                  |I|             E
                                  +-+
]]></artwork>
        </figure>
        <t>To allow the clock of the transported signal to be carried across the PLE domain in a transparent way the network 
synchronization reference model and deployment scenario outlined in <xref section="4.3.2" sectionFormat="of" target="RFC4197"/> is applicable.</t>
        <t>As illustrated in <xref target="diff_clock"/>, the attachment circuit clock E is generated by PE2 via a differential clock recovery method in reference to a common clock I. For this to work the difference between clock I and clock A MUST be explicitly transferred between the PE1 and PE2 using the timestamp inside the RTP header.</t>
        <t>For the reverse direction PE1 does generate the clock J in reference to clock I and the clock difference between I and G.</t>
        <t>The way the common clock I is implemented is out of scope of this document. Well established concepts for achieving frequency synchronization in a PSN have already been defined in <xref target="G.8261"/> and can be applied here as well.</t>
      </section>
    </section>
    <section anchor="emulated-services">
      <name>Emulated Services</name>
      <t>This specification does describe the emulation of services from a wide range of technologies such as TDM, ethernet, fibre channel or OTN as bit stream or structured bit stream as defined in <xref section="3.3.3" sectionFormat="of" target="RFC3985"/> and <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
      <section anchor="generic-ple-service">
        <name>Generic PLE Service</name>
        <t>The generic PLE service is an example of the bit stream defined in <xref section="3.3.3" sectionFormat="of" target="RFC3985"/>.</t>
        <t>Under the assumption that the CE-bound IWF is not responsible for any service specific operation, a bit stream of any rate can be carried using the generic PLE payload.</t>
        <t>There is no NSP function present for this service.</t>
      </section>
      <section anchor="ethernet-services">
        <name>Ethernet services</name>
        <t>Ethernet services are special cases of the structured bit stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>IEEE has defined several layers for ethernet in <xref target="IEEE802.3"/>. Emulation is operating at the physical (PHY) layer, more precisely at the Physical Subcoding Layer (PCS).</t>
        <t>Over time many differnet ethernet interface types have been specified in <xref target="IEEE802.3"/> with a varying set of characteristcs such as optional vs mandatory FEC and single-lane vs multi-lane transmission.</t>
        <t>All ethernet services are leverging the basic PLE payload and interface specific mechanisms are confined to the respective service specific NSP functions.</t>
        <section anchor="gbase-r-and-25gbase-r">
          <name>10GBASE-R and 25GBASE-R</name>
          <t>The PCS layers of 10GBASE-R defined in clause 49 and 25GBASE-R defined in clause 107 of <xref target="IEEE802.3"/> are based on a 64B/66B code.</t>
          <t><xref target="IEEE802.3"/> clauses 74 and 108 do define a optional FEC layer, if present the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function must generate the FEC.</t>
          <t>The PSN-bound NSP function is also responsible to detect 10GBASE-R and 25GBASE-R specific attachment circuits faults such as LOS and sync loss.</t>
          <t>The PSN-bound IWF is mapping the scrambled 64B/66B code stream into the basic PLE payload.</t>
          <t>The CE-bound NSP function MUST perform</t>
          <ul spacing="normal">
            <li>PCS code sync</li>
            <li>descrambling</li>
          </ul>
          <t>in order to properly</t>
          <ul spacing="normal">
            <li>transform invalid 66B code blocks into proper error control characters /E/</li>
            <li>insert Local Fault (LF) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</li>
          </ul>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or if the farend PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>Before sending the bit stream to the CE, the CE-bound NSP function MUST also scramble the 64B/66B code stream.</t>
        </section>
        <section anchor="gbase-r-50gbase-r-and-100gbase-r">
          <name>40GBASE-R, 50GBASE-R and 100GBASE-R</name>
          <t>The PCS layers of 40GBASE-R and 100GBASE-R defined in clause 82 and of 50GBASE-R defined in clause 133 of <xref target="IEEE802.3"/> are based on a 64B/66B code transmitted over multiple lanes.</t>
          <t><xref target="IEEE802.3"/> clauses 74 and 91 do define a optional FEC layer, if present the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function must generate the FEC.</t>
          <t>To gain access to the scrambled 64B/66B code stream the PSN-bound NSP further MUST perform</t>
          <ul spacing="normal">
            <li>block synchronization</li>
            <li>PCS lane deskew</li>
            <li>PCS lane reordering</li>
          </ul>
          <t>The PSN-bound NSP function is also responsible to detect 40GBASE-R, 50GBASE-R and 100GBASE-R specific attachment circuits faults such as LOS and sync loss.</t>
          <t>The PSN-bound IWF is mapping the serialized, scrambled 64B/66B code stream including the alignment markers into the basic PLE payload.</t>
          <t>The CE-bound NSP function MUST perform</t>
          <ul spacing="normal">
            <li>PCS code sync</li>
            <li>alignment marker removal</li>
            <li>descrambling</li>
          </ul>
          <t>in order to properly</t>
          <ul spacing="normal">
            <li>transform invalid 66B code blocks into proper error control characters /E/</li>
            <li>insert Local Fault (LF) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</li>
          </ul>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or if the farend PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>When sending the bit stream to the CE, the CE-bound NSP function MUST also perform</t>
          <ul spacing="normal">
            <li>scrambling of the 64B/66B code</li>
            <li>block distribution</li>
            <li>alignment marker insertion</li>
          </ul>
        </section>
        <section anchor="gbase-r-and-400gbase-r">
          <name>200GBASE-R and 400GBASE-R</name>
          <t>The PCS layers of 200GBASE-R and 400GBASE-R defined in clause 119 of <xref target="IEEE802.3"/> are based on a 64B/66B code transcoded to 
a 256B/257B code to reduce the overhead and make room for a mandatory FEC.</t>
          <t>To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform</t>
          <ul spacing="normal">
            <li>alignment lock and deskew</li>
            <li>PCS Lane reordering and de-interleaving</li>
            <li>FEC decoding</li>
            <li>post-FEC interleaving</li>
            <li>alignment marker removal</li>
            <li>descrambling</li>
            <li>reverse transcoding from 256B/257B to 64B/66B</li>
          </ul>
          <t>Further the PSN-bound NSP MUST perform rate compensation and scrambling before the PSN-bound IWF is mapping the same into the basic PLE payload.</t>
          <t>Rate compensation is applied so that the rate of the 66B encoded bit stream carried by PLE is 528/544 times the nominal bitrate of the 200GBASE-R or 400GBASE-R at the PMA service interface. X number of 66 byte long rate compensation blocks are inserted every X*20479 number of 66B client blocks. For 200GBASE-R the value of X is 16 and for 400GBASE-R the value of X is 32. Rate compensation blocks are special 66B control characters of type 0x00 that can easily be searched for by the CE-bound IWF in order to remove them.</t>
          <t>The PSN-bound NSP function is also responsible to detect 200GBASE-R and 400GBASE-R specific attachment circuits faults such as LOS and sync loss.</t>
          <t>The CE-bound NSP function MUST perform</t>
          <ul spacing="normal">
            <li>PCS code sync</li>
            <li>descrambling</li>
            <li>rate compensation block removal</li>
          </ul>
          <t>in order to properly</t>
          <ul spacing="normal">
            <li>transform invalid 66B code blocks into proper error control characters /E/</li>
            <li>insert Local Fault (LF) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</li>
          </ul>
          <t>Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or if the farend PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>When sending the bit stream to the CE, the CE-bound NSP function MUST also perform</t>
          <ul spacing="normal">
            <li>transcoding from 64B/66B to 256B/257B</li>
            <li>scrambling</li>
            <li>aligment marker insertion</li>
            <li>pre-FEC distribution</li>
            <li>FEC encoding</li>
            <li>PCS Lane distribution</li>
          </ul>
        </section>
      </section>
      <section anchor="sonetsdh-services">
        <name>SONET/SDH Services</name>
        <t>SONET/SDH services are special cases of the structured bit stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>SDH interfaces are defined in <xref target="G.707"/> and SONET interfaces are defined in <xref target="GR253"/>.</t>
        <t>The PSN-bound NSP function does not modify the received data but is responsible to detect SONET/SDH interface specific attachment circuit faults such as LOS, LOF and OOF.</t>
        <t>Data received by the PSN-bound IWF is mapped into the basic PLE payload without any awareness of SONET/SDH frames.</t>
        <t>When the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set, the CE-bound NSP function is responsible for generating the</t>
        <ul spacing="normal">
          <li>MS-AIS maintenance signal defined in clause 6.2.4.1.1 of <xref target="G.707"/> for SDH services</li>
          <li>AIS-L maintenance signal defined in clause 6.2.1.2 of <xref target="GR253"/> for SONET services</li>
        </ul>
      </section>
      <section anchor="fibre-channel-services">
        <name>Fibre Channel Services</name>
        <t>Fibre channel services are special cases of the structured bit stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>The T11 technical committee of INCITS has defined several layers for fibre channel. Emulation is operating at the FC-1 layer.</t>
        <t>Over time many different fibre channel interface types have been specified in FC-PI-x and FC-FS-x standards with a varying set of characteristcs such as optional vs mandatory FEC and single-lane vs multi-lane transmission.</t>
        <t>All fibre channel services are leveraging the basic PLE payload and interface specific mechanisms are confined to the respective service specific NSP functions.</t>
        <section anchor="gfc-2gfc-4gfc-and-8gfc">
          <name>1GFC, 2GFC, 4GFC and 8GFC</name>
          <t>The PSN-bound NSP function is responsible to detect fibre channel specific attachment circuits faults such as LOS and sync loss.</t>
          <t>The PSN-bound IWF is mapping the received 8B/10B code stream as is into the basic PLE payload.</t>
          <t>The CE-bound NSP function MUST perform transmission word sync in order to properly</t>
          <ul spacing="normal">
            <li>replace invalid transmission words with the special character K30.7</li>
            <li>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</li>
          </ul>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets.</t>
          <t>FC-FS-2 amendment 1 does define the use of scrambling for 8GFC, in this case the CE-bound NSP MUST also perform descrambling before replacing invalid transmission words or inserting NOIS ordered sets. And before sending the bit stream to the, the CE-bound NSP function MUST scramble the 8B/10B code stream.</t>
        </section>
        <section anchor="gfc-and-32gfc">
          <name>16GFC and 32GFC</name>
          <t>FC-PI-5 amendment 1 defines a optional FEC layer for 16GFC. For 32GFC the FEC layer is, as defined in FC-PI-6, mandatory. If FEC is present, the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function must generate the FEC.</t>
          <t>The PSN-bound NSP function is responsible to detect fibre channel specific attachment circuits faults such as LOS and sync loss.</t>
          <t>The PSN-bound IWF is mapping the received 64B/66B code stream as is into the basic PLE payload.</t>
          <t>The CE-bound NSP function MUST perform</t>
          <ul spacing="normal">
            <li>transmission word sync</li>
            <li>descrambling</li>
          </ul>
          <t>in order to properly</t>
          <ul spacing="normal">
            <li>replace invalid transmission words with the error transmission word 1Eh</li>
            <li>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</li>
          </ul>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or if the farend PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>Before sending the bit stream to the CE, the CE-bound NSP function MUST also scramble the 64B/66B code stream.</t>
        </section>
        <section anchor="gfc-and-4-lane-128gfc">
          <name>64GFC and 4-lane 128GFC</name>
          <t>Both FC-PI-7 for 64GFC and FC-PI-6P for 4-lane 128GFC define a mandatory FEC layer. The PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function must generate the FEC.</t>
          <t>To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform</t>
          <ul spacing="normal">
            <li>alignment lock and deskew</li>
            <li>Lane reordering and de-interleaving</li>
            <li>FEC decoding</li>
            <li>post-FEC interleaving</li>
            <li>alignment marker removal</li>
            <li>descrambling</li>
            <li>reverse transcoding from 256B/257B to 64B/66B</li>
          </ul>
          <t>Further the PSN-bound NSP MUST perform scrambling before the PSN-bound IWF is mapping the same into the basic PLE payload.</t>
          <t>Note : the use of rate compensation is for further study.</t>
          <t>The PSN-bound NSP function is also responsible to detect fibre channel specific attachment circuits faults such as LOS and sync loss.</t>
          <t>The CE-bound NSP function MUST perform</t>
          <ul spacing="normal">
            <li>tranmission word sync</li>
            <li>descrambling</li>
          </ul>
          <t>in order to properly</t>
          <ul spacing="normal">
            <li>replace invalid transmission words with the error transmission word 1Eh</li>
            <li>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</li>
          </ul>
          <t>Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets, or if the farend PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC errors.</t>
          <t>When sending the bit stream to the CE, the CE-bound NSP function MUST also perform</t>
          <ul spacing="normal">
            <li>transcoding from 64B/66B to 256B/257B</li>
            <li>scrambling</li>
            <li>aligment marker insertion</li>
            <li>pre-FEC distribution</li>
            <li>FEC encoding</li>
            <li>Lane distribution</li>
          </ul>
        </section>
      </section>
      <section anchor="oduk-otn-services">
        <name>ODUk OTN Services</name>
        <t>ODUk services are special cases of the structured bit stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
        <t>OTN interfaces are defined in <xref target="G.709"/>.</t>
        <t>The PSN-bound NSP function MUST terminate the FEC and present to the IWF an extended ODUk including a valid frame alignment overhead. Further OTN interface specific attachment circuit faults such as LOS are to</t>
        <t>The PSN-bound NSP function is also responsible to detect OTUk specific attachment circuits faults such as LOS, LOF, LOM, AIS and DEG.</t>
        <t>For ODUk services the PSN-bound IWF MUST use the byte aligned PLE payload.</t>
        <t>The CE-bound NSP function will recover the ODUk by searching for the frame alignment overhead and generate the FEC.</t>
        <t>When the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set, the CE-bound NSP function is responsible for generating the ODUk-AIS maintenance signal defined in clause 16.5.1 of <xref target="G.709"/>.</t>
      </section>
    </section>
    <section anchor="ple-encapsulation-layer">
      <name>PLE Encapsulation Layer</name>
      <t>The basic packet format used by PLE is shown in the <xref target="encap"/>.</t>
      <figure anchor="encap">
        <name>PLE Encapsulation Layer</name>
        <artwork><![CDATA[
+-------------------------------+  -+
|     PSN and VPWS Demux        |    \
|          (MPLS/SRv6)          |     > PSN and VPWS
|                               |    /  Demux Headers
+-------------------------------+  -+
|        PLE Control Word       |    \
+-------------------------------+     > PLE Header
|           RTP Header          |    /
+-------------------------------+ --+
|          Bit Stream           |    \
|           Payload             |     > Payload
|                               |    /
+-------------------------------+ --+
]]></artwork>
      </figure>
      <section anchor="psn-and-vpws-demultiplexing-headers">
        <name>PSN and VPWS Demultiplexing Headers</name>
        <t>This document does not imply any specific technology to be used for implementing the VPWS demultiplexing and PSN layers.</t>
        <t>When a MPLS PSN layer is used. A VPWS label provides the demultiplexing mechanism as described in <xref section="5.4.2" sectionFormat="of" target="RFC3985"/>. The PSN tunnel can be a simple best path Label Switched Path (LSP) established using LDP <xref target="RFC5036"/> or Segment Routing <xref target="RFC8402"/> or a traffic engineered LSP established using RSVP-TE <xref target="RFC3209"/> or SR-TE <xref target="RFC9256"/>.</t>
        <t>When PLE is applied to a SRv6 based PSN, the mechanisms defined in <xref target="RFC8402"/> and the End.DX2 endpoint behavior defined in <xref target="RFC8986"/> do apply.</t>
      </section>
      <section anchor="ple-header">
        <name>PLE Header</name>
        <t>The PLE header MUST contain the PLE control word (4 bytes) and MUST include a fixed size RTP header <xref target="RFC3550"/>. The RTP header MUST immediately follow the PLE control word.</t>
        <section anchor="ple-control-word">
          <name>PLE Control Word</name>
          <t>The format of the PLE control word is in line with the guidance in <xref target="RFC4385"/> and is shown in <xref target="cw"/>.</t>
          <figure anchor="cw">
            <name>PLE Control Word</name>
            <artwork><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R|RSV|FRG|   LEN     |       Sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>The bits 0..3 of the first nibble are set to 0 to differentiate a control word or Associated Channel Header (ACH) from an IP packet or ethernet frame. The first nibble MUST be set to 0000b to indicate that this header is a control word as defined in <xref section="3" sectionFormat="of" target="RFC4385"/>.</t>
          <t>The other fields in the control word are used as defined below:</t>
          <ul spacing="normal">
            <li>L</li>
          </ul>
          <ul empty="true">
            <li>
              <t>Set by the PE to indicate that data carried in the payload is invalid due to an attachment circuit fault. The downstream PE MUST play out appropriate replacement data. The NSP MAY inject an appropriate native fault propagation signal.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>R</li>
          </ul>
          <ul empty="true">
            <li>
              <t>Set by the downstream PE to indicate that the IWF experiences packet loss from the PSN or a server layer backward fault indication is present in the NSP. The R bit MUST be cleared by the PE once the packet loss state or fault indication has cleared.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>RSV</li>
          </ul>
          <ul empty="true">
            <li>
              <t>These bits are reserved for future use. This field MUST be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>FRG</li>
          </ul>
          <ul empty="true">
            <li>
              <t>These bits MUST be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>LEN</li>
          </ul>
          <ul empty="true">
            <li>
              <t>In accordance to <xref section="3" sectionFormat="of" target="RFC4385"/> the length field MUST always be set to zero as there is no padding added to the PLE packet. To detect malformed packets the default, preconfigured or signaled payload size MUST be assumed.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>Sequence number</li>
          </ul>
          <ul empty="true">
            <li>
              <t>The sequence number field is used to provide a common PW sequencing function as well as detection of lost packets. It MUST be generated in accordance with the rules defined in <xref section="5.1" sectionFormat="of" target="RFC3550"/> and MUST be incremented with every PLE packet being sent.</t>
            </li>
          </ul>
        </section>
        <section anchor="rtp-header">
          <name>RTP Header</name>
          <t>The RTP header MUST be included and is used for explicit transfer of timing information. The RTP header is purely a formal reuse and RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Transport Protocol (SRTP), etc., are not applicable to PLE VPWS.</t>
          <t>The format of the RTP header is as shown in <xref target="rtp"/>.</t>
          <figure anchor="rtp">
            <name>RTP Header</name>
            <artwork><![CDATA[
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Synchronization Source (SSRC) Identifier            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <ul spacing="normal">
            <li>V: Version</li>
          </ul>
          <ul empty="true">
            <li>
              <t>The version field MUST be set to 2.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>P: Padding</li>
          </ul>
          <ul empty="true">
            <li>
              <t>The padding flag MUST be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>X: Header extension</li>
          </ul>
          <ul empty="true">
            <li>
              <t>The X bit MUST be set to zero by sender and ignored by receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>CC: CSRC count</li>
          </ul>
          <ul empty="true">
            <li>
              <t>The CC field MUST be set to zero by the sender and ignored by the receiver.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>PT: Payload type</li>
          </ul>
          <ul empty="true">
            <li>
              <t>A PT value MUST be allocated from the range of dynamic values defined by <xref target="RFC3551"/> for each direction of the VPWS. The same PT value MAY be reused both for direction and between different PLE VPWS.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>Sequence number</li>
          </ul>
          <ul empty="true">
            <li>
              <t>The Sequence number in the RTP header MUST be qual to the sequence number in the PLE control word. The sequence number of the RTP header MAY be used to extend the sequence number of the PLE control word from 16 to 32 bits. If so, the initial value of the RTP sequence number MUST be 0 and incremented whenever the PLE control word sequence number cycles through from 0xFFFF to 0x0000.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>Timestamp</li>
          </ul>
          <ul empty="true">
            <li>
              <t>Timestamp values are used in accordance with the rules established in <xref target="RFC3550"/>. For bit-streams up to 200 Gbps the frequency of the clock used for generating timestamps MUST be 125 MHz based on a the common clock I. For bit-streams above 200 Gbps the frequency MUST be 250 MHz.</t>
            </li>
          </ul>
          <ul spacing="normal">
            <li>SSRC: Synchronization source</li>
          </ul>
          <ul empty="true">
            <li>
              <t>The SSRC field MAY be used for detection of misconnections.</t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="ple-payload-layer">
      <name>PLE Payload Layer</name>
      <t>A bit-stream is mapped into a PLE packet with a fixed payload size which MUST be defined during VPWS setup, MUST be the same in both directions of the VPWS and MUST remain unchanged for the lifetime of the VPWS.</t>
      <t>All PLE implementations MUST be capable of supporting the default payload size of 1024 bytes.</t>
      <section anchor="basic-payload">
        <name>Basic Payload</name>
        <t>The PLE payload is filled with incoming bits of the bit-stream starting from the most significant to the least significant bit without considering any structure of the bit-stream.</t>
      </section>
      <section anchor="byte-aligned-payload">
        <name>Byte aligned Payload</name>
        <t>The PLE payload is filled in a byte aligned manner, where the order of the payload bytes corresponds to their order on the attachment circuit. Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant.</t>
        <t>All PLE implementations MUST support the transport of OTN bit-streams using the byte aligned payload.</t>
      </section>
    </section>
    <section anchor="ple-operation">
      <name>PLE Operation</name>
      <section anchor="common-considerations">
        <name>Common Considerations</name>
        <t>A PLE VPWS can be established using manual configuration or leveraging mechanisms of a signaling protocol.</t>
        <t>Furthermore emulation of bit-stream signals using PLE is only possible when the two attachment circuits of the VPWS are of the same type (OC192, 10GBASE-R, ODU2, etc) and are using the same PLE payload type and payload size. This can be ensured via manual configuration or via a signaling protocol</t>
        <t>PLE related control protocol extensions to PWE3 <xref target="RFC4447"/> and EVPN-VPWS <xref target="RFC8214"/> are out of scope of this document and are described in <xref target="I-D.schmutzer-bess-ple-vpws-signalling"/>.</t>
      </section>
      <section anchor="ple-iwf-operation">
        <name>PLE IWF Operation</name>
        <section anchor="psn-bound-encapsulation-behavior">
          <name>PSN-bound Encapsulation Behavior</name>
          <t>After the VPWS is set up, the PSN-bound IWF does perform the following steps:</t>
          <ul spacing="normal">
            <li>Packetize the data received from the CE is into a fixed size PLE payloads</li>
            <li>Add PLE control word and RTP header with sequence numbers, flags and timestamps properly set</li>
            <li>Add the VPWS demultiplexer and PSN headers</li>
            <li>Transmit the resulting packets over the PSN</li>
            <li>Set L bit in the PLE control word whenever attachment circuit detects a fault</li>
            <li>Set R bit in the PLE control word whenever the local CE-bound IWF is in packet loss state</li>
          </ul>
        </section>
        <section anchor="ce-bound-decapsulation-behavior">
          <name>CE-bound Decapsulation Behavior</name>
          <t>The CE-bound IWF is responsible for removing the PSN and VPWS demultiplexing headers, PLE control word and RTP header from the received packet stream and play-out of the bit-stream to the local attachment circuit.</t>
          <t>A de-jitter buffer MUST be implemented where the PLE packets are stored upon arrival. The size of this buffer SHOULD be locally configurable to allow accommodation of specific PSN packet delay variation expected.</t>
          <t>The CE-bound IWF SHOULD use the sequence number in the control word to detect lost and mis-ordered packets. It MAY use the sequence number in the RTP header for the same purposes.</t>
          <t>The payload of a lost packet MUST be replaced with equivalent amount of replacement data. The contents of the replacement data MAY be locally configurable. All PLE implementations MUST support generation of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xAA" pattern does ensure clock synchronization is maintained. While playing out the replacement data, the IWF will apply a holdover mechanism to maintain the clock.</t>
          <t>Whenever the VPWS is not operationally up, the CE-bound NSP function MUST inject the appropriate native downstream fault indication signal.</t>
          <t>Whenever a VPWS comes up, the CE-bound IWF enters the intermediate state, will start receiving PLE packets and will store them in the jitter buffer. The CE-bound NSP function will continue to inject the appropriate native downstream fault indication signal until a pre-configured amount of payloads is stored in the jitter buffer.</t>
          <t>After the pre-configured amount of payload is present in the jitter buffer the CE-bound IWF transitions to the normal operation state and the content of the jitter buffer is played out to the CE in accordance with the required clock. In this state the CE-bound IWF MUST perform egress clock recovery.</t>
          <t>The recovered clock MUST comply with the jitter and wander requirements applicable to the type of attachment circuit, specified in:</t>
          <ul spacing="normal">
            <li>
              <xref target="G.825"/> and <xref target="G.823"/> for SDH</li>
            <li>
              <xref target="GR253"/> for SONET</li>
            <li>
              <xref target="G.8261"/> for synchronous ethernet</li>
            <li>
              <xref target="G.8251"/> for OTN</li>
          </ul>
          <t>Whenever the L bit is set in the PLE control word of a received PLE packet the CE-bound NSP function SHOULD inject the appropriate native downstream fault indication signal instead of playing out the payload.</t>
          <t>If the CE-bound IWF detects loss of consecutive packets for a pre-configured amount of time (default is 1 millisecond), it enters packet loss (PLOS) state and a corresponding defect is declared.</t>
          <t>If the CE-bound IWF detects a packet loss ratio (PLR) above a configurable signal-degrade (SD) threshold for a configurable amount of consecutive 1-second intervals, it enters the degradation (DEG) state and a corresponding defect is declared. Possible values for the SD-PLR threshold are between 1..100% with the default being 15%. Possible values for consecutive intervals are 2..10 with the default 7.</t>
          <t>While either a PLOS or DEG defect is declared the CE-bound NSP function SHOULD inject the appropriate native downstream fault indication signal. Also the PSN-bound IWF SHOULD set the R bit in the PLE control word of every packet transmitted.</t>
          <t>The CE-bound IWF does change from the PLOS to normal state after the pre-configured amount of payload has been received similarly to the transition from intermediate to normal state.</t>
          <t>Whenever the R bit is set in the PLE control word of a received PLE packet the PLE performance monitoring statistics SHOULD get updated.</t>
        </section>
      </section>
      <section anchor="ple-performance-monitoring">
        <name>PLE Performance Monitoring</name>
        <t>PLE SHOULD provide the following functions to monitor the network performance to be inline with expectations of transport network operators.</t>
        <t>The near-end performance monitors defined for PLE are as follows:</t>
        <ul spacing="normal">
          <li>ES-PLE : PLE Errored Seconds</li>
          <li>SES-PLE : PLE Severely Errored Seconds</li>
          <li>UAS-PLE : PLE Unavailable Seconds</li>
        </ul>
        <t>Each second with at least one packet lost or a PLOS/DEG defect SHALL be counted as ES-PLE. Each second with a PLR greater than 15% or a PLOS/DEG defect SHALL be counted as SES-PLE.</t>
        <t>UAS-PLE SHALL be counted after configurable number of consecutive SES-PLE have been observed, and no longer counted after a configurable number of consecutive seconds without SES-PLE have been observed. Default value for each is 10 seconds.</t>
        <t>Once unavailability is detected, ES and SES counts SHALL be inhibited up to the point where the unavailability was started. Once unavailability is removed, ES and SES that occurred along the clearing period SHALL be added to the ES and SES counts.</t>
        <t>A PLE far-end performance monitor is providing insight into the CE-bound IWF at the far end of the PSN. The statistics are based on the PLE-RDI indication carried in the PLE control word via the R bit.</t>
        <t>The PLE VPWS performance monitors are derived from the definitions in accordance with <xref target="G.826"/></t>
      </section>
    </section>
    <section anchor="qos-and-congestion-control">
      <name>QoS and Congestion Control</name>
      <t>The PSN carrying PLE VPWS may be subject to congestion, but PLE VPWS representing constant bit-rate (CBR) flows cannot respond to congestion in a TCP-friendly manner as described in <xref target="RFC2913"/>.</t>
      <t>Hence the PSN providing connectivity for the PLE VPWS between PE devices MUST be Diffserv <xref target="RFC2475"/> enabled and MUST provide a per domain behavior <xref target="RFC3086"/> that guarantees low jitter and low loss.</t>
      <t>To achieve the desired per domain behavior PLE VPWS SHOULD be carried over traffic-engineering paths through the PSN with bandwidth reservation and admission control applied.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>As PLE is leveraging VPWS as transport mechanism the security considerations described in <xref target="RFC7432"/> and <xref target="RFC3985"/> are applicable.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>Applicable signaling extensions are out of the scope of this document, hence there are no new requirements from IANA.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Andreas Burk for reviewing this document and providing useful comments and suggestions.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>Contributors' Addresses</t>
      <artwork><![CDATA[
Andreas Burk
Deutsche Telekom
Email: andreas.burk@telekom.de
]]></artwork>
      <!-- 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>
        <name>Normative References</name>
        <reference anchor="RFC3985">
          <front>
            <title>Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</title>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant">
              <organization/>
            </author>
            <author fullname="P. Pate" initials="P." role="editor" surname="Pate">
              <organization/>
            </author>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3).  It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS.  It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3985"/>
          <seriesInfo name="DOI" value="10.17487/RFC3985"/>
        </reference>
        <reference anchor="RFC4664">
          <front>
            <title>Framework for Layer 2 Virtual Private Networks (L2VPNs)</title>
            <author fullname="L. Andersson" initials="L." role="editor" surname="Andersson">
              <organization/>
            </author>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen">
              <organization/>
            </author>
            <date month="September" year="2006"/>
            <abstract>
              <t>This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs).  This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4664"/>
          <seriesInfo name="DOI" value="10.17487/RFC4664"/>
        </reference>
        <reference anchor="RFC4197">
          <front>
            <title>Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks</title>
            <author fullname="M. Riegel" initials="M." role="editor" surname="Riegel">
              <organization/>
            </author>
            <date month="October" year="2005"/>
            <abstract>
              <t>This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks.  It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3).  It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4197"/>
          <seriesInfo name="DOI" value="10.17487/RFC4197"/>
        </reference>
        <reference anchor="RFC4385">
          <front>
            <title>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN</title>
            <author fullname="S. Bryant" initials="S." surname="Bryant">
              <organization/>
            </author>
            <author fullname="G. Swallow" initials="G." surname="Swallow">
              <organization/>
            </author>
            <author fullname="L. Martini" initials="L." surname="Martini">
              <organization/>
            </author>
            <author fullname="D. McPherson" initials="D." surname="McPherson">
              <organization/>
            </author>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header.  The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4385"/>
          <seriesInfo name="DOI" value="10.17487/RFC4385"/>
        </reference>
        <reference anchor="G.8261" target="https://www.itu.int/rec/T-REC-G.8261">
          <front>
            <title>Timing and synchronization aspects in packet networks</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
            </author>
            <date year="2019" month="August"/>
          </front>
        </reference>
        <reference anchor="GR253">
          <front>
            <title>SONET Transport Systems : Common Generic Criteria</title>
            <author>
              <organization>Telcordia</organization>
            </author>
            <date year="2009" month="October"/>
          </front>
        </reference>
        <reference anchor="G.825" target="https://www.itu.int/rec/T-REC-G.825">
          <front>
            <title>The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH)</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
        </reference>
        <reference anchor="G.823" target="https://www.itu.int/rec/T-REC-G.823">
          <front>
            <title>The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
        </reference>
        <reference anchor="G.8251" target="https://www.itu.int/rec/T-REC-G.8251">
          <front>
            <title>The control of jitter and wander within the optical transport network (OTN)</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
            </author>
            <date year="2022" month="November"/>
          </front>
        </reference>
        <reference anchor="G.826" target="https://www.itu.int/rec/T-REC-G.826">
          <front>
            <title>End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
            </author>
            <date year="2002" month="December"/>
          </front>
        </reference>
        <reference anchor="IEEE802.3" target="https://standards.ieee.org/ieee/802.3/10422/">
          <front>
            <title>IEEE Standard for Ethernet</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2022" month="May"/>
          </front>
        </reference>
        <reference anchor="G.709" target="https://www.itu.int/rec/T-REC-G.709">
          <front>
            <title>Interfaces for the optical transport network</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
            </author>
            <date year="2020" month="June"/>
          </front>
        </reference>
        <reference anchor="G.707" target="https://www.itu.int/rec/T-REC-G.707">
          <front>
            <title>Network node interface for the synchronous digital hierarchy (SDH)</title>
            <author>
              <organization>International Telecommunication Union (ITU)</organization>
            </author>
            <date year="2007" month="January"/>
          </front>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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="RFC3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
              <organization/>
            </author>
            <author fullname="S. Casner" initials="S." surname="Casner">
              <organization/>
            </author>
            <author fullname="R. Frederick" initials="R." surname="Frederick">
              <organization/>
            </author>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson">
              <organization/>
            </author>
            <date month="July" year="2003"/>
            <abstract>
              <t>This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="64"/>
          <seriesInfo name="RFC" value="3550"/>
          <seriesInfo name="DOI" value="10.17487/RFC3550"/>
        </reference>
        <reference anchor="RFC3551">
          <front>
            <title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
              <organization/>
            </author>
            <author fullname="S. Casner" initials="S." surname="Casner">
              <organization/>
            </author>
            <date month="July" year="2003"/>
            <abstract>
              <t>This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control.  It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences.  In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP.  It defines a set of standard encodings and their names when used within RTP.  The descriptions provide pointers to reference implementations and the detailed standards.  This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890.  It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found.  The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="65"/>
          <seriesInfo name="RFC" value="3551"/>
          <seriesInfo name="DOI" value="10.17487/RFC3551"/>
        </reference>
        <reference anchor="RFC2475">
          <front>
            <title>An Architecture for Differentiated Services</title>
            <author fullname="S. Blake" initials="S." surname="Blake">
              <organization/>
            </author>
            <author fullname="D. Black" initials="D." surname="Black">
              <organization/>
            </author>
            <author fullname="M. Carlson" initials="M." surname="Carlson">
              <organization/>
            </author>
            <author fullname="E. Davies" initials="E." surname="Davies">
              <organization/>
            </author>
            <author fullname="Z. Wang" initials="Z." surname="Wang">
              <organization/>
            </author>
            <author fullname="W. Weiss" initials="W." surname="Weiss">
              <organization/>
            </author>
            <date month="December" year="1998"/>
            <abstract>
              <t>This document defines an architecture for implementing scalable service differentiation in the Internet.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2475"/>
          <seriesInfo name="DOI" value="10.17487/RFC2475"/>
        </reference>
        <reference anchor="RFC3086">
          <front>
            <title>Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification</title>
            <author fullname="K. Nichols" initials="K." surname="Nichols">
              <organization/>
            </author>
            <author fullname="B. Carpenter" initials="B." surname="Carpenter">
              <organization/>
            </author>
            <date month="April" year="2001"/>
            <abstract>
              <t>This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products.  This format is specified to expedite working group review of PDB submissions.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3086"/>
          <seriesInfo name="DOI" value="10.17487/RFC3086"/>
        </reference>
        <reference anchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi">
              <organization/>
            </author>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal">
              <organization/>
            </author>
            <author fullname="N. Bitar" initials="N." surname="Bitar">
              <organization/>
            </author>
            <author fullname="A. Isaac" initials="A." surname="Isaac">
              <organization/>
            </author>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro">
              <organization/>
            </author>
            <author fullname="J. Drake" initials="J." surname="Drake">
              <organization/>
            </author>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx">
              <organization/>
            </author>
            <date month="February" year="2015"/>
            <abstract>
              <t>This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN).  The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
      </references>
      <references>
        <name>Informative 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">
              <organization/>
            </author>
            <author fullname="P. Pate" initials="P." surname="Pate">
              <organization/>
            </author>
            <author fullname="R. Cohen" initials="R." role="editor" surname="Cohen">
              <organization/>
            </author>
            <author fullname="D. Zelig" initials="D." surname="Zelig">
              <organization/>
            </author>
            <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="RFC4553">
          <front>
            <title>Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)</title>
            <author fullname="A. Vainshtein" initials="A." role="editor" surname="Vainshtein">
              <organization/>
            </author>
            <author fullname="YJ. Stein" initials="YJ." role="editor" surname="Stein">
              <organization/>
            </author>
            <date month="June" year="2006"/>
            <abstract>
              <t>This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4553"/>
          <seriesInfo name="DOI" value="10.17487/RFC4553"/>
        </reference>
        <reference anchor="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">
              <organization/>
            </author>
            <author fullname="I. Sasson" initials="I." surname="Sasson">
              <organization/>
            </author>
            <author fullname="E. Metz" initials="E." surname="Metz">
              <organization/>
            </author>
            <author fullname="T. Frost" initials="T." surname="Frost">
              <organization/>
            </author>
            <author fullname="P. Pate" initials="P." surname="Pate">
              <organization/>
            </author>
            <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="RFC5036">
          <front>
            <title>LDP Specification</title>
            <author fullname="L. Andersson" initials="L." role="editor" surname="Andersson">
              <organization/>
            </author>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei">
              <organization/>
            </author>
            <author fullname="B. Thomas" initials="B." role="editor" surname="Thomas">
              <organization/>
            </author>
            <date month="October" year="2007"/>
            <abstract>
              <t>The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031.  A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them.  This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made.  This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5036"/>
          <seriesInfo name="DOI" value="10.17487/RFC5036"/>
        </reference>
        <reference anchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils">
              <organization/>
            </author>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi">
              <organization/>
            </author>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg">
              <organization/>
            </author>
            <author fullname="B. Decraene" initials="B." surname="Decraene">
              <organization/>
            </author>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski">
              <organization/>
            </author>
            <author fullname="R. Shakir" initials="R." surname="Shakir">
              <organization/>
            </author>
            <date month="July" year="2018"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called "segments".  A segment can represent any instruction, topological or service based.  A segment can have a semantic local to an SR node or global within an SR domain.  SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane.  A segment is encoded as an MPLS label.  An ordered list of segments is encoded as a stack of labels.  The segment to process is on the top of the stack.  Upon completion of a segment, the related label is popped from the stack.</t>
              <t>SR can be applied to the IPv6 architecture, with a new type of routing header.  A segment is encoded as an IPv6 address.  An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header.  The active segment is indicated by the Destination Address (DA) of the packet.  The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author fullname="D. Awduche" initials="D." surname="Awduche">
              <organization/>
            </author>
            <author fullname="L. Berger" initials="L." surname="Berger">
              <organization/>
            </author>
            <author fullname="D. Gan" initials="D." surname="Gan">
              <organization/>
            </author>
            <author fullname="T. Li" initials="T." surname="Li">
              <organization/>
            </author>
            <author fullname="V. Srinivasan" initials="V." surname="Srinivasan">
              <organization/>
            </author>
            <author fullname="G. Swallow" initials="G." surname="Swallow">
              <organization/>
            </author>
            <date month="December" year="2001"/>
            <abstract>
              <t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>
        <reference anchor="RFC9256">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils">
              <organization/>
            </author>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar">
              <organization/>
            </author>
            <author fullname="D. Voyer" initials="D." surname="Voyer">
              <organization/>
            </author>
            <author fullname="A. Bogdanov" initials="A." surname="Bogdanov">
              <organization/>
            </author>
            <author fullname="P. Mattes" initials="P." surname="Mattes">
              <organization/>
            </author>
            <date month="July" year="2022"/>
            <abstract>
              <t>Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</t>
              <t>This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>
        <reference anchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils">
              <organization/>
            </author>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo">
              <organization/>
            </author>
            <author fullname="J. Leddy" initials="J." surname="Leddy">
              <organization/>
            </author>
            <author fullname="D. Voyer" initials="D." surname="Voyer">
              <organization/>
            </author>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima">
              <organization/>
            </author>
            <author fullname="Z. Li" initials="Z." surname="Li">
              <organization/>
            </author>
            <date month="February" year="2021"/>
            <abstract>
              <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC4447">
          <front>
            <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini">
              <organization/>
            </author>
            <author fullname="E. Rosen" initials="E." surname="Rosen">
              <organization/>
            </author>
            <author fullname="N. El-Aawar" initials="N." surname="El-Aawar">
              <organization/>
            </author>
            <author fullname="T. Smith" initials="T." surname="Smith">
              <organization/>
            </author>
            <author fullname="G. Heron" initials="G." surname="Heron">
              <organization/>
            </author>
            <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="RFC8214">
          <front>
            <title>Virtual Private Wire Service Support in Ethernet VPN</title>
            <author fullname="S. Boutros" initials="S." surname="Boutros">
              <organization/>
            </author>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi">
              <organization/>
            </author>
            <author fullname="S. Salam" initials="S." surname="Salam">
              <organization/>
            </author>
            <author fullname="J. Drake" initials="J." surname="Drake">
              <organization/>
            </author>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan">
              <organization/>
            </author>
            <date month="August" year="2017"/>
            <abstract>
              <t>This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8214"/>
          <seriesInfo name="DOI" value="10.17487/RFC8214"/>
        </reference>
        <reference anchor="I-D.schmutzer-bess-ple-vpws-signalling">
          <front>
            <title>Private Line Emulation VPWS Signalling</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="Patrice Brissette" initials="P." surname="Brissette">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <date day="3" month="May" year="2021"/>
            <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-ple-vpws-signalling-02"/>
        </reference>
        <reference anchor="RFC2913">
          <front>
            <title>MIME Content Types in Media Feature Expressions</title>
            <author fullname="G. Klyne" initials="G." surname="Klyne">
              <organization/>
            </author>
            <date month="September" year="2000"/>
            <abstract>
              <t>This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2913"/>
          <seriesInfo name="DOI" value="10.17487/RFC2913"/>
        </reference>
        <reference anchor="RFC1925">
          <front>
            <title>The Twelve Networking Truths</title>
            <author fullname="R. Callon" initials="R." surname="Callon">
              <organization/>
            </author>
            <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+19a3PbyJXod/6Kzri2rjRDUiT1sKXazI5MUbYSWWJE2Z7U
3ZtUE2hKiECAwUMyx/b+9nse/QIISnJsj6eyo1Q8EtDoPn369Hn36U6n0wrS
MEquDkRZzDrPWq0iKmJ1IMZZdCsLJU6jRInRvIxlEaWJSG9VJsYyuFGFmNxF
RXCtQnGmirs0u8lbcjrN1C18fDpqhWmQyDn0FGZyVnTy4HpeFr+orLOQcd5Z
xKrT224FMMRVmi0PRF6ErWiRHYgiK/Ni0Ovt9watVl7IJPy7jNMEOlqqvLWI
DsT/LdKgLfI0KzI1y+G35Zx/CdL5XCVF/v9aLVkW12l20BKiA/8XIkryAzHp
ihcZzFVlET1k+CaFulVJ9U2aAULewF+/pAk9eJLDYKo40N09CaJi6f5IQ+X9
USZF5l4urgl4/kvNZRTjZHHI7pUe8qdbHqkLE6hC/KeueHsdFYW8UZkH8p9U
pubL2quvDPM/aMzunRlzPdBnXXGqlnOZJB7IZ1GQxjKqvCGIj1RZAHEocali
dUN9fWnQz7p61J8KHqMbqirIw66YGAL1gB5eZ1FeRDKpvSXAh1EepGKyhMWc
A/GdJEGXXmYp7h8VRkWafYXJBHon/RTg+KvYP+0CSuNYAvCRyqU3m9MykKvv
7p3LlwU9DnHw4Hod6EA4ZzJKpL8EZ/JKJcBCxJ/Lucz8999yERIZ3SA862YC
9DSOrhJZyCz16UlmcZrXXv2KCxAseOR1YL+AbTCXcayuJDAmD/AXKpNxuPJS
g64SoKg0W6QZCYmvAPhVziMD4DBYI76fZ+mdz3Bo73pPfzVYgymOuQ7SY9ie
MvS35bGMchm7pwToz1EcJe++AnQzGi386R0NQPC1omSWZnPAx606aLUS97sQ
F8fD7f1nu/rXnb29HfNrf/+p+XWbG7zoPhvs9Q9oNK1FXEZzEHEChDhI6SS4
ztIk+oU1CZkvVFDkgBWxYH0iMWoEduAEuMaJNF8ewO4oVJbQH4A4lBso+csk
Crjr1wn+u3Fy+XpTMDQyu0IMXhfFIj/Y2rq7u+tGRdmNkmIrU8HWZediNOww
/PRBCHrJgRj0+vud3jOc2sVgd7sysx81ZJPzs9GluMxkkgNNFWYLC6A1gAnA
eKESEJSBGGYRQB3JB2cH8wnSLNQtDSS9/U6/JzSWd6tIBuEZpLDyaSzSmfgH
CGhQ0hDnd/AP/Ap62jWgOYyuogIQZvAsQJYH10JmSkxlDnocQFtAX2al0jK3
34C8yGQWXC/FxuTo5ea3XKLdKl56oEcSABo3218VN4PezjNxM42Krdzh5Fti
Y3sVG4ZI+v8SJnCW6aIA0GLQxQ1Za7yIjfPLs2+7+tUNOhh0+n3DeyrzHSVh
p0g7oDwIlWVpJhYqIzaXBAo4Tga8F4DMCQPp9B/Ai4Dl5QKaAEvywEezIkE7
pBCw7J0MjSJDLQtZXHMP0CbBLqDpN2VfVWoA5AzgycloNHrWG3SrWwOfgvED
0MsspHmPYO0zWOmHZwCfNkKW6+7ybqSU6sJXW/jLFo2+1e/tDAZb9fXr7dL6
Pe3tNzJYwtZMBnpt7iXPb4d6gL46L9iIe3peTxvnpY1mkYAEZ4rDSdo5/qaZ
MMypSmhPO71+q9XqdDpCTkFfkUHRal1egwIWpkGJRrkIVR5k0RSWUQrYetcp
05xKArnIyb0AisJ1dHXdAcUAGC5uNtR8JAhTmYvbKCtK3HLaL3EXAWvOVXYb
IWVsvBm/nWyyd0JrE7nxTliWvjGenG1CB+lthB4PdBcsYmACIket2Ccn/g2Y
fxIsuzyteRSGsYI5PkG0ZmlYBqzGwOZ/lRYIFKqTD086QEU2XOdf2RifjjY/
CTFvNGJMh28RMRNGTAUv67w2jJeuIMiVhSQvI9DO5GIRa3JBmaiyGrYYRwK+
zNQ/Sxg6JIwAYUggRjEDNovgA7yArzLTlL7IVKH9STOi9vFI3KUlWBhTFFIl
tsGFIiTfKliCc8CSeidxwXAwgFwoza0M74WhhyPmxthlgrhCRPo7yX6TgjRg
CKaABqVI7s1JBqZlQR0QpHMwIRGr41GuN6lCpw3OTYZhpvKcKQmESgYYklP8
2oeM5C1MpUiDtIY0BC6QWQa72n1iSLoNgC1TPRf4/VreRtA+VLMoiXg5AHev
RscC9ehoZhYJcHWYpNibxZfFrAR2D3bPlRKHQD6GAHACG5ND2BrqXaGSvIIU
wDOtZaBw8nlXnDPiUKkvoENHjCJWtyoWQN3pHbNq6UlF2+NxNAUqGF5LeBOb
TZpbxPs4xmewnEtDJNVPLU7nKoBHUT6nucd5yjr5FrBIXKOtMEsXAsi6iAAZ
71DkI96zNM87Gr4clgEh5NEdOa0FCqGxPVbom+nPshwPNt5fEXKCG7UEnp4D
Fhk3RQqUO+a1hWFBCXv//r/QsHq2M/j4UW+7UFVGxGEqD5DtqJx2IHQABgRQ
AHTMhK5Q+9G2ysTbD2O5jFMZgrIEawdNgRDGwH+wc8NXLoF/lSAYQOi8udxE
3CFizdshULgEqDN4OwQmMpERjS81Dd7JZRvdwcASATfMe4EQE2gTqgUoZ8gl
Y7mEpkbFLFEbTZTUeHaLWWnWZrQAAyTUYe9mqpL3bw4aniFKmA/wzsyt3ppe
u8jAlbdsloPTrIoKc5+lSOsokZIgQq82sMZ5FEvCu17B3d1tWMEpMoV3CwAD
VwrH13x1ClZ4sfS3egIMATrNkUfNxBgAjJwCtHHZb4sR/P9ym+Y02ua1ok1H
nzsZBl8zp4bNmKVzMcedFEYzoGMEvoApJmmcXkXQb16irZNbBbBd3WttD13v
35Mt/PHjFvyGigBMD0EAu0Dwk318Uoir6AqmVwgSWrmYLgWyiUIjYI7Decxj
oQnR2wO51qfFdhf+R4Pgbzs4s/fv/6A9Ex8/dkkoX7D4If+/OEsLK44VbTdY
XADiu1evJ5fftfm/4uycfr8Y/eX1ycXoCH+fvDw8PbW/mBaTl+evT4/cb+7L
4fmrV6OzI/4Ynorao1eHf4X/IOjfnY8vT87PDk+/WyUktDKBZKaedEQ5WiO+
58Nxf0fPfNDvI5r5j2f9pzvMJhIeK03ipf4TUL1EYlMyo20Zx8DrFqhNgoSB
EfLr9C4RuJMYjZcg8iKiiyV1daGIXkCVeAV6agxNKm1are/F4fCl6IjDPE8D
FJWh5dAvlYSdjC1OJtgCdsYclKfQqJ8TIk94P3x+Ae+Hxsx6DlRzAT3hmxG+
KPMincMmHYVX9HByMeT2BfEmJKlJWl4M8eUIhxqhwQeQTEDhTUJ4ejzCL47T
7A5tHXqNXsCMSQwanLw9hgakML/VMvG4TMzb06MxvD2VU5jVETBuHhamMNZC
CNtgB6cp2iXHEhgzPHo1PkVoXiGbtk11N6yGwTjQ7myC3Z+R082qbtAetnye
IgLPj17fQItzbfccoUQG5b0QN/gSdp575zxRWrxTi8rnrontYzxEQMfXy5xa
DCkkKCbllLgjNsCFGDP7tguBfL2zRpOl1+fUK+udpyBwxfnMrTpone5tXSvF
9wPEyjiFPYGGPP0Cj/9Cnf4FhA9yTuyQEQavLiZvxp1LhOlC5WmZARbhF3gt
K4uFCJiBwgRS7wpgJrmOX18OccCLyzGTVhr7y4uPsV8JawlyxeHQawNKFLRp
0rHwJVHmBORRpmB7Vkk0xwZHuI986Xyk7b6X1tEErWgl7pPh2Iihhb5R5X4A
6IvbPWp7RbzoIuUNRSbDyRjeIbUtYplQx7z1JjVfrt19rGFU4TNk51DBiCZo
5lFOCmcDxl8fIsJeJ/JWglCdxsrDFZo18PI+2wdbDb02wygLwKTBx5feY6ve
tFqTNdIb+SA/2O0924MHJGgVMTP4z12NX4BB/fZ4E/WxEh2H0Jth4/ThTDeD
sadxGtzAQ5CWztpTJBeFsfCA6FPaaGzWsn6p3XQZElOO7ijNyGAkr5v6V5ki
TxZqqpUxiPM/qbP6nIXnlXZfZ/btHN9WldWJHn6n20fprCMFFnWrr1lys9qG
qtBS8Cy7gMWMFEdSse8baVDtSqMFbCugtpKWkR2egVqQMiTXMFgyf4ADb9qV
WTtifcwV8FGi3qk47pK3FawB5PzQfx15aB1hczQI4rhEh0lhxoO2f6dWHz+2
Wv8DP9q1434+/Cc6JBaDhTgdvBmfGZNRdDo/flhtXH/gvVrTGPpH3lyUKMWh
zzWNb71/6w8rjX/omJ8fqo29F5UPcMTxqI+//bHywy8GK+BgRz+sH4Fet/wG
H8SZmWwjBuxr/VHrA6giffGB/vogJvAWNYYPXfxBZkS/6If4WjccArAf3Mh/
w67H949Mr//mRvYbPGaejBuEdmHEOXa37udvgoA0bXE454xchbIOsWu7hkzZ
oQTE7aj0s8hUFoUMrklU1X/cq2r3AXP+pr71K95n7w/EE7v72F37x+9wm9Y4
43ewMfGxmk8zMsuIV0VJNC/njJBbgAF5hjYNQXSBVI1XeQraM7tVnmKsWuyT
PC/AI2Zg3bHdlKXlFRuwBIBzEUJnbMhK9MQFChid81/AhDwHkWi1jtEtBiq1
XZRiudDzQF3UMkJy64HGkOQRyt+Zi6KQimB8aLmJjiXMYQluCwVZn/h2COx9
xD6pnG0eMiTYJlynm4sN0N3J7eC3xu5Iq+VJI2CgBnfF4azQsgPngf/FHQnT
IDHmvjXmpvYskTrBEb8o1z65UNxGEqSGY4XdNfwYf/7U+PQeqq79vGj8/rbp
YePP6o7Cn0Ze0ficOPbK4w8d0JQ6NSaMfJifr3SInVgZYn6YSa778Ru6mWh2
60FCAsE8oPWyzwfVhsxzHSS2/x8fgMRr6CD5IjihH58J63dm7kYQ/lj/5gHu
6/38zX5zuPaTH2qk0Ew0tWFOqgONHvENjOM4Krqc/h6wpsss9ULFzCdMCGwS
qERmUarTRZC/XqaeU4u/1nvVerhQpuhQBPlOzLaV5Nu1TDJM5zJKyPnhud8L
9EzqOAED0aonqNSVNoprqEWcLkn65AboZta+A6zdqIuYKwOsPbLhFGCm6Ktu
0P4ctj5+bLOn0Ak8I8gYHyOPr2FYaElbgZmW9fNFgB5ujto/mAtLE4eK/BkC
BiWlzwLk3PykiyyZHVXwllBEMkn3DB8Zl77+gOPg9PuhIAfbFGM2OGFY9yUj
H75Fq9cLutDGxk8R+jI3HBoN1rwAYYFpU+gzxodo1l6TV6nLQqzZCsIeSTc3
2PGo6E8rE/fBd+0a5slNXmgfsaGfKtZIpUcJhwuGi5ojfZAzNkD/OhGx5/vr
irdgLwic6jSOcvSAaJtFx1CC60jdIlJmGGCjuFGdUIm0UUxdS9hUMgb9IUSf
sqpZMpzfpG0lHfEggoQGFGIw1gt5AkdGcZuYIOv7J0aZ65go1Ucd8KzEoBj3
FaPXhRURE6ZD0gwkqCmwvBkmFRJ6mhzTl0ev2jZG1hYz8k4H2s/Iwl87lLVR
iw9tUCb0X5BbtcG+Yy/zik1ZbbBTadAlu9kkeCGzMb6HiumML4yihTwgsZE5
zdI86B4JGipxrylrh1hEnpfzBYeSrnX0YzjqTNMSJqAVoCQtVnQ5jAgYwMwK
Oq2uzeE9i9AZtaftpInHcFy3a/0pax2Lt0umGIiqfrkAiDiSojmNhkZ7JEw4
wlJMq7XyiBRJAh45ncxVbrDavPxrEbyytJQfc+2RS46MBkYhnZO3pw3bUnc2
zwYXyMX0IxOa0lFTUkCNbbYxfvnXTe6yDYIGJgNICaIcfYS6rXXLTsopH9YQ
p6T2boyHk00MjqOvjjx8XpAHofLAM2Yaa/rEKYhD6HU3GPGmoOOv4lZmS4px
ckgKdh2mdyjMjA/cDk0X2ql1myMUYAKkIGvQ707Jn9BBrDroRaQG6BfhvwrP
C4hUfYjcsHGRMZSXXRlKm8q8SmfaA2TmaenZi+VhL8BdeTWB87P0oDxUVEdW
toJPqzlt9iei33vx/HAy6lzQeINd/RfveHSja+oATLmmHtEFsSxBWO3sV79v
aNLvPeVQl78mlYREKfZ2nm/t7T0XmAYMAFbbcj+5eLpDY/V7z4Az64HgW7ti
uEiaAKOZ3ZNEeZMzzUUq25aEuzHHmMGbha6wnspHc1B0qgIZvtGydM04yCwx
nu/zLXKngowo1q2EW75VzQk2LYZmHNVihMIkJ4sY1MYVgDT7nIOgNKQHck3O
p5jE46PfMBhy2DZSKJL35Vr8EFK1dS1aOibDHQNw+IAkKo6MgGDWtovyLzLk
MDHF41jPwl6i5FbGEYBpQCSHs/Yp8yc6N9IkqtjNnYut0Rb2BtqXygo/sCU2
To83eWhiigUlBiWNUgdgpCgQqDew6DAQtaw4pjNVdVhQP6cdZNlTpflOq3WW
YqbZyZoJAVNDBoksE9UYythkbcnK2CpkNCn2zC5iYBecrEXuloSkCH4G9FD4
sLZxAhF3N0MjIlxHuGFEiGGyYoWVtOg+6KUl0TC0ZBcHBTZw99BCIP09V7OU
cttctoAnvzRxDUfte/Ya0RJtHUOr1LiBXDVX2zF7qS12K9uq3+vdw+F21rRt
4GbPBhyannkDNPC87e1P4nlGfBSoqFLIyuTECJQu+UM8cb//m2SJqbhCm1UG
GKAwS34/22mCjSMpPmPBHc1Rp5oRYRgOyWRgNDfqrvIoU7ThMVL6r3PsR1DZ
r8C98RBGHP2iwvaDnDyIS5exE0dXCYEzl9kNboB7OP3nMfr6UIDOeQqc73ch
8L9GCLxFFH0ZEeBtfY90NEZ8unfMIfRyXBoJUuMO36L4GPQq23nnXqGxtnGT
POjv/wvyAH8jBb8lQS/ce7412H1q3iNvCsuA2S1KDFwZzqaUN0CFaTrXyasV
K2YtV/48XuwQS3hnF6PPfE+rzFe36JCdEyt5SwyZ85tCxcYh/r0Aqu3gw3rD
x7IW/Ns41gxO2QsF+HE4BSRoBLRafuS+OvsKx2MHQjpfqCSXNoXeo8wp6z/F
g4wc8zvv5cEXK0MZFyzyrNQ5SwgmsyNgMYFnEAl5m874OtDNypH73cGzrd2d
HfZUsis5RfEf42d+jx7BA2F59G7s+1eHzj9kDNiu+Fkk5XwKCIVu9vZgYOgx
TpFdrUxLc0BJ+fW4MwFQRc7en78f9Hae7le6AmIFDOB5JvqMHb0ekAgTkERJ
E/gZp9rfo0WaVcFfbbc96IpVpHvQGUcN75gVcYMIWy6U6L3r9Xh10NOkYGlj
dGgCljANSuf1T5dNPN2JQ6JsoqP555iZ69nVl1BVvpAt+P06onD7+3dN4XdN
4fGawgrPN3IOurTsv6pSGPGyRk/4Hs0okkl17YKmkzjhZeVetSF6hF0e+sS6
hN2zr+8TnlTz8SWdy6iEWFxGPOdC3tuaM+nv504UTEHvPWVxLLXTUu8AokE8
XVDL1HDsy2GnwTfaEFtc5Vtt+OeYc/zPjwHWo0p2h+bCjZKa5rlOPtvsFHRZ
yzvcIKhWAcIdyHh8TFki/4oc47790ZAEU8smQaJ9NelgmjvGmguV0CFjHZ1e
1Wr3uoPuTrfP2ZCOaGb6bI2LdlDqfOf08b32OeZsSYv7JEJ0veJGqp6lcpvp
uBJZ+/obCgn/EvgcRf0oyIHxVPTnEE89ORueXE4eisJUwoEPRV6Oh50+f7wu
ckIRqQoeHhk+ga7HJ513tFfg9+MJ/G5PRH+DcApHU2brl5RCKvLbx1ReHA/b
YkD/7sC/NOwz+OUhta2Z5dUm/LUdSpa5PHu+1e9VLUGZM5P6AiEBf2XpOBND
uU6t05qKVepWPs8dM7Q729Ci+PN2r/vU0+dAnzInP4kqN87OJ99YqWuY0K+j
12HqCW3ugQDplIT0Ud8kPZAnGUcq+WtPTUdW9YyI3JwAoyFWJM+KQlbV9rV9
zCDTyc/1GEkzb5Jn5yCg/DXrisMkNP3dq0I+qD9W4gyrG8Fs9D2zu7cHtL2Z
Y+5WEUk4zBvd8YRD6oWtVurGetu5ScQn2zwZxKPstR0n7YqTGX0S5ca73/6N
RDx/Wzytyb31BZmaNTVWGduqR+pLsDq2X1eH7I+uf2d3/9uinntW2dhh7ak/
YK3jeQqLwlzjKbEc11LzkjE7w/zPXBixqrCxrinu2fW/QvDwK7qp//1c1F/F
GY3bWRz4qsGqyy7S9owGMy/KcPk5vssvLzU+gaevsPRPCF/+ztL/DVj6v59n
sskrid4UOp+POcjOkUKPvr7/BAd9yCG5/5CL8R75Y1NfeL2Q5ih/ucDSLSFP
3OVJoHcDKZv8dh4jN3FWd7y3AvcnOiRNvYzPYIx0duwT+SH5QfGfV22qaIHo
ORq90CcRquu9Ki8Ix6U29yiWR+jBSmCPzBu5i+LYnOKgXmjI6VJHxYyFSZt6
Df4J5gad4bftXsV5Pt652t/r7vqe1X1TIQahHlVOTFIWNaOcJbYuHcfVcPn4
vov3cqkUffT+/Xs6fEl901End5a5+ecHIegYMf7gWQ0qsYTH2I7UvHxnT1vh
P//d8o5cbWARkS0s0rDpHcqif3+sdNR66LAhvd8SekAuzpJ/EtwIOuDC1Gp4
i1K2AvcjOmO4oRddHcaHGo/38OM61I/oueODKaiIzIS5aa2zCnpt9YwVTCGY
/O6RmH0kjPZgHBGQf8y4gTjxKBzIlxWC8ep+mYWsVx40YSM8jbTkox6G39kj
Nkt9dI4onSqfmqNLZu/RiA2lxxAi9sAb9iG53I19YQpgdMUh9xJT3RtdAkwf
cK52bN3KK7WPnBTc7dZLP1jTSh/TtUebsBwXZoJOFag/WKq1UnoHOS8+2zjF
2g/+ASw+zoI1f0zVj22s+oGRlFqRFH7/bKc34Pd0wpBKyyhdWga6g/4buje1
ariL7QGVzcIhLtzTfdBnkMM8QH6CF0CzKZPfQkf6qLgL50oBgpgNV4qb1SrO
6akYy3OUhN2jnwcwm3CB5XdqdQgrX+5TaZQw5YIY+gSPt9FZWMPfrEayQAy4
fBzLS3hnEgtIgd/YIUGZc40zas+qBq7tLHpHB0B/8U8Fmrpgu7s9QxfeS+5h
rks6xktTwK1pcO0hqLM7noWWD6Z2ZR1ulpt4JtQJxKsyCkluEcL+oKumm7ol
nnB5/z64c1Kl17Da/YZng4Zn2/B1H95six2xK/bEU/FM7ItPeAYM7TP/1/rQ
E/S/D6cfLj4AyX84vniB3PJ0dOZxWgEbSxs5Ok/JctYvAINluMGdz239ZaUT
x2yg5KLX5cN2pEhFGfCOJJqiakJKvCJduEe6pDtkW2hjzREB7JG1JdHExuHw
5aY+/piIk7FRPPwTZaTDMQ1XoDAnaw0k8DPFXyIurKZMVhsQlaZ7qjlZAW7t
GUhzYHnbC89yIcdZpOIwN+pPtbdMSxCvW+Cz6d0B2Uyt1o+wvoXNFBitQssl
RnWGnR7ChCBpN7FZoU1OQNk6O4HxFcJe0pYUjMbOCZBJdBIXuFOWLjJasrrN
zF+TO+jwrzAqFgWn0bxvdIkLGo1cFvJK18slhbSLU74QtTlXAWpYLLas1Duw
cyPcB7mhCHS9uAoaKORIzKChAYvCgnYKTal2BgMVuQp7LrphsAqT03yR7E1D
TEEMNoSXzTESaaJzZH1ArBmwMhJG6HUnjILJG8QBjJTrbcWGAgEeai8XFQQG
ytG1UYnE6vT9i8pSAxb6EnTNekB26gGsLZCMxgYeUxv78/sEhoV9npBfFYhe
6sPj6/YO9RCDFgD835uXjO/kMq+DwuVe7BHZhQzZmg5DF1N3Nhdgy9qxcxmj
MIJmxh5jtYrWp01HSTE2f0UOBjwSTURKzXl3kQA16KFzxHoBaxxZI1TkNUbN
c/NqndkSr+Zg/Pit+YgsVGP26bPmzDMKjUPjqzKRVnHiSNRVOogqi2BFbFbG
ag1f23WFx0g1cAoF1dwMMnNcnzrjzFmHcGvHJgWrNU88S4V5ZF3L4G5RVQmN
hLc6timJYAsikLDhi1LsTSx4GLbWMW7mkmoHStZA0BuAFi/V6YR2TrFrW7+F
/tZWdqZb0ry6mbpM4gbW1NwEnSVHqmH6azeWQhQbWCdxs+1Dhj5sKoWNh8Yf
LjooNrA+4SYe6A+6bWIMaKi42himmhoV1mpSuapYkRX1KSs8q1yrEZ+nRtlO
Pk+b4l4+X5/RmtGbPw4+jD/8DBrUcIh/v9K+hUvRrFmd1TWrLwxPA+rMz6Wt
5bH+52vC01Cukoh+QkR/gjWoMYcr+zrwuNpihTX3Hf9A1fN78YZu7svJo8yM
9pb/bBaKA2LR4wOwYEP2TfNHRnLMYnn1BYTezwdGYbX8w4z0c0V9qA3R3H2l
6+HwgOv4UrV/0ytQ8pdSAsaXB9a3g0l7OMQh7g4+sWBFHliAAUkVq2TZSiTh
MpFzsOXpC0+1XTozs69TLBVoo14BGq+sGLNxCg+6wUG7nCrm3tAfBpuxE/e9
TFyJHJeT6LHEtfK5bkhpta9BPv2z5MpJRYNUX2ORdxtVgFWerOdnVAKOFjQO
tM6EpsXo7+HX2wPS4ShjJ0/ZhUFXIGBypDl9YgCo928m29OZjJ6kvwZ9wnjS
V8av9xMsg5h8VlyAj8DrvTuGH7LB3qEVRstiWR0tiOV7moSspXSvCuM7i6y7
wPg0MNbg3wBSLogh9HrixXSRa++/qRSkMcO1iawC4rvXDYROR+4PdsWrl7/4
J+zY4lstDlW5iWSKh23WwGH6Huz2sG8mYNj9ByusmfURS83IITRH8GiKNouv
NM7xOkN7AZNz9xsGoB39h37F+VqOuvQVPp2qyz6miqrMRQLNfAxLCEvKfCA3
J7CsctG2TbzkAN7pdpfnPptwGmmmqF4Z6MnXyIhCG9SJo5kijcrnLpziS64/
47rVJRmtaScXpFNhLmK5QEXM+Ha1mVCdINUtGWjPGxc4es7ZDNoZbv14noE+
i+hOG0IbbLKUdFmyvFyFI4N3IDcGwTLcOar8aJlQBSkXbARzsvYCZY45NoCh
8cimnCy9K2ZWxtTTqATdHp4NldWqROrwClksCcAXcuAYnLygBzRdEOoEhcUx
rhWaJJwoM+2Zva46MbpUBB8UaPIxEAI1Mi2ymjwfGBgkCeRDUEP0CpIRlwDX
CpIfIilNRARM5bYJDOlWOJOtClVBogt16k1qszJolfStiUO9ujwybl0j/Yx7
f9WlDstT0gECtnh1vbHMz3L3fN9UEprtYXxjrpPp2iwhKsZUKVzmU7G+WoNH
1q53undhkeYcybTpJHiJTlOIubL9Hd0St6BjkBvnw/7+oO0q3bQxFjogw0lf
/EECpZKE5BMz9UJhfG+La2+LQWOSk3MA6wauQyDXFFzFFZfBzRTXiVu57MgZ
nWTQvR1tm7rqOzvmkNTozfisQxjQYYRBf0cf8b63bp6dfS1M9F8nnaOuu2t8
ClYp3TV+u7jLOzwDnIKOCTMBouutQoRPvNh9NSj3XMc/gCBtpVmCnmqXFQI5
/2rsn+++MXn8ZM3GuqRvXqhFTn5SvggBWTDx5nUldG3qbSUE4i06HxsKw1Wl
xvgJtJZG3Lqm6ORtsh30LVpOOTC5WZzGxP03hQe1Yk7FCE1c8ntT6V+ftbZV
0Y3LyiY0wGes2hbilPjTusiQVd4auCErBujyJulmOrx4XIckd+jwakMqxIor
VHuDbNMj1UwslaQO3V896YGyHM1OrgR8a1FSjdj2gwvsLBpDR+ZqPJ3HjYwh
lsuO3mk1QW2kMGGjQVYhUw5VR18kOi3RTHHeL68GphOX9cSRvCD7rVygmpnh
JQ66dL5RRWjP66713TtTDRIQo2VU2mfEFWNRsQYZErp6kybujVjVKAgVBgRu
JTr1sRm63vHOr3oGDi6WHtgk76wxlior4TKNyJ9J5SWivGPSDSv+TVBsH+ja
X1NzPSSy+kWZgbRRJjfTK2otfT+qXRQd7zBuzn+WiHBipnO0wikntTEkgnOj
i5U0lawkG2rtvGlhuuJR6oQxSnjJvuu9Ozz8jouZNwEkY32zJfllXYJkjzlX
30KqO1pIJFJ9mJZFnjZlVoqp5pxmhJeagcH79joC2sJdQkVTyqJx/m0bwqEk
Lb4SQorrNA65KJVNbADCMN0700ynUFgGZCQKekVTl7MKfRr5ck++pA5bka64
GrfyIlErMRwbwbLASK1xpVjhYmVsClnRtYDaKPfuSyT22GZ0kCKqmZDRlvx7
SXQjnWc9N1RfYSy87PckxiGJRgkHCD8XBWB8FREsI+WFegEUt02MrCW5z0ys
EWpfT3ios4ZoXZW3riCf1G99GaTm1gkHBtz1lhyys7WNeSOb3VHtH8fHiGLI
dG4ydNc6K8yFn0zDGBvjGq6FSS6sAFvJEVdXGC+oVabWbEz/aTo2iSKUxmQH
X72+OvMvgKvGEkgJX7IWuSrI2pVDvKSLca1kVwKYLtp2J7R1k/oRa/flnvEL
Nt096g1gmoHpVGMBWv9hrXKd1kKM3gp3z3+xnkVoWfbZOySCBoplTZ05OgPv
pCFj3ahnpETh+WfP4DVMgesvrd0v5ATZMN4LLE8DwhXU+pyuh9psi6gwfMnX
2DYwk3XT2xDSs9FxAtAjIoUu0gxiHcq+bw6y0j9tOBzlYlN7w2RVQ2HUdUIg
fpDleIfzJnoUVY5ywt2Y6j5wU/ax1O/wRJnh3tJNfm7G7NjBEfSFwkejF584
aTE2Jqx2WxqlY3LUgdl5MFMlLu2n7ne7/V7vP9wWNQvE0dP+7n80d+xPzc6I
eh5gj6v9PSUJhWJZRbilyHV3jidbMR27YUJffzugjpOnDZaf7j/Xe/J+IwTW
mUPPZhe72pZNainpMuwk9DJEEBPA8rQc0Ov+eBmEeRxU2MCyFX2nKd9xZZ0+
JHV42Ircrw1d12wuPput0Z8sRSTfzZBEIIDZloY1yYsoyA3er8gkx1vKQ8/e
H3ufv7KfszNDf2iyGKrGuq1bQGocf8lSV98h4QNmLvR0eYBsY0jn+61fX6/F
Np+euaR+ZdbB2EnDjF1AytwmJrmEP8PLToXRpINvDjj5vXblIF9K6DVYezkh
38bntWy6la81Qhek5k3sQS+0ezFN/DyignOYkFS3vB3LV67aC8ApnYzB64rV
rgVyoiu8UZZISybIYR7fsZ444NlMbLUV7ZoKQ3ZRK59rGSS6qiDplPOc+DrW
JKW6bdSZ37V8TOc8aXdB9vrBuuJIc0gOi9m4JErInumI7lIHKirNCvINxJFJ
w0GgRxyOwBsrCeLcISdKriPYwmS0G4bAqcHOyq91fSdzNgEQxDVjc6226tCU
GpcGQUk3hkgqfccmE+wK8h+pLEpDB1slX2plDl3jRJ6t31OsguPW52Qc4O7X
hTvWWWG/Om8PesP0aBvJnJxpD4ZjRpV6lZqHdS6OTnw5Ukt+XOGJ6IK1DLTr
whZknzVyB3aOZlX/oX99fINar7VXvHmw9UT8JWUcDpF4cwJTZwPZk1cE99IY
dQTMXHKpvnLKMjXFiejv21SryjYFM5rtHewgMNf/oguKzidtDJ+DKjWj++QD
mbgbLMJqrxypuRyOOzPMngyBgXGkpuEYAfqYB/t9rrr1UpkkR/IM2YU3scRb
pE6j/FiojcIzHkHnfNzLOFiOotkMN6O5pXnnKdoQKpFUY9iG+FyOHJbU0xcU
2dR6He81V43iVdqlBFFRKIVq851v++Cf5nRuqi+L0Q5kfRd80wh2Ks6lZuiP
fbF8iKGj3P24dH7CBcANzohqpgDJXRTCb5l32y4pm6E53mqIWZ9O4OgPpYoh
jleiPbkJqXixG46T5J7Y9Nwq5DzTvQWV3uoUgMh9urM9sMbdH7wLXzJVvaIJ
oTw5PDtchdAZmC4u4gU8vAAGwdYYxGiLa0OBmdJ5cCDz76q2LG1eBIKRdhjc
JOkd0NMVv+e9KEsQD7Dr79IS9PI4utGGr0xusMgLXSn4vAQVg13Nt5HSNwrW
YypuF5S5mpVcj4ttajwOXl7pTaej7PYS7hRd/f5f//1/MEqAZj4eh8VUKh8O
enCkyiIPAPpLFaubdE4PR0Cr8QGOho27U2j8U8Hvu1ijGH7+8w+djvjzxeGr
s6Pzt2fiYnQ8uhidDUeTVusmk3PU180VOzC0vewpb10XxSI/2Nq6ArItp12Y
2hasYbplvupks2CwN9h/dMOtaZxOt+ag46hsywy5FcL+KTqRKmagbIPGTWUn
O+/edec3IczRdD6P1E03ibcGvf4e9JEF11u93a05HlDu5MukkO86Zmm2QLvS
dwbRQWtQ7j6Il5eXeFnoMD2E/8DfmHwBfw+6vV34m048pKHq6DIF+oiDKVoQ
1VJlK02ROZrxHPpIozzj/NRb70X1TnqNBbxT3SSz1hojD+7vk3vFNG51Oj+2
/j+sUXyNjZgAAA==

-->

</rfc>
