Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group



I think we should identify:
Thanks,
Phil
 
----- Original Message -----
From: "Jeff Mandin" <jmandin@STREETWAVES-NETWORKS.COM>
To: <STDS-802-16@LISTSERV.IEEE.ORG>
Sent: Monday, March 29, 2004 6:29 AM
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

> Here's a list of things that 16e has been discussing that could go into
> a new PAR:
>
> 1. Management and Provisioning issues
>
>     a) BS interface to AAA server (ie. details of RADIUS/DIAMETER
>         exchange etc.)
>
>     b) MIBs, including dynamic management of Service Flows
>
>     c) BS Discovery of "Neighbor BSes"
>
>     d) Roaming between administrative domains
>
> 2. The following can be termed "Extended Services" (following the
>     example of 802.11 ESS) or "Backbone mobility services"
>
>     a) Protocol to enable BSes to query neighbors or centralized servers
>        during evaluation of Handover requests from MSSes (Revision
>        to Annex C).
>
>     b) Structures and semantics of data that are passed between BSes
>        during Handover.  These are currently addressed in Annex C and
>        elsewhere in .16e, but more work is needed, particularly
>        on derivation of security context and readmission/reactivation of
>        service flows.
>
>     c) Transport protocol for low-latency transfer (predictive and
>        reactive) of the L2 context data at handover, and related
>        MAC-layer triggers
>
>     d) Compatibility w/ various types of L3 mobility (and triggers)
>
> - Jeff
>
> ------------------
>
> Jeff Mandin
> Streetwaves Networking
>
>
> >  To:
STDS-802-16@listserv.ieee.org Subject: [STDS-802-16] [NETMAN_SG]
> >  Network Management Study Group From: "Johnston, Dj"
> >  <
dj.johnston@INTEL.COM> Date: Fri, 26 Mar 2004 18:53:19 -0800
> >  Reply-To: "Johnston, Dj" <
dj.johnston@INTEL.COM> Sender:
> > 
owner-stds-802-16@listserv.ieee.org Thread-Index:
> >  AcQTprE0A4ncKA23Qyu9ObpkW8LGcw== Thread-Topic: [NETMAN_SG] Network
> >  Management Study Group Title: Message All,
> >
> >  We need to get moving on inputs to the network management study
> >  group. The goal I put forth to the WG is that we do our work before
> >  and during the May meeting, so this will require us to work some of
> >  the issues on the reflector and maybe have a conference call or two,
> >  if we are to produce a PAR and five criteria during the interim. If
> >  we don't have a workable basis for consensus going into the May
> >  meeting, then I expect we will be asking for an extention in July,
> >  and that is a long time, given that it would then be November before
> >  the TG request would be approved by the EC and NesCom would add more
> >  time to the process, so maybe we would be looking at 2005 before we
> >  had a group for real. Finishing in May is a good plan.
> >
> >  I propose that email directed to this effort has [NETMAN_SG] in the
> >  subject line to allow appropriate filtering.
> >
> >  The primary thing that led me to suggesting a study group was the
> >  plethora of different things people wanted to do with respect to
> >  network management, network architectures, interfaces, MIBs and so on
> >  and the rapid closure of .16d as a forum in which to address them. My
> >  personal wish list is no secret, you will find it in the comment
> >  databases - security, interfaces, MIBs.
> >
> >  So as a first step, I would like to request that people forth their
> >  ideas for what problems they think network management group or groups
> >  (don't let the name predjudice the function) should be solving, or
> >  what features they should be introducing. This will give us a list of
> >  issues that we can enumerate, sort, sift, rejig, classify and
> >  generally argue about until we can approach consensus on scope and
> >  purpose. But first we need the issues out on the table for all to
> >  see.
> >
> >  A potential benefit I suggested was that items of questionable scope
> >  in .16e might find a more secure home in a new group. This is not my
> >  idea and I have not been in the loop on these discussions (although I
> >  do like the idea), so perhaps it would be useful input for people who
> >  are thinking along these lines to start describing specifics of what
> >  bits in .16e are problematic and might benefit from a group with a
> >  clear scope to address them.
> >
> >  I'll make my suggestions in a separate email..
> >
> >  DJ (chair 802.16 network management study group)
> >
>