Re: [its] [manet] Scenarios, potential topics...

["Dearlove, Christopher (UK)" <[e-mail]>]

The point about the 1 route (rather than 0 routes) case was just to note that the suggestion that the requirement for "always" >1 routes is too strong, not to suggest it was undesirable.

(Incidentally if you need redundancy, and are prepared to accept the additional overheads, then >1 routes isn't sufficient, you also need to consider whether they are disjoint or not.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: [phone] |  Fax: [phone]
[e-mail] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[e-mail]] 
Sent: 03 July 2012 18:11
To: Dearlove, Christopher (UK)
Cc: Rex Buddenberg; Alexandru Petrescu; manet; [e-mail]; Abdussalam Baryun
Subject: Re: [manet] [its] Scenarios, potential topics...

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Yes, I agree - 1 route is better than 0. But at least for me, the point is that >1 route is always better than 1.. hence, "interfaces" instead of "interface". ;-)  And which link is better, etc, etc. 

Regards,
Stan

On Jul 3, 2012, at 12:58 PM, Dearlove, Christopher (UK) wrote:

> There are emergency service requirements where even 1 route would be an improvement on the otherwise available 0 routes. Communications down to the platform on underground railway lines would have been one on 7/7 in London.
> 
> -- 
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: [phone] |  Fax: [phone]
> [e-mail] | http://www.baesystems.com
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Rex Buddenberg
> Sent: 03 July 2012 17:41
> To: Alexandru Petrescu
> Cc: manet; [e-mail]; Abdussalam Baryun
> Subject: Re: [manet] [its] Scenarios, potential topics...
> 
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
> 
> Alex,
> 
> You just HAD to go and ask:
> 
>> I am interested to hear others' oppinions as well.
>> 
> 
> One of the handful of requirements differences between emergency
> services and the rest of us is higher availability and survivability
> needs.  Skipping some analysis steps, this always boils down to >1
> route.  
> 
>>>> Scenario :  A router deployed in a moving vehicle, uses its egress
>>>> interface to connect to larger-area access network(s) or to other
>>>> vehicles.
> 
> So the English in the above statement is not quite right: 'interface'
> MUST be plural in any practical situation: interfaces.  
> 
> 
> LTE is likely to be the big player for the radio-WAN, but there won't be
> just one instantiation.  A quick scenario: an instrumented ambulance may
> have one or more LANs within the vehicle to which several end systems
> are attached -- vital signs sensors, VOIP handset for the EMT, etc.
> quite possibly a WiFi hotspot ...  All attached to a vehicle-mounted
> router.  The router has interfaces to 1) wired ethernet (for use while
> in the garage), 2) commercial LTE (where coverage exists), 3) emergency
> services LTE (in US, this is earmarked for 700MHz band and does not yet
> in fact exist), 4) WiFi -- pick up a neighborhood hotspot, 5) satellite
> or other radio-WAN network for rural areas not reachable by other means.
> Any sane high Ao engineering will be picking at least two of the
> above.  
> 
> 
> Any help?
> 
> 
> 
> On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote:
>> Hi Abdussalam and thanks for the reply.
>> 
>> Le 01/07/2012 19:31, Abdussalam Baryun a écrit :
>>> Hi Alex and All,
>>> 
>>>> Scenario :  A router deployed in a moving vehicle, uses its egress
>>>> interface to connect to larger-area access network(s) or to other
>>>> vehicles.
>>> 
>>> <Q1>Should it use IPv6-over-LTE?
>> 
>> In our context we consider indeed IPv6 over LTE, for several reasons.
>> The 3GPP specs about LTE seem to be very specific and detailed about the
>> use of IPv6.  (In the past, before LTE, the earlier 3GPP specs were
>> mentioning IPv6 but more like an option feature.)
>> 
>> However, the 3GPP specs about the use of IPv6 have some lack of
>> specification in the case that the UE (User Terminal) is actually a
>> Mobile Router.  The Prefix Delegation part may be underspecified.
>> 
>>> <Q2>Should it use Mobile IP?
>> 
>> Hmm... that is a good question and much can be said about it.  I am
>> interested to liste others' oppinions as well.
>> 
>> I think Mobile IP may be necessary but not sufficient.  In the case of
>> direct vehicle-to-vehicle IP communications (non covered areas) Mobile
>> IP may not be necessary.  It may be that extensions to Neighbor
>> Discovery and DHCP could help establish paths within local topologies.
>> 
>> And, when that is done (e.g. exchange routes between two vehicles using
>> RA) it may become apparent that interactions between Mobile IP and this
>> mechanism may be necessary.
>> 
>>>> Open to discussion:<Q3> what are the scenarios?
>> 
>> We are interested in describing the scenarios.  There may exist several
>> possibilities.  I think of the following lego-like approach:
>> 
>> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation.
>> - scenario MR-to-MR - conceive prefixes in Router Advertisements,
>>   compare to other dynamic routing approaches.
>> - scenario MR-to-MR-to-Infrastructure - combine the above two.
>> 
>> Another direction is classify the kinds of vehicles.  I think of
>> something like this:
>> 
>> - Internet Vehicle (has a plethora of interfaces, long- and short-
>>   range).
>> - Range Extending Vehicle - extends the range of reachability.
>> - Leaf Vehicle - like and end-node.
>> 
>> Then there are other scenario statements that could open the path to the
>> following:
>> - addressability within vehicle, ULA, VIN.
>> - problem of bandwidth difference between inside and outside the
>>   vehicle.
>> 
>>> <Q4> What are the potential work items?  <Q5>What might be needed,
>>> if anything at all?
>>> 
>>> I am interested  to work on Vehicle Ad-hoc NETwork (VANET) and ITS
>>> issues and in your questions directions. I will join the ITS-WG which
>>> I think can have relation to MANET [RFC2501].
>> 
>> Well, hmm.  I am happy to hear that but let us go easy about this.
>> 
>> "ITS" at IETF is currently just an informal effort.  Its future may be
>> ambitious but right now it's not a WG.  To do that, we'd need to make a
>> BoF first (Birds-of-a-Feather) and ask others' oppinion about way forward.
>> 
>> Secod, RFC2501 and ad-hoc routing are just one possibility to continue
>> working on this.  Some people may express positive technical feedback
>> about MANET and others less so.
>> 
>>> IMO that vehicle routers communications depend on both their
>>> communication protocols and the used-network for such communication
>>> (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO
>>> there is no doubt that Mobile IP [RFC6275] is needed for the router's
>>> if the communication is through the Internet's domain(s), but if it
>>> is through Ad-hoc networks' domain(s) it MAY not be used.
>> 
>> I tend to agree that Mobile IP may not be needed between vehicles which
>> communicate directly without infrastructure.  Then one wonders _what_ is
>> needed?
>> 
>>> The Internet is an infrastructure network and Ad-hoc networks are
>>> infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with
>>> the WG answers, and will read more into the WG inputs regarding these
>>> issues.
>> 
>> (see above note about this "WG" acronym which ITS is not currently)
>> 
>>> I will schedule to participate/prepare I-D in the future for ITS
>>> scenarios. I am preparing an I-D on DSRv2 routing which is a MANET
>>> routing protocol that fits the use-case of ITS and VANET as well.
>> 
>> I am interested to work on scenario/reqs drafts for ITS.
>> 
>> About "DSRv2" - is it still about Routing Headers?
>> 
>> I am interested to hear others' oppinions as well.
>> 
>> Yours,
>> 
>> Alex
>> 
>>> 
>>> Regards
>>> 
>>> Abdussalam Baryun University of Glamorgan, UK
>>> =======================================================
>>> 
>>> From: Alexandru Petrescu <alexandru.petrescu at gmail.com> To: its
>>> at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its]
>>> Scenarios, potential topics...
>>> --------------------------------------------------------------------------------
>>> 
>>> 
>>> 
>>> 
>>> 
>> Welcome to the ITS list at IETF, an informal discussion.
>>> 
>>> Earlier at IETF discussions related to vehicular communications
>>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a
>>> few), drafts were published [*].  At times people expressed interest
>>> to meet f2f.  Now there is this email list.
>>> 
>>> Participants are solicited to work on the topic of using IP in
>>> Intelligent Transportation Systems.  The term ITS is a placeholder
>>> that, in my oppinion, is generic enough to cover many aspects of
>>> vehicular communications; vehicles may be wheeled, watered, flown.
>>> Ambulance, fire engine, coastal ship are particular examples.
>>> 
>>> Scenario :  A router deployed in a moving vehicle, uses its egress
>>> interface to connect to larger-area access network(s) or to other
>>> vehicles.  Should it use IPv6-over-LTE?  Should it use Mobile IP?
>>> 
>>> Example potential work items: - Reqs for IPv6 in vehicular networks
>>> - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and
>>> IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p
>>> (IPv6-over-foo). - open.
>>> 
>>> I am told about other vehicular drafts and discussions, that I have
>>> not cited, existed and still exist (about e.g. ecall).  I am
>>> interested to learn about all the vehicular activities at IETF.
>>> 
>>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO.
>>> 
>>> Open to discussion: what are the scenarios?  What are the potential
>>> work items?  What might be needed, if anything at all?
>>> 
>>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02
>>> draft-jhlee-mext-mnpp-00.txt, October 2009.
>>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009.
>>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010.
>>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008.
>>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011.
>>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011.
>>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010.
>>> draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010
>>> draft-rosen-ecrit-ecall-04.txt, March 2010.
>>> draft-singh-simple-vehicle-info, July 2007.
>>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010.
>>> draft-bauer-mext-aero-solspace, Sep. 2009.
>>> draft-bauer-mext-aero-topology, Sep. 2009.
>>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008.
>>> draft-rosen-ecrit-ecall-05.txt, March 2012.
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
> 
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
> 
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet