Hi Phil/All,
I would add more emphasis on the rule
than the exception “mainly for the lowest 2 layers” J.
Anyway jokes apart, though I agree with some of your points,
I feel network reference models and related definitions that you suggest should
only be informative in nature and should not become normative.
best regards,
jose
From:
owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On
Behalf Of Phillip Barber
Sent: Tuesday, March 30, 2004
12:36 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16]
[NETMAN_SG] Network Management Study Group
I think it is important to note that '...mainly for the
lowest 2 layers...' is not 'only for the lowest two
layers'. The recently approved PAR and formation of the 802.21 TG with
its focus almost entirely in layers above layer 2 add additional emphasis to
this point.
All that being said, I would not advocate SG work that would
seek to define new Network or Protocol definitions--definitions that are more
than competently handled in other standards venues. But as part of the SG
process we should certainly investigate Network Reference Models (minimal
definitions, functionally inclusive of multiple network solution models) that
can aid us in defining network and interface trigger events and message
information elements suitable to enabling mobility functionality. As we
have discovered in our deliberations in 16e, it is difficult to generate
comprehensive primitives, triggers, and messages without the required models.
----- Original Message -----
Sent: Tuesday, March 30,
2004 2:08 PM
Subject: Re: [STDS-802-16]
[NETMAN_SG] Network Management Study Group
Hi All,
To identify the scope of 802.16 WG work for the network
architecture here is a quoted snippet from the IEEE 802 LMSC overview:
“LMSC (or IEEE Project
802) develops LAN and MAN standards, mainly for the lowest 2 layers
of the Reference Model for Open Systems Interconnection
(OSI). LMSC coordinates with other
national and international standards groups, with some
standards now published by ISO as
international standards.”
Here is the document link for your convenience. http://ieee802.org/802%20overview.pdf
Hope this clarifies my earlier comment on informative
guidelines as opposed to normative ones for the network architecture and
interfacing.
best regards,
jose
From:
owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On
Behalf Of Marianna Goldhammer
Sent: Tuesday, March 30, 2004
10:27 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16]
[NETMAN_SG] Network Management Study Group
1.Regarding the MIBs, the first
priority should be a PAR for FWA MIBs. Supplementary to what Vladimir just said, first
802.16 implementations will be FWA, and a managed inter-operable system needs
urgently MIBs.
2. In my view, the words "network
architecture" , applied to 3GGP models, are not only related to traffic,
but also to interference management.
A main RNC functionality is traffic
scheduling, with the scope to minimize the interference.
- centralized approach, actually combining
in the same physical box interference management with traffic routing.
- "distributed interference
management" approach, suitable to "decentralized" traffic
approach.
The PAR (common one / separate one ?)
should include the support for centralized / distributed interference
management (should have a decision if we support both or not). For the
distributed approach, we should include the case of Base Stations belonging to
different operators.
This issue needs really the architecture
definition, as part of the standard itself.
3. For mobility support, a Layer 2.5
(MPLS) approach would be a nice solution. This will imply communication with
Routers, in a similar way in which 802.11f defines AP communication
with Switches.
-----Original Message-----
From: Puthenkulam, Jose P
[mailto:jose.p.puthenkulam@INTEL.COM]
Sent: Tuesday, March 30, 2004 9:06
PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16]
[NETMAN_SG] Network Management Study Group
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
My position is that in the PAR we need
item[s] on structure of data backbone to support mobillity.
- 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].
-----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.
-----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.
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..
-----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
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.
************************************************************************************
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.
************************************************************************************
|