Re: [STDS-802-16] [NETMAN_SG] notes on 802.11F
Vladimir is right that it's "802.11F", not "802.11f". Lower case
represents an amendment. 802.11F is not an amendment to IEEE Std
802.11. It's is a standalone Recommended Practice. I think this was
done mainly because going above Layer 2 would be controversial in
802. As a Recommended Practice rather than a standard, the potential
for controversy was expected to be lower.
A "Recommended Practice" contains normative material, not just
informative. This is typically done with "should" statements, whereas
a Standard uses "shall" statements. But, according to IEEE, "should"
is normative too.
While you can include "should" statements in a standard, I think that
it is natural that a large collection of "should" statements would be
published separately. One other thing: 802.11F was intended to apply
across a range of applications, not only to 802.11 access points.
Roger
At 11:34 +0300 04/03/31, Vladimir Yanover wrote:
>All,
>
>1. About 802 LMSC scope
>Jose made a good point.
>The idea was to develop for network infrastructure "Recommended
>Practice" document [rather than standard document].
>Note the document of similar scope: 802.11F "Recommended Practice
>for Multi-Vendor Access Point Interoperability via an
>Inter-Access Point Protocol Across Distribution Systems Supporting
>IEEE 802.11 Operation". Reference model
>of 802.11F includes IP layer and everybody is comfortable with it.
>
>I believe that with above clarification, the elements suggested by
>Phil, Joey, myself and others will be accepted by
>SG community as an essential part of the scope of new PAR.
>
>2. About 802 model - just informational comment.
>
>802.16, in its existing form, already does not fit this model.
>
>For example, according to IEEE Std 802-2001, the document "provides
>a standard for the structure
>of LAN MAC addresses". In section 9 it specifies 48 bits Universal
>addresses and protocol identifiers
>that must be used under 802.
>While 802.16 SS has 48-bits MAC address, 802.16 system may be used
>in IP-only configuration with
>no 48 bits addresses involved. Computer sends an IP datagram to
>ISP over dial-up [or other WAN connection].
>The datagrams arrives to access concentrator, then, over chain of IP
>routers and ATM links, to 802.16 BS.
>At the BS the datagram is classified into certain connection by
>destination IP address.
>After transmission over the air [in a MAC PDU that carries certain
>CID], the datagram comes to SS which is
>[in my example] a PC Card installed in a laptop. Through all the way
>no 48 bits addresses are involved.
>
>Actually 802.16 gives up formal conformance with 802 LAN model to
>gain WAN functionality, which is extremely
>important for providing variety of network configurations
>in wireless access to Internet.
>Under specific configuration, 802.16 system may be used to
>merge LANs behind SSs in a single
>switched LAN. But this is a relatively rare scenario.
>
>Vladimir
>
>-----Original Message-----
>From: Johnston, Dj [mailto:dj.johnston@INTEL.COM]
>Sent: Wednesday, March 31, 2004 12:06 AM
>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: <mailto:jose.p.puthenkulam@INTEL.COM>Puthenkulam, Jose P
>To: <mailto:STDS-802-16@listserv.ieee.org>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>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.
>************************************************************************************
>
>
>
>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.
>************************************************************************************