[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 RFC 6074

Network Working Group                                           E. Rosen
Internet-Draft                                                    W. Luo
Expires: January 19, 2006                                       B. Davie
                                                     Cisco Systems, Inc.
                                                              V. Radoaca
                                                         Nortel Networks
                                                           July 18, 2005


    Provisioning Models and Endpoint Identifiers in L2VPN Signaling
                   draft-ietf-l2vpn-signaling-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   There are a number of different kinds of "Provider Provisioned Layer
   2 VPNs" (L2VPNs).  The 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".



Rosen, et al.           Expires January 19, 2006                [Page 1]

Internet-Draft               L2VPN Signaling                   July 2005


   When the discovery process is complete, a signaling protocol is
   automatically invoked.  The signaling protocol sets up the mesh of
   Pseudowires (PWs) that form the (virtual) backbone of the L2VPN.  Any
   PW signaling protocol needs to have a method which allows each PW
   endpoint to identify the other; thus a PW signaling protocol will
   have the notion of an endpoint identifier.  The semantics of the
   endpoint identifiers which the signaling protocol uses for a
   particular type of L2VPN are determined by the provisioning model.
   This document specifies a number of L2VPN provisioning models, and
   further specifies the semantic structure of the endpoint identifiers
   required by each provisioning model.  It discusses the way in which
   the endpoint identifiers are distributed by the discovery process,
   especially when the discovery process is based upon 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 (L2TPv3).


































Rosen, et al.           Expires January 19, 2006                [Page 2]

Internet-Draft               L2VPN Signaling                   July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Signaling Protocol Framework . . . . . . . . . . . . . . . . .  7
     2.1   Endpoint Identification  . . . . . . . . . . . . . . . . .  7
     2.2   Creating a Single Bidirectional Pseudowire . . . . . . . .  8
     2.3   Attachment Identifiers and Forwarders  . . . . . . . . . .  9

   3.  Applications . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.1   Individual Point-to-Point VCs  . . . . . . . . . . . . . . 11
       3.1.1   Provisioning Models  . . . . . . . . . . . . . . . . . 11
         3.1.1.1   Double Sided Provisioning  . . . . . . . . . . . . 11
         3.1.1.2   Single Sided Provisioning with Discovery . . . . . 11
       3.1.2   Signaling  . . . . . . . . . . . . . . . . . . . . . . 12
     3.2   Virtual Private LAN Service  . . . . . . . . . . . . . . . 13
       3.2.1   Provisioning . . . . . . . . . . . . . . . . . . . . . 13
       3.2.2   Auto-Discovery . . . . . . . . . . . . . . . . . . . . 13
         3.2.2.1   BGP-based auto-discovery . . . . . . . . . . . . . 14
       3.2.3   Signaling  . . . . . . . . . . . . . . . . . . . . . . 15
       3.2.4   Pseudowires as VPLS Attachment Circuits  . . . . . . . 16
     3.3   Colored Pools: Full Mesh of Point-to-Point VCs . . . . . . 16
       3.3.1   Provisioning . . . . . . . . . . . . . . . . . . . . . 16
       3.3.2   Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17
         3.3.2.1   BGP-based auto-discovery . . . . . . . . . . . . . 17
       3.3.3   Signaling  . . . . . . . . . . . . . . . . . . . . . . 18
     3.4   Colored Pools: Partial Mesh  . . . . . . . . . . . . . . . 19
     3.5   Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 19
       3.5.1   Signaling  . . . . . . . . . . . . . . . . . . . . . . 21
       3.5.2   Provisioning and Discovery . . . . . . . . . . . . . . 23
       3.5.3   Non-distributed VPLS as a sub-case . . . . . . . . . . 23
       3.5.4   Splicing and the Data Plane  . . . . . . . . . . . . . 23

   4.  Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 25
     4.1   Multihop EBGP redistribution of L2VPN NLRIs  . . . . . . . 25
     4.2   EBGP redistribution of L2VPN NLRIs with  Pseudowire
           Switching  . . . . . . . . . . . . . . . . . . . . . . . . 25
     4.3   Inter-Provider Application of Dist. VPLS Signaling . . . . 27

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30

   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31

   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 32

   9.  Informative References . . . . . . . . . . . . . . . . . . . . 33



Rosen, et al.           Expires January 19, 2006                [Page 3]

Internet-Draft               L2VPN Signaling                   July 2005


       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33

       Intellectual Property and Copyright Statements . . . . . . . . 35
















































Rosen, et al.           Expires January 19, 2006                [Page 4]

Internet-Draft               L2VPN Signaling                   July 2005


1.  Introduction

   [L2VPN-FW] 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 which 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 PPVPN provisioning
   models, and specifies the semantic structure of the endpoint
   identifiers required for each provisioning model.

   Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or
   L2TP version 3 (as specified in [L2TP-BASE] and extended in [L2TP-
   L2VPN]) can be used as signaling protocols to set up and maintain
   pseudowires (PWs) [PWE3-ARCH].  Any protocol which 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 [L2VPN-FW], [L2VPN-TERM], and
   [PWE3-ARCH], in particular the terms "Attachment Circuit",
   "pseudowire", "PE", "CE".

   Section 2 provides an overview of the relevant aspects of [PWE3-
   CONTROL] and [L2TP-L2VPN].

   Section 3 details various provisioning models and relates them to the
   signaling process and to the discovery process.

   Section 4 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.




Rosen, et al.           Expires January 19, 2006                [Page 5]

Internet-Draft               L2VPN Signaling                   July 2005


   We do not specify an auto-discovery procedure in this draft, but we
   do specify the information which needs to be obtained via auto-
   discovery in order for the signaling procedures to begin.  The way in
   which the signaling mechanisms can be integrated with BGP-based auto-
   discovery is covered in some detail.

   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 RFC 2119










































Rosen, et al.           Expires January 19, 2006                [Page 6]

Internet-Draft               L2VPN Signaling                   July 2005


2.  Signaling Protocol Framework

2.1  Endpoint Identification

   Per [L2VPN-FW], a pseudowire can be thought of as a relationship
   between a pair of "Forwarders".  In simple instances of 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 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 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 [PWE3-CONTROL], the term "Attachment Identifier", or
   "AI", is used to refer to a quantity whose purpose is to identify a
   Forwarder.  In [L2TP-L2VPN], the term "Forwarder Identifier" is used
   for the same purpose.  In the context of this document, "Attachment
   Identifier" and "Forwarder Identifier" are used interchangeably.

   [PWE3-CONTROL] specifies two 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 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



Rosen, et al.           Expires January 19, 2006                [Page 7]

Internet-Draft               L2VPN Signaling                   July 2005


   the concatenation of the AGI and the SAII, while the TAI is the
   concatenation of the AGI and the TAII.

   Similarly, [L2TP-L2VPN] 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 [L2TP-L2VPN] is an equivalent term as
   Attachment Identifier in [PWE3-CONTROL].  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 an operator
   who chooses to use the AII structure defined here would not be at
   liberty to use a completely different structure for these identifiers
   for some other application.  For example, it would be unwise to use
   ASCII strings for AII values when setting up individual pseudowires
   and at the same time to use the <RT:PE_address> structure for AII
   values in VPLS signaling.

2.2  Creating a Single Bidirectional Pseudowire

   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 PPVPN provisioning models, the two endpoints of a
   given PW can simultaneously initiate the signaling for it.  They must



Rosen, et al.           Expires January 19, 2006                [Page 8]

Internet-Draft               L2VPN Signaling                   July 2005


   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 is
   described in [L2TP-L2VPN]

2.3  Attachment Identifiers and Forwarders

   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 <PE
   router, AI> must be globally unique.

   It is frequently convenient to a set of Forwarders as being members
   of a particular "group", where PWs may only be set up among members
   of a group.  In such cases, it is convenient to identify the
   Forwarders relative to the group, so that an Attachment Identifier
   would consist of  an Attachment Group Identifier (AGI) plus an
   Attachment Individual Identifier (AII).

   IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING
   WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN
   [PWE3-CONTROL].

   An Attachment  Group Identifier  may be thought  of as  a VPN-id, or
   a VLAN identifier, some  attribute which  is shared by  all the
   Attachment Circuits (or pools thereof) which are allowed to be
   connected.

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

   We can now consider an LSP to be identified by:





Rosen, et al.           Expires January 19, 2006                [Page 9]

Internet-Draft               L2VPN Signaling                   July 2005


   o  <PE1, <AGI, AII1>, PE2, <AGI, AII2>>

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

   o  <PE2, <AGI, AII2>, PE1, <AGI, AII1>>

   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 which  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 which 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 which 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.  So as far as
   the signaling procedures are concerned, the TAI is really just an
   arbitrary string of bytes, a "cookie".











Rosen, et al.           Expires January 19, 2006               [Page 10]

Internet-Draft               L2VPN Signaling                   July 2005


3.  Applications

   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.

3.1  Individual Point-to-Point VCs

   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.

3.1.1  Provisioning Models

3.1.1.1  Double Sided Provisioning

   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, 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.

3.1.1.2  Single Sided Provisioning with Discovery

   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 which 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
   course is the local name of the other Attachment Circuit).  Neither



Rosen, et al.           Expires January 19, 2006               [Page 11]

Internet-Draft               L2VPN Signaling                   July 2005


   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
   <VPN-id, local AII> pairs.  Each PE compares its local <VPN-id,
   remote AII> pairs with the <VPN-id, local AII> pairs advertised by
   the other PEs.  If PE1 has a local <VPN-id, remote AII> pair with
   value <V, fred>, and PE2 has a local <VPN-id, local AII> pair with
   value <V, fred>, 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 he 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 Section 3.3 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 AC names in
   this simple scheme).

3.1.2  Signaling

   The LDP-based signaling follows the procedures specified in [PWE3-
   CONTROL].  That is, one PE (PE1) sends a Label Mapping Message to
   another PE (PE2) to establish a pseudowire in one direction.  If that
   message is processed successfully, and there is not yet a pseudowire
   in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping
   Message to PE1.

   In addition to the procedures of [PWE3-CONTROL], when a PE receives a
   Label Mapping Message, and the TAI identifies a particular Attachment
   Circuit which 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
   Status Code meaning "Attachment Circuit bound to different remote
   Attachment Circuit", and the processing of the Mapping message is



Rosen, et al.           Expires January 19, 2006               [Page 12]

Internet-Draft               L2VPN Signaling                   July 2005


   complete.

   Similarly with the L2TP-based signaling, when a PE receives an ICRQ
   message, and the TAI identifies a particular Attachment Circuit which
   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.

3.2  Virtual Private LAN Service

   In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits
   can be though of as LAN interfaces which attach to "virtual LAN
   switches", or, in the terminology of [L2VPN-FW], "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 [L2VPN-
   REQ, VPLS] requires that a single pseudowire be created between each
   pair of VSIs that are in the same VPLS.  Each PE device may have a
   multiple VSIs, where each VSI belongs to a different VPLS.

3.2.1  Provisioning

   Each VPLS must have a globally unique identifier, which we call a
   VPN-id.  Every VSI must be configured with the VPN-id of the VPLS to
   which it belongs.

   Each VSI must also have a unique identifier, but this can be formed
   automatically by concatenating its VPN-id with the 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.)

3.2.2  Auto-Discovery





Rosen, et al.           Expires January 19, 2006               [Page 13]

Internet-Draft               L2VPN Signaling                   July 2005


3.2.2.1  BGP-based auto-discovery

   The framework for BGP-based auto-discovery for a VPLS service is as
   specified in [BGP-AUTO], section 3.2.

   The AFI/SAFI used would be:

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

   o  An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS)
      service whose pseudowires are set up using the procedures
      described in the current document.

   In order to use BGP-based auto-discovery as specified in [BGP-AUTO],
   the globally unique identifier associated with a VPLS must be
   encodable as an 8-byte Route Distinguisher (RD).  If the globally
   unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded
   as an RD as specified in [BGP-AUTO].  However, any other method of
   assigning a unique identifier to a VPLS and encoding it as an RD
   (using the encoding techniques of [RFC2547bis]) will do.

   Each VSI needs to have a unique identifier, which can be encoded as a
   BGP NLRI.  This is formed by prepending the RD (from the previous
   paragraph) to an IP address of the PE containing the virtual LAN
   switch.  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.  An alternate numbering scheme (e.g.
   numbering the VSIs of a single VPN from 1 to n) could be used if
   desired.

   (Note also that it is not strictly necessary for all the VSIs in the
   same VPLS to have the same RD, all that is really necessary is that
   the NLRI uniquely identify a virtual LAN switch.)

   Each VSI needs to be associated with one or more Route Target (RT)
   Extended Communities, as discussed in [BGP-AUTO}.  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 has a VSI with a particular RT, it can then receive all the
   NLRI which have that same RT, and from the BGP next hop attribute of



Rosen, et al.           Expires January 19, 2006               [Page 14]

Internet-Draft               L2VPN Signaling                   July 2005


   these NLRI will learn the IP addresses of the other PE routers which
   have VSIs with the same RT.  The considerations of [RFC2547bis]
   section 4.3.3 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.  If a particular VPLS
   consists of multiple VLANs, each VLAN must have its own unique RT.  A
   VSI can be placed in multiple VLANS (or even in multiple VPLSes) by
   assigning it multiple RTs.

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

   If Distributed VPLS (described in Section 3.5) is deployed, only the
   N-PEs participate in BGP-based autodiscovery.  This means that an
   N-PE would need to advertise reachability to each of the VSIs that it
   supports, including those located in 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.

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

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

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

   o  an extended community attribute containing one or more RTs


3.2.3  Signaling

   It is necessary to create Attachment Identifiers which identify the
   VSIs.  In the preceding section, a VSI-ID was encoded as RD:PE_addr
   for the purposes of autodiscovery.  For signaling purposes, the same
   information is carried but is encoded slightly differently.  Noting
   that the RD is effectively a VPN identifier, we therefore encode the
   RD in the AGI field, and place the PE_addr in the TAII field.  The
   SAII can be null.

   The AGI field therefore consists of a length field of value 8,
   followed by the 8 bytes of the RD.  The TAII consists of a length
   field of value 4 followed by the 4-byte PE address.

   Note that it is not possible using this technique to set up more than



Rosen, et al.           Expires January 19, 2006               [Page 15]

Internet-Draft               L2VPN Signaling                   July 2005


   one PW per pair of VSIs.

3.2.4  Pseudowires as VPLS Attachment Circuits

   It is also possible using this technique to set up a PW which
   attaches at one endpoint to a VSI, but at the other endpoint only to
   an Attachment Circuit.  However, in this case there may be more than
   one PW between a pair of PEs, so that AIIs cannot be null.  Rather,
   each such PW must have AII which is unique relative to the VPN-id.
   This value would be carried in both the SAII and the TAII field of
   the signaling messages.

3.3  Colored Pools: Full Mesh of Point-to-Point VCs

   In the "Colored Pools" model of operation, 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 VCs for each
   VPN.

3.3.1  Provisioning

   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, 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.  This issue is independent of the procedures
   described in this document.]

   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.



Rosen, et al.           Expires January 19, 2006               [Page 16]

Internet-Draft               L2VPN Signaling                   July 2005


   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.

3.3.2  Auto-Discovery

3.3.2.1  BGP-based auto-discovery

   The framework for BGP-based auto-discovery for a colored pool service
   is as specified in [BGP-AUTO], section 3.2.

   The AFI/SAFI used would be:

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

   o  An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS)
      service whose pseudowires are set up using the procedures
      described in the current document.

   In order to use BGP-based auto-discovery, the color associated with a
   colored pool must be encodable as both an RT (Route Target) and an RD
   (Route Distinguisher).  The globally unique identifier of a pool must
   be encodable as NLRI; the color would be encoded as the RD and the
   pool identifier as a four-byte quantity which is appended to the RD
   to create the NLRI.

   Auto-discovery procedures 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 has a pool with a particular color, it can then receive all
   the NLRI which have that same color, and from the BGP next hop
   attribute of these NLRI will learn the IP addresses of the other PE
   routers which have pools switches with the same color.  It also
   learns the unique identifier of each such remote pool, as this is



Rosen, et al.           Expires January 19, 2006               [Page 17]

Internet-Draft               L2VPN Signaling                   July 2005


   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 = TBD, encoded as RD:pool_num;

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

   o  an extended community attribute containing one or more RTs.


3.3.3  Signaling

   The LDP-based signaling follows the procedures specified in [PWE3-
   CONTROL].  That is, one PE (PE1) sends a Label Mapping Message to
   another PE (PE2) to establish a pseudowire in one direction.  If that
   message is processed successfully, and there is not yet a pseudowire
   in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping
   Message to PE1.  Similarly, the L2TPv3-based signaling follows the
   procedures of [L2TP-BASE].  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 color as the AGI, the local
   pool's relative identifier as the SAII, and the remote pool's
   relative identifier as the TAII.

   When PE2 receives a Label Mapping message or an ICRQ message from
   PE1, and the TAI identifies to a pool, and there is already an
   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
   which is to be bound to the the pseudowire.  However, the remote PE
   may examine the SAII field to determine which Attachment Circuit
   should be bound to the pseudowire.






Rosen, et al.           Expires January 19, 2006               [Page 18]

Internet-Draft               L2VPN Signaling                   July 2005


3.4  Colored Pools: Partial Mesh

   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 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 which has X as one of its "export RTs".
      The signaling messages and procedures themselves are as in section
      3.3.3.

   As a simple example, consider the task of building a hub-and-spoke
   topology.  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.

3.5  Distributed VPLS

   In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), 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 other
   U-PE 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.

   Consider for example the following topology:









Rosen, et al.           Expires January 19, 2006               [Page 19]

Internet-Draft               L2VPN Signaling                   July 2005


           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 which 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.















Rosen, et al.           Expires January 19, 2006               [Page 20]

Internet-Draft               L2VPN Signaling                   July 2005


                      splicing points
                       |           |
                       V           V
      A-C PW    <-----><-----------><------>


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


      B-D PW    <-----><-----------><------>
                       ^           ^
                       |           |
                      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.

3.5.1  Signaling

   The signaling to support Distributed VPLS can be done with the
   mechanisms described in this paper.  However, the procedures for VPLS
   (section 3.2.3) 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 <j, IP address> 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.

   In the above example, U-PE A would be told <3, E>, telling it to set
   up 3 PWs to E. When signaling, A would set the AGI to the proper



Rosen, et al.           Expires January 19, 2006               [Page 21]

Internet-Draft               L2VPN Signaling                   July 2005


   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: {<j, IP address>}, 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: {<3, A>, <3, B>},
      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: {<IP address, k>}, telling it to set up k PWs,
      for each U-PE, to the specified IP address.  Each of these IP
      addresses identifies a N-PE, and k specifies the number of U-PEs
      at that N-PE which are in the VPLS.  In the above example, E would
      be given the remote list: {<2, F>}.  Since N-PE E has two 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
   three PWs it must set up to A. It would similarly signal three 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.

   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,



Rosen, et al.           Expires January 19, 2006               [Page 22]

Internet-Draft               L2VPN Signaling                   July 2005


   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, which will be a number from 1 to n inclusive.  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 <i, F>, 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.

3.5.2  Provisioning and Discovery

   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 Section 3.2.2 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.

3.5.3  Non-distributed VPLS as a sub-case

   A PE which is providing "non-distributed VPLS" (i.e., a PE which
   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 splicing.

   If every PE in a VPLS is providing non-distributed VPLS, and thus
   every PE advertises itself as an N-PE with one local U-PE, the
   resultant signaling is exactly the same as that specified in section
   3.2.3 above, except that an SAII value of 1 is used instead of null.
   (A PE providing non-distributed VPLS should therefore treat SAII
   values of 1 the same as it treats SAII values of null.)

3.5.4  Splicing and the Data Plane

   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



Rosen, et al.           Expires January 19, 2006               [Page 23]

Internet-Draft               L2VPN Signaling                   July 2005


   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 [PW-SWITCH].













































Rosen, et al.           Expires January 19, 2006               [Page 24]

Internet-Draft               L2VPN Signaling                   July 2005


4.  Inter-AS Operation

   The provisioning, autodiscovery and signaling mechanisms described
   above can all be applied in an inter-AS environment.  As in [2547bis]
   there are a number of options for inter-AS operation.

4.1  Multihop EBGP redistribution of L2VPN NLRIs

   This option is most like option (c) in [2547bis].  That is, we use
   multihop EBGP redistribution of L2VPN NLRIs between source and
   destination ASes, with EBGP redistribution of labeled IPv4 routes
   from AS to neighboring AS.

   An ASBR must maintain labeled IPv4 /32 routes to the PE routers
   within its AS.  It uses EBGP to distribute these routes to other
   ASes.  ASBRs in any transit ASes will also have to use EBGP to pass
   along the labeled /32 routes.  This results in the creation of a
   label switched path from the ingress PE router to the egress PE
   router.  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 Section 3.2.  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 Section
   3.2.3.

   For VPWS, the BGP advertisement and PW signaling are exactly as
   described in Section 3.3.  As a result of the multihop EBGP session
   that exists between source and destination AS, the PEs in one AS that
   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 Section 3.2.3.  A
   partial mesh can similarly be established using the procedures of
   Section 3.4.

4.2  EBGP redistribution of L2VPN NLRIs with  Pseudowire Switching

   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



Rosen, et al.           Expires January 19, 2006               [Page 25]

Internet-Draft               L2VPN Signaling                   July 2005


   L2TPv3 sessions will cross the AS boundary and that these session
   connect to many devices within an AS.  In the case were 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.  These concerns motivate the approach
   described here.

   [PW-SWITCH] describes an approach to "switching" packets from one
   pseudowire to another at a particular node.  This approach allows an
   end-to-end 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 [2547bis].

   In this model, we use EBGP redistribution of L2VPN NLRI from AS to
   neighboring AS.  First, the PE routers use IBGP to redistribute L2VPN
   NLRI either to an Autonomous System Border Router (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
   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 use "PW switching" to splice that PW to the PW from the PE.
   Repeating the process at each ASBR leads to a sequence of PW segments
   that, when spliced together, connect the two PEs.

   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 produce 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 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



Rosen, et al.           Expires January 19, 2006               [Page 26]

Internet-Draft               L2VPN Signaling                   July 2005


   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.

   We note that, in order for this approach to work correctly, the two
   ASes must use RTs and RDs consistently, just as in layer 3 VPNs
   [RFC2547bis].  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 providers is essential.

4.3  Inter-Provider Application of Dist. VPLS Signaling

   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


   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



Rosen, et al.           Expires January 19, 2006               [Page 27]

Internet-Draft               L2VPN Signaling                   July 2005


   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 section 3.5, 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 which is locally attached to
   BR12; PEs B and C would be have like U-PEs which 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.



































Rosen, et al.           Expires January 19, 2006               [Page 28]

Internet-Draft               L2VPN Signaling                   July 2005


5.  Security Considerations

   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 and auto-
   discovery protocols are discussed in the relevant protocol
   specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], [PWE3-
   CONTROL]).

   The security considerations related to the particular kind of L2VPN
   service being supported are discussed in [L2VPN-REQS], [L2VPN-FW],
   and [VPLS].

   The security consideration of inter-AS operation are similar to those
   for inter-AS L3VPNs [2547bis].

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





























Rosen, et al.           Expires January 19, 2006               [Page 29]

Internet-Draft               L2VPN Signaling                   July 2005


6.  IANA Considerations

   This document requires IANA to assign an AFI and a SAFI.  The AFI
   could be the same as that assigned for [BGP-VPLS].  The SAFI should
   be assigned specifically for this draft.














































Rosen, et al.           Expires January 19, 2006               [Page 30]

Internet-Draft               L2VPN Signaling                   July 2005


7.  Acknowledgments

   Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini
   and Francois LeFaucheur 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.








































Rosen, et al.           Expires January 19, 2006               [Page 31]

Internet-Draft               L2VPN Signaling                   July 2005


8.  Normative References

   [BRADNER]  Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MP-BGP]  Bates, T., Rekhter, Y., Chandra, R. and D. Katz,
   "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

   [EXT-COMM]  Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended
   Communities Attribute", Internet-Draft
   draft-ietf-idr-bgp-ext-communities-09, July 2005.

   [L2TP-BASE] Lau et. al., "Layer Two Tunneling Protocol (Version 3)",
   RFC 3931, March 2005.

   [LDP] Anderson et al., "LDP Specification",  RFC 3036, Jan 2001.

   [PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini,
   et. al., draft-ietf-pwe3-control-protocol-17.txt, June 2005.
































Rosen, et al.           Expires January 19, 2006               [Page 32]

Internet-Draft               L2VPN Signaling                   July 2005


9.  Informative References

   [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-
   based VPNs", Ould-Brahim et. al.,
   draft-ietf-l3vpn-bgpvpn-auto-05.txt, February 2005

   [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo,
   draft-ietf-l2tpext-l2vpn-05.txt, June 2005

   [L2VPN-FW] "L2VPN Framework", Andersson et. al.,
   draft-ietf-l2vpn-l2-framework-05.txt, June 2004

   [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned
   Virtual Private Network Services", Augustyn, Serbest, et. al.,
   draft-ietf-l2vpn-requirements-04.txt, February 2005

   [L2VPN-TERM] Andersson, Madsen, "PPVPN Terminology", RFC 4026, March
   2005.

   [PWE3-ARCH] Bryant, Pate, et. al., "PWE3 Architecture", RFC 3985,
   March 2005.

   [PW-SWITCH] "Pseudo Wire Switching", Martini, et. al.,
   draft-martini-pwe3-pw-switching-03.txt, April 2005

   [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al.,
   draft-ietf-l3vpn-rfc2547bis-03.txt,  October 2004

   [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson,
   September 1999

   [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al.,
   draft-ietf-l2vpn-vpls-ldp-06.txt, February 2005


Authors' Addresses

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

   Email: erosen@cisco.com







Rosen, et al.           Expires January 19, 2006               [Page 33]

Internet-Draft               L2VPN Signaling                   July 2005


   Wei Luo
   Cisco Systems, Inc.
   170 W Tasman Dr.
   San Jose, CA  95134
   USA

   Email: luo@cisco.com


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

   Email: bsd@cisco.com


   Vasile Radoaca
   Nortel Networks
   600 Technology Park
   Billerica, MA  01821
   USA

   Phone: +1 978 288 6097
   Email: vasile@nortelnetworks.com

























Rosen, et al.           Expires January 19, 2006               [Page 34]

Internet-Draft               L2VPN Signaling                   July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosen, et al.           Expires January 19, 2006               [Page 35]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/