Subject: RE: [seamoby] updated problem statement

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 2 May 2001 20:36:48 -0400

Very well written.  I just read it for the first time.  Good job!

- Cheers, Kulwinder.

> -----Original Message-----
> From: Phil Roberts [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 7:23 PM
> To: [email-masked]'
> Subject: [seamoby] updated problem statement
> 
> 
> 
> I just submitted this to internet drafts.  Text included below.
> Incorporated changes from several people including most of michael's
> comment.  
> 
> 
>  
> 
>    Personal                                                P. Roberts 
>                                                            Compiler 
>    Internet Draft                                     
>    Title: draft-proberts-localsubnetmobility-         
> problem-00.txt 
>    Category: Informational                                  May 2001 
>    Expires : November 2001                            
>     
>     
>     
>                         Local Subnet Mobility Problem Statement 
>                     
> <draft-proberts-localsubnetmobility-problem-00.txt> 
>     
>     
>    Status of This Memo 
>     
>     
>    This document is an Internet-Draft and is in full conformance with 
>    all provisions of Section 10 of RFC2026.  Internet-Drafts 
> are working 
>    documents of the Internet Engineering Task Force (IETF), 
> its areas, 
>    and its working groups.  Note that other groups may also 
> distribute 
>    working documents as Internet-Drafts. 
>     
>    Internet-Drafts are draft documents valid for a maximum of 
> six months 
>    and may be updated, replaced, or obsoleted by other documents at 
>    any time.  It is inappropriate to use Internet-Drafts as reference 
>    material or to cite them other than as "work in progress." 
>     
>    The list of current Internet-Drafts can be accessed at: 
>         http://www.ietf.org/ietf/1id-abstracts.txt 
>    The list of Internet-Draft Shadow Directories can be accessed at: 
>         http://www.ietf.org/shadow.html. 
>     
>     
>                                  Abstract 
>     
>    This document specifies a problem statement for 
> investigation within 
>    the IRTF.  There are a couple of seemingly unrelated problems that 
>    have led investigators to converge on the desirability of 
>    implementing a routing protocol whose purpose is to allow a mobile 
>    node to retain connectivity via its current IP subnet 
> while it moves 
>    within the scope of the micro mobility domain. In general 
> this domain 
>    is expected to be contained within an autonomous system so that 
>    global aggregation of subnets is still preserved. An additional 
>    benefit of the protocols is that mobile nodes may more 
> quickly react 
>    to failed links.  The problem is to investigate the limits 
> and issues 
>    with using (a) new protocol(s) to implement per node routes to 
>    facilitate better the movement of nodes and recovery of 
> the network 
>    in the presence of failed links or routers.  The document 
> is a brief 
>    statement of the problem to be investigated with 
> references to lots 
>    of other work that has been done already by many others in 
> the area.   
>      
>     
>   
>                                                               
>        1 > 
> Internet Draft Local Subnet Mobility Problem Statement       May 2001 
>  
>  
>     
>     
> 1. Introduction 
>     
>    The design of Internet routing has evolved largely based on the 
>    assumption that most end systems are stationary. As the idea of 
>    mobile devices came along, Mobile IP provided an easy 
> migration path 
>    for supporting end system mobility without significant change or 
>    impact to the Internet infrastructure. This was achieved 
> primarily by 
>    placing the support for routing to mobile devices on the 
> end systems 
>    and at a limited number of centralized points within the 
>    infrastructure, effectively "hiding" the end system 
> mobility from the 
>    infrastructure routing protocols. However, as we anticipate the 
>    desire to support real-time traffic flows to mobile 
> devices and the 
>    possibility that mobile devices may become a significant 
> portion of 
>    all Internet end nodes, investigation of alternative designs merit 
>    consideration. Many investigators in this area have converged on 
>    solutions that propose the use of local subnet mobility routing to 
>    support mobility within a limited domain, effectively exposing the 
>    mobility of end systems to the routers. 
>     
>    This draft represents a problem statement to enable 
> investigation of 
>    how a local subnet mobility routing protocol can be employed to 
>    enable mobility and fast network recovery.  It is a 
> problem statement 
>    based on a lot of work done in attempting to provide low latency 
>    handover in mobile networks and fast recovery in networks 
> with fast 
>    recovery requirements.  Please see the reference list for 
> a large set 
>    of work that has been done in the past along these lines. 
>     
>    A good summary of the problem as it pertains to network 
> recovery is 
>    [MC].  The micromobility design team of the seamoby working group 
>    produced a problem statement also [SMM].  See the 
> reference list for 
>    lots of previous work that has been done especially in the area of 
>    mobility with alternate proposals from Mobile IP. 
>     
> 2. Problem Statement 
>     
>    This section proposes questions that have led to a 
> perceived need for 
>    investigation of node routing within the IRTF.  Why is there a 
>    perceived need for a non-tunnel-based routing solution for 
> mobility?  
>    While Mobile IP provides transparency of the mobility to 
>    correspondent nodes communicating with hosts on the mobile 
> network, 
>    Mobile IP does not provide transparency for any state contained 
>    within routers along the paths from correspondent nodes and the 
>    mobile node's home agent. That is, state in routers which is 
>    dependent on the stability of the source or destination address in 
>    the IP header will be negatively impacted by the mobile 
> node's change 
>    of care of addresses. For example, when a mobile node changes its 
>    care of address, the mobile node's current reservation 
> would require 
>    that the filter specs be updated with the new care of address. By 
>    instead treating the mobility as a topology change within 
> the local 
>    area, these unpleasant second order effects can be avoided.  
>     
>   
> Design Team                                                   
>        2 > 
> Internet Draft Local Subnet Mobility Problem Statement       May 2001 
>  
>  
> 2.1 Problem One  
>     
>    There are applications that involve supporting real-time traffic 
>    flows to end devices that are mobile.  These applications require 
>    that there be minimal (ideally no) interruption to the 
> packet flows 
>    and that these flows need to preserve the existing QoS and 
> security 
>    characteristics as the end station moves.  In addition the 
> movement 
>    of the end devices should not cause excessive signaling in the 
>    network as the devices move.  Such applications often also run on 
>    networks in which link failures or router failures can cause a 
>    significant service disruption.  Is it possible to use a similar 
>    protocol to allow for faster restoration of service during link 
>    failures.  Could such mobility requirements and fast restoration 
>    requirements be met in a way that is more efficient and 
> simpler than 
>    approaches based on Mobile IP and current intradomain routing 
>    protocols by using a routing protocol that implements local subnet 
>    mobility within a limited scope within the network?  What 
> would the 
>    limits of such a solution be in terms of scaling?  
> Specifically how 
>    many nodes could be supported across what kind of network 
> breadth and 
>    depth at what cost of complexity in the routers around the edge of 
>    such a network?  Is it possible to meet traffic engineering 
>    requirements using such a protocol?  Could it simplify 
> management of 
>    QoS in the part of the network where mobility is most 
> readily felt? 
>     
> 2.2 Problem Two 
>     
>    One of the primary principles of the Internet has been end-to-end  
>    communication. Most (if not all) of the protocols running over IP 
>    have been designed with end-to-end signaling in mind.  Currently, 
>    changes due to mobility induce unwanted end-to-end signaling. This 
>    may cause applications running over IP to fail due to delay and 
>    latency induced by unwanted signaling.  Security, QoS and AAA 
>    signaling all suffer due to this.  Could a local subnet mobility 
>    protocol aid in this respect? 
>     
> 2.3 Problem Three 
>     
>    Why is there a need for an investigation of it in the IRTF rather 
>    than a direct move to work on a standard within a working group of 
>    the IETF?  The area directors overseeing the activities of the 
>    seamoby working group and the mobile-ip working group have raised 
>    questions about the scale of local subnet mobility routing and the 
>    potential need to introduce both another routing protocol 
> and another 
>    mobility protocol. A comparison with existing mobility 
> management and 
>    routing protocols are involved in making such an 
> assessment both in 
>    terms of relative scalability, performance, and complexity. 
>     
>     
> 3. Acknowledgements 
>     
>    The compiler would like to acknowledge all the 
> contributors who have 
>    produced work relating to host routing for the various problems.   
>     
>   
> Design Team                                                   
>        3 > 
> Internet Draft Local Subnet Mobility Problem Statement       May 2001 
>  
>  
>     
> References 
>     
>     [MC] M. Scott Corson, A. O'Neill, G. Tsirtsis.  IP Fast 
> Restoration.  
> Work in Progress.  Draft-corson-fastrestore-00.txt, November 2000. 
>     [SMM] J. Loughney, et. al.  "SeaMoby Micromobility Problem 
> Statement."  Work in Progress.  Draft-ietf-seamoby-mm-problem-01.txt, 
> February 2001. 
>     [FHO] G. Tsirtsis, et. al.  "Fast Handovers for Mobile 
> Ipv6."  Work 
> in Progress.  Draft-ietf-mobileip-fast-mipv6-00.txt, February 2001. 
>     [MT] M. Thomas.  "Analysis of Mobile IP and RSVP Interactions."  
> Work in Progress.  Draft-thomas-seamoby-rsvp-analysis-00.txt, 
> February 
> 2001. 
>     [CI] Z. Shelby, et. al.  "Cellular IP v6."  Work in Progress.  
> Draft-shelby-seamoby-cellularipv6-00.txt, November 2000. 
>     [HSR] A. O'Neill.  "Host Specific Routing."  Work in Progress.  
> Draft-oneill-li-hst-00.txt, November 2000. 
>     [IMMP] A. Campbell and J. Gomez.  "IP Micro-mobility Protocols."  
> ACM SIGMOBILE Mobile Computer and Communications Review (MC2R), 2001, 
> available at http://www.comet.columbia.edu/micromobility. 
>     [CIP] Campbell, et. al.  "Cellular IP."  Work in Progress.  Draft 
> expired, but available at 
http://www.comet.columbia.edu/micromobility. 
    [HAW] Ramjee, et. al.  "Hawaii."  Work in Progress.  Draft expired, 
but available at http://www.comet.columbia.edu/micromobility. 
    [EMA] M. Scott Corson, and Alan O'Neill. An Approach to Fixed/Mobile 
   Converged Routing. University of Maryland, Institute for Systems 
Research, 
   Technical Report, TR 2000-5. 2000. available at 
   http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml 

Addresses 
    
   The compiler of this document is: 
    
   Phil Roberts, Megisto Systems, Inc., [email-masked] 

Design Team                                                          4

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 4 May 2001 04:57:50 -0400

> From: James Kempf [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 12:14 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [seamoby] updated problem statement
> 
> 
> Hi Phil,
> 
> The problem statement looks good, I've got just one comment. There
> seems to be an implicit assumption in the statement that the routing
> protocol which IRTF will come up with will be based on a standard
> wired subnet routing model. I think this assumption is 
> somewhat limiting.

It is not limiting.  It is quite the opposite.  Subnets allow route
aggregation, and thus scalability.

> Remember, we are talking about research. The model might end up
> being something between the completely ad hoc MANET model and
> the standard subnet model.

MANET approaches do not seem too focused on scalability.

> 
> So, I'd suggest changing "subnet" to "network" or some other neutral
> term.

Subnet is an useful term.  It allows devices that move together to be
grouped into a mobile subnet.  

Take for example a collection of devices installed into a vehicle.  Rather
than doing handoff for each device in a vechicle, the vechicle can be
treated as a mobile subnet.

The entire subnet can be handed off with just one subnet prefix.  
It has the added advantage that the subnetted devices do not have to be
"mobile aware".

A collection of PCs and other devices mounted in a train would never have to
know that they were mobile.

The idea of a subnet maps very well with the idea of a "Reference Frame" for
a 'body in motion' in Physics.
A mobile subnet extends the Physics idea of Relative Motion to IP. 

- Kulwinder.

> 		jak

---

From: James Kempf <[email-masked]>
Date: Fri, 4 May 2001 07:43:07 -0700 (PDT)

Hi Kulwinder,

While I appreciate the points you make, the point I was trying to
make was that this is supposed to be a problem statement about
a research activity. In research, it is best to let such questions
open to encourage out of the box thinking. I'm sure you and I
can exchange email back and forth on the list examining cases
and discussing this and that, but I would rather see Abha and
her team get a clear, unconstrained statement of the problem
and let them go at it. 

		jak
		
>From: Kulwinder Atwal <[email-masked]>
>To: "'James Kempf'" <[email-masked]>, [email-masked], 
[email-masked]
>Subject: RE: [seamoby] updated problem statement
>Date: Fri, 4 May 2001 04:57:50 -0400 
>
>
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 7 May 2001 14:12:20 -0500

I likes it.

-----Original Message-----
From: Phil Roberts [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 6:23 PM
To: [email-masked]'
Subject: [seamoby] updated problem statement

 

   Personal                                                P. Roberts 
                                                           Compiler 
   Internet Draft                                     

   Status of This Memo 

   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working 
   documents of the Internet Engineering Task Force (IETF), its areas, 
   and its working groups.  Note that other groups may also distribute 
   working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at 
   any time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

                                 Abstract 
    
   This document specifies a problem statement for investigation within 
   the IRTF.  There are a couple of seemingly unrelated problems that 
   have led investigators to converge on the desirability of 
   implementing a routing protocol whose purpose is to allow a mobile 
   node to retain connectivity via its current IP subnet while it moves 
   within the scope of the micro mobility domain. In general this domain 
   is expected to be contained within an autonomous system so that 
   global aggregation of subnets is still preserved. An additional 
   benefit of the protocols is that mobile nodes may more quickly react 
   to failed links.  The problem is to investigate the limits and issues 
   with using (a) new protocol(s) to implement per node routes to 
   facilitate better the movement of nodes and recovery of the network 
   in the presence of failed links or routers.  The document is a brief 
   statement of the problem to be investigated with references to lots 
   of other work that has been done already by many others in the area.   

                                                                     1 

    
1. Introduction 
    
   The design of Internet routing has evolved largely based on the 
   assumption that most end systems are stationary. As the idea of 
   mobile devices came along, Mobile IP provided an easy migration path 
   for supporting end system mobility without significant change or 
   impact to the Internet infrastructure. This was achieved primarily by 
   placing the support for routing to mobile devices on the end systems 
   and at a limited number of centralized points within the 
   infrastructure, effectively "hiding" the end system mobility from the 
   infrastructure routing protocols. However, as we anticipate the 
   desire to support real-time traffic flows to mobile devices and the 
   possibility that mobile devices may become a significant portion of 
   all Internet end nodes, investigation of alternative designs merit 
   consideration. Many investigators in this area have converged on 
   solutions that propose the use of local subnet mobility routing to 
   support mobility within a limited domain, effectively exposing the 
   mobility of end systems to the routers. 
    
   This draft represents a problem statement to enable investigation of 
   how a local subnet mobility routing protocol can be employed to 
   enable mobility and fast network recovery.  It is a problem statement 
   based on a lot of work done in attempting to provide low latency 
   handover in mobile networks and fast recovery in networks with fast 
   recovery requirements.  Please see the reference list for a large set 
   of work that has been done in the past along these lines. 
    
   A good summary of the problem as it pertains to network recovery is 
   [MC].  The micromobility design team of the seamoby working group 
   produced a problem statement also [SMM].  See the reference list for 
   lots of previous work that has been done especially in the area of 
   mobility with alternate proposals from Mobile IP. 
    
2. Problem Statement 
    
   This section proposes questions that have led to a perceived need for 
   investigation of node routing within the IRTF.  Why is there a 
   perceived need for a non-tunnel-based routing solution for mobility?  
   While Mobile IP provides transparency of the mobility to 
   correspondent nodes communicating with hosts on the mobile network, 
   Mobile IP does not provide transparency for any state contained 
   within routers along the paths from correspondent nodes and the 
   mobile node's home agent. That is, state in routers which is 
   dependent on the stability of the source or destination address in 
   the IP header will be negatively impacted by the mobile node's change 
   of care of addresses. For example, when a mobile node changes its 
   care of address, the mobile node's current reservation would require 
   that the filter specs be updated with the new care of address. By 
   instead treating the mobility as a topology change within the local 
   area, these unpleasant second order effects can be avoided.  

Design Team                                                          2 

2.1 Problem One  
    
   There are applications that involve supporting real-time traffic 
   flows to end devices that are mobile.  These applications require 
   that there be minimal (ideally no) interruption to the packet flows 
   and that these flows need to preserve the existing QoS and security 
   characteristics as the end station moves.  In addition the movement 
   of the end devices should not cause excessive signaling in the 
   network as the devices move.  Such applications often also run on 
   networks in which link failures or router failures can cause a 
   significant service disruption.  Is it possible to use a similar 
   protocol to allow for faster restoration of service during link 
   failures.  Could such mobility requirements and fast restoration 
   requirements be met in a way that is more efficient and simpler than 
   approaches based on Mobile IP and current intradomain routing 
   protocols by using a routing protocol that implements local subnet 
   mobility within a limited scope within the network?  What would the 
   limits of such a solution be in terms of scaling?  Specifically how 
   many nodes could be supported across what kind of network breadth and 
   depth at what cost of complexity in the routers around the edge of 
   such a network?  Is it possible to meet traffic engineering 
   requirements using such a protocol?  Could it simplify management of 
   QoS in the part of the network where mobility is most readily felt? 
    
2.2 Problem Two 

2.3 Problem Three 
    
   Why is there a need for an investigation of it in the IRTF rather 
   than a direct move to work on a standard within a working group of 
   the IETF?  The area directors overseeing the activities of the 
   seamoby working group and the mobile-ip working group have raised 
   questions about the scale of local subnet mobility routing and the 
   potential need to introduce both another routing protocol and another 
   mobility protocol. A comparison with existing mobility management and 
   routing protocols are involved in making such an assessment both in 
   terms of relative scalability, performance, and complexity. 

3. Acknowledgements 
    
   The compiler would like to acknowledge all the contributors who have 
   produced work relating to host routing for the various problems.   

Design Team                                                          3 

References 
    
    [MC] M. Scott Corson, A. O'Neill, G. Tsirtsis.  IP Fast Restoration.  
    [FHO] G. Tsirtsis, et. al.  "Fast Handovers for Mobile Ipv6."  Work 
Work in Progress.  Draft-thomas-seamoby-rsvp-analysis-00.txt, February 
expired, but available at http://www.comet.columbia.edu/micromobility. 

Addresses 

  
Design Team                                                          4