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]