Software Defined Networking (SDN) and the closely related technology innovation of Network Functions Virtualization (NFV) have been amongst the hottest topics recently discussed in the media and at industry conferences. These will undoubtedly have a significant impact on many aspects of networking in years to come and in the not too distant future these will be defacto capabilities in all networking solutions in one form or another. SDN in particular has been widely discussed and often in general terms that address all types of networks without addressing the specific challenges associated with SDN in transport networks.

Transmode has taken a pragmatic and evolutionary approach to SDN

that allows network operators to deploy Enlighten™ with the SDN

Controller to migrate in a simple and controlled manner without

the need for any hardware upgrades within the packet-optical

network. The solution uses a standards-based Path Computation

Element (PCE) engine and open standardized interfaces such as

OpenFlow, PCEP and MTOSI, along with innovative virtual routing

functions to address multi-layer packet-optical networks and the

specific challenges addressed by transport networks in multi-vendor/

technology environments.

This application note discusses SDN and relevant aspects of NFV,

how they can be applied to transport networks. It also addresses

the benefits of increased automation with lower operational costs

and better network utilization that the solution brings to network

operators of all sizes and how Transmode is evolving packet-optical

management and control to incorporate these capabilities.

Software Defined Networking Transmode’s approach to SDN-Enabled Packet-Optical Networking

Application Note

SDN – What is it?Software Defined Networking, as the name implies, is an approach that allows network operators to manage their networks with a level of abstraction that removes the complexities of the underlying hardware by separating the data and control planes. This approach started within the server heavy world of datacenters where the ability to standardize and simplify hardware and move networking functions to the software domain can bring great economic and operational advantages.

To put it simply, SDN removes the need for network control functions and intelligence from the network elements as these functions are provided by an SDN controller. This simplifies the data center network elements, simplifies operations and makes multi-vendor networks considerably easier to manage.

Fig. 1 The evolution to SDN moves the control functions from the network to an SDN controller.

Why is transport special?SDN is now evolving to address the wider area domain of telecoms networks. Within these networks, functions at the higher levels of the OSI stack easily use the same model as the one used inside datacenters, as the primary purpose of these systems is the handling of data with no real need to understand or handle physical data transmission. Systems towards the lower end of the OSI stack need to also consider these transmission/transport related factors as they evolve to handle SDN capabilities. Beyond considering data handling, the lower layer systems have to consider the physical network and the many complex aspects of running transmission networks over this network.

This new paradigm is of interest to many network operators as it creates a number of advantages over today’s network architectures. It enables a higher level of automation in end to end path computation and creation, and it gives a better understanding of the overall network topology which enables improved network resource utilization. Furthermore, it enables easier service provisioning across multiple network layers and enables simpler

programmability of new functions across these layers. For all these reasons, SDN is considered by the industry and many industry observers to be a very significant industry trend.

Standardization of SDNSDN touches almost all aspects of networking. This has great advantages as it offers the possibility of real centralized control over all these aspects over a single complete end to end network. But this also throws up a number of issues that need to be addressed.

The SDN initiative requires a lot of vendor cooperation and standardization to make this viable. The vast majority of vendors are very supportive of the SDN activities, but this touches many areas where different standardization bodies are involved in various standardization activities. This includes most of the usual standardization bodies such as the IETF, the OIF and the IEEE plus some SDN specific organizations such as the Open Networking Foundation (ONF) and Open Daylight.

Vendors developing SDN architectures need to ensure that the solutions they develop can work in environments that contain multiple approaches to SDN as well as multiple vendors and technologies.

SDN for Transport NetworksAs Transmode’s area of interest within networking is confined to packet-optical networks, we will now focus on this area of SDN, specifically SDN for transport networks. This predominately addresses networks built by service providers but also covers some other aspects of networking such as data center interconnect networks and networks built by large enterprises for their own use. It does not address SDN within the datacenter or an Enterprises’ own LAN environment, just connectivity between datacenters and LANs.

Transport networks face a number of challenges that aren’t as significant in other areas of the operators’ networks. Any SDN solution for transport networks must be able to address the points raised earlier concerning the need to have a better understanding of the physical network and the engineering rules associated with running traffic over the network.

Transport networks address multiple networking layers (ROADM switched WDM wavelength, Layer 1 technologies such as OTN, Layer 2 Ethernet and Layer 2.5 MLPS-TP) to support higher level services and traffic. There is currently a lack of automated provisioning across these layers that would simplify and significantly speed up network operations that are often cumbersome and time consuming.

2 3

Application NoteApplication Note

In addition, SDN in transport networks offers the possibility of addressing the challenge of end-to-end service provisioning across network domains built with equipment from different vendors.

The challenge of distanceOne of the fundamental principles of SDN is that network control decisions are made in a controller that communicates with network equipment that is simpler than perhaps it would have been before.

In order for the equipment to respond quickly to the dynamic nature of its traffic, it requires that there are no significant delays in the communication between the SDN controller and the network element. Within geographically smaller networks such as those within data centers, this doesn’t present much of a challenge as the controller is located very close to the network element.

This could be anywhere from a few meters to a few 100 meters but from a control message latency point of view this distance is insignificant. However, in transport networks a central Network Operations Center (NOC) typically controls all or a large area of the network and this can be 1000s of kilometers from the extremities of the network.

The time it takes from signaling messages to travel to and from the remotest network elements can now have a significant impact on the ability of an SDN network to function correctly as the solution scales to handle higher levels of signaling traffic and a transport-oriented SDN architecture must consider and resolve this challenge of SDN controller distance.

The challenge of scalabilityA closely related challenge that SDN for transport networks must address is the challenge of scalability. Put simply, these networks are complex and large. They involve multiple OSI layers, multiple services and multiple technologies over thousands of nodes each with a potentially large number of ports and interfaces. Not only must an SDN solution have enough power to manage such a complex network today, it must have the ability to scale further as the network continues to grow.

Hierarchical controllers – a way of solving distance and scalability issues?The way to address the two challenges mentioned above is to build a hierarchical SDN controller architecture that can keep the controller function close enough to all nodes in the network and that can scale to match the networks future growth demands.

Transmode’s SDN approachTransmode’s long term focus has revolved around simplicity of networking within metro and regional networks, providing the functionality that is required without bringing in functionality from long distance networks unless it is really needed. This has allowed the company to produce very efficient products which hit the price points customers are looking for and allows Transmode to add metro specific features that can add real benefit, such as the family of Layer 2 Ethernet Muxponders that are the cornerstone of the Native Packet Optical 2.0 architecture.

One consequence of this approach is that Transmode has always kept the control functions of the network separate from the network elements and more closely associated with the management layer in an SDN-ready architecture, as shown in the multi-layer architecture in figure 2.

The term control could be seen as a little ambiguous as it means different things to different people depending on their area of interest within networking. Here the term refers to functions such as policy for path routing decisions rather than functions such as protection switching and traffic shaping/policing decisions which are always handled locally within the network element.

Fig. 2 Traditional architecture verses Transmode’s multi-layer architecture and SDN approach.

An evolutionary approachThe multi-layer architecture with centralized control as a function of the Transmode Network Manager (TNM) is the ideal starting point for adding SDN capabilities to the network. The approach allows for an evolutionary rather than revolutionary approach, which is appropriate for transport networks that are already widely deployed and the underlying infrastructure over which all networks run.

Key to this evolutionary approach is the subtle move of control functions from the control domain to the SDN controller. This means the move of these functions from a Network Management System to an SDN controller.

These functions include service related functions such as resource discovery, routing & signaling, traffic engineering, link/path management and dynamic service provisioning.

3

Application NoteApplication Note

Fig. 3 Transmode’s SDN approach.

Path Computation Element While SDN is a relatively new concept, the idea of splitting the data and control planes and using a remote controller is not exactly new. This concept has been used in the IETF since 2006 in the Path Computation Element standard as defined in RFC 4655. This is a control protocol that works in MPLS and GMPLS networks, and partially removes the path computation from head-end routers to define network paths.

Within Transmode’s SDN architecture, the PCE is a software module that is part of the SDN controller, which is part of Transmode’s Enlighten multi-layer management/control suite. Ultimately, the PCE engine within the SDN controller will provide path computation across Layers 0, 1, 2 and MPLS-TP to perform any requested path computation function.

The remaining management functions include performance management, fault management, security management and software control – all essentially functions related to the management of the node instead of control of individual services.

The migration to an SDN based architecture essentially involves the move of these control functions into an SDN controller along with the necessary functionality in the network element to respond to this control. Also the architecture needs to manage interfaces to external systems via various protocols, including those defined by the new SDN focused groups, such as the OpenFlow, MTOSI and PCEP protocols.

Transmode’s SDN architectureThe migration to Transmode’s SDN architecture requires the control function to be considered as three separate network management functions. The first two of these, and the most significant from an initial deployment perspective, are the Topology management and the Path Computation Element (PCE) functions. The Topology manager maintains a complete database of all Layer 0, Layer 1 and Layer 2 network elements, status of all the external ports and the routing between all network elements.

The PCE is a significant part of the Transmode SDN architecture and represents an important difference to some other approaches available in the industry. The third function is a selection of virtual routing functions using the Network Functions Virtualization (NFV) capabilities and these are important in the later stages of the SDN evolution.

These 3 modules are accompanied by a selection of southbound interfaces to Transmode network elements and northbound open interfaces to the TNM and other SDN controllers.

It is important to note that Transmode’s SDN strategy is to provide a solution for the management of Transmode network elements via the SDN controller. Due to the complexities of managing the optical domain with the highest possible performance, Transmode believes that it is critical that this is performed by a Transmode controller that is dedicated to just Transmode network elements, rather than extending the capabilities to other vendors transport solutions. Interworking in a broader multi-vendor environment is, of course, important and this is achieved via controller to controller interfaces and the virtual routing functions.

4 5

Application NoteApplication Note

Virtual routing functions using NFV As previously mentioned, the virtual routing functions of the SDN controller play an important part in the SDN approach and rely on some key advantages of the Transmode packet-optical network elements.

Transmode’s family of Layer 2 Ethernet Muxponders (EMXP) are the cornerstone of the Native Packet Optical 2.0 architecture. While the EMXP family is designed to perform Layer 2 switching and aggregation, in order to perform some advanced functions they also contain a filter capability that enables the devices to read higher order signaling and messaging on traffic ports.

This functionality is used for example in the Switched Video Transport solution where IGMPv3 messages are read and then Layer 2 multicast switching is performed to optimize

the video distribution network. This capability allows Transmode to bring virtual routing functions under the SDN approach which is a function that many other transport solutions might not be able to achieve.

The virtual routing functions enable the SDN enabled packet-optical network to respond to signaling messages embedded in the incoming data stream from external networks. This enables the network to assist in the setting up of end-to-end paths across a wider multi-vendor/technology network. This assists in the virtualization of some functions previously found in routers across the packet-optical network and SDN controller. The end result being easier provisioning of services end-to-end across multi-domain networks, as shown in figure 4.

5

Fig. 4 Virtual routing functions in action.

The hierarchical SDN architecture Earlier, we discussed the specific challenges faced when creating an SDN-enabled transport network and that the hierarchical approach resolved two of these challenges – controller distance/signaling latency and overall SDN controller scale.

Transmode’s implementation of the SDN controller neatly fits into a hierarchical architecture as the controller controls a specific packet-optical network and can communicate east-west and north-south with peer and higher level SDN controllers as well as other control planes. This approach

keeps the SDN control close enough to avoid issues with controller distance and associated signaling delay and allows network operators to scale their overall SDN environment as desired. It also gives them reassurance with the knowledge that the packet-optical networks are controlled by an SDN controller designed to understand the packet-optical domain and ensure that the best performance and economics is maintained, as shown in figure 5.

Application NoteApplication Note

App

licat

ion

Not

e_SD

N_A

Transmode’s step-by-step SDN evolutionSDN is currently a new and exciting paradigm in telecoms and offers a future architecture with many cost and operational benefits. But the road to SDN needn’t be a giant revolutionary step, it can be a step-by-step evolution. Today Transmode’s networks are managed via the TNM with end-to-end multi-layer service provisioning and interfaces to external OSS systems in an SDN-ready environment.

ConclusionsSDN has created a lot of excitement in the telecoms industry and offers the possibility of greatly simplified network automation and in some higher layer systems, the possibility of simplified and lower cost hardware. Transmode has taken a pragmatic and transport oriented approach to this opportunity by creating an SDN environment that is optimized for packet-optical networks, clearly addresses the challenges that transport networks pose and can be easily evolved to when the network operator is ready.

Fig. 5 The hierarchical SDN controller architecture

The Transmode approach to SDN provides network operators from data center owners and large enterprises through to service providers of all sizes with the ability to perform multi-layer path selection with centralized hierarchical control. It provides collapsed and integrated restoration and protection functions for Layer 1 optical, Layer 2 Ethernet and MPLS-TP services while fulfilling OAM and SLA functions. One additional key capability is the interoperability with the IP service layer through the virtual routing functionality and the hierarchical architecture addresses the challenges of controller distance and scalability.

This results in simplified and automated end-to-end service provisioning, better interoperability with other networks and better utilization of network resources.

The specifications and information within this document are subject to change without further notice. All statements, information and recommendations are believed to be accurate but are presented without warranty of any kind. Contact Transmode for more details.

www.transmode.com

Application Note