Re: [STDS-802-16] Comment 332
This is a good idea. I think it would be best to let the NetMan Study
Group schedule it during their meeting time.
Roger
>If it would help, why don't we ask Roger to schedule a 1 hour
>session on the secondary management connection. I am willing as one
>of the "veterans" to lead the discussion, starting with the original
>intentions (it did come form a contribution by me in the first
>place) and my concerns from the start. I would like at least one
>representative from the new management study group to be present
>because this is a management issue, not really an airlink issue.
>
>Ken
>
>
>From: owner-stds-802-16@LISTSERV.IEEE.ORG
>[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Vladimir
>Yanover
>Sent: Thursday, May 06, 2004 1:10 AM
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] Comment 332
>
>Jeff and All,
>see comments below
>Vladimir
>
>-----Original Message-----
>From: Jeff Mandin
>[<mailto:jmandin@STREETWAVES-NETWORKS.COM>mailto:jmandin@STREETWAVES-NETWORKS.COM]
>Sent: Thursday, May 06, 2004 1:42 AM
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] Comment 332
>
>
>Vladimir and all,
>
>First I want to note that I withdrew my recirc Comment about deleting
>the SMC from the present draft, and currently support Bob Nelson's
>comment 332.
>
>[VY] Note that #332 is about keeping the SMC after network entry,
>not on having it in the standard.
>
>So the whole discussion, though useful, is not directly related to #332.
>
>
>Vladimir Yanover wrote:
>
>> .... 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.
>>
>
>Can B) actually be seen as describing anything other than an additional
>CS SAP? It's even equipped with a MAC address (on the SS). Logically
>speaking , B) places another set of classification mechanisms outside
>the CS that choose one CS SAP (or both SAPs on each SS - in the case of
>802.3/ARP etc.).
>
>[VY] Functionally yes, but B is currently out of the standard's
>scope. BTW, I don't say it's 100% OK.
>
>> 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].
> >
> From our point of view (ie. the 802.16 MAC), ALL received downlink data
>terminates at the SS. So there should be no need for a "flag". What
>happens after the packet is delivered to the CS SAP is the concern of
>the "higher-level application" only.
>
>[VY] It could be yet another solution. For example, SS may decide
>that packet X is addressed to the SS by IP dest address.
>
>
>> 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
>>
>
>Iit's worth noting that there's a class of devices that are "managed",
>but would likely prefer to operate without an SMC. For example, an
>integrated SS/IP phone might carry voice on dynamic UGS connections,
>while carrying call signalling, management, and text messaging on a
>single best-effort connection.
>
>[VY] I disagree with extending term "management". We have to
>distinguish between "management" of SS as 802.16 conformant entity
>
>and "management" of other layers [which typically are vendor
>specific] and devices behind the SS. After all, we are talking on
>what
>
>must be a part of the standard and what must not. >From this point
>of view, call signaling is an application data and must be carried
>on regular traffic connection [presumably different from the UGS one
>carrying voice itself].
>
>
>- Jeff
>
>
>> -----Original Message-----
>> *From:* Yigal Leiba
>>[<mailto:yigall@runcom.co.il>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 332
>>
>> Hi 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 concerned
>> 1. Managed through SMC
>> 2. 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>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 332
>>
>> 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>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>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
>>
>><<mailto:postmaster@redlinecommunications.com>mailto:postmaster@redlinecommunications.com>.
>>
>> Thank 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 mail was sent via 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 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 mail was sent via 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.
>************************************************************************************