Re: [802.21] transport layer for MIH IS.
Mike and others,
I am not sure there has to be a transport issue for MIH. (As others have pointed out, we are
at this point still not entirely sure what this MIH layer really delivers. But I really hope
that we will never have to face the issue of selecting a transport for MIH.)
Depending on how we evolve it, MIH can be either made into a pure local layer (i.e., it only
interacts with its upper and lower layers), or a full-blown communication layer/endpoint
(i.e., it can have own peers and can originate and consume messages). If the latter case,
the design and implementation complexity of MIH would multiply, since once you start to
originate and consume messages you will have to deal with message loss, retransmission,
queuing and buffering, traffic/congestion management, timer management... and other horrible
horrible issues. IMO we should try at all cost to avoid making MIH into an endpoint itself.
If we succeed in refraining ourselves from making MIH into a full-blown endpoint, we also
would save ourselves from the trouble of picking a transport for it.
regards,
-Qiaobing
Mike Moreton wrote:
> It may be that you covered this in more detail at your meeting...
>
> I can think of at least 4 different possibilities:
>
> (1) Define new MAC specific management frames (e.g. a variant of action frames in 802.11). This would require changes to each MAC specification, but would allow the MAC to give these frames whatever priority was required.
>
> (2) Transport in an L2 data frame with a new Ethertype allocated for the protocol. This would not require any MAC changes for an 802 MAC, but would require you to live with the different priorities available for data frames, and probably would need some special support within cellular.
>
> (3) Carried in IP packets. Gives you wider addressability than L2, but it's not clear that you need this if you're only going from STA to AP (or whatever you call them). In practice, the IETF are likely to insist on you using UDP encapsulation.
>
> (4) Carried over TCP. Built-in reliability, but do you want it?
>
> Plus all the advantages and disadvantages you've already mentioned...
>
> Mike.
>
>
>
> -----Original Message-----
> From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org] On Behalf Of David Xiang
> Sent: Thursday, January 20, 2005 8:31 PM
> To: STDS-802-21@listserv.ieee.org
> Subject: [802.21] transport layer for MIH IS.
>
>
> When we consider the complexity of .21 implementation and interaction with
> other media standard, we need to think of our transport layer for
> information service exchange with network or peer, though it seems out of
> scope of .21 from most of the proposals.
> I saw two ideas of transport layer from the proposals: IP application, and
> L2. I just want to get your thoughts on which one is better.
>
> IP:
> Pros: 1. Generic and less impact on other media standard,
> 2. Give more implementation flexibility for .21 information service
> and other requirements.
> 3. More easy to be implemented.
>
> Cons: 1. slow
> 2. Not reliable or robust as L2 transport, but IP application can
> become robust with some good mechanisms.
>
> L2:
> Pros: 1. faster
> 2. More robust
>
> Cons: 1. Too rely on other media standard which may not good for .21
> implementation.
> 2. Not flexible, any time .21 do some changes on SI, it may request
> all other media standard to do some changes too.
>
> Any thoughts?
>
> Thanks,
>
> David
>