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

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