10.  Network Slicing

10.1.  Use Case Description

   Network slicing divides one physical network infrastructure into
   multiple logical networks.  Each slice, which corresponds to a
   logical network, uses resources and network functions independently
   from each other.  Network slicing provides flexibility of resource
   allocation and service quality customization.

   Future services will demand network performance with a wide variety
   of characteristics such as high data rate, low latency, low loss
   rate, security, and many other parameters.  Ideally, every service
   would have its own physical network satisfying its particular
   performance requirements; however, that would be prohibitively
   expensive.  Network slicing can provide a customized slice for a
   single service, and multiple slices can share the same physical
   network.  This method can optimize performance for the service at
   lower cost, and the flexibility of setting up and releasing the
   slices also allows the user to allocate network resources
   dynamically.

   Unlike the other use cases presented here, network slicing is not a
   specific application that depends on specific deterministic
   properties; rather, it is introduced as an area of networking to
   which DetNet might be applicable.

10.2.  DetNet Applied to Network Slicing

10.2.1.  Resource Isolation across Slices

   One of the requirements discussed for network slicing is the "hard"
   separation of various users' deterministic performance.  That is, it
   should be impossible for activity, lack of activity, or changes in
   activity of one or more users to have any appreciable effect on the
   deterministic performance parameters of any other slices.  Typical
   techniques used today, which share a physical network among users, do
   not offer this level of isolation.  DetNet can supply point-to-point
   or point-to-multipoint paths that offer a user bandwidth and latency
   guarantees that cannot be affected by other users' data traffic.
   Thus, DetNet is a powerful tool when reliability and low latency are
   required in network slicing.

10.2.2.  Deterministic Services within Slices

   Slices may need to provide services with DetNet-type performance
   guarantees; note, however, that a system can be implemented to
   provide such services in more than one way.  For example, the slice
   itself might be implemented using DetNet, and thus the slice can
   provide service guarantees and isolation to its users without any
   particular DetNet awareness on the part of the users' applications.
   Alternatively, a "non-DetNet-aware" slice may host an application
   that itself implements DetNet services and thus can enjoy similar
   service guarantees.

10.3.  A Network Slicing Use Case Example - 5G Bearer Network

   Network slicing is a core feature of 5G as defined in 3GPP.  The
   system architecture for 5G is under development at the time of this
   writing [TS23501].  A network slice in a mobile network is a complete
   logical network, including RANs and Core Networks (CNs).  It provides
   telecommunications services and network capabilities, which may vary
   from slice to slice.  A 5G bearer network is a typical use case for
   network slicing; for example, consider three 5G service scenarios:
   eMBB, URLLC, and mMTC.

   o  eMBB (Enhanced Mobile Broadband) focuses on services characterized
      by high data rates, such as high-definition video, Virtual Reality
      (VR), augmented reality, and fixed mobile convergence.

   o  URLLC (Ultra-Reliable and Low Latency Communications) focuses on
      latency-sensitive services, such as self-driving vehicles, remote
      surgery, or drone control.

   o  mMTC (massive Machine Type Communications) focuses on services
      that have high connection-density requirements, such as those
      typically used in smart-city and smart-agriculture scenarios.

   A 5G bearer network could use DetNet to provide hard resource
   isolation across slices and within a given slice.  For example,
   consider Slice-A and Slice-B, with DetNet used to transit services
   URLLC-A and URLLC-B over them.  Without DetNet, URLLC-A and URLLC-B
   would compete for bandwidth resources, and latency and reliability
   requirements would not be guaranteed.  With DetNet, URLLC-A and
   URLLC-B have separate bandwidth reservations; there is no resource
   conflict between them, as though they were in different physical
   networks.

10.4.  Non-5G Applications of Network Slicing

   Although the operation of services not related to 5G is not part of
   the 5G network slicing definition and scope, network slicing is
   likely to become a preferred approach for providing various services
   across a shared physical infrastructure.  Examples include providing
   services for electrical utilities and pro audio via slices.  Use
   cases like these could become more common once the work for the 5G CN
   evolves to include wired as well as wireless access.

10.5.  Limitations of DetNet in Network Slicing

   DetNet cannot cover every network slicing use case.  One issue is
   that DetNet is a point-to-point or point-to-multipoint technology;
   however, network slicing ultimately needs multipoint-to-multipoint
   guarantees.  Another issue is that the number of flows that can be
   carried by DetNet is limited by DetNet scalability; flow aggregation
   and queuing management modification may help address this issue.
   Additional work and discussion are needed to address these topics.

10.6.  Network Slicing Today and in the Future

   Network slicing has promise in terms of satisfying many requirements
   of future network deployment scenarios, but it is still a collection
   of ideas and analyses without a specific technical solution.  DetNet
   is one of various technologies that could potentially be used in
   network slicing, along with, for example, Flex-E and segment routing.
   For more information, please see the IETF 99 Network Slicing BoF
   session agenda and materials as provided in [IETF99-netslicing-BoF].

10.7.  Network Slicing Requests to the IETF

   o  Isolation from other flows through queuing management

   o  Service quality customization and guarantees

   o  Security

11.  Use Case Common Themes

   This section summarizes the expected properties of a DetNet network,
   based on the use cases as described in this document.

11.1.  Unified, Standards-Based Networks

11.1.1.  Extensions to Ethernet

   A DetNet network is not "a new kind of network" -- it is based on
   extensions to existing Ethernet standards, including elements of
   IEEE 802.1 TSN and related standards.  Presumably, it will be
   possible to run DetNet over other underlying transports besides
   Ethernet, but Ethernet is explicitly supported.

11.1.2.  Centrally Administered Networks

   In general, a DetNet network is not expected to be "plug and play";
   rather, some type of centralized network configuration and control
   system is expected.  Such a system may be in a single central
   location, or it may be distributed across multiple control entities
   that function together as a unified control system for the network.
   However, the ability to "hot swap" components (e.g., due to
   malfunction) is similar enough to "plug and play" that this kind of
   behavior may be expected in DetNet networks, depending on the
   implementation.

11.1.3.  Standardized Data-Flow Information Models

   Data-flow information models to be used with DetNet networks are to
   be specified by DetNet.

11.1.4.  Layer 2 and Layer 3 Integration

   A DetNet network is intended to integrate between Layer 2 (bridged)
   network(s) (e.g., an AVB/TSN LAN) and Layer 3 (routed) network(s)
   (e.g., using IP-based protocols).  One example of this is making
   AVB/TSN-type deterministic performance available from Layer 3
   applications, e.g., using RTP.  Another example is connecting two
   AVB/TSN LANs ("islands") together through a standard router.

11.1.5.  IPv4 Considerations

   This document explicitly does not specify any particular
   implementation or protocol; however, it has been observed that
   various use cases (and their associated industries) described herein
   are explicitly based on IPv4 (as opposed to IPv6), and it is not
   considered practical to expect such implementations to migrate to

   IPv6 in order to use DetNet.  Thus, the expectation is that even if
   not every feature of DetNet is available in an IPv4 context, at least
   some of the significant benefits (such as guaranteed end-to-end
   delivery and low latency) will be available.

11.1.6.  Guaranteed End-to-End Delivery

   Packets in a DetNet flow are guaranteed not to be dropped by the
   network due to congestion.  However, the network may drop packets for
   intended reasons, e.g., per security measures.  Similarly,
   best-effort traffic on a DetNet is subject to being dropped (as on a
   non-DetNet IP network).  Also note that this guarantee applies to
   actions taken by DetNet protocol software and does not provide any
   guarantee against lower-level errors such as media errors or checksum
   errors.

11.1.7.  Replacement for Multiple Proprietary Deterministic Networks

   There are many proprietary non-interoperable deterministic Ethernet-
   based networks available; DetNet is intended to provide an
   open-standards-based alternative to such networks.

11.1.8.  Mix of Deterministic and Best-Effort Traffic

   DetNet is intended to support the coexistence of time-sensitive
   operational (OT) traffic and informational (IT) traffic on the same
   ("unified") network.

11.1.9.  Unused Reserved Bandwidth to Be Available to Best-Effort
         Traffic

   If bandwidth reservations are made for a stream but the associated
   bandwidth is not used at any point in time, that bandwidth is made
   available on the network for best-effort traffic.  If the owner of
   the reserved stream then starts transmitting again, the bandwidth is
   no longer available for best-effort traffic; this occurs on a
   moment-to-moment basis.  Note that such "temporarily available"
   bandwidth is not available for time-sensitive traffic, which must
   have its own reservation.

11.1.10.  Lower-Cost, Multi-Vendor Solutions

   The DetNet network specifications are intended to enable an ecosystem
   in which multiple vendors can create interoperable products, thus
   promoting device diversity and potentially higher numbers of each
   device manufactured, promoting cost reduction and cost competition

   among vendors.  In other words, vendors should be able to create
   DetNet networks at lower cost and with greater diversity of available
   devices than existing proprietary networks.

11.2.  Scalable Size

   DetNet networks range in size from very small (e.g., inside a single
   industrial machine) to very large (e.g., a utility-grid network
   spanning a whole country and involving many "hops" over various kinds
   of links -- for example, radio repeaters, microwave links, or fiber
   optic links).  However, recall that the scope of DetNet is confined
   to networks that are centrally administered and thereby explicitly
   excludes unbounded decentralized networks such as the Internet.

11.2.1.  Scalable Number of Flows

   The number of flows in a given network application can potentially be
   large and can potentially grow faster than the number of nodes and
   hops, so the network should provide a sufficient (perhaps
   configurable) maximum number of flows for any given application.

11.3.  Scalable Timing Parameters and Accuracy

11.3.1.  Bounded Latency

   DetNet data-flow information models are expected to provide means to
   configure the network that include parameters for querying network
   path latency, requesting bounded latency for a given stream,
   requesting worst-case maximum and/or minimum latency for a given path
   or stream, and so on.  It is expected that the network may not be
   able to provide a given requested service level; if this is indeed
   the case, the network control system should reply that the requested
   services are not available (as opposed to accepting the parameter but
   then not delivering the desired behavior).

11.3.2.  Low Latency

   Various applications may state that they require "extremely low
   latency"; however, depending on the application, "extremely low" may
   imply very different latency bounds.  For example, "low latency"
   across a utility-grid network is a different order of magnitude of
   latency values compared to "low latency" in a motor control loop in a
   small machine.  It is intended that the mechanisms for specifying
   desired latency include wide ranges and that architecturally there is
   nothing to prevent arbitrarily low latencies from being implemented
   in a given network.

11.3.3.  Bounded Jitter (Latency Variation)

   As with the other latency-related elements noted above, parameters
   that can determine or request permitted variations in latency should
   be available.

11.3.4.  Symmetrical Path Delays

   Some applications would like to specify that the transit delay time
   values be equal for both the transmit path and the return path.

11.4.  High Reliability and Availability

   Reliability is of critical importance to many DetNet applications,
   because the consequences of failure can be extraordinarily high in
   terms of cost and even human life.  DetNet-based systems are expected
   to be implemented with essentially arbitrarily high availability --
   for example, 99.9999% uptime (where 99.9999 means "six nines") or
   even 12 nines.  DetNet designs should not make any assumptions about
   the level of reliability and availability that may be required of a
   given system and should define parameters for communicating these
   kinds of metrics within the network.

   A strategy used by DetNet for providing such extraordinarily high
   levels of reliability is to provide redundant paths so that a system
   can seamlessly switch between the paths while maintaining its
   required level of performance.

11.5.  Security

   Security is of critical importance to many DetNet applications.  A
   DetNet network must have the ability to be made secure against device
   failures, attackers, misbehaving devices, and so on.  In a DetNet
   network, the data traffic is expected to be time sensitive; thus, in
   addition to arriving with the data content as intended, the data must
   also arrive at the expected time.  This may present "new" security
   challenges to implementers and must be addressed accordingly.  There
   are other security implications, including (but not limited to) the
   change in attack surface presented by PRE.

11.6.  Deterministic Flows

   Reserved-bandwidth data flows must be isolated from each other and
   from best-effort traffic, so that even if the network is saturated
   with best-effort (and/or reserved-bandwidth) traffic, the configured
   flows are not adversely affected.

12.  Security Considerations

   This document covers a number of representative applications and
   network scenarios that are expected to make use of DetNet
   technologies.  Each of the potential DetNet use cases will have
   security considerations from both the use-specific perspective and
   the DetNet technology perspective.  While some use-specific security
   considerations are discussed above, a more comprehensive discussion
   of such considerations is captured in [DetNet-Security]
   ("Deterministic Networking (DetNet) Security Considerations").
   Readers are encouraged to review [DetNet-Security] to gain a more
   complete understanding of DetNet-related security considerations.

13.  IANA Considerations

   This document has no IANA actions.