draft-ietf-ippm-owdp-12.txt		draft-ietf-ippm-owdp-13.txt
	Network Working Group Stanislav Shalunov		Network Working Group Stanislav Shalunov
	Internet Draft Benjamin Teitelbaum		Internet Draft Benjamin Teitelbaum
	Expiration Date: June 2005 Anatoly Karp		Expiration Date: June 2005 Anatoly Karp
	Jeff W. Boote		Jeff W. Boote
	Matthew J. Zekauskas		Matthew J. Zekauskas
	Internet2		Internet2
	December 2004		December 2004
	A One-way Active Measurement Protocol (OWAMP)		A One-way Active Measurement Protocol (OWAMP)
	<draft-ietf-ippm-owdp-12.txt>		<draft-ietf-ippm-owdp-13.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 2, line 13		skipping to change at page 2, line 13
	well as other unidirectional characteristics, such as one-way loss.		well as other unidirectional characteristics, such as one-way loss.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Relationship of Test and Control Protocols . . . . . . 4		1.1. Relationship of Test and Control Protocols . . . . . . 4
	1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5		1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
	3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7		3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7		3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7
	3.2. Values of the Accept Field . . . . . . . . . . . . . . 10		3.2. Integrity Zero Padding (IZP) . . . . . . . . . . . . . 10
	3.3. OWAMP-Control Commands . . . . . . . . . . . . . . . . 11		3.3. Values of the Accept Field . . . . . . . . . . . . . . 11
	3.4. Creating Test Sessions . . . . . . . . . . . . . . . . 11		3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 11
	3.5. Send Schedules . . . . . . . . . . . . . . . . . . . . 16		3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 12
	3.6. Starting Test Sessions . . . . . . . . . . . . . . . . 17		3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 17
	3.7. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19		3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 18
	3.8. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22		3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19
	4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 26		3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22
	4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 26		4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 27
	4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 26		4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27
	4.1.2. Packet Format and Content . . . . . . . . . . . . 27		4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 27
	4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 30		4.1.2. Packet Format and Content . . . . . . . . . . . . 28
	5. Computing Exponentially Distributed Pseudo-Random Numbers . 32		4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31
	5.1. High-Level Description of the Algorithm . . . . . . . 32		5. Computing Exponentially Distributed Pseudo-Random Numbers . 33
	5.2. Data Types, Representation, and Arithmetic . . . . . . 33		5.1. High-Level Description of the Algorithm . . . . . . . 33
	5.3. Uniform Random Quantities . . . . . . . . . . . . . . 34		5.2. Data Types, Representation, and Arithmetic . . . . . . 34
	6. Security Considerations . . . . . . . . . . . . . . . . . . 35		5.3. Uniform Random Quantities . . . . . . . . . . . . . . 35
	6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 35		6. Security Considerations . . . . . . . . . . . . . . . . . . 36
	6.2. Preventing Third-Party Denial of Service . . . . . . . 36		6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 36
	6.3. Covert Information Channels . . . . . . . . . . . . . 36		6.2. Preventing Third-Party Denial of Service . . . . . . . 37
	6.4. Requirement to Include AES in Implementations . . . . 36		6.3. Covert Information Channels . . . . . . . . . . . . . 37
	6.5. Resource Use Limitations . . . . . . . . . . . . . . . 36		6.4. Requirement to Include AES in Implementations . . . . 37
	6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 37		6.5. Resource Use Limitations . . . . . . . . . . . . . . . 37
	6.7. Required Properties of MD5 . . . . . . . . . . . . . . 38		6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 38
	6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 40		6.7. Required Properties of MD5 . . . . . . . . . . . . . . 39
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41		6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 41
	8. Internationalization Considerations . . . . . . . . . . . . 41		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42
	9. Appendix A: Sample C Code for Exponential Deviates . . . . 41		8. Internationalization Considerations . . . . . . . . . . . . 42
	10. Appendix B: Test Vectors for Exponential Deviates . . . . 46		9. Appendix A: Sample C Code for Exponential Deviates . . . . 42
	11. Normative References . . . . . . . . . . . . . . . . . . . 47		10. Appendix B: Test Vectors for Exponential Deviates . . . . 47
	12. Informative References . . . . . . . . . . . . . . . . . . 47		11. Normative References . . . . . . . . . . . . . . . . . . . 48
	13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48		12. Informative References . . . . . . . . . . . . . . . . . . 48
			13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	The IETF IP Performance Metrics (IPPM) working group has proposed		The IETF IP Performance Metrics (IPPM) working group has proposed
	draft standard metrics for one-way packet delay [RFC2679] and loss		draft standard metrics for one-way packet delay [RFC2679] and loss
	[RFC2680] across Internet paths. Although there are now several		[RFC2680] across Internet paths. Although there are now several
	measurement platforms that implement collection of these metrics		measurement platforms that implement collection of these metrics
	[SURVEYOR], [RIPE], there is not currently a standard that would		[SURVEYOR] [RIPE] [BRIX], there is not currently a standard that
	permit initiation of test streams or exchange of packets to collect		would permit initiation of test streams or exchange of packets to
	singleton metrics in an interoperable manner.		collect singleton metrics in an interoperable manner.
	With the increasingly wide availability of affordable global		With the increasingly wide availability of affordable global
	positioning systems (GPS) and CDMA-based time sources, hosts		positioning systems (GPS) and CDMA-based time sources, hosts
	increasingly have available to them very accurate time		increasingly have available to them very accurate time
	sources--either directly or through their proximity to Network Time		sources--either directly or through their proximity to Network Time
	Protocol (NTP) primary (stratum 1) time servers. By standardizing a		Protocol (NTP) primary (stratum 1) time servers. By standardizing a
	technique for collecting IPPM one-way active measurements, we hope to		technique for collecting IPPM one-way active measurements, we hope to
	create an environment where IPPM metrics may be collected across a		create an environment where IPPM metrics may be collected across a
	far broader mesh of Internet paths than is currently possible. One		far broader mesh of Internet paths than is currently possible. One
	particularly compelling vision is of widespread deployment of open		particularly compelling vision is of widespread deployment of open
	OWAMP servers that would make measurement of one-way delay as		OWAMP servers that would make measurement of one-way delay as
	commonplace as measurement of round-trip time using an ICMP-based		commonplace as measurement of round-trip time using an ICMP-based
	tool like ping.		tool like ping.
	Additional design goals of OWAMP include being hard to detect and		Additional design goals of OWAMP include being hard to detect and
	manipulate, security, logical separation of control and test		manipulate, security, logical separation of control and test
	functionality, and support for small test packets.		functionality, and support for small test packets. (Being hard to
			detect makes interference with measurements more difficult for
			intermediaries in the middle of the network.)
	OWAMP test traffic is hard to detect because it is simply a stream of		OWAMP test traffic is hard to detect because it is simply a stream of
	UDP packets from and to negotiated port numbers, with potentially		UDP packets from and to negotiated port numbers, with potentially
	nothing static in the packets (size is negotiated, as well). OWAMP		nothing static in the packets (size is negotiated, as well). OWAMP
	also supports an encrypted mode that further obscures the traffic, at		also supports an encrypted mode that further obscures the traffic, at
	the same time making it impossible to alter timestamps undetectably.		the same time making it impossible to alter timestamps undetectably.
	Security features include optional authentication and/or encryption		Security features include optional authentication and/or encryption
	of control and test messages. These features may be useful to		of control and test messages. These features may be useful to
	prevent unauthorized access to results or man-in-the-middle attackers		prevent unauthorized access to results or man-in-the-middle attackers
	skipping to change at page 9, line 11		skipping to change at page 9, line 11
	that is the shared secret associated with Username. (Both the server		that is the shared secret associated with Username. (Both the server
	and the client use the same mappings from user names to secret keys.		and the client use the same mappings from user names to secret keys.
	The server, being prepared to conduct sessions with more than one		The server, being prepared to conduct sessions with more than one
	client, uses user names to choose the appropriate secret key; a		client, uses user names to choose the appropriate secret key; a
	client would typically have different secret keys for different		client would typically have different secret keys for different
	servers. The situation is analogous to that of passwords, except		servers. The situation is analogous to that of passwords, except
	that secret keys, rather than being the typical low-entropy		that secret keys, rather than being the typical low-entropy
	passwords, are suitable for use as AES keys.) The shared secret will		passwords, are suitable for use as AES keys.) The shared secret will
	typically be provided as a passphrase; in this case, the MD5 sum		typically be provided as a passphrase; in this case, the MD5 sum
	[RFC1321] of the passphrase (without possible newline character(s) at		[RFC1321] of the passphrase (without possible newline character(s) at
	the end of the passphrase) SHOULD be used as a key for encryption by		the end of the passphrase) MUST be used as a key for encryption by
	the client and decryption by the server (the passphrase also SHOULD		the client and decryption by the server (the passphrase also MUST NOT
	NOT contain newlines in the middle).		contain newlines in the middle).
	Session-key and Client-IV are generated randomly by the client.		Session-key and Client-IV are generated randomly by the client.
	Session-key MUST be generated with sufficient entropy not to reduce		Session-key MUST be generated with sufficient entropy not to reduce
	the security of the underlying cipher. Client-IV merely needs to be		the security of the underlying cipher. Client-IV merely needs to be
	unique (i.e., it MUST never be repeated for different sessions using		unique (i.e., it MUST never be repeated for different sessions using
	the same secret key; a simple way to achieve that without the use of		the same secret key; a simple way to achieve that without the use of
	cumbersome state is to generate the Client-IV strings using a		cumbersome state is to generate the Client-IV strings using a
	cryptographically secure pseudo-random number source: if this is		cryptographically secure pseudo-random number source: if this is
	done, the first repetition is unlikely to occur before 2^64 sessions		done, the first repetition is unlikely to occur before 2^64 sessions
	with the same secret key are conducted).		with the same secret key are conducted).
	The server MUST respond with the following message:		The server MUST respond with the following message:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Unused, MBZ (15 octets) |		| MBZ (15 octets) |
	| |		| |
	| +-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+
	| | Accept |		| | Accept |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Server-IV (16 octets) |		| Server-IV (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Uptime (Timestamp) |		| Uptime (Timestamp) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IZP (8 octets) |		| IZP (8 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Unused 15-octet part MUST be zero. The client MUST ignore its		The MBZ 15-octet part MUST be zero. The client MUST ignore its
	value. MBZ (MUST be zero) fields here and hereafter have the same		value. MBZ (MUST be zero) fields here and hereafter have the same
	semantics: the party that sends the message MUST set the field to a		semantics: the party that sends the message MUST set the field to a
	string of zero bits; the party that interprets the message MUST		string of zero bits; the party that interprets the message MUST
	ignore the value. (This way the field could be used for future		ignore the value. (This way the field could be used for future
	extensions.)		extensions.)
	Server-IV is generated randomly by the server. In unauthenticated		Server-IV is generated randomly by the server. In unauthenticated
	mode, Server-IV is unused.		mode, Server-IV is unused.
	The Accept field indicates the server's willingness to continue		The Accept field indicates the server's willingness to continue
	skipping to change at page 10, line 40		skipping to change at page 10, line 40
	Timestamp format is described in ``Sender Behavior'' section below.		Timestamp format is described in ``Sender Behavior'' section below.
	The same instantiation of the server SHOULD report the same exact		The same instantiation of the server SHOULD report the same exact
	Uptime value to each client in each session.		Uptime value to each client in each session.
	Integrity Zero Padding (IZP) is treated the same way as IZP in the		Integrity Zero Padding (IZP) is treated the same way as IZP in the
	next section and beyond.		next section and beyond.
	The previous transactions constitute connection setup.		The previous transactions constitute connection setup.
	3.2. Values of the Accept Field		3.2. Integrity Zero Padding (IZP)
			IZP MUST be all zeros in all messages that use IZP. The recipient of
			a message where IZP is not zero MUST reject the message, as it is an
			indication of tampering with the content of the message by an
			intermediary (or brokenness). If the message is part of
			OWAMP-Control, the session MUST be terminated and results
			invalidated. If the message is part of OWAMP-Test, it MUST be
			silently ignored. This will ensure data integrity. In
			unauthenticated mode, IZP is nothing more than a simple check. In
			authenticated and encrypted modes, however, it ensures, in
			conjunction with properties of CBC chaining mode, that everything
			received before was not tampered with. For this reason, it is
			important to check the IZP field as soon as possible, so that bad
			data doesn't get propagated.
			3.3. Values of the Accept Field
	Accept values are used throughout the OWAMP-Control protocol to		Accept values are used throughout the OWAMP-Control protocol to
	communicate the server response to client requests. The full set of		communicate the server response to client requests. The full set of
	valid Accept field values are:		valid Accept field values are:
	0 OK.		0 OK.
	1 Failure, reason unspecified (catch-all).		1 Failure, reason unspecified (catch-all).
	2 Internal error.		2 Internal error.
	skipping to change at page 11, line 18		skipping to change at page 11, line 34
	5 Cannot perform request due to temporary resource limitations.		5 Cannot perform request due to temporary resource limitations.
	All other values are reserved. The sender of the message MAY use the		All other values are reserved. The sender of the message MAY use the
	value of 1 for all non-zero Accept values. A message sender SHOULD		value of 1 for all non-zero Accept values. A message sender SHOULD
	use the correct Accept value if it is going to use other values. The		use the correct Accept value if it is going to use other values. The
	message receiver MUST interpret all values of Accept other than these		message receiver MUST interpret all values of Accept other than these
	reserved values as 1. This way, other values are available for		reserved values as 1. This way, other values are available for
	future extensions.		future extensions.
	3.3. OWAMP-Control Commands		3.4. OWAMP-Control Commands
	In authenticated or encrypted mode (which are identical as far as		In authenticated or encrypted mode (which are identical as far as
	OWAMP-Control is concerned, and only differ in OWAMP-Test) all		OWAMP-Control is concerned, and only differ in OWAMP-Test) all
	further communications are encrypted with the Session-key, using CBC		further communications are encrypted with the Session-key, using CBC
	mode. The client encrypts its stream using Client-IV. The server		mode. The client encrypts its stream using Client-IV. The server
	encrypts its stream using Server-IV.		encrypts its stream using Server-IV.
	The following commands are available for the client: Request-Session,		The following commands are available for the client: Request-Session,
	Start-Sessions, Stop-Sessions, and Fetch-Session. The command		Start-Sessions, Stop-Sessions, and Fetch-Session. The command
	Stop-Sessions is available to both the client and the server. (The		Stop-Sessions is available to both the client and the server. (The
	server can also send other messages in response to commands it		server can also send other messages in response to commands it
	receives.)		receives.)
	After Start-Sessions is sent/received by the client/server, and		After the client sends the Start-Sessions command and until it both
	before it both sends and receives Stop-Sessions (order unspecified),		sends and receives (in an unspecified order) the Stop-Sessions
	it is said to be conducting active measurements.		command, it is said to be conducting active measurements. Similarly,
			the server is said to be conducting active measurements after it
			receives the Start-Sessions command and until it both sends and
			receives (in an unspecified order) the Stop-Sessions command.
	While conducting active measurements, the only command available is		While conducting active measurements, the only command available is
	Stop-Sessions.		Stop-Sessions.
	These commands are described in detail below.		These commands are described in detail below.
	3.4. Creating Test Sessions		3.5. Creating Test Sessions
	Individual one-way active measurement sessions are established using		Individual one-way active measurement sessions are established using
	a simple request/response protocol. An OWAMP client MAY issue zero or		a simple request/response protocol. An OWAMP client MAY issue zero or
	more Request-Session messages to an OWAMP server, which MUST respond		more Request-Session messages to an OWAMP server, which MUST respond
	to each with an Accept-Session message. An Accept-Session message		to each with an Accept-Session message. An Accept-Session message
	MAY refuse a request.		MAY refuse a request.
	The format of Request-Session message is as follows:		The format of Request-Session message is as follows:
	0 1 2 3		0 1 2 3
	skipping to change at page 12, line 19		skipping to change at page 13, line 19
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Schedule Slots |		| Number of Schedule Slots |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Packets |		| Number of Packets |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Port | Receiver Port |		| Sender Port | Receiver Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Address |		| Sender Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Sender Address (cont.) or MBZ |		| Sender Address (cont.) or MBZ (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Receiver Address |		| Receiver Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Receiver Address (cont.) or MBZ |		| Receiver Address (cont.) or MBZ (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| SID (16 octets) |		| SID (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Padding Length |		| Padding Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Start Time |		| Start Time |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timeout |		| Timeout, (8 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type-P Descriptor |		| Type-P Descriptor |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MBZ |		| MBZ (8 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IZP (16 octets) |		| IZP (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	This is immediately followed by one or more schedule slot		This is immediately followed by one or more schedule slot
	descriptions (the number of schedule slots is specified in the		descriptions (the number of schedule slots is specified in the
	`Number of Schedule Slots' field above):		`Number of Schedule Slots' field above):
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Slot Type | |		| Slot Type | |
	+-+-+-+-+-+-+-+-+ MBZ |		+-+-+-+-+-+-+-+-+ MBZ (15 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Slot Parameter (Timestamp) |		| Slot Parameter (Timestamp) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	These are immediately followed by IZP:		These are immediately followed by IZP:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	skipping to change at page 15, line 12		skipping to change at page 16, line 12
	Conf-Sender is not set, the Type-P Descriptor is a declaration of how		Conf-Sender is not set, the Type-P Descriptor is a declaration of how
	the sender will be configured.		the sender will be configured.
	If Conf-Sender is set and the server does not recognize the Type-P		If Conf-Sender is set and the server does not recognize the Type-P
	Descriptor, or it cannot or does not wish to set the corresponding		Descriptor, or it cannot or does not wish to set the corresponding
	attributes on OWAMP-Test packets, it SHOULD reject the session		attributes on OWAMP-Test packets, it SHOULD reject the session
	request. If Conf-Sender is not set, the server SHOULD accept or		request. If Conf-Sender is not set, the server SHOULD accept or
	reject the session paying no attention to the value of the Type-P		reject the session paying no attention to the value of the Type-P
	Descriptor.		Descriptor.
	IZP MUST be all zeros in this and all messages that use IZP. The
	recipient of a message where IZP is not zero MUST reject the message,
	as it is an indication of tampering with the content of the message
	by an intermediary (or brokenness). If the message is part of
	OWAMP-Control, the session MUST be terminated and results
	invalidated. If the message is part of OWAMP-Test, it MUST be
	silently ignored. This will ensure data integrity. In
	unauthenticated mode, IZP is nothing more than a simple check. In
	authenticated and encrypted modes, however, it ensures, in
	conjunction with properties of CBC chaining mode, that everything
	received before was not tampered with. For this reason, it is
	important to check the IZP field as soon as possible, so that bad
	data doesn't get propagated.
	To each Request-Session message, an OWAMP server MUST respond with an		To each Request-Session message, an OWAMP server MUST respond with an
	Accept-Session message:		Accept-Session message:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Accept | Unused | Port |		| Accept | MBZ | Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	| |		| |
	| SID (16 octets) |		| SID (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IZP (12 octets) |		| IZP (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 16, line 27		skipping to change at page 17, line 12
	number belonging to the generating machine, an 8-octet timestamp, and		number belonging to the generating machine, an 8-octet timestamp, and
	a 4-octet random value. To reduce the probability of collisions, if		a 4-octet random value. To reduce the probability of collisions, if
	the generating machine has any IPv4 addresses (with the exception of		the generating machine has any IPv4 addresses (with the exception of
	loopback), one of them SHOULD be used for SID generation, even if all		loopback), one of them SHOULD be used for SID generation, even if all
	communication is IPv6-based. If it has no IPv4 addresses at all, the		communication is IPv6-based. If it has no IPv4 addresses at all, the
	last four octets of an IPv6 address MAY be used instead. Note that		last four octets of an IPv6 address MAY be used instead. Note that
	SID is always chosen by the receiver. If truly random values are not		SID is always chosen by the receiver. If truly random values are not
	available, it is important that the SID be made unpredictable, as		available, it is important that the SID be made unpredictable, as
	knowledge of the SID might be used for access control.		knowledge of the SID might be used for access control.
	3.5. Send Schedules		3.6. Send Schedules
	The sender and the receiver both need to know the same send schedule.		The sender and the receiver both need to know the same send schedule.
	This way, when packets are lost, the receiver knows when they were		This way, when packets are lost, the receiver knows when they were
	supposed to be sent. It is desirable to compress common schedules		supposed to be sent. It is desirable to compress common schedules
	and still to be able to use an arbitrary one for the test sessions.		and still to be able to use an arbitrary one for the test sessions.
	In many cases, the schedule will consist of repeated sequences of		In many cases, the schedule will consist of repeated sequences of
	packets: this way, the sequence performs some test, and the test is		packets: this way, the sequence performs some test, and the test is
	repeated a number of times to gather statistics.		repeated a number of times to gather statistics.
	To implement this, we have a schedule with a given number of slots.		To implement this, we have a schedule with a given number of slots.
	skipping to change at page 17, line 29		skipping to change at page 18, line 17
	+ Periodic stream: a single slot of type 1;		+ Periodic stream: a single slot of type 1;
	+ Poisson stream of back-to-back packet pairs: two slots -- type 0		+ Poisson stream of back-to-back packet pairs: two slots -- type 0
	with a non-zero parameter and type 1 with a zero parameter.		with a non-zero parameter and type 1 with a zero parameter.
	Further, a completely arbitrary schedule can be specified (albeit		Further, a completely arbitrary schedule can be specified (albeit
	inefficiently) by making the number of test packets equal to the		inefficiently) by making the number of test packets equal to the
	number of schedule slots. In this case, the complete schedule is		number of schedule slots. In this case, the complete schedule is
	transmitted in advance of an OWAMP-Test session.		transmitted in advance of an OWAMP-Test session.
	3.6. Starting Test Sessions		3.7. Starting Test Sessions
	Having requested one or more test sessions and received affirmative		Having requested one or more test sessions and received affirmative
	Accept-Session responses, an OWAMP client MAY start the execution of		Accept-Session responses, an OWAMP client MAY start the execution of
	the requested test sessions by sending a Start-Sessions message to		the requested test sessions by sending a Start-Sessions message to
	the server.		the server.
	The format of this message is as follows:		The format of this message is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2 | |		| 2 | |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ |
	| Unused (15 octets) |		| MBZ (15 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IZP (16 octets) |		| IZP (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The server MUST respond with an Start-Ack message (which SHOULD be		The server MUST respond with an Start-Ack message (which SHOULD be
	sent as quickly as possible). Start-Ack messages have the following		sent as quickly as possible). Start-Ack messages have the following
	format:		format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Accept | |		| Accept | |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ |
	| Unused (15 octets) |		| MBZ (15 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IZP (16 octets) |		| IZP (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	If Accept is non-zero, the Start-Sessions request was rejected; zero		If Accept is non-zero, the Start-Sessions request was rejected; zero
	skipping to change at page 19, line 5		skipping to change at page 19, line 35
	The server SHOULD start all OWAMP-Test streams immediately after it		The server SHOULD start all OWAMP-Test streams immediately after it
	sends the response or immediately after their specified start times,		sends the response or immediately after their specified start times,
	whichever is later. If the client represents a Sender, the client		whichever is later. If the client represents a Sender, the client
	SHOULD start its OWAMP-Test streams immediately after it sees the		SHOULD start its OWAMP-Test streams immediately after it sees the
	Start-Ack response from the Server (if the Start-Sessions command was		Start-Ack response from the Server (if the Start-Sessions command was
	accepted) or immediately after their specified start times, whichever		accepted) or immediately after their specified start times, whichever
	is later. See more on OWAMP-Test sender behavior in a separate		is later. See more on OWAMP-Test sender behavior in a separate
	section below.		section below.
	3.7. Stop-Sessions		3.8. Stop-Sessions
	The Stop-Sessions message may be issued by either the Control-Client		The Stop-Sessions message may be issued by either the Control-Client
	or the Server. The format of this command is as follows:		or the Server. The format of this command is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 3 | Accept | Unused |		| 3 | Accept | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Sessions |		| Number of Sessions |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Unused (8 octets) |		| MBZ (8 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	This is immediately followed by zero or more session description		This is immediately followed by zero or more session description
	records (the number of session description records is specified in		records (the number of session description records is specified in
	the ``Number of Sessions'' field above). The session description		the ``Number of Sessions'' field above). The session description
	record is used to indicate which packets were actually sent by the		record is used to indicate which packets were actually sent by the
	sender process (rather than skipped). The header of the session		sender process (rather than skipped). The header of the session
	description record is as follows:		description record is as follows:
	skipping to change at page 22, line 20		skipping to change at page 22, line 43
	completed time for send endpoints to ensure the Stop-Sessions message		completed time for send endpoints to ensure the Stop-Sessions message
	reaches the receiver endpoint after Timeout.		reaches the receiver endpoint after Timeout.
	To effect a premature stop of sessions, the party that initiates this		To effect a premature stop of sessions, the party that initiates this
	command MUST stop its OWAMP-Test send streams to send the Session		command MUST stop its OWAMP-Test send streams to send the Session
	Packets Sent values before sending this command. That party SHOULD		Packets Sent values before sending this command. That party SHOULD
	wait until receiving the response Stop-Sessions message before		wait until receiving the response Stop-Sessions message before
	stopping the receiver streams so that it can use the values from the		stopping the receiver streams so that it can use the values from the
	received Stop-Sessions message to validate the data.		received Stop-Sessions message to validate the data.
	3.8. Fetch-Session		3.9. Fetch-Session
	The format of this client command is as follows:		The format of this client command is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 4 | |		| 4 | |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ |
	| Unused (7 octets) |		| MBZ (7 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Begin Seq |		| Begin Seq |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| End Seq |		| End Seq |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| SID (16 octets) |		| SID (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 23, line 18		skipping to change at page 24, line 8
	between Start-Sessions and Stop-Sessions, incomplete requests can		between Start-Sessions and Stop-Sessions, incomplete requests can
	only happen on a different OWAMP-Control connection (from the same or		only happen on a different OWAMP-Control connection (from the same or
	different host as Control-Client).		different host as Control-Client).
	The server MUST respond with a Fetch-Ack message. The format of this		The server MUST respond with a Fetch-Ack message. The format of this
	server response is as follows:		server response is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Accept | Finished | Unused (2 octets) |		| Accept | Finished | MBZ (2 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Seqno |		| Next Seqno |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Skip Ranges |		| Number of Skip Ranges |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Records |		| Number of Records |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IZP (16 octets) |		| IZP (16 octets) |
	| |		| |
	skipping to change at page 47, line 10		skipping to change at page 48, line 10
	SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)		SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
	SID = 0xfeed0feed1feed2feed3feed4feed5ab		SID = 0xfeed0feed1feed2feed3feed4feed5ab
	SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)		SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
	11. Normative References		11. Normative References
	[AES] Advanced Encryption Standard (AES),		[AES] Advanced Encryption Standard (AES),
	http://csrc.nist.gov/encryption/aes/		http://csrc.nist.gov/encryption/aes/
	[RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification,
	Implementation and Analysis', RFC 1305, March 1992.
	[RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321,		[RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321,
	April 1992.		April 1992.
	[RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3',		[RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3',
	RFC 2026, October 1996.		RFC 2026, October 1996.
	[RFC2119] S. Bradner, `Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, `Key words for use in RFCs to Indicate
	Requirement Levels', RFC 2119, March 1997.		Requirement Levels', RFC 2119, March 1997.
	[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for		[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for
	skipping to change at page 47, line 40		skipping to change at page 48, line 37
	Metric for IPPM', RFC 2679, September 1999.		Metric for IPPM', RFC 2679, September 1999.
	[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet		[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet
	Loss Metric for IPPM', RFC 2680, September 1999.		Loss Metric for IPPM', RFC 2680, September 1999.
	[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior		[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior
	Identification Codes', RFC 2836, May 2000.		Identification Codes', RFC 2836, May 2000.
	12. Informative References		12. Informative References
			[BRIX] Brix Networks, http://www.brixnet.com/
	[ZIGG] G. Marsaglia, M. Sibuya, and J. H. Ahrens, Communications of		[ZIGG] G. Marsaglia, M. Sibuya, and J. H. Ahrens, Communications of
	ACM, 15 (1972), 876-877.		ACM, 15 (1972), 876-877.
	[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone,		[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone,
	Handbook of Applied Cryptography, CRC Press, revised reprint		Handbook of Applied Cryptography, CRC Press, revised reprint
	with updates, 1997.		with updates, 1997.
	[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd		[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd
	edition, 1998.		edition, 1998.
	skipping to change at page 48, line 23		skipping to change at page 49, line 21
	Group Meeting,		Group Meeting,
	http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz.		http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz.
	[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.		[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
	[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An		[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An
	Infrastructure for Network Performance Measurements',		Infrastructure for Network Performance Measurements',
	Proceedings of INET'99, June 1999.		Proceedings of INET'99, June 1999.
	http://www.isoc.org/inet99/proceedings/4h/4h_2.htm		http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
			[RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification,
			Implementation and Analysis', RFC 1305, March 1992.
	13. Authors' Addresses		13. Authors' Addresses
	Stanislav Shalunov		Stanislav Shalunov
	Internet2		Internet2
	3025 Boardwalk Dr, Suite 200		1000 Oakbrook Drive, Suite 300
	Ann Arbor, MI 48108		Ann Arbor, MI 48104
	Telephone: +1-734-995-7060
	Email: shalunov@internet2.edu		Email: shalunov@internet2.edu
	SIP: shalunov@internet2.edu		SIP: shalunov@internet2.edu
	Benjamin Teitelbaum		Benjamin Teitelbaum
	Internet2		Internet2
	3025 Boardwalk Dr, Suite 200		1000 Oakbrook Drive, Suite 300
	Ann Arbor, MI 48108		Ann Arbor, MI 48104
	Email: ben@internet2.edu		Email: ben@internet2.edu
	SIP: ben@internet2.edu		SIP: ben@internet2.edu
	Anatoly Karp		Anatoly Karp
	4710 Regent St, Apt 81B		4710 Regent St, Apt 81B
	Madison, WI 53705		Madison, WI 53705
	Telephone: +1-608-347-6255		Telephone: +1-608-347-6255
	Email: ankarp@charter.net		Email: ankarp@charter.net
	Jeff W. Boote		Jeff W. Boote
	Internet2		Internet2
	3025 Boardwalk Dr, Suite 200		1000 Oakbrook Drive, Suite 300
	Ann Arbor, MI 48108		Ann Arbor, MI 48104
	Email: boote@internet2.edu		Email: boote@internet2.edu
	SIP: boote@internet2.edu		SIP: boote@internet2.edu
	Matthew J. Zekauskas		Matthew J. Zekauskas
	Internet2		Internet2
	3025 Boardwalk Dr, Suite 200		1000 Oakbrook Drive, Suite 300
	Ann Arbor, MI 48108		Ann Arbor, MI 48104
	Email: matt@internet2.edu		Email: matt@internet2.edu
			SIP: matt@internet2.edu
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be found		on the procedures with respect to rights in RFC documents can be found
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/