Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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


  • No labels