RE: NCS Signaling MIB SC Objects

Hi all,


I do not discuss the usefullness of the objects,
I just believe they don't work due to the way the spec is currently
written for the CMTS.


section 3.2.5 of DQOS-IO8 clearly specifies:

If the PacketCable Authorization Module receives a bandwidth reservation
request (i.e. a DSA) without an authorization block,
the CMTS must reject the request.

Unless the dQoS specification is changed so that a clear distinction is
made between what is meant

for PacketCable authorization 
and what is not, 

 I still don't see how it can work.

It is clearly not the intention of the PacketCable specification that
any DSA for a SCN will always succeed, this would be 
a very easy theft-of-service scenario,.....

The DSA for the SCN will be a valid DSA on the DOCSIS level, but if the
CMTS has PacketCable enabled, it will not
pass the authorization module and be rejected for that reason, this is,
unless we change something on the requirements for a CMTS. 

But I don't have an easy solution for that, just stating that any SCN
can be allowed without authorization
opens up a security hole,...


Just stating that it is valid on the DOCSIS level and is therefor okay
is, I believe, a too easy answer,
this would make any PacketCable compliant CMTS, non-DOCSIS compliant. A
PacketCable CMTS MUST reject a DSA
without the authorization block present !


If needed I can clarify my reasoning, in a conf call if this helps to
solve the problem, this problem is already 
on discussion for too long !


Thanks,
  Best regards,
    Wim


Wim De Ketelaere
CTO
tComLabs 








-----Original Message-----
From: Jean-Francois Mule [mailto:[email protected]] 
Sent: 02 April 2004 02:22
To: Beacham Gordon-CGB005; David De Reu; Wim De Ketelaere
Cc: [email protected]; Richard Woundy @ Comcast; Kevin Johns
Subject: 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