Subject: [Mipshop] Some comments on draft-faccin-mih-infoserv-01

From: Dirk Kutscher <[email-masked]>
Date: Thu, 20 Oct 2005 18:30:53 +0900

Folks,

I have written up some comments on draft-faccin-mih-infoserv-01 and on 
the architectural discussion in general -- maybe it is useful.

In the previous discussions there seem to be different opinions about 
what an MIIS activity in the IETF should do:

	- Should it develop an MIIS for specific IETF mobility
           protocols, i.e., advancing what has been done with CARD and
           FMIP off-link inverse ND?

	- Should it "simply" provide an IP-based transport for whatever 
   	  IS will be finally specified in an 802.21 standard document?

	- Should it develop an even more general information
           service, i.e., addressing hand-over but also some form of
           service location for higher-layer services, e.g., describing
           hotspot authentication and tariff options and describing VoIP
           services in network-topological or geographical scopes, while
           being extensible to future applications?

It should be noted that the current 802.21 draft itself proposes an IS 
that provides information for different layers ("general network, link 
layer, and higher layer information").

The Internet Draft seems to describe scenarios for an IP-based IS that 
are compatible with the 802.21 model. Based on the 802.21 framework, you 
are describing  different scenarios (IS-server on AP, IS-Server on 
subnet router, standalone IS-server) and are considering potential 
extensions such as segregating discovery and info retrieval.

These scenarios seem to be the basis for splitting up the problem space 
into different areas in section 4, where section 4.1 identifies the 
involved entities ("mobile", IS-Server) and the overall operations, 4.2 
describes abstract communication processes, 4.3 discusses the discovery 
of IS-server discovery, 4.4. talks about TCP as a transport protocol, 
and 4.5 illustrates some security problems.

Section 5 is providing a list of specific requirements for protocol 
development, section 6 lists outstanding issues, and section 7 discusses 
security issues based on the currently assumed architecture.

My questions and comments:

1) I understand that the draft presents transport protocol requirements. 
But do we think that the use cases and general functional requirements 
are complete? For example, there seems to be the implicit assumption 
that an IS will always be accessed in an interactive 
query/response-style. (This is what the 802.21 document is proposing). 
Now, for a non-realtime IS for distributing information about available 
network services in a certain network-topological or geographical scope, 
one could also consider multicast/broadcast distribution. For example, 
in some countries, DVB (terrestial or satellite-based) can provide quite 
inexpensive multicast distribution channels that could be utilized for 
IS (relying on some receiver-based filtering). The argument here would 
be, that you not only have to consider heterogenous networks but also 
heterogenous transport protocols, depending on the currently used 
network and (maybe) application requirements. This would certainly imply 
additional transport protocol requirements that have not been considered 
so far.

2) IMO, the motivation for MIIS is to support mobility in heterogenous 
network environments, e.g., in scenarios where I use one interface to 
connect to an IS in order to find out details about services that are 
accessible over another interface (as the Internet Draft describes). 
Now, I think these scenarios imply additional requirements for uniquely 
identifying and authenticating service descriptions. For example, the 
same service description may be available from different ISs, and I want 
to make sure that I can uniquely identify it. This is especially 
important when we consider periodic transmission, e.g., in multicast 
distribution scenarios.

3) Authentication of service descriptions: The Internet Draft addresses 
this, but I am again not sure, if we have defined all the use cases we 
want to support. E.g., do we want to support aggregation (and possibly 
filtering) and re-distribution of service descriptions? This would 
certainly imply additional requirements -- you want to be able to 
authenticate single service descriptions as well as the aggregate and so on.

I have another general comment (not on the Internet Draft itself): I am 
not sure that it is a useful approach to separate the IS content 
discussion from the IS transport discussion, i.e., by saying the IETF is 
to develop an IP-based transport for the IEEE 802.21 IS format.

We have had the discussion about XML vs. TLV. James has correctly 
pointed out that XML is a useful technology for providing structured 
information representation and extensibility for text-based 
applications, while it may be not so optimal for communication processes 
on the system level, e.g., resource- and time-critical communication for 
seamless handover. So, it might be better to have a good, consistent 
understanding of what you want to distribute and how you want to do it. 
I am not talking "architecture" here, but there are relations that 
should be considered.

In addition, the requirements that originate from the discussion of 
transport mechanisms (request/response, multicast, authentication 
issues) might in fact influence the design decisions of the content 
representation, e.g., with respect to unique identification and 
authentication.

A final comment on the IEEE 802.21 draft: As I read it, the document 
defines a logical data schema for IS, not the actual representation. So, 
it uses RDF to formally define the schema but does not say that is must 
(e.g.,) be represented in XML. In fact, the 802.21 draft itself mentions 
the possibility to distribute the link layer info directly over L2 
protocols and has an example of an ASN.1 representation.

The general approach seems to make sense (it does not have to be RDF 
though). I think you want a logical data schema that allows you to 
express structured information (also with some notion of data types) and 
that also provides for structured extensibility, i.e., you want to be 
able to distinguish the important, standardized information elements 
from additional, maybe vendor-specific ones. Also you want to avoid name 
clashes of this extension vocabulary, if possible without requiring a 
central registry. Addressing this on the conceptual level (as 802.21 
seems to be trying to do) does not keep you from coming up with 
efficient representations for conveying the information in certain 
scenarios. In fact, you could also have both: the efficient 
representation for a well-defined set of applications and a more 
flexible representation (say XML-based) for the higher-layer ISs.

Best regards,

Dirk

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Oct 2005 10:55:53 -0700

Dirk,

What I take away from your extensive comments is that the scope of the 
requirements in draft-faccin is so broad that is is difficult to decide what 
approach to take.

The intent of the CARD and FMIP information services work was specifically 
focussed at providing a host with information about surrounding access 
points for which it has some sort of L2 access point identifier, in order to 
faciliate predictive handover optimization. The NED work is intended to 
extend this with a query procedure that is simpler than CARD but richer than 
FMIP, and, additionally, to remove some information representations that 
were built in to the protocol for CARD, so that the only information 
representation fixed in the protocol is the L2 access point identifier and 
the link technology identifier, which the host must know because it must 
have an interface card in order to hear access points, and it must be able 
to hear access points in order to want to consider handing over to them. 
Other link characteristics can be defined to depend on the link technology.

Some of the broader uses for IS you've suggested, such as advertising 
tariffs, hotspots and service offerings, were discussed during the CARD 
work, but it was my opinion then and still is now that it is unlikely these 
would see deployment in cellular style networks due to operator business 
considerations. In hotspot networks, there are other existing means that are 
more likely to see wider deployment. Certainly, w.r.t. facilitating 
predictive handover optimization, these broader uses are pretty irrelevant, 
IMHO.

With regard to the 802.21 draft, I have not looked at it recently. In other 
cases, such as LDAP, a schema such as you mention can be instantiated using 
ASN.1 in the protocol, so I expect that would be the intent with 802.21, 
though I understand that the choice of representation has not yet been made. 
The kinds of information needed for predictive handover optimization are 
fairly straightforward, and I don't see the need for an extensive schema to 
describe them. I am not sure it is such a good idea to mix this simple 
information with the more complex information that might be required for the 
broader uses. However, it certainly would be possible to have a container 
that would handle both, and that is the intent of NED. Whether keeping the 
container independent of the information representation is useful in 
simplifying implementation and deployment is a question that I think we need 
to answer.

            jak

----- Original Message ----- 
From: "Dirk Kutscher" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Thursday, October 20, 2005 2:30 AM
Subject: [Mipshop] Some comments on draft-faccin-mih-infoserv-01

> Folks,
>
> I have written up some comments on draft-faccin-mih-infoserv-01 and on the 
> architectural discussion in general -- maybe it is useful.
>
> In the previous discussions there seem to be different opinions about what 
> an MIIS activity in the IETF should do:
>
> - Should it "simply" provide an IP-based transport for whatever IS will be 
> finally specified in an 802.21 standard document?
>
> The Internet Draft seems to describe scenarios for an IP-based IS that are 
> compatible with the 802.21 model. Based on the 802.21 framework, you are 
> describing  different scenarios (IS-server on AP, IS-Server on subnet 
> router, standalone IS-server) and are considering potential extensions 
> such as segregating discovery and info retrieval.
>
> describes abstract communication processes, 4.3 discusses the discovery of 
> IS-server discovery, 4.4. talks about TCP as a transport protocol, and 4.5 
> illustrates some security problems.
>
> But do we think that the use cases and general functional requirements are 
> complete? For example, there seems to be the implicit assumption that an 
> IS will always be accessed in an interactive query/response-style. (This 
> is what the 802.21 document is proposing). Now, for a non-realtime IS for 
> distributing information about available network services in a certain 
> network-topological or geographical scope, one could also consider 
> multicast/broadcast distribution. For example, in some countries, DVB 
> (terrestial or satellite-based) can provide quite inexpensive multicast 
> distribution channels that could be utilized for IS (relying on some 
> receiver-based filtering). The argument here would be, that you not only 
> have to consider heterogenous networks but also heterogenous transport 
> protocols, depending on the currently used network and (maybe) application 
> requirements. This would certainly imply additional transport protocol 
> requirements that have not been considered so far.
>
> accessible over another interface (as the Internet Draft describes). Now, 
> I think these scenarios imply additional requirements for uniquely 
> identifying and authenticating service descriptions. For example, the same 
> service description may be available from different ISs, and I want to 
> make sure that I can uniquely identify it. This is especially important 
> when we consider periodic transmission, e.g., in multicast distribution 
> scenarios.
>
> We have had the discussion about XML vs. TLV. James has correctly pointed 
> out that XML is a useful technology for providing structured information 
> representation and extensibility for text-based applications, while it may 
> be not so optimal for communication processes on the system level, e.g., 
> resource- and time-critical communication for seamless handover. So, it 
> might be better to have a good, consistent understanding of what you want 
> to distribute and how you want to do it. I am not talking "architecture" 
> here, but there are relations that should be considered.
>
> transport mechanisms (request/response, multicast, authentication issues) 
> might in fact influence the design decisions of the content 
> though). I think you want a logical data schema that allows you to express 
> structured information (also with some notion of data types) and that also 
> provides for structured extensibility, i.e., you want to be able to 
> distinguish the important, standardized information elements from 
> additional, maybe vendor-specific ones. Also you want to avoid name 
> central registry. Addressing this on the conceptual level (as 802.21 seems 
> to be trying to do) does not keep you from coming up with efficient 
> representations for conveying the information in certain scenarios. In 
> fact, you could also have both: the efficient representation for a 
> well-defined set of applications and a more flexible representation (say 
> XML-based) for the higher-layer ISs.
>
>
> Best regards,
>
> Dirk
>

---

From: Dirk Kutscher <[email-masked]>
Date: Fri, 21 Oct 2005 14:37:46 +0900

James Kempf wrote:

> requirements in draft-faccin is so broad that is is difficult to decide 
> what approach to take.

James,

well, that is not what I wanted to communicate primarily, but: there are 
simply different conceivable application scenarios and requirements you 
can base your approach on. IMO, it would be useful to explicitly state 
and discuss these assumptions.

E.g., NED seems to be addressing a well-defined problem: it's a packet 
format for network information, where you ask for details of entities 
with a known L2 identifier, relying on request/response interactions. 
OK, this can be a valuable component of an IS, if you limit yourself to 
querying details of entities that you have located by scanning on the 
respective interface. It is clearly intended for FMIP-like applications, 
which is fine.

It just has to be made clear that this is a different approach than 
defining a general, extensible IS inlucluding transport protocols, for 
which draft-faccin has started to collect requirements for. 
draft-faccin, and the whole discussion about re-chartering mipshop, 
could IMHO benefit from defining the intended applications explicitly, 
i.e., which problem are we trying to solve.

> work, but it was my opinion then and still is now that it is unlikely 
> these would see deployment in cellular style networks due to operator 
> business considerations. In hotspot networks, there are other existing 
> means that are more likely to see wider deployment. Certainly, w.r.t. 
> facilitating predictive handover optimization, these broader uses are 
> pretty irrelevant, IMHO.

Sure, this is a different use than enabling predictive handover.

I understand the concerns wrt to business considerations for 
distributing information about other providers' networks etc. But when I 
look at, e.g., WLAN hotspots today, there are two problems that I feel 
should be solved (these are all well-known):

1) Locating hotspots: There are numerous "hotspot finder" websites, 
directories etc. that are mostly intended for manual usage, i.e., you 
use your web browser to search for something suitable in your current 
location. I think this could clearly be optimized by an IS. Wrt business 
considerations, many operators provide services for both, say, 3G and 
WLAN, and should have an interest to distribute this information.

2) Associating with hotspots: The current UAM-based approach essentially 
inhibits automated association. You need a human user to select 
providers, tariffs, payment options etc. It get's more complicated when 
you start using applications such as VoIP and want to figure out the 
local proxy and other parameters. Again, an IS, could make the required 
information available in a more useful way.

I think these are valid uses of IS. But they are something else than 
predictive handover.

IMO, the first questions we need to answer should be:

1) Which use case are we addressing here (predictive handover vs.
    "broader use")?

2) Does this relate to 802.21 or not?

3) If "broader use" is considered in-scope: how does broader-use fit to
    predictive handover, e.g., is there any use for a common approach for
    information representation and transport protocols.

Best regards,

Dirk