| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Answers are inline. -----Original Message----- Hi Ronny, Maybe, you're expressing valuable points. However, I
am having hard time understanding your view. I would like to hear your opinions. Thanks in advance. My questions are inline. > -----Original Message----- > From: Ronny Kim [mailto: > Sent: Tuesday, January 10, 2006 > To: STDS-802-21@listserv.ieee.org > Subject: Re: [802.21] MIH Protocol message naming > > > MIH protocol message format is used for remote
message > exchange between MIH function entities remotely.
Because of > the nature of the MIH, there are two transport
mechanism one > is using control plane and the other is using
data plane > either L2 or L3. Good up to here... > When control plane is used, **message format** is
media dependent > and primitives will provide information to the
media specific > MAC for MIH related signaling. > When Data plane is used, message format defined
in Section 8 > will be used. What's the difference whether the MIH protocol message
is delivered by L2 control or data plane? For clarification, the above mentioned "message
format" means MIH protocol message itself? [Ronny]
Yes Then, why this MIH protocol message needs to be
delivered media dependently in case where the L2 control plane is
used? [Ronny]
I don’t make decision for media specific changes. If the media specific group
feels that there are already existing L2 control messages and if they want to
extend their existing messages, then MIH protocol messages defined in section 8
can no longer be used. Can't it be delivered as its defined form by the
payload of that L2 control message? Let me share your view on this. [Ronny]
In case of using 802.16 generic MAC management message which is explained below,
MIH protocol messages without MIH header can be delivered. > IMO, with this understanding, naming should be
similar to the > primitives. > Because media dependent management frames will
use different > name, their own name and will covey contents
provided by primitives. > For example, we have 802.16 generic MAC
management message > container accepted at last meeting. In that
container, > messages defined in section 8.4 will be
encapsulated without > MIH message header. Why? How can a peer MIH function entity decrypt the
MIH protocol message without MIH header? [Ronny]
That is because receiving MAC can extract MIH related information and put that
information in the corresponding Primitives to deliver up to MIH function. Therefore,
in this case we don’t need to include MIH protocol header. Regards, Junghoon If media specific group decided to extend > their management messages, e.g, 802.16
MOB_BSHO_REQ /RSP to > include MIH related information, then nothing
defined in > section 8 will affect the message. Primitives
will provide > information to the specific MAC layer for MIH
related > information. If we just want to use new ethertype
or layer > 3-this is a case of using data plane-, then in
layer 2 data > frame or layer 3 data frame MIH Packet format
defined in > section 8 will be encapsulated. > > Thanks, > -Ronny > > > -----Original Message----- > From: Gupta, Vivek G
[mailto:vivek.g.gupta@INTEL.COM] > Sent: Sunday, January 08, 2006 > To: STDS-802-21@listserv.ieee.org > Subject: Re: [802.21] MIH Protocol message naming > > > -----Original Message----- > > From: Junghoon Jee [mailto:jhjee@etri.re.kr] > > Sent: Sunday, January 08, 2006 > > To: Gupta, Vivek G; 'zze-Seamless PERESSE M
ext RD-RESA-REN'; > STDS-802- > > 21@listserv.ieee.org > > Subject: RE: [802.21] MIH Protocol message
naming > > > <clip> > > > > > > > > > Hi Junghoon, > > > > > > > > I agree with your statement. I
guess MIH Function Message should > > > > simply not have a "primitive
like" naming scheme, since it > > > is confusing. > > > > > > > > However, these messages will be
transmitted using other > > > media specific > > > > primitives: for example, in 16g
(if I understood correctly), 4 > > > > primitives (section 6.3.2.3 in the
16g draft) are used to > > > transmit and > > > > receive MIH messages (1 Request
and 1 Response in both > > > directions). Another example: > > > > for 11 and 3 we can use LLC
primitives to send MIH message over > > the > > > > data plane. For L3 transport, I
guess MIH messages can be > > > transported > > > > using an implementation specific
access point (e.g. > socket), since > > > > > > their is no such thing as a SAP
within IETF. > > > > > > > > I think we should separate
interactions that deal with the > > > local MIH > > > > message passing (i.e. MIH_X
primitives that MIH users > will use and > > > > > > Link_X primitives the MIH Function
will use) from the > interactions > > > > > > that deal with the MIH message
transport (i.e. Media (or > > Transport) > > > > Specific facilities the MIH
Function will use to transport > > > MIH messages). > > > > [Vivek G Gupta] > > > MIH protocol shall only use MIH
messages and not Link layers > > > messages (since link layer messages
shall be local only). > > > > > There is a lot of similarity in naming
between Table-8 and > > > Table-13 in the draft (SAP primitives
and actual MIH > > > messages) which may not be a bad thing. > > > > The issue is not whether this is bad or
good. > > Clearly representing the MIH protocol
messages not to be > confused with > > local primitives needs to be done. > > > > --Junghoon > > > [Vivek G Gupta] > Absolutely. > Initially link layer messages could also be
remote and that was adding > to confusion. Things should get better with clear
separation of > primitives and clarity in what is local and what
can be > remote. I agree > that it is the representation and definition of
protocol messages that > has to be updated as opposed to just the naming. > Best Regards > -Vivek |