draft-ietf-detnet-flow-information-model-13.txt   draft-ietf-detnet-flow-information-model-14.txt 
DetNet B. Varga DetNet B. Varga
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: June 16, 2021 R. Cummings Expires: July 28, 2021 R. Cummings
National Instruments National Instruments
Y. Jiang Y. Jiang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
D. Fedyk D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
December 13, 2020 January 24, 2021
DetNet Flow Information Model DetNet Flow and Service Information Model
draft-ietf-detnet-flow-information-model-13 draft-ietf-detnet-flow-information-model-14
Abstract Abstract
This document describes flow and service information model for This document describes flow and service information model for
Deterministic Networking (DetNet). These models are defined for IP Deterministic Networking (DetNet). These models are defined for IP
and MPLS DetNet data planes and MPLS DetNet data planes
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2021. This Internet-Draft will expire on July 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 45 skipping to change at page 3, line 45
required by Detnet services. required by Detnet services.
The DetNet Architecture treats the DetNet related data plane The DetNet Architecture treats the DetNet related data plane
functions decomposed into two sub-layers: a service sub-layer and a functions decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide forwarding sub-layer. The service sub-layer is used to provide
DetNet service protection and reordering. The forwarding sub-layer DetNet service protection and reordering. The forwarding sub-layer
provides resource allocation (to ensure low loss, assured latency, provides resource allocation (to ensure low loss, assured latency,
and limited out-of-order delivery) and leverages Traffic Engineering and limited out-of-order delivery) and leverages Traffic Engineering
mechanisms. mechanisms.
In the IETF DetNet service utilizes IP or MPLS and DetNet is DetNet service utilizes IP or MPLS and DetNet is currently defined
currently defined for IP and MPLS networks as shown in Figure 1 based for IP and MPLS networks as shown in Figure 1 based on Figure 2 and
on Figure 2 and Figure 3 of [RFC8938]. IEEE 802.1 Time Sensitive Figure 3 of [RFC8938]. IEEE 802.1 Time Sensitive Networking (TSN)
Networking (TSN) utilizes Ethernet and is defined over Ethernet utilizes Ethernet and is defined over Ethernet networks. A DetNet
networks. A DetNet flow includes one or more App-flow(s) as payload. flow includes one or more App-flow(s) as payload. App-flows can be
App-flows can be Ethernet, MPLS, or IP flows, which impacts which Ethernet, MPLS, or IP flows, which impacts which header fields are
header fields are utilized to identify a flow. DetNet flows are utilized to identify a flow. DetNet flows are identified by the
identified by the DetNet encapsulation of App-flow(s) (e.g., MPLS DetNet encapsulation of App-flow(s) (e.g., MPLS labels, IP 6-tuple
labels, IP 6-tuple etc.). In some scenarios App-flow and DetNet flow etc.). In some scenarios App-flow and DetNet flow look similar on
look similar on the wire (e.g., L3 App-flow over a DetNet IP the wire (e.g., L3 App-flow over a DetNet IP network).
network).
+-----+ +-----+
| TSN | | TSN |
+-------+ +-+-----+-+ +-------+ +-+-----+-+
| DN IP | | DN MPLS | | DN IP | | DN MPLS |
+--+--+----+----+ +-+---+-----+-+ +--+--+----+----+ +-+---+-----+-+
| TSN | DN MPLS | | TSN | DN IP | | TSN | DN MPLS | | TSN | DN IP |
+-----+---------+ +-----+-------+ +-----+---------+ +-----+-------+
Figure 1: DetNet Service Examples as per Data Plane Framework Figure 1: DetNet Service Examples as per Data Plane Framework
skipping to change at page 5, line 24 skipping to change at page 5, line 24
v | | v | |
+-+ | v Network +-+ | v Network
+-+ v +-+ nodes +-+ v +-+ nodes
+-+ +-+ +-+ +-+
+-+ +-+
Figure 2: Usage of Information models (flow, service and Figure 2: Usage of Information models (flow, service and
configuration) configuration)
DetNet flow and service information model is based on [RFC8655] and DetNet flow and service information model is based on [RFC8655] and
on the concept of data model specified by [IEEE8021Qcc]. on the concept of data model specified by [IEEE8021Qcc]. In addition
Furthermore, the DetNet flow and service information models described to the TSN data model, [IEEE8021Qcc] also specifies configuration of
in this document are based on [IEEE8021Qcc]. In addition to the TSN TSN features (e.g., traffic scheduling specified by [IEEE8021Qbv]).
data model, [IEEE8021Qcc] also specifies configuration of TSN The common architecture and flow model, allow configured features to
features (e.g., traffic scheduling specified by [IEEE8021Qbv]). The be consistent in certain deployment scenarios, e.g., when the network
common architecture and flow model, allow configured features to be
consistent in certain deployment scenarios, e.g., when the network
that provides the DetNet service includes both L3 and L2 network that provides the DetNet service includes both L3 and L2 network
segments. segments.
1.1. Goals 1.1. Goals
As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates As expressed in the [IETFDetNet] Charter, the DetNet WG collaborates
with IEEE 802.1 TSN in order to define a common architecture for both with IEEE 802.1 TSN in order to define a common architecture for both
Layer 2 and Layer 3. This is beneficial for several reasons, e.g., Layer 2 and Layer 3. This is beneficial for several reasons, e.g.,
in order to simplify implementations and maintain consistency across in order to simplify implementations and maintain consistency across
diverse networks. The flow and service information models are also diverse networks. The flow and service information models are also
skipping to change at page 6, line 4 skipping to change at page 5, line 50
information models described in this document are based on information models described in this document are based on
[IEEE8021Qcc], which is an amendment to [IEEE8021Q]. [IEEE8021Qcc], which is an amendment to [IEEE8021Q].
This document specifies flow and service information models only. This document specifies flow and service information models only.
1.2. Non Goals 1.2. Non Goals
This document does not specify flow data models or DetNet This document does not specify flow data models or DetNet
configuration. Therefore, the goals of this document differ from the configuration. Therefore, the goals of this document differ from the
goals of [IEEE8021Qcc], which also specifies the TSN data model and goals of [IEEE8021Qcc], which also specifies the TSN data model and
configuration of certain TSN features. The DetNet specific YANG data configuration of certain TSN features.
model is described in [I-D.ietf-detnet-yang].
The DetNet specific YANG data model is described in
[I-D.ietf-detnet-yang].
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [RFC8655] and the DetNet Data Plane Framework [RFC8938]. architecture [RFC8655] and the DetNet Data Plane Framework [RFC8938].
The reader is assumed to be familiar with these documents and any The reader is assumed to be familiar with these documents and any
terminology defined therein. The DetNet <=> TSN dictionary of terminology defined therein. The DetNet <=> TSN dictionary of
[RFC8655] is used to perform translation from [IEEE8021Qcc] to this [RFC8655] is used to perform translation from [IEEE8021Qcc] to this
skipping to change at page 9, line 40 skipping to change at page 9, line 40
tolerance. tolerance.
o FlowBiDir: defines the data path requirement of the App-flow o FlowBiDir: defines the data path requirement of the App-flow
whether it must share the same data path and physical path for whether it must share the same data path and physical path for
both directions through the network, e.g., to provide congruent both directions through the network, e.g., to provide congruent
paths in the two directions. paths in the two directions.
5. DetNet Flow Related Parameters 5. DetNet Flow Related Parameters
The Data model specified by [IEEE8021Qcc] describes data flows using The Data model specified by [IEEE8021Qcc] describes data flows using
TSN service as periodic flows with fix packet size (i.e., Constant TSN service as periodic flows with fixed packet size (i.e., Constant
Bit Rate (CBR) flows) or with variable packet size. The same concept Bit Rate (CBR) flows) or with variable packet size. The same concept
is applied for flows using DetNet service. is applied for flows using DetNet service.
Latency and loss parameters are correlated because the effect of late Latency and loss parameters are correlated because the effect of late
delivery can result in data loss for an application. However, not delivery can result in data loss for an application. However, not
all applications require hard limits on both latency and loss. For all applications require hard limits on both latency and loss. For
example, some real-time applications allow graceful degradation if example, some real-time applications allow graceful degradation if
loss happens (e.g., sample-based data processing, media loss happens (e.g., sample-based data processing, media
distribution). Some other applications may require high-bandwidth distribution). Some other applications may require high-bandwidth
connections that make use of packet replication techniques which are connections that make use of packet replication techniques which are
skipping to change at page 10, line 30 skipping to change at page 10, line 30
o DnFlowRequirements (Section 5.9) o DnFlowRequirements (Section 5.9)
o DnFlowBiDir (Section 5.10) o DnFlowBiDir (Section 5.10)
Flow attributes are described in the following sections. Flow attributes are described in the following sections.
5.1. Management ID of the DetNet Flow 5.1. Management ID of the DetNet Flow
A unique (management) identifier is needed for each DetNet flow A unique (management) identifier is needed for each DetNet flow
within the DetNet domain. It is specified by DnFlowID. It can be within the DetNet domain. It is specified by DnFlowID. It can be
used to define the many to one mapping of DetNet flows to a DetNet used to define the N:1 mapping of DetNet flows to a DetNet service.
service.
5.2. Payload type of the DetNet Flow 5.2. Payload type of the DetNet Flow
The DnPayloadType attribute is set according to the encapsulated App- The DnPayloadType attribute is set according to the encapsulated App-
flow format. The attribute can be Ethernet, MPLS, or IP. flow format. The attribute can be Ethernet, MPLS, or IP.
5.3. Format of the DetNet Flow 5.3. Format of the DetNet Flow
The DnFlowFormat attribute is set according to the DetNet PSN The DnFlowFormat attribute is set according to the DetNet PSN
technology. The attribute can be MPLS or IP. technology. The attribute can be MPLS or IP.
skipping to change at page 11, line 33 skipping to change at page 11, line 33
c. IPv6FlowLabel c. IPv6FlowLabel
d. Dscp (attribute) d. Dscp (attribute)
e. Protocol e. Protocol
f. SourcePort f. SourcePort
g. DestinationPort g. DestinationPort
h. IPSecSpi h. IPSecSpi
The IP 6-tuple that is used for DetNet IP flow identification The IP 6-tuple that is used for DetNet IP flow identification
consists of items a, b, d, e, f, and g. Items c and h are additional consists of items a, b, d, e, f, and g. Items c and h are additional
attributes that can be used for DetNet flow identification in attributes that can be used for DetNet flow identification in
addition to the 6-tuple. Using wild cards for these attributes are addition to the 6-tuple. 6-tuple and use of wild cards for these
specified in [RFC8939]. attributes are specified in [RFC8939].
5.5. Traffic Specification of the DetNet Flow 5.5. Traffic Specification of the DetNet Flow
DnTrafficSpecification attributes specify how the DN Ingress DnTrafficSpecification attributes specify how the DN Ingress
transmits packets for the DetNet flow. This is effectively the transmits packets for the DetNet flow. This is effectively the
promise/request of the DN Ingress to the network. The network uses promise/request of the DN Ingress to the network. The network uses
this traffic specification to allocate resources and adjust queue this traffic specification to allocate resources and adjust queue
parameters in network nodes. parameters in network nodes.
TrafficSpecification has the following attributes: TrafficSpecification has the following attributes:
skipping to change at page 13, line 4 skipping to change at page 13, line 4
sensitive). Possible options how to extend DnTrafficSpecification sensitive). Possible options how to extend DnTrafficSpecification
attributes is for further discussion. attributes is for further discussion.
5.6. Endpoints of the DetNet Flow 5.6. Endpoints of the DetNet Flow
The DnFlowEndpoints attribute defines the starting and termination The DnFlowEndpoints attribute defines the starting and termination
reference points of the DetNet flow by pointing to the ingress reference points of the DetNet flow by pointing to the ingress
interface/node and egress interface(s)/node(s). Depending on the interface/node and egress interface(s)/node(s). Depending on the
network scenario it defines an interface or a node. Interface can be network scenario it defines an interface or a node. Interface can be
defined for example if the App-flow is a TSN Stream and it is defined for example if the App-flow is a TSN Stream and it is
received over a well defined UNI interface. For example, for App- received over a well defined UNI (User-to-Network Interface). For
flows with MPLS encapsulation defining an ingress node is more common example, for App-flows with MPLS encapsulation defining an ingress
when per platform label space is used. node is more common when per platform label space is used.
5.7. Rank of the DetNet Flow 5.7. Rank of the DetNet Flow
The DnFlowRank attribute provides the rank of this flow relative to The DnFlowRank attribute provides the rank of this flow relative to
other flows in the DetNet domain. Rank (range: 0-255) is used by the other flows in the DetNet domain. Rank (range: 0-255) is used by the
DetNet domain to decide which flows can and cannot exist when network DetNet domain to decide which flows can and cannot exist when network
resources reach their limit. Rank is used to help to determine which resources reach their limit. Rank is used to help to determine which
flows can be bumped (i.e., removed from node configuration thereby flows can be bumped (i.e., removed from node configuration thereby
releasing its resources) if for example a port of a node becomes releasing its resources) if for example a port of a node becomes
oversubscribed (e.g., due to network re-configuration). DnFlowRank oversubscribed (e.g., due to network re-configuration). DnFlowRank
skipping to change at page 20, line 25 skipping to change at page 20, line 25
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
detnet-mpls-13 (work in progress), October 2020. detnet-mpls-13 (work in progress), October 2020.
[IEEE8021Qcc]
IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE
Standard for Local and metropolitan area networks -
Bridges and Bridged Networks -- Amendment 31: Stream
Reservation Protocol (SRP) Enhancements and Performance
Improvements", 2018,
<https://ieeexplore.ieee.org/document/8514112/>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane: Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>. <https://www.rfc-editor.org/info/rfc8939>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf- Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-12 (work in progress), October 2020. detnet-security-13 (work in progress), December 2020.
[I-D.ietf-detnet-yang] [I-D.ietf-detnet-yang]
Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and
Z. Li, "Deterministic Networking (DetNet) Configuration Z. Li, "Deterministic Networking (DetNet) Configuration
YANG Model", draft-ietf-detnet-yang-09 (work in progress), YANG Model", draft-ietf-detnet-yang-09 (work in progress),
November 2020. November 2020.
[IEEE8021Q] [IEEE8021Q]
IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE
Standard for Local and metropolitan area networks - Standard for Local and metropolitan area networks -
Bridges and Bridged Networks", 2018, Bridges and Bridged Networks", 2018,
<https://ieeexplore.ieee.org/document/8403927>. <https://ieeexplore.ieee.org/document/8403927>.
[IEEE8021Qbv] [IEEE8021Qbv]
IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE
Standard for Local and metropolitan area networks - Standard for Local and metropolitan area networks -
Bridges and Bridged Networks - Amendment 25: Enhancements Bridges and Bridged Networks - Amendment 25: Enhancements
for Scheduled Traffic", 2015, for Scheduled Traffic", 2015,
<https://ieeexplore.ieee.org/document/7572858/>. <https://ieeexplore.ieee.org/document/7572858/>.
[IEEE8021Qcc]
IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE
Standard for Local and metropolitan area networks -
Bridges and Bridged Networks -- Amendment 31: Stream
Reservation Protocol (SRP) Enhancements and Performance
Improvements", 2018,
<https://ieeexplore.ieee.org/document/8514112/>.
[IETFDetNet] [IETFDetNet]
IETF, "IETF Deterministic Networking (DetNet) Working IETF, "IETF Deterministic Networking (DetNet) Working
Group", <https://datatracker.ietf.org/wg/detnet/charter/>. Group", <https://datatracker.ietf.org/wg/detnet/charter/>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
 End of changes. 15 change blocks. 
43 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/