RE: [802.21] Discussion on transport protocol selection for MIH!
Hi Kalyan,
Please find my inline replies.
Regards,
Ajoy
-----Original Message-----
From: Koora Kalyan Com Bocholt [mailto:kalyan.koora@siemens.com]
Sent: Tuesday, July 19, 2005 2:11 AM
To: Singh Ajoy-ASINGH1; 'Gupta, Vivek G'; STDS-802-21@listserv.ieee.org
Cc: mihep@eng.monash.edu.au
Subject: AW: [802.21] Discussion on transport protocol selection for MIH!
Hi Ajoy,
let me put up an other scenario where it is also not possible to get
information over higher layer.
Let us assume you have an IP connection over a cellular interface like
3GPP and your in a foreign country. You come up to a hotspot where you
don't have any knowledge of the ISPs over there. Further, it is possible
that some come up and some go down time to time. In this case how does
the cellular provider knows about the hotspot?
Ajoy-> Let me understand your question here. I am assuming that hotspot provider is MIH enabled.
There are several ways to do this:
a. If you know the IP address of MIH server of 802.XX link, you can directly communicate with MIH server using L3 cellular transport.
b. Alternatively, maintain cellular link and establish L3 connection with 802.XX ISP and then use L3 connection to obtain capability information of 802.XX link.
Let me ask you, how L2 based solution will be better in this case. I would like to get your view of L2 based solution so that we can compare how L2 based solution will work any better than L3 based solution. As I stated in my earlier email, I am not opposed to extending L2 to do this, but I need to better understand your view about L2 based solution so that I can compare apple to apple. This also applies to you earlier question.
Or do you assume that all
the ISPs at hotspots do have some agreements with the cellular ISP? Some
of them could be just 'local' ISPs using firewall/NAT/masquerading
techniques and are not interested in cellular providers.
In this case too, you may have the possiblity to handover to the hotspot
ISP if you find any suitable provider.
Regards,
Kalyan
-----Ursprüngliche Nachricht-----
Von: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
Gesendet: Montag, 18. Juli 2005 17:07
An: 'Gupta, Vivek G'; Koora Kalyan Com Bocholt;
'STDS-802-21@listserv.ieee.org'
Betreff: 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
Ajoy-> 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