Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update)

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 03 Apr 2008 18:11:32 +0900

George,

George Tsirtsis
> Guys,
>
> I am not sure I follow you.
>
> My understanding of the HA advertising a Lifetime on a link is that it
> allows nodes on the link to (1) discover the HA address (2) cache the
> HA address for as long as the lifetime indicates. This makes sense *on
> link* since end nodes may discover the HA capability but they may also
> have no use for it for a while (e.g., until a handoff to a foreign
> link).
>   
OK, but I have one question.

When MN uses the HA-1 for its home registration and the lifetime of HA-1 
is expired,
will MN start discoverying the new HA for its home registration?
Or MN can continue using the HA-1 unless HA-1 rejects home registration?

I mean
can MN removes the HA entry used for current home registration, when the 
lifetime of that HA is expired?
MN start discoverying the HA again and re-send the BU to the newly 
discovered HA?

I might miss something here. I'm getting confused.

> If  this explanation is correct, I would argue that when the HA is
> discovered from a foreign link e.g., using DHAAD, DNS, DHCP etc, the
> HA address must be used immediately and thus should NOT be cached. In
> other words the MN should discover the HA address when it needs it and
> then either engage with it or forget about it.
>   
Do you mean the MN does not record the HA discovered by DHAAD in the 
home agent list?

regards
ryuji

> Does this make sense?
>
> George
>
> On Thu, Mar 20, 2008 at 9:19 AM, Benjamin Lim
> <[email-masked]> wrote:
>   
>> Hi,
>>
>>  Just saw this mail in my back-log. Comments inline.
>>
>>
>>  > -----Original Message-----
>>  > From: [email-masked] [mailto:[email-masked]] On
>>  > Behalf Of RYUJI WAKIKAWA
>>  > Sent: Monday, March 17, 2008 4:39 PM
>>  > To: Hesham Soliman
>>  > Cc: [email-masked]
>>  > Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update)
>>  >
>>  > Hi Hesham
>>  >
>>  > I guess this HA lifetime (Home Agent Information Option)
>>  > might be originally introduced for the management of home
>>  > agents operated on the same link.
>>  > Indeed, all the description for this option are for the Home
>>  > Agent operation in RFC3775.
>>  [Ben] Most likely, HAs on home link uses lifetime to compute preferences on
>>  the avaliability of HAs, since 3775 states that HA will reply MN in the HA
>>  list a number of prefered HAs.
>>
>>
>>  >
>>  > We should clearly state that this option is used only for HA
>>  > and not for MN.
>>  > The usage of the home agent information option can be limited
>>  > to the HA.
>>  [Ben] Why limit for HA usage? You pointed out in your previous mail that
>>  since MR/MN does not know HA lifetime, is it not better to also inform MR/MN
>>  of HA's lifetime in the HA list to advert those issues you raised up?
>>
>>  Regards,
>>  Benjamin Lim
>>
>>
>>
>>  > We just need to add 1-2 lines for the better clarification of this.
>>  >
>>  > what do you think?
>>  >
>>  > regards
>>  > ryuji
>>  >
>>  >
>>  >
>>  >
>>  > On 2008/03/14, at 12:44, Hesham Soliman wrote:
>>  >
>>  > > I think this is a valid point but I don't know if 3775 is the right
>>  > > place to address it. Since DHAAD is the only mechanism defined in
>>  > > 3775 there is no issue. Other RFCs that define other
>>  > mechanisms need
>>  > > to address the missing information.
>>  > >
>>  > > Hesham
>>  > > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote:
>>  > >
>>  > >> Hi
>>  > >>
>>  > >> In RFC3775, the HA can advertise the HA lifetime by the Home Agent
>>  > >> information option carried in RA.
>>  > >> However, this home agent lifetime is only available in this option.
>>  > >>
>>  > >> When MR boots up from a foreign link, there are several
>>  > ways to get
>>  > >> HA address such as DNS lookup, DHAAD (no HA lifetime field
>>  > is defined
>>  > >> in DHAAD message), etc.
>>  > >>
>>  > >> How should MN manage these HAs in the home agent list?
>>  > >>
>>  > >> When the HA lifetime is not available, should MN set
>>  > INFINITY value
>>  > >> for the HA in the home agent list?
>>  > >>
>>  > >> When MN obtains HA at the foreign link and then back to the home,
>>  > >> shall MN update the HA lifetime of that HA to the value
>>  > specified in
>>  > >> RA?
>>  > >>
>>  > >> MN might lose the HA due to the HA lifetime expiration if
>>  > it return
>>  > >> home.
>>  > >> If it never returns home, MN can keep the HA address
>>  > forever This is
>>  > >> not fair:-)
>>  > >>
>>  > >> I need some clarification how we can use this HA lifetime.
>>  > >>
>>  > >> regards,
>>  > >> ryuji
>>  > >>
>>  > >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!!
>>  > >>
>>  > >>
>>  > --------------------------------------------------------------
>>  > -----------
>>  > >>                       CALL FOR PAPERS
>>  > >>
>>  > >>                          MobiCom 2008
>>  > >>           The Fourteenth Annual International Conference
>>  > >>               on Mobile Computing and Networking
>>  > >>
>>  > >>                       September 14-19, 2007
>>  > >>                       San Francisco Bay Area, CA, USA
>>  > >>             http://www.sigmobile.org/mobicom/2008/
>>  > >>                   Sponsored by ACM SIGMOBILE
>>  > >>
>>  > ---------------------------------------------------------------------
>>  > >> ---- ACM MobiCom is the premier international conference
>>  > dedicated to
>>  > >> addressing the challenges in the areas of mobile computing and
>>  > >> wireless and mobile networking.  It has served as an exciting
>>  > >> international forum since 1995, addressing networks, systems,
>>  > >> algorithms, and applications that support the symbiosis of mobile
>>  > >> computers and wireless networks. This year, we will continue this
>>  > >> tradition, but we especially encourage the submission of papers in
>>  > >> the experimental systems area.  This area has seen exciting
>>  > >> developments in recent years and explicit efforts will be taken to
>>  > >> represent it strongly at MobiCom this year.
>>  > >>
>>  > >> Authors are invited to submit full papers, challenges
>>  > papers, student
>>  > >> posters, and research demos and exhibits, presenting new research
>>  > >> related to the theory or practice of mobile computing
>>  > and/or wireless
>>  > >> and mobile networking. All submissions must describe original
>>  > >> research, not published or currently under review for another
>>  > >> conference or journal. Areas of interest include, but are
>>  > not limited
>>  > >> to:
>>  > >>
>>  > >> * Operating system and middleware support for mobile computing and
>>  > >>   networking
>>  > >> * Architectures, protocols, and algorithms to cope with mobility,
>>  > >>   limited bandwidth, limited power and/or intermittent connectivity
>>  > >> * Fundamental understanding of mobile computing and wireless
>>  > >> networking
>>  > >> * Wireless and mobile techniques for delay tolerant, mobile ad hoc,
>>  > >>   and wireless sensor networks
>>  > >> * Security, privacy, and trustworthiness of mobile and wireless
>>  > >> systems
>>  > >> * Wireless access technologies (e.g. mesh systems, PANs)
>>  > >> * Integration and interworking of wired and wireless networks
>>  > >> * Protocols exploiting novel technologies such as UWB, MIMO,
>>  > >>   directional antennas, and software radios
>>  > >> * Techniques for dynamic spectrum use
>>  > >> * Architectures, algorithms and protocols for cognitive wireless
>>  > >>   networks and their integration in the Internet
>>  > >> * Modeling, measurement and simulation of mobile networks
>>  > >> * Experimental test-beds for mobile/wireless networks
>>  > >> * Performance evaluation of mobile and wireless networks,
>>  > protocols,
>>  > >>   and systems
>>  > >> * Next generation (beyond 802.11) wireless technologies and related
>>  > >>   systems and protocols
>>  > >>
>>  > >> Submission Instructions
>>  > >> Detailed instructions on how and where to submit your paper can be
>>  > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf
>>  > >>
>>  > >> IMPORTANT DATES:
>>  > >> Abstracts submission due: March 7, 2008 Paper submission
>>  > due: March
>>  > >> 14, 2008 Notification of acceptance: June 19, 2008 Camera-ready
>>  > >> version due: July 7, 2008
>>  > >>
>>  > >> General Chair - [email-masked]:
>>  > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC
>>  > >>
>>  > >> Technical Co-Chairs - [email-masked]:
>>  > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter
>>  > Steenkiste, Carnegie
>>  > >> Mellon University
>>  > >>
>>  > >> FOR MORE INFORMATION: Please contact the General Chair or Program
>>  > >> Co-Chairs for more information.  For information on ACM
>>  > SIGMOBILE and
>>  > >> the MobiCom series of conferences, see
>>  > http://www.sigmobile.org/ or
>>  > >> contact [email-masked].
>>  > >>
>>  > >>
>>  > --------------------------------------------------------------
>>  > -----------
>>  > >>                         CALL FOR PAPERS
>>  > >>
>>  > >>                        ACM MobiArch 2008
>>  > >>                  An ACM SIGCOMM 2008 Workshop
>>  > >>                Seattle, WA, USA, August 22, 2008
>>  > >>
>>  > >>              The 3rd ACM International Workshop on
>>  > >>          Mobility in the Evolving Internet Architecture
>>  > >>             Paper registration deadline: March 17, 2008
>>  > >>
>>  > ---------------------------------------------------------------------
>>  > >> ----
>>  > >>
>>  > >>      http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/
>>  > >>
>>  > >> Recent developments in wireless access technologies and mobile
>>  > >> devices are beginning to make widespread user, terminal
>>  > and network
>>  > >> mobility a reality in the commercial Internet. At the same
>>  > time, the
>>  > >> Internet architecture struggles to incorporate the
>>  > functionality that
>>  > >> will sustain this increasingly more mobile and more
>>  > dynamic Internet
>>  > >> use.
>>  > >> Efficient
>>  > >> mobility management and mobility optimizations, locator-identifier
>>  > >> splits, multihoming, security and related network operation and
>>  > >> management functions are still in the early stages of
>>  > development. It
>>  > >> is, however, already clear that supporting widespread
>>  > mobility poses
>>  > >> to significantly impact the original end-to-end design of the
>>  > >> Internet.
>>  > >>
>>  > >> At the same time, critical momentum is building to significantly
>>  > >> revise or even replace the current Internet architecture. Several
>>  > >> substantial Future Internet initiatives have started in
>>  > Europe, the
>>  > >> US and Asia, and the topic is also actively being discussed in the
>>  > >> vendor and network operator communities. These Future Internet
>>  > >> efforts offer the exciting opportunity to design radically
>>  > different
>>  > >> approaches to supporting host and network mobility and
>>  > multihoming,
>>  > >> and may eventually lead to an internetwork architecture with
>>  > >> significantly more advanced mobility features than those that the
>>  > >> piecemeal extensions of the current Internet protocols result in.
>>  > >>
>>  > >> MobiArch'08 welcomes submissions from both researchers and
>>  > >> practitioners that explore recent advances in architectures,
>>  > >> protocols and emerging technologies to enable mobility and
>>  > >> multihoming in the Internet, as well as concepts and designs to
>>  > >> support widespread mobility and multihoming in future
>>  > internetworks.
>>  > >> Early results, position papers, systems and measurement papers are
>>  > >> particularly welcome.
>>  > >>
>>  > >> TOPICS
>>  > >> MobiArch'08 covers all aspects related to mobility in the
>>  > current and
>>  > >> future Internet, including, but not limited to:
>>  > >>
>>  > >> * Architectures and protocols for mobility support at all layers
>>  > >>   of the Internet protocol stack, as well as cross-layer approaches
>>  > >> * Novel concepts to support widespread mobility and multihoming
>>  > >>   in a Future Internet
>>  > >> * Routing and addressing issues (including locator/identifier
>>  > >>   splits) and their impact on the Internet architecture
>>  > >> * Multihoming, including flow distribution and load-sharing for
>>  > >>   wireless and mobility
>>  > >> * Performance evaluation, experimentation and modeling of
>>  > >>   Internet mobility
>>  > >> * Models for mobility patterns and their experimental validation
>>  > >> * New wireless technologies and services and their impact on the
>>  > >>   Internet architecture
>>  > >> * Location management, positioning and data management for
>>  > >>   wireless and mobility
>>  > >> * Accounting, access control, security and privacy issues and
>>  > >>   their impact on the Internet architecture
>>  > >> * Social, economic, scalability and deployment issues
>>  > >>
>>  > >> SUBMISSION GUIDELINES
>>  > >> Submissions must be no longer than six pages, including
>>  > all figures
>>  > >> and references, must be in PDF format, and must follow the ACM
>>  > >> formatting guidelines
>>  > >> (http://www.acm.org/sigs/publications/proceedings-templates
>>  > >> ).
>>  > >> Submissions that do not adhere to these requirements will
>>  > be rejected
>>  > >> without further review.
>>  > >> Peer review is single-blind; the authors names and
>>  > affiliations are
>>  > >> to be included on the submission. Submissions cannot be previously
>>  > >> published or be under concurrent review elsewhere. The
>>  > submission of
>>  > >> position papers is encouraged; please clearly identify position
>>  > >> papers as such when submitting.
>>  > >> Papers may be submitted at http://edas.info/newPaper.php?c=6140
>>  > >>
>>  > >> IMPORTANT DATES
>>  > >> March 17, 2008        Registration of paper abstract
>>  > >> March 24, 2008        Submissions due
>>  > >> May 1, 2008           Notification of acceptance
>>  > >> June 9, 2008          Camera ready version due
>>  > >> August 22, 2008       Workshop date
>>  > >>
>>  > >>
>>  > >> TECHNICAL PROGRAM COMMITTEE
>>  > >> Lars Eggert           (co-chair, Nokia Research Center, FI)
>>  > >> Linda Doyle           (co-chair, Trinity College, IE)
>>  > >> Rui Aguiar            (Universidade de Aveiro, PT)
>>  > >> Bengt Ahlgren         (Swedish Institute of Computer Science, SE)
>>  > >> Jari Arkko            (Ericsson, FI)
>>  > >> Marcelo Bagnulo       (University Carlos III of Madrid, ES)
>>  > >> Olivier Bonaventure   (Université Catholique de Louvain, BE)
>>  > >> Wesley Eddy           (NASA/Verizon (US)
>>  > >> Joseph Evans          (University of Kansas, US)
>>  > >> Ted Faber             (USC Information Sciences Institute, US)
>>  > >> Stephen Hailes        (University College London, UK)
>>  > >> Roger Karrer          (T-Labs, DE)
>>  > >> Rajeev Koodli         (Nokia Research Center, US)
>>  > >> Donal O'Mahony        (Trinity College, IE)
>>  > >> Jörg Ott              (Helsinki University of Technology, FI)
>>  > >> Guru Parulkar         (Stanford University, US)
>>  > >> Dipankar Raychaudhuri (Rutgers University, US)
>>  > >> Dave Thaler           (Microsoft, US)
>>  > >> Ryuji Wakikawa        (Keio University, JP)
>>  > >> Klaus Wehrle          (RWTH Aachen University, DE)
>>  > >> Lixia Zhang           (UCLA, US)
>>  > >>
>>  > >> _______________________________________________
>>  > >> MEXT mailing list
>>  > >> [email-masked]
>>  > >> https://www.ietf.org/mailman/listinfo/mext
>>  > >
>>  >
>>  > _______________________________________________
>>  > MEXT mailing list
>>  > [email-masked]
>>  > https://www.ietf.org/mailman/listinfo/mext
>>  >
>>
>>
>>  _______________________________________________
>>  MEXT mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/mext
>>
>>     

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 03 Apr 2008 18:14:42 +0900

Hi George

In my previous email, I tried to figure out why DHAAD does not provide 
HA lifetime.
My guess was that the HA lifetime is originally proposed for HA who manages
other HAs at the home link by original authors.
I think my guess was wrong...

Anyway, if MN manages the HA lifetime if the lifetime is available,  we 
need some
operational description when the lifetime is not available.
RFC3775 clearly said that the HA entry MUST be deleted when its lifetime 
is expired.
BUT the lifetime is not always available...

So far, we have two options for this.

1. George
     No cache. MN does not record the HA information in its home agent list.
2. Vijay
     Local configuration matter. No modification is required to RFC3775.

I personally agree with Vijay, but I think we need some clarification 
for this in the bis.
We might need to define the default value for the locally configured HA 
lifetime..

regards,
ryuji

George Tsirtsis

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 3 Apr 2008 11:10:17 +0100

Ryuji,

I am fine with staying silent on this is issue as Vijay is saying. I
do not understand why you propose a "default" lifetime though.

George

On Thu, Apr 3, 2008 at 10:14 AM, Ryuji Wakikawa
<[email-masked]> wrote:
> Hi George
>
>  In my previous email, I tried to figure out why DHAAD does not provide HA
> lifetime.
>  RFC3775 clearly said that the HA entry MUST be deleted when its lifetime is
> expired.
>  I personally agree with Vijay, but I think we need some clarification for
> this in the bis.

---

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 4 Apr 2008 14:17:04 +0800

Hi Ryuji,
 
See below.

=8==8<=8==
> RFC3775 clearly said that the HA entry MUST be deleted when 
> its lifetime is expired.
[Ben] Which part of 3775 states this? Base on section 11.4.1, I did not see
such comment.

> I personally agree with Vijay, but I think we need some 
> clarification for this in the bis.
> We might need to define the default value for the locally 
> configured HA lifetime..
[Ben] Base on my understanding of 3775 sect 11.4.1, it does not specifically
mention what MN will do to the list of HA address received in DHAAD reply. I
think the confusion comes in because the section state one possible way to
do home registration is to perform a sequential trial of each home agent
address in the list (e.g. test 1st HA address --> fail --> test 2nd HA
address --> fail --> until end of list or succeed.) So this implies that MN
should store the list of HA address in order to do the above action. Whether
this list is store temporary (just to find HA) or permenantly (info for MN
in case HA goes down) is not mention. Maybe we should add some clarifying
text for this matter?

Regards,
Benjamin Lim

> >>  > From: [email-masked] 
> [mailto:[email-masked]] On  > 
> >> Behalf Of RYUJI WAKIKAWA  > Sent: Monday, March 17, 2008 
> 4:39 PM  > 
> >> To: Hesham Soliman  > Cc: [email-masked]  > Subject: Re: [MEXT] The 
> >> usage of "HA lifetime" (RFC3775-update)  >  > Hi Hesham  > 
>  > I guess 
> >> this HA lifetime (Home Agent Information Option)  > might be 
> >> originally introduced for the management of home  > agents 
> operated 
> >> on the same link.
> >>  > Indeed, all the description for this option are for the Home  > 
> >>  [Ben] Most likely, HAs on home link uses lifetime to compute 
> >> preferences on  the avaliability of HAs, since 3775 states that HA 
> >> will reply MN in the HA  list a number of prefered HAs.
> >>
> >>
> >>  >
> >>  > We should clearly state that this option is used only for HA  > 
> >> and not for MN.
> >>  > The usage of the home agent information option can be 
> limited  > 
> >> to the HA.
> >>  [Ben] Why limit for HA usage? You pointed out in your 
> previous mail 
> >> that  since MR/MN does not know HA lifetime, is it not 
> better to also 
> >> inform MR/MN  of HA's lifetime in the HA list to advert 
> those issues you raised up?
> >>
> >>  Regards,
> >>  Benjamin Lim
> >>
> >>
> >>
> >>  > > I think this is a valid point but I don't know if 3775 is the 
> >> right  > > place to address it. Since DHAAD is the only mechanism 
> >> defined in  > > 3775 there is no issue. Other RFCs that 
> define other  
> >> > mechanisms need  > > to address the missing information.
> >>  > >
> >>  > > Hesham
> >>  > >> In RFC3775, the HA can advertise the HA lifetime by the Home 
> >> Agent  > >> information option carried in RA.
> >>  > >> When MR boots up from a foreign link, there are 
> several  > ways 
> >> to get  > >> HA address such as DNS lookup, DHAAD (no HA lifetime 
> >> field  > is defined  > >> in DHAAD message), etc.
> >>  > >>
> >>  > >> When the HA lifetime is not available, should MN set  > 
> >> INFINITY value  > >> for the HA in the home agent list?
> >>  > >>
> >>  > >> When MN obtains HA at the foreign link and then back to the 
> >> home,  > >> shall MN update the HA lifetime of that HA to 
> the value  
> >> > specified in  > >> RA?
> >>  > >>
> >>  > >> MN might lose the HA due to the HA lifetime 
> expiration if  > it 
> >> return  > >> home.
>  > forever 
> >> This is  > >> not fair:-)  > >>  > >> I need some 
> clarification how 
> >> we can use this HA lifetime.
> >>  > >>
> >>  > >> regards,
> >>  > >> ryuji
> >>  > >>
> >>  > >> ---- ACM MobiCom is the premier international conference  > 
> >> dedicated to  > >> addressing the challenges in the areas 
> of mobile 
> >> computing and  > >> wireless and mobile networking.  It 
> has served as 
> >> an exciting  > >> international forum since 1995, addressing 
> >> networks, systems,  > >> algorithms, and applications that support 
> >> the symbiosis of mobile  > >> computers and wireless 
> networks. This 
> >> year, we will continue this  > >> tradition, but we especially 
> >> encourage the submission of papers in  > >> the 
> experimental systems 
> >> area.  This area has seen exciting  > >> developments in 
> recent years 
> >> and explicit efforts will be taken to  > >> represent it 
> strongly at 
> >> MobiCom this year.
> >>  > >>
> >>  > >> Authors are invited to submit full papers, challenges  > 
> >> papers, student  > >> posters, and research demos and exhibits, 
> >> presenting new research  > >> related to the theory or practice of 
> >> mobile computing  > and/or wireless  > >> and mobile 
> networking. All 
> >> submissions must describe original  > >> research, not 
> published or 
> >> currently under review for another  > >> conference or 
> journal. Areas 
> >> of interest include, but are  > not limited  > >> to:
> >>  > >>
> >>  > >> * Fundamental understanding of mobile computing and 
> wireless  > 
> >> >> networking  > >> * Wireless and mobile techniques for delay 
> >> tolerant, mobile ad hoc,
> >> > >> systems  > >> * Wireless access technologies (e.g. 
> mesh systems, 
> >> PANs)  > >> * Integration and interworking of wired and wireless 
> >> networks  > >> * Protocols exploiting novel technologies 
> such as UWB, 
> >> MIMO,
> >>  > >> * Techniques for dynamic spectrum use  > >> * Architectures, 
> >> algorithms and protocols for cognitive wireless
> >>  > >> * Modeling, measurement and simulation of mobile 
> networks  > >> 
> >> * Experimental test-beds for mobile/wireless networks  > >> * 
> >> Performance evaluation of mobile and wireless networks,  > 
> protocols,
> >>  > >>   and systems
> >>  > >> Detailed instructions on how and where to submit 
> your paper can 
> >> be  > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf
> >>  > >>
> >>  > >> IMPORTANT DATES:
> >>  > >> Abstracts submission due: March 7, 2008 Paper submission  > 
> >> due: March  > >> 14, 2008 Notification of acceptance: June 
> 19, 2008 
> >> Camera-ready  > >> version due: July 7, 2008  > >>  > >> General 
> >> Chair - [email-masked]:
> >>  > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC  > >>  > >> 
> >>  > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter  > 
> Steenkiste, 
> >> Carnegie  > >> Mellon University  > >>  > >> FOR MORE INFORMATION: 
> >> Please contact the General Chair or Program  > >> 
> Co-Chairs for more 
> >> information.  For information on ACM  > SIGMOBILE and  > >> the 
> >> MobiCom series of conferences, see  > 
> http://www.sigmobile.org/ or  > 
> >> > >> devices are beginning to make widespread user, 
> terminal  > and 
> >> network  > >> mobility a reality in the commercial 
> Internet. At the 
> >> same  > time, the  > >> Internet architecture struggles to 
> >> incorporate the  > functionality that  > >> will sustain this 
> >> increasingly more mobile and more  > dynamic Internet  > >> use.
> >>  > >> Efficient
> >>  > >> mobility management and mobility optimizations, 
> >> locator-identifier  > >> splits, multihoming, security and related 
> >> network operation and  > >> management functions are still in the 
> >> early stages of  > development. It  > >> is, however, 
> already clear 
> >> that supporting widespread  > mobility poses  > >> to 
> significantly 
> >> impact the original end-to-end design of the  > >> Internet.
> >>  > >>
> >>  > >> At the same time, critical momentum is building to 
> >> significantly  > >> revise or even replace the current Internet 
> >> architecture. Several  > >> substantial Future Internet 
> initiatives 
> >> have started in  > Europe, the  > >> US and Asia, and the topic is 
> >> also actively being discussed in the  > >> vendor and network 
> >> operator communities. These Future Internet  > >> efforts 
> offer the 
> >> exciting opportunity to design radically  > different  > >> 
> >> approaches to supporting host and network mobility and  > 
> >> multihoming,  > >> and may eventually lead to an internetwork 
> >> architecture with  > >> significantly more advanced 
> mobility features 
> >> than those that the  > >> piecemeal extensions of the current 
> >> Internet protocols result in.
> >>  > >>
> >>  > >> MobiArch'08 welcomes submissions from both 
> researchers and  > 
> >> >> practitioners that explore recent advances in 
> architectures,  > >> 
> >> protocols and emerging technologies to enable mobility and  > >> 
> >> multihoming in the Internet, as well as concepts and 
> designs to  > >> 
> >> support widespread mobility and multihoming in future  > 
> >> internetworks.
> >>  > >> Early results, position papers, systems and 
> measurement papers 
> >> are  > >> particularly welcome.
> >>  > >>
> >>  > >> TOPICS
> >>  > >> MobiArch'08 covers all aspects related to mobility in the  > 
> >> current and  > >> future Internet, including, but not limited to:
> >>  > >>
> >>  > >> * Models for mobility patterns and their experimental 
> >> validation  > >> * New wireless technologies and services 
> and their impact on the
> >>  > >>   Internet architecture
> >>  > >> * Social, economic, scalability and deployment 
> issues  > >>  > 
> >> >> SUBMISSION GUIDELINES  > >> Submissions must be no 
> longer than six 
> >> pages, including  > all figures  > >> and references, must 
> be in PDF 
> >> format, and must follow the ACM  > >> formatting guidelines  > >> 
> >>  > >> Submissions that do not adhere to these requirements 
> will  > be 
> >> rejected  > >> without further review.
> >>  > >> Peer review is single-blind; the authors names and  > 
> >> affiliations are  > >> to be included on the submission. 
> Submissions 
> >> cannot be previously  > >> published or be under concurrent review 
> >> elsewhere. The  > submission of  > >> position papers is 
> encouraged; 
> >> please clearly identify position  > >> papers as such when 
> >> submitting.