RE: RE: NCS Signaling MIB SC Objects

Leaving the issue of the justification of the NCS SF feature itself aside, and assuming that the idea of having the NCS flows with QoS can look usefull to MSOs, Broadcom would second this view. There seems to be no obvious restrictions in the DOCSIS and/or PacketCable specs which would not allow the MSOs to Securely Create NCS SF either by completely relying on the existing PacketCable security meachinsim (SCN is delivered to the MTA over the SNMPv3 Secured channel), or by implementing vendor specific mechanisms to augment or extend the existing ones for better/wider access control on the CMTS side.

This, obviously, does not mean that the NCS SF related objects in SIG MIB do not need some additional work and clarification. For example, the fact that different CMSs can be assigned to the different end-points of the MTA, cannot be accomodated by the exitsing NCS SF related MIB Objects. Another example - pktcSigServiceClassNameMask which does not seem to be required as this value is supposed to be provided in the NCS SF US/DS classifiers pre-provisioned on the CMTS and identified by the SCN. Instead, there is a real need to have an object (currently lacking) which would provide unambigous means for NCS SF creation/deletion (for eachg direction - DS/US).

Eugene.



-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Jean-Francois Mule
Sent: Tuesday, April 06, 2004 3:12 PM
To: Wim De Ketelaere; Beacham Gordon-CGB005; David De Reu
Cc: [email protected]; Richard Woundy @ Comcast; Kevin Johns
Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects


Hi Wim,

We had some additional discussions internal between the PacketCable & DOCSIS guys, and we concur on our spec(s) interpretation (Greg on the DOCSIS side, Kevin and I on the PacketCable side). More importantly, the CMTS vendors seem to be in sync with our interpretation based on what we have seen in our labs ([CMTS vendors, feel free to speak up here]).

Here's what we can summarize:
1)  The PacketCable specs do not intend to imply (nor require) that DSx-REQs that lack a PacketCable Auth Block be authorized by the "PacketCable Authorization Module".  While we do define the behavior of the "PacketCable Authorization Module", we do not preclude CMTS to employ other modules to authorize DOCSIS-based DSx requests. Perhaps the text could be clarified in DQOS sec. 3.2.5 to add some informative text around that. However, our understanding is that vendors are clear on this already.  The PacketCable compliant CMTS will support at least two independent authorization modules: one for DSx-REQs that contain a PacketCable Auth Block as defined in DQOS I09, and one for those that do not. Again, if there is no packetcable TLV in the DSx req, why shouldn't this request be processed by a docsis authorization module? 

2)  The treatment of DSx-REQs that lack a PacketCable Auth Block is currently in the realm of vendor differentiation.  DOCSIS only requires that the CMTS authorize the request in some manner.  Whether that authorization defaults to "allow" for all requests, "deny" for all requests, or some rules in between is left to the CMTS vendor and its QoS policy configurations.

3)  This feature is defined so that the operator can configure high-priority signaling flows for the MTAs on their system.  In order to use this feature, they will need to take a number of steps, including configuration of the CMTS to allow (ie "pre-authorize") the creation of service flows based on the SCN in the MTA config file. And Greg, Kevin and I strongly agree that these mib objects are more suited in the MTA config file than in the CM one.

4)  Even if the operator misconfigures the CMTS (either by not defining the SCN, or by not "pre-authorizing" it), or the CMTS doesn't support this feature, the MTA will only attempt to create the signaling flow, and then upon failure,  default to sending all signaling traffic on the primary US/DS service flows.

Therefore, we maintain that these 3 mib objects are pertinent and should stay in the MTA mib.

Jean-François 

> -----Original Message-----
> From: Wim De Ketelaere [mailto:[email protected]]
> Sent: Thursday, April 01, 2004 11:04 PM
> To: Jean-Francois Mule; 'Beacham Gordon-CGB005'; 'David De Reu'
> Cc: [email protected]; Richard Woundy @ Comcast; Kevin Johns
> Subject: [ipcdn] 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.
Note the informative statement (lowercase) is on the PacketCable Auth Module. Note that a PacketCable CMTS is a DOCSIS compliant CMTS as well and when it sees a DSx request from the eCM embedded in the MTA that does not contain any packetcable tlvs, the CMTS has no way of saying: but hey, that's a PacketCable MTA request so one could argue that this requirement is really for those DSA requests that do contain some packetcable tlvs but the request is malformed or wrong.

> 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.
I hope my earlier email and the explanations above have helped clarified this.

> It is clearly not the intention of the PacketCable
> specification that any DSA for a SCN will always succeed, 
That is a question of MSO policy authorization and is left for vendor differentiation. Some QoS policy configuration & information models are available in IETF but this is out of the scope of our QoS specs. 

> this would be 
> a very easy theft-of-service scenario,.....
An operator would have to allow this.

> 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 
 ^
 PacketCable authorization module
  and again, it does not even hit the PacketCable auth module but that it gets handled by the plain docsis auth module.

> 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,...
Operator decision.

> 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 !
We disagree.

> 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
> 
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn