IETF Definition of Transport Slice

A number of use cases benefit from establishing network connectivity providing transport and assurance of a specific set of network resources. In this document, as detailed in the subsequent sections, we refer to this connectivity and resource commitment as the transport slice. Services that might benefit from the transport slices include but not limited to: 5G services (e.g. eMBB, URLLC, mMTC)(See ) Network wholesale services Network infrastructure sharing among operators NFV connectivity and Data Center Interconnect This document defines the concept of transport slices that provide connectivity with a specific commitment of network resources between a number of end points over a shared network infrastructure.

Transport slices are created and managed within the scope of one or more underlying network technologies (e.g., IP, MPLS, optical). Transport slices are expected to enable a diverse set of applications that have different requirements to coexist on the same network infrastructure. Transport slice is described as a construct that specifies connectivity requirements, emphasizing on assurance of those requirements. Transport slice is unaware of the underlying infrastructure connectivity (hence, the term "transport"). The types of underlying networking technologies can be based on any combination of IP, Ethernet, MPLS, and optical technologies. Transport slices also include specification of resources related to network functions required by customer applications. Traditionally, VPNs have focussed on segmentation, i.e., creation and management of the private networks. They are bound to a specific traffic type and are technology specific. In contrast, transport slices concern with the assurance of resources required from the network and provide a common user interface for describing those resources. A service provider can use many aspects of the VPNs to build the transport slices. Transport slices relate to a more general topic of network slicing. It is not the goal of this document to define this broader concept, but in general, it is to identify the methodology to describe the logical (or abstract) partitioning of network resources associated with a service or an application.

The terms and abbreviations used in this document are listed below. E2E NS: End to End Network Slice TS: Transport Slice TSC: Transport Slice Controller EP: Endpoint EU: End User NBI: NorthBound Interface SBI: SouthBound Interface SLI: Service Level Indicator A well defined quantitative measure of some aspect of the level of service that is provided. SLO: Service Level Objective A target value or range of values for a service level that is measured by an SLI. A natural structure for SLOs is thus SLI <= target, or lower bound <= SLI <= upper bound. SLA: Service Level Agreement An explicit or implicit contract with the end users that includes consequences of meeting (or missing) the SLOs they contain. The above terminology is described in greater detail in the remainder of this document.

The definition of a transport slice is as follows: "A transport slice is a logical network topology connecting a number of endpoints with a set of shared or dedicated network resources, that are used to satisfy specific Service Level Objectives (SLOs)". The text below describes transport slices in more details. Transport slice specification is technology-agnostic, and the means for transport slice realization can be chosen depending on several factors such as: service requirements, specifications or capabilities of underlying infrastructure. The structure and different characteristics of transport slices are described in the following sections. The term "transport" in transport slice is derived from the definition of Transport Network in the section 1.3.1 of : A Transport Network provides transparent transmission of user traffic between attached client devices by establishing and maintaining point-to-point or point-to-multipoint connections between such devices. "Slice" refers to a set of characteristics that separate one type of user-traffic from other types. Transport slice assumes that an underlying transport network is capable of changing the configurations of the network devices on demand, through in-band signaling or via controller(s) and to provide transport transmissions with fulfilling all or some of SLOs to all of the traffic in the slice or to specific flows.

The following subsections describe the characteristics needed for support of transport slices.

A transport slice is defined in terms of several quantifiable characteristics or service level objectives (SLOs). These objectives define a set of network resource parameters or values necessary to provide a service as requested for a given transport slice. SLOs do not describe 'how' the transport slices will be implemented or realized in the underlying network layers. Instead, they are defined in terms of dimensions of operations (time, capacity, etc.), availability and other attributes. A transport slice can have one or more SLOs associated with it, all SLO's combined to form an SLA. The SLO values are defined unidirectionally and for specific subsets of two or more endpoints (i.e. for a subset of connections in transport slice). The SLOs and values associated with them that are exposed to the end user, are in the form of Service Level Indicators (SLIs). If for example the range of latencies a network can provide is 50ms-100ms, then this would be the range of values the end user should be able to request, it would be as low as 50ms or as high as 100ms or anything in between. The values of requested SLOs should always be in the range of values supported. The underlying networks must provide means to monitor and measure the performance of transport slices against the SLOs requested and verify that they are being met. Some SLOs can be measured directly through a collection of metrics and statistics from the network (commonly known as 'telemetry'), while others are deduced from measurable objectives and may require additional tools or mechanisms to measure their target values.

This document defines a minimal set of SLOs and later systems or standards could extend this set and define more SLOs. For example, we included Guaranteed bandwidth which is the minimum requested bandwidth for the transport slice. The later standard might define other SLOs related to bandwidth if needed. Accordingly, SLOs can be categorized in to 'Directly Measurable Objectives' or 'Indirectly Measurable Objectives' as follows: Some of the 'Directly Measurable Objectives' are: Guaranteed Minimum Bandwidth Guaranteed Maximum Latency Maximum permissible delay variation Maximum permissible packet loss rate Availability Other objectives could be specified Some of the 'Indirectly Measurable Objectives' are: Security others objectives such as geographical restrictions, maximum occupancy level, etc. could be specified The definition of these objectives are as follows: Guaranteed Minimum Bandwidth: Minimum guaranteed bandwidth between two endpoints at any time. The bandwidth is measured in data rate units of bits per second and is measured unidirectionally. Guaranteed Maximum Latency: Upper bound of network latency when transmitting between two endpoints. The latency is measured in terms of network characteristics (excluding application-level latency). and discuss round trip times and one-way metrics, respectively. Maximum permissible delay variation: Packet delay variation (PDV) as defined by , is measured by the difference in the one-way delay between sequential packets in a flow. Minimizing variations in the delay is important for real-time applications. Maximum permissible packet loss rate: is defined by the ratio of packets dropped to packets transmitted between two endpoints. See Availability: is defined as the ratio of uptime to total_time(uptime+downtime), where uptime is the time the transport slice is available in accordance with the SLOs associated with it. Security: This objective may request for encryption between two end-points explicitly to meet architecture recommendations as in or for compliance with . Other security requests may be made as specified in [draft-ietf-i2nsf-capability]. Note: Security violations are not directly observable and cannot be measured as quantifiable metrics. Still, the user of the transport slice should be able to request certain criteria for compliance and identify exceptions and unexpected traffic. For this purpose [i2nsf-nsf-monitoring-data-model] can be leveraged.

Additional objectives, such as certain geographical restrictions or well defined domains that a slice may transit may be necessary. Optionally, when the customer is traffic aware, other traffic specific characteristics may be provided. These include for example, MTU, traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a higher-level behavior to process traffic according to user-application (which may be realized using network functions). Maximal occupancy for a transport slice should be provided. Since it carries traffic for multiple flows between the two endpoints, the objectives should also say if they are for the entire connection, group of flows or on per flow basis. Maximal occupancy should specify the scale of the flows (i.e. maximum number of accommodatable flows) and optionally a maximum number of countable resource units, e.g IP or MAC addresses a slice might consume. With these objectives incorporated, a customer sees transport slice as a dedicated network for its exclusive use. Achieving this may require explicit request for different types of isolation in provider networks as described in . Additional description of slice attributes is covered in a broader context of 'Generic Network Slice Template' in .

The transport slice endpoints are the conceptual entities that perform any required conversion, or adaptation, and forwarding of the user traffic. The characteristics of the transport slice endpoints (TSE) are: They are conceptual points of connection of a network function, device or application to the transport slice They are identified in a request provided by the customer of transport slice (i.e. higher level operation systems) during the creation of the transport slice They are associated with a device, application and/or network function nodes. A non-exhaustive list of such nodes are routers, switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 , NAT64 , HTTP header enrichment functions, and TCP optimizers A TSE is identified by its associated node (its IP address, name , ID, etc.), a unique identifier and/or a unique name and other data. A non-exhaustive list of other data includes IP address (v4 or v6), VLAN, port, connectivity type (P2P, P2MP, MP2MP). TBD for more Note that the TSE is different from access points (AP) defined in as an AP is a logical identifier to identify the shared link between the customer and the operator where as TSE is an identifier of an endpoint. Also TSE is different from TE Link Termination Point (LTP) defined in as it is a conceptual point of connection of a TE node to one of the TE links on a TE node. The TSE is similar to the Termination Point (TP) defined in and can contain more attributes. TSE could be modeled by augmenting the TP model. There is another type of the endpoints called "Transport Slice Realization endpoints (TSREs)". These endpoints are allocated and assigned by the network controller during the realization of a transport slice and are technology-specific, i.e. they depend on the network technology used during the transport slice realization. They are identified by a node and some associated data. A non-exhaustive list of nodes containing TSREs are routers, switches, PON nodes, Wireless nodes and Optical devices. Note that there will be a mapping between TSE and TSRE on Transport Slice Controller (TSC). When TSC receives a request via its NBI to create a transport slice between multiple TSEs, it will send the request via its SBI to realize the transport slice. The TSRE will be notified by network controller during TS realization to enable mapping between TSREs and the TSEs. shows an example of a transport slice and its realization between multiple TSEs and TSREs.

| | | Transport slice realization | | between TSRE1 and TSRE2 | | | | <===================================================> | Transport slice between TSE1 and TSE2 with SLO1 Legend: DAN: Device, application and/or network function ]]>

The transport slices connection types can be point to point (P2P), point to multipoint (P2MP), multi-point to point (MP2P), or multi-point to multi-point (MP2MP). The transport slice connection type will requested by the higher level operation system.

Transport slice may follow a hierarchical relationship to provide a vertical structure to it. This is used for composing multi-layer slices in which each layer provides an abstraction, as well as an independent monitoring, performance, control and management of the resources. The vertical transport slice characteristic could be used in 2 forms: The Transport slice itself where it represents a hierarchy of abstracted transport slices. In this case, the realization will be done just once with a particular technology. Thus, the lowest transport slice in the hierarchy that can not be decomposed further will be one to one mapping to its instance of the realized transport slice. Each layer (physical, datalink, or IP) has its own set of resources that can be provided to the upper layer as a transport slice. Thus, transport slice at one layer is used by the layer above. This type of multi-layer vertical transport slice associates resources at different layers. For example, an IP transport slice would utilize one or more optical transport slice. In this case, the realization will be done for a particular technology at that particular layer. Thus, the lowest transport slice in this type of hierarchy that can not be decomposed further will be an instance of realized physical layer transport slice.

<=====TS11=======> <==============TS12===============> <====TS121====> <=====TS122======> .--. .--. .--. ( )--. ( )--. ( )--. .' ' .' ' .' ' [EU-x] ( Network-1 ) ( Network-2 ) ... ( Network-3 ) [EU-y] `-----------' `-----------' `----------' | | | | Operator-y | Operator-z | Legend: TSnnn: Level 3 vertical transport slice nnn TSnn: Level 2 vertical transport slice nn TSn: Level 1 transport Slice n ]]> shows the transport slice hierarchy. Slices TS11 and TS12 are composed together to form TS1 that is the top level transport slice definition, TS121 and TS122 collectively define TS12. The SLO for bandwidth guarantee will be shared and latency guarantee will be split into latency in networks 2 and 3. To emphasize the hierarchical structure, consider Network-2 and Network-3 are in the same administrative domain but use different transport technologies respectively. Then instead of presenting 2 transport slices, Operator-z can expose only one transport slice TS12 abstracting the underlying transport technology details. Note: The specification to connect TS121 and TS122 are similar to those connecting TS12 and TS11.

In contrast, horizontal transport slices enable the composition of multiple realized transport slices. Since transport slices are not necessarily a single encapsulation tunnel and may traverse through different data planes, each realized transport slice will require a stitching, interworking or mapping function. These stitching functions can be viewed as a type of intermediate network function endpoints. For instance in , TS11 and TS12 are horizontal transport slices. If we assume that TS11 is an L2 tunnel and TS12 is an SRV6 based path, then a 'Service type EP' (not shown in the figure) is needed for translation. Author's notes: This service type EP is a new type of transport slice specific service function. We may call it transport slice gateway.

A transport slice is a set of connections among various endpoints to form a logical network that meets the SLOs agreed upon.

x bps, Delay < y ms)/ [EP1m]-/___________________________/-------[EP2n] == == == == == == == == == == == == == == == == == == .--. .--. [EP11] ( )- . ( )- . [EP21] .' ' SLO .' ' [EP12] ( Network-1 ) ... ( Network-p ) [EP22] : `-----------' `-----------' : [EP1m] [EP2n] Legend SLOs in terms of attributes, e.g. BW, delay. EP: Endpoint B/W: Bandwidth ]]> illustrates a case where a transport slice provides connectivity between a set of endpoints pairs with specific characteristics for each SLO (e.g. guaranteed minimum bandwidth of x bps and guaranteed delay of less than y ms). The endpoints may be distributed in the underlay networks, and a transport slice can be deployed across multiple network domains. Also, the endpoints on the same transport slice may belong to the same address space. Transport slices involve both customer's and provider's views. A customer 'describes' its requirements in terms of connectivity with specific SLOs. Provider networks address those requirements through 'transport slice realization' (its implementation) using provider network specific technologies. A transport slice is requested from an entity (such as an orchestrator or a system-wide controller) performing broader service or application specific functions. The interface from such an entity should express the needed connectivity in a technology-agnostic way and donot need to recognize configurations based on the technologies (e.g. being more declarative than imperative). The request to instantiate a transport slice is only represented with some indicators such as SLOs based on which the underlying technologies are selected and managed. Often, in other SDOs the term sub-slice or slice-subnet comes up. Some of those are mapped to transport network requirements in the form of a transport slice. With in the scope of transport slices (w.r.t. the IP/MPLS based transport networks) there are no definitions for 'sub-slice' or 'slice subnets'. 'Transport slice' term universally represents SLO and connectivity requirements from the transport networks. Furthermore, the structure of transport slices may be layered vertically or composed horizontally, i.e. operationally, a transport slice maybe decomposed in two or more transport slices which are then independently realized and managed. This is further described in .

A transport slice and its realization involves the following stakeholders and it is relevant to define them for consistent terminology. A customer is a user of a transport slice. Customers may request monitoring of associated resources or specific changes. A user may either directly manage its service by interfacing with the transport slice controller or indirectly through an orchestrator. An orchestrator is an entity that composes different services, resource and network requirements. It interfaces with the transport slice controllers. It realizes a transport slice in the network, maintains and monitors the run-time state of resources and topologies associated with it. A well-defined interface is needed between different types of transport slice controllers and different types of orchestrators. A transport slice operator (or slice operator for short) manages one or more transport slices using the Transport Slice Controller(s). is a form of network infrastructure controller that offers network resources to TSC to realize a particular transport slice. These may be existing network controllers associated with one or more specific technologies that may be adapted to the function of realizing transport slices in a network.

The interworking and interoperability among the different stakeholders to provide common means of provisioning, operating and monitoring the transport slices is a mandatory requirement. The following communication interfaces are identified (see ). The TSC Northbound Interface is an interface between a higher level operation system, e.g. 'E2E network slice orchestrator' and the 'Transport slice controller'. It is a technology agnostic interface. Over this NBI, slice characteristics and other requirements can be communicated to TSC and the operational state of a transport slice may be requested. The TSC Southbound Interface is an interface between 'Transport slice controller (TSC)' and network controller(s). These interfaces are technology-specific and utilize many of the network models.

Realization of a Transport Slice is a mapping of underlying infrastructure with its definition. It is a technology specific entity that is created and maintained over its southbound interfaces. The Network controller(s) export the connectivity and resource mappings to the TSC. The network controller abstracts the details of underlying resources from the TSC. The realization can be achieved in the form of either physical or logical connectivity through VPNs, a variety of tunneling technologies such as Segment Routing, SFC, etc. Accordingly, endpoints may be realized as physical or logical service or network functions.

This section will describe the scope and use of term isolation.

This section explains the scope and use of term dedicated resource in the context of transport slices.

An end-to-end (E2E) network slice is a complete logical network that provides a service in its entirety with a specific assurance to the customer. A transport slice concerns with those assurance aspects only within the transport networks. Consider , where a network operator has an E2E network slice that traverses multiple technology-specific networks. Each of these networks might use any number of technologies, including but not limited to IP, MPLS, Fiber-Optics (e.g. WDM, DWDM), Passive Optical Networking (PON), Microwave, etc. Each of these networks includes multiple (physical or virtual) nodes and may also provide network functions beyond simply carrying of technology-specific protocol data units. The types of nodes used in any of these networks may include: Packet/frame processing nodes (e.g., Routers, Switches) Application servers Service Functions(e.g., Firewall, Loadbalancer) Radio Access Network (RAN) components Mobile Core components Microwave transceivers Optical repeaters etc. Each network may support different technologies and an E2E network slice is a combination of these networks. As an example: Network 1 might contain multiple 5G RAN nodes connected to a few Cell Site Gateways (CSG) routers. Network 2 might have one or more layer-3 routers and layer-2 switches which may run on top of an optical network. Network 3 might have a number of 5G RAN nodes connected to Passive Optical Network (PON) switches.

<-OS1-> <-TS1-> <-TS2-> <-OS2-> ... <-TSn-> <-OSm-> |------------------------------------------------------| | .--. .--. .--. | | ( )--. ( )--. ( )--. | | .' ' .' ' .' ' | [EU-x] | ( Network-1 ) ( Network-2 ) ... ( Network-p ) |[EU-y] | `-----------' `-----------' `----------' | | | | Operator-z | |------------------------------------------------------| Legend: E2E NS: End-to-end network slice TSn: Transport Slice n OSm: Other Slice m EU-x: End User-x EU-y: End User-y ]]> When operator-z creates a specific E2E network slice, it may create one or more of transport slices and other slices (application logic or other system functions). An independent E2E logical network (called E2E network slice) is created for a service (e.g. CCTV, autonomous driving, HD map, etc.) with a specific network SLOs, e.g. a secure connection with an E2E latency less than 5ms, from End User-x (EU-x) to End User-y (EU-y). EU-x maybe a 5G user equipment such as an infotainment unit in a car, CCTV, or a car for autonomous driving, etc. and EU-y in 5G is 5G application server, IMS, etc. In , "E2E NS" is that logical network with requested SLO between EU-x to EU-y and is associated with a customer and a specific service type.

Not applicable in this memo.

This memo includes no request to IANA.

The entire TEAS NS design team and everyone participating in those discussion has contributed to this draft. Particularly, Eric Gray, Xufeng Liu, Jie Dong, and Jari Arkko for a thorough review among other contributions.