Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group
Dear all,
I would like to express my opinion regarding the scope and/or
context of the new SG.
It seems that there is a clear distinction between two type
of activities:
a. Management support (e.g. MIB)
b. Mobility related high layer operations, including security
extensions, BS-BS protocol, triggers, PKMv2 and other
vegetables.
I fully agree with the expressed opinions that there should
be two separate SGs for the items above, and also think that
the suggested MIB contribution can be reviewed as a good
baseline (with hopes of expansion to other PHY modes and no
problems regarding rights to do changes, as we witnessed
before).
Regarding the other SG, this should be very carefully
examined, since, unless nobody thinks that .21 will manage to
do its work, we should use it as a platform for generic 802
BS-BS communication carrying .16 information and good
potential for inter technology handoff.
In addition we should verify what do we want to leave in TGe
and what to move to a new SG, since not having TGe with
minimum self containing operations for mobility probably will
fail to achieve its target.
I'm not yet fully convinced why we require PKMv2 having PKMv1
with new EAP extensions of TGe (for example I don't yet
understand the need for symmetrical authentication in a PMP
deployment scenarios as we have, but it is probably just me).
Finally, probably at this stage we should still try to focus
on the targets, not yet on solutions.
Thanks,
Itzik.
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-
802-16@LISTSERV.IEEE.ORG]On Behalf Of Johnston, Dj
Sent: Tuesday, March 30, 2004 23:06
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management
Study Group
Phil, Jose,
My impression is that a lot of the problems with integration
of 802 technologies into wider area architecture is a
function of 802 not being willing to go beyond the MAC SAP. I
don't think we need to go far beyond the MAC SAP, but
awareness of the broader models and the ability to specifiy
behaviour related to things happening just beyond the MAC SAP
is going to buy a lot in terms of interworking.
This is where the scope of an infrastructure PAR is a
critical item in determining how well we can meet our goals.
DJ
-----Original Message-----
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
Jose and all:
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.
Thanks,
Phil
----- Original Message -----
From: Puthenkulam, Jose P
To: STDS-802-16@listserv.ieee.org
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
Hello All,
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.
802.16e network may use:
- centralized approach, actually combining in the same
physical box interference management with traffic routing.
OR
- "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.
Regards,
Marianna
-----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
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.
**************************************************************
**********************
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.
**************************************************************
**********************