OIF Demo Issue #2 - Controller Abstraction

Issue Title : Controllers abstract the network in different ways Description

Different controllers abstract the network in different ways. As a result, the information available to the Orchestrator is different, meaning the information the Orchestrator needs to provide to the controller when performing service establishment can be different per domain. Discussion = The ONF’s SDN architecture expects controllers will utilize different abstractions when representing the real topology being controlled. This is necessary as 1) business requirements may require information hiding, 2) the underlying technology being used within the controller’s domain may be unsupported by the upper controller/orchestrator. However, it is important for the information required by the controller to be clear to the upper controller/orchestrator. For example, if a controller is expecting the orchestrator to request services using bi-directional links, the controller may reject a request that specifies two uni-directional links instead. A mechanism may need to be provided so the upper controller/orchestrator may identify the abstraction schema being used/ to be used by the controller. Resolution (Demo)
Handled on a case-by-case basis between orchestrator and controller. Resolution (Long Term)
Possibly include more example abstractions in the specification documents.
- provide some formal names for different types of abstractions? e.g. single node domain, domain with topology (e.g., ROADMs), components (e.g., ROADM degrees) - indicate if domain uses control plane? note this was done in MTNM for operations purposes
- issue of impact on notification – topology abstraction may impact scalability of notification, e.g., controller could notify on service basis rather than topology element - views that this is natural - open for contribution – some views that this is not relevant to TAPI

Open-Network-Models-and-Interfaces-ONMI / TAPI

OIF Demo Issue #2 - Controller Abstraction #343