draft-ietf-ippm-connectivity-01.txt		draft-ietf-ippm-connectivity-02.txt
	Network Working Group J. Mahdavi, Pittsburgh Supercomputer Center		Network Working Group J. Mahdavi, Pittsburgh Supercomputer Center
	Internet Draft V. Paxson, Lawrence Berkeley National Laboratory		Internet Draft V. Paxson, Lawrence Berkeley National Laboratory
	Expiration Date: May 1998 November 1997		Expiration Date: February 1999 August 1998
	Connectivity		IPPM Metrics for Measuring Connectivity
	<draft-ietf-ippm-connectivity-01.txt>		<draft-ietf-ippm-connectivity-02.txt>
	1. Status of this Memo		1. 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.
	Internet Drafts are draft documents valid for a maximum of six		Internet Drafts are draft documents valid for a maximum of six
	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 reference		at any 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''.
	To learn the current status of any Internet Draft, please check the		To view the entire list of current Internet-Drafts, please check the
	``1id-abstracts.txt'' listing contained in the Internet Drafts shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or		Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
	ftp.isi.edu (US West Coast).		Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
	This memo provides information for the Internet community. This memo		This memo provides information for the Internet community. This memo
	does not specify an Internet standard of any kind. Distribution of		does not specify an Internet standard of any kind. Distribution of
	this memo is unlimited.		this memo is unlimited.
	2. Introduction		2. Introduction
	Connectivity is the basic stuff from which the Internet is made.		Connectivity is the basic stuff from which the Internet is made.
	Therefore, metrics determining whether pairs of hosts (IP addresses)		Therefore, metrics determining whether pairs of hosts (IP addresses)
	can reach each other must form the base of a measurement suite. We		can reach each other must form the base of a measurement suite. We
	define several such metrics, some of which serve mainly as building		define several such metrics, some of which serve mainly as building
	blocks for the others.		blocks for the others.
	This memo defines a series of metrics for connectivity between a pair		This memo defines a series of metrics for connectivity between a pair
	of Internet hosts. It builds on notions introduced and discussed in		of Internet hosts. It builds on notions introduced and discussed in
	the revised IPPM Framework document (currently <draft-ietf-ippm-		RFC 2330, the IPPM framework document. The reader is assumed to be
	framework-01.txt>); the reader is assumed to be familiar with that		familiar with that document.
	document.
	The structure of the memo is as follows:		The structure of the memo is as follows:
	ID Connectivity November 1997		ID IPPM Metrics for Measuring Connectivity August 1998
	+ An analytic metric, called Type-P-Instantaneous-Unidirectional-		+ An analytic metric, called Type-P-Instantaneous-Unidirectional-
	Connectivity, will be introduced to define one-way connectivity at		Connectivity, will be introduced to define one-way connectivity at
	one moment in time.		one moment in time.
	+ Using this metric, another analytic metric, called Type-P-		+ Using this metric, another analytic metric, called Type-P-
	Instantaneous-Bidirectional-Connectivity, will be introduced to		Instantaneous-Bidirectional-Connectivity, will be introduced to
	define two-way connectivity at one moment in time.		define two-way connectivity at one moment in time.
	+ Using these metrics, corresponding one- and two-way analytic		+ Using these metrics, corresponding one- and two-way analytic
	metrics are defined for connectivity over an interval of time.		metrics are defined for connectivity over an interval of time.
	+ Using these metrics, an analytic metric, called Type-P1-P2-		+ Using these metrics, an analytic metric, called Type-P1-P2-
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	3.3. Metric Units:		3.3. Metric Units:
	Boolean.		Boolean.
	3.4. Definition:		3.4. Definition:
	Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at		Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at
	time T if a type-P packet transmitted from Src to Dst at time T will		time T if a type-P packet transmitted from Src to Dst at time T will
	arrive at Dst.		arrive at Dst.
	ID Connectivity November 1997		ID IPPM Metrics for Measuring Connectivity August 1998
	3.5. Discussion:		3.5. Discussion:
	This metric is probably not directly useful, because it is		For most applications (e.g., any TCP connection) bidirectional
	instantaneous and unidirectional. For most applications,		connectivity is considerably more germane than unidirectional
	bidirectional connectivity is considerably more germane (e.g., any		connectivity, although unidirectional connectivity can be of interest
	TCP connection). Most applications also require connectivity over an		for some security applications (e.g., testing whether a firewall
	interval. Finally, one might not have instantaneous connectivity due		correctly filters out a "ping of death"). Most applications also
	to a transient event such as a full queue at a router, even if at		require connectivity over an interval, while this metric is
	nearby instants in time one does have connectivity. These points are		instantaneous, though, again, for some security applications
	addressed below, with this metric serving as a building block.		instantaneous connectivity remains of interest. Finally, one might
			not have instantaneous connectivity due to a transient event such as
			a full queue at a router, even if at nearby instants in time one does
			have connectivity. These points are addressed below, with this
			metric serving as a building block.
	Note also that we have not explicitly defined *when* the packet		Note also that we have not explicitly defined *when* the packet
	arrives at Dst. The TTL field in IP packets is meant to limit IP		arrives at Dst. The TTL field in IP packets is meant to limit IP
	packet lifetimes to 255 seconds (RFC 791). In practice the TTL field		packet lifetimes to 255 seconds (RFC 791). In practice the TTL field
	can be strictly a hop count (RFC 1812), with most Internet hops being		can be strictly a hop count (RFC 1812), with most Internet hops being
	much shorter than one second. This means that most packets will have		much shorter than one second. This means that most packets will have
	nowhere near the 255 second lifetime. In principle, however, it is		nowhere near the 255 second lifetime. In principle, however, it is
	also possible that packets might survive longer than 255 seconds.		also possible that packets might survive longer than 255 seconds.
	Consideration of packet lifetimes must be taken into account in		Consideration of packet lifetimes must be taken into account in
	attempts to measure the value of this metric.		attempts to measure the value of this metric.
	skipping to change at page 3, line 43		skipping to change at page 4, line 4
	have connectivity to Src. Such a methodology could reliably measure		have connectivity to Src. Such a methodology could reliably measure
	the unidirectional connectivity defined in this metric.		the unidirectional connectivity defined in this metric.
	4. Instantaneous Two-way Connectivity		4. Instantaneous Two-way Connectivity
	4.1. Metric Name:		4.1. Metric Name:
	Type-P-Instantaneous-Bidirectional-Connectivity		Type-P-Instantaneous-Bidirectional-Connectivity
	4.2. Metric Parameters:		4.2. Metric Parameters:
			ID IPPM Metrics for Measuring Connectivity August 1998
	+ A1, the IP address of a host		+ A1, the IP address of a host
	+ A2, the IP address of a host		+ A2, the IP address of a host
	+ T, a time		+ T, a time
	ID Connectivity November 1997
	4.3. Metric Units:		4.3. Metric Units:
	Boolean.		Boolean.
	4.4. Definition:		4.4. Definition:
	Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional-		Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional-
	Connectivity* at time T if address A1 has Type-P-Instantaneous-		Connectivity* at time T if address A1 has Type-P-Instantaneous-
	Unidirectional-Connectivity to address A2 and address A2 has Type-P-		Unidirectional-Connectivity to address A2 and address A2 has Type-P-
	Instantaneous-Unidirectional-Connectivity to address A1.		Instantaneous-Unidirectional-Connectivity to address A1.
	skipping to change at page 4, line 40		skipping to change at page 5, line 4
	development of interval-connectivity metrics below.		development of interval-connectivity metrics below.
	5. One-way Connectivity		5. One-way Connectivity
	5.1. Metric Name:		5.1. Metric Name:
	Type-P-Interval-Unidirectional-Connectivity		Type-P-Interval-Unidirectional-Connectivity
	5.2. Metric Parameters:		5.2. Metric Parameters:
	+ Src, the IP address of a host		+ Src, the IP address of a host
			ID IPPM Metrics for Measuring Connectivity August 1998
	+ Dst, the IP address of a host		+ Dst, the IP address of a host
	+ T, a time		+ T, a time
	+ dT, a duration		+ dT, a duration
	{Comment: Thus, the closed interval [T, T+dT] denotes a time		{Comment: Thus, the closed interval [T, T+dT] denotes a time
	interval.}		interval.}
	ID Connectivity November 1997
	5.3. Metric Units:		5.3. Metric Units:
	Boolean.		Boolean.
	5.4. Definition:		5.4. Definition:
	Address Src has *Type-P-Interval-Unidirectional-Connectivity* to		Address Src has *Type-P-Interval-Unidirectional-Connectivity* to
	address Dst during the interval [T, T+dT] if for some T' within [T,		address Dst during the interval [T, T+dT] if for some T' within [T,
	T+dT] it has Type-P-instantaneous-connectivity to Dst.		T+dT] it has Type-P-instantaneous-connectivity to Dst.
	skipping to change at page 6, line 5		skipping to change at page 6, line 5
	Boolean.		Boolean.
	6.4. Definition:		6.4. Definition:
	Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity*		Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity*
	between them during the interval [T, T+dT] if address A1 has Type-P-		between them during the interval [T, T+dT] if address A1 has Type-P-
	Interval-Unidirectional-Connectivity to address A2 during the		Interval-Unidirectional-Connectivity to address A2 during the
	interval and address A2 has Type-P-Interval-Unidirectional-		interval and address A2 has Type-P-Interval-Unidirectional-
	Connectivity to address A1 during the interval.		Connectivity to address A1 during the interval.
	ID Connectivity November 1997		ID IPPM Metrics for Measuring Connectivity August 1998
	6.5. Discussion:		6.5. Discussion:
	This metric is not quite what's needed for defining "useful"		This metric is not quite what's needed for defining "generally
	connectivity - that requires the notion that a packet sent from A1 to		useful" connectivity - that requires the notion that a packet sent
	A2 can elicit a response from A2 that will reach A1. With this		from A1 to A2 can elicit a response from A2 that will reach A1. With
	definition, it could be that A1 and A2 have full-connectivity but		this definition, it could be that A1 and A2 have full-connectivity
	only, for example, at at time T1 early enough in the interval [T,		but only, for example, at at time T1 early enough in the interval [T,
	T+dT] that A1 and A2 cannot reply to packets sent by the other. This		T+dT] that A1 and A2 cannot reply to packets sent by the other. This
	deficiency motivates the next metric.		deficiency motivates the next metric.
	7. Two-way Temporal Connectivity		7. Two-way Temporal Connectivity
	7.1. Metric Name:		7.1. Metric Name:
	Type-P1-P2-Interval-Temporal-Connectivity		Type-P1-P2-Interval-Temporal-Connectivity
	7.2. Metric Parameters:		7.2. Metric Parameters:
	skipping to change at page 7, line 5		skipping to change at page 7, line 5
	Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to		Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to
	address Dst during the interval [T, T+dT] if there exist times T1 and		address Dst during the interval [T, T+dT] if there exist times T1 and
	T2, and time intervals dT1 and dT2, such that:		T2, and time intervals dT1 and dT2, such that:
	+ T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT].		+ T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT].
	+ T1+dT1 <= T2.		+ T1+dT1 <= T2.
	+ At time T1, Src has Type-P1 instantanous connectivity to Dst.		+ At time T1, Src has Type-P1 instantanous connectivity to Dst.
	+ At time T2, Dst has Type-P2 instantanous connectivity to Src.		+ At time T2, Dst has Type-P2 instantanous connectivity to Src.
	+ dT1 is the time taken for a Type-P1 packet sent by Src at time T1		+ dT1 is the time taken for a Type-P1 packet sent by Src at time T1
	to arrive at Dst.		to arrive at Dst.
	ID Connectivity November 1997		ID IPPM Metrics for Measuring Connectivity August 1998
	+ dT2 is the time taken for a Type-P2 packet sent by Dst at time T2		+ dT2 is the time taken for a Type-P2 packet sent by Dst at time T2
	to arrive at Src.		to arrive at Src.
	7.5. Discussion:		7.5. Discussion:
	This metric defines "useful" connectivity -- Src can send a packet to		This metric defines "generally useful" connectivity -- Src can send a
	Dst that elicits a response. Because many applications utilize		packet to Dst that elicits a response. Because many applications
	different types of packets for forward and reverse traffic, it is		utilize different types of packets for forward and reverse traffic,
	possible (and likely) that the desired responses to a Type-P1 packet		it is possible (and likely) that the desired responses to a Type-P1
	will be of a different type Type-P2. Therefore, in this metric we		packet will be of a different type Type-P2. Therefore, in this
	allow for different types of packets in the forward and reverse		metric we allow for different types of packets in the forward and
	directions.		reverse directions.
	7.6. Methodologies:		7.6. Methodologies:
	Here we sketch a class of methodologies for estimating Type-P1-P2-		Here we sketch a class of methodologies for estimating Type-P1-P2-
	Interval-Temporal-Connectivity. It is a class rather than a single		Interval-Temporal-Connectivity. It is a class rather than a single
	methodology because the particulars will depend on the types P1 and		methodology because the particulars will depend on the types P1 and
	P2.		P2.
	7.6.1. Inputs:		7.6.1. Inputs:
	+ Types P1 and P2, addresses A1 and A2, interval [T, T+dT].		+ Types P1 and P2, addresses A1 and A2, interval [T, T+dT].
	skipping to change at page 8, line 5		skipping to change at page 8, line 5
	dT = 60 seconds.		dT = 60 seconds.
	W = 10 seconds.		W = 10 seconds.
	N = 20 packets.		N = 20 packets.
	7.6.3. Algorithm:		7.6.3. Algorithm:
	+ Compute N *sending-times* that are randomly, uniformly distributed		+ Compute N *sending-times* that are randomly, uniformly distributed
	over [T, T+dT-W].		over [T, T+dT-W].
	ID Connectivity November 1997		ID IPPM Metrics for Measuring Connectivity August 1998
	+ At each sending time, transmit from A1 a well-formed packet of		+ At each sending time, transmit from A1 a well-formed packet of
	type P1 to A2.		type P1 to A2.
	+ Inspect incoming network traffic to A1 to determine if a		+ Inspect incoming network traffic to A1 to determine if a
	successful reply is received. The particulars of doing so are		successful reply is received. The particulars of doing so are
	dependent on types P1 & P2, discussed below. If a successful		dependent on types P1 & P2, discussed below. If a successful
	reply is received, the value of the measurement is "true".		reply is received, the value of the measurement is "true".
	+ If no successful replies are received by time T+dT, the value of		+ If no successful replies are received by time T+dT, the value of
	the measurement is "false".		the measurement is "false".
	skipping to change at page 9, line 5		skipping to change at page 9, line 5
	probably should be addressed with another metric).		probably should be addressed with another metric).
	+ An ICMP port-unreachable from A2 to A1 indicates temporal		+ An ICMP port-unreachable from A2 to A1 indicates temporal
	connectivity between the addresses (and again a *lack* of service		connectivity between the addresses (and again a *lack* of service
	connectivity for TCP-port-N1-port-N2). {Comment: TCP		connectivity for TCP-port-N1-port-N2). {Comment: TCP
	implementations generally do not need to send ICMP port-		implementations generally do not need to send ICMP port-
	unreachable messages because a separate mechanism is available		unreachable messages because a separate mechanism is available
	(sending a RST). However, RFC 1122 states that a TCP receiving an		(sending a RST). However, RFC 1122 states that a TCP receiving an
	ICMP port-unreachable MUST treat it the same as the equivalent		ICMP port-unreachable MUST treat it the same as the equivalent
	transport-level mechanism (for TCP, a RST).}		transport-level mechanism (for TCP, a RST).}
	ID Connectivity November 1997		ID IPPM Metrics for Measuring Connectivity August 1998
	+ An ICMP host-unreachable or network-unreachable to A1 (not		+ An ICMP host-unreachable or network-unreachable to A1 (not
	necessarily from A2) with an enclosed IP header matching that sent		necessarily from A2) with an enclosed IP header matching that sent
	from A1 to A2 *suggests* a lack of temporal connectivity. If by		from A1 to A2 *suggests* a lack of temporal connectivity. If by
	time T+dT no evidence of temporal connectivity has been gathered,		time T+dT no evidence of temporal connectivity has been gathered,
	then the receipt of the ICMP can be used as additional information		then the receipt of the ICMP can be used as additional information
	to the measurement value of "false".		to the measurement value of "false".
	{Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.}		{Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.}
	8. Security Considerations		8. Security Considerations
	This memo raises no security issues.		As noted in RFC 2330, active measurement techniques, such as those
			defined in this document, can be abused for denial-of-service attacks
			disguised as legitimate measurement activity. Furthermore, testing
			for connectivity can be used to probe firewalls and other security
			mechnisms for weak spots.
	9. References		9. References
	F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June		F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June
	1995.		1995.
	R. Braden, "Requirements for Internet hosts - communication layers",		R. Braden, "Requirements for Internet hosts - communication layers",
	RFC 1122, October 1989.		RFC 1122, October 1989.
	V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, Paxson, "Framework		V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, Paxson, "Framework
	for IP Performance Metrics", Internet Draft <draft-ietf-ippm-		for IP Performance Metrics", RFC 2330, May 1998.
	framework-01.txt>, November 1996.
	J. Postel, "Internet Protocol", RFC 791, September 1981.		J. Postel, "Internet Protocol", RFC 791, September 1981.
	10. Authors' Addresses		10. Authors' Addresses
	Jamshid Mahdavi <mahdavi@psc.edu>		Jamshid Mahdavi <mahdavi@psc.edu>
	Pittsburgh Supercomputing Center		Pittsburgh Supercomputing Center
	4400 5th Avenue		4400 5th Avenue
	Pittsburgh, PA 15213		Pittsburgh, PA 15213
	USA		USA
	Vern Paxson <vern@ee.lbl.gov>		Vern Paxson <vern@ee.lbl.gov>
	MS 50B/2239		MS 50A-3111
	Lawrence Berkeley National Laboratory		Lawrence Berkeley National Laboratory
	University of California		University of California
	Berkeley, CA 94720		Berkeley, CA 94720
			ID IPPM Metrics for Measuring Connectivity August 1998
	USA		USA
	Phone: +1 510/486-7504		Phone: +1 510/486-7504
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/