Scalable Network Slicing over SR Networks
draft-bestbar-spring-scalable-ns-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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, <https://www.rfc-editor.org/info/rfc8402>.

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]