Re: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives

[Peretz Feder <pfeder@LUCENT.COM>]

Title:

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.

---

From: Peretz Feder [mailto:pfeder@lucent.com]
Sent: Sunday, January 29, 2006 1:17 PM
To: Gupta, Vivek G
Cc: Kalyan Koora; STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] AW: [802.21] Telecon on source/destination Ids within different primitives

 

<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.