<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-dang-detnet-deployment-01"
     ipr="trust200902">
  <front>
    <title abbrev="">Services Deployment Guideline in DetNet Network</title>

    <author fullname="Joanna Dang" initials="J." role="editor" surname="Dang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>No.156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>

          <region>P.R. China</region>
        </postal>

        <phone/>

        <email>dangjuanna@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Zongpeng Du" initials="Z." surname="Du">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>32 Xuanwumen West St</street>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>

          <region>P.R. China</region>
        </postal>

        <phone/>

        <email>duzongpeng@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Yizhou " initials="L." role="editor" surname="Li">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>China</country>

          <region>P.R. China</region>
        </postal>

        <phone/>

        <email>liyizhou@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="9" month="October" year="2021"/>

    <area>Routing Area (rtg)</area>

    <workgroup>DetNet</workgroup>

    <keyword>Deployment</keyword>

    <abstract>
      <t>Deterministic Networking (DetNet) defined in <xref target="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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Deterministic Networking (DetNet) defined in <xref target="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 <xref target="RFC8578"/> have in common a need for
      "deterministic flows". How to introduce deterministic flows to the
      DetNet network is required.</t>

      <t>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.</t>

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

      <t>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.</t>
    </section>

    <section anchor="RL" title="Requirements Language">
      <t>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.</t>
    </section>

    <section anchor="TA" title="Terminology &amp; Abbreviations">
      <t>DetNet UPE</t>

      <t>A DetNet edge node, which connects DetNet flows into DetNet
      network.</t>

      <t>DetNet P</t>

      <t>A DetNet relay node or DetNet transit node.</t>

      <t>DetNet PE</t>

      <t>A DetNet edge node, where DetNet flows leave DetNet network.</t>

      <t>DetNet source</t>

      <t>An end system is capable of originating a DetNet flow.</t>

      <t>DetNet Destination</t>

      <t>An end system is capable of terminating a DetNet flow.</t>
    </section>

    <section anchor="pbd" title="Preparation and Planning of DetNet networks">
      <t>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.</t>

      <t>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.</t>

      <t>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.</t>

      <section title="Collecting and Planning information of DetNet system">
        <t>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.</t>
      </section>

      <section title="Collecting and Planning parameters of DetNet service and DetNet flow">
        <t>The DetNet network administrator should collect the parameters of
        DetNet service and DetNet flow.</t>

        <t>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.</t>

        <t>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 <xref
        target="RFC8939"/> , <xref target="RFC8964"/>, and Ethernet
        information (such as MAC address, VLAN) respectively.</t>

        <t>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, 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.</t>

        <t>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.</t>

        <section anchor="EPASP" title="Explicit Path and Service Protection">
          <t>In the follow-up work, the DetNet network administrator creates
          explicit route defined in section 3.2.3 of <xref target="RFC8655"/>
          according to the information which node the DetNet flow is accessed
          from and which node the DetNet flow leaves from.</t>

          <t>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.</t>

          <t>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.</t>
        </section>

        <section anchor="DTNT"
                 title="Encapsulation Type of Networking Technology">
          <t>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 <xref target="IP-Over-MPLS"/> or IP over SR is
          recommended.</t>
        </section>

        <section anchor="Doqm" title="Type of Queuing Mechanism">
          <t>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.</t>

          <t>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.</t>

          <t><list style="symbols">
              <t>CyclicBufferSize: the length of the cyclic buffer</t>

              <t>CyclicInterval: duration of periodic scheduling</t>

              <t>BufferNumber: the number of the cyclic buffer</t>

              <t>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.</t>
            </list></t>
        </section>
      </section>

      <section anchor="DRE" title="DetNet Resource Evaluation">
        <t>The DetNet network administrator can enable network resource
        evaluation and reservation of the controller. The requirements of
        DetNet flow in section 5.9 of <xref target="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.</t>

        <t>In fact, the network may support a distributed protocol similar to
        RSVP defined in <xref target="draft-trossen-detnet-rsvp-tsn"/>, so
        this function can rely on the distributed protocol.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>The algorithm on the network resource reservation is not discussed
        now in this document.</t>

        <section anchor="ARA"
                 title="DetNet Bandwidth Evaluation and Reservation">
          <t>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.</t>

          <t><list style="symbols">
              <t>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.</t>

              <t>Explicit route part: This mechanism ensures that the
              available bandwidth along the explicit path can meet
              MinBandwidth of DetNet flow.</t>
            </list></t>

          <t>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.</t>

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

        <section anchor="ALAJ" title="DetNet Latency Evaluation">
          <t>The DetNet network administrator can let the controller collect
          the network-wide delay information for calculation and evaluation,
          and obtain the queuing type.</t>

          <t>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<xref target="IEEE802.1QCH"/> and so on. <xref
          target="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.</t>

          <t>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.</t>
        </section>

        <section anchor="sje" title="DetNet Jitter Evaluation">
          <t>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.</t>
        </section>
      </section>
    </section>

    <section title="Controller Processing and Operation">
      <t>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.</t>

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

      <t>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 <xref target="RFC6241"/>/YANG<xref
      target="RFC6020"/>. Deterministic Networking (DetNet) YANG Model defined
      in <xref target="DetNet-YANG"/> contains the specification for the
      Deterministic Networking YANG Model for configuration and operational
      data for DetNet Flows.</t>
    </section>

    <section title=" Performed Functions on DetNet Network Node">
      <t>The DetNet network administrator should check the operation of the
      DetNet network nodes.</t>

      <t>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]).</t>

      <t>After DetNet network node receives the information from the
      controller, the function will be executed.</t>

      <t>Basic Network Configuration among DetNet Network nodes:</t>

      <t><list style="symbols">
          <t>MPLS TE or Segment Routing configuration RSVP configuration for
          resource reservation(optional)</t>

          <t>Configuration Enabling DetNet capability Configuration of Queuing
          mechanism</t>
        </list>Ingress Node DetNet services Configuration:<list
          style="symbols">
          <t>DetNet flow Configuration Explicit path configuration</t>

          <t>Configuration of Mapping DetNet flow to explicit path
          Configuration of Service Protection</t>

          <t>Configuration of Queuing mechanism EgressConfiguration of Queuing
          mechanism Configuration of Service Protection</t>
        </list></t>

      <t>Egress Node DetNet services Configuration:</t>

      <t><list style="symbols">
          <t>DetNet flow Configuration Explicit path configuration</t>

          <t>Configuration of Mapping DetNet flow to explicit path
          Configuration of Service Protection</t>

          <t>Configuration of Queuing mechanism EgressConfiguration of Queuing
          mechanism Configuration of Service Protection</t>
        </list></t>

      <t>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.</t>

      <figure>
        <artwork align="right"><![CDATA[    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                           |
          +-------------------------------------------------------+
]]></artwork>

        <postamble>Figure-2: DetNet Network Functions</postamble>
      </figure>
    </section>

    <section anchor="security-considerations" title="Security Considerations">
      <t>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.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <reference anchor="RFC8655"
                 target="https://www.rfc-editor.org/info/rfc8655">
        <front>
          <title>Deterministic Networking Architecture</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC8578"
                 target="https://www.rfc-editor.org/info/rfc8578">
        <front>
          <title>Deterministic Networking Use Cases</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="DetNet-YANG"
                 target="https://www.rfc-editor.org/info/draft-ietf-detnet-yang-12">
        <front>
          <title>Deterministic Networking (DetNet) YANG Model</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="DetNet-Bounded-Latency"
                 target="https://www.rfc-editor.org/info/draft-ietf-detnet-bounded-latency">
        <front>
          <title>DetNet Bounded Latency</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC8934"
                 target="https://www.rfc-editor.org/info/rfc8934">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: MPLS</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IP-Over-MPLS"
                 target="https://www.rfc-editor.org/info/draft-ietf-detnet-ip-over-mpls">
        <front>
          <title>DetNet Data Plane: IP over MPLS</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC9023"
                 target="https://www.rfc-editor.org/info/rfc9023">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: IP over IEEE
          802.1 Time-Sensitive Networking (TSN)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC8964"
                 target="https://www.rfc-editor.org/info/rfc8964">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: MPLS</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC8939"
                 target="https://www.rfc-editor.org/info/rfc8939">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: IP</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC3209"
                 target="https://www.rfc-editor.org/info/rfc3209">
        <front>
          <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IEEE802.1QCH"
                 target="https://ieeexplore.ieee.org/document/7961303">
        <front>
          <title>IEEE Standard for Local and metropolitan area
          networks--Bridges and Bridged Networks--Amendment 29: Cyclic Queuing
          and Forwarding</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC8402"
                 target="https://www.rfc-editor.org/info/RFC8402">
        <front>
          <title>Segment Routing Architecture</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC6241"
                 target="https://www.rfc-editor.org/info/RFC6241">
        <front>
          <title>Network Configuration Protocol (NETCONF)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC6020"
                 target="https://www.rfc-editor.org/info/RFC6020">
        <front>
          <title>YANG - A Data Modeling Language for the Network Configuration
          Protocol (NETCONF)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC9016"
                 target="https://www.rfc-editor.org/info/RFC9016">
        <front>
          <title>Flow and Service Information Model for Deterministic
          Networking (DetNet)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="draft-trossen-detnet-rsvp-tsn"
                 target="https://www.rfc-editor.org/info/draft-trossen-detnet-rsvp-tsn">
        <front>
          <title>RSVP for TSN Networks</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
