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