Subject: [nemo] Preparing NEMO Agenda - please sent slot request ASAP

From: Thierry Ernst <[email-masked]>
Date: Fri, 14 Feb 2003 12:19:16 +0900 (JST)

Dear all,

The next IETF meeting is approaching.  This mailing list has been more
than silent over the past months. There is an old IETF tradition (not
much discussion on ML between meetings, strong activity a few weeks
before, and keeping silent afterwards), and we (NEMO members) have
been very respectful in doing it :-). I myself didn't push for
discussions since I was due to release the draft. Now that it's done,
I'm relieved from this burden. Anyway, sorry for the delay.

So, the object of this mail is to ask you if we need a meeting at San
Francisco ? I yes, I need to know if anyone of you is planning to
contribute drafts or discussion in the following, which are the most
urgent, besides the requirements:

- threat analysis

- solution for basic support

- other ?

With this respect, may I ask you to send both TJ and myself request
for slots ASAP so that we know how much time we should request
(subject, time requested, associated draft is any).

At present time, we don't see a need for more than a 1-hour meeting. I
will make a slot request Tuesday 18th Feb based on the requests
received no later than MONDAY MIDNIGHT. Of course, requests will be
accepted after this date, but provided we have time left in the
requested slot.

Thierry.

---

From: William D Ivancic <[email-masked]>
Date: Fri, 14 Feb 2003 15:53:08 -0500

I've recently been asked to work with the Aeronautical community to provide 
input to their Protocol Specifications.  The aeronautical community, 
similar to the Space community, often adds some requirements that then make 
it very difficult to use  standard IETF protocols.      Instead, some 
changes are required and then you end up with a proprietary protocol.  My 
experience has lead me to believe that these added requirements are often 
unnecessary and little thought is put into the end cost and complexity.

The following statements were taken from a Draft Communiqué From ATNP/WGB 
to AEEC ADN Working Group.  I've voice my opinion to various ATNP/WGB 
groups members regarding what requirements are absolute necessary. I have 
also pointed out  that the Mobile IPv4 mobile networks I've worked with do 
not perform policy based routing and that only one preferred route is taken 
when two or more attachment points from the mobile to the fixed network are 
available.

Does anyone see the need for  or anticipate implementing policy base 
routing or allowing data to flow over more than one link?  Not only does 
this seem more complex, but It seems like a security problem as one would 
be tying multiple ISPs networks togeather or perhaps an ISP with a 
Corporate network.  Is this in the current requirements document?  I didn't 
think so.  If not, should this at least be addressed as something that is 
currently required, something that will be addressed in future 
requirements, or something that will not be allowed?

For you information,  the aeronautical links are currently 8 kbps 
shared.  Also, to the best of my knowledge, the layer-2 radio systems do 
not support such links.  Everybody listens on the same frequencies and only 
one VDL (VHF Data Link) radio per aircraft.  Full deployment isn't until 
2010 or so.  In addition, Satellite links which may provide the secondary 
attachment points will probably provide 50 kpbs to 2 Mbps or better data 
rates from aircraft to ground and perhaps higher from ground to aircraft.

Will

(Sorry about all the Acronyms,  I don't know what each stands for yet)
===================================================
Mobile IP Key Issues

ATNP/WG B has raised the following four issues regarding the use of mobile 
IP for aircraft.  Our response is provided after statement of the ATNP/WG B 
as extracted from the referenced document:

1. Connectivity to multiple subnets:

Comment:

“International Civil Aviation Organization (ICAO) requirement is to permit 
aircraft to be able to make concurrent use of more than one air/ground 
datalink according to a policy based routing scheme that determines which 
datalink is used for each application. The ICAO OPLINK Panel has specified 
the requirements for datalink selection using a hierarchical 
classification. This requirement is necessary when reliance is placed upon 
network availability for air safety. It also acts as a means of mitigating 
the effects of Denial of Service attacks and can help provide load 
balancing over limited bandwidth networks.

On the other hand, Mobile IP has been designed to permit the use of a 
single mobile network at any one time with “make before break” transition 
between mobile networks. It does not permit simultaneous use other than by 
duplicating traffic (ref RFC 3220 4.2.3).”

Response:

We understand and agree with the above comment. We also believe that a 
similar requirement exists in other airborne applications. At this point we 
are investigating various options to satisfy ICAO mobility requirements. 
Some of these options are:

q       Incorporate IDRP mobility in IP based networks
q       Provide input to NEMO specifications
q       Devise an Aviation specific solution

Within the last two years Internet Architecture Board (IAB) has actively 
supported inclusion of aviation industry requirements within the IETF 
activities. NEtwork MObility (NEMO) Working Group under IETF has been 
chartered to address the enhanced support for network mobility that would 
include multiple points of attachment for a mobile network. We believe that 
NEMO, with input from the aviation community, will satisfy the ICAO 
mobility requirements, including concurrent use of more than one air/ground 
datalink according to a policy based routing scheme that determines which 
datalink is used for each application.

---

From: Greg Daley <[email-masked]>
Date: Mon, 17 Feb 2003 10:18:10 +1100

Hello Will,

Current basic NEMO specifications are aimed at
individual hosts not perceiving the link on which
their data flows, nor that the link is moving at all.

The mobile router or HA may be able to allocate data
to individual tunnels MR(Addr1)->HA or MR(Addr2)->HA
and allocation of flows to these and the reverse tunnels
(from HA->MR) may be able to be established using an
integrated QoS signalling scheme (such as RSVP).

This is a policy routing issue, which is not solely mobility
related.  It should be possible though to investigate the
effects of movement on resource reservation re/allocation
in the case of movement.

It may be that the QoS signalling issues are analogous
to those in transient networks, or equivalent to host based
schemes since the MR is likely to be the gateway for all
NEMO traffic, and understands the QoS requirements of the
hosts.

Anyone have ideas?

Greg

---

From: Alexandru Petrescu<[email-masked]>
Date: Mon, 17 Feb 2003 15:26:11 +0100

Greg Daley wrote:
[...]
> Anyone have ideas?

Hi Greg how are you, ideas plenty.

I think that aeronautics requirements are important should be refined
and included in the requirements document.  It's also that it might be
that aeronautics requirements fit very well within the current
requirements, but we need to identify that.

One could note that requirements from several other fields have been
suggested until now, and they are not yet reflected in the
requirements draft.

For example, aeronautics, MESA and automotive types of requirements
have been suggested until now.  I guess we could try to see if they
could be refined and integrated together in the requirements document.

That is also to say that currently the draft mentions ITS (Intelligent
Transportation System) in paragraph two of section 1.  What is ITS?
Does ITS consider usage of IP technologies?  Is there a "competitor"
to ITS?

-- 
Message Classification: GBU

---

From: Greg Daley <[email-masked]>
Date: Tue, 18 Feb 2003 09:03:49 +1100

Hi Alex,

ITS is a way of using computation systems
to provide information about vehicular
traffic flow, origin-destination path
statistics and monitoring of unusual/emergency
traffic events.

I think that ITS is a broad field, rather than
a specific technology. ITS can rely on many different
technologies: for example, inductive
loop instrumentation embedded in road surfaces and
visual recognition techniques.
I know of some projects in france which have been
using GSM systems as instrumentation for determining
speeds and volumes of user flows.
Similar analogies may be made with IP networks.

If we have a list of interested parties/documents,
should we approach a group/groups requirements doc,
maybe a bit similar to the 3GPP-IPv6wg reqs?
Should this be accounted for in the base reqs?

I'm inclined to believe that the reqs should not
be combined with the basic NEMO reqs, since we're
not sure that the application areas will all be covered
with basic NEMO (low-latency communications for example).

Greg

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 18 Feb 2003 17:09:26 +0100

Greg Daley wrote:
> I think that ITS is a broad field, rather than a specific 
> technology. ITS can rely on many different technologies: for 
> example, inductive loop instrumentation embedded in road surfaces 
> and visual recognition techniques.

Aha, I see what you mean.  When I'm asking about ITS using IP
technologies is exactly for that kind of communication.  For example,
is ITS going to assign an IP address to the bumper of your car,
another IP address to my bumper and run an UDP application on your
bumper that sends the distance to my bumper (the distance as seen by
your bumper).  Then a sort of election takes place and both my bumper
and your bumper decide we're too close, so your car accelerates, my
car de-celerates.  A similar thing happens between a plane taking off
and a plane landing: if too close, the former goes down the latter
goes up.

This scenario assumes that bumpers have IP addresses.  Now, even if
this assumption is true, there we still need to see whether it fits in
the network mobility scenarios.  The above scenario fits better a
manet(-to-be), not much the NEMO approach.

A NEMO-fitting scenario would be that your bumper is reachable at a
permanent home address; when your bumper gets too close to my bumper,
it would first present itself "HELO" with its permanent home address.
  Then my bumper would write to that permanent home address telling it
being too close.  Note, that if my bumper and if your bumper are in a
close relation somehow, travelling together, then, after the vehicles
have been distanced, I would care about where you are, hoping you
didn't take an alternate route.  So my bumper would send an UDP
message to your bumper asking "WHEREIS", again towards the same
permanent home address.

Also, an even more credible scenario is car manufacturer upgrading
software inside the vehicle, without a need for the vehicle to get an
appointment to a service center: devices in the car have a permanent
home address, reachable whenever the vehicle can connect to the
Internet.  That excellently fits the "parts replacement" scenario for
many manufactureres and for NEMO as well.

Remark this is all imaginary scenario (I have no affiliation to ITS),
but this could fit the network mobility because there are several
devices with IP addresses and in a moving network.

Aeronautics could come up with similar scenarios.

This is also to say that there is potentially much more to using IP
technologies in a vehicle, than just giving access to Web for user
laptops.

> I know of some projects in france which have been using GSM systems
>  as instrumentation for determining speeds and volumes of user 
> flows. Similar analogies may be made with IP networks.

Aha, I know about one project in Switzerland for SMART cars (that is a
very small car, like the ones driving in golf field) where you get off
the car, you click the button "park yourself", and the car parks
itself between two other cars in the parking.  Remember the "park"
command of MS-DOS parking the disk heads :-)

Still that doesn't use IP addresses for bumpers.

> If we have a list of interested parties/documents, should we 
> approach a group/groups requirements doc, maybe a bit similar to 
> the 3GPP-IPv6wg reqs? Should this be accounted for in the base reqs
> 
> 
> 
> I'm inclined to believe that the reqs should not be combined with 
> the basic NEMO reqs, since we're not sure that the application 
> areas will all be covered with basic NEMO (low-latency 
> communications for example).

I tend to agree, so maybe we should remove ITS from
draft-requirements, but try to find out which are the scenarios that
are being considered both by ITS and by aeronautics and by 3gpp that
do need IP addresses and IP connectivity.  And since William came up
with such an aeronautics scenario, we should consider it in more detail.

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 18 Feb 2003 01:23:32 -0500

At 09:03 AM 2/18/2003 +1100, Greg Daley wrote:

>... ITS is a way of using computation systems
>I think that ITS is a broad field...
>
>If we have a list of interested parties/documents...

I would be happy to participate in a sub-group focused
on aeronautics (in my case, Air Force) requirements for
NEMO.  I agree there are some oddities that come up here
more frequently than elsewhere: for instance, multiple
radio link technologies with _very_ different characteristics
(VHF LOS only when near airports, UHF SATCOM everywhere but
with 250 mS single-hop speed of light lag, etc.).  This is
in addition to traffic profiles (at least for the most
essential traffic) very different from standard Internet
access.  Etc.

Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
Mohawk Valley Engineers Executive Council 2002 Company of the Year!
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email-masked]> www.critical.com

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 18 Feb 2003 17:57:33 +0100

Hi William.  I understand that the requirements below come from a
body/organization strongly considering IP connectivity for for flying
vehicle.  Sorry for my naming scheme, please replace substitute for
the right terms.  Also please note I'm a totally clueless about
the aeronautics field.

I understand that it is assumed that a mobile network could be
deployed in a flying vehicle that flies above the ground and that
connects to different IP subnets lying on the ground.  I understand
that the IP subnets lying on the ground could be offering Access
Routers (AR).  Those two subnets on the ground could be very much
associated to the Foreign Networks concepts of Mobile IPv4.

Then, each time a flying vehicle connects to an Access Router, a
Mobile Router in that vehicle will obtain a new Care-of Address.

But we also need to identify in the aeronautics scenario, where is the
home network.  In this landscape, one might be tempted to associate
the home network to the ground, like "Earth is Home".  However, maybe
a finer association would be that the home network is a certain
airbase, for example the Control Center, or something at a fixed
location, where the HA is placed, and different than the subnetworks
providing the ARs.

> “International Civil Aviation Organization (ICAO) requirement is to
>  permit aircraft to be able to make concurrent use of more than one
>  air/ground datalink according to a policy based routing scheme 
> that determines which datalink is used for each application.

So, I understand that a MR would need simultaneous connectivity to
two or more ground datalinks (AR).  This could fit the multi-homing
requirement in the requirements draft: the mobile network in the
flying network could either have two mobile routers, each connected to
one AR on the ground, or could have one mobile router with two
interfaces, each interface attached to one AR on the ground.

Multiple links to ground could provide reliability and implicitly
safety under the form of a guaranteed link to ground.

> On the other hand, Mobile IP has been designed to permit the use of
>  a single mobile network at any one time with “make before break” 
> transition between mobile networks.

I understand the first occurence of the word mobile network, but not
the second.  Maybe, the second occurence is a confusion: for example
the word "mobile network" is in wide use in the telecom community to
stand for a fixed network that supports mobile terminals moving around
that fixed network.  Is this the intended meaning?

> We understand and agree with the above comment. We also believe 
> that a similar requirement exists in other airborne applications. 
> At this point we are investigating various options to satisfy ICAO
>  mobility requirements. Some of these options are:
> 

William, why suggesting IDRP, is this the Inter-Domain Routing
Protocol (somehow equivalent to BGP)?

What would be the scheme of IDRP work together with Mobile IP?

I'm asking because one might be tempted to understand this as a mobile
network whose MR does routing (IDRP) interactions with the visited
ground network?

---

From: William D Ivancic <[email-masked]>
Date: Tue, 18 Feb 2003 14:13:09 -0500

Alexandru

At 05:57 PM 2/18/2003 +0100, Alexandru Petrescu wrote:.....
>>"International Civil Aviation Organization (ICAO) requirement is to
>>  air/ground datalink according to a policy based routing scheme that 
>> determines which datalink is used for each application.
>
>requirement in the requirements draft:

Correct, but is policy-based routing or load balancing part of this 
requirement.  I don't see it and I don't think is should be - at least for 
the basic support.

"R12: The solution MUST function for multi-homed mobile networks. More 
precisely:
   R13.1: The solution MUST support mobile networks with multiple MRs,
   R13.2: The solution MUST support MR with multiple interfaces,
   R13.3: The solution must support MR with multiple global addresses on an 
egress interface."

>>  a single mobile network at any one time with "make before break" 

Yes, I believe so.

>>similar requirement exists in other airborne applications. At this point 
>>we are investigating various options to satisfy ICAO

This is the suggestion of a small group in the aeronautics community.  I 
have not studied the details of how they may want to use IDRP with mobile 
networks. These statements were taken from an Aeronautics document.  The 
aeronautics community is small and the amount of networking people is 
smaller with lots of politics involved.  They are also very ISO oriented 
today rather than IETF but are moving toward the IETF because of econimics 
and scale.  I suspect that the reason for considering IDRP is taken from 
ISO/IEC 10747:

"The methods of this protocol differ from those generally adopted for an 
intra-domain routeing protocol because they emphasize the interdependencies 
between efficient route calculation and the preservation of legal, 
contractual, and administrative concerns. This protocol calculates routes 
which will be efficient, loop-free, and in compliance with the domain's 
local routeing policies. IDRP may be used when routeing domains do not 
fully trust each other; it imposes no upper limit on the number of routeing 
domains that can participate in this protocol; and it provides isolation 
between its operations and the internal operations of each routeing domain."

I suspect very little consideration has been given to router convergence 
times, the amount of bandwidth required to run IDRP, and the practicality 
of injecting routes into other's networks.  However, for the latter case, 
the aeronautics community may feel they will own their own private network 
- at least on a country by country basis.  A private network is expensive, 
but doable.  In addition, it solves many security problems.

Will

---

From: William D Ivancic <[email-masked]>
Date: Tue, 18 Feb 2003 14:25:45 -0500

>essential traffic) very different from standard Internet

I'm not so sure this is very different from standard Internet and tools 
that are available.  Local QoS off the mobile router is doable today with 
TOS or diff serve bits and queue management.   I can ensure that higher 
priority packets get the bandwidth first.

I've run mobile-ipv4 at up to 3 seconds RTT delay with not problem.  It 
begins to fall apart at higher delays due to security timers - protect 
against replay.   So 250mS single-hop shouldn't be a problem.  I've also 
run across multiple diverse links with no problem.  I haven't done 
policy-based routing, however.  I believe the aeronautics community  wants 
such a policy so they can have command and control on the VHF link with 
other information running on the UHF or Ku-Band or L-Band Satcom link.   I 
am not convinced that such complexity is necessary or truly provides much 
benefit in an operational system.

Will

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 18 Feb 2003 20:54:56 +0100

William D Ivancic wrote:
>>> 1. Connectivity to multiple subnets: Comment: "International 
>>> Civil Aviation Organization (ICAO) requirement is to permit 
>>> aircraft to be able to make concurrent use of more than one 
>> So, I understand that a MR would need simultaneous connectivity 
>> to two or more ground datalinks (AR).  This could fit the 
>> multi-homing requirement in the requirements draft:
> 
> 
>  requirement.  I don't see it and I don't think is should be - at 
> least for the basic support.
> 
> "R12: The solution MUST function for multi-homed mobile networks. 
> More precisely: R13.1: The solution MUST support mobile networks 
> with multiple MRs, R13.2: The solution MUST support MR with 
> multiple interfaces, R13.3: The solution must support MR with 
> multiple global addresses on an egress interface."

I see, so the multi-homing is important.

> This is the suggestion of a small group in the aeronautics 
> community.  I have not studied the details of how they may want to 
> use IDRP with mobile networks. These statements were taken from an 
> Aeronautics document.  The aeronautics community is small and the 
> amount of networking people is smaller with lots of politics 
> involved.

> They are also very ISO oriented today rather than IETF but are 
> moving toward the IETF because of econimics and scale.

I see, I had the opportunity sometimes to meet ISO, ADA and B people. 
  It's often very good to talk to them.

> "The methods of this protocol differ from those generally adopted 
> for an intra-domain routeing protocol because they emphasize the 
> interdependencies between efficient route calculation and the 
> preservation of legal, contractual, and administrative concerns. 
> This protocol calculates routes which will be efficient, loop-free,
>  and in compliance with the domain's local routeing policies. IDRP 
> may be used when routeing domains do not fully trust each other; it
> imposes no upper limit on the number of routeing domains that can
> participate in this protocol; and it provides isolation between its
> operations and the internal operations of each routeing domain."
> 
> I suspect very little consideration has been given to router 
> convergence times, the amount of bandwidth required to run IDRP, 
> and the practicality of injecting routes into other's networks. 
> However, for the latter case, the aeronautics community may feel 
> they will own their own private network - at least on a country by 
> country basis.  A private network is expensive, but doable.  In 
> addition, it solves many security problems.

Yes, a small large private network is expensive (in all terms) but
doable if commitment high enough.

A small large private network has many advantages, like, among others,
the highest possibly level of security and almost highest imaginable
provable level of guarantees of well functioning.

In that case however, I do not have a clear picture of why Mobile IP
is required, I'm trying to clarify (for myself, not in the NEMO
context) what are the advantages that Mobile IP would bring to the
picture, but maybe this is off-topic here.  In a small private
network, maybe IDRP or BGP or other dynamic routing protocols are enough.

Overall, from the aeronautics requirements, I understand that
multi-homing is the only common requirement with NEMO, which is a good
thing that NEMO potentially has to offer to aeronautics, I believe.

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 18 Feb 2003 20:58:04 +0100

William D Ivancic wrote:
> I've run mobile-ipv4 at up to 3 seconds RTT delay with not problem.
> 

What is this RTT between?  Is it between MN and HA or between MN and a
CN?  Or is it between MN and CN through the HA?  If yes, how many IP
hops are there between HA and CN?  Just curious.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 18 Feb 2003 16:49:48 -0800

Hi folks..

> with basic NEMO (low-latency communications for example).

This approach would probably be best; we would like to consider all potentially
germaine applications of mobile routers and embody the reasonable ones in the
requirements draft. All other input and future needs can be dealt with as
special cases or other documents..otherwise, we will be stuck in a holding
pattern.

TJ

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Feb 2003 15:39:18 +0100

In your previous mail you wrote:

=> fine.

   The following statements were taken from a Draft Communique From ATNP/WGB
   
=> policy routing is not a NEMO problem at all. It is not standard in
the Internet by many routers support it (Cisco, Juniper for instance).
It can have performance problems but I believe this will be never a
concern in your context.

   routing

=> it is implemented.

   or allowing data to flow over more than one link?

=> this is another problem. Do you need data of the same stream to
flow over more than one link or not? Do you prefer layer 2 solutions
(PPP-MP, RFC 1990)? etc.

    Mobile IP Key Issues

   Comment:
   
   International Civil Aviation Organization (ICAO) requirement is to permit
   
 => It seems you'd like PPP-MP or similar stuff.

   On the other hand, Mobile IP has been designed to permit the use of a
   single mobile network at any one time with "make before break"
   transition between mobile networks. It does not permit simultaneous
   use other than by duplicating traffic (ref RFC 3220 4.2.3).
   
=> I disagree. If you have multiple home addresses (and home agents),
you can use multiple mobile networks. Look at the multiple interface
stuff to (draft-montavont-mobileip-mmi-00.txt).

=> I already saw this idea some years ago. A priori this is not a bad
idea (when IDRP/CLNS are replaced by BGP/IP) but near all implementations
are not prepared to join or quit adjacencies, or to work well with
a high level of route flapping (i.e., this implies unusual operational
constraints). BTW this seems to be out of the scope of NEMO.

Regards

[email-masked]

PS: air links are very slow compared to core links so a more traditional
solution based on tunelling should work. The problem is planes can move
very far so perhaps the best is a combinaison of both solutions?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Feb 2003 10:29:03 -0800 (PST)

Francis really captures technically my
non-technical discomfort with having a more
confined effort for requirements gathering. My
fear is that such an effort could lead to a rather
stovepiped set of requirements that are preceding
from assumptions that aren't properly checked. My
personal feeling is that input from the
aeronautics community would be *extremely*
valuable, but think that a mutual learning
experience would be a much better way to achieve
that.

Another way to put this, if general NEMO
requirements doesn't fit the needs for the
aeronautics community, it would be a very good
thing to have everybody on the same page as to
what the explicit engineering tradeoffs so we can
partition the problem space. That's at least as
important as cataloging the requirements.

		Mike

---

From: William D Ivancic <[email-masked]>
Date: Fri, 21 Feb 2003 19:20:50 -0500

Alexandru,

I forwarded you question to my colleague, Dave Stewart, who did much of the 
testing.  Place the delay between the MR and FA and between the FA and 
HA.  We used and Adtech SX14.  To place the delay between the FA and MR, we 
needed to put some routers that we used to match interfaces into bridge 
mode.    Dave's response is below.  Sorry I didn't get  back sooner, but I 
wanted to make sure I gave you a correct and complete answer.

>Dave,
>
>Refresh my memory,  we tried the Adtech between the FA and MR, but also, I 
>think we had it between the FA and HA for a while. Correct?

Yes,  it was one ot the first tests we performed, way back when.  We had 
the Adtech between HA - FA and between MR - FA.  In either case, the MD5 
hashing failed when the RTT approached 3 seconds.  It did not make a 
difference whether the delay was evenly split or all on one side of the 
link or the other.  As I recall, Kent (Kent Leung of  Cisco Systems) 
thought he could tweak the registration to fix this, but we felt 3 seconds 
were enough.