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

From: Eunsoo Shim <[email-masked]>
Date: Thu, 14 Jul 2005 12:25:37 -0400

Please let me add a few comments in this discussion. My comments are inline.
Regards,

Eunsoo

>Here is a list of problems Rajeev and I had when we tried to use CARD to
>define NED:
>
>- 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.  
>
>  
>
[eunsoo] Ajoy pointed out, CARD can be easily used for any network 
entity in addition to ARs, that is, CARD can be used between the MN and 
"the information server for 802.21 IS".

>- 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. 
>
>  
>
[eunsoo] The CARD specification (rfc4066) shows how the CARD message can 
be delivered over SCTP and ICMP. I understand Marco implemented CARD on 
top of UDP and used it for his experiment. Based on this fact, I don't 
quite understand James' comment saying "CARD's format was strictly 
defined by its transport mechanism".

>- 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. 
>
>  
>
[eunsoo] I clearly said in the past during the discussion in the SeaMoby 
WG that CARD's functionality was collecting information about access 
networking (covering L2 as well as L3 information) and distributing the 
information. Mapping AP addresses to AR IP addresses is a part of the 
functionality.  CARD can support FMIP very well, which is an important 
advantage of CARD. Moreover, CARD can be used for any application that 
requires information about the current and neighboring access points and 
access routers. It is apparant that CARD can deliver even information 
about the whole access network.

> Now, there is no reason to priviledge this
>particular application above others in 802.21 InfoElements, and NED doesn't.
>  
>
[eunsoo] As said above, CARD can support both of FMIP and 802.21 IS 
well. Supporting FMIP very well is not a problem but rather an advantage 
since fast handoff is important obviously.

>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.  
>  
>
[eunsoo] 802.21 is talking about filters for 802.21 IS. The Preferences 
and Requirements Suboptions of CARD are filters that can satisfy the 
filter functionality of 802.21 IS.

>-  CARD handles fragmentation of final results using a "context-id". This is
>necessary because of the blocks of bits format and ICMP transport. I think
>it makes more sense to define the InfoElements logically, and let the
>transport handle the fragmentation.
>- The length field in CARD options is 8 bits, due to the blocks of bits
>format. This required us to define the units of the length as "8 octets"
>which leads to some potential for wasted padding.
>
>Ajoy-> This depends upon the actual capability being used. Some potential padding is always possible in any protocol so I do not see why it is bad.  
>
>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. 
>
>As to "how the proposed draft solves the 802.21 problems better than CARD",
>I'll leave answering that up to 802.21 people. 
>
>
>Ajoy-> I have been part of 802.21 discussion. I do represent here my view of 802.21. 
>
>Suffice to say, Rajeev and I
>believe NED does solve those problems, and we're prepared to work with
>802.21 and MIPSHOP to fill any gaps that they may find.
>
>Also, BTW, I suggest you read Stefano and Greg's draft. They've also
>proposed an InfoElements protocol.
>
>Ajoy-> I will definitely do so. In fact I had discussion with Stefano on 802.21 list about CARD. 
>
>            jak
>
>
>
>
>----- Original Message -----
>From: "Singh Ajoy-ASINGH1" <[email-masked]>
>To: "'James Kempf'" <[email-masked]>; <[email-masked]>
>Cc: <[email-masked]>; "'Marco Liebsch'" <[email-masked]>;
>"'Eunsoo Shim'" <[email-masked]>
>Sent: Tuesday, July 12, 2005 7:34 PM
>Subject: RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt
>
>
>  
>
>>Hi James,
>>
>>I finally managed to read your proposed nhodd draft.
>>After reading the draft, I am not really convinced why we need to define a
>>    
>>
>new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I
>am still trying to understand how the newly proposed draft solves the
>problem of IEEE 802.21 any better than existing CARD protocol. In my view
>perhaps taking the CARD protocol to standard track is better idea than
>trying to invent a new protocol to solve the problem.
>  
>
>>Regards,
>>Ajoy
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>    
>>
>Of James Kempf
>  
>
>>Sent: Friday, July 08, 2005 11:05 AM
>>To: [email-masked]
>>Cc: [email-masked]
>>Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt
>>
>>Folks,
>>
>>I've posted the Neighborhood Discovery draft by Rajeev and myself to the
>>Internet Drafts directory. Until it is available, you can find it here:
>>
>>
>>    
>>
>http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt
>  
>
>>This is the same draft as I previously posted for Mobopts, except I
>>    
>>
>changed
>  
>
>>the filename to reflect the fact that this topic is now going to be
>>discussed in MIPSHOP (I think, discussion is still ongoing).
>>
>>This draft is intended to partially fufill the IEEE 802.21 requirement for
>>network information discovery.
>>
>>Please send comments if you have any.
>>
>>            jak
>>
>>
>>_______________________________________________
>>Mobopts mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/mobopts
>>
>>    
>>
>
>  
>

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Jul 2005 14:55:13 -0700

Ajoy,

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

So everytime someone wants to use CARD for something they have to include
the CARD folks into the design? Doesn't sound like a very scalable design
process to me.

                jak

---

From: Eunsoo Shim <[email-masked]>
Date: Thu, 14 Jul 2005 23:39:42 -0400

James,

Please see my inline comments.

>>server" or an L2 device like an AP but with IP capability, or even
>>    
>>
>involves
>  
>
>>doesn't make sense anymore. Something like EAP (after which NED is
>>    
>>
>modelled)
>  
>
>>does.
>>
I don't see any base for this subjective statement. Could you elaborate 
this?

>>Ajoy-> CARD is NOT limited to FMIPv6. It can be used to other mobility
>>    
>>
>protocol as well.
>  
>
>
You remember that SeaMoby WG produced drafts 
"draft-ietf-seamoby-card-requirements-02.txt" to which you also made 
contributions.
According to the draft, the requirements for CARD include the following:
- Identifying the IP address of a CAR (3.1)
- Support for inter-technology handoffs (3.2)
- capability discovery (3.4)
- dependence on a mobility management protocol --- CARD MUST NOT depend 
on a particular mobility management protocol (3.10)

Your message gives an impression that CARD was designed mainly for 
mapping AP address to AR IP address. But as you agreed on the CARD 
requirements draft, CARD was designed to support much more than the 
cross-link ARP. In particular, inter-technology handoff support is at 
least very very closely related to what 802.21's media indepent handoff 
is about.

The draft "draft-ietf-seamoby-card-issues-04.txt" to which you again 
contributed lists a number of possible application examples:
- Load balancing between ARs.
– Bandwidth-intensive applications.
– Minimization of cost.
– Inter-technology handovers.
– Adaptability to changing topology without Ad hoc routing schemes.

Certainly CARD is not designed to do everything human beings can 
imagine. But it was designed to be general enough to satisfy the above 
requirements and the above application examples, at least.

You are saying "from the viewpoint of a generalized protocol". What do 
you mean by "generalized protocol"?

>>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
>  
>
>>questionable nature of this design decision when Seamoby was completing
>>    
>>
>the
>  
>
That's quite unfortunate. Please take a look at the requirements of 
802.21 IS compiled by 802.21 WG. They include filters. Even schemas are 
mentioned. For anyone to say something of CARD is not necessary for 
802.21 IS and to propose a kind of subset of CARD, she/he should refer 
to the 802.21 IS requirements.

Following the good method adopted by many IETF WGs,  I believe 802.21 IS 
requirements should be clarified first of all. Then existing protocols 
(primarily CARD in this case) should be compared to the requirements and 
discussed. Based on the result, we can say what is necessary and 
unnecessary and what needs to be changed, added or created.

>>registry for network capabilities and for L2 Technologies, because they
>>    
>>
>are
>  
>
Regards,

Eunsoo