draft-ietf-detnet-flow-information-model-08.txt   draft-ietf-detnet-flow-information-model-09.txt 
DetNet J. Farkas DetNet B. Varga
Internet-Draft B. Varga Internet-Draft J. Farkas
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: November 7, 2020 R. Cummings Expires: November 14, 2020 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.
May 6, 2020 May 13, 2020
DetNet Flow Information Model DetNet Flow Information Model
draft-ietf-detnet-flow-information-model-08 draft-ietf-detnet-flow-information-model-09
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 November 7, 2020. This Internet-Draft will expire on November 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 6
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.3. Naming Conventions . . . . . . . . . . . . . . . . . . . 7
2.4. Naming Conventions . . . . . . . . . . . . . . . . . . . 7
3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7 3. DetNet Domain and its Modeling . . . . . . . . . . . . . . . 7
3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7 3.1. DetNet Service Overview . . . . . . . . . . . . . . . . . 7
3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7 3.2. Reference Points Used in Modeling . . . . . . . . . . . . 7
3.3. Information Elements . . . . . . . . . . . . . . . . . . 8 3.3. Information Elements . . . . . . . . . . . . . . . . . . 8
4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8 4. App-flow Related Parameters . . . . . . . . . . . . . . . . . 8
4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8 4.1. App-flow Characteristics . . . . . . . . . . . . . . . . 8
4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9 4.2. App-flow Requirements . . . . . . . . . . . . . . . . . . 9
5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9 5. DetNet Flow Related Parameters . . . . . . . . . . . . . . . 9
5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10 5.1. Management ID of the DetNet Flow . . . . . . . . . . . . 10
5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10 5.2. Payload type of the DetNet Flow . . . . . . . . . . . . . 10
5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10 5.3. Format of the DetNet Flow . . . . . . . . . . . . . . . . 10
5.4. Identification and Specification of DetNet Flows . . . . 11 5.4. Identification and Specification of DetNet Flows . . . . 10
5.4.1. DetNet MPLS Flow Identification and Specification . . 11 5.4.1. DetNet MPLS Flow Identification and Specification . . 10
5.4.2. DetNet IP Flow Identification and Specification . . . 11 5.4.2. DetNet IP Flow Identification and Specification . . . 11
5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11 5.5. Traffic Specification of the DetNet Flow . . . . . . . . 11
5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12 5.6. Endpoints of the DetNet Flow . . . . . . . . . . . . . . 12
5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12 5.7. Rank of the DetNet Flow . . . . . . . . . . . . . . . . . 12
5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 12 5.8. Status of the DetNet Flow . . . . . . . . . . . . . . . . 12
5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13 5.9. Requirements of the DetNet Flow . . . . . . . . . . . . . 13
5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 13 5.9.1. Minimum Bandwidth of the DetNet Flow . . . . . . . . 13
5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 14 5.9.2. Maximum Latency of the DetNet Flow . . . . . . . . . 13
5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 14 5.9.3. Maximum Latency Variation of the DetNet Flow . . . . 13
5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 14 5.9.4. Maximum Loss of the DetNet Flow . . . . . . . . . . . 13
5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14 5.9.5. Maximum Consecutive Loss of the DetNet Flow . . . . . 14
5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14 5.9.6. Maximum Misordering Tolerance of the DetNet Flow . . 14
5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14 5.10. BiDir requirement of the DetNet Flow . . . . . . . . . . 14
6. DetNet Service Related Parameters . . . . . . . . . . . . . . 14 6. DetNet Service Related Parameters . . . . . . . . . . . . . . 14
6.1. Management ID of the DetNet service . . . . . . . . . . . 15 6.1. Management ID of the DetNet service . . . . . . . . . . . 14
6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15 6.2. Delivery Type of the DetNet service . . . . . . . . . . . 15
6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15 6.3. Delivery Profile of the DetNet Service . . . . . . . . . 15
6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 15 6.3.1. Minimum Bandwidth of the DetNet Service . . . . . . . 15
6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 15 6.3.2. Maximum Latency of the DetNet Service . . . . . . . . 15
6.3.3. Maximum Latency Variation of the DetNet Service . . . 16 6.3.3. Maximum Latency Variation of the DetNet Service . . . 15
6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 16 6.3.4. Maximum Loss of the DetNet Service . . . . . . . . . 15
6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 16 6.3.5. Maximum Consecutive Loss of the DetNet Service . . . 15
6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16 6.3.6. Maximum Misordering Tolerance of the DetNet Service . 16
6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16 6.4. Connectivity Type of the DetNet Service . . . . . . . . . 16
6.5. BiDir requirement of the DetNet Service . . . . . . . . . 16 6.5. BiDir requirement of the DetNet Service . . . . . . . . . 16
6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 16 6.6. Rank of the DetNet Service . . . . . . . . . . . . . . . 16
6.7. Status of the DetNet Service . . . . . . . . . . . . . . 17 6.7. Status of the DetNet Service . . . . . . . . . . . . . . 16
7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 17 7. Flow Specific Operations . . . . . . . . . . . . . . . . . . 17
7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18 7.1. Join Operation . . . . . . . . . . . . . . . . . . . . . 18
7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 18 7.2. Leave Operation . . . . . . . . . . . . . . . . . . . . . 18
7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 18 7.3. Modify Operation . . . . . . . . . . . . . . . . . . . . 18
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Deterministic Networking (DetNet) provides a capability to carry Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and delivery latency. A description of the general background and
concepts of DetNet can be found in [RFC8655]. concepts of DetNet can be found in [RFC8655].
This document describes the Detnet Flow Service Information Model. This document describes the Detnet Flow Service Information Model.
skipping to change at page 5, line 26 skipping to change at page 5, line 26
+-+ 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].
Furthermore, the origination of the DetNet flow information model was Furthermore, the origination of the DetNet flow information model was
the flow identification possibilities described in [IEEE8021CB], the flow identification possibilities described in Section 6. of
which is used by [IEEE8021Qcc] as well. In addition to the TSN data [IEEE8021CB], which is used by [IEEE8021Qcc] as well. In addition to
model, [IEEE8021Qcc] also specifies configuration of TSN features the TSN data model, [IEEE8021Qcc] also specifies configuration of TSN
(e.g., traffic scheduling specified by [IEEE8021Qbv]). The common features (e.g., traffic scheduling specified by [IEEE8021Qbv]). The
architecture and flow model, allow configured features to be common architecture and flow model, allow configured features to be
consistent in certain deployment scenarios, e.g., when the network 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
aligned for those reasons. Therefore, the DetNet flow and service aligned for those reasons. Therefore, the DetNet flow and service
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 (this revision) does not specify flow data models or This document does not specify flow data models or DetNet
DetNet configuration. Therefore, the goals of this document differ configuration. Therefore, the goals of this document differ from the
from the goals of [IEEE8021Qcc], which also specifies the TSN data goals of [IEEE8021Qcc], which also specifies the TSN data model and
model and configuration of certain TSN features. configuration of certain TSN features.
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 architecture [RFC8655] and the DetNet Data Plane Framework
[I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be
familiar with these documents and any terminology defined therein. familiar with these documents and any terminology defined therein.
The DetNet <=> TSN dictionary of [RFC8655] is used to perform The DetNet <=> TSN dictionary of [RFC8655] is used to perform
skipping to change at page 7, line 9 skipping to change at page 7, line 9
DetNet Deterministic Networking. DetNet Deterministic Networking.
DN DetNet. DN DetNet.
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching.
PSN Packet Switched Network. PSN Packet Switched Network.
TSN Time-Sensitive Networking. TSN Time-Sensitive Networking.
2.3. Requirements Language 2.3. Naming Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.4. Naming Conventions
The following naming conventions were used for naming information The following naming conventions were used for naming information
model components in this document. It is recommended that extensions model components in this document. It is recommended that extensions
of the model use the same conventions. of the model use the same conventions.
o Names SHOULD be descriptive. o Descriptive names are used.
o Names MUST start with uppercase letters. o Names start with uppercase letters.
o Composed names MUST use capital letters for the first letter of o Composed names use capital letters for the first letter of each
each component. All other letters are lowercase, even for component. All other letters are lowercase, even for acronyms.
acronyms. Exceptions are made for acronyms containing a mixture Exceptions are made for acronyms containing a mixture of lowercase
of lowercase and capital letters, such as IPv6. Example composed and capital letters, such as IPv6. Example composed names are
names are SourceMacAddress and DestinationIPv6Address. SourceMacAddress and DestinationIPv6Address.
3. DetNet Domain and its Modeling 3. DetNet Domain and its Modeling
3.1. DetNet Service Overview 3.1. DetNet Service Overview
The DetNet service can be defined as a service that provides a The DetNet service can be defined as a service that provides a
capability to carry a unicast or a multicast data flow for an capability to carry a unicast or a multicast data flow for an
application with constrained requirements on network performance, application with constrained requirements on network performance,
e.g., low packet loss rate and/or latency. e.g., low packet loss rate and/or latency.
skipping to change at page 12, line 15 skipping to change at page 11, line 50
b. MaxPacketsPerInterval: the maximum number of packets that the b. MaxPacketsPerInterval: the maximum number of packets that the
Ingress will transmit in one Interval. Ingress will transmit in one Interval.
c. MaxPayloadSize: the maximum payload size that the Ingress will c. MaxPayloadSize: the maximum payload size that the Ingress will
transmit. transmit.
These attributes can be used to describe any type of traffic (e.g., These attributes can be used to describe any type of traffic (e.g.,
CBR, VBR, etc.) and can be used during resource allocation to CBR, VBR, etc.) and can be used during resource allocation to
represent worst case scenarios. represent worst case scenarios.
[[Editor's note (to be removed from a future revision): Further Further optional attributes can be considered to achieve more
optional attributes can be considered to achieve more efficient efficient resource allocation. Such optional attributes might be
resource allocation. Such optional attributes might be worth for worth for flows with soft requirements (i.e., the flow is only loss
flows with soft requirements (i.e., the flow is only loss sensitive sensitive or only delay sensitive, but not both delay-and-loss
or only delay sensitive, but not both delay-and-loss sensitive). sensitive). Possible options how to extend DnTrafficSpecification
Possible options how to extend DnTrafficSpecification attributes is attributes is for further discussion.
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 interface. For example, for App-
flows with MPLS encapsulation defining an ingress node is more common flows with MPLS encapsulation defining an ingress node is more common
skipping to change at page 13, line 18 skipping to change at page 13, line 4
* OutOfService: Administratively blocked. * OutOfService: Administratively blocked.
b. DnEgressStatus is an enumeration for the status of the flow's b. DnEgressStatus is an enumeration for the status of the flow's
Egress reference points: Egress reference points:
* None: no Egress. * None: no Egress.
* Ready: all Egresses are ready. * Ready: all Egresses are ready.
* PartialFailed: One or more Egress ready, and one or more * PartialFailed: One or more Egress ready, and one or more
Egress failed. The DetNet flow can be used if the Ingress is Egress failed. The DetNet flow can be used if the Ingress is
Ready. Ready.
* Failed: All Egresses failed. * Failed: All Egresses failed.
* OutOfService: Administratively blocked. * OutOfService: Administratively blocked.
c. FailureCode: A non-zero code that specifies the error if the c. FailureCode: A non-zero code that specifies the error if the
DetNet flow encounters a failure (e.g., packet replication and DetNet flow encounters a failure (e.g., packet replication and
elimination is requested but not possible, or DnIngressStatus is elimination is requested but not possible, or DnIngressStatus is
Failed, or DnEgressStatus is Failed, or DnEgressStatus is Failed, or DnEgressStatus is Failed, or DnEgressStatus is
PartialFailed). PartialFailed).
[[Editor's note (to be removed from a future revision): FailureCodes Defining FailureCodes for DetNet is out-of-scope in this document.
to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN Table 46-1 of [IEEE8021Qcc] describes TSN failure codes.
failure codes.]]
5.9. Requirements of the DetNet Flow 5.9. Requirements of the DetNet Flow
DnFlowRequirements specifies requirements to ensure the service level DnFlowRequirements specifies requirements to ensure the service level
desired for the DetNet flow. desired for the DetNet flow.
The DnFlowRequirements includes the following attributes: The DnFlowRequirements includes the following attributes:
a. MinBandwidth(Section 5.9.1) a. MinBandwidth(Section 5.9.1)
b. MaxLatency(Section 5.9.2) b. MaxLatency(Section 5.9.2)
skipping to change at page 17, line 41 skipping to change at page 17, line 24
Ready. Ready.
* Failed: All Egresses failed. * Failed: All Egresses failed.
* OutOfService: Administratively blocked. * OutOfService: Administratively blocked.
c. DnServiceFailureCode: A non-zero code that specifies the error if c. DnServiceFailureCode: A non-zero code that specifies the error if
the DetNet service encounters a failure (e.g., packet replication the DetNet service encounters a failure (e.g., packet replication
and elimination is requested but not possible, or and elimination is requested but not possible, or
DnServiceIngressStatus is Failed, or DnServiceEgressStatus is DnServiceIngressStatus is Failed, or DnServiceEgressStatus is
Failed, or DnServiceEgressStatus is PartialFailed). Failed, or DnServiceEgressStatus is PartialFailed).
[[Editor's note (to be removed from a future revision): Defining DnServiceFailureCodes for DetNet service is out-of-scope in
DnServiceFailureCodes to be defined for DetNet service. Table 46-1 this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure
of [IEEE8021Qcc] describes TSN failure codes.]] codes.
7. Flow Specific Operations 7. Flow Specific Operations
The DetNet flow information model relies on three high level The DetNet flow information model relies on three high level
information groups: information groups:
o DnIngress: The DnIngress information group includes elements that o DnIngress: The DnIngress information group includes elements that
specify the source for a single DetNet flow. This information specify the source for a single DetNet flow. This information
group is applied from the user of the DetNet service to the group is applied from the user of the DetNet service to the
network. network.
skipping to change at page 19, line 12 skipping to change at page 18, line 43
between the Join and the Leave, then while figuring out whether the between the Join and the Leave, then while figuring out whether the
new flow spec can be supported, the controller entity has to assume new flow spec can be supported, the controller entity has to assume
that the resources committed to the current flow are in use. By that the resources committed to the current flow are in use. By
using Modify the controller entity knows that the resources using Modify the controller entity knows that the resources
supporting the current flow can be available for supporting the supporting the current flow can be available for supporting the
altered flow. Modify is considered to be an optional operation due altered flow. Modify is considered to be an optional operation due
to possible controller plane limitations. to possible controller plane limitations.
8. Summary 8. Summary
This document describes DetNet flow information model and service This document describes the DetNet flow information model and the
information model for DetNet IP networks and DetNet MPLS networks. service information model for DetNet IP networks and DetNet MPLS
networks. These models are used as input for the YANG model.
9. IANA Considerations 9. IANA Considerations
N/A. N/A.
10. Security Considerations 10. Security Considerations
Security considerations for DetNet are described in detail in The external interfaces of the DetNet domain need to be subject to
[I-D.ietf-detnet-security]. General security considerations are appropriate confidentiality. Additionally, knowledge of which flows/
described in [RFC8655]. This section covers security for the Flow services are provided to a customer or delivered by a network
Information Model and there are no additional security considerations operator may supply information that can be used in a variety of
introduced by this document. security attacks. Security considerations for DetNet are described
in detail in [I-D.ietf-detnet-security]. General security
considerations are described in [RFC8655]. This document discusses
modeling the information, not how it is exchanged.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06
ip-05 (work in progress), February 2020. (work in progress), April 2020.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
draft-ietf-detnet-mpls-05 (work in progress), February detnet-mpls-06 (work in progress), April 2020.
2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Malis, A., and S. Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-04 (work in progress), February 2020. data-plane-framework-06 (work in progress), May 2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T. and E. Grossman, "Deterministic Networking Mizrahi, T. and E. Grossman, "Deterministic Networking
(DetNet) Security Considerations", draft-ietf-detnet- (DetNet) Security Considerations", draft-ietf-detnet-
security-09 (work in progress), March 2020. security-09 (work in progress), March 2020.
[IEEE8021CB] [IEEE8021CB]
IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE
Standard for Local and metropolitan area networks - Frame Standard for Local and metropolitan area networks - Frame
Replication and Elimination for Reliability", 2017, Replication and Elimination for Reliability", 2017,
skipping to change at page 21, line 11 skipping to change at page 21, line 4
[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>.
Authors' Addresses Authors' Addresses
Balazs Varga
Janos Farkas
Ericsson Ericsson
Magyar tudosok korutja 11 Magyar tudosok korutja 11
Budapest 1117 Budapest 1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: balazs.a.varga@ericsson.com
Balazs Varga Janos Farkas
Ericsson Ericsson
Magyar tudosok korutja 11 Magyar tudosok korutja 11
Budapest 1117 Budapest 1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: janos.farkas@ericsson.com
Rodney Cummings Rodney Cummings
National Instruments National Instruments
11500 N. Mopac Expwy 11500 N. Mopac Expwy
Bldg. C Bldg. C
Austin, TX 78759-3504 Austin, TX 78759-3504
USA USA
Email: rodney.cummings@ni.com Email: rodney.cummings@ni.com
 End of changes. 32 change blocks. 
80 lines changed or deleted 72 lines changed or added

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