Implementation options for CCVPN E-LAN Services 

Service Creation

OPTION 1 (Service Decomposition in the Portal/UUI)

1. This is the current implementation for CCVPN P2P services in Casablanca
2. Service Decomposition happens in the Portal/UUI
   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
   2. In Casablanca, the UUI made separate calls to SO, i.e., did decomposition but without Service Orders

3. 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)

4. Service Instance relationships would need to be maintained in A&AI to relate to the one EP-LAN

OPTION 2 (Service Decomposition in the SO)

1. This is considered the ideal implementation
2. Service Decomposition happens in the SO
   1. The Portal makes a single Service Order via TMF 641, with one service orderItem for the composite EP-LAN Service

3. SDC can support Composite Services creation. SO can decompose and delegate the nested Services such as Access E-Line

4. Parameters for all services can be passed as one composite orderItem to External API. Then passed to SO as one Create E2EServiceInstance request. SO can then Create the connectivity services (UNIs, Access E-LAN, Access E-Line, ENNIs,…) from one parent Composite Service Specification

OPTION 3 (Service Decomposition in the External API)

1. This is considered the more realistic implementation
2. Service Decomposition happens in the External API framework

   1. The Portal makes one Service Order via TMF 641, with multiple service orderItem(s) for each of the services that make up EP-LAN Service

3. External API framework coordinates with SO for each orderItem

4. To remove the EP-LAN Service fully would involve the Portal making one Service Order with multiple orderItem(s), each with an action of ‘delete’

   1. i.e., there is no E2E Service Instance that corresponds to the full EP-LAN Service. Service Instance relationships would need to be maintained in A&AI to relate to the one EP-LAN

Service Modification

OPTION A (linked to Option 2 above)

Image Added

1. Service Change Decomposition in SO

2. SDC models LCM Operation/Interfaces for modifications allowed on a Service (such as AdjustBandwidth) so that the modification capability can be exposed through the Service Catalog

3. SO offers Service Modification API and associated workflows to interact with SDNC, A&AI & External API to make the required service adjustments

OPTION B (linked to Option 3 above)

Image Added

1. Service Change Decomposition in External API framework (there is no "real decomposition")

   1. Instead of a Service Change, External API will use SO to recreate the Service using SO Update E2EServiceInstance API

2. External API must be able to retrieve all existing Service Characteristics of the Service Instance from A&AI to use in the recreation of the Service plus with the modified CIR Characteristic

3. Service Change for the full EP-LAN has to be made separately to its composite Access E-LAN & E-LINE Services