Re: Extending a /64

[Tony Whyman <[e-mail]>]

On 17/11/2020 15:48, David Farmer wrote:
>
>
> On Tue, Nov 17, 2020 at 3:44 AM Tony Whyman 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 17/11/2020 02:55, David Farmer wrote:
>     > ou mention that airplanes can fall out of the sky, it would be
>     really
>     > bad if an airplane every fell out of the sky, or collided with
>     another
>     > airplane, because of an address conflict.
>
>     I should probably make it clear that irrespective of whatever
>     addressing
>     plan we come up with - this will never happen. There is strength in
>     depth in the system.
>
> I don't actually think something as simple as an address conflict 
> would ever be the primary cause of an aircraft incident. However, it 
> is not that difficult to conceive of situations where such an address 
> conflict, causing a communication failure, could be a contributory 
> cause to an incident. If you combined a communications outage with 
> multiple other human or systems failures it is difficult to exclude 
> the possibility of such an issue being a contributory cause of an 
> incident. So, it would seem inappropriate to have an addressing scheme 
> like ULA were the possibility, however small, of an address conflict 
> is part of normal operation.
>
>
David,

This is an interesting subject and covered at length in the Safety and 
Performance Requirements (SPR) for ATN Baseline 2. This is a joint 
RTCA/Eurocae document (ref DO-350A/ED228A). The SPR is intended to be a 
complete hazard analysis for all the ATS Applications in order to 
identify the Safety Objectives and to allocate them to various 
functions. All Safety Objectives have to be satisfied in order to gain 
Safety Approval for operational use.

The Safety Objective for the Network itself is expressed as an 
availability requirement and a confidence level to which it must be 
shown that the availability requirement is met. The end-to-end 
availability requirement for the current generation of ATS Applications 
is that in high density airspace (lots of aircraft) there has to be a 
99.9% probability that a message is delivered to its intended recipient 
and the response returned, without loss of integrity and within the 
required transaction time and per Flight Hour.

Using the wrong network address will result in mis-delivery, a discarded 
packet and is one of the many possible reasons that can result in a 
failure to meet the availability requirement.

The confidence level at present is required to be appropriate for what 
is known as a Severity Class 4 hazard. This is defined as a hazard which 
if realised implies:

“A slight reduction in separation or slight reduction in air traffic 
control capability. Significant increase in air traffic controller 
workload. There may also be a Slight Increase in workload for the flight 
crew resulting from having to perform tasks that may have otherwise been 
automated."

You translate that as "if the data comms goes down, the airspace has to 
be re-configured to reflect the lower airspace capacity due to having to 
revert to using voice comms only" i.e. aircraft have to fly around 
circles, stay or the ground or get diverted until ATC is ready to cope 
with them. Generally, this does not take that long and it is something 
they train for. You don't want it to happen too often given the 
resulting flight delays, but these kind of problems should not result a 
serious incident.

In order to demonstrate that an SC4 hazard has been mitigated to the 
required confidence level, you need to demonstrate that the acceptable 
risk that the availability target has not been met is less than 1 in 
10^-3. This is just about feasible with black box testing, but still 
takes a lot of effort. Its also why mainstream COTS network nodes are so 
important a resource given that "in service experience" can get you a 
long way to demonstrating correct operation.

When it comes to ensuring that you are using the correct Network 
Address, as you would expect, this part of the system is subject to 
considerable analysis, testing and audit given the SC4 hazard level. At 
present, two independent proofs (that you have the correct network 
address for a given Flight) are required. One is provided by the 
aircraft when it reports its Flight Identifier/Network Address binding 
and the other is in the Flight Plan provided separately by the airline's 
Flight Despatcher.

At the core of the ATC Centre's Flight Data Processor is a function that 
brings this all together and validates the identity of an aircraft. This 
a key safety function and is subject to considerable analysis and 
testing. And long term testing is required to demonstrate the necessary 
confidence level.

This is also why, in the migration to the ATN/IPS, no one wants to 
propose any semantic change to the addressing plan that would force a 
revision of this function. The IPv6 address of an application on board 
an aircraft has to be canonical with the existing NSAP Address if we are 
to avoid any change.

Those arguing for a "better" addressing plan really do not appreciate 
how saving a few bits could result in years of delay in introducing the 
ATN/IPS. This is not just a consequence of the time it takes to test out 
such a function, but if you look at any ATC Centre's system development 
plan, they will have mapped out a plan for a whole sequence of 
improvements, and if you want a change to any function, you have to slot 
in to the current development plan - they might not even start work on 
this for a few years.

The next generation of applications will probably require a higher 
confidence level appropriate for Severity Class 3. How to achieve this 
with COTS networks is an active research area for myself and is taking 
me down the path of having more than one end-to-end independent (no 
common failure modes) internetwork between aircraft and the ATC Centre. 
But that is another story.

Regards

Tony