1. Two demonstrations from 2001 and 2012 showed that SDN/OpenFlow and GMPLS can work together to provision optical paths. The controllers do not need optical network knowledge and end-to-end connectivity is maintained. 2. Lessons learned are that a logically centralized control plane with peer-to-peer data plane is better than full decentralization. Transport networks will aggregate IP and tunnel it, with multiple overlaying control planes. A SDN solution needs abstraction and coordination between IP and optical. 3. The document believes SDN will work by separating the control and data planes and introducing more virtualized packet and transport network services. GMPLS will remain an important provisioning protocol at the data plane level

1. SDN & GMPLS
Ping Pan, Ph.D.
March 9th. 2014

2.  Supercomm2001:
• Juniper and Calient have demonstrated GMPLS for packet over DWDM
• Simple drag-and-drop provisioning
• Multi-vendor, Multi-service, Multi-domain…
A story…
Juniper
A
Calient
B
Calient
C
Juniper
D
Path (AD, BW)  Path (AD, BW, ERO)  Path (AD, BW)
 Outcome:
• The GMPLS overlay implementation is straightforward, because the routers do
not need to know about optics; vice versa
• End-to-end IP connectivity and routing are not disturbed
• BTW, Juniper routers run MPLS; Calient boxes, GMPLS or whatever
• This remains to be the operational method today
• All the work (e.g. E-NNI) that requires extensive optical interface did not go
anywhere… due to operational complexity

3.  SDN Demo 2012:
• Esnet and Infinera demonstrated Transport SDN GMPLS over OTN
• Simple drag-and-drop provisioning
Another story…
Packet
A
Infinera
B
Infinera
C
Packet
D
OF (AD, BW) 
Path (AD, BW, ERO)
 Outcome:
• The implementation is straightforward, because the controller does not
need to know about optics; vice versa
• End-to-end connectivity and routing are not disturbed
• Packet-to-optical is VLAN; optical-to-optical is GMPLS (or whatever)
• Do we believe that the controller can do better than NNI if it has more
optical data? Is this a technical problem in the first place?
ESnet
OSCAR

4. 1. Peer-to-peer data-plane works
• The Internet is built with tunnels… tunnel over tunnel
• The tunnel end-points define the service demarcation boundary
• Tunnel end-points peer with each other and initiate services
• The belief of a flat network connecting all users is questionable
2. Hierarchical control-plane works
• The entire Internet is driven by this principle
• The connectivity data (routes) in one area cannot leak to another
area, without careful policy examination
• The interface between the hierarchies causes much of the complexity
• The belief that one controller can access and control all networks is flawed
3. Direct transport network provisioning is hard
• One major reason for the rapid traffic growth in the Internet is because of
advanced optical gears
• The advancement in optics has out-paced standardization by a long shot
• The belief that one provisioning interface can directly program optics from
multiple vendors is naïve
Lessons Learned

5.  Logically centralized/hierarchical control plane with peer to
peer data plane beats full decentralization
 Translation to transport networks:
1. Transport networks will aggregate IP packets at edge, and tunnel
them into various optical containers (OTN, DWDM etc.)
2. There will be multiple control planes overlaying on top of each
other
• VMware control-plane over IP routing
• IP routing over optical control-plane…
3. A SDN solution needs to…
• Virtualize transport networks with abstraction
• Coordinate IP-optical traffic through logically centralized server
• Leave component and device optical provisioning alone (GMPLS
is fine as it is!)
Here is our belief on SDN…

6.  SDN (the separation of control and data plane) will work
 At control-plane, we will see more virtualized services for
both packet and transport networks
• So long as OpenFlow remains simple, we will see its deployment
• Much work needs to be done on network operation and
management
 At data-plane, we will see bigger, faster and more efficient
transport devices
• More hardware component-centric switches in WAN and Metro Core
• More software-based switches in Access and Data Centers
 GMPLS, as a provisioning protocol at data-plane, will be in
operation for a long time
The Future (at least our prediction)