Subject: [Mipshop] RE: CARD Discussion

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Tue, 11 Oct 2005 21:49:35 -0400

> 
> Ajoy-> I have looked at various information being considered by 802.21
> and noticed that all these information can be queried using TLV based
> mechanism provided by protocol such as CARD. 

I think generic query is needed to support heterogeneous handovers in
an efficient, flexibile and extensible way, but to me CARD is not
designed for that since it does not support a schema language and a
query language.

Ajoy-> With due respect, I do see very hard sale for only XML based
protocol for following reasons: 
a. XML is NOT efficient from bandwidth utilization so I do not believe
any solution that will only support XML encoding will be acceptable to
existing cellular devices. 
b. The performance impact of XML on mobile devices is not known yet.

I think the primary motivation for IS protocol is heterogeneous mobility
between 802.XX and cellular. 

> But the Requirements and
> the Preferences sub-option were not designed to express complex
> relations among multiple AVPs like something used in database query.
> Simplicity was one of the guidelines when CARD protocol was designed.
> However, if you want to use, let say, XML scipt as a filter, you can
> define an AVP for it in which the value portion becomes a generic XML
> script. This approach provides flexibility to support implementations
> with different level of complexity.

Any protocol can be extended to carry data that was not supposed to be
carried in its original design.  You may want to argue in the same way
that CARD can carry LDAP queries if you need LDAP (and which would
make CARD less reastic solution).  BTW, if you want to carry XML, use
of http (or http over TLS if you need a secure channel) would be much
easier to deploy.

Ajoy-> I do agree that CARD or NED NOT are designed to support soley XML
encoding. Also. the idea of designing a protocol solely for XML encoding
is not necessary a good idea. But I was proposing CARD extension for XML
to accommodate some use cases where XML may be acceptable encoding. 

Yoshihiro Ohba

> 
> For example, CARD has an information filtering mechanism by based on
> Preferences and Requirements Sub-Options where filtering is important
> for reducing the amount of information exchanged over the air.
> 
> Ajoy-> Sure. The primary reason to use filter is to avoid sending
> unnecessary information over the air. If bandwidth is not important
then
> you can make a generic query to receive all possible mobility related
> information. 
> 
> However, when multiple AVPs are contained in the Preferences and
> Requirements Sub-Options, CARD is not clear as to whether the
> conditions specified by those AVPs are "AND" or "OR" conditions or
> both "AND" and "OR" conditions can be mixed.  Also, the Requirements
> Sub-Options do not seem to readily support inequality conditions such
> as "greater than" or range of values without specifying all AVPs that
> matches values in the range.  Also, I don't know how to specify a
> requirement when only one AVP with multiple fields is contained in the
> Requirements Sub-Option where the requirement is satisfied when only a
> specific sub-field of the AVP matches the specified value. 
> 
> Ajoy-> If you need complex query like that you can encode XML script
as
> value of one new filter as pointed out above.
> 
> (BTW, I
> don't understand why Preferences and Requirements should be
> distinguished while both are just filtering conditions.)
> 
> Ajoy-> The reason to distinguish Requirements and Preferences
> sub-options was again to maintain simplicity and clarity. The
> Preferences sub-option is used to select a subset of attributes
> interesting to the information requester. For example, you can express
a
> request like "give me data on channel, number of attached mobile
> stations, ESSID of access points".
> The Requirements sub-option is used to select a subset of neighboring
> devices meeting certain criteria. For example, you can express a
request
> like "give me data of access points that support 802.11g interface or
> 3GPP". By combining Requirements and Preferences, you can create more
> refined filters.
> 
> To repeat, the Requirements and Preferences sub-options were not
> designed to be comparable to generic query languages or XML scripts.
But
> you can carry, for example, XML-script based filter as an AVP in the
> sub-options.
> 
> Those issues are really important for dealing with heterogeneity.  I
> think an appropriate schema language and query language are needed to
> address those issues.  On the other hand, in the CARD protocol they
> are not clearly addressed or just left as out of scope. 
> 
> Ajoy-> I hope by encoding XML encoded script inside a TLV encoded
filter
> might address your need. 
> 
> To me the current CARD protocol is proprietary solution and hard to be
> applicable for supporting heterogeneous handovers.
> 
> Ajoy-> I hope my above answers might clarify some of your comments. 
> 
> Regards,
> Yoshihiro Ohba
> 
> 
> On Tue, Oct 11, 2005 at 08:55:26AM -0400, Singh Ajoy-ASINGH1 wrote:
> > 
> > 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[email-masked]] 
> > Sent: Monday, October 10, 2005 8:53 PM
> > To: Singh Ajoy-ASINGH1
> > Cc: Rajeev Koodli; [email-masked]; James Kempf;
> > [email-masked]; Petrescu Alexandru-AAP021
> > Subject: Re: [Mipshop] new charter
> > 
> > On Mon, Oct 10, 2005 at 04:20:25PM -0400, Singh Ajoy-ASINGH1 wrote:
> > > 
> > > Ajoy-> CARD provides generic query mechanism that can be used by
> > mobile
> > > node to query various mobility related information required for
> proper
> > > network selection. In my view, L2->L3 is nothing but one example
of
> > > information query.  IMHO, this does not belong to FMIP and better
> left
> > > to protocol such as CARD. 
> > 
> > I am not sure what is the definition of "generic" in the above text.
> > As far as I understand, a more generic query mechanism (than CARD)
is
> > based on an information schema language together with a query
language
> > that works for querying information defined using the schema
language.
> > 
> > Ajoy-> I am not comparing CARD query mechanism with XML. If folks
> think
> > XML is more appropriate then we will go with XML. CARD is generic
> enough
> > for mobility related query mechanism. 
> > 
> > Yoshihiro Ohba
> > 
> > > 
> > > If CARD provides target AR selection or router - router
> neoighborhood 
> > > map population, that could be useful.
> > > 
> > > Ajoy-> CARD provides a mechanism for information query that can be
> > used
> > > by network selection purpose. Target network selection itself is
> > > implementation.  
> > > 
> > > 
> > > Regards,
> > > 
> > > -Rajeev
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > Regards,
> > > > Ajoy 
> > > > 
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:[email-masked]] 
> > > > Sent: Monday, October 10, 2005 2:31 PM
> > > > To: Singh Ajoy-ASINGH1
> > > > Cc: Petrescu Alexandru-AAP021; [email-masked]; James Kempf;
> > > > [email-masked]
> > > > Subject: Re: [Mipshop] new charter
> > > > 
> > > > 
> > > > 
> > > > Singh Ajoy-ASINGH1 wrote:
> > > > 
> > > > 
> > > >>Ajoy-> I am confused why FMIPv6 needs to define Information
> Service
> > > >>protocol. 
> > > > 
> > > > 
> > > > It does not.
> > > > It continues to use the PrRt* messages, perhaps with a
harmonized 
> > > > message structure defined by the "handover information exchange"
> > > > protocol.
> > > > 
> > > > -Rajeev
> > > > 
> > > > 
> > > > 
> > > >>I guess FMIPv6 was defined to take care of routing aspect of 
> > > >>Fast Mobile/IP. CARD was deigned for Information Query Response
> and
> > > >>Context Transfer protocol was defined to transfer context from
one
> > AR
> > > > 
> > > > to
> > > > 
> > > >>other. 
> > > >>
> > > >>
> > > >>
> > > 
> > > _______________________________________________
> > > Mipshop mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mipshop
> > > 
> > > 
> > 
> > 
> 
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 12 Oct 2005 01:58:52 -0400

> b. The performance impact of XML on mobile devices is not known yet.

Bandwidth/performance requirement can be solved by a number of
techniques like compression and binary encoding.  That said, I think
functional requirement is more important than bandwidth/performance
requirement.  Regarding XML, if bandwidth/performance is more
important, why 3GPP2 has dependency on several XML-based technologies
such as XCAP?

Yoshihiro Ohba