Subject: Re: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

From: "Wubo (lana)" <[email-masked]>
Date: Tue, 7 Apr 2020 12:54:31 +0000

Hi Luis,

Thanks for the discussions , please see inline[Bo].

Best regards,
Bo

发件人: Teas-ns-dt [mailto:[email-masked]] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2020年4月7日 3:37
收件人: [email-masked]
主题: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi all,

Thanks for the good discussion today.

Let me share two thoughts regarding the discussions of today:

·         Different SLOs for different TS members on the same slice. According to the discussion today, I think we need to differentiate two situations:

o   Situation 1 -  a slice customer request a slice for supporting a service that needs different SLOs in different part of the slice.

o   Situation 2 – two slice customers request a slice to support two different services that need different SLOs.

o   In situation 1, I think it could be feasible to support the different SLOs on the slice, since those SLOs will apply to different parts of the slice, e.g. different BW in access than in the central point providing content to all the accesses.

o   In situation 2, however, it is not so intuitive that the two customers could be accommodated on the same slice. For instance, there could be different (not always compatible) SLOs for the same part of the slice (either access, central point, etc), or one of the customers could require some on-the-fly reconfigurations that could impact or interfere the other customer’s service.

o   Maybe my problem here is the concept of TS member if synonymous of TS customer. Two different customers could share a slice without problem if the SLOs are equivalent, and/or if any action from one customer cannot interfere on the other (either because there are isolation mechanisms in place or simply because the customer is not allowed to perform any re-configuration). But if that is not the case, then it is not so easy to make different customer co-exist (too much complexity, it seems easier to go for different slices). So probably re-defining the idea of TS member the issue of sharing or dividing a slice between parts with different SLOs could be more clear.
[Bo]
I agree that TS-members need to be more clearly defined to avoid these confusion. Please let me confirm with you:

For the situation 1, you mentioned "different SLOs in different parts of the slice".
Taken the figure below as an example, Do you mean that the SLO of EP3-EP4 can be different from that of EP1-EP3 or EP1-EP4, but multiple SLOs between EP1 and EP3 are not allowed?
                 +--------------------------+
                 |                          |
  +-----+  /--\  |                          |  /--\   +-------+
  |     +-+ EP1+-+                          +-+ EP3+--+ Site2 |
  |Site1|  \--/  |                          |  \--/   +-------+
  |     |        |                          |
  |     |  /--\  |                          |  /--\   +-------+
  |     +-+ EP2|-+                          +-+ EP4+--+ Site3 |
  +-----+  \--/  |                          |  \--/   +-------+
                 |        Transport         |
                 |        Network           |
                 +--------------------------+
            |                                    |
            |<-----Transport Slice n------------>|
            |                                    |

For the situation 2, based on my understanding of  the nsdt-transport-definition draft, even if two TS customers share one TS, the TS are not aware of the different customer services. Therefore, the TS-member cannot be used to distinguish customer services.
Assume it’s the case that two customers share the same TS slice by requesting same part uses different SLO, for example, SLO in EP1-EP3, and the two customers do not affect each other.
If the different SLO definition uses the TS-member to distinguish, there may be no clear distinction of TS-member and TS definition.

·         Need of topology view in the higher system. Two comments here:

o   In this respect it could be needed for the higher system to pass some geographical or location related information to the TSC. Having to pass this kind of information not necessarily require to have a topological view of the transport network (i.e., it can be passed without having that view), but probably having the topological view (or some detail of) could simplify the process and assist higher systems in their process.

o   When thinking on the connection to the end-points, such the case for gNB’s and UPF’s as we saw today, the higher system would benefit from having a consistent topological view that could assist it on properly instructing both the TSC and the other controllers to identify the end points. For that I can agree we can have yet the black box approach internally to the transport part. Again, probably some geographical or location information could assist on the process.
[Bo] To clarify the  question,  do you mean:
Comment 1: Use geographical or location related information  instead of the TS endpoint to define TS abstract topology?
Comment 2: Better to add  geographical or location related information to the TS endpoint?

Just to share my thoughts after today’s meeting,

Best regards

Luis

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
[email-masked]<mailto:[email-masked]>

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 14 Apr 2020 19:42:26 +0000

Hi Bo,

Apologies for my late response.

See my replies also in-line, labeled as [Luis>>].

Thanks

Luis

De: Wubo (lana) <[email-masked]>
Enviado el: martes, 7 de abril de 2020 14:55
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]
Asunto: Re: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Luis,

Best regards,
Bo

发件人: Teas-ns-dt [mailto:[email-masked]] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2020年4月7日 3:37
收件人: [email-masked]<mailto:[email-masked]>
主题: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi all,

[Luis>>] Let me give you an example. You may want to connect a number of gNBs with let’s say 10 Gbps, but support the connection of the UPF where some application is connected with 100 Gbps, allowing this application buffering (i.e., not stringent requirement in terms of latency). So in this case we have different SLOs in terms of guaranteed BW in different parts of the slice, but for the same slice customer.
But could be the case another customer could request a slice to support similar connectivity but needing a extremely low latency (maybe for a V2X service, with critical response). Then, even if both slices are compatible in terms of throughput, they are not compatible in terms of latency. For sure, a slice adapted for customer 2 satisfies the requirements of customer 1 as well, but it is probably more convenient to create two different slices, one adapted to each customer. Think in other attributes such as MTU size, support of group communications, etc. All of these can make difficult to determine the possibility of making services from customers to co-exist.
But things can become either more complex if the customer have some possibility of taking actions on the transport resources allocated to it. I’m thinking on some capability for steering the traffic or shaping the traffic or the like. This “control” capabilities can interfere with the traffic from other customers, making such co-existence impossible, and forcing to have different slices for those customers (and guaranteeing isolation among them).

[Luis>>] So this means that similar customers can coexist. That’s fine if the SLO’s are compatible and no (“control”) actions from one customer can impact other customers in that slice. That’s fine.

[Luis>>] I guess that in that case we would require to do the same as we today on non-sliced networks. Basically to take care of the individual customer service on the multi-service network (at the time of planning, operating, etc). I think that in this case the concept of slice is diluted.

[Luis>>] I was thinking on the case, for instance, of having to stitch a slice in the RAN with a slice in the CN. The upper systems needs some means of associating and understanding what are the end to stitch from an end-to-end perspective, and maybe some details on topological options. For example, it can be possible to associate a gNB with a UPF in region A and another UPF in region B (e.g., for pooling), and for that maybe it is interesting to have some high level topological detail in the transport part, plus a view of where is the gNB and the two UPFs.

Best regards

Luis

Technology and Planning

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 14 Apr 2020 20:54:31 +0000

Hi Luis, Bo,
I just started to follow this thread and found bit concerning.

From some of the text below, it seems we may not be following the definition of slice properly. A slice corresponds to a set of SLO (and a service-vertical perhaps). So how can we have different SLOs with in a slice? This should not be permitted. If such a capability is needed it should be an orchestration on top (or independent) of the transport slice infrastructure. To me, over-generalizing the slices could make them too complex to operate and may also lose isolation characteristics.
Similarly,
some capability for steering the traffic or shaping the traffic or the like.
^^^^^
I think this in fact changes the SLO of the slice and should be treated so. Has augmenting slice SLOs have already been discussed? Sorry I missed Monday’s call.
-Kiran

From: Teas-ns-dt <[email-masked]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, April 14, 2020 12:42 PM
To: Wubo (lana) <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Bo,

Thanks

Luis

De: Wubo (lana) <[email-masked]<mailto:[email-masked]>>
Enviado el: martes, 7 de abril de 2020 14:55
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Asunto: Re: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Luis,

Best regards,
Bo

Hi all,

  *   Different SLOs for different TS members on the same slice. According to the discussion today, I think we need to differentiate two situations:
     *   Situation 1 -  a slice customer request a slice for supporting a service that needs different SLOs in different part of the slice.
     *   Situation 2 – two slice customers request a slice to support two different services that need different SLOs.
     *   In situation 1, I think it could be feasible to support the different SLOs on the slice, since those SLOs will apply to different parts of the slice, e.g. different BW in access than in the central point providing content to all the accesses.
     *   In situation 2, however, it is not so intuitive that the two customers could be accommodated on the same slice. For instance, there could be different (not always compatible) SLOs for the same part of the slice (either access, central point, etc), or one of the customers could require some on-the-fly reconfigurations that could impact or interfere the other customer’s service.
     *   Maybe my problem here is the concept of TS member if synonymous of TS customer. Two different customers could share a slice without problem if the SLOs are equivalent, and/or if any action from one customer cannot interfere on the other (either because there are isolation mechanisms in place or simply because the customer is not allowed to perform any re-configuration). But if that is not the case, then it is not so easy to make different customer co-exist (too much complexity, it seems easier to go for different slices). So probably re-defining the idea of TS member the issue of sharing or dividing a slice between parts with different SLOs could be more clear.
[Bo]
I agree that TS-members need to be more clearly defined to avoid these confusion. Please let me confirm with you:

  *   Need of topology view in the higher system. Two comments here:
     *   In this respect it could be needed for the higher system to pass some geographical or location related information to the TSC. Having to pass this kind of information not necessarily require to have a topological view of the transport network (i.e., it can be passed without having that view), but probably having the topological view (or some detail of) could simplify the process and assist higher systems in their process.
     *   When thinking on the connection to the end-points, such the case for gNB’s and UPF’s as we saw today, the higher system would benefit from having a consistent topological view that could assist it on properly instructing both the TSC and the other controllers to identify the end points. For that I can agree we can have yet the black box approach internally to the transport part. Again, probably some geographical or location information could assist on the process.
[Bo] To clarify the  question,  do you mean:
Comment 1: Use geographical or location related information  instead of the TS endpoint to define TS abstract topology?
Comment 2: Better to add  geographical or location related information to the TS endpoint?

Best regards

Luis

Technology and Planning

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 14 Apr 2020 21:59:28 +0000

Hi Kiran,

The point is that some services could have constituent parts with different requirements. Some examples:
.- the connection of gNBs in the capilar part of the mobile network vs the connection of some centralized content server that aggregates the traffic of the different gNBs -> here there could be a difference in the needs of BW / throughput. This can be applicable to other scenarios such as connection of different corporate premises, of different sizes, to a central point plus the connection from that central point to some DB/centralized system.
.- the connection to some VR/AR system close to the edge, requiring low latency and rapid responsiveness complemented by additional connectivity for feeding the contents -> here there could be a difference in terms of required latency in each constituent part

In those examples a single service can require different guarantees in different parts. We need to find a way of handling this, according to the discussions.

The other aspect that you mention is about the control capabilities that the customer could have over the allocated slice. Should we only consider slices where the customer only injects traffic? Maybe it is a starting point,  but I would expect more sophisticated capabilities available for the customer when going to slicing when compared with existing mode of operation. But I acknowledge we need to start for something less complex, and grow on top of that.  Being said that, I think that such advanced capabilities don’t change the SLOs (I mean, a customer could decide to re-connect a gNB from UPF A to UPF B, but such connection will have the same characteristics).

Best regards

Luis

De: Kiran Makhijani <[email-masked]>
Enviado el: martes, 14 de abril de 2020 22:55
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Wubo (lana) <[email-masked]>; [email-masked]
Asunto: RE: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Luis, Bo,

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, April 14, 2020 12:42 PM
To: Wubo (lana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Bo,

Thanks

Luis

Hi Luis,

Best regards,
Bo

Hi all,

Best regards

Luis

Technology and Planning

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 15 Apr 2020 16:09:56 +0000

Luis,
Many thanks. I am glad that we are having these discussions (they should be documented somewhere perhaps as operations/usecase/scenarios).

- “connection of gNBs” : this case is representation of transport slice graph (gNBs to content server is a link). In definitions document we mention that SLOs can be per flow/group of flow or for the entire slice. So for me the SLO doesn’t change but the scale changes.
- “connection to AR/VR”: low-latency service should be one transport slice (SLO doesn’t change). And the feeder as a non-slice (non-SLO) connection to this low-latency service. I still insist that it is important to follow value of slice is in meeting SLO guarantees. For everything that connects to these slices – we should look one level above or orthogonal. Otherwise complexity will be very high.

we only consider slices where the customer only injects traffic?
I do not know – we have deferred these conversations until initial clarity has happened. But this is the bare-minimum requirement.

-Kiran

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Sent: Tuesday, April 14, 2020 2:59 PM
To: Kiran Makhijani <[email-masked]>; Wubo (lana) <[email-masked]>; [email-masked]
Subject: RE: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Kiran,

Best regards

Luis

De: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Enviado el: martes, 14 de abril de 2020 22:55
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Wubo (lana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Asunto: RE: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Luis, Bo,

Hi Bo,

Thanks

Luis

Hi Luis,

Best regards,
Bo

Hi all,

Best regards

Luis

Technology and Planning

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 15 Apr 2020 16:44:18 +0000

Hi Kiran,

Thanks for sharing your view. I got your points (*). Maybe is time to dig a bit on different use cases to extract conclusions on how the transport slices could be consumed.

Best regards

Luis

(*) not so clear for me your view for the AR/VR case, the feeder would be part of the slice, in my opinion.

De: Kiran Makhijani <[email-masked]>
Enviado el: miércoles, 15 de abril de 2020 18:10
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Wubo (lana) <[email-masked]>; [email-masked]
Asunto: RE: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Luis,

-Kiran

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, April 14, 2020 2:59 PM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Wubo (lana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Two comments about the discussion today (different SLOs in the same slice / need of topology in the upper system)

Hi Kiran,

Best regards

Luis

Hi Luis, Bo,

Hi Bo,

Thanks

Luis

Hi Luis,

Best regards,
Bo

Hi all,

Best regards

Luis

Technology and Planning