Versions Compared

Old Version 5

changes.mady.by.user Davide Cherubini

Saved on

compared with

New Version 6

changes.mady.by.user Davide Cherubini

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 (Service Decomposition in the Portal/UUI)

Image Removed

  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)

Image Removed

  • This is considered the ideal implementation
  • 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

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

    • 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