TEAS Working Group T. Saad Internet-Draft V. Beeram Intended status: Standards Track Juniper Networks Expires: May 3, 2021 October 30, 2020 Realizing Network Slices in IP/MPLS Networks draft-bestbar-teas-ns-packet-00 Abstract Network slicing provides the ability to partition a physical network into multiple isolated logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Network slices need to operate in parallel with varying degrees of isolation while providing slice elasticity in terms of network resource allocation. The Differentiated Service (Diffserv) model allows for carrying multiple services on top of a single physical network by relying on compliant nodes to apply specific forwarding treatments on to packets that carry the respective Diffserv code point. This document proposes a solution based on the Diffserv model to realize network slicing in IP/MPLS networks. The proposed solution is agnostic to the path control technology used in the network slicing domain and allows service differentiation of traffic within a given network slice. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Saad & Beeram Expires May 3, 2021 [Page 1] Internet-Draft IP/MPLS Network Slicing October 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Network Resource Slicing Membership . . . . . . . . . . . . . 5 2.1. Dedicated Network Resources . . . . . . . . . . . . . . . 6 2.2. Shared Network Resources . . . . . . . . . . . . . . . . 6 3. Path Selection . . . . . . . . . . . . . . . . . . . . . . . 6 4. Approaches to Network Resource Slicing . . . . . . . . . . . 7 4.1. Data Plane Network Resource Slicing . . . . . . . . . . . 7 4.2. Control Plane Network Resource Slicing . . . . . . . . . 8 4.3. Data and Control Plane Network Resource Slicing . . . . . 10 5. Network Slice Instantiation . . . . . . . . . . . . . . . . . 11 5.1. Slice Intent . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Slice Per-Hop Definition . . . . . . . . . . . . . . . . 12 5.2.1. Slice Data Plane Selector . . . . . . . . . . . . . . 13 5.2.2. Slice Network Resource Reservation . . . . . . . . . 17 5.2.3. Slice Per-Hop Behavior . . . . . . . . . . . . . . . 18 5.2.4. Slice Topology Membership . . . . . . . . . . . . . . 19 5.3. Network Slice Boundary . . . . . . . . . . . . . . . . . 19 5.3.1. Network Slice Edge Nodes . . . . . . . . . . . . . . 19 5.3.2. Network Slice Interior Nodes . . . . . . . . . . . . 20 5.3.3. Network Slice Incapable Nodes . . . . . . . . . . . . 20 5.3.4. Combining Network Resource Slicing Approaches . . . . 21 5.4. Slice Traffic Steering . . . . . . . . . . . . . . . . . 22 6. Control Plane Extensions . . . . . . . . . . . . . . . . . . 22 7. Applicability to Path Control Technologies . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Saad & Beeram Expires May 3, 2021 [Page 2] Internet-Draft IP/MPLS Network Slicing October 2020 1. Introduction Network slicing allows a Service Provider, or a network operator to create independent and isolated logical networks on top of a common or shared physical network infrastructure. Such network slices can be offered to customers or used internally by the Service Provider to facilitate or enhance their service offerings. A Service Provider can also use network slicing to structure and organize the elements of its infrastructure. For example, certain network resource capabilities and functionality can be grouped together providing a self-contained unit (network slice) of varying size and complexity. When logical networks representing network slices are realized on top of a shared physical network, it is important to steer traffic on the specific network resources allocated for the network slice. In packet networks, the packets that traverse a specific network slice MAY be identified by specific field(s) carried within the packet. A network slice boundary node will usually mark or populate the respective field(s) in packets that enter a network slice to allow interior slice nodes to identity those packets and apply the specific Per Hop Behavior (PHB) that is associated with the slice and that defines the scheduling treatment and, in some cases, the packet drop probability. In a Differentiated Service (Diffserv) domain [RFC2475], packets requiring the same forwarding treatment are classified and marked with a Class Selector (CS) at domain ingress nodes. At transit nodes, the CS field inside the packet is inspected to determine the specific forwarding treatment to be applied before the packet is forwarded further. Multiple network slices can be realized on top of a shared physical infrastructure network. A single network slice may also support multiple forwarding treatments or Diffserv classes that can be carried over the same logical network slice. This document proposes a solution that allows proper placement of paths and respective treatment of traffic traversing network slice resource(s) in IP/MPLS networks. The network slice traffic may be marked at slice boundary nodes with a Slice Selector (SS) to allow routers to apply a specific forwarding treatment that guarantees the slice Service Level Agreements (SLAs). Network slice traffic may further carry a Diffserv CS to allow differentiation of forwarding treatments for packets forwarded over the same network slice network resources. For example, when using MPLS as a dataplane, it is possible to identify packets belonging to the same slice by carrying a global MPLS Slice Selector Label (SSL) in the MPLS label stack that identifies the slice in each packet. Additional Diffserv Saad & Beeram Expires May 3, 2021 [Page 3] Internet-Draft IP/MPLS Network Slicing October 2020 classification may be indicated in the MPLS Traffic Class (TC) bits of the SSL to allow further differentiation of traffic treatments of traffic traversing the same slice network resources. 1.1. Terminology The reader is expected to be familiar with the terminology specified in [I-D.nsdt-teas-ietf-network-slice-definition] and [I-D.draft-nsdt-teas-ns-framework-04]. The following terminology is used in the document: Slicing capable node: a node that supports one of the network slicing approaches described in this document. Slicing incapable node: a node that does not support one of the network slicing approaches described in this document. Slice traffic: traffic that is forwarded over network resource(s) associated with a specific network slice. Slice path: a path that is setup over network resource(s) associated with a specific network slice. Slice-aware TE: a mechanism for TE path selection that takes into account the available network resource(s) associated with a specific network slice. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Acronyms and Abbreviations CS: Class Selector SS: Slice Selector Slice-PHD: Slice Per-Hop Definition as described in Section 5.2 Slice-PHB: Slice Per-Hop Behavior as described in Section 5.2.3 Saad & Beeram Expires May 3, 2021 [Page 4] Internet-Draft IP/MPLS Network Slicing October 2020 SSL: Slice Selector Label as described in section Section 5.2.1 SSLI: Slice Selector Label Indicator SLA: Service Level Agreement SLO: Service Level Objective Diffserv: Differentiated Services DS-TE: Differentiated Services Traffic Engineering MPLS: Multiprotocol Label Switching LSP: Label Switched Path LSR: Label Switching Router LER: Label Edge Router RSVP: Resource Reservation Protocol TE: Traffic Engineering SR: Segment Routing 1.3. Scope The definition of Network Slice for use within the IETF and the characteristics of IETF Network Slice are specified in [I-D.draft-nsdt-teas-transport-slice-definition-04]. A framework for reusing IETF VPN and traffic-engineering technologies to realize IETF Network Slices is discussed in [I-D.draft-nsdt-teas-ns-framework-04]. This document provides a solution that addresses the network slice requirements in packet networks from a device and network resource level perspective based on DiffServ principles. 2. Network Resource Slicing Membership A network slice can span multiple parts of an IP/MPLS network (e.g. all or specific network resources in the access, aggregation, or core network), and can stretch across multiple operator domains. A network slice may include all or a sub-set of the physical nodes and links of an IP/MPLS network, and it may be comprised of dedicated and/or shared network resources (e.g. in terms of processing power, storage, and bandwidth) and may have varying degrees of isolation from the other network slices. Saad & Beeram Expires May 3, 2021 [Page 5] Internet-Draft IP/MPLS Network Slicing October 2020 2.1. Dedicated Network Resources Physical network resources may be fully dedicated to a specific network slice. For example, this allows traffic belonging to a slice to traverse the dedicated resources without network resource contention from traffic of another network slice. Dedicated network resource slicing allows for simple partitioning of the physical network resources into multiple isolated network slices without the need to distinguish packets traversing the dedicated network resources since only one slice traffic can use them. 2.2. Shared Network Resources To optimize network utilization, sharing of the physical network resources may be desirable. In such case, the same physical network resource capacity is partitioned among logical network slice(s). Shared network resources can be partitioned in the dataplane (for example by applying hardware policers and shapers), partitioned in the control plane by providing a logical representation of the physical link that has a subset of the network resources available to it. 3. Path Selection Path selection in a network can be network state dependent, or network state independent as described in Section 5 of [I-D.draft-dt-teas-rfc3272bis-11]. The latter is the choice commonly used by IGP(s) when selecting a best path to a destination prefix, while the former is used by ingress TE routers, or Path Computation Engines (PCEs) when optimizing the placement of a flow based on the current network resource utilization. For example, when steering traffic on a delay optimized path, the IGP can use its Link State Database (LSDB)'s view of the network topology to compute a path optimizing for the delay metric of each link in the network resulting in a cumulative lowest delay path. When path selection is network state dependent, the path computation can leverage Traffic Engineering mechanisms (e.g. as defined in [RFC2702]) to compute feasible paths taking into account the incoming traffic demand rate and current state of network. This allows avoiding overly utilized link(s), and reduces the chance of congestion on traversed link(s). To enable TE path placement, the link state is advertised with current reservation(s), thereby reflecting the available bandwidth on each link. Such link reservations may be maintained centrally on a network wide network resource manager, or distributed on devices (as Saad & Beeram Expires May 3, 2021 [Page 6] Internet-Draft IP/MPLS Network Slicing October 2020 usually done with RSVP). TE extensions exist today to allow IGPs (e.g. [RFC3630] and [RFC5305]), and BGP-LS [RFC7752] to advertise such link state reservations. When network resource reservations are also slice aware, the link state can carry per network slice state (e.g. per network slice link reservable bandwidth). This allows path computation to take into account the specific network resources available for a network slice when determining the path for a specific flow. In this case, we refer to the process of path placement and path provisioning has Slice-aware Traffic Engineering (Slice-aware TE). 4. Approaches to Network Resource Slicing The partitioning of the shared network resources amongst multiple slices can be achieved in: a) control plane only, or b) data plane only, or c) both control and data planes. 4.1. Data Plane Network Resource Slicing The physical network resources can be partitioned on network devices by applying a Per-Hop forwarding Behavior (PHB) onto packets that traverse the network device(s). In the Diffserv model, a Class Selector (CS) is carried in the packet and is used by transit node(s) to apply the PHB that determines the scheduling treatment and, in some cases, drop probability for packet(s). When dataplane network resource slicing is required, packets need to be forwarded on the specific slice network resources and be applied a specific forwarding treatment that is dictated by the Slice Per-Hop Definition (Slice-PHD) (refer to Section 5.2 below) consumed by each device. A slice Selector (SS) MAY be carried in each slice packet to identify the slice that it belongs to. The ingress node of a slice domain, in addition to marking packets with a Diffserv CS, MAY also add a SS to each slice packet. The transit node(s) within a slice domain MAY use the SS to associate packets with a slice and to determine the Slice Per Hop Behavior (Slice-PHB) that is applied to the packet (refer to Section 5.2.3 for further details). The CS MAY be used to apply a Diffserv PHB on to the packet to allow differentiation of traffic treatment within the same network slice. Saad & Beeram Expires May 3, 2021 [Page 7] Internet-Draft IP/MPLS Network Slicing October 2020 When dataplane only network resource slicing is desirable, routers may rely on a network state independent view of the topology to determine the best path(s) to reach destination(s). In this case, the best path selection dictates the forwarding path of packets to the destination. The SS that is carried in each packet determines the specific Slice-PHB treatment for each slice along the selected path. For example, Segment-Routing flexible algorithm may be deployed in a network to steer packet(s) on the lowest cumulative delay. A Slice- PHD may be used to enable the link(s) along the least latency path for dataplane slicing. Network slice packet(s) forwarded along the lowest delay path can carry the SS when forwarded along the least latency path. Transit nodes along the lowest delay path can inspect the SS and Diffserv CS to determine the Slice-PHB and the Diffserv class PHB to apply to packets before they are forwarded downstream. 4.2. Control Plane Network Resource Slicing The physical network resources in the network can be logically partitioned by having a representation of network resources appear in a virtual topology. The virtual topology can contain all or a subset of the physical network resource(s). The logical network resources that appear in the virtual topology can reflect a part, whole, or in- excess of the physical network resource capacity (when oversubscription is desirable). For example, a physical link bandwidth can be divided into fractions, each belonging to a slice. Each fraction of the physical link bandwidth can be represented as a logical link in a virtual topology that is used when determining path(s) in a specific slice. The per slice virtual network can be used by routing protocol(s), or by the ingress/PCE when computing slice aware path(s). To perform network state dependent path computation in each slice, the resource reservation on each link needs to be slice aware (Slice- aware TE). Depending on the network Slice-PHD, a physical link may be part of one or more slice(s). Each such link may be sliced 'n' ways so that each slice will have certain network resources associated with it. The per slice network resource availability on link(s) are updated (and may eventually be advertised in the network) when new path(s) are placed in the network. The per slice resource reservation, in this case, can be maintained on each device(s) or be centralized on a resource reservation manager that holds link reservation state(s) on links in the network. A number of network slice(s) can share the available network resource(s) allocated to each network slice amongst a group. In this case, a node can update the reservable bandwidth for each slice to Saad & Beeram Expires May 3, 2021 [Page 8] Internet-Draft IP/MPLS Network Slicing October 2020 take into consideration the available bandwidth from other slice(s) in the same group. For illustration purposes, the diagram below represents bandwidth isolation or sharing amongst a group of network slice(s). In Figure 1a, the network slices: Slice1, Slice2, Slice3 and Slice4 are not sharing any bandwidths between each other. In Figure 1b, the network slices: Slice1 and Slice2 can share the available bandwidth portion allocated to each amongst them. Similarly, Slice3 and Slice4 can share amongst themselves any available bandwidth allocated to them, but they cannot share available bandwidth allocated to Slice1 or Slice2. In both cases, the Max Reservable Bandwidth may exceed the actual physical link resource capacity to allow for over subscription. Saad & Beeram Expires May 3, 2021 [Page 9] Internet-Draft IP/MPLS Network Slicing October 2020 I-----------------------------I I-----------------------------I <--Slice1-> I I-----------------I I I---------I I I <-Slice1-> I I I I I I I-------I I I I---------I I I I I I I I I I I-------I I I <-----Slice2------> I I I I I-----------------I I I <-Slice2-> I I I I I I I---------I I I I-----------------I I I I I I I I I I I---------I I I <---Slice3----> I I I I I-------------I I I Slice1 + Slice2 I I I I I I-----------------I I I-------------I I I I I I I I <---Slice4----> I I-----------------I I I-------------I I I <-Slice3-> I I I I I I I-------I I I I-------------I I I I I I I I I I I-------I I I I Slice1+Slice2+Slice3+Slice4 I I I I I I I <-Slice4-> I I I-----------------------------I I I---------I I I <--Max Reservable Bandwidth--> I I I I I I I---------I I I I I I I Slice3 + Slice4 I I I-----------------I I I Slice1+Slice2+Slice3+Slice4 I I I I-----------------------------I <--Max Reservable Bandwidth--> (a) (b) Figure 1: (a) bandwidth allocation(s) when no sharing between slice(s), (b) bandwidth allocation(s) when sharing between slice(s) of the same group. 4.3. Data and Control Plane Network Resource Slicing In order to support strict guarantees and hard isolation between network slice(s), the network resource(s) can be partitioned in both the control plane and data plane. The control plane partitioning allows the creation of customized topologies per slice that router(s) or a Path Computation Engine Saad & Beeram Expires May 3, 2021 [Page 10] Internet-Draft IP/MPLS Network Slicing October 2020 (PCE) can use to determine optimal path placement for specific demand flows (Slice-aware TE). The data plane partitioning protects slice traffic from network resource contention that occurs due to bursts in traffic from different slice(s) traversing the same shared network resource. 5. Network Slice Instantiation A network slice can span multiple technologies and multiple administrative domains. Depending on the network slice consumer's requirements, a network slice can be isolated from other network slices in terms of data, control or management planes. The instantiation of a network slice may necessitate a network Slice Manager or service orchestrator that accepts a Service Layer Slice Intent as input and is translates it to a network wide device specific Slice-PHD as shown in Figure 2. The Diffserv procedures may be employed within the same network slice to realize multiple classes of traffic belonging to the same slice. +----------+ | Slice | | Manager | +----------+ | Network Slice | Service Layer ========================================= | Network Slice | Device/Resource Layer | | Slice Per-Hop Definition | Distribution XXXX|XXXXXX XX /| XX XX / | XX XX / | XX XXXX v v XXXX XXX Ingress All XXX XXX node(s) nodes XXX XXX XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX <----------- Path Control ---------> RSVP-TE/SR-Policy /SR-FlexAlgo .. Figure 2: Network Slice instantiation model. Saad & Beeram Expires May 3, 2021 [Page 11] Internet-Draft IP/MPLS Network Slicing October 2020 5.1. Slice Intent A network slicing solution may be realized using a network slice service Layer, and a device/resource Layer. The service layer can be managed by a service orchestrator that exposes a north bound interface to slice consumers that can be used to convey the intent. Depending on the use cases and type of services for which the end-to- end slice is instantiated, multiple levels of control may be exposed to the tenants by a slice provider. For example, network slicing provider may allow for a connectivity and data processing that is tailored to specific customer requirements. At the service layer, the consumer of a network slice expresses their intent for a particular network slice by specifying requirements rather than how a slice is realized. The requirements for a network slice can vary and can be expressed in terms of connectivity needs between end-points (point-to-point, point-to- multipoint or multipoint-to-multipoint) with customizable network capabilities that may include data speed, quality, latency, reliability, security, and services (refer to [I-D.draft-nsdt-teas-transport-slice-definition-04] for more details). These capabilities are always provided based on a Service Level Agreement (SLA) between the network slice consumer and the provider. The network slice orchestrator is responsible for translating the network slice consumer intent into a Slice-PHD that can be instantiated by network elements at Device/Resource layer so that the network slice consumer requirements in terms of network characteristics are met. 5.2. Slice Per-Hop Definition The high-level slice intent is consumed to produce a set of features and attributes that can be provisioned on network elements. The device level Slice-PHD includes attributes related to: o Dataplane specific properties: This includes the SS, any firewall rules or flow-spec filters, and QoS profiles associated with the slice and any classes within it. o Control plane specific properties: This includes guaranteed bandwidth, any network resource sharing amongst slice(s), and slice reservation preference to prioritize any reservations of a specific slice over others. Saad & Beeram Expires May 3, 2021 [Page 12] Internet-Draft IP/MPLS Network Slicing October 2020 o Membership policies: This defines policies that dictate node/link/ function network resource topology association for a specific slice. There is a desire for flexibility in implementing network slices to support the services across networks consisting of products from multiple vendors, and may be grouped into disparate domains and using various path control technologies and tunnel types. It is expected that having a standardized data model for a Slice-PHD will facilitate the instantiation of a network slice on a network slicing capable node. It is also possible to deliver a Slice-PHD to network devices using several mechanisms, including using protocols such as NETCONF or RESTCONF, or exchanging it using a suitable routing protocol that network devices participate in (such as IGP(s) or BGP). 5.2.1. Slice Data Plane Selector A router MUST be able to identify a packet as belonging to a network slice before it can apply the proper forwarding treatment or PHB associated with the slice. One or more fields within the packet MAY be selected as a SS to do this. Per Slice Forwarding Address: One approach to distinguish packets targeted to a destination but belong to different slices is to assign multiple forwarding addresses (or multiple MPLS label bindings in the case of MPLS network) to the same destination - one for each slice the destination can be reached over. For example, when realizing a network slice over an IP dataplane, the same destination can be assigned multiple IP addresses (or multiple SRv6 locators in the case of SRv6 network) to enable steering of traffic to the same destination over multiple network slices. Similarly, when an MPLS dataplane is used, [RFC3031] states in Section 2.1 that: 'Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service'. In such case, the same destination can be assigned multiple MPLS label bindings corresponding to an LSP that traverses network resources of a specific slice towards the destination. The specific slice forwarding address (or MPLS forwarding label) can be carried in the packet belonging to a network slice to allow (IP or MPLS) routers along the path to identify the packets and apply the respective per Slice-PHB and forwarding treatment. This Saad & Beeram Expires May 3, 2021 [Page 13] Internet-Draft IP/MPLS Network Slicing October 2020 approach requires maintaining per slice state for each destination in the network in both the control and data plane and on each router in the network. For example, consider a network slicing provider with a network composed of 'N' nodes, each with 'K' adjacencies to its neighbors. Assuming a node is reachable in as many as 'M' network slice(s), the node will have to assign and advertise reachability for 'N' unique forwarding addresses, or MPLS forwarding labels corresponding to the 'N' slices. Similarly, each node will have to assign a unique forwarding address (or MPLS forwarding label) for each of its 'K' adjacencies to enable strict steering over each. Consequently, the control plane at any node in the network will need to store as many as (N+K)*M states. In addition, a node will have to store and program (N+K)*M forwarding addresses or labels entries in its Forwarding Information Base (FIB) to realize this. Therefore, as 'N', 'K', and 'M' parameters increase, this approach will have scalability challenges both in the control and data planes. Per Slice Selector: A Slice Selector (SS) field can be carried in each packet to identify the packet belonging to a specific slice, independent of the forwarding address or MPLS forwarding label that is bound to the destination. Routers within the network slice domain can use the forwarding address (or MPLS forwarding label) to determine the forwarding path, and use the SS field in the packet to determine the specific Slice-PHB that gets applied on the packet. This approach allows better scale since it relies on a single forwarding address or MPLS label binding to be used independent of the number of network slices required along the path. In this case, the additional SS field will need to be carried, and maintained in each packet while it traverses the slice domain. The SS can be carried in one of multiple fields within the packet, depending on the dataplane type used. For example in MPLS networks, the SS can be represented as a global MPLS label that is carried in the packet's MPLS label stack. All packets that belong to the same slice MAY carry the same SS label in the MPLS label stack. It is possible, as well, to have multiple SS label(s) point to the same Slice-PHB. The MPLS SS Label (SSL) may appear in several positions in the MPLS label stack. For example, the MPLS SSL can be maintained at the top of the label stack while the packet is forwarded along the MPLS path. In this case, the forwarding at each hop is determined by the forwarding label that resides below the SSL. Figure 3 Saad & Beeram Expires May 3, 2021 [Page 14] Internet-Draft IP/MPLS Network Slicing October 2020 shows an example where the SSL appears at the top of MPLS label stack in a packet. PE1 is a network Slice edge node that receives the packet that needs to be steered over a slice specific MPLS Path. PE1 computes the SR Path composed of the Label Segment- List={9012, 9023}. It imposes a SSL=1001 corresponding to Slice- ID=1001 followed by the SR Path Segment-List. At P1, the top label sets the context of the packet to Slice-ID=1001. The forwarding of the packet is determined by inspecting the forwarding label (below the SSL) within the context of SSL. SR Adj-SID: SSL: 1001 9012: P1-P2 9023: P2-PE2 /-----\ /-----\ /-----\ /-----\ | PE1 | ----- | P1 | ------ | P2 |------ | PE2 | \-----/ \-----/ \-----/ \-----/ In packet: +------+ +------+ +------+ +------+ | IP | | 1001 | | 1001 | | 1001 | +------+ +------+ +------+ +------+ | Pay- | | 9012 | | 9023 | | IP | | Load | +------+ +------+ +------+ +----- + | 9023 | | IP | | Pay- | +------+ +------+ | Load | | IP | | Pay- | +------+ +------+ | Load | | Pay- | +------+ | Load | +------+ Figure 3: SSL at top of label stack. The SSL can also reside at the bottom of the label stack. For example, the VPN service label may also be used as an SSL which allows steering of traffic towards one or more egress PEs over the same network slice. In such cases, one or more service labels MAY be mapped to the same slice. The same VPN label may also be allocated on all Egress PEs so it can serve as a single SSL for a specific network slice. Alternatively, a range of SSL (VPN labels) may be mapped to a single network slice to allow carrying multiple VPN(s) over the same network slice as shown in Figure 4. Saad & Beeram Expires May 3, 2021 [Page 15] Internet-Draft IP/MPLS Network Slicing October 2020 SR Adj-SID: SSL (VPN) on PE2: 1001 9012: P1-P2 9023: P2-PE2 /-----\ /-----\ /-----\ /-----\ | PE1 | ----- | P1 | ------ | P2 |------ | PE2 | \-----/ \-----/ \-----/ \-----/ In packet: +------+ +------+ +------+ +------+ | IP | | 9012 | | 9023 | | 1001 | +------+ +------+ +------+ +------+ | Pay- | | 9023 | | 1001 | | IP | | Load | +------+ +------+ +------+ +----- + | 1001 | | IP | | Pay- | +------+ +------+ | Load | | IP | | Pay- | +------+ +------+ | Load | | Pay- | +------+ | Load | +------+ Figure 4: SSL or VPN label at bottom of label stack. In some cases, the position of the SSL may not be at a fixed place in the MPLS label header. In this case, transit routers cannot expect the SSL at a fixed place in the MPLS label stack. This can be addressed by introducing a new Special Purpose Label from the label reserved space called a Slice Selector Label Indicator (SSLI). The slice network ingress boundary node, in this case, will need to impose at least two additional MPLS labels (SSLI + SSL) to identify the slice that the packets belong to as shown in Figure 5. Saad & Beeram Expires May 3, 2021 [Page 16] Internet-Draft IP/MPLS Network Slicing October 2020 SR Adj-SID: SSLI/SSL: SSLI/1001 9012: P1-P2 9023: P2-PE2 /-----\ /-----\ /-----\ /-----\ | PE1 | ----- | P1 | ------ | P2 |------ | PE2 | \-----/ \-----/ \-----/ \-----/ In packet: +------+ +------+ +------+ +------+ | IP | | 9012 | | 9023 | | SSLI | +------+ +------+ +------+ +------+ | Pay- | | 9023 | | SSLI | | 1001 | | Load | +------+ +------+ +------+ +------+ | SSLI | | 1001 | | IP | +------+ +------+ +------+ | 1001 | | IP | | Pay- | +------+ +------+ | Load | | IP | | Pay- | +------+ +------+ | Load | | Pay- | +------+ | Load | +------+ Figure 5: SSLI and bottom SSL at bottom of label stack. When the slice is realized over an IP dataplane, the SSL can be encoded in the IP header. For example, the SSL can be encoded in portion of the IPv6 Flow Label field as described in [I-D.draft-filsfils-spring-srv6-stateless-slice-id-01]. 5.2.2. Slice Network Resource Reservation Bandwidth and network resource allocation strategies for network slicing are essential to achieve optimal placement of paths within the network while still meeting the target SLOs. Resource reservation allows for the managing of available bandwidth and for prioritization of existing allocations to enable preference based preemption when contention on a specific network resource arises. Sharing of a network resource's available bandwidth amongst a group of slices may also be desirable. For example, a slice may not always be using all of its reservable bandwidth; this allows other slices in the same group to use the available bandwidth resources. Saad & Beeram Expires May 3, 2021 [Page 17] Internet-Draft IP/MPLS Network Slicing October 2020 Congestion on shared network resources may result from sub-optimal placement of paths in different network slices. When this occurs, preemption of some slice specific paths may be desirable to alleviate congestion. A preference based allocation scheme enables prioritization of slice paths that can be preempted. Since network characteristics and its state can change over time, the per slice topology and its state also needs to be propagated in the network to enable ingress TE routers or Path Computation Engine (PCEs) to perform accurate path placement based on the current state of the network slice. 5.2.3. Slice Per-Hop Behavior In Diffserv terminology, the forwarding behavior that is assigned to a specific class is called a Per-Hop Behavior (PHB). The PHB defines the forwarding precedence that a marked packet with a specific CS receives in relation to other traffic on the Diffserv-aware network. A Slice Per Hop Behavior (Slice-PHB) is the externally observable forwarding behavior applied to a specific packet belonging to a slice. The goal of a Slice-PHB is to provide a specified amount of network resources for traffic belonging to a specific slice. A single network slice may also support multiple forwarding treatments or services that can be carried over the same logical network slice. The slice traffic may be identified at slice boundary nodes by carrying a SS to allow router(s) to apply a specific forwarding treatment that guarantee the slice SLA(s). With Differentiated Services (Diffserv) it is possible to carry multiple service(s) over a single converged network. Packets requiring the same forwarding treatment are marked with a Class Selector (CS) at domain ingress nodes. Up to eight classes or Behavior Aggregated (BAs) may be supported for a given Forwarding Equivalence Class (FEC) [RFC2475]. To support multiple services over the same network slice, a slice packet MAY also carry a Diffserv CS to identify the specific Diffserv forwarding treatment to be applied on the different service traffic belonging to the same slice. At transit nodes, the CS field carried inside the packets are used to determine the specific Per Hop Behavior (PHB) that determines the forwarding and scheduling treatment before packets are forwarded, and in some cases, drop probability for each packet. Saad & Beeram Expires May 3, 2021 [Page 18] Internet-Draft IP/MPLS Network Slicing October 2020 5.2.4. Slice Topology Membership A network slice is built on top of a customized topology that may include the full or subset of the physical network topology. The network slice topology could also span multiple administrative domains and/or multiple dataplane technologies. The network slice topology can overlap or share a subset of links with another network slice topology. A number of policies or topology filters can be defined to limit the specific topology elements that belong to a network slice. The Slice-PHD membership can carry the topology filtering policies. For example, such policies can leverage Resource Affinities as defined in [RFC2702] to include or exclude certain link(s) in a specific network slice topology. The Slice-PHD may also include a reference to a predefined topology (e.g. derived from from a Flexible Algorithm Definition (FAD) as defined in [I-D.ietf-lsr-flex-algo], or Multi-Topology ID as defined [RFC4915]. Alternatively, the topology filtering policies can specify specific link properties (such as delay, bandwidth capacity, security) to filter/include such link(s) in a network slice topology. 5.3. Network Slice Boundary A network slice originates at the boundary of a network slice provider at edge node(s). Traffic that is steered over the network slice may traverse network slicing capable interior nodes, as well as, network slicing incapable interior nodes. The network slice may compose of one or more administrative domain(s); for example, an organization's intranet or an ISP. The administration of the network is responsible for ensuring that adequate network resources are provisioned and/or reserved to support the SLAs offered by the network end-to-end. 5.3.1. Network Slice Edge Nodes Network slicing edge nodes sit at the boundary of a network slice provider network and receive traffic that requires steering over network resources specific to a network slice. The slice edge nodes are responsible for identifying network slice specific traffic flows by possibly inspecting multiple fields from inbound packets (e.g. implementations may inspect IP traffic's network 5-tuple in the IP and transport protocol headers) to decide on which network slice it can be forwarded. Saad & Beeram Expires May 3, 2021 [Page 19] Internet-Draft IP/MPLS Network Slicing October 2020 Network slice ingress nodes may condition the inbound traffic at network boundaries in accordance with the requirements or rules of each service's SLA(s). The requirements and rules for network slice services are set using mechanisms which are outside the scope of this document. When dataplane slicing is required, the slice boundary nodes are responsible for adding a suitable SS onto packets that belong to specific network slices. In addition, edge nodes MAY mark the corresponding Diffserv CS to differentiate between different types of traffic carried over the same network slice. 5.3.2. Network Slice Interior Nodes A network slice interior node receives slice traffic and MAY be able to identify the packets belonging to a specific network slice by inspecting the SS field carried inside each packet, or by inspecting other fields within the packet that may identify specific flows belonging to a specific network slice. For example when dataplane slicing is required, interior nodes can use the SS carried within the packet to apply the corresponding Slice-PHB forwarding behavior. Nodes within the network slice provider network may also inspect the Diffserv CS within each packet to apply a per Diffserv class PHB within the network slice, and allow differentiation of forwarding treatments for packets forwarded over the same network slice network resources. 5.3.3. Network Slice Incapable Nodes Packets that belong to a network slice may need to traverse nodes that are incapable of network slicing. In this case, several options are possible to allow the network slice traffic to continue to be forwarded over such devices and be able to resume the network slice forwarding treatment once the traffic reaches devices that are capable of network slicing. When dataplane network slicing is desirable, packets carry a SS to allow slice interior nodes to identify them. To enable end-to-end network slicing, the SS MUST be maintained in the packets as they traverse devices within the network - including devices incapable of network slicing. For example, when the SS is an MPLS label at the bottom of the MPLS label stack, packets can traverse over devices that are incapable of network slicing without any further considerations. On the other hand, when the SSL is at the top of the MPLS label stack, packets can be bypassed (or tunneled) over the network slicing incapable devices Saad & Beeram Expires May 3, 2021 [Page 20] Internet-Draft IP/MPLS Network Slicing October 2020 towards the next device that supports network slicing as shown in Figure 6. SR Node-SID: SSL: 1001 @@@: network slicing enforced 1601: P1 ...: network slicing not enforced 1602: P2 1603: P3 1604: P4 1605: P5 @@@@@@@@@@@@@@ ........................ . /-----\ /-----\ /-----\ . | P1 | ----- | P2 | ----- | P3 | . \-----/ \-----/ \-----/ . | @@@@@@@@@@ | /-----\ /-----\ | P4 | ------ | P5 | \-----/ \-----/ +------+ +------+ +------+ | 1001 | | 1604 | | 1001 | +------+ +------+ +------+ | 1605 | | 1001 | | IP | +------+ +------+ +------+ | IP | | 1605 | | Pay- | +------+ +------+ | Load | | Pay- | | IP | +------+ | Load | +------+ +----- + | Pay- | | Load | +------+ Figure 6: Extending network slice over slicing incapable device(s). 5.3.4. Combining Network Resource Slicing Approaches It is possible to employ a combination of the approaches that were discussed in Section 4 to realize an end-to-end network slice. For example, data and control plane network resource slicing can be employed in parts of a network, while control plane only slicing can be employed in the other parts of the network. The Slice-aware path selection in such case can take into account the per slice available network resources. Packets carry a SS within them so the corresponding Slice-PHB can be enforced on the parts of the network that realize dataplane network resource slicing. The SS can be Saad & Beeram Expires May 3, 2021 [Page 21] Internet-Draft IP/MPLS Network Slicing October 2020 maintained while traffic traverses nodes that do not enforce any dataplane slicing, and so slice PHB enforcement can resume once traffic traverses slicing capable nodes. 5.4. Slice Traffic Steering The usual techniques to steer traffic onto paths can be applicable when steering traffic over paths established in a specific network slice. For example, one or more (layer-2 or layer-3) VPN services can be directly mapped to paths established in a specific network slice. In this case, traffic that arrives on the Provider Edge (PE) router over external interface(s) can be directly mapped to a specific network slice path. External interface(s) can be further partitioned (e.g. using VLANs) to allow mapping one or more VLANs to specific network slice paths. Another option is steer specific destinations directly over specific network slices. This allows traffic arriving on any external interface and targeted to such destinations to be directly steered over the slice transport paths. A third option that can also be used is to utilize a dataplane firewall filter or classifier to enable matching of several fields in the incoming packets to decide whether the packet is steered on a specific slice. This option allows for applying a rich set of rule(s) to identify specific packets to be mapped to a network slice. However, it requires dataplane network resources to be able to perform the additional checks in hardware. 6. Control Plane Extensions Routing protocol(s) may need to be extended to carry additional per slice link state. For example, [RFC5305], [RFC3630], and [RFC7752] are ISIS, OSPF, and BGP protocol extensions to exchange network link state information to allow ingress TE routers and PCE(s) to do proper path placement in the network. The extensions required to support network slicing may be defined in other document(s), and are outside the scope of this document. The provisioning of the network slicing device Slice-PHD may need to be automated. Multiple options are possible to facilitate automation of provisioning a network slice definition on device(s) that are capable of network slicing. For example, a YANG data model for the network Slice-PHD may be supported on network devices and controllers. A suitable transport Saad & Beeram Expires May 3, 2021 [Page 22] Internet-Draft IP/MPLS Network Slicing October 2020 (e.g. NETCONF [RFC6241], RESTCONF [RFC8040], or gRPC) may be used to enable configuration and retrieval of state information for network slicing on network device(s). The network Slice-PHD YANG data model may be defined in a separate document, and is outside the scope of this document. 7. Applicability to Path Control Technologies The network slicing approach(s) described in this document are agnostic to the technology used to setup path(s) that carry networking slice traffic. Once feasible path(s) within a network slice are selected, it is possible to use RSVP-TE protocol [RFC3209] to setup or signal the LSP(s) that would be used to carry slice traffic. Specific extension(s) to RSVP-TE protocol to enable signaling of slice aware RSVP LSP(s) are outside the scope and will be tackled in a separate document(s). Alternatively, Segment Routing (SR) [RFC8402] may be used and the feasible path(s) can realized by steering over specific segment(s) or segment-list(s) using an SR policy. Further detail(s) on how the approach(es) presented in this document can be realized over an SR network will be tackled in a separate document. 8. IANA Considerations This document has no IANA actions. 9. Security Considerations The main goal of network slicing is to allow for some level of isolation for traffic from multiple different network slices that are utilizing a common network infrastructure and to allow for different levels of services to be provided for traffic traversing a single network slice resource(s). A variety of techniques may be used to achieve this, but the end result will be that some packets may be mapped to specific resource(s) and may receive different (e.g., better) service treatment than others. The mapping of network traffic to a specific slice is indicated primarily by the SS, and hence an adversary may be able to utilize resource(s) allocated to a specific network slice by injecting packets carrying the same SS field in their packets. Such theft-of-service may become a denial-of-service attack when the modified or injected traffic depletes the resources available to forward legitmiate traffic belonging to a specific network slice. Saad & Beeram Expires May 3, 2021 [Page 23] Internet-Draft IP/MPLS Network Slicing October 2020 The defense against this type of theft and denial-of-service attacks consists of the combination of traffic conditioning at network slicing domain boundaries with security and integrity of the network infrastructure within a network slicing domain. 10. Acknowledgement The authors would like to thank Krzysztof Szarkowicz, Swamy SRK, and Prabhu Raj Villadathu Karunakaran for their review of this document, and for providing valuable feedback on it. 11. Contributors The following individuals contributed to this document: Colby Barth Juniper Networks Email: cbarth@juniper.net Srihari R. Sangli Juniper Networks Email: ssangli@juniper.net Chandra Ramachandran Juniper Networks Email: csekar@juniper.net 12. References 12.1. Normative References [I-D.draft-filsfils-spring-srv6-stateless-slice-id-01] Filsfils, C., Clad, F., Camarillo, P., and K. Raza, "Stateless and Scalable Network Slice Identification for SRv6", draft-filsfils-spring-srv6-stateless-slice-id-01 (work in progress), July 2020. [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-13 (work in progress), October 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Saad & Beeram Expires May 3, 2021 [Page 24] Internet-Draft IP/MPLS Network Slicing October 2020 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 12.2. Informative References [I-D.draft-dt-teas-rfc3272bis-11] Farrel, A., "Overview and Principles of Internet Traffic Engineering", draft-dt-teas-rfc3272bis-11 (work in progress), May 2020. Saad & Beeram Expires May 3, 2021 [Page 25] Internet-Draft IP/MPLS Network Slicing October 2020 [I-D.draft-nsdt-teas-ns-framework-04] Gray, E. and J. Drake, "Framework for Transport Network Slices", draft-nsdt-teas-ns-framework-04 (work in progress), July 2020. [I-D.draft-nsdt-teas-transport-slice-definition-04] Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "IETF Definition of Transport Slice", draft- nsdt-teas-transport-slice-definition-04 (work in progress), September 2020. [I-D.nsdt-teas-ietf-network-slice-definition] Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "Definition of IETF Network Slices", draft-nsdt- teas-ietf-network-slice-definition-00 (work in progress), October 2020. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Authors' Addresses Tarek Saad Juniper Networks Email: tsaad@juniper.net Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net Saad & Beeram Expires May 3, 2021 [Page 26]