< draft-ietf-intserv-ctrl-load-svc-03.txt		draft-ietf-intserv-ctrl-load-svc-04.txt >
	Internet Engineering Task Force Integrated Services WG		Internet Engineering Task Force Integrated Services WG
	INTERNET-DRAFT J. Wroclawski		INTERNET-DRAFT J. Wroclawski
	draft-ietf-intserv-ctrl-load-svc-03.txt MIT LCS		draft-ietf-intserv-ctrl-load-svc-04.txt MIT LCS
	August, 1996		November, 1996
	Expires: 2/97		Expires: 5/97
	Specification of the Controlled-Load Network Element Service		Specification of the Controlled-Load Network Element Service
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 30 ¶
	(4) the minimum policed unit m for TSpec A is less than or equal to		(4) the minimum policed unit m for TSpec A is less than or equal to
	that of TSpec B,		that of TSpec B,
	(5) the maximum packet size M of TSpec A is greater than or equal		(5) the maximum packet size M of TSpec A is greater than or equal
	to that of TSpec B.		to that of TSpec B.
	Note that not all TSpecs can be ordered with respect to each other.		Note that not all TSpecs can be ordered with respect to each other.
	If two TSpecs differ but not all five of the points above are true,		If two TSpecs differ but not all five of the points above are true,
	then the TSpecs are unordered.		then the TSpecs are unordered.
	A merged TSpec may be calculated over a set of TSpecs by taking:		A merged TSpec is the TSpec used by the RSVP protocol when merging a
			set of TSpecs to create a "merged" reservation. TSpec merging is
			described further in [4] and [3]. The TSpec merge operation addresses
			two requirements:
			- The "merged" TSpec parameters are used as the traffic flow's
			TSpec at the local node.
			- The merged parameters are passed upstream to traffic source(s) to
			describe characteristics of the actually installed reservation
			along the data path.
			For the controlled-load service, a merged TSpec may be calculated
			over a set of TSpecs by taking:
			(1) the largest token bucket rate r;
			(2) the largest token bucket size b;
			(3) the largest peak rate p;
			(4) the smallest minimal policed unit m;
			(5) the *smallest* maximum packet size M;
			across all members of the set.
			A Least Common TSpec is a TSpec adequate to describe the traffic from
			any one of a number of traffic flows. The least common TSpec may be
			useful when creating a shared reservation for a number of flows using
			SNMP or another management protocol. This differs from the merged
			TSpec described above in that the computed parameters are not passed
			upstream to the sources of traffic.
			For the controlled-load service, the Least Common TSpec may be
			calculated over a set of TSpecs by taking:
	(1) the largest token bucket rate r;		(1) the largest token bucket rate r;
	(2) the largest token bucket size b;		(2) the largest token bucket size b;
	(3) the largest peak rate p;		(3) the largest peak rate p;
	(4) the smallest minimal policed unit m;		(4) the smallest minimal policed unit m;
	(5) the largest maximum packet size M;		(5) the largest maximum packet size M;
	across all members of the set. This use of the word "merging" is		across all members of the set.
	similar to that in the RSVP protocol; a merged TSpec is one that is
	adequate to describe the traffic from any one of a number of flows.
	The sum of n controlled-load service TSpecs is used when computing		The sum of n controlled-load service TSpecs is used when computing
	the TSpec for a shared reservation of n flows. It is computed by		the TSpec for a shared reservation of n flows. It is computed by
	taking:		taking:
	- The sum across all TSpecs of the token bucket rate parameter r.		- The sum across all TSpecs of the token bucket rate parameter r.
	- The sum across all TSpecs of the token bucket size parameter b.		- The sum across all TSpecs of the token bucket size parameter b.
	- The sum across all TSpecs of the peak rate parameter p.		- The sum across all TSpecs of the peak rate parameter p.
	skipping to change at page 17, line 25 ¶		skipping to change at page 18, line 25 ¶
	[1] S. Shenker and J. Wroclawski. "Network Element QoS Control		[1] S. Shenker and J. Wroclawski. "Network Element QoS Control
	Service Specification Template". Internet Draft, July 1996, <draft-		Service Specification Template". Internet Draft, July 1996, <draft-
	ietf-intserv-svc-template-03.txt>		ietf-intserv-svc-template-03.txt>
	[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP:		[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP:
	A Transport Protocol for Real-Time Applications", Internet Draft,		A Transport Protocol for Real-Time Applications", Internet Draft,
	March 1995, <draft-ietf-avt-svc-rtp-07.txt>		March 1995, <draft-ietf-avt-svc-rtp-07.txt>
	[3] B. Braden, et. al. "Resource Reservation Protocol (RSVP) -		[3] B. Braden, et. al. "Resource Reservation Protocol (RSVP) -
	Version 1 Functional Specification", Internet Draft, July 1996,		Version 1 Functional Specification", Internet Draft, October 1996,
	<draft-ietf-rsvp-spec-13.txt>		<draft-ietf-rsvp-spec-14.txt>
	[4] J. Wroclawski. "The use of RSVP with IETF Integrated Services",		[4] J. Wroclawski. "The use of RSVP with IETF Integrated Services",
	Internet Draft, July 1996, <draft-ietf-intserv-rsvp-use-00.txt>		Internet Draft, October 1996, <draft-ietf-intserv-rsvp-use-01.txt>
	[5] S. Shenker and J. Wroclawski. "General Characterization		[5] S. Shenker and J. Wroclawski. "General Characterization
	Parameters for Integrated Service Network Elements", Internet Draft,		Parameters for Integrated Service Network Elements", Internet Draft,
	July 1996, <draft-ietf-intserv-charac-02.txt>		September 1996, <draft-ietf-intserv-charac-02.txt>
	[6] S. Floyd, and V. Jacobson. "Link-sharing and Resource Management		[6] S. Floyd, and V. Jacobson. "Link-sharing and Resource Management
	Models for Packet Networks," IEEE/ACM Transactions on Networking,		Models for Packet Networks," IEEE/ACM Transactions on Networking,
	Vol. 3 No. 4, pp. 365-386, August 1995.		Vol. 3 No. 4, pp. 365-386, August 1995.
	[7] A. K. J. Parekh. "A Generalized Processor Sharing Approach to		[7] A. K. J. Parekh. "A Generalized Processor Sharing Approach to
	Flow Control in Integrated Service Networks". MIT Laboratory for		Flow Control in Integrated Service Networks". MIT Laboratory for
	Information and Decision Systems, Report LIDS-TH-2089, February 1992		Information and Decision Systems, Report LIDS-TH-2089, February 1992
	Authors' Address:		Authors' Address:
End of changes. 7 change blocks.
	12 lines changed or deleted		43 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/