GMPLS and OpenFlow can coexist by implementing different models of interworking and integration. Key requirements for coexistence include extensions to support optical transport technologies, integrated northbound and southbound interfaces, and a common path computation engine that can handle multiple network topologies and provision flows across domains. A flow-aware PCE is proposed as an important component to enable joint routing of services across OpenFlow and GMPLS-controlled transport domains in a hierarchical manner.

1. Coexistence of GMPLS and OpenFlow
rationale & approaches
Nicola Ciulli Head of Research & Development, Nextworks
Pre-FIA Workshop
(G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
May 7th 2013, Dublin
With acknowledgments to the FP7 FIBRE project

2. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Incipit [1]
 Two questions and a discussion on the possible answers
2
Q1. Are OpenFlow (SDN at large) and
GMPLS really competing?… or is it
rather just a matter of a functional
split & redesign?
Q2. Can one prevail on the
other? … and can this happen in
all the cases?

3. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Incipit [2]
 Common design principles, not under discussion
 Separation of data and control planes
 Open interfaces to control network services
 And maybe there are different areas of initial application
3
Packet Networks
• Connectionless
• Enterprise/data centre origins
• Dynamic flows (short lived)
• EMS/NMS independent
• Monolithic, closed COTS
eqpt (control & data plane
merged)
Transport Networks
• Connection (circuit) oriented
• Service provider origins
• Semi-static pipes (long lived)
• EMS/NMS + cross-connect
paradigm
• Programmable systems with
GMPLS/PCE as control plane

4. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Act I: OpenFlow
 Primarily/natively a protocol to open the
box and make software/user-defined
classification& forwarding decisions
 A successful attempt for L2 devices w.r.t.
FORCES, GSMP, etc.
 The flow is the core concept (for packets
& circuits)
 Abstraction & slicing as a native feature
 All the network control logic (routing, TE,
BoD, etc.) is implemented by
applications on top of the controller
 Generally a centralized, master-slave,
control hierarchy
 OF switch to make the raw flow
classification & forwarding
 FlowVisor to create/maintain slices of
network resources
 OF controllers (e.g. NOX) to control each
slice
4
FlowVisor
OF Switch
Host 1 Host N-1 Host N
PACKET_IN
PACKET_IN
PACKET_OUT
PACKET_OUT
NOX core
NOX routing
app
NOX
topo. app
...
...

5. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
OpenFlow strenghts & issues
 Strengths
 A single unified network API for the many control applications
• True (so far) vendor-unlock (control app independence from hw gears)
• Towards an “open market” of network application developers
 Joint-optimization functions and services across packets and circuits due to the
centralized approach
 More programmability so far, thanks to access to the bare metal (cls & fwd engines
of the switch)
 Leverages on a wide set of open source projects (OVS, NOX, Floodlight, Trema,
OpenDaylight, etc.)
 Issues (?)
 Technology specific characterization & support
• Mostly L2 networks (+ a few optics attempts, ref. Ericsson or UBristol & Adva
research)
• Is it really possible to convey many different specific technologies and proprietary
extensions into a common unified rule-set?
– Think about GMPLS extensions for SDH/SONET, WSON, port-switching, etc.
 Scalability
• Challenges in making centralized controllers interact/cooperate with each other
 Very basic routing decisions in state-of-the-art controllers
• No TE, no weights on links
• Just one routing domain
5

6. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Act II: GMPLS + PCE
 The label and the Label Switched Path as core concepts
 Support for L2, TDM and WSON switching capabilities
 An information model based on the abstraction into logical resources (e.g.
Link Component / physical port, link bundling)
 A stack of protocols for distributed
 topology discovery and resource capabilities/availabilities dissemination
 resources reservation and allocation
 recovery
 [hierarchical] path computation
 Routing and signalling states distributed on the various controllers
 Standard interfaces (UNI, I-NNI, E-NNI) for the inter-vendor operations
6

7. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
GMPLS + PCE strenghts & issues
 Strengths
 De-facto control plane standard for transport networks (core/backbone)
• automatic network service provisioning and restoration
 A rich feature set for the fine tuning of different technologies (T-Eth, SDH/SONET,
WDM/WSON, etc.)
 Consolidated to respond to transport network requirements in all implementations
and deployments
• Manageable (e.g. SNMP)
• Integrated with NMS/EMS
 Consolidated by many SDOs: IETF, ITU, OIF, MEF
 Issues (?)
 Technology specific characterization & support
• A long process to agree on standard representation/control of new techs
 Abstraction
• Node resources modelling and control is a typical challenge (out-of-scope problem
for GMPLS + PCE)
 Full user/operator control of resource allocation
• GMPLS/PCE automation never exploited fully by most network operators
• Commercially, UNI has never been truly delivered to overlay customers
 Sw implementations are not open & decoupled from hw
• GMPLS stack often sold in bundle with the transport network node
7

8. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Act III: GMPLS vs OF… fight or choice?
 “Control Plane Complexity”
 Different technologies may imply complexity, as well as distributed
states
 GMPLS may seem more complex than OF (+ctrls), but
• just a few (very simple) network applications for routing in OF/SDN
appeared yet. Will these scale well for large networks?
• OF supports well L2 switching, what about all the other techs?
• Distributed state is complex but useful for critical resiliency (e.g. on-the-
fly restoration)
• Distributed TE and its convergence may slow down reactions, but routing
areas/domain are right there to help mitigate this
• As of today, GMPLS is more complex than OF simply because it still
does more things
– Recovery
– Multiple transport technologies under the same control instance
– multi-layer/multi-region/multi-domain
8
Based on issues identified by Das, Parulkar, McKeown in
“Why OpenFlow/SDN Can Succeed Where GMPLS Failed”,
ECOC 2012

9. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
GMPLS vs. OF… fight or choice? [2]
 “Lack of a common map-abstraction”
 Both OF and GMPLS have a common map (topology) for the control
applications:
• in OF it’s the [abstract/virtual] node model (node, port, vlan, etc.)
• in GMPLS it’s a topology of nodes & links in the domain with specific
switching capabilities
 Different approaches to abstraction
• In GMPLS, resource abstraction is generally delegated to the node
information model
• In OF, it is done by FlowVisor
 Different goals/scopes of network API, by design
• In GMPLS there’s no need for the user to access the abstract resources
directly. The control plane does it on user’s behalf, packaging their
control under circuit services
• In OF, the user can make his app for resources mangling
 “Lack of a gradual adoption path”
 Simply not true. Every new technology has a gradual
migration/adoption path (both horizontal and vertical)
9

10. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
GMPLS vs. OF… fight or choice? [3]
 Therefore, it’s all about
 Which functions are needed in the specific network context
(datacentre, access network, core network, etc.)
 What we want to have in and out of the box
 GMPLS and OF can coexist depending on the split we implement
10
“The fact that Google is doing it [SDN] is not a strong indication
that service providers are going to do it tomorrow. Google has a
relatively simple Ethernet/WDM networks which is why they are
able to pull it off”
Mark Lutkowitz, Telecom Pragmatics
“The management of optical is different from managing a
packet switch or a TDM [circuit switched] platform. We need
to deal with transmission impairments and constraints that
simply do not exist inside a packet switch.”
Jörg-Peter Elbers, CEO ADVA Optical Networking

11. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
In the broader SDN picture…
 SDN is a nice design principle
 Not brand new, but useful to compose a broader OSS picture
 Looking at OF and GMPLS from a higher (SDN) perspective…
 Both can fit the SDN design principle
• OF “natively”
• GMPLS can well fit the SDN design principle (e.g. as a driver for
transport networks)
 What really matters, in the end, is…
 the right split point in the overall architecture, depending on
• The involved technologies (optical, packet)
• The place in the network (DC, access, aggregation, core, etc.)
• The role & business of the operator (ISP, carrier, etc.)
 i.e. what does the operator has to program?
• The behaviour of single nodes?
• Or, e.g., circuit services at large? (e.g. restoration techniques)
11

12. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Act IV: to coexist or not to coexist?
12OPEN123 – SDN RESEARCH INCUBATOR & SHOWCASE
Cooperating
SMART
BROKER(s)
kernel
(SDN Controller)
Open Resource Access
OF
proxy
SNMP
proxy
XXX
proxy
Service Intelligence Routing
Intelligence
Topology
Discovery
Path
Computation
HierarchyTunnels
Mgmt
Routing
Algorithms
Statefulness
Data Plane
(OpenFlow)
Control Plane
(GMPLS/MPLS) Mgmt Plane
Data-Path
Mgmt
Alarms &
Performance
[Re-]planning &
Network optimization
Southbound Interface
(Multiple protocols/APIs)
Northbound Interface
(SDN APIs)
drivers
(network techs / CP / MP)
User-defined
Routing
Algorithm
user space
(3rd party apps)
[Parent]
Path
Computation
Policy Mgmt
User-defined
Service
Mgmt
Cooperating
SMART
BROKER(s)
Cooperating
SDN
Controller(s)
E/W
Interface
User-defined
Network
Analytics
User-defined
Network
Planning
...
Abstraction
...

13. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Coexistence model #1: OF over [G]MPLS
13
GMPLS
Extended FlowVisor (Network slicing)
Extended OpenFlow Controller
BoD administration
BoD Network Management Interface
GMPLS NMI / UNI
Path/Flow
Computation
Engine
OF DOMAINOF DOMAIN
GMPLS DOMAIN
OF protocol
OF protocol

14. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Coexistence model #2: [G]MPLS over OF
14
GMPLS
Extended FlowVisor (Network slicing)
Extended OpenFlow Controller
BoD administration
BoD Network Management Interface
OF protocol
BoD user
BoD User Network Interface
Slice of network
resources offered for
GMPLS-controlled
BoD services
Path/Flow
Computation
Engine
OF DOMAINOF DOMAIN
GMPLS DOMAIN
OF protocol
OF protocol

15. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
A brief discussion of them
 OF over [G]MPLS
 GMPLS is grouping a set of nodes (e.g. WDM ring) and exports an OF
virtual/abstract node
 The GMPLS northbound i/f should be OF node like
• With UNI, no control of the GMPLS resources and paths  not a complete
solutions (need to complement with other NB i/fs, e.g. for topology)
• With NMI, ERO can be decided in the upper layers also for GMPLS domain
 Need to export partial or full topology info to the upper layers (e.g. just border
nodes, or full topology)
 Hierarchical PCE can solve the scalability and policy issues
 [G]MPLS over OF
 OF is the standard for GMPLS southbound i/f for all the nodes
 Need OF extensions for the optical resource control
 Need to correctly map the L2 switching capabilities into the GMPLS logical
topology
 Different technology domains may result in GMPLS TE routing domains
• Hierarchical PCE can ease multi-layer/region handling
• multiple topologies (optical & L2) handled in a common Path/Flow
Computation Engine (Flow-PCE)
 Can really implement virtual GMPLS topologies across OF-controlled
switching domains (packet-MPLS/optical)  “GMPLS CP as a Service”
15

16. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Some coexistence requirements (aggregated)
 OF extensions for the optical resource control
 GMPLS extensions
 A GMPLS northbound i/f OF node aware (in approach #1)
 A GMPLS southbound i/f OF protocol capable (in approach #2)
 Tools that can help design virtual GMPLS topologies
across OF-controlled switching domains (packet-
MPLS/optical)  “GMPLS CP as a Service”
 Bind flow/circuit provisioning to users’ application (OF
app integrated with BoD workflow)
 Handling of multiple topologies (GMPLS & OF in
approach #1) in a common Path/Flow Computation
Engine (Flow-PCE)
16

17. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Summary of coexistence models & requirements for OoG
17
resources setup
opaque signalling transparent
routing
info
opaque
GMPLS grouping a set of nodes (e.g. WDM
ring) with no topology info
• Optical OF
• GMPLS NB and SB i/fs
• GMPLS CP as a Service
• OF app binding with BoD
• F-PCE
Does it make sense?
• Optical OF
• GMPLS NB and SB i/fs
• GMPLS CP as a Service
• OF app binding with BoD
• F-PCE
transparent
GMPLS grouping a set of nodes (e.g. WDM
ring) with topology info
• Optical OF
• GMPLS NB and SB i/fs
• GMPLS CP as a Service
• OF app binding with BoD
• F-PCE
Transparent GMPLS
• Optical OF
• GMPLS NB and SB i/fs
• GMPLS CP as a Service
• OF app binding with BoD
• F-PCE

18. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
A key brick: Flow-aware PCE
 A Path Computation Element for multi-region/multi-
layer nets
 based on IETF PCE architecture (RFC4655)
 Hierarchical for the multiple domain routing abstraction
 Joint routing services (explicit [flow] routes) for OF and transit
GMPLS domains
18
Child PCE
Domain “A” Child PCE
Domain “Z”
Child PCE
OF domain A
edge
OF Domain Z
edge
Parent
PCE
Domain
Transit
(GMPLS, BoD)

19. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Flow-aware PCE essentials
 A Path Computation Element for TE constraint-based path
computation in multi-region/multi-layer nets
 Based on IETF PCE architecture (IETF RFC4655)
 Can include topologies from OF domains, [G]MPLS domains, ALTO
servers with different topology detail levels
 Compose network services related e2e flow routes
 allocate/select flow identifiers in OpenFlow domains
 allocate/select (legacy) switching resources in transit domain
 same PCE code or even same instance for different domains
 Support hierarchical deployment (iterations of child/parent) for
enhanced inter-island flow computation
 Child Flow-PCE for intra-domain flow computation
 Parent Flow-PCE for inter-domain flows
 Can maintain also topology info about IT end-resources (e.g. servers
and VMs) and resource status
 Can use this augmented topology info when computing a flow path
19

20. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Finale
 GMPLS has its solid market position in [optical] transport networks
 ok, right, as just an arm for NMS-driven circuit setup…
 OpenFlow’s hype is mostly justified for innovating DC networking
 Virtualization, abstraction etc. are much more critical in the datacentre…
 …which is a “tamed” networking environment (i.e. mono-operator, mono-
vendor, mono-tech, etc.)
 Core GMPLS specs are mostly consolidated and cross-validated by
many SDOs
 Most has to be defined in OF yet
 Great potentials and interests, some OSS components (but why a closed
ONF forum?)
 In the end, GMPLS+PCE and OF are just a collection of protocols
and interfaces that can cooperate in a broader SDN picture
 Ok, GMPLS and PCE are more than protocols (i.e. architectures), but
you don’t have to buy the whole package
2020

21. Pre-FIA Workshop: (G)MPLS and OpenFlow: Interworking, Integrating, or Replacing?
Thank you! For any further info…
Nicola Ciulli
Head of Research & Development
n.ciulli@nextworks.it
info@nextworks.it
www.nextworks.it
HQ: via Livornese, 1027, 56122 Pisa (Italy)
Tel: +39-050-3871600
Fax: +39-050-3871601
21
Nextworks R&D on F-PCE and distributed SDN architectures are
partly funded by the EC through FP7 FIBRE project
www.fibre-ict.eu