WAN SDN Controller Deep Dive

My previous post, the overview of WAN SDN Controller is explained. So, in current post i will describe the functional element of WAN SDN Controller and it's correlation with some use-cases.

If we refer to Verizon SDN NFV Reference Architecture

Service Management

The Service management function for all aspect of service installation and management. It is hiding the complexity of the network since the resources are been abstracted, hence the northbound application/orchestration function can call to Service management API to create a complex services, which WAN connectivity only one of its component. let's say an orchestrator want to create DC interconnect which spanning from one DC to another. The orchestrator can call API to DC SDN controller to spin-up the VMs and create interDC connectivity with VXLAN. In parallel orchestrator tell WAN SDN Controller to prepare WAN connectivity from IP and Optical networks between the DCs

Resource Management and Optimization

This function enables northbound systems to create, modify or delete resources. It provides functions like optimal path selection, tunnel load balancing, bulk optimization, traffic reroute for maintenance actions, etc. The Resource Management function can use the statistics collected by the SDN Controller itself or it can interface with standalone analytics solutions that may trigger optimization actions.

The use case example are:

• Path(could be MPLS LSP or Optical Cross-Connect) creation and modification 
• Optimised the path based on certain algorithm, hence not following IGP mechanism normally based on cost, this could unlock stranded bandwidth form underutilized link connection which neglected by normal IGP path selection mechanism.
• Path optimization based on certain internal or external trigger. ie: if the link utilisation of certain link reach certain threshold the path that using this particular link is become subject to be optimised.
• FireBlanket, the WAN SDN controller can push a certain network policies to all IP devices in network perimeter based on external system intelligence that detected potential anomaly like DDoS attack.

Statistics and Topology

An SDN Controller provides several basic functions, such as statistics collection (per service and/or resource) and topology discovery. This information is used as input to the Resource Management function and can also be exposed to northbound systems via ReSTful APIs. 

Some of use case that can use this functional elements are:

• Network Statistic Data Warehouse, the statistic of the network can be exported to external data warehouse to be used for certain analytics.
• Offline Traffic Engineering, A tools can be developed to simulate certain scenario in the network by taking the advantage of statistic and topology information from this element 

Forwarding Rules Manager

When the network contains white boxes, a Forwarding Rules Function is required to define the exact set of forwarding rules to be pushed to those white boxes. The Forwarding Rules Manager takes into account topology information and the service and resource related inputs from the Service Management and Resource Management functions.

Adaptation

The adaption function translates abstract, device-independent data models that are used by the Service Management and Resource Management functions to device-specific data models. These device independent data models are service-oriented models that are rendered in YANG. 

South-bound protocol stacks

Depending on the network element and the required action, different protocols may be used. OpenFlow is one of the protocols of choice for managing white boxes. The choice of the south bound protocol depends on the use case and will also require additional adaptations / extensions. NETCONF (RFC 6241) is emerging is the primary candidate for provisioning network functions in general. PCE Protocol (PCEP, RFC 5440) is the primary protocol for path setup in RSVP-TE MPLS networks. PCEP, OF, and NETCONF are also being leveraged for Segment Routing-based MPLS networks. BGP-LS (still in the Internet Draft stage) can be used for topology discovery. In addition, certain network functions may require proprietary protocols. 

Most of south-bound protocol stacks are relatively new, for example Segment Routing this protocol is created to address the limitation of IP/MPLS technology.

WAN SDN Controller

Intro

Right now we don't need to spend much to realize an idea. With Cloud service delivery we don't need to setup server stack just to test an application prototype instead we can use cloud service like AWS lamda.

Cloud service delivery models also impacting the Communication Service Provider (CSP)'s services offering outlook. Enterprise demand CSP to be more agile turning up the service. Previously the service delivery model was CSP providing fixed pipe of bandwidth to enterprise in turn, enterprise will pay fixed price for the service. 

The service model looks simple fixed bandwidth for fixed price, actually it is like that because the  difficulty that CSP face to provide value added services ie: bandwidth calendaring, bandwidth on-demand with the legacy MPLS infrastructure which normally deployed by CSP. The difficulty lies on manual labor to align multiple CSP's organizations from planning, operation and customer service not to mention the IT/OSS departement to provide proper billing for such service.

By allowing applications to consume IT resources on-demand, cloud technologies have fundamentally changed the way datacenters (DCs) are being designed and operated. Software Defined Networking (SDN) extends the cloud model to the network by allowing applications to consume network connections as quickly and as easily as they consume virtualized compute and storage. In an SDN-based DC network, connections are not permanent entities; they are initiated by virtual machines in seconds, and are dismantled when no longer required. 

As the cloud expands to encompass multiple DCs and users across metro and wide area networks (MANs and WANs), applications will expect the carrier network connections that underpin this new, distributed cloud fabric to leverage SDN and be just as easy to set up and consume. 

As mentioned before Cloud service delivery change the way the CSP design and operate its network fundamentally. Software Defined Networking (SDN) initially introduced in Data Center (DC) environment by allowing the applications to quickly consume the resources like networks connections, virtualized compute and storage. Hence, the services can be build in seconds and collapsed in seconds. When the cloud service expanded to multiple DCs across WAN, the application will expect the carrier network connections that underpin this new, distributed cloud fabric to leverage SDN and be just as easy to set up and consume. 

What is WAN SDN Controller?

Achieving SDN in the WAN is no trivial task.  While DCs are simple, homogeneous and can count on essentially limitless bandwidth, carrier networks are complex, multi-vendor, and are subject to many technology and bandwidth constraints. Any attempt to introduce a faster and more automated way of provisioning the WAN must work in concert with provisioning systems for existing services. The dynamic consumption nature of distributed clouds and their users will put significant pressure on operational models designed for static and predictable traffic patterns. SPs will need to augment existing traffic engineering processes with a dynamic resource management capability that can ensure network efficiency, resiliency and availability in the face of rapidly changing cloud connectivity needs.

The industry has already begun the process of evolving SDN for carrier networks with proposals to abstract and open the proprietary packet/optical layer to external control using OpenFlow. While this is a good starting point, little value can be realized without a broader SDN framework that can provision and correlate topology, resource and constraint information across multiple layers – including packet/optical, Ethernet, IP and IP VPNs. Only a multi-layer SDN framework has the global visibility and universal control necessary to deliver on the SDN promise of increased network agility, efficiency and scale. 

Verizon's SDN & NFV Reference Architecture, has realized the vision to provide. it is Published is Published early 2016 by Collaboration between Verizon, Alcatel-Lucent, Nokia, Ericsson, Cisco, HP, Samsung, Intel and Red Hat which capture following Key points:

• Captured NFV MANO and SDN in a single architecture
• Recognized the end-to-end orchestration is more than just NFVO
• Recognized the difference between DC SDN and WAN SDN
• Showed an evolution of traditional EMSs to new management systems

WAN SDN Control entity - in general, a WAN SDN controller must accomplish the following objectives:

• Northbound APIs for network abstraction and programmability to be used by customer facing orchestration systems and third-party applications 
• Model-driven Adaptation Layer that allows network service models to help drive north bound and south bound mappings 
• Multi-layer and multi-vendor control 
• Automated management of end-to-end services
• Resource optimization 
• Topology discovery and rectification
• Statistics collection and processing 
• Provide a control interface to hybrid/classical control mechanisms

The following figure depicts the functional elements of WAN SDN Controller

WAN SDN Controller Use Case

The following are the use cases that is possible by the framework.

Optimal Path-Selection:

• Flow steering
• Egress peer engineering
• Enhanced quality of experience
• Enhanced ECMP

Automated Service Fulfillment:

• Simplified OSS and operation
• Cross layer correlation
• Zero touch configuration

Bandwidth and Link Management:

• Tactical path provisioning
• Tactical bandwidth provisioning
• Run the network hotter, unlock the stranded bandwidth

Assurance:

• Analytics driven optimization
• Telemetry
• Fault and alarm correlation
• Offline traffic engineering tool

Appify

appify — create the simplest possible Mac app from a shell script

https://gist.github.com/mathiasbynens/674099#!/bin/bash

if [ "$1" = "-h" -o "$1" = "--help" -o -z "$1" ]; then cat <
appify v3.0.1 for Mac OS X - http://mths.be/appify
Creates the simplest possible Mac app from a shell script.
Appify takes a shell script as its first argument:
`basename "$0"` my-script.sh
Note that you cannot rename appified apps. If you want to give your app
a custom name, use the second argument:
`basename "$0"` my-script.sh "My App"
Copyright (c) Thomas Aylott
Modified by Mathias Bynens
EOF
exit; fi
 
APPNAME=${2:-$(basename "$1" ".sh")}
DIR="$APPNAME.app/Contents/MacOS"
 
if [ -a "$APPNAME.app" ]; then
echo "$PWD/$APPNAME.app already exists :("
exit 1
fi
 
mkdir -p "$DIR"
cp "$1" "$DIR/$APPNAME"
chmod +x "$DIR/$APPNAME"
 
echo "$PWD/$APPNAME.app"

Reinventing Copper

Today, for broadband access technology everybody talking which is the better technologies for wireless.. LTE, TD-LTE, FD-LTE, LTE-Advance, but soon it will be SHIFT to wireline, because nonetheless, the speed and bandwidth battle is always won by the Cable Broadbad. 

There are two different medium for wireline access fiber or copper. For greenfield deployment fiber technology such as PON is the best solution. But... big telco provider tend to use existing twisted copper investment while gradually deploy their fiber network, how much copper technology can deliver the speed?  following graphic is the answer.

With VDSL2 as the base line, bonding is like bundling two pair of cable to get more bandwidth. headphone.While DSL Phantom Mode technology is a bit of magic for the copper network. It creates a third (phantom or virtual) channel over 2 regular copper pairs. Vectoring is canceling crosstalk between two pair of copper, the idea is same like noise-canceling technology in your headphone.

And the state of the-art-technology is ITU-T pre-standard, G.Fast. The main requirement of this standard is to achieve high peak rate 500 Mb/s at 100 m.  By combining VDSL+, bonding, phantom-mode, vectoring and G.Fast its field-proven we can achieve more than 1 Gb/s at 70 m.