Open APIs

 View Only
Expand all | Collapse all

TMF641 - change service relationship (also TMF622)

  • 1.  TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 02, 2021 13:18
    Hi all,

    I don't find any topic on this from the past so I could imagine this situation it is not that common. Let's dive into the point.

    We are working on a TMF compliant SOM layer where TMF641 is our main entry door for CFS ordering. The API definition is quite clear when we talk about handling a service (add/modify/delete) but I am seeing some challenges when dealing with changes on a service relationship. The same occurs at Product level with TMF622.
    The current question I have is about how could we modify a specific CFS to remove a specific relationship to other service that is no longer applicable. I will give two examples.

    In a first instance, imagine a VPN Connectivity CFS that relates (reliesOn) with multiple Access CFS. Later after activation, we wanted to update the VPN Connectivity CFS to remove one of the relationships that it has with a specific Access CFS. How could this be done via TMF641 POST with the given VPN Connectivity CFS with action MODIFY? Note that it is expected to not send a full desired picture of a service when the action is MODIFY but just specify what really is requested for change.

    When we look to TMF622, the same issue can occur. We could take a look on the E-Tree service from MEF and how it is expected to be ordered at Product level. There would be an EVC Product Item that can rely in innumerous UNI's Product Items. Later on, I could imagine the customer to call TMF622 to remove one of the UNI's. Of course that, if a Product/Service Order MODIFY action includes always all the needed relationships, we would have a solution but, there should be a simpler way to manage this.

    Wouldn't be acceptable that we include in the TMF641 API an Action attribute at itemRelationship or serviceRelationship? I think it would solve this issue.

    Regards

    ------------------------------
    Carlos Portela
    Prodapt Solutions
    ------------------------------


  • 2.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 04, 2021 01:32
    Hi Carlos

    I understand the challenge you are describing.
    We have an action attribute at the OrderItem level, which could be used, perhaps, to say that the embedded Product or Service payload implies adding/changing/removing a relationship.

    I would be reluctant to add the action attribute at the Product (or Service) level (e.g. the Relationship classes), since these classes model the state of the inventory, and action is out of context there. But the whole topic needs more thought, let's see if @Ludovic Robert or @Kamal Maghsoudlou or @Johanne Mayer have any thoughts on this.

    ​​​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 3.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 04, 2021 18:02
    Edited by Carlos Portela Jul 04, 2021 18:23
    Hi Jonathan,

    Indeed, that's in fact what I was thinking. Note that the relationship classes "serviceOrderItemRelationship" and "productOrderItemRelationship" do not belong to the inventories class model but only to the order ones. I think it would be best that we play with this class and re-use the same attribute action there. 

    We could imagine an order mockup like this:
    • orderItem 1 
      • action: modify
      • serviceId: (vpnConnectivity instance id)
      • orderItemRelationship
        • itemId: 2
        • action: delete
    • orderItem 2
      • action: noChange
      • serviceId: (access instance id)

    Look forward to hearing some feedback from the collaborators you mention.

    Thanks for your help


    ------------------------------
    Carlos Portela
    Prodapt Solutions
    ------------------------------



  • 4.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 02:44
    Hello Carlos, Jonathan,

    Is there issues Carlos, preventing you to pass the complete 'wished' Service (or Product) representation in the order ? As the order is intend-base (describe what you want), I'm a bit like Jonathan and uncomfortable to modify the service/product representation part in the order.

    I understood passing the complete representation requires server side to make a comparison between 'inventory' view and 'order' view but seems to be a very robust way to manage all modification UCs.

    Thanks
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 5.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 06:43
    Edited by Carlos Portela Jul 05, 2021 07:00
    Ludovic, 

    I think it will be complex to manage BSS/OSS and B2B integration if we always pass the complete Service/Product representation in an order because we could foresee that two different northbound systems are working on the same Service/Product instance. Also, I think it should be possible to have an order that includes only the desired attributes to be changed on a service and not the entire view of the service.

    The main challenges I see if we dont support this kind of use-case will occur when two northbound systems using the same service. Imagine that you have a COM system consuming TMF641 from SOM and also a self-service GUI directly on SOM system where the customer can configure some characteristics or add other non-billable services directly in SOM. Also, it will be very complex to manage MEF SONATA and MEF INTERLUDE in parallel if we do not support this use-case. Sometimes, a BSS system does not need to know about all the CFS configuration.. 

    I think it will be more difficult to ensure such consistency on the order if we always need to pass the complete service/product setup when we need to do a change. It means that the Order API consumer will need to use TMF638/637 in advance every time a change is needed.

    Hope this helps to explain such complexity

    (and note that we would not need to modify service/product representation part in an order but just add an attribute, being action, in the order specific "orderItemRelationship" object)

    ------------------------------
    Carlos Portela
    Prodapt Solutions
    ------------------------------



  • 6.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 02:46
    Hi Carlos
    I was referring to the ProductRelationship / ServiceRelationship entities, since these are what reflect the relationship in the inventory after the orders are done and dusted.
    It's not obvious that there is a direct connection/relation between the orderItemRelationship at order time and product/service relationship.
    Let's wait to see what my colleagues have to say on this.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 7.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 05:25
    Hi Carlos,

    I believe in your case, the customer is trying to disconnect one of its sites (fully or partially) when they are sending the Delete UNI Order. In such cases, do you just want to delete the relationship of the UNI CFS with the EVC CFS or you would want to disconnect the UNI CFS as well? Even if the underlying connectivity that is enabling the UNI CFS may be maintained from CSP perspective, the actual UNI CFS would need to be disconnected in my opinion. What is the use case where you would just want to remove the relationship between UNI CFS and EVC CFS but keep the UNI CFS intact?

    Regards

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation
    ------------------------------



  • 8.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 06:30
    Edited by Carlos Portela Jul 05, 2021 07:04
    Hello Kinshuk,

    Thanks for your reply. In fact, if we look to MEF definition, and to many CSP use-cases, we should be able to support multiple connectivity services on top of a single phyisical line. Note that the relationship is the other way around, EVC/OVC reliesOn UNI, and we need to delete this relationship on the EVC/OVC product.

    In MEF, the use case could be the following:
    - EVC 1 with 300 UNI's, being UNI B one of them
    - EVC 2 with 100 UNI's, being UNI B one of them
    - OVC 3 with 1 UNI, being UNI B one of them
    It means that the three products (EVC 1, 2 AND OVC 3) would rely on the same UNI B product.
    Now, the customer/partner is interested to remove EVC 1 connectivity only from UNI B product but still keep the other two connectivity products up & running (EVC 2 and OVC 3) on this UNI. To make it clear, the EVC 1 would keep only 299 UNI's after such request.

    The question is: how could we do it without sending the "full install-base setup" in the order to avoid such complexity?

    ------------------------------
    Carlos Portela
    Prodapt Solutions
    ------------------------------



  • 9.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 08:30
    Hi Carlos,

    Thanks for your reply. In your case, since UNI B is part of 3 Services (2EVCs and 1 OVC), I assume that each of these EVCs and OVC will be consuming a portion of the UNI based on the bandwidth of the provisioned EVC/OVC at that endpoint. Is that correct? Are you assigning different VLANs in the UNI for each EVC/OVC?

    Regards,
    Kinshuk

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation
    ------------------------------



  • 10.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 09:05
    Edited by Carlos Portela Jul 05, 2021 09:06
    Kinshuk,

    Indeed you are right. In the UNI characteristics, as per defined by MEF, you can set its global bandwidth and the maximum of EVC/OVC end-points you want to support on this product. When a new EVC/OVC is created for a UNI, we need to validate that the requested VLAN or VLAN range (in EVC/OVC characteristics) is available on this specific UNI and can be used for such L2 connectivity. 

    Regards

    ------------------------------
    Carlos Portela
    Prodapt Solutions
    ------------------------------



  • 11.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 05, 2021 09:43

    Hi Carlos,

    Thanks for the clarification. I think the order that this customer is submitting is removing the EVC Endpoint and not really removing a UNI altogether. I would assume that you already has EVC Endpoint Product and CFS as well. 

    In such case, the Order that is sent should have 2 Order Lines

    1. EVC (Modify) - Because when an EVC Endpoint is removed, the EVC also needs to be updated
    2. EVC Endpoint (Delete)

    I think we may not need a line item for UNI, because the UNI is unchanged. Only the VLAN assignments on the UNI are changing, which I believe are part of EVC Endpoint CFS. 

    As part of your Service Design & Assign, whenever you receive Delete on EVC Endpoint, you identify which UNI it is utilizing and remove that relationship in the Service Inventory. So, the relationship between UNI and EVC should be the based on the availability of EVC Endpoints and should be mastered in Service Inventory. 



    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation
    ------------------------------



  • 12.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Aug 10, 2021 13:56
    Edited by Carlos Portela Aug 10, 2021 13:57
    Hi Kinshuk,

    Indeed, if the EVC End Point is modelled as a service and not as a set of attributes of the EVC, we can follow that approach.
    However, if we look to today's OVC service from MEF model, the end-points are being modelled as a sub-set of characteristics. I've understood they plan to change it and have the end-points as separate service that should be ordered as additional item. In this case, the example I've gave will not be applicable.

    Forgetting MEF models for a moment, I think the challenge I raise can still occur in many other modelling use-cases. For example, if we want to model a VPN as a Service that rely on multiple Site Connectivity Services, we could imagine that this VPN Service will have its relationships being constantly updated to reach more or less connectivity sites. There are always many ways to model this but, taking this one, I think the current TMF641 model will not be sufficient to update VPN service relationships by just adding a new relationship or ceasing a specific one. 

    If we are looking to have a TMF641 API definition that can support any kind of modelling choice and use-case, it would be great that the API offers the capability to remove or add a specific relationship of a service. I am currently seeing this need more and more with OTT-based models.
    In order to have the TMF641 flexible enough for these cases, I would suggest it to have an additional attribute being "relationshipAction" under the "ServiceOrderItemRelationship" sub-resource to fix such challenge.

    @Ludovic Robert, is this suggestion something that can be discussed on the API team meetings?​​

    ------------------------------
    Carlos Portela
    Prodapt Solutions
    ------------------------------



  • 13.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Jul 06, 2021 02:48
    Edited by Peter Skoularikos Jul 06, 2021 03:22
    Hi Carlos

    One solution is to ensure that the CFS reflects the service ie. E-Line or other , whereas UNIs reflect the resource facing services  , so one can segregate the set of UNI's which are specific to each and treat these as RFS's with corresponding Resource end points ( ports etc ) . Thus the ordering process does not identify the specific UNI which is claimed at  design  stage from an inventory or other network reference topology platform. It goes back to the conversation we had on how much of the technical infrastructure is exposed at product ordering stage.

    Note also that the "end point" may be a virtual end point , which is attached to a port, and that the UNI has an association to the access link, so providing flexibility in setting up any type of network. 


    ------------------------------
    Peter Skoularikos
    Telekinetics
    ------------------------------



  • 14.  RE: TMF641 - change service relationship (also TMF622)

    TM Forum Member
    Posted Aug 10, 2021 14:08
    Hi Peter,

    I agree with your remark but this detailed exposition at POM level is in fact defined like that by MEF and we are just looking on how to manage this granularity with the Open API's. Note that this kind of need to break/create specific relationships at Product or Service level might come for many use-cases and not only MEF. We can even reduce the complexity and detail on the Product Model but you might still face these challenges on the Service Model to define the dependencies between services. Today, TMF641 and TMF622 doesn't offer the option to ask for a Service/Product modification by only breaking a specific relationship that is no longer needed. As we are offering more and more self-service capabilities, combined with OTT services, there are a lot of use-cases when a user will request to move a specific service from a specific site/access/connectivity to another one and this will trigger updates on the service relationship to be attached to a new entity. It all depends on how a CSP defines its service model and flexibility for customisation. 

    Regards

    ------------------------------
    Carlos Portela
    Prodapt Solutions
    ------------------------------