From:
stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of Peretz Feder
Sent: Sunday, January 29, 2006
5:47 PM
To: Subir Das
Cc: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] Transport
protocol issue!
Subir:
If R1 is available, it means we have peers of MIHF that are able to exchange
MIH frames with each other OTA using the native L2.
Under such condition, L2 should be used between these two. Why would L3
be considered for MIH frame exchange when R1 is available to be used.
When R1 is not available, L3/L4 is the next logical case.
Why did we bother defining MIH frame at all for L2? Should we have defined MIH
packet instead?
Peretz Feder
[Vivek G Gupta]
I can think of at least one case where a client may prefer
L3 over L2 for Information Service (IS) access.
Since the information obtained from IS is usually consumed
at higher layers it makes it easier from an implementation perspective to
query/retrieve
these IEs at L3, instead of at L2. So if L3 connection is
available, a client may prefer L3 over L2 in this case.
However if the client is not connected to any access network
(does not have L3), it may have to go with L2 anyway (at least initially).
So it’s not really an issue of defining MIH frame vs
MIH packet etc.
In general it’s preferable not to lay down usage/deployment
preferences in the normative sense in the specification.
On 1/27/2006 9:54 AM, Subir Das wrote:
Peretz,
Why do we want to do this way? Does this mean if we have L2 we
don't need L3 for all cases?
regards,
-Subir
Peretz Feder wrote:
and it will always attempt L2 (bridging) first and when R1is not
available it will attempt to transport its PDU by opening a UDP/TCP
socket
On 1/24/2006 9:53 AM, Stefano M. Faccin wrote:
Kalyan,
Thanks for the clarification. I believe we should strive for transparency of the transport protocol, i.e. the MIHF does not know which one is used.
Stefano
-----Original Message-----
From: ext Kalyan Koora [mailto:kalyan.koora@benq.com]
Sent: Tuesday, January 24, 2006 8:25 AM
To: Faccin Stefano (Nokia-NRC/Dallas); STDS-802-21@LISTSERV.IEEE.ORG
Subject: AW: [802.21] Transport protocol issue!
Hi Stefano,
with #2 I mean, whether the MIHF should know how the transport
protocol is constructed.
If the answer is yes, then we have some sort of dependency.
Example, a change in transport protocol (from its standard)
needs a change in the MIHF, at the minimum from implementation
point of view.
regards,
Kalyan
-----Ursprüngliche Nachricht-----
Von: Stefano M. Faccin [mailto:stefano.faccin@NOKIA.COM]
Gesendet: Dienstag, 24. Januar 2006 15:05
An: STDS-802-21@LISTSERV.IEEE.ORG
Betreff: Re: [802.21] Transport protocol issue!
Kalyan,
Can you elaborate a bit more on #2?
Stefano
-----Original Message-----
From: ext Kalyan Koora [mailto:kalyan.koora@BENQ.COM]
Sent: Tuesday, January 24, 2006 3:23 AM
To: STDS-802-21@listserv.ieee.org
Subject: [802.21] Transport protocol issue!
Hi All,
while going through the present draft, couple of questions
arised where I would like to hear to the experts opinions.
Considering: Communication between 2 MIHF peers using MIHF protocol
with an arbitrary transport protocol.
1. Should the MIHF know over which transport protocol messages are
exchanged?
2. Should MIHF be in a position to dissect the transport protocol?
(if yes, then do we have transport protocol dependency?)
3. Is PPP also a possible transport protocol for MIHF communication?
Regards,
Kalyan