ODTN TAPI Open Config Models for Phase 1

ODTN TAPI & Open. Config Models for Phase 1. 0 1

To be determined by Use Case Team Orchestrator (0. TAPI Model Selection) 1. TAPI NBI Selection 2. TAPI Parameter Mapping (Connectivity. Service/SEP -> Connection/CEP) 3. TAPI Parameter Selection (Connection/CEP) mapped to SB 4. Parameter Mapping from TAPI (Connection/CEP) to Open. Config (different for each vendor) 5. Open. Config SB Model Selection (different for each vendor) NBI(RESTCONF) 1 common 2 3 4 different for each vendor 5 Connnectivity. Service/SEP ↓ Connection/CEP ↓ ↓↓ Open. Config/CEP Open. Config NETCONF Transponder 2

TAPI Models for Phase 1. 0 Topology: 2 Transponders with N tributary ports Need to be pre-configured • 1 Link • 2 Nodes • 1 Node. Edge. Point(Internal), N Node. Edge. Point(Edge), N Service. Interface. Point for each Node • Node. Edge. Point (Edge) Node. Edge. Point (Internal) sip 11 nep 22 nep 12 DSR Service. Interface. Point sip 21 Service. End. Point Connection. End. Point nep 11 DSR Topology OTSi nep 21 DSR OTSi link 1 Node DSR Mapping TRPD 1 Link TRPD 2 DSR Transitional Link DSR Tributary Connection node 1 node 2 3

TAPI Models for Phase 1. 0 Request to create Connectivity. Service from NBI Select 2 Service. Interface. Points as Service. End. Point Create 1 Connectivity. Service with Service. End. Point • • Connectivity Service consrv 1 Node. Edge. Point (Edge) nep 22 nep 12 Node. Edge. Point (Internal) sip 11 Service. Interface. Point DSR Service. End. Point Connection. End. Point nep 21 nep 11 DSR Topology OTSi DSR OTSi link 1 Node DSR Mapping TRPD 1 Link TRPD 2 DSR Transitional Link DSR Tributary Connection node 1 node 2 4 sip 21

TAPI Models for Phase 1. 0 Create connection included in Connectivity. Service • Create lower-connections first • • Create the lowest layer (OTSi) Connection+CEPs, and the corresponding client layer (DSR)Link+NEPs Create the DSR (cross)Connection+CEPs Create the E 2 E DSR connection • Connectivity Service consrv 1 Node. Edge. Point (Edge) cep 111 ec 11 1 DSR Connection. End. Point link 2 (DSR) DSR 12 nn Service. End. Point cep 221 connec 211 (DSR/CBR) co cep 211 ec 1 nep 12 DSR connec 212 (OTSi/Lambda) DSR Topology OTSi nep 11 link 1 (OTSi) nep 22 nn Service. Interface. Point sip 11 co Node. Edge. Point (Internal) cep 121 nep 21 DSR OTSi Node DSR Mapping TRPD 1 Link TRPD 2 DSR Transitional Link DSR Tributary Connection node 1 5 node 2 sip 21

TAPI Models for Phase 1. 0 Request to create another Connectivity. Service Create SEP, Connections, CEPs, Link NEPs in the same way • Connectivity Service consrv 1 Node. Edge. Point (Edge) Node. Edge. Point (Internal) Service. Interface. Point connec 1 (DSR) sip 11 DSR Service. End. Point Connection. End. Point DSR Topology DSR OTSi Node DSR OTSi DSR Mapping TRPD 1 Link DSR Transitional Link connec 2 (DSR) TRPD 2 DSR consrv 2 Tributary Connection node 1 6 node 2 sip 21

Attributes Example Topology: 2 Transponders with N client ports • Need to be pre-configured • 1 Link • 2 Nodes • 1 Node. Edge. Point(Internal), N Node. Edge. Point(Edge) nep 22 nep 12 TRPD 1 TRPD 2 nep 11 nep 21 link 1 Tributary node 1 node 2 7 "tapi-common: context": { "tapi-topology: topology" : [ { "uuid": "0000 -0000 -0001 -1000000", "node": [ Node { "uuid": "0000 -0000 -1000 -0001 -1000000", "owned-node-edge-point": [ NEP { "uuid": "0000 -0000 -1100 -0001 -1100000", "layer-protocol-name": "OTSi. A", "mapped-service-interface-point": ["0000 -0000 -42000001 -1100000"], "name": [ { "value-name": "nep 11" } ] }, . . . ], Next Page "layer-protocol-name": ["OTSi. A"], "name": [ { "value-name": "node 1" } ], }, . . . ], Link "link": [ { "uuid": "0000 -0000 -2000 -0001 -0000001", "node-edge-point": ["0000 -0000 -1100 -0001 -1100000", "0000 -0000 -1100 -0001 -2100000"], "layer-protocol-name": ["OTSi. A"], "name": [ { "value-name": "link 1" } ], "layer-protocol-name": ["OTSi. A"], "name": [ { "value-name": "p 2 p" }

Attributes Example Topology: 2 Transponders with N client ports • sip 11 Need to be pre-configured • N Service. Interface. Point nep 22 nep 12 TRPD 1 sip 21 TRPD 2 nep 11 nep 21 link 1 Tributary node 1 node 2 8 "tapi-common: context": { "service-interface-point": [ { "uuid": "0000 -0000 -4200 -0001 -1100000", "layer-protocol-name": ["OTSi. A"], "name": [ { "value-name": "sip 11" } ], "available-capacity": { "total-size": { "value": 10, "unit": "GBPS" } } }, { "uuid": "0000 -0000 -4200 -0001 -2100000", "layer-protocol-name": ["OTSi. A"], "name": [ { "value-name": "sip 21" } ], "available-capacity": { "total-size": { "value": 10, "unit": "GBPS" } } }, . . . ], SIP

Attributes Example Request to create Connectivity. Service from NBI • • Select 2 Service. Interface. Points as Service. End. Point Create 1 Connectivity. Service with 2 Service. End. Points Connectivity Service consrv 1 sep 11 TRPD 1 sep 21 TRPD 2 9 "tapi-connectivity: connectivity-service" : [ { "uuid": "0000 -0000 -4000 -0001 -1000000", "end-point": [ Previous Page SEP { "local-id": "0000 -0000 -4100 -0001 -1100000", "layer-protocol-name": "OTSi. A", "service-interface-point": "0000 -0000 -4200 -00011100000", "capacity": { "available-capacity": {. . . }, "bandwidth-profile": {. . . } } }, "name": [ { "value-name": "sep 11" } ] }, . . . ], "connection": ["0000 -0000 -3000 -0001 -21100000"], "direction": "BIDIRECTIONAL", "name": [ { Next Page "value-name": "consrv 1" } ],

Attributes Example Create connection included in Connectivity. Service • • Select 2 Node. Edge. Point(Edge) Create 1 Connection and 2 Connection. End. Points Connectivity Service consrv 1 sep 11 sep 21 Connection TRPD cep 121 1 connec 211 TRPD 2 cep 221 10 "tapi-connectivity: connection" : [ Connection { "uuid": "0000 -0000 -3000 -0001 -21100000", "connection-end-point": ["0000 -0000 -1200 -000112100000", "0000 -0000 -1200 -0001 -22100000"], "direction": "BIDIRECTIONAL", "layer-protocol-name": "OTSi. A", "name": [ { "value-name": "connec 211" } ], . . . "tapi-topology: topology" : [ { "node": [ { "uuid": "0000 -0000 -1000 -0001 -1000000", "owned-node-edge-point" : [ { "uuid": "0000 -0000 -1100 -0001 -1100000", "tapi-connectivity: connection-end-point": [ CEP { "uuid": "0000 -0000 -1200 -0001 -11100000", "layer-protocol-name": "OTSi. A", "parent-node-edge-point": ["0000 -0000 -1100 -0001 Needed? -1100000"], Prev. "client-node-edge-point": [], How to use? Page "connectivity-service-end-point": ["0000 -00004100 -0001 -1100000"], "connection-port-direction": "BIDIRECTIONAL", "connection-port-role": "TRUNK", "name": [ { "value-name": "cep 111" } ] }, . . . ], . . .

Attributes Example Create lower-connection • • Select Node. Edge. Point(Internal) Create 1 Connection and 1 Connection. End. Point Connectivity Service consrv 1 sep 11 sep 21 Connection TRPD cep 121 1 connec 111 connec 211 TRPD 2 cep 221 Connection(lower) cep 111 connec 112 cep 211 11 "tapi-connectivity: connection": [ { "uuid": "0000 -0000 -3000 -0001 -21100000", "connection-end-point": ["0000 -0000 -1200 -000112100000", "0000 -0000 -1200 -0001 -22100000"], "lower-connection": ["0000 -0000 -3000 -0001 -11100000", "0000 -0000 -3000 -0001 -11200000"], "direction": "BIDIRECTIONAL", "layer-protocol-name": "OTSi. A", "name": [ { "value-name": "connec 211" } ] }, Lower-connections { "uuid": "0000 -0000 -3000 -0001 -11100000", "connection-end-point": [ "0000 -0000 -1200 -000111100000", "0000 -0000 -1200 -0001 -12100000"], "direction": "BIDIRECTIONAL", "layer-protocol-name": "OTSi. A", Add topology/node/ "name": [ owned. NEP/CEP { "value-name": "connec 111" } ] }, { "uuid": "0000 -0000 -3000 -0001 -11200000", "connection-end-point": [ "0000 -0000 -1200 -000121100000", "0000 -0000 -1200 -0001 -22100000"], "direction": "BIDIRECTIONAL", "layer-protocol-name": "OTSi. A", "name": [ Add topology/node/ { owned. NEP/CEP "value-name": "connec 112" } ],

Point 1. NBI Selection • For phase 1, what parameters are needed for NBI? • We definitely need to take care of client port(SIP) and direction • Restoration, PCE and some metrics(cost, latency, Qo. S) might be used after Phase 2 • Q 1. How about client port bandwidth? It might be needed if we use transponder which can change client port bandwidth Orchestrator 1 SIP(Client port) Direction(Uni or Bi) Bandwidth? Connectivity. Service (Request from Client) Topology Available capacity? Node/NEP/SIP/Link Connnectivity. Service/SEP 2 Connection/CEP 3 Node/NEP/SIP/Link (Request from Provider) 12

Point 3. TAPI Parameter Selection mapped to SB • We should use OTSi(ITU-T G. 872) as abstraction layer of optical channel • OTSi is characterized by center frequency and application identifier • CEP has port direction and OTSi parameters • Connection has no parameter which should be used for Phase 1 Orchestrator 1 SIP(Client port) Direction(Uni or Bi) Bandwidth? Connectivity. Service (Request from Client) Topology Available capacity? Node/NEP/SIP/Link (Request from Provider) Node/NEP/SIP/Link Connnectivity. Service/SEP 2 CEP connection-port-direction selected-nominal-center-frequency ( fixed val if needed ) selected-frequency-slot ( fixed val if needed ) selected-application-identifier Connection/CEP 3 13

OTSi parameters of TAPI • OTSi parameters are represented by NEP and CEP • Available/Occupied frequency for MUX feature are represented by NEP, but not needed for Phase 1. 0 tapi-otsi. tree (for NEP) tapi-otsi. tree (for CEP) augment /tapi-common: context/tapi-topology: topology/tapitopology: node/tapi-topology: owned-node-edge-point: +--ro available-frequency-slot * | +--ro nominal-central-frequency | | +--ro grid-type? grid-type | | +--ro adjustment-granularity? adjustment-granularity | | +--ro channel-number? uint 64 | +--ro slot-width-number? uint 64 +--ro occupied-frequency-slot * +--ro nominal-central-frequency | +--ro grid-type? grid-type | +--ro adjustment-granularity? adjustment-granularity | +--ro channel-number? uint 64 +--ro slot-width-number? uint 64 augment /tapi-common: context/tapi-topology: topology/tapitopology: node/tapi-topology: owned-node-edge-point/tapiconnectivity: connection-end-point: +--ro selected-nominal-central-frequency * | +--ro grid-type? grid-type | +--ro adjustment-granularity? adjustment-granularity | +--ro channel-number? uint 64 +--ro supportable-lower-nominal-central-frequency * | +--ro grid-type? grid-type | +--ro adjustment-granularity? adjustment-granularity | +--ro channel-number? uint 64 +--ro supportable-upper-nominal-central-frequency * | +--ro grid-type? grid-type | +--ro adjustment-granularity? adjustment-granularity | +--ro channel-number? uint 64 +--ro selected-application-identifier * | +--ro application-identifier-type? application-identifiertype | +--ro application-identifier-value? string +--ro supportable-application-identifier * | +--ro application-identifier-type? application-identifiertype | +--ro application-identifier-value? string +--ro selected-frequency-slot * +--ro nominal-central-frequency | +--ro grid-type? grid-type | +--ro adjustment-granularity? adjustment-granularity | +--ro channel-number? uint 64 +--ro slot-width-number? uint 64 14

Point 3. TAPI Parameter Selection mapped to SB • Q 2. How to select Tx/Rx Power? • Q 3. What is appropriate for application-identifier? • Q 4. Is there any additional parameters needed for SB? Orchestrator 1 SIP(Client port) Direction(Uni or Bi) Bandwidth? Connectivity. Service (Request from Client) Topology Available capacity? Node/NEP/SIP/Link (Request from Provider) Node/NEP/SIP/Link Connnectivity. Service/SEP 2 CEP connection-port-direction selected-nominal-center-frequency ( fixed val if needed ) selected-frequency-slot ( fixed val if needed ) selected-application-identifier Connection/CEP 3 15

Point 2. TAPI Parameter Mapping • Q 5. Is TAPI usage correct? (P 3 -P 12) Isn’t there any misunderstanding? • Q 6. What parameters should be mapped from Connectivity. Service/SEP to Connection/CEP? How? • Direction : Use preset value of NEP • Center frequency / frequency slot : Set fixed value if needed • Bandwidth? Anything else? Orchestrator 1 SIP(Client port) Direction(Uni or Bi) Bandwidth? Connectivity. Service (Request from Client) Topology Available capacity? Node/NEP/SIP/Link (Request from Provider) Node/NEP/SIP/Link Connnectivity. Service/SEP 2 CEP connection-port-direction selected-nominal-center-frequency ( fixed val if needed ) selected-frequency-slot ( fixed val if needed ) selected-application-identifier Connection/CEP 3 16

Case 1: line: 200 G x 1 (single lambda) - client: 40 G x 5 • Which model is correct? • Model 1: No need to use available capacity param ( Capacity is managed by available 40 G NEP ) • Model 2: Need to use available capacity param, link/availabie-capacity or node/available-capacity can be used DSR Connectivity Service (40 G) Model 1 x 5 Node. Edge. Point (Edge) DSR Conn(40 G) Node. Edge. Point (Internal) x 5 Service. Interface. Point aggregate Service. End. Point DSR Connection. End. Point Mapping Connection Link (40 G) x 5 DSR Transponder 2 DSR Connectivity Service (40 G) Model 2 x 5 DSR Conn(40 G) Link Transitional Link x 5 1. . 1 x 5 aggregate Link (200 G) Transponder 1 Topology Node DSR Link Conn(40 G) 1. . 1 x 5 DSR Link Conn(40 G) 1. . 5 DSR Transponder 1 Link (200 G) 17 x 5 1. . 5 DSR Transponder 2

Case 2: line: 40 G x 5(WDM) - client: 40 G x 5 • Which model is correct? • From OTSi viewpoint, Model 2 looks like better • What is Application. Identifier used for? To be revised based on Karthik’s FB DSR layer is needed if we consider OTSi layer and its parameters OTSi Connectivity Service (40 G) Model 1 x 5 Node. Edge. Point (Edge) OTSi Conn(40 G) Node. Edge. Point (Internal) OTSi Link Conn(40 G) x 5 Service. Interface. Point x 5 Service. End. Point OTSi Connection. End. Point assume each lambda as different links Transponder 1 Topology Node Mapping Connection OTSi Transponder 2 OTSi Connectivity Service (40 G) Model 2 x 5 OTSi Conn(40 G) Link Transitional Link (40 G) x 5 OTSi Link Conn(40 G) x 5 OTSi Transponder 1 Link (200 G) 18 supportable. Nominal. Center. Frequency [5] selected. Nominal. Center. Frequency supportable. Applicatoin. Idenfier x 5 selected. Application. Identifier OTSi supportable. Frequency. Slot [5] occupied. Frequency. Slot [0. . 5] Transponder 2

Case. X: model with DSR layer • Which model is correct? ( I think Model 1 might be correct ) • Model 1: Describe OTSi and DSR layer • Model 2: No DSR Layer, only something like OTSi DSR Connectivity Service (40 G) Model 1 DSR Conn(40 G) x 5 DSR Link Conn(40 G) DSR Link (40 G) OTSi Link (40 G) DSR Node. Edge. Point (Edge) Node. Edge. Point (Internal) OTSi Link Conn(40 G) 1. . 1 Service. Interface. Point aggregate Service. End. Point x 5 OTSi Connection. End. Point Link (40 G) x 5 DSR 1. . 1 x 5 aggregate Link (200 G) Transponder 1 OTSi Transponder 1 Topology Node Mapping DSR Connectivity Service (40 G) Model 2 x 5 Link Transitional Link OTSi Conn(40 G) x 5 aggregate Connection OTSi Transponder 1 OTSi Link Conn(40 G) 1. . 1 x 5 Link (40 G) Link (200 G) 1. . 1 x 5 aggregate x 5 OTSi Transponder 2

Point 5. Open. Config SB Model Selection • Available models differ from each vendor’s device specification • Some devices support older version of Open. Config • Openconfig-platform and optical-transport are key components • which version should be used? • how to use these models to describe actual device components? • wiki: https: //wiki. onosproject. org/display/ODTN/Available+Open. Config+models+and+versions+for+phas e+1 20

Point 4. Mapping from TAPI to Open. Config • To be determined after Open. Config SBI are fixed 21

Schedule To be fixed by 1. TAPI NBI Selection: Feb 12 2. TAPI Parameter Mapping ( Connectivity. Service -> Connection ): Feb 12 3. TAPI parameter Selection mapped to SB: Feb 12 4. Parameter Mapping from TAPI to Open. Config: Feb 28 5. Open. Config SB Model Selection: Feb 28 22

Backup Slides 23

tapi-connectivity. tree Discussion 1. NBI Selection module: tapi-connectivity augment /tapi-common: context: +--rw connectivity-service* [uuid] | +--rw end-point* [local-id] | | +--rw layer-protocol-name? tapi-common: layer-protocol-name | | +--rw service-interface-point? -> /tapi-common: context/service-interface-point/uuid | | +--rw capacity | | | +--ro total-potential-capacity | | +--ro total-size | | | +--ro value? uint 64 | | | +--ro unit? capacity-unit | | +--ro bandwidth-profile | | +--ro bw-profile-type? bandwidth-profile-type | | +--ro committed-information-rate | | | +--ro value? uint 64 | | | +--ro unit? capacity-unit | | +--ro committed-burst-size | | | +--ro value? uint 64 | | | +--ro unit? capacity-unit | | +--ro peak-information-rate | | | +--ro value? uint 64 | | | +--ro unit? capacity-unit | | +--ro peak-burst-size | | | +--ro value? uint 64 | | | +--ro unit? capacity-unit | | +--ro color-aware? boolean | | +--ro coupling-flag? boolean | | | +--ro available-capacity | | | +--ro total-size | | +--ro value? uint 64 | | +--ro unit? capacity-unit | | | +--ro bandwidth-profile | | | +--ro bw-profile-type? bandwidth-profile-type | | | +--ro committed-information-rate | | +--ro value? uint 64 | | +--ro unit? capacity-unit | | | +--ro committed-burst-size | | +--ro value? uint 64 24 RW -> Should be exposed to RESTCONF client to set value RO -> Read. Only for RESTCONF client is OK, but we need to make them configurable in ONOS If DCS does not allow to set RO container/leaf, we cannot set these values even if in Orange. Box. If so, we need to change permission from ro to rw or make another model for internal use which enables us to set all components in TAPI model

Discussion 1. NBI Selection tapi-connectivity. tree (Subset which has RW permission) augment /tapi-common: context: ー Seems to be needed in Phase 1 +--rw connectivity-service* [uuid] | +--rw end-point* [local-id] | | +--rw layer-protocol-name? tapi-common: layer-protocol-name | | +--rw service-interface-point? -> /tapi-common: context/service-interface-point/uuid | | +--rw capacity | | +--rw direction? tapi-common: port-direction | | +--rw role? tapi-common: port-role | | +--rw protection-role? protection-role | | +--rw local-id string | | +--rw name* [value-name] | | | +--rw value-name string | | | +--rw value? string | | +--rw administrative-state? administrative-state | +--rw direction? tapi-common: forwarding-direction | +--rw layer-protocol-name? tapi-common: layer-protocol-name | +--rw uuid | +--rw name* [value-name] | | +--rw value-name string | | +--rw value? string | +--rw is-exclusive? boolean | +--rw schedule | | +--rw end-time? date-and-time | | +--rw start-time? date-and-time | +--rw route-objective-function? route-objective-function | +--rw diversity-policy? diversity-policy | +--rw administrative-state? administrative-state | +--rw resilience-type | | +--rw restoration-policy? restoration-policy | | +--rw protection-type? protection-type | +--rw restoration-coordinate-type? coordinate-type | +--rw restore-priority? uint 64 | +--rw reversion-mode? reversion-mode | +--rw wait-to-revert-time? uint 64 | +--rw hold-off-time? uint 64 | +--rw is-lock-out? boolean | +--rw is-frozen? boolean | +--rw is-coordinated-switching-both-ends? boolean | +--rw max-switch-times? uint 64 25 | +--rw layer-protocol? tapi-common: layer-protocol-name • For Phase 1, which params needed? • protocol (fixed as “OTSi. A”? ) • capacity? • direction? • role? • policy? • state?

Discussion 1. NBI Selection • How to deal with Read. Only leafs in TAPI? How to make them configurable from yang-tools? (P 13) • Change Yang Model permissions by ourselves? (Read. Only -> Read. Write) • Create another YANG model for ONOS/ODTN internal use? • Are TAPI’s RW leafs/containers enough for Phase 1 NBI? (P 14) • In RW leafs/containers, which parameters are needed for Phase 1? (P 14) • We need to make subsets to achieve Phase 1 requirements • In Phase 1 we decided not to take care about protocol, but layer-protocol leaf is mandatory - Is it good to set “OTSi. A” as layer-protocol temporary? 26