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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 6 Jan 2003 11:00:31 -0600

Hello James, 
Sorry for late reply. I got back from vacation recently.
Please find my inline reply. 
Regards,
ajoy 

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, December 20, 2002 11:40 AM
To: Singh Ajoy-ASINGH1; [email-masked]
Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking

>
> PROS: Enables inter-working of CARD and FMIPv6. Probably this will make
> CARD and FMIPv6 implementation less complicated.
>

I favor this approach, for router to mobile communication, at least.

AJOY-> I am not against piggybacking the CARD signaling over FMIPv6 
message. I was just asking if we need to make CARD ICMP options tightly 
coupled with PRoxyRtSol or ProxyRtAdv messages or let be optinal
so that any ICMP messages can be used to piggyback these options.
It looks like from others' response that quite a few of WG members 
are against the idea of tight coupling.
What you think?

> CONS: This approach restricts the deployment of CARD to FMIpv6 only.
> This approach may also require modification to the present FMIPv6
protocol.

I don't see why this should restrict CARD To FMIPv6. FMIPv6 defines some
additional ICMP messages. If the CARD messages are extensions too, the
difference between the loose approach and tight approach isn't so great in
my
view. The new ICMP messages can be used with or without handover. 

AJOY-> The difference is cosmetic. If someone is not implementing 
CARD along with FMIPv6, it may not be cleaner to use FMIPv6 
messages for CARD signaling. Actually the CARD ICMP messages will be similar
to
FMIPv6 message, but it will have different type.

Those designed
to be used with handover are FMIPv6, those designed to be used without are
CARD.

There has been a discussion in the MIP group about whether the FMIPv6
prehandover signaling should be completely decoupled from handover, but the
discussion has not reached any clear conclusion. One issue is whether
decoupling
the signaling would also decouple any signaling between the mobile's current
access router and other access routers (i.e. HI/HAck). If no signaling
occurs
between access routers when the FMIPv6 signaling occurs (that is, it is for
information only), then that would be the equivalent of CARD. If signaling
does
occur, perhaps to pre-configure a care of address on the new subnet, then it
would be different.

I think a more pressing issue for CARD is whether the same protocol can be
used
to exchange CARD information between routers.

AJOY-> I agree and this will also be addressed. First, 
we would like WG to agree upon MN-AR messaging.

 The current FMIPv6 approach isn't
defined for this, and there are some good arguments why this should be done
using a reliable transport, such as SCTP or TCP, rather than UDP, which came
up
during the CT discussion.

AJOY-> Since this 
discussion has already taken place in context of CT protocol,
do we really need to get WG consensus about this? Won't the same 
conclusion apply in this case also?

> Intermediate Approach: In this approach, we can define CARD signaling as
> generic ICMP options. These ICMP options can be piggybacked upon any ICMP
> message including FMIPv6 signaling messages. Additionally, we can also
define
> new CARD ICMP messages, which can be used when no outgoing ICMP messages
are
> pending.
>
> The following are the PROS and CONS of this approach:
>
> PROS: This approach enables the deployment of CARD along with any protocol
> including FMIPv6.  This also provides opportunity for additional
optimization
> when deployed with FMIPv6 by exploiting the possibility of piggybacking
CARD
> signaling over the FMIPv6 messages.
>
> CONS: The CARD protocol will be slightly more complex compared to the
other
> approaches.

I am opposed to this. It seems the least clean of all the approaches, both
architecturally and implementationally.

AJOY-> Why do you think so? Is it because this approach allows the
piggybacking
of CARD messages over any ICMP messages? If this is your concern, we can 
state that CARD signaling can only be piggybacked upon FMIPv6 as well as 
some explicit CARD messages. The new CARD messages will be used 
when CARD is not deployed along with FMIPv6. 

> Loose Coupling Approach: We can define CARD signaling as new set of
messages
> and prohibit the possibility of piggybacking upon any FMIPv6 messages.
>
> The following are the PROS and CONS of this approach:
>
> PROS:De-couples CARD from any other protocol including FMIPv6. Probably
this
> is simpler to implement.

I'm not sure I follow why. While implementing the protocol might be easier,
since FMIPv6 will be the principle consumer, it might be more complicated to
integrate the two.

AJOY-> I agree, if we assume CARD will only be deployed with FMIPv6.

> CONS: Adds extra over the air messages during critical path of handoff
which
> may not be desirable for the most wireless link.
>

Again, why would this be so? The CARD information can be exchanged between
the
AR and MN at any time prior to the handover.

AJOY-> Not all CARD information will be exchanged long before the handoff.
Some of the dynamic capabilities may only be exchanged just prior to
handoff.  

BTW, I think that the Loose Coupling approach might be appropriate for the
inter-router exchange protocol, presuming we want to tackle that. However, I
believe we would need to look at alternatives, such as including CARD
information in the IGP (though that might be messy, given the IETF has three
"standard" IGPs).

AJOY-> OK, probably we can ignore this approach for now.

            jak

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Jan 2003 11:54:12 -0800

Ajoy,

I'm OK with option 2, having a general ICMP option, *provided* the ADs are.

I seem to recall Erik Nordmark in the past having expressed some skepticism
about certain types of extension mechanisms, and though I don't remember exactly
what his criteria were for successful v.s. unsuccessful extension mechanisms, I
do vaguely recall his mentioning something about an ICMP mechanism (it might not
have been options) being not particularly successful.

I think it might be a good idea to clear this decision with Allison and Erik so
that we don't run into any last minute opposition from the IESG.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Jan 2003 11:54:12 -0800

Ajoy,

            jak