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/