RE: [802.21] transport layer for MIH IS.
Stefano,
It sounds like your objections to an L2 transport could be overcome by using a protocol encapsulated in L2 data frames (which wouldn't need any MAC changes) rather than one using new MAC management frames (which would).
Mike.
-----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: Monday, January 24, 2005 3:04 PM
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