idnits 2.17.1 draft-nsdt-teas-transport-slice-definition-04.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 (September 9, 2020) is 1318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EU-x' is mentioned on line 713, but not defined == Missing Reference: 'EU-y' is mentioned on line 713, but not defined == Missing Reference: 'EP11' is mentioned on line 511, but not defined == Missing Reference: 'EP21' is mentioned on line 511, but not defined == Missing Reference: 'EP12' is mentioned on line 513, but not defined == Missing Reference: 'EP22' is mentioned on line 513, but not defined == Missing Reference: 'EP1m' is mentioned on line 515, but not defined == Missing Reference: 'EP2n' is mentioned on line 515, but not defined == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-01 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 teas R. Rokui 3 Internet-Draft Nokia 4 Intended status: Informational S. Homma 5 Expires: March 13, 2021 NTT 6 K. Makhijani 7 Futurewei 8 LM. Contreras 9 Telefonica 10 J. Tantsura 11 Apstra, Inc. 12 September 9, 2020 14 IETF Definition of Transport Slice 15 draft-nsdt-teas-transport-slice-definition-04 17 Abstract 19 This document describes the definition of a slice in the transport 20 networks and its characteristics. The purpose here is to bring 21 clarity and a common understanding of the transport slice concept and 22 describe related terms and their meaning. It explains how transport 23 slices can be used in combination with end to end network slices, or 24 independently. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 13, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 63 3. Definition and Scope of Transport Slice . . . . . . . . . . . 4 64 4. Transport Slice System Characteristics . . . . . . . . . . . 5 65 4.1. Service Level Objectives for Transport Slices . . . . . . 5 66 4.1.1. Minimal Set of SLOs . . . . . . . . . . . . . . . . . 5 67 4.1.2. Other Objectives . . . . . . . . . . . . . . . . . . 7 68 4.2. Transport Slice Endpoints . . . . . . . . . . . . . . . . 8 69 4.2.1. Transport Slice Connectivity Types . . . . . . . . . 9 70 4.3. Vertical Composition of Transport Slice . . . . . . . . . 9 71 4.4. Horizontal Composition of Transport Slice . . . . . . . . 11 72 5. Transport Slice Structure . . . . . . . . . . . . . . . . . . 11 73 5.1. Stakeholders . . . . . . . . . . . . . . . . . . . . . . 13 74 5.2. Transport Slice Controller Interfaces . . . . . . . . . . 14 75 5.3. Transport slice Realization . . . . . . . . . . . . . . . 15 76 6. Isolation in Transport Slices . . . . . . . . . . . . . . . . 15 77 6.1. Traffic Isolation . . . . . . . . . . . . . . . . . . . . 15 78 6.2. Dedicated Resources . . . . . . . . . . . . . . . . . . . 15 79 7. Relationship with End-to-End Network Slicing . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 17 83 11. Informative References . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 A number of use cases benefit from establishing network connectivity 89 providing transport and assurance of a specific set of network 90 resources. In this document, as detailed in the subsequent sections, 91 we refer to this connectivity and resource commitment as the 92 transport slice. Services that might benefit from the transport 93 slices include but not limited to: 95 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP]) 96 o Network wholesale services 98 o Network infrastructure sharing among operators 100 o NFV connectivity and Data Center Interconnect 102 This document defines the concept of transport slices that provide 103 connectivity with a specific commitment of network resources between 104 a number of end points over a shared network infrastructure. 106 1.1. Rationale 108 Transport slices are created and managed within the scope of one or 109 more underlying network technologies (e.g., IP, MPLS, optical). 110 Transport slices are expected to enable a diverse set of applications 111 that have different requirements to coexist on the same network 112 infrastructure. 114 Transport slice is described as a construct that specifies 115 connectivity requirements, emphasizing on assurance of those 116 requirements. Transport slice is unaware of the underlying 117 infrastructure connectivity (hence, the term "transport"). The types 118 of underlying networking technologies can be based on any combination 119 of IP, Ethernet, MPLS, and optical technologies. Transport slices 120 also include specification of resources related to network functions 121 required by customer applications. 123 Traditionally, VPNs have focussed on segmentation, i.e., creation and 124 management of the private networks. They are bound to a specific 125 traffic type and are technology specific. In contrast, transport 126 slices concern with the assurance of resources required from the 127 network and provide a common user interface for describing those 128 resources. A service provider can use many aspects of the VPNs to 129 build the transport slices. 131 Transport slices relate to a more general topic of network slicing. 132 It is not the goal of this document to define this broader concept, 133 but in general, it is to identify the methodology to describe the 134 logical (or abstract) partitioning of network resources associated 135 with a service or an application. 137 2. Terms and Abbreviations 139 The terms and abbreviations used in this document are listed below. 141 o E2E NS: End to End Network Slice 143 o TS: Transport Slice 144 o TSC: Transport Slice Controller 146 o EP: Endpoint 148 o EU: End User 150 o NBI: NorthBound Interface 152 o SBI: SouthBound Interface 154 o SLI: Service Level Indicator A well defined quantitative measure 155 of some aspect of the level of service that is provided. 157 o SLO: Service Level Objective A target value or range of values for 158 a service level that is measured by an SLI. A natural structure 159 for SLOs is thus SLI <= target, or lower bound <= SLI <= upper 160 bound. 162 o SLA: Service Level Agreement An explicit or implicit contract with 163 the end users that includes consequences of meeting (or missing) 164 the SLOs they contain. 166 The above terminology is described in greater detail in the remainder 167 of this document. 169 3. Definition and Scope of Transport Slice 171 The definition of a transport slice is as follows: 173 "A transport slice is a logical network topology connecting a number 174 of endpoints with a set of shared or dedicated network resources, 175 that are used to satisfy specific Service Level Objectives (SLOs)". 177 The text below describes transport slices in more details. 179 Transport slice specification is technology-agnostic, and the means 180 for transport slice realization can be chosen depending on several 181 factors such as: service requirements, specifications or capabilities 182 of underlying infrastructure. The structure and different 183 characteristics of transport slices are described in the following 184 sections. 186 The term "transport" in transport slice is derived from the 187 definition of Transport Network in the section 1.3.1 of [RFC5921] : A 188 Transport Network provides transparent transmission of user traffic 189 between attached client devices by establishing and maintaining 190 point-to-point or point-to-multipoint connections between such 191 devices. "Slice" refers to a set of characteristics that separate 192 one type of user-traffic from other types. Transport slice assumes 193 that an underlying transport network is capable of changing the 194 configurations of the network devices on demand, through in-band 195 signaling or via controller(s) and to provide transport transmissions 196 with fulfilling all or some of SLOs to all of the traffic in the 197 slice or to specific flows. 199 4. Transport Slice System Characteristics 201 The following subsections describe the characteristics needed for 202 support of transport slices. 204 4.1. Service Level Objectives for Transport Slices 206 A transport slice is defined in terms of several quantifiable 207 characteristics or service level objectives (SLOs). These objectives 208 define a set of network resource parameters or values necessary to 209 provide a service as requested for a given transport slice. SLOs do 210 not describe 'how' the transport slices will be implemented or 211 realized in the underlying network layers. Instead, they are defined 212 in terms of dimensions of operations (time, capacity, etc.), 213 availability and other attributes. A transport slice can have one or 214 more SLOs associated with it, all SLO's combined to form an SLA. The 215 SLO values are defined unidirectionally and for specific subsets of 216 two or more endpoints (i.e. for a subset of connections in transport 217 slice). 219 The SLOs and values associated with them that are exposed to the end 220 user, are in the form of Service Level Indicators (SLIs). If for 221 example the range of latencies a network can provide is 50ms-100ms, 222 then this would be the range of values the end user should be able to 223 request, it would be as low as 50ms or as high as 100ms or anything 224 in between. The values of requested SLOs should always be in the 225 range of values supported. The underlying networks must provide 226 means to monitor and measure the performance of transport slices 227 against the SLOs requested and verify that they are being met. Some 228 SLOs can be measured directly through a collection of metrics and 229 statistics from the network (commonly known as 'telemetry'), while 230 others are deduced from measurable objectives and may require 231 additional tools or mechanisms to measure their target values. 233 4.1.1. Minimal Set of SLOs 235 This document defines a minimal set of SLOs and later systems or 236 standards could extend this set and define more SLOs. For example, 237 we included Guaranteed bandwidth which is the minimum requested 238 bandwidth for the transport slice. The later standard might define 239 other SLOs related to bandwidth if needed. 241 Accordingly, SLOs can be categorized in to 'Directly Measurable 242 Objectives' or 'Indirectly Measurable Objectives' as follows: 244 Some of the 'Directly Measurable Objectives' are: 246 o Guaranteed Minimum Bandwidth 248 o Guaranteed Maximum Latency 250 o Maximum permissible delay variation 252 o Maximum permissible packet loss rate 254 o Availability 256 o Other objectives could be specified 258 Some of the 'Indirectly Measurable Objectives' are: 260 o Security 262 o others objectives such as geographical restrictions, maximum 263 occupancy level, etc. could be specified 265 The definition of these objectives are as follows: 267 o Guaranteed Minimum Bandwidth: Minimum guaranteed bandwidth between 268 two endpoints at any time. The bandwidth is measured in data rate 269 units of bits per second and is measured unidirectionally. 271 o Guaranteed Maximum Latency: Upper bound of network latency when 272 transmitting between two endpoints. The latency is measured in 273 terms of network characteristics (excluding application-level 274 latency). [RFC2681] and [RFC7679] discuss round trip times and 275 one-way metrics, respectively. 277 o Maximum permissible delay variation: Packet delay variation (PDV) 278 as defined by [RFC3393], is measured by the difference in the one- 279 way delay between sequential packets in a flow. Minimizing 280 variations in the delay is important for real-time applications. 282 o Maximum permissible packet loss rate: is defined by the ratio of 283 packets dropped to packets transmitted between two endpoints. See 284 [RFC7680] 286 o Availability: is defined as the ratio of uptime to 287 total_time(uptime+downtime), where uptime is the time the 288 transport slice is available in accordance with the SLOs 289 associated with it. 291 o Security: This objective may request for encryption [RFC4303] 292 between two end-points explicitly to meet architecture 293 recommendations as in [TS33.210] or for compliance with [HIPAA] 294 [PCI]. Other security requests may be made as specified in 295 [draft-ietf-i2nsf-capability]. 297 * Note: Security violations are not directly observable and 298 cannot be measured as quantifiable metrics. Still, the user of 299 the transport slice should be able to request certain criteria 300 for compliance and identify exceptions and unexpected traffic. 301 For this purpose [i2nsf-nsf-monitoring-data-model] can be 302 leveraged. 304 4.1.2. Other Objectives 306 Additional objectives, such as certain geographical restrictions or 307 well defined domains that a slice may transit may be necessary. 309 Optionally, when the customer is traffic aware, other traffic 310 specific characteristics may be provided. These include for example, 311 MTU, traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a 312 higher-level behavior to process traffic according to user- 313 application (which may be realized using network functions). 315 Maximal occupancy for a transport slice should be provided. Since it 316 carries traffic for multiple flows between the two endpoints, the 317 objectives should also say if they are for the entire connection, 318 group of flows or on per flow basis. Maximal occupancy should 319 specify the scale of the flows (i.e. maximum number of accommodatable 320 flows) and optionally a maximum number of countable resource units, 321 e.g IP or MAC addresses a slice might consume. 323 With these objectives incorporated, a customer sees transport slice 324 as a dedicated network for its exclusive use. Achieving this may 325 require explicit request for different types of isolation in provider 326 networks as described in Section 6. 328 Additional description of slice attributes is covered in a broader 329 context of 'Generic Network Slice Template' in 330 [I-D.contreras-teas-slice-nbi]. 332 4.2. Transport Slice Endpoints 334 The transport slice endpoints are the conceptual entities that 335 perform any required conversion, or adaptation, and forwarding of the 336 user traffic. The characteristics of the transport slice endpoints 337 (TSE) are: 339 o They are conceptual points of connection of a network function, 340 device or application to the transport slice 342 o They are identified in a request provided by the customer of 343 transport slice (i.e. higher level operation systems) during the 344 creation of the transport slice 346 o They are associated with a device, application and/or network 347 function nodes. A non-exhaustive list of such nodes are routers, 348 switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, 349 application acceleration, Deep Packet Inspection (DPI), server 350 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 351 enrichment functions, and TCP optimizers 353 o A TSE is identified by its associated node (its IP address, name , 354 ID, etc.), a unique identifier and/or a unique name and other 355 data. A non-exhaustive list of other data includes IP address (v4 356 or v6), VLAN, port, connectivity type (P2P, P2MP, MP2MP). TBD for 357 more 359 Note that the TSE is different from access points (AP) defined in 360 [RFC8453] as an AP is a logical identifier to identify the shared 361 link between the customer and the operator where as TSE is an 362 identifier of an endpoint. Also TSE is different from TE Link 363 Termination Point (LTP) defined in [I-D.ietf-teas-yang-te-topo] as it 364 is a conceptual point of connection of a TE node to one of the TE 365 links on a TE node. 367 The TSE is similar to the Termination Point (TP) defined in [RFC8345] 368 and can contain more attributes. TSE could be modeled by augmenting 369 the TP model. 371 There is another type of the endpoints called "Transport Slice 372 Realization endpoints (TSREs)". These endpoints are allocated and 373 assigned by the network controller during the realization of a 374 transport slice and are technology-specific, i.e. they depend on the 375 network technology used during the transport slice realization. They 376 are identified by a node and some associated data. A non-exhaustive 377 list of nodes containing TSREs are routers, switches, PON nodes, 378 Wireless nodes and Optical devices. 380 Note that there will be a mapping between TSE and TSRE on Transport 381 Slice Controller (TSC). When TSC receives a request via its NBI to 382 create a transport slice between multiple TSEs, it will send the 383 request via its SBI to realize the transport slice. The TSRE will be 384 notified by network controller during TS realization to enable 385 mapping between TSREs and the TSEs. 387 Figure 1 shows an example of a transport slice and its realization 388 between multiple TSEs and TSREs. 390 (-------------------) 391 ( Transport Network ) 392 DAN1 ( ) DAN2 393 -------- TSRE1 -------- -------- TSRE2 -------- 394 | o |-------o| A | | B |o--------| o | 395 | TSE1| -------- -------- | TSE2 | 396 -------- | ( ) | -------- 397 | | ( ) | | 398 | | (-------------------) | | 399 | | | | 400 | | <=============================> | | 401 | Transport slice realization | 402 | between TSRE1 and TSRE2 | 403 | | 404 | <===================================================> | 405 Transport slice between TSE1 and TSE2 with SLO1 407 Legend: 408 DAN: Device, application and/or network function 410 Figure 1: A transport slice between TSEs and its realization between 411 TSREs 413 4.2.1. Transport Slice Connectivity Types 415 The transport slices connection types can be point to point (P2P), 416 point to multipoint (P2MP), multi-point to point (MP2P), or multi- 417 point to multi-point (MP2MP). The transport slice connection type 418 will requested by the higher level operation system. 420 4.3. Vertical Composition of Transport Slice 422 Transport slice may follow a hierarchical relationship to provide a 423 vertical structure to it. This is used for composing multi-layer 424 slices in which each layer provides an abstraction, as well as an 425 independent monitoring, performance, control and management of the 426 resources. The vertical transport slice characteristic could be used 427 in 2 forms: 429 o The Transport slice itself where it represents a hierarchy of 430 abstracted transport slices. In this case, the realization will 431 be done just once with a particular technology. Thus, the lowest 432 transport slice in the hierarchy that can not be decomposed 433 further will be one to one mapping to its instance of the realized 434 transport slice. 436 o Each layer (physical, datalink, or IP) has its own set of 437 resources that can be provided to the upper layer as a transport 438 slice. Thus, transport slice at one layer is used by the layer 439 above. This type of multi-layer vertical transport slice 440 associates resources at different layers. For example, an IP 441 transport slice would utilize one or more optical transport slice. 442 In this case, the realization will be done for a particular 443 technology at that particular layer. Thus, the lowest transport 444 slice in this type of hierarchy that can not be decomposed further 445 will be an instance of realized physical layer transport slice. 447 <======================== TS1 ========================> 448 <=====TS11=======> <==============TS12===============> 449 <====TS121====> <=====TS122======> 450 .--. .--. .--. 451 ( )--. ( )--. ( )--. 452 .' ' .' ' .' ' 453 [EU-x] ( Network-1 ) ( Network-2 ) ... ( Network-3 ) [EU-y] 454 `-----------' `-----------' `----------' 455 | | | 456 | Operator-y | Operator-z | 458 Legend: 459 TSnnn: Level 3 vertical transport slice nnn 460 TSnn: Level 2 vertical transport slice nn 461 TSn: Level 1 transport Slice n 463 Figure 2: Transport Slice Vertical and Horizontal Composition 465 Figure 2 shows the transport slice hierarchy. Slices TS11 and TS12 466 are composed together to form TS1 that is the top level transport 467 slice definition, TS121 and TS122 collectively define TS12. The SLO 468 for bandwidth guarantee will be shared and latency guarantee will be 469 split into latency in networks 2 and 3. To emphasize the 470 hierarchical structure, consider Network-2 and Network-3 are in the 471 same administrative domain but use different transport technologies 472 respectively. Then instead of presenting 2 transport slices, 473 Operator-z can expose only one transport slice TS12 abstracting the 474 underlying transport technology details. 476 Note: The specification to connect TS121 and TS122 are similar to 477 those connecting TS12 and TS11. 479 4.4. Horizontal Composition of Transport Slice 481 In contrast, horizontal transport slices enable the composition of 482 multiple realized transport slices. Since transport slices are not 483 necessarily a single encapsulation tunnel and may traverse through 484 different data planes, each realized transport slice will require a 485 stitching, interworking or mapping function. These stitching 486 functions can be viewed as a type of intermediate network function 487 endpoints. For instance in Figure 2, TS11 and TS12 are horizontal 488 transport slices. If we assume that TS11 is an L2 tunnel and TS12 is 489 an SRV6 based path, then a 'Service type EP' (not shown in the 490 figure) is needed for translation. 492 Author's notes: This service type EP is a new type of transport slice 493 specific service function. We may call it transport slice gateway. 495 5. Transport Slice Structure 497 A transport slice is a set of connections among various endpoints to 498 form a logical network that meets the SLOs agreed upon. 500 ____________________________ 501 [EP11]------/ /--[EP21] 502 / / 503 [EP12]----/ Transport Slice /----[EP22] 504 : / (SLOs e.g. / 505 : / B/W > x bps, Delay < y ms)/ 506 [EP1m]-/___________________________/-------[EP2n] 508 == == == == == == == == == == == == == == == == == == 510 .--. .--. 511 [EP11] ( )- . ( )- . [EP21] 512 .' ' SLO .' ' 513 [EP12] ( Network-1 ) ... ( Network-p ) [EP22] 514 : `-----------' `-----------' : 515 [EP1m] [EP2n] 517 Legend 518 SLOs in terms of attributes, e.g. BW, delay. 519 EP: Endpoint 520 B/W: Bandwidth 522 Figure 3: Transport slice 524 Figure 3 illustrates a case where a transport slice provides 525 connectivity between a set of endpoints pairs with specific 526 characteristics for each SLO (e.g. guaranteed minimum bandwidth of x 527 bps and guaranteed delay of less than y ms). The endpoints may be 528 distributed in the underlay networks, and a transport slice can be 529 deployed across multiple network domains. Also, the endpoints on the 530 same transport slice may belong to the same address space. 532 Transport slices involve both customer's and provider's views. A 533 customer 'describes' its requirements in terms of connectivity with 534 specific SLOs. Provider networks address those requirements through 535 'transport slice realization' (its implementation) using provider 536 network specific technologies. 538 A transport slice is requested from an entity (such as an 539 orchestrator or a system-wide controller) performing broader service 540 or application specific functions. The interface from such an entity 541 should express the needed connectivity in a technology-agnostic way 542 and donot need to recognize configurations based on the technologies 543 (e.g. being more declarative than imperative). The request to 544 instantiate a transport slice is only represented with some 545 indicators such as SLOs based on which the underlying technologies 546 are selected and managed. 548 Often, in other SDOs the term sub-slice or slice-subnet comes up. 549 Some of those are mapped to transport network requirements in the 550 form of a transport slice. With in the scope of transport slices 551 (w.r.t. the IP/MPLS based transport networks) there are no 552 definitions for 'sub-slice' or 'slice subnets'. 'Transport slice' 553 term universally represents SLO and connectivity requirements from 554 the transport networks. 556 Furthermore, the structure of transport slices may be layered 557 vertically or composed horizontally, i.e. operationally, a transport 558 slice maybe decomposed in two or more transport slices which are then 559 independently realized and managed. This is further described in 560 Section 4.3. 562 5.1. Stakeholders 564 A transport slice and its realization involves the following 565 stakeholders and it is relevant to define them for consistent 566 terminology. 568 Customer or User: A customer is a user of a transport slice. 569 Customers may request monitoring of associated resources or 570 specific changes. A user may either directly manage its service 571 by interfacing with the transport slice controller or indirectly 572 through an orchestrator. 574 Orchestrator: An orchestrator is an entity that composes different 575 services, resource and network requirements. It interfaces with 576 the transport slice controllers. 578 Transport Slice Controller (TSC): It realizes a transport slice in 579 the network, maintains and monitors the run-time state of 580 resources and topologies associated with it. A well-defined 581 interface is needed between different types of transport slice 582 controllers and different types of orchestrators. A transport 583 slice operator (or slice operator for short) manages one or more 584 transport slices using the Transport Slice Controller(s). 586 Transport Network Controller: is a form of network infrastructure 587 controller that offers network resources to TSC to realize a 588 particular transport slice. These may be existing network 589 controllers associated with one or more specific technologies that 590 may be adapted to the function of realizing transport slices in a 591 network. 593 5.2. Transport Slice Controller Interfaces 595 The interworking and interoperability among the different 596 stakeholders to provide common means of provisioning, operating and 597 monitoring the transport slices is a mandatory requirement. The 598 following communication interfaces are identified (see Figure 4). 600 TSC Northbound Interface (NBI): The TSC Northbound Interface is an 601 interface between a higher level operation system, e.g. 'E2E 602 network slice orchestrator' and the 'Transport slice controller'. 603 It is a technology agnostic interface. Over this NBI, slice 604 characteristics and other requirements can be communicated to TSC 605 and the operational state of a transport slice may be requested. 607 TSC Southbound Interface (SBI): The TSC Southbound Interface is an 608 interface between 'Transport slice controller (TSC)' and network 609 controller(s). These interfaces are technology-specific and 610 utilize many of the network models. 612 +------------------------------------------+ 613 | Customer | 614 +------------------------------------------+ 615 A 616 | 617 V 618 +------------------------------------------+ 619 | A higher level operation system | 620 | (e.g e2e network slice orchestrator) | 621 +------------------------------------------+ 622 A 623 | TSC NBI 624 V 625 +------------------------------------------+ 626 | Transport Slice Controller | 627 +------------------------------------------+ 628 A 629 | TSC SBI 630 V 631 +------------------------------------------+ 632 | Network Controller(s) | 633 +------------------------------------------+ 635 Figure 4: Interface of Transport Slice Controller 637 5.3. Transport slice Realization 639 Realization of a Transport Slice is a mapping of underlying 640 infrastructure with its definition. It is a technology specific 641 entity that is created and maintained over its southbound interfaces. 642 The Network controller(s) export the connectivity and resource 643 mappings to the TSC. The network controller abstracts the details of 644 underlying resources from the TSC. 646 The realization can be achieved in the form of either physical or 647 logical connectivity through VPNs, a variety of tunneling 648 technologies such as Segment Routing, SFC, etc. Accordingly, 649 endpoints may be realized as physical or logical service or network 650 functions. 652 6. Isolation in Transport Slices 654 6.1. Traffic Isolation 656 This section will describe the scope and use of term isolation. 658 6.2. Dedicated Resources 660 This section explains the scope and use of term dedicated resource in 661 the context of transport slices. 663 7. Relationship with End-to-End Network Slicing 665 An end-to-end (E2E) network slice is a complete logical network that 666 provides a service in its entirety with a specific assurance to the 667 customer. A transport slice concerns with those assurance aspects 668 only within the transport networks. Consider Figure 5, where a 669 network operator has an E2E network slice that traverses multiple 670 technology-specific networks. Each of these networks might use any 671 number of technologies, including but not limited to IP, MPLS, Fiber- 672 Optics (e.g. WDM, DWDM), Passive Optical Networking (PON), 673 Microwave, etc. 675 Each of these networks includes multiple (physical or virtual) nodes 676 and may also provide network functions beyond simply carrying of 677 technology-specific protocol data units. The types of nodes used in 678 any of these networks may include: 680 o Packet/frame processing nodes (e.g., Routers, Switches) 682 o Application servers 684 o Service Functions(e.g., Firewall, Loadbalancer) 685 o Radio Access Network (RAN) components 687 o Mobile Core components 689 o Microwave transceivers 691 o Optical repeaters 693 o etc. 695 Each network may support different technologies and an E2E network 696 slice is a combination of these networks. As an example: 698 o Network 1 might contain multiple 5G RAN nodes connected to a few 699 Cell Site Gateways (CSG) routers. 701 o Network 2 might have one or more layer-3 routers and layer-2 702 switches which may run on top of an optical network. 704 o Network 3 might have a number of 5G RAN nodes connected to Passive 705 Optical Network (PON) switches. 707 <======================= E2E NS ======================> 708 <-OS1-> <-TS1-> <-TS2-> <-OS2-> ... <-TSn-> <-OSm-> 709 |------------------------------------------------------| 710 | .--. .--. .--. | 711 | ( )--. ( )--. ( )--. | 712 | .' ' .' ' .' ' | 713 [EU-x] | ( Network-1 ) ( Network-2 ) ... ( Network-p ) |[EU-y] 714 | `-----------' `-----------' `----------' | 715 | | 716 | Operator-z | 717 |------------------------------------------------------| 718 Legend: 719 E2E NS: End-to-end network slice 720 TSn: Transport Slice n 721 OSm: Other Slice m 722 EU-x: End User-x 723 EU-y: End User-y 725 Figure 5: E2E network slice 727 When operator-z creates a specific E2E network slice, it may create 728 one or more of transport slices and other slices (application logic 729 or other system functions). 731 An independent E2E logical network (called E2E network slice) is 732 created for a service (e.g. CCTV, autonomous driving, HD map, etc.) 733 with a specific network SLOs, e.g. a secure connection with an E2E 734 latency less than 5ms, from End User-x (EU-x) to End User-y (EU-y). 735 EU-x maybe a 5G user equipment such as an infotainment unit in a car, 736 CCTV, or a car for autonomous driving, etc. and EU-y in 5G is 5G 737 application server, IMS, etc. 739 In Figure 5, "E2E NS" is that logical network with requested SLO 740 between EU-x to EU-y and is associated with a customer and a specific 741 service type. 743 8. Security Considerations 745 Not applicable in this memo. 747 9. IANA Considerations 749 This memo includes no request to IANA. 751 10. Acknowledgment 753 The entire TEAS NS design team and everyone participating in those 754 discussion has contributed to this draft. Particularly, Eric Gray, 755 Xufeng Liu, Jie Dong, and Jari Arkko for a thorough review among 756 other contributions. 758 11. Informative References 760 [HIPAA] HHS, "Health Insurance Portability and Accountability Act 761 - The Security Rule", February 2003, 762 . 765 [I-D.contreras-teas-slice-nbi] 766 Contreras, L., Homma, S., and J. Ordonez-Lucena, 767 "Considerations for defining a Transport Slice NBI", 768 draft-contreras-teas-slice-nbi-01 (work in progress), 769 March 2020. 771 [I-D.ietf-teas-yang-te-topo] 772 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 773 O. Dios, "YANG Data Model for Traffic Engineering (TE) 774 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 775 progress), June 2019. 777 [PCI] PCI Security Standards Council, "PCI DSS", May 2018, 778 . 780 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 781 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 782 September 1999, . 784 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 785 Address Translator (Traditional NAT)", RFC 3022, 786 DOI 10.17487/RFC3022, January 2001, 787 . 789 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 790 Metric for IP Performance Metrics (IPPM)", RFC 3393, 791 DOI 10.17487/RFC3393, November 2002, 792 . 794 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 795 RFC 4303, DOI 10.17487/RFC4303, December 2005, 796 . 798 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 799 L., and L. Berger, "A Framework for MPLS in Transport 800 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 801 . 803 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 804 NAT64: Network Address and Protocol Translation from IPv6 805 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 806 April 2011, . 808 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 809 Ed., "A One-Way Delay Metric for IP Performance Metrics 810 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 811 2016, . 813 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 814 Ed., "A One-Way Loss Metric for IP Performance Metrics 815 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 816 2016, . 818 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 819 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 820 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 821 2018, . 823 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 824 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 825 DOI 10.17487/RFC8453, August 2018, 826 . 828 [TS.23.501-3GPP] 829 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 830 (V16.2.0): System Architecture for the 5G System (5GS); 831 Stage 2 (Release 16)", September 2019, 832 . 835 [TS33.210] 836 3GPP, "3G security; Network Domain Security (NDS); IP 837 network layer security (Release 14).", December 2016, 838 . 841 Authors' Addresses 843 Reza Rokui 844 Nokia 845 Canada 847 Email: reza.rokui@nokia.com 849 Shunsuke Homma 850 NTT 851 Japan 853 Email: shunsuke.homma.ietf@gmail.com 855 Kiran Makhijani 856 Futurewei 857 USA 859 Email: kiranm@futurewei.com 861 Luis M. Contreras 862 Telefonica 863 Spain 865 Email: luismiguel.contrerasmurillo@telefonica.com 867 Jeff Tantsura 868 Apstra, Inc. 870 Email: jefftant.ietf@gmail.com