<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.0.2) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schmutzer-bess-bitstream-vpws-signalling-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <front>
    <title abbrev="Bitstream EVPN-VPWS">Ethernet VPN Signalling Extensions for Bit-stream VPWS</title>
    <seriesInfo name="Internet-Draft" value="draft-schmutzer-bess-bitstream-vpws-signalling-01"/>
    <author initials="S." surname="Gringeri" fullname="Steven Gringeri">
      <organization>Verizon</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>steven.gringeri@verizon.com</email>
      </address>
    </author>
    <author initials="J." surname="Whittaker" fullname="Jeremy Whittaker">
      <organization>Verizon</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>jeremy.whittaker@verizon.com</email>
      </address>
    </author>
    <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>Austria</country>
        </postal>
        <email>cschmutz@cisco.com</email>
      </address>
    </author>
    <author initials="B." surname="Vasudevan" fullname="Bharath Vasudevan">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <city>Bangalore</city>
          <country>India</country>
        </postal>
        <email>bhavasud@cisco.com</email>
      </address>
    </author>
    <author initials="P." surname="Brissette" fullname="Patrice Brissette">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <city>Ottawa</city>
          <country>Canada</country>
        </postal>
        <email>pbrisset@cisco.com</email>
      </address>
    </author>
    <date year="2024" month="April" day="18"/>
    <abstract>
      <?line 73?>

<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>
  <middle>
    <?line 78?>

<section anchor="introduction-and-motivation">
      <name>Introduction and Motivation</name>
      <t>Virtual Private Wire Service (VPWS) is a widely deployed technology for providing point-to-point (P2P) services for various layer 2 and also layer 1 technologies.  Initially VPWS were define in the Pseudowire Emulation Edge-to-Edge (PWE3) architecture <xref target="RFC3985"/> for Frame Relay, ATM, HDLC, PPP, Ethernet, TDM and SONET/SDH.</t>
      <t>How Ethernet VPWS can be signalled using Ethernet VPN has already been specified in <xref target="RFC8214"/>. This document is defining necessary signalling extension for Ethernet VPN to also support the following bit stream VPWS instance types:</t>
      <ul spacing="normal">
        <li>
          <t>TDM services using SAToP <xref target="RFC4553"/></t>
        </li>
        <li>
          <t>TDM services using CESoP <xref target="RFC5086"/></t>
        </li>
        <li>
          <t>SONET/SDH services using CEP <xref target="RFC4842"/></t>
        </li>
        <li>
          <t>Private line services using PLE <xref target="I-D.ietf-pals-ple"/></t>
        </li>
      </ul>
      <t>A generic VPWS reference model similar to the one defined in <xref target="RFC3985"/> and <xref target="I-D.ietf-pals-ple"/> is shown in <xref target="ref_model"/>. Data received from a CEs is encapsulated by PEs into the respective VPWS established between the attachment circuits of the local and remote PE and transmitted across the Packet Switched Network (PSN) using a PSN tunnel.</t>
      <figure anchor="ref_model">
        <name>VPWS Reference Model</name>
        <artwork><![CDATA[
CE1 & CE2 physical                       CE3 & CE4 physical
  interfaces                                interfaces
       |      <------- PSN tunnels ----->      |
       |    +-----------------------------+    |
       |    |                             |    |
+---+  v  +---+                         +---+  v  +---+
|CE1|-----|   |.......... VPWS1 ........|PE2|-----|CE3|
+---+     |   |                         +---+     +---+
          |PE1| packet switched network   |
+----     |   |                         +---+     +---+
|CE2|-----|   |.......... VPWS2 ........|PE3|-----|CE4|
+---+     +---+                         +---+     +---+
          ^ |                             | ^
          | +-----------------------------+ |
          |                                 |
      attachment                       attachment
       circuits                         circuits
          |                                 |
          |<------ emulated services ------>|
]]></artwork>
      </figure>
    </section>
    <section anchor="requirements-notation">
      <name>Requirements Notation</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <ul spacing="normal">
        <li>
          <t>AIS - Alarm Indication Signal</t>
        </li>
        <li>
          <t>AFI - Address Family Identifier</t>
        </li>
        <li>
          <t>ATM - Asynchronous Transfer Mode</t>
        </li>
        <li>
          <t>BGP - Border Gateway Protocol</t>
        </li>
        <li>
          <t>CBR - Constant Bit Rate</t>
        </li>
        <li>
          <t>CE - Customer Edge</t>
        </li>
        <li>
          <t>CEP - SONET/SDH Circuit Emulation over Packet</t>
        </li>
        <li>
          <t>CESoP - Structure-aware TDM Circuit Emulation Service over Packet Switched Network</t>
        </li>
        <li>
          <t>DF - Designated Forwarder</t>
        </li>
        <li>
          <t>EAD - Ethernet Auto Discovery</t>
        </li>
        <li>
          <t>FC - Fibre Channel</t>
        </li>
        <li>
          <t>EBM - Equipped Bit Mask</t>
        </li>
        <li>
          <t>EVI - EVPN Instance</t>
        </li>
        <li>
          <t>EVPN - Ethernet Virtual Private Network</t>
        </li>
        <li>
          <t>HDLC - High-level Data Link Control</t>
        </li>
        <li>
          <t>LDP - Label Distribution Protocol</t>
        </li>
        <li>
          <t>MPLS - Multi Protocol Label Switching</t>
        </li>
        <li>
          <t>MTU - Maximum Transmission Unit</t>
        </li>
        <li>
          <t>NDF - Non-Designated Forwarder</t>
        </li>
        <li>
          <t>NLRI - Network Layer Reachability Information</t>
        </li>
        <li>
          <t>OC - Optical Carrier</t>
        </li>
        <li>
          <t>ODUk - Optical Data Unit k</t>
        </li>
        <li>
          <t>PDH - Plesynchronous Digital Hierarchy</t>
        </li>
        <li>
          <t>PE - Provider Edge</t>
        </li>
        <li>
          <t>PLE - Private Line Emulation</t>
        </li>
        <li>
          <t>PPP - Point-to-Point Protocol</t>
        </li>
        <li>
          <t>PSN - Packet Switched Network</t>
        </li>
        <li>
          <t>PW - Pseudo Wire</t>
        </li>
        <li>
          <t>PWE3 - Pseudowire Emulation Edge-to-Edge</t>
        </li>
        <li>
          <t>P2P - Point-to-Point</t>
        </li>
        <li>
          <t>RTP - Realtime Transport Protocol</t>
        </li>
        <li>
          <t>SAFI - Subsequent Address Family Identifier</t>
        </li>
        <li>
          <t>SAToP - Structure Agnostic TDM over Packet</t>
        </li>
        <li>
          <t>SDH - Synchronous Digital Hierarchy</t>
        </li>
        <li>
          <t>SONET - Synchronous Optical Network</t>
        </li>
        <li>
          <t>SRv6 - Segment Routing over IPv6 Dataplane</t>
        </li>
        <li>
          <t>STM - Synchronous Transport Module</t>
        </li>
        <li>
          <t>STS - Synchronous Transport Signal</t>
        </li>
        <li>
          <t>TDM - Time Division Multiplexing</t>
        </li>
        <li>
          <t>TLV - Type Length Value</t>
        </li>
        <li>
          <t>UNE - Unequipped</t>
        </li>
        <li>
          <t>VC - Virtual Circuit</t>
        </li>
        <li>
          <t>VPWS - Virtual Private Wire Service</t>
        </li>
        <li>
          <t>VT - Virtual Tributary</t>
        </li>
      </ul>
    </section>
    <section anchor="solution-requirements">
      <name>Solution Requirements</name>
      <t>To avoid redefining PW types for <xref target="RFC8214"/> the notion of "PW type" from <xref target="RFC8077"/> is maintained and only a new PW type for <xref target="I-D.ietf-pals-ple"/> has been assigned by IANA.</t>
      <ul spacing="normal">
        <li>
          <t>TBD1 - Private Line Emulation (PLE) over Packet</t>
        </li>
      </ul>
      <t>The concept of "CEP type" from <xref target="RFC5287"/> to distinguish different connection types that use the same PW type is adopted.  In this document it is referred to as "PLE/CEP type".  Two new connection types are defined <xref target="ple_cep_options"/>.</t>
      <t>To unambiguously identify the rate of an attachment circuit, also the concept of "CEP/TDM bit-rate" from <xref target="RFC5287"/> is adopted and called "PLE/CEP/TDM bit-rate" herein.</t>
      <t>The VPWS signalling requirements are as follows:</t>
      <ul spacing="normal">
        <li>
          <t>Implementations MUST support MPLS as underlay PSN</t>
        </li>
        <li>
          <t>The VPWS instance MAY be signalled as SRv6 overlay service per <xref target="RFC9252"/> leveraging on <xref target="RFC8986"/> using the End.DX2 function.  In such case, the implementation MUST support SRv6 as underlay PSN.</t>
        </li>
        <li>
          <t>The use of control word MUST be signalled, as defined in <xref target="RFC4553"/>, <xref target="RFC5086"/>, <xref target="RFC4842"/> and <xref target="I-D.ietf-pals-ple"/>.</t>
        </li>
        <li>
          <t>The PW type MUST be signalled and the PE nodes MUST validate that the PW type is identical on both endpoint.</t>
        </li>
        <li>
          <t>For CEP <xref target="RFC4842"/> and PLE <xref target="I-D.ietf-pals-ple"/>  the PLE/CEP type MUST be signalled and the PE nodes MUST validate that the PLE/CEP type is identical on both endpoints.</t>
        </li>
        <li>
          <t>The PLE/CEP/TDM bit-rate MUST be signalled if the attachment circuit can not be unambiguously identified from the PW type alone and the PE nodes MUST validate that the attachment circuit is identical on both endpoints.</t>
        </li>
        <li>
          <t>A non-default payload size MAY be signalled. Both PE nodes MUST validate that the payload size is identical on both endpoints.</t>
        </li>
        <li>
          <t>A locally configured connection identifier as defined in <xref target="endpoint_id"/> SHOULD be sent to the remote PE node. A locally configured expected identifier MAY be used to identify a misconnection by comparing it with the identifier received from the remote PE node.</t>
        </li>
        <li>
          <t>The multi-homed PE scenarios per <xref target="RFC7432"/> and <xref target="RFC8214"/> SHOULD be supported where the load-balancing mode single-active MUST be supported. Port-active load-balancing mode MAY also be supported.</t>
        </li>
        <li>
          <t>Multi-homed PE scenarios non-revertive mode MUST and revertive mode SHOULD be supported in compliance to <xref target="I-D.ietf-bess-evpn-pref-df"/>.</t>
        </li>
      </ul>
    </section>
    <section anchor="service_types">
      <name>Service Types</name>
      <t>The following sections list all possible service types that are supported by the proposed signalling mechanisms.</t>
      <section anchor="ethernet_types">
        <name>Ethernet Service Types</name>
        <table anchor="ethernet_service_table">
          <name>Ethernet Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">Encapsulation Standard</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1000Base-X</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">1,250,000</td>
            </tr>
            <tr>
              <td align="left">10GBASE-R</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">10,312,500</td>
            </tr>
            <tr>
              <td align="left">25GBASE-R</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">25,791,300</td>
            </tr>
            <tr>
              <td align="left">40GBASE-R</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">41,250,000</td>
            </tr>
            <tr>
              <td align="left">50GBASE-R</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">51,562,500</td>
            </tr>
            <tr>
              <td align="left">100GBASE-R</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">103,125,000</td>
            </tr>
            <tr>
              <td align="left">200GBASE-R</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">212,500,000</td>
            </tr>
            <tr>
              <td align="left">400GBASE-R</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">425,000,000</td>
            </tr>
          </tbody>
        </table>
        <!--
50GE has 4 lanes of 12,890625 Gb/s per clause 133.1.4 of IEEE802.3
200GE has 8 lanes of 26,5625 Gb/s per clause 119.1.4 of IEEE802.3
400GE has 16 lanes of 26,5625 Gb/s per clause 119.1.4 of IEEE802.3
-->

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

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

</section>
      <section anchor="otn_types">
        <name>OTN Service Types</name>
        <table anchor="otn_service_table">
          <name>OTN Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">Encapsulation Standard</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ODU0</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">1,244,160</td>
            </tr>
            <tr>
              <td align="left">ODU1</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">2,498,775</td>
            </tr>
            <tr>
              <td align="left">ODU2</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">10,037,273</td>
            </tr>
            <tr>
              <td align="left">ODU2e</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">10,399,525</td>
            </tr>
            <tr>
              <td align="left">ODU3</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">40,319,218</td>
            </tr>
            <tr>
              <td align="left">ODU4</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x4</td>
              <td align="left">104,794,445</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="tdm_types">
        <name>TDM Service Types</name>
        <table anchor="tdm_service_table">
          <name>TDM Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">Encapsulation Standard</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">CESoPSN basic mode</td>
              <td align="left">
                <xref target="RFC5086"/></td>
              <td align="left">0x0015</td>
              <td align="left">N/A</td>
              <td align="left">N</td>
            </tr>
            <tr>
              <td align="left">CESoPSN with CAS</td>
              <td align="left">
                <xref target="RFC5086"/></td>
              <td align="left">0x0017</td>
              <td align="left">N/A</td>
              <td align="left">N</td>
            </tr>
            <tr>
              <td align="left">E1</td>
              <td align="left">
                <xref target="RFC4553"/></td>
              <td align="left">0x0011</td>
              <td align="left">N/A</td>
              <td align="left">32</td>
            </tr>
            <tr>
              <td align="left">DS1</td>
              <td align="left">
                <xref target="RFC4553"/></td>
              <td align="left">0x0012</td>
              <td align="left">N/A</td>
              <td align="left">24</td>
            </tr>
            <tr>
              <td align="left">DS1 octet-aligned</td>
              <td align="left">
                <xref target="RFC4553"/></td>
              <td align="left">0x0012</td>
              <td align="left">N/A</td>
              <td align="left">25</td>
            </tr>
            <tr>
              <td align="left">E3</td>
              <td align="left">
                <xref target="RFC4553"/></td>
              <td align="left">0x0013</td>
              <td align="left">N/A</td>
              <td align="left">535</td>
            </tr>
            <tr>
              <td align="left">T3</td>
              <td align="left">
                <xref target="RFC4553"/></td>
              <td align="left">0x0014</td>
              <td align="left">N/A</td>
              <td align="left">699</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="sonet_sdh_types">
        <name>SONET/SDH Service Types</name>
        <table anchor="sonet_sdh_service_table">
          <name>Ethernet Service Types</name>
          <thead>
            <tr>
              <th align="left">Service Type</th>
              <th align="left">Encapsulation Standard</th>
              <th align="left">PW Type</th>
              <th align="left">PLE/CEP Type</th>
              <th align="left">PLE/CEP/TDM Bit-rate</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">VT1.5/VC-11</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x1</td>
              <td align="left">26</td>
            </tr>
            <tr>
              <td align="left">VT2/VC-12</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x1</td>
              <td align="left">35</td>
            </tr>
            <tr>
              <td align="left">VT3</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x1</td>
              <td align="left">53</td>
            </tr>
            <tr>
              <td align="left">VT6/VC-2</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x1</td>
              <td align="left">107</td>
            </tr>
            <tr>
              <td align="left">STS-Nc</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x0</td>
              <td align="left">783*N</td>
            </tr>
            <tr>
              <td align="left">VC-4-Mc</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x0</td>
              <td align="left">783<em>3</em>M</td>
            </tr>
            <tr>
              <td align="left">Fract. STS1/VC-3</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x2</td>
              <td align="left">783</td>
            </tr>
            <tr>
              <td align="left">Fract. VC-4</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x2</td>
              <td align="left">783*4</td>
            </tr>
            <tr>
              <td align="left">Async STS1/VC-3</td>
              <td align="left">
                <xref target="RFC4842"/></td>
              <td align="left">0x0010</td>
              <td align="left">0x2</td>
              <td align="left">783</td>
            </tr>
            <tr>
              <td align="left">OC3/STM1</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">155,520</td>
            </tr>
            <tr>
              <td align="left">OC12/STM4</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">622,080</td>
            </tr>
            <tr>
              <td align="left">OC48/STM16</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">2,488,320</td>
            </tr>
            <tr>
              <td align="left">OC192/STM64</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">9,953,280</td>
            </tr>
            <tr>
              <td align="left">OC768/STM256</td>
              <td align="left">
                <xref target="I-D.ietf-pals-ple"/></td>
              <td align="left">TBD1</td>
              <td align="left">0x3</td>
              <td align="left">39,813,120</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="reuse-of-existing-bgp-evpn-vpws-capabilities">
      <name>Reuse of existing BGP EVPN-VPWS Capabilities</name>
      <t>A PLE VPWS instance is identified by a pair of per-EVI ethernet A-D routes advertised by two PE nodes establishing the VPWS in accordance to <xref target="RFC8214"/>.</t>
      <t>The EVPN layer 2 attribute extended community defined in <xref target="RFC8214"/> MUST be supported and added to the per-EVI ethernet A-D route.</t>
      <ul spacing="normal">
        <li>
          <t>C bit set to 1 to indicate Control Word MUST be present.</t>
        </li>
        <li>
          <t>P and B bits are set by dual-homing PEs as per <xref target="RFC8214"/> and
<xref target="I-D.ietf-bess-evpn-pref-df"/></t>
        </li>
        <li>
          <t>L2 MTU MUST be set to zero and ignored by the receiver</t>
        </li>
      </ul>
    </section>
    <section anchor="bitstream_attribute">
      <name>BGP Bitstream Attribute</name>
      <t>To exchange and validate bit-stream specific attachment circuit parameters during the VPWS setup, a new BGP path attribute called "BGP Bitstream attribute" is defined.</t>
      <t>The BGP bitstream attribute is an optional and transitive BGP path attribute with the attribute type codepoint TBD2.</t>
      <t>The BGP Bitstream attribute can only be attached to Ethernet Auto-Discovery (A-D) routes (Route type 1) defined in <xref target="RFC7432"/>. The usage for other route types and Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations is not allow unless specified in future specifications.</t>
      <t>The format is defined as a set of Type/Length/Value (TLV) triplets, described in the following sections and listed in <xref target="bitstream_attribute_table"/>. This attribute SHOULD only be included with EVPN Network Layer Reachability Information (NLRI).</t>
      <table anchor="bitstream_attribute_table">
        <name>BGP Bitstream attribute TLV</name>
        <thead>
          <tr>
            <th align="left">TLV Type</th>
            <th align="left">Name</th>
            <th align="left">Length</th>
            <th align="left">Mandatory</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1</td>
            <td align="left">PW Type TLV</td>
            <td align="left">3</td>
            <td align="left">Y</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">PLE/CEP/TDM Bit-rate TLV</td>
            <td align="left">5</td>
            <td align="left">Y</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">PLE/CEP Options TLV</td>
            <td align="left">3</td>
            <td align="left">Y 1*</td>
          </tr>
          <tr>
            <td align="left">4</td>
            <td align="left">TDM Options TLV</td>
            <td align="left">13</td>
            <td align="left">Y 2*</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">PLE/CEP/TDM Payload Bytes TLV</td>
            <td align="left">3</td>
            <td align="left">N</td>
          </tr>
          <tr>
            <td align="left">6</td>
            <td align="left">Endpoint-ID TLV</td>
            <td align="left">0..80</td>
            <td align="left">N</td>
          </tr>
        </tbody>
      </table>
      <ul empty="true">
        <li>
          <t>1* PLE/CEP only</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>2* TDM only</t>
        </li>
      </ul>
      <t>For a particular PSN it is expected that the network operator will choose a common set of parameters per VPWS type, hence efficient BGP update packing as discussed in <xref section="12" sectionFormat="of" target="RFC4277"/> is expected to happen.</t>
      <section anchor="pw_type">
        <name>PW Type TLV</name>
        <t>The PW Type TLV MUST be present in the BGP bitstream attribute to signal what type of VPWS instance has to be established. Valid PW types for the mechanisms described in this document can be found in <xref target="service_types"/>.</t>
        <t>The PW Type TLV format is shown in <xref target="pw_type_format"/></t>
        <figure anchor="pw_type_format">
          <name>PW Type TLV</name>
          <artwork><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|           PW Type           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 1</t>
        <t>Length : 6</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>Reserved / R :</t>
        <ul empty="true">
          <li>
            <t>For future use.  MUST be set to ZERO and ignored by receiver.</t>
          </li>
        </ul>
        <t>PW Type :</t>
        <ul empty="true">
          <li>
            <t>A 15-bit quantity containing a value that represents the type of VPWS.  Assigned Values are specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].</t>
          </li>
        </ul>
      </section>
      <section anchor="bitrate">
        <name>PLE/CEP/TDM Bit-rate TLV</name>
        <t>The PLE/CEP/TDM Bit-rate TLV is MANDATORY but MAY be omitted if the attachment circuit type can be unambiguously derived from the PW Type carried in the PW Type TLV.  The PLE/CEP/TDM Bit-rate TLV format is shown in <xref target="bit_rate_format"/>.</t>
        <figure anchor="bit_rate_format">
          <name>PLE/CEP/TDM Bit-rate TLV</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     PLE/CEP/TDM Bit-rate                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 2</t>
        <t>Length : 8</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>Reserved :</t>
        <ul empty="true">
          <li>
            <t>8-bit field for future use.  MUST be set to ZERO and ignored by receiver.</t>
          </li>
        </ul>
        <t>PLE/CEP/TDM Bit-rate :</t>
        <ul empty="true">
          <li>
            <t>A four byte field denoting the data rate of the emulated service. Rules defined in <xref target="RFC5287"/> do apply for signalling TDM VPWS. Rules for CEP VPWS are defined in <xref target="RFC4842"/>.</t>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <ul spacing="normal">
              <li>
                <t>For PLE [PLE] the bit rate MUST be set to the data rate in units of 1-kbps of the PLE payload.</t>
              </li>
            </ul>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <ul spacing="normal">
              <li>
                <t>Guidelines for setting the bit rate for SAToP VPWS and CESoP VPWS can be found in <xref target="RFC5287"/>.  And for CEP VPWS in <xref target="RFC4842"/>.</t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="ple_cep_options">
        <name>PLE/CEP Options TLV</name>
        <t>The PLE/CEP Options TLV MUST be present when signalling CEP and PLE VPWS instances. The PLE/CPE Options TLV format is shown in <xref target="ple_cep_options_tlv_format"/>.</t>
        <figure anchor="ple_cep_options_tlv_format">
          <name>PLE/CEP Options TLV</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        PLE/CEP Options        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 3</t>
        <t>Length : 6</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>Reserved :</t>
        <ul empty="true">
          <li>
            <t>8-bit field for future use. MUST be set to ZERO and ignored by receiver.</t>
          </li>
        </ul>
        <t>PLE/CEP Options :</t>
        <ul empty="true">
          <li>
            <t>A two byte field with the format as shown in <xref target="ple_cep_options_format"/></t>
          </li>
        </ul>
        <figure anchor="ple_cep_options_format">
          <name>PLE/CEP Options</name>
          <artwork><![CDATA[
 0                                       1
 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|AIS|UNE|RTP|EBM|      Reserved [0:6]       |  PLE/CEP  | Async |
|   |   |   |   |                           |    Type   |T3 |E3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
        </figure>
        <t>AIS, UNE, RTP, EBM :</t>
        <ul empty="true">
          <li>
            <t>These bits MUST be set to zero and ignored by the receiver except for CEP VPWS.  Guidelines for CEP are defined in <xref target="RFC4842"/></t>
          </li>
        </ul>
        <t>Reserved :</t>
        <ul empty="true">
          <li>
            <t>7-bit field for future use. MUST be set to ZERO and ignored by receiver.</t>
          </li>
        </ul>
        <t>CEP/PLE Type :</t>
        <ul empty="true">
          <li>
            <t>Indicates the connection type for CEP and PLE. CEP connection types are defined in <xref target="RFC4842"/>. Two new values for PLE are defined in this document:</t>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <ul spacing="normal">
              <li>
                <t>0x3 - Basic PLE payload</t>
              </li>
            </ul>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <ul spacing="normal">
              <li>
                <t>0x4 - Byte aligned PLE payload</t>
              </li>
            </ul>
          </li>
        </ul>
        <t>Async :</t>
        <ul empty="true">
          <li>
            <t>These bits MUST be set to zero and ignored by the receiver except for CEP VPWS.  Guidelines for CEP are defined in <xref target="RFC4842"/></t>
          </li>
        </ul>
      </section>
      <section anchor="tdm_options">
        <name>TDM options TLV</name>
        <t>Whether when signalling TDM VPWS the TDM Options TLV MUST be present or MAY be omitted when signalling TDM VPWS instances is defined in <xref target="RFC5287"/>. The TDM Options TLV format is shown in <xref target="tdm_options_tlv_format"/>.</t>
        <figure anchor="tdm_options_tlv_format">
          <name>TDM Options TLV</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                         TDM Options                           |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 4</t>
        <t>Length : 16</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>Reserved :</t>
        <ul empty="true">
          <li>
            <t>8-bit field for future use. MUST be set to ZERO and ignored by receiver.</t>
          </li>
        </ul>
        <t>TDM Options :</t>
        <ul empty="true">
          <li>
            <t>A twelve byte field with the format as defined in {Section 3.8 of RFC5287}</t>
          </li>
        </ul>
      </section>
      <section anchor="payload_bytes">
        <name>PLE/CEP/TDM Payload Bytes TLV</name>
        <t>The PLE/CEP/TDM Payload Bytes TLV MAY be included if a non-default payload size is to be used. If this TLV is omitted then the default payload sizes defined in <xref target="RFC4553"/>, <xref target="RFC5086"/>, <xref target="RFC4842"/> and [PLE] MUST be assumed. The format of the PLE/CEP/TDM Payload Bytes TLV is shown in <xref target="payload_bytes_tlv_format"/>.</t>
        <figure anchor="payload_bytes_tlv_format">
          <name>PLE/CEP/TDM Payload Bytes TLV</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   PLE/CEP/TDM Payload Bytes   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 5</t>
        <t>Length : 6</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>Reserved :</t>
        <ul empty="true">
          <li>
            <t>8-bit field for future use.  MUST be set to ZERO and ignored by receiver.</t>
          </li>
        </ul>
        <t>PLE/CEP/TDM Payload Bytes :</t>
        <ul empty="true">
          <li>
            <t>A two byte field denoting the desired payload size to be used. Rules defined in <xref target="RFC5287"/> do apply for signalling TDM VPWS. Rules for CEP VPWS are defined in <xref target="RFC4842"/>.</t>
          </li>
        </ul>
      </section>
      <section anchor="endpoint_id">
        <name>Endpoint-ID TLV</name>
        <t>The Endpoint-ID TLV MAY be included to allow for misconnection detection. The Endpoint-ID TLV format is shown in <xref target="endpoint_tlv_format"/>.</t>
        <figure anchor="endpoint_tlv_format">
          <name>Endpoint-ID TLV</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
//                Endpoint Identifier (variable)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Type : 6</t>
        <t>Length : 3-83</t>
        <ul empty="true">
          <li>
            <t>The total length in octets of the value portion of the TLV.</t>
          </li>
        </ul>
        <t>Endpoint Identifier :</t>
        <ul empty="true">
          <li>
            <t>Arbitrary string of variable length from 0 to 80 octets used to describe the attachment circuit to the remote PE node.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="control-plane-operations">
      <name>Control Plane Operations</name>
      <t>The deployment model shown in figure 3 of <xref target="RFC8214"/> does equally apply to the operations defined in this document.</t>
      <section anchor="vpws-setup-and-teardown">
        <name>VPWS Setup and Teardown</name>
        <t>After an attachment circuit has been configured to be part of a VPWS instance and has not declared any local defect, the PE node announces his endpoint using a per-EVI ethernet A-D route to other PEs in the PSN via BGP.  The Ethernet Tag ID is set to the VPWS instance identifier and the BGP bitstream attribute is included to carry mandatory and optional bit-stream specific attachment circuit parameters.</t>
        <t>Both endpoints receiving the EVPN per-EVI A-D route, validate the end to end connectivity by comparing BGP bitstream attributes.  Upon successful validation, the VPWS instance comes up and traffic can flow through the PSN.  In the scenario where the validation phase fails, the remote PE reachability information is simply ignored and dismissed as a destination candidate.  The VPWS instance validation is performed as follow:</t>
        <ul spacing="normal">
          <li>
            <t>The mandatory PW type parameter MUST be identical</t>
          </li>
          <li>
            <t>The mandatory PLE/CEP/TDM Bit-rate parameter MUST be identical. This MAY be skipped if this parameter was not signalled because the attachment circuit rate can be unambiguously derived from the PW type <xref target="RFC5287"/>.</t>
          </li>
          <li>
            <t>For CEP and PLE, the mandatory CEP/PLE Type parameter signalled via the CEP/PLE Options TLV MUST be identical</t>
          </li>
          <li>
            <t>If the payload size was signalled via the optional PLE/CEP/TDM Payload Bytes TLV it MUST be identical and supported by the PE node. Else the default payload size MUST be assumed.</t>
          </li>
        </ul>
        <t>If any of the previous statements is no true or any of the signal CEP/PLE or TDM options is not supported by the PE node, the VPWS instance must stay down and a appropriate defect MUST be declared.</t>
        <t>PLE is structure agnostic for SONET/SDH service types and hence can not validate whether a mix of SONET and SDH attachment circuits are connected (by incident) via VPWS.  The detection of such
misconfiguration is the responsibility of the operator managing the CE nodes.</t>
        <t>In case of multi-homed CEs the mechanisms defined in <xref target="RFC8214"/> apply but are limited to the single-active and port-active scenarios.</t>
        <t>Whenever the VPWS instance configuration is removed, the PE node MUST withdraw its associated per-EVI ethernet A-D route.</t>
      </section>
      <section anchor="misconnection-handling">
        <name>Misconnection Handling</name>
        <t>In circuit switched networks it is a common requirement to have the ability to check if the correct two endpoints got connected via a circuit.  To confirm that the established bit-stream VPWS service is connecting the appropriate pair of attachment circuits, a Endpoint-ID string MAY be configured on each attachment circuit and communicated to the peer PE node using the Endpoint-ID TLV defined in <xref target="endpoint_id"/>.</t>
        <t>Each endpoint MAY be configured to compare the Endpoint-ID received from the peer PE node to a locally configured expected Endpoint-ID and raise a fault (defect) when the IDs don't match.  When a fault is raised, the R bit in the control word must bet set to 1 (backward defect indication) for the VPWS packets sent to the peer PE node. Each endpoint MAY be configured to only compare and report mismatches, but not to raise a fault.</t>
      </section>
      <section anchor="failure-scenarios">
        <name>Failure Scenarios</name>
        <section anchor="single-homed-ces">
          <name>Single-homed CEs</name>
          <t>Whenever a attachment circuit does declare a local fault the following operations MUST happen:</t>
          <ul spacing="normal">
            <li>
              <t>Operations defined in <xref target="RFC4553"/>, <xref target="RFC5086"/>, <xref target="RFC4842"/> and <xref target="I-D.ietf-pals-ple"/> MUST happen</t>
            </li>
            <li>
              <t>The per-EVI ethernet A-D route MAY be withdrawn</t>
            </li>
          </ul>
          <t>Whenever the CE-bound IWF does enter packet loss state the operations defined in <xref target="RFC4553"/>, <xref target="RFC5086"/>, <xref target="RFC4842"/> and <xref target="I-D.ietf-pals-ple"/> MUST happen.</t>
        </section>
        <section anchor="multi-homed-ces">
          <name>Multi-homed CEs</name>
          <t><xref target="multi_homed_ce_diagram"/> demonstrates a multi-homing scenario. CE1 is connected to PE1 and PE2 where PE1 is the designated forwarder while PE2 is the non designated forwarder.</t>
          <figure anchor="multi_homed_ce_diagram">
            <name>EVPN-VPWS Multi-homing Redundancy</name>
            <artwork><![CDATA[
                    PSN
                 +---------+
    DF  +---+    |         |   +---+   +---+
     +--|PE1|----|---------|---|PE3|---|CE2|
+---+/   +---+    |   VPWS1/|   +---+   +---+
|CE1|             |       / |
+---+\   +---+    |      /  |
     +--|PE2|----|-----+   |
   NDF  +---+    |         |
                 +---------+
]]></artwork>
          </figure>
          <t>In <xref target="multi_homed_ce_diagram"/> PE1 and PE2 are configured for single-active load-balancing mode.  Both PEs are advertising a per-ES ethernet A-D route with the same non-zero Ethernet Segment (ES) value and the single-active bit set. This non-zero ES value is called Ethernet Segment Identifier (ESI).</t>
          <t>In this example PE1 is elected as Designated Forwarder (DF) for the shared ESI where as PE2 is the Non-Designated Forwarder (NDF) for that segment. The signalling of primary / backup follows exactly the procedure defined in <xref target="RFC8214"/> where P and B bits of the layer 2 attribute extended community are used to settle proper connectivity.</t>
          <t>Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN Ethernet Segment DF Election procedures described in <xref target="RFC8214"/> and <xref target="I-D.ietf-bess-evpn-pref-df"/> for EVPN-VPWS.  PE1 leverage mass-withdraw mechanism to tell PE3 to steer traffic over backup connectivity.  The per-EVI ethernet A-D route advertisement remains intact. The main purpose is to keep reachability information available for fast convergence purpose. Therefore, the per-EVI ethernet A-D route MAY be withdrawn only under local fault and MUST be withdraw when the circuit is unconfigured.</t>
          <t>Port-active operation happens in the same way as single-active load-balancing mode described before but at the port level instead of being at the sub-interface level.</t>
        </section>
      </section>
    </section>
    <section anchor="mandatory-control-word">
      <name>Mandatory Control Word</name>
      <t>Both <xref section="18" sectionFormat="of" target="RFC7432"/> and <xref section="3.1" sectionFormat="of" target="RFC8214"/> do provide guidance on when the use of control should be signalled.</t>
      <t>As the bit-stream VPWS types signalled via the mechanisms described in this document mandate a control word to be present, the use of control word MUST always be signalled independent of the underlying PSN characteristics.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The same Security Considerations described in <xref target="RFC8214"/> are valid for this document.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document defines a new BGP path attribute known as the "BGP bitstream attribute".  IANA is requested to assign the codepoint TBD2 in the "BGP Path Attributes" registry to the BGP bitstream attribute.</t>
      <t>This document defines a new PW Type for PLE VPWS. IANA is requested to assign the PW type value TBD1 to PLE in the "MPLS Pseudowire Types" registry.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>to be added</t>
      <!-- KRAMNDOWN REFERENCES

kramdown examples

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

Example table:

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

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

Example references:

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

-->

</section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC4277">
          <front>
            <title>Experience with the BGP-4 Protocol</title>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).</t>
              <t>This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4277"/>
          <seriesInfo name="DOI" value="10.17487/RFC4277"/>
        </reference>
        <reference anchor="RFC5287">
          <front>
            <title>Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks</title>
            <author fullname="A. Vainshtein" initials="A." surname="Vainshtein"/>
            <author fullname="Y(J). Stein" surname="Y(J). Stein"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5287"/>
          <seriesInfo name="DOI" value="10.17487/RFC5287"/>
        </reference>
        <reference anchor="RFC8214">
          <front>
            <title>Virtual Private Wire Service Support in Ethernet VPN</title>
            <author fullname="S. Boutros" initials="S." surname="Boutros"/>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <author fullname="S. Salam" initials="S." surname="Salam"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="August" year="2017"/>
            <abstract>
              <t>This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8214"/>
          <seriesInfo name="DOI" value="10.17487/RFC8214"/>
        </reference>
        <reference anchor="RFC4553">
          <front>
            <title>Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)</title>
            <author fullname="A. Vainshtein" initials="A." role="editor" surname="Vainshtein"/>
            <author fullname="YJ. Stein" initials="YJ." role="editor" surname="Stein"/>
            <date month="June" year="2006"/>
            <abstract>
              <t>This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4553"/>
          <seriesInfo name="DOI" value="10.17487/RFC4553"/>
        </reference>
        <reference anchor="RFC5086">
          <front>
            <title>Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)</title>
            <author fullname="A. Vainshtein" initials="A." role="editor" surname="Vainshtein"/>
            <author fullname="I. Sasson" initials="I." surname="Sasson"/>
            <author fullname="E. Metz" initials="E." surname="Metz"/>
            <author fullname="T. Frost" initials="T." surname="Frost"/>
            <author fullname="P. Pate" initials="P." surname="Pate"/>
            <date month="December" year="2007"/>
            <abstract>
              <t>This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5086"/>
          <seriesInfo name="DOI" value="10.17487/RFC5086"/>
        </reference>
        <reference anchor="RFC4842">
          <front>
            <title>Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)</title>
            <author fullname="A. Malis" initials="A." surname="Malis"/>
            <author fullname="P. Pate" initials="P." surname="Pate"/>
            <author fullname="R. Cohen" initials="R." role="editor" surname="Cohen"/>
            <author fullname="D. Zelig" initials="D." surname="Zelig"/>
            <date month="April" year="2007"/>
            <abstract>
              <t>This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4842"/>
          <seriesInfo name="DOI" value="10.17487/RFC4842"/>
        </reference>
        <reference anchor="I-D.ietf-pals-ple">
          <front>
            <title>Private Line Emulation over Packet Switched Networks</title>
            <author fullname="Steven Gringeri" initials="S." surname="Gringeri">
              <organization>Verizon</organization>
            </author>
            <author fullname="Jeremy Whittaker" initials="J." surname="Whittaker">
              <organization>Verizon</organization>
            </author>
            <author fullname="Nicolai Leymann" initials="N." surname="Leymann">
              <organization>Deutsche Telekom</organization>
            </author>
            <author fullname="Christian Schmutzer" initials="C." surname="Schmutzer">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Chris Brown" initials="C." surname="Brown">
              <organization>Ciena Corporation</organization>
            </author>
            <date day="21" month="October" year="2023"/>
            <abstract>
              <t>   This document describes a method for encapsulating high-speed bit-
   streams as virtual private wire services (VPWS) over packet switched
   networks (PSN) providing complete signal transport transparency.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pals-ple-01"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9252">
          <front>
            <title>BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)</title>
            <author fullname="G. Dawra" initials="G." role="editor" surname="Dawra"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="July" year="2022"/>
            <abstract>
              <t>This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9252"/>
          <seriesInfo name="DOI" value="10.17487/RFC9252"/>
        </reference>
        <reference anchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <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>
        <reference anchor="I-D.ietf-bess-evpn-pref-df">
          <front>
            <title>Preference-based EVPN DF Election</title>
            <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
              <organization>Nokia</organization>
            </author>
            <author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
              <organization>Nokia</organization>
            </author>
            <author fullname="Wen Lin" initials="W." surname="Lin">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="John Drake" initials="J." surname="Drake">
              <organization>Independent</organization>
            </author>
            <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
              <organization>Cisco Systems</organization>
            </author>
            <date day="9" month="October" year="2023"/>
            <abstract>
              <t>   The Designated Forwarder (DF) in Ethernet Virtual Private Networks
   (EVPN) is defined as the Provider Edge (PE) router responsible for
   sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a
   multi-homed device/network in the case of an all-active multi-homing
   Ethernet Segment (ES), or BUM and unicast in the case of single-
   active multi-homing.  The Designated Forwarder is selected out of a
   candidate list of PEs that advertise the same Ethernet Segment
   Identifier (ESI) to the EVPN network, according to the Default
   Designated Forwarder Election algorithm.  While the Default Algorithm
   provides an efficient and automated way of selecting the Designated
   Forwarder across different Ethernet Tags in the Ethernet Segment,
   there are some use cases where a more 'deterministic' and user-
   controlled method is required.  At the same time, Network Operators
   require an easy way to force an on-demand Designated Forwarder
   switchover in order to carry out some maintenance tasks on the
   existing Designated Forwarder or control whether a new active PE can
   preempt the existing Designated Forwarder PE.

   This document proposes a Designated Forwarder Election algorithm that
   meets the requirements of determinism and operation control.  This
   document updates RFC8584 by modifying the definition of the DF
   Election Extended Community.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-pref-df-13"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC3985">
          <front>
            <title>Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</title>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <author fullname="P. Pate" initials="P." role="editor" surname="Pate"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3985"/>
          <seriesInfo name="DOI" value="10.17487/RFC3985"/>
        </reference>
        <reference anchor="RFC8077">
          <front>
            <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/>
            <date month="February" year="2017"/>
            <abstract>
              <t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.</t>
              <t>This document is a rewrite of RFC 4447 for publication as an Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="84"/>
          <seriesInfo name="RFC" value="8077"/>
          <seriesInfo name="DOI" value="10.17487/RFC8077"/>
        </reference>
        <reference anchor="RFC1925">
          <front>
            <title>The Twelve Networking Truths</title>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="April" year="1996"/>
            <abstract>
              <t>This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1925"/>
          <seriesInfo name="DOI" value="10.17487/RFC1925"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+09a3PbRpLf+Svm7Ko7O+ETJPWq3dxSEhVrTw+eSNu7l8u6
QGAo4gQCDABKVizfb79+zAwGIEhJtpPdulqlFFPAPLp7evo1Pc1Go1HzYj+I
rg/EKps19mq1LMhCeSCG2VwmkczEu9GFGAfXkRuG0EwMP2YySoM4SsUsTsRh
kDXSLJHuAhq+H9fc6TSRtwf4XD0ewgANeufHXuQuYGw/cWfQzZsvVtmvMmlM
ZZo2prpH43Z5lzZSM2Wj3al5biav4+T+QKSZXwuWyYHIklWaOe32ftup1dLM
jfwPbhhHMPy9TGvL4ED8lMVeXaRxAsPOUvh0v+APXrxYyChLf67V3FU2j5OD
mhAN+BUiiNIDMW6KHxOYWSYBPWSox5m8lVHxTZwA4d7BX7/GET14iTjI7EAN
99ILsvv8j9iX+g8vXkUZIvR2POC3yzlBz6/lwg1CxBbnbF6rOf90y1M1AYMi
yH9uivfzIMvcG5lYMP9ZJnJxX3r1WwP9PzRp805Puhnqo6YYay6woD6aJ0Ga
BW5UekuAHwWpF4vxPZBmAWt5GnlNepnEyLbSD7I4+UKsBsBRSeBuxsxTPPsn
D4FYx+ewKd656cqXt25k4XM4dxM3m5febcWmBDzDfuhG18DjidyCw2nkb8Ng
OndvEYpNGIya4hCIn8oskxYGIxcI48nSu+djcAkcceduAf/IjVx/C/zLKUNg
wV+rBRGIooWbBbfyoFaL8s9CXJ0c9ZzdXfWx7+zBx1qj0RDuFOBzvaxWm8yD
VIBsWqFMEOlSesEskKkAASgW0pu7UZAu4M9YgDyK70js+fdAl8ATuZQS8Uy8
C5Js5YZilAS3ILDE+yCRYiyTWyBdKl6hEHwtPDdJ7rHDNBedPEwqYtgpQGvv
BuTu+C7IvLn0xYXM7uLkBgYYjS9eN2sM/yLw/VDCHy+B5FkS+ysvA6ksQA6K
8zhDAODPWm0bTBokwN8Vd4Evw3vhy2UY38O0GaAexWF8fU8YL5P4NkBFIZZx
EGWNLG7QB4DKGb0WqcYS2966SRCvUhG694CPQzABerF60MnHBjo3BSAQwG4P
YXaER9yB/AA4ZkEkgSlpHUapXPnxHcI+XKxCwk0M/WuJcOC/AMb7Yfe1cBMP
xI70shU0/fTp32HRu/t7/c+fCbCTBLhZXEmAoy4Gk/O6eHN8dlQXo9GobjRe
XUyOzwnm8eXFcNIaH78Bor+Blbd0IoDpgXyaSs0CQLFVSgrSVpxzF0gbwhr7
99AWtIdmLx8x+/TpXwC+PafT+/y5KYp8iJ+RBDhkJIGyqZvc2/wmtSImzAqz
EqsCudPVcgnajyg4i5F5Fd8JS2XjvgftCdyQ3S9lCtvjOyKAWVFGazyYxCMF
ca/f737+vKHh0XBsGvbbezvc0JByvbkZda/ncGPNqyFyQKn96GyI7U8bx81A
gsWyBEwby1Biz4G4lhHoGo8RA2UPnISYLUDUhEC8RRC6CZIHKQLCRXGZWgyL
WXD1q2fBhUnn8V3EfWCODzQ6ruCxm7kwqydB+PhilsQL2FdHwxT7ABzuMkXW
hVfTezHCx5ECJZHIFyizGHIJKzINgxS3/xS2P3IOtnNBfIIGQv7wgsRbgcmE
cgdfhbEHuxzhBuUbA/FGQ/oLhFyULkATw1Cul8QpC7YNQoZljCK1K+APka2i
SIawA/4XfmpHw474V8DJEcv5fRrgnNU/R8MuNeyZhjVUMZlMZi6u5iM/ecua
evLA//yhwT8WbKmgJz+odoUO3ze2/Xy/3uFhK1jcpPY9973l8b/f2LzUrvYA
5HugmXGgh6b5oWXvCP3nw2joqHZARzOfAmAziHk7ns8CfAQziyWveqpXPVKr
rnFqfMEcAKGzGSfHxqlrcOrZOD2JhhU4/e3RxfqbTYFHeeGh0PqxH93a2pPV
P3kDPb7Zu5t+dIMvAog+q20CZpMSOUaM8osfHng/fzoQL40ME+T7/fEFyaAr
Iz3P8d2Lz2RrXMlfVqCFyX0SF3GmrIwJiJQbeS+Am/xUvDh/O568qPO/4uKS
Pl8N//Pt6dXwGD+P3wzOzswH3WL85vLt2XH+Ke95dHl+Prw45s7wVJQenQ/+
Cv+guHtxOZqcXl4Mzl6w6WCrVBdMAhC4U8nSZZlIEoqoaFMvCaasBw6PRp2e
UklOp7MPIl/p6c4u6GlxN5cRzxVHYLHwnyBS74W7XEpQLzAGqGgwD5ZBBmqj
jjOwxgAVLZtExolMFgFbV6jwBqdj0RADUE4LMuA9NnDY7aYGJ6fYwPdBU6Ti
BGxPmPrUB6zQmEioyeQcm6T3kTdP4gjtrwnKflhFWkFsc/jjCNocwiLBwx+B
L+5c0ERJDI5yTPMcHV5Bg6OYTIIMvXhxBc3o1RDfgIcUL6Az2lz8FEfMtfsR
c65lpVk2LXdA8wC6gP9OVloDHAJYGLQk1jtrQ3WbYYyjHp/AkMeSzCNc1JM4
gVF9psxwcAxvjYU0WAETHKP7AIMS+U+O4P1JMAUwjsDcB5VC3Q6RoEPgd1hX
n2hx7qY03fAdLgdGNmC52Hrix/DAmqlse1sAo90JTd8E1/NGCD5+yMbDWRDd
IPnBoCcYzo6RVmfuFBsE6J1OV0QYe9HOR2fIPuerMAvMC9WJiQXanBpO3mI7
92OwWC2YOxbgTeF4b8EExyYXRMmLOGpsoubF2RUirw2GMzLprySIOHcahODl
AUmUO4aS4TtxiYheLjMyFo7A+1EMe3n89sZ6Q/gjGIIINAJmAiUfSpuhj4Nr
3FNANpmgpU+rN0LGHJF7YjEm2okNQ/kztCQNW9H7EVJ2pH0Z+lCgKtoXjW08
N3qP78kxIa+Kn4HZ03jcXaG2zjoE+Pxqgs+BorCc4K3QMpEZb0M3ZokwXk1T
kMgo3bYKB7berV0nBtdRnALlaeOV9uiYaD9+jPC060sN9WpadBpf3e5gK3lN
UvgqBg5GfxnnPB3BO1z5ZehGRJUxibFxWYoRAUCMrULVaryxVS41EbWGmCAV
j4PbgBiddglY8h/VnpicvcM24PqIMxldU5QmXNEkby+Qhd5GUokAfPYOmVnv
ayWv6DmqzMbWCAA1m1iNJrSbXZRBL8U4Dnln2xoWFCu4crdxgFa9cQeB8chV
I8fP9iHJso9iFrsz8UI1fMGuCDs4e+3dXfZiFi4wnEvuj9FmLpiEd3oCPX6V
F4SOLTm0bopign2a08HFoElEPTzubNx94GOcDV8XeQ7tBy8GMbrMCHJUK2ug
Y/QGkYyFj+HB6HoFHhJ8npGhkuEAkeQoCNMnm7sZ+DKS6JKi668xw4iHHy9B
uFH4oWQoBOR+k/uYYCQkRhX+AqBuGbig2+QuJmqtTesmuWP56RPQ6wPg9QFm
w6g5+Im0qqvIXUyD6xXwLtA94N16z94g0gyo4EYVDl+dXftsnWAtZHcMKmH/
KsLlSNOCexy10HiVuqOtEkRNXhribiv2kNhWIKLrpirAwPGD0wVgjW9pwVNB
dqCORpC6gg6rCOR1iAbI+IKYRk9kAhJg1hUjLNCLpAnyDvZURq1YSr0R9p2+
A6iiSk3ca5IzJs6yj8EI5dsi/YaR3zz+iyNmq4iWj1khXXlzoE0qyaoTQQGV
IiYESwmTpkYF+Q5WxmNlTpYx97YxqrP5aQUh8vhKvRBEqReiJFsCFAYAzetr
k3JcYE4hgggsQ7U+t24Y+Mh6tG2yeWG3MIOiZAciTGMQkzLyKQBI84GFsBbJ
oWk2h2sET2Ftqq+B1B5mK7hpTp8Kvq8AIZhtCL1QABCkLTav3M2BDgLZtKQz
qifjVTHrE7AbwKBRA9jKBWUHTv99GLvgAQa/rm+pJngD0P8xOApjPAkCikcB
LYD/Z0AYlKOWoDQUStY2gB7oQ+ADkyhPEEFGIph4mQ5xIdTN6unkR4yp4bD5
ZAp92Jsk1o3YdcUCHQID3xRHWixdPHdDdQDm35zFQT5WMdBXAZZmtAWaHI05
+E0+vks9GWGAPLXE1m6va+3qXKFb6LPMgSHuUDSrmJ/rN6YumE4ewok+vEDp
FoJTxdFEw866dxMMziTTr6sGQBKRiil0I/dhEx7IbQlKXBqUR8GJORpZeF6F
ECw7EjsMOAodFwQGnQ3L22XUAH991vBnJOHQYFKyf0I699NLpQs+kA7+zHor
D3qnvLCpCMF0IP98GYPlMg1NgNm2GVCl5fBNWS0vkxj6YCglV4T5+RAA9fJl
7vqVoZPqhQHvodBEPIA20gFicnzxQBt8LngBkkM10VKu+CcJsEMtwB5g5E67
3T4EDdb4C7TaIH0f2Eh7EO2PXfh/p+7023Xopwb48XAwHjaunt6/Xe92nHpf
DeD0nzuA06/v7nfqXTVA79kQ9Ioo9J89QL9T7+/kKAARn0+Ebr0DiGgYnOcP
4TARzRC95w/RYwjUEBjgM8xn9oiLjK+ifdU8i/G+P/xLo1EDQg7J3O8J9NHo
wAGA3Ntv7zh98eO0xXLMC120eDrdbrPT7GGj0+FwuNd2mt0a0oHH2MvHcHaQ
3BUjdPbXR+iZETo7XzhEo/EDbdFCnGdtn86832eH/nhy9Iy92bb40nlOV6fA
j73ndO0VttPec7ruFVgYhMlzkG3X+529+m5fdd55VudevW3h230erfbqbQvj
nWdRq79b37Nxdp5FsA5sKIe7844FNqzcq1uYV29YUQPID9FIGw3Oe2AtBODP
wF8OGrm8TdL7xTQOm+DjocJ1YCu3QZNdu1N35Ys/CucjPfpjfxdQOp8uU1Gr
cdzc9X3W13SivMJA0gFJ+2etktPtaGyBWLQvcWNeTi7WtmOcRb/Lfrw8ftt+
Evw91pW9Xr2z09ZdO0/u6tR7+8Dcu33d1Xn6rECw7m7d2e2avvI5nbv7+/W+
YybuPrlvD1X7ft3p7Om+vWfM2wO13qv3en2li3BFK1l7bfn5xOklRfHKfJH5
i9+FL+i0Ynwhpm4aeGzBPhTccsK03e4AeuKiNcD/FzqS43A0GG/otlvqNuyY
hhwE0A07pmHXoZbH401NHdPU6ZmmMXhCYPaHHKt7tCOzybC7oWXXtOx3uelk
U9Oeabqzv694AFevkgfWllrzQH7AtGb2x2TY+PPfhR/eTTrNfuvdUaNjUZ+j
HQrfNn3At86O6uJQB+fRDoqU72xabmja76qmOzj240N32rvUYTwZNy68rc3x
/7t73e+YIWH0XuP8aT26351TnxPMq2viXB2Ebjs2Dne2O+KcT+nzHbM3HXl+
wWyXR93WeHL+NOFNWrrfBwmqpP5Rx8HeTxOF2HvHcertPd27t0dz7zxdadZ7
e3v1bj79Ps2/83QA9uv7/W7dMSDs7hAMoLyfPER3v77XQR9Hexb57numa0Gp
BCpEKj9yOJ+Op026uDhyl3yiGMgUc7swlFiMD5tAFIXaphjGWbpBgmOCmdPA
U1rt+ohB41gk8SrD+LxPIYlUufZ3cR7+MolXOkasJhSu58WJbwUo8sQ9DjXQ
2a9JeMz4pFZylp5Pwa/FYhXh8ehauFfFetZiNZw3SSaXinttxooCNEec2ycp
TtahABcnE0h9pize22HoZSIxqkZ9RzTbIRuJFP+AYYA8/soNMeZDB0/DFMN1
edhKQQ49a+KxqA0dZzt0Bm0wZUh/lUlMs4NyipM84KICbAlxC/JGfqlgYAj8
6aW5OPDBkP0zHbHIjxicueZoq4lp2mm3nIzpVYVZly7mimYySYEESYEdAOzV
sq7OyhCuJSZ352uuD1aKIJv3L0xuJ8XVkHmw5XS9JZ3YRIJPjlR2H+XzBRRQ
q5jaxCnzRxR1xlxrTteF/ew0RT5tBYAU2KbjwKmOQDMLFlIoGiaFQrwCNnyt
d9crPOBV03Zer3M7hzqb6ozEveZjxhiH5iH0KRogu/FMG6Y8OX0tWk86ABev
xtQatuA0iNSRVJBS7J5TuldRiD0Lybns3hge4W5NHVfE/AZrHXFbuMTPIHtQ
yLX4MLlFh8ni1eTs3WtYOjx4ztJ6MeEoqw5UIv4YrNS0q2BzFrYmdzhfQBVl
1WsYRF64QjFC7EGS6mnpG+IVZntgzvkDHZQr8+gCj1If9Hn5gzhHiyqLgRPI
97UsK+wEagN+/8rBi03GFTfsm4Zdyyi75JPTwmCd7ziigRoKxik26XAbh9v0
S3OO1FnG4T2yaz4oGzw7ZDDyEUTj9Fi9bzebqDepDeq9jYuhNd+mrQXDofr7
ARHQ+OEy4SOHMxb4TzxRQ3UGispbYdYyehN8/GMONszxjM7jjEE040LAQmMG
2jyOQcO6pHtgMRV7WpINJTmJNNxydRUPkDNg9wB3FCKxWpLUxMxRyglO8fDd
W6Wp5suxOjIBAxcGV/ct+LQ5BzQWc8yOi5psztvs8enl8o5sdxWzt9+VFJXe
LZvEJUzDsXlxR5TBYfBaRsFowCAiRzOsLGu8twP6oZhaUboAUtq0dsKAugow
i1eRokrxNAKNBCFEGb1cjFgZ5YoaH/gl6k1K1GxXZHx2Kp45Fc+60LsDb7qw
X/rA4btiT+yLZzyrfd/4yv9qKn+VcF/PZ1WixM5mxf9dSaQjUJwTlL8ahit7
Vr0Sdgbt42OYrNniOul9by0v7nP6fAAErCkMD8QObnXkhCzGjKqQn8PSk4tu
8vlvSXGgIaiyefAhjAqcZKjSElfiAIdDYaH0FdjUTVG2sP5reHVZtrC0dQUD
aqBprAH4OXgZU/yyckGBZnSminlCfCWA4SLJk0i1L/lKgb3dAISBTgwiFahs
SlvBvsB0ITEI8eg2MxdK7dQ5vNeDZgf+a6cP4U2fF+InlDW93s7PWqhs0itk
IuJfWsJsaggb8XxwcTyYXF79VYBE0cfFsbo/sTkVgI0slgLFXABfJsVDYk1s
jzIhjQVgMU5TrOUnFMCsFBuA4gdsYeSGvrEhvk5yPEdM/H8WHRXEEdVLVPnz
LWAwoqe01kb2bGAYSxA5liDa+3aCiATHHkkN2N2hTzv5awRSFSZKOoGSTaA5
POCpwMyPM+2f+XQDS+XP4YPy/YemuFqBrb/ulqgcOT/GNP6Q7zxaB/0ICQs2
7j9TCU9kW9gJf3kSF4Wfmgj0d4IkNAYwfoL//UyQIbGKKUfS5LfkaMBwGDXg
U9fGDR7GKMxwNJWWoyf5cYV3OINIwYcXdTVhzGz4grOBGXRYA07Jt+80GkPm
J0WZn1GgR34RbfUeES3J4II9DgZeKQWyIIYLbcsGH96usJcB2+u0soJZlzZz
mTkaFsastrKKIH3Iwtt/Ss7fVnKW1/vpktEyujYuW0kI2hxgyb/ub2OIPSr/
vkj8GRyU5MNIpSX4TKxHEcDdyuAld6KSt6t+Oty0o9i8C789+O3D7w787sLv
Hvzuw29lO77n9zW/tYfB6fjh7cXw4WoyehgeniuOMtT/qX2w83POwZp6Qh8N
PNT0jUb7d9MPvVM75gGPYvAU7BtgsZGHt/Iv8i6gX8fLCHW8GlKne0kHindT
yQHbZ0ZUMTSKmeO2OG+u6Q8StptVW5n/d78Z/6PqRwmfOyXqUpyqylDKuM+B
Zc3QpD+2puWXtbRJ5r9lZ2Wm1HWpT8HrP2CtiycjDXFIB8SWTtYve/gSN60+
ey20YQb9x1hNfdYeF3Q3ntXmevv9nI4e1vSyNo9YOJYCcmWlHidlx2rjcEa9
27HWks3Gmr88aaXWt5D5p8bP3/8uvtLTfwCGrxxhGww2o/y9YHjazzf1GatZ
3068qLaYepbF1PnHNZlsBIy5JMNb+YjFZMsUHcnuNvdUKJsEzHp0af0EAXwc
fvYBp0srAk3rfZQMNIczwQyPFDdd3Ah01BrvLjTF6YyVkQpbaUGazVWlkKox
vvymEXutekXcNAUF6LPcVaTMndItGJdcMJti/xTH+fvfQBxvXpfnOmAbFq0q
BrXGAJZY6f+dHLGvCEQV0an2yYrBKJkGOGRhH9ubeC0UZcItv0Uciu6nlE42
P720r1upTJZSm7KcKhRCK16b8mUm1VXKqpEqbTIDwD8lwPr7L5IApRG+r7Va
ZdLolSlkSWDZNjzDfl1q3Gp9S0OkYr1NuliRXyxxsWOJi25jr/vVEqOKALyl
EzoswlprWaLq+mnC6InoLKeNG2GvrafUVwr1KfHGk6LKG4yU4qRztEZ4wQWs
GTzLR4OGtyUX5qOxVDkzvYf4wiNwL4BayMvyY0xp+2VFNyNZnOjaZ2bwje6t
khgkWMaY8URiciLdxId5wXWdZXh7s+qOel4dwLqOyYIPExrobnvpVB7Hxl6Y
k+NLL3QTyn+7V3XNAEgQLHX7ziy8jeIV+YZzqq+mFlTXLtucK4egcL4RF2Hj
UccX4jZwMbdAnb+ZbKeJey2AI1Fs5SH6UiaidZ9VXe3dktNli1IqBykWJoOG
SjHohK9n56rBoh0WbuMqZWauvGPuj6aMIUjdvvErsTNChv9o2X6L58CFS7Eb
0MNyjm+XMV2jx6KFs1WoBweU6hWkgyGxuN9SZ7dh9gmdQ8xQx2RzgPB6rpdI
V2uQ5vapdR02n0csgZdAJ7sB1l8q7rfEznUKrFwnXF+87X9vbAGEyA+oRo5O
8YLtnakcMgTSJ6ophiniZUETUKYNzsTDcLbXgbkfbBZfXxI3C2rMFXPhuqJT
1WHZlhFUtpi+CX7D5Y0C5VDkHe/Udsyvwk+l5+pyGhVsSBM/+RCcEC3EcexC
AiqUx4uX41qIDOag5iDiFsYuumFVHKpAy9PZ+gV3xHx9SLMrH3FysvWJCJ21
C8Xm+vowVEStvrJfcrtqtdMZiUal0JaJvKVyq8B4marJQdmNWCJbYrTNaqzy
ozR54KUd8lNJkZsgrdq+i1WK5URdWGRUR5SyjLomiZegNDOpRLfBQgt3Nq5p
05maRK6uSUSHlOWKoVZeKCeq6foLRnjdqegk3ub/iBhzhSIq5QrjVFXPRJNZ
CTlA99UURYJH6/aaFl7FUlkBK+MWR8YqITU2fknBmY3OwiYFEZgGSsgo0pvk
PGBnLk3CjMqp57isEdUdwfZ2yQAsILqWilZwGVDd/6wUPKatIFJhsAiyPHO8
WBYAKbK06gCYq/xNCvFGeGe/UlSXkEWpeotVTGy9TCuNoRY/ce8EETlNYy+g
Y/itGexob5wXHIo3AGlIlZqQOErOlMtXpiov0iQ6WuVpOPXwVskstSCodufS
u9EJPV6cJMij6MzlmvM6zizWQGZwNQjIETGTI1nkaZiFsq3FwviGiQFOjZ/i
AHuz6OsLFayKCee2gazMUyXGLUMLCIAqrkpCU9kfvojguRZ3LCUZQ7x+hQI5
Bf9tc50OtKhxTmOFrYOFRCfrQa6NvV5JowAQOpxbC3zYY1HNCTegvFcWpq9Y
Ar3mUwYc/fQYzdzo38CSdoGTYDWR6U0HZGwcQfH1FSVPKDOxUM6HZN9UWlcu
Xk1d7wZr5WmxF5hqjq9NTinxA5diTQtlTWysQSs8TlBK8NZU5WobVJgIBBNh
JoFrUCCglITmBbqo/XYCNhLK3rEWAfj0pRizvDASyJILbhVnkauhZLteLUXO
Yn675XmQoOC8YLKFLiudkm9QEsmeSdtPW9wDRWotwqKSTDwaNqaUH3P6/kS5
WFhOVBfXDbHEMqniLZ7WN0aK1/JloUILLdqnT6RJPtCjD5784AfuNVhN6ByC
7I5SyotE0Wk0Dl1CUMyAJ6kdS2Qx143gGdlnQ0dZ3yNupYNeqmzkTJeNxEvo
oaT2qlVEwaL1libuU/GDZcLWHuY1fbky8PGJVTE4j6U8iPyxVUYYPlJhZKpK
bEbCT7paMVU35tP/ligNTTWbW+tDU5XnYhBHR1J0JsF/l8eil7qEL4PlWGB9
L9TLi00IbieNib5Us4MJwJjLd+c2O1xJH/gdTIB7DMmcIvtuZCubOZRxpQUW
hzJtO6Si/hAIY1WRSlWWU5f1LKd+XLVpzdkO1fnDYxQ6NrduIHL5yVfD8WsV
GNKeehEmdYVOeUn5QGPVC3cDOwZrY9vBtOGY7s3o2oLyo4uF5PROkSHvJnA0
quqsilfHJ7m+SOcUDYER1XaDXtZe2lSsVby6yEdxESmCkkOzxS+uAOtjgSGv
lkD9Bb64KuaHYHtZaOofecAIVTFmFW9SwsC+Sair0z/lYqSb5JW5MHcx5JpL
WNfFCkMAUSnAEGKp3JnSXrpI/pHhvk69wIoaIQqArC0cbKphqExOg2bpxkf5
xuNj9x35axn0hgK2RnBUXUJ0aaGDMZKNaU+WgAzBxxx2iQwZmgQ6KkIlM9UK
FUgiHlNp5soroZvgl6lE9P0DdOGa4wmA43KVYIkrddh4I+Vyc7jEvQXaU1SU
zljclKxlmOaanDM1FA0OJIkT5T0+Q++yeUPFFQsGBX3FiXInDQmNcWfVyVtF
ufRBf9PyeIxaVhrUxAFJfGBZbIoBPCKsLA6ZEo7sfqmaeWiJcW1n9KAk+POw
G6aSJBk3SVfThvmmA27LoeD8Rp19cVcF96w7V/qgulA/Lj/H7qjXJh6svsZF
iutVwLeZoZ0hXalkZTqPV6FfLBeIKUs6objg37Bzvh41edoFKo7w8F01y8BW
MWPOG6pXwZiX1XRDWLW0VLsReGeJYiYyJ9Rcq5O+gAdDvh5+NROIYvrCKS/V
peW8VYL8joXQsaq0HYcnBtnQYpvESFRIUAnkUqQdv8YHr8OUxvv0MnAj93P5
S4pYAKebryDfRBSM4aV6sSFWi0VsaVLy5H9ZyVQZeFzTV/k79sVhvUloxBFO
aS5ipy9gjGssUW4OGTZM29yOjb4Io1PwWHo+BqcOKLKOpqIFaKlihEmBTGVn
rdtFXIrAAM0rP/CQcsA617oAs1X4CJeJSyz9x9Xg/OL48v2FuBqeDK+GF0fD
ca12AxYQBcGUsofe5ito0to8y5bpQat1DRJrNcVvrmp57jRu6V6NZOY5O87+
kxu2pmE8bYEiAe5t6Slb/N16pJQ8EEgNaOTdND5+bC5u8JK+HnwRyJtmFLac
dmcHxki8eavdby3g000jvQe98LGh16cFvr2yXuiK6wHeBn4zmYzA/DyKByNd
6g7NUafZ1oV+kHMaCxCusNXUybL6ay2Xr9CUYglqvpx85CBe6G/2sr7ap/BF
DYoKGNbNvxKs0BjLIXf2nb7VmCpQ/R90SndDCXEAAA==

-->

</rfc>
