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

Re: [STDS-802-16] Comment 332



Title:
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]
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]
>     *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]*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]*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] *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>.
>
>         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.
************************************************************************************