idnits 2.17.1 draft-wd-teas-ietf-network-slice-nbi-yang-02.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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 320 has weird spacing: '...ch-type ide...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 21, 2021) is 1159 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6991' is defined on line 1502, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slice-definition (ref. 'I-D.ietf-teas-ietf-network-slice-definition') == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-ns-framework (ref. 'I-D.nsdt-teas-ns-framework') == Outdated reference: A later version (-05) exists of draft-geng-teas-network-slice-mapping-02 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-10 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-02 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Wu 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 25, 2021 L. Han 6 China Mobile 7 R. Rokui 8 Nokia 9 February 21, 2021 11 A Yang Data Model for IETF Network Slice NBI 12 draft-wd-teas-ietf-network-slice-nbi-yang-02 14 Abstract 16 This document provides a YANG data model for the IETF Network Slice 17 NBI (Northbound Interface). The model can be used by a higher level 18 system to request configuration, and management IETF Network Slices 19 from the IETF Network Slice Controller (NSC). 21 The YANG modules in this document conforms to the Network Management 22 Datastore Architecture (NMDA) defined in RFC 8342. 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 August 25, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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. Conventions used in this document . . . . . . . . . . . . . . 3 60 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 61 3. IETF Network Slice NBI Model Usage . . . . . . . . . . . . . 4 62 4. IETF Network Slice NBI Model Overview . . . . . . . . . . . . 5 63 5. IETF Network Slice Templates . . . . . . . . . . . . . . . . 8 64 6. IETF Network Slice Modeling Description . . . . . . . . . . . 9 65 6.1. IETF Network Slice Topology . . . . . . . . . . . . . . . 10 66 6.2. IETF Network Slice SLO Policy . . . . . . . . . . . . . . 10 67 6.3. IETF Network Slice Endpoint (NSE) . . . . . . . . . . . . 12 68 7. IETF Network Slice Monitoring . . . . . . . . . . . . . . . . 15 69 8. IETF Network Slice NBI Module . . . . . . . . . . . . . . . . 16 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 75 12.2. Informative References . . . . . . . . . . . . . . . . . 33 76 Appendix A. IETF Network Slice NBI Model Usage Example . . . . . 34 77 Appendix B. Comparison with Other Possible Design choices for 78 IETF Network Slice NBI . . . . . . . . . . . . . . . 36 79 B.1. ACTN VN Model Augmentation . . . . . . . . . . . . . . . 37 80 B.2. RFC8345 Augmentation Model . . . . . . . . . . . . . . . 37 81 Appendix C. Appendix B IETF Network Slice Match Criteria . . . . 38 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 84 1. Introduction 86 This document provides a YANG [RFC7950] data model for the IETF 87 Network Slice NBI. 89 The YANG model discussed in this document is defined based on the 90 description of the IETF Network Slice in 91 [I-D.ietf-teas-ietf-network-slice-definition] and 92 [I-D.nsdt-teas-ns-framework], which is used to operate IETF Network 93 Slice during the IETF Network Slice instantiation. This YANG model 94 supports various oprations on IETF Network Slices such as creation, 95 modification, deletion, and monitoring of IETF Network Slices. 97 The IETF Network Slice Controller (NSC) provides a Northbound 98 Interface (NBI) that allows consumers of network slices to request 99 and monitor IETF network slices. Consumers operate on abstract IETF 100 network slices, with details related to their realization hidden. 102 The NSC takes requests from a management system or other application 103 via an NBI. This interface carries data objects the IETF network 104 slice user provides, describing the needed IETF network slices in 105 terms of topology, applicable service level objectives (SLO), and any 106 monitoring and reporting requirements that may apply. The NBI 107 conveys the generic IETF network slice requirements. These may then 108 be realized using an SBI within the NSC. 110 The YANG model discussed in this document describes the requirements 111 of an IETF Network Slice from the point of view of the consumer, 112 which is classified as Customer Service Model in [RFC8309]. 114 It will be up to the management system or NSC (IETF Network Slice 115 controller) to take this model as an input and use other management 116 system or specific configuration models to configure the different 117 network elements to deliver an IETF Network Slice. The YANG models 118 can be used with network management protocols such as NETCONF 119 [RFC6241] or RESTCONF [RFC8040]. The details of how the IETF network 120 slices are realized by the NSC is out of scope for this document. 122 The IETF Network Slice operational state is included in the same tree 123 as the configuration consistent with Network Management Datastore 124 Architecture [RFC8342]. 126 2. Conventions used in this document 128 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 The following terms are defined in [RFC6241] and are used in this 135 specification: 137 o client 139 o configuration data 141 o state data 143 This document makes use of the following terminology introduced in 144 the YANG 1.1 Data Modeling Language [RFC7950]: 146 o augment 148 o data model 150 o data node 152 This document also makes use of the following terminology introduced 153 in the IETF Network Slice definition draft 154 [I-D.ietf-teas-ietf-network-slice-definition]: 156 o NBI: Northbound Interface 158 o NS: IETF Network Slice 160 o NSC: IETF Network Slice Controller 162 o NSE: Network Slice Endpoint 164 o SLO: Service Level Objective 166 This document defines the following new terminology: 168 o IETF Network Slice Member (Network-Slice-Member): In the context 169 of an IETF Network Slice, an IETF Network-Slice-Member is an 170 abstract entity which represents a particular connection between a 171 pair of NSEs. An IETF Network Slice can has one or multiple 172 members. 174 2.1. Tree Diagrams 176 Tree diagrams used in this document follow the notation defined in 177 [RFC8340]. 179 3. IETF Network Slice NBI Model Usage 181 The intention of the IETF Network Slice NBI model is to allow the 182 consumer, e.g. a higher level management system, to request and 183 monitor IETF Network Slices. In particular, the model allows 184 consumers to operate in an abstract, technology-agnostic manner, with 185 realization details hidden. 187 According to the [I-D.ietf-teas-ietf-network-slice-definition] 188 description, the NBI model is applicable to use case such as (but not 189 limited to) Network wholesale services, Network infrastructure 190 sharing among operators, NFV connectivity and Data Center 191 Interconnect and 5G E2E network slice. 193 As Figure 1 shows, in all these use-cases, the NBI model is used by 194 the higher management system (i.e the consumer of the IETF network 195 slice controller ) to communicate with IETF Network Slice controller 196 for life cycle manage of IETF Network Slices including both 197 enablement and monitoring. For example, in 5G E2E network slicing 198 use-case the E2E network slice orchestrator acts as the higher layer 199 system to request the IETF Network Slices. The interface is used to 200 support dynamic IETF Network Slice creation and its lifecycle 201 management to facilitate end-to-end network slice services. 203 +----------------------------------------+ 204 | IETF Network Slice Consumer | 205 | | 206 +----------------+-----------------------+ 207 | 208 | 209 |IETF Network Slice NBI YANG 210 | 211 +---------------------+--------------------------+ 212 | IETF Network Slice Controller (NSC) | 213 +------------------------------------------------+ 215 Figure 1: IETF Network Slice NBI Model Context 217 4. IETF Network Slice NBI Model Overview 219 As defined in [I-D.ietf-teas-ietf-network-slice-definition], an IETF 220 network slice is a logical network connecting a number of endpoints 221 with specified SLOs. The connectivity can be point-to-point, 222 multipoint-to-point, point-to-multipoint or multipoint-to-multipoint. 223 In addition, a minimum set of SLOs is defined, including but not 224 limited to bandwidth, delay, and etc. An example of an IETF network 225 slice is shown in Figure 2 . 227 +----------------------------------------------+ 228 | | 229 NSE1 O------------------+ | 230 . +---------------------------O NSE2 231 . | . 232 . |multipoint-to-multipoint . 233 | 234 +---------------------------O NSEn 235 NSEm O------------------+ | 236 | | 237 +----------------------------------------------+ 239 | | 240 |<-----------An IETF Network Slice ---------->| 241 | between endpoints NSE1 to NSEn | 243 Legend: 244 NSE: IETF Network Slice Endpoint 245 O: Represents IETF Network Slice Endpoints 247 Figure 2: An IETF Network Slice Example 249 Draft [I-D.ietf-teas-ietf-network-slice-definition] introduces the 250 IETF network slice endpoints (NSEs) which are conceptual points of 251 connection to IETF network slice. As such, they are ingress/egress 252 point where the traffic enters/exits the IETF network slice. In 253 other words, they are the edge of the IETF network slices. 255 When IETF network slice controller (NSC) receives a message via its 256 NBI for creation/modification of an IETF network slice, it uses the 257 provided IETF network slice endpoints to map them to appropriate 258 services/tunnels/paths endpoints in the underlay IETF network. It 259 then uses services/tunnels/paths endpoints to realize the IETF 260 network slice. 262 The IETF Network Slice ("ietf-network-slice") is defined to manage 263 network slices in the IETF network. In particular, the 'ietf- 264 network-slice' module can be used to create, modify, and monitor 265 network slices of an IETF network. 267 The 'ietf-network-slice' module uses two main nodes: list 'ietf- 268 network-slice' and container 'ns-templates' (see Figure 3). 270 The 'ietf-network-slice' list includes the set of IETF Network slices 271 managed within IETF network. 'ietf-network-slice' is the data 272 structure that abstracts an IETF Network Slice. Under the "ietf- 273 network-slice", list "ns-endpoint" is used to abstract the NSEs, e.g. 274 NSEs in the example above. 276 The 'ns-templates' container is used by the NSC to maintain a set of 277 common network slice templates that apply to one or several IETF 278 Network Slices. 280 The figure below describes the overall structure of the YANG module: 282 module: ietf-network-slice 283 +--rw ietf-network-slices 284 +--rw ns-templates 285 | +--rw slo-template* [id] 286 | +--rw id string 287 | +--rw template-description? string 288 +--rw ietf-network-slice* [ns-id] 289 +--rw ns-id string 290 +--rw ns-description? string 291 +--rw ns-tag* string 292 +--rw ns-topology? identityref 293 +--rw (ns-slo-policy)? 294 | +--:(standard) 295 | | +--rw slo-template? leafref 296 | +--:(custom) 297 | +--rw slo-policy 298 | +--rw policy-description? string 299 | +--rw ns-metric-bounds 300 | +--rw ns-metric-bound* [metric-type] 301 | +--rw metric-type identityref 302 | +--rw metric-unit string 303 | +--rw value-description? string 304 | +--rw boundary? uint64 305 +--rw status 306 | +--rw admin-enabled? boolean 307 | +--ro oper-status? operational-type 308 +--rw ns-endpoint* [ep-id] 309 | +--rw ep-id string 310 | +--rw ep-description? string 311 | +--rw ep-role? identityref 312 | +--rw location 313 | | +--rw altitude? int64 314 | | +--rw latitude? decimal64 315 | | +--rw longitude? decimal64 316 | +--rw node-id? string 317 | +--rw ep-ip? inet:host 318 | +--rw ns-match-criteria 319 | | +--rw ns-match-criteria* [match-type] 320 | | +--rw match-type identityref 321 | | +--rw value? string 322 | +--rw ep-network-access* [network-access-id] 323 | | +--rw network-access-id string 324 | | +--rw network-access-description? string 325 | | +--rw network-access-node-id? string 326 | | +--rw network-access-tp-id? string 327 | | +--rw network-access-tp-ip? inet:host 328 | +--rw ep-rate-limit 329 | | +--rw incoming-throughput 330 | | | +--rw maximum-throughput? te-types:te-bandwidth 331 | | +--rw outgoing-throughput 332 | | +--rw maximum-throughput? te-types:te-bandwidth 333 | +--rw ep-protocol 334 | +--rw status 335 | | +--rw admin-enabled? boolean 336 | | +--ro oper-status? operational-type 337 | +--ro ep-monitoring 338 | +--ro incoming-utilized-bandwidth? 339 | | te-types:te-bandwidth 340 | +--ro incoming-bw-utilization decimal64 341 | +--ro outgoing-utilized-bandwidth? 342 | | te-types:te-bandwidth 343 | +--ro outgoing-bw-utilization decimal64 344 +--rw ns-member* [ns-member-id] 345 +--rw ns-member-id uint32 346 +--rw ns-member-description? string 347 +--rw src 348 | +--rw src-ep-id? leafref 349 +--rw dest 350 | +--rw dest-ep-id? leafref 351 +--rw monitoring-type? ns-monitoring-type 352 +--ro ns-member-monitoring 353 +--ro latency? yang:gauge64 354 +--ro jitter? yang:gauge32 355 +--ro loss-ratio? decimal64 357 Figure 3 359 5. IETF Network Slice Templates 361 The 'ns-templates' container (Figure 3) is used by service provider 362 of the NSC to define and maintain a set of common IETF Network Slice 363 templates that apply to one or several IETF Network Slices. The 364 exact definition of the templates is deployment specific to each 365 network provider. The model includes only the identifiers of SLO- 366 templates. When creation of IETF Network slice, the SLO policies can 367 be easily identified. 369 The following shows an example where two network slice templates can 370 be retrieved by the upper layer management system: 372 { 373 "ietf-network-slices": { 374 "ns-templates": { 375 "slo-template": [ 376 { 377 "id":"GOLD-template", 378 "template-description": "Bandwidth: 1 Gbps, delay 100ms " 379 }, 380 { 381 "id":"PLATINUM-template", 382 "template-description": "Bandwidth: 1 Gbps, delay 50ms " 383 }, 384 ], 385 } 386 } 387 } 389 6. IETF Network Slice Modeling Description 391 The 'ietf-network-slice' is the data structure that abstracts an IETF 392 Network Slice of the IETF network. Each 'ietf-network-slice' is 393 uniquely identified by an identifier: 'ns-id'. 395 An IETF Network Slice has the following main parameters: 397 o "ns-id": Is an identifier that is used to uniquely identify the 398 IETF Network Slice within NSC. 400 o "ns-description": May be provided to help identify an IETF Network 401 Slice. 403 o "ns-topology": Indicates the network topology for the IETF Network 404 Slice: Hub-Spoke, Any-to-Any, and Custom. 406 o "status": Enable the control of the operative and administrative 407 status of the IETF Network Slice, can be used as indicator to 408 detect network slice anomalies. 410 o "ns-tag": The list is to show the correlation between higher level 411 function and the IETF network slices. If provided, this parameter 412 may be used by IETF Network Slice Controller (NSC) during the 413 realization. It may also be used by NSC for monitoring and 414 assurance of the IETF network slices where NSC can notify the 415 higher system by issuing the notifications. It is noted that a 416 single higher level consumer might have multiple IETF Network 417 Slices for a single application. This attribute may be used by 418 NSC to also correlated multiple IETF network slices for a single 419 application. 421 o "ns-slo-policy": Defines SLO policy for the "ietf-network-slice". 422 More description are provided in Section 6.1 424 The "ns-endpoint" is an abstrac entity that represents a set of 425 matching rules applied to an IETF network edge device or a customer 426 network edge device involved in the IETF Network Slice and each 'ns- 427 endpoint' belongs to a single 'ietf-network-slice'. More description 428 are provided in Section 6.3 430 6.1. IETF Network Slice Topology 432 An IETF Network Slice can be point-to-point (P2P), point-to- 433 multipoint (P2MP), multipoint-to-point (MP2P), or multipoint-to- 434 multipoint (MP2MP) based on the consumer's traffic pattern 435 requirements. 437 Therefore, the "ns-topology" under the node "ietf-network-slice" is 438 required for configuration. The model supports any-to-any, Hub and 439 Spoke (where Hubs can exchange traffic), and the different 440 combinations. New topologies could be added via augmentation. By 441 default, the any-to-any topology is used. 443 In addition, "ep-role" under the node "ns-endpoint" also needs to be 444 defined, which specifies the role of the NSE in a particular Network 445 Slice topology. In the any-to-any topology, all NSEs MUST have the 446 same role, which will be "any-to-any-role". In the Hub-and-Spoke 447 topology, NSEs MUST have a Hub role or a Spoke role. 449 6.2. IETF Network Slice SLO Policy 451 As defined in [I-D.ietf-teas-ietf-network-slice-definition], the SLO 452 policy of an IETF Network Slice defines the minimum IETF Network 453 Slice SLO attributes, and additional attributes can be added as 454 needed. 456 "ns-slo-policy" is used to represent a specific SLO policy. During 457 the creation of an IETF Network Slice, the policy can be specified 458 either by a standard SLO template or a customized SLO policy. 460 The model allows multiple SLO attributes to be combined to meet 461 different SLO requirements. For example, some NSs are used for video 462 services and require high bandwidth, some NSs are used for key 463 business services and request low latency and reliability, and some 464 NSs need to provide connections for a large number of NSEs. That is, 465 not all SLO attributes must be specified to meet the particular 466 requirements of a slice. 468 "ns-metric-bounds" contains all these variations, which includes a 469 list of "ns-metric-bound" and each "ns-metric-bound" could specify a 470 particular "metric-type". "metric-type" is defined with YANG identity 471 and the YANG module supports the following options: 473 "network-slice-slo-bandwidth": Indicates the guaranteed minimum 474 bandwidth between any two NSE. The unit is data rate per second. 475 And the bandwidth is unidirectional. 477 "network-slice-slo-one-way-delay": Indicates the maximum one-way 478 latency between two NSE. The unit is micro seconds. 480 "network-slice-slo-two-way-delay": Indicates the maximum round 481 trip latency between two NSE. The unit is micro seconds. 483 "network-slice-slo-jitter": Indicates the jitter constraint of the 484 slice maximum permissible delay variation, and is measured by the 485 difference in the one- way delay between sequential packets in a 486 flow. 488 "network-slice-slo-loss": Indicates maximum permissible packet 489 loss rate, which is defined by the ratio of packets dropped to 490 packets transmitted between two endpoints. 492 "network-slice-slo-availability": Is defined as the ratio of up- 493 time to total_time(up-time+down-time), where up-time is the time 494 the IETF Network Slice is available in accordance with the SLOs 495 associated with it. 497 Some other Network Slice objectives, such as MTU and security which 498 can be added when needed. MTU specifies the maximum packet length 499 that the network slice guarantee to be able to carry across. 501 Note: About the definition of SLO parameters, the author is 502 discussing to reuse the TE-Types grouping definition as much as 503 possible, to avoid duplication of definitions. 505 The following shows an example where a network slice policy can be 506 configured: 508 { 509 "ietf-network-slices": { 510 "ietf-network-slice": { 511 "slo-policy": { 512 "policy-description":"video-service-policy", 513 "ns-metric-bounds": { 514 "ns-metric-bound": [ 515 { 516 "metric-type": "network-slice-slo-bandwidth", 517 "metric-unit": "mbps" 518 "boundary": "1000" 519 }, 520 { 521 "metric-type": "network-slice-slo-availability", 522 "boundary": "99.9%" 523 }, 524 ], 525 } 526 } 527 } 528 } 529 } 531 6.3. IETF Network Slice Endpoint (NSE) 533 An IETF Network Slice Endpoint has several characteristics: 535 o "ep-id": Uniquely identifies the NSE within Network Slice 536 Controller (NSC). The identifier is a string that allows any 537 encoding for the local administration of the IETF Network Slice. 539 o "location": is NSE location information that facilities NSC easy 540 identification of a NSE. 542 o "ep-role": Is a topology role of a NSE belonging to an IETF 543 network slice, as described in Section 6.1. The "ep-role" leaf 544 defines the role of the endpoint in a particular NS topology. In 545 the NS any-to-any topology, all NSEs MUST have the same role, 546 which will be "any-to-any-role". 548 o "node-id": is NSE node information that facilities NSC easy 549 identification of a NSE. 551 o "ep-ip": is NSE IP information that facilities NSC easy 552 identification of a NSE. 554 o "ns-match-criteria": Is used to define matching policies to apply 555 on a given NSE. 557 o "ep-network-access": Is the list that includes the interfaces 558 attached to an edge device of the IETF Network Slice by which the 559 customer traffic is received. 561 o "ep-rate-limit": Is to set rate-limiting policies to apply on a 562 given NSE, including ingress and egress traffic to ensure access 563 security. When applied in the incoming direction, the rate-limit 564 is applicable to the traffic from the NSE to the IETF scope 565 Network that passes through the external interface. When 566 Bandwidth is applied to the outgoing direction, it is applied to 567 the traffic from the IETF Network to the NSE of that particular 568 NS. 570 o "ep-protocol": Specify the protocol for a NSE for exchanging 571 control-plane information, e.g. L1 signaling protocol or L3 572 routing protocols,etc. 574 o "status": Enable the control of the operative and administrative 575 status of the NSE, can be used as indicator to detect NSE 576 anomalies. 578 An NSE belong to a single IETF Network Slice. An IETF Network Slice 579 involves two or more NSEs. An IETF Network Slice can be modified by 580 adding new "ns-endpoint" or removing existing "ns-endpoint". 582 A NSE is used to define the matching rule on the customer traffic 583 that can be injected to an IETF Network Slice. "network-slice-match- 584 criteria" is defined to support different options. Classification 585 can be based on many criteria, such as: 587 o Physical interface: Indicates all the traffic received from the 588 interface belongs to the IETF Network Slice. 590 o Logical interface: For example, a given VLAN ID is used to 591 identify an IETF Network Slice. 593 o Encapsulation in the traffic header: For example, a source IP 594 address is used to identify an IETF Network Slice. 596 To illustrate the use of NSE parameters, the below are two examples. 597 How the NSC realize the mapping is out of scope for this document. 599 o NSE mapping to PE example: As shown in Figure 4 , consumer of the 600 IETF network slice would like to connect two NSEs to satisfy 601 specific service, e.g., Network wholesale services. In this case, 602 the IETF network slice endpoints are mapped to physical interfaces 603 of PE nodes. The IETF network slice controller (NSC) uses "node- 604 id" (PE device ID), "ep-network-access" (Two PE interfaces ) to 605 map the interfaces and corresponding services/tunnels/paths. 607 NSE1 NSE2 608 (With PE1 parameters) (with PE2 parameters) 609 o<--------- IETF Network Slice 1 ------->o 610 + | | + 611 + |<----------- S1 ----------->| + 612 + | | + 613 + | |<------ T1 ------>| | + 614 + v v v v + 615 + +----+ +----+ + 616 +-----+ | | PE1|==================| PE2| +-----+ 617 | |----------X | | | | | | 618 | | | | | | X----------| | 619 | |----------X | | | | | | 620 +-----+ | | |==================| | | +-----+ 621 AC +----+ +----+ AC 622 Customer Provider Provider Customer 623 Edge 1 Edge 1 Edge 2 Edge 2 625 Legend: 626 O: Representation of the IETF network slice endpoints (NSE) 627 +: Mapping of NES to PE or CE nodes on IETF network 628 X: Physical interfaces used for realization of IETF network slice 629 S1: L0/L1/L2/L3 services used for realization of IETF network slice 630 T1: Tunnels used for realization of IETF network slice 632 Figure 4 634 o NSE mapping to CE example: As shown in Figure 5 , consumer of the 635 IETF network slice would like to connect two NSEs to provide 636 connectivity between transport portion of 5G RAN to 5G Core 637 network functions. In this scenario, the IETF network slice 638 endpoints (NSE) might be mapped to tunnels endpoints on CE nodes 639 (see 3GPP TS 28.541 V17.1.0 section 6.3.17 EP_Transport). The 640 IETF network slice controller (NSC) uses "node-id" (CE device ID) 641 , "ep-ip" (CE tunnel endpoint IP), "network-slice-match-criteria" 642 (VLAN interface), "ep-network-access" (Two nexthop interfaces ) to 643 map underlay services/tunnels/paths. 645 NSE3 NSE4 646 (With CE1 parameters) (with CE2 parameters) 647 o<--------- IETF Network Slice 2 ------->o 648 + | | + 649 + |<----------- S2 ----------->| + 650 + | | + 651 + | |<------ T2 ------>| | + 652 + v v v v + 653 + AC +----+ +----+ + 654 +-----+ | | PE1|==================| PE2| +-----+ 655 | |----------X | | | | | | 656 | | | | | | X----------| | 657 | |----------X | | | | | | 658 +-----+ | | |==================| | | +-----+ 659 AC +----+ +----+ AC 660 Customer Provider Provider Customer 661 Edge 1 Edge 1 Edge 2 Edge 2 663 Legend: 664 O: Representation of the IETF network slice endpoints (NSE) 665 +: Mapping of NES to PE or CE nodes on IETF network 666 X: Physical interfaces used for realization of IETF network slice 667 S2: L0/L1/L2/L3 services used for realization of IETF network slice 668 T2: Tunnels used for realization of IETF network slice 670 Figure 5 672 7. IETF Network Slice Monitoring 674 An IETF Network Slice is a connectivity with specific SLO 675 characteristics, including bandwidth, QoS metric, etc. The 676 connectivity is a combination of logical connections, represented by 677 Network-Slice-Members. 679 This model also describes performance status of an IETF Network 680 Slice. The statistics are described in the following granularity: 682 o Per NS connection: specified in 'network-slice-member-monitoring' 683 under the "network-slice-member" 685 o Per NS Endpoint: specified in 'endpoint-monitoring' under the 686 "network-slice-endpoint" 688 This model does not define monitoring enabling methods. The 689 mechanism defined in [RFC8640] and [RFC8641] can be used for either 690 periodic or on-demand subscription. 692 By specifying subtree filters or xpath filters to 'ns-member' or 'ns- 693 endpoint' ,so that only interested contents will be sent. These 694 mechanisms can be used for monitoring the IETF Network Slice 695 performance status so that the client management system could 696 initiate modification based on the IETF Network Slice running status. 698 8. IETF Network Slice NBI Module 700 file "ietf-network-slice@2021-02-19.yang" 701 module ietf-network-slice { 702 yang-version 1.1; 703 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 704 prefix ietf-ns; 706 import ietf-inet-types { 707 prefix inet; 708 } 709 import ietf-yang-types { 710 prefix yang; 711 reference 712 "RFC 6991: Common YANG Types."; 713 } 714 import ietf-te-types { 715 prefix te-types; 716 } 718 organization 719 "IETF Traffic Engineering Architecture and Signaling (TEAS) 720 Working Group"; 721 contact 722 "WG Web: 723 WG List: 724 Editor: Bo Wu 725 : Dhruv Dhody "; 726 description 727 "This module contains a YANG module for the IETF Network Slice. 729 Copyright (c) 2021 IETF Trust and the persons identified as 730 authors of the code. All rights reserved. 732 Redistribution and use in source and binary forms, with or 733 without modification, is permitted pursuant to, and subject to 734 the license terms contained in, the Simplified BSD License set 735 forth in Section 4.c of the IETF Trust's Legal Provisions 736 Relating to IETF Documents 737 (http://trustee.ietf.org/license-info). 739 This version of this YANG module is part of RFC XXXX; see the 740 RFC itself for full legal notices."; 742 revision 2021-02-19 { 743 description 744 "initial version."; 745 reference 746 "RFC XXXX: A Yang Data Model for IETF Network Slice Operation"; 747 } 749 /* Features */ 750 /* Identities */ 752 identity network-slice-topology { 753 description 754 "Base identity for IETF Network Slice topology."; 755 } 757 identity any-to-any { 758 base network-slice-topology; 759 description 760 "Identity for any-to-any IETF Network Slice topology."; 761 } 763 identity hub-spoke { 764 base network-slice-topology; 765 description 766 "Identity for Hub-and-Spoke IETF Network Slice topology."; 767 } 769 identity custom { 770 base network-slice-topology; 771 description 772 "Identity of a custom NS topology where Hubs 773 can act as Spoke for certain parts of 774 the network or Spokes as Hubs."; 775 } 777 identity endpoint-role { 778 description 779 "Base identity of a NSE role in an IETF Network Slice topology."; 780 } 782 identity any-to-any-role { 783 base endpoint-role; 784 description 785 "Identity of any-to-any NS."; 786 } 787 identity spoke-role { 788 base endpoint-role; 789 description 790 "A NSE is acting as a Spoke."; 791 } 793 identity hub-role { 794 base endpoint-role; 795 description 796 "A NSE is acting as a Hub."; 797 } 799 identity custom-role { 800 base endpoint-role; 801 description 802 "A NSE is custom role in the NS."; 803 } 805 identity network-slice-slo-metric-type { 806 description 807 "Base identity for Network Slice SLO metric type"; 808 } 810 identity network-slice-slo-two-way-delay { 811 base network-slice-slo-metric-type; 812 description 813 "SLO delay metric."; 814 } 816 identity network-slice-slo-one-way-delay { 817 base network-slice-slo-metric-type; 818 description 819 "SLO delay metric."; 820 } 822 identity network-slice-slo-jitter { 823 base network-slice-slo-metric-type; 824 description 825 "SLO jitter metric."; 826 } 828 identity network-slice-slo-loss { 829 base network-slice-slo-metric-type; 830 description 831 "SLO loss metric ."; 832 } 834 identity network-slice-slo-availability { 835 base network-slice-slo-metric-type; 836 description 837 "SLO availability level."; 838 } 840 identity network-slice-slo-bandwidth { 841 base network-slice-slo-metric-type; 842 description 843 "SLO bandwidth metric."; 844 } 846 identity network-slice-match-type { 847 description 848 "Base identity for Network Slice traffic match type"; 849 } 851 identity network-slice-phy-interface-match { 852 base network-slice-match-type; 853 description 854 "VLAN as Network Slice traffic match criteria."; 855 } 857 identity network-slice-vlan-match { 858 base network-slice-match-type; 859 description 860 "VLAN as Network Slice traffic match criteria."; 861 } 863 identity network-slice-label-match { 864 base network-slice-match-type; 865 description 866 "Label as Network Slice traffic match criteria."; 867 } 869 /* 870 * Identity for availability-type 871 */ 873 identity availability-type { 874 description 875 "Base identity from which specific availability 876 types are derived."; 877 } 879 identity level-1 { 880 base availability-type; 881 description 882 "level 1: 99.9999%"; 884 } 886 identity level-2 { 887 base availability-type; 888 description 889 "level 2: 99.999%"; 890 } 892 identity level-3 { 893 base availability-type; 894 description 895 "level 3: 99.99%"; 896 } 898 identity level-4 { 899 base availability-type; 900 description 901 "level 4: 99.9%"; 902 } 904 identity level-5 { 905 base availability-type; 906 description 907 "level 5: 99%"; 908 } 910 /* typedef */ 912 typedef operational-type { 913 type enumeration { 914 enum up { 915 value 0; 916 description 917 "Operational status UP."; 918 } 919 enum down { 920 value 1; 921 description 922 "Operational status DOWN"; 923 } 924 enum unknown { 925 value 2; 926 description 927 "Operational status UNKNOWN"; 928 } 929 } 930 description 931 "This is a read-only attribute used to determine the 932 status of a particular element"; 933 } 935 typedef ns-monitoring-type { 936 type enumeration { 937 enum one-way { 938 description 939 "represents one-way monitoring type"; 940 } 941 enum two-way { 942 description 943 "represents two-way monitoring type"; 944 } 945 } 946 description 947 "enumerated type of monitoring on a network-slice-member "; 948 } 950 /* Groupings */ 952 grouping status-params { 953 description 954 "Grouping used to join operational and administrative status"; 955 container status { 956 description 957 "Container for status of administration and operational"; 958 leaf admin-enabled { 959 type boolean; 960 description 961 "Administrative Status UP/DOWN"; 962 } 963 leaf oper-status { 964 type operational-type; 965 config false; 966 description 967 "Operations status"; 968 } 969 } 970 } 972 grouping network-slice-match-criteria { 973 description 974 "Grouping for Network Slice match definition."; 975 container ns-match-criteria { 976 description 977 "Describes Network Slice match criteria."; 978 list ns-match-criteria { 979 key "match-type"; 980 description 981 "List of Network Slice traffic criteria"; 982 leaf match-type { 983 type identityref { 984 base network-slice-match-type; 985 } 986 description 987 "Identifies an entry in the list of match-type for 988 the Network Slice."; 989 } 990 leaf value { 991 type string; 992 description 993 "Describes Network Slice match criteria,e.g. IP address, 994 VLAN, etc."; 995 } 996 } 997 } 998 } 1000 grouping network-slice-metric-bounds { 1001 description 1002 "Network Slice metric bounds grouping"; 1003 container ns-metric-bounds { 1004 description 1005 "Network Slice metric bounds container"; 1006 list ns-metric-bound { 1007 key "metric-type"; 1008 description 1009 "List of Network Slice metric bounds"; 1010 leaf metric-type { 1011 type identityref { 1012 base network-slice-slo-metric-type; 1013 } 1014 description 1015 "Identifies an entry in the list of metric-types 1016 bound for the Network Slice."; 1017 } 1018 leaf metric-unit { 1019 type string; 1020 mandatory true; 1021 description 1022 "The metric unit of the parameter. 1023 For example, s, ms, ns, and so on."; 1024 } 1025 leaf value-description { 1026 type string; 1027 description 1028 "The description of previous value. "; 1029 } 1030 leaf boundary { 1031 type uint64; 1032 default "0"; 1033 description 1034 "Boundary on network-slice-member metric. A zero indicate 1035 an unbounded upper limit for the specific metric-type"; 1036 } 1037 } 1038 } 1039 } 1041 grouping ep-network-accesses { 1042 description 1043 "Grouping for endpoint network access definition."; 1044 list ep-network-access { 1045 key "network-access-id"; 1046 description 1047 "IETF Network Slice endpoint network access related parameters"; 1048 leaf network-access-id { 1049 type string; 1050 description 1051 "unique identifier for the referred endpoint network access"; 1052 } 1053 leaf network-access-description { 1054 type string; 1055 description 1056 "endpoint network access description"; 1057 } 1058 leaf network-access-node-id { 1059 type string; 1060 description 1061 "EP network access node ID in the case of multi-homing."; 1062 } 1063 leaf network-access-tp-id { 1064 type string; 1065 description 1066 "EP network access termination port ID."; 1067 } 1068 leaf network-access-tp-ip { 1069 type inet:host; 1070 description 1071 "The IP address of EP network access."; 1072 } 1073 } 1074 } 1075 grouping endpoint-monitoring-parameters { 1076 description 1077 "Grouping for endpoint-monitoring-parameters."; 1078 container ep-monitoring { 1079 config false; 1080 description 1081 "Container for endpoint-monitoring-parameters."; 1082 leaf incoming-utilized-bandwidth { 1083 type te-types:te-bandwidth; 1084 description 1085 "Bandwidth utilization that represents the actual 1086 utilization of the incoming endpoint."; 1087 } 1088 leaf incoming-bw-utilization { 1089 type decimal64 { 1090 fraction-digits 5; 1091 range "0..100"; 1092 } 1093 units "percent"; 1094 mandatory true; 1095 description 1096 "To be used to define the bandwidth utilization 1097 as a percentage of the available bandwidth."; 1098 } 1099 leaf outgoing-utilized-bandwidth { 1100 type te-types:te-bandwidth; 1101 description 1102 "Bandwidth utilization that represents the actual 1103 utilization of the incoming endpoint."; 1104 } 1105 leaf outgoing-bw-utilization { 1106 type decimal64 { 1107 fraction-digits 5; 1108 range "0..100"; 1109 } 1110 units "percent"; 1111 mandatory true; 1112 description 1113 "To be used to define the bandwidth utilization 1114 as a percentage of the available bandwidth."; 1115 } 1116 } 1117 } 1119 grouping common-monitoring-parameters { 1120 description 1121 "Grouping for link-monitoring-parameters."; 1122 leaf latency { 1123 type yang:gauge64; 1124 units "usec"; 1125 description 1126 "The latency statistics per Network Slice member. 1127 [RFC2681] and [RFC7679] discuss round trip times and one-way 1128 metrics, respectively"; 1129 } 1130 leaf jitter { 1131 type yang:gauge32; 1132 description 1133 "The jitter statistics per Network Slice member 1134 as defined by [RFC3393]."; 1135 } 1136 leaf loss-ratio { 1137 type decimal64 { 1138 fraction-digits 6; 1139 range "0 .. 50.331642"; 1140 } 1141 description 1142 "Packet loss as a percentage of the total traffic 1143 sent over a configurable interval. The finest precision is 1144 0.000003%. where the maximum 50.331642%."; 1145 reference 1146 "RFC 7810, section-4.4"; 1147 } 1148 } 1150 grouping geolocation-container { 1151 description 1152 "A grouping containing a GPS location."; 1153 container location { 1154 description 1155 "A container containing a GPS location."; 1156 leaf altitude { 1157 type int64; 1158 units "millimeter"; 1159 description 1160 "Distance above the sea level."; 1161 } 1162 leaf latitude { 1163 type decimal64 { 1164 fraction-digits 8; 1165 range "-90..90"; 1166 } 1167 description 1168 "Relative position north or south on the Earth's surface."; 1169 } 1170 leaf longitude { 1171 type decimal64 { 1172 fraction-digits 8; 1173 range "-180..180"; 1174 } 1175 description 1176 "Angular distance east or west on the Earth's surface."; 1177 } 1178 } 1179 // gps-location 1180 } 1182 // geolocation-container 1184 grouping endpoint { 1185 description 1186 "IETF Network Slice endpoint related information"; 1187 leaf ep-id { 1188 type string; 1189 description 1190 "unique identifier for the referred IETF Network 1191 Slice endpoint"; 1192 } 1193 leaf ep-description { 1194 type string; 1195 description 1196 "endpoint name"; 1197 } 1198 leaf ep-role { 1199 type identityref { 1200 base endpoint-role; 1201 } 1202 default "any-to-any-role"; 1203 description 1204 "Role of the endpoint in the IETF Network Slice."; 1205 } 1206 uses geolocation-container; 1207 leaf node-id { 1208 type string; 1209 description 1210 "Uniquely identifies an edge node within the IETF slice 1211 network."; 1212 } 1213 leaf ep-ip { 1214 type inet:host; 1215 description 1216 "The address of the endpoint IP address."; 1217 } 1218 uses network-slice-match-criteria; 1219 uses ep-network-accesses; 1220 container ep-rate-limit { 1221 description 1222 "Container for the asymmetric traffic control"; 1223 container incoming-throughput { 1224 description 1225 "Container for the incoming traffic policy"; 1226 leaf maximum-throughput { 1227 type te-types:te-bandwidth; 1228 description 1229 "If maximum-throughput is 0, it means best effort, no 1230 minimum throughput is guaranteed."; 1231 } 1232 } 1233 container outgoing-throughput { 1234 description 1235 "Container for the bandwidth policy"; 1236 leaf maximum-throughput { 1237 type te-types:te-bandwidth; 1238 description 1239 "If maximum-throughput is 0, it means best effort, no 1240 minimum throughput is guaranteed."; 1241 } 1242 } 1243 } 1244 container ep-protocol { 1245 description 1246 "Describes protocol for the Network Slice Endpoint."; 1247 } 1248 uses status-params; 1249 uses endpoint-monitoring-parameters; 1250 } 1252 //network-slice-endpoint 1254 grouping network-slice-member { 1255 description 1256 "network-slice-member is described by this container"; 1257 leaf ns-member-id { 1258 type uint32; 1259 description 1260 "network-slice-member identifier"; 1261 } 1262 leaf ns-member-description { 1263 type string; 1264 description 1265 "network-slice-member description"; 1266 } 1267 container src { 1268 description 1269 "the source of Network Slice link"; 1270 leaf src-ep-id { 1271 type leafref { 1272 path "/ietf-network-slices/ietf-network-slice/" 1273 + "ns-endpoint/ep-id"; 1274 } 1275 description 1276 "reference to source Network Slice endpoint"; 1277 } 1278 } 1279 container dest { 1280 description 1281 "the destination of Network Slice link "; 1282 leaf dest-ep-id { 1283 type leafref { 1284 path "/ietf-network-slices/ietf-network-slice" 1285 + "/ns-endpoint/ep-id"; 1286 } 1287 description 1288 "reference to dest Network Slice endpoint"; 1289 } 1290 } 1291 leaf monitoring-type { 1292 type ns-monitoring-type; 1293 description 1294 "One way or two way monitoring type."; 1295 } 1296 container ns-member-monitoring { 1297 config false; 1298 description 1299 "SLO status Per network-slice endpoint to endpoint "; 1300 uses common-monitoring-parameters; 1301 } 1302 } 1304 //network-slice-member 1306 grouping slice-template { 1307 description 1308 "Grouping for slice-templates."; 1309 container ns-templates { 1310 description 1311 "Contains a set of network slice templates to 1312 reference in the IETF network slice."; 1313 list slo-template { 1314 key "id"; 1315 leaf id { 1316 type string; 1317 description 1318 "Identification of the SLO Template to be used. 1319 Local administration meaning."; 1320 } 1321 leaf template-description { 1322 type string; 1323 description 1324 "Description of the SLO policy template."; 1325 } 1326 description 1327 "List for SLO template identifiers."; 1328 } 1329 } 1330 } 1332 /* Configuration data nodes */ 1334 container ietf-network-slices { 1335 description 1336 "IETF network-slice configurations"; 1337 uses slice-template; 1338 list ietf-network-slice { 1339 key "ns-id"; 1340 description 1341 "a network-slice is identified by a network-slice-id"; 1342 leaf ns-id { 1343 type string; 1344 description 1345 "A unique network-slice identifier across an IETF NSC "; 1346 } 1347 leaf ns-description { 1348 type string; 1349 description 1350 "Give more description of the network slice"; 1351 } 1352 leaf-list ns-tag { 1353 type string; 1354 description 1355 "Network Slice tag for operational management"; 1356 } 1357 leaf ns-topology { 1358 type identityref { 1359 base network-slice-topology; 1360 } 1361 default "any-to-any"; 1362 description 1363 "Network Slice topology."; 1364 } 1365 choice ns-slo-policy { 1366 description 1367 "Choice for SLO policy template. 1368 Can be standard template or customized template."; 1369 case standard { 1370 description 1371 "Standard SLO template."; 1372 leaf slo-template { 1373 type leafref { 1374 path "/ietf-network-slices" 1375 + "/ns-templates/slo-template/id"; 1376 } 1377 description 1378 "Standard SLO template to be used."; 1379 } 1380 } 1381 case custom { 1382 description 1383 "Customized SLO template."; 1384 container slo-policy { 1385 description 1386 "Contains the SLO policy."; 1387 leaf policy-description { 1388 type string; 1389 description 1390 "Description of the SLO policy."; 1391 } 1392 uses network-slice-metric-bounds; 1393 } 1394 } 1395 } 1396 uses status-params; 1397 list ns-endpoint { 1398 key "ep-id"; 1399 uses endpoint; 1400 description 1401 "list of endpoints in this slice"; 1402 } 1403 list ns-member { 1404 key "ns-member-id"; 1405 description 1406 "List of network-slice-member in a slice"; 1407 uses network-slice-member; 1408 } 1409 } 1410 //ietf-network-slice list 1412 } 1413 } 1414 1416 9. Security Considerations 1418 The YANG module defined in this document is designed to be accessed 1419 via network management protocols such as NETCONF [RFC6241] or 1420 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1421 layer, and the mandatory-to-implement secure transport is Secure 1422 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1423 mandatory-to-implement secure transport is TLS [RFC8446]. 1425 The NETCONF access control model [RFC8341] provides the means to 1426 restrict access for particular NETCONF or RESTCONF users to a 1427 preconfigured subset of all available NETCONF or RESTCONF protocol 1428 operations and content. 1430 There are a number of data nodes defined in this YANG module that are 1431 writable/creatable/deletable (i.e., config true, which is the 1432 default). These data nodes may be considered sensitive or vulnerable 1433 in some network environments. Write operations (e.g., edit-config) 1434 to these data nodes without proper protection can have a negative 1435 effect on network operations. 1437 o /ietf-network-slice/ietf-network-slices/ietf-network-slice 1439 The entries in the list above include the whole network 1440 configurations corresponding with the slice which the higher 1441 management system requests, and indirectly create or modify the PE or 1442 P device configurations. Unexpected changes to these entries could 1443 lead to service disruption and/or network misbehavior. 1445 10. IANA Considerations 1447 This document registers a URI in the IETF XML registry [RFC3688]. 1448 Following the format in [RFC3688], the following registration is 1449 requested to be made: 1451 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 1452 Registrant Contact: The IESG. 1453 XML: N/A, the requested URI is an XML namespace. 1455 This document requests to register a YANG module in the YANG Module 1456 Names registry [RFC7950]. 1458 Name: ietf-network-slice 1459 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 1460 Prefix: ietf-ns 1461 Reference: RFC XXXX 1463 11. Acknowledgments 1465 The authors wish to thank Sergio Belotti, Qin Wu, Susan Hares, Eric 1466 Grey, and many other NS DT members for their helpful comments and 1467 suggestions. 1469 12. References 1471 12.1. Normative References 1473 [I-D.ietf-teas-ietf-network-slice-definition] 1474 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1475 Tantsura, "Definition of IETF Network Slices", draft-ietf- 1476 teas-ietf-network-slice-definition-00 (work in progress), 1477 January 2021. 1479 [I-D.nsdt-teas-ns-framework] 1480 Gray, E. and J. Drake, "Framework for Transport Network 1481 Slices", draft-nsdt-teas-ns-framework-04 (work in 1482 progress), July 2020. 1484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1485 Requirement Levels", BCP 14, RFC 2119, 1486 DOI 10.17487/RFC2119, March 1997, 1487 . 1489 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1490 DOI 10.17487/RFC3688, January 2004, 1491 . 1493 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1494 and A. Bierman, Ed., "Network Configuration Protocol 1495 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1496 . 1498 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1499 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1500 . 1502 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1503 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1504 . 1506 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1507 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1508 . 1510 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1511 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1512 . 1514 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1515 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1516 May 2017, . 1518 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1519 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1520 . 1522 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1523 Access Control Model", STD 91, RFC 8341, 1524 DOI 10.17487/RFC8341, March 2018, 1525 . 1527 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1528 and R. Wilton, "Network Management Datastore Architecture 1529 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1530 . 1532 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1533 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1534 . 1536 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1537 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1538 and Datastores over NETCONF", RFC 8640, 1539 DOI 10.17487/RFC8640, September 2019, 1540 . 1542 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1543 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1544 September 2019, . 1546 12.2. Informative References 1548 [I-D.geng-teas-network-slice-mapping] 1549 Geng, X., Dong, J., Pang, R., Han, L., Niwa, T., Jin, J., 1550 Liu, C., and N. Nageshar, "5G End-to-end Network Slice 1551 Mapping from the view of Transport Network", draft-geng- 1552 teas-network-slice-mapping-02 (work in progress), July 1553 2020. 1555 [I-D.ietf-teas-actn-vn-yang] 1556 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1557 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1558 teas-actn-vn-yang-10 (work in progress), November 2020. 1560 [I-D.liu-teas-transport-network-slice-yang] 1561 Liu, X., Tantsura, J., Bryskin, I., Contreras, L., WU, Q., 1562 Belotti, S., and R. Rokui, "IETF Network Slice YANG Data 1563 Model", draft-liu-teas-transport-network-slice-yang-02 1564 (work in progress), November 2020. 1566 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1567 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1568 . 1570 Appendix A. IETF Network Slice NBI Model Usage Example 1572 The following example describes a simplified service configuration of 1573 two IETF Network slice instances: 1575 o IETF Network Slice 1 on Device1, Device3, and Device4, with any- 1576 to-any connection type 1578 o IETF Network Slice 2 on Device2, Device3, with any-to-any 1579 connection type 1581 192.0.2.2 VLAN1 1582 +--------+ 1583 |Device1 o------/ 1584 +--------+ | +------+ 1585 +--------+ +------o| A +---------------+ 1586 |Device2 o-------/-----o| | | 1587 +--------+ +---+--+ | 1588 198.51.100.2 | | 1589 VLAN2 | +---+--+ 192.0.2.4 VLAN1 1590 | | | +--------+ 1591 192.0.2.3 VLAN1 | | C o-----/-----oDevice4 | 1592 +--------+ | +---+--+ +--------+ 1593 | o------/ | | 1594 | | | +---+--+ | 1595 | Device3| +------o| B +---------------+ 1596 | o-------/-----o| | 1597 +--------+ +------+ 1598 198.51.100.3 1599 VLAN2 1601 POST: /restconf/data/ietf-network-slice:ietf-network-slices 1602 Host: example.com 1603 Content-Type: application/yang-data+json 1605 { 1606 "ietf-network-slices": { 1607 "ietf-network-slice": [ 1608 { 1609 "network-slice-id": 1, 1610 "network-slice-name": "slice1", 1611 "network-slice-topology": "any-to-any", 1612 "network-slice-endpoint": [ 1613 { 1614 "endpoint-id": 11, 1615 "endpoint-name": "device1-ep1", 1616 "endpoint-role": "any-to-any-role", 1617 "network-slice-match-criteria": [ 1618 { 1619 "match-type": "network-slice-vlan-match", 1620 "value": "1" 1621 } 1622 ] 1623 }, 1624 { 1625 "endpoint-id": 12, 1626 "endpoint-name": "device3-ep1", 1627 "endpoint-role": "any-to-any-role", 1628 "network-slice-match-criteria": [ 1629 { 1630 "match-type": "network-slice-vlan-match", 1631 "value": "1" 1632 } 1633 ] 1634 }, 1635 { 1636 "endpoint-id": 13, 1637 "endpoint-name": "device4-ep1", 1638 "endpoint-role": "any-to-any-role", 1639 "network-slice-match-criteria": [ 1640 { 1641 "match-type": "network-slice-vlan-match", 1642 "value": "1" 1643 } 1644 ] 1645 } 1646 ] 1647 }, 1648 { 1649 "network-slice-id": 2, 1650 "network-slice-name": "slice2", 1651 "network-slice-topology": "any-to-any", 1652 "network-slice-endpoint": [ 1653 { 1654 "endpoint-id": 21, 1655 "endpoint-name": "device2-ep1", 1656 "endpoint-role": "any-to-any-role", 1657 "network-slice-match-criteria": [ 1658 { 1659 "match-type": "network-slice-vlan-match", 1660 "value": "2" 1661 } 1662 ] 1663 }, 1664 { 1665 "endpoint-id": 22, 1666 "endpoint-name": "device3-ep2", 1667 "endpoint-role": "any-to-any-role", 1668 "network-slice-match-criteria": [ 1669 { 1670 "match-type": "network-slice-vlan-match", 1671 "value": "2" 1672 } 1673 ] 1674 } 1675 ] 1676 } 1677 ] 1678 } 1679 } 1681 Appendix B. Comparison with Other Possible Design choices for IETF 1682 Network Slice NBI 1684 According to the 3.3.1. Northbound Inteface (NBI) 1685 [I-D.nsdt-teas-ns-framework], the IETF Network Slice NBI is a 1686 technology-agnostic interface, which is used for a consumer to 1687 express requirements for a particular IETF Network Slice. Consumers 1688 operate on abstract IETF Network Slices, with details related to 1689 their realization hidden. As classified by [RFC8309], the IETF 1690 Network Slice NBI is classified as Customer Service Model. 1692 This draft analyzes the following existing IETF models to identify 1693 the gap between the IETF Network Slice NBI requirements. 1695 B.1. ACTN VN Model Augmentation 1697 The difference between the ACTN VN model and the IETF Network Slice 1698 NBI requirements is that the IETF Network Slice NBI is a technology- 1699 agnostic interface, whereas the VN model is bound to the IETF TE 1700 Topologies. The realization of the IETF Network Slice does not 1701 necessarily require the slice network to support the TE technology. 1703 The ACTN VN (Virtual Network) model introduced in 1704 [I-D.ietf-teas-actn-vn-yang] is the abstract consumer view of the TE 1705 network. Its YANG structure includes four components: 1707 o VN: A Virtual Network (VN) is a network provided by a service 1708 provider to a customer for use and two types of VN has defined. 1709 The Type 1 VN can be seen as a set of edge-to-edge abstract links. 1710 Each link is an abstraction of the underlying network which can 1711 encompass edge points of the customer's network, access links, 1712 intra-domain paths, and inter-domain links. 1714 o AP: An AP is a logical identifier used to identify the access link 1715 which is shared between the customer and the IETF scoped Network. 1717 o VN-AP: A VN-AP is a logical binding between an AP and a given VN. 1719 o VN-member: A VN-member is an abstract edge-to-edge link between 1720 any two APs or VN-APs. Each link is formed as an E2E tunnel 1721 across the underlying networks. 1723 The Type 1 VN can be used to describe IETF Network Slice connection 1724 requirements. However, the Network Slice SLO and Network Slice 1725 Endpoint are not clearly defined and there's no direct equivalent. 1726 For example, the SLO requirement of the VN is defined through the 1727 IETF TE Topologies YANG model, but the TE Topologies model is related 1728 to a specific implementation technology. Also, VN-AP does not define 1729 "network-slice-match-criteria" to specify a specific NSE belonging to 1730 an IETF Network Slice. 1732 B.2. RFC8345 Augmentation Model 1734 The difference between the IETF Network Slice NBI requirements and 1735 the IETF basic network model is that the IETF Network Slice NBI 1736 requests abstract consumer IETF Network Slices, with details related 1737 to the slice Network hidden. But the IETF network model is used to 1738 describe the interconnection details of a Network. The customer 1739 service model does not need to provide details on the Network. 1741 For example, IETF Network Topologies YANG data model extension 1742 introduced in Transport Network Slice YANG Data Model 1744 [I-D.liu-teas-transport-network-slice-yang] includes three major 1745 parts: 1747 o Network: a transport network list and an list of nodes contained 1748 in the network 1750 o Link: "links" list and "termination points" list describe how 1751 nodes in a network are connected to each other 1753 o Support network: vertical layering relationships between IETF 1754 Network Slice networks and underlay networks 1756 Based on this structure, the IETF Network Slice-specific SLO 1757 attributes nodes are augmented on the Network Topologies model,, e.g. 1758 isolation etc. However, this modeling design requires the slice 1759 network to expose a lot of details of the network, such as the actual 1760 topology including nodes interconnection and different network layers 1761 interconnection. 1763 Appendix C. Appendix B IETF Network Slice Match Criteria 1765 5G is a use case of the IETF Network Slice and 5G End-to-end Network 1766 Slice Mapping from the view of IETF Network 1767 [I-D.geng-teas-network-slice-mapping] 1769 defines two types of Network Slice interconnection and 1770 differentiation methods: by physical interface or by TNSII (Transport 1771 Network Slice Interworking Identifier). TNSII is a field in the 1772 packet header when different 5G wireless network slices are 1773 transported through a single physical interfaces of the IETF scoped 1774 Network. In the 5G scenario, "network-slice-match-criteria" refers 1775 to TNSII. 1777 +------------------------------------------------------------+ 1778 | 5G E2E network slice orchestrator | 1779 ++-----------------------------------------------------+-----+ 1780 | | | 1781 | IETF Network Slice NBI | 1782 +---+-------+ | +-----+-----+ 1783 | | +------------------+ | | 1784 |RAN Slice | |IETF Network Slice| |Core Slice | 1785 |controller | | controller | | controller| 1786 +----+------+ +-------+----------+ +-----+-----+ 1787 | | | 1788 | | | 1789 +---+--+ +------------+----------------+ ++-----+ 1790 | | | | | | 1791 | | | | | | 1792 |+----+| | | | | 1793 || ||NS1-NSE1 | Network Slice 1 | |+----+| 1794 ||gNB1|+---------+-----+-----------------------+--------+|UPF1|| 1795 || |+************ / |NS1-NSE3|+----+| 1796 |+----+|NS2-NSE1 | */ | | | 1797 | | /* | | | 1798 |+----+|NS1-NSE2 | / * | | | 1799 || |+---------- * Network Slice 2 |NS2-NSE3|+----+| 1800 ||gNB2|+************************************************+|UPF2|| 1801 || ||NS2-NSE2 | | |+----+| 1802 |+----+| | | | 1803 | | | | | | 1804 | | | | | | 1805 +------+ +----------- -----------------+ +------+ 1807 As shown in the figure, gNodeB 1 and gNodeB 2 use IP gNB1 and IP gNB2 1808 to communicate with the IETF network, respectively. In addition, the 1809 traffic of NS1 and NS2 on gNodeB 1 and gNodeB 2 is transmitted 1810 through the same access links to the IETF slice network. The IETF 1811 slice network need to to distinguish different IETF Network Slice 1812 traffic of same gNB. Therefore, in addition to using "node-id" and 1813 "port-id" to identify a Network Slice Endpont, other information is 1814 needed along with these parameters to uniquely distinguish a NSE. 1815 For example, VLAN IDs in the user traffic can be used to distinguish 1816 the NSEs of gNBs and UPFs. 1818 Authors' Addresses 1819 Bo Wu 1820 Huawei Technologies 1821 101 Software Avenue, Yuhua District 1822 Nanjing, Jiangsu 210012 1823 China 1825 Email: lana.wubo@huawei.com 1827 Dhruv Dhody 1828 Huawei Technologies 1829 Divyashree Techno Park 1830 Bangalore, Karnataka 560066 1831 India 1833 Email: dhruv.ietf@gmail.com 1835 Liuyan Han 1836 China Mobile 1838 Email: hanliuyan@chinamobile.com 1840 Reza Rokui 1841 Nokia 1843 Email: reza.rokui@nokia.com