draft-eddy-nemo-aero-reqs-01.txt		draft-eddy-nemo-aero-reqs-02.txt
	NEMO Working Group W. Eddy		MEXT Working Group W. Eddy
	Internet-Draft Verizon		Internet-Draft Verizon
	Intended status: Informational W. Ivancic		Intended status: Informational W. Ivancic
	Expires: January 7, 2008 NASA		Expires: February 22, 2008 NASA
	T. Davis		T. Davis
	Boeing		Boeing
	July 6, 2007		August 21, 2007
	NEMO Route Optimization Requirements for Operational Use in Aeronautics		NEMO Route Optimization Requirements for Operational Use in Aeronautics
	and Space Exploration Mobile Networks		and Space Exploration Mobile Networks
	draft-eddy-nemo-aero-reqs-01		draft-eddy-nemo-aero-reqs-02
	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 38		skipping to change at page 1, line 38
	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 January 7, 2008.		This Internet-Draft will expire on February 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes the requirements and desired properties of		This document describes the requirements and desired properties of
	NEMO Route Optimization techniques for use in global networked		NEMO Route Optimization techniques for use in global networked
	communications systems for aeronautics and space exploration.		communications systems for aeronautics and space exploration.
	THE PRESENT VERSION OF THIS DOCUMENT HAS NOT YET BEEN OFFICIALLY		This version has been review by members of the International Civil
	REVIEWED OR APPROVED BY ICAO OR ANY OTHER AERONAUTICAL OR SPACE		Aviation Orgnanization (ICAO) and other aeronautical communications
	COMMUNICATIONS STANDARDS BODY.		standards bodies.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. NEMO RO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5		2. NEMO RO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Aeronautical Communications Scenarios . . . . . . . . . . 5		2.1. Aeronautical Communications Scenarios . . . . . . . . . . 5
	2.2. Space Exploration Scenarios . . . . . . . . . . . . . . . 9		2.2. Space Exploration Scenarios . . . . . . . . . . . . . . . 9
	3. Required Characteristics . . . . . . . . . . . . . . . . . . . 11		3. Required Characteristics . . . . . . . . . . . . . . . . . . . 11
	3.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 12		3.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 11
	3.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 13		3.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 12
	3.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 13		3.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 13
	3.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 14		3.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 13
	3.5. Req5 - Integrity . . . . . . . . . . . . . . . . . . . . . 14		3.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 14
	3.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 15		3.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 15
	3.7. Req7 - Throughput . . . . . . . . . . . . . . . . . . . . 15		3.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 15
	3.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 16		3.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 16
	3.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 17		3.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 17
	4. Desirable Characteristics . . . . . . . . . . . . . . . . . . 17		4. Desirable Characteristics . . . . . . . . . . . . . . . . . . 17
	4.1. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 17		4.1. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 17
	4.2. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 18		4.2. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 18
	4.3. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 18		4.3. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 18
	4.4. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 18		4.4. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 18
	4.5. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 18		4.5. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 19
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 19		5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Informative References . . . . . . . . . . . . . . . . . . . . 20		8. Changes from draft-eddy-nemo-aero-reqs-01 . . . . . . . . . . 20
	Appendix A. Basics of IP-based Aeronautical Networking . . . . . 21		9. Informative References . . . . . . . . . . . . . . . . . . . . 21
	Appendix B. Basics of IP-based Space Networking . . . . . . . . . 22		Appendix A. Basics of IP-based Aeronautical Networking . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Appendix B. Basics of IP-based Space Networking . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
			Intellectual Property and Copyright Statements . . . . . . . . . . 25
	1. Introduction		1. Introduction
	As background the NEMO terminology and NEMO goals and requirements		As background the NEMO terminology and NEMO goals and requirements
	documents are suggested reading [1] [2]. The drafts produced as part		documents are suggested reading [1] [2]. The drafts produced as part
	of the Mobile Platform Internet (MPI) effort are also of relevence,		of the Mobile Platform Internet (MPI) effort are also of relevence,
	and some of the material in this document is borrowed from the MPI		and some of the material in this document is borrowed from the MPI
	drafts [3] [4].		drafts [3] [4].
	The base NEMO standard [5] allows Mobile IPv6 [6] to be used by		The base NEMO standard [5] allows Mobile IPv6 [6] to be used by
	skipping to change at page 3, line 50		skipping to change at page 3, line 50
	based on their functions. These multiple networks are required for		based on their functions. These multiple networks are required for
	regulatory reasons to have different treatments of their air-ground		regulatory reasons to have different treatments of their air-ground
	traffic, and often must use distinct air-ground links and service		traffic, and often must use distinct air-ground links and service
	providers.		providers.
	Many properties of the aeronautics and space environments amplify the		Many properties of the aeronautics and space environments amplify the
	known issues with NEMO bidirectional MRHA tunnels [7] even further.		known issues with NEMO bidirectional MRHA tunnels [7] even further.
	Longer routes leading to increased delay and additional		Longer routes leading to increased delay and additional
	infrastructure load - In aeronautical networks (e.g. using Plain		infrastructure load - In aeronautical networks (e.g. using Plain
	Old ACARS or ACARS over VDL mode 2 ) the queueing delays are often		Old Aircraft Communication Addressing and Reporting System (ACARS)
	long due to ARQ mechanisms and underprovisioned radio links.		or ACARS over VHF Data Link (VDL) mode 2 ) the queueing delays are
			often long due to ARQ mechanisms and underprovisioned radio links.
	Furthermore, for aeronautical communications systems that pass		Furthermore, for aeronautical communications systems that pass
	through geosynchronous satellites, and for space exploration, the		through geosynchronous satellites, and for space exploration, the
	propagation delays are also long. These delays combined with the		propagation delays are also long. These delays combined with the
	additional need to cross continents in order to transport packets		additional need to cross continents in order to transport packets
	between ground stations and CNs means that delays are already		between ground stations and CNs means that delays are already
	quite high in aeronautical and space networks without the addition		quite high in aeronautical and space networks without the addition
	of an MRHA tunnel. The increased delays caused by MRHA tunnels		of an MRHA tunnel. The increased delays caused by MRHA tunnels
	may be unacceptable in meeting Required Communication Performance		may be unacceptable in meeting Required Communication Performance
	[8].		[8].
	skipping to change at page 9, line 22		skipping to change at page 9, line 22
	This section describes some features of the network environments		This section describes some features of the network environments
	found in space exploration that are relevent to selecting an		found in space exploration that are relevent to selecting an
	appropriate NEMO RO mechanism. It should be noted that IPv4-based		appropriate NEMO RO mechanism. It should be noted that IPv4-based
	mobile routing has been demonstrated onboard the UK-DMC satellite and		mobile routing has been demonstrated onboard the UK-DMC satellite and
	that the documentation on this serves as a useful reference for		that the documentation on this serves as a useful reference for
	understanding some of the goals and configuration issues for certain		understanding some of the goals and configuration issues for certain
	types of space use of NEMO [10]. This section assumes space use of		types of space use of NEMO [10]. This section assumes space use of
	NEMO within the "near-Earth" range of space (i.e. not for		NEMO within the "near-Earth" range of space (i.e. not for
	communications between the Earth and Mars, or other "deep-space"		communications between the Earth and Mars, or other "deep-space"
	locations). No strong distinction is made here between civilian		locations). Note, that NEMO is currently being considered for use
	versus military use, or exploration mission versus Earth-observing or		out to Lunar distances. No strong distinction is made here between
	other mission types; our focus is on civilian exploration missions,		civilian versus military use, or exploration mission versus Earth-
	but we believe that many of the same basic concerns are relevent to		observing or other mission types; our focus is on civilian
	these other mission types.		exploration missions, but we believe that many of the same basic
			concerns are relevent to these other mission types.
	In space communications, a high degree of bandwidth asymmetry is		In space communications, a high degree of bandwidth asymmetry is
	often present, with the uplink from the ground to a craft typically		often present, with the uplink from the ground to a craft typically
	being multiple orders of magnitude slower than the downlink from the		being multiple orders of magnitude slower than the downlink from the
	craft to the ground. This means that the RO overhead may be		craft to the ground. This means that the RO overhead may be
	negligible on the downlink but significant for the uplink. An RO		negligible on the downlink but significant for the uplink. An RO
	scheme that minimizes the amount of signaling from CNs to an MN is		scheme that minimizes the amount of signaling from CNs to an MN is
	desirable, since these uplinks may be low-bandwidth to begin with		desirable, since these uplinks may be low-bandwidth to begin with
	(possibly only several kilobits per second). Since the uplink is		(possibly only several kilobits per second). Since the uplink is
	used for sending commands, it should not be blocked for long periods		used for sending commands, it should not be blocked for long periods
	skipping to change at page 11, line 24		skipping to change at page 11, line 24
	developed [4] [11]. The nine required characteristics listed in this		developed [4] [11]. The nine required characteristics listed in this
	document can be seen as directly descended from these ICAO criteria,		document can be seen as directly descended from these ICAO criteria,
	except here we have made them much more specific and focused for the		except here we have made them much more specific and focused for the
	NEMO technology. The original ICAO criteria were more general and		NEMO technology. The original ICAO criteria were more general and
	used for comparing the features of different mobility solutions (e.g.		used for comparing the features of different mobility solutions (e.g.
	mobility techniques based on routing protocols versus transport		mobility techniques based on routing protocols versus transport
	protocols versus Mobile IP, etc.). Within the text describing each		protocols versus Mobile IP, etc.). Within the text describing each
	requirement in this section, we provide the high-level ICAO criteria		requirement in this section, we provide the high-level ICAO criteria
	from which it evolved.		from which it evolved.
	The one-line summarized requirements that are discussed in this
	section are:
	Req1 - An RO scheme MUST have the ability to be bypassed by
	applications that desire to use bidirectional tunnels through an
	HA. (Separability)
	Req2 - RO schemes MUST permit an MR to be simultaneously connected
	to multiple access networks, having multiple prefixes and Care-Of
	Addresses in a MONAMI6 context. (Multihoming)
	Req3 - An RO solution MUST be capable of configuring itself (and
	reconfiguring after mobility events) without blocking unoptimized
	packet flow during its initiation and before or after transitions
	in the active access links. (Latency)
	Req4 - An RO solution MUST NOT imply a single point of failure,
	whether that be a single MR, a single HA, or other point within
	the ground network. (Availability)
	Req5 - An RO scheme MUST NOT cause packets to be dropped at any
	point in operation, when they would not normally have been dropped
	in a non-RO configuration. (Integrity)
	Req6 - An RO scheme MUST be simultaneously usable by ten thousand
	nodes without overloading the ground network or routing system.
	(Scalability)
	Req7 - An RO scheme MUST be capable of operating on traffic
	streams with individual rates up to 5 Mbps, and aggregates of 50
	Mbps, while accounting for less than 9.6 kbps of bandwidth for its
	own signaling overhead. (Throughput)
	Req8 - IPsec MUST be usable over the RO scheme, and the data used
	to make RO decisions MUST be authenticable, perhaps using some
	form of IPsec. (Security)
	Req9 - New applications, potentially using new transport protocols
	or IP options MUST be possible within an RO scheme.
	(Adaptability)
	These requirements for aeronautics are generally similar to or in		These requirements for aeronautics are generally similar to or in
	excess of the requirements for space exploration, so we do not add		excess of the requirements for space exploration, so we do not add
	any additional requirements specifically for space exploration. In		any additional requirements specifically for space exploration. In
	addition, the lack of a standards body regulating performance and		addition, the lack of a standards body regulating performance and
	safety requirements for space exploration means that the requirements		safety requirements for space exploration means that the requirements
	for aviation are much easier to agree upon and base within existing		for aviation are much easier to agree upon and base within existing
	requirements frameworks. After consideration, we believe that the		requirements frameworks. After consideration, we believe that the
	set of aviation-based requirements outlined here also fully suffices		set of aviation-based requirements outlined here also fully suffices
	for space exploration.		for space exploration.
	3.1. Req1 - Separability		3.1. Req1 - Separability
	For some traffic, there may be a concern with taking the path		An RO scheme MUST have the ability to be bypassed by traffic types
	selected by a RO mechanism, since this may be considered a less		that desire to use bidirectional tunnels through an HA.
	trustworthy or less reliable path for some reason than the MRHA
	tunnel that represents a more-known quantity, or for capacity		3.1.1. Rationale for Aeronautics - Separability
	properties or regulatory reasons. This is not to say that the RO-
	selected path really is less safe to use, just that it may be		For the aeronautics community there are basically three types of
			traffic (classes of service): "critical traffic" used for air traffic
			control and safety of flight, "signaling traffic" used for air
			operations management, and "user traffic" used by passenger services.
			For critical and signaling traffic, there may be a concern with
			taking the path selected by a RO mechanism, since this may be
			considered a less trustworthy or less reliable path for some reason
			than the MRHA tunnel that represents a more-known quantity, or for
			capacity properties or regulatory reasons. This is not to say that
			the RO-selected path really is less safe to use, just that it may be
	perceived as such due to a lack of prior probing or unknown		perceived as such due to a lack of prior probing or unknown
	information about its delay or capacity properties. Since the MRHA		information about its delay or capacity properties. Since the MRHA
	tunnel's path has known properties, it may be preferred over an		tunnel's path has known properties, it may be preferred over an
	unknown RO-selected path for certain restricted classes of data flows		unknown RO-selected path for certain restricted classes of data flows
	(e.g. ATS or spacecraft command and control).		(e.g. ATS or spacecraft command and control).
	For this reason, an RO scheme must have the ability to be bypassed by		For this reason, an RO scheme must have the ability to be bypassed by
	applications that desire to use bidirectional tunnels through an HA.		applications that desire to use bidirectional tunnels through an HA.
	This desire could be expressed through a policy database similar to		This desire could be expressed through a policy database similar to
	the Security Policy Database used by IPsec, for instance, but the		the Security Policy Database used by IPsec, for instance, but the
	skipping to change at page 13, line 8		skipping to change at page 12, line 24
	desire by applications is left as a detail for the specific RO		desire by applications is left as a detail for the specific RO
	specifications.		specifications.
	This requirement was derived from ICAO's TC-1 - "The approach should		This requirement was derived from ICAO's TC-1 - "The approach should
	provide a means to define data communications that can be carried		provide a means to define data communications that can be carried
	only over authorized paths for the traffic type and category		only over authorized paths for the traffic type and category
	specified by the user."		specified by the user."
	3.2. Req2 - Multihoming		3.2. Req2 - Multihoming
			Req2 - RO schemes MUST permit an MR to be simultaneously connected to
			multiple access networks, having multiple prefixes and Care-Of
			Addresses in a MONAMI6 context.
			3.2.1. Rationale for Aeronautics - Multihoming
	Multiple factors drive a requirement for multihoming capabilities.		Multiple factors drive a requirement for multihoming capabilities.
	For ATS safety-of-life critical traffic, the need for high		For ATS safety-of-life critical traffic, the need for high
	availability suggests a basic multihoming requirement. The		availability suggests a basic multihoming requirement. The
	regulatory and operational difficulty in deploying new systems and		regulatory and operational difficulty in deploying new systems and
	transitioning away from old ones also implies that a mix of access		transitioning away from old ones also implies that a mix of access
	technologies may be in use at any given time, and may require		technologies may be in use at any given time, and may require
	simultaneous use. Another factor is that the multiple domains of		simultaneous use. Another factor is that the multiple domains of
	applications onboard may actually be restricted in what data links		applications onboard may actually be restricted in what data links
	they are allowed to use based on regulations and policy, so at		they are allowed to use based on regulations and policy, so at
	certain times or locations, PIES data flows may have to use distinct		certain times or locations, PIES data flows may have to use distinct
	skipping to change at page 13, line 38		skipping to change at page 13, line 12
	It is not this requirement's intention that an RO scheme itself		It is not this requirement's intention that an RO scheme itself
	provide multihoming, but rather simply to exclude RO techniques whose		provide multihoming, but rather simply to exclude RO techniques whose
	use is not possible in multihomed scenarios.		use is not possible in multihomed scenarios.
	This requirement was derived from ICAO's TC-2 - "The approach should		This requirement was derived from ICAO's TC-2 - "The approach should
	enable an aircraft to both roam between and to be simultaneously		enable an aircraft to both roam between and to be simultaneously
	connected to multiple independent air-ground networks."		connected to multiple independent air-ground networks."
	3.3. Req3 - Latency		3.3. Req3 - Latency
			Req3 - An RO solution MUST be capable of configuring itself (and
			reconfiguring after mobility events) without blocking unoptimized
			packet flow during its initiation and before or after transitions in
			the active access links.
			3.3.1. Rationale for Aeronautics - Latency
	It is possible that an RO scheme may take longer to setup or involve		It is possible that an RO scheme may take longer to setup or involve
	more signaling than the basic NEMO MRHA tunnel maintenance that		more signaling than the basic NEMO MRHA tunnel maintenance that
	occurs during an update to the MR's active CoAs when the set of		occurs during an update to the MR's active CoAs when the set of
	usable access links changes. During this period of flux, it may be		usable access links changes. During this period of flux, it may be
	important for applications to be able to immediately get packets onto		important for applications to be able to immediately get packets onto
	the ground network, especially considering that connectivity may have		the ground network, especially considering that connectivity may have
	been blocked for some period of time while link-layer and NEMO		been blocked for some period of time while link-layer and NEMO
	proceedures for dealing with the transition occurred. Also, when an		proceedures for dealing with the transition occurred. Also, when an
	application starts for the first time, the RO scheme may not have		application starts for the first time, the RO scheme may not have
	previous knowledge related to the CN and may need to perform some		previous knowledge related to the CN and may need to perform some
	skipping to change at page 14, line 20		skipping to change at page 13, line 48
	sent, perhaps without the full benefit of RO, if the RO scheme		sent, perhaps without the full benefit of RO, if the RO scheme
	requires additional time to configure a more optimal path to the CN.		requires additional time to configure a more optimal path to the CN.
	This requirement was derived from ICAO's TC-3 - "The approach should		This requirement was derived from ICAO's TC-3 - "The approach should
	minimize latency during establishment of initial paths to an		minimize latency during establishment of initial paths to an
	aircraft, during handoff, and during transfer of individual data		aircraft, during handoff, and during transfer of individual data
	packets."		packets."
	3.4. Req4 - Availability		3.4. Req4 - Availability
			Req4 - An RO solution MUST NOT imply a single point of failure,
			whether that be a single MR, a single HA, or other point within the
			ground network.
			3.4.1. Rationale for Aeronautics - Availability
	A need for high availability of connectivity to ground networks		A need for high availability of connectivity to ground networks
	arises from the use of IP networking for carrying safety-of-life		arises from the use of IP networking for carrying safety-of-life
	critical traffic. For this reason, single points of failure need to		critical traffic. For this reason, single points of failure need to
	be avoided. If an RO solution assumes either a single MR onboard, a		be avoided. If an RO solution assumes either a single MR onboard, a
	single HA, or some similar vulnerable point, and is not usable when		single HA, or some similar vulnerable point, and is not usable when
	redundant elements are present and in use then it will not be		redundant elements are present and in use then it will not be
	acceptable. An RO solution also MUST NOT itself imply a single point		acceptable. An RO solution also MUST NOT itself imply a single point
	of failure.		of failure.
	This does not mention specific redundancy mechanisms for MRs, HAs, or		This does not mention specific redundancy mechanisms for MRs, HAs, or
	skipping to change at page 14, line 45		skipping to change at page 14, line 32
	this requirement. When an MR is completely disconnected from the		this requirement. When an MR is completely disconnected from the
	majority of the network it is intended to communicate, including its		majority of the network it is intended to communicate, including its
	HA, there is no requirement for it to be able to retain any		HA, there is no requirement for it to be able to retain any
	communications involving parties outside the mobile networks managed		communications involving parties outside the mobile networks managed
	by itself.		by itself.
	This requirement was derived from ICAO's TC-4 - "The approach should		This requirement was derived from ICAO's TC-4 - "The approach should
	have high availability which includes not having a single point of		have high availability which includes not having a single point of
	failure."		failure."
	3.5. Req5 - Integrity		3.5. Req5 - Packet Loss
			Req5 - An RO scheme MUST NOT cause packets to be dropped at any point
			in operation, when they would not normally have been dropped in a
			non-RO configuration. (Integrity)
			3.5.1. Rationale for Aeronautics - Packet Loss
	It is possible that some RO schemes could cause data packets to be		It is possible that some RO schemes could cause data packets to be
	lost during transitions in RO state or due to unforseen packet		lost during transitions in RO state or due to unforseen packet
	filters along the RO-selected path. This could be difficult for an		filters along the RO-selected path. This could be difficult for an
	application to detect and respond to in time. For this reason, an RO		application to detect and respond to in time. For this reason, an RO
	scheme MUST NOT cause packets to be dropped at any point in		scheme MUST NOT cause packets to be dropped at any point in
	operation, when they would not normally have been dropped in a non-RO		operation, when they would not normally have been dropped in a non-RO
	configuration. If duplicating a small number of packets sent over		configuration. If duplicating a small number of packets sent over
	both the MRHA tunnel and the optimized path is possible until the		both the MRHA tunnel and the optimized path is possible until the
	optimized path can be verified to function for a particular data		optimized path can be verified to function for a particular data
	skipping to change at page 15, line 20		skipping to change at page 15, line 13
	This requirement does not necessarily imply make-before-break in		This requirement does not necessarily imply make-before-break in
	transitioning between links. The intention is that during the		transitioning between links. The intention is that during the
	handoff period, the RO scheme itself should not produce losses that		handoff period, the RO scheme itself should not produce losses that
	would not have occurred if RO had been disabled.		would not have occurred if RO had been disabled.
	This requirement was derived from ICAO's TC-5 - "The approach should		This requirement was derived from ICAO's TC-5 - "The approach should
	not negatively impact end-to-end data integrity, for example, by		not negatively impact end-to-end data integrity, for example, by
	introducing packet loss during path establishment, handoff, or data		introducing packet loss during path establishment, handoff, or data
	transfer."		transfer."
			It is understood that this may be a requirement that is not easily
			implementable with regards to RO. Furthermore Req1, Separability,
			may be sufficient. In addition, the ability for a RO implementation
			to determine the appropriate path for particular systems is probably
			out of scope. Regardless, this requirment is currently being
			retained in order to ensure it gets addressed in some manner via
			either RO or elsewhere. This requirment is likely to be removed, but
			we do not wish to loose the thought at this time.
	3.6. Req6 - Scalability		3.6. Req6 - Scalability
			Req6 - An RO scheme MUST be simultaneously usable by ten thousand
			nodes without overloading the ground network or routing system.
			3.6.1. Rationale for Aeronautics - Scalability
	Several thousand aircraft may be in operation at some time, each with		Several thousand aircraft may be in operation at some time, each with
	perhaps several hundred MNNs onboard. The number of active		perhaps several hundred MNNs onboard. The number of active
	spacecraft using IP will be multiple orders of magnitude smaller than		spacecraft using IP will be multiple orders of magnitude smaller than
	this over at least the next decade, so the aeronautical needs are		this over at least the next decade, so the aeronautical needs are
	more stringent in terms of scalability to large numbers of MRs. It		more stringent in terms of scalability to large numbers of MRs. It
	would be a non-starter if the combined use of an RO technique by all		would be a non-starter if the combined use of an RO technique by all
	of the MRs in the network caused ground networks provisioned within		of the MRs in the network caused ground networks provisioned within
	the realm of typical long-haul private telecommunications networks		the realm of typical long-haul private telecommunications networks
	(like the FAA's Telecommunications Infrastructure (FTI) or NASA's		(like the FAA's Telecommunications Infrastructure (FTI) or NASA's
	NISN) to be overloaded or melt-down under the RO signaling load or		NISN) to be overloaded or melt-down under the RO signaling load or
	amount of rapid path changes for multiple data flows.		amount of rapid path changes for multiple data flows.
	Thus, an RO scheme MUST be simultaneously usable by ten thousand		Thus, an RO scheme MUST be simultaneously usable by ten thousand
	nodes without overloading the ground network or routing system.		nodes without overloading the ground network or routing system.
	This requirement was derived from ICAO's TC-6 - "The approach should		This requirement was derived from ICAO's TC-6 - "The approach should
	be scaleable to accomodate anticipated levels of aircraft equipage."		be scaleable to accomodate anticipated levels of aircraft equipage."
	3.7. Req7 - Throughput		3.7. Req7 - Efficient Signaling
			An RO scheme MUST be capable of efficient signaling
			3.7.1. Rationale for Aeronautics - Efficient Signaling
	The amount of bandwidth available for aeronautical and space		The amount of bandwidth available for aeronautical and space
	communications has historically been quite small in comparison to the		communications has historically been quite small in comparison to the
	desired bandwidth. This situation is expected to persist for at		desired bandwidth (e.g. in the case of VDL links the bandwidth is 8
	least several more years. Links tend to be provisioned based on		kbps of shared resources). This situation is expected to persist for
			at least several more years. Links tend to be provisioned based on
	estimates of application needs (which could well prove wrong if		estimates of application needs (which could well prove wrong if
	either demand or the applications in-use themselves do not follow		either demand or the applications in-use themselves do not follow
	expectations), and do not leave much room for additional networking		expectations), and do not leave much room for additional networking
	protocol overhead. Since every byte of available air-ground link		protocol overhead. Since every byte of available air-ground link
	capacity that is used by signaling for NEMO RO is likely to delay		capacity that is used by signaling for NEMO RO is likely to delay
	bytes of application data and reduce application throughput, it is		bytes of application data and reduce application throughput, it is
	important that the NEMO RO scheme's signaling overhead scales up much		important that the NEMO RO scheme's signaling overhead scales up much
	more slowly than the throughput of the flows RO is being performed		more slowly than the throughput of the flows RO is being performed
	on. This way as higher-rate datalinks are deployed along with more		on. This way as higher-rate datalinks are deployed along with more
	bandwidth-hungry applications, the NEMO RO scheme will be able to		bandwidth-hungry applications, the NEMO RO scheme will be able to
	safely be discounted in capacity planning.		safely be discounted in capacity planning.
	If the bandwidth needed for NEMO RO signaling is constant, or
	irrespective of the application data rate for flows using RO, then
	this requirement is satisfied. If the bandwidth needed grows with
	the application data rate, but with an asymptotically slower rate of
	growth, this is also acceptable (for instance, if the application
	data rate doubles, but the RO signaling overhead only increases by
	10%).
	The one-line summary of this requirement listed above uses specific
	values of up to 5 Mbps for an individual flow, and 50 Mbps aggregate
	through an MR, with a limit of 9.6 kbps used for RO signaling as a
	target. These numbers were chosen somewhat arbitrarily simply to
	provide a concrete and measurable requirement, and may be subject to
	revision. We do not specifically state signaling overhead goals for
	lower-bandwidth links because it is assumed that for aeronautical
	use, IPv6 use will be enabled by the deployment of new high-rate
	radio systems.
	This requirement was derived from ICAO's TC-7 - "The approach should		This requirement was derived from ICAO's TC-7 - "The approach should
	result in throughput which accommodates anticipated levels of		result in throughput which accommodates anticipated levels of
	aircraft equipage."		aircraft equipage."
	3.8. Req8 - Security		3.8. Req8 - Security
			Req8 - IPsec MUST be usable over the RO scheme, and the data used to
			make RO decisions MUST be authenticable, perhaps using some form of
			IPsec.
			3.8.1. Rationale for Aeronatics - Security
	Security based on IPsec is widely understood and modules qualified		Security based on IPsec is widely understood and modules qualified
	for use in aeronautical and space exploration environments are		for use in aeronautical and space exploration environments are
	currently available off-the-shelf due to the US Department of Defense		currently available off-the-shelf due to the US Department of Defense
	HAIPE work. Other security frameworks may not be as attractive due		HAIPE work. Other security frameworks may not be as attractive due
	to a lack of familiarity or available flight-qualified systems. If		to a lack of familiarity or available flight-qualified systems. If
	an RO solution precludes the use of IPsec by applications, this would		an RO solution precludes the use of IPsec by applications, this would
	make it undesirable or unusable. Likewise, since the IPsec standards		make it undesirable or unusable. Likewise, since the IPsec standards
	seem to be the only widely-agreed upon framework for implementing		seem to be the only widely-agreed upon framework for implementing
	packet authentication and other security services, the use of IPsec		packet authentication and other security services, the use of IPsec
	to authenticate or otherwise secure RO signaling and other data used		to authenticate or otherwise secure RO signaling and other data used
	skipping to change at page 17, line 8		skipping to change at page 17, line 10
	These issues motivate the requirement that IPsec MUST be usable by		These issues motivate the requirement that IPsec MUST be usable by
	applications utilizing the RO scheme, and the data used to make RO		applications utilizing the RO scheme, and the data used to make RO
	decisions MAY be authenticable using IPsec.		decisions MAY be authenticable using IPsec.
	This requirement was extrapolated from ICAO's TC-8 - "The approach		This requirement was extrapolated from ICAO's TC-8 - "The approach
	should be secure."		should be secure."
	3.9. Req9 - Adaptability		3.9. Req9 - Adaptability
			Req9 - New applications, potentially using new transport protocols or
			IP options MUST be possible within an RO scheme.
			3.9.1. Rationale for Aeronatics - Adaptability
	The concepts of operations are not fully developed for network-		The concepts of operations are not fully developed for network-
	centric command and control and other uses of IP-based networks in		centric command and control and other uses of IP-based networks in
	aeronautical and space environments. The exact application		aeronautical and space environments. The exact application
	protocols, data flow characteristics, and even transport protocols		protocols, data flow characteristics, and even transport protocols
	that will be used in either transitional and final operational		that will be used in either transitional and final operational
	concepts are not completely defined yet, and may even change with		concepts are not completely defined yet, and may even change with
	deployment experience. If the RO solution assumes that some amount		deployment experience. If the RO solution assumes that some amount
	of preconfiguration of flow properties (port number ranges, etc.) is		of preconfiguration of flow properties (port number ranges, etc.) is
	required, this could make the integration of new applications or		required, this could make the integration of new applications or
	protocols difficult. An RO scheme might assume this in order to		protocols difficult. An RO scheme might assume this in order to
	skipping to change at page 20, line 5		skipping to change at page 20, line 12
	Steve Bretmersky, Thierry Ernst, Tony Li, Jari Arkko, Phillip Watson,		Steve Bretmersky, Thierry Ernst, Tony Li, Jari Arkko, Phillip Watson,
	Roberto Baldessari, Carlos Jesus Bernardos Cano, and Eivan Cerasi		Roberto Baldessari, Carlos Jesus Bernardos Cano, and Eivan Cerasi
	were incorporated into this document.		were incorporated into this document.
	Wesley Eddy's work on this document was performed at NASA's Glenn		Wesley Eddy's work on this document was performed at NASA's Glenn
	Research Center, while in support of NASA's Advanced Communications		Research Center, while in support of NASA's Advanced Communications
	Navigations and Surveillance Architectures and System Technologies		Navigations and Surveillance Architectures and System Technologies
	(ACAST) project, and the NASA Space Communications Architecture		(ACAST) project, and the NASA Space Communications Architecture
	Working Group (SCAWG).		Working Group (SCAWG).
	8. Informative References		8. Changes from draft-eddy-nemo-aero-reqs-01
			Note, this section will be removed upon publication as an RFC.
			At the IETF69 nemo meeting, consensus was reached to have the
			aeronautics, car-to-car, electronics devices, and any other groups
			develop individual requirements documents. At a later date, these
			individual requirements documents are likely to be combined into one
			document. Thus, the draft-eddy-nemo-aero-req-01 document has been
			revised as follows:
			The document has been renamed as draft-eddy-nemo-aero-reqs-02.
			Once MEXT gets organized, this document will become an ietf-mext
			working document per IETF69 consensus. However, in order to get
			this document out for comment during the transision period, it has
			been release at this time as an individual submission.
			In Req1 - Separability the wording has been changed such that
			selection is base on traffic types rather than applications. It
			was noted during the IETF69 NEMO meeting that requiring a RO to
			determine separability by application is not practical but use of
			techniques such as traffic classification may be.
			Req5 - Integrity has been changed to Req5 - Packet Loss. Within
			the IETF integrity has a different meaning than packet loss.
			Within the aviation community, integrity, as used here, refers to
			path integrity or data flow integrity. Within the IETF, integrity
			implies good data rather than good path. Thus, in order to
			improve clarity within the IETF, the wording has been changed.
			Req7 - Throughput has been changed to Req7 - Efficient Signaling.
			Overall throughput is relative to the bandwidth of the available
			links and is relatively independent of the RO implementation.
			Rather, the real requirement is for RO to be deployable over low
			bandwidth systems (e.g. VHDL links of 8 kbps for today's
			aeronautical communication links). Thus, the wording has been
			change to reflect the actual requirement.
			Acronyms have been defined the first time they are used.
			The requirements section has been re-written to read more like a
			contract. Thus, we have requirements and rationale with the
			rationale being numbered paragraphs. The idea is that, if so
			desired at a later date, this should enable combining of the
			various requirement documents into a single requirements document.
			In addition, we hope that the changes will make this document
			easier for an implementer to utilize.
			9. Informative References
	[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	draft-ietf-nemo-terminology-06 (work in progress),		draft-ietf-nemo-terminology-06 (work in progress),
	November 2006.		November 2006.
	[2] Ernst, T., "Network Mobility Support Goals and Requirements",		[2] Ernst, T., "Network Mobility Support Goals and Requirements",
	draft-ietf-nemo-requirements-06 (work in progress),		draft-ietf-nemo-requirements-06 (work in progress),
	November 2006.		November 2006.
	[3] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks",		[3] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks",
	skipping to change at page 22, line 33		skipping to change at page 24, line 4
	Authors' Addresses		Authors' Addresses
	Wesley M. Eddy		Wesley M. Eddy
	Verizon Federal Network Systems		Verizon Federal Network Systems
	NASA Glenn Research Center		NASA Glenn Research Center
	21000 Brookpark Road, MS 54-5		21000 Brookpark Road, MS 54-5
	Cleveland, OH 44135		Cleveland, OH 44135
	USA		USA
	Email: weddy@grc.nasa.gov		Email: weddy@grc.nasa.gov
	Will Ivancic		Will Ivancic
	NASA Glenn Research Center		NASA Glenn Research Center
	21000 Brookpark Road, MS 54-5		21000 Brookpark Road, MS 54-5
	Cleveland, OH 44135		Cleveland, OH 44135
	USA		USA
	Phone: +1-216-433-3494		Phone: +1-216-433-3494
	Email: William.D.Ivancic@grc.nasa.gov		Email: William.D.Ivancic@grc.nasa.gov
	Terry Davis		Terry Davis
	Boeing Commercial Airplanes		Boeing Commercial Airplanes
			P.O.Box 3707 MC 07-25
			Seattle, WA 98124-2207
			USA
	Phone: 206-280-3715		Phone: 206-280-3715
	Email: Terry.L.Davis@boeing.com		Email: Terry.L.Davis@boeing.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
End of changes. 30 change blocks.
	96 lines changed or deleted		158 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/