[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

Internet Research Task Force                             F. Templin, Ed.
(IRTF)                                      Boeing Research & Technology
Internet-Draft                                              June 9, 2010
Intended status: Informational
Expires: December 11, 2010


              The Internet Routing Overlay Network (IRON)
                       draft-templin-iron-05.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 a
   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
   must be updated.  This document therefore proposes an Internet
   Routing Overlay Network (IRON) for supporting sustainable growth
   through PI addressing while requiring no changes to end systems and
   no changes to the existing routing system.  This document is a
   product of the IRTF Routing Research Group (RRG).

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 December 11, 2010.



Templin                 Expires December 11, 2010               [Page 1]


Internet-Draft                    IRON                         June 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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IRON Routers . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  The Internet Routing Overlay Network (IRON)  . . . . . . . . .  5
   5.  IRON Initialization  . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  IR(VP) and IR(GW) Initialization . . . . . . . . . . . . .  7
     5.2.  IR(EP) Initialization  . . . . . . . . . . . . . . . . . .  8
   6.  IRON Operation . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  IR(EP) Operation . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  IR(VP) Operation . . . . . . . . . . . . . . . . . . . . . 10
     6.3.  IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 10
     6.4.  IRON Reference Operating Scenario  . . . . . . . . . . . . 11
     6.5.  Mobility, Multihoming and Traffic Engineering  . . . . . . 12
       6.5.1.  Mobility Management  . . . . . . . . . . . . . . . . . 12
       6.5.2.  Multihoming  . . . . . . . . . . . . . . . . . . . . . 13
       6.5.3.  Inbound Traffic Engineering  . . . . . . . . . . . . . 13
       6.5.4.  Outbound Traffic Engineering . . . . . . . . . . . . . 13
   7.  Related Initiatives  . . . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16








Templin                 Expires December 11, 2010               [Page 2]


Internet-Draft                    IRON                         June 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 a
   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
   must be updated.

   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 with Virtual Prefixes (VPs)
   for router Forwarding Information Base (FIB) and Routing Information
   Base (RIB) scaling reduction.  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 [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 (NBMA) "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
   [RFC4271] routing systems of the IPv4 and IPv6 Internets in any way.

   IRON uses the IPv4 and IPv6 global Internet routing systems as
   virtual NBMA links for tunneling inner network protocol packets that
   use End User Network (EUN) PI Prefix (EP) source addresses within
   outer IPv4 or IPv6 packets that use Routing LOCator (RLOC) addresses.
   Moreover, inner packets can be either IPv4 or IPv6 without regard to



Templin                 Expires December 11, 2010               [Page 3]


Internet-Draft                    IRON                         June 2010


   the address family used in the outer packet, and inner packets can
   even be non-IP protocols such as OSI/CLNP.

   This document is offered in compliance with Internet Research Task
   Force (IRTF) document stream procedures [RFC5743]; it is not an IETF
   product and is not a standard.  The views in this document were
   considered controversial by the IRTF Routing Research Group (RRG) but
   the RG reached a consensus that the document should still be
   published.  The document will undergo a period of review within the
   RRG and through selected expert reviewers prior to publication.  The
   following sections discuss details of the IRON architecture.


2.  Terminology

   The following abbreviations correspond to terms used within this
   document and elsewhere in common Internetworking nomenclature:

      EP - End User Network PI Prefix

      ETE - Egress Tunnel Endpoint

      EUN - End User Network

      ISP - Internet Service Provider

      ITE - Ingress Tunnel Endpoint

      MVP - Master Virtual Prefix (database)

      NBMA - Non-Broadcast, Multiple Access

      PA - Provider Aggregated

      PI - Provider Independent

      SCMP - the SEAL Control Message Protocol

      SEAL_ID - an Identification value, randomly initialized and
      monotonically incremented for each SEAL protocol packet

      TE - Tunnel Endpoint (i.e., either ingress or egress)

      VP - Virtual Prefix







Templin                 Expires December 11, 2010               [Page 4]


Internet-Draft                    IRON                         June 2010


3.  IRON Routers

   IRON introduces a new class of routers called IRON Routers (IRs) that
   can be deployed on platforms ranging from high-end enterprise routers
   to customer premises routers to simple commodity servers.  Moreover,
   IRs can be 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
   destination addresses taken from End User Network PI prefixes (EPs)
   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 non-initial 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 VPs from which it sub-delegates more-specific
      EPs to EUNs.

   o  IR(EP) - a tunnel endpoint router (or host with embedded gateway
      function) that obtains an 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
      ISP(s), but may also be a router or even a singleton host within
      the EUN.

   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 IPv4 and/or IPv6 global
      Internet DFZs.  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 (e.g., OSI/CLNP [RFC1070], etc.) are also within scope.


4.  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 encapsulated inner network layer packets over the IPv4 and
   IPv6 Internets.  Each such IR views the IPv4 and IPv6 global
   Internets as monolithic virtual NBMA "links", and connects to the



Templin                 Expires December 11, 2010               [Page 5]


Internet-Draft                    IRON                         June 2010


   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 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 EPs taken from the VPs
   to customer EUNs.  These EUNs may be located within 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 physically arrange for basic connectivity via one or more
   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.  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.  Each IR(GW) forwards any 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 PA
   addresses can communicate with other end systems that use PI
   addresses taken from an IRON VP.

   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.

   The IRON additionally requires a global mapping database to allow IRs
   to map EPs/VPs to RLOCs assigned to the interfaces of other IRs.
   Each VP in the IRON is therefore represented in a globally
   distributed Master VP (MVP) mapping database.  The MVP database is
   maintained by a globally-managed assigned numbers authority in the
   same manner as the Internet Assigned Numbers Authority (IANA)
   currently maintains the master list of all top-level IPv4 and IPv6
   delegations.  The database can be replicated across multiple servers



Templin                 Expires December 11, 2010               [Page 6]


Internet-Draft                    IRON                         June 2010


   for load balancing much in the same way that FTP mirror sites are
   used to manage software distributions.  Each VP in the MVP database
   is encoded as the tuple: "{address family, prefix, prefix-length,
   FQDN}", where:

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

   o  "prefix" is the VP, e.g., 2001:DB8::/32 (IPv6), 192.2/16 (IPv4),
      etc.

   o  "prefix-length" is the length (in bits) of the associated VP

   o  FQDN is a DNS Fully-Qualified Domain Name

   For each VP entry in the MVP database, the VP company maintains a
   FQDN in the DNS to map the VP to a list of IR(VP)s that serve it.
   The FQDN is resolved by both other IR(VP)s and by IR(EP)s that hold
   EP delegations from the VP into a list of resource records.  Each
   resource record corresponds to an individual IR(VP), and encodes the
   tuple : "{address family, RLOC address, WGS 84 coordinates}" where
   "address family" is the address family of the RLOC, "RLOC" is the
   routing locator assigned to an IR(VP), and "WGS 84 coordinates"
   identify the physical location of the IR(VP).  Together, the MVP
   database and the FQDNs in the global DNS provide sufficient mapping
   capabilities to support navigation of the IRON.


5.  IRON Initialization

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

5.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 by reading the MVP
   database (see Section 4).  These VPs may be IPv4 or IPv6, but they
   may also be prefixes of other network layer protocols (e.g., OSI/CLNP
   NSAP [RFC4548], etc.).  Each IR(VP/GW) reads the MVP database from a
   nearby server upon startup time, and periodically checks for deltas
   on the server since the database was last read.  Upon reading the MVP
   database, the IR(VP/GW) resolves the FQDN corresponding to each VP
   into an RLOC and a physical location.  Each RLOC address is an IPv4
   or IPv6 RLOC address assigned to the 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



Templin                 Expires December 11, 2010               [Page 7]


Internet-Draft                    IRON                         June 2010


   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 EPs derived from its VPs into its FIB based
   on the mapping information received from each of its EUN customers.

5.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 2001:DB8::1 (IPv6), the IR(EP)
   informs the VP company that the route 192.2.1/24 with 2001:DB8::1 as
   the L2 address of the next-hop 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(s) with username/password) to register its EP-to-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 IR(EP) also uses the same EP-to-RLOC registration
   procedure to inform its VP company of a change in RLOC, e.g., due to
   a mobility event, a change in its primary ISP, etc.).  After the
   IR(EP) registers its mapping information, the VP company then
   propagates it to each of its IR(VPs) that aggregates the EP, e.g.,
   via a routing protocol that all of the VP company's IR(VP)s 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.  (This resolution closely resembles the ISATAP Potential
   Router List (PRL) resolution procedure [RFC5214].)  The IR(EP) then
   selects 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 VET
   interface with the RLOC as the L2 address of the next-hop.  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 December 11, 2010               [Page 8]


Internet-Draft                    IRON                         June 2010


6.  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 redirect messages informing them of a more
   optimal route.  Each IR operates as specified in the following
   sections:

6.1.  IR(EP) Operation

   After an IR(EP) is initialized, it sends periodic beacons to at least
   2-4 of its VP company's IR(VP)s which serve as default routers.  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 an IR(VP), it marks the IR(VP) as unreachable and selects a
   different IR(VP).  If the IR(EP) ceases to receive RA messages from
   multiple IR(VPs), it marks the ISP connection as failed/failing and
   uses an RLOC assigned by a different ISP to re-register its EP-to-
   RLOC mapping.

   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 source
   IR(EP) then forwards the packet either to an IR(VP) or to a
   destination IR(EP).  The source IR(EP) first checks its FIB for the
   longest matching prefix.  If the longest matching prefix is more-
   specific than "default", the source IR(EP) forwards the packet to the
   next-hop the same as for ordinary IP forwarding.  If the longest
   match is "default", however, the source IR(EP) forwards the packet to
   one of the IR(VP)s serving as its default routers.

   The source IR(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 source IR(EP) further uses SCMP to
   test liveness and/or to accept redirect messages from the next-hop
   IR.  When the source IR(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 source IR(EP) will follow a route-optimized
   path.

   An IR(EP) that accepts redirects may be redirected by an IR(VP) in
   its home VP company network to one or more IR(VP)s in a "foreign"



Templin                 Expires December 11, 2010               [Page 9]


Internet-Draft                    IRON                         June 2010


   network.  In that case, the IR(EP) has no way of knowing if these
   foreign IR(VP)s are reachable and able to process encapsulated
   packets.  In that case, the IR(EP) should select multiple foreign
   IR(VPs) (e.g., 2-4) and send "live" packets to one of them while
   sending corresponding "blank" packets to the others.  In turn, each
   foreign IR(VP) accepts and forwards "live" packets, but drops "blank"
   packets after sending a redirect.  In this way, even if the original
   packet is lost due to congestion or a short-term outage, the IR(EP)
   will receive a redirect from at least one of the foreign IR(VP)s.

6.2.  IR(VP) Operation

   After an IR(VP) is initialized, it sends RA responses to the periodic
   RS beacons sent by IR(EPs) as described in Section 6.1.  When the
   IR(VP) receives an encapsulated packet from another IR, it examines
   the inner destination address then forwards the packet as follows:

   o  If the inner destination address matches an EP in its FIB, the
      IR(VP) 'A' re-encapsulates the packet using VET/SEAL and forwards
      it to the next-hop IR(EP) 'B'.  If the source IR 'C' is accepting
      redirects, 'A' also sends an SCMP redirect message back to 'C'.
      'C' will then send subsequent packets directly to 'B'.

   o  If the inner destination address does not match an EP but matches
      a VP in its FIB, the IR(VP) 'A' re-encapsulates the packet using
      VET/SEAL and forwards it to the next-hop IR(VP) 'B' .  If the
      source IR 'C' is accepting redirects, 'A' also sends an SCMP
      redirect message back to 'C'.  'C' will then send subsequent
      packets directly to 'B'.

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

   An IR(VP) that accepts redirects may need to forward initial packets
   via the IR(VP)s of a "foreign" network.  In that case, the IR(VP) can
   send a "live" packet in parallel with corresponding "blanks" the same
   as for an IR(EP).

6.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 IPv4 and/or
   IPv6 Internet BGP.  The VPs will be seen as ordinary routing
   information in the BGP, and any packets originating from the non-IRON
   IPv4 or IPv6 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



Templin                 Expires December 11, 2010              [Page 10]


Internet-Draft                    IRON                         June 2010


   determine the best next-hop toward the final destination.  The IR(GW)
   then either forwards the packet to an IR(VP) within the home network
   or acts as an IR(VP) itself to forward the packet further.

6.4.  IRON Reference Operating Scenario

   With respect to the previous sections, a path between two EUNs can
   potentially involve both the two IR(EPs) and the IR(VP)s of the two
   VP companies that serve the EUNs.  Route optimization based on
   redirection will allow shortcuts that eliminate the IR(VP)s from the
   path.  The following figure depicts the IRON reference operating
   scenario for communications between two EUNs:


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

                Figure 1: IRON Reference Operating Scenario

   In this reference scenario, VP companies A and B have established
   IR(VP)s within the Internet that serve EPs to EUNs.  EUN A has
   procured an EP from VP company A, while EUN B has procured an EP from
   VP company B. The hosts in both EUNs have assigned addresses taken
   from their corresponding EPs on their EUN-interior interfaces, and
   the IR(EPs) have assigned RLOC 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)).  If IR(EP(A
   ))does not have a more-specific route, it encapsulates the packet and
   forwards it to an IR(VP) owned by VP company A. IR(VP(A ))
   decapsulates the packet and checks its FIB for a route toward the
   packet's destination address.  If IR(VP(A)) does not have an EP route



Templin                 Expires December 11, 2010              [Page 11]


Internet-Draft                    IRON                         June 2010


   to Host B in its FIB, it consults its full table of VP-to-RLOC
   mappings to discover that the next-hop toward Host B is via
   IR(VP(B)).  IR(VP(A)) then re-encapsulates the packet and sends it to
   IR(VP(B)) which has an EP route to Host B via IR(EP(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 process, when an IR(VP) re-encapsulates the packet and
   forwards it to a next-hop IR, it also returns an SCMP redirect
   message to the previous hop IR if the previous hop is willing to
   accept redirects.  The previous hop IR will then install a route in
   its FIB that uses a more optimal next hop.  For example, if IR(EP(A))
   is accepting redirects IR(VP(A)) will return a redirect message when
   it forwards a packet to IR(VP(B)).  IR(EP(A)) will then send
   subsequent packets directly to IR(VP(B)), which will return a
   redirect message when it forwards the packets to IR(EP(B)).  Finally,
   IR(EP(A)) will have an optimized route that lists IR(EP(B)) as the
   next hop (shown as "....>" in the diagram).

   Another redirection scenario arises when IR(VP(A)) is itself willing
   to accept redirects.  In that case, IR(EP(A)) may discover IR(EP(B))
   as a better next hop toward EUN A based solely on a redirect message
   from IR(VP(A)) and without involving IR(VP(B)).  Note however that
   this may require IR(VP(A)) to carry thousands or even millions of EP
   entries in its FIB for all EUNs that it has sent packets to recently,
   which may negatively impact scalability.

6.5.  Mobility, Multihoming and Traffic Engineering

   While IR(VP)s can be considered as fixed infrastructure, IR(EP)s may
   need to move between different network points of attachment, connect
   to multiple ISPs, or explicitly manage their traffic flows.  The
   following sections discuss mobility, multihoming and traffic
   engineering considerations for IR(EP)s:

6.5.1.  Mobility Management

   When an IR(EP) moves to a new topological location, it receives a new
   RLOC address.  The IR(EP) then registers the new EP-to-RLOC mapping
   with its VP company the same as during its initialization phase as
   described in Section 5.2.  In this way, mobile networks are naturally
   supported without the need for ancillary mechanisms.

   Next, the IR(EP) sends Neighbor Advertisement (NA) messages to each
   neighboring IR from which it has received packets recently.  The NA
   message includes the new RLOC as the outer source address and
   includes the previous RLOC within an NA option field.  The
   neighboring IR will update its neighbor cache so that subsequent



Templin                 Expires December 11, 2010              [Page 12]


Internet-Draft                    IRON                         June 2010


   packets will flow through the new RLOC.

6.5.2.  Multihoming

   An IR(EP) registers only the RLOC of its primary ISP with its VP
   company even if it connects to multiple ISPs.  If the IR(EP) later
   needs to select a different ISP as its primary, it simply repeats the
   EP-to-RLOC registration process the same as if it were reacting to a
   mobility event as described above.

6.5.3.  Inbound Traffic Engineering

   When an IR(EP) receives packets via its primary ISP (i.e., the ISP
   for which it is currently registered with the VP company), it may
   wish to balance the load of incoming traffic between multiple ISP
   connection points.  In that case, the IR(EP) may send NA messages to
   certain neighboring IRs the same as in the case of a mobility event
   as described in Section 6.5.1.  In that way, the IR(EP) can manage
   its incoming traffic flows for best utilization of its multiple ISPs.

6.5.4.  Outbound Traffic Engineering

   IR(EP)s maintain a list of IR(VP)s that serve as default routers for
   VET interface encapsulation of inner packets with source addresses
   taken from an EP prefix.  IR(EP)s also maintain a list of neighbors
   on underlying interfaces that serve as default routers for packets
   with non-EP source addresses.  If the inner and outer protocols are
   of different versions (e.g., OSI/CLNP as the inner version and IPv4
   as the outer version) then the default routes of both versions are
   mutually exclusive and no special arrangements are needed.

   If the inner and outer protocol versions are the same, however (e.g.,
   IPv6 as both the inner and outer protocol) then a special treatment
   of the default route is necessary.  In particular, the IR(EP) must
   examine the source address of a packet to be forwarded to determine
   the proper handling of "default".  If the packet uses a source
   address taken from an EP prefix, the IR(EP) forwards it to an IR(VP)
   using encapsulation via a VET interface; otherwise, the IR(EP)
   forwards the packet to a next hop on an underlying link.

   Using this arrangement of default, when an IR(EP) forwards a packet
   with an EP source address it can forward it to any of its associated
   IR(VP)s using VET interface encapsulation over any of its underlying
   interfaces.  The choice of underlying interface can be managed, and
   the source address assigned to the underlying interface will be used
   as the outer source address of the encapsulated packet.  Each
   encapsulated packet can therefore be directed through the desired ISP
   using a topologically-correct outer source address.



Templin                 Expires December 11, 2010              [Page 13]


Internet-Draft                    IRON                         June 2010


7.  Related Initiatives

   IRON builds upon the concepts RANGER architecture [RFC5720], 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.


8.  IANA Considerations

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


9.  Security Considerations

   Security considerations for RANGER apply also to IRON.


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


11.  References

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

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



Templin                 Expires December 11, 2010              [Page 14]


Internet-Draft                    IRON                         June 2010


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

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

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

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

   [RFC1070]  Hagens, R., Hall, N., and M. Rose, "Use of the Internet as
              a subnetwork for experimentation with the OSI network
              layer", RFC 1070, February 1989.

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

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [RFC5720]  Templin, F., "Routing and Addressing in Networks with
              Global Enterprise Recursion (RANGER)", RFC 5720,
              February 2010.

   [RFC5743]  Falk, A., "Definition of an Internet Research Task Force
              (IRTF) Document Stream", RFC 5743, December 2009.





Templin                 Expires December 11, 2010              [Page 15]


Internet-Draft                    IRON                         June 2010


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 December 11, 2010              [Page 16]


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