Re: [STDS-802-16] Resolution of comment 332
As do I. The secondary management channel is unclean. It's also out of
scope, see Figure 1.
DJ
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Al Dabagh,
Baraa
Sent: Monday, May 03, 2004 9:00 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Resolution of comment 332
I very much support this...
BA
Baraa Al-Dabagh
BWD
Intel Corporation
baraa.al.dabagh@intel.com
Phone: 408-545-6078
> -----Original Message-----
> From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-
> 16@listserv.ieee.org] On Behalf Of Yigal Leiba
> Sent: Monday, May 03, 2004 3:16 AM
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] Resolution of comment 332
>
> Jeff, Vladimir,
>
> I think that the secondary management connection was born in sin, as a
> vehicle to carry the DHCP, TFTP, TOD and similar functionality
inherited
> from DOCSiS. Later on, SNMP was add to the list.
> In my view this is all twisted, because as opposed to DOCSiS which
> emulates a LAN, 802.16 does not, and DHCP and TFTP should in fact be
> handled differently because one is IP and one isn't. I that respect I
> fully support
> the idea to kill SM connection and to specify instead that regular
data
> connection may carry CS SDUs addressed to the SS itself [as
provisioned
> through DSx].
>
> Yigal
>
> -----Original Message-----
> From: owner-stds-802-16@listserv.ieee.org
> [mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Vladimir
Yanover
> Sent: Monday, May 03, 2004 4:43 PM
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] Resolution of comment 332
>
>
> Jeff,
>
> The standard does not preclude from having in BS sort of IP forwarding
> function [not specified in the standard], which decides on forwarding
> traffic from external SNMP console to SM
connection
> [and back]. I wouldn't call it SNMP proxy.
> So seems that external SNMP console may be supported. Note that SM
> connection is very different from those carrying network traffic,
> particularly it is not associated with any service flow [classifiers
> etc.]. One may suggest to add to the standard specification of named
forwarding
> function [in terms of classifiers etc.]. It would be reasonable .
> Another possible option is to kill SM connection and to specify
instead
> that
> regular data connection may carry CS SDUs addressed to the SS itself
[if
> provisioned through DSx].
>
> Vladimir
>
> -----Original Message-----
> From: Jeff Mandin [mailto:jmandin@streetwaves-networks.com]
> Sent: Monday, May 03, 2004 2:26 PM
> To: Vladimir Yanover; stds-802-16@IEEE.ORG
> Subject: Re: [STDS-802-16] Resolution of comment 332
>
>
>
> > My understanding of Secondary Management connection role is to carry
> >traffic from / to the SS itself. particularly, this traffic does not
> >pass CS SAP, but rather goes from
/
> to
> >Management Entities [Fig. 1]
> >
> >Vladimir
> >
> >
> >
> That's really the crux of the issue! IP is an "internetwork
protocol",
> and includes the notion of an "IP interface", which is inevitably
> associated with a MAC SAP.
>
> So SNMP etc. traffic should really be viewed as application traffic
(ie.
> which passes the CS SAP).
>
> Indeed, many people's conception is that the management traffic
> originates at an NMS external to the BS which is then bridged or
> routed. If so, then the traffic certainly passes the CS SAP. For
> external traffic to not pass the CS SAP, we would require a management
> proxy entity.
>
>
>
>
> 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.
>
************************************************************************
**
> **
> ********