[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [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 Research & Technology
Intended status: Informational                            April 28, 2010
Expires: October 30, 2010


              The Internet Routing Overlay Network (IRON)
                       draft-templin-iron-01.txt

Abstract

   The Internet routing system is experiencing a growth profile that has
   led many to express concerns for unsustainable routing scaling.
   Operational practices such as increased use of multihoming with IPv4
   Provider-Independent (PI) addressing are resulting in more and more
   fine-grained prefixes injected into the routing system from more and
   more end user networks.  Furthermore, depletion of the remaining
   public IPv4 address space has raised concerns for both increased
   deaggregation (leading to yet further routing scaling) and an
   impending address space runout scenario.  At the same time, the IPv6
   routing system is finally beginning to see significant growth in IPv6
   Provider-Aggregated (PA) prefixes but there does not seem to be
   solution on the near term horizon for IPv6 PI addressing.  Since the
   Internet must continue to support escalating growth due to increasing
   demand, it is clear that current mechanisms and operational practices
   are reaching a tipping point where something must be done.  This
   document proposes an Internet Routing Overlay Network (IRON) for
   supporting sustainable growth while requiring no changes to end
   systems and no changes to the existing routing system.

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 October 30, 2010.

Copyright Notice



Templin                 Expires October 30, 2010                [Page 1]


Internet-Draft                    IRON                        April 2010


   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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  IRON Routers . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Internet Routing Overlay Network (IRON)  . . . . . . . . .  5
   4.  IRON Initialization  . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  IR(VP) and IR(GW) Initialization . . . . . . . . . . . . .  6
     4.2.  IR(EP) Initialization  . . . . . . . . . . . . . . . . . .  7
   5.  IRON Operation . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  IR(EP) Operation . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  IR(VP) Operation . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  IRON Example Configuration and Scenario  . . . . . . . . . 10
   6.  Related Initiatives  . . . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
















Templin                 Expires October 30, 2010                [Page 2]


Internet-Draft                    IRON                        April 2010


1.  Introduction

   The Internet routing system is experiencing a growth profile that has
   led many to express concerns for unsustainable routing scaling.
   Operational practices such as increased use of multihoming with IPv4
   Provider-Independent (PI) addressing are resulting in more and more
   fine-grained prefixes injected into the routing system from more and
   more end user networks.  Furthermore, depletion of the remaining
   public IPv4 address space has raised concerns for both increased
   deaggregation (leading to yet further routing scaling) and an
   impending address space runout scenario.  At the same time, the IPv6
   routing system is finally beginning to see significant growth in IPv6
   Provider-Aggregated (PA) prefixes but there does not seem to be
   solution on the near term horizon for IPv6 PI addressing.  Since the
   Internet must continue to support escalating growth due to increasing
   demand, it is clear that current mechanisms and operational practices
   are reaching a tipping point where something must be done.

   Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in
   Increasing Scopes (AIS) [I-D.zhang-evolution] are global routing
   proposals that introduce routing overlays using Virtual Prefixes
   (VPs) to reduce router Forwarding Information Base (FIB) and Routing
   Information Base (RIB) scaling.  Routing and Addressing in Networks
   with Global Enterprise Recursion (RANGER) [I-D.templin-ranger]
   examines recursive arrangements of enterprise networks that can apply
   to a very broad set of use case scenarios [I-D.russert-rangers].  In
   particular, RANGER supports encapsulation and secure redirection by
   treating each layer in the recursive hierarchy as a virtual non-
   broadcast, multiple access "link".  RANGER is an architectural
   framework that includes Virtual Enterprise Traversal (VET)
   [I-D.templin-intarea-vet] and the Subnetwork Adaptation and
   Encapsulation Layer (SEAL) [I-D.templin-intarea-seal] as its
   functional building blocks.

   This document proposes an Internet Routing Overlay Network (IRON) for
   supporting sustainable growth while requiring no changes to the
   existing routing system.  IRON borrows concepts from VA, AIS and
   RANGER, and further borrows concepts from the Internet Vastly
   Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture
   proposal.  IRON specifically seeks to enable scalable Provider-
   Independent (PI) addressing without changing the current BGP routing
   system in any way.

   IRON uses the IPv4 and IPv6 Internet DFZs as routing infrastructures
   for tunneling outer IPv4 or IPv6 packets with Routing LOCator (RLOC)
   addresses which encapsulate inner packets with Endpoint Interface
   iDentifier (EID) addresses.  Moreover, inner packets can be either
   IPv4 or IPv6 without regard to the address family used in the outer



Templin                 Expires October 30, 2010                [Page 3]


Internet-Draft                    IRON                        April 2010


   packet, and inner packets can even be non-IP protocols such as OSI.
   The following sections discuss details of the IRON architecture.


2.  IRON Routers

   IRON introduces a new class of routers called IRON Routers (IRs).
   These routers can be simple commodity hardware platforms that are
   introduced incrementally, and without affecting existing
   infrastructure.  The purpose of these new IRs is to provide waypoints
   (or "cairns") for navigating the IRON so that packets with Endpoint
   Interface iDentifier (EID) destination addresses can be delivered to
   the correct End User Networks (EUNs) through the use of encapsulation
   with minimum path stretch for initial packets and optimized routes
   for most packets.  The different categories of IRs includes:

   o  IR - an IRON Router of any kind

   o  IR(VP) - a tunnel endpoint router that is owned by a VP company
      and that aggregates Virtual Prefixes (VP) which it sub-delegates
      to EUNs.  An IR(VP) will typically be a commodity hardware
      platform with a minimum of one interface connected to the public
      Internet.  (For example, a typical IR(VP) can be a single-
      interface "router on a stick".)

   o  IR(S_VP) - an IR(VP) that forwards packets received from an
      IR(S_EP) to an IR(D_VP) in another VP company's network, to an
      IR(D_EP) in a customer EUN or to the public Internet..

   o  IR(D_VP) - an IR(VP) that forwards packets received from an
      IR(S_VP) to an IR(D_EP) and returns an encapsulated redirect
      message to inform the IR(S_VP) of a better next hop (i.e., the
      IR(D_EP) itself).

   o  IR(EP) - a tunnel endpoint router (or host) that receives an EID
      Prefix (EP) from a VP company, and that connects an EUN to the
      IRON.  An IR(EP) will typically be a customer premises equipment
      (CPE) device that connects the EUN to its provider(s), but may
      also be a router or even a singleton host within the EUN.

   o  IR(S_EP) - an IR(EP) that forwards packets received from an end
      system in the EUN.  IR(S_EPs) forward initial encapsulated packets
      to IR(S_VP)s, and thereafter may send packets directly to
      IR(D_EPs) if redirected to do so.

   o  IR(D_EP) - an IR(EP) that decapsulates packets originating from an
      IR(D_VP) or an IR(S_EP) and forwards them to end systems in the
      EUN.



Templin                 Expires October 30, 2010                [Page 4]


Internet-Draft                    IRON                        April 2010


   o  IR(GW) - a router that acts as a gateway between the IRON and the
      non-IRON Internet.  Each VP company configures one or more IR(GWs)
      which advertise the company's VPs into the Internet DFZ.  An
      IR(GW) may be configured on the same physical platform as IR(VPs),
      or as a separate standalone platform.  An IR(GW) will typically be
      a BGP router that is capable of sourcing encapsulated packets.

   IRON observes the Internet Protocol standards [RFC0791][RFC2460].
   Other network layer protocols that can be encapsulated within IP
   packets are also within scope.


3.  The Internet Routing Overlay Network (IRON)

   The Internet Routing Overlay Network (IRON) consists of IRON Routers
   (IRs) that use Virtual Enterprise Traversal (VET) and the Subnetwork
   Encapsulation and Adaptation Layer (SEAL) for the purpose of
   forwarding EID-addressed data packets over the IPv4 and IPv6
   Internet.  Each such IR views the IPv4 and IPv6 global Internets as
   monolithic NBMA links, and connects to the links via a VET interface
   used for automatic tunneling.  Each IR therefore sees all other IRs
   as virtual single-hop neighbors on the link from the standpoint of
   the inner network layer protocol, while they may be separated by many
   physical outer IP hops.  IRs are deployed incrementally and without
   disturbing the existing Internet routing system.

   The IRON is manifested through a business model in which Virtual
   Prefix (VP) companies own and manage a set of IR(VPs) that are
   dispersed throughout the Internet and that serve a set of highly-
   aggregated VPs.  Each VP company sets up a service in which it leases
   EID Prefixes (EPs) taken from the VPs to customer EUNs.  These EUNs
   may be located on the same network as the VP company's IR(VP)
   routers, or they may be located elsewhere within the Internet.  The
   VP company acts as a virtual enterprise network which EUNs loosely
   consider as their "home" network even though they may physically
   arrange for basic connectivity via one or more Internet Service
   Provider (ISP) networks that may have no affiliation with the VP
   company.  VP companies can therefore open for business and begin
   serving their customers immediately without the need to coordinate
   their activities with ISPs or with other VP companies.

   Each VP company also establishes a set of IR(GW) routers that connect
   to the IPv4 and/or IPv6 Internet DFZs (i.e., the IR(GW) must be a BGP
   router).  The IR(GW) advertises all of the VP company's IPv4 VPs into
   the IPv4 DFZ and advertises all of its IPv6 VPs into the IPv6 DFZ.
   The IR(GW) forwards any EID-addressed packets coming from the DFZ to
   an IR(VP) that can encapsulate the packet and forward it to the
   appropriate IR(EP).  In this way, end systems that use ISP-aggregated



Templin                 Expires October 30, 2010                [Page 5]


Internet-Draft                    IRON                        April 2010


   addresses can communicate with other end systems that use IRON VP-
   aggregated addresses.

   EUNs establish at least one IR(EP) that connects the EUN to the IRON.
   The IR(EP) uses encapsulation to forward packets with EP source
   addresses to an IR(VP) belonging to its VP company as a default
   router.  The VP company's IR(VP) then forwards the packets toward
   their final destination, and returns a SEAL Control Message Protocol
   (SCMP) redirect message to inform the IR(EP) of a better next hop if
   necessary.  In this way, IR(EPs) experience reasonable path stretch
   for initial packets and can discover route-optimized paths for
   subsequent packets.


4.  IRON Initialization

   IRON initialization entails the startup actions of VP company and EUN
   equipment The following sections discuss these startups procedures:

4.1.  IR(VP) and IR(GW) Initialization

   Upon startup, each IR(VP) and IR(GW) owned by the VP company
   discovers the full set of VPs for the IRON.  These VPs may be IPv4 or
   IPv6, but they may also be prefixes of other network layer protocols
   such as OSI NSAP [RFC4548], etc.  Each VP is maintained in a Master
   VP (MVP) flat file that consists of the union of all VPs in the IRON.
   The MVP file is maintained by a globally-managed assigned numbers
   authority in exactly the same manner as the Internet Assigned Numbers
   Authority (IANA) currently maintains the master list of all top-level
   IPv4 and IPv6 delegations.  Indeed, the IANA is proposed as the
   primary registration authority for the MVP file.  Each VP in the MVP
   file is encoded as the tuple: "{address family, prefix/length,
   FQDN}", where:

   o  "address family" is one of IPv4, IPv6, OSI/CLNP, etc.

   o  "prefix/length" is the VP and its associated length, e.g., 2002:
      DB8::/32 (IPv6), 192.2/16 (IPv4), etc.

   o  FQDN is a DNS Fully-Qualified Domain Name

   Each IR(VP) and IR(GW) reads the MVP from a nearby server upon
   startup time, and periodically checks for deltas on the server since
   the MVP was last read.  (The MVP 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 reading the MVP,
   the IR(VP/GW) resolves the FQDN corresponding to each VP into a list
   of DNS Well-Known Service (WKS) resource records with an IRON-



Templin                 Expires October 30, 2010                [Page 6]


Internet-Draft                    IRON                        April 2010


   specific format (to be specified) that includes the address family,
   RLOC address, and geographic (Latitude/Longitude) coordinates at
   which the IR(VP) is physically located.  Each RLOC address is an IPv4
   or IPv6 RLOC address of an IR(VP) within the DFZ.

   For each VP, the IR(VP/GW) sorts the list of RLOCs in order of
   "geographic closeness", and inserts each "VP->RLOC" mapping into its
   Forwarding Information Base (FIB) with a priority corresponding to
   geographic closeness.  Specifically, the FIB entries must be
   configured such that packets with destination addresses covered by
   the VP are forwarded to the corresponding RLOC using encapsulation of
   the inner network layer packet in an outer IP header.  Note that the
   VP and RLOC may be of different address families; hence, possible
   encapsulations include IPv6-in-IPv4, IPv4-in-IPv6, IPv6-in-IPv6,
   IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.  After each
   IR(VP/GW) reads in the list of VPs and sorts the information
   accordingly, it is said to be "synchronized with the IRON".  Each
   IR(VP) next installs all EID Prefixes (EPs) derived from its VPs into
   its FIB based on the mapping information received from each EUN that
   owns an EP.

4.2.  IR(EP) Initialization

   Upon startup, each IR(EP) must register its EP-to-RLOC binding with
   the company that owns the corresponding VP, where the RLOC is an IPv4
   or IPv6 address assigned to the IR(EP) by an ISP network.  For
   example, if an IR(EP) owns the EP 192.2.1/24 (IPv4) and the RLOC
   assigned to the IR(EP) by the ISP is 2002:DB8::1 (IPv6), the IR(EP)
   informs the VP company that the route 192.2.1/24 -> 2002:DB8::1 must
   be added to the FIB in each of its IR(VPs) that aggregates the EP.
   The IR(EP) typically informs the VP company by using an authenticated
   short transaction protocol, e.g., http with username/password along
   with EP->RLOC mapping information.  The exact specification for the
   short transaction is up to the VP company and need only be
   communicated to the IR(EP).  The VP company then propagates this
   information to each of its IR(VPs) that aggregates the EP, e.g., via
   a routing protocol that all of the VP company's IR(VPs) engage in.

   After the IR(EP) informs the VP company of its EP->RLOC mapping, it
   resolves a FQDN for the VP company in order to discover the RLOC
   addresses and geographic locations of the IR(VPs) owned by the
   company.  The IR(EP) then picks the closest subset of these RLOC
   addresses (typically 2-4 routers chosen, e.g., based on geographic
   distance), and adds them to a default router list of FIB entries that
   each points to a tunnel virtual interface with the RLOC as the next-
   hop address.  The IR(EP) will then use these routes in the default
   router list as the means for forwarding encapsulated packets with EID
   source addresses toward the final destination via encapsulation.



Templin                 Expires October 30, 2010                [Page 7]


Internet-Draft                    IRON                        April 2010


5.  IRON Operation

   Following IRON initialization, IRs engage in the steady-state process
   of receiving and forwarding packets.  Except in instances when it
   forwards an unencapsulated packet to the public Internet, the IR
   encapsulates each forwarded packet using the mechanisms of VET
   [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal].  IRs
   also use the SEAL Control Message Protocol (SCMP) to test liveness of
   other IRs and to receive redirects informing them of a better next
   hop.  Each IR operates as specified in the following sections:

5.1.  IR(EP) Operation

   After an IR(EP) is initialized, it sends periodic beacons to at least
   2-4 of the IR(VPs) in its default router list.  Each beacon is a SEAL
   Control Message Protocol (SCMP) Router Solicitation (RS) message, and
   will elicit an SCMP Router Advertisement (RA) message from the
   IR(VP).  If the IR(EP) ceases to receive RA messages from a single
   IR(VP), it marks that IR(VP) as unreachable and selects a different
   IR(VP) as its primary default router.  If the IR(EP) ceases to
   receive RA message from all IR(VPs), it marks the ISP connection as
   failed and uses a different ISP to re-register its EP-to-RLOC binding
   with its VP company using the RLOC assigned by the new ISP.

   When an end system in an EUN has a packet to send, the packet is
   forwarded through the EUN until it reaches the IR(EP).  The IR(EP)
   then acts as an IR(S_EP) to forward a packet either to an IR(S_VP) or
   to an IR(D_EP).  The IR(S_EP) first checks its FIB for the longest
   matching prefix.  If the longest matching prefix is more-specific
   than "default", the IR(S_EP) forwards the packet to the next-hop the
   same as for ordinary IP forwarding, where the next hop will typically
   be an IR(D_EP).  If the longest match is "default", however, the
   IR(S_EP) forwards the packet to one of its default routers.

   The IR(S_EP) uses VET and SEAL to encapsulate each forwarded packet
   in an outer IP header with the IP address of the next-hop IR as the
   destination address.  The IR(S_EP) further uses SCMP to test liveness
   of and to receive SCMP redirect messages from the next-hop IR.  When
   the IR(S_EP) receives an SCMP redirect, it checks the SEAL_ID field
   of the encapsulated message to verify that the redirect corresponds
   to a packet that it had previously sent to the neighbor and accepts
   the redirect if there is a match.  Thereafter, subsequent packets
   forwarded by the IR(S_EP) will follow a route-optimized route.

   when an IR(EP) has a packet to forward from the EUN to a destination
   in a different network, it first checks its FIB for the longest
   matching prefix.  If the longest matching prefix is more-specific
   than "default", the IR(EP) forwards the packet to the next hop IR



Templin                 Expires October 30, 2010                [Page 8]


Internet-Draft                    IRON                        April 2010


   using VET/SEAL encapsulation.  If the longest match is "default",
   however, the IR(EP) encapsulates the packet in an outer IP header
   with the IP address of an IR(VP) (discovered during initialization)
   as the destination address.  The IR(EP) encapsulates the packet using
   the and

5.2.  IR(VP) Operation

   After an IR(VP) is initialized, it responds to the periodic beacons
   sent by IR(EPs) as described in Section 5.1.  When the IR(VP)
   receives an encapsulated packet, it first verifies that the inner and
   outer source addresses of the packet match an entry in its FIB, i.e.,
   it performs an ingress filter check to confirm that the packet was
   sent by a legitimate IR(S_EP) or IR(S_VP).  If there is a matching
   FIB entry, the IR(VP) accepts and decapsulates the packet; otherwise
   it discards the packet.  The IR(VP) next examines the destination
   address of the decapsulated packet then acts as an IR(S_VP) to
   forward the packet as follows:

   o  If the destination address matches an EP in its FIB, the IR(S_VP)
      re-encapsulates the packet using VET/SEAL, forwards it to the
      next-hop IR(D_EP) and sends an SCMP redirect message back to the
      previous hop IR.  The previous hop IR will then install a route
      for the EP in its FIB and will send subsequent packets directly to
      the IR(D_EP).

   o  If the destination address does not match an EP but matches a VP
      in its FIB, the IR(S_VP) re-encapsulates the packet using VET/
      SEAL, forwards it to the next-hop IR(D_VP), but does not send an
      SCMP redirect message back to the previous hop IR.

   o  if the destination address does not match an EP or a VP in the
      FIB, the IR(S_VP) forwards the unencapsulated packet to the public
      Internet via a default or more-specific route.

   When the IR(S_VP) forwards an encapsulated packet to an IR(D_VP) or
   an IR(D_EP), it may receive an SCMP redirect message informing it of
   a better next hop IR.  The IR(S_VP) records the new route in its FIB
   and then relays a copy of the SCMP redirect message back to the IR
   from which it received the original encapsulated packet.

   Note that when an IR(S_VP) selects a next-hop IR(D_VP), it has no way
   of knowing whether the IR(D_VP) is reachable and able to process
   encapsulated packets.  Therefore, the IR(S_VP) should select multiple
   IR(D_VPs) (e.g., 2-4), send the "live" packet to one of the IR(D_VPs)
   and send "blank" packets to the other IR(D_VPs).  In turn, each
   IR(D_VP) accepts and forwards "live" packets, but drops "blank"
   packets after sending the redirect.  In this way, even if the



Templin                 Expires October 30, 2010                [Page 9]


Internet-Draft                    IRON                        April 2010


   original packet is lost due to short- or long-term outage, the
   IR(S_VP) should receive a redirect from at least one of the
   IR(D_VPs).

5.3.  IR(GW) Operation

   Each VP company must establish one or more IR(GW) routers which
   advertise the full set of the company's VP's into the BGP.  The VPs
   will be seen as ordinary routing information in the BGP, and any
   packets originating from the non-IRON Internet will be forwarded into
   the VP company's network by an IR(GW).  When an IR(GW) receives a
   packet from the non-IRON Internet but destined to an EP destination,
   it consults its FIB to determine the best next-hop toward the final
   destination.  The IR(GW) then encapsulates the packet using VET/SEAL
   then sends it to the next-hop IR the same as described for IR(VP)
   operation above.  As for IR(VP) operation, when an IR(GW) forwards an
   encapsulated packet to an IR(D_VP), it may obtain more timely
   convergence by sending a "live" packet to one IR(D_VP) and "blanks"
   to others.

5.4.  IRON Example Configuration and Scenario

   With respect to the previous sections, the following figure depicts a
   simple example IRON configuration and scenario:


                     +------------+       +------------+
                     |            |       |            |
             /======>+  IR(VP) A  +======>+  IR(VP) B  +======\
            //       |            |       |            |      \\
           //        +------------+       +------------+       \\
          //                                                    V
     +----+-----+                                           +----+-----+
     | IR(EP) A | ........................................> | IR(EP) B |
     +----+-----+                                           +----+-----+
          |                                                      |
     ^^^^^+^^^^^^                                           ^^^^^+^^^^^^
    (    EUN A   )                                         (    EUN B  )
     -----+------                                           -----+------
          |                                                      |
      +---+----+                                             +---+----+
      | Host A |                                             | Host B |
      +--------+                                             +--------+

                   Figure 1: Example IRON Configuration

   In this example, VP companies A and B have established IR(VP)s within
   the Internet that serve EP's to EUNs.  EUN A has procured an EP from



Templin                 Expires October 30, 2010               [Page 10]


Internet-Draft                    IRON                        April 2010


   VP company A, while EUN B has procured an EP from VP company B. The
   IR(EPs) and hosts in both EUNs have assigned addresses taken from
   their corresponding EPs on their EUN-interior interfaces, and the
   IR(EPs) have assigned provider-aggregated addresses taken from their
   ISPs on their WAN interfaces.

   When Host A in EUN A has a packet to send to Host B in EUN B, normal
   routing conveys the packet from Host A to IR(EP) A. Since IR(EP) A
   does not have a more-specific route, it encapsulates the packet and
   sends it via a tunnel to IR(VP) A (i.e., an IR(VP) owned by its VP
   company).  IR(VP) A decapsulates the packet (since the packet source
   addresses match an EP route in its FIB) and checks its FIB for a
   route toward the packet's destination address.  IR(VP) A does not
   have an EP route to B in its FIB, but it holds a full table of VP-to-
   RLOC mappings and discovers that the next-hop toward Host B is via
   IR(VP) B. IR(VP) A re-encapsulates the packet and sends it to IR(VP)
   B which has an EP route to B. IR(VP) B then re-encapsulates the
   packet and sends it to IR(EP) B, which decapsulates the packet and
   forwards it via EUN B to Host B.

   In this scenario, when IR(VP) B re-encapsulates the packet and
   forwards it to IR(EP) B, it also returns an SCMP redirect message to
   IR(VP) A. IR(VP) A then sets an EP route toward B in its FIB and
   relays the SCMP redirect message to IR(EP) A which also installs an
   EP route for B in its FIB.  Subsequent packets from Host A to Host B
   then flow through a direct tunnel (shown as "...>") while bypassing
   the IR(VP) routers.

   Not discussed in this scenario are the operation of IR(GWs) (see
   Section 5.3) nor the mechanisms for IR(EP)s to switch between
   multiple ISPs.


6.  Related Initiatives

   IRON builds upon the concepts RANGER architecture
   [I-D.templin-ranger], and therefore inherits the same set of related
   initiatives.

   Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in
   Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for
   the Virtual Prefix concepts.

   Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has
   contributed valuable insights, including the use of real-time
   mapping.





Templin                 Expires October 30, 2010               [Page 11]


Internet-Draft                    IRON                        April 2010


7.  IANA Considerations

   The IANA is instructed to create a Master Virtual Prefix (MVP)
   registry for IRON.


8.  Security Considerations

   Security considerations for RANGER apply also to IRON.


9.  Acknowledgements

   This ideas behind this work have benefited greatly from discussions
   with colleagues; some of which appear on the RRG and other IRTF/IETF
   mailing lists.


10.  References

10.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.

10.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-02 (work in progress), March 2010.

   [I-D.russert-rangers]
              Russert, S., Fleischman, E., and F. Templin, "Operational
              Scenarios for IRON and RANGER", draft-russert-rangers-02
              (work in progress), March 2010.

   [I-D.templin-intarea-seal]
              Templin, F., "The Subnetwork Encapsulation and Adaptation
              Layer (SEAL)", draft-templin-intarea-seal-13 (work in
              progress), March 2010.

   [I-D.templin-intarea-vet]
              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-intarea-vet-10 (work in progress),



Templin                 Expires October 30, 2010               [Page 12]


Internet-Draft                    IRON                        April 2010


              March 2010.

   [I-D.templin-ranger]
              Templin, F., "Routing and Addressing in Next-Generation
              EnteRprises (RANGER)", draft-templin-ranger-09 (work in
              progress), October 2009.

   [I-D.whittle-ivip-arch]
              Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
              Architecture", draft-whittle-ivip-arch-04 (work in
              progress), March 2010.

   [I-D.zhang-evolution]
              Zhang, B. and L. Zhang, "Evolution Towards Global Routing
              Scalability", draft-zhang-evolution-02 (work in progress),
              October 2009.

   [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.


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 October 30, 2010               [Page 13]


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