Arturo Mayoral Victor López Oscar Gonzalez de Dios Telefonica May 7 2019 Telefonica GCTIO has designed the most significant use cases for service provisioning and configuration management in the optical layer ID: 1029062
Download Presentation The PPT/PDF document "TAPI NBI specification based on common T..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. TAPI NBI specification based on common Topology and Service abstraction models for Multi-layer WDM/OTN networksArturo Mayoral, Victor López, Oscar Gonzalez de Dios, TelefonicaMay 7, 2019
2. Telefonica GCTIO has designed the most significant use cases for service provisioning and configuration management in the optical layer.The objective of Telefonica is to achieve the goal of introducing an standard Northbound interface (NBI) based on RESTCONF (RFC 8040) and ONF T-API (release version 2.1) models, in its production networks in the short term.For that, the level of interoperability among different suppliers solutions need to be the higher as possible and the simpler statement of supporting TAPI v2.1.1 plus RESTCONF is not sufficient for fully interoperable solutions.This presentation includes the Telefonica proposal for topology and services abstraction model designed for WDM and OTN networks which defines a set of guidelines for describing multi-layer network at both topology and service levels.The intention of this document is share current Telefonica proposal with ONF audience towards the definition of a ONF topology and service abstraction model which can serve the following: improve common understanding of TAPI models, increase model gaps awareness and anticipate potential vendor interoperability issues.Ambition
3. Protocol considerations
4. ONF TAPI v2.1 SpecificationInformation ModelModelVersionRevision (dd/mm/yyyy)tapi-common.yang2.1.110/12/2018tapi-connectivity.yang2.1.110/12/2018tapi-eth.yang2.1.110/12/2018tapi-dsr.yang2.1.110/12/2018tapi-notification.yang2.1.110/12/2018tapi-oam.yang2.1.110/12/2018tapi-odu.yang2.1.110/12/2018tapi-photonic-media.yang2.1.110/12/2018tapi-path-computation.yang2.1.110/12/2018tapi-topology.yang2.1.110/12/2018tapi-virtual-network.yang2.1.110/12/2018ONF Transport API version 2.1, released on October 16th, 2018, is the version proposed in current proposal.https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1This is the complete list of YANG models for this specification:
5. ONF TAPI v2.1 Specification (2)TAPI RESTCONF specification consists of the following resources:{+restconf}/data (Data API): CRUD based RESTCONF API for the entire data tree defined in the TAPI YANG files.{+restconf}/operations (Operations API): RPC based RESTCONF API consisting on a small set of operations defined as RPCs in the TAPI YANG files.{+restconf}/yang-library-version: This mandatory leaf identifies the revision date of the "ietf-yang-library" YANG module that is implemented by this server.{+restconf}/streams (Notifications API): Notifications implementation of RESTCONF protocol are defined in https://tools.ietf.org/html/rfc8040#section-6.3, The solution implementing the RESTCONF server must expose its supported notification streams by populating the "restconf-state/streams" container definition in the "ietf-restconf-monitoring" module defined in Section 9.3 of [RFC 8040]. The streams resource can be found at:{+restconf}/data/ietf-restconf-monitoring:restconf-state/streamsThe solution must support the “filter” Query Parameter, as defined in Section 4.8.4 of [RFC 8040], to indicate the target subset of the possible events being advertised by the RESTCONF server stream. The "filter" query parameter URI SHALL be listed in the "capability" leaf-list, located at:{+restconf}/data/ietf-restconf-monitoring:restconf-state/capabilties,as defined in Section 9.3 of [RFC 8040]RESTCONF Implementation
6. It is proposed the following level of compliancy for the first integration phase (Pack SDNC_1).Operations API: Not mandatory supportData API: Mandatory FULL Create, Retrieve, Update, Delete (CRUD) support of all the following objects is requested.ONF TAPI v2.1 Specification (3)RESTCONF Implementation/tapi-common:context//tapi-common:context/service-interface-point//tapi-common:context/service-interface-point={uuid}//tapi-common:context/tapi-topology:topology-context/nw-topology-service//tapi-common:context/tapi-topology:topology-context/topology//tapi-common:context/tapi-topology:topology-context/topology={uuid}//tapi-common:context/tapi-topology:topology-context/topology/node//tapi-common:context/tapi-topology:topology-context/topology/node={uuid}//tapi-common:context/tapi-topology:topology-context/topology/link//tapi-common:context/tapi-topology:topology-context/topology/link={uuid}//tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point//tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point={uuid}//tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:cep-list//tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:cep-list/tapi-connectivity:connection-end-point//tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:cep-list/tapi-connectivity:connection-end-point={uuid}//tapi-common:context/tapi-connectivity:connectivity-context//tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service//tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service={uuid}//tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service/connection//tapi-common:context/tapi-connectivity:connectivity-context/connection//tapi-common:context/tapi-connectivity:connectivity-context/connection={uuid}//tapi-common:context/tapi-path-computation:path-computation-context//tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service//tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service={uuid}//tapi-common:context/tapi-path-computation:path-computation-context/path//tapi-common:context/tapi-path-computation:path-computation-context/path={uuid}//tapi-common:context/tapi-common:context/tapi-notification:notification-context//tapi-common:context/tapi-common:context/tapi-notification:notification-context/notification/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription//tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/notification
7. SSE vs Websockets transport protocol for RESTCONF notifications:Server Sent Events (SSE) [W3C.REC-eventsource-20150203] is the current standard mechanism defined by RESTCONF to stream notifications.However due to the current high support of Websocket technology in previous OIF TAPI interop activities, there is a debate on which standard to accept.OAS TAPI specification is considered a possible candidate as RESTCONF 8040 Reference Implementation. TAPI OAS is considered as a valuable reference implementation which may serve for early adoption of TAPI concepts and first Proofs of Concepts (PoCs) but the present specification states that the standard RESTCONF protocol described in the previous section must prevail over any other implementation. Thus, any deviation of the standard included in the TAPI OAS will be precluded in real deployments, in other words, in case of a conflict in integration between two implementations, the RESTCONF standard will always prevail over TAPI OAS or any other REST-alike implementation.ONF TAPI v2.1 Specification (4)RESCONF implementation:
8. Notifications implementation of RESTCONF protocol are defined in https://tools.ietf.org/html/rfc8040#section-6.3, however tapi-notification.yang defines a specific API entry to create/delete/retrieve notification-subscription services:/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/ , and also an specific leaf object to specify the streaming address of each notification-subscription service:/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/notification-channel/stream-address/ONF TAPI v2.1 Specification (5)RESCONF implementation:
9. OTN/WDM network topology modeling
10. Scenario 1: WDM/OTN network with OTN switchesComponents View 1OTN Matrix + Client and LineOTNLine 100GLine 100GOTN Matrix + Client and LineClient 10x10GEClient 10x1GEOTN Matrix + Client and LineOTNLine 100GLine 100GClient 10x10GEClient 10x1GE
11. The first TAPI Topology model presented is based on a single flat topology view which collapses all network layers into a single topology. The T0 – Multilayer topology MUST include:ODU/DSR forwarding domains represented as multi-layer and multi-rate tapi-topology:node, allowing the representation of the internal mapping between DSR and ODU NEPs (multi-layer) and the multiplexing/de-multiplexing across different ODU rates (multi-rate). ODU-OTSi transitions MUST be represented as transitional links. OTSi forwarding domains: represent the optical side of the optical terminals (transponders/muxponders). They are represented by single-layer tapi-topology:node, allowing the representation of the logical aggregation of OTSi connections into OTSiA aggregation and the mapping of OTSiA to ODU connections as. OTSI to Photonic-Media node connectivity MUST be represented as OMS links.Photonic-Media forwarding domains: represents the Photonic Media (Open Line System (OLS)) network. This forwarding domains can be mapped to OLP, ROADM/FOADM and ILA network elements which connectivity is always represented as OMS or OTS links. These forwarding domains SHALL expose the capability of create Media Channel connection and connectivity services between its endpoints. OTN/WDM network topology modelingTAPI Topology Flat Abstraction model
12. Transponder / OTSi switch Node41.D151.D1ODUTransponder / ODU switch Node2.D1x1021.D111D130.D131.D1x10x10ODUODUTransponder / ODU switch NodeODUODUOTSI/OMS OTSiTransponder / OTSi switch NodeOTSPHTN NODEPHTN Node(ILA)OTSOTSNMC/OMS OTSPHTN NODEOTSi OTSI/OMSTransponder / OTSi switch NodeODUTransponderOTSi OTSi OTSi OTSi OMS OMS OMS OMSPHTN NODEOTSI/OMS OTSI/OMSOTSiNMC/OMSTAPI Topology Flat Abstraction viewTopology #1: Flat topology (DSR+ODU+OTSi+OMS+OTS)DSRDSRDSR/ODUDSR/ODUDSRDSRx10x1020.D110.D167.D140.D1ODU60.D150.D170.D1Transponder / OTSi switch Node77.D1TransponderOTSi76.D173.D171.D172.D1x10ODUODUODU78.D165.D166.D1ODUODU69.D175.D163.D164.D161.D168.D174.D162.D1OTSI/OMSNMC/OMSNMC/OMSNMC/OMS Topology #0
13. Photonic NodeOTSi NodeODU/DSR NodeTransponder / OTSi switch Node41.D151.D1ODUTransponder / ODU switch Node2.D1x1021.D111D130.D131.D1x10x10ODUODUTransponder / ODU switch NodeODUODUOTSI/OMS OTSiTransponder / OTSi switch NodeOTSPHTN NODEPHTN Node(ILA)OTSOTSNMC/OMS OTSPHTN NODEOTSi OTSI/OMSTransponder / OTSi switch NodeODUTransponderOTSi OTSi OTSi OTSi OMS OMS OMS OMSPHTN NODEOTSI/OMS OTSI/OMSOTSiNMC/OMSTAPI Topology Flat Abstraction viewTopology #1: Flat topology (DSR+ODU+OTSi+OMS+OTS)DSRDSRDSR/ODUDSR/ODUDSRDSRx10x1020.D110.D167.D140.D1ODU60.D150.D170.D1Transponder / OTSi switch Node77.D1TransponderOTSi76.D173.D171.D172.D1x10ODUODUODU78.D165.D166.D1ODUODU69.D175.D163.D164.D161.D168.D174.D162.D1DeviceOTSI/OMSNMC/OMSNMC/OMSNMC/OMS
14. Based on the previous topology model a four-level abstraction model is required to simplify the customer usage of the network data provided by the TAPI server. A general guidelines the model proposes:The network logical abstraction is divided in four-level abstraction topologies differentiating the DSR/ODU client layer, the DSR/ODU server layer, the OTSi/OTSiA and Photonic Media (Media Channels, OMS, and OTS) layers. Each topology MUST be presented as a tapi-topology:topology object within the TAPI context.Each topology (except the DSR/ODU abstracted topology which does not have further client layer) MUST represent explicitly the client layer and the connectivity with the server layer through Transitional Links. The server topology in every level topology is presented as a single node abstraction.The first design principle is representing each forwarding domain at every layer as an aggregated tapi-topology:node object. At every layer, an abstract/aggregated node MUST be included to represent the potential forwarding between client network endpoints (SIPs + associated NEPs) at that layer.Each aggregated node MUST include a reference to the next level topology by tapi-topology:encap-topology attribute.Each aggregated node which include a list of NEPs as elements of the tapi-topology:owned-node-edge-point list, which need tobe identified as tapi-topology:node/tapi-topology:aggregated-node-edge-point , to be referenced by the NEPs of the underlying explicit topology.OTN/WDM network topology modelingTAPI Topology Layered Abstraction model
15. Topology T1 - DSR/ODU: represents the client DSR/ODU layers. In this topology, This topology MUST include only a DSR/ODU aggregated topology representing the potential forwarding between client/service network endpoints (SIPs + associated NEPs). From the HW perspective, in this topology these NEPs/SIPs represent the client ports of all transponder/muxponders, connected through WDM mesh networks or through point-to-point optical links.The NEPs layer qualifications allowed T1 level topology are:layer-protocol-name=DSR, ODUsupported-cep-layer-protocol-qualifier=[DIGITAL_SIGNAL_TYPE, ODU_TYPE]NEPs forwarding capabilities within this node SHALL be constrained by using node-rule-group/rules/forwarding-rules. The NEPs can be segmented according to the following conditions:Different layer-protocol-qualifier: In case multiple the aggregated node includes NEPs with different layer-protocol-qualifier types (i.e., between different DSR_SIGNAL_TYPEs or ODU_TYPE), each group SHALL be segmented with a node-rule-group, including:forwarding-rule=MAY_FORWARD_ACROSS_GROUPNot forwarding between same device ports: . In some cases it might be relevant to restrict the forwarding between client ports at the same network device (e.g., transponder). In this case ALL NEPs related to client ports at the same device SHALL be segmented with a node-rule-group, including:forwarding-rule=CANNOT_FORWARD_ACROSS_GROUPOTN/WDM network topology modelingTAPI Topology Layered Abstraction model
16. Topology T2 - DSR/ODU-OTSi: represent DSR/ODU explicitly and its connectivity with the OTSi network layers. In this topology:This topology includes the ODU/DSR as a client layer and the OTSi/OTSiA as a server layer.The ODU/DSR layer network, as the client layer, MUST be represented explicitly, i.e., each ODU/DSR forwarding domain MUST be represented as a single tapi-topology:nodeODU/DSR forwarding domains are multi-layer and multi-rate, allowing the representation of the internal mapping between DSR and ODU signals (multi-layer) and the multiplexing/de-multiplexing across different ODU rates.The NEPs layer qualifications allowed T2 level client layer topology are:layer-protocol-name=DSR, ODUsupported-cep-layer-protocol-qualifier=[DIGITAL_SIGNAL_TYPE, ODU_TYPE]The ODU NEPs representing the line side transmission and OTSi NEPs are 1:1 transitional relations expressed as transitional links.The OTSi/OTSiA layer network represents the potential forwarding capabilities between OTSi/OTSiA service endpoints. These NEPs/SIPs represents the line ports of all transponder/muxponders connected to the WDM mesh networkThe NEPs layer qualifications allowed T2 level server layer topology are:layer-protocol-name=PHOTONIC_MEDIAsupported-cep-layer-protocol-qualifier= [PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA]OTU layer is intentionally not included in the model as ODU->OTSiA/OTSi representation is enough to cover all our defined use cases.OTN/WDM network topology modelingTAPI Topology Layered Abstraction model
17. Topology T3 - OTSi/Photonic Media : represents OTSi/Photonic Media layer networks. In this topology:The client layer topology consists of nodes representing the mapping and multiplexing of OTSi signals. It consists of nodes including OTSi client endpoints representing the Trail Termination Points (TTPs) of the OTSi connections and OTSi/OMS endpoints representing the physical connectivity with ROADM/FOADM add/drop ports.The connectivity between transponder/muxponder line ports and ROADM/FOADM’s add/drop ports are expressed by tapi-topology:links between OMS PHOTONIC_MEDIA NEPs.The NEPs layer qualifications allowed T3 level client layer topology are:layer-protocol-name= PHOTONIC_MEDIAsupported-cep-layer-protocol-qualifier=[PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA], [PHOTONIC_LAYER_QUALIFIER_OMS]Generally transponder/muxponder line ports and ROADM/FOADM’s add/drop ports are 1:1 relations, in case Optical Line Protection (OLPs) are present, OLP complexity shall be always represented in the Topology T4-Server Photonic Media OLS topology.OTN/WDM network topology modelingTAPI Topology Layered Abstraction model
18. Topology T4 - Server Photonic Media (Open Line System - OLS): The Photonic Media layer is actually an aggregation of multiple network layers (OTS, OMS, NMC, NMCA, SMC, SMCA). The purpose of L3-Server topology is to represent explicitly each NMC forwarding domain as a Photonic Media node. These nodes might represent ROADM/FOADM sites in a WDM mesh. The NEPs at this layer are:layer-protocol-name= PHOTONIC_MEDIAsupported-cep-layer-protocol-qualifier=[PHOTONIC_LAYER_QUALIFIER_NMC/NMCA]tapi-photonic-media:media-channel-node-edge-point-spec will represent the media channel pool resources supportable, available and occupied. NMC NEPs MUST be present on top of OMS NEPs/CEPs to represent the adjacency between OTSi signals and NMCs over the OMS link between Transponder Line Ports and ROADM Add/Drop ports.Each NMC/NMCA NEP MUST include the tapi-photonic-media:media-channel-node-edge-point-spec to represent the media channel pool resources supportable, available and occupied. It is assumed at minimum, the lower layer forwarding constructs (tapi-topology:link) between forwarding domains which need to be represented in this topology should be OMS links. OTS layer links and intermediate OMS forwarding domains (In Line Amplifier sites) might be represented or not depending on vendor.In case OLP constructs are present for OMS protection, this should be represented in TAPI by using tapi-topology:resilience-type/tapi-topology:protection-type link’s attribute. Underlying switch control for OMS protection is out of the scope of this modelling.From now this layer topology does not include associated service interface points to be selected by users for the creation of services at the NMC/NMCA layers and it will only connection generated by the TAPI server will be represented.OTN/WDM network topology modelingTAPI Topology Layered Abstraction model
19. ROADM Node OTSi/ OTSiA NodeOTSiNodeTAPI Topology Layered Abstraction view 41.D151.D131.D111.D11.D121.D1ROADM NodeROADM Node5.D36.D31.D32.D3ILANodeOMS LinkPhotonic Media (OTSiMC, OMS, OTS) OLS NodeOMS LinkOMS LinkOTS Link Photonic Media (OTSi/OTSiA Node)DSR/ODUDSR/ODUx10x10x10x10OTSi NodeOTS Linkx10x10Topology #1Topology #2Topology #3Topology #4DSR/ODU Node4.D33.D3OTSi/ OTSiA NodeOTSi/ OTSiA NodeOTSi NodeDSR/ODU1.D22.D25.D26.D24.D23.D2
20. TAPI Topology Layered Abstraction viewROADM Node OTSi/ OTSiA NodeOTSiNode 41.D151.D131.D111.D11.D121.D1ROADM NodeROADM Node5.D36.D31.D32.D3ILANodeOMS LinkPhotonic Media (OTSiMC, OMS, OTS) OLS NodeOMS LinkOMS LinkOTS Link Photonic Media (OTSi/OTSiA Node)DSR/ODUDSR/ODUx10x10x10x10OTSi NodeOTS Linkx10x10Topology #1Topology #2Topology #3Topology #4DSR/ODU Node4.D33.D3OTSi/ OTSiA NodeOTSi/ OTSiA NodeOTSi NodeDSR/ODU1.D22.D25.D26.D24.D23.D2
21. Scenario 2: Point-to-point DWDM link + Mesh WDM/OTN network with OLPsTransponder 10GETransponder 10GEMux-ponder10x10GEMux-ponder10x10GEOLPOLPTransponder100GETransponder100GEMux-ponder10x10GE
22. ODUTransponder / ODU switch Nodex10ODUOTSI/OMS OTSiPHTN NODE OTSi OMSOTSI/OMSDSR32.D1Transponder / OTSi switch NodeTransponder / OTSi switch NodeOTSI/OMS OTSiOLP NODE OMS/NMC OMS/ NMC22.D1TAPI Topology Flat Abstraction viewTopology #5, #6, #7: Flat topology (DSR+ODU+OTSi+OMS+OTS)21.D1OTSPHTN Node(ILA)OTS OTS OMS OMSPHTN NODE OMS/ NMC39.D150.D1 OTSi OTSI/OMSTransponder OTSi48.D141.D142.D1x10ODUDSR51.D138.D147.D1ODU2.D1x10ODUOTSI/OMS OTSiPHTN NODE OTSi OMSOTSI/OMSDSR/ODU11.D1Transponder / OTSi switch NodeTransponder / OTSi switch NodeOTSI/OMS OTSiOLP NODEOMS/NMCOTSOMS/NMCPHTN NODEPHTN Node(ILA)OTSOTSOMS/NMC OTSPHTN NODEODUTransponder / ODU switch Node33.D1OTSI/OMS OTSiTransponder / OTSi switch NodeDSRPHTN Node(ILA)OTSODUTransponder / ODU switch Node34.D1OTSI/OMS OTSiTransponder / OTSi switch NodeDSRODUDSRTransponder / ODU switch NodeODUDSR/ODU1.D1Transponder / ODU switch NodeTransponder / ODU switch Node36.D145.D137.D146.D144.D152.D143.D135.D153.D149.D144.D140.D1 OTS OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMCOTS Topology #0
23. ODUTransponder / ODU switch Nodex10ODUOTSI/OMS OTSiPHTN NODE OTSi OMSOTSI/OMSDSR32.D1Transponder / OTSi switch NodeTransponder / OTSi switch NodeOTSI/OMS OTSiOLP NODE OMS/NMC OMS/ NMC22.D1OTSi NodeODU/DSR NodeDeviceTAPI Topology Flat Abstraction viewTopology #5, #6, #7: Flat topology (DSR+ODU+OTSi+OMS+OTS)21.D1OTSPHTN Node(ILA)OTS OTS OMS OMSPHTN NODE OMS/ NMC39.D150.D1 OTSi OTSI/OMSTransponder OTSi48.D141.D142.D1x10ODUDSR51.D138.D147.D1ODU2.D1x10ODUOTSI/OMS OTSiPHTN NODE OTSi OMSOTSI/OMSDSR/ODU11.D1Transponder / OTSi switch NodeTransponder / OTSi switch NodeOTSI/OMS OTSiOLP NODEOMS/NMCPhotonic NodeOTSOMS/NMCPHTN NODEPHTN Node(ILA)OTSOTSOMS/NMC OTSPHTN NODEODUTransponder / ODU switch Node33.D1OTSI/OMS OTSiTransponder / OTSi switch NodeDSRPHTN Node(ILA)OTSODUTransponder / ODU switch Node34.D1OTSI/OMS OTSiTransponder / OTSi switch NodeDSRODUDSRTransponder / ODU switch NodeODUDSR/ODU1.D1Transponder / ODU switch NodeTransponder / ODU switch Node36.D145.D137.D146.D144.D152.D143.D135.D153.D149.D144.D140.D1 OTS OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMC OMS/ NMCOTS
24. TAPI Topology Layered Abstraction viewTopology #1: Client topology representation (DSR + ODU)DSR/ODU Node 2x10x10ODUODUODU23.D122.D12.D11.D112.D1ODUODUx10DSR/ODU Node 1ODUODU34.D133.D1Topology #2Topology #5Topology #1
25. 22.D2TAPI Topology Layered Abstraction viewTopology #2, #3: Server topology (ODU + OTSi) ODUODUODU32.D1x102.D21.D112.D2ODUx106.D37.D38.D3x101.D32.D33.D35.D34.D3Topology #4OTSiNodeOTSi NodeOTSi NodeOTSi NodeOTSiNodePhotonic Media (OTSi/OTSiA Node)Topology #2Topology #3ODU 31.D1x10ROADMNodeROADMNodeROADMNodeILANodeOLPNodeOLPNodeOMS LinkOMS LinkOMS LinkOMS LinkOMS LinkOTS LinkOTS LinkOMS ConnectionPhotonic Media (OTSiMC, OMS, OTS) OLS Node11.D121.D133.D242.D1x102.D23.D21.D27.D28.D26.D25.D24.D2
26. OMS LinkOTS LinkOTS LinkROADMNodeTAPI Topology Layered Abstraction viewTopology #4: Server topology (Photonic Media - OLS) ROADMNodeOLPNodeROADMNodeILANodeOLPNodeOMS LinkOMS LinkOMS LinkOMS LinkOMS ConnectionOMS LinkOMS LinkOTSiNodeOTSiNodeOTSiNodeOTSiNodeOTSiNodeTopology #4
27. ILANodeOTS LinkTAPI Topology Layered Abstraction viewTopology #7: Server topology (Photonic Media - OLS)FOADMNodeFOADMNodePhotonic Media (OTSi/OTSiA Node)OTS LinkILANodeOMS LinkOMS ConnectionOTS LinkOTSiNodeODUODU34.D133.D12.D61.D6OTSiNodeTopology #5Topology #6Topology #71.D52.D5
28. OTN/WDM network connectivity service modeling
29. Based on ONF TAPI 2.1 models a network model is proposed for vendor agnostic integration on the systems. The assumptions made so far for the connectivity service model are the following:Service Interface Points (SIPs):All the network managed by an SDN-C should be contained in a single context which will include the list of available SIPs for all layers (except of OLS Network Media Channel layer which only applies to scenarios where partially disaggregation is implemented).A SIP is logically mapped to two topology NEPs: to the aggregated NEP of the server layer aggregated node of the upper level topology and the explicit NEP in the client layer node of the next level topologytapi-common:service-interface-points (SIPs) must be included at least for three layers: DSR, ODU, OTSiA/OTSi, for the development of the UCs included in the first phase (Pack SDNC_1). The following tapi objects must be included, e.g. for OTSiA/OTSi SIPs:layer-protocol-name = PHOTONIC_MEDIAsupported-layer-protocol-qualifier = [PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA]OTSiA/OTSi SIPs must be augmented with the following photonic-media extensions.ODU and DSR SIPs does not include any specific extensions yet.Connectivity-service and connections:Each tapi-connectivity:connectivity-service will always include at least a reference to one “Top Connection” tapi-connectivity:connection object within its connection list. The “Top Connection” object is intended to represent the service end-to-end within a layer and it will include the tapi-connectivity:connection/route object including the list of connection-end-points (CEPs) traversed by the service at that layer.The “Top Connection” may additionally include a reference to the connections created at the same layer to support the end-to-end in the tapi-connectivity:connection/lower-connection list. OTN/WDM network connectivity service modeling
30. TAPI LTP Template – Basic ArrangementsCEP has-server NEP(same layer)NEP Aggregates NEPs(same layer, capacity pool)CEP has-client NEP(same-layer or different layers)NEP connects-to NEP in another Node via Link(same layer)NEP connects-to NEP in another Node via Transitional Link(different layer)CEP connects-to CEP in another Node via Link Connection(same layer)nmpODU (10G)ETH, SDH, LO-ODU…(10G)ODU (100G)ODUODU (100G)ODU (10x10G)CEP connects-to-peer CEP via switched Connection(same layer) flexible cases with exposed CPF(a)(b)CEP connects-to-peer CEP via Encapsulated XC(same layer) fixed-mapping casesF(a)F(b)F F * Top (Link) Connection is not explicitly modeled in TAPIMedia Channel CEP{lowerFreq, upperFreq}Media Channel Assembly[{lowerFreq, upperFreq}, {lowerFreq, upperFreq}, ..]Service Interface PointNode Edge PointConnection End Point (TTP + CTP)Connection End Point (CTP only)Connection End Point (Inverse mux CTP only)Connection End Point (TTP only)Node Edge Point GroupMIPDown MEPUp MEPOPMNon Intrusive MonitoringNo Specific OAM signalingOptical Power MonitoringConnectionLinkTransitional Link
31. CASE 1: 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)
32. Topology #1DSR/ODUT2 DSR/ ODU switch NodeTransponder / ODU switch Node51.D160.D1ODU NodeDSR NodeODU 10GE DSR DSR 10GE ODU2T2 DSR/ ODU switch Node ODU2 10GE DSR DSR 10GE10GE/DSR Top ConnectionODUODUODU LinkT1 DSR/ODU Node11.D1x1020.D1x1010GE/DSR Connectivity ServiceODUPool = yesLayer=ODU4 (TTP rate)Total Capacity=200GSupported CTP Rates=ODU2, ODU2e, ODU3Max # TTP instances=2Max # CTP per TTP instances=10, 10, 2Layer=DSRTotal Capacity=10GSupported CTP Rates= 10GigE,Max # CTP instances=1Layer=ODU4 (TTP rate)Total Capacity=100GSupported CTP Rates=ODU4Max # TTP instances=1Max # CTP per TTP instances=1
33. Topology #1DSR/ODUT2 DSR/ ODU switch NodeTransponder / ODU switch Node51.D160.D1ODU NodeDSR NodeODU 10GE DSR DSR 10GE ODU2T2 DSR/ ODU switch Node ODU2 10GE DSR DSR 10GE ODU4 ODU4ODU4 Top Connection10GE/DSR Top ConnectionODUODUODU LinkODUODUT1 DSR/ODU Node11.D1x1020.D1x1010GE/DSR Connectivity Service ODU4 ODU4ODUPool = yesLayer=ODU4 (TTP rate)Total Capacity=200GSupported CTP Rates=ODU2, ODU2e, ODU3Max # TTP instances=2Max # CTP per TTP instances=10, 10, 2Layer=DSRTotal Capacity=10GSupported CTP Rates= 10GigE,Max # CTP instances=1Layer=ODU4 (TTP rate)Total Capacity=100GSupported CTP Rates=ODU4Max # TTP instances=1Max # CTP per TTP instances=1
34. Topology #1DSR/ODUT2 DSR/ ODU switch NodeTransponder / ODU switch Node51.D160.D1ODU NodeDSR NodeODU 10GE DSR DSR 10GE ODU2T2 DSR/ ODU switch Node ODU2 10GE DSR DSR 10GEODU2 Top Connection ODU4 ODU4ODU4 Top Connection10GE/DSR Top ConnectionODUODUODU LinkODUODUT1 DSR/ODU Node11.D1x1020.D1x1010GE/DSR Connectivity Service ODU4 ODU4ODUPool = yesLayer=ODU4 (TTP rate)Total Capacity=200GSupported CTP Rates=ODU2, ODU2e, ODU3Max # TTP instances=2Max # CTP per TTP instances=10, 10, 2ODU2ODU2Layer=DSRTotal Capacity=10GSupported CTP Rates= 10GigE,Max # CTP instances=1Layer=ODU4 (TTP rate)Total Capacity=100GSupported CTP Rates=ODU4Max # TTP instances=1Max # CTP per TTP instances=1
35. Transponder / ODU switch NodeOTSi OTSi ODU ODU2 DSRODU ODU4 ODU OTSiTransponder / OTSi switch NodeOTSi NodeDSR/ODU NodeTransponder / ODU switch NodeOTSi OTSi ODU ODU2 DSRODU ODU4 ODU OTSiTransponder / OTSi switch NodePhotonic NodeODU4 Top ConnectionODU LinkOTSiTransitional LinkOTSiTransitional LinkOTSi Top ConnectionOTSi NodeODU/DSR TopologyTopology #2ODU/OTSiODU2 Top ConnectionPhotonic Link
36. ROADM Node OMS1 OMS-O NMC NMCTransponder / ODU switch NodeOMS Link OMS1 OMS-OOTSi/PHTNNodeOTSi/PHTNNode(ILA)OTSi Top Connection OTSOMS Link OTS OTS OTSOTS LinkOTS LinkPhotonic Node NMC Top Connection OTSi ODU ODU2 DSRODU NMC ODU4 ODUODU4 Top ConnectionODU2Top Connection OTSiTransponder / OTSi switch Node NMCNMCOTSi NodeDSR/ODU Node OMSAdd/Drop PortLine Port11 OMSTopology #3,#4OTSi/Photonic OTSiOTSi Link NMC
37. CASE 2: 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)
38. Topology #1DSR/ODUDSR/ ODU switch NodeTransponder / ODU switch NodeDSR/ODU Node51.D111.D1x1021.D120.D130.D1x1060.D1x10ODU NodeDSR Node 1GE DSR 1GEDSR/ ODU switch Node 1GE DSR 1GE ODU ODU ODU4 ODU4ODU4 Top ConnectionODU1GE/DSR Top Connection ODU0 DSR ODU0 DSRCASE 2: 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)Pool = yesLayer=ODU2 (TTP rate)Total Capacity=100GSupported CTP Rates= ODU0, ODU1Max # TTP instances=10Max # CTP per TTP instances= 10, 4Layer=ODU0Total Capacity=1GSupported CTP Rates= ODU0Max # CTP instances=1ODUPool = yesLayer=ODU4 (TTP rate)Total Capacity=200GSupported CTP Rates= ODU2, ODU2e, ODU3Max # TTP instances=2Max # CTP per TTP instances= 10, 4ODU
39. Topology #1DSR/ODUDSR/ ODU switch NodeTransponder / ODU switch NodeDSR/ODU Node51.D111.D1x1021.D120.D130.D1x1060.D1x10ODU NodeDSR Node 1GE DSR ODU 1GE ODU2DSR/ ODU switch Node ODU2 1GE DSR ODU 1GE ODU ODUODU2 Top Connection ODU4 ODU4ODU4 Top ConnectionODU1GE/DSR Top Connection ODU0 DSR ODU0 DSRODU0 Top ConnectionCASE 2: 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation) ODU0Pool = yesLayer=ODU2 (TTP rate)Total Capacity=100GSupported CTP Rates= ODU0, ODU1Max # TTP instances=10Max # CTP per TTP instances= 10, 4Layer=ODU0Total Capacity=1GSupported CTP Rates= ODU0Max # CTP instances=1ODUODUODU ODU2 ODU2Pool = yesLayer=ODU4 (TTP rate)Total Capacity=200GSupported CTP Rates=ODU2, ODU2e, ODU3Max # TTP instances=2Max # CTP per TTP instances=10, 10, 2
40. CASE 3: 1GE client signal over ODU 0 over ODU2 over ODU4 (with intermediate ODU0 switching)
41. Topology #1 DSR/ODU Flexible StructureODU NodeDSR Node51.D160.D1ODU/DSR Node51.D160.D1x10ODUDSR/ ODU switch Node ODU2 1GE DSR ODU 1GE ODU ODU4ODU ODU4 ODU0 DSRx10ODUDSR/ ODU switch Node ODU2 1GE DSR ODU 1GE ODU ODU4ODU ODU4 ODU0 DSRODU4 Top ConnectionODU4 Top Connection1GE Top ConnectionODU0 Top ConnectionODU2 Top Connection DSR ODU2 ODUODU ODU ODU2 ODUODUODU0 Top Connection ODU0 ODU0ODU2 Top ConnectionDSR/ ODU switch Node
42. Case 4: 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation) with intermediate transponder regeneration.
43. Topology #1 DSR/ODU Flexible StructureODU NodeDSR Node51.D160.D1ODU/DSR Node51.D160.D1x10ODUDSR/ ODU switch Node ODU2 1GE DSR 1GE ODU ODU4ODU ODU4 DSRx10ODUDSR/ ODU switch Node ODU2 1GE DSR 1GE ODU ODU4ODU ODU4 DSRODU4 Top ConnectionODU4 Top Connection1GE Top ConnectionODU2 Top ConnectionODU/DSR Transponder NodeODU4 LinkODU4 Link
44. Case 5: 10GE client signal over ODU0 over ODU2 over ODU4 with Line Side OLP Protection
45. ROADM Node OMS1 OMS-O NMC NMCTransponder / ODU switch NodeOMS Link OMS1 OMS-OOTSi/PHTNNodeOTSi/PHTNNode(ILA)OTSi Top Connection OTSOMS Link OTS OTS OTSOTS LinkOTS LinkPhotonic Node NMC Top Connection - A OTSi ODU ODU2 DSRODU NMC ODU4 ODUODU4 Top ConnectionODU2Top Connection OTSiTransponder / OTSi switch Node NMCNMCOTSi NodeDSR/ODU Node OMSAdd/Drop PortLine Port11 OMSTopology #3,#4OTSi/Photonic OTSi NMCOLP NODEAdd/Drop Port NMC1 OMS NMC OMS OMS NMC2 NMC OMS NMC NMC NMC NMC OMSSwtich-control= yesselected-connection-end-point: NMC-1,NMC-2selected-route: NMC Top Connection - Aresilience-type:ONE_FOR_ONE_PROTECTION NMC1NMC Top Connection - B
46. Use Cases
47. Discovery use cases:Use case 0: Topology and services discovery.Provisioning use cases:Use case 1: Unconstrained E2E Service Provisioning (Digital Signal Rate (DSR) Service i.e., GE, 10GbE, STM-X, fiberchannel…) Use case 2: Unconstrained with channel or slot selection2a: OCH/OTSi (channel selection) 2b:ODU (time slot selection) Service ProvisioningUse case 3: Constrained service provisioning.3a: Include/exclude a node or group of nodes.3b: Include/exclude a link or group of links.3c: Include/exclude the path used by other service.Use case 4: Manual unconstrained E2E Service Provisioning. Step by step.Use cases (I)
48. Resilience use cases:Use case 5: 1+1 Diverse Service Provisioning for any of the previous cases (1, 2, 3a, 3b, 3c, 4) 5a: 2 transponders (Y cable)5b: OLP5c: (eSNCP)Use case 6: Dynamic restoration for unconstrained and constrained use cases (1, 2, 3a, 3b, 3c, 4)Use case 7: Restoration and protection 1+1 for use cases (1, 2, 3a, 3b, 3c, 4)Use case 8: Permanent protection 1+1 for use cases (1, 2, 3a, 3b, 3c, 4)Use case 9: Reverted protection for use cases (5a, 5b, 5c, 6, 7 and 8)Use cases (II)
49. Service maintenance use cases:Use case 10: Service deletion (applicable to all previous use cases)Use case 11: Modification of service characteristics.11a: Modification of service path11b: Modification of service nominal path to secondary (protection) path for maintenance operations. (Only valid for resiliency use cases)11c Modification or upgrade of service capacity. (Only valid for electrical services)Planning use cases:Use case 12: 12a: Pre-calculation of the optimum path (applicable to all previous use cases)12b: Simultaneous pre-calculation of two disjoint paths.12c: Multiple simultaneous path computation (Bulk request processing)12d: Physical impairment validation of an pre-calculated Och trail path.Use cases (III)