One document matched: draft-luo-l2tpext-l2vpn-signaling-02.txt
Differences from draft-luo-l2tpext-l2vpn-signaling-01.txt
Network Working Group Wei Luo
Internet Draft Cisco Systems, Inc.
June 2003
L2VPN Signaling Using L2TPv3
draft-luo-l2tpext-l2vpn-signaling-02.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
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-02.txt June 2003
Table of Contents
Status of this Memo.......................................... 1
1. Introduction.............................................. 3
2. Network Reference Models and L2VPN Applications........... 3
3. L2TP Protocol Components.................................. 5
3.1 Control Messages...................................... 5
3.2 Existing AVPs for L2VPN............................... 5
3.3 New AVPs for L2VPN.................................... 6
4. Common L2VPN Addressing................................... 7
4.1 Forwarder Identifiers................................. 7
4.2 Provisioning Forwarders............................... 7
4.3 Heterogeneous L2VPNs.................................. 8
5. L2VPN Signaling Procedures................................ 8
5.1 Overview.............................................. 8
5.2 Pseudowire Tie Detection.............................. 9
5.3 Generic Algorithm..................................... 9
5.4 Application-specific Processing....................... 13
5.4.1 Cross-connect.................................... 13
5.4.2 Virtual Private LAN Service...................... 13
5.4.3 Colored Pools.................................... 14
5.5 Distributed L2VPN Applications........................ 14
5.5.1 Splicing Point-to-point Connections.............. 14
5.5.2 Distributed VPLS................................. 15
6. BGP-based Auto-discovery.................................. 16
6.1 NLRI Encoding of L2VPN Addresses...................... 16
6.2 AFI/SAFI and BGP Capabilities......................... 17
6.3 Route Targets......................................... 17
6.4 Inter-AS L2VPN Applications........................... 18
7. Intellectual Property Notice.............................. 19
8. IANA Considerations....................................... 19
9. Security Considerations................................... 19
10. Acknowledgement.......................................... 19
11. References............................................... 19
12. Authors' Address......................................... 20
Luo [Page 2]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
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 have been highlighted 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 commonalities as well as differences
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 Models and L2VPN Applications
In the LAC-LAC reference model, 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. A pseudowire
is used to bind two "forwarders" together. For different L2VPN
applications, different types of forwarders are defined.
In the L2VPN framework [L2 FW], a LAC is a Provider Edge (PE) device.
LAC and PE are interchangable terms in the context of this document.
Remote systems in the LAC-LAC reference model are Customer Edge (CE)
devices.
+----+ L2 +----+ +----+ L2 +----+
| CE |------| PE |....[core network]....| PE |------| CE |
+----+ +----+ +----+ +----+
|<- emulated service ->|
|<----------------- L2 service -------------->|
Non-distributed L2VPN Network Reference Model
In a simple cross-connect application, an attachment circuit is a
forwarder directly bound to a pseudowire. It is a one-to-one
mapping. Traffic received from the attachment circuit on a local PE
is forwarded to the remote PE through the pseudowire. When the
remote PE receives traffic from the pseudowire, it forwards the
Luo [Page 3]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
traffic to the corresponding attachment circuit on its end. The
forwarding decision is based on the attachment circuit or pseudowire
demultiplexing identifier.
With Virtual Private LAN Service (VPLS), a Virtual Switching Instance
(VSI) is a forwarder connected to one or more attachment circuits and
pseudowires. A single pseudowire is used to connect a pair of VSIs
on two peering PEs. 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. Each
pool is a forwarder and connected through a network of point-to-point
cross-connect. The data forwarding perspective is identical to the
cross-connect application. However, constructing colored pools
involves more complicated signaling procedures.
Another network reference model is the distributed reference model
for L2VPN applications [L2 FW]. Instead of a single device, the PE
functionality is divided into two PE devices: U-PE and N-PE.
PE Functionality PE Functionality
................... ...................
. . . .
+----+ L2 +----+ +----+ . . +----+ +----+ L2 +----+
| CE |--.-|U-PE|---|N-PE|-..[core network]..-|N-PE|---|U-PE|-.--| CE |
+----+ . +----+ +----+ . . +----+ +----+ . +----+
................... ...................
|<--------- emulated service --------->|
|<---------------------- L2 service --------------------->|
Distributed L2VPN Network Reference Model
Unlike the non-distributed reference model where the emulated service
is provided by a single pseudowire, the emulated service is provided
by splicing multiple pseudowires together in the distributed
reference model.
Pseudowire splicing is applicable to all the L2VPN applications
described above, therefore for each application there will be a non-
distributed and a distributed version of deployment.
Luo [Page 4]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
3. L2TP Protocol Components
3.1 Control Messages
L2TP defines two sets of session management procedures: incoming call
and outgoing call. Even though it is entirely possible to use the
outgoing call procedures to signaling L2VPNs, the incoming call
procedures has some advantages in terms of the relevance of the
semantics. [PWE3L2TP] gives more details on why the incoming call
procedures are more appropriate for setting up pseudowires.
The signaling procedures for L2VPNs described in the following
sections are all based on the Incoming Call procedures.
3.2 Existing AVPs for L2VPN
Router ID
The Router ID sent in SCCRQ and SCCRP during control connection setup
establishes the unique identity of each PE.
Pseudowire Capabilities List
The Pseudowire Capabilities List sent in the SCCRQ and SCCRP
indicates the pseudowire types supported by the sending PE. It
merely serves as an advertisement to the receiving PE. Its content
should not affect the control connection setup.
Before a local PE initiates a session of a particular pseudowire type
to a remote PE, it MUST examine whether the remote PE has advertised
this pseudowire type in this AVP, and SHOULD NOT attempt to initiate
the session if the intended pseudowire type is not supported by the
remote PE.
Pseudowire Type
The Pseudowire Type sent in ICRQ signals the intended pseudowire type
to the receiving PE. The receiving PE checks it against its local
pseudowire capabilities 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, it MUST respond with a CDN with an "unsupported pseudowire
type" result code.
Pseudowire Control Encapsulation
Luo [Page 5]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
The Pseudowire Control Encapsulation can be sent in ICRQ, ICRP, and
ICCN. If the receiving PE supports the specified control
encapsulation, it MUST include it in its data packets sent to the
sending PE. Otherwise, it MUST reject the connection by sending a
CDN to the sending PE.
Circuit Status
The Circuit Status is sent in both ICRQ and ICRP to inform the
receiving PE about the circuit status on the sending PE. It can also
be sent in ICCN and SLI to update the status.
Remote End ID
The Remote End ID sent in ICRQ instructs the receiving PE to bind the
proposed pseudowire to the forwarder that has been assigned with the
encoded value.
3.3 New AVPs for L2VPN
Local End ID
The Local End ID AVP, Attribute Type TBA, is an identifier used to
associate a pseudowire to a local forwarder. The Local End ID AVP
may also be used in conjunction with the Remote End ID AVP to detect
pseudowire ties. When it is omitted in the control messages, it is
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The End Identifier field is a variable-length field whose value is
unique for a given PE. 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 field.
Luo [Page 6]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
4. Common L2VPN Addressing
4.1 Forwarder Identifiers
A forwarder identifier is assigned to each forwarder on a given PE
that supports L2VPN applications. The Forwarder ID is unique in the
context of the Router ID. A Forwarder ID is locally significant and
allocated to forwarders regardless their types.
A common L2VPN address is defined as the concatenation of the Router
ID and the Forwarder ID. It's called "common" because the Forwarder
ID value is assigned from a common name space for different types of
forwarders. The common L2VPN addressing scheme makes it possible to
interconnect not only forwarders of the same type, but those of
different types.
4.2 Provisioning Forwarders
In simple cross-connect, each individual attachment circuit is
assigned with a Forwarder ID value. The value may be an arbitrary
integer or a descriptive string. Each attachment circuit is
provisioned with the L2VPN address of the remote attachment circuit
and the next-hop PE address.
In VPLS, each VSI is assigned with a Forwarder ID value. The value
may be the VPN-ID of the VPLS domain. Each VSI is provisioned with
the L2VPN addresses of the remote VSIs and the next-hop PE address.
In colored pool, each pool is assigned with a Forwarder ID and a
"color". The Forwarder ID value may be an arbitrary integer or a
descriptive string. The "color" can be a VPN-ID. Each pool is
provisioned with the L2VPN addresses of the remote pools and the
next-hop PE address.
If the remote Router ID in the L2VPN address is also the next-hop PE
address, the provisioning parameters can be reduced to just the L2VPN
address, i.e. the Router ID and Forwarder ID of the remote forwarder.
In addition, the provisioning can be accomplished through either
manual configuration or some auto-discovery procedure.
Luo [Page 7]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
4.3 Heterogeneous L2VPNs
Often there is more than one form of L2VPN application required in a
network. For example, an individual attachment circuit on one PE
needs to be connected to a VSI or colored pool on another PE 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.
5. L2VPN Signaling Procedures
5.1 Overview
Assume a PE assigns a Forwarder ID to one of its local forwarders,
and knows it needs to set up a pseudowire to a remote forwarder on a
remote PE that has a certain Forwarder ID. This knowledge can be
obtained either through manual configuration or some auto-discovery
procedure.
Before establishing the intended pseudowire, each pair of peering PEs
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 PE examines
whether the remote PE supports the pseudowire type it intends to set
up. Only if the remote PE supports the intended pseudowire type, it
should initiate a pseudowire connection request.
When the local PE receives an ICRQ for a pseudowire connection, it
examines the Forwarder ID values encoded in the Local and Remote End
ID AVPs in order to determine the following:
- whether it has a local forwarder with the Forwarder ID value
specified in the Remote End ID AVP,
Luo [Page 8]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
- whether the remote forwarder with the Forwarder ID value
specified in the Local End ID AVP is allowed to connect with
this local forwarder.
If both conditions are met, it sends an ICRP to the remote PE to
accept the connection request. If either of the two conditions
fails, it sends a CDN to the remote PE to reject the connection
request.
5.2 Pseudowire Tie Detection
Conceivably in the network reference models, as either PE may
initiate a pseudowire to another PE at any time, the PEs could end up
initiating a pseudowire to each other simultaneously.
In order to avoid setting up duplicated pseudowires between two
forwarders, each PE 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 AVPs are present in the ICRQ,
the receiving PE compares them against the Local End ID and Remote
End ID that it already sent in an ICRQ, respectively. 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 the Remote End ID AVP is present in the ICRQ, the Local End
ID is assumed to have the same value as the Remote End ID. The
receiving PE compares the received Remote End ID with the Local End
ID that it already sent in an ICRQ. If the Local End ID in that 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.
5.3 Generic Algorithm
Despite the apparent disparity among different L2VPN applications, a
common set of signaling procedures can be defined.
Each PE 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
Luo [Page 9]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
TARGET_FORWARDERS list. These two lists can be constructed by manual
configuration and/or some auto-discovery procedure.
SOURCE_FORWARDERS TARGET_FORWARDERS
------------------------------------------------------------------
s1: <Router ID : Forwarder ID> t1: <Router ID : Forwarder ID>
s2: <Router ID : Forwarder ID> t2: <Router ID : Forwarder ID>
s3: <Router ID : Forwarder ID> t3: <Router ID : Forwarder ID>
... ...
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 PE participating in L2VPN.
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 established between them. Proceed
to step 6.
4. Compare the Forwarder 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
PE, no pseudowire is needed. The PE 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 PEs,
a pseudowire must be established between them. The PE 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 PE obtains the address of the
remote PE, and establishes a control connection to the remote
PE if one does not already exist.
8. The local PE sends an ICRQ to the remote PE. The Forwarder
IDs of source and target forwarders are encoded in the Local
and Remote End ID AVPs, respectively.
Luo [Page 10]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
9. If the local PE receives a response corresponding to the
ICRQ it just sent, proceed to step 10. Otherwise, if the
local PE receives an ICRQ from the same remote PE, proceed
to step 11.
10. The local PE receives a response from the remote PE. If
it is a CDN, go back to step 2. If it's an ICRP, the local
PE binds the source forwarder to the pseudowire and sends
an ICCN to the remote PE. Go back to step 2.
11. If the local PE receives an ICRQ from the same remote PE,
it needs to perform session tie detection, as described in
Section 5.2. If a session tie is detected, the PE performs
tie breaking.
12. If the local PE loses the tie breaker, it sends a CDN with
the result code that indicates the disconnection is due to
losing the tie breaker. Proceed to step 14.
13. If the local PE wins the tie breaker, it ignores the remote
PE's ICRQ, but acknowledges receipt of the control message
in order to maintain the control connection's reliable
transport, and continues waiting for the response from the
remote PE. Go to step 10.
14. The local PE determines whether it should accept the
connection request, as described in the Section 5.1.
If it accepts the ICRQ, it sends an ICRP to the remote PE.
15. The local PE receives a response from the remote PE. If
it is a CDN, go back to step 2. If it is an ICCN, the local
PE binds the source forwarder to the pseudowire, go back
to step 2.
The following diagram illustrates the above procedure:
Luo [Page 11]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 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 Forwarder 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 12]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 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
5.4 Application-specific Processing
5.4.1 Cross-connect
When a PE learns the L2VPN address of the remote attach circuit, 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 PE binds
the attachment circuit to the pseudowire.
5.4.2 Virtual Private LAN Service
A PE may have multiple VSIs. When a PE learns the L2VPN address of
the remote VSIs, 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 PE binds
the VSI to the pseudowire by making the pseudowire a member link of
the bridging domain defined by the VSI.
Luo [Page 13]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
5.4.3 Colored Pools
A CE may have multiple physical or logical attachment circuits, such
as Frame Relay DLCIs attached to a PE, which form a "pool" of
attachment circuits. Each pool corresponds to a particular CE and is
associated with a particular VPN. If there are multiple CEs of the
same VPN attached to a PE, the PE will have multiple pools associated
with the same VPN.
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 PE, and the pseudowire is bound to an
unused attachment circuit from each pool. For pools on the same PE,
a local cross-connect is formed to bind two attachment circuits.
5.5 Distributed L2VPN Applications
The advantages of this generic L2VPN signaling procedure include not
only being able to interconnect heterogeneous L2VPN applications but
providing a unified signaling procedure for both non-distributed and
distributed L2VPN applications. In other words, no special signaling
or provisioning is required for distributed L2VPN applications. A
local forwarder needs not to know whether the remote forwarder is an
attachment circuit, a VSI, a colored pool, or even a pseudowire that
acts as a "proxy" of some other forwarder. The following sections
illustrate how to apply the generic L2VPN signaling procedures to
distributed L2VPN applications.
5.5.1 Splicing Point-to-point Connections
Suppose U-PE 1 and U-PE 2 each have an attachment circuit or colored
pool that needs to be interconnected via pseudowires. The end-to-end
connection is considered as point-to-point regardless of the number
of pseudowires spliced together.
The forwarders on U-PE 1 and U-PE 2 are denoted in the form of their
L2VPN addresses.
AC/Pool 1: <U-PE 1 Router ID : Forwarder ID 1>
AC/Pool 2: <U-PE 2 Router ID : Forwarder ID 2>
U-PE 1 --- N-PE 3 --- N-PE 4 --- U-PE 2
As described in Section 4.2 on U-PE 1, AC/Pool 1 is provisioned to
Luo [Page 14]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
connect to with AC/Pool 2 and N-PE 3 is the next-hop PE address.
Similarly on U-PE 2, AC/Pool 2 is provisioned to connect to AC/Pool 1
and N-PE 4 is the next-hop PE.
N-PE 3 has two "proxy" forwarders that represent the two actual
forwarders. The "proxy" AC/Pool 1 is provisioned to connect with the
AC/Pool 2 and N-PE 4 is the next-hop PE address. The "proxy" AC/Pool
2 is provisioned to connect to AC/Pool 1 and U-PE 1 is the next-hop
PE address. N-PE 4 is similarly provisioned.
The knowledge of how to provision each forwarder can be obtained from
manual configuration or some auto-discovery procedure.
The signaling procedures are excuted on all U-PEs and N-PEs. When
the targeted L2VPN address in the pseudowire setup message matches a
local forwarder, real or "proxy", the PE binds the pseudowire to it.
N-PEs bind pseudowires to "proxy" forwarders and U-PEs bind
pseudowires to real forwarders.
5.5.2 Distributed VPLS
In distributed VPLS the U-PE has the VSI functionality and the N-PE
is responsible for splicing the pseudowires from the U-PE to other
U-PEs and N-PEs. Suppose each U-PE has a VSI belonging to the same
VPLS domain. Even though each VSI could have a different Forwarder
ID on each U-PE, it does not makes any difference in this example.
So let's say it has a common value, VPN-ID, for the sake of
simplicity.
The forwarders on U-PEs are denoted in the form of their L2VPN
addresses.
VSI 1: <U-PE 1 Router ID : VPN-ID>
VSI 2: <U-PE 2 Router ID : VPN-ID>
VSI 3: <U-PE 3 Router ID : VPN-ID>
VSI 4: <U-PE 4 Router ID : VPN-ID>
U-PE 1 ----+ +---- U-PE 3
| |
| |
N-PE 5 ------- N-PE 6
| |
| |
U-PE 2 ----+ +---- U-PE 4
To set up full-mesh connectivity among the VSIs, each U-PE needs to
Luo [Page 15]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
have three pseudowires to the adjacent N-PE. N-PE then needs to
splice these three pseudowires to another three pseudowires which go
to other U-PE and N-PE respectively.
U-PE 1 learns three remote forwarders: VSI 2, VSI 3 and VSI 4. And
VSI 1 is provisioned to connect to all three and the next-hop PE
address for all three is N-PE 5. Other U-PEs are similarly
provisioned.
N-PE 5 has four "proxy" forwarders representing the four actual VSI
forwarders on the U-PEs. The "proxy" VSI 1 is provisioned to connect
to VSI 3 and VSI 4 with the next-hop PE address as N-PE 6, and to VSI
2 with the next-hop PE address as U-PE 2. Other "proxy" forwarders
are provisioned in the similar fashion. Other N-PEs are also
similarly provisioned.
The knowledge of how to provision each forwarder can be obtained from
manual configuration or some auto-discovery procedure.
The signaling procedures are excuted on all U-PEs and N-PEs. When
the targeted L2VPN address in the pseudowire setup message matches a
local forwarder, real or "proxy", the pseudowire is bound to it. N-
PEs bind pseudowires to "proxy" forwarders and U-PEs bind pseudowires
to real forwarders.
6. 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 is conceivably useful for LDP-based L2VPN signaling as
well.
6.1 NLRI Encoding of L2VPN Addresses
As defined in Section 4, a L2VPN address is the concatenation of the
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.
Luo [Page 16]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
- Prefix: variable-length
The Prefix fields carry the L2VPN address.
When using BGP-based auto-discovery, care needs to be taken to ensure
the Forwarder 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. This makes it easy to deploy heterogeneous L2VPNs with
BGP-based auto-discovery.
6.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 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].
6.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 PE 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
policy. Therefore, the L2VPN signaling will set up a full mesh of
pseudowires among these forwarders using the algorithm described the
Luo [Page 17]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
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 PE, the "hub" RT is assigned to local forwarders as the "export
RT", and the hub PE is configured to "import" only the Common L2VPN
addresses that have the "spoke" RT. On the spoke PE, the "spoke" RT
is assigned to local forwarders as the "export RT", and the spoke PE
is configured to "import" only the Common L2VPN addresses that have
the "hub" RT. This distribution policy will result in (1) spoke PEs
only seeing the forwarders configured on the hub PE, and (2) a hub PE
seeing all forwarders configured on every spoke PE. 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.
6.4 Inter-AS L2VPN Applications
When L2VPN PEs span across AS boundries, for non-distributed L2VPN
applications we need to ensure the inter-AS connectivity among the
PEs. In the case that L2TP use IP or UDP as transport, this means
inter-AS IP reachability, which is provided by BGP.
Sometimes service providers want to enforce certain policies at the
AS boundries including those for L2VPN applications. And they want
the inter-AS L2VPN control connections and pseudowires to run only
between the ASBRs.
PE 1 ----+ +---- PE 3
| |
| |
ASBR 1 ------- ASBR 2
| |
| |
PE 2 ----+ +---- PE 4
This is very similar to the network reference model of distributed
L2VPN applications. Thus, the objectives can be accomplished by
designating the PEs as U-PE and the ASBRs as N-PE. The BGP sessions
between U-PE and N-PE are iBGP sessions, and those between N-PEs are
eBGP sessions. In addition to operations described in Section 5.5,
each ASBR needs to rewrite the BGP next-hop attribute of the received
L2VPN NLRIs to be itself or another ASBR in the same AS before
Luo [Page 18]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
propagating them to its iBGP and eBGP peers.
7. 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.
8. IANA Considerations
This document defines a new L2TP AVP and a pair of AFI/SAFI to be
maintained by the IANA.
9. Security Considerations
The signaling procedures described in this document does not incur
additional security considerations that L2TP already provisions.
10. Acknowledgement
Many thanks to Mark Townsley, Jed Lau and Dmitry Bokotey for their
review and insightful feedback.
11. 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",
Luo [Page 19]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003
draft-rosen-ppvpn-l2-signaling-02.txt, September 2002
[RFC 2858] T. Bates et. al., "Multiprotocol Extensions for BGP-4",
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
12. Authors' Address
Wei Luo
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: luo@cisco.com
Luo [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 13:27:59 |