Software Defined Networking (SDN) is a prevalent marketing term that attempts to embrace a set of core principles. These are typically identified as the separation of the data plane and control plane, a programmatic interaction with the network, network abstraction, and the use of a functional component called a Controller to exert direct control on network resources.

Multiple technologies exist that meet these objectives and conform to the requirements and architecture implicit in the very definition of SDN. These technologies include established standards-based approaches such as the Path Computation Element (PCE) and the Interface to the Routing System (I2RS). There are also new emerging standards like Service Function Chaining (SFC) and Segment Routing (SR). Recent advances in protocol specifications to separate control and forwarding include Open Flow (OF), Protocol Oblivious Forwarding (POF), and P4 (Programming Protocol-independent Packet Processors).

Operators and vendors must choose between forwarding and control plane implementation technologies. Criteria for such decisions may include a preference for one of many implementation design axes: centralised to distributed, micro-flow to aggregated-flow, reactive to proactive, virtual to physical, stateless to stateful, and fully-consistent to eventually-consistent. In many cases a further commercial, operational, and implementation decision is required to determine the deployment of these technologies: open source, closed open source, or property software.
This tutorial outlines many of the SDN architectures and technologies available today and describes how they relate to each other. Where possible we evaluate and compare multiple technology and deployment options, summarising current art, challenges/gaps, opportunities and next steps. It is, however, not our intention to make a decision for you since your requirements will all be different and different options will suit different scenarios.

back to tutorials ^

This tutorial will explain the concepts of self-organizing networks and show how such networks can also be self-configuring. These notions are common in some parts of the network, especially in mobile networks, but can (and should) be applied much more widely. The goal is to decrease operator intervention, increase reliability, improve responsiveness, enhance efficiency, and generally improve end user perception of services.
Some components of self-organizing and self-configuring networks include autodiscovery mechanisms; detection of changes in topology, usage — more generally, network telemetry; adaptive algorithms; and steering policies. The tutorial will offer more details on these and other components, as well as say how they interact. Finally, it will offer up some directions for future research.

back to tutorials ^

By allowing the logical placement of controls at application/service boundaries, rather than at the perimeter, the virtualization of security controls promises to reduce policy complexity and consequent policy misalignment. Policy expressed at an application boundary, need only address that application's protection needs. The resulting focused policy sets can be smaller, easier to understand and easier to change without mistakes. Even a series of controls, applied at application/service boundaries, are intrinsically aligned by having a common focus. Such alignment supports mutually coherent sets of policy expressed across different kinds controls (e.g. FW, IPS, NGFW, ...). The resulting overall policy is both simpler and better aligned.

The placement of controls at application/service boundaries also improves the resulting protection. Controls placed at application/service boundaries provide more granular visibility into east/west traffic. Controls placed at application/service boundaries are better contextualized, because alerts and logs are generated from a well characterized placement in the application topology. Candidate mitigation alternatives can be identified from the resulting topology. With more granular visibility, better context and mitigation alternatives, the resulting protection can be much more effective.

While the virtualization of security controls has clear benefits, the confidence we place in such controls is dependent on the operational integrity and resilience of the underlying virtualization technology. Compute and network virtualization work together to deliver the level of isolation, flexibility and reliability that security functionality demands. In this session, we will demonstrate with concrete examples, how virtualization of security controls can reduce management complexity while improving protection. We will also demonstrate how virtualization technologies support the level of integrity and resilience required to realize these improved virtualized security controls.

back to tutorials ^

The Internet of Everything, the confluence of people, machines, data analytics and processes, will likely prove to be the single greatest technology innovation we have seen this century. It will soon surpass the impact that the internet, mobility and social media have had on society which is truly remarkable and exciting for business. This session will provide attendees with a solid working definition of IoE, explain why various industries are adopting and what types of solutions they are investing in. Moreover, we will drill down into the key technology enablers and foundational capabilities that every organization will need to know ­ whether building IoE based solutions or implementing them. Coming out of the session, the audience will not only have a greater appreciation for IoE, but also be better prepared to become part of the transformation we are seeing every day.

back to tutorials ^

back to program ^

Today CIOs are under immense pressure to deliver IT services for an increasingly dynamic business environment. SDN and network policy have made their way into Enterprise and cloud provider networks driven by the demands of cloud consumption models, solving the challenges of attaching lots of dynamic endpoints through programmable intent rather than configuration. And cloud datacenters are just the beginning, as similar challenges exist in branch offices, extranets and connecting user groups in the campus. SDN solutions hold promise in light of delivering new operational models that are a good match for business realities in today¹s cloud environment.

This talk demystifies the critical elements of the SDN toolkit and the value of SDN to a CIO. We will also explore use cases and implementations of SDN technology in the context of enterprise datacenters and the WAN, all in support of aligning IT to business needs.

back to program ^

SDN discussion often talk about solving Data Center Problems, or WAN problems, or other specific cases. Just as MPLS has to addres crossing domains, SDN has to be able to solve problems which cross silos within an operator. And has to be usable with MPLS, Segment Routing, and a range of VPN technologies. This talk will briefly examine approaches to using SDN in such a mixed environment.

back to program ^

back to program ^

YANG models are increasingly the mechanism of preference for configuring devices and networks. They are used in the south-bound interface from a network controller to the device for specific provisioning in SDN systems, and they are used proposed for a south-bound interface between a controller or orchestrator and a control-plane enabled network in a hybrid SDN architecture.

YANG is also the modelling language used in the Interface to the Routing System (I2RS) for real-time or event driven interaction with the routing system, and is proposed for a north-bound interface from the controller to allow an orchestrator to request end-to-end connectivity or specific network behaviors. 

Two things are missing from this view. The first is a north-bound interface to the orchestrator where a set of network features and behaviour can be requested in support of the services delivered to the customer. The second is an interface that is even further north on the commercial interface between customer and network service provider. This presentation focuses on the second of these: the Service Model Interface.
This presentation will discuss the difference between an abstracted service model and the data models used to configure networks, protocols, and devices in support of the service. This fundamental distinction is key to understanding the separation between how a service is described and contracted from the point of view of a customer and how the network operator chooses to provide the service.

The speaker will use the work of the IETF's Layer Three Service Model (L3SM) working group as a concrete example of how this concept can be achieved through cooperation between network operators, and how the abstraction of a service is very different from the configuration of the underlying technologies that realise the service.
The presentation will address the following topics:

• The value of a service model to end-user customers, enterprises, and service providers.
• How the Service Model Interface fits into emerging architectural views of SDN including the Application-Based Network Architecture (ABNO – RFC 7491) and ETSI's NFV architecture.
• The key distinctions between service models and the technology-specific data models that enable delivery of the services.
• Why it is important that service models are specified by their users and not by equipment vendors.
• The experiences in establishing a L3VPN service model and the prospect of extending and of generalising this to other services especially other MPLs-based services.

back to program ^

The state-of-the-art in network management remains relegated to proprietary device interfaces (e.g., CLIs), imperative, incremental configuration, and inflexible, legacy protocols (e.g., SNMP).  The rising adoption of SDN has shown the benefits of well-defined, programmable APIs to the data and control planes, but these capabilities are lacking in the management plane where there is a significant opportunity for automation and increased operational efficiency.
In this talk, we will share our experience in leveraging the collective expertise of network operators to build standard, open-source, operations-centric models that enable declarative configuration and streaming telemetry.  This new streaming model for monitoring the network overcomes the scaling limitations of legacy mechanisms, and offers new flexibility in how management systems interact with network elements.
We describe the efforts of a number of global-scale network operators to collaborate on the development of common APIs for the management plane based on data models, with a focus on network configuration and monitoring.  The OpenConfig working group is the first industry-wide initiative driving an open, software defined network configuration and management plane that allows programmatic network operation.  By working closely with multiple vendor partners, we are enabling new and existing platforms with native support for the next generation open management interfaces. 

back to program ^

This talk will discuss what DevOps orchestration looks like for carrier, and how it must adapt to telecom and networking realities to act as the companion operational movement to SDN/NFV network architecture.  A case study with real world results will be shared to illustrate how DevOps can transform complex carrier services to make teams more productive and innovative.

back to program ^

Networks today run many different services and applications. These services have different performance and policy requirements from the network than the services of the last decade. For example, one service provider provides short delay paths to select set of high-revenue financial customers and it needs to measure delay across the links in its network and may segregate these customers' paths from the rest of its customers. Another major service might be the over-the-top video, such as NetFlix and YouTube. This service has a video quality requirement, and if not met, may lead to customer churn. The service is very adaptive and can tune its bandwidth requirements to available resources. In this case, the SP may provision for optimum video quality under normal network conditions and may want to tune the video quality down under link and router failures. This enables the service provider not to over provision its network too much for handling failures. These, and many other services, are now carried over the same network. As a result, SDN MANO needs to become service aware by provisioning these services end-to-end, from the access and aggregation networks where necessary VRFs, access-lists are setup, to WAN where paths that satisfies these performance requirements are setup.
In this talk, we will give an overview of some of the new protocol and open-source developments, such as IETF’s NETCONF/YANG, I2RS policy associations, and PCEP, and how they can be orchestrated together to achieve this end-to-end service activation. However, protocol developments alone solve only part of the puzzle. To gain maximum network efficiency, we need extreme topology and performance telemetry from different layers of the network and apply analytics algorithms to find resources in the network to run these services even under heavy load. Hence, we will also illustrate how we overlay different traffic-matrices, one for each service class, on top of each other with their own separate optimization algorithms in order to yield optimum multi-service delivery network.

back to program ^

Many service providers are currently building data centers for provide access to virtualized network functions. The integration of those data centers into an existing carrier network is one of the main challenges which need to be addressed. With NFV there is the need to provide an end to end view and orchestration which not only covers the data center but also spans the service provider network and the data center network. This presentation will cover different options for integrating DC and SP network and addresses the following topics:

- Requirements for End-to-End Network orchestration (e.g. OpenStack integration, separate controllers, options for southbound protocols, security)

- Architectural options of DCI (Data Center Interconnect) and carrier network integration (e.g. MPLS based, "flat IP" model, virtual router, ...)

- Evaluation, pro and cons of architectural options

- Operational impact of End-to-End integration (e.g. if a network function is moved into DC)

back to program ^

The presentation will introduce the unique needs of network telemetry and analytics in large data center fabrics. We start with outlining an intent based declarative approach to modeling greenfield or brownfield fabric topologies given a set of capacity, topological and traffic constraints.  We then describe a pipeline for generating and analyzing network sensor/telemetry data - specifically touching upon 3 analytics applications - performing topology verification, routing consistency, and end host granular reachability analysis. The talk will focus on the operational experiences gained in deploying these systems at scale.

back to program ^

As the demand for cloud services continues to grow at an explosive rate, the next generation cloud has to reach a new level of scale and elasticity. The virtualized overlay network layer has to scale to support millions of Virtual Networks (VNs), connecting hundreds of millions of Virtual Machines (VMs) and Virtualized Network Functions (VNFs). In addition to scale, elasticity is essential for cloud providers to manage capacity effectively in their Data Centers (DCs), improve service velocity, increase availability, and give customers even more dynamic access to compute, storage, and network resources. Scalable and lossless VM and VNF mobility is the key capability that we need to achieve in order to enable this all-new level of elasticity.

Last year, we presented Hierarchical SDN (HSDN), a solution to scale the Data Center and cloud underlay network infrastructure to support tens of millions of physical endpoints at low cost. HSDN is an architectural framework that applies to both control and forwarding planes, and has some unique, highly desirable properties. In particular, HSDN radically simplifies establishing and handling tunnels and can operate with all paths in the network pre-established in the forwarding tables.

In this presentation, we apply the HSDN principles to the overlay network layer to achieve this all-new desired level of elasticity at scale. We present a novel overlay mobility scheme that takes advantage of the unique properties of HSDN to achieve seamless and lossless VM and VNF migration at scale. We then use hierarchical partitioning in the overlay network to scale the updating of the overlay reachability information, as required to support migration, and dramatically improve convergence.

back to program ^

Overlay networks are popular for DC architectures because they provide network infrastructure independence – but they also provide a number of challenges – being out of sync with the underlay means the overlay has no information when the underlay changes – this can result in latency challenges which in turn has an impact on application performance. With hosted applications being the name of the game and increasing packet processing capabilities with general purpose compute, the key question is can overlay networks really provide the full suite of capabilities like an integrated stack would? If not then what is the optimum approach and can SDN provide an answer to this mix.

This presentation compares this existing overlay technologies, highlights their differences and explores solutions and optimizations wrt to overlays and underlays. It also looks at how some Sps are building Scale-up clouds to host mission critical applications and what impact does an overlay have to that model

back to program ^

Security breach rates are increasing, with associated losses approaching $445B. Over 90% (Gartner) of these breaches are associated with misconfiguration, driven by security management complexity. This complexity is rooted in the system, network and control architectures underpinning traditional datacenters and hosting fabrics. Additionally, rapidly morphing threats, shifting business need, evolving regulatory restriction, dynamic workload footprint and emerging technologies, all act to exacerbate this management complexity.  The emergence of SDN, NFV and security control softwarization presents the opportunity transformationally improve cybersecurity.

The ability to “cellularize” networks at application/service granularity enables fine-grained containment, protection and visibility, which together can be used to disrupt the “reconnaissance and lateral movement” phases of advanced attacks. The ability to anchor virtualized security controls on these granular “microsegments” allows the establishment of comprehensive “default deny” security postures, greatly inhibiting the avoidance behaviors, currently used to circumvent protection technologies. From a “big picture” perspective, the ability to leverage an always current topology that reflects the positional relationships between workloads and their respective protections, facilitates unprecedented improvements in policy alignment at provisioning time and in actionable context for both behavioral analytics and incident root cause analysis.

This session will provide an overview of demonstrated and directional opportunities to radically improve cybersecurity through, using SDN, NFV and security control softwarization.

back to program ^

We are moving from a hobbyist form of being connected as humans exemplified by the popularity of personalized wearables designed to monitor your level of fitness to one where the notion of the Internet of Bio-Nanothings [IoBNT] designed to enable applications such as intra-body sensing with implications to molecular communications. The amount of information that is transmitted publicly should evoke questions as to security-safety and privacy.
Do we become our own human API? What must be your rights and responsibilities as the quantified self? This presentation seeks to undertsand societal and ethical implications to the quantified self; and to provoke further research on this topic.

back to program ^

Historically, denial of service (DoS) attacks have been mitigated by a combination of deep packet inspection and traffic policing at the network edges. Distributed denial of service (DDoS) attacks have made this harder because attacking traffic can enter the network from a large number of sources simultaneously. In order to protect against DDoS, policing has to be performed closer to the target (the attacked node in the network) or must rely on sophisticated and coordinated traffic monitoring across the network.

Advances in network function virtualization (NFV) and SDN introduce the possibility to perform advanced DDoS protection mechanisms on standard processing servers in the DC network.  This may significantly reduce the cost of handling DDoS attacks by removing the need for specialized network hardware installed at all exit points from the network, and by allowing new DDoS mitigation functions to be turned up on demand and deployed to the network edges.

This presentation will briefly recap the nature of DDoS attacks and how they are handled today. It will then move on to explain how today's DDoS mitigation can be enhanced by using NFV and SDN technologies. When the DDoS attack is detected, the detection device send the attack information to the network controller which conducts the edge router to collect the attack traffic information and redirect the attack flow to the virtualized security function on the network edge to filter the traffic.

back to program ^

Within the network research community a number of programs have developed research oriented facilities and services that seek to simplify and automate the allocation of geographically distributed server, storage, and switching resources to researchers wishing to test new concepts at scale. The GEANT Project, the pan European R&E network, has likewise been developing a generalized virtualization model that takes common features of these various research efforts, and key unique features of each, and folds these in with several additional innovative features to create the GEANT Testbeds Service "GTS". This generalized virtualization framework, and the the GEANT service based upon the framework, allows clients to acquire multi-species cyber-infrastructure (e.g. virtual machines, virtual circuits, switching/forwarding fabrics, storage, etc.) that can be geolocated across Europe for the primary purpose of promoting network research - broadly construed - at scale and under user control. This talk will provide a brief overview of the virtualization architecture with a look at basic scalability, extensibility, security, performance, and relevant multi-domain deployment efforts that promise a wider and denser reach. Since this generalized virtualization architecture is open, and there remain many technical issues to be addressed, the talk will also present areas that could benefit from additional community involvement and applied research.

back to program ^

This talk will describe why carriers need SDN, their SDN requirements, a carrier SDN-based network architecture, addressing the requirements, and related standardization in the ONF and IETF.It has been over 17 years since the formation of the MPLS Work Group and 18 since many of the fundamental tenets of its architecture were conceived.  Over that period MPLS has evolved in many directions encompassing Traffic Engineering, L2 VPNs, L3 VPNs, EVPN, Pseudowires, BGP scaling, and MPLS-TP
Now Segment Routing with control via SDN is being deployed.  Other applications of SDN to MPLS are also being developed.
This talk will cover the founding principles of MPLS that have allowed MPLS to evolve and morph in so many ways.  It will explore how technology changes in processor speeds and cache sizes, frame size and link speed, and the scalability of IGPs and BGP have enabled ideas that were only dreamed of (if even concieved) in 1996 to  be realized.  In particular it will explore SDN control of MPLS and Segment Routing.

back to program ^

In carrier networks, easy deployment of new network functionalities and automation of network operation are becoming increasingly important to rapidly provision network services for a variety of user demands. Network Function Virtualization (NFV) and software-defined networking (SDN)/OpenFlow are attractive concepts that meet these requirements. We present our NFV-enabled network node architecture leveraging SDN/OpenFlow. We also introduce a virtual BRAS (Broadband Remote Access Server) prototype using Intel DPDK as high performance throughputs.

back to program ^

We have demonstrated a virtualized voice service built on the OpenStack cloud operating system running on IBM SoftLayer public cloud. The IBM Software Defined Platform was used to deploy a Session Border Controller (SBC) and IP Multimedia Subsystem (IMS) core. The deployment has the open characteristics sought for an NFV environment. We will discuss the components used for the open source IMS core and third party SBC. We will discuss the IBM Software Defined Platform and policy framework used in the deployment of the workload. Finally we will discuss the SoftLayer Public Cloud that we used to build the testbed and the network design for the virtual voice service.

We have created the architecture of the testbed based on the characteristics of Network Function Virtulization (NFV). With a MANO layer comprised of the IBM Software Defined Platform and the OpenStack Cloud OS. The Virtualized Network Function (VNF) is the virtualized voice service utilizing IMS. The Network Function Virtualization Infrastructure is using KVM as the hypervisor and running on bare metal Linux hardware. The baremetal Linux machines have been deployed using APIs from the SoftLayer Public Cloud. 
We demonstrated softphone registration, call completion and scaling components of the voice service. We relate the experience of using the SoftLayer Public Cloud as a platform to test and develop NFV services.

back to program ^

Is your NFV infrastructure ready for carrier grade deployment?
Network Functions Virtualization holds the promise of lowered CAPeX and OPeX expenses along with improved agility for the delivery of services. However, guaranteeing the 5 9s reliability of end to end services is critically important for widespread adoption. The ETSI NFV architecture introduces many new architectural components--the VNFs, the NFVI, the VIM, VNF Manager and the NFV Orchestrator. These new components introduce the need for new interactions among these components and also with the legacy components such as the OSS/BSS and the physical devices.

Spirent will propose test methodologies to perfom functional tetsing of the various components and interfaces and also methodologies for performance benchmarking of VNFs and Network Services

back to program ^

Software Defined Networking (SDN) paradigm offers flexibility to the operators and service providers in provisioning and managing their networks. Segment Routing (SR) technology can enable networks to achieve scalable SDN and traffic engineering solutions. In this presentation, we will show usage of SR technology and protocols with SR enhancements such as BGP-LU and BGP-LS in an large scale network. Our architecture, design and standard-compatible approaches aim to offer efficient and scalable SDN solutions for core, intra- and inter-datacenter networks. The presentation will discuss our challenges and observations drawn from a real-deployment. We will highlight our engagement and collaboration with vendors in advancing this technology.

back to program ^

During this session we will present how Segment Routing is used to unify the forwarding plane between Data Centers, WAN and Carrier Ethernet architectures. Use cases and customer motivations will be covered, together with the technical innovations required to deliver on this vision. This session will be delivered together with an operator* to bring the perspective of a Service Provider and an Enterprise consuming the service.
*What is the goal of this session?*
Demonstrate how a Segment Routing based unified forwarding plane architecture address current and emerging use cases that benefit from an integration between Data Centers, WAN and Carrier Ethernet architectures.
*How will the session help the participants or their customers solve a problem or meet a need?*
It will provide use cases that the attendees can relate to, and that are relevant for current and future needs. *The operator to co-author the session has been identified but is not yet ready to be publicly mentioned.

back to program ^

back to program ^

During this talk we will present how we can use Segment Routing to
load-balance a network with specific peering constrains.
The comparison scenario is a production environment with MPLT-TE and load
share optimisation.

What is the goal of this talk:

Demonstrate how Segment Routing can be implemented to substitute an
existing MPLS-TE network, and the benefits.

How will the talk help the participants or their customers solve a
problem or meet a need:

It will provide use cases and test results of a real problem today,
MPLS-TE management.

back to program ^

back to program ^

We are seeing a great deal of interest in EVPN, particularly in the data centers. It allows our largest data center customers to build massive layer-3 data center fabrics, while still providing a layer-2 service to their customers. It also provides multi-tenancy and sophisticated policy control mechanisms. EVPN can be viewed as a traditional distributed control plane protocol where each device is managed individually. In the talk I will make the argument that there is a natural evolution from EVPN to full SDN. With EVPN, it is possible to define very sophisticated policies such service chains between tenants. I will point to the recent IETF drafts that describe in detail how this can be achieved with clever manipulation of the Route Targets (RTs), Route Distinguishers (RDs), and next-hops. However, in reality, it quickly becomes infeasible to do such configuration manually. Here is where the SDN controller comes in. It allows you to define the policies at a high level of abstraction. In the management plane, the SDN controller “compiles the high level policies into low level configuration of RTs, RDs, and next-hops”. In the control plane, the RD acts as a super-intelligent route-reflector, that manipulates the traffic using next-hop and MPLS label manipulation. Also, the SDN controller is tightly integrated with the virtualization orchestrator (e.g. OpenStack) to dynamically create overlay tunnel endpoints (VTEPs) in the hypervisor when needed. Finally, the SDN controller adds a telemetry and analytics dimension. Thus, we see that EVPN can be viewed as an migratory intermediate step between traditional MPLS-VPN protocols towards full SDN.

back to program ^

Rings are special — the simplest topology that offers resilience — and they are nearly ubiquitous. Current approaches to resilience on rings with MPLS are inefficient and complex. This talk offers a different way to achieve resilience in rings with MPLS; it also shows how some of the principles of Self-Organizing Networks can be used to simplify configuration and operation of MPLS in rings. The approach is open and standards-based.
The talk motivates the new paradigm (called Resilient MPLS Rings), and offers technical details on how it works. The main idea is similar to BLSR, but operating at the packet (MPLS) layer. This involves IGP and RSVP-TE extensions. A status update on standardization will also be presented.

back to program ^

This talk will review the emerging requirements for streaming telemetry and outline open questions and interesting issues around this nascent technology. The network infrastructure measures and senses vast amounts of interesting data, but that data has never been simple to collect. New use cases and new tool chains for network monitoring can consume far more data than we can extract using conventional methods like screen-scraping and SNMP. Streaming telemetry is a relatively new paradigm for getting large amounts of data off the network as quickly as possible.

back to program ^

The increased interest in providing programmable interfaces for network operations has led to a growing number of data models being developed to describe many elements of the network.  These data models, most often written in the YANG data modeling language, are intended to define an API for the network to replace operations traditionally done manually or scripted through CLIs.  Given the importance of MPLS and traffic engineering in many large networks, it is clear that having YANG data models for MPLS is crucial for enabling automation and programmability in key parts of the network.

In this talk, we share our experiences in developing a programmable interface for managing MPLS and traffic engineering in global-scale multi-vendor networks, with support for both configuration and operational state monitoring.  We discuss the challenges in designing a complex data model that is vendor neutral and operations-centric, while also being realizable across major platforms.  We describe our efforts to represent existing LSP configurations using these models as we transition our management software away from platform-specific tooling to vendor-neutral open interfaces.  Finally, based on our ongoing engagements with major vendors, we highlight some of the key areas of implementation differences between vendors, and how these differences can be managed in the models.

back to program ^

Carriers are seriously considering what they should design and construct for future networks and how they should operate them. They expect that Software-defined networking (SDN) will play a key role in operating future networks because it allows them to implement their own management policy by separating the control-plane from the network elements. 
Even though SDN attracts wide attention from carriers, few SDN-controlled networks have been materialized due to lack of detailed discussion on requirements for SDN-controlled network architecture. In this talk, firstly we address functional requirements for SDN-controlled network architecture. Traffic Measurement, Flow classification, Path computation, Route enforcement, QoE management, Network status update are among functional requirements. We develop detailed discussion on those functional requirements. We also discuss performance requirements for those functional requirements.
Then we present a novel macro-flow-based traffic engineering method. In this method, Flow-mining, Model Predictive Control (MPC), Path computation, Content deployment, Virtual network resource allocation are key components. We employ a machine-learning-based Flow-mining algorithm to traffic measurement for Flow classification. Model predictive control (MPC), which has been time-proven in plant control, is applied to optimize Path computation, Content deployment, Virtual network resource allocation. We developed a SDN controller, which implemented those functions. We demonstrate feasibility of our proposed architecture by running the SDN controller for proof-of-concept (PoC) network, which consist of Open vSwitch and emulates the Internet2's topology data and flow data [1].
[1] Y. Takahashi, K. Ishibashi, N. Kamiyama, K. Shiomoto, T. Otoshi, Y. Ohsita, and M. Murata, "Macroflow-based traffic engineering in SDN-controlled network," iPOP 2015, T3-1, Okinawa, Japan, April, 2015

back to program ^

Software defined network separates control functions from underlying network and is enabling enterprises to build manageable data center to support big data processing. Big Data frameworks has emerged as an important platform for data intensive distributed computing, real-time analysis and enables actionable intelligence for Software Defined Networks.
A typical data center will support traffic patterns that can be categorized as persistence large data packets (elephant-flows) and short lived small packets (mice-flows). Typically most of the flows in the network are mice-flows but most of the data belongs to few elephant-flows. Elephant-flows fills network buffers causing large latency for mice-flows.

In this paper we consider, Hadoop applications run on compute framework (MapReduce) which exploits the distributed storage architecture of Hadoop's distributed file system (HDFS) to deliver scalable, reliable parallel processing services for arbitrary algorithms.
In a Hadoop cluster the pain points that impacts the overall performance

·Congestion traffic due to elephant-flow from Hadoop’ application and also from other applications sharing the same network
·Inadequate bandwidth between reducers and mappers due to shuffle phase (the process by which the system performs the sort - and transfers the map outputs to the reducers as inputs - is known as the shuffle) of Hadoop's MapReduce computation which involves movement of intermediate data
Our study and demo explores implementation of an SDN Application (SDN-App) that leverages OpenDaylight (Northbound APIs), 3rd party application (sFlow) and southbound protocol (OpenFlow) - to enable dynamic traffic flow optimization in a typical data center running Hadoop applications in the network.

Target audience
Take away from this presentation:
·Framework to create applications (SDN-Apps) that can be deployed with
SDN/MPLS 2015 - Call for Papers

OpenDaylight
·Approach to effectively create SDN Applications leveraging OpenDaylight (northbound APIs)
·Implementing programmable interfaces to 3rd party applications/suites

back to program ^

This abstract describes the vision for an agile photonic communication infrastructure capable of supporting a range of Information and Communications Technology services offered by Tier1 operators, alternative Service providers, and research and education networking users. The envisioned solution provides virtualized connectivity resource management architecture, enabling the independent administration of each of the users allocated resources; and a fully agile and dynamic photonic network layer.    
Photonic Nation is our vision for interconnecting nations and cities to support competitive ICT services enabling outsourcing of cloud computing, cloud storage and hosted software applications to cloud SPs. Photonic Nation’s applicability has a wide scope in a variety of different deployment scenario’s:

• High-speed inter Data Centre connectivity and interconnection service providers for, large enterprises and peering partners;
• On-demand and scheduled high bandwidth capacity and connectivity for massive bandwidth exchanges;
• Wholesale leased facilities to Service Providers, mobile Service Providers, content Service Providers;
• Private networks for education, for healthcare, for financial networks.

To achieve the goal of a widespread nation-wide, virtualized communication resource, the deployed solution must meet several requirements, including:

• User Independence – allowing independent turn-up and management of services and network facilities.
• Flexibility/Agility – allowing expandable and reconfigurable in order to serve varying user needs over both long-term (e.g., months) and short-term (e.g., minutes) timescales.
• Geographic Scale – to be accessible by all users and partners within the network independently.
• Scalable Bandwidth – to be able to scale in bandwidth served in order to meet the projected demands over at least the next decade.

The presentation will analyse and discuss the fundamental building blocks of the architecture, and illustrate the benefits of the architecture, these include:

• WAVE Fabric or Agile Photonic Networking - A flexible and evolvable underlying transport solution based on a photonic Wavefabric using Dense Wavelength Division Multiplexing (DWDM), augmented with photonic OAM infrastructure, in support photonic wave ping and wave trace tools.
• Digital network layer – Converged Packet-Optical Transport – enables the optimized solution based on a balance between cost, scalability, specific service needs and requirements. The usage of flex-grid enabled transponders allows the usage of supper channels, and reconfigurable encoding schemes.
• MAN/WAN SDN Controller (WSC) – enables users to operate and manage their infrastructure and complex relationships, and simplifies complex network relationships down to an intuitive topology layout that covers virtual, physical, and logical resources and relationships.
• Northbound and controller interfaces – These interfaces integrate higher-level automation solutions on top of the policy and controller framework, including workflow automation tools and analytics.

Southbound Controller protocol – The OpenFlow protocol is typically used in SDN architecture, and vendors have released OpenFlow-compliant switches.
Advanced network research increasingly requires testbeds, deployed at scale, to fully realize and evaluate novel network concepts. Constructing such large scale testbeds - and providing the security, privacy, access to key network switching and forwarding nodes, and control by the user (research team) - pose technical, administrative, and budgetary hurdles that degrade, delay, or completely block advances in network technology, best practices, and/or distributed applications. GEANT, the pan-European research network, is investing in advanced automated service technologies that can create and manage such distributed experimental environments easily and efficiently. The GEANT Testbeds Service (GTS) is a production GEANT capability that provides the user with virtualized network resources such as computational/end system platforms, virtual circuits, and both experimental (OpenFLow) and conventional switching/forwarding elements in a user defined and user controlled distributed environment spanning the European footprint. GTS targets the software defined networking and global network virtualization research communities as they explore these emerging topics, and is working collaboratively with other similar initiatives toward a common global approach to such services. This talk will provide an overview of the GTS service architecture, its current development and deployment status, and the roadmap for the next several years.

back to program ^

We have been developing an optical packet and circuit integrated network (OPCInet) as a high-speed metro/core network [1]-[3], which can provide diverse services on the same network infrastructure. Path controllers placed for OPCI nodes construct a logical control-plane (C-plane) network in a domain. In [2][3], we developed distributed control protocols for the C-plane, which include signaling and routing for OCS, and dynamic resource allocation (DRA). The OPCInet dynamically moves the boundary to separate OPS and OCS wavelength resources in each link depending on the situation of path usage. Such distributed control protocols achieve higher scalability and tolerance to failures than centralized one. Meanwhile, software defined networking (SDN) is received much attention in both research fields of intra-cloud (data-center) networks and inter-cloud optical transport technologies. Even though exiting SDN technologies adopt centralized control mechanisms, the OPCInet will have to deal with SDN extension [1]: The SDN extension will enable network service providers (NSPs) to efficiently and programmably transfer a large amount of data-center (or access network) traffic on the OPCInet. This will be done via an SDN north-bound interface. On the other hand, for the SDN south-bound interface, control functions such as signaling and DRA need to be executed using SDN by requests from NSP’s equipment (NSPE). One of solutions is to install a mediation SDN controller (called Broker) between the OPCInet C-plane and NSPE. It is possible that the NSPs desire to centrally control all OPCI nodes from one geographical location without placing a path controller for every OPCI node in a domain and with maintaining the distributed C-plane functions. We can easily modify this physically centralized, logically distributed system into a physically virtualized system against overload of controller and recovery from a failure. In this work, we develop all-in-one control equipment for the OPCInet. We implement 6 path controllers and 1 Broker inside only one physical laptop by means of VMware Player (ver. 6.0.1). The controllers are mapped to separate virtual machines (VMs) (Guest OS: Ubuntu 12.04LTS). Figure 1 illustrates the structure of controllers’ network. The 6 path controllers are connected by 7 Generic Routing Encapsulation (GRE) tunnels. The Broker communicates with every path controller via a virtual hub. We connect one terminal regarded as NSPE to the Broker. The NSPE can request the Broker to establish or release a wavelength path on the specified route; then, the Broker executes path signaling in accordance with the request by Telnet. When a path is established or released, the information such as date/time, link, number of in-use wavelength paths and OPS/OCS resources is notified from the C-plane to the NSPE via the Broker by use of socket-based communications. Figure 2 shows the notified information displayed on the NSPE when a path was established between Node-1 and Node-6 via Nodes-2, 3, 5 in downstream (Node-1 to 6) and via Nodes-5, 4, 2 in upstream. The last 8-bits of each IP address correspond to the Node number. By use of socket-based communications, the NSPE can also request the Broker to forcibly execute DRA in a link; then, the Broker executes the DRA by Telnet. Figure 3 shows a result of forcible DRA, in which the ratio of OPS/OCS resources in the link between Nodes-1 and 2 was changed from 30:10 to 20:20.

Figure 1: Structure of controllers’ network implemented in our all-in-one laptop.
Category: C
Figure 2: Notified information displayed on the NSPE in the case that a path was established.
Figure 3: A result of forcible DRA (displayed on the Broker).
This work is partly done under NICT/NSF Japan-US Network Opportunity (JUNO) program.
References:
[1] H. Harai, et al., IEEE/OSA Journal of Lightwave Technol., Vol.32, No.16, pp.2751-2759, Aug. 2014.
[2] H. Furukawa, et al., Optics Express, Vol.22, Iss.1, pp.47-54, Jan. 2014.
[3] T. Miyazawa, et al., IEEE/OSA Journal of Optical Communications and Networking, Vol.4, No.1, pp.25-37, Jan. 2012.

back to program ^

back to program ^

Recently, user demands for network services have been diversified. Especially users expect QoS which enables users to continue using high priority communication services even when the network cannot continue to accommodate all services due to a disaster, and scheduled service which enables users to communicate by paying only for the time and bandwidth they use. Operators’ revenue will increase by providing these attractive services. In order to put these services into practice, operators’ networks need to realize both high reliability to continue services when faults occur, and global optimization to accommodate various traffic for each user and time by efficiently utilizing limited network resources, such as network nodes and links.
Previously two techniques, protection switching and rerouting, have been used to change each route. Protection switching realizes high speed switching to protection route registered by the operator in advance, within 50msec when a fault occurs. However, protection switching has issues on inefficiency of network resource usage due to resource allocation of protection routes, and on service disruption when faults occur both on working and protection routes due to a disaster. On the other hand, rerouting is a technique to change a route by re-computing the most appropriate route. However, rerouting has issues on difficulty in utilizing network-wide resource usage efficiently since rerouting is performed for each route, and on difficulty in high speed route change since re-computing is performed after a trigger happens, which may result in service disruptions.

We propose packet transport network system where centralized control is performed by SDN orchestrator and it dynamically assigns network resource to globally optimize the resource usage efficiency (Fig. 1). The proposed network system is characterized by its SDN orchestrator which manages multiple logical planes. A logical plane is defined as a group of logical routes and their assigned bandwidth, which operators register in advance. In order to apply the most appropriate logical plane to the network, SDN orchestrator has NW analysis function and logical plane control function. NW analysis function monitors and analyzes network status and selects the most appropriate logical plane. Based on the information of time, node failure and loss of services (1), NW analysis function selects the most appropriate logical plane in terms of bandwidth assurance, connectivity of user service, resource usage, and power consumption (2). On receiving a trigger (3) from NW analysis function, logical plane control function (4) send logical plane switch requests to network nodes (5).

When a disaster happens in the network and the loss of services number exceeds pre-configured threshold, SDN orchestrator selects and switches logical plane in a short time, so that high priority services’ communication routes bypass node failure point. In this way, the influence of disaster on high priority services is minimized. As a result, operators can continue providing high priority services by effectively utilizing limited resources. On the other hand, when a operator provides scheduled service, SDN orchestrator applies logical plane to the network so that unused devices (for example, interface cards) can be shutdown for power saving.

As a next-generation access and aggregation integrated network, the Elastic Lambda Aggregation Network (EλAN) has been proposed [1]. A programmable optical line terminal (P-OLT) provides logical OLTs (L-OLTs). Each L-OLT is dynamically programmable. Therefore, the L-OLT can act as a virtual OLT (V-OLT). In the EλAN, live migration of V-OLTs among P-OLTs is applied to reduce energy consumption and to enhance network reliability [2]. In the laboratory level, we have successfully demonstrated sequential V-OLT migrations in MPLS/SDN 2013 and SDN/MPLS 2014. In this presentation, we will report V-OLT migration trials over largenetwork environment for evaluating service down time estimation method and also report multiple parallel V-OLT migration trials.

We constructed an EλAN testbed network using JGN-X [3]. Figure 1 shows a geographical location arrangement of the testbed network. 3 locations, Koganei (NICT), Yokohama (Keio Univ.), and Naha (iPOP2015 conference venue), are connected by VLANs. P-OLTs are assigned to all locations and V-OLTs are migrated among P-OLTs which are set in same or different locations. The distances between P-OLTs are examined in 3 patterns. In the first pattern, both P-OLTs are located in Koganei. The distance between P-OLTs is 0 km (less than 20 m). In the second pattern, one P-OLT is located in Koganei and another P-OLT is located in Yokohama. The distance between POLTs is 22.9 km. In the third pattern, one P-OLT is located in Koganei and another P-OLT is located in Naha. The distance between P-OLTs is 1543.3 km. In the EλAN testbed network, to move some devices to remote (Yokohama and Naha) sites, two device domains are constructed. Figure 2 shows devices in Naha site. One P-OLT, four ONUs, one L1-switch are set. All devices are controlled by the network management system (NMS) with the SDN/OpenFlow protocol.

V-OLT migration time is divided into 2 parts. One is a distance dependent part such as SDN message
transmission time form an SDN controller to each device. Another is a distance independent part such as device configuration time. Therefore, V-OLT migration time is estimated using equation (1).
t =α × X + tinit (1) In eq. (1), t [s] is L-OLT migration time, α [s/km] is proportionality constant, X is L-OLT migration distanc[km], and tinit is a distance independent device configuration time. From the experiment results, we can determine α.

Other detailed results will be shown in the presentation.
Fig. 1. Geographic location arrangement Fig. 2. EλAN devices in the Naha site
[1] S. Okamoto, “Elastic optical metro/access combined aggregation network technologies for realizing a future service adaptive
network paradigm,” Proc. in IEICE Tec. Report, CS2012-96, Jan. 2013. (Written in Japanese)
[2] T. Yamaguchi, et al., “Experimental Report of Elastic Lambda Aggregation Network (EλAN) Control Method for SDN-based
Carrier Class Network,” Proc. in COIN2014, TP-24, Aug. 2014.
[3] New generation network testbed JGN eXtreme: JGN-X, http://www.jgn.nict.go.jp/english/index.html

back to program ^

In the distributed path computational model, the computation is carried out at the head-end network element. This is done based solely on the head-end network element’s view of the network-state. In the centralized path computational model, the computation is carried out by an external Path Computational Element (PCE) that maintains a global view of network state. Each of these traditional computational models has well-documented benefits and drawbacks of its own. This presentation will introduce a new computational paradigm that leverages the benefits of both the traditional computational models and will discuss in detail the motivation behind using this paradigm. This new hybrid computational paradigm involves having the centralized computation element compute the path in terms of a sequence of abstract hops and then letting the head-end network element take care of computationally expanding the abstract hops in the path.
In order to facilitate abstract-hop constrained routing, abstract views of the TE Topology must be created and computation needs to be done off of the resulting abstract topology. In the mechanism detailed in this presentation, a set of abstract regions are defined where each abstract region represents a group of routers that satisfy a logical combination of certain link/node attributes, say admin group, SRLG, etc. The centralized computation is done off of the abstract view and hence the path generated by the centralized computation engine results in a sequence of abstract hops. These abstract paths are then handed over to the head-end node which takes care of translating these into actual paths using its view of the current network-state. This presentation will discuss in detail the various tools that are needed to facilitate this notion of hybrid computation.

back to program ^

PCEP provides an evolutionary approach to provide centralized SDN
functionality. The objective is to re-use as much of the topology creation,
failure detection functionality that exists in the current service provider
networks such that SDN capabilities can be achieved and core SP network
requirements such as provisioning TE service paths, SLA maintenance, fast
fail-over convergence, fault-OAM capabilities can be satisfied at the same
time.  The focus here is to discuss use cases and methodologies applicable
to PCEP and how it fits in the other SP-SDN protocols such as BGP-LS and
segment routing to provide an end-to-end solution to address the SDN needs
of carrier and service provider networks. It is also intended to demonstrate
using a demo, the progress made by open source communities such as
OpenDaylight (ODL) in the SP-SDN protocol areas and interoperability between
proprietary and open source solutions for PCEP.

back to program ^

This talk describes new paradigms and tools available for the operation of network devices. Network management traditionally required high levels of human intervention that lead to long-cycles to make any changes to a network. The requirement for a more responsive network infrastructure has led to new approaches to configuration management, network monitoring and software management. These new capabilities enable a higher level of network automation that leverage some of the lessons learned from the operation of large compute resources.

back to program ^

Software-define networking (SDN) allows service providers to realize the network programmability, the OPEX/CAPEX reduction, and the short lead-time service delivery. It can be applied to our backbone transport networks. Network elements for SDN are becoming available in the market and open source controllers to manage transport networks have been developed. They increase the feasibility of realizing Transport SDN.
The characteristics of transport network are multi-layer, multi-domain and multi-vendor. First of all, multi-layer means that our transport networks use multiple technical layers, such as WDM, OTN, MPLS and so on.

Secondly, it has an access network domain to connect subscribers to service providers, an aggregation network domain to route subscriber’s traffic and a core network domain to provide highly aggregated connections. We administrate them in different manners. Finally, multiple vendors’ products are introduced for with respect to each layer and each network domain. Its operations are currently segmented and specifically optimized.
The problem of our transport networks is how we achieve the agile and low-overhead operations required by the subscribers and cloud applications. In the existing situations, we spend long time and cost to introduce vender-specific network operating systems and service-specific OSS/BSS and educate operators in order to introduce new network equipment and provide new services. In addition, the specific optimization causes inefficient operations in total.

Our approach to solve the problem is to develop the SDN controller which can control transport networks in a lump. Two points are required to consider. First point is to abstract multi-layer, multi-domain, and multi-vender networks. Second point is the scalability and high-availability, which is enough to entrust the controller to manage our backbone networks. We will present the use cases and PoC of transport SDN.

back to program ^

Following the concepts of Software Defined Networks (SDN), a number of key architectures have been proposed for a SDN controller to control a network and manage the resources of the network. Most of the architectures typically rely on a centralized approach but in some cases a hybrid approach may also worthwhile.
However, the existing SDN architectures proposed have some weaknesses. For the SDNs using open flow based technologies, every forwarding node in the network must be open flow capable. In addition, there must be a connection or session between the central SDN controller and each forwarding node in the network. For segment routing (SR) based SDN, it is required that every forwarding node in the network support the maximum depth of label stack that a SR data packet may have. Some extra labels in a data packet constitute a big overhead. Moreover, the SDN controller must have a connection or session to every edge forwarding node of the network.
In brief an “intelligent” SDN must be capable of addressing the weaknesses in open flow and SR based SDNs. It should be forwarding technology agnostic and be capable of integrating with a range of existing forwarding mechanisms, as well as future forwarding technologies. The intelligent SDN controller should utilize the strengths of both central and distributed control mechanisms.
This article will present an intelligent SDN, in which the SDN controller can just connect to one or a few of any forwarding nodes in the network. It is not required that the SDN controller connect to every forwarding node in the network or every edge node of the network. We will also illustrate an intelligent SDN controller architecture and provide a companion between our intelligent SDN approach and other SDN approaches including those for open flow and SR networks. Finally, we will outline the current industry trends and standards-based mechanisms that may be combined to provide the intelligent SDN and the gaps that must be filled by standards organizations.

back to program ^

SDN architecture based on separation of control and data plane in network element enables network programmability and application aware networking. In today’s SDN solutions, controllers are able to provide open APIs through service abstraction. For instance, an application is able to invoke connectivity services across multiple domains through a single controller with different service plugins. Application, such as Virtual Tenant Network (VTN) Coordinator, can build virtual network based on underlying physical network. It gets underlying connectivity, or invokes network resources in other words, by deploying a series of flow table entries to physical network through controller. This differs greatly from traditional network management concepts, in which network provision is performed on a dedicated management system either manually, or through the Operation Supporting System (OSS), and is transparent to applications. On the other hand, resource management in today’s SDN implementations is still largely designed for the conventional network management purpose, and the controller is, for the most part, not aware of how applications are using network resources. Given the fact that a large number of applications may be using the network, and each has different service level agreements, in terms of packet loss rate, or availability, it would be of crucial importance to know how each application is using the network. For example, a network failure may disrupt thousands of applications passing the failure point. To realize fast and differentiated failure recovery, we must know precisely the correspondence between the network resources and the affected applications. Another example is the need to temporally reduce/increase the amount of bandwidth allocated for a certain service, e.g., content distribution service. In a network with hundreds, or thousands of network nodes, each containing thousands of flow table entries, traversing the managed topology database for affected flows can be very time and resource consuming, leading to poor scalability. In this work, we are interested in identifying the gap between the current SDN design concept, and true application aware networking resource management. We argue that the current SDN controller implementations are not designed to be fully application aware. We further show that a module that maps the applications to the network resources can help mitigate the problem, and should be designed as a fundamental component in the SDN controller. We use OpenDaylight as a concrete example, and show the performance of typical application aware network operations, e.g., differentiated failure recovery, and application bandwidth adjustment, with and without such a module. Our results shows that in a network configured with 1000 nodes, each with 100 flow table entries, the time to update the flow table entries along a 100 links path is 0.27 seconds and 20.8 seconds, with and without the proposed module, respectively.

back to program ^

Currently Software defined networks is capable of Layer2-4 based policy implementation but is agnostic to higher layers. Application recognition and flow characterization is critical for providing a better Quality of Experience (QoE) to the end user. A simple example could be a Network operator extending better QoE to priority customer for applications being used.
Leveraging SDN controllers (OpenDaylight) to dynamically configure networks depending on the application that is using the network in run-time is critical to enable monetization.
We evaluate and show-case a Deep Packet Inspection (DPI) based approach coupled with monitoring to provide L7 visibility to differentiate important mice flows and reengineer the traffic flow patterns as per defined policies.
An overview of the SDN Application architecture as follows.

SDN/MPLS 2015 - Call for Papers

Page 2 of 2
In our approach, we implement a SDN Application (SDN-App) that leverages OpenDaylight SDN Controller to enable differentiated services for mice flows. The presentation will aim at a SDN eco-system inter-working of SDN-App with OpenDaylight (SDN Controller) and other 3rd party tools, leveraging OpenDaylight northbound APIs and steps to integrate equivalent SDN Apps for actionable intelligence.
At the high level, the SDN-App that will aim at enabling an OpenDaylight eco-system
· Interworking with 3rd party suite (sFlow) for flow characterization and nDPI to prioritize important mice flows
· Compute traffic re-engineering rules for SDN using path computation engine
· Leverage OpenDaylight Northbound APIs - to enable traffic re-engineering
· Dynamically set flows to provide better QoE leveraging OpenFlow based Queue/meter mechanism

The roadmap ahead, aims at using OpenDaylight’ Service function forwarder (SFF) and commercial DPI as a service function (SF).

Target audience
An audience looking for insight on effectively creating SDN-Apps that can leverage SDN Controller (such as OpenDaylight) as well as inter-work to 3rd party applications would be interested in this presentation.
Take away from this presentation (for Developers, Enterprise and Telco customers) would be
· A framework to create SDN-Apps that can be deployed with OpenDaylight
· Approach to leverage OpenDaylight northbound APIs
· Implementing a programmable interfaces to 3rd party applications
· An approach to enable actionable intelligence to enable application awareness and differentiated policies for mice flows.

back to program ^

Hierarchical and automatic number allocation (HANA) [1][2] is an
automatic network address allocation tool for each router, switch, server and
user terminal (Fig. 1). This is used when setting up a network initially or
changing it for upgrading. The automatic property makes operator-burden
relax because only top of the router or the switch is allocated network address
and others are only allocated prefix lengths. Address configuration burden is
reduced downto 1/100 for a 1,000-server network. We have developed
HANA-capable layer 3 switches for enterprise networks.

In this report, we succeeded applying HANA to OpenFlow-capable SDN
network. Openflow is a tool for (re)configuring flows by using 12 or more
tuples (e.g., source/destination IP, MAC addresses) after a network is built. We
add one-more benefit to the SDN network: automatic addressing to switches
and servers.

Let us assume that a network design. At first, we usually design a set of hostname, IP address, device, accommodated
position in rack, upstream/downstream switches and connected ports, and so on. After completing the maintenance
table (e.g., a form of spreadsheet), we start real configuration of each equipment. We change our mind in SDN: at first
names are given, and then others are allocated automatically. The maintenance tables can be generated automatically
by slight modification of HANA environment (Fig. 2). We develop this environment by using Ryu and Lagopus, both
of which are open source software for an OpenFlow controller and switch, respectively.
We believe that this method is not only fit to OpenFlow but general SDN that has a management network.

[1] Yang Song, Lixin Gao, Kenji Fujikawa, “Resilient Routing under Hierarchical Automatic Addressing,” IEEE Globecom 2011.
[2] K. Fujikawa, H. Tazaki, H. Harai, “Inter-AS Locator Allocation of Hierarchical Automatic Number Allocation in a 10,000-AS Network,” SAINT 2012.
Fig. 1. HANA Overview.

Fig. 2. HANA automatically allocates network addresses and makes maintenance sheet.

back to program ^