Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational August 19, 2011
Expires: February 20, 2012
The Internet Routing Overlay Network (IRON)
draft-templin-ironbis-02.txt
Abstract
Since the Internet must continue to support escalating growth due to
increasing demand, it is clear that current routing architectures and
operational practices must be updated. This document proposes an
Internet Routing Overlay Network (IRON) architecture that supports
sustainable growth while requiring no changes to end systems and no
changes to the existing routing system. IRON further addresses other
important issues including routing scaling, mobility management,
mobile networks, multihoming, traffic engineering and NAT traversal.
While business considerations are an important determining factor for
widespread adoption, they are out of scope for this document.
Status of this Memo
This Internet-Draft is submitted 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 February 20, 2012.
Copyright Notice
Copyright (c) 2011 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 February 20, 2012 [Page 1]
Internet-Draft IRON August 2011
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.
Templin Expires February 20, 2012 [Page 2]
Internet-Draft IRON August 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Internet Routing Overlay Network . . . . . . . . . . . . . 7
3.1. IRON Client . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. IRON Serving Router . . . . . . . . . . . . . . . . . . . 10
3.3. IRON Relay Router . . . . . . . . . . . . . . . . . . . . 10
4. IRON Organizational Principles . . . . . . . . . . . . . . . . 11
5. IRON Control Plane Operation . . . . . . . . . . . . . . . . . 13
5.1. IRON Client Operation . . . . . . . . . . . . . . . . . . 13
5.2. IRON Server Operation . . . . . . . . . . . . . . . . . . 14
5.3. IRON Relay Operation . . . . . . . . . . . . . . . . . . . 14
6. IRON Forwarding Plane Operation . . . . . . . . . . . . . . . 15
6.1. IRON Client Operation . . . . . . . . . . . . . . . . . . 15
6.2. IRON Server Operation . . . . . . . . . . . . . . . . . . 16
6.3. IRON Relay Operation . . . . . . . . . . . . . . . . . . . 17
7. IRON Reference Operating Scenarios . . . . . . . . . . . . . . 18
7.1. Both Hosts within Same IRON Instance . . . . . . . . . . . 18
7.1.1. EUNs Served by Same Server . . . . . . . . . . . . . . 18
7.1.2. EUNs Served by Different Servers . . . . . . . . . . . 20
7.2. Mixed IRON and Non-IRON Hosts . . . . . . . . . . . . . . 22
7.2.1. From IRON Host A to Non-IRON Host B . . . . . . . . . 22
7.2.2. From Non-IRON Host B to IRON Host A . . . . . . . . . 24
7.3. Hosts within Different IRON Instances . . . . . . . . . . 25
8. Mobility, Multiple Interfaces, Multihoming, and Traffic
Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Mobility Management and Mobile Networks . . . . . . . . . 26
8.2. Multiple Interfaces and Multihoming . . . . . . . . . . . 26
8.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 27
9. Renumbering Considerations . . . . . . . . . . . . . . . . . . 27
10. NAT Traversal Considerations . . . . . . . . . . . . . . . . . 27
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 28
12. Nested EUN Considerations . . . . . . . . . . . . . . . . . . 28
12.1. Host A Sends Packets to Host Z . . . . . . . . . . . . . . 30
12.2. Host Z Sends Packets to Host A . . . . . . . . . . . . . . 30
13. Implications for the Internet . . . . . . . . . . . . . . . . 31
14. Additional Considerations . . . . . . . . . . . . . . . . . . 32
15. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 32
16. Security Considerations . . . . . . . . . . . . . . . . . . . 33
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
18.1. Normative References . . . . . . . . . . . . . . . . . . . 34
18.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. IRON VPs over Internetworks with Different
Address Families . . . . . . . . . . . . . . . . . . 37
Appendix B. Scaling Considerations . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
Templin Expires February 20, 2012 [Page 3]
Internet-Draft IRON August 2011
1. Introduction
Growth in the number of entries instantiated in the Internet routing
system has led to concerns regarding unsustainable routing scaling
[RADIR]. Operational practices such as the increased use of
multihoming with Provider-Independent (PI) addressing are resulting
in more and more fine-grained prefixes being injected into the
routing system from more and more end user networks. Furthermore,
depletion of the public IPv4 address space has raised concerns for
both increased address space fragmentation (leading to yet further
routing table entries) and an impending address space run-out
scenario. At the same time, the IPv6 routing system is beginning to
see growth [BGPMON] which must be managed in order to avoid the same
routing scaling issues the IPv4 Internet now faces. Since the
Internet must continue to scale to accommodate increasing demand, it
is clear that new routing methodologies and operational practices are
needed.
Several related works have investigated routing scaling issues.
Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing
Scopes (AIS) [EVOLUTION] are global routing proposals that introduce
routing overlays with Virtual Prefixes (VPs) to reduce the number of
entries required in each router's Forwarding Information Base (FIB)
and Routing Information Base (RIB). Routing and Addressing in
Networks with Global Enterprise Recursion (RANGER) [RFC5720] examines
recursive arrangements of enterprise networks that can apply to a
very broad set of use-case scenarios [RFC6139]. IRON specifically
adopts the RANGER Non-Broadcast, Multiple Access (NBMA) tunnel
virtual-interface model, and uses Virtual Enterprise Traversal (VET)
[INTAREA-VET] and the Subnetwork Adaptation and Encapsulation Layer
(SEAL) [INTAREA-SEAL] as its functional building blocks.
This document proposes an Internet Routing Overlay Network (IRON)
architecture with goals of supporting scalable routing and addressing
while requiring no changes to the Internet's Border Gateway Protocol
(BGP) routing system [RFC4271]. IRON observes the Internet Protocol
standards [RFC0791][RFC2460], while other network-layer protocols
that can be encapsulated within IP packets (e.g., OSI/CLNP
(Connectionless Network Protocol) [RFC1070], etc.) are also within
scope.
IRON borrows concepts from VA and AIS, and further borrows concepts
from the Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH]
architecture proposal along with its associated Translating Tunnel
Router (TTR) mobility extensions [TTRMOB]. Indeed, the TTR model to
a great degree inspired the IRON mobility architecture design
discussed in this document. The Network Address Translator (NAT)
traversal techniques adapted for IRON were inspired by the Simple
Templin Expires February 20, 2012 [Page 4]
Internet-Draft IRON August 2011
Address Mapping for Premises Legacy Equipment (SAMPLE) proposal
[SAMPLE].
IRON is a global virtual routing system comprising Virtual Service
Provider (VSP) overlay networks that service Virtual Prefixes (VPs)
from which End User Network (EUN) prefixes (EPs) are delegated to
customer sites. IRON is motivated by a growing customer demand for
mobility management, mobile networks, multihoming and traffic
engineering while using stable addressing to minimize dependence on
network renumbering [RFC4192][RFC5887]. IRON VSP overlay network
instances use the existing IPv4 and IPv6 global Internet routing
systems as virtual NBMA links for tunneling inner network protocol
packets within outer IPv4 or IPv6 headers (see Section 3). Each IRON
instance requires deployment of a small number of new Autonomous
System Border Routers (ASBRs) and supporting servers, as well as
IRON-aware clients that connect customer EUNs. No modifications to
hosts, and no modifications to most routers, are required. The
following sections discuss details of the IRON architecture.
2. Terminology
This document makes use of the following terms:
End User Network (EUN):
an edge network that connects an organization's devices (e.g.,
computers, routers, printers, etc.) to the Internet. IRON EUNs
are mobile networks, and can change their ISP attachments without
having to renumber.
End User Network Prefix (EP):
a more specific inner network-layer prefix (e.g., an IPv4 /28, an
IPv6 /56, etc.) derived from an aggregated Virtual Prefix (VP) and
delegated to an EUN by a Virtual Service Provider (VSP).
End User Network Prefix Address (EPA):
a network-layer address belonging to an EP and assigned to the
interface of an end system in an EUN.
Forwarding Information Base (FIB):
a data structure containing network prefixes to next-hop mappings;
usually maintained in a router's fast-path processing lookup
tables.
Internet Routing Overlay Network (IRON):
the union of all VSP overlay network instances. Each such IRON
instance supports routing within the overlay through encapsulation
of inner packets with EPA addresses within outer headers that use
Templin Expires February 20, 2012 [Page 5]
Internet-Draft IRON August 2011
locator addresses. Each IRON instance connects to the global
Internet the same as for any Autonomous System (AS).
IRON Client Router/Host ("Client"):
a customer's router or host that logically connects the customer's
EUNs and their associated EPs to an IRON instance via an NBMA
tunnel virtual interface.
IRON Serving Router ("Server"):
a VSP's IRON instance router that provides forwarding and mapping
services for the EPs owned by customer Clients.
IRON Relay Router ("Relay"):
a VSP's IRON instance router that acts as a relay between the IRON
and the native Internet.
IRON Agent (IA):
generically refers to any of an IRON Client/Server/Relay.
IRON Instance:
a set of IRON Agents deployed by a VSP to service customer EUNs
through automatic tunneling over an underlying Internetwork (e.g.,
the global Internet).
Internet Service Provider (ISP):
a service provider that connects customer EUNs to the underlying
Internetwork. In other words, an ISP is responsible for providing
basic Internet connectivity for customer EUNs.
Locator
an IP address assigned to the interface of a router or end system
within a public or private network. Locators taken from public IP
prefixes are routable on a global basis, while locators taken from
private IP prefixes [RFC1918] are made public via Network Address
Translation (NAT).
Routing and Addressing in Networks with Global Enterprise Recursion
(RANGER):
an architectural examination of virtual overlay networks applied
to enterprise network scenarios, with implications for a wider
variety of use cases.
Subnetwork Encapsulation and Adaptation Layer (SEAL):
an encapsulation sublayer that provides extended packet
identification and a Control Message Protocol to ensure
deterministic network-layer feedback.
Templin Expires February 20, 2012 [Page 6]
Internet-Draft IRON August 2011
Virtual Enterprise Traversal (VET):
a method for discovering border routers and forming dynamic
tunnel-neighbor relationships over enterprise networks (or sites)
with varying properties.
Virtual Prefix (VP):
a large prefix block (e.g., an IPv4 /16, an IPv6 /20, an OSI
Network Service Access Protocol (NSAP) prefix, etc.) that is owned
and managed by a Virtual Service Provider (VSP).
Virtual Service Provider (VSP):
a company that owns and manages a set of VPs from which it
delegates EPs to EUNs.
VSP Overlay Network:
the same as defined above for IRON Instance.
3. The Internet Routing Overlay Network
The Internet Routing Overlay Network (IRON) is a union of Virtual
Service Provider (VSP) overlay networks (also known as "IRON
instances") configured over a common Internetwork. IRON provides a
number of important services to End User Networks (EUNs) that are not
well supported in the current Internet architecture, including
routing scaling, mobility management, mobile networks, multihoming,
traffic engineering and NAT traversal. While the principles
presented in this document are discussed within the context of the
public global Internet, they can also be applied to any autonomous
Internetwork. The rest of this document therefore refers to the
terms "Internet" and "Internetwork" interchangeably except in cases
where specific distinctions must be made.
Each IRON instance consists of IRON Agents (IAs) that automatically
tunnel the packets of end-to-end communication sessions within
encapsulating headers used for Internet routing. IAs use the Virtual
Enterprise Traversal (VET) [INTAREA-VET] virtual NBMA link model in
conjunction with the Subnetwork Encapsulation and Adaptation Layer
(SEAL) [INTAREA-SEAL] to encapsulate inner network-layer packets
within outer headers, as shown in Figure 1.
Templin Expires February 20, 2012 [Page 7]
Internet-Draft IRON August 2011
+-------------------------+
| Outer headers with |
~ locator addresses ~
| (IPv4 or IPv6) |
+-------------------------+
| SEAL Header |
+-------------------------+ +-------------------------+
| Inner Packet Header | --> | Inner Packet Header |
~ with EP addresses ~ --> ~ with EP addresses ~
| (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) |
+-------------------------+ +-------------------------+
| | --> | |
~ Inner Packet Body ~ --> ~ Inner Packet Body ~
| | --> | |
+-------------------------+ +-------------------------+
Inner packet before Outer packet after
encapsulation encapsulation
Figure 1: Encapsulation of Inner Packets within Outer IP Headers
VET specifies the automatic tunneling mechanisms used for
encapsulation, while SEAL specifies the format and usage of the SEAL
header as well as a set of control messages. Most notably, IAs use
the SEAL Control Message Protocol (SCMP) to deterministically
exchange and authenticate control messages such as router
solicitations, route redirections, indications of Path Maximum
Transmission Unit (PMTU) limitations, destination unreachables, etc.
IAs appear as neighbors on an NBMA tunnel virtual link.
Each IRON instance comprises a set of IAs distributed throughout the
Internet to serve highly aggregated Virtual Prefixes (VPs). VSPs
delegate sub-prefixes from their VPs, which they provide to customers
as End User Network Prefixes (EPs). In turn, the customers assign
the EPs to their customer edge IAs, which connect their End User
Networks (EUNs) to the VSP IRON instance.
VSPs may have no affiliation with the ISP networks from which
customers obtain their basic Internet connectivity. Therefore, a
customer could procure its summary network and data link services
either through a common provider or through separate entities. In
that case, the VSP can open for business and begin serving its
customers immediately without the need to coordinate its activities
with ISPs or other VSPs. Further details on business considerations
are out of scope for this document.
IRON requires no changes to end systems or to most routers in the
Internet. Instead, IAs are deployed either as new platforms or as
Templin Expires February 20, 2012 [Page 8]
Internet-Draft IRON August 2011
modifications to existing platforms. IAs may be deployed
incrementally without disturbing the existing Internet routing
system, and act as waypoints (or "cairns") for navigating VSP overly
networks. The functional roles for IAs are described in the
following sections.
3.1. IRON Client
An IRON client (or, simply, "Client") is a customer's router or host
that logically connects the customer's EUNs and their associated EPs
to its VSP's IRON instance via tunnels, as shown in Figure 2. Client
routers obtain EPs from their VSPs and use them to number subnets and
interfaces within their EUNs.
Each Client connects to one or more Servers in the IRON instance
which serve as default routers. The Servers in turn consider this
class of Clients as "connected Clients". Clients also dynamically
discover destination-specific Servers through the receipt of redirect
messages. These destination-specific Servers consider this class of
Clients as "foreign Clients".
A Client can be deployed on the same physical platform that also
connects the customer's EUNs to its ISPs, but it may also be a
separate router or even a standalone server system located within the
EUN. (This model applies even if the EUN connects to the ISP via a
Network Address Translator (NAT) -- see Section 6.7). Finally, a
Client may also be a simple end system that connects a singleton EUN
and exhibits the outward appearance of a host.
.-.
,-( _)-.
+--------+ .-(_ (_ )-.
| Client |--(_ ISP )
+---+----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN ) e `-(______)-
`-(______)-' l ___
| s => (:::)-.
+----+---+ .-(::::::::)
| Host | .-(::: IRON :::)-.
+--------+ (:::: Instance ::::)
`-(::::::::::::)-'
`-(::::::)-'
Figure 2: IRON Client Router Connecting EUN to IRON Instance
Templin Expires February 20, 2012 [Page 9]
Internet-Draft IRON August 2011
3.2. IRON Serving Router
An IRON serving router (or, simply, "Server") is a VSP's router that
provides forwarding and mapping services within the IRON instance for
the EPs owned by customer Client routers. In typical deployments, a
VSP will deploy many Servers around the IRON instance in a globally
distributed fashion (e.g., as depicted in Figure 3) so that Clients
can discover those that are nearby.
+--------+ +--------+
| Boston | | Tokyo |
| Server | | Server |
+--+-----+ ++-------+
+--------+ \ /
| Seattle| \ ___ /
| Server | \ (:::)-. +--------+
+------+-+ .-(::::::::)------+ Paris |
\.-(::: IRON :::)-. | Server |
(:::: Instance ::::) +--------+
`-(::::::::::::)-'
+--------+ / `-(::::::)-' \ +--------+
| Moscow + | \--- + Sydney |
| Server | +----+---+ | Server |
+--------+ | Cairo | +--------+
| Server |
+--------+
Figure 3: IRON Serving Router Global Distribution Example
Each Server acts as a tunnel-endpoint router. The Server forms
bidirectional tunnel-neighbor relationships with each of its
connected Clients, and also serves as the unidirectional tunnel-
neighbor egress for dynamically discovered foreign Clients. Each
Server also forms bidirectional tunnel-neighbor relationships with a
set of Relays that can forward packets from the IRON instance out to
the native Internet and vice versa, as discussed in the next section.
3.3. IRON Relay Router
An IRON Relay Router (or, simply, "Relay") is a router that connects
the VSP's IRON instance to the Internet as an Autonomous System (AS).
The Relay therefore also serves as an Autonomous System Border Router
(ASBR) that is owned and managed by the VSP.
Each VSP configures one or more Relays that advertise the company's
VPs into the IPv4 and IPv6 global Internet BGP routing systems. Each
Relay associates with the VSP's IRON instance Servers, e.g., via
bidirectional tunnel-neighbor relationships over the IRON instance,
Templin Expires February 20, 2012 [Page 10]
Internet-Draft IRON August 2011
via a direct interconnect such as an Ethernet cable, etc. The Relay
role is depicted in Figure 4.
.-.
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-' | +--------+
| |--| Server |
+----+---+ | +--------+
| Relay |----| +--------+
+--------+ |--| Server |
_|| | +--------+
(:::)-. (Ethernet)
.-(::::::::)
+--------+ .-(::: IRON :::)-. +--------+
| Server |=(:::: Instance ::::)=| Server |
+--------+ `-(::::::::::::)-' +--------+
`-(::::::)-'
|| (Tunnels)
+--------+
| Server |
+--------+
Figure 4: IRON Relay Router Connecting IRON Instance to Native
Internet
4. IRON Organizational Principles
The IRON consists of the union of all VSP overlay networks configured
over a common Internetwork (e.g., the public Internet). Each such
IRON instance represents a distinct "patch" on the Internet "quilt",
where the patches are stitched together by standard Internet routing.
When a new IRON instance is deployed, it becomes yet another patch on
the quilt and coordinates its internal routing system independently
of all other patches.
Each IRON instance connects to the Internet as an AS in the BGP
routing system using a public Autonomous System Number (ASN). The
IRON instance maintains a set of Relays that serve as ASBRs as well
as a set of Servers that provide routing and addressing services to
Client customers. Figure 5 depicts the logical arrangement of
Relays, Servers, and Clients in an IRON instance.
Templin Expires February 20, 2012 [Page 11]
Internet-Draft IRON August 2011
.-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------------ Relays ------------>
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(::::::::::: IRON Instance :::::::::::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<------------ Servers ------------>
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<----------- Clients and EUNs ----------->
Figure 5: IRON Organization
Each Relay connects the IRON instance directly to the IPv4 and IPv6
Internets via external BGP (eBGP) peerings with neighboring ASes. It
also advertises the VSP's IPv4 VPs into the IPv4 BGP routing system
and advertises the VSP's IPv6 VPs into the IPv6 BGP routing system.
Relays will therefore receive packets with EPA destination addresses
sent by end systems in the Internet and forward them to a server that
connects the EPA-addressed end system to the VSP's IRON instance.
Finally, the IRON instance Relays maintain synchronization by running
interior BGP (iBGP) between themselves the same as for ordinary
ASBRs.
Each Server is configured as an ASBR for a stub AS, and uses a
private ASN [RFC1930] to peer with each IRON instance Relay the same
as for an ordinary eBGP neighbor. (The Server and Relay functions
can instead be deployed together on the same physical platform as a
unified gateway.) Each Server maintains a working set of connected
Clients for which it caches EP-to-Client mappings in its Forwarding
Information Base (FIB). Each Server also, in turn, propagates the
list of EPs in its working set to its neighboring Relays via eBGP.
Therefore, each Server only needs to track the EPs for its current
working set of Clients, while each Relay will maintain a full EP-to-
Templin Expires February 20, 2012 [Page 12]
Internet-Draft IRON August 2011
Server Routing Information Base (RIB) that represents reachability
information for all EPs in the IRON instance.
Customer Clients obtain their basic Internet connectivity from ISPs,
and connect to VSP Servers to attach their EUNs to the IRON instance.
Each EUN can further connect to the IRON instance via multiple
Clients as long as the Clients coordinate with one another, e.g., to
mitigate EUN partitions. Unlike Relays and Servers, Clients may use
private addresses behind one or several layers of NATs. Each Client
initially discovers a list of nearby Servers then forms a
bidirectional tunnel-neighbor relationship with one or more Servers
through an initial exchange followed by periodic keepalives.
After the Client connects to Servers, it forwards initial outbound
packets from its EUNs by tunneling them to a Server, which may, in
turn, forward them to a nearby Relay within the IRON instance. The
Client may subsequently receive redirect messages informing it of a
more direct route through a different Server within the IRON instance
that serves the final destination EUN. This foreign Server in turn
provides the Client with a unidirectional tunnel-neighbor egress for
route optimization purposes,.
IRON can also be used to support VPs of network-layer address
families that cannot be routed natively in the underlying
Internetwork (e.g., OSI/CLNP over the public Internet, IPv6 over
IPv4-only Internetworks, IPv4 over IPv6-only Internetworks, etc.).
Further details for the support of IRON VPs of one address family
over Internetworks based on other address families are discussed in
Appendix A.
5. IRON Control Plane Operation
Each IRON instance supports routing through the control plane startup
and runtime dynamic routing operation of IAs. The following sub-
sections discuss control plane considerations for initializing and
maintaining the IRON instance routing system.
5.1. IRON Client Operation
Each Client obtains one or more EPs in a secured exchange with the
VSP as part of the initial customer signup agreement. Upon startup,
the Client connects to a location broker (e.g., a well known website
run by the VSP) to discover a list of nearby Servers.
After the Client obtains a list of nearby Servers, it initiates short
transactions to connect to one or more Servers, e.g., via secured TCP
connections. During the transaction, each Server provides the Client
Templin Expires February 20, 2012 [Page 13]
Internet-Draft IRON August 2011
with a tunnel-neighbor identifier ("NBR_ID") and a Shared Secret that
the Client will use to sign and authenticate certain control
messages. The protocol details of the transaction are specific to
the VSP, and hence out of scope for this document.
After the Client connects to Servers, it configures default routes
that list the Servers as next hops on the tunnel virtual interface.
The Client may subsequently discover more-specific routes through
receipt of redirect messages.
5.2. IRON Server Operation
Each IRON Server is provisioned with the locators for Relays within
the IRON instance. Unless the Server shares the same physical
platform as a Relay, the Server is further configured as an ASBR for
a stub AS and uses eBGP with a private ASN to peer with each Relay.
Upon startup, the Server connects to each Relay via eBGP peerings for
the purpose of reporting the list of EPs it is currently serving.
The Server then actively listens for Client customers that register
their EP prefixes as part of a connection establishment procedure.
When a new Client connects, the Server announces the new EP routes to
its neighboring Relays; when an existing Client disconnects, the
Server withdraws its EP announcements.
5.3. IRON Relay Operation
Each IRON Relay is provisioned with the list of VPs that it will
serve, as well as the locators for Servers within the IRON instance.
The Relay is also provisioned with eBGP interconnections with peering
ASes in the Internet -- the same as for any BGP router.
Upon startup, the Relay connects to each Server via IRON instance-
internal eBGP peerings for the purpose of discovering EP-to-Server
mappings, and connects to all other Relays using iBGP either in a
full mesh or using route reflectors. (The Relay only uses iBGP to
announce those prefixes it has learned from AS peerings external to
the IRON instance, however, since all Relays have already discovered
all EPs in the IRON instance via their eBGP peerings with Servers.)
The Relay then engages in eBGP routing exchanges with peer ASes in
the IPv4 and/or IPv6 Internets the same as for any BGP router.
After this initial synchronization procedure, the Relay advertises
the VPs to its eBGP peers in the Internet. In particular, the Relay
advertises the IPv6 VPs into the IPv6 BGP routing system and
advertises the IPv4 VPs into the IPv4 BGP routing system, but it does
not advertise any of the IRON overlay's EPs to any of its eBGP peers.
The Relay further advertises "default" via eBGP to its associated
Templin Expires February 20, 2012 [Page 14]
Internet-Draft IRON August 2011
Servers, then engages in ordinary packet-forwarding operations.
6. IRON Forwarding Plane Operation
Following control plane initialization, IAs engage in the cooperative
process of receiving and forwarding packets. IAs forward
encapsulated packets over the IRON instance using the mechanisms of
VET [INTAREA-VET] and SEAL [INTAREA-SEAL], while Relays additionally
forward packets to and from the native IPv6 and IPv4 Internets. IAs
also use SCMP to coordinate with other IAs, including the process of
sending and receiving redirect messages, error messages, etc. Each
IA operates as specified in the following sub-sections.
6.1. IRON Client Operation
After connecting to Servers as specified in Section 5.1, the Client
registers one or more active ISP connections with each Server. To do
so, it sends periodic beacons (e.g., cryptographically signed SRS
messages) to the Server via each ISP connection to maintain tunnel-
neighbor address mapping state. The beacons should be sent at no
more than 60 second intervals (subject to a small random delay) so
that state in NATs on the path as well as on the Server itself is
refreshed regularly. Although the Client may connect via multiple
ISPs, a single NBR_ID is used to represent the set of all ISP paths
the Client has registered with this Server. The NBR_ID therefore
names this "bundle" of ISP connections.
If the Client ceases to receive acknowledgements from a Server via a
specific ISP connection, it marks the Server as unreachable from that
ISP. (The Client should also inform the Server of this outage via
one of its working ISP connections.) If the Client ceases to receive
acknowledgements from the Server via multiple ISP connections, it
disconnects from this server and connects to a new nearby Server.
The act of disconnecting from old servers and connecting to new
servers will soon propagate the appropriate routing information among
the IRON instance's Relay Routers.
When an end system in an EUN sends a flow of packets to a
correspondent in a different network, the packets are forwarded
through the EUN via normal routing until they reach the Client, which
then tunnels the initial packets to a Server as its default router.
In particular, the Client encapsulates each packet in an outer header
with its locator as the source address and the locator of the Server
as the destination address.
The Client uses the mechanisms specified in VET and SEAL to
encapsulate each packet to be forwarded. The Client further accepts
Templin Expires February 20, 2012 [Page 15]
Internet-Draft IRON August 2011
SCMP protocol messages from its Servers, including indications of
PMTU limitations, redirects and other control messages. When the
Client is redirected to a foreign Server that serves a destination
EP, it sends future packets toward that destination EP directly to
the foreign Server instead of via one of its connected Servers.
Note that Client-to-Client tunneling is not permitted, since this
could result in unpredictable behavior when one or both Clients are
located behind a NAT, or when one or both Clients are mobile.
Therefore, Client-to-Client mobility binding updates are not required
in the IRON model.
6.2. IRON Server Operation
After the Server associates with nearby Relays, it accepts Client
connections and authenticates the SRS messages it receives from its
already-connected Clients. The Server discards any SRS messages that
failed authentication, and responds to authentic SRS messages by
returning signed SRAs.
When the Server receives a SEAL-encapsulated data packet from one of
its connected Clients, it uses normal longest-prefix-match rules to
locate a FIB entry that matches the packet's inner destination
address. If the matching FIB entry is more-specific than default,
the next hop is another of its connected Clients; otherwise, the
next-hop is a Relay which serves as a default router. The Server
then re-encapsulates the packet (i.e., it removes the outer header
and replaces it with a new outer header of the same address family),
sets the outer destination address to the locator address of the next
hop and tunnels the packet to the next hop.
When the Server receives a SEAL-encapsulated data packet from a
foreign Client, it accepts the packet only if there is a matching
ingress filter table entry; otherwise, it silently drops the packet.
The Server then locates a FIB entry that matches the packet's inner
destination address. If there is no matching FIB entry more-specific
than default (i.e., the destination does not correspond to a
connected Client), the Server silently drops the packet. Otherwise,
the Server re-encapsulates the packet and forwards it to the correct
connected Client. If the Client is in the process of disconnecting
(e.g., due to mobility), the Server also returns a redirect message
listing a NULL next hop to inform the foreign Client that the
connected Client has moved.
When the Server receives a SEAL-encapsulated data packet from a
Relay, it again locates a FIB entry that matches the packet's inner
destination. If there is no matching FIB entry more-specific than
default, the Server drops the packet and sends a destination
Templin Expires February 20, 2012 [Page 16]
Internet-Draft IRON August 2011
unreachable message. Otherwise, the Server re-encapsulates the
packet and forwards it to the correct connected Client.
Note that Server-to-Server tunneling is not permitted, since this
could result in sustained routing loops in which Server A has a route
to Server B, and Server B has a route to Server A. This implies that
a Server must never accept and process a redirect message, but must
instead relay the redirect message to the appropriate Client.
The permissible data flow paths for tunneled packets that flow
through a Server are therefore:
o From a connected Client to another connected Client (i.e., a
hairpin route)
o From a connected Client to a default Relay router
o From a foreign Client to a connected Client
o From a default Relay router to a connected Client
6.3. IRON Relay Operation
After each Relay has synchronized its VPs (see Section 5.3) it
advertises them in the IPv4 and IPv6 Internet BGP routing systems.
These prefixes will be represented as ordinary routing information in
the BGP, and any packets originating from the IPv4 or IPv6 Internet
destined to an address covered by one of the prefixes will be
forwarded to one of the VSP's Relays.
When a Relay receives a packet from the Internet destined to an EPA
covered by one of its VPs, it behaves as an ordinary IP router. In
particular, the Relay looks in its FIB to discover a locator of a
Server that serves the EP covering the destination address. The
Relay then simply encapsulates the packet with its own locator as the
outer source address and the locator of the Server as the outer
destination address and forwards the packet to the Server.
When a Relay receives a packet from a Server destined to an EPA
covered by an EP serviced by a different Server, the Relay forwards
the packet to the correct Server and initiates a redirection
procedure. The procedure used is termed "Asymmetric Extended Route
Optimization" [AERO], which both establishes the necessary ingress
filtering state in the target Server and conveys a better next hop to
the source Client.
Templin Expires February 20, 2012 [Page 17]
Internet-Draft IRON August 2011
7. IRON Reference Operating Scenarios
IRON supports communications when one or both hosts are located
within EP-addressed EUNs. The following sections discuss the
reference operating scenarios.
7.1. Both Hosts within Same IRON Instance
When both hosts are within EUNs served by the same IRON instance, it
is sufficient to consider the scenario in a unidirectional fashion,
i.e., by tracing packet flows only in the forward direction from
source host to destination host. The reverse direction can be
considered separately and incurs the same considerations as for the
forward direction. The simplest case occurs when the EUNs that
service the source and destination hosts are connected to the same
server, while the general case occurs when the EUNs are connected to
different Servers. The two cases are discussed in the following
sections.
7.1.1. EUNs Served by Same Server
In this scenario, the packet flow from the source host is forwarded
through the EUN to the source's Client. The Client then tunnels the
packets to the Server, which simply re-encapsulates and forwards the
tunneled packets to the destination's Client. The destination's
Client then removes the packets from the tunnel and forwards them
over the EUN to the destination. Figure 6 depicts the sustained flow
of packets from Host A to Host B within EUNs serviced by the same
Server(S) via a "hairpinned" route:
Templin Expires February 20, 2012 [Page 18]
Internet-Draft IRON August 2011
________________________________________
.-( )-.
.-( )-.
.-( )-.
.( ).
.( ).
.( +------------+ ).
( +===================>| Server(S) |=====================+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
((_|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ +-----+-----+ )
| Client(A) | | Client(B) |
+-----+-----+ VSP IRON Instance +-----+-----+
^ | ( (Overlaid on the Native Internet) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+
Figure 6: Sustained Packet Flow via Hairpinned Route
With reference to Figure 6, Host A sends packets destined to Host B
via its network interface connected to EUN A. Routing within EUN A
will direct the packets to Client(A) as a default router for the EUN,
which then uses VET and SEAL to encapsulate them in outer headers
with its locator address as the outer source address, the locator
address of Server(S) as the outer destination address, and the NBR_ID
parameters associated with its tunnel-neighbor state as the identity.
Client(A) then simply forwards the encapsulated packets into its ISP
network connection that provided its locator. The ISP will forward
the encapsulated packets into the Internet without filtering since
the (outer) source address is topologically correct. Once the
packets have been forwarded into the Internet, routing will direct
them to Server(S).
Server(S) will receive the encapsulated packets from Client(A) then
check its FIB to discover an entry that covers destination address B
with Client(B) as the next hop. Server(S) then re-encapsulates the
Templin Expires February 20, 2012 [Page 19]
Internet-Draft IRON August 2011
packets in a new outer header that uses the source address,
destination address, and NBR_ID parameters associated with the
tunnel-neighbor state for Client(B). Server(S) then forwards these
re-encapsulated packets into the Internet, where routing will direct
them to Client(B). Client(B) will, in turn, decapsulate the packets
and forward the inner packets to Host B via EUN B.
7.1.2. EUNs Served by Different Servers
In this scenario, the initial packets of a flow produced by a source
host within an EUN connected to the IRON instance by a Client must
flow through both the Server of the source host and a nearby Relay,
but route optimization can eliminate these elements from the path for
subsequent packets in the flow. Figure 7 shows the flow of initial
packets from Host A to Host B within EUNs of the same IRON instance:
________________________________________
.-( )-.
.-( +------------+ )-.
.-( +======>| Relay(R) |=======+ )-.
.( || +*-----------+ || ).
.( || * vv ).
.( +--------++--+* +--++--------+ ).
( +==>| Server(A) *| | Server(B) |====+ )
( // +----------*-+ +------------+ \\ )
( // .-. * .-. \\ )
( //,-( _)-. * ,-( _)-\\ )
( .||_ (_ )-. * .-(_ (_ ||. )
((_|| ISP A .) * (__ ISP B ||_))
( ||-(______)-' * `-(______)|| )
( || | * | vv )
( +-----+-----+ * +-----+-----+ )
| Client(A) |<* | Client(B) |
+-----+-----+ VSP IRON Instance +-----+-----+
^ | ( (Overlaid on the Native Internet) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ ****> == Redirect +--------+
Figure 7: Initial Packet Flow Before Redirects
With reference to Figure 7, Host A sends packets destined to Host B
Templin Expires February 20, 2012 [Page 20]
Internet-Draft IRON August 2011
via its network interface connected to EUN A. Routing within EUN A
will direct the packets to Client(A) as a default router for the EUN,
which then encapsulates them in outer headers and forwards the
encapsulated packets into the ISP network connection that provided
its locator. The ISP will forward the encapsulated packets into the
Internet, where routing will direct them to Server(A).
Server(A) receives the encapsulated packets from Client(A) and
consults its FIB to determine that the most-specific matching route
is "default" with Relay(R) as the next hop. Server(A) then re-
encapsulates the packets and forwards them into the Internet where
routing will direct them to Relay(R).
Relay(R) receives the encapsulated packets from Server(A) then checks
its FIB to discover an entry that covers inner destination address B
with Server(B) as the next hop. Relay(R) then returns redirect
messages to Server(A), which forwards (or, "proxies") the redirects
to Client(A). Relay(R) finally re-encapsulates the packets and
forwards them to Server(B).
Server(B) receives the encapsulated packets from Relay(R) then checks
its FIB to discover an entry that covers destination address B with
Client(B) as the next hop. Server(B) then re-encapsulates the
packets in a new outer header that uses the source address,
destination address, and NBR_ID parameters associated with the
tunnel-neighbor state for Client(B). Server(B) then forwards these
re-encapsulated packets into the Internet, where routing will direct
them to Client(B). Client(B) will, in turn, decapsulate the packets
and forward the inner packets to Host B via EUN B.
After the initial flow of packets, Server(A) will have received one
or more redirect messages from Relay(R) listing Server(B) as a better
next hop. Server(A) will, in turn, proxy the redirects to Client(A),
which will establish unidirectional tunnel-neighbor state listing
Server(B) as the next hop toward the EP that covers Host B. Client(A)
thereafter forwards its encapsulated packets directly to the locator
address of Server(B) without involving either Server(A) or Relay(B),
as shown in Figure 8.
Templin Expires February 20, 2012 [Page 21]
Internet-Draft IRON August 2011
________________________________________
.-( )-.
.-( )-.
.-( )-.
.( ).
.( ).
.( +------------+ ).
( +====================================>| Server(B) |====+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
((_|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ +-----+-----+ )
| Client(A) | | Client(B) |
+-----+-----+ IRON Instance +-----+-----+
^ | ( (Overlaid on the Native Internet) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+
Figure 8: Sustained Packet Flow After Redirects
7.2. Mixed IRON and Non-IRON Hosts
The cases in which one host is within an IRON EUN and the other is in
a non-IRON EUN (i.e., one that connects to the native Internet
instead of the IRON) are described in the following sub-sections.
7.2.1. From IRON Host A to Non-IRON Host B
Figure 9 depicts the IRON reference operating scenario for packets
flowing from Host A in an IRON EUN to Host B in a non-IRON EUN.
Templin Expires February 20, 2012 [Page 22]
Internet-Draft IRON August 2011
_________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |--------------------------+ )-.
.( +------------+ \ ).
.( +=======>| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // IRON ) \ )
( // .-. Instance ) .-. \ )
( //,-( _)-. ) ,-( _)-. \ )
( .||_ (_ )-. ) The Native Internet .- _ (_ )-| )
( _|| ISP A ) ) (_ ISP B |))
( ||-(______)-' ) `-(______)-' | )
( || | )-. | v )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router(B) |
+-----+-----+ +-----+-----+
^ | ( ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (non-IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+
Figure 9: From IRON Host A to Non-IRON Host B
In this scenario, Host A sends packets destined to Host B via its
network interface connected to IRON EUN A. Routing within EUN A will
direct the packets to Client(A) as a default router for the EUN,
which then encapsulates them and sends them into the ISP network.
The ISP will pass the packets without filtering since the (outer)
source address is topologically correct. Once the packets have been
released into the native Internet, the Internet routing system will
direct them to Server(A).
Server(A) receives the encapsulated packets from Client(A) then re-
encapsulates and forwards them to Relay(A), which simply decapsulates
them and forwards the unencapsulated packets into the Internet. Once
the packets are released into the Internet, routing will direct them
to the final destination B. (Note that Server(A) and Relay(A) are
depicted in Figure 9 as two halves of a unified gateway. In that
case, the "forwarding" between Server(A) and Relay(A) is a zero-
instruction imaginary operation within the gateway.)
Templin Expires February 20, 2012 [Page 23]
Internet-Draft IRON August 2011
7.2.2. From Non-IRON Host B to IRON Host A
Figure 10 depicts the IRON reference operating scenario for packets
flowing from Host B in an Non-IRON EUN to Host A in an IRON EUN.
_________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |<-------------------------+ )-.
.( +------------+ \ ).
.( +========| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // IRON ) \ )
( // .-. Instance ) .-. \ )
( //,-( _)-. ) ,-( _)-. \ )
( .||_ (_ )-. ) The Native Internet .- _ (_ )-| )
( _|| ISP A ) ) (_ ISP B |))
( ||-(______)-' ) `-(______)-' | )
( vv | )-. | | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router(B) |
+-----+-----+ +-----+-----+
| | ( ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (Non-IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+>| Host A | <===> == Tunnel | Host B |-+
+--------+ +--------+
Figure 10: From Non-IRON Host B to IRON Host A
In this scenario, Host B sends packets destined to Host A via its
network interface connected to non-IRON EUN B. Internet routing will
direct the packets to Relay(A), which then forwards them to Server(A)
using encapsulation if necessary.
Server(A) will then check its FIB to discover an entry that covers
destination address A with Client(A) as the next hop. Server(A) then
(re-)encapsulates the packets in an outer header that uses the source
address, destination address, and NBR_ID parameters associated with
the tunnel-neighbor state for Client(A). Next, Server(A) forwards
these (re-)encapsulated packets into the Internet, where routing will
direct them to Client(A). Client(A) will, in turn, decapsulate the
Templin Expires February 20, 2012 [Page 24]
Internet-Draft IRON August 2011
packets and forward the inner packets to Host A via its network
interface connected to IRON EUN A.
7.3. Hosts within Different IRON Instances
Figure 11 depicts the IRON reference operating scenario for packets
flowing between Host A in an IRON instance A and Host B in a
different IRON instance B. In that case, forwarding between hosts A
and B always involves the Servers and Relays of both IRON instances,
i.e., the scenario is no different than if one of the hosts was
serviced by an IRON EUN and the other was serviced by a non-IRON EUN.
_________________________________________
.-( )-. .-( )-.
.-( +-------)----+ +---(--------+ )-.
.-( | Relay(A) | <---> | Relay(B) | )-.
.( +------------+ +------------+ ).
.( +=======>| Server(A) | | Server(B) |<======+ ).
.( // +--------)---+ +---(--------+ \\ ).
( // ) ( \\ )
( // IRON ) ( IRON \\ )
( // .-. Instance A ) ( Instance B .-. \\ )
( //,-( _)-. ) ( ,-( _). || )
( .||_ (_ )-. ) ( .-'_ (_ )|| )
( _|| ISP A ) ) ( (_ ISP B ||))
( ||-(______)-' ) ( '-(______)-|| )
( vv | )-. .-( | vv )
( +-----+ ----+ )-. .-( +-----+-----+ )
| Client(A) |)-. .-(| Client(B) |
+-----+-----+ The Native Internet +-----+-----+
^ | ( ) | ^
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+>| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+
Figure 11: Hosts within Different IRON Instances
8. Mobility, Multiple Interfaces, Multihoming, and Traffic Engineering
While IRON Servers and Relays can be considered as fixed
infrastructure, Clients may need to move between different network
points of attachment, connect to multiple ISPs, or explicitly manage
Templin Expires February 20, 2012 [Page 25]
Internet-Draft IRON August 2011
their traffic flows. The following sections discuss mobility,
multihoming, and traffic engineering considerations for IRON Client
routers.
8.1. Mobility Management and Mobile Networks
When a Client changes its network point of attachment (e.g., due to a
mobility event), it configures one or more new locators. If the
Client has not moved far away from its previous network point of
attachment, it simply informs its Server of any locator additions or
deletions. This operation is performance sensitive and should be
conducted immediately to avoid packet loss. This form of mobility
can be classified as a "localized mobility event".
If the Client has moved far away from its previous network point of
attachment, however, it re-issues the Server discovery procedure
described in Section 5.3 to discover whether its candidate set of
Servers has changed. If the Client's current Server is also included
in the new list received from the VSP, this provides indication that
the Client has not moved far enough to warrant changing to a new
Server. Otherwise, the Client may wish to move to a new Server in
order to reduce routing stretch. This operation is not performance
critical, and therefore can be conducted over a matter of seconds/
minutes instead of milliseconds/microseconds. This form of mobility
can be classified as a "global mobility event".
To move to a new Server, the Client first engages in the EP
registration process with the new Server, as described in Section
5.3. The Client then informs its former Server that it has departed;
again, via a VSP-specific secured reliable transport connection. The
former Server will then withdraw its EP advertisements from the VSP
routing system and retain the (stale) FIB entries until their
lifetime expires. In the interim, the former Server continues to
deliver packets to the Client's last-known locator addresses for the
short term while informing any unidirectional tunnel-neighbors that
the Client has moved.
Note that the Client may be either a mobile host or a mobile router.
In the case of a mobile router, the Client's EUN becomes a mobile
network, and can continue to use the Client's EPs without renumbering
even as it moves between different network attachment points.
8.2. Multiple Interfaces and Multihoming
A Client may register multiple ISP connections with each Server.
Therefore, multiple interfaces are naturally supported. This feature
results in the Client considering its multiple ISP connections as a
"bundle" of interfaces that are represented as a single entity at the
Templin Expires February 20, 2012 [Page 26]
Internet-Draft IRON August 2011
network layer, and therefore allows for ISP independence at the link-
layer.
A Client may further register with multiple Servers for fault
tolerance and reduced routing stretch. In that case, the Client
should register each of its ISP connections with each of its Servers
unless it has a way of carefully coordinating its ISP-to-Server
mappings. (However, unpredictable performance may result if the
Client registers only preferred ISP connections with Server A and
backup ISP connections with Server B.)
Client registration with multiple Servers results in "pseudo-
multihoming", in which the multiple homes are within the same VSP
IRON instance and hence share fate with the health of the IRON
instance itself.
8.3. Traffic Engineering
A Client can dynamically adjust the priorities of its ISP
registrations with its Server in order to influence inbound traffic
flows. It can also change between Servers when multiple Servers are
available, but should strive for stability in its Server selection in
order to limit VSP network routing churn.
A Client can select outgoing ISPs, e.g., based on current Quality-of-
Service (QoS) considerations such as minimizing delay or variance.
9. Renumbering Considerations
As new link-layer technologies and/or service models emerge,
customers will be motivated to select their service providers through
healthy competition between ISPs. If a customer's EUN addresses are
tied to a specific ISP, however, the customer may be forced to
undergo a painstaking EUN renumbering process if it wishes to change
to a different ISP [RFC4192][RFC5887].
When a customer obtains EPs from a VSP, it can change between ISPs
seamlessly and without need to renumber. IRON therefore provides ISP
independence at the link layer. If the VSP itself applies
unreasonable costing structures for use of the EPs, however, the
customer may be compelled to seek a different VSP and would again be
required to engage in a network layer renumbering event.
10. NAT Traversal Considerations
The Internet today consists of a global public IPv4 routing and
Templin Expires February 20, 2012 [Page 27]
Internet-Draft IRON August 2011
addressing system with non-IRON EUNs that use either public or
private IPv4 addressing. The latter class of EUNs connect to the
public Internet via Network Address Translators (NATs). When a
Client is located behind a NAT, it selects Servers using the same
procedures as for Clients with public addresses and can then send SRS
messages to Servers in order to get SRA messages in return. The only
requirement is that the Client must configure its SEAL encapsulation
to use a transport protocol that supports NAT traversal, e.g., UDP,
TCP, SSL, etc.
Since the Server maintains state about its connected Clients, it can
discover locator information for each Client by examining the
transport port number and IP address in the outer headers of the
Client's encapsulated packets. When there is a NAT in the path, the
transport port number and IP address in each encapsulated packet will
correspond to state in the NAT box and might not correspond to the
actual values assigned to the Client. The Server can then
encapsulate packets destined to hosts in the Client's EUN within
outer headers that use this IP address and transport port number.
The NAT box will receive the packets, translate the values in the
outer headers, then forward the packets to the Client. In this
sense, the Server's "locator" for the Client consists of the
concatenation of the IP address and transport port number.
In order to keep NAT and Server connection state alive, the Client
sends periodic beacons to the server, e.g., by sending an SRS message
to elicit an SRA message from the Server. IRON does not otherwise
introduce any new issues to complications raised for NAT traversal or
for applications embedding address referrals in their payload.
11. Multicast Considerations
IRON Servers and Relays are topologically positioned to provide
Internet Group Management Protocol (IGMP) / Multicast Listener
Discovery (MLD) proxying for their Clients [RFC4605]. Further
multicast considerations for IRON (e.g., interactions with multicast
routing protocols, traffic scaling, etc.) are out of scope and will
be discussed in a future document.
12. Nested EUN Considerations
Each Client configures a locator that may be taken from an ordinary
non-EPA address assigned by an ISP or from an EPA address taken from
an EP assigned to another Client. In that case, the Client is said
to be "nested" within the EUN of another Client, and recursive
nestings of multiple layers of encapsulations may be necessary.
Templin Expires February 20, 2012 [Page 28]
Internet-Draft IRON August 2011
For example, in the network scenario depicted in Figure 12, Client(A)
configures a locator EPA(B) taken from the EP assigned to EUN(B).
Client(B) in turn configures a locator EPA(C) taken from the EP
assigned to EUN(C). Finally, Client(C) configures a locator ISP(D)
taken from a non-EPA address delegated by an ordinary ISP(D). Using
this example, the "nested-IRON" case must be examined in which a Host
A, which configures the address EPA(A) within EUN(A), exchanges
packets with Host Z located elsewhere in the Internet.
.-.
ISP(D) ,-( _)-.
+-----------+ .-(_ (_ )-.
| Client(C) |--(_ ISP(D) )
+-----+-----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN(C) ) e `-(______)-'
`-(______)-' l ___
| EPA(C) s => (:::)-.
+-----+-----+ .-(::::::::)
| Client(B) | .-(::: IRON :::)-. +-----------+
+-----+-----+ (:::: Instance ::::) | Relay(Z) |
| `-(::::::::::::)-' +-----------+
.-. `-(::::::)-' +-----------+
,-( _)-. | Server(Z) |
.-(_ (_ )-. +-----------+ +-----------+
(_ EUN(B) ) | Server(C) | +-----------+
`-(______)-' +-----------+ | Client(Z) |
| EPA(B) +-----------+ +-----------+
+-----+-----+ | Server(B) | +--------+
| Client(A) | +-----------+ | Host Z |
+-----------+ +-----------+ +--------+
| | Server(A) |
.-. +-----------+
,-( _)-. EPA(A)
.-(_ (_ )-. +--------+
(_ EUN(A) )---| Host A |
`-(______)-' +--------+
Figure 12: Nested EUN Example
The two cases of Host A sending packets to Host Z, and Host Z sending
packets to Host A, must be considered separately, as described below.
Templin Expires February 20, 2012 [Page 29]
Internet-Draft IRON August 2011
12.1. Host A Sends Packets to Host Z
Host A first forwards a packet with source address EPA(A) and
destination address Z into EUN(A). Routing within EUN(A) will direct
the packet to Client(A), which encapsulates it in an outer header
with EPA(B) as the outer source address and Server(A) as the outer
destination address then forwards the once-encapsulated packet into
EUN(B). Routing within EUN(B) will direct the packet to Client(B),
which encapsulates it in an outer header with EPA(C) as the outer
source address and Server(B) as the outer destination address then
forwards the twice-encapsulated packet into EUN(C). Routing within
EUN(C) will direct the packet to Client(C), which encapsulates it in
an outer header with ISP(D) as the outer source address and Server(C)
as the outer destination address. Client(C) then sends this triple-
encapsulated packet into the ISP(D) network, where it will be routed
into the Internet to Server(C).
When Server(C) receives the triple-encapsulated packet, it removes
the outer layer of encapsulation and forwards the resulting twice-
encapsulated packet into the Internet to Server(B). Next, Server(B)
removes the outer layer of encapsulation and forwards the resulting
once-encapsulated packet into the Internet to Server(A). Next,
Server(A) checks the address type of the inner address 'Z'. If Z is
a non-EPA address, Server(A) simply decapsulates the packet and
forwards it into the Internet. Otherwise, Server(A) rewrites the
outer source and destination addresses of the once-encapsulated
packet and forwards it to Relay(Z). Relay(Z), in turn, rewrites the
outer destination address of the packet to the locator for Server(Z),
then forwards the packet and sends a redirect to Server(A) (which
forwards the redirect to Client(A)). Server(Z) then re-encapsulates
the packet and forwards it to Client(Z), which decapsulates it and
forwards the inner packet to Host Z. Subsequent packets from
Client(A) will then use Server(Z) as the next hop toward Host Z,
which eliminates Server(A) and Relay(Z) from the path.
12.2. Host Z Sends Packets to Host A
Whether or not Host Z configures an EPA address, its packets destined
to Host A will eventually reach Server(A). Server(A) will have a
mapping that lists Client(A) as the next hop toward EPA(A).
Server(A) will then encapsulate the packet with EPA(B) as the outer
destination address and forward the packet into the Internet.
Internet routing will convey this once-encapsulated packet to
Server(B), which will have a mapping that lists Client(B) as the next
hop toward EPA(B). Server(B) will then encapsulate the packet with
EPA(C) as the outer destination address and forward the packet into
the Internet. Internet routing will then convey this twice-
encapsulated packet to Server(C), which will have a mapping that
Templin Expires February 20, 2012 [Page 30]
Internet-Draft IRON August 2011
lists Client(C) as the next hop toward EPA(C). Server(C) will then
encapsulate the packet with ISP(D) as the outer destination address
and forward the packet into the Internet. Internet routing will then
convey this triple-encapsulated packet to Client(C).
When the triple-encapsulated packet arrives at Client(C), it strips
the outer layer of encapsulation and forwards the twice-encapsulated
packet to EPA(C), which is the locator address of Client(B). When
Client(B) receives the twice-encapsulated packet, it strips the outer
layer of encapsulation and forwards the once-encapsulated packet to
EPA(B), which is the locator address of Client(A). When Client(A)
receives the once-encapsulated packet, it strips the outer layer of
encapsulation and forwards the unencapsulated packet to EPA(A), which
is the host address of Host A.
13. Implications for the Internet
The IRON architecture envisions a hybrid routing/mapping system that
benefits from both the shortest-path routing afforded by pure dynamic
routing systems and the routing-scaling suppression afforded by pure
mapping systems. Therefore, IRON targets the elusive "sweet spot"
that pure routing and pure mapping systems alone cannot satisfy.
The IRON system requires a VSP deployment of new routers/servers
throughout the Internet to maintain well-balanced virtual overlay
networks. These routers/servers can be deployed incrementally
without disruption to existing Internet infrastructure and
appropriately managed to provide acceptable service levels to
customers.
End-to-end traffic that traverses an IRON instance may experience
delay variance between the initial packets and subsequent packets of
a flow. This is due to the IRON system allowing a longer path
stretch for initial packets followed by timely route optimizations to
utilize better next hop routers/servers for subsequent packets.
IRON instances work seamlessly with existing and emerging services
within the native Internet. In particular, customers serviced by an
IRON instance will receive the same service enjoyed by customers
serviced by non-IRON service providers. Internet services already
deployed within the native Internet also need not make any changes to
accommodate VSP customers.
The IRON system operates between IAs within provider networks and end
user networks. Within these networks, the underlying paths traversed
by the virtual overlay networks may comprise links that accommodate
varying MTUs. While the IRON system imposes an additional per-packet
Templin Expires February 20, 2012 [Page 31]
Internet-Draft IRON August 2011
overhead that may cause the size of packets to become slightly larger
than the underlying path can accommodate, IAs have a method for
naturally detecting and tuning out instances of path MTU underruns.
In some cases, these MTU underruns may need to be reported back to
the original hosts; however, the system will also allow for MTUs much
larger than those typically available in current Internet paths to be
discovered and utilized as more links with larger MTUs are deployed.
Finally, and perhaps most importantly, the IRON system provides in-
built mobility management, mobile networks, multihoming and traffic
engineering capabilities that allow end user devices and networks to
move about freely while both imparting minimal oscillations in the
routing system and maintaining generally shortest-path routes. This
mobility management is afforded through the very nature of the IRON
customer/provider relationship, and therefore requires no adjunct
mechanisms. The mobility management and multihoming capabilities are
further supported by forward-path reachability detection that
provides "hints of forward progress" in the same spirit as for IPv6
Neighbor Discovery (ND).
14. Additional Considerations
Considerations for the scalability of Internet Routing due to
multihoming, traffic engineering, and provider-independent addressing
are discussed in [RADIR]. Other scaling considerations specific to
IRON are discussed in Appendix B.
Route optimization considerations for mobile networks are found in
[RFC5522].
In order to ensure acceptable customer service levels, the VSP should
conduct a traffic scaling analysis and distribute sufficient Relays
and Servers for the IRON instance globally throughout the Internet.
15. Related Initiatives
IRON builds upon the concepts of the RANGER architecture [RFC5720] ,
and therefore inherits the same set of related initiatives. The
Internet Research Task Force (IRTF) Routing Research Group (RRG)
mentions IRON in its recommendation for a routing architecture
[RFC6115].
Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing
Scopes (AIS) [EVOLUTION] provide the basis for the Virtual Prefix
concepts.
Templin Expires February 20, 2012 [Page 32]
Internet-Draft IRON August 2011
Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH] has contributed
valuable insights, including the use of real-time mapping. The use
of Servers as mobility anchor points is directly influenced by Ivip's
associated TTR mobility extensions [TTRMOB].
[RO-CR] discusses a route optimization approach using a Correspondent
Router (CR) model. The IRON Server construct is similar to the CR
concept described in this work; however, the manner in which Clients
coordinate with Servers is different and based on the redirection
model associated with NBMA links [RFC5214].
Numerous publications have proposed NAT traversal techniques. The
NAT traversal techniques adapted for IRON were inspired by the Simple
Address Mapping for Premises Legacy Equipment (SAMPLE) proposal
[SAMPLE].
The IRON Client-Server relationship is managed in essentially the
same way as for the Tunnel Broker model [RFC3053]. Numerous existing
tunnel broker provider networks (e.g., Hurricane Electric, SixXS,
freenet6, etc.) provide existence proofs that IRON-like overlay
network services can be deployed and managed on a global basis
[BROKER].
16. Security Considerations
Security considerations that apply to tunneling in general are
discussed in [RFC6169]. Additional considerations that apply also to
IRON are discussed in RANGER [RFC5720] , VET [INTAREA-VET] and SEAL
[INTAREA-SEAL].
The IRON system further depends on mutual authentication of IRON
Clients to Servers and Servers to Relays. This is accomplished
through initial authentication exchanges that establish tunnel-
neighbor NBR_ID values that can be used to detect off-path attacks.
As for all Internet communications, the IRON system also depends on
Relays acting with integrity and not injecting false advertisements
into the BGP (e.g., to mount traffic siphoning attacks).
IRON Servers must ensure that any changes in a Client's locator
addresses are communicated only through an authenticated exchange
that is not subject to replay. For this reason, Clients periodically
send digitally-signed SRS messages to the Server. If the Client's
locator address stays the same, the Server can accept the SRS message
without verifying the signature as long as the NBR_ID of the SRS
matches the Client. If the Client's locator address changes, the
Server must verify the SRS message's signature before accepting the
message. Once the message has been authenticated, the Server updates
Templin Expires February 20, 2012 [Page 33]
Internet-Draft IRON August 2011
the Client's locator address to the new address.
Each IRON instance requires a means for assuring the integrity of the
interior routing system so that all Relays and Servers in the overlay
have a consistent view of Client<->Server bindings. Finally, Denial-
of-Service (DoS) attacks on IRON Relays and Servers can occur when
packets with spoofed source addresses arrive at high data rates.
However, this issue is no different than for any border router in the
public Internet today.
Middleboxes can interfere with tunneled packets within an IRON
instance in various ways. For example, a middlebox may alter a
packet's contents, change a packet's locator addresses, inject
spurious packets, replay old packets, etc. These issues are no
different than for middlebox interactions with ordinary Internet
communications. If man-in-the-middle attacks are a matter for
concern in certain deployments, however, IRON Agents can use IPsec to
protect the authenticity, integrity and (if necessary) privacy of
their tunneled packets.
17. Acknowledgements
The ideas behind this work have benefited greatly from discussions
with colleagues; some of which appear on the RRG and other IRTF/IETF
mailing lists. Robin Whittle and Steve Russert co-authored the TTR
mobility architecture, which strongly influenced IRON. Eric
Fleischman pointed out the opportunity to leverage anycast for
discovering topologically close Servers. Thomas Henderson
recommended a quantitative analysis of scaling properties.
The following individuals provided essential review input: Jari
Arkko, Mohamed Boucadair, Stewart Bryant, John Buford, Ralph Droms,
Wesley Eddy, Adrian Farrel, Dae Young Kim, and Robin Whittle.
18. References
18.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Templin Expires February 20, 2012 [Page 34]
Internet-Draft IRON August 2011
18.2. Informative References
[AERO] Templin, F., Ed., "Asymmetric Extended Route Optimization
(AERO)", Work in Progress, June 2011.
[BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes,
http://bgpmon.net/stat.php", June 2010.
[BROKER] Wikipedia, W., "List of IPv6 Tunnel Brokers,
http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers",
August 2011.
[EVOLUTION]
Zhang, B., Zhang, L., and L. Wang, "Evolution Towards
Global Routing Scalability", Work in Progress,
October 2009.
[GROW-VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation", Work
in Progress, February 2011.
[INTAREA-SEAL]
Templin, F., Ed., "The Subnetwork Encapsulation and
Adaptation Layer (SEAL)", Work in Progress, February 2011.
[INTAREA-VET]
Templin, F., Ed., "Virtual Enterprise Traversal (VET)",
Work in Progress, January 2011.
[IVIP-ARCH]
Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
Architecture", Work in Progress, March 2010.
[RADIR] Narten, T., "On the Scalability of Internet Routing", Work
in Progress, February 2010.
[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as
a subnetwork for experimentation with the OSI network
layer", RFC 1070, February 1989.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996.
Templin Expires February 20, 2012 [Page 35]
Internet-Draft IRON August 2011
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code
Point (ICP) Assignments for NSAP Addresses", RFC 4548,
May 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
Route Optimization Requirements for Operational Use in
Aeronautics and Space Exploration Mobile Networks",
RFC 5522, October 2009.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
February 2010.
[RFC5743] Falk, A., "Definition of an Internet Research Task Force
(IRTF) Document Stream", RFC 5743, December 2009.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[RFC6115] Li, T., "Recommendation for a Routing Architecture",
RFC 6115, February 2011.
[RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and
Addressing in Networks with Global Enterprise Recursion
(RANGER) Scenarios", RFC 6139, February 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.
Templin Expires February 20, 2012 [Page 36]
Internet-Draft IRON August 2011
[RO-CR] Bernardos, C., Calderon, M., and I. Soto, "Correspondent
Router based Route Optimisation for NEMO (CRON)", Work
in Progress, July 2008.
[SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for
IPv6: Simple Address Mapping for Premises Legacy Equipment
(SAMPLE)", Work in Progress, June 2010.
[TTRMOB] Whittle, R. and S. Russert, "TTR Mobility Extensions for
Core-Edge Separation Solutions to the Internet's Routing
Scaling Problem,
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf",
August 2008.
Appendix A. IRON VPs over Internetworks with Different Address Families
The IRON architecture leverages the routing system by providing
generally shortest-path routing for packets with EPA addresses from
VPs that match the address family of the underlying Internetwork.
When the VPs are of an address family that is not routable within the
underlying Internetwork, however, (e.g., when OSI/NSAP [RFC4548] VPs
are used within an IPv4 Internetwork) a global VP mapping database is
required. The mapping database allows the Relays of the local IRON
instance to map VPs belonging to other IRON instances to companion
prefixes taken from address families that are routable within the
Internetwork. For example, an IPv6 VP (e.g., 2001:DB8::/32) could be
paired with a companion IPv4 prefix (e.g., 192.0.2.0/24) so that
encapsulated IPv6 packets can be forwarded over IPv4-only
Internetworks.
In that case, every VP must be represented in a globally distributed
Master VP database (MVPd) that maintains VP-to-companion prefix
mappings for all VPs in the IRON. The MVPd is maintained by a
globally managed assigned numbers authority in the same manner as the
Internet Assigned Numbers Authority (IANA) currently maintains the
master list of all top-level IPv4 and IPv6 delegations. The database
can be replicated across multiple servers for load balancing, much in
the same way that FTP mirror sites are used to manage software
distributions.
Upon startup, each Relay advertises an IPv4 companion prefix (e.g.,
192.0.2.0/24) into the internetwork IPv4 routing system and/or an
IPv6 companion prefix (e.g., 2001:DB8::/64) into the internetwork
IPv6 routing system for the IRON instance that it serves. The Relay
then configures the host number '1' in the IPv4 companion prefix
(e.g., as 192.0.2.1) and the interface identifier '0' in the IPv6
companion prefix (e.g., as 2001:DB8::0), and assigns the resulting
addresses as "Relay anycast" addresses for the IRON instance.
Templin Expires February 20, 2012 [Page 37]
Internet-Draft IRON August 2011
The Relay then discovers the full set of VPs for all other IRON
instances by reading the MVPd. The Relay reads the MVPd from a
nearby server and periodically checks the server for deltas since the
database was last read. After reading the MVPd, the Relay has a full
list of VP-to-companion prefix mappings. The Relay can then forward
packets toward EPAs belonging to other IRON instances by
encapsulating them in an outer header of the companion prefix address
family and using the Relay anycast address as the outer destination
address.
Possible encapsulations in this model include IPv6-in-IPv4, IPv4-in-
IPv6, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.
Appendix B. Scaling Considerations
Scaling aspects of the IRON architecture have strong implications for
its applicability in practical deployments. Scaling must be
considered along multiple vectors, including Interdomain core routing
scaling, scaling to accommodate large numbers of customer EUNs,
traffic scaling, state requirements, etc.
In terms of routing scaling, each VSP will advertise one or more VPs
into the global Internet routing system from which EPs are delegated
to customer EUNs. Routing scaling will therefore be minimized when
each VP covers many EPs. For example, the IPv6 prefix 2001:DB8::/32
contains 2^24 ::/56 EP prefixes for assignment to EUNs; therefore,
the IRON could accommodate 2^32 ::/56 EPs with only 2^8 ::/32 VPs
advertised in the interdomain routing core. (When even longer EP
prefixes are used, e.g., /64s assigned to individual handsets in a
cellular provider network, considerable numbers of EUNs can be
represented within only a single VP.)
In terms of traffic scaling for Relays, each Relay represents an ASBR
of a "shell" enterprise network that simply directs arriving traffic
packets with EPA destination addresses towards Servers that service
customer EUNs. Moreover, the Relay sheds traffic destined to EPAs
through redirection, which removes it from the path for the majority
of traffic packets between Clients within the same IRON instance. On
the other hand, each Relay must handle all traffic packets forwarded
between its customer EUNs and the non-IRON Internet. The scaling
concerns for this latter class of traffic are no different than for
ASBR routers that connect large enterprise networks to the Internet.
In terms of traffic scaling for Servers, each Server services a set
of the VSP customer EUNs. The Server services all traffic packets
destined to its EUNs but only services the initial packets of flows
initiated from the EUNs and destined to EPAs. Therefore, traffic
scaling for EPA-addressed traffic is an asymmetric consideration and
is proportional to the number of EUNs each Server serves.
Templin Expires February 20, 2012 [Page 38]
Internet-Draft IRON August 2011
In terms of state requirements for Relays, each Relay maintains a
list of all Servers in the IRON instance as well as FIB entries for
all customer EUNs that each Server serves. This state is therefore
dominated by the number of EUNs in the IRON instance. Sizing the
Relay to accommodate state information for all EUNs is therefore
required during overlay network planning. In terms of state
requirements for Servers, each Server maintains state only for the
customer EUNs it serves, and not for the customers served by other
Servers in the IRON instance. Finally, neither Relays nor Servers
need keep state for final destinations of outbound traffic.
Clients source and sink all traffic packets originating from or
destined to the customer EUN. Therefore, traffic scaling
considerations for Clients are the same as for any site border
router. Clients also retain unidirectional tunnel-neighbor state for
the Servers for final destinations of outbound traffic flows. This
can be managed as soft state, since stale entries purged from the
cache will be refreshed when new traffic packets are sent.
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 February 20, 2012 [Page 39]