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

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