idnits 2.17.1 draft-ietf-teas-ietf-network-slice-nbi-yang-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 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 303 has weird spacing: '...ch-type ide...' == Line 305 has weird spacing: '...w index uin...' == Line 309 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 (28 September 2021) is 941 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 (-12) exists of draft-ietf-opsawg-vpn-common-11 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-12 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-04 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-04 Summary: 1 error (**), 0 flaws (~~), 10 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: 1 April 2022 R. Rokui 6 Nokia 7 T. Saad 8 Juniper Networks 9 L. Han 10 China Mobile 11 28 September 2021 13 IETF Network Slice Service YANG Model 14 draft-ietf-teas-ietf-network-slice-nbi-yang-00 16 Abstract 18 This document provides a YANG data model for the IETF Network Slice 19 service model. The model can be used by a IETF Network Slice 20 customer to manage IETF Network Slice from an IETF Network Slice 21 Controller (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 1 April 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 (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 Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 9 62 6. IETF Network Slice Modeling Description . . . . . . . . . . . 9 63 6.1. IETF Network Slice Connectivity Type . . . . . . . . . . 10 64 6.2. IETF Network Slice SLO and SLE Policy . . . . . . . . . . 11 65 6.3. IETF Network Slice Endpoint (NSE) . . . . . . . . . . . . 13 66 7. IETF Network Slice Monitoring . . . . . . . . . . . . . . . . 16 67 8. IETF Network Slice Service Module . . . . . . . . . . . . . . 17 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 38 73 12.2. Informative References . . . . . . . . . . . . . . . . . 40 74 Appendix A. IETF Network Slice NBI Model Usage Example . . . . . 41 75 Appendix B. Comparison with Other Possible Design choices for IETF 76 Network Slice NBI . . . . . . . . . . . . . . . . . . . . 44 77 B.1. ACTN VN Model Augmentation . . . . . . . . . . . . . . . 44 78 B.2. RFC8345 Augmentation Model . . . . . . . . . . . . . . . 45 79 Appendix C. Appendix B IETF Network Slice Match Criteria . . . . 45 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 82 1. Introduction 84 This document provides a YANG [RFC7950] data model for the IETF 85 Network Slice service model. 87 The YANG model discussed in this document is defined based on the 88 description of the IETF Network Slice in 89 [I-D.ietf-teas-ietf-network-slices], which is used to operate IETF 90 Network Slices during the IETF Network Slice instantiation. This 91 YANG model supports various operations on IETF Network Slices such as 92 creation, modification, deletion, and monitoring. 94 The IETF Network Slice Controller (NSC) is a logical entity that 95 allows customers to manage IETF network slices. Customers operate on 96 abstract IETF network slices. Details related to the production of 97 slices that fulfil the request are internal to the entity that 98 operates the network. Such details are deployment- and 99 implementation-specific. 101 The NSC receives request from its customer-facing interface (e.g., 102 from a management system). This interface carries data objects the 103 IETF network slice user provides, describing the needed IETF network 104 slices in terms of topology, target service level objectives (SLO), 105 and also monitoring and reporting requirements. These requirements 106 are then translated into technology-specific actions that are 107 implemented in the underlying network using a network-facing 108 interface. The details of how the IETF network slices are put into 109 effect are out of scope for this document. 111 The YANG model discussed in this document describes the requirements 112 of an IETF Network Slice from the point of view of the customer. It 113 is thus classified as customer service model in [RFC8309]. 115 The IETF Network Slice operational state is included in the same tree 116 as the configuration consistent with Network Management Datastore 117 Architecture [RFC8342]. 119 2. Conventions used in this document 121 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 The following terms are defined in [RFC6241] and are used in this 128 specification: 130 * client 132 * configuration data 134 * state data 136 This document makes use of the terms defined in [RFC7950]. 138 This document also makes use of the terms introduced in the Framework 139 for IETF Network Slices [I-D.ietf-teas-ietf-network-slices]: 141 This document defines the following term: 143 * IETF Network Slice Connection (NS-Connection): In the context of 144 an IETF Network Slice, an IETF NS-Connection is an abstract entity 145 which represents a particular connection between a pair of NSEs. 146 An IETF Network Slice can has one or multiple NS-Connections. 148 2.1. Tree Diagrams 150 The tree diagram used in this document follow the notation defined in 151 [RFC8340]. 153 3. IETF Network Slice Service Model Usage 155 The intention of the IETF Network Slice service model is to allow the 156 customer to manage IETF Network Slices. In particular, the model 157 allows customers to operate in an abstract and technology-agnostic 158 manner, with details of the IETF Network Slices realization hidden. 160 According to the [I-D.ietf-teas-ietf-network-slices] description, 161 IETF Network Slices are applicable to use cases such as (but not 162 limited to) network wholesale services, network infrastructure 163 sharing among operators, NFV connectivity, Data Center Interconnect, 164 and 5G E2E network slice. 166 As shown in Figure 1, in all these use-cases, the model is used by 167 the higher management system to communicate with NSC for life cycle 168 manage of IETF Network Slices including both enablement and 169 monitoring. For example, in 5G E2E network slicing use-case the E2E 170 network slice orchestrator acts as the higher layer system to request 171 the IETF Network Slices. The interface is used to support dynamic 172 IETF Network Slice creation and its lifecycle management to 173 facilitate end-to-end network slice services. 175 +----------------------------------------+ 176 | IETF Network Slice Customer | 177 | | 178 +----------------+-----------------------+ 179 | 180 | 181 |IETF Network Slice service model YANG 182 | 183 +---------------------+--------------------------+ 184 | IETF Network Slice Controller (NSC) | 185 +------------------------------------------------+ 187 Figure 1: IETF Network Slice Service Reference Architecture 189 4. IETF Network Slice Service Model Overview 191 As defined in [I-D.ietf-teas-ietf-network-slices], an IETF Network 192 Slice is a logical network topology connecting a number of endpoints 193 using a set of shared or dedicated network resources that are used to 194 satisfy specific service requirements. The logical topology types 195 are: point-to-point, point-to-multipoint, multipoint-to-point, or 196 multipoint-to-multipoint. The endpoints are conceptual points that 197 could map to a device, application or a network function. And the 198 specific service requirements, typically expressed as bandwidth, 199 latency, latency variation, and other desired or required 200 characteristics, such as security, MTU, traffic-type (e.g., IPv4, 201 IPv6, Ethernet or unstructured) or a higher-level behavior to process 202 traffic according to user-application (which may be realized using 203 network function). An example of an IETF network slice is shown in 204 Figure 2 . 206 +----------------------------------------------+ 207 | | 208 NSE1 O------------------+ | 209 . +---------------------------O NSE2 210 . | . 211 . | multipoint-to-multipoint . 212 . | . 213 . +---------------------------O NSEn 214 NSEm O------------------+ | 215 | | 216 +----------------------------------------------+ 218 | | 219 |<-----------An IETF Network Slice ---------->| 220 | between endpoints NSE1 to NSEn | 222 Legend: 223 NSE: IETF Network Slice Endpoint 224 O: Represents IETF Network Slice Endpoints 226 Figure 2: An IETF Network Slice Example 228 As shown in the example, an IETF network slice may have multiple 229 NSEs. The NSEs are the ingress/egress points where traffic enters/ 230 exits the IETF network slice. As the edge of the IETF network slice, 231 the NSEs also delimit a topological network portion within which the 232 committed SLOs apply. 234 When an NSC receives a message via its customer-facing interface for 235 creation/modification of an IETF network slice, it uses the provided 236 NSEs to retrieve the corresponding border link or "Provider Node" 237 (e.g., PE). The NSC further maps them to the appropriate 238 service/tunnel/path endpoints in the underlying network. It then 239 uses services/tunnels/paths to realize the IETF network slice. 241 The 'ietf-network-slice' module uses two main data nodes: list 'ietf- 242 network-slice' and container 'ns-templates' (see Figure 3). 244 The 'ietf-network-slice' list includes the set of IETF Network slices 245 managed within a provider network. 'ietf-network-slice' is the data 246 structure that abstracts an IETF Network Slice. Under the "ietf- 247 network-slice", list "ns-endpoint" is used to abstract the NSEs, e.g. 248 NSEs in the example above. And list "ns-connection" is used to 249 abstract connections between NSEs. 251 The 'ns-templates' container is used by the NSC to maintain a set of 252 common network slice templates that apply to one or several IETF 253 Network Slices. 255 The figure below describes the overall structure of the YANG module: 257 module: ietf-network-slice 258 +--rw network-slices 259 +--rw ns-slo-sle-templates 260 | +--rw ns-slo-sle-template* [id] 261 | +--rw id string 262 | +--rw template-description? string 263 +--rw network-slice* [ns-id] 264 +--rw ns-id string 265 +--rw ns-description? string 266 +--rw customer-name* string 267 +--rw ns-connectivity-type? identityref 268 +--rw (ns-slo-sle-policy)? 269 | +--:(standard) 270 | | +--rw slo-sle-template? leafref 271 | +--:(custom) 272 | +--rw slo-sle-policy 273 | +--rw policy-description? string 274 | +--rw ns-metric-bounds 275 | | +--rw ns-metric-bound* [metric-type] 276 | | +--rw metric-type identityref 277 | | +--rw metric-unit string 278 | | +--rw value-description? string 279 | | +--rw bound? uint64 280 | +--rw security* identityref 281 | +--rw isolation? identityref 282 | +--rw max-occupancy-level? uint8 283 | +--rw mtu uint16 284 | +--rw steering-constraints 285 | +--rw path-constraints 286 | +--rw service-function 287 +--rw status 288 | +--rw admin-enabled? boolean 289 | +--ro oper-status? operational-type 290 +--rw ns-endpoints 291 | +--rw ns-endpoint* [ep-id] 292 | +--rw ep-id string 293 | +--rw ep-description? string 294 | +--rw ep-role? identityref 295 | +--rw location 296 | | +--rw altitude? int64 297 | | +--rw latitude? decimal64 298 | | +--rw longitude? decimal64 299 | +--rw node-id? string 300 | +--rw ep-ip? inet:host 301 | +--rw ns-match-criteria 302 | | +--rw ns-match-criterion* [match-type] 303 | | +--rw match-type identityref 304 | | +--rw values* [index] 305 | | +--rw index uint8 306 | | +--rw value? string 307 | +--rw ep-peering 308 | | +--rw protocol* [protocol-type] 309 | | +--rw protocol-type identityref 310 | | +--rw attribute* [index] 311 | | +--rw index uint8 312 | | +--rw attribute-description? string 313 | | +--rw value? string 314 | +--rw ep-network-access-points 315 | | +--rw ep-network-access-point* [network-access-id] 316 | | +--rw network-access-id string 317 | | +--rw network-access-description? string 318 | | +--rw network-access-node-id? string 319 | | +--rw network-access-tp-id? string 320 | | +--rw network-access-tp-ip? inet:host 321 | | +--rw mtu uint16 322 | | +--rw ep-rate-limit 323 | | +--rw incoming-rate-limit? 324 | | | te-types:te-bandwidth 325 | | +--rw outgoing-rate-limit? 326 | | te-types:te-bandwidth 327 | +--rw ep-rate-limit 328 | | +--rw incoming-rate-limit? te-types:te-bandwidth 329 | | +--rw outgoing-rate-limit? te-types:te-bandwidth 330 | +--rw status 331 | | +--rw admin-enabled? boolean 332 | | +--ro oper-status? operational-type 333 | +--ro ep-monitoring 334 | +--ro incoming-utilized-bandwidth? 335 | | te-types:te-bandwidth 336 | +--ro incoming-bw-utilization decimal64 337 | +--ro outgoing-utilized-bandwidth? 338 | | te-types:te-bandwidth 339 | +--ro outgoing-bw-utilization decimal64 340 +--rw ns-connections 341 +--rw ns-connection* [ns-connection-id] 342 +--rw ns-connection-id uint32 343 +--rw ns-connection-description? string 344 +--rw src 345 | +--rw src-ep-id? leafref 346 +--rw dest 347 | +--rw dest-ep-id? leafref 348 +--rw (ns-slo-sle-policy)? 349 | +--:(standard) 350 | | +--rw slo-sle-template? leafref 351 | +--:(custom) 352 | +--rw slo-sle-policy 353 | +--rw policy-description? string 354 | +--rw ns-metric-bounds 355 | | +--rw ns-metric-bound* [metric-type] 356 | | +--rw metric-type identityref 357 | | +--rw metric-unit string 358 | | +--rw value-description? string 359 | | +--rw bound? uint64 360 | +--rw security* identityref 361 | +--rw isolation? identityref 362 | +--rw max-occupancy-level? uint8 363 | +--rw mtu uint16 364 | +--rw steering-constraints 365 | +--rw path-constraints 366 | +--rw service-function 367 +--rw monitoring-type? ns-monitoring-type 368 +--ro ns-connection-monitoring 369 +--ro latency? yang:gauge64 370 +--ro jitter? yang:gauge32 371 +--ro loss-ratio? decimal64 373 Figure 3 375 5. IETF Network Slice Templates 377 The 'ns-templates' container (Figure 3) is used by service provider 378 of the NSC to define and maintain a set of common IETF Network Slice 379 templates that apply to one or several IETF Network Slices. The 380 exact definition of the templates is deployment specific to each 381 network provider. 383 The model includes only the identifiers of SLO and SLE templates. 384 When creation of IETF Network slice, the SLO and SLE policies can be 385 easily identified. 387 The following shows an example where two network slice templates can 388 be retrieved by the upper layer management system: 390 { 391 "ietf-network-slices": { 392 "ns-templates": { 393 "slo-sle-template": [ 394 { 395 "id":"GOLD-template", 396 "template-description": "Two-way bandwidth: 1 Gbps, 397 one-way latency 100ms " 398 "sle-isolation":"ns-isolation-shared", 399 }, 400 { 401 "id":"PLATINUM-template", 402 "template-description": "Two-way bandwidth: 1 Gbps, 403 one-way latency 50ms " 404 "sle-isolation":"ns-isolation-dedicated", 405 }, 406 ], 407 } 408 } 409 } 411 6. IETF Network Slice Modeling Description 413 The 'ietf-network-slice' is the data structure that abstracts an IETF 414 Network Slice of the IETF network. Each 'ietf-network-slice' is 415 uniquely identified by an identifier: 'ns-id'. 417 An IETF Network Slice has the following main parameters: 419 * "ns-id": Is an identifier that is used to uniquely identify the 420 IETF Network Slice within NSC. 422 * "ns-description": Gives some description of an IETF Network Slice 423 service. 425 * "ns-connectivity-type": Indicates the network connectivity type 426 for the IETF Network Slice: Hub-and-Spoke, any-to-any, or custom 427 type. 429 * "status": Is used to show the operative and administrative status 430 of the IETF Network Slice, and can be used as indicator to detect 431 network slice anomalies. 433 * "customer-name": Is used to show the correlation between actual 434 slice customers and IETF network slices. It can be used by the 435 NSC for monitoring and assurance of the IETF network slices where 436 NSC can notify the higher system by issuing the notifications. 437 For example, multiple actual customers use a same network slice. 439 * "ns-slo-sle-policy": Defines SLO and SLE policies for the "ietf- 440 network-slice". More description are provided in Section 6.2 442 The "ns-endpoint" is an abstrac entity that represents a set of 443 matching rules applied to an IETF network edge device or a customer 444 network edge device involved in the IETF Network Slice and each 'ns- 445 endpoint' belongs to a single 'ietf-network-slice'. More description 446 are provided in Section 6.3 448 6.1. IETF Network Slice Connectivity Type 450 Based on the customer's traffic pattern requirements, an IETF Network 451 Slice connection type could be point-to-point (P2P), point-to- 452 multipoint (P2MP), multipoint-to-point (MP2P), or multipoint-to- 453 multipoint (MP2MP). The "ns-connectivity-type" under the node "ietf- 454 network-slice" is used for this. 456 According to the network services defined in 457 [I-D.ietf-opsawg-vpn-common], some well-known connectivity types are 458 proposed for IETF network slices. The type could be any-to-any, Hub- 459 and-Spoke (where Hubs can exchange traffic), and the custom. By 460 default, the any-to-any is used. New connectivity type could be 461 added via augmentation or by list of 'ns-connection' specified. 463 In addition, "ep-role" under the node "ns-endpoint" also needs to be 464 defined, which specifies the role of the NSE in a particular Network 465 Slice connectivity type. In the any-to-any, all NSEs MUST have the 466 same role, which will be "any-to-any-role". In the Hub-and-Spoke, 467 NSEs MUST have a Hub role or a Spoke role. 469 6.2. IETF Network Slice SLO and SLE Policy 471 As defined in [I-D.ietf-teas-ietf-network-slices], the SLO and SLE 472 policy of an IETF Network Slice defines the minimum IETF Network 473 Slice SLO attributes, and additional attributes can be added as 474 needed. 476 "ns-slo-sle-policy" is used to represent specific SLO and SLE 477 policies. During the creation of an IETF Network Slice, the policy 478 can be specified either by a standard SLO and SLO template or a 479 customized SLO and SLE policy. 481 The policy could both apply one per Network Slice or per connection 482 'ns-connection'. 484 The model allows multiple SLO and SLE attributes to be combined to 485 meet different SLO and SLE requirements. For example, some NSs are 486 used for video services and require high bandwidth, some NSs are used 487 for key business services and request low latency and reliability, 488 and some NSs need to provide connections for a large number of NSEs. 489 That is, not all SLO or SLE attributes must be specified to meet the 490 particular requirements of a slice. 492 "ns-metric-bounds" contains all these variations, which includes a 493 list of "ns-metric-bound" and each "ns-metric-bound" could specify a 494 particular "metric-type". "metric-type" is defined with YANG identity 495 and the YANG module supports the following options: 497 "ns-slo-one-way-bandwidth": Indicates the guaranteed minimum 498 bandwidth between any two NSE. And the bandwidth is 499 unidirectional. 501 "ns-slo-two-way-bandwidth": Indicates the guaranteed minimum 502 bandwidth between any two NSE. And the bandwidth is 503 bidirectional. 505 "network-slice-slo-one-way-latency": Indicates the maximum one-way 506 latency between two NSE. 508 "network-slice-slo-two-way-latency": Indicates the maximum round- 509 trip latency between two NSE. 511 "ns-slo-one-way-delay-variation": Indicates the jitter constraint 512 of the slice maximum permissible delay variation, and is measured 513 by the difference in the one-way latency between sequential 514 packets in a flow. 516 "ns-slo-two-way-delay-variation": Indicates the jitter constraint 517 of the slice maximum permissible delay variation, and is measured 518 by the difference in the two-way latency between sequential 519 packets in a flow. 521 "ns-slo-one-way-packet-loss": Indicates maximum permissible packet 522 loss rate, which is defined by the ratio of packets dropped to 523 packets transmitted between two endpoints. 525 "ns-slo-two-way-packet-loss": Indicates maximum permissible packet 526 loss rate, which is defined by the ratio of packets dropped to 527 packets transmitted between two endpoints. 529 "ns-slo-availability": Is defined as the ratio of up-time to 530 total_time(up-time+down-time), where up-time is the time the IETF 531 Network Slice is available in accordance with the SLOs associated 532 with it. 534 Some other Network Slice SLOs or SLEs could be extended when needed. 536 Note: The definition of "slo-sle-policy" and "steering-constraints" 537 will be updated when WG converge on the terms. 539 Note: RFC7297 shaping/policing for out of profile traffic. 541 The following shows an example where a network slice policy can be 542 configured: 544 { 545 "ietf-network-slices": { 546 "ietf-network-slice": { 547 "slo-policy": { 548 "policy-description":"video-service-policy", 549 "ns-metric-bounds": { 550 "ns-metric-bound": [ 551 { 552 "metric-type": "ns-slo-one-way-bandwidth", 553 "metric-unit": "mbps" 554 "bound": "1000" 555 }, 556 { 557 "metric-type": "ns-slo-availability", 558 "bound": "99.9%" 559 }, 560 ], 561 } 562 } 563 } 564 } 565 } 567 6.3. IETF Network Slice Endpoint (NSE) 569 An IETF Network Slice Endpoint has several characteristics: 571 * "ep-id": Uniquely identifies the NSE within Network Slice 572 Controller (NSC). The identifier is a string that allows any 573 encoding for the local administration of the IETF Network Slice. 575 * "location": Indicates NSE location information that facilities NSC 576 easy identification of a NSE. 578 * "ep-role": Represents a connectivity type role of a NSE belonging 579 to an IETF network slice, as described in Section 6.1. The "ep- 580 role" leaf defines the role of the endpoint in a particular NS 581 connectivity type. In the any-to-any, all NSEs MUST have the same 582 role, which will be "any-to-any-role". 584 * "node-id": The NSE node information facilities NSC with easy 585 identification of a NSE. 587 * "ep-ip": The NSE IP information facilities NSC with easy 588 identification of a NSE. 590 * "ns-match-criteria": A matching policies to apply on a given NSE. 592 * "ep-network-access-points": The list of the interfaces attached to 593 an edge device of the IETF Network Slice by which the customer 594 traffic is received. 596 * "ep-rate-limit": Set the rate-limiting policies to apply on a 597 given NSE, including ingress and egress traffic to ensure access 598 security. When applied in the incoming direction, the rate-limit 599 is applicable to the traffic from the NSE to the IETF scope 600 Network that passes through the external interface. When 601 Bandwidth is applied to the outgoing direction, it is applied to 602 the traffic from the IETF Network to the NSE of that particular 603 NS. 605 * "ep-protocol": Specify the protocol for a NSE for exchanging 606 control-plane information, e.g. L1 signaling protocol or L3 607 routing protocols,etc. 609 * "status": Enable the control of the operative and administrative 610 status of the NSE, can be used as indicator to detect NSE 611 anomalies. 613 An NSE belong to a single IETF Network Slice. An IETF Network Slice 614 involves two or more NSEs. An IETF Network Slice can be modified by 615 adding new "ns-endpoint" or removing existing "ns-endpoint". 617 A NSE is used to define the matching rule on the customer traffic 618 that can be injected to an IETF Network Slice. "network-slice-match- 619 criteria" is defined to support different options. Classification 620 can be based on many criteria, such as: 622 * Physical interface: Indicates all the traffic received from the 623 interface belongs to the IETF Network Slice. 625 * Logical interface: For example, a given VLAN ID is used to 626 identify an IETF Network Slice. 628 * Encapsulation in the traffic header: For example, a source IP 629 address is used to identify an IETF Network Slice. 631 To illustrate the use of NSE parameters, the below are two examples. 632 How the NSC realize the mapping is out of scope for this document. 634 * NSE with PE parameters example: As shown in Figure 4 , customer of 635 the IETF network slice would like to connect two NSEs to satisfy 636 specific service, e.g., Network wholesale services. In this case, 637 the IETF network slice endpoints are mapped to physical interfaces 638 of PE nodes. The IETF network slice controller (NSC) uses 'node- 639 id' (PE device ID), 'ep-network-access-points' (Two PE interfaces 640 ) to map the interfaces and corresponding services/tunnels/paths. 642 NSE1 NSE2 643 (With PE1 parameters) (with PE2 parameters) 644 o<--------- IETF Network Slice 1 ------->o 645 + | | + 646 + |<----------- S1 ----------->| + 647 + | | + 648 + | |<------ T1 ------>| | + 649 + v v v v + 650 + +----+ +----+ + 651 +-----+ | | PE1|==================| PE2| +-----+ 652 | |----------X | | | | | | 653 | | | | | | X----------| | 654 | |----------X | | | | | | 655 +-----+ | | |==================| | | +-----+ 656 AC +----+ +----+ AC 657 Customer Provider Provider Customer 658 Edge 1 Edge 1 Edge 2 Edge 2 660 Legend: 661 O: Representation of the IETF network slice endpoints (NSE) 662 +: Mapping of NES to PE or CE nodes on IETF network 663 X: Physical interfaces used for realization of IETF network slice 664 S1: L0/L1/L2/L3 services used for realization of IETF network slice 665 T1: Tunnels used for realization of IETF network slice 667 Figure 4 669 * NSE with CE parameters example: As shown in Figure 5 , customer of 670 the IETF network slice would like to connect two NSEs to provide 671 connectivity between transport portion of 5G RAN to 5G Core 672 network functions. In this scenario, the IETF network slice 673 controller (NSC) uses 'node-id' (CE device ID) , 'ep-ip' (CE 674 tunnel endpoint IP), 'network-slice-match-criteria' (VLAN 675 interface), 'ep-network-access-points' (Two nexthop interfaces ) 676 to retrieve the corresponding border link or PE, and further map 677 to services/tunnels/paths. 679 NSE3 NSE4 680 (With CE1 parameters) (with CE2 parameters) 681 o<--------- IETF Network Slice 2 ------->o 682 + | | + 683 + |<----------- S2 ----------->| + 684 + | | + 685 + | |<------ T2 ------>| | + 686 + v v v v + 687 + +----+ +----+ + 688 +-----+ | + | PE1|==================| PE2| + | +-----+ 689 | |----------X | | | | | | 690 | | | | | | X----------| | 691 | |----------X | | | | | | 692 +-----+ | | |==================| | | +-----+ 693 AC +----+ +----+ AC 694 Customer Provider Provider Customer 695 Edge 1 Edge 1 Edge 2 Edge 2 697 Legend: 698 O: Representation of the IETF network slice endpoints (NSE) 699 +: Mapping of NSE to PE or CE-PE interfaces on IETF network 700 X: Physical interfaces used for realization of IETF network slice 701 S2: L0/L1/L2/L3 services used for realization of IETF network slice 702 T2: Tunnels used for realization of IETF network slice 704 Figure 5 706 Note: The model needs to be optimized for better extension of other 707 protocols or AC technologies. 709 7. IETF Network Slice Monitoring 711 An IETF Network Slice is a connectivity with specific SLO 712 characteristics, including bandwidth, latency, etc. The connectivity 713 is a combination of logical unidirectional connections, represented 714 by 'ns-connection'. 716 This model also describes performance status of an IETF Network 717 Slice. The statistics are described in the following granularity: 719 * Per NS connection: specified in 'ns-connection-monitoring' under 720 the "ns-connection" 722 * Per NS Endpoint: specified in 'ep-monitoring' under the "ns- 723 endpoint" 725 This model does not define monitoring enabling methods. The 726 mechanism defined in [RFC8640] and [RFC8641] can be used for either 727 periodic or on-demand subscription. 729 By specifying subtree filters or xpath filters to 'ns-connection' or 730 'ns-endpoint' ,so that only interested contents will be sent. These 731 mechanisms can be used for monitoring the IETF Network Slice 732 performance status so that the customer management system could 733 initiate modification based on the IETF Network Slice running status. 735 Note: More critical events affecting service delivery need to be 736 added. 738 8. IETF Network Slice Service Module 740 The "ietf-network-slice" module uses types defined in [RFC6991], 741 [RFC8776]. 743 file "ietf-network-slice@2021-07-20.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-20 { 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 819 Network Slice traffic. Hence, the IETF network slice traffic 820 is isolated from other servceis traffic sharing the same 821 resources."; 822 } 824 identity ns-security-type { 825 description 826 "Base identity for for IETF Network security level."; 827 } 829 identity ns-security-authenticate { 830 base ns-security-type; 831 description 832 "IETF Network Slice requires authentication."; 833 } 835 identity ns-security-integrity { 836 base ns-security-type; 837 description 838 "IETF Network Slice requires data integrity."; 839 } 841 identity ns-security-encryption { 842 base ns-security-type; 843 description 844 "IETF Network Slice requires data encryption."; 845 } 847 identity ns-connectivity-type { 848 description 849 "Base identity for IETF Network Slice topology."; 850 } 852 identity any-to-any { 853 base ns-connectivity-type; 854 description 855 "Identity for any-to-any IETF Network Slice topology."; 856 } 858 identity hub-spoke { 859 base ns-connectivity-type; 860 description 861 "Identity for Hub-and-Spoke IETF Network Slice topology."; 862 } 864 identity custom { 865 base ns-connectivity-type; 866 description 867 "Identity of a custom NS topology where Hubs can act as 868 Spoke for certain parts of the network or Spokes as Hubs."; 870 } 872 identity endpoint-role { 873 description 874 "Base identity of a NSE role in an IETF Network Slice topology."; 875 } 877 identity any-to-any-role { 878 base endpoint-role; 879 description 880 "Identity of any-to-any NS."; 881 } 883 identity spoke-role { 884 base endpoint-role; 885 description 886 "A NSE is acting as a Spoke."; 887 } 889 identity hub-role { 890 base endpoint-role; 891 description 892 "A NSE is acting as a Hub."; 893 } 895 identity ns-slo-metric-type { 896 description 897 "Base identity for IETF Network Slice SLO metric type."; 898 } 900 identity ns-slo-one-way-bandwidth { 901 base ns-slo-metric-type; 902 description 903 "SLO bandwidth metric. Minimum guaranteed bandwidth between 904 two endpoints at any time and is measured unidirectionally"; 905 } 907 identity ns-slo-two-way-bandwidth { 908 base ns-slo-metric-type; 909 description 910 "SLO bandwidth metric. Minimum guaranteed bandwidth between 911 two endpoints at any time"; 912 } 914 identity ns-slo-one-way-latency { 915 base ns-slo-metric-type; 916 description 917 "SLO one-way latency is upper bound of network latency when 918 transmitting between two endpoints. The metric is defined in 919 RFC7679"; 920 } 922 identity ns-slo-two-way-latency { 923 base ns-slo-metric-type; 924 description 925 "SLO two-way latency is upper bound of network latency when 926 transmitting between two endpoints. The metric is defined in 927 RFC2681"; 928 } 930 identity ns-slo-one-way-delay-variation { 931 base ns-slo-metric-type; 932 description 933 "SLO one-way delay variation is defined by RFC3393, is the 934 difference in the one-way delay between sequential packets 935 between two endpoints."; 936 } 938 identity ns-slo-two-way-delay-variation { 939 base ns-slo-metric-type; 940 description 941 "SLO two-way delay variation is defined by RFC5481, is the 942 difference in the round-trip delay between sequential packets 943 between two endpoints."; 944 } 946 identity ns-slo-one-way-packet-loss { 947 base ns-slo-metric-type; 948 description 949 "SLO loss metric. The ratio of packets dropped to packets 950 transmitted between two endpoints in one-way 951 over a period of time as specified in RFC7680"; 952 } 954 identity ns-slo-two-way-packet-loss { 955 base ns-slo-metric-type; 956 description 957 "SLO loss metric. The ratio of packets dropped to packets 958 transmitted between two endpoints in two-way 959 over a period of time as specified in RFC7680"; 960 } 962 identity ns-slo-availability { 963 base ns-slo-metric-type; 964 description 965 "SLO availability level."; 967 } 969 identity ns-match-type { 970 description 971 "Base identity for IETF Network Slice traffic match type."; 972 } 974 identity ns-phy-interface-match { 975 base ns-match-type; 976 description 977 "Use the physical interface as match criteria for the IETF 978 Network Slice traffic."; 979 } 981 identity ns-vlan-match { 982 base ns-match-type; 983 description 984 "Use the VLAN ID as match criteria for the IETF Network Slice 985 traffic."; 986 } 988 identity ns-label-match { 989 base ns-match-type; 990 description 991 "Use the MPLS label as match criteria for the IETF Network 992 Slice traffic."; 993 } 995 identity peering-protocol-type { 996 description 997 "Base identity for NSE peering protocol type."; 998 } 1000 identity peering-protocol-bgp { 1001 base peering-protocol-type; 1002 description 1003 "Use BGP as protocol for NSE peering with customer device."; 1004 } 1006 identity peering-static-routing { 1007 base peering-protocol-type; 1008 description 1009 "Use static routing for NSE peering with customer device."; 1010 } 1012 /* 1013 * Identity for availability-type 1014 */ 1016 identity availability-type { 1017 description 1018 "Base identity from which specific availability types are 1019 derived."; 1020 } 1022 identity level-1 { 1023 base availability-type; 1024 description 1025 "level 1: 99.9999%"; 1026 } 1028 identity level-2 { 1029 base availability-type; 1030 description 1031 "level 2: 99.999%"; 1032 } 1034 identity level-3 { 1035 base availability-type; 1036 description 1037 "level 3: 99.99%"; 1038 } 1040 identity level-4 { 1041 base availability-type; 1042 description 1043 "level 4: 99.9%"; 1044 } 1046 identity level-5 { 1047 base availability-type; 1048 description 1049 "level 5: 99%"; 1050 } 1052 /* typedef */ 1054 typedef operational-type { 1055 type enumeration { 1056 enum up { 1057 value 0; 1058 description 1059 "Operational status UP."; 1060 } 1061 enum down { 1062 value 1; 1063 description 1064 "Operational status DOWN."; 1065 } 1066 enum unknown { 1067 value 2; 1068 description 1069 "Operational status UNKNOWN."; 1070 } 1071 } 1072 description 1073 "This is a read-only attribute used to determine the 1074 status of a particular element."; 1075 } 1077 typedef ns-monitoring-type { 1078 type enumeration { 1079 enum one-way { 1080 description 1081 "Represents one-way measurments monitoring type."; 1082 } 1083 enum two-way { 1084 description 1085 "represents two-way measurements monitoring type."; 1086 } 1087 } 1088 description 1089 "An enumerated type for monitoring on a IETF Network Slice 1090 connection."; 1091 } 1093 /* Groupings */ 1095 grouping status-params { 1096 description 1097 "A grouping used to join operational and administrative status."; 1098 container status { 1099 description 1100 "A container for the administrative and operational state."; 1101 leaf admin-enabled { 1102 type boolean; 1103 description 1104 "The administrative status."; 1105 } 1106 leaf oper-status { 1107 type operational-type; 1108 config false; 1109 description 1110 "The operational status."; 1111 } 1113 } 1114 } 1116 grouping ns-match-criteria { 1117 description 1118 "A grouping for the IETF Network Slice match definition."; 1119 container ns-match-criteria { 1120 description 1121 "Describes the IETF Network Slice match criteria."; 1122 list ns-match-criterion { 1123 key "match-type"; 1124 description 1125 "List of the IETF Network Slice traffic match criteria."; 1126 leaf match-type { 1127 type identityref { 1128 base ns-match-type; 1129 } 1130 description 1131 "Identifies an entry in the list of the IETF Network Slice 1132 match criteria."; 1133 } 1134 list values { 1135 key "index"; 1136 description 1137 "List of match criteria values."; 1138 leaf index { 1139 type uint8; 1140 description 1141 "Index of an entry in the list."; 1142 } 1143 leaf value { 1144 type string; 1145 description 1146 "Describes the IETF Network Slice match criteria, e.g. 1147 IP address, VLAN, etc."; 1148 } 1149 } 1150 } 1151 } 1152 } 1154 grouping ns-connection-group-metric-bounds { 1155 description 1156 "Grouping of Network Slice metric bounds that 1157 are shared amongst multiple connections of a Network 1158 Slice."; 1159 leaf ns-slo-shared-bandwidth { 1160 type te-types:te-bandwidth; 1161 description 1162 "A limit on the bandwidth that is shared amongst 1163 multiple connections of an IETF Network Slice."; 1164 } 1165 } 1167 grouping ns-sles { 1168 description 1169 "Indirectly Measurable Objectives of a IETF Network 1170 Slice."; 1171 leaf-list security { 1172 type identityref { 1173 base ns-security-type; 1174 } 1175 description 1176 "The IETF Network Slice security SLE(s)"; 1177 } 1178 leaf isolation { 1179 type identityref { 1180 base ns-isolation-type; 1181 } 1182 default "ns-isolation-shared"; 1183 description 1184 "The IETF Network Slice isolation SLE requirement."; 1185 } 1186 leaf max-occupancy-level { 1187 type uint8 { 1188 range "1..100"; 1189 } 1190 description 1191 "The maximal occupancy level specifies the number of flows to 1192 be admitted."; 1193 } 1194 leaf mtu { 1195 type uint16; 1196 units "bytes"; 1197 mandatory true; 1198 description 1199 "The MTU specifies the maximum length in octets of data 1200 packets that can be transmitted by the NS. The value needs 1201 to be less than or equal to the minimum MTU value of 1202 all 'ep-network-access-points' in the NSEs of the NS. "; 1203 } 1204 container steering-constraints { 1205 description 1206 "Container for the policy of steering constraints 1207 applicable to IETF Network Slice."; 1208 container path-constraints { 1209 description 1210 "Container for the policy of path constraints 1211 applicable to IETF Network Slice."; 1212 } 1213 container service-function { 1214 description 1215 "Container for the policy of service function 1216 applicable to IETF Network Slice."; 1217 } 1218 } 1219 } 1221 grouping ns-metric-bounds { 1222 description 1223 "IETF Network Slice metric bounds grouping."; 1224 container ns-metric-bounds { 1225 description 1226 "IETF Network Slice metric bounds container."; 1227 list ns-metric-bound { 1228 key "metric-type"; 1229 description 1230 "List of IETF Network Slice metric bounds."; 1231 leaf metric-type { 1232 type identityref { 1233 base ns-slo-metric-type; 1234 } 1235 description 1236 "Identifies an entry in the list of metric type 1237 bounds for the IETF Network Slice."; 1238 } 1239 leaf metric-unit { 1240 type string; 1241 mandatory true; 1242 description 1243 "The metric unit of the parameter. For example, 1244 s, ms, ns, and so on."; 1245 } 1246 leaf value-description { 1247 type string; 1248 description 1249 "The description of previous value. "; 1250 } 1251 leaf bound { 1252 type uint64; 1253 default "0"; 1254 description 1255 "The Bound on the Network Slice connection metric. A 1256 zero indicate an unbounded upper limit for the 1257 specific metric-type."; 1258 } 1259 } 1260 } 1261 } 1263 grouping ep-peering { 1264 description 1265 "A grouping for the IETF Network Slice Endpoint peering."; 1266 container ep-peering { 1267 description 1268 "Describes NSE peering attributes."; 1269 list protocol { 1270 key "protocol-type"; 1271 description 1272 "List of the NSE peering protocol."; 1273 leaf protocol-type { 1274 type identityref { 1275 base peering-protocol-type; 1276 } 1277 description 1278 "Identifies an entry in the list of NSE peering 1279 protocol type."; 1280 } 1281 list attribute { 1282 key "index"; 1283 description 1284 "List of protocol attribute."; 1285 leaf index { 1286 type uint8; 1287 description 1288 "Index of an entry in the list."; 1289 } 1290 leaf attribute-description { 1291 type string; 1292 description 1293 "The description of the attribute. "; 1294 } 1295 leaf value { 1296 type string; 1297 description 1298 "Describes the value of protocol attribute, e.g. 1299 nexthop address, peer address, etc."; 1300 } 1301 } 1302 } 1303 } 1304 } 1305 grouping ep-network-access-points { 1306 description 1307 "Grouping for the endpoint network access definition."; 1308 container ep-network-access-points { 1309 description 1310 "List of network access points."; 1311 list ep-network-access-point { 1312 key "network-access-id"; 1313 description 1314 "The IETF Network Slice network access points 1315 related parameters."; 1316 leaf network-access-id { 1317 type string; 1318 description 1319 "Uniquely identifier a network access point."; 1320 } 1321 leaf network-access-description { 1322 type string; 1323 description 1324 "The network access point description."; 1325 } 1326 leaf network-access-node-id { 1327 type string; 1328 description 1329 "The network access point node ID in the case of 1330 multi-homing."; 1331 } 1332 leaf network-access-tp-id { 1333 type string; 1334 description 1335 "The termination port ID of the EP network access 1336 point."; 1337 } 1338 leaf network-access-tp-ip { 1339 type inet:host; 1340 description 1341 "The IP address of the EP network access point."; 1342 } 1343 leaf mtu { 1344 type uint16; 1345 units "bytes"; 1346 mandatory true; 1347 description 1348 "Maximum size in octets of a data packet that 1349 can traverse a NSE network access point. "; 1350 } 1351 /* Per ep-network-access-point rate limits */ 1352 uses ns-rate-limit; 1354 } 1355 } 1356 } 1358 grouping endpoint-monitoring-parameters { 1359 description 1360 "Grouping for the endpoint monitoring parameters."; 1361 container ep-monitoring { 1362 config false; 1363 description 1364 "Container for endpoint monitoring parameters."; 1365 leaf incoming-utilized-bandwidth { 1366 type te-types:te-bandwidth; 1367 description 1368 "Incoming bandwidth utilization at an endpoint."; 1369 } 1370 leaf incoming-bw-utilization { 1371 type decimal64 { 1372 fraction-digits 5; 1373 range "0..100"; 1374 } 1375 units "percent"; 1376 mandatory true; 1377 description 1378 "To be used to define the bandwidth utilization 1379 as a percentage of the available bandwidth."; 1380 } 1381 leaf outgoing-utilized-bandwidth { 1382 type te-types:te-bandwidth; 1383 description 1384 "Outoing bandwidth utilization at an endpoint."; 1385 } 1386 leaf outgoing-bw-utilization { 1387 type decimal64 { 1388 fraction-digits 5; 1389 range "0..100"; 1390 } 1391 units "percent"; 1392 mandatory true; 1393 description 1394 "To be used to define the bandwidth utilization 1395 as a percentage of the available bandwidth."; 1396 } 1397 } 1398 } 1400 grouping common-monitoring-parameters { 1401 description 1402 "Grouping for link-monitoring-parameters."; 1403 leaf latency { 1404 type yang:gauge64; 1405 units "usec"; 1406 description 1407 "The latency statistics per Network Slice connection. 1408 RFC2681 and RFC7679 discuss round trip times and one-way 1409 metrics, respectively"; 1410 } 1411 leaf jitter { 1412 type yang:gauge32; 1413 description 1414 "The jitter statistics per Network Slice member 1415 as defined by RFC3393."; 1416 } 1417 leaf loss-ratio { 1418 type decimal64 { 1419 fraction-digits 6; 1420 range "0 .. 50.331642"; 1421 } 1422 description 1423 "Packet loss as a percentage of the total traffic 1424 sent over a configurable interval. The finest precision is 1425 0.000003%. where the maximum 50.331642%."; 1426 reference 1427 "RFC 7810, section-4.4"; 1428 } 1429 } 1431 grouping geolocation-container { 1432 description 1433 "A grouping containing a GPS location."; 1434 container location { 1435 description 1436 "A container containing a GPS location."; 1437 leaf altitude { 1438 type int64; 1439 units "millimeter"; 1440 description 1441 "Distance above the sea level."; 1442 } 1443 leaf latitude { 1444 type decimal64 { 1445 fraction-digits 8; 1446 range "-90..90"; 1447 } 1448 description 1449 "Relative position north or south on the Earth's surface."; 1451 } 1452 leaf longitude { 1453 type decimal64 { 1454 fraction-digits 8; 1455 range "-180..180"; 1456 } 1457 description 1458 "Angular distance east or west on the Earth's surface."; 1459 } 1460 } 1461 // gps-location 1462 } 1464 // geolocation-container 1466 grouping ns-rate-limit { 1467 description 1468 "The Network Slice rate limit grouping."; 1469 container ep-rate-limit { 1470 description 1471 "Container for the asymmetric traffic control"; 1472 leaf incoming-rate-limit { 1473 type te-types:te-bandwidth; 1474 description 1475 "The rate-limit imposed on incoming traffic."; 1476 } 1477 leaf outgoing-rate-limit { 1478 type te-types:te-bandwidth; 1479 description 1480 "The rate-limit imposed on outgoing traffic."; 1481 } 1482 } 1483 } 1485 grouping endpoint { 1486 description 1487 "IETF Network Slice endpoint related information"; 1488 leaf ep-id { 1489 type string; 1490 description 1491 "unique identifier for the referred IETF Network 1492 Slice endpoint"; 1493 } 1494 leaf ep-description { 1495 type string; 1496 description 1497 "endpoint name"; 1498 } 1499 leaf ep-role { 1500 type identityref { 1501 base endpoint-role; 1502 } 1503 default "any-to-any-role"; 1504 description 1505 "Role of the endpoint in the IETF Network Slice."; 1506 } 1507 uses geolocation-container; 1508 leaf node-id { 1509 type string; 1510 description 1511 "Uniquely identifies an edge node within the IETF slice 1512 network."; 1513 } 1514 leaf ep-ip { 1515 type inet:host; 1516 description 1517 "The address of the endpoint IP address."; 1518 } 1519 uses ns-match-criteria; 1520 uses ep-peering; 1521 uses ep-network-access-points; 1522 uses ns-rate-limit; 1523 /* Per NSE rate limits */ 1524 uses status-params; 1525 uses endpoint-monitoring-parameters; 1526 } 1528 //ns-endpoint 1530 grouping ns-connection { 1531 description 1532 "The Network Slice connection is described in this container."; 1533 leaf ns-connection-id { 1534 type uint32; 1535 description 1536 "The Network Slice connection identifier"; 1537 } 1538 leaf ns-connection-description { 1539 type string; 1540 description 1541 "The Network Slice connection description"; 1542 } 1543 container src { 1544 description 1545 "the source of Network Slice link"; 1546 leaf src-ep-id { 1547 type leafref { 1548 path "/network-slices/network-slice" 1549 + "/ns-endpoints/ns-endpoint/ep-id"; 1550 } 1551 description 1552 "reference to source Network Slice endpoint"; 1553 } 1554 } 1555 container dest { 1556 description 1557 "the destination of Network Slice link "; 1558 leaf dest-ep-id { 1559 type leafref { 1560 path "/network-slices/network-slice" 1561 + "/ns-endpoints/ns-endpoint/ep-id"; 1562 } 1563 description 1564 "reference to dest Network Slice endpoint"; 1565 } 1566 } 1567 uses ns-slo-sle-policy; 1568 /* Per connection ns-slo-sle-policy overrides 1569 * the per network slice ns-slo-sle-policy. 1570 */ 1571 leaf monitoring-type { 1572 type ns-monitoring-type; 1573 description 1574 "One way or two way monitoring type."; 1575 } 1576 container ns-connection-monitoring { 1577 config false; 1578 description 1579 "SLO status Per network-slice endpoint to endpoint "; 1580 uses common-monitoring-parameters; 1581 } 1582 } 1584 //ns-connection 1586 grouping slice-template { 1587 description 1588 "Grouping for slice-templates."; 1589 container ns-slo-sle-templates { 1590 description 1591 "Contains a set of network slice templates to 1592 reference in the IETF network slice."; 1593 list ns-slo-sle-template { 1594 key "id"; 1595 leaf id { 1596 type string; 1597 description 1598 "Identification of the Service Level Objective (SLO) 1599 and Service Level Expectation (SLE) template to be used. 1600 Local administration meaning."; 1601 } 1602 leaf template-description { 1603 type string; 1604 description 1605 "Description of the SLO & SLE policy template."; 1606 } 1607 description 1608 "List for SLO and SLE template identifiers."; 1609 } 1610 } 1611 } 1613 /* Configuration data nodes */ 1615 grouping ns-slo-sle-policy { 1616 description 1617 "Network Slice policy grouping."; 1618 choice ns-slo-sle-policy { 1619 description 1620 "Choice for SLO and SLE policy template. 1621 Can be standard template or customized template."; 1622 case standard { 1623 description 1624 "Standard SLO template."; 1625 leaf slo-sle-template { 1626 type leafref { 1627 path "/network-slices" 1628 + "/ns-slo-sle-templates/ns-slo-sle-template/id"; 1629 } 1630 description 1631 "Standard SLO and SLE template to be used."; 1632 } 1633 } 1634 case custom { 1635 description 1636 "Customized SLO template."; 1637 container slo-sle-policy { 1638 description 1639 "Contains the SLO policy."; 1640 leaf policy-description { 1641 type string; 1642 description 1643 "Description of the SLO policy."; 1644 } 1645 uses ns-metric-bounds; 1646 uses ns-sles; 1647 } 1648 } 1649 } 1650 } 1652 container network-slices { 1653 description 1654 "IETF network-slice configurations"; 1655 uses slice-template; 1656 list network-slice { 1657 key "ns-id"; 1658 description 1659 "a network-slice is identified by a ns-id"; 1660 leaf ns-id { 1661 type string; 1662 description 1663 "A unique network-slice identifier across an IETF NSC "; 1664 } 1665 leaf ns-description { 1666 type string; 1667 description 1668 "Give more description of the network slice"; 1669 } 1670 leaf-list customer-name { 1671 type string; 1672 description 1673 "List of the customer that actually uses the slice. 1674 In the case that multiple customers sharing 1675 same slice service, e.g., 5G, customer name may 1676 help with operational management"; 1677 } 1678 leaf ns-connectivity-type { 1679 type identityref { 1680 base ns-connectivity-type; 1681 } 1682 default "any-to-any"; 1683 description 1684 "Network Slice topology."; 1685 } 1686 uses ns-slo-sle-policy; 1687 uses status-params; 1688 container ns-endpoints { 1689 description 1690 "Endpoints"; 1692 list ns-endpoint { 1693 key "ep-id"; 1694 uses endpoint; 1695 description 1696 "List of endpoints in this slice"; 1697 } 1698 } 1699 container ns-connections { 1700 description 1701 "Connections container"; 1702 list ns-connection { 1703 key "ns-connection-id"; 1704 description 1705 "List of Network Slice connections."; 1706 uses ns-connection; 1707 } 1708 } 1709 } 1710 //ietf-network-slice list 1711 } 1712 } 1713 1715 9. Security Considerations 1717 The YANG module defined in this document is designed to be accessed 1718 via network management protocols such as NETCONF [RFC6241] or 1719 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1720 layer, and the mandatory-to-implement secure transport is Secure 1721 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1722 mandatory-to-implement secure transport is TLS [RFC8446]. 1724 The NETCONF access control model [RFC8341] provides the means to 1725 restrict access for particular NETCONF or RESTCONF users to a 1726 preconfigured subset of all available NETCONF or RESTCONF protocol 1727 operations and content. 1729 There are a number of data nodes defined in this YANG module that are 1730 writable/creatable/deletable (i.e., config true, which is the 1731 default). These data nodes may be considered sensitive or vulnerable 1732 in some network environments. Write operations (e.g., edit-config) 1733 to these data nodes without proper protection can have a negative 1734 effect on network operations. 1736 o /ietf-network-slice/network-slices/network-slice 1737 The entries in the list above include the whole network 1738 configurations corresponding with the slice which the higher 1739 management system requests, and indirectly create or modify the PE or 1740 P device configurations. Unexpected changes to these entries could 1741 lead to service disruption and/or network misbehavior. 1743 10. IANA Considerations 1745 This document registers a URI in the IETF XML registry [RFC3688]. 1746 Following the format in [RFC3688], the following registration is 1747 requested to be made: 1749 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 1750 Registrant Contact: The IESG. 1751 XML: N/A, the requested URI is an XML namespace. 1753 This document requests to register a YANG module in the YANG Module 1754 Names registry [RFC7950]. 1756 Name: ietf-network-slice 1757 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 1758 Prefix: ietf-ns 1759 Reference: RFC XXXX 1761 11. Acknowledgments 1763 The authors wish to thank Mohamed Boucadair, Kenichi Ogaki, Sergio 1764 Belotti, Qin Wu, Susan Hares, Eric Grey, and many others for their 1765 helpful comments and suggestions. 1767 12. References 1769 12.1. Normative References 1771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1772 Requirement Levels", BCP 14, RFC 2119, 1773 DOI 10.17487/RFC2119, March 1997, 1774 . 1776 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1777 DOI 10.17487/RFC3688, January 2004, 1778 . 1780 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1781 and A. Bierman, Ed., "Network Configuration Protocol 1782 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1783 . 1785 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1786 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1787 . 1789 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1790 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1791 . 1793 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1794 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1795 . 1797 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1798 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1799 . 1801 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1802 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1803 May 2017, . 1805 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1806 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1807 . 1809 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1810 Access Control Model", STD 91, RFC 8341, 1811 DOI 10.17487/RFC8341, March 2018, 1812 . 1814 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1815 and R. Wilton, "Network Management Datastore Architecture 1816 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1817 . 1819 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1820 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1821 . 1823 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1824 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1825 and Datastores over NETCONF", RFC 8640, 1826 DOI 10.17487/RFC8640, September 2019, 1827 . 1829 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1830 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1831 September 2019, . 1833 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1834 "Common YANG Data Types for Traffic Engineering", 1835 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1836 . 1838 12.2. Informative References 1840 [I-D.geng-teas-network-slice-mapping] 1841 Geng, X., Dong, J., Pang, R., Han, L., Niwa, T., Jin, J., 1842 Liu, C., and N. Nageshar, "5G End-to-end Network Slice 1843 Mapping from the view of Transport Network", Work in 1844 Progress, Internet-Draft, draft-geng-teas-network-slice- 1845 mapping-03, 22 February 2021, 1846 . 1849 [I-D.ietf-opsawg-vpn-common] 1850 Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A 1851 Layer 2/3 VPN Common YANG Model", Work in Progress, 1852 Internet-Draft, draft-ietf-opsawg-vpn-common-11, 23 1853 September 2021, . 1856 [I-D.ietf-teas-actn-vn-yang] 1857 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 1858 Yoon, "A YANG Data Model for VN Operation", Work in 1859 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-12, 1860 25 August 2021, . 1863 [I-D.ietf-teas-ietf-network-slices] 1864 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 1865 Makhijani, K., Contreras, L. M., and J. Tantsura, 1866 "Framework for IETF Network Slices", Work in Progress, 1867 Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 1868 August 2021, . 1871 [I-D.liu-teas-transport-network-slice-yang] 1872 Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu, 1873 Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG 1874 Data Model", Work in Progress, Internet-Draft, draft-liu- 1875 teas-transport-network-slice-yang-04, 9 July 2021, 1876 . 1879 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1880 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1881 . 1883 Appendix A. IETF Network Slice NBI Model Usage Example 1885 The following example describes a simplified service configuration of 1886 two IETF Network slice instances: 1888 * IETF Network Slice 1 on Device1, Device3, and Device4, with any- 1889 to-any connectivity type 1891 * IETF Network Slice 2 on Device2, Device3, with any-to-any 1892 connectivity type 1894 192.0.2.2 VLAN1 1895 +--------+ 1896 |Device1 o------/ 1897 +--------+ | +------+ 1898 +--------+ +------o| A +---------------+ 1899 |Device2 o-------/-----o| | | 1900 +--------+ +---+--+ | 1901 198.51.100.2 | | 1902 VLAN2 | +---+--+ 192.0.2.4 VLAN1 1903 | | | +--------+ 1904 192.0.2.3 VLAN1 | | C o-----/-----oDevice4 | 1905 +--------+ | +---+--+ +--------+ 1906 | o------/ | | 1907 | | | +---+--+ | 1908 | Device3| +------o| B +---------------+ 1909 | o-------/-----o| | 1910 +--------+ +------+ 1911 198.51.100.3 1912 VLAN2 1914 POST: /restconf/data/ietf-network-slice:ietf-network-slices 1915 Host: example.com 1916 Content-Type: application/yang-data+json 1917 { 1918 "network-slices":{ 1919 "network-slice":[ 1920 { 1921 "ns-id":"1", 1922 "ns-description":"slice1", 1923 "ns-connectivity-type":"any-to-any", 1924 "ns-endpoints":{ 1925 "ns-endpoint":[ 1926 { 1927 "ep-id":"11", 1928 "ep-description":"slice1 ep1 connected to device 1", 1929 "ep-role":"any-to-any-role", 1930 "ns-match-criteria":[ 1931 { 1932 "match-type":"ns-vlan-match", 1933 "value":[ 1934 { 1935 "index":"1", 1936 "value":"1" 1937 } 1938 ] 1939 } 1940 ] 1941 }, 1942 { 1943 "ep-id":"12", 1944 "ep-description":"slice1 ep2 connected to device 3", 1945 "ep-role":"any-to-any-role", 1946 "ns-match-criteria":[ 1947 { 1948 "match-type":"ns-vlan-match", 1949 "value":[ 1950 { 1951 "index":"1", 1952 "value":"20" 1953 } 1954 ] 1955 } 1956 ] 1957 }, 1958 { 1959 "ep-id":"13", 1960 "ep-description":"slice1 ep3 connected to device 4", 1961 "ep-role":"any-to-any-role", 1962 "ns-match-criteria":[ 1963 { 1964 "match-type":"ns-vlan-match", 1965 "value":[ 1966 { 1967 "index":"1", 1968 "value":"1" 1969 } 1970 ] 1971 } 1972 ] 1973 } 1975 ] 1976 } 1977 }, 1978 { 1979 "ns-id":"ns2", 1980 "ns-description":"slice2", 1981 "ns-connectivity-type":"any-to-any", 1982 "ns-endpoints":{ 1983 "ns-endpoint":[ 1984 { 1985 "ep-id":"21", 1986 "ep-description":"slice2 ep1 connected to device 2", 1987 "ep-role":"any-to-any-role", 1988 "ns-match-criteria":[ 1989 { 1990 "match-type":"ns-vlan-match", 1991 "value":[ 1992 { 1993 "index":"1", 1994 "value":"2" 1995 } 1996 ] 1997 } 1998 ] 1999 }, 2000 { 2001 "ep-id":"22", 2002 "ep-description":"slice2 ep2 connected to device 3", 2003 "ep-role":"any-to-any-role", 2004 "ns-match-criteria":[ 2005 { 2006 "match-type":"ns-vlan-match", 2007 "value":[ 2008 { 2009 "index":"1", 2010 "value":"2" 2011 } 2012 ] 2013 } 2014 ] 2015 } 2016 ] 2017 } 2018 } 2019 ] 2020 } 2021 } 2023 Appendix B. Comparison with Other Possible Design choices for IETF 2024 Network Slice NBI 2026 According to the 5.3.2 Northbound Inteface (NBI) 2027 [I-D.ietf-teas-ietf-network-slices], the IETF Network Slice NBI is a 2028 technology-agnostic interface, which is used for a customer to 2029 express requirements for a particular IETF Network Slice. Customers 2030 operate on abstract IETF Network Slices, with details related to 2031 their realization hidden. As classified by [RFC8309], the IETF 2032 Network Slice NBI is classified as Customer Service Model. 2034 This draft analyzes the following existing IETF models to identify 2035 the gap between the IETF Network Slice NBI requirements. 2037 B.1. ACTN VN Model Augmentation 2039 The difference between the ACTN VN model and the IETF Network Slice 2040 NBI requirements is that the IETF Network Slice NBI is a technology- 2041 agnostic interface, whereas the VN model is bound to the IETF TE 2042 Topologies. The realization of the IETF Network Slice does not 2043 necessarily require the slice network to support the TE technology. 2045 The ACTN VN (Virtual Network) model introduced 2046 in[I-D.ietf-teas-actn-vn-yang] is the abstract customer view of the 2047 TE network. Its YANG structure includes four components: 2049 * VN: A Virtual Network (VN) is a network provided by a service 2050 provider to a customer for use and two types of VN has defined. 2051 The Type 1 VN can be seen as a set of edge-to-edge abstract links. 2052 Each link is an abstraction of the underlying network which can 2053 encompass edge points of the customer's network, access links, 2054 intra-domain paths, and inter-domain links. 2056 * AP: An AP is a logical identifier used to identify the access link 2057 which is shared between the customer and the IETF scoped Network. 2059 * VN-AP: A VN-AP is a logical binding between an AP and a given VN. 2061 * VN-member: A VN-member is an abstract edge-to-edge link between 2062 any two APs or VN-APs. Each link is formed as an E2E tunnel 2063 across the underlying networks. 2065 The Type 1 VN can be used to describe IETF Network Slice connection 2066 requirements. However, the Network Slice SLO and Network Slice 2067 Endpoint are not clearly defined and there's no direct equivalent. 2068 For example, the SLO requirement of the VN is defined through the 2069 IETF TE Topologies YANG model, but the TE Topologies model is related 2070 to a specific implementation technology. Also, VN-AP does not define 2071 "network-slice-match-criteria" to specify a specific NSE belonging to 2072 an IETF Network Slice. 2074 B.2. RFC8345 Augmentation Model 2076 The difference between the IETF Network Slice NBI requirements and 2077 the IETF basic network model is that the IETF Network Slice NBI 2078 requests abstract customer IETF Network Slices, with details related 2079 to the slice Network hidden. But the IETF network model is used to 2080 describe the interconnection details of a Network. The customer 2081 service model does not need to provide details on the Network. 2083 For example, IETF Network Topologies YANG data model extension 2084 introduced in Transport Network Slice YANG Data Model 2085 [I-D.liu-teas-transport-network-slice-yang] includes three major 2086 parts: 2088 * Network: a transport network list and an list of nodes contained 2089 in the network 2091 * Link: "links" list and "termination points" list describe how 2092 nodes in a network are connected to each other 2094 * Support network: vertical layering relationships between IETF 2095 Network Slice networks and underlay networks 2097 Based on this structure, the IETF Network Slice-specific SLO 2098 attributes nodes are augmented on the Network Topologies model,, e.g. 2099 isolation etc. However, this modeling design requires the slice 2100 network to expose a lot of details of the network, such as the actual 2101 topology including nodes interconnection and different network layers 2102 interconnection. 2104 Appendix C. Appendix B IETF Network Slice Match Criteria 2106 5G is a use case of the IETF Network Slice and 5G End-to-end Network 2107 Slice Mapping from the view of IETF 2108 Network[I-D.geng-teas-network-slice-mapping] 2110 defines two types of Network Slice interconnection and 2111 differentiation methods: by physical interface or by TNSII (Transport 2112 Network Slice Interworking Identifier). TNSII is a field in the 2113 packet header when different 5G wireless network slices are 2114 transported through a single physical interfaces of the IETF scoped 2115 Network. In the 5G scenario, "network-slice-match-criteria" refers 2116 to TNSII. 2118 +------------------------------------------------------------+ 2119 | 5G E2E network slice orchestrator | 2120 ++-----------------------------------------------------+-----+ 2121 | | | 2122 | IETF Network Slice NBI | 2123 +---+-------+ | +-----+-----+ 2124 | | +------------------+ | | 2125 |RAN Slice | |IETF Network Slice| |Core Slice | 2126 |controller | | controller | | controller| 2127 +----+------+ +-------+----------+ +-----+-----+ 2128 | | | 2129 | | | 2130 +---+--+ +------------+----------------+ ++-----+ 2131 | | | | | | 2132 | | | | | | 2133 |+----+| | | | | 2134 || ||NS1-NSE1 | Network Slice 1 | |+----+| 2135 ||gNB1|+---------+-----+-----------------------+--------+|UPF1|| 2136 || |+************ / |NS1-NSE3|+----+| 2137 |+----+|NS2-NSE1 | */ | | | 2138 | | /* | | | 2139 |+----+|NS1-NSE2 | / * | | | 2140 || |+---------- * Network Slice 2 |NS2-NSE3|+----+| 2141 ||gNB2|+************************************************+|UPF2|| 2142 || ||NS2-NSE2 | | |+----+| 2143 |+----+| | | | 2144 | | | | | | 2145 | | | | | | 2146 +------+ +----------- -----------------+ +------+ 2148 As shown in the figure, gNodeB 1 and gNodeB 2 use IP gNB1 and IP gNB2 2149 to communicate with the IETF network, respectively. In addition, the 2150 traffic of NS1 and NS2 on gNodeB 1 and gNodeB 2 is transmitted 2151 through the same access links to the IETF slice network. The IETF 2152 slice network need to to distinguish different IETF Network Slice 2153 traffic of same gNB. Therefore, in addition to using "node-id" and 2154 "ep-ip" to identify a Network Slice Endpont, other information is 2155 needed along with these parameters to uniquely distinguish a NSE. 2156 For example, VLAN IDs in the user traffic can be used to distinguish 2157 the NSEs of gNBs and UPFs. 2159 Authors' Addresses 2161 Bo Wu 2162 Huawei Technologies 2163 101 Software Avenue, Yuhua District 2164 Nanjing 2165 Jiangsu, 210012 2166 China 2168 Email: lana.wubo@huawei.com 2170 Dhruv Dhody 2171 Huawei Technologies 2172 Divyashree Techno Park 2173 Bangalore 560066 2174 Karnataka 2175 India 2177 Email: dhruv.ietf@gmail.com 2179 Reza Rokui 2180 Nokia 2182 Email: reza.rokui@nokia.com 2184 Tarek Saad 2185 Juniper Networks 2187 Email: tsaad@juniper.net 2189 Liuyan Han 2190 China Mobile 2192 Email: hanliuyan@chinamobile.com