RE: [802.21] Discussion on transport protocol selection for MIH!
[Gupta, Vivek G]
Actually the difficulty is for the first time, when you are powering up
or in an un-initialized state or don't have any of the links connected.
At that time which initial link to select may be an issue.
But then you could always have a default radio/link to use in such
cases.
Ajoy-> Yes, but that is initial call setup scenario. Do we really need any seamlessness during initial call setup?
-----Original Message-----
From: Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
Sent: Sunday, July 17, 2005 9:45 AM
To: Singh Ajoy-ASINGH1; Koora Kalyan Com Bocholt; STDS-802-21@listserv.ieee.org
Subject: RE: [802.21] Discussion on transport protocol selection for MIH!
> -----Original Message-----
> From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]
On
> Behalf Of Singh Ajoy-ASINGH1
> Sent: Sunday, July 17, 2005 6:36 AM
> To: 'Koora Kalyan Com Bocholt'; 'STDS-802-21@listserv.ieee.org'
> Subject: RE: [802.21] Discussion on transport protocol selection for
MIH!
>
> Hi Kalyan,
>
> I would like to comment on one of your statement here.
>
> Regards,
> Ajoy
>
>
> 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
>
> Ajoy-> If you have multi-link mobile, you can use IP transport of
> connected link to obtain information about neighboring link.
[Gupta, Vivek G]
Actually the difficulty is for the first time, when you are powering up
or in an un-initialized state or don't have any of the links connected.
At that time which initial link to select may be an issue.
But then you could always have a default radio/link to use in such
cases.
>
> -----Original Message-----
> From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]
On
> Behalf Of Koora Kalyan Com Bocholt
> Sent: Thursday, July 14, 2005 5:38 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: [802.21] 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