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]
