[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 6179

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/