From: Peretz Feder
[mailto:pfeder@lucent.com]
Sent: Sunday, January 29, 2006
9:52 PM
To: Gupta,
Vivek G; STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] AW: [802.21]
Telecon on source/destination Ids within different primitives
Hello Vivek: see in-line
Peretz Feder
"The selection between L2 and L3 is based on other factors and the entity which does that is outside scope of
802.21.
[PF] What is the argument to eliminate MIH from selecting the transport mechanism?
If that entity is outside scope, any interfaces exposed by that entity is also outside scope.
[PF] why is the transport selection out of scope?
In 802.21 since MIH Function is the only entity in scope, we should focus on specifying interfaces/primitives from
MIH Function only and not specify interfaces from other components/layers in the system such as network(IP),
transport, application etc."
[PF] Are you advocating MIHF shouldn't decide what transport mechanism to use? Please provide the reasons.
Think L2 for a second, wouldn't MIH frame from a client device to a peer be transferred by the MIHF? If you say no,
then MIH either has to move the MIH frame to the MAC layer or to the IP layer. To me that is a switching point that
MIHF needs to determine through some interface. If not determined by MIHF, who will and how?
On 1/29/2006 6:41 PM, Gupta, Vivek G
wrote:
Peretz,
some comments below.
<clip>
“MIH will attempt to always transport over R1 when R1 is
available” instead of over R3:
..which basically means, L2 will always be
preferred over L3:
Is this always true?
When R1 is available and MIH entity (function) exists at the other side
of R1 (OTA), there should be no reason not to attampt to transport the MIH
frame over the native L2 interface.
Do we really need to make
such assertions in 802.21 Specification?
yes for our IEEE spec, which is L2 (or L2 plus) in nature.
[Vivek G Gupta]
Even though 802.21 is an IEEE spec, it’s not just L2
in nature.
If that is the case, maybe we should remove reference to all
mention of MIH communication over L3…
I would prefer to keep such
statements out of the normative part of the specification.
I am also not sure what do we gain by
introduction of MIH_NET_SAP.
Apart from that most of what this
contribution specifies is already there in the new draft.
MIH_NET_SAP is required so that the selection of the transport mechanism to be used can be determined.
[Vivek G Gupta] The selection between L2 and L3 is based on other factors and the entity which does that is outside scope of 802.21. If that entity is outside scope, any interfaces exposed by that entity is also outside scope. In 802.21 since MIH Function is the only entity in scope we should focus on specifying interfaces/primitives from MIH Function only and not specify interfaces from other components/layers in the system such as network(IP), transport, application etc.
If the transport decision resides in the MIH Function, then the MIH Function must be aware of the transport resources that are available (L2 or the specific L4). If the transport decision
resides outside the MIH Function, we need an interface to such Transport-Selector.
As MIH function is aware about the availability of R1, MIH should always pass the message to the local L2 when available. If L2 is not available, MIH should pass the message to a Higher-Layer-Transport-Selector entity (through MIH-NET-SAP) on which it has no control.