Internet DRAFT - draft-templin-mif-ironapp
draft-templin-mif-ironapp
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational January 04, 2012
Expires: July 7, 2012
IRON Applicability for Multiple Interface Nodes
draft-templin-mif-ironapp-00.txt
Abstract
The 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.
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 July 7, 2012.
Copyright Notice
Copyright (c) 2012 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
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
Templin Expires July 7, 2012 [Page 1]
Internet-Draft IRON January 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The IRON Interface . . . . . . . . . . . . . . . . . . . . . . 3
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Templin Expires July 7, 2012 [Page 2]
Internet-Draft IRON January 2012
1. Introduction
The Internet Routing Overlay Network (IRON) [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
[RFC6418][RFC6419]. 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 [RFC0791][RFC2460], i.e., the same as for ordinary ISP
interfaces.
2. The IRON Interface
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.
Templin Expires July 7, 2012 [Page 3]
Internet-Draft IRON January 2012
IRON is based on Virtual Enterprise Traversal (VET) [INTAREA-VET],
the Subnetwork Encapsulation and Adaptation Layer (SEAL)
[INTAREA-SEAL] and Asymmetric Extended Route Optimization [AERO] 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 Figure 1:
Templin Expires July 7, 2012 [Page 4]
Internet-Draft IRON January 2012
_______________
(:::::::::::::::)-.
.-(::::::::::::::::::::)
.-(::::::::::::::: VSP ::::)-.
(:::: Internet ::: Server <====)======+
^`-(:::::::::::::::::::::::)-' ||
+-------> (::::::::::::::::::) <--+ ||
| ^ | ||
| | | ||
.-. | .v. .-. | ||
,-( _'-v ,-( _)-. ,-( _)-v ||
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-. ||
(__ ISP1 _)(__ ISP2 _)(__ ISP3 _) ||
`-(__^___)-' `-(__^___)-' `-(__^___)-' ||
| | | ||
+-------+ | +------+ ||
| | | ||
| | | ||
+--v--------v---------v--+ ||
| <- ISP Interfaces -> | ||
| | ||
| MIF Node | ||
| | ||
| IRON Interface -> <===============+
+------------------------+
Figure 1: MIF Node with IRON Interface
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.
Templin Expires July 7, 2012 [Page 5]
Internet-Draft IRON January 2012
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.
3. Related Work
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]. These same use-case scenarios apply also to IRON.
4. IANA Considerations
There are no IANA considerations for this document.
5. Security Considerations
Security considerations appear in the IRON, VET, SEAL and AERO
documents.
6. Acknowledgements
This work was motivated through discussions on the IETF Multiple
Interfaces (mif) working group mailing list.
7. References
7.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.
7.2. Informative References
[AERO] Templin, F., Ed., "Asymmetric Extended Route Optimization
(AERO)", Work in Progress, December 2011.
Templin Expires July 7, 2012 [Page 6]
Internet-Draft IRON January 2012
[INTAREA-SEAL]
Templin, F., Ed., "The Subnetwork Encapsulation and
Adaptation Layer (SEAL)", Work in Progress, December 2011.
[INTAREA-VET]
Templin, F., Ed., "Virtual Enterprise Traversal (VET)",
Work in Progress, December 2011.
[IRON] Templin, F., Ed., "The Internet Routing Overlay Network
(IRON)", Work in Progress, December 2011.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
February 2010.
[RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and
Addressing in Networks with Global Enterprise Recursion
(RANGER) Scenarios", RFC 6139, February 2011.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
November 2011.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, November 2011.
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 July 7, 2012 [Page 7]
