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

2. 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.

3. Protection Use Cases Linear: OTN SNCP Media layer protection
Ethernet Ring Protection (?)
E2E and segment protection
Add/Remove Protection, Remove Keeping Spare
Operator Commands: Manual, Forced, Lockout
Modify Route
TMF MTNM modify SNC:
RouteList_T addedOrNewRoute: Depending on the modifyType, AddedOrNewRoute 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.
RouteList_T removedRoute: RemovedRoute 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 addedOrNewRoute only to reroute a segment.

4. Restoration Use Cases Segment Routing? Route* Management:
MTNM getRoute, switchRoute, add/removeRoute, setIntendedRoute
inUseBy: 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 FcRoute(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. ”
Will be replaced by “priority”, being the
intended Route the one with highest priority.
Core IM is “selectionPriority”.
string  id
intended
actualState
administrativeState
inUseBy
exclusive
Route_T 
routeXCs
globaldefs::NVSList_T 
additionalInfo

5. 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.
The Connection is the result of ConnectivityService intent – conceptually the “intended forwarding route” of a ConnectivityService.
A given Connection may be supported by various resiliency schemes, “parallel” and/or “consecutive” and/or “nested” etc. at the Connection layer.
The SwitchControl represents a resiliency (or only Protection) scheme, orchestrating a number of Switches.
The “intended route” is the route with highest priority. Relation with Traffic Engineering.
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.
The “resiliency route” of a Connection may be “shorter”, having a SwitchControl as its scope.
Connection may be associated to a SwitchControl in case it is required some abstract provisioning on whole Connection scope (e.g. just “switch to protection”).

6. Resiliency on Resources (1)
Resiliency is always and only provisioned through SwitchControl, both Protection and Restoration cases.
A Route is modeled as a set of CEPs (but PLANNED one). The following Route Types are foreseen:
INSTALLED (CEPs allocated to the Connection)
PLANNED (NEPs or Links, whose CEPs would be allocated to the Connection)
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
“Selected CEP” (or NEP for PLANNED) and “Selected Route” will include a “Priority” attribute
The “preferred” or “intended” Route is not explicitly modeled 2 1 1 3

7. Resiliency on Resources (2)1 1 1 1 3 3
Selected Route 2 2 1 1 1 1 3 3

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

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

10. 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

11. Resiliency on Resources (6)
Create SwitchControl:
Switch(es), hence including CEPs (or NEPs for PLANNED Routes) and their roles/selection priorities in the scheme
Technology independent & dependent parameters (e.g. “SNCP/I” or “restoration”, revertive, hold off time, etc.)
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 SwitchControl:
SwitchControl composes its Switches
Switch refers to CEPs
CEP belongs to a route of the Connection

12. Resiliency on Resources (7)
Create ConnectivityService:
endPoint
switchControl:
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
Technology independent & dependent parameters (e.g. “SNCP/I” or “restoration”, revertive, hold off time, etc.)

13. 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
SwitchControl
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. SwitchControl may be useful in case some switching decision can be taken locally.

14. Resiliency on Resources, solution B
Resiliency is always and only provisioned through Routes, both Protection and Restoration cases.
The SwitchControl and its Switch(es) are created as side effect
Create Route:
Technology independent & dependent parameters (e.g. “SNCP/I” or “restoration”, revertive, hold off time, etc.)
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.

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

16. SIP/CSEP or NEP/CEP (1)
Currently TAPI allows the provisioning of Connectivity Service and OAM Service on SIP/CSEP objects.
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. ODU4 Connectivity Service that supports ODU2 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.
Pros: the OAM and Resiliency provisioning capability is explicitly shown by Server.
Cons: proliferation of objects – same result can be achieved by an attribute/package (decoration) in NEP, like Supported CTP Rates etc.

17. SIP/CSEP or NEP/CEP (2)
SIP class remains dedicated only to Connectivity Services.
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)
Hence OAM and Resiliency can be provisioned on NEP exposing the related capability.
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.

18. Service and Resource distinct provisioning
Another approach is to split the provisioning:
“Service Provisioning”: Connectivity/OAM/Resiliency on SIP/CSEP
ConnectivityService, OamService, ResiliencyService
“Resource Provisioning”: Connectivity/OAM/Resiliency on NEP/CEP
ConnectionMaintenance, OamMaintenance, ResiliencyMaintenance
Simplification (similar result of previous slide):
ConnectivityIntent, OamIntent, ResiliencyIntent on either SIP/CSEP or NEP/CEP
Is it necessary/convenient to separate ConnectivityService 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. TapiConnectivity - Resilience

20. Core IM (1) C&SC encapsulated in a FcSwitch C&SC encapsulated in an FC
C&SC encapsulated in a C&SC
C&SC encapsulated in an LTP
C&SC stand-alone
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
There may be a hierarchy/mesh of C&SCs where a C&SC may govern others and may itself be governed
The C&SC may create/delete/adjust FCs as well as activate switches

21. 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 (FcRoute) 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 FcHasLowerLeverFcs association). There are cases where a route is the most appropriate representation and cases where the aggregation approach is the most appropriate representation.

22. Core IM (3)
If selection priority of an FcPort is increased in value and the FC is currently selecting this FcPort then if another FcPort of a lower selection priority value is available, the wait to restore process will come into action as if the other FcPort had just become available. If selection priority of a FcPort is changed and the FC is not currently selecting this FcPort but is selecting an item that is now of a higher numeric value than the changed FcPort then the wait to restore process will come into action as if the other FcPort 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.
ForwardingConstruct attribute (but not of FcRoute):
isProtectionLockOut: 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.
servicePriority: 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.

23. Core IM (4) 3.4.9 FcRoute 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 FcHasLowerLevelFcs association where each FC exists in an FD/Link. The aggregation may be:
Single layer
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 FcRoute 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 FcRoute 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.

24. Core IM (5) The LifecycleState of an FcRoute 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 FcRoute is INSTALLED and the intention is to remove the FcRoute
“It is not meaningful to express in the Link the type of scheme used in the underlying network“

25. Core IM (6)

26. Core IM (7) TR-512.5_OnfCoreIm-Resilience
Figure 3-2 Instance diagram key

27. ITU-T G (10/2017)