idnits 2.17.1 draft-nsdt-teas-transport-slice-definition-02.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 21, 2020) is 1465 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EU-x' is mentioned on line 670, but not defined == Missing Reference: 'EU-y' is mentioned on line 670, but not defined == Missing Reference: 'EP11' is mentioned on line 471, but not defined == Missing Reference: 'EP21' is mentioned on line 471, but not defined == Missing Reference: 'EP12' is mentioned on line 473, but not defined == Missing Reference: 'EP22' is mentioned on line 473, but not defined == Missing Reference: 'EP1m' is mentioned on line 475, but not defined == Missing Reference: 'EP2n' is mentioned on line 475, 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 (-12) exists of draft-ietf-teas-sf-aware-topo-model-05 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-02 Summary: 0 errors (**), 0 flaws (~~), 13 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: October 23, 2020 NTT 6 K. Makhijani 7 Futurewei 8 LM. Contreras 9 Telefonica 10 April 21, 2020 12 IETF Definition of Transport Slice 13 draft-nsdt-teas-transport-slice-definition-02 15 Abstract 17 This document describes the definition of a slice in the transport 18 networks and its characteristics. The purpose here is to bring 19 clarity and a common understanding of the transport slice concept and 20 describe related terms and their meaning. It explains how transport 21 slices can be used in end to end network slices, or independently. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 23, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 59 3. Definition and Scope of Transport slice . . . . . . . . . . . 4 60 4. Transport Slice System Characteristics . . . . . . . . . . . 4 61 4.1. Service Level Objectives on Transport Slice . . . . . . . 4 62 4.1.1. Isolation discussion . . . . . . . . . . . . . . . . 6 63 4.2. Endpoint Variation . . . . . . . . . . . . . . . . . . . 8 64 4.2.1. Types of Endpoints . . . . . . . . . . . . . . . . . 8 65 4.2.2. Connectivity Patterns . . . . . . . . . . . . . . . . 8 66 4.3. Vertical Transport Slice . . . . . . . . . . . . . . . . 9 67 4.4. Horizontal Composition of Transport slice . . . . . . . . 10 68 5. Transport Slice Structure . . . . . . . . . . . . . . . . . . 10 69 5.1. Stakeholders . . . . . . . . . . . . . . . . . . . . . . 12 70 5.2. Transport Slice Controller Interfaces . . . . . . . . . . 12 71 5.3. Transport slice Realization . . . . . . . . . . . . . . . 14 72 6. Relationship with End-to-End Network Slicing . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 17 76 10. Informative References . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 A number of use cases benefit from establishing a transport 82 connectivity according to the assurance of a specific set of network 83 resources. Some such services which might benefit from the transport 84 slices are: 86 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP]) 88 o Network wholesale services 90 o Network infrastructure sharing among the operators 92 o NFV connectivity (Data Center Interconnect) 94 o VPNs with specific characteristics 95 This document defines the concept of transport slices that provide 96 connectivity with specific use of network resources between a number 97 of end points over a shared network infrastructure. Transport slices 98 are created and managed within the scope of transport networks (e.g. 99 IP, MPLS, optical). They are expected to enable a diverse set of 100 applications that have different requirements on communication to 101 coexist on the same network infrastructure. 103 Transport slices relate to a more general topic of network slicing. 104 It is not the goal of this document to define this broader concept, 105 but in general, it is a methodology to describe the logical 106 partitioning of network resources associated with a service or an 107 application. 109 2. Terms and Abbreviations 111 The terms and abbreviations used in this document are listed below. 113 o E2E NS: End to End Network Slice 115 o TS: Transport Slice 117 o TSC: Transport Slice Controller 119 o EP: Endpoint 121 o EU: End User 123 o NBI: NorthBound Interface 125 o SBI: SouthBound Interface 127 o SLO: Service Level Objective 129 o SLA: Service Level Agreement 131 o MTBF: Mean Time Between Failures 133 o MTTR: Mean Time To Repair 135 Author's notes: This list may be non-exhaustive. Also, a light 136 explanation for each term would be required. Or this section may be 137 removed if it isn't needed. 139 3. Definition and Scope of Transport slice 141 The basic definition of a transport slice is as follows: 143 "A transport slice is a logical network topology connecting a number 144 of endpoints and a set of shared or dedicated network resources, 145 which are used to satisfy specific Service Level Objectives (SLO)". 147 SLOs are used to describe different network resources associated with 148 the service delivered and corresponding parameters necessary to 149 realize the transport slice. 151 Transport slice should be technology-agnostic, and the means for 152 realization can be chosen depending on several factors such as 153 service requirements, specifications or capabilities of underlying 154 infrastructure. The structure and different characteristics of 155 transport slices are described in the following sections. 157 4. Transport Slice System Characteristics 159 The characteristics here describe the properties and main 160 functionality related to different components of a system that 161 supports transport slices. 163 4.1. Service Level Objectives on Transport Slice 165 A transport slice is defined in terms of several quantifiable 166 objectives or SLOs. These objectives define a set of network 167 resource parameters or values necessary to provide a service a given 168 transport slice. SLOs need not concern with 'how' will they get 169 implemented or realized in the underlying networks. They may be 170 defined along the dimensions of operations (time, capacity, 171 compute...), reliability and, availability attributes. A non- 172 exhaustive list of characteristics types for transport slice is 173 described below: 175 o Guaranteed Bandwidth: assurance of minimum or range of the 176 bandwidth requirement. Requested unidirectionally. 178 o Guaranteed Latency: maximum permissible network delay when 179 transmitting between source and destination endpoints. Requested 180 unidirectionally. The latency is measured in terms of network 181 characteristics (excluding application-level latency). [RFC2681] 182 and [RFC7679] discuss round trip times and one-way metrics, 183 respectively. 185 o Minimal permissible jitter: packet delay variation (PDV) as 186 defined by [RFC3393] is measured by the difference in the one-way 187 delay between selected packets in a flow. Minimizing variations 188 in the delay are important for real-time applications, therefore, 189 jitter-prevention parameter provide minimal permissible jitter 190 expectations for a flow. 192 o Packet loss rate: To specify permissible packet loss rate between 193 two endpoints. For critical networks, this number may be very 194 close to zero. See [RFC7680]. 196 o NF resources: The endpoints in Section 4.2 performance depend on 197 resource allocated to those functions and can be specified in 198 terms of compute, memory and access control objectives points. 199 See [NFVGST]. 201 o Availability: concerns with how quickly network becomes available 202 after a fault. The requirements are specified through Meant time 203 between failures (MTBF), and Mean time to repair (MTTR) to acquire 204 availability metrics. 206 o Resource redundancy: represents reliability attributes in which a 207 backup or duplicate resources such as path (same SLOs - latency, 208 bandwidth, etc.), network functions (same compute, memory, etc.) 209 To meet no packet loss objective, packet replication maybe 210 necessary to guarantee that at least packets from one path was 211 achieved. However, we should consider this as 'how' aspect of 212 objective and not 'what'. 214 o Security: The objective of securing a transport slice concern with 215 three attributes: a) end-to-end encryption between source and 216 destination endpoints, this can be seen as the logical link 217 between source and destination end points requiring encryption, b) 218 Authentication and access control (ACLs) objectives to permit data 219 on this transport slice, c) Isolation, is also a characteristic of 220 security, to prevent interference between two or more slices or 221 other flows on the same infrastructure. Isolation is implied by 222 the definition of transport slice itself (logical 223 partitioning...). 225 o Resolution of guarantee: The above objectives can be resolved in 226 to either hard or soft guarantees. A hard guarantee is the one 227 that is not affected by other traffic. In a soft guarantee, a 228 violation (of the guarantee) may occur in rare cases due to 229 resource interference. In such cases, the guarantee will be 230 maintained by the network controller within a certain tolerance 231 level of that objective. Note that a hard guarantee does not 232 prevent from hardware failures, such as losing a node. Additional 233 protection against such issues is possible, by specifying those 234 characteristics separately (see item "resource redundancy" below). 236 Note also that the hard and soft guarantees do not say anything 237 about the specific implementation of how these guarantees are 238 achieved. Different implementations might use different 239 techniques, from avoiding oversubsription to dedicating particular 240 links or their virtual fractions to particular transport slices. 242 o Resource isolation: In some cases it may be necessary to dedicate 243 specific resources to the slice, for instance, for security 244 reasons. 246 o etc. 248 The framework [I-D.nsdt-teas-ns-framework] may further specify 249 mechanisms for the performance, assurance and monitoring of these 250 objectives. 252 Note: Additional objectives may be necessary to capture, such as 253 specifying well defined paths or domains that a slice may transit. A 254 transport slice carries multiple flows between the 2 endpoints, 255 therefore objectives should also say if they are aggregates or on per 256 flow basis and in such case to be specific enough for the system to 257 be able to identify these specifics (subset of flows). 259 Further description of a set of measurable attributes is captured in 260 [I-D.contreras-teas-slice-nbi]. 262 SLA vs SLO discussion: In defining transport slices, the term SLO 263 instead of SLA is used even though SLAs are more commonly used term 264 by the operators. SLOs are definitive and measurable parameters 265 associated with a service, therefore, network resource and 266 connectivity requirements are defined accurately. In contrast, 267 service level agreements represent contracts for a service between a 268 service provider and a service consumer (or subscriber). Providers 269 then translate SLA into SLO; these translations vary from one service 270 provider to the other. Therefore, all through within the scope of 271 transport slices term SLO will be used. 273 4.1.1. Isolation discussion 275 Due to overloading of the term, a further discussion is added to 276 highlight two aspects of isolation, first the resolution of isolation 277 of an objective (as described above) and second, the dedicated use or 278 a hard-separation perspective of the resource. 280 Providing a hard resolution of guarantee for the characteristics of a 281 transport slice means that the behavior and performance of other 282 transport slices should not impact that slice, even if they run over 283 the same underlying infrastructure or use logically shared network 284 resources. 286 In the context of soft resolution of guarantees, since the transport 287 slices are logically partitioned over the shared resources, a certain 288 degree of commitment to the guarantee is expected even when it is not 289 hard. When the shared resource pools begin to become saturated, SLO 290 violations can happen, however, impacting only the performance or 291 operation of service associated with the transport slice. 293 This degree of isolation can be derived from availability 294 characteristics requested, such as whether a hard or soft guarantee 295 was requested. Requesting a hard guarantee may commit more resources 296 than would be required for a softer limit. 298 In addition, resource isolation may be applied to ensure dedicated 299 access to a particular node, for instance. In such requests a 300 dedicated allocation to a link, node and/or other resources to create 301 a transport slice for a particular service. For example, a mission- 302 critical service may ask for a dedicated router and/or a link or port 303 for complete isolation from other services. 305 When realizing a transport slice, a network controller should be 306 responsible for allocating and providing resources according to the 307 specified objectives. 309 SLO violations can occur for two reasons and corresponding statements 310 apply 312 o Shared resource interference: i.e. multiple transport slices 313 simultaneously share the same resource, and one of them consume 314 the resource in surplus. If the SLO guarantees are strictly 315 required, then the network controller can be informed of this by 316 requesting a hard guarantee. Note that the terms hard and soft 317 limit are requirement oriented and different from what is 318 specified in, [I-D.ietf-teas-enhanced-vpn]). 320 o Resource failure or fault occurs, such as a link or node failure. 321 Where it is important to defend against these, the relevant 322 characteristics on resource redundancy (and perhaps some other 323 characteristics on restoration speed and other factors) need to be 324 specified. 326 * Restoration isolation: the network is not impacted for a period 327 longer than the given time. For example, failover or the 328 service restoration takes no longer than some number of 329 seconds. This is specified by Availability SLO. 331 * Protection isolation: the network path is protected with 332 specified backup path. This is specified by Availability SLO. 334 4.2. Endpoint Variation 336 Transport slice endpoints are the terminating or originating nodes 337 requiring connectivity with specific SLO. Endpoints may be devices 338 or functions. 340 4.2.1. Types of Endpoints 342 There are two types of endpoints based on the functions they perform. 344 Transport type EP: This type of end point performs forwarding 345 customer payload without any modification. E.g. routers, 346 switches. 348 Service type EP: This type of endpoint manipulates, processes or 349 modifies the user data payload (based on policies). A non- 350 exhaustive list of service functions includes: firewalls, WAN and 351 application acceleration, Deep Packet Inspection (DPI), server 352 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 353 enrichment functions, and TCP optimizers. The generic term "L4-L7 354 services" is often used to describe such service functions (SFs). 356 This document leverages the term Network Function (NF) to represent 357 both types of endpoints in [I-D.ietf-teas-sf-aware-topo-model]. 359 4.2.2. Connectivity Patterns 361 Endpoints may be connected point to point (P2P), point to multipoint 362 (P2MP), multi-point to point (MP2P), or multi-point to multi-point 363 (MP2MP) based on the topology requested by the customer. 365 P2P pattern: P2P type of connections are between 2 endpoints like a 366 pseudowire, or a logical link. The interconnections must 367 represent the SLOs as requested by the customer. 369 P2MP/MP2P/MP2MP patterns: P2MP/MP2P/MP2MP type connections will 370 interconnect two or more endpoints together (one to many, many to 371 one, many to many), representing an abstract topology or graph. 372 When describing P2MP/MP2P/MP2MP scenarios it should be possible 373 for each logical link to have different SLO than the other link in 374 the same graph. 376 4.3. Vertical Transport Slice 378 Transport slice may follow a hierarchical relationship that would 379 provide a vertical structure to it. This is used for building multi- 380 layer slices in which each layer provides an abstraction, as well as 381 an independent monitoring, performance, control and management of the 382 resources. The vertical transport slice characteristic maybe used in 383 2 forms: 385 o The Transport slice itself where it represents a hierarchy of 386 abstracted transport slices. In this case, realization will be 387 done just once with a particular technology. Thus, the lowest 388 transport slice in the hierarchy that can not be decomposed 389 further will be one to one mapping to its instance of realized 390 transport slice. 392 o Each layer (physical, datalink, or IP) has its own set of 393 resources that can be provided to the upper layer as a transport 394 slice. Thus, transport slice at one layer is used by the layer 395 above. This type of multi-layer vertical transport slice 396 associates resources at different layers. For example, an IP 397 transport slice would utilize one or more optical transport slice. 398 In this case, realization will be done for a particular technology 399 at that particular layer. Thus, the lowest transport slice in 400 this type of hierarchy that can not be decomposed further will be 401 an instance of realized physical layer transport slice. 403 <======================== TS1 ========================> 404 <=====TS11=======> <==============TS12===============> 405 <====TS121====> <=====TS122======> 406 .--. .--. .--. 407 ( )--. ( )--. ( )--. 408 .' ' .' ' .' ' 409 [EU-x] ( Network-1 ) ( Network-2 ) ... ( Network-3 ) [EU-y] 410 `-----------' `-----------' `----------' 411 | | | 412 | Operator-y | Operator-z | 414 Legend: 415 TSnnn: Level 3 vertical transport slice nnn 416 TSnn: Level 2 vertical transport slice nn 417 TSn: Level 1 transport Slice n 419 Figure 1: Transport Slice Vertical and Horizontal Composition 421 Figure 1 shows the transport slice hierarchy. Slices TS11 and TS12 422 are composed together to form TS1 that is the top level transport 423 slice definition, TS121 and TS122 collectively define TS12. The SLO 424 for bandwidth guarantee will be shared and latency guarantee will be 425 split into latency in networks 2 and 3. To emphasize the 426 hierarchical structure, consider Network-2 and Network-3 are in the 427 same administrative domain but use different transport technologies 428 SR and L2VPN respectively. Then instead of presenting 2 transport 429 slices, Operator-z can expose only one transport slice TS12 430 abstracting the underlying transport technology details. 432 Note: The specification to connect TS121 and TS122 are similar to 433 those connecting TS12 and TS11. 435 4.4. Horizontal Composition of Transport slice 437 In contrast, horizontal transport slices enable the composition of 438 multiple realized transport slices. Since transport slices are not 439 necessarily a single encapsulation tunnel and may traverse through 440 different data planes, each realized transport slice will require a 441 stitching, interworking or mapping function. These stitching 442 functions can be viewed as a type of intermediate network function 443 endpoints. For instance in Figure 1, TS11 and TS12 are horizontal 444 transport slices. If we assume that TS11 is an L2 tunnel and TS12 is 445 an SRV6 based path, then a 'Service type EP' (not shown in the 446 figure) is needed for translation. 448 Author's notes: This service type EP is a new type of transport slice 449 specific service function. We may call it transport slice gateway. 451 5. Transport Slice Structure 453 A transport slice has a set of connections and various endpoints to 454 form a logical network. The goal is to achieve specific SLO for a 455 customer as shown in Figure 2. The endpoints may be user equipment, 456 any physical or virtual network functions (PNF/VNF), or any network 457 service for that matter. Similarly, connections may be virtual or 458 physical links of any type of technology. 460 ____________________________ 461 [EP11]------/ /--[EP21] 462 / / 463 [EP12]----/ Transport Slice /----[EP22] 464 : / (SLOs e.g. / 465 : / B/W > x bps, Delay < y ms)/ 466 [EP1m]-/___________________________/-------[EP2n] 468 == == == == == == == == == == == == == == == == == == 470 .--. .--. 471 [EP11] ( )- . ( )- . [EP21] 472 .' ' SLO .' ' 473 [EP12] ( Network-1 ) ... ( Network-p ) [EP22] 474 : `-----------' `-----------' : 475 [EP1m] [EP2n] 477 Legend 478 SLOs in terms of attributes, e.g. BW, delay. 479 EP: Endpoint 480 B/W: Bandwidth 482 Figure 2: Transport slice 484 Figure 2 illustrates a case where a single transport slice provides 485 connectivity between any pair of endpoints with specific 486 characteristics for SLO (i.e., assuring bandwidth to at least x bps 487 and transmission delay to be less than y ms). The endpoints may be 488 distributed in the underlay networks, and transport slice can be 489 deployed across multiple network domains. Also, the endpoints on the 490 same transport slice may belong to the same address space. 492 The "Transport Slices" provides various connections with certain SLO 493 between various endpoints whereas the transport slice realization 494 addresses its implementation using various technologies. In short, 495 the structure of a transport slice involves both definition and its 496 realization. 498 A transport slice is built based on a request from a higher 499 operations system. The interface to higher operations systems should 500 express the needed connectivity in a technology-agnostic way, and 501 slice customers don't need to recognize concrete configurations based 502 on the technologies (e.g being more declarative than imperative). 503 The request to instantiate a transport slice is represented with some 504 indicators such as SLO, and technologies are selected and managed 505 accordingly. 507 In the context of network slices, the term sub-slice or slice-subnet 508 comes up in other standard organizations, however, w.r.t. the IP/MPLS 509 based transport networks these terms are all equivalent. 511 Furthermore, the structure of transport slices may be layered 512 vertically or composed horizontally, i.e. operationally, a transport 513 slice maybe decomposed in two or more transport slices which are then 514 independently realized and managed. This is further described in 515 Section 4.3. 517 5.1. Stakeholders 519 A transport slice and its realization involves the following 520 stakeholders and it is relevant to define them for consistent 521 terminology. 523 Customer or User: A customer is a user of transport slice. 524 Customers may request for monitoring of associated resources or 525 specific changes to them. A user may either directly manage its 526 service by interfacing with the transport slice controller or 527 indirectly through an orchestrator. 529 Orchestrator: An orchestrator is an entity that aggregates different 530 services, resource and network requirements. It interfaces with 531 the transport slice controllers. 533 Transport Slice Controller (TSC): It realizes a transport slice in 534 the network, maintains and monitors the run-time state of 535 resources and topologies associated with it. A well-defined 536 interface is needed between different types of transport slice 537 controller and different types of orchestrator. A transport slice 538 operator (or slice operator for short) manages one or more 539 transport slices using the Transport Slice Controller(s). 541 Transport Network Controller: is some form of network infrastructure 542 controller that offers network resources to TSC to realize a 543 particular transport slice. These may be existing network 544 controllers associated with one or more specific technologies that 545 may be adapted to the function of realizing transport slices in a 546 network. 548 5.2. Transport Slice Controller Interfaces 550 The interworking and inter-operability among the different 551 stakeholders is required to provide common means of provisioning, 552 operating and monitoring the transport slices. The following 553 communication interfaces are identified (see Figure 3). 555 TSC Northbound Interface (NBI): The TSC Northbound Interface is an 556 interface between a higher level system, e.g. 'E2E network slice 557 orchestrator' and the 'Transport slice controller'. It is a 558 technology agnostic interface. Over this NBI, slice 559 characteristics and other requirements can be informed to TSC and 560 current state of a transport slice may be requested. 562 TSC Southbound Interface (SBI): The TSC Southbound Interface is an 563 interface between 'Transport slice controller' and network 564 controller(s). These interfaces are technology-specific and can 565 utilize many of the existing data models such as L2SM, L3SM, VPN, 566 etc. TSC may request for network resources or request of their 567 current state for SLO assurance. 569 Note on technology -agnostic vs -specific use: These terms are 570 used in a transport slice's context. A transport slice from 571 customer level in TSC, is not concerned with the underlying 572 network protocol or technology (such as L2VPN, L2VPN, etc.) or 573 corresponding service model (L2SM, L3SM, etc.) representing that 574 protocol. Therefore, for example, both L2VPN, L2SM are 575 technology-specific from a customer of a slice's view. 576 Technology-agnostic simply means representing a transport slice 577 completely as a logical entity. 579 +------------------------------------------+ 580 | Customer | 581 +------------------------------------------+ 582 A 583 | 584 V 585 +------------------------------------------+ 586 | A higher level system | 587 | (e.g e2e network slice orchestrator) | 588 +------------------------------------------+ 589 A 590 | TSC NBI 591 V 592 +------------------------------------------+ 593 | Transport Slice Controller | 594 +------------------------------------------+ 595 A 596 | TSC SBI 597 V 598 +------------------------------------------+ 599 | Network Controller(s) | 600 +------------------------------------------+ 602 Figure 3: Interface of Transport Slice Controller 604 5.3. Transport slice Realization 606 Realization of a Transport Slice is a mapping of underlying 607 infrastructure with its definition. It is technology specific entity 608 that is created and maintained over southbound interfaces. The 609 Network controller(s) export the connectivity and resource mappings 610 to the TSC. The network controller abstracts the details of 611 underlying resources from the TSC. 613 The realization may be achieved in the form of either physical or 614 logical connectivity through VPNs, a variety of tunneling 615 technologies such as segment routing, SFC, etc. Accordingly, 616 endpoints may be realized as physical or logical service or network 617 functions. 619 6. Relationship with End-to-End Network Slicing 621 An end-to-end (E2E) network slice is a complete logical network that 622 provides a service in its entirety with a specific assurance to the 623 customer. A transport slice concerns with those assurance aspects 624 only within the transport networks. Consider Figure 4, where a 625 network operator has an E2E network slice that traverses multiple 626 technology-specific networks. Each of these networks might use any 627 number of technologies, including but not limited to IP, MPLS, Fiber- 628 Optics (e.g. WDM, DWDM), Passive Optical Networking (PON), 629 Microwave, etc. 631 Each of these networks includes multiple (physical or virtual) nodes 632 and may also provide network functions beyond simply carrying of 633 technology-specific protocol data units. The types of nodes used in 634 any of these networks may include: 636 o Packet/frame processing nodes (e.g., Routers, Switches) 638 o Application servers 640 o Service Functions(e.g., Firewall, Loadbalancer) 642 o Radio Access Network (RAN) components 644 o Mobile Core components 646 o Microwave transceivers 648 o Optical repeaters 650 o etc. 652 Each network may support different technologies and an E2E network 653 slice is a combination of these networks. As an example: 655 o Network 1 might contain multiple 5G RAN nodes connected to a few 656 Cell Site Gateways (CSG) routers. 658 o Network 2 might have one or more layer-3 routers and layer-2 659 switches which may run on top of an optical network. 661 o Network 3 might have a number of 5G RAN nodes connected to Passive 662 Optical Network (PON) switches. 664 <======================= E2E NS ======================> 665 <-OS1-> <-TS1-> <-TS2-> <-OS2-> ... <-TSn-> <-OSm-> 666 |------------------------------------------------------| 667 | .--. .--. .--. | 668 | ( )--. ( )--. ( )--. | 669 | .' ' .' ' .' ' | 670 [EU-x] | ( Network-1 ) ( Network-2 ) ... ( Network-p ) |[EU-y] 671 | `-----------' `-----------' `----------' | 672 | | 673 | Operator-z | 674 |------------------------------------------------------| 675 Legend: 676 E2E NS: End-to-end network slice 677 TSn: Transport Slice n 678 OSm: Other Slice m 679 EU-x: End User-x 680 EU-y: End User-y 682 Figure 4: E2E network slice 684 When an operator-z creates a specific E2E network slice, it may 685 create one or more of transport slices and other slices (application 686 logic or other system functions). 688 An independent E2E logical network (called E2E network slice) is 689 created for a service (e.g. CCTV, autonomous driving, HD map, etc.) 690 with a specific network SLO requirement e.g. a secure connection with 691 an E2E latency less than 5ms, from End User-x (EU-x) to End User-y 692 (EU-y). EU-x maybe a 5G user equipment such as an infotainment unit 693 in a car, CCTV, or a car for autonomous driving, etc. and EU-y in 5G 694 is 5G application server, IMS, etc. 696 In Figure 4, "E2E NS" is that logical network with requested SLO 697 between EU-x to EU-y and is associated with a customer and a specific 698 service type. 700 7. Security Considerations 702 TBD 704 8. IANA Considerations 706 This memo includes no request to IANA. 708 9. Acknowledgment 710 The entire TEAS NS design team and everyone participating in those 711 discussion has contributed to this draft. Particularly, Eric Gray, 712 Xufeng Liu, Jie Dong, Jeff Tantsura, and Jari Arkko for a thorough 713 review among other contributions. 715 10. Informative References 717 [I-D.contreras-teas-slice-nbi] 718 Contreras, L., Homma, S., and J. Ordonez-Lucena, 719 "Considerations for defining a Transport Slice NBI", 720 draft-contreras-teas-slice-nbi-01 (work in progress), 721 March 2020. 723 [I-D.ietf-teas-enhanced-vpn] 724 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 725 Framework for Enhanced Virtual Private Networks (VPN+) 726 Services", draft-ietf-teas-enhanced-vpn-05 (work in 727 progress), February 2020. 729 [I-D.ietf-teas-sf-aware-topo-model] 730 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 731 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 732 YANG Model", draft-ietf-teas-sf-aware-topo-model-05 (work 733 in progress), March 2020. 735 [I-D.nsdt-teas-ns-framework] 736 Gray, E. and J. Drake, "Framework for Transport Network 737 Slices", draft-nsdt-teas-ns-framework-02 (work in 738 progress), March 2020. 740 [NFVGST] ETSI, "NFVI Compute and Network Metrics Specification", 741 Febuary 2018, . 744 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 745 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 746 September 1999, . 748 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 749 Address Translator (Traditional NAT)", RFC 3022, 750 DOI 10.17487/RFC3022, January 2001, 751 . 753 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 754 Metric for IP Performance Metrics (IPPM)", RFC 3393, 755 DOI 10.17487/RFC3393, November 2002, 756 . 758 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 759 NAT64: Network Address and Protocol Translation from IPv6 760 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 761 April 2011, . 763 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 764 Ed., "A One-Way Delay Metric for IP Performance Metrics 765 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 766 2016, . 768 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 769 Ed., "A One-Way Loss Metric for IP Performance Metrics 770 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 771 2016, . 773 [TS.23.501-3GPP] 774 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 775 (V16.2.0): System Architecture for the 5G System (5GS); 776 Stage 2 (Release 16)", September 2019, 777 . 780 Authors' Addresses 782 Reza Rokui 783 Nokia 784 Canada 786 Email: reza.rokui@nokia.com 788 Shunsuke Homma 789 NTT 790 Japan 792 Email: shunsuke.homma.fp@hco.ntt.co.jp 794 Kiran Makhijani 795 Futurewei 796 USA 798 Email: kiranm@futurewei.com 799 Luis M. Contreras 800 Telefonica 801 Spain 803 Email: luismiguel.contrerasmurillo@telefonica.com