SPRING Working Group T. Saad Internet-Draft V. Beeram Intended status: Standards Track Juniper Networks Expires: June 19, 2021 December 16, 2020 Scalable Network Slicing over SR Networks draft-bestbar-spring-scalable-ns-00 Abstract Multiple network slices can be realized on top of a single shared network. A router that requires forwarding of a packet that belongs to a network slice may have to decide on the forwarding action to take based on selected next-hop(s), and the forwarding treatment (e.g. scheduling and drop policy) to enforce based on the slice aggregate per-hop behavior. Segment Routing is a technology that enables the steering of packets in a network by encoding pre- established segments within the network into the packet header. This document introduces mechanisms to enable forwarding of packets over a specific network slice along a Segment Routing (SR) path. 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 June 19, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Saad & Beeram Expires June 19, 2021 [Page 1] Internet-Draft Scalable Network Slices over SR December 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Forwarding over SR Network Slices . . . . . . . . . . . . . . 3 2.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 3 2.2. Network Slice Selection . . . . . . . . . . . . . . . . . 4 2.2.1. Segment Range as Slice Selector . . . . . . . . . . . 4 2.2.2. Global Identifier as Slice Selector . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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. When logical network slices are realized on top of a shared physical network, it is important to forward traffic using only the specific resource(s) allocated for the network slice. Packets that traverse a network slice MAY be identified by specific field(s) carried within the packet. Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets through a network by carrying an ordered list of segments. A segment is referred to by its Segment Identifier (SID). This document introduces two approaches applicable to SR networks that enable forwarding of packet(s) that belong to a network slice over a SR Path. The first approach extends the SR paradigm by defining a new SID type (slice SID) that, in addition to defining the forwarding action (next-hop selection), associates a SID to the network slice and allows enforcing the specified forwarding treatment. Saad & Beeram Expires June 19, 2021 [Page 2] Internet-Draft Scalable Network Slices over SR December 2020 The second approach relies on a separate field carried in the packet (e.g. MPLS label) to identify the network slice and relies on another field (e.g. existing SR segments) for the path selection for the packet. 1.1. Terminology 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. 2. Forwarding over SR Network Slices A router that receives a packet that belongs to a network slice has to decide on the set of eligible next-hop(s) to forward the packet on (path selection), and on the forwarding treatment (scheduling and drop policy) that needs to be enforced for a specific slice (network slice selection). 2.1. Path Selection The segment routing architecture [RFC8402] defines a number of topological segments that may be advertised in routing protocols to allow for a flexible definition of end-to-end paths. For example, an SR-capable IGP node may advertise SIDs for its attached prefixes and adjacencies. The IGP-Adjacency segment represents the strict path over a specific adjacency between two routers, while the IGP-Prefix segment represents the path to a prefix that is computed over a specific topology and algorithm. For an IGP-Prefix segment, the IGP uses the topology and algorithm to compute the primary, and optionally alternate (backup) next-hop(s) for a destination prefix. SR allows the use of multiple routing algorithms (e.g. Flexible Algorithms) that enable IGPs on a router to compute paths for Prefix-SIDs whose topology may be constrained and whose paths optimized for additional metric types other than the default IGP cost (e.g. delay metric). Multiple network slice(s) may overlap over the same topology and may require paths to prefixes be optimized for the same metric. In such case, the IGP prefix selected path (including the primary and backup computed next-hop(s)) can be shared for all the per slice Prefix- SIDs. The IGP, then, can maintain a single topology for N network Saad & Beeram Expires June 19, 2021 [Page 3] Internet-Draft Scalable Network Slices over SR December 2020 slices, which allows for optimizing SPF computation(s) for multiple Slice SIDs and improves convergence. 2.2. Network Slice Selection Routers that forward packets over links shared by multiple network slices need to identify to which network slice the packet belongs so that the associated forwarding treatment can be enforced. In [I-D.draft-bestbar-teas-ns-packet-00], a Slice Per Hop Definition (Slice-PHD) is introduced that carries a number of policies related to a network slice, including a slice selector that can be used to identify packets belonging to a slice, and a dataplane policy that defines the forwarding treatment that is enforced on network slice packets. 2.2.1. Segment Range as Slice Selector It is possible to derive the forwarding action (next-hop selection) and the per-hop forwarding treatment from a single field (e.g. SR segment) carried inside a packet that is traversing the SR network. For example, one way to achieve this is leverage the SR Flexible Algorithm [I-D.ietf-lsr-flex-algo] to assign multiple SR Prefix-SIDs for a prefix and map all Prefix-SIDs of the same FAD to a network slice. While this approach does not require any protocol extension to realize, it does pose some IGP scalability concerns when realizing a large number of network slices (and consequently, the number of FADs that need to be advertised and managed by the IGP in a network). Another approach, is to add a new distinguisher to existing IGP segments (e.g. Prefix-SID and Adjacency-SID) to allow multiple SIDs to be assigned (and advertised) for the same topological element within the same FAD. This approach requires extending the IGP segment Prefix-SID and Adjacency-SID TLVs to carry a new distinguisher field (e.g. network slice identifier). In such a case, the traffic that belongs to different network slices, but destined to the same topological element, carries the specific per slice SID, and a transit node can use the active (top) SID to derive both the forwarding action and forwarding treatment from the slice SID. For example, multiple per slice Prefix-SIDs (Slice Prefix-SIDs) can be assigned for the same prefix such that they all share the same IGP computed path over one topology and optimized for one algorithm to allow the steering of traffic to the same prefix along a path but over different network slices. Saad & Beeram Expires June 19, 2021 [Page 4] Internet-Draft Scalable Network Slices over SR December 2020 Similarly, multiple Adjacency-SIDs can be allocated for the same adjacency between the two routers to distinguish forwarding over the same adjacency on each network slice. The same forwarding treatment MUST be enforced on all packets belonging to the network slice but could be destined to any topological element in the network. In this case, a range of Slice SIDs are used to select the same network slice and any packet steered with such Slice SIDs will be subject to the dataplane policy defined in the Slice-PHD. Notably, this approach requires maintaining per slice state for each topological element on every router in the network in both the control and data plane. For example, a network composed of 'N' nodes, where each node has up to 'K' adjacencies to its neighbors, a node would have to assign and advertise 'M' Slice Prefix-SIDs and 'M' Slice Adjacency-SID(s) to each of it 'K' adjacencies. Consequently, a router will have to maintain up to (N+K)*M SIDs in the control plane, and an equal number of label routes in its forwarding plane. Consider a network shown in Figure 1 that is enabled for SR. The Segment Routing Global Block (SRGB) on all nodes is assumed to start from 16000. We assume the links in the network are partitioned amongst two network slices: SLC1, and SLC2. o Node R5 assigns Slice Prefix-SIDs for Algorithm 0 of index=105, and index=205 for network slice SLC1 and SLC2 respectively to represent the shortest IGP path from any node to R5. o A Flexible Algorithm Definition (FAD) number 128 is user-defined such that the FAD Metric-Type is 1 (Min Unidirectional Link Delay). o Node R5 assigns Slice Prefix-SIDs for Algorithm 128 of index=815, and index=825 for network slices SLC1 and SLC2 respectively to represent the least delay path from any node to R5. o All nodes in the network participate and advertise their capability to compute FAD 128 Prefix-SID paths. Using the approach described in this section, R1 is able to forward packets that traverse network slices SLC1 and SLC2 along the least delay path by imposing the MPLS SR SID 16815, and 16825 respectively. Alternatively, R1 is able to forward packets that traverse network slices SLC1 and SLC2 along the IGP shortest path to R5 by imposing the MPLS SR SID 16015, and 16025 respectively. Saad & Beeram Expires June 19, 2021 [Page 5] Internet-Draft Scalable Network Slices over SR December 2020 SLICE | ALG(0) | Path | Slice Prefix-SID(R5) | Symbol ======================================= SLC1 | 16015 | + SLC2 | 16025 | @ .. SLCn | .. | SLICE | ALG(128) | Path | Slice Prefix-SID(R5) | Symbol ======================================= SLC1 | 16815 | . SLC2 | 16825 | * .. SLCn | .. | + + + + + + + + + + + + + + @ @ @ @ @ @ @ @ @ @ @ @ + + @ +----+ @ + + @ +-------| R2 |------+ @ + +@ / +----+ \ @ + +----+ / \ +----+ | R1 | | R5 | +----+ \ / +----+ .* \+----+ +----+/ *. .* | R3 |---------| R4 | *. .* +----+ +----+ *. .* * * * * * * * * * * * * *. . . . . . . . . . . . . . . Figure 1: Example of forwarding over network slices using SR Paths. 2.2.2. Global Identifier as Slice Selector It is possible that the forwarding action and the per-hop behavior treatment are derived from different fields carried in a packet. For example, a packet can carry a global slice selector field that can be used to define the forwarding treatment while the forwarding next-hop selection relies on the SR topological SIDs. The makes the slice identification independent of the topology or the destination of the packet, and thus, allows for scalable network slicing. The global Slice Selector (SS) is carried in each packet destined to any topological element and that is to be steered over the network slice. For example, a global slice selector can be represented as a global MPLS label that is carried in an MPLS packet's label stack. Saad & Beeram Expires June 19, 2021 [Page 6] Internet-Draft Scalable Network Slices over SR December 2020 It is possible, also, to have multiple SS label(s) associated with the same network slice resources. When the slice is realized over an IPv6 dataplane, the SS can be encoded in the IP header. For example, the SS can be encoded in portion of the IPv6 Flow Label field as described in [I-D.draft-filsfils-spring-srv6-stateless-slice-id-01]. Routers within the network use the topological SR segment SIDs to determine the forwarding action (next-hop selection), and use the global slice selector to enforce the dataplane policy (e.g. as defined by the Slice-PHD). The Slice Selector Label (SSL) may appear in several positions in the MPLS label stack. For example, the SSL MAY be located at the top of the MPLS packet label stack and maintained, by each hop, while the packet is forwarded along the SR path. Alternatively, the SSL could also reside at the bottom of the label stack. For example, the VPN service label may also serve as an SSL which allows steering of traffic towards one or more egress PEs over the same network slice. In such a case, it MAY be desirable to have one or more service labels be mapped to the same network 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. In other 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 packets that belong to the network slice. It should be noted that this approach minimizes the amount of state required to be stored on a node to allow network slice forwarding since it does not require a Prefix-SID state per network slice in the control plane, nor in the forwarding plane. To illustrate forwarding over network slices using a global slice label, we consider the same network described earlier in Figure 1, but with some changes in the configuration: o Node R5 assigns a Prefix-SID for Algorithm 0 (default) of index=5 to represent the shortest IGP path from any node to R5. o Node R5 assigns a Prefix-SID for Algorithm 128 of index=805 to represent the least delay path from any node to R5. Saad & Beeram Expires June 19, 2021 [Page 7] Internet-Draft Scalable Network Slices over SR December 2020 o All nodes in the network participate and advertise their capability to compute FAD 128 Prefix-SID paths. o The global labels 1001 and 1002 are used as a slice selectors for packets that require to be forwarded over network slices SLC1 and SLC2 respectively. Using the approach described in this section, R1 is able to forward packets that traverse network slices SLC1 and SLC2 along the least delay path by imposing the following labels {1001,16805} and {1002,16805} respectively. Similarly, R1 is able to forward packets that traverse network slices SLC1 and SLC2 along the IGP shortest path to R5 by imposing the following labels {1001,16005} and {1002,16005} respectively. The path that the packets traverse in each of the above case remains as described in Figure 1. 3. IANA Considerations This document has no IANA actions. 4. 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. 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. Saad & Beeram Expires June 19, 2021 [Page 8] Internet-Draft Scalable Network Slices over SR December 2020 5. Acknowledgement The authors would like to thank Krzysztof Szarkowicz, Swamy SRK, Navaneetha Krishnan, and Prabhu Raj Villadathu Karunakaran for their review of this document, and for providing valuable feedback on it. 6. 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 7. Normative References [I-D.draft-bestbar-teas-ns-packet-00] Saad, T. and V. Beeram, "Realizing Network Slices in IP/ MPLS Networks", draft-bestbar-teas-ns-packet-00 (work in progress), October 2020. [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Saad & Beeram Expires June 19, 2021 [Page 9] Internet-Draft Scalable Network Slices over SR December 2020 [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, . Authors' Addresses Tarek Saad Juniper Networks Email: tsaad@juniper.net Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net Saad & Beeram Expires June 19, 2021 [Page 10]