Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Discussion on transport protocol selection for MIH!



Hello All,

at first I am glad to see that some discussion has started on
the reflectors regarding 802.21 related aspects after a long break.
I hope it will give a good result this way.

While defining transport protocols for 802.21 service elements
(ES, CS & IS), we have to keep couple of points in mind 
[Ref: .21 draft]:

- the information exchange should be done fast
- the overhead in exchange of information should be as less as possible
- the extraction of the information at the terminal should not include 
  high computational complexity

Though this is defined within IS section, this is valid for all
the service elements.
Within the present .21 draft, a 'common' frame format for service
element exchange is defined. Irrespective of the transport protocol,
this (future standardised) frame format should be taken as a
requirement which should be embedded into the transport protocol
without any change. That is, encapsulating the .21 frame in the
transport protocol.

From my point of view, it is ideal to define ONE standardised 
transport protocol to carry the service elements between different
MIH peers. This protocol should be 'ideally' able to:

- carry the service elements ES, CS and IS
- exchange the information with little delay (without complicated
  acknowledge methods with CRCs, retransmissions)
- enable the client/station to extract the information quickly
  and forward them to higher layers.

These requirements do recommend to select transport protocols which
are suited for layers as low as possible (eg. layer 2).

I see that contrains in selection of lower layer protocols are
arising mainly due to the IS. This is because the IS involves
in carrying different network discovery and service discovery
information. Further, a part of IS is of dynamic type, i.e.
some service may be available at a particular time only.

Problem factor (from IS point of view)
- If we select lower layer protocols, it is almost impossible
  to deliver complete IS in request/response method.
- If we select higher layer protocols (eg. layer 3), it is 
  difficult for the IS to be delivered before a generic layer
  related connection is established (if we consider IP, then
  prior to exchange of info an IP connection is to be established).
- On the other side, if complete IS is not available at mobility
  protocol, it is not possible to select and connect to an 
  appropriate network.

Thus, both of the protocol selections do have their own advantages 
and disadvantages.

Atleast to overcome part of the difficulty, it has been decided
to divide the IS into basic and extended set. The main intention
of the baisc set is 
- to be delivered as soon as possible without much delay
- to keep the amount of information as small as possilbe
- to extract the information without any great complexity
- to embed less secure information

This basic set enables the client/station to have a knowledge
of the network and allow it to decide to ask for extended information
if needed. Either the higher layer can do this it self, like 
enabling a connection and asking for extended set or the higher
layer can ask MIH to get this information.
The extended set can have secure information elements.

Now keeping all these points in mind, and seeing the discussion
on the mailing lists, I feel, that we have to divide the 802.21 
service elements into 2 categories:

category 1 for ES, CS and Basic IS (BIS)
category 2 for Extended IS (EIS)

and transport protocols have to be discussed for them independently
as the requirements of both the categories are a bit different.
Further, the 1st categorie is intented to be transmitted between
client/station and the Point of Attachment (PoA) with "relatively"
less data. Weheras, the 2nd category can be carried over gateways, 
routers, etc. where there is "relatively" much data.

Couple of questions on experts:

- If this is agreed, shall the BOF discussed for future shoud cover both?
- In our draft, we mentioned about an option "MAC Management Frames" 
  carrying MIH service elements. If the aim of the group is to
  develop some protocols just like EAPoL, then are these considered
  as Management or Data frames?
- If the above answer is "data frames", then does .11 or .3 presently 
  allows to access management frames from higher layers (layer 3 
  and above)?
- Where is the correct place for such discussions IEEE or IETF or ???
  To my understanding lower layer protocols like EAP, ARP are also 
  topic of IETF.

Waiting eagerly to get your comments,

with best regards,
Kalyan