Subject: RE: [mobile-ip] Thoughts on using handover capability extension

From: [email-masked]
Date: Fri, 8 Nov 2002 16:28:58 -0600

Folks,

Please keep the discussion on CARD and FMIPv6 separated at
this time. Seamoby is working on CARD. There is no reason
to duplicate the same functionality in FMIPv6. Also for
discussion on CARD (if required), lets take that to the 
seamoby list.

-Basavaraj

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 16:15:24 -0800

Basavaraj,

I would like to clarify. PrRtAdv is an FMIPv6 (ICMP)
message which can carry more than one option. It is
proposed that this option (of being able to carry more
than one tuple) be utilized. As far as I can see, I don't
see overlap. CARD would be needed to construct the
map anyway (modulo static configuration).

Regards,

-Rajeev

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 9 Nov 2002 12:06:02 -0500

Hi, Rejeev,

Actually the CARD will have methods to deliver such information to the MN as
well as methods to construct the map.
Regards,

Eunsoo

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, November 08, 2002 7:15 PM
Subject: Re: [mobile-ip] Thoughts on using handover capability extension

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 14:45:09 -0600

Hi,

This is a very good discussion, and it is exactly the sort of thing I
was hoping to encourage with my earlier comments.  I think we need to
have a clear understanding of the relationship between FMIPv6 and CARD
before progressing the FMIPv6 draft.  If we can agree that PrRtAdv is
the over-the-air container for CARD information then I would feel much
better about leaving it in the FMIPv6 draft.  However, my assumption
(keep in mind I haven't been following Seamoby) was that they were
defining an entirely new set of MN-to-network messages for the
transport of this information into MNs.  I think it would be a mistake
to take these two efforts forward independently.

I would like to point out that all of the discussion initiated by
Rajeev seems to indicate that there are many possible options for how
and when neighboring ARs are discovered.  It would be ideal to have a
pre-loaded map of AP mac addresses to router mac/IP addresses in the
MN prior to handover.  It may also be possible to embed some of this
information in the actual link-layer handover messages.  In any case,
it might be wise to decouple this "AR discovery" process from the
actual redirection of traffic which I think is the proper topic of the
FMIPv6 draft.

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 13:42:02 -0800

Pete,

> to take these two efforts forward independently.

Putting on my Seamoby chair hat, I agree and that is why I would like the
discussion moved to the Seamoby list. As you know, working groups operate by
concensus, and if we can get enough concensus in Seamoby to use FMIPv6 as the
base protocol for CARD it will happen. If you read the Seamoby charter (charters
*do* matter), it says that the group will use other protocols if available. So
using FMIPv6 signaling for CARD is a viable alternative. Please also attend the
Seamoby meeting and bring this up when the discussion on CARD happens.

Taking off my Seamoby chair hat, I would like to see the CARD protocol
simplified to do what is needed to maintain the mapping between AR L2 address
and AP L2 address on the MN, and, in addition, provide some information on the
wireless link type for this to simplify intertechnology handover.

                jak

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Nov 2002 14:37:51 -0800

Hello Pete,

Pete McCann wrote:

> before progressing the FMIPv6 draft.

How about,

- FMIPv6 supports packet forwarding and address configuration, and
- CARD does __ (I guess adjacent router capability discovery etc.)

I don't see the need for complicating this any further.
PrRtAdv already carries a [new AP-id, new AR-MAC, new AR-IP]
tuple. The question is what stops anyone from including more than
one tuple ? There is a clear separation between the delivery of these
messages (which is the extent of relevance for FMIPv6), and how the
map information is computed (which is in the realm of CARD, IMO).

> If we can agree that PrRtAdv is

You would eliminate the possibility of anticipation by doing so, apart
from removing a method to convey new AR MAC address to the MN.
I hope you agree that you can run FMIPv6 without running CARD.
I think by moving PrRtAdv out, you would impose that unnecessary
dependency as well.

> to take these two efforts forward independently.

Well, some folks, including James Kempf, think that seamoby DT
should re-use PrRtSol/PrRtAdv in FMIPv6. I tend to agree. They
are needed in FMIPv6.

> MN prior to handover.  It may also be possible to embed some of this

This is the only thing being proposed in FMIPv6. Move PrRtSol/PrRtAdv
to an earlier time and provide the map.

> information in the actual link-layer handover messages.  In any case,

This is not within the scope of FMIPv6.

> actual redirection of traffic which I think is the proper topic of the

AR discovery is never in the scope of FMIPv6. You should not
confuse PrRtSol/PrRtAdv with AR discovery.

-Rajeev

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 17:09:28 -0600

Hi, Rajeev,

 > - CARD does __ (I guess adjacent router capability discovery etc.)

I agree FMIPv6 does packet forwarding.  Are we sure we want it to do
address configuration?  Also, you mentioned router capability
discovery (which I agree is in scope of CARD) but not router discovery
itself (which I think is also in scope of CARD).

 > map information is computed (which is in the realm of CARD, IMO).

If Seamoby can agree that PrRtAdv is the right container message, then
I am all for it.  Have those discussions converged yet?

Also, I like your suggestions to allow PrRtAdv in advance of handover.
In fact I think it should be decoupled completely from tunnel
establishment.  This should be a means of obtaining information, and
shouldn't have a side-effect of establishing state in routers.

 > I think by moving PrRtAdv out, you would impose that unnecessary

Well, I would rather solve a problem once than twice.

Sorry to continue discussing CARD here on mobileip, but can we agree
that it consists of two things:

1) an inter-AR protocol for discovering info about neighboring access
   routers;
2) a MN-to-AR protocol for distributing that info to MNs.

To me it sounds like you think CARD is only (1).  I think it is both
(1) and (2), and that we shouldn't define two different protocols for (2).

 > should re-use PrRtSol/PrRtAdv in FMIPv6. I tend to agree.

A perfectly reasonable position; is it the consensus view of the
seamoby working group?  I think the answer to this question is important.

 > They are needed in FMIPv6.

I don't think they're needed if we limit FMIPv6 to solving packet
forwarding only.

 > confuse PrRtSol/PrRtAdv with AR discovery.

That's exactly the functionality they seem to be implementing, isn't
it?  The MN hears about a link layer address, and wants to know the AR
behind it.  It must send messages to "discover" the AR's identity.
Maybe we are just confusing our terminology here.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Nov 2002 15:59:25 -0800

Hi Pete,

> address configuration?  Also, you mentioned router capability

We certainly should allow for it.

> itself (which I think is also in scope of CARD).

We seem to be interpreting Router Discovery slightly differently.
IMO, FMIPv6 allows for "resolving an id to an AR". I can see you
might call it AR Discovery, but that's not what I have been saying.
Clearly, the information about the neighboring APs and ARs needs
to be resident on the ARs. This information could be statically
configured or through CARD. FMIPv6 only concerns with delivery
of that information, and not how that information is computed.

> I am all for it.  Have those discussions converged yet?

It is up to seamoby to decide.

> shouldn't have a side-effect of establishing state in routers.

Good.

> Well, I would rather solve a problem once than twice.

Me too. However, you need to indicate how one could still do
anticipation in FMIPv6 without CARD.

> (1) and (2), and that we shouldn't define two different protocols for (2).

Well, the issue is whether you run CARD or not, you need something
like 2) for FMIPv6. And, it is already there for a while now.

> I don't think they're needed if we limit FMIPv6 to solving packet

See commetn above regarding anticipation.

> Maybe we are just confusing our terminology here.

I hope my comment above clarifies the terminology I have been assuming.
In any case, resolving the LL-id to AR-info is what FMIPv6 is concerned
about. The way the association between the two is built up is beyond FMIPv6.
Hope this clarifies..

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 00:13:42 -0800

I *really* dislike sending email to two lists, but people just don't seem
willing to take this discussion to the Seamoby list, where it properly belongs.
Apologies.

> itself (which I think is also in scope of CARD).

Yes router discovery is in the scope of CARD.

> I am all for it.  Have those discussions converged yet?

No, which is why I am urging people to take this discussion to the Seamoby list
so that we can get it to converge.

> 2) a MN-to-AR protocol for distributing that info to MNs.

These don't have to be separate. You can use the same signaling for both. The
security must be different on them, however.

> (1) and (2), and that we shouldn't define two different protocols for (2).

Yes, exactly.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 05:13:22 -0800

I think that CARD should just focus on router address and wireless link type for
now, and include a way, like an ICMP option, to extend for later when people
actually intend to use other capabilities. Better to start simple with a way to
expand than have something complex initially that people won't use nor
implement. Is anyone planning on implementing complex capability determination
as products at this point? I think using CARD for anything more than wireless
link type and router address information is a research topic.

Therefore, it makes sense to leverage the FMIP signaling. Why have two protocols
that are about 80% the same when you can have one that does the whole job?

            jak

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Pete McCann" <[email-masked]>;
"Rajeev Koodli" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 12, 2002 12:50 AM
Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover capability
extension

> CARD talks about capability which may include more than just IP address (or
> subnet prefix) and MAC address.
> So distribution of information about ARs to MN may include more than AP ID,
> AR MAC, AR IP(or prefix).
> I wonder whether people want to extent FMIPv6 protocol to cover such a
> general case.
> Also one of the requirements for CARD is that it should be independent of
> any specific mobility management protocol.
> I'd like to suggest we develop CARD protocol further (it is in its very
> early stage in terms of protocol spec) and see what is the best way to
> resolve the partial overlapping between FMIPv6 and CARD.
> Regards,
>
> Eunsoo
>
> From: "James Kempf" <[email-masked]>
> To: "Pete McCann" <[email-masked]>; "Rajeev Koodli"
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>;
> Sent: Tuesday, November 12, 2002 3:13 AM
> Subject: [Seamoby] Re: [mobile-ip] Thoughts on using handover capability
> extension
>
>
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>
>

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 12 Nov 2002 17:44:16 +0100

In my opinion, a solution for a CARD protocol should be able to do more 
than what
you refer to. I also agree to Eunsoo, that according to Seamoby rules 
and repsective
requirements, the solution should be kept independent and flexible. 
Working together
with FMIP could be a hook in the CARD solution, as the proposal in the 
first draft
describes.
CARD protocol and parameter deployment can be restricted to the function you
describe. But it should be able to do more. If you look at the current 
proposal,
CARD control message encoding for the interface between MN and current AR
allows for piggybacking the protocol with for example FMIP. This message
option could replace the LLA option as described in the current FMIP draft.
On reception of this "CARD option", current AR initiates reverse address
translation of L2-ID(s) and capability discovery. In case of embedding more
than one L2-ID of candidate access points to the RtSolProxy message, the
current AR needs to perform TAR selection before sending the HI to the
selected TAR, (when the APs attach to different ARs), right?

Now, a reasonable scenario could have more than on candidate to attach to.
This requires more functionality to the CARD solution, in case of 
stand-alone
deployment as well as for the FMIP-combined case. What do you think?

marco

James Kempf wrote:

>>>willing to take this discussion to the Seamoby list, where it properly
>>>      
>>>
>>belongs.
>>    
>>
>>>Apologies.
>>>
>>>      
>>>
>>>No, which is why I am urging people to take this discussion to the Seamoby
>>>      
>>>
>>list
>>    
>>
>>>These don't have to be separate. You can use the same signaling for both.
>>>      
>>>
>>The
>>    
>>
>>>>(1) and (2), and that we shouldn't define two different protocols for
>>>>        
>>>>
>>(2).
>>    
>>
>>>Yes, exactly.
>>>
>>>            jak
>>>

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 12 Nov 2002 10:58:03 -0500

We don't know how CARD will evolve and thus I am afraid to put constraints
on CARD by relying on FMIP for the information distribution part.
I guess that is (almost?) the same reason some people do not like to have
FMIP rely on CARD.
A question arising to me is whether revising FMIP would be justified later
for distribution of more information than what FMIP needs between AR and MN
even though the revision is not really for fast handoff. The possible change
may be not only the content of the information from AR to MN but also the
way MN requests information to AR.
Currently what FMIP needs from the information distribution is a subset of
what CARD is trying to cover. If we consider merging the overlapping parts,
wouldn't it be reasonable to take a more general one? Then there would be no
problem to support not only what FMIP needs but also whatever information
distribution other/future work needs. Again I think SeaMoby WG should do
more work on CARD to find a good resolution of this overlapping.
As a last comment, I don't know who is going to disclose their product
development plans on the mailing list. Since CARD work started not so long
ago, probably we can ask whether people are interested in any feature rather
than people have any product plan using the feature at this moment.
Regards,

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; "Pete McCann" <[email-masked]>;
"Rajeev Koodli" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 12, 2002 8:13 AM
Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover capability
extension

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 12 Nov 2002 03:50:15 -0500

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Pete McCann" <[email-masked]>; "Rajeev Koodli"

belongs.
list
The
(2).

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 12 Nov 2002 03:50:15 -0500

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Pete McCann" <[email-masked]>; "Rajeev Koodli"

belongs.
list
The
(2).

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 12 Nov 2002 17:44:16 +0100

marco

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 05:13:22 -0800

jak

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 14:45:09 -0600

Hi,

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 23:24:41 -0800

> I guess that is (almost?) the same reason some people do not like to have

This is precisely the reason why it is a good idea to start simple. The current
DT document is much too complicated. We don't need "preferences" and
"requirements" being sent by the MN to the AR. We know two uses now, fast
handover and intertechnology handover. We should define CARD so that it works
for these cases, but is extensible for later cases.

> way MN requests information to AR.

If we use FMIP, any additional capabilities can later be added as ICMP options.
This is a simple and easy way of extending the protocol without having to redo
it.

> more work on CARD to find a good resolution of this overlapping.

The DT document calls for an unspecified ICMP extension for distributing the
capabilities. Why not make that extension the same as PrxyRtAdv? Similarly, why
not make SolPrxyRtAdv the same as the extension for soliciting it? Why have two
ICMP extensions that are similar in 80% of what they do? The IETF needs to
maintain some architectural consistency. Just because these protocols are being
done in two working groups is no reason to get into turf battles about whose
protocol depends on whose.

> than people have any product plan using the feature at this moment.

If nobody is going to stand up and say they want to use CARD in products, then
we ought to stop the work and let people publish it as research papers. IETF is
not in the business of doing research, it does engineering of standards for
products.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 23:57:17 -0800

> I wonder whether people want to extent FMIPv6 protocol to cover such a

Like I said, there is only one capability that matters now: link technology. The
rest can be covered by desiging the protocol to be extensible.

> any specific mobility management protocol.

So what, precisely, makes SolPrxyRtAdv and PrxyRtAdv dependent on MIP?

> resolve the partial overlapping between FMIPv6 and CARD.

I think they should be merged. We don't need two protocols one of which does 80%
of what the other is trying to do.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 23:42:55 -0800

> deployment as well as for the FMIP-combined case. What do you think?

TAR selection by the AR was thoroughly discussed in the requirements phase and
rejected. It is not in the requirements and it should not be there. This is
something internal to the AR and has nothing at all to do with the protocol.

The MN should just solicit for capabilities, and it should get them. If should
be able to put the capabilities it wants into the solicitation. Since the only
capability that any application is in a position to use right now is the link
technology, that is all that we should be specifiying. We can leave the rest
open by making the protocol extensible.

A simple way to do this would be to use TLV extensions to SolPrxyRtAdv and
PrxyRtAdv. The mobile nodes sends the solicition with a list of empty TLV pairs
containing the capabilities it wants along with the AP addresses, and it
receives back one set of records consisting of the AR addresses (L2 and IP) and
their capabilities for each router. For now, we should have one capability, link
technology. The rest can be standardized when there is need.

            jak

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 13 Nov 2002 12:06:07 +0100

Take the FMIP example: Now, your function implies that the RtSolRroxy 
message
from the MN to the current AR carries only one L2-ID of the new AR to 
attach to,
right? This implies, that TAR selection has been performed in advance to 
the FMIP
procedure, right? So, why needs the mobile to perform CARD with FMIP then,
it's actually to be performed before the FMIP procedure in case of 
having more
than one AR as candidate to attach to? Furthermore, if access technology 
type is
the only "capability" the mobile is interested in (for now, as you 
propose), I guess
this info can be retrieved already on reception of L2-ID (L2 trigger) on 
the mobile
terminal, right?
Designing the protocol based on this assumption would probably lead us into
the wrong direction when trying to extend the protocol in the future to 
perform
TAR selection based on various capability parameters.  

marco

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 13 Nov 2002 07:40:41 -0500

The below is a good example that tells it is too early to talk about using
SolPrxyRtAdv and PrxyRtAdv for CAR information distribution. If MN retrieves
the CAR information in advance of any handoff, actually MN cannot even
specify any L2 ID because it does not know where to go yet. Or MN may
specify multiple L2 IDs.
If people are willing to extend SolProxyRtAdv and PrxyRtAdv messages enough
to support all the features CARD requires, the message names would not be a
problem. To know the difference (extension requirements), we need to work on
CARD itself first.
Regards,

Eunsoo

----- Original Message -----
From: "Marco Liebsch" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Eunsoo Shim" <[email-masked]>; "Pete McCann" <[email-masked]>;
"Rajeev Koodli" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, November 13, 2002 6:06 AM
Subject: Re: [Seamoby] Re: [mobile-ip] Thoughts on using handover capability
extension

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Nov 2002 11:34:39 -0800

> procedure, right?

Suppose the MN wants to find out the available ARs for a Bluetooth access point.
The MN sends a RtSolProxy with the following TLV extensions:

        <wireless link type, len, Bluetooth>
        <l2 id type, len, Bluetooth AP identifier>

The AR sends back a PrxyRtAdv with the following:

    <wireless link type, len, Ethernet>
    <l2 id type, len, router L2 identifier>
    <ip id type, len, router IP address>

Or suppose the MN wants to find all surrounding Bluetooth access points:

        <wireless link type, len, Bluetooth>

The AR returns:

        <wireless link type, len Ethernet>
        <l2 id type, len, router-1 L2 identifier>
       < ip id type, len, router-1 IP address>
       <wireles link type, len, Bluetooth>
       <l2 id type,len, Bluetooth AP-1 identifier>
                  ...
       <l2 id type, len, router-2 L2 identifier>
       <ip id type, len, router-2 IP address>
          ...

> So, why needs the mobile to perform CARD with FMIP then,

Not if cross technology information is desired, or the mobile wants to maintain
a map of the surrounding APs and routers. For 802.11, that's the only way it can
know, prior to handover, what the IP and L2 address of the new router is.

> TAR selection based on various capability parameters.

Not at all. We can add TLV extensions for additional parameters. So suppose
tomorrow it becomes possible to handover to a router that routes blue packets
instead of red. We can define a color capability extension:

        <color capability type, len, blue>

The MN sends this, the AR returns with a list of routers that support blue
packets.

                        jak