2.3.5 IP over Cable Data Network (ipcdn)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.ipcdn.org/ -- Additional IPCDN Web Page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-03

Richard Woundy <Richard_Woundy@cable.comcast.com>
Jean-Francois Mule <jf.mule@cablelabs.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: ipcdn@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
Description of Working Group:
The IETF IPCDN Working Group develops and standardizes SNMP MIBs for IP-capable data-over-cable systems, for example cable modems and associated cable-data equipment in a Headend. These MIBs cover not only cable data interfaces, but also management of cable-data equipment and systems.

The WG is also a forum for discussion of 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 work is identified, such items MAY be added that to the WG's charter, subject to normal IETF processes. Standardisation of MIBs for the EuroModem cable modem is within the scope of the IPCDN Working Group. Harmonisation of EuroModem MIBs and DOCSIS MIBs is desirable and will be examined by the IPCDN WG.

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

Related groups:

The IEEE 802.14 WG was chartered to specify the physical layer and data link layer protocols for the CATV Data Network. The IEEE has discontinued the IEEE 802.14 effort, so that group no longer exists.

DOCSIS has completed its 1.0 versions of Data over Cable standards and is in the process of refining these standards to add additional functionality and to repair any flaws discovered in operational use. The IPCDN WG will update the documents produced which track the 1.0 versions accordingly. These include the RF Interface MIB and the Cable Device MIB. In addition, the operational and management issues of multicast over a Cable Data Network will be addressed.

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.

- a MIB for managing the Telephone Modem Return Path (Telco Return) for 1-way cable modems. (draft-ietf-ipcdn-tri-mib-01.txt)

- a MIB for managing the Baseline Privacy system for DOCSIS. (draft-ietf-ipcdn-bpi-mib-01.txt), (draft-ietf-ipcdn-bpiplus-mib-00.txt)

- a MIB for managing the Quality of Service parameters for a Cable Data Network. (draft-ietf-ipcdn-qos-mib-02.txt)

- a MIB for managing Multicast (IGMP) over a Cable Data Network. (draft-ietf-ipcdn-igmp-mib-00.txt)

- a MIB for CMTS based customer management (draft-ietf-ipcdn-subscriber-mib-00.txt)

- Revisions to the Proposed Standard RF and CM MIBs to address SNMPv3 and IPv6 compliance and interoperability issues.

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
FEB 00  Submit updated RF and CM MIBs to IESG with implementation statement for advancement to Draft Standard
JUN 00  Revaluate charter and milestones.
  • - draft-ietf-ipcdn-qos-mib-08.txt
  • - draft-ietf-ipcdn-igmp-mib-04.txt
  • - draft-ietf-ipcdn-subscriber-mib-10.txt
  • - draft-ietf-ipcdn-bpiplus-mib-08.txt
  • - draft-ietf-ipcdn-device-mibv2-05.txt
  • - draft-ietf-ipcdn-docsisevent-mib-02.txt
  • - draft-ietf-ipcdn-docs-rfmibv2-06.txt
  • - draft-ietf-ipcdn-pktc-signaling-00.txt
  • - draft-ietf-ipcdn-pktc-mtamib-00.txt
  • - draft-ietf-ipcdn-pktc-eventmess-01.txt
  • Request For Comments:
    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

    Current Meeting Report

    Vienna.IETF IPCDN 
    MeetingSan Francisco, CA 
    USAMarch 19, 
    Reported by Greg Nakanishi 
    (gnakanishi@motorola.com)Edited by Rich Woundy 
    WG Meeting 
    Approximately twelve attendees of the IP over Cable Data Networks WG met at 
    the San Francisco IETF on March 19, 2003. The WG discussed the status of its 
    work items: five drafts for DOCSIS MIBs, three drafts for 
    PacketCable/IPCablecom, and six drafts for CableHome. The results of the 
    February 2003 interim meeting in Louisville, CO were also discussed.  
    Total meeting time was a little more than one 
    The "DOCSIS Subscriber Management MIB" completed MIB doctor review, 
    although the use of DSCP value and mask objects needs to be resolved.  The 
    "Application of the IGMP MIB to DOCSIS 1.1" needs to be rewritten with a MIB 
    compliance statement; this draft will be brought back to the WG. 
    Twenty-two submissions for thirteen distinct internet-drafts have been 
    posted since the previous IETF meeting in Atlanta. The WG also launched a 
    website for additional information, 
    This was the first time the WG used jabber text conferencing during its 
    meeting. There were two remote jabber participants (not counted in the 
    twelve participants above), and a third jabber participant joined after the 
    Rich Woundy reviewed the discussion from the February interim meeting.  At 
    the interim meeting, eighteen attendees reviewed IPCDN MIBs for about six 
    hours. The BPI+ MIB and DOCSIS QoS MIB were reviewed in depth, four more 
    DOCSIS MIBs were briefly reviewed, the DOCSIS Set-Top Gateway MIB was 
    briefly discussed, and the CableHome MIBs were presented. The minutes have 
    been posted to the IETF and www.ipcdn.org 
    Review of DOCSIS 
    Rich Woundy presented a list of the most current versions of the DOCSIS 
    MIBs. Greg Nakanishi asked for the timeframe(s) to have all of the draft 
    updates as a result of the interim meeting. Jean-Francois Mule 
    responded that the timeframe depended on the 
    There were a number of technical comments on the BPI+ MIB draft -08 at the 
    interim meeting. The BPI+ MIB draft -09 is work-in-progress at the 
    moment. The goal is to post the next draft with all comments resolved 
    prior to 
    The Cable Device MIB draft -04 was briefly discussed at the interim 
    meeting, which resulted in the posting of draft -05. The latest draft has 
    significant revisions to the compliance statements (separated for CM and 
    CMTS), has new filtering tables for IPv4/IPv6 filtering, Dscp marking, and 
    IPv4/IPv6 CPE control, and has deleted all VACM extension objects. This 
    draft requires careful WG 
    At this point, Rich raised the debate about the use of the DiffServ MIB and 
    its applicability to Cable Device IPv4/IPv6 filtering, and to the packet 
    classification tables in the DOCSIS QoS and Subscriber Management MIBs. 
    Rich found the DiffServ MIB to have powerful features for packet 
    classification, queuing and scheduling, although for adoption into cable 
    might require simplications via MIB compliance statements. One 
    difficulty in adopting the DiffServ MIB is that its Data Path table 
    differentiates between interfaces but not between groups of devices (e.g. 
    cable modems) on a single interface -- unlike the Subscriber 
    Management MIB. An additional issue may be the potential "partial" use of 
    the DiffServ MIB for cable interfaces, but the "complete" use of the 
    DiffServ MIB for other interfaces on a 
    The Event Notification MIB draft -03 was briefly discussed at the 
    interim meeting. A timeframe for publication of draft -04 needs to be 
    determined, and the draft requires careful WG 
    The DOCSIS 2.0 RFI MIB draft -05 was briefly discussed at the interim 
    meeting, which resulted in the posting of draft -06. The name of the MIB 
    module needs to be changed from DOCS-IETF-RFI-MIB back to 
    DOCS-IF-MIB (the slide incorrectly indicated it should be changed to 
    DOCS-RFI-MIB); both this draft and the cable device MIB draft need to 
    retain the module names of RFC 2670 and RFC 2669, respectively.  This 
    draft requires careful WG 
    Minnie Lu raised an issue about the RFI MIB objects 
    docsIfCmtsServiceInPackets and 
    docsIfCmtsServiceInOctets, asking why they do not include packets from 
    DOCSIS 1.1 or 2.0 modems after registration -- according to the DOCSIS QoS 
    MIB. This issue will be (re-)raised and discussed on the mailing 
    The DOCSIS QoS MIB draft -07 was discussed in-depth at the interim 
    meeting, which resulted in the posting of draft -08. One remaining issue is 
    the MIB's use of IP ToS instead of DSCP. Rich's opinion was that the MIB 
    should reflect what is in the DOCSIS specifications, and in the case of 
    packet classification for DOCSIS QoS, DOCSIS clearly uses the older 
    notion of the IP ToS 
    The DOCSIS Subscriber Management MIB draft -08 was briefly discussed at the 
    interim meeting, where Bert Wijnen indicated his MIB doctor approval. 
    However, two draft revisions were made after the interim meeting to 
    resolve issues raised in different MIB reviews. Draft -09 changed the 
    module name from DOCS-SUBMGT-MIB to DOCS-IETF-SUBMGT-MIB, to reduce 
    potential confusion between the CableLabs and IETF versions.  Draft -10 
    replaced the TosValue and TosMask objects with DscpValue and DscpMask 
    objects. The current controversy is whether to keep the DscpMask object, 
    over the objections of the IETF DiffServ WG, or just drop this new 
    Rich led a discussion comparing the progress of the DiffServ WG in 
    parallel with the development of DOCSIS 1.1 and the IPCDN WG. DSCP is 
    replacing IP ToS in the Cable Device and Subscriber Management MIBs; the 
    DOCSIS QoS MIB is retaining the concept of the IP ToS byte. In the 
    meantime, folks in CableLabs are looking at how the DOCSIS protocols and 
    specifications can be made 
    Greg Nakanishi asked which operators are using DiffServ today. Cox 
    appears to be a key cable operator using DiffServ. Someone in the 
    meeting asked what happens if the DscpMask object is dropped, and what are 
    the impacts to the underlying DOCSIS layer two protocols. Rich replied that 
    the WG co-chairs are going back to the operators to understand how they 
    have been using DiffServ, and whether dropping the DscpMask object would 
    cause operational 
    Review of PacketCable/IPCablecom 
    Jean-Francois Mule reviewed the progress on the 
    PacketCable/IPCablecom MIBs. Jean-Francois pointed out that he and Rich are 
    seeing the same mistakes and issues in multiple MIBs under review of the 
    IPCDN WG. The chairs may start asking for peer reviews on draft MIBs 
    within our WG; that is, authors may be requested to review other 
    There were a number of technical and editorial comments reviewed for the 
    PacketCable/IPCablecom MTA MIB, based on email sent to the mailing list. One 
    issue is the use of a "TFTP URL" for downloading an MTA 
    configuration file -- the IETF draft defining the TFTP URI scheme has been 
    queued for AD approval for almost a year, presumably due to the lack of 
    adequate security in the TFTP protocol. One participant suggested that we 
    don't expose the fact that we are using TFTP for configuration file 
    downloads, to avoid the IETF controversy about using 
    Similarly, the WG reviewed comments for the 
    PacketCable/IPCablecom Signaling MIB, based on another email sent to the 
    mailing list. One issue is that AVT profiles are defined in RFC 1890 (and 
    the recent internet-draft update 
    draft-ietf-avt-profile-new-13.txt), but this MIB  uses its own naming 
    convention. Another issue is the residual references to the DCS 
    protocol (SIP-based), even though PacketCable/IPCablecom uses the NCS 
    protocol (MGCP-based). A third issue is a needed clarification as to when 
    the MTA performs DNS resolution, e.g. at boot-time, or upon receipt of an 
    RSIP (ReStartInProgress) NCS message. This third issue prompted a number of 
    questions and comments on DNS responses. Rich pointed out that some CMS 
    vendors might support server cluster failover by returning multiple IP 
    addresses in a single DNS "A" resource record; the presence of an IP 
    address in the "A" record might imply that the CMS believes that the 
    server with that IP address is alive, and the ordering of IP addresses in 
    the "A" record might indicate relative server processing load 
    (lighter-loaded servers are listed before heavier -loaded 
    [Editor's note: The original slides included the following comment on the 
    Signaling MIB: "Use InetAddress dns type for 
    pktcNcsEndPntConfigCallAgentId". This comment was removed, because the 
    CallAgentId as defined by NCS/MGCP includes more than the DNS FQDN, e.g. 
    Finally, the WG reviewed comments for the 
    PacketCable/IPCablecom Management Event MIB. The InetAddress objects in 
    this MIB must link to the appropriate InetAddressType objects (the slides 
    incorrectly indicated the opposite linkage, from InetAddressType objects to 
    InetAddress objects). Another issue is the lack of alignment of logging 
    severity levels between the Management Event MIB and the SYSLOG MIB. The 
    consensus of the meeting attendees is to align 
    PacketCable/IPCablecom event logging severity levels with 
    DOCSIS/CableHome event logging severity levels, which are already 
    aligned with the SYSLOG MIB. Azlina volunteered to review the 
    Management Event MIB; other volunteers are sought to ensure quality MIB 
    reviews in the 
    Greg Nakanishi asked whether all PacketCable/IPCablecom MIB names should be 
    changed using the same naming convention adopted for the DOCSIS MIBs, to 
    prevent confusion between CableLabs and IETF versions. The attendees and 
    co-chairs agreed with this proposal. This implies the following MIB 
    module name changes: PKTC-IETF-MTA-MIB for the MTA MIB, 
    PKTC-IETF-SIG-MIB for the Signaling MIB, and 
    PKTC-IETF-EVENT-MIB for the Event Management 
    The expectation is that the PacketCable/IPCablecom MIBs will be revised in 
    the next month or so after the San Francisco IETF meeting (target of 
    mid-April). The co-chairs will want to issue WG last-calls as soon as the 
    MIBs are updated and ready for 
    Review of CableHome 
    New co-authors have signed up to edit and review the CableHome MIBs.  The 
    authors represent CableLabs, YAS corporation, and four CableHome vendors 
    (Ashley Laurent, Linksys, Motorola, and TI). As a result, the WG 
    co-chairs believe that the IPCDN WG should accept the CableHome MIBs as 
    part of the IPCDN 
    There is some overlap between the DHCPv4 Server MIB and the CableHome 
    Gateway Configuration MIB. The DHCPv4 Server MIB has been recently 
    revised, and as soon as it reaches WG last call in the DHC WG, the 
    appropriate CableHome authors will need to resolve the 
    No objections to accepting the CableHome MIBs were received from the IPCDN 
    mailing list, nor from the IETF meeting participants. The co-chairs will add 
    them to the WG 
    There was an expectation that the IPCDN WG would discuss the DOCSIS 
    Set-Top Gateway (DSG) MIB at the San Francisco IETF meeting. This agenda 
    item was cancelled due to lack of preparation by interested parties.  By 
    default, the WG is deferring any decision about whether to accept this MIB as 
    one of its work 
    The chairs reminded the IPCDN authors that they are insisting on more 
    frequent draft updates than in the past. They are also requesting that 
    participants review the MIBs of this WG -- in addition to a new request for 
    MIB authors to participate in peer reviews of each others' 
    Greg White (jabber participant) requested a timeline for getting the 
    DOCSIS MIBs from internet-draft status to RFC, for coordination with 
    CableLabs standardization 


    Interim IPCDN Meeting - Denver 2/13
    Interim Meeting Agenda
    Interim Meeting DOCSIS BPI + MIB 08
    Interim Meeting DOCS-QOS-MIB
    Interim Meeting DOCSIS Subscriber Management
    Interim Meeting DOCSIS Cable Device MIB Update
    Interim Meeting DOCSIS Notification MIB Update
    Interim Meeting CableHome MIB Status