•Service Instance relationships would need to be maintained in A&AI to relate to the one EP-LAN.This is the current implementation for CCVPN P2P services in Casablanca Service Decomposition happens in the Portal/UUI
The CCVPN E-LAN Service Use Case will impact each of the Projects listed on this page.
Options for CCVPN E-LAN Services
Service Creation
OPTION 1
- Multiple Service Orders (ideally via TMF 641 if from external BSS portal), with 1 service orderItem for each of the services that make up EP-LAN Service
- In Casablanca, the UUI made separate calls to SO, i.e., did decomposition but without Service Orders
To remove the EP-LAN Service fully would involve the Portal making multiple separate Service Orders with one orderItem, each with an action of ‘delete’ ( i.e. there is no E2E Service Instance that corresponds to the full EP-LAN Service)
Depending on the chosen implementation Option (listed here), impact will be different. Listed impacts refer to Option 2 for Service Creation and Option A for Service Modification
AAI
- Support Composite Service Instances (multi-operator)
DCAE
Performance management - Stretched GOAL - POSTPONED TO R5
OOF
- TBC
SDN-C
- TBC
Modeling
- Need to support Composite Services
SDC
- Support Composite Services creation
- Must be able to model LCM operations/Interfaces and expose the modification capabilities through the Service Catalog
External API
- Implement TMF 641 for external BSS Portal (parameters passed as one composite/single orerItem)
- implement East-West cross-operator External API-External API ("patch service" for service modification)
SO
- Implement ability to "decompose" the End-to-End service (in collaboration with SDC). The same applies for the Service Change.
- Implement Service Modification API and associated workflows to interact with other projects (SDN-C, A&AI & ExtAPI)