ACP/WG N Meeting 06 WGN06 – WP18

ACP/WG N/SGN1 WP707

AERONAUTICAL Communication Panel (ACP)

Working Group N - Internetworking

Sub Group N1 – Internet Communications Services

Malmö, Sweden, 27-31 March 2006

Standards and Maturity Guidance

on Mobility Techniques

Wesley M. Eddy

Verizon Federal Network Systems

(supporting NASA Glenn Research Center)

Introduction

Working paper (WP) 507, discussed by ICAO Working Group N, Subgroup N1 (SWGN1) in November of 2005, lists a number of candidate technologies for supporting the mobility of aircraft in a networked communications system [1]. To aid in the decision process amongst these candidate solutions, WP 605 lists and describes a set of evaluation criteria [2]. In this paper, we provide some guidance on two of the metrics proposed in WP 605.

Metric Definitions

The two criteria from WP 605 which we address here are:

·  IC3 – Open Industry Standard: The approach should not be unique to aviation, but rather should be based on open industry standards. This does not mean that the approach has to operate over the public Internet.

·  IC4 – Mature and Commercially Available: The approach should have mature and commercially available implementations. The motivation for this characteristic is to take advantage of commercial-off-the-shelf products that have passed the experimental stage.

The definition of IC3 leaves some room for interpretation. A mobility approach may be an existing published standard, an active work in progress that is expected to become a standard, a de-facto standard (not formally accepted, but well-known), or simply a concept or experimental technique that has not yet been standardized. Even among published standards, there are significant differences between standards bodies, and within a single standards body, there may be various levels of standardization. For the purposes of evaluating network mobility protocols, we choose to only consider a technique to be a standard, if it is specified in the Internet Engineering Task Force (IETF) Request for Comments (RFC) document series, since this is by far the dominant group of protocol specifications in the range of networking layers under consideration by SWGN1.

The IETF standards process begins with Internet-Drafts, similar to ICAO Working Papers. An Internet-Draft progresses through a community review and development process, and if successful, becomes an RFC. Some of the mobility techniques under consideration are currently only Internet-Drafts, which may not necessarily become published RFCs. Among published RFCs, there are four levels of maturity of relevance here:

·  Experimental – A technique that is not yet deemed to be safe for widespread use on the Internet, but is encouraged for use in limited deployment to help understand its behavior and possibly enable its advance onto the standards track. An Experimental RFC is technically not a standard in the IETF's view.

·  Proposed Standard (PS) – A protocol that is deemed safe for global use. This is the lowest level of the standards track, usually used for the initial RFC publication of a protocol specification.

·  Draft Standard (DS) – After a PS has existed for some time and multiple distinct and interoperable implementations exist, then (possibly with some small revisions), a protocol may reach the DS stage.

·  Standard – Sometimes referred to as a “full standard”, this is the highest level of the standards track and is used to represent a relatively small number of very mature and widely tested protocols. None of the mobility techniques under consideration have reached this level.

With regards to IC4, our evaluation is slightly less certain, as it is limited to personal knowledge of commercial offerings and their level of usage, support, and robustness. This metric is more subjective than IC3, but is also valuable since there exist many published standards which have either atrophied and been obsoleted, or have never attracted widespread support in reality. Since the status of a standard's publication and, even more so, its level of commercial support may change over the course of SWGN1's work, it is difficult to determine the level of impact that the current status of the candidate solutions should have.

We do not provide any input to this decision in this WP, but merely supply current data and technical opinions.

Evaluation

Table 1 lists current information on the ten mobility approaches described in WP 507 and WP 605. In addition to IC3 and IC4 evaluations, we have also provided the main RFC document numbers which describe the protocols. In most cases, there are several ancillary RFCs that go into greater depth on certain aspects of the protocol, or interactions with other protocols.

The Mobile IPv6 (MIP6) technology is the basis for solutions N1, N1A, N2, and N2A. As well as porting the IPv4 mobility support to IPv6, MIP6 also includes a number of feature enhancements. The MIP6 technology is actively supported and developed by industry, and support for MIP6 is a requirement of Phase 2 of the IPv6-Ready product certification initiative. It can be assumed that MIP6 will be well-supported by both standards bodies and a wide selection of commercial products for some time.

/ IC3 – Open Industry Standard / IC4 – Mature and Commercially Available / Main RFC Numbers /
N1 - MIP6 / PS / Yes / 3775
N1A – MIP6 & MONAMI6 / In progress to PS / Not yet / Currently, only Internet-Drafts
N2 - NEMO / PS / Unknown / 3963
N2A – NEMO & MONAMI6 / In progress to PS / Not yet / Currently, only Internet-Drafts
R1 – BGP-4 / DS / Yes / 4271 – 4278
R2 – IDRP extension / no / No / none
T - SCTP / PS, in progress to DS / Yes / 2960, 3309
A1- XMPP / PS / Yes / 3920 - 3923
A2 - SIMPLE / In progress to PS / Unknown / Protocol incomplete
A3 – ATN Application Mobility / no / No / none

Table 1 – Evaluation of IC3 and IC4 Metrics for Candidate Mobility Technologies

The NEMO technology (N2 and N2A) is an adaptation of MIP6 for use by routers rather than end-hosts, which improves the scalability of the signaling, given mobility patterns that involve entire networks rather than singular hosts. Although it currently lacks some desirable technical properties, NEMO is already a PS-level standard and advanced features are under active development and improvement in the IETF. The level of commercial support for NEMO is currently unknown to us. We are aware of at least one major router manufacturer who has experimental NEMO code, and several other laboratory users of NEMO.

The MONAMI6 extensions to MIP6 and NEMO (N1A and N2A) have only recently begun to be worked on, and are not yet solidified into standards. Their focus is on support of multiple interfaces, and the end solutions could be useful in providing ATN-style policy mechanisms, which are lacking in the basic MIP6 and NEMO protocols.

BGP-4 (R1) is an extremely well-supported standard, as the Internet's basic operation relies upon it daily. However, BGP-4 is not specifically designed to deal with active mobility, but rather general routing changes and disturbances. It may be sufficient for mobility in an aeronautical network, although a certain amount of tweaking is likely to be required. ATN's IDRP (R2), on the other hand, is an existing solution that is specifically designed for mobility, but is also not an IETF standard, and is not commercially supported at all outside of the niche of vendors catering to aeronautical networking.

Like BGP-4, SCTP (T) is also a standard that was not designed for mobility. Many instances of experimentation have demonstrated that SCTP is capable of supporting mobility, and even has some desirable features not found in network-layer solutions, but this type of use is not directly supported by the standards documents or available vendor implementations.

XMPP (A1) is a relatively new instant messaging format that is supported by a large number of implementations. However, these code bases are largely either open-source projects, or owned by small start-up companies, rather than the larger, more-diverse and stable vendors that IC4 infers. SIMPLE (A2) is an addition to the large SIP protocol to allow it to be used for instant messaging. The SIMPLE work is still under development, and is currently less well-supported than XMPP. Neither of these protocols are directly designed to provide the type of smooth mobility that is under consideration here, although they could be used to provide an ACARS-like service. Application layer mobility (A3) is a viable technique, but appears poor in this analysis due to the fact that it is not defined strictly in an IETF RFC, and not interoperably supported by vendors outside of the aviation community.

Conclusions

This analysis indicates that if current IC3 and IC4 properties are to be considered major factors, without considering any other criteria such as the technical merits of the candidates, then:

·  N1A & N2A are likely to be ruled out because they are works in progress. However, these techniques are likely to mature quickly and provide some of the greatest advantages for the aeronautics community. The MONAMI6 working group's charter goal is to complete all of their documents by December of 2006, although realistically this may take a year longer.

·  R2 and A3 are likely to be ruled out because of lack of wide commercial support.

·  A2 is likely to be ruled out due to immaturity of the standard.

·  N1 can be considered further.

·  N2 should be considered further, if commercial support is available.

·  R1 and T should be considered further, if configuration tweaking and/or slight extension and modification of protocol behaviors is acceptable.

·  A1 should be considered further, if the level of commercial support is sufficient.

Due to the rapidly shifting trends in networking technology, these conclusions are rather time-sensitive and may be appropriate to re-evaluate after some period of time. Particularly, N1A, N2A, and A2 are likely to advance to usable, published standards, the commercial support for N2 and A1 may change, and active research in T might alter the standards to make mobility a stated goal of the protocol, although we see this as unlikely.

Given their importance to other large communities (for example, cellular telephony), we expect the Mobile IP-based solutions (N1, N1A, N2, and N2A) to continue to be actively developed within the IETF, and to be well-supported by industry for at least several years. We expect a growing number of commercial products that implement these protocols to appear within the next year or two, as a result of the increasing availability of consumer platforms with multiple radio link technologies, and the continuous deployment of access points by network providers.

The IETF is likely to resist standardizing BGP-4 extensions (approach R1) for the sake of supporting mobility, since the IETF already has the Mobile IP standards, and numerous experimental mobile ad-hoc routing protocols. Work on yet-another mobile routing protocol is unlikely to gain traction, especially given the impact to BGP, which is considered one of only a few very important “core” protocols.

It is also not likely that SCTP mobility extensions (approach T) will be approved within the next several years, if at all. The primary focus of the SCTP creators is on multihoming for redundancy and failover. Efforts at utilizing the multihoming features for either striping transfers across multiple simultaneous links and for mobility have been proposed and politely rejected a number of times.

The large number of instant messaging protocols, of which XMPP (A1) and SIMPLE (A2) are only two of many, and the competitive landscape of service providers (AOL, Microsoft, Yahoo, Google, etc), make it very difficult to predict anything about the future status of standards body and commercial support for any particular instant messaging protocol. In the last decade, many instant messaging protocols have been obsoleted (e.g. ICQ). Protocols in this category may fail to meet IC3 and IC4 criteria due only to consumer market issues and without any regard to technical merits.

References

[1] “Candidate Approaches for an ATN IPS Mobility Solution”, ICAO ACP Sub-Working Group N1, Working Paper 507, November 2005.

[2] “Preliminary Analysis of Candidate ATN IPS Mobility Solutions”, ICAO ACP Sub-Working Group N1, Working Paper 605, February 2006.

Supplementary Links to Relevant IETF Working Groups:

Mobility for IPv6 (MIP6)

http://www.ietf.org/html.charters/mip6-charter.html

Network Mobility (NEMO)

http://www.ietf.org/html.charters/nemo-charter.html

Mobile Nodes and Multiple Interfaces in IPv6 (MONAMI6)

http://www.ietf.org/html.charters/monami6-charter.html

Inter-Domain Routing (BGP)

http://www.ietf.org/html.charters/idr-charter.html

Transport Area (SCTP)

http://www.ietf.org/html.charters/tsvwg-charter.html

XMPP/Jabber (no longer chartered within IETF)

http://www.xmpp.org/

http://www.jabber.org/

SIP for Instant Messaging and Presence Leveraging Extensions

http://www.ietf.org/html.charters/simple-charter.html