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

["Stan Ratliff (sratliff)" <[e-mail]>]

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