International Civil Aviation Organization
ACP-WGI
18/WP-01
07/06/05/15
WORKING PAPER
COMMUNICATIONS PANEL (CP)
Eighteenth meeting of WG-I
Montreal, Canada 24 – 25 June 2015
Agenda Item 7:
Xxx
IPS Mobility and Multilink Considerations
(Presented by Aloke Roy)
SUMMARY
This paper reviews mobility and multi-link in the context of the current
ATN/IPS Manual. Several issues limiting the usefulness of the current
standard are identified and potential areas for future development are
described. An appendix with network topology diagrams and message
sequence charts for the basic scenarios is also included.
ACTION
Consider the issues raised and the suggestions made in this paper when
updating the ATN/IPS manual.
1.
INTRODUCTION
1.1
Doc 9896, Manual on the Aeronautical Telecommunication Network (ATN), introduces
an IP based networking paradigm to support ATN applications. The document, based on Internet
standards that were available at the time of publication in 2010, establishes a basic networking strategy
and identifies the core Internet standards to be used for the ATN/IPS. Although Doc 9896 it covers basic
addressing and internetworking it does not adequately cover the specific areas of mobility management
for aircraft or the use of multiple data links to the aircraft.
1.2
Mobility and multiple links are mentioned in Doc 9896 but some of the reference
standards are obsolete (e.g. RFC 3775) or are left as “guidance” in Part III of the document. The guidance
material, especially regarding multi-link, isn’t really guidance at all but is just a list of possible
enhancements with no recommendation on which ones should be included in the ATN/IPS (e.g. Part III
1.6 – 1.7).
(19 pages)
Document1
-2ACP-WGWI18/WPxx
1.3
While mobility and multi-link networking are often addressed in commercial networks,
the particular requirements for aeronautical use do not appear to be adequately covered by commonly
adopted Internet standards.1 For these reasons, ATN specific mobility and multi-link solutions require
further study and development.
1.4
Fundamentally, mobility and multi-links (also called “multi-homing in the Internet
jargon) are manifestations of the same technical problem: how to maintain and optimize end-to-end
communication when there is more than one path to the aircraft? But the two problems of 1) how to deal
with multiple paths that change over time (mobility) and 2) how to deal with multiple paths that are
available at the same time (multi-link) are traditionally addressed separately. This paper will follow that
tradition and consider the two cases independently. When the solution for one helps with the other, that
will be noted as well.
2.
2.1
DISCUSSION
Background
2.1.1
For this paper, Honeywell focused primarily on the environment of the US and the
problems that the US FAA would face in implementing mobility and multi-link. From an air traffic
service application standpoint, this environment is expected to evolve as shown in Figure 1. The primary
difference between the US evolution and, for example, the European evolution is that the US is likely to
go directly from the existing FANS environment to the ATN B2 application message set and ATN/IPS
internetworking and not deploy the B1 messages or ATN/OSI networking.
Remote/Oceanic
Domestic
ATN Support
Intermediate Term
ATN End State
Application/
Message Set
FANS 1/A+
FANS 1/A
FANS 1/A
ATN B2
ATN B2
Apps & Messages
Internetwork
ACARS
ACARS
ACARS
ATN IPS
ATN IPS
VDLM2
VDLM2 or
SATCOM
VDLM2 or
SATCOM
Multi-Link
VDL, SATCOM, AeroMACS
Data Link
SATCOM
(classic aero
Time
Note: European Trajectory is Different: Includes B1 Messages and ATN/OSI
Internetworking as Intermediate Steps
Figure 1 US ATS Evolution
1The term “Internet” here refers specifically to the internet standards and protocols published by the IETF
(https://www.ietf.org/) rather than the generic term “internet” which would also encompass OSI and other
internetworking systems.
-3ACP-WGW01/WP-01
2.1.2
Although the starting environment considered is specific to the US the issues identified
and discussed are related to the end point environment so they are applicable globally. Transition issues
that depend on the intermediate environment (e.g. FANS vs. ATN/OSI) are not addressed.
2.1.3
Section 1 in the appendix shows in more detail the current FAA environment and the
assumed future environment.
Applications
end-to-end application association
Applications
Transport
end-to-end transport connection
Transport
Application association
is based on transport
connection
Transport connection is
based on Internet
address
Internet address is
relative to Mobile
Service Provider
address
Internet
Link Layer
Internet
Link
Layer
local sub-net connection
Internet
Link
Layer
Link
Layer
Link
Layer
ATN Network
Connection(s)
Internet
Link Layer
local subnet connection
Figure 2 Basic ATN/IPS Architecture
2.1.4
Figure 2, adapted from Doc 9896, shows the ATN/IPS architecture at the highest level.
Doc 9896 specifies the standards and protocols to implement this architecture; however the real
environment is expected to have several features that are not adequately described by this static reference
architecture. Some of the features related to mobility and multi-link that are not addressed by this high
level architecture include:




Hierarchical (scalable) addressing for host systems,
Dynamic changes to the routing structure (including mobility and changes due to network
evolution or failure),
Efficiency (route optimization, protocol optimization-e.g. LREF, Fast Byte, etc.),
Routing stability.
2.1.5
Although the listed issues were covered in some detail in the ATN/OSI, the ATN/OSI
documents are sometimes considered too prescriptive and the networking protocols selected for ATN/OSI
are not as widely deployed as the Internet IP protocol suite.
2.1.6
For example, the ATN/OSI solution to the scalable addressing problem and the routing
stability problems consists of having each aircraft be a separate routing domain and aggregating the routes
in ATN Backbones and ATN Islands. In other words, the aircraft had to operate a router and follow the
ATN addressing scheme and the ground routing domains had to conform to the ATN specified topology.
In contrast, in the ATN/IPS, the aircraft is defined as a Host endpoint and the IPv6 address is defined
relative to a local service provider, so the ATN/OSI type solutions are not applicable. Sub-network
convergence was also specified in the ATN/OSI, but the ATN/IPS leaves most of that unspecified,
primarily because it is expected that a wider range of sub-network technologies will be adopted in the
ATN/IPS and it would be too cumbersome to require, for example, that all sub-networks be based on a
particular protocol such as X.25.
-4ACP-WGWI18/WPxx
2.1.7
The flexibility allowed in the ATN/IPS may make it easier to field “ATN/IPS Compliant”
solutions more quickly by using commercial solutions as soon as they are available. It also makes it less
likely to lock in on a set of protocols that becomes obsolete and difficult to support. However the
technical problems that were addressed in the ATN/OSI still need to be solved.
2.1.8
ATN/IPS.
The rest of this paper addresses the main issues of mobility and multi-link support in the
2.2
Mobility
2.2.1
Mobile IP version 6 (MIPv6) was chosen (with limitations) as the mobility solution in
Doc 9896. MIPv6 is based on host mobility; that is an end point node “hosting” an application can change
its sub-network connection to the Internet while the hosted application remains reachable.
2.2.2
An important consideration in MIPv6, and IPv6 in general, is how addresses are assigned.
Figure 1 shows the addressing scheme defined in Doc 9896. The aircraft address is assigned relative to
the mobility service provider providing the link to the aircraft. This approach works well for basic
mobility, but as discussed later does not scale for multiple links.
Figure 3 ATN Address Structure
2.2.3
Section 2.1 in the appendix shows how an aircraft can connect to a mobility service
provider and receive the MSP relative address.
2.2.4
Once the aircraft has connected to the ATN/IPS Internet and been assigned an address,
basic mobility is straightforward. A single entity, the Home Agent (HA) for the aircraft keeps track of the
current point of attachment and MSP relative address for the aircraft and forwards traffic to and from the
aircraft as it attaches to different points on the internet. Section 2.2 in the appendix shows how this basic
mobility works.
2.2.5
The first issue in Doc 9896 with mobility is that the version selected, based on RFC 3775,
is obsolete and has been replaced by RFC 6275. Since RFC 3775 was not widely deployed and has
several known limitations, Honeywell recommends updating Doc 9896 to use RFC 6275.
2.2.6
Second, because of known issues with RFC 3775, Doc 9896 does not endorse the use of
route optimization. It should be noted however that MIPv6 without route optimization is only efficient
when the home agent is relative “close” in network terms to the correspondent note. Given the global
nature of airline and other aircraft operations, this assumption is not likely to always be true. The newer
specification, RFC 6275, is considered more secure2 and robust than the previous version and the ATN
manual recommendation against its use should be reconsidered in light of the new specification.
2 In basic mobility, the HA binding update is secured using IPsec, however since the CN and MN may not have any
previous association, a return routability procedure was developed to provide a basic level of security without using
IPsec. Note how the return routability messages traverse both routes and hence are more difficult (but not
impossible) to intercept and/or spoof.
-5ACP-WGW01/WP-01
2.2.7
Section 2.2.3 in the appendix shows the message sequence chart for route optimization
and the result of eliminating the mobile tunnel on ATN routing.
2.3
Multi-link
2.3.1
The basic ATN/IPS architecture shown in Figure 2 only supports one connection between
the application layer and the rest of the ATN. Real aircraft will likely have multiple connections. This is
not just an issue with the diagram; one of the biggest drawbacks of the MIPv6 approach is that
communication is only available over one subnet at a time, even if the aircraft has multiple connections.
2.3.2
Section 3.1.1 in the appendix shows the topology of the network when an aircraft has
multiple links. Section 3.1.2 shows the message sequence that creates this topology.
2.3.3
As indicated in Figure 2 and Figure 3, the association of an application with an IP address
(via the transport connection) limits the use of multiple links because the state on application is intimately
combined with the state of the network connection. Even though it is relatively straightforward to make
multiple connections to the aircraft, per the existing standards only one link is allowed to be used by an
application at a time. The implications of these limitations are explored in section 3.1.3 in the appendix.
2.3.4
A partial list of the technical issues that need to be addressed but that are not currently
handled by the ATN standards is given below:








In general, while multi-homing for mobile nodes has been defined in some standards, there
doesn’t seem to be a consensus in the best way to support it at this time.
In particular, aircraft management of multiple links is not defined in any standard.
Load balancing, e.g. when to use which link/address depends on link characteristics not apparent
from addresses (This was implemented using security tags in ATN/OSI but has not yet been
proven in large scale deployment).
Different delay/congestion statistics on different links have a dramatic affect on transport timers
but there is no clean way to account for this in current standards.
Multicast reception for mobile nodes is not well defined.
Different MTU on different routes can create tricky failure modes when links are changed.
MIPv6 (reportedly) doesn’t work well with firewalls3.
MIPv6 as currently specified still has security vulnerabilities.
2.3.5
The ATN is not the only user group facing these challenges, however our industry is
somewhat unique in that the mobility is extreme (global in fact) and continuity and integrity requirements
are based on life safety. Each of the issues listed will need to be addressed with aviation specific
requirements in mind.
2.3.6
Although the desired general solution, where the multiple links can be used
simultaneously to seamlessly support all applications is not yet available, it is possible to use the current
standards to provide a very limited type of multi-link capability. This can be accomplished by using each
link for a different application (e.g. ADS-C on SATCOM and Tower CPDLC on AeroMACS). It may
also be possible, perhaps with some minor changes to the context management application, to support
independent instances of the same application on separate links (e.g. Tower CPDLC on SATCOM and En
Route CPDLC on SATCOM). Section 3.1.3 in the appendix shows one way this limited multi-link
capability could be used.
3This statement appears in several descriptions of MIPv6, but Honeywell has not identified authoritative references
to substantiate it.
-6ACP-WGWI18/WPxx
2.3.7
Multi-link is a difficult technical problem, however, multi-link should be the norm for
future aircraft: it does not make business sense for the aircraft to carry multiple radios and have multiple
simultaneous connections but only use one link at a time due to technical limitations.
2.4
Possible future directions for multi-link and mobility
2.4.1
As described above, no general solution for multi-link aircraft network appears to be
ready for standardization. There are pointers in Doc 9896 to some of the industry work that may
eventually provide this support, but those references are slightly out of date. The following sections
briefly review some of the current options that should be considered for further development.
2.4.2
Since a fundamental problem with the ATN/IPS architecture is the linkage between
application state and network connection, one possible direction for future research is to explore the
options for separating the session and the link:
1. Redefine the meaning of an ATN Application Session
 Aviation industry could, if desired, develop their own concepts and protocols to
maintain an application session over multiple links
 Advantage would be that such a custom solution could be optimized for aviation
use on currently available sub-networks
 Disadvantages are the time it would take to develop the standards and the cost to
implement them just for use in one industry
2. Make the aircraft a router
 This is the approach taken in ATN/OSI
 IP layer will route packets on whichever link is best at the time
 Standardized for IP as “NEMO” (RFC 3963 with several updates/extensions) but
not widely available yet, and as described by Doc 9896, is “still being
investigated” within the IETF
 This is also the approach taken by “AERO” (RFC 6706 with several more recent
drafts). This is an active development specific to the aviation industry that
addresses many of the issues raised in this paper but is currently only available in
experimental form.
3. Multipath TCP
 IETF experimental standard, RFC 6824
 Should be the most compatible with existing TCP if it does get developed into a
standard
4. Stream Control Transport Protocol (SCTP)
 IETF proposed standard, RFC 4960
 Designed for “telephone quality connections”
 Mobility is similar to Multipath TCP but has more flow control options
 Would require extensive profiling for ATN use
5. Session Initiation Protocol (SIP)
 IETF proposed standard, RFC 3261
 Similar to HTTP and SMTP, but optimized for voice, multi-media and instant
messages (with support from new transport protocols)
 Works on both TCP and UDP and other transport mechanisms
 Would require extensive profiling for ATN use
2.4.3
There is also a list of options in the current version of Doc 9896 that enhance the
handover from one link to another. These options do not provide simultaneous multi-link capability but
-7ACP-WGW01/WP-01
might prove useful for improving the performance of individual link handovers. A short list with the
current RFC numbers is given below:
1. Hierarchal Mobile IPv6 (HMIPv6)
 IETF proposed standard, RFC 5380
 Local/Regional solution, would not handle global ATN requirements
 May be useful, for example, to speed handovers from one VDL or AeroMACS
sub-network to another or when changing satellites in SATCOM
2. Mobile IPv6 Fast Handovers
 IETF proposed standard, RFC 5568
 Speeds up handover by detecting movement between links more quickly and
using tunnels to partially overlap (i.e. “make-before-break”) some of the
transactions shown in MSC1b and 1c
3. Proxy mobile IPv6
 IETF proposed standard, RFC 5213 (updated by RFC 6543)
 Handles mobility in the network (with a proxy) rather than at the mobile node
 Could simplify avionics, but doesn’t address multiple link technology
2.5
Conclusions
2.5.1
The first and primary conclusion from this study is that while mobility is addressed in the
ATN manual, the current standards only allow the applications to take very limited advantage of multiple
link technology. The only real multi-link option that the current standards could support is the use of
different links for different applications (e.g. ADS-C, Tower and En Route comm. could each use
different links). If this limited multi-link capability is desirable, the stakeholders should work with the
airlines, service providers and equipment vendors to make sure the ATN applications can support it. If
equipment vendors and ANSPs cooperate, it should be possible to accomplish this by publishing service
profiles to clarify ICAO documents without actually changing the international standards.
2.5.2
Another important conclusion is that near term ATN/IPS deployment should be made
with the understanding that mobile and multi-link technology is evolving rapidly. As much as practical
the applications and services should be designed to be independent of the underlying network. The
primary focus for future work should be on developing the protocols and standards to support this
independence. The secondary focus can be on optimizing performance of currently specified ATN
2.5.3
The final conclusion, based on a partial review of ongoing network research and
development, is that commercial-off-the-shelf solutions for mobility and multi-homing are not ready to be
standardized for ATN use. It is recommended that ICAO and other aeronautical standardization
organizations should continue to develop alternate approaches and undertake efforts to address the gaps
identified in this paper. The solutions should be coordinated with IETF and the larger Internet community
so that the ATN can be based on stable, widely deployed RFCs.
3.
ACTION BY THE MEETING
3.1
The ACP Working Group I is invited to consider the material in this paper when
preparing the next update to the ATN/IPS manual. In particular, the working group should:


Update the mobility specification in Doc 9896 to the current RFC 6275,
Remove the restrictions on MIPv6 Route Optimization and explore additional techniques to
improve the robustness, routing table updates and routing efficiency
-8ACP-WGWI18/WPxx




Develop and publish profiles for use of the internet standards specified in the IPS manual (or as
alternate, encourage non-ICAO groups such as RTCA or EUROCAE to standardize some of the
options listed in the IPS manual,
Consider different IPv6 addressing structure and address discovery mechanisms to permit
simultaneous multilink operations over multiple IP air/ground networks offered by separate
MSPs,
Develop requirements for mobility and multi-link, and
Consider the list of alternatives described in this paper to develop standards to address the
deficiencies in the existing IPS Manual.
-9ACP-WGW01/WP-01
Appendix
1.
ENVIRONMENT
Figure 4 shows the current FAA high level architecture. In this architecture, much of the routing and
multi-link support is provided by the communications service provides (CSP) and is based on industry
standards for ACARS networking.
FANS Apps
AFN
CPDLC
ADS-C
AC1
Comm
Mgt
Legacy FAA Data Networks (FTI)
Static Links
to/from Comm
Service Providers
AC2
SATCOM
CSP
SAT
Link
Dynamic Links
to/from Aircraft
VHF
Link
Comm
Mgt
AC3
Comm
Mgt
CSP-2
HF
Link
e.g .
Oceanic/
Remote
e.g .
Domestic,
but also
using
SATCOM
e.g .
typical
Domestic
VHF
Link
CSP-1
HF
Link
Figure 4 Current High Level Architecture
Figure 5 shows how the high level architecture is expected to change as the ATN/IPS is adopted. There is
very little change in the physical architecture, with the main difference being in the support for ATN
applications (including dual stack for legacy apps) and the use of IP routing and connections to the
service providers.
- 10 ACP-WGWI18/WPxx
Dual Stack Supported Apps
CM/
AFN
CPDLC
ATN/IPS
adaptation
ADS-C
ACARS
adaptation
AC1
Comm
Mgt
e.g .
Oceanic/
Remote
Converged FAA Data Networks
Static Links
to/from Comm
Service Providers
AC2
SATCOM
CSP
Comm
Mgt
SAT
Link
Dynamic Links
to/from Aircraft
VHF
Link
AC3
Comm
Mgt
CSP-2
HF
Link
e.g .
Domestic,
but also
using
SATCOM
e.g .
typical
Domestic
VHF
Link
CSP-1
HF
Link
Figure 5 Future High Level Architecture
2.
2.1
MOBILITY
Nominal Case, Aircraft at “home”
The nominal case is shown in Figure 6. In this case, the aircraft has established a connection via a VDL
mobility service provider (MSP). The aircraft, as a mobile node, will be assigned an address relative to
this VDL MSP.
VDL Mobility
Service Provider
HA
e.g. ATN
B2 Apps
CN
VDL
subnet
equip
FAA Autonomous
System
Aircraft (as Mobile
Node, home is
same as VDL MSP)
MN
(e.g. ATN B2 Apps)
VDL
subnet
equip
HA
AeroMACS
subnet
equip
ATN/IPS Core
AeroMACS Mobility
Service Provider
Logical Route
Physical Route
Figure 6 ATN/IPS Entities (Aircraft "at home")
AeroMACS
subnet
equip
AC
Comm
Mgmt
- 11 ACP-WGW01/WP-01
The message sequence chart for the nominal case is shown in Figure 7. This diagram does not provide
any new information not already in the standards, but it shows how the aircraft gets its home address and
introduces the MSC tool used to analyze the mobility and multi-link cases later.
Figure 7 MSC0: Aircraft at home
2.2
Case 1: Single mobile address, multiple foreign sub-networks
2.2.1
Case 1 Topology
Figure 8 shows the topology for Case 1. This is the same as the architecture shown in the previous
section, this time showing the abstract internetworking and link layer connectivity. This paper focuses on
network layer handovers, but the figure also shows where link layer handovers are made. These link layer
handovers are handled entirely within each sub-network and are not visible at the IP layer. Note that
VDLm2 currently is implemented with both Layer 2 and Layer 3 handovers. Current plans for SATCOM
as discussed in the IRIS Precursor and SwiftBroadband for Safety Services work indicate that SATCOM
spot beam handovers will be conducted at the link layer and satellite handovers will take place at the
network layer.
The next two sections show the MSCs for this topology, first without route optimization and then with
route optimization.
- 12 ACP-WGWI18/WPxx
Home Network
Must support Mobile IPv6
Home Agent (HA)
Correspondent Node,
e.g. FAA Application Host or Proxy
Foreign Sub-network 2
(e.g. SATCOM Saf ety Services)
CN
ATN IPS Routed Internet
Correspondent networks
have no special mobility
requirements
Link Access
Points
Layer 3 Handovers
handled by MIPv6
Foreign Sub-network 1
(e.g. VDL Mode 2)
L2 Handovers
transparent to L3 and
above
MN
Mobile Node,
e.g. Aircraf t
Must support
Mobile IPv6
Figure 8 Case 1 Topology
2.2.2
Case 1 Without Route Optimization
Figure 9 and Figure 10 show the MSCs for basic mobility without route optimization. This is the ATN
Manual default mobility mechanism. Note that security for the HA Binding Update is provided by IPsec.
The key exchange protocol is not shown explicitly in this MSC.
In Figure 9, ATC communications are established over the first mobile sub-network, and in Figure 10
communications are maintained when the aircraft switches to a second mobile sub-network.
Packets “in flight” through the ATN internet can be still be forwarded by foreign subnet 1 as long as the
link connection is maintained, but per the standards the HA will only route new packets through the
current tunnel hence this mechanism does not support a general multi-link capability.
- 13 ACP-WGW01/WP-01
Figure 9 MSC 1a: ATC Comm established over first mobile sub-network
- 14 ACP-WGWI18/WPxx
Figure 10 MSC 1b: Maintaining ATC Comm over second mobile sub-network
Figure 11 shows the “tunnel” created with basic MIPv6.
Doc 9896 discourages the use of route optimization, so the tunnel will be used for all communications.
There is an assumption in Doc 9896 that the HA and CN are “close”, however this doesn’t seem to make
sense for e.g. foreign airlines operating in the US, the tunnel could actually be very long. The MIPv6
solution to this problem is shown in the next section on route optimization.
- 15 ACP-WGW01/WP-01
VDL Mobility
Service Provider
HA
e.g. ATN
B2 Apps
CN
VDL
subnet
equip
FAA Autonomous
System
Aircraft (as Mobile
Node, home is
same as VDL MSP)
MN
e.g. ATN B2 Apps
VDL
subnet
equip
HA
AeroMACS
subnet
equip
AC
Comm
Mgmt
AeroMACS
subnet
equip
AeroMACS Mobility
Service Provider
ATN/IPS Core
Tunnel Route
Figure 11 Mobility without Route Optimization
2.2.3
Case 1 With Route Optimization
Figure 12 shows the MSC for the additional updates needed to perform route optimization. This MSC is a
continuation from the one shown in the previous section.
Recall that the HA binding update for basic mobility was secured using IPsec, however since the CN and
MN may not have any previous association, the return routability procedure shown in this MSC was
developed to provide a basic level of security without using IPsec. Note how the return routability
messages traverse both routes and hence are more difficult (but not impossible) to intercept and/or spoof.
- 16 ACP-WGWI18/WPxx
Figure 12 MSC 1c: Mobility with route optimization
Figure 13 shows how the tunnel in Figure 11 has been replaced with a direct route between the CN and
MN. When the tunnel route is significantly longer than the direct route, this can be an important
optimization. Also, once the optimized route is in place, network outages affecting the HA will not
prevent communication between the CN and MN.
- 17 ACP-WGW01/WP-01
VDL Mobility
Service Provider
HA
e.g. ATN
B2 Apps
CN
Aircraft (as Mobile
Node, home is
same as VDL MSP)
VDL
subnet
equip
FAA Autonomous
System
MN
e.g. ATN B2 Apps
Return Routability test
uses both routes
Other traffic only uses
optimized route
VDL
subnet
equip
AeroMACS
subnet
equip
HA
AC
Comm
Mgmt
AeroMACS
subnet
equip
AeroMACS Mobility
Service Provider
ATN/IPS Core
Normal Mobile route
(part standard IP, part tunneled)
Optimized route
Figure 13 Mobility with route optimization
3.
MULTI-LINK
3.1
Case 2: Multiple mobile addresses, multiple foreign sub-networks
3.1.1
Case 2 Topology
Figure 14 shows the topology when an aircraft is “at home” on more than one network. This is allowed by
the MIPv6 specification and could be required for basic communication if foreign sub-networks don’t
internetwork.
Correspondent Node,
e.g. FAA Application Host or Proxy
Sub-network 2
(e.g. SATCOM Saf ety Services)
Administrative
Domain 2 (AD2)
CN
ATN IPS Routed Internet
Correspondent networks
have no special mobility
requirements
Administrative
Domain 1 (AD1)
Link Access
Points
Layer 3 may be a
handover, or may
be connected in
parallel in this case
Sub-network 1
(e.g. airport hosted AeroMacs)
L2 Handovers
transparent to L3 and
above
Figure 14 Case 2 Topology
MN
Mobile Node,
e.g. Aircraf t
may or may
not support
MIPv6
- 18 ACP-WGWI18/WPxx
3.1.2
Case 2 Basic MSC
Figure 15 MSC 2a: Aircraft gets two addresses
3.1.3
Implications of Case 2.
The current standards impose the following rules on the multi-address version of multi-link shown above:
1. Aircraft can have only one current data authority.
=> Implies someone (air or ground?) would have to coordinate downstream clearance
facility and transfer of data authority to the new link.
2. Applications are associated with individual dialogs; Dialogs (as currently defined) are
associated with transport connections; Transport connections are associated with IP
addresses.
=> Implies existing dialog could not be transferred to new link but could be used as long
as AC keeps both links.
3. Security is implemented by associations at the dialog layer using the calling and called IP
addresses.
=> Implies each session will have to set up its own security using one and only one
address.
4. CM logon can only associate one address with each application.
=> Implies either the aircraft will have to manage multiple connections or ground CM
application will have to change to allow alternative address for a single application.
- 19 ACP-WGW01/WP-01
3.1.4
Using multi-link to support independent application sessions.
Figure 16 shows one way multiple links could be potentially be used simultaneously using current
standards.
This example assumes new aircraft functionality and a potential enhancement to the context management
application but is otherwise consistent with existing industry standards. This is not in any sense a general
solution however, because there is no redundancy/failover capability or load balancing and would
probably only work in very specific circumstances.
Figure 16 MSC 2b: Use of two CPDLC sessions