Subject: [MEXT] Comments on [WGLC] draft-ietf-mext-aero-reqs-01

From: Tony Whyman <[email-masked]>
Date: Tue, 11 Mar 2008 10:46:07 +0000

Firstly apologies for submitting comments on this draft a day after the 
deadline. However, a copy of the draft was only passed to me yesterday 
and I have only joined the list today in order to make a few comments:

1. Section 2.1 "Aeronautical Communications Scenarios" does not include 
what I believe is an important characteristic of ATS Communications. 
That is communication is not between an aircraft and an ATC Centre. It 
is instead between a Flight and an ATC Centre. For example, Flight BA 
108 may be flown by aircraft G-YMMJ on on one day and aircraft G-YMMK on 
the next. In principle, ATC does not know or care (other than whether 
its a "heavy" or not) which aircraft is used for a given flight. On the 
other hand, data link communications address the physical platform i.e. 
the aircraft.

Thus before data communication can take place, there has to be a binding 
between the Callsign (Flight Identifier), the physical aircraft making 
the Flight and any IP Address assigned to that aircraft, whether it is 
static or dynamic. That binding lasts only for the duration of the 
Flight and is then discarded. Only once that binding has been made can 
ATC contact the Flight.

This is an important consideration, because an ATS ground system cannot 
have meaningful communications with an aircraft without access to such 
information. A Mobility Solution that is  concerned with communications 
with a mobile node identified by an IP Address alone is only part of the 
solution.

2. Section 2.1.2 mentions aircraft to aircraft communications. This 
requirement needs to be treated carefully as the only requirements I 
know of in this area involve line of sight communications and are 
broadcast in nature. For example, aircraft may broadcast out their 4D 
position so that other aircraft in the same airspace can build up a real 
time airspace picture and present this to the pilot, perform collision 
avoidance, etc.

I do not believe that there is a general requirement for 
aircraft-aircraft communications other than in the context of a single 
broadcast wireless network.

3. Section 3.4 on availability talks of "high availability" but does not 
quantify what this means. In European Airspace, the current requirement 
for data link communications availability may be found here:

http://www.eurocontrol.int/link2000/gallery/content/public/files/documents/Generic%20ACSP%20Reqt%20v1.3.pdf

This specifies an availability requirement of 99.99% in the so called 
"Post Pioneer Phase " (i.e. full operations) for the air/ground 
communications service. But note that this requirement comes with the 
caveat that data link is the secondary means of communication and hence 
loss of communications is not treated as a safety issue.

I know that some safety experts would like to review this anyway, but, 
perhaps more important,  some time in the not too distant future (~2020) 
data link is expected to become the primary means of communication in 
some airspaces. I have tried to compute the impact of this by following 
through the same process and came up with a figure of 99.99995% 
availability for the air/ground communications service. I would 
emphasise that this is not an official figure and needs to be verified 
by Safety Experts before anyone should even think of quoting it, and 
there may also be means by which we can reduce it that I have not 
considered. On the other hand, it does illustrate the kind of figures 
that ATS high availability implies. 99.99% is the current target and it 
will only get more stringent.

In this context, the statement by the draft "An RO mechanism MUST NOT 
add any new single point of failure for communications in general" needs 
to be questioned, and I would recommend "An RO mechanism MUST NOT 
include any single point of failure for communications".

For such reasons, I do not believe that there can be any special points 
in a network supporting ATS Communications.

3. Section 3.8 "Security": Generally most security threats can be deal 
with effectively on an end-to-end basis and this is usually the 
preferred approach as it avoids reliance on third parties. However, 
Denial of Service threats are a serious issue and should be the focus of 
this section in respect of ATS Communications. Any mobility solution for 
ATS Communications must be carefully analysed with respect to its 
vulnerability to Denial of Service Attacks, and appropriate 
countermeasures provided.

4. An important Institutional Requirement/Issue does not seem to have 
made it into the requirements list.  This has arisen in the context of 
analysis of Mobile IP specifically, and the use of a Home Agent, and is 
to do with regulatory approval of the Home Agent.

While ATS data link is a secondary means of communications, it is still 
possible to argue that air/ground communications service providers do 
not have to meet the same standards as do an Air Traffic Control Centre 
or an Aircraft. However, that situation is changing and by the time data 
link is primary, it should be expected that air/ground communications 
service providers will have to be subject to regulatory approval (and 
audit) in order to show that they meet the safety and performance 
requirements for a given airspace.

However, while the ATC Authority and Air/Ground Communications Service 
Provider can typically be subject to the same regulator, this is not 
necessarily true of a Home Agent, and this has given rise to what is 
perhaps unfairly known as the "Liberian Home Agent Problem". However 
unfair the title may be, it does illustrate the simple fact that you 
cannot have a flag of convenience where ATS safety is concerned.

As soon as you bring any Home Agent, or indeed any special point into a 
network, you introduce the regulatory problem of:

* Who regulates it?
* How is a consistent level of regulation and approval enforced worldwide?
* How do you deal with different Safety and Performance requirements 
that naturally derive from the fact that each airspace (e.g. Oceanic, 
European Continental, etc.)  is potentially different.

Even if you can develop a worldwide trust framework for the operational 
approval of Home Agents, you still have either to demand that all meet 
the same (the most stringent) Safety and Performance Requirements or you 
have to have a means of dynamically determining the approvals level of 
an aircraft's Home Agent before accepting it for ATS data Link 
communications. While the former is simpler to manage, what happens if 
the bar needs to be raised and more stringent Safety and Performance 
Requirements introduced? Worldwide flag days are probably not the best idea.

Assuming that the regulatory issues can be overcome, if a NEMO RO 
solution involves anything like a Home Agent in the process then there 
has to be a mechanism where the ATC Centre can recognise that this is 
being used and dynamically determine its approvals level.

5. In section 2.1.1 it is stated "In fact, since these devices are 
accessed by skilled technicians and professionals, it may be acceptable 
even if complex configuration is required for NEMO RO."

As avionics is typically subject to DO178B Level C Software Development 
requirements, I would have said that anything complex is a bad idea.

Regards

Tony Whyman

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 11 Mar 2008 09:16:05 -0500

>and I have only joined the list today in order to make a few comments:

Thanks for your comments!

>what I believe is an important characteristic of ATS Communications. 

Yes, we can add some text in this section that clarifies this, though
I know it is an issue for IP-based communications with aircraft in-general,
it probably doesn't bear on selection of individual RO techniques, which
is why it had been glossed over.

>2. Section 2.1.2 mentions aircraft to aircraft communications. ...
>

Right; do you suggest that we need a bit more text to explain this?  I've
tried to avoid some of the complication of the aero world when in the
specific context of looking at viable RO solutions, it doesn't have direct
bearing.  That's why the description is simplified from reality.

>quantify what this means. ...
>

That wording change seems okay to me.  It's what we were trying to get
at anyways.  It should be noted that one reason for pursuing RO is to
not rely on HA infrastructure except for an initial packet exchange.

>countermeasures provided.

Of course; we could add a little text to clarify this.  In the IETF, it
is somewhat of a given that any technology will be closely evaluated for
potential for DoS and that each layer has its own security considerations,
so we focused here only on the security requirements specific to NEMO RO.

> ...

It is truly an issue, but one for use of MIP in general, and not for
selecting between RO technologies, I believe.  For instance, it does
not really help us to select amongst various RO solutions as it affects
them all equally.  I believe it is a problem for ICAO and the regulatory
bodies in deciding how they want to operate IP networks, but that it
doesn't affect the technology itself.  There are certainly ways to setup
the operational network that avoid this by controlling the delegation of
addresses.

>requirements, I would have said that anything complex is a bad idea.

I think we should alter this text, as it is easy to misread.  Since you
mention DO-178B, it seems that the text suggested software development
or properties of the software itself, which is not what we meant.  We
were just trying to say that it's okay if it's not plug-and-play and
requires input of some configuration parameters.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Tony Whyman <[email-masked]>
Date: Tue, 11 Mar 2008 15:48:59 +0000

Wesley,

Thanks for your quick response

> is why it had been glossed over.
I believe that this requirement does affect the choice of RO approach. 
The problem is that unless you understand the Operational Scenario, and 
evaluate against it, you are unlikely to choose the correct solution. 
For ATS, you need to consider the following cases:

1. Initial Data Link Logon with a controlling ATSU
2. Transfer of Communications from the controlling ATSU to  the next ATSU
3. Aircraft contact with a non-controlling ATSU
4. A non-controlling ATSU contacting an aircraft
5. Aircraft movement from one air/ground network to another
6. Concurrent use of multiple air/ground networks by an aircraft.

Any RO solution has to be evaluated in the context of each of these 
scenarios, in order to determine its appropriateness.

(1) and (3) are relatively easy as the aircraft can just do a DNS lookup 
on the ATSU. It can then tell the ATSU its Flight identifier and the 
dynamic binding can be made.

(2) is also straightforward as the transfer is driven by the controlling 
ATSU which can tell the next ATSU about the Flight Identifier to 
aircraft binding, or just instruct the aircraft to contact the next ATSU 
- which then becomes the controlling ATSU.

(4) is much more tricky as a non-controlling ATSU does not necessarily 
have any means to know the Flight Identifier/Aircraft binding. It has to 
find this out from the controlling ATSU, which probably has to perform 
some sort of ground distribution of the information. In Europe, this is 
currently done using the OLDI network, and the Logon Forward (LOF) message.

(5) and (6) are always aircraft driven as it is the aircraft that knows 
about its air/ground connectivity.

Now, what you also infer from the above, is that there is no requirement 
for ATS communication before an aircraft has contacted the first 
controlling ATSU en route. The controlling ATSU is also the entity that 
keeps track of the dynamic binding between the Flight, the aircraft and 
its IP Address(es). If (5) and (6) are not required then there is no 
requirement for extra mobility functionality beyond normal IP networking.

Assuming that (5) and (6) are required, then what is required by any RO 
solution is to support (5) and (6) within the context of (1) to (4). 
There is no requirement for an aircraft to be generally available on a 
well known IP address. The requirement is that once the controlling ATSU 
has learnt the current Flight Identifier/Aircraft/IP Address binding, 
changes to the aircraft's network connectivity, which could include 
changes to its IP Address, are communicated in the simplest and most 
efficient manner to the controlling ATSU.
> bearing.  That's why the description is simplified from reality.

I think really what I was trying to say is that there is no need I know 
of to complicate the RO solution by including aircraft to aircraft 
communications. My recommendation is to explicitly rule out 
aircraft-to-aircraft comms support as a requirement for the RO solution.

<snip/>
> the operational network that avoid this by controlling the delegation of
On the other hand, if you have two RO approaches, one that depends on a 
Home Agent and the other that has no Home Agent involved, then surely 
this issue gives a strong preference to the latter.

Unless you assume that all possible solutions include a Home Agent, or 
alternatively, do not include a Home Agent, then isn't this a valid 
criteria on which to select an RO solution?
> requires input of some configuration parameters.
Well, where I come from, complex configuration files are read by 
software, which has then to be subject to many detailed test cases 
before you can say with any degree of confidence that it works. And 
that's assuming that "rubbish-in rubbish-out" does not apply, as even 
clever people can screw up complex configurations. Where safety is a 
major requirements, my view is always keep it simple. The statement I 
was referring to is best removed.

Regards

Tony Whyman