Internet DRAFT - draft-dykim-nara

draft-dykim-nara






Network Working Group                                             DY Kim
Internet-Draft                                       Chungnam University
Intended status: Experimental Protocol                     June 19, 2014
Expires: December 19, 2014

             Network Architecture with Recursive Addressing
                          draft-dykim-nara-03

Abstract

   A network architecture based on recursive addressing is proposed.
   The Internet is modeled as a network of autonomous sites, each being
   a collection of nodes.  Each site is named by an exterior address
   whereas each node by an interior local address.  Exterior routing
   depends solely on site addresses while interior routing on node
   addresses.  Mobility is inherent in Interior routing while migration
   and multihoming are in exterior routing.  The model can recursively
   repeat itself both outwards and inwards in the network, enabling its
   applicability, for example, to inter-planetary as well as Internet of
   Things.

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 19, 2014.

Copyright Notice

   Copyright (c) 2014 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.


DY Kim                 Expires December 19, 2014                [Page 1]

Internet-Draft                    NARA                         June 2014

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  ROUTING  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  IMPLEMENTATION CHOICES . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Node Address . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Site Address . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Gateway  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Name Servers . . . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  Routing Protocols  . . . . . . . . . . . . . . . . . . . .  7
   5.  CONSEQUENCES . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Recursive Internet . . . . . . . . . . . . . . . . . . . .  7
     5.2.  No Address Depletion . . . . . . . . . . . . . . . . . . .  8
     5.3.  No Inadvertent Internet Governance . . . . . . . . . . . .  8
     5.4.  Fast Mobility  . . . . . . . . . . . . . . . . . . . . . .  8
     5.5.  Site Multi-homing and Migration  . . . . . . . . . . . . .  8
     5.6.  Host Multi-homing  . . . . . . . . . . . . . . . . . . . .  8
     5.7.  Traffic Engineering  . . . . . . . . . . . . . . . . . . .  9
     5.8.  No Renumbering . . . . . . . . . . . . . . . . . . . . . .  9
     5.9.  Semantic Overloading . . . . . . . . . . . . . . . . . . .  9
   6.  CONCLUSIONS  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.  Introduction

   Scalability of the Internet has long been recognized as one of its
   major problems.  Explosion of DFZ(Default Free Zone) routing tables,
   one aspect of the problem, has resulted from the Internet's inability
   of efficient multi-homing, for which semantic overloading of the IP
   address has been blamed.  This semantic overloading, that IP
   addresses are used as both identifiers(IDs) and Locators(Locs) for
   nodes, has also been perceived as against the naming and addressing
   principles[IEN0001][IEN0019][RFC1498] and so as the main obstacle
   hindering the Internet from providing fast mobility and seamless
   multihoming.

   A considerable number of protocols based on the Loc/ID
   Separation(LIS) architecture have been proposed.  Some of them are
   host-based[RFC4423][GSE][ILNP][IEEE-MCOM]while others are router-
   based[LISP][IRON][Ivip].

   This document proposes an architecture, named NARA, based on local
   addressing in its strict sense.  Local addresses, for nodes, are
   never exploited in exterior routing.  A collection of nodes under an
   autonomous administration is called a site, and only site addresses
   identifying them are used in exterior routing.

   NARA is very close to the ideas proposed in ENCAPS and
   hIPv4[RFC1955][RFC6306].  The addresses of the latter two, however,
   name interfaces whereas NARA's addresses name node themselves.




DY Kim                 Expires December 19, 2014                [Page 2]

Internet-Draft                    NARA                         June 2014

   Node addresses in NARA are semantically overloaded.  They are used
   for end-to-end connections as well as for routing.  This is a stark
   contrast to prevalent arguments of LIS. Semantic overloading is not
   seen as an evil in NARA, but is rather positively exploited to
   provide fast mobility and seamless multihoming.

   Although this document describes NARA in a two-tier network, the same
   addressing and routing principles can be recursively repeated inwards
   and outwards off a given network tier.  NARA is a recursive network
   architecture.

   Following sections provide a generic description of the NARA
   architecture and associated routings.  Implemetation choices for a
   better chance of deployment are discussed in the ensuing section.
   Consequences of the proposal are discussed before concluding the
   document.

2.  ARCHITECTURE

   The Internet is modeled as a networked collection of autonomous
   sites.  A site is a collection of nodes, also called either
   hosts(stub nodes) or routers(relay nodes). A subset of hosts and an
   associated router form a subnet.  Therefore, a site can also be
   considered as a networked collection of subnets.  A site itself can
   be a stub or a (transit) relay.


                +-----+     +-------------+         +-------------+
                | APP |-----| Name Server |---...---| Name Server |
                +--+--+     |  interior   |         |   exterior  |
                   |        +-------------+         +-------------+
                   |
               +---+---+
               | TP/IP |
               +---+---+
                   |          Site A                  +--------+
              +--------------------------------+      | Site B |
              |                                |      +---+----+
              |   site = {subnet}              |          |
              |        = {subnet = {node}}     |   +------+
              |        = {node}                |   |
              |   host = stub node           +---+-+  +--------+
              |   router = relay node        | G |----| Site C |
              |   subnet addr = router addr  +---+    +--------+
              |                                |
              +--------------------------------+

   The Internet at one instance of the hierarchy is therefore governed
   by the two-tier administration, i.e., the exterior authority and the
   interior(local) authorities.





DY Kim                 Expires December 19, 2014                [Page 3]

Internet-Draft                    NARA                         June 2014

   A node is named by an address local to a given site.  A subset of
   nodes and an associated router form a subnet.  Being associated with
   a router, each subnet can be identified by the router address.
   Therefore, the subnet address and the router address can be used
   interchangeably.

   A site is bordered by a gateway router, G in Fig.  1. The gateway
   assumes the address which is valid in the exterior tier.  Since each
   site is associated with a gateway, a site is identified by the
   gateway address.  Therefore, the site address and the gateway address
   can be used interchangeably.

   One of the important functions of the gateway is to change addresses
   of packets at their passing in either direction.  There might be two
   ways to accomplish this address change.  One way is address swapping.
   That is, when a packet leaves a site, its source address is swapped
   to the site address.  When entering a target domain, the destination
   address of the packet, essentially the target site address, is
   swapped to a local(interior) address of the target node inside the
   site.  In this scenario, a gateway is identical to a NAT(Network
   Address/Port Translator).

   Another way of address change is encapsulation.  The outgoing packet
   is encapsulated within an outer packet header of which the source
   address is the egress gateway address.  In entering the destination
   site, the outer header is stripped off and the packet is routed
   inside by use of the interior(local) address of the target node which
   is kept in the inner header.

   Exterior routing is done solely on site addresses while interior
   routing on node addresses.  Node addresses are never exposed to
   exterior routing.  This way, the routing table in a tier can be
   maintained to a manageable size.

   In addition to routing, node addresses are also associated with
   transport connections.  In this sense, it can be said that node
   addresses are semantically overloaded.  In NARA, semantic overloading
   of addresses is not considered harmful; it is rather natural and even
   desirable.

   It is assumed that two peer sites use the same addressing scheme.
   Otherwise, meaningful connection cannot normally be established,
   although some complicated measures like address translation might
   provide a detour.  In contrast, the outer tier does not have to
   conform with the same addressing scheme as the interior sites.

   Normally, neither node- nor site-addresses bear topological
   significance; they each consume separate flat number spaces.  Node
   addresses don't change while nodes are moving around within a site.
   Site addresses don't change at migration across upstream network
   providers as well as at multi-homing.




DY Kim                 Expires December 19, 2014                [Page 4]

Internet-Draft                    NARA                         June 2014

   In a rare case of implementation instances, site addresses might bear
   topological significance as with the current Internet.  In this case,
   only the site address would change at migration to a different
   network provider.  At multi-homing in this case, a site can be given
   multiple site addresses from different upstream network providers.

   The domain name of a node would be resloved first to a site address
   by the exterior name server.  An interior name server then resolves
   the rest to a local node address.

   A node in a given site can be a site by itesef.  That is, the node
   can be marked by a gateway and contain children nodes inside.  This
   way, the same network architecture can recur as needed.

3.  ROUTING

   Packets in a site are routed solely on node addresses.  Link-state
   protocols like ISIS is recommended for interior routing.

   Each router maitains a membership table of {target host, associated
   target router}; see Fig.  2. When a host moves from one subnet to
   another, such a move is immediately broadcast by the newly visited
   subnet router to all other routers in the site, resulting in
   immediate update of the membership tables.  In this way, host
   mobility is directly and instantaneouly provided by routers.

   Moving of a subnet is equivalent to moving of the associated router,
   and such a topological change will trigger an immediate link-state
   update.  Henceforth, (subnet) network mobility is also provided as an
   inherent feature of interior routing.

     +------------------------------------------------------------+
     |                    +--------------+      +--------------+  |
     |    +-------+       | +---+  +---+ |      | +---+  +---+ |  |
     |    | 1, 91 |       | | 6 |  | 4 | |      | | 3 |  | 2 | |  |
     |    | 2, 97 |       | +---+  +---+ |      | +---+  +---+ |  |
     |    | 3, 97 |       |    +----+    |      |    +----+    |  |
     |    | 4, 94 |       +----| 94 |----+      +----| 97 |----+  |
     |    | 5, 91 |            +----+                +----+       |
     |    | 6, 94 |             |  |__________________   |        |
     |    +-------+             |                     |  |        |
     |   membership            +----+                +----+       |
     |     table          +----| 91 |----+           | 96 |       |
     |   (common to       |    +----+    |           +----+       |
     |   all routers)     | +---+  +---+ |              |         |
     |  {host, router}    | | 1 |  | 5 | |              |         |
     |                    | +---+  +---+ |              |         |
     |                    +--------------+           +-----+      |
     +-----------------------------------------------| 101 |------+






DY Kim                 Expires December 19, 2014                [Page 5]

Internet-Draft                    NARA                         June 2014

                                                     +-----+

   Packets in the exterior tier are routed solely on site addresses.
   Interior node addresses are not advertised into the exterior tier.

   In the sense of the network graph, each transit site can be
   considered to correspond to a router(relay node) within a site
   whereas a stub site to a host(stub node). That is, symmetry of
   network architecture repeats itself at each tier.  Therefore, the
   same routing features of interior routing can also be applied to
   exterior routing with tranist sites and stub sites in place of
   routers and hosts, respectively.

       +----------------------------------------------------------+
       |  +----+    +----+                   +----+               |
       |  | 11 |    | 37 |                   | 15 |               |
       |  +----+    +----+                   +----+               |
       |     |___    |                         |                  |
       |         |___|                         |                  |
       |  +----+    +-----+                  +-----+    +----+    |
       |  | 25 |----|  1  |------------------|  3  |----| 41 |    |
       |  +----+    +-----+                  +-----+    +----+    |
       |              |  |__________            |                 |
       |              |             |           |                 |
       |              |             |           |                 |
       |  +----+    +-----+         +--------+-----+              |
       |  | 22 |----|  2  |------------------|  4  |              |
       |  +----+    +-----+                  +-----+              |
       |              +----+                                      |
       |              |11,1| {stub, transit}                      |
       |              |15,3|                                      |
       |              |22,2| membership table                     |
       |              |25,1|  (common to                          |
       |              |37,1|  all routers)                        |
       |              |41,3|                                      |
       |              +----+                                      |
       +----------------------------------------------------------

4.  IMPLEMENTATION CHOICES

   Although the proposed network architecture of NARA is described in a
   generic way, it can be tailored for smooth and incremental deployment
   in the existing Internet.

4.1.  Node Address

   In principle, both IPv4 and IPv6 addresses can be used for local node
   addresses.  However, since the range of IPv4 private addresses might
   be enough for most sites, use of IPv4 addresses might be more
   appealing.





DY Kim                 Expires December 19, 2014                [Page 6]

Internet-Draft                    NARA                         June 2014

   The IPv4 addresses do not have to be private addresses, since the
   node addresses are not advertized to the exterior tier.  Use of
   already acquired IPv4 addresses ensures minimal changes to existing
   vast population of IPv4 nodes.  Transition to IPv6 addresses will not
   be a requisite anymore, but a luxurious option at most.

   It is to be noted that IP addresses adopted as such do not name
   interfaces anymore; they name nodes themselves.  That is, although IP
   addresses will continue to be used, their context will be changed.

4.2.  Site Address

   The routing prefix of a given site, i.e., the aggragate address of
   the whole PA(provider-aggregatable) addresses already assigned to the
   site, can be used as the site address.

4.3.  Gateway

   An important funtion of the gateway is to change addresses of packets
   passing throught it.  A gateway can be either a NAT router or a
   tunnel router, depending on the adopted scheme of address change.

4.4.  Name Servers

   DNS working in a strictly hiearchical manner would serve the purpose
   of the name servers of NARA. The FQDN(Fully Qualified Domain Name) of
   a node would be resloved first to a site address by a global name
   server.  A local name server then resolves the rest to a local node
   address.

4.5.  Routing Protocols

   OSPF or ISIS can be used for interior routing.  A difference is that
   IP addresses (as node addresses) now points to nodes instead of
   interfaces.  Changes to OSPF coding should be minimal.  ISIS might be
   preferable since it inherently deals with node addresses.

   Although other protocols, in principle, could also be used for
   exterior routing, BGP4 with PA addresses might be the immediate
   option not much to disturb the current operation of the Internet.

5.  CONSEQUENCES

5.1.  Recursive Internet

   In NARA, the network architectures of the interior and the exterior
   tiers are symmetric, basically the same.  Therefore, the same generic
   architecture can be repeated without bound outwards as well as
   inwards.  For example, in the design of an inter-planetary Internet,
   the same architecture can be placed on top of the global Internet.
   Also, in accommodating IoT (Internet of Things) edge networks which
   by themselves may each consist of a huge number of internal nodes,
   repetition of the same architecture might significantly reduce the
   complexity of the whole-scale networking.

DY Kim                 Expires December 19, 2014                [Page 7]

Internet-Draft                    NARA                         June 2014


   The Internet modeled as with NARA can be asserted to be scalable and
   expandable without bound.

5.2.  No Address Depletion

   Since the global Internet is split into tiers of manageable size,
   there'd be no danger of address depletion.  The 32-bit length for
   node addresses will be more than enough for most sites' need.  The
   same should be true of the site prefixes.  In fact, migration to IPv6
   is not a requirement anymore, but merely a luxurious option.

5.3.  No Inadvertent Internet Governance

   Since sites don't have to buy node address spaces from any
   authorities, the impact of the Internet governance will reduce only
   to a minimal necessity.

5.4.  Fast Mobility

   Host mobility inside a site is provided as default.  Transport
   connections are associated with node addresses which don't change
   while nodes are moving inside a given site.  Transport connections
   don't break at interior host mobility.  Since such mobility is
   directly provided by link-state routing, with periodic link-state
   updates augmented by immediate event-driven broadcasts, host mobility
   is as fast as the frequency and speed of broadcast packet
   propagation.

   Network(subnet) mobility is also provided as an inherent feature of
   the interior routing.  Renumbering of mobile subnets is not necessary
   since each subnet is identified by the associated router address
   which, being itself a node address, does not change inside a given
   site.

5.5.  Site Multi-homing and Migration

   Site addresses don't change at migration to new upstream transit
   sites.

   Site multi-homing with flat address is not a problem, either.  The
   same site address of a multi-homed site will simply be seen
   simultaneously in gateway routing tables of involved upstream transit
   sites.

5.6.  Host Multi-homing









DY Kim                 Expires December 19, 2014                [Page 8]

Internet-Draft                    NARA                         June 2014


   Host multi-homing can also be supported.  If a host is multi-homed on
   multiple sites, there'd be multiple return site addresses for the
   same name from the name server.  Transport connections through
   different sites would be considered as different ones.  If there's
   need to converge these multiple connections to be presented as a
   single virtual transport connection to a given application, a sort of
   session management function might be exploited on top of the
   transport layer as is done with MPTCP[RFC6182].

5.7.  Traffic Engineering

   Gateways of a multi-homed site can control inbound traffic according
   to the remote site addresses.  Interior routers can also choose exit
   gateways in accordance with target site addresses.

   If traffic engineering in the granularity of a node is desired, a
   node may inform the subnet routers of its preferred site address of a
   given remote multi-homed site.  The same can be done for preference
   about the exiting gateway.

5.8.  No Renumbering

   Since node addresses are local, no renumbering of nodes is necessary
   at domain migration or multi-homing.

5.9.  Semantic Overloading

   The current proposal implicitly suggests that semantic overloading of
   an address may not be seen as a fatal problem to a network
   architecture.  The addresses, of nodes and sites, are used both for
   identification and routing in NARA. This contextual malleability of
   addresses is seen as rather a virtue than an evil.  It can also be
   argued that whatever separation one might engineer, semantic
   overloading would inevitably result one way or another and so should
   rather be received as a natural phenomenon of networking.

6.  CONCLUSIONS

   A network architecture based on local and recursive addressing is
   introduced.  The Internet is seen as a collection of sites, each
   being itself a collection of nodes.  Addresses local to a given site
   name nodes whereas exterior addresses do sites.  Mobility, of both
   hosts and subnets, is seamless because it is provided directly by
   routers as one of their inherent operational features.  Frozen site-
   as well as node-addresses guarantee seamless domain migration and
   multi-homing with no need of renumbering.  Address depletion is not
   an issue anymore and the Internet governance reduces to a minimal
   necessity.  The proposed network model can repeat itself outwards as
   well as inwards, enabling its applicability to inter-plenary Internet
   as well as to Internet of Things.

7.  Security Considerations


DY Kim                 Expires December 19, 2014                [Page 9]

Internet-Draft                    NARA                         June 2014


   None.

8.  References

   [GSE]      O'Dell , M., "GSE - An Alternate Addressing Architecture
              for IPv6 draft-ietf-ipngwg-gseaddr-00", February 1997.

   [IEEE-MCOM]
              Kafle, V.P., "An ID/locator split architecture for future
              networks", February 2010.

   [IEN0001]  Hinchley, A., "Issues in the interconnection of datagram
              networks", July 1977.

   [IEN0019]  Shoch, J. F., "Inter-network naming, addressing, and
              routing", January 1978.

   [ILNP]     Atkinson , R., Bhatti, S. N. and U. St.  Andrews, "ILNP
              Architectural Description draft-irtf-rrg-ilnp-arch-03",
              May 2012.

   [IRON]     Templin, F., "The Internet Routing Overlay Network (IRON)
              draft-templin-iron-16", December 2010.

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

   [LISP]     Farinacci, D., Fuller, V., Meyer, D. and D. Lewis,
              "Locator/ID Separation Protocol (LISP) draft-ietf-
              lisp-23", May 2012.

   [RFC1498]  Saltzer, J.H., "On the naming and binding of network
              destinations", August 1993.

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", June 1996.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", May 2006.

   [RFC6182]  Ford, A., "Architectural Guidelines for Multipath TCP
              Development", March 2011.

   [RFC6306]  Frejborg, P., "Hierarchical IPv4 Framework", July 2011.

Author's Address








DY Kim                 Expires December 19, 2014               [Page 10]

Internet-Draft                    NARA                         June 2014


   DaeYoung KIM
   Chungnam University
   InfoCom Eng.
   Daejeon, 305-764
   South COREA
   
   Phone: +82 42 821 6862
   Email: dykim@cnu.kr













































DY Kim                 Expires December 19, 2014               [Page 11]