| Network Working Group | DY Kim |
| Internet-Draft | Chungnam University |
| Intended status: Experimental | October 18, 2012 |
| Expires: April 19, 2013 |
Network Architecture with Recursive Addressing
draft-dykim-nara-00
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 site address drawn from a global number space while each node is named by a node address drawn from a number space local to each site. Routing among sites depends solely on site addresses while that within each site on node addresses. Flat routing to render inherent mobility as well as mapped routing to additionally cope with table size are proposed. The model can recursively repeat itself both outwards and inwards in the network, enabling its applicability, for example, to inter-planetary as well as body area networks.
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 April 19, 2013.
Copyright (c) 2012 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 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 multihoming.
A considerable number of new protocols based on the Loc/ID Separation(LIS) architecture have been proposed thus far. Some of them are host-based solutions [RFC4423][GSE][ILNP][IEEE-MCOM]while others are router-based[LISP][IRON][Ivip]. Most such proposals share one thing; IDs and Locs are global.
This document proposes an architecture, named NARA, based on local addressing in its strict sense. Local addresses, for nodes, are never exploited in DFZ (called exterior in this document) routing. A collection of nodes under an autonomous administration is called a site, and only site addresses identifying them are used for exterior routing. That way, the global network is split into two rather orthogonal tiers.
NARA is very close to the ideas proposed in ENCAPS and hIPv4[RFC1955][RFC6306]. The latter two, however, name node interfaces (or point of attachment: PoA) with either global IP addresses (in ENCAPS) or local Endpoint Locators (in hIPv4), whereas node themselves are named by local addresses in NARA.
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 principle can be recursively repeated inwards and outwards off a given network tier. In this respect, NARA can be considered as one of recursive network architectures.
Following sections describe the architecture of NARA and associated routing, along with implementation choices for a better chance of deployability. Consequences of the proposal are provided before concluding the document.
+-----+ +-------+
| APP |-----| NameS |
+-----+ +-------+
|
+---|---+
| TP/IP |
+---|---+
| +--------+
+----|---------------------------+ | SITE_A |
| | SITE | +--------+
| +------+ +-------+ | |
| | node |-------------| iSITE | | |
| +------+ | +-------+ | |
| +------+ +--|--+ | +--------+
| | node | | G |---| SITE_B |
| +------+ +--|--+ +--------+
+--------------------------------+
The Internet is modeled as a networked collection of autonomous sites. A site is a collection of nodes, also called either hosts(leaf node) or routers(relay nodes). A subset of hosts and an associated router forms a subnet. Therefore, a site can also be considered as a networked collection of subnets. A site itself can be a leaf or a transit.
A site is named by a global site address while a node by a node address local to a given site. Now that each subnet is associated with a router, it can be identified by a router address.
Exterior routing among sites is done solely on site addresses while interior routing on node addresses. Node addresses are not used in exterior routing. That is, exterior and interior routings are orthogonal to each other.
Transport connections are also associated with node addresses. In this sense, it can be said that node addresses are semantically overloaded. In this proposed network architecture, semantic overloading of addresses is not considered harmful; it is considered rather natural and even desirable.
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 also don't change at migration between upstream network providers as well as at multi-homing.
Node names are global. A name server provides mapping between a node name and a {node address, site address} tuple. If the site address is local, packets are delivered to the target interior node by use of an interior routing. If it is foreign, packets are delivered to one of exterior routers, aka gateways, interfacing with other sites.
Packets in the site tier, interior to sites, are routed solely on node addresses. Site addresses don't come into play in interior routing. Any protocols including OSPF and ISIS can be applied to this interior routing.
+------------------------------------------------------------+
| mapper +--------------+ +--------------+ |
| +-------+ | +---+ +---+ | | +---+ +---+ | |
| | 1, 91 | | | 6 | | 4 | | | | 3 | | 2 | | |
| | 2, 97 | | +---+ +---+ | | +---+ +---+ | |
| | 3, 97 | | +----+ | | +----+ | |
| | 4, 94 | +----| 94 |----+ +----| 97 |----+ |
| | 5, 91 | +----+----------------+----+ |
| | 6, 94 | | |________________ | |
| +-------+ | | | |
| +----+----------------+----+ |
| {node,subnet} +----| 91 |----+ | 96 | |
| ={node,router} | +----+ | +----+ |
| | +---+ +---+ | | |
| | | 1 | | 5 | | | |
| | +---+ +---+ | | |
| +--------------+ +-----+ |
+-----------------------------------------------| 101 |------+
+-----+
In a scenario of flat-address routing, node addresses are directly used in routing and forwarding decisions. Each router maintains a table of {target node address, target router address, next-hop router address} tuples. Tables are updated through routing information exchange between routers.
Hosts may not involve themselves directly with such routing tables. It is up to routers to route packets exiting nodes.
When a node moves from one subnet to another, such a membership change is broadcast to all other routers in the site by the previous and/or newly visited subnet router(s). Host mobility provided directly by routers in this way can hence be fast.
When a subnet moves along with the associated router, such a move will be perceived as a topological change of the network and will be reflected in the routing tables at the speed of associated link-state updates. Henceforth, (subnet) network mobility is provided also as an inherent feature of the routing.
In a scenario of mapped-address routing, a common mapping server inside a given site is used in order to shrink the table size of each routers. {target node address, target router address} tuples are maintained by the mapping server whereas router tables will keep only {target node address, next-hop router address} tuples as with usual router activities. At reception of the first packet from a node after a given inactive interval, the router will consult the mapping server for the associated target router address. The associated next-hop router will then be determined by a given routing algorithm. Acquired {target node address, target router address} tuples may be cached at routers but will be short-lived lest stale information be used for mobile hosts.
Hosts themselves need not be aware of existence of the mapping server. They will continue to involve themselves only with node addresses, for source and target, and rely on routers for path finding. They will behave themselves the same way as they do with flat routing.
This scenario of mapped-address routing is very similar to the related operation of cellular networks. This might rather be considered as a merit, for cellular networks are known for their fast mobility.
+----------------------------------------------------------+ | +----+ +----+ +----+ | | | 11 | | 37 | | 15 | | | +----+ +----+ +----+ | | |___ | | | | |___| | | | +----+ +-----+ +-----+ +----+ | | | 25 |----| 1 |------------------| 3 |----| 41 | | | +----+ +-----+ +-----+ +----+ | | | |___________ | | | | | | | | | |___________| | | +----+ +-----+ +-----+ | | | 22 |----| 2 |------------------| 4 | | | +----+ +-----+ +-----+ | | +----+ | | |11,1| | | |15,3| | | |22,2| | | |25,1| | | |37,1| | | |41,3| | | +----+ | +----------------------------------------------------------+
Packets in the global tier, exterior to sites, are routed solely on site addresses. Node addresses are not advertised into the global tier. Any protocols, BGP, OSPF or ISIS, can be applied to this exterior routing.
In a scenario of flat-address routing, site addresses are directly used in routing and forwarding decisions. Each transit gateway maintains a table of {target site address, target transit-site address, next-hop transit-site address} tuples. Tables are updated through routing information exchange between transit gateways. For multi-homed target sites, multiple entries for the same target site may exist with different next-hop transit-site addresses.
Leaf gateways may not involve themselves directly with such routing tables. It is up to transit gateways to route packets exiting leaf sites.
In a scenario of virtual-address routing, aggregatable addresses are used in order to shrink the routing table size. Transit gateways may use PA(provider-aggregatable) prefixes as virtual addresses for routing instead of site addresses. Each site address will then be associated with one or more (for multi-homing) PA prefixes, with such mapping maintained by a mapping server in the global tier. A site address will be converted by an upstream transit gateway to a PA prefix at entering that upstream provider, and the PA prefix will subsequently be converted back to the site address at leaving the upstream provider into the downstream target site.
Leaf gateways themselves need not be aware of existence of such PA prefixes. They will continue to involve themselves only with site addresses, for source and target, and hence behave themselves the same way as they do with flat routing.
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 32-bit might be more than enough for most sites, use of IPv4 addresses might be more appealing.
Use of IPv4 addresses ensures minimal changes to existing vast population of IPv4 hosts. Also, 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 but name nodes themselves. That is, although IP addresses will continue to be used, interpretation of their context will be changed.
32-bit IP addresses can be used for site addresses. The uniqueness of the site addresses will be maintained by the distribution authorities like ICANN.
One might wonder where to carry site addresses. It is proposed to carry them in the IPv4 option field of length 32 bits. It is long enough to accommodate a considerable number of sites that may additionally come into being in the global Internet.
Another option is to follow the scheme proposed in hIPv4. That is, node addresses and site addresses can be swapped by gateways (called Locator Swap Router in hIPv4) at exiting and entering given sites.
In the two-tier model described here, names are globally unique. DNS can continue to be used with a bit of extension; to return {node address, site address} pairs instead of {IP address}.
The scope of names can be an issue in recursive repetition of this network architecture. If the tiers would recurse without bound inwards and/or outwards, demanding uniqueness of names in the entire resultant network may not be feasible because of excessive length of the names.
Name resolution can also be done recursively. For example, if a remote node wants to get a body temperature of a human node, an application message "get body temperature" may first be targeted to the human node of an address pair (node, site), for which a name server as in Fig. 1 has done the mapping. Then, the content of the message may be used to consult another name server encompassing the tier pair one level deeper, that is the tier where the human body belongs and another covering the nodes inside the human body. This name server can then return an address pair (in-human node, human node) to continue address swapping to reach the final thermometer. That is to say, context-awareness may ensure recursive name service.
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 better suited in this sense because it inherently deals with node addresses.
Although other protocols, in principle, could also be used for exterior routing, BGP4 with some modification with virtual-address routing might be a choice more acceptable as a start to most existing ISPs and large transit sites.
The first step towards to introduction of NARA is that site addresses be distributed and managed by naming and numbering authorities like ICANN and regional Internet registries.
DNS shall be recoded or reconfigured to deal with {node address, site address} pairs in place of only {IP address}. Necessary changes would be trivial and so could be done in a global scale with minimal pains.
As far as transport connections are concerned, nothing changes for hosts.
The only change would be reconfigure and enable hosts to put the site address acquired from DNS into the IP option field. There'll be rare need to look into the site address in received packets since it is not associated with transport connections at all; the node address only will be.
If flat-address routing is used, a new column has to be added to the routing table to house target node addresses. Also, membership change of children nodes per each router should be added to link-state update messages.
A potential concern about the flat-address routing is that the number of table entries will considerably increase to accommodate all possible active nodes in a given site. This may be seen as too much a burden for large sites, although it may be quite manageable for small sites. The resultant table size could be economically affordable even for larger sites, considering the current memory technology. Another issue might be the lookup speed for such large tables, for which there might be an ample number of smart implementation techniques.
Benefits from this large flat tables is, however, huge. Mobility, for both hosts and subnets, is provided as an inherent function of routing. No extra infrastructural element is needed, and the provided mobility is very fast, i.e., at the speed of broadcast packet propagation.
If mapped-address routing should be used, the table to be managed by each router will be the same as with usual routing; {target node address, next-hop router address}. Only extra action to be taken is consult an in-site server for {target node address, target router address} mapping, to be cached for persistent continuation of smooth packet flow for an ongoing session. Necessary code changes will be minimal.
Hosts and routers will have to be ready to use IP option fields. It is asserted by a lot of experts that use of the IP option field is not going to work since most routers today, interior as well as exterior, are configured by network operators simply to ignore any IP options.
However, as long as the problem is non-use of an available facility rather than lack of its implementation, it would highly be encouraged to reconfigure the nodes to respond to option fields to switch to the operational mode proposed by NARA.
Another side effect of the use of the IP option field is increasing the packet size by 64-bits; 32 bits for each source and target site addresses. This should, however, be a minimal burden in view of the benefits from the new architecture as well as compared to other new network architectural proposals most of which inevitably increase the packet size.
If mapped-address interior routing is to be used, a mapping server has to be installed inside each site. If virtual-address exterior routing is to be used, another mapping server has to be installed in the exterior (global) tier. Installation and management of such servers involve only central management authorities, not every client nodes or sites, and hence any cost or pains should be confined to a small number of entities.
In NARA, the network architectures of the interior (in-site) and the exterior (global) 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 edge networks like body area networks which by themselves may each consist of a huge number of internal nodes(e.g. in the case of intelligent robots), 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 two 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 32-bit site address length. 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 in-site host mobility. And since such mobility is directly provided by link-state routing, with periodic link-state updates augmented by immediate event broadcast, host mobility is as fast as the speed of broadcast packet propagation.
Network(subnet) mobility is also provided as an inherent feature of 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.
Mobility across sites poses a number of challenges. In order to continue communication in a newly visited site, node authentication will have to take place before anything. Such authentication process may take a considerable number of seconds, if not minutes, hard to guarantee non-breakage of transport connections.
Even if authentication may be swift enough to guarantee sustaining mobile connections, reflection of site changes onto the name server might take at least tens of seconds to converge. If this time lag is not to be borne, the gateway of the previous site might continue redirecting the incoming packets to the newly visited site, just long enough for name servers to converge. Engineering techniques employed by cellular networks might enlighten the detailed design of fast cross-site mobility in NARA.
Site addresses also don't change at migration to new upstream transit sites. Therefore, there's no need for refreshing DNS for nodes inside migrating sites. The only action might be to update the entries for migrating sites in the {site address, PA prefix} mapping server, yet only in the case of virtual-address routing.
Site multi-homing with flat exterior routing 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. In the case of virtual-address routing, multiple entries will exist in the mapping server for the same multi-homed site, a {site address, PA prefix} pair for each upstream transit sites.
Host multi-homing can also be supported. If a host is multi-homed on multiple sites, there'd be multiple return values {node address, site address} for the same name. 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, some 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 sites 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, nodes may involve themselves in informing the subnet routers of their preferred site address of a given remote multi-homed site or even the preferred site address of a given remote multi-homed node. The same can be done for preference about the exiting gateway.
MPTCP can additionally be employed with no impact on the normal NARA operation, to benefit from its implicit traffic engineering capability, too.
Since node addresses are local, no renumbering of nodes is necessary at site 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 in 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 sites name nodes whereas global addresses do sites. Mobility, of both hosts and subnets, is very fast because it is provided directly by routers as one of their inherent features. Frozen site- as well as node- addresses guarantee seamless site 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 body area networks.
None.