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

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

Hi All,

Some thoughts...

It seems like the SG maybe have a lot of topics to discuss and its scope seems quite broad ... As long as the PARs we create are more focused we should do fine J

The PAR for MIBs makes perfect sense. My suggestion for handling fixed (RevD) versus mobile (16e) parameters is to separate it as two working documents done by the same task group. Obviously the early fixed work done already (Joey's Contribution) can be the starting point for one of the documents.

As long as "Network Management" refers to the Management plane functions alone, AAA protocols should be considered as part of the control plane. So including it as part of the security PAR maybe more appropriate. Also AAA protocols should be part of informative guidelines as opposed to normative. This is especially relevant if IETF protocols like RADIUS are of interest.

IMHO, all mobility related issues including micro and macro mobility considering both normative and informative sections should ideally be part of the 802.16e work.

Regarding network architecture and interfacing, my vote is for only defining informative guidelines within 802.16 as it currently maybe outside scope of IEEE 802 architecture model. So doing work in the study group to better understand the network requirements is a good idea.

best regards,

jose

From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Vladimir Yanover
Sent: Tuesday, March 30, 2004 7:58 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

Hello,

My position is that in the PAR we need item[s] on structure of data backbone to support mobillity.

Above includes

- types of nodes [BS(NodeB)-RNC-SGSN-GGSN in terms of 3GPP]

- layering model of each node and protocols for communication between nodes [e.g. BS-to-BS communication]

- IP mobility support at the network [like MoIP & micro-mobility]

- micro-mobility may include specification of "L2 triggers"

- AAA elements [nodes responsible for AAA, global definition of services]

It is very close to Phil's list and to Joey's comments.

Note that some elements of this stuff are already present in 802.16e doc; probably we have to remove them to a new document [as suggested also by DJ].

Development of network specification is critically important for penetration of 802.16e technology.

It is hard to imagine a network operator buying 802.16e enabled BSs and SSs without

clear [based on standard] understanding of the structure of land network for this type

of mobility. Note status of network specifications in 3GPP.

I support DJ's idea of PKMv2 .

I would suggest to have a separated PAR for MIB development. Note that actual work on MIB for fixed systems

has advanced in WiMax and ETSI [Intel, Alvarion, Airspan, Proxim]. There is a MIB group in WiMax [chaired by Joey Chou]. There is a MIB project in HIPERMAN [I am a Rapporteur]. There is a draft of MIB document that includes

ASN.1 encoding [IEEE C802.16d-03/76r3 also known as BRAN35d017]. Having this activity tied to developement of network structure for mobility would be strange and impractical and may affect synchronization between 802.16

and HIPERMAN MIB documents [HIPERMAN MIB must be finalized this year].

Vladimir

-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Monday, March 29, 2004 6:29 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

I think we should identify:

those network logical entities (AAA services administrator, paging controller, gateway routers, caching services, SFID administrator, MACGs, mobility management controllers, etc...) that may exist on the network. Note that I propose distinguishing identification of logical entities by function rather than by device. One or more logical functions may be performed by the same device;
network logical entities' relationships to BS and to each other
events on BS and on the network that may trigger communications;
information elements transferred across the network during triggered communications (avoid protocol and message formatting specification);
primitives on BS tied to trigger events and appropriate primitive/SAP associations;
an appropriate, minimally defining Network Reference Model(s) highlighting these relationships;
an appropriate BS/MSS Reference Model containing these relationships.

Thanks,
Phil

-----Original Message-----
From: Johnston, Dj [mailto:dj.johnston@INTEL.COM]
Sent: Tuesday, March 30, 2004 3:04 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

Here's my thoughts on what we might do with security:

There are arguably three (partially overlapping) layers to 802.16 mobile security, the link cipher (AES-CCM and DES-CBC), the local network entry and key management (PKM) and the interaction with network side AAA architectures (currently lightly defined but involving EAP).

Not withstanding the need for a more efficient secure link cipher (GCM based?) I believe the link ciphers are done for now. It would be prudent to wait for 802.1ae and others to go through the pain of specifying an authenticated encryption mode that is fast, efficient and secure (pick any two) before 802.16 attempts another upgrade. In the meantime, I think the actual requirements will become much more detailed as we gain deployment experience.

We know PKM to have a number of security flaws, albeit mitigated by the very high practical barriers to misuse that derive from the nature of P2PM high frequency fixed equipment. Rather than attempt incremental upgrades to security with backwards compatible delta changes to the PKM messaging, I suggest that we go for a separate PKMv2 with messaging aimed at the needs of mobile equipment. In the medium term there would be a rough alignment of fixed=PKMv1 and mobile=PKMv2. PKMv2 would have secure authenticated key exchange, mutual authentication, base certs etc., generally borrowed from current examples available elsewhere (802.11i, IETF). This would allow us to let the current PKMv1 go through without too much fuss and meet the needs of fixed equipment. Mobile equipment might have something that meets the needs of mobile operators with PKMv2.

PKMv2 could be done in 16e, A network management PAR or a security PAR. I think 16e is becoming a stretch and dealing with PKMv2 in a new PAR would remove a road block from the other mobility work in 16e.

The AAA network interaction is something tied into the nature of the networks 802.16 becomes part of. I see this as being right on track for a network management PAR.

So in summary..

Ignore link ciphers until a clear need for something new turns up.

PKM remains as it is, with a version 1 tag as per the current spec.

PKMv2 gets defined either in a network management PAR or a security PAR.

AAA is an integral part of a network management PAR.

Feedback is most welcome..

DJ

-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Chou, Joey
Sent: Monday, March 29, 2004 9:34 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

Here is the list of items that can be included in the new Network Management PAR.

�    802.16 MIB for SS and BS, including fault management (e.g. fault notification, loop-back, ...), account management (e.g. usage data capture, ...), performance management (performance data capture), security management

�    Provisioned and Dynamic service flow creation models

�    Service deployment scenarios and models from the service provider perspective

�    Service flow context switching during BS - BS handoff from management perspective

�    Service flow context downloading while roaming into a network that belongs to the same of different service providers

�    SS management models (e.g. through the host, circuit city model, through the air interface, ...)

Joey Chou

Intel Corporation

-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Johnston, Dj
Sent: Friday, March 26, 2004 7:53 PM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [NETMAN_SG] Network Management Study Group

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)

This mail passed through mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************