2.4.7 IP over Cable Data Network (ipcdn)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional IPCDN Web Page

Last Modified: 2005-10-03

Chair(s):

Richard Woundy <Richard_Woundy@cable.comcast.com>
Jean-Francois Mule <jf.mule@cablelabs.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion: ipcdn@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
Archive: http://www.ietf.org/mail-archive/web/ipcdn/index.html

Description of Working Group:

The IETF IPCDN Working Group develops and standardizes MIBs
for IP-capable data-over-cable systems, for example cable
modems, multimedia terminal adapters and associated
cable-data equipment in a cable headend.
These MIBs cover not only cable data interfaces, but also
management of cable-data equipment and systems.

The WG mailing list may be used to discuss Internet-related
issues in data-over-cable equipment and systems. In the event
of a particular new Internet technology issue arising in the
cable-data context, the WG will identify whether that is best
handled within the IETF or is best handled by another standards
body. In the event that new IETF MIB work is requested, the WG
chairs can discuss additional WG work items with the AD. Such
additions will have to go through normal re-charter process.
If non-MIB work gets identified, such items are not normal
work items for this IPCDN-MIB WG and must go through normal
IETF new WG chartering process.

Standardization of MIBs for DOCSIS and PacketCable systems are
explicitly within the scope of the IPCDN Working Group.

The IPCDN WG will also keep informed on what other groups in
the industry are doing as it relates to the efforts of this
working group.

The WG will align its specifications with IPv6 and SNMP Standards.

Related groups:

CableLabs (http://www.cablelabs.com/) is structured into projects.
In its Cable Modem DOCSIS project, CableLabs has produced three
generations of data over cable specifications: DOCSIS 1.0,
DOCSIS 1.1, and DOCSIS 2.0.
In its PacketCable project, CableLabs has produced one generation
of interface specifications for delivering real-time multimedia
services over DOCSIS (http://www.packetcable.com/specifications/).
Internationally, IPCablecom is the global name associated
with the extensions & global standardization of PacketCable
in ETSI & ITU-T SG9.

DOCSIS 1.0 includes specifications for a bidirectional
data-over-cable interface (RFI, or Radio Frequency Interface)
and a data privacy service (BPI, or Baseline Privacy Interface).
The key devices in a DOCSIS network are the Cable Modem (CM, the
device at the subscriber premise) and the Cable Modem Termination
System (CMTS, the device at the cable headend). For DOCSIS 1.0
systems, the IPCDN WG has published the Cable Device MIB
(RFC 2669), the RF Interface MIB (RFC 2670), and the Baseline
Privacy MIB (RFC 3083).

DOCSIS 1.1 extends the DOCSIS 1.0 specifications to support
better quality of service parameters (RFIv1.1), to enable
operation in European cable networks (EuroDOCSIS), and to
authenticate modems and firmware images (BPI+). The IPCDN WG
will update the Cable Device and Radio Frequency MIBs for
DOCSIS 1.1, and repair flaws discovered in operational use.
Other IPCDN WG documents will address the operational and
management issues for new DOCSIS 1.1 functional components
(e.g. BPI+), for subscriber device management, and for
uniform event notification. The IPCDN WG has also published the DOCSIS
Subscriber Management MIB (RFC4036) for DOCSIS 1.1 and 2.0
systems.

DOCSIS 2.0 enhances the DOCSIS 1.1 specifications at the
physical layer, in particular to support two new physical
layer encodings: S-CDMA and A-TDMA. The IPCDN WG will update
the Radio Frequency MIB for DOCSIS 2.0.

PacketCable 1.0 is built on top of the DOCSIS 1.1 cable modem
infrastructure and it includes a suite of interface
specifications covering multimedia terminal adapter (MTA)
device provisioning, voice over IP session signaling, QoS
signaling based on IETF standards. The key systems in a
PacketCable network are the multimedia terminal adapter (MTA),
a Call Management Server (CMS), a PacketCable-compliant
DOCSIS 1.1 CMTS, Media Gateway Controllers, Media Gateways
along with back-office systems. In ITU-T SG-9 and ETSI AT,
IPCableCom has standardized PacketCable to create a set of
international standards.


Work items:

The IPCDN WG will address issues related to network management,
especially as they concern HFC access networks. It is expected
that other services (i.e. RSVP, IPSEC, etc.) will operate
mostly unmodified.

The specific work items include

-- DOCSIS,
- publish MIB documents for:
- subscriber device management on a DOCSIS 1.1 CMTS,
- managing the quality of service parameters for a
DOCSIS 1.1 device,
- managing the Baseline Privacy Plus system for a
DOCSIS 1.1 device,
- uniform event notification on a DOCSIS 1.1 device,
- revise MIB documents for:
- DOCSIS 1.0 RF Interface MIB to support EuroDOCSIS
parameters and DOCSIS 2.0 physical layer management,
- the DOCSIS 1.0 Cable Device MIBs to address SNMPv3
and IPv6 compliance and interoperability issues,

-- IPCablecom & PacketCable
- publish MIB documents for:
- managing the device parameters of
PacketCable/IPCableCom MTA devices,
- managing the signaling parameters of
PacketCable/IPCableCom MTA devices,
- managing events for PacketCable/IPCablecom systems,

Goals and Milestones:

Done  Post final I-D on Baseline Privacy MIB; Last call
Done  Post I-Ds revising RF and CM MIBs to support DOCSIS1.1 and for compliance with SNMPv3 and IPv6
Done  Submit Baseline Privacy MIB to IESG for publication as a Standards Track RFC
Done  Submit DOCSIS Subscriber Management MIB to IESG for consideration as a Standards Track RFC
Done  Submit DOCSIS 1.1 QoS MIB to IESG for consideration as a Standards Track RFC
Done  Submit DOCSIS BPI+ MIB to IESG for consideration as a Standards Track RFC
Done  Submit DOCSIS Event Notification MIB to IESG for consideration as a Standards Track RFC
Oct 2005  Submit PacketCable/IPCableCom MTA event MIB to IESG for consideration as a Standards Track RFC
Oct 2005  Submit PacketCable/IPCableCom MTA device MIB to IESG for consideration as a Standards Track RFC
Oct 2005  Submit PacketCable/IPCableCom MTA signaling MIB to IESG for consideration as a Standards Track RFC
Oct 2005  Submit updated DOCSIS Cable Device MIB to IESG for consideration as a Standards Track RFC
Oct 2005  Submit updated DOCSIS RF MIB to IESG for consideration as a Standards Track RFC (Proposed Standard)
Jan 2006  Re-evaluate charter and milestones or conclude wg

Internet-Drafts:

  • draft-ietf-ipcdn-qos-mib-12.txt
  • draft-ietf-ipcdn-device-mibv2-10.txt
  • draft-ietf-ipcdn-docsisevent-mib-06.txt
  • draft-ietf-ipcdn-docs-rfmibv2-14.txt
  • draft-ietf-ipcdn-pktc-signaling-09.txt
  • draft-ietf-ipcdn-pktc-mtamib-07.txt
  • draft-ietf-ipcdn-pktc-eventmess-05.txt

    Request For Comments:

    RFCStatusTitle
    RFC2669 PS Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems
    RFC2670 PS Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces
    RFC3083 I Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems
    RFC4036 Standard Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management
    RFC4131 Standard Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus

    Current Meeting Report

    IPCDN Minutes, Vancouver, BC, November 10, 2005

    IETF IPCDN Meeting
    Vancouver, British Columbia
    Thursday November 10, 2005

    Reported by Richard Woundy (richard_woundy@cable.comcast.com)

    WG Meeting Summary and Administration

    The IPCDN WG met to discuss the progress of various MIB documents, especially the outstanding PacketCable/IPCablecom and DOCSIS internet-drafts.

    The DOCSIS BPI+ MIB was published as RFC 4131 in September. The DOCSIS QoS MIB and the DOCSIS Event Notification Management MIB are on the RFC Editor Queue.

    Most of the meeting discussion centered on resolving open issues with the PacketCable/IPCablecom MTA MIB (syntax of Kerberos realm names and realm organization names, and a textual convention for encryption algorithms), and with the PacketCable/IPCablecom Management Event MIB (whether event throttling applies to local logging on the cable modem). The PacketCable/IPCableCom NCS Signaling MIB, DOCSIS Cable Device MIB, and DOCSIS RFIv2 MIB were also discussed, with a focus on the next steps to get to the 'Publication Requested' state for all five internet-drafts.

    There is a strong desire by the WG to conclude all DOCSIS and PacketCable/ IPCablecom MIB drafts by around December 2005 or January 2006.

    There were about ten attendees at the WG session in Vancouver. Total meeting time was one hour.

    PacketCable/IPCableCom MTA MIB

    draft-ietf-ipcdn-pktc-mtamib-07.txt

    Eugene Nechamkin and Jean-Francois Mule produced version 07 of the MTA MIB draft, to address comments from the AD review (Bert Wijnen) and from the IPCDN mailing list. The resolution of these comments were posted on the mailing list. Most comments were resolved with simple editorial fixes. One significant addition is specification of the same encryption algorithms as the BPI+ MIB (RFC 4131, ref: DocsBpkmDataEncryptAlg).

    The WG discussion was centered on the proper MIB object SYNTAX for Kerberos realm names and Kerberos realm organization names.

    With respect to the Kerberos realm organization name (pktcMtaDevRealmOrgName), X.509 and RFC 2459 constrain the length of the organization name to 64 characters. The characters may be encoded as UTF8String, so each character may occupy between one and six octets. Therefore, a single organization name may occupy up to 384 octets. The current MIB object has a SYNTAX of SnmpAdminString(SIZE (1..255)).

    The WG recommends to change the pktcMtaDevRealmOrgName object as follows:

    1. Remove the sentence referring to the "o=" prefix in the DESCRIPTION clause. Do not include the "o=" prefix in the value of this MIB object.
    2. Change the SYNTAX of this object to LongUtf8String, imported from the SYSAPPL-MIB defined in RFC 2287. This enables a maximum size of 1024 octets (for future growth).
    3. Add a compliance statement for this object to limit the maximum size of the object to 384 octets, and include justification, e.g. each UTF-8 character can be up to 6 octets long, and the organization name may contain up to 64 UTF-8 characters.

    Three distinct MIB objects contain a Kerberos realm name: pktcMtaDevProvKerbRealmName, pktcMtaDevRealmName,and pktcMtaDevCmsKerbRealmName. RFC 4120 specifies a syntax of GeneralString for the Kerberos realm name, although the RFC says the realm name may be non-ASCII (UTF8String) in the future. The WG recommendation is to continue to use SnmpAdminString as the SYNTAX for these three MIB objects.

    This draft also has a new textual convention for MTA configuration file encryption algorithms, PktcMtaDevProvEncryptAlg. This textual convention enables future support of triple-DES and AES encryption, similar to the DocsBpkmDataEncryptAlg textual convention in the DOCSIS BPI+ MIB (RFC 4131). It was suggested to compare the PktcMtaDevProvEncryptAlg and DocsBpkmDataEncryptAlg textual conventions, and if they are identical, then have the MTA MIB IMPORT DocsBpkmDataEncryptAlg from the BPI+ MIB.

    Editor's note: the DocsBpkmDataEncryptAlg includes 40-bit and 56-bit DES encryption but not 64-bit DES encryption as in PktcMtaDevProvEncryptAlg. These textual conventions are NOT identical nor compatible.

    The next steps for this internet-draft are:

    1. Bert Wijnen will respond to the author's email and confirm whether or not the draft addresses the AD review comments.
    2. The authors will incorporate the recommended changes to the pktcMtaDevRealmOrgName MIB object in version -08.
    3. The co-chairs will compose a PROTO write-up and request to put the draft into the 'Publication Requested' state.

    PacketCable/IPCableCom NCS Signaling MIB

    draft-ietf-ipcdn-pktc-signaling-09.txt

    Gordon Beacham, Satish Kumar, and Sumanth Channabasappa submitted version 09 of the NCS Signaling MIB draft, to address comments from the MIB doctor and various WG participants. The resolution of these comments were posted on the mailing list.

    Significant updates included changes to a number of MIB objects in the pktcSigDevMultiFreqToneTable, and the removal of the pktcNcsEndPntConfigTxGain and pktcNcsEndPntConfigRxGain objects.

    There were no comments concerning this internet-draft in this meeting.

    The next steps for this internet-draft are:

    1. The WG co-chairs will review this draft.
    2. The co-chairs will compose a PROTO write-up and request to put the draft into the 'Publication Requested' state.

    PacketCable/IPCableCom Management Event MIB

    draft-ietf-ipcdn-pktc-eventmess-05.txt

    Wim De Ketelaere, Eugene Nechamkin, and Sumanth Channabasappa submitted version 05 of the PacketCable/IPCableCom Management Event MIB draft, responding to comments from a review by Greg Nakanishi and additional feedback from Randy Presuhn. The resolutions of these comments were posted on the mailing list.

    There was some discussion in the meeting about whether the event throttling objects (pktcDevEvThrottleAdminStatus, pktcDevEvThrottleThreshold, and pktcDevEvThrottleInterval) apply to local logging of events, or only to network transmissions of events via SNMP or SYSLOG messages. The current throttling MIB objects only refer to SNMP and SYSLOG, but pktcDevEventDescrReporting and pktcDevEvLogType refer to local logging.

    The WG recommends adding the following text to the DESCRIPTION of pktcDevEvThrottleAdminStatus: "The impact of event throttling controls on local logging is an implementation-specific matter."

    Editor's note: The following DESCRIPTION of pktcDevEvLogType suggests that the throttling controls do NOT apply to local logging. If throttling of local logging is implementation-specific, then at least this DESCRIPTION should be revised. Bert Wijnen requests that there be explicit text in the relevant DESCRIPTION clause(s) for what folks (e.g. developers) can expect.

    pktcDevEvLogType OBJECT-TYPE
           SYNTAX      BITS {
                       local(0), 
                       syslog (1), 
                       trap (2), 
                       inform (3) 
                       } 
           MAX-ACCESS  read-only 
           STATUS      current 
           DESCRIPTION 
                   "This MIB Object contains the kind of actions taken by  
                    the MTA when the event under consideration occurred. 
        
                    A bit with a value of 1 indicates the corresponding 
                    action was taken. Setting it to a value of 0 indicates  
                    that the corresponding action was not taken. 
         
                    An event may trigger one or more actions (e.g.: Syslog  
                    and SNMP) or may remain as a local event since  
                    transmissions could be disabled or inhibited as defined  
                    by the Throttle MIB Objects." 
                     
           ::= { pktcDevEventLogEntry 7 }
    

    The next steps for this internet-draft are:

    1. The WG co-chairs will review this draft.
    2. The co-chairs will compose a PROTO write-up and request to put the draft into the 'Publication Requested' state.

    DOCSIS Cable Device MIB (replacing RFC2669)

    draft-ietf-ipcdn-device-mibv2-10.txt

    Kevin Marez and Richard Woundy produced version 10 of the DOCSIS Cable Device MIB draft, to address comments from the AD review (Bert Wijnen) and from the MIB doctor review. The resolution of the AD review comments were posted on the mailing list. Most comments were resolved with simple editorial fixes.

    Two significant changes in version 10 discussed in the meeting were the new narrative text for MIB module IMPORTs and REFERENCE clauses (section 3.1.1), and the new narrative text discussing the persistance model for cable modem MIB objects (section 3.1.2). There were no significant comments on the IMPORT/REFERENCE narrative text, although this is different from the approach taken by other IPCDN internet-drafts. Bert noted that there were no MUST statements in the persistance model narrative, but that was OK since the normative persistance requirements are in the MIB object definitions.

    The next step for this internet-draft is for the IPCDN co-chairs (in this particular case, Jean-Francois Mule) to compose a PROTO write-up and to request to put the draft into the 'Publication Requested' state.

    DOCSIS RFIv2 MIB (replacing RFC2670)

    draft-ietf-ipcdn-docs-rfmibv2-14.txt

    Eduardo Cardona produced version 14 of the DOCSIS RFIv2 MIB, in response to comments from the AD review (Bert Wijnen).

    There were no comments concerning this internet-draft in this meeting.

    The next steps for this internet-draft are:

    1. The WG co-chairs will review this draft.
    2. The co-chairs will compose a PROTO write-up and request to put the draft into the 'Publication Requested' state.

    IPCDN Next Steps

    The co-chairs will review plans for promoting, finalizing, and reviewing current IPCDN MIBs, with a focus on the DOCSIS and PacketCable/IPCableCom MIB internet-drafts.

    Co-chairs:

    Richard Woundy <Richard_Woundy@cable.comcast.com>
    Jean-Francois Mule' <jf.mule@cablelabs.com>

    Slides

    Agenda