RE: [802.21] MIH Protocol message naming
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:ronnykim@lge.com]
> Sent: Tuesday, January 10, 2006 4:13 AM
> 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?
Then, why this MIH protocol message needs to be delivered media
dependently in case where the L2 control plane is 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.
> 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?
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 5:47 PM
> 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 4:42 PM
> > 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