Subject: Re: [Detnet] draft-ietf-detnet-use-cases & slices suggestions

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 4 Jan 2018 01:51:31 +0000

Hi Toerless,

Thank you for your comments. They are very useful.

Here is the revised text of Network Slicing Use Case. You can find some of your suggested words are added into it, which have been highlighted.

I hope perhaps Greg and Alex can also be satisfied with this version , because a paragraph tries to respond to your comments about adding other use cases mentioned in 3GPP . I have highlighted them too.

This is open to discuss.

Any other comments are welcome.

-----------------------------------------------------------------------------------------------------------------------

10. Network Slicing

10.1. Use Case Description

Network slicing divides one physical network infrastructure into multiple logical networks. Each slice, corresponding to a logical network,

uses resources and network functions independently from each other. Network slicing provides flexibility of resource allocation and service

quality customization. Future services will demand network performance with a wide variety of characteristics such as high data rate, low

latency, low loss rate, security and many other parameters. Ideally every service would have its own physical network satisfying its particular

performance requirements; however that would be prohibitively expensive. Network slicing can provide a customized slice for a single service,

and multiple slices can share the same physical network. This method can optimize the performance for the service at lower cost, and the

flexibility of setting up and release the slices also allows the user to allocate the network resources dynamically. Unlike other DetNet use cases,

Network slicing is not a specific application with specific deterministic requirements; it is proposed as a new requirement for the future network,

which is still in discussion, and DetNet is a candidate solution for it.

10.2 Using DetNet in Network Slicing
10.2.1 Hard resource isolation across slices
One of the requirements discussed for network slicing is the "hard" separation of various users’ deterministic performance. That is, it should
be impossible for activity, lack of activity, or changes in activity of one or more users to have any appreciable effect on the deterministic
performance parameters of any other slices. Typical techniques used today, which share a physical network among users, do not offer this
kind of insulation. DetNet can supply point-to-point or point-to-multipoint paths that offer bandwidth and latency guarantees to a user that
cannot be affected by other users’ data traffic. Thus DetNet is a powerful tool when latency and reliability are required in Network Slicing.

10.2.2 Deterministic services within slices
Slices need to be able to provide services that require DetNet type guarantees. Technically, DetNet in Network Slicing can be used just the
same as DetNet without Network Slicing.(from Toerless)

10.3 Network Slicing Use Case
Network Slicing is a core feature of 5G defined in 3GPP, which is currently under development. A Network Slice in mobile network is a complete
logical network including Radio Access Network (RAN) and Core Network (CN). It provides telecommunication services and network capabilities,
which may vary (or not) from slice to slice. A 5G bearer network is a typical use case of network slicing, including 3 service scenarios: enhanced
Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC).

Each of these are described below.

Ÿ   Enhanced Mobile Broadband (eMBB)
eMBB focuses on services characterized by high data rates, such as high definition (HD) videos, virtual reality (VR), augmented reality (AR),
and fixed mobile convergence (FMC).

Ÿ   Ultra-Reliable and Low Latency Communications (URLLC)
URLLC focuses on latency-sensitive services, such as self-driving vehicles, remote surgery, or drone control.

Ÿ   massive Machine Type Communications (mMTC)
mMTC focuses on services that have high requirements for connection density, such as those typical for smart city and smart agriculture use cases.

5G bearer uses DetNet to have hard resource isolation across slices and within the slice.

For example, there are two slices in the network: Slice-A and Slice-B; DetNet is used to transit URLLC services: URLLC-A and URLLC-B. Without DetNet,
URLLC-A and URLLC-B compete for bandwidth resource. Latency and reliability is not guaranteed; With DetNet, URLLC-A and URLLC-B have separate
bandwidth reservation and there is no confliction between them, just as they are in different logical networks.

Even though not necessary within the scope of work explicitly charted for slices in 5G: Whenever 5G or other network service providers see the
opportunity to operate services described as use-cases in other sections of this document across a shared physical infrastructure, network slices would
be the likely preferred approach to provide such services. Examples include providing electrical utilities services (section 3.), pro audio
services (section 2.) or V2X via slices. Use cases like these could become more into the focus for network slices when the work for 5G core network evolution
will include services that are more inclusive of even wired access options required in those use-cases.
( part from Toerless and the highlighted text answers the question of Greg and Alex)

However, DetNet cannot cover every Network Slicing use case, and there are some other problems to be solved. Firstly, DetNet is a point-to-point or
point-to-multipoint technology while Network Slicing needs multi-point to multi-point guarantee. Second, the number of flows that can be carried by
DetNet is limited by DetNet scalability. Flow aggregation and queuing management modification may help to fix the problem. More work and discussions
are needed in these topics.

10.4 Network Slicing Today and Future
Network slicing can satisfy the requirements of a lot of future deployment scenario, but it is still a collection of ideas and analysis, without a specific
technical solution. A lot of technologies, such as Flex-E, Segment Routing, and DetNet have potential to be used in Network Slicing. For more details
please see IETF99 Network Slicing BOF session agenda and materials.

10.5. Network Slicing Asks

Ÿ   Isolation from other flows through Queuing Management

Ÿ   Service Quality Customization and Guarantee

Ÿ   Security

-----------------------------------------------------------------------------------------------------------------------

Best Regards

Xuesong

>-----Original Message-----

>From: Toerless Eckert [mailto:[email-masked]]

>Sent: Thursday, November 16, 2017 11:32 AM

>To: [email-masked]; [email-masked]

>Subject: draft-ietf-detnet-use-cases & slices suggestions

>Wrt to my comments on the mike@singapore re. slicing use-case:

>First of all i would like to reinforce Stewarts statement that we should not

>remove slicing from the use-case draft. My point was different: making the

>importance for detnet in slicing clearer - because i think it is hierarchical and

>multi-faceted, and that does not well reflect in the current text.

>Following suggestions for improvements aside, the existing text of 10. is already

>very nicely enlightening about slices, more so than i have seen in other places.

>A) I would not call 10.1 "Use Case Description" but instead "Technology

>Description"

>B) 10.3 up to the the "However" is IMHO the most fundamental use-case for

>detnet

>  in the slicing realm. It should be moved and become e.g.: a new 10.2.1

>use-case,

>  here is proposed changed paragraphs:

>  10.2.1 Hard resource isolation across slices

>  |Network slicing aims to provide logical networks with hard resource

>  |separation guarantees between those different logical networks.

>  |Hard resource separation means that it should be impossible for activity,

>  |lack of activity, or changes in activity of one or more slices to have

>  |any appreciable effect on the deterministic performance parameters of any

>  |other slices.

>  |Typical techniques used today (for example in pre-existing logical/virtual

>  |network solutions), which share a physical network amongst users, do

>  |not offer this kind of insulation.  DetNet can supply point-to-point

>  |or point-to-multipoint paths that offer bandwidth and latency

>  |guarantees to a slice that cannot be affected by other slices data

>  |traffic.

>  I hope i did correctly interpret "user" to mean "slice", because, but even

>  if not, i think the above is correct: If we want to have strict separation

>  guarantees btween different users inside the same clice, that is IMHO a

>  separate use case within the slicing technology:

>C) I would group existing 10.2.1...10.2.3 under a common use-case, maybe:

>   10.2.2 Deterministic services within slices

>   Slices need to be able to provide services that require detnet type

>   guarantees. These requirements would equally make the use of detnet

>   for these services a requirement if the service was not provided via a

>   logical network slice but via a separate physcial network (and therefore

>   the use-case requirement of 10.2.1 would not exist)

>   A 5G bearer network is a typical  ...

>   [ Make existing 10.2.1...10.2.3 become eg: 10.2.2.1 ... 10.2.2.3]

>D) It would be nice to have more clarifying details

>   about the sentence "A 5G bearer network is a typical

>   use case of network slicing, including 3 service scenarios"

>   If the answer to my questions are not really clear because 3GPP has not

>   make up its mind what exactly is required, then maybe phrase the text

>   accordingly (3GPP has not yet decided where or...):

>   1. Will 3GPP want to have slices which are NOT 5G bearer networks ?

>     if yes, then say this.

>   2. For a network slice which is a 5G bearer network, would it have

>     only one of the 3 service scenarios, or any subset of the 3 ?

>   3. If the answer to 1. is "yes, also slices that are not 3GPP bearers",

>      would any or all of the three mentioned service scenarios also

>      be required in those non-3GPP slices ?

>E) It might be useful to add text stating that use cases for detnet

>   mentioned in other sections of the document would likely become

>   use cases of slices in the future.

>   Possible suggested text:

>   Even though not necesary within the scope of work explicitly charted

>   for slices in 5G: Whenever 5G or other network service providers see the

>   opportunity to operate services described as use-cases in other sections of

>   this document across a shared physcial infrastructure, network slices

>   would be the likely preferred approach to provide such services.

>   Examples include providing electrical utilities services (section 3.)

>   or pro audio services (section 2.) via slices. Use cases like these could

>become

>   more into the focus for network slices when the work for 5G core

>   network evolution will include services that are more inclusive of

>   even wired access options required in those use-cases.

>F) Another likely evolution of slices worthwhile to notice:

>   Slices may equally become the preferred mode of providing services that

>   are otherwise considered to be out of scope in this document, such as

>   those in 12.2. These can easily come into scope when Mobile Edge Compute

>   ressources connecting to slices can allow to provide detnet service

>guarantees

>   to these use-cases by eliminating the uncontrolled parts of a path

>   between servers and client.

>Cheers

>    Toerless

>On Mon, Nov 13, 2017 at 09:06:40AM +0000, Grossman, Ethan A. wrote:

>> Tal does this work for you?

>> Ethan.

>> On Nov 13, 2017, at 3:48 PM, Norman Finn

><[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

>wrote:

>> Sounds like Tuesday 16:00.  Right?  Near registration.

>> -- Norm

>> ________________________________

>> From: Grossman, Ethan A. [[email-masked]<mailto:[email-masked]>]

>> Sent: Sunday, November 12, 2017 8:16 PM

>> To: Das, Subir

>> Cc: Patrick Wetterwald (pwetterw); Norman Finn;

>> [email-masked]<mailto:draft-ietf-detnet-security@<mailto:[email-masked]%3cmailto:draft-ietf-detnet-security@>

>> ietf.org>; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>; Gary Weiner

>> Subject: Re: [Detnet] DetNet Security Meet-Up

>> I can do Tuesday 16:00. I have a commitment Tuesday at 18:30.

>> Ethan.

>> On Nov 13, 2017, at 11:27 AM, Das, Subir

><[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:

>> I arrived today but can't  make it on Tuesday at 13:30. Available from 16:00.

>> ________________________________

>> From: Grossman, Ethan A. [[email-masked]<mailto:[email-masked]>]

>> Sent: Sunday, November 12, 2017 10:15 PM

>> To: Patrick Wetterwald (pwetterw)

>> Cc: Norman Finn;

>> [email-masked]<mailto:draft-ietf-detnet-security@<mailto:[email-masked]%3cmailto:draft-ietf-detnet-security@>

>> ietf.org>; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>; Gary Weiner

>> Subject: Re: [Detnet] DetNet Security Meet-Up

>> Yes I was agreeing to Tuesday.

>> Ethan.

>> On Nov 13, 2017, at 10:46 AM, Patrick Wetterwald (pwetterw)

><[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:

>> On Tuesday. Correct ?

>> Patrick

>> From: detnet <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

>> on behalf of "Grossman, Ethan A."

>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

>> Date: Monday, 13 November 2017 at 03:43

>> To: Norman Finn

><[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

>,

>> "[email-masked]<mailto:draft-ietf-detnet-security

>> @ietf.org>"

>> <[email-masked]<mailto:draft-ietf-detnet-security

>> @ietf.org>>

>> Cc: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]%3cmailto:[email-masked]%3e>"

>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>, Gary Weiner

>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

>> Subject: Re: [Detnet] DetNet Security Meet-Up

>> Meet at 13:30 at IETF Registration?

>> Ethan.

>> From: Norman Finn [mailto:[email-masked]]

>> Sent: Sunday, November 12, 2017 4:52 PM

>> To: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>;

>> [email-masked]<mailto:draft-ietf-detnet-security@<mailto:[email-masked]%3cmailto:draft-ietf-detnet-security@>

>> ietf.org>

>> Cc: Gary Weiner <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>;

>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

>> Subject: RE: DetNet Security Meet-Up

>> Yes, let's get together.  Right now, any time Tuesday after lunch would be

>fine.

>> -- Norm

>> ________________________________

>> From: Grossman, Ethan A. [[email-masked]<mailto:[email-masked]>]

>> Sent: Sunday, November 12, 2017 3:59 AM

>> To:

>> [email-masked]<mailto:draft-ietf-detnet-security@<mailto:[email-masked]%3cmailto:draft-ietf-detnet-security@>

>> ietf.org>

>> Cc: Gary Weiner; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

>> Subject: DetNet Security Meet-Up

>> Hello DetNet Security draft authors, (and adding the DetNet list since

>> we are now a WG draft and would like to include anyone who has any interest),

>Tal and I are here in Singapore and would like to know if any of the rest of you

>might be here in town and might want to meet up over lunch or dinner (or

>something) to discuss DetNet security, e.g. next steps for the DetNet Security

>draft. If so, please reply and we can plan something.

>> Thanks,

>> Ethan.

>> Ethan Grossman, DetNet Security Draft editor.

>> _______________________________________________

>> detnet mailing list

>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

>> https://www.ietf.org/mailman/listinfo/detnet

>> _______________________________________________

>> detnet mailing list

>> [email-masked]<mailto:[email-masked]>

>> https://www.ietf.org/mailman/listinfo/detnet

>--

>---

>[email-masked]<mailto:[email-masked]>

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 16 Jan 2018 11:57:28 +0000

Hello Xuesong

I am wondering if this part of the text is correct:

"For example, there are two slices in the network: Slice-A and Slice-B; DetNet is used to transit URLLC services: URLLC-A and URLLC-B. Without DetNet,
URLLC-A and URLLC-B compete for bandwidth resource. Latency and reliability is not guaranteed; With DetNet, URLLC-A and URLLC-B have separate
bandwidth reservation and there is no confliction between them, just as they are in different logical networks. "

Or did you mean to say that (DetNet -> slice):
Without slicing URLLC-A and URLLC-B compete for bandwidth resource. Latency and reliability is not guaranteed; With silicing, URLLC-A and URLLC-B have separate
bandwidth reservation and there is no confliction between them, just as they are in different logical networks.

Best regards
Hannu

From: detnet [mailto:[email-masked]] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Thursday, January 04, 2018 3:52 AM
To: Toerless Eckert <[email-masked]>; Greg Mirsky <[email-masked]>; Alexandre Petrescu <[email-masked]>; [email-masked]
Cc: Grossman, Ethan A. <[email-masked]>; Norman Finn <[email-masked]>; Mach Chen <[email-masked]>
Subject: Re: [Detnet] draft-ietf-detnet-use-cases & slices suggestions

Hi Toerless,

This is open to discuss.

10. Network Slicing

10.2 Using DetNet in Network Slicing
10.2.1 Hard resource isolation across slices
One of the requirements discussed for network slicing is the "hard" separation of various users' deterministic performance. That is, it should
be impossible for activity, lack of activity, or changes in activity of one or more users to have any appreciable effect on the deterministic
performance parameters of any other slices. Typical techniques used today, which share a physical network among users, do not offer this
kind of insulation. DetNet can supply point-to-point or point-to-multipoint paths that offer bandwidth and latency guarantees to a user that
cannot be affected by other users' data traffic. Thus DetNet is a powerful tool when latency and reliability are required in Network Slicing.

?   Enhanced Mobile Broadband (eMBB)
eMBB focuses on services characterized by high data rates, such as high definition (HD) videos, virtual reality (VR), augmented reality (AR),
and fixed mobile convergence (FMC).

?   Ultra-Reliable and Low Latency Communications (URLLC)
URLLC focuses on latency-sensitive services, such as self-driving vehicles, remote surgery, or drone control.

?   massive Machine Type Communications (mMTC)
mMTC focuses on services that have high requirements for connection density, such as those typical for smart city and smart agriculture use cases.

?   Isolation from other flows through Queuing Management

?   Service Quality Customization and Guarantee

?   Security

Best Regards

Xuesong

>To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 17 Jan 2018 01:29:31 +0000

Hi Hannu,

Thank you for your review, and what you have mentioned in the email is very important for understanding this use case.
If you notice that there is a statement “5G bearer uses DetNet to have hard resource isolation across slices and within the slice” before the example you have mentioned, maybe
you can find that this paragraph is intended to illustrate how DetNet can offer resource isolation across slices.
I think if there are only URLLC services in Slice-A and Slice-B, DetNet can separate the slices directly; if there are also non-URLLC services, DetNet can separate the URLLC service from different slices rather than separate the slices.
The assumption here is that non-URLLC services don’t need DetNet-level transmission quality, so non-URLLC services can’t be separated by DetNet.
If you think this part of text is not clear enough , I can add more explanations to avoid confusion.

Best Regards,
Xuesong

From: Flinck, Hannu (Nokia - FI/Espoo) [mailto:[email-masked]]
Sent: Tuesday, January 16, 2018 7:57 PM
To: Gengxuesong (Geng Xuesong); Toerless Eckert; Greg Mirsky; Alexandre Petrescu; [email-masked]
Cc: Grossman, Ethan A.; Norman Finn; Mach Chen
Subject: RE: draft-ietf-detnet-use-cases & slices suggestions

Hello Xuesong

“For example, there are two slices in the network: Slice-A and Slice-B; DetNet is used to transit URLLC services: URLLC-A and URLLC-B. Without DetNet,
URLLC-A and URLLC-B compete for bandwidth resource. Latency and reliability is not guaranteed; With DetNet, URLLC-A and URLLC-B have separate
bandwidth reservation and there is no confliction between them, just as they are in different logical networks. “

Best regards
Hannu

From: detnet [mailto:[email-masked]] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Thursday, January 04, 2018 3:52 AM
To: Toerless Eckert <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>; Norman Finn <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] draft-ietf-detnet-use-cases & slices suggestions

Hi Toerless,

This is open to discuss.

10. Network Slicing

•   Enhanced Mobile Broadband (eMBB)
eMBB focuses on services characterized by high data rates, such as high definition (HD) videos, virtual reality (VR), augmented reality (AR),
and fixed mobile convergence (FMC).

•   Ultra-Reliable and Low Latency Communications (URLLC)
URLLC focuses on latency-sensitive services, such as self-driving vehicles, remote surgery, or drone control.

•   massive Machine Type Communications (mMTC)
mMTC focuses on services that have high requirements for connection density, such as those typical for smart city and smart agriculture use cases.

•   Isolation from other flows through Queuing Management

•   Service Quality Customization and Guarantee

•   Security

Best Regards

Xuesong