Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] Comment 332



Title: Message
At Ensemble, our secondary management connection was IPv4 over Ethernet, with the Ethernet, suppressed out through PHS.
 
Ken


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 1: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