| 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 Vladimir Yanover
Sent: Wednesday, May 05, 2004 3:56 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Comment 332Yigal, Radu and All,
I respectfully disagree with Radu's interpretation. To my best knowledge, there always was common understanding that
1. Traffic that enters SM connection does not pass CS SAP
2. SM connection is used for such types of communication where SS is the terminal point.
I am sorry that the text allows misinterpretation, but let's ask other veterans [Ken, Carl] what was the original understanding.
One may suggest to extend the role of SM connection to servicing ALL "management" traffic, whatever are endpoints and whatever is the definition of "management". Difficulties we are experiencing now are created by this intention for extention, not by original understanding.
According to above interpretation, e.g. SNMP packets sent from NMS console to the SS pass over SM connection while SNMP packets addressed to a device behind SS pass over regular data connection. It is OK as those are are inherently different types of traffic: first is payed by operator, second by subscriber.
I believe, this answers question Ravi's question #2.
Historical answer to question #1 was that SM connection stays forever [up to the next network entry or re-entry].
Recent changes were to introduce additional feature: make possible automatic deletion of the connection after network entry [as this is not a regular connection, DSD cannot be used].
Concerning Ravi's statement "SNMP management of SS is most easily achieved if this management traffic flows through the CS SAP", I think that it is a mixture of standard language and implementor language. 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. 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]. 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
This mail was sent via mail.alvarion.com-----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 332Hi 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 concerned1. Managed through SMC2. 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 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.
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 footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************