interoperability question in 2145
Hi Anthony,
With regards to Tony's concern about how the protocol can be exchanged
at L2, we could add text in the proper sections that says (note the
striking similarity to RFC 4798)
MIH protocol over IEEE 802 Networks
This is an optional transport mapping. There is a need to carry MIH
protocol
directly over an 802 LAN transport in order to allow for the
communication of mobility signaling when the IP infrastructure is not
available.
MIH protocol over IEEE 802 networks has some inherent restrictions.
Using
the MIH over an IEEE 802 transport mapping restricts messages to a
single logical IEEE 802 LAN, bridged LAN or VLAN.
Serialization
MIH messages are serialized, as described in Section X of this
specification.
The resulting serialized message is shipped in the data portion of an
IEEE LAN MAC frame.
(((depending on our fragmentation solution, add ...
Fragmentation
MIH messages are fragmented if needed, as described in section X
of this specification. The resulting fragmented message is shipped in
the data portion of an IEEE LAN MAC frame. )))
Well-known Values
Serialized MIH messages are sent in IEEE 802.3 frames with an
Ethernet type field of MIH_ETYPE (hexadecimal MIH_ETYPE ).
When serialized MIH messages are sent in IEEE 802.3 frames (and in
other IEEE 802 MAC frame types that can natively represent Ethernet
type values), an Ethernet type field value of MIH_ETYPE (hexadecimal
MIH_ETYPE ) MUST be used as the link layer protocol identifier. In
IEEE
802 LANs that use LLC as the means of link layer protocol
identification, such as IEEE 802.11 Wireless LANs, the SNAP
encapsulation method described in subclause 10.5 "Encapsulation of
Ethernet frames over LLC" in [IEEE802] MUST be used.
(((Depending on how fragmentation is handled... If opting for a fixed
non fragmenting solution then add...
When an MIH entity uses this transport mapping, it MUST be capable
of accepting MIH messages of at least MIH_MIN octets in size.
It is RECOMMENDED that implementations be capable of accepting
messages of up to MIH_MAX octets in size. Implementation of larger
values is encouraged whenever possible.)))
IEEE 802.3 Frame Format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination |
+- -+
| Ethernet |
+- -+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source |
+- -+
| Ethernet |
+- -+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIH_ETYPE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIH protocol |
+- -+
/ message ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Each tic mark represents one bit.)
-----Original Message-----
From: ext Anthony Chan [mailto:anthonychan@huawei.com]
Sent: 28 May, 2008 09:32
To: 'David Cypher'; yohba@tari.toshiba.com; vivek.g.gupta@intel.com;
Williams Michael.G (Nokia-OCTO/Dallas)
Cc: 'Nada Golmie'; 'Y. Alice Cheng'
Subject: interoperability question in 2145
Tony Jeffrey mentioned interoperability in comment 2145:
"Either specify how the MIH protocol can be exchanged interoperably at
layer
2 and layer 3 or explicitly state that such specification is out of the
scope of the standard. If you go the latter route for both layer 2 and
layer 3, then consider whether the protocol section of the standard is
at all useful."
So, is it necessary to explain the following in the spec?
(1) when the sender chooses L2 transport, the receiver will and is able
to receive the MIH message at L2,
(2) when the sender chooses L3 transport, the receiver will and is able
to receive the MIH message at L3
irrespective of whether the receiver may use L3 transport or L2
transport to send in both (1) and (2).
Currently, the following may be inferred from the spec:
(a) A sender may send MIH message using either L2 or L3 transport.
(b) When the MIH message is sent using L2 transport, the EtherType value
of MIH enables LSAP to deliver the message to MIHF at the receiver.
(a) and (b) together will imply the interoperability behaviors of (1)
and
(2) above.
H Anthony Chan
-----Original Message-----
From: Anthony Chan [mailto:anthonychan@huawei.com]
Sent: Tuesday, May 27, 2008 4:03 PM
To: 'David Cypher'; 'yohba@tari.toshiba.com'; 'vivek.g.gupta@intel.com';
'Michael.G.Williams@NOKIA.COM'
Cc: 'Nada Golmie'
Subject: RE: 21-08-0140-04-0000
David,
I think only the sender has the choice of whether to use L2 or L3. The
receiver has no choice but to follow whatever the sender uses.
When the sender uses L2 to send MIH message, the MIH is encapsulated
directly with LLC header. The payload of the L2 packet will not contain
an IP header. The LLC at the receiver will not deliver to IP. So the
MIHF at the receiver has to receive it directly from LSAP.
Similarly, if the sender uses L3 transport, the MIH is encapsulated with
IP header before being encapsulated with LLC header at the sending side.
The LLC at the receiving side must therefore deliver to IP and up.
The reason that I agree to remove PICS is for the reason that the
capability to deliver such message to MIHF at L2 should be already
intrinsic to the EtherType definition in the LLC header. I agree to your
very helpful remark that this is a service to MIHF and is not a function
of MIHF.
H Anthony Chan
-----Original Message-----
From: David Cypher [mailto:david.cypher@nist.gov]
Sent: Tuesday, May 27, 2008 2:27 PM
To: Anthony Chan; yohba@tari.toshiba.com; vivek.g.gupta@intel.com;
Michael.G.Williams@NOKIA.COM
Cc: 'Nada Golmie'
Subject: RE: 21-08-0140-04-0000
H Anthony Chan,
At 12:42 PM 5/27/2008, Anthony Chan wrote:
>David,
>
>Let me try to rephrase your explanation to make sure I understand
correctly.
>
>
>The question was whether the receiver is able to receive L2 transported
>message when the sender happens to choose L2 to send.
It does not matter to MIH how it received (L2 or L3) the MIH PDU.
>The capability to deliver message to MIHF is in LSAP. When LSAP
>receives a message with EtherType = MIH, LSAP will deliver the message
to MIHF.
Yes
>I will delete PICS for MIHF support then.
Thanks, sorry for changing my mind.
David Cypher
====================================
>H Anthony Chan
>
>-----Original Message-----
>From: David Cypher [mailto:david.cypher@nist.gov]
>Sent: Tuesday, May 27, 2008 10:39 AM
>To: yohba@tari.toshiba.com; vivek.g.gupta@intel.com;
anthonychan@huawei.com;
>Michael.G.Williams@NOKIA.COM
>Cc: Nada Golmie
>Subject: 21-08-0140-04-0000
>
>Regarding possible PICS question, "Is L2 transport supported?"
>
>This is a difficult question to fit into the PICS proforma and
>difficult to leave out.
>
>Does MIH do the L2 transport? I think not. It is a service
>(possibly) required of MIH and therefore is outside of a PICS Proforma
>for MIH. This is an excellent profile question though.
>
>Transportation of the MIH messages is a service of either L2 or L3.
>The primitive MIH_TP_Data.request contains the choice of
>transport (L2 or L3). The standard does not mandate either one or
>both. Unless there is a transport mechanism, MIH will not operate.
>
>Now seeing the other half of this problem (MIH fragmentation). If MIH
>fragmentation is only for L2 transport, then some (who have not read
>the ITU-T X.290 and X.296) may get confused when they see a the single
>question proposed in 21-08-163-01-0000 "Is MIH fragmentation
>supported?" marked as mandatory.
>
>This is the correct question and status, since PICS Proforma is for
>static conformance.
>A MIH must support MIH fragmentation, since it must be able to receive
>fragments.
>In the dynamic nature the device may never see or use fragmentation,
>but the capabilities must be there if needed.
>
>I think now upon closer examination of the details, I would suggest
>removing the PICS Proforma question from 21-08-140-04-0000 rather than
>keeping it as was my comment on today's teleconference.
>MIH does not support L2. MIH may use the services of L2, if available
>and appropriate.
>
>David Cypher