< draft-ietf-dccp-spec-12.txt		draft-ietf-dccp-spec-13.txt >
	Internet Engineering Task Force Eddie Kohler		Internet Engineering Task Force Eddie Kohler
	INTERNET-DRAFT UCLA		INTERNET-DRAFT UCLA
	draft-ietf-dccp-spec-12.txt Mark Handley		draft-ietf-dccp-spec-13.txt Mark Handley
	Expires: 28 May 2006 UCL		Expires: 2 June 2006 UCL
	Sally Floyd		Sally Floyd
	ICIR		ICIR
	28 November 2005		2 December 2005
	Datagram Congestion Control Protocol (DCCP)		Datagram Congestion Control Protocol (DCCP)
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on 28 May 2006.		This Internet-Draft will expire on 2 June 2006.
	Abstract		Abstract
	The Datagram Congestion Control Protocol (DCCP) is a transport		The Datagram Congestion Control Protocol (DCCP) is a transport
	protocol that provides bidirectional unicast connections of		protocol that provides bidirectional unicast connections of
	congestion-controlled unreliable datagrams. DCCP is suitable for		congestion-controlled unreliable datagrams. DCCP is suitable for
	applications that transfer fairly large amounts of data, but can		applications that transfer fairly large amounts of data, but can
	benefit from control over the tradeoff between timeliness and		benefit from control over the tradeoff between timeliness and
	reliability.		reliability.
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	15. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 108		15. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 108
	16. Middlebox Considerations . . . . . . . . . . . . . . . . . . 108		16. Middlebox Considerations . . . . . . . . . . . . . . . . . . 108
	17. Relations to Other Specifications. . . . . . . . . . . . . . 110		17. Relations to Other Specifications. . . . . . . . . . . . . . 110
	17.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 110		17.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 110
	17.2. Congestion Manager and Multiplexing . . . . . . . . . . 111		17.2. Congestion Manager and Multiplexing . . . . . . . . . . 111
	18. Security Considerations. . . . . . . . . . . . . . . . . . . 111		18. Security Considerations. . . . . . . . . . . . . . . . . . . 111
	18.1. Security Considerations for Partial		18.1. Security Considerations for Partial
	Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 112		Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 112
	19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 113		19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 113
	19.1. Packet Types Registry . . . . . . . . . . . . . . . . . 113		19.1. Packet Types Registry . . . . . . . . . . . . . . . . . 113
	19.2. Reset Codes Registry. . . . . . . . . . . . . . . . . . 114		19.2. Reset Codes Registry. . . . . . . . . . . . . . . . . . 113
	19.3. Option Types Registry . . . . . . . . . . . . . . . . . 114		19.3. Option Types Registry . . . . . . . . . . . . . . . . . 114
	19.4. Feature Numbers Registry. . . . . . . . . . . . . . . . 114		19.4. Feature Numbers Registry. . . . . . . . . . . . . . . . 114
	19.5. Congestion Control Identifiers Registry . . . . . . . . 115		19.5. Congestion Control Identifiers Registry . . . . . . . . 114
	19.6. Ack Vector States Registry. . . . . . . . . . . . . . . 115		19.6. Ack Vector States Registry. . . . . . . . . . . . . . . 115
	19.7. Drop Codes Registry . . . . . . . . . . . . . . . . . . 115		19.7. Drop Codes Registry . . . . . . . . . . . . . . . . . . 115
	19.8. Service Codes Registry. . . . . . . . . . . . . . . . . 115		19.8. Service Codes Registry. . . . . . . . . . . . . . . . . 115
	19.9. Port Numbers Registry . . . . . . . . . . . . . . . . . 116		19.9. Port Numbers Registry . . . . . . . . . . . . . . . . . 116
	20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 118		20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
	A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 118		A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 118
	A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 120		A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 120
	A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 121		A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 120
	A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 122		A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 121
	A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 122		A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 122
	A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 123		A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 123
	A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 124		A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 124
	B. Appendix: Partial Checksumming Design Motivation. . . . . . . 125		B. Appendix: Partial Checksumming Design Motivation. . . . . . . 125
	Normative References . . . . . . . . . . . . . . . . . . . . . . 127		Normative References . . . . . . . . . . . . . . . . . . . . . . 126
	Informative References . . . . . . . . . . . . . . . . . . . . . 127		Informative References . . . . . . . . . . . . . . . . . . . . . 127
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 130		Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 130
	Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 130		Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 130
	List of Tables		List of Tables
	Table 1: DCCP Packet Types . . . . . . . . . . . . . . . . . . . 25		Table 1: DCCP Packet Types . . . . . . . . . . . . . . . . . . . 25
	Table 2: DCCP Reset Codes. . . . . . . . . . . . . . . . . . . . 32		Table 2: DCCP Reset Codes. . . . . . . . . . . . . . . . . . . . 32
	Table 3: DCCP Options. . . . . . . . . . . . . . . . . . . . . . 34		Table 3: DCCP Options. . . . . . . . . . . . . . . . . . . . . . 34
	Table 4: DCCP Feature Numbers. . . . . . . . . . . . . . . . . . 39		Table 4: DCCP Feature Numbers. . . . . . . . . . . . . . . . . . 39
	skipping to change at page 32, line 30 ¶		skipping to change at page 32, line 30 ¶
	10, "Bad Init Cookie"		10, "Bad Init Cookie"
	The Init Cookie echoed by the client was incorrect or missing.		The Init Cookie echoed by the client was incorrect or missing.
	See Section 8.1.4.		See Section 8.1.4.
	11, "Aggression Penalty"		11, "Aggression Penalty"
	This endpoint has detected congestion control-related		This endpoint has detected congestion control-related
	misbehavior on the part of the other endpoint. See Section		misbehavior on the part of the other endpoint. See Section
	12.3.		12.3.
	12-127, Reserved		12-127, Reserved
	Receivers should treat these codes like Reset Code 0,		Receivers should treat these codes as they do Reset Code 0,
	"Unspecified".		"Unspecified".
	128-255, CCID-specific codes		128-255, CCID-specific codes
	Semantics depend on the connection's CCIDs. See Section 10.3.		Semantics depend on the connection's CCIDs. See Section 10.3.
	Receivers should treat unknown CCID-specific Reset Codes like		Receivers should treat unknown CCID-specific Reset Codes as they
	Reset Code 0, "Unspecified".		do Reset Code 0, "Unspecified".
	The following table summarizes this information.		The following table summarizes this information.
	Reset		Reset
	Code Name Data 1 Data 2 & 3		Code Name Data 1 Data 2 & 3
	----- ---- ------ ----------		----- ---- ------ ----------
	0 Unspecified 0 0		0 Unspecified 0 0
	1 Closed 0 0		1 Closed 0 0
	2 Aborted 0 0		2 Aborted 0 0
	3 No Connection 0 0		3 No Connection 0 0
	skipping to change at page 63, line 36 ¶		skipping to change at page 63, line 36 ¶
	the application running on a nonstandard port (assuming the DCCP		the application running on a nonstandard port (assuming the DCCP
	header has not been encrypted).		header has not been encrypted).
	Endpoints MUST associate a Service Code with every DCCP socket, both		Endpoints MUST associate a Service Code with every DCCP socket, both
	actively and passively opened. The application will generally		actively and passively opened. The application will generally
	supply this Service Code. Each active socket MUST have exactly one		supply this Service Code. Each active socket MUST have exactly one
	Service Code. Passive sockets MAY, at the implementation's		Service Code. Passive sockets MAY, at the implementation's
	discretion, be associated with more than one Service Code; this		discretion, be associated with more than one Service Code; this
	might let multiple applications, or multiple versions of the same		might let multiple applications, or multiple versions of the same
	application, listen on the same port, differentiated by Service		application, listen on the same port, differentiated by Service
	Code. If the DCCP-Request's Service Code doesn't match any of the		Code. If the DCCP-Request's Service Code doesn't equal any of the
	server's Service Codes for the given port, the server MUST reject		server's Service Codes for the given port, the server MUST reject
	the request by sending a DCCP-Reset packet with Reset Code 8, "Bad		the request by sending a DCCP-Reset packet with Reset Code 8, "Bad
	Service Code". A middlebox MAY also send such a DCCP-Reset in		Service Code". A middlebox MAY also send such a DCCP-Reset in
	response to packets whose Service Code is considered unsuitable.		response to packets whose Service Code is considered unsuitable.
	Service Codes are not intended to be DCCP-specific, and are		Service Codes are not intended to be DCCP-specific, and are
	allocated by IANA. Following the policies outlined in RFC 2434,		allocated by IANA. Following the policies outlined in RFC 2434,
	most Service Codes are allocated First Come First Served, subject to		most Service Codes are allocated First Come First Served, subject to
	the following guidelines.		the following guidelines.
	skipping to change at page 64, line 24 ¶		skipping to change at page 64, line 24 ¶
	standards-track specifications, IETF or otherwise. (This set		standards-track specifications, IETF or otherwise. (This set
	consists of the ASCII digits, uppercase letters, and characters		consists of the ASCII digits, uppercase letters, and characters
	space, '-', '.', and '/'.)		space, '-', '.', and '/'.)
	o Service Codes whose high-order byte equals 63 (ASCII '?') are		o Service Codes whose high-order byte equals 63 (ASCII '?') are
	reserved for Private Use.		reserved for Private Use.
	o Service Code 0 represents the absence of a meaningful Service		o Service Code 0 represents the absence of a meaningful Service
	Code, and MUST NOT be allocated.		Code, and MUST NOT be allocated.
	o The value 4294967295 is an invalid Service Code, and MUST NOT		o The value 4294967295 is an invalid Service Code. Servers MUST
	appear in the Service Code field of a DCCP-Request or DCCP-		reject any DCCP-Request with this Service Code value by sending a
	Response packet.		DCCP-Reset packet with Reset Code 8, "Bad Service Code".
	This design for Service Code allocation is based on the allocation		This design for Service Code allocation is based on the allocation
	of 4-byte identifiers for Macintosh resources, PNG chunks, and		of 4-byte identifiers for Macintosh resources, PNG chunks, and
	TrueType and OpenType tables.		TrueType and OpenType tables.
	In text settings, we recommend that Service Codes be written in one		In text settings, we recommend that Service Codes be written in one
	of three forms, prefixed by the ASCII letters SC and either a colon		of three forms, prefixed by the ASCII letters SC and either a colon
	":" or equals sign "=". These forms are interpreted as follows.		":" or equals sign "=". These forms are interpreted as follows.
	SC: Indicates a Service Code representable using a subset of the		SC: Indicates a Service Code representable using a subset of the
	skipping to change at page 72, line 36 ¶		skipping to change at page 72, line 36 ¶
	If the packet type is not understood, drop packet and return		If the packet type is not understood, drop packet and return
	If P.Data Offset is too small for packet type, or too large for		If P.Data Offset is too small for packet type, or too large for
	packet, drop packet and return		packet, drop packet and return
	If P.type is not Data, Ack, or DataAck and P.X == 0 (the packet		If P.type is not Data, Ack, or DataAck and P.X == 0 (the packet
	has short sequence numbers), drop packet and return		has short sequence numbers), drop packet and return
	If the header checksum is incorrect, drop packet and return		If the header checksum is incorrect, drop packet and return
	If P.CsCov is too large for the packet size, drop packet and		If P.CsCov is too large for the packet size, drop packet and
	return		return
	Step 2: Check ports and process TIMEWAIT state		Step 2: Check ports and process TIMEWAIT state
			/* Flow ID is <src addr, src port, dst addr, dst port> 4-tuple */
	Look up flow ID in table and get corresponding socket		Look up flow ID in table and get corresponding socket
	If no socket, or S.state == TIMEWAIT,		If no socket, or S.state == TIMEWAIT,
	Generate Reset(No Connection) unless P.type == Reset		Generate Reset(No Connection) unless P.type == Reset
	Drop packet and return		Drop packet and return
	Step 3: Process LISTEN state		Step 3: Process LISTEN state
	If S.state == LISTEN,		If S.state == LISTEN,
	If P.type == Request or P contains a valid Init Cookie option,		If P.type == Request or P contains a valid Init Cookie option,
	/* Must scan the packet's options to check for an Init		/* Must scan the packet's options to check for an Init
	Cookie. Only the Init Cookie is processed here,		Cookie. Only the Init Cookie is processed here,
	skipping to change at page 111, line 32 ¶		skipping to change at page 111, line 32 ¶
	the same headers currently defined. The 4 byte header cost is a		the same headers currently defined. The 4 byte header cost is a
	reasonable tradeoff for DCCP's congestion control features and		reasonable tradeoff for DCCP's congestion control features and
	access to ECN. Truly bandwidth-starved endpoints should use some		access to ECN. Truly bandwidth-starved endpoints should use some
	future header compression scheme.		future header compression scheme.
	17.2. Congestion Manager and Multiplexing		17.2. Congestion Manager and Multiplexing
	Since DCCP doesn't provide reliable, ordered delivery, multiple		Since DCCP doesn't provide reliable, ordered delivery, multiple
	application sub-flows may be multiplexed over a single DCCP		application sub-flows may be multiplexed over a single DCCP
	connection with no inherent performance penalty. Thus, there is no		connection with no inherent performance penalty. Thus, there is no
	need for DCCP to provide built-in, SCTP-style support for multiple		need for DCCP to provide built-in support for multiple sub-flows.
	sub-flows.		This differs from SCTP [RFC 2960].
	Some applications might want to share congestion control state among		Some applications might want to share congestion control state among
	multiple DCCP flows that share the same source and destination		multiple DCCP flows that share the same source and destination
	addresses. This functionality could be provided by the Congestion		addresses. This functionality could be provided by the Congestion
	Manager [RFC 3124], a generic multiplexing facility. However, the		Manager [RFC 3124], a generic multiplexing facility. However, the
	CM would not fully support DCCP without change; it does not		CM would not fully support DCCP without change; it does not
	gracefully handle multiple congestion control mechanisms, for		gracefully handle multiple congestion control mechanisms, for
	example.		example.
	18. Security Considerations		18. Security Considerations
	skipping to change at page 116, line 46 ¶		skipping to change at page 116, line 46 ¶
	requested as early as possible.		requested as early as possible.
	Each port registration SHALL include the following information:		Each port registration SHALL include the following information:
	o A short port name, consisting entirely of letters (A-Z and a-z),		o A short port name, consisting entirely of letters (A-Z and a-z),
	digits (0-9), and punctuation characters from "-_+./*" (not		digits (0-9), and punctuation characters from "-_+./*" (not
	including the quotes).		including the quotes).
	o The port number that is requested to be registered.		o The port number that is requested to be registered.
	o A short English phrase describing the port's purpose. This		o A short English phrase describing the port's purpose. This MUST
	SHOULD include one or more space-separated textual Service Code		include one or more space-separated textual Service Code
	descriptors naming the port's corresponding Service Codes (see		descriptors naming the port's corresponding Service Codes (see
	Section 8.1.2).		Section 8.1.2).
	o Name and contact information for the person or entity performing		o Name and contact information for the person or entity performing
	the registration, and possibly a reference to a document defining		the registration, and possibly a reference to a document defining
	the port's use. Registrations coming from IETF working groups		the port's use. Registrations coming from IETF working groups
	need only name the working group, but it is also recommended to		need only name the working group, but it is also recommended to
	indicate a contact person.		indicate a contact person.
	Registrants are encouraged to follow these guidelines when		Registrants are encouraged to follow these guidelines when
	submitting a registration:		submitting a registration. The guidelines may be violated at IANA's
			discretion.
	o A port name SHOULD NOT be registered for more than one DCCP port		o A port name SHOULD NOT be registered for more than one DCCP port
	number.		number.
	o A port name registered for UDP MAY be registered for DCCP as		o A port name registered for UDP MAY be registered for DCCP as
	well. Any such registration SHOULD use the same port number as		well. Any such registration SHOULD use the same port number as
	the existing UDP registration.		the existing UDP registration.
	o Concrete intent to use a port SHOULD precede port registration.		o Concrete intent to use a port SHOULD precede port registration.
	For example, existing UDP ports SHOULD NOT be registered in		For example, existing UDP ports SHOULD NOT be registered in
	skipping to change at page 119, line 30 ¶		skipping to change at page 119, line 30 ¶
	We draw acknowledgement buffers like this:		We draw acknowledgement buffers like this:
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	|S,L|S,L|S,L|S,L| | | | |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|		|S,L|S,L|S,L|S,L| | | | |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	^ ^		^ ^
	buf_tail buf_head, buf_ackno = A buf_nonce = E		buf_tail buf_head, buf_ackno = A buf_nonce = E
	<=== buf_head and buf_tail move this way <===		<=== buf_head and buf_tail move this way <===
	Each `S,L' represents a State/Run length byte. We will draw these		Each "S,L" represents a State/Run length byte. We will draw these
	buffers showing only their live portion, and will add an annotation		buffers showing only their live portion, and will add an annotation
	showing the Acknowledgement Number for the last live byte in the		showing the Acknowledgement Number for the last live byte in the
	buffer. For example:		buffer. For example:
	+-----------------------------------------------+		+-----------------------------------------------+
	A |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| T BN[E]		A |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| T BN[E]
	+-----------------------------------------------+		+-----------------------------------------------+
	Here, buf_nonce equals E and buf_ackno equals A.		Here, buf_nonce equals E and buf_ackno equals A.
End of changes. 17 change blocks.
	23 lines changed or deleted		25 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/