coexistence of gmpls and openflow: rationale & approaches

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

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?


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


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

...

...


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


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


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


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


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


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


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


Act IV: to coexist or not to coexist?

12 OPEN123 – 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 Hierarchy Tunnels

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

...


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 DOMAIN OF DOMAIN GMPLS DOMAIN

OF protocol OF protocol


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 DOMAIN OF DOMAIN GMPLS DOMAIN

OF protocol OF protocol


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


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


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


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)


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


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

20 20


Thank you! For any further info…

Nicola Ciulli Head of Research & Development

[email protected]

[email protected]

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