Answers are inline.
-----Original Message-----
From: Junghoon Jee
[mailto:jhjee@ETRI.RE.KR]
Sent: Sunday, January 08, 2006 6:41 PM
To:
STDS-802-21@listserv.ieee.org
Subject: 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?
[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 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