idnits 2.17.1 draft-wd-teas-ietf-network-slice-nbi-yang-03.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 3 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...' == Line 322 has weird spacing: '...w index uin...' == 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 (July 9, 2021) is 1022 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) == Outdated reference: A later version (-05) exists of draft-geng-teas-network-slice-mapping-03 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-11 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-00 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-02 Summary: 1 error (**), 0 flaws (~~), 8 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: January 10, 2022 R. Rokui 6 Nokia 7 T. Saad 8 Juniper Networks 9 L. Han 10 China Mobile 11 July 9, 2021 13 A Yang Data Model for IETF Network Slice NBI 14 draft-wd-teas-ietf-network-slice-nbi-yang-03 16 Abstract 18 This document provides a YANG data model for the IETF Network Slice 19 Controller (NSC) Northbound Interface (NBI). The model can be used 20 by a IETF Network Slice customer to request configuration, and 21 management IETF Network Slice services from the IETF 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 January 10, 2022. 40 Copyright Notice 42 Copyright (c) 2021 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 60 3. IETF Network Slice NBI Model Usage . . . . . . . . . . . . . 4 61 4. IETF Network Slice NBI Model Overview . . . . . . . . . . . . 5 62 5. IETF Network Slice Templates . . . . . . . . . . . . . . . . 9 63 6. IETF Network Slice Modeling Description . . . . . . . . . . . 10 64 6.1. IETF Network Slice Connectivity Type . . . . . . . . . . 11 65 6.2. IETF Network Slice SLO and SLE Policy . . . . . . . . . . 11 66 6.3. IETF Network Slice Endpoint (NSE) . . . . . . . . . . . . 13 67 7. IETF Network Slice Monitoring . . . . . . . . . . . . . . . . 16 68 8. IETF Network Slice NBI Module . . . . . . . . . . . . . . . . 17 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 74 12.2. Informative References . . . . . . . . . . . . . . . . . 38 75 Appendix A. IETF Network Slice NBI Model Usage Example . . . . . 39 76 Appendix B. Comparison with Other Possible Design choices for 77 IETF Network Slice NBI . . . . . . . . . . . . . . . 42 78 B.1. ACTN VN Model Augmentation . . . . . . . . . . . . . . . 42 79 B.2. RFC8345 Augmentation Model . . . . . . . . . . . . . . . 43 80 Appendix C. Appendix B IETF Network Slice Match Criteria . . . . 43 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 83 1. Introduction 85 This document provides a YANG [RFC7950] data model for the IETF 86 Network Slice NBI. 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 Slice during the IETF Network Slice instantiation. This YANG 92 model supports various operations on IETF Network Slices such as 93 creation, modification, deletion, and monitoring of IETF Network 94 Slices. 96 The IETF Network Slice Controller (NSC) provides a Northbound 97 Interface (NBI) that allows customers of network slices to request 98 and monitor IETF network slices. 100 The NBI carries information that the IETF network slice customer 101 provides, describing generic requirements of connectivity, service 102 level objectives (SLO), etc. and also monitoring and reporting 103 requirements that may apply. It is an abstract interface that hides 104 excessive technology-related information which may then be realized 105 using some technology-specific Southbound Interface (SBI) by the NSC. 107 The YANG model discussed in this document describes the requirements 108 of an IETF Network Slice from the point of view of the customer, 109 which is classified as Customer Service Model in [RFC8309]. 111 It will be up to the management system or NSC to take this model as 112 an input and use other management system or specific configuration 113 models to configure the different network elements to deliver an IETF 114 Network Slice. The YANG models can be used with network management 115 protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The 116 details of how the IETF network slices are realized by the NSC is out 117 of scope for this document. 119 The IETF Network Slice operational state is included in the same tree 120 as the configuration consistent with Network Management Datastore 121 Architecture [RFC8342]. 123 2. Conventions used in this document 125 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 The following terms are defined in [RFC6241] and are used in this 132 specification: 134 o client 136 o configuration data 138 o state data 140 This document makes use of the following terminology introduced in 141 the YANG 1.1 Data Modeling Language [RFC7950]: 143 o augment 144 o data model 146 o data node 148 This document also makes use of the terms introduced in the Framework 149 for IETF Network Slices [I-D.ietf-teas-ietf-network-slices]: 151 o NBI: Northbound Interface 153 o NS: IETF Network Slice 155 o NSC: IETF Network Slice Controller 157 o NSE: Network Slice Endpoint 159 o SLO: Service Level Objective 161 o SLE: Service Level Expectation 163 This document defines the following term: 165 o IETF Network Slice Connection (NS-Connection): In the context of 166 an IETF Network Slice, an IETF NS-Connection is an abstract entity 167 which represents a particular connection between a pair of NSEs. 168 An IETF Network Slice can has one or multiple NS-Connections. 170 2.1. Tree Diagrams 172 Tree diagrams used in this document follow the notation defined in 173 [RFC8340]. 175 3. IETF Network Slice NBI Model Usage 177 The intention of the IETF Network Slice NBI model is to allow the 178 customer, e.g. a higher-level management system, to request and 179 monitor IETF Network Slices. In particular, the model allows 180 customers to operate on abstract and technology-agnostic manner, with 181 details of the IETF Network Slices realization hidden. 183 According to the [I-D.ietf-teas-ietf-network-slices] description, the 184 NBI model is applicable to use cases such as (but not limited to) 185 network wholesale services, network infrastructure sharing among 186 operators, NFV connectivity, Data Center Interconnect, and 5G E2E 187 network slice. 189 As shown in Figure 1, in all these use-cases, the NBI model is used 190 by the higher management system to communicate with IETF Network 191 Slice controller for life cycle manage of IETF Network Slices 192 including both enablement and monitoring. For example, in 5G E2E 193 network slicing use-case the E2E network slice orchestrator acts as 194 the higher layer system to request the IETF Network Slices. The 195 interface is used to support dynamic IETF Network Slice creation and 196 its lifecycle management to facilitate end-to-end network slice 197 services. 199 +----------------------------------------+ 200 | IETF Network Slice Customer | 201 | | 202 +----------------+-----------------------+ 203 | 204 | 205 |IETF Network Slice NBI YANG 206 | 207 +---------------------+--------------------------+ 208 | IETF Network Slice Controller (NSC) | 209 +------------------------------------------------+ 211 Figure 1: IETF Network Slice NBI Model Context 213 4. IETF Network Slice NBI Model Overview 215 As defined in [I-D.ietf-teas-ietf-network-slices], an IETF network 216 slice is a logical network connecting a number of endpoints with 217 specified SLOs. The connectivity type can be Hub-and-Spoke, any-to- 218 any, or custom connectivity type. In addition, a minimum set of SLOs 219 is defined, including but not limited to bandwidth, latency, and etc. 220 An example of an IETF network slice is shown in Figure 2 . 222 +----------------------------------------------+ 223 | | 224 NSE1 O------------------+ | 225 . +---------------------------O NSE2 226 . | . 227 . | Any-to-Any . 228 . | . 229 . +---------------------------O NSEn 230 NSEm O------------------+ | 231 | | 232 +----------------------------------------------+ 234 | | 235 |<-----------An IETF Network Slice ---------->| 236 | between endpoints NSE1 to NSEn | 238 Legend: 239 NSE: IETF Network Slice Endpoint 240 O: Represents IETF Network Slice Endpoints 242 Figure 2: An IETF Network Slice Example 244 [I-D.ietf-teas-ietf-network-slices] introduces the IETF network slice 245 endpoints (NSEs) which are conceptual points of connection to IETF 246 network slice. As such, they are ingress/egress point where the 247 traffic enters/exits the IETF network slice. In other words, they 248 are the edge of the IETF network slices. 250 When IETF network slice controller (NSC) receives a message via its 251 NBI for creation/modification of an IETF network slice, it uses the 252 provided IETF network slice endpoints to map them to appropriate 253 services/tunnels/paths endpoints in the underlay IETF network. It 254 then uses services/tunnels/paths endpoints to realize the IETF 255 network slice. 257 The IETF Network Slice ("ietf-network-slice") is defined to manage 258 network slices in the IETF network. In particular, the 'ietf- 259 network-slice' module can be used to create, modify, and monitor 260 network slices of an IETF network. 262 The 'ietf-network-slice' module uses two main nodes: list 'ietf- 263 network-slice' and container 'ns-templates' (see Figure 3). 265 The 'ietf-network-slice' list includes the set of IETF Network slices 266 managed within IETF network. 'ietf-network-slice' is the data 267 structure that abstracts an IETF Network Slice. Under the "ietf- 268 network-slice", list "ns-endpoint" is used to abstract the NSEs, e.g. 269 NSEs in the example above. 271 The 'ns-templates' container is used by the NSC to maintain a set of 272 common network slice templates that apply to one or several IETF 273 Network Slices. 275 The figure below describes the overall structure of the YANG module: 277 module: ietf-network-slice 278 +--rw network-slices 279 +--rw ns-slo-sle-templates 280 | +--rw ns-slo-sle-template* [id] 281 | +--rw id string 282 | +--rw template-description? string 283 +--rw network-slice* [ns-id] 284 +--rw ns-id string 285 +--rw ns-description? string 286 +--rw ns-tag* string 287 +--rw ns-connectivity-type? identityref 288 +--rw (ns-slo-sle-policy)? 289 | +--:(standard) 290 | | +--rw slo-sle-template? leafref 291 | +--:(custom) 292 | +--rw slo-policy 293 | | +--rw policy-description? string 294 | | +--rw ns-metric-bounds 295 | | +--rw ns-metric-bound* [metric-type] 296 | | +--rw metric-type identityref 297 | | +--rw metric-unit string 298 | | +--rw value-description? string 299 | | +--rw bound? uint64 300 | +--rw sle-policies 301 | +--rw security-sle* identityref 302 | +--rw isolation? identityref 303 | +--rw max-occupancy-level? uint8 304 +--rw status 305 | +--rw admin-enabled? boolean 306 | +--ro oper-status? operational-type 307 +--rw ns-endpoints 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-criterion* [match-type] 320 | | +--rw match-type identityref 321 | | +--rw values* [index] 322 | | +--rw index uint8 323 | | +--rw value? string 324 | +--rw ep-network-access-points 325 | | +--rw ep-network-access-point* [network-access-id] 326 | | +--rw network-access-id string 327 | | +--rw network-access-description? string 328 | | +--rw network-access-node-id? string 329 | | +--rw network-access-tp-id? string 330 | | +--rw network-access-tp-ip? inet:host 331 | | +--rw ep-rate-limit 332 | | +--rw incoming-rate-limit? 333 | | | te-types:te-bandwidth 334 | | +--rw outgoing-rate-limit? 335 | | te-types:te-bandwidth 336 | +--rw ep-rate-limit 337 | | +--rw incoming-rate-limit? te-types:te-bandwidth 338 | | +--rw outgoing-rate-limit? te-types:te-bandwidth 339 | +--rw ep-protocol 340 | +--rw status 341 | | +--rw admin-enabled? boolean 342 | | +--ro oper-status? operational-type 343 | +--ro ep-monitoring 344 | +--ro incoming-utilized-bandwidth? 345 | | te-types:te-bandwidth 346 | +--ro incoming-bw-utilization decimal64 347 | +--ro outgoing-utilized-bandwidth? 348 | | te-types:te-bandwidth 349 | +--ro outgoing-bw-utilization decimal64 350 +--rw ns-connections 351 +--rw ns-connection* [ns-connection-id] 352 +--rw ns-connection-id uint32 353 +--rw ns-connection-description? string 354 +--rw src 355 | +--rw src-ep-id? leafref 356 +--rw dest 357 | +--rw dest-ep-id? leafref 358 +--rw (ns-slo-sle-policy)? 359 | +--:(standard) 360 | | +--rw slo-sle-template? leafref 361 | +--:(custom) 362 | +--rw slo-policy 363 | | +--rw policy-description? string 364 | | +--rw ns-metric-bounds 365 | | +--rw ns-metric-bound* [metric-type] 366 | | +--rw metric-type identityref 367 | | +--rw metric-unit string 368 | | +--rw value-description? string 369 | | +--rw bound? uint64 370 | +--rw sle-policies 371 | +--rw security-sle* identityref 372 | +--rw isolation? identityref 373 | +--rw max-occupancy-level? uint8 374 +--rw monitoring-type? ns-monitoring-type 375 +--ro ns-connection-monitoring 376 +--ro latency? yang:gauge64 377 +--ro jitter? yang:gauge32 378 +--ro loss-ratio? decimal64 380 Figure 3 382 5. IETF Network Slice Templates 384 The 'ns-templates' container (Figure 3) is used by service provider 385 of the NSC to define and maintain a set of common IETF Network Slice 386 templates that apply to one or several IETF Network Slices. The 387 exact definition of the templates is deployment specific to each 388 network provider. 390 The model includes only the identifiers of SLO and SLE templates. 391 When creation of IETF Network slice, the SLO and SLE policies can be 392 easily identified. 394 The following shows an example where two network slice templates can 395 be retrieved by the upper layer management system: 397 { 398 "ietf-network-slices": { 399 "ns-templates": { 400 "slo-sle-template": [ 401 { 402 "id":"GOLD-template", 403 "template-description": "Two-way bandwidth: 1 Gbps, 404 one-way latency 100ms " 405 "sle-isolation":"ns-isolation-shared", 406 }, 407 { 408 "id":"PLATINUM-template", 409 "template-description": "Two-way bandwidth: 1 Gbps, 410 one-way latency 50ms " 411 "sle-isolation":"ns-isolation-dedicated", 412 }, 413 ], 414 } 415 } 416 } 418 6. IETF Network Slice Modeling Description 420 The 'ietf-network-slice' is the data structure that abstracts an IETF 421 Network Slice of the IETF network. Each 'ietf-network-slice' is 422 uniquely identified by an identifier: 'ns-id'. 424 An IETF Network Slice has the following main parameters: 426 o "ns-id": Is an identifier that is used to uniquely identify the 427 IETF Network Slice within NSC. 429 o "ns-description": Gives some description of an IETF Network Slice 430 service. 432 o "ns-connectivity-type": Indicates the network connectivity type 433 for the IETF Network Slice: Hub-and-Spoke, any-to-any, or custom 434 type. 436 o "status": Is used to show the operative and administrative status 437 of the IETF Network Slice, and can be used as indicator to detect 438 network slice anomalies. 440 o "ns-tag": Is used to show the correlation between higher level 441 function and the IETF network slices. If provided, this parameter 442 may be used by IETF Network Slice Controller (NSC) during the 443 realization. It may also be used by NSC for monitoring and 444 assurance of the IETF network slices where NSC can notify the 445 higher system by issuing the notifications. It is noted that a 446 single higher level customer might have multiple IETF Network 447 Slices for a single application. This attribute may be used by 448 NSC to also correlated multiple IETF network slices for a single 449 application. 451 o "ns-slo-sle-policy": Defines SLO and SLE policies for the "ietf- 452 network-slice". More description are provided in Section 6.2 454 The "ns-endpoint" is an abstrac entity that represents a set of 455 matching rules applied to an IETF network edge device or a customer 456 network edge device involved in the IETF Network Slice and each 'ns- 457 endpoint' belongs to a single 'ietf-network-slice'. More description 458 are provided in Section 6.3 460 6.1. IETF Network Slice Connectivity Type 462 Based on the customer's traffic pattern requirements, an IETF Network 463 Slice connection type could be point-to-point (P2P), point-to- 464 multipoint (P2MP), multipoint-to-point (MP2P), or multipoint-to- 465 multipoint (MP2MP). The "ns-connectivity-type" under the node "ietf- 466 network-slice" is used for this. 468 For the connectivity requirements, the model proposes to support any- 469 to-any, Hub-and-Spoke (where Hubs can exchange traffic), and the 470 custom. By default, the any-to-any is used. New connectivity type 471 could be added via augmentation or by list of 'ns-connection' 472 specified. 474 In addition, "ep-role" under the node "ns-endpoint" also needs to be 475 defined, which specifies the role of the NSE in a particular Network 476 Slice connectivity type. In the any-to-any, all NSEs MUST have the 477 same role, which will be "any-to-any-role". In the Hub-and-Spoke, 478 NSEs MUST have a Hub role or a Spoke role. 480 6.2. IETF Network Slice SLO and SLE Policy 482 As defined in [I-D.ietf-teas-ietf-network-slices], the SLO policy of 483 an IETF Network Slice defines the minimum IETF Network Slice SLO 484 attributes, and additional attributes can be added as needed. 486 "ns-slo-sle-policy" is used to represent specific SLO and SLE 487 policies. During the creation of an IETF Network Slice, the policy 488 can be specified either by a standard SLO and SLO template or a 489 customized SLO and SLE policy. 491 The policy could both apply one per Network Slice or per connection 492 'ns-connection'. 494 The model allows multiple SLO and SLE attributes to be combined to 495 meet different SLO and SLE requirements. For example, some NSs are 496 used for video services and require high bandwidth, some NSs are used 497 for key business services and request low latency and reliability, 498 and some NSs need to provide connections for a large number of NSEs. 499 That is, not all SLO or SLE attributes must be specified to meet the 500 particular requirements of a slice. 502 "ns-metric-bounds" contains all these variations, which includes a 503 list of "ns-metric-bound" and each "ns-metric-bound" could specify a 504 particular "metric-type". "metric-type" is defined with YANG identity 505 and the YANG module supports the following options: 507 "ns-slo-one-way-bandwidth": Indicates the guaranteed minimum 508 bandwidth between any two NSE. And the bandwidth is 509 unidirectional. 511 "ns-slo-two-way-bandwidth": Indicates the guaranteed minimum 512 bandwidth between any two NSE. And the bandwidth is 513 bidirectional. 515 "network-slice-slo-one-way-latency": Indicates the maximum one-way 516 latency between two NSE. 518 "network-slice-slo-two-way-latency": Indicates the maximum round- 519 trip latency between two NSE. 521 "ns-slo-one-way-delay-variation": Indicates the jitter constraint 522 of the slice maximum permissible delay variation, and is measured 523 by the difference in the one-way latency between sequential 524 packets in a flow. 526 "ns-slo-two-way-delay-variation": Indicates the jitter constraint 527 of the slice maximum permissible delay variation, and is measured 528 by the difference in the two-way latency between sequential 529 packets in a flow. 531 "ns-slo-one-way-packet-loss": Indicates maximum permissible packet 532 loss rate, which is defined by the ratio of packets dropped to 533 packets transmitted between two endpoints. 535 "ns-slo-two-way-packet-loss": Indicates maximum permissible packet 536 loss rate, which is defined by the ratio of packets dropped to 537 packets transmitted between two endpoints. 539 "ns-slo-availability": Is defined as the ratio of up-time to 540 total_time(up-time+down-time), where up-time is the time the IETF 541 Network Slice is available in accordance with the SLOs associated 542 with it. 544 Some other Network Slice SLOs or SLEs could be extended when needed. 546 The following shows an example where a network slice policy can be 547 configured: 549 { 550 "ietf-network-slices": { 551 "ietf-network-slice": { 552 "slo-policy": { 553 "policy-description":"video-service-policy", 554 "ns-metric-bounds": { 555 "ns-metric-bound": [ 556 { 557 "metric-type": "ns-slo-one-way-bandwidth", 558 "metric-unit": "mbps" 559 "bound": "1000" 560 }, 561 { 562 "metric-type": "ns-slo-availability", 563 "bound": "99.9%" 564 }, 565 ], 566 } 567 } 568 } 569 } 570 } 572 6.3. IETF Network Slice Endpoint (NSE) 574 An IETF Network Slice Endpoint has several characteristics: 576 o "ep-id": Uniquely identifies the NSE within Network Slice 577 Controller (NSC). The identifier is a string that allows any 578 encoding for the local administration of the IETF Network Slice. 580 o "location": Indicates NSE location information that facilities NSC 581 easy identification of a NSE. 583 o "ep-role": Represents a connectivity type role of a NSE belonging 584 to an IETF network slice, as described in Section 6.1. The "ep- 585 role" leaf defines the role of the endpoint in a particular NS 586 connectivity type. In the any-to-any, all NSEs MUST have the same 587 role, which will be "any-to-any-role". 589 o "node-id": The NSE node information facilities NSC with easy 590 identification of a NSE. 592 o "ep-ip": The NSE IP information facilities NSC with easy 593 identification of a NSE. 595 o "ns-match-criteria": A matching policies to apply on a given NSE. 597 o "ep-network-access-points": The list of the interfaces attached to 598 an edge device of the IETF Network Slice by which the customer 599 traffic is received. 601 o "ep-rate-limit": Set the rate-limiting policies to apply on a 602 given NSE, including ingress and egress traffic to ensure access 603 security. When applied in the incoming direction, the rate-limit 604 is applicable to the traffic from the NSE to the IETF scope 605 Network that passes through the external interface. When 606 Bandwidth is applied to the outgoing direction, it is applied to 607 the traffic from the IETF Network to the NSE of that particular 608 NS. 610 o "ep-protocol": Specify the protocol for a NSE for exchanging 611 control-plane information, e.g. L1 signaling protocol or L3 612 routing protocols,etc. 614 o "status": Enable the control of the operative and administrative 615 status of the NSE, can be used as indicator to detect NSE 616 anomalies. 618 An NSE belong to a single IETF Network Slice. An IETF Network Slice 619 involves two or more NSEs. An IETF Network Slice can be modified by 620 adding new "ns-endpoint" or removing existing "ns-endpoint". 622 A NSE is used to define the matching rule on the customer traffic 623 that can be injected to an IETF Network Slice. "network-slice-match- 624 criteria" is defined to support different options. Classification 625 can be based on many criteria, such as: 627 o Physical interface: Indicates all the traffic received from the 628 interface belongs to the IETF Network Slice. 630 o Logical interface: For example, a given VLAN ID is used to 631 identify an IETF Network Slice. 633 o Encapsulation in the traffic header: For example, a source IP 634 address is used to identify an IETF Network Slice. 636 To illustrate the use of NSE parameters, the below are two examples. 637 How the NSC realize the mapping is out of scope for this document. 639 o NSE mapping to PE example: As shown in Figure 4 , customer of the 640 IETF network slice would like to connect two NSEs to satisfy 641 specific service, e.g., Network wholesale services. In this case, 642 the IETF network slice endpoints are mapped to physical interfaces 643 of PE nodes. The IETF network slice controller (NSC) uses 'node- 644 id' (PE device ID), 'ep-network-access-points' (Two PE interfaces 645 ) to map the interfaces and corresponding services/tunnels/paths. 647 NSE1 NSE2 648 (With PE1 parameters) (with PE2 parameters) 649 o<--------- IETF Network Slice 1 ------->o 650 + | | + 651 + |<----------- S1 ----------->| + 652 + | | + 653 + | |<------ T1 ------>| | + 654 + v v v v + 655 + +----+ +----+ + 656 +-----+ | | PE1|==================| PE2| +-----+ 657 | |----------X | | | | | | 658 | | | | | | X----------| | 659 | |----------X | | | | | | 660 +-----+ | | |==================| | | +-----+ 661 AC +----+ +----+ AC 662 Customer Provider Provider Customer 663 Edge 1 Edge 1 Edge 2 Edge 2 665 Legend: 666 O: Representation of the IETF network slice endpoints (NSE) 667 +: Mapping of NES to PE or CE nodes on IETF network 668 X: Physical interfaces used for realization of IETF network slice 669 S1: L0/L1/L2/L3 services used for realization of IETF network slice 670 T1: Tunnels used for realization of IETF network slice 672 Figure 4 674 o NSE mapping to CE-PE interface example: As shown in Figure 5 , 675 customer of the IETF network slice would like to connect two NSEs 676 to provide connectivity between transport portion of 5G RAN to 5G 677 Core network functions. In this scenario, the IETF network slice 678 endpoints (NSE) might be mapped to the respective PE-CE interface 679 (see 3GPP TS 28.541 V17.1.0 section 6.3.17 EP_Transport). The 680 IETF network slice controller (NSC) uses 'node-id' (CE device ID) 681 , 'ep-ip' (CE tunnel endpoint IP), 'network-slice-match-criteria' 682 (VLAN interface), 'ep-network-access-points' (Two nexthop 683 interfaces ) to map underlay services/tunnels/paths. 685 NSE3 NSE4 686 (With CE1 parameters) (with CE2 parameters) 687 o<--------- IETF Network Slice 2 ------->o 688 + | | + 689 + |<----------- S2 ----------->| + 690 + | | + 691 + | |<------ T2 ------>| | + 692 + v v v v + 693 AC +----+ +----+ AC 694 +-----+ | | PE1|==================| PE2| | +-----+ 695 | |----------X | | | | | | 696 | | | | | | X----------| | 697 | |----------X | | | | | | 698 +-----+ | | |==================| | | +-----+ 699 AC +----+ +----+ AC 700 Customer Provider Provider Customer 701 Edge 1 Edge 1 Edge 2 Edge 2 703 Legend: 704 O: Representation of the IETF network slice endpoints (NSE) 705 +: Mapping of NSE to PE or CE-PE interfaces on IETF network 706 X: Physical interfaces used for realization of IETF network slice 707 S2: L0/L1/L2/L3 services used for realization of IETF network slice 708 T2: Tunnels used for realization of IETF network slice 710 Figure 5 712 7. IETF Network Slice Monitoring 714 An IETF Network Slice is a connectivity with specific SLO 715 characteristics, including bandwidth, latency, etc. The connectivity 716 is a combination of logical unidirectional connections, represented 717 by 'ns-connection'. 719 This model also describes performance status of an IETF Network 720 Slice. The statistics are described in the following granularity: 722 o Per NS connection: specified in 'ns-connection-monitoring' under 723 the "ns-connection" 725 o Per NS Endpoint: specified in 'ep-monitoring' under the "ns- 726 endpoint" 728 This model does not define monitoring enabling methods. The 729 mechanism defined in [RFC8640] and [RFC8641] can be used for either 730 periodic or on-demand subscription. 732 By specifying subtree filters or xpath filters to 'ns-connection' or 733 'ns-endpoint' ,so that only interested contents will be sent. These 734 mechanisms can be used for monitoring the IETF Network Slice 735 performance status so that the customer management system could 736 initiate modification based on the IETF Network Slice running status. 738 8. IETF Network Slice NBI Module 740 The "ietf-network-slice" module uses types defined in [RFC6991], 741 [RFC8776]. 743 file "ietf-network-slice@2021-07-06.yang" 744 module ietf-network-slice { 745 yang-version 1.1; 746 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 747 prefix ietf-ns; 749 import ietf-inet-types { 750 prefix inet; 751 reference 752 "RFC 6991: Common YANG Types."; 753 } 754 import ietf-yang-types { 755 prefix yang; 756 reference 757 "RFC 6991: Common YANG Types."; 758 } 759 import ietf-te-types { 760 prefix te-types; 761 reference 762 "RFC 8776: Common YANG Data Types for Traffic Engineering."; 763 } 765 organization 766 "IETF Traffic Engineering Architecture and Signaling (TEAS) 767 Working Group"; 768 contact 769 "WG Web: 770 WG List: 771 Editor: Bo Wu 772 : Dhruv Dhody 773 : Reza Rokui 774 : Tarek Saad "; 775 description 776 "This module contains a YANG module for the IETF Network Slice. 778 Copyright (c) 2021 IETF Trust and the persons identified as 779 authors of the code. All rights reserved. 781 Redistribution and use in source and binary forms, with or 782 without modification, is permitted pursuant to, and subject to 783 the license terms contained in, the Simplified BSD License set 784 forth in Section 4.c of the IETF Trust's Legal Provisions 785 Relating to IETF Documents 786 (http://trustee.ietf.org/license-info). 788 This version of this YANG module is part of RFC XXXX; see the 789 RFC itself for full legal notices."; 791 revision 2021-07-06 { 792 description 793 "initial version."; 794 reference 795 "RFC XXXX: A Yang Data Model for IETF Network Slice Operation"; 796 } 798 /* Features */ 799 /* Identities */ 801 identity ns-isolation-type { 802 description 803 "Base identity for IETF Network slice isolation level."; 804 } 806 identity ns-isolation-shared { 807 base ns-isolation-type; 808 description 809 "Shared resources (e.g. queues) are associated with the Network 810 Slice traffic. Hence, the IETF network slice traffic can be 811 impacted by effects of other services traffic sharing 812 the same resources."; 813 } 815 identity ns-isolation-dedicated { 816 base ns-isolation-type; 817 description 818 "Dedicated resources (e.g. queues) are associated with the Network 819 Slice traffic. Hence, the IETF network slice traffic is isolated 820 from other servceis traffic sharing the same resources."; 821 } 823 identity ns-security-type { 824 description 825 "Base identity for for IETF Network security level."; 826 } 828 identity ns-security-authenticate { 829 base ns-security-type; 830 description 831 "IETF Network Slice requires authentication."; 832 } 834 identity ns-security-integrity { 835 base ns-security-type; 836 description 837 "IETF Network Slice requires data integrity."; 838 } 840 identity ns-security-encryption { 841 base ns-security-type; 842 description 843 "IETF Network Slice requires data encryption."; 844 } 846 identity ns-connectivity-type { 847 description 848 "Base identity for IETF Network Slice topology."; 849 } 851 identity any-to-any { 852 base ns-connectivity-type; 853 description 854 "Identity for any-to-any IETF Network Slice topology."; 855 } 857 identity hub-spoke { 858 base ns-connectivity-type; 859 description 860 "Identity for Hub-and-Spoke IETF Network Slice topology."; 861 } 863 identity custom { 864 base ns-connectivity-type; 865 description 866 "Identity of a custom NS topology where Hubs can act as 867 Spoke for certain parts of the network or Spokes as Hubs."; 868 } 870 identity endpoint-role { 871 description 872 "Base identity of a NSE role in an IETF Network Slice topology."; 873 } 875 identity any-to-any-role { 876 base endpoint-role; 877 description 878 "Identity of any-to-any NS."; 879 } 881 identity spoke-role { 882 base endpoint-role; 883 description 884 "A NSE is acting as a Spoke."; 885 } 887 identity hub-role { 888 base endpoint-role; 889 description 890 "A NSE is acting as a Hub."; 891 } 893 identity custom-role { 894 base endpoint-role; 895 description 896 "A NSE is custom role in the NS."; 897 } 899 identity ns-slo-metric-type { 900 description 901 "Base identity for IETF Network Slice SLO metric type."; 902 } 904 identity ns-slo-one-way-bandwidth { 905 base ns-slo-metric-type; 906 description 907 "SLO bandwidth metric. Minimum guaranteed bandwidth between 908 two endpoints at any time and is measured unidirectionally"; 909 } 911 identity ns-slo-two-way-bandwidth { 912 base ns-slo-metric-type; 913 description 914 "SLO bandwidth metric. Minimum guaranteed bandwidth between 915 two endpoints at any time"; 916 } 918 identity ns-slo-one-way-latency { 919 base ns-slo-metric-type; 920 description 921 "SLO one-way latency is upper bound of network latency when 922 transmitting between two endpoints. The metric is defined in 923 RFC7679"; 924 } 926 identity ns-slo-two-way-latency { 927 base ns-slo-metric-type; 928 description 929 "SLO two-way latency is upper bound of network latency when 930 transmitting between two endpoints. The metric is defined in 931 RFC2681"; 932 } 934 identity ns-slo-one-way-delay-variation { 935 base ns-slo-metric-type; 936 description 937 "SLO one-way delay variation is defined by RFC3393, is the 938 difference in the one-way delay between sequential packets 939 between two endpoints."; 940 } 942 identity ns-slo-two-way-delay-variation { 943 base ns-slo-metric-type; 944 description 945 "SLO two-way delay variation is defined by RFC5481, is the 946 difference in the round-trip delay between sequential packets 947 between two endpoints."; 948 } 950 identity ns-slo-one-way-packet-loss { 951 base ns-slo-metric-type; 952 description 953 "SLO loss metric. The ratio of packets dropped to packets 954 transmitted between two endpoints in one-way 955 over a period of time as specified in RFC7680"; 956 } 958 identity ns-slo-two-way-packet-loss { 959 base ns-slo-metric-type; 960 description 961 "SLO loss metric. The ratio of packets dropped to packets 962 transmitted between two endpoints in two-way 963 over a period of time as specified in RFC7680"; 964 } 966 identity ns-slo-availability { 967 base ns-slo-metric-type; 968 description 969 "SLO availability level."; 970 } 972 identity ns-match-type { 973 description 974 "Base identity for IETF Network Slice traffic match type."; 975 } 977 identity ns-phy-interface-match { 978 base ns-match-type; 979 description 980 "Use the physical interface as match criteria for the IETF 981 Network Slice traffic."; 982 } 984 identity ns-vlan-match { 985 base ns-match-type; 986 description 987 "Use the VLAN ID as match criteria for the IETF Network Slice 988 traffic."; 989 } 991 identity ns-label-match { 992 base ns-match-type; 993 description 994 "Use the MPLS label as match criteria for the IETF Network 995 Slice traffic."; 996 } 998 /* 999 * Identity for availability-type 1000 */ 1002 identity availability-type { 1003 description 1004 "Base identity from which specific availability types are 1005 derived."; 1006 } 1008 identity level-1 { 1009 base availability-type; 1010 description 1011 "level 1: 99.9999%"; 1012 } 1014 identity level-2 { 1015 base availability-type; 1016 description 1017 "level 2: 99.999%"; 1018 } 1020 identity level-3 { 1021 base availability-type; 1022 description 1023 "level 3: 99.99%"; 1024 } 1026 identity level-4 { 1027 base availability-type; 1028 description 1029 "level 4: 99.9%"; 1030 } 1032 identity level-5 { 1033 base availability-type; 1034 description 1035 "level 5: 99%"; 1036 } 1038 /* typedef */ 1040 typedef operational-type { 1041 type enumeration { 1042 enum up { 1043 value 0; 1044 description 1045 "Operational status UP."; 1046 } 1047 enum down { 1048 value 1; 1049 description 1050 "Operational status DOWN."; 1051 } 1052 enum unknown { 1053 value 2; 1054 description 1055 "Operational status UNKNOWN."; 1056 } 1057 } 1058 description 1059 "This is a read-only attribute used to determine the 1060 status of a particular element."; 1061 } 1063 typedef ns-monitoring-type { 1064 type enumeration { 1065 enum one-way { 1066 description 1067 "Represents one-way measurments monitoring type."; 1068 } 1069 enum two-way { 1070 description 1071 "represents two-way measurements monitoring type."; 1072 } 1073 } 1074 description 1075 "An enumerated type for monitoring on a IETF Network Slice 1076 connection."; 1077 } 1079 /* Groupings */ 1081 grouping status-params { 1082 description 1083 "A grouping used to join operational and administrative status."; 1084 container status { 1085 description 1086 "A container for the administrative and operational state."; 1087 leaf admin-enabled { 1088 type boolean; 1089 description 1090 "The administrative status."; 1091 } 1092 leaf oper-status { 1093 type operational-type; 1094 config false; 1095 description 1096 "The operational status."; 1097 } 1098 } 1099 } 1101 grouping ns-match-criteria { 1102 description 1103 "A grouping for the IETF Network Slice match definition."; 1104 container ns-match-criteria { 1105 description 1106 "Describes the IETF Network Slice match criteria."; 1107 list ns-match-criterion { 1108 key "match-type"; 1109 description 1110 "List of the IETF Network Slice traffic match criteria."; 1111 leaf match-type { 1112 type identityref { 1113 base ns-match-type; 1114 } 1115 description 1116 "Identifies an entry in the list of the IETF Network Slice 1117 match criteria."; 1118 } 1119 list values { 1120 key "index"; 1121 description 1122 "List of match criteria values."; 1123 leaf index { 1124 type uint8; 1125 description 1126 "Index of an entry in the list."; 1127 } 1128 leaf value { 1129 type string; 1130 description 1131 "Describes the IETF Network Slice match criteria, e.g. 1132 IP address, VLAN, etc."; 1133 } 1134 } 1135 } 1136 } 1137 } 1139 grouping ns-connection-group-metric-bounds { 1140 description 1141 "Grouping of Network Slice metric bounds that 1142 are shared amongst multiple connections of a Network 1143 Slice."; 1144 leaf ns-slo-shared-bandwidth { 1145 type te-types:te-bandwidth; 1146 description 1147 "A limit on the bandwidth that is shared amongst 1148 multiple connections of an IETF Network Slice."; 1149 } 1150 } 1152 grouping ns-sles { 1153 description 1154 "Indirectly Measurable Objectives of a IETF Network 1155 Slice."; 1156 container sle-policies { 1157 description 1158 "Container for the policy of SLEs applicable to 1159 IETF Network Slice."; 1161 leaf-list security-sle { 1162 type identityref { 1163 base ns-security-type; 1164 } 1165 description 1166 "The IETF Network Slice security SLE(s)"; 1167 } 1168 leaf isolation { 1169 type identityref { 1170 base ns-isolation-type; 1171 } 1172 default "ns-isolation-shared"; 1173 description 1174 "The IETF Network Slice isolation SLE requirement."; 1175 } 1176 leaf max-occupancy-level { 1177 type uint8 { 1178 range "1..100"; 1179 } 1180 description 1181 "The maximal occupancy level specifies the number of flows to 1182 be admitted."; 1183 } 1184 } 1185 } 1187 grouping ns-metric-bounds { 1188 description 1189 "IETF Network Slice metric bounds grouping."; 1190 container ns-metric-bounds { 1191 description 1192 "IETF Network Slice metric bounds container."; 1193 list ns-metric-bound { 1194 key "metric-type"; 1195 description 1196 "List of IETF Network Slice metric bounds."; 1197 leaf metric-type { 1198 type identityref { 1199 base ns-slo-metric-type; 1200 } 1201 description 1202 "Identifies an entry in the list of metric type 1203 bounds for the IETF Network Slice."; 1204 } 1205 leaf metric-unit { 1206 type string; 1207 mandatory true; 1208 description 1209 "The metric unit of the parameter. For example, 1210 s, ms, ns, and so on."; 1211 } 1212 leaf value-description { 1213 type string; 1214 description 1215 "The description of previous value. "; 1216 } 1217 leaf bound { 1218 type uint64; 1219 default "0"; 1220 description 1221 "The Bound on the Network Slice connection metric. A 1222 zero indicate an unbounded upper limit for the 1223 specific metric-type."; 1224 } 1225 } 1226 } 1227 } 1229 grouping ep-network-access-points { 1230 description 1231 "Grouping for the endpoint network access definition."; 1232 container ep-network-access-points { 1233 description 1234 "List of network access points."; 1235 list ep-network-access-point { 1236 key "network-access-id"; 1237 description 1238 "The IETF Network Slice network access points 1239 related parameters."; 1240 leaf network-access-id { 1241 type string; 1242 description 1243 "Uniquely identifier a network access point."; 1244 } 1245 leaf network-access-description { 1246 type string; 1247 description 1248 "The network access point description."; 1249 } 1250 leaf network-access-node-id { 1251 type string; 1252 description 1253 "The network access point node ID in the case of 1254 multi-homing."; 1255 } 1256 leaf network-access-tp-id { 1257 type string; 1258 description 1259 "The termination port ID of the EP network access 1260 point."; 1261 } 1262 leaf network-access-tp-ip { 1263 type inet:host; 1264 description 1265 "The IP address of the EP network access point."; 1266 } 1267 /* Per ep-network-access-point rate limits */ 1268 uses ns-rate-limit; 1269 } 1270 } 1271 } 1273 grouping endpoint-monitoring-parameters { 1274 description 1275 "Grouping for the endpoint monitoring parameters."; 1276 container ep-monitoring { 1277 config false; 1278 description 1279 "Container for endpoint monitoring parameters."; 1280 leaf incoming-utilized-bandwidth { 1281 type te-types:te-bandwidth; 1282 description 1283 "Incoming bandwidth utilization at an endpoint."; 1284 } 1285 leaf incoming-bw-utilization { 1286 type decimal64 { 1287 fraction-digits 5; 1288 range "0..100"; 1289 } 1290 units "percent"; 1291 mandatory true; 1292 description 1293 "To be used to define the bandwidth utilization 1294 as a percentage of the available bandwidth."; 1295 } 1296 leaf outgoing-utilized-bandwidth { 1297 type te-types:te-bandwidth; 1298 description 1299 "Outgoing bandwidth utilization at an endpoint."; 1300 } 1301 leaf outgoing-bw-utilization { 1302 type decimal64 { 1303 fraction-digits 5; 1304 range "0..100"; 1306 } 1307 units "percent"; 1308 mandatory true; 1309 description 1310 "To be used to define the bandwidth utilization 1311 as a percentage of the available bandwidth."; 1312 } 1313 } 1314 } 1316 grouping common-monitoring-parameters { 1317 description 1318 "Grouping for link-monitoring-parameters."; 1319 leaf latency { 1320 type yang:gauge64; 1321 units "usec"; 1322 description 1323 "The latency statistics per Network Slice connection. 1324 RFC2681 and RFC7679 discuss round trip times and one-way 1325 metrics, respectively"; 1326 } 1327 leaf jitter { 1328 type yang:gauge32; 1329 description 1330 "The jitter statistics per Network Slice member 1331 as defined by RFC3393."; 1332 } 1333 leaf loss-ratio { 1334 type decimal64 { 1335 fraction-digits 6; 1336 range "0 .. 50.331642"; 1337 } 1338 description 1339 "Packet loss as a percentage of the total traffic 1340 sent over a configurable interval. The finest precision is 1341 0.000003%. where the maximum 50.331642%."; 1342 reference 1343 "RFC 7810, section-4.4"; 1344 } 1345 } 1347 grouping geolocation-container { 1348 description 1349 "A grouping containing a GPS location."; 1350 container location { 1351 description 1352 "A container containing a GPS location."; 1353 leaf altitude { 1354 type int64; 1355 units "millimeter"; 1356 description 1357 "Distance above the sea level."; 1358 } 1359 leaf latitude { 1360 type decimal64 { 1361 fraction-digits 8; 1362 range "-90..90"; 1363 } 1364 description 1365 "Relative position north or south on the Earth's surface."; 1366 } 1367 leaf longitude { 1368 type decimal64 { 1369 fraction-digits 8; 1370 range "-180..180"; 1371 } 1372 description 1373 "Angular distance east or west on the Earth's surface."; 1374 } 1375 } 1376 // gps-location 1377 } 1379 // geolocation-container 1381 grouping ns-rate-limit { 1382 description 1383 "The Network Slice rate limit grouping."; 1384 container ep-rate-limit { 1385 description 1386 "Container for the asymmetric traffic control"; 1387 leaf incoming-rate-limit { 1388 type te-types:te-bandwidth; 1389 description 1390 "The rate-limit imposed on incoming traffic."; 1391 } 1392 leaf outgoing-rate-limit { 1393 type te-types:te-bandwidth; 1394 description 1395 "The rate-limit imposed on outgoing traffic."; 1396 } 1397 } 1398 } 1400 grouping endpoint { 1401 description 1402 "IETF Network Slice endpoint related information"; 1403 leaf ep-id { 1404 type string; 1405 description 1406 "unique identifier for the referred IETF Network 1407 Slice endpoint"; 1408 } 1409 leaf ep-description { 1410 type string; 1411 description 1412 "endpoint name"; 1413 } 1414 leaf ep-role { 1415 type identityref { 1416 base endpoint-role; 1417 } 1418 default "any-to-any-role"; 1419 description 1420 "Role of the endpoint in the IETF Network Slice."; 1421 } 1422 uses geolocation-container; 1423 leaf node-id { 1424 type string; 1425 description 1426 "Uniquely identifies an edge node within the IETF slice 1427 network."; 1428 } 1429 leaf ep-ip { 1430 type inet:host; 1431 description 1432 "The address of the endpoint IP address."; 1433 } 1434 uses ns-match-criteria; 1435 uses ep-network-access-points; 1436 uses ns-rate-limit; 1437 /* Per NSE rate limits */ 1438 container ep-protocol { 1439 description 1440 "Describes protocol for the Network Slice Endpoint."; 1441 } 1442 uses status-params; 1443 uses endpoint-monitoring-parameters; 1444 } 1446 //ns-endpoint 1448 grouping ns-connection { 1449 description 1450 "The Network Slice connection is described in this container."; 1451 leaf ns-connection-id { 1452 type uint32; 1453 description 1454 "The Network Slice connection identifier"; 1455 } 1456 leaf ns-connection-description { 1457 type string; 1458 description 1459 "The Network Slice connection description"; 1460 } 1461 container src { 1462 description 1463 "the source of Network Slice link"; 1464 leaf src-ep-id { 1465 type leafref { 1466 path "/network-slices/network-slice" 1467 + "/ns-endpoints/ns-endpoint/ep-id"; 1468 } 1469 description 1470 "reference to source Network Slice endpoint"; 1471 } 1472 } 1473 container dest { 1474 description 1475 "the destination of Network Slice link "; 1476 leaf dest-ep-id { 1477 type leafref { 1478 path "/network-slices/network-slice" 1479 + "/ns-endpoints/ns-endpoint/ep-id"; 1480 } 1481 description 1482 "reference to dest Network Slice endpoint"; 1483 } 1484 } 1485 uses ns-slo-sle-policy; 1486 /* Per connection ns-slo-sle-policy overrides 1487 * the per network slice ns-slo-sle-policy. 1488 */ 1489 leaf monitoring-type { 1490 type ns-monitoring-type; 1491 description 1492 "One way or two way monitoring type."; 1493 } 1494 container ns-connection-monitoring { 1495 config false; 1496 description 1497 "SLO status Per network-slice endpoint to endpoint "; 1499 uses common-monitoring-parameters; 1500 } 1501 } 1503 //ns-connection 1505 grouping slice-template { 1506 description 1507 "Grouping for slice-templates."; 1508 container ns-slo-sle-templates { 1509 description 1510 "Contains a set of network slice templates to 1511 reference in the IETF network slice."; 1512 list ns-slo-sle-template { 1513 key "id"; 1514 leaf id { 1515 type string; 1516 description 1517 "Identification of the Service Level Objective (SLO) 1518 and Service Level Expectation (SLE) template to be used. 1519 Local administration meaning."; 1520 } 1521 leaf template-description { 1522 type string; 1523 description 1524 "Description of the SLO & SLE policy template."; 1525 } 1526 description 1527 "List for SLO and SLE template identifiers."; 1528 } 1529 } 1530 } 1532 /* Configuration data nodes */ 1534 grouping ns-slo-sle-policy { 1535 description 1536 "Network Slice policy grouping."; 1537 choice ns-slo-sle-policy { 1538 description 1539 "Choice for SLO and SLE policy template. 1540 Can be standard template or customized template."; 1541 case standard { 1542 description 1543 "Standard SLO template."; 1544 leaf slo-sle-template { 1545 type leafref { 1546 path "/network-slices" 1547 + "/ns-slo-sle-templates/ns-slo-sle-template/id"; 1548 } 1549 description 1550 "Standard SLO and SLE template to be used."; 1551 } 1552 } 1553 case custom { 1554 description 1555 "Customized SLO template."; 1556 container slo-policy { 1557 description 1558 "Contains the SLO policy."; 1559 leaf policy-description { 1560 type string; 1561 description 1562 "Description of the SLO policy."; 1563 } 1564 uses ns-metric-bounds; 1565 } 1566 uses ns-sles; 1567 } 1568 } 1569 } 1571 container network-slices { 1572 description 1573 "IETF network-slice configurations"; 1574 uses slice-template; 1575 list network-slice { 1576 key "ns-id"; 1577 description 1578 "a network-slice is identified by a ns-id"; 1579 leaf ns-id { 1580 type string; 1581 description 1582 "A unique network-slice identifier across an IETF NSC "; 1583 } 1584 leaf ns-description { 1585 type string; 1586 description 1587 "Give more description of the network slice"; 1588 } 1589 leaf-list ns-tag { 1590 type string; 1591 description 1592 "Network Slice tag for operational management"; 1593 } 1594 leaf ns-connectivity-type { 1595 type identityref { 1596 base ns-connectivity-type; 1597 } 1598 default "any-to-any"; 1599 description 1600 "Network Slice topology."; 1601 } 1602 uses ns-slo-sle-policy; 1603 uses status-params; 1604 container ns-endpoints { 1605 description 1606 "Endpoints"; 1607 list ns-endpoint { 1608 key "ep-id"; 1609 uses endpoint; 1610 description 1611 "list of endpoints in this slice"; 1612 } 1613 } 1614 container ns-connections { 1615 description 1616 "Connections container"; 1617 list ns-connection { 1618 key "ns-connection-id"; 1619 description 1620 "List of Network Slice connections."; 1621 uses ns-connection; 1622 } 1623 } 1624 } 1625 //ietf-network-slice list 1626 } 1627 } 1629 1631 9. Security Considerations 1633 The YANG module defined in this document is designed to be accessed 1634 via network management protocols such as NETCONF [RFC6241] or 1635 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1636 layer, and the mandatory-to-implement secure transport is Secure 1637 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1638 mandatory-to-implement secure transport is TLS [RFC8446]. 1640 The NETCONF access control model [RFC8341] provides the means to 1641 restrict access for particular NETCONF or RESTCONF users to a 1642 preconfigured subset of all available NETCONF or RESTCONF protocol 1643 operations and content. 1645 There are a number of data nodes defined in this YANG module that are 1646 writable/creatable/deletable (i.e., config true, which is the 1647 default). These data nodes may be considered sensitive or vulnerable 1648 in some network environments. Write operations (e.g., edit-config) 1649 to these data nodes without proper protection can have a negative 1650 effect on network operations. 1652 o /ietf-network-slice/network-slices/network-slice 1654 The entries in the list above include the whole network 1655 configurations corresponding with the slice which the higher 1656 management system requests, and indirectly create or modify the PE or 1657 P device configurations. Unexpected changes to these entries could 1658 lead to service disruption and/or network misbehavior. 1660 10. IANA Considerations 1662 This document registers a URI in the IETF XML registry [RFC3688]. 1663 Following the format in [RFC3688], the following registration is 1664 requested to be made: 1666 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 1667 Registrant Contact: The IESG. 1668 XML: N/A, the requested URI is an XML namespace. 1670 This document requests to register a YANG module in the YANG Module 1671 Names registry [RFC7950]. 1673 Name: ietf-network-slice 1674 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 1675 Prefix: ietf-ns 1676 Reference: RFC XXXX 1678 11. Acknowledgments 1680 The authors wish to thank Sergio Belotti, Qin Wu, Susan Hares, Eric 1681 Grey, and many other NS DT members for their helpful comments and 1682 suggestions. 1684 12. References 1686 12.1. Normative References 1688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1689 Requirement Levels", BCP 14, RFC 2119, 1690 DOI 10.17487/RFC2119, March 1997, 1691 . 1693 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1694 DOI 10.17487/RFC3688, January 2004, 1695 . 1697 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1698 and A. Bierman, Ed., "Network Configuration Protocol 1699 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1700 . 1702 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1703 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1704 . 1706 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1707 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1708 . 1710 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1711 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1712 . 1714 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1715 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1716 . 1718 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1719 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1720 May 2017, . 1722 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1723 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1724 . 1726 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1727 Access Control Model", STD 91, RFC 8341, 1728 DOI 10.17487/RFC8341, March 2018, 1729 . 1731 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1732 and R. Wilton, "Network Management Datastore Architecture 1733 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1734 . 1736 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1737 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1738 . 1740 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1741 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1742 and Datastores over NETCONF", RFC 8640, 1743 DOI 10.17487/RFC8640, September 2019, 1744 . 1746 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1747 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1748 September 2019, . 1750 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1751 "Common YANG Data Types for Traffic Engineering", 1752 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1753 . 1755 12.2. Informative References 1757 [I-D.geng-teas-network-slice-mapping] 1758 Geng, X., Dong, J., Pang, R., Han, L., Niwa, T., Jin, J., 1759 Liu, C., and N. Nageshar, "5G End-to-end Network Slice 1760 Mapping from the view of Transport Network", draft-geng- 1761 teas-network-slice-mapping-03 (work in progress), February 1762 2021. 1764 [I-D.ietf-teas-actn-vn-yang] 1765 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 1766 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1767 teas-actn-vn-yang-11 (work in progress), February 2021. 1769 [I-D.ietf-teas-ietf-network-slices] 1770 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 1771 Makhijani, K., Contreras, L. M., and J. Tantsura, 1772 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 1773 network-slices-00 (work in progress), April 2021. 1775 [I-D.liu-teas-transport-network-slice-yang] 1776 Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu, 1777 Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG 1778 Data Model", draft-liu-teas-transport-network-slice- 1779 yang-02 (work in progress), November 2020. 1781 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1782 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1783 . 1785 Appendix A. IETF Network Slice NBI Model Usage Example 1787 The following example describes a simplified service configuration of 1788 two IETF Network slice instances: 1790 o IETF Network Slice 1 on Device1, Device3, and Device4, with any- 1791 to-any connectivity type 1793 o IETF Network Slice 2 on Device2, Device3, with any-to-any 1794 connectivity type 1796 192.0.2.2 VLAN1 1797 +--------+ 1798 |Device1 o------/ 1799 +--------+ | +------+ 1800 +--------+ +------o| A +---------------+ 1801 |Device2 o-------/-----o| | | 1802 +--------+ +---+--+ | 1803 198.51.100.2 | | 1804 VLAN2 | +---+--+ 192.0.2.4 VLAN1 1805 | | | +--------+ 1806 192.0.2.3 VLAN1 | | C o-----/-----oDevice4 | 1807 +--------+ | +---+--+ +--------+ 1808 | o------/ | | 1809 | | | +---+--+ | 1810 | Device3| +------o| B +---------------+ 1811 | o-------/-----o| | 1812 +--------+ +------+ 1813 198.51.100.3 1814 VLAN2 1816 POST: /restconf/data/ietf-network-slice:ietf-network-slices 1817 Host: example.com 1818 Content-Type: application/yang-data+json 1819 { 1820 "network-slices":{ 1821 "network-slice":[ 1822 { 1823 "ns-id":"1", 1824 "ns-description":"slice1", 1825 "ns-connectivity-type":"any-to-any", 1826 "ns-endpoints":{ 1827 "ns-endpoint":[ 1828 { 1829 "ep-id":"11", 1830 "ep-description":"slice1 ep1 connected to device 1", 1831 "ep-role":"any-to-any-role", 1832 "ns-match-criteria":[ 1833 { 1834 "match-type":"ns-vlan-match", 1835 "value":[ 1836 { 1837 "index":"1", 1838 "value":"1" 1839 } 1840 ] 1841 } 1842 ] 1843 }, 1844 { 1845 "ep-id":"12", 1846 "ep-description":"slice1 ep2 connected to device 3", 1847 "ep-role":"any-to-any-role", 1848 "ns-match-criteria":[ 1849 { 1850 "match-type":"ns-vlan-match", 1851 "value":[ 1852 { 1853 "index":"1", 1854 "value":"20" 1855 } 1856 ] 1857 } 1858 ] 1859 }, 1860 { 1861 "ep-id":"13", 1862 "ep-description":"slice1 ep3 connected to device 4", 1863 "ep-role":"any-to-any-role", 1864 "ns-match-criteria":[ 1865 { 1866 "match-type":"ns-vlan-match", 1867 "value":[ 1868 { 1869 "index":"1", 1870 "value":"1" 1872 } 1873 ] 1874 } 1875 ] 1876 } 1877 ] 1878 } 1879 }, 1880 { 1881 "ns-id":"ns2", 1882 "ns-description":"slice2", 1883 "ns-connectivity-type":"any-to-any", 1884 "ns-endpoints":{ 1885 "ns-endpoint":[ 1886 { 1887 "ep-id":"21", 1888 "ep-description":"slice2 ep1 connected to device 2", 1889 "ep-role":"any-to-any-role", 1890 "ns-match-criteria":[ 1891 { 1892 "match-type":"ns-vlan-match", 1893 "value":[ 1894 { 1895 "index":"1", 1896 "value":"2" 1897 } 1898 ] 1899 } 1900 ] 1901 }, 1902 { 1903 "ep-id":"22", 1904 "ep-description":"slice2 ep2 connected to device 3", 1905 "ep-role":"any-to-any-role", 1906 "ns-match-criteria":[ 1907 { 1908 "match-type":"ns-vlan-match", 1909 "value":[ 1910 { 1911 "index":"1", 1912 "value":"2" 1913 } 1914 ] 1915 } 1916 ] 1917 } 1918 ] 1919 } 1921 } 1922 ] 1923 } 1924 } 1926 Appendix B. Comparison with Other Possible Design choices for IETF 1927 Network Slice NBI 1929 According to the 3.3.1. Northbound Inteface (NBI) 1930 [I-D.ietf-teas-ietf-network-slices], the IETF Network Slice NBI is a 1931 technology-agnostic interface, which is used for a customer to 1932 express requirements for a particular IETF Network Slice. Customers 1933 operate on abstract IETF Network Slices, with details related to 1934 their realization hidden. As classified by [RFC8309], the IETF 1935 Network Slice NBI is classified as Customer Service Model. 1937 This draft analyzes the following existing IETF models to identify 1938 the gap between the IETF Network Slice NBI requirements. 1940 B.1. ACTN VN Model Augmentation 1942 The difference between the ACTN VN model and the IETF Network Slice 1943 NBI requirements is that the IETF Network Slice NBI is a technology- 1944 agnostic interface, whereas the VN model is bound to the IETF TE 1945 Topologies. The realization of the IETF Network Slice does not 1946 necessarily require the slice network to support the TE technology. 1948 The ACTN VN (Virtual Network) model introduced in 1949 [I-D.ietf-teas-actn-vn-yang] is the abstract customer view of the TE 1950 network. Its YANG structure includes four components: 1952 o VN: A Virtual Network (VN) is a network provided by a service 1953 provider to a customer for use and two types of VN has defined. 1954 The Type 1 VN can be seen as a set of edge-to-edge abstract links. 1955 Each link is an abstraction of the underlying network which can 1956 encompass edge points of the customer's network, access links, 1957 intra-domain paths, and inter-domain links. 1959 o AP: An AP is a logical identifier used to identify the access link 1960 which is shared between the customer and the IETF scoped Network. 1962 o VN-AP: A VN-AP is a logical binding between an AP and a given VN. 1964 o VN-member: A VN-member is an abstract edge-to-edge link between 1965 any two APs or VN-APs. Each link is formed as an E2E tunnel 1966 across the underlying networks. 1968 The Type 1 VN can be used to describe IETF Network Slice connection 1969 requirements. However, the Network Slice SLO and Network Slice 1970 Endpoint are not clearly defined and there's no direct equivalent. 1971 For example, the SLO requirement of the VN is defined through the 1972 IETF TE Topologies YANG model, but the TE Topologies model is related 1973 to a specific implementation technology. Also, VN-AP does not define 1974 "network-slice-match-criteria" to specify a specific NSE belonging to 1975 an IETF Network Slice. 1977 B.2. RFC8345 Augmentation Model 1979 The difference between the IETF Network Slice NBI requirements and 1980 the IETF basic network model is that the IETF Network Slice NBI 1981 requests abstract customer IETF Network Slices, with details related 1982 to the slice Network hidden. But the IETF network model is used to 1983 describe the interconnection details of a Network. The customer 1984 service model does not need to provide details on the Network. 1986 For example, IETF Network Topologies YANG data model extension 1987 introduced in Transport Network Slice YANG Data Model 1988 [I-D.liu-teas-transport-network-slice-yang] includes three major 1989 parts: 1991 o Network: a transport network list and an list of nodes contained 1992 in the network 1994 o Link: "links" list and "termination points" list describe how 1995 nodes in a network are connected to each other 1997 o Support network: vertical layering relationships between IETF 1998 Network Slice networks and underlay networks 2000 Based on this structure, the IETF Network Slice-specific SLO 2001 attributes nodes are augmented on the Network Topologies model,, e.g. 2002 isolation etc. However, this modeling design requires the slice 2003 network to expose a lot of details of the network, such as the actual 2004 topology including nodes interconnection and different network layers 2005 interconnection. 2007 Appendix C. Appendix B IETF Network Slice Match Criteria 2009 5G is a use case of the IETF Network Slice and 5G End-to-end Network 2010 Slice Mapping from the view of IETF Network 2011 [I-D.geng-teas-network-slice-mapping] 2013 defines two types of Network Slice interconnection and 2014 differentiation methods: by physical interface or by TNSII (Transport 2015 Network Slice Interworking Identifier). TNSII is a field in the 2016 packet header when different 5G wireless network slices are 2017 transported through a single physical interfaces of the IETF scoped 2018 Network. In the 5G scenario, "network-slice-match-criteria" refers 2019 to TNSII. 2021 +------------------------------------------------------------+ 2022 | 5G E2E network slice orchestrator | 2023 ++-----------------------------------------------------+-----+ 2024 | | | 2025 | IETF Network Slice NBI | 2026 +---+-------+ | +-----+-----+ 2027 | | +------------------+ | | 2028 |RAN Slice | |IETF Network Slice| |Core Slice | 2029 |controller | | controller | | controller| 2030 +----+------+ +-------+----------+ +-----+-----+ 2031 | | | 2032 | | | 2033 +---+--+ +------------+----------------+ ++-----+ 2034 | | | | | | 2035 | | | | | | 2036 |+----+| | | | | 2037 || ||NS1-NSE1 | Network Slice 1 | |+----+| 2038 ||gNB1|+---------+-----+-----------------------+--------+|UPF1|| 2039 || |+************ / |NS1-NSE3|+----+| 2040 |+----+|NS2-NSE1 | */ | | | 2041 | | /* | | | 2042 |+----+|NS1-NSE2 | / * | | | 2043 || |+---------- * Network Slice 2 |NS2-NSE3|+----+| 2044 ||gNB2|+************************************************+|UPF2|| 2045 || ||NS2-NSE2 | | |+----+| 2046 |+----+| | | | 2047 | | | | | | 2048 | | | | | | 2049 +------+ +----------- -----------------+ +------+ 2051 As shown in the figure, gNodeB 1 and gNodeB 2 use IP gNB1 and IP gNB2 2052 to communicate with the IETF network, respectively. In addition, the 2053 traffic of NS1 and NS2 on gNodeB 1 and gNodeB 2 is transmitted 2054 through the same access links to the IETF slice network. The IETF 2055 slice network need to to distinguish different IETF Network Slice 2056 traffic of same gNB. Therefore, in addition to using "node-id" and 2057 "ep-ip" to identify a Network Slice Endpont, other information is 2058 needed along with these parameters to uniquely distinguish a NSE. 2059 For example, VLAN IDs in the user traffic can be used to distinguish 2060 the NSEs of gNBs and UPFs. 2062 Authors' Addresses 2064 Bo Wu 2065 Huawei Technologies 2066 101 Software Avenue, Yuhua District 2067 Nanjing, Jiangsu 210012 2068 China 2070 Email: lana.wubo@huawei.com 2072 Dhruv Dhody 2073 Huawei Technologies 2074 Divyashree Techno Park 2075 Bangalore, Karnataka 560066 2076 India 2078 Email: dhruv.ietf@gmail.com 2080 Reza Rokui 2081 Nokia 2083 Email: reza.rokui@nokia.com 2085 Tarek Saad 2086 Juniper Networks 2088 Email: tsaad@juniper.net 2090 Liuyan Han 2091 China Mobile 2093 Email: hanliuyan@chinamobile.com