Re: [STDS-802-16] Resolution of comment 332
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.
************************************************************************
****
********
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.
Thank you.