headers
Beacham Gordon-CGB005 | 1 Apr 2004 21:35

NCS Signaling MIB SC Objects

Jean-Francois,

Please comment on the CL position regarding the deletion of the following service class objects from the
NCS MIB as proposed by ETSI. The last notes I have indicate the CL DQoS team was investigating this issue as
originally raised by tComlabs. Thanks.

>Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, pktcSigServiceClassNameMask
and pktcSigNcsServiceFlowState objects from the current MIB definition until a workable form of its
associated mechanisms is defined.
>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 works, because in this case the Service Flow is set up
during the CM Registration process, without the need for DSA messaging. This is also probably the way it is
currently done, since the use of the above MIB objects is not possible with an IPCablecom/PacketCable
compliant 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.
Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
gordon.beacham <at> motorola.com
Permalink | Reply | 0 comments |
headers
Beacham Gordon-CGB005 | 1 Apr 2004 21:36

pktcSigDevToneDbLevel syntax change


> I think the issue with "pktcSigDevToneDbLevel" has not been
> completeley agreed upon (see attached is the latest feedback from
> Broadcom).

Agreed. Change has been made to:

   pktcSigDevToneDbLevel    OBJECT-TYPE
       SYNTAX       TenthdBm (-250..-30)

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
gordon.beacham <at> motorola.com
Permalink | Reply | 0 comments |
headers
Beacham Gordon-CGB005 | 1 Apr 2004 21:36

RE: Editorial Changes - NCS MIB

Agreed. Thanks for your comments. Gordon

-----Original Message-----
From: David De Reu [mailto:DeReu <at> tComLabs.com]
Sent: Tuesday, March 30, 2004 10:50 PM
To: IPCDN Mailing List; azlina <at> cisco.com; Beacham Gordon-CGB005
Subject: RE: [ipcdn] Editorial Changes - NCS MIB

> > 3. Change pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } to:
> >    pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 }
>
> Recommend keeping the notification as it is per Appendix D
> of the draft-ietf-ops-mib-review-guidelines-02.txt.

Good point indeed. We currently have

  pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 }
  pktcSigMibObjects   OBJECT IDENTIFIER ::= { pktcSigMib 1 }
  pktcSigConformance  OBJECT IDENTIFIER ::= { pktcSigMib 3 }

When we follow the OID layout suggested in appendix D of
<http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02
.txt>, which is

  xxxMIB
  |
  +-- xxxNotifications(0)
  +-- xxxObjects(1)
  +-- xxxConformance(2)
      |
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eugene Nechamkin | 1 Apr 2004 21:45
Favicon

RE: pktcSigDevToneDbLevel syntax change

Thanks.

Eugene.

-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham <at> motorola.com]
Sent: Thursday, April 01, 2004 11:36 AM
To: 'ipcdn <at> ietf.org'; 'David De Reu'; Eugene Nechamkin; Beacham
Gordon-CGB005; Wim De Ketelaere
Cc: Jean-Francois Mule
Subject: [ipcdn] pktcSigDevToneDbLevel syntax change

> I think the issue with "pktcSigDevToneDbLevel" has not been
> completeley agreed upon (see attached is the latest feedback from
> Broadcom).

Agreed. Change has been made to:

   pktcSigDevToneDbLevel    OBJECT-TYPE
       SYNTAX       TenthdBm (-250..-30)

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
gordon.beacham <at> motorola.com
Permalink | Reply | 1 comment |
headers
perozbabu | 2 Apr 2004 02:58
Picon

Re: Please unsubscribe my access to ipcdn


sir,
      Please unsubscribe my access to ipcdn

Thanks,

Peroz Babu

                                                                                                                                       

                      mailman-owner <at> www        To:       perozbabu <at> mototech.com.tw                                                     
                      1.ietf.org               cc:                                                                                     
                      Sent by:                 Subject:  ietf.org mailing list memberships reminder                                    
                      mailman-admin <at> iet                                                                                                
                      f.org                                                                                                            

                                                                                                                                       
                      04/02/2004 12:19                                                                                                 
                      AM                                                                                                               

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 2 Apr 2004 02:22
Favicon

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wim De Ketelaere | 2 Apr 2004 08:04

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 6 Apr 2004 22:58
Favicon

IPCDN qos mib - publication has been requested

Folks,

We have requested publication of the ipcdn-qos-mib ID as Proposed Standard.
This ID had passed WGLC and we had responded to AD comments in November.

Publication requested for:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt

Please note that once a request to publish an ID as an RFC has 
been submitted, the ID must not be revised without the explicit 
advance approval of the shepherding Area Director (AD) [Bert Wijnen].

Jean-François 
IPCDN co-chair
Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 6 Apr 2004 23:11
Favicon

RE: Re: Please unsubscribe my access to ipcdn

You may do this yourselves at:
http://www1.ietf.org/mailman/listinfo/ipcdn

Peroz Babu wrote:
> sir,
>       Please unsubscribe my access to ipcdn
Permalink | Reply | 1 comment |
headers
Jean-Francois Mule | 7 Apr 2004 00:12
Favicon

RE: 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
(Continue reading)

Permalink | Reply | 1 comment |

Gmane