This bring me another question, which Ajoy
also mentioned. do we believe the MIH must be locate in AP/BS? If so, it may be
a good idea for option 1 or 2. But I think the most of information MIH need are
better gotten from the MSC or radio control server in the core network which
has the comprehensive knowledge of the network and HO policy, but not AP/BS
which only provide the access point. So in order to reduce the complexity of 802.21
network implementation, it may be a important consideration to let as less
network nodes has the knowledge of MIH as possible. So if we think AP/BS only
provides the IS forwarding function, can’t we make the MIH IS be transparent
for AP/BS which will make the life little easier?
David
From: Mike Geipel
[mailto:geipel@ieee.org]
Sent: Tuesday, January 25, 2005
7:55 AM
To: 'Mike Moreton'; 'Singh
Ajoy-ASINGH1'; 'David Xiang'; 'Peretz Feder'; 'Stefano M. Faccin'
Cc: 'Ajay Rajkumar'; 'Michael
Williams'
Subject: RE: [802.21] transport
layer for MIH IS.
I've been following this email thread, and
I'd think that this sort of discussion is important.
I would be inclined to avoid option (4) at
all costs. :-)
Option (3) is a bit better, but I'd fight
hard for defining an IP type, rather than a UDP port! Here's why: if a
router in the path fragments an IP frame, only the first fragment
would contain the UDP port. If this flow must be classified to
ensure delivery, you've just lost the discriminator in subsequent frames.
Option (2) and option (1) are going to be
the right approach in the long term. Ultimately, you're going to need to
define mappings to all the different MACs, just as 802.1 has had to do many
times before. Yet: 802.16 already defines an Ethernet convergence
sublayer, and I expect that 802.11 does something similar, which makes life a
bit easier. The only wildcard is what would be needed to define a mapping
for cellphones.
For Ethernet-like transport there is
likely going to be another option available to you:
There is a new IEEE working group (802.3as
"Frame Study") to address a question from 802.1 (802.1ad "Provider Bridges" & 802.1AE
"MACSec") as to the largest frame size that 802.3 can be expanded to
with "minimal impact" to current devices. (Note that backward
compatibility is NOT a requirement!!) They are requested to come up with
a value between 1650 and 2048 by March of 2005 to support optional
features. (Likely value: 1875-2000.) The Ethernet payload is still
limited to the same value of 1500 bytes.
There is already a precedent for
this. 802.1Q requested room for an additional Q-tag field, which prompted
the revision by 802.3ac in which the max size was increased from 1518 to
1522. Now 802.1ad wants 4 optional bytes. 802.1AE wants at least 64
bytes. 802.21 could ask for a few more...
Note that this dramatically increases the
likelihood that IP frames will be fragmented by routers that bridge segments
with different end-to-end MTU sizes.
I can't speak to 802.11, but in 802.16,
this larger Ethernet frame will likely fit within a single unfragmented PDU of
the Ethernet convergence sublayer.
--
Mike Geipel
Principal Engineer
Axxcelera Broadband Wireless
1600 East Parham Road
Richmond, VA
23228
Direct: 804-864-4125
-----Original Message-----
From: Mike Moreton [mailto:mm2004@MAILSNARE.NET]
Sent: Monday, January 24, 2005 9:06 AM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] transport layer for MIH IS.
It may be that you covered this in more detail at your meeting...
I can think of at least 4 different possibilities:
(1) Define new MAC specific management frames (e.g. a variant of action frames
in 802.11). This would require changes to each MAC specification, but
would allow the MAC to give these frames whatever priority was required.
(2) Transport in an L2 data frame with a new Ethertype allocated for the
protocol. This would not require any MAC changes for an 802 MAC, but
would require you to live with the different priorities available for data
frames, and probably would need some special support within cellular.
(3) Carried in IP packets. Gives you wider addressability than L2, but
it's not clear that you need this if you're only going from STA to AP (or
whatever you call them). In practice, the IETF are likely to insist on
you using UDP encapsulation.
(4) Carried over TCP. Built-in reliability, but do you want it?
Plus all the advantages and disadvantages you've already mentioned...
Mike.
-----Original Message-----
From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org] On Behalf Of David Xiang
Sent: Thursday, January 20, 2005 8:31 PM
To: STDS-802-21@listserv.ieee.org
Subject: [802.21] transport layer for MIH IS.
When we consider the complexity of .21 implementation and interaction with
other media standard, we need to think of our transport layer for
information service exchange with network or peer, though it seems out of
scope of .21 from most of the proposals.
I saw two ideas of transport layer from the proposals: IP application, and
L2. I just want to get your thoughts on which one is better.
IP:
Pros: 1. Generic and less impact on other media standard,
2. Give more implementation flexibility for .21
information service
and other requirements.
3. More easy to be implemented.
Cons: 1. slow
2. Not reliable or robust as L2
transport, but IP application can
become robust with some good
mechanisms.
L2:
Pros: 1. faster
2. More robust
Cons: 1. Too rely on other media standard which may not good for .21
implementation.
2. Not flexible, any time .21 do some changes on
SI, it may request
all other media standard to do
some changes too.
Any thoughts?
Thanks,
David