idnits 2.17.00 (12 Aug 2021) /tmp/idnits52252/draft-ietf-teas-ietf-network-slice-nbi-yang-01.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 12 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 352 has weird spacing: '...w index uin...' == Line 357 has weird spacing: '...ol-type ide...' == Line 392 has weird spacing: '...w index uin...' == Line 397 has weird spacing: '...ol-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 (4 March 2022) is 71 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: 'I-D.ietf-opsawg-vpn-common' is defined on line 2180, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7640 == Outdated reference: A later version (-05) exists of draft-geng-teas-network-slice-mapping-04 == Outdated reference: draft-ietf-opsawg-vpn-common has been published as RFC 9181 == Outdated reference: A later version (-14) exists of draft-ietf-teas-actn-vn-yang-13 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-05 == Outdated reference: A later version (-05) exists of draft-liu-teas-transport-network-slice-yang-04 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS B. Wu 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: 5 September 2022 R. Rokui 6 Ciena 7 T. Saad 8 Juniper Networks 9 L. Han 10 China Mobile 11 4 March 2022 13 IETF Network Slice Service YANG Model 14 draft-ietf-teas-ietf-network-slice-nbi-yang-01 16 Abstract 18 This document defines a YANG model for the IETF Network Slice service 19 model. The model can be used by a IETF Network Slice customer to 20 manage IETF Network Slice from an IETF Network Slice Controller 21 (NSC). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 5 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. IETF Network Slice Service Model Usage . . . . . . . . . . . 4 60 4. IETF Network Slice Service Model Overview . . . . . . . . . . 5 61 5. IETF Network Slice Templates . . . . . . . . . . . . . . . . 11 62 6. IETF Network Slice Modeling Description . . . . . . . . . . . 12 63 6.1. IETF Network Slice Connectivity . . . . . . . . . . . . . 13 64 6.2. IETF Network Slice SLO and SLE Policy . . . . . . . . . . 13 65 6.3. IETF Network Slice Endpoint (NSE) . . . . . . . . . . . . 15 66 7. IETF Network Slice Monitoring . . . . . . . . . . . . . . . . 19 67 8. IETF Network Slice Service Module . . . . . . . . . . . . . . 20 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 71 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 73 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 74 13.2. Informative References . . . . . . . . . . . . . . . . . 47 75 Appendix A. IETF Network Slice Service Model Usage Example . . . 48 76 Appendix B. Comparison with Other Possible Design choices for IETF 77 Network Slice Service Interface . . . . . . . . . . . . . 57 78 B.1. ACTN VN Model Augmentation . . . . . . . . . . . . . . . 58 79 B.2. RFC8345 Augmentation Model . . . . . . . . . . . . . . . 59 80 Appendix C. Appendix B IETF Network Slice Match Criteria . . . . 59 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 83 1. Introduction 85 This document defines a YANG [RFC7950] data model for the IETF 86 Network Slice service model. 88 The YANG model discussed in this document is defined based on the 89 description of the IETF Network Slice in 90 [I-D.ietf-teas-ietf-network-slices], which is used to operate IETF 91 Network Slices during the IETF Network Slice instantiation. This 92 YANG model supports various operations on IETF Network Slices such as 93 creation, modification, deletion, and monitoring. 95 The IETF Network Slice Controller (NSC) is a logical entity that 96 allows customers to manage IETF network slices. Customers operate on 97 abstract IETF network slices. Details related to the production of 98 slices that fulfil the request are internal to the entity that 99 operates the network. Such details are deployment- and 100 implementation-specific. 102 The NSC receives request from its customer-facing interface (e.g., 103 from a management system). This interface carries data objects the 104 IETF network slice user provides, describing the needed IETF network 105 slices in terms of topology, target service level objectives (SLO), 106 and also monitoring and reporting requirements. These requirements 107 are then translated into technology-specific actions that are 108 implemented in the underlying network using a network-facing 109 interface. The details of how the IETF network slices are put into 110 effect are out of scope for this document. 112 The YANG model discussed in this document describes the requirements 113 of an IETF Network Slice from the point of view of the customer. It 114 is thus classified as customer service model in [RFC8309]. 116 Editorial Note: (To be removed by RFC Editor) 118 This draft contains several placeholder values that need to be 119 replaced with finalized values at the time of publication. Please 120 apply the following replacements: 122 * "XXXX" --> the assigned RFC value for this draft both in this 123 draft and in the YANG models under the revision statement. 125 * The "revision" date in model, in the format XXXX-XX-XX, needs to 126 be updated with the date the draft gets approved. 128 The IETF Network Slice operational state is included in the same tree 129 as the configuration consistent with Network Management Datastore 130 Architecture [RFC8342]. 132 2. Conventions used in this document 134 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 The following terms are defined in [RFC6241] and are used in this 141 specification: 143 * client 145 * configuration data 147 * state data 149 This document makes use of the terms defined in [RFC7950]. 151 The tree diagram used in this document follow the notation defined in 152 [RFC8340]. 154 This document also makes use of the terms introduced in the Framework 155 for IETF Network Slices [I-D.ietf-teas-ietf-network-slices]. 157 This document defines the following terms: 159 * IETF Network Slice Connection (NS-Connection): Refers to 160 connectivity construct defined 161 in[I-D.ietf-teas-ietf-network-slices]. An IETF Network Slice can 162 have one or multiple NS-Connections. 164 * IETF Network Slice Connection (NS-Connection-group): When an IETF 165 Network Slice has multiple NS-connections. The connections with 166 similar SLO or SLE are treated as one NS-connection group. An 167 IETF Network Slice can have one or multiple NS-Connection-groups. 169 2.1. Acronyms 171 The following acronyms are used in the document: 173 CE Customer Edge 174 NSC Network Slice Controller 175 NSE Network Slice Endpoint 176 MTU Maximum Transmission Unit 177 PE Provider Edge 178 SLE Service Level Expectation 179 SLO Service Level Objective 181 3. IETF Network Slice Service Model Usage 183 The intention of the IETF Network Slice service model is to allow the 184 customer to manage IETF Network Slices. In particular, the model 185 allows customers to operate in an abstract and technology-agnostic 186 manner, with details of the IETF Network Slices realization hidden. 188 According to the [I-D.ietf-teas-ietf-network-slices] description, 189 IETF Network Slices are applicable to use cases such as (but not 190 limited to) network wholesale services, network infrastructure 191 sharing among operators, NFV (Network Function Virtualization) 192 connectivity, Data Center Interconnect, and 5G E2E network slice. 194 As shown in Figure 1, in all these use-cases, the model is used by 195 the higher management system to communicate with NSC for life cycle 196 manage of IETF Network Slices including both enablement and 197 monitoring. For example, in 5G E2E (End-to-end) network slicing use- 198 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 Customer | 205 | | 206 +----------------+-----------------------+ 207 | 208 | 209 |IETF Network Slice service model YANG 210 | 211 +---------------------+--------------------------+ 212 | IETF Network Slice Controller (NSC) | 213 +------------------------------------------------+ 215 Figure 1: IETF Network Slice Service Reference Architecture 217 4. IETF Network Slice Service Model Overview 219 As defined in [I-D.ietf-teas-ietf-network-slices], an IETF Network 220 Slice service is specified in terms of a set of endpoints, a set of 221 one or more connectivity constructs (point-to-point (P2P), point-to- 222 multipoint (P2MP), or multipoint-to-multipoint (MP2MP) between 223 subsets of these endpoints, and a set of SLOs and SLEs for each 224 endpoints sending to each connectivity construct. A connection 225 construct is the basic connectivity unit of a network slice, and a 226 slice service may consist of one or more connection constructs. The 227 endpoints are conceptual points that could map to a device, 228 application or a network function. And the specific service 229 requirements, typically expressed as bandwidth, latency, latency 230 variation, and other desired or required characteristics, such as 231 security, MTU, traffic-type (e.g., IPv4, IPv6, Ethernet or 232 unstructured) or a higher-level behavior to process traffic according 233 to user-application (which may be realized using network function). 234 An example of an IETF network slice containing multiple connectivity 235 constructs is shown in Figure 2 . 237 +----------------------------------------------+ 238 | | 239 NSE1 O------------------+ | 240 | +---------------------------O NSE6 241 | MP2MP Blue | | 242 | +---------------------------O NSE7 243 NSE2 O------------------+ | 244 | | 245 | P2P Red | 246 NSE3 O---------------------------/------------------O NSE8 247 | / | 248 NSE4 O-------------------------/--------------------O NSE9 249 | | 250 | | 251 | P2MP Green +---------------------------O NSE10 252 NSE5 O------------------+ | 253 | +---------------------------O NSE11 254 | | 255 | P2P Yellow | 256 NSE12 O--------------------------/-------------------O NSE13 257 | / | 258 NSE14 O------------------------/---------------------O NSE15 259 | | 260 +----------------------------------------------+ 262 |<-----------An IETF Network Slice ---------->| 263 | between endpoints NSE1 to NSE15 | 265 NSE: IETF Network Slice Endpoint 266 O: Represents IETF Network Slice Endpoints 268 Figure 2: An IETF Network Slice Example 270 As shown in the example, an IETF network slice may have multiple 271 NSEs. The NSEs are the ingress/egress points where traffic enters/ 272 exits the IETF network slice. As the edge of the IETF network slice, 273 the NSEs also delimit a topological network portion within which the 274 committed SLOs apply. 276 When an NSC receives a message via its customer-facing interface for 277 creation/modification of an IETF network slice, it uses the provided 278 NSEs to retrieve the corresponding service demarcation link or slice 279 provider edge node" (e.g., PE). The NSC further maps them to the 280 appropriate service/tunnel/path endpoints in the underlying network. 281 It then uses services/tunnels/paths to realize the IETF network 282 slice. 284 The 'ietf-network-slice' module uses two main data nodes: list 'ietf- 285 network-slice' and container 'ns-templates' (see Figure 3). 287 The 'ietf-network-slice' list includes the set of IETF Network slices 288 managed within a provider network. 'ietf-network-slice' is the data 289 structure that abstracts an IETF Network Slice. Under the "ietf- 290 network-slice", list "ns-endpoint" is used to abstract the NSEs, e.g. 291 NSEs in the example above. And list "ns-connection" is used to 292 abstract connections or connectivity constructs between NSEs. 294 The 'ns-templates' container is used by the NSC to maintain a set of 295 common network slice templates that apply to one or several IETF 296 Network Slices. 298 The figure below describes the overall structure of the YANG module: 300 module: ietf-network-slice 301 +--rw network-slices 302 +--rw ns-slo-sle-templates 303 | +--rw ns-slo-sle-template* [id] 304 | +--rw id string 305 | +--rw template-description? string 306 +--rw network-slice* [ns-id] 307 +--rw ns-id string 308 +--rw ns-description? string 309 +--rw ns-tags 310 | +--rw ns-tag* [index] 311 | +--rw index uint32 312 | +--rw ns-tag-type? identityref 313 | +--rw ns-tag-value? string 314 +--rw (ns-slo-sle-policy)? 315 | +--:(standard) 316 | | +--rw slo-sle-template? leafref 317 | +--:(custom) 318 | +--rw slo-sle-policy 319 | +--rw policy-description? string 320 | +--rw ns-metric-bounds 321 | | +--rw ns-metric-bound* [metric-type] 322 | | +--rw metric-type identityref 323 | | +--rw metric-unit string 324 | | +--rw value-description? string 325 | | +--rw bound? uint64 326 | +--rw security* identityref 327 | +--rw isolation? identityref 328 | +--rw max-occupancy-level? uint8 329 | +--rw mtu uint16 330 | +--rw steering-constraints 331 | +--rw path-constraints 332 | +--rw service-function 333 +--rw status 334 | +--rw admin-enabled? boolean 335 | +--ro oper-status? operational-type 336 +--rw ns-endpoints 337 | +--rw ns-endpoint* [ep-id] 338 | +--rw ep-id string 339 | +--rw ep-description? string 340 | +--rw location 341 | | +--rw altitude? int64 342 | | +--rw latitude? decimal64 343 | | +--rw longitude? decimal64 344 | +--rw node-id? string 345 | +--rw ep-ip? inet:ip-address 346 | +--rw ns-match-criteria 347 | | +--rw ns-match-criterion* [index] 348 | | +--rw index uint32 349 | | +--rw match-type? 350 | | | identityref 351 | | +--rw values* [index] 352 | | | +--rw index uint8 353 | | | +--rw value? string 354 | | +--rw target-ns-connection-group-id? leafref 355 | +--rw ep-peering 356 | | +--rw protocol* [protocol-type] 357 | | +--rw protocol-type identityref 358 | | +--rw attribute* [index] 359 | | +--rw index uint8 360 | | +--rw attribute-description? string 361 | | +--rw value? string 362 | +--rw ep-network-access-points 363 | | +--rw ep-network-access-point* [network-access-id] 364 | | +--rw network-access-id 365 | | | string 366 | | +--rw network-access-description? 367 | | | string 368 | | +--rw network-access-node-id? 369 | | | string 370 | | +--rw network-access-tp-id? 371 | | | string 372 | | +--rw network-access-tp-ip-address? 373 | | | inet:ip-address 374 | | +--rw network-access-tp-ip-prefix-length? uint8 375 | | +--rw network-access-qos-policy-name? 376 | | | string 377 | | +--rw mtu 378 | | | uint16 379 | | +--rw network-access-tags 380 | | | +--rw network-access-tag* [index] 381 | | | +--rw index uint32 382 | | | +--rw network-access-tag-type? 383 | | | | identityref 384 | | | +--rw network-access-tag-value? string 385 | | +--rw ns-match-criteria 386 | | | +--rw ns-match-criterion* [index] 387 | | | +--rw index 388 | | | | uint32 389 | | | +--rw match-type? 390 | | | | identityref 391 | | | +--rw values* [index] 392 | | | | +--rw index uint8 393 | | | | +--rw value? string 394 | | | +--rw target-ns-connection-group-id? leafref 395 | | +--rw ep-peering 396 | | | +--rw protocol* [protocol-type] 397 | | | +--rw protocol-type identityref 398 | | | +--rw attribute* [index] 399 | | | +--rw index uint8 400 | | | +--rw attribute-description? string 401 | | | +--rw value? string 402 | | +--rw incoming-rate-limits 403 | | | +--rw cir? uint64 404 | | | +--rw cbs? uint64 405 | | | +--rw eir? uint64 406 | | | +--rw ebs? uint64 407 | | | +--rw pir? uint64 408 | | | +--rw pbs? uint64 409 | | +--rw outgoing-rate-limits 410 | | +--rw cir? uint64 411 | | +--rw cbs? uint64 412 | | +--rw eir? uint64 413 | | +--rw ebs? uint64 414 | | +--rw pir? uint64 415 | | +--rw pbs? uint64 416 | +--rw incoming-rate-limits 417 | | +--rw cir? uint64 418 | | +--rw cbs? uint64 419 | | +--rw eir? uint64 420 | | +--rw ebs? uint64 421 | | +--rw pir? uint64 422 | | +--rw pbs? uint64 423 | +--rw outgoing-rate-limits 424 | | +--rw cir? uint64 425 | | +--rw cbs? uint64 426 | | +--rw eir? uint64 427 | | +--rw ebs? uint64 428 | | +--rw pir? uint64 429 | | +--rw pbs? uint64 430 | +--rw status 431 | | +--rw admin-enabled? boolean 432 | | +--ro oper-status? operational-type 433 | +--ro ep-monitoring 434 | +--ro incoming-utilized-bandwidth? 435 | | te-types:te-bandwidth 436 | +--ro incoming-bw-utilization decimal64 437 | +--ro outgoing-utilized-bandwidth? 438 | | te-types:te-bandwidth 439 | +--ro outgoing-bw-utilization decimal64 440 +--rw ns-connection-groups 441 +--rw ns-connection-group* [ns-connection-group-id] 442 +--rw ns-connection-group-id string 443 +--rw (ns-slo-sle-policy)? 444 | +--:(standard) 445 | | +--rw slo-sle-template? leafref 446 | +--:(custom) 447 | +--rw slo-sle-policy 448 | +--rw policy-description? string 449 | +--rw ns-metric-bounds 450 | | +--rw ns-metric-bound* [metric-type] 451 | | +--rw metric-type identityref 452 | | +--rw metric-unit string 453 | | +--rw value-description? string 454 | | +--rw bound? uint64 455 | +--rw security* identityref 456 | +--rw isolation? identityref 457 | +--rw max-occupancy-level? uint8 458 | +--rw mtu uint16 459 | +--rw steering-constraints 460 | +--rw path-constraints 461 | +--rw service-function 462 +--rw ns-connection* [ns-connection-id] 463 | +--rw ns-connection-id uint32 464 | +--rw ns-connectivity-type? identityref 465 | +--rw src-nse* leafref 466 | +--rw dest-nse* leafref 467 | +--rw (ns-slo-sle-policy)? 468 | | +--:(standard) 469 | | | +--rw slo-sle-template? leafref 470 | | +--:(custom) 471 | | +--rw slo-sle-policy 472 | | +--rw policy-description? string 473 | | +--rw ns-metric-bounds 474 | | | +--rw ns-metric-bound* [metric-type] 475 | | | +--rw metric-type 476 | | | | identityref 477 | | | +--rw metric-unit string 478 | | | +--rw value-description? string 479 | | | +--rw bound? uint64 480 | | +--rw security* identityref 481 | | +--rw isolation? identityref 482 | | +--rw max-occupancy-level? uint8 483 | | +--rw mtu uint16 484 | | +--rw steering-constraints 485 | | +--rw path-constraints 486 | | +--rw service-function 487 | +--ro ns-connection-monitoring 488 | +--ro one-way-min-delay? uint32 489 | +--ro one-way-max-delay? uint32 490 | +--ro one-way-delay-variation? uint32 491 | +--ro one-way-packet-loss? decimal64 492 | +--ro two-way-min-delay? uint32 493 | +--ro two-way-max-delay? uint32 494 | +--ro two-way-delay-variation? uint32 495 | +--ro two-way-packet-loss? decimal64 496 +--ro ns-connection-group-monitoring 497 +--ro one-way-min-delay? uint32 498 +--ro one-way-max-delay? uint32 499 +--ro one-way-delay-variation? uint32 500 +--ro one-way-packet-loss? decimal64 501 +--ro two-way-min-delay? uint32 502 +--ro two-way-max-delay? uint32 503 +--ro two-way-delay-variation? uint32 504 +--ro two-way-packet-loss? decimal64 506 Figure 3 508 5. IETF Network Slice Templates 510 The 'ns-templates' container (Figure 3) is used by service provider 511 of the NSC to define and maintain a set of common IETF Network Slice 512 templates that apply to one or several IETF Network Slices. The 513 exact definition of the templates is deployment specific to each 514 network provider. 516 The model includes only the identifiers of SLO and SLE templates. 517 When creation of IETF Network slice, the SLO and SLE policies can be 518 easily identified. 520 The following shows an example where two network slice templates can 521 be retrieved by the upper layer management system: 523 { 524 "ietf-network-slices": { 525 "ns-templates": { 526 "slo-sle-template": [ 527 { 528 "id":"GOLD-template", 529 "template-description": "Two-way bandwidth: 1 Gbps, 530 one-way latency 100ms " 531 "sle-isolation":"ns-isolation-shared", 532 }, 533 { 534 "id":"PLATINUM-template", 535 "template-description": "Two-way bandwidth: 1 Gbps, 536 one-way latency 50ms " 537 "sle-isolation":"ns-isolation-dedicated", 538 }, 539 ], 540 } 541 } 542 } 544 6. IETF Network Slice Modeling Description 546 The 'ietf-network-slice' is the data structure that abstracts an IETF 547 Network Slice of the IETF network. Each 'ietf-network-slice' is 548 uniquely identified by an identifier: 'ns-id'. 550 An IETF Network Slice has the following main parameters: 552 * "ns-id": Is an identifier that is used to uniquely identify the 553 IETF Network Slice within NSC. 555 * "ns-description": Gives some description of an IETF Network Slice 556 service. 558 * "status": Is used to show the operative and administrative status 559 of the IETF Network Slice, and can be used as indicator to detect 560 network slice anomalies. 562 * "ns-tags": It is a mean to correlate the higher level "Customer 563 higher level operation system" and IETF network slices. It might 564 be used by IETF network slice operator to provide additional 565 information to the IETF Network Slice Controller (NSC) during the 566 automation of the IETF network slices. E.g. adding tag with 567 "customer-name" when multiple actual customers use a same network 568 slice. Another use-case for "ns-tag" might be for Operator to 569 provide additional attributes to NSC which might be used during 570 the realization of IETF network slices such as type of services 571 (e.g., L2 or L3). These additional attributes can also be used by 572 the NSC for various use-cases such as monitoring and assurance of 573 the IETF network slices where NSC can notify the higher system by 574 issuing the notifications. Note that all these attributes are 575 OPTIONAL but might be useful for some use-cases. 577 * "ns-slo-sle-policy": Defines SLO and SLE policies for the "ietf- 578 network-slice". More description are provided in Section 6.2 580 * "ns-endpoint": Represents a set of matching rules applied to an 581 IETF network edge device or a customer network edge device 582 involved in the IETF Network Slice and each 'ns-endpoint' belongs 583 to a single 'ietf-network-slice'. More description are provided 584 inSection 6.3. 586 * "ns-connection-groups": Abstracts the connections between NSEs. 588 6.1. IETF Network Slice Connectivity 590 Based on the customer's traffic requirements, an IETF Network Slice 591 connectivity type could be point-to-point (P2P), point-to-multipoint 592 (P2MP), multipoint-to-point (MP2P), multipoint-to-multipoint (MP2MP) 593 or a combination of these types. 595 [I-D.ietf-teas-ietf-network-slices] defines the basic connectivity 596 construct for a network slice, and the connectivity construct may 597 have different SLO and SLE requirements. "ns-connection" represents 598 this connectivity construct, and "ns-slo-sle-policy" under it 599 represents the per-connection SLO and SLE requirements. 601 Apart from the per-connection SLO and SLE,slice traffic is usually 602 managed by combining similar types of traffic. For example, some 603 connections for video services require high bandwidth, and some 604 connections for voice over IP request low latency and reliability. 605 "ns-connect-group" is thus defined to treat each type as a class with 606 per-connection-group SLO and SLE. 608 6.2. IETF Network Slice SLO and SLE Policy 610 As defined in [I-D.ietf-teas-ietf-network-slices], the SLO and SLE 611 policy of an IETF Network Slice defines some common attributes. 613 "ns-slo-sle-policy" is used to represent specific SLO and SLE 614 policies. During the creation of an IETF Network Slice, the policy 615 can be specified either by a standard SLO and SLO template or a 616 customized SLO and SLE policy. 618 The policy can apply to per-network slice, per-connection group "ns- 619 connection group", or per-connection "ns-connection". 621 The container "ns-metric-bounds" supports all the variations and 622 combinations of NS SLOs, which includes a list of "ns-metric-bound" 623 and each "ns-metric-bound" could specify a particular "metric-type". 624 "metric-type" is defined with YANG identity and supports the 625 following options: 627 "ns-slo-one-way-bandwidth": Indicates the guaranteed minimum 628 bandwidth between any two NSE. And the bandwidth is 629 unidirectional. 631 "ns-slo-two-way-bandwidth": Indicates the guaranteed minimum 632 bandwidth between any two NSE. And the bandwidth is 633 bidirectional. 635 "network-slice-slo-one-way-latency": Indicates the maximum one-way 636 latency between two NSE. 638 "network-slice-slo-two-way-latency": Indicates the maximum round- 639 trip latency between two NSE. 641 "ns-slo-one-way-delay-variation": Indicates the jitter constraint 642 of the slice maximum permissible delay variation, and is measured 643 by the difference in the one-way latency between sequential 644 packets in a flow. 646 "ns-slo-two-way-delay-variation": Indicates the jitter constraint 647 of the slice maximum permissible delay variation, and is measured 648 by the difference in the two-way latency between sequential 649 packets in a flow. 651 "ns-slo-one-way-packet-loss": Indicates maximum permissible packet 652 loss rate, which is defined by the ratio of packets dropped to 653 packets transmitted between two endpoints. 655 "ns-slo-two-way-packet-loss": Indicates maximum permissible packet 656 loss rate, which is defined by the ratio of packets dropped to 657 packets transmitted between two endpoints. 659 "ns-slo-availability": Is defined as the ratio of up-time to 660 total_time(up-time+down-time), where up-time is the time the IETF 661 Network Slice is available in accordance with the SLOs associated 662 with it. 664 The following common SLEs are defined: 666 "mtu": Refers to the service MTU, which is the maximum PDU size 667 that the customer may use. 669 "security": Includes the request for encryption or other security 670 techniques to traffic flowing between the two NS endpoints. 672 "isolation": Specifies the isolation level that a customer 673 expects, including dedicated, shared, or other level. 675 max-occupancy-level: Specifies the number of flows to be admitted 676 and optionally a maximum number of countable resource units (e.g., 677 IP or MAC addresses) an IETF Network Slice service can consume. 679 "steering-constraints": Specifies the constraints how the provider 680 routes traffic for the IETF Network Slice service. 682 The following shows an example where a network slice policy can be 683 configured: 685 { 686 "ietf-network-slices": { 687 "ietf-network-slice": { 688 "slo-policy": { 689 "policy-description":"video-service-policy", 690 "ns-metric-bounds": { 691 "ns-metric-bound": [ 692 { 693 "metric-type": "ns-slo-one-way-bandwidth", 694 "metric-unit": "mbps" 695 "bound": "1000" 696 }, 697 { 698 "metric-type": "ns-slo-availability", 699 "bound": "99.9%" 700 }, 701 ], 702 } 703 } 704 } 705 } 706 } 708 6.3. IETF Network Slice Endpoint (NSE) 710 An NSE belong to a single IETF Network Slice. An IETF Network Slice 711 involves two or more NSEs. An IETF Network Slice can be modified by 712 adding new "ns-endpoint" or removing existing "ns-endpoint". 714 An IETF Network Slice Endpoint has several characteristics: 716 * "ep-id": Uniquely identifies the NSE within Network Slice 717 Controller (NSC). The identifier is a string that allows any 718 encoding for the local administration of the IETF Network Slice. 720 * "location": Indicates NSE location information that facilities NSC 721 easy identification of a NSE. 723 * "node-id": The NSE node information facilities NSC with easy 724 identification of a NSE. 726 * "ep-ip": The NSE IP information facilities NSC with easy 727 identification of a NSE. 729 * "ns-match-criteria": Defines matching policies for network slice 730 traffic to apply on a given NSE. 732 * "ep-network-access-points": Specifies the list of the interfaces 733 attached to an edge device of the IETF Network Slice by which the 734 customer traffic is received. This is an optional NSE attribute. 735 When a NSE has multiple interfaces attached and the NSC needs NSE 736 interface-specific attributes, each "ep-network-access-point" can 737 specify attributes such as interface specific IP address, MTU, 738 etc. 740 * "incoming-rate-limits" and "outgoing-rate-limits": Set the rate- 741 limiting policies to apply on a given NSE, including ingress and 742 egress traffic to ensure access security. When applied in the 743 incoming direction, the rate-limit is applicable to the traffic 744 from the NSE to the IETF scope Network that passes through the 745 external interface. When Bandwidth is applied to the outgoing 746 direction, it is applied to the traffic from the IETF Network to 747 the NSE of that particular NS. If an NSE has multiple AC, the 748 "rate limit" of "ep-network-access-point" can be set to an AC 749 specific value, but the rate cannot exceed the "rate limit" of the 750 NSE. If a NSE only contains a single AC, then the "rate-limit" of 751 "ep-network-access-point" is the same with the NSE "rate-limit". 752 The definition refers to [RFC7640]. 754 * "ep-peering": Specifies the protocol for a NSE for exchanging 755 control-plane information, e.g. L1 signaling protocol or L3 756 routing protocols,etc. 758 * "status": Enables the control of the operative and administrative 759 status of the NSE, can be used as indicator to detect NSE 760 anomalies. 762 NSE defines the matching rule on the customer traffic that can be 763 injected to an IETF Network Slice. "network-slice-match-criteria" is 764 defined to support different options. Classification can be based on 765 many criteria, such as: 767 * Physical interface: Indicates all the traffic received from the 768 interface belongs to the IETF Network Slice. 770 * Logical interface: For example, a given VLAN ID is used to 771 identify an IETF Network Slice. 773 * Encapsulation in the traffic header: For example, a source IP 774 address is used to identify an IETF Network Slice. 776 To illustrate the use of NSE parameters, the below are two examples. 777 How the NSC realize the mapping is out of scope for this document. 779 * NSE with PE parameters example: As shown in Figure 4 , customer of 780 the IETF network slice would like to connect two NSEs to satisfy 781 specific service, e.g., Network wholesale services. In this case, 782 the IETF network slice endpoints are mapped to physical interfaces 783 of PE nodes. The IETF network slice controller (NSC) uses 'node- 784 id' (PE device ID), 'ep-network-access-points' (Two PE interfaces 785 ) to map the interfaces and corresponding services/tunnels/paths. 787 NSE1 NSE2 788 (With PE1 parameters) (with PE2 parameters) 789 o<--------- IETF Network Slice 1 ------->o 790 + | | + 791 + |<----------- S1 ----------->| + 792 + | | + 793 + | |<------ T1 ------>| | + 794 + v v v v + 795 + +----+ +----+ + 796 +-----+ | | PE1|==================| PE2| +-----+ 797 | |----------X | | | | | | 798 | | | | | | X----------| | 799 | |----------X | | | | | | 800 +-----+ | | |==================| | | +-----+ 801 AC +----+ +----+ AC 802 Customer Provider Provider Customer 803 Edge 1 Edge 1 Edge 2 Edge 2 805 Legend: 806 O: Representation of the IETF network slice endpoints (NSE) 807 +: Mapping of NES to PE or CE-PE interfaces 808 X: Physical interfaces used for realization of IETF network slice 809 S1: L0/L1/L2/L3 services used for realization of IETF network slice 810 T1: Tunnels used for realization of IETF network slice 812 Figure 4 814 * NSE with CE parameters example: As shown in Figure 5 , customer of 815 the IETF network slice would like to connect two NSEs to provide 816 connectivity between transport portion of 5G RAN to 5G Core 817 network functions. In this scenario, the IETF network slice 818 controller (NSC) uses 'node-id' (CE device ID) , 'ep-ip' (CE 819 tunnel endpoint IP), 'network-slice-match-criteria' (VLAN 820 interface), 'ep-network-access-points' (Two nexthop interfaces ) 821 to retrieve the corresponding CEs, ACs, or PEs, and further map to 822 services/tunnels/paths. 824 NSE3 NSE4 825 (With CE1 parameters) (with CE2 parameters) 826 o<-------------- IETF Network Slice 2 ------------>o 827 + + 828 |<+-- ------------------- S2 ----------------- --+>| 829 | + + | 830 | + |<------ T2 ------>| + | 831 | + v v + | 832 v + +----+ +----+ + v 833 +-----++ | | PE1|==================| PE2| | + +-----+ 834 | X----------X | | | | +| | 835 | | | | | | X----------X | 836 | X----------X | | | | | | 837 +-----+ | | |==================| | | +-----+ 838 AC +----+ +----+ AC 839 Customer Provider Provider Customer 840 Edge 1 Edge 1 Edge 2 Edge 2 842 Legend: 843 O: Representation of the IETF network slice endpoints (NSE) 844 +: Mapping of NSE to CE or CE-PE interfaces 845 X: Physical interfaces used for realization of IETF network slice 846 S2: L0/L1/L2/L3 services used for realization of IETF network slice 847 T2: Tunnels used for realization of IETF network slice 849 Figure 5 851 Note: The model needs to be optimized for better extension of other 852 protocols or AC technologies. 854 7. IETF Network Slice Monitoring 856 An IETF Network Slice is a connectivity with specific SLO 857 characteristics, including bandwidth, latency, etc. The connectivity 858 is a combination of logical unidirectional connections, represented 859 by 'ns-connection'. 861 This model also describes performance status of an IETF Network 862 Slice. The statistics are described in the following granularity: 864 * Per NS connection: specified in 'ns-connection-monitoring' under 865 the "ns-connection". 867 * Per NS Endpoint: specified in 'ep-monitoring' under the "ns- 868 endpoint". 870 * Per NS connection group: specified in 'ns-connection-monitoring' 871 under the "ns-connection-group". 873 This model does not define monitoring enabling methods. The 874 mechanism defined in [RFC8640] and [RFC8641] can be used for either 875 periodic or on-demand subscription. 877 By specifying subtree filters or xpath filters to 'ns-connection', 878 'ns-endpoint' or "ns-connection-group", so that only interested 879 contents will be sent. These mechanisms can be used for monitoring 880 the IETF Network Slice performance status so that the customer 881 management system could initiate modification based on the IETF 882 Network Slice running status. 884 Note: More critical events affecting service delivery need to be 885 added. 887 8. IETF Network Slice Service Module 889 The "ietf-network-slice" module uses types defined in [RFC6991] and 890 [RFC8776], and [RFC7640]. 892 file "ietf-network-slice@2022-03-04.yang" 893 module ietf-network-slice { 894 yang-version 1.1; 895 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 896 prefix ietf-ns; 898 import ietf-inet-types { 899 prefix inet; 900 reference 901 "RFC 6991: Common YANG Types."; 902 } 903 import ietf-te-types { 904 prefix te-types; 905 reference 906 "RFC 8776: Common YANG Data Types for Traffic Engineering."; 907 } 908 import ietf-te-packet-types { 909 prefix te-packet-types; 910 reference 911 "RFC 8776: Common YANG Data Types for Traffic Engineering."; 912 } 914 organization 915 "IETF Traffic Engineering Architecture and Signaling (TEAS) 916 Working Group"; 917 contact 918 "WG Web: 919 WG List: 921 Editor: Bo Wu 922 923 Editor: Dhruv Dhody 924 925 Editor: Reza Rokui 926 927 Editor: Tarek Saad 928 929 Author: Liuyan Han 930 "; 931 description 932 "This module contains a YANG module for the IETF Network Slice. 934 Copyright (c) 2022 IETF Trust and the persons identified as 935 authors of the code. All rights reserved. 937 Redistribution and use in source and binary forms, with or 938 without modification, is permitted pursuant to, and subject 939 to the license terms contained in, the Revised BSD License 940 set forth in Section 4.c of the IETF Trust's Legal Provisions 941 Relating to IETF Documents 942 (https://trustee.ietf.org/license-info). 944 This version of this YANG module is part of RFC XXXX; see the 945 RFC itself for full legal notices."; 947 revision 2022-03-04 { 948 description 949 "initial version."; 950 reference 951 "RFC XXXX: A Yang Data Model for IETF Network Slice Operation"; 952 } 954 /* Features */ 955 /* Identities */ 957 identity ns-tag-type { 958 description 959 "Base identity for IETF Network Slice tag type."; 960 } 962 identity ns-tag-customer { 963 base ns-tag-type; 964 description 965 "The IETF Network Slice customer ID tag type."; 967 } 969 identity ns-tag-service { 970 base ns-tag-type; 971 description 972 "The IETF Network Slice service tag type."; 973 } 975 identity ns-tag-opaque { 976 base ns-tag-type; 977 description 978 "The IETF Network Slice opaque tag type."; 979 } 981 identity network-access-tag-type { 982 description 983 "Base identity for the network access tag type."; 984 } 986 identity network-access-tag-vlan-id { 987 base network-access-tag-type; 988 description 989 "The network access interface VLAN ID tag type."; 990 } 992 identity network-access-tag-ip-mask { 993 base network-access-tag-type; 994 description 995 "The network access tag IP mask."; 996 } 998 identity network-access-tag-opaque { 999 base network-access-tag-type; 1000 description 1001 "The network access opaque tag type."; 1002 } 1004 identity ns-isolation-type { 1005 description 1006 "Base identity for IETF Network slice isolation level."; 1007 } 1009 identity ns-isolation-shared { 1010 base ns-isolation-type; 1011 description 1012 "Shared resources (e.g. queues) are associated with the Network 1013 Slice traffic. Hence, the IETF network slice traffic can be 1014 impacted by effects of other services traffic sharing 1015 the same resources."; 1016 } 1018 identity ns-isolation-dedicated { 1019 base ns-isolation-type; 1020 description 1021 "Dedicated resources (e.g. queues) are associated with the 1022 Network Slice traffic. Hence, the IETF network slice traffic 1023 is isolated from other servceis traffic sharing the same 1024 resources."; 1025 } 1027 identity ns-security-type { 1028 description 1029 "Base identity for for IETF Network security level."; 1030 } 1032 identity ns-security-authenticate { 1033 base ns-security-type; 1034 description 1035 "IETF Network Slice requires authentication."; 1036 } 1038 identity ns-security-integrity { 1039 base ns-security-type; 1040 description 1041 "IETF Network Slice requires data integrity."; 1042 } 1044 identity ns-security-encryption { 1045 base ns-security-type; 1046 description 1047 "IETF Network Slice requires data encryption."; 1048 } 1050 identity ns-connectivity-type { 1051 description 1052 "Base identity for IETF Network Slice connectivity."; 1053 } 1055 identity point-to-point { 1056 base ns-connectivity-type; 1057 description 1058 "Identity for point-to-point IETF Network Slice connectivity."; 1059 } 1061 identity point-to-multipoint { 1062 base ns-connectivity-type; 1063 description 1064 "Identity for point-to-multipoint IETF Network Slice 1065 connectivity."; 1066 } 1068 identity multipoint-to-multipoint { 1069 base ns-connectivity-type; 1070 description 1071 "Identity for multipoint-to-multipoint IETF Network Slice 1072 connectivity."; 1073 } 1075 identity any-to-any { 1076 base ns-connectivity-type; 1077 description 1078 "Identity for any-to-any IETF Network Slice connectivity."; 1079 } 1081 identity hub-spoke { 1082 base ns-connectivity-type; 1083 description 1084 "Identity for Hub-and-Spoke IETF Network Slice connectivity."; 1085 } 1087 identity custom { 1088 base ns-connectivity-type; 1089 description 1090 "Identity of a custom NS topology where Hubs can act as 1091 Spoke for certain parts of the network or Spokes as Hubs."; 1092 } 1094 identity endpoint-role { 1095 description 1096 "Base identity of a NSE role in an IETF Network Slice topology."; 1097 } 1099 identity any-to-any-role { 1100 base endpoint-role; 1101 description 1102 "Identity of any-to-any NS."; 1103 } 1105 identity spoke-role { 1106 base endpoint-role; 1107 description 1108 "A NSE is acting as a Spoke."; 1109 } 1110 identity hub-role { 1111 base endpoint-role; 1112 description 1113 "A NSE is acting as a Hub."; 1114 } 1116 identity ns-slo-metric-type { 1117 description 1118 "Base identity for IETF Network Slice SLO metric type."; 1119 } 1121 identity ns-slo-one-way-bandwidth { 1122 base ns-slo-metric-type; 1123 description 1124 "SLO bandwidth metric. Minimum guaranteed bandwidth between 1125 two endpoints at any time and is measured unidirectionally."; 1126 } 1128 identity ns-slo-two-way-bandwidth { 1129 base ns-slo-metric-type; 1130 description 1131 "SLO bandwidth metric. Minimum guaranteed bandwidth between 1132 two endpoints at any time."; 1133 } 1135 identity ns-slo-shared-bandwidth { 1136 base ns-slo-metric-type; 1137 description 1138 "The shared SLO bandwidth bound. It is the limit on the 1139 bandwidth that can be shared amongst a group of connections 1140 of an IETF Network Slice."; 1141 } 1143 identity ns-slo-one-way-delay { 1144 base ns-slo-metric-type; 1145 description 1146 "SLO one-way-delay is the upper bound of network delay when 1147 transmitting between two endpoints. The metric is defined in 1148 RFC7679."; 1149 } 1151 identity ns-slo-two-way-delay { 1152 base ns-slo-metric-type; 1153 description 1154 "SLO two-way delay is the upper bound of network delay when 1155 transmitting between two endpoints. The metric is defined in 1156 RFC2681."; 1157 } 1158 identity ns-slo-one-way-delay-variation { 1159 base ns-slo-metric-type; 1160 description 1161 "SLO one-way delay variation is defined by RFC3393, is the 1162 difference in the one-way delay between sequential packets 1163 between two endpoints."; 1164 } 1166 identity ns-slo-two-way-delay-variation { 1167 base ns-slo-metric-type; 1168 description 1169 "SLO two-way delay variation is defined by RFC5481, is the 1170 difference in the round-trip delay between sequential packets 1171 between two endpoints."; 1172 } 1174 identity ns-slo-one-way-packet-loss { 1175 base ns-slo-metric-type; 1176 description 1177 "SLO loss metric. The ratio of packets dropped to packets 1178 transmitted between two endpoints in one-way 1179 over a period of time as specified in RFC7680."; 1180 } 1182 identity ns-slo-two-way-packet-loss { 1183 base ns-slo-metric-type; 1184 description 1185 "SLO loss metric. The ratio of packets dropped to packets 1186 transmitted between two endpoints in two-way 1187 over a period of time as specified in RFC7680."; 1188 } 1190 identity ns-slo-availability { 1191 base ns-slo-metric-type; 1192 description 1193 "SLO availability level."; 1194 } 1196 identity ns-match-type { 1197 description 1198 "Base identity for IETF Network Slice traffic match type."; 1199 } 1201 identity ns-phy-interface-match { 1202 base ns-match-type; 1203 description 1204 "Use the physical interface as match criteria for the IETF 1205 Network Slice traffic."; 1207 } 1209 identity ns-vlan-match { 1210 base ns-match-type; 1211 description 1212 "Use the VLAN ID as match criteria for the IETF Network Slice 1213 traffic."; 1214 } 1216 identity ns-label-match { 1217 base ns-match-type; 1218 description 1219 "Use the MPLS label as match criteria for the IETF Network 1220 Slice traffic."; 1221 } 1223 identity peering-protocol-type { 1224 description 1225 "Base identity for NSE peering protocol type."; 1226 } 1228 identity peering-protocol-bgp { 1229 base peering-protocol-type; 1230 description 1231 "Use BGP as protocol for NSE peering with customer device."; 1232 } 1234 identity peering-static-routing { 1235 base peering-protocol-type; 1236 description 1237 "Use static routing for NSE peering with customer device."; 1238 } 1240 /* 1241 * Identity for availability-type 1242 */ 1244 identity availability-type { 1245 description 1246 "Base identity from which specific availability types are 1247 derived."; 1248 } 1250 identity level-1 { 1251 base availability-type; 1252 description 1253 "level 1: 99.9999%"; 1254 } 1255 identity level-2 { 1256 base availability-type; 1257 description 1258 "level 2: 99.999%"; 1259 } 1261 identity level-3 { 1262 base availability-type; 1263 description 1264 "level 3: 99.99%"; 1265 } 1267 identity level-4 { 1268 base availability-type; 1269 description 1270 "level 4: 99.9%"; 1271 } 1273 identity level-5 { 1274 base availability-type; 1275 description 1276 "level 5: 99%"; 1277 } 1279 /* typedef */ 1281 typedef operational-type { 1282 type enumeration { 1283 enum up { 1284 value 0; 1285 description 1286 "Operational status UP."; 1287 } 1288 enum down { 1289 value 1; 1290 description 1291 "Operational status DOWN."; 1292 } 1293 enum unknown { 1294 value 2; 1295 description 1296 "Operational status UNKNOWN."; 1297 } 1298 } 1299 description 1300 "This is a read-only attribute used to determine the 1301 status of a particular element."; 1302 } 1303 typedef ns-monitoring-type { 1304 type enumeration { 1305 enum one-way { 1306 description 1307 "Represents one-way measurments monitoring type."; 1308 } 1309 enum two-way { 1310 description 1311 "represents two-way measurements monitoring type."; 1312 } 1313 } 1314 description 1315 "An enumerated type for monitoring on a IETF Network Slice 1316 connection."; 1317 } 1319 /* Groupings */ 1321 grouping status-params { 1322 description 1323 "A grouping used to join operational and administrative status."; 1324 container status { 1325 description 1326 "A container for the administrative and operational state."; 1327 leaf admin-enabled { 1328 type boolean; 1329 description 1330 "The administrative status."; 1331 } 1332 leaf oper-status { 1333 type operational-type; 1334 config false; 1335 description 1336 "The operational status."; 1337 } 1338 } 1339 } 1341 grouping ns-match-criteria { 1342 description 1343 "A grouping for the IETF Network Slice match definition."; 1344 container ns-match-criteria { 1345 description 1346 "Describes the IETF Network Slice match criteria."; 1347 list ns-match-criterion { 1348 key "index"; 1349 description 1350 "List of the IETF Network Slice traffic match criteria."; 1352 leaf index { 1353 type uint32; 1354 description 1355 "The entry index."; 1356 } 1357 leaf match-type { 1358 type identityref { 1359 base ns-match-type; 1360 } 1361 description 1362 "Identifies an entry in the list of the IETF Network Slice 1363 match criteria."; 1364 } 1365 list values { 1366 key "index"; 1367 description 1368 "List of match criteria values."; 1369 leaf index { 1370 type uint8; 1371 description 1372 "Index of an entry in the list."; 1373 } 1374 leaf value { 1375 type string; 1376 description 1377 "Describes the IETF Network Slice match criteria, e.g. 1378 IP address, VLAN, etc."; 1379 } 1380 } 1381 leaf target-ns-connection-group-id { 1382 type leafref { 1383 path "/network-slices/network-slice" 1384 + "/ns-connection-groups/ns-connection-group" 1385 + "/ns-connection-group-id"; 1386 } 1387 description 1388 "reference to a Network Slice connection group."; 1389 } 1390 } 1391 } 1392 } 1394 grouping ns-sles { 1395 description 1396 "Indirectly Measurable Objectives of a IETF Network 1397 Slice."; 1398 leaf-list security { 1399 type identityref { 1400 base ns-security-type; 1401 } 1402 description 1403 "The IETF Network Slice security SLE(s)"; 1404 } 1405 leaf isolation { 1406 type identityref { 1407 base ns-isolation-type; 1408 } 1409 default "ns-isolation-shared"; 1410 description 1411 "The IETF Network Slice isolation SLE requirement."; 1412 } 1413 leaf max-occupancy-level { 1414 type uint8 { 1415 range "1..100"; 1416 } 1417 description 1418 "The maximal occupancy level specifies the number of flows to 1419 be admitted."; 1420 } 1421 leaf mtu { 1422 type uint16; 1423 units "bytes"; 1424 mandatory true; 1425 description 1426 "The MTU specifies the maximum length in octets of data 1427 packets that can be transmitted by the NS. The value needs 1428 to be less than or equal to the minimum MTU value of 1429 all 'ep-network-access-points' in the NSEs of the NS."; 1430 } 1431 container steering-constraints { 1432 description 1433 "Container for the policy of steering constraints 1434 applicable to IETF Network Slice."; 1435 container path-constraints { 1436 description 1437 "Container for the policy of path constraints 1438 applicable to IETF Network Slice."; 1439 } 1440 container service-function { 1441 description 1442 "Container for the policy of service function 1443 applicable to IETF Network Slice."; 1444 } 1445 } 1446 } 1447 grouping ns-metric-bounds { 1448 description 1449 "IETF Network Slice metric bounds grouping."; 1450 container ns-metric-bounds { 1451 description 1452 "IETF Network Slice metric bounds container."; 1453 list ns-metric-bound { 1454 key "metric-type"; 1455 description 1456 "List of IETF Network Slice metric bounds."; 1457 leaf metric-type { 1458 type identityref { 1459 base ns-slo-metric-type; 1460 } 1461 description 1462 "Identifies an entry in the list of metric type 1463 bounds for the IETF Network Slice."; 1464 } 1465 leaf metric-unit { 1466 type string; 1467 mandatory true; 1468 description 1469 "The metric unit of the parameter. For example, 1470 s, ms, ns, and so on."; 1471 } 1472 leaf value-description { 1473 type string; 1474 description 1475 "The description of previous value."; 1476 } 1477 leaf bound { 1478 type uint64; 1479 default "0"; 1480 description 1481 "The Bound on the Network Slice connection metric. A 1482 zero indicate an unbounded upper limit for the 1483 specific metric-type."; 1484 } 1485 } 1486 } 1487 } 1489 grouping ep-peering { 1490 description 1491 "A grouping for the IETF Network Slice Endpoint peering."; 1492 container ep-peering { 1493 description 1494 "Describes NSE peering attributes."; 1496 list protocol { 1497 key "protocol-type"; 1498 description 1499 "List of the NSE peering protocol."; 1500 leaf protocol-type { 1501 type identityref { 1502 base peering-protocol-type; 1503 } 1504 description 1505 "Identifies an entry in the list of NSE peering 1506 protocol type."; 1507 } 1508 list attribute { 1509 key "index"; 1510 description 1511 "List of protocol attribute."; 1512 leaf index { 1513 type uint8; 1514 description 1515 "Index of an entry in the list."; 1516 } 1517 leaf attribute-description { 1518 type string; 1519 description 1520 "The description of the attribute."; 1521 } 1522 leaf value { 1523 type string; 1524 description 1525 "Describes the value of protocol attribute, e.g. 1526 nexthop address, peer address, etc."; 1527 } 1528 } 1529 } 1530 } 1531 } 1533 grouping ep-network-access-points { 1534 description 1535 "Grouping for the endpoint network access definition."; 1536 container ep-network-access-points { 1537 description 1538 "List of network access points."; 1539 list ep-network-access-point { 1540 key "network-access-id"; 1541 description 1542 "The IETF Network Slice network access points 1543 related parameters."; 1545 leaf network-access-id { 1546 type string; 1547 description 1548 "Uniquely identifier a network access point."; 1549 } 1550 leaf network-access-description { 1551 type string; 1552 description 1553 "The network access point description."; 1554 } 1555 leaf network-access-node-id { 1556 type string; 1557 description 1558 "The network access point node ID in the case of 1559 multi-homing."; 1560 } 1561 leaf network-access-tp-id { 1562 type string; 1563 description 1564 "The termination port ID of the EP network access 1565 point."; 1566 } 1567 leaf network-access-tp-ip-address { 1568 type inet:ip-address; 1569 description 1570 "The IP address of the EP network access point."; 1571 } 1572 leaf network-access-tp-ip-prefix-length { 1573 type uint8; 1574 description 1575 "The subnet prefix length expressed in bits."; 1576 } 1577 leaf network-access-qos-policy-name { 1578 type string; 1579 description 1580 "The name of the QoS policy that is applied to the 1581 network access point. The name can reference a QoS 1582 profile that is pre-provisioned on the device."; 1583 } 1584 leaf mtu { 1585 type uint16; 1586 units "bytes"; 1587 mandatory true; 1588 description 1589 "Maximum size in octets of a data packet that 1590 can traverse a NSE network access point."; 1591 } 1592 container network-access-tags { 1593 description 1594 "Container for the network access tags."; 1595 list network-access-tag { 1596 key "index"; 1597 description 1598 "The network access point tags list."; 1599 leaf index { 1600 type uint32; 1601 description 1602 "The entry index."; 1603 } 1604 leaf network-access-tag-type { 1605 type identityref { 1606 base network-access-tag-type; 1607 } 1608 description 1609 "The network access point tag type."; 1610 } 1611 leaf network-access-tag-value { 1612 type string; 1613 description 1614 "The network access point tag value."; 1615 } 1616 } 1617 } 1618 /* Per ep-network-access-point rate limits */ 1619 uses ns-match-criteria; 1620 uses ep-peering; 1621 uses ns-rate-limit; 1622 } 1623 } 1624 } 1626 grouping ep-monitoring-metrics { 1627 description 1628 "Grouping for the NS endpoint monitoring metrics."; 1629 container ep-monitoring { 1630 config false; 1631 description 1632 "Container for NS endpoint monitoring metrics."; 1633 leaf incoming-utilized-bandwidth { 1634 type te-types:te-bandwidth; 1635 description 1636 "Incoming bandwidth utilization at an endpoint."; 1637 } 1638 leaf incoming-bw-utilization { 1639 type decimal64 { 1640 fraction-digits 5; 1641 range "0..100"; 1642 } 1643 units "percent"; 1644 mandatory true; 1645 description 1646 "To be used to define the bandwidth utilization 1647 as a percentage of the available bandwidth."; 1648 } 1649 leaf outgoing-utilized-bandwidth { 1650 type te-types:te-bandwidth; 1651 description 1652 "Outoing bandwidth utilization at an endpoint."; 1653 } 1654 leaf outgoing-bw-utilization { 1655 type decimal64 { 1656 fraction-digits 5; 1657 range "0..100"; 1658 } 1659 units "percent"; 1660 mandatory true; 1661 description 1662 "To be used to define the bandwidth utilization 1663 as a percentage of the available bandwidth."; 1664 } 1665 } 1666 } 1668 grouping ns-connection-monitoring-metrics { 1669 description 1670 "Grouping for NS connection monitoring metrics."; 1671 uses te-packet-types:one-way-performance-metrics-packet; 1672 uses te-packet-types:two-way-performance-metrics-packet; 1673 } 1675 grouping geolocation-container { 1676 description 1677 "A grouping containing a GPS location."; 1678 container location { 1679 description 1680 "A container containing a GPS location."; 1681 leaf altitude { 1682 type int64; 1683 units "millimeter"; 1684 description 1685 "Distance above the sea level."; 1686 } 1687 leaf latitude { 1688 type decimal64 { 1689 fraction-digits 8; 1690 range "-90..90"; 1691 } 1692 description 1693 "Relative position north or south on the Earth's surface."; 1694 } 1695 leaf longitude { 1696 type decimal64 { 1697 fraction-digits 8; 1698 range "-180..180"; 1699 } 1700 description 1701 "Angular distance east or west on the Earth's surface."; 1702 } 1703 } 1704 // gps-location 1705 } 1707 // geolocation-container 1709 grouping bw-rate-limits { 1710 description 1711 "Bandwidth rate limits grouping."; 1712 reference 1713 "RFC 7640: Traffic Management Benchmarking"; 1714 leaf cir { 1715 type uint64; 1716 units "bps"; 1717 description 1718 "Committed Information Rate. The maximum number of bits 1719 that a port can receive or send during one-second over an 1720 interface."; 1721 } 1722 leaf cbs { 1723 type uint64; 1724 units "bytes"; 1725 description 1726 "Committed Burst Size. CBS controls the bursty nature 1727 of the traffic. Traffic that does not use the configured 1728 CIR accumulates credits until the credits reach the 1729 configured CBS."; 1730 } 1731 leaf eir { 1732 type uint64; 1733 units "bps"; 1734 description 1735 "Excess Information Rate, i.e., excess frame delivery 1736 allowed not subject to SLA. The traffic rate can be 1737 limited by EIR."; 1738 } 1739 leaf ebs { 1740 type uint64; 1741 units "bytes"; 1742 description 1743 "Excess Burst Size. The bandwidth available for burst 1744 traffic from the EBS is subject to the amount of 1745 bandwidth that is accumulated during periods when 1746 traffic allocated by the EIR policy is not used."; 1747 } 1748 leaf pir { 1749 type uint64; 1750 units "bps"; 1751 description 1752 "Peak Information Rate, i.e., maximum frame delivery 1753 allowed. It is equal to or less than sum of CIR and EIR."; 1754 } 1755 leaf pbs { 1756 type uint64; 1757 units "bytes"; 1758 description 1759 "Peak Burst Size."; 1760 } 1761 } 1763 grouping ns-rate-limit { 1764 description 1765 "The rate limits grouping."; 1766 container incoming-rate-limits { 1767 description 1768 "Container for the asymmetric traffic control."; 1769 uses bw-rate-limits; 1770 } 1771 container outgoing-rate-limits { 1772 description 1773 "The rate-limit imposed on outgoing traffic."; 1774 uses bw-rate-limits; 1775 } 1776 } 1778 grouping endpoint { 1779 description 1780 "IETF Network Slice endpoint related information"; 1781 leaf ep-id { 1782 type string; 1783 description 1784 "Unique identifier for the referred IETF Network 1785 Slice endpoint."; 1786 } 1787 leaf ep-description { 1788 type string; 1789 description 1790 "Give more description of the Network Slice endpoint."; 1791 } 1792 uses geolocation-container; 1793 leaf node-id { 1794 type string; 1795 description 1796 "Uniquely identifies an edge node within the IETF slice 1797 network."; 1798 } 1799 leaf ep-ip { 1800 type inet:ip-address; 1801 description 1802 "The IP address of the endpoint."; 1803 } 1804 uses ns-match-criteria; 1805 uses ep-peering; 1806 uses ep-network-access-points; 1807 uses ns-rate-limit; 1808 /* Per NSE rate limits */ 1809 uses status-params; 1810 uses ep-monitoring-metrics; 1811 } 1813 //ns-endpoint 1815 grouping ns-connection { 1816 description 1817 "The network slice connection grouping."; 1818 list ns-connection { 1819 key "ns-connection-id"; 1820 description 1821 "List of Network Slice connections."; 1822 leaf ns-connection-id { 1823 type uint32; 1824 description 1825 "The Network Slice connection identifier."; 1826 } 1827 leaf ns-connectivity-type { 1828 type identityref { 1829 base ns-connectivity-type; 1830 } 1831 default "point-to-point"; 1832 description 1833 "Network Slice connection construct type."; 1834 } 1835 leaf-list src-nse { 1836 type leafref { 1837 path "/network-slices/network-slice" 1838 + "/ns-endpoints/ns-endpoint/ep-id"; 1839 } 1840 description 1841 "reference to source Network Slice endpoint."; 1842 } 1843 leaf-list dest-nse { 1844 type leafref { 1845 path "/network-slices/network-slice" 1846 + "/ns-endpoints/ns-endpoint/ep-id"; 1847 } 1848 description 1849 "reference to source Network Slice endpoint."; 1850 } 1851 uses ns-slo-sle-policy; 1852 /* Per connection ns-slo-sle-policy overrides 1853 * the per network slice ns-slo-sle-policy. 1854 */ 1855 container ns-connection-monitoring { 1856 config false; 1857 description 1858 "SLO status Per NS connection."; 1859 uses ns-connection-monitoring-metrics; 1860 } 1861 } 1862 } 1864 //ns-connection 1866 grouping ns-connection-group { 1867 description 1868 "The Network Slice connection group is described in this 1869 container."; 1870 leaf ns-connection-group-id { 1871 type string; 1872 description 1873 "The Network Slice connection group identifier."; 1874 } 1875 uses ns-slo-sle-policy; 1876 uses ns-connection; 1877 /* Per connection ns-slo-sle-policy overrides 1878 * the per network slice ns-slo-sle-policy. 1879 */ 1880 container ns-connection-group-monitoring { 1881 config false; 1882 description 1883 "SLO status Per NS connection."; 1884 uses ns-connection-monitoring-metrics; 1885 } 1886 } 1888 //ns-connection-group 1890 grouping slice-template { 1891 description 1892 "Grouping for slice-templates."; 1893 container ns-slo-sle-templates { 1894 description 1895 "Contains a set of network slice templates to 1896 reference in the IETF network slice."; 1897 list ns-slo-sle-template { 1898 key "id"; 1899 leaf id { 1900 type string; 1901 description 1902 "Identification of the Service Level Objective (SLO) 1903 and Service Level Expectation (SLE) template to be used. 1904 Local administration meaning."; 1905 } 1906 leaf template-description { 1907 type string; 1908 description 1909 "Description of the SLO & SLE policy template."; 1910 } 1911 description 1912 "List for SLO and SLE template identifiers."; 1913 } 1914 } 1915 } 1917 /* Configuration data nodes */ 1919 grouping ns-slo-sle-policy { 1920 description 1921 "Network Slice policy grouping."; 1922 choice ns-slo-sle-policy { 1923 description 1924 "Choice for SLO and SLE policy template. 1925 Can be standard template or customized template."; 1926 case standard { 1927 description 1928 "Standard SLO template."; 1930 leaf slo-sle-template { 1931 type leafref { 1932 path "/network-slices" 1933 + "/ns-slo-sle-templates/ns-slo-sle-template/id"; 1934 } 1935 description 1936 "Standard SLO and SLE template to be used."; 1937 } 1938 } 1939 case custom { 1940 description 1941 "Customized SLO template."; 1942 container slo-sle-policy { 1943 description 1944 "Contains the SLO policy."; 1945 leaf policy-description { 1946 type string; 1947 description 1948 "Description of the SLO policy."; 1949 } 1950 uses ns-metric-bounds; 1951 uses ns-sles; 1952 } 1953 } 1954 } 1955 } 1957 container network-slices { 1958 description 1959 "Containes a list of IETF network slice"; 1960 uses slice-template; 1961 list network-slice { 1962 key "ns-id"; 1963 description 1964 "A network-slice is identified by a ns-id."; 1965 leaf ns-id { 1966 type string; 1967 description 1968 "A unique network-slice identifier across an IETF NSC."; 1969 } 1970 leaf ns-description { 1971 type string; 1972 description 1973 "Give more description of the network slice."; 1974 } 1975 container ns-tags { 1976 description 1977 "Container for the list of IETF Network Slice tags."; 1979 list ns-tag { 1980 key "index"; 1981 description 1982 "IETF Network Slice tag list."; 1983 leaf index { 1984 type uint32; 1985 description 1986 "The entry index."; 1987 } 1988 leaf ns-tag-type { 1989 type identityref { 1990 base ns-tag-type; 1991 } 1992 description 1993 "The IETF Network Slice tag type."; 1994 } 1995 leaf ns-tag-value { 1996 type string; 1997 description 1998 "The IETF Network Slice tag value."; 1999 } 2000 } 2001 } 2002 uses ns-slo-sle-policy; 2003 uses status-params; 2004 container ns-endpoints { 2005 description 2006 "NS Endpoints."; 2007 list ns-endpoint { 2008 key "ep-id"; 2009 uses endpoint; 2010 description 2011 "List of endpoints in this slice."; 2012 } 2013 } 2014 container ns-connection-groups { 2015 description 2016 "Contains NS connections group."; 2017 list ns-connection-group { 2018 key "ns-connection-group-id"; 2019 description 2020 "List of Network Slice connections."; 2021 uses ns-connection-group; 2022 } 2023 } 2024 } 2025 //ietf-network-slice list 2026 } 2028 } 2029 2031 9. Security Considerations 2033 The YANG module defined in this document is designed to be accessed 2034 via network management protocols such as NETCONF [RFC6241] or 2035 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 2036 layer, and the mandatory-to-implement secure transport is Secure 2037 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 2038 mandatory-to-implement secure transport is TLS [RFC8446]. 2040 The NETCONF access control model [RFC8341] provides the means to 2041 restrict access for particular NETCONF or RESTCONF users to a 2042 preconfigured subset of all available NETCONF or RESTCONF protocol 2043 operations and content. 2045 There are a number of data nodes defined in this YANG module that are 2046 writable/creatable/deletable (i.e., config true, which is the 2047 default). These data nodes may be considered sensitive or vulnerable 2048 in some network environments. Write operations (e.g., edit-config) 2049 to these data nodes without proper protection can have a negative 2050 effect on network operations. 2052 o /ietf-network-slice/network-slices/network-slice 2054 The entries in the list above include the whole network 2055 configurations corresponding with the slice which the higher 2056 management system requests, and indirectly create or modify the PE or 2057 P device configurations. Unexpected changes to these entries could 2058 lead to service disruption and/or network misbehavior. 2060 10. IANA Considerations 2062 This document registers a URI in the IETF XML registry [RFC3688]. 2063 Following the format in [RFC3688], the following registration is 2064 requested to be made: 2066 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 2067 Registrant Contact: The IESG. 2068 XML: N/A, the requested URI is an XML namespace. 2070 This document requests to register a YANG module in the YANG Module 2071 Names registry [RFC7950]. 2073 Name: ietf-network-slice 2074 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 2075 Prefix: ietf-ns 2076 Reference: RFC XXXX 2078 11. Acknowledgments 2080 The authors wish to thank Mohamed Boucadair, John Mullooly, Kenichi 2081 Ogaki, Sergio Belotti, Qin Wu, Susan Hares, Eric Grey, and many 2082 others for their helpful comments and suggestions. 2084 12. Contributors 2086 The following authors contributed significantly to this document: 2088 Luis M. Contreras 2089 Telefonica 2090 Spain 2092 Email: luismiguel.contrerasmurillo@telefonica.com 2094 13. References 2096 13.1. Normative References 2098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2099 Requirement Levels", BCP 14, RFC 2119, 2100 DOI 10.17487/RFC2119, March 1997, 2101 . 2103 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2104 DOI 10.17487/RFC3688, January 2004, 2105 . 2107 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2108 and A. Bierman, Ed., "Network Configuration Protocol 2109 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2110 . 2112 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2113 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2114 . 2116 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2117 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2118 . 2120 [RFC7640] Constantine, B. and R. Krishnan, "Traffic Management 2121 Benchmarking", RFC 7640, DOI 10.17487/RFC7640, September 2122 2015, . 2124 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2125 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2126 . 2128 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2129 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2130 . 2132 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2133 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2134 May 2017, . 2136 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2137 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2138 . 2140 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2141 Access Control Model", STD 91, RFC 8341, 2142 DOI 10.17487/RFC8341, March 2018, 2143 . 2145 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2146 and R. Wilton, "Network Management Datastore Architecture 2147 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2148 . 2150 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2151 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2152 . 2154 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 2155 E., and A. Tripathy, "Dynamic Subscription to YANG Events 2156 and Datastores over NETCONF", RFC 8640, 2157 DOI 10.17487/RFC8640, September 2019, 2158 . 2160 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 2161 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 2162 September 2019, . 2164 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2165 "Common YANG Data Types for Traffic Engineering", 2166 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2167 . 2169 13.2. Informative References 2171 [I-D.geng-teas-network-slice-mapping] 2172 Geng, X., Dong, J., Pang, R., Han, L., Rokui, R., Niwa, 2173 T., Jin, J., Liu, C., and N. Nageshar, "5G End-to-end 2174 Network Slice Mapping from the view of Transport Network", 2175 Work in Progress, Internet-Draft, draft-geng-teas-network- 2176 slice-mapping-04, 25 October 2021, 2177 . 2180 [I-D.ietf-opsawg-vpn-common] 2181 Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A 2182 Common YANG Data Model for Layer 2 and Layer 3 VPNs", Work 2183 in Progress, Internet-Draft, draft-ietf-opsawg-vpn-common- 2184 12, 29 September 2021, . 2187 [I-D.ietf-teas-actn-vn-yang] 2188 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 2189 Yoon, "A YANG Data Model for VN Operation", Work in 2190 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-13, 2191 23 October 2021, . 2194 [I-D.ietf-teas-ietf-network-slices] 2195 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 2196 Makhijani, K., Contreras, L. M., and J. Tantsura, 2197 "Framework for IETF Network Slices", Work in Progress, 2198 Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 2199 October 2021, . 2202 [I-D.liu-teas-transport-network-slice-yang] 2203 Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu, 2204 Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG 2205 Data Model", Work in Progress, Internet-Draft, draft-liu- 2206 teas-transport-network-slice-yang-04, 9 July 2021, 2207 . 2210 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2211 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2212 . 2214 Appendix A. IETF Network Slice Service Model Usage Example 2216 The following example describes a simplified service configuration of 2217 two IETF Network slice instances: 2219 * IETF Network Slice 1 on PE1, PE2, and PE3, with two NS-connection- 2220 groups 2222 +----+ VLAN100 2223 | o------/ 2224 | | | +------+ 2225 | DU1| +------o| PE1 +---------------+ 2226 | o-------/-----o| | | 2227 +----+ VLAN200 +---+--+ | 2228 VLAN300 | | +-----+ 2229 | +---+--+ | | 2230 | | o-----/-----o | 2231 | | PE3o-----/-----o CU1 | 2232 +----+ | +---+--+ | | 2233 | o------/ | | +-----+ 2234 | | | +---+--+ | 2235 | DU2| +------o| PE2 +---------------+ 2236 | o-------/-----o| | 2237 +----+ +------+ 2239 POST: /restconf/data/ietf-network-slice:ietf-network-slices 2240 Host: example.com 2241 Content-Type: application/yang-data+json 2242 { 2243 "ietf-network-slice:network-slices": { 2244 "network-slice": [ 2245 { 2246 "ns-id": "NS1", 2247 "ns-description": "URLLC", 2248 "ns-tags": { 2249 "ns-tag": [ 2250 { 2251 "index": 1, 2252 "ns-tag-type": "ns-tag-customer", 2253 "ns-tag-value": "FOO" 2254 }, 2255 { 2256 "index": 2, 2257 "ns-tag-type": "ns-tag-customer", 2258 "ns-tag-value": "BAR" 2259 }, 2260 { 2261 "index": 3, 2262 "ns-tag-type": "ns-tag-service", 2263 "ns-tag-value": "L2" 2264 } 2265 ] 2266 }, 2267 "status": { 2268 "admin-enabled": true, 2269 "oper-status": "up" 2270 }, 2271 "ns-endpoints": { 2272 "ns-endpoint": [ 2273 { 2274 "ep-id": "DU1", 2275 "ep-description": "DU1 at location X", 2276 "ep-ip": "1.1.1.1", 2277 "ns-match-criteria": { 2278 "ns-match-criterion": [ 2279 { 2280 "index": 0, 2281 "match-type": "ns-vlan-match", 2282 "values": [ 2283 { 2284 "index": 1, 2285 "value": "VLAN-100" 2286 } 2287 ], 2288 "target-ns-connection-group-id": "Matrix1" 2289 }, 2290 { 2291 "index": 1, 2292 "match-type": "ns-vlan-match", 2293 "values": [ 2294 { 2295 "index": 1, 2296 "value": "VLAN-200" 2297 }, 2298 { 2299 "index": 2, 2300 "value": "VLAN-300" 2301 } 2302 ], 2303 "target-ns-connection-group-id": "Matrix2" 2304 } 2305 ] 2306 }, 2307 "ep-network-access-points": { 2308 "ep-network-access-point": [ 2309 { 2310 "network-access-id": "AC1-VRF100", 2311 "network-access-description": "VRF100 to PE1", 2312 "network-access-node-id": "PE1", 2313 "network-access-tp-id": "1", 2314 "network-access-tp-ip-address": "192.0.1.2", 2315 "network-access-tp-ip-prefix-length": 24, 2316 "network-access-qos-policy-name": "QoS-Gold", 2317 "network-access-tags": { 2318 "network-access-tag": [ 2319 { 2320 "index": 1, 2321 "network-access-tag-type": "network-access-tag-vlan-id", 2322 "network-access-tag-value": "100" 2323 }, 2324 { 2325 "index": 2, 2326 "network-access-tag-type": "network-access-tag-vrf-id", 2327 "network-access-tag-value": "FOO" 2328 } 2329 ] 2330 }, 2331 "ep-peering": { 2332 "protocol": [ 2333 { 2334 "protocol-type": "peering-protocol-bgp", 2335 "attribute": [ 2336 { 2337 "index": 1, 2338 "value": "COLOR:10" 2339 }, 2340 { 2341 "index": 2, 2342 "value": "RT:20" 2343 }, 2344 { 2345 "index": 3, 2346 "value": "RT:30" 2347 } 2348 ] 2349 } 2350 ] 2351 }, 2352 "incoming-rate-limits": { 2353 "cir": "1000000", 2354 "cbs": "1000", 2355 "pir": "5000000", 2356 "pbs": "1000" 2358 } 2359 }, 2360 { 2361 "network-access-id": "AC2-VRF200", 2362 "network-access-description": "VRF200 to PE1", 2363 "network-access-node-id": "PE1", 2364 "network-access-tp-id": "2", 2365 "network-access-tp-ip-address": "192.0.2.2", 2366 "network-access-tp-ip-prefix-length": 24, 2367 "network-access-qos-policy-name": "QoS-Gold", 2368 "network-access-tags": { 2369 "network-access-tag": [ 2370 { 2371 "index": 1, 2372 "network-access-tag-type": "network-access-tag-vlan-id", 2373 "network-access-tag-value": "100" 2374 }, 2375 { 2376 "index": 2, 2377 "network-access-tag-type": "network-access-tag-vrf-id", 2378 "network-access-tag-value": "FOO" 2379 } 2380 ] 2381 }, 2382 "ep-peering": { 2383 "protocol": [ 2384 { 2385 "protocol-type": "peering-protocol-bgp", 2386 "attribute": [ 2387 { 2388 "index": 1, 2389 "value": "COLOR:10" 2390 }, 2391 { 2392 "index": 2, 2393 "value": "RT:20" 2394 }, 2395 { 2396 "index": 3, 2397 "value": "RT:30" 2398 } 2399 ] 2400 } 2401 ] 2402 }, 2403 "incoming-rate-limits": { 2404 "cir": "1000000", 2405 "cbs": "1000", 2406 "pir": "5000000", 2407 "pbs": "1000" 2408 } 2409 } 2410 ] 2411 } 2412 }, 2413 { 2414 "ep-id": "DU2", 2415 "ep-description": "DU2 at location Y", 2416 "ep-ip": "2.2.2.2", 2417 "ep-network-access-points": { 2418 "ep-network-access-point": [ 2419 { 2420 "network-access-id": "AC1-VRF100", 2421 "network-access-description": "VRF100 to PE2", 2422 "network-access-node-id": "PE2", 2423 "network-access-tp-id": "1", 2424 "network-access-tp-ip-address": "192.1.1.2", 2425 "network-access-tp-ip-prefix-length": 24, 2426 "network-access-qos-policy-name": "QoS-Gold", 2427 "ep-peering": { 2428 "protocol": [ 2429 { 2430 "protocol-type": "peering-protocol-bgp", 2431 "attribute": [ 2432 { 2433 "index": 1, 2434 "value": "COLOR:10" 2435 }, 2436 { 2437 "index": 2, 2438 "value": "RT:20" 2439 }, 2440 { 2441 "index": 3, 2442 "value": "RT:30" 2443 } 2444 ] 2445 } 2446 ] 2447 }, 2448 "incoming-rate-limits": { 2449 "cir": "1000000", 2450 "cbs": "1000", 2451 "pir": "5000000", 2452 "pbs": "1000" 2453 } 2455 }, 2456 { 2457 "network-access-id": "AC2-VRF200", 2458 "network-access-description": "VRF200 to PE1", 2459 "network-access-node-id": "PE2", 2460 "network-access-tp-id": "2", 2461 "network-access-tp-ip-address": "192.1.2.2", 2462 "network-access-tp-ip-prefix-length": 24, 2463 "network-access-qos-policy-name": "QoS-Gold", 2464 "ep-peering": { 2465 "protocol": [ 2466 { 2467 "protocol-type": "peering-protocol-bgp", 2468 "attribute": [ 2469 { 2470 "index": 1, 2471 "value": "COLOR:10" 2472 }, 2473 { 2474 "index": 2, 2475 "value": "RT:20" 2476 }, 2477 { 2478 "index": 3, 2479 "value": "RT:30" 2480 } 2481 ] 2482 } 2483 ] 2484 }, 2485 "incoming-rate-limits": { 2486 "cir": "1000000", 2487 "cbs": "1000", 2488 "pir": "5000000", 2489 "pbs": "1000" 2490 } 2491 } 2492 ] 2493 } 2494 }, 2495 { 2496 "ep-id": "CU1", 2497 "ep-description": "CU1 at location Z", 2498 "ep-ip": "3.3.3.3", 2499 "ep-network-access-points": { 2500 "ep-network-access-point": [ 2501 { 2502 "network-access-id": "AC1-VRF100", 2503 "network-access-description": "VRF100 to PE2", 2504 "network-access-node-id": "PE3", 2505 "network-access-tp-id": "1", 2506 "network-access-tp-ip-address": "192.2.1.2", 2507 "network-access-tp-ip-prefix-length": 24, 2508 "network-access-qos-policy-name": "QoS-Gold", 2509 "ep-peering": { 2510 "protocol": [ 2511 { 2512 "protocol-type": "peering-protocol-bgp", 2513 "attribute": [ 2514 { 2515 "index": 1, 2516 "value": "COLOR:10" 2517 }, 2518 { 2519 "index": 2, 2520 "value": "RT:20" 2521 }, 2522 { 2523 "index": 3, 2524 "value": "RT:30" 2525 } 2526 ] 2527 } 2528 ] 2529 }, 2530 "incoming-rate-limits": { 2531 "cir": "1000000", 2532 "cbs": "1000", 2533 "pir": "5000000", 2534 "pbs": "1000" 2535 } 2536 }, 2537 { 2538 "network-access-id": "AC2-VRF200", 2539 "network-access-description": "VRF200 to PE1", 2540 "network-access-node-id": "PE3", 2541 "network-access-tp-id": "2", 2542 "network-access-tp-ip-address": "192.2.2.2", 2543 "network-access-tp-ip-prefix-length": 24, 2544 "network-access-qos-policy-name": "QoS-Gold", 2545 "ep-peering": { 2546 "protocol": [ 2547 { 2548 "protocol-type": "peering-protocol-bgp", 2549 "attribute": [ 2550 { 2551 "index": 1, 2552 "value": "COLOR:10" 2553 }, 2554 { 2555 "index": 2, 2556 "value": "RT:20" 2557 }, 2558 { 2559 "index": 3, 2560 "value": "RT:30" 2561 } 2562 ] 2563 } 2564 ] 2565 }, 2566 "incoming-rate-limits": { 2567 "cir": "1000000", 2568 "cbs": "1000", 2569 "pir": "5000000", 2570 "pbs": "1000" 2571 } 2572 } 2573 ] 2574 } 2575 } 2576 ] 2577 }, 2578 "ns-connection-groups": { 2579 "ns-connection-group": [ 2580 { 2581 "ns-connection-group-id": "Matrix1", 2582 "slo-sle-policy": { 2583 "policy-description": "URLLC-SLAs-Template1", 2584 "ns-metric-bounds": { 2585 "ns-metric-bound": [ 2586 { 2587 "metric-type": "ns-slo-shared-bandwidth", 2588 "metric-unit": "Gbps", 2589 "value-description": "Shared banwidth for Matrix1 connections", 2590 "bound": "15" 2591 }, 2592 { 2593 "metric-type": "ns-slo-one-way-bandwidth", 2594 "metric-unit": "Gbps", 2595 "value-description": "One-way banwidth for Matrix3 connections", 2596 "bound": "10" 2597 }, 2598 { 2599 "metric-type": "ns-slo-one-way-delay", 2600 "metric-unit": "msec", 2601 "value-description": "One-way delay for Matrix3 connections" 2602 }, 2603 { 2604 "metric-type": "ns-slo-one-way-delay-variation", 2605 "metric-unit": "msec", 2606 "value-description": "One-way delay variation for Matrix3 connections" 2607 } 2608 ] 2609 } 2610 }, 2611 "ns-connection": [ 2612 { 2613 "ns-connection-id": 1, 2614 "src-nse": [ 2615 "DU1" 2616 ], 2617 "dest-nse": [ 2618 "CU1" 2619 ], 2620 "slo-sle-policy": { 2621 "ns-metric-bounds": { 2622 "ns-metric-bound": [ 2623 { 2624 "metric-type": "ns-slo-one-way-delay", 2625 "metric-unit": "msec", 2626 "bound": "20" 2627 } 2628 ] 2629 } 2630 } 2631 }, 2632 { 2633 "ns-connection-id": 2, 2634 "src-nse": [ 2635 "DU2" 2636 ], 2637 "dest-nse": [ 2638 "CU1" 2639 ] 2640 } 2641 ] 2642 }, 2643 { 2644 "ns-connection-group-id": "Matrix2", 2645 "slo-sle-template": "URLLC-SLAs-Template2", 2646 "ns-connection": [ 2647 { 2648 "ns-connection-id": 1, 2649 "src-nse": [ 2650 "DU1" 2651 ], 2652 "dest-nse": [ 2653 "CU1" 2654 ] 2655 }, 2656 { 2657 "ns-connection-id": 2, 2658 "src-nse": [ 2659 "DU2" 2660 ], 2661 "dest-nse": [ 2662 "CU1" 2663 ] 2664 } 2665 ] 2666 } 2667 ] 2668 } 2669 }, 2670 { 2671 "ns-id": "NS2", 2672 "status": { 2673 "admin-enabled": true, 2674 "oper-status": "up" 2675 } 2676 } 2677 ] 2678 } 2679 } 2681 Appendix B. Comparison with Other Possible Design choices for IETF 2682 Network Slice Service Interface 2684 According to the 5.3.1 IETF Network Slice Service Interface 2685 [I-D.ietf-teas-ietf-network-slices], the Network Slice service 2686 Interface is a technology-agnostic interface, which is used for a 2687 customer to express requirements for a particular IETF Network Slice. 2688 Customers operate on abstract IETF Network Slices, with details 2689 related to their realization hidden. As classified by [RFC8309], the 2690 Network Slice service Interface is classified as Customer Service 2691 Model. 2693 This draft analyzes the following existing IETF models to identify 2694 the gap between the IETF Network Slice service Interface 2695 requirements. 2697 B.1. ACTN VN Model Augmentation 2699 The difference between the ACTN VN model and the IETF Network Slice 2700 service requirements is that the IETF Network Slice service interface 2701 is a technology-agnostic interface, whereas the VN model is bound to 2702 the IETF TE Topologies. The realization of the IETF Network Slice 2703 does not necessarily require the slice network to support the TE 2704 technology. 2706 The ACTN VN (Virtual Network) model introduced 2707 in[I-D.ietf-teas-actn-vn-yang] is the abstract customer view of the 2708 TE network. Its YANG structure includes four components: 2710 * VN: A Virtual Network (VN) is a network provided by a service 2711 provider to a customer for use and two types of VN has defined. 2712 The Type 1 VN can be seen as a set of edge-to-edge abstract links. 2713 Each link is an abstraction of the underlying network which can 2714 encompass edge points of the customer's network, access links, 2715 intra-domain paths, and inter-domain links. 2717 * AP: An AP is a logical identifier used to identify the access link 2718 which is shared between the customer and the IETF scoped Network. 2720 * VN-AP: A VN-AP is a logical binding between an AP and a given VN. 2722 * VN-member: A VN-member is an abstract edge-to-edge link between 2723 any two APs or VN-APs. Each link is formed as an E2E tunnel 2724 across the underlying networks. 2726 The Type 1 VN can be used to describe IETF Network Slice connection 2727 requirements. However, the Network Slice SLO and Network Slice 2728 Endpoint are not clearly defined and there's no direct equivalent. 2729 For example, the SLO requirement of the VN is defined through the 2730 IETF TE Topologies YANG model, but the TE Topologies model is related 2731 to a specific implementation technology. Also, VN-AP does not define 2732 "network-slice-match-criteria" to specify a specific NSE belonging to 2733 an IETF Network Slice. 2735 B.2. RFC8345 Augmentation Model 2737 The difference between the IETF Network Slice service requirements 2738 and the IETF basic network model is that the IETF Network Slice 2739 service requests abstract customer IETF Network Slices, with details 2740 related to the slice Network hidden. But the IETF network model is 2741 used to describe the interconnection details of a Network. The 2742 customer service model does not need to provide details on the 2743 Network. 2745 For example, IETF Network Topologies YANG data model extension 2746 introduced in Transport Network Slice YANG Data Model 2747 [I-D.liu-teas-transport-network-slice-yang] includes three major 2748 parts: 2750 * Network: a transport network list and an list of nodes contained 2751 in the network 2753 * Link: "links" list and "termination points" list describe how 2754 nodes in a network are connected to each other 2756 * Support network: vertical layering relationships between IETF 2757 Network Slice networks and underlay networks 2759 Based on this structure, the IETF Network Slice-specific SLO 2760 attributes nodes are augmented on the Network Topologies model,, e.g. 2761 isolation etc. However, this modeling design requires the slice 2762 network to expose a lot of details of the network, such as the actual 2763 topology including nodes interconnection and different network layers 2764 interconnection. 2766 Appendix C. Appendix B IETF Network Slice Match Criteria 2768 5G is a use case of the IETF Network Slice and 5G End-to-end Network 2769 Slice Mapping from the view of IETF 2770 Network[I-D.geng-teas-network-slice-mapping] 2772 defines two types of Network Slice interconnection and 2773 differentiation methods: by physical interface or by TNSII (Transport 2774 Network Slice Interworking Identifier). TNSII is a field in the 2775 packet header when different 5G wireless network slices are 2776 transported through a single physical interfaces of the IETF scoped 2777 Network. In the 5G scenario, "network-slice-match-criteria" refers 2778 to TNSII. 2780 +------------------------------------------------------------+ 2781 | 5G E2E network slice orchestrator | 2782 ++-----------------------------------------------------+-----+ 2783 | | | 2784 | IETF Network Slice service model | 2785 +---+-------+ | +-----+-----+ 2786 | | +------------------+ | | 2787 |RAN Slice | |IETF Network Slice| |Core Slice | 2788 |controller | | controller | | controller| 2789 +----+------+ +-------+----------+ +-----+-----+ 2790 | | | 2791 | | | 2792 +---+--+ +------------+----------------+ ++-----+ 2793 | | | | | | 2794 | | | | | | 2795 |+----+| | | | | 2796 || ||NS1-NSE1 | Network Slice 1 | |+----+| 2797 ||gNB1|+---------+-----+-----------------------+--------+|UPF1|| 2798 || |+************ / |NS1-NSE3|+----+| 2799 |+----+|NS2-NSE1 | */ | | | 2800 | | /* | | | 2801 |+----+|NS1-NSE2 | / * | | | 2802 || |+---------- * Network Slice 2 |NS2-NSE3|+----+| 2803 ||gNB2|+************************************************+|UPF2|| 2804 || ||NS2-NSE2 | | |+----+| 2805 |+----+| | | | 2806 | | | | | | 2807 | | | | | | 2808 +------+ +----------- -----------------+ +------+ 2810 As shown in the figure, gNodeB 1 and gNodeB 2 use IP gNB1 and IP gNB2 2811 to communicate with the IETF network, respectively. In addition, the 2812 traffic of NS1 and NS2 on gNodeB 1 and gNodeB 2 is transmitted 2813 through the same access links to the IETF slice network. The IETF 2814 slice network need to to distinguish different IETF Network Slice 2815 traffic of same gNB. Therefore, in addition to using "node-id" and 2816 "ep-ip" to identify a Network Slice Endpont, other information is 2817 needed along with these parameters to uniquely distinguish a NSE. 2818 For example, VLAN IDs in the user traffic can be used to distinguish 2819 the NSEs of gNBs and UPFs. 2821 Authors' Addresses 2822 Bo Wu 2823 Huawei Technologies 2824 101 Software Avenue, Yuhua District 2825 Nanjing 2826 Jiangsu, 210012 2827 China 2828 Email: lana.wubo@huawei.com 2830 Dhruv Dhody 2831 Huawei Technologies 2832 Divyashree Techno Park 2833 Bangalore 560066 2834 Karnataka 2835 India 2836 Email: dhruv.ietf@gmail.com 2838 Reza Rokui 2839 Ciena 2840 Email: rrokui@ciena.com 2842 Tarek Saad 2843 Juniper Networks 2844 Email: tsaad@juniper.net 2846 Liuyan Han 2847 China Mobile 2848 Email: hanliuyan@chinamobile.com