DeNet WG Q. Xiong
Internet-Draft J. Yu
Intended status: Standards Track ZTE Corporation
Expires: May 4, 2020 P. Liu
F. Qin
China Mobile
November 1, 2019

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

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 May 4, 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 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

As defined in [RFC8655], 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-mpls] and [I-D.ietf-detnet-ip], Differentiated Services (DiffServ) can provide traffic forwarding treatment for DetNet networks. 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.

This document proposes a QoS policy to apply DiffServ model for DetNet networks 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 [RFC8655], [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
   
   

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-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-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 [RFC8655], 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.

2.2.1. Scheduler

As decribed in [RFC8655], 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-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 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 [RFC8655],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-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-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.

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.

8.2. Normative References

[I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S. and J. Korhonen, "DetNet Data Plane: IP", Internet-Draft draft-ietf-detnet-ip-03, October 2019.
[I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S. and J. Korhonen, "DetNet Data Plane: MPLS", Internet-Draft draft-ietf-detnet-mpls-03, October 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[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.
[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.
[RFC4594] Babiarz, J., Chan, K. and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006.
[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.
[RFC8655] Finn, N., Thubert, P., Varga, B. and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019.

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
Peng Liu China Mobile Beijing, 100053 China EMail: liupengyjy@chinamobile.com
Fengwei Qin China Mobile Beijing, China EMail: qinfengwei@chinamobile.com