Subject: [ipcdn] IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Thu, 15 Jan 2004 11:02:29 -0800

Attached is draft 3 of the Signaling MIB based on the changes requested in a document posted by Broadcom to the IPCDN mailing list on 11/27/2003 (also attached).

To date there has been no comment on any of these issues from the community. Therefore, I am making a request for last call comments on these proposed changes. Please submit any comments on the changes to the reflector by 1/29/2004.

There are five primary changes that I will start separate email threads for if you have comments to make:

1. Modification of the pktcSigDevCodecTable table to reflect MTA codec capabilities
2. Modification of the pktcSigPulseSignalTable to include 5 additional signals
3. Modification of pktcSigDevToneType and elimination of DTMF 0-15, A-D, etc.
4. Proposed need for dB power levels for individual frequencies in the pktcSigDevToneTable table
5. Proposed introduction of country codes for telephony parameters

 <<draft-ietf-ipcdn-pktc-signaling-03.ZIP>> 
 <<Comments on SIG MIB draft-02 (BRCM)_2003-11-27.doc>> 

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
[email-masked]

---

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Thu, 15 Jan 2004 13:17:12 -0800

I'm resending the attachments separately since the email bounced. Gordon

 <<draft-ietf-ipcdn-pktc-signaling-03.rtf>> 

>  -----Original Message-----
> From: 	Beacham Gordon-CGB005  
> Sent:	Thursday, January 15, 2004 11:02 AM
> To:	[email-masked]'
> Subject:	IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments
> 
> 
>  << File: draft-ietf-ipcdn-pktc-signaling-03.rtf (Compressed) >> 
>  << File: Comments on SIG MIB draft-02 (BRCM)_2003-11-27.doc >> 
> 
> Gordon Beacham

---

From: "Matthew Schmitt" <[email-masked]>
Date: Mon, 19 Jan 2004 10:36:41 -0700

David,
	I'm not certain I agree with your statement that: "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."  While I would agree that there is no defined
mechanism for a plain modem to initiate a DSx message, I do not believe
that it is prohibited.  While console access is prohibited, SNMP access
is not (both via the RFI and the CMCI, unless administratively
prohibited), which means that it could be controlled for example via a
proprietary MIB.

Matt

-----Original Message-----
From: David De Reu [mailto:[email-masked]] 
Sent: Monday, January 19, 2004 8:54 AM
To: IPCDN Mailing List
Subject: [ipcdn] Re: IETF IPCDN Signaling MIB - Draft 3 - Last Call for
Comments

Dear all,

Below I have listed some items for discussion based upon trouble points
we found with draft-02. I think it would be beneficial if we could get
these sorted out before draft-03, because it would greatly reduce the
number of ambiguities, thus making it more clear for an MTA vendor how
to implement the MIB.

(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.
   This is because the CMTS must reject all DSx messaging initiated by
   the CM if there is no valid authorization block. There is no such
   block in this case (there even is no gate on the CMTS). Note that
   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. 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).

   Operationally, the practical solution is quite simple. You can add
   the necessary MIB objects in the CM config file (specifying the
   service flow parameters directly, or alternatively using a Service
   Class Name (SCN)). 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. 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. 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?

(2) pktcSigDevRtCadence is superfluous

   The pktcSigDevRtCadence object is not needed, and introduces an
   ambiguity in the MIB. First of all, this object is intended to
   specify the "ring cadence rt", but "rt" is not really a ring cadence:
   it is the ringback tone. The "rt" signal does not cause ringing
   voltage to be applied to the analog line, but causes a *tone* to be
   played to the calling party. Indeed, the ringback tone is included in
   the pktcSigDevToneTable. Like for every tone, the MTA will consult
   this table to determine the properties of the ringback tone, and
   hence the pktcSigDevRtCadence object will not be used anyway.

   Solution: we suggest the removal of the pktcSigDevRtCadence object.

(3) pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence

   There needs to be clarification on the difference between these
   objects and the pktcSigDevRgCadence and pktcSigDevRsCadence. Agreed
   that the latter is for North American systems, and the former is for
   international systems, but it must unambiguously be clear to an MTA
   vendor when to use which object.

   Is it correct to state that an MTA for the international market would
   have to implement both alternatives according to the module
   compliance statement, but it would only use the international pair of
   objects? If this is the case, then why require that the North
   American pair of objects has to be implemented?

(4) pktcSigPulseSignalTable, pktcDevRingCadenceTable and E-package

   Regardless of any changes to the table definitions, we suggest to
   make it clear that they only need to be implemented when the ETSI
   E-package is supported. Without support for the E-package, these
   tables have no use.

   By the way, can the operator currently determine by MIBs which
   NCS packages the MTA supports (and in particular, if the MTA supports
   the E-package)?

(5) Mapping NCS signal requests (tones, rings) to MIB objects

   How will an MTA vendor currently know unambiguously when to use
   which tone or ring cadence definition for a given NCS signal request?

(6) pktcSigDevSilenceSuppression: per codec is better

   It was argued before that on one hand VAD is independent of the
   codec, but on the other hand in practice different VAD
   implementations may be needed for different codecs, and hence the
   presence of such a VAD implementation depends on the codec (so that
   for instance VAD would be supported for G.729 but not for G.711).

   As far as I can see, it is indeed logical to let VAD support depend
   on the codec, since the exact algorithm used for VAD may be different
   for different codecs. This is apparently also the viewpoint taken in
   the PacketCable NCS specification [PKT-SP-EC-MGCP-I08-030728, p.35],
   where we read in the context of an MTA's capabilities (that can be
   queried by an AUEP command): "If there is a need to specify that some
   parameters, such as e.g., silence suppression, are only compatible
   with some codecs, then the gateway will return several capability
   sets". Note that only the CMS can normally send an AUEP that queries
   the MTA for its capabilities, and not the SNMP manager. Therefore,
   the same functionality must also be provided by the MIB.

   In contrast with the NCS spec, the PacketCable PROV spec considers
   VAD independent from the codec (MTA capabilities TLV 5.12). This may
   be a reason to also do it this way in the MIB, but according to the
   arguments above this is not the best thing to do. Therefore we feel
   it is better to adopt a more correct MIB definition instead, i.e.
   letting the support of VAD depend on the codec.

Thanks,

David

_____________________________________________________
David De Reu
tComLabs
Stapelplein 70/004 - 9000 Ghent - Belgium
Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74
www.tComLabs.com _____________________________________________________

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

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

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Fri, 30 Jan 2004 17:56:25 -0800

> Issue #7 - definition of pktcSigDevToneDbLevel
...
> In the current draft-03, this object is specified as follows: 
>  
> pktcSigDevToneDbLevel    OBJECT-TYPE 
>     SYNTAX       Integer32 (-60..4) 
>     UNITS        "dbm" 
>     MAX-ACCESS   read-write 

> (1) The analog reference point seems the logical reference point to use,
>    since this table is about signals that will be generated on the
>    analog line. When the reference point is changed to the digital
>    reference point, will this not be confusing for someone who wants to
>    fill out the values in the table? Maybe that person will have to do
>    a quick calculation to calculate what digital dB level he must
>    provide to obtain the analog dB level he wants, but if this is the
>    case, can the MTA not do this calculation?

This calculation would only need to be done once by the operator so that
the correct defaults could be determined. After that, these defaults would be 
used in the configuration of all MTAs. While we understand the concern, we don't
think that is too big of a hurdle.

>    Second, just as a tought, would the problem also be solved by
>    leaving the description of the object as it is, but changing the
>    range limits?

This would also resolve the issue, however, it might be difficult to
specify (in the MIB) the limited range since it will be dependent on the digital
loss plan deployed in the country. For example, a country that uses -10dB D/A loss
would need to have the tone range restricted to -10...-60. Meanwhile, a country with
very little digital loss (i.e. -3dB) could afford to have a larger range (-3...-60).
MIB definition cannot accomodote multiple ranges for the same object.

> (2) Does this discussion also apply to the pktcSigPulseSignalDbLevel
>    object? In other words, I think the interpretation chosen for the
>    tone dB level should also be the one for the pulse signal dB level,
>    and clarified in the defintion of the latter as well.

Yes, agreed. When the issue with "pktcSigDevToneDbLevel" MIB Object is agreed upon, 
the "pktcSigPulseSignalDbLevel" object should be treated the same way.
Independent of this, it might worth noting that the current range of the 
"pktcSigPulseSignalDbLevel" MIB Object (-250..152) is very large considering only 
one of the modes (meterPulse) uses it and the country specifications do not require 
it to be so high. We would recommend reducing this to a more reasonable range 
of (-250..0).

>    Also, is it intentional that the SYNTAX of the
>    pktcSigPulseSignalDbLevel object is TenthdBm, and that it is
>    Integer32 for pktcSigDevToneDbLevel?

We agree. By using "TenthdBm" SYNTAX in all "dB" related MIB objects we would make 
the SIG MIB more consistent.

Eugene.

3fj)b�	b��3bz��m��?�0�'�~���f��f��X��)ߣ��q�