Network Working Group F. Templin, Ed.
Internet-Draft Boeing Phantom Works
Intended status: Informational February 04, 2010
Expires: August 8, 2010
The Internet Routing Overlay Network (IRON)
draft-templin-iron-00.txt
Abstract
RANGER examines recursive arrangements of enterprise networks, where
the term "enterprise" can apply to a very broad set of use case
scenarios. RANGER considers the global Internet itself as the
highest level of enterprise network recursion, and assumes that
existing policies and operational practices in the current Internet
BGP routing system will continue into the foreseeable future.
However, RANGER also seeks to arrest the growth of the BGP RIB so
that it will level off and not continue to expand along super-linear
rates. In particular, RANGER expects that the current Internet BGP
routing system will continue to maintain the current RLOC-based RIB,
but that future growth due to mobility, multihoming and PI addressing
will be increasingly accommodated using EID addressing instead of
RLOC addressing. This new growth must be accommodated within
acceptable scaling limitations for both the RIB and FIB sizes for
EID-based routers in the Internet. Therefore, RANGER proposes that
an Internet Routing Overlay Network (IRON) be established over the
existing DFZ for the purpose of supporting scalable EID space
routing.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Templin Expires August 8, 2010 [Page 1]
Internet-Draft IRON February 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
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 BSD License.
Templin Expires August 8, 2010 [Page 2]
Internet-Draft IRON February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Internet Routing Overlay Network (IRON) . . . . . . . . . . 3
4. Related Initiatives . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Templin Expires August 8, 2010 [Page 3]
Internet-Draft IRON February 2010
1. Introduction
RANGER [I-D.templin-ranger] examines recursive arrangements of
enterprise networks, where the term "enterprise" can apply to a very
broad set of use case scenarios [I-D.russert-rangers]. RANGER
considers the global Internet itself as the highest level of
enterprise network recursion, and assumes that existing policies and
operational practices in the current Internet BGP routing system
[RFC4271] will continue into the forseeable future. However, RANGER
also seeks to arrest the growth of the BGP RIB so that it will level
off and not continue to expand along super-linear rates. In
particular, RANGER expects that the current Internet BGP routing
system will continue to maintain the current RLOC-based RIB, but that
future growth due to mobility, multihoming and PI addressing will be
increasingly accommodated using EID addressing instead of RLOC
addressing. This new growth must be accommodated within acceptable
scaling limitations for both the RIB and FIB sizes for EID-based
routers in the Internet. Therefore, RANGER proposes that an Internet
Routing Overlay Network (IRON) be established over the existing DFZ
for the purpose of supporting scalable EID space routing.
2. Terminology
The terminology of RANGER[I-D.templin-ranger], VET
[I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal] applies
also to IRON.
IRON observes the Internet Protocol standards [RFC0791][RFC2460].
3. The Internet Routing Overlay Network (IRON)
The Internet Routing Overlay Network (IRON) consists of routers that
communicate via tunnels across the existing Internet DFZ for the
purpose of propagating EID-based routing information and forwarding
EID-addressed data packets. Each such IRON router views the global
Internet DFZ as a monolithic VET NBMA link, and connects to the link
via a VET interface used for automatic tunneling. Each IRON router
therefore sees all other IRON routers as single-hop neighbors on the
VET link from the standpoint of the inner IP protocol, while they may
be separated by many outer IP hops across the underlying RLOC-based
Internet.
Each IRON router participates in a new IRON-specific BGP instance
that carries only EID prefixes and is maintained as a separate BGP
instance that does not interact with the current RLOC-based Internet
BGP system. Each IRON router sets up IRON BGP peering arrangements
Templin Expires August 8, 2010 [Page 4]
Internet-Draft IRON February 2010
with only a limited set of neighbors that are "nearby" within the
underlying RLOC-based Internet topology (i.e., it does not establish
a full mesh with all other IRON routers). IRON routers can discover
the addresses of nearby neighboring IRON routers through static
address configuration, resolving a well-known DNS FQDN, or through a
limited-scope multicast flood search discovery. When an FQDN is
used, each FQDN uses the well-known suffix "isatap.net".
IRON routers connect RANGER networks (e.g., ISP networks, large
corporate enterprise networks, academic campus networks, etc.) to the
IRON, and forward data and control packets between one another via
VET automatic tunneling. These IRON routers participate in the IRON
BGP instance, however there is no requirement that they also
participate in the current Internet RLOC-based BGP routing instance.
Therefore, IRON routers can be deployed incrementally and without
disturbing the existing Internet routing system.
<<< Insert figure 1 here showing example IRON topology >>>
The IRON RIB carries only a relatively small number of highly-
aggregated EID prefixes that are in some ways similar to the Virtual
Prefixes (VPs) proposed for Virtual Aggregation (VA)
[I-D.ietf-grow-va], where each VP is "owned" by one or more IRON
routers. In particular, the IRON RIB carries only highly-aggregated
VPs (e.g., 4000::/8, 4100::/8, etc.) such that the number of VPs
carried in the IRON RIB will be kept to a manageable size. The full
IRON RIB is propagated to all IRON routers via their peering
arrangements, and each IRON router installs all IRON RIB VPs (along
with their associated neighboring IRON router nexthop addresses) in
its FIB.
Customer Edge (CE) routers within RANGER networks will have incentive
to use EID-based PI prefixes in order to support mobility and
multihoming. Each such CE router "registers" its PI prefixes both
within the RANGER network and with any IRON BGP routers that own the
VP from which the PI prefix is derived. In particular, CE routers
that are holders of PI prefixes "blow bubbles" by sending periodic RA
messages that are propagated up through the RANGER network recursive
hierarchy. These RA "bubbles" percolate up through a reverse tree
ascending through the RANGER network until they reach IRON routers
that connect the RANGER network to the IRON. These IRON routers then
forwards the RA "bubbles" to any IRON routers that own a VP from
which the PI prefix is derived.
Once "registered", the CE router's PI prefix are kept only in the
FIBs of routers on paths over which the RA "bubbles" travel; the PI
prefixes are not injected into the IRON RIB. Moreover, only those
routers on the paths over which the CE's EID addressed packets will
Templin Expires August 8, 2010 [Page 5]
Internet-Draft IRON February 2010
travel need to install the PI prefix in their FIBs - no other routers
need to install the prefixes. The location of the CE router's EID
prefixes are tracked through the FIB entries in IRON routers that
hold the VPs from which the EID prefixes are derived. Once these VP
and more-specific prefix FIB entries are established, end-to-end data
communications using RANGER and EID-based addressing is enabled.
Data communications are propagated based on available information in
router FIBs, where standard longest-prefix-match forwarding is used.
However, since the FIB entries of most routers will be sparsely
populated, the RANGER mechanisms for data driven route optimization
are used.
<<< Insert figure 2 here showing RIB; FIB entries of IRON routers >>>
As a specific example, when a customer device associated with CE
router 'A' needs to send a packet to a customer device associated
with CE router 'E' (and the two CE routers are located in different
RANGER networks) the packet traverses default routes within the
RANGER network recursive hierarchy until it arrives at IRON router
'B'. IRON router 'B' then consults its FIB and discovers a VP that
covers the 'E' prefix, then forwards the packet via VET automatic
tunneling to an IRON router 'C' that owns the VP. Next, if 'E' is
"away from home", 'C' consults its FIB and discovers a more-specific
route that covers the 'E' prefix. 'C' then forwards the packet to an
IRON router 'D' which connects the RANGER network where 'E' currently
resides. At the same time, 'C' sends a redirect message to inform
'B' of a better nexthop. Thereafter, 'B' will forward packets
destined to 'E' directly to 'D' without having to involve 'C', since
'B' will have a more-specific route in its FIB. These FIB entries
will be maintained as long as data packets are flowing, and allowed
to expire when the flow of data packets ceases.
<<< Insert figure 3 here showing message exchange example >>>
In summary, the RANGER approach to scalable routing within the
Internet is to create a new Internet Routing Overlay Network (IRON)
using an EID-based BGP instance for the purpose of keeping a limited
set of highly-aggregated EID VPs in the RIB. EID prefixes owned by
CE routers are added to selected router FIB tables on-demand, and are
never injected into the RIB, therefore the FIB sizes of most routers
are also reduced. This same hybrid approach using both dynamic
routing protocols and on-demand data driven updates applies not only
within the IRON DFZ core, but also at any level within a RANGER
network recursive hierarchy.
Templin Expires August 8, 2010 [Page 6]
Internet-Draft IRON February 2010
4. Related Initiatives
IRON builds directly upon the RANGER architecture
[I-D.templin-ranger], and therefore inherits the same set of related
initiatives.
5. IANA Considerations
There are no IANA considerations for this document.
6. Security Considerations
Security considerations for RANGER apply also to IRON.
7. Acknowledgements
This ideas behind this work have evolved directly from the
development of RANGER, VET and SEAL. Discussions with colleagues
have helped motivate the work.
8. References
8.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.
8.2. Informative References
[I-D.ietf-grow-va]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-ietf-grow-va-01 (work in progress), October 2009.
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", draft-russert-rangers-01 (work in progress),
September 2009.
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Templin Expires August 8, 2010 [Page 7]
Internet-Draft IRON February 2010
Layer (SEAL)", draft-templin-intarea-seal-08 (work in
progress), January 2010.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-08 (work in progress),
January 2010.
[I-D.templin-ranger]
Templin, F., "Routing and Addressing in Next-Generation
EnteRprises (RANGER)", draft-templin-ranger-09 (work in
progress), October 2009.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
Author's Address
Fred L. Templin (editor)
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires August 8, 2010 [Page 8]
