Innovating on Naming and Addressing of Computer

Innovating on Naming and Addressing of Computer
Networks by Using Software Defined Networking
Flávio de Oliveira Silva∗† , Maurício Amaral Gonçalves† João Henrique de Souza Pereira∗ ,
Rafael Pasquini† , Pedro Frosi Rosa† , and Sergio Takeo Kofuji∗
∗ Polytechnic
School, University of São Paulo, São Paulo - Brazil
[email protected], [email protected], [email protected]
† Faculty of Computing, Federal University of Uberlândia, Minas Gerais - Brazil
[email protected], [email protected], [email protected], [email protected]
Abstract—Naming and addressing are key aspects of computer
networks. At the current Internet, names are bound to an IP
address and although the initial design was considerably modified
by the use of strategies like Classless Inter-Domain Routing
(CIDR) and Network Address Translation (NAT), requirements
like multihoming, mobility and multicast remain open at the
Internet architecture. Several research groups are engaged in
the design of a new Internet that addresses these and other
requirements. In this scenario, Software Defined Networking
(SDN) represents a new abstraction that can leverage the research
and innovation at this area. This paper presents SDN based
technologies available and discuss how the research community
can use them to experiment new naming and addressing schemes.
Index Terms—SDN, Naming, Addressing, Future Internet
I. I NTRODUCTION
Naming and addressing are key aspects of computer networks. Basically data is sent and received by peers during
communication and the name indicates what is this peer, or
in order words, designates its existence and can identify it
precisely. The address indicates where it is located and by
having its location [11], it would be possible to build a route,
that indicates a way the reach this location and after that,
the communication between two ore more peers would be
possible.
However, what is simple in concept, is not trivial to accomplish in the computer networks, specially inter-connected
networks.
Internet started as a experimental network, the ARPANET,
and when IP was proposed [9], addressing was the only aspect
defined and the mapping between name and addresses was
left to protocols at higher layers. The address defined, was
four octets long and originally the first eight bits represented
the network number and the following the host local address.
If fact the TCP/IP architecture does not define any naming
scheme, but only a mapping between a name and an IP address
that can be flat or hierarchical.
Due to the growth of the Internet and the advent of problems
like the IP address depletion and the scaling in routing,
short-term solutions [3] like the Network Address Translator
(NAT) [3] [14] and Classless Inter-Domain Routing (CIDR)
[4] were deployed, waiting for the long-term solution, IPv6
[2], specified in 1995. After seventeen years, no long-term
solution was fully deployed and the short term solutions were
still in place. This situation demonstrates that changes in
the addressing of the current network is a hard architectural
change. These solutions also indicates that the addressing and
naming issues were not addressed in a proper way and many
patches were deployed to solve questions that arose from
previous ones such as the side effects of NAT to application
protocols[5].
Today in the Internet, communication requirements like
multihoming, mobility and multicast are open issues and
several research groups are engaged in the design of a future
Internet that can satisfy these application requirements. This
research is conducted basically using two approaches, based on
the evolution of the current Internet and a clean slate view, that
frees researchers and foster innovations [10]. Software Defined
Networking (SDN), that basically separates the software from
the hardware of the network elements and offers a open and
well defined interface to control them, is a result of this clean
slate vision.
This paper presents SDN based technologies available and
discuss how the research community can use them to experiment new naming and addressing schemes.
II. NAMING AND A DDRESSING BY U SING SDN
The deployment and experimentation of new naming and
addressing schemes is really difficult even at a laboratory
inside a campus, and to be successfully adopted at the Internet,
these experiments must consider appropriate scales.
In this scenario, where the researchers are locked in their
network, SDN represents an extraordinary opportunity to rethink networks by using some abstractions that decouples the
software that controls the network elements from the hardware
offering a open and well defined interface to control and
modify the hardware behavior.
SDN, currently, is materialized in OpenFlow [7]. Its basic
goal is to enable researchers to innovate in the computer
science field related to networking and communication. Essentially, OpenFlow separates the data plane from the control
plane, defining an OpenFlow switch. While OpenFlow works
with current networks, it can be used to shape and deploy future network architectures, allowing new networking protocols
to be defined and readily experimented in real conditions in
production networks.
An Openflow switch contains one or more flow tables
used for packet lookup and forwarding. Openflow version 1.0,
specify a single table, while versions 1.1, 1.2 and 1.3 specify
a pipeline of them. Each entry in the flow table has a key that
is composed by a series of match fields, that are compared
against the packet. These match fields contain headers from
the protocols of layers two, three, and four of the TCP/IP
architecture. Whenever a packet matches an entry of the flow
table, a set with one or more actions, is executed. Each
OpenFlow version has a different group of possible actions
but, in general, all versions support dropping a packet or
forwarding it to one or more switch ports. When no match is
found, a possible action is forward the packet to the Controller.
The behavior of the switch is driven by the flow table state.
The Controller is responsible for the maintenance of the flow
tables, no matter how many switches are under its control, and
the communication between the switches and the controller
over secure channels uses the OpenFlow Protocol. The ability
to change the switch behavior on the fly by modifying the flow
table makes it suitable to the experimentation of new naming
and addressing schemes.
At the current networks, several approaches may be used
to exploit new addressing and even naming schemes as the
work presented at [6]. The match fields, based on the headers
of current protocols, may be combined in different ways and
multiple flow entries can be used to produce the desired behavior. By using a special controller, the network resources may
be separated into isolated slices [12] enabling the deployment
of these approaches.
At the future networks, SDN can leverage the research of
new naming and addressing schemes, but at this scenario
some issues may arise if you are not considering current
protocols. What about not using IP? Or novel approaches that
do not consider TCP? Do we still need a MAC address? Some
projects like MobilityFirst and XIA [8] are starting to use
OpenFlow to prototype some disruptive ideas that are based
on new naming and addressing schemes.
A problem to face, regarding new network architectures,
is that in most cases another protocol stack is used and,
in this scenario, the headers used to compose keys of the
flow table are not present. To work with OpenFlow 1.0,
deployed currently at hardware and software based switches
some mappings must be executed to prototype the architecture.
OpenFlow 1.2, in turn, has an Extensible Match Support,
enabling the inclusion of a new set of match fields, but it
is only specified at this moment and its not available, even in
software based switches.
Our research group is modeling ideas regarding future
Internet architecture [1] and SDN is leveraging our research
[13]. This research considers a new naming schema based
on the Title, a topology independent designation to ensure
an unambiguous identification of an entity, a thing which
has communication requirements and capabilities that can be
semantically understood from top to bottom layers.
III. C ONCLUSIONS
The naming and addressing scheme are basic aspects of
a network architecture and requirements like multihoming,
mobility and multicast are strictly tied with them.
Several researches groups are engaged in the design of a
future Internet architecture and at this scenario, SDN and
OpenFlow can leverage this research by releasing them from
their current networks and providing the means to innovate,
deploy and experiment future network architectures.
R EFERENCES
[1] Joao de Souza Pereira, Flavio de Oliveira Silva, Edmo Filho, Sergio
Kofuji, and Pedro Rosa. Title model ontology for future internet
networks. In John Domingue, Alex Galis, Anastasius Gavras, Theodore
Zahariadis, Dave Lambert, Frances Cleary, Petros Daras, Srdjan Krco,
Henning Müller, Man-Sze Li, Hans Schaffers, Volkmar Lotz, Federico
Alvarez, Burkhard Stiller, Stamatis Karnouskos, Susanna Avessta, and
Michael Nilsson, editors, The Future Internet. Future Internet Assembly 2011: Achievements and Technological Promises, volume 6656 of
Lecture Notes in Computer Science, pages 103–114. Springer Berlin /
Heidelberg, 2011.
[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Number 1883 in Request for Comments. IETF, December 1995.
Published: RFC 1883 (Proposed Standard) Obsoleted by RFC 2460.
[3] K. Egevang and P. Francis. The IP Network Address Translator (NAT).
Number 1631 in Request for Comments. IETF, May 1994. Published:
RFC 1631 (Informational) Obsoleted by RFC 3022.
[4] Internet Engineering Steering Group and R. Hinden. Applicability
Statement for the Implementation of Classless Inter-Domain Routing
(CIDR). Number 1517 in Request for Comments. IETF, September
1993. Published: RFC 1517 (Historic).
[5] M. Holdrege and P. Srisuresh. Protocol Complications with the IP
Network Address Translator. Number 3027 in Request for Comments.
IETF, January 2001. Published: RFC 3027 (Informational).
[6] Te-Yuan Huang, Kok-Kiong Yap, Ben Dodson, Monica S. Lam, and
Nick McKeown. PhoneNet: a phone-to-phone network for group
communication within an administrative domain. In Proceedings of
the second ACM SIGCOMM workshop on Networking, systems, and
applications on mobile handhelds, MobiHeld ’10, page 27–32, New
York, NY, USA, 2010. ACM.
[7] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar,
Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner.
OpenFlow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69–74, March 2008. ACM ID: 1355746.
[8] Jianli Pan, S. Paul, and R. Jain. A survey of the research on future
internet architectures. Communications Magazine, IEEE, 49(7):26 –36,
July 2011.
[9] J. Postel. DoD standard Internet Protocol. Number 760 in Request
for Comments. IETF, January 1980. Published: RFC 760 Obsoleted by
RFC 791, updated by RFC 777.
[10] Jennifer Rexford and Constantine Dovrolis. Future internet architecture:
clean-slate versus evolutionary research. Commun. ACM, 53(9):36–40,
September 2010.
[11] J. Saltzer. On the Naming and Binding of Network Destinations. Number
1498 in Request for Comments. IETF, August 1993. Published: RFC
1498 (Informational).
[12] Rob Sherwood, Glen Gibb, Kok-Kiong Yap, Guido Appenzeller, Martin
Casado, Nick McKeown, and Guru Parulkar. Can the production network
be the testbed? In Proceedings of the 9th USENIX conference on
Operating systems design and implementation, OSDI’10, page 1–6,
Berkeley, CA, USA, 2010. USENIX Association.
[13] Flavio de Oliveira Silva, Mauricio Amaral Gonçalves, João Henrique
de Souza Pereira, Lasaro Jonas Camargos, Rafael Pasquini, Pedro Frosi
Rosa, and Sergio Takeo Kofuji. Implementing the domain title service
atop OpenFlow. In Anais do III Workshop de Pesquisa Experimental
na Internet do Futuro (WPEIF), pages 38–41, Porto Alegre, May 2012.
Sociedade Brasileira de Computação.
[14] P. Srisuresh and K. Egevang. Traditional IP Network Address Translator
(Traditional NAT). Number 3022 in Request for Comments. IETF,
January 2001. Published: RFC 3022 (Informational).