Carrying Big Labels in BGP-4Huawei Technologies2330 Central ExpresswaySanta ClaraCA95050USArenwei.li@huawei.comHuawei Technologies2330 Central ExpresswaySanta ClaraCA95050USAlin.han@huawei.com
Routing
MPLS Working Group
When BGP is used to distribute a particular
route, it can also be used to distribute an MPLS label which is mapped
to that route. In some cases, for example, when L3VPN is used to access
and connect to virtual networks in data centers, there may be 16 millions of VPN instances
on a router. In order to map MPLS labels to VPN instances, big labels are
required. This document specifies the method to carry and distribute
such big labels by piggybacking the big label mapping information for an
IP route in the BGP Update message that is used
to distribute the route itself.
Network virtualization and server virtualization are being designed
and deployed in data center networks, and new data encapsulation methods and
protocols are being defined and specified, for example, VXLAN, NVGRE and
NVO3. The general idea is to add a new virtual network header so that a physical
network can be used to support millions (16M) of virtualized overlaid networks.
Network overlay virtualization have placed a new requirement on the access
method to such virtulized networks.
BGP/MPLS IP VPNs of and , provide a market-proven
technology and solution for end-to-end IP VPNs. In BGP/MPLS IP VPNs, all the
customer sites are connected to the service provider networks through PE-CE
link. It is desirable to extend the BGP/MPLS scheme so that customers can access
their virtualized networks hosted in a data center by using BGP/MPLS IP VPNs.
In the data plane of BGP/MPLS IP VPNs, the customer VPN/VRF instances are
represented by an MPLS label (VPN label) locally assgined by the PE connecting
to CE. Since MPLS labels are 20 bits long, a PE can maximally support 1 million
VPNs/VRFs, but PE is required to support 16 millions of virtual networks that are
being standardized in VXLAN, NVGRE and NVO3. When BGP/MPLS IP VPNs are extended
to access virtualized networks in data centers, [I-D.draft-renwei-l3vpn-big-label]
describes several use cases and solutions to use big labels to represent the VPN and
maps them to virtual network instances.
The big label information mapped to VPN routes can be carried and distributed
by BGP-4 in the framework of .
This document specifies the method to carry and distribute
such big labels by piggybacking the big label mapping information for an
IP route in the BGP Update message that is used
to distribute the route itself.
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 .
The following terms are used in this document:
Provider Edge, the provider edge router connected to CE.
Customer Edge, the customer edge router connected to PE
MPLS label switch router
Internet Assigned Numbers Authority
Address Family Identifier
Subsequent Address Family Identifier
This document tries to make L3 VPN BGP signaling work with the MPLS big label specified
in [I-D.draft-renwei-mpls-big-label]. With the proposed method, the MPLS big label can be
carried in BGP NLRI and mapped to BGP routes.
The extension of BGP is used to connect a customer site to its virtualized
network hosted in a data center by using, for example, VXLAN, NVGRE or NVO3.
Take NVO3 as an example. NVO3 is an on-going effort to standardize solutions to data center virtualizaiton
with the goal of providing viable data encapsulation and protocols across a scaling
range of a few thousand VMs to several million VMs running on greater than
one hundred thousand physical servers. NVO3 considers approaches to
multi-tenancy that reside at the network layer rather than using traditional
isolation mechanisms that rely on the underlying layer 2 technology (e.g. VLANs).
Based on NVO3 framework and problem statement, NVO3 will deliver 16 million
virtual networks in a physical data center.
Potentially, PE-NVE needs to support 16 million of VRFs. The extension of BGP
described in this document can be used between PE-NVE and PE for the purpose of association
between L3VPN labels and network virtualizaiton instances in the NVO3 network.
A PE device uses VPN labels to find the associated VRFs for VPN packet
forwarding. When L3VPN is used to access and connect a virtual network
hosted in a data center by using VXLAN, NVGRE or NVO3, a label space having
a minimal set of 16 million labels is required.
The document [I-D.draft-renwei-mpls-big-label] specifies an encoding
format by adding a new label value field to the common label as follows:
The Big Label Indicator is a reserved MPLS label. The currently unassigned
reserved label
range is 4-6 and 8-12. We will temporarily use label 8 for big label indicator,
but the final value will be assigned by IANA. The Big Label Value is a 32-bit
value.
When an MPLS LSR receivs an MPLS packet, it reads out the MPLS label. If the
MPLS label is a Big Label Indicator, it will use the subsequent 32-bit value
as the MPLS label for the forwarding purpose.
In what follows, we will describe how BGP-4 carries and distributes such
big labels for IP routes.
In BGP-4, label mapping information is carried as part of the Network Layer
Reachability Information (NLRI) in the Multiprotocol Extensions of BGP-4 .
The AFI indicates, as usual, the address family of the associated route. The
fact that the NLRI carries an MPLS big label is indicated by using a SAFI
value, to be requested to IANA. The SAFI value 4 is currently assigned for
common labels. The currently unassigned range is 8-63. Before IANA assigns an official SAFI value for big labels,
8 is temporarily used as the SAFI value to indicate that it carries big labels.
The Network Layer Reachability Information carrying big labels is encoded as
one or more triples of the form (length, label, prefix), whose fields are
described as follows:
Length: The Length field indicates the length in bits of the address
prefix plus the label.
Label:
The Label field carries a 4-octet Big Label Value of the big label
format specified in [I-D.draft-renwei-mpls-big-label]. Note that
the Big Label Indicator is not carried in NLRI; instead, it will
be assigned by IANA. In the data plane, when encoding a packet
for forwarding, both the Big Label Indicator and Big Label Value
must be encoded in the MPLS header as specified in
[I-D.draft-renwei-mpls-big-label].
Prefix:
The Prefix field contains address prefixes followed by enough
trailing bits to make the end of the field fall on an octet
boundary. Note that the value of trailing bits is irrelevant.
All rules and restrictions applicable to the SAFI value 4 is also applicable
to the SAFI value 8 (subject to IANA) except for the Label field must be
4 octets. In particular, the following usage rules for SAFI value 4 also applies
to the SAFI value for big labels:
The label(s) specified for a particular route (and associated with
its address prefix) must be assigned by the LSR which is identified
by the value of the Next Hop attribute of the route.
When a BGP speaker redistributes a route, the label(s) assigned to
that route must not be changed (except by omission), unless the
speaker changes the value of the Next Hop attribute of the route.
A BGP speaker can withdraw a previously advertised route (as well as
the binding between this route and a label) by either (a) advertising
a new route (and a label) with the same NLRI as the previously
advertised route, or (b) listing the NLRI of the previously
advertised route in the Withdrawn Routes field of an Update message.
The label information carried (as part of NLRI) in the Withdrawn
Routes field should be set to 0x800000. (Of course, terminating the
BGP session also withdraws all the previously advertised routes.)
A BGP speaker that uses MP-BGP to carry label
mapping information should use the Capabilities Optional Parameter,
as defined in , to inform its peers about this capability.
The MP_EXT Capability Code, as defined in , is used to
advertise the (AFI, SAFI) pairs available on a particular connection.
A BGP speaker should not advertise this capability to another BGP
speaker unless there is a Label Switched Path (LSP) between the two
speakers.
The requirements on IANA are specified in other related documents
[I-D.draft-renwei-mpls-big-label] and [I-D.draft-renwei-mpls-bgp-big-label],
which request a reserved label to represent Big Label Indicator and BGP
capabilities for big labels.
This draft does not add any additional security implications to the BGP/MPLS
IP VPNs. All existing authentication and security mechanisms for BGP and MPLS
still apply.