idnits 2.17.1 draft-qiang-coms-netslicing-information-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 62 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 153 has weird spacing: '...node-id str...' == Line 155 has weird spacing: '...port-id str...' == Line 157 has weird spacing: '...node-id str...' == Line 159 has weird spacing: '...port-id str...' == Line 173 has weird spacing: '...unit-id str...' == (2 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 25, 2017) is 2398 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 495 looks like a reference -- Missing reference section? 'COMS-PS' on line 492 looks like a reference -- Missing reference section? 'ServerName' on line 192 looks like a reference -- Missing reference section? 'TBD' on line 490 looks like a reference Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 none L. Qiang 3 Internet-Draft Huawei 4 Intended status: Informational A. Galis 5 Expires: March 29, 2018 University College London 6 L. Geng 7 China Mobile 8 K. Makhijani 9 Huawei 10 P. Martinez-Julia 11 NICT 12 H. Flinck 13 Nokia 14 September 25, 2017 16 Technology Independent Information Model for Network Slicing 17 draft-qiang-coms-netslicing-information-model-00 19 Abstract 21 This document provides a technology independent information model for 22 transport network slicing. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 29, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Network Slice Tree Structure . . . . . . . . . . . . . . . . 3 61 3.1. atomic-component . . . . . . . . . . . . . . . . . . . . 5 62 3.1.1. connectivity-cateogry . . . . . . . . . . . . . . . . 6 63 3.1.2. storage-cateogry . . . . . . . . . . . . . . . . . . 7 64 3.1.3. compute-categoty . . . . . . . . . . . . . . . . . . 8 65 3.2. predefined-function-block . . . . . . . . . . . . . . . . 8 66 3.3. global-attributes . . . . . . . . . . . . . . . . . . . . 8 67 4. Opeartions . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 8. Informative References [TBD] . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 Considering the business logic of network slicing as shown in Fig. 77 Figure 1. At the top layer, tenants describe the service that they 78 want through a service model, and this service model dose not bind to 79 any specific implementation technology. At the bottom layer, 80 multiple technologies are available to be used to support the network 81 slicing service. Between the common service model and lots of 82 available implementation technologies, there is a gap which needs a 83 technology independent information model. During the implementation 84 process, the most appropriate technology will be selected according 85 to the SLA, and the management/operations on the information model 86 also will be translated into the language understood by the select 87 technology (or directly translated into a set of network parameters 88 configurations). 90 Service Model 91 Tenant<---------->Network Slicing Service Provider 92 ^ 93 | 94 | 95 |Management/Operations 96 +---------------------v-----------------------+ 97 | Technology Independent NS Information Model | 98 +---------------------^-----------------------+ 99 |Mapping to Specific Technology 100 | 101 | 102 +----------+-----------+------------+ 103 | | | | 104 | | | | NS-Oriented Extension in 105 | | | | Each Specific Technology 106 | | | | 107 +---v--+ +--v---+ +--v---+ +---v--+ Available 108 | ACTN | |DetNet| | VPN | | SR | ... Implementation 109 +------+ +------+ +------+ +------+ Technologies 111 Figure 1: Technology Independent NS Information Model 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Other network slicing related words used in this document are 120 interpreted as description in [COMS-PS]. 122 Yang language is used to represent the transport network slice 123 information model. 125 3. Network Slice Tree Structure 127 Following is the tree structure of network slice. 129 module: ietf-coms-information-model 130 +--rw network-slice 131 +--rw atomic-component 132 | +--rw connectivity-category 133 | | +--rw node-list 134 | | | +--rw node* 135 | | | +--rw node-id string 136 | | | +--rw location? string 137 | | | +--rw port* [port-id] 138 | | | | +--rw port-id string 139 | | | | +--rw port-rate? int32 140 | | | | +--rw packet-loss-probability? uint8 141 | | | | +--rw packet-loss-threshold? unit8 142 | | | | +--rw received-packets? int32 143 | | | | +--rw sent-packets? int32 144 | | | +--rw forwarding-policy 145 | | | +--rw match? string 146 | | | +--rw action? string 147 | | | +--rw priority? string 148 | | | +--rw counter? int64 149 | | +--rw link-list 150 | | +--rw link* [link-id] 151 | | +--rw link-id string 152 | | +--rw src-node 153 | | | +--rw node-id string 154 | | +--rw src-port 155 | | | +--rw port-id string 156 | | +--rw dst-node 157 | | | +--rw node-id string 158 | | +--rw src-port 159 | | | +--rw port-id string 160 | | +--rw link-bandwidth-agreement? string 161 | | +--rw link-throughput? string 162 | | +--rw link-throughput-threshold? string 163 | | +--rw link-latency-agreement? string 164 | | +--rw link-latency? string 165 | | +--rw link-jitter-agreement? string 166 | | +--rw link-jitter? string 167 | | +--rw link-jitter-threshold? string 168 | | +--rw physical-path-restriction 169 | | +--rw mandatory-physical-device* 170 | | +--rw exclusive-physical-device* 171 | +--rw storage-category 172 | | +--rw storage-unit* [storage-unit-id] 173 | | +--rw storage-unit-id string 174 | | +--rw size? int64 175 | | +--rw ingress-rate? string 176 | | +--rw egress-rate? string 177 | | +--rw read-write-mode? enumeration 178 | | +--rw access-mode? enumeration 179 | | +--rw redundancy? boolean 180 | | +--rw location? string 181 | +--rw compute-category 182 | +--rw compute-unit* [compute-unit-id] 183 | +--rw compute-unit-id string 184 | +--rw alu-number? int8 185 | +--rw speed? string 186 | +--rw cache-size? string 187 | +--rw access-mode? enumeration 188 | +--rw location? string 189 +--rw predefined-function-block 190 | +--rw sdn-controller 191 | | +--rw ActiveOF 192 | | | +--rw OFServer* [ServerName] 193 | | | +--rw ServerName string 194 | | | +--rw IPAddress? IPAddressType 195 | | | +--rw Port? PortType 196 | | +--rw PassiveOF 197 | | +--rw OFPort? PortType 198 | +--rw firewall 199 | +--rw vswitch 200 | +--rw load-balancer 201 +--rw global-attributes 202 +--rw qos-agreement 203 | +--rw max-latency? string 204 | +--rw min-bandwidth? string 205 | +--rw max-jitter? string 206 | +--rw max-packet-loss-probability? uint8 207 +--rw qos-monitored-result 208 | +--rw slice-level-latency? string 209 | +--rw slice-level-bandwidth? string 210 | +--rw slice-level-jitter? string 211 | +--rw slice-level-packet-loss-probability? uint8 212 +--rw topology-requirement 213 | +--rw node-list 214 | +--rw link-list 215 +--rw reliability-level? unit8 216 +--rw resource-reservation-level? unit8 217 +--rw availability? string 218 +--rw availability-threshold? string 219 +--rw access-control 220 +--rw match? string 221 +--rw action? string 222 +--rw priority? string 223 +--rw counter? int64 225 3.1. atomic-component 227 The atomic-component refers to the basic resources to construct a 228 network slice. According to the different capabilities provided, 229 atomic-component could be further divided into three cateogries: 231 o connectivity-cateogry: resources to provide connectivity, include 232 nodes and links. 234 o storage-cateogry: resources to provide storage, such as RAM, ROM, 235 etc. 237 o compute-categoty: resource to provide compute, such as CPU, GPU, 238 etc. 240 Different cateogries of atomic-components could exist independently, 241 they also can be bound together when necessary. For example, bind a 242 storage unit to a connectivity node. 244 3.1.1. connectivity-cateogry 246 3.1.1.1. node 248 For easy going, some attributes of node are explained as follows: 250 location: a string which indicates a geographical area, the node must 251 be mapped to the physical device(s) inside this indicated 252 geographical area. 254 forwarding policy: could be the routing table or flow table or other 255 information indicates the forwarding policy of this node. 257 port rate: the packet forwarding capability of a port for this node 258 in the unit of pps (packet per second). 260 packet-loss-probability: a statistical value which reflects the 261 probability of packet loss. 263 packet-loss-threshold: a threshold of the packet loss probability. 264 If the value of packet-loss-probability is larger than packet-loss- 265 threshold, should actively notify the management system. 267 received-packets: a statistical value which reflects the number of 268 received packets in a period of time. 270 sent-packets: a statistical value which reflects the number of sent 271 packets in a period of time. 273 3.1.1.2. link 275 Some attributes of link are explained as follows: 277 src-node: the source node the link. 279 src-port: the port of the source node. 281 dst-node: the destination node of the link. 283 dst-port: the port of the destination node. 285 link-bandwidth-agreement: specify the bandwidth requirement for this 286 link. If this parameter does not be set specifically, then the link 287 will be constructed according to the default bandwidth calculated by 288 algorithm. 290 link-throughput: the current throughput of this link. 292 link-throughput-threshold: a threshold for link throughput. If the 293 value of link-throughput is smaller than link-throughput-threshold, 294 should actively notify the management system. 296 link-latency-agreement: specify the latency requirement for this 297 link. If this parameter does not be set specifically, then the link 298 will be constructed according to the default latency calculated by 299 algorithm. 301 link-latency: the current latency of this link. 303 link-jitter-agreement: specify the jitter requirement for this link. 304 If this parameter does not be set specifically, then the link will be 305 constructed according to the default jitter calculated by algorithm. 307 link-jitter: the current jitter of this link. 309 link-jitter-threshold: a threshold for link jitter. If the value of 310 link-jitter is larger than link-jitter-threshold, should actively 311 notify the management system. 313 mandatory-physical-device*: a list of physical devices that must be 314 passed by the mapped physical path of this link. 316 exclusive-physical-device*: a list of physical devices that cannot be 317 passed by the mapped physical path of this link. 319 3.1.2. storage-cateogry 321 read-write-mode: there are three options include read only, write 322 only, and read & write. 324 access-mode: two options include shared or dedicated. 326 redundancy: bool value indicate wheter the storage unit has back-up 327 or not. 329 location: the location of the storage unite, could be used to bind to 330 a connectivity node. 332 3.1.3. compute-categoty 334 alu-number: the number of arithmetic logic unit 336 access-mode: two options include shared or dedicated. 338 location: the location of the storage unite, could be used to bind to 339 a connectivity node. 341 3.2. predefined-function-block 343 Some typical features could be packaged into function blocks in 344 advance, such as SDN controller, firewall, vSwitch, load balancer, 345 etc. 347 3.3. global-attributes 349 The global-attributes refers to a set of attributes in the whole 350 network slice level. Some explanations are provided as follows for 351 easy going: 353 qos-agreement: spcify some global QoS metrics of a whole network 354 slice. 356 qos-monitored-result: the monitored results of the global QoS 357 metrics. 359 topology-requirement: should be able to support a variety of topology 360 construction methods, such as: 1) given the complete topology 361 information (i.e., the whole nodes and links lists); 2) only given 362 some key information (e.g., edge nodes, converge nodes). 364 reliability-level: the ability of a network slice to be in a stable 365 state. In this document, the main method to achieve reliability is 366 "backup". If necessary, other methods also can be extended based on 367 the current definition. The detailed definition of Reliability_Level 368 is provided in Table 1. 370 resource-reservation-level: classify different resource reservation 371 levels of a network slice. This attribute is related to the slice 372 isolation but is not strictly bound. The detailed definition is 373 provided in Table 2. 375 availability: a statistical value which reflects the probability for 376 a network slice instance to work with expected SLA in a period of 377 time (e.g., 99.999% of time). 379 availability-threshold: a threshold of the availability. If the 380 value of Availability is smaller than Availability_Threshold, should 381 actively notify the management system. 383 access-control: llustrate each role can take what kind of operations 384 on the network slice. 386 +=======+=====================================+========================+ 387 | | | | 388 | Value | Explanation | Note | 389 | | | | 390 +=======+=====================================+========================+ 391 | | | | 392 | 0 | No specific reliability requirement | The lowest reliability | 393 | | | level | 394 +-------+-------------------------------------+------------------------+ 395 | | | | 396 | 1 | Each path has a backup path | Path reliability | 397 | | | | 398 +-------+-------------------------------------+------------------------+ 399 | | | | 400 | 2 | Each node/link has a backup node/ | Logical resource | 401 | | link | reliability | 402 +-------+-------------------------------------+------------------------+ 403 | | | | 404 | 3 | Each node/link has a backup node/ | Physical resource | 405 | | link, and the primary and backup | reliability | 406 | | nodes/links must be mapped to | | 407 | | different physical devices/paths | | 408 | | (the mapped two physical paths | | 409 | | couldn't have any shared device) | | 410 | | | | 411 +=======+=====================================+========================+ 413 Table 1: Explanation of reliability-level 415 +=======+=====================================+========================+ 416 | | | | 417 | Value | Explanation | Note | 418 | | | | 419 +=======+=====================================+========================+ 420 | | | | 421 | 0 | No specific resource reservation | The lowest resource | 422 | | requirement | reservation level, the | 423 | | | network slice instance | 424 | | | will share and compete | 425 | | | for resource with other| 426 | | | network slice instances| 427 | | | | 428 +-------+-------------------------------------+------------------------+ 429 | | | | 430 | 1 | A certain of resource reservation, | Shared and | 431 | | the free reserved resources could be| non-preemptive | 432 | | used by other slice instances, and | | 433 | | unable to be retrieved if other | | 434 | | slic instances are using them | | 435 | | | | 436 +-------+-------------------------------------+------------------------+ 437 | | | | 438 | 2 | More stringent resource reservation,| Shared and preemptive | 439 | | the free reserved resources could be| | 440 | | used by other slice instances, and | | 441 | | will be retrieved if the network | | 442 | | slice needs them | | 443 | | | | 444 +-------+-------------------------------------+------------------------+ 445 | | | | 446 | 3 | The reserved resources couldn't be | The highest resource | 447 | | used by other slice instances, even | reservation level, | 448 | | if these resources are free | exclusive | 449 | | | | 450 +=======+=====================================+========================+ 452 Table 2: Explanation of resource-reservation-level 454 4. Opeartions 456 The defined information model should be able to support the following 457 operations on network slices. Except for support the operations on a 458 complete network slice, each element insides a network slice also 459 should be able to be operated specifically. 461 o construct: construct a network slicee 462 o delete: delete a network slice 464 o modify: modify a constructed network slice 466 o set_element_value: set the value of an indicated element in a 467 network slice 469 o get_element_value: get the value of an indicated element in a 470 network slice 472 o monitor: monitor the status of a network slice 474 o enable_report: enable the active report to the subscribes/ 475 management system when the monitored status changes beyond 476 expectation 478 5. Security Considerations 480 TBD 482 6. IANA Considerations 484 There is no IANA action required by this document. 486 7. Acknowledgements 488 TBD 490 8. Informative References [TBD] 492 [COMS-PS] "NS Framework", . 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 Authors' Addresses 502 Li Qiang 503 Huawei 505 Email: qiangli3@huawei.com 506 Alex Galis 507 University College London 509 Email: a.galis@ucl.ac.uk 511 Liang Geng 512 China Mobile 514 Email: gengliang@chinamobile.com 516 Kiran Makhijani 517 Huawei 519 Email: Kiran.Makhijani@huawei.com 521 Pedro Martinez-Julia 522 NICT 524 Email: pedro@nict.go.jp 526 Hannu Flinck 527 Nokia 529 Email: hannu.flinck@nokia.com