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

Versions: 00 01 02 03

Network Working Group                                      Eric C. Rosen
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: August 2002

                                                           February 2002


                   Single-Sided Signaling for L2VPNs


                 draft-rosen-ppvpn-l2-signaling-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Abstract

   [MARTINISIG] contains a proposal for using LDP [RFC 3036] to signal
   point-to-point VCs (sometimes also known as "pseudowires") across an
   MPLS network.  However, that draft requires that each endpoint have
   apriori knowledge of the IP address other endpoint, and that both
   endpoints have apriori knowledge of a common VC identifier. As a
   consequence, each VC needs to be provisioned at both endpoints.  In
   this draft, we extend the [MARTINISIG] signaling technique so as to
   eliminate the requirement for apriori knowledge of a common VC
   identifier, and to eliminate the requirement that each endpoint be
   known to the other.  We then show the signaling can then be used for
   setting up a Virtual Private LAN Service [VPLS1, VPLS2] or a full-
   mesh of point-to-point VCs.





Rosen                                                           [Page 1]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002




Table of Contents

    1      Specification of Requirements  ..........................   2
    2      Introduction  ...........................................   3
    3      Attachment Identifiers  .................................   5
    4      Signaling  ..............................................   6
    4.1    Procedures  .............................................   6
    4.2    FEC  Element  ...........................................   8
    5      Individual Point-to-Point VCs  ..........................   9
    6      Virtual Private LAN Service  ............................   9
    6.1    Provisioning  ...........................................   9
    6.2    Auto-Discovery  .........................................  10
    6.2.1  BGP-based auto-discovery  ...............................  10
    6.2.2  DNS-based auto-discovery  ...............................  11
    6.3    Signaling  ..............................................  11
    7      Colored Pools: Mesh of Point-to-Point VCs  ..............  11
    7.1    Provisioning  ...........................................  12
    7.2    Auto-Discovery  .........................................  12
    7.2.1  BGP-based auto-discovery  ...............................  12
    7.2.2  DNS-based Auto-Discovery  ...............................  13
    7.3    Signaling  ..............................................  13
    8      IETF Sub-IP Area Positioning  ...........................  13
    9      Security Considerations  ................................  14
   10      Acknowledgments  ........................................  14
   11      References  .............................................  14
   12      Author's Information  ...................................  15





1. Specification of Requirements

   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                                                           [Page 2]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


2. Introduction

   In this paper we will use some terminology drawn from [L2VPN].

     - Attachment VC: A VC (virtual circuit)  connecting a CE (customer
       edge) device  to a PE (provider edge) device.

     - Pseudowire: a VC connecting two attachment VCs (previously called
       "emulated VC"; the term has been changed for alignment with the
       work in the PWE3 WG).

   In [MARTINISIG], a pseudowire consists of two LSPs (Label Switched
   Paths), one in each direction.  Each endpoint initiates the setup of
   the LSP that carries packets in the "incoming" direction.  (Note that
   the pseudowire itself is bidirectional.)

   In order for the signaling to proceed, each endpoint has apriori
   knowledge of (a) the address of the other endpoint, and (b) a VCid.
   On a given pseudowire, the same VCid must be used for both LSPs.

   In this context, "apriori knowledge" simply means information that
   must be known prior to the initiation of signaling.

   Each  LSP is  uniquely  identified by  the  triple <transmitter,
   responder, vcid>.  (The  VCid must  be unique in  the context  of a
   single  LDP session between PE1 and PE2.)  A pseudowire is a pair of
   LSPs:

           <PE1, PE2, VCid_x, VC_type_y>, <PE2, PE1, VCid_x, VC_type_y>

   Each endpoint must also have apriori knowledge, for each pseudowire,
   of the local Attachment VC to which that pseudowire is to be bound.

   Unfortunately, this requires that PE1 and PE2 be explicitly
   provisioned with the elements of these tuples; there does not seem to
   be any way to provide an auto-discovery mechanism which eliminates
   the need to provision the VCid at both endpoints, or which eliminates
   the need for each endpoint to have apriori knowledge of the other's
   IP address.  Essentially this means that each pseudowire must be
   individually provisioned  both of its endpoint PEs.

   The purpose of this paper is to extend the signaling of [MARTINISIG]
   so that the need for this provisioning is eliminated.  In particular,
   we would like to be able to set up a pseudowire while requiring that
   only ONE endpoint need have apriori knowledge of the IP address of
   the other.  (Note that if one endpoint has no apriori knowledge of
   the other, it CANNOT have apriori knowledge of a VCid that the other
   will use for a particular pseudowire; if one doesn't know the other



Rosen                                                           [Page 3]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


   endpoint, one cannot be sure that the VCid is unique in the context
   of an LDP session to that endpoint.)  There may be some identifier of
   which both endpoints need to have apriori knowledge (e.g., a VPN-id,
   or a VLAN identifier), but this will not be the identifier of any
   individual VC.

   The procedures described herein, together with an auto-discovery
   procedure, will enable signaling to proceed without requiring either
   endpoint to be provisioned even with the address of the other
   endpoint, as the latter may be provided through the auto-discovery
   procedure.

   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.

   (Note that although the need to provision each individual pseudowire
   VC at both endpoints is eliminated, it may still be necessary to
   provision the Attachment VCs.  If, e.g,. the Attachment VCs pass
   through a switched network, elimination of the provisioning step for
   them is impossible.)

   We will still require that each endpoint have apriori knowledge, for
   each of its Attachment VCs, that that circuit is to be bound to a
   pseudowire, but we will not require that there be apriori knowledge
   of which pseudowire is bound to which Attachment VC.

   In [MARTINISIG], the VCid is used for two purposes:

     - to indicate that a given pseudowire is bound to a given
       Attachment VC (i.e., the Attachment VC is configured with the
       VCid and remote PE address);

     - to indicate in LDP signaling that a given LSP in one direction is
       part of the same VC as a given LSP in the other direction.

   So it is necessary to have another means of achieving these
   functions.

   Note that although this draft is entitled "Single-sided signaling",
   that is really something of a misnomer, as both endpoints do
   participate in the signaling .  A more accurate title would be
   "Signaling Based on the Existence of Apriori Knowledge at only One
   Endpoint".







Rosen                                                           [Page 4]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


3. Attachment Identifiers

   We propose to extend [MARTINISIG] by adding a new FEC type
   (provisionally type 129, subject to assignment by IANA) which,
   instead of specifying a VCid, may the specify following
   identification fields:

     - Target Attachment Identifier (TAI);

     - Source Attachment Identifier (SAI);

     - Attachment Group Identifier (AGI).

   Each Attachment VC  will be configured with an  Attachment Identifier
   and/or with an Attachment Group Identifier.

   An  Attachment Identifier  is unique  in  the context  of a  single
   PE,  but different PEs may use different AIs for different things.

   An Attachment Identifier may be used, at a given PE, to identify:

     - A single Attachment VC, e.g., corresponding to an ATM VPI/VCI.
       This is how it would be used when setting up individual point-
       to-point VCs, as is done in [MARTINISIG].

     - A pool of Attachment VCs, e.g., corresponding to a set of
       Attachment VCs which connect the PE to a particular CE.  This is
       how it would be used when one wants to have a VC going from CE1
       (at PE1) to CE2 (at PE2), but one doesn't care which CE1-PE1
       connection gets bound to which CE2-PE2 connection.

     - A virtual Attachment VC, e.g., corresponding to an ethernet
       switching function for a particular VLAN.  This is how it would
       be used when providing a transparent LAN service, in which a set
       of Virtual Switches for a particular VLAN have to be meshed via
       point-to-point VCs.

   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  VCs (or pools thereof) which are allowed to be connected.

   The intention is that an LSP will now be identified by:

           <PE1, AI1, PE2, AI2>,

   the LSP in the opposite direction will be identified by:

           <PE2, AI2, PE1, AI1>,



Rosen                                                           [Page 5]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


   and an pseudowire is a pair of such LSPs.

   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 VCs  (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 VCs (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.)

   The  intention  is  that the  PE  which  receives  a Label  Mapping
   Message containing  a TAI  will be  able to  map  that TAI  uniquely
   to  one of  its Attachment  VCs (or  pools).   The  way in  which  a
   PE  maps  a  TAI to  an Attachment  VC (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".

   When  an Attachment  VC or  pool is  provisioned, it  is configured
   with an Attachment Identifier, or an Attachment Group Identifier, or
   both.


4. Signaling

4.1. Procedures

   In order for  PE1 to begin signaling  PE2, PE1 must know the  address
   of the remote PE2, and a TAI.  While  this information may be
   configured at PE1, it is  expected that  it would  be learned
   dynamically via  some autodiscovery procedure.  To PE1, the auto-
   discovery process is a function which maps from an AGI to a set of
   <PE, AI> pairs.

   To begin the signaling procedure, a PE (PE1) that has knowledge of
   the other endpoint (PE2) initiates the setup of the LSP in the
   incoming (PE2-->PE1) direction by sending a Label Mapping message
   containing the new FEC type.  The FEC type includes the following:

     - SAI

     - AGI, if one has been configured.







Rosen                                                           [Page 6]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


     - TAI (SAI at the remote PE).

   What happens when PE2 receives such a Label Mapping message?

   First, PE2 interprets the TAI.  Exactly how PE2 does this mapping is
   a local matter.   The TAI might,  e.g., be  a string  which
   identifies  a particular Attachment VC, such  as "ATM3VPI4VCI5", or
   it might, e.g.,  be a string such as "Fred" which is associated  by
   configuration with a particular Attachment VC, or it might be a VPN-
   id of some sort, depending on the application.

   If  PE2 cannot  map the  TAI to  anything, then  PE2 sends  a  Label
   Release message to PE1, with a Status Code meaning "invalid TAI", and
   the processing of the Mapping message is complete.

   If the TAI maps  to an Attachment VC (or pool) which  is NOT
   configured with the same AGI that is specified in the Label Mapping
   message, a corresponding Label Release message, with a Status Code
   meaning "no AGI in common" is sent to PE1, and the processing of the
   Mapping message is complete.

   The AGI  of an Attachment VC (or  pool) and the Label  Mapping
   Message's AGI are considered to be the same if and only if:

     - The  Attachment VC or pool is  configured with an AGI,  and that
       same AGI occurs in the message, and

     - The Attachment VC or pool is not configured with an AGI, no AGI
       occurs in the message.

   If the TAI maps to a single Attachment VC, and that Attachment VC 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 VC bound to different PE", and the processing of
   the Mapping message is complete.

   If the TAI maps to a single Attachment VC, and that Attachment VC 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 SAI field of the Mapping message, then PE2
   sends a Label Release message to PE1, with a Status Code meaning
   "Attachment VC bound to different remote Attachment VC", and the
   processing of the Mapping message is complete.

   If the TAI maps to a pool of Attachment VCs, and there is already an
   pseudowire connecting an Attachment VC in that pool to an Attachment
   VC at PE1, and the AI at PE1 of that pseudowire is the same as the



Rosen                                                           [Page 7]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


   SAI of the Label Mapping message, then PE2 sends a Label Release
   message to PE1, with a Status Code meaning "Attachment VC bound to
   different remote Attachment VC", and the processing of the Mapping
   message is complete.

   If PE2 is still processing the Label Mapping message at this point,
   then it accepts the label (provided of course that there are no
   "standard" LDP errors).  Then it has to make sure that an LSP is set
   up in the opposite (PE1-->PE2) direction.  If it has already signaled
   for an LSP in that direction, nothing more need be done.  Otherwise,
   it must initiate such signaling by sending a Label Mapping message to
   PE1.  This is very similar to the Label Mapping message PE2 received,
   but with the SAI and TAI reversed.


4.2. FEC  Element

   FEC element type 129 is used.   The FEC element is encoded as
   follows:



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     129       |C|         VC Type             |VC info Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Parameters                           |
      |                              "                                |
      |                              "                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   VC Type is as defined in [MARTINISIG], and as extended in [VPLS2] and
   [shah].

   C and VC info length are as defined in [MARTINISIG].

   Parameters are:

     - SAI, encoded as a one byte length field followed by the SAI.

     - TAI, encoded as a one byte length field followed by the TAI.







Rosen                                                           [Page 8]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


     - AGI, encoded as a one byte length field followed by the AGI.

     - Interface parameters, as defined in [MARTINISIG].



5. Individual Point-to-Point VCs

   One model of operation which the above procedures can support is the
   following.  Each PE is configured with the necessary set of
   Attachment VCs, and each Attachment VC is configured with a VPN-id, a
   local name (which is unique relative to the VPN-id), and a remote
   name. The intent is that the local Attachment VC is supposed to be
   connected to the remote Attachment VC with the specified remote name.
   As part of an auto-discovery procedure, each PE advertises its <VPN-
   id, local name> pairs.  Each PE compares its local <VPN-id, remote
   name> pairs with the <VPN-id, local name> pairs advertised by the
   other PEs.  If PE1 has a local <VPN-id, remote name> pair with value
   <V, fred>, and PE2 has a local <VPN-id, local name> pair with value
   <V, fred>, PE1 will thus be able to discover that it needs to connect
   to PE2, and will use "fred" as the TAI.  The SAI is not used.

   In this model of operation, the Attachment VCs and the pseudowires
   are point-to-point.  The primary benefit of this model of operation
   is that it enables you to move an Attachment VC from one PE to
   another without having to reconfigure the remote endpoint.


6. Virtual Private LAN Service

   In the VPLS model of operation, the Attachment VCs can be though of
   as LAN interfaces which attach to "virtual LAN switches".  The VPLS
   service [VPLS1, VPLS2] requires that a pseudowire be created between
   each pair of virtual LAN switches that are in a common VPLS.  Each PE
   device may have a number of virtual LAN switches, where each of those
   virtual LAN switches belongs to a different VPLS.


6.1. Provisioning

   Each VPLS must have a globally unique identifier.  Every virtual LAN
   switch must be configured with the identifier of the VPLS to which it
   belongs.

   Each virtual LAN switch must also have a unique identifier, but this
   can be formed automatically by concatenating its VPLS identifier with
   the IP address of the PE router in which that virtual LAN switch
   exists.



Rosen                                                           [Page 9]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


6.2. Auto-Discovery

6.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:

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

     - An SAFI specified by IANA specifically for a VPLS 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 virtual LAN switch 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 it is not strictly necessary for all the virtual LAN
   switches 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 virtual LAN switch 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 virtual LAN switches, 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 virtual LAN switch with a particular RT, it can then
   receive all the NLRI  which have that same RT, and from the BGP next
   hop attribute of these NLRI will learn the IP addresses of the other



Rosen                                                          [Page 10]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


   PE routers which have virtual LAN switches 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 virtual LAN switches 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 virtual LAN switch 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.


6.2.2. DNS-based auto-discovery

   [DNS-LDP-VPLS] includes a proposal for using DNS-based auto-
   discovery.


6.3. Signaling

   The AI of a particular virtual LAN interface is identical to the RT
   described above in section 6.2.1.  (If DNS-based auto-discovery is
   being used, this would likely be just an RFC2685 VPN-id encoded as an
   RT.)

   As the AI is the same at both ends of the pseudowire, only the TAI
   field need be provided; the SAI field can be omitted.  The AGI field
   is omitted as well.

   This means that the TAI field of the FEC element will consist of a
   length byte whose value is 8, followed by the 8-byte RT.  The SAI and
   AGI fields will consist solely of a length byte whose value is 0.


7. Colored Pools: Mesh of Point-to-Point VCs

   In the "Colored Pools" model of operation, each PE may contain
   several pools of Attachment VCs, 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.



Rosen                                                          [Page 11]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


   This model of operation can be used to provide the same service as in
   [BGP-SIGNALING].  However, the pseudowire setup is done with LDP
   rather than BGP, and there is reduced provisioning, as the
   configuration of CE-ids and label ranges is not required.


7.1. Provisioning

   Each pool is configured, and associated with:

     - a set of Attachment VCs;  whether these Attachment VCs must
       themselves be provisioned, or whether they can be auto-allocated
       as needed, is independent of and orthogonal to the procedures
       described in this document;

     - a "color", which in the simplest case is simply a VPN-id of some
       sort;

     - a globally unique identifier.

   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 VC from each of the two pools.  If
   each pool is a set of Attachment VCs 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 make use of the auto-
   discovery scheme of [BGP-AUTO], the colors must be encodable as RTs,
   and the unique pool identifiers must be encodable as RDs.


7.2. Auto-Discovery

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

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

     - An SAFI specified by IANA specifically for a Colored Pool L2VPN
       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 an RT (Route Target) and the unique



Rosen                                                          [Page 12]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


   identifier of a pool must be encodable as an RD (Route
   Distinguisher), as discussed in [BGP-AUTO].  If a full-mesh
   configuration is desired, the RT can be, though it need not be, the
   encoding of an RFC 2685 VPN-id.

   The NLRI for a given pool would consist of its RD prepended to a
   loopback address of the PE router in which it exists.

   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
   encoded in the RD.


7.2.2. DNS-based Auto-Discovery

   The use of DNS-based auto-discovery for the colored pool model of
   operation is for further study.


7.3. Signaling

   When a PE sends a Label Mapping message to set up a VC between two
   pools, the local pool's unique identifier is encoded as the SAI and
   the remote pool's unique identifier is encoded as the TAI.


8. IETF Sub-IP Area Positioning

   This draft is targeted at both the PPVPN WG and the MPLS WG. It
   appears to be in the province of the PPVPN WG to consider the
   requirements of signaling to support layer 2 VPNs.  Specification in
   detail of the actual extensions to LDP would appear to be the
   province of the MPLS WG.







Rosen                                                          [Page 13]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


9. Security Considerations

   The signaling procedures specified herein require that a node
   initiate and/or accept LDP sessions with entities that are not
   necessarily directly connected to that node.  It would be advisable
   for a given node to use access control to restrict the set of nodes
   that can set up LDP sessions with it, and it would be advisable to
   use some form of authentication to guarantee that the remote endpoint
   of an LDP session is the entity that it claims to be.  Using the TCP
   MD5 option may be adequate, or alternatively IPsec can be used.


10. Acknowledgments

   Thanks to Dan Tappan and Ted Qian for their comments.  Thanks to
   Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for
   discussing the auto-discovery issues.


11. References

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

   [BGP-SIGNALING] "Layer 2 VPNs over Tunnels", Kompella et. al.,
   draft-kompella-ppvpn-l2vpn-01.txt, November 2001

   [DNS-LDP-VPLS] "DNS/LDP Based VPLS", Heinanen, draft-heinanen-dns-
   ldp-vpls-00.txt, January 2002

   [L2VPN] "An Architecture for L2VPNs", Rosen et. al., draft-ietf-
   ppvpn-l2vpn-00.txt, July 2001.

   [MARTINISIG] "Transport of Layer 2 Frames Over MPLS", Martini et.
   al., draft-martini-l2circuit-trans-mpls-08.txt, November 2001.

   [RFC2547bis], "BGP/MPLS VPNs", Rosen, Rekhter, et. al., draft-ietf-
   ppvpn-rfc2547bis-01.txt, January 2002

   [RFC3036] "LDP Specification", January 2001.

   [VPLS1] "Requirements for Virtual Private LAN Services (VPLS)",
   Augustyn et. al., draft-augustyn-vpls-requirements-00.txt, October
   2001.

   [VPLS2] "Transparent VLAN Services over MPLS", Laserre, et. al.,
   draft-lasserre-vkompella-ppvpn-vpls-00.txt, November 2001.



Rosen                                                          [Page 14]


Internet Draft   draft-rosen-ppvpn-l2-signaling-01.txt     February 2002


12. Author's Information


   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: erosen@cisco.com










































Rosen                                                          [Page 15]


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