[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            X. Geng
Internet-Draft                                                   M. Chen
Intended status: Experimental                                     Huawei
Expires: January 5, 2020                                          F. Qin
                                                            China Mobile
                                                           July 04, 2019


                     DetNet Control Plane Framework
                   draft-geng-detnet-control-plane-00

Abstract

   This document defines DetNet control plane framework.  It specifies
   the guidance of DetNet control plane implementation.

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

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 January 5, 2020.

Copyright Notice

   Copyright (c) 2019 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



Geng, et al.             Expires January 5, 2020                [Page 1]


Internet-Draft              Abbreviated-Title                  July 2019


   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
   2.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  DetNet Control Plane Classification . . . . . . . . . . . . .   3
     3.1.  Fully Distributed Control Plane . . . . . . . . . . . . .   3
     3.2.  Fully Centralized Control Plane . . . . . . . . . . . . .   3
     3.3.  Hybrid Control Plane  . . . . . . . . . . . . . . . . . .   4
   4.  DetNet Control Plane Considerations . . . . . . . . . . . . .   5
     4.1.  Explicit Route  . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Resource Reservation  . . . . . . . . . . . . . . . . . .   6
     4.3.  Seamless Redundancy . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Deterministic Networking (DetNet) provides the capability to carry
   specified unicast or multicast data flows for real-time applications
   with extremely low data loss rates and bounded latency within a
   network domain.  As discussed in the Deterministic Networking
   Architecture[I-D.ietf-detnet-architecture], Techniques used to
   provide this capability include reserving data plane resources for
   individual (or aggregated) DetNet flows in some or all of the
   intermediate nodes along the path of the flow, providing explicit
   routes for DetNet flows, and distributing data from DetNet flow
   packets over time and/or space to ensure delivery of each packet's
   data in spite of the loss of a path.

   All these DetNet specific technologies need support of protocal from
   both data plane and control plane.

   DetNet data plane framework is defined in
   [I-D.ietf-detnet-data-plane-framework].  This document defines DetNet
   control plane framework.  It specifies the guidance of DetNet control
   plane implementation.






Geng, et al.             Expires January 5, 2020                [Page 2]


Internet-Draft              Abbreviated-Title                  July 2019


2.  Terminologies

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

   Terminologies for DetNet go along with the definition in
   [I-D.ietf-detnet-architecture].

3.  DetNet Control Plane Classification

   This section defines three classes of DetNet control plane: fully
   distributed control plane, fully centralized control plane, hybrid
   control plane, based on different network architectures, showing how
   configuration information exchanges between various entities in the
   network.

3.1.  Fully Distributed Control Plane

   In a fully distributed configuration model, UNI information is
   transmitted over DetNet UNI protocol from the user side to the
   network side; then UNI information and network configuration
   information propagate in the network over distributed control plane
   protocol.  For example:

   1) IGP collects topology information and DetNet capabilities of
   network([I-D.geng-detnet-info-distribution]);

   2) Control Plane of the Edge Node(Ingress) receives a flow
   establishment request from UNI and calculates a/some valid path(s);

   3) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
   explicit route.  After receiving the PATH message, the other Edge
   Node(Egress) sends a Resv message with distributed label and resource
   reservation request.

   Current distributed control plane protocol,e.g., RSVP-TE[RFC3209],
   SRP[IEEE802.1Qcc], can only reserve bandwidth along the path, while
   the configuration of a fine-grained schedule, e.g.,Time Aware
   Shaping(TAS) defined in [IEEE802.1Qbv], is not supported.

3.2.  Fully Centralized Control Plane

   In the fully centralized configuration model, UNI information is
   transmitted from Centralized User Configuration (CUC) to Centralized
   Network Configuration(CNC).  Configurations of routers for DetNet
   flows are performed by CNC with network management protocol.  For
   example:



Geng, et al.             Expires January 5, 2020                [Page 3]


Internet-Draft              Abbreviated-Title                  July 2019


   1) CNC collects topology information and DetNet capability of network
   through Netconf;

   2) CNC receives a flow establishment request from UNI and calculates
   a/some valid path(s);

   3) CNC configures the devices along the path for flow transmission.

3.3.  Hybrid Control Plane

   In the hybrid configuration model, controller and control plane
   protocols work together to offer DetNet service, and there are a lot
   of possible combinations.  For example:

   1) CNC collects topology information and DetNet capability of network
   through IGP/BGP-LS;

   2) CNC receives a flow establishment request from UNI and calculates
   a/some valid path(s);

   3) Based on the calculation result, CNC distributes flow path
   information to Edge Node(Ingress) and other information(e.g.
   replication/elimination) to the relevant nodes.

   4) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
   explicit route.  After receiving the PATH message, the other Edge
   Node(Egress) sends a Resv message with distributed label and resource
   reservation request.

   or

   1) Controller collects topology information and DetNet capability of
   network through IGP/BGP-LS;

   2) Control Plane of Edge Node(Ingress) receives a flow establishment
   request from UNI;

   3) Edge Node(Ingress) sends the path establishment request to CNC
   through PCEP;

   4) After Calculation, CNC sends back the path information of the flow
   to the Edge Node(Ingress) through PCEP;

   5) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
   explicit route.  After receiving the PATH message, the other Edge
   Node(Egress) sends a Resv message with distributed label and resource
   reservation request.




Geng, et al.             Expires January 5, 2020                [Page 4]


Internet-Draft              Abbreviated-Title                  July 2019


   There are also other variations that can be included in the hybrid
   control plane.  This draft can not coverer all the control plane data
   needed in hybrid configuration models.  Every solution has there own
   mechanism and corresponding parameters to make it work.

4.  DetNet Control Plane Considerations

   This section gives general instructions about how to implement
   different DetNet technologies in control plane.  New requirements for
   the current protocal are highlighted.

4.1.  Explicit Route

   Explicit Route is required in DetNet to provide stable transport
   service and guarante that DetNet service is not effected when the
   network topology changes.  The following features are necessary to
   have explicit route in DetNet:

   o  Path Computation

   Explicit path for DetNet is supposed to meet the SLA(Service Level
   Agreement) requirement or resource guarantee from the application/
   client, which include: bandwidth, maximum end-to-end delay, maximum
   end-to-end delay variation, maximum loss ratio and so on.  In an
   distributed system with IGP-TE, CSPF(Contstraint Shortest Path First)
   can be used to compute a set of feasible paths for a DetNet Service.
   In a system with a network controller, PCE(Path Computation Engine)
   can compute paths satisfying the requirements of DetNet with the
   network information collected from the DetNet domain.

   o  Setting up a path

   After choosing a path that meets the requirement, an explicit path is
   supposed to set up in a DetNet domain.  DetNet flows are steered
   through the network along their allocated path.  RSVP-TE can be used
   to set up a path with flow identification.  The packets with the flow
   identification would be routed as the RSVP-TE specifies.  Segment
   Routing is another option and no flow status is needed excepct for
   the ingress node.  SR policy is insterted into the packet at the
   ingress node and the packet .

   o  Strict or Loose

   An explicit path is strict when every intermidate hop is specified so
   that its route can't change.  An explicit path is loose when any IGP
   route is allowed along the path.  Generally, end-to-end SLA guarantee
   needs a strict explicit in DetNet.  However, when the IGP route is




Geng, et al.             Expires January 5, 2020                [Page 5]


Internet-Draft              Abbreviated-Title                  July 2019


   known and can meet the SLA requirement, Loose explicit path is also
   acceptable.

4.2.  Resource Reservation

   Congestion could cause uncontrolled delay and packet loss.  DetNet
   flows are supposed to be protected from congestion, so enough
   resource reservation for DetNet service is necessary.  Resource in
   the network is complex and hard to quantize, for example: packet
   processing resource, buffer size, port bandwidth and so on.  The
   resource a flow occupies is determined by the flow characteristics.

   o  Resource Allocation

   Port bandwidth is one of the basic attributes of the network device
   which is easy to get and calculate.  In the current implementation,
   network resource allocation means bandwidth allocation.  DetNet flow
   is characterized with traffic specification, which is defined in
   [I-D.ietf-detnet-flow-information-model] , including : Interval, Max
   Packets Per Interval and Max Payload Size.  Flow rate is the an
   average value, while traffic specification describes the worst case
   of the traffic.  And time concept is introduced in traffic
   spefication.The resource reservation in DetNet can be worst-case
   bandwidth reservation, and avoid confiction in an interval may also
   be considered.  Buffer resource is also in the scope to avoid packet
   loss when the buffer is not enough.

   o  Device Configuration with or withour Flow Discrimination

   The resouce allocation is guaranteed by device configuration.  For
   example, the value of output port bandwidth reservation can be
   configured as the parameter of queue management and scheduling
   algorithm.  When the DetNet flows are aggregated, a group of DetNet
   flows shared the allocated resource in the network device.  When the
   DetNet flows are treated independently, the device should maintains a
   mapping relationship between DetNet flows and its corresponding
   resource.

4.3.  Seamless Redundancy

   Seamless Redundancy is guaranteed by the packet replication and
   elimination.  The flow is replicated and go through parallel paths to
   avoid packet loss caused by device failure.  The network device
   should

   o  Explicit Path





Geng, et al.             Expires January 5, 2020                [Page 6]


Internet-Draft              Abbreviated-Title                  July 2019


   The current signalling that can set up an explicit path, as mentioned
   above like RSVP-TE or Segment Routing, can support an P2P or P2MP
   path.  Seamless Redundancy requires P2MP2P path.  Protocal extentions
   are required to support this new feature.

   o  Flow Identification and Sequence Number

   The nodes that execute Packet Replication or Elmination are supposed
   to identify different DetNet flows and the nodes that execute Packet
   Elimination are supposed to discriminate packets in one DetNet flow.
   The flow identification and the rule of the sequence number should be
   specified in the relay nodes by distributed signalling or a
   centralized controller.

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Security Considerations

   TBD

7.  Acknowledgements

   TBD

8.  Normative References

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-13 (work in progress), May 2019.

   [I-D.ietf-detnet-data-plane-framework]
              Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
              Bryant, S., and J. Korhonen, "DetNet Data Plane
              Framework", draft-ietf-detnet-data-plane-framework-00
              (work in progress), May 2019.

   [I-D.ietf-detnet-flow-information-model]
              Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet
              Flow Information Model", draft-ietf-detnet-flow-
              information-model-03 (work in progress), March 2019.





Geng, et al.             Expires January 5, 2020                [Page 7]


Internet-Draft              Abbreviated-Title                  July 2019


   [IEEE802.1Qcc]
              IEEE, "IEEE, "Stream Reservation Protocol (SRP)
              Enhancements and Performance Improvements (IEEE Draft
              P802.1Qcc)", 2017,
              <http://www.ieee802.org/1/files/private/cc-drafts/>.".

   [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]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

Authors' Addresses

   Xuesong Geng
   Huawei


   Mach(Guoyi) Chen
   Huawei


   Fengwei Qin
   China Mobile

   Email: qinfengwei@chinamobile.com





















Geng, et al.             Expires January 5, 2020                [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/