One document matched: draft-renwei-mpls-bgp-big-label-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
docName="draft-renwei-mpls-bgp-big-label-00.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="Carrying Big Labels in BGP-4">
Carrying Big Labels in BGP-4</title>
<author fullname="Renwei Li" initials="R." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<email>renwei.li@huawei.com</email>
</address>
</author>
<author fullname="Lin Han" initials="L." surname="Han">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<email>lin.han@huawei.com</email>
</address>
</author>
<date year="2013"/>
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
BGP/MPLS IP VPNs of <xref target="RFC2547"/> and <xref target="RFC4364"/>, 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.
</t>
<t>
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.
</t>
<t>
The big label information mapped to VPN routes can be carried and distributed
by BGP-4 in the framework of <xref target="RFC3107"/>.
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.
</t>
<section title="Requirement Language">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>The following terms are used in this document:
<list hangIndent="6" style="hanging">
<t hangText="PE"><vspace blankLines="0"/>
Provider Edge, the provider edge router connected to CE.</t>
<t hangText="CE"><vspace blankLines="0"/>
Customer Edge, the customer edge router connected to PE </t>
<t hangText="MPLS LSR"><vspace blankLines="0"/>
MPLS label switch router </t>
<t hangText="IANA"><vspace blankLines="0"/>
Internet Assigned Numbers Authority </t>
<t hangText="AFI"><vspace blankLines="0"/>
Address Family Identifier </t>
<t hangText="SAFI"><vspace blankLines="0"/>
Subsequent Address Family Identifier </t>
</list>
</t>
</section>
</section>
<section title = "Motivation">
<t>
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.
</t>
<t> 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.
</t>
<t>
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).
</t>
<t> Based on NVO3 framework and problem statement, NVO3 will deliver 16 million
virtual networks in a physical data center.
</t>
<t>
<figure>
<artwork>
..................................
. .
. +------------+ .
. |+----+ +---+| .
. || | |VM || .
. /+|NVE | +---+| .
. / || | +---+| .
-----+ +----------------+ . +------------+ || | |VM || .
| | | . | | |+----+ +---+| .
+---+--+ +------+ +---+---+--+ NVO3 | | Server | .
| CE |---| PE | MPLS | PE-NVE | network | +------------+ .
|device| |device| network | device | over L3 | .
+---+--+ +------+ +---+---+--+ network | +------------+ .
| / | | . | | |+----+ +---+| .
-----+ / +----------------+ . +------------+ || | |VM || .
/ . \ ||NVE | +---+| .
-----+ / . \+| | +---+| .
| / . || | |VM || .
+---+--+ . |+----+ +---+| .
| CE | . | Server | .
|device| . Data Center +------------+ .
+---+--+ ..................................
|
-----+
</artwork>
</figure>
</t>
<t>
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.
</t>
</section>
<section title = "Big Labels">
<t>
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.
</t>
<t>
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:
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Big Label Indicator | Exp |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Big Label Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
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.
</t>
<t>
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.
</t>
<t>
In what follows, we will describe how BGP-4 carries and distributes such
big labels for IP routes.
</t>
</section>
<section title = "AFI/SAFI">
<t>
In BGP-4, label mapping information is carried as part of the Network Layer
Reachability Information (NLRI) in the Multiprotocol Extensions of BGP-4 <xref target="RFC2858"/>.
</t>
<t>
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.
</t>
</section>
<section title = "Big Label in NLRI">
<t>
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:
</t>
<figure>
<artwork>
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Label (4 octets) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
</artwork>
</figure>
<t>
<list style = "letters">
<t>
Length: The Length field indicates the length in bits of the address
prefix plus the label.
</t>
<t>
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].
</t>
<t>
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.
</t>
</list>
</t>
<t>
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:
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.)
</t>
</section>
<section title = "Capability Anouncement">
<t>
A BGP speaker that uses MP-BGP <xref target="RFC2858"/> to carry label
mapping information should use the Capabilities Optional Parameter,
as defined in <xref target="RFC2842"/>, to inform its peers about this capability.
The MP_EXT Capability Code, as defined in <xref target="RFC2858"/>, is used to
advertise the (AFI, SAFI) pairs available on a particular connection.
</t>
<t>
A BGP speaker should not advertise this capability to another BGP
speaker unless there is a Label Switched Path (LSP) between the two
speakers.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t> 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.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2547" ?>
<?rfc include="reference.RFC.4364" ?>
<?rfc include="reference.RFC.3107" ?>
<?rfc include="reference.RFC.1771" ?>
<?rfc include="reference.RFC.2842" ?>
<?rfc include="reference.RFC.2858" ?>
<?rfc include="reference.RFC.3031" ?>
<?rfc include="reference.RFC.3032" ?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3
/reference.I-D.draft-mahalingam-dutt-dcops-vxlan-03.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3
/reference.I-D.draft-sridharan-virtualization-nvgre-02.xml" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:52:46 |