Network Working Group DY Kim
Internet-Draft Chungnam University
Intended status: Experimental December 17, 2013
Expires: June 20, 2014
Network Architecture with Recursive Addressing
draft-dykim-nara-02
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 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.
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 June 20, 2014.
Copyright Notice
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
DY Kim Expires June 20, 2014 [Page 1]
Internet-Draft NARA December 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . 3
3. INTERIOR ROUTING . . . . . . . . . . . . . . . . . . . . . . 5
4. EXTERIOR ROUTING . . . . . . . . . . . . . . . . . . . . . . 6
5. IMPLEMENTATION CHOICES . . . . . . . . . . . . . . . . . . . 7
5.1. Node Address . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Site Address . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Name Servers . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Routing Protocols . . . . . . . . . . . . . . . . . . . . 8
6. CONSEQUENCES . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Recursive Internet . . . . . . . . . . . . . . . . . . . 9
6.2. No Address Depletion . . . . . . . . . . . . . . . . . . 9
6.3. No Inadvertent Internet Governance . . . . . . . . . . . 9
6.4. Fast Mobility . . . . . . . . . . . . . . . . . . . . . . 9
6.5. Site Multi-homing and Migration . . . . . . . . . . . . . 9
6.6. Host Multi-homing . . . . . . . . . . . . . . . . . . . . 10
6.7. Traffic Engineering . . . . . . . . . . . . . . . . . . . 10
6.8. No Renumbering . . . . . . . . . . . . . . . . . . . . . 10
6.9. Semantic Overloading . . . . . . . . . . . . . . . . . . 10
7. CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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 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
DY Kim Expires June 20, 2014 [Page 2]
Internet-Draft NARA December 2013
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.
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.
DY Kim Expires June 20, 2014 [Page 3]
Internet-Draft NARA December 2013
+-----+ +-------------+ +-------------+
| 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 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 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.
DY Kim Expires June 20, 2014 [Page 4]
Internet-Draft NARA December 2013
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.
3. INTERIOR ROUTING
Packets in a site are routed solely on node addresses. Link-state
protocols like ISIS is recommended for interior routing.
DY Kim Expires June 20, 2014 [Page 5]
Internet-Draft NARA December 2013
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
4. EXTERIOR ROUTING
Packets in the exterior tier are routed solely on site addresses.
Interior node addresses are not advertised into the exterior tier.
DY Kim Expires June 20, 2014 [Page 6]
Internet-Draft NARA December 2013
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| |
| +----+ |
+----------------------------------------------------------
Fig. 3: Exterior Routing of NARA
5. 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.
5.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 June 20, 2014 [Page 7]
Internet-Draft NARA December 2013
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.
5.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.
5.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.
5.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.
5.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.
6. CONSEQUENCES
DY Kim Expires June 20, 2014 [Page 8]
Internet-Draft NARA December 2013
6.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.
The Internet modeled as with NARA can be asserted to be scalable and
expandable without bound.
6.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.
6.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.
6.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.
6.5. Site Multi-homing and Migration
DY Kim Expires June 20, 2014 [Page 9]
Internet-Draft NARA December 2013
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.
6.6. Host Multi-homing
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].
6.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.
6.8. No Renumbering
Since node addresses are local, no renumbering of nodes is necessary
at domain migration or multi-homing.
6.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.
7. CONCLUSIONS
DY Kim Expires June 20, 2014 [Page 10]
Internet-Draft NARA December 2013
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.
8. Security Considerations
None.
9. Normative References
[GSE] O'Dell , M., "GSE - An Alternate Addressing Architecture
for IPv6 draft-ietf-ipngwg-gseaddr-00", February 1997.
[IEEE-MCOM]
Kafle, V., "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., "Inter-network naming, addressing, and
routing", January 1978.
[ILNP] Atkinson , R., Bhatti, S., and U. 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., "On the naming and binding of network
destinations", August 1993.
DY Kim Expires June 20, 2014 [Page 11]
Internet-Draft NARA December 2013
[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
DaeYoung KIM
Chungnam University
InfoCom Eng.
Daejeon 305-764
South COREA
Phone: +82 42 821 6862
Email: dykim@cnu.kr
DY Kim Expires June 20, 2014 [Page 12]