sdn for optical networks - ondm 2019...odu oh och transport unit (otu) client service mapping...
TRANSCRIPT
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
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
▸ 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)
Unified Information and Data Modeling
▸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)
Disaggregated Optical Networks
20
Use case for Model Driven Development
▸ 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
Disaggregated Optical Networks
21
Use case for Model Driven Development
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
Disaggregated Optical Networks
22
Use case for Model Driven Development
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)
Service Interface Point
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)
Service Interface Point
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
OpenROADM Device Model (Simpl.)
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|
OpenROADM Device Model (Simpl.)
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
OpenROADM Device Model (Simpl.)
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?
OpenROADM Device Model (Simpl.)
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
OpenROADM Device Model (Simpl.)
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/>
</org-openroadm-device></filter>
</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
<rpc message-id="3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get>
<filter type="subtree"><org-openroadm-device xmlns="http://org/openroadm/device"><circuit-packs/>
</org-openroadm-device></filter>
</get></rpc>
<rpc-reply message-id="3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><data>
<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
<rpc message-id="4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get>
<filter type="subtree"><org-openroadm-device xmlns="http://org/openroadm/device"><roadm-connections/>
</org-openroadm-device></filter>
</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">...
<rpc-reply message-id="5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><data>
<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
ROADM Express Connection
49
A Network Media Channel From Degree 1 to Degree 4
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
ROADM Express Connection
51
A Network Media Channel From Degree 1 to Degree 4
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
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="60"><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>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
ROADM Express Connection
53
A Network Media Channel From Degree 1 to Degree 4
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
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="62"><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"><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