Subject: [MEXT] Thoughts on the different nemo ro approaches

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 19:01:44 +0200

Hi,

I have been reading the drafts people have submitted for the nemo ro 
work for the aviation case.
In particular, i have read

draft-bauer-mext-aero-topology-00
draft-wakikawa-mext-haha-interop2008-00
draft-wakikawa-mext-cr-consideration-00
draft-wakikawa-nemo-orc-01
draft-thubert-mext-global-haha-00
draft-bernardos-mext-nemo-ro-cr-00

Essentially we have two different approaches, one based on distributed 
HAs and another one based on the concept of the correspondent router.
It seems to me that the CR based approach is more complex than the ha 
based approach, so i guess that a first legitimate question to ask is 
where does the complexity springs from?
One observation that i would like to contrast with the group is that the 
HA based approach makes the following fundamental assumption: A set of 
globally distributed anchor points that are within the _same_ 
administrative domain are available and are enough to provide the RO 
capabilities required.

OTOH, the CR based approach makes a different assumption, which is that 
a set of distributed anchor points with which is possible to have a 
trust relationship are available and are enough to provide the RO 
capabilties required.

The difference as i understand it, is that the HA based approach assumes 
that the anchor points are in the same admin domain (or that they are 
within domains with strong admin relationship, which allows them to do 
functions that are usually not acceptable across domains) and the CR 
based approach does not makes that assumption.

By assuming that these anchor points are in the same admin domain, the 
HA based approach can take advantage of the following functions that are 
not available across domains (i may be missing some function):
- anycast routing
- host/MNP route injection to sink traffic for the proper anchor point.
- strong state synchronization between HAs/anchor points

The usage of these tools indeed make life easier, but they impose some 
constraints.
I think that we need to understand these constraints, and figure out 
whether they are acceptable for the aviation community. In other words, 
i think that a relevant exercise at this point is to try to figure out 
how a HA based approach can be deployed within the aviation scenario 
described in draft-bauer-mext-aero-topology-00

So, let's consider how this could be deployed.

A first deployment scenario would be that the HAs are deployed within a 
gACSP. This seems like the perfect match. The gACSP has global 
infrastructure, so it can be assumed to have HAs distributed along the 
globe and they can provide reasonable good enough rute optimization. So, 
if an aricraft is using the gACSP all the way, this seems to work 
reasonably. A first question may be posed though in this scenario about 
addressing. From which prefix the MNP is extracted from? I mean, one 
option is that the gACSP has a prefix for this, and uses it to assign to 
all the different companies that it serves. However, this would result 
in a form of provider dependent addressing and maybe the problems of 
provider dependent addressing would rise here.  In other words, is it ok 
for the aviation companies to use a prefix that is owned by the gASCP? 
This basically means that if they want to change the provider (i don't 
know if this is possible), they will need to renumber.
A related question to this one, about what is the normal relation 
between the aviation company and the gASCP? Is it normal that a given 
aviation company works with one or both the gACSP that exists? If they 
work with one, the provide lock in effect could be an issue. If they 
work with two, then would this approach implies that they need to have 
two prefixes, one for each gACSP? That would probably be problematic 
from the network management perspective. In both cases, either if they 
decide to use two prefixes, or they use a single gACSP with only one 
prefix, the next question is whether they can acquire a CoA from the 
other gACSP? if they can, it is possible that the gACSP performs cold 
potato routing and the RO benefits are not achieved.
The other option of course is that the aviation companies have a 
provider indepedent prefix and that the gACSP announces it on behalf of 
their clients. In this case both gACSP can announce the client prefix. 
The potential issue here is what is the impact for the global routing 
table of such practice.

A second scenario is where other than gASCP are considered.
At this point, i don't even grasp how the scenarios are. For instance, 
is it possible that some airlines do not have any relationship with any 
of the two gASCP? In that case, they only have contracts with smaller 
providers and in that case i this not clear to me how the ha 
infrastructure can be deployed. I mean, would this imply that each of 
the smaller players will have a HA and they would run HAHA protocol 
between them? I don't know if the implications of these are acceptable 
for the relationship that those players have.

One particular case where this is significant is when the communication 
with the gACSP is down for whatever reason. If this is the case, and the 
HA infrastrucutre is not reachable, the direct communication between the 
aircraft and the CNs that are directly attached to the same ACSP is not 
possible, even if they have direct connectivity. I am not sure if this 
is acceptable.

So, imho, what needs to be understood a bit more in depth is the 
possible deployment models of a HA based approach in the aviation 
reality. I am hoping that we can have this discussion in dublin

Regards, marcelo

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Jul 2008 10:29:00 -0700

Marcelo,

What is the timeframe you are looking for a RO solution
for aeronautical use cases? To my understanding, ATS/AOS
communications require safety-of-flight certified links
and I am not seeing near-term safety-of-flight certified
links with performance characteristics capable of handling
IPv6 let alone the additional signalling required for RO
(at least not in terms of scaling to the anticipated numbers
of aircraft in a multiple access domain).

Asked another way, can the aeronautical use cases be
considered as a near-term driver for a RO solution when
the links may not yet be ready to handle even IPv6?

Thanks - Fred
[email-masked]
  
>-----Original Message-----
>From: marcelo bagnulo braun [mailto:[email-masked]] 
>Sent: Thursday, July 24, 2008 10:02 AM
>To: mext
>Subject: [MEXT] Thoughts on the different nemo ro approaches
>
>Hi,
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 19:37:47 +0200

Hi Fred,

thanks for the input

according to draft-bauer-mext-aero-topology-00

   Meanwhile

   ICAO is currently producing an amended version of the manual that

   allows the ATN to be an internetwork based on IPv6 for both ground-

   ground and air-ground communications.  States have already begun

   deployment of the ground portion.  Definition of the mobility support

   for aircraft within this new ATN architecture is underway in the ICAO

   and will form the basis of new ATN manual [icao9896].

I guess you can find similar statements in other places as well.
So it seem that there are some people that think this will be possible 
in the future and now it is good time to design the solution, in order 
to deploy the solution within the required timing

Regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Jul 2008 10:46:01 -0700

Thanks Marcelo,

Nonetheless, link performance characteristics are an important
consideration (e.g., see RFC3819). I tried to raise this at the
mike at one of the past meetings but didn't do a very good job
of it, so it seemed necessary to raise it again here.

Fred

>Sent: Thursday, July 24, 2008 10:38 AM
>To: Templin, Fred L
>Cc: mext
>Subject: Re: [MEXT] Thoughts on the different nemo ro approaches
>
>Hi Fred,
>
>thanks for the input
>

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Thu, 24 Jul 2008 13:04:21 -0500

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Templin, Fred L
>Sent: Thursday, July 24, 2008 1:46 PM
>

I basically agree with Fred, but propose that we make some
simplifying assumptions and move on.

There are actually 2 high-level issues with the datalink layers:

I1 - What form of MAC protocols or techniques will be used?

I2 - What spectrum will be available?

Without capable datalink protocols or available spectrum, the
network won't be worth building.  But without the network, the
datalinks are not worth building.  It is not worth the cost to
develop, certify, and equip new datalinks only to run ISO
protocols over them :), so we must press forward with the
network.

So ... I propose that we assume:

A1 - The datalink protocols and spectrum are being worked on in
     parallel to our efforts on the network.  There are other groups
     chartered to handle this (e.g. ICAO WG-T and WG-F).

A2 - The people working on the datalink will be evaluating it
     specifically as a bearer for IP services.  This is at least
     true of the Future Comm Study, where supporting networking was
     an evaluation criterion.

With regards to A2, we may want to just find the right people and
make sure they're aware of RFC 3819 and any other relevant documents
that would help them make a good decision.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Jul 2008 11:20:48 -0700

Wesley, 

I think we are largely in accord; see below:

>From: Eddy, Wesley M. (GRC-RCN0)[VZ] [mailto:[email-masked]] 
>Sent: Thursday, July 24, 2008 11:04 AM
>To: Templin, Fred L; marcelo bagnulo braun
>Cc: mext
>Subject: RE: [MEXT] Thoughts on the different nemo ro approaches
>

I don't know why we would build new datalinks to support
ISO either. :^} But, just to socialize an aeronautical use
case term the Controller Pilot Data Link Communications 
(CPDLC) protocol will require data links that can support
safety-of-flight while scaling to large numbers of aircraft
within a common signals-in-space coverage region regarless
of the underlying network/transport. 

>that would help them make a good decision.

These are good suggestions, and I support our moving forward
with good faith in link designers. Also, I think these documents
like draft-bauer are a good start at information sharing between
the IETF and ICAO and would like to see more of it. However, my
sense of it is that we may be moving too fast and may not be
engaging enough people within the two communities in a
cross-functional manner.

Thanks - Fred

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 21:10:09 +0200

> engaging enough people within the two communities in a
fully agree
any suggestion how to improve the interaction or any additional document 
would be very appreciated
We could try to go to one of their meeting and make a presentation to 
try to engage more people or even do a joint meeting, if people think 
this would be useful

regards, marcelo

---

From: <[email-masked]>
Date: Fri, 25 Jul 2008 10:03:45 +0200

Hi,

> of the underlying network/transport.
There are already two air-ground access networks in operational use here
in Europe, while additional ones will start to appear because ANSPs have
to in Europe.
CPDLC is already in use, over VDL Mode 2 and OSI protocols.

> engaging enough people within the two communities in a
Wesley has already pointed out that there is a chicken-egg problem here.

Besides this, we (that is DLR) also have people here that are working on
the future data link development, and they are also in ICAO ACP WG-T.

We already have a quiet good information exchange, not just with the
WG-T community but with other people as well (ANSP).

But I do agree that in general IP networking for air-ground
communications has not received the attention it deserves inside the
aviation industry.

Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Jul 2008 08:52:25 -0700

Hi Christian,

>From: [email-masked] [mailto:[email-masked]] 
>Sent: Friday, July 25, 2008 1:04 AM
>To: Templin, Fred L; [email-masked]; [email-masked]
>Cc: [email-masked]

Yes, I know about these. But, I suspect I am in a minority
among the IETF community to which the aviation use cases
are new. Plus, VDL Mode 2 is a fine example of a link
type that does not have performance characteristics that
would accommodate IPv6 or mobility-related signalling.

>Wesley has already pointed out that there is a chicken-egg 

And I already said I support our moving forward with good
faith in link designers. However, that does not mean that
we shouldn't still talk about the links.

>the future data link development, and they are also in ICAO ACP WG-T.

Are they participating in the IETF also?

>communications has not received the attention it deserves inside the

If that is true, then it further strengthens the point I
was making which is that air-ground communications has
not received the attention it deserves *outside* the
aviation industry (e.g., within the IETF).

Thanks - Fred

---

From: "CERASI Eivan" <[email-masked]>
Date: Sun, 27 Jul 2008 14:25:08 +0200

Hi, 

Thanks for this e-mail. I agree that the HAHA approach is less complex.
More importantly, it minimizes changes on the MR which is a key benefit
as we would avoid retro-fit of airborne components.

The application of HAHA concept of foreign/local is a bit confusing for
me, maybe it could be associated to administrative authorities whereby
the local is your default MSP and foreign is an alternative MSP that is
willing to perform some value-added services such as a binding for the
MR.

One of the downsides of HAHA is that the MR is excluded from the RO
decision process and we lose any "RO triger" that we previously
discussed. I also understand that it relies on DHAAD which may induce
protocol overhead over radio links. Just thinking, maybe a route to
investigate is to have some flag within MR packets to address these
issues and allow the MR to play some role.

Eivan
    
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
marcelo bagnulo braun
Sent: Thursday 24 July 2008 19:02
To: mext
Subject: [MEXT] Thoughts on the different nemo ro approaches

Hi,

Regards, marcelo

____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 28 Jul 2008 17:17:02 +0900

Hi Marcelo,

Thanks for summary.

On 2008/07/25, at 2:01, marcelo bagnulo braun wrote:

> Essentially we have two different approaches, one based on  
> distributed HAs and another one based on the concept of the  
> correspondent router.
> It seems to me that the CR based approach is more complex than the  
> ha based approach, so i guess that a first legitimate question to  
> ask is where does the complexity springs from?
> One observation that i would like to contrast with the group is that  
> the HA based approach makes the following fundamental assumption: A  
> set of globally distributed anchor points that are within the _same_  
> OTOH, the CR based approach makes a different assumption, which is  
> that a set of distributed anchor points with which is possible to  
> have a trust relationship are available and are enough to provide  
> the RO capabilties required.
>
> The difference as i understand it, is that the HA based approach  
> assumes that the anchor points are in the same admin domain (or that  
> they are within domains with strong admin relationship, which allows  
> them to do functions that are usually not acceptable across domains)  
> and the CR based approach does not makes that assumption.
>
> By assuming that these anchor points are in the same admin domain,  
> the HA based approach can take advantage of the following functions  
> that are not available across domains (i may be missing some  
> function):
> - anycast routing

what's differences of these two?
IMO, Anycast routing is used to sink traffic for the propose anchor  
point.

> - strong state synchronization between HAs/anchor points

There are several approaches to sync MN's state.
As described in Pascal's ID, there are several approaches how to  
manage MN's state such as on-demand, proactive, even predictive mode.
Airflights' movements can be easily traced and expected, there are  
many ways to optimize this state sync functionality.

> The usage of these tools indeed make life easier, but they impose  
> some constraints.
> whether they are acceptable for the aviation community. In other  
> words, i think that a relevant exercise at this point is to try to  
> figure out how a HA based approach can be deployed within the  
> aviation scenario described in draft-bauer-mext-aero-topology-00
>
> A first deployment scenario would be that the HAs are deployed  
> within a gACSP. This seems like the perfect match. The gACSP has  
> global infrastructure, so it can be assumed to have HAs distributed  
> along the globe and they can provide reasonable good enough rute  
> optimization. So, if an aricraft is using the gACSP all the way,  
> this seems to work reasonably. A first question may be posed though  
> in this scenario about addressing. From which prefix the MNP is  
> extracted from? I mean, one option is that the gACSP has a prefix  
> for this, and uses it to assign to all the different companies that  
> it serves. However, this would result in a form of provider  
> dependent addressing and maybe the problems of provider dependent  
> addressing would rise here.  In other words, is it ok for the  
> aviation companies to use a prefix that is owned by the gASCP? This  
> basically means that if they want to change the provider (i don't  
> between the aviation company and the gASCP? Is it normal that a  
> given aviation company works with one or both the gACSP that exists?  
> If they work with one, the provide lock in effect could be an issue.  
> If they work with two, then would this approach implies that they  
> need to have two prefixes, one for each gACSP? That would probably  
> be problematic from the network management perspective. In both  
> cases, either if they decide to use two prefixes, or they use a  
> single gACSP with only one prefix, the next question is whether they  
> can acquire a CoA from the other gACSP? if they can, it is possible  
> that the gACSP performs cold potato routing and the RO benefits are  
> not achieved.

agree on deploying HAs in gACSP. I also want to know the relationship  
of gASCP, ASCP, ANSP and aviation companies.
Are there any peering points such as IX in aviation networks?

> provider indepedent prefix and that the gACSP announces it on behalf  
> of their clients.
> In this case both gACSP can announce the client prefix. The  
> potential issue here is what is the impact for the global routing  
> table of such practice.

I think this is reasonable approach for aviation case.
do you see any potential issue? We inject HAHA experimental prefix   
from different ISPs(i.e. AS) to BGP. We don't have any issues so far.
> At this point, i don't even grasp how the scenarios are. For  
> instance, is it possible that some airlines do not have any  
> relationship with any of the two gASCP? In that case, they only have  
> contracts with smaller providers and in that case i this not clear  
> to me how the ha infrastructure can be deployed. I mean, would this  
> imply that each of the smaller players will have a HA and they would  
> run HAHA protocol between them? I don't know if the implications of  
> these are acceptable for the relationship that those players have.

It is very important to know WHO will manage HA. I am not sure each  
airline company will operate HA by themselves..

>
> One particular case where this is significant is when the  
> communication with the gACSP is down for whatever reason. If this is  
> the case, and the HA infrastrucutre is not reachable, the direct  
> communication between the aircraft and the CNs that are directly  
> attached to the same ACSP is not possible, even if they have direct  
> connectivity. I am not sure if this is acceptable.

Do we need to discuss this redundancy requirement in this RO discussion?

As I mentioned in the other mails, this is not correct behavior of  
MobileIP/NEMO.
Both protocols rely on HA reliability and requires HA accessibility in  
order to provide mobility support.
That's why we are working on HA reliability protocol (local  
redundancy) and globalHAHA (global redundancy).

BTW, I don't think we should consider the case of gACSP down.
Is this realistic scenarios? If so, shall I return to Japan by sailing!?

regards,
ryuji

---

From: "CERASI Eivan" <[email-masked]>
Date: Tue, 29 Jul 2008 16:06:18 +0200

Just another thought on the subject.

In their own way, both solutions assume that a service provider between
the MR and CN is capable of providing managed value-added services to
perform RO.

This is very different to RO for MIP; I was wondering if it would make
sense to apply the NEMO RO solution as a means to enhance MIP RO. I
recognise it is not really within the charter but it may be an
additional aspect to support solution space and make more universal that
for the aviation sector.

Eivan

> that a set of distributed anchor points with which is possible to have

> a trust relationship are available and are enough to provide the RO 
> capabilties required.
>

> HA based approach can take advantage of the following functions that 
> are not available across domains (i may be missing some
> function):
> - anycast routing

> figure out how a HA based approach can be deployed within the aviation

> scenario described in draft-bauer-mext-aero-topology-00
>
> A first deployment scenario would be that the HAs are deployed within 
> a gACSP. This seems like the perfect match. The gACSP has global 

> globe and they can provide reasonable good enough rute optimization. 
> So, if an aricraft is using the gACSP all the way, this seems to work 
> reasonably. A first question may be posed though in this scenario 
> about addressing. From which prefix the MNP is extracted from? I mean,

> one option is that the gACSP has a prefix for this, and uses it to 
> assign to all the different companies that it serves. However, this 
> would result in a form of provider dependent addressing and maybe the 
> problems of provider dependent addressing would rise here.  In other 
> words, is it ok for the aviation companies to use a prefix that is 
> owned by the gASCP? This basically means that if they want to change 
> the provider (i don't know if this is possible), they will need to 
> renumber.
> aviation company works with one or both the gACSP that exists?
> If they work with two, then would this approach implies that they need

> to have two prefixes, one for each gACSP? That would probably be 
> problematic from the network management perspective. In both cases, 
> either if they decide to use two prefixes, or they use a single gACSP 
> with only one prefix, the next question is whether they can acquire a 
> CoA from the other gACSP? if they can, it is possible that the gACSP 
> performs cold potato routing and the RO benefits are not achieved.
>
____