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