Network Working Group Y. Zha
Internet Draft Y. Jiang
Intended status: Informational Huawei Technologies
Expires: September 2017 L. Geng
China Mobile
March 13, 2017
Deterministic Networking Flow Information Model
draft-zha-detnet-flow-info-model-02
Abstract
Deterministic Networking (DetNet) provides end-to-end absolute
delay and loss guarantee to serve real-time applications. DetNet
is focused on a general approach that use techniques such as 1)
data plane resources reservation for DetNet flows; 2) providing
fixed path for DetNet flows; 3)sequentializng, replicating, and
eliminating duplicate packets transmission [draft-ietf-detnet-
architecture-00] to guarantee the worst case delay of DetNet flow
while allow sharing among best effort traffic. Data flow
information model is important to the DetNet work that it defines
information be used by flow establishment and control protocols.
This document describes and DetNet flow information model that
represents the flow identifier, traffic description information so
that can make resource reservation and provide differentiate
service.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Zha, et al. Expires September 13 2017 [Page 1]
Internet-Draft DetNet Flow Info Model March 2017
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 13, 2017.
Copyright Notice
Copyright (c) 2014 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
(http://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 ................................................2
2. Conventions used in this document ............................3
3. DetNet Flow Information Model ................................4
3.1. Flow Identifier .........................................4
3.1.1. Layer 2 Flow Identification ........................5
3.1.2. Layer 3 Flow Identification ........................6
3.2. Transport Layer Information .............................6
3.3. Flow Traffic Description ................................7
3.3.1. Traffic Type .......................................9
3.3.2. Traffic Shaping ....................................9
3.4. Flow Statistics ........................................10
4. Use of Flow Information Model ...............................11
4.1. Mapping of Flow Information ............................11
4.2. Data Plane Configuration ...............................12
5. Security Considerations .....................................13
6. IANA Considerations .........................................13
7. Acknowledgments .............................................14
8. References ..................................................14
8.1. Normative References ...................................14
8.2. Informative References .................................14
1. Introduction
Deterministic service with both assured delay and data loss is
promising to service providers. Due to lack of deterministic
Zha, et al. Expires September 13 2017 [Page 2]
Internet-Draft DetNet Flow Info Model March 2017
service provisioning mechanism there is no guarantee when
deploying a time critical service [RFC3393]. Deterministic
Networking (DetNet) tries to provide a solution to this issue with
limited scope that the data flows are constrained with some
maximum data rate properties. DetNet delivers assured end-to-end
latency and packet loss by dedicating network resources to DetNet
flows while unused reserved resource are still open to best effort
traffic.
In order to reserve proper amount of network resource to serve the
DetNet flow, the DetNet flow first needs to be described with such
parameters that can be understood by the network. Secondly,
current flow description and resource reservation are mainly
focused on bandwidth which is basically a statistical concept
during a relative long observation interval. And also, there are
different type of use cases those requires deterministic
networking services. All these use cases may send different kind
of traffics to the network with different deterministic service
provisioning requirements [draft-ietf-detnet-use-cases-11].
Data plane techniques such as queuing, shaping, scheduling and
preemption are configured in a standard way to guarantee
deterministic forwarding behavior in the network device. The
controller or control plane takes the description of the DetNet
flow and then translates into data plane level configuration to
serve the flow. This is the key of DetNet as to define how to
describe DetNet flow and how to reserve network resource for it.
The flow description should be focused on traffic characteristics
of real time service with parameters that could be converted to
device level configurations.
An information model defines concepts in a uniform way, enabling
formal mapping processes to be developed to the information model
to a set of data models. This simplifies the process of
constructing software to automate the policy management process.
It also simplifies the language generation process, though that is
beyond the scope of this document.
This document describes an information model for representing
DetNet flow with comment concept and parameters of a DetNet
service that can be mapped into device level configurations.
2. Conventions used in this document
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].
Zha, et al. Expires September 13 2017 [Page 3]
Internet-Draft DetNet Flow Info Model March 2017
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to
be interpreted as carrying [RFC2119] significance.
3. DetNet Flow Information Model
According to current charter, DetNet information model is to
identify the information needed for flow establishment and control
and be used by reservation protocols and data plane configuration.
The work will be independent from the protocol(s) used to control
the flows. The DetNet information model presented in this document
defines some common concept of DetNet flows with information that
can be used for flow identification, flow monitoring, performance
management, reservation protocol, and data plane configuration.
For example, deterministic properties of controlled latency, low
packet loss, low packet delay variation, and high reliability.
More information can be added in the future. And each part of the
information model can be used individually by different network
function or network entities. The DetNet information model only
defines what kind of information is needed and how it could be
used. Data repository, data definition language, query language,
implementation language, and protocol should not be defined here.
More specifically, the information model can be used by a data
model for different scenarios. In [RFC3198], data model is "A
mapping of the contents of an information model into a form that
is specific to a particular type of data store or repository."
In this document, DetNet information model contains three sets of
information, flow identifier information, flow metering statistics,
and traffic description.
3.1. Flow Identifier
Flow identifier is the first step of flow description as DetNet
requires differentiate service so flow needs to be identified by
the data plane. The DetNet service is described at flow level so
each flow could have unique flow identifier.
Zha, et al. Expires September 13 2017 [Page 4]
Internet-Draft DetNet Flow Info Model March 2017
+--------+
| DetNet | --------+ +---------+
| Sender |----\ /--- |||||---| |
+--------+ \ +-----------+ / --------+ |Trans- |
\ | DetNet |/ DetNet Queue |mission |
---| Classifier|\ |Selection|---
+-----------+ / +-----------+ \ --------+ | |
|Best Effort| / \--- ||||||||---| |
| Sender |-/ --------+ +---------+
+-----------+ Best Effort Queue
Figure 1. DetNet Flow Being Classified
As shown in figure 1, network reserves dedicate resource for
DetNet flows which will be identified first to use the resource.
So a DetNet flow model should first contain information for flow
identification. As defined in [draft-ietf-detnet-architecture-00]
draft, deterministic service can be applied to both layer 2 and
layer 3 network, such as IP routing, MPLS labeling and Ethernet
bridging, flow identifier information is needed for both layers.
3.1.1. Layer 2 Flow Identification
Different flow indentifying technique may be used for different
networks. DetNet provides layering flow identification models that
can be used for both high layer and low layer. In [802.1qcc],
flow identification in layer 2 is usually by mac address plus
unique flow ID within the network domain. In access network which
is usually layer 2 network, flow is identified by Vlan and MAC
address.
+--------------+--------------+
| Name | Elements |
+--------------+--------------+
| | Source |
| | MacAddress |
| +--------------+
| | Destination |
|Flow | MacAddress |
|Identifier +--------------+
| | VlanID |
| +--------------+
| | UniqueID |
+--------------+--------------+
Zha, et al. Expires September 13 2017 [Page 5]
Internet-Draft DetNet Flow Info Model March 2017
3.1.2. Layer 3 Flow Identification
In IP/MPLS network, flow identification in layer 3 is needed. For
example, a LSP is setup to forward packets destined to particular
IP address. If both DetNet flow and non-DetNet flow is sending to
same destination, how to provide differentiate service becomes
problem. First, the preliminary solution can be just provide
DetNet service at user level, which means assuming traffic from
particular source should be all performance guaranteed. Second,
put additional label for per flow identification.
+--------------+--------------+
| Name | Elements |
+--------------+--------------+
| | Protocol |
| +--------------+
| | Source |
| | portID |
| +--------------+
| | Destination |
|Flow | portID |
|Identifier +--------------+
| | Source |
| | IpAddress |
| +--------------+
| | Destination |
| | IpAddress |
| +--------------+
| | UniqueID |
+--------------+--------------+
3.2. Transport Layer Information
Since flow model is used and being mapped between multiple layers,
transport information is also mandatory. UDP flow and TCP flow
apparently have absolute different traffic behavior and working
mechanism which lead to different resource reservation scheme as
well as forwarding features. So the source tells the network
transport information of the flow it is going to send, e.g.,
protocols related information. More details will be provided in
next version.
Zha, et al. Expires September 13 2017 [Page 6]
Internet-Draft DetNet Flow Info Model March 2017
+--------------+----------------------+
| Name | Elements |
+--------------+----------------------+
| | udpSourcePort |
|UDP +----------------------+
| | udpDestinationPort |
|--------------+----------------------+
| | tcpSourcePort |
| +----------------------+
| | tcpDestinationPort |
|TCP +----------------------+
| | tcpWindowScale |
| +----------------------+
| | tcpWindowSize |
+--------------+----------------------+
3.3. Flow Traffic Description
The information model should contain traffic description
information to define the traffic profile from the source. DetNet
flow defines the source guarantee that is the promise of source
that the maximum amount traffic it can send. It is a kind of
contract between the source and network who serve the flow. If the
source is sending overload or different type of traffic, the
overload or traffic does not match the predefined traffic profile
will be not guaranteed. So the DetNet is that the source tells the
network "I will send the traffic like this", and the network will
reserve the resource for the flow based on its traffic
characteristics as defined in the model.
Unlike previous flow model or traffic profile which is mainly
based on bandwidth of service, DetNet flow should be more accurate
and at lower level for deterministic forwarding. For DetNet
service provisioning which is focused on absolute worst case delay,
the network needs to know not only the number of packets the flow
will be sending but also when or during what period of time the
source will be sending what amount of packets. Based on the
architecture draft, there are two kinds of flows, synchronous one
and asynchronous one. The information model of the DetNet flow
with traffic description information is shown as below.
Zha, et al. Expires September 13 2017 [Page 7]
Internet-Draft DetNet Flow Info Model March 2017
+--------------+--------------+
| Name | Elements |
+--------------+--------------+
| | Guaranteed |
| +--------------+
| | RealTime |
|ServiceType +--------------+
| | Mux |
|--------------+--------------+
|QoS | |
|--------------+--------------+
|MTU | |
+--------------+--------------+
|Bandwidth | |
+--------------+--------------+
|Burst | |
|Periodic | |
+--------------+--------------+
|PeriodValue | |
+--------------+--------------+
| |BurstID |
| +--------------+
| |BurstLegnth |
| +--------------+
|Burst |MaxFrames |
| +--------------+
| |MaxFrameSize |
| +--------------+
| |StartTime |
| +--------------+
| |EndTime |
+--------------+--------------+
The basic idea is that the flow consists of a list of bursts. The
Burst is a set of packets with burst duration. The burst is close
related to service traffic pattern and also it is dependent on the
data plane technique.
There are two basic requirements for traffic information
definition, first it can be used to describe service; second the
parameter defined here can be mapped to data plane configuration.
Zha, et al. Expires September 13 2017 [Page 8]
Internet-Draft DetNet Flow Info Model March 2017
3.3.1. Traffic Type
Back to ATM era, when service wants to send traffic to a broadband
network, it must inform network with information about what kind
of traffic it is going to send as well as the performance
requirements. DetNet provides absolute service guarantee for
limited amount traffic, so the network also requires the
information of traffic of the flow, such as constant rate flow,
vibrate rate flow or unspecified. Then the network can make
appropriate resource reservation for specific flow. E.g., for a
VBR flow, peak rate can be 3-7 times over sustained rate which
lead to sophisticated reservation scheme.
+---------------+--------------+
| Name | Elements |
+---------------+--------------+
| | CBR |
| +--------------+
|TrafficType | VBR |
| +--------------+
| | UBR |
|---------------+--------------+
3.3.2. Traffic Shaping
As mentioned above, DetNet service only guarantee limited traffic
with bounded delay. It is usually not easy to regulate source
behavior when sending traffic, so shaping is necessary in DetNet
working system. Meanwhile, only DetNet traffic that follows the
predefined traffic behavior will be served properly, those
overloaded will not be guaranteed.
On the other hand, shaping procedure as one of the necessary
working components needs to de standardized for deterministic
delay provisioning. Network or control plane needs to know how the
shaping, queuing and scheduling is performed to calculate delay.
As shaping and queuing in DetNet is a per-flow based, the flow
model contains information about shaping information.
There are two commonly used shapers, leaky bucket and token bucket.
Leaky bucket is defined to limit both bandwidth and burstiness of
packet transmission and is recommended for ATM network with
constant output rate. There are multiple implementations of leaky
bucket, below is a set of parameters for one leaky bucket model.
Zha, et al. Expires September 13 2017 [Page 9]
Internet-Draft DetNet Flow Info Model March 2017
Token bucket, on the other hand is a shaping and policing model
used for many protocols such as RSVP. Below is a Two-Parameter
Token Bucket [RFC 3290].
+--------------+--------------+
| Name | Elements |
+--------------+--------------+
| | BufferSize |
| +--------------+
|Leaky Bucket | InputRate |
| +--------------+
| | OutputRate |
| +--------------+
| | InitialBuffer|
|--------------+--------------+
| | Burst |
|Token Bucket +--------------+
| | TokenRate |
+--------------+--------------+
3.4. Flow Statistics
As a matter of fact, there is no mechanism to provide flow delay
and loss parameter, which is also important for DetNet service.
Keeping the knowledge of flow-based delay and loss information is
also crucial for OAM and fault management.
The detail of flow metering statistic information in the
information model will be proposed in next version.
+--------------+--------------+
| Name | Elements |
+--------------+--------------+
|MaxDelay | |
|--------------+--------------+
|MaxPacketLoss | |
+--------------+--------------+
| | FlowStart |
|TimeStamp +--------------+
| | FlowEnd |
|--------------+--------------+
Zha, et al. Expires September 13 2017 [Page 10]
Internet-Draft DetNet Flow Info Model March 2017
4. Use of Flow Information Model
As defined in current charter, DetNet flow information model is
used for flow establishment and control and can also be used by
reservation protocols and YANG data models.
4.1. Mapping of Flow Information
This section proposes a way to map information model parameters
into network configuration. [802.1qcc] defined stream reservation
protocols in layer 2 network with deterministic characteristics.
DetNet works on layer 3, which will not be covered by 802.1qcc.
Figure 2 shows that, DetNet flow model is used to configure the
DetNet network, e.g., TSN network. Some of the flow information
defined in this model is mapped in to 802.1qcc parameters to
configure TSN domain.
+---------------------------------+
| DetNet Flow Model |
+---------------------------------+
V V
V V
+---------------+ V
| TSN Network | V
| Configuration | V
+---------------+ V
| 802.1qcc | V
____ | | V
/ \ | | V
/ \____V___________ | V
____/ \ | V _
/ \V________________ _V___/ \
| +------+ +---+ +---+ +--------+ \ / \_
| |Talker|=====|NE |=========|NE |===|Listener| | | \
\ +------+ +---+ +---+ +--------+ | \_ /
\ ______ / \______/
\ / \ /
\_________/ \_______________Domain 1_/ Domain 2
Figure 2. DetNet Flow Model to TSN Configuration
Zha, et al. Expires September 13 2017 [Page 11]
Internet-Draft DetNet Flow Info Model March 2017
4.2. Data Plane Configuration
As defined in current charter, the DetNet data plane should be TSN
compatible. Take TSN TAS (Time Aware Shaper) for example, the
information defined in the flow model can be mapped to data plane
parameter to configure TSN time aware shaper that provides a
deterministic forwarding behavior for the flow.
As defined in previous section, information model contains traffic
description of DetNet flow that can be used to configure data
plane. In this section, take TSN time aware shaper as an example
for data plane technique, mapping of data flow parameter to TAS
configuration is presented.
The basic idea is that, the controller or network control plane
takes data flow traffic description as the request and compute the
associated time interval and control list of the TAS gate control
function. Data flow model contains timing information of the
DetNet flow as it arrives at T1 and ends at T2, which can be
mapped into control list of TAS to reserve an open gate for the
DetNet flow for time period T1 to T2. As shown in figure 2, a
DetNet flow with data traffic between T1 and T2 send the request
to controller or control plane, and then the control plane uses
the information to configure the TAS based on current status of
TAS. Finally, the TAS function being configured with control list
update for open gate transmission for this flow during T1 and T2.
As a result, ideally, the flow will be transmitted immediately
using the dedicated open gate time slot with absolute delay and
loss guarantee.
Zha, et al. Expires September 13 2017 [Page 12]
Internet-Draft DetNet Flow Info Model March 2017
T1 T2 DetNet data flow
+---------------+ /___________\ Traffic description
|Data flow model| \ /
+---------------+ |||||||||||||
| |
| |
\ /
+---------------+
| Control Plane |
+---------------+
/ \
| |
\ /
+-----------------------------+ Control List
| Time Aware Shaper | T0 CCCCCCCO
| | T1 OCCCCCCC
| --------+ +----+ +---------+| T2 CCCCCCCO
| |||||-|Gate|-| || .
| --------+ +----+ | || .
|DetNet Queue |Trans- || .
| . |mission || Tn CCCCCCCC
| . |Selection||
| . | ||
| --------+ +----+ | ||
| |||||-|Gate|-| ||
| --------+ +----+ +---------+|
|Best Effort |
|Queue |
+-----------------------------+
Figure 3. Mapping of Flow Model into TAS Configuration
5. Security Considerations
TBD
6. IANA Considerations
This document has no actions for IANA.
Zha, et al. Expires September 13 2017 [Page 13]
Internet-Draft DetNet Flow Info Model March 2017
7. Acknowledgments
This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in
alphabetical order: Jinchun Xu and Hengjun Zhu.
8. References
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP
Performance Metrics (IPPM) ", RFC 3393, November 2002.
[RFC3290] Y. Bernet, "An Informal Management Model for Diffserv
Routers", RFC 3290, May 2002.
8.2. Informative References
[draft-ietf-detnet-use-cases-11]
Grossman, E., et al. "Deterministic Networking Problem Statement",
draft draft-ietf-detnet-use-cases-11 (work in progress), October
2016.
[draft-ietf-detnet-architecture-00]
Finn, N., Thubert, P., and M. Teener, "Deterministic Networking
Architecture", draft-ietf-detnet-architecture-00 (work in
progress), October 2016.
[802.1qcc]
IEEE 802.1Qcc, Draft 1.2, Mar 2017.
Zha, et al. Expires September 13 2017 [Page 14]
Internet-Draft DetNet Flow Info Model March 2017
Authors' Addresses
Yiyong Zha
Huawei Technologies
Email: zhayiyong@huawei.com
Yuanlong Jiang
Huawei Technologies
Email: jiangyuanlong@huawei.com
Liang Geng
China Mobile
Email: gengliang@chinamobile.com
Zha, et al. Expires September 13 2017 [Page 15]