WiMob'07: Special Session on Mobility Models

CFP for IEEE WiMOB’2007 special session on Mobility Models for
Mobile Ad hoc Networks, Mesh networks, Wireless networks and NEMO
networks

The session is a part of the 3rd IEEE International Conference on
Wireless and Mobile Computing, Networking and Communications
“WiMob 2007”

http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in
Crowne Plaza Hotel, White Plains, New York, USA, from October 8-10, 2007.

Motivations:

Because WiMob'07 conference is focused on wireless networks and because
the performances of wireless networks are strongly linked to the
mobility models used, we propose a special session focusing only on
mobility models. This session is focused on these kind of wireless
networks:
- MANET: Mobile ad hoc networks where whole the topology is dynamic
- Mesh networks and classical wireless networks offering an
   infrastructure topologies allowing fixed and mobile Internet for the
   end user.
- Network Mobile (NEMO) networks offering new kind of dynamic topology
   where not only the user is mobile but also the network

These kind of networks should deal with mobility: user mobility, group
mobility, etc. But, what is really mobility? how mobility influences the
performances? how to define new mobility models? etc.

Scope of the Contributions for Mobility Models in the case of MANET,

RE: [Mipshop] Multicast Mobility mailing list

Hi Rajeev,
  Sorry for the late reply. I am on vacation and checking mail very irregularly. Thanks for the offer to take up
the problem work in mobopts. I was not sure whether the solution space falls within the purview of mobopts.

Thanks
Suresh

________________________________

From: Rajeev Koodli [mailto:rajeev.koodli <at> nokia.com]
Sent: Mon 23/04/2007 12:54 PM
To: Suresh Krishnan (QB/EMC); mipshop <at> ietf.org; nemo <at> ietf.org; monami6 <at> ietf.org;
mobopts <at> ietf.org; mip4 <at> ietf.org; netlmm <at> ietf.org
Subject: Re: [Mipshop] Multicast Mobility mailing list

Hi Suresh,

Good to see interest on this topic.

As you may be aware, MobOpts has been looking into this topic for a while
now. draft-schmidt-mobopts-mmcastv6-ps-02.txt is a good document
illustrating the problems and existing approaches to solving them, with
about 50 references. This is adopted as the RG document.

I think we will have interesting work to do starting with the problem
description (with possibly more than one work item). It would be good to
have the interests channeled together for maximum benefit.

MobOpts has also been successful in handing over relatively mature topics to
IETF WGs when it makes sense. This is also something we can investigate on

FW: Beyond State of the Art contributions merge v2.doc

FW: Beyond State of the Art contributions merge v2.doc

DS-MIP6: Consensus call to close issue 93

Hello,

The DS-MIP6 I-D <draft-ietf-mip6-nemo-v4traversal-04.txt> still has
issue 93 open. This was discussed at IETF68. Vijay presented 4 options
to solve the issue. These are captured in:

https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf

We need to make a decision on this issue and move forward with the
I-D. At the meeting itself, I got the sense that option 3 was the one
that had the least impact and easy to implement.

Please consider this email as a consensus call for issue 93. The
problem and choices are as follows (based on Vijay's slides):

Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The
encapculations are either:
 - IPv6-in-UDP-over-IPv4
 - IPv4-in-UDP-over-IPv4
There is a need (or I guess desirable) to indicate the type of
protocol being encapsulated in the UDP header.

Choices are:
1. Parse the protocol header following the UDP header
2. Reserve a UDP port for each protocol header (i.e one UDP port for
   IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)
3. One reserved UDP port and a DS-MIP6 "tunnel type message"
4. Encapsulated protocol header type is indicated in the BU message

Pros and cons of these choices are in the slides that were presented
at IETF68 (see URL above).

Please provide your opinions and comments by May 15th, 07 on the MIP6
mailing list.

-Raj

Reminder: VANET 2007 Submissions due May 14

gmane.ietf.nemo

ANNOUNCEMENT and CALL FOR PAPERS

VANET 2007

The Fourth ACM International Workshop on Vehicular Ad Hoc Networks

In conjunction with ACM MobiCom 2007
September 10, 2007   
Montréal, QC, Canada

Sponsored by ACM SIGMOBILE

http://www.sigmobile.org/workshops/vanet2007/  

Important Dates:
Paper Submission Deadline: May 14, 2007, 11:59 p.m. GMT
Notification of Acceptance: June 18, 2007
Camera-Ready Deadline: July 16, 2007

The goal of this workshop is to present and discuss recent advances in the development of wireless
vehicular ad hoc networking (VANET) technologies.  Based on short- to medium-range communication
systems (vehicle-to-vehicle and vehicle-to-roadside), vehicular ad hoc networks will enable
vehicular safety applications (including collision and other safety warnings) as well as non-safety
applications (like real-time traffic congestion and routing information, high-speed tolling, mobile
infotainment, and many others).

The creation of high-performance, highly reliable, highly scalable, and secure VANET technologies
presents an extraordinary challenge for the wireless research community.  A high degree of
communication reliability is needed under unfavorable conditions.  Clearly, the specificity of
vehicular ad hoc networks in terms of mobility behavior and applications scenarios and requirements
makes VANET research an exciting and demanding application- and purpose-driven sub-discipline of
wireless networking.

Following the successes of VANET 2004 held in Philadelphia, VANET 2005 held in Cologne, Germany, and VANET
2006 in Los Angeles, CA, the Fourth ACM International Workshop on Vehicular Ad Hoc Networks (VANET) will
be held in Montréal, QC, Canada September 14, 2007, in conjunction with MobiCom 2007. 

Authors are invited to submit papers presenting new research related to the theory or practice of
vehicular ad hoc networks (VANET).  All submissions must describe original research, not published or
currently under review for another workshop, conference, or journal.  Areas of interest include, but are
not limited to:

- Safety and non-safety applications
- Roadside-to-vehicle and vehicle-to-vehicle communication
- Communication protocol design
- Channel modeling
- Modulation and coding
- Power control and scalability issues
- Multi-channel organization and operation 
- Security issues and countermeasures
- Privacy issues
- Network management
- Simulation frameworks & real-world testbeds

VANET present a highly active field of research, development, standardization and field trials. 
Throughout the world, there are many national/international projects in government, industry, and
academia devoted to VANET.  These include the consortia like Vehicle Safety Consortium (US), Car-2-Car
Communication Consortium (Europe) and Advanced Safety Vehicle Program (Japan), standardization
efforts like IEEE 802.11p (WAVE), and field trials like the large-scale Vehicle Infrastructure
Integration Program (VII) in the US.

Submission Instructions

All paper submissions will be handled electronically.  Papers must be in PDF format, no longer than 10 pages
(single- or double-column), in font no smaller than 11 points, and must fit properly on US Letter-sized
paper (8.5 inch x 11 inch) with reasonable margins.  Submitted papers will be judged based on their quality
through a double-blind review process, where the identities of the authors are withheld from the
reviewers.  Detailed instructions for paper submission will be posted on the VANET 2007 web page at: http://www.sigmobile.org/workshops/vanet2007/.

 
General Co-Chairs:
Wieland Holfelder, DaimlerChrysler REDNA
Paolo Santi, Italian Natl. Research Council

Technical Program Co-Chairs:
Yih-Chun Hu, University of Illinois at Urbana-Champaign
Jean-Pierre Hubaux, EPFL

Web Chair:
Ken Laberteaux, Toyota Technical Center

Technical Program Committee (partial list):
Victor Bahl, Microsoft Research
Fan Bai, General Motors
Levente Buttyan, Budapest University of Technology and Economics
Tracy Camp, Colorado School of Mines
Eylem Ekici, Ohio State University
Tamer ElBatt, San Diego Research Center
Andreas Festag, NEC Europe Ltd
Hannes Hartenstein, University of Karlsruhe
Wieland Holfelder, DaimlerChrysler REDNA
Yih-Chun Hu, University of Illinois at Urbana-Champaign
Jean-Pierre Hubaux, EPFL 
Markus Jakobsson, Indiana University
Daniel Jiang, DaimlerChrysler REDNA
Frank Kargl, Ulm University
Timo Kosch, BMW
Ken Laberteaux, Toyota Technical Center
Martin Mauve, Heinrich Heine University Düsseldorf
Christof Paar, Ruhr-University Bochum
Panos Papadimitratos, EPFL
Adrian Perrig, Carnegie Mellon University
Maxim Raya, EPFL
Paolo Santi, CNR
Rajeev Shorey, General Motors Research
Pravin Varaiya, University of California at Berkeley

RE: [Mip6] DS-MIP6: Consensus call to close issue 93

Hi,

My preference is for option 4. I know many preferred option 
3, but it adds a 4 byte per-packet overhead for each tunneled
data packet. I wish we can avoid that.

Vijay 

> -----Original Message-----
> From: Basavaraj Patil [mailto:basavaraj.patil <at> nsn.com] 
> Sent: Tuesday, May 08, 2007 2:16 PM
> To: Mobile IPv6 Mailing List; nemo <at> ietf.org
> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93
> 
> 
> Hello,
> 
> The DS-MIP6 I-D <draft-ietf-mip6-nemo-v4traversal-04.txt> still has
> issue 93 open. This was discussed at IETF68. Vijay presented 4 options
> to solve the issue. These are captured in:
> 
> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf
> 
> We need to make a decision on this issue and move forward with the
> I-D. At the meeting itself, I got the sense that option 3 was the one
> that had the least impact and easy to implement.
> 
> Please consider this email as a consensus call for issue 93. The
> problem and choices are as follows (based on Vijay's slides):
> 
> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The
> encapculations are either:
>  - IPv6-in-UDP-over-IPv4
>  - IPv4-in-UDP-over-IPv4
> There is a need (or I guess desirable) to indicate the type of
> protocol being encapsulated in the UDP header.
> 
> Choices are:
> 1. Parse the protocol header following the UDP header
> 2. Reserve a UDP port for each protocol header (i.e one UDP port for
>    IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)
> 3. One reserved UDP port and a DS-MIP6 "tunnel type message"
> 4. Encapsulated protocol header type is indicated in the BU message
> 
> Pros and cons of these choices are in the slides that were presented
> at IETF68 (see URL above).
> 
> Please provide your opinions and comments by May 15th, 07 on the MIP6
> mailing list.
> 
> -Raj
> 
> 
> _______________________________________________
> Mip6 mailing list
> Mip6 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
> 

RE: [Mip6] DS-MIP6: Consensus call to close issue 93

Hi Raj, 

At the meeting Sri (the author of the issue) and Kent said they didn't know
that a UDP port was already reserved. Once we cleared that, the rationale
for the issue was no longer applicable. I believe Sri said he wanted some
time to be sure before the issue is rejected. 
More inline on the options: 

 > Choices are:
 > 1. Parse the protocol header following the UDP header

=> This should be "parse the version field after the UDP header". This is
what's already in the draft and it works fine today with any UDP
encapsulation. 

 > 2. Reserve a UDP port for each protocol header (i.e one UDP port for
 >    IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)

=> This isn't needed. 

 > 3. One reserved UDP port and a DS-MIP6 "tunnel type message"

=> This is what the issue suggested but the additional 4 bytes are
redundant. 

 > 4. Encapsulated protocol header type is indicated in the BU message

=> Again, not needed IMO.

I think option 1 is the right option. There is no reason given for a change.

Hesham

RE: RE: [Mip6] DS-MIP6: Consensus call to close issue 93

Hi Hesham:

Sure. I agree that the application can switch based
on the IP version field. True. I'm ok either way. You
can keep it the way you have it now or use an approach
below. But, just one comment.

I prefere 3519 style of thin wrapper. Reason: If we
need to add Keepalive messages tomorrow, a separate
subtype can be defined for the keepalive messages and
so we can extend this. Off course, I do realize, you guys
wanted to use BU/BA as the keepalive message and that
processing in my opinion is bit expensive compared to a
simple keepalive message and that too with the option
of skipping keepalive message when any data traffic
is seen. But, if you think this 4-byte wrapper is a waste
for the keepalive extension that never be defined in
future, I'm ok.

Sri

> -----Original Message-----
> From: Hesham Soliman [mailto:Hesham <at> elevatemobile.com] 
> Sent: Tuesday, May 08, 2007 7:03 PM
> To: 'Basavaraj Patil'; 'Mobile IPv6 Mailing List'; nemo <at> ietf.org
> Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93
> 
> Hi Raj, 
> 
> At the meeting Sri (the author of the issue) and Kent said 
> they didn't know
> that a UDP port was already reserved. Once we cleared that, 
> the rationale
> for the issue was no longer applicable. I believe Sri said he 
> wanted some
> time to be sure before the issue is rejected. 
> More inline on the options: 
> 
> 
>  > Choices are:
>  > 1. Parse the protocol header following the UDP header
> 
> => This should be "parse the version field after the UDP 
> header". This is
> what's already in the draft and it works fine today with any UDP
> encapsulation. 
> 
>  > 2. Reserve a UDP port for each protocol header (i.e one 
> UDP port for
>  >    IPv6-in-UDP-over-IPv4 and another for 
> IPv4-in-UDP-over-IPv4 etc.)
> 
> => This isn't needed. 
> 
>  > 3. One reserved UDP port and a DS-MIP6 "tunnel type message"
> 
> => This is what the issue suggested but the additional 4 bytes are
> redundant. 
> 
>  > 4. Encapsulated protocol header type is indicated in the BU message
> 
> => Again, not needed IMO.
> 
> I think option 1 is the right option. There is no reason 
> given for a change.
> 
> Hesham
> 
> 

RE: RE: [Mip6] DS-MIP6: Consensus call to close issue 93

Hi Sri,  

 > Sure. I agree that the application can switch based
 > on the IP version field. True. I'm ok either way. You
 > can keep it the way you have it now or use an approach
 > below. But, just one comment.
 > 
 > I prefere 3519 style of thin wrapper. Reason: If we
 > need to add Keepalive messages tomorrow, a separate
 > subtype can be defined for the keepalive messages and
 > so we can extend this. Off course, I do realize, you guys
 > wanted to use BU/BA as the keepalive message and that
 > processing in my opinion is bit expensive compared to a
 > simple keepalive message and that too with the option
 > of skipping keepalive message when any data traffic
 > is seen. But, if you think this 4-byte wrapper is a waste
 > for the keepalive extension that never be defined in
 > future, I'm ok.

=> I agree with you on the need for lighter weight keep-alive. I raised an
issue
a long time ago, and rejected it :), because there wasn't enough interest to
justify its addition. 
However, I don't think it's related to this discussion because if we wanted
a keep alive we 
could simply define a new option in the DO header or just encapsulate a
"ping". 
So I don't see the correlation with this issue as the keepalive can always
be sent in a ping using either IPv4 or IPv6 and the same parsing rules would
apply. 

Hesham

 > 
 > Sri
 > 
 >  
 > 
 > > -----Original Message-----
 > > From: Hesham Soliman [mailto:Hesham <at> elevatemobile.com] 
 > > Sent: Tuesday, May 08, 2007 7:03 PM
 > > To: 'Basavaraj Patil'; 'Mobile IPv6 Mailing List'; nemo <at> ietf.org
 > > Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to 
 > close issue 93
 > > 
 > > Hi Raj, 
 > > 
 > > At the meeting Sri (the author of the issue) and Kent said 
 > > they didn't know
 > > that a UDP port was already reserved. Once we cleared that, 
 > > the rationale
 > > for the issue was no longer applicable. I believe Sri said he 
 > > wanted some
 > > time to be sure before the issue is rejected. 
 > > More inline on the options: 
 > > 
 > > 
 > >  > Choices are:
 > >  > 1. Parse the protocol header following the UDP header
 > > 
 > > => This should be "parse the version field after the UDP 
 > > header". This is
 > > what's already in the draft and it works fine today with any UDP
 > > encapsulation. 
 > > 
 > >  > 2. Reserve a UDP port for each protocol header (i.e one 
 > > UDP port for
 > >  >    IPv6-in-UDP-over-IPv4 and another for 
 > > IPv4-in-UDP-over-IPv4 etc.)
 > > 
 > > => This isn't needed. 
 > > 
 > >  > 3. One reserved UDP port and a DS-MIP6 "tunnel type message"
 > > 
 > > => This is what the issue suggested but the additional 4 bytes are
 > > redundant. 
 > > 
 > >  > 4. Encapsulated protocol header type is indicated in 
 > the BU message
 > > 
 > > => Again, not needed IMO.
 > > 
 > > I think option 1 is the right option. There is no reason 
 > > given for a change.
 > > 
 > > Hesham
 > > 
 > > 
 >