Service and Resource Resiliency Andrea Mazzini Nokia September

Service and Resource Resiliency Andrea Mazzini, Nokia September 10, 2019

Purpose of this contribution • This contribution considers some common protections and restoration scenarios, from TMF MTNM and ONF Core IM, for both Service and Resource management. • The idea is to enhance TAPI for the management of more common/simple schemes – where interoperability is more likely to occur.

Protection Use Cases • Linear: o OTN SNCP o Media layer protection Ethernet Ring Protection (? ) • • E 2 E and segment protection Add/Remove Protection, Remove Keeping Spare Operator Commands: Manual, Forced, Lockout Modify Route • TMF MTNM modify SNC: Route. List_T added. Or. New. Route: Depending on the modify. Type, Added. Or. New. Route describes the route of a new protection leg or the whole SNC. When it describes a segment to be added, either the SNCP cross-connects or the switch TPs that will be changed in the segment may be specified by the NMS. The EMS then chooses the missing segments. Alternatively, the NMS may specify the full route. Route. List_T removed. Route: Removed. Route describes dropping of a protection leg from the original SNC. Either the last cross-connects (that contain the SNCP) are specified by the NMS or the full route may be specified. This parameter can be used in conjunction with added. Or. New. Route only to reroute a segment.

Restoration Use Cases • Segment Routing? • Route* Management: o MTNM get. Route, switch. Route, add/remove. Route, set. Intended. Route string id string intended string actual. State string administrative. State string in. Use. By string exclusive Route_T route. XCs globaldefs: : NVSList_T additional. Info Will be replaced by “priority”, being the intended Route the one with highest priority. Core IM is “selection. Priority”. o in. Use. By: With value "y" if at least one of its XCs or CTPs is carrying traffic of another SNC, "n" otherwise. (*) Core IM, the C&SC governs FC(s), there is no direct relationship with Fc. Route(s) “[C&SC] represents the capability to control and coordinate switches, to add/delete/modify FCs and to add/delete/modify LTPs/LPs so as to realize a protection scheme. ”

Resiliency on Resources (1) • • Protection Schemes are focused on Switches Restoration Schemes are focused on Routes • TAPI: need to consider exact management purpose of Connection and Route wrt resiliency. o The Connection is the result of Connectivity. Service intent – conceptually the “intended forwarding route” of a Connectivity. Service. o A given Connection may be supported by various resiliency schemes, “parallel” and/or “consecutive” and/or “nested” etc. at the Connection layer. o The Switch. Control represents a resiliency (or only Protection) scheme, orchestrating a number of Switches. o The “intended route” is the route with highest priority. Relation with Traffic Engineering. o The “forwarding route” of a Connection always covers the whole Connection scope (i. e. the Node). Relation with Traffic Engineering. § A Connection has one and only one “forwarding route”. It is independent from resiliency. o The “resiliency route” of a Connection may be “shorter”, having a Switch. Control as its scope. § Connection may be associated to a Switch. Control in case it is required some abstract provisioning on whole Connection scope (e. g. just “switch to protection”).

Resiliency on Resources (1) • • • Resiliency is always and only provisioned through Switch. Control, both Protection and Restoration cases. A Route is modeled as a set of CEPs (but PLANNED one). The following Route Types are foreseen: 1. INSTALLED (CEPs allocated to the Connection) 2. PLANNED (NEPs or Links, whose CEPs would be allocated to the Connection) 3. POTENTIAL (CEPs allocated but not assigned to the Connection) § The CURRENT route is the list of CEPs involved in the Connection flow, subset or equal to an INSTALLED route. The priority of a Route is modeled by the Switch potentially selecting it o “Selected CEP” (or NEP for PLANNED) and “Selected Route” will include a “Priority” attribute o The “preferred” or “intended” Route is not explicitly modeled 2 3 1 1 0

Resiliency on Resources (2) 2 2 1 0 0 1 1 1 3 3 Selected Route 2 2 1 1 3 0 0 1 1 3

Resiliency on Resources (3) • The routes of a Connection which is SNCP & restoration protected: Grey, red, blue: resources are exclusively allocated, e. g. INSTALLED. MTNM: together formed the unique route of SNC Black: Intended/ Highest prio Switch. Control Green: pre-calculated, e. g. PLANNED or POTENTIAL Black: the INSTALLED route. Green: PLANNED or POTENTIAL route.

Resiliency on Resources (4) Possible CURRENT routes If green is CURRENT route, it is also INSTALLED Black: the INSTALLED route.

Resiliency on Resources (5) • The routes of a Connection which is restoration protected: Black: the INSTALLED route. Green: PLANNED or POTENTIAL route. (In case there is not protection) the highest priority route may become PLANNED or POTENTIAL when not selected

Resiliency on Resources (6) • Create Switch. Control: 1. Switch(es), hence including CEPs (or NEPs for PLANNED Routes) and their roles/selection priorities in the scheme 2. Technology independent & dependent parameters (e. g. “SNCP/I” or “restoration”, revertive, hold off time, etc. ) 3. Resiliency Routes, specified with more or less details § Similar parameters as Connectivity Service creation, but with “reliable” CEPs as end points (or NEPs for PLANNED Routes) § Type: INSTALLED/POTENTIAL/PLANNED Apparently there is no need of direct relationship between Connection and Switch. Control: • Switch. Control composes its Switches • Switch refers to CEPs • CEP belongs to a route of the Connection

Resiliency on Resources (7) • Create Connectivity. Service: 1. end. Point 2. switch. Control: a) Resiliency Route(s), specified with more or less details § Similar parameters as Connectivity Service creation, but with reliable NEPs as end points (bw and layer protocol info already provided in CSEPs) (Note that NEPs may be also internal, infrastructure trail cases) § Priority (will be represented in Switches) § Type: INSTALLED/POTENTIAL/PLANNED b) Technology independent & dependent parameters (e. g. “SNCP/I” or “restoration”, revertive, hold off time, etc. )

Resiliency on Resources (8) • Three and four ended schemes: Black, red: resources are exclusively allocated, e. g. INSTALLED. MTNM: together formed the unique route of SNC Black: Intended/ Highest prio Switch without “reliable” CEP Switch. Control Four ended case, where the controller is aware or unaware (e. g. just routing diversity) that two distinct connectivities are part of a wider protection scheme. Switch. Control may be useful in case some switching decision can be taken locally.

Resiliency on Resources, solution B • Resiliency is always and only provisioned through Routes, both Protection and Restoration cases. o The Switch. Control and its Switch(es) are created as side effect • Create Route: 1. Technology independent & dependent parameters (e. g. “SNCP/I” or “restoration”, revertive, hold off time, etc. ) 2. Resiliency Route, specified with more or less details § Similar parameters as Connectivity Service creation, but with “reliable” CEPs or NEPs as end points § Priority § Type: INSTALLED/POTENTIAL/PLANNED The above listed parameters 1, 2 can be specified at Connectivity Service creation.

Abstraction levels • As a first step, it is possible to define only the two “extreme” provisioning scenarios: o Resiliency. Service, i. e. some simple parameters like SLS to drive possible implementation of protection/restoration schemes, which choice is essentially delegated to agent o Resiliency. Maintenance, i. e. full detail on lowest available partitioning level

SIP/CSEP or NEP/CEP (1) • Currently TAPI allows the provisioning of Connectivity Service and OAM Service on SIP/CSEP objects. o Note that in multi-layer connectivity model, SIPs may be available also on INNI (or even on internal NEP) side, for the provisioning of “infrastructure” Connectivity Services, driving the implementation of “trail” Connections which will support client connectivities (e. g. ODU 4 Connectivity Service that supports ODU 2 or DSR etc. clients). § Hence today is possible to provision OAM also on “infrastructure” Connectivity Service scope. § Note that from MEF perspective, OAM is applied only to “UNI to UNI” or “UNI to ENNI” Services. • Currently it is not possible to provision OAM between generic CEPs, unless we introduce the “OAM SIP”, somehow similar to the “Infrastructure Connectivity SIP”. • SIP may become a decorator class of NEP. Check cardinalities. • In this light, we can also introduce the “Resiliency SIP”, allowing the provisioning of protection/restoration schemes between NNIs. o Pros: the OAM and Resiliency provisioning capability is explicitly shown by Server. o Cons: proliferation of objects – same result can be achieved by an attribute/package (decoration) in NEP, like Supported CTP Rates etc.

SIP/CSEP or NEP/CEP (2) • SIP class remains dedicated only to Connectivity Services. o This introduces a hierarchy, but it is true that OAM and Resiliency applies only to Connectivity Service § Plus in future other “non connectivity” Services • OAM and Resiliency are more on “resource” side (cause-effect, the requirement is the control) o Hence OAM and Resiliency can be provisioned on NEP exposing the related capability. o In other words, no abstraction applies to OAM/Resiliency • This does not prevent adding abstract OAM/Resiliency parameters to Connectivity Service, e. g. SLS, its fulfilment state, some generic/summary PM parameters, etc.

Service and Resource distinct provisioning • Another approach is to split the provisioning: o “Service Provisioning”: Connectivity/OAM/Resiliency on SIP/CSEP § Connectivity. Service, Oam. Service, Resiliency. Service o “Resource Provisioning”: Connectivity/OAM/Resiliency on NEP/CEP § Connection. Maintenance, Oam. Maintenance, Resiliency. Maintenance • Simplification (similar result of previous slide): o Connectivity. Intent, Oam. Intent, Resiliency. Intent on either SIP/CSEP or NEP/CEP • Is it necessary/convenient to separate Connectivity. Service and Connection provisioning? • The provisioning of Service Resiliency should focus on SLA/SLS, delegating to the Server the choice of more appropriate protection/restoration scheme. • The provisioning of Resource Resiliency implies details of protection/restoration scheme and operator commands.

19 Tapi. Connectivity - Resilience

Core IM (1) • • • C&SC encapsulated in a Fc. Switch C&SC encapsulated in an FC C&SC encapsulated in an LTP C&SC stand-alone o Used where the C&SC coordinates switches and other configuration spread across multiple FCs etc. § In this case it replaces the traditional protection group approach o There may be a hierarchy/mesh of C&SCs where a C&SC may govern others and may itself be governed o The C&SC may create/delete/adjust FCs as well as activate switches

Core IM (2) • Protection: A resilience mechanism where the resources used to achieve resilience against failure are in place and running ready to be selected so as to rapidly recover the service. The resources may be shared by several services such that under certain failure conditions one service may take the resilience resources from another causing the other to fail. • Restoration: A resilience mechanism where there are no additional resources over and above those needed to provide the capability in place and running but there is either a plan for resources to be used and/or there is a control capability that can determine which resources can be used to recover a failed service. • Each instance of an FC Route (Fc. Route) class models an individual route of an FC. The route is an alternative view of the internal structure of the FC to FC aggregation (see Fc. Has. Lower. Lever. Fcs association). There are cases where a route is the most appropriate representation and cases where the aggregation approach is the most appropriate representation.

Core IM (3) • If selection priority of an Fc. Port is increased in value and the FC is currently selecting this Fc. Port then if another Fc. Port of a lower selection priority value is available, the wait to restore process will come into action as if the other Fc. Port had just become available. If selection priority of a Fc. Port is changed and the FC is not currently selecting this Fc. Port but is selecting an item that is now of a higher numeric value than the changed Fc. Port then the wait to restore process will come into action as if the other Fc. Port had just become available. • If selection priority of a Route is increased in value and the Route is currently selecting this Route, then if another Route of a lower selection priority value is available the wait to restore process will come into action as if the other Route had just become available. If selection priority of a Route is changed and the FC is not currently selecting this Route but is selecting an item that is now of a higher numeric value than the changed Route, then the wait to restore process will come into action as if the other Route had just become available. • Forwarding. Construct attribute (but not of Fc. Route): • is. Protection. Lock. Out: The resource is configured to temporarily not be available for use in the protection scheme(s) it is part of. This overrides all other protection control states including forced. If the item is locked out then it cannot be used under any circumstances. Note: Only relevant when part of a protection scheme. • service. Priority: Relevant where "service" FCs are competing for server resources. Used to determine which signal FC is allocated resource. The priority of the "service" with respect to other "services". Lower numeric value means higher priority. Covers cases such as pre-emptible in a resilience solution.

Core IM (4) 3. 4. 9 Fc. Route has FCs and/or Links There are two methods of describing the forwarding resources used by an FC to achieve forwarding across the network: • Direct aggregation of FCs via Fc. Has. Lower. Level. Fcs association where each FC exists in an FD/Link. The aggregation may be: o Single layer o Multiple layer where some of the FCs represent "Trails“ • Indirect aggregation of FCs and/or Links via the Route. Where the route is described by FC those FCs need not exist in an FD but instead may stand-alone describing some arbitrary fragment of the flow. The Fc. Route has several potential uses: • As part of the constraint model related to routing an FC • As a description of future alternative ways through the network to cover variability in the service need or some other where only one is active at any one time (as depicted above) • To represent each of a number of alternative ways through the network for a particular FC to provide resilience • As a description of the current way through the network for a particular FC (current route) The key focus in this document is the use of Fc. Route for resilience. The actual instantiated active route across the network, i. e. the actual configuration of the real devices, must necessarily be fully detailed (otherwise information could not flow). But the definition of the desired route can be just a set of constraints that the actual route simply needs to satisfy. Similarly the alternative routes may be simply constraints.

Core IM (5) The Lifecycle. State of an Fc. Route is: • PLANNED: If the resources are not present in the network • POTENTIAL_BUSY: If the resources are present in the network but are shared with other FCs and are currently used by those FCs • POTENTIAL_AVAILABLE: If the resources are present in the network and are shared with other FCs but are not currently used by any FCs • INSTALLED: If the resources are present and allocated to this FC (whether shared or not) • PENDING_REMOVAL: If the Fc. Route is INSTALLED and the intention is to remove the Fc. Route “It is not meaningful to express in the Link the type of scheme used in the underlying network“

Core IM (6)

TR-512. 5_Onf. Core. Im-Resilience Figure 3 -2 Instance diagram key Core IM (7)

ITU-T G. 873. 1 (10/2017)