<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.0.2) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schmutzer-bess-bitstream-vpws-signalling-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <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-00"/>
    <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="2023" month="October" day="23"/>
    <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 defined in this document can be attached to EVPN VPWS routes <xref target="RFC8214"/>. The usage for other Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations is not defined herein but may be specified in future specifications.</t>
      <t>The BGP bitstream attribute is an optional and transitive BGP path attribute.  The attribute type code TBD2 has been assigned by IANA (see <xref target="iana"/>)</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 : 3</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 : 5</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 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>
        <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 : 3</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 : 13</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 : 3</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 : 0-80</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 widthdraw 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="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 attribute code type TBD2 to the BGP bitstream attribute from the "BGP Path Attributes" registry.</t>
      <t>This document defines a new PW Type for PLE VPWS.  IANA is requested to assign a PW type value TBD1 from the "MPLS Pseudowire Types" registry.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>to be added</t>
      <!-- KRAMNDOWN REFERENCES

kramdown examples

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

Example table:

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

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

Example references:

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

-->

</section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="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+09a3PiSJLf+RW17Yi7fiAeAmzs2J1bjHG392zMGbp79+Zm
O4RUGK2FxEjCbsbu++2XmfVQSQhsd/fMblyMJzwNUj0ys7LyVVlpy7IqbuT5
4fURW6Uzq1uppH4a8CM2SOc8DnnKPoyGbOxfh04QQDM2+JzyMPGjMGGzKGbH
fmolacydBTT8OK4402nMb4/wuXw8gAEseudFbugsYGwvdmbQzZ0vVukvPLam
PEmsqeph3S7vEivRU1qNRsV1Un4dxesjlqRexV/GRyyNV0lqNxqHDbtSSVIn
9D45QRTC8GueVJb+EfsxjdwqS6IYhp0l8Gm9EB/caLHgYZr8VKk4q3QexUcV
xiz4ZcwPkyM2rrG3MczMY58eCqjHKb/lYf5NFAPhPsC3X6KQHuwhDjw9ksPt
uX66zr5EHldf3GgVpojQ+3FPvF3OCXrxmi8cP0Bscc7atZzzz7diqhpgkAf5
LzX2ce6nqXPDYwPmv/CYL9aFV7820P+gSWt3atLtUPdrbKy4wIC6P4/9JPWd
sPCWAO/7iRux8RpIs4C1PAvdGr2MI2Rb7vlpFH8lVj3gqNh3tmPmSp79s4tA
bOJzXGMfnGTl8VsnNPA5njuxk84L73ZiUwBewH7shNfA4zHfgcNZ6O3CYDp3
bhGKbRiMauwYiJ/wNOUGBiMHCOPywrvnY3AJHHHn7AC/74SOtwP+5VRAYMBf
qfghiKKFk/q3/KhSCbPPjF2d9tv2wYH82LG78LFiWRZzpgCf46aVymTuJwxk
0wplAkuW3PVnPk8YCEC24O7cCf1kAV8jBvIouiOx562BLr7LMinFohn74Mfp
ygnYKPZvQWCxj37M2ZjHt0C6hL1EIfiKuU4cr7HDNBOdYpiERbBTgNbuDcjd
8Z2funPusSFP76L4BgYYjYevahUB/8L3vIDDlz0geRpH3spNQSozkIPsIkoR
APhaqeyCSYEE+Dvszvd4sGYeXwbRGqZNAfUwCqLrNWG8jKNbHxUFW0Z+mFpp
ZNEHgMoevWKJwhLb3jqxH60SFjhrwMcmmAC9SD5oZmMDnWsMEPBhtwcwO8LD
7kB+ABwzP+TAlLQOo4SvvOgOYR8sVgHhxgbeNUc48F8A4+Og9Yo5sQtih7vp
Cpre3/8HLHrrsNv58oUAO42Bm9kVBziqrDe5qLJ3J+f9KhuNRlWt8apscnJB
MI8vh4NJfXzyDoj+Dlbe0IkApgvyacoVCwDFVgkpSFNxzh0gbQBr7K2hLWgP
xV4eYnZ//weAr2s321++1FieD/EzkgCHDDlQNnHitclvXCliwiw3K7EqkDtZ
LZeg/YiCswiZV/IdM1Q27nvQnsAN6XrJE9ger4kAekUFWuPeJBpJiNudTuvL
ly0N+4OxbthpdPdFQ03KzeZ61G7bFo0VrwbIAYX2o/MBtj+zTmo+B4tlCZha
y4Bjzx675iHoGlcgBsoeOAkxW4CoCYB4Cz9wYiQPUgSEi+QyuRgGs+Dql8+C
C5PMo7tQ9IE5PtHouIInTurArC4H4eOxWRwtYF/1Bwn2ATicZYKsC6+mazbC
x6EEJebIFyizBOQcVmQa+Alu/ylsf+QcbOeA+AQNhPzh+rG7ApMJ5Q6+CiIX
djnCDco3AuKNBvQNhFyYLEATw1COG0eJEGxbhIyQMZLUDoMvLF2FIQ9gB/wv
/FT6gyb7N8DJZsv5OvFxzvKf/qBFDdu6YQVVTMrjmYOr+chP1rIinzyIf/5o
iR8DtoTRkx9ku1yHN9aunzebHR52giWaVN6Ivrdi/DdbmxfaVR6AfA80Mw70
UNM/tOxNpr4+jAa2bAd01PNJALaDmLUT8xmAj2BmthSrnqhVD+WqK5ysr5gD
ILS342SbOLU0Tm0TpyfRsASnvz+6WH83KfAoLzzkWj/2o1obe7L8J2ugxtd7
d9uPavBVANFnuU3AbJIiR4tR8eKHB7Gf74/YnpZhjHy/P70gGXSlpecFvnvx
hWyNK/7zCrQwuU9sGKXSypiASLnhawbc5CXsxcX78eRFVfzLhpf0+WrwX+/P
rgYn+Hn8rnd+rj+oFuN3l+/PT7JPWc/+5cXFYHgiOsNTVnh00fsb/IPi7sXl
aHJ2OeydvxCmg6lSHTAJQOBOuZAuy5iTUERFm7ixPxV64Lg/aralSrKbzUMQ
+VJPNw9AT7O7OQ/FXFEIFov4CiJ1zZzlkoN6gTFARYN5sPRTUBtVnEFoDFDR
vEZknPB44QvrChVe72zMLNYD5bQgA94VBo5wu6nB6Rk28DzQFAk7BdsTpj7z
ACs0JmJqMrnAJsk6dOdxFKL9NUHZD6tIK4htjt+OoM0xLBI8fAt8ceeAJooj
cJQjmqd/fAUN+hGZBCl68ewKmtGrAb4BDylaQGe0ucRTHDHT7n3BuYaVZti0
ogOaB9AF/Hey0ixwCGBh0JLY7KwM1V2GMY56cgpDnnAyj3BRT6MYRvUEZQa9
E3irLaTeCpjgBN0HGJTIf9qH96f+FMDog7kPKoW6HSNBB8DvsK4e0eLCSWi6
wQdcDoxswHIJ60k8hgfGTEXb2wAY7U5o+s6/nlsB+PiBMB7O/fAGyQ8GPcFw
foK0Onem2MBH73S6IsKYi3YxOkf2uVgFqa9fyE6CWKDNqeHkPbZzPvuL1UJw
xwK8KRzvPZjg2GRIlBxGobWNmsPzK0ReGQznZNJfcRBxztQPwMsDkkh3DCXD
a3aJiF4uUzIW+uD9SIa9PHl/Y7wh/BEMRgQaATOBkg+4ydAn/jXuKSAbj9HS
p9UbIWOOyD0xGBPtREtT/hwtSc1W9H6ElB0pX4Y+5KiK9oW1i+dGH/E9OSbk
VYlnYPZYj7sr1NbehACfX03wOVAUlhO8FVomMuNN6MZCIoxX0wQkMkq3ncJB
WO/GrmO96zBKgPK08Qp7dEy0Hz9GeNr1hYZqNQ06ja9u97EVvyYpfBUBB6O/
jHOejeAdrvwycEKiypjE2LgoxYgAIMZWgWw13toqk5qImsUmSMUT/9YnRqdd
Apb8Z7knJucfsA24Puych9cUpQlWNMn7IbLQ+5BLEYDPPiAzq30t5RU9R5Vp
7YwAULOJ0WhCu9lBGbTHxlEgdrapYUGxgit3G/lo1Wt3EBiPXDVy/Ewfkiz7
MBJid8ZeyIYvhCsiHJxu4+BAeDELBxjOIfdHazMHTMI7NYEav8wLQseWHFon
QTEhfJqz3rBXI6IenzS37j7wMc4Hr/I8h/aDG4EYXaYEOaqVDdAxeoNIRszD
8GB4vQIPCT7PyFBJcYCQiyiIoE86d1LwZTjRJUHXX2GGEQ8vWoJwo/BDwVDw
yf0m9zHGSEiEKvwFQF3XcEG3yV1E1NqY1okzx/L+Huj1CfD6BLNh1Bz8RFrV
Vegspv71CngX6O6L3boW3iDSDKjghCUOX1W49ukmwerI7hhUwv5lhMuQpgV3
RdRC4VXojraKH9bE0hB3G7GH2LQCEV0nkQEGET84WwDW+JYWPGFkB6poBKkr
6LAKQV4HaICMh8Q0aiIdkACzLh9hgV4kTZB3sKc0atmSq41waHdsQBVVauxc
k5zRcZZDDEZI3xbpNwi92slfbTZbhbR8ghWSlTsH2iScrDrm51DJY0KwFDCp
KVSQ72BlXKHMyTIWvU2MqsL8NIIQWXylmguiVHNRkh0BCg2A4vWNSUVcYE4h
ghAsQ7k+t07ge8h6tG3SeW63CAZFyQ5EmEYgJnnoUQCQ5gMLYSOSQ9NsD9cw
MYWxqb4FUnOYneAmGX1K+L4EBH+2JfRCAUCQtti8dDf7Kghk0pLOqJ6MV8ms
T8CuB4OGFrCVA8oOnP51EDngAfq/bG6pGngD0P8xOHJjPAkCikcBLYD/Z0AY
lKOGoNQUijc2gBrok+8Bk0hPEEFGIuh4mQpxIdS18un4Z4yp4bDZZBJ92Jsk
1rXYddgCHQIN3xRHWiwdPHdDdQDm31yIg2ysfKCvBCzFaAs0Oaw5+E0evktc
HmKAPDHE1kG7ZezqTKEb6AuZA0PcoWiWMT/Hs6YOmE4uwok+PEPpFoBTJaKJ
mp1V7xoYnHGqXpcNgCQiFZPrRu7DNjyQ22KUuDSoGAUnFtHI3PMyhGDZkdiB
L6LQUU5g0Nkwv12GFvjrM8ubkYRDg0nK/gnp3Ps9qQs+kQ7+IvRWFvROxMIm
LADTgfzzZQSWyzTQAWbTZkCVlsE3FWp5GUfQB0MpmSLMzocAqL29zPUrQsfl
Cw3eQ64JewBtpALE5PjigTb4XPACJIdsoqRc/isJsGMlwB5g5Gaj0TgGDWb9
FVptkb4Pwkh7YI3PLfh/s2p3GlXoJwd4e9wbD6yrp/dvVFtNu9qRA9id5w5g
d6oHh81qSw7QfjYE7TwKnWcP0GlWO/sZCkDE5xOhVW0CIgoG+/lD2IKIeoj2
84doCwjkEBjg08yn94iDjC+jfeU8i/G+P/7BsipAyAGZ+22GPhodOACQ3cPG
vt1hb6d1IcfcwEGLp9lq1Zq1NjY6GwwG3YZda1WQDmKMbjaGvY/kLhmhebg5
QluP0Nz/yiEs6wfaork4z8Y+nbm/zQ59e9p/xt5sGHxpP6ernePH9nO6tnPb
qfucrt0cC4MweQ6yjWqn2a0edGTn/Wd1blcbBr6t59GqW20YGO8/i1qdg2rX
xNl+FsGasKFs0V3sWGDD0r26g3nVhmUVgPwYjbRR76IN1oIP/gx8s9HIFdsk
WS+mUVADHw8Vrg1buQGa7NqZOiuP/YnZn+nRnzoHgNLFdJmwSkXEzR3PE/qa
TpRXGEg6Imn/rFWyW02FLRCL9iVuzMvJcGM7Rmn4m+zHy5P3jSfB3xa6st2u
NvcbqmvzyV3tavsQmPugo7raT58VCNY6qNoHLd2XP6dz6/Cw2rH1xK0n922j
aj+s2s2u6tt+xrxtUOvtarvdkboIV7SUtTeWX5w47VEUr8gXqbf4TfiCTivG
QzZ1Et8VFuxDzi0nTBuNJqDHhvUe/j/XkRyHfm+8pdtBodugqRuKIIBq2NQN
Wza1PBlva2rrpnZbN43AEwKzPxCxukc7CjYZtLa0bOmWnZZoOtnWtK2b7h8e
Sh7A1SvlgY2lVjyQHTBtmP0RGTbe/Dfhhw+TZq1T/9C3mgb1RbRD4tugD/jW
3pddbOpgP9pBkvKDScstTTst2XQfx3586GbjgDqMJ2Nr6O5sjv8/6LZeC4aE
0dvWxdN6tF5fUJ9TzKur4VxNhG43NrbobHbEOZ/S57Vgbzry/IrZLvut+nhy
8TThTVq60wEJKqV+v2lj76eJQuy9b9vVRlf1bndp7v2nK81qu9uttrLpD2n+
/acDcFg97LSqtgbhYJ9gAOX95CFah9VuE30c5Vlku++ZrgWlEsgQKf8swvl0
PK3TxVnfWYoTRZ8nmNuFocR8fFgHoijUNsUwztLxYxwTzBwLT2mV68N61gmL
o1WK8XmPQhKJdO3voiz8pROvVIxYTsgc141izwhQZIl7ItRAZ7864TEVJ7Vc
ZOl5FPxaLFYhHo9uhHtlrGcjViPyJsnkknGv7VhRgKYvcvs4xcmaFOASyQRc
nSmzj2YYehlzjKpR3xHNdiyMRIp/wDBAHm/lBBjzoYOnQYLhuixsJSGHnhX2
WNSGjrNtOoPWmApIf+FxRLODcoriLOAiA2wxcQvyRnapoKcJfL+nLw580mT/
Qkcs/DMGZ65FtFXHNM20W5GM6ZaFWZcO5oqmPE6ABHGOHQDs1bIqz8oQriUm
d2drrg5W8iDr9y90bifF1ZB5trQ0WSV/QiVzTwXcgj+IAUXeo2DzYnYphj2d
a3GqFyEDbT8yZi97p2evWP1J58vs5ZhaA4dP/VCe+PgJhcYVAuI0iQFSbOGs
ae3NRFjhSuj1EGMYtJmW0AZPs0ImTtVk5iPlOvoUbNxcFjyxExF1OQCF4zEJ
HWWcvf1Ek71MOOYS+07ofPnySkUWMcPBWEncGA5xNEgfFHN1cZxcp+Nk9nJy
/uEVAIhHz2lSzaccpeWhSkQJw5VKVpQwuhC3Ons4Q07GWelQlxKe3GCFgoTs
UWKVpyVwsJeY74FZ5w90VC4NpCEepj6oE/MHdoE2VRrFa+H9GrYVdgLFAb9/
E+GLbeaVaNjRDVuGWXYpzk5zgzVfi5gG6igYJ9+kKdrYok2nMOdInmYcr3Gf
ZIMKk2efTEZxCGGdncj3jVoNNSe1Qc23dTGU7tu2p2E4VIA/IAIKP1wmfGSL
nAXxFc/UUKGBqnJXmLeM/oQ4ANJHG/qARmVyRiCccSFgoTEHbR5FoGMd0j6w
mJI9DdmGspyEBu6GqowI8BlsQh83PSKxWpLcxNxRygpO8PjdXSWJ4suxPDQB
ExcGlzcuxHlzBmgEG2y55GFNGPQme9zvLe/IepdRe/NdQVWp3bJNKMA0IjrP
7ogyOAxezMiZDbjTRTzDyLPGmzugIfLJFYUrIIVNWyKQZ9EqlFTJn0egmcAY
K6KXiREjp1xS45N4iZqTUjUbJTmfzZJndsmzFvRuwpsW7JcOcPgB67JD9oxn
lTfWN/5XkRmshPtmRqsUJWY+K/7viiMdgeIiRfmbYbgyZ1UrYebQPj6GzpvN
r5Pa98by4j6nz0dAwIrE8AgWA7Y6ckIaYU5VIJ7D0pOTrjP6b0lxoCko83nw
IYwKnKSpUmdX7AiHQ2EhtShY1aDrCjbWfw+uLos2lrKvYEAFNI3VA08Hr2Oy
n1cO6PiUTlUxU0hcChBwkeSJudyX4lKBud0AhJ5SpKQCpVVpqv0XpF57AR7e
pvpKqZk8hzd70LbBf80EIrzr84L9iLKm3d7/SQmVbXqFjET8piTMtoawES96
w5Pe5PLqb2StyAPjSN6g2J4MIKwJIQXy2QAej/PHxIrYLuVCagvAYBxpq2wF
s1RsAIqfsIWWG+rOBvs2yfEcMfH/WXSUEIeVL1Hpz/eAQYuewlpr2bOFYQxB
ZBuCqPP9BBEJji5JDdjdgUc7+VsEUhkmUjqBko2hOTwQU4EnEqXKQwMd7eNw
uYwVoe0x66PGrlYBL8m5kjlyXoRp/IG482gc9CMcQqyJ/jOZ8ESWhZnwlyVx
UfiphiC/ZiSfMYDxI/zvJwIUSZVPOeI6v8Wji2T4EobDqIE4dbVu8DBGLgCO
JpFUk7xd4R1OP5Tw4UVdRRY9G74Q2cACdFgBkZJv3mnUZsyPkjI/oTgPvTza
8j0iWpDAOWsczLtCCmROCOfaFs09vF1hLgO2V2llOaMuqWUSczTIjVluY+VB
+pQGt7/LzV9XbhbX++ly0TC5ti5bQQSaHGBIv9avY4Y9Kv2+SvhpHKTcw0il
IfZ0TpokgLOTwQvORClvl/00RdOmZPMW/LbhtwO/+/B7AL9d+D2E39J24p7f
t/xWHnpn44f3w8HD1WT0MDi+kBylqf9j42j/p4yDFfWYOhp4qKgbjebvth96
J3fMAx7F4CnYd8BiKw/v5F/kXUC/ipcRqng1pEr3ko4k7yZcBGyfGVHF0Chm
jpvivLahP0jYbldtRf4/+G78j4ofJXzmkshLcbIqQyHjPgNWaIYafdmZll/U
0jqZ/1a4KjOprgt9cj7/kdC6eDJisWM6IDZ0snrZxpe4adXZa66NYNB/jdVU
Z+1RTnfjWW2mtz/O6ehhQy8r80gIx0I4rqjUo7joVm0dTqt3M9JasNmE5i9O
Wqr1DWR+1/jZ+9/EU3r6D8DwjSPsgsFklH8WDE/7+a4eYznrm4kX5RZT27CY
mv+6JpOJgDaXeHDLH7GYTJmi4titWlcGsknAbMaWNs8PwMcRzz7hdElJmGmz
j5SB+mjGn+GR4raLG36S82LPZkIZyaCVEqTpXFYKKRvj628aCa9VrYiTJKAA
PSF3JSkzp3QHxgUXzKTY7+I4e/8riOPt6/JcB2zLopVFoDYYwBArnX+SI/YN
Yag8OuU+2TeGonS45deIQ9H9lMK55v2eed1KZrIU2hTlVK4QWv7alMdTLq9S
lo1UapNpAH6XAJvvv0oCFEZ4U6nXi6RRK5NL48CybXiC/arQuF7/noZIyXrr
dLE8vxjiYt8QFw2r2/hmiVFGALGlYzoqwlpraSzr+inCqInoJKeBG6HbUFOq
K4XqjHjrOVHpDUZKcVI5WiO84ALWDJ7ko0EjtqUozEdjyXJmag+JC4/AvQBq
Li/LizCl7ecV3YwU4kTVPtODb3VvpcQgwTLGjCcSkxPuxB7MC67rLMXbm2V3
1LNcGuM6phB8mM5Ad9sLZ/I4NvYSSUNu4MSU/7aWdc0ASBAsVfPOLLwNoxX5
hnOqryYXVNUu254rh6CIBChRhE2MOh6yW9/BzAJ5+qaTFyfONQOORLGVhegL
mYjGfVZ5tXdH3pIpSqkcJFvo/BkqxaCSmp6dqwaLdpy7jSuVmb7yjpk/ijKa
IFXzxi/HzggZ/qNk+y2eAucuxW5BD8s5vl9GdI0eixbOVoEaHFCqlpAOhsTi
fkuVwYW5J3QOMUMdk84Bwuu5WiJVrYHr26fGddhsHrYEXgKd7PhYfym/32Iz
08k3Mp1wffG2/1rbAgiR51ONHJXgBds7lUluCKRHVJMMk8fLgManPBucSQwj
cr2O9P1gvfjqkrheUG2u6AvXJZ3Kjsp2jCBzxdRN8BtR3siXDkXW8U5ux+wq
/JS7jiqnUcKGNPGTj8AJ0VwcxywkIEN5YvEyXHORwQzUDETcwthFNSyLQ+Vo
eTbbvOCOmG8OqXflI05OujkRobNxoVhfXx8EkqjlV/YLblelcjYj0SgV2jLm
t1RuFRgvlTU5KP0SS2RzjLYZjWV2lCIPvDRDfjJrcxukZdt3sUqwnKgDi4zq
iFKWUdfE0RKUpshhBQmisVDCXRjXtOl0TSJH1SSiQ8pixVAVxkVNQWlqqv6C
Fl53MjqJt/k/I8aiQhGVcoVxyqpnoskshRyg+3KKIsGldXtFCy9jqUIBS+MW
R8YqIRVh/JKC0xs9leU8gZy+FDKS9Do1D9hZlCYRjCpSz3FZQ6o7gu3NkgFY
QHQjES3nMqC6/0kqeExaQaQCf+GnWeZ4viwAUmRp1AHQV/lrFOIN8c5+qagu
IItS9RarmJh6mVb6zvfSuRc7d4yonCSR61MtsZ0p7GhwXOQ8incAakClmpA6
UtAU61cmMi1S5zka9WlE5uGtFFpyRVDvzrl7o/J53CiOkUnRm8tU53WUGryB
3OAoEJAlIkGPeJFlYebqtuYr42suBjgVfpIFzN2i7i+U8CpmnJsWsrRPpRw3
LC0gAOq4MhFNdX/ETQTXMdhjyckaEguYq5CTc+C2F+pAkxrn1GbYJlhIdDIf
+MbYm6U0cgChx7mzwoc5FhWdcHxKexXS9KUQQa/EMQOOfnaCdm7475iNDpwE
q4lcrzsgZ+MIkrGvKHtC2om5ej4k/KbcuHPxcuq4N1gsT8k9X5dzfKVTSokf
RC3WJFfXxMQa1MLjBKX8bkVVUW6DKhOBZCLMOHANSgQUk9A8Rxe5307BSELh
O1YyAJ/usbEQGFoEGYLBKeMs8jWkcFerJcmZT283XA+SFCItmIyhy1Kv5DvU
RDJnUgbUDv9AkhrDxSjCwoJQ7A+sKSXInH08lT4W1hNV1XUDrLFMuniHq/Wd
kRJruZcr0UKLdn9PquQTPfrk8k+e71yD2YTeIQjvMKG0SBSdWuXQHQTJDHiU
2jREluC6ETwjA21gS/N7JFqpqJesGzlTdSPxFnrAqb1sFVK0aLOlDvyU/GCd
sI2HWVFfURr45NQoGZwFUx5Y9tioIwwfqTIylSXWI+EnVa6YyhuL4/86KwxN
RZvrm0NTmed8FEeFUlQqwf8Ux6KXqoavAMs2wHrD5MvhNgR3k0aHX8rZQUdg
9O27C5MdrrgH/A42wBpjMmfIvlvZymQOaV0pgSVimaYhUlKACISxLEklS8vJ
23qGVz8u27T6cIcK/eE5Cp2bG1cQRf3Jl4PxKxkZUq56HiZ5h066SdlAY9kL
d4PwDDbGNqNpgzFdm1HFBflnByvJqZ3CA7GbwNMoK7TKXp6cZvoimVM4BEaU
2w16GXtpW7VW9nKYjeIgUgSliM3m/3IFWB8LjHnVGeovcMZlNT8E200DXQDJ
BUYoCzLLgJMUBuZVQlWe/ik3I504K82FyYuBKLqEhV2MOAQQlSIMAdbKnUnt
park9zX3Nas5VlQIUQRkY+FgUw0CaXJqNAsXPopXHh+78Cj+LoPaUMDWCI4s
TIg+LXRQGiaz7ckS4AE4mYMWkSFFk0CFRahmplyhHEnYYypN33kldGP8ayoh
/QECunEtAgqA43IVY40redp4w/lye7zEuQXaU1iUDlmchKxlmOaavDM5FA0O
JIli6T4+Q+8K84aqK+YMCvobJ9Kf1CTUxp1RKG8VZtIHHU7D5dFqWWpQHQgk
8YF1sSkI8IiwMjhkSjgK/0sWzUNLTBR3RheKg0MPu2HKSZKJJslqauk/dSDa
qupm7ipGimMtbixsbIaCCcQtLXbxbCyjUlIkFIK9+Jdk8D5GYbz7Pbr4WPw7
OUIEJNtvwd6EFA9IdgVDMZyHU5Ir+fOKJ9LAEFcwzSu15AbQ7Qi8qynN5W0h
Vu1F0CW8EcKlLwwnL2Cqayylva7txkndx1C5YHIX7wRYB7aEqqDL8xk0VPnU
uN4ibsOb8MAa9FykHKiXa1UD2Ki9g8skqvz851XvYnhy+XHIrgang6vBsD8Y
Vyo3oIMpDiPVDfTWfwUlqczTdJkc1evXsGdWU/zjSXXXmUZ11cuKZ669bx8+
uWF9GkTTOogy4OC6mrIu/rwbiUVwrLkFjdwb6/Pn2uIG74mrwRc+v6mFQd1u
NPdhjNid1xud+gI+3VjJGiTTZ0utTB28S6k/6Y7lEV5HfTeZjMAA6ke9kaq2
hgaRXWuoWjPINdYCtjfsOHm4Kb9tpJPlmpI3K+fLyEcuylD9cSnjr8vk/laA
pAJGFrO/SpVrjBV5m4d2x2hMRZD+D3MkXMCMbwAA

-->

</rfc>
