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

RE: [802.21] Transport protocol issue!



 


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