Re: [STDS-802-16] Comment 332
I'll schedule this as part of the first Netman meeting.
I would like people who have plans for the SMC to bring contributions
that pertain to what changes to the SMC are necessary and more
importantly, how the scope and purpose of Netman PARs should accomdate
changes to the SMC.
Please take a look at the prototype PARs I've put up at
http://mgt.wirelessman.org . They might be useful as a starting point.
Thanks,
DJ (IEEE 802.16 Network Management Study Group chair)
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Roger B. Marks
Sent: Thursday, May 06, 2004 8:54 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Comment 332
This is a good idea. I think it would be best to let the NetMan Study
Group schedule it during their meeting time.
Roger
>If it would help, why don't we ask Roger to schedule a 1 hour session
>on the secondary management connection. I am willing as one of the
>"veterans" to lead the discussion, starting with the original
>intentions (it did come form a contribution by me in the first
>place) and my concerns from the start. I would like at least one
>representative from the new management study group to be present
>because this is a management issue, not really an airlink issue.
>
>Ken
>
>
>From: owner-stds-802-16@LISTSERV.IEEE.ORG
>[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Vladimir
>Yanover
>Sent: Thursday, May 06, 2004 1:10 AM
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] Comment 332
>
>Jeff and All,
>see comments below
>Vladimir
>
>-----Original Message-----
>From: Jeff Mandin
>[<mailto:jmandin@STREETWAVES-NETWORKS.COM>mailto:jmandin@STREETWAVES-NE
>TWORKS.COM]
>Sent: Thursday, May 06, 2004 1:42 AM
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] Comment 332
>
>
>Vladimir and all,
>
>First I want to note that I withdrew my recirc Comment about deleting
>the SMC from the present draft, and currently support Bob Nelson's
>comment 332.
>
>[VY] Note that #332 is about keeping the SMC after network entry, not
>on having it in the standard.
>
>So the whole discussion, though useful, is not directly related to
>#332.
>
>
>Vladimir Yanover wrote:
>
>> .... One may easily imagine a BS with classification capabilities
>> that are applied to A) data traversing CS SAP, thus entering regular
>> connections and B) data coming from NMS console / TFTP server /
>> Time server / DHCP server entering the SM connection.
>>
>
>Can B) actually be seen as describing anything other than an
>additional CS SAP? It's even equipped with a MAC address (on the SS).
>Logically speaking , B) places another set of classification mechanisms
>outside the CS that choose one CS SAP (or both SAPs on each SS - in the
>case of 802.3/ARP etc.).
>
>[VY] Functionally yes, but B is currently out of the standard's scope.
>BTW, I don't say it's 100% OK.
>
>> Configuration procedure for A is somehow addressed in the standard
>> [DSx procedures] while configuration for B is not, thus it is vendor
>> dependent.
>>
>> Now, suppose we kill SMC i.e. replace its functionally with
>> "regular"
> > data connection [probably with additional flag meaning termination
>at
> > the SS].
> >
> From our point of view (ie. the 802.16 MAC), ALL received downlink
data
>terminates at the SS. So there should be no need for a "flag". What
>happens after the packet is delivered to the CS SAP is the concern of
>the "higher-level application" only.
>
>[VY] It could be yet another solution. For example, SS may decide that
>packet X is addressed to the SS by IP dest address.
>
>
>> Then we get standardized tools to configure classifiers & QoS
>> parameters for such connection[s] as well. Will it be cleaner? Could
> > be, as for existing SMC everything is different from regular >
> connections, not only endpoint. There are also fees associated with >
> cleaning, for example, should replacement for SMC be created by DSA?
>> Worth to try to bring some text for that.
>>
>> Vladimir
>>
>
>Iit's worth noting that there's a class of devices that are "managed",
>but would likely prefer to operate without an SMC. For example, an
>integrated SS/IP phone might carry voice on dynamic UGS connections,
>while carrying call signalling, management, and text messaging on a
>single best-effort connection.
>
>[VY] I disagree with extending term "management". We have to
>distinguish between "management" of SS as 802.16 conformant entity
>
>and "management" of other layers [which typically are vendor specific]
>and devices behind the SS. After all, we are talking on what
>
>must be a part of the standard and what must not. >From this point of
>view, call signaling is an application data and must be carried on
>regular traffic connection [presumably different from the UGS one
>carrying voice itself].
>
>
>- Jeff
>
>
>> -----Original Message-----
>> *From:* Yigal Leiba
>>[<mailto:yigall@runcom.co.il>mailto:yigall@runcom.co.il]
>> *Sent:* Wednesday, May 05, 2004 9:42 AM
>> *To:* STDS-802-16@LISTSERV.IEEE.ORG
>> *Subject:* Re: [STDS-802-16] Comment 332
>>
>> Hi Radu,
>>
>> I think that comment #332 is not in contradiction to any of the
>> points you are raising. The comment simply tries to clarify that
>> there are possible SS behavior types as far as SMC is concerned
>> 1. Managed through SMC
>> 2. Unmanaged (through SMC)
>> 3. Unmanaged (through SMC), but using SMC for network entry
>> DHCP, TFTP download, etc.
>>
>> As for the clarification, rather than deletion issue, I agree
with
>> you that at this stage we are safer with clarifications.
>>
>> Yigal
>>
>> -----Original Message-----
>> *From:* owner-stds-802-16@listserv.ieee.org
>>
>>[<mailto:owner-stds-802-16@listserv.ieee.org>mailto:owner-stds-802-16@
>>listserv.ieee.org]*On
>>Behalf Of
>> *Radu Selea
>> *Sent:* Wednesday, May 05, 2004 3:00 AM
>> *To:* STDS-802-16@listserv.ieee.org
>> *Subject:* Re: [STDS-802-16] Comment 332
>>
>> DJ,
>>
>> 1. The secondary management connection is a good
>> idea and it serves the purpose: Parallel management
>> network. And based on the purpose it has to stay OPEN. But
>> the comment 332 starts from an 'original' idea that SMC
>> is created only to allow Configuration File download. This
is
>> not correct, other people use it for management and that was
>> the reason of creating it.
>>
>> 2. That it should go through a CS ,it is
obvious.On
>> BS we have aside encapsulation, a real classification task
to
>> do. That nothing points in the 802.16D document to these
items
>> ,it is true. I have tried to introduce a small comment "015"
>> that partially introduced a reference to it : " BS's CS
shall
>> map these messages to the appropriate Secondary Management
>> Connection " . That was a former action item from WiMax,
>> when we found out, that we do not know how to fill the table
>> in the BS section related to SMC. At the end of the day the
>> comment was rejected by people that are agreeing with the
idea
>> of SMC going through CS and people that were part of the
>> discussion in WiMax. :)
>> This is the reason ,I am the advocate of clarification
instead
>> of deletion. If we delete something it will be hard to agree
>> that we have to put something back...
>>
>> 3. The problem is simple as Ken said. Can
>> be IPv4/Ethernet . The other IP stack activities , DJ
>> mentioned , are triggered by the usual interaction of a DHCP
>> client/server , SNMP agent/manager or ToD client/server and
>> should be transparent to 802.16 MAC . In case specific lower
>> layer events that trigger particular SNMP traps for
instance,
>> it is the same approach as used in any broadband modem
>> (cable,xDSL).
>> Another issue is that taking CS as defined now in the
standard
>> we have no assurance that the principle ( management and
data
>> separation) is respected.
>> I mentioned that in a previous e-mail.
>>
>> 4. About Figure 1. , the NMS and IP stack , you have
>> lost me ...
>>
>>
>>
>>
>> -----Original Message-----
>> *From:* owner-stds-802-16@listserv.ieee.org
>>
>>[<mailto:owner-stds-802-16@listserv.ieee.org>mailto:owner-stds-802-16@
>>listserv.ieee.org]*On
>>Behalf Of
>> *Johnston, Dj
>> *Sent:* Tuesday, May 04, 2004 4:33 PM
>> *To:* STDS-802-16@listserv.ieee.org
>> *Subject:* Re: [STDS-802-16] Comment 332
>>
>> 1) Don't know. The spec seems silent on the matter. I
>> always assumed it would be left open, so the station can
>> be managed any time the network chooses. Comment 332
>> would
> > give an answer.
>>
>> 2) My reading of the spec suggests that the SM
connection
>> has a direct plumbing of IP frames into the bottom of a
>> distinct IP stack, with a location that is undefined. It
>> floats somewhere in the management plane. Possibly the
Mac
>> CPS management entity.
>>
>> I see nothing that comes close to suggesting that it
>> passed through the CS_SAP. Indeed this doesn't fit the
>> model, since we have multiple CS types, not all of which
>> support IP traffic. Also the text weakly describes the
>> encapsulation (6.3.1.1) by referring to 5.2.7; If the CS
>> were really in the loop, when we would invoke an IP
packet
>> CS, rather than referring to a subclause within the IP
>> packet CS to describe a specific encapsulation that
takes
>> place in the management plane.
>>
>> Of course there is no management behaviour.. its out of
>> scope. Figure 1 says so. Which one is wrong? Is it the
>> management behaviour or figure 1?
>>
>> If we have a secondary management channel and an
>> independent management IP stack, this still does not
mean
>> that SNMP must run over it. In fact, with a separate
>> stack, you could argue that there is a separate MIB
space
>> for that stack, so you could hypothetically run SNMP
over
>> both and have them both interact with different MIBs.
>>
>> ---
>>
>> This gets to the core of my problem with the secondary
>> management connection.
>>
>> It is not a bad idea. A parallel management network is a
>> fine idea in a managed network and has been used widely
>> elsewhere.
>>
>> It is however, not a well defined thing in 802.16. We do
>> not know exactly what the details are. Where do the
MPDUs
>> go? Where is the IP stack? How does SNMP interact with
it?
>> Does it have separate mibbage? Is there an IP Packet CS
or
>> is it just simple encapsulation? Does the connection
>> persist? Should it be auto restarted if it fails? What
>> triggers the IP level activity such as DHCP in the IP
>> stack? How does the IP stack know what's happening below
>> in the 802.16 management plane? Is is a magic IP stack
>> with side plumbing into the 802.16 MAC state so that
>> internal triggers can fire these events?
>>
>> Given that a secondary management connection could be
well
>> defined and there is certainly not universal support for
>> my public position of removing it, I did not bother
making
>> that comment; it would not pass. Instead I hoped that we
>> could improve it a bit so that some of these issues are
>> resolved. Comment 332 goes some of the way to improving
>> matters and should be supported but there is more to do.
>>
>> Some of this can be cleaned up by having a cleanly
defined
>> management service interface, with primitives for the
>> transport of the SMC IP traffic between the
>> managament plane and the management IP stack. Then the
>> structure would be clear, the IP stack would be in the
NMS
>> in figure 1. The rules associate with the MLME_SAP
>> primitives for carrying the traffic would clear up any
>> doubt about the encapsulation. We will find if this sort
>> of thing has traction in Netman.
>>
>> DJ
>>
>>
>> -----Original Message-----
>> *From:* owner-stds-802-16@listserv.ieee.org
>>
>>[<mailto:owner-stds-802-16@listserv.ieee.org>mailto:owner-stds-802-16@
>>listserv.ieee.org]
>>*On
>> Behalf Of *Ravi Joganathan
>> *Sent:* Tuesday, May 04, 2004 9:31 AM
>> *To:* STDS-802-16@listserv.ieee.org
> > *Subject:* [STDS-802-16] Comment 332
>>
>> There appears to be a couple of issues in relation
to
>> the resolution of comment 332 that appear not to
have
>> been given consideration and which I would like the
>> resolution of the comment to cover if possible.
>>
>> 1) Whether to keep the SM open or not after the
>> initialisation.
>> 2) Whether traffic normally carried over SM
does
>> pass through CS SAP (or not).
>>
>> Can anyone help us with references to the text that
>> would help clarify these issues.
>>
>> On a related topic, it seems that SNMP management of
>> SS is most easily achieved if this management
traffic
>> flows through the CS SAP.
>>
>> If secondary management is not handled in this way,
it
>> appears additional complexity will be introduced in
>> the BS (SNMP proxy).
>>
>> Ravi
>>
>> Ravi Joganathan
>> Senior Software Engineer
>> Airspan Networks Inc
>>
>>
>>
>>
>> _IMPORTANT NOTICE_: This message is intended only for the
use
>> of the individual or entity to which it is addressed. The
>> message may contain information that is privileged,
>> confidential and exempt from disclosure under applicable
law.
>> If the reader of this message is not the intended recipient,
>> or the employee or agent responsible for delivering the
>> message to the intended recipient, you are notified that any
>> dissemination, distribution or copying of this communication
>> is strictly prohibited. If you have received this
>> communication in error, please notify Redline immediately by
>> email at postmaster@redlinecommunications.com
>>
>><<mailto:postmaster@redlinecommunications.com>mailto:postmaster@redlin
>>ecommunications.com>.
>>
>> Thank you.
>>
>>
>>
>> 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.
>***********************************************************************
*************