Subject: RE: [seamoby] Issue 2: Make IP messages uniform

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 27 Jun 2001 11:26:36 -0500

How does the newAR learn the IP address of the old AR?   

Ajoy: This can be sent in some layer 2 handoff request message 
from oldAR to newAR. There are other ways too. Please 
note that in cellular old BSC and new BSC exchange some 
information before MN is tuned to different frequency at the 
new BSC. 

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 10:19 AM
To: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'
Cc: 'Pat Calhoun'; [email-masked]
Subject: RE: [seamoby] Issue 2: Make IP messages uniform

> -----Original Message-----
> From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 10:24 AM
> To: 'Kulwinder Atwal'; 'Rajeev Koodli'
> Cc: 'Pat Calhoun'; [email-masked]
> Subject: RE: [seamoby] Issue 2: Make IP messages uniform
> 
> 
> 
> With Post-Connection CT the newAR knows nothing about the MN, 
> so it cannot
> use an L2 Trigger, becuase it does not know who the MN is, 
> where its Context
> may be, where its CoA maybe.
> 
> Ajoy: L2 trigger can provide MN-ID and oldAR address info 
> which can be 
> used by newAR to initiate CT. This is similar to the link 
> layer trigger at oldAR where 
> trigger will have to provide IP address of newAR.

How does the newAR learn the IP address of the old AR?    

- Kulwinder

> 
> 
> 
> -----Original Message-----
> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 10:23 PM
> To: 'Rajeev Koodli'; Kulwinder Atwal
> Cc: 'Pat Calhoun'; [email-masked]
> Subject: RE: [seamoby] Issue 2: Make IP messages uniform
> 
> 
> 
> 
> > -----Original Message-----
> > From: Rajeev Koodli [mailto:[email-masked]]
> > Sent: Monday, June 25, 2001 9:00 PM
> > To: Kulwinder Atwal
> > Cc: 'Pat Calhoun'; [email-masked]
> > Subject: Re: [seamoby] Issue 2: Make IP messages uniform
> > 
> > 
> > Kulwinder Atwal wrote:
> > 
> > >
> > > Additionally, a MN message on a high bandwidth link could 
> > be forwarded by
> > > the currentAR to the oldAR to request CT, and at the _same_ 
> > time a MN
> > > message could be forwarded by the currentAR to the ParentAR 
> > to affect a
> > > route change.
> > >
> > > The route change message may travel to a different entity 
> > along a different
> > > link, than the Context Transfer request message.  Having 
> > them happen in
> > > parrallel could significantly reduce Reactive Context Transfer.
> > >
> > >
> > 
> > Exactly. As soon as the MN detects that it has undergone 
> > handover, it sends a
> > message which includes BU as an encapsulation. The new AR 
> > sends the CT message
> > towards the old AR and the BU towards the mobility agent.
> > We proposed this (the message is SHIN) in our 
> -smoothv6-.txt draft (in
> > Pittsburgh IETF).
> 
> 
> Post-Connection Context Transfer:
> 
> Yes, I think it would take less time for the newAR to process 
> a message from
> the MN that contained the necessary info.  The newAR will 
> need to ask the MN
> some indentity info anyway like:
> 
> - Who are you?
> - Where is your Context located?  
> - Where is your CoA located?
> 
> Why can't the MN send the info needed to start a route change 
> request and a
> CT request in the same packet as its identity?
> 
> The MN is already there at the newAR with all the needed info.
> 
> With Post-Connection CT the newAR knows nothing about the MN, 
> so it cannot
> use an L2 Trigger, because it does not know who the MN is, 
> where its Context
> may be, where its CoA maybe.
> 
> It may turn out that the Context, and CoA are just too far 
> away to attempt a
> CT (Maybe the MN was moving while experiencing a loss in 
> connectivity).
> 
> - Kulwinder.
> 
> > 
> > Regards,
> > 
> > -Rajeev
> > 
> > 
> > 
>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 27 Jun 2001 09:41:54 -0700

> information before MN is tuned to different frequency at the 

there could be a static BSC ID -> IP Address table. Alternatively, some
protocol could be used to fetch this information (e.g. ldap). Or even
cooler, some SRV record, such as:

<bsc_id>._ct@domain

(of course, this assumes we know the domain, which is another problem
altogether :(

PatC