draft-ietf-detnet-flow-information-model-01.txt		draft-ietf-detnet-flow-information-model-02.txt
	DetNet J. Farkas		DetNet J. Farkas
	Internet-Draft B. Varga		Internet-Draft B. Varga
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: September 6, 2018 R. Cummings		Expires: April 25, 2019 R. Cummings
	National Instruments		National Instruments
	Y. Jiang		Y. Jiang
	Huawei
	Y. Zha		Y. Zha
	Tencent		Huawei Technologies Co., Ltd.
	March 05, 2018		October 22, 2018
	DetNet Flow Information Model		DetNet Flow Information Model
	draft-ietf-detnet-flow-information-model-01		draft-ietf-detnet-flow-information-model-02
	Abstract		Abstract
	This document describes flow and service information model for		This document describes flow and service information model for
	Deterministic Networking (DetNet). The DetNet service is provided		Deterministic Networking (DetNet). The DetNet service is provided
	either for a Layer 3 or a Layer 2 flow. This document provides		either for a Layer 3 or a Layer 2 flow. This document provides
	DetNet flow and service information model both for Layer 3 and Layer		DetNet flow and service information model both for Layer 3 and Layer
	2 flows in an integrated fashion.		2 flows in an integrated fashion.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 39 ¶
	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 September 6, 2018.		This Internet-Draft will expire on April 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 44 ¶		skipping to change at page 2, line 43 ¶
	7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14		7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14
	8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10. Common Attributes of Source and Destination . . . . . . . . . 16		10. Common Attributes of Source and Destination . . . . . . . . . 16
	10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16		10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16
	10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16		10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16
	10.3. User to Network Requirements . . . . . . . . . . . . . . 17		10.3. User to Network Requirements . . . . . . . . . . . . . . 17
	11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18		13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18
	13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 18		13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 19
	14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19		14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19
	14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20		14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20
	14.2. Interface Configuration . . . . . . . . . . . . . . . . 21		14.2. Interface Configuration . . . . . . . . . . . . . . . . 21
	14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21		14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21
	15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 21		15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 22
	16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	18. Security Considerations . . . . . . . . . . . . . . . . . . . 22		18. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	19.1. Normative References . . . . . . . . . . . . . . . . . . 22		19.1. Normative References . . . . . . . . . . . . . . . . . . 22
	19.2. Informative References . . . . . . . . . . . . . . . . . 22		19.2. Informative References . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	A Deterministic Networking (DetNet) service provides a capability to		A Deterministic Networking (DetNet) service provides a capability to
	carry a unicast or a multicast data flow for an application with		carry a unicast or a multicast data flow for an application with
	constrained requirements on network performance, e.g., low packet		constrained requirements on network performance, e.g., low packet
	loss rate and/or latency. The DetNet service is provided either for		loss rate and/or latency. The DetNet service is provided either for
	a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network,		a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network,
	see, e.g., [I-D.ietf-detnet-dp-alt]. Similarly, Time-Sensitive		see, e.g., [I-D.ietf-detnet-dp-sol-mpls]. Similarly, Time-Sensitive
	Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged		Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged
	network. DetNet and TSN have common architecture as expressed in		network. DetNet and TSN have common architecture as expressed in
	[IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can		[IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can
	be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and		be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and
	DetNet L2 flows. Therefore, the DetNet flow and service information		DetNet L2 flows. Therefore, the DetNet flow and service information
	model provided by this document covers both DetNet L3 flows and		model provided by this document covers both DetNet L3 flows and
	DetNet L2 flows in an integrated fashion.		DetNet L2 flows in an integrated fashion.
	In a given network scenario three information models can		In a given network scenario three information models can
	distinguished:		distinguished:
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 30 ¶
	e.g., low packet loss rate and/or latency.		e.g., low packet loss rate and/or latency.
	The simplest DetNet service is to provide bridging over the DN domain		The simplest DetNet service is to provide bridging over the DN domain
	(i.e., tunneling for L2), where the connected hosts are in the same		(i.e., tunneling for L2), where the connected hosts are in the same
	broadcast (BC) domain. Forwarding over the DetNet domain is based on		broadcast (BC) domain. Forwarding over the DetNet domain is based on
	L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is		L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is
	DetNet Routing service that provides routing, so available only for		DetNet Routing service that provides routing, so available only for
	L3 hosts that are in different BC domains. Forwarding over the		L3 hosts that are in different BC domains. Forwarding over the
	DetNet domain is based on L3 (IP) addresses (i.e. dst-IP).		DetNet domain is based on L3 (IP) addresses (i.e. dst-IP).
	Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] shows the		Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] show the
	DetNet service related reference points and main components.		DetNet service related reference points and main components.
	5.2. Service parameters		5.2. Service parameters
	Two forwarding methods are distinguished: (1) Bridging and (2)		A DetNet network receives DetNet flows via a UNI as shown in Figure 5
	Routing. The DN service is represented by a DN-PSeudoWire (DN-PW).		in [I-D.ietf-detnet-architecture]. The DetNet network connects the
			UNIs via tunnels in order to provide DetNet service as shown in
			Figure 8 in [I-D.ietf-detnet-architecture].
	Data-flows are received over the UNI. Usually there is a DN service		The DetNet service attributes are the following:
	related legacy VPN service. The DN service and the legacy VPN
	service use a common AC (attachment circuit). Legacy VPN is used by
	regular traffic of the DetNet end-systems. DN flows are "directed"
	by a selector to DN-PW(s). (See Figure 8. in
	[I-D.ietf-detnet-architecture])
	Service attributes for DetNet connectivity are:		o Bandwidth
			It is the bandwidth guaranteed for the DetNet service.
	o Bandwidth parameter(s),		o Delay parameters
			The are two delay parameters for a DetNet service:
	o Delay parameter(s),		* Maximum latency, which is the maximum end-to-end one-way
			latency for the DetNet service.
	o Loss parameter(s),		* Packet Delay Variation (PDV), which is the difference between
	o Connectivity type,		the minimum and the maximum end-to-end one-way latency. The
			PDV parameter describes the maximum packet delay variation for
			the DetNet service. (Note that PDV is sometimes referred to as
			jitter.)
	o In order delivery,		o Loss parameters
	o Service rank.		* The maximum Packet Loss Ratio (PLR) parameter describes the
			maximum packet loss ratio for the DetNet service between the
			edges of the DetNet network.
	Time/loss sensitive applications may have somewhat special		* Some applications have special loss requirement. The maximum
	requirements especially for loss (e.g., no loss in two consecutive		consecutive loss tolerance parameter describes the maximum
	communication cycles; very low outage time, etc.).		number of consecutive packets whose loss can be tolerated. The
			maximum consecutive loss tolerance can be measured based on
			sequence number.
	Two connectivity types are distinguished: point-to-point (p2p) and		o Maximum allowed misordering
	point-to-multipoint (p2mp). Connectivity type p2mp is created by a		Maximum allowed misordering describes the tolerable maximum number
	transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity		of packets that can be received out of order. The maximum allowed
	is a superposition of p2mp connections.)		misordering can be measured based on sequence number. The value
			zero for the maximum allowed misordering indicates that in order
			delivery is required, misordering cannot be tolerated.
	Depending on the application and the end-system capabilities DetNet		o Connectivity type
	service may be requested to provide in order delivery.		Two connectivity types are distinguished: point-to-point (p2p) and
			point-to-multipoint (p2mp). Connectivity type p2mp is created by
			a transport layer function (e.g., p2mp LSP). (Note: mp2mp
			connectivity is a superposition of p2mp connections.)
	Service rank provides the rank of a service instance relative to		o Service rank
	other services in the network. Rank is used by the network in case		Service rank provides the rank of a service instance relative to
	of network resource limitation scenarios.		other services in the network. Rank is used by the network in
			case of network resource limitation scenarios.
	5.3. Reference Points		5.3. Reference Points
	From service model design perspective a fundamental question is the		From service model design perspective a fundamental question is the
	location of the service endpoints, i.e., where the service starts and		location of the service endpoints, i.e., where the service starts and
	ends.		ends.
	Note: Further discussion is needed based on data plane encapsulation		Note: Further discussion is needed based on data plane encapsulation
	results what reference points should be defined. Only some possible		results what reference points should be defined. Only some possible
	examples listed here:		examples listed here:
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 27 ¶
	central entity knows that the resources supporting the current flow		central entity knows that the resources supporting the current flow
	can be available for supporting the altered flow. Modify is		can be available for supporting the altered flow. Modify is
	considered to be an optional operation due to possible control-plane		considered to be an optional operation due to possible control-plane
	limitations.		limitations.
	As the DetNet UNI can provide service for both L3 and L2 flows, end		As the DetNet UNI can provide service for both L3 and L2 flows, end
	systems may not need to implement the L3 <=> L2 Transfer Function		systems may not need to implement the L3 <=> L2 Transfer Function
	specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also		specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also
	subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a		subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a
	function similar to the Transfer Function, see, e.g., the Svc Proxy		function similar to the Transfer Function, see, e.g., the Svc Proxy
	in Figure 1 in [I-D.ietf-detnet-dp-alt].		in Figure 3 in [I-D.ietf-detnet-architecture].
	7. Flow		7. Flow
	The flows leveraging DetNet service can be unicast or multicast data		The flows leveraging DetNet service can be unicast or multicast data
	flows for an application with constrained requirements on network		flows for an application with constrained requirements on network
	performance, e.g., low packet loss rate and/or latency. Therefore,		performance, e.g., low packet loss rate and/or latency. Therefore,
	they can require different connectivity types: point-to-point (p2p)		they can require different connectivity types: point-to-point (p2p)
	or point-to-multipoint (p2mp). The p2mp connectivity is created by a		or point-to-multipoint (p2mp). The p2mp connectivity is created by a
	transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt].		transport layer function (e.g., p2mp LSP)
	(Note that mp2mp connectivity is a superposition of p2mp		[I-D.ietf-detnet-dp-sol-mpls]. (Note that mp2mp connectivity is a
	connections.)		superposition of p2mp connections.)
	Many flows using DetNet service are periodic with fix packet size		Many flows using DetNet service are periodic with fix packet size
	(i.e., Constant Bit Rate (CBR) flows), or periodic with variable		(i.e., Constant Bit Rate (CBR) flows), or periodic with variable
	packet size.		packet size.
	Delay and loss parameters are correlated because the effect of late		Delay and loss parameters are correlated because the effect of late
	delivery can result data loss for an application. However, not all		delivery can result data loss for an application. However, not all
	applications require hard limits on both parameters (delay and loss).		applications require hard limits on both parameters (delay and loss).
	For example, some real-time applications allow graceful degradation		For example, some real-time applications allow graceful degradation
	if loss happens (e.g., sample-based processing, media distribution).		if loss happens (e.g., sample-based processing, media distribution).
	skipping to change at page 13, line 38 ¶		skipping to change at page 14, line 4 ¶
	Committed Rate indicates the rate at which traffic commits to be sent		Committed Rate indicates the rate at which traffic commits to be sent
	by the source (described in terms of the CIR (Committed Information		by the source (described in terms of the CIR (Committed Information
	Rate) and CBS (Committed Burst Size) attributes.) Excess Rate		Rate) and CBS (Committed Burst Size) attributes.) Excess Rate
	indicates the extent by which the traffic sent by the source exceeds		indicates the extent by which the traffic sent by the source exceeds
	the committed rate. The Excess Rate is described in terms of the EIR		the committed rate. The Excess Rate is described in terms of the EIR
	(Excess Information Rate) and EBS (Excess Burst Size) attributes. ]]		(Excess Information Rate) and EBS (Excess Burst Size) attributes. ]]
	[[NOTE3: a third alternative is to define application based traffic		[[NOTE3: a third alternative is to define application based traffic
	models such as [GPP22885] defines periodic and event-driven traffic		models such as [GPP22885] defines periodic and event-driven traffic
	model, and 5G PPP work defines traffic model for MTC (Machine Type		model, and 5G PPP work defines traffic model for MTC (Machine Type
	Communication) use cases. Periodic traffic type is usually for		Communication) use cases [I-D.ietf-detnet-use-cases]. Periodic
	status update between devices or devices transmit status report to a		traffic type is usually for status update between devices or devices
	central unit in regular basis. TrafficPeriod, defines the period of		transmit status report to a central unit in regular basis.
	the status update message. DataSize, defines the data size of the		TrafficPeriod, defines the period of the status update message.
	massage which is constant. 3GPP also defines approximately-periodic		DataSize, defines the data size of the massage which is constant.
	transmission with variations on period and uncertainty in the time		3GPP also defines approximately-periodic transmission with variations
	arrival of the packets. Event-triggered traffic type corresponds		on period and uncertainty in the time arrival of the packets. Event-
	traffic being triggered by an MTC device event.		triggered traffic type corresponds traffic being triggered by an MTC
	MinIntervalBetweenEvent, defines the minimum interval between two		device event. MinIntervalBetweenEvent, defines the minimum interval
	events. Event-triggered transmission will not happen all the time,		between two events. Event-triggered transmission will not happen all
	whenever an alert is sent, it waits until the issue being solved to		the time, whenever an alert is sent, it waits until the issue being
	be able to send another alert. MaxPacketPerEvent, defines the max		solved to be able to send another alert. MaxPacketPerEvent, defines
	number of packets within one message. ]]		the max number of packets within one message. ]]
	7.3. Flow Rank		7.3. Flow Rank
	FlowRank provides the rank of this flow relative to other flows in		FlowRank provides the rank of this flow relative to other flows in
	the network. This rank is used to determine success/failure of flow		the network. This rank is used to determine success/failure of flow
	establishment. Rank (boolean) is used by the network to decide which		establishment. Rank (boolean) is used by the network to decide which
	flows can and cannot exist when network resources reach their limit.		flows can and cannot exist when network resources reach their limit.
	Rank is used to help to determine which flows can be dropped (i.e.,		Rank is used to help to determine which flows can be dropped (i.e.,
	removed from node configuration) if a port of a node becomes		removed from node configuration) if a port of a node becomes
	oversubscribed (e.g., due to network reconfiguration). The true		oversubscribed (e.g., due to network reconfiguration). The true
	skipping to change at page 22, line 20 ¶		skipping to change at page 22, line 31 ¶
	N/A.		N/A.
	19. References		19. References
	19.1. Normative References		19.1. Normative References
	[I-D.ietf-detnet-architecture]		[I-D.ietf-detnet-architecture]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", draft-ietf-		"Deterministic Networking Architecture", draft-ietf-
	detnet-architecture-03 (work in progress), August 2017.		detnet-architecture-08 (work in progress), September 2018.
	[I-D.ietf-detnet-dp-alt]
	Korhonen, J., Farkas, J., Mirsky, G., Thubert, P.,
	Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol
	and Solution Alternatives", draft-ietf-detnet-dp-alt-00
	(work in progress), October 2016.
	[I-D.ietf-detnet-use-cases]		[I-D.ietf-detnet-dp-sol-mpls]
	Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,		Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
	Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y.,		Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in
	Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana,		progress), October 2018.
	X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D.,
	Geng, X., Dujovne, D., and M. Seewald, "Deterministic
	Networking Use Cases", draft-ietf-detnet-use-cases-13
	(work in progress), September 2017.
	[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>.
	[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",		[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
	RFC 6003, DOI 10.17487/RFC6003, October 2010,		RFC 6003, DOI 10.17487/RFC6003, October 2010,
	<https://www.rfc-editor.org/info/rfc6003>.		<https://www.rfc-editor.org/info/rfc6003>.
	19.2. Informative References		19.2. Informative References
	[GPP22885]		[GPP22885]
	3GPP, "Study on LTE support for Vehicle-to-Everything		3GPP, "Study on LTE support for Vehicle-to-Everything
	(V2X) services",		(V2X) services",
	<http://www.3gpp.org/DynaReport/22885.html>.		<http://www.3gpp.org/DynaReport/22885.html>.
			[I-D.ietf-detnet-use-cases]
			Grossman, E., "Deterministic Networking Use Cases", draft-
			ietf-detnet-use-cases-19 (work in progress), October 2018.
	[IEEE8021AS]		[IEEE8021AS]
	IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local		IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local
	and metropolitan area networks - Timing and		and metropolitan area networks - Timing and
	Synchronization for Time-Sensitive Applications in Bridged		Synchronization for Time-Sensitive Applications in Bridged
	Local Area Networks", 2011,		Local Area Networks", 2011,
	<http://standards.ieee.org/getieee802/		<http://standards.ieee.org/getieee802/
	download/802.1AS-2011.pdf>.		download/802.1AS-2011.pdf>.
	[IEEE8021CB]		[IEEE8021CB]
	IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local		IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local
	skipping to change at page 24, line 4 ¶		skipping to change at page 24, line 6 ¶
	[IEEE8021TSN]		[IEEE8021TSN]
	IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN)		IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN)
	Task Group", <http://www.ieee802.org/1/pages/tsn.html>.		Task Group", <http://www.ieee802.org/1/pages/tsn.html>.
	[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/>.
	Authors' Addresses		Authors' Addresses
	Janos Farkas		Janos Farkas
	Ericsson		Ericsson
	Konyves Kalman krt. 11/B		Magyar tudosok korutja 11
	Budapest 1097		Budapest 1117
	Hungary		Hungary
	Email: janos.farkas@ericsson.com		Email: janos.farkas@ericsson.com
	Balazs Varga		Balazs Varga
	Ericsson		Ericsson
	Konyves Kalman krt. 11/B		Magyar tudosok korutja 11
	Budapest 1097		Budapest 1117
	Hungary		Hungary
	Email: balazs.a.varga@ericsson.com		Email: balazs.a.varga@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
	Yuanlong Jiang		Yuanlong Jiang
	Huawei		Huawei Technologies Co., Ltd.
			Bantian, Longgang district
			Shenzhen 518129
			China
	Email: jiangyuanlong@huawei.com		Email: jiangyuanlong@huawei.com
	Yiyong Zha		Yiyong Zha
	Tencent		Huawei Technologies Co., Ltd.
			China
			Email: zhayiyong@huawei.com
End of changes. 33 change blocks.
	76 lines changed or deleted		86 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/