| Network Working Group | DY Kim |
| Internet-Draft | Chungnam University |
| Intended status: Experimental | December 16, 2013 |
| Expires: June 19, 2014 |
Network Architecture with Recursive Addressing
draft-dykim-nara-02
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 a exterior address whereas each node by a interior local address. Exterior routing depends solely on site addresses while interior routing on node addresses. Both interior and exterior routings render inherent mobility as well as seamless multihoming capability. 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.
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 June 19, 2014.
Copyright (c) 2013 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.
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 the identifiers(IDs) and the 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.
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 two-tier networks, 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 deployability are then discussed in the ensuing section. Consequences of the proposal are discussed before concluding the document.
+-----+ +-------------+ +-------------+
| 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 +---+ +--------+
| |
+--------------------------------+
Fig. 1: Architectiral Overview of NARA
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.
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 domain, the destination of the packet address which is essentially the site address is swapped back to a local(interior) address of the target node inside the site. In this scenario, a gateway is essentially a NAT(Network Address/Port Translator) router.
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 preserved 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.
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 FQDN(Fully Qualified 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.
Packets in a site are routed solely on node addresses. Link-state protocols like ISIS is recommended for interior routing.
In addition to usual routing and forwarding tables, each router also maintains a node membership table of {target node, associated target router} tuples. See Fig. 2. When a node moves from one subnet to another, such a membership change is immediately broadcast by the previous and/or newly visited subnet router to all other routers in the site, resulting in membership table update. In this way, host mobility is provided directly by routers.
Moving of a subnet is the same as moving of the associated router, and such a move will be perceived as a topological change of the network and so will be reflected in the routing tables at link-state updates. Henceforth, (subnet) network mobility is provided also as an inherent feature of the routing.
In host mobility, frequent membership change may result in broadcast storms. In order to reduce the number of such storms, only the router of the newly visited subnet may be allowed to broadcast the member addtion to other routers, effetively halfening the total broadcast packets. In this case, a false alarm broadcast could be an issue, which, however, would be mitigated by an appropriate separate security measure.
+------------------------------------------------------------+
| +--------------+ +--------------+ |
| +-------+ | +---+ +---+ | | +---+ +---+ | |
| | 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) | +---+ +---+ | | |
| {node, router} | | 1 | | 5 | | | |
| | +---+ +---+ | | |
| +--------------+ +-----+ |
+-----------------------------------------------| 101 |------+
+-----+
Fig. 2: Interior Routing of NARA
+----------------------------------------------------------+
| +----+ +----+ +----+ |
| | 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| |
| +----+ |
+----------------------------------------------------------
Fig. 3: Exterior Routing of NARA
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.
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.
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.
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 hosts. 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.
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.
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.
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.
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.
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.
The Internet modeled as with NARA can be asserted to be scalable and expandable without bound.
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.
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.
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.
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.
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].
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.
Since node addresses are local, no renumbering of nodes is necessary at domain migration or multi-homing.
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.
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.
None.