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

From: [email-masked]
Date: Tue, 7 Jan 2003 17:05:50 -0500

Hi Erik:

Let me chip into the discussion.

In the current CARD protocol draft, we have defined CARD ICMP type. This enables standalone implementation of CARD, independent of FMIPv6. There are two ICMP options for this type, namely, Request and Response. Each of those options have sub-options carrying CARD info.

At the same time, to allow for integration with FMIPv6, if that is the implementers' choice, CARD Request and Response can be piggybacked on FMIPv6 signaling. This however, imposes the restriction that CARD signaling events must be aligned with FMIPv6 signaling events. 

To eliminate this restriction when integrating with FMIPv6, we were considering a possibility of the type, say, send Request in CARD ICMP type and possibly receive response in FMIPv6 message with CARD Response option piggybacked on it. For this however, Request and Response options need to have sequence ID field of their own.

Please let us know about what you think about it. In particular, about the feasibility of mixed standalone and piggybacking.

Regards,
Hemant

-----Original Message-----
From: ext Erik Nordmark [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 3: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.

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.

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 implementors providing the different protocols for
the same box.

  Erik

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Jan 2003 02:41:52 +0100 (CET)

> In the current CARD protocol draft, we have defined CARD ICMP type. This
> enables standalone implementation of CARD, independent of FMIPv6. There are
> two ICMP options for this type, namely, Request and Response. Each of those
> options have sub-options carrying CARD info.

OK.

> At the same time, to allow for integration with FMIPv6, if that is the
> implementers' choice, CARD Request and Response can be piggybacked on FMIPv6
> signaling. This however, imposes the restriction that CARD signaling events
> must be aligned with FMIPv6 signaling events. 

And that the FMIPv6 sender only perform such piggybacking when the FMIPv6
receiver is capable to process the received piggybacked info.
Thus this can't be an independent choice for an implementor - you might need
a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking
on the FMIPv6 messages.

> To eliminate this restriction when integrating with FMIPv6, we were
> considering a possibility of the type, say, send Request in CARD ICMP type
> and possibly receive response in FMIPv6 message with CARD Response option
> piggybacked on it. For this however, Request and Response options need to
> have sequence ID field of their own.

So you would send a CARD message that says "if you'd like I can accept
the response as a CARD message or piggybacked on a FMIPv6 message".
If you always use that type of exchange you handle the capability discovery
part.

But aren't there also cases when you want to piggyback something on 
the CARD request?

Do we already know that CARD would be logically sent first?
Or will there (also) be a need for the inverse piggybacking (carrying FMIPv6
information in CARD ICMP messages?)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Jan 2003 02:41:52 +0100 (CET)

OK.

  Erik

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 17 Jan 2003 14:32:08 +0100

Eric,

please see a proposal for the issue you addressed below.

marco

>a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking

We discussed this issue within the design team. To avoid modification of 
other protocols
(FMIPv6, Neighbor Disc.) for discovery of whether or not the 
communication peer
supports CARD protocol piggybacking, what about the following:

The ICMP message for CARD protocol stand-alone deployment has a flag,
indicating piggybacking capability of the message sender, if present.
First CARD message sent (for example mobile to AR) is to be a 
stand-alone CARD message,
indicating the sender's capability of piggybacking. The appropriate 
reply message, in this
example from AR, indicates, whether or not the AR itself is able to 
perform piggybacking.
In case of both entities support piggybacking, further CARD messages can 
be piggybacked.
The CARD reply could already be piggybacked in case of the AR supports 
piggybacking and
in case of an appropriate "carrier" protocol message is to be sent anyway.

For the latter proposal it's important to separate protocol messages' 
sequence numbers.
Hence, the piggybacked CARD reply message would carry the CARD message 
sequence number
in the option to be piggybacked. This keeps CARD protocol sequence 
numbers de-coupled
from the "carrier protocol's" sequence numbers.

What do you think?

marco

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 17 Jan 2003 14:32:08 +0100

Eric,

marco

What do you think?

marco

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 17:58:11 +0100 (CET)

> from the "carrier protocol's" sequence numbers.

This should work.

It adds some amount of complexity thus I hope it provides sufficient
performance benefits to compensate.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Jan 2003 17:58:11 +0100 (CET)

This should work.

  Erik