Versions Compared

Old Version 1

changes.mady.by.user Davide Cherubini

Saved on

compared with

New Version 2

changes.mady.by.user Davide Cherubini

Saved on

Key

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

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)

Image Added

  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