Re: [STDS-802-16] Comment 332
Dear All,
Based on most 802.x standards like Ethernet one might see the management as being mostly secondary to the definition of the actual interface. And this is very much true for example in the case of Ethernet because management is done at the bridge (or switch or router) level and is covered mostly by RFCs. However, I would say that 802.16 is essentially a different case because a BS plus its slaves (SSs) forms in many ways a distributed "bridge" (or switch or router) where the BS and the SSs are the "ports" of the "bridge". Similarly to other 802 standards the management of the distributed "bridge" as a whole could be left outside the scope of the standard. However, I strongly believe that the communication of management information between various "ports" should be part of this standard and should be fully-defined. Imagine how a normal Ethernet switch would operate if the internal communication between its ports was faulty, and you will get the picture of usefulness of the stand!
ard without SMC defined.
Therefore I strongly suggest addressing and resolving the SMC issue properly in revD.
Regards,
Octavian Sarca
Director, System Architecture
Redline Communications Inc.
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Phil Barber
Sent: Tuesday, May 04, 2004 10:52 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Comment 332
Unfortunately, after network entry, SMC in 16d is a conduit for network management traffic in name only. Other than some vague language pointing certain traffic types like SNMP to the SMC, there are no mechanics defined in 16d to assure separate control paths for management and data traffic after network entry.
Not too long ago, DJ proposed an appropriate stack reference model with separate paths for management and data traffic and appropriate SAPs. Unfortunately, the membership was not disposed to adopting this model at the late date in the process. Thus we are left with a reference model that blends data and management traffic into the same stream. That is going to result in some implementors using common CIDs for certain management traffic.
For 16d, the impact, while troubling, is not problematic.
For 16e, the impact is going to be much more dramatic. By definition, mobile systems have substantially more management and control traffic and our ability to define and manage that traffic will have substantial impact on the success of the standard. But that is 16e, and a problem for another day.
For 16d, we should allow the flexibility to implementors to use SMC as they have already planned and close this issue. We are beyond both need and time for solving this problem in 16d. Let's close 16d and move on.
We can re-address this issue in 16e and beyond.
Thanks,
Phil
---------- Original Message ----------------------------------
From: Radu Selea <Radu@REDLINECOMMUNICATIONS.COM>
Reply-To: Radu Selea <Radu@REDLINECOMMUNICATIONS.COM>
Date: Tue, 4 May 2004 21:00:02 -0400
> 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.
>
>Thank you.
>
>
>
>
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.
Thank you.