Software Defined Networking is the latest Industry buzzword that has captured the imagination of the computer networking industry. It certainly is an emerging architecture to solve a host of problems around high performance control plane, finer grained control on the data plane and is yet another incarnation of the control and data plane separation paradigm (Think SS7, IP Switching etc).

However, this time around due to standardization of protocols between control and data plane, such as openflow, and standardized set of API to the data plane many more things are achievable that were not possible before in previous attempts to separate the control and data plane for IP networks. This new model has the potential to disrupt and change how the networks of the future are built and operated as it allows easy abstraction of network based functionality to a set of virtual services. SDN also allows programmable control of networks in a virtual model (without the need to have physical access

) This technology tutorial discusses briefly the background and motivation of SDN and then dives into technical details of available models and protocols such as Openflow. The summary of topics discussed in this technology tutorial are

1. Openflow and SDN

2. Openstack and SDN for cloud (Integration of Openflow and Openstack)

3. Open and not so open APIs

4. Standards view - I2RS, ONF

5. Opendaylight Project

6. Applying SDN: use cases

7. SDN and security

back to tutorials ^

Interface to the Routing System (i2rs) is a new IETF working group that is intended to make it easy for network applications and SDN controllers to interact with and control network elements in a real-time event-driven fashion. This tutorial will describe the architecture of i2rs and its proposed functionality; and how i2rs fits into the over-all SDN space. The key aspects of i2rs are a data-model driven paradigm and the talk will delve into the benefits of programming the network based on a data-model. Another key feature of I2RS is making network topology standardized and easily available; the architecture for this and progress on the associated information models will be provided. Finally, some example use-cases for I2RS, in the areas of RIB programming, topology awareness and policy enforcement, will be given.

back to tutorials ^

This tutorial will review the motivation behind NFV and look at ongoing standards activity as it develops. In addition, it will examine which markets are moving first to NFV architectures, and what these shifts mean to existing and future network architectures.

back to tutorials ^

OpenDaylight represents a community that has come together to fulfill the need in the industry of creating an open, reference framework for programmability and control through an open source SDN solution. Such a framework maintains the flexibility and choice to allow organizations to deploy SDN as they please, yet still mitigates many of the risks of adopting early stage technologies and integrating with existing infrastructure investments. Through the combination of open community developers and open source code and project governance that guarantees an open, community decision making process on business and technical issues.

This presentation will describe The Open Daylight organization, its mission, as well as technical details around the open source Software-Defined Networking (SDN) controller project it represents.

back to tutorials ^

This talk reviews service provider business, technical and operational motivations related to Network Programmability and Virtualization as background. It then describes challenges that service providers and the industry face, as well as technology and standards drivers that should help achieve the goals and overcome challenges. The talk concludes with a summary of possible outcomes for the fate of  Network Programmability and Virtualization.

back to program ^

NTT Communications (NTT Com) has already deployed packet transport networks by using router-based MPLS based aggregation network which is using Decoupled Control/Data architecture with reinforced OAM and fail-over functionality. Through its operation, we confirmed that high availability and effectiveness of decoupled Control/Data architecture contributed to the network operation efficiency. NTT Com applied MPLS based technologies to the cutting-edge video transport network system on a nationwide scale which requires high reliability, high stability and high usability to facilitate circuit operations. NTT Com is planning to introduce PTN in order to integrate the backbone for each service. Additionally, for network simplicity through layer integration, NTT Com introduces OXC on Optical layer, and SDN for operation integration to facilitate inter DC connectivity.

back to program ^

In this talk we outline how network based VPNs can be seamlessly extended into the data center. The resulting service overlay network becomes the foundation for a number of virtualized network services that can be deployed quickly, elastically scaled according to customer demands and that make optimal use of available compute and network resources. We also explore how we can expand orchestration concepts from the data center into the WAN and how we can use new label based forwarding techniques to optimally steer traffic thru the network.

back to program ^

TBA

back to program ^

Since MPLS was first defined the networking scene has changed substantially. At that point it was not entirely clear that the Internet would be the dominant network layer protocol. MPLS were designed to be an efficient toolbox to increase avaiability, performance and xxx of IP networks. To leverage this applications such as PW's, VPNs (L2 and L3) and MPLS-TE were developed. MPLS has also been used for networks where IP forwaring is not necessarily a design assumption, e.g. GMPLS and MPLS-TP. Now we see a new set of application emerge - cloud, sdn, new types of network virtulization, etc. - this will put new and interesting requirements on MPLS. The presentation will start by looking at what was the strength of MPLS and also discuss what the new requirments are and how the can be met.

back to program ^

There are currently “macro trends” inducing uncertainty and volatility in today’s networks. These trends include the evolution of intelligence, horizontally integrated networks, and the prevalence of virtualization. This presentation will discuss why there is this uncertainty in the network space, how Software Defined Networking (and the rise of software in general) is accelerating this effect, and what network operators might do to take advantage of it.

back to program ^

The presentation will give a detailed view about the potential and challenges of SDN in combination with network virtualization from a services provides standpoint. “Real world” use cases based on the existing requirements and network architecture will be provided, including scenarios for virtualization of network functionalities (e.g. Firewalling, warding mechanisms to avoid DDoS attacks, ePC). The end-to-end orchestration of services and the decoupling of network and application life cycles are the main enablers for highly flexible services and solutions based on the use cases will be presented.

The presentation will cover/answer the following questions:

• Challenges, Benefits and Use Cases:  What are the benefits of SDN and an end-to-end orchestration of services? Use cases which benefit from the integration of SDN into existing BNG based network architecture of Deutsche Telekom. In which context SDN makes sense and where are on the other hand the challenges? Comparing of pro and cons of different approaches. Analyses of network functions which potentially can be virtualized taking scalability, complexity and performance requirements into account.            

• SDN Architecture for Service Providers: Architecture blue print for the integration of SDN based approaches into BNG architecture of Deutsche Telekom. Comparison of different SDN solutions (e.g. OpenFlow, I2RS, …) and suitability based on use cases and network architecture.

• Hybrid Architectures, Integration and Migration: What are the mechanisms to integrate SDN and NFV into an existing network architecture? Which approaches are necessary for a smooth and hitless migration? How does a hybrid architecture look like and what are the challenges to address in order to run SDN in parallel to other architecture approaches?

back to program ^

Much as there may be a desire to make connections between virtualized data centers and WANs as "seamless" as possible, there is no getting around the fact that they are significantly different environments. Not only is the WAN an environment of relatively high latencies and constrained bandwidth, but the set of services that are expected in the two environments differ significantly. One need only look at the services on offer at Amazon EC2 and the self-provisioning model of cloud services to see how much these services differ from WAN services like L3 VPNs. In this talk we'll discuss how these two disparate worlds can be integrated to leverage service provider assets and deliver the services expected by cloud customers.

back to program ^

Motivation for virtualization of network functions is presented as background. A set of representative use cases from which common requirements are derived are then described. An architecture that places these virtualized network functions in the context of existing physical network deployments (such as IP, MPLS and Ethernet) is then summarized. Finally, challenges and technical problems requiring solution are summarized.

back to program ^

The virtualization of data center networks to meet the requirements of multi-tenancy has to-date relied on a a vaiety of standard and non-standard solutions. This has resulted in a profusion of different approaches. There are a number of initiatives to standardize the architecture and mechanisms used for data center virtual networks in order to bring some of the benefits of interoperability and reuse of technologies. This presentation will provide a status update of standardization in data center virtual networks, focussing on the work of the IETF.

back to program ^

Software Defined Networks bring networking from the world of fixed, standards-based protocols towards a more programming-centric, API-driven world.  Along with the promise of greater agility, SDNs brings more complexities, particularly as multiple API/SDKs compete for mind and marketshare and historical precedents from the computing and mobile worlds indicate that it’s quite possible that there will be at least two if not more defacto standards.  Given these complexities and uncertainties, it is important to consider the role of heterogeneous, self-service automation frameworks.  This talk will discuss the concept of self-service automation for heterogeneous networks including SDNs, and how they can help to reduce risks in:

• Enabling end-to-end self-service for dev, test, security, compliance, and deployers a reality in heterogeneous environments
• Evolving end-to-end infrastructure including datacenter/cloud/SDN
• Making legacy plus new network elements available to support effective, agile SDN application development
• Ensure disaster recovery routines keep pace with changes in the environment
• SDN testing and test lab automation

The talk will also address key characteristics of self-service automation help overcome the typical obstacles to successful automation, and enable automation to be sustainable, scalable, and able to overcome interface and expertise silos.

back to program ^

Data Fabrics used to be simple -- it was assumed that Ethernet is a fine medium, offering cheap, ubiquitous connectivity. Over time, a closer look at the plain Ethernet fabric in view of data centers' more stringent requirements shows tatters and patches and areas frayed and threadbare. The de facto 3-tier architecture with its odd rules and unnatural layer restrictions looks like a Pierrot suit.

What are the requirements of a modern-day, scale-out data center? How do these contrast with the requirements of Wide Area fabrics? What are the limitations of existing fabrics that force us to look anew at the problem? What are the choices before us, and do any of them offer an acceptable solution? Are technologies like VXLAN, NVGRE, MPLS-over-GRE, TRILL and the like the answer? This talk will look at the issues, look at some alternatives, and propose a solution that not just meets the requirements, but goes far beyond.

back to program ^

Cloud service delivery to large enterprise customers must address a variety of business, technical, and operational considerations, encompassing -- easy and convenient ordering and billing processes; cost effectiveness relative to alternative modes of service delivery; virtualization within the network and cloud domains; end-to-end security of data in transit and data at rest; dynamic composition, orchestration, and provisioning of cloud and network services; and integrated service assurance. This presentation describes a practical end-to-end framework for delivering cloud services to enterprises.

back to program ^

Network Virtualization Overlays offer the allure of agile data center and cloud service deployments over standard IP network infrastructure. This talk will discuss how E-VPN provides foundational building blocks to implement network virtualization overlays over multiple transport technologies. We will also discuss interworking between E-VPN overlays and standard MPLS IP-VPNs for the purpose of enabling customer access to cloud services. The talk will also cover how E-VPN enables elastic and scalable data center services with inter-data center connectivity to cloud for both inter and intra-subnet extensions.

back to program ^

Two trends are driving renewed interest in IP/Optical integration. First, as Optical networks evolve, they are becoming more dynamic and agile. Second, the vision of Software Defined Networking has opened up new possibilities for how IP and Optical Networks can be integrated. This talk will explore the elements of the puzzle and various models for how pieces can fit together for improved optimization and automation of Multi Layered networks. First we will review some of the enabling technologies such as IP / DWDM Control Plane integration (GMPLS), PCE Centralized Computation and Network Planning and Optimization (NoS) tools. Building on these enabling technologies, we present models that will enable IP/MPLS networks to exploit the agility of the Optical networks, enabling the IP/MPLS network to dynamically add, remove or proactively reroute optical capacity. We will highlight the value as well as the operational models and technology.

back to program ^

The latest shiny things in networking are Software Defined Networks (SDN) and Network Function Virtualization (NFV).  They promise new ways of operating and managing networks, and innovative methods for deploying services, reducing operational costs, and increasing the value from deployed equipment.  One of the benefits of this approach is network automation and the ability to dynamically deliver network resources for virtualized services and connectivity in support of demands from applications.

The networking industry already has many functional components and protocols such as the Path Computation Element (PCE), Application-Layer Traffic Optimization (ALTO), Interface to the Routing System (I2RS), and OpenFlow, that provide numerous features and functions required to facilitate network automation and connectivity for virtualized services and application demands.  But without an overall architecture it is impossible to see how these and other components can be combined.

Application-Based Network Operations (ABNO) [1] is a term that covers the application-centric operation of networks to provide automation for on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (including point-to- point connectivity, network and function virtualization, mobile backhaul, and mobile gateway interconnectivity) across a range of network technologies from packet (IP/MPLS) down to Ethernet and optical transport.

ABNO brings together existing technologies for gathering information from the network, for consideration and abstraction of network topologies, application of path computation and traffic engineering, and for provisioning or reserving network resources.  Thus, ABNO may be seen as the use of a toolbox of existing components enhanced with a few new elements.

This presentation describes the architecture and framework for ABNO, showing how these components fit together.  It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications, and identifies the missing components that need to be developed to make a more sophisticated and coherent operating environment.  Lastly, the presentation highlights operator-derived use cases for application-driven network operation to show how the components of the ABNO architecture interact to deliver services acrossl the network.

[1] King, D. and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", draft-farrkingel-pce-abno-architecture, work in progress.

back to program ^

I2RS is a new working group at the IETF focusing on standardizing technologies in the SDN arena around two key areas: fast programmability and network topology. In the case of the former, we set out to allow for the quick and efficient configuration of network elements (real or virtual) in order to facilitate agility and flexibility in how a network element can be programmed to react to certain network conditions. In the case of the second area, we sought to provide generalized, normalized and multi-layered topology in a standards-based format that not only network savvy elements could consume, but also not-so savvy network applications could as well. It is the combination of both of these key concepts that can lead to allowing an operator to achieve what we refer to as "Instant CSPF". This presentation will describe how this solution can be achieved.

back to program ^

This talk introduces our recent research on pursuing deep programmability within the network. Deep programmability refers to not only the control plane programmability, but also the data plane programmability for processing traffic data and parsing new protocols such as non-Internet protocols, as well as the programmability for defining APIs for control plane and data plane operations in SDN.

Putting forth the idea of deep programmability, we also introduce a new network node architecture that enables deeply programmable network, called FLARE. The FLARE architecture introduces multiple isolated programming environments where we can flexibly and deeply program innovative in-network services such as new switching logics, packet caching, transcoding and DPI, and run them all concurrently at the line speed or switching among them on demand. We show demos and evaluations with the prototype of FLARE network nodes and discuss the benefits from them for the future Internet. We also introduce our LivingLab with FLARE nodes, where we use FLARE to enable deeply programmable networking in our daily life.

back to program ^

An active stateful PCE provides the ability to compute paths with global visibility and to control the timing of setup of such paths, making it an important building block for applications that require central traffic engineering. In this context, stateful PCE bridges the gap between the controller and the dynamic control plane, and allows for an evolutionary approach to deploying such applications, as it only requires software upgrades on the edges on the network to enable the client functionality. The benefit of deploying centralized TE is both in reduction of CAPEX and OPEX and in enabling new applications, such as WAN traffic controllers, bandwidth on demand or smart LSP sizing.

These exciting applications come at the cost of introducing a single point of control, with all it implies in terms of redundancy and resiliency schemes, load sharing, configuration/discovery, capabilities support and protection. In addition to these universal challenges, a PCE deployment must also address specific issues related to the injection of ephemeral state in the network, its integration with routing, and the ability to update state without traffic loss.

This talk will look at some of the challenges in deploying solutions integrating stateful PCE, at best practices and at how some of the built-in protocol mechanisms should be used in order to ensure correct behavior both for failure cases and for planned maintenance. We will look at existing solutions and their characteristics, and at areas where work is still needed.

back to program ^

Today there are various needs for transport networks. Some of them require dynamic path creation, optimization and deletion in transport networks for customers within a very short time window. For example, in cloud computing, transport paths are needed to provide dynamically, and they are expected to align with virtual machine operations such as launch, migration and deletion. In addition, it would be needed to allocate efficient network resources because service providers have to reduce cost. To minimize unused network resources, multiplexing various users’ data traffic is a typical solution. To satisfy these requirements, SDN in MPLS transport networks should realize rapid LSP operation and multiplexing various data traffic without any service level degradation.

Stateful PCE, which is a powerful southbound interface to control RSVP-TE parameters, is attracting attention as an SDN application for MPLS networks. Using stateful PCE, network operators are able to use the controller that is programmed to flexibly conduct LSP operation such as LSP creation, optimization and deletion within a short time window. However, when service provider multiplexes various data traffic on several LSPs, data traffic congestion may happen because of momentary shortage of physical resources. Currently, data traffic amount cannot be directly controlled by stateful PCE, and bursty best-effort traffic sometimes interferes with service level of guaranteed traffic.

In the existing scheme, there are two issues which cause the degradation of service level. First issue is that there is no capability to manipulate data traffic amount dynamically. Physical network resources allocated to convey data traffic amount should be properly adjusted in fairly short time scale so that they are aligned with RSVP-TE parameters (e.g. signaled bandwidth) entered timely by stateful PCE. Second issue is that there is no capability to associate forwarding direction of incoming data traffic with target LSP(s) which carry it. In existing networks, forwarding entry on an edge router gives the direction of data traffic. If best-effort and guaranteed traffic are coming together and best-effort one increases suddenly, data traffic forwarding must be adjusted so that a certain amount of best-effort traffic which exceeds allocated physical resources is separately transported over different LSP(s). However, modifying configuration manually is a complex process and is not suitable for realizing dynamic services.

We propose solutions to manipulate data traffic amount and to associate forwarding direction of incoming data with carrying LSP(s) in a timely manner, called dynamic data plane management. We present several SDN use cases and explain our proposed dynamic data plane management using stateful PCE.

back to program ^

back to program ^

This session describes optimal path computation and instantiation in software defined networks using stateful path computation elements (PCE). Stateful PCE can be used to compute optimal paths for MPLS Label Switched Paths (LSPs) based on application request in a Software Defined Network (SDN). In addition, it can be used to instantiate and maintain those LSPs on Label Switching Routers (LSRs). We describe how PCE programs traffic steering and load-sharing policies when TE LSPs are created or updated. IETF-standard based Path Computation Element Protocol (PCEP) provides an evolutionary/standard-compliant migration path for Service Providers (SPs) to gradually integrate SDN operational model into their networks.

back to program ^

back to program ^

Segment Routing addresses the pain points reported by MPLS operators (simplicity of operation, scalability, functionality) and enables a much tighter and responsive interaction between the network and the applications. 

Numerous operators and vendors quickly recognized the merits of this technology and endorsed it. A detailed multi-vendor IETF draft is available since March 2013. Much more details will be released for Berlin IETF, August 2013. 

Segment Routing was presented for the first time at the MPLS World Congress (http://www.slideshare.net/getyourbuildon/tagged/cisco_segment_routing). 

For MPLS/SDN 2013 INTERNATIONAL CONFERENCE, we would propose novel content not yet presented at any conference. The content would be focused on the SDN/TE and FRR use-cases and include: objective, technology, IETF, multi-vendor support, use-case.

back to program ^

There are a couple of practical use cases where the consumer of a MPLS label binding may not be adjacent to the router that performs the binding.

Bringing up an explicit session using the existing label distribution protocols between the non-adjacent router that binds the label and the router that acts as a consumer of this binding is the existing remedy for this dilemma.

Moving distribution of Label information into the IGP and taking advantage of the flooding distribution simplifies consumption of label bindings for non-adjacent consumers.

This talk highlights historical approaches to link-state routing using the notion of short, fixed size 'labels' and compares them to the recent MPLS incarnations, particularly "Segment routing" and "IGP Label Advertisement".

Example use cases being covered are in the areas of

- Protection / Bypass routing

- Scalable construction of explicit routed paths

- Traffic engineering

- Automated construction of an all pairs SPT routing mesh

- Automated construction of an all pairs diverse path (MRT) routing mesh

For each use case applicability for distributed-computation and centralized-computation (aka SDN) will be analyzed.

back to program ^

North-bound SDN APIs allow creation of network-aware applications. Cloud and data center applications have successfully taken advantage of these APIs to provide seamless virtual machine mobility and elasticity. However, these applications are unaware of whether or not the underlying wide area network can provide acceptable performance. To date, a killer SDN application for wide area networks has not surfaced.

Technology vendors have toyed with bandwidth on demand, demand placement and rapid provisioning as SDN applications for carriers. These applications, plus the ability to provide performance guarantees for cloud applications, require deep understanding of underlying real-time network topology and traffic demands. Route analytics is the state-of-the-art-technology needed to provide this information.

This presentation will show how route analytics integrate with SDN applications to provide the policy layer intelligence required to either approve applications to proceed or determine that new network paths must be created. Furthermore, it will illustrate how route analytics technology works, whether the network has tight reservations (such as Google's inter-data center network) or not, which is typical for most networks where it is impossible to know all the traffic demands a priori.

back to program ^

back to program ^

back to program ^

The adoption of IP within the 3G Radio Access Network (RAN) to facilitate the enormous increase in mobile data and reduce the operational costs of operating such networks has been highly effective. According to Infonetics Research [1], the ratio of Mobile Broadband (MBB) subscribers to total mobile subscribers is expected to grow from 15% in 2011 to nearly 40% in 2016.

However it is well-known that further evolution and development is needed, to deliver the myriad of technical requirements to support MBB across 4G and LTE networks. These technical requirements for MBB include: greater virtualization, effective management of large AS internal topologies, reduce internal AS convergence times, supporting large numbers of VPNs with point-to-multipoint and multipoint-to-multipoint service connectivity, and carrier grade reliability. In addition, the ability to deploy and manage services using a centralized traffic engineering control system within the 4G and LTE IP RAN for MBB services would be highly advantageous. Most of these requirements are addressed in the technologies to be presented.

The technologies highlighted within this presentation include the Topology-Transparent Zone (TTZ) [2] which may be deployed for network virtualization, resolving internal AS scalability and convergence, Multi-topology MPLS [3] procedures and protocol extensions to support separation of traffic across low latency (for mobile voice) and high capacity (for mobile data) links, and the use of the SDN Application-based Network Operations (ABNO) [4] architecture to provide underlying transport (Ethernet and optical) path protection. ABNO provides the mechanisms to request and setup transport protection services, using well-defined standards based path computation, provisioning and reservation protocols and procedures. 

This presentation will demonstrate how the combination of existing and new standards-based interoperable technologies will provide an architecture and key features to dramatically change the way IP RANs will be designed, deployed and operated for 4G and LTE environments.
This presentation belongs to the following categories:

• SDN
• IP/MPLS
• Mobile / 4G & LTE
• Network Virtualization
• Centralized Traffic Engineering

References                                                                                       
[1] Infonetics Research, “Mobile broadband demand will push mobile services to $976 billion by 2016; SMS, voice persevere”, July 2012. 
[2] OSPF Topology-Transparent Zone (http://tools.ietf.org/html/draft-chen-ospf-ttz), February 2013.
[3] Extensions for Multi Topology Routing (http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology), January, 2013.
[4] A PCE-based Architecture for Application-based Network Operations (ABNO) (http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture), February 2013.

back to program ^

The Mobile Networks are facing rapidly changing requirements in respect to subscriber mobility, radio coverage and microwave transmission. SDN and Unified MPLS open new opportunities for Self Organizing these Networks. The talk will explain how through SDN and with a Unified MPLS transport the mobile architecture can be Self Organized. We will present SON solutions for the Microwave ACM and the Unified MPLS Transport integration and for the LTE Radio and the Unified MPLS Topology and Capacity correlation. We will demonstrate that the SDN value for SON is in the programmable logic and that its placement is use case dependent and complementary to the network logic.

back to program ^

Connecting islands of IP/MPLS client domains across an administratively independent Packet Transport Core represents an overlay connectivity model. Dynamically establishing overlay connections among client nodes in such a model poses a number of signaling, routing and operational requirements on the client and server networks. The base requirement is for the clients to setup an end-to-end bidirectional overlay connection while satisfying constraints on bandwidth, affinity, diversity and delay and to be able to modify the attributes of such connection on demand without service impact. The clients should have the flexibility to compute and traffic-engineer end-to-end paths across the server packet core and should be able to dynamically control the utilization of their resources within the core based on the demands in the client domains. In some cases, a client may need to form an IP/MPLS IGP adjacency over the overlay connection with its neighbor. In other cases, such a connection can simply be used as a forwarding adjacency. While some operational environments may allow a client to learn relevant information about the transport core topology, others may not. Thus, the onus is on the carriers to adopt an Overlay Architecture that accommodates a varied set of service requirements.

GMPLS based Overlay Architectures have been around for more than a decade and have been discussed in detail in this forum as well as many others; but for various reasons there have been few adopters overs the years. Now, with the advent of concepts like topology abstraction, topology extraction, PCE-initiated LSPs and network-policy, the GMPLS Overlay repertoire has expanded significantly, and is well positioned to cater to the current Carrier requirements. This presentation will review a reference overlay network and its associated network requirements. It will discuss how the adoption of this new GMPLS Overlay Network architecture significantly reduces the complexities associated with overlay deployments.

The presentation will take a close look at an implementation that uses this new architecture to bring up a mesh of L2 VLAN connections among Client Edge (CE) nodes across a packet transport server network domain. Architectural details discussed in this presentation cover the full spectrum of the solution set – Signaling, Traffic-Engineering, Path-Computation and OAM.

back to program ^

Recently many people pay attention to Software Defined Network (SDN). SDN will enable us to program networks according to end user’s needs as though we wrote an application program. Moreover, it is expected that the program will take effect quickly.

Existing packet transport networks are statically configured networks by network management system (NMS). On the other hand, service networks, which consist of routers, are dynamically configured networks. Therefore an adaptation function is essential between packet transport networks and service networks for SDN.

In this presentation, we will discuss the efficiency of multi-layer cut-through and how to utilize it. Packet transport networks consist of packet transport layer and optical transport layer. It is important in terms of end-to-end delay to cut off packet processing at every node along with LSPs by using optical paths, because multi-layer cut-through has possibilities to offer some value for end users who are sensitive to end-to-end delay.

Basically optical paths have larger bandwidth than that of LSPs and contain many LSPs. Therefore cut-through optical path can be easily set up in the area of much traffic in terms of network efficiency, but cannot be set up in the area of low traffic. This shows that multi-layer cut-through cannot be efficient at all cases. We will show some case studies.

Next, we will propose a concept of Software Defined Transport Networks (SDTN) with packet transport networks from a viewpoint of multi-layer cut-through. We think that the requirements of Telecom carriers to SDTN are the same as to SDN. The requirements to SDN are multi-services over single network, quick configuration of new services, and easy migration from existing network.

Network virtualization could meet above requirements in SDN. But a question arises that network virtualization could also meet above requirements in SDTN. Namely, the question is what we could virtualize in packet transport networks. We think that all transport nodes should not be virtualized because transport networks should be stable and robust. Therefore an adaptation between virtualized networks and transport networks is essential. Thus transport edge nodes are introduced.

Multi-layer cut-through is important function and good example of the adaptation. We will show the details of the adaptation and propose layered model for carrier SDTN. The adaptation is realized at network service layer, that is, at transport edge nodes. Network virtualization in SDTN is realized by transport edge manager and transport edge nodes, and is not realized by transport nodes.

back to program ^

The optical transport space is rapidly evolving – not only has transmission technology advanced to 100Gb and beyond, but there is an increasing trend towards the adoption of converged transport systems that integrate digital switching technologies, such as OTN and packet switching, along with WDM optics. This in turn is increasing the flexibility and dynamic capabilities of the transport layer, and enabling it to better adapt to the dynamic needs of cloud networks.  As carriers upgrade their core networks to take advantage of 100Gb optics, they are also beginning to rethink their network architectures to best leverage transport network economics. 
The flexible and dynamic nature of intelligent transport has also brought about the emergence of Transport SDN as an enabler of open, programmable transport networks and facilitator of multi-layer, multi-vendor network integration.   A key principle in Transport SDN is the logical centralization of control where a more global view of the entire network resides, enabling a number of benefits, including:

• Enablement of network abstractions  to higher level applications, which do not need to know specifics of network implementation
• More rapid innovation resulting from programmable networking capabilities
• Open standardized interfaces and protocols to a multi-vendor environment that is accessible by a broader ecosystem
• Automation of processes associated with network provisioning across multi-layer, multi-vendor networks

However, many architectural challenges underlie the notion of multi-layer, multi-vendor Transport SDN.  This presentation will explore the role and definition of Transport SDN, how it compares/contrasts with SDN for the packet world, and will delve into various issues and tradeoffs for consideration pertaining to

• Adoption and assimilation of Transport SDN
• Network virtualization and abstraction models for Transport networks
• Interworking relationship of GMPLS control plane functions with Transport SDN
• Service virtualization versus network virtualization
• The roles of OpenFlow in Transport SDN

The latest operational experiences and learnings from multi-vendor, multi-layer integration leveraging SDN technologies and techniques will be presented.

back to program ^

This presentation introduces a solution to emulate a traditional transport network (e.g., SONET/SDH) using IP/MPLS. We discuss traditional transport network requirements (e.g. guaranteed bandwidth, bi-directional co-routed path, end-to-end path protection, rich OAM functions, etc) and describe how they are realized in IP/MPLS networks. A combination of enhanced MPLS-TE functionality, in-band OAM functionality (standardized by IETF for MPLS-TP) and guaranteed bandwidth for pseudowires services can address transport requirements while retaining a converged IP/MPLS network

back to program ^

In the presentation, we will introduce the RISE OpenFlow testbed and our R&D activities for its enhancement.

1 RISE OpenFlow testbed RISE (Research Infrastructure for large Scale network Experiments) (Fig. 1) is a wide-area OpenFlow testbed on JGN-X, developed and operated by NICT.We initially started to deploy a wide-area OpenFlow network environment on top of JGN-X, and currently we are providing testbed service to researchers and developers utilizing the environment. Hybrid OpenFlow envoronment on L2 networks RISE is an OpenFlow environment built on the L2 networks provided by JGN-X. The major reason for this deployment approach is that preparing a dedicated network infrastructure for RISE costs considerably high and thus is not practical. On the other hand, this incurrs some limitations in RISE, and the technical issues we studied through the RISE deployment are discussed in our earlier literature [1, 2]. Providng OpenFlow testbed service We are currently providing an OpenFlow testbed service (the name “RISE” was determined when the testbed service was started). RISE users can bring their OpenFlow controllers to RISE and conduct their experiments. More precisely, RISE provides OpenFlow switches, communication links among the switches, and end-hosts connected to the switches and a RISE user deploys network applications into the end-hosts and controls the communications by her own OpenFlow controller. In general, a large-scale testbed facility should be shared among the users from a viewpoint of cost, and thus we need to realize a multi-user OpenFlow environment. In RISE, we did not adopt the famous FlowVisor system [3] for slicing the OpenFlow networks. FlowVisor requires pre-allocation of flow-space, which consists of L1 to L4 information for controlling packet forwarding, to each user without overlapping. This is unacceptable to some testbed users because they may need some major modifications in their experiment scenarios depending on other users’ flow-space utilization. Therefore, we adopt the VSI (Virtual Switch Instance) mechanism implemented in NEC’s OpenFlow switches to realize a multiuser environment. With VSI, we can configure multiple logical OpenFlow switches in a physical switch, and those logical switches can refer to different controllers. Thus the RISE users can share the physical switches.

2 Technical challenges in RISE OpenFlow testbed federation We are developing a federation mechanism for RISE and other large-scale OpenFlow network infrastructures worldwide. The NDDI (Network Development and Deployment 1 Initiative) project1in the US is deploying a wide-area Open- Flow networks called OS3E (Open Science, Scholarship and Services Exchange) and developing a service framework called OESS (Open Exchange Software Suite)2to provide advanced L2 service (AL2S) to the users. We are integrating our OpenFlow controller based on Trema3with OESS to interconnect RISE and OS3E [4]. Virtualization of OpenFlow Although VSI is a strong mechanism to realize a multi-user OpenFlow environment, its scalability is limited. We can configure only 16 logical switches in a physical switch. Because the number of RISE users are rapidly growing, we will have to deploy many physical switches to support those users in the near future. To solve this issue, we have been developing a more advanced virtualization framework for OpenFlow [5, 6]. In this framework, we employ an architecture similar to FlowVisor. However, our framework introduces translation mechanisms in both the control plane and the data plane. Actually, FlowVisor just splits the flow-space, not logicalize it. On the other hand, our framework completely logicalize the flow-space, and therefore we call this flow-space virtualization. Introducing the concept of this flow-space virtualization in RISE and realizing a more advanced multi-user OpenFlow testbed environment is our future work.

References [1] Yoshihiko Kanaumi, Shuichi Saito, and Eiji Kawai. Deployment of a Programmable Network for a Nation-wide R&D Network. In Proc. of ManFI 2010, April 2010. [2] Yoshihiko Kanaumi, Shu ichi Saito, Eiji Kawai, Shuji Ishii, Kazumasa Kobayashi, and Shinji Shimojo. Deployment and Operation of Wide-area Hybrid OpenFlow Network. In Proc. of ManFI 2012, April 2012. [3] Rob Sherwood, Glen Gibb, Kok-Kiong Yap, Guido Appenzeller, Martin Casado, Nick McKeown, and Guru Parulkar. FlowVisor: A Network Virtualization Layer, October 2009. [4] Shuji Ishii, Eiji Kawai, Tomoaki Takata, Yoshihiko Kanaumi, Shu ichi Saito, Kazumasa Kobayashi, and Shinji Shimojo. Extending the RISE Controller for the Interconnection of RISE and OS3E/NDDI. In Proc. of ICON 2012, December 2012. [5] Hiroaki Yamanaka, Eiji Kawai, and Shuji Ishii. Realizing Virtual OpenFlow Networks by Flow Space Virtualization (in Japanese). In Technical Report of IEICE (NS2012-41), June 2012. [6] Hiroaki Yamanaka, Eiji Kawai, Shuji Ishii, and Shinji Shimojo. A Consideration of Flow Translation Enabling Arbitrary Flow Definition in Flow Space Virtualization (in Japanese). In Technical Report of IEICE (IN2012-127), December 2012. 1http://www.internet2.edu/network/ose/ 2http://code.google.com/p/nddi/wiki/README 3https://github.com/trema/trema/

back to program ^

The ability to manage the network or computing resources effectively may play a more important role than we often thought. When we talk about multi-layer management, or simply IP VPN provisioning (watch out the control plane resource), or service chaining in physical or virtual world, or end-to-end WAN/DC and Packet/Optical Multi-Layer Multi-Domain (MLMD) orchestration and alarm correlation, we are talking about resource management. The representation of the resources and their status, the global view and optimal handling the resource pool are the keys. We propose a SDN empowered resource management approach, in combination with device level capabilities, to address some long-standing or new resource management issues in individual layers, and particularly for Multi-Layer Multi-Domain alarm correlation.

back to program ^

DC Network Virtualization brings obvious benefits for cloud applications that run on virtualized servers. The presentation talks about DC network virtualization overlay use cases and requirements. It discusses MPLS VPN applicability to DC Network Virtualization and challenges and how SDN and NFV can help enable that.

back to program ^

The goal of this proposal is to enable Service plane virtualization enabled by moving the Policy and subscriber centric elements into the cloud. Virtualization of services & control plane will play a key role in accelerating new service models that allow operators to better serve key customer segments such as MVNO, enterprise and M2M.

Due to inherent distributed topology, the cloud facilitates faster and smooth deployments of the policies at the enforcement points. It seamlessly provides a method to break the traditional linkage of software and hardware in the area related to policies.  End to End QOS and policy deployment is coordinated and orchestrated for the underlying enforcement points. The policy enforcement points, which could be right from the core of the network to the access network, vary in the nature of configuration, deployments and QOS applications. But the business level and user level polices would be the same from the end user perspective. The translation and mapping of the policies are carried out in the common cloud and percolated towards the enforcement points.

By moving policy control and service plane to the cloud, the benefits of virtualization and distribution would be directly imbibed by the operators. This would eventually lead to improved operations, easier manageability profits and higher revenues.

back to program ^

1. Introduction

Software Defined Network (SDN) is a hot topic in network technology. Inter-operability between these SDNs is very important for the end-to-end service point of view. We successfully demonstrated a single OpenFlow domain laid on multiple testbed inter-connected with dynamic path provisioning.

1. Network Technologies

We use two SDN technologies and one measurement framework. An SDN technology is NSI, which is an inter domain protocol to provision end-to-end connection. NSI is a Web services interface standardized at OGF in order to improve usability and agility of network infrastructure as same as computing infrastructure for grid / cloud applications. NSI enables applications to control networks without any manual operations.
Another SDN technology is OpenFlow, which provides flexibility and customizability to data transport.  In our demonstration, the video streaming flow was routed from the Internet to provisioned circuit path by OpenFlow. 
PerfSONAR is a platform for network performance monitoring, which gets packet loss of the Internet. PerfSONAR provides the ability to measure the network performance and to exchange the measured data with well-defined protocols and data format among multiple network domains.

1. Service scenario

Demonstration network consisted of 3 physical domains (KDDIlab network, JGNX and StarLight). These networks have dynamic path provisioning system, which supports inter-domain control with NSI (Network Services Interface).
Service scenario was as follows,
a) User starts video streaming via the Internet.
b) Packet loss rate of the internet traffic is getting higher.
c) When packet loss rate is higher than a predetermined rate, the provisioning system starts to provision a circuit VLAN path among the domains with NSI, then the video streaming flow is routed to the provisioned path.
c’) user can switch the flow manually via WBUI.

1. Summary

We demonstrated an integration of NSI, OpenFlow and PerfSONAR technologies to realize multi-domain SDN. We believe that the integration is an essential key for SDN interworking.

back to program ^

Software-defined networking (SDN) promises acceleration in the pace of network innovations, easier programmability of networks and extensibility in network switching through an open software interface. Most Cloud providers are planning to upgrade their existing networks with SDN capabilities. These include deploying OpenFlow based switches and overlay mechanisms based on protocols such as EVPN or VxLAN. Telecom Service providers are also hoping to upgrade their networks with off-the-shelf hardware switches capable of OpenFlow and MPLS forwarding and moving their control plane intelligence to centralized controllers controlled by application level software. These new breed of OpenFlow switches and controllers and the overlay mechanisms need to be thoroughly tested, individually and as a system for performance (throughput, jitter, loss), availability, security and scalability. In addition the controllers need to be tested to validate policies, control plane protocols and functions such as VM Mobility. This presentation will focus on testing SDN architecture in both service provider and data center environments to ensure success of commercial deployment. Areas that will be covered include: troubleshooting connectivity with flow analysis, benchmarking flow scalability and forwarding performance of high-speed Ethernet OpenFlow/SDN, decoding discovery frames, traffic generation, validating data paths, security performance in a multi-tenant environment within and across multiple data centers, and measuring failover convergence times.

back to program ^

The capacity planning and optimization task is often segmented on the basis of network architecture and technology, e.g., backbone vs. access, and lP vs. optical. Multiple data sources, e.g., SNMP, NetFlow, DPI, IPDR, and service offerings, e.g., HSD, fiber, residential, commercial, Wi-Fi, video, further section the methodology and process.

In a typical service provider environment, there is often a clear demarcation between IP layer, i.e., layer 3, and optical layer, i.e., layer 1, in terms of organizations and functions for network engineering and capacity planning. Different groups with various methodologies and tools plan and optimize each layer individually. There is opportunity in collaboration between the two efforts, but it is often limited. In the end, while each layer can indeed and often be optimized (subject to skill and tool limitations), the combination of two layers as a whole is far from optimal.

Router bypass, also known as router off-load, when architected properly, can be an effective way to reduce the cost of layer 3 network. It allows transit traffic to stay in layer 1 without touching the intermediate layer 3 nodes. In addition to the increase in Capex efficiency, router bypass also reduces IP traffic impairments such as latency, jitter, and packet loss.

The design of router bypass has been a challenging task requiring visibility and analysis of both the layer 3 and the layer 1 networks. For a typical backbone network, there can be millions of possible layer 3 topologies with various levels of router bypass implementation, resiliency, and traffic impairment characteristics.

This presentation illustrates an approach to expand auto discovery and modeling of a network modeling tool from IP layer to the optical layer. The result is a multi-layer network model. Given a set of traffic demands, an optical topology, cost function, and impairment constraints, the modeling tool generates millions of candidate IP topologies, performs exhaustive failure simulation, and score each candidate with the cost function. The end result is a least cost, among the numerous candidates, multi-layer design supporting the traffic demand, failure criteria and service quality requirements. Within this framework, this presentation focuses on the implication of router bypass in the aspects of cost, resiliency, and service quality.

The methodology, tools and process to successfully perform multi-layer network modeling, planning, and optimization are presented. Analytics results from a real backbone network are provided to illustrate the benefit of this holistic approach. Guidelines are proposed to assist manual router bypass design for operators with limited multi-layer modeling capability. Common challenges are discussed, and mitigation strategies are proposed.

back to program ^

back to program ^

Data Center has evolved over the past few decades, from a simple storage resource in a closet to distributed client/server computing in a warehouse building. Current Service Provider Data Center network is easily comprised of heterogeneous layer2/3 devices to accommodate application. Yet, Service Providers are facing many challenges such as growing data under infrastructure complex and tight resource constrains and maintaining system performance and scalability.

This paper explores above mentioned design challenge, showcases 3 common network architectures that could be used for the Service Provider Data Center Network, and some applications

Based on our experience obtained from implementation, the following topics are highlighted:

Visualization

1. -          L2 Network provides overlapped VLAN ID and MAC address space via virtual plane
2. -          L3 network uses IP tunnel and MPLS L2VPN/L3VPN to provide address space separation
3. -          Server creates virtual domain on top of underlying network

Support VM Mobility

1. -          L2 Network VLAN stretch within or cross data center to support VM move
2. -          L3 Network uses IP/MPLS tunnel combined with exit to L3 route to support VM move
3. -          SDN emerges in VM sprawl environment

Integrate WAN service

1. -          Data Center Extend MPLS Layer 2/Layer 3 VPN service to data center
2. -          L2 Network using Aggregator provides a very clean demark between WAN service and DC daily operation
3. -          L3 Network using L3 ToR/MoR provides the function and scalability of the network

Mapping Network service to Auxiliary Function

1. -          L2 Network the architectures make centralized auxiliary functions layer easily to deploy
2. -          L3 Network the architectures drives distributed auxiliary functions

Automation Security and QoS

1. -          Automation is desirable to increase productivities
2. -          QoS is requested to address congestion

This paper provides a comprehensive study to the Service Provider Data Center Architectures requirements and design solution. The data center network architecture selection will have a big impact on network virtualization, VM mobility, WAN service integration, mapping to auxiliary functions, auto-provisioning, security and QoS.

back to program ^

EVRY is the second largest IT service provider in Northern Europe with 10,000 employees serving the largest banks, financial institutes and other industries in the region. Having grown through a large number of mergers and acquisitions, the architecture and portfolio is highly diverse with many operational silos that are driven by customization to meet the individual customer needs. The technology standard of today’s network is also legacy based with long value chains traversing over too many Data Center sites.

This presentation addresses how EVRY is leveraging a major Data Center consolidation as well as multiple contract renegotiations to consolidate all production on a new Data Center platform.  We will cover the follow areas:

• Requirements and lessons-learned in EVRY’s existing Data Center networks
• Pains from existing Data Center networks
• Regulatory and security requirements regarding bank and finance applications
• Requirement of availability and segregation in a multi-tenant environments
• Requirements for private cloud and continuous operation service delivery models
• Target enterprise and Data Center architecture:
• Principles, standards and roadmap that steer all service development and implementation.
• Architecture considerations of virtualization versus physical segregation
• What role could paradigms like SDN play in the target architecture at EVRY?
• Migration strategy:
• How to facilitate, from a network perspective, the migration of tens of thousands of servers and hundreds of value chains of mission critical environments over a long period of time without service disruption.

Finally, the presentation will address to the vendors the increasing need for standardized management and provisioning interfaces as well as sufficient agility and flexible pricing models to support multi-sourcing strategies and multi-tenant service provider architectures.

back to program ^

This session looks at the drivers for Software Defined Networks (SDN) examining applications in the data center, provider networks and enterprise. It dives deep into OpenFlow with a content focus on the new version 1.3. The presenter, Michael Haugh, is chair of the Open Networking Foundation (ONF) Testing-Interop Working Group and will share insight on the interoperability test events and progression of the conformance program. Attendees will walk away with a good understanding of what SDN/OpenFlow is and the current maturity of this hot protocol.

back to program ^