Subject: [Mipshop] RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 15 Jul 2005 10:12:09 -0500

James, 

Please find my inline replies. 

Regards,
Ajoy 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, July 14, 2005 4:55 PM
To: Singh Ajoy-ASINGH1; [email-masked]
Cc: [email-masked]; 'Marco Liebsch'
Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

Ajoy,

> - The information source is always an AR. If the source is an "information
> server" or an L2 device like an AP but with IP capability, or even
involves
> an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But let's
> suppose you can extract the options out of CARD and try to use them. Then
> you run into the problems below.
>
> Ajoy-> CARD is an IP layer protocol. Being a IP layer protocol, it can
easily accommodate a scenario where MIH function is implemented on a
standalone server or an AP that is reachable using IP based transport.
> Please note that 802.21 is defining MIH function for 802.XX, 3GPP2 and
3GPP and it is difficult to have a common MAC layer protocol that can be
used in all of the above technologies. This was one of motivation why 802.21
is also looking at IP based transport. If this is not the case, you can
extend 802.11 and 802.16 using MAC extension for the information service.

I believe Mike responded on this.

Ajoy-> I was stating the motivation for IP layer protocol and how CARD can be used for that. Please note that during IEEE 802.21 November 2004 meeting itself I made this point as part of Motorola contribution. 

>
> - Most 802 protocols don't like the CARD format of a bunch of disconnected
> blocks of bits. CARD's format was strictly defined by it's transport
> mechanism, namely as options over ICMP ND messages. Once you liberate the
> application from that transport format, the disconnected blocks format
> doesn't make sense anymore. Something like EAP (after which NED is
modelled)
> does.
>
> Ajoy-> I do not quite understand your argument here. CARD is using TLV
encoding and TLV encoding is used in 802.11 as well as most of IP based
protocol. CARD options have been used over ICMP on MN-AR interface and over
SCTP/UDP over AR-AR interface.

The on-the-wire format of CARD is based on RFC 2461 Options. That isn't an
appropriate format for a widely applicable solution, especially for 802.21.

Ajoy-> I have seen how TLV is used by various IP based protocols as well as IEEE MACs and I do not think TLV usage of CARD is anyway significantly different from others. All the protocols customize TLV usage a bit to suit their need. As CARD was designed to encode capability (InfoElement), so the encoding scheme is very useful for encoding IEEE 802.21 InfoElement. 

> - CARD privileges certain network information elements (like resolution of
> AP addresses to AR addresses) above others. This is due to the built in
> design assumption that the primary application for CARD is a kind of
> cross-link ARP or ND to find the router's address (which, by the way,
> duplicates what FMIP does).
>
> Ajoy-> CARD is NOT limited to FMIPv6. It can be used to other mobility
protocol as well.

I guess I didn't make my point very well. My main point is that CARD has
singled out a specific application - cross link ARP - and designed in
specific option types for that - L2 ID and Address - while others are
carried in the Capability Container. From the point of view of a generalized
protocol, that doesn't make much sense. It only makes much sense if one
knows the history of CARD.

Ajoy-> The solution space of CARD and IEEE 802.21 is similar. That is why I am proposing the idea of enhancing CARD. I do not think generic protocol will be very useful for IEEE 802.21 IS. 

>
>  Now, there is no reason to priviledge this
> particular application above others in 802.21 InfoElements, and NED
doesn't.
> All applications use the IANA registry, and must be defined. NED still
uses
> AP/BS addresses as the initial identifier for the network, because that is
> what the host will see so it is really the only way the host can tell the
> server what network it is interested in.
> - CARD has two ways to do capability querying (preferences and
> requirements). I've never seen the logic of having two ways to do the same
> thing, and despite the objections of an expert reviewer about the
> questionable nature of this design decision when Seamoby was completing
the
> draft, the WG opted to include both in the final design.
>
> Ajoy-> Again, I do not understand your comment. Preference and
requirements are two different things. We have explained this earlier as
well.

It was explained, I didn't buy the explanation when I was WG chair (and
neither did the expert reviewers BTW), and I don't buy it now. That's why
this distinction isn't in NED.

Ajoy-> Sorry, I can't help you here. We still believe keeping both requirements and Preference options are much cleaner approach than overloading two different functions on a single option. I think Eunsoo has also suggested potential use of these options for IS protocol. 

> We honestly *did* really try to use CARD for NED, in fact, I wrote an
> initial draft for it, but it was really not very satisfying from a design
> standpoint. So, in the end, the only thing we ended up reusing is the IANA
> registry for network capabilities and for L2 Technologies, because they
are
> really crucial for extensibility.
>
> Ajoy-> It would have been nice if you would have involved CARD folks in
this discussion as well. I can't comment about something that I am not
really aware of.

                jak

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