Subject: RE: [Seamoby] Minutes for Meeting at IETF 53

From: "Glenn Morrow"<[email-masked]>
Date: Mon, 15 Apr 2002 15:55:47 -0500

Excuse me for not being at the WG meeting due to a conflict but I do have
some comments on the meeting minutes.

[The Issue]
It seems that the minutes indicate that people have somehow come to a
conclusion that there is no need for access routers to divulge that they are
geographically adjancent to themselves via the IP infrastructure. The
minutes also seem to indicate that the mobile alone should be the only way
to pass addresses of CARs to source ARs.

[Technical Questions]
O.K. If this is true then how will a mobile pass this information to their
source AR if the mobile only has one NIC and that NIC is only capable of
listening to one media at once? 

Even if the NIC can handle multiple technologies what if it can't do the
multiple technologies simulateneously?

[Business Questions]
What is the legacy NICs are not capable of double-communication as described
above?

What if there are two or more NICs but it chews up the batteries of the
device when both are in use? 

What about the cost ramification and therefore market potential of devices
with more than one or a multimode NIC?

Are these devices just destined to have crapy handoff, low battery life, or
just be expensive?

Of course your existing routers don't do this sort of thing and gee it might
cost some money to develop the new functions - ya - that's because IP wasn't
never designed to deal with node mobility - ya - that's what this working
group is here for, I thought.

[Non-technical commentary - atheism] 
The end to end thing is always a good thing to think of BUT keep in mind
that they only reason you do things to the network if to do something the
hosts can't do or its less expensive to deploy. Nobody ever wants to add
something to the network if they can avoid it. I just think that this might
be one of those cases when you can't avoid it. The IP addresses are not L2
stuff.

[Administrative Commentary]
If the WG just doesn't want to deal with the administrative hassle of making
network based CAR discovery automatic or zero-conf-like similar to dynamic
routing, then just say all we want to do is make this configurable at this
time or spin it off into another WG that does want to agree on a way to
dynamically convey this information. Also as I recall, the early antagonists
of dynamic routing also said it wouldn't scale. Gee you could also pawn it
off on AAA. Whoaa - hot potata - hot patata.

Keep in mind the excuses and needs for dynamic routing are analogous to the
excuses and needs for dynamic CAR discovery. i.e. sometimes you need it and
want it and sometimes ya don't.

Hope this helps,

Glenn

[Solve it for routers and the hosts are a breeze]
p.s. you'll probably bump into the same problem again in the Monet WG where
the correct thing to do should be pretty blatent.

---

From: "Glenn Morrow"<[email-masked]>
Date: Mon, 15 Apr 2002 15:55:47 -0500

[The Issue]

[Technical Questions]

[Business Questions]

Hope this helps,

Glenn

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 16 Apr 2002 14:56:42

Hi Glenn:

See some comments below:

>From: "Glenn Morrow"<[email-masked]>
>To: [email-masked]
>Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>Date: Mon, 15 Apr 2002 15:55:47 -0500
>

[HC] I agree that this is a genuine technical problem. What I would really 
like to understand is whether the above is a relevant case for CAR discovery 
or we simply neglect it and focus only on two physical interfaces case. I 
raised this question before, but we have not had much discussion on it. In 
any case, address translation part of CARD will be required in this case for 
fast handoff support.

----clip-----------------------
>be one of those cases when you can't avoid it. The IP addresses are not L2

[HC] Also, in handoff philosophy in general, access routers do maintain 
state and transfer it from AR to AR, for example context transfer. If that 
is OK with end-to-end principle, then it seems that CARD protocol whose 
operations are confined to ARs (and of course MNs) on the periphery of the 
network should fit in the principle as well.

>the correct thing to do should be pretty blatent.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 16 Apr 2002 10:29:34 -0500

Hemant - you snipped the business rationale for why it is relavant. Keep in
mind that no one wants to or can prevent the mobile from doing the selection
when it can. The problem is that there is a plethora of existing host NICs
that can't for even intra-technology handoff. Also keep in mind that smooth
handoff uses a network resource. It is therefore pretty evident that the
owners of the facilities may wish to have a say in how those resources are
used. If the mobile is capable of seeing things the without the help of the
network or rather resource policy of the network, the mobile still has the
option to not use the resources.

Are you saying the IETF should only deal with smooth handover and CAR
discovery for inter-access-technology handoffs? This would mean that every
single access technology would have to re-invent smooth handoff and access
specific CAR discovery. It would also eliminate the possibility of
cost-reduced multimode NICs.

If people are concerned about duplication of standardized IEEE technologies
then bring these technologies into the IETF if they can be made to work for
all access technologies.

If you just handle the double NIC case then you have not really solved the
whole problem and so vendors will make incompatible proprietary solutions.
All you will have succeeded in doing is protecting marketshare of the
proprietary solutions. 

I hope you see the point. To not handle these other "deployed" cases would
be seen by me as a protectionist tactic to delay standardization.

Thanks,

Glenn

> -----Original Message-----
> From: Hemant Chaskar [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 9:57 AM
> To: [email-masked]
> >conclusion that there is no need for access routers to 
> divulge that they 
> >are
> >If the WG just doesn't want to deal with the administrative 
> hassle of 
> >making

---

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 16 Apr 2002 10:29:34 -0500

Thanks,

Glenn

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 16 Apr 2002 20:55:09 +0200

> divulge that
 > they
 > > >O.K. If this is true then how will a mobile pass this 
 > information to
 > their
 > > >source AR if the mobile only has one NIC and that NIC is 
 > only capable
 > of
 > In a single interface handoff situation, Layer 2 typically 
 > delivers the
 > AP or AR L2 identifier to which the MN will be handed over. This
 > information is required (by the MIP fast handover algorithms) at the
 > MN's AR. So the issue is fairly simple: the AR must be able to do
 > reverse address translation in order that it can contact the 
 > other AR.

This is not really applicable to Mobile-Initiated MIP Fast Handoff.
In Mobile-initiated we consider the useful case where the MN can recover
the CAR IP address/es from the L2 trigger. The MN then sends a Proxy
Router Solicitation (RtSolPr) to its curent AR containing one or more CAR
IP addresses. This means that the source AR already gets the CAR addresses.
So we can do without the AR doing translation or discovering geographical
adjacency. The MN can pass these CAR address/es to the source AR for both
single and multiple-interface MNs. So I think that the conclusion from the
meeting is compatible with MIP Fast Handoffs.

/Karim

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 16 Apr 2002 21:17:38 +0000

Hi James:

What do you mean when you say that hearing multiple L2 is equivalent to 
inter-technology case? I do not get the point. Why can't the MN listen to 
different L2 beacons of the same technology? I guess it can, and hence, it 
still needs to chose one among them for handoff. Then the issue is exactly 
the same as Glenn raised for single NIC case: How to get capabilities 
without letting go the old connection? Of course, I am assuming that these 
L2's have comparable signal strengths.

Hemant

>From: "James Kempf" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
>Date: Tue, 16 Apr 2002 10:26:45 -0700
>
>
> > >[The Issue]
> > >conclusion that there is no need for access routers to divulge that
>they
> > >are
>In a single interface handoff situation, Layer 2 typically delivers the
>reverse address translation in order that it can contact the other AR.
>Capabilities aren't involved, except to the extent that the MN can hear
>multiple L2s and make the decision. But this is exactly the same as for
>the intertechnology case.
>
>             jak
>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 16 Apr 2002 21:25:12 +0000

Hi Karim:

See at the end of email:

>From: "Karim El-Malki (ERA)" <[email-masked]>
>To: "'James Kempf'" <[email-masked]>,   Hemant Chaskar  
><[email-masked]>, [email-masked]
>Date: Tue, 16 Apr 2002 20:55:09 +0200
>
>  > > >[The Issue]

[HC] I am wondering, if this useful case is genral enough. In other words, 
can MN always get IP addresses from AP beacons (or L2 triggers) without 
having to acquire connectivity with AP. More so, in single NIC case.

Also, could you please say what conclusion you are referring to.

Hemant

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 16 Apr 2002 21:25:12 +0000

Hi Karim:

Hemant

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 11:50:13 +0200

The reason I sent my previous email was that I got the feeling
from this thread that there is focus on providing a solution for
the network-centric case (i.e. the network handles CAR discovery
and the MN isn't involved). I wanted to point out that this
solution would not be applicable to the mobile-centric case and
clarify that this case is supported by MIP (v4 and v6) fast
handoffs.

From the IETF meeting there was a majority who wanted to go for
the mobile-centric case (i.e. where the mobile is involved and
decides). Following Steve's presentation I think that became
quite clear. So, why are there discussions about doing a solution
which is meant for the network-centric case only? This solution
wouldn't apply to the mobile-centric case. That's what I was meant
to ask in my last email.

/Karim

 > Karim,
 > 
 > But it is applicable to network initiated handoff. And there are two
 > algorithms, one in which the access router sends a PrxyRtAdv 
 > to the MN
 > and one in which the MN is switched (for FMIPv4).
 > 
 >             jak
 > 
 > ----- Original Message -----
 > To: "'James Kempf'" <[email-masked]>; "Hemant Chaskar"
 > <[email-masked]>; <[email-masked]>
 > Sent: Tuesday, April 16, 2002 11:55 AM
 > >  > > >minutes also seem to indicate that the mobile alone should be
 > the
 > >  > only way
 > >  > > [HC] I agree that this is a genuine technical problem. What I
 > would
 > >  > really
 > >  > > like to understand is whether the above is a relevant case for
 > CAR
 > >  > discovery
 > >  > > or we simply neglect it and focus only on two 
 > physical interfaces
 > >  > case. I
 > >  > > raised this question before, but we have not had much 
 > discussion
 > on
 > >  > it. In
 > >  > > any case, address translation part of CARD will be required in
 > this
 > >  > case for
 > >  > > fast handoff support.
 > >  > >
 > >  >
 > > Router Solicitation (RtSolPr) to its curent AR containing 
 > one or more
 > CAR
 > > adjacency. The MN can pass these CAR address/es to the 
 > source AR for
 > both
 > > single and multiple-interface MNs. So I think that the 
 > conclusion from
 > the

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 12:13:57 +0200

> one or more CAR
 > source AR for both
 > conclusion from the

[KEM] If you get a trigger at the MN you are somehow told
that you have to move and this could contain the network's desired
place where you should move (if it's multi-technology then one network
may not know all that is possible). Here it is assumed that these are
IP addresses or that the IP addresses can be easily recovered. The MN
collects the full list of CAR addresses and decides. At least that's
what I understood people wanted at the last meeting. Do you think it
is not generic enough since it relies on IP addresses recovered from
triggers?

 > Also, could you please say what conclusion you are referring to.

[KEM] I'm referring to the discussion about mobile-centric vs network-centric
approaches related to Steve's presentation. I believe there was a
consensus on mobile-centric, which favours a CAR discovery solution where the
MN is involved and takes the decisions.

/Karim

---

From: [email-masked]
Date: Wed, 17 Apr 2002 10:06:22 -0400

Hi Karim,

-----Original Message-----
From: ext Karim El-Malki (ERA) [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 6:14 AM
To: 'Hemant Chaskar'; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Minutes for Meeting at IETF 53

[DOT] How did the trigger get the IP addresses? Is this also possible
in the inter-technology/inter-domain case? If so, is CAR discovery
then still necessary? Or in other words, isn't your magic trigger
with the IP addresses of places the network wants me to go not exactly 
the list of possible GAARs from a network point of view? Though it is
still not clear to me how this trigger is provided.

[DOT] Steve's presentation has already had a large influence on the requirements 
discussion regarding the involvement of the MN, which has been emphasized in the 
requirements. However, concluding now further from his presentation that the WG is 
in favour regarding certain network-centric (what is that exactly BTW?) or mobile-centric 
approaches does not put the WG in the position it is supposed to be. More precisely, believing 
in consensus doesn't make it a consensus. I cannot remember that there was a consensus call 
during the meeting or after. There was explicitly a question whether to let go the network 
case, which was only supported by three hands. There was also a comment from Steve's side 
that "There are times when information from the ARs might help the mobile node make a better 
decision.  I wasn't advocating killing this work, but it just needs to fit into a basic model.".
Let us simply see whether network assistance (if that's what you mean with network-centric)
solutions would fly under the constraint of the current requirements (which emphasizes
MN's role in this process). 

Regards,

Dirk

---

From: [email-masked]
Date: Wed, 17 Apr 2002 10:06:22 -0400

Hi Karim,

-----Original Message-----
From: ext Karim El-Malki (ERA) [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 6:14 AM
To: 'Hemant Chaskar'; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Minutes for Meeting at IETF 53

Regards,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 17 Apr 2002 14:45:38

Hi James:

If there are more than one L2 beacons available (of comparable signal 
strength), probably governed by different ARs, how do we choose? I do not 
have problem choosing randomly, but just want to confirm if this is the way 
we want to proceed.

There is no doubt that handoff is necessary as old link will fade, but you 
still have choice as to which new beacon to hold on to.

Hemant

>Date: Tue, 16 Apr 2002 15:44:48 -0700
>
>Right, that's what I'm saying. There is one case where the MN needs to
>choose, and the other where the MN and AR get an L2 address and don't
>have a choice. The handover happens because, if not, the power will fade
>and the MN loses link connectivity.
>
>The former case might require capabilities, the latter just requires
>cross link ARP.
>
>             jak
>
>From: "Hemant Chaskar" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Tuesday, April 16, 2002 2:17 PM
> > > > >O.K. If this is true then how will a mobile pass this information
>to
> > >their
> > > > >source AR if the mobile only has one NIC and that NIC is only
>capable
> > >of
> > > > raised this question before, but we have not had much discussion
>on
> > >it. In
> > Join the world's largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com
> >
> >
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 17 Apr 2002 14:56:31

Hi Karim:

>To: "'Hemant Chaskar'" <[email-masked]>, [email-masked],   
>[email-masked]
>Date: Wed, 17 Apr 2002 12:13:57 +0200
>

[HC]I think the issue was raised about single NIC case. So, if you are 
saying that in general single NIC case, IP addresses will always be 
available in beacons (L2 triggers), then our problem becomes simpler, that 
is great. I am still looking for answer to question: Is capability discovery 
required in this case and how to do this? When you receive multiple L2 
becons (and hence multiple IP addresses from those beacons from L2 triggers 
that you have in mind), which one to choose still remains a question. Or, 
will L2 triggers also include capability set of ARs?

Also, another issue that was raised for both single and multiple NIC case 
was about power and bandwidth considerations in receiving capabilities at 
MN. Again, if that is not a concern then our problem becomes simpler.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 17 Apr 2002 15:21:39 -0400

Hello Karim,
First, I don't think that Steve Deering said anything about excluding
the network from CAR discovery. All he said (AFAIK) was that the MN's
preferences must be satisfied in the decision of selecting the TAR.
Now that doesn't imply MN based CAR discovery: that the MN should receive 
all the capabilities and GAAR IDs and then make the decision.

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 17 Apr 2002 15:21:39 -0400

Hello Karim,

Regards,
Govind.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 18 Apr 2002 16:08:39 +0200

Since a couple of emails disagreed with me about this point,
I'm sending one email reply to clarify. As in the minutes,
the concept was that the only entity which can find out
all the possible CARs is the MN (that's what I mean by mobile-centric).
The network could give hints, but it is the MN that has the complete
view and decides. That's what I understood from the meeting and there
seemed to be consensus on this. Hope we agree so far. The network
could assist in CAR discovery (e.g. it's L2 can help in anticipating
the movement). That's also somewhere in the minutes. In fact what I
said below was that I couldn't understand why there was focus on a
network-centric solution (i.e. where the MN is NOT involved). I wasn't
ruling out network involvement, but I couldn't understand why there
was work on ARs only doing CAR discovery. Hope my point is more clear
now. Maybe I misinterpreted some emails and people are in agreement
with this. I think Dirk's email at least was in line with what I
have above (i.e. we need to focus on the MN's role and allow the
network to assist where needed).
Rgds
/Karim

 > From: Govind Krishnamurthi [mailto:[email-masked]]
 > Sent: den 17 april 2002 21:22
 > To: [email-masked]; [email-masked];
 > [email-masked]; [email-masked]
 > >  > >  > information is required (by the MIP fast handover 
 > algorithms) at
 > >  > the
 > >  > > In Mobile-initiated we consider the useful case where 
 > the MN can
 > >  > recover
 > >  > > IP addresses. This means that the source AR already 
 > gets the CAR
 > >  > addresses.

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 18 Apr 2002 11:18:44 -0400

My observation on this MN centric approach is that, to me, there
are logical flaws. Let me present these flaws in two cases; I will
refer to the "old and candidate" networks, meaning the network that
was supporting the MN, and a network that is a possible candidate
network for handover of the MN's traffic. Each has an AR, AP, etc.

  1. The old and candidate networks have an interworking capability:
     in this case, the networks have a more complete, and current
     view of the services available before and after handover. The
     proposal is to use CAR to ship information describing this view
     to the MN. At best, this implies using wireless bandwidth, and MN
     CPU cycles and battery power to make a decision that can be made
     by two networks that have relatively unlimited link bandwidth, 
     CPU cycles, and power.

     Note that if the two networks are under the same administration,
     it would seem reasonable to assume that the networks are deployed
     with some sort of interworking capability.

  2. The old and candidate networks have no interworking capability,
     e.g. they know nothing of each other. In this opposite extreme,
     the primary model is essentially one of an IP service running 
     over two wireless access networks. Since, by definition, the MN
     is the main common element between the two networks, it would 
     appear to make sense to have it make the handover decision.

     There are then three alternatives to how the MN can access the 
     information from the candidate network: the candidate network
     broadcasts capability information "regularly" over the wireless
     channel; the candidate network responds to all requests for
     capability information; and, the candidate network responds
     to authorized requests from a specific MN (implying that the
     MN is authenticated). 

     Now, at this point, I will assume that each network has an
     operator that wishes to recover his/her investment in spectrum,
     equipment, backhaul links, operating costs, etc. In a commercial
     operation, it is reasonable to assume competition: what operator
     would be willing to promiscuously broadcast capability information
     about their network that could be used by a competitor to lure
     away customers? Wireline network operators are leery of exposing
     any information that might identify their network topology or
     how it operates, and so why would a wireless operator be different?

     So, this implies that the MN must establish a link with the candidate
     network, be authenticated and authorized to receive capability
     information. A lot has to happen before IP packets can be exchanged
     (CAR is an L3 solution), and, in order for capability discovery
     to be useful, the MN must be in communication with at least two
     candidate networks. If the MN is assumed to have single channel, 
     multi-mode NICs, this discovery process has to occur sequentially 
     - the equivalent of channel scanning used in FDM wireless systems 
     - which is very difficult to do and provide "seamless" handover,
     particularly when L2 authentication and L3 capability discovery
     have to be completed. 

     This leads to the conclusion that the MN has to have multi-channel, 
     multi-mode NICs, which might make the NIC vendors happy, and
     certainly would make the battery vendors very happy.

None of these arguments apply if we are talking about best effort service
over an "open" access network. To me, the idea of must be open and
non-commercial
access networks outside of select government/academic networks is
unrealistic.
It is arguable that that access to the Internet today is predominately 
commercial.

The bottom line is that there are significantly greater resources within
the network to perform these functions, and the communications between
networks are relatively (note, I said "relatively") easier to make secure.

Why does this matter? If Seamoby develops both solutions, then won't the
marketplace determine what makes sense or not? Perhaps, but this approach
makes sense only if there is no cost to defining a one-size-fits-all
solution.
I would prefer that the effort be focussed on inter-AR capability discovery,
including internetwork capability discovery. 

Just more of my delusional thoughts,
Gary

> From: Karim El-Malki (ERA) [mailto:[email-masked]]
> Sent: April 18, 2002 10:09
> To: [email-masked]

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 18 Apr 2002 11:18:44 -0400

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 18 Apr 2002 12:26:11 -0400

> network to assist where needed).

*snip*

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 18 Apr 2002 12:26:11 -0400

*snip*

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 18 Apr 2002 16:20:15 -0400

Hello Karim,

>all the possible CARs is the MN (that's what I mean by mobile-centric).

[Govind] Sure, but there may be inherent constraints. Suppose there is
just one interface, and the MN can hear multiple L2 beacons and
if figuring out which ARs these L2 devices  are connected
to implies that the
MN has to disconnect from the current AP then what good is
the MN finding out the GAARs in this case. Also, to know CARs the
MN has to get the capabilties (whatever they might be) from each
and every GAAR. This may  be an expensive proposition in terms of
wireless bandwidth.

>network-centric solution (i.e. where the MN is NOT involved).

[Govind] I don't know where you saw a network based solution which
completely prohibits the MN from participation. CAR discovery by
definition needs the capability match of the ARs with the MN's requirements. 
So there cannot be a case wherein the MN is not
involved.

I wasn't
>network to assist where needed).

[Govind] The main point is that the MNs requirements should be
taken into consideration when deciding on the TARs whether this
happens in the network or in the MN is upto the individual solution
(as long as it satisfies the requirements).
Hope these clarifies your concerns.

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 18 Apr 2002 16:20:15 -0400

Hello Karim,

I wasn't

Regards,
Govind.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 19 Apr 2002 10:44:39 +0200

> Hope these clarifies your concerns.

Sorry I'm falling behind on this discussion and haven't read all the emails,
but the point was that the decision is to be taken by the MN, not by the
network. So what you write above about the decision happening in the network
does not follow from the discussion so far. The MN should take the decision
with hints from the network, not the other way round.

/K.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 19 Apr 2002 10:44:39 +0200

/K.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 19 Apr 2002 11:01:18 +0200

> I don't think anybody is proposoing a solution just for the
 > network-centric
 > case now (if you are, please raise your hand).
 > 
 > The solutions for the mobile-centric case will work for the
 > network-centric
 > case too.
 
Seems like it was my misunderstanding and the way I posed the question.
I was trying to see whether there was agreement on the mailing list (after
agreement during the meeting) about the MN being the entity which discovers
all possible CARs, with hints from the network, and takes the decision.

/Karim

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 19 Apr 2002 11:01:18 +0200

/Karim

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 19 Apr 2002 15:12:09 +0000

Hi James,

TAR is not in scope. I am talking about identifying capabilities of ARs (or 
identifying match between capabilities of these ARs and MN's requirements) 
that govern these L2 beacons.

So, is it in scope of CAR discovery or we delegate the matter to IEEE?

Hemant

>Date: Thu, 18 Apr 2002 08:33:10 -0700
>
>Hemant,
>
>Remember, TAR is not in scope.
>
>As a practical matter, I believe the 802.11 standard should provide some
>guidance, currently it doesn't.
>
>             jak
>
>Sent: Wednesday, April 17, 2002 2:45 PM
> > > > What do you mean when you say that hearing multiple L2 is
>equivalent
> > >to
> > > > inter-technology case? I do not get the point. Why can't the MN
>listen
> > >to
> > > > without letting go the old connection? Of course, I am assuming
>that
> > >these
> > > > > > >It seems that the minutes indicate that people have somehow
>come
> > >to a
>divulge
> > >that
> > > > > > >geographically adjancent to themselves via the IP
>infrastructure.
> > >The
>information
> > > > > > or we simply neglect it and focus only on two physical
>interfaces
> > > > >case. I
>delivers
>other
> > >AR.
> > > > >Capabilities aren't involved, except to the extent that the MN
>can
> > >hear
> > > > >multiple L2s and make the decision. But this is exactly the same
>as
> > >for

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 19 Apr 2002 15:19:20 +0000

Hi Karim:

I am trying to understand the algorithmic perspective of the comment below 
saying that "The MN should take the decision with hints from the network, 
not the other way round."

So, if there is an application on MN processor which takes one input as MN 
requirements and other input as AR capabilities and provides certain output 
(say boolean yes or no), is it acceptable approach? I guess yes.

Now, suppose that there is this *same* application somewhere on processor of 
some network entity taking the *same* inputs as above and providing the same 
kind of output, is it acceptable approach? I guess it should be.

So, is it the input and output information model of the application that 
decides whether the approach in MN-centric or is it the location of the 
processor executing the application as such that decides whether the 
approach is MN-centric? I guess it is the former.

Hemant

>To: "'Govind Krishnamurthi'" <[email-masked]>, [email-masked]
>Date: Fri, 19 Apr 2002 10:44:39 +0200
>
>  > I wasn't

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 19 Apr 2002 17:03:45 +0000

Hi James:

L2 beacons have nothing to do with CAR discovery. I would like to understand 
however if the capability set of ARs  behind those beacons is important or 
not. If it is, it has to be indentified by CAR discovery protocol. If that 
is the case, then there needs to be a creative implementation of CAR 
discovery protocol for the case that this thread is concerned with, namely, 
MN having single NIC and not being able to communicate with ARs behind those 
L2 beacons without letting go the old connection (the difficulty persists 
even if MN gets IP addresses in beacons).

Hemant

>Date: Fri, 19 Apr 2002 09:18:53 -0700
>
>I don't see what L2 beacons has to do with CAR discovery. The issue is
>what ARs the MN has access to and what are their capabilities. How the
>MN chooses to use that in the context of a particular L2 is up to the
>MN.
>The ARs may be identified by their L2 identifier or by an IP address.
>
>             jak
>
>Sent: Friday, April 19, 2002 8:12 AM
> > > > strength), probably governed by different ARs, how do we choose? I
>do
> > >not
> > > > have problem choosing randomly, but just want to confirm if this
>is
> > >the way
> > > > we want to proceed.
> > > >
> > > > There is no doubt that handoff is necessary as old link will fade,
>but
> > >you
> > > > >Right, that's what I'm saying. There is one case where the MN
>needs
> > >to
> > > > >have a choice. The handover happens because, if not, the power
>will
> > >fade
> > > > > > different L2 beacons of the same technology? I guess it can,
>and
> > > > >hence, it
> > > > > > still needs to chose one among them for handoff. Then the
>issue is
> > > > >exactly
>only
> > > > > > >information is required (by the MIP fast handover algorithms)
>at
> > >the

---

From: "Xiaoming Fu" <[email-masked]>
Date: Sun, 21 Apr 2002 12:32:02 +0200

Hi all,

I have not been following this discussion closely, so sorry if this
has been clear to all:

(In IETF53minutes / Requirement 5 - FORMAT OF CAPABILITIES):
The capabilities MUST be described in a standard format which is TBD.

=> Is "TBD" task within the Seamoby/CARD? Or it is going to like 
"The exact format differs (and/or derives) from the capacity 
parameters specified by specific L2 technologies"?

(Rajeev's mail: 
CARD: a process that facilitates resolving the prospective link(identifier)
with its prefix and assocaited capabilities. This comes out as off-link ARP
with extensions.
TARS: a process that assists in selecting _a_ router from among multiple
candidates.)
=>Where does CARD end?
If I understand correctly, it's (current) ARs. "Associated capabilities" also 
include some higher-layer information e.g., QoS and security. So when 
CARD is used, perhaps one possibility is that the same information in CT 
could be avoided to save wireless bandwidth. 

=>How does TARS possibly work:
MN may (e.g., periodically) ask its (current) AR for a satisfied TARS by 
checking into "associated capabilities". My understanding is, when 
succeeds a L2 identifier  may only be returned to MN. However when 
it it may be impossible to identify the IP address of TARS (because the 
AR only knows about the L2 identifiers & associated capacity of CARs). 
One possibility is to let the (current)AR to "solicitate" an L3 advertisement 
from the TARS to the MN. 

Thanks,
Xiaoming

---

From: "Xiaoming Fu" <[email-masked]>
Date: Sun, 21 Apr 2002 12:32:02 +0200

Hi all,

(Rajeev's mail: 

Thanks,
Xiaoming

---

From: "Xiaoming Fu" <[email-masked]>
Date: Sun, 21 Apr 2002 18:06:17 +0200

Hi all,

(Rajeev's mail: 

=>Where does CARD end?

=>How does TARS possibly :
MN may (e.g., periodically) ask its (current) AR for a TARS by checking 
into "associated capabilities". My understanding is, when this
succeeds a L2 identifier of a TAR may only be returned to MN. It may 
be still impossible for the AR (and henceforce the MN) to identify the IP 
address of TAR (because the AR only knows about the L2 identifiers & 
associated capacity of CARs). Is it then necessary to let the (current)AR 
"solicitate" L3 advertisement from TAR?

Thanks,
Xiaoming

---

From: "Xiaoming Fu" <[email-masked]>
Date: Sun, 21 Apr 2002 18:06:17 +0200

Hi all,

(Rajeev's mail: 

=>Where does CARD end?

Thanks,
Xiaoming

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 21 Apr 2002 15:10:39 -0500

Eunsoo/James,

We implemented both source as well as target trigger scenarios 
of Low latency handoff draft. In case of source trigger, the 
Pre-trigger indication at source FA provides the BTS id of the 
target BTS to which MN is moving to. The L2 trigger 
handler at the oFA resolves BTS-ID to obtain the IP address
of the nFA. We used static table to resolve IP address from the 
given BTS-ID. Similarly, in case of target trigger, the 
Pre-trigger indication at nFA provides the BTS-ID of 
the source BTS from which the MN is moving from. The L2 trigger
handler at nFA resolves source BTS-ID to obtain the IP address 
of the source FA. Pre-trigger indication is sent from 
radio network controller to foreign agent as soon 
as link layer handoff is detected based upon power
measurement. Hope this helps. 

regards,
ajoy 

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Sunday, April 21, 2002 9:29 PM
To: James Kempf; [email-masked]; Singh Ajoy-ASINGH1
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

James,

I see. Thanks a lot.

Eunsoo
----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; <[email-masked]>; "Singh
Ajoy-ASINGH1" <[email-masked]>
Sent: Sunday, April 21, 2002 2:43 AM
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

> > Could you tell us, if possible, how the IP address of the target
> address is
> > discovered in your experiment with the IS-2000 RAN?
>
> The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the
> technical lead. I've cc'ed him on this response, perhaps he can describe
> how the L2 triggers were implemented.
>
> > Also how can the mobile utilize the BSSid to find the FA or AR address
> > without asking the current AR in 802.11? Don't we need something like
> the
> > CAR discovery protocol eventually? I assume the mobile does not
> receive the
> > Agent Advertisement messages of the target AR in the above question.
>
> Sure. But for experimental purposes, one can simply statically configure
> the access routers or FAs with the mapping.
>
>             jak
>
>

---

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 23 Apr 2002 13:23:37 -0500

Very very well said - let's move on to the analysis and agreement of a
standard from a set of candidate solutions to this problem space, please.

> I heard Steve's presentation.  I asked a question at the microphone
> about whether he believed it precluded network-controlled operation.
> He said it did not, but he wanted to restore mobile nodes to be
> full citizens (paraphrasing, and it's been a few weeks now).
> Subsequent discussion seems to be going to extremes, to the point
> of ignoring obviously reasonable network-constrolled designs for
> which [seamoby] ought to be responsive.
> 
> The paper you cite does not preclude such operation.  We can
> view the mobile node as a client which is making use of available
> service.  If the network provides the service, it is free to
> establish parameters by which it provides the service, and if
> it is beneficial to have a mobile node move to another point of
> attachment, I see nothing wrong with notifying the node about
> that, along with a good candidate for an access router.  I don't
> see any reason why the network should be restricted from using
> a CAR discovery protoocol to identify such a candidate.
> 
> >   Maybe the question is what business Seamoby has here?
> 
> My answer would be that [seamoby] ought to be making protocols
> by which we can expedite smooth handovers.  That's a good piece
> of work, and one for which we can exhibit existence proofs to
> show that it is possible.  I think that so far that there has
> been trouble to get agreement on "general" goals, but that there
> are particular instances where the intended results should be
> obvious.  I believe these particular instances include
> network-controlled and mobile-controlled scenarios.
> 
> ===================================================================
> 
> Somewhere else, it was stated that only the mobile node can
> possibly know all of the CARs.  I would amend this to instead
> say that the mobile node can always know about CARs that are
> not visible to the network.  But, as it turns out, the network
> can always know CARs that are not visible to the mobile node
> also.  So, we have to allow the mobile node to make the choice,
> but we should not prevent the mobile node from following
> network-directives.  Thus, we should develop a model by which
> CAR discovery is allowed to provide input to a network-controlled
> handover scheme, which is nonetheless subject to possible rejection
> by the mobile node.
> 
> Regards,
> Charlie P.
>

---

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 23 Apr 2002 13:23:37 -0500

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 26 Apr 2002 10:12:57 -0500

Hello Bachet,
I did not mean that Mobile/IP handover occurs at 
BTS. But some inter-BTS handover causes Mobile/IP handover.
Suppose you have BTS 1 to 5 mapped to FA1 and BTS 5 to 10 mapped 
to FA2. When L2 trigger indicates that MN is moving from BTS 1 to 
BTS 5, the trigger handler knows that it has to initiate 
Mobile/IP handover. Similarly, when trigger indicates that
MN is moving from BTS 1 to BTS 2,  the trigger handler knows 
that there is no need to initiate Mobile/IP handover.
Hope this helps. 
regards,
ajoy

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Friday, April 26, 2002 9:31 AM
To: [email-masked]
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

Hello Ajoy,
  Do you mean to say that BTS is where Mobile IP handover occurs, i.e. 
BTS of 1xRTT was where FA was placed in your experiment? If yes then how 
do you reconcile this with the standard architecture?
  Can you please provide more details so that we can better understand 
what you did?

Regards,

>measurement. Hope this helps. 
--behcet

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 26 Apr 2002 10:12:57 -0500

Hello Bachet,

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Friday, April 26, 2002 9:31 AM
To: [email-masked]
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

Hello Ajoy,

Regards,

--behcet