EUROCONTROL ATN/IPS PROTOTYPE - VALIDATION REPORT



[pic] |

International Civil Aviation Organization

WORKING PAPER |ACP-WGI-10/WP-04

| |

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

Working Group I – Internet Protocol Suite

Montreal, Canada April 27 – May 1, 2009

| | |

ATN/IPS Prototype - Validation Report

Presented by EUROCONTROL

SUMMARY – Original Paper is provided as an Attachment

ATTACHMENT – ATN/IPS Prototype – Validation Report.

|ATN/IPS Prototype - Validation Report |

Edition Number : 1.2

Edition Date : 29/04/09

Status : Released Issue

Intended for : EATM Stakeholders

DOCUMENT CHARACTERISTICS

|TITLE |

|ATN/IPS Prototype - Validation Report |

|Publications Reference: | |

|Document Identifier |Edition Number: |1.2 |

|ATNIPS-090112-VR |Edition Date: |29/04/09 |

|Abstract |

|This document presents the outcome of the EUROCONTROL ATN/IPS trials to validate the use of Mobile IP standards to enable air-ground |

|network mobility services as specified in ICAO Document 9896. This document consolidates the outcome of validation activities that |

|terminated December 9th 2008 and final tests conducted in February 2009 devoted to NEMO and route optimisation. Intermediate reports were|

|provided to ACP/WGI in the course of 2008 to prepare the content of ICAO Document 9896. The trials demonstrate the validity of the |

|content of ICAO Document 9896. |

|Keywords |

|ICAO |ATN |IPS |OSI |

|MIPv6 |Network |Network Mobility (NEMO) |PMIP |

|Authors |

|Atos Origin (RJK, CGD), EUROCONTROL |

|Contact(s) Person |Tel |Unit |

|Eivan Cerasi |+32 2.729.37 91 |DAP/CSP |

|STATUS, AUDIENCE AND ACCESSIBILITY |

|Status |Intended for |Accessible via |

|Working Draft |( |General Public |( |Intranet |( |

|Draft |( |EATM Stakeholders |( |Extranet |( |

|Proposed Issue |( |Restricted Audience |( |Internet (eurocontrol.int) |( |

|Released Issue |( | |

DOCUMENT APPROVAL

The following table identifies all management authorities who have successively approved the present issue of this document.

|AUTHORITY |NAME AND SIGNATURE |DATE |

|WP Leader |Eivan Cerasi |29/04/09 |

|CND/CNS/COM Domain Manager |Jacky Pouzet |29/04/09 |

| | | |

| | | |

| | | |

| | | |

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present document.

|EDITION |EDITION |REASON FOR CHANGE |PAGES AFFECTED |

|NUMBER |DATE | | |

|1.0 |12/01/2009 |Initial version | |

|1.1 |20/04/2009 |Inclusion of follow-up tests on MIPv6 route optimisation and NEMO |Section 3.4, |

| | | |Annex 1, |

| | | |Annex 4 |

|1.2 |29/04/09 |Final editorials |7, 8, 24, 31 |

| | | | |

| | | | |

Publications

EUROCONTROL Headquarters

96 Rue de la Fusée

B-1130 BRUSSELS

Tel: +32 (0)2 729 4715

Fax: +32 (0)2 729 5149

E-mail: publications@eurocontrol.int

Contents

DOCUMENT CHARACTERISTICS 2

DOCUMENT APPROVAL 3

DOCUMENT CHANGE RECORD 4

EXECUTIVE SUMMARY 7

CHAPTER 1 – ATN/IPS Trials 8

1.1 Objectives 8

CHAPTER 2 – ATN/IPS prototype 9

2.1 Hardware platform 9

2.1.1 Network topologies 10

2.1.2 IPv6 routing 10

2.1.3 Equipment 10

2.1.4 Hardware platform limitations 11

2.2 Software components 11

2.2.1 Datalink Service Simulator: dslu 12

2.2.2 Dialogue Service Provider: dslp 13

2.2.3 Dialogue Service Interface: dsli 13

2.3 Platform issues and workarounds 13

2.4 Means of compliance control 14

CHAPTER 3 – ATN/IPS validation 15

3.1 IPS Dialogue Service 15

3.2 Validation scenarios 15

3.2.1 Aircraft logon 16

3.2.2 Transfer of ATC communication 16

3.3 Mobility validation scenarios 16

3.3.1 Mobility Service Providers 17

3.3.2 Test strategy 17

3.3.3 Aircraft mono ACSP, mono ANSP flight, no mobility 18

3.3.4 Aircraft mono ACSP, multi ANSP flight, no mobility 18

3.3.5 Aircraft Mono ACSP, mono ANSP flight, mobility PMIPv6(PMIPv6 18

3.3.6 Aircraft mono ACSP, mono ANSP flight, mobility MIPv6(MIPv6 18

3.3.7 Aircraft mono ACSP, multi ANSP flight, mobility MIPv6(MIPv6 18

3.3.8 Aircraft mono ACSP, multi ANSP flight, mobility PMIPv6(PMIPv6 19

3.3.9 Aircraft multi ACSP, mono ANSP flight, mobility MIPv6(MIPv6 19

3.3.10 Mobility MIPv6(PMIPv6 19

3.3.11 Mobility PMIPv6(MIPv6 19

3.4 Follow-up features 20

3.4.1 MIPv6 route optimisation 20

3.4.2 Network Mobility (NEMO) 22

3.4.3 Advanced validation 23

CHAPTER 4 – Validation outcome 24

4.1 ATN/IPS Dialogue Service 24

4.2 ATN/IPS mobility 25

4.3 Handover latency 27

4.4 Mobility signalling on the A/G link 28

CHAPTER 5 – Conclusions 31

ANNEX 1 – Platform design 32

ANNEX 2 – Software validation 37

ANNEX 3 – Mobility scenarios 39

ANNEX 4 – Protocol analysis 42

ANNEX 5 – Dialogue Service validation scenario 52

REFERENCES 56

LIST OF ABBREVIATIONS 57

EXECUTIVE SUMMARY

Intermediate reports of the related content of this document were submitted to ICAO ACP/WGI in the course of 2008 to prepare the content of ICAO Document 9896 (ATN/IPS Manual). Edition 1.0 of this document consolidated the outcome of validation activities that terminated December 9th 2008 which focused on the mandatory elements of ICAO Document 9896. Edition 1.0 was presented to the EUROCONTROL Communications Team early 2009. Edition 1.1 integrates final tests of the ATN/IPS optional and future mobility features by covering MIPv6 Route Optimisation and Network Mobility (NEMO).

The ATN/IPS validation

The specifications for the Aeronautical Telecommunications Network have been amended in order to introduce the IP suite termed ATN/IPS (ICAO Annex 10 Amendment 83). Ground deployment of the ATN/IPS ICAO 9896, “Manual for the ATN using IPS standards and Protocols”, has already begun within the European region. The ATN/IPS can also be used as a means to provide mobility for aircraft by using Mobile IPv6 over air-ground communications links.

EUROCONTROL DAP/CSP has trialled this means of interoperability through the development of an air/ground demonstrator implementing part of ATN/IPS manual (ICAO Doc 9896).

The main focus of the trials was to develop a prototype implementation of the ATN/IPS dialogue service defined in ICAO Document 9896 which is specific to the aviation community for air-ground communications and to make use of it over a Mobile IP platform. The trials consisted of simulating interoperability between mobile users (aircraft) and a ground ATN/IPS infrastructure (ACSP + ANSP) to validate the ICAO ATN/IPS manual. It is expected that these trials will be followed by further field trials organised by other ICAO stakeholders.

Scope of the document

This document summarises the outcome of the EUROCONTROL ATN/IPS trials which confirms that the maturity of the ICAO ATN/IPS manual (Doc 9896). This document will also be forwarded to external stakeholders and ICAO ACP/WG-I in particular as validation evidence.

ATN/IPS Trials

1 Objectives

As contribution to ICAO ACP/WG-I, these trials were executed by EUROCONTROL DAP/CSP, with the aim to demonstrate and validate the interoperability specifications of ICAO Doc 9896 (also referred as ATN/IPS manual) for air-ground communications.

The trials consisted of the implementation of an ATN/IPS prototype, used for a laboratory-based validation.

The intent of these trials were to:

• Assess the use of legacy CM and CPDLC applications (as specified ICAO Doc 9705/9880) over the considered ATN/IPS internetwork:

- validate the ATN/OSI convergence: “IPS Dialogue Service”,

- integrate ASN.1 extensions for use of IP addressing in CM.

• Set-up a network platform implementing the ATN/IPS architecture.

• Perform mobility scenarios to validate CM/CPDLC exchanges over IP mobility specifications as described in the ATN/IPS manual: MIPv6 + suggested enhancements (route optimization, PMIPv6, NEMO).

• Demonstrate the transparency of aircraft IP mobility at CM/CPDLC application level.

Validation of the ground ATN/IPS is considered out of scope as the use of IPv6, BGP4+ routing and aviation applications are already in operations. Furthermore, the validation of Mobile IPv6 standards is also out of scope as several commercial products already exist.

ATN/IPS prototype

1 Hardware platform

The ATN/IPS prototype hardware platform is presented in Figure 1; it was designed with the aim to:

• Provide connectivity for IP based mobility solutions: MIPv6, PMIPv6 and NEMO;

• Simulate Air Traffic Control application exchanges (CM and CPDLC) in line with operational conditions: aircraft logon, roaming (layer 2 handoff), transfer of communication between ATC centres.

• Simulate multi-path air-ground communications (different access points and 2 distinct ACSPs).

[pic]

Figure 1: ATN-IPS hardware platform

Additional information relating to the hardware platform (i.e. physical inter-connections, detailed addressing scheme) can be found in ANNEX 1 – platform design.

1 Network topologies

The platform provides network topologies serving 3 distinct objectives:

• MIPv6 testing

• PMIPv6 testing

• NEMO testing

The routers configurations enable:

• PMIP connectivity to ACSP1

• NEMO / MIPv6 connectivity to either ACSP1 or ACSP2

The air-ground communication is simulated using WLAN (Wi-Fi 802.11); the aircraft’s roaming is triggered changing its WLAN attachment. Depending on the attached WAP (wireless access point), the aircraft benefits either MIPv6 or PMIPv6 connectivity.

2 IPv6 routing

The IPv6 prefixes assigned to the different organisations are as follows:

• ANSP1: 2001:4b51::/32

• ANSP2: 2001:4b52::/32

• ANSP3: 2001:4b53::/32

• ACSP1: 2001:4b54::/32 (prefix includes aircrafts made accessible through ACSP1)

• ACSP2: 2001:4b55::/32 (prefix includes aircrafts made accessible through ACSP2)

Routing between organisations is enabled with BGP4+ and due to the small scale of the IPS platform; internal routing is provided by iBGP4+ (not EIGRP, OSPF, RIPng, etc.) when needed within organisations.

ACSP1G and ACSP2G routers (refer to ANNEX 1 – platform design) advertise their /32 IPv6 prefix to other organisations (ACSP, ANSP).

No filtering is applied, meaning that all hosts and routers are reachable within the ATN/IPS hardware platform.

3 Equipment

The ATN/IPS specification was established with the specific goal of providing global ATM services based on commercial off-the-shelf technologies. The EUROCONTROL ATN/IPS validation trials apply this approach by making use of standard commercial equipment to build its network platform:

• Cisco routers series : 26xx and 28xx (IPv6 + MIPv6)

Firmware: Cisco IOS® versions 12.4(15)T5 or 12.4(20)T (for NEMO).

• 6Wind routers series: 6221 and 6211 (PMIPv6)

Firmware: 6WindGate™ version 2.6.16.

The PCs used on the platform are Linux Fedora Core 8 based, customized as follows:

• kernel 2.6.23 patched with the latest Mobile IPv6 Linux (MIPL) patches:

• mip6d to run Mobile IPv6 stack on aircraft side ( acting as a Mobile Node (cf. RFC 3775)

• mip6d to run Mobile IPv6 stack inside ACSP2 ( acting as a Home Agent (cf. RFC 3775)

• mip6d to run Mobile IPv6 stack on ATC center -> acting as a Correspondent Node (cf. RFC 3775) for the Route Optimisation.

• PPPoE client for Linux used for the PPP connection between the Mobile Node and the Mobile Access Gateways (PMIPv6)

4 Hardware platform limitations

• Layer 2 hand-over

No layer-2 hand-overs with the same access router are simulated. Indeed, when the mobile node changes access point, a new access router is involved; this will be detected by mobile IP and will lead to a new CoA. The implementation of layer-2 hand-over without change of CoA is not relevant for this validation activity and is only worth testing in the context of a field or radio trial.

• Static routing is required on the platform between 6Wind and Cisco routers

There is no shared dynamic routing protocol between 6Wind and Cisco routers, with the current Cisco IOS and 6Wind firmware. 6Wind provides RIPngV2 and BGP3, while Cisco provides RIPngV1 and BGP4.

To fulfil the test scenarios, static routes were set up on the PMIPv6 domain, to ensure correct network routing.

• The MIPL 2.0 Mobile Node was not able to interoperate with a Cisco Home Agent

The MIPv6 HomeAgent resides on a Linux PC, hosted on ACSP2 network. This approach was selected because preliminary connectivity trials revealed interoperability issues between the Linux MIPL stack and the Cisco MIPv6 HomeAgent implementation 12.4(15)T5.

The HMAC-SHA1 authentication fails; the IPsec encapsulation used by MIPL is not compatible with the one of the Cisco Routers and is subject of further investigation which may lead to an update of this report, see 3.4.

2 Software components

The overall objective of the ATN/IPS prototype is to validate the use of legacy ATN applications over an experimental ATN/IPS internetwork, as specified in the ATN/IPS manual:

• validation of ATN/OSI convergence layer : “IPS Dialogue Service”,

• integration of ASN.1 extensions for use of IP addressing in CM.

Software components were developed as part of the ATN/IPS demonstrator (dslu, dslp and dsli) with the aim to simulate CM and CPDLC applications over the ATN/IPS DS. The components generate valid ATC application messages to simulate exchanges between a roaming aircraft and multiple ATC ground facilities.

The end-to-end communication is established using the ATN/IPS standard and protocol as specified in ICAO Document 9896.

[pic]

Figure 2: ATN/IPS software architecture

1 Datalink Service Simulator: dslu

The dlsu process simulates CM or CPDLC services acting as either airborne or ground application. It relies on the Dialogue Service to establish a communication relationship with a peer datalink application and provides the following:

• Supported services: CM Logon Request/Response, Contact Request/Response, CPDLC Start Request/Response, End Request/Response, message transfer.

The list of supported DM and UM messages are detailed in the following table:

|Element ID |Semantic |

|UM19 |MAINTAIN [level] (expressed in 'Flight Level' unit) |

|UM159 |ERROR [errorInformation] |

|UM161 |END SERVICE |

|UM162 |SERVICE UNAVAILABLE |

|UM169 |[freetext] |

|UM183 |[freetext] |

|UM227 |LOGICAL ACKNOWLEDGEMENT |

|DM0 |WILCO |

|DM1 |UNABLE |

|DM2 |STANDBY |

|DM3 |ROGER |

|DM6 |REQUEST [level] (expressed in 'Flight Level' unit) |

|DM62 |ERROR [errorInformation] |

|DM67 |[freetext] |

|DM100 |LOGICAL ACKNOWLEDGEMENT |

• Interprets and executes textual commands to encode (using Packed Encoding Rules), send and receive CM and CPDLC messages.

• Validates the use of IPS Dialogue Service acting as DS-User.

2 Dialogue Service Provider: dslp

The dslp process implements the Dialogue Service mapping (primitives, parameters and FSM) specified by the ATN/IPS DS [1]; this component is termed the DS-Provider entity:

• Supports TCP/IPv6 and TCP/IPv4 communication stacks.

• Supports dual network attachment (multi-homed).

• Provides connection oriented Dialogue Services (D-START, D-DATA, D-END, D-ABORT, D-P-ABORT) over either TCP or UDP transport layers.

• Provides connectionless Dialogue Services (D-UNITDATA) over UDP.

3 Dialogue Service Interface: dsli

dsli can be referred to as the application-programming interface. Practically, this is a shared library (libdsli) providing a TCP based communication between a DS-User and its local DS-Provider.

3 Platform issues and workarounds

Some fixes have been applied to Linux and 6Wind routers to ensure a proper behaviour of MIPv6 and PMIPv6 environments.

• Standard linux pppoe interface workaround

The out-of-the-box PPP over Ethernet daemon, taking care of the point-to-point connection for the PMIPv6 connectivity expects to be run over ethernet interface “eth0” whereas the prototype needed to work with an interface “ath0”.

The interface can be selected (command line argument “-I ath0”) but the command was ineffective (eth0 was always used). As a workaround, the binary executable “pppoe” has been patched to replace the hard coded “eth0” string by “ath0”.

• Mip6d daemon fixes

• Random memory corruption

A random memory corruption was occurring on each “Binding Ack” transmission. The “Binding Ack” context was released, and used some time later to store a “Binding Ack” result. This problem was fixed in a patch and reported to the MIPL community.

• On reception of “Router Advert” from a second router on the home network, mip6d was flushing its home networks table. Once flushed, the home agent was no longer able to serve any home address and answered each “Binding Update” with a status error (no home network). This problem was fixed in a patch and reported to the MIPL community.

• 6Wind routers misbehaviour

• Core of the Local Mobility Agent (PMIPv6 “home agent”)

This problem occurs when 2 Mobile Access Gateways (MAGs) are sending “Binding Update” to the same LMA. The root cause of the problem is not yet determined but is under investigation by 6wind on the basis of collected data (network captures, core dump, router traces). A procedure to recover from this situation is documented.

• XMS daemon termination

An unpredictable termination of xmsd process was noticed while applying a configuration on a 6Wind router. A simple reboot of the 6wind router fixes the problem most of the time. Nevertheless, it occasionally entailed a corruption of the start-up configuration leading to the incapacity to manage the router even after a reboot.

• Unexpected Wifi association

One Wifi access point was stealing a Wifi association between the mobile node and another Wifi access point; even if access points had different ESSID and MAC addresses. Because of the broadcasted IPv6 “Router advert”, the mobile was changing his CoA, but couldn’t exchange anymore IPv6 or even LLC packets on the Wifi association.

The problem disappeared by using a specific WEP key for the faulty Wifi access point.

4 Means of compliance control

The correct behaviour of the prototype was assessed by:

• Logs provided by the software components: ATN-IPS software, PPPoE client or mip6d.

• Network captures using either Wireshark® (for Linux PCs) or tcpdump (for Cisco and 6wind).

• As complementary work, we have developed a wireshark plug-in to decode the ATNPKT format, which is the format of messages exchanged between peer DS-providers.

• Observation of the IPv6 tunnels created on the Linux PCs when the mobility is triggered (Linux commands: ifconfig / ip)

ATN/IPS validation

1 IPS Dialogue Service

The approach to ATN/IPS validation is based on the following two steps:

• The first is to demonstrate the suitability of the specified IPS Dialogue Service to be used as convergence layer between the legacy ATN applications and the ATN/IPS internetwork.

• The second is to provide a way to simulate operational ATC exchanges covering the sequences of events that are most likely to occur during the progress of a flight over a mobile IP environment:

• Aircraft connection to one ANSP before takeoff.

• Aircraft handover during the flight: either at the link layer level (roaming) or at the application level (transfer of communication between ATC centres).

• Aircraft ordered disconnection after landing.

• Aircraft loss of connection during the flight (although being an unlikely event).

For this purpose, unit test-cases were defined for the software validation and are summarized in ANNEX 2 – Software validation. These were then supported by validation scenarios which are summarized in ANNEX 5 – Validation scenario.

It is to be noted that the content of the above two Annexes are derived from the Site Acceptance Test document of the project.

2 Validation scenarios

The developed Datalink Service Simulator (see section 2.2.1) provides an interface (in text-mode) to invoke CM and CPDLC services. With this interface “step-by-step” message exchanges can be transmitted to simulate ATC exchanges (an example of step-by-step scenario is given in ANNEX 5 – Validation scenario).

Alternately, the input commands of the simulator can be generated through shell scripts; this modus operandi avoids the air and ground operators from having to enter step-by-step commands. This interface mode is referred to as the automated mode. For convenience purposes, the validation scenarios developed for the trials were run in automated mode.

The automated mode allowed to build complex validation scenarios involving 3 distinct hosts, used to simulate:

• a roaming aircraft,

• an ATC centre acting as CDA (current data authority),

• an ATC centre acting as NDA (next data authority).

1 Aircraft logon

This automated mode script simulates an aircraft logon to ATC1 with exchange of CPDLC freetext in both directions. The following script parameters can be configured: count of freetext exchanges, delay between transmissions, transport layer selection (TCP vs. UDP), keepalive delay, SSID (to switch the WLAN attachment during the test).

This automated script is used for all validation scenarios requiring a single ANSP (mono-ANSP flights defined in section 3.3.2).

2 Transfer of ATC communication

This automated mode script simulates a transfer of communication between two ANSPs. The script parameters are the same as for the logon.

[pic]

Figure 3: Operational context for validation

This automated script is used for all validation scenarios requiring multiple ANSPs (multi-ANSP flights defined in section 3.3.2).

3 Mobility validation scenarios

The purpose of the mobility validation scenarios is to validate the use of IP mobility as described in the ATN/IPS manual. Furthermore, they demonstrate ATN/OSI convergence under stable or roaming conditions:

• Initiate Context Management and establish CPDLC connections over the ATN/IPS platform internetwork (between airborne and ground ATC facilities).

• Maintain end-to-end dialogues (CM logon + CPDLC connections):

when roaming between mobile access points (change of ACSP / Mobility Service Provider),

when changing the type of mobile connectivity (MIPv6 to PMIP, PMIP to MIP, …)

• Transfer ATC control between ground facilities (CDA and NDA) hosted in different ANSP; this requires the establishment of simultaneous CPDLC connections between the aircraft and both ANSP during the transfer.

The test observations had particularly focused on:

• Network silence duration in handover situations.

• Network exchanges in each situation: nominal, layer 2 loss, handover.

• IPS dialogue states, in respect to operator commands and network events.

1 Mobility Service Providers

For the purpose of the trials, the following mobility service providers (MSP) were configured.

• ASCP1: PMIPv6 MSP

Local Mobility Anchor (mistral) + 2 Mobile Access Gateways (tivano, sirocco).

Provides MIPv6 connectivity to ACSP2 through a dedicated IPv6 access router (acsp1g); or through any of the 2 gateways acting as access router.

• ACSP2: MIPv6 MSP

Home Agent (castle) + 2 access routers (ascp2a1, acsp2a2).

Note: it could have been decided to put them on ANSP side, as according to the ATN/IPS architecture; an ANSP may also serve as MSP.

2 Test strategy

The mobility validation scenarios are described in regards of the following criteria:

• Movement of aircraft toward the ACSP domain:

Mono-ACSP means that the relation with the ACSP is preserved although the aircraft may change its point of attachment.

Multi-ACSP means that the relation between the aircraft and the ACSP will change during the test. When changing ACSP, the aircraft preserves its attachment to the MIPv6 HA; the second ACSP is used as a transit domain. Although this is technically possible, this strategy would require some kind of strategic/business agreement between ACSP to inter-operate this way.

• Controlling ANSP:

Mono-ANSP means that only one ANSP is involved in the scenario (aircraft logon).

Multi-ANSP means that 2 ANSPs are involved in the scenario (ATC transfer).

• Change of point of attachment, and possibly of mobility (MIPv6 vs. PMIPv6) during the test:

No mobility means that the aircraft never changes point of attachment i.e. wifi access point (MIPv6 or PMIP).

PMIPv6(PMIPv6 means that the aircraft changes the access point and therefore also changes the serving PMIPv6 gateway.

MIPv6(MIPv6 means that the aircraft changes MIPv6 access router; this may also entail a change of ACSP, but the serving HA is preserved[1].

MIPv6(PMIPv6 and MIPv6(PMIPv6 changes were not tested because this would require a change of HoA; and therefore this would be disruptive for the application dialogues.

The list of mobility validation scenarios is given here after; for a detailed description of the scenarios refer to ANNEX 3 – Mobility Scenarios.

3 Aircraft mono ACSP, mono ANSP flight, no mobility

|Object |Simulate an aircraft always bound to ACSP2, controlled by ANSP1, without change of network AP (access point). |OK |

4 Aircraft mono ACSP, multi ANSP flight, no mobility

|Object |Simulate an aircraft controlled initially by ANSP1 and then transferred to ANSP2 during flight, always bound to ACSP2, |OK |

| |without change of network AP. | |

5 Aircraft Mono ACSP, mono ANSP flight, mobility PMIPv6(PMIPv6

|Object |Simulate an aircraft always bound to ACSP1, controlled by ANSP1, with a change of network AP while preserving the |OK |

| |mobility technology (PMIPv6). | |

6 Aircraft mono ACSP, mono ANSP flight, mobility MIPv6(MIPv6

|Object |Simulate an aircraft always bound to ACSP2, controlled by ANSP1, with a change of network AP while preserving the |OK |

| |mobility technology (MIPv6). | |

7 Aircraft mono ACSP, multi ANSP flight, mobility MIPv6(MIPv6

|Object |Simulate an aircraft always bound to ACSP2, controlled by ANSP1, with a change of network AP while preserving the |OK |

| |mobility technology (MIPv6), and being transferred to ANSP2 during flight. | |

8 Aircraft mono ACSP, multi ANSP flight, mobility PMIPv6(PMIPv6[2]

|Object |Simulate an aircraft always bound to ACSP1, controlled by ANSP1, with a change of network AP while preserving the |OK |

| |mobility technology (PMIPv6), and being transferred to ANSP2 during flight. | |

9 Aircraft multi ACSP, mono ANSP flight, mobility MIPv6(MIPv6

|Object |Simulate an aircraft controlled by ANSP1, changing ACSP during flight (from a network AP in ACSP2 to a network AP in |OK |

| |ACSP1) while preserving mobility technology (MIPv6). | |

10 Mobility MIPv6(PMIPv6

|Object |Simulate an aircraft always bound to ACSP1, controlled by ANSP1, with change of network AP and mobile attachment type |N/A |

| |during test. | |

| |Simulate an aircraft controlled by ANSP1, changing ACSP during flight (from a network AP in ACSP2 to a network AP in | |

| |ACSP1) with a simultaneous change in mobile attachment type (MIPv6 to PMIPv6). | |

| |As the hand-over is not seamless, this test is considered as failed because changing from MIPv6 to PMIPv6 is not transparent (see |

| |section 4.2). Operational procedures would have to circumvent this issue. |

11 Mobility PMIPv6(MIPv6

|Object |Simulate an aircraft always bound to ACSP1, controlled by ANSP1, with a change of network AP and change of mobility |N/A |

| |technology. | |

| |Simulate an aircraft controlled by ANSP1, changing ACSP during fly (from a network AP in ACSP2 to a network AP in ACSP1)| |

| |with a simultaneous change in mobile attachment type (PMIPv6 to MIPv6). | |

| |As the hand-over is not seamless, this test is considered as failed because changing from PMIPv6 to MIPv6 is not transparent (see |

| |section 4.2). Operational procedures would have to circumvent this issue. |

4 Follow-up features

Some additional ATN/IPS optional mobility features focusing on MIPv6 Route Optimisation and NEMO were left to a second stage. For logistic reasons, these features were not directly tested on the mobility platform set up for the experimentation (see section 2.1) ; but on dedicated platform described here after. It is to be noted that these features are being integrated to the EUROCONTROL mobility platform in April 2009 which will not lead to an update of this report.

1 MIPv6 route optimisation

[pic]

Figure 4: MIPv6 Route Optimisation test platform

It is interesting to note that the MIPL 2.0 software used on the mobile node and home agent can be used on a correspondent node (i.e. on the ANSP side). Through configuration it is possible to enable route optimisation, and bypass the tunnel between the mobile node and his HA to reduce overhead.

This requires some dialogue between the correspondent node and the home agent, and between the mobile node and the correspondent node so that the correspondent node is notified of mobile movements, and adjusts its own tunnel toward the mobile.

The mobile sends two messages to the correspondent node. One through the Home Agent, the Home Test Init (HoTI) , and one directly to the correspondent node, the Care of Test Init (CoTI). Each one of the messages carries a cookie (different between them) in order to enable the Route Optimisation. At receiving the HoTI and CoTI, the correspondent node replies by an Home Test (HoT) through the Home Agent and by a Care of Test (CoT) directly to the CN, the messages carrying their respective cookie. When the mobile node receives the HoT and CoT, an algorithm compares the couple of cookies (HoTI/HoT) and (CoTI/CoT), if they are identical, the Route Optimisation is enabled, if they are different, the Route Optimisation is not established.

2 Network Mobility (NEMO)

[pic]

Figure 5: NEMO test platform

NEMO is an extension of Mobile IPv6. It has negligible impact on the ACSP side; on aircraft side, it implies the use of a mobile router.

Network mobility provided by a mobile router was proved to be functional with MIPv6 USAGI software. The mobile router was hosted on a Linux PC with MIPv6 USAGI software, and the home agent remained on the same Linux PC as in the former test phase.

The mobility mechanism is almost the same. The binding update and acknowledge phase is the same, with a special flag for “mobile router” (which was not set for normal mobile node). After the binding phase, another phase is performed to exchange mobile network information (ICMPv6 Mobile Prefix Solicitation and ICMPv6 Mobile Prefix Advertisement).

This allows the mobile router to choose its own prefix from its home network environment to be broadcasted on its internal network (i.e. in the aircraft) through Router Advertisements. A computer (laptop, PDA, …) connecting to the mobile router will generate its own address through auto-configuration, as if it was on the home network.

Then, the communication flow for the laptop is the same as if it was on the real home network, and the mobile router tunnels the flow to the home agent.

The networks used in the experiment are (check end of ANNEX 1 –):

• 2001:4b54:1::/64 : the home network, directly wired

• 2001:4b54:2::/64 : the home network, deserved by mobile router

• 2001:4b54::/32 : the group of reachable networks through directly wired routers and mobile routers (termed extended “home network” in Figure 6)

• 2001:4b55:1::/64

[pic]

Figure 6: NEMO IPv6 addressing test environment

3 Advanced validation

The Linux MIPv6 software was proved to be incompatible with Cisco's implementation of MIPv6 protocol. The observed behaviour was authentication rejects (status = 132) send from the Home Agent hosted on Cisco router, while a Linux MIPv6 USAGI software was attempting to send Binding Updates to it.

A deeper analysis brings these findings:

• Cisco requires authentication data in the Binding Update, as specified in the MIPv6 RFC 3775

• Cisco requires this authentication data to conform to RFC4285 (ie. in a Mobility Header Option, without IPSEC)

• Linux provides authentication with either :

o IPsec policies, according to RFC 2402

o or authentication data which conforms to MIPv6 RFC3775 (chapter 5.2.6), also reported in (ie. in a Mobility Header Option, without IPSEC)

There is no common authentication mechanism available between Cisco and Linux software.

As authentication is mandatory on Cisco, Cisco and Linux are at this point incompatible regarding MIPv6 protocol. This incompatibility is a direct result of product implementation which does not directly impact the ATN/IPS specifications.

Validation outcome

1 ATN/IPS Dialogue Service

The maturity of ICAO Document 9896 « IPS Dialogue Service » specification has been validated by these trials.

Nevertheless it will not be directly interoperable with ATN/OSI based applications without the use of some form of application gateway. Even if this is not the intent of the ATN/IPS specification, this fact is important to highlight.

Simulators of legacy CM and CPDLC applications were run over the trial ATN/IPS internetwork using either TCP or UDP transport layers.

The applicative dialogues are maintained while the aircraft roams between wireless access points.

The aircraft is still reachable through the same IPv6 address (HoA) all along its journey; even if for routing reasons, the HoA cannot be shared between MIPv6 and PMIPv6 domains (section 4.2).

A first minor improvement to the ATNPKT format description, in section “2.2.5.5.13 User Data” can be envisaged. The size of the user data part could be expressed in bits rather than in bytes, the destination will need to know the exact number of used bits to decode the PER. This change does not impact the ATNPKT format itself since the 2 bytes used for the size of the user data part are sufficient to include 8191 bytes, whereas the max for UDP is 8184.

A second improvement to the ATNPKT format can be to include the length of the user data to the ATNPKT header. This would be more convenient since only 2 read operations would be required (compared to the 3 operations required with current format):

• One for the header to determine the size of the variable part.

• One for the variable part including optional fields and user data.

Against this change would be need to transmit the 2 bytes for the user data size at all times even in the absence of user data.

2 ATN/IPS mobility

Mobile IPv6 architecture is similar to the current ATN/OSI implementation. Although ATN/OSI does not have a dedicated HomeAgent, the ACSPs have built their service upon centralised architectures demonstrating its suitability for implementation. The benefit of Mobile IP for ATN/IPS is the ability to define borders between 3 major areas:

[pic]

Figure 7: ATN/IPS mobility layer boundaries

Furthermore, Mobile IP presents a mobility solution supported by commercial vendors that will certainly enrich its features overtime.

The following points address the co-existence of MIPv6 and PMIPv6. The relevance of these issues would have to be considered with regard an implementation plan; however, their knowledge is essential as they may influence the design of ACSP services.

• A MIPv6 connectivity can be achieved through a PMIPv6 domain, but PMIPv6 connectivity can’t be achieved through a MIPv6 domain

A MIPv6 enabled mobile node only needs from his network access point the CoA generation. This is simply provided by a typical router, answering IPv6 Router Solicitations, and broadcasting Router Advertisements with an IPv6 prefix. The PMIPv6 MAG, which is the network access point, can perfectly be set up to provide Router Advertisements, in order to enable the MIPv6 mechanism. This specific MAG ability is described in PMIP RFC 5213 – section 6.14.

On the contrary, a PMIPv6 enabled node needs from his network access point a point-to-point access, which would then trigger mobility messages (i.e. a MAG’s job). The MIPv6 network access point is a router without a point-to-point enabled configuration. And even if it could offer a PPP connection, it would still have to trigger the mobility messages, and would finally just need to be a PMIPv6 MAG!

• A mobile node attached to a PMIPv6 domain cannot enter another PMIPv6 domain without changing its HoA

As different PMIPv6 domains have different Home Agents, and as each home agent manages different home networks, entering a PMIPv6 domain induces a home network, and an IPv6 prefix.

Home networks can’t be shared between PMIPv6 domains, neither by PMIPv6 home agents. As will be described bellow, once a PMIPv6 home agent takes control of a HoA, it never releases it. That’s one reason why there can’t be two home agent managing the same home network. The other one would be a continuous advertisement battle between two PMIPv6 HomeAgents to convince the external world (understand here the ANSPs) each of them holds the true HoA.

It is to be noted that IETF experts are considering mechanisms to chain adjacent PMIP domains but it will take a number of years to publish RFCs.

• PMIPv6 enabled mobile cannot be MIPv6 enabled at the same time

Once the mobile connects once to the PMIPv6 MAG, the PMIPv6 HomeAgent advertises the mobile HomeAddress (through IPv6 Neighbour Advertisements). The HoA is never released by the PMIPv6 HA. Enabling MIPv6 in parallel raises the following concerns:

• The HoA cannot be shared between the PMIPv6 HA and the MIPv6 HA

A mobile node cannot be MIPv6 and PMIPv6 enabled at the same time with the same Home Address.

The HomeAgent has to be set up to run in either PMIP or MIP mode, but not both. As a matter of fact, the behaviour is different in each mode:

In MIPv6, a binding update from a mobile node must be authenticated by IPsec usage, because otherwise the binding update would have been accepted from any host claiming the Home Address. The mobile node may return to the home network.

In PMIPv6, the mobile node creates a point-to-point connection to its gateway (cf. RFC 5213, 6.3). This triggers the binding update between the gateway and the home agent. The point-to-point connection includes the authentication mechanism. Therefore, the mobile is only authenticated when connected through a gateway, and can’t authenticate when returning to the home network.

This implies that in PMIPv6, there’s an additional constraint for the mobile node, which cannot return to its home network. For security reasons, the PMIPv6 HomeAgent never releases its grip over the Home Address. This is the main discrepancy with the MIPv6 version of the HomeAgent. This also means that a PMIPv6 home agent is continually broadcasting IPv6 Neighbour Adverts to claim the HoA ownership.

If we assume that the HomeAgents manage distinct Home Networks, then a switch from MIPv6 to PMIPv6 changes the Home Network, and of course the Home Address.

Moreover HomeAgents cannot share Home Addresses, because they advertise the addresses to the external world, and especially to ANSPs. If two Home Agents were to advertise the same address, a distant node wouldn’t be able to choose the proper path to the mobile node.

The only solution to the problem would be an interconnection between the HomeAgents, and the sharing of Home Network. One way to achieve this could be the Global HA-HA extension, but the draft available does not address this issue yet.

• The mobile node cannot handle concurrently PMIPv6 and MIPv6 stacks for IPv6 routing reasons

The PMIPv6 connection sets up a default gateway through the point-to-point connection, to access the external world. When MIPv6 is used, the default gateway is changed to send all traffic through the newly created IPv6 tunnel towards the Home Agent.

If for any reason the MIPv6 connectivity is lost, nothing will trigger back a default route change onto the point-to-point connection.

• A ground application connected to a mobile node changing from a PMIPv6 based connection to a MIPv6 connection will loose the connection

As the home address between a MIPv6 based connection and a PMIPv6 based connection will be different, the ANSP would see his connection broken. And a reconnection wouldn’t work, as the HoA would have changed, without any awareness of the ground application.

Even if there was a deep breakthrough in MIPv6/PMIPv6 technology, allowing a common HoA to be used though MIPv6 and PMIPv6; the groundside (i.e. ANSP) will have routing issues.

In the current model, it was granted that the HoA was inside an ACSP network, and ANSP routing was very simple: all communications to an IPv6 address inside an ACSP network was routed to this ACSP. If a HoA could be shared between two ACSP, there would have to be a dedicated IPv6 address range, an some dynamic routing between all ACSPs and all ANSPs to hand over a HoA from one ACSP to another.

• Mobile Home-Agent resilience

Without optimising MIPv6 or NEMO traffic, nor implementing routing protocols between the mobile node and access routers; a distributed architecture could optimise air-ground service delivery. For example, a mesh of HomeAgents distributed between continents or dense areas can greatly improve traffic management. Such a technical arrangement has been identified in IETF drafts termed Global-HAHA.

3 Handover latency

It is important to recall that in the context of these trials a layer 2 change implies a layer 3 hand-over: During a layer 2 or 3 hand-off, the ATN/IPS applications may establish new dialogues as soon as the end-to-end connectivity is restored. On the other hand, interrupted dialogues may not resume immediately as the handover latency depends on additional events:

• MIPv6: an additional delay due to the transport layer mechanisms may appear; in fact the dialogue is resumed after the first transmission or retransmission over the new layer 2 connection.

During the tests, delays were noticed due to the TCP adaptive retransmission mechanism. A lost IP packet during a layer 2/3 handover, may be kept in the TCP retransmission queue for quite a long time because as the delay between TCP retransmissions is exponential.

In the following extract packet traces, the last TCP retransmission occurs about 4 seconds after the Binding Acknowledgement; this extra delay will be much more important if the layer 2 handover takes longer:

No. Time Source Destination Protocol Info

46 11.178544 2001:4b51:1::2 2001:4b55:3::10 TCP 43692 > 5911 [PSH, ACK] Seq=123

47 11.301195 2001:4b51:1::2 2001:4b55:3::10 TCP [TCP Retrans] 43692 > 5911 [PSH, ACK] Seq=123

48 11.724046 2001:4b51:1::2 2001:4b55:3::10 TCP [TCP Retrans] 43692 > 5911 [PSH, ACK] Seq=123

51 14.194184 2001:4b51:1::2 2001:4b55:3::10 TCP [TCP Retrans] 43692 > 5911 [PSH, ACK] Seq=123

…

67 19.949285 2001:4b55:3::2 2001:4b54:2:… MIPv6 Binding Acknowledgement

…

69 24.180311 2001:4b51:1::2 2001:4b55:3::10 TCP [TCP Retrans] 43692 > 5911 [PSH, ACK] Seq=123

70 24.219997 2001:4b55:3::10 2001:4b51:1::2 TCP 5911 > 43692 [ACK]

Depending on the transport layer implementation this delay might be reduced as it will be impacted by:

TCP ( keepalive (when enabled) + adaptive retransmissions

UDP ( IPS DS keepalive + fixed period retransmissions

The observed handover delay with MIPv6 + TCP is less than 30 seconds, in nominal case it does not exceed 10 seconds; MIPv6 + UDP is more efficient (less than 5 seconds).

• PMIPv6: same as MIPv6 + additional delay due to the PPP connection management:

The extra delay due to the TCP retransmissions is reinforced by the delay required to handle the PPP connection (termination + initialisation with a new MAG); it depends on:

Same Mobile Access Gateway after the level 2 handoff:

Polling on the PPP connection

Layer 2 handoff coupled with a change of Mobile Access Gateway:

Detection of the PPP connection termination (polling expiration)

Initiation of a new PPP connection with an alternate gateway (inter-attempts delay)

The observed handover time with PMIPv6 is about 1 minute.

4 Mobility signalling on the A/G link

The additional traffic generated on the air-ground link because of the mobility signalling shall be a major concern when choosing a mobility solution. The traces collected during the trials can be used as estimates but would need to be coupled with the capabilities of the underlying layer 2 link.

Refer to ANNEX 4 – Protocol Analysis to see the detailed protocol exchanges related to the mobility mechanisms listed below.

IPv6 mobility signalling:

• Neighbour Discovery

– ICMPv6: Router Solicitations (70 bytes), Router Advertisements (110 bytes), Neighbour Solicitations (86 bytes), Neighbour Advertisements (86 bytes).

– Used for movement detection when the mobile node changes its point of attachment (layer 2 handoff).

– Router Advertisements are periodically sent by the IPv6 routers; their frequency for access routers (A/G routers) impacts the A/G link utilisation as well as the handover latency.

– The mobile node sends periodical Router Solicitations during the layer 2 handoff.

– The amount of signalling due to the Network Discovery is variable; it might be estimated at about 500 bytes ( RS_RA exchange + (NA_NS exchange x 2)

• Home Agent Registration / Deregistration

– MIPv6: Binding Updates (110 bytes), Binding Acknowledgments (94 bytes).

– Used by a mobile node to associate a CoA to its HoA when it enters a foreign network (movement detected).

– The amount of signalling due to HA registration / deregistration is about 200 bytes.

• Return routability

– MIPv6: Home address Test Init (112 bytes), Home address Test (120 bytes), Care Of Test Init (72 bytes), Care Of Test (80 bytes).

– This procedure is used to set-up a route optimization between a mobile node and a specific correspondent node.

PMIPv6 exchanges due to the PPP dialogue between the MN and the MAG:

These exchanges are conditioned by the protocol used, in out case it was: PPP over Ethernet.

• PPP over Ethernet Discovery: PADI, PADO, PADR, PADS

• PPP PAP (Password Authentication Protocol): Authenticate-Req, Authenticate-Ack

• PPP LCP (Link Control Protocol): Conf-Req, Conf-Ack, Term-Req, Term-Ack, Echo-Req, Echo-Ack

• PPP IPv6 configuration: Conf-Req, Conf-Ack

The amount of signalling due to the PPP dialogue is:

– Init phase: 800 bytes / Polling: 90 bytes / termination phase: 90 bytes.

The following table summarizes the mobility signalling on the air-ground link:

[pic]

Conclusions

The maturity of the specified « IPS Dialogue Service » has been validated by these trials. Nevertheless, it will not allow the direct interworking of ATN applications over ATN/OSI without the use of an application gateway or dual stack devices.

ICAO ACP/WG-I may wish to review two considerations for the ATNPKT:

1) The size of the user data part could be expressed in bits rather than in bytes to facilitate the PER decoding process.

2) At the cost of two additional bytes, include the length of the user data to the ATNPKT header to reduce the read operations.

In its basic form Mobile IPv6 is well suited to support ATN applications by delivering a robust and flexible mobility solution for the aviation community along with foreseen enrichment of its features.

The ATN/IPS trials have clearly validated the content of the ICAO Document 9896 underlying the maturity of its provisions. The planning of field trials to integrate flight and environmental conditions would be the next logical step.

1

Platform design

[pic]

[pic]

|Host |Port |Address |Connected to |

|ANSP1 |Serial 0/0 | |Serial 0/0 ACPS1G |

| |Serial 0/1 | |Serial 0/0 ANSP3 |

| |Serial 0/2 | |Serial 0/2 ANSP2 |

| |FastEth 0/0 |2001:4b51:1::1/64 |CAMELEON |

| |FastEth 0/1 | | |

|ANSP2 |Serial 0/0 | |Serial 0/2 ANSP3 |

| |Serial 0/1 | |Serial 0/1 ACSP2G |

| |Serial 0/2 | |Serial 0/2 ANSP1 |

| |FastEth 0/0 |2001:4b52:1::1/64 |TIGER |

|ANSP3 |Serial 0/0 | |Serial 0/1 ANSP1 |

| |Serial 0/1 | | |

| |Serial 0/2 | |Serial 0/0 ANSP2 |

| |Serial 0/3 | | |

| |FastEth 0/0 | | |

|ACSP1G |Serial 0/0 | |Serial 0/0 ANSP1 |

| |Serial 0/1 | | |

| |Serial 0/2 | |Serial 0/2 ACSP2G |

| |Serial 0/3 | | |

| |FastEth 0/0 |2001:4b54:6::1/64 |FastEth 0/0 MISTRAL |

| |FastEth 0/1 |2001:4b54:2::1/64 | |

|ACSP2G |Serial 0/0 |2001:4b55:4::1/64 |Serial 0/0 ACSP2A2 |

| |Serial 0/1 | |Serial 0/1 ANSP2 |

| |Serial 0/2 | |Serial 0/2 ACSP1G |

| |FastEth 0/0 |2001:4b55:1::1/64 | |

| |FastEth 0/1 |2001:4b55:3::1/64 |SWITCH |

|ACSP2A1 |Serial 0/0 | | |

| |FastEth 0/0 |2001:4b55:10::150/64 | |

| |FastEth 0/1 |2001:4b55:3::150/64 |SWITCH |

|ACSP2A2 |Serial 0/0 |2001:4b55:4::151/64 |Serial 0/0 ACSP2G |

| |Serial 0/1 | | |

| |Serial 0/2 | | |

| |FastEth 0/0 |2001:4b55:11::151/64 | |

| |FastEth 0/1 | | |

|MISTRAL |FastEth 0/0 |2001:4b54:15::101/64 |HUB |

|(PMIP home agent) | | | |

| |FastEth 0/1 |2001:4b54:6::101/64 |FastEth 0/0 ACSP1G |

|TIVANO |FastEth 0/0 |2001:4b54:15:103/64 |HUB |

|(Mobile Access Gateway) | | | |

| |FastEth 0/1 |2001:4b54:13::103/64 | |

| |FastEth 0/2 | | |

|SIROCCO |FastEth 0/0 |2001:4b54:15::104/64 |HUB |

|(Mobile Access Gateway) | | | |

| |FastEth 0/1 |2001:4b54:14::104/64 | |

| |FastEth 0/2 | | |

|CAMELEON |Eth2 |2001:4b51:1::2/64 |ANSP1 |

|(ATC1) | | | |

|TIGER |Eth0 |2001:4b52:1::2/64 |ANSP2 |

|(ATC2) | | | |

|BUTTERFLY |Eth0 |2001:4b55:3::10/64 |SWITCH |

|(AIRCRAFT / mobile node) | | | |

|CASTLE |Eth0 |2001:4b55:3::2/64 |SWITCH |

|(MIPv6 home agent) | | | |

[pic]

2

Software validation

|Capacity to simulate operational ATC exchanges |Status |

|Check syntax analysis failures |OK |

|Validate the input of dialogue service commands at test application level |OK |

|Validate the input of CM and CPDLC commands at test application level |OK |

|Simulate CM and CPDLC applications (airborne/ground): |OK |

|CM Logon Req/Rsp, Contact Req/Rsp | |

|CPDLC Start Req/Rsp, End Req/Rsp, message transfer | |

|PER encoding/decoding of CM and CPDLC protocol data units: |OK |

|UM: 19, 159, 161,162,169, 183, 227 | |

|DM: 0, 1, 2, 3, 6, 62, 67, 100 | |

|Check the DS-API used between a DS-User and its local DS-Provider |OK |

|Compliance to the specified ATN/IPS Dialogue Service |Status |

|Check CM ASN.1 additions for support of IP (as defined in [2], CM ASN1 additions). The following parameters: |OK |

|groundInitiatedApplications (CMLogonRequest), | |

|airInitiatedApplications (CMLogonResponse), | |

|might be set as AEEnhancedQualifierVersionAddress ; using either an IPv4/IPv6 address or a hostname to identify ATN | |

|applications. | |

|Use of the IANA registered port numbers for CM, CPDLC, FIS and ADS. |OK |

|The “Quality of Services” requested by the DS-User is provided using the DS field, as specified in [4] DiffServ RFC 2474. |OK |

|Implement the communication protocol specified for ATN-IPS Dialogue Service: |OK |

|use the specified ATNPKT as transport level user data for the protocol exchanges between the peer DS-Providers | |

|apply the mapping specified for the DS primitives and parameters. | |

|Fulfilment of the high level requirements while acting over a connection-oriented transport protocol: |OK |

|connection-oriented service as specified in [3], SARPS chapter 4.2: D-START, D-DATA, D-END, D-ABORT, D-P-ABORT. | |

|implement the finite state machine for Dialogue Service over TCP. | |

|Use of multiple dialogues between the same peer applications over TCP |OK |

|Fulfilment of the high level requirements while acting over a connectionless transport protocol |OK |

|connection-oriented service as specified in [3], SARPS chapter 4.2: D-START, D-DATA, D-END, D-ABORT, D-P-ABORT. | |

|connectionless service as specified in [3], SARPS chapter 4.7: D-UNIT-DATA. | |

|implement the finite state machine for Dialogue Service over UDP. | |

|Use of multiple dialogues between the same peer applications over UDP |OK |

|Implement reliability mechanisms to provide connection-oriented DS over UDP: |OK |

|pseudo connection over UDP | |

|detect the loss or duplication of UDP datagrams using one-to-one acknowledge | |

|detect long lived unpaired connections | |

|handle UDP datagrams truncation | |

3

Mobility scenarios

|Mobility scenario |Status |

|Aircraft mono ACSP, mono ANSP flight, no mobility |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1). | |

|Context: | |

|MIPv6 connectivity provided by ACSP2, | |

|tested over TCP and UDP, | |

|no mobility. | |

|Aircraft mono ACSP, mono ANSP flight, no mobility |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1). | |

|Context: | |

|PMIPv6 connectivity provided by ACSP1, | |

|tested over TCP and UDP, | |

|no mobility. | |

|Aircraft mono ACSP, multi ANSP flight, no mobility |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1) | |

|Step 2) Transfer of communication from ATC1 to ATC2 | |

|Step 3) CPDLC exchanges between the aircraft and ATC2 (ANSP2) | |

|Context: | |

|MIPv6 connectivity provided by ACSP2, | |

|tested over TCP and UDP, | |

|no mobility. | |

|Aircraft mono ACSP, multi ANSP flight, no mobility |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1) | |

|Step 2) Transfer of communication from ATC1 to ATC2 | |

|Step 3) CPDLC exchanges between the aircraft and ATC2 (ANSP2) | |

|Context: | |

|PMIPv6 connectivity provided by ACSP1, | |

|tested over TCP and UDP, | |

|no mobility. | |

|Aircraft Mono ACSP, mono ANSP flight, mobility PMIPv6(PMIPv6 |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1) | |

|Context: | |

|PMIPv6 connectivity provided by ACSP1, | |

|tested over TCP and UDP, | |

|mobility intra-ACSP : PMIPv6(PMIPv6. | |

|Aircraft mono ACSP, mono ANSP flight, mobility MIPv6(MIPv6 |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1) | |

|Context: | |

|MIPv6 connectivity provided by ACSP2, | |

|tested over TCP and UDP, | |

|mobility intra-ACSP : MIPv6(MIPv6. | |

|Aircraft mono ACSP, multi ANSP flight, mobility MIPv6(MIPv6 |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1) | |

|Step 2) Transfer of communication from ATC1 to ATC2 | |

|Step 3) CPDLC exchanges between the aircraft and ATC2 (ANSP2) | |

|Context: | |

|MIPv6 connectivity provided by ACSP2, | |

|tested over TCP and UDP, | |

|mobility intra-ACSP during transfer : MIPv6(MIPv6. | |

|Aircraft mono ACSP, multi ANSP flight, mobility PMIPv6(PMIPv6 |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1) | |

|Step 2) Transfer of communication from ATC1 to ATC2 | |

|Step 3) CPDLC exchanges between the aircraft and ATC2 (ANSP2) | |

|Context: | |

|PMIPv6 connectivity provided by ACSP1, | |

|tested over TCP and UDP, | |

|mobility intra-ACSP during transfer : PMIPv6(PMIPv6. | |

|Aircraft multi ACSP, mono ANSP flight, mobility MIPv6(MIPv6 |OK |

|Step 1) CM logon + CPDLC exchanges between the aircraft and ATC1 (ANSP1) | |

|Context: | |

|initial MIPv6 connectivity provided by ACSP2, | |

|tested over TCP and UDP, | |

|mobility inter-ACSP : MIPv6(ACSP2)(MIPv6(ACSP1). | |

|Mobility PMIPv6(MIPv6 |N/A |

|Mobility MIPv6(PMIPv6 |N/A |

4

Protocol analysis

This section provides some details about the protocol exchanges (IPv6, MIPv6, PMIPv6) observed during the mobility tests performed on the ATN/IPS platform.

[pic]

[pic]

[pic]

[pic]

[pic]

MIPv6 network callflow

[pic]

MIPv6 ATN callflow

[pic]

MIPv6 network route optimisation callflow

[pic]

PMIPv6 network callflow

[pic]

PMIPv6 ATN callflow

Estimation of the air/ground traffic load (in bytes):

|TCP based |PMIPv6 |MIPv6 |

|TCP connection cost |102 + 102 + 94 = 298 |134+134+126 = 394 |

|(SYN + SYN_ACK + ACK) | | |

|TCP keepalive cost |94 |126 |

|ATNPKT of length X |94 + X |126 + X |

|ATNPKT keepalive |94 + 3 = 97 |126 + 3 = 129 |

|PPP LCP Echo Req+Rep |60 + 30 = 90 |0 |

|MIPv6 Binding Update and Ack |0 |110 + 94 = 204 |

|UDP based |PMIPv6 |MIPv6 |

|ATNPKT of length X |70 + X |102 + X |

|ATNPKT keepalive |70 + 5 = 75 |102 + 5 = 107 |

|PPP LCP Echo Req+Rep |60 + 30 = 90 |0 |

|MIPv6 Binding Update and Ack |0 |110 + 94 = 204 |

Let’s assume these settings were chosen:

• No TCP keepalive is used

• TCP connection triple handshake is sent once for all at dialogue start, and so is not accounted for here (394 bytes once is to be neglected)

• In TCP mode, ATNPKT keepalive is fired every 80s (240s inactivity / 3 probes)

• In UDP mode, ATNPKT keepalive is fired every 80s (240s inactivity / 3 probes)

• MIPv6 binding update/acks are sent every hour, and so are not accounted for here (204 bytes in 3600 seconds is to be neglected)

• PMIPv6 PPP LCP Echos are sent every 5s, to keep the PPP connection established (giving a maximum 15s period to detect PPP connection break)

• ATNPKT frequency is so low that TCP window algorithm is not used (i.e. One ATNPKT per TCP packet)

This gives an approximation for FREQ ATNPKTs of length N (N is the ATNPKT payload) sent per second of:

• TCP / UDP general formula:

bandwidth = keepalive_bandwidth + ATNPKT_bandwidth

bandwidth = keepalive_size / 80 + (ATNPKT_size + ACK size) * FREQ

• TCP over PMIPv6 : bandwidth = 90 / 5 + 97 / 80 + (94 + N + 94) * FREQ

• TCP over MIPv6 : bandwidth = 135 / 80 + (126 + N + 126) * FREQ

• UDP over PMIPv6 : bandwidth = 90/5 + 75 / 80 + (70 + N + 76) * FREQ

• UDP over MIPv6 : bandwidth = 107 / 80 + (102 + N + 108) * FREQ

[pic]

5

Dialogue Service validation scenario

The following test-case is extracted from the ATN/IPS software test plan; it is provided as example of validation scenario run in interactive mode.

|Object |Simulates a transfer of communication between ATC in interactive mode. |

|Identification |LOT2_020 |

|Test Pre-requisites |dslu and dslp stopped |

| |port numbers and hostnames configured on butterfly, cameleon and tiger |

|Configuration |Aircraft 1 ( CM / CPDLC applications (dslu + dslp) |

| |ANSP1 ATC ( CM / CPDLC applications (dslu + dslp) |

| |ANSP2 ATC ( CM / CPDLC applications (dslu + dslp) |

|Requirements |REQ 18, REQ 19 |

|Action |Result |

|Check that the DS port num are correctly configured on butterfly, cameleon and tiger: | |

|1) they might be either defined in /etc/services : | |

|ds-provider 5909/tcp | |

|cm 5910/udp | |

|cm 5910/tcp | |

|cpdlc 5911/udp | |

|cpdlc 5911/tcp | |

|2) or configured through environment variables : | |

|export DSLI_PORT=5909 | |

|export CM_UDP_PORT=5910 | |

|export CM_TCP_PORT=5910 | |

|export CPDLC_UDP_PORT=5911 | |

|export CPDLC_TCP_PORT=5911 | |

|3) additionally, butterfly, cameleon and tiger shall be defined as aliases in /etc/hosts. | |

|Start the tester and the DS-Provider on the 3 hosts: |dslp started in background|

|dslp –6 –f 0x20 –f 0x10 –f 0x11 –f 0x12 & |mode |

|export DSL_TRACE=3 | |

|dslu |dslu ready to receive |

|(Note that the User’s Manual will describe the use of dslu and dslp( invocation parameters, environment variables, |commands |

|log management, command tree, …). | |

|Enter the following commands on butterfly, cameleon and tiger: |Registration id obtained: |

|(do not enter the lines starting with a semi-colon ; they just intent to give explanations) |CM ( 1 |

|; set receive timeout to 300 seconds |CPDLC ( 2 |

|delay 300000 | |

| | |

|; DS-API initialisation | |

|dsli send api_start | |

| | |

|; register CM and CPDLC over TCP | |

|dsli send reg_req 1 2 | |

|dsli send reg_req 2 2 | |

|Enter the following commands on butterfly (aircraft): |Initiating Dialogue |

|; Initiate CM Logon request to ACT1 |with ATC1 |

|per encode cm logon_req |(AIR, CM, id=1) |

|cm send logon_req 1 called 5910 cameleon calling 5910 localhost 1 1 0 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on cameleon (ATC1): |Accepting Dialogue |

|; Expect the CM Logon indication from the aircraft |with aircraft |

|cm receive logon_ind |(ATC1, CM, id=1) |

| | |

|; Send the CM Logon positive response to the aircraft | |

|per encode cm logon_rsp | |

|cm send logon_rsp 1 1 ? 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: | |

|; Expect the CM Logon confirm from ATC1 | |

|cm receive logon_cnf | |

|Enter the following commands on cameleon: |Initiating Dialogue |

|; Send the CPDLC Start request to the aircraft |with aircraft |

|per encode cpdlc start_req um 227 |(ATC1, CPDLC, id=2) |

|cpdlc send start_req 2 called 5911 butterfly calling 5911 localhost 1 0 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: |Accepting Dialogue |

|; Expect the CPDLC Start indication from ATC1 |with ATC1 |

|cpdlc receive start_ind |(AIR, CPDLC, id=2) |

| | |

|; Send the CPDLC Start positive response to ATC1 | |

|per encode cpdlc start_rsp dm 100 | |

|cpdlc send start_rsp 2 2 ? 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on cameleon: | |

|; Expect the CPDLC Start confirm from the aircraft | |

|cpdlc receive start_cnf dm | |

| | |

|; Send CPDLC Message (UM 169) to the aircraft | |

|per encode cpdlc message um 169 ‘freetext’ | |

|cpdlc send message 2 2 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: | |

|; Expect the CPDLC Message (UM 169) from ATC1 | |

|cpdlc receive message um | |

| | |

|; Send CPDLC Message (DM 0 WILCO) to ATC1 | |

|per encode cpdlc message dm 0 | |

|cpdlc send message 2 2 | |

|dsli receive ok_cnf | |

|Enter the following commands on cameleon: |Initiating Dialogue |

|; Expect the CPDLC Message (DM 0) from the aircraft |with aircraft |

|cpdlc receive message dm |(ATC1, CM, id=3) |

| | |

|; Send CM Contact request to the aircraft | |

|per encode cm contact | |

|cm send contact_req 2 called 5910 butterfly calling 5910 localhost 1 0 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: |Accepting Dialogue |

|; Expect the CM Contact Indication from ATC1 |with ATC1 |

|cm receive contact_ind |(AIR, CM, id=3) |

| | |

|; Send CPDLC Start Request to ATC2 |Initiating Dialogue |

|per encode cpdlc start_req dm 100 |With ATC2 |

|cpdlc send start_req 2 called 5911 tiger calling 5911 localhost 1 0 0 |(AIR, CPDLC, id=4) |

|dsli receive ok_cnf | |

|Enter the following commands on tiger (ATC2): |Accepting Dialogue |

|; Expect the CPDLC Start indication from the aircraft |with aircraft |

|cpdlc receive start_ind |(ATC2, CPDLC, id=1) |

| | |

|; Send the CPDLC Start positive response to ATC1 | |

|per encode cpdlc start_rsp um 227 | |

|cpdlc send start_rsp 2 1 ? 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: | |

|; Expect the CPDLC Start confirm from ATC2 | |

|cpdlc receive start_cnf | |

| | |

|; Send the CPDLC Contact positive response to ATC1 | |

|per encode cm contact_rsp | |

|cm send contact_rsp 1 3 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on Cameleon: | |

|; Expect the CM Contact confirm from the aircraft | |

|cm receive contact_cnf | |

| | |

|; Send the CPDLC End request to the aircraft | |

|per encode cpdlc end_req um 227 | |

|cpdlc send end_req 2 2 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: |Dialogue Ended |

|; Expect the CPDLC End indication from ATC1 |with ATC1 |

|cpdlc receive end_ind um |(AIR, CPDLC, id=2) |

| | |

|; Send the CPDLC End positive response to ATC1 | |

|per encode cpdlc end_rsp dm 100 | |

|cpdlc send end_rsp 2 2 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on Cameleon: |Dialogue Ended |

|; Expect the CPDLC End confirm from the aircraft |with aircraft |

|cpdlc receive end_cnf dm |(ATC1, CPDLC, id=2) |

|Enter the following commands on tiger: | |

|; Send the CPDLC Message (UM 183) to the aircraft | |

|per encode cpdlc message um 183 'Prise de controle' | |

|cpdlc send message 2 1 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: | |

|; Expect the CPDLC Message from ATC2 | |

|cpdlc receive message um | |

|Enter the following commands on tiger: |Dialogue Ended |

|; Send the CPDLC Abort request to the aircraft |with aircraft |

|per encode cpdlc abort_req um 3 |(ATC2, CPDLC, id=1) |

|cpdlc send abort_req 2 1 0 | |

|dsli receive ok_cnf | |

|Enter the following commands on butterfly: |Dialogue Ended |

|; Expect the CPDLC Message from ATC2 |with ATC2 |

|cpdlc receive abort_ind um |(AIR, CPDLC, id=4) |

|Note that at this point there still CM dialogues pending between the aircraft and ATC1. |They will be ended either|

| |after keepalive expiration|

| |; or after the CM |

| |unregistration. |

|Enter the following commands on butterfly, cameleon and tiger: | |

|; unregister CM and CPDLC applications | |

|dsli send unreg_req 1 | |

|dsli send unreg_req 2 | |

|dsli send api_stop | |

REFERENCES

References ICAO

[1] IPS Dialogue Service Interface Update

Ref ACP-WG-I-07/WP-9

[2] CM ASN.1 Additions for Support of IP

Ref ACP-WG-I-04/WP-09

[3] Manual of technical provisions for the aeronautical telecommunication network (ATN)

Ref Document 9705, Edition 3

References IETF

[4] RFC 2474 - Definition of the Differentiated Services Field (DS Field)

in the IPv4 and IPv6 Headers.

[5] RFC 3775 - Mobility Support in IPv6

[6] RFC 3963 - Network Mobility (NEMO) Basic Support Protocol

[7] RFC 5213 - Proxy Mobile IPv6

[8] RFC 2516 – A Method for Transmitting PPP Over Ethernet (PPPoE)

LIST OF ABBREVIATIONS

|ACSP |Air Communications Service Provider |

|ACP |Aeronautical Communications Panel |

|ANSP |Air Navigation Service Provider |

|AP |Access Point |

|AR |Access Router |

|ASN.1 |Abstract Syntax Notation One |

|ATC |Air Traffic Control |

|ATN |Aeronautical Telecommunication Network |

|BGP |Border Gateway Protocol |

|CDA |Current Data Authority |

|CM |Context Management |

|CN |Correspondent Node |

|CoA |Care Of Address |

|CPDLC |Controller Pilot Data Link Communication |

|DM |Downlink Message |

|DS |Dialogue Service |

|EATM |European Air Traffic Management |

|FN |Foreign Network |

|HA |Home Agent |

|HN |Home Network |

|HoA |Home Address |

|ICAO |International Civil Aviation Organization |

|ICMPv6 |Internet Control Message Protocol v6 |

|IETF |Internet Engineering Task Force |

|IPv6 |Internet Protocol v6 |

|IPS |Internet Protocol Suite |

|LMA |Local Mobility Anchor |

|MAG |Mobile Access Gateway |

|MIPL |Mobile IPv6 for Linux |

|MIPv6 |Mobile IPv6 |

|MN |Mobile Node |

|MSP |Mobility Service Provider |

|NDA |Next Data Authority |

|NEMO |Network Mobility |

|PADI |PPPoE Active Discovery Initiation |

|PADO |PPPoE Active Discovery Offer |

|PADR |PPPoE Active Discovery Request |

|PADS |PPPoE Active Discovery Session-confirmation |

|PADT |PPPoE Active Discovery Termination |

|OSI |Open Systems Interconnection |

|PMIPv6 |Proxy Mobile IPv6 |

|PPP |Point-to-point Protocol |

|PPP PAP |PPP Password Authentication Protocol |

|PPP LCP |PPP Link Control Protocol |

|PPPoE |Point-to-point Protocol over Ethernet |

|SARPS |Standards and Recommended Practices |

|SSID |Service Set Identifier |

|TCP |Transmission Control Protocol |

|UDP |User Datagram Protocol |

|UM |Uplink Message |

|WAP |Wireless Access Point |

|WGI |Working Group Internet |

|WLAN |Wireless Local Area Network |

-----------------------

[1] A technical proposal termed Global HA-HA is being considered by the IETF experts allowing a distribution of HomeAgents throughout the internet. Use of experimental code was not part of these EUROCONTROL trials.

[2] This mobility is between two MAGs of the same PMIP domain not between MAGs belonging to distinct PMIP domains (see section

4.2).

- 2 -

).

-----------------------

dsli

DS-User

DS-Provider

dslp

Dialogue Service Provider

DS-User

DS-Provider

dsli

Airborne CM/CPDLC application

Ground CM/CPDLC application

ATN-IPS

IPv6 Network

ATN-IPS Dialogue Service

over TCP / UDP

dslu

CM Logon received from AIRCRAFT

CPDLC DM6 received from AIRCRAFT

Send CPDLC UM127 to AIRCRAFT

…

dslu

Send CM Logon to ATC1

Send CPDLC DM6 to ATC1

CPDLC UM127 received from ATC1

…

(1) LOGON of

1

6

CDA)

becomes

(LFBO

connection

CPDLC

Current

(6)

5

closed

is

CPDLC

Previous

(5)

connection

(4) CPDLC

4

3a

3b

2

NDA)

becomes

(LFBO

aircraft

] to

Frequency

(3b) CONTACT LFBO [

CM / CPDLC: Transfer of communication

LFBO

LFPO

becomes

(LFPO

connection

(2) CPDLC

(3a) Synchronisation between ground ATC centres

aircraft

establishment[pic]qrstuv¢°±ÛÜâãäçèé ? @ A B C D F G H I J r ÷ó÷ë÷óÑŶ¬¢¬¢˜¬’¢„¢„

establishment (passive)

CDA).

active

becomes

Stable ground BGP4 routing (ANSP Domain)

e.g. EUROCONTROL prefix 2001:4B50::/32

Mobility Service Provision (ACSP Domain)

Location of HAs and assignment of Home Addresses for aircraft

Aircraft HoA

(MIPv6 Host of NEMO Mobile router)

MSP /32 annoucement(s) via ground BGP

ANSP ground BGP prefix announcement or aggregate

No routing, only IPv6 and MIPv6 exchanges to build CoA and BUs

G

R

O

U

N

D

A

I

R

dslp

Dialogue Service Provide

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download