| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----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.
************************************************************************************