draft-ietf-shim6-failure-detection-08.txt		faildet.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track I. van Beijnum		Intended status: Standards Track I. van Beijnum
	Expires: December 24, 2007 June 22, 2007		Expires: January 10, 2008 July 9, 2007
	Failure Detection and Locator Pair Exploration Protocol for IPv6		Failure Detection and Locator Pair Exploration Protocol for IPv6
	Multihoming		Multihoming
	draft-ietf-shim6-failure-detection-08		draft-ietf-shim6-failure-detection-09
	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.
	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 1, line 35		skipping to change at page 1, line 35
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	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 December 24, 2007.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document specifies how the level 3 multihoming shim protocol		This document specifies how the level 3 multihoming shim protocol
	(SHIM6) detects failures between two communicating hosts. It also		(SHIM6) detects failures between two communicating hosts. It also
	specifies an exploration protocol for switching to another pair of		specifies an exploration protocol for switching to another pair of
	skipping to change at page 6, line 35		skipping to change at page 6, line 35
	o The address is not tentative in the sense of RFC 2462 [RFC2462].		o The address is not tentative in the sense of RFC 2462 [RFC2462].
	In other words, the address assignment is complete so that		In other words, the address assignment is complete so that
	communications can be started.		communications can be started.
	Note that this explicitly allows an address to be optimistic in		Note that this explicitly allows an address to be optimistic in
	the sense of Optimistic DAD [RFC4429] even though implementations		the sense of Optimistic DAD [RFC4429] even though implementations
	may prefer using other addresses as long as there is an		may prefer using other addresses as long as there is an
	alternative.		alternative.
	o The address is a global unicast, unique local address [RFC4193],		o The address is a global unicast or unique local address [RFC4193].
	or an unambiguous IPv6 link-local address. That is, it is not an		That is, it is not an IPv6 site-local or link-local address.
	IPv6 site-local address.
	Where IPv6 link-local addresses are used, their use needs to be		With link-local addresses, the nodes would be unable to determine
	unambiguous as follows. At most one link-local address may be		on which link the given address is usable.
	used per node within the same connection between two peers.
	o The address and interface is acceptable for use according to a		o The address and interface is acceptable for use according to a
	local policy.		local policy.
	Available addresses are discovered and monitored through mechanisms		Available addresses are discovered and monitored through mechanisms
	outside the scope of SHIM6. SHIM6 implementations MUST be able to		outside the scope of SHIM6. SHIM6 implementations MUST be able to
	employ information provided by IPv6 Neighbor Discovery [RFC2461],		employ information provided by IPv6 Neighbor Discovery [RFC2461],
	Address Autoconfiguration [RFC2462], and DHCP [RFC3315] (when DHCP is		Address Autoconfiguration [RFC2462], and DHCP [RFC3315] (when DHCP is
	implemented). This information includes the availability of a new		implemented). This information includes the availability of a new
	address and status changes of existing addresses (such as when an		address and status changes of existing addresses (such as when an
	skipping to change at page 15, line 34		skipping to change at page 15, line 34
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header, Hdr Ext Len, 0, 0, Checksum		Next Header, Hdr Ext Len, 0, 0, Checksum
	These are as specified in Section 5.3 of the SHIM6 protocol		These are as specified in Section 5.3 of the SHIM6 protocol
	description [I-D.ietf-shim6-proto].		description [I-D.ietf-shim6-proto].
	Type		Type
	This field identifies the Probe message and MUST be set to 66		This field identifies the Keepalive message and MUST be set to 66
	(Keepalive).		(Keepalive).
	Reserved1		Reserved1
	This is a 7-bit field reserved for future use. It is set to zero		This is a 7-bit field reserved for future use. It is set to zero
	on transmit, and MUST be ignored on receipt.		on transmit, and MUST be ignored on receipt.
	R		R
	This is a 1-bit field reserved for future use. It is set to zero		This is a 1-bit field reserved for future use. It is set to zero
	skipping to change at page 23, line 50		skipping to change at page 23, line 50
	again treated similarly here.)		again treated similarly here.)
	Operational Exploring InboundOk		Operational Exploring InboundOk
	-----------------------------------------------------------		-----------------------------------------------------------
	START Send; - START Send		START Send; - START Send
	STOP Keepalive		STOP Keepalive
	6.3. Keepalive timeout		6.3. Keepalive timeout
	Upon a timeout on the Keepalive timer, the node sends one last		Upon a timeout on the Keepalive timer, the node sends one last
	Keepalive message and cancels the timer governing the sending of the		Keepalive message. This can only happen in the Operational state.
	next Keepalive message. This can only happen in the Operational
	state.
	The Keepalive message is constructed as described in Section 5.1. It		The Keepalive message is constructed as described in Section 5.1. It
	is sent using the current address pair.		is sent using the current address pair.
	Operational Exploring InboundOk		Operational Exploring InboundOk
	-----------------------------------------------------------		-----------------------------------------------------------
	SEND Keepalive; - -		SEND Keepalive - -
	STOP Keepalive
	6.4. Send timeout		6.4. Send timeout
	Upon a timeout on the Send timer, the node enters the Exploring		Upon a timeout on the Send timer, the node enters the Exploring state
	state, sends a Probe message, and stops the Keepalive timer if it was		and sends a Probe message. The Probe message is constructed as
	running. The Probe message is constructed as explained in		explained in Section 6.1, except that the Sta field is set to 1
	Section 6.1, except that the Sta field is set to 1 (Exploring).		(Exploring).
	Operational Exploring InboundOk		Operational Exploring InboundOk
	-----------------------------------------------------------		-----------------------------------------------------------
	SEND Probe Exploring; - SEND Probe Exploring;		SEND Probe Exploring; - SEND Probe Exploring;
	STOP Keepalive; GOTO Exploring		GOTO Exploring GOTO Exploring
	GOTO Exploring
	6.5. Retransmission		6.5. Retransmission
	While in the Exploring state the node keeps retransmitting its Probe		While in the Exploring state the node keeps retransmitting its Probe
	messages to different (or same) addresses as defined in Section 4.3.		messages to different (or same) addresses as defined in Section 4.3.
	A similar process is employed in the InboundOk state, except that		A similar process is employed in the InboundOk state, except that
	upon such retransmission the Send timer is started if it was not		upon such retransmission the Send timer is started if it was not
	running already.		running already.
	The Probe messages are constructed as explained in Section 6.1,		The Probe messages are constructed as explained in Section 6.1,
	skipping to change at page 25, line 31		skipping to change at page 25, line 29
	SEND Probe InboundOk; SEND Probe InboundOk; SEND Probe		SEND Probe InboundOk; SEND Probe InboundOk; SEND Probe
	STOP Keepalive; START Send; InboundOk;		STOP Keepalive; START Send; InboundOk;
	RESTART Send; GOTO InboundOk RESTART Send		RESTART Send; GOTO InboundOk RESTART Send
	GOTO InboundOk		GOTO InboundOk
	6.8. Reception of the Probe message State=InboundOk		6.8. Reception of the Probe message State=InboundOk
	Upon the reception of a Probe message with State set to InboundOk,		Upon the reception of a Probe message with State set to InboundOk,
	the node sends a Probe message, restarts the Send timer, stops the		the node sends a Probe message, restarts the Send timer, stops the
	Keepalive timer if it was running, and transitions to the Operational		Keepalive timer if it was running, and transitions to the Operational
	state.		state. New current address pair is chosen for the connection, based
			on the reports of received probes in the message that we just
			received. If no received probes have been reported, the current
			address pair is unchanged.
	The Probe message is constructed as explained in Section 6.1, except		The Probe message is constructed as explained in Section 6.1, except
	that the Sta field is set to 0 (Operational).		that the Sta field is set to 0 (Operational).
	Operational Exploring InboundOk		Operational Exploring InboundOk
	-------------------------------------------------------------		-------------------------------------------------------------
	SEND Probe Operational; SEND Probe Operational; SEND Probe		SEND Probe Operational; SEND Probe Operational; SEND Probe
	RESTART Send; RESTART Send; Operational;		RESTART Send; RESTART Send; Operational;
	STOP Keepalive GOTO Operational RESTART Send;		STOP Keepalive GOTO Operational RESTART Send;
	GOTO Operational		GOTO Operational
	skipping to change at page 37, line 6		skipping to change at page 37, line 6
	| | the problem and		| | the problem and
	| (B1,A1) Probe id=p, | sends a com-		| (B1,A1) Probe id=p, | sends a com-
	| state=exploring | plaint that		| state=exploring | plaint that
	|<--------------------------------------------| it is not rec-		|<--------------------------------------------| it is not rec-
	| | eiving anything		| | eiving anything
	A responds | State: Exploring		A responds | State: Exploring
	State: InboundOk |		State: InboundOk |
	| |		| |
	| (A1, B1) Probe id=q, |		| (A1, B1) Probe id=q, |
	| state=inboundok, |		| state=inboundok, |
	| received payload, |		| received probe p |
	| received probe q |
	|----------------------------------------/ | But A's response		|----------------------------------------/ | But A's response
	| | is lost		| | is lost
	| (B2,A2) Probe id=r, |		| (B2,A2) Probe id=r, |
	| state=exploring | Next try different		| state=exploring | Next try different
	|<--------------------------------------------| locator pair		|<--------------------------------------------| locator pair
	| |		| |
	| (A2, B2) Probe id=s, |		| (A2, B2) Probe id=s, |
	| state=inboundok, |		| state=inboundok, |
	| received payload, |
	| received probes p, r | This one gets		| received probes p, r | This one gets
	|-------------------------------------------->| through		|-------------------------------------------->| through
	| | State: Operational		| | State: Operational
	| |		| |
	| | B now knows		| | B now knows
	| | that A has no		| | that A has no
	| (B2,A2) Probe id=t, | problem to receive		| (B2,A2) Probe id=t, | problem to receive
	| state=operational, | its packets, and		| state=operational, | its packets, and
	| received probe s | that A's probe		| received probe s | that A's probe
	|<--------------------------------------------| gets to B. It		|<--------------------------------------------| gets to B. It
	skipping to change at page 39, line 9		skipping to change at page 39, line 9
	contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer		contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer
	Dawkins, and James Kempf, and HIP WG contributors such as Pekka		Dawkins, and James Kempf, and HIP WG contributors such as Pekka
	Nikander. This draft is also in debt to work done in the context of		Nikander. This draft is also in debt to work done in the context of
	SCTP [RFC2960] and HIP multihoming and mobility extension		SCTP [RFC2960] and HIP multihoming and mobility extension
	[I-D.ietf-hip-mm].		[I-D.ietf-hip-mm].
	Appendix C. Acknowledgements		Appendix C. Acknowledgements
	The authors would also like to thank Christian Huitema, Pekka Savola,		The authors would also like to thank Christian Huitema, Pekka Savola,
	John Loughney, Sam Xia, Hannes Tschofenig, Sebastian Barre, Thomas		John Loughney, Sam Xia, Hannes Tschofenig, Sebastian Barre, Thomas
	Henderson, and Deguang Le for interesting discussions in this problem		Henderson, Matthijs Mekking, and Deguang Le for interesting
	space, and for review of this specification.		discussions in this problem space, and for review of this
			specification.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: jari.arkko@ericsson.com		Email: jari.arkko@ericsson.com
End of changes. 14 change blocks.
	27 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/