Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 8 Jan 2003 13:14:11 -0600

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:00 PM
To: Singh Ajoy-ASINGH1; 'Erik Nordmark'
Cc: [email-masked]; 'James Kempf'; [email-masked];
[email-masked]
Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
interworking

We also need to look at the consumer(s) of CARD.
If we are talking about mapping link-layer identifier
of the next access router to its IP address and prefix
information for fast handovers, FMIPv6 protocol already
covers this funcitonality with PrRtSol and PrRtAdv

Are there other consumers, usage scenarios of CARD?

AJOY-> CARD has two components:
1. L2-L3 address mapping 
2. Capability discovery of neighboring AR.

Perhaps the capability discovery feature of the 
CARD may be useful for any handoff including 
fast handoff. The CARD may be used in case
of standard Mobile/IP if MN is capable to perform 
make before break IP layer handoff. Perhaps this 
feature will be applicable for inter-technology 
handoff with overlapping coverage area. Any 
comments?

alper

> Erick,
> Thanks for your feedback. Please find my
> inline reply. I am also posting this to
> Mobile/IP WG as this may affect
> FMIPv6 protocol.
> Regards,
> Ajoy
>
> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2003 2:02 PM
> To: Singh Ajoy-ASINGH1
> Cc: 'Erik Nordmark'; [email-masked]; 'James Kempf'; [email-masked]
> Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking
>
>
>
> Part of the tradeoffs with piggybacking has to do with implementation
> considerations.
> In order to do piggybacking of CARD on e.g. FMIPv6 the same piece
> of software needs to implement both protocols. Thus you loose some
> implementation flexibility if you want piggybacking which, depending
> on how CARD and FMIPv6 are deployed, might make deployment harder.
>
> For instance, if FMIPv6 is already implemented and deployed by vendor X
and Y
> but those vendors do not have plans to update their implementations to add
> CARD, then you can't really deploy CARD as an add-on piece of software
that
> people can download.
>
> AJOY-> Good point. So, I guess we should define both generic ICMP options
> as well as the carrier of the generic options (new messages) in the base
CARD
> draft. This will eliminate the issue raised by you. Additionally, the
FMIPv6
> draft may describe how to piggyback CARD options on FMIPv6 messages.
> This will enable FMIPv6 implementation to take advantage of the
> efficient implementataion of the CARD. I do agree in this case both CARD
> and FMIPv6 must be developed by same vendor which is ok.
>
> But if most people that are going to implement one of the protocols is
> going to implement the other as well then this wouldn't be a concern.
>
> AJOY-> I think this will be the most common scenario. Hence, it makes
> sense to piggyback CARD options on FMIPv6 messages.
> But I guess this is mostly an FMIPv6 issue and probably should be
addressed
> in FMIPv6 draft. What other's think?
>
> So I think it all depends on whether most people view this as two pieces
> of the same protocol, or merely two different protocols operating between
> the same set of nodes. In the latter case I think you want the
implementation
> flexibility of different implementers providing the different protocols
for
> the same box.
>   Erik

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