Innovating on Naming and Addressing of Computer
Transcrição
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).
Documentos relacionados
Domain Title Service for Future Internet Networks
(2007). At Brazil, among others, projects like Horizon described by Moreira et al. (2009) and Web Science introduced by Maculan et al. (2009), are involved with the development of novel networks. T...
Leia mais