├── COMS Charter for Working Group.docx ├── Detailed_NS_ProblemStatement-V0.3.docx ├── Detailed_NS_ProblemStatement-V0.4.docx ├── Detailed_NS_ProblemStatement-V0.5-Ravi_Slawomir_Med_Christian_Pedro_Carlos_Alex.docx ├── Detailed_NS_ProblemStatement-V0.9_31-5-2017_hfl.docx ├── Gap Analysis for NS.docx ├── IETF97_Sidemeeting01 ├── 0-Network Slicing Side Meeting Introduction_IETF97.pdf ├── 1-Network Slicing Problem Statement_IETF97.pdf ├── 2-Autonomic Slice Networking_IETF97.pdf ├── 3-Architecture for delivering multicast mobility services using network slicing_IETF97.pdf ├── 4-ACTN and network slicing_IETF97.pdf └── MeetingMinutes.md ├── IETF98_Sidemeeting02 ├── Automatic Network Slicing Management for Transport Network-Cristina qiang.pptx ├── Conclusion+Q&A_IETF98_SideMeeting_V1.pptx ├── Hares-IETF Dynamic Management.pdf ├── Introduction_IETF98_SideMeeting_V1.pptx ├── Net-Slice-ICN-Use-Case.pdf ├── Netslices-3GPP-Use-Case-IETF98.pptx ├── Network Slicing Architecture-liang.ppt ├── Network Slicing Use Cases_01.ppt ├── TowardsSliceNetworking_IETF98_SideMeeting_V3.0.pdf ├── agenda.md ├── agenda.txt ├── call_for_contributions.txt ├── ietf98-how-to-slice-flinck-nokia.pdf ├── ietf98-netslices-pedro-nict-summarized.pdf ├── ietf98-netslices-pedro-nict.pdf ├── meeting minutes ├── network-slicing-gert.ppt └── slides-98-dmm-draft-ietf-dmm-fpc-cpdp-1.pptx ├── NS-WG_Charter-Draft 1.pptx ├── NS_drafts ├── draft-dong-network-slicing-problem-statement-00.txt ├── draft-gdmb-netslices-intro-and-ps-02.txt ├── draft-qin-netslices-use-cases-01.md ├── draft-qin-netslices-use-cases-01.txt └── draft-qin-netslices-use-cases-01.xml ├── Network Slicing Architecture.docx ├── Network Slicing Architecture_hfl.docx ├── Nsdt-2019 ├── draft-nsdt-teas-transport-slice-definition.xml └── ns_defn.md ├── README.md ├── ToC-NSFramework_Revisited_V1.docx ├── draft-netslices-problem-statement-00.docx ├── draft-ns-gap-analysis.docx ├── slicing_usecases_draft_0.2.docx └── slicing_usecases_draft_0.2_HFl.docx /COMS Charter for Working Group.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/COMS Charter for Working Group.docx -------------------------------------------------------------------------------- /Detailed_NS_ProblemStatement-V0.3.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/Detailed_NS_ProblemStatement-V0.3.docx -------------------------------------------------------------------------------- /Detailed_NS_ProblemStatement-V0.4.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/Detailed_NS_ProblemStatement-V0.4.docx -------------------------------------------------------------------------------- /Detailed_NS_ProblemStatement-V0.5-Ravi_Slawomir_Med_Christian_Pedro_Carlos_Alex.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/Detailed_NS_ProblemStatement-V0.5-Ravi_Slawomir_Med_Christian_Pedro_Carlos_Alex.docx -------------------------------------------------------------------------------- /Detailed_NS_ProblemStatement-V0.9_31-5-2017_hfl.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/Detailed_NS_ProblemStatement-V0.9_31-5-2017_hfl.docx -------------------------------------------------------------------------------- /Gap Analysis for NS.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/Gap Analysis for NS.docx -------------------------------------------------------------------------------- /IETF97_Sidemeeting01/0-Network Slicing Side Meeting Introduction_IETF97.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF97_Sidemeeting01/0-Network Slicing Side Meeting Introduction_IETF97.pdf -------------------------------------------------------------------------------- /IETF97_Sidemeeting01/1-Network Slicing Problem Statement_IETF97.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF97_Sidemeeting01/1-Network Slicing Problem Statement_IETF97.pdf -------------------------------------------------------------------------------- /IETF97_Sidemeeting01/2-Autonomic Slice Networking_IETF97.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF97_Sidemeeting01/2-Autonomic Slice Networking_IETF97.pdf -------------------------------------------------------------------------------- /IETF97_Sidemeeting01/3-Architecture for delivering multicast mobility services using network slicing_IETF97.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF97_Sidemeeting01/3-Architecture for delivering multicast mobility services using network slicing_IETF97.pdf -------------------------------------------------------------------------------- /IETF97_Sidemeeting01/4-ACTN and network slicing_IETF97.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF97_Sidemeeting01/4-ACTN and network slicing_IETF97.pdf -------------------------------------------------------------------------------- /IETF97_Sidemeeting01/MeetingMinutes.md: -------------------------------------------------------------------------------- 1 | # Network Slicing Side Meeting 2 | 3 | - Nov 14, 2016, 19:00-21:00, Studio 3 4 | - 67 People signed the attendance sheet. 5 | 6 | # General Admin 7 | 8 | _Jie Dong_ introduced the purpose of the meeting. 9 | 10 | Services have unique requirements, end-2-end slicing is required for 5G. Among definitions we need to establish common definition. 11 | Purpose is to have a common view of what network slicing is in IETF. 12 | 13 | List request has been sent to Deborah (Routing Area AD). 14 | # Topics Covered 15 | ## Network slicing problem statement [Stewart Bryant] 16 | 17 | https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00 18 | 19 | ## Presentation: 20 | 21 | What is to be done in IETF, what existing and new work? 22 | 23 | Existing definition 24 | - 3GPP 25 | - ITU-T (FG IMT-2020) 26 | - IETF? 27 | 28 | **Requirements of Network Slicing** 29 | - Isolation/separation 30 | - Customization of topology 31 | - Flexibility of topology 32 | - Guaranteed QoS 33 | - Management consideration 34 | 35 | 36 | 1. What should be definition of network slicing in IETF? 37 | 2. What is needed beyond connectivity? 38 | 3. What is the scope of network slicing in IETF? 39 | 4. How much can existing/on-going tech meet the reqt? 40 | 41 | ## Discussion/Questions: 42 | 43 | Comment 1. IETF is protocol-oriented, how would slicing change the semantics of 44 | existing protocols? 45 | 46 | Stewart: We typically have a set of tools designed for best-effort fabrics and 47 | adding BW, these are not scalable and we need some additional scheduling. 48 | 49 | Comment 2. We typically build separate networks for banking and other low 50 | latency apps, this is not economical. Isolation and security are weak points. 51 | 52 | Comment 3. What are the performance and isolation requirements? Does this mean 53 | statistical sharing is out of scope? Fixed fraction of b/w seems to be a must. 54 | 55 | Stewart: There will be a spectrum of requirements, different QoS for different 56 | application, we may need some packet scheduling.Do we need isolation using 57 | mechanisms like IEEE (time sensitive networking ? TSN) or detnet. If its 58 | bit-level, we will go back to TDM. 59 | 60 | Andrew: isolation and security is the biggest challenge, figure out how to 61 | provide banking applications in economic manner, such as a slice. Packet 62 | scheduling at buffer and line speed level is not enough we need to adapt to 63 | packet changes at micro-level 64 | (it was quietly mentioned, we are not thinking at bit-level but focus at packet 65 | level). 66 | 67 | Comment 4. Look at 5G applications for machine critical, interface b/w down to 68 | radio is key, we may adapt BW based on radio capacity, Internet does not do 69 | this today, we need to figure this out. 70 | 71 | Stewart: It may be a packet level. factoring into a lower layer is an issue 72 | 73 | Comment 5. Can we define slicing?? 74 | 75 | Stewart: We can also agree on an existing definition, which would be useful. 76 | 77 | Comment 6. Generalised packet networks are not suitable for hard packet 78 | tunnels. 79 | 80 | Comment 7. Dave Allen (Ericsson): slicing definition leave it open disjoint 81 | resource like wavelength is considered in other forum as the only way to 82 | achieve isolation. e.g. WDM-PON, wavelengths allocated per slice. (Young Lee 83 | added that WSON controller is already doing this). What does packet have to do 84 | if isolation cannot be guaranteed? 85 | 86 | # Autonomic slice networking [Alex Galis] 87 | 88 | ## Presentation: 89 | https://tools.ietf.org/html/draft-galis-anima-autonomic-slice-networking-00 90 | 91 | - Generation 1 - Resource partition of network resource is one definition. 92 | - Generation 2 - Network function and services are another definition of network 93 | slicing. 94 | - Generation 3 - Grouping of partitioning of 5G slicing 95 | - Generation 4 - Management and control and advertisement has to be added to the Network slicing definition 96 | 97 | *ANIMA* - unified network slicing definition in the context of autonomic 98 | networking 99 | 100 | - The service instance component 101 | - A network slice instance component 102 | - Resource component 103 | - Slice capability exposure component 104 | 105 | *Suggested 15 work items and issues* 106 | 107 | ## Discussion/Questions: 108 | 109 | Comment 1. Dino: asked difference between horizontal and vertical slicing. 110 | Vertical slicing, can an application be a member of multiple slices? Will 111 | Extranet be required? For horizontal slicing, would it be stitching or 112 | something else? These would be for customers ill shared services and isolation 113 | for specific VPN connectivity 114 | 115 | Alex: Yes, level of abstraction and level of isolation need to be considered, 116 | and separate control may also be needed. 117 | 118 | Stewart: We may see both models 119 | 120 | Comment 2. This complicates the solution space. 121 | 122 | Alex: This is not an intent to recreate a VPN technology. 123 | 124 | Comment 3. Feels like IETF is lagging in industry work, upper service layer 125 | which drives network resources. OpenSource is already ahead/doing some of this, 126 | slicing is mainly multi-tenant, this is not rocket science or new. They are 127 | trying to map existing technology like VXLAN and mapping it into YANG. Is there 128 | a new architecture and protocol required? what is the role of IETF? API 129 | ? application level TOSCA; policy; YANG; already in place in industry. Question 130 | is where is the gap? Map to protocol of new or existing protocols. 131 | 132 | Stewart: Those are the questions we are asking at the start of the session. 133 | 134 | Comment 4. Slicing is a service definition, where is the gap? 135 | Categorise them and see if we need new protocols, or adapt existing. 136 | 137 | Alex: Yes, at least 15 problems, these are not supported by existing protocols. 138 | 139 | Comment 5. We have a slicing architecture (as part of a H2020 project), and 140 | service orchestrator, we then define flows which are application specific: IoT, 141 | video, etc. 142 | 143 | Comment 6. Ravi: IMT-2020 challenge was that service context could be only 144 | identified by flow tuple in cp, dp and mgmt. Also slicing is interesting for 145 | ICN as it allows new architectures and new properites per slice basis. 146 | 147 | # Architecture for delivering multicast mobility services using network slicing [Truong-Xuan Do] 148 | 149 | https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00 150 | 151 | ## Presentation: 152 | 153 | Multicast functionality is different for say broadcast, mobility etc cases, so 154 | there is a need to function decomposition and function chaining. 155 | 156 | ## Discussion/Questions: 157 | 158 | Comment 1. You are aware of DMM working group, DMM FTC draft defines a model 159 | that covers this. I think the group does not have a good definition of "slice", 160 | domain is similar with 5G slice. I think it’s not clear what a slice is. 161 | 162 | Stewart: This is why we are here; do we need to define "slice"? 163 | 164 | # ACTN and network slicing [Daniele Ceccarelli] 165 | 166 | https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01 167 | 168 | ## Presentation: 169 | 170 | Describe end to end L2VPN/L3VPN is not enough, so there are 3 different level of controls (CNC, PNC and MDSC for customer, physical, multi-domain network controls). Access points, per domain tunnels and inter-domain links. Customer is able to provide constraints during network provisioning. 171 | 172 | ## Discussion/Questions: 173 | 174 | Comment 1. Parviz: ACTN is a great piece of work, we have integrated based on 175 | this framework. We shipped and integrate into ONOS. ACTN is used for integrated 176 | packet optical SDN based solution. It is generalized for L0-L3 layers and need 177 | to be perhaps extended for L1,L2 and NS. ACTN seems to have a good starting 178 | point for network resource slicing and Detnet may be implementing a protocol 179 | solution for time-sensitive networking. 180 | 181 | Comment 2. Do you slice at the lower/physical lower and provide a slice to the 182 | customer? So they can modify network resource, based on their specific slice? 183 | Customer may just want the resource, not a solution, they want to manage it by 184 | themselves. 185 | 186 | Daniele: Yes, they can manage their own resource. 187 | 188 | Young Lee: VNF connectivity is included in the solution. 189 | 190 | Alex: Maybe methods for slicing exist, the management methods for specific 191 | applications and network functions are missing. 192 | 193 | Comment 3. ACTN has multiple topology descriptions (physical, virtual and 194 | customer), can it support end to end slicing with applications? 195 | 196 | YoungLee: ACTN also support NFV-constraints as part of abstraction and 197 | connectivity. 198 | 199 | Comment 4. Looking at ACTN it seems it can abstract multiple physical domains 200 | and give us a logical view of TE/transport. 201 | 202 | Daniele: ACTN introduces virtual networking, between MDSC and CNC, beneath PNC, 203 | its technology/vendor specific. 204 | 205 | Comment 5: Why ACTN for network slicing? Does it support hierarchy? 206 | 207 | YoungLee: Yes. It does via MDSC-MDSC recursion. 208 | 209 | Comment 6. ACTN is for multi-domain. How about for a single domain? 210 | 211 | YoungLee: Yes, multi-domain solution includes single-domain, which is easier. 212 | 213 | Comment 7. For 5G transport, IETF has a role to play. Front-haul, back-haul and 214 | cross haul need transport network abstraction which is needed for 5G network. 215 | Orchestration federation takes each component to give end-to-end solution. 216 | 217 | 218 | Georgios: Asked how does it do QoS besides partitioning of n/w resources. 219 | 220 | Ans: Whatever TC can do is supported 221 | 222 | Pedro: There are 2 aspects of slices - an act of creating it, and second 223 | customizing and managing it in isolation is second part of the problem. 224 | 225 | Comment: Service abstraction layer is missing and Information models. 226 | 227 | Seil: is there a gap to be discussed. 228 | 229 | Natasha from GSMA: not duplicate the work of other SDOs, if work needs to 230 | evolve they will let IETF specific group know. 231 | 232 | Wim from Nokia: slicing includes all - management, applications, radio etc 233 | beyond transport. 234 | 235 | Chris Seal: we need a stable platform first that doesnt exist. 236 | 237 | Loa: non WG BOF can be done, it is way too early to exclude from IETF 238 | 239 | Dave Allend: so many people are working on it. Problem space need to be 240 | deconstructed, work needs to be done in totality of it. 241 | 242 | Jonas: can we invite 3GPP for next meeting? 243 | 244 | ## Open Discussion 60 mins 245 | 246 | Stewart posed several questions 247 | ##### 1. Does the IETF need to work on slicing? 248 | Yes 249 | ##### 2. Does existing technologies solve the full set of slicing requirements? 250 | No 251 | 252 | ###### Comments: 253 | 254 | Already there are several slice definitions, educating and agreeing definitions is useful 255 | 256 | - Suggest we allow implementations first using existing solutions, using the 257 | tools which are already available. 258 | 259 | - Network slicing is important; it needs to be end-to-end and the IETF has be 260 | involved. We also need to engage with other SDOs (3GPP, et al.),including 261 | inviting the (SDOs) to participate in a BoF. 262 | 263 | - ACTN seems like a good starting point, maybe this needs to be extended for 264 | additional technologies like Radio 265 | 266 | - A lot of this discussion needs to be relevant to the IETF, what's on and in 267 | the wire 268 | 269 | - Process from here for the discussion, is non-WG BoF and then WG-forming BoF. 270 | We should not exclude a potential WG on this topic, we should prepare and 271 | investigate, then if we decide not to form that’s better than not being able to 272 | form due to a lack of investigation work. 273 | 274 | - One reason for lots of slicing definitions is the fact so many people are 275 | working on this topic. Across different areas and functions (controllers, 276 | orchestrations), and scheduling and APIs. We would need to deconstruct the 277 | problem space to understand what is needed, and how the IETF can help. 278 | 279 | - Of the questions asked through show of hands, people favored forming 280 | a non-working group and agreed this is an area IETF can work into. 281 | 282 | - Identifying gaps from IETF perspective is the most important aspect. 283 | 284 | ##### 3. Does the IETF need to focus discussion and develop tools for slicing? 285 | (no discussion captured) 286 | 287 | ##### 4. Interests to work on slicing? 288 | A lot 289 | 290 | ##### 5. Willing to contribute to drafts and discussions? 291 | Some 292 | 293 | 294 | -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Automatic Network Slicing Management for Transport Network-Cristina qiang.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Automatic Network Slicing Management for Transport Network-Cristina qiang.pptx -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Conclusion+Q&A_IETF98_SideMeeting_V1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Conclusion+Q&A_IETF98_SideMeeting_V1.pptx -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Hares-IETF Dynamic Management.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Hares-IETF Dynamic Management.pdf -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Introduction_IETF98_SideMeeting_V1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Introduction_IETF98_SideMeeting_V1.pptx -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Net-Slice-ICN-Use-Case.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Net-Slice-ICN-Use-Case.pdf -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Netslices-3GPP-Use-Case-IETF98.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Netslices-3GPP-Use-Case-IETF98.pptx -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Network Slicing Architecture-liang.ppt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Network Slicing Architecture-liang.ppt -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/Network Slicing Use Cases_01.ppt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/Network Slicing Use Cases_01.ppt -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/TowardsSliceNetworking_IETF98_SideMeeting_V3.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/TowardsSliceNetworking_IETF98_SideMeeting_V3.0.pdf -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/agenda.md: -------------------------------------------------------------------------------- 1 | # Draft Agenda of Network Slicing side meeting at IETF98 2 | 3 | - Location: Room Vevey 1/2, 4 | - Date/Time: 2017.03.27, 18:15-21:15 5 | 6 | ### Scope of the NS meeting: 7 | Present and discuss use cases, architecture and identify technical problems to be address by future work at IETF. The place of such work either as part of re-scoping some exiting WG or a new dedicated WG is not part of this meeting. 8 | 9 | ### Presentation 01: Agenda bash 10 | Meeting Organisers: Alex Galis – UCL, J. Dong – Huawei, K. Makhijani-Huawei, Stewart Bryant – Huawei 11 | Chairs of the meeting: Stewart Bryant – Huawei, Alex Galis - UCL 12 | Duration: 1-3 mins 13 | 14 | ### Presentation 02: Introductory Document and Revised Problem Statement walk through 15 | Presenter: Alex Galis - UCL/Stewart - Huawei 16 | Duration: 10 mins + 5 mins Q&A 17 | Abstract: This presentation represents an introduction to the motivation and SoA review for NS work ares including a revision of NS problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem related to NS capabilities, functions, APIs and operations. 18 | https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02 19 | 20 | **I. Towards NS Use Cases** 21 | ### Presentation 03: 5G Network Slicing - 3GPP Use Case background 22 | Presenter: Xavier DeFoy -InterDigital 23 | Duration: 10 mins + 5 mins Q&A 24 | Abstract: This presentation describes work conducted at the 3GPP standard organization on 5G Network Slicing, and attempts to derive high level requirements and context information for future Network Slicing work in IETF. 25 | https://datatracker.ietf.org/doc/html/draft-defoy-netslices-3gpp-network-slicing 26 | 27 | ### Presentation 04: Generalized Market/Service Verticals with Network Slicing Use cases 28 | Presenter: K. Makhijani- Huawei/J. Dongjie - Huawei 29 | Duration: 10 mins + 5 mins Q&A 30 | Agenda: Present a generalized structure of use case categories and corresponding requirements. Both new and traditional services and use cases are described. 31 | https://tools.ietf.org/html/draft-qin-netslices-use-cases-00 32 | 33 | 34 | ### Presentation 05: An ICN service delivery prototype using slices. 35 | Presenter: Ravi Ravindran - Huawei 36 | Duration: 10 mins + 5 mins Q&A 37 | Abstract: A network slicing framework allows one to deliver services over IP or new network architectures like ICN. ICN provides desirable features to support applications such as name-based networking, in-network mobility, multicasting and caching while operating over heterogeneous transports . Moreover, depending on the granularity of slicing, these features can be delivered as service-centric ICN slices or as a narrow waist serving multiple services. Through this presentation we present ICN as a use case for the network slicing group, with some details on a working prototype and requirements to orchestrate ICN slices. 38 | 39 | **II. Towards Operators Ecosystem Viewpoints** 40 | 41 | ### Presentation 06: Network Slicing architecture 42 | Presenter: Liang Geng – China Mobile 43 | Duration: 10 mins + 5 mins Q&A 44 | 45 | Abstract: This document defines the overall architecture of network slicing. Base on the general architecture, basic concepts of network slicing and examples of network slicing instances are introduced for clarification purposes. Some architectural considerations about the data plane, control plane, management and orchestration of network slicing are described to give a general view of network slicing implementation principles. This also helps to identify the gaps in existing IETF works relating to network slicing. 46 | https://datatracker.ietf.org/doc/draft-geng-netslices-architecture/ 47 | 48 | ### Presentation 07: Network Slicing: Technical Viewpoints and Functional Roles 49 | Presenter: Pedro Martinez-Julia - NICT (Japan) 50 | Duration: 10 mins + 5 mins Q&A 51 | Abstract: The limitations on internal and external flexibility of network resources and the benefits of network service composability are key aspects to promote network slicing and its related technologies. This presentation discusses a set of basic requirements that should be added to the reference architecture for network slicing, supported by two technical points of view of NS and the minimum functional roles involves in NS and their interactions. It also illustrates a potential use case, an envisioned advanced scenario, and required interfaces. 52 | 53 | 54 | **III. Towards Manufactures Viewpoints** 55 | ### Presentation 08: How to slice Network Slicing for the IETF 56 | Presenter: H. Flinck - Nokia 57 | Duration: 10 mins + 5 mins Q&A 58 | Abstract: Network slicing is motivated by sharing network infrastructure among multiple tenants. It is based in X as a Service model and motivated total cost of ownership and extending the communication services towards vertical markets. It is concept for customizing shared network resources for particular use for a tenant. A slice is composed by network functions and connectivity between these functions to meet a special SLA. Slice management and control can be divided into customer face management capabilities and to network resources facing capabilities. 3GPP, ETSI, NGMN and TM forum are already working on the slice management aspects. The issue addressed by this talk is how would the IETF complement this ongoing work. We suggest developing transport slices would be most natural work area. This would include interfaces and APIs of offered to the slice management to compose slices and to provide needed control for transport services. 59 | 60 | ### Presentation 09: ACTN Virtual Network operation (with Network Slicing Insights) 61 | Presenter: G. Grammel - Juniper/L. Young - Huawei 62 | Duration: 10 mins + 5 mins Q&A 63 | Abstract: This draft describes how ACTN can provide transport network resources based on the VN service and instantiation request from orchestrator that is in charge of orchestrating 5G network slicing. This is work in progress in the TEAS WG and it might be beneficial to your side meeting. Although it is YANG model, it is presented in the context of architecture’s point of view and what ACTN can contribute. 64 | https://datatracker.ietf.org/doc/draft-lee-teas-actn-vn-yang/?include_text=1 65 | 66 | 67 | ### Presentation 10: Automatic Network Slicing Management for Transport Network 68 | Presenter: Qiang Li - Huawei 69 | Duration: 10 mins + 5 mins Q&A 70 | Abstract: Coming soon 71 | 72 | ### Presentation 11: Managing Slices – Dynamic Control Plane Datastores 73 | Presenter: Susan Hares - Huawei 74 | Duration: 10 mins + 5 mins Q&A 75 | Abstract: One the important parts of network slides is network management of the slides. The dynamic nature of the network slices may not align with traditional network management. Traditional network management considers there is a box with a configuration file which aids the box to boot up and run. Fitting the dynamic nature of network slides into this tradition box may seem like putting a round peg into a square hole. Recently, the NETMOD, RESTCONF and the I2RS working groups have been working on a transformation of the traditional management system. A “revised-datastore” model suggest that beside a “configuration” for the box with traditional rules, there can be dynamic datastores with configuration. The rules on interaction between “datastores” are being developed. Other routing groups (TEAS, I2RS, RTGWG) have made use of this new concept in their yang data models for topology discover. My hope is this presentation will apprise those interested in NETSLICES on current IETF work that can be leveraged to accomplish your aids, and aid “gap analysis” needed for any charter development for a IETF BOF proposal. 76 | 77 | 78 | ### Final Q&A & Conclusions: 30 mins 79 | 80 | **Call for collaboration, contribution on** 81 | - Problem statement 82 | - Scope of the work 83 | - Work Priorities 84 | - Gap Analysis 85 | - Use cases & Requirements (multiple drafts) 86 | - Architectures / Reference Models (multiple drafts) 87 | - NS Capability Exposure (multiple drafts) 88 | - NS functions and operations (multiple drafts) 89 | - Terminology 90 | 91 | *Close Meeting* 92 | -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/agenda.txt: -------------------------------------------------------------------------------- 1 | Draft Agenda of Network Slicing side meeting at IETF98 2 | 3 | - Location: Room Vevey 1/2, 4 | - Date/Time: 2017.03.27, 18:15-21:15 5 | 6 | Scope of the NS meeting: 7 | Present and discuss use cases, architecture and identify technical problems to be address by future work at IETF. The place of such work either as part of re-scoping some exiting WG or a new dedicated WG is not part of this meeting. 8 | 9 | 1. Agenda bash 10 | Meeting Organisers: Alex Galis – UCL, J. Dong – Huawei, K. Makhijani-Huawei, Stewart Bryant – Huawei 11 | Chairs of the meeting Stewart Bryant – Huawei, Alex Galis - UCL 12 | Duration: 1-3 mins 13 | 14 | 2. Introductory Document and Revised Problem Statement walk through 15 | Presenter: Alex Galis - UCL/Stewart - Huawei 16 | Duration: 10 mins + 5 mins Q&A 17 | https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02 18 | 19 | I. Towards NS Use Cases 20 | 21 | 3. 5G Network Slicing - 3GPP Use Case background 22 | Presenter: Xavier DeFoy -InterDigital 23 | Duration: 10 mins + 5 mins Q&A 24 | https://datatracker.ietf.org/doc/html/draft-defoy-netslices-3gpp-network-slicing 25 | 26 | 4. Generalized Market/Service Verticals with Network Slicing Use cases 27 | Presenter: K. Makhijani- Huawei/J. Dongjie - Huawei 28 | Duration: 10 mins + 5 mins Q&A 29 | https://tools.ietf.org/html/draft-qin-netslices-use-cases-00 30 | 31 | 5. An ICN service delivery prototype using slices. 32 | Presenter: Ravi Ravindran - Huawei 33 | Duration: 10 mins + 5 mins Q&A 34 | 35 | II. Towards Operators Ecosystem Viewpoints 36 | 37 | 6. Network Slicing architecture 38 | Presenter: Liang Geng – China Mobile 39 | Duration: 10 mins + 5 mins Q&A 40 | 41 | https://datatracker.ietf.org/doc/draft-geng-netslices-architecture/ 42 | 43 | 7. Network Slicing: Technical Viewpoints and Functional Roles 44 | Presenter: Pedro Martinez-Julia - NICT (Japan) 45 | Duration: 10 mins + 5 mins Q&A 46 | https://github.com/netslices/IETF-NetSlices/raw/master/IETF98_Sidemeeting02/ietf98-netslices-pedro-nict.pdf 47 | 48 | 49 | III. Towards Manufactures Viewpoints 50 | 51 | 8. How to slice Network Slicing for the IETF 52 | Presenter: H. Flinck - Nokia 53 | Duration: 10 mins + 5 mins Q&A 54 | 55 | 9. ACTN Virtual Network operation (with Network Slicing Insights) 56 | Presenter: G. Grammel - Juniper/L. Young - Huawei 57 | Duration: 10 mins + 5 mins Q&A 58 | 59 | https://datatracker.ietf.org/doc/draft-lee-teas-actn-vn-yang/?include_text=1 60 | 61 | 10. Automatic Network Slicing Management for Transport Network 62 | Presenter: Qiang Li - Huawei 63 | Duration: 10 mins + 5 mins Q&A 64 | 65 | 11. Managing Slices – Dynamic Control Plane Datastores 66 | Presenter: Susan Hares - Huawei 67 | Duration: 10 mins + 5 mins Q&A 68 | 69 | 12. Final Q&A & Conclusions: 30 mins 70 | -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/call_for_contributions.txt: -------------------------------------------------------------------------------- 1 | NetSlices IETF 98: side meeting: Call for Contributions 2 | 3 | Hello all, 4 | We are planning to have another side-meeting to continue face to face 5 | discussions on the topic and are in the process of setting up agenda and 6 | inviting contributions from the community. 7 | Please send your contributions (such as usecases) and suggestions for discussion topics. 8 | 9 | In order to collaborate, we have setup github repository. Feel free to use this 10 | for reviews, document update and uploading your contributions. 11 | 12 | -- Main Repository 13 | https://github.com/netslices/IETF-NetSlices 14 | -- Folder for IETF98 side meeting 15 | https://github.com/netslices/IETF-NetSlices/IETF98_Sidemeeting02 16 | -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/ietf98-how-to-slice-flinck-nokia.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/ietf98-how-to-slice-flinck-nokia.pdf -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/ietf98-netslices-pedro-nict-summarized.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/ietf98-netslices-pedro-nict-summarized.pdf -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/ietf98-netslices-pedro-nict.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/ietf98-netslices-pedro-nict.pdf -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/meeting minutes: -------------------------------------------------------------------------------- 1 | Network Slicing Side Meeting in IETF98 2 | 2017.3.27 18:15-21:15, Vevey 1/2, Chicago 3 | 4 | Chairs: Stewart Bryant (Huawei), Alex Galis (UCL) 5 | 6 | Alex briefly introduces the purpose of the side meeting. 7 | 8 | 1. Introduction and problem statement , Alex 9 | Netslicing is not new, now move fast with 5G. 10 | Key characteristics of network slicing 11 | Network slicing work items at IETF 12 | Q&A: None 13 | 14 | 15 | 2. 3GPP 5G network slicing use cases, Xavier 16 | Introduce the architecture of NS in 3GPP 17 | Core network slicing 18 | RAN slicing: early study indicates mainly by preconfigured 19 | Q&A: 20 | Omar: In 3GPP, how many slices can be provided on the RAN side? 21 | Speaker: Don’t know 22 | Q: Does RAN selects core network slices? 23 | Speaker: No. RAN selects the functions of the core, CCNF chooses the core slice. 24 | Q: Does CCNF provide mobility management function? 25 | A: Yes. 26 | John Strassner: Is there a model driven approach to orchestration? Data comes from different parts of the networks. From management or orchestration point of view, have you done modeling of the functions, for interoperability? 27 | 3GPP-IETF liaison person: Be aware that deadline of Phase 1 of 5G in 3GPP is June 2018. The results from IETF should go hand in hand with 3GPP. 28 | Q: the title is use case, but content is more of architecture, would need more use cases to discuss. 29 | A: there is another use case draft to be presented. 30 | Hannu: From the presentation, what points are you pointing out for IETF to consider? 31 | Speaker: No answer for this yet. 32 | 33 | 34 | 3.Network Slicing use cases, Kiran 35 | eMBB: large bandwidth, VR/AR ask for low latency 36 | uRLLC: latency 37 | mMTC: 38 | other type use case: 39 | ask for contribution of use case 40 | Q&A: 41 | George: from 5G deployment point of view, it is also important to have vertical industry involved. 42 | 43 | 44 | 4. ICN use-case, Ravi 45 | Q&A: 46 | Q: Is this pure ICN or over IP? 47 | A: This is over IP. 48 | Q: Is SFC used in this slicing use case? 49 | A: Not really. User asks for content from some cache. But SFC may not be involved. 50 | 51 | 52 | 5. Network Slicing Architecture, Liang Geng 53 | Introduces reference architecture and key components of network slicing 54 | Q&A 55 | Q: what is the formal definition of network slice? 56 | A: combined resources of connectivity, network functions, computing, storage and some exposed provisioning. Another definition: Logical segment of networks. 57 | Q: slice can be small, medium and large. The current definition is too wide. Can we narrow down a little bit? 58 | A: Welcome input to the definition 59 | Igor: can we define net slice as distributed data centers? 60 | A: Need to include DCI. 61 | Sue: For dynamic control and management, the recent work on revised datastore etc. in netmod/netconf may be relevant, also the topology and rib models in i2rs and teas, suggest to consider align with these works in next step. 62 | 63 | 64 | 6. Network slicing, technique viewpoints and functional roles, Pedro 65 | Requirements: flexibility, plasticity, composability 66 | Q&A: none 67 | 68 | 69 | 7. How to slice network, a slicing for IETF, Hannu 70 | Q&A 71 | Q: NFV works on slicing but haven’t seen how that works. How IETF interacts with NFV? Do not reinvent what NFV does. 72 | Q: How does dynamic slicing work? 73 | A: It is orchestration work 74 | Jie: What does multi-cites mean? Is low latency slice just one of the use cases? 75 | A: Multi-site means topology not only p2p, but with customized connectivity. Yes low latency is just one case of transport slice, can be slices with other requirement. 76 | Q: there is a work being done on multi-domain orchestration and slicing (5GEX). 77 | 78 | 79 | 8. Autonomous Transport network, Qiang Li 80 | Q&A 81 | Igor: identify one of the gap: the function to discover, negotiate and abstract the view of the topology, there is related work in teas wg (ACTN). 82 | 83 | 84 | 9. ACTN and slicing, Gert 85 | What is network slicing, and what is not? 86 | Quote definition of network slicing in NFV 5G white paper 87 | What slices are not: probably a broadcast mechanism 88 | Q&A: none 89 | 90 | 91 | 10. FPSM in dmm, Satoru 92 | Enable separation of data and control plane functions of mobile network 93 | Coordination between transport and mobile functions/services to form network slice 94 | Q&A: none 95 | 96 | 97 | Open discussion: 98 | 1. Any of the topics relevant to IETF? A half in the room agree 99 | 2. Who is willing to work on document? Or who is willing to help to scope the work in IETF? Many 100 | 3. Should we build the charter for BoF at next IETF? Yes 101 | 102 | Dave Allan: Charter is good. Need to identify what is the scope, what is not in the scope of IETF. 103 | 104 | Young: TEAS and ACTN is making progress on network slicing (and telemetry), need to identify gaps 105 | 106 | Geroge: A charter is needed, and write down what is out of scope, and prioritize the work which is needed by other organizations. 107 | 108 | David Sinicrope: gap analysis should not only for IETF, but also understand what other people are doing with gap analysis, avoid overlapping with others, may liaison with ITU-T SG13. 109 | 110 | Stewart: Finding critical technical points within scope of IETF is important. 111 | 112 | George: IETF needs to provide input to 3GPP 113 | 114 | ??: The use cases can apply to non-5G and 5G, the scope of our work may not be limited by 3GPP 5G. 115 | 116 | 5G and non-5G, which use-cases are included in the scope? 117 | 118 | 5G – high capacity access network but it takes network and cloud. 119 | 120 | Peter Smith: Even without 5G, we still need an end-to-end network slicing mechanism. 121 | 122 | Kiran: Need to identify what should to be standardized in IETF, the charter. 123 | 124 | ??: Suggest to make the scope small so can match the pace of 5G requirement on slicing. 125 | 126 | Gert: Not sure we share a common view of network slice, would be good to clarify this. 127 | 128 | Dave Allan: Not sure IETF needs a unique definition of network slice. Suggest to use industry definition so that IETF can help the industry and find the unique value. 129 | 130 | Gert: Maybe find another term for network slice in IETF. 131 | -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/network-slicing-gert.ppt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/network-slicing-gert.ppt -------------------------------------------------------------------------------- /IETF98_Sidemeeting02/slides-98-dmm-draft-ietf-dmm-fpc-cpdp-1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/IETF98_Sidemeeting02/slides-98-dmm-draft-ietf-dmm-fpc-cpdp-1.pptx -------------------------------------------------------------------------------- /NS-WG_Charter-Draft 1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/NS-WG_Charter-Draft 1.pptx -------------------------------------------------------------------------------- /NS_drafts/draft-dong-network-slicing-problem-statement-00.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Network Working Group J. Dong 6 | Internet-Draft S. Bryant 7 | Intended status: Informational Huawei Technologies 8 | Expires: May 4, 2017 October 31, 2016 9 | 10 | 11 | Problem Statement of Network Slicing in IP/MPLS Networks 12 | draft-dong-network-slicing-problem-statement-00 13 | 14 | Abstract 15 | 16 | The research and standardization of IMT-2020 (a.k.a. 5G) are in 17 | progress in several industry communities and standard organizations. 18 | The goal of 5G is to integrate various services, each of which has a 19 | set of unique requirements, into a single network, such that each 20 | service has a customized network suited to its needs. The concept 21 | "Network Slicing" is widely discussed and considered as the key 22 | mechanism to meet the diverse service requirements concurrently with 23 | the same physical network infrastructure. This document provides an 24 | overview of the concept "network slicing" in the current IMT-2020 25 | (a.k.a. 5G) related works, and discusses the corresponding 26 | requirements on IP/MPLS network, which will be used as the mobile 27 | transport network for 5G. 28 | 29 | Requirements Language 30 | 31 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 | document are to be interpreted as described in RFC 2119 [RFC2119]. 34 | 35 | Status of This Memo 36 | 37 | This Internet-Draft is submitted in full conformance with the 38 | provisions of BCP 78 and BCP 79. 39 | 40 | Internet-Drafts are working documents of the Internet Engineering 41 | Task Force (IETF). Note that other groups may also distribute 42 | working documents as Internet-Drafts. The list of current Internet- 43 | Drafts is at http://datatracker.ietf.org/drafts/current/. 44 | 45 | Internet-Drafts are draft documents valid for a maximum of six months 46 | and may be updated, replaced, or obsoleted by other documents at any 47 | time. It is inappropriate to use Internet-Drafts as reference 48 | material or to cite them other than as "work in progress." 49 | 50 | This Internet-Draft will expire on May 4, 2017. 51 | 52 | 53 | 54 | 55 | 56 | Dong & Bryant Expires May 4, 2017 [Page 1] 57 | 58 | Internet-Draft Network Slicing Problem Statement October 2016 59 | 60 | 61 | Copyright Notice 62 | 63 | Copyright (c) 2016 IETF Trust and the persons identified as the 64 | document authors. All rights reserved. 65 | 66 | This document is subject to BCP 78 and the IETF Trust's Legal 67 | Provisions Relating to IETF Documents 68 | (http://trustee.ietf.org/license-info) in effect on the date of 69 | publication of this document. Please review these documents 70 | carefully, as they describe your rights and restrictions with respect 71 | to this document. Code Components extracted from this document must 72 | include Simplified BSD License text as described in Section 4.e of 73 | the Trust Legal Provisions and are provided without warranty as 74 | described in the Simplified BSD License. 75 | 76 | Table of Contents 77 | 78 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 79 | 2. Network Slicing Problem Statement . . . . . . . . . . . . . . 3 80 | 2.1. Isolation and Separation . . . . . . . . . . . . . . . . 3 81 | 2.2. Customization of the Topology . . . . . . . . . . . . . . 5 82 | 2.3. Flexibility of the Topology . . . . . . . . . . . . . . . 7 83 | 2.4. Guaranteed Quality of Service . . . . . . . . . . . . . . 7 84 | 2.5. Management Considerations . . . . . . . . . . . . . . . . 8 85 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 88 | 6. Informative References . . . . . . . . . . . . . . . . . . . 9 89 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 | 91 | 1. Introduction 92 | 93 | The research and standardization of IMT-2020 (a.k.a. 5G) are in 94 | progress in several industry communities and standard organizations. 95 | The goal of 5G is to integrate various services, each of which has a 96 | set of unique requirements, into a single network, such that each 97 | service has a customized network suited to its needs. The concept 98 | "Network Slicing" is widely discussed and considered as the key 99 | mechanism to meet diverse service requirements concurrently with the 100 | same physical network infrastructure. 101 | 102 | The Next Generation Mobile Networks (NGMN) gives the definition of 103 | network slice in [Network-Slicing-Concept]: 104 | 105 | "Network Slice Instance: a set of network functions, and resources to 106 | run these network functions, forming a complete instantiated logical 107 | network to meet certain network characteristics required by the 108 | Service Instance(s)." 109 | 110 | 111 | 112 | Dong & Bryant Expires May 4, 2017 [Page 2] 113 | 114 | Internet-Draft Network Slicing Problem Statement October 2016 115 | 116 | 117 | [TR23.799] of 3rd Generation Partnership Project (3GPP) identifies 118 | the support of network slicing as one of the key issues to be 119 | resolved in the NextGen system: 120 | 121 | "Network slicing enables the operator to create networks customised 122 | to provide optimized solutions for different market scenarios which 123 | demands diverse requirements, e.g. in the areas of functionality, 124 | performance and isolation." 125 | 126 | In Focus Group (FG) IMT-2020, which is the Focus Group in ITU-T 127 | working on 5G transport network, network slicing is discussed in the 128 | Network Softwarization work item. [FG-IMT2020-Gaps] gives the 129 | definition of slicing: Slicing allows logically isolated network 130 | partitions (LINP) with a slice being considered as a unit of 131 | programmable resources such as network, computation and storage. 132 | 133 | In order to meet the diverse service requirements, end-to-end network 134 | slicing is required in 5G, which includes the slicing of the User 135 | Equipment (UE), Radio Access Network (RAN), mobile Core network and 136 | also the mobile transport network. As one of the widely deployed 137 | mobile transport networks, IP/MPLS networks need to provide the 138 | functionality and capability required by network slicing. 139 | 140 | 2. Network Slicing Problem Statement 141 | 142 | This section analyzes the requirements of network slicing on IP/MPLS 143 | networks, and identifies the potential gaps between the existing 144 | mechanisms and the network slicing requirements. 145 | 146 | In IP/MPLS networks, Virtual Private Network (VPN) has been widely 147 | deployed to provide many different virtual networks on the same 148 | physical operator network. It would be beneficial to reuse the 149 | existing VPN technologies when possible, with some enhancements from 150 | the newly developed technologies such as SDN, NFV, SFC etc., to meet 151 | the network slicing requirements. However, the method used to share 152 | the resources of the underlying network with the VPNs results in 153 | competition for resources between the VPNs, which can make it 154 | difficult to provide the degree of isolation and performance needed 155 | by some services. These issues are explored in greater detail in the 156 | following sections. 157 | 158 | 2.1. Isolation and Separation 159 | 160 | Network slicing provides a method that allows services with diverse 161 | requirements to be provided on the same physical network with greater 162 | independence than is usually provided in a packet switching network. 163 | Each network slice appears to its users as an independent, dedicated 164 | private network which is impervious to anything that is happening on 165 | 166 | 167 | 168 | Dong & Bryant Expires May 4, 2017 [Page 3] 169 | 170 | Internet-Draft Network Slicing Problem Statement October 2016 171 | 172 | 173 | any of the other network slices. This requires a higher degree of 174 | isolation than is found in a conventional VPN where traffic patterns 175 | in one VPN can increase the latency and jitter in another VPN, and 176 | where the shared control plane means that a high workload servicing 177 | one VPN can result in less responsiveness to another VPN. The 178 | isolation and other service requirements of each user service are 179 | likely to be different,and it is important that this is represented 180 | in the slices that carry these services to provide an efficient and 181 | economic network design. 182 | 183 | Where 5G is used as the bearer service for real time traffic in 184 | applications such as Autonomous Driving, Virtual Reality or 185 | industrial control, there is a requirement for ultra-low transport 186 | latency and guaranteed bandwidth. In such cases, dedicated data- 187 | plane resources may be needed to guarantee the performance of the 188 | network slices carrying these services. This allows a high degree of 189 | isolation between the network slices so that the required performance 190 | is always met even when there is congestion or some other type of 191 | degradation occurs in other network slices sharing the same 192 | underlying packet network. 193 | 194 | In addition to the data plane isolation requirement described above, 195 | we need to consider the control plane isolation requirements of the 196 | various network slices. As with the data plane isolation, the 197 | required degree of isolation in control plane will also depend on the 198 | application requirements. There are essentially three degrees of 199 | control plane isolation that need to be considered: dedicated control 200 | plane, hybrid control plane and shared control plane. A dedicated 201 | control plane can provide control plane performance guarantees, and 202 | allows customization of the control functions, which may be required 203 | for the provisioning and optimization of some critical services. 204 | With a hybrid control plane, some of the control functions are 205 | dedicated to each network slice, while others are shared amongst a 206 | number of network slices. The hybrid approach provides a flexible 207 | way of achieving the balance between performance and efficiency. 208 | With shared control plane, the network slices use the same control 209 | plane functions and resources, regardless of whether their data plane 210 | are isolated or not. This results in competition between network 211 | slices for resources and thus less isolation. In this case, a high 212 | computation or high bandwidth event in one slice will result in less 213 | responsivity in another slice. 214 | 215 | It is anticipated that many third-party or vertical industrial 216 | networks will be created or migrated onto the 5G network. These 217 | third-party or industrial services will be provided with different 218 | network slices, and will typically have different requirements on the 219 | operation and management of their own network slice. For some of the 220 | services, the operation and management of the network slices can be 221 | 222 | 223 | 224 | Dong & Bryant Expires May 4, 2017 [Page 4] 225 | 226 | Internet-Draft Network Slicing Problem Statement October 2016 227 | 228 | 229 | simply delegated to the network operator, as long as the performance 230 | requirements and relative isolation of the network slices can be 231 | guaranteed. This is much as happens with today's VPN networks. 232 | However, for some other services, it is expected that the owner of 233 | the service will require more control of the network slice, such as 234 | the placement of the network functions, the establishment and 235 | selection of the transport path, network resource allocation, etc. 236 | In order to meet these requirements, network needs to provide 237 | mechanisms to allow the third parties to configure, deploy and manage 238 | their own network slice, with minimal intervention from the network 239 | operator. 240 | 241 | The different services will each have their own level of security 242 | requirements and will probably deploy different security mechanisms. 243 | For many applications the network slice must provide protection 244 | against interception of traffic or interruption of service, by 245 | unauthorised users. However security is always a balance between the 246 | performance, complexity and resources needed, and the economics of 247 | the service, including in the case of some Internet of Things (IoT) 248 | the energy consumption requirements. The security requirements of 249 | the service carried of the network slices may be markedly different 250 | and the design needs to accommodate this. What is of critical 251 | importance is that each slice is impervious to an attack on any or 252 | all of the other network slices. Thus for example if there is a DDoS 253 | attack on the elements of one slice, there MUST NOT be any impact on 254 | the data plane or control plane of the other network slices. 255 | 256 | The IP/MPLS network that is the bearer of these network slices needs 257 | to provide the mechanisms required to meet the diverse isolation 258 | requirements in data plane, control plane, network operation and 259 | security. Existing VPN technologies use a mixture of logical 260 | separation, and rely on network traffic engineering, either through 261 | metric tuning, RSVP, or Segment Routing to provide a degree of 262 | traffic isolation. However the isolation is only partial since the 263 | VPNs compete for the same resources. Thus to provide the enhanced 264 | degree of isolation needed to support more demanding service 265 | requirements, a greater degree of isolation needs to be provided by 266 | the packet network than is currently. 267 | 268 | 2.2. Customization of the Topology 269 | 270 | In order to provide the bespoke network structure needed by each of 271 | the network service domains, it is necessary to provide each of the 272 | network slices with its own customized topology. There are a number 273 | of well known methods of providing a virtual topology that can be 274 | used to customize the topology: 275 | 276 | o Multi-topology Routing 277 | 278 | 279 | 280 | Dong & Bryant Expires May 4, 2017 [Page 5] 281 | 282 | Internet-Draft Network Slicing Problem Statement October 2016 283 | 284 | 285 | o Virtual Private Networks 286 | 287 | o Overlay Networks 288 | 289 | o Segment Routing 290 | 291 | Multi-topology Routing (MTR) [RFC4915], [RFC5120], [RFC7307] is a way 292 | of causing the underlying routing layer to concurrently form multiple 293 | topologies over the physical network either applying a path metric to 294 | a link that is specified per topology and computing a shortest path 295 | tree that is customised to that topology. Another technique is to 296 | use a different ships in the night routing protocol such as Maximally 297 | Redundant Trees [RFC7812]. MRT relies on a common routing protocol 298 | and a common compute engine to maintain the topology. MRT has only 299 | limited application to specialist problems. In neither case is there 300 | integration with the data-plane to maintain isolation between the 301 | slices. Furthermore it can be difficult to set up and maintain the 302 | metrics to get the degree of topology control needs by the various 303 | services. In both cases a characteristic of the user packet needs to 304 | be used to mark the packet into the correct topology. 305 | 306 | VPNs are often used to create virtual topologies which separate and 307 | isolate the traffic of different users or services. In some VPNs 308 | [RFC4364] , [RFC4761], [RFC7432] a common control plane is used to 309 | run the topology of the VPN and the topology of the bearer or 310 | transport network. Where a separate protocol instance is used, for 311 | example as a separate instance of BGP, the control plane of each 312 | instance is isolated, but the control traffic and the user traffic of 313 | all the instances normally fate shares. If the control plane engages 314 | with a resource reservation protocol such as RSVP a further degree of 315 | isolation is possible, but this may not be sufficient for the most 316 | sensitive applications. 317 | 318 | A overlay network is normally completely independent of the underlay 319 | that provides it with transport services, and normally with no 320 | coupling of the routing/signalling protocols and no way to reserve 321 | the resources in the underlying data plane, the required degree of 322 | isolation is not achieved for the most sensitive applications. 323 | Furthermore with this approach the applications have no control over 324 | the paths that their packets take across the network. 325 | 326 | Segment routing (SR) [I-D.ietf-spring-segment-routing] is a technique 327 | that bares further consideration in this application space. With the 328 | strict source routing approach it is possible for an edge node to 329 | precisely specify the network path for its traffic. With loose 330 | source routing less control is available and it is a matter of 331 | further study whether this provides the degree of isolation needed in 332 | the network slicing environment. It is possible to have in effect a 333 | 334 | 335 | 336 | Dong & Bryant Expires May 4, 2017 [Page 6] 337 | 338 | Internet-Draft Network Slicing Problem Statement October 2016 339 | 340 | 341 | control plane and topology per service with the SR approach. However 342 | there would need to be co-ordination between the entity creating the 343 | topologies and some entity managing the resources in the network. 344 | The use of this approach needs further study. 345 | 346 | 2.3. Flexibility of the Topology 347 | 348 | As described by NGMN, a network slice is formed by a set of network 349 | functions, and resources to run these network functions. With the 350 | introduction of Network Function Virtualisation (NFV) and Mobile Edge 351 | Computing (MEC), the network functions can be dynamically created at 352 | different locations, and can migrate from one place to another 353 | dynamically. The flexible and dynamic positioning of network 354 | functions in a network slice requires that the IP/MPLS networks be 355 | enhanced to have the capability of dynamically provisioning the 356 | customized network slice topology with on demand connectivity 357 | instantiated between the network functions. 358 | 359 | The requirements is for existing topologies to be modified and new 360 | topologies added without any disruption to the other operating 361 | topologies. This will require particular attention to the impact on 362 | the data plane since reconfiguration of a topology of a network slice 363 | may lead to detectable changes, possibly transient, possibly 364 | permanent in the forwarding behaviour of other network slices. 365 | 366 | 2.4. Guaranteed Quality of Service 367 | 368 | 5G aims to provide diversified services on the same physical network. 369 | One important type of 5G service is mission critical communication. 370 | The typical use cases for this are autonomous driving, remote surgery 371 | and industrial control systems, etc, which currently require direct 372 | point to point communication, or a dedicated network over fixed 373 | infrastructure. These services have stringent requirements on 374 | latency, jitter, bandwidth, availability and reliability, etc. It is 375 | thus necessary that network slices used to carry mission critical 376 | services provide end-to-end guaranteed performance. In addition, 377 | some enhanced Mobile BroadBand (eMBB) services such as Virtual 378 | Reality (VR) which are also the target of 5G operators require 379 | transport latency to be at the millisecond (ms) level, and the 380 | bandwidth requirement will be several hundreds of Mbps. 381 | 382 | With the exception of service carried over traffic engineered label 383 | switched paths (LSPs) using resource reservation for that LSP, 384 | existing VPN technologies share the resources of the underlying 385 | network with other VPNs results in competition for resources between 386 | them, which makes it difficult to provide the degree of performance 387 | needed by the mission critical services. Even when traffic 388 | engineering solutions are deployed, there is short term contention 389 | 390 | 391 | 392 | Dong & Bryant Expires May 4, 2017 [Page 7] 393 | 394 | Internet-Draft Network Slicing Problem Statement October 2016 395 | 396 | 397 | for bandwidth making it difficult to achieve the very low latencies 398 | some of these proposed new services demand. 399 | 400 | [DETNET-WG] is working on the deterministic data paths over layer 2 401 | and layer 3 network segments, such deterministic paths can provide 402 | the bounds on latency, loss, and packet delay variation (jitter), and 403 | high reliability that are required. Network slices of an IP/MPLS 404 | network may take advantage of the mechanisms defined in Detnet to 405 | meet the performance requirement of 5G services. 406 | 407 | 2.5. Management Considerations 408 | 409 | As the sliced network evolves it will be necessary to provision, de- 410 | provision and modify network slices. Great care needs to exercised 411 | in this so as to avoid disrupting other slices. This is a more 412 | difficult problem than we have historically addressed, except perhaps 413 | in the case of specialist time transfer services, because changes in 414 | topology can impact the latency of traffic running in the network. 415 | The temptation is to avoid this by freezing the paths of existing 416 | services. However the danger is that as the network ages, it will 417 | become stale with resources stranded because the running services are 418 | unable to be modified for fear of disrupting them, whilst new 419 | services cannot be provisioned because it is not possible to glean 420 | the resources they need from the fragments of discontinued services. 421 | Some form of dynamic garbage collection may therefore be needed that 422 | operates in such a way as not to introduce a transient into running 423 | network slices. 424 | 425 | 3. IANA Considerations 426 | 427 | This document makes no request of IANA. 428 | 429 | Note to RFC Editor: this section may be removed on publication as an 430 | RFC. 431 | 432 | 4. Security Considerations 433 | 434 | The security of traffic into and over an network slice needs to be 435 | addressed by the owner of the network slice, and it is expected that 436 | this would use state of the art methods. Because of the diversity of 437 | requirements these are outside the scope of this document. 438 | 439 | The security of the slices themselves is an important consideration 440 | in the design and operation of the network slicing technology. It is 441 | important that an attack on the network slicing system is not used as 442 | a method of disrupting, a targeted network slice, which may be of 443 | high value, or of a critical nature, possibly with safety of life 444 | consequences. 445 | 446 | 447 | 448 | Dong & Bryant Expires May 4, 2017 [Page 8] 449 | 450 | Internet-Draft Network Slicing Problem Statement October 2016 451 | 452 | 453 | The nature of the vulnerability of a network slice may be more subtle 454 | that we are ordinarily concerned with. Given the delay sensitive 455 | nature of the traffic being carried over some network slices a 456 | relatively minor congestion or modulated congestion may be sufficient 457 | to cause disruption to the slice. It is therefore important to 458 | police the ingress traffic of all services, and to take precautions 459 | to protect any traffic metering technology deployed. 460 | 461 | 5. Acknowledgements 462 | 463 | TBD 464 | 465 | 6. Informative References 466 | 467 | [DETNET-WG] 468 | "IETF Detnet Working Group", 2016, 469 | . 470 | 471 | [FG-IMT2020-Gaps] 472 | "FG IMT-2020: Report on Standards Gap Analysis", 2015, 473 | . 474 | 475 | [I-D.ietf-spring-segment-routing] 476 | Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 477 | and R. Shakir, "Segment Routing Architecture", draft-ietf- 478 | spring-segment-routing-09 (work in progress), July 2016. 479 | 480 | [Network-Slicing-Concept] 481 | "Description of Network Slicing Concept", 2016, 482 | . 484 | 485 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 | Requirement Levels", BCP 14, RFC 2119, 487 | DOI 10.17487/RFC2119, March 1997, 488 | . 489 | 490 | [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 491 | Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 492 | 2006, . 493 | 494 | [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 495 | LAN Service (VPLS) Using BGP for Auto-Discovery and 496 | Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 497 | . 498 | 499 | 500 | 501 | 502 | 503 | 504 | Dong & Bryant Expires May 4, 2017 [Page 9] 505 | 506 | Internet-Draft Network Slicing Problem Statement October 2016 507 | 508 | 509 | [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 510 | Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 511 | RFC 4915, DOI 10.17487/RFC4915, June 2007, 512 | . 513 | 514 | [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 515 | Topology (MT) Routing in Intermediate System to 516 | Intermediate Systems (IS-ISs)", RFC 5120, 517 | DOI 10.17487/RFC5120, February 2008, 518 | . 519 | 520 | [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 521 | King, "LDP Extensions for Multi-Topology", RFC 7307, 522 | DOI 10.17487/RFC7307, July 2014, 523 | . 524 | 525 | [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 526 | Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 527 | Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 528 | 2015, . 529 | 530 | [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 531 | IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 532 | FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 533 | . 534 | 535 | [TR23.799] 536 | "Study on Architecture for Next Generation System", 2012, 537 | . 539 | 540 | Authors' Addresses 541 | 542 | Jie Dong 543 | Huawei Technologies 544 | 545 | Email: jie.dong@huawei.com 546 | 547 | 548 | Stewart Bryant 549 | Huawei Technologies 550 | 551 | Email: stewart.bryant@gmail.com 552 | 553 | 554 | 555 | 556 | 557 | 558 | 559 | 560 | Dong & Bryant Expires May 4, 2017 [Page 10] 561 | -------------------------------------------------------------------------------- /NS_drafts/draft-gdmb-netslices-intro-and-ps-02.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | No Working Group A. Galis 6 | Internet-Draft University College London 7 | Intended status: Informational J. Dong 8 | Expires: July 23, 2017 K. Makhijani 9 | S. Bryant 10 | Huawei Technologies 11 | M. Boucadair 12 | Orange 13 | P. Martinez-Julia 14 | NICT 15 | February 14, 2017 16 | 17 | 18 | Network Slicing - Introductory Document and Revised Problem Statement 19 | draft-gdmb-netslices-intro-and-ps-02 20 | 21 | Abstract 22 | 23 | This document introduces Network Slicing problems and the motivation 24 | for new work areas. It represents an initial revision of the Network 25 | Slicing problem statement derived from the analysis of the technical 26 | gaps in IETF protocols ecosystem. It complements and brings together 27 | the silo efforts being carried out in several other IETF working groups 28 | to achieve certain aspects of Network Slicing functions and operations. 29 | 30 | Status of This Memo 31 | 32 | This Internet-Draft is submitted in full conformance with the 33 | provisions of BCP 78 and BCP 79. 34 | 35 | Internet-Drafts are working documents of the Internet Engineering 36 | Task Force (IETF). Note that other groups may also distribute 37 | working documents as Internet-Drafts. The list of current Internet- 38 | Drafts is at http://datatracker.ietf.org/drafts/current/. 39 | 40 | Internet-Drafts are draft documents valid for a maximum of six months 41 | and may be updated, replaced, or obsoleted by other documents at any 42 | time. It is inappropriate to use Internet-Drafts as reference 43 | material or to cite them other than as "work in progress." 44 | 45 | This Internet-Draft will expire on July 23, 2017. 46 | 47 | Copyright Notice 48 | 49 | Copyright (c) 2017 IETF Trust and the persons identified as the 50 | document authors. All rights reserved. 51 | 52 | This document is subject to BCP 78 and the IETF Trust's Legal 53 | Provisions Relating to IETF Documents 54 | (http://trustee.ietf.org/license-info) in effect on the date of 55 | publication of this document. Please review these documents 56 | 57 | 58 | 59 | Galis, et al. Expires July 23, 2017 [Page 1] 60 | 61 | 62 | Internet-Draft NS Intro and PS January 2017 63 | 64 | 65 | carefully, as they describe your rights and restrictions with respect 66 | to this document. Code Components extracted from this document must 67 | include Simplified BSD License text as described in Section 4.e of 68 | the Trust Legal Provisions and are provided without warranty as 69 | described in the Simplified BSD License. 70 | 71 | Table of Contents 72 | 73 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 | 1.1. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 | 2. Suggested Problems and Work Areas . . . . . . . . . . . . . . 4 76 | 2.1. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 | 3. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 | 7.2. Informative References . . . . . . . . . . . . . . . . . 9 84 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 | 86 | 1. Introduction 87 | 88 | Network Slicing (NS) refers to the managed partitions of physical 89 | and/or virtual network resources, network physical/virtual and 90 | service functions [RFC7665] that can act as an independent instance 91 | of a connectivity network and/or as a network cloud. Network resources 92 | include connectivity, compute, and storage resources. 93 | 94 | Network Slices considerably transform the networking perspective by 95 | abstracting, isolating, orchestrating, softwarizing, and separating 96 | logical network components from the underlying physical network 97 | resources and as such they enhance Internet architecture principles 98 | ([RFC1958], [RFC3439], [RFC3234]). 99 | 100 | The management plane creates the grouping of network resources (whereby 101 | network resources can be physical, virtual or a combination thereof), 102 | it connects with the physical and virtual network and service functions 103 | ([SFC WG]) as appropriate, and it instantiates all of the network and 104 | service functions assigned to the slice. On the other hand, for slice 105 | operations, the slice control plane takes over the control and governing 106 | of all the network resources, network functions, and service functions 107 | assigned to the slice. It (re-) configures them as appropriate and as per 108 | elasticity needs, in order to provide an end-to-end service. In particular, 109 | ingress routers are configured so that appropriate traffic is bound to 110 | the relevant slice. Identification means for the traffic may be simple 111 | (relying on a subset of the transport coordinate, DSCP/traffic class, or 112 | flow label), or identification may be a more sophisticated one (to be 113 | further defined). Also, the traffic capacity that is specified for a slice 114 | can be changed dynamically, based on some events (e.g. triggered by a 115 | service request). The slice control plane is responsible for instructing 116 | the involved elements to honor such needs. 117 | 118 | Network operators can use NS to enable different services to receive 119 | different treatment and to allow the allocation and release of network 120 | resources according to the context and contention policy of the operators. 121 | Such an approach using NS would allow significant reduction of the operations 122 | expenditure. In addition NS makes possible softwarization, programmability 123 | ([RFC7149]), and the innovation necessary to enrich the offered services. 124 | Network softwarization techniques [IMT2020-2015], [IMT2020-2016] may be used 125 | 126 | 127 | 128 | Galis, et al. Expires July 23, 2017 [Page 2] 129 | 130 | Internet-Draft NS Intro and PS January 2017 131 | 132 | 133 | to realise and manage [MANO-2014] network slicing. NS provides the 134 | means for the network operators to provide network programmable 135 | capabilities to both OTT providers and other market players without 136 | changing their physical infrastructure. NS enables the concurrent 137 | deployment of multiple logical, self-contained and independent, 138 | shared or partitioned networks on a common infrastructure. Slices 139 | may support dynamic multiple services, multi-tenancy, and the 140 | integration means for vertical market players (e.g. automotive 141 | industry, energy industry, healthcare industry, media and 142 | entertainment industry, etc.) 143 | 144 | The purpose of the NS work in IETF is to develop a set of protocols and/ 145 | or protocol extensions that enable efficient slice creation, 146 | activation / deactivation, composition, elasticity, coordination / 147 | orchestration, management, isolation, guaranteed SLA, and safe and secure 148 | operations within a connectivity network or network cloud / data centre 149 | environment that assumes an IP and/or MPLS-based underlay. 150 | 151 | While there are isolated efforts being carried out in several IETF 152 | working groups Network WG [I-D.leeking-actn-problem-statement 03], TEAS WG 153 | [I-D.teas-actn-requirements-04], [I-D.dong-network-slicing-problem-statement], 154 | ANIMA WG [I-D.galis-anima-autonomic-slice-networking], [IETF-Slicing1], 155 | [IETF-Slicing2], [IETF-Slicing3], [IETF-Slicing4], [IETF-Slicing5],[IETF- 156 | Mobility], [IETF-Virtualization], [IETF-Coding], [IETF-Anchoring] to 157 | achieve certain aspects of network slice functions and operations, 158 | there is a clear need to look at the complete life-cycle management 159 | characteristics of Network Slicing solutions though the discussions 160 | based on the following architectural tenets: 161 | 162 | o Underlay tenet: support for an IP/MPLS-based underlay data plane the 163 | transport network used to carry that underlay. 164 | 165 | o Governance tenet: a logically centralized authority for network 166 | slices in a domain. 167 | 168 | o Separation tenet: slices may be independent of each other and have 169 | an appropriate degree of isolation (note 1) from each other. 170 | 171 | o Capability exposure tenet: each slice allows third parties to 172 | access via dedicated interfaces and /or APIs information regarding 173 | services provided by the slice (e.g., connectivity information, mobility, 174 | autonomicity, etc.) within the limits set by the operator. 175 | 176 | NS approaches that do not adhere to these tenets are explicitly 177 | outside of the scope of the proposed work at IETF. 178 | 179 | In pursuit of the solutions described above, there is a need to 180 | document an architecture for network slicing within both wide area 181 | network and data center environments. 182 | 183 | 184 | 185 | 186 | 187 | Galis, et al. Expires July 23, 2017 [Page 3] 188 | 189 | 190 | Internet-Draft NS Intro and PS January 2017 191 | 192 | 193 | Elicitation of requirements ([RFC2119], [RFC4364]) for both Network 194 | Slice control and management planes will be needed, facilitating 195 | the selection, extension, and/or development of the protocols for each 196 | of the functional interfaces identified to support the architecture. 197 | 198 | Additionally, documentation on the common use-cases for slice 199 | validation for 5G is needed, such as mission-critical ultra-low latency 200 | communication services; massive-connectivity machine communication 201 | services (e.g. smart metering, smart grid and sensor networks); extreme 202 | QoS; independent operations and management; independent cost and/or 203 | energy optimisation; independent multi-topology routing; multi-tenant 204 | operations; etc. 205 | 206 | The proposed NS work would be coordinated with other IETF WGs (e.g. 207 | TEAS WG, DETNET WG, ANIMA WG, SFC WG, NETCONF WG, SUPA WG, NVO3 WG, 208 | DMM WG, Routing Area WG (RTGWG), Network Management Research Group 209 | (NMRG)and NFV Research Group (NFVRG)) to ensure that the commonalities 210 | and differences in solutions are properly considered. Where suitable 211 | protocols, models or methods exist, they will be preferred over 212 | creating new ones. 213 | 214 | 1.1. Notes 215 | 216 | (1) This issue requires efficient interaction between an upper layer 217 | in the hierarchy and a lower layer for QoS guarantees and for most 218 | of the operations on slicing. 219 | 220 | 2. Suggested Problems and Work Areas 221 | 222 | The goal of this proposed work is to develop one or more protocol 223 | specifications (or extensions to existing protocols) to address specific 224 | slicing problems that are not met by the existing tools. The following 225 | problems were selected according to the analysis of the technical gaps in 226 | IETF protocols ecosystem. 227 | 228 | o Uniform Reference Model for Network Slicing (Architecture document): 229 | Describes all of the functional elements and instances of a network slice. 230 | Describes shared non-sliced network parts. Establishes the boundaries to the 231 | basic network slice operations (creation, management, exposure, consumption). 232 | Describes the minimum functional and non-functional roles derived from basic 233 | network slice operations including infrastructure owner (creation, exposure, 234 | management), slice operator (exposure, management, consumption), slice user 235 | (management, consumption). Describe the interactions between infrastructure 236 | owner -- slice operator, slice operator -- slice operator, slice operator -- 237 | slice user. Additionally, this working area will normalize nomenclature and 238 | definitions for Network Slicing. 239 | 240 | o Review common scenarios from the requirements for operations and 241 | interactions point of view. Describes the roles (owner, operator, user) which 242 | are played by entities with single /multiple entities playing different roles. 243 | 244 | 245 | o Slice Templates: Design the slices to different scenarios 246 | ([ChinaCom-2009], [GENI-2009], [IMT2020-2016bis], [NGMN-2016], 247 | [NGS-3GPP-2016], [ONF-2016]); Outlines an appropriate slice template 248 | definition that may include capability exposure of managed partitions 249 | of network resources (i.e. connectivity ([CPP]), compute and storage 250 | resources), physical and/or virtual network and service functions that can 251 | act as an independent connectivity network and/or as a network cloud. 252 | 253 | 254 | 255 | 256 | 257 | Galis, et al. Expires July 23, 2017 [Page 4] 258 | 259 | 260 | Internet-Draft NS Intro and PS January 2017 261 | 262 | 263 | o Network Slice capabilities (where some prioritization may be 264 | needed) are expected to be: 265 | 266 | * Four-dimensional efficient slice creation with guarantees for 267 | isolation in each of the Data /Control /Management /Service 268 | planes. Enablers for safe, secure and efficient multi-tenancy 269 | in slices. 270 | 271 | * Methods to enable diverse requirements for NS including 272 | guarantee for the end-to-end QoS of service in a slice. 273 | 274 | * Efficiency in slicing: specifying policies and methods to realize 275 | diverse requirements without re-engineering the infrastructure. 276 | 277 | * Recursion: namely methods for NS segmentation allowing a slicing 278 | hierarchy with parent - child relationships. 279 | 280 | * Customized security mechanisms per slice. 281 | 282 | * Methods and policies to manage the trade-offs between flexibility 283 | and efficiency in slicing. 284 | 285 | * Optimisation: namely methods for network resources automatic 286 | selection for NS; global resource view formed; global energy view 287 | formed; Network Slice deployed based on global resource 288 | and energy efficiency; Mapping algorithms. 289 | 290 | * Monitoring status and behaviour of NS in a single and/or 291 | muti-domain environment; NS interconnection. 292 | 293 | * Capability exposure (e.g. openness) for NS; plus APIs for slices. 294 | 295 | * Programmability and control of Network Slices. 296 | 297 | o Network slice operations (again some prioritization may be needed) are 298 | expected to be: 299 | 300 | * Slice life cycle management including creation, 301 | activation / deactivation, protection (note 2), elasticity (note 3), 302 | extensibility (note 4), safety (note 5), sizing and scalability of the 303 | slicing model per network and per network cloud: slices in access, core 304 | and transport networks; slices in data centres, slices in edge clouds. 305 | 306 | * Autonomic slice management and operation: namely self-configuration, 307 | self-composition, self-monitoring, self-optimisation, 308 | self-elasticity are carried as part of the slice protocols. 309 | 310 | 311 | 312 | Galis, et al. Expires July 23, 2017 [Page 5] 313 | 314 | 315 | Internet-Draft NS Intro and PS January 2017 316 | 317 | 318 | 319 | 320 | * Slice stitching / composition: having enablers and methods for 321 | efficient stitching /composition/ decomposition of slices: 322 | - vertically (service + management + control planes) and/or 323 | - horizontally (between different domains part of access, 324 | core, edge segments) and /or 325 | - vertically + horizontally. 326 | 327 | * End-to-end network segments and network clouds orchestration 328 | of slices ([GUERZONI-2016], [KARL-2016]). 329 | 330 | * Service Mapping: having dynamic and Automatic Mapping of Services to 331 | slices; YANG models for slices. 332 | 333 | o Describe the enablers and methods for the above mentioned capabilities 334 | and operations from different viewpoints on slices (note 6). 335 | 336 | o Efficient enablers and methods for integration of above capabilities and 337 | operations. 338 | 339 | 2.1. Notes 340 | 341 | (2) Protection refers to the related mechanisms so that events within 342 | one slice, such as congestion, do not have a negative impact on 343 | another slice. 344 | 345 | (3) Elasticity refers to the mechanisms and triggers for the growth 346 | /shrinkage of network resources, and/or network and service functions. 347 | 348 | (4) Extensibility refers to the ability to expand a NS with 349 | additional functionality and/or characteristics, or through the 350 | modification of existing functionality/characteristics, while 351 | minimizing impact to existing functions. 352 | 353 | (5) Safety refers to the conditions of being protected against 354 | different types and the consequences of failure, error harm or any 355 | other event, which could be considered non-desirable. 356 | 357 | (6) Multiple viewpoints on slices: I) viewpoint of the slice's owner 358 | towards user: from this viewpoint a slice is defined as a means to 359 | "split" physical or virtual infrastructure elements to "service" smaller 360 | portions. This action would be recursively done from the owner of the initial and 361 | physical infrastructure element to the users. II) viewpoint of from the user towards 362 | the physical infrastructure owner. From this viewpoint a slice is viewed just as a 363 | set of resources that must be managed (requests to a provider, listed, changed, 364 | returned to the provider, etc.). This viewpoint emphasizes those issues that would 365 | be used in the SLA definition of a slice. 366 | 367 | 368 | 369 | 370 | Galis, et al. Expires July 23, 2017 [Page 6] 371 | 372 | 373 | Internet-Draft NS Intro and PS January 2017 374 | 375 | 376 | 377 | 378 | 3. Documents 379 | 380 | The following are the proposed / expected / resulting documents with 381 | priority (I) or (II) (we note that revised prioritization may be needed): 382 | 383 | o (I) Agreed work plan 384 | 385 | o (I) NS Architecture document 386 | - Slice template and reference model to IESG (Informational) 387 | 388 | o (I) NS Exposure Interface specification and Data model 389 | - Slice life-cycle management model and NS Exposure Interface 390 | specification to IESG (Informational) 391 | - YANG data model for slicing. 392 | 393 | o (I) Service Requirement to Network Capability Mapping Data Model 394 | - Requirements for both NS control and management planes. 395 | - Common use-cases for slice validation for 5G. 396 | 397 | o (I) Four dimensional efficient slice isolation with guarantees for 398 | isolation in each of the Data/ Control/ Management/ Service planes. 399 | 400 | o (II) Methods to enable diverse requirements for NS including 401 | guarantee for the end-to-end QoS of a slice. 402 | 403 | o (I) End-to-end coordination and orchestration of slices. 404 | 405 | o (II) Customized security mechanisms per slice. 406 | 407 | o (I) Slice stitching / composition: enablers for efficient stitch / 408 | composition / decomposition of slices vertically, horizontally and 409 | vertically + horizontally. This item covers considerations related to 410 | interconnecting slices that are bond the same administrative domain or 411 | interconnecting multi-administrative domain. 412 | 413 | 4. Security Considerations 414 | 415 | Security will be a major part of the design of network slicing. 416 | 417 | 5. IANA Considerations 418 | 419 | This document requests no IANA actions. 420 | 421 | 6. Acknowledgements 422 | 423 | Thanks to Sheng Jiang (Huawei Technologies), Hannu Flinck (Nokia), 424 | Kevin Smith (Vodafone) for reviewing this draft. 425 | 426 | 427 | 428 | 429 | 430 | 431 | Galis, et al. Expires July 23, 2017 [Page 7] 432 | 433 | 434 | Internet-Draft NS Intro and PS January 2017 435 | 436 | 437 | 7. References 438 | 439 | 7.1. IETF References 440 | 441 | [I-D.dong-network-slicing-problem-statement] 442 | Dong, J. and S. Bryant, "Problem Statement of Network 443 | Slicing in IP/MPLS Networks", draft-dong-network-slicing- 444 | problem-statement-00 (work in progress), October 2016. 445 | 446 | [I-D.galis-anima-autonomic-slice-networking] 447 | Galis, A., Makhijani, K., and D. Yu, "Autonomic Slice 448 | Networking-Requirements and Reference Model", draft-galis- 449 | anima-autonomic-slice-networking-01 (work in progress), 450 | October 2016. 451 | [RFC7665] 452 | Halpern, J., Pignataro, C., 453 | "Service Function Chaining (SFC) Architecture", 454 | https://tools.ietf.org/html/rfc7665, October 2015. 455 | 456 | [I-D.leeking-actn-problem-statement 03] 457 | Ceccarelli, D., Lee, Y., 458 | "Framework for Abstraction and Control of Traffic Engineered 459 | Networks", draft-leeking-actn-problem-statement-03 460 | (work in progress), September 2014. 461 | 462 | [I-D.teas-actn-requirements-04] 463 | Lee, Y., Dhody, D., Belotti, S., Pithewan, K., Ceccarelli, D., 464 | "Requirements for Abstraction and Control of TE Networks", 465 | draft-ietf-teas-actn-requirements-04.txt 466 | January 2017. 467 | 468 | [IETF-Slicing1] 469 | "Presentations - Network Slicing meeting at IETF 97 of 470 | 15th November 2016", n.d., . 473 | 474 | [IETF-Slicing2] 475 | "Presentations - Network Slicing meeting at IETF 97 of 476 | 15th November 2016", n.d., . 479 | 480 | [IETF-Slicing3] 481 | "Presentations - Network Slicing meeting at IETF 97 of 482 | 15th November 2016", n.d., . 484 | 485 | [IETF-Slicing4] 486 | "Presentations - Network Slicing meeting at IETF 97 of 487 | 15th November 2016", n.d., . 491 | 492 | 493 | 494 | 495 | 496 | 497 | 498 | Galis, et al. Expires July 23, 2017 [Page 8] 499 | 500 | 501 | Internet-Draft NS Intro and PS January 2017 502 | 503 | 504 | [IETF-Slicing5] 505 | "Presentations - Network Slicing meeting at IETF 97 of 506 | 15th November 2016", n.d., . 508 | 509 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 | Requirement Levels", BCP 14, RFC 2119, 511 | DOI 10.17487/RFC2119, March 1997, 512 | . 513 | 514 | [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 515 | Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 516 | 2006, . 517 | 518 | [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 519 | RFC 1958, 520 | . 521 | 522 | [RFC3439] Bush, R., Meyer, D., "Some Internet Architectural Guidelines and 523 | Philosophy", RFC 3439, 524 | . 525 | 526 | [RFC3234] Carpenter, B., Brim S., "Middleboxes: Taxonomy and Issues", 527 | RFC3439, 528 | . 529 | 530 | [RFC7149] Boucadair, M., Jacquenet, C. , " Software-Defined Networking: A 531 | Perspective from within a Service Provider Environment", RFC 7149, 532 | March 2014 533 | . 534 | 535 | [SFG WG] 536 | "Service Function Chaining WG" 537 | . 538 | [CPP] 539 | Boucadair M., Jacquenet, C., Wang, N., "IP Connectivity 540 | Provisioning Profile (CPP)" 541 | 542 | 543 | [IETF-Mobility]Truong-Xuan Do, Young-Han Kim, "Architecture 544 | for delivering multicast mobility services using network 545 | slicing" 2016-10-31 546 | 547 | 548 | [IETF-Virtualization] Carlos Bernardos, Akbar Rahman, Juan Zuniga, Luis Contreras, 549 | Pedro Aranda, " Network Virtualization Research Challenges" 2016-10-31 550 | 551 | 552 | [IETF-Coding] M.A. Vazquez-Castro, Tan Do-Duy, Paresh Saxena, Magnus Vikstrom, 553 | "Network Coding Function Virtualization" 2016-11-14 554 | 555 | 556 | [IETF-Anchoring] Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, 557 | Alexandre Petrescu, Fred Templin "Distributed Mobility Anchoring" 558 | 2016-12-15 559 | 560 | 561 | 7.2. Informative References 562 | 563 | 564 | 565 | 566 | [ChinaCom-2009] 567 | "A. Galis et al - Management and Service-aware Networking 568 | Architectures (MANA) for Future Internet - Invited paper 569 | IEEE 2009 Fourth International Conference on 570 | Communications and Networking in China (ChinaCom09) 26-28 571 | August 2009, Xi'an, China", n.d., 572 | . 573 | 574 | [GENI-2009] 575 | "GENI Key Concepts - Global Environment for Network 576 | Innovations (GENI)", n.d., 577 | . 578 | 579 | [GUERZONI-2016] 580 | "Guerzoni, R., Vaishnavi, I., Perez-Caparros, D., Galis, A., 581 | et al Analysis of End-to-End Multi Domain Management and 582 | Orchestration Frameworks for Software Defined 583 | Infrastructures - an Architectural Survey", June 2016, 584 | . 585 | 586 | [IMT2020-2015] 587 | "Report on Gap Analysis", ITU-T FG IMT2020, December 588 | 2015, . 590 | 591 | [IMT2020-2016] 592 | "Draft Technical Report Application of network 593 | softwarization to IMT-2020 (O-041)", ITU-T FG IMT2020, 594 | December 2016, . 596 | 597 | 598 | 599 | 600 | 601 | Galis, et al. Expires July 23, 2017 [Page 9] 602 | 603 | 604 | Internet-Draft NS Intro and PS January 2017 605 | 606 | 607 | [IMT2020-2016bis] 608 | "Draft Terms and definitions for IMT-2020 in ITU-T 609 | (O-040)", ITU-T FG IMT2020, December 2016, 610 | . 612 | 613 | [KARL-2016] 614 | "Karl, H., Peuster, M, Galis, A., et al DevOps for Network 615 | Function Virtualization - An Architectural Approach", July 616 | 2016, 617 | . 618 | 619 | [MANO-2014] 620 | "Network Functions Virtualisation (NFV); Management and 621 | Orchestration v1.1.1.", ETSI European Telecommunications 622 | Standards Institute., December 2014, 623 | . 625 | 626 | [NGMN-2016] 627 | "Hedmar,P., Mschner, K., et al - Description of Network 628 | Slicing Concept", NGMN Alliance NGS-3GPP-2016, January 629 | 2016, . 631 | 632 | [NGS-3GPP-2016] 633 | "Study on Architecture for Next Generation System - latest 634 | version v1.0.2", September 2016, 635 | . 637 | 638 | [ONF-2016] 639 | "Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 640 | M., Lopes, D., Kaippallimalit, J., - Open Network 641 | Fundation document "Applying SDN Architecture to 5G 642 | Slicing", Open Network Fundation, April 2016, 643 | . 646 | 647 | Authors' Addresses 648 | 649 | Alex Galis 650 | University College London 651 | 652 | Email: a.galis@ucl.ac.uk 653 | 654 | 655 | 656 | 657 | Galis, et al. Expires July 23, 2017 [Page 10] 658 | 659 | 660 | Internet-Draft NS Intro and PS January 2017 661 | 662 | 663 | Jie Dong 664 | Huawei Technologies 665 | 666 | Email: jie.dong@huawei.com 667 | 668 | 669 | Kiran Makhijani 670 | Huawei Technologies 671 | 672 | Email: kiran.makhijani@huawei.com 673 | 674 | 675 | Stewart Bryant 676 | Huawei Technologies 677 | 678 | Email: stewart.bryant@gmail.com 679 | 680 | 681 | Mohamed Boucadair 682 | Orange 683 | 684 | Email: mohamed.boucadair@orange.com 685 | 686 | Pedro Martinez-Julia 687 | National Institute of Information and Communications Technology (NICT) 688 | 689 | Email: pedro@nict.go.jp 690 | 691 | 692 | 693 | 694 | 695 | 696 | 697 | 698 | 699 | 700 | 701 | 702 | 703 | 704 | 705 | 706 | 707 | 708 | 709 | 710 | 711 | 712 | 713 | 714 | 715 | 716 | 717 | 718 | 719 | 720 | Galis, et al. Expires July 23, 2017 [Page 11] 721 | 722 | -------------------------------------------------------------------------------- /NS_drafts/draft-qin-netslices-use-cases-01.md: -------------------------------------------------------------------------------- 1 | % Title = "Network Slicing Use Cases: Network Customization for different services" 2 | % abbrev = "Use cases for Network Slicing" 3 | % category = "info" 4 | % docName = "draft-qin-netslices-usecase-customization-01" 5 | % ipr= "trust200902" 6 | % area = "Internet" 7 | % workgroup = "none" 8 | % keyword = ["Network Slicing"] 9 | % 10 | % date = 2017-03-24T00:00:00Z 11 | % [pi] 12 | % toc = "yes" 13 | % 14 | % #Independent Submission 15 | % [[author]] 16 | % initials="J." 17 | % surname = "Qin" 18 | % fullname = "Jun Qin" 19 | % organization ="Huawei Technologies" 20 | % [author.address] 21 | % email = "qinjun4@huawei.com" 22 | % [author.address.postal] 23 | % street = "Huawei Campus, No. 156 Beiqing Rd." 24 | % city = "Beijing " 25 | % code = "100095" 26 | % 27 | % [[author]] 28 | % initials="K." 29 | % surname = "Makhijani" 30 | % fullname = "Kiran Makhijani" 31 | % organization ="Huawei Technologies" 32 | % [author.address] 33 | % email = "kiran.makhijani@huawei.com" 34 | % [author.address.postal] 35 | % street = "2890 Central Expressway" 36 | % city = "Santa Clara" 37 | % code = "CA 95050" 38 | % [[author]] 39 | % initials="J." 40 | % surname = "Dong" 41 | % fullname = "Jie Dong" 42 | % organization ="Huawei Technologies" 43 | % [author.address] 44 | % email = "jie.dong@huawei.com" 45 | % [author.address.postal] 46 | % street = "Huawei Campus, No. 156 Beiqing Rd." 47 | % city = "Beijing " 48 | % code = "100095" 49 | % [[author]] 50 | % initials="L." 51 | % surname = "Qiang" 52 | % fullname = "Li Qiang" 53 | % organization ="Huawei Technologies" 54 | % [author.address] 55 | % email = "qiangli3@huawei.com" 56 | % [author.address.postal] 57 | % street = "Huawei Campus, No. 156 Beiqing Rd." 58 | % city = "Beijing " 59 | % code = "100095" 60 | % [[author]] 61 | % initials="S." 62 | % surname = "Peng" 63 | % fullname = "Shuping Peng" 64 | % organization ="Huawei Technologies" 65 | % [author.address] 66 | % email = "pengshuping@huawei.com" 67 | % [author.address.postal] 68 | % street = "Huawei Campus, No. 156 Beiqing Rd." 69 | % city = "Beijing " 70 | % code = "100095" 71 | 72 | .# Abstract 73 | 74 | Network Slicing paradigm enables creation of partitioned network infrastructure to provide isolated network platforms for various service verticals. The motivation behind Network Slicing (NS) is to allow deployment of new services 75 | without causing or experiencing any disruption due to other already running or 76 | deployed services in the network. The purpose of this document is to focus on use cases that benefit from the usefulness of network slicing. 77 | 78 | {mainmatter} 79 | 80 | # Introduction 81 | 82 | Network Slicing (NS) is a widely discussed paradigm and is a mandatory 83 | requirement in 5G to meet the diverse service requirements in different 5G service scenarios. NS refers to the 84 | managed partitions of physical and/or virtual network resources, 85 | network physical/virtual and service functions [@!RFC7665] that can act 86 | as an independent instance of a connectivity network and/or as a 87 | network cloud [@!I-D.gdmb-netslices-intro-and-ps]. In 88 | 3rd Generation Partnership Project (3GPP) [@?TR23.799] defines "Network 89 | slicing enables the operator to create networks customized to provide 90 | optimized solutions for different market scenarios which demands 91 | diverse requirements, e.g. in the areas of functionality, performance 92 | and isolation". Draft [@!I-D.gdmb-netslices-intro-and-ps] defines 93 | network slicing in a broad context and suggests related problems and 94 | work areas. Other organizations like Next Generation 95 | Mobile Networks (NGMN) [@?Network-Slicing-Concept] and ITU-T FG 96 | IMT-2020 [@?FG-IMT2020-Gaps] also present their separate definitions of 97 | NS. 98 | 99 | To maximize resource utilization and minimize infrastructure cost, 100 | services will need to be deployed simultaneously, next to each other 101 | over a shared network as against the traditional monolithic model. 102 | Service operators can utilize or benefit from Network Slicing through 103 | multi-tenancy, enabling different customized infrastructures for 104 | different group of services across different network segments and 105 | operating them independently. Moreover, NS is also able to guarantee 106 | the isolation between different network slices. The operation of the 107 | data packets traversing one network slice must not adversely affect the 108 | service operation in other network slices sharing the same underlying 109 | packet network. 110 | 111 | This document describes use cases, where service operators can utilize or benefit from Network Slicing through multi-tenancy, enabling different customized infrastructures for different group of services across different network segments and operating them independently. Although 5G will drive NS based deployments, the scope of the document is not limited to 5G; it covers example scenarios specified from 5G vision as well as generalized scenarios that can be applied to existing infrastructures. 112 | 113 | ## Requirements Language 114 | 115 | The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL 116 | NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and 117 | "**OPTIONAL**" in this document are to be interpreted as described in RFC 2119. 118 | 119 | Additionally, the key words "**MIGHT**", "**COULD**", "**MAY WISH TO**", 120 | "**WOULD PROBABLY**", "**SHOULD CONSIDER**", and "**MUST (BUT WE KNOW YOU 121 | WON'T)**" in this document are to interpreted as described in RFC 6919. 122 |   123 | ## Terminology 124 | 125 | - V2X (Vehicle-to-everything): 126 | Is a communication of information from a vehicle to any other entity that may be a user end-device, network element or application end point. 127 | - ITS (Intelligent Transportation Systems): 128 | Considered an aspect of Internet of Things creates a transport network. The network provides services relating to transport and traffic management systems through flow of information between sensors, smart devices and humans. 129 | - Over-the-top (OTT): 130 | A service, e.g., content delivery using a CDN, operated by a different operator than the NSP to which the users of that service are attached. 131 | - Industry vertical: 132 | A collection of services or tools specific to an 133 | industry, trade or market sector. Also referred to as Service Verticals in this document. 134 | 135 | 136 | # Network Customization for diverse services 137 | 138 | ## Overview 139 | [Note: To discuss diverse set of service attributes] 140 | 141 | Often services specify a broader resource requirements to perform normally whereas the underlying infrastructure is generally best-effort. Traditionally, basic service guarantees are associated with resource attributes such as: 142 | 143 | * Latency 144 | * Bandwidth/Burst or other bit rates. 145 | * Security 146 | 147 | In addition, other attributes as mentioned below are embedded into the infrastructure to improve over all quality of experience 148 | 149 | * Redundancy 150 | * Reliability 151 | * Authentication 152 | 153 | More recently, other service attributes have become significant such as 154 | 155 | * Continuity during mobility 156 | * Purpose-built network functions. 157 | * Service placement 158 | 159 | It should be possible for the providers of any service to 160 | continuously evolve, adapt, and differentiate themselves through 161 | purpose-built infrastructures with minimal impact on network deployment and 162 | operations. The motivation behind 5G Network slicing paradigm is exactly that. 163 | By creating logically partitioned network infrastructures, isolated platforms 164 | for various industry verticals can be provided. NS is envisioned to enable new 165 | service deployments without having to build new network infrastructures or 166 | causing disruptions to other already deployed services in the network. In 167 | regards to NS, there are two primary characteristics, a) Strict demand for network resource, b) Network Customization. 168 | 169 | ## Strict Resource Demand Concept {#resource-demand} 170 | 171 | Several services are sensitive to response times and/or amount of bandwidth, e.g. realtime interactive multimedia, high bandwidth video feed or remote access to an enterprise network. Failure to meet these criteria leads to service degradation. 172 | 173 | Moreover, newer scenarios from different industries are evolving due to these factors - a) everything connected, b) technological advancements in sensors, IoT, robotics and multi-media, c) innovations in social network interactions (including both human-human or human-machine). These may impose even stricter and more specific set of resource and connectivity requirements on per service basis. 174 | The challenge lies in utilizing common network infrastructure and judiciously allocating available infrastructure resources. 175 | 176 | 177 | ## Network Customization Concept{#customization} 178 | Network slicing is enabled through customization. Customization gives control to the operator (of a slice) to create, provision, change and consume network resources to suit their service demands. It requires ability to decompose resources from an underlying network infrastructure and logically aggregate them to tailored a part of network into a slice. These customizations are not only in the context of the network characteristics but also include network functions. 179 | 180 | ## Scope of use cases 181 | 182 | Network slicing by itself is not a new concept nor its benefits are limited to 5G. While writing use cases following were considered - 183 | 184 | * A Network Slicing aware infrastructure allows operators to use part of the network resources to meet stringent resource requirement as in (#resource-demand) or exploit dynamic customizations as described in (#customization). Finally, there will be scenarios that require both customization and strict resource requirements. 185 | 186 | * The document doesn't specify whether a network slice consists of a single or multiple service(s). at the simplest level one service may correspond to a slice, however, it is possible that many services may become part of the same slice for the purpose of isolated data or context sharing. 187 | 188 | * Use cases below are discussed from 2 perspectives - 189 | 190 | a. Newer scenarios: that should absolutely meet strict resource requirements, as if they use a dedicated infrastructure. The example use cases are categorized further in (#Demanding-NS). 191 | b. Existing Scenarios: Several already deployed or existing examples that would further benefit when deployed through Network Slice paradigm are discussed in (#Using-NS). 192 | 193 | # NS Use Cases of Strict Resource Demands {#Demanding-NS} 194 | 195 | The International Telecommunication Union (ITU) has classified 5G mobile network services into three categories: Enhanced Mobile Broadband (eMBB), Ultra-reliable and Low-latency Communications (uRLLC), and Massive Machine Type Communications (mMTC). Following representative use cases are divided based on these criteria. 196 | 197 | ## eMBB Type of NS Use Cases 198 | The scenarios in this section are discussed in regards to growth in data rate capacity, connection density and interactive media. 199 | 200 | ### HD Video 201 | 202 | Person-to-person or person-to-group video communication with high resolution (4K/8K) and more advanced capabilities will have a much wider usage in 5G era. In a large stadium or live event (spots/concert) setting, following kind of services can be offered: 203 | 204 | * Watch HD playback video or instant replay. 205 | * Stream/share live HD videos with remote friends, or photos to social networks. 206 | 207 | The connection density and date rate requirements will be high. The aim is to provide video streaming and sharing services to everyone, regardless of the physical location, the device being used, and the network connection [@?NGMN-White-Paper]. 208 | 209 | ### Virtual Reality (VR)/Augmented Reality (AR){#ar-vr} 210 | 211 | Virtual Reality(VR)/Augmented Reality(AR) is another demanding use case of eMBB services. VR/AR video streaming will have far more stringent network resource requirements than on-demand video content. It may require it's own dedicated infrastructure with enhanced network protocols. The adoption of bandwidth-intensive VR/AR immersive services will have a direct impact on network capacity. At present 360 degree videos are mostly low resolution, requiring ~25 Mbps network bandwidth for streaming. 360 degree video is basis of AR/VR and as the display quality improves (retina resolution, 5K per eye), the bandwidth required will ramp up to several Gbps for a fully immersive experience. 212 | The infrastructure required to deliver immersive services will be different from traditional network. It may require several purpose-built hardware-assisted for video processing inline, dedicated immersive service capacity per user and perhaps an alternate transport designed specially for video services. 213 | 214 | ### Realizing eMBB type Slices 215 | A purpose-built Network Slice for video streaming shall ensure first and foremost, that there is always sufficient network capacity available for users that are not attending of the live-event (eMBB slice). That is, users not subscribed to eMBB slice dedicated for the event, will not experience service degradation because available bandwidth got used up by stadium attendees. 216 | 217 | Since quality of experience is important but not critical; this slice may scale out by borrowing resources on-demand from the common infrastructure resource-pool and may even return dynamically to save costs if the bandwidth demand is low. As such slices of these kind may be temporary and destroyed at the end of the event. 218 | 219 | ## uRLLC Type of NS Use Cases 220 | 221 | ### Industrial Operation and Inspection 222 | 223 | In industry area, usually remote operations need the support of the mobile transport networks. Operating machinery from a control center at a remote site could avoid on-site hazards relating to sites like waterworks, large process plants, mines, harbors, and chemical factory. Tele-operating heavy machinery and other equipments with high accuracy in dangerous or hard to access sites requires a high-quality communication link between the control-center and the machines. 224 | 225 | ### Remote Surgery 226 | Remote surgery which enables surgeons to perform critical specialized medical procedures remotely, allowing their vital expertise to be applied globally. Providing the correct control and feedback for the surgeon entails very strict requirements in terms of latency, reliability and security. 227 | 228 | ### Realizing uRLLC type Slices 229 | 230 | A Network slice dedicated for remote operations requires communication characteristics of low latency and low jitter. To manipulate equipment efficiently the response time of a control instruction must be as short as possible. A typical haptic control loop in a remote operation application requires latency to be below 10ms [@?Technology-Watch-Report]. 231 | 232 | 233 | 234 | ### Vehicle-to-everything (V2X) 235 | 236 | Vehicle-to-everything (V2X) refers to an intelligent transport system where all vehicles and infrastructure systems are interconnected with each other [@?White-paper-5GAA]. The V2X features fall into several categories relating to safety, navigation, infotainment, diagnostics and efficiency [@?ITS-I]. This makes for an interesting use case for network slices as each category is served through a different slice; a vehicle becomes part of 3 or 4 different logical network infrastructures at the same time. For Example: 237 | 238 | 1. A vehicle may become part of a customized slice that serves low latency and zero-packet loss slice and supports a Vehicular Ad Hoc Network (VANET) type protocols for vehicle to vehicle communication and autonomous driving. It may further have different access selection (short-range DSRC or commercial C-V2X) see [@?White-paper-5GAA] for details.This slice have characteristics of constant, low bandwidth, ultra-low latency. 239 | 2. A Vehicle may join an isolated slice that represents its car manufacturer's network for remote diagnostics, software/firmware upgrades to vehicle maybe performed. The key characteristics for this slice is to ensure security of sensors and other devices through VPN style closed network. 240 | 3. An infotainment slice of vehicle provides broadband for in vehicle entertainment, Internet access and enhanced navigation. 241 | 242 | ## mMTC Type NS Use Cases 243 | 244 | ### Smart Cities 245 | 246 | Smart city is an integration of public infrastructures together through Machine-to-Machine (M2M) communications and other Internet of Things (IoT) solutions. The common smart city services include: 247 | 248 | - automatic metering for gas, energy, water, etc. 249 | - environment monitoring for pollution, temperature, humidity, etc. 250 | - light management inside buildings or even the whole city, 251 | - traffic signal control, 252 | public safety alerting for natural disasters and emergencies. 253 | 254 | Building a smart city requires a variety of IOT networks to inter-operate together, These IOT networks are run by different departments with different access privileges for administration and access control. For emergency services in smart city, the communication network must ensure the reliable communication. 255 | 256 | 257 | ### Health Monitoring 258 | 259 | E-health refers to the application that remote monitor the physical conditions (e.g., heart rate, pulse, blood pressure etc.), and accordingly take necessary medical measures remotely. Often E-health service could be life-critical relate its communication network must be able to provide the reliable and fast but small-size of data exchange. In addition, the privacy and security of user’s data must be guaranteed. 260 | 261 | 262 | ### Realizing mMTC Type Slices 263 | 264 | mMTC involves potentially a large number of small and power-constrained devices, therefore, resource allocation at scale is of particular importance in mMTC type slices. Furthermore, different kind of IoT devices may exhibit quite different traffic patterns e.g., uninterrupted (heart rate monitors) & periodic delay tolerant (temperature sensors), delay sensitive (e.g., weather forecast & disaster alerting), mobility mode, security awareness etc. The mMTC type slices should be conscious of various requirements of scale, data pattern, reliability, security and energy efficient communications. 265 | 266 | # NS Use Cases of Other (Over-The-Top services) type{#Using-NS} 267 | 268 | Besides specific scenarios with special requirements, discussed in previous section, examples in this section benefit from sliced-network infrastructure. 269 | 270 | Over-The-Top(OTT) services are typical scenario of this kind. OTT services are those associated with content, like video (with normal definition), audio, IM messages, web-digital content, and other media transmitted via the Internet, this kind of communications are expected to be pervasive and part of everyday life. A high degree of applications such as VOIP, CDNs are deployed as OTT services with low expectations from the underlying network as communication medium and subsequently by building their own application infrastructure. The trend toward IP (or HTTP) based content delivery may be perceived as an indicative of network as dumb pipe. However, QoE is important to content delivery and requires coordination with the ISPs. With new advances in multimedia formats and social network channels service offerers must adapt to varying parameters of QoE. 271 | 272 | ## Realizing OTT Service Slices 273 | A network slice represented by partitioned network infrastructure allocated for content delivery can help create new opportunities for both network operators and content providers. [@!RFC6770] provides many use cases relating to ISP Handling of third-party content. 274 | Following examples may be considered: 275 | - Content Service Providers (CSPs) could lease a CDN slice and operate it as a well coordinated CDN infrastructure of content awareness, optimally placed servers & proprietary optimization logic functions (different for live video (real-time) and on-demand (caching)). 276 | - VOIP is a peer to peer service and requires CBR across multiple domains. If a VOIP-slice specification is from a well-known template that is universally understood then a low cost, reliable end-to-end VOIP service can be offered without intense provisioning of the transport. 277 | 278 | # NS Use cases with Mixed Requirements 279 | Along another dimension, many services will have combination of hard resource constraints that were discussed in (#Demanding-NS) such as both eMBB and uRLL. 280 | Some examples are as follows 281 | - As described in (#ar-vr), AV/VR has high bandwidth requirement but 'interactive' VR/AR applications are extremely sensitive to delay and require very low end-to-end latency (~20ms). 282 | - While operating machinery remotely, the primary communication characteristics are low latency and low jitter but in case of video assisted maintenance, the bandwidth also becomes important. In fact, most of the applications have mixed requirements from the network infrastructure. 283 | 284 | # Generic Network Slicing Use Case Analysis 285 | 286 | - Network Operator View: It is a daunting task to manage ever increasing number of services with their customized resource requirements. A logical division of networks shall allow simpler orchestration, management and operation both for service operator and network operators. 287 | - Opportunities in Industry verticals: With an independent control of services and associated network resources, Industry verticals can test and deploy services quicker. 288 | - 5G context: While the scope of document does not limit to 5G, it is important to take into consideration that 5G blurs the boundary between fixed and mobile networks. some related factors are (1) end-device access will be mainly radio or wireless but very well be fixed (2) end-device is simultaneously associated with those many access networks (3) transport could be IP or non-IP based. 5G will also be early adopter of Network Slicing in its architecture, therefore, many scenarios from 5G will be prioritized. 289 | - Heterogeneous resources: Different kind of resources maybe required in difference slices. Each network slice appears to its users as an independent, dedicated private network which is impervious to anything including the heterogeneous resources that is happening on any of the other network slices, a high degree of isolation on data plane is needed. 290 | - Transport Context: the transport network should give a customized topology built for a different network slices, and provide the network resources and performance characteristics like bandwidth, latency, jitter, security, availability, and etc that required by the corresponding slices. 291 | 292 | # Conclusion 293 | 294 | Many emerging services, together with the existing and evolving services will be carried out in the context of 5G network slicing. The goal of 5G is to support various service scenarios which have very diverse and strict demands from the network infrastructure. 295 | 296 | These scenarios require networks to be more flexible and scalable to support customized service requirements and diverse performance requirements with a single network infrastructure. Specifically, the current transport network architecture is not as flexible or scalable to provide the required network customizations and the resource assurances for different type of use cases at simultaneously. 297 | 298 | Network slicing is a way to to support service or industry verticals over the same physical network such that each network slice appears to its tenant as an independent, dedicated private network and is impervious to anything that is happening on any of the other network slices. For services which do not have special requirements from the network; slicing provides an effective way for those to coexist along with the services having strict requirements. 299 | 300 | 301 | # Security Considerations 302 | 303 | The security considerations apply to each slice. In addition general security 304 | considerations of underlying infrastructure whether isolated communication with 305 | in a slice apply for links using wireless technologies. 306 | 307 | # IANA Considerations 308 | 309 | There are no IANA actions requested at this time. 310 | 311 | # Acknowledgements 312 | Thanks to Stewart Bryant for providing details for several use cases. 313 | 314 | 315 | 316 | Intelligent Transportation Systems and the IETF 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | BT Ultra HD YouView box review 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | FG IMT-2020: Report on Standards Gap Analysis 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | Description of Network Slicing Concept 341 | 342 | Next Generation Mobile Network Alliance 343 | 344 | 345 | 346 | 347 | 348 | 350 | 351 | 5G White Paper 352 | 353 | Next Generation Mobile Network Alliance 354 | 355 | 356 | 357 | 358 | 359 | 361 | 362 | Technology Watch Report, The Tactile Internet 363 | 364 | ITU-T 365 | 366 | 367 | 368 | 369 | 370 | 371 | 372 | Study on Architecture for Next Generation System 373 | 374 | International Telecommunications Union 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | The Case for Cellular V2X for Safety and Cooperative Driving 384 | 385 | 5G Automotive Association 386 | 387 | 388 | 389 | 390 | 391 | {backmatter} 392 | -------------------------------------------------------------------------------- /NS_drafts/draft-qin-netslices-use-cases-01.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | none J. Qin 6 | Internet-Draft K. Makhijani 7 | Intended status: Informational J. Dong 8 | Expires: September 25, 2017 L. Qiang 9 | S. Peng 10 | Huawei Technologies 11 | March 24, 2017 12 | 13 | 14 | Network Slicing Use Cases: Network Customization for different services 15 | draft-qin-netslices-usecase-customization-01 16 | 17 | Abstract 18 | 19 | Network Slicing paradigm enables creation of partitioned network 20 | infrastructure to provide isolated network platforms for various 21 | service verticals. The motivation behind Network Slicing (NS) is to 22 | allow deployment of new services without causing or experiencing any 23 | disruption due to other already running or deployed services in the 24 | network. The purpose of this document is to focus on use cases that 25 | benefit from the usefulness of network slicing. 26 | 27 | Status of This Memo 28 | 29 | This Internet-Draft is submitted in full conformance with the 30 | provisions of BCP 78 and BCP 79. 31 | 32 | Internet-Drafts are working documents of the Internet Engineering 33 | Task Force (IETF). Note that other groups may also distribute 34 | working documents as Internet-Drafts. The list of current Internet- 35 | Drafts is at http://datatracker.ietf.org/drafts/current/. 36 | 37 | Internet-Drafts are draft documents valid for a maximum of six months 38 | and may be updated, replaced, or obsoleted by other documents at any 39 | time. It is inappropriate to use Internet-Drafts as reference 40 | material or to cite them other than as "work in progress." 41 | 42 | This Internet-Draft will expire on September 25, 2017. 43 | 44 | Copyright Notice 45 | 46 | Copyright (c) 2017 IETF Trust and the persons identified as the 47 | document authors. All rights reserved. 48 | 49 | This document is subject to BCP 78 and the IETF Trust's Legal 50 | Provisions Relating to IETF Documents 51 | (http://trustee.ietf.org/license-info) in effect on the date of 52 | publication of this document. Please review these documents 53 | 54 | 55 | 56 | Qin, et al. Expires September 25, 2017 [Page 1] 57 | 58 | Internet-Draft Use cases for Network Slicing March 2017 59 | 60 | 61 | carefully, as they describe your rights and restrictions with respect 62 | to this document. Code Components extracted from this document must 63 | include Simplified BSD License text as described in Section 4.e of 64 | the Trust Legal Provisions and are provided without warranty as 65 | described in the Simplified BSD License. 66 | 67 | Table of Contents 68 | 69 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 71 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 | 2. Network Customization for diverse services . . . . . . . . . 4 73 | 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 74 | 2.2. Strict Resource Demand Concept . . . . . . . . . . . . . 5 75 | 2.3. Network Customization Concept . . . . . . . . . . . . . . 5 76 | 2.4. Scope of use cases . . . . . . . . . . . . . . . . . . . 6 77 | 3. NS Use Cases of Strict Resource Demands . . . . . . . . . . . 6 78 | 3.1. eMBB Type of NS Use Cases . . . . . . . . . . . . . . . . 6 79 | 3.1.1. HD Video . . . . . . . . . . . . . . . . . . . . . . 6 80 | 3.1.2. Virtual Reality (VR)/Augmented Reality (AR) . . . . . 7 81 | 3.1.3. Realizing eMBB type Slices . . . . . . . . . . . . . 7 82 | 3.2. uRLLC Type of NS Use Cases . . . . . . . . . . . . . . . 7 83 | 3.2.1. Industrial Operation and Inspection . . . . . . . . . 7 84 | 3.2.2. Remote Surgery . . . . . . . . . . . . . . . . . . . 8 85 | 3.2.3. Realizing uRLLC type Slices . . . . . . . . . . . . . 8 86 | 3.2.4. Vehicle-to-everything (V2X) . . . . . . . . . . . . . 8 87 | 3.3. mMTC Type NS Use Cases . . . . . . . . . . . . . . . . . 9 88 | 3.3.1. Smart Cities . . . . . . . . . . . . . . . . . . . . 9 89 | 3.3.2. Health Monitoring . . . . . . . . . . . . . . . . . . 9 90 | 3.3.3. Realizing mMTC Type Slices . . . . . . . . . . . . . 9 91 | 4. NS Use Cases of Other (Over-The-Top services) type . . . . . 10 92 | 4.1. Realizing OTT Service Slices . . . . . . . . . . . . . . 10 93 | 5. NS Use cases with Mixed Requirements . . . . . . . . . . . . 10 94 | 6. Generic Network Slicing Use Case Analysis . . . . . . . . . . 11 95 | 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 98 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 99 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 100 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 101 | 11.2. Informative References . . . . . . . . . . . . . . . . . 13 102 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 103 | 104 | 1. Introduction 105 | 106 | Network Slicing (NS) is a widely discussed paradigm and is a 107 | mandatory requirement in 5G to meet the diverse service requirements 108 | in different 5G service scenarios. NS refers to the managed 109 | 110 | 111 | 112 | Qin, et al. Expires September 25, 2017 [Page 2] 113 | 114 | Internet-Draft Use cases for Network Slicing March 2017 115 | 116 | 117 | partitions of physical and/or virtual network resources, network 118 | physical/virtual and service functions [RFC7665] that can act as an 119 | independent instance of a connectivity network and/or as a network 120 | cloud [I-D.gdmb-netslices-intro-and-ps]. In 3rd Generation 121 | Partnership Project (3GPP) [TR23.799] defines "Network slicing 122 | enables the operator to create networks customized to provide 123 | optimized solutions for different market scenarios which demands 124 | diverse requirements, e.g. in the areas of functionality, performance 125 | and isolation". Draft [I-D.gdmb-netslices-intro-and-ps] defines 126 | network slicing in a broad context and suggests related problems and 127 | work areas. Other organizations like Next Generation Mobile Networks 128 | (NGMN) [Network-Slicing-Concept] and ITU-T FG IMT-2020 129 | [FG-IMT2020-Gaps] also present their separate definitions of NS. 130 | 131 | To maximize resource utilization and minimize infrastructure cost, 132 | services will need to be deployed simultaneously, next to each other 133 | over a shared network as against the traditional monolithic model. 134 | Service operators can utilize or benefit from Network Slicing through 135 | multi-tenancy, enabling different customized infrastructures for 136 | different group of services across different network segments and 137 | operating them independently. Moreover, NS is also able to guarantee 138 | the isolation between different network slices. The operation of the 139 | data packets traversing one network slice must not adversely affect 140 | the service operation in other network slices sharing the same 141 | underlying packet network. 142 | 143 | This document describes use cases, where service operators can 144 | utilize or benefit from Network Slicing through multi-tenancy, 145 | enabling different customized infrastructures for different group of 146 | services across different network segments and operating them 147 | independently. Although 5G will drive NS based deployments, the 148 | scope of the document is not limited to 5G; it covers example 149 | scenarios specified from 5G vision as well as generalized scenarios 150 | that can be applied to existing infrastructures. 151 | 152 | 1.1. Requirements Language 153 | 154 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*", 155 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 | document are to be interpreted as described in RFC 2119. 157 | 158 | Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 159 | "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 160 | WON'T)*" in this document are to interpreted as described in RFC 161 | 6919. 162 | 163 | 164 | 165 | 166 | 167 | 168 | Qin, et al. Expires September 25, 2017 [Page 3] 169 | 170 | Internet-Draft Use cases for Network Slicing March 2017 171 | 172 | 173 | 1.2. Terminology 174 | 175 | o V2X (Vehicle-to-everything): Is a communication of information 176 | from a vehicle to any other entity that may be a user end-device, 177 | network element or application end point. 178 | 179 | o ITS (Intelligent Transportation Systems): Considered an aspect of 180 | Internet of Things creates a transport network. The network 181 | provides services relating to transport and traffic management 182 | systems through flow of information between sensors, smart devices 183 | and humans. 184 | 185 | o Over-the-top (OTT): A service, e.g., content delivery using a CDN, 186 | operated by a different operator than the NSP to which the users 187 | of that service are attached. 188 | 189 | o Industry vertical: A collection of services or tools specific to 190 | an industry, trade or market sector. Also referred to as Service 191 | Verticals in this document. 192 | 193 | 2. Network Customization for diverse services 194 | 195 | 2.1. Overview 196 | 197 | [Note: To discuss diverse set of service attributes] 198 | 199 | Often services specify a broader resource requirements to perform 200 | normally whereas the underlying infrastructure is generally best- 201 | effort. Traditionally, basic service guarantees are associated with 202 | resource attributes such as: 203 | 204 | o Latency 205 | 206 | o Bandwidth/Burst or other bit rates. 207 | 208 | o Security 209 | 210 | In addition, other attributes as mentioned below are embedded into 211 | the infrastructure to improve over all quality of experience 212 | 213 | o Redundancy 214 | 215 | o Reliability 216 | 217 | o Authentication 218 | 219 | More recently, other service attributes have become significant such 220 | as 221 | 222 | 223 | 224 | Qin, et al. Expires September 25, 2017 [Page 4] 225 | 226 | Internet-Draft Use cases for Network Slicing March 2017 227 | 228 | 229 | o Continuity during mobility 230 | 231 | o Purpose-built network functions. 232 | 233 | o Service placement 234 | 235 | It should be possible for the providers of any service to 236 | continuously evolve, adapt, and differentiate themselves through 237 | purpose-built infrastructures with minimal impact on network 238 | deployment and operations. The motivation behind 5G Network slicing 239 | paradigm is exactly that. By creating logically partitioned network 240 | infrastructures, isolated platforms for various industry verticals 241 | can be provided. NS is envisioned to enable new service deployments 242 | without having to build new network infrastructures or causing 243 | disruptions to other already deployed services in the network. In 244 | regards to NS, there are two primary characteristics, a) Strict 245 | demand for network resource, b) Network Customization. 246 | 247 | 2.2. Strict Resource Demand Concept 248 | 249 | Several services are sensitive to response times and/or amount of 250 | bandwidth, e.g. realtime interactive multimedia, high bandwidth video 251 | feed or remote access to an enterprise network. Failure to meet 252 | these criteria leads to service degradation. 253 | 254 | Moreover, newer scenarios from different industries are evolving due 255 | to these factors - a) everything connected, b) technological 256 | advancements in sensors, IoT, robotics and multi-media, c) 257 | innovations in social network interactions (including both human- 258 | human or human-machine). These may impose even stricter and more 259 | specific set of resource and connectivity requirements on per service 260 | basis. The challenge lies in utilizing common network infrastructure 261 | and judiciously allocating available infrastructure resources. 262 | 263 | 2.3. Network Customization Concept 264 | 265 | Network slicing is enabled through customization. Customization 266 | gives control to the operator (of a slice) to create, provision, 267 | change and consume network resources to suit their service demands. 268 | It requires ability to decompose resources from an underlying network 269 | infrastructure and logically aggregate them to tailored a part of 270 | network into a slice. These customizations are not only in the 271 | context of the network characteristics but also include network 272 | functions. 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | Qin, et al. Expires September 25, 2017 [Page 5] 281 | 282 | Internet-Draft Use cases for Network Slicing March 2017 283 | 284 | 285 | 2.4. Scope of use cases 286 | 287 | Network slicing by itself is not a new concept nor its benefits are 288 | limited to 5G. While writing use cases following were considered - 289 | 290 | o A Network Slicing aware infrastructure allows operators to use 291 | part of the network resources to meet stringent resource 292 | requirement as in Section 2.2 or exploit dynamic customizations as 293 | described in Section 2.3. Finally, there will be scenarios that 294 | require both customization and strict resource requirements. 295 | 296 | o The document doesn't specify whether a network slice consists of a 297 | single or multiple service(s). at the simplest level one service 298 | may correspond to a slice, however, it is possible that many 299 | services may become part of the same slice for the purpose of 300 | isolated data or context sharing. 301 | 302 | o Use cases below are discussed from 2 perspectives - 303 | 304 | a Newer scenarios: that should absolutely meet strict resource 305 | requirements, as if they use a dedicated infrastructure. The 306 | example use cases are categorized further in Section 3. 307 | 308 | b Existing Scenarios: Several already deployed or existing 309 | examples that would further benefit when deployed through 310 | Network Slice paradigm are discussed in Section 4. 311 | 312 | 3. NS Use Cases of Strict Resource Demands 313 | 314 | The International Telecommunication Union (ITU) has classified 5G 315 | mobile network services into three categories: Enhanced Mobile 316 | Broadband (eMBB), Ultra-reliable and Low-latency Communications 317 | (uRLLC), and Massive Machine Type Communications (mMTC). Following 318 | representative use cases are divided based on these criteria. 319 | 320 | 3.1. eMBB Type of NS Use Cases 321 | 322 | The scenarios in this section are discussed in regards to growth in 323 | data rate capacity, connection density and interactive media. 324 | 325 | 3.1.1. HD Video 326 | 327 | Person-to-person or person-to-group video communication with high 328 | resolution (4K/8K) and more advanced capabilities will have a much 329 | wider usage in 5G era. In a large stadium or live event (spots/ 330 | concert) setting, following kind of services can be offered: 331 | 332 | o Watch HD playback video or instant replay. 333 | 334 | 335 | 336 | Qin, et al. Expires September 25, 2017 [Page 6] 337 | 338 | Internet-Draft Use cases for Network Slicing March 2017 339 | 340 | 341 | o Stream/share live HD videos with remote friends, or photos to 342 | social networks. 343 | 344 | The connection density and date rate requirements will be high. The 345 | aim is to provide video streaming and sharing services to everyone, 346 | regardless of the physical location, the device being used, and the 347 | network connection [NGMN-White-Paper]. 348 | 349 | 3.1.2. Virtual Reality (VR)/Augmented Reality (AR) 350 | 351 | Virtual Reality(VR)/Augmented Reality(AR) is another demanding use 352 | case of eMBB services. VR/AR video streaming will have far more 353 | stringent network resource requirements than on-demand video content. 354 | It may require it's own dedicated infrastructure with enhanced 355 | network protocols. The adoption of bandwidth-intensive VR/AR 356 | immersive services will have a direct impact on network capacity. At 357 | present 360 degree videos are mostly low resolution, requiring ~25 358 | Mbps network bandwidth for streaming. 360 degree video is basis of 359 | AR/VR and as the display quality improves (retina resolution, 5K per 360 | eye), the bandwidth required will ramp up to several Gbps for a fully 361 | immersive experience. The infrastructure required to deliver 362 | immersive services will be different from traditional network. It 363 | may require several purpose-built hardware-assisted for video 364 | processing inline, dedicated immersive service capacity per user and 365 | perhaps an alternate transport designed specially for video services. 366 | 367 | 3.1.3. Realizing eMBB type Slices 368 | 369 | A purpose-built Network Slice for video streaming shall ensure first 370 | and foremost, that there is always sufficient network capacity 371 | available for users that are not attending of the live-event (eMBB 372 | slice). That is, users not subscribed to eMBB slice dedicated for 373 | the event, will not experience service degradation because available 374 | bandwidth got used up by stadium attendees. 375 | 376 | Since quality of experience is important but not critical; this slice 377 | may scale out by borrowing resources on-demand from the common 378 | infrastructure resource-pool and may even return dynamically to save 379 | costs if the bandwidth demand is low. As such slices of these kind 380 | may be temporary and destroyed at the end of the event. 381 | 382 | 3.2. uRLLC Type of NS Use Cases 383 | 384 | 3.2.1. Industrial Operation and Inspection 385 | 386 | In industry area, usually remote operations need the support of the 387 | mobile transport networks. Operating machinery from a control center 388 | at a remote site could avoid on-site hazards relating to sites like 389 | 390 | 391 | 392 | Qin, et al. Expires September 25, 2017 [Page 7] 393 | 394 | Internet-Draft Use cases for Network Slicing March 2017 395 | 396 | 397 | waterworks, large process plants, mines, harbors, and chemical 398 | factory. Tele-operating heavy machinery and other equipments with 399 | high accuracy in dangerous or hard to access sites requires a high- 400 | quality communication link between the control-center and the 401 | machines. 402 | 403 | 3.2.2. Remote Surgery 404 | 405 | Remote surgery which enables surgeons to perform critical specialized 406 | medical procedures remotely, allowing their vital expertise to be 407 | applied globally. Providing the correct control and feedback for the 408 | surgeon entails very strict requirements in terms of latency, 409 | reliability and security. 410 | 411 | 3.2.3. Realizing uRLLC type Slices 412 | 413 | A Network slice dedicated for remote operations requires 414 | communication characteristics of low latency and low jitter. To 415 | manipulate equipment efficiently the response time of a control 416 | instruction must be as short as possible. A typical haptic control 417 | loop in a remote operation application requires latency to be below 418 | 10ms [Technology-Watch-Report]. 419 | 420 | 3.2.4. Vehicle-to-everything (V2X) 421 | 422 | Vehicle-to-everything (V2X) refers to an intelligent transport system 423 | where all vehicles and infrastructure systems are interconnected with 424 | each other [White-paper-5GAA]. The V2X features fall into several 425 | categories relating to safety, navigation, infotainment, diagnostics 426 | and efficiency [ITS-I]. This makes for an interesting use case for 427 | network slices as each category is served through a different slice; 428 | a vehicle becomes part of 3 or 4 different logical network 429 | infrastructures at the same time. For Example: 430 | 431 | 1. A vehicle may become part of a customized slice that serves low 432 | latency and zero-packet loss slice and supports a Vehicular Ad 433 | Hoc Network (VANET) type protocols for vehicle to vehicle 434 | communication and autonomous driving. It may further have 435 | different access selection (short-range DSRC or commercial C-V2X) 436 | see [White-paper-5GAA] for details.This slice have 437 | characteristics of constant, low bandwidth, ultra-low latency. 438 | 439 | 2. A Vehicle may join an isolated slice that represents its car 440 | manufacturer's network for remote diagnostics, software/firmware 441 | upgrades to vehicle maybe performed. The key characteristics for 442 | this slice is to ensure security of sensors and other devices 443 | through VPN style closed network. 444 | 445 | 446 | 447 | 448 | Qin, et al. Expires September 25, 2017 [Page 8] 449 | 450 | Internet-Draft Use cases for Network Slicing March 2017 451 | 452 | 453 | 3. An infotainment slice of vehicle provides broadband for in 454 | vehicle entertainment, Internet access and enhanced navigation. 455 | 456 | 3.3. mMTC Type NS Use Cases 457 | 458 | 3.3.1. Smart Cities 459 | 460 | Smart city is an integration of public infrastructures together 461 | through Machine-to-Machine (M2M) communications and other Internet of 462 | Things (IoT) solutions. The common smart city services include: 463 | 464 | o automatic metering for gas, energy, water, etc. 465 | 466 | o environment monitoring for pollution, temperature, humidity, etc. 467 | 468 | o light management inside buildings or even the whole city, 469 | 470 | o traffic signal control, public safety alerting for natural 471 | disasters and emergencies. 472 | 473 | Building a smart city requires a variety of IOT networks to inter- 474 | operate together, These IOT networks are run by different departments 475 | with different access privileges for administration and access 476 | control. For emergency services in smart city, the communication 477 | network must ensure the reliable communication. 478 | 479 | 3.3.2. Health Monitoring 480 | 481 | E-health refers to the application that remote monitor the physical 482 | conditions (e.g., heart rate, pulse, blood pressure etc.), and 483 | accordingly take necessary medical measures remotely. Often E-health 484 | service could be life-critical relate its communication network must 485 | be able to provide the reliable and fast but small-size of data 486 | exchange. In addition, the privacy and security of user's data must 487 | be guaranteed. 488 | 489 | 3.3.3. Realizing mMTC Type Slices 490 | 491 | mMTC involves potentially a large number of small and power- 492 | constrained devices, therefore, resource allocation at scale is of 493 | particular importance in mMTC type slices. Furthermore, different 494 | kind of IoT devices may exhibit quite different traffic patterns 495 | e.g., uninterrupted (heart rate monitors) & periodic delay tolerant 496 | (temperature sensors), delay sensitive (e.g., weather forecast & 497 | disaster alerting), mobility mode, security awareness etc. The mMTC 498 | type slices should be conscious of various requirements of scale, 499 | data pattern, reliability, security and energy efficient 500 | communications. 501 | 502 | 503 | 504 | Qin, et al. Expires September 25, 2017 [Page 9] 505 | 506 | Internet-Draft Use cases for Network Slicing March 2017 507 | 508 | 509 | 4. NS Use Cases of Other (Over-The-Top services) type 510 | 511 | Besides specific scenarios with special requirements, discussed in 512 | previous section, examples in this section benefit from sliced- 513 | network infrastructure. 514 | 515 | Over-The-Top(OTT) services are typical scenario of this kind. OTT 516 | services are those associated with content, like video (with normal 517 | definition), audio, IM messages, web-digital content, and other media 518 | transmitted via the Internet, this kind of communications are 519 | expected to be pervasive and part of everyday life. A high degree of 520 | applications such as VOIP, CDNs are deployed as OTT services with low 521 | expectations from the underlying network as communication medium and 522 | subsequently by building their own application infrastructure. The 523 | trend toward IP (or HTTP) based content delivery may be perceived as 524 | an indicative of network as dumb pipe. However, QoE is important to 525 | content delivery and requires coordination with the ISPs. With new 526 | advances in multimedia formats and social network channels service 527 | offerers must adapt to varying parameters of QoE. 528 | 529 | 4.1. Realizing OTT Service Slices 530 | 531 | A network slice represented by partitioned network infrastructure 532 | allocated for content delivery can help create new opportunities for 533 | both network operators and content providers. [RFC6770] provides 534 | many use cases relating to ISP Handling of third-party content. 535 | Following examples may be considered: - Content Service Providers 536 | (CSPs) could lease a CDN slice and operate it as a well coordinated 537 | CDN infrastructure of content awareness, optimally placed servers & 538 | proprietary optimization logic functions (different for live video 539 | (real-time) and on-demand (caching)). - VOIP is a peer to peer 540 | service and requires CBR across multiple domains. If a VOIP-slice 541 | specification is from a well-known template that is universally 542 | understood then a low cost, reliable end-to-end VOIP service can be 543 | offered without intense provisioning of the transport. 544 | 545 | 5. NS Use cases with Mixed Requirements 546 | 547 | Along another dimension, many services will have combination of hard 548 | resource constraints that were discussed in Section 3 such as both 549 | eMBB and uRLL. Some examples are as follows - As described in 550 | Section 3.1.2, AV/VR has high bandwidth requirement but 'interactive' 551 | VR/AR applications are extremely sensitive to delay and require very 552 | low end-to-end latency (~20ms). - While operating machinery 553 | remotely, the primary communication characteristics are low latency 554 | and low jitter but in case of video assisted maintenance, the 555 | bandwidth also becomes important. In fact, most of the applications 556 | have mixed requirements from the network infrastructure. 557 | 558 | 559 | 560 | Qin, et al. Expires September 25, 2017 [Page 10] 561 | 562 | Internet-Draft Use cases for Network Slicing March 2017 563 | 564 | 565 | 6. Generic Network Slicing Use Case Analysis 566 | 567 | o Network Operator View: It is a daunting task to manage ever 568 | increasing number of services with their customized resource 569 | requirements. A logical division of networks shall allow simpler 570 | orchestration, management and operation both for service operator 571 | and network operators. 572 | 573 | o Opportunities in Industry verticals: With an independent control 574 | of services and associated network resources, Industry verticals 575 | can test and deploy services quicker. 576 | 577 | o 5G context: While the scope of document does not limit to 5G, it 578 | is important to take into consideration that 5G blurs the boundary 579 | between fixed and mobile networks. some related factors are (1) 580 | end-device access will be mainly radio or wireless but very well 581 | be fixed (2) end-device is simultaneously associated with those 582 | many access networks (3) transport could be IP or non-IP based. 5G 583 | will also be early adopter of Network Slicing in its architecture, 584 | therefore, many scenarios from 5G will be prioritized. 585 | 586 | o Heterogeneous resources: Different kind of resources maybe 587 | required in difference slices. Each network slice appears to its 588 | users as an independent, dedicated private network which is 589 | impervious to anything including the heterogeneous resources that 590 | is happening on any of the other network slices, a high degree of 591 | isolation on data plane is needed. 592 | 593 | o Transport Context: the transport network should give a customized 594 | topology built for a different network slices, and provide the 595 | network resources and performance characteristics like bandwidth, 596 | latency, jitter, security, availability, and etc that required by 597 | the corresponding slices. 598 | 599 | 7. Conclusion 600 | 601 | Many emerging services, together with the existing and evolving 602 | services will be carried out in the context of 5G network slicing. 603 | The goal of 5G is to support various service scenarios which have 604 | very diverse and strict demands from the network infrastructure. 605 | 606 | These scenarios require networks to be more flexible and scalable to 607 | support customized service requirements and diverse performance 608 | requirements with a single network infrastructure. Specifically, the 609 | current transport network architecture is not as flexible or scalable 610 | to provide the required network customizations and the resource 611 | assurances for different type of use cases at simultaneously. 612 | 613 | 614 | 615 | 616 | Qin, et al. Expires September 25, 2017 [Page 11] 617 | 618 | Internet-Draft Use cases for Network Slicing March 2017 619 | 620 | 621 | Network slicing is a way to to support service or industry verticals 622 | over the same physical network such that each network slice appears 623 | to its tenant as an independent, dedicated private network and is 624 | impervious to anything that is happening on any of the other network 625 | slices. For services which do not have special requirements from the 626 | network; slicing provides an effective way for those to coexist along 627 | with the services having strict requirements. 628 | 629 | 8. Security Considerations 630 | 631 | The security considerations apply to each slice. In addition general 632 | security considerations of underlying infrastructure whether isolated 633 | communication with in a slice apply for links using wireless 634 | technologies. 635 | 636 | 9. IANA Considerations 637 | 638 | There are no IANA actions requested at this time. 639 | 640 | 10. Acknowledgements 641 | 642 | Thanks to Stewart Bryant for providing details for several use cases. 643 | 644 | 11. References 645 | 646 | 11.1. Normative References 647 | 648 | [I-D.gdmb-netslices-intro-and-ps] 649 | Galis, A., Dong, J., kiran.makhijani@huawei.com, k., 650 | Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network 651 | Slicing - Introductory Document and Revised Problem 652 | Statement", draft-gdmb-netslices-intro-and-ps-02 (work in 653 | progress), February 2017. 654 | 655 | [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 656 | P., Ma, K., and G. Watson, "Use Cases for Content Delivery 657 | Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 658 | November 2012, . 659 | 660 | [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 661 | Chaining (SFC) Architecture", RFC 7665, 662 | DOI 10.17487/RFC7665, October 2015, 663 | . 664 | 665 | 666 | 667 | 668 | 669 | 670 | 671 | 672 | Qin, et al. Expires September 25, 2017 [Page 12] 673 | 674 | Internet-Draft Use cases for Network Slicing March 2017 675 | 676 | 677 | 11.2. Informative References 678 | 679 | [FG-IMT2020-Gaps] 680 | "FG IMT-2020: Report on Standards Gap Analysis", 681 | . 682 | 683 | [ITS-I] "Intelligent Transportation Systems and the IETF", 684 | . 686 | 687 | [Network-Slicing-Concept] 688 | Next Generation Mobile Network Alliance, "Description of 689 | Network Slicing Concept", January 2016, 690 | . 692 | 693 | [NGMN-White-Paper] 694 | Next Generation Mobile Network Alliance, "5G White Paper", 695 | March 2015, . 697 | 698 | [Technology-Watch-Report] 699 | ITU-T, "Technology Watch Report, The Tactile Internet", 700 | August 2014, . 701 | 702 | [TR23.799] 703 | International Telecommunications Union, "Study on 704 | Architecture for Next Generation System", SA2 Study 3GPP- 705 | TR23.799, December 2017, 706 | . 707 | 708 | [White-paper-5GAA] 709 | 5G Automotive Association, "The Case for Cellular V2X for 710 | Safety and Cooperative Driving", November 2016, 711 | . 713 | 714 | Authors' Addresses 715 | 716 | Jun Qin 717 | Huawei Technologies 718 | Huawei Campus, No. 156 Beiqing Rd. 719 | Beijing 100095 720 | 721 | Email: qinjun4@huawei.com 722 | 723 | 724 | 725 | 726 | 727 | 728 | Qin, et al. Expires September 25, 2017 [Page 13] 729 | 730 | Internet-Draft Use cases for Network Slicing March 2017 731 | 732 | 733 | Kiran Makhijani 734 | Huawei Technologies 735 | 2890 Central Expressway 736 | Santa Clara CA 95050 737 | 738 | Email: kiran.makhijani@huawei.com 739 | 740 | 741 | Jie Dong 742 | Huawei Technologies 743 | Huawei Campus, No. 156 Beiqing Rd. 744 | Beijing 100095 745 | 746 | Email: jie.dong@huawei.com 747 | 748 | 749 | Li Qiang 750 | Huawei Technologies 751 | Huawei Campus, No. 156 Beiqing Rd. 752 | Beijing 100095 753 | 754 | Email: qiangli3@huawei.com 755 | 756 | 757 | Shuping Peng 758 | Huawei Technologies 759 | Huawei Campus, No. 156 Beiqing Rd. 760 | Beijing 100095 761 | 762 | Email: pengshuping@huawei.com 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | 784 | Qin, et al. Expires September 25, 2017 [Page 14] 785 | -------------------------------------------------------------------------------- /NS_drafts/draft-qin-netslices-use-cases-01.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | Network Slicing Use Cases: Network Customization for different services 14 | 15 | 16 | Huawei Technologies 17 |
18 | 19 | Huawei Campus, No. 156 Beiqing Rd. 20 | Beijing 21 | 100095 22 | 23 | 24 | 25 | 26 | qinjun4@huawei.com 27 | 28 |
29 | 30 | 31 | Huawei Technologies 32 |
33 | 34 | 2890 Central Expressway 35 | Santa Clara 36 | CA 95050 37 | 38 | 39 | 40 | 41 | kiran.makhijani@huawei.com 42 | 43 |
44 | 45 | 46 | Huawei Technologies 47 |
48 | 49 | Huawei Campus, No. 156 Beiqing Rd. 50 | Beijing 51 | 100095 52 | 53 | 54 | 55 | 56 | jie.dong@huawei.com 57 | 58 |
59 | 60 | 61 | Huawei Technologies 62 |
63 | 64 | Huawei Campus, No. 156 Beiqing Rd. 65 | Beijing 66 | 100095 67 | 68 | 69 | 70 | 71 | qiangli3@huawei.com 72 | 73 |
74 | 75 | 76 | Huawei Technologies 77 |
78 | 79 | Huawei Campus, No. 156 Beiqing Rd. 80 | Beijing 81 | 100095 82 | 83 | 84 | 85 | 86 | pengshuping@huawei.com 87 | 88 |
89 | 90 | 91 | 92 | Internet 93 | none 94 | Network Slicing 95 | 96 | 97 | 98 | Network Slicing paradigm enables creation of partitioned network infrastructure to provide isolated network platforms for various service verticals. The motivation behind Network Slicing (NS) is to allow deployment of new services 99 | without causing or experiencing any disruption due to other already running or 100 | deployed services in the network. The purpose of this document is to focus on use cases that benefit from the usefulness of network slicing. 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 |
110 | Network Slicing (NS) is a widely discussed paradigm and is a mandatory 111 | requirement in 5G to meet the diverse service requirements in different 5G service scenarios. NS refers to the 112 | managed partitions of physical and/or virtual network resources, 113 | network physical/virtual and service functions that can act 114 | as an independent instance of a connectivity network and/or as a 115 | network cloud . In 116 | 3rd Generation Partnership Project (3GPP) defines "Network 117 | slicing enables the operator to create networks customized to provide 118 | optimized solutions for different market scenarios which demands 119 | diverse requirements, e.g. in the areas of functionality, performance 120 | and isolation". Draft defines 121 | network slicing in a broad context and suggests related problems and 122 | work areas. Other organizations like Next Generation 123 | Mobile Networks (NGMN) and ITU-T FG 124 | IMT-2020 also present their separate definitions of 125 | NS. 126 | 127 | To maximize resource utilization and minimize infrastructure cost, 128 | services will need to be deployed simultaneously, next to each other 129 | over a shared network as against the traditional monolithic model. 130 | Service operators can utilize or benefit from Network Slicing through 131 | multi-tenancy, enabling different customized infrastructures for 132 | different group of services across different network segments and 133 | operating them independently. Moreover, NS is also able to guarantee 134 | the isolation between different network slices. The operation of the 135 | data packets traversing one network slice must not adversely affect the 136 | service operation in other network slices sharing the same underlying 137 | packet network. 138 | 139 | This document describes use cases, where service operators can utilize or benefit from Network Slicing through multi-tenancy, enabling different customized infrastructures for different group of services across different network segments and operating them independently. Although 5G will drive NS based deployments, the scope of the document is not limited to 5G; it covers example scenarios specified from 5G vision as well as generalized scenarios that can be applied to existing infrastructures. 140 | 141 | 142 |
143 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 144 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 145 | "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 146 | 147 | Additionally, the key words "MIGHT", "COULD", "MAY WISH TO", 148 | "WOULD PROBABLY", "SHOULD CONSIDER", and "MUST (BUT WE KNOW YOU 149 | WON'T)" in this document are to interpreted as described in RFC 6919. 150 |   151 | 152 |
153 | 154 |
155 | 156 | 157 | V2X (Vehicle-to-everything): 158 | Is a communication of information from a vehicle to any other entity that may be a user end-device, network element or application end point. 159 | ITS (Intelligent Transportation Systems): 160 | Considered an aspect of Internet of Things creates a transport network. The network provides services relating to transport and traffic management systems through flow of information between sensors, smart devices and humans. 161 | Over-the-top (OTT): 162 | A service, e.g., content delivery using a CDN, operated by a different operator than the NSP to which the users of that service are attached. 163 | Industry vertical: 164 | A collection of services or tools specific to an 165 | industry, trade or market sector. Also referred to as Service Verticals in this document. 166 | 167 | 168 |
169 |
170 | 171 |
172 | 173 |
174 | [Note: To discuss diverse set of service attributes] 175 | 176 | Often services specify a broader resource requirements to perform normally whereas the underlying infrastructure is generally best-effort. Traditionally, basic service guarantees are associated with resource attributes such as: 177 | 178 | 179 | 180 | Latency 181 | Bandwidth/Burst or other bit rates. 182 | Security 183 | 184 | 185 | In addition, other attributes as mentioned below are embedded into the infrastructure to improve over all quality of experience 186 | 187 | 188 | 189 | Redundancy 190 | Reliability 191 | Authentication 192 | 193 | 194 | More recently, other service attributes have become significant such as 195 | 196 | 197 | 198 | Continuity during mobility 199 | Purpose-built network functions. 200 | Service placement 201 | 202 | 203 | It should be possible for the providers of any service to 204 | continuously evolve, adapt, and differentiate themselves through 205 | purpose-built infrastructures with minimal impact on network deployment and 206 | operations. The motivation behind 5G Network slicing paradigm is exactly that. 207 | By creating logically partitioned network infrastructures, isolated platforms 208 | for various industry verticals can be provided. NS is envisioned to enable new 209 | service deployments without having to build new network infrastructures or 210 | causing disruptions to other already deployed services in the network. In 211 | regards to NS, there are two primary characteristics, a) Strict demand for network resource, b) Network Customization. 212 | 213 |
214 | 215 |
216 | Several services are sensitive to response times and/or amount of bandwidth, e.g. realtime interactive multimedia, high bandwidth video feed or remote access to an enterprise network. Failure to meet these criteria leads to service degradation. 217 | 218 | Moreover, newer scenarios from different industries are evolving due to these factors - a) everything connected, b) technological advancements in sensors, IoT, robotics and multi-media, c) innovations in social network interactions (including both human-human or human-machine). These may impose even stricter and more specific set of resource and connectivity requirements on per service basis. 219 | The challenge lies in utilizing common network infrastructure and judiciously allocating available infrastructure resources. 220 | 221 |
222 | 223 |
224 | Network slicing is enabled through customization. Customization gives control to the operator (of a slice) to create, provision, change and consume network resources to suit their service demands. It requires ability to decompose resources from an underlying network infrastructure and logically aggregate them to tailored a part of network into a slice. These customizations are not only in the context of the network characteristics but also include network functions. 225 | 226 |
227 | 228 |
229 | Network slicing by itself is not a new concept nor its benefits are limited to 5G. While writing use cases following were considered - 230 | 231 | 232 | 233 | A Network Slicing aware infrastructure allows operators to use part of the network resources to meet stringent resource requirement as in or exploit dynamic customizations as described in . Finally, there will be scenarios that require both customization and strict resource requirements. 234 | The document doesn't specify whether a network slice consists of a single or multiple service(s). at the simplest level one service may correspond to a slice, however, it is possible that many services may become part of the same slice for the purpose of isolated data or context sharing. 235 | Use cases below are discussed from 2 perspectives - 236 | 237 | Newer scenarios: that should absolutely meet strict resource requirements, as if they use a dedicated infrastructure. The example use cases are categorized further in . 238 | Existing Scenarios: Several already deployed or existing examples that would further benefit when deployed through Network Slice paradigm are discussed in . 239 | 240 | 241 | 242 |
243 |
244 | 245 |
246 | The International Telecommunication Union (ITU) has classified 5G mobile network services into three categories: Enhanced Mobile Broadband (eMBB), Ultra-reliable and Low-latency Communications (uRLLC), and Massive Machine Type Communications (mMTC). Following representative use cases are divided based on these criteria. 247 | 248 | 249 |
250 | The scenarios in this section are discussed in regards to growth in data rate capacity, connection density and interactive media. 251 | 252 | 253 |
254 | Person-to-person or person-to-group video communication with high resolution (4K/8K) and more advanced capabilities will have a much wider usage in 5G era. In a large stadium or live event (spots/concert) setting, following kind of services can be offered: 255 | 256 | 257 | 258 | Watch HD playback video or instant replay. 259 | Stream/share live HD videos with remote friends, or photos to social networks. 260 | 261 | 262 | 263 | The connection density and date rate requirements will be high. The aim is to provide video streaming and sharing services to everyone, regardless of the physical location, the device being used, and the network connection . 264 | 265 |
266 | 267 |
268 | Virtual Reality(VR)/Augmented Reality(AR) is another demanding use case of eMBB services. VR/AR video streaming will have far more stringent network resource requirements than on-demand video content. It may require it's own dedicated infrastructure with enhanced network protocols. The adoption of bandwidth-intensive VR/AR immersive services will have a direct impact on network capacity. At present 360 degree videos are mostly low resolution, requiring ~25 Mbps network bandwidth for streaming. 360 degree video is basis of AR/VR and as the display quality improves (retina resolution, 5K per eye), the bandwidth required will ramp up to several Gbps for a fully immersive experience. 269 | The infrastructure required to deliver immersive services will be different from traditional network. It may require several purpose-built hardware-assisted for video processing inline, dedicated immersive service capacity per user and perhaps an alternate transport designed specially for video services. 270 | 271 |
272 | 273 |
274 | A purpose-built Network Slice for video streaming shall ensure first and foremost, that there is always sufficient network capacity available for users that are not attending of the live-event (eMBB slice). That is, users not subscribed to eMBB slice dedicated for the event, will not experience service degradation because available bandwidth got used up by stadium attendees. 275 | 276 | Since quality of experience is important but not critical; this slice may scale out by borrowing resources on-demand from the common infrastructure resource-pool and may even return dynamically to save costs if the bandwidth demand is low. As such slices of these kind may be temporary and destroyed at the end of the event. 277 | 278 |
279 |
280 | 281 |
282 | 283 |
284 | In industry area, usually remote operations need the support of the mobile transport networks. Operating machinery from a control center at a remote site could avoid on-site hazards relating to sites like waterworks, large process plants, mines, harbors, and chemical factory. Tele-operating heavy machinery and other equipments with high accuracy in dangerous or hard to access sites requires a high-quality communication link between the control-center and the machines. 285 | 286 |
287 | 288 |
289 | Remote surgery which enables surgeons to perform critical specialized medical procedures remotely, allowing their vital expertise to be applied globally. Providing the correct control and feedback for the surgeon entails very strict requirements in terms of latency, reliability and security. 290 | 291 |
292 | 293 |
294 | A Network slice dedicated for remote operations requires communication characteristics of low latency and low jitter. To manipulate equipment efficiently the response time of a control instruction must be as short as possible. A typical haptic control loop in a remote operation application requires latency to be below 10ms . 295 | 296 |
297 | 298 |
299 | Vehicle-to-everything (V2X) refers to an intelligent transport system where all vehicles and infrastructure systems are interconnected with each other . The V2X features fall into several categories relating to safety, navigation, infotainment, diagnostics and efficiency . This makes for an interesting use case for network slices as each category is served through a different slice; a vehicle becomes part of 3 or 4 different logical network infrastructures at the same time. For Example: 300 | 301 | 302 | 303 | A vehicle may become part of a customized slice that serves low latency and zero-packet loss slice and supports a Vehicular Ad Hoc Network (VANET) type protocols for vehicle to vehicle communication and autonomous driving. It may further have different access selection (short-range DSRC or commercial C-V2X) see for details.This slice have characteristics of constant, low bandwidth, ultra-low latency. 304 | A Vehicle may join an isolated slice that represents its car manufacturer's network for remote diagnostics, software/firmware upgrades to vehicle maybe performed. The key characteristics for this slice is to ensure security of sensors and other devices through VPN style closed network. 305 | An infotainment slice of vehicle provides broadband for in vehicle entertainment, Internet access and enhanced navigation. 306 | 307 | 308 |
309 |
310 | 311 |
312 | 313 |
314 | Smart city is an integration of public infrastructures together through Machine-to-Machine (M2M) communications and other Internet of Things (IoT) solutions. The common smart city services include: 315 | 316 | 317 | 318 | automatic metering for gas, energy, water, etc. 319 | environment monitoring for pollution, temperature, humidity, etc. 320 | light management inside buildings or even the whole city, 321 | traffic signal control, 322 | public safety alerting for natural disasters and emergencies. 323 | 324 | 325 | Building a smart city requires a variety of IOT networks to inter-operate together, These IOT networks are run by different departments with different access privileges for administration and access control. For emergency services in smart city, the communication network must ensure the reliable communication. 326 | 327 |
328 | 329 |
330 | E-health refers to the application that remote monitor the physical conditions (e.g., heart rate, pulse, blood pressure etc.), and accordingly take necessary medical measures remotely. Often E-health service could be life-critical relate its communication network must be able to provide the reliable and fast but small-size of data exchange. In addition, the privacy and security of user’s data must be guaranteed. 331 | 332 |
333 | 334 |
335 | mMTC involves potentially a large number of small and power-constrained devices, therefore, resource allocation at scale is of particular importance in mMTC type slices. Furthermore, different kind of IoT devices may exhibit quite different traffic patterns e.g., uninterrupted (heart rate monitors) & periodic delay tolerant (temperature sensors), delay sensitive (e.g., weather forecast & disaster alerting), mobility mode, security awareness etc. The mMTC type slices should be conscious of various requirements of scale, data pattern, reliability, security and energy efficient communications. 336 | 337 |
338 |
339 |
340 | 341 |
342 | Besides specific scenarios with special requirements, discussed in previous section, examples in this section benefit from sliced-network infrastructure. 343 | 344 | Over-The-Top(OTT) services are typical scenario of this kind. OTT services are those associated with content, like video (with normal definition), audio, IM messages, web-digital content, and other media transmitted via the Internet, this kind of communications are expected to be pervasive and part of everyday life. A high degree of applications such as VOIP, CDNs are deployed as OTT services with low expectations from the underlying network as communication medium and subsequently by building their own application infrastructure. The trend toward IP (or HTTP) based content delivery may be perceived as an indicative of network as dumb pipe. However, QoE is important to content delivery and requires coordination with the ISPs. With new advances in multimedia formats and social network channels service offerers must adapt to varying parameters of QoE. 345 | 346 | 347 |
348 | A network slice represented by partitioned network infrastructure allocated for content delivery can help create new opportunities for both network operators and content providers. provides many use cases relating to ISP Handling of third-party content. 349 | Following examples may be considered: 350 | - Content Service Providers (CSPs) could lease a CDN slice and operate it as a well coordinated CDN infrastructure of content awareness, optimally placed servers & proprietary optimization logic functions (different for live video (real-time) and on-demand (caching)). 351 | - VOIP is a peer to peer service and requires CBR across multiple domains. If a VOIP-slice specification is from a well-known template that is universally understood then a low cost, reliable end-to-end VOIP service can be offered without intense provisioning of the transport. 352 | 353 |
354 |
355 | 356 |
357 | Along another dimension, many services will have combination of hard resource constraints that were discussed in such as both eMBB and uRLL. 358 | Some examples are as follows 359 | - As described in , AV/VR has high bandwidth requirement but 'interactive' VR/AR applications are extremely sensitive to delay and require very low end-to-end latency (~20ms). 360 | - While operating machinery remotely, the primary communication characteristics are low latency and low jitter but in case of video assisted maintenance, the bandwidth also becomes important. In fact, most of the applications have mixed requirements from the network infrastructure. 361 | 362 |
363 | 364 |
365 | 366 | 367 | Network Operator View: It is a daunting task to manage ever increasing number of services with their customized resource requirements. A logical division of networks shall allow simpler orchestration, management and operation both for service operator and network operators. 368 | Opportunities in Industry verticals: With an independent control of services and associated network resources, Industry verticals can test and deploy services quicker. 369 | 5G context: While the scope of document does not limit to 5G, it is important to take into consideration that 5G blurs the boundary between fixed and mobile networks. some related factors are (1) end-device access will be mainly radio or wireless but very well be fixed (2) end-device is simultaneously associated with those many access networks (3) transport could be IP or non-IP based. 5G will also be early adopter of Network Slicing in its architecture, therefore, many scenarios from 5G will be prioritized. 370 | Heterogeneous resources: Different kind of resources maybe required in difference slices. Each network slice appears to its users as an independent, dedicated private network which is impervious to anything including the heterogeneous resources that is happening on any of the other network slices, a high degree of isolation on data plane is needed. 371 | Transport Context: the transport network should give a customized topology built for a different network slices, and provide the network resources and performance characteristics like bandwidth, latency, jitter, security, availability, and etc that required by the corresponding slices. 372 | 373 | 374 |
375 | 376 |
377 | Many emerging services, together with the existing and evolving services will be carried out in the context of 5G network slicing. The goal of 5G is to support various service scenarios which have very diverse and strict demands from the network infrastructure. 378 | 379 | These scenarios require networks to be more flexible and scalable to support customized service requirements and diverse performance requirements with a single network infrastructure. Specifically, the current transport network architecture is not as flexible or scalable to provide the required network customizations and the resource assurances for different type of use cases at simultaneously. 380 | 381 | Network slicing is a way to to support service or industry verticals over the same physical network such that each network slice appears to its tenant as an independent, dedicated private network and is impervious to anything that is happening on any of the other network slices. For services which do not have special requirements from the network; slicing provides an effective way for those to coexist along with the services having strict requirements. 382 | 383 |
384 | 385 |
386 | The security considerations apply to each slice. In addition general security 387 | considerations of underlying infrastructure whether isolated communication with 388 | in a slice apply for links using wireless technologies. 389 | 390 |
391 | 392 |
393 | There are no IANA actions requested at this time. 394 | 395 |
396 | 397 |
398 | Thanks to Stewart Bryant for providing details for several use cases. 399 | 400 |
401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | FG IMT-2020: Report on Standards Gap Analysis 413 | 414 | 415 | 416 | 417 | 418 | 419 | Intelligent Transportation Systems and the IETF 420 | 421 | 422 | 423 | 424 | 426 | 427 | 5G White Paper 428 | 429 | Next Generation Mobile Network Alliance 430 | 431 | 432 | 433 | 434 | 435 | 436 | Description of Network Slicing Concept 437 | 438 | Next Generation Mobile Network Alliance 439 | 440 | 441 | 442 | 443 | 444 | 445 | Study on Architecture for Next Generation System 446 | 447 | International Telecommunications Union 448 | 449 | 450 | 451 | 452 | 453 | 455 | 456 | Technology Watch Report, The Tactile Internet 457 | 458 | ITU-T 459 | 460 | 461 | 462 | 463 | 464 | 465 | The Case for Cellular V2X for Safety and Cooperative Driving 466 | 467 | 5G Automotive Association 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | -------------------------------------------------------------------------------- /Network Slicing Architecture.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/Network Slicing Architecture.docx -------------------------------------------------------------------------------- /Network Slicing Architecture_hfl.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/Network Slicing Architecture_hfl.docx -------------------------------------------------------------------------------- /Nsdt-2019/ns_defn.md: -------------------------------------------------------------------------------- 1 | %%% 2 | Title = "IETF Definition of Transport Slice" 3 | abbrev = "IETF Definition of Transport Slice" 4 | ipr= "trust200902" 5 | area = "Internet" 6 | workgroup = "TEAS WG" 7 | submissiontype = "IETF" 8 | keyword = [""] 9 | date = 2019-12-09T00:00:00Z 10 | 11 | [seriesInfo] 12 | name = "Internet-Draft" 13 | value = "draft-nsdt-teas-transport-slice-00" 14 | stream = "IETF" 15 | status = "informational" 16 | 17 | [[author]] 18 | initials="R." 19 | surname="Rokui" 20 | fullname="Reza Rokui" 21 | organization = "Nokia" 22 | [author.address] 23 | email = "reza.rokui@nokia.com" 24 | [author.address.postal] 25 | code = "Canada" 26 | 27 | [[author]] 28 | initials="S." 29 | surname="Homma" 30 | fullname="Shunsuke Homma" 31 | organization = "NTT" 32 | [author.address] 33 | email = "shunsuke.homma.fp@hco.ntt.co.jp" 34 | [author.address.postal] 35 | code = "Japan" 36 | 37 | [[author]] 38 | initials="K." 39 | surname="Makhijani" 40 | fullname="Kiran Makhijani" 41 | organization = "Futurewei" 42 | [author.address] 43 | email = "kiranm@futurewei.com" 44 | [author.address.postal] 45 | code = "USA" 46 | %%% 47 | 48 | .# Abstract 49 | 50 | This document describes the definition of transport slice in IETF, 51 | and describes considerations for realization of transport slice. 52 | This work is part of work on TEAS WG network slicing Design Team. 53 | 54 | {mainmatter} 55 | 56 | # Introduction 57 | 58 | Network slicing is a methodology to generically describe the logical 59 | partitioning of network resources associated with a service or an 60 | application. Network Slicing is considered very useful because there 61 | is a need to generically describe diverse set of services and related 62 | resource requirements that can then be applied to any number or type 63 | of proposed, implemented and/or deployed technologies and associated 64 | devices. Some key applications which might benefit from the use of 65 | network slicing include: 66 | 67 | - 5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP]) 68 | - Wholesale business VPN 69 | - Network infrastructure sharing among the operators 70 | - NFV connectivity (Data Center Interconnect) 71 | 72 | A network slice is composed of different endpoints and application 73 | specific connectivity between them. Transport network slices are a 74 | type of network slices that are created and managed with in the scope 75 | of transport networks (IP, MPLS, GMPLS). There is no concrete 76 | definition for network transport slices established or method to 77 | realize them. 78 | 79 | This document provides a definition of 'transport slice' in IETF, and 80 | describes considerations for realization of transport slices. In 81 | this document the term transport slice is used as short form for 82 | transport network slice. 83 | 84 | 85 | # Terms and Abbreviations 86 | 87 | Service Level Objective (SLO): 88 | 89 | NS ID 90 | 91 | mMTC 92 | 93 | URLLC 94 | 95 | # High level architecture of end-to-end network slicing 96 | 97 | An end-2-end (E2E) network slice is a complete network slice that 98 | provides a service in its entireity with a specific assurance to the 99 | customer. A transport slice concerns those assurance aspects only 100 | with in the transport networks. To illustrate the IETF definitions 101 | of both E2E network slice and transport slice, consider the network 102 | shown in [@FigE2ENS], where a network operator has an E2E network slice 103 | that traverses multiple technology-specific networks. Each of these 104 | networks might use any of a number of technologies, including IP, 105 | MPLS, Fiber-Optics (e.g. WDM, DWDM), Passive Optical Networking 106 | (PON), Microwave, etc. 107 | 108 | Each of these networks includes multiple (physical or virtual) nodes 109 | and may also provide network functions beyond simply carrying of 110 | technology-specific protocol data units. The types of nodes used in 111 | any of these networks may include: 112 | 113 | - Packet Switches (e.g. Routers, Bridges) 114 | - Application servers 115 | - Firewalls 116 | - Radio Access Network (RAN) components 117 | - Mobile Core componets 118 | - Microwave transceivers 119 | - Optical repeaters 120 | - etc. 121 | 122 | Each network may support different technology and an E2E netowrk 123 | slice is a combination of these networks. As an example: 124 | 125 | - Network 1 might contain multiple 5G RAN nodes connected to a few 126 | Cell Site Gateways (CSG) routers. 127 | - Network 2 might have one or more layer-3 routers and layer-2 128 | - Network 3 might have a few 5G RAN nodes connecting to Passive 129 | Optical Network (PON) switches. 130 | 131 | {#FigE2ENS} 132 | ~~~ ascii-art 133 | <======================= E2E NS ===================> 134 | 135 | 136 | <-OS1-> <-TS1-> <-TS2-> <-OS2-> ... <-TSn-> <-OSm-> 137 | 138 | |------------------------------------------------------| 139 | | .--. .--. .--. | 140 | | ( )--. ( )--. ( )--. | 141 | | .' ' .' ' .' ' | 142 | [EU-x] | ( Network-1 ) ( Network-2 ) ... ( Network-p ) |[EU-y] 143 | | `-----------' `-----------' `----------' | 144 | | | 145 | | Operator-z | 146 | |------------------------------------------------------| 147 | Legend: 148 | E2E NS: End-to-end network slice 149 | TSn: Transport Slice n 150 | OSm: Other Slice m 151 | EU-x: End User-x 152 | EU-y: End User-y 153 | 154 | ~~~ 155 | Figure: E2E network slice 156 | 157 | To further clarify the concept of the E2E network slice, consider the 158 | network operator-z has various customers. One of the customers, 159 | needs a separate and an independent E2E logical network for a service 160 | (e.g. CCTV, autonomous driving, HD map etc.) and has a specific 161 | network SLA requirement (e.g. a secure connection with an E2E latency 162 | less than 5ms) from End User-x (EU-x) to End User-y (EU-y) to the 163 | other side. This E2E logical network is called an "E2E network 164 | slice". A typical example of EU-x in 5G is the User equipment such 165 | as infotainment unit in the car, CCTV, Car for autonomous driving 166 | etc. and a typical example of EU-y in 5G is 5G application server, 167 | IMS etc. 168 | 169 | In Figure {@FigE2ENS} we use the term "E2E network slice" to show the logical 170 | network with requested SLA from EU-x to EU-y. It is important to 171 | consider that an "E2E network slice" is associated with a customer 172 | and a service type (e.g. CCTV service, autonomous driving etc.). 173 | 174 | For example, a customer "City of NY" would like to connect all its 175 | CCTV cameras for the entire city to one or more locations for viewing 176 | or collection. To this end, it requests local carrier - 'operator-z' 177 | in NY to create a new E2E network slice with a bandwidth no-less-than 178 | 10Mbps from each CCTV coverage area. In this case, a single E2E 179 | network slice will be created by the operator-z for customer "City of 180 | NY", service type of CCTV and requested bandwidth connecting all the 181 | CCTV camera zones to one or more control-centers for the collection 182 | of video data. 183 | 184 | It may also be possible that more than one customer and/or service 185 | types are associated with an E2E network slice. For instance, an E2E 186 | network slice is associated with not only to service type CCTV but 187 | another service "Public Safety", i.e. NS ID 10 is used for two 188 | services for City of NY. 189 | 190 | # IETF Definition and Scope of Transport slice 191 | 192 | ## Defintion 193 | 194 | The IETF definition of a transport slice is as follows: 195 | 196 | A transport network slice is an abstract network topology connecting 197 | a number of endpoints, with an expected network service specified 198 | through a set of service level objectives. 199 | 200 | Note that multiple transport slices can be combined together into one 201 | transport slice, in that case each segment will be called transport 202 | subslice or transport subnet slice. The document will consistently 203 | use the term transport subslice. Use of service level objectives 204 | help to clearly describe different network resources and 205 | corresponding parameters neccessary to describe a service. 206 | 207 | Informally, a transport slice has a set of connections and various 208 | endpoints to form a logical network. The goal is to achieve specific 209 | SLO for a customer as shown in Figure [@FigTS]. The endpoints maybe any 210 | physical or virtual network functions (PNF/VNF) or any network 211 | service for that matter. Simillarly connections maybe virtual or 212 | physicals links of any type of technology. 213 | 214 | {#FigTS} 215 | ~~~ ascii-art 216 | 217 | <------- Transport slice --------> 218 | 219 | .--. .--. 220 | [EP11] ( )- . ( )- . [EP21] 221 | .' ' .' ' 222 | [EP12] ( Network-1 ) ... ( Network-p ) [EP22] 223 | : `-----------' `-----------' : 224 | [EP1m] [EP2n] 225 | 226 | Legend 227 | EP: Endpoint 228 | ~~~ 229 | Figure: Transport network slice 230 | 231 | Referring to Figure [@FigE2ENS], when operator-z creates a specific E2E network 232 | slice, it should create one or more of the following two types of 233 | artefacts: 234 | 235 | - Transport slice (or transport sub-slices) 236 | - Other slice (application logic or other non-IETF slice components) 237 | 238 | As shown in Figure [@FigE2ENS], an E2E network slice might have one or more of 239 | "Transport Slices" and one or more of other slices of any 240 | combinations. One of the critical parts of an E2E network slice is 241 | "Transport Slices" which provides various connections with certain 242 | SLA between various endpoints. 243 | 244 | Defining the other slices is out-of-scope of current work. 245 | 246 | Figure [@FigTS] illustrates the definition of a Transport Slice where a 247 | single transport slice provides connectivity between "m" endpoints on 248 | left-hand side to "n" endpoints on right-hand side with specific 249 | characteristic for Service Level Agreement (SLA). 250 | 251 | Each transport slice has the following main characteristics: 252 | 253 | - Transport slice definition: It addresses a set of technology- 254 | agnostic connections between various endpoints with certain SLA 255 | - Transport slice realization: In addition to its definition, a 256 | Transport Slice has a realization in the operator's network. 257 | Unlike transport slice definition, which is technology agnostics, 258 | its realization is technology specific. 259 | 260 | ## Transport Slice Characteristics 261 | 262 | TODO 263 | 264 | ### Service Level Objectives 265 | 266 | TODO 267 | 268 | ### Endpoints 269 | 270 | TODO 271 | 272 | ### Slice Isolation 273 | TODO 274 | 275 | # Transport Slice Examples 276 | 277 | ## Scenario-1 278 | 279 | Figure [@Fig5G] depicts an example of transport slice connecting two 5G RAN 280 | nodes (gNB) to three 5G Core user plan function nodes (UPF). In this 281 | case a transport slice 20 is created with SLA including 10 [msec], or 282 | better, latency between 5G endpoints gNBs and UPFs. 283 | 284 | {#Fig5G} 285 | ~~~ ascii-art 286 | 287 | <--- Transport slice(TS ID:20) ---> 288 | with SLA of latency, less 289 | than 10[msec] 290 | 291 | .----. [UPF1] 292 | [gNB1] ( )----. 293 | .---' '----. [UPF2] 294 | [gNB2] ( Network ) 295 | `-----------------------' [UPF3] 296 | 297 | 298 | ~~~ 299 | Figure: Example of Transport Slice 20 connecting gNBs to 5G Core UPF 300 | 301 | ## Scenario-2 302 | 303 | Figure {#FigSF} depicts another example where transport slice 30 is created 304 | to connect router ER1 to two firewall endpoints with SLA including 10 305 | [Mbps], or higher, bandwidth. 306 | 307 | {#FigSF} 308 | ~~~ ascii-art 309 | <--- Transport slice(TS ID:30) ---> 310 | with SLA B/W 5Mbps 311 | 312 | .----. 313 | ( )----. 314 | .---' '----. [FW1] 315 | [ER1] ( Network ) 316 | `-----------------------' [FW2] 317 | 318 | Legends 319 | ER: Edge Router 320 | FW: Firewall 321 | ~~~ 322 | Figure: Example of Transport Slice connecting Router to two firewalls 323 | 324 | ## Scenario-3 325 | 326 | Another example of transport slice is SFC case as shown in Figure 5 327 | and Figure 6 which depict an example with SF1 and SF2 (e.g. DPI, 328 | Firewall, WAF, video optimizer, content cache server, NAT/CGN, Load 329 | balancer) and the transport slice between ER1 and ER2 traverses these 330 | SFs. There are two approaches: 331 | 332 | - Approach-1 shown in Figure [@FigSF1] where Transport slice 40 chains 333 | router ER1, SF1, SF2, and router ER2. Transport slice 40 needs 334 | lower than 30 ms delay. However, endpoints SF1 and SF2 are 335 | implicitly identified during the transport slice realization. In 336 | this case, a single transport slice is created between ER1 and 337 | ER2. 338 | - Approach-2 shown in Figure [@FigSF2] where the transport slice 40 can be 339 | broken into transport slices 41, 42, 43. In this case SF1 and SF2 340 | are explicityly identified and as a results three transport slices 341 | between following endpoints will be realized: 342 | 343 | -- Between endpoints ER1 and SF1 344 | -- Between endpoints SF1 and SF2 345 | -- Between endpoints SF2 and ER2 346 | 347 | {#FigSF1} 348 | ~~~ ascii-art 349 | <--- Transport slice(TS ID:40) ---> 350 | with SLA of latency 30ms 351 | 352 | +-----+ 353 | | SF1 | 354 | + *** + .----. 355 | * * ( )--. 356 | * * ( ) 357 | * * --' Network '--. 358 | [ER1]******** *********** *************[ER2] 359 | `-------------*-*--------' 360 | * * 361 | + *** + 362 | | SF2 | 363 | +-----+ 364 | ~~~ 365 | Figure: Approach-1: Example of Transport Slice connecting Edge Routers ER1 and ER2 with SFC 366 | 367 | {#FigSF2} 368 | ~~~ ascii-art 369 | 370 | <-- Transport slice (TS ID:40) --> 371 | with SLA latency 30ms 372 | <- TS41 -> <- TS42 -> <- TS43 --> 373 | SLA SLA SLA 374 | 5[ms] 20[ms] 5[ms] 375 | 376 | +-----+ 377 | | SF1 | 378 | + *** + .----. 379 | * * ( )--. 380 | * * ( ) 381 | * * --' Network '--. 382 | [ER1]******** *********** *************[ER2] 383 | `-------------*-*--------' 384 | * * 385 | + *** + 386 | | SF2 | 387 | +-----+ 388 | ~~~ 389 | Figure: Approach-2: Example of Transport Slice connecting Edge Routers ER1 and ER2 with SFC 390 | 391 | # Realization of Transport slice 392 | 393 | In addition to its definition, a Transport Slice has another 394 | characteristic which is its realization in the operator's network as 395 | shown in Figure [@FigReal]. The creaton of a new Transport Slice will be 396 | initiated from a northbound interface whereby a higher level system 397 | can request connections with specific characteristics (Step 1). This 398 | request will be processed by a Transport Slice Controller (Step 2) 399 | which specifies a mapping between northbound request to any IETF 400 | Services, Tunnels and paths. A series of requests for creaton of 401 | services, tunnels and paths will be sent to the network to realize 402 | the trasport slice. 403 | 404 | 405 | {#FigReal} 406 | ~~~ ascii-art 407 | |------------------------------------------| 408 | | A highter level system | 409 | | (e.g e2e network slice orchestrator) | 410 | |------------------------------------------| 411 | | (Step 1) 412 | | 413 | V 414 | |------------------------------------------| 415 | | Transport Slice Controller |(Step 2) 416 | |------------------------------------------| 417 | | (Step 3) 418 | | 419 | V 420 | 421 | Step 1: 422 | The higher level system (e.g. e2e network slice orchestrator) 423 | can request a transport slice with specific characteristics 424 | 425 | Step 2: 426 | The transport slice controller maps the northboud request to 427 | any IETF Services/Tunnels/Paths models 428 | 429 | Step 3: 430 | Realize the transport slice by creating Services/Tunnels/Paths 431 | 432 | 433 | ~~~ 434 | Figure: Transport Slice Realization 435 | 436 | ## Realization of Scenario-1 437 | 438 | Figure [@FigE2ENS] depicts the realization of the transport slice 20 of 439 | [@Fig5G]. Operator's transport slice controller invoke an abstract 440 | API to create a transport slice between 5G endpoints gNB1 and gNB2 to 441 | 5G Core endpoints UPF1, UPF2 and UPF3 with SLA inlcuding 10 [ms] 442 | latency. 443 | 444 | Since in most cases the passed in endpoints (i.e. 5G RAN and 5G Core 445 | endpoints) cannot support any IP/MPLS/Optics services, the endpoints 446 | to realize the transport slice 20 will not be the endpoints passed 447 | in. This is one of the most important aspects to consider when 448 | realizing the transport slices. 449 | 450 | As shown in [@FigE2ENS], the realization of transport slice 20 required 451 | the transport slice controller to find out the "best" endpoints which 452 | support the realization of transport slice 20 in the network, i.e. 453 | endpoints ER1, ER2 and ER3. After that, the realization of the 454 | transport slice 20 will be initiated by creation of various 455 | services/tunnels/paths between edge routers ER1, ER2 and ER3. The 456 | type of Services/Tunnels/Paths depends on the supported technologies 457 | of endpoints ER1, ER2 and ER3. 458 | 459 | In this scenario, the end points of transport slice realization are 460 | not those endpoints passed in, i.e. 461 | 462 | - Definition of transport slice is between gNB1 and gNB2 to UPF1, 463 | UPF2, and UPF3 464 | - Realization of transport slice is between edge routers ER1, ER2 465 | and ER3 466 | 467 | {#FigNS20} 468 | ~~~ ascii-art 469 | 470 | | Create Transport slice 20 between gNB1 & gNB2 471 | | to UPF1 & UPF2 & UPF3 with SLA latency 472 | | 10 ms or better 473 | v 474 | +----------------------------------+ 475 | | Transport Slice Controller | 476 | +----------------------------------+ 477 | | Realize transport slice 20 between 478 | | ER1, ER2 and ER3 with SLA latency of 479 | | 10 ms or better 480 | v +----+ 481 | .----. +UPF1| 482 | [gNB1] +----+ ( )---. /+--=-+ 483 | \ | |===========================[ER2]+ 484 | \| ER1| ( Network ) +----+ 485 | /| |===========================[ER3]+-|UPF2| 486 | / +----+ `----------------' + +----+ 487 | [gNB2] \ 488 | \+----+ 489 | +UPF3| 490 | +----+ 491 | Legends 492 | === : Tunnels & Services 493 | ER: Edge Router 494 | 495 | ~~~ 496 | Figure: Realization of Transport slice 20 of [@Fig5G] 497 | 498 | ## Realization of Scenario-2 499 | 500 | [@FigNS30} depicts the realization of transport slice 30 of [@FigSF]. 501 | Operator's Transport Slice Controller receives a request to create a 502 | transport slice between network functions R1 and firewalls FW1 and 503 | FW2 with SLA including 5 [Mbps]. Depends on the underlying network 504 | topology, Operator's transport slice controller will realize the 505 | transport slice. For example, if both network functions (i.e. R1, 506 | FW1, FW2) and network supports segment routing, two Tunnels/Services 507 | of type SR can be created (or used) in the network between R1, FW1 508 | and FW2 to realise the transport slice 30. However, if the network 509 | just supports RSVP, two tunnels/services of type RSVP can be used to 510 | realize this transport slice. 511 | 512 | Note that since the network functions ER1, FW1 and FW2 support 513 | segment routing, the endpoints of the tunnels in this example are 514 | those endpointss passed in, i.e. the endpoints of the both transport 515 | slice definiton and its realization are R1, FW1 and FW2: 516 | 517 | - Definition of transport slice is between network functions R1 to 518 | FW1 and FW2 519 | - Realization of transport slice is between network functions R1 to 520 | FW1 and FW2 521 | 522 | We will see in next example that in some scenarios this is not the 523 | case and the endpoints of Transport Slice definition might be 524 | different from endpoints of its realization of transport slices. 525 | 526 | It is very clear that regardless of how transport slice is realized 527 | in the network (i.e. using tunnels of type RSVP or SR), the 528 | definition of transport slice 30 does not change at all but rather 529 | its realization. 530 | 531 | {#FigNS30} 532 | ~~~ ascii-art 533 | | Create Transport slice 30 between 534 | | ER1 and FW1 and FW2 with SLA 5 Mbps 535 | v 536 | +----------------------------------+ 537 | | Transport Slice Controller | 538 | +----------------------------------+ 539 | | Realize transport slice 30 540 | | between R1 and FW1 & FW2 541 | | with SLA 5 Mbps 542 | v 543 | .----. 544 | +----+ .----( )----. 545 | | |=============================[FW1] 546 | | ER | ( Network ) 547 | | |=============================[FW2] 548 | +----+ `----------------' 549 | 550 | Legends 551 | === : Tunnels & Services of type SR 552 | or RSVP with SLA 5 Mbps 553 | 554 | ~~~ 555 | Figure: Realization of Transport slice 30 of [@FigSF] 556 | 557 | ## Realization of Scenario-3 558 | 559 | Figure 9 depicts the realization of the transport slice 40 of 560 | Figure 4 where a transport slice needed between network functions R1 561 | and R2 across SF1 and SF2. However, the location of SF1 and SF2 are 562 | decided internally with a logic in Transport Slice Controller. For 563 | example, when SLA requires the high secure transport slice between 564 | ER1 and ER2 which in turn results on adding SF1 and SF2 to the 565 | realization of transport slice 40 implicitly by transport slice 566 | controller. 567 | 568 | Figure 10 shows the realization of the transport slice 40 of 569 | Figure 5. In this case the location of SF1 and SF2 has been 570 | explicitly decided by higher level logic. In this case three 571 | transport slices 41, 42 and 43 will be created separately and 572 | eventually bind together to form a single transport slice 40 to meet 573 | the SLA that delay is lower than 30 ms. 574 | 575 | {#FigNSSF1} 576 | ~~~ ascii-art 577 | | Create transport slice between ER1 578 | | and ER2 with latency 30 [msec] 579 | v 580 | +------------------+ +-----------+ 581 | | Transport slice |<------------>| SF | 582 | | controller | | Manager | 583 | +------------------+ +-----------+ 584 | | Realize transport slice 40 between 585 | | ER1 & ER2 traversing SF1 and SF2 586 | | with SLA of latency 30 [msec] 587 | V 588 | <----------------- TS 40 -------------------> 589 | +-----+ 590 | | SF1 | 591 | + === + .----. 592 | # # ( )--. 593 | # # ( ) 594 | # # --' Network '--. 595 | [ER1]========= ========= ===================[ER2] 596 | `-------------- # # --------' 597 | # # 598 | + == + 599 | | SF2 | 600 | +-----+ 601 | 602 | Legends 603 | ===== : Tunnels & Services 604 | 605 | 606 | ~~~ 607 | Figure: Realization of Transport slice 40 of Figure 5 608 | 609 | {#FigNSSF2} 610 | ~~~ ascii-art 611 | 612 | | Requirements on communication 613 | | between ER1 and ER2 614 | v 615 | +---------------------+ +-----------+ 616 | | High level system | <--------> | SF Manager| 617 | +---------------------+ +-----------+ 618 | | Create transport slice between ER1 and SF1, 619 | | with latency 5 [msec] 620 | | Create transport slice between SF1 and SF2, 621 | | with latency 20 [msec] 622 | | Create transport slice between SF2 and ER2, 623 | | with latency 5 [msec] 624 | v 625 | +-------------------+ 626 | | Transport slice | 627 | | controller | 628 | +-------------------+ 629 | | | | Realize TS 41 between ER, SF1 630 | | | | with latency 5 msec 631 | +------+ | +-------+ Realize TS 42 between SF1, SF2 632 | | | | with latency 20 msec 633 | | | | Realize TS 43 between SF2, ER2 634 | | | | with latency 5 msec 635 | v v v 636 | <--TS 41--> <--TS 42--> <--TS 43 --> 637 | <---------------- TS 40 ----------------> 638 | +-----+ 639 | #=| SF1 | 640 | # +-----+ .----. 641 | # # ( )--. 642 | # .---#' Network '--. 643 | [ER1]=====#( #==========# )#=====[ER2] 644 | `--------------#------' # 645 | # # 646 | +-----+ # 647 | | SF2 |====# 648 | +-----+ 649 | 650 | Legend 651 | === : Tunnels & Services 652 | 653 | 654 | ~~ 655 | Figure: Realization of Transport slice 40 of Figure 6 656 | 657 | {backmatter} 658 | 659 | 660 | 661 | 3rd Generation Partnership Project (3GPP) 662 | 3GPP TS 23.501 (V16.2.0): System Architecture for the 5G System (5GS) Stage 2 (Release 16) 663 | 664 | month='September', year='2019' 665 | 666 | 667 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IETF-NetSlices 2 | Network Slicing Concepts at IETF 3 | 4 | ## First Side meeting material 5 | - dire: IETF_SideMeeting01 6 | - Minutes: https://mailarchive.ietf.org/arch/search/?email_list=netslices&q=minutes 7 | 8 | ## Mailing List: 9 | - netslices@ietf.org 10 | - https://www.ietf.org/mailman/listinfo/netslices 11 | 12 | ## List of Drafts for Discussion 13 | 14 | 1. Network Slicing - Introductory Document [ietf: NSINTRO][2] 15 | 2. Problem Statement of Network Slicing in IP/MPLS Networks [ietf: NSPS00][1] 16 | 17 | 18 | [1]: https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02 19 | [2]: https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00 20 | -------------------------------------------------------------------------------- /ToC-NSFramework_Revisited_V1.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/ToC-NSFramework_Revisited_V1.docx -------------------------------------------------------------------------------- /draft-netslices-problem-statement-00.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/draft-netslices-problem-statement-00.docx -------------------------------------------------------------------------------- /draft-ns-gap-analysis.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/draft-ns-gap-analysis.docx -------------------------------------------------------------------------------- /slicing_usecases_draft_0.2.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/slicing_usecases_draft_0.2.docx -------------------------------------------------------------------------------- /slicing_usecases_draft_0.2_HFl.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/netslices/IETF-NetSlices/1a68994cbc3074872e50b9892013a9e60fce1631/slicing_usecases_draft_0.2_HFl.docx --------------------------------------------------------------------------------