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.
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.).
> 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.
> 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.
- Jeff
> -----Original Message-----
> *From:* Yigal Leiba [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]*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]*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] *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>.
>
> 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.
> ************************************************************************************