Network Working Group Himanshu Shah
Internet Draft Xavier Briard
Expiration Date: September 2001 Jim Tsillas
Tenor Networks
Extensions to MPLS-based Layer 2 VPNs
draft-shah-mpls-l2vpn-ext-00.txt
1. 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.
2. Abstract
The Provisioning of VPN based on Layer 2 circuits across MPLS-base
network has been described in draft-kompella-mpls-l2vpn-02.txt. The
draft describes how provider's edge routers distribute configured
VPN information amongst themselves. This information is then
processed to map layer 2 circuits of customer's edge devices to
remote customer devices of the same VPN through MPLS cloud via
adjoining provider's edge devices. The proposal requires a priori
guestimating of customer's growth needs for the VPN and accordingly
over provisioning of a contiguous set of (preferably per platform)
MPLS labels.
Unfortunately, when the actual needs exceed the already provisioned
and advertised labels, incrementing to higher range causes
disruptions in ongoing data traffic.
This document proposes extension to draft-kompella-mpls-l2vpn-02.txt
such that range on provider's edge router can be increased for the
MPLS labels without requiring to being contiguous for all the
customer edge devices. Also, when the range is increased to
accommodate more customer edge devices into the existing VPN, the
processing of increased range advertisement does not disturb the
ongoing data traffic on existing layer 2 circuits.
shah et al. page 1
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
3. Introduction
The service provider's edge (PE) router, which offers layer 2 VPN
services are required to configure VPN specific information which
includes VPN ID, Customer's Edge ID and a range that denotes the
number of customer's edge devices that can be accommodated for this
VPN. The range parameter is recommended to be over-provisioned to
accommodate future additions of customer sites to the VPN with
minimal configuration impact. In addition, if data link is of multi-
access in nature for instance frame relay, "range" number of DLCIs
must be configured where each DLCI denote a direct connection to
remote customer edge device. It is not required that these DLCIs be
contiguous within the range.
The provider's edge router then allocates a contiguous range of MPLS
labels and advertises to its peers; VPN ID, CE ID, CE range and MPLS
label base. The remote peer validates the received information and
proceeds to update cross-connect forwarding table based on which CE-
ID sent the information and what CE-ID is locally configured for the
VPN.
The receiver calculates "inner label" by offsetting the local CE-ID
into the received label base. This "inner label" is then used to
send data traffic to the CE through advertising PE router via MPLS
tunnels. This process of deriving the label by offsetting CE-ID from
base mandates labels to be contiguous.
On the one hand, this requirement of contiguousness offers reduction
in amount of information that needs to be exchanged amongst PE
routers. However, on the other hand disadvantages are two fold.
First, because the manner in which these labels are used (LSP
hierarchical fashion), the labels are required to be (per platform)
global and to obtain a contiguous set of global labels may not always
be possible. Secondly, when need exceeds already provisioned range,
a new range with yet another whole set of contiguous labels are
required. And re-advertising of this new range causes previously
programmed cross-connects be removed from forwarding table and
re-added with new label information.
This document proposes a simple extension to the base document (of
Kompella [Mpls]) where an information element is added to the
distributed VPN information and an additional processing step to
handle this information.
4. Extension to signalling MPLS-Based Layer 2 VPNs
In Kompella [Mpls] draft, L2VPN information block is defined which
constitute the VPN information. This information is then distributed
using either LDP or BGP.
shah et al. page 2
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
A new information element, CE-Base is introduced to allow for
advertisement of multiple ranges. A given range is then said to
begin and end with associated CE-base and CE-range that is present
in the advertisement. The L2VPN FEC element (for LDP) or L2VPN NLRI
(for BGP) is then referred to as a set. One or more set of the VPN
information elements would then constitute the configured range on
the PE router.
4.1 CE-Base
CE-base is Customer Edge base information. The base information
identifies a VPN for a set of CE identifiers that fall within the
CE-base and CE-range. In some sense, the associated MPLS label base
is bounded by CE-base and CE-range. The labels are required to be
sequential for total of CE-range minus CE-base.
User is not required to configure CE-base. Instead, L2VPN software
module obtains fragments of label sets, which are contiguous within
the fragment. One or more fragments can be obtained to support the
configured range. Each fragment is then delineated by CE-base and
CE-range that is distributed to PE peers.
The L2VPN FEC element for LDP as described in Kompella [Mpls] draft
is shown below with added information of CE-base.
"In LDP, VPN CE information and its associated label base are
carried in a Label Mapping message, distributed in the downstream
unsolicited mode described in [LDP]. A new FEC element is defined
below to carry all the information corresponding to a VPN CE, except
from the label base. The label base is carried in the Label TLV
following the FEC TLV. If a FEC element in a FEC TLV encodes Layer
2 VPN information, it MUST be the only FEC element in the FEC TLV."
When advertising more than one range that constitutes the configured
range, user must generate advertisement for each FEC element with
different CE-base information in the FEC TLV.
shah et al. page 3
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
The extended Layer 2 VPN FEC element is depicted in Figure 1 below.
Figure 1: L2 VPN FEC Element
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Encaps. Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Flags | Reserved (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE ID | CE Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE-base | reserved (must be zero) |new
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Connectivity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
. ... .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, following text from the Kompella [Mpls] draft for BGP
signaling.
"In BGP, the Multiprotocol Extensions [BGP-MP] are used to carry
L2-VPN signalling information. [BGP-MP] defines the format of two
BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used
to announce and withdraw the announcement of reachability
information.
We introduce a new address family identifier (AFI) for L2-VPN [to be
assigned by IANA], a new subsequent address family identifier (SAFI)
[to be assigned by IANA], and also a new NLRI format for carrying
the individual L2-VPN CE information. This NLRI will be carried in
the above-mentioned BGP attributes. This NLRI MUST be accompanied
by one or more extended communities. The extended community type is
"Layer 2 VPN" (to be assigned by IANA); and the format is <VPN-
ID>:<connectivity>, where <VPN-ID> is 4 octets in length, and
<connectivity> is two octets. All extended communities accompanying
one or more Layer 2 VPN NLRIs MUST have the same <VPN-ID>."
When advertising more than one range that constitutes a configured
range, more than one NLRIs are included in a single MP_REACH_NLRI or
MP_UNREACH_NLRI BGP attributes.
The format of the extended Layer 2 VPN NLRI is as shown in Figure 2
below.
shah et al. page 4
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
Figure 2: BGP NLRI for L2 VPN Information
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Label base (3 octets) |
+------------------------------------+
| Reserved (Must Be Zero) (1 octet) |
+------------------------------------+
| CE ID (2 octets) |
+------------------------------------+
| CE Base (2 octets) | <- new
+------------------------------------+
| CE Range (2 octets) |
+------------------------------------+
| Variable TLVs (0 to n octets) |
| ... |
+------------------------------------+
4.2. Signalled Information
The Kompella [Mpls] draft describes the individual information
elements that is distributed as part of VPN information.
Following sections describes those elements from the base draft
with changes where necessary.
4.2.1. Type (LDP only)
The Type is L2-VPN (to be decided by IETF Consensus Action).
4.2.2. Length
In LDP, the Length is the entire length of the L2 VPN FEC element,
including the fixed header and all the sub-TLVs.
In BGP, the Length field indicates the length in octets of the L2-
VPN address prefix.
4.2.3. Encapsulation Type
Identifies the layer 2 encapsulation, e.g., ATM, Frame Relay etc.
The following encapsulation types are defined:
shah et al. page 5
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
Value Encapsulation
0 Reserved
1 ATM PDUs (AAL/5)
2 ATM Cells
3 Frame Relay
4 PPP
5 Cisco-HDLC
6 Ethernet VLAN (unswitched)
7 MPLS
4.2.4. Control Flags
This is a bit vector, defined as in the following Figure.
Figure 3: Control Flags Bit Vector
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |S|
+-+-+-+-+-+-+-+-+
The following bit is defined; the rest MUST be set to zero.
Name Bit Meaning
S 0 Sequenced delivery of frames is required
4.2.5. Label base (BGP only)
The label-base which is to be used for determining the inner label
for forwarding packets to the CE identified by CE ID. (Note: LDP
carries the label-base in the Label TLV following the FEC TLV.)
Note that label base is bounded by CE-base and CE-range parameters.
4.2.6. VPN ID (LDP only)
A 32 bit number which uniquely identifies a VPN in a provider's
domain.
4.2.7. CE ID
A 16 bit number which uniquely identifies a CE in a VPN.
4.2.8 CE Base
A 16 bit number which identifies the base of CE ID.
shah et al. page 6
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
4.2.9 CE Range
A 16 bit number which describes the range of CE IDs starting from
CE-base to which the advertised CE is willing to connect. In
particular, a PE receiving an L2 VPN TLV MUST NOT use a label less
than <label-base> or greater than or equal to <label-base> +
( <CE-Range> - <CE-Base> - 1)
when sending traffic for this VPN to the advertising PE. The CE-
Range present in the VPN information does not necessarily represent
the total number of CE-Ids that advertising CE is willing to
connect. In the case, where multiple number of VPN FEC elements
(LDP) or NLRIs (BGP) exist for a VPN, total number of CE-Ids the
advertising CE is willing to connect for the VPN is the sum of (<CE-
range> - <CE-Base>) present in each advertised set. These CE-ranges
between the sets does not have to be contiguous either. For example,
a given VPN contains 50 sites with CE-Ids starting from 0 to 49.
However, a particular PE router could be configured with total
CE-IDs of 20 with ranges of 0 to 9 and 30 to 39. Such level of
flexibility, albeit with additional configuration, is possible.
4.2.10 CE Connectivity (LDP only)
A 32-bit number encoding connectivity. If the leftmost bit is 1,
the CE is a spoke. The remaining 31 bits encode the CE colors (bit
i = 1 means the CE has color i).
4.2.11 Sub-TLVs
New sub-TLVs can be introduced as needed.
In LDP, the TLV encoding mechanism described in [LDP] must be used.
In BGP, TLVs (type takes 1 octet) can be added to extend the
information carried in the L2 VPN address prefix.
A TLV (type = 1) will be used for carrying VLAN IDs if the
encapsulation is VLAN.
4.3 Advantages of using BGP
The Kompella [Mpls] draft discusses various advantages of using BGP
as the signaling protocol for VPN information distribution as
compared to LDP.
The new mechanism proposed in this document where VPN information
can be distributed in multiple sets bodes well in BGP parlance where
each set is an L2VPN NLRI and multiple NLRIs can accompany in a
single MP_REACH_NLRI or MP_UNREACH_NLRI attribute. Thus, the number
of advertisements can be reduced if all the sets are known at the
time of advertisement.
shah et al. page 7
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
5.0. Adding a New Site
The first step in adding a new site to a VPN is to pick a new CE ID.
If all current members of the VPN are over-provisioned, i.e., their
range includes the new CE ID, adding the new site is a purely local
task. Otherwise, the sites whose range doesn't include the new CE ID
and wish to communicate directly with the new CE must have their
ranges increased to incorporate the new CE ID.
In the circumstances when the range is increased, PE router does not
have to obtain a whole new set of labels that are contiguous from 0
to increased range. Instead, it obtains a small set of labels that
covers the difference between the old range and new range and some
increment to cover for future growth. This could be obtained in one
or more sets.
For example, original range configured in the PE router was 50. The
service provider now wants to add 4 more sites to this VPN. It would
increase the range to 60 with over-provision of 6 more sites. Now
lets suppose that PE router could only obtain 2 sets of 5 each
contiguous labels. PE router would then generate two L2VPN FEC
element, one for each set, with CE-base and CE-range in one set to
be 50 and 55 respectively and 55 and 60 in the second set.
The next step is ensuring that the new site has the required
connectivity (see below). This may require tweaking the
connectivity mechanism; however, in several common cases, the only
configuration needed is local to the PE to which the CE is attached.
The rest of the configuration is a local matter between the new CE
and the PE to which it is attached.
It bears repeating that the key to making additions easy is over-
provisioning. However, what is being over-provisioned is the number
of DLCIs/VCIs that connect the CE to the PE. This is a local
matter, and generally is not an issue.
5.1. PE Information Exchange
When a PE is configured with all the needed information for a CE, it
first of all chooses a contiguous set of labels with n labels, where
n may or may not be the whole CE's range. In the event that a
contiguous set of labels for the entire range could not be obtained,
PE may obtain more than one smaller sets where individual set has
contiguous labels and the combined sets represent the total range.
Call the smallest label in each set the label-base. The PE then
advertises each set(for this CE): its Router ID, the VPN ID, the CE
ID, CE-base, CE-Range, and the label-base. When one set does not
equal to CE's configured range, more than one set are advertised.
shah et al. page 8
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
This is the basic Layer 2 VPN advertisement. This same
advertisement is sent to all other PEs. Note that PEs that may not
be part of the VPN can receive and keep this information, in case at
some future point, a CE connected to the PE joins the VPN. Also,
note that PE participating in the VPN must save all the VPN
information which may be spread in multiple sets.
If the PE-CE connection goes down, or the CE configuration is
removed, the above advertisement is withdrawn.
5.1.1 PE Advertisement Processing
When a PE receives a Layer 2 VPN advertisement of a given set, it
checks if the VPN ID matches any VPN that it is a member of. If
not, the PE just stores the advertisement for future use. If VPN
membership is verified but the received information set does not
include the configured CE-ID, PE must save this information for
later use.
The simple rule of thumb when processing VPN information in multiple
sets, is to match the local CE-ID through each set to find a set
where the CE-ID falls within the CE-base and CE-range of the set.
The CE-base is than subtracted from CE-ID and used as an offset into
the associated label base to derive the "inner label" for send data
traffic. Same logic is used with received CE-ID and the local VPN
information in the multiple sets to derive the "inner label" to
expect on receive data traffic.
Lets suppose the advertisement is from PE A for VPN X, CE m with
set range S-Rm, set base S-Bm and label base Lm. For each CE that
the receiving PE B is connected to that is member of VPN X, PE B
does the following.
0) Look up the configuration information associated with the CE.
If the encapsulation type for VPN X in the advertisement does
not match the configured encapsulation type for VPN X, stop.
shah et al. page 9
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
1) Say the configured CE-ID is k, the configured range is Rk, and
the DLCI list is Dk[]. Also, the label base PE B allocated for
this CE is in n sets, then set bases are S-B(1-n)k, set ranges
are S-R(1-n_k and label bases are L(1-n)k where n is the
number of sets.
2) Check if k = m. If so, issue an error: "CE-ID k has been
allocated to two CE in VPN X (check CE at PE A)". Stop.
3) Check if S-Bm <= k < S-Rm. The received VPN information for a
set does not include the configured CE-ID. Save this
information.
4) Look through local 1 to n sets to find the set which contains
the CE ID m. Let this set be S-Rjk (Set range j of CE-ID k).
If none of the set contains this CE ID m, stop and issue a
warning: "Cannot communicate with CE m (PE A) of VPN X:
outside range".
5) Look in the appropriate table to see which label will get to
PE A. This is the "outer" label, Z.
6) The DLCI that CE-k will use to talk to CE-m is Dk[m]. The
"inner" label for sending packets to CE-m is (Lm + (k - S-Bm)).
The "inner" label on which to expect packets from CE-m
is (Ljk + (m - S-Bjk)).
7) Install a "route" such that packets from CE-k with DLCI Dk[m]
will be sent with outer label Z, inner label (Lm + (k - S-Bm)).
Also, install a route such that packets received with
label (Lnk + (m - S-Bjk)) will be mapped to DLCI Dk[m] and be
sent to CE-k.
8) Activate DLCI Dk[m] to the CE. This can be done using LMI.
If an advertisement is withdrawn, the appropriate DLCI must be de-
activated, and the corresponding routes must be removed from the
forwarding table.
5.1.2. Example of PE Advertisment Processing
shah et al. page 10
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
Figure 3: Example Network Topology
S0 S3
.............. ..............
. . . .
. +-----+ . . .
. | CE0 |-----------+ . +-----+ .
. +-----+ . | . | CE5 | .
. . | . +--+--+ .
. +-----+ . | . | .
. | CE1 |-------+ | .......|......
. +-----+ . | | /
. . | | /
.............. | | /
| | SP Network /
.....|...|.............................../.....
. | | / .
. +-+---+-+ +-------+ / .
. | PE0 |-------| P |-- | .
. +-+---+-+ +-------+ \ | .
. / \ \ +---+---+ .
. | -----+ --| PE2 | .
. | | +---+---+ .
. | +---+---+ / .
. | | PE1 | / .
. | +---+---+ / .
. | \ / .
...|.............|.............../.............
| | /
| | /
| | /
S1 | | S2 /
.............. | ........|........../......
. . | . | | .
. +-----+ . | . +--+--+ +--+--+ .
. | CE2 |-----+ . | CE3 | | CE4 | .
. +-----+ . . +-----+ +-----+ .
. . . .
.............. ..........................
Consider the example network of Figure 3. Let the VPN connecting S0,
S1, S2 and S3 have a VPN id of 1. Suppose PE2 receives an
advertisement from PE0 for VPN 1, CE ID 0, CE-base = 4 with CE range
R0 = 10 and label base L0 = 1000. Since PE2 is connected to CE4
which is also in VPN 1, PE2 does the following:
0) Look up the configuration information associated with CE4. The
advertised encapsulation type matches the configured
encapsulation type (both are Frame Relay), so proceed.
shah et al. page 11
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
1) Let's suppose that CE4 has 2 sets. Set 1 with set base (S-B4(1))
= 0, set range (S-R4(1)= 2, label base (L4(1)) = 2000 and set 2
has set base (S-B4(2)) = 2, set range (S-R4(2)) = 10 and label
base (L4(2)) = 4000. The configured range R4 is 9, its DLCI list
D4[] is [ 107, 209, 265, 301, 414, 555, 654, 777, 888].
2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 5.1.1 is
skipped.
3) Since CE4's id is less than received range R0 (= 10) and greater
than equal to CE-base = 4, step 3 of 5.1.1 is passed. CE0's id is
then matched in local set 1. As it turns out CE 0 is equal to
S-B4{1) (= 0) of set 1. Step 4 of 5.1.1 is passed.
4) Look in the appropriate table on PE2 to see which label will get
to PE0. Let the label be 10001.
5) The DLCI that CE4 will use to talk to CE0 is D4[0], i.e., 107.
The inner label for sending packets to CE0 is (4 - CE-base) equal
0, i.e. 1000. The inner label on which to expect packets from
CE0 is (0 - S-B4(1)) equal 0 which is (L4(1) + 0), i.e., 2000.
6) Install a "route" such that packets from CE4 with DLCI 107 will
be sent with outer label 10001, inner label 1000. Also,
install a route such that packets received with label 2000 will
be mapped to DLCI 107 and be sent to CE4.
7) Activate DLCI 107 to CE4.
Since CE5 is also attached to PE2, PE2 needs to do processing
similar to the above for CE5.
Similarly, when PE0 receives an advertis ment from PE2 for VPN1,
CE4, with two sets, S-B4(1) = 0, S-R4(1) = 2, L4(1) = 2000 and S-
B4(2) = 2, S-R4(2) = 10, L4(2) = 4000. PE0 processes the
advertis0ment for CE0 (and CE1, which is also in VPN 1).
0) Look up the configuration information associated with CE0. The
advertised encapsulation type matches the configured
encapsulation type (both are Frame Relay), so proceed.
1) CE0 has two range sets. S-B0(1) = 0, S-R0(1) = 4 and label base
L0(1) = 577. S-B0(2) = 4, S-R0(2) = 10 and label base L0(2) =
1000. Its DLCI list D0[] is [100 - 109].
2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 5.1.1
is skipped.
shah et al. page 12
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
3) CE0's ID is first checked in received set 1. Since CE-ID 0 is
greater than equal to S-B4(1) (=0) and is less than S-R4(1)(= 2),
label base L4(1) of set 1 is selected. Similarly, received CE-ID
4 is checked against the local set 1. CE-ID 4 is greater than
equal to set base S-B0(1) (= 0) but not less than set range S-
R0(1) (= 4), set 1 is not selected. Now, CE-ID 4 is checked
against local set 2. Since CE-ID 4 is greater than equal to set
base S-B0(2) (= 4) and less than set range S-R0(2) (= 10), label
base L0(2) of set 2 is selected.
4) Let the outer label to reach PE2 be 9999.
5) The DLCI which CE0 will use to talk to CE4 is D0[4], i.e., 103.
The inner label for send packets to CE4 is L4(1) = 2000 + (CE-ID
( = 0) - CE-Base ( = 0) 0), i.e., 2000 + (0 - 0) = 2000. The
inner label on which to expect the packets from CE4 is L0(2) =
1000 + CE-ID ( = 4) - CE-Base (= 4), i.e., 1000 + (4 - 4) = 1000.
6) Install a "route" such that packets from CE0 with DLCI 104 will
be sent with outer label 9999, inner label 2000. Also, install a
route that packets received with label 1000 will be mapped to
DLCI 104 and be set to CE0.
7) Activate DLCI 103 to CE0.
Note that the inner label of 2000, computed by PE0, for sending
packets from CE0 to CE4 is the same as what PE2 computed as the
incoming label for receiving packets originated at CE0 and destined
to CE4. Similarly, the inner label of 1000, computed by PE0, for
receiving packets from CE4 to CE0 is same what PE2 computed as the
outgoing label for sending packets originated at CE4 and destined to
CE0.
6.0 Generalizing the VPN Topology
In the Kompella [Mpls] draft, full mesh and hub and spoke type of
VPN topologies is described using the color value and spoke bit in
the connectivity field of the distributed VPN information. However,
the spoke bit is available only when using the LDP signaling.
Same type of VPN topologies can be created when using BGP as
signaling mechanism by creative ways of using the CE-Ids. For
example, in order to create a hub and spoke type of VPN topologies,
"hub" PE routers could be configured with CE-ID of the lowest values
and highest range and the "spoke" PE routers with higher CE-IDs and
the range of 1 or sum of the "hub" sites. The processing algorithm
described above will then have "spoke" PE routers not creating layer
2 circuits among themseleves as the "spoke" CE-Ids would not fall
under the received range.
shah et al. page 13
Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001
It is also possible to create sub-VPN clusters by using CE-ID
sub ranges. This would require additional configuration on a
per set basis where for each set, set-base and set-range is
configured. With such configuration, all those CE-IDs that
fall within the configured sets would form connectivity with
other. These type of methodologies does not incur any
further extensions to the protocol and in fact is the added
advantage of the extension proposed in this document.
7. Acknowledgements
Some of the text in this document is "borrowed" from the base
Kompella draft for completeness. We would like to thank
Bill Townsend for reviewing the draft.
8. References
[MPLS] Kompella et al., "MPLS based Layer 2 VPNs", draft-kompella-
mpls-l2vpn-02.txt, November 2000.
9. Authors Information
Himanshu Shah
Tenor Networks
100 Nanog Park
Acton, MA 01720
hshah@tenornetworks.com
Xavier Briard
Tenor Networks
100 Nanog Park
Acton, MA 01720
xbriard@tenornetworks.com
Jim Tsillas
Tenor Networks
100 Nanog Park
Acton, MA 01720
jtsillas@tenornetworks.com
shah et al. page 14