Subject: RE: [nemo] can't make San Diego but here's some food for thought

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 2 Aug 2004 23:46:31 +0200

Hi Stuart:

For the multiple encapsulation problem, there's been a number of solution proposed to what we refer to as nested RO. In particular, RRH as a 2 year history of discussion in the ML (current version is 5); it has been implemented and tested. I'd be glad to discuss that if you wish.

What needs to be done next is a classical header compression that includes both the IPv6 header and the routing header over the low speed link, and I guess that's it.

http://www1.ietf.org/mail-archive/web/nemo/current/msg01306.html 

Pascal
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart W. Card
> Sent: lundi 2 août 2004 18:41
> To: IETF NEMO WG
> Cc: T.J.Kniveton; [email-masked]; [email-masked]
> Subject: [nemo] can't make San Diego but here's some food for thought
> 
> At 04:50 PM 7/30/2004, <[email-masked]> wrote:
> >...
> >See you in San Diego...
> 
> Sadly, I will again be unable to join you.  However, I would like
> to take this opportunity to remind you of some work we have done
> and issues we have identified, described in long-ago postings to
> the mailing list, in case any of this proves relevant during IETF60.
> 
> (1) We have a very NEMO-like solution for IPv4 under Linux.  It has
> been extensively tested, both in the lab and in the field (multiple LANs
> aboard aircraft, using Line Of Sight, Beyond LOS and SATCOM radios
> to reach base stations). It uses MIPv4 extension type 42 to register
> prefixes and supports multihoming via multiple simultaneous COAs.
> It minimally violates the MIPv4 RFC by not merely sending redundant
> packets to the COAs, but rather load balancing across them with
> QoS reservations. That approach to forwarding is decoupled from
> the basic network mobility support mechanism, so the registration
> is 100% compliant with the RFCs as far as we know.  It was designed
> by Dr. Steve Zabele of AlphaTech, implemented by his staff, and
> integrated by a Northrop Grumman led team into a DoD system.
> 
> (2) We have not yet migrated to IPv6 and NEMO, partly
> because the lack of FAs in MIPv6 forces encapsulation
> over the links to the MRs.  While this overhead is minor
> over wireline and many wireless media, it is significant
> over our wireless WAN links (long latency, low data rate,
> high error rate, due to being narrowband and traversing
> long ranges often including geostationary satellites).
> We would like to migrate to IPv6 and NEMO to be in step
> with the community.  Are there any ideas being considered
> that could obviate the requirement for encapsulation over the
> links to the MRs, at least in some special cases that might
> need additional support not required by the basic support draft?
> 
> (3) For the reasons cited in (2) above, we are concerned with
> the multiple encapsulation that may occur with nested NEMO
> and/or RO.  We really don't care about RO in the wireline network,
> as our bandwidths are so many orders of magnitude smaller, but
> we do need to avoid any avoidable multiple trips or encapsulations
> over the wireless links.  We believe this concern will be shared
> by other developers of wireless WANs, as bandwidth is inherently
> much more precious in the wireless WAN than the wireless LAN,
> as the latter spectrum can be extensively re-used in different cells,
> but the former cannot.
> 
> (4) Assume MN1 is served by MR1 and MN2 by MR2, and that
> the former is the parent of the latter in a nested NEMO.  If MR2
> then achieves another point of attachment to the fixed infrastructure,
> but also retains its connectivity through MN1, MN2 is multi-homed,
> but MN1 is not, per the the nomenclature and multihoming drafts.
> This is because MNs are nominally precluded from offering transit.
> However, the access link between MR1 and the infrastructure may
> have very different QoS attributes from that directly between MR2
> and the infrastructure: nodes in MN2 can choose their preference,
> but nodes in MN1 cannot; in some scenarios, the restriction on
> transit through MN2 will preclude some applications from running
> on nodes in MN1, even though adequate capacity and QoS would
> be available to them, were they only permitted to transit MN2.
> Setting QoS aside, MN1 and MN2 may both offer bursty traffic,
> with peak demand from each exceeding the capacity of its MR's
> direct link to the backbones, but the peak aggregate demand
> not exceeding their aggregated capacity; MN2 will be fine, but
> MN1 will suffer needless congestion induced packet loss if it is
> not permitted to transit MN2.  We realize that transit should not
> be offered in general by MNs, for good and obvious reasons, but
> believe cases of this sort should be supported.  Keep in mind that
> the only reason MN2 was allowed to transit MN1, and not vice versa,
> was the temporal order in which registrations occurred: MN2 first was
> attached to MN1 and then later directly to the backbones; had MN2
> initially been attached to a backbone, and MN1 attached to MN2,
> the 'rules' as to who can transit whom would have been reversed.
> 
> If anyone would like to discuss these interactively, despite my
> absence from the face-to-face meeting, send me an e-mail and
> we can arrange to speak by phone.
> 
> We believe these concerns will be shared, not just by US DoD
> developers, but by mobile wireless WAN developers in general,
> so thanks for giving them some thought!
> 
> Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
> * Creativity * Diversity * Expertise * Flexibility * Integrity *
> 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: Thu, 05 Aug 2004 15:12:10 +0200

Pascal Thubert (pthubert) wrote:
> For the multiple encapsulation problem, there's been a number of 
> solution proposed to what we refer to as nested RO. In particular, 
> RRH as a 2 year history of discussion in the ML (current version is 
> 5); it has been implemented and tested. I'd be glad to discuss that 
> if you wish.
> 
> What needs to be done next is a classical header compression that 
> includes both the IPv6 header and the routing header over the low 
> speed link, and I guess that's it.
> 

Pascal, are you sure that RRH is well adapted to Stuart's scenario?
Seems that that secnario uses Linux and I understand RRH is prototyped
only under Cisco routers, right?

Pascal, do you know what kind of network topology the Card/Zabele/DoD
demo was using?  Do you know whether all the ground stations are linked
together with fast links or via ISP/Internet?

I strongly doubt that any of the currently proposed RO schemes was done
with the kind of architecture in mind that Card/Zabele is talking about.

I mean there might be other simpler ways to get rid of the encapsulation
overhead if we know the architecture; RRH is kind of like for very
wide-area and numerous-hosts Internet architecture.

Alex

---

From: ivancic <[email-masked]>
Date: Fri, 06 Aug 2004 09:13:03 -0400

Alexandru Petrescu wrote:

> ........Pascal, do you know what kind of network topology the 
> Card/Zabele/DoD

>with the kind of architecture in mind that Card/Zabele is talking about.
IMHO writing or even considering a protocol optimized for a specific 
architecture is a costly endevor.  It is a proprietrary solution.  
Something the FAA  and other Government organizations are use to 
investing in as DoD and Aerospace companies like proprietary solutions.  
Once you get in the door, you have no competition.  Thus the airline 
service providers (United, Quantas, Contiental,  Delta, etc....) should 
be pushing for an IETF standards solution to control costs.  Hopefully, 
Stewart can get develop his ideas and, if deemed reasonable, get them 
incorporated in the IETF standards.

Will

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Aug 2004 15:29:16 +0200

ivancic wrote:
>> demo was using?  Do you know whether all the ground stations are 
>> linked together with fast links or via ISP/Internet?
>> 
>> I strongly doubt that any of the currently proposed RO schemes was 
>> done with the kind of architecture in mind that Card/Zabele is 
>> talking about.
>> 
> investing in as DoD and Aerospace companies like proprietary 
> solutions. Once you get in the door, you have no competition.  Thus 
> the airline service providers (United, Quantas, Contiental,  Delta, 
> etc....) should be pushing for an IETF standards solution to control 
> costs.  Hopefully, Stewart can get develop his ideas and, if deemed 
> reasonable, get them incorporated in the IETF standards.

I kind of noticed this.  The "proprietary" "closed" systems discussion
is not always black and white to me.  Motorola has a proprietary closed
system within which Mobile IP is used as per RFC, but that does not mean
this protocol is well adapted to that particular closed situation.  Much
better could have been done with simpler and more cost-effective than
Mobile IP.

I was trying to say that Mobile IP in general has a very typical
architecture in mind (i.e. mobile device connecting at the edges of the
Internet, to wireless ISP's) which is somehow restrictive in nature,
especially when considering the airborne stuff mentioned, or even the
coast guard stuff in one of your papers.

I was thinking to take the opportunity to learn about this variety of
"alternative" architectures if I can say so, 3 were mentioned, and see
whether better than Mobile IP can be done.  But, as you say, this may be
a too costly endeavour.  At the same time, seeing Mobile IP deployed in
closed systems (3GPP is another one) is really sometimes so
performance-consuming, and giving place to so difficult to understand
designs such as HAHA that, I don't know...

Maybe this is about IRTF...

Alex