Network Architecture with Recursive Addressing

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 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-basedwhile others are router-based. 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. 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 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.

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

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 |------+ +-----+ 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| | | +----+ | +----------------------------------------------------------

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

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.

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.