RE: [802.21] transport layer for MIH IS.
|-----Original Message-----
|From: owner-stds-802-21@LISTSERV.IEEE.ORG [mailto:owner-stds-802-
|21@LISTSERV.IEEE.ORG] On Behalf Of Mike Moreton
|Sent: Tuesday, January 25, 2005 2:11 AM
|To: STDS-802-21@LISTSERV.IEEE.ORG
|Subject: RE: [802.21] transport layer for MIH IS.
|
|Vivek,
|
|Thanks - that makes sense. In which case an IP transport is definitely
not
|an alternative.
[Gupta, Vivek G]
Yes, that's been the initial thinking.
|
|Am I right in saying that there may be two parts to this? Some sort of
|basic information transfer that happens before authentication (but must
be
|limited in scope due to the lack of authentication), followed by an
ongoing
|protocol exchange.
[Gupta, Vivek G]
Mike you are right again. We are currently in the process of doing this
analysis for the different information elements. Most of the information
under consideration at this time is basically static type of
information.
|
|The former must be embedded in L2 protocols (e.g. 802.11 management
frames)
|while the latter can be encapsulated in L2 (either via an ethertype, or
in
|UDP/IP).
|
[Gupta, Vivek G]
That seems right, though our focus so far has mostly been info at
L2..(mgmt frames). Given that would it not be preferable to have a
single way of doing this if possible (mgmt frames only)...say a
different set of mgmt frames or a flag somewhere which helps to
distinguish the two sets of information (unauthenticatd/authenticated)?
Anyway if there is information that can be accessed only after
authentication, then that needs to be specified and someone needs to
know about that and enforce it and we could possibly use that fact in
the transport.
Best Regards,
-Vivek
|
|-----Original Message-----
|From: owner-stds-802-21@LISTSERV.IEEE.ORG [mailto:owner-stds-802-
|21@LISTSERV.IEEE.ORG] On Behalf Of Gupta, Vivek G
|Sent: Monday, January 24, 2005 4:34 PM
|To: STDS-802-21@LISTSERV.IEEE.ORG
|Subject: Re: [802.21] transport layer for MIH IS.
|
|
|Mike,
|
|We discussed the first two options during our meeting.
|The other advantage of (1) is that we may be able to transfer data
|through an unauthenticated port in cases of MACs which currently may
not
|allow say Class 1 data frames. We may be trying to solve a larger media
|specific problem here. While (2) may be required for supporting media
|like Ethernet(not sure how good an argument that is).
|(1) definitely requires changes to other standards while in case of (2)
|we may get by without any changes to media specific MACs.
|
|Best Regards,
|-Vivek
|
||-----Original Message-----
||From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]
On
||Behalf Of Mike Moreton
||Sent: Monday, January 24, 2005 6:06 AM
||To: STDS-802-21@listserv.ieee.org
||Subject: RE: [802.21] transport layer for MIH IS.
||
||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.
||