Versions Compared

Old Version 4

changes.mady.by.user Davide Cherubini

Saved on

compared with

New Version Current

changes.mady.by.user Davide Cherubini

Saved on

Key

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

•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

•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

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

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

    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

    1. 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

    1. Support Composite Services creation
    2. Must be able to model LCM operations/Interfaces and expose the modification capabilities through the Service Catalog

    External API

    1. Implement TMF 641 for external BSS Portal (parameters passed as one composite/single orerItem)
    2. implement East-West cross-operator  External API-External API ("patch service" for service modification)

    SO

    1. Implement ability to "decompose" the End-to-End service (in collaboration with SDC). The same applies for the Service Change. 
    2. Implement Service Modification API and associated workflows to interact with other projects (SDN-C, A&AI & ExtAPI)