1. Service and Resource Resiliency
Andrea Mazzini, Nokia
October 1, 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.
Results from September f2f discussions
Focus is on connection-oriented forwarding technologies.

3. Protection Use Cases Linear: E.g. OTN SNCP Media layer protection
Ethernet Ring Protection: for further evaluation
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. ”
Intelligence is in the SwitchControl and Switch.
Hence move “priority” attribute to Switch ports.
The Route is a path in the network, does not
have inherent priority.
string  id
intended
actualState
administrativeState
inUseBy
exclusive
Route_T 
routeXCs
globaldefs::NVSList_T 
additionalInfo

5. Resiliency on Resources (1)
Resiliency is always and only provisioned through SwitchControl, both Protection and Restoration cases.
An INSTALLED Route is modeled as a set of connected CEPs
The CURRENT Route is (a part of) an INSTALLED Route where traffic is flowing (according to system best knowledge)
A NOT INSTALLED Route is modeled similarly to a Connectivity Service, i.e. it is an intent for a Route.
At least the ending (reliable) CEPs, plus more details / constraints in case
The “priority of a Route” is modeled by the Switch potentially selecting it
“Selectable CEP” and “Selectable Route” will include a “Priority” attribute
The “preferred” or “intended” Route is not explicitly modeled
Selectable CEP 2 1 1 3
Selectable Route (?)

6. Resiliency on Resources (2)
Selectable CEP 2 2 1 1 1 1 3 3
Selected CEP
Installed Route
Current Route
Not Installed Route
There is only one Installed Route of the SwitchControl 2 2 1 1 1 1 3 3

7. 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. NOT INSTALLED
Switch
SwitchControl
Black:
the INSTALLED route.
Green: NOT INSTALLED route.

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

9. Resiliency on Resources (4.1)
2-ended Connection in Node
3-ended Connection in Node

10. Resiliency on Resources (4.2)
2-ended Connection in Node
SwitchControl always spans one Connection: it is possible to protect/unprotect a whole Connection only.
2-ended Connection in Node

11. Resiliency on Resources (4.3)
SwitchControl becomes an ancillary class of Connection
Node becomes the scope of Resiliency features
Nodes are defined to model connectivity capability (aka subnetworks)
Note the Infrastructure Connections in multi-layer Nodes
Protection Route could not exit the Connection’s Node

12. Resiliency on Resources (4.4)
SwitchControl
2-ended Connection in Node
Node becomes the scope of Resiliency features: segment protection example

13. Resiliency on Resources (4.5) – option 1
SwitchControl
2-ended Connection in Node
Installed Route #1 - Current
Installed Route #2

14. Resiliency on Resources (4.6) – option 2
SwitchControl
2-ended Connection in Node
Installed Route #1 - Current
Installed Route #3 - Current
Routes in the scope of SwitchControl
Installed Route #2

15. Resiliency on Resources (5)
Selectable CEP 2 2 1 1 1 1 3 3
Selected CEP
Installed Routes
Installed & Current Route
Not Installed Route 2 2 1 1 1 1 3 3

16. Resiliency on Resources (5.1)
Installed Route #1
Shall Route description include reliable CEPs?
Installed Route #2
Current
Installed Route #3
2-ended Connection in Node

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

18. Resiliency on Resources (6)
Create SwitchControl:
Switch(es), hence including CEPs 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, with “reliable” CEPs as end points
Type: INSTALLED/NOT INSTALLED
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

19. 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/NOT INSTALLED
Technology independent & dependent parameters (e.g. “SNCP/I” or “restoration”, revertive, hold off time, etc.)

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

21. 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/NOT INSTALLED
The above listed parameters 1, 2 can be specified at Connectivity Service creation.
Solution B seems essentially redundant wrt SwitchControl provisioning

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

23. Resiliency on Segments (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.

24. Resiliency on Segments(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.

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

26. TapiConnectivity - Resilience

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

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

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

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

31. 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“

32. Core IM (6)

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

34. ITU-T G (10/2017)