One document matched: draft-renwei-mpls-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-big-label-00.txt"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="Encoding of Big Labels">
    Encoding of Big Labels in MPLS Label Stacks</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="Ming Li" initials="M."  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>mli@huawei.com</email>
		</address>
	</author>

<date year="2013"/>
    
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>

<abstract>
<t>
   This document specifies encoding and encapsulation methods for MPLS big
   labels. Big labels are required for accessing virtual networks in data
   centers by using, for example, BGP/MPLS IP VPNs. Data center virtualization
   encapsulation methods and protocols such as VXLAN, NVGRE and NVO3 are
   being standardized to support a few millions of virtual networks, but the
   currently label format can support up to one million of labels. When the
   BGP/MPLS IP VPN method, for example, is used by an enterprise/customer to
   access its corresponding virtual networks, more than one million of labels
   are required to map VPN labels and Virtual Network Identifiers.
</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 has placed a new requirement on the access
method to such huge number of virtulized networks.
</t>

<t>
BGP/MPLS IP VPNs, as specified in RFC 2547 and RFC 4364, 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 the 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]
specifies use cases and solutions to use big labels to represent the VPN and
maps them to virtual network instances.
</t>

<t>
This document specifies the label format and encoding methods of big labels in
the MPLS label stack of [RFC 3032].
</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 RFC 2119 [RFC2119].
</t>

</section>

<section title="Terminology">

<t>The following terms are used in this document:

        <list hangIndent="6" style="hanging">
         <t hangText="VXLAN"><vspace blankLines="0"/>
             Virtual eXtensible Local Area Network </t>
          <t hangText="NVGRE"><vspace blankLines="0"/>
             Network Virtualization using GRE </t>
          <t hangText="NVO3"><vspace blankLines="0"/>
             Network Virtualization Overlay over Layer 3  </t>
          <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>

        </list>
</t>


</section>

</section>



<section title = "Motivations">

<t>
In [I-D.draft-renwei-l3vpn-big-label], several use cases are described so that
an enterprise/customer can use provider-provided BGP/MPLS IP VPN to access its corresponding virtual
network hosted in a data center.
</t>

<t>
The virtual network may be provided by VXLAN,
NVGRE or NVO3. In all such network virtualization frameworks, 16 millions of
virtual networks may be supported. This implies that up to 16 millions of
enterprises/customers can have their own data centers hosted by data center
service providers.
On the other hand, BGP/MPLS IP VPNs have been used widely by the service providers.
This imposes a new requirement of using BGP/MPLS IP VPN protocols and solutions
to access the virtual networks in data centers. One problem and obstacle of
using BGP/MPLS IP VPN to access virtual networks is that there are not enough
labels to do one-one mapping between VPN label space and virtual network
identification space.
</t>
</section>

<section title = "Review of MPLS Label Stack">

<t>
The label stack is represented as a sequence of "label stack
   entries".  Each label stack entry is represented by 4 octets 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                    Label:  Label Value, 20 bits
                    Exp:    Experimental Use or for QoS, 3 bits.
                    S:      Bottom of Stack, 1 bit
                    TTL:    Time to Live, 8 bits
</artwork>
</figure>
</t>

<t>
For BGP/MPLS IP VPN, the VPN labels share the same format as all other common
MPLS labels as defined as in the above figure.
 </t>
 
 
</section>

 <section title = "Big Labels">

<t>
A PE device  uses VPN labels to find the associated VRFs for VPN packet
forwarding. Since there are potentially 16 millions of virtual networks,
20 bits label are not sufficient; we need to specify a new type of labels:
big labels. A big label is an extension to the MPLS label format of RFC 3032
so that the label space is bigger than the 20-bit space with the minimal
space being 16 millions of labels.
</t>

<t>
There are several options to define big labels.  One option is to totally
re-define the label format; A second option is to extend the length of
label entry; A third option is, for the sake of backward compatibility,
to add a new field to the common label entry specified in RFC 3032.
</t>

<t>
The exact format of the third option is defined 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                                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Exp:    Experimental Use or for QoS, 3 bits
                    S:      Bottom of Stack, 1 bit
                    TTL:    Time to Live, 8 bits


</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> All the EXP, S and TTL are also applicable to the Big Label Value as
follows:
</t>
<t>
<list>
<t>
EXP:   Experimental Use or for QoS, 3 bits
</t>
<t>
S:     Bottom of Stack, 1 bit
</t>
<t>
TTL:   Time to Live, 8 bits
</t>

</list>
</t>

</section>


<section anchor="IANA" title="IANA Considerations">
<t>
This draft will request IANA to assign a reserved label for Big Label Indicator.
</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.3107" ?>
   <?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>