One document matched: draft-ietf-grow-va-mpls-innerlabel-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<!-- zzzz next line -->
<rfc category="info" ipr="trust200811" docName="draft-ietf-grow-va-mpls-innerlabel-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="VA MPLS Label">Proposal to use an inner MPLS label to identify the remote ASBR VA</title>
<author initials ='X' surname ='Xu' fullname='Xiaohu Xu'>
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>
No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
</street>
<city>Beijing</city>
<region>Beijing</region>
<code>100085</code>
<country>P.R.China</country>
</postal>
<phone>+86 10 82836073</phone>
<email>xuxh@huawei.com</email>
</address>
</author>
<author initials ='P' surname ='Francis' fullname='Paul Francis'>
<organization abbrev="MPI-SWS">Max Planck Institute for Software Systems</organization>
<address>
<postal>
<street>Gottlieb-Daimler-Strasse</street>
<city>Kaiserslautern</city>
<!-- <region>NY</region> -->
<code>67633</code>
<country>Germany</country>
</postal>
<!-- <phone>+1 607 255 9223</phone> -->
<email>francis@mpi-sws.org</email>
</address>
</author>
<!-- zzzz set date zzzz -->
<date day="23" month="September" year="2009"/>
<abstract>
<t>
The draft "MPLS Tunnels for Virtual Aggregation"
<xref target="I-D.ietf-grow-va-mpls"></xref>
specifies how MPLS is used as the tunneling protocol for
Virtual Aggregation (VA).
The -00 version of that draft specifies only one level of
labels, with the result that one Label Switched Path
(LSP) for every remote ASBR must be established.
For large ISPs, this can amount to a large number of LSPs.
This draft proposes adding the option of using an inner label to
identify the remote ASBR.
Either an outer label or an IP tunnel is used to reach
the local ASBR.
When MPLS is used as the tunneling protocol, this reduces the number
of LSPs to the number of local border routers (ASBR).
</t>
</abstract>
</front>
<middle>
<section title="Proposal">
<t>
The draft "MPLS Tunnels for Virtual Aggregation"
<xref target="I-D.ietf-grow-va-mpls"></xref>
specified how MPLS is used as the tunneling protocol for
Virtual Aggregation (VA).
The -00 version of that draft specifies only one level of
labels, with the result that one LSP for
every remote ASBR must be established.
For large ISPs, this can amount to a large number of LSPs
(roughly 20,000 for one large ISP we studied).
This draft proposes the optional use of an inner label to reduce the number
of LSPs to the number of local ASBRs.
Besides improving the efficiency of VA, this also makes it feasible
to use MPLS TE (traffic engineered) LSPs.
</t>
<t>
VA requires that tunneled packets are "targeted" to remote ASBRs.
However, the tunnel header must be stripped before the packet
is transmitted to the remote ASBR.
This means that the tunnel header must identify the remote ASBR to
the local ASBR, so that the local ASBR may strip the header and forward
the packet to the remote ASBR.
In the -00 draft of
<xref target="I-D.ietf-grow-va-mpls"></xref>, there is one LSP
per remote ASBR. In other words, there is a distinct label per
remote ASBR.
</t>
<t>
This draft proposes adding the option of using an inner label to
identify the remote ASBR.
Either an outer label or an IP tunnel identifies
the local ASBR.
When the local ASBR receives the packet, it strips off the outer label/header,
uses the value of the inner label to identify the remote ASBR,
and then strips the inner label
before forwarding the packet to the remote ASBR.
Note that, in the case of stacked labels, the outer label may have been
stripped by the previous hop using penultimate hop popping (PHP).
</t>
<t>
This style of tunneling is essentially identical to that used for
MPLS VPNs
<xref target="RFC4364"></xref>, though simpler because there is
no need for virtual forwarding tables.
</t>
<t>
There are three forms of tunneling that can be used, stacked labels
(<xref target="RFC3032"></xref>),
and MPLS-in-IP or MPLS-in-GRE
(<xref target="RFC4023"></xref>),
as follows:
</t>
<figure> <artwork><![CDATA[
Stacked labels (RFC3032):
Payload | IP | Inner label | Outer label | link | ==>
MPLS-in-IP (RFC4023):
Payload | IP | Inner label | Outer IP header | link | ==>
MPLS-in-GRE (RFC4023):
Payload | IP | Inner label | GRE | Outer IP header | link | ==>
]]></artwork> </figure>
<t>
When a local ASBR advertises a route into iBGP, it sets the Next Hop
to itself, and assigns a label to the route.
This label is used as the inner label, and
identifies the remote ASBR from which the route was received
<xref target="RFC3107"></xref>.
</t>
<t>
The presence of the inner label in the iBGP update acts as the signal
to the receiving router that an inner label should be used in
packets tunneled to the Next Hop address.
Other information is used to determine whether the tunnel itself
is MPLS, IP, or GRE.
Specifically,
<xref target="I-D.ietf-grow-va-gre"></xref>.
specifies how to convey the use of IP or GRE
tunneling in BGP for VA (i.e. though the attributes from
<xref target="RFC5512"></xref>).
If these attributes indicate IP or GRE tunneling, then the
corresponding IP or GRE tunnel should be used.
If no 5512 attribute is present, but there is a LSP to the
Next Hop address, then the LSP should be used.
If no 5512 attribute is present, and there is no LSP to the
Next Hop address, then the packet should be IP tunneled to
the Next Hop address.
</t>
<t>
The following table summarizes the tunneling behavior (and for
completeness includes the both the cases where the inner label is
and is not signaled).
</t>
<figure> <artwork><![CDATA[
Inner | 5512 | LSP to | Tunnel
label? | attr? | Next Hop? | Behavior
---------------------------------------------------------
No | No | No | Don't tunnel packet
| | | (normal behavior without VA)
No | No | Yes | Use LSP
No | Yes | No | Use 5512 tunnel to next hop
No | Yes | Yes | Use 5512 tunnel to Next Hop
| | | if possible, else use LSP *
Yes | No | No | Use IP tunnel to Next Hop
| | | with inner label
Yes | No | Yes | Use LSP (stacked labels)
Yes | Yes | No | Use 5512 tunnel to Next Hop
| | | with inner label
Yes | Yes | Yes | Use 5512 tunnel to Next Hop
| | | with inner label if possible,
| | | else use LSP *
* If the receiving router does not have the appropriate 5512
tunneling capability (IP or GRE), and it does have LSP
capability, then it should use the LSP.
]]></artwork> </figure>
<t>
It is important to note that conveying inner label or
tunneling information in BGP is not a negotiation per se: there is
no assurance that the recipient of the information can actually
do the type of tunneling indicated.
It is therefore necessary for the AS administrator to insure that
routers are capable of acting on any labeling or tunneling information
that they receives.
</t>
<section title="Requirements notation">
<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 anchor="changes" title="Changes from Previous Versions">
<t>
This is the first version of this draft.
</t>
</section> <!-- "changes" -->
</section>
<section anchor="sec-iana" title="IANA Considerations">
<t>
There are no IANA considerations.
</t>
</section>
<section anchor="sec-consider" title="Security Considerations">
<t>
Because this document describes a standard application of MPLS,
there are no new security considerations beyond those already described
in <xref target="I-D.ietf-grow-va-mpls"></xref>.
It is worth noting, however, that the some of the
security considerations normally associated with VPNs, namely that
it not be possible for a non-VPN source to inject a packet into a VPN,
do not apply here. Virtual Aggregation applies to global routing,
not to VPN, and therefore it is not necessary to isolate communities.
</t>
</section>
<!--
<section anchor="sec-ack" title="Acknowledgements">
<t>
The authors would like to acknowledge the efforts of Xinyang Zhang
and Jia Wang, who worked on CRIO (Core Router Integrated Overlay), an
early inter-domain variant of FIB suppression, and the efforts of Hitesh Ballani
and Tuan Cao, who worked on the configuration-only variant of VA
that works with legacy routers.
We would also like to thank Hitesh and Tuan, as well as Scott Brim,
Daniel Ginsburg, Robert Raszuk, and Rajiv Asati for their helpful comments.
In particular, Daniel's comments significantly simplified the spec
(eliminating the need for a new External Communities Attribute), and
Robert suggested Edge Suppression.
</t>
</section> <!-- "sec-ack" -->
-->
</middle>
<back>
<references title='Normative References'>&rfc2119;
<reference anchor='RFC3032'>
<front>
<title>MPLS Label Stack Encoding</title>
<author initials='E.' surname='Rosen' fullname='E. Rosen'>
<organization /></author>
<author initials='D.' surname='Tappan' fullname='D. Tappan'>
<organization /></author>
<author initials='G.' surname='Fedorkow' fullname='G. Fedorkow'>
<organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<author initials='D.' surname='Farinacci' fullname='D. Farinacci'>
<organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'>
<organization /></author>
<author initials='A.' surname='Conta' fullname='A. Conta'>
<organization /></author>
<date year='2001' month='January' />
<abstract>
<t>This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3032' />
<format type='TXT' octets='48314' target='ftp://ftp.isi.edu/in-notes/rfc3032.txt' />
</reference>
<reference anchor='RFC3107'>
<front>
<title>Carrying Label Information in BGP-4</title>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<author initials='E.' surname='Rosen' fullname='E. Rosen'>
<organization /></author>
<date year='2001' month='May' />
<abstract>
<t>This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3107' />
<format type='TXT' octets='16442' target='ftp://ftp.isi.edu/in-notes/rfc3107.txt' />
</reference>
<reference anchor='RFC4023'>
<front>
<title>Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)</title>
<author initials='T.' surname='Worster' fullname='T. Worster'>
<organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<author initials='E.' surname='Rosen' fullname='E. Rosen'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4023' />
<format type='TXT' octets='31696' target='ftp://ftp.isi.edu/in-notes/rfc4023.txt' />
</reference>
<reference anchor='RFC4364'>
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author initials='E.' surname='Rosen' fullname='E. Rosen'>
<organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<date year='2006' month='February' />
<abstract>
<t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4364' />
<format type='TXT' octets='116446' target='ftp://ftp.isi.edu/in-notes/rfc4364.txt' />
</reference>
<reference anchor='RFC5512'>
<front>
<title>BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute</title>
<author initials='P' surname='Mohapatra' fullname='Pradosh Mohapatra'>
<organization />
</author>
<author initials='E' surname='Rosen' fullname='Eric Rosen'>
<organization />
</author>
<date month='April' day=' ' year='2009' />
<abstract><t>
In certain situations, transporting a packet from one Border Gateway
Protocol (BGP) speaker to another (the BGP next hop) requires that
the packet be encapsulated by the first BGP speaker and decapsulated
by the second. To support these situations, there needs to be some
agreement between the two BGP speakers with regard to the
"encapsulation information", i.e., the format of the encapsulation
header as well as the contents of various fields of the header.
The encapsulation information need not be signaled for all
encapsulation types. In cases where signaling is required (such as
Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing
Encapsulation (GRE) with key), this document specifies a method by
which BGP speakers can signal encapsulation information to each
other. The signaling is done by sending BGP updates using the
Encapsulation Subsequent Address Family Identifier (SAFI) and the
IPv4 or IPv6 Address Family Identifier (AFI). In cases where no
encapsulation information needs to be signaled (such as GRE without
key), this document specifies a BGP extended community that can be
attached to BGP UPDATE messages that carry payload prefixes in order
to indicate the encapsulation protocol type to be used.
</t></abstract>
</front>
<seriesInfo name='RFC' value='5512' />
<format type='TXT'
target='http://www.ietf.org/rfc/rfc5512.txt' />
</reference>
<reference anchor='I-D.ietf-grow-va-mpls'>
<front>
<title>MPLS Tunnels for Virtual Aggregation</title>
<author initials='P' surname='Francis' fullname='Paul Francis'>
<organization />
</author>
<author initials='X' surname='Xu' fullname='Xiaohu Xu'>
<organization />
</author>
<date month='May' day='23' year='2009' />
<abstract><t>The document "FIB Suppression with Virtual Aggregation" [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for MPLS Label Switched Paths (LSP), without label stacking.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-grow-va-mpls-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-grow-va-mpls-00.txt' />
</reference>
<reference anchor='I-D.ietf-grow-va-gre'>
<front>
<title>GRE and IP-in-IP Tunnels for Virtual Aggregation</title>
<author initials='P' surname='Francis' fullname='Paul Francis'>
<organization />
</author>
<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
<organization />
</author>
<author initials='X' surname='Xu' fullname='Xiaohu Xu'>
<organization />
</author>
<date month='July' day='6' year='2009' />
<abstract><t>The document "FIB Suppression with Virtual Aggregation" [I-D.grow-va] describes how FIB size may be reduced. That draft refers generically to tunnels, and leaves it to other documents to define the tunnel establishment methods for specific tunnel types. This document provides those definitions for GRE and IP-in-IP tunnels.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-grow-va-gre-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-grow-va-gre-00.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:02:56 |