One document matched: draft-templin-iron-pm-00.txt
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational November 22, 2010
Expires: May 26, 2011
Provider-Managed IRON
draft-templin-iron-pm-00.txt
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 26, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Templin Expires May 26, 2011 [Page 1]
Internet-Draft Provider-Managed IRON November 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IRON Conceptual Model . . . . . . . . . . . . . . . . . . . . 3
3. Provider-Managed IRON . . . . . . . . . . . . . . . . . . . . 6
4. Dealing with NATs . . . . . . . . . . . . . . . . . . . . . . 8
5. Dealing with Mobility . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Templin Expires May 26, 2011 [Page 2]
Internet-Draft Provider-Managed IRON November 2010
1. Introduction
The Internet Routing Overlay Network (IRON) [I-D.templin-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 Provider-Managed IRON deployment.
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.
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.
2. IRON Conceptual Model
IRON is descended from the RANGER architecture
[RFC5720][I-D.russert-rangers]; it uses Virtual Enterprise Traversal
(VET) [I-D.templin-intarea-vet] and the Subnetwork Encapsulation and
Adaptation Layer (SEAL) [I-D.templin-intarea-seal] 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.
IRON clients connect End User Networks (EUNs) which are assigned EUN
Templin Expires May 26, 2011 [Page 3]
Internet-Draft Provider-Managed IRON November 2010
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.
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.
Figure 1 below depicts an example Provider-Managed IRON deployment:
Templin Expires May 26, 2011 [Page 4]
Internet-Draft Provider-Managed IRON November 2010
.-.
,-( _)-.
.-(_ (_ )-. +--------+
(_ 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)|
+--------+ +--------+
Figure 1: Provider-Managed IRON Deployment
The flows of packets that can occur in this model include:
1. From Host(A) in IRON EUN A to Host(B) in IRON EUN B (depicted in
Figure 1)
2. From Host(A) in IRON EUN A to Host(C) in the Internet
3. From Host(C) in the Internet to Host(A) in IRON EUN A
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
Templin Expires May 26, 2011 [Page 5]
Internet-Draft Provider-Managed IRON November 2010
tunnel from Client(A) to Server(B) with the Relay and Server(A)
removed from the path.
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.
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).
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.
3. Provider-Managed IRON
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.
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
Templin Expires May 26, 2011 [Page 6]
Internet-Draft Provider-Managed IRON November 2010
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.
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 [RFC5565]. However, a full
mesh framework would present a limiting factor for scaling in
multiple dimensions.
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.
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.
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
Templin Expires May 26, 2011 [Page 7]
Internet-Draft Provider-Managed IRON November 2010
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.
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.
4. Dealing with NATs
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.
In the 6a44 proposal [I-D.despres-softwire-6a44], 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.
Using the Provider-Managed IRON approach and its constituent SEAL
Templin Expires May 26, 2011 [Page 8]
Internet-Draft Provider-Managed IRON November 2010
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.
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.
5. Dealing with Mobility
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.
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.
Templin Expires May 26, 2011 [Page 9]
Internet-Draft Provider-Managed IRON November 2010
6. IANA Considerations
There are no IANA considerations for this document.
7. Security Considerations
The security considerations in IRON [I-D.templin-iron] apply also to
this document.
8. Acknowledgements
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.
9. References
9.1. Normative References
[I-D.templin-iron]
Templin, F., "The Internet Routing Overlay Network
(IRON)", draft-templin-iron-13 (work in progress),
October 2010.
9.2. Informative References
[I-D.despres-softwire-6a44]
Despres, R., Carpenter, B., and S. Jiang, "Native IPv6
Across NAT44 CPEs (6a44)", draft-despres-softwire-6a44-01
(work in progress), October 2010.
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", draft-russert-rangers-05 (work in progress),
July 2010.
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-23 (work in
progress), October 2010.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-16 (work in progress),
Templin Expires May 26, 2011 [Page 10]
Internet-Draft Provider-Managed IRON November 2010
July 2010.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
February 2010.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires May 26, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 13:59:54 |