Change service API Orange Team Targeted for Dublin

Change ‘service’ API Orange Team Targeted for Dublin

Challenge 1. When BSS triggers an order to ONAP to modify an existing service, if the modification request is ‘valid’, it must be applied [Legato] 2. When self-care or another-SP system request a modification to existing service it could be managed: 3. Through a product. Order request (then not a service level message but a product level message) [Sonata] that will be managed in the BSS and them an service. Order will be triggered (bullet point 1) 4. Through a direct service request [Allegro] or [Interlude] but in this case the BSS is not ‘checked’ for any impact (product inventory, product offering definition, billing). From ONAP perspective we should be able to distinguish request from 1. from the ones coming from 4. This will bring flexibility for implementation to define API use depending on UC. 2

Proposition • • • Add an alternative way (<> service. Order) to modify an existing service (only characteristic value for first release) These operations must be ‘extra’ controlled in this context (all service modifications defined in SDC are authorized through TMF 641, only a subset of them are permitted with this alternative way) - By assumption these operations will not be ‘controlled’ at BSS level Provide a mechanism to monitor & track service change Examples: Change service characteristics value for a v. Box: activate /deactivate Web. Content. Filtering, Anti. Spam, Antimalware, etc. . Change Bandwidth for an access E-Line UC: Selfcare Inter. SP UC for elastic bandwidth UC 3 Service. Order service operations scope add e remov change Service. Order change operations scope API service change operations scope

Solution • Bring to external AP a new API based on TMF 640 Activation & Configuration. But will be enhanced with TMF latest API improvement (aligned with TMF guideline 3. 1) • Only operation PATCH service will be provided to modifying existing service (we do not plan to provide capability to create/terminate service through this API in this release) • Only a subset on characteristic could be handled through this operation (we do not in this version plan to restrict characteristic value scope … a characteristic is updatable or not …but this enhancement could be in the backlog) • Leveraging existing API service Inventory code to retrieve service in the inventory (GET service) • A resource Monitor will be managed to allow service modification monitoring + traceability. The response of the operation can be sent back synchronously or not, in this case a “monitor” resource hyperlink is given in the response Note: we do not provide any authorization mechanism to check if API user is allowed to perform this modification. 4

Prerequisite SDC or Policy or …Ext. API ? : Provide a way to describe operations authorized at this service level: à List of characteristics allowed to be modified (use of parameter annotation https: //wiki. onap. org/display/DW/4. 3. 7. +Annotation+Types#id-4. 3. 7. Annotation. Types 1. 1. 1. 3. 2 Parameter. Definition see§ 1. 1. 1. 3. 2) Ext API: Add a new API to allow direct service modification (PATCH & GET Service + GET Monitor) Add a new DB to store Monitor Need upgrade: (Mandatory) In AIA to get all characteristics valued when service is retrieved (as of today characteristics are not retrieved) In SO to have an API to perform a service change (and avoid the delete/recreate). The new API can work in a first release with delete/recreate 5

Stretch Goal API service. Catalog is improved to display authorized operation at service level (flag to identify characteristic updateable through this new API). Add notification on the Monitor Resource. Expand API scope to allow state change (only suspend/activate for example). Backlog Enhance modification authorization scope at characteristic value Expand API at resource level (VNF) 6

TMF 641 POST Service. Order (TMF 641) As of now, NBI offers a service. Order API to request add, remove or change operation on service. This operation are assessed with current SDC information (service. Spec exists, characteristics checks) LEG stan ATO dard way External API DESIGN-TIME Service Design & Creation 7 Interne Orange RUN-TIME Service Orchestrator Active & Available Inventory

Alternate proposition The evolution will open an alternative way to request service change. This request will assessed with SDC but also additional check for specific activation & configuration operation should be possible For Inte r Alle lude & gro PATCH Service (proposition: motorize through TMF 640) External API DESIGN-TIME Service Design & Creation + Policy for update 8 Interne Orange RUN-TIME Service Orchestrator Active & Available Inventory

Thanks