SDN Based Traffic Engineering

In my previous post i mention one of WAN SDN use case is Traffic Engineering (TE). This post will reveal what improvement that SDN based TE can offer compared to classical TE.

Classical Traffic Engineering in many WAN network, RSVP based TE is commonly used to accommodate a data path that not following the calculation of routing protocol.

However RSVP-TE also have shortcoming, hence not optimal solution.

• The CSFP alogrithm contained in oane IGP area.
• N-Squared, RSVP requires to established complete full mesh LSP between all PE
• Hold the state of RSVP session in the node, consume more CPU and memory resources
• Relatively complex control plane, small router could have an issue if it joining a big network.

Although many workaround is provided to overcome the issues mentioned, but it just introduce more complexity inter term of network design as well as operation. Hence all this problem lead the birth of new simpler protocol, Segment Routing.

Segment Routing is tunneling protocol which based on the Source Routing paradigm, the source node know the path to tail-end node, encode the segments (which form the path) in packet header and use OSPF/ISIS extension to carried segment information. 

                               

The segment is encoded as:

• MPLS label or an ordered list of hops represent by a stack of MPLS labels, similar like regular MPLS data plane.
• IPv6  address or an ordered list of hops represent by a number of IPv6 addresses in the IPv6 extension header.

We can think a segment as a set of information from ingress PE to dictate how is the packet is going, whether follow the shortest path to node N, follow the shortest path for prefix P, or explicitly define which link/node/ to go node N. The application of Segment Routing for Shortest path application is illustrate below

PE2 advertises Node Segment into IGP (Prefix-SID Sub-TLV Extension to IS-IS/OSPF) then all routers in SR domain install the node segment to PE2 in the MPLS data-plane - a segment is actually an LSP, in this process no LDP or RSVP control-plane involved. Traffic that going from PE1 to PE2, PE1 pushes on node segment {800} and uses shortest IGP path to reach PE2. Active segment is the top of the stack for MPLS, P1 and P2 implement CONTINUE (swap) action in MPLS data-plane, P3 implements NEXT (pop) action. No state held in network with the exception of segment list for tunnel held at PE1. 

For the Traffic Engineering application, the path can be computed either distributed in each router involved along the path - similar like classic RSVP-TE or centralised by external computation engine.

Path Computation Element, One of WAN Controller component is The Path Computation Element (PCE) which has the concept to separates between path computation and path signaling function which will gives operators more control of their networks, adds ability to apply network operator policies, address multi-vendor integration considerations. 

Before PCE can compute the path it has to understand the view network topology to built Traffic-Engineering Database (TED) in which WAN controller can ease this by establishing BGP sessions to one or more router or path computation Client (PCC). Through this sessions PCE receives link-state prefixes via BGP-LS NLRI.

After the network topology can be discovered, WAN Controller can perform path computation and asked routers of the network to established, re-signal or tear-down where Path Computation Element Protocol (PCEP) facilitated this.

All in all, the protocols explained are introduced to addressing the problem space happed in most of WAN network, become a building block for SDN Based Traffic Engineering. Segment Routing, which expected to replace RSVP-TE because its comes with low overhead. And with PCEP, the calculation of path is off-loaded to WAN SDN Controller which in turn can reduce manual path provisioning also provide also the abstraction of network resources hence more complex path calculation objective and constraint can applied easily.

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"