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: 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

> coupled with PRoxyRtSol or ProxyRtAdv messages or let them be optinal
> What do you think?
> to FMIPv6 message, but it will have different type.
>
> Those designed
> AJOY-> I agree and this will also be addressed. First
>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. 

>This approach may also require modification to the present FMIPv6 protocol.

define 
are 
optimization 
CARD 
>CONS: The CARD protocol will be slightly more complex compared to the other

messages 
this
which 
>Please send your choice if any.
>
>Regards,
>Ajoy

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 6 Jan 2003 18:04:54 -0600

Erik,

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, January 06, 2003 5:49 PM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]; [email-masked]; 'James Kempf';
[email-masked]

> I would appreciate your comments.  

I don't have enough context to understand. Is this written
up in an I-D already?

AJOY-> The detailed text is not yet available. But some high-level description 
is available in section 6.1 of http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-00.txt. 

I assume you mean Neighbor Discovery options and not ICMP options
since the ICMP message format doesn't have any options.

AJOY-> Yes 

  Erik

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 7 Jan 2003 10:39:50 -0600

Erik,

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, January 06, 2003 5:49 PM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]; [email-masked]; 'James Kempf';
[email-masked]

AJOY-> Yes 

  Erik

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 7 Jan 2003 10:39:50 -0600

Erik,

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, January 06, 2003 5:49 PM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]; [email-masked]; 'James Kempf';
[email-masked]

AJOY-> Yes 

  Erik

---

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

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 7 Jan 2003 16:57:12 -0600

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

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. 

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

---

From: [email-masked]
Date: Wed, 8 Jan 2003 10:18:19 -0500

Hi Alper,
Comments inline.
Cheers,
Govind.
-----Original Message-----
From: ext Alper E. YEGIN [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 9: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.

[Govind] What you describe there are carriers that take the messages from
and to the MN. I don't think anyone is discounting the fact that 
if FMIPv6 is available and is adapted to the needs of CARD these 
messages can be used as carriers. However, CARD also talks about 
capabilities discovery and mapping capabilities to the requirements
of the MN. Also, FMIPv6 needs "something" to fill in the mapping
from link layer id to L3 id. CARD does that. 

Are there other consumers, usage scenarios of CARD?
[Govind] Several potential uses are listed in the issues draft.

alper

---

From: [email-masked]
Date: Wed, 8 Jan 2003 13:06:00 -0500

Rajeev,

What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the  functionalities of CARD (however you do it) is to fill up this mapping table.
Doing it statically is just one way of doing it.

Govind.

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 1:01 PM
To: Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
interworking

Govind,

> from link layer id to L3 id. CARD does that.

This is not an accurate characterization. FMIPv6 can work without CARD.
How the map containing the [AP-ID, AR-prefix] tuple is computed on the
access router is orthogonal to the operation of FMIPv6. One could use CARD
or static configuration, or any link state routing protocol (with extensions)
for
that matter to compute the map.

-Rajeev

---

From: [email-masked]
Date: Wed, 8 Jan 2003 13:08:27 -0500

Hi Rajeev:

As you say, the L2 ID - IP address mapping is orthogonal to FMIPv6. Well, but it is very much essential component of CARD, according to CARD problem statement. Whether to use that component in FMIPv6 or not is implementer's choice.

Hemant 

-----Original Message-----
From: ext Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 1:01 PM
To: Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
interworking

Govind,

-Rajeev

---

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];

covers this funcitonality with PrRtSol and PrRtAdv

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

---

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];

alper

---

From: [email-masked]
Date: Wed, 8 Jan 2003 16:51:51 -0500

Rajeev,
I don't understand what you mean by saying CARD is not a protocol.
 There are several ways to implement the various components of the CARD protocol
and having a static map, IMO, is one way to implement the mapping to facilitate L2-L3
translation. Ofcourse, this is a simplistic and clearly not the best way to do it as 
explained in the issues draft.
Hope it is clear now.

-Govind.

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 4:40 PM
To: Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
interworking

> Doing it statically is just one way of doing it.

OK, if CARD means a set of options to chose from and not _a_ protocol, then
I agree with you. My impression was CARD is a protocol in works.

-Rajeev

---

From: [email-masked]
Date: Wed, 8 Jan 2003 19:23:04 -0500

Hi:

I don't understand this distinction between protocol and options. All protocols have options, extensions and optimizations. How does one define if something is a protocol and something is an option?

CARD has in its charter designing a mechanism to provide L2 ID to IP adr. mapping. Of course, static configuration is one of them. But, it is a trivial solution and does not warrant any discussion or specific mention. Then, there can be more sophisticated solutions. If implementer sees any benefits in using sophisticated solutions, he may do so. If he thinks it is too much, he can let it go.

Hemant

-----Original Message-----
From: ext Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 4:40 PM
To: Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
interworking

-Rajeev

---

From: [email-masked]
Date: Wed, 8 Jan 2003 19:23:04 -0500

Hi:

Hemant

-----Original Message-----
From: ext Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 4:40 PM
To: Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
interworking

-Rajeev

---

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 09 Jan 2003 04:28:08 +0000

Hi Erik:

See some comments below as [HMC]:

>From: Erik Nordmark <[email-masked]>
>Reply-To: Erik Nordmark <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked], [email-masked],   
>[email-masked], [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.

[HMC] I agree. For this FMIPv6 spec needs to recognize CARD options and 
suboptions as well.

>
> > 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?)

[HMC] I agree. But then, a better approach could be to define combined 
CARD/FMIPv6 ICMP type. The corresponding options can be FMIPv6 options or 
CARD options.

So, as I see there are two approaches possible:

(1) CARD ICMP type with its options and suboptions. It is implementation's 
task to properly sync CARD and FMIPv6 state machines in MN and AR.

(2) A combined FMIPv6/CARD ICMP type with options and suboptions for both 
FMIPv6 and CARD.

What does the WG think about this?

Hemant

>   Erik

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

---

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 09 Jan 2003 04:28:08 +0000

Hi Erik:

Hemant