Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
Date: Wed, 12 Oct 2005 10:18:14 +0200

James,

> -----Message d'origine-----
> De : James Kempf [mailto:[email-masked]] 
> Envoyé : mardi 11 octobre 2005 20:52
> À : NJEDJOU Eric RD-RESA-REN; [email-masked]; 
> [email-masked]
> Objet : Re: [Mipshop] ES and CS within the MIPSHOP charter
> 
> Eric,
> 
> I would oppose putting ES and CS into the charter.

That's one view. I am not sure it represents the thinking of the majority.

> 
> ES has been discussed twice within IETF already, and both 
> times the approach of having a network-based signaling 
> protocol for link events (which is what ES is) has been rejected:
> 
> - The DNA working group discussed ES and decided to confine 
> their work to link hints derived through APIs on the device.
> 
> - The Trigtran BOF met twice and was not able to overcome 
> some strong objections to using network-based link hints.
> 
The approaches you are refering to were not necessarily linked to any real problem statement on network controlled handovers. Today there is a problem to be solved for deployments needs of Wireless Access Providers, that have built strong and successfull network-based signalling models on 3GPP that they want to extend to 802.11 and 802.16. 

Furthermore,
DNA has nothing to do with the ES/CS transport problem that is being raised. 
802.21 is bringing to maturity some considerations about events and commands. The problem was not necessarily well understood at he time of the TRIGTRAN Bof.  

> Bernard Abboba's draft on link hints:
> 
> http://www.iab.org/documents/drafts/draft-iab-link-indications-03.txt
> 
> summarizes the IETF objections to network-based link indications.
> 
> Regarding CS, I have a difficult time seeing exactly how 
> these would be done independently from the particular radio 
> link protocol.

A particular radio link protocol send commands for handoff within that system. Do you know of a way for the network to tell a station to move to WLAN using 3GPP RRC procedures? There is none.

> 
> Finally, I think we are having enough trouble converging on a 
> shared consensus about what the WG should be doing for IS, 
> that trying to also tackle ES and CS might be too big a job. 
> I think we should get consensus on what we want to put into 
> the charter for IS and actually complete the work first. 
> Then, if people think they have some new ideas about 
> overcoming the objections for ES, we can consider tackling that.

If some feel IS is important to be in the charter for their applications, other thing EC/CS is for theirs and that just represents the variety of interests of involved actors. As far as i understand IETF operation, one does not decide what is important or not for everyone
SO again i call upon all interested parties to voice their opinion on having ES/CS in the charter 

> 
>             jak
> 
> ----- Original Message -----
> From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, October 11, 2005 5:08 AM
> Subject: [Mipshop] ES and CS within the MIPSHOP charter
> 
> 
> Hi folks,
> 
> Agree with couple previous mails that we are discussion solutions
> (CARD...)  without even having set the requirements for those.
> 
> Stephano has brought up a point here which is about having ES and CS
> within the charter of MIPSHOP. For that he gave a quite clear example
> scenario where those would be needed. I will stress that point here:
> 
> WISPs want to put inter-system mobility functions in their network
> deployment roadmaps. Some milestones in these roadmaps demand that the
> access systems have to be used as they are for the first generation of
> mobility management architectures. Therefore, as many WISPs would like
> the mobility management to be network initiated and controlled (to
> control the resources usage), they need to have Management entities in
> their networks. As acces systems are to be kept unchanged for first
> deployments, the most straitghtforward option is to exchange the
> Mobility Management signaling (event and command) on top of layer 3.
> Effectively, this is the only way forward because for example 
> Management
> facilities within 802.11 will be standardized long after first WISP
> deployments milestones.
> Example: the terminal experiences bad radio conditions on an .11 link,
> report that directly on top of IP to a management entity somewhere in
> the network. The entity takes into account other information 
> as operator
> policies, load conditions (not seen by terminal) to decide of the
> handoff to another link. OF COURSE, POLICIES ARE TO BE KEPT OUT OF
> SCOPE. Once the entity has run the selection algorithm, it needs to
> instrut the terminal of its target link. Today, an AP can not 
> relay that
> management decision (received by the entity in the network) to a
> station. This because .11 is not adapated for that, at least 
> as the 1999
> specification stands. Therefore, the management entity in the network
> has to find a way to relay the selection decision. And again the most
> straightforward way seems to use IP.
> Hope that with these usage scenarios people will understand 
> and support
> the need to bring back ES and CS in the charter
> 
> I will suggest that we have separate threads for each new item we want
> in the charter. Otherwise people are discussing every thing and
> confusing every other.
> 
> Eric
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 
> 
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop