Internet DRAFT - draft-davis-aviationreq
draft-davis-aviationreq
TBD T. Davis
Internet-Draft Boeing
Intended status: Informational September 18, 2006
Expires: March 22, 2007
Aviation Global Internet Operations Requirements
draft-davis-aviationreq-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 22, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The commercial aviation industry is among the first to develop and
deploy mobile networks capable of utilizing Internet communications
services around the world. In development of this capability the
industry developed their own standards for the use of IP based
communications within the aircraft and on the direct connected off-
board links. This document defines aviationOs desired Internet
usages and capabilities and the gaps the industry sees in basic
Internet technology required for the full utilization of the Internet
Davis Expires March 22, 2007 [Page 1]
Internet-Draft Aviation Requirements September 2006
by mobile platforms.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Aviation Internet Concept of Operations . . . . . . . . . . . 3
3. Aircraft Control Domain . . . . . . . . . . . . . . . . . . . 4
4. Airline Information Services Domain . . . . . . . . . . . . . 5
5. Passenger Domain . . . . . . . . . . . . . . . . . . . . . . . 6
6. Aircraft to Ground Links . . . . . . . . . . . . . . . . . . . 6
7. Transitional Services . . . . . . . . . . . . . . . . . . . . 6
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Draft ICAO Technical Considerations . . . . . . . . . 8
Appendix B. Draft ICAO Implementation Considerations . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Davis Expires March 22, 2007 [Page 2]
Internet-Draft Aviation Requirements September 2006
1. Introduction
The commercial aviation industry is among the first to develop and
deploy mobile networks capable of utilizing Internet communications
services around the world. In development of this capability the
industry developed their own standards for the use of IP based
communications within the aircraft and on the direct connected off-
board links. These internal and link network specifications are
covered by Arinc standards 664, 763, 811, 821, and 822.
As this technology has begun to deploy, the industry has found
several gaps in its ability to fully utilize Internet technology and
services. This document defines aviationOs desired Internet usages
and capabilities and the gaps the industry sees in basic Internet
technology required for the full utilization of the Internet by
mobile platforms. The aviation industryOs usage of Internet services
is also confined and regulated by service and support requirements
defined by various national and international agencies that govern
aircraft operation and air transport services.
2. Aviation Internet Concept of Operations
Aircraft systems, including communications systems, are divided into
three distinct domains for which statutory, regulatory, and
airworthiness certification requirements are distinctly different.
The domains are:
Aircraft Control (AC) Domain
The AC domain covers aircraft operational control and air traffic
communications relating to safety and regularity of flight.
The communications equipment in the AC domain operates under the
regulations of the International Civil Aviation Organization
(ICAO), the Air Navigation Service Providers (ANSPs), and the
airworthiness requirements of the certifying aeronautical agency/
government. This domain is generally under operational control of
the ANSPs.
Airline Information Services (AIS) Domain
The AIS domain covers airline administrative and non-safety
airline operational communications.
The equipment in the AIS domain operates under rules and
regulations of the airworthiness certifying aeronautical and
communications agency/government, but because the use is not
Davis Expires March 22, 2007 [Page 3]
Internet-Draft Aviation Requirements September 2006
safety related, the rules are similar to those governing
international banking and generally under the governance and
jurisdiction of the carrierOs flag country.
Passenger Information and Entertainment Services (PIES) Domain
The PIES domain covers entertainment and communications provided
directly to the passengers, including interfaces for passenger
communication equipment.
The equipment in the PIES domain generally operates under the
rules and regulations of the local government and/or the flag
country, covering personal communications. This includes voice/
telephone/cell service rules, regulations, and law enforcement
access.
The maintenance of these discreet logical networks is critical to the
ability to operate the aircraft in all jurisdictions around the
world.
3. Aircraft Control Domain
At the present time, current scenarioOs envision that the
communication of the Aircraft Control Domain would be operated as a
closed domain with access permitted to only the aircraft and the
national entities providing air navigation services. This isolation
is necessary to ensure the safety and reliability of air navigation
services. This design also serves to minimize the routing tables
associated with this network ensuring that aircraft mobility services
can be assured of a rapid routing convergence as the aircraft add and
drop links
In addition the communication of the Aircraft Control Domain will be
operated as a high security network with all traffic both encrypted
and authenticated. It is anticipated that this domain will require
many individual sets of digital keys to allow the aircraft to operate
in the various national and regional air traffic control spaces
around the globe with separate authentication and encryption within
each control space. Network layer authentication will also be
required in order for aircraft to join this network.
For network services, this network is expected to have a unified
domain naming service structure in order to facilitate the handoff of
aircraft in flight between the air traffic control spaces. It is
anticipated to require its own top level domain. Secure DNS services
and dynamic DNS are required. Aircraft operating in this domain will
have statically assigned IP prefixes for routing. On board systems
Davis Expires March 22, 2007 [Page 4]
Internet-Draft Aviation Requirements September 2006
may utilize DHCP and/or IPv6 auto-configuration services like
neighbor discovery. Network time services via NTP will be provided
as a stratum 1 service from the aircraft GPS and therefore this
network will not be required to have an additional NTP source.
The Control domain also has regulatory requirements covering the
approval of different links and providers to handle traffic/data
related to the safety of flight and pilot to controller
communications. These requirements also specify maximum levels of
latency and minimum levels of QoS performance. In general this
network takes link priority over traffic from the Airline Information
Services and Passenger domains.
All services for the Control domain including routing, mobility,
security, and naming services will ultimately be handled in
accordance with guidance provided by ICAO and air navigation service
providers.
4. Airline Information Services Domain
The AIS domain will likely be operated as a closed subnet within the
airlines' infrastructure, however some routing can be expected to
both exit and enter this subnet. Again the minimal size of the
network should assure rapid network convergence. Dual-homed servers
are likely to be deployed on the edge of this network to provide data
transfer between the airlines' operational aircraft network and their
corporate IT systems.
This network is also assumed to be operated as a high security
network with network access authentication and encryption required.
The authentication, encryption and digital keying will likely be
defined by the airline with guidance from industry groups and their
flag government.
The network services required for this network domain will be similar
to those required for the Control domain although the data volumes
are likely to be much higher. This domain also has some similar
regulatory requirements on latency and QOS performance but are in
general much less strict than the AC domain. In general this link
will be a secondary queue with priority over traffic from the
passenger domain; however AC domain traffic will have priority over
AIS domain traffic.
This domain is subject to both international and national
regulations.
Davis Expires March 22, 2007 [Page 5]
Internet-Draft Aviation Requirements September 2006
5. Passenger Domain
The operation of the Passenger services and In-flight Entertainment
(IFE) domain is expected to be defined by the service providers and
the in-flight entertainment system vendors. It is assumed to be
subject to all local, national, and international regulations
regarding voice and data communications. It may also be subject to
local and national law enforcement requirements for intercept.
6. Aircraft to Ground Links
Some data communication and digital voice links between the aircraft
and ground stations or service providers are expected to be shared
between the three domains under the guidance provided above.
In addition it is expected that the normal state of operation for the
aircraft shall be to have multiple data or voice links simultaneously
active. These links are expected to be aircraft initiated and will
come and go primarily based on location (over land or water, which
country) and what service providers are available as the aircraft
traverses the globe. No single uniform service provider
infrastructure exists for any type of link globally. Thus on a
typical flight around the globe the aircraft may utilize three to
seven link types provided by five to ten independent service
providers.
In order to implement this type of link service infrastructure link
access authentication and accounting must occur. In addition, all
Air-to-Ground communications are expected to be link encrypted.
This mix of link types provided by multiple service providers appears
to make the implementation of home agents as envisioned by NEMO
(NEtwork MObility) extremely operationally difficult. Further the
regulatory and links latency requirements will also make the use of
home agents difficult.
7. Transitional Services
The aircraft services must also include transition architectures such
that existing IP-v4 based aircraft may operate seamlessly on either
existing IP-v4 or new IP-v6 air to ground links. Likewise, new IP-v6
aircraft must operate seamlessly on either IP-v4 or IP-v6 air to
ground links. The aviation industry expects that IP-v4 based
aircraft will continue to operate in the system for 20 or more years.
Likewise individual aviation networks (air and ground) will
transition from IP-v4 to IP-v6 slowly over the next 10 to 15 years;
Davis Expires March 22, 2007 [Page 6]
Internet-Draft Aviation Requirements September 2006
therefore, aircraft must be able to operate seamlessly with either
IP-v4 or IP-v6 link services including handling mixed links
simultaneously.
8. Summary
This document is intended to provide the basis by which the IETF can
provide an informational RFC to the aviation industry detailing the
recommended suite of network services and technologies. This
informational RFC is expected to contain primarily existing defined
services and technologies but may include some RFCOs specifically
developed to support the aviation industries global mobility and
complex regulatory requirements. There is an expectation that a
specific new informational RFC for OInternet DockingO services will
also be developed to cover the specifics of a mobile network
connecting and disconnecting from non-similar networks around the
world to be referenced in primary document.
This RFC will be periodically updated to incorporate new regulatory
information and guidelines from appropriate governmental or industry
organizations around the globe.
9. Security Considerations
10. Protocol Considerations
This document does not impose any protocol considerations.
11. IANA Considerations
This document requests no action from IANA.
12. Acknowledgements
The following people have contributed to this document: TBD
13. References
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
Davis Expires March 22, 2007 [Page 7]
Internet-Draft Aviation Requirements September 2006
Appendix A. Draft ICAO Technical Considerations
o TC-1. The approach should provide a means to define data
communications that can be carried only over authorized paths for
the traffic type and category specified by the user.
o TC-2. The approach should enable an aircraft to both roam between
and to be simultaneously connected to multiple independent air-
ground networks.
o TC-3. The approach should minimize latency during establishment
of initial paths to an aircraft, during handoff, and during
transfer of individual data packets.
o TC-4. The approach should have high availability which includes
not having a single point of failure.
o TC-5. The approach should not negatively impact end-to-end data
integrity, for example, by introducing packet loss during path
establishment, handoff or data transfer.
o TC-6. The approach should be scaleable to accommodate anticipated
levels of aircraft equipage.
o TC-7. The approach should result in throughput which accommodates
anticipated levels of aircraft equipage.
o TC-8. The approach should be secure.
o TC-9. The approach should be scalable to accommodate anticipated
transition to new IP-based communication protocols.
Appendix B. Draft ICAO Implementation Considerations
o IC.1 The approach should permit the addition of air/ground service
providers.
o IC.2 The approach should not rely on a particular air/ground
service provider or administration for operation.
o IC.3 The approach should not be unique to aviation but rather
should be based on open industry standards.
o IC.4 The approach should have mature and commercially available
implementations.
o IC.5 The approach should allow the industry to implement a closed
network.
o IC.6 The approach should allow an authentication to be required
for systems to join the closed network.
Davis Expires March 22, 2007 [Page 8]
Internet-Draft Aviation Requirements September 2006
Author's Address
Terry Davis
Boeing
TBD
TBD
U.S.A.
Email: terry.l.davis@boeing.com
Davis Expires March 22, 2007 [Page 9]
Internet-Draft Aviation Requirements September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Davis Expires March 22, 2007 [Page 10]
