| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----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 332DJ,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 3321) 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 332There 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 Incpostmaster@redlinecommunications.com.
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 atThank you.