SDN For Optical Networks - ONDM 2019...ODU OH OCh Transport Unit (OTU) Client Service Mapping Switching and Multiplexing OTU Transmission OH Digital Adaptation Optical Channel (OCh)

SDN Control of Disaggregated Optical Networks with OpenConfig, OpenROADM

23rd Conference on Optical Networks Design and Modelling (ONDM2019)

Ramon Casellas [email protected]

May 13-16, 2019. Athens, Greece

1

mailto:[email protected]

Introduction: Telecom. Networks

▸To provision / deploy a network service (e.g., a data

connection),

- A path needs to be computed and resources pre-assigned.

- A set of network elements (nodes) need to be configured, so:

- State is created, rules are defined in order to forward traffic

or to cross-connect inputs to outputs

- Resources are effectively reserved where appropriate

2

Allowing users to communicate and transmit/receive data

Node-1

Node-2

Node-3

Node-4

Node-5 Node-6

.12

.56

.54

.45

.42

.23

.32

.21

.46

.64

.65

.36

.34

.63

.43

.15

.51

Main Requirement

▸Minimizing manual intervention.

▸ Automation across the whole network:

- Setting up connections and configuring the forwarding and switching behavior of the intermediate nodes….

- With increasing traffic dynamicity requiring frequent and complex re-arrangement

- In an environment of increasing complexity with multiple technological layers

- In networks spanning multiple segments and across administrative domains.

▸With the pressure to keep costs down, error free, with satisfactory robustness and fault tolerance.

▸ Operator friendly allowing workflows and abstractions using high level constructs, automating common tasks, while being efficient.

▸ Enable on-demand provisioning of services and user control.

3

Automate the Provisioning of Services

Optical Transport Networks

4

Basic Optical Transport Network ServiceClient Signal

Client Signal

MultiplexingClient Signals,Framing,…

OTN Wrapper

Optical Transmission (Optical Channel Signal)

Power

Frequency

Client

OCh Payload Unit (OPU)

Client

OCh Data Unit (ODU)

OPU OH

ODU OH

OCh Transport Unit (OTU)

Client Service Mapping

Switching and Multiplexing

TransmissionOTU OH

Digital

Adaptation

Optical Channel (OCh)

MU

X

DEM

UX

Optical Channel / Network Media Channel

Optical Multiplex Section(OMS)

Optical ChannelCarrier (OCC)

Optical Transmission Section (OTS)

Optical Transport Networks

5

Main elements and their configuration

Bandwidth Variable Wavelength Selective Switch1xN direct Signals to any output portMultiple frequency slots Routing and Switching

Power EqualizationMillisecond configuration times

Transceiver

Transceiver

TransceiverM

UX

DEM

UX

λ1

λ2

λn

ROADM

Add/DropPort

WSS

DEGREEor Direction

OA OA

Trn

TransceiverOutput Signal(freq, power, spectrum)Modulation Format,FEC,…

ROADMAdd/Drop/Express Operations, Media Channel Switching,…

Trn

WSS

WSS

Drop

Direction X

Direction Y

Centralized Control Plane

6

Forwarding Plane

MgmtPlane

Management Interface

Agent

Forwarding Plane

Agent

Forwarding Plane

MgmtPlane

Agent

MgmtPlane

Manager

ControllerControl Interface

▸ Single (logically centralized) controller, responsible for interacting with agents at

the nodes

Main traits

SDN Principles

▸ Centralized control architecture, enabling an application layer

▸ Separation of the control plane from the data plane,

- Note: neither the “data plane and control plane separation” nor the “centralized” aspect is

new in optical transport networks.

▸ Avoid complexity of distributed control planes

▸ Network devices to be programmed using a standard interface (e.g. OpenFlow) enabling

and leveraging programmability

7

Simplified architecture & protocols around a set of basic concepts

Is OpenFlow the right protocol?

▸ It is desirable to have a common and unified protocol,

- In practice need to interact with multiple elements using multiple protocols.

- Requires agreed hardware models and/or extensions mechanisms.

- Market adoption?

▸SBI ideal protocol : flexible, extensible, while remaining future-proof

allowing generic configuration for yet-to-be-invented devices.

- Decoupling the protocols to transport information between entities, from the

way the information is structured.

- Other relevant aspects: encodings, frameworks, their feature set and maturity,

- Actual device vendor support.

8

For the South Bound Interface (SBI)

Is OpenFlow the right protocol?

▸OpenFlow is one possibility (there are others, e.g. PCEP,…)

- Low level, byte oriented protocol

- Stable, deployed, mainly for packet switched networks,

- Complex to extend and its applicability to optical networks is not

straightforward.

• In packet switching, the P4 language is trying to overcome some of the limitations of OpenFlow, providing a high –level language.

▸In the optical domain,

- There seems to be little support for OpenFlow.

- Vendors are favoring other approaches based on e.g. Yang/NETCONF.

9

For the South Bound Interface (SBI)

Unified Information and Data Modeling

▸ An approach to design SDN Controlled Networks based on the systematic use of data models (for services, for control plane construct, for devices…), which can be automatically validated, used, and the SDN logic and applications can be developed around such models.

▸ In general, for a device (or system)

▸ Information Model

- Macroscopically describes the device capabilities, in terms of operations and configurable parameters, using high level abstractions without specific details on aspects such as a particular syntax or encoding.

▸ Data Model

- Determines the structure, syntax and semantics of the data that is externally visible

- (More concrete)

10

Model-driven development


▸ Unified information and data modeling language to describe a device capabilities, attributes, operations to be performed on a device or system and notifications

- A common language with associated tools

- Enabling complex models with complex semantics, flexible, supporting extensions and augmentations

- A “best-practice” and guidelines for model authors

▸ An architecture for remote configuration and control

- Client / Server, supporting multiple clients, access lists, transactional semantics, roll-back –Aligned with SDN.

▸ An associated transport protocol provides primitives to view and manipulate the data, providing a suitable encoding as defined by the data-model.

- Flexible, efficient, secure.

- Note that, Ideally, data models should be protocol independent

11

Requirements (1/2)


▸Standard, agreed upon models for devices

- Huge activity area

- Hard to reach consensus (controversial aspects)

- Often SDOs competing and overlapping

- Some models do exist. Most stable ones cover mature aspects (interface

configuration, RIB, BGP routing)

12

Requirements (2/2)

Yang Language: A simple example

13

A YANG model for a TV

Comparison with MIBs and

SMI?

Improved expressiveness

and flexibility.

Better means to reflect

intended semantics

module cttc-tv {namespace "http://www.cttc.es/ctv";prefix ctv;organization "CTTC";contact "[email protected]";description "TV Yang model";revision "2018-01-30" {

reference “0.1";}

typedef volume-type {type int32 {

range "0..100";}

}

container info {config false;leaf vendor {

type string;}leaf serial {

type string;}

}…

… container parameters {

config true;leaf input {

type enumeration {enum hdmi1;enum hdmi2;

}}leaf volume {

type volume-type;}leaf channel {

type uint32 {range "1..512";

}}

}

… rpc reboot {

input {leaf delay {

type uint16;}

}output {

leaf status {type empty;

}}

}

notification sleep {leaf delay {

type uint16;}

}

}

/ctv:parameters/ctv:volume = 50

The NETCONF protocol

▸ Offers primitives to view and manipulate data, providing a suitable encoding as defined by the data-model.

- Data is arranged into one or multiple configuration datastores (set of configuration information that is required to get a device from its initial default state into a desired operational state.)

▸ Enables remote access to a device, and provides the set of rules by which multiple clients may access and modify a datastore within a NETCONF server (e.g., device).

- NETCONF enabled devices include a NETCONF server,

- Management applications include a NETCONF client and device Command Line Interfaces (CLIs) can be a wrapped around a NETCONF client.

▸ It is based on the exchange of XML-encoded RPC messages over a secure (commonly Secure Shell, SSH) connection.

14

A Transport Protocol for Network Device Configuration

The NETCONF protocol

15

A Transport Protocol for Network Device Configuration

# pyang -f tree ondm-tv.yang

module: ondm-tv+--ro info| +--ro vendor? string| +--ro serial? string+--rw parameters

+--rw input? enumeration+--rw volume? volume-type+--rw channel? uint32

rpcs:+---x reboot

+---w input| +---w delay? uint16+--ro output

+--ro status? empty

notifications:+---n sleep

+--ro delay? uint16

serial

ondm-tv

info

vendor

parameters

input

volume

SERVER(device)Client (User)

get /info/serial

edit-config /parametersinput=hdmi1, volume=10

get-configfilter=/parameters/volume

<?xml version="1.0" encoding="UTF-8"?><rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<get><filter type="subtree">

<org-openroadm-device xmlns="http://org/openroadm/device"><info/>

</org-openroadm-device></filter>

</get></rpc>]]> ]]>

Netconf

16

Messages and Layers

XML Message framingRPC Layer

Operation Layer

Content Layer

End of Message (Netconf 1.0)

<?xml version="1.0" encoding="UTF-8"?><rpc-reply message-id="2"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<data><org-openroadm-device xmlns="http://org/openroadm/device">

<info><node-id>ROADM-PA-9</node-id><node-number>9</node-number><node-type>rdm</node-type><clli>ROADM-PA-9</clli><vendor>CTTC</vendor><model>RDM1</model><serial-id>CTTC_DEADBEEF_9</serial-id><softwareVersion>2.2.0</softwareVersion><openroadm-version>2.2</openroadm-version><template>none</template><geoLocation>

<latitude>39.927</latitude><longitude>-76.42</longitude>

</geoLocation><max-degrees>4</max-degrees><max-srgs>1</max-srgs>

RESTConf

▸RESTful protocol to access YANG defined data

- Representational State Transfer, i.e. server maintains no session state

- URIs reflect data hierarchy in a Netconf datastore

- HTTP as transport, JSON encoding

- Allows XML or JSON as encoding

- “lightweight” approach – reuse HTTP, JSON ,….

17

An Alternative To Netconf

RESTConf

18

JSON Example (cfr. RFC8259)

{

"Image": {

"Width": 800,

"Height": 600,

"Title": "View from 15th Floor",

"Thumbnail": {

"Url": "http://www.example.com/image/481989943",

"Height": 125,

"Width": 100

},

"Animated" : false,

"IDs": [116, 943, 234, 38793]

}

}

GET /restconf/data/ctv:parameters

Server returns{

"input" : "hdmi1","volume" : 60,"channel" : 5

}

POST /restconf/operations/ctv:reboot HTTP/1.1 Host: mytv.com Content-Type: application/yang-data+json

{ "ctv:input" : {

"delay" : 2 }

}

Disaggregated Optical Networks

19

Use case for Model Driven Development

▸Traditional optical transport networks

- Single vendor managed domain.

- May export high-level interfaces and open NBI, opaque internal details.

- Highly coupled and integrated

▸Disaggregation

- Composing and assembling open, available components, devices and sub-

systems.

- Around the concept of “whitebox”

- Partial or Full (down to each of the optical components)


20


▸ Opportunities:

- New degree of flexibility, allowing component migration and upgrades without vendor

lock-in.

▸ Challenges:

- Disaggregated optical nodes may not have the same level of integration and performance

that integrated systems.

- Control and management : use case for open interfaces exporting programmability.

• OpenROADM http://openroadm.org

multi-source agreement covers pluggable optics, transponders and ROADMs.

• OpenConfig, http://openconfig.net/

a collaborative effort by network operators, has published a set of models providing a configuration and state model for terminal optical devices within a DWDM system, including both client- and line-side parameters


21


Degree

DegreeDegr

ee

#1 #2

Add/DropGroup

Add/DropGroup

Degree

DegreeDegr

ee

#1 #2

Add/DropGroup

Add/DropGroup

SDN Controller

APP

Data Plane

SDN Agent

SBI: South Bound Interface (Netconf / YANG)

Device Manager

NBI: North Bound Interface (e.g REST)

Vendor Driver

Yang models

Yang models


22


Degree

DegreeDegr

ee

#1 #2

Add/DropGroup

Add/DropGroup

Degree

DegreeDegr

ee

#1 #2

Add/DropGroup

Add/DropGroup

SDN Controller

APP

Data Plane

SDN Agent

SBI: South Bound Interface (Netconf / YANG)

Device Manager

NBI: North Bound Interface (e.g REST)

Vendor Driver

Yang models

module transceiver {container transceiver {

leaf FEC {type enum;

}leaf frequency {

type float;}

}}

Yang models

ODTN

▸ODTN (Open and Disaggregated Transport Networks) is an ONF project that aims to rally service providers, hardware vendors and system integrators, to

- Build a reference implementation using (a) open source software, (b) open and common data models, and (c) disaggregated hardware devices.

- Perform lab and field trials using the reference implementation.

- Identify supply chain gaps and propose solutions.

▸The project's scope covers:

- Disaggregated DWDM systems, including but not limited to transponders and Open Line Systems, amplifiers, multiplexers, all-optical switches and ROADMs

- Open source network operating system for control and configuration of the DWDM system

- Open and common data models, APIs and protocols

23

Introduction

ODTN

24

Project Phases

OLS Controller

WSS TRN

Open Line System (OLS)

OpenConfig

MUX WSSAMP MUXTRN

ONOS

Phase 1.5 : with OLS Controller

TAPI 2.X

TAPI 2.X

TRN ROADM ROADM

ROADM ROADMTRN

TRN

TRN

APIAPI

API

API

Phase 2.0 : with OpenROADM devices

Figures reproduced from ODTN project see https://wiki.onosproject.org/display/ODTN/ODTN

Transport API (T-API)

▸SDN Controllers offer proprietary Interfaces to applications (or Network

Orchestrators). Common approach based on “vendor domains”

▸Heterogeneity

- Different controllers interfaces

- Not even using the same protocol

- Forces the use of “plugins” and it’s hard to extend

- (this has been the case of multiple umbrella management systems)

▸There is a need for a standard interface, with common models

25

Problem Statement

Transport API (T-API)

26

Main use Case

Layer 2 / Layer 3 Switching

Optical Domain

Applications

Controller Controller

Network Orchestrator

ControlDomain

SDN Network Control Plane

Controller

TAPI Interface

End-to-endRequest (TAPI

Interface)

T-API Common

27

Simplified Yang Modelmodule tapi-common {

namespace "urn:onf:otcc:yang:tapi-common";prefix tapi-common;organization "ONF OTCC ";

container context {uses tapi-context;presence "Root container for all TAPI interaction";

}grouping tapi-context {

list service-interface-point {key 'uuid';uses service-interface-point;

}}grouping service-interface-point {

leaf layer-protocol-name {type layer-protocol-name

}leaf-list supported-layer-protocol-qualifier {

type layer-protocol-qualifier;config false;min-elements 1;

}

module: tapi-common+--rw context!

+--rw service-interface-point* [uuid]| +--ro layer-protocol-name? | +--ro supported-layer-protocol-qualifier*| +--rw uuid| +--rw name* [value-name]+--rw uuid? +--rw name* [value-name]

+--rw value-name string+--rw value? string

{"uuid": "9ef93cb9-453f-42ae-8ac9-294df75a1770",“name": [

{“value-name": "name","value": "Sample Context"

}],

"service-interface-point": [{

"uuid": "6c5e2598-342f-40be-8a27-90e2b2c0f070","name": [

{"value-name": "name","value": “SIP1"

}],

"layer-protocol-name": [ "DSR"

]},…

]}

T-API Recursive Topologies

28

Node Edge Point (Network Internal)

Node Edge Point (Network Edge)

Service Interface Point

Node

Node

Node

Node

Node

Node

NodeNode

Node Node

T-API Topology

29

Simplified Yang Model

module tapi-topology {namespace

"urn:onf:otcc:yang:tapi-topology";prefix tapi-topology;import tapi-common {

prefix tapi-common;}

augment "/tapi-common:context" {uses topology-context;

}

grouping topology-context {container nw-topology-service {

...}list topology {

key 'uuid';uses topology;

}}

grouping topology {list node {

key 'uuid';config false;uses node;

}list link {

key 'uuid';config false;uses link;

}}

grouping link {list node-edge-point {

uses node-edge-point-ref;}leaf direction {

type tapi-common:forwng-direction;}

}

grouping node {list owned-node-edge-point {

key 'uuid';config false;uses node-edge-point;

}}

...}

T-API Topology

30

Retrieving the T-API Topology within the context{

"uuid": , "name":

"service-interface-point":

...

"topology": [

{

"uuid": "uuid-sample-topology",

"name": [

{

"value-name": "name",

"value": "Sample Network"

}

],

"node": [

{

"uuid": "uuid-node-1",

"name":...

"layer-protocol-name":

"owned-node-edge-point":

[

...

]...

},

{

"uuid": "uuid-node-2",

"name":...

"layer-protocol-name":

"link" : [

{

"uuid": "uuid-link-node-1-to-node-2",

"name": ...

"total-potential-capacity":

"available-capacity":

"cost-characteristic":

"latency-characteristic":

"node-edge-point":

[ ...

]

},

...

]

}

]

}

T-API Connectivity Services

31

Requesting Connectivity between endpoints

Node Edge Point (Network Internal)

Node Edge Point (Network Edge)


A Connectivity Service can be requested between ServiceInterfacePoints (SIPs)Top-level Connection is recursively decomposed into lower-level Connections, per Node

T-API Connectivity Services

32

Node Edge Point (Internal)

Node Edge Point (Edge)


Connection EndPoint

Connectivity Service EndPoint

T-API Connectivity

33

RESTConf RPC

rpcs:+---x create-connectivity-service| +---w input| | +---w end-point* [local-id]| | | +---w layer-protocol-name? | | | +---w layer-protocol-qualifier? | | | +---w service-interface-point| | | | +---w service-interface-point-uuid?

Creating a Service

▸ The user requests a connection using the NBI (cfr. TAPI)

▸ The SDN Controller performs a routing and spectrum assignment process that finds

the k-shortest path between the devices and performs first fit spectrum allocation.

▸ Once completed, flow / forwarding rules are configured at each device:

- For the Terminal Device, a logical channel association is instantiated within the device

between a client (transceiver) port and an optical channel component bound to the line

port of the device.

- For each of the OpenROADM devices across the path, a ROADM internal connection is

requested:

• OTS and OMS (optical transport and optical multiplex) interfaces are created within each degree (if not existing)

• Supporting Media Channel and NMC interfaces are created,

• Followed by the creation of a roadm-connection object.

34

SDN Connectivity Provisioning

OpenROADM model

35

Simplified Data model

SRG1-AMP-TX

SRG1-AMP-RX

SRG1-CS

SRG1-CS-IN1 SRG1-CS-OUT1

SRG1-WSS

DEG1DEG1

DEG1-AMP-RX

DEG1-AMP-TX

DEG1-WSS

SRG2-AMP-TX

SRG2-AMP-RX

SRG2-CS

SRG2-CS-IN1 SRG2-CS-OUT1

SRG2-WSS

DEG2

DEG3ExpLink12ExpLink13

Dlink11Dlink12

ExpLink21

ExpLink31ALink11ALink21

OpenROADM Device

OpenROADM Device Model (Simpl.)

36

Device Informationmodule: org-openroadm-device

+--rw org-openroadm-device+--rw info| +--rw node-id? org-openroadm-common-node-types:node-id-type| +--rw node-number? uint32| +--rw node-type org-openroadm-device-types:node-types| +--rw clli? string| +--ro vendor string| +--ro model string| +--ro serial-id string| +--rw ipAddress? ietf-inet-types:ip-address| +--rw prefix-length? uint8| +--rw defaultGateway? ietf-inet-types:ip-address| +--ro macAddress? ietf-yang-types:mac-address| +--ro softwareVersion? string| +--ro openroadm-version? org-openroadm-common-types:openroadm-version-type| +--rw template? string| +--ro current-datetime? ietf-yang-types:date-and-time| +--rw geoLocation| | +--rw latitude? decimal64| | +--rw longitude? decimal64| +--ro max-degrees? uint16| +--ro max-srgs? uint16


37

Circuit Packs (field replaceable unit in electronic switching equipment)

module: org-openroadm-device+--rw org-openroadm-device

+--rw circuit-packs* [circuit-pack-name]| +--rw circuit-pack-type string| +--rw shelf -> /org-openroadm-device/shelves/shelf-name| +--rw slot string

+--rw ports* [port-name]| +--rw port-name string| +--rw port-type? string| +--rw port-qual? org-openroadm-device-types:port-qual| +--ro port-wavelength-type? org-openroadm-port-types:port-wavelength-types| +--ro port-direction org-openroadm-common-alarm-pm-types:direction| +--ro label? string| +--rw circuit-id? string| +--rw logical-connection-point? string| +--ro partner-port| | +--ro circuit-pack-name?| | +--ro port-name? +--ro interfaces*| | +--ro interface-name? -> /org-openroadm-device/interface/name|


38

Internal, Physical and External Linksmodule: org-openroadm-device

+--rw org-openroadm-device+--ro internal-link* [internal-link-name]| +--ro internal-link-name string| +--ro source| | +--ro circuit-pack-name| | +--ro port-name| +--ro destination| +--ro circuit-pack-name| +--ro port-name

+--rw physical-link* [physical-link-name]| +--rw physical-link-name string| +--ro source| | +--ro circuit-pack-name| | +--ro port-name| +--ro destination| +--ro circuit-pack-name| +--ro port-name

+--rw external-link* [external-link-name]| +--rw external-link-name| +--rw source| | +--rw node-id| | +--rw circuit-pack-name| | +--rw port-name| +--rw destination| +--rw node-id| +--rw circuit-pack-name| +--rw port-name


39

Interfacesmodule: org-openroadm-device

+--rw org-openroadm-device+--rw interface* [name]| +--rw name string| +--rw description? string| +--rw type identityref| +--rw circuit-id? string| +--rw supporting-interface? -> /org-openroadm-device/interface/name| +--rw supporting-circuit-pack-name? -> /org-openroadm-device/circuit-packs/circuit-pack-name| +--rw supporting-port?


40

Degrees and Shared Risk Groups (Add / Drop Stages)module: org-openroadm-device

+--rw org-openroadm-device+--rw degree* [degree-number]| +--rw degree-number uint16| +--ro max-wavelengths uint16| +--rw circuit-packs* [index]| +--ro mc-capabilities| +--ro slot-width-granularity? org-openroadm-common-optical-channel-types:frequency-GHz| +--ro center-freq-granularity? org-openroadm-common-optical-channel-types:frequency-GHz| +--ro min-slots? uint32| +--ro max-slots? Uint32

+--rw shared-risk-group* [srg-number]| +--ro max-add-drop-ports uint16| +--ro current-provisioned-add-drop-ports uint16| +--rw srg-number uint16| +--rw circuit-packs* [index]| +--ro mc-capabilities| +--ro slot-width-granularity? org-openroadm-common-optical-channel-types:frequency-GHz| +--ro center-freq-granularity? org-openroadm-common-optical-channel-types:frequency-GHz| +--ro min-slots? uint32| +--ro max-slots? uint32


41

ROADM Connectionsmodule: org-openroadm-device

+--rw org-openroadm-device+--rw roadm-connections* [connection-name]| +--rw connection-name string| +--rw source| | +--rw src-if -> /org-openroadm-device/interface/name| +--rw destination| +--rw dst-if -> /org-openroadm-device/interface/name

Netconf Hello

42

Initial Netconf Capability Discovery

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities>

<capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:base:1.1</capability>

</capabilities></hello>

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities>

<capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:candidate:1.0</capability><capability>urn:ietf:params:netconf:capability:notification:1.0</capability><capability>http://org/openroadm/alarm?module=org-openroadm-alarm&revision=2017-12-15</capability><capability>http://org/openroadm/common-types?module=org-openroadm-common-types…</capability><capability>http://org/openroadm/device?module=org-openroadm-device&revision=2017-12-15</capability><capability>http://org/openroadm/media-channel-interfaces? …</capability><capability>http://org/openroadm/network-media-channel-interfaces?<capability>http://org/openroadm/optical-channel-interfaces?<capability>http://org/openroadm/optical-transport-interfaces?

</capabilities><session-id>36</session-id>

</hello>

Initial Device Discovery

43

Get Operation on /org-openroadm-device:org-openroadm-device/info

<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get>

<filter type="subtree"><org-openroadm-device xmlns="http://org/openroadm/device"><info/>


</get></rpc>

<rpc-reply message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><data>

<org-openroadm-device xmlns="http://org/openroadm/device"><info><node-id>ROADM-PA-9</node-id><node-number>9</node-number><node-type>rdm</node-type><clli>ROADM-PA-9</clli><vendor>CTTC</vendor><model>RDM1</model><serial-id>CTTC_DEADBEEF_9</serial-id><softwareVersion>2.2.0</softwareVersion><openroadm-version>2.2</openroadm-version><template>none</template><geoLocation>

<latitude>39.927</latitude><longitude>-76.42</longitude>

</geoLocation><max-degrees>4</max-degrees><max-srgs>1</max-srgs>

Getting the device composition

44

Get Operation on /org-openroadm-device/circuit-packs


<filter type="subtree"><org-openroadm-device xmlns="http://org/openroadm/device"><circuit-packs/>


</get></rpc>


<org-openroadm-device xmlns="http://org/openroadm/device"><circuit-packs><circuit-pack-name>DEG1-AMPRX</circuit-pack-name><circuit-pack-type>AMP</circuit-pack-type><administrative-state>inService</administrative-state><circuit-pack-category>

<type>circuitPack</type></circuit-pack-category><shelf>SHELF_DEG1</shelf><slot>SHELF_DEG1_SLOT_DEG1-AMPRX</slot><ports>

<port-name>DEG1-AMPRX-IN</port-name><port-qual>roadm-external</port-qual><port-wavelength-type>multi-wavelength</port-wavelength-type><port-direction>rx</port-direction><label>11</label><logical-connection-point>DEG1-TTP-RX</logical-connection-point><partner-port>

<circuit-pack-name>DEG1-AMPTX</circuit-pack-name><port-name>DEG1-AMPTX-OUT</port-name>

</partner-port><roadm-port>...

Device Discovery

▸At this point, the controller has information about the OpenROADM

- Device Information

- Circuit Packs (AMPs, WSS, C&S, …)

- Device Ports

• Including external and internal ports, and logical connection points

▸It can also retrieve the status of existing connections:

45

SDN Controller retrieving device structure


<filter type="subtree"><org-openroadm-device xmlns="http://org/openroadm/device"><roadm-connections/>


</get></rpc> <rpc-reply message-id="4"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><data/>

</rpc-reply>

Discovering the Network Topology

46

Get Operation on /org-openroadm-device/external-links

<rpc message-id=“5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get>

<filter type="subtree">...


<org-openroadm-device xmlns="http://org/openroadm/device"><external-link><external-link-name>EXT-ROADM-PA-9-DEG1-ROADM-IL-8-DEG3</external-link-name><source>

<node-id>ROADM-PA-9</node-id><circuit-pack-name>DEG1-AMPTX</circuit-pack-name><port-name>DEG1-AMPTX-OUT</port-name>

</source><destination>

<node-id>ROADM-IL-8</node-id><circuit-pack-name>DEG3-AMPRX</circuit-pack-name><port-name>DEG3-AMPRX-IN</port-name>

</destination></external-link><external-link><external-link-name>EXT-ROADM-PA-9-DEG2-ROADM-GA-10-DEG2</external-link-name><source>

<node-id>ROADM-PA-9</node-id><circuit-pack-name>DEG2-AMPTX</circuit-pack-name><port-name>DEG2-AMPTX-OUT</port-name>

...

OpenROADM Network

47

ROADM Express Connection

48

A Network Media Channel From Degree 1 to Degree 4

DEG1DEG1

DEG1-AMP-RX

DEG1-AMP-TX

DEG1-WSS

DEG4

ExpLink14

ExpLink41

Optical Transport Interface – TTPOTS-DEG4-TTP-TX

Optical MultiplexInterface – TTPOMS-DEG4-TTP-TX

Optical Transport Interface – TTPOTS-DEG1-TTP-RX

Optical MultiplexInterface – TTPOMS-DEG1-TTP-RX

Assume OTS and OMS are pre-configured


49


DEG1DEG1

DEG1-AMP-RX

DEG1-AMP-TX

DEG1-WSS

DEG4

ExpLink14

ExpLink41

MC-TTP-DEG1-TTP-RX-190.7mediaChannelTrailTerminationPointsupporting-interface: OMS-DEG1-TTP-RXmin-freq: 190.675max-freq: 190.725

MC-TTP-DEG4-TTP-TX-190.7mediaChannelTrailTerminationPointsupporting-interface: OMS-DEG4-TTP-TXmin-freq: 190.675max-freq: 190.725

Creation of MC Interfaces

50

Edit-config Operation on /org-openroadm-device/interface

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="58"><edit-config>

<target><running/>

</target><config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">

<org-openroadm-device xmlns="http://org/openroadm/device"><interface nc:operation="merge">

<name>MC-TTP-DEG1-TTP-RX-190.7</name><description>Media-Channel</description><type xmlns:openROADM-if="http://org/openroadm/interfaces">

openROADM-if:mediaChannelTrailTerminationPoint</type><administrative-state>inService</administrative-state><supporting-circuit-pack-name>DEG1-AMPRX</supporting-circuit-pack-name><supporting-port>DEG1-AMPRX-IN</supporting-port><supporting-interface>OMS-DEG1-TTP-RX</supporting-interface><mc-ttp xmlns="http://org/openroadm/media-channel-interfaces">

<min-freq>190.675</min-freq><max-freq>190.725</max-freq>

</mc-ttp></interface>

</org-openroadm-device></config>

</edit-config></rpc>

50 GHz


51


DEG1DEG1

DEG1-AMP-RX

DEG1-AMP-TX

DEG1-WSS

DEG4

ExpLink14

ExpLink41

NMC-CTP-DEG1-TTP-RX-190.7networkMediaChannelConnectionTerminationPointFrequency: 190.7Width: 50.0

NMC-CTP-DEG4-TTP-TX-190.7networkMediaChannelConnectionTerminationPointFrequency: 190.7Width: 50.0

Creation of NMC Interfaces

52

Edit-config Operation on /org-openroadm-device/interface


<target><running/>


<org-openroadm-device xmlns="http://org/openroadm/device"><interface nc:operation="merge">

<name>NMC-CTP-DEG1-TTP-RX-190.7</name><description>Network-Media-Channel</description><type xmlns:openROADM-if="http://org/openroadm/interfaces">

openROADM-if:networkMediaChannelConnectionTerminationPoint</type><administrative-state>inService</administrative-state><supporting-circuit-pack-name>DEG1-AMPRX</supporting-circuit-pack-name><supporting-port>DEG1-AMPRX-IN</supporting-port><supporting-interface>MC-TTP-DEG1-TTP-RX-190.7</supporting-interface><nmc-ctp xmlns="http://org/openroadm/network-media-channel-interfaces">

<frequency>190.7</frequency><width>50.0</width>

</nmc-ctp></interface>

</org-openroadm-device></config>

</edit-config></rpc>

Frequency Slot


53


DEG1DEG1

DEG1-AMP-RX

DEG1-AMP-TX

DEG1-WSS

DEG4

ExpLink14

ExpLink41

Creation of a roadm-connection - Between Connection Termination Points- Unidirectional RX TX- From: NMC-CTP-DEG1-TTP-RX-190.7- To: NMC-CTP-DEG4-TTP-TX-190.7

NMC-CTP-DEG1-TTP-RX-190.7networkMediaChannelConnectionTerminationPointFrequency: 190.7Width: 50.0

Creation of ROADM Connection

54

Edit-config Operation on /org-openroadm-device/roadm-connections


<target><running/>


<org-openroadm-device xmlns="http://org/openroadm/device"><roadm-connections nc:operation="merge">

<connection-name>NMC-CTP-DEG1-TTP-RX-190.7-to-NMC-CTP-DEG4-TTP-TX-190.7</connection-name><opticalControlMode>off</opticalControlMode><target-output-power>0</target-output-power><source>

<src-if>NMC-CTP-DEG1-TTP-RX-190.7</src-if></source><destination>

<dst-if>NMC-CTP-DEG4-TTP-TX-190.7</dst-if></destination>

</roadm-connections></org-openroadm-device>

</config></edit-config>

</rpc>

Conclusions

▸Introduction to model driven development as the adopted framework

for SDN for transport networks

- Leverage on increasing device programmability.

▸Clear use case: Disaggregated Optical networks

- Example of TAPI and OpenROADM models.

▸Need for common, agreed upon models

55

Thank you Questions?

56

Documents

SDN For Optical Networks - ONDM 2019...ODU OH OCh Transport Unit (OTU) Client Service Mapping Switching and Multiplexing OTU Transmission OH Digital Adaptation Optical Channel (OCh)