ICONA: Inter Cluster ONOS Network Application

Matteo Gerola, CREATE-NET

 

Landscape

Since the beginning of the Software Defined Networking (SDN) revolution, the control plane reliability, scalability and availability were among the major concerns expressed by Service and Cloud Providers. Existing deployments show that standard IP/MPLS networks natively offer fast recovery in the case of failures. Their main limitation lies in the complexity of the distributed control plane, implemented in the forwarding devices. IP/MPLS networks fall short when it comes to design and implementation of new services that require changes to the distributed control protocols and service logic. The SDN architecture, that splits data and control planes, simplifies the introduction of new services, moving the intelligence from the physical devices to a Network Operating System (NOS), also known as a controller, that is in charge of all the forwarding decisions. The NOS is usually considered logically centralized since it cannot introduce any single point of failure in production environments. Several distributed NOS architectures have been proposed recently to guarantee the proper level of redundancy in the control plane: ONIX [1], Kandoo [2], HyperFlow [3] to name a few.

ONOS (Open Networking Operating System) [4] provides one of the most promising solutions to properly deal with control plane robustness in SDN. ONOS offers a stable implementation of a distributed NOS and was released recently under a liberal open-source license, supported by a growing community of vendors and operators. In ONOS architecture, a cluster of controllers shares a logically centralized network view: network resources are partitioned and controlled by different ONOS instances in the cluster and resilience to faults is guaranteed by design, with automatic traffic rerouting in case of node or link failure. Despite the distributed architecture, ONOS is designed in order to control the data plane from a single location, even in case of large Wide Area Network (WAN) scenarios. However, as envisioned in the work of Heller et al. [5], even though a single controller may suffice to guarantee round-trip latencies on the scale of typical mesh restoration target delays (200 msec), this may not be valid for all possible network topologies. Furthermore, ensuring an adequate level of fault tolerance can be guaranteed only if controllers are placed in different locations of the network.

To this purpose, we designed a geographically distributed multi-cluster solution called ICONA (Inter Cluster ONOS Network Application) which is working on top of ONOS. The main objective of ICONA is to increase the robustness to network faults by distributing ONOS clusters in several locations and further, to decrease event-to-response delays in large scale networks. In the rest of the paper we will consider a large scale WAN use-case under the same administrative domain (e.g. single service provider), managed by a single logical control plane. ICONA is a tool that can be deployed on top of ONOS; a first release is available under the Apache 2.0 open source license [6].

Figure 1

Figure 1: ONOS distributed architecture

Introducing ONOS

ONOS implements a distributed architecture in which multiple controller instances share multiple distributed data stores with eventual consistency. Figure 1 shows the ONOS internal architecture within a cluster of four instances. The entire data plane is managed simultaneously by the whole cluster. With these mechanisms in place, ONOS achieves scalability and resiliency. The Southbound modules manage the physical topology, react to network events and program/configure the devices leveraging different protocols. The Distributed Core is responsible for maintaining the distributed data stores, electing the master controller for each network portion and sharing information with the adjacent layers. The Northbound modules offer an abstraction of the network and the interface for the application to interact and program the NOS. Finally, the Application layer offers a container in which third-party applications can be deployed. ONOS leverages on Apache Karaf [7], a java OSGi based runtime, which provides a container on to which various components can be deployed. Under Karaf, an application, such as ICONA, can be installed, upgraded, started and stopped at runtime, without interfering other components.

Figure 2

Figure 2: ICONA architecture: the data plane is divided in portions interconnected through so-called inter-cluster links (in red). Each portion is managed by multiple co-located ONOS and ICONA instances, while different clusters are deployed in various data centers.

ICONA Architecture

The basic idea behind ICONA is to partition the Service Provider’s network into several geographical regions, each one managed by a different cluster of ONOS instances. While the management of the network is still under the same administrative domain, a peer-to-peer approach allows a more flexible design. The network architect shall select the number of clusters and their geographical dimension depending on requirements (e.g. leveraging on some of the tools being suggested within the aforementioned work [5]), without losing any feature offered by ONOS and without worsening the system performance. In this scenario, each ONOS cluster provides both scalability and resiliency to a small geographical region, while several clusters use a publish-subscribe event manager to share topology information, monitor events and operator requests.

The ICONA control plane is geographically distributed among different data centers, each one controlling the adjacent portion of the physical network. Figure 2 shows the aforementioned architecture where each cluster is located in a different data center (e.g. ONOS 1a and ONOS 1b are co-located instances). To offer the same reliability already available in ONOS, the ICONA application runs on top of each instance. Referring on Figure 1, ICONA is deployed in the Application layer, and interacts with ONOS using the Northbound API.

The communication between different ICONA instances is currently based on a multicast event-based messaging system, inspired by Java Messaging System (JMS). Applications (e.g. controllers) can publish a message, which will be distributed to all instances of the application that are registered to JMS. The application is internally divided in three modules (see Figure 2):

  • Topology Manager (TM): is responsible to discover the data plane elements, reacts to network events and stores in a persistent local database, the links and devices with the relevant metrics.
  • Service Manager (SM): handle all the interaction between the network operators and ICONA.
  • Backup Manager (BM): If a failure happens within the same cluster, ONOS takes care of rerouting all the paths involved in the failure. If instead the failure happens between two different clusters, then the ICONA’s BM module will handle the failure.

The ICONA full paper [8] contains more information on this application and experimental comparison results between ONOS and ICONA.

Wrap-Up

ICONA (Inter Cluster ONOS Network Application) is a tool built on top of ONOS distributed controller with the aim to enable clustering of ONOS instances across different locations in a Wide Area Network. ICONA is based on a pragmatic approach that inherits ONOS features while improving its responsiveness to network events like link/node failures or congested links that impose the rerouting of a large set of traffic flows. We are collaborating with ON.Lab to evaluate the opportunity to include some of the ideas developed therein as part of the official ONOS release.

 

References

[1] T. Koponen, M. Casado, N. Gude, J. Stribling,
L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, and S. Shenker. Onix: A distributed control platform for large-scale production networks. 9th USENIX Conference on Operating Systems Design and Implementation, 2010.

[2] H. Y. Soheil and Y.Ganjali. Kandoo: a framework for efficient and scalable offloading of control applications. First workshop on Hot topics in in software defined networking, 2012.

[3] A. Tootoonchian and Y. Ganjali. Hyperflow: a distributed control plane for openflow. 2010 internet network management conference on Research on enterprise networking, 2010.

[4] P. Berde, M. Gerola, J. Hart, Y. Higuchi,
M. Kobayashi, T. Koide, B. Lantz, B. O’Connor, P. Radoslavov, W. Snow, and G. Parulkar. Onos: towards an open, distributed SDN OS. Third workshop on Hot topics in in software defined networking, 2014.

[5] B. Heller, R. Sherwood, and N. McKeown. The controller placement problem. First workshop on Hot topics in in software defined networking, 2012.

[6] Icona software - https://github.com/smartinfrastructures/dreamer.

[7] Apache karaf - http://karaf.apache.org/.

[8] ICONA full paper - http://arxiv.org/abs/1503.07798

 


 

Matteo GerolaMatteo Gerola is a software architect and senior research engineer at Future Networks unit at CREATE-NET research center. His main research interests focus on SDN, Network Virtualization and OpenFlow. Within CREATE-NET he has been involved in several European projects on SDN, optical technologies, and Future Internet test-beds. He has published in more than 20 International refereed journals and conferences. Along the years, he has participated to events, conferences and workshops as TPC member, author and invited speaker. He is an active member of the Open Network Operating System (ONOS) community, and an ON.Lab alumnus.

 

Editor:

Jose M. Verger is a networking industry veteran who has worked in new product development, engineering and product management for Cisco Systems, 3COM, Bell Communications Research (Bellcore), AT&T and multiple successful start-ups such as Sentient Networks, Point Red and Wavezero. Currently Jose is at Verizon focusing on mobile public networks architecture and planning for enterprise services including the virtualization efforts.

 

SDN Architectural Limitations: Towards a Full Software Network Vision

Sven van der Meer, Ericsson NM Labs, Athlone, Ireland; and Eduard Grasa, Fundació i2CAT, Barcelona, Spain

 

In spite of being only a few years old as a technology, Software Defined Networking (SDN) has jumped from research labs to the product portfolio of most of the big networking industry players and a myriad of innovative start-ups. SDN has changed our perception of the network, the same way cloud computing has not long ago done for computing and storage. It has decoupled control software from specialized forwarding hardware by virtualising underlying physical resources and provided (semi-) standardized interfaces to the virtualized hardware resources; allowing for an increased service deployment agility. However, we argue that SDN in its current incarnation is just the beginning of the network softwarisation trend, since it still carries too much heritage from legacy telecommunication network architectures.

Figure 1

Figure 1 SDN Architecture Overview (ONF)

Figure 1 describes the architecture of Software Defined Networks as defined by the Open Networking Foundation (ONF) [1]. SDN architecture is composed by four main entities:

  • Interconnected network elements in the data plane, which communicate between a number of endpoints.
  • One or more SDN controllers in the “controller plane”, each one hosting the functions to control one or more network elements and exposing “network services” to applications via an API.
  • SDN applications that interact with the network services offered by the controller layer.
  • OSS systems that provide supporting management functions and integrate the SDN with the remaining provider infrastructure.

A brief analysis of this picture leads to the conclusion that SDN –as defined by ONF- sees the network as a set of forwarding devices that can be controlled by logically centralized software controllers via well-defined APIs. This view is essentially the same as classical telecommunication networks dating back to telephony, in which a physical network moves data between endpoints of physical devices. Yet we are in the 21st century, where computer networking is part of a global distributed computing platform, providing connectivity and performance to a diverse set of applications with varying requirements.

While the control aspects are now detached from the physical network and can be abstracted out and programmed, the network is essentially presented as a flat collection of physical devices forwarding data between interfaces. In this paradigm, applications are not first-class network citizens, presented with a network endpoint (IP address plus transport port number) and a very limited service choice: Sockets, the standard application-network API, only allow applications to request a reliable or an unreliable service, with no way to express their performance needs such as maximum delay or packet loss. The lack of application names in the network also exacerbates issues such as security, multi-homing and mobility [2].

The structural organization of the “data plane” functions is another limitation of the current SDN approach. Network functions are usually organized in stacks of layers, each one traditionally performing a different function (physical access, medium access control, network addressing and routing and end-to-end transport) implemented by different protocols. However the theoretical simplicity of the functional layering model doesn’t work in practice. Through the years, multiple “enhancements” to the basic model have been made to address scalability and security problems such as: “tunnels”; “layers 2.5” and “virtual layers”, leading to an ever-increasing protocol base [3] which causes network complexity to grow. SDN promises to simplify management of such networks by “virtualizing” the network resources belonging to different layers and offering them to the control functions via simplified models, but does nothing to attack the root of the problem, which is the structure of the “data plane” per se.

In fact, the concepts of “control” and “data” planes are borrowed from telecomm networks; do they help in defining the software networks of the future? Or are they a barrier to completely transforming how we perceive, design, deploy and operate networks? What if we used different concepts to define a network architecture without having to think in hardware constraints? Some people have started doing that under the RINA (Recursive InterNetwork Architecture) effort [4], and the resulting architecture is surprisingly simple and elegant (Figure 2). First of all, networking is a distributed application (if it uses computers what else could it be?), specialized to provide communication services to other applications: networking is Inter Process Communications or IPC1. Second, networking is recursive: layers provide communication services to each other, over a given scope and range, but don’t have fundamentally different functions. Third, all the layers in a network have the same basic functions, but customized to the operating environment for which they have been designed (e.g. a VPN layer vs a network layer vs a layer managing a wireless link). Last, but not least. all the layers provide the same API, which allows applications on top to request communication services to each other by name, specifying the characteristics required by each service (delay, jitter, loss, etc).

Figure 2

Figure 2 Example of the RINA structure

Such a network architecture minimizes the number of protocols required to support all forms of computer networking, thus bounding complexity and facilitating network management; natively supports virtualization, since the number of layers in each network is decided by the network designers, not the architecture; enables the programmability of all networking functions; and completely unifies networking and distributed computing, since the network is just a set of specialized distributed applications that provide IPC. Notice that concepts such as “physical” or “virtual” network elements are irrelevant for the architecture, what matters is how the different functions are organized into layers and how they interact with each other. Which functions will be deployed in specialized silicon/general purpose hardware/Operating Systems become matters of implementation requirements.

Summing up, SDN initiatives to date have opened the door to changing the perception of how we see networks, but have only focused on the “control aspects” of our current “old-telecom-style” computer networks. Although the benefits gained by this transformation alone are large, they are only a small piece of the potential pie. Realizing the full software network vision, being explored by initiatives such as RINA, will be the complete game-changer.

 

1 The quote is from Robert Metcalfe in 1972.

 

References

[1] Open Networking Foundation, “SDN architecture, Issue 1”. ONF TR-502, June 2014.

[2] J. Day. “How in the heck do you lose a layer?” 2011 International conference on the network of the future.

[3] IETF statistics. “RFCs per year”. Available online: http://arkko.com/tools/rfcstats/pubdistr.html

[4] J. Day, I. Matta, K. Mattar. “Networking is IPC: A guiding principle to a better Internet”. ACM CONEXT 2008.

 


 

Dr. Sven van der Meer received his PhD in 2002 from Technical University Berlin. He joined Ericsson in 2011 where he is currently a Master Engineer and team leader in the Ericsson Network Management Labs. Most of his current time is dedicated to designing and building advanced policy systems that can be used to direct the behaviour of complex event management systems. In the past, Sven has worked with Fraunhofer FOKUS, Technical University Berlin and the Telecommunication Software and Systems Group (TSSG) leading teams and projects, consulting partners and customers, and teaching on university level. He is actively involved in the IEEE CNOM community as standing member of programme committees (IFIP/IEEE IM, IEEE/IFIP NOMS amongst others) and in organising successful workshop series (IEEE MACE, IEEE MUCS, IEEE ManFed.Com amongst others). He also contributed to standardisation organisations, namely the OMG and the TM Forum. He has published in more than 100 articles, conference proceedings, books, conference papers and technical reports. He has supervised and evaluated 6 PhD and more than 30 M.Sc. students.

 

Eduard GrasaDr. Eduard Grasa graduated in Telecommunication Engineering at the Technical University of Catalonia (UPC, July 2004) and got his Ph.D. (UPC, February 2009). In 2003 he joined the Optical Communications Group (GCO), where he did his thesis on software architectures for the management of virtual networks in collaboration with i2CAT, which he joined in 2008. He has participated in several national and international research projects. His current interests are focused on the Recursive Internetwork Architecture (RINA), a clean-slate internetwork architecture proposed by John Day. He was the technical lead of the FP7 IRATI project, where a RINA Prototype for Linux over Ethernet was researched; and is currently the technical lead of the FP7 PRISTINE project, investigating the programmability and distributed management aspects of RINA.

 

Editor:

Neil DaviesNeil Davies is an expert in resolving the practical and theoretical challenges of large scale distributed and high-performance computing. He is a computer scientist, mathematician and hands-on software developer who builds both rigorously engineered working systems and scalable demonstrators of new computing and networking concepts. His interests center around scalability effects in large distributed systems, their operational quality, and how to manage their degradation gracefully under saturation and in adverse operational conditions. This has lead to recent work with Ofcom on scalability and traffic management in national infrastructures.

Throughout his 20-year career at the University of Bristol he was involved with early developments in networking, its protocols and their implementations. During this time he collaborated with organizations such as NATS, Nuclear Electric, HSE, ST Microelectronics and CERN on issues relating to scalable performance and operational safety. He was also technical lead on several large EU Framework collaborations relating to high performance switching. Mentoring PhD candidates is a particular interest; Neil has worked with CERN students on the performance aspects of data acquisition for the ATLAS experiment, and has ongoing collaborative relationships with other institutions.

 

SDN in NFV Architectural Framework

Marie-Paule Odini, HPE

 

With NFV focusing on the virtualization of network functions, and SDN focusing on the decoupling of control and data plane, combining the two is now a hot topic in the telecom community. ETSI NFV has recently published GS NFV-EVE 005 a Report on SDN Usage in NFV Architectural Framework that analyzes architecture, design patterns and use cases to drive some recommendations for the NFV community. Some of these recommendations are already included or investigated for ETSI NFV Release 2 specifications are in progress, and further work may be conducted for other topics. This article provides some highlights of the main topics.

One of the first element that is described is the positioning of SDN controller in ETSI NFV architectural framework (Fig 1)

  • 1- SDN controller as a VIM, Virtualized Infrastructure Manager
  • 2- SDN controller as a VNF
  • 3- SDN controller in the NFVI
  • 4- SDN controller in the OSS/BSS
  • 5- SDN controller as a PNF

For some of these cases, some recommendations were articulated, such as:

  • REC#2: support of the SDN controller as a PNF
  • REC#22: requirement be specified for the Nf-Vi interface to support operations going to an SDN controller.

Figure 1

Fig 1. SDN controller in NFV architectural framework (source: ETSI NFV GS-EVE 005)

Further positioning were studied for SDN resources, SDN applications but also interactions between those different elements and the need for new reference points.

Another aspect that was also investigated was the relationship that the SDN controller may have with its environment being SDN resources and SDN applications, but also with other SDN controllers and with NFV Management and Orchestration. While the first two are pretty well covered in the industry between standards, open source and vendor implementations, the other two: controller to controller whether it is for hierarchy or federation, and controller to NFV Orchestrator to synchronize some NFV and SDN topologies, or orchestration, are still immature and require further study as recommended in REC#4 (Fig 2).

Figure 2

Fig 2. SDN controller interfaces (source: ETSI NFV GS-EVE 005)

This whole study was conducted with contributions from over 30 different companies and contributors, and supported by some real case implementation with more than 14 ETSI NFV Proof of Concepts (POC) that combined SDN with NFV and provided concrete feedback to the team. As an example the following POC#34 conducted by Hewlett Packard Enterprise with Telenor, Vodafone and other vendors, demonstrated at the SDN World Congress in Dusseldorf and at MWC’16, reported on the usage of SDN in a vEPC (Fig 3.)

Figure 3

Fig 3. SDN enabled Virtual EPC – ETSI NFV POC#34 (source: ETSI NFV)

This case is particularly interesting as it paves the road for 5G with next generation mobile core decoupling the control plane and data plane and introducing SDN and NFV combined and orchestrated across multiple domains, and multivendor environments.

The interconnections of different domains is a critical topic in a telecom network with multiple data centers and distributed architecture. As such the notion of partitioning and multi-site was discussed and also presented to OPNFV and OpenDaylight to ensure that support of multiple SDN controllers under a VIM being OpenStack for instance was taken into account (Fig 4).

Figure 4

Fig 4. NFVI-PoP interconnection with pre-provisioned static pipe (source: ETSI NFV GS-EVE 005)

This type of scenario was further refined exploring the different dimensions of WAN underlying options, but also having multiple administrative domain sharing NFVI-PoPs. One example of those is the following Fig 5 that highlights a case where Service Provider A1 with his own NFV Orchestrator has resources deployed in multiple domains, one being A2 with its own VIM A2 and the other being A1 with its VIM A1 and A1 resources, that is hosted in another service provider B1 NFVI-PoP. This case brings many interesting configuration aspects, such as the interactions between SDN Controller A1 and SDN controller A2 and the potential risk that A1 introduces some unexpected flows in A2 SDN environment, which has been leading to recommendation REC-SEC#3 on attack mitigation, but this also brings the questions of having the A1 NFVO coordinate between the WAN Infrastructure Manager/SDN controller (WIM and underlying layers) and the VIM A1 and A2 to ensure proper configuration of the end to end path across these different domains.

Figure 5

Fig 5. Multiple trust domain (source: ETSI NFV GS-EVE 005)

Overall the topic is pretty complex and while the team was conscious that some design pattern may have been underestimated, the main ones have been covered to highlight some of the main principles. As SDN gets deployed in carrier networks, a use case that comes to mind is the transport network and the different layers between optical, Ethernet, underlay, overlay and the hierarchy of SDN controllers. This has been illustrated with a failure and switchover scenario in Fig 6: typically if the SDN controller in charge of the primary line detects a failure, he will report an alarm to the upper layer SDN controller that will trigger the switchover to the backup line.

Figure 6

Fig 6. SDN controller hierarchy and failover scenario (source: ETSI NFV GS-EVE 005)

Last but not least, Service Chaining is also a hot topic when talking SDN with NFV. Extensive studies were conducted with ETSI NFV POCs, typically POC#28 in conjunction with ONF, led by Huawei, POC#33 led by NTT Labs and POC#37 with China Mobile and HPE. These POCs leveraged the Service Function Chaining (SFC) RFCs and draft produced by IETF SFC architecture and contributed to clause 5.8 of the ETSI NFV report. In parallel a review of SDN controller open source projects was performed which indicated that SFC was implemented in a similar way in OpenDaylight based on IETF principles and using LISP and other mechanism quite popular in the market. With OPNFV integrating OpenDaylight and SFC with OpenStack, the road to SDN & NFV is getting brighter and brighter with more and more aligned across the industry.

 


 

Marie-Paule OdiniMarie-Paule Odini holds a master's degree in electrical engineering from Utah State University. Her experience in telecom experience including voice and data. After managing the HP worldwide VoIP program, HP wireless LAN program and HP Service Delivery program, she is now HP CMS CTO for EMEA and also a Distinguished Technologist, NFV, SDN at Hewlett-Packard. Since joining HP in 1987, Odini has held positions in technical consulting, sales development and marketing within different HP organizations in France and the U.S. All of her roles have focused on networking or the service provider business, either in solutions for the network infrastructure or for the operation.

 

Editor:

Antonio ManzaliniAntonio Manzalini received the M. Sc. Degree in Electronic Engineering from the Politecnico of Turin. In 1990 he joined CSELT, which then became Telecom Italia Lab. He started his activities on research and development of technologies and architectures for future optical networks. In this RTD avenue, he was actively involved in leading positions in several EURESCOM and EC funded Projects (e.g., MWTN, LION, NOBEL). He chaired (during two consecutive Study Periods) two ITU-T Questions on transport networks. He is author of a book on Network Synchronization (for SDH) and his RTD results are published in more than 110 papers. In 2008 he was awarded the International Certification of Project Management by PMI. He was member of technical and program committee of several IEEE Conferences. He is Chairing the IEEE SDN Initiative, leading a technical community of 2600 participants. He is currently joining the Strategy and Innovation Dept. of Telecom Italia addressing innovation activities mainly concerning future Telco-ICT networks and services technologies (e.g., Software Defined Networks, Network Function Virtualization and 5G).

http://ieee-sdn.blogspot.it/
https://twitter.com/a_manzalini

 

SDN in LANs: Programming the Network to Secure IoT Traffic

Nicolas Le Sauze and Mathieu Boussard, Nokia Bell Labs

 

Context: both SDN and high-end IoT gaining maturity

In today’s world, we are surrounded by more and more connected devices, collecting data and offering services to ease every aspect of our connected lives. Whether it is for work, leisure, health, etc., we will increasingly interact with smart devices that we either own, or that are made accessible to us by third parties as different as friends or smart city providers. However, recent studies have shown that end users are concerned about the privacy and security issues this future is introducing [Trustee2015]. Hurdles include:

  1. security, as some of these devices may not be powerful enough to handle strong security processes and as such can become an attack vector towards other devices;
  2. data privacy, as we often don’t know when and how our personal data is collected, and by whom and for what purpose.

In parallel, the advent of Software Defined Networking (SDN) is profoundly transforming how networks are managed. Introduced in data centers to cope with the “cloudification” of software services and the associated demands for more scalability, fast deployment and reconfiguration, SDN is now also starting to commercially impact core and access networks. Yet, SDN applicability to home LANs remains so far a limited research area [SIGCOM2011]. Historically, our home networks were tightly bound to the physical space of the home, relying on locally significant Layer 2 protocols and interconnecting with the outside world through an Internet Gateway. For example, the Universal Plug and Play (UPnP) protocols enable automatic detection and consumption of services offered by devices at home. The two drawbacks of this legacy are:

  1. it requires a large degree of openness within the LAN so that unicast and multicast traffic can flow freely between devices, when security and privacy concerns would rather advocate for more control, e.g. through isolation, between devices of the LAN; and
  2. we now live in a world where we want to have access to our home devices from anywhere, imposing complex Internet Gateway configuration procedures. More recent solutions avoid such problems by having connected devices work in silos and in relation with an external cloud service - but this introduces the aforementioned loss of control for the users, and a possible additional complexity to create interactions between devices from different service providers.

SDN benefits can remove remaining barriers for a faster and wider adoption of IoT devices in the home

The above considerations motivated our research of a Smart Environment Controller (SEC) to break silos between devices and networks by securely mixing resources within and across multiple IoT-based smart environments [ITC2015].

a)Figure 1a
b)Figure 1b

 

Figure 1: a) Smart Environment Controller (SEC) for home network and device fine-grain control, b) creation of a multi-location Software-Defined LANs between two remote homes.

Relying on SDN principles, the SEC creates a clear separation between the data/forwarding plane, the control and management plane, and the application plane (Figure 1a). Physical devices are represented as virtual objects (VO) to hide the underlying device-specifics [WoT2011], while the network controller enables controlled communication between devices thanks to a dynamic programming of the Open vSwitch (ovs)-based home gateway through OpenFlow commands. Acting as a software intermediary between the applications and the data plane, the SEC receives simple commands from the user to authorize communications between groups of devices that we called Communities of Virtual Objects (CoVO). The resulting network configuration for each CoVO is therefore called a Software-Defined LAN (SD-LAN): all specified devices of the CoVO can communicate as if they were on the same physical LAN (i.e. through unicast or multicast), while being isolated from non-participating devices. It is possible to have CoVOs spanning different domains, by coordinating the corresponding SEC components to establish communication links through appropriate tunnelling mechanisms (e.g. GRE, VXLAN). The resulting SD-LANs span multiple physical LANs, allowing distant end-users to easily and safely share devices with each other (Figure 1b). In [ITC2015], we report the results obtained with a first prototype enabling to realize the scenario of Figure 1, and for which we developed all components of the SEC, as well as an accompanying Android application providing a user interface to manage devices and CoVOs. Besides the CoVO business logic implementation and related interfaces, the SEC embeds a network controller implementation responsible for translating CoVO definitions into the proper Openflow-based forwarding rules to realize the corresponding SD-LAN. It is important to note that this implementation may either be instantiated in an ISP service suite or in a pure over-the-top mode. Software components may also run a physical box in the home (ISP gateway or additional IoT gateway) or partially in an edge-cloud. Such discussions are left for further studies, as it leads to very different business models and technical implementations, e.g. for interconnecting users from different ISPs.

Beyond home scenarios, a revolution for any smart environment

By enforcing network control (isolation, connection, monitoring), SD-LANs represent a straightforward manner to meet end-user expectations for better control of their security and privacy in smart environments. Through a simple user interface, we enable a fine-grained network control, while removing the technical hurdles generally associated with interconnecting multiple physical environments. Our approach allows building service-oriented overlay networks, dynamically following users and their evolving needs as suggested on the Figure 2. For instance, a user could create a number of service-specific CoVOs resulting in various shared or private SD-LANs.

Figure 2

Figure 2: Example of Service-oriented SD-LANs in/between home and business environments

The figure 2 also illustrates that different smart environments can be controlled in order to take into account the multiple identities of end-users (me and my devices at work, me and my devices at home). For example, in the enterprise domain, SD-LANs facilitate accommodating Bring Your Own Device (BYOD) behaviours. They improve network security by allowing both end-users and corporate network administrators to create specific isolated slices with well-defined characteristics. They can also advantageously be used in smart building scenarios to isolate fleets of devices while imposing specific networking characteristics among them. In the smart city domain, various silos can be enforced (e.g. for security/privacy purposes) or, on the contrary, intersected with a fine-grained control (by instantiating SD-LANs encompassing selected devices from different silos, and only those). More interestingly, and when authorized, SD-LANs can be created across these various domains and actors, for instance to add a private home device to a fleet of smart city devices or to define a short-lived connection between a corporate device and a home device with a specified Quality of Service (QoS).

Our first results show that there is great value for the end-user in considering the network of the Internet of Things not as a “dumb” pipe but as a key enabler of her security and privacy – it is about time we put the user back in control of her network, and as a result of her connected life!

 

[Trustee2015] https://www.truste.com/resources/privacy-research/us-internet-of-things-index-2015/

[SIGCOM2011] Y. Yiakoumis, K.-K. Yap, S. Katti, G. Parulkar, and N. McKeown, “Slicing home networks,” in Proceedings of The 2nd ACM SIGCOMM Workshop on Home Networks, 2011, pp. 1–6.

[ITC2015] Boussard, Mathieu; Bui, Dinh Thai; Ciavaglia, Laurent; Douville, Richard; Pallec, Michel Le; Sauze, Nicolas Le; Noirie, Ludovic; Papillon, Serge; Peloso, Pierre; Santoro, Francesco, "Software-Defined LANs for Interconnected Smart Environment," in Teletraffic Congress (ITC 27), 2015 27th International , vol., no., pp.219-227, 8-10 Sept. 2015

[WoT2011] M. Boussard, B. Christophe, O. Le Berre, V. Toubiana, "Providing user support in Web-of-Things enabled Smart Spaces" in proceedings of the 2nd International Workshop on the Web of Things (WoT 2011). ACM, San Francisco, USA, June 2011

 


 

Nicolas Le SauzeNicolas Le Sauze received his engineering degree in 1998 from the ENST Bretagne in France and joined the Alcatel corporate research centre to work on optical packet switches and optical Ethernet solutions for metropolitan networks until 2006. He then acted as research manager with Alcatel-Lucent Bell Labs in Villarceaux, leading various projects on Ethernet and IP technologies and related control protocols. From 2010 to 2013, he led the FP7 ETICS project on solutions and business models for inter-carrier QoS management. Since 2014, his research interests revolve around the evolutions of network protocols and network solutions in support of the emerging Internet of Things challenges.

He authored or co-authored around 30 technical papers in peer-reviewed international conferences or journals, and owns over 20 active patents.

 

Matthieu BoussardMatthieu Boussard is a research fellow at Nokia Bell Labs. He received his engineering degree from the French ‘Institut National des Télécommunications’ in 2000, specializing on parallel and distributed computing. After working as a Guest Researcher at the National Institute of Standards and Technologies (NIST) on clustering environments, he joined telecom manufacturer Alcatel as a development and system engineer in 2001.

In 2004, he joined Alcatel’s Research & Innovation division, working on context-aware systems, multimodal user interfaces research and mobile and ubicomp applications, taking part in and coordinating multiple internal and collaborative research projects. During 2010-2013, he has been leading internal research projects investigating Web of Things and Smart Environments. Since 2014, he has been investigating the applicability of Software-Defined Networking to Internet of Things security and applications.

He has co-authored over 20 peer-reviewed publications and 20 patents.

 

Editor:

Stefano SalsanoStefano Salsano is Associate Professor at the University of Rome Tor Vergata. His current research interests include Software Defined Networking, Information-Centric Networking, Mobile and Pervasive Computing, Seamless Mobility. He participated in 16 research projects funded by the EU, being Work Package leader or unit coordinator in 8 of them (ELISA, AQUILA, SIMPLICITY, Simple Mobile Services, PERIMETER, OFELIA, DREAMER/GN3plus, SCISSOR) and technical coordinator in one of them (Simple Mobile Services). He has been principal investigator in several research and technology transfer contracts funded by industries (Docomo, NEC, Bull Italia, OpenTechEng, Crealab, Acotel, Pointercom, s2i Italia) with a total funding of more than 1.3M€. He has led the development of several testbeds and demonstrators in the context of EU projects, most of them released as Open Source software. He is co-author of an IETF RFC and of more than 130 papers and book chapters that have been collectively cited more than 2300 times. His h-index is 27.

 

IEEE SDN/NFV Standardization

Niranth Amogh, Huawei; Alex Gelman, Director - IEEE ComSoc Standards Program Development Board; and Mehmet Ulema, Director - IEEE ComSoc Standards Development Board

 

1. Introduction

Software Defined Networking (SDN) and Network Functions Virtualization (NFV) are being increasingly applied to a variety of communication networks including mobile and computer networks. The key characteristics of SDN and NFV are modularization of hardware and software, virtualization at all levels of network, multi-tenancy via supporting multi user control of resource and provision of strong isolation of control, and centralization of control and programmability.

A key question remains - How does software defined and virtualized networks provide a paradigm shift in the way application and services are designed and interact with these networks? There is a need to evaluate impact on end users, network and service providers.

There are a number of technical aspects which impact several network elements concerning SDN and NFV. Several key areas need to be addressed for standardization in order to accelerate the adoption of networks evolving with SDN and NFV. Several standardization bodies like ETSI, IETF, ONF, 3GPP, and IEEE itself are involved in standardizing different technical aspects.

This paper introduces the projects of IEEE Standards Association towards standardizing key issues surrounding SDN and NFV.

 

2. IEEE Standardization Efforts

2.1 Standard for Service Overlay Networks

“Next Generation Service Overlay Networks (NGSON)” is an effort to standardize a service ecosystem for the benefit of network operators, service and content providers, and end users. Protocols are being developed for service composition [1], content delivery [2] and self-organizing management [3].

A reference framework of IP-based service overlay networks for collaborative and customer-centric service delivery has already been standardized [4]. It includes context aware, dynamically adaptive, and self-organizing network capabilities such as advanced routing and forwarding schemes.

The below figure provides an illustration of an offered service model of NGSON.

Figure 1

Figure 1: NGSON offered service

NGSON also aims to accelerate the proliferation of SDN services and applications and to offer a more efficient way of providing them through a service architecture ecosystem of one-stop shopping for service specific challenges.

2.2 Standards for SDN/NFV Security, Performance and Reliability

It is well known that lack of quality modeling (security, performance, reliability) increases Capital Expenses (CAPEX) as well as Operational Expenses (OPEX) of the networks. There are several motivations from the perspective of quality which require standards development such as security and performance degradation for services delivered over SDN/NFV, creation of outage database, identification of level of resilience/service quality, identification of Key Performance Indicators (KPIs), cross layer optimizations, reliability models/schemes, Quality of Service (QoS) and impact of Service Level Agreements (SLAs), Quality of Experience (QoE), language for service reliability and mapping to SDN/NFV KPIs.

“Security for Virtualized Environments” [5] is an effort to standardize security models, terminology, and analytics, essential components of SDN/NFV environments to ensure confidentiality, integrity and availability.

“Performance for Virtualized Environments” [6] is an effort to standardize performance models, terminology, and analytics to enable optimized system operations and service delivery in SDN/NFV infrastructures.

“Reliability for Virtualized Environments” [7] is an effort to standardize reliability models, terminology, and analytics to enable optimized system operations and service delivery in SDN/NFV infrastructures.

2.3 Software-Defined Quantum Communication

The purpose of this project is to define a classical interface to quantum communication devices that permits these devices to be reconfigured to implement a variety of protocols and measurements [8]. This interface will enable configuration of quantum endpoints in a communication network in order to dynamically create, modify, or remove quantum protocols or applications. The protocol design will facilitate future integration with Software-Defined Networking and Open Networking Foundation OpenFlow.

 

3. References

[1] P1903.1 - Standard for Content Delivery Protocols of Next Generation Service Overlay Network (NGSON), https://standards.ieee.org/develop/project/1903.1.html

[2] P1903.2 - Standard for Service Composition Protocols of Next Generation Service Overlay Network (NGSON), https://standards.ieee.org/develop/project/1903.2.html

[3] P1903.3 - Standard for Self-Organizing Management Protocols of Next Generation Service Overlay Network (NGSON), https://standards.ieee.org/develop/project/1903.3.html

[4] 1903-2011 - IEEE Standard for the Functional Architecture of Next Generation Service Overlay Networks, http://standards.ieee.org/findstds/standard/1903-2011.html

[5] P1915.1 - Standard for Software Defined Networking and Network Function Virtualization Security, https://standards.ieee.org/develop/project/1915.1.html

[6] P1916.1 - Standard for Software Defined Networking and Network Function Virtualization Performance, https://standards.ieee.org/develop/project/1916.1.html

[7] P1917.1 - Standard for Software Defined Networking and Network Function Virtualization Reliability, https://standards.ieee.org/develop/project/1917.1.html

[8] P1913.1 - Standard for Software Defined Quantum Communication, https://standards.ieee.org/develop/project/1913.1.html

 


 

Niranth AmoghNiranth Amogh (namogh@huawei.com) is a Principal Researcher at the Huawei India R&D Center at Bangalore. He is responsible for the Wireless Networks Research within the organization. His research areas include Broadband Critical Communications, M2M/IoT, SDN/NFV and NGSON. He has filed several patents in his research areas and holds leadership positions in several SDOs in India and globally. He is an alumnus of BITS, Pilani and NIE, Mysore.

 

Alexander D. GelmanAlexander D. Gelman (gelman.alexander@gmail.com) is Chief Technical Officer of NETovations, LLC, Networking Research Consulting Group and Director of Standards Program Development in IEEE ComSoc. Previously, Alex worked with Panasonic Princeton Laboratory and Bellcore. Alex served on several ComSoc committees, in publications and conferences and co-founded CCNC. Alex founded the ComSoc Standards Board and initiated several IEEE standardization projects. Alex is 2006 winner of IEEE ComSoc´s Donald W. McLellan Meritorious Service Award. He received ME and Ph.D. (EE) from the City University of New York.

Mehmet UlemaMehmet Ulema (mehmet.ulema@manhattan.edu) is a professor at the Computer Information Systems at Manhattan College, New York. Previously, he was with AT&T Bell Laboratories, Bellcore, Daewoo Telecom, and Hazeltine. He also serves as the Director of Standards Development in ComSoc. He was the TPC Chair of GLOBECOM 2009, General Co-chair of NOMS 2016. He is on the editorial board of IEEE Journal of IoT, and Springer Journal of Network and Services Management. He received PhD at Polytechnic University, Brooklyn and BS & MS at Istanbul Technical University.