RE: NCS Signaling MIB SC Objects

Okay, now it is my turn to be reminded to close on some issues, I see... ;) thx for the reminder.

We did discuss this question internally with the packetcable team. We believe that these 3 MIB objects still make sense and that they must be kept in the NCS signaling MIB. I will try to provide some justification below. I also cc: Kevin Johns who is our PacketCable QoS lead so he can chime in on the responses to this note, and may be Greg White can help too.

--- Context
These 3 objects are typically used in the MTA config file to indicate specific service class name(s) corresponding to a pre-provisioned set of QoS paramaters on the CMTS. If SET in the MTA config file, the MTA can instruct the CM to generate a SF with the specific service class name (SCN) so that the MTA NCS signaling packets can use the special service flow rather than best effort. Unlike PacketCable DQoS which defines AuthBlock and TLVs like gateid for the MTA to use in the DSx msging, the SCN use is not intended to use any of the packetcable gate related parameters => no AuthBlock. DQoS DSx is used to create/modify SF dynamically for the media streams: NCS starts as soon as the MTA provisioning is complete, the MTA registers with the CMS (RSIP, etc.) and a call can be initiated (NCS CRCX with gate info in LCO,...) and QoS can be installed for that call.  The pb is to guarantee some QoS for the NCS data and this is what those objects are for.
So these objects are valid to use in a DOCSIS dialog initiated by the embedded CM of the MTA with the CMTS. A DSx message with a classifier and SCN for US|DS and no AuthBlock (hence no gateID) is a valid DOCSIS qos message. Upon activation, the SCN-based flow, NCS runs over qos SF. 

--- Response to questions from  both Gordon (4/1) and David (1/19)
On Thrusday April 1st, Gordon wrote:
> >Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, 
> >pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState 
> objects from 
> >the current MIB definition until a workable form of its associated 
> >mechanisms is defined. 
I don't see what's wrong with the mechanism I described above. It seems a workable form to me & Kevin.


Gordon wrote:
> The removal of these objects from the 
> MIB does not mean that there is no more mechanism to 
> establish a separate NCS Service Flow,  because such a Service 
> Flow can still be defined in the Cable Modem config file 
> (with the use of a Service Class Name if desired). 
This breaks the whole concept of decoupling the data provisioning from the voice provisioning. Why ask the data provider to put special CM config for some voice NCS signaling flows that the Telephony Service Provider might use? Why not keep the trigger of a special flow for NCS in the telephony prov, especially since this is an E-MTA with an embedded CM => the MTA f() can very effectively pass the SCN params onto the CM?

> This 
> works, because in this case the Service Flow is set up during 
> the CM Registration process, without the need for DSA 
> messaging. 
An E-MTA has an embedded cable modem and it is valid for an E-MTA to initiate plain docsis DSx messaging (in addition to the DQoS flavored ones).

> This is also probably the way it is currently 
> done, 
See above.

> since the use of the above MIB objects is not possible 
> with an IPCablecom/PacketCable compliant CMTS. 
Disagree. See context above: a compliant ipcablecom/packetcable CMTS is also a compliant DOCSIS CMTS.

> Leaving the 
> MIB objects in place, while awaiting the definition of a 
> workable mechanism is not an option either, because this new 
> definition would most likely have different MIB requirements.
This works today, and is used.


On January 19, 2004, David de Reu wrote:
> (1) pktcSigServiceClassName(US|DS|Mask) objects
> 
>    There is still a problem with the 
> pktcSigServiceClassName(US|DS|Mask)
>    objects (and indirectly with the related pktcSigNcsServiceFlowState
>    object). Although the MIBs currently reflect the PacketCable PROV
>    spec text, the proposed system for setting up a signaling service
>    flow will *NOT* work with a PacketCable/IPCablecom compliant CMTS.
How so? This is incorrect.
Note that Service Class Names are also used in the so called "PacketCable Multimedia" QoS (a policy server using COPS can invoke a SCN which will trigger the CMTS to initiate DSx with a CM).

>    This is because the CMTS must reject all DSx messaging initiated by
>    the CM if there is no valid authorization block. 
This assumption is not valid. If no Authblock, treat the DSx like a plain docsis msg (and if there's a correct classifier and a valid pre-provisioned SCN that can be matched on the CMTS, proceed with SF).

> There is no such
>    block in this case (there even is no gate on the CMTS). Note that
Yes no authblock but there's a SCN which matches some pre-provisioned QoS data on the CMTS.

>    this does not mean that PacketCable takes a step backward 
> compared to
>    (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that 
> a CM is not
>    allowed to initiate DSx messaging, since it is not allowed 
> to expose
>    an interface to the outside world to do this. 
I'm not sure I follow this point.

> For an 
> embedded MTA in
>    PacketCable, this interface is present and the DSx 
> messaging *can* be
>    initiated by the CM, but the CMTS will accept it only if the
>    appropriate authorization can take place (using the authorization
>    block).
Nope, that is true for an E-MTA initiated DSx message compliant to DQoS only. I'm told this assertion is not true for a CM initiated DSx msg.

>    Operationally, the practical solution is quite simple. You can add
>    the necessary MIB objects in the CM config file (specifying the
If this is for the NCS flow, why not the MTA config file -- again keep the telephony related config param in the MTA portion of the prov.

>    service flow parameters directly, or alternatively using a Service
>    Class Name (SCN)). 
Well, this is exactly what we are doing here and it just happens to be in the SIG MIB so that the MTA which is the entity generating the NCS traffic knows what SCN <-> SF to use to pass on the data to the eCM.

> In that case, the CM will set up the 
> service flow
>    during its registration, without the need for DSx messaging.
> 
>    Solution: It is of course not up to the SIG MIB to provide 
> a solution
>    to this problem. 
Why not if it is for the NCS signaling?

> However, if the 
> pktcSigServiceClassName(US|DS|Mask)
>    objects *are* included in the MIB, then you have a set of 
> objects of
>    which you know on forehand that they are useless. 
We obviously do not agree and this has been in our specs for many years now.

> So the question
>    seems to me: do we want to include these objects in the 
> MIB? We could
>    also leave them out now, and wait for a correctly functioning
>    mechanism to be defined in the PacketCable/IPCablecom specs.
>    Alternatively, if the objects remain in the MIB, then we 
> have to ask
>    ourselves what will be required from an MTA: we will 
> require that the
>    MTA does the DSA nevertheless, knowing that it will not succeed
>    anyway?


I hope I've helped clarified this.
Jean-François