OpenFlow experience in Transport Networks, iPOP'2013, Ping Pan

iPOP2013, Tokyo, Japan

Development and Testing Experience

on Transport SDN

Michael Frendo

Ping Pan

Infinera


Transport SDN is on the horizon…

Data Center

Switch VM

VM

VLAN

VLAN

Data Center

Switch VM

VM

VLAN

VLAN

WAN Transport

Switch Switch

Switch Switch

Switch

Metro

Metro Switch

Switch

Switch SDN

Controller


One Key Motivation: simplify network operation

Source: OFC/NFOEC’2013 SDN Workshop


Transport SDN Framework…

Overlay Network

Path Computation

VPN Bandwidth on

Demand

Packet Infrastructure

Transport Infrastructure Wireless Infrastructure

Offer network services through

overlay

Interface the network through virtualization

This is hard in multi-vendor multi-layer environment


Open Transport Network via Virtual Switch

Open Transport Switch (OTS) is a light weight software switch installed on transport switches for network resource virtualization

Through OTS, the SDN Controller can provision, monitor and configure the underlying switches and networks

SDN Controller

WDM/ OTN/

Packet

WDM/ OTN/

Packet

OTS OTS

Traffic Traffic

Applications


High Level View of OTS

OTS-Management Agent

OTS-Control Agent OTS-Data Agent

Control Plane

XMPP/others YANG /JSON

OpenFlow

SDN Controller

Data Forwarding Plane

Physical Interfaces

N

Internal Communication

Transport Switch

Platform


Infinera – ESnet Demo: background

• Provide services to more than 40 DOE research sites, including the entire National Laboratory system, its supercomputing facilities

• Connect to 140 research and commercial networks, permitting scientists to collaborate with partners around the world

• Carry between 7 to 10 petabytes of data monthly, with traffic an average of 10 times every 4 years


Demo Setup

bnl-tb-wdm-3 bnl-tb-wdm-4

40G

100G

20G 20G

20G L1 Tunnel

Topology Monitoring App BW on Demand App

ESnet SDN Controller

Mellanox Mellanox

Path #1

Path #2

Path #3

OTS OTS

ESnet LIMAN Production Network

Brookhaven National Laboratory Testbed

SDN Controller “talking” to Open Transport Switch (OTS) via OpenFlow 1.0 extensions

Bandwidth on Demand application for Big Data transport

3 physical transport path options (with varying latencies)


Setup an Edge-to-Edge Connection from Application


OpenFlow 1.0 and Extension


Network Resource Inventory


What we have learned: the good

1. OpenFlow is good enough

– Transport networks support far less complex connection

configuration scenarios:

• Same type, same granularity: ODU2e – ODU2e cross-connect

• Different type, same granularity: 10GE – ODU2e cross-connect

• Same type, different granularity: ODU1 – ODU2 mux

• Different type, different granularity: VLAN – ODUflex mapping

2. Packet and optical provisioning all look the same

– The operators simply ask for “connection X, bandwidth Y etc.”

– The connection can be packet, OTN or ROADM…

3. No need for per-vendor-specific interface

– OTS hides all the special commands (TL1, CLI, SNMP etc.)

– Huge deployment cost saving


What we have learned: the good (cont.)

4. Leveraging the existing provisioning mechanisms

– The OTS provisioning commands may trigger the use of

(G)MPLS for circuit setup

5. Converging on packet and optical network management

– Optical networks use NMS; packet networks use CLI

– Here, the operators program each node directly, may that be

packet or circuit

6. Ease of 3rd. party application plug-in’s

– Through the same interface, many 3rd. party applications can

interface with the networks

– There are many OpenFlow-friendly tools available now

7. Straight-forward implementation

– Most of the protocol implementations are open sourced.


What we have learned: the bad

1. Circuit provisioning is important, but the configuration

and monitoring functions are absolutely critical!

– SDN Controller needs to know:

1. System configuration and interface capability

2. Network topology

3. Network resource usage

– SDN controller must be able to query and sync with the networks

– Our lesson: the mapping between SDN and the devices can be

out of sync, and creates “black holes”

2. Network alarm support is critical

– Need to have a scalable way to notify the SDN Controller on

network failure… reliably

– Our lesson: a technician unplugged an interface right before a

big demo at a remote location. The controller did not know…


What we have learned: the bad (cont.)

4. OpenFlow 1.0 is not suitable for transport networks

– All interfaces and ports are Ethernet

– Our Lesson: we had to introduce extension to “mask off”

Ethernet-specific information


What we have really learned…

1. OpenFlow 1.3 is good enough for transport networks

– The key is in the definition of “virtual interface” or “logical port”

2. YANG is a good data modeling solution to support

network configuration and monitoring capabilities

– Actually, IETF I2RS has arrived to the similar conclusion

independently, where they use YANG for route topology export

3. JSON/HTTP REST is simpler than NetConf (and

OFconfig)

– The message representation between SDN Controller and

network devices can have significant impact on development…


Here is the message sequence for programming transport devices….

GET, http, application/sdn-system-info+json

200, OK, (“port “:[“id”, “bandwidth”, “capability”])…)

GET, http, application/sdn-topology-info+json

200, OK, (“node“:[“IP”, “next-hop”, “bw”, “available bw”])…)

GET, http, application/sdn-connection-info+json

200, OK, (“connection“:[“source”, “destination”, “bw”, “ero”])…)

POST, http, (“connection“:[“source”, “destination”, “bw”, “ero”])…)

OpenFlow: Virtual Port X is up for the connection

OpenFlow: Virtual Port X Virtual Port Y, connection up

SDN Controller

Transport Switch

Virtual node bring-up

Populate topology table

Network resource

monitoring

Setup connection Trigger LSP

setup

Setup cross-connect


Here is what TE topology data may look like…

{

"links":[

{

"id":"urn:ogf:network:domain=infn-demo:node=infn-dtnx-1:port=300",

"nodeID":"192.23.4.5",

"localNode":"10.1.2.3",

"remoteNode":"10.1.7.2",

"MaxBandwidth":"5000000000",

"UsedBandwidth":"1000000000",

"MaxReservableBandwidth":"20000000000",

"TrafficEngineeringMetric":"100",

"ProtectionCapability":"yes",

"SRLG":"10",

"encodingType":"OTN",

},

{

"id":"urn:ogf:network:domain=infn-demo:node=infn-dtnx-1:port=301",

"nodeID":"192.23.4.5",

"localNode":"10.1.2.5",

"remoteNode":"10.1.52.2",

"MaxBandwidth":"100000000000",

"UsedBandwidth":"0",

"MaxReservableBandwidth":"100000000000",

"TrafficEngineeringMetric":"200",

"ProtectionCapability":"no",

"SRLG":"20",

"encodingType":"Ethernet",

}

]

}


Conclusion

• Transport SDN has real business value to service

providers

• OTS provides a robust architecture for all transport

network devices

• OpenFlow can be used for transport networks

• Network topology monitoring, resource query, alarms and

system configuration are critical to SDN network

operation

OpenFlow experience in Transport Networks, iPOP'2013, Ping Pan

Technology

Transcript of OpenFlow experience in Transport Networks, iPOP'2013, Ping Pan