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

From: Pat Calhoun <[email-masked]>
Date: Thu, 21 Jun 2001 15:45:02 -0700

If I understand this particular issue properly, it is a request for a layer 3
message be created to initiate CT. However, I believe that the mobility management
used already has messages that initiate L3 handoffs, and these could be used
to initiate CT.

So, we have two options:
1. Create a message, which will introduce additional over the air latency in
   getting the CT initiated.
2. Retrofit in an existing MM solution, and perhaps create CT documents that 
   describe the CT profile for MM. Example, a document that states how the
   MIPv6 binding update can be used as a substitute for L2 signalling.

I, personally, much prefer option 2, but it does restrict CT to work only 
when an MM is present, which I believe would always be the case anyways.

PatC

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 27 Jun 2001 09:24:16 -0500

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.

-----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: Kulwinder Atwal <[email-masked]>
Date: Wed, 27 Jun 2001 11:18:54 -0400

> From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 10:24 AM
> To: 'Kulwinder Atwal'; 'Rajeev Koodli'

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

- Kulwinder

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 27 Jun 2001 12:28:00 -0500

Great. We are in agreement.
regards,
ajoy 

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 12:12 PM
To: Singh Ajoy-ASINGH1
Cc: 'Pat Calhoun'; 'Kulwinder Atwal'; 'Rajeev Koodli';
[email-masked]

On Wed, Jun 27, 2001 at 12:22:08PM -0500, Singh Ajoy-ASINGH1 wrote:
> Hello Pat: 
> You are right. There are several ways to accomplish this.
> I guess we just have to say that both in pre and post 
> connection cases, L2 trigger may be available at the new AR.
> We do not have to provide the exact trigger mechanism. 
> won't this work ? 

That is my preference. My issue was binding direction to a particular
scheme is the wrong approach.

PatC

---

From: kempf <[email-masked]>
Date: Wed, 27 Jun 2001 07:37:42 -0700 (PDT)

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

The L2 trigger contains either the L2 address of the old AR that
can be mapped to the IP address or its IP address directly, what's called an IP 
address identifier in draft-ietf-mobileip-lowlatencyhandoffs-ipv4-01.txt.

		jak

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 27 Jun 2001 16:42:19 -0500

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

> Sent: Wednesday, June 27, 2001 2:50 PM
> To: Kulwinder Atwal
> Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; 'Pat Calhoun';
> [email-masked]
> On Wed, Jun 27, 2001 at 02:58:01PM -0400, Kulwinder Atwal wrote:
> > > 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. 
> > > 
> > 
> > Yes, but in Bluetooth there is no L2 protocol message for 
> passing the oldAR
> > IP address.  I need an IP message.
> 
> It seems you have a chicken and egg problem. If you cannot figure out
> the IP address of the peer, how is a L3 message, being sent to an IP
> address that you don't know, going to help?

The MN does know the address of the oldAR, because it was just there.  The
MN tells the newAR the oldAR's IP address.

ajoy: Well this may work in some cases. Perhaps, we should also
keep the option of MN sending some layer 3 message whenever link layer
trigger is not available. I would rather prefer if Seamoby just defines
Context transfer protocol and implementer can choose the appropriate trigger
according to their need. 

The fastest way for it to find out is to ask the MN. The MN
makes the introduction after L2 setup.

ajoy: I do not think this assumption is always correct. Generally 
MN can exchange packet with new AR upon completion of following steps:

1. Radio link (L1) is established with new access network. 

2. The PPP or some other link layer protocol is negotiated which may be 
used for framing. You may argue PPP is not always 
required so perhaps this is not valid in those cases. 

3.In lossy link some protocol is required for error correction. 
I think most of the data link layer protocol requires synchronization between 
MN and network before it can exchange higher layer traffic. 

If step 2 and 3 are not present and RF bandwidth is more than wired bandwidth,
then perhaps your assumption is correct. 

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 27 Jun 2001 17:51:33 -0400

> Sent: Wednesday, June 27, 2001 5:42 PM
> To: 'Kulwinder Atwal'; 'Pat Calhoun'
> Cc: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; [email-masked]

In your network it may be this way, but for me:

Step 2 is not present.  step 1, 3 are one step.  In Post-Connection, there
is no wire for the MN to use.  The MN only has the wireless link to convey
the oldAR IP address.

- Kulwinder.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 27 Jun 2001 18:21:35 -0500

Ajoy: I did not mean that there is a wire between MN and 
access network. I meant any L2 message sent from oldAR to new AR over 
wired link will be faster than message from MN to newAR. I suppose 
you were claiming that fastest way to inform AR is to send layer 3 message 
from MN to new AR. 

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

- Kulwinder.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Jun 2001 11:05:28 -0500

Pat,

Do you mean a separate profile for each of the technologies that
you mentioned? I guess that would be too elaborate right now.
I am sure such profiles will pop up in future drafs.

Now if you are talking about a general abstract wireless tech. profile,
maybe that is more fitting?

Madjid

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Monday, June 25, 2001 5:06 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Pat Calhoun'; Kulwinder Atwal; [email-masked]
Subject: Re: [seamoby] Issue 2: Make IP messages uniform

On Mon, Jun 25, 2001 at 02:24:42PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> I prefer that we don't introduce explicit messaging, at least for now.
> Defining a general CT trigger that each technology can map onto should be
> good enough.
> 
> I am with option 2.

so if I understand correctly, perhaps a wireless technology profile would
be useful (e.g. 802.11 profile, mip profile (for non-l2 signalling),
cdma2000 profile)

PatC
> Madjid
> Sent: Friday, June 22, 2001 5:05 PM
> To: Kulwinder Atwal
> On Fri, Jun 22, 2001 at 02:39:35AM -0400, Kulwinder Atwal wrote:
> > 
> > 
> > > Sent: Thursday, June 21, 2001 6:45 PM
> > > To: [email-masked]
> > > Subject: [seamoby] Issue 2: Make IP messages uniform
> > > 
> > > 
> > The newAR will need to request CT from a peer AR.  Are you suggesting
that
> > MIPv6 uses the Peer-to-Peer model such that the oldAR will hold the CoA?
> > Or, is it quite possible that the CoA and the oldAR may not be
co-located?
> > 
> > Also, if the MN to AR link is 55 Mbps, as Charlie has suggested, for
some
> > technology do we really care about over the air latency for a few bytes?
> 
> no, but look at option 2 below. My point is that there is already some
> signalling, either at L2 (e.g. signal strength), or at L3 (binding
update).
> Why require another message, since we've already agreed to co-locate with
> other MM protocols.
> 
> > 
> > Of course some lower bandwidth technologies will use an L2 Trigger at
the
> > newAR, but the choice is really technology specific.
> 
> right, so we allow for L2 or L3. The question is whether CT needs to
define
> another message, or if an existing one can be used.
> 
> I much prefer the latter.
> 
> > 
> > Further, I would hope that if the CoA were not co-located with the oldAR
> > that some time could be saved by sending a change in route to the parent
AR
> > on the newAR-to-ParentAR link, while at the _same_ time sending a
message to
> > the oldAR on the oldAR-to-newAR link to transfer Context.
> > 
> > Since time is very critical in Reactive Context Transfer it would seem
like
> > a very useful method to reduce latency.
> 
> right, but I don't see how a CT L3 message would be faster, and therefore
enable
> reactive CT, than would a binding update.
> 
> > 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
> ok, this is the one and first argument that I've heard that could convince
> me to agree to MN-initiated CT.
> 
> PatC