Page 1 IPCDN Working Group IETF 60 - IPCDN WG Update Richard Woundy Jean-François Mulé IPCDN Co-Chairs Tuesday August 3 rd, 2004 [email protected]

IPCDN Working GroupPage 1

IETF 60 - IPCDN WG Update

Richard Woundy

Jean-François Mulé

IPCDN Co-Chairs

Tuesday August 3rd, 2004

[email protected]

[email protected]


Meeting Agenda

• Agenda Bashing• Administration• IPCDN DOCSIS MIB Updates

– Internet-Drafts in IETF Last Call» Subscriber Mgmt MIB draft 14» DOCSIS BPI+ MIB draft 13

– DOCSIS QoS MIB draft 9

– DOCSIS RFI MIB draft 11

– DOCSIS Event Notification MIB draft 3

– DOCSIS Cable Device MIB v2 draft 6

• PacketCable/IPCablecom MIB Updates– MTA MIB

– Signaling MIB

– Management Event MIB

• Next Steps


Note Well & Intro

• Registration included materials referring to RFC 3667 and RFC 3668

• As usual, this IPCDN WG meeting and all IETF contributions are subject to the rules of RFC 3667 and RFC 3668

• Call for:– WG meeting notes takers

• Blue sheets


Administration

• IPCDN WG Charter and Updated Milestones – WG Milestones updated on July 23rd 2004

http://www.ietf.org/html.charters/ipcdn-charter.html– 3 new WG milestones completed:

DOCSIS Subscriber Management, BPI+ MIB and DOCSIS QoS MIB are marked as DONE

• WG Work Plan and Upcoming Milestones– Sept 2004:

» Goal: conclude all DOCSIS and PacketCable MIB work

– December 2004» Goal: conclude CableHome MIB work

• Any comments on charter update from WG?


IPCDN DOCSIS MIB Updates



QoS MIB draft09by Will Murwin and Michael Patrick - Motorola


Diffserv Context

• The IETF diffserv RFCs define the layout of the DS field:– the IPv4 TOS octet

– the IPv6 Traffic Class octet

• IETF RFC 2474 and RFC 2475 approved in December 1998• IETF RFC2481 approved in January 1999 as experimental,

deprecated by standard track RFC 3168 in September 2001

0 1 2 3 4 5 6 7 +---+---+---+---+---+----+---+---+| DSCP |ECN bits|+---+---+---+---+---+----+---+---+

DS field structure

DSCP: differentiated services codepointECN: Explicit Congestion Notification, RFC 2481, now RFC3168


Concerns raised by OPS AD

• In reviews of previous versions of the IPCDN DOCSIS QoS MIB, AD Bert Wijnen raised concerns about the use of TOS overwrite (full 8-bit value)

• Concerns expressed by IETF Area Director and diffserv wg chairman Brian Carpenter– The DOCSIS QoS MIB defines ways to potentially modify the

ECN bits which might cause serious impact in the network

– The impact could propagate to the Internet Backbone if diffserv re-marking is not operated properly at trusted boundaries

• Recommendations to authors:– Restrict diffserv marking to DSCP field only (6 bits)

– Do not allow any spec to alter ECN bits when modifying diffserv service classes

– Do not use a mask for DS field


DOCS QOS MIB: 1 Open Issue

1 remaining OPEN ISSUE• The DOCS QOS MIB

draft-ietf-ipcdn-qos-mib-09 contains two read-create TOS related MIB objects

– docsQosServiceClassTosAndMask – docsQosServiceClassTosOrMask

(I-D references the obsolete IPv4 TOS Octet as defined in RFC 791)

• These objects define the “TOS Overwrite” parameters for an upstream service class. They allow the operator to modify individual bits in the IPv4 TOS Octet including ECN bits.

• Issue:– These 2 objects can be SET through

SNMP, and their values could change a packet’s ECN bits.

– DSCPs are not supposed to be “masked”

– The use of TOS in object names is discouraged, in favor of DSCP

PROPOSED RESOLUTION for WG REVIEW

• Make the 2 TOS objects read-only– Allow operator to maintain

existing DOCSIS implementations – Reference the definition of TOS

per RFC 2474 with ECN bits as defined in RFC 3168

• Add a new writable object for “DSCP Overwrite”

– Allow diffserv compliant operation & preserves ECN

– Use DscpOrAny Textual-Convention from RFC 3289

» Values 0..63 = overwrite DSCP with value

» Value –1 = don’t overwrite

• Maintains object naming conventions that exist in QoS MIB & DOCSIS RFI Specification while allowing better control of DSCP values


Next steps for QoS MIB

• If WG is ok the proposed resolution, WG chairs to validate the fix will meet the requirements to move I-D to publication & IESG

• Update QoS MIB draft

• WG Chairs to request publication



RF MIB v2 draft 10 and draft 11 draft-ietf-ipcdn-docs-rfmibv2-11.txt

by Eduardo Cardona – [email protected]


RFIv2 MIB Draft Changes

• Draft 10 – Published in April 2004– WGLC completed with 1 one pending issue

» Raised by Andrew Donati for StorageType Objects.

» Extensive comments from Randy Presuhn in this discussion. Many thanks to Randy for his valuable advice.

» Resolution: Added StorageType object in docsIfCmtsModulationTable

– Additional object descriptions & clarifications – see list

• Draft 11 – Published in July 2004– Clarifications for three MIB objects (see next slide)– Draft ready for publication pending final WG chair review


RFI v2 MIB Draft 11 Changes

• Draft Status– 3 clarifications made from IPCDN participant comments

• Comments about MIB object docsIfSigQMicroreflections, Dan Rice and Randy Presuhn

– Removed Discontinuity statement for object docsIfSigQMicroreflections,

– Units changed to “-dBc”

• Correction in docsIfCmStatusValue, Andrew Donati, Lucy Pollak– Aligned enumeration references about docsIfCmtsCmStatusValue in

the description clause of docsIfCmStatusValue.

• Added read-only Compliance to CM MIB object docsIfCmStatusValue

– By design, it may be preferable to have a read-only object syntax, but it comes from RFC 2670



DOCSIS BPI+ MIB draft 13 draft-ietf-ipcdn-bpiplus-mib-13

by Eduardo Cardona – [email protected]


BPI+ MIB Draft Changes

• Draft 13– AD Bert Wijnen sent review comments on draft 12 on

07/14/2004:» 12 items needed to be address for ID publication and IETF Last

Call» 5 clarification requested

– Draft 13 posted in 07/19/2004 closing all AD comments

– IETF Last Call was issued on DRAFT 13

• Draft 14 pending– Will include additional clarifications:

» mainly for BPI+ Multicast and » ZeroBasedCounter32 objects

– Should address any IETF Last Call comments


BPI+ MIB Draft 13 Changes

• Draft Status– Draft 13 in IETF Last Call 07/27/2004

• Added Persistent requirements:– docsBpi2CmAuthReset, docsBpi2CmtsDefaultAuthLifetime,

docsBpi2CmtsDefaultTEKLifetime, docsBpi2CmtsMulticastAuthEntry, docsBpi2CmtsProvisionedCmCertEntry, docsBpi2CmtsCACertEntry

– Added object docsBpi2CmtsIpMulticastMapStorageType

• Added default value indication to docsBpi2CmtsIpMulticastSAType for SNMP created entries in docsBpi2CmtsIpMulticastMapTable

• ZeroBasedCounter32 objects:– Refined requirements

» Removed from description Multiple objects ‘Since Reboot’ or ‘Since entry creation’ in consideration of wrap-up times

» Add discontinuity statement, (revisited in draft 14 per MIB doctors observations)


BPI+ MIB Draft 13 Changes (Continued)

• Null String sentenced changed for zero-length OCTET STRING:– docsBpi2CodeCvcUpdate, docsBpi2CmtsCACertThumbprint,

docsBpi2CmtsCACert, docsBpi2CmtsProvisionedCmCert, docsBpi2CmtsAuthBpkmCmCert, docsBpi2CmDeviceCmCert

• Correction in docsBpi2CmtsAuthCmExpiresOld:– columnar value is not instantiated if CM related to entry is in BPI mode.

• Unsigned32 (1..4294967295) instead of X (1..10000) for:– docsBpi2CmtsAuthCACertIndexPtr, docsBpi2CmIpMulticastIndex and

docsBpi2CmtsIpMulticastIndex

• docsBpi2CmIpMulticastMapTable updates:– Deleted object docsBpi2CmtsIpMulticastMaskType (renumbered OIDs)– docsBpi2CmtsIpMulticastAddressType InetAddressType for both …

MulticastAddressType and …MulticastMask objects. – Removed RowStatus objects requirements in conflict with aging non-

active entries (RFC 2579).


BPI+ MIB Draft 13 Changes (Continued)

• Re-rooted branches:– docsBpi2Notification ::= docsBpi2MIB.0– docsBpi2Conformance ::= docsBpi2MIB.2

• Removed restriction to delete active rows in docsBpi2CmtsProvisionedCmCertStatus.

• NITs– Added Reference Citations in IMPORTS clause as comments– Objects docsBpi2CmtsCACertSubject and docsBpi2CmtsCACertIssuer:

» Follow recommendations of UTF-8 OCTET STRING notation to represent ASCII CR and LF

– docsBpi2CmDeviceCmCert : added ‘InconsistenValue’ exception to description

– Added Note about DES encryption in Security Considerations section “BPI+ Encryption Algorithms”

– Clarified description of docsBpi2CmtsDefaultSelfSignedManufCertTrust



DOCSIS Event Notification Mgmt MIB draft 03 draft-ietf-ipcdn-docsisevent-mib-03.txt

by Greg Nakanishi – [email protected]


DOCSIS Event Notification MIB

• Draft updated in May 2004

• MIB doctor review completed by Harrie Hazewinkel

• 1 open issue: Should include the event level and event text be included with the event id in the varbinding list?

There are two options to consider (see Greg’s email)

– 1) Send event id, event level, and event text in the notification. The application gets required info from the notification, no lookup table is needed. The message size is larger than option 2.

– 2) Send just the event id in the notification. The application uses some type of lookup table to determine the event level and event text. The message size is smaller than option 1.

• Open discussion(also please send text to the list)

• Next steps for I-D– Close open issue, update the draft and request publication


IPCDN IPCablecom/PacketCableMIB Updates

MTA MIB draft04by Eugene Nechamkin – Broadcom

and Jean-François Mulé - CableLabs


Status of MTA MIB

• Draft 03 was also reviewed by ETSI IPCablecom with no comments

• Draft 04 addresses known issues from– IPCDN– PacketCable OSS working group

• WGLC issued on 7/21, to conclude on 8/10• Draft under MIB Doctor review by Randy

Presuhn


PKTC MTA MIB Draft 04 Changes

• Several updates:– Sub-sections itemization removed in the Terminology Section– Alignment with latest PacketCable™ Specifications and Engineering

Change Notifications– The lists of Normative and Informative references have been updated.– Descriptions for number of Objects were modified: e.g.

pktcMtaDevSerialNumber, pktcMtaDevSwCurrentVers, pktcMtaDevProvisioningTimer, pktcMtaDevProvisioningState, pktcMtaDevConfigFile, pktcMtaDevProvConfigHash,

• The pktcMtaDevProvisioningCounter MIB object introduced– We experienced some testing issues which caused this counter to be

added

• To reflect the introduction of the new SNMP Provisioning flows, the description of the following objects have changed: pktcMtaDevProvConfigHash, pktcMtaDevProvConfigKey, pktcMtaDevSnmpEntity, pktcMtaDevProvSolicitedKeyTimeout, and others.

• Next steps:– Address any technical issues from Randy’s MIB doctor review or

WGLC– Publish draft05 and request publications


IPCDN IPCablecom/PacketCableMIB Updates

MTA Signaling draft05by Gordon Beacham – Motorola


Status

• IETF NCS Signaling MIB 5– Posted 7/16– Addressed feedback from ETSI

• IPCDN WG Last Call– 7/21-8/10


Changes

• Deleted objects– pktcSigServiceClassNameUS– pktcSigServiceClassNameDS– pktcSigServiceClassNameMask– pktcSigNcsServiceFlowState– pktcSigDevStandardRingCadence– pktcSigDevRingSplashCadence

• Changed pktcSigDevToneDbLevel syntax– SYNTAX TenthdBm (-250..-30)

• Changed pktcSigPulseSignalDbLevel syntax– SYNTAX TenthdBm (-350..0)

• Changed pktcNcsEndPntConfigMaxHookFlash syntax to match pktcNcsEndPntConfigMinHookFlash

– SYNTAX Unsigned32 (20..1000)


Changes – continued

• Defined PktcRingCadence TC– This object represents a ring cadence and repeatable

characteristics in a bit string format. The first two octets of the bit string represent the length in bits of the duration of the cadence (i.e., the number of bits that follow the third octet). The third octet is used to represent repeatable characteristics. 00000000 means repeatable, and 10000000 means non repeatable. Each bit after the third octet represents 50 ms and 1 represents ring and 0 represents silent. The first bit of the fourth octet is the first bit of the ring cadence. All bits are counted in network order such that the octet with only the first bit set will look like 10000000 bit sequence. A total of 264 bits can be set to represent 13200 ms of total cadence cycle. There will be at most 3 on/off transitions per cadence period.

– SYNTAX OCTET STRING (SIZE(4..36))



• Changed cadence objects to use new TC– pktcSigDevR0Cadence, pktcSigDevR1Cadence, pktcSigDevR2Cadence– pktcSigDevR3Cadence, pktcSigDevR4Cadence, pktcSigDevR5Cadence– pktcSigDevR6Cadence, pktcSigDevR7Cadence, pktcSigDevRgCadence,

pktcSigDevRsCadence, pktcSigDevRingCadence

• Revised descriptions for:– pktcNcsEndPntConfigStutterDialToneTO,

– pktcNcsEndPntConfigReorderToneTO, pktcNcsEndPntConfigRingBackTO

– pktcNcsEndPntConfigRingingTO, pktcNcsEndPntConfigOffHookWarnToneTO

– pktcNcsEndPntConfigMessageWaitingTO, pktcNcsEndPntConfigDialToneTO

– pktcNcsEndPntConfigBusyToneTO

» This object contains the default timeout value for stutter dial tone. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message.



• Revised pktcNcsEndPntConfigCallWaitingMaxRep description

– This object contains the default value of the maximum number of repetitions of the call waiting tone that the MTA will play from a single CMS request. The MTA MUST NOT update this object with the information provided in the NCS message (if present). If the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message.


Open Issues

• Revision to pktcNcsEndPntConfigCallAgentId description per PC Sig MIB ECx

– This object contains a string indicating the call agent name (e.g.: [email protected]). The call agent name, after the character '@', MUST be a fully qualified domain name and MUST have a corresponding pktcMtaDevCmsFqdn entry in the pktcMtaDevCmsTable. The object pktcMtaDevCmsFqdn is defined in the PacketCable MIBMTA Specification. For each particular end-point, the MTA MUST use the current value of this object to communicate with the corresponding CMS. The MTA MUST update this object with the value of the 'Notified Entity' parameter of the NCS messages. Because of the high importance of this object to the ability of the MTA to maintain reliable NCS communication with the CMS, it is highly recommended not to change this object’s value through management station during normal operations.

• Revision to pktcNcsEndPntConfigCallAgentUdpPort description per PC Sig MIB ECx

– This object contains the current value of the User Datagram Protocol (UDP) receive port on which the call agent will receive NCS signaling from the endpoint. For each particular end-point, the MTA MUST use the current value of this object to communicate with the corresponding CMS. The MTA MUST update this object with the value of the 'Notified Entity' parameter of the NCS message. If the Notified Entity parameter does not contain a CallAgent port, the MTA MUST update this object with default value of 2727. Because of the high importance of this object to the ability of the MTA to maintain reliable NCS communication with the CMS, it is highly recommended not to change this object’s value through management station during normal operations.


IPCDN WG Next Steps

• Advance all DOCSIS MIBs to IESG & publication

• Waiting for Review and almost ready for publication

– Finished WGLC, waiting for MIB Doctor Review– PacketCable/IPCablecom MTA MIB– PacketCable/IPCablecom Signaling MIB

• Update CableHome MIBs• Revise Charter Milestones

Documents

Page 1 IPCDN Working Group IETF 60 - IPCDN WG Update Richard Woundy Jean-François Mulé IPCDN Co-Chairs Tuesday August 3 rd, 2004 [email protected]