Services Deployment Guideline in DetNet Network
draft-dang-detnet-deployment-01

Document Type Active Internet-Draft (individual)
Authors Joanna Dang  , Zongpeng Du  , Yizhou Li 
Last updated 2021-10-09
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
DetNet                                                      J. Dang, Ed.
Internet-Draft                                                    Huawei
Intended status: Informational                                     Z. Du
Expires: 12 April 2022                                      China Mobile
                                                              L. Li, Ed.
                                                                  Huawei
                                                          9 October 2021

            Services Deployment Guideline in DetNet Network
                    draft-dang-detnet-deployment-01

Abstract

   Deterministic Networking (DetNet) defined in [RFC8655] provides a
   capability for the delivery of data flows with extremely low packet
   loss rates and bounded end-to-end delivery latency.  DetNet network
   administrators worldwide can deploy DetNet services into their
   networks.  This document aims to provide a guideline for DetNet
   network administrators.

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 12 April 2022.

Copyright Notice

   Copyright (c) 2021 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 carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Dang, et al.              Expires 12 April 2022                 [Page 1]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   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
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology & Abbreviations . . . . . . . . . . . . . . . . .   3
   4.  Preparation and Planning of DetNet networks . . . . . . . . .   3
     4.1.  Collecting and Planning information of DetNet system  . .   4
     4.2.  Collecting and Planning parameters of DetNet service and
           DetNet flow . . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.1.  Explicit Path and Service Protection  . . . . . . . .   5
       4.2.2.  Encapsulation Type of Networking Technology . . . . .   5
       4.2.3.  Type of Queuing Mechanism . . . . . . . . . . . . . .   6
     4.3.  DetNet Resource Evaluation  . . . . . . . . . . . . . . .   6
       4.3.1.  DetNet Bandwidth Evaluation and Reservation . . . . .   7
       4.3.2.  DetNet Latency Evaluation . . . . . . . . . . . . . .   8
       4.3.3.  DetNet Jitter Evaluation  . . . . . . . . . . . . . .   8
   5.  Controller Processing and Operation . . . . . . . . . . . . .   8
   6.  Performed Functions on DetNet Network Node  . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Deterministic Networking (DetNet) defined in [RFC8655] provides a
   capability for the delivery of data flows with extremely low packet
   loss rates and bounded end-to-end delivery latency.  The diverse
   industries in [RFC8578] have in common a need for "deterministic
   flows".  How to introduce deterministic flows to the DetNet network
   is required.

   While the DetNet technologies are becoming mature, it's the right
   time for DetNet deployment to do the live network experiments and
   even large-scale commercial deployments.  The DetNet network is
   actively managed by a network operations entity (the "administrator",
   whether a single person or a department of administrators).  A
   network administrator is responsible for the deployment of DetNet
   services, who can must master the skills of how to introduce
   deterministic flows into DetNet networks and the related maintenance.

   This document is intended as guidance for DetNet network
   administrators.  And the DetNet network belongs to the L3 layer
   network.

Dang, et al.              Expires 12 April 2022                 [Page 2]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   The processes of consists of deployment preparation, planning and
   configuration.  Session 4 illustrates what information needs to be
   collected and how to use them and how to input the collected
   parameters into the network planning system.  In session 5, the
   controller executes the operation instructions to generate
   configurations and even calculates specific explicit paths.  Session
   6 and the network element node performs configuration and path
   information received from the controller.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

3.  Terminology & Abbreviations

   DetNet UPE

   A DetNet edge node, which connects DetNet flows into DetNet network.

   DetNet P

   A DetNet relay node or DetNet transit node.

   DetNet PE

   A DetNet edge node, where DetNet flows leave DetNet network.

   DetNet source

   An end system is capable of originating a DetNet flow.

   DetNet Destination

   An end system is capable of terminating a DetNet flow.

4.  Preparation and Planning of DetNet networks

   Before deployment, a DetNet network administrator must first fully
   understand the concept of DetNet service defined in session 4.3 of
   RFC 8655, DetNet flow defined in RFC 9016, and explicit route defined
   in defined in session 3.2.3 of RFC8655.  The essence of DetNet
   service deployment is to map the DetNet service to the corresponding
   DetNet flow, and then use the relevant explicit path to transmit on
   the network.

Dang, et al.              Expires 12 April 2022                 [Page 3]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   Next, the DetNet network administrator must investigate and
   understand the status of the network.  After that she/he should input
   the information collected onto the DetNet planning tool, which may be
   integrated in the controller or appears as an independent system.
   The DetNet planning tool should have a certain degree of automation
   capabilities.

   In this document, we do not introduce the connectivity deployment
   (such as IGP, BGP) of the basic network, and assume that the basic
   network connections are ready.

4.1.  Collecting and Planning information of DetNet system

   The DetNet network administrator must figure out the related DetNet
   system where DetNet service to be deployed.  The DetNet system should
   include DetNet Edge and Transit Nodes, which node the DetNet flow
   will passes through via explicit paths.  The DetNet network
   administrator must know the specific location of the relevant network
   nodes of DetNet system, which should be single-domain or cross-
   domain.  If the DetNet network is cross-domain, some Transit Nodes
   may also perform the functions of ASBR.

4.2.  Collecting and Planning parameters of DetNet service and DetNet
      flow

   The DetNet network administrator should collect the parameters of
   DetNet service and DetNet flow.

   According to session 6 of RFC 9016, the management ID, delivery type,
   delivery profile, connectivity type and BiDir requirement and rank of
   the Detnet services should be collected.

   According to session 5 of RFC9016, the management ID, payload type,
   format, identification and specification, endpoints, rank,
   requirement and BiDir Requirement of the Detnet flows should be
   collected.  The flow identification for MPLS and IP Data Planes are
   described in [RFC8939] , [RFC8964], and Ethernet information (such as
   MAC address, VLAN) respectively.

   The DetNet network administrator must plan how to map the DetNet
   services into a DetNet flow.  If a DetNet service wants to join
   DetNet flow, the premise is that the encapsulation types of both of
   them must be the same and DetNet Edges to be used are same.  About
   the encapsulation types, that is, the Delivery Type of the DetNet
   Service must be equal to the Payload Type of the DetNet Flow.  Then
   it is necessary to determine whether the Requirements of the DetNet
   Flow can meet the requirements of the Delivery Profile of the DetNet
   Service.  First, it is seen if MaxLatency, MaxLatencyVariation,

Dang, et al.              Expires 12 April 2022                 [Page 4]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   MaxLoss, MaxConsecutiveLossTolerance, MaxMisordering are satisfied.
   If they are satisfied, it is judged whether MinBandwidth can be
   satisfied.  The above work should be done using automation functions.
   It is finally determined that the DetNet services will join a DetNet
   flow, then a Management ID of the DetNet Flow is assigend to this
   DetNet services.  To explain further, Management ID of the DetNet
   Flow, which is a unique identifier for identifying each DetNet flow,
   can be used to define the N:1 mapping of DetNet flows to a DetNet
   service.

   If a DetNet flow deployed needs to be canceled, the network
   administrator will execute the corresponding undo operation through
   the controller, and the network will release the corresponding
   resources.

4.2.1.  Explicit Path and Service Protection

   In the follow-up work, the DetNet network administrator creates
   explicit route defined in section 3.2.3 of [RFC8655] according to the
   information which node the DetNet flow is accessed from and which
   node the DetNet flow leaves from.

   The endpoints, where the Detnet service will access to and explicit
   paths will be running between, must be within the scope of the DetNet
   system.  Based on the endpoints of the DetNet flow, the related
   DetNet Ingress PE and Egress PE are determined.  The DetNet Ingress
   PE and Egress PE can run more than one explicit path to implement
   service protection and reordering on DetNet Edge nodes.

   The DetNet network administrator can consider how to do with service
   protection to meet MaxLoss, MaxConsecutiveLossTolerance and
   MaxMisordering of a deterministic flow.  The premise of service
   protection is that there are multiple available explicit paths for a
   DetNet flow.  These types of packet loss can be greatly reduced by
   spreading the data over multiple disjointed forwarding paths.  The
   PREOF embeded in the PE node ensures that packets are not out of
   order.

4.2.2.  Encapsulation Type of Networking Technology

   The DetNet network administrator must pay attention to the
   encapsulation type of the explicit route, which is added to the
   DetNet flows when DetNet flow enters the UPE node.  The DetNet
   network administrator may freely choose encapsulation type of the
   networking technology according to his/her preferences.  The way of
   IP over SR or [IP-Over-MPLS] or IP over SR is recommended.

Dang, et al.              Expires 12 April 2022                 [Page 5]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

4.2.3.  Type of Queuing Mechanism

   Based on the traffic specification and rank of the DetNet flow, the
   buffer settings of the queue, including Guaranteed-Service IntServ,
   Cyclic Queuing and Forwarding and so on, need to refer to Internal,
   MaxPacketsPerInterval, MaxPayloadSize, MinPacketsPerInterval and
   DnFlowRank within them.

   The DetNet network administrator obtains or sets the queuing type
   used by the network.  For examplem, if the cyclic queuing mechanism
   is used in the network, the parameters of the queuing.  This
   mechanism must allow multiple deterministic flows to share a periodic
   buffer.

   *  CyclicBufferSize: the length of the cyclic buffer

   *  CyclicInterval: duration of periodic scheduling

   *  BufferNumber: the number of the cyclic buffer

   *  MinBurstSize: the minimum burst size that can be tolerated by
      cyclic queue mechanism, which is specified in octets per second
      and excludes additional DetNet header (if any).Bandwidth used
      above the Committed Information rate is called Burst traffic.  It
      is used when the bandwidth available is more than CIR.
      MinBurstSize is the minimum burst size that has to be guaranteed
      for the DetNet traffic.  The queuing mechanism needs to pay
      attention to how to shape burst size traffic into buffers.

4.3.  DetNet Resource Evaluation

   The DetNet network administrator can enable network resource
   evaluation and reservation of the controller.  The requirements of
   DetNet flow in section 5.9 of [RFC9016] include MinBandwidth,
   MaxLatency, MaxLoss, MaxConsecutiveLossTolerance and MaxMisordering.
   If the deterministic flow has requirement for Jitter, a new parameter
   named jitter needs to be added.

   In fact, the network may support a distributed protocol similar to
   RSVP defined in [draft-trossen-detnet-rsvp-tsn], so this function can
   rely on the distributed protocol.

   Based on Requirements of DetNet flow, the resource reservation
   algorithm must completely satisfy them.  Regarding MaxLatency, there
   are different precision degree of mechanisms, one is to seek a
   maximum degree of approximation, the other is to ensure accuracy.
   The CFQ mechanism is recommended when resource reservation works
   well.

Dang, et al.              Expires 12 April 2022                 [Page 6]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   The DetNet SLA requirements to the DetNet flow generally have
   deterministic bandwidth, bounded latency and bounded jitter.  But in
   fact these three parameters are interrelated.  For example, the
   insufficient bandwidth reservation might introduce the additional
   delay or the additional jitter.  Therefore, the bandwidth reservation
   should consider the latency and jitter requirements.

   There are three methods here to do with, one is to get it through
   centralized calculation provided by controller or other centralized
   systems, the other is to get it through negotiation between DetNet
   Nodes along the explicit routes, and the third is to rely on the
   human brain.  When the scale of the network becomes larger or the
   types of services become more, the third method is difficult to
   handle.  Therefore, the first and the second methods are recommended.
   These centralized and distributed solutions can cooperate with each
   other, for example, if the centralized system is offline, the
   distributed system functions will be enabled.  Or in order to support
   rapid network decision-making, the priority is given to using
   distributed systems for deployment, and the centralized systems are
   responsible for global optimization.

   The algorithm on the network resource reservation is not discussed
   now in this document.

4.3.1.  DetNet Bandwidth Evaluation and Reservation

   The DetNet network administrator must know the bandwidth resource
   evaluation and reservation can be divided into service access
   interface part on the DetNet UPE node and explicit route part.

   *  Service access interface part on the DetNet UPE node: The
      bandwidth of service access interface part on the DetNet UPE is
      reserved according to the MinBandwidth of the DetNet flow.

   *  Explicit route part: This mechanism ensures that the available
      bandwidth along the explicit path can meet MinBandwidth of DetNet
      flow.

   The P node should take into account that there are multiple explicit
   routes passing in the same direction.  For example, if one interface
   of P node accesses 3 explicit paths, the reserved bandwidth of the
   interface is the total required bandwidth of the 3 explicit paths.

   It is emphasized that the remaining bandwidth of the interface on the
   DetNet nodes can also be used for non-DetNet flows.

Dang, et al.              Expires 12 April 2022                 [Page 7]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

4.3.2.  DetNet Latency Evaluation

   The DetNet network administrator can let the controller collect the
   network-wide delay information for calculation and evaluation, and
   obtain the queuing type.

   Given that DetNet nodes have a finite amount of buffer space, the
   resource allocation necessarily results in a maximum end-to-end
   latency.  The overall latency of the explicit route can be calculated
   based on the queue scheduling mechanism on the data plane of the
   DetNet nodes.  The queue scheduling mechanisms have various types,
   such as DiffServ,Qch[IEEE802.1QCH] and so on.
   [DetNet-Bounded-Latency] provides end-to-end delay bound and backlog
   bound computations for such mechanisms that can be used by the
   control plane to provide DetNet QoS.  If the CQF is used,
   CyclicBufferSize, CyclicInterval and BufferNumber of queuing
   mechanism can be included in the calculation factors that affect the
   E2E delay.

   The controller evaluates the path delay based on the resources of the
   entire network, and judges whether it meets the MaxLatency of the
   deterministic flow.

4.3.3.  DetNet Jitter Evaluation

   The DetNet network administrator can figure out that there are two
   aspects to reduce network jitter.  The first is through resource
   reservation in section 4.4.1 to 4.4.2 , and the second is through
   effective queuing control methods.  The former is not easy to
   evaluate jitter, but the latter is very convenient.  The DetNet
   network administrator also can know the queuing type, because not all
   queuing mechanisms have a jitter control mechanism.  The CQF is
   recommend to effectively solve the uncertainty of jitter.  Under this
   mechanism, the end to end jitter can be controlled within 2 *
   CyclicInterval.

5.  Controller Processing and Operation

   The DetNet network administrator should let the planning tool connect
   to DetNet controller defined in draft-ietf-detnet-controller-plane-
   framework ,or the planning tool should automatically to notisfy the
   DetNet controller after the work finised in the planning tool.  As
   draft-ietf-detnet-controller-plane-framework describes, the DetNet
   control plane is responsible for the instantiation and maintenance of
   DetNet services and DetNet flows and explicit path, for the functions
   of resource reservation, path caculation and service protection.

Dang, et al.              Expires 12 April 2022                 [Page 8]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   Finally, the DetNet controller should generate configuration and path
   information and download them on demand to the related DetNet network
   nodes.

   After the information is input by the DetNet network administrator,
   the controller will convert the information into the network
   configuration and send it to the DetNet network element node, using a
   protocol such as NETCONF [RFC6241]/YANG[RFC6020].  Deterministic
   Networking (DetNet) YANG Model defined in [DetNet-YANG] contains the
   specification for the Deterministic Networking YANG Model for
   configuration and operational data for DetNet Flows.

6.  Performed Functions on DetNet Network Node

   The DetNet network administrator should check the operation of the
   DetNet network nodes.

   The dynamic signaling protocols most commonly used for label
   distribution are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which
   enables BGP/ MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs
   [RFC7432]).

   After DetNet network node receives the information from the
   controller, the function will be executed.

   Basic Network Configuration among DetNet Network nodes:

   *  MPLS TE or Segment Routing configuration RSVP configuration for
      resource reservation(optional)

   *  Configuration Enabling DetNet capability Configuration of Queuing
      mechanism

   Ingress Node DetNet services Configuration:

   *  DetNet flow Configuration Explicit path configuration

   *  Configuration of Mapping DetNet flow to explicit path
      Configuration of Service Protection

   *  Configuration of Queuing mechanism EgressConfiguration of Queuing
      mechanism Configuration of Service Protection

   Egress Node DetNet services Configuration:

   *  DetNet flow Configuration Explicit path configuration

Dang, et al.              Expires 12 April 2022                 [Page 9]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   *  Configuration of Mapping DetNet flow to explicit path
      Configuration of Service Protection

   *  Configuration of Queuing mechanism EgressConfiguration of Queuing
      mechanism Configuration of Service Protection

   After DetNet network equipment receives the configuration, it starts
   to execute.  As Figure 2 is shown, the functions of each DetNet
   network element is clearly visible.

    SDN         +----+  1.Entrance to the above information
   Controller   |    |  2.Network Resource Evaluation and Reservation(Optional)
                +----+  3.Converting the information into the network configuration
                  |
      +--------+-------+------+
      |        |       |      |
   +----+   +---+   +---+   +---+
   U PE +---+ P +---+...+---+ PE+
   +----+   +---+   +---+   +---+
     |        |              |
     |        |              +-->+-----------------------------+
     |        |                  |1. Enabling queuing mechanism|
     |        |                  |2. End Explicit Path         |
     |        |                  +-----------------------------+
     |        +-->+--------------------------+
     |            |Enabling queuing mechanism|
     |            +--------------------------+
     +--> +-------------------------------------------------------+
          |1.Identifying a deterministic flow                     |
          |2.Establishing explicit path for the deterministic flow|
          |3.Enabling queuing mechanism                           |
          +-------------------------------------------------------+

   Figure-2: DetNet Network Functions

7.  Security Considerations

   The DetNet network administrator should work accroding to RFC 9055
   which addresses security considerations specific to the IP and MPLS
   data plane technologies, thereby complementing the Security
   Considerations sections of those documents.

8.  Normative References

   [DetNet-Bounded-Latency]
              "DetNet Bounded Latency", <https://www.rfc-
              editor.org/info/draft-ietf-detnet-bounded-latency>.

Dang, et al.              Expires 12 April 2022                [Page 10]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   [DetNet-YANG]
              "Deterministic Networking (DetNet) YANG Model",
              <https://www.rfc-editor.org/info/draft-ietf-detnet-yang-
              12>.

   [draft-trossen-detnet-rsvp-tsn]
              "RSVP for TSN Networks", <https://www.rfc-editor.org/info/
              draft-trossen-detnet-rsvp-tsn>.

   [IEEE802.1QCH]
              "IEEE Standard for Local and metropolitan area networks--
              Bridges and Bridged Networks--Amendment 29: Cyclic Queuing
              and Forwarding",
              <https://ieeexplore.ieee.org/document/7961303>.

   [IP-Over-MPLS]
              "DetNet Data Plane: IP over MPLS", <https://www.rfc-
              editor.org/info/draft-ietf-detnet-ip-over-mpls>.

   [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>.

   [RFC3209]  "RSVP-TE: Extensions to RSVP for LSP Tunnels",
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC6020]  "YANG - A Data Modeling Language for the Network
              Configuration Protocol (NETCONF)",
              <https://www.rfc-editor.org/info/RFC6020>.

   [RFC6241]  "Network Configuration Protocol (NETCONF)",
              <https://www.rfc-editor.org/info/RFC6241>.

   [RFC8402]  "Segment Routing Architecture",
              <https://www.rfc-editor.org/info/RFC8402>.

   [RFC8578]  "Deterministic Networking Use Cases",
              <https://www.rfc-editor.org/info/rfc8578>.

   [RFC8655]  "Deterministic Networking Architecture",
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8934]  "Deterministic Networking (DetNet) Data Plane: MPLS",
              <https://www.rfc-editor.org/info/rfc8934>.

   [RFC8939]  "Deterministic Networking (DetNet) Data Plane: IP",
              <https://www.rfc-editor.org/info/rfc8939>.

Dang, et al.              Expires 12 April 2022                [Page 11]
Internet-Draft   Services Deployment Guideline in DetNet    October 2021

   [RFC8964]  "Deterministic Networking (DetNet) Data Plane: MPLS",
              <https://www.rfc-editor.org/info/rfc8964>.

   [RFC9016]  "Flow and Service Information Model for Deterministic
              Networking (DetNet)",
              <https://www.rfc-editor.org/info/RFC9016>.

   [RFC9023]  "Deterministic Networking (DetNet) Data Plane: IP over
              IEEE 802.1 Time-Sensitive Networking (TSN)",
              <https://www.rfc-editor.org/info/rfc9023>.

Authors' Addresses

   Joanna Dang (editor)
   Huawei
   No.156 Beiqing Road
   Beijing
   P.R. China, 100095
   China

   Email: dangjuanna@huawei.com

   Zongpeng Du
   China Mobile
   32 Xuanwumen West St
   Beijing
   P.R. China, 100053
   China

   Email: duzongpeng@chinamobile.com

   Yizhou (editor)
   Huawei
   P.R. China,
   China

   Email: liyizhou@huawei.com

Dang, et al.              Expires 12 April 2022                [Page 12]