Network Working Group Tissa Senevirathne
Internet Draft Paul Billinghurst
Document: draft-tsenevir-8021qbgp-00.txt Hamid Ould-Brahim
Category: Informational Bryan Gleeson
Nortel Networks
November 2000
Distribution of 802.1Q VLAN information using BGP 4-MP Extensions
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
This paper presents a method to distribute 802.1Q VLAN information
across Autonomous Systems using BGP-4. The solution provided here
allows to learn VLAN information across Autonomous Systems. The VLAN
information and end point discovery presented here is especially
useful in providing end-to-end Virtual LAN Services across
Autonomous Systems.
Senevirathne Informational - April 2001 1
draft-tsenevir-8021qbgp-00.txt November 2000
Table of Content
1. Conventions used in this document..................................2
2. Introduction.......................................................2
3. Typical Deployment Scenario........................................3
4. VLAN Domain Identifier (VDI).......................................4
4.1. Use of BGP Extended Communities..................................4
5. Encoding VLAN information in BGP...................................6
5.1.1 Multiprotocol Reachable NLRI....................................6
5.1.2 NLRI Encoding...................................................7
5.1.3 Encoding of VLAN Information....................................7
5.2 Advertising Unreachability.......................................10
6. Capability Advertisement..........................................11
7. Population of VFEC................................................11
8. VLAN information Aggregation......................................11
9. VLAN Distribution over E-BGP Sessions.............................12
10. VLAN Distribution over I-BGP Sessions............................12
11. Security Considerations..........................................12
12. References.......................................................12
13. Acknowledgments..................................................13
14. Author's Addresses...............................................14
Full Copyright Statement.............................................15
1. Conventions used in this document
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 [2].
2. Introduction
This paper presents a possible method of distributing 802.1Q VLAN
information using BGP.
With the increasing prospect of MAN (Metropolitan Area Networks) and
optical Ethernet solutions, End to End Layer 2 connectivity
provisioning is attracting attention. There are several publications
that present various tunneling protocols to transport Layer 2
traffic across IP Networks. However, there are only few publications
available in the area of automatic distribution of VLAN information.
Automatic distribution of VLAN information becomes important in
large networks, especially where large number of mutually exclusive
VLAN topologies exist.
[3] Paper presents a method of distributing VLAN related information
using OSPF Opaque LSA. [4] Presents method of Layer 2 information
distribution using BGP. However, level of detail presented here is
different to [4]. This paper does not attempt to extend any Layer 1
connectivity across MPLS network, rather it provides a VPN sort of
connectivity at the Layer 2 level. Concepts and format of VLAN
information presented in [3] have been extended in this paper to
Senevirathne Informational - April 2001 2
draft-tsenevir-8021qbgp-00.txt November 2000
facilitate distribution of VLAN information across Autonomous
Systems.
Unlike, IP address allocations, VLANs are allocated at random and at
the will of the customer. As an example, VLAN v1 of customer c1 may
not have any co-relation to VLAN v2 of customer c2. This random
distribution of VLAN information makes classification of incoming
packets to Layer 2 VPN more complex than classification of incoming
packets to a Layer 3 VPN. To resolve this we have introduced a
concept of VLAN Domain Identifier (VDI). VDI provides a method of
distributing, multiple, mutually exclusive Layer 2 topologies on a
given network infrastructure. [3] Presents methods to group VLAN
ranges within a given VLAN domain. Thus providing a hierarchical and
scalable Layer 2 VPN solution.
In this paper we propose to use BGP multiprotocol extensions to
carry proposed VLAN information. The methods used here are similar
to [5]. A given update message may carry VLAN Reachability
Information for more than one VLAN domain.
3. Typical Deployment Scenario
Below is a typical scenario where Layer 2 end-to-end service is
required. However, the proposed solution is not limited to the
scenario below.
------------ ----------
----------- | | | |
| | | | | | ---------
| ------- | | | | | | |
| |VDI-V1| | | | | | | |
| ------- | L2 | ------ | BB | ----- | L2 | ------ |
| |--------||VFEC-1| |------| |VFEC-1||-----| |VDI-V1||
| ------- | | ------ | | ------ | | ------ |
| |VDI-V2| | | | | | | |
| -------- | | ------ | | | | |
| | ||VFEC-2| | | | | |
------------ | ------ | | | ---------
CE-1 | | | | CE-2
------------ ----------
PE-1 PE-2
L2 Layer 2 Connectivity
BB Back Bone Network with BGP
It is assumed there is a BGP connectivity between each of PE
devices. It is assumed that there exists a Layer 2 connectivity
between CE and PE (say this is 1 Gig Link). Each PE maintain a VFEC
[6] (VLAN Forwarding Equivalence Class) per VLAN Domain.
Senevirathne Informational - April 2001 3
draft-tsenevir-8021qbgp-00.txt November 2000
PE maintains VFEC entries for locally attached devices. Local VFEC
entries are either obtained via static configuration or by some
other method.
PE learns about the VFEC entries in other devices using methods
described in this document and [3]. It is the function of the
receiving PE to update the appropriate "VLAN domain" VFEC table,
according to the incoming VDI field in the BGP update message (see
below for details).
In the above figure, VFEC-1 corresponds to VLAN domain V1. VFEC-1 of
PE-1 contain reachability and other information required to reach
CE-2 VLAN V1. VLAN information on CE-2 and PE-2 reachability is
learnt by PE-1 via BGP extensions presented in this paper.
Similarly, VFEC-1 in PE-2 learns reachability and other information
about VLAN V1 in CE-1 via BGP extensions presented here.
4. VLAN Domain Identifier (VDI)
As discussed earlier, there could exist multiple VLAN topologies
(domains) within a given IP topology. These VLANs may reside in
different Autonomous Systems (AS), these AS may be controlled by
different providers. VDI is a two level identifier. VDI identifies
both the corresponding AS and VLAN domain ID within the AS. Thus VDI
is defined as {AS:Domain_ID}. It is assumed that, two VLAN domains
are in the same layer 2 topology, if and only if the VLAN Domain_ID
are equal and the remote AS is part of the peering ASs for this
{AS:Domain_ID}. The AS-VLAN peering list is manually configured. If
there is large number of AS-VLAN peers, one may choose to use
Extended Community Attribute for the purpose of matching incoming
VDIs to local VDI. As such AS number may be used in conjunction with
local policies to accept or reject VLAN reachable information from
that Autonomous System (AS).
Encoding of VDI
+--------------------------------------+
| AS (2 Octets) |
+--------------------------------------+
| Domain ID (4 Octets) |
+--------------------------------------+
AS
Autonomous System Identifier
Domain ID
VLAN Domain Identity Number. This is a 32-bit number that is
assigned with mutual consensus between different AS administrators,
who wish to provide connectivity to the specified VLAN domain.
4.1. Use of BGP Extended Communities
Senevirathne Informational - April 2001 4
draft-tsenevir-8021qbgp-00.txt November 2000
The BGP Communities were defined in [7] to simplify application of
complex policies. Without BGP Communities, also known as route
coloring [8], implementation of complex policies in large routing
environment becomes administratively expensive, if not prohibitive.
BGP Community is defined as a 4-octet value. General usage of the
community is {AS:ID}; here AS is the 2-octet Autonomous System
number and ID is arbitrary 2-octet number. The above proposed VDI
numbering scheme follows a similar format as the common community
value encoding. As a result there is a risk of these mutually
exclusive community strings overlapping.
The BGP Extended Communities Attribute [9], provides a method to
define communities attributes without the risk of overlap. In
addition Extended Communities Attribute presented in [9] provides a
structured definition of Community Attributes. Thereby, facilitating
easy implementation of complex policies.
In light of the above reasons, in this paper, we suggest to use
Extended Communities Attribute to propagate Communities with VLAN
distribution information.
The extended community may be used by BGP routers to implement
complex VLAN policies easily. As an example a PE may want to use
VLAN reachability announced by a specific PE only for backup
purpose. All VLAN reachability learnt from that PE may be tagged
with some Extended Community, such that all the VLAN rechability
with that community gets a lower priority.
Presented below is the preferred Extended Communities Attribute
encoding for the VLAN distribution. Extended Community sub-Type
0x8020 (hex) is proposed for this purpose. However, if the proposal
is accepted a specific value for this purpose will be requested
through IANA.
+--------------------------------------+
| Type (2 Octets)=0x8020 |
+--------------------------------------+
| AS (2 Octets) |
+--------------------------------------+
| VLAN Community ID (4 Octets) |
+--------------------------------------+
Type
Two Octet field, suggested value 0x8020, see [9] for details.
AS
Autonomous System number assigned by IANA.
VLAN Community ID
Senevirathne Informational - April 2001 5
draft-tsenevir-8021qbgp-00.txt November 2000
Community String applied to this update message. NOTE: VLAN
Community ID, can be different from Domain_ID field in VDI. This is
especially true if a single Extended Community is scoping multiple
VLAN Domain distributions in a single update message.
5. Encoding VLAN information in BGP
BGP-4 Multiprotocol Extensions [10] were designed to carry non IP
information in BGP messages. Here we propose to use BGP-4
Multiprotcol Extensions to distribute Layer 2 VLAN information and
other related services.
Subsequent Address Family Identifier (SAFI) will indicate the
receiving routers that this attribute is carrying Layer 2 VLAN
information. At present, it is suggested to use 130 (decimal) for
SAFI field. Values 0-127 are reserved by IANA. If this proposal is
accepted it is suggested that a value in the range of 1-127 is
requested from IANA for this purpose.
5.1.1 Multiprotocol Reachable NLRI
[10] Presents the encoding format of the MP_REACH_NLRI. We intend to
use the attribute with no modification to the encoding format. NLRI
field in the MP_REACH_NLRI attribute is enhanced to carry proposed
VLAN information.
+----------------------------------------------------+
| Address Family Identifier (2 Octets) |
+----------------------------------------------------+
| Subsequent Address Family Identifier (1 Octet) |
+----------------------------------------------------+
| Length of Next Hop Network Address (1 Octet) |
+----------------------------------------------------+
| Network Address of Next Hop (variable) |
+----------------------------------------------------+
| Number of SNPAs (1 Octet) |
+----------------------------------------------------+
| SNPA definition as in [10] |
~ ~
| |
+----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+----------------------------------------------------+
The definition and meaning of the fields are as specified in [10].
Presented below are the fields that carry special meaning for this
proposal.
Subsequent Address Family Identifier
This field indicates that this MP-REACH-NLRI is carrying Layer 2
information. Suggested value is 130 (decimal).
Senevirathne Informational - April 2001 6
draft-tsenevir-8021qbgp-00.txt November 2000
Network Layer Reachability Information
This field carries the VLAN information that is being distributed.
See Section 5.1.2 below for the encoding of the field.
5.1.2 NLRI Encoding
In order to support distribution of 802.1Q VLAN information, NLRI
field is encoded as below.
+---------------------------------------------------------------+
| Length of the NLRI (2 Octets) |
+---------------------------------------------------------------+
| Number of VLAN Distribution Information (2 Octets) |
+---------------------------------------------------------------+
| Length of the First VLAN Distribution Information (2 Octets) |
+---------------------------------------------------------------+
| First VLAN distribution Information (variable) |
+---------------------------------------------------------------+
| Length of the Second VLAN Distribution Information (2 Octets) |
+---------------------------------------------------------------+
| Second VLAN distribution Information (variable) |
+---------------------------------------------------------------+
| |
~ ~
| |
+---------------------------------------------------------------+
| Length of the N th VLAN Distribution Information (2 Octets) |
+---------------------------------------------------------------+
| N th VLAN distribution Information (variable) |
+---------------------------------------------------------------+
Definition and meaning of the fields are as below
Length of the NLRI
The length of the NLRI in bytes.
Number of VLAN Distribution Information.
Number of VLAN Distribution Information encoded in this NLRI.
Length of the VLAN Distribution Information
Length of the VLAN distribution information in bytes.
VLAN distribution Information
The VLAN information that is being distributed.
5.1.3 Encoding of VLAN Information
Senevirathne Informational - April 2001 7
draft-tsenevir-8021qbgp-00.txt November 2000
VLAN information presented in [3] is required to be encoded in the
VLAN distribution field. Observation of the same information format
allows convenient distribution of VLAN information from OSPF to BGP
and vice versa.
+----------------------------------------------------------+
| VLAN Domain Identifier (VDI) (6 Octets) |
+----------------------------------------------------------+
| Length of the End Point IP Address (1 Octets) |
+----------------------------------------------------------+
| End Point IP Address |
+----------------------------------------------------------+
| Length of BPDU Tag (1 Octets) |
+----------------------------------------------------------+
| BPDU Tag ( 2 Octets) |
+----------------------------------------------------------+
| Length of Global Services (2 Octets) |
+----------------------------------------------------------+
| Global Services (variable) |
+----------------------------------------------------------+
| Number of VLAN Distributions (2 Octets) |
+----------------------------------------------------------+
| First VLAN Information (6 Octets) |
+----------------------------------------------------------+
| Number of Labels in the First Label Stack(1 Octet) |
+----------------------------------------------------------+
| First Label Stack (variable) |
+----------------------------------------------------------+
~ ~
| |
+----------------------------------------------------------+
| N th VLAN Information (6 Octets) |
+----------------------------------------------------------+
| Number of Labels in the First Label Stack (1 Octet) |
+----------------------------------------------------------+
| N th Label Stack (variable) |
+----------------------------------------------------------+
VLAN Domain Identifier (VDI)
VLAN Domain Identifier for this VLAN information, encoded as Section
4 above.
Length of End Point IP Address
Length of the IP Address is in bits
End point IP Address
IP Address of the end point.
Length of the BPDU Tag
Senevirathne Informational - April 2001 8
draft-tsenevir-8021qbgp-00.txt November 2000
Length of the BPDU Tag in bits. Supported values are 0 or 12. All
other values are reserved. 0 indicates there is no BPDU TAG
associated.
Length of Global Services
Length of Global Services in Bytes.
Global Services
Associated Services with this VDI.(TBD)
Number of Labels in the First Label Stack
Number of Labels in this Stack. Value zero indicates there are no
labels associated with this VDI.
Label Stack
Label Stack contain one or more 3 octet long labels. The high-order
bit contain the bottom of the stack. Remaining 3 high order bits are
all reserved. Remaining 20 bits of the label contain the label value
[11]. The entries in the Label Stack are zero padded to align with 4
octet (32 bit) boundaries.
The end-devices optionally choose to advertise a MPLS label that
could be pushed in to the Label Stack. This label(s) may provide the
ability to merge several MPLS tunnels on to a single outgoing tunnel
or may define wider forwarding scope at the egress. See Section 10.,
below for scaling example.
VLAN Information
VLAN Information is a combination of several fields.
+--------------------------------------------------------------+
| VLAN Flags (1 Octet) |
+--------------------------------------------------------------+
| Reserved (1 Octet)| Start VLAN (12 bits) | End VLAN (12 bits)|
+--------------------------------------------------------------+
| Reserved (2 bits) | SP (3 bits) | EP (3 bits) |
+--------------------------------------------------------------+
VLAN Flags
+-------------------------------------------------------------+
| MV ( 1 bit) |
+-------------------------------------------------------------+
| FV (2 bits) |
+-------------------------------------------------------------+
| MP (1 bit) |
+-------------------------------------------------------------+
Senevirathne Informational - April 2001 9
draft-tsenevir-8021qbgp-00.txt November 2000
| FP (2 bits) |
+-------------------------------------------------------------+
| Reserved (2 bits) |
+-------------------------------------------------------------+
MV
VLAN TAG Matching Flag
0 Liberal Matching, 1 Conservative Matching. See [6] for details
FV
VLAN TAG Field Flag
VLAN Tag Range Match - b'00
VLAN Tag Exact Match - b'01
MP
P bit Matching Flag
0 Liberal Matching, 1 Conservative Matching. See [6] for details
FP
P bit Field Flag
P bit Range Match - b'10
P bit Exact Match - b'11
Start VLAN
Starting TAG of this VLAN entry
End VLAN
End TAG of this VLAN entry. This field is ignored if FV== b'01
SP
Starting P bit value
EP
End value of P bit. This field is ignored if FP==b'11
Reserved
All reserved fields are set to zero in transmission and ignored in
receipt.
5.2 Advertising Unreachability
Senevirathne Informational - April 2001 10
draft-tsenevir-8021qbgp-00.txt November 2000
It may be required to withdraw either an entire VLAN or some subset
of services. We suggest that the same encoding format as the VLAN
reachability encoding be used in MP-UNREACH-NLRI.
6. Capability Advertisement
Not all BGP speakers are required to provide Layer 2 tunneling
services. However, they may be required to participate in Layer 2
VLAN distribution. However, in order to properly handle Multi
protocol extensions, all the BGP speakers are required to be MP
capable. The MP capability is advertised using the methods specified
in [12], with Capability set to 1 with SAFI set to 130 (TBD).
7. Population of VFEC
Each device that is providing Layer 2 VLAN services maintains a
separate instance of VFEC for each VLAN domain (or Domain_ID). Some
of the entries are directly attached VLAN information. Directly
attached information are either statically configured or learnt by
some other mechanism such as [3].
BGP acceptance policy populates appropriate VFEC tables with the
incoming VLAN distribution information. There may be local policies
to reject some VLAN domains from some AS.
BGP announce policy would announce directly attached (or locally
learnt) VLANs via the methods presented here. In some situations
there may be local policies to prevent announcing some or all of
this VLAN information via BGP.
Exact format of the VFEC depends on the Layer 2 tunneling protocol
being implemented. [6] Presents VFEC format for MPLS based layer 2
tunnels. Details of the format and the construction of the VFEC is
implementation dependent and beyond the scope of this document.
8. VLAN information Aggregation
-----
| |------------
| AS 1 | |
----- -------- ----------
| |------| |
| AS 4 | | AS 3 |
------ -------- ----------
| | |
| AS 2 |------------
------
Senevirathne Informational - April 2001 11
draft-tsenevir-8021qbgp-00.txt November 2000
Suppose AS 4 is providing transitive services to AS 1, 2 and 3. In
this scenario, AS 4 may aggregate all the VLAN information from AS 3
and advertise to AS 1 and AS 2 and vice versa. As explained in [13],
AS 4 may advertise a single label to both AS 1 and 2. AS 1 and 2, in
turn can use this Label, either as the top label or part of the
Label Stack to merge traffic going to AS 3, thereby providing
effective scaling in large deployments.
9. VLAN Distribution over E-BGP Sessions
The concepts presented here together with AS local policies can be
used for inter-AS VLAN distribution. Extended Communities presented
in section 4.1 may be useful in implementing complex policies such
as backup paths etc. The key is, the concepts presented here use the
BGP Multiprotocol extensions to distribute VLAN information, as a
result most of the E-BGP methods used in IP routing can be easily
implemented.
10. VLAN Distribution over I-BGP Sessions
Use of IGP such as OSPF to distribute VLAN information within a
large Autonomous system may lead to scaling issues, specially in
environment where, changes to the VLAN topology is frequent.
However, it is noted here, that calculations such as SPF (Shortest
Path First) is not performed on VLAN Distribution Information.
Hence, the impact may be less critical than that of classical IP
routing. In any case use of I-BGP may provide better manageability
and imperative if the AS is multi homed and providing transitive
services.
Full meshed network topology is a fundamental requirement of
classical I-BGP. This requirement leads to scaling issues in large
networks and possibly makes I-BGP administratively prohibitive.
There are several solutions to circumvent the need of fully meshed
I-BGP topology. Route Reflector concept presented in [14] provides a
method to construct manageable I-BGP peer network. There are no
additional changes needed to distribute VLAN information using Route
Reflector methods explained in [14], except that BGP speakers are
able to understand BGP-MP extensions [10] and Extended Communities
attributes [9].
11. Security Considerations
This implementation does not affect the underlying security
requirements of BGP-4.
12. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
Senevirathne Informational - April 2001 12
draft-tsenevir-8021qbgp-00.txt November 2000
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Senevirathe, T, and Billinghurst, P., "Distribution of 802.1Q
VLAN information using OSPF Opaque LSA", Work in Progress,
October 2000.
4 Kompella, K., et al., "MPLS-based Layer 2 VPNs", Work in
Progress, October 2000.
5 Ould-Brahim, H., et al., "BGP/VPN: VPN Information Discovery for
Network-based VPNs", Work in Progress, July 2000.
6 Senevirathne, T., and Billinghurst, P., "Use of CR-LDP or RSVP-TE
to Extend 802.1Q Virtual LANs Across MPLS Networks", Work in
Progress, October 2000.
7 Chandra, R., "BGP Communities Attribute", RFC 1997, August 1996.
8 Stewart III, J.W., "BGP4 Inter-Domain Routing in the Internet",
Addison-Wesley, 1998.
9 Ramachandra, S., and Tappen, D., " BGP Extended Communities
Attribute", Work in Progress, May 2000.
10 Bates, T., et al., "Multiprotocol Extensions for BGP-4", RFC
2283, February 1198.
11 Rosen, E., et al., "MPLS Label Stack Encoding", Work in Progress,
July 2000.
12 Chandra, R., and Scudder, J., "Carrying Label Information in BGP-
4", Work in Progress, January 2000.
13 Rekhter, Y and Rosen, E., "Carrying Label Information in BGP-4",
Work in Progress, January 2000
14 Bates, T., et.al., "BGP Route Reflection - An alternative to full
mesh IBGP", RFC 1966, June 1996.
13. Acknowledgments
Ideas presented in this document have been influenced by sighted
references and ongoing work in the IETF. Akbal Karlcut provided
valuable suggestions.
Senevirathne Informational - April 2001 13
draft-tsenevir-8021qbgp-00.txt November 2000
14. Author's Addresses
Tissa Senevirathne
Nortel Networks
4401 Great America Pkwy, Santa Clara, CA 95054
Phone: 408-565-2571
Email: tsenevir@nortelnetworks.com
Paul Billinghurst
Nortel Networks
4401 Great America Pkwy, Santa Clara, CA 95054
Phone: 408-565-2357
Email: pbilling@nortelnetworks.com
Hamid Ould-Brahim
Nortel Networks
PO Box 3511 Station C, Ottawa, ON KIY 4H7
Phone: 613-765-3418
Email: hbrahim@nortelnetworks.com
Bryan Gleeson
Nortel Networks
2305 Mission College Blvd, Santa Clara, CA 95054
Phone: 408-565-2625
Email: bgleeson@nortelnetworks.com
Senevirathne Informational - April 2001 14
draft-tsenevir-8021qbgp-00.txt November 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Senevirathne Informational - April 2001 15