One document matched: draft-francis-va-tunnels-mpls-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="bcp" ipr="trust200811" docName="draft-francis-va-tunnels-mpls-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 Tunnels">MPLS Tunnels for Virtual Aggregation</title>
	    <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>
	        <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>
 
	
	<!-- zzzz set date zzzz -->
	<date day="11" month="February" year="2009"/>

        <abstract>
		<t> 
The document "FIB Suppression with Virtual Aggregation" 
<xref target="I-D.francis-intra-va"></xref>
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 tag stacking.
</t>
        </abstract>

    </front>

    <middle>

        <section title="Introduction">
<t>
This document specifies how to use and signal the tunnels
required by
<xref target="I-D.francis-intra-va"></xref>,
"FIB Suppression with Virtual Aggregation", for MPLS.
This document is limited to MPLS without tag stacking.
This document adopts the terminology of
<xref target="I-D.francis-intra-va"></xref>.
This document covers the behavior for both VA routers and
legacy routers.
</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>


<section anchor="sec-req" title="Tunneling Requirements">
<t>
According to <xref target="I-D.francis-intra-va"></xref>,
VA has the following tunnel-related requirements.  The requirement
numbers here (R1 - R5) are cited by <xref target="I-D.francis-intra-va"></xref>.
<t><list style="hanging">
<t hangText="R1:  ">
Legacy routers and APRs must be able to detunnel packets addressed to
themselves at their BGP NEXT_HOP address.
They must be able to signal the tunnel
information needed by other routers to initiate these tunneled packets.
</t>
<t hangText="R2:  ">
Border VA routers must be able to detunnel packets targeted to neighboring
remote ASBRs.  They must be able to forward these packets to the targeted
remote ASBR without doing a FIB lookup.
They must be able to signal the tunnel
information needed by other routers to initiate these tunneled packets.
</t>
<t hangText="R3:  ">
VA routers must be able to initiate tunneled packets targeted
to any BGP NEXT_HOP address
(i.e. those for APRs, legacy routers, or remote ASBRs).
</t>
<t hangText="R4:  ">
Legacy routers may optionally be able to initiate tunneled packets targeted
to any BGP NEXT_HOP address
(i.e. those for APRs, legacy routers, or remote ASBRs).
The MPLS tunnels defined in this document allow this capability.
</t>
<t hangText="R5:  ">
All routers must be able to forward all tunneled packets.
</t>
</list></t>
</t>
</section> <!-- "sec-req" -->

<section anchor="sec-spec" title="Tunneling Specification for MPLS">
<t>
VA utilizes a straight-forward application of MPLS.  The tunnels
are MPLS Label Switched Paths (LSP), and are signaled using either the
Label Distribution Protocol (LDP) <xref target="RFC5036"></xref>.
(Note that usage of RSVP-TE <xref target="RFC3209"></xref> to signal these
tunnels, in particular the scalability of configuring so many tunnels,
is for further study.)
All routers (VA and legacy alike) must run LDP, as required
by R5.
A legacy router that cannot run LDP and initiate LSPs terminating at
itself cannot participate in a VA domain.
</t>
<t>
Requirements R1 and R2 require that routers initiate tunnels.  
This is done by importing the full BGP NEXT_HOP address
(/32 if IPv4, /128 if IPv6) into the IGP 
(i.e. OSPF <xref target="RFC2328"></xref>), and
initiating Downstream Unsolicited tunnels to all IGP neighbors
with the full BGP NEXT_HOP address as the Forwarding Equivalence Class (FEC).
</t>
<t>
Note that in the case of requirement R2, the BGP NEXT_HOP address is
that of the remote ASBR, not that of the router that is initiating
the LSP (i.e. the local ASBR VA router).  
Strictly speaking, this is non-standard behavior---normally it is the
router owning the FEC address that initiates signaling.
Nevertheless routers can employ existing Penultimate
Hop Popping (PHP) mechanisms in the data plane for forwarding packets
to remote ASBRs.
</t>
<t>
Requirements R3 and R4 should naturally be satisfied through normal
MPLS usage.  In other words, the LSP to the BGP NEXT_HOP address
should automatically be the preferred method to routing the packet
towards the BGP NEXT_HOP address.
</t>
</section> <!-- "sec-spec" -->


<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 (near) standard application of
intra-domain MPLS,
there are no new security considerations beyond those already described
in <xref target="I-D.francis-intra-va"></xref>.
</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='RFC2328'>

<front>
<title>OSPF Version 2</title>
<author initials='J.' surname='Moy' fullname='John Moy'>
<organization>Ascend Communications, Inc.</organization>
<address>
<postal>
<street>1 Robbins Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code></postal>
<phone>978-952-1367</phone>
<facsimile>978-392-2075</facsimile>
<email>jmoy@casc.com</email></address></author>
<date year='1998' month='April' />
<area>Routing</area>
<keyword>open shortest-path first protocol</keyword>
<keyword>routing</keyword>
<keyword>OSPF</keyword>
<abstract>
<t>

    This memo documents	version	2 of the OSPF protocol.	 OSPF is a
    link-state routing protocol.  It is	designed to be run internal to a
    single Autonomous System.  Each OSPF router	maintains an identical
    database describing	the Autonomous System's	topology.  From	this
    database, a	routing	table is calculated by constructing a shortest-
    path tree.
</t>
<t>
    OSPF recalculates routes quickly in	the face of topological	changes,
    utilizing a	minimum	of routing protocol traffic.  OSPF provides
    support for	equal-cost multipath.  An area routing capability is
    provided, enabling an additional level of routing protection and a
    reduction in routing protocol traffic.  In addition, all OSPF
    routing protocol exchanges are authenticated.
</t>
<t>
    The	differences between this memo and RFC 2178 are explained in
    Appendix G.	All differences	are backward-compatible	in nature.
    Implementations of this memo and of	RFCs 2178, 1583, and 1247 will
    interoperate.
</t>
<t>
    Please send	comments to ospf@gated.cornell.edu.
</t></abstract></front>

<seriesInfo name='STD' value='54' />
<seriesInfo name='RFC' value='2328' />
<format type='TXT' octets='447367' target='ftp://ftp.isi.edu/in-notes/rfc2328.txt' />
<format type='XML' octets='446761' target='http://xml.resource.org/public/rfc/xml/rfc2328.xml' />
</reference>

  
		      
<reference anchor='RFC3209'>

<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author initials='D.' surname='Awduche' fullname='D. Awduche'>
<organization /></author>
<author initials='L.' surname='Berger' fullname='L. Berger'>
<organization /></author>
<author initials='D.' surname='Gan' fullname='D. Gan'>
<organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'>
<organization /></author>
<author initials='V.' surname='Srinivasan' fullname='V. Srinivasan'>
<organization /></author>
<author initials='G.' surname='Swallow' fullname='G. Swallow'>
<organization /></author>
<date year='2001' month='December' />
<abstract>
<t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='3209' />
<format type='TXT' octets='132264' target='ftp://ftp.isi.edu/in-notes/rfc3209.txt' />
</reference>


<reference anchor='RFC5036'>

<front>
<title>LDP Specification</title>
<author initials='L.' surname='Andersson' fullname='L. Andersson'>
<organization /></author>
<author initials='I.' surname='Minei' fullname='I. Minei'>
<organization /></author>
<author initials='B.' surname='Thomas' fullname='B. Thomas'>
<organization /></author>
<date year='2007' month='October' />
<abstract>
<t>The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031.  A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them.  This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made.  This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5036' />
<format type='TXT' octets='287101' target='ftp://ftp.isi.edu/in-notes/rfc5036.txt' />
</reference>



<reference anchor='I-D.francis-intra-va'>
<front>
<title>FIB Suppression with Virtual Aggregation</title>

<author initials='P' surname='Francis' fullname='Paul Francis'>
    <organization />
</author>

<author initials='X' surname='Xu' fullname='Xiaohu Xu'>
    <organization />
</author>

<author initials='H' surname='Ballani' fullname='Hitesh Ballani'>
    <organization />
</author>

<date month='February' day='11' year='2009' />

<abstract><t> 
The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways.  One of the most costly stresses is FIB size:  ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB.  FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB.  Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load.  FIB suppression deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP.
</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-francis-intra-va-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-francis-intra-va-00.txt' />
</reference>


  </references>
	    

    </back>

</rfc>