Subject: [Irtf-mobility-charter] IP Mobility Optimizations (Mob Opts) RG charter

From: Rajeev Koodli <[email-masked]>
Date: Mon, 06 Oct 2003 10:02:17 -0700

Hello folks,

attached is the charter.
Please provide your input.

Best Regards,

-Rajeev

IP Mobility Optimizations (Mob Opts) 

The dramatic increase in wireless and mobile devices coupled with the
desire to connect them to the ever-growing Internet is leading to a
Mobile Internet, where support for terminal mobility would soon be taken
for granted. While basic protocol support and some enhancements are
being standardized IETF, there is a need for significant research
(both empirical and analytical) to better understand mobility on the
Internet. For instance, a successful handover of a terminal from one
point of attachment to another at least includes a new link establishment
(including link-level (re)authentication), IP connectivity establishment
(including network-layer (re)authentication), and new route
establishment (when the handover leads to a subnet change). In addition,
since a handover almost inevitably affects transport protocol
performance, mechanisms to smoothen handover are of interest. These
considerations become even more challenging when a terminal handovers
across different access networks, such as from a Wireless LAN
to CDMA or to GPRS. Hence, it would be extremely useful to understand
these problems as the transition to the Mobile Internet accelerates.

The objective of this research group is two-fold. Establish a forum
for Wireless and IP Mobility researchers to investigate key and
interesting problems in the field. The findings on these problems
should benefit the community at large, but especially the
standardization bodies like the IETF and the IEEE. And, help establish
a uniform platform or testbed that researchers could use for
experimentation as common tools, scenarios and methodologies provide
more accurate performance benchmarking. A more ambitious, longer-term
goal is to become a catalyst for research in Mobile
Inter-networking. 

The group shall address the following research topics:

o analysis of Mobile IP Route Optimization considering such
  parameters as traffic pattern, link conditions, topology etc. with
  the goal of arriving at conclusions on its usage

o investigation of securing handovers by making use of access
  authentication parameters, focussing initially on IEEE 802
  systems. And, applying the adopted security for Fast Handovers
  designed in the Mobile IP group in the IETF. 

o improving re-authentication latency during handovers, and
  subsequently transport protocol performance

o evaluation of existing and new mechanisms for discovering, and
  selecting a target base station and/or router for handover

o examination of the feasibility of generic mechanisms that allow
  tighter integration of the link layer with the IP layer for
  improving handover performance

o alternative mechanisms for discovering a Mobility Anchor Point (MAP)
  in Hierarchical Mobile IP (HMIP), as well as mechanisms for handling
  the effects of single point of failure

The research group addresses questions of an evolutionary nature,
making use of the IP Mobility architecture (i.e., Mobile IP and
handover optimizations such as Fast Handover and Hierarchical Mobile
IP) developed in the Mobile IP Working Group. In particular, radically
new architectures (e.g., based on the separation of identity and
location) are outside the scopeof this group. 

/* Stanadard template for ML, website,..*/

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 06 Oct 2003 19:22:07 +0200

Rajeev Koodli wrote:
> 
> Hello folks,
> 
> attached is the charter. Please provide your input.

Hello Rajeev, thank you for sending this.

I must acknowledge I'm taken a little bit by surprise by this
announcement, but this must be related to me having difficulty to keep
updated of the most recent advancements at ietf and irtf on mobility.

Could you please introduce this charter a little bit, a bit of recent
history, etc, thank you and sorry if I look clueless it's because things
happened so fast recently.

Was there an IRTF-mobility sort of BoF taking place in Vienna?

Is this somehow related to the mipshop BoF?  Has the mipshop BoF become
an IETF WG?  Referencing HMIP in this irtf-mobility charter seems to
relate to mipshop somehow.

Is this somehow related to the Routing Research group; there existed a
small irtf subgroup dubbed rr-mm (routing research for micromobility)
whose main results was a generic draft with MIND results and which seems
to overlap at some points with this charter (e.g. the MAP thing).

And, finally, have I manually subscribed to this list and my memory
fails me remembering of doing so, or somebody else subscribed me to this
list?  What's the current list membership?  (I've tried mailman
interface on www.irtf.org but to no avail).  Whatever happened, I'm glad
to be here but wanted to know who else is here, what's the status on
openness/private, etc.

"a terminal handovers" might be ok and I prefer
"a terminal hands over".

Thank you for any information,

Alex
GBU

> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  Mobile Internet, where support for terminal mobility would soon be 
> taken for granted. While basic protocol support and some enhancements
>  are being standardized IETF, there is a need for significant 
> research (both empirical and analytical) to better understand 
> mobility on the Internet. For instance, a successful handover of a 
> terminal from one point of attachment to another at least includes a
>  new link establishment (including link-level (re)authentication), IP
>  connectivity establishment (including network-layer 
> (re)authentication), and new route establishment (when the handover 
> leads to a subnet change). In addition, since a handover almost 
> inevitably affects transport protocol performance, mechanisms to 
> smoothen handover are of interest. These considerations become even 
> more challenging when a terminal handovers across different access 
> networks, such as from a Wireless LAN to CDMA or to GPRS. Hence, it 
> would be extremely useful to understand these problems as the 
> transition to the Mobile Internet accelerates.
> 
> standardization bodies like the IETF and the IEEE. And, help 
> establish a uniform platform or testbed that researchers could use 
> for experimentation as common tools, scenarios and methodologies 
> provide more accurate performance benchmarking. A more ambitious, 
> longer-term goal is to become a catalyst for research in Mobile 
> Inter-networking.
> 
> authentication parameters, focussing initially on IEEE 802 systems. 
> And, applying the adopted security for Fast Handovers designed in the
>  Mobile IP group in the IETF.
> 
> tighter integration of the link layer with the IP layer for improving
>  handover performance
> 
> o alternative mechanisms for discovering a Mobility Anchor Point 
> (MAP) in Hierarchical Mobile IP (HMIP), as well as mechanisms for 
> handling the effects of single point of failure
> 
>  IP) developed in the Mobile IP Working Group. In particular, 
> radically new architectures (e.g., based on the separation of 
> identity and location) are outside the scopeof this group.
> 
> 

_______________________________________________
Irtf-mobility-charter mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/irtf-mobility-charter

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 06 Oct 2003 11:48:03 -0700

Hi,

the listinfo is at

Regards,

-Rajeev

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 06 Oct 2003 15:38:43 -0400

Rajeev,

Re: IP Mobility Optimizations (Mob Opts)

I have a question regarding the last paragraph in the "research
group" charter.

>location) are outside the scopeof this group.

Although not explicitly stated, I think the underlying assumption
of the entire group is that TCP is assumed. That is, to maintain
a particular session during mobility (e.g., handoffs between wireless
links in different subnets) that the "IP address of the mobile node
endpoint" must remain the same for the duration of the session.
MIP or routing technology is fundamentally assumed here so that the
mobile node IP address remains the same as far as the other end host is
concerned. This is obvious from the "new route establishment" example
provided in the proposed charter.

If a MN were allowed to change/add/delete a new IP address without
breaking the session - the "new route establishment" in the charter
wording wouldn't need to occur! [Indeed, even neither MIP tunnels nor
routing updates would be required!] Thus another obvious "solution"
is to create another transport layer that doesn't have the rigid "one
IP address forever" constraint built in (as TCP does). Note that if one
had such a transport that a "new [Internet] architecture" would also
not be required (only normal IP forwarding is required). "Handovers"
across disparate wireless networks would also be less of an issue
(you only need to concern yourself with link layer and network layer
re-establishment).

If this group is indeed a "research group", I think other transports
without this constraint could be investigated. Or the group could
explicitly exclude such work.

I'm not against the charter work as described if the group only wants
to consider TCP for legacy reasons. However, this important TCP
constraint should be explicitly stated.

Regards,

Michael Ramalho

Michael A. Ramalho
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.941.708.4650
Cell: +1.941.544.2844

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 06 Oct 2003 14:33:05 -0700

Hi Michael,

thank you for your comments.

The focus here is not on creating a new transport abstraction
to handle IP mobility. Indeed, the implicit assumption is that
providing mobility support at IP layer helps all transports, and
not just TCP. For instance, improving handover latency could
benefit an application like VoIP.

The comments in-line below are perhaps dicsussion about transport
versus IP mobility, rather than the charter itself.

> provided in the proposed charter.

Well, there are tasks assuming MIP. However, no specific assumption
regarding what transport protocol is used is made. You are right that we
are not looking into transport protocol based solutions; the focus is on
IP Mobility that should serve all transports, not just TCP.

> (you only need to concern yourself with link layer and network layer

Another way to look at above is that MIP already provides the ability to
add a
new IP address (and hence delete the previous one) without breaking
the session for all transports!

Fast handovers on the other hand, looks into movement detection (into a
new subnet), IP address configuration and location update latencies.
Granted that each transport protocol can do its own location update,
once the need is detected, but the problem space is likely going to have
to address similar key issues (movement detection, new IP address
configuration,..). Furthermore, why/how should the remote
end-point believe the update from the MN that it has a new IP address ?
The MIP group, as you are aware, spent considerable time working
out a solution (Return Routability). Finally, how would you support
applications that do not use this new transport protocol ? If every
application
needs to use it, that would be a good candidate functionality at the
IP layer!

> explicitly exclude such work.

Put another way, the group would like to focus on IP as opposed to
transport mobility.

> constraint should be explicitly stated.

Improving handover latency, avoiding the
need for re-authentication during handovers, candidate router
selection are more general problems and should help all transport
protocols. So, I don't believe it is accurate to limit the focus to TCP.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 06 Oct 2003 19:00:47 -0700

> (including network-layer (re)authentication), and new route

These items are highly AAA-specific (both last-hop AAA and AAA backend).
Since this work is carried out in IRTF, I'd have suggested collaboration
with the AAAArch, but that group seems like going away. I don't know if
AAAArch would consider an extension to tackle this new problem, but at a
minimum its members' involvement in this work would be useful. And also
interaction with the IETF side: AAA, PANA, EAP WGs....

Alper