Subject: RE: [nemo] Mobile Network Conops

From: "Davis, Terry L" <[email-masked]>
Date: Thu, 5 Aug 2004 08:24:04 -0700

Alex

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, August 05, 2004 6:29 AM
To: Davis, Terry L
Cc: T.J.Kniveton; Thierry Ernst; IETF NEMO WG
Subject: Re: [nemo] Mobile Network Conops

Davis, Terry L wrote:
> Sometime it helps if you have some rough CONOP requirements for the
> problem you are discussing.

Absolutely.

> For the aircraft (or ship), I can give you a bit of future view of
> what an aircraft CONOP requirements set "might" include.  Very little
>  of this could be considered absolutely definite at this time but
> they are topics of discussion.

Terry, do these CONOP's relate somehow to the Card/Zabele/DoD demo mentioned previously on this list?  They also talk aircraft and LOS.
==========================
I missed the Card/Zabele/DoD demo list mail.  Although they may be similar, these are around discussions for commercial service.  Network Centric Operations certainly have 
===========================

> Some (probably most) of this does not apply to the NEMO problem space  
> but it will give an idea of the challenges facing mobile networks and 
> I think it will give you an idea why I favor HA-HA work remaining  in 
> NEMO.

Yes, HAHA is intriguing.

[CONOPS]

Thanks for providing these requirements.

I think there is a need for an additional CONOP that says that there are times when all wireless links of an airplane (except the ultra-urgent) should be turned off (not just lowered its QoS, but switched off), I think.
=========================
Possibly for passengers, maybe for crew but some links will be up whenever they are available.
=========================

> *	The aircraft will typically have access to Internet connectivity 
> via three or more layer 2 communications.  Typically these will
> include: multiple satcom links, multiple wireless networks 
> (802.11a/b/g & 802.15/20(?)), hardwired terrestrial, or infared.
> 
> *	The aircraft will periodically be on the operator/owners networks,
>  the aircraft manufacturer's networks, multiple airline comm providers 
> (Arinc, Sita, Inmarsat, CBB, etc), maintenance repair stations, 
> multiple regulatory control networks (FAA/JAA/CAA/Eurocontrol), and 
> multiple airports.  It will likely be normally on three or more of 
> these simultaneously.

Are all those networks connected together in a sort of mesh of high-speed links?  Or is each one of them connecting to the Internet via its own ISP?
===========================
Some may be, some definitely will not be interconnected.  I would envision that all of the onboard networks would have the ability to connect to multiple providers; some commercial, some aviation or air traffic control specific.
===========================

Can the HAHA concept help with this sort of deployment mentioned above?
  How?  Is there anything missing in HAHA that needs improvement?
===========================
We will probaly figure that out as we actually see initial versions run.  I do believe there is need for some informational RFC's to be developed for mobile networks to cover what it takes to build a full mobile network infrastructure; I tend to refer to it as "Internet docking" to cover mobility, security, QoS, etc.
==========================

> 
> *	The aircraft will have continuous access to NO single layer 2 
> communication link.
> 
> *	The aircraft will be mixed v4 and v6 systems; some offboard 
> communication support for both will be required.  V6 will likely not  
> predominate until aircraft manufactured dates past 2020.
> 
> *	The aircraft may require specific comm types be sent over the layer
>  2 links in a very specific hierarchy to meet regulatory constraints.
> 
> 
> 
> *	The aircraft operator will require specific message prioritization
>  and queueing by "link cost", priority, and bandwidth.
> 
> *	Most link connectivity points will move in hundreds or thousands of
>  miles when they transfer between ground stations or airports.
> 
> *	Security will be different for all the networks the aircraft 
> connects to.
> 
> *	Link performance characteristics and latency will be different for
>  all links.
> 
> *	The solution must provide for ground based systems to connect to 
> the mobile platform regardless what network it is connected to or
> where it is in the world.  (DNS/DHCP/etc)  Current aerospace 
> standards make this impossible; only the aircraft can currently 
> initiate communications.
> 
> *	Multiple DNS systems will be registered on the different links.  In
>  some cases, due to the aerospace specs, link specific DNS services
> will likely be required.
> 
> *	Security, QoS, and reachability states must be maintained across 
> link and ground station changes.
> 
> *	The aircraft will sometimes go for extended periods in hours with 
> no Internet connectivity.
> 
> *	The aircraft will encounter areas where it will FLAP routes by 
> crossing in and out satellite coverage fringe areas and during
> terminal approach (circling) holding patterns.
> 
> *	The aircraft will have multiple types of onboard networks as well;
>  wired, wifi, infared, etc.
> 
> *	The aircraft may have multiple routers; each may be associated with
>  different links and onboard networks.
> 
> *	The aircraft will most likely only receive communication and 
> network major updates every 10 or 20 years.
> 
> *	There may be regulatory limitations on when and how configurations
>  and routing can be updated.

This should be a bit re-formulated.  "Routing" and "regulatory body" don't quite match.
====================================
Unfortunately they do match since it is not clear what part of the onboard configurations can be dynamically changed without re-certification.  Changing the aviation industry from being 429/629-bus based with hard (permanent) configs is challenging.
====================================

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Aug 2004 11:33:53 +0200

Davis, Terry L wrote:
> I missed the Card/Zabele/DoD demo list mail.

Maybe here http://www1.ietf.org/mail-archive/web/nemo/current/msg01419.html

> Although they may be similar, these are around discussions for 
> commercial service. Network Centric Operations certainly have

I guess they have :-)

I think interoperable commercial services are a very good thing and
we're kind of interested by more details about how could v4/v6 NEMO
moving networks be applied to the mentioned CONOPS.

> =========================== Some may be, some definitely will not be
>  interconnected.  I would envision that all of the onboard networks 
> would have the ability to connect to multiple providers; some 
> commercial, some aviation or air traffic control specific.

Do you have a slide showing specific cases of a commercial provider and
of an aviation/air traffic control provider?

> Can the HAHA concept help with this sort of deployment mentioned 
> above? How?  Is there anything missing in HAHA that needs 
> improvement?

> =========================== We will probaly figure that out as we 
> actually see initial versions run.  I do believe there is need for 
> some informational RFC's to be developed for mobile networks to cover
>  what it takes to build a full mobile network infrastructure; I tend 
> to refer to it as "Internet docking" to cover mobility, security, 
> QoS, etc.

So "Internet Docking" would be a specific local infrastructure of
several providers to which moving networks can seamlessly attach and
maintain ongoing sessions.  Local: would all the provider networks be
connected tightly to one another (local) or would each of those
providers be at different points across the Internet.

> ==================================== Unfortunately they do match 
> since it is not clear what part of the onboard configurations can be 
> dynamically changed without re-certification. Changing the aviation 
> industry from being 429/629-bus based with hard (permanent) configs 
> is challenging. ====================================

I understand. Similar concerns are expressed with respect to the CAN
buses for vehicular. Anyone proposed IP-over-ARINC-629 already? (just
like they have IP over infiniband, ipoib WG).

Alex