IRON Applicability for Multiple Interface
NodesBoeing Research & TechnologyP.O. Box 3707 MC 7L-49SeattleWA98124USAfltemplin@acm.orgNetwork Working GroupI-DInternet-DraftThe Internet Routing Overlay Network (IRON) is a new internetworking
and routing architecture that addresses important issues including
routing scaling, network renumbering, mobility management, mobile
networks, multihoming, traffic engineering, NAT traversal and security.
In this document, we focus on IRON's applicability for multiple
interface (mif) nodes.The Internet Routing Overlay Network (IRON) is a new internetworking and routing architecture
that addresses numerous important issues including routing scaling,
network renumbering, mobility management, mobile networks, multihoming,
traffic engineering, NAT traversal and security. IRON further provides a
new interface type that augments the collection of interfaces available
to a multiple interface (mif) node.Mif nodes are presented with the problem of managing a collection of
multiple interfaces; each of which connects to an Internet Service
Provider (ISP) and its respective provisioning domain . Each such ISP
interface receives a configuration that is specific to the ISP's
provisioning domain, including network-layer addresses and prefixes, DNS
server addresses, etc. In operational practice, the mif node may receive
overlapping provisioning information, e.g., if multiple ISPs supply the
node with configuration information from the same private addressing
plan. Moreover, each ISP interface's provisioning information may change
over time, e.g., if the node is mobile. It is therefore essential that
the mif node select the correct interface for communications with
services within a specific ISP provisioning domain and/or with
correspondents in the global Internet.In this document, we focus on IRON's applicability for mif nodes with
these ISP interface characteristics. We show that IRON presents a new
interface type that complements the mif node's ISP interface collection,
i.e., the mif node need not use the IRON interface exclusively but
instead views it as "just another interface" albeit with certain
desirable properties not commonly supported by ISP interfaces. IRON
further observes the Internet Protocol (IP) standards , i.e., the same
as for ordinary ISP interfaces.The IRON interface is a non-broadcast, multiple access (NBMA) tunnel
virtual interface that is configured over one or several ISP interfaces
and coordinated with a Virtual Service Provider (VSP) server that may or
may not be independent of any of the mif node's ISPs. Example ISPs
include 3GPP and BBF providers, but the IRON domain of applicability
extends to all ISP network connection interface types. While the IRON
interface is configured over ISP interfaces, it appears to the mif node
as "just another interface" in addition to the ISP interfaces.IRON is based on Virtual Enterprise Traversal (VET) , the Subnetwork Encapsulation and
Adaptation Layer (SEAL) and
Asymmetric Extended Route Optimization as
its functional building blocks. VET defines the IRON NBMA tunnel virtual
interface model and specifies autoconfiguration and internetworking
operation over the interface (including IRON interface neighbor
coordination). SEAL specifies the encapsulation format used by the IRON
interface for deterministic error messaging as well as optional
authentication, integrity and anti-replay capabilities. Finally, AERO
specifies a route optimization capability that the mif node can use to
dynamically discover an IRON interface neighbor that is close to the
final destination.The IRON interface receives persistent provisioning domain
configuration information (including IP addresses/prefixes) from a VSP,
and uses a nearby VSP server located in the Internet as a default router
for reaching Internet correspondents. The VSP provisioning information
remains stable even if the mif node's ISP interface configurations
change. The IRON interface therefore appears as a virtual direct
connection to the Internet independent of any ISPs as shown in :The IRON interface provides the mif node with a stable
"handle" for connecting to correspondents in the Internet. Since the
IRON interface configuration remains stable even if the underlying ISP
interface configurations change, the interface supports mobility
management, multihoming and traffic engineering. However, the IRON
interface need not be used for communications between the mif node and
services within a specific ISP network, since the ISP interface itself
may be better positioned to access those services.A common mif node scenario involves a mobile device such as a handset
with both 3GPP and WiFi interfaces, where the 3GPP interface connects to
a cellular service provider and the WiFi interface connects to a
wireless network serviced by a BBF cable modem provider. In that case,
the IRON interface can provide simultaneous operation over both
underlying interfaces even if both interfaces receive overlapping IP
address and prefix information. This is due to the fact that the IRON
interface operates based on interface identifiers and not IP addresses
as the means for keeping the underlying interfaces separate.The IRON interface therefore becomes just another candidate for
interface selection the same as the ISP interfaces, and can be selected
for communications in which a stable addressing configuration is
necessary. As a result, the IRON interface is a new interface type that
should be accounted for by mif node interface selection standards.Routing and Addressing in Networks with Global Enterprise Recursion
(RANGER) examines recursive arrangements
of enterprise networks that can apply to a very broad set of use-case
scenarios . These same use-case scenarios
apply also to IRON.There are no IANA considerations for this document.Security considerations appear in the IRON, VET, SEAL and AERO
documents.This work was motivated through discussions on the IETF Multiple
Interfaces (mif) working group mailing list.Asymmetric Extended Route Optimization (AERO)Nodes (i.e., gateways, routers and hosts) attached to link
types such as multicast-capable, shared media and non-broadcast
multiple access (NBMA), etc. can exchange packets as neighbors on
the link. Each node should therefore be able to discover a
neighboring gateway that can provide default routing services to
reach off-link destinations, and should also accept redirection
messages from the gateway informing it of a neighbor that is
closer to the final destination. This redirect function can
provide a useful route optimization, since the triangular path
from the ingress link neighbor, to the gateway, and finally to the
egress link neighbor may be considerably longer than the direct
path between the neighbors. However, ordinary redirection may lead
to operational issues on certain link types and/or in certain
deployment scenarios. This document therefore introduces an
Asymmetric Extended Route Optimization (AERO) capability that
addresses the issues.The Subnetwork Encapsulation and Adaptation Layer
(SEAL)For the purpose of this document, a subnetwork is defined as a
virtual topology configured over a connected IP network routing
region and bounded by encapsulating border nodes. These virtual
topologies are manifested by tunnels that may span multiple IP
and/or sub-IP layer forwarding hops, and can introduce failure
modes due to packet duplication and/or links with diverse Maximum
Transmission Units (MTUs). This document specifies a Subnetwork
Encapsulation and Adaptation Layer (SEAL) that accommodates such
virtual topologies over diverse underlying link technologies.Virtual Enterprise Traversal (VET)Enterprise networks connect hosts and routers over various link
types, and often also connect to provider networks and/or the
global Internet. Enterprise network nodes require a means to
automatically provision addresses/prefixes and support
internetworking operation in a wide variety of use cases including
Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks
(MANETs), ISP networks, multi-organizational corporate networks
and the interdomain core of the global Internet itself. This
document specifies a Virtual Enterprise Traversal (VET)
abstraction for autoconfiguration and operation of nodes in
enterprise networks.The Internet Routing Overlay Network (IRON)