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

From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
Date: Tue, 11 Oct 2005 17:43:03 +0200

Stephano,
This is exact. Not only the charter should include that (looks like the overall Working Group objective does) but also the scope description. That description appears as considering MIES and MICS as "may be adressed items" only where those could appear as "to be solved" items for some actors use.
Eric 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 11 octobre 2005 16:48
À : [email-masked]
Objet : RE: [Mipshop] ES and CS within the MIPSHOP charter

Eric,
just to make sure I understand you correctly, your point is that the charter should also include 802.21 MIES and MICS, correct?
Stefano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext NJEDJOU Eric RD-RESA-REN
> Sent: Tuesday, October 11, 2005 07:09
> To: [email-masked]; [email-masked]
> 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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Oct 2005 18:56:50 +0200

NJEDJOU Eric RD-RESA-REN wrote:
> Stephano, This is exact. Not only the charter should include that 
> (looks like the overall Working Group objective does) but also the 
> scope description. That description appears as considering MIES and 
> MICS as "may be adressed items" only where those could appear as "to 
> be solved" items for some actors use.

The actors interested in 802.21 should probably re-BoF.

Doing CS and ES in addition to IS is additional work, not to mention
CARD, NED, network-controlled handovers, and the security of them all.
These are enough work for a full-size WG, not just partial work in the
mipshop WG, provided that the BoF proponents could converge on
least-common denominators, as individuals.

If 802.21 can't decide between CARD and NED then probably IETF *could*
help figure out a common CARNED way.

There was a MIHEP BoF proposal prior to the Paris meeting.  According to
a report, that didn't get approved because not enough discussion.  I
think the situation has changed.  So BoF again would make sense.

Alex