Subject: [L2tpext] draft-luo-l2tpext-l2vpn-signaling-01.txt

From: Wei Luo <[email-masked]>
Date: Mon, 03 Mar 2003 14:32:47 -0800

FYI, enclosed is the latest draft-luo-l2tpext-l2vpn-signaling-01.txt.  It should
be available from IETF website as well.  Your comments are appreciated.

---Wei

Network Working Group                                            Wei Luo
Internet Draft                                       Cisco Systems, Inc.
February 2003

                      L2VPN Signaling Using L2TPv3

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

   The Layer 2 Tunneling Protocol (L2TPv3) provides a standard method
   for setting up and managing L2TP sessions to tunnel a variety of L2
   protocols.  One of the reference models supported by L2TPv3 describes
   the use of an L2TP session to cross-connect two Layer 2 circuits
   attached to a pair of peering LACs.  A cross-connect is a basic form
   of Layer 2 Virtual Private Networks (L2VPNs).  This document
   describes mechanisms which utilize the building blocks that L2TP
   provides to construct different types of L2VPNs.

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

Luo                                                    	[Page 1]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

   Table of Contents

   Status of this Memo..........................................    1

   1. Introduction..............................................    3

   2. Network Reference Model and L2VPN Applications............    3

   3. Forwarders and End Identifiers............................    4

   4. L2TP Control Messages.....................................    5

   5. Existing AVPs for L2VPNs..................................    5
      5.1 Router ID.............................................    5
      5.2 Pseudowire Capabilities List..........................    5
      5.3 Pseudowire Type.......................................    5
      5.4 Pseudowire Control Encapsulation......................    6
      5.5 Circuit Status........................................    6
      5.6 Remote End ID.........................................    6

   6. New AVPs for L2VPN........................................    6
      6.1 Local End ID..........................................    6

   7. Pseudowire Tie Detection..................................    7

   8. L2VPN Signaling Procedures................................    8
      8.1 Overview..............................................    8
      8.2 Generic Algorithm.....................................    8
      8.3 Application-specified Processing......................   12
         8.3.1 Cross-connect....................................   12
         8.3.2 Virtual Private LAN Service......................   12
         8.3.3 Colored Pools....................................   13

   9. BGP-based Auto-discovery..................................   13
      9.1 Common L2VPN Addressing and NLRI Encoding.............   13
      9.2 AFI/SAFI and BGP Capabilities.........................   14
      9.3 Route Targets.........................................   14

   10. Heterogeneous L2VPN Deployment...........................   15

   11. Intellectual Property Notice.............................   16

   12. IANA Considerations......................................   16

   13. Security Considerations..................................   16

   14. Acknowledgement..........................................   16

Luo                                                    	[Page 2]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

   15. References...............................................   16

   16. Authors' Address.........................................   17

1. Introduction

   [L2TPv3] defines a dynamic tunneling mechanism to carry multiple L2
   protocols besides PPP (as originally defined in [RFC 2661]), over a
   packet-based network.  The baseline protocol supports various types
   of applications, which has been hightlighted in the different L2TP
   reference models in [L2TPv3].  L2VPN applications are typically in
   the scope of the LAC-LAC reference model.

   This document discusses the commonality as well as difference among
   L2VPN applications with respect to utilizing L2TPv3 as the signaling
   protocol.  It also specifies the necessary information required by
   BGP-based auto-discovery for the integration with the L2TPv3-based
   signaling protocol.  Other auto-discovery mechanisms are left for
   future studies.

   The acronym "L2TP" refers to L2TPv3 or L2TP in general in this
   document.

2. Network Reference Model and L2VPN Applications

   In the LAC-LAC reference mode, a LAC serves as a cross-connect
   between attachment circuits and L2TP sessions.  Each L2TP session
   acts as an emulated circuit, also known as pseudowire.

   +-----+  L2  +-----+                      +-----+  L2  +-----+
   |     |------| LAC |...[packet network]...| LAC |------|     |
   +-----+      +-----+                      +-----+      +-----+
   remote                                                 remote
   system                                                 system
                      |<- emulated service ->|
         |<----------------- L2 service ----------------->|

   In a simple cross-connect application, an attachment circuit is
   directly bound to a pseudowire.  It's a one-to-one mapping.  Traffic
   received from the attachment circuit on a local LAC is forwarded to
   the remote LAC through the pseudowire.  When the remote LAC receives
   traffic from the pseudowire, it forwards the traffic to the
   corresponding attachment circuit on its end.  The forwarding decision
   is based on the attachment circuit or pseudowire demultiplexing
   identifier respectively.

Luo                                                    	[Page 3]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

   With Virtual Private LAN Service (VPLS), one or more attachment
   circuits and pseudowires are connected to a Virtual Switching
   Instance (VSI) on a LAC.  A single pseudowire is used to connect a
   pair of VSIs on two peering LACs.  Traffic received from an
   attachment circuit or a pseudowire is first forwarded to the
   corresponding VSI based on the attachment circuit or pseudowire
   demutiplexing identifier.  The VSI performs additional lookup to
   determine where to further forward the traffic.

   [L2 FW] describes an L2VPN application called Colored Pools, which is
   essentially made of a network of point-to-point cross-connect.  The
   data forwarding perspective is identical to the cross-connect
   application, while constructing Colored Pools involves more
   complicated signaling procedures.

3. Forwarders and End Identifiers

   As described in [L2 FW], a pseudowire is bound to a "forwarder",
   which in turn binds to one or more attachment circuits.  For
   different L2VPN applications, different types of forwarders are
   defined.

   An End Identifier is assigned to each forwarder on a given LAC that
   supports L2VPN applications.  It must be unique in the context of the
   LAC.

   In simple cross-connect, each individual attachment circuit is a
   forwarder, and provisioned with an End ID value.  Without any auto-
   discovery, each attachment circuit needs to be manually provisioned
   with the remote Router ID and the End ID of the remote attachment
   circuit.  The End ID value for an attachment circuit may be an
   arbitrary integer or a descriptive string.

   In VPLS, each VSI is a forwarder, and provisioned with an End ID
   value.  Without any auto-discovery, each VSI needs to be manually
   provisioned with its remote LAC addresses and the End IDs of the
   remote VSIs.  The End ID value for a VSI may be the VPN ID of the
   VPLS domain.

   In Colored Pools, each pool is a forwarder, and provisioned with an
   End ID value.  Without any auto-discovery, each pool needs to be
   manually provisioned with its remote LAC addresses and the End IDs of
   the remote pools.  The End ID value for a pool may be an arbitrary
   integer or a descriptive string.

Luo                                                    	[Page 4]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

4. L2TP Control Messages

   L2TP defines two sets of session management procedures: Incoming Call
   and Outgoing Call.  Even though it's entirely possible to use the
   Outgoing Call procedures to signaling L2VPNs, the Incoming Call
   procedures has some advantages in terms of the relevance of semantics
   and being able to offer moderate capability negotiation between two
   LCCEs.  [PWE3L2TP] gives more details on why Incoming Call is more
   appropriate for setting up pseudowires.

   The signaling procedures for L2VPNs described in the following
   sections are all based on the Incoming Call procedures.

5. Existing AVPs for L2VPNs

   Besides the AVPs required to establish and manage control connections
   and sessions, the following AVPs defined in [L2TPv3] are directly
   relevant to L2VPN applications.

5.1 Router ID

   The Router ID sent in SCCRQ and SCCRP during control connection setup
   establishes the unique identity of each LAC.

5.2 Pseudowire Capabilities List

   The Pseudowire Capabilities List sent in SCCRQ and SCCRP indicates
   the pseudowire types supported by the sending LAC.  It merely serves
   as an advertisement to the receiving LAC.  Its content should not
   affect the control connection setup.

   Before a local LAC initiates a session of a particular pseudowire
   type to a remote LAC, it MUST examine whether the remote LAC has
   advertised such a capability in this AVP, and SHOULD NOT attempt to
   initiate the session if the intended pseudowire type is not supported
   by the remote LAC.

5.3 Pseudowire Type

   The Pseudowire Type sent in ICRQ signals the intended pseudowire type
   to the receiving LAC.  The receiving LAC checks it against its local
   pseudowire capability list.  If it finds a match, it responds with an
   ICRP without a Pseudowire Type AVP, which implicitly acknowledges its
   acceptance of the intended pseudowire.  If it does not find a match,

Luo                                                    	[Page 5]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

   it MUST respond with a CDN with an "unsupported pseudowire type"
   result code.

5.4 Pseudowire Control Encapsulation

   The Pseudowire Control Encapsulation can be sent in ICRQ, ICRP, and
   ICCN.  If the receiving LAC supports the specified control
   encapsulation, it MUST include it in its data packets sent to the
   sending LAC.  Otherwise, it MUST reject the connection by sending a
   CDN to the sending LAC.

5.5 Circuit Status

   The Circuit Status is sent in both ICRQ and ICRP to inform the
   receiving LAC about the circuit status on the sending LAC.  It can
   also be sent in ICCN and SLI to update the status.

5.6 Remote End ID

   The Remote End ID sent in ICRQ instructs the receiving LAC to bind
   the proposed pseudowire to the forwarder that has been assigned with
   the encoded End Identifier value.

6. New AVPs for L2VPN

6.1 Local End ID

   The Local End ID AVP, Attribute Type TBA, encodes the End Identifier
   value of the forwarder to be bound to the proposed pseudowire on the
   sending LAC.  The Local End ID AVP may also be used in conjunction
   with the Remote End ID AVP to detect session-level ties.  When it's
   omitted in the control messages, it's assumed that it has the same
   value as the Remote End ID.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              TBA              |  End ID ... (variable length) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Luo                                                    	[Page 6]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

   The End Identifier field is a variable-length field whose value is
   unique for a given LCCE.  This AVP MAY be present in ICRQ.

   This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for this
   AVP SHOULD be set to 0.  The Length (before hiding) of this AVP is 6
   plus the length of the End Identifier value.

7. Pseudowire Tie Detection

   Conceivably in the LAC-LAC network reference model, as either LAC may
   initiate a session to another LAC at any time, they could end up
   initiating a session to each other simultaneously.

   In order to avoid setting up duplicated pseudowires between two
   forwarders, each LAC must be able to independently detect such a
   pseudowire tie.  The following procedures need to be followed to
   detect a tie:

   If both Remote End ID and Local End ID are present in ICRQ, the
   receiving LAC compares them with the Remote End ID and Local End ID,
   in reverse order, encoded in the ICRQ it has already sent to the
   sending LAC.  If the received Remote End ID matches the sent Local
   End ID and the received Local End ID matches the sent Remote End ID,
   a tie is detected.

   If only Remote End ID is present in ICRQ, the Local End ID is assumed
   to have the same value as the Remote End ID.  The receiving LAC
   compares the received Remote End ID with the Local End ID, encoded in
   the ICRQ it has already sent to the sending LAC.  If the Local End ID
   in this ICRQ is also omitted, then the Remote End ID is compared.  If
   they match, a tie is detected.

   Once a tie has been discovered, the standard L2TP tie breaking
   procedure is employed to disconnect the duplicated pseudowire.

Luo                                                    	[Page 7]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

8. L2VPN Signaling Procedures

8.1 Overview

   Assume a LAC assigns an End ID to one of its local forwarders, and
   knows it needs to set up a pseudowire to a remote forwarder on a
   remote LAC that has a certain End ID.  This knowledge can be obtained
   either through manual configuration or some auto-discovery procedure.

   Before establishing the intended pseudowire, each pair of peering
   LACs exchanges control connection messages to establish a control
   connection.  Each advertises its supported pseudowire types in the
   Pseudowire Capabilities List AVP.

   After the control connection is established, the local LAC examines
   whether the remote LAC supports the pseudowire type it intends to set
   up.  Only if the remote LAC supports the intended pseudowire type, it
   should initiate a pseudowire connection request.

   When the local LAC receives an ICRQ for a pseudowire connection, it
   examines the Remote End ID encoded in the ICRQ to determine the
   following:

     - whether it has a local forwarder assigned with an End ID value
       specified in the Remote End ID,

     - whether the remote LAC is allowed to connect with this local
       forwarder.

   If both conditions are met, it sends an ICRP to the remote LAC to
   accept the connection request.  If either of the two conditions
   fails, it sends a CDN to the remote LAC to reject the connection
   request.

8.2 Generic Algorithm

   Despite the apparent disparity among different L2VPN applications, a
   common set of signaling procedures can be defined.

   Each LAC first forms a list, SOURCE_FORWARDERS, consisting of all
   local forwarders of a given VPN.  Then it puts all local forwarders
   that need to be interconnected and all remote forwarders of the same
   VPN into another list, TARGET_FORWARDERS.  The formation of the
   network topology depends on the content in the SOURCE_FORWARDERS and
   TARGET_FORWARDERS list.  These two lists can be constructed by manual
   configuration and/or some auto-discovery procedure.

Luo                                                    	[Page 8]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

   The following algorithm is used to set up pseudowires among all the
   forwarders that intend to be interconnected by iterating through each
   source and target forwarder.  An L2VPN is formed upon finishing the
   algorithm in every LAC participating in L2VPN.

          SOURCE_FORWARDERS             TARGET_FORWARDERS
       s1: <Router ID, End ID>        t1: <Router ID, End ID>
       s2: <Router ID, End ID>        t2: <Router ID, End ID>
       s3: <Router ID, End ID>        t3: <Router ID, End ID>
                ...                           ...

     1.  Pick the next forwarder, from SOURCE_FORWARDERS.  If no
         forwarder is available for processing, the processing is
         complete.

     2.  Pick the next forwarder, from TARGET_FORWARDERS.  If no
         forwarder is available for processing, go back to step 1.

     3.  If the two forwarders are associated with different Router IDs,
         a pseudowire must be setup between them.  Proceed to step 6.

     4.  Compare the End ID values of the two forwarders, if they match,
         the source and target forwarders are the same, so no more
         action is necessary.   Go back to step 2.

     5.  As the source and target forwarders both reside on the local
         LAC, no pseudowire is needed.  LAC simply creates a local
         cross-connect between the two forwarders.  Go back to step 2.

     6.  As the source and target forwarders reside on different LACs,
         a pseudowire must be established between them.  LAC first
         examines if the source forwarder has already established a
         pseudowire to the target forwarder.  If so, go back to step 2.

     7.  If no pseudowire is already established between the source and
         target forwarders, the local LAC obtains the address of the
         remote LAC, and establishes a control connection to the remote
         LAC if one does not already exist.

     8.  The local LAC sends an ICRQ to the remote LAC.  The End IDs of
         source and target forwarders are encoded as the Local End ID
         and Remote End ID respectively.

     9.  If the local LAC receives a response corresponding to the
         ICRQ it just sent, proceed to step 10.  Otherwise, if the
         local LAC receives an ICRQ from the same remote LAC, proceed
         to step 11.

Luo                                                    	[Page 9]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

     10. The local LAC receives a response from the remote LAC.  If
         it's a CDN, go back to step 2.  If it's an ICRP, the local
         LAC binds the source forwarder to the pseudowire and sends
         an ICCN to the remote LAC, go back to step 2.

     11. If the local LAC receives an ICRQ from the same remote LAC,
         it needs to perform session tie detection, as described in
         Section 7.  If a session tie is detected, it performs tie
         breaking.

     12. If it lost in tie breaking, the local LAC sends a CDN with
         the result code that indicates the disconnection is due to
         losing tie breaker.  Proceed to step 14.

     13. If it won in tie breaking, the local LAC ignores the remote
         LAC's ICRQ (note that the L2TP reliable transport confirms
         receipt of the message with any legitimate control message
         even though it doesn't respond to the ICRQ), and continues
         waiting for the response from the remote LAC.  Go to step 10.

     14. The local LAC determines whether it should accept the
         connection request, as described in the section 8.1.
         If it accepts the ICRQ, it sends an ICRP to the remote LAC.

     15. The local LAC receives a response from the remote LAC.  If
         it's a CDN, go back to step 2.  If it's an ICCN, the local
         LAC binds the source forwarder to the pseudowire, go back
         to step 2.

   The following diagram illustrate the above procedures:

Luo                                                   	[Page 10]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

          --------->     Pick Next
          |           Source Forwarder
          |                 |
          |                 |
          |                 v                  N
          |        Found Source Forwarder? ----------> End
          |                 |
          |              Y  |
          |                 v
          |              Pick Next     <--------------------------------
          |           Target Forwarder                                 |
          |                 |                                          |
          |                 |                                          |
          |  N              v                                          |
          -------- Found Target Forwarder?                             |
                            |                                          |
                         Y  |                                          |
                            v             Y                        Y   |
                      Same Router ID? -----------> Same End ID? -------|
                            |                         |                |
                         N  |                      N  |                |
                            |                         v                |
                            |                      Create Local -------|
                            v                      Cross-connect       |
                    Pseudowire Already    Y                            |
                    Established Between -------------------------------|
                    Source and Target?                                 |
                            |                                          |
                         N  |                                          |
                            v                                          |
                 Local Initiates Pseudowire                            |
               Connection Request to Remote                            |
                            |                                          |
                            |                                          |
                            v                                          |
      ------->    Local Wait for Message                               |
      |           ----- from Remote   --------------                   |
      |           |                                |                   |
      |           |                                |                   |
      |           v                                v                   |
      |   Local Receives Pseudowire      Local Receives Pseudowire     |
      |     Connection Request             Connection Response         |
      |       from Remote                     from Remote              |
      |           |                                |                   |
      |           |                                |                   |
      |           v                                v             N     |
      |   Perform Pseudowire              Connection Accepted? --------|
      |   Tie Detection                            |                   |

Luo                                                   	[Page 11]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

      |           |                             Y  |                   |
      |           |                                v                   |
      |           |                        Local Binds Source ---------|
      |           |                      Forwarder to Pseudowire       |
      |           |                                                    |
      |           v             N                  N                   |
      |       Tie Detected?  -----> Accept Remote ----->  Reject ------|
      |           |             Connection Request?    Remote Request  |
      |        Y  |                        ^   |                       |
      |           v                        |   |   Y                   |
      |   Perform Tie Breaking             |   ------>  Local Binds ----
      |           |                        |         Source Forwarder
      |           |                        |           to Pseudowire
      |           v             N          |
      |   Won Tie Breaking?  ------>   Disconnect
      |           |                  Local Connection
      |        Y  |
      |           v
      ------ Ignore Remote
            Connection Request

8.3 Application-specified Processing

8.3.1 Cross-connect

   When a LAC learns the remote Router ID and remote End ID, it may
   start the signaling right away or wait for the circuit status of the
   local attachment circuit to become active.

   After the pseudowire has been successfully established, a LAC binds
   the attachment circuit to the pseudowire.

8.3.2 Virtual Private LAN Service

   A VSI is a forwarder in VPLS and consists of a number of attachment
   circuits and a number of pseudowires.  A LAC may have multiple VSIs.
   When a LAC learns the remote Router IDs and remote End IDs, it may
   start the signaling right away or wait for the first attachment
   circuit to join the local VSI.

   After the pseudowire has been successfully established, a LAC binds
   the VSI to the pseduowire by making the pseudowire a member link of
   the bridging domain defined by the VSI.

Luo                                                   	[Page 12]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

8.3.3 Colored Pools

   In the LAC-LAC network reference model, a remote system may have
   multiple physical or logical attachment circuits, such as Frame Relay
   DLCIs attached to a LAC, which form a "pool" of attachment circuits.
   Each pool corresponds to a particular remote system, and is
   associated with a particular VPN.  If there are multiple remote
   systems of the same VPN attached to a LAC, the LAC will have multiple
   pools associated with the same VPN.

   Each pool is provisioned with an End ID that differentiates itself
   from other forwarders residing in the same LAC, and a "color", which
   represents a particular VPN.  The format of "color" can be a VPN ID.
   A VPN ID can be an unsigned integer or a structured numeric value.

   If pools with a certain color need to be connected in a full-mesh
   fashion, a pseudowire is created between every pair of pools except
   the pools residing on the same LAC, and the pseudowire is bound to an
   unused attachment circuit from each pool.  For pools on the same LAC,
   a local cross-connect is formed to bind two attachment circuits.

9. BGP-based Auto-discovery

   The BGP-based auto-discovery specified in this document is similar to
   the schemes described in [BGPVPN] and [LDPVPN], but further
   optimized.  Although this mechanism is only discussed in the L2TP
   context, it's conceivably useful for LDP-based L2VPN signaling as
   well.

9.1 Common L2VPN Addressing and NLRI Encoding

   As outlined in Section 3, each forwarder is assigned with an End
   Identifier value.  An End ID is locally significant and unique
   regardless what type of forwarder it's associated with.  A Router ID
   is a 32-bit global unique value.  A Common L2VPN Address is defined
   as the concatenation of Router ID and End ID.

   The Network Layer Reachability Information (NLRI) for BGP
   Multiprotocol Extension [RFC 2858] is encoded as one or more tuples
   of the form <length, prefix>:

     - Length: 1 octet
       The Length field indicates the length in bits of the common
       L2VPN address.

     - Prefix: variable-length

Luo                                                   	[Page 13]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

       The Prefix fields carry the Common L2VPN Address.  As the
       Router ID is 32 bits in length, the maximum length of the
       End ID is 223 bits, which is rounded to 27 whole octets.

   When using BGP-based auto-discovery, care needs to be taken to ensure
   the End ID values assigned to the local forwarders do not exceed the
   maximum length allowed.

   Unlike the NLRI encoding described in [BGPVPN] and [LDPVPN], the
   Common L2VPN Addressing scheme uses a single format for all L2VPN
   applications, and no Route Distinguisher is needed to guarantee the
   uniqueness of the prefix, as a Common L2VPN Address is globally
   unique by definition.

9.2 AFI/SAFI and BGP Capabilities

   An AFI, to be assigned by IANA, is used for all L2VPN applications.
   When L2VPN applications choose to use the Common L2VPN Addressing
   scheme, an SAFI, to be assigned by IANA, is used to identify that the
   NLRI carried in BGP has such an address format.

   In order for two BGP speakers to exchange Common L2VPN NLRI, they
   MUST use the negotiation scheme defined in [RFC 2842] to ensure that
   both of them are capable of processing such NLRI correctly.  This is
   done by using the Capability Code 1 for Multiprotocol Extensions, and
   the Capability Value containing the AFI and SAFI specified in this
   document.  The format of the Capabilities parameter is defined in
   [RFC 2858].

9.3 Route Targets

   If a forwarder wishes to be discovered via BGP, it needs to create a
   Common L2VPN Address, and associate the address with one or more
   Route Target (RT) Extended Community attributes [BGPEXT].  These
   attributes are carried in BGP as part of the Path Attributes, along
   with the LAC itself as the BGP next hop.

   RTs are used in BGP to control the NLRI distribution.  Each BGP
   speaker can define a set of distribution policies using RTs to
   control how addresses are advertised and learnt, thereby governing
   the formation of the L2VPN network topology.

   To form a full mesh among the forwarders that belong to the same VPN,
   each forwarder is configured with the same RT value as both the
   "export RT" and "import RT".  This distribution policy will allow
   these forwarders to be visible to all BGP speakers having this

Luo                                                   	[Page 14]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

   policy.  Therefore, the L2VPN signaling will set up a full mesh of
   pseudowires among these forwarders using the algorithm described the
   previous section.

   Sometimes, a hub-and-spoke L2VPN network is desired.  This can be
   achieved by using two different RTs for distribution processing,
   where one stands for "hub" and the other stands for "spoke".  On the
   hub LAC, the "hub" RT is assigned to local forwarders as the "export
   RT", and the hub LAC is configured to "import" only the Common L2VPN
   addresses that have the "spoke" RT.  On the spoke LAC, the "spoke" RT
   is assigned to local forwarders as the "export RT", and the spoke LAC
   is configured to "import" only the Common L2VPN addresses that have
   the "hub" RT.  This distribution policy will result in (1) spoke LACs
   only seeing the forwarders configured on the hub LAC, and (2) a hub
   LAC seeing all forwarders configured on every spoke LAC.  The L2VPN
   signaling then sets up pseudowires that form the hub-and-spoke
   topology.

   A more complex topology is partial mesh.  It can be done by using a
   set of "import RTs" and "export RTs" for distribution processing.

10. Heterogeneous L2VPN Deployment

   Often there is more than one form of L2VPN application required in a
   network.  For example, an individual attachment circuit on one LAC
   needs to be connected to a VSI or Colored Pool on another LAC by a
   pseudowire.  In such a case, different L2VPN applications are
   deployed concurrently and different types of forwarders are inter-
   connected by pseudowires.

   The use of Common L2VPN Addressing makes this mix-and-match L2VPN
   deployment scenario feasible and easy to manage.  As forwarders are
   addressed in the same fashion despite different forwarding behaviors
   that each may have, a common set of signaling and auto-discovery
   procedures can be implemented for a heterogeneous L2VPN deployment.

   In addition, the forwarding behavior of each forwarder is determined
   by its local characteristics, not those of its peer forwarder.  This
   gives great flexibility to deploy a heterogeneous L2VPN.

Luo                                                   	[Page 15]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

11. Intellectual Property Notice

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

12. IANA Considerations

   This document defines a new L2TP AVP and a pair of AFI/SAFI to be
   maintained by the IANA.

13. Security Considerations

   The signaling procedures described in this document does not incur
   additional security considerations that L2TP already provisions.

14. Acknowledgement

   Many thanks to Mark Townsley, Jed Lau and Dmitry Bokotey for their
   review and insightful feedback.

15. References

   [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)",
              RFC 2661, August 1999.

   [L2TPv3]   J. Lau et. al., "Layer Two Tunneling Protocol (version3)",
              draft-ietf-l2tpext-l2tp-base-04.txt, November 2002

   [L2 FW]    L. Andersson et. al., "PPVPN L2 Framework",
              draft-ietf-ppvpn-l2-framework-00.txt, August 2002

   [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3",
              draft-townsley-pwe3-l2tpv3-00.txt, June 2002

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

   [LDPVPN]   E. Rosen, "LDP-based Signaling for L2VPNs",
              draft-rosen-ppvpn-l2-signaling-02.txt, September 2002

   [RFC 2858] T. Bates et. al., "Multiprotocol Extensions for BGP-4",

Luo                                                   	[Page 16]

Internet Draft  draft-luo-l2tpext-l2vpn-signaling-01.txt   February 2003

              RFC 2858, June 2000

   [RFC 2842] R. Chandra et. al., "Capabilities Advertisement with
              BGP-4", RFC2842, May 2000

   [BGPEXT]   S. Sangli et. al., "BGP Extended Communities Attribute",
              draft-ietf-idr-bgp-ext-communities-05.txt, May 2002

16. Authors' Address

   Wei Luo
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   Email: [email-masked]

Luo                                                   	[Page 17]