RE: [802.21] transport layer for MIH IS.
|
|Stefano ==> I agree on guidelines and specs. What I believe we need to
|specify is the IEs, the logic of the various procedures, and the type
of
|messages. Based on this, we can make recommendations on how this can be
|implemented at L2 and at L3, but 802.21 is not the place to define such
|implementations. It's rather simple: if 802.21 specifies L2 transport,
do
|we really expect 802.11 will take what we specify line-by-line? If not,
it
|will be a mess anyway.
|
Yes, we do need to identify the Information Elements and the format for
the general representation of information. Any changes to media specific
MACs can only be a recommendation from 802.21. Most likely all such
transport etc. related recommendations may find their way into the
Appendix (informative) part of 802.21 spec, so that hopefully the spec
is NOT a mess.
It would behoove us to identify general direction of such amendments and
understand their pros and cons so that we could drive these amendments
in media specific groups in a timely manner, while developing our spec.
Kind Regards
-Vivek
|-----Original Message-----
|From: owner-stds-802-21@LISTSERV.IEEE.ORG [mailto:owner-stds-802-
|21@LISTSERV.IEEE.ORG] On Behalf Of stefano.faccin@nokia.com
|Sent: Monday, January 24, 2005 7:04 AM
|To: STDS-802-21@LISTSERV.IEEE.ORG
|Subject: RE: [802.21] transport layer for MIH IS.
|
|David,
|thanks for your reply. Comments in-line.
|Stefano
|
|-----Original Message-----
|From: owner-stds-802-21@LISTSERV.IEEE.ORG
|[mailto:owner-stds-802-21@LISTSERV.IEEE.ORG]On Behalf Of ext David
Xiang
|Sent: Thursday, January 20, 2005 7:58 PM
|To: STDS-802-21@LISTSERV.IEEE.ORG
|Subject: Re: [802.21] transport layer for MIH IS.
|
|
|Stefano,
|When do you expect .21 to be deployed? We already have 802.3, 802.11,
and
|3GPP/3GPP2 technology been widely commercially used, and the product
with
|multiple wireless media interface is merging, so I believe the market
|expect
|to have a standard like 802.21 ASAP, right? I believe how quick this
|standard can be commercialized and how easy to this standard be
implemented
|in current or early future network is important for .21 to be success.
|Stefano ==> David, I agree on the importance of getting things done
fast.
|One aspect you may want to consider, though, is that even if 802.21
|completes the standard in a very brief period of time, there will be a
|delay before all the products support it. also, there will be networks
|where e.g. the "legacy" 802.11 APs are not 802.21 enabled (i.e. 802.11
MAC
|does not support 802.21), but the service provider wants to support
802.21
|enabled terminals. In such situations, L2 transport is not the
solution,
|and that's why I was stating that I see the ability to provide L3
transport
|for 802.21 as the key for the 802.21 success, since it will allow a
much
|faster deployment of 802.21.
|
|Regarding the scope, I just afraid that if we don't give some guideline
or
|specification, it will bring the confusion and complexity for actually
|implementation, e.g the ST uses one IP application to transfer SI to
.11
|network, then handovers to another network(.16),it uses MAC management
|message for IS, and then if handover to another .11 network with using
.11
|L2 layer for IS. What a mess it will be.
|Stefano ==> I agree on guidelines and specs. What I believe we need to
|specify is the IEs, the logic of the various procedures, and the type
of
|messages. Based on this, we can make recommendations on how this can be
|implemented at L2 and at L3, but 802.21 is not the place to define such
|implementations. It's rather simple: if 802.21 specifies L2 transport,
do
|we really expect 802.11 will take what we specify line-by-line? If not,
it
|will be a mess anyway.
|
|Regarding IP layer, I don't mean we create another IP protocol, but a
IP
|application, such as Telcordia & Toshiba proposal to use SIP. So, we
don't
|need to deal with IETF but we can define ourself.
|Stefano ==> Sorry, I don't agree on this. 802.21 has no power to define
any
|IP protocols nor IP applications (by the way, I'm having trouble
|understanding the difference, since in reality what is being proposed
over
|SIP is nothing but a protocol). IETF is the place to do such work. The
|problem is again a matter of scope: defining such solution in 802.21
leads
|to very slim changes of acceptance and adoption. We need to push the
work
|in IETF, it's the only way to have a L3 solution acceptable to the
majority
|of people. Now, whether we define a new protocol or reuse an existing
one,
|that's another matter that requires further discussion. If we can adopt
an
|existing one (with e.g. some modifications), it would be a nice
shortcut
|(though experience should have thought one that taking an existing
protocol
|and modifying it for a new use does not necessarily take less time than
|defining a new one from scratch). Again, 802.21 can develop
recommendations
|(e.g. requirements the protoco!
| l !
|should satisfy, etc.) and bring those in IETF.
|
|Regarding the robust of L2, e.g for a situation, the IP connection or
IP
|service is unavailable, but ST still can communicate with network with
its
|L2.
|Stefano ==> Uhmm, I have trouble seeing such a scenario. Why would the
IP
|layer not be available? If it's not available, why would you be
interested
|anyway in handoff (i.e. no IP layer connection, means there is nothing
to
|hand over anyway).
|
|David
|
|
|-----Original Message-----
|From: owner-stds-802-21@LISTSERV.IEEE.ORG
|[mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Stefano M.
Faccin
|Sent: Thursday, January 20, 2005 5:05 PM
|To: STDS-802-21@LISTSERV.IEEE.ORG
|Subject: Re: [802.21] transport layer for MIH IS.
|
|David,
|as Perez says, we must realistically expect that 802.21 signaling
(remote
|events, etc.) will be implemented both with IP-based solutions and L2
|specific solutions. The reason is quite straightforward: do you want to
|deploy 802.21 ASAP? Well, use an overlay solution where transport is
802.21.
|If we rely just on L2, it may take a long time before anybody can
actually
|use 802.21. Whether somebody is interested in the IP transport or not
is
|another issue. Now, the two real question is whether or not all this
|discussion is in the scope of 802.21. As I mentioned in my slides, I
|believe
|802.21 shall not define any transport, only logic of MIH functions,
|interfaces, IEs, etc. 802.21 can develop recommendations for the
specific
|link layer groups and for IETF, 3GPP or 3GPP2 on how to take the
outcome of
|802.21 and implement it, but I don't see how 802.21 can define such
|implementation. As Perez says, if transport over IP is to be defined,
IETF
|is the place to go. How specifically this!
| will be done is out of scope of 802.21.
|
|David, I also have the same question that Ajoy has: why do you believe
L2
|transport is more reliable?
|
|Stefano
|
|-----Original Message-----
|From: owner-stds-802-21@LISTSERV.IEEE.ORG
|[mailto:owner-stds-802-21@LISTSERV.IEEE.ORG]On Behalf Of ext David
Xiang
|Sent: Thursday, January 20, 2005 5:23 PM
|To: STDS-802-21@LISTSERV.IEEE.ORG
|Subject: Re: [802.21] transport layer for MIH IS.
|
|
|I mean how to transfer the IS through air-interface. Is the IS carried
in
|IP
|play load which doesn't care what media interface carrier it or direct
in
|L2
|payload of that specific media interface (e.g IE of MAC management
message
|for 802.11, 16)?
|
|David
|
|On 1/20/2005 3:30 PM, David Xiang wrote:
|> 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.
|
|Transport across network elements must be IP type, which of course is
|carried
|within L2 Ethernet frames.
|
|In .21 new Ethernet frames (type .21) is in scope, IP is questionable.
It
|may be
|an IETF domain to pick form the .21 standard.
|
|>
|> 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?
|
|It is not one or the other, it will have to be both if we include MIH
|exchange
|between a station and MIH IS DB at the core network.
|
|The big question is how do we define the IP protocol associated with
the
|exchange of IP messages between the terminal and the IS network
element? is
|it
|an IETF follow up? or within the scope of IEEE802.21?
|
|>
|> Thanks,
|>
|> David