Subject: [Teas-ns-dt] Transport slice, connections and functions.

From: Kiran Makhijani <[email-masked]>
Date: Tue, 12 Nov 2019 17:05:41 +0000

Hello,
As promised in the call yesterday, I hope we use the following text to better articulate and converge on the discussion on transport connection and functions. We’ll deal separately with what what SFs should be in scope (covered by Luis’s thread).

----- Background -----
We initially started with transport slice as described by Reza:
  - an SLA-guaranteeing inter-connection between 2 networks (e.g. RAN and 5GC).
  - This gives us very simple network resources to work with
      - path latency, bandwidth, resiliency, and reliability.
      - the northbound interface has 2 actors: transport-slice oeprator and transport-slice tenant.
      - allow changes to transport slice by tenants.
      - The realization maybe achieved via ACTN, SR, RSVP etc existing technologies.

We then extended the discussion include 2 more components: isolation (connectivity SLA?) and service function (also a resource).
   - isolation: is an important end to end characteristic. It allows an operator to offer different type of network services to tenants. Tenants can then use this slice to purpose built network for their applications. It may be achieved via hard of soft resource isolation.

   - service functions: tenants should be able to install their own polices, rules etc in the offered transport slices, therefore, they should be part of transport slices. It is also a means to enable isolation.

-------Problem --------
My doubt is: If we only consider connectivity as transport slice, we may run into scale challenges when we include service functions. If we don’t include functions then the scope of transport slice is less interesting.

---- By example------
Now if we only consider slice as a connection then we should guarantee SLAs between SFs. i.e.

    (SF-1)---[ts0]---(SF-2)--[ts1]--(SF-3)
        |
        |----[ts2]--(SF-4)

  Just using above figure as an example, if we only consider connectivity as transport slice, then the tenant will need to create separate transport slices ts0, ts1, ts2 to connect different SFs. This will mean all those transport slices have to be managed/identified seprately. Higher the number of functions and multi-points, scalability challenges will start to show (this looks like micro-managing every link). it is even a bigger challenge for the slice operator, since there's very little abstraction here.

Alternately, we can consider the below figure as one transport slice, managed as a single entity.

    (SF-1)------(SF-2)----(SF-3)
        |
        |------(SF-4)

I assume both the figures as one transport network i.e. same administrative domain. The app-logic or the users of the tenants (users) are not at all invovled. Therefore, they are not end to end slices.

Finally, we may have 2 different administrative domains and there it may need more than one transport slice as below, each meeting same SLA of latency/bw/reliability.
    (ts-1)-----(ts-2)----(ts-3)

Maybe chain of SFs is a higher level “non-transport slice”. But I find it less interesting.

Thanks
Kiran