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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 6 Jan 2003 16:41:25 -0600

Allision/Erik, 
We have been discussion the possibility of 
defining CARD signaling as generic ICMP options.
The idea is to allow piggybacking of 
the generic ICMP options over any ICMP messages 
including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv).
Do you see any issue this approach? James, has indicated 
some potential issue in the attached email.  
I would appreciate your comments.  
Regards,
Ajoy 

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, January 06, 2003 1:54 PM
To: Singh Ajoy-ASINGH1; [email-masked]
Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking

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

----- Original Message -----
From: "Singh Ajoy-ASINGH1" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; <[email-masked]>
Sent: Monday, January 06, 2003 9:00 AM
Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking

> 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 them 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 do 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
>
>
>Hello All,
>
>The CARD design team would like to solicit WG consensus about CARD 
>and FMIPv6 protocol inter-working.  The selection of anyone method 
>from the proposed list would help us to focus in the right direction 
>during the next phase of the protocol design. The high-level description
>of the various approaches with their relative merits and de-merits is 
>listed below:
 
>Tight Coupling Approach 
>Intermediate Approach
>Loose Coupling Approach 

>Tight Coupling Approach: In this case, we can define CARD signaling as 
>an extension to the FMIPv6 messages. This makes the CARD protocol tightly
>coupled with FMIv6 protocol. 

>The following are the PROS and CONS of this approach:

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

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

>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.
>
>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. 
> 
>CONS: Adds extra over the air messages during critical path of handoff
which 
>may not be desirable for the most wireless link. 
>
>Please send your choice if any.
>
>Regards,
>Ajoy

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 7 Jan 2003 00:49:19 +0100 (CET)

> I would appreciate your comments.  

I don't have enough context to understand. Is this written
up in an I-D already?
I assume you mean Neighbor Discovery options and not ICMP options
since the ICMP message format doesn't have any options.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 7 Jan 2003 00:49:19 +0100 (CET)

Erik