Re: [802.21] MIH Protocol message naming
Ronny,
I have one comment.
On Mon, Jan 09, 2006 at 11:12:59AM -0800, Ronny Kim wrote:
> 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.
This is certainly possible. In this case, the protocol running over
802.16 is similar to the MIH protocol in that it carries MIH payload.
However, strictly speaking it's not the MIH protocol because it does
not carry the MIH header required by the MIH protocol.
Yoshihiro Ohba
> 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
>