idnits 2.17.1 draft-ietf-teas-ietf-network-slices-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (April 16, 2021) is 1099 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EP1' is mentioned on line 839, but not defined == Missing Reference: 'EP2' is mentioned on line 839, but not defined == Missing Reference: 'EPm' is mentioned on line 843, but not defined == Missing Reference: 'EPn' is mentioned on line 843, but not defined == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-03 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-06 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-05 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel, Ed. 3 Internet-Draft Old Dog Consulting 4 Intended status: Informational E. Gray 5 Expires: October 18, 2021 Ericsson 6 J. Drake 7 Juniper Networks 8 R. Rokui 9 Nokia 10 S. Homma 11 NTT 12 K. Makhijani 13 Futurewei 14 LM. Contreras 15 Telefonica 16 J. Tantsura 17 Juniper Networks 18 April 16, 2021 20 Framework for IETF Network Slices 21 draft-ietf-teas-ietf-network-slices-01 23 Abstract 25 This document describes network slicing in the context of networks 26 built from IETF technologies. It defines the term "IETF Network 27 Slice" and establishes the general principles of network slicing in 28 the IETF context. 30 The document discusses the general framework for requesting and 31 operating IETF Network Slices, the characteristics of an IETF Network 32 Slice, the necessary system components and interfaces, and how 33 abstract requests can be mapped to more specific technologies. The 34 document also discusses related considerations with monitoring and 35 security. 37 This document also provides definitions of related terms to enable 38 consistent usage in other IETF documents that describe or use aspects 39 of IETF Network Slices. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on October 18, 2021. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 78 3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 6 79 3.1. Definition and Scope of IETF Network Slice . . . . . . . 6 80 4. IETF Network Slice System Characteristics . . . . . . . . . . 7 81 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 7 82 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 8 83 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 10 84 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 12 85 4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 12 86 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 12 88 5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 13 89 5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 15 90 5.3.1. IETF Network Slice Controller Interfaces . . . . . . 17 91 5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 17 92 5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 18 93 5.5. Realizing IETF Network Slice . . . . . . . . . . . . . . 20 94 5.5.1. Underlying Technology . . . . . . . . . . . . . . . . 20 95 6. Applicability of ACTN to IETF Network Slices . . . . . . . . 21 96 7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 23 97 7.1. Isolation as a Service Requirement . . . . . . . . . . . 23 98 7.2. Isolation in IETF Network Slice Realization . . . . . . . 24 99 8. Management Considerations . . . . . . . . . . . . . . . . . . 24 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 9.1. Privacy Considerations . . . . . . . . . . . . . . . . . 25 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 103 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 104 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 107 13.2. Informative References . . . . . . . . . . . . . . . . . 27 108 Appendix A. Unused Material . . . . . . . . . . . . . . . . . . 31 109 A.1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . 32 110 A.2. Management Systems or Other Applications . . . . . . . . 32 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 113 1. Introduction 115 ===================== EDITOR'S NOTE ===================== 117 This document is a merge of the text in 118 [I-D.ietf-teas-ietf-network-slice-definition] and 119 [I-D.ietf-teas-ietf-network-slice-framework]. In this version, the 120 text included from the contributing documents has been re-arranged to 121 rationalise the structure, but no substantive changes have been made. 122 Additionally, the Editor has made a number of stylistic edits and 123 fixed further simple editorial and formatting issues. 125 In the case that the source text is not used within the document, it 126 is presented in Appendix A. 128 =================== END EDITOR'S NOTE =================== 130 A number of use cases benefit from network connections that along 131 with the connectivity provide assurance of meeting a specific set of 132 objectives with respect to network resources use. This connectivity 133 and resource commitment is referred to as a network slice. Since the 134 term network slice is rather generic, the qualifying term "IETF" is 135 used in this document to limit the scope of network slice to network 136 technologies described and standardized by the IETF. This document 137 defines the concept of IETF Network Slices that provide connectivity 138 coupled with a set of specific commitments of network resources 139 between a number of endpoints over a shared network infrastructure. 140 Services that might benefit from IETF Network Slices include, but are 141 not limited to: 143 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501]) 144 o Network wholesale services 146 o Network infrastructure sharing among operators 148 o NFV connectivity and Data Center Interconnect 150 IETF Network Slices are created and managed within the scope of one 151 or more network technologies (e.g., IP, MPLS, optical). They are 152 intended to enable a diverse set of applications that have different 153 requirements to coexist on the shared network infrastructure. A 154 request for an IETF Network Slice is technology-agnostic so as to 155 allow a consumer to describe their network connectivity objectives in 156 a common format, independent of the underlying technologies used. 158 This document also provides a framework for discussing IETF Network 159 Slices. This framework is intended as a structure for discussing 160 interfaces and technologies. It is not intended to specify a new set 161 of concrete interfaces or technologies. Rather, the idea is that 162 existing or under-development IETF technologies (plural) can be used 163 to realize the concepts expressed herein. 165 For example, virtual private networks (VPNs) have served the industry 166 well as a means of providing different groups of users with logically 167 isolated access to a common network. The common or base network that 168 is used to provide the VPNs is often referred to as an underlay 169 network, and the VPN is often called an overlay network. As an 170 example technology, a VPN may in turn serve as an underlay network 171 for IETF Network Slices. 173 Note that it is conceivable that extensions to these IETF 174 technologies are needed in order to fully support all the ideas that 175 can be implemented with slices, but at least in the beginning there 176 is no plan for the creation of new protocols or interfaces. 178 1.1. Background 180 Driven largely by needs surfacing from 5G, the concept of network 181 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 182 and [BBF-SD406]). In [TS23501], a Network Slice is defined as "a 183 logical network that provides specific network capabilities and 184 network characteristics", and a Network Slice Instance is defined as 185 "A set of Network Function instances and the required resources (e.g. 186 compute, storage and networking resources) which form a deployed 187 Network Slice." According to [TS28530], an end-to-end network slice 188 consists of three major types of network segments: Radio Access 189 Network (RAN), Transport Network (TN) and Core Network (CN). IETF 190 Network Slice provides the required connectivity between different 191 entities in RAN and CN segments of an end-to-end network slice, with 192 a specific performance commitment. For each end-to-end network 193 slice, the topology and performance requirement on a consumer's use 194 of IETF Network Slice can be very different, which requires the 195 underlay network to have the capability of supporting multiple 196 different IETF Network Slices. 198 While network slices are commonly discussed in the context of 5G, it 199 is important to note that IETF Network Slices are a narrower concept, 200 and focus primarily on particular network connectivity aspects. 201 Other systems, including 5G deployments, may use IETF Network Slices 202 as a component to create entire systems and concatenated constructs 203 that match their needs, including end-to-end connectivity. 205 A IETF Network Slice could span multiple technologies and multiple 206 administrative domains. Depending on the IETF Network Slice 207 consumer's requirements, an IETF Network Slice could be isolated from 208 other, often concurrent IETF Network Slices in terms of data, control 209 and management planes. 211 The consumer expresses requirements for a particular IETF Network 212 Slice by specifying what is required rather than how the requirement 213 is to be fulfilled. That is, the IETF Network Slice consumer's view 214 of an IETF Network Slice is an abstract one. 216 Thus, there is a need to create logical network structures with 217 required characteristics. The consumer of such a logical network can 218 require a degree of isolation and performance that previously might 219 not have been satisfied by traditional overlay VPNs. Additionally, 220 the IETF Network Slice consumer might ask for some level of control 221 of their virtual networks, e.g., to customize the service paths in a 222 network slice. 224 This document specifies a framework for the use of existing 225 technologies as components to provide an IETF Network Slice service, 226 and might also discuss (or reference) modified and potential new 227 technologies, as they develop (such as candidate technologies 228 described in section 5 of [I-D.ietf-teas-enhanced-vpn]). 230 2. Terms and Abbreviations 232 The terms and abbreviations used in this document are listed below. 234 o NBI: NorthBound Interface 236 o NS: Network Slice 238 o NSC: Network Slice Controller 239 o NSE: Network Slice Endpoint 241 o SBI: SouthBound Interface 243 o SLA: Service Level Agreement 245 o SLI: Service Level Indicator 247 o SLO: Service Level Objective 249 The above terminology is defined in greater details in the remainder 250 of this document. 252 3. IETF Network Slice Objectives 254 It is intended that IETF Network Slices can be created to meet 255 specific requirements, typically expressed as bandwidth, latency, 256 latency variation, and other desired or required characteristics. 257 Creation is initiated by a management system or other application 258 used to specify network-related conditions for particular traffic 259 flows. 261 It is also intended that, once created, these slices can be 262 monitored, modified, deleted, and otherwise managed. 264 It is also intended that applications and components will be able to 265 use these IETF Network Slices to move packets between the specified 266 end-points in accordance with specified characteristics. 268 As an example of requirements that might apply to IETF Network 269 Slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3). 271 3.1. Definition and Scope of IETF Network Slice 273 The definition of a network slice in IETF context is as follows: 275 An IETF Network Slice is a logical network topology connecting a 276 number of endpoints using a set of shared or dedicated network 277 resources that are used to satisfy specific Service Level Objectives 278 (SLOs). 280 An IETF Network Slice combines the connectivity resource requirements 281 and associated network behaviors such as bandwidth, latency, jitter, 282 and network functions with other resource behaviors such as compute 283 and storage availability. IETF Network Slices are independent of the 284 underlying infrastructure connectivity and technologies used. This 285 is to allow an IETF Network Slice consumer to describe their network 286 connectivity and relevant objectives in a common format, independent 287 of the underlying technologies used. 289 IETF Network Slices may be combined hierarchically, so that a network 290 slice may itself be sliced. They may also be combined sequentially 291 so that various different networks can each be sliced and the network 292 slices placed into a sequence to provide an end-to-end service. This 293 form of sequential combination is utilized in some services such as 294 in 3GPP's 5G network [TS23501]. 296 An IETF Network Slice is technology-agnostic, and the means for IETF 297 Network Slice realization can be chosen depending on several factors 298 such as: service requirements, specifications or capabilities of 299 underlying infrastructure. The structure and different 300 characteristics of IETF Network Slices are described in the following 301 sections. 303 Term "Slice" refers to a set of characteristics and behaviours that 304 separate one type of user-traffic from another. IETF Network Slice 305 assumes that an underlying network is capable of changing the 306 configurations of the network devices on demand, through in-band 307 signaling or via controller(s) and fulfilling all or some of SLOs to 308 all of the traffic in the slice or to specific flows. 310 4. IETF Network Slice System Characteristics 312 The following subsections describe the characteristics of IETF 313 Network Slices. 315 4.1. Objectives for IETF Network Slices 317 An IETF Network Slice is defined in terms of several quantifiable 318 characteristics or Service Level Objectives (SLOs). SLOs along with 319 the terms Service Level Indicator (SLI) and Service Level Agreement 320 (SLA) are used to define the performance of a service at different 321 levels. 323 A Service Level Indicator (SLI) is a quantifiable measure of an 324 aspect of the performance of a network. For example, it may be a 325 measure of throughput in bits per second, or it may be a measure of 326 latency in milliseconds. 328 A Service Level Objective (SLO) is a target value or range for the 329 measurements returned by observation of an SLI. For example, an SLO 330 may be expressed as "SLI <= target", or "lower bound <= SLI <= upper 331 bound". A network slice is expressed in terms of the set of SLOs 332 that are to be delivered for the different connections between 333 endpoints. 335 A Service Level Agreement (SLA) is an explicit or implicit contract 336 between the consumer of an IETF Network Slice and the provider of the 337 slice. The SLA is expressed in terms of a set of SLOs and may 338 include commercial terms as well as the consequences of missing/ 339 violating the SLOs they contain. 341 Additional descriptions of IETF Network Slice attributes is covered 342 in [I-D.contreras-teas-slice-nbi]. 344 4.1.1. Service Level Objectives 346 SLOs define a set of network attributes and characteristics that 347 describe an IETF Network Slice. SLOs do not describe how the IETF 348 Network Slices are implemented or realized in the underlying network 349 layers. Instead, they are defined in terms of dimensions of 350 operation (time, capacity, etc.), availability, and other attributes. 351 An IETF Network Slice can have one or more SLOs associated with it. 352 The SLOs are combined in an SLA. The SLOs are defined for sets of 353 two or more endpoints and apply to specific directions of traffic 354 flow. That is, they apply to specific source endpoints and specific 355 connections between endpoints within the set of endpoints and 356 connections in the IETF Network Slice. 358 4.1.1.1. Minimal Set of SLOs 360 This document defines a minimal set of SLOs and later systems or 361 standards could extend this set as described in Section 4.1.1.2. 363 SLOs can be categorized in to 'Directly Measurable Objectives' or 364 'Indirectly Measurable Objectives'. Objectives such as guaranteed 365 minimum bandwidth, guaranteed maximum latency, maximum permissible 366 delay variation, maximum permissible packet loss rate, and 367 availability are 'Directly Measurable Objectives'. While 'Indirectly 368 Measurable Objectives' include security, geographical restrictions, 369 maximum occupancy level objectives. The later standard might define 370 other SLOs as needed. 372 Editor's Note TODO: replace Minimal set to most commonly used 373 objectives to describe network behavior. Other directly or 374 indirectly measurable objectives may be requested by that consumer of 375 an IETF Network Slice. 377 The definition of these objectives are as follows: 379 Guaranteed Minimum Bandwidth 380 Minimum guaranteed bandwidth between two endpoints at any time. 381 The bandwidth is measured in data rate units of bits per second 382 and is measured unidirectionally. 384 Guaranteed Maximum Latency 386 Upper bound of network latency when transmitting between two 387 endpoints. The latency is measured in terms of network 388 characteristics (excluding application-level latency). 389 [RFC2681] and [RFC7679] discuss round trip times and one-way 390 metrics, respectively. 392 Maximum Permissible Delay Variation 394 Packet delay variation (PDV) as defined by [RFC3393], is the 395 difference in the one-way delay between sequential packets in a 396 flow. This SLO sets a maximum value PDV for packets between 397 two endpoints. 399 Maximum permissible packet loss rate 401 The ratio of packets dropped to packets transmitted between two 402 endpoints over a period of time. See [RFC7680]. 404 Availability 406 The ratio of uptime to the sum of uptime and downtime, where 407 uptime is the time the IETF Network Slice is available in 408 accordance with the SLOs associated with it. 410 Security 412 An IETF Network Slice consumer may request that the network 413 applies encryption or other security techniques to traffic 414 flowing between endpoints. 416 Note that the use of security or the violation of this SLO is 417 not directly observable by the IETF Network Slice consumer and 418 cannot be measured as a quantifiable metric. 420 Also note that the objective may include request for encryption 421 (e.g., [RFC4303]) between the two endpoints explicitly to meet 422 architecture recommendations as in [TS33.210] or for compliance 423 with [HIPAA] and/or [PCI]. 425 Please see more discussion on security in Section 9. 427 4.1.1.2. Other Service Level Objectives 429 Additional SLOs may be defined to provide additional description of 430 the IETF Network Slice that a consumer requests. 432 If the IETF Network Slice consumer service is traffic aware, other 433 traffic specific characteristics may be valuable including MTU, 434 traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a 435 higher-level behavior to process traffic according to user- 436 application (which may be realized using network functions). 438 Maximal occupancy for an IETF Network Slice should be provided. 439 Since it carries traffic for multiple flows between the two 440 endpoints, the objectives should also say if they are for the entire 441 connection, group of flows or on per flow basis. Maximal occupancy 442 should specify the scale of the flows (i.e., maximum number of flows 443 to be admitted) and optionally a maximum number of countable resource 444 units, e.g., IP or MAC addresses a slice might consume. 446 4.2. IETF Network Slice Endpoints 448 As noted in Section 3.1, an IETF Network Slice describes connectivity 449 between multiple endpoints across the underlying network. These 450 connectivity types are: point-to-point, point-to-multipoint, 451 multipoint-to-point, multipoint-to-point, or multipoint-to- 452 multipoint. 454 Figure 1 shows an IETF Network Slice along with its Network Slice 455 Endpoints (NSEs). 457 The characteristics of IETF NSEs are as follows: 459 o The IETF NSE are conceptual points of connection to IETF network 460 slice. As such, they serve as the IETF Network Slice ingress/ 461 egress points. 463 o Each endpoint could map to a device, application or a network 464 function. A non-exhaustive list of devices, applications or 465 network functions might include but not limited to: routers, 466 switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, 467 application acceleration, Deep Packet Inspection (DPI), server 468 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 469 enrichment functions, and TCP optimizers. 471 o An NSE should be identified by a unique ID in the context of an 472 IETF Network Slice consumer. 474 o In addition to an identifier, each NSE should contain a subset of 475 attributes such as IPv4/IPv6 addresses, encapsulation type (i.e., 476 VLAN tag, MPLS Label etc.), interface/port numbers, node ID etc. 478 o A combination of NSE unique ID and NSE attributes defines an NSE 479 in the context of the IETF Network Slice Controller (NSC). 481 o During the realization of the IETF Network Slice, in addition to 482 SLOs, all or subset of IETF NSE attributes will be utilized by the 483 IETF NSC to find the optimal realization in the IETF network. 485 o Similarly to IETF Network Slices, the IETF Network Slice Endpoints 486 are logical entities that are mapped to services/tunnels/paths 487 endpoints in IETF Network Slice during its initialization and 488 realization. 490 Note that there are various IETF TE terms such as access points (AP) 491 defined in [RFC8453], Termination Point (TP) defined in [RFC8345], 492 and Link Termination Point (LTP) defined in [RFC8795] which are 493 tightly coupled with TE network type and various realization 494 techniques. At the time of realization of the IETF Network Slice, 495 the NSE could be mapped to one or more of these based on the network 496 slice realization technique in use. 498 |----------------------------------| 499 NSE1 | | NSE2 500 O.....| |.....O 501 . | | . 502 . | | . 503 . | | . 504 | | 505 NSEm | | NSEn 506 O.....| |.....O 507 | | 508 |----------------------------------| 510 <------------ IETF Network Slice --------------> 511 between endpoints NSE1 to NSEn 513 Legend: 514 NSE: IETF Network Slice Endpoint 515 O: Represents IETF Network Slice Endpoints 517 Figure 1: An IETF Network Slice Endpoints (NSE) 519 4.2.1. IETF Network Slice Connectivity Types 521 The IETF Network Slice connection types can be point to point (P2P), 522 point to multipoint (P2MP), multi-point to point (MP2P), or multi- 523 point to multi-point (MP2MP). They will requested by the higher 524 level operation system. 526 4.3. IETF Network Slice Decomposition 528 Operationally, an IETF Network Slice may be decomposed in two or more 529 IETF Network Slices as specified below. Decomposed network slices 530 are then independently realized and managed. 532 o Hierarchical (i.e., recursive) composition: An IETF Network Slice 533 can be further sliced into other network slices. Recursive 534 composition allows an IETF Network Slice at one layer to be used 535 by the other layers. This type of multi-layer vertical IETF 536 Network Slice associates resources at different layers. 538 o Sequential composition: Different IETF Network Slices can be 539 placed into a sequence to provide an end-to-end service. In 540 sequential composition, each IETF Network Slice would potentially 541 support different dataplanes that need to be stitched together. 543 5. Framework 545 A number of IETF Network Slice services will typically be provided 546 over a shared underlying network infrastructure. Each IETF Network 547 Slice consists of both the overlay connectivity and a specific set of 548 dedicated network resources and/or functions allocated in a shared 549 underlay network to satisfy the needs of the IETF Network Slice 550 consumer. In at least some examples of underlying network 551 technologies, the integration between the overlay and various 552 underlay resources is needed to ensure the guaranteed performance 553 requested for different IETF Network Slices. 555 Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example 556 architecture that might apply in using the technology described in 557 this document. 559 5.1. IETF Network Slice Stakeholders 561 An IETF Network Slice and its realization involves the following 562 stakeholders and it is relevant to define them for consistent 563 terminology. 565 Consumer: A consumer is the requester of an IETF Network Slice. 566 Consumers may request monitoring of SLOs. A consumer may manage 567 the IETF Network Slice service directly by interfacing with the 568 IETF NSC or indirectly through an orchestrator. 570 Orchestrator: An orchestrator is an entity that composes different 571 services, resource and network requirements. It interfaces with 572 the IETF NSC. 574 IETF Network Slice Controller (NSC): It realizes an IETF Network 575 Slice in the underlying network, maintains and monitors the run- 576 time state of resources and topologies associated with it. A 577 well-defined interface is needed between different types of IETF 578 NSCs and different types of orchestrators. An IETF Network Slice 579 operator (or slice operator for short) manages one or more IETF 580 Network Slices using the IETF NSCs. 582 Network Controller: is a form of network infrastructure controller 583 that offers network resources to the NSC to realize a particular 584 network slice. These may be existing network controllers 585 associated with one or more specific technologies that may be 586 adapted to the function of realizing IETF Network Slices in a 587 network. 589 5.2. Expressing Connectivity Intents 591 The NSC northbound interface (NBI) can be used to communicate between 592 IETF Network Slice users (or consumers) and the NSC. 594 An IETF Network Slice user may be a network operator who, in turn, 595 provides the IETF Network Slice to another IETF Network Slice user or 596 consumer. 598 Using the NBI, a consumer expresses requirements for a particular 599 slice by specifying what is required rather than how that is to be 600 achieved. That is, the consumer's view of a slice is an abstract 601 one. Consumers normally have limited (or no) visibility into the 602 provider network's actual topology and resource availability 603 information. 605 This should be true even if both the consumer and provider are 606 associated with a single administrative domain, in order to reduce 607 the potential for adverse interactions between IETF Network Slice 608 consumers and other users of the underlay network infrastructure. 610 The benefits of this model can include: 612 o Security: because the underlay network (or network operator) does 613 not need to expose network details (topology, capacity, etc.) to 614 IETF Network Slice consumers the underlay network components are 615 less exposed to attack; 617 o Layered Implementation: the underlay network comprises network 618 elements that belong to a different layer network than consumer 619 applications, and network information (advertisements, protocols, 620 etc.) that a consumer cannot interpret or respond to (note - a 621 consumer should not use network information not exposed via the 622 NSC NBI, even if that information is available); 624 o Scalability: consumers do not need to know any information beyond 625 that which is exposed via the NBI. 627 The general issues of abstraction in a TE network is described more 628 fully in [RFC7926]. 630 This framework document does not assume any particular layer at which 631 IETF Network Slices operate as a number of layers (including virtual 632 L2, Ethernet or IP connectivity) could be employed. 634 Data models and interfaces are of course needed to set up IETF 635 Network Slices, and specific interfaces may have capabilities that 636 allow creation of specific layers. 638 Layered virtual connections are comprehensively discussed in IETF 639 documents and are widely supported. See, for instance, GMPLS-based 640 networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and 641 [RFC8454]). The principles and mechanisms associated with layered 642 networking are applicable to IETF Network Slices. 644 There are several IETF-defined mechanisms for expressing the need for 645 a desired logical network. The NBI carries data either in a 646 protocol-defined format, or in a formalism associated with a modeling 647 language. 649 For instance: 651 o Path Computation Element (PCE) Communication Protocol (PCEP) 652 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 653 [RFC4208] use a TLV-based binary encoding to transmit data. 655 o Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 656 Protocol [RFC8040] use XML abnd JSON encoding. 658 o gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 659 programmable interface; 661 o SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding 662 (ASN.1). 664 o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 665 model configuration and other data for NETCONF, RESTCONF, and GNMI 666 - among others; ProtoBufs can be used to model gRPC and GNMI data; 667 Structure of Management Information (SMI) [RFC2578] may be used to 668 define Management Information Base (MIB) modules for SNMP, using 669 an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 670 1988). 672 While several generic formats and data models for specific purposes 673 exist, it is expected that IETF Network Slice management may require 674 enhancement or augmentation of existing data models. 676 5.3. IETF Network Slice Controller (NSC) 678 The IETF NSC takes abstract requests for IETF Network Slices and 679 implements them using a suitable underlying technology. An IETF NSC 680 is the key building block for control and management of the IETF 681 Network Slice. It provides the creation/modification/deletion, 682 monitoring and optimization of IETF Network Slices in a multi-domain, 683 a multi-technology and multi-vendor environment. 685 The main task of the IETF NSC is to map abstract IETF Network Slice 686 requirements to concrete technologies and establish required 687 connectivity, and ensuring that required resources are allocated to 688 the IETF Network Slice. 690 A NSC northbound interface (NBI) is needed for communicating details 691 of a IETF Network Slice (configuration, selected policies, 692 operational state, etc.), as well as providing information to a slice 693 requester/consumer about IETF Network Slice status and performance. 694 The details for this NBI are not in scope for this document. 696 The controller provides the following functions: 698 o Provides a technology-agnostic NBI for creation/modification/ 699 deletion of the IETF Network Slices. The API exposed by this NBI 700 communicates the endpoints of the IETF network slice, IETF Network 701 Slice SLO parameters (and possibly monitoring thresholds), 702 applicable input selection (filtering) and various policies, and 703 provides a way to monitor the slice. 705 o Determines an abstract topology connecting the endpoints of the 706 IETF Network Slice that meets criteria specified via the NBI. The 707 NSC also retains information about the mapping of this abstract 708 topology to underlying components of the IETF network slice as 709 necessary to monitor IETF Network Slice status and performance. 711 o Provides "Mapping Functions" for the realization of IETF Network 712 Slices. In other words, it will use the mapping functions that: 714 * map technology-agnostic NBI request to technology-specific SBIs 716 * map filtering/selection information as necessary to entities in 717 the underlay network. 719 o Via an SBI, the controller collects telemetry data (e.g., OAM 720 results, statistics, states, etc.) for all elements in the 721 abstract topology used to realize the IETF Network Slice. 723 o Using the telemetry data from the underlying realization of a IETF 724 Network Slice (i.e., services/paths/tunnels), evaluates the 725 current performance against IETF Network Slice SLO parameters and 726 exposes them to the IETF Network Slice consumer via the NBI. The 727 NSC NBI may also include a capability to provide notification in 728 case the IETF Network Slice performance reaches threshold values 729 defined by the IETF Network Slice consumer. 731 An IETF Network Slice user is served by the IETF Network Slice 732 Controller (NSC), as follows: 734 o The NSC takes requests from a management system or other 735 application, which are then communicated via an NBI. This 736 interface carries data objects the IETF Network Slice user 737 provides, describing the needed IETF Network Slices in terms of 738 topology, applicable service level objectives (SLO), and any 739 monitoring and reporting requirements that may apply. Note that - 740 in this context - "topology" means what the IETF Network Slice 741 connectivity is meant to look like from the user's perspective; it 742 may be as simple as a list of mutually (and symmetrically) 743 connected end points, or it may be complicated by details of 744 connection asymmetry, per-connection SLO requirements, etc. 746 o These requests are assumed to be translated by one or more 747 underlying systems, which are used to establish specific IETF 748 Network Slice instances on top of an underlying network 749 infrastructure. 751 o The NSC maintains a record of the mapping from user requests to 752 slice instantiations, as needed to allow for subsequent control 753 functions (such as modification or deletion of the requested 754 slices), and as needed for any requested monitoring and reporting 755 functions. 757 5.3.1. IETF Network Slice Controller Interfaces 759 The interworking and interoperability among the different 760 stakeholders to provide common means of provisioning, operating and 761 monitoring the IETF Network Slices is enabled by the following 762 communication interfaces (see Figure 2). 764 NSC Northbound Interface (NBI): The NSC Northbound Interface is an 765 interface between a consumer's higher level operation system 766 (e.g., a network slice orchestrator) and the NSC. It is a 767 technology agnostic interface. The consumer can use this 768 interface to communicate the requested characteristics and other 769 requirements (i.e., the SLOs) for the IETF Network Slice, and the 770 NSC can use the interface to report the operational state of an 771 IETF Network Slice to the consumer. 773 NSC Southbound Interface (SBI): The NSC Southbound Interface is an 774 interface between the NSC and network controllers. It is 775 technology-specific and may be built around the many network 776 models defined within the IETF. 778 +------------------------------------------+ 779 | Consumer higher level operation system | 780 | (e.g E2E network slice orchestrator) | 781 +------------------------------------------+ 782 A 783 | NSC NBI 784 V 785 +------------------------------------------+ 786 | IETF Network Slice Controller (NSC) | 787 +------------------------------------------+ 788 A 789 | NSC SBI 790 V 791 +------------------------------------------+ 792 | Network Controllers | 793 +------------------------------------------+ 795 Figure 2: Interface of IETF Network Slice Controller 797 5.3.2. Northbound Interface (NBI) 799 The IETF Network Slice Controller provides a Northbound Interface 800 (NBI) that allows consumers of network slices to request and monitor 801 IETF Network Slices. Consumers operate on abstract IETF Network 802 Slices, with details related to their realization hidden. 804 The NBI complements various IETF services, tunnels, path models by 805 providing an abstract layer on top of these models. 807 The NBI is independent of type of network functions or services that 808 need to be connected, i.e., it is independent of any specific 809 storage, software, protocol, or platform used to realize physical or 810 virtual network connectivity or functions in support of IETF Network 811 Slices. 813 The NBI uses protocol mechanisms and information passed over those 814 mechanisms to convey desired attributes for IETF Network Slices and 815 their status. The information is expected to be represented as a 816 well-defined data model, and should include at least endpoint and 817 connectivity information, SLO specification, and status information. 819 To accomplish this, the NBI needs to convey information needed to 820 support communication across the NBI, in terms of identifying the 821 IETF Network Slices, as well providing the above model information. 823 5.4. IETF Network Slice Structure 825 An IETF Network Slice is a set of connections among various endpoints 826 to form a logical network that meets the SLOs agreed upon. 828 |------------------------------------------| 829 NSE1 O....| |....O NSE2 830 . | | . 831 . | IETF Network Slice | . 832 . | (SLOs e.g. B/W > x bps, Delay < y ms) | . 833 NSEm O....| |....O NSEn 834 |------------------------------------------| 836 == == == == == == == == == == == == == == == == == == == == == == 838 .--. .--. 839 [EP1] ( )- . ( )- . [EP2] 840 . .' IETF ' SLO .' IETF ' . 841 . ( Network-1 ) ... ( Network-p ) . 842 `-----------' `-----------' 843 [EPm] [EPn] 845 Legend 846 NSE: IETF Network Slice Endpoints 847 EP: Serivce/tunnels/path Endpoints used to realize the 848 IETF Network Slice 850 Figure 3: IETF Network Slice 852 Figure 3 illustrates a case where an IETF Network Slice provides 853 connectivity between a set of IEFT network slice endpoints (NSE) 854 pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps 855 and guaranteed delay of no more than y ms). The IETF Network Slice 856 endpoints are mapped to the underlay IETF Network Slice Endpoints 857 (NEPs). Also, the IETF NSEs on the same IETF network slice may 858 belong to the same or different address spaces. 860 IETF Network Slice structure fits into a broader concept of end-to- 861 end network slices. A network operator may be responsible for 862 delivering services over a number of technologies (such as radio 863 networks) and for providing specific and fine-grained services (such 864 as CCTV feed or High definition realtime traffic data). That 865 operator may need to combine slices of various networks to produce an 866 end-to-end network service. Each of these networks may include 867 multiple physical or virtual nodes and may also provide network 868 functions beyond simply carrying of technology-specific protocol data 869 units. An end-to-end network slice is defined by the 3GPP as a 870 complete logical network that provides a service in its entirety with 871 a specific assurance to the consumer [TS23501]. 873 An end-to-end network slice may be composed from other network slices 874 that include IETF Network Slices. This composition may include the 875 hierarchical (or recursive) use of underlying network slices and the 876 sequential (or stitched) combination of slices of different networks. 878 5.5. Realizing IETF Network Slice 880 Realization of IETF Network Slices is out of scope of this document. 881 It is a mapping of the definition of the IETF Network Slice to the 882 underlying infrastructure and is necessarily technology-specific and 883 achieved by the NSC over the SBI. 885 The realization can be achieved in a form of either physical or 886 logical connectivity through VPNs (see, for example, 887 [I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies 888 such as Segment Routing, MPLS, etc. Accordingly, endpoints may be 889 realized as physical or logical service or network functions. 891 5.5.1. Underlying Technology 893 There are a number of different technologies that can be used, 894 including physical connections, MPLS, TSN, Flex-E, etc. 896 See Section 5 of [I-D.ietf-teas-enhanced-vpn] for instance, for 897 example underlying technologies. 899 Also, as outlined in "applicability of ACTN to IETF Network Slices" 900 below, ACTN ([RFC8453]) offers a framework that is used elsewhere in 901 IETF specifications to create virtual network (VN) services similar 902 to IETF Network Slices. 904 A IETF Network Slice can be realized in a network, using specific 905 underlying technology or technologies. The creation of a new IETF 906 Network Slice will be initiated with following three steps: 908 o Step 1: A higher level system requests connections with specific 909 characteristics via NBI. 911 o Step 2: This request will be processed by an IETF NSC which 912 specifies a mapping between northbound request to any IETF 913 Services, Tunnels, and paths models. 915 o Step 3: A series of requests for creation of services, tunnels and 916 paths will be sent to the network to realize the trasport slice. 918 It is very clear that regardless of how IETF Network Slice is 919 realized in the network (i.e., using tunnels of type RSVP or SR), the 920 definition of IETF Network Slice does not change at all but rather 921 its realization. 923 6. Applicability of ACTN to IETF Network Slices 925 Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an 926 example of similar IETF work. ACTN defines three controllers to 927 support virtual network (VN) services - 929 o Customer Network Controller (CNC), 931 o Multi-Domain Service Coordinator (MDSC) and 933 o Provisioning Network Controller (PNC). 935 A CNC is responsible for communicating a customer's VN requirements. 937 A MDSC is responsible for multi-domain coordination, virtualization 938 (or abstraction), customer mapping/translation and virtual service 939 coordination to realize the VN requirement. Its key role is to 940 detach the network/service requirements from the underlying 941 technology. 943 A PNC oversees the configuration, monitoring and collection of the 944 network topology. The PNC is a underlay technology specific 945 controller. 947 While the ACTN framework is a generic VN framework that is used for 948 various VN service beyond the IETF Network Slice, it is still a 949 suitable basis to understand how the various controllers interact to 950 realize a IETF Network Slice. 952 One possible mapping between the IETF Network Slice, and ACTN, 953 definitions is as shown in Figure 4. 955 IETF Network Slice | ACTN analogous 956 Terminology / Concepts Terminology 957 | and Concepts 958 +--------------------------------------+ 959 |Consumer higher level operation system| | +-----+ 960 | (e.g E2E network slice orchestrator) | =====> | CNC | 961 +--------------------------------------+ | +-----+ 962 ^ ^ 963 | NSC NBI | | CMI 964 v v 965 +-------------------------------------+ | +------+ 966 | IETF Network Slice Controller (NSC) | =====> | MDSC | 967 +-------------------------------------+ | +------+ 968 ^ ^ 969 | NSC SBI | | MPI 970 v v 971 +-------------------------------------+ | +-----+ 972 | Network Controller(s) | =====> | PNC | 973 +-------------------------------------+ | +-----+ 975 Figure 4: Mapping between IETF Network Slices and ACTN 977 The NSC NBI conveys the generic IETF Network Slice requirements. 978 These may then be realized using an SBI within the NSC. 980 As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC 981 Interface (CMI) is used to convey the virtual network service 982 requirements along with the service models and the MDSC-PNC Interface 983 (MPI) is used to realize the service along network configuration 984 models. [I-D.ietf-teas-te-service-mapping-yang] further describe how 985 the VPN services can be mapped to the underlying TE resources. 987 The Network Controller is depicted as a single block, analogous to a 988 Provisioning Network Controller (PNC - in this example). In the ACTN 989 framework, however, it is also possible that the NC function is 990 decomposed into MDSC and PNC - that is, the NC may comprise hierarchy 991 as needed to handle the multiple domains and various underlay 992 technologies, whereas a PNC in ACTN is intended to be specific to at 993 most a single underlay technology and (likely) to individual devices 994 (or functional components). 996 Note that the details of potential implementations of everything that 997 is below the NSC in Section 6 are out of scope in this document - 998 hence the specifics of the relationship between NC and PNC, and the 999 possibility that the MDSC and PNC may be combined are at most 1000 academically interesting in this context. Another way to view this 1001 is that, in the same way that ACTN might combine MDSC and PNC, the 1002 NSC might also directly include NC functionality. 1004 [RFC8453] also describes TE Network Slicing in the context of ACTN as 1005 a collection of resources that is used to establish a logically 1006 dedicated virtual network over one or more TE networks. In case of 1007 TE enabled underlying network, ACTN VN can be used as a base to 1008 realize the IETF Network Slicing by coordination among multiple peer 1009 domains as well as underlay technology domains. 1011 Section 6 shows only one possible mapping as each ACTN component (or 1012 interface) in the figure may be a composed differently in other 1013 mappings, and the exact role of both components and subcomponents 1014 will not be always an exact analogy between the concepts used in this 1015 document and those defined in ACTN. 1017 This is - in part - shown in a previous paragraph in this section 1018 where it is pointed out that the NC may actually subsume some aspects 1019 of both the MDSC and PNC. 1021 Similarly, in part depending on how "customer" is interpreted, CNC 1022 might merge some aspects of the higher level system and the NSC. As 1023 in the NC/PNC case, this way of comparing ACTN to this work is not 1024 useful as the NSC and NSC NBI are the focus on this document. 1026 7. Isolation in IETF Network Slices 1028 An IETF Network Slice consumer may request, that the IETF Network 1029 Slice delivered to them is isolated from any other network slices of 1030 services delivered to any other consumers. It is expected that the 1031 changes to the other network slices of services do not have any 1032 negative impact on the delivery of the IETF Network Slice. 1034 7.1. Isolation as a Service Requirement 1036 Isolation may be an important requirement of IETF Network Slices for 1037 some critical services. A consumer may express this request as an 1038 SLO. 1040 This requirement can be met by simple conformance with other SLOs. 1041 For example, traffic congestion (interference from other services) 1042 might impact on the latency experienced by an IETF Network Slice. 1043 Thus, in this example, conformance to a latency SLO would be the 1044 primary requirement for delivery of the IETF Network Slice service, 1045 and isolation from other services might be only a means to that end. 1047 It should be noted that some aspects of isolation may be measurable 1048 by a consumer who have the information about the traffic on a number 1049 of IETF Network Slices or other services. 1051 7.2. Isolation in IETF Network Slice Realization 1053 Delivery of isolation is achieved in the realization of IETF Network 1054 Slices, with existing, in-development, and potential new technologies 1055 in IETF. It depends on how a network operator decides to operate 1056 their network and deliver services. 1058 Isolation may be achieved in the underlying network by various forms 1059 of resource partitioning ranging from dedicated allocation of 1060 resources for a specific IETF Network Slice, to sharing or resources 1061 with safeguards. For example, traffic separation between different 1062 IETF Network Slices may be achieved using VPN technologies, such as 1063 L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by 1064 network capacity planning, allocating dedicated network resources, 1065 traffic policing or shaping, prioritizing in using shared network 1066 resources, etc. Finally, service continuity may be ensured by 1067 reserving backup paths for critical traffic, dedicating specific 1068 network resources for a selected number of network slices, etc. 1070 8. Management Considerations 1072 IETF Network Slice realization needs to be instrumented in order to 1073 track how it is working, and it might be necessary to modify the IETF 1074 Network Slice as requirements change. Dynamic reconfiguration might 1075 be needed. 1077 9. Security Considerations 1079 This document specifies terminology and has no direct effect on the 1080 security of implementations or deployments. In this section, a few 1081 of the security aspects are identified. 1083 o Conformance to security constraints: Specific security requests 1084 from consumer defined IETF Network Slices will be mapped to their 1085 realization in the unerlay networks. It will be required by 1086 underlay networks to have capabilities to conform to consumer's 1087 requests as some aspects of security may be expressed in SLOs. 1089 o IETF NSC authentication: Unerlying networks need to be protected 1090 against the attacks from an adversary NSC as they can destablize 1091 overall network operations. It is particularly critical since an 1092 IETF Network Slice may span across different networks, therefore, 1093 IETF NSC should have strong authentication with each those 1094 networks. Futhermore, both SBI and NBI need to be secured. 1096 o Specific isolation criteria: The nature of conformance to 1097 isolation requests means that it should not be possible to attack 1098 an IETF Network Slice service by varying the traffic on other 1099 services or slices carried by the same underlay network. In 1100 general, isolation is expected to strengthen the IETF Network 1101 Slice security. 1103 o Data Integrity of an IETF Network Slice: A consumer wanting to 1104 secure their data and keep it private will be responsible for 1105 applying appropriate security measures to their traffic and not 1106 depending on the network operator that provides the IETF Network 1107 Slice. It is expected that for data integrity, a consumer is 1108 responsible for end-to-end encryption of its own traffic. 1110 Note: see NGMN document[NGMN_SEC] on 5G network slice security for 1111 discussion relevant to this section. 1113 IETF Network Slices might use underlying virtualized networking. All 1114 types of virtual networking require special consideration to be given 1115 to the separation of traffic between distinct virtual networks, as 1116 well as some degree of protection from effects of traffic use of 1117 underlying network (and other) resources from other virtual networks 1118 sharing those resources. 1120 For example, if a service requires a specific upper bound of latency, 1121 then that service can be degraded by added delay in transmission of 1122 service packets through the activities of another service or 1123 application using the same resources. 1125 Similarly, in a network with virtual functions, noticeably impeding 1126 access to a function used by another IETF Network Slice (for 1127 instance, compute resources) can be just as service degrading as 1128 delaying physical transmission of associated packet in the network. 1130 While a IETF Network Slice might include encryption and other 1131 security features as part of the service, consumers might be well 1132 advised to take responsibility for their own security needs, possibly 1133 by encrypting traffic before hand-off to a service provider. 1135 9.1. Privacy Considerations 1137 Privacy of IETF Network Slice service consumers must be preserved. 1138 It should not be possible for one IETF Network Slice consumer to 1139 discover the presence of other consumers, nor should sites that are 1140 members of one IETF Network Slice be visible outside the context of 1141 that IETF Network Slice. 1143 In this sense, it is of paramount importance that the system use the 1144 privacy protection mechanism defined for the specific underlying 1145 technologies used, including in particular those mechanisms designed 1146 to preclude acquiring identifying information associated with any 1147 IETF Network Slice consumer. 1149 10. IANA Considerations 1151 There are no requests to IANA in this framework document. 1153 11. Acknowledgments 1155 The entire TEAS NS design team and everyone participating in related 1156 discussions has contributed to this document. Some text fragments in 1157 the document have been copied from the [I-D.ietf-teas-enhanced-vpn], 1158 for which we are grateful. 1160 Significant contributions to this document were gratefully received 1161 from the contributing authors listed in the "Contributors" section. 1162 In addition we would like to also thank those others who have 1163 attended one or more of the design team meetings, including the 1164 following people not listed elsewhere: 1166 o Aihua Guo 1168 o Bo Wu 1170 o Greg Mirsky 1172 o Lou Berger 1174 o Rakesh Gandhi 1176 o Ran Chen 1178 o Sergio Belotti 1180 o Stewart Bryant 1182 o Tomonobu Niwa 1184 o Xuesong Geng 1186 12. Contributors 1188 The following authors contributed significantly to this document: 1190 Jari Arkko 1191 Ericsson 1192 Email: jari.arkko@piuha.net 1194 Dhruv Dhody 1195 Huawei, India 1196 Email: dhruv.ietf@gmail.com 1198 Jie Dong 1199 Huawei 1200 Email: jie.dong@huawei.com 1202 Xufeng Liu 1203 Volta Networks 1204 Email: xufeng.liu.ietf@gmail.com 1206 13. References 1208 13.1. Normative References 1210 [I-D.ietf-teas-ietf-network-slice-definition] 1211 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1212 Tantsura, "Definition of IETF Network Slices", draft-ietf- 1213 teas-ietf-network-slice-definition-00 (work in progress), 1214 January 2021. 1216 [I-D.ietf-teas-ietf-network-slice-framework] 1217 Gray, E. and J. Drake, "Framework for IETF Network 1218 Slices", draft-ietf-teas-ietf-network-slice-framework-00 1219 (work in progress), March 2021. 1221 13.2. Informative References 1223 [BBF-SD406] 1224 Broadband Forum, ., "End-to-end network slicing", BBF 1225 SD-406 , n.d.. 1227 [HIPAA] HHS, "Health Insurance Portability and Accountability Act 1228 - The Security Rule", February 2003, 1229 . 1232 [I-D.contreras-teas-slice-nbi] 1233 Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF 1234 Network Slice use cases and attributes for Northbound 1235 Interface of controller", draft-contreras-teas-slice- 1236 nbi-03 (work in progress), October 2020. 1238 [I-D.ietf-teas-actn-yang] 1239 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 1240 Shin, J., and S. Belotti, "Applicability of YANG models 1241 for Abstraction and Control of Traffic Engineered 1242 Networks", draft-ietf-teas-actn-yang-06 (work in 1243 progress), August 2020. 1245 [I-D.ietf-teas-enhanced-vpn] 1246 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1247 Framework for Enhanced Virtual Private Networks (VPN+) 1248 Service", draft-ietf-teas-enhanced-vpn-06 (work in 1249 progress), July 2020. 1251 [I-D.ietf-teas-te-service-mapping-yang] 1252 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 1253 and J. Tantsura, "Traffic Engineering (TE) and Service 1254 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 1255 yang-05 (work in progress), November 2020. 1257 [I-D.openconfig-rtgwg-gnmi-spec] 1258 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 1259 C., and C. Morrow, "gRPC Network Management Interface 1260 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 1261 progress), March 2018. 1263 [NGMN-NS-Concept] 1264 NGMN Alliance, ., "Description of Network Slicing 1265 Concept", https://www.ngmn.org/uploads/ 1266 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 1267 2016. 1269 [NGMN_SEC] 1270 NGMN Alliance, "NGMN 5G Security - Network Slicing", April 1271 2016, . 1274 [PCI] PCI Security Standards Council, "PCI DSS", May 2018, 1275 . 1277 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1278 Schoenwaelder, Ed., "Structure of Management Information 1279 Version 2 (SMIv2)", STD 58, RFC 2578, 1280 DOI 10.17487/RFC2578, April 1999, 1281 . 1283 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1284 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1285 September 1999, . 1287 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1288 Address Translator (Traditional NAT)", RFC 3022, 1289 DOI 10.17487/RFC3022, January 2001, 1290 . 1292 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1293 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1294 DOI 10.17487/RFC3393, November 2002, 1295 . 1297 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1298 "Message Processing and Dispatching for the Simple Network 1299 Management Protocol (SNMP)", STD 62, RFC 3412, 1300 DOI 10.17487/RFC3412, December 2002, 1301 . 1303 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1304 (USM) for version 3 of the Simple Network Management 1305 Protocol (SNMPv3)", STD 62, RFC 3414, 1306 DOI 10.17487/RFC3414, December 2002, 1307 . 1309 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 1310 Network Management Protocol (SNMP)", STD 62, RFC 3417, 1311 DOI 10.17487/RFC3417, December 2002, 1312 . 1314 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1315 "Generalized Multiprotocol Label Switching (GMPLS) User- 1316 Network Interface (UNI): Resource ReserVation Protocol- 1317 Traffic Engineering (RSVP-TE) Support for the Overlay 1318 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 1319 . 1321 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1322 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1323 . 1325 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 1326 Interpretation of Generalized Multiprotocol Label 1327 Switching (GMPLS) Terminology within the Context of the 1328 ITU-T's Automatically Switched Optical Network (ASON) 1329 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 1330 2006, . 1332 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1333 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 1334 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 1335 DOI 10.17487/RFC5212, July 2008, 1336 . 1338 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1339 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1340 DOI 10.17487/RFC5440, March 2009, 1341 . 1343 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1344 the Network Configuration Protocol (NETCONF)", RFC 6020, 1345 DOI 10.17487/RFC6020, October 2010, 1346 . 1348 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1349 NAT64: Network Address and Protocol Translation from IPv6 1350 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1351 April 2011, . 1353 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1354 and A. Bierman, Ed., "Network Configuration Protocol 1355 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1356 . 1358 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1359 Ed., "A One-Way Delay Metric for IP Performance Metrics 1360 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1361 2016, . 1363 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1364 Ed., "A One-Way Loss Metric for IP Performance Metrics 1365 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1366 2016, . 1368 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1369 Ceccarelli, D., and X. Zhang, "Problem Statement and 1370 Architecture for Information Exchange between 1371 Interconnected Traffic-Engineered Networks", BCP 206, 1372 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1373 . 1375 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1376 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1377 . 1379 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1380 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1381 . 1383 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1384 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1385 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1386 2018, . 1388 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1389 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1390 DOI 10.17487/RFC8453, August 2018, 1391 . 1393 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 1394 Yoon, "Information Model for Abstraction and Control of TE 1395 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 1396 September 2018, . 1398 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1399 O. Gonzalez de Dios, "YANG Data Model for Traffic 1400 Engineering (TE) Topologies", RFC 8795, 1401 DOI 10.17487/RFC8795, August 2020, 1402 . 1404 [TS23501] 3GPP, ., "System architecture for the 5G System (5GS)", 1405 3GPP TS 23.501 , 2019. 1407 [TS28530] 3GPP, ., "Management and orchestration; Concepts, use 1408 cases and requirements", 3GPP TS 28.530 , 2019. 1410 [TS33.210] 1411 3GPP, "3G security; Network Domain Security (NDS); IP 1412 network layer security (Release 14).", December 2016, 1413 . 1416 Appendix A. Unused Material 1418 This section includes material from the source documents that is not 1419 used in the body of this document. It is intended for deletion. 1421 For this purpose, the text is tagged to show its origin using the 1422 format or where the letters 'D' and 'F' indicate the 1423 definitions draft [I-D.ietf-teas-ietf-network-slice-definition] and 1424 the framework draft [I-D.ietf-teas-ietf-network-slice-framework] 1425 respectively, and the subsequent numbers indicate the the section of 1426 the source document. 1428 A.1. Abstract 1430 1432 This memo is intended for discussing interfaces and technologies. It 1433 is not intended to be a new set of concrete interfaces or 1434 technologies. Rather, it should be seen as an explanation of how 1435 some existing, concrete IETF VPN and traffic-engineering technologies 1436 can be used to create IETF network slices. Note that there are a 1437 number of these technologies, and new technologies or capabilities 1438 keep being added. This memo is also not intended presume any 1439 particular technology choice. 1441 A.2. Management Systems or Other Applications 1443 1445 The IETF Network Slice system is used by a management system or other 1446 application. These systems and applications may also be a part of a 1447 higher level function in the system, e.g., putting together network 1448 functions, access equipment, application specific components, as well 1449 as the IETF Network Slices. 1451 Authors' Addresses 1453 Adrian Farrel (editor) 1454 Old Dog Consulting 1456 Email: adrian@olddog.co.uk 1458 Eric Gray 1459 Ericsson 1461 Email: ewgray@graiymage.com 1463 John Drake 1464 Juniper Networks 1466 Email: jdrake@juniper.net 1468 Reza Rokui 1469 Nokia 1471 Email: reza.rokui@nokia.com 1472 Shunsuke Homma 1473 NTT 1475 Email: shunsuke.homma.ietf@gmail.com 1477 Kiran Makhijani 1478 Futurewei 1480 Email: kiranm@futurewei.com 1482 Luis M. Contreras 1483 Telefonica 1484 Spain 1486 Email: luismiguel.contrerasmurillo@telefonica.com 1488 Jeff Tantsura 1489 Juniper Networks 1491 Email: jefftant.ietf@gmail.com