idnits 2.17.1 draft-ietf-teas-ietf-network-slice-definition-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2021) is 1163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EP11' is mentioned on line 432, but not defined == Missing Reference: 'EP21' is mentioned on line 432, but not defined == Missing Reference: 'EP12' is mentioned on line 434, but not defined == Missing Reference: 'EP22' is mentioned on line 434, but not defined == Missing Reference: 'EP1m' is mentioned on line 436, but not defined == Missing Reference: 'EP2n' is mentioned on line 436, but not defined == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-01 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-05 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 teas R. Rokui 3 Internet-Draft Nokia 4 Intended status: Informational S. Homma 5 Expires: July 25, 2021 NTT 6 K. Makhijani 7 Futurewei 8 LM. Contreras 9 Telefonica 10 J. Tantsura 11 Apstra, Inc. 12 January 21, 2021 14 Definition of IETF Network Slices 15 draft-ietf-teas-ietf-network-slice-definition-00 17 Abstract 19 This document provides a definition of the term "IETF Network Slice" 20 for use within the IETF and specifically as a reference for other 21 IETF documents that describe or use aspects of network slices. 23 The document also describes the characteristics of an IETF network 24 slice, related terms and their meanings, and explains how IETF 25 network slices can be used in combination with end-to-end network 26 slices or independent of them. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 25, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 64 3. Definition and Scope of IETF Network Slice . . . . . . . . . 4 65 4. IETF Network Slice System Characteristics . . . . . . . . . . 4 66 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 5 67 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 5 68 4.1.2. Minimal Set of SLOs . . . . . . . . . . . . . . . . . 5 69 4.1.3. Other Objectives . . . . . . . . . . . . . . . . . . 7 70 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 7 71 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 9 72 4.3. IETF Network Slice Composition . . . . . . . . . . . . . 9 73 5. IETF Network Slice Structure . . . . . . . . . . . . . . . . 10 74 6. IETF Network Slice Stakeholders . . . . . . . . . . . . . . . 11 75 7. IETF Network Slice Controller Interfaces . . . . . . . . . . 12 76 8. Realizing IETF Network Slice . . . . . . . . . . . . . . . . 12 77 9. Isolation in IETF Network Slices . . . . . . . . . . . . . . 13 78 9.1. Isolation as a Service Requirement . . . . . . . . . . . 13 79 9.2. Isolation in IETF Network Slice Realization . . . . . . . 13 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 83 13. Informative References . . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 A number of use cases benefit from network connections that along 89 with the connectivity provide assurance of meeting a specific set of 90 objectives wrt network resources use. In this document, as detailed 91 in the subsequent sections, we refer to this connectivity and 92 resource commitment as an IETF network slice. Services that might 93 benefit from the network slices include but not limited to: 95 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP]) 97 o Network wholesale services 99 o Network infrastructure sharing among operators 101 o NFV connectivity and Data Center Interconnect 103 The use cases are further described in [I-D.nsdt-teas-ns-framework]. 105 This document defines the concept of IETF network slices that provide 106 connectivity coupled with a set of specific commitments of network 107 resources between a number of endpoints over a shared network 108 infrastructure. Since the term network slice is rather generic, the 109 qualifying term 'IETF' is used in this document to limit the scope of 110 network slice to network technologies described and standardized by 111 the IETF. 113 IETF network slices are created and managed within the scope of one 114 or more network technologies (e.g., IP, MPLS, optical). They are 115 intended to enable a diverse set of applications that have different 116 requirements to coexist on the same network infrastructure. A 117 request for an IETF network slice is technology-agnostic so as to 118 allow a consumer to describe their network connectivity objectives in 119 a common format, independent of the underlying technologies used. 121 2. Terms and Abbreviations 123 The terms and abbreviations used in this document are listed below. 125 o NS: Network Slice 127 o NSC: Network Slice Controller 129 o NBI: NorthBound Interface 131 o SBI: SouthBound Interface 133 o SLI: Service Level Indicator 135 o SLO: Service Level Objective 137 o SLA: Service Level Agreement 138 The above terminology is defined in greater details in the remainder 139 of this document. 141 3. Definition and Scope of IETF Network Slice 143 The definition of a network slice in IETF context is as follows: 145 An IETF network slice is a logical network topology connecting a 146 number of endpoints using a set of shared or dedicated network 147 resources that are used to satisfy specific Service Level Objectives 148 (SLOs). 150 An IETF network slice combines the connectivity resource requirements 151 and associated network behaviors such as bandwidth, latency, jitter, 152 and network functions with other resource behaviors such as compute 153 and storage availability. IETF network slices are independent of the 154 underlying infrastructure connectivity and technologies used. This 155 is to allow an IETF network slice consumer to describe their network 156 connectivity and relevant objectives in a common format, independent 157 of the underlying technologies used. 159 IETF network slices may be combined hierarchically, so that a network 160 slice may itself be sliced. They may also be combined sequentially 161 so that various different networks can each be sliced and the network 162 slices placed into a sequence to provide an end-to-end service. This 163 form of sequential combination is utilized in some services such as 164 in 3GPP's 5G network [TS.23.501-3GPP]. 166 An IETF network slice is technology-agnostic, and the means for IETF 167 network slice realization can be chosen depending on several factors 168 such as: service requirements, specifications or capabilities of 169 underlying infrastructure. The structure and different 170 characteristics of IETF network slices are described in the following 171 sections. 173 Term "Slice" refers to a set of characteristics and behaviours that 174 separate one type of user-traffic from another. IETF network slice 175 assumes that an underlying network is capable of changing the 176 configurations of the network devices on demand, through in-band 177 signaling or via controller(s) and fulfilling all or some of SLOs to 178 all of the traffic in the slice or to specific flows. 180 4. IETF Network Slice System Characteristics 182 The following subsections describe the characteristics of IETF 183 network slices. 185 4.1. Objectives for IETF Network Slices 187 An IETF network slice is defined in terms of several quantifiable 188 characteristics or service level objectives (SLOs). SLOs along with 189 terms Service Level Indicator (SLI) and Service Level Agreement (SLA) 190 are used to define the performance of a service at different levels. 192 A Service Level Indicator (SLI) is a quantifiable measure of an 193 aspect of the performance of a network. For example, it may be a 194 measure of throughput in bits per second, or it may be a measure of 195 latency in milliseconds. 197 A Service Level Objective (SLO) is a target value or range for the 198 measurements returned by observation of an SLI. For example, an SLO 199 may be expressed as "SLI <= target", or "lower bound <= SLI <= upper 200 bound". A network slice is expressed in terms of the set of SLOs 201 that are to be delivered for the different connections between 202 endpoints. 204 A Service Level Agreement (SLA) is an explicit or implicit contract 205 between the consumer of an IETF network slice and the provider of the 206 slice. The SLA is expressed in terms of a set of SLOs and may 207 include commercial terms as well as the consequences of missing/ 208 violating the SLOs they contain. 210 Additional descriptions of IETF network slice attributes is covered 211 in [I-D.contreras-teas-slice-nbi]. 213 4.1.1. Service Level Objectives 215 SLOs define a set of network attributes and characteristics that 216 describe an IETF network slice. SLOs do not describe 'how' the IETF 217 network slices are implemented or realized in the underlying network 218 layers. Instead, they are defined in terms of dimensions of 219 operation (time, capacity, etc.), availability, and other attributes. 220 An IETF network slice can have one or more SLOs associated with it. 221 The SLOs are combined in an SLA. The SLOs are defined for sets of 222 two or more endpoints and apply to specific directions of traffic 223 flow. That is, they apply to specific source endpoints and specific 224 connections between endpoints within the set of endpoints and 225 connections in the network slice. 227 4.1.2. Minimal Set of SLOs 229 This document defines a minimal set of SLOs and later systems or 230 standards could extend this set as per Section 4.1.3. 232 SLOs can be categorized in to 'Directly Measurable Objectives' or 233 'Indirectly Measurable Objectives'. Objectives such as guaranteed 234 minimum bandwidth, guaranteed maximum latency, maximum permissible 235 delay variation, maximum permissible packet loss rate, and 236 availability are 'Directly Measurable Objectives'. While 'Indirectly 237 Measurable Objectives' include security, geographical restrictions, 238 maximum occupancy level objectives. The later standard might define 239 other SLOs as needed. 241 Editor's Note TODO: replace Minimal set to most commonly used 242 objectives to describe network behavior. Other directly or 243 indirectly measurable objectives may be requested by that consumer of 244 an IETF network slice. 246 The definition of these objectives are as follows: 248 Guaranteed Minimum Bandwidth 250 Minimum guaranteed bandwidth between two endpoints at any time. 251 The bandwidth is measured in data rate units of bits per second 252 and is measured unidirectionally. 254 Guaranteed Maximum Latency 256 Upper bound of network latency when transmitting between two 257 endpoints. The latency is measured in terms of network 258 characteristics (excluding application-level latency). 259 [RFC2681] and [RFC7679] discuss round trip times and one-way 260 metrics, respectively. 262 Maximum Permissible Delay Variation 264 Packet delay variation (PDV) as defined by [RFC3393], s the 265 difference in the one-way delay between sequential packets in a 266 flow. This SLO sets a maximum value PDV for packets between 267 two endpoints. 269 Maximum permissible packet loss rate 271 The ratio of packets dropped to packets transmitted between two 272 endpoints over a period of time. See [RFC7680] 274 Availability 276 The ratio of uptime to the sum of uptime and downtime, where 277 uptime is the time the IETF network slice is available in 278 accordance with the SLOs associated with it. 280 Security 282 An IETF network slice consumer may request that the network 283 applies encryption or other security techniques to traffic 284 flowing between endpoints. 286 Note that the use of security or the violation of this SLO is 287 not directly observable by the IETF network slice consumer and 288 cannot be measured as a quantifiable metric. 290 Also note that the objective may include request for encryption 291 (e.g., [RFC4303]) between the two endpoints explicitly to meet 292 architecture recommendations as in [TS33.210] or for compliance 293 with [HIPAA] and/or [PCI]. 295 Editor's Note: Please see more discussion on security in 296 Section 10. 298 4.1.3. Other Objectives 300 Additional SLOs may be defined to provide additional description of 301 the IETF network slice that a consumer requests. 303 If the IETF network slice consumer service is traffic aware, other 304 traffic specific characteristics may be valuable including MTU, 305 traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a 306 higher-level behavior to process traffic according to user- 307 application (which may be realized using network functions). 309 Maximal occupancy for an IETF network slice should be provided. 310 Since it carries traffic for multiple flows between the two 311 endpoints, the objectives should also say if they are for the entire 312 connection, group of flows or on per flow basis. Maximal occupancy 313 should specify the scale of the flows (i.e. maximum number of flows 314 to be admitted) and optionally a maximum number of countable resource 315 units, e.g IP or MAC addresses a slice might consume. 317 4.2. IETF Network Slice Endpoints 319 As noted in Section 3, an IETF network slice describes connectivity 320 between endpoints across the underlying network. This connectivity 321 may be be point-to-point, point-to-multipoint (P2MP), multipoint-to- 322 point, or multipoint-to-multipoint. 324 The characteristics of IETF network slice endpoints (NSEs) are as 325 follows. 327 o They are conceptual points of connection of a consumer network, 328 network function, device, or application to the IETF network 329 slice. This might include routers, switches, firewalls, WAN, 330 4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep 331 Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], 332 NAT64 [RFC6146], HTTP header enrichment functions, and TCP 333 optimizers. 335 o They are identified in a request provided by the consumer of an 336 IETF network slice when the IETF network slice is requested. 338 o An NSE is identified a unique identifier and/or a unique name and 339 other data. A non-exhaustive list of other data includes IPv4 or 340 IPv6 address, VLAN tag, port number, connectivity type (P2P, P2MP, 341 MP2MP). 343 Note that the NSE is different from access points (AP) defined in 344 [RFC8453] as an AP is a logical identifier to identify the shared 345 link between the consumer and the operator where as NSE is an 346 identifier of an endpoint. Also NSE is different from TE Link 347 Termination Point (LTP) defined in [I-D.ietf-teas-yang-te-topo] as it 348 is a conceptual point of connection of a TE node to one of the TE 349 links on a TE node. 351 The NSE is similar to the Termination Point (TP) defined in [RFC8345] 352 and can contain more attributes. NSE could be modeled by augmenting 353 the TP model. 355 There is another type of the endpoints called "IETF Network Slice 356 Realization Endpoints (NSREs)". These endpoints are allocated and 357 assigned by the network controller during the realization of an IETF 358 network slice and are technology-specific, i.e. they depend on the 359 network technology used during the IETF network slice realization. 360 The identification of NSREs forms part of the realization of the IETF 361 network slice and is implementation and deployment specific. 363 Figure 1 shows an example of an IETF network slice and its 364 realization between multiple NSEs and NSREs. 366 (-------------------) 367 ( IETF scoped Network ) 368 DAN1 ( ) DAN2 369 -------- NSRE1 -------- -------- NSRE2 -------- 370 | o |-------o| A | | B |o--------| o | 371 | NSE1| -------- -------- | NSE2 | 372 -------- | ( ) | -------- 373 | | ( ) | | 374 | | (-------------------) | | 375 | | | | 376 | | <=============================> | | 377 | IETF Network Slice realization | 378 | between NSRE1 and NSRE2 | 379 | | 380 | <===================================================> | 381 IETF Network Slice between NSE1 and NSE2 with SLO1 383 Legend: 384 DAN: Device, application and/or network function 386 Figure 1: An IETF Network Slice between NSEs and its realization 387 between NSREs 389 4.2.1. IETF Network Slice Connectivity Types 391 The IETF Network Slice connection types can be point to point (P2P), 392 point to multipoint (P2MP), multi-point to point (MP2P), or multi- 393 point to multi-point (MP2MP). They will requested by the higher 394 level operation system. 396 4.3. IETF Network Slice Composition 398 Operationally, an IETF network slice maybe decomposed in two or more 399 IETF network slices as specified below. Decomposed network slices 400 are then independently realized and managed. 402 o Hierarchical (i.e., recursive) composition: An IETF network slice 403 can be further sliced into other network slices. Recursive 404 composition allows an IETF network slice at one layer to be used 405 by the other layers. This type of multi-layer vertical IETF 406 network slice associates resources at different layers. 408 o Sequential composition: Different IETF network slices can be 409 placed into a sequence to provide an end-to-end service. In 410 sequential composition, each IETF network slice would potentially 411 support different dataplanes that need to be stitched together. 413 5. IETF Network Slice Structure 415 Editor's note: This content of this section merged with Relationship 416 with E2E slice discussion. 418 An IETF network slice is a set of connections among various endpoints 419 to form a logical network that meets the SLOs agreed upon. 421 ____________________________ 422 [EP11]------/ /--[EP21] 423 / / 424 [EP12]----/ IETF Network Slice /----[EP22] 425 : / (SLOs e.g. / 426 : / B/W > x bps, Delay < y ms)/ 427 [EP1m]-/___________________________/-------[EP2n] 429 == == == == == == == == == == == == == == == == == == 431 .--. .--. 432 [EP11] ( )- . ( )- . [EP21] 433 .' ' SLO .' ' 434 [EP12] ( Network-1 ) ... ( Network-p ) [EP22] 435 : `-----------' `-----------' : 436 [EP1m] [EP2n] 438 Legend 439 SLOs in terms of attributes, e.g. BW, delay. 440 EP: Endpoint 441 B/W: Bandwidth 443 Figure 2: IETF Network slice 445 Figure 2 illustrates a case where an IETF network slice provides 446 connectivity between a set of endpoints pairs with specific 447 characteristics for each SLO (e.g. guaranteed minimum bandwidth of x 448 bps and guaranteed delay of no more than y ms). The endpoints may be 449 distributed in the underlay networks, and an IETF network slice can 450 be deployed across multiple network domains. Also, the endpoints on 451 the same IETF network slice may belong to the same or different 452 address spaces. 454 IETF Network slice structure fits into a broader concept of end-to- 455 end network slices. A network operator may be responsible for 456 delivering services over a number of technologies (such as radio 457 networks) and for providing specific and fine-grained services (such 458 as CCTV feed or High definition realtime traffic data). That 459 operator may need to combine slices of various networks to produce an 460 end-to-end network service. Each of these networks may include 461 multiple physical or virtual nodes and may also provide network 462 functions beyond simply carrying of technology-specific protocol data 463 units.An end-to-end network slice is defined by the 3GPP as a 464 complete logical network that provides a service in its entirety with 465 a specific assurance to the consumer [TS.23.501-3GPP]. 467 An end-to-end network slice may be composed from other network slices 468 that include IETF network slices. This composition may include the 469 hierarchical (or recursive) use of underlying network slices and the 470 sequential (or stitched) combination of slices of different networks. 472 6. IETF Network Slice Stakeholders 474 An IETF network slice and its realization involves the following 475 stakeholders and it is relevant to define them for consistent 476 terminology. 478 Consumer: A consumer is the requester of an IETF network slice. 479 Consumers may request monitoring of SLOs. A consumer may manage 480 the IETF network slice service directly by interfacing with the 481 IETF network slice controller or indirectly through an 482 orchestrator. 484 Orchestrator: An orchestrator is an entity that composes different 485 services, resource and network requirements. It interfaces with 486 the IETF network slice controllers. 488 IETF Network Slice Controller (NSC): It realizes an IETF network 489 lice in the underlying network, maintains and monitors the run- 490 time state of resources and topologies associated with it. A 491 well-defined interface is needed between different types of IETF 492 network slice controllers and different types of orchestrators. 493 An IETF network slice operator (or slice operator for short) 494 manages one or more IETF network slices using the IETF network 495 slice Controller(s). 497 Network Controller: is a form of network infrastructure controller 498 that offers network resources to NSC to realize a particular 499 network slice. These may be existing network controllers 500 associated with one or more specific technologies that may be 501 adapted to the function of realizing IETF network slices in a 502 network. 504 7. IETF Network Slice Controller Interfaces 506 The interworking and interoperability among the different 507 stakeholders to provide common means of provisioning, operating and 508 monitoring the IETF Network slices is enabled by the following 509 communication interfaces (see Figure 3). 511 NSC Northbound Interface (NBI): The NSC Northbound Interface is an 512 interface between a consumer's higher level operation system 513 (e.g., a network slice orchestrator) and the NSC. It is a 514 technology agnostic interface. The consumer can use this 515 interface to communicate the requested characteristics and other 516 requirements (i.e., the SLOs) for the IETF network slice, and the 517 NSC can use the interface to report the operational state of an 518 IETF network slice to the consumer. 520 NSC Southbound Interface (SBI): The NSC Southbound Interface is an 521 interface between the NSC and network controllers. It is 522 technology-specific and may be built around the many network 523 models defined within the IETF. 525 +------------------------------------------+ 526 | Consumer higher level operation system | 527 | (e.g E2E network slice orchestrator) | 528 +------------------------------------------+ 529 A 530 | NSC NBI 531 V 532 +------------------------------------------+ 533 | IETF Network Slice Controller (NSC) | 534 +------------------------------------------+ 535 A 536 | NSC SBI 537 V 538 +------------------------------------------+ 539 | Network Controllers | 540 +------------------------------------------+ 542 Figure 3: Interface of IETF Network Slice Controller 544 8. Realizing IETF Network Slice 546 Realization of IETF network slices is out of scope of this document. 547 It is a mapping of the definition of the IETF network slice to the 548 underlying infrastructure and is necessarily technology-specific and 549 achieved by the NSC over the SBI. 551 The realization can be achieved in a form of either physical or 552 logical connectivity through VPNs (see, for example, 553 [I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies 554 such as Segment Routing, MPLS, etc. Accordingly, endpoints may be 555 realized as physical or logical service or network functions. 557 9. Isolation in IETF Network Slices 559 An IETF network slice consumer may request, that the IETF Network 560 Slice delivered to them is isolated from any other network slices of 561 services delivered to any other consumers. It is expected that the 562 changes to the other network slices of services do not have any 563 negative impact on the delivery of the IETF network slice. 565 9.1. Isolation as a Service Requirement 567 Isolation may be an important requirement of IETF network slices for 568 some critical services. A consumer may express this request as an 569 SLO. 571 This requirement can be met by simple conformance with other SLOs. 572 For example, traffic congestion (interference from other services) 573 might impact on the latency experienced by an IETF network slice. 574 Thus, in this example, conformance to a latency SLO would be the 575 primary requirement for delivery of the IETF network slice service, 576 and isolation from other services might be only a means to that end. 578 It should be noted that some aspects of isolation may be measurable 579 by a consumer who have the information about the traffic on a number 580 of IETF network slices or other services. 582 9.2. Isolation in IETF Network Slice Realization 584 Delivery of isolation is achieved in the realization of IETF network 585 slices, with existing, in-development, and potential new technologies 586 in IETF. It depends on how a network operator decides to operate 587 their network and deliver services. 589 Isolation may be achieved in the underlying network by various forms 590 of resource partitioning ranging from dedicated allocation of 591 resources for a specific IETF network slice, to sharing or resources 592 with safeguards. For example, traffic separation between different 593 IETF network slices may be achieved using VPN technologies, such as 594 L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by 595 network capacity planning, allocating dedicated network resources, 596 traffic policing or shaping, prioritizing in using shared network 597 resources, etc. Finally, service continuity may be ensured by 598 reserving backup paths for critical traffic, dedicating specific 599 network resources for a selected number of network slices, etc. 601 10. Security Considerations 603 This document specifies terminology and has no direct effect on the 604 security of implementations or deployments. In this section, a few 605 of the security aspects are identified. 607 o Conformance to security constraints: Specific security requests 608 from consumer defined IETF network slices will be mapped to their 609 realization in the unerlay networks. It will be required by 610 underlay networks to have capabilities to conform to consumer's 611 requests as some aspects of security may be expressed in SLOs. 613 o IETF network slice controller authentication: Unerlying networks 614 need to be protected against the attacks from an adversary NSC as 615 they can destablize overall network operations. It is 616 particularly critical since an IETF network slice may span across 617 different networks, therefore, IETF NSC should have strong 618 authentication with each those networks. Futhermore, both SBI and 619 NBI need to be secured. 621 o Specific isolation criteria: The nature of conformance to 622 isolation requests means that it should not be possible to attack 623 an IETF network slice service by varying the traffic on other 624 services or slices carried by the same underlay network. In 625 general, isolation is expected to strengthen the IETF network 626 slice security. 628 o Data Integrity of an IETF network slice: A consumer wanting to 629 secure their data and keep it private will be responsible for 630 applying appropriate security measures to their traffic and not 631 depending on the network operator that provides the IETF network 632 slice. It is expected that for data integrity, a consumer is 633 responsible for end-to-end encryption of its own traffic. 635 Note: see NGMN document [NGMN_SEC] on 5G network slice security for 636 discussion relevant to this section. 638 11. IANA Considerations 640 This memo includes no request to IANA. 642 12. Acknowledgment 644 The entire TEAS NS design team and everyone participating in those 645 discussion has contributed to this draft. Particularly, Eric Gray, 646 Xufeng Liu, Jie Dong, Adrian Farrel, and Jari Arkko for a thorough 647 review among other contributions. 649 13. Informative References 651 [HIPAA] HHS, "Health Insurance Portability and Accountability Act 652 - The Security Rule", February 2003, 653 . 656 [I-D.contreras-teas-slice-nbi] 657 Contreras, L., Homma, S., and J. Ordonez-Lucena, 658 "Considerations for defining a Transport Slice NBI", 659 draft-contreras-teas-slice-nbi-01 (work in progress), 660 March 2020. 662 [I-D.ietf-teas-enhanced-vpn] 663 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 664 Framework for Enhanced Virtual Private Networks (VPN+) 665 Services", draft-ietf-teas-enhanced-vpn-05 (work in 666 progress), February 2020. 668 [I-D.ietf-teas-yang-te-topo] 669 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 670 O. Dios, "YANG Data Model for Traffic Engineering (TE) 671 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 672 progress), June 2019. 674 [I-D.nsdt-teas-ns-framework] 675 Gray, E. and J. Drake, "Framework for Transport Network 676 Slices", draft-nsdt-teas-ns-framework-02 (work in 677 progress), March 2020. 679 [NGMN_SEC] 680 NGMN Alliance, "NGMN 5G Security - Network Slicing", April 681 2016, . 684 [PCI] PCI Security Standards Council, "PCI DSS", May 2018, 685 . 687 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 688 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 689 September 1999, . 691 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 692 Address Translator (Traditional NAT)", RFC 3022, 693 DOI 10.17487/RFC3022, January 2001, 694 . 696 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 697 Metric for IP Performance Metrics (IPPM)", RFC 3393, 698 DOI 10.17487/RFC3393, November 2002, 699 . 701 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 702 RFC 4303, DOI 10.17487/RFC4303, December 2005, 703 . 705 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 706 NAT64: Network Address and Protocol Translation from IPv6 707 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 708 April 2011, . 710 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 711 Ed., "A One-Way Delay Metric for IP Performance Metrics 712 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 713 2016, . 715 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 716 Ed., "A One-Way Loss Metric for IP Performance Metrics 717 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 718 2016, . 720 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 721 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 722 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 723 2018, . 725 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 726 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 727 DOI 10.17487/RFC8453, August 2018, 728 . 730 [TS.23.501-3GPP] 731 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 732 (V16.2.0): System Architecture for the 5G System (5GS); 733 Stage 2 (Release 16)", September 2019, 734 . 737 [TS33.210] 738 3GPP, "3G security; Network Domain Security (NDS); IP 739 network layer security (Release 14).", December 2016, 740 . 743 Authors' Addresses 745 Reza Rokui 746 Nokia 747 Canada 749 Email: reza.rokui@nokia.com 751 Shunsuke Homma 752 NTT 753 Japan 755 Email: shunsuke.homma.ietf@gmail.com 757 Kiran Makhijani 758 Futurewei 759 USA 761 Email: kiranm@futurewei.com 763 Luis M. Contreras 764 Telefonica 765 Spain 767 Email: luismiguel.contrerasmurillo@telefonica.com 769 Jeff Tantsura 770 Apstra, Inc. 772 Email: jefftant.ietf@gmail.com