idnits 2.17.1 draft-nsdt-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 (October 21, 2020) is 1275 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: April 24, 2021 NTT 6 K. Makhijani 7 Futurewei 8 LM. Contreras 9 Telefonica 10 J. Tantsura 11 Apstra, Inc. 12 October 21, 2020 14 Definition of IETF Network Slices 15 draft-nsdt-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 April 24, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 65 3. Definition and Scope of IETF Network Slice . . . . . . . . . 4 66 4. IETF Network Slice System Characteristics . . . . . . . . . . 5 67 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 5 68 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 5 69 4.1.2. Minimal Set of SLOs . . . . . . . . . . . . . . . . . 6 70 4.1.3. Other Objectives . . . . . . . . . . . . . . . . . . 7 71 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 7 72 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 9 73 4.3. IETF Network Slice Composition . . . . . . . . . . . . . 9 74 5. IETF Network Slice Structure . . . . . . . . . . . . . . . . 10 75 6. IETF Network Slice Stakeholders . . . . . . . . . . . . . . . 11 76 7. IETF Network Slice Controller Interfaces . . . . . . . . . . 11 77 8. Realizing IETF Network Slice . . . . . . . . . . . . . . . . 12 78 9. Isolation in IETF Network Slices . . . . . . . . . . . . . . 12 79 9.1. Isolation as a Service Level Objective . . . . . . . . . 13 80 9.2. Isolation in IETF Network Slice Realization . . . . . . . 13 81 10. Relationship with End-to-End Network Slice . . . . . . . . . 14 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 85 14. Informative References . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 A number of use cases benefit from network connections that along 91 with the connectivity provide assurance of meeting a specific set of 92 objectives wrt network resources use. In this document, as detailed 93 in the subsequent sections, we refer to this connectivity and 94 resource commitment as an IETF network slice. Services that might 95 benefit from the network slices include but not limited to: 97 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP]) 99 o Network wholesale services 101 o Network infrastructure sharing among operators 103 o NFV connectivity and Data Center Interconnect 105 The use cases are further described in [I-D.nsdt-teas-ns-framework]. 107 This document defines the concept of IETF Network Slices that provide 108 connectivity coupled with a set of specific commitments of network 109 resources between a number of endpoints over a shared network 110 infrastructure. Since the term network slice is rather generic, the 111 qualifying term 'IETF' is used in this document to limit the scope of 112 network slice to network technologies described and standardized by 113 the IETF. 115 1.1. Rationale 117 IETF Network Slices are created and managed within the scope of one 118 or more network technologies (e.g., IP, MPLS, optical). They are 119 intended to enable a diverse set of applications that have different 120 requirements to coexist on the same network infrastructure. 122 An IETF Network Slice is a well-defined structure of connectivity 123 requirements and associated network behaviors. IETF Network Slices 124 are defined such that they are independent of the underlying 125 infrastructure connectivity and technologies used. This is to allow 126 an IETF Network Slice consumer to describe their network connectivity 127 and relevant objectives in a common format, independent of the 128 underlying technologies used. 130 IETF Network Slices may be combined hierarchically, so that a network 131 slice may itself be sliced. They may also be combined sequentially 132 so that various different networks can each be sliced and the network 133 slices placed into a sequence to provide an end-to-end service. This 134 form of sequential combination is utilized in some services such as 135 in 3GPP's 5G network [TS.23.501-3GPP]. 137 2. Terms and Abbreviations 139 The terms and abbreviations used in this document are listed below. 141 o NS: Network Slice 143 o NSC: Network Slice Controller 145 o NBI: NorthBound Interface 147 o SBI: SouthBound Interface 149 o SLI: Service Level Indicator 151 o SLO: Service Level Objective 153 o SLA: Service Level Agreement 155 The above terminology is defined in greater details in the remainder 156 of this document. 158 3. Definition and Scope of IETF Network Slice 160 The definition of a network slice in IETF context is as follows: 162 An IETF Network Slice is a logical network topology connecting a 163 number of endpoints with a set of shared or dedicated network 164 resources, that are used to satisfy specific Service Level Objectives 165 (SLOs). 167 IETF Network Slice specification is technology-agnostic, and the 168 means for IETF network slice realization can be chosen depending on 169 several factors such as: service requirements, specifications or 170 capabilities of underlying infrastructure. The structure and 171 different characteristics of IETF Network Slices are described in the 172 following sections. 174 Term "Slice" refers to a set of characteristics and behaviours that 175 separate one type of user-traffic from another. IETF Network Slice 176 assumes that an underlying network is capable of changing the 177 configurations of the network devices on demand, through in-band 178 signaling or via controller(s) and fulfilling all or some of SLOs to 179 all of the traffic in the slice or to specific flows. 181 4. IETF Network Slice System Characteristics 183 The following subsections describe the characteristics of IETF 184 network slices. 186 4.1. Objectives for IETF Network Slices 188 An IETF Network Slice is defined in terms of several quantifiable 189 characteristics or service level objectives (SLOs). SLOs along with 190 terms Service Level Indicator (SLI) and Service Level Agreement (SLA) 191 are used to define the performance of a service at different levels. 193 A Service Level Indicator (SLI) is a quantifiable measure of an 194 aspect of the performance of a network. For example, it may be a 195 measure of throughput in bits per second, or it may be a measure of 196 latency in milliseconds. 198 A Service Level Objective (SLO) is a target value or range for the 199 measurements returned by observation of an SLI. For example, an SLO 200 may be expressed as "SLI <= target", or "lower bound <= SLI <= upper 201 bound". A network slice is expressed in terms of the set of SLOs 202 that are to be delivered for the different connections between 203 endpoints. 205 A Service Level Agreement (SLA) is an explicit or implicit contract 206 between the consumer of an IETF Network Slice and the provider of the 207 slice. The SLA is expressed in terms of a set of SLOs and may 208 include commercial terms as well as the consequences of missing/ 209 violating the SLOs they contain. 211 Additional descriptions of IETF network slice attributes is covered 212 in [I-D.contreras-teas-slice-nbi]. 214 4.1.1. Service Level Objectives 216 SLOs define a set of network attributes and characteristics that 217 describe an IETF network slice. SLOs do not describe 'how' the IETF 218 network slices are implemented or realized in the underlying network 219 layers. Instead, they are defined in terms of dimensions of 220 operation (time, capacity, etc.), availability, and other attributes. 221 An IETF network slice can have one or more SLOs associated with it. 222 The SLOs are combined in an SLA. The SLOs are defined for sets of 223 two or more endpoints and apply to specific directions of traffic 224 flow. That is, they apply to specific source endpoints and specific 225 connections between endpoints within the set of endpoints and 226 connections in the network slice. 228 4.1.2. Minimal Set of SLOs 230 This document defines a minimal set of SLOs and later systems or 231 standards could extend this set as per Section 4.1.3. 233 SLOs can be categorized in to 'Directly Measurable Objectives' or 234 'Indirectly Measurable Objectives'. Objectives such as guaranteed 235 minimum bandwidth, guaranteed maximum latency, maximum permissible 236 delay variation, maximum permissible packet loss rate, and 237 availability are 'Directly Measurable Objectives'. While 'Indirectly 238 Measurable Objectives' include security, geographical restrictions, 239 maximum occupancy level objectives. The later standard might define 240 other SLOs as needed. 242 Editor's Note TODO: Minimal set describes most commonly used 243 objectives to describe network behavior. Other directly or 244 indirectly measurable objectives may be requested by that customer of 245 an IETF network slice. 247 The definition of these objectives are as follows: 249 Guaranteed Minimum Bandwidth 251 Minimum guaranteed bandwidth between two endpoints at any time. 252 The bandwidth is measured in data rate units of bits per second 253 and is measured unidirectionally. 255 Guaranteed Maximum Latency 257 Upper bound of network latency when transmitting between two 258 endpoints. The latency is measured in terms of network 259 characteristics (excluding application-level latency). 260 [RFC2681] and [RFC7679] discuss round trip times and one-way 261 metrics, respectively. 263 Maximum Permissible Delay Variation 265 Packet delay variation (PDV) as defined by [RFC3393], s the 266 difference in the one-way delay between sequential packets in a 267 flow. This SLO sets a maximum value PDV for packets between 268 two endpoints. 270 Maximum permissible packet loss rate 272 The ratio of packets dropped to packets transmitted between two 273 endpoints over a period of time. See [RFC7680] 275 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 11. 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 customer 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 customer 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 can be merged with 416 Relationship 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 6. IETF Network Slice Stakeholders 456 An IETF Network Slice and its realization involves the following 457 stakeholders and it is relevant to define them for consistent 458 terminology. 460 Consumer: A consumer is the requester of an IETF Network Slice. 461 Consumers may request monitoring of SLOs. A consumer may manage 462 the IETF Network Slice service directly by interfacing with the 463 IETF Network Slice controller or indirectly through an 464 orchestrator. 466 Orchestrator: An orchestrator is an entity that composes different 467 services, resource and network requirements. It interfaces with 468 the IETF Network Slice controllers. 470 IETF Network Slice Controller (NSC): It realizes an IETF Network 471 Slice in the underlying network, maintains and monitors the run- 472 time state of resources and topologies associated with it. A 473 well-defined interface is needed between different types of IETF 474 Network Slice controllers and different types of orchestrators. 475 An IETF Network Slice operator (or slice operator for short) 476 manages one or more IETF Network Slices using the IETF Network 477 Slice Controller(s). 479 Network Controller: is a form of network infrastructure controller 480 that offers network resources to NSC to realize a particular 481 network slice. These may be existing network controllers 482 associated with one or more specific technologies that may be 483 adapted to the function of realizing IETF Network Slices in a 484 network. 486 7. IETF Network Slice Controller Interfaces 488 The interworking and interoperability among the different 489 stakeholders to provide common means of provisioning, operating and 490 monitoring the IETF Network slices is enabled by the following 491 communication interfaces (see Figure 3). 493 NSC Northbound Interface (NBI): The NSC Northbound Interface is an 494 interface between a consumer's higher level operation system 495 (e.g., a network slice orchestrator) and the NSC. It is a 496 technology agnostic interface. The consumer can use this 497 interface to communicate the requested characteristics and other 498 requirements (i.e., the SLOs) for the IETF Network Slice, and the 499 NSC can use the interface to report the operational state of an 500 IETF Network Slice to the consumer. 502 NSC Southbound Interface (SBI): The NSC Southbound Interface is an 503 interface between the NSC and network controllers. It is 504 technology-specific and may be built around the many network 505 models defined within the IETF. 507 +------------------------------------------+ 508 | Consumer higher level operation system | 509 | (e.g E2E network slice orchestrator) | 510 +------------------------------------------+ 511 A 512 | NSC NBI 513 V 514 +------------------------------------------+ 515 | IETF Network Slice Controller (NSC) | 516 +------------------------------------------+ 517 A 518 | NSC SBI 519 V 520 +------------------------------------------+ 521 | Network Controllers | 522 +------------------------------------------+ 524 Figure 3: Interface of IETF Network Slice Controller 526 8. Realizing IETF Network Slice 528 Realization of IETF Network Slices is out of scope of this document. 529 It is a mapping of the definition of the IETF Network Slice to the 530 underlying infrastructure and is necessarily technology-specific and 531 achieved by the NSC over the SBI. 533 The realization can be achieved in a form of either physical or 534 logical connectivity through VPNs (see, for example, 535 [I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies 536 such as Segment Routing, MPLS, etc. Accordingly, endpoints may be 537 realized as physical or logical service or network functions. 539 9. Isolation in IETF Network Slices 541 Editor's note: This content is a work in progress. 543 An IETF Network Slice consumer may request, that the IETF Network 544 Slice delivered to them is isolated from any other network slices of 545 services delivered to any other customers. It is expected that the 546 changes to the other network slices of services do not have any 547 negative impact on the delivery of the IETF Network Slice. 549 This requirement may be met by simple conformance with other SLOs. 550 For example, traffic congestion (interference from other services) 551 might impact on the latency experienced by an IETF network slice. 552 Thus, conformance to a latency SLO would be the primary requirement 553 for delivery of the IETF network slice service, and isolation from 554 other services might be only a means to that end. 556 Nevertheless, "isolation" remains a useful shorthand to describe the 557 desire that an IETF network slice should not be impacted by any other 558 network slice or service supported by the underlying network. The 559 concept may also be useful for achieving independence against failure 560 between a pair of IETF network slices (used, for example, for backup 561 connectivity). 563 Other meanings of "isolation" such as "do not deliver traffic from 564 this IETF network slice to an endpoint that is not part of this IETF 565 network slice" should be taken for granted by the definition and 566 realization of any IETF network slice. 568 9.1. Isolation as a Service Level Objective 570 As described above, the concept of "isolation" may be presented as an 571 SLO. It may be unqualified as "keep this IETF network slice free 572 from effects caused by any other network slice or service," qualified 573 as "keep a specific SLI free from effects caused by any other network 574 slice or service," or tightly specified to the effects or 575 vulnerabilities of another specific IETF network slice. 577 It should be noted that some aspects of isolation may be measurable 578 by a customer who can control the traffic on a number of IETF network 579 slices or other services. 581 9.2. Isolation in IETF Network Slice Realization 583 How delivery of isolation is achieved in the realization of a network 584 slice is implementation and technology dependent. It may further 585 depend on how a network operator decides to operate their network and 586 deliver services. 588 Isolation may be achieved in the underlying network by various forms 589 of resource partitioning ranging from dedicated allocation of 590 resources for a specific IETF network slice, to sharing or resources 591 with safeguards. 593 10. Relationship with End-to-End Network Slice 595 Editor's note: The details deleted from here should be in the 596 framework. 598 An end-to-end network slice is defined by the 3GPP as a complete 599 logical network that provides a service in its entirety with a 600 specific assurance to the customer [TS.23.501-3GPP]. A network 601 operator may be responsible for delivering services over a number of 602 technologies (such as radio networks) and for providing specific and 603 fine-grained services (such as CCTV feed or High definition realtime 604 traffic data). That operator may need to combine slices of various 605 networks to produce an end-to-end network service. Each of these 606 networks may include multiple physical or virtual nodes and may also 607 provide network functions beyond simply carrying of technology- 608 specific protocol data units. 610 An end-to-end network slice may be composed from other network slices 611 that include IETF Network Slices. This composition may include the 612 hierarchical (or recursive) use of underlying network slices and the 613 sequential (or stitched) combination of slices of different networks. 615 11. Security Considerations 617 Editor's Note: Need further improvement; work in progress. 619 This document specifies terminology and has no direct effect on the 620 security of implementations or deployments. 622 As noted in Section 4.1.2, some aspects of security may be expressed 623 in SLOs and so form part of the service delivered as an IETF network 624 slice. As further mentioned in Section 8, there is an underlying 625 asumption that traffic presented to an IETF network slice will not be 626 misdelivered to an endpoint that is not part of that IETF network 627 slice. 629 Furthermore, the nature of conformance to SLOs means that it should 630 not be possible to attack an IETF network slice service by varying 631 the traffic on other services or slices carried by the same underlay 632 network. This concern can be strengthened by the stipulation of 633 "isolation" as an SLO. 635 Note, however, that a customer wanting to secure their data and keep 636 it private will be responsible for applying appropriate security 637 measures to their traffic and not depending on the network operator 638 that provides the IETF network slice. 640 12. IANA Considerations 642 This memo includes no request to IANA. 644 13. Acknowledgment 646 The entire TEAS NS design team and everyone participating in those 647 discussion has contributed to this draft. Particularly, Eric Gray, 648 Xufeng Liu, Jie Dong, Adrian Farrel, and Jari Arkko for a thorough 649 review among other contributions. 651 14. Informative References 653 [HIPAA] HHS, "Health Insurance Portability and Accountability Act 654 - The Security Rule", February 2003, 655 . 658 [I-D.contreras-teas-slice-nbi] 659 Contreras, L., Homma, S., and J. Ordonez-Lucena, 660 "Considerations for defining a Transport Slice NBI", 661 draft-contreras-teas-slice-nbi-01 (work in progress), 662 March 2020. 664 [I-D.ietf-teas-enhanced-vpn] 665 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 666 Framework for Enhanced Virtual Private Networks (VPN+) 667 Services", draft-ietf-teas-enhanced-vpn-05 (work in 668 progress), February 2020. 670 [I-D.ietf-teas-yang-te-topo] 671 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 672 O. Dios, "YANG Data Model for Traffic Engineering (TE) 673 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 674 progress), June 2019. 676 [I-D.nsdt-teas-ns-framework] 677 Gray, E. and J. Drake, "Framework for Transport Network 678 Slices", draft-nsdt-teas-ns-framework-02 (work in 679 progress), March 2020. 681 [PCI] PCI Security Standards Council, "PCI DSS", May 2018, 682 . 684 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 685 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 686 September 1999, . 688 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 689 Address Translator (Traditional NAT)", RFC 3022, 690 DOI 10.17487/RFC3022, January 2001, 691 . 693 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 694 Metric for IP Performance Metrics (IPPM)", RFC 3393, 695 DOI 10.17487/RFC3393, November 2002, 696 . 698 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 699 RFC 4303, DOI 10.17487/RFC4303, December 2005, 700 . 702 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 703 NAT64: Network Address and Protocol Translation from IPv6 704 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 705 April 2011, . 707 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 708 Ed., "A One-Way Delay Metric for IP Performance Metrics 709 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 710 2016, . 712 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 713 Ed., "A One-Way Loss Metric for IP Performance Metrics 714 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 715 2016, . 717 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 718 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 719 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 720 2018, . 722 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 723 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 724 DOI 10.17487/RFC8453, August 2018, 725 . 727 [TS.23.501-3GPP] 728 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 729 (V16.2.0): System Architecture for the 5G System (5GS); 730 Stage 2 (Release 16)", September 2019, 731 . 734 [TS33.210] 735 3GPP, "3G security; Network Domain Security (NDS); IP 736 network layer security (Release 14).", December 2016, 737 . 740 Authors' Addresses 742 Reza Rokui 743 Nokia 744 Canada 746 Email: reza.rokui@nokia.com 748 Shunsuke Homma 749 NTT 750 Japan 752 Email: shunsuke.homma.ietf@gmail.com 754 Kiran Makhijani 755 Futurewei 756 USA 758 Email: kiranm@futurewei.com 760 Luis M. Contreras 761 Telefonica 762 Spain 764 Email: luismiguel.contrerasmurillo@telefonica.com 766 Jeff Tantsura 767 Apstra, Inc. 769 Email: jefftant.ietf@gmail.com