One document matched: draft-templin-iron-pm-01.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="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-templin-iron-pm-01.txt" ipr="trust200811">
<front>
<title abbrev="Provider-Managed IRON">Provider-Managed IRON</title>
<author fullname="Fred L. Templin" initials="F." role="editor"
surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="23" month="May" year="2011" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The Internet Routing Overlay Network (IRON) is a new internetworking
architecture based on encapsulation of inner network layer packets
within outer network layer headers using a non-broadcast, multiple
access (NBMA) virtual interface model. IRON suggests a third-party
global deployment of servers and relays to achieve a
Provider-Independent (PI) routing and addressing framework, but there
may be instances in which an Internet Service Provider (ISP) wishes to
manage its own IRON deployment. This document presents a
Provider-Managed IRON framework that offers a fast path alternative for
deployment of a long term solution.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Internet Routing Overlay Network (IRON) <xref
target="RFC6179"></xref> is a new internetworking architecture based on
encapsulation of inner network layer packets within outer network layer
headers using a non-broadcast, multiple access (NBMA) virtual interface
model. IRON suggests a third-party global deployment of servers and
relays to achieve a Provider-Independent (PI) routing and addressing
framework, but there may be instances in which an Internet Service
Provider (ISP) wishes to manage its own Provider-Managed IRON
deployment.</t>
<t>By managing its own IRON deployment, an ISP can ensure optimal
placement of servers and relays so that clients receive a high quality
of service with minimal routing path stretch. The ISP can further
delegate native IP prefixes to clients even if they are located behind
one or several layers of NATs, and even if they move between different
network points of attachment. Since most ISPs service limited regional
areas, however, routing stretch may become significant for mobile users
that travel far from their homes (e.g., to a different continent). This
situation is no different than that for corporate travelers who
establish Virtual Private Network (VPN) links to their home enterprise
networks when they travel abroad, and can be mitigated by ISP placement
of minimal support infrastructure outside of their primary coverage
region.</t>
<t>This document presents a Provider-Managed IRON framework, and shows
that it can offer ISPs a fast path alternative for deployment of a long
term solution.</t>
</section>
<section anchor="iron" title="IRON Conceptual Model">
<t>IRON is descended from the RANGER architecture <xref
target="RFC5720"></xref><xref target="RFC6139"></xref>; it uses Virtual
Enterprise Traversal (VET) <xref
target="I-D.templin-intarea-vet"></xref> and the Subnetwork
Encapsulation and Adaptation Layer (SEAL) <xref
target="I-D.templin-intarea-seal"></xref> as its functional building
blocks. IRON uses the VET NBMA virtual interface model for coordination
between neighboring routers on a virtual overlay network. It also uses
SEAL as an IP-in-IP encapsulation sublayer, and uses the SEAL Control
Message Protocol (SCMP) for signaling between tunnel endpoints. In
particular, IRON clients use SEAL and SCMP to establish bidirectional
tunnels with IRON servers and to inform the servers of any outer network
layer address changes. IRON clients can also establish unidirectional
tunnels to servers that are closer to the final destination based on
route optimization signaling.</t>
<t>IRON clients connect End User Networks (EUNs) which are assigned EUN
prefixes (EPs) taken from highly-aggregated IP prefixes known as Virtual
Prefixes (VPs). IRON servers connect their clients to a virtual overlay
network configured over an internetwork such as the global Internet.
IRON relays in turn connect the virtual overlay network to the native
(i.e., non-IRON) Internet. The IRON relays in the virtual overlay
network belong to a single Autonomous System (AS) and use eBGP to
advertise the VPs externally into the native Internet default-free
routing system. IRON relays and servers further use an interior routing
protocol such as iBGP to track the EPs assigned to clients.</t>
<t>To provide better service to clients, sufficient numbers of IRON
relays and servers should be uniformly distributed throughout the
internetwork over which the virtual overlay network is configured. Since
the number of IRON servers needed may be very large, each server is
required only to keep track of its own set of clients and to convey its
client constituency to each of the relays. The iBGP peerings between
servers and relays is therefore arranged as a partial mesh in which
servers report their client constituencies to each relay but not to
other servers. In this arrangement, servers have partial topology
information and relays have full topology information. Routing within
the virtual overlay network may therefore direct the initial packets in
a flow through a suboptimal path that involves extraneous relays and
servers as intermediate hops, but redirect messages will quickly inform
the client of a better route.</t>
<t><xref target="OPT"></xref> below depicts an example Provider-Managed
IRON deployment:</t>
<t><figure anchor="OPT" title="Provider-Managed IRON Deployment">
<artwork><![CDATA[ .-.
,-( _)-.
.-(_ (_ )-. +--------+
(_ Internet )--| Host(C)|
`-(______)-' +--------+
|
+------------+
________________| Relay |________________
.-( +------+-----+ )-.
.-( ^^ | || )-.
.( || | vv ).
.( +------------+ | +------------+ ).
( +========>| Server(A) |<--+ | Server(B) |=======+ )
( || +------------+ +------------+ || )
( || vv )
( +-----------+ +-----------+ )
| Client(A) | | Client(B) |
+-----+-----+ ISP Network +-----+-----+
| ( ) |
.-. .-( .-) .-.
,-( _)-. .-(_________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN(A) ) (_ IRON EUN(B) )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host(A)| | Host(B)|
+--------+ +--------+]]></artwork>
</figure>The flows of packets that can occur in this model
include:</t>
<t><list style="numbers">
<t>From Host(A) in IRON EUN A to Host(B) in IRON EUN B (depicted in
<xref target="OPT"></xref>)</t>
<t>From Host(A) in IRON EUN A to Host(C) in the Internet</t>
<t>From Host(C) in the Internet to Host(A) in IRON EUN A</t>
</list>In case 1, the initial packets in the flow sourced from Host(A)
are forwarded through EUN(A) to Client(A), which then forwards them via
the bidirectional tunnel to Server (A). Server(A) then forwards the
packets to a Relay, which returns redirect messages and tunnels the
packets further to Server(B). Server(B) then forwards the packets via
the bidirectional tunnel to Client(B), where they are forwarded across
EUN(B) and delivered to Host B. Following the redirect messages,
subsequent packets flow directly via a unidirectional tunnel from
Client(A) to Server(B) with the Relay and Server(A) removed from the
path.</t>
<t>In case 2, packets sourced from Host(A) are forwarded through EUN(A)
to Client(A), which forwards them via the bidirectional tunnel to
Server(A). Server(A) then forwards them to a Relay, which in turn
forwards them via normal Internet routing until they reach host C.</t>
<t>In case 3, packets sourced from host C are forwarded through normal
Internet routing until they reach a Relay that connects the
Provider-Managed virtual overlay network to the rest of the Internet.
The Relay then forwards the packets to Server(A), where they are
forwarded through the bidirectional tunnel to Client(A) then delivered
to Host(A).</t>
<t>These fundamental communication flow archetypes apply to the case of
IRON virtual overlay networks configured over the unbounded global
Internet when a third party supplies EUNs with PI prefixes. However, the
same archetypes apply when the virtual overlay network is configured
over a more limited topology such as an ISP's service network where the
IP prefixes assigned to EUNs are Provider-Managed. The following section
discusses a Provider-Managed IRON model.</t>
</section>
<section title="Provider-Managed IRON">
<t>The generic IRON use case assumes that the internetwork over which
IRON overlay networks will be configured is the Internet itself. In
other words, the generic use case assumes a global deployment of relays
and servers by a third-party agency that does not coordinate with any
specific ISPs. In that case, the VPs/EPs served by the third party would
be independent of any Provider-Managed prefix space, and hence would be
PI. However, an ISP wishing to roll out a useful service for its
customers could choose to establish an IRON deployment using its own
service network as the internetwork over which the virtual overlay is
configured. In that case, the VPs/EPs serviced by the ISP would be
Provider-Managed and there would be no third-party agencies for
customers to coordinate with. The ISP would also be in the best position
to provide optimal or nearly-optimal placement of IRON relays and
servers within its managed network.</t>
<t>When an ISP deploys its own IRON virtual overlay system, it
establishes relays at the border of the virtual overlay network that
connect the overlay to the global Internet. These relays run eBGP on
their Internet-facing interfaces, and advertise the VPs that have been
delegated to the ISP. The ISP should only need to advertise a small
number of VPs that would only very rarely need to be withdrawn and
re-announced within the global routing system. The ISP also deploys
servers close to its customer EUNs in sufficient numbers so that the
customers receive a high quality of service. While the IRON architecture
allows for the relay and server function to be deployed on the same
physical platform, for reasons of scaling it is expected that they will
often be deployed on separate platforms.</t>
<t>In terms of scaling, in the limiting case in which all of the ISP's
IRON routers provide both the relay and server function, the
relay/servers would engage in a full mesh iBGP session the same as
described in the Softwire Mesh Framework <xref target="RFC5565"></xref>.
However, a full mesh framework would present a limiting factor for
scaling in multiple dimensions.</t>
<t>First, each relay/server would only be able to service a limited set
of customer client EUNs, since each client requires that the server
maintain bidirectional tunnel state and engage in periodic keepalive
exchanges. Second, since an ISP wishing to support a large number of
customer clients would need to deploy a large number of relay/servers,
the number of iBGP peering sessions between them would grow with the
square of the number of relay/servers. This scaling situation can be
addressed through the use of route reflectors, but the route reflectors
cannot convey reachability state from one relay/server to another.
Moreover, there is no reason that each server needs to have full
knowledge of all EPs assigned to all customer EUNs. Instead, it should
only have to know about the EPs assigned to its own current set of
client customers and maintain a default route pointing to the relay
router anycast address.</t>
<t>Hence, when the server and relay functions are deployed on separate
platforms, the IRON system enables a "partial mesh" topology in which
servers report only the EP-to-client relationships for all of their
client customers and maintain default routes to relays. Relays in turn
discover all EP-to-server relationships and thus have full topology
knowledge of the EP distributions throughout the ISP network. Moreover,
servers can be placed close to the customers to support optimal routes,
and more servers can be added as the client load grows.</t>
<t>As an example, assume that an ISP deploys a Provider-Managed IRON
deployment using a single IPv6 ::/24 VP, from which it assigns IPv6
::/56 EPs to its client customers. The ISP can establish a reasonable
number of relays (e.g., 100) at the virtual overlay network border with
the Internet. The ISP could then uniformly distribute a sufficient
number of servers (e.g., 2^16) located close to customers throughout its
network, where each server would be sized to serve 2^16 customers. Such
a deployment would enable service for all 2^32 ::/56 EPs taken from the
single ::/24 VP while advertising only a single VP into the global
routing system. Each of the 100 relays would need to maintain iBGP
peering sessions with each of the 2^16 servers to discover all
client-to-server mappings in the IRON system. Each of the 2^16 servers
would only need to report their client constituency via the 100 iBGP
peering sessions and would not need to discover the client
constituencies of other servers since they only require the relay router
anycast address as the default route.</t>
<t>Since the servers would have only partial topology information (i.e.,
they would only know about their own clients and about the relay anycast
default route) packets originated by one of their clients A and destined
to a client B that is serviced by a different server would need to be
forwarded through a relay. Using the IRON secure redirection system,
however, the relay would return a redirect message which the server
would forward to the client customer. Thereafter, packets originating
from client A and destined to client B would be forwarded directly to
client B's server without involving either client A's server nor any
relays. This technique is often known as route optimization, and is a
fundamental requirement for any production-quality routing system.</t>
</section>
<section title="Dealing with NATs">
<t>In typical ISP deployments, customer EUNs are located behind Customer
Premises Equipment (CPE) routers that perform a Network Address
Translation (NAT) function internally. With the impending runout of IPv4
addresses, ISPs are now also faced with a situation in which they may
need to assign private-use IP addresses to the outward-facing interfaces
of CPEs and perform a second level of NATing withing the ISP network.
Hence, devices in customer EUNs will be located behind one or several
layers of NATs which impart special requirements on tunneling
technologies. In particular, tunneling technologies will need to be
configured over the UDP protocol which can traverse NATs.</t>
<t>In the 6a44 proposal <xref
target="I-D.despres-softwire-6a44"></xref>, the authors present a novel
method of supporting IPv6 clients in EUNs through stateless
coordinations with servers in the ISP network. Each client in this model
receives only a single address that is constructed based on the outer
NAT address and port mapping values, however, and these values can
change across NAT reboots and/or loss of state. Hence, it may not be
practical for administrators to represent the 6a44 addresses in a static
name resolution system such as the DNS and/or for communicating peers to
rely on a stable address for session continuity.</t>
<t>Using the Provider-Managed IRON approach and its constituent SEAL
mechanism, however, a client device in the customer EUN can receive an
EP from its service provider (e.g., an IPv6 ::/56) and then register
this EP with a nearby server that it discovers through an anycast router
solicitation. Once registered, the server distributes this new EP
registration to all relays.</t>
<t>This stateful registration establishes next hop information in the
server which the client must refresh periodically by sending beacons
which have the side effect of keeping state alive in any NATs on the
path. Since NATs may lose state and create new mappings, however, the
server does not rely on the IP address and port mapping information to
identify the client. Instead it relies on the SEAL identification tags
that were established when the client first registered with the server.
In this arrangement, it does not matter if the address and port mappings
change periodically as long as the client sends beacons frequently
enough to keep the NAT state synchronized with the server state.</t>
</section>
<section title="Dealing with Mobility">
<t>When a client moves to a new network point of attachment, it simply
sends a new anycast router solicitation message to register with a new
server. Unlike the global IRON case, however, a client in a
Provider-Managed IRON deployment can only discover a server in its home
ISP even if it has moved far away from home. For example, if a customer
from ISP A located in the United States takes their IRON client router
to Beijing they can still continue to use their Provider-Managed EPs,
but all traffic to and from the EPs would need to be routed through the
relays and servers in the ISP A US-based network even if both
correspondent hosts are located in Beijing. Although clearly not
optimal, this situation is no different than for a corporate employee
who takes their laptop to a distant country and uses a VPN to connect to
their home office.</t>
<t>However, if ISP A wishes to provide better mobility service to its
customers, it can deploy additional relays and servers in the networks
of other ISPs worldwide simply by leasing public IP addresses and
establishing equipment in the foreign ISPs networks. In that case, the
Provider-Managed IRON case begins to look identical to the
Provider-Independent case, and mobile clients can achieve a high quality
of service even if they have moved far away from their home network. It
therefore becomes immaterial as to whether the customer would pay an ISP
for their IRON services or pay some third party entity - the service
they would receive would be equivalent and dependent only on the quality
of the IRON deployment.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA considerations for this document.</t>
</section>
<section anchor="secure" title="Security Considerations">
<t>The security considerations in IRON <xref target="RFC6179"></xref>
apply also to this document.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The concept of a Provider-Specific version of IRON was inspired by
discussions in the intarea working group during IETF79. The ideas were
further motivated by related works authored by Brian Carpenter, Remi
Despres and Sheng Jiang.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.6179"?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5720"?>
<?rfc include="reference.RFC.5565"?>
<?rfc include="reference.I-D.templin-intarea-seal"?>
<?rfc include="reference.I-D.templin-intarea-vet"?>
<?rfc include="reference.I-D.despres-softwire-6a44"?>
<?rfc include="reference.RFC.6139"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:50:19 |