Re: [STDS-802-16] Resolution of comment 332
By my reading of D4, the TLV is a mandatory entity in the REG-REQ
message in which the SS must specify its desire for management
support/traffic over the SMC. The BS is expected to respond in the
REG-RSP TLV and either confirm or deny the SS request. As a result, the
override capability that Phil suggests is already in the document.
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Phil Barber
Sent: Monday, May 03, 2004 3:36 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Resolution of comment 332
While I agree with Yigal's assessment, I am concerned about the result
of attempting to excise SMC from the document at this late date. I
worry that in our haste to remove SMC we might miss important direct or
indirect SMC references without opportunity for repair, thus sacrificing
the integrity of the document. I think the TLV solution very sensible.
It limits SMC impact to network entry for implementors not interested in
maintaining the function while otherwise maintaining document
continuity. It might be wise to let BS have override control of SMC
post-network entry persistence through SBC-RSP TLV since BS is network
resource gatekeeper (I don't remember if this feature is present in the
proposed solution).
Thanks,
Phil
---------- Original Message ----------------------------------
From: Radu Selea <Radu@REDLINECOMMUNICATIONS.COM>
Reply-To: Radu Selea <Radu@REDLINECOMMUNICATIONS.COM>
Date: Mon, 3 May 2004 13:57:48 -0400
>Itzik ,
>
>I am not in disagreement with that but I can foresee few issues that
should be clarified, before killing SMC.
>1. The desire is to have a separate management path. In the standard is
written:
>"If no classifier is found in which all parameters match the packet
then the packet
>is delivered under vendor- or operator-specific conditions. Two actions
may be performed: the packet may
>be delivered using a "default" connection, or the packet may be
discarded. "
>This is no separation anymore.
>
>So, a vendor has the liberty to put on that 'default ' connection
packets related to management along with packets related to traffic. I
am talking here about packets that are not necessarily covered by the
classification rules (fields) present in the document.
>As long as these situations are not taken into consideration ,I would
not agree to delete something that is there .
>SM connection carries delay tolerant messages. There are a lot of
techniques to solve the forwarding issues on this path which we cannot
use for regular traffic because of implementation reasons. The existence
of the SMC narrow somehow the possibilities of messing with these
issues.
>The BS contains information about SS's (MAC , IP ...) and sometime does
not contain the same information for users devices. That means we cannot
solve the problems in an homogenous way.
>
>2. Unfortunately ,every vendor has a view on how he wants to use the
system and network deployment. Every try to get out of a particular
pattern, is leading to a rejection state. Then the usual compromise is
to let them as generic as possible which is bad.
>Then , I would prefer first to have a solution and then to delete
whatever is required.
>
>3. I am agreeing that the standard content that refers to SMC is not
clean, but I think we should clean it not delete it. Anytime we are not
comfortable about something, we label it as 'out of scope'. And the SS
management issue is as out of scope of our work, as the interoperability
is ...
>
>
>
>
>Cheers,
>Radu.
>
>-----Original Message-----
>From: owner-stds-802-16@LISTSERV.IEEE.ORG
>[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of Itzik Kitroser
>Sent: Monday, May 03, 2004 11:20 AM
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] Resolution of comment 332
>
>
>Radu,
>
>I think that what Yigal was trying to say is that there is a
replacement
>in the form of a "regular" service flow, which will be mapped in a
>proper way and which will retain the functionality of the SMC.
>
>If a SF can be mapped (and I believe it can) directly to the managed
SS,
>and with proper policy parameters, it will be handled from a scheduling
>point of view in a same way as the SMC.
>
>Taking the above, it makes sense to have a handle the higher layer
>management in a regular format; also it is more flexible/extendable.
>
>Regards,
>Itzik.
>
>-----Original Message-----
>From: owner-stds-802-16@LISTSERV.IEEE.ORG
>[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Radu Selea
>Sent: Monday, May 03, 2004 3:03 PM
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] Resolution of comment 332
>
>Yigal,
>
>Aside of your views of what DOCSIS wants to emulate or not, which are
>interesting , I cannot agree with you because of few reasons:
>1. SMC was not born quite in sin , but us with our original strategies
>ended with a tormented concept. SMC is quite functional in DOCSIS and
>let's not forget that DOCSIS targets the same market , ACCESS. They had
>few revisions on the base document since then and nobody killed the
>sinful SMC. They do not mobility ,of course...
>2. I cannot agree with killing something without a replacement.
>
>As about the nature of traffic on SMC , I agree with you ,it is not all
>IP.
>
>
>
>-----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 6: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.
>***********************************************************************
*
>****
>********
>
>
>
>
>Thank you.
>