One document matched: draft-ietf-grow-simple-va-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-simple-va-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="S-VA">Simple Virtual Aggregation (S-VA)</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>+49 631 930 39600</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>
<author initials ='H' surname ='Ballani' fullname='Hitesh Ballani'>
<organization abbrev="Cornell U.">Cornell University</organization>
<address>
<postal>
<street>4130 Upson Hall</street>
<city>Ithaca</city>
<region>NY</region>
<code>14853</code>
<country>US</country>
</postal>
<phone>+1 607 279 6780</phone>
<email>hitesh@cs.cornell.edu</email>
</address>
</author>
<author initials ='R' surname ='Raszuk' fullname='Robert Raszuk'>
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street> 170 West Tasman Drive</street>
<city> San Jose</city>
<region> CA </region>
<code> 95134 </code>
<country> USA </country>
</postal>
<phone> </phone>
<email>raszuk@cisco.com</email>
</address>
</author>
<author initials ='L' surname ='Zhang' fullname='Lixia Zhang'>
<organization abbrev="UCLA">UCLA</organization>
<address>
<postal>
<street> 3713 Boelter Hall </street>
<city>Los Angeles</city>
<region>CA</region>
<code> 90095 </code>
<country>US</country>
</postal>
<phone> </phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>
<!-- zzzz set date zzzz -->
<date day="1" month="March" year="2010"/>
<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.
Simple Virtual Aggregation (S-VA) is a simple form of Virtual
Aggregation (VA) that allows any and all edge routers to shrink their
FIB requirements substantially and therefore increase their useful lifetime.
S-VA does not change FIB requirements for core routers.
S-VA is extremely easy to configure---considerably more so than the
various tricks done today to extend the life of edge routers.
S-VA can be
deployed autonomously by an ISP (cooperation between ISPs is not required),
and can co-exist with legacy routers in the ISP.
</t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>
ISPs today manage constant DFRT growth in a number of ways.
One way, of course, is for ISPs to upgrade their
router hardware before DFRT growth
outstrips the size of the FIB.
This is too expensive for many ISPs. They would prefer to extend
the lifetime of routers whose FIBs can no longer hold the full DFRT.
</t>
<t>
A common approach taken by lower-tier ISPs is to default route to their
providers. Routes to customers and peer ISPs are maintained, but everything
else defaults to the provider. This approach has several disadvantages.
First, packets to Internet destinations may take longer-than-necessary
AS paths.
This problem can be mitigated through careful configuration of partial
defaults, but this can require substantial configuration overhead.
A second problem with defaulting to providers is that the ISP is no longer
able to provide the full DFRT to its customers.
Finally, provider defaults prevents the ISP from being able to detect
martian packets. As a result, the ISP transmits packets that could
otherwise have been dropped over its expensive provider links.
Simple Virtual Aggregation (S-VA)
solves these problems because the full DFRT is used by core routers.
</t>
<t>
An alternative is for the ISP to maintain full routes in its core
routers, but to filter routes from edge routers that do not require
a full DFRT.
These edge routers can then default route to the core routers.
This is often possible with edge routers that interface to
customer networks.
The problem with this approach is that it cannot be used for all
edge routers. For instance, it cannot be used for routers that
connect to transits.
It should also not be used for routers that connect to customers which
wish to receive the full DFRT.
</t>
<t>
This draft describes a very simple technique, called Simple
Virtual Aggregation (S-VA), that allows any and
all edge routers to have substantially reduced FIB requirements
even while still advertising and receiving the full DFRT over BGP.
The basic idea is as follows.
Core routers in the ISP maintain the full DFRT in the FIB and RIB.
Edge routers maintain the full DFRT in the RIB, but suppress certain
routes from the FIB.
Edge routers install a default route to core routers.
Label Switched Paths (LSP) are used to transmit packets from a
core router, through the edge router, to the Next Hop
remote Autonomous System Border Router (ASBR).
ASBRs strip the tunnel header (MPLS or IP) before
forwarding tunneled packets to the remote ASBR (in much
the same way MPLS Penultimate Hop Popping (PHP) strips the
LSP header before forwarding packets to the tunnel target).
</t>
<t>
S-VA requires no
changes to BGP and no changes to MPLS forwarding mechanisms in routers.
Configuration is extremely simple: S-VA must be enabled, and routers must
told whether they are FIB-suppressing routers or not.
Everything else is automatic.
ISPs can deploy FIB suppression autonomously and with no coordination with
neighbor ASes.
</t>
<section anchor="sec-scope" title="Scope of this Document">
<t>
The scope of this document is limited to Intra-domain S-VA operation.
In other words, the case where a single ISP autonomously operates S-VA
internally without any coordination with neighboring ISPs.
</t>
<t>
Note that this document assumes that the S-VA "domain"
(i.e. the unit of autonomy) is the AS (that is,
different ASes run S-VA independently and without coordination).
For the remainder of this document, the terms ISP, AS, and domain are
used interchangeably.
</t>
<t>
This document applies equally to IPv4 and IPv6.
</t>
<t>
S-VA may operate with a mix of upgraded routers and
legacy routers.
There are no topological restrictions placed on the mix of routers.
In order to avoid loops between upgraded and legacy routers, however,
legacy routers must be able to terminate tunnels.
</t>
<t>
Note that S-VA is a greatly simplified variant of "full VA"
<xref target="I-D.ietf-grow-va"></xref>.
With full VA, all routers (core or otherwise) can have reduced
FIBs.
However, full VA requires substantial new configuration and
operational complexity compared to S-VA.
Note that S-VA was formerly specified in
<xref target="I-D.ietf-grow-va"></xref>.
It has been moved to this separate draft to simplify its
understanding.
</t>
</section> <!-- "sec-scope" -->
<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 title="Terminology">
<t>
<list style="hanging">
<t hangText="FIB-Installing Router (FIR):">
An S-VA router that does not suppress any routes, and advertises itself
as a default route for 0/0. Typically a core router or route
reflector would be configured as an FIR.
</t>
<t hangText="FIB-Suppressing Router (FSR):">
An S-VA router that installs a route to 0/0, and may
suppress other routes. Typically an edge router would be
configured as an FSR.
</t>
<t hangText="Install and Suppress:">
The terms "install" and "suppress" are used to describe whether
a RIB entry has been loaded or not loaded into the FIB.
In other words, the phrase
"install a route" means "install a route into the FIB", and the
phrase "suppress a route" means "do not install a route into the
FIB".
</t>
<t hangText="Legacy Router:">
A router that does not run S-VA, and has no knowledge of S-VA.
</t>
<t hangText="Routing Information Base (RIB):">
The term RIB is used rather sloppily in this document to refer either
to the loc-RIB (as used in <xref target="RFC4271"></xref>), or to the combined
Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out.
</t>
</list></t>
</section>
<section anchor="sec-temp" title="Temporary Sections">
<t>
This section contains temporary information, and will be removed
in the final version.
</t>
<section anchor="sec-changed" title="Document revisions">
<t>
Note that S-VA was formerly specified in
<xref target="I-D.ietf-grow-va"></xref>.
No new functionality is specified in this draft.
</t>
</section> <!-- "sec-changed" -->
</section> <!-- "sec-temp" -->
-->
</section>
<section anchor="basic-operation" title="Operation of S-VA">
<t>
There are three types of routers in S-VA, FIB-Installing routers (FIR),
FIB-Suppressing routers (FSR), and optionally legacy routers.
While any router can be an FIR or an FSR (there are no topology constraints),
the simplist form of deployment is for border routers to be configured
as edge routers, and for non-border routers (for instance the routers
used as route reflectors) to be configured as core routers.
S-VA, however, does not mandate this deployment per se.
</t>
<t>
FIRs must originate a BGP route to NLRI 0/0
<xref target="RFC4271"></xref>.
The ORIGIN is set to INCOMPLETE (value 2), the AS number of the
FIR's
AS is used in the AS_PATH, and the BGP NEXT_HOP is set to the router's
own address.
The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included.
The FIR MUST attach a NO_EXPORT Communities Attribute
<xref target="RFC1997"></xref> to the route.
</t>
<t>
FIRs must not FIB-suppress any routes.
</t>
<t>
FSRs must FIB-install a route to 0/0.
When transmitting a packet to a FIR (i.e. based on
a 0/0 FIB lookup), the packet must be tunneled.
This is to prevent loops that would otherwise occur when a packet
transits multiple FSRs on the way to the core, some of which
have FIB-installed the route for the destination, and others of
which have not.
FSRs may FIB-install any other routes.
They should install any routes for which their eBGP neighbor
is the NEXT_HOP.
There are a couple reasons for this, which can be illustrated in
the figure below.
This figure shows an autonomous system with a FIR FIR1
and an FSR FSR1. FSR1 is an ASBR and is
connected to two remote ASBRs, EP1 and EP2.
</t>
<figure>
<artwork><![CDATA[
+------------------------------------------+
| Autonomous System | +----+
| | |EP1 |
| /---+---| |
| To ----\ +----+ +----+ / | +----+
| Other \|FIR1|----------|FSR1|/ |
|Routers /| | | |\ |
| ----/ +----+ +----+ \ | +----+
| \---+---|EP2 |
| | | |
| | +----+
+------------------------------------------+
]]></artwork>
</figure>
<t>
Suppose that FSR1 does not FIB-install routes for which EP1 and EP2 are
next hops. In this case, when EP2 sends a packet to FSR1 for which
the next hop is EP1, FSR1 will first tunnel the packet to FIR1, which
will tunnel it right back to FSR1. This trombone routing is avoided
if local ASBRs FIB-install routes where their neighbor remote ASBRs
are the BGP NEXT_HOP.
</t>
<t>
In addition, FSR1 cannot filter source addresses using strict unicast
Reverse Path Forwarding (uRPF) unless it FIB-installs the routes
learned from the remote ASBR.
Note, however, that FSRs cannot do loose uRPF. Rather, this
must be done by FIRs.
</t>
<t>
The above observations lead to the following rules:
FSRs that are ASBRs should FIB-install all routes
for which the neighbor is the BGP NEXT_HOP.
FSRs that are ASBRs must FIB-install any routes
that are used for uRPF.
<!--
A relatively small number of routes are learned from
neighbor ASes that are customers or peers. For these, it should
almost always be possible to FIB-install all routes
When the neighbor AS is a transit, however, there may not be space
in the FIB to FIB-install all routes for which the neighbor is the
BGP NEXT_HOP.
In this case, some simple heuristics can be used to decide which
routes to FIB-install, and which to suppress. For instance,
customer routes can be given preference over non-customer routes.
This insures that all customer routes take shortest path (versus
possibly defaulting to a FIR that is not on the shortest
path to the customer).
After this,
routes with shorter AS-paths can be given preference to routes with
longer AS-paths on the assumption that more traffic is transmitted
to nearby destinations, and therefore fewer packets will trombone.
-->
</t>
<section anchor="sec-tunnels" title="Tunnels">
<t>
S-VA works with both MPLS and IP-in-IP tunnels.
There are potentially up to two tunnels required for a packet
to traverse an AS with S-VA.
The first tunnel is that from an FSR to a FIR
(for the 0/0 default).
This is called the default tunnel.
The second tunnel targets the remote
ASBR which is the BGP NEXT_HOP, although the tunnel header is
stripped by the local ASBR before transmitting to the remote ASBR.
This is the exit tunnel.
The start of the exit tunnel is an ingress local ASBR in the
case where the ingress local ASBR has FIB-installed the associated route.
Otherwise, the start of the exit tunnel is a FIR.
</t>
<t>
The target address of the default tunnel is always the
FIR.
If MPLS is used, the FIRs must initiate
LSPs to themselves using either the
Label Distribution Protocol (LDP) <xref target="RFC5036"></xref>.
RSVP-TE <xref target="RFC3209"></xref> may also be used.
</t>
<t>
If IP-in-IP tunnels are used, then
the BGP Encapsulation Extended Community (BGPencap-Attribute)
(<xref target="RFC5512"></xref>) is used to convey the ability
to accept tunnels at the target address (the BGP NEXT_HOP).
</t>
<t>
For the exit tunnels, again either MPLS or IP-in-IP can be used.
In the case of IP-in-IP, the inner label defined in
<xref target="RFC4023"></xref> and signaled in BGP with
<xref target="RFC3107"></xref> is used by the local ASBR to
identify the remote ASBR which is the BGP NEXT_HOP for the packet.
Specifically,
when a local ASBR, which can be either an FSR or a FIR,
advertises an eBGP-received route into iBGP, it
sets the BGP NEXT_HOP as itself.
It assigns a label to the route.
This label is used as the inner label in packets tunneled to the
local ASBR, and is used to
identify the remote ASBR from which the route was received.
When receiving a packet with this label, the local ASBR strips off
the label, and forwards the native packet to the remote ASBR indicated
by the label.
</t>
<t>
In the case of MPLS, the inner label may or may not be used.
If it is used, then an LSP is established to the IP address of
the local ASBR as described above for FIRs.
The BGP NEXT_HOP is set to be itself (the same address that serves
as the FEC in the LSP).
The inner label is established as described in the previous
paragraph for IP-in-IP tunnels, but with the encapsulation
defined in <xref target="RFC3032"></xref>.
</t>
<t>
If the inner label is not used, then the local ASBR must initiate
a Downstream Unsolicited LSP for each remote ASBR.
The FEC for the LSP is the remote ASBR address that is used
in the BGP NEXT_HOP field.
When a packet is received on one of these LSPs, the local ASBR
strips the MPLS header, and forwards the packet to the remote
ASBR indicated by the label.
</t>
</section> <!-- "sec-tunnels" -->
<section anchor="sec-legacy" title="Legacy Routers">
<t>
S-VA may be operated with a mix of legacy and S-VA-upgraded routers.
The legacy routers, however, must be able to forward tunneled packets.
In the case of MPLS tunnels, this means that they must fully participate
in MPLS signaling.
If a legacy router is an ASBR, then it must also initiate tunnels
to itself and be able to detunnel packets (without the inner label).
</t>
</section> <!-- "sec-legacy" -->
</section> <!-- "basic-operation" -->
<section anchor="sec-iana" title="IANA Considerations">
<t>
There are no IANA considerations.
</t>
</section>
<section anchor="sec-consider" title="Security Considerations">
<t>
The authors are not aware of any new security considerations
due to S-VA.
</t>
</section>
<section anchor="sec-ack" title="Acknowledgements">
<t>
The concept for S-VA comes from Robert Raszuk.
</t>
</section> <!-- "sec-ack" -->
</middle>
<back>
<references title='Normative References'>&rfc2119;
<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='RFC4271'>
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'>
<organization /></author>
<author initials='S.' surname='Hares' fullname='S. Hares'>
<organization /></author>
<date year='2006' month='January' />
<abstract>
<t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t><t> The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t><t> BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t><t> This document obsoletes RFC 1771. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4271' />
<format type='TXT' octets='222702' target='ftp://ftp.isi.edu/in-notes/rfc4271.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='RFC1997'>
<front>
<title>BGP Communities Attribute</title>
<author initials='R.' surname='Chandrasekeran' fullname='Ravishanker Chandrasekeran'>
<organization>cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country></postal>
<email>rchandra@cisco.com</email></address></author>
<author initials='P.' surname='Traina' fullname='Paul Traina'>
<organization>cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country></postal>
<email>pst@cisco.com</email></address></author>
<author initials='T.' surname='Li' fullname='Tony Li'>
<organization />
<address>
<email>tli@skat.usc.edu</email></address></author>
<date year='1996' month='August' />
<abstract>
<t>Border Gateway Protocolis an inter-autonomous system routing protocol designed for TCP/IP internets. This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet.</t></abstract></front>
<seriesInfo name='RFC' value='1997' />
<format type='TXT' octets='8275' target='ftp://ftp.isi.edu/in-notes/rfc1997.txt' />
</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='I-D.ietf-grow-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>
<author initials='D' surname='Jen' fullname='Dan Jen'>
<organization />
</author>
<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
<organization />
</author>
<author initials='L' surname='Zhang' fullname='Lixia Zhang'>
<organization />
</author>
<date month='May' day='23' 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-ietf-grow-va-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-grow-va-00.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='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='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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:59:13 |