|
Vladimir and all:
I agree with Vladimir that MIBs related to
network metrics communications (device status, user usage statistics,
network performance metrics, network security policy violation reporting,
etc...) to the NOC should be handled through its own TG, for all of the reasons
presented by Vladimir.
Thanks,
Phil
----- Original Message -----
Sent: Tuesday, March 30, 2004 9:58
AM
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
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
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
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
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..
(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.
************************************************************************************
This
mail was sent via
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.
************************************************************************************
|