TAPI NBI specification based on common Topology and
TAPI NBI specification based on common Topology and Service abstraction models for Multi-layer WDM/OTN networks Arturo Mayoral, Victor López, Oscar Gonzalez de Dios, Telefonica May 7, 2019
Ambition • 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 v 2. 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.
Protocol considerations
ONF TAPI v 2. 1 Specification Information Model • ONF Transport API version 2. 1, released on October 16 th, 2018, is the version proposed in current proposal. – • https: //github. com/Open. Networking. Foundation/TAPI/tree/v 2. 1. 1 This is the complete list of YANG models for this specification: Model tapi-common. yang tapi-connectivity. yang tapi-eth. yang tapi-dsr. yang tapi-notification. yang tapi-oam. yang tapi-odu. yang tapi-photonic-media. yang tapi-path-computation. yang tapi-topology. yang tapi-virtual-network. yang Version 2. 1. 1 2. 1. 1 Revision (dd/mm/yyyy) 10/12/2018 10/12/2018 10/12/2018
ONF TAPI v 2. 1 Specification (2) RESTCONF Implementation • 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/rfc 8040#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/streams The 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]
ONF TAPI v 2. 1 Specification (3) RESTCONF Implementation • It is proposed the following level of compliancy for the first integration phase (Pack SDNC_1). § Operations API: Not mandatory support § Data API: Mandatory FULL Create, Retrieve, Update, Delete (CRUD) support of all the following objects is requested. /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={uuid}/ /tapi-common: context/tapi-topology: topology-context/topology/node={uuid}/ /tapi-common: context/tapi-topology: topology-context/topology/link={uuid}/ /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-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-endpoint={uuid}/ /tapi-common: context/tapi-connectivity: connectivity-context/tapi-connectivity: connectivity-service/ /tapi-common: context/tapi-connectivity: connectivity-service={uuid}/ /tapi-common: context/tapi-connectivity: connectivity-service/connection/ /tapi-common: context/tapi-connectivity: connectivity-context/connection={uuid}/ /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={uuid}/ /tapi-common: context/tapi-common: context/tapi-notification: notification-context/notification /tapi-common: context/tapi-common: context/tapi-notification: notification-context/notif-subscription/notification
ONF TAPI v 2. 1 Specification (4) RESCONF implementation: • SSE vs Websockets transport protocol for RESTCONF notifications: § § • Server Sent Events (SSE) [W 3 C. 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 (Po. Cs) 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 v 2. 1 Specification (5) RESCONF implementation: • Notifications implementation of RESTCONF protocol are defined in https: //tools. ietf. org/html/rfc 8040#section-6. 3, however tapi-notification. yang defines a specific API entry to create/delete/retrieve notification-subscription services: § /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-notification: notification-context/notif -subscription/notification-channel/stream-address/
OTN/WDM network topology modeling
Scenario 1: WDM/OTN network with OTN switches Components View 1 OTN Matrix + Client and Line Client 10 x 1 GE OTN Line 100 G OTN Matrix + Client and Line Client 10 x 10 GE Client 10 x 1 GE OTN Line 100 G
OTN/WDM network topology modeling TAPI Topology Flat Abstraction model The first TAPI Topology model presented is based on a single flat topology view which collapses all network layers into a single topology. The T 0 – 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/demultiplexing 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 OTSi. A aggregation and the mapping of OTSi. A 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.
TAPI Topology Flat Abstraction view Topology #1: Flat topology (DSR+ODU+OTSi+OMS+OTS) 61. D 1 62. D 1 67. D 1 68. D 1 77. D 1 73. D 1 Topology #0 74. D 1 Transponder / ODU switch Node Transponder / OTSi switch Node 2. D 1 10. D 1 x 10 OTSI/OMS ODU DSR/ODU 11 D 1 20. D 1 PHTN NODE OTS NMC/OMS x 10 78. D 1 PHTN NODE NMC/OMS OTSi ODU PHTN Node (ILA) OTS OTSI/OMS Transponder / OTSi switch Node ODU PHTN NODE OMS OTSi ODU OTSI/OMS ODU OTSi OTSI/O Transponder MS Transponder OTSi DSR ODU OTSi 76. D 1 75. D 1 ODU 69. D 1 70. D 1 ODU ODU 63. D 1 21. D 1 30. D 1 DSR x 10 41. D 1 50. D 1 DSR x 10 Transponder / OTSi switch Node NMC/OMS 66. D 1 Transponder / ODU switch Node OTSI/OMS OTSi ODU NMC/OMS Transponder / OTSi switch Node 65. D 1 72. D 1 NMC/OMS OMS DSR/ODU 71. D 1 64. D 1 31. D 1 40. D 1 x 10 51. D 1 60. D 1
TAPI Topology Flat Abstraction view Topology #1: Flat topology (DSR+ODU+OTSi+OMS+OTS) 61. D 1 62. D 1 67. D 1 68. D 1 77. D 1 73. D 1 Transponder / ODU switch Node Transponder / OTSi switch Node x 10 OTSI/OMS ODU DSR/ODU OTS PHTN Node (ILA) OTS OTSI/OMS Transponder / OTSi switch Node ODU PHTN NODE OMS OTSi ODU OTSI/OMS ODU OTSi OTSI/O Transponder MS Transponder OTSi 41. D 1 50. D 1 DSR x 10 Transponder / OTSi switch Node NMC/OMS 66. D 1 Transponder / ODU switch Node OTSI/OMS OTSi ODU NMC/OMS Transponder / OTSi switch Node 65. D 1 72. D 1 NMC/OMS OMS DSR/ODU 78. D 1 PHTN NODE NMC/OMS x 10 11 D 1 20. D 1 PHTN NODE NMC/OMS OTSi ODU 2. D 1 10. D 1 ODU/DSR Node OTSi Node Photonic Node 74. D 1 71. D 1 DSR ODU x 10 ODU OTSi 76. D 1 75. D 1 ODU 69. D 1 70. D 1 ODU ODU 63. D 1 21. D 1 30. D 1 DSR x 10 64. D 1 31. D 1 40. D 1 Device 51. D 1 60. D 1
OTN/WDM network topology modeling TAPI Topology Layered Abstraction model 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/OTSi. A 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 tapitopology: 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 modeling TAPI Topology Layered Abstraction model • Topology T 1 - 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-topoint optical links. The NEPs layer qualifications allowed T 1 level topology are: • layer-protocol-name=DSR, ODU • supported-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-protocolqualifier types (i. e. , between different DSR_SIGNAL_TYPEs or ODU_TYPE), each group SHALL be segmented with a noderule-group, including: § forwarding-rule=MAY_FORWARD_ACROSS_GROUP • Not 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_GROUP
OTN/WDM network topology modeling TAPI Topology Layered Abstraction model • Topology T 2 - 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/OTSi. A 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: node ODU/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 T 2 level client layer topology are: • layer-protocol-name=DSR, ODU • supported-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/OTSi. A layer network represents the potential forwarding capabilities between OTSi/OTSi. A service endpoints. These NEPs/SIPs represents the line ports of all transponder/muxponders connected to the WDM mesh network The NEPs layer qualifications allowed T 2 level server layer topology are: • layer-protocol-name=PHOTONIC_MEDIA • supported-cep-layer-protocol-qualifier= [PHOTONIC_LAYER_QUALIFIER_OTSi/OTSi. A] OTU layer is intentionally not included in the model as ODU->OTSi. A/OTSi representation is enough to cover all our defined use cases.
OTN/WDM network topology modeling TAPI Topology Layered Abstraction model • Topology T 3 - 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 tapitopology: links between OMS PHOTONIC_MEDIA NEPs. The NEPs layer qualifications allowed T 3 level client layer topology are: • layer-protocol-name= PHOTONIC_MEDIA • supported-cep-layer-protocol-qualifier=[PHOTONIC_LAYER_QUALIFIER_OTSi/OTSi. A], [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 T 4 -Server Photonic Media OLS topology.
OTN/WDM network topology modeling TAPI Topology Layered Abstraction model • Topology T 4 - Server Photonic Media (Open Line System - OLS): § The Photonic Media layer is actually an aggregation of multiple network layers (OTS, OMS, NMCA, SMCA). The purpose of L 3 -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_MEDIA • supported-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.
TAPI Topology Layered Abstraction view 1. D 1 11. D 1 21. D 1 3. D 2 Topology #1 x 10 DSR/ODU Node DSR/ODU 5. D 2 x 10 6. D 2 DSR/ODU x 10 1. D 3 Topology #2 2. D 3 3. D 3 OTSi/ OTSi. A Node 41. D 1 51. D 1 x 10 1. D 2 2. D 2 31. D 1 4. D 2 Photonic Media (OTSi/OTSi. A Node) 5. D 3 6. D 3 OTSi Node OTSi. N ode OTSi/ OTSi A Node OTSi Node 4. D 3 Topology #3 Photonic Media (OTSi. MC, OMS, OTS) OLS Node OMS Link ROADM Node OTS Link ILA Node OMS Link OTS Link ROADM Node OMS Link ROADM Node Topology #4
TAPI Topology Layered Abstraction view 1. D 1 11. D 1 21. D 1 3. D 2 Topology #1 x 10 DSR/ODU Node DSR/ODU 5. D 2 x 10 6. D 2 DSR/ODU x 10 1. D 3 Topology #2 2. D 3 3. D 3 OTSi/ OTSi. A Node 41. D 1 51. D 1 x 10 1. D 2 2. D 2 31. D 1 4. D 2 Photonic Media (OTSi/OTSi. A Node) 5. D 3 6. D 3 OTSi Node OTSi. N ode OTSi/ OTSi A Node OTSi Node 4. D 3 Topology #3 Photonic Media (OTSi. MC, OMS, OTS) OLS Node OMS Link ROADM Node OTS Link ILA Node OMS Link OTS Link ROADM Node OMS Link ROADM Node Topology #4
Scenario 2: Point-to-point DWDM link + Mesh WDM/OTN network with OLPs Transponder 100 GE Transponder 10 GE O L P Transponder 10 GE Mux-ponder 10 x 10 GE
TAPI Topology Flat Abstraction view Topology #5, #6, #7: Flat topology (DSR+ODU+OTSi+OMS+OTS) 36. D 1 37. D 1 33. D 1 45. D 1 43. D 1 44. D 1 46. D 1 35. D 1 52. D 1 Transponder / ODU switch Node DSR ODU Transponder / ODU switch Node 1. D 1 53. D 1 Transponder / OTSi switch Node OTSI/OMS OTSi ODU DSR/ODU OMS/NMC OTS OLP NODE OMS/ NMC OTSPHTN Transponder / ODU switch Node 2. D 1 11. D 1 x 10 OTSI/OMS OTSi ODU DSR/ODU OTSI/OMS OTS Node (ILA) PHTN NODE OMS/ NMC OMS/NMC OTS OMS/ NMC PHTN Node (ILA) OTS OMS/ NMC OMS/ NMC OMS PHTN NODE OMS OMS/ NMC OTSi OTSI/OMS OTSi 47. D 1 PHTN NODE OMS/ NMC OTS Transponder / OTSi switch Node 49. D 1 Topology #0 PHTN NODE Transp onder OTSi OLP NODE OMS/ NMC Transponder / OTSi switch Node OTSI/OMS OTSi 21. D 1 x 10 ODU 39. D 1 41. D 1 51. D 1 Transponder / ODU switch Node DSR 42. D 1 34. D 1 Transponder / ODU switch Node ODU 22. D 1 DSR Transponder / ODU switch Node ODU x 10 ODU 48. D 1 DSR 50. D 1 40. D 1 DSR ODU 38. D 1 44. D 1 32. D 1
TAPI Topology Flat Abstraction view Topology #5, #6, #7: Flat topology (DSR+ODU+OTSi+OMS+OTS) 36. D 1 37. D 1 33. D 1 46. D 1 35. D 1 52. D 1 Transponder / ODU switch Node DSR ODU Transponder / ODU switch Node 1. D 1 ODU/DSR Node OTSi Node Photonic Node 45. D 1 43. D 1 44. D 1 Transponder / OTSi switch Node OTSI/OMS OTSi ODU DSR/ODU PHTN NODE OMS/NMC OTS OLP NODE OMS/ NMC OTSPHTN Transponder / ODU switch Node 2. D 1 11. D 1 x 10 OTSI/OMS OTSi ODU DSR/ODU OTSI/OMS PHTN Node (ILA) PHTN NODE OMS/ NMC PHTN Node (ILA) OMS/ NMC OMS OTS OMS/NMC OTS OTS OMS/ NMC OMS PHTN NODE OMS OMS/ NMC OTSi OTSI/OMS OTSi 47. D 1 PHTN NODE OMS/ NMC OTS Transp onder OTSi OLP NODE OMS/ NMC Transponder / OTSi switch Node OTSI/OMS OTSi 21. D 1 x 10 ODU 39. D 1 41. D 1 51. D 1 Transponder / ODU switch Node DSR 42. D 1 34. D 1 Transponder / ODU switch Node ODU 22. D 1 DSR Transponder / ODU switch Node ODU x 10 ODU 48. D 1 DSR 50. D 1 40. D 1 DSR ODU 38. D 1 44. D 1 49. D 1 PHTN NODE OMS/ NMC OTS Transponder / OTSi switch Node OTS Node (ILA) 53. D 1 Device 32. D 1
TAPI Topology Layered Abstraction view Topology #1: Client topology representation (DSR + ODU) 1. D 1 22. D 1 12. D 1 23. D 1 2. D 1 34. D 1 33. D 1 Topology #1 DSR/ODU Node 1 ODU x 10 DSR/ODU Node 2 x 10 ODU ODU x 10 Topology #5 Topology #2
TAPI Topology Layered Abstraction view Topology #2, #3: Server topology (ODU + OTSi) 1. D 2 11. D 2 1 1. D 1 12. D 21 2. D 2 x 10 3. D 2 4. D 2 5. D 2 32. D 1 22. D 31. D 21 6. D 2 33. D 42. D 21 x 10 ODU ODU 7. D 2 8. D 2 ODU 6. D 3 ODU 1. D 3 x 10 Topology #2 x 10 2. D 3 3. D 3 OTSi Node 4. D 3 Photonic Media (OTSi/OTSi. A Node) OTSi Node 8. D 3 OTSi Node 5. D 3 Topology #3 Photonic Media (OTSi. MC, OMS, OTS) OLS Node OMS Link OMS Connection OLP Node OMS Link ROADM OTS Node OMLink SL ink ILA Node OTS Link ROADM S Link Node OM OLP Node ink ROADM MS L Node O 7. D 3 Topology #4
TAPI Topology Layered Abstraction view Topology #4: Server topology (Photonic Media - OLS) OTSi Node OMS Link OMS Connection OM S Li OLP nk Node OMS Link OTS Link ILA Node ROADM Node OMS Link OTS Link ROADM Node OM SL ink SL ROADM Node OTSi Node OM OLP Node Topology #4
TAPI Topology Layered Abstraction view Topology #7: Server topology (Photonic Media - OLS) 33. D 1 34. D 1 2. D 5 1. D 5 ODU 2. D 6 ODU 1. D 6 OTSi. N ode Topology #5 Photonic Media (OTSi/OTSi. A Node) OTSi. N ode Topology #6 FOAD M Node OMS Link OMS Connection OTS Link ILA Node FOAD M Node OTS Link Topology #7
OTN/WDM network connectivity service modeling
OTN/WDM network connectivity service modeling 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 topology tapi-common: service-interface-points (SIPs) must be included at least for three layers: DSR, ODU, OTSi. A/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 OTSi. A/OTSi SIPs: § layer-protocol-name = PHOTONIC_MEDIA § supported-layer-protocol-qualifier = [PHOTONIC_LAYER_QUALIFIER_OTSi/OTSi. A] OTSi. A/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 tapiconnectivity: 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.
TAPI LTP Template – Basic Arrangements ODU p (10 x 10 G) ODU (100 G) NEP Aggregates NEPs (same layer, capacity pool) ODU (100 G) CEP has-server NEP (same layer) Node Edge Point ETH, SDH, LO-ODU… m (10 G) ODU n Service Interface Point Node Edge Point Group Connection End Point (TTP only) Connection End Point ODU (10 G) (CTP only) Connection End Point (TTP + CTP) Connection End Point CEP has-client NEP (same-layer or different layers) (Inverse mux CTP only) Connection Media Channel CEP {lower. Freq, upper. Freq} NEP connects-to NEP in another Node via Link (same layer) Media Channel Assembly [{lower. Freq, upper. Freq}, . . ] (b) (a) Link F Transitional Link Down MEP CEP connects-to-peer CEP via switched Connection (same layer) flexible cases with exposed CP MIP NEP connects-to NEP in another Node via Transitional Link (different layer) (a) F CEP connects-to CEP in another Node via Link Connection (same layer) * Top (Link) Connection is not explicitly modeled in TAPI Up MEP (b) F F CEP connects-to-peer CEP via Encapsulated XC (same layer) fixed-mapping cases OPM Non Intrusive Monitoring No Specific OAM signaling Optical Power Monitoring F
CASE 1: 10 GE client signal over ODU 2 over ODU 4 (Fixed DSR-ODU mapping, flexible ODU allocation)
0 Topology #1 DSR Node ODU Node DSR/ODU 10 GE/DSR Connectivity Service 11. D 1 20. D 1 T 2 DSR/ ODU switch Node 10 GE DSR • • T 2 DSR/ ODU switch Node 10 GE/DSR Top Connection 10 GE DSR ODU 2 x 10 10 GE DSR Layer=DSR Total Capacity=10 G Supported CTP Rates= 10 Gig. E, Max # CTP instances=1 ODU Pool = yes Layer=ODU 4 (TTP rate) Total Capacity=200 G Supported CTP Rates=ODU 2, ODU 2 e, ODU 3 Max # TTP instances=2 Max # CTP per TTP instances=10, 2 ODU Link Transponder / ODU switch Node ODU • • • 51. D 1 60. D 1 • • • Layer=ODU 4 (TTP rate) Total Capacity=100 G Supported CTP Rates=ODU 4 Max # TTP instances=1 Max # CTP per TTP instances=1 ODU T 1 DSR/ODU Node
Topology #1 DSR Node ODU Node DSR/ODU 10 GE/DSR Connectivity Service 11. D 1 20. D 1 10 T 2 DSR/ ODU switch Node 10 GE DSR T 2 DSR/ ODU switch Node 10 GE/DSR Top Connection 10 GE DSR ODU 2 ODU 4 Pool = yes Layer=ODU 4 (TTP rate) Total Capacity=200 G Supported CTP Rates=ODU 2, ODU 2 e, ODU 3 Max # TTP instances=2 Max # CTP per TTP instances=10, 2 ODU 4 ODU Link Transponder / ODU switch Node ODU • • • 10 GE DSR ODU 4 Top Connection ODU Layer=DSR Total Capacity=10 G Supported CTP Rates= 10 Gig. E, Max # CTP instances=1 x 10 DSR ODU 2 • • 51. D 1 60. D 1 • • • Layer=ODU 4 (TTP rate) Total Capacity=100 G Supported CTP Rates=ODU 4 Max # TTP instances=1 Max # CTP per TTP instances=1 ODU 4 ODU T 1 DSR/ODU Node
Topology #1 DSR Node ODU Node DSR/ODU 10 GE/DSR Connectivity Service 11. D 1 20. D 1 10 T 2 DSR/ ODU switch Node 10 GE DSR T 2 DSR/ ODU switch Node 10 GE/DSR Top Connection 10 GE ODU 2 Top Connection DSR ODU 2 Layer=DSR Total Capacity=10 G Supported CTP Rates= 10 Gig. E, Max # CTP instances=1 ODU 4 Pool = yes Layer=ODU 4 (TTP rate) Total Capacity=200 G Supported CTP Rates=ODU 2, ODU 2 e, ODU 3 Max # TTP instances=2 Max # CTP per TTP instances=10, 2 DSR ODU 4 ODU ODU Link Transponder / ODU switch Node ODU • • • 10 GE ODU 2 ODU • • x 10 DSR ODU 2 ODU 4 Top Connection ODU 2 51. D 1 60. D 1 • • • Layer=ODU 4 (TTP rate) Total Capacity=100 G Supported CTP Rates=ODU 4 Max # TTP instances=1 Max # CTP per TTP instances=1 ODU 4 ODU T 1 DSR/ODU Node
Topology #2 ODU/OTSi ODU/DSR Topology OTSi Node DSR/ODU Node Transponder / ODU switch Node DSR Transponder / ODU switch Node ODU 2 Top Connection OTSi Node ODU 2 Transponder / OTSi switch Node ODU 4 Top Connection Transponder / OTSi switch Node ODU 4 ODU Link ODU DSR ODU 2 ODU OTSi Top Connection OTSi Photonic Link OTSi ODU OTSi Transitional Link OTSi Photonic Node ODU OTSi Transitional Link
Topology #3, #4 OTSi/Photonic Transponder / ODU switch Node DSR ODU 4 Top Connection ODU 2 Top Connection OTSi Link ROADM Node ODU 2 Transponder / OTSi switch Node ODU NMC Top Connection NMC OTSi NMC ODU 4 ODU Photonic Node NMC OTSi NMC OMS 1 Line Port OMS-O 1 1 OMS Link OMS OTS Add/Drop Port OTS Link ODU OTSi/PHTN Node (ILA) NMC OMS-O 1 OMS DSR/ ODU Node OTSi Node OTS OM S OTS Link OTSi/PHTN Node
CASE 2: 1 GE client signal over ODU 0 over ODU 2 over ODU 4 (Fixed DSR-ODU mapping, flexible ODU allocation)
Topology #1 CASE 2: 1 GE client signal over ODU 0 over ODU 2 over ODU 4 (Fixed DSR-ODU mapping, flexible ODU allocation) DSR Node ODU Node DSR/ODU Node x 10 11. D 1 20. D 1 DSR/ ODU switch Node 1 GE DSR 1 GE/DSR Top Connection 51. D 1 60. D 1 x 10 DSR/ ODU switch Node 1 GE DSR ODU 0 1 GE DSR • • Layer=ODU 0 Total Capacity=1 G Supported CTP Rates= ODU 0 Max # CTP instances=1 ODU ODU 4 Top Connection ODU 4 Transponder / ODU switch Node ODU • • • Pool = yes Layer=ODU 2 (TTP rate) Total Capacity=100 G Supported CTP Rates= ODU 0, ODU 1 Max # TTP instances=10 Max # CTP per TTP instances= 10, 4 ODU 21. D 1 30. D 1 x 10 • • • Pool = yes Layer=ODU 4 (TTP rate) Total Capacity=200 G Supported CTP Rates= ODU 2, ODU 2 e, ODU 3 Max # TTP instances=2 Max # CTP per TTP instances= 10, 4 ODU
ODU Node 11. D 1 20. D 1 DSR/ ODU switch Node 1 GE/DSR Top Connection DSR x 10 DSR/ ODU switch Node ODU 0 Top Connection ODU 0 ODU 2 Top Connection ODU 2 DSR ODU 2 ODU ODU 4 Top Connection ODU 4 ODU Transponder / ODU switch Node ODU Pool = yes Layer=ODU 2 (TTP rate) Total Capacity=100 G Supported CTP Rates= ODU 0, ODU 1 Max # TTP instances=10 Max # CTP per TTP instances= 10, 4 21. D 1 30. D 1 x 10 • • • 1 GE DSR ODU 0 ODU Layer=ODU 0 Total Capacity=1 G Supported CTP Rates= ODU 0 Max # CTP instances=1 51. D 1 60. D 1 1 GE DSR • • • DSR/ODU Node x 10 • • Topology #1 CASE 2: 1 GE client signal over ODU 0 over ODU 2 over ODU 4 (Fixed DSR-ODU mapping, flexible ODU allocation) DSR Node Pool = yes Layer=ODU 4 (TTP rate) Total Capacity=200 G Supported CTP Rates=ODU 2, ODU 2 e, ODU 3 Max # TTP instances=2 Max # CTP per TTP instances=10, 2 ODU
CASE 3: 1 GE client signal over ODU 0 over ODU 2 over ODU 4 (with intermediate ODU 0 switching)
Topology #1 DSR/ODU Flexible Structure DSR Node ODU Node x 10 51. D 1 60. D 1 51. D 1 ODU/DSR Node DSR/ ODU switch Node 1 GE Top Connection ODU 0 Top Connection 1 GE DSR DSR 1 GE ODU 0 ODU 2 Top Connection ODU ODU 0 ODU ODU 4 Top Connection ODU 2 ODU DSR/ ODU switch Node ODU 2 ODU 4 Top Connection ODU 4 ODU ODU DSR ODU 2 ODU 0 ODU 2 Top Connection ODU ODU 4 ODU DSR
Case 4: 10 GE client signal over ODU 2 over ODU 4 (Fixed DSR-ODU mapping, flexible ODU allocation) with intermediate transponder regeneration.
DSR Node Topology #1 DSR/ODU Flexible Structure ODU Node x 10 ODU/DSR Node 60. D 1 51. D 1 DSR/ ODU switch Node 1 GE ODU 2 ODU 4 Top Connection ODU 4 Link ODU ODU 4 ODU 1 GE DSR ODU/DSR Transponder Node ODU 51. D 1 60. D 1 DSR/ ODU switch Node 1 GE Top Connection ODU 2 Top Connection 1 GE DSR x 10 ODU 4 Top Connection ODU 4 Link ODU DSR
Case 5: 10 GE client signal over ODU 0 over ODU 2 over ODU 4 with Line Side OLP Protection
Topology #3, #4 OTSi/Photonic ODU 4 Top Connection ODU 2 Top Connection Transponder / ODU switch Node OTSi Top Connection ROADM Node DSR ODU 2 Transponder / OTSi switch Node NMC Top Connection - A NMC Top Connection - B OLP NODE ODU OTSi NMC 1 ODU 4 ODU NMC NMC 2 OTSi NMC 1 OMS NMC OMS Photonic Node NMC OMS-O 1 1 OMS Link OMS OTS Line Port Add/Drop Port ODU OTS Link NMC • • Swtich-control= yes selected-connection-end-point: NMC-1, NMC-2 selected-route: NMC Top Connection - A resilience-type: ONE_FOR_ONE_PROTECTION NMC NMC OMS-O OMS OTSi Node NMC OMS DSR/ ODU Node OTSi/PHTN Node (ILA) 1 Add/Drop Port 1 OMS OM S OTS OTS Link OTSi/PHTN Node
Use Cases
Use cases (I) • Discovery use cases: q Use case 0: Topology and services discovery. • Provisioning use cases: q q Use case 1: Unconstrained E 2 E Service Provisioning (Digital Signal Rate (DSR) Service i. e. , GE, 10 Gb. E, STM-X, fiberchannel…) Use case 2: Unconstrained with channel or slot selection • 2 a: OCH/OTSi (channel selection) • 2 b: ODU (time slot selection) Service Provisioning q Use case 3: Constrained service provisioning. • 3 a: Include/exclude a node or group of nodes. • 3 b: Include/exclude a link or group of links. • 3 c: Include/exclude the path used by other service. q Use case 4: Manual unconstrained E 2 E Service Provisioning. Step by step.
Use cases (II) • Resilience use cases: q Use case 5: 1+1 Diverse Service Provisioning for any of the previous cases (1, 2, 3 a, 3 b, 3 c, 4) • 5 a: 2 transponders (Y cable) • 5 b: OLP • 5 c: (e. SNCP) q Use case 6: Dynamic restoration for unconstrained and constrained use cases (1, 2, 3 a, 3 b, 3 c, 4) q Use case 7: Restoration and protection 1+1 for use cases (1, 2, 3 a, 3 b, 3 c, 4) q Use case 8: Permanent protection 1+1 for use cases (1, 2, 3 a, 3 b, 3 c, 4) q Use case 9: Reverted protection for use cases (5 a, 5 b, 5 c, 6, 7 and 8)
Use cases (III) • Service maintenance use cases: q Use case 10: Service deletion (applicable to all previous use cases) q Use case 11: Modification of service characteristics. • 11 a: Modification of service path • 11 b: Modification of service nominal path to secondary (protection) path for maintenance operations. (Only valid for resiliency use cases) • 11 c Modification or upgrade of service capacity. (Only valid for electrical services) • Planning use cases: q Use case 12: • 12 a: Pre-calculation of the optimum path (applicable to all previous use cases) • 12 b: Simultaneous pre-calculation of two disjoint paths. • 12 c: Multiple simultaneous path computation (Bulk request processing) • 12 d: Physical impairment validation of an pre-calculated Och trail path.
- Slides: 49