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

Versions: 00 01 02

DeNet WG                                                      Quan Xiong
Internet-Draft                                                Jinghai Yu
Intended status: Standards Track                         ZTE Corporation
Expires: September 12, 2019                               March 11, 2019


                           DetNet QoS Policy
                    draft-xiong-detnet-qos-policy-01

Abstract

   This document proposes a Quality of Service (QoS) policy to apply
   Differentiated Services (DiffServ) model for Deterministic Networking
   (DetNet) and defines a DetNet DiffServ mechanism including DetNet IP
   and MPLS encapsulation.

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 September 12, 2019.

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




Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 1]


Internet-Draft              DetNet QoS Policy                 March 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  DetNet DiffServ Overview  . . . . . . . . . . . . . . . . . .   3
     2.1.  DetNet Classifiers  . . . . . . . . . . . . . . . . . . .   4
     2.2.  DetNet Traffic Conditioners . . . . . . . . . . . . . . .   4
       2.2.1.  Scheduler . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  Order . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  DetNet DSCP . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  DetNet PHB  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  DetNet Queuing  . . . . . . . . . . . . . . . . . . . . .   6
   3.  DetNet IP DiffServ Consideration  . . . . . . . . . . . . . .   6
   4.  DetNet MPLS DiffServ Consideration  . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Informative References  . . . . . . . . . . . . . . . . .   7
     8.2.  Normative References  . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   As defined in [I-D.ietf-detnet-architecture], Deterministic
   Networking (DetNet) provides a capability to carry specified unicast
   or multicast data flows for real-time applications with extremely low
   data loss rates and bounded latency.  DetNet and non-DetNet packets
   may be allowed to transmitted in the same network and more than one
   DetNet flows which has different priorities may be forwarded through
   the DetNet domain.  The DetNet Class of Service (CoS) should be taken
   into consideration to provide Quality of Service (QoS) for DetNet
   services.

   As discussed in [I-D.ietf-detnet-dp-sol-ip], Differentiated Services
   (DiffServ) can be used to provide traffic forwarding treatment for
   DetNet network.  The DiffServ architecture as specified in [RFC2475]
   defined a model that traffic entering a DiffServ domain is classified
   and conditioned at the boundaries and marked with a DiffServ Code
   Point (DSCP) defined in [RFC2474].  The DSCP is used at transit nodes
   to select the Per Hop Behavior (PHB) that determines the scheduling
   treatment.  And [RFC3270] provide a solution to support DiffServ for
   traffic marked with Traffic Class (TC) [RFC5462] transported over an
   MPLS network.






Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 2]


Internet-Draft              DetNet QoS Policy                 March 2019


   This document proposes a QoS policy to apply DiffServ model for
   DetNet network and defines a DetNet DiffServ mechanism including
   DetNet IP and MPLS encapsulation.

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

1.2.  Terminology

   The terminology is defined as [I-D.ietf-detnet-architecture],
   [RFC3270], [RFC2475] and [RFC2474].

2.  DetNet DiffServ Overview

   The DetNet network needs to be capable of supporting differentiated
   services dividing to one or more contiguous DiffServ domains.  The
   key components within a DiffServ domain including traffic
   classification and conditioning functions, and PHB-based forwarding.
   The customers may specify packet classification policy, traffic
   profiles and actions to DetNet flows which are in-profile or out-of-
   profile at the boundary.  The DiffServ domains may support different
   PHB groups internally and different codepoint->PHB mappings at the
   transit nodes.  The DetNet DiffServ process for packets is as
   Figure 1 shown.


                   +---------+
                   |  Meter  |-----------------------------------+
            +----->| (DetNet |------------------+                |
            |      | Profile)|--+               |                |
            |      +---------+  |               |                |
            |                   V               V                V
DetNet+------------+     +----------+     +------------+     +---------+
Flow  | Classifier |     |  Marker  |     |Shaper/Order|     | Queuing |
=====>| (DetNet    |====>| (DetNet  |====>|  Dropper/  |====>| (DetNet |
      |  BA/MF)    |     |  DSCP)   |     | Scheduler/ |     |  PHB)   |
      +------------+     +----------+     +------------+     +---------+

        Figure 1: Overview of a DetNet DiffServ mechanism









Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 3]


Internet-Draft              DetNet QoS Policy                 March 2019


2.1.  DetNet Classifiers

   As defined in [RFC2475], packet classifiers select packets in a
   traffic stream based on the information of packet header including
   two types of classifiers, the BA (Behavior Aggregate) and MF (Multi-
   Field) Classifier.  The difference is that the BA classifies packets
   based on the CoS field and the latter one based on more other header
   fields.

   In DetNet DiffServ model, BA and MF can be applied for packets
   classification.  After classification, the flows can be seperated
   from DetNet and non-DetNet.  As specified in
   [I-D.ietf-detnet-dp-sol-ip], no DetNet specific encapsulation is
   defined to support DetNet IP flow identification and DetNet service
   delivery.  So the DetNet IP classifiers is the same as defined in
   [RFC2474] and [RFC2475].  As defined in
   [I-D.ietf-detnet-dp-sol-mpls], DetNet service Label (S-Label) is used
   to identify a DetNet flow and forwarding labels (F-Labels) are used
   to provide LSP-based connectivity in DetNet MPLS header.  The S-Label
   and F-Labels can be used in combination with MPLS TC filed in MF
   classifier.  And DetNet MPLS BA classifier select packets based on
   the MPLS TC field only as defined in [RFC5462].

2.2.  DetNet Traffic Conditioners

   As mentioned in [I-D.ietf-detnet-architecture], DetNet flows can be
   shaped or scheduled.  The rate limiting of DetNet traffic and the
   starvation avoiding of non-DetNet traffic, e.g., at the ingress of
   the DetNet domain must be applied by traffic policing and shaping
   functions.  As [RFC2475] defined, the traffic conditioner may contain
   four elements: meter, marker, shaper and dropper.  Traffic
   conditioning performs metering, shaping, policing and/or re-marking
   to ensure the traffic which entering the DiffServ domain conforms to
   the service provisioning policy.

   In DetNet, the traffic policing and conditioning SHOULD include
   meter, marker, shaper, dropper, scheduler and order.  A meter with a
   DetNet Profile is used to measure the DetNet flows selected by a
   DetNet classifier and the result of the meter with respect to a
   packet may be used to trigger a DetNet action including a marking,
   shaping, dropping, scheduling or ordering.  A marker is used to set
   the Cos field of a DetNet packet to a DetNet DSCP (section 2.3),
   mapping the marked packet to a DetNet PHB.  A Shaper may apply
   specific shaping algorithms implemented by DetNet network, e.g.,
   credit-based shaper [IEEE802.1Qav].  A dropper is used to discard
   some of the non-DetNet packets to provide the QoS of the DetNet flows
   when congestion occurs.




Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 4]


Internet-Draft              DetNet QoS Policy                 March 2019


2.2.1.  Scheduler

   As decribed in [I-D.ietf-detnet-architecture], the DetNet flows can
   be scheduled to achieve time-based synchronization for scheduled
   traffic.  This document proposes a new type of action for DetNet
   traffic conditioning named Scheduler action.  A scheduler may apply
   specific scheduling and related Queuing algorithms implemented by
   DetNet network, e.g., Time-gated queues [IEEE802.1Qbv] and Cyclic
   Queuing and Forwarding [IEEE802.1Qch].

2.2.2.  Order

   As defined in [I-D.ietf-detnet-dp-sol-mpls], DetNet control word
   (d-CW) containing sequencing information for packet replication and
   duplicate elimination purposes.  Sequence Number is different packet-
   by-packet.  Based on Detnet MPLS date plane encapsulation, this
   document proposes a new type of action for DetNet traffic
   conditioning named order action which used to reorder the packets
   within a DetNet flow that are received out of order.

2.3.  DetNet DSCP

   The DetNet DSCP carried in CoS field in IP header and TC field in
   MPLS header may be uesd to mark packets at ingress nodes and select a
   DetNet PHB (section 2.4) at transit nodes.  DetNet DSCP MUST be
   defined to one or more particular values, which MUST be unique for
   codepoints in the standard space.

   [Ed.note: We need to define one or more DetNet DSCP values and
   related DetNet PHB for DetNet-specific treatment.]

2.4.  DetNet PHB

   As specified in [RFC2475], per-hop behaviors are defined to permit a
   reasonably granular means of allocating buffer and bandwidth
   resources at each node among competing traffic streams.  PHB groups
   will usually share a common constraint such as a packet scheduling or
   buffer management policy.  According to [RFC4594], Default Forwarding
   (DF) PHB, Assured Forwarding (AF) PHBs, Expedited Forwarding (EF) PHB
   and Class Selector (CS) PHBs have been defined to provide forwarding
   treatment.  These PHBs can be used to forward DetNet flows based on
   the requirement.

   This document defines a new type of Deterministic Networking (DN) PHB
   which is intended for traffic requiring extremely low data loss rates
   and bounded latency for DetNet.  The DN PHB may include a set of PHB
   classes, e.g., DN1,DN2,etc.  And the number of the class is the same
   with the DetNet DSCP values.  The DSCP in IP header and TC in MPLS



Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 5]


Internet-Draft              DetNet QoS Policy                 March 2019


   header should be mapped to DN PHB with the relevant PHB specification
   which may be completed in future discussion.

2.5.  DetNet Queuing

   As discussed in [I-D.ietf-detnet-architecture],the nodes in DetNet
   network shall queue each received packets to one of the potential
   transmission ports and provide storage for queued packets, awaiting
   to submit these for transmission.  A port provides one or more queues
   corresponding to the number of traffic classes.  The queuing
   mechanism should be configured and implemented to DetNet nodes.

   As defined in [RFC4594], Priority Queuing (PQ) was defined to queue
   the packets in priority sequence and Rate Queuing (RQ)selects packets
   according to the specified rate including Weighted Fair Queuing (WFQ)
   and Weighted Round Robin (WRR).  Active Queue Management (AQM) also
   be defined to use packet dropping or marking to manage the depth of a
   queue.

   As per IEEE 802.1 WG, queuing and transmission selection algorithms
   also can be used for queue scheduling in DetNet network.

3.  DetNet IP DiffServ Consideration

   As specified in [I-D.ietf-detnet-dp-sol-ip], no DetNet specific
   encapsulation is defined to support DetNet IP flow identification and
   DetNet service delivery.  So the DetNet IP classification is the same
   as defined in [RFC2474] and [RFC2475].  But the recommended DetNet
   DSCP may be uesd to mark packets to select a DetNet PHB and the
   transit nodes should implement mechanisms performing the PHB.  The
   mapping of DSCP to PHBs MUST be configurable.  Implementations should
   support the recommended codepoint-to-PHB mappings in their default
   configuration.

4.  DetNet MPLS DiffServ Consideration

   As defined in [I-D.ietf-detnet-dp-sol-mpls], DetNet S-Label and
   F-Labels can be used in combination with MPLS TC filed in MF
   classifier.  The BA classifier is the same with the [RFC3270].

   Two types of LSPs including Explicitly TC-encoded-PSC LSP (E-LSP) and
   Label-Only-Inferred-PSC LSP (L-LSP) follows the definition of
   [RFC3270] and can be used to support DetNet explicit routes in MPLS-
   TE LSP.  A E-LSP can be used to support one or more DetNet flows and
   a L-LSP can be established for one flow.  E-LSP and L-LSP can use a
   signaled TC->PHB mapping to forward packets whose corresponding PHBs
   are defined in this document.




Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 6]


Internet-Draft              DetNet QoS Policy                 March 2019


   In DetNet MPLS network, DetNet Layer Two Service is supported in TSN
   over MPLS.  The LSP egressing over egde nodes can use the
   preconfigured PHB->802.1 mapping as defined in [RFC3270].

   As specified in [RFC3270], there may be more than one LSP carrying
   the same flow.  Two or more LSPs can be merged into one LSP at one
   egressing LSR.  It can be used to perform the packet replication
   (PRF) at ingress nodes and the packet elimination (PEF) at the egress
   nodes in DetNet DiffServ model.  The order action which defined in
   this document can be used for packet ordering functionality (POF).

5.  Security Considerations

   TBD.

6.  IANA Considerations

   TBD.

7.  Acknowledgements

   TBD.

8.  References

8.1.  Informative References

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

8.2.  Normative References

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

   [I-D.ietf-detnet-dp-sol-ip]
              Korhonen, J. and B. Varga, "DetNet IP Data Plane
              Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in
              progress), October 2018.

   [I-D.ietf-detnet-dp-sol-mpls]
              Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
              Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in
              progress), October 2018.



Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 7]


Internet-Draft              DetNet QoS Policy                 March 2019


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

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
              Protocol Label Switching (MPLS) Support of Differentiated
              Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
              <https://www.rfc-editor.org/info/rfc3270>.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              DOI 10.17487/RFC4594, August 2006,
              <https://www.rfc-editor.org/info/rfc4594>.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <https://www.rfc-editor.org/info/rfc5462>.

Authors' Addresses

   Quan Xiong
   ZTE Corporation
   No.6 Huashi Park Rd
   Wuhan, Hubei  430223
   China

   Phone: +86 27 83531060
   Email: xiong.quan@zte.com.cn


   Jinghai Yu
   ZTE Corporation
   50 Software Avenue, YuHuaTai District
   Nanjing, Jiangsu  210012
   China

   Phone: +86 025 26774049
   Email: yu.jinghai@zte.com.cn




Quan Xiong & Jinghai YuExpires September 12, 2019               [Page 8]


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