<pre>Internet Engineering Task Force (IETF)                          E. Rosen
Request for Comments: 6074                                      B. Davie
Category: Standards Track                            Cisco Systems, Inc.
ISSN: 2070-1721                                               V. Radoaca
                                                          Alcatel-Lucent
                                                                  W. Luo
                                                            January 2011


              <span class="h1">Provisioning, Auto-Discovery, and Signaling</span>
              <span class="h1">in Layer 2 Virtual Private Networks (L2VPNs)</span>

Abstract

   Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may
   have different "provisioning models", i.e., models for what
   information needs to be configured in what entities.  Once
   configured, the provisioning information is distributed by a
   "discovery process".  When the discovery process is complete, a
   signaling protocol is automatically invoked to set up the mesh of
   pseudowires (PWs) that form the (virtual) backbone of the L2VPN.
   This document specifies a number of L2VPN provisioning models, and
   further specifies the semantic structure of the endpoint identifiers
   required by each model.  It discusses the distribution of these
   identifiers by the discovery process, especially when discovery is
   based on the Border Gateway Protocol (BGP).  It then specifies how
   the endpoint identifiers are carried in the two signaling protocols
   that are used to set up PWs, the Label Distribution Protocol (LDP),
   and the Layer 2 Tunneling Protocol version 3 (L2TPv3).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6074">http://www.rfc-editor.org/info/rfc6074</a>.








<span class="grey">Rosen, et al.                Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























<span class="grey">Rosen, et al.                Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
   <a href="#section-2">2</a>.  Signaling Protocol Framework . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-2.1">2.1</a>.  Endpoint Identification  . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-2.2">2.2</a>.  Creating a Single Bidirectional Pseudowire . . . . . . . .  <a href="#page-7">7</a>
     <a href="#section-2.3">2.3</a>.  Attachment Identifiers and Forwarders  . . . . . . . . . .  <a href="#page-7">7</a>
   <a href="#section-3">3</a>.  Applications . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-9">9</a>
     <a href="#section-3.1">3.1</a>.  Individual Point-to-Point Pseudowires  . . . . . . . . . .  <a href="#page-9">9</a>
       <a href="#section-3.1.1">3.1.1</a>.  Provisioning Models  . . . . . . . . . . . . . . . . .  <a href="#page-9">9</a>
         <a href="#section-3.1.1.1">3.1.1.1</a>.  Double-Sided Provisioning  . . . . . . . . . . . .  <a href="#page-9">9</a>
         <a href="#section-3.1.1.2">3.1.1.2</a>.  Single-Sided Provisioning with Discovery . . . . .  <a href="#page-9">9</a>
       <a href="#section-3.1.2">3.1.2</a>.  Signaling  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-3.2">3.2</a>.  Virtual Private LAN Service  . . . . . . . . . . . . . . . <a href="#page-11">11</a>
       <a href="#section-3.2.1">3.2.1</a>.  Provisioning . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
       <a href="#section-3.2.2">3.2.2</a>.  Auto-Discovery . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
         <a href="#section-3.2.2.1">3.2.2.1</a>.  BGP-Based Auto-Discovery . . . . . . . . . . . . . <a href="#page-12">12</a>
       <a href="#section-3.2.3">3.2.3</a>.  Signaling  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
       <a href="#section-3.2.4">3.2.4</a>.  Pseudowires as VPLS Attachment Circuits  . . . . . . . <a href="#page-15">15</a>
     <a href="#section-3.3">3.3</a>.  Colored Pools: Full Mesh of Point-to-Point Pseudowires . . <a href="#page-15">15</a>
       <a href="#section-3.3.1">3.3.1</a>.  Provisioning . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
       <a href="#section-3.3.2">3.3.2</a>.  Auto-Discovery . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
         <a href="#section-3.3.2.1">3.3.2.1</a>.  BGP-Based Auto-Discovery . . . . . . . . . . . . . <a href="#page-16">16</a>
       <a href="#section-3.3.3">3.3.3</a>.  Signaling  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
     <a href="#section-3.4">3.4</a>.  Colored Pools: Partial Mesh  . . . . . . . . . . . . . . . <a href="#page-19">19</a>
     <a href="#section-3.5">3.5</a>.  Distributed VPLS . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
       <a href="#section-3.5.1">3.5.1</a>.  Signaling  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
       <a href="#section-3.5.2">3.5.2</a>.  Provisioning and Discovery . . . . . . . . . . . . . . <a href="#page-23">23</a>
       <a href="#section-3.5.3">3.5.3</a>.  Non-Distributed VPLS as a Sub-Case . . . . . . . . . . <a href="#page-23">23</a>
       <a href="#section-3.5.4">3.5.4</a>.  Splicing and the Data Plane  . . . . . . . . . . . . . <a href="#page-24">24</a>
   <a href="#section-4">4</a>.  Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
     <a href="#section-4.1">4.1</a>.  Multihop EBGP Redistribution of L2VPN NLRIs  . . . . . . . <a href="#page-24">24</a>
     4.2.  EBGP Redistribution of L2VPN NLRIs with Multi-Segment
           Pseudowires  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
     4.3.  Inter-Provider Application of Distributed VPLS
           Signaling  . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
     <a href="#section-4.4">4.4</a>.  RT and RD Assignment Considerations  . . . . . . . . . . . <a href="#page-27">27</a>
   <a href="#section-5">5</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
   <a href="#section-6">6</a>.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
   <a href="#section-7">7</a>.  BGP-AD and VPLS-BGP Interoperability . . . . . . . . . . . . . <a href="#page-29">29</a>
   <a href="#section-8">8</a>.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-30">30</a>
   <a href="#section-9">9</a>.  References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-30">30</a>
     <a href="#section-9.1">9.1</a>.  Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-30">30</a>
     <a href="#section-9.2">9.2</a>.  Informative References . . . . . . . . . . . . . . . . . . <a href="#page-31">31</a>







<span class="grey">Rosen, et al.                Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   [<a id="ref-RFC4664">RFC4664</a>] describes a number of different ways in which sets of
   pseudowires may be combined together into "Provider Provisioned Layer
   2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different
   kinds of L2VPN.  Different kinds of L2VPN may have different
   "provisioning models", i.e., different models for what information
   needs to be configured in what entities.  Once configured, the
   provisioning information is distributed by a "discovery process", and
   once the information is discovered, the signaling protocol is
   automatically invoked to set up the required pseudowires.  The
   semantics of the endpoint identifiers that the signaling protocol
   uses for a particular type of L2VPN are determined by the
   provisioning model.  That is, different kinds of L2VPN, with
   different provisioning models, require different kinds of endpoint
   identifiers.  This document specifies a number of L2VPN provisioning
   models and specifies the semantic structure of the endpoint
   identifiers required for each provisioning model.

   Either LDP (as specified in [<a href="./rfc5036" title="&quot;LDP Specification&quot;">RFC5036</a>] and extended in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>]) or
   L2TP version 3 (as specified in [<a href="./rfc3931" title="&quot;Layer Two Tunneling Protocol - Version 3 (L2TPv3)&quot;">RFC3931</a>] and extended in [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>])
   can be used as signaling protocols to set up and maintain PWs
   [<a href="./rfc3985" title="&quot;Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture&quot;">RFC3985</a>].  Any protocol that sets up connections must provide a way
   for each endpoint of the connection to identify the other; each PW
   signaling protocol thus provides a way to identify the PW endpoints.
   Since each signaling protocol needs to support all the different
   kinds of L2VPN and provisioning models, the signaling protocol must
   have a very general way of representing endpoint identifiers, and it
   is necessary to specify rules for encoding each particular kind of
   endpoint identifier into the relevant fields of each signaling
   protocol.  This document specifies how to encode the endpoint
   identifiers of each provisioning model into the LDP and L2TPv3
   signaling protocols.

   We make free use of terminology from [<a href="./rfc3985" title="&quot;Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture&quot;">RFC3985</a>], [<a href="./rfc4026" title="&quot;Provider Provisioned Virtual Private Network (VPN) Terminology&quot;">RFC4026</a>], [<a href="./rfc4664" title="&quot;Framework for Layer 2 Virtual Private Networks (L2VPNs)&quot;">RFC4664</a>],
   and [<a href="./rfc5659" title="&quot;An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge&quot;">RFC5659</a>] -- in particular, the terms "Attachment Circuit",
   "pseudowire", "PE" (provider edge), "CE" (customer edge), and "multi-
   segment pseudowire".

   <a href="#section-2">Section 2</a> provides an overview of the relevant aspects of [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>]
   and [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>].

   <a href="#section-3">Section 3</a> details various provisioning models and relates them to the
   signaling process and to the discovery process.  The way in which the
   signaling mechanisms can be integrated with BGP-based auto-discovery
   is covered in some detail.





<span class="grey">Rosen, et al.                Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   <a href="#section-4">Section 4</a> explains how the procedures for discovery and signaling can
   be applied in a multi-AS environment and outlines several options for
   the establishment of multi-AS L2VPNs.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>]

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Signaling Protocol Framework</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Endpoint Identification</span>

   Per [<a href="./rfc4664" title="&quot;Framework for Layer 2 Virtual Private Networks (L2VPNs)&quot;">RFC4664</a>], a pseudowire can be thought of as a relationship
   between a pair of "Forwarders".  In simple instances of Virtual
   Private Wire Service (VPWS), a Forwarder binds a pseudowire to a
   single Attachment Circuit, such that frames received on the one are
   sent on the other, and vice versa.  In Virtual Private LAN Service
   (VPLS), a Forwarder binds a set of pseudowires to a set of Attachment
   Circuits; when a frame is received from any member of that set, a MAC
   (Media Access Control) address table is consulted (and various 802.1d
   procedures executed) to determine the member or members of that set
   on which the frame is to be transmitted.  In more complex scenarios,
   Forwarders may bind PWs to PWs, thereby "splicing" two PWs together;
   this is needed, e.g., to support distributed VPLS and some inter-AS
   scenarios.

   In simple VPWS, where a Forwarder binds exactly one PW to exactly one
   Attachment Circuit, a Forwarder can be identified by identifying its
   Attachment Circuit.  In simple VPLS, a Forwarder can be identified by
   identifying its PE device and its VPN.

   To set up a PW between a pair of Forwarders, the signaling protocol
   must allow the Forwarder at one endpoint to identify the Forwarder at
   the other.  In [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>], the term "Attachment Identifier", or "AI",
   is used to refer to a quantity whose purpose is to identify a
   Forwarder.  In [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>], the term "Forwarder Identifier" is used for
   the same purpose.  In the context of this document, "Attachment
   Identifier" and "Forwarder Identifier" are used interchangeably.

   [<a id="ref-RFC4447">RFC4447</a>] specifies two Forwarding Equivalence Class (FEC) elements
   that can be used when setting up pseudowires, the PWid FEC element,
   and the Generalized ID FEC element.  The PWid FEC element carries
   only one Forwarder identifier; it can be thus be used only when both
   forwarders have the same identifier, and when that identifier can be
   coded as a 32-bit quantity.  The Generalized ID FEC element carries
   two Forwarder identifiers, one for each of the two Forwarders being





<span class="grey">Rosen, et al.                Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   connected.  Each identifier is known as an Attachment Identifier, and
   a signaling message carries both a "Source Attachment Identifier"
   (SAI) and a "Target Attachment Identifier" (TAI).

   The Generalized ID FEC element also provides some additional
   structuring of the identifiers.  It is assumed that the SAI and TAI
   will sometimes have a common part, called the "Attachment Group
   Identifier" (AGI), such that the SAI and TAI can each be thought of
   as the concatenation of the AGI with an "Attachment Individual
   Identifier" (AII).  So the pair of identifiers is encoded into three
   fields: AGI, Source AII (SAII), and Target AII (TAII).  The SAI is
   the concatenation of the AGI and the SAII, while the TAI is the
   concatenation of the AGI and the TAII.

   Similarly, [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>] allows using one or two Forwarder Identifiers to
   set up pseudowires.  If only the target Forwarder Identifier is used
   in L2TP signaling messages, both the source and target Forwarders are
   assumed to have the same value.  If both the source and target
   Forwarder Identifiers are carried in L2TP signaling messages, each
   Forwarder uses a locally significant identifier value.

   The Forwarder Identifier in [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>] is an equivalent term to
   Attachment Identifier in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].  A Forwarder Identifier also
   consists of an Attachment Group Identifier and an Attachment
   Individual Identifier.  Unlike the Generalized ID FEC element, the
   AGI and AII are carried in distinct L2TP Attribute-Value Pairs
   (AVPs).  The AGI is encoded in the AGI AVP, and the SAII and TAII are
   encoded in the Local End ID AVP and the Remote End ID AVP,
   respectively.  The source Forwarder Identifier is the concatenation
   of the AGI and SAII, while the target Forwarder Identifier is the
   concatenation of the AGI and TAII.

   In applications that group sets of PWs into "Layer 2 Virtual Private
   Networks", the AGI can be thought of as a "VPN Identifier".

   It should be noted that while different forwarders support different
   applications, the type of application (e.g., VPLS vs. VPWS) cannot
   necessarily be inferred from the forwarders' identifiers.  A router
   receiving a signaling message with a particular TAI will have to be
   able to determine which of its local forwarders is identified by that
   TAI, and to determine the application provided by that forwarder.
   But other nodes may not be able to infer the application simply by
   inspection of the signaling messages.

   In this document, some further structure of the AGI and AII is
   proposed for certain L2VPN applications.  We note that [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>]
   defines a TLV structure for AGI and AII fields.  Thus, an operator
   who chooses to use the AII structure defined here could also make use



<span class="grey">Rosen, et al.                Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   of different AGI or AII types if he also wanted to use a different
   structure for these identifiers for some other application.  For
   example, the long prefix type of [<a href="./rfc5003" title="&quot;Attachment Individual Identifier (AII) Types for Aggregation&quot;">RFC5003</a>] could be used to enable
   the communication of administrative information, perhaps combined
   with information learned during auto-discovery.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Creating a Single Bidirectional Pseudowire</span>

   In any form of LDP-based signaling, each PW endpoint must initiate
   the creation of a unidirectional LSP.  A PW is a pair of such LSPs.
   In most of the L2VPN provisioning models, the two endpoints of a
   given PW can simultaneously initiate the signaling for it.  They must
   therefore have some way of determining when a given pair of LSPs are
   intended to be associated together as a single PW.

   The way in which this association is done is different for the
   various different L2VPN services and provisioning models.  The
   details appear in later sections.

   L2TP signaling inherently establishes a bidirectional session that
   carries a PW between two PW endpoints.  The two endpoints can also
   simultaneously initiate the signaling for a given PW.  It is possible
   that two PWs can be established for a pair of Forwarders.

   In order to avoid setting up duplicated pseudowires between two
   Forwarders, each PE must be able to independently detect such a
   pseudowire tie.  The procedures of detecting a pseudowire tie are
   described in [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>].

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Attachment Identifiers and Forwarders</span>

   Every Forwarder in a PE must be associated with an Attachment
   Identifier (AI), either through configuration or through some
   algorithm.  The Attachment Identifier must be unique in the context
   of the PE router in which the Forwarder resides.  The combination
   &lt;PE router, AI&gt; must be globally unique.

   As specified in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>], the Attachment Identifier may consist of
   an Attachment Group Identifier (AGI) plus an Attachment Individual
   Identifier (AII).  In the context of this document, an AGI may be
   thought of as a VPN-ID, or some attribute that is shared by all the
   Attachment Circuits that are allowed to be connected.

   It is sometimes helpful to consider a set of attachment circuits at a
   single PE to belong to a common "pool".  For example, a set of
   attachment circuits that connect a single CE to a given PE may be
   considered a pool.  The use of pools is described in detail in
   <a href="#section-3.3">Section 3.3</a>.



<span class="grey">Rosen, et al.                Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   The details for how to construct the AGI and AII fields identifying
   the pseudowire endpoints in particular provisioning models are
   discussed later in this document.

   We can now consider an LSP for one direction of a pseudowire to be
   identified by:

   o  &lt;PE1, &lt;AGI, AII1&gt;, PE2, &lt;AGI, AII2&gt;&gt;

   and the LSP in the opposite direction of the pseudowire will be
   identified by:

   o  &lt;PE2, &lt;AGI, AII2&gt;, PE1, &lt;AGI, AII1&gt;&gt;

   A pseudowire is a pair of such LSPs.  In the case of using L2TP
   signaling, these refer to the two directions of an L2TP session.

   When a signaling message is sent from PE1 to PE2, and PE1 needs to
   refer to an Attachment Identifier that has been configured on one of
   its own Attachment Circuits (or pools), the Attachment Identifier is
   called a "Source Attachment Identifier".  If PE1 needs to refer to an
   Attachment Identifier that has been configured on one of PE2's
   Attachment Circuits (or pools), the Attachment Identifier is called a
   "Target Attachment Identifier".  (So an SAI at one endpoint is a TAI
   at the remote endpoint, and vice versa.)

   In the signaling protocol, we define encodings for the following
   three fields:

   o  Attachment Group Identifier (AGI)

   o  Source Attachment Individual Identifier (SAII)

   o  Target Attachment Individual Identifier (TAII)

   If the AGI is non-null, then the SAI consists of the AGI together
   with the SAII, and the TAI consists of the TAII together with the
   AGI.  If the AGI is null, then the SAII and TAII are the SAI and TAI,
   respectively.

   The intention is that the PE that receives an LDP Label Mapping
   message or an L2TP Incoming Call Request (ICRQ) message containing a
   TAI will be able to map that TAI uniquely to one of its Attachment
   Circuits (or pools).  The way in which a PE maps a TAI to an
   Attachment Circuit (or pool) should be a local matter (including the
   choice of whether to use some or all of the bytes in the TAI for the
   mapping).  So as far as the signaling procedures are concerned, the
   TAI is really just an arbitrary string of bytes, a "cookie".



<span class="grey">Rosen, et al.                Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Applications</span>

   In this section, we specify the way in which the pseudowire signaling
   using the notion of source and target Forwarder is applied for a
   number of different applications.  For some of the applications, we
   specify the way in which different provisioning models can be used.
   However, this is not meant to be an exhaustive list of the
   applications, or an exhaustive list of the provisioning models that
   can be applied to each application.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Individual Point-to-Point Pseudowires</span>

   The signaling specified in this document can be used to set up
   individually provisioned point-to-point pseudowires.  In this
   application, each Forwarder binds a single PW to a single Attachment
   Circuit.  Each PE must be provisioned with the necessary set of
   Attachment Circuits, and then certain parameters must be provisioned
   for each Attachment Circuit.

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Provisioning Models</span>

<span class="h5"><a class="selflink" id="section-3.1.1.1" href="#section-3.1.1.1">3.1.1.1</a>.  Double-Sided Provisioning</span>

   In this model, the Attachment Circuit must be provisioned with a
   local name, a remote PE address, and a remote name.  During
   signaling, the local name is sent as the SAII, the remote name as the
   TAII, and the AGI is null.  If two Attachment Circuits are to be
   connected by a PW, the local name of each must be the remote name of
   the other.

   Note that if the local name and the remote name are the same, the
   PWid FEC element can be used instead of the Generalized ID FEC
   element in the LDP-based signaling.

   With L2TP signaling, the local name is sent in Local End ID AVP, and
   the remote name in Remote End ID AVP.  The AGI AVP is optional.  If
   present, it contains a zero-length AGI value.  If the local name and
   the remote name are the same, Local End ID AVP can be omitted from
   L2TP signaling messages.

<span class="h5"><a class="selflink" id="section-3.1.1.2" href="#section-3.1.1.2">3.1.1.2</a>.  Single-Sided Provisioning with Discovery</span>

   In this model, each Attachment Circuit must be provisioned with a
   local name.  The local name consists of a VPN-ID (signaled as the
   AGI) and an Attachment Individual Identifier that is unique relative
   to the AGI.  If two Attachment Circuits are to be connected by a PW,
   only one of them needs to be provisioned with a remote name (which of




<span class="grey">Rosen, et al.                Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   course is the local name of the other Attachment Circuit).  Neither
   needs to be provisioned with the address of the remote PE, but both
   must have the same VPN-ID.

   As part of an auto-discovery procedure, each PE advertises its
   &lt;VPN-id, local AII&gt; pairs.  Each PE compares its local &lt;VPN-id,
   remote AII&gt; pairs with the &lt;VPN-id, local AII&gt; pairs advertised by
   the other PEs.  If PE1 has a local &lt;VPN-id, remote AII&gt; pair with
   value &lt;V, fred&gt;, and PE2 has a local &lt;VPN-id, local AII&gt; pair with
   value &lt;V, fred&gt;, PE1 will thus be able to discover that it needs to
   connect to PE2.  When signaling, it will use "fred" as the TAII, and
   will use V as the AGI.  PE1's local name for the Attachment Circuit
   is sent as the SAII.

   The primary benefit of this provisioning model when compared to
   Double-Sided Provisioning is that it enables one to move an
   Attachment Circuit from one PE to another without having to
   reconfigure the remote endpoint.  However, compared to the approach
   described in <a href="#section-3.3">Section 3.3</a> below, it imposes a greater burden on the
   discovery mechanism, because each Attachment Circuit's name must be
   advertised individually (i.e., there is no aggregation of Attachment
   Circuit names in this simple scheme).

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Signaling</span>

   The LDP-based signaling follows the procedures specified in
   [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].  That is, one PE (PE1) sends a Label Mapping message to
   another PE (PE2) to establish an LSP in one direction.  If that
   message is processed successfully, and there is not yet an LSP for
   the pseudowire in the opposite (PE1-&gt;PE2) direction, then PE2 sends a
   Label Mapping message to PE1.

   In addition to the procedures of [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>], when a PE receives a
   Label Mapping message, and the TAI identifies a particular Attachment
   Circuit that is configured to be bound to a point-to-point PW, then
   the following checks must be made.

   If the Attachment Circuit is already bound to a pseudowire (including
   the case where only one of the two LSPs currently exists), and the
   remote endpoint is not PE1, then PE2 sends a Label Release message to
   PE1, with a Status Code meaning "Attachment Circuit bound to
   different PE", and the processing of the Mapping message is complete.

   If the Attachment Circuit is already bound to a pseudowire (including
   the case where only one of the two LSPs currently exists), but the AI
   at PE1 is different than that specified in the AGI/SAII fields of the
   Mapping message then PE2 sends a Label Release message to PE1, with a




<span class="grey">Rosen, et al.                Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   Status Code meaning "Attachment Circuit bound to different remote
   Attachment Circuit", and the processing of the Mapping message is
   complete.

   Similarly, with the L2TP-based signaling, when a PE receives an ICRQ
   message, and the TAI identifies a particular Attachment Circuit that
   is configured to be bound to a point-to-point PW, it performs the
   following checks.

   If the Attachment Circuit is already bound to a pseudowire, and the
   remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify
   (CDN) message to PE1, with a Status Code meaning "Attachment Circuit
   bound to different PE", and the processing of the ICRQ message is
   complete.

   If the Attachment Circuit is already bound to a pseudowire, but the
   pseudowire is bound to a Forwarder on PE1 with the AI different than
   that specified in the SAI fields of the ICRQ message, then PE2 sends
   a CDN message to PE1, with a Status Code meaning "Attachment Circuit
   bound to different remote Attachment Circuit", and the processing of
   the ICRQ message is complete.

   These errors could occur as the result of misconfigurations.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Virtual Private LAN Service</span>

   In the VPLS application [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>], the Attachment Circuits can be
   thought of as LAN interfaces that attach to "virtual LAN switches",
   or, in the terminology of [<a href="./rfc4664" title="&quot;Framework for Layer 2 Virtual Private Networks (L2VPNs)&quot;">RFC4664</a>], "Virtual Switching Instances"
   (VSIs).  Each Forwarder is a VSI that attaches to a number of PWs and
   a number of Attachment Circuits.  The VPLS service requires that a
   single pseudowire be created between each pair of VSIs that are in
   the same VPLS.  Each PE device may have multiple VSIs, where each VSI
   belongs to a different VPLS.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Provisioning</span>

   Each VPLS must have a globally unique identifier, which in [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>]
   is referred to as the VPLS identifier (or VPLS-id).  Every VSI must
   be configured with the VPLS-id of the VPLS to which it belongs.

   Each VSI must also have a unique identifier, which we call a VSI-ID.
   This can be formed automatically by concatenating its VPLS-id with an
   IP address of its PE router.  (Note that the PE address here is used
   only as a form of unique identifier; a service provider could choose
   to use some other numbering scheme if that was desired, as long as





<span class="grey">Rosen, et al.                Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   each VSI is assigned an identifier that is unique within the VPLS
   instance.  See <a href="#section-4.4">Section 4.4</a> for a discussion of the assignment of
   identifiers in the case of multiple providers.)

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Auto-Discovery</span>

<span class="h5"><a class="selflink" id="section-3.2.2.1" href="#section-3.2.2.1">3.2.2.1</a>.  BGP-Based Auto-Discovery</span>

   This section specifies how BGP can be used to discover the
   information necessary to build VPLS instances.

   When BGP-based auto-discovery is used for VPLS, the AFI/SAFI (Address
   Family Identifier / Subsequent Address Family Identifier) [<a href="./rfc4760" title="&quot;Multiprotocol Extensions for BGP-4&quot;">RFC4760</a>]
   will be:

   o  An AFI (25) for L2VPN.  (This is the same for all L2VPN schemes.)

   o  A SAFI (65) specifically for an L2VPN service whose pseudowires
      are set up using the procedures described in the current document.

   See <a href="#section-6">Section 6</a> for further discussion of AFI/SAFI assignment.

   In order to use BGP-based auto-discovery, there must be at least one
   globally unique identifier associated with a VPLS, and each such
   identifier must be encodable as an 8-byte Route Distinguisher (RD).
   Any method of assigning one or more unique identifiers to a VPLS and
   encoding each of them as an RD (using the encoding techniques of
   [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>]) will do.

   Each VSI needs to have a unique identifier that is encodable as a BGP
   Network Layer Reachability Information (NLRI).  This is formed by
   prepending the RD (from the previous paragraph) to an IP address of
   the PE containing the VSI.  Note that the role of this address is
   simply as a readily available unique identifier for the VSIs within a
   VPN; it does not need to be globally routable, but it must be unique
   within the VPLS instance.  An alternate scheme to assign unique
   identifiers to each VSI within a VPLS instance (e.g., numbering the
   VSIs of a single VPN from 1 to n) could be used if desired.

   When using the procedures described in this document, it is necessary
   to assign a single, globally unique VPLS-id to each VPLS instance
   [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>].  This VPLS-id must be encodable as a BGP Extended
   Community [<a href="./rfc4360" title="&quot;BGP Extended Communities Attribute&quot;">RFC4360</a>].  As described in <a href="#section-6">Section 6</a>, two Extended
   Community subtypes are defined by this document for this purpose.
   The Extended Community MUST be transitive.






<span class="grey">Rosen, et al.                Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   The first Extended Community subtype is a Two-octet AS Specific
   Extended Community.  The second Extended Community subtype is an IPv4
   Address Specific Extended Community.  The encoding of such
   Communities is defined in [<a href="./rfc4360" title="&quot;BGP Extended Communities Attribute&quot;">RFC4360</a>].  These encodings ensure that a
   service provider can allocate a VPLS-id without risk of collision
   with another provider.  However, note that coordination of VPLS-ids
   among providers is necessary for inter-provider L2VPNs, as described
   in <a href="#section-4.4">Section 4.4</a>.

   Each VSI also needs to be associated with one or more Route Target
   (RT) Extended Communities.  These control the distribution of the
   NLRI, and hence will control the formation of the overlay topology of
   pseudowires that constitutes a particular VPLS.

   Auto-discovery proceeds by having each PE distribute, via BGP, the
   NLRI for each of its VSIs, with itself as the BGP next hop, and with
   the appropriate RT for each such NLRI.  Typically, each PE would be a
   client of a small set of BGP route reflectors, which would
   redistribute this information to the other clients.

   If a PE receives a BGP update from which any of the elements
   specified above is absent, the update should be ignored.

   If a PE has a VSI with a particular RT, it can then import all the
   NLRIs that have that same RT, and from the BGP next hop attribute of
   these NLRI it will learn the IP addresses of the other PE routers
   which have VSIs with the same RT.  The considerations in <a href="./rfc4364#section-4.3.3">Section</a>
   <a href="./rfc4364#section-4.3.3">4.3.3 of [RFC4364]</a> on the use of route reflectors apply.

   If a particular VPLS is meant to be a single fully connected LAN, all
   its VSIs will have the same RT, in which case the RT could be (though
   it need not be) an encoding of the VPN-id.  A VSI can be placed in
   multiple VPLSes by assigning it multiple RTs.

   Note that hierarchical VPLS can be set up by assigning multiple RTs
   to some of the VSIs; the RT mechanism allows one to have complete
   control over the pseudowire overlay that constitutes the VPLS
   topology.

   If Distributed VPLS (described in <a href="#section-3.5">Section 3.5</a>) is deployed, only the
   Network-facing PEs (N-PEs) participate in BGP-based auto-discovery.
   This means that an N-PE would need to advertise reachability to each
   of the VSIs that it supports, including those located in User-facing
   PEs (U-PEs) to which it is connected.  To create a unique identifier
   for each such VSI, an IP address of each U-PE combined with the RD
   for the VPLS instance could be used.





<span class="grey">Rosen, et al.                Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   In summary, the BGP advertisement for a particular VSI at a given PE
   will contain:

   o  an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:PE_addr

   o  a BGP next hop equal to the loopback address of the PE

   o  an Extended Community Attribute containing the VPLS-id

   o  an Extended Community Attribute containing one or more RTs.

   See <a href="#section-6">Section 6</a> for discussion of the AFI and SAFI values.  The format
   for the NLRI encoding is:

        +------------------------------------+
        |  Length (2 octets)                 |
        +------------------------------------+
        |  Route Distinguisher (8 octets)    |
        +------------------------------------+
        |  PE_addr (4 octets)                |
        +------------------------------------+

   Note that this advertisement is quite similar to the NLRI format
   defined in [<a href="./rfc4761" title="&quot;Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling&quot;">RFC4761</a>], the main difference being that [<a href="./rfc4761" title="&quot;Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling&quot;">RFC4761</a>] also
   includes a label block in the NLRI.  Interoperability between the
   VPLS scheme defined here and that defined in [<a href="./rfc4761" title="&quot;Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling&quot;">RFC4761</a>] is beyond the
   scope of this document.

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Signaling</span>

   It is necessary to create Attachment Identifiers that identify the
   VSIs.  In the preceding section, a VSI-ID was encoded as RD:PE_addr,
   and the VPLS-id was carried in a BGP Extended Community.  For
   signaling purposes, this information is encoded as follows.  We
   encode the VPLS-id in the AGI field, and place the PE_addr (or, more
   precisely, the VSI-ID that was contained in the NLRI in BGP, minus
   the RD) in the TAII field.  The combination of AGI and TAII is
   sufficient to fully specify the VSI to which this pseudowire is to be
   connected, in both single AS and inter-AS environments.  The SAII
   MUST be set to the PE_addr of the sending PE (or, more precisely, the
   VSI-ID, without the RD, of the VSI associated with this VPLS in the
   sending PE) to enable signaling of the reverse half of the PW if
   needed.

   The structure of the AGI and AII fields for the Generalized ID FEC in
   LDP is defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].  The AGI field in this case consists of
   a Type of 1, a length field of value 8, and the 8 bytes of the




<span class="grey">Rosen, et al.                Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   VPLS-id.  The AIIs consist of a Type of 1, a length field of value 4,
   followed by the 4-byte PE address (or other 4-byte identifier).  See
   <a href="#section-6">Section 6</a> for discussion of the AGI and AII Type assignment.

   The encoding of the AGI and AII in L2TP is specified in [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>].

   Note that it is not possible using this technique to set up more than
   one PW per pair of VSIs.

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  Pseudowires as VPLS Attachment Circuits</span>

   It is also possible using this technique to set up a PW that attaches
   at one endpoint to a VSI, but at the other endpoint only to an
   Attachment Circuit.  There may be more than one PW terminating on a
   given VSI, which must somehow be distinguished, so each PW must have
   an SAII that is unique relative to the VSI-ID.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Colored Pools: Full Mesh of Point-to-Point Pseudowires</span>

   The "Colored Pools" model of operation provides an automated way to
   deliver VPWS.  In this model, each PE may contain several pools of
   Attachment Circuits, each pool associated with a particular VPN.  A
   PE may contain multiple pools per VPN, as each pool may correspond to
   a particular CE device.  It may be desired to create one pseudowire
   between each pair of pools that are in the same VPN; the result would
   be to create a full mesh of CE-CE Virtual Circuits for each VPN.

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Provisioning</span>

   Each pool is configured, and associated with:

   o  a set of Attachment Circuits;

   o  a "color", which can be thought of as a VPN-id of some sort;

   o  a relative pool identifier, which is unique relative to the color.

   [Note: depending on the technology used for Attachment Circuits
   (ACs), it may or may not be necessary to provision these circuits as
   well.  For example, if the ACs are frame relay circuits, there may be
   some separate provisioning system to set up such circuits.
   Alternatively, "provisioning" an AC may be as simple as allocating an
   unused VLAN ID on an interface and communicating the choice to the
   customer.  These issues are independent of the procedures described
   in this document.]






<span class="grey">Rosen, et al.                Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   The pool identifier and color, taken together, constitute a globally
   unique identifier for the pool.  Thus, if there are n pools of a
   given color, their pool identifiers can be (though they do not need
   to be) the numbers 1-n.

   The semantics are that a pseudowire will be created between every
   pair of pools that have the same color, where each such pseudowire
   will be bound to one Attachment Circuit from each of the two pools.

   If each pool is a set of Attachment Circuits leading to a single CE
   device, then the Layer 2 connectivity among the CEs is controlled by
   the way the colors are assigned to the pools.  To create a full mesh,
   the "color" would just be a VPN-id.

   Optionally, a particular Attachment Circuit may be configured with
   the relative pool identifier of a remote pool.  Then, that Attachment
   Circuit would be bound to a particular pseudowire only if that
   pseudowire's remote endpoint is the pool with that relative pool
   identifier.  With this option, the same pairs of Attachment Circuits
   will always be bound via pseudowires.

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Auto-Discovery</span>

<span class="h5"><a class="selflink" id="section-3.3.2.1" href="#section-3.3.2.1">3.3.2.1</a>.  BGP-Based Auto-Discovery</span>

   This section specifies how BGP can be used to discover the
   information necessary to build VPWS instances.

   When BGP-based auto-discovery is used for VPWS, the AFI/SAFI will be:

   o  An AFI specified by IANA for L2VPN.  (This is the same for all
      L2VPN schemes.)

   o  A SAFI specified by IANA specifically for an L2VPN service whose
      pseudowires are set up using the procedures described in the
      current document.

   See <a href="#section-6">Section 6</a> for further discussion of AFI/SAFI assignment.

   In order to use BGP-based auto-discovery, there must be one or more
   unique identifiers associated with a particular VPWS instance.  Each
   identifier must be encodable as an RD (Route Distinguisher).  The
   globally unique identifier of a pool must be encodable as NLRI; the
   pool identifier, which we define to be a 4-byte quantity, is appended
   to the RD to create the NLRI.

   When using the procedures described in this document, it is necessary
   to assign a single, globally unique identifier to each VPWS instance.



<span class="grey">Rosen, et al.                Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   This identifier must be encodable as a BGP Extended Community
   [<a href="./rfc4360" title="&quot;BGP Extended Communities Attribute&quot;">RFC4360</a>].  As described in <a href="#section-6">Section 6</a>, two Extended Community
   subtypes are defined by this document for this purpose.  The Extended
   Community MUST be transitive.

   The first Extended Community subtype is a Two-octet AS Specific
   Extended Community.  The second Extended Community subtype is an IPv4
   Address Specific Extended Community.  The encoding of such
   Communities is defined in [<a href="./rfc4360" title="&quot;BGP Extended Communities Attribute&quot;">RFC4360</a>].  These encodings ensure that a
   service provider can allocate a VPWS identifier without risk of
   collision with another provider.  However, note that co-ordination of
   VPWS identifiers among providers is necessary for inter-provider
   L2VPNs, as described in <a href="#section-4.4">Section 4.4</a>.

   Each pool must also be associated with an RT (route target), which
   may also be an encoding of the color.  If the desired topology is a
   full mesh of pseudowires, all pools may have the same RT.  See
   <a href="#section-3.4">Section 3.4</a> for a discussion of other topologies.

   Auto-discovery proceeds by having each PE distribute, via BGP, the
   NLRI for each of its pools, with itself as the BGP next hop, and with
   the RT that encodes the pool's color.  If a given PE has a pool with
   a particular color (RT), it must receive, via BGP, all NLRI with that
   same color (RT).  Typically, each PE would be a client of a small set
   of BGP route reflectors, which would redistribute this information to
   the other clients.

   If a PE receives a BGP update from which any of the elements
   specified above is absent, the update should be ignored.

   If a PE has a pool with a particular color, it can then receive all
   the NLRI that have that same color, and from the BGP next hop
   attribute of these NLRI will learn the IP addresses of the other PE
   routers that have pools switches with the same color.  It also learns
   the unique identifier of each such remote pool, as this is encoded in
   the NLRI.  The remote pool's relative identifier can be extracted
   from the NLRI and used in the signaling, as specified below.

   In summary, the BGP advertisement for a particular pool of attachment
   circuits at a given PE will contain:

   o  an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:pool_num;

   o  a BGP next hop equal to the loopback address of the PE;

   o  an Extended Community Attribute containing the VPWS identifier;

   o  an Extended Community Attribute containing one or more RTs.



<span class="grey">Rosen, et al.                Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   See <a href="#section-6">Section 6</a> for discussion of the AFI and SAFI values.

<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>.  Signaling</span>

   The LDP-based signaling follows the procedures specified in
   [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].  That is, one PE (PE1) sends a Label Mapping message to
   another PE (PE2) to establish an LSP in one direction.  The address
   of PE2 is the next-hop address learned via BGP as described above.
   If the message is processed successfully, and there is not yet an LSP
   for the pseudowire in the opposite (PE1-&gt;PE2) direction, then PE2
   sends a Label Mapping message to PE1.  Similarly, the L2TPv3-based
   signaling follows the procedures of [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>].  Additional details on
   the use of these signaling protocols follow.

   When a PE sends a Label Mapping message or an ICRQ message to set up
   a PW between two pools, it encodes the VPWS identifier (as
   distributed in the Extended Community Attribute by BGP) as the AGI,
   the local pool's relative identifier as the SAII, and the remote
   pool's relative identifier as the TAII.

   The structure of the AGI and AII fields for the Generalized ID FEC in
   LDP is defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].  The AGI field in this case consists of
   a Type of 1, a length field of value 8, and the 8 bytes of the VPWS
   identifier.  The TAII consists of a Type of 1, a length field of
   value 4, followed by the 4-byte remote pool number.  The SAII
   consists of a Type of 1, a length field of value 4, followed by the
   4-byte local pool number.  See <a href="#section-6">Section 6</a> for discussion of the AGI
   and AII Type assignment.  Note that the VPLS and VPWS procedures
   defined in this document can make use of the same AGI Type (1) and
   the same AII Type (1).

   The encoding of the AGI and AII in L2TP is specified in [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>].

   When PE2 receives a Label Mapping message or an ICRQ message from
   PE1, and the TAI identifies a pool, and there is already a pseudowire
   connecting an Attachment Circuit in that pool to an Attachment
   Circuit at PE1, and the AI at PE1 of that pseudowire is the same as
   the SAI of the Label Mapping or ICRQ message, then PE2 sends a Label
   Release or CDN message to PE1, with a Status Code meaning "Attachment
   Circuit already bound to remote Attachment Circuit".  This prevents
   the creation of multiple pseudowires between a given pair of pools.

   Note that the signaling itself only identifies the remote pool to
   which the pseudowire is to lead, not the remote Attachment Circuit
   that is to be bound to the pseudowire.  However, the remote PE may
   examine the SAII field to determine which Attachment Circuit should
   be bound to the pseudowire.




<span class="grey">Rosen, et al.                Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Colored Pools: Partial Mesh</span>

   The procedures for creating a partial mesh of pseudowires among a set
   of colored pools are substantially the same as those for creating a
   full mesh, with the following exceptions:

   o  Each pool is optionally configured with a set of "import RTs" and
      "export RTs";

   o  During BGP-based auto-discovery, the pool color is still encoded
      in the RD, but if the pool is configured with a set of "export
      RTs", these are encoded in the RTs of the BGP Update messages
      INSTEAD of the color;

   o  If a pool has a particular "import RT" value X, it will create a
      PW to every other pool that has X as one of its "export RTs".  The
      signaling messages and procedures themselves are as in
      <a href="#section-3.3.3">Section 3.3.3</a>.

   As a simple example, consider the task of building a hub-and-spoke
   topology with a single hub.  One pool, the "hub" pool, is configured
   with an export RT of RT_hub and an import RT of RT_spoke.  All other
   pools (the spokes) are configured with an export RT of RT_spoke and
   an import RT of RT_hub.  Thus, the hub pool will connect to the
   spokes, and vice-versa, but the spoke pools will not connect to each
   other.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Distributed VPLS</span>

   In Distributed VPLS ([<a href="./rfc4664" title="&quot;Framework for Layer 2 Virtual Private Networks (L2VPNs)&quot;">RFC4664</a>]), the VPLS functionality of a PE
   router is divided among two systems: a U-PE and an N-PE.  The U-PE
   sits between the user and the N-PE.  VSI functionality (e.g., MAC
   address learning and bridging) is performed on the U-PE.  A number of
   U-PEs attach to an N-PE.  For each VPLS supported by a U-PE, the U-PE
   maintains a pseudowire to each of the other U-PEs in the same VPLS.
   However, the U-PEs do not maintain signaling control connections with
   each other.  Rather, each U-PE has only a single signaling
   connection, to its N-PE.  In essence, each U-PE-to-U-PE pseudowire is
   composed of three pseudowires spliced together: one from U-PE to
   N-PE, one from N-PE to N-PE, and one from N-PE to U-PE.  In the
   terminology of [<a href="./rfc5659" title="&quot;An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge&quot;">RFC5659</a>], the N-PEs perform the pseudowire switching
   function to establish multi-segment PWs from U-PE to U-PE.









<span class="grey">Rosen, et al.                Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   Consider, for example, the following topology:

           U-PE A-----|             |----U-PE C
                      |             |
                      |             |
                    N-PE E--------N-PE F
                      |             |
                      |             |
           U-PE B-----|             |-----U-PE D

   where the four U-PEs are in a common VPLS.  We now illustrate how PWs
   get spliced together in the above topology in order to establish the
   necessary PWs from U-PE A to the other U-PEs.

   There are three PWs from A to E.  Call these A-E/1, A-E/2, and A-E/3.
   In order to connect A properly to the other U-PEs, there must be two
   PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B
   (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1).

   The N-PEs must then splice these pseudowires together to get the
   equivalent of what the non-distributed VPLS signaling mechanism would
   provide:

   o  PW from A to B: A-E/1 gets spliced to E-B/1.

   o  PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1.

   o  PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1.

   It doesn't matter which PWs get spliced together, as long as the
   result is one from A to each of B, C, and D.

   Similarly, there are additional PWs that must get spliced together to
   properly interconnect U-PE B with U-PEs C and D, and to interconnect
   U-PE C with U-PE D.

   The following figure illustrates the PWs from A to C and from B to D.
   For clarity of the figure, the other four PWs are not shown.













<span class="grey">Rosen, et al.                Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


                      splicing points
                       |           |
                       V           V
      A-C PW    &lt;-----&gt;&lt;-----------&gt;&lt;------&gt;


           U-PE A-----|             |----U-PE C
                      |             |
                      |             |
                    N-PE E--------N-PE F
                      |             |
                      |             |
           U-PE B-----|             |-----U-PE D


      B-D PW    &lt;-----&gt;&lt;-----------&gt;&lt;------&gt;
                       ^           ^
                       |           |
                      splicing points

   One can see that distributed VPLS does not reduce the number of
   pseudowires per U-PE, but it does reduce the number of control
   connections per U-PE.  Whether this is worthwhile depends, of course,
   on what the bottleneck is.

<span class="h4"><a class="selflink" id="section-3.5.1" href="#section-3.5.1">3.5.1</a>.  Signaling</span>

   The signaling to support Distributed VPLS can be done with the
   mechanisms described in this document.  However, the procedures for
   VPLS (<a href="#section-3.2.3">Section 3.2.3</a>) need some additional machinery to ensure that
   the appropriate number of PWs are established between the various
   N-PEs and U-PEs, and among the N-PEs.

   At a given N-PE, the directly attached U-PEs in a given VPLS can be
   numbered from 1 to n.  This number identifies the U-PE relative to a
   particular VPN-id and a particular N-PE.  (That is, to uniquely
   identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be
   known.)

   As a result of configuration/discovery, each U-PE must be given a
   list of &lt;j, IP address&gt; pairs.  Each element in this list tells the
   U-PE to set up j PWs to the specified IP address.  When the U-PE
   signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets
   the SAII to the PW number, and sets the TAII to null.







<span class="grey">Rosen, et al.                Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   In the above example, U-PE A would be told &lt;3, E&gt;, telling it to set
   up 3 PWs to E.  When signaling, A would set the AGI to the proper
   VPN-id, and would set the SAII to 1, 2, or 3, depending on which of
   the three PWs it is signaling.

   As a result of configuration/discovery, each N-PE must be given the
   following information for each VPLS:

   o  A "Local" list: {&lt;j, IP address&gt;}, where each element tells it to
      set up j PWs to the locally attached U-PE at the specified
      address.  The number of elements in this list will be n, the
      number of locally attached U-PEs in this VPLS.  In the above
      example, E would be given the local list: {&lt;3, A&gt;, &lt;3, B&gt;},
      telling it to set up 3 PWs to A and 3 to B.

   o  A local numbering, relative to the particular VPLS and the
      particular N-PE, of its U-PEs.  In the above example, E could be
      told that U-PE A is 1, and U-PE B is 2.

   o  A "Remote" list: {&lt;IP address, k&gt;}, telling it to set up k PWs,
      for each U-PE, to the specified IP address.  Each of these IP
      addresses identifies an N-PE, and k specifies the number of U-PEs
      at the N-PE that are in the VPLS.  In the above example, E would
      be given the remote list: {&lt;2, F&gt;}.  Since N-PE E has 2 U-PEs,
      this tells it to set up 4 PWs to N-PE F, 2 for each of its E's
      U-PEs.

   The signaling of a PW from N-PE to U-PE is based on the local list
   and the local numbering of U-PEs.  When signaling a particular PW
   from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII
   is set to null, and the TAII is set to the PW number (relative to
   that particular VPLS and U-PE).  In the above example, when E signals
   to A, it would set the TAII to be 1, 2, or 3, respectively, for the 3
   PWs it must set up to A.  It would similarly signal 3 PWs to B.

   The LSP signaled from U-PE to N-PE is associated with an LSP from
   N-PE to U-PE in the usual manner.  A PW between a U-PE and an N-PE is
   known as a "U-PW".

   The signaling of the appropriate set of PWs from N-PE to N-PE is
   based on the remote list.  The PWs between the N-PEs can all be
   considered equivalent.  As long as the correct total number of PWs
   are established, the N-PEs can splice these PWs to appropriate U-PWs.
   The signaling of the correct number of PWs from N-PE to N-PE is based
   on the remote list.  The remote list specifies the number of PWs to
   set up, per local U-PE, to a particular remote N-PE.





<span class="grey">Rosen, et al.                Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   When signaling a particular PW from an N-PE to an N-PE, the AGI is
   set to the appropriate VPN-id.  The TAII identifies the remote N-PE,
   as in the non-distributed case, i.e., it contains an IP address of
   the remote N-PE.  If there are n such PWs, they are distinguished by
   the setting of the SAII.  In order to allow multiple different SAII
   values in a single VPLS, the sending N-PE needs to have as many VSI-
   IDs as it has U-PEs.  As noted above in <a href="#section-3.2.2">Section 3.2.2</a>, this may be
   achieved by using an IP address of each attached U-PE, for example.
   A PW between two N-PEs is known as an "N-PW".

   Each U-PW must be "spliced" to an N-PW.  This is based on the remote
   list.  If the remote list contains an element &lt;i, F&gt;, then i U-PWs
   from each local U-PE must be spliced to i N-PWs from the remote N-PE
   F.  It does not matter which U-PWs are spliced to which N-PWs, as
   long as this constraint is met.

   If an N-PE has more than one local U-PE for a given VPLS, it must
   also ensure that a U-PW from each such U-PE is spliced to a U-PW from
   each of the other U-PEs.

<span class="h4"><a class="selflink" id="section-3.5.2" href="#section-3.5.2">3.5.2</a>.  Provisioning and Discovery</span>

   Every N-PE must be provisioned with the set of VPLS instances it
   supports, a VPN-id for each one, and a list of local U-PEs for each
   such VPLS.  As part of the discovery procedure, the N-PE advertises
   the number of U-PEs for each VPLS.  See <a href="#section-3.2.2">Section 3.2.2</a> for details.

   Auto-discovery (e.g., BGP-based) can be used to discover all the
   other N-PEs in the VPLS, and for each, the number of U-PEs local to
   that N-PE.  From this, one can compute the total number of U-PEs in
   the VPLS.  This information is sufficient to enable one to compute
   the local list and the remote list for each N-PE.

<span class="h4"><a class="selflink" id="section-3.5.3" href="#section-3.5.3">3.5.3</a>.  Non-Distributed VPLS as a Sub-Case</span>

   A PE that is providing "non-distributed VPLS" (i.e., a PE that
   performs both the U-PE and N-PE functions) can interoperate with
   N-PE/U-PE pairs that are providing distributed VPLS.  The "non-
   distributed PE" simply advertises, in the discovery procedure, that
   it has one local U-PE per VPLS.  And of course, the non-distributed
   PE does no PW switching.

   If every PE in a VPLS is providing non-distributed VPLS, and thus
   every PE is advertising itself as an N-PE with one local U-PE, the
   resultant signaling is exactly the same as that specified in
   <a href="#section-3.2.3">Section 3.2.3</a> above.





<span class="grey">Rosen, et al.                Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


<span class="h4"><a class="selflink" id="section-3.5.4" href="#section-3.5.4">3.5.4</a>.  Splicing and the Data Plane</span>

   Splicing two PWs together is quite straightforward in the MPLS data
   plane, as moving a packet from one PW directly to another is just a
   'label replace' operation on the PW label.  When a PW consists of two
   or more PWs spliced together, it is assumed that the data will go to
   the node where the splicing is being done, i.e., that the data path
   will pass through the nodes that participate in PW signaling.

   Further details on splicing are discussed in [<a href="./rfc6073" title="&quot;Segmented Pseudowire&quot;">RFC6073</a>].

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Inter-AS Operation</span>

   The provisioning, auto-discovery, and signaling mechanisms described
   above can all be applied in an inter-AS environment.  As in
   [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>], there are a number of options for inter-AS operation.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Multihop EBGP Redistribution of L2VPN NLRIs</span>

   This option is most like option (c) in [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>].  That is, we use
   multihop External BGP (EBGP) redistribution of L2VPN NLRIs between
   source and destination ASes, with EBGP redistribution of labeled IPv4
   or IPv6 routes from AS to neighboring AS.

   An Autonomous System Border Router (ASBR) must maintain labeled IPv4
   /32 (or IPv6 /128) routes to the PE routers within its AS.  It uses
   EBGP to distribute these routes to other ASes, and sets itself as the
   BGP next hop for these routes.  ASBRs in any transit ASes will also
   have to use EBGP to pass along the labeled /32 (or /128) routes.
   This results in the creation of a set of label switched paths from
   all ingress PE routers to all egress PE routers.  Now, PE routers in
   different ASes can establish multi-hop EBGP connections to each other
   and can exchange L2VPN NLRIs over those connections.  Following such
   exchanges, a pair of PEs in different ASes could establish an LDP
   session to signal PWs between each other.

   For VPLS, the BGP advertisement and PW signaling are exactly as
   described in <a href="#section-3.2">Section 3.2</a>.  As a result of the multihop EBGP session
   that exists between source and destination AS, the PEs in one AS that
   have VSIs of a certain VPLS will discover the PEs in another AS that
   have VSIs of the same VPLS.  These PEs will then be able to establish
   the appropriate PW signaling protocol session and establish the full
   mesh of VSI-VSI pseudowires to build the VPLS as described in
   <a href="#section-3.2.3">Section 3.2.3</a>.

   For VPWS, the BGP advertisement and PW signaling are exactly as
   described in <a href="#section-3.3">Section 3.3</a>.  As a result of the multihop EBGP session
   that exists between source and destination AS, the PEs in one AS that



<span class="grey">Rosen, et al.                Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   have pools of a certain color (VPN) will discover PEs in another AS
   that have pools of the same color.  These PEs will then be able to
   establish the appropriate PW signaling protocol session and establish
   the full mesh of pseudowires as described in <a href="#section-3.2.3">Section 3.2.3</a>.  A
   partial mesh can similarly be established using the procedures of
   <a href="#section-3.4">Section 3.4</a>.

   As in Layer 3 VPNs, building an L2VPN that spans the networks of more
   than one provider requires some co-ordination in the use of RTs and
   RDs.  This subject is discussed in more detail in <a href="#section-4.4">Section 4.4</a>.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  EBGP Redistribution of L2VPN NLRIs with Multi-Segment Pseudowires</span>

   A possible drawback of the approach of the previous section is that
   it creates PW signaling sessions among all the PEs of a given L2VPN
   (VPLS or VPWS).  This means a potentially large number of LDP or
   L2TPv3 sessions will cross the AS boundary and that these sessions
   connect to many devices within an AS.  In the case where the ASes
   belong to different providers, one might imagine that providers would
   like to have fewer signaling sessions crossing the AS boundary and
   that the entities that terminate the sessions could be restricted to
   a smaller set of devices.  Furthermore, by forcing the LDP or L2TPv3
   signaling sessions to terminate on a small set of ASBRs, a provider
   could use standard authentication procedures on a small set of inter-
   provider sessions.  These concerns motivate the approach described
   here.

   [<a id="ref-RFC6073">RFC6073</a>] describes an approach to "switching" packets from one
   pseudowire to another at a particular node.  This approach allows an
   end-to-end, multi-segment pseudowire to be constructed out of several
   pseudowire segments, without maintaining an end-to-end control
   connection.  We can use this approach to produce an inter-AS solution
   that more closely resembles option (b) in [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>].

   In this model, we use EBGP redistribution of L2VPN NLRI from AS to
   neighboring AS.  First, the PE routers use Internal BGP (IBGP) to
   redistribute L2VPN NLRI either to an ASBR, or to a route reflector of
   which an ASBR is a client.  The ASBR then uses EBGP to redistribute
   those L2VPN NLRI to an ASBR in another AS, which in turn distributes
   them to the PE routers in that AS, or perhaps to another ASBR which
   in turn distributes them, and so on.

   In this case, a PE can learn the address of an ASBR through which it
   could reach another PE to which it wishes to establish a PW.  That
   is, a local PE will receive a BGP advertisement containing L2VPN NLRI
   corresponding to an L2VPN instance in which the local PE has some
   attached members.  The BGP next-hop for that L2VPN NLRI will be an
   ASBR of the local AS.  Then, rather than building a control



<span class="grey">Rosen, et al.                Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   connection all the way to the remote PE, it builds one only to the
   ASBR.  A pseudowire segment can now be established from the PE to the
   ASBR.  The ASBR in turn can establish a PW to the ASBR of the next
   AS, and splice that PW to the PW from the PE as described in
   <a href="#section-3.5.4">Section 3.5.4</a> and [<a href="./rfc6073" title="&quot;Segmented Pseudowire&quot;">RFC6073</a>].  Repeating the process at each ASBR
   leads to a sequence of PW segments that, when spliced together,
   connect the two PEs.

   Note that in the approach just described, the local PE may never
   learn the IP address of the remote PE.  It learns the L2VPN NLRI
   advertised by the remote PE, which need not contain the remote PE
   address, and it learns the IP address of the ASBR that is the BGP
   next hop for that NLRI.

   When this approach is used for VPLS, or for full-mesh VPWS, it leads
   to a full mesh of pseudowires among the PEs, just as in the previous
   section, but it does not require a full mesh of control connections
   (LDP or L2TPv3 sessions).  Instead, the control connections within a
   single AS run among all the PEs of that AS and the ASBRs of the AS.
   A single control connection between the ASBRs of adjacent ASes can be
   used to support however many AS-to-AS pseudowire segments are needed.

   Note that the procedures described here will result in the splicing
   points (PW Switching PEs (S-PEs) in the terminology of [<a href="./rfc5659" title="&quot;An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge&quot;">RFC5659</a>])
   being co-located with the ASBRs.  It is of course possible to have
   multiple ASBR-ASBR connections between a given pair of ASes.  In this
   case, a given PE could choose among the available ASBRs based on a
   range of criteria, such as IGP metric, local configuration, etc.,
   analogous to choosing an exit point in normal IP routing.  The use of
   multiple ASBRs would lead to greater resiliency (at the timescale of
   BGP routing convergence) since a PE could select a new ASBR in the
   event of the failure of the one currently in use.

   As in layer 3 VPNs, building an L2VPN that spans the networks of more
   than one provider requires some co-ordination in the use of RTs and
   RDs.  This subject is discussed in more detail in <a href="#section-4.4">Section 4.4</a>.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Inter-Provider Application of Distributed VPLS Signaling</span>

   An alternative approach to inter-provider VPLS can be derived from
   the Distributed VPLS approach described above.  Consider the
   following topology:

   PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B
                            Router 12    Router 21       |
                                                         |
                                                        PE C




<span class="grey">Rosen, et al.                Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are
   networks of different service providers.  Border Router 12 is Network
   1's border router to network 2, and Border Router 21 is Network 2's
   border router to Network 1.  We suppose further that the PEs are not
   "distributed", i.e, that each provides both the U-PE and N-PE
   functions.

   In this topology, one needs two inter-provider pseudowires: A-B and
   A-C.

   Suppose a service provider decides, for whatever reason, that it does
   not want each of its PEs to have a control connection to any PEs in
   the other network.  Rather, it wants the inter-provider control
   connections to run only between the two border routers.

   This can be achieved using the techniques of <a href="#section-3.5">Section 3.5</a>, where the
   PEs behave like U-PEs, and the BRs behave like N-PEs.  In the example
   topology, PE A would behave like a U-PE that is locally attached to
   BR12; PEs B and C would be have like U-PEs that are locally attached
   to BR21; and the two BRs would behave like N-PEs.

   As a result, the PW from A to B would consist of three segments:
   A-BR12, BR12-BR21, and BR21-B.  The border routers would have to
   splice the corresponding segments together.

   This requires the PEs within a VPLS to be numbered from 1-n (relative
   to that VPLS) within a given network.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  RT and RD Assignment Considerations</span>

   We note that, in order for any of the inter-AS procedures described
   above to work correctly, the two ASes must use RTs and RDs
   consistently, just as in Layer 3 VPNs [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>].  The structure of
   RTs and RDs is such that there is not a great risk of accidental
   collisions.  The main challenge is that it is necessary for the
   operator of one AS to know what RT or RTs have been chosen in another
   AS for any VPN that has sites in both ASes.  As in Layer 3 VPNs,
   there are many ways to make this work, but all require some co-
   operation among the providers.  For example, provider A may tag all
   the NLRI for a given VPN with a single RT, say RT_A, and provider B
   can then configure the PEs that connect to sites of that VPN to
   import NLRI that contains that RT.  Provider B can choose a different
   RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A
   can import NLRI with that RT at the appropriate PEs.  However, this
   does require both providers to communicate their choice of RTs for
   each VPN.  Alternatively, both providers could agree to use a common
   RT for a given VPN.  In any case, communication of RTs between the




<span class="grey">Rosen, et al.                Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   providers is essential.  As in Layer 3 VPNs, providers may configure
   RT filtering to ensure that only coordinated RT values are allowed
   across the AS boundary.

   Note that a single VPN identifier (carried in a BGP Extended
   Community) is required for each VPLS or VPWS instance.  The encoding
   rules for these identifiers [<a href="./rfc4360" title="&quot;BGP Extended Communities Attribute&quot;">RFC4360</a>] ensure that collisions do not
   occur with other providers.  However, for a single VPLS or VPWS
   instance that spans the networks of two or more providers, one
   provider will need to allocate the identifier and communicate this
   choice to the other provider(s), who must use the same value for
   sites in the same VPLS or VPWS instance.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   This document describes a number of different L2VPN provisioning
   models, and specifies the endpoint identifiers that are required to
   support each of the provisioning models.  It also specifies how those
   endpoint identifiers are mapped into fields of auto-discovery
   protocols and signaling protocols.

   The security considerations related to the signaling protocols are
   discussed in the relevant protocol specifications ([<a href="./rfc5036" title="&quot;LDP Specification&quot;">RFC5036</a>],
   [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>], [<a href="./rfc3931" title="&quot;Layer Two Tunneling Protocol - Version 3 (L2TPv3)&quot;">RFC3931</a>], and [<a href="./rfc4667" title="&quot;Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)&quot;">RFC4667</a>]).

   The security considerations related to BGP-based auto-discovery,
   including inter-AS issues, are discussed in [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>].  L2VPNs that
   use BGP-based auto-discovery may automate setup of security
   mechanisms as well.  Specification of automated security mechanisms
   are outside the scope of this document, but are recommended as a
   future work item.

   The security considerations related to the particular kind of L2VPN
   service being supported are discussed in [<a href="./rfc4664" title="&quot;Framework for Layer 2 Virtual Private Networks (L2VPNs)&quot;">RFC4664</a>], [<a href="./rfc4665" title="&quot;Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks&quot;">RFC4665</a>], and
   [<a href="./rfc4762" title="&quot;Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling&quot;">RFC4762</a>].

   The way in which endpoint identifiers are mapped into protocol fields
   does not create any additional security issues.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IANA Considerations</span>

   IANA has assigned an AFI and a SAFI for L2VPN NLRI.  Both the AFI and
   SAFI are the same as the values assigned for [<a href="./rfc4761" title="&quot;Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling&quot;">RFC4761</a>].  That is, the
   AFI is 25 (L2VPN) and the SAFI is 65 (already allocated for VPLS).
   The same AFI and SAFI are used for both VPLS and VPWS auto-discovery
   as described in this document.





<span class="grey">Rosen, et al.                Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   [<a id="ref-RFC4446">RFC4446</a>] defines registries for "Attachment Group Identifier (AGI)
   Type" and "Attachment Individual Identifier (AII) Type".  Type 1 in
   each registry has been assigned to the AGI and AII formats defined in
   this document.

   IANA has assigned two new LDP status codes.  IANA already maintains a
   registry of name "STATUS CODE NAME SPACE" defined by [<a href="./rfc5036" title="&quot;LDP Specification&quot;">RFC5036</a>].  The
   following values have been assigned:

   0x00000030 Attachment Circuit bound to different PE

   0x0000002D Attachment Circuit bound to different remote Attachment
   Circuit

   Two new L2TP Result Codes have been registered for the CDN message.
   IANA already maintains a registry of L2TP Result Code Values for the
   CDN message, defined by [<a href="./rfc3438" title="&quot;Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update&quot;">RFC3438</a>].  The following values have been
   assigned:

   27: Attachment Circuit bound to different PE

   28: Attachment Circuit bound to different remote Attachment Circuit

   [<a id="ref-RFC4360">RFC4360</a>] defines a registry entitled "Two-octet AS Specific Extended
   Community".  IANA has assigned a value in this registry from the
   "transitive" range (0x0000-0x00FF).  The value is as follows:

   o  0x000A Two-octet AS specific Layer 2 VPN Identifier

   [<a id="ref-RFC4360">RFC4360</a>] defines a registry entitled "IPv4 Address Specific Extended
   Community".  IANA has assigned a value in this registry from the
   "transitive" range (0x0100-0x01FF).  The value is as follows:

   o  0x010A Layer 2 VPN Identifier

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  BGP-AD and VPLS-BGP Interoperability</span>

   Both BGP-AD and VPLS-BGP [<a href="./rfc4761" title="&quot;Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling&quot;">RFC4761</a>] use the same AFI/SAFI.  In order
   for both BGP-AD and VPLS-BGP to co-exist, the NLRI length must be
   used as a demultiplexer.

   The BGP-AD NLRI has an NLRI length of 12 bytes, containing only an
   8-byte RD and a 4-byte VSI-ID.  VPLS-BGP [<a href="./rfc4761" title="&quot;Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling&quot;">RFC4761</a>] uses a 17-byte
   NLRI length.  Therefore, implementations of BGP-AD must ignore NLRI
   that are greater than 12 bytes.






<span class="grey">Rosen, et al.                Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgments</span>

   Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca
   Martini, Dave McDysan, Francois Le Faucheur, Russ Gardo, Keyur Patel,
   Sam Henderson, and Matthew Bocci for their comments, criticisms, and
   helpful suggestions.

   Thanks to Tissa Senevirathne, Hamid Ould-Brahim, and Yakov Rekhter
   for discussing the auto-discovery issues.

   Thanks to Vach Kompella for a continuing discussion of the proper
   semantics of the generalized identifiers.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3438">RFC3438</a>]  Townsley, W., "Layer Two Tunneling Protocol (L2TP)
              Internet Assigned Numbers Authority (IANA) Considerations
              Update", <a href="https://www.rfc-editor.org/bcp/bcp68">BCP 68</a>, <a href="./rfc3438">RFC 3438</a>, December 2002.

   [<a id="ref-RFC3931">RFC3931</a>]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", <a href="./rfc3931">RFC 3931</a>, March 2005.

   [<a id="ref-RFC4360">RFC4360</a>]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", <a href="./rfc4360">RFC 4360</a>, February 2006.

   [<a id="ref-RFC4364">RFC4364</a>]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", <a href="./rfc4364">RFC 4364</a>, February 2006.

   [<a id="ref-RFC4447">RFC4447</a>]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April 2006.

   [<a id="ref-RFC4667">RFC4667</a>]  Luo, W., "Layer 2 Virtual Private Network (L2VPN)
              Extensions for Layer 2 Tunneling Protocol (L2TP)",
              <a href="./rfc4667">RFC 4667</a>, September 2006.

   [<a id="ref-RFC4760">RFC4760</a>]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", <a href="./rfc4760">RFC 4760</a>,
              January 2007.

   [<a id="ref-RFC5036">RFC5036</a>]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", <a href="./rfc5036">RFC 5036</a>, October 2007.




<span class="grey">Rosen, et al.                Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


   [<a id="ref-RFC6073">RFC6073</a>]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
              Aissaoui, "Segmented Pseudowire", <a href="./rfc6073">RFC 6073</a>, January 2011.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-RFC3985">RFC3985</a>]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", <a href="./rfc3985">RFC 3985</a>, March 2005.

   [<a id="ref-RFC4026">RFC4026</a>]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", <a href="./rfc4026">RFC 4026</a>, March 2005.

   [<a id="ref-RFC4446">RFC4446</a>]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", <a href="https://www.rfc-editor.org/bcp/bcp116">BCP 116</a>, <a href="./rfc4446">RFC 4446</a>, April 2006.

   [<a id="ref-RFC4664">RFC4664</a>]  Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
              Private Networks (L2VPNs)", <a href="./rfc4664">RFC 4664</a>, September 2006.

   [<a id="ref-RFC4665">RFC4665</a>]  Augustyn, W. and Y. Serbest, "Service Requirements for
              Layer 2 Provider-Provisioned Virtual Private Networks",
              <a href="./rfc4665">RFC 4665</a>, September 2006.

   [<a id="ref-RFC4761">RFC4761</a>]  Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
              (VPLS) Using BGP for Auto-Discovery and Signaling",
              <a href="./rfc4761">RFC 4761</a>, January 2007.

   [<a id="ref-RFC4762">RFC4762</a>]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
              <a href="./rfc4762">RFC 4762</a>, January 2007.

   [<a id="ref-RFC5003">RFC5003</a>]  Metz, C., Martini, L., Balus, F., and J. Sugimoto,
              "Attachment Individual Identifier (AII) Types for
              Aggregation", <a href="./rfc5003">RFC 5003</a>, September 2007.

   [<a id="ref-RFC5659">RFC5659</a>]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation Edge-to-Edge", <a href="./rfc5659">RFC 5659</a>,
              October 2009.















<span class="grey">Rosen, et al.                Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6074">RFC 6074</a>                     L2VPN Signaling                January 2011</span>


Authors' Addresses

   Eric Rosen
   Cisco Systems, Inc.
   1414 Mass. Ave.
   Boxborough, MA  01719
   USA

   EMail: erosen@cisco.com


   Bruce Davie
   Cisco Systems, Inc.
   1414 Mass. Ave.
   Boxborough, MA  01719
   USA

   EMail: bsd@cisco.com


   Vasile Radoaca
   Alcatel-Lucent
   Think Park Tower 6F
   2-1-1 Osaki, Tokyo, 141-6006
   Japan

   EMail: vasile.radoaca@alcatel-lucent.com


   Wei Luo

   EMail: luo@weiluo.net



















Rosen, et al.                Standards Track                   [Page 32]
</pre>