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

From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
Date: Tue, 11 Oct 2005 14:08:46 +0200

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Oct 2005 11:52:01 -0700

Eric,

I would oppose putting ES and CS into the charter.

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.

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.

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.

            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,

Eric

---

From: Greg Daley <[email-masked]>
Date: Wed, 12 Oct 2005 09:08:50 +1000

Hi James,

James Kempf wrote:
> 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.
> 

It seems to me that there are some pretty strict guidelines laid
out in order to make sure that event delivery does what it's supposed to
do.

I'd guess it may be interesting to see if we can work from that
document to get an idea of what use cases and threat are reasonable for
event(or command) transmission over IP.

Some input from Bernard and the IAB may be useful in determining
if it's just a no-go area, or can be OK if the architecture's right.

> Regarding CS, I have a difficult time seeing exactly how these would be 
> done independently from the particular radio link protocol.

:)

Well I think that ES and CS sometimes get lumped together, but
the security considerations may be quite different.

> 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.

I'd be happy to see ES/CS use cases in MIPSHOP, but think it would
be best to concentrate only on that (not proceeding until the threat
models etc are agreed).

It would be good if people encouraged discussion on these topic,
and discussed drafts, even if there weren't direct WG charter items
immediately.

If IEEE 802.21 would like to go ahead in 3-6 months time on this,
it would be very good to know what the IETF believes is the right
way to go.

Greg