2.4.6 IP over Cable Data Network (ipcdn)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. 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-02-02

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 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 MIB work, 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, PacketCable and CableHome
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 STD.

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.
In its CableHome project, CableLabs has produced one generation
of interface specifications for extending manageability for
customer care to the residential gateway or home router device
connected to the Internet through a DOCSIS-compliant cable modem
(http://www.cablelabs.com/projects/cablehome/).

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.

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.

CableHome 1.0 is a set of specifications for residential
gateway or home router functionality standardizing methods
for implementing address acquisition, device configuration
and management, network address translation, event reporting,
remote connectivity diagnostics, secure software download,
firewall policy file download, firewall monitoring,
management parameter access control and other residential
gateway functionality. By standardizing these features,
CableHome 1.0 specifications enable cable operators to
deliver high-value, managed broadband services to their
high-speed data service subscribers, through a DOCSIS cable
modem.

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,
  -- CableHome
        - publish MIB documents for:
            - managing attributes of a residential gateway or
                home router device,
            - managing private address-to-public address mappings
                for a residential gateway or home router device,
            - managing the address lease acquistion client and the
                address lease server functionality of a residential
                gateway or home router device,
            - managing diagnostic utilities used to remotely test
                the connectivity between a residential gateway and
                privately-addressed LAN hosts,
            - managing firewall attributes, monitoring firewall
                attacks, and managing security certificates in a
                residential gateway or home router device,
            - managing QoS configuration in a residential
                gateway or home router device.

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
Sep 04  Submit updated DOCSIS RF MIB to IESG for consideration as a Standards Track RFC (Proposed Standard)
Sep 04  Submit updated DOCSIS Cable Device MIB to IESG for consideration as a Standards Track RFC
Sep 04  Submit DOCSIS Event Notification MIB to IESG for consideration as a Standards Track RFC
Sep 04  Submit PacketCable/IPCableCom MTA device MIB to IESG for consideration as a Standards Track RFC
Sep 04  Submit PacketCable/IPCableCom MTA signaling MIB to IESG for consideration as a Standards Track RFC
Sep 04  Submit PacketCable/IPCableCom MTA event MIB to IESG for consideration as a Standards Track RFC
Dec 04  Submit Cablehome MIB for managing residential gateway or home router device to IESG for consideration as Standards Track RFC
Dec 04  Submit Cablehome MIB for MIB for managing private address-to-public address mappings for a residential gateway or home router device to IESG for consideration as Standards Track RFC
Dec 04  Submit Cablehome MIB for managing the address lease acquistion client and the address lease server functionality of a residential gateway or home router device to IESG for consideration as Standards Track RFC
Dec 04  Submit Cablehome MIB for managing diagnostic utilities used to remotely test the connectivity between a residential gateway and privately-addressed LAN hosts to IESG for consideration as Standards Track RFC
Dec 04  Submit Cablehome MIB for managing firewall attributes,monitoring firewall attacks, and managing security certificates in a residential gateway or home router device to IESG for consideration as Standards Track RFC
Jan 05  Revaluate charter and milestones or conclude wg

Internet-Drafts:

  • draft-ietf-ipcdn-qos-mib-12.txt
  • draft-ietf-ipcdn-subscriber-mib-16.txt
  • draft-ietf-ipcdn-bpiplus-mib-15.txt
  • draft-ietf-ipcdn-device-mibv2-07.txt
  • draft-ietf-ipcdn-docsisevent-mib-06.txt
  • draft-ietf-ipcdn-docs-rfmibv2-13.txt
  • draft-ietf-ipcdn-pktc-signaling-08.txt
  • draft-ietf-ipcdn-pktc-mtamib-06.txt
  • draft-ietf-ipcdn-pktc-eventmess-04.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

    Current Meeting Report

    C:\Documents and Settings\jfmule\My Documents\Standards\ietf\ipcdn\ipcdn meeting #62\ietf62-ipcdn-minutes_edited.diff.html
    IETF IPCDN Meeting Notes
    IETF#62, IP over Cable Data Networks WG
    Minneapolis, USA
    Tuesday, March 8, 2005
    
    Reported by Greg Nakanishi (gnakanishi@motorola.com)
    Edited by Jean-Francois Mule' (jfm@cablelabs.com)
    
    
    --- WG Meeting Summary
    --- ------------------
    About ten IETF participants attended the IPCDN WG meeting at IETF #62
    in Minneapolis on March 8 2005. Two participants joined the wg meeting
    via the jabber session. Total meeting time was about one hour.
    
    The meeting materials are consolidated into 1 deck of slides and are
    provided as part of the IETF proceedings. They are also posted at
    http://www.ipcdn.org/meetings.html
    
    The slides provided for the meeting contain lots of details on the
    wg status and Internet-Draft issues. The present notes do not
    duplicate the slide content, please read the slides for details.
    The action items (AI) are outlined and called out in the text below.
    
    
    1/ Agenda Bashing
    Greg Nakanishi volunteered to be the note taker.
    A jabber session was also initiated with two participants: Bert
    Wijnen, AD and area advisor for ipcdn and Eduardo Cardona, current
    editor of a couple of Internet-Drafts. The jabber chat room was:
    ipcdn@conference.ietf.jabber.com; Rich Woundy and Jean-Francois Mule
    volunteered to be the jabber scribes during the meeting.
    The proposed agenda was accepted by the wg without modifications, it
    is also available at: http://www.ipcdn.org/meetings.html
    
    
    2/ Administration
    We reviewed the WG Charter & milestones (see slide 4) and
    http://www.ietf.org/html.charters/ipcdn-charter.html
    
    The chairs proposed to update milestone for the DOCSIS Cable Device
    MIB v2 and the PacketCable MIBs to June 2005, that is be "wg done" by
    June 2005 and formerly request publication which will start Ad and
    IESG review.
    Bert commented that June 2005 seems aggressive for completing the CD
    MIB (via jabber). While this may be aggressive given the past pace,
    with Kevin Marez as the new editor and the ad-hoc session with Randy
    Presuhn we were able to organize at IETF to address some of Randy's
    mib doctor comments on the draft, this should still be doable.
    # AI: wg chairs to reflect new milestones when proposing updated IPCDN
    # charter to AD
    
    Bert also added that he hoped to pick up MIB reviews for the event MIB
    and the RFIv2 MIB modules shortly after IETF.
    # AI: wg chairs to follow-up with Bert and MIB co-authors to ensure
    # mib doctors have been assigned to those 2 IPCDN DOCSIS I-Ds
    # AI completed on 4/1/2005.
    
    
    + Concluding the IPCDN CableHome work items
    The chairs (Jean-Francois speaking at the mike) proposed that the WG
    drops the CableHome MIBs from the charter.  There were 6 expired
    Internet-Drafts:
    draft-ietf-ipcdn-cable-gateway-config-mib-00
    draft-ietf-ipcdn-cable-gateway-tools-mib-00
    draft-ietf-ipcdn-cable-gateway-device-mib-00
    draft-ietf-ipcdn-cable-gateway-addressing-mib-00
    draft-ietf-ipcdn-cable-gateway-security-mib-00
    draft-ietf-ipcdn-cable-gateway-qos-mib-00
    
    
    The rationale for concluding all the CH work items was discussed later
    in the meeting and is documented on slide 41 of the meeting materials.
    The AD Bert asked whether the CableHome mib modules had been rooted
    under mib-2 at CableLabs (the answer is no which means from an IETF
    point of view, we do not have the same worries as with some of the
    earlier DOCSIS MIBs.
    => There was no objection from the WG participants in the room.
    => Via jabber, Bert accepted our explanations and agreed to reflect
       the WG decision by modifying the charter.
    # Decision: wg and AD agreement to conclude the IPCDN CableHome work
    # AI: wg chairs to propose new updated IPCDN charter reflecting the
    # change
    
    
    3/ IPCDN DOCSIS mibs
    
    + DOCSIS Cable Device MIB version 2
      draft-ietf-ipcdn-device-mibv2-07.txt
      Editor: Kevin Marez
      http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-07.txt
    We spent much of the meeting time discussing the update of the DOCSIS
    cable device mibv2 and the open issues to advance this Internet-Draft.
    Most of those issues were raised by the mib doctor review from Randy.
    
    Note that the complete enumerated listing of all the draft07
    modifications is available at:
    http://www.ipcdn.org/meetings/cdmib-07-changes.doc
    or http://tools.ietf.org/wg/ipcdn/
    and a diff between draft06 and draft07 is at:
    http://tools.ietf.org/wg/ipcdn/draft-ietf-ipcdn-device-mibv2/draft-ietf-ipcdn-device-mibv2-07-from-06.diff.html
    
    - Open issue #1: MIB compile warning in compliance statement
    Multiple entries in the docsDevGroups are deprecated ex:
    docsDevNmAccessGroup, docsDevSoftwareGroup, etc. The MIB compiler
    complains with warning messages about compliance statements that
    referred to deprecated objects.
    Rich indicated he thought the inclusion of deprecated groups was not
    proper practice, but that it was not prohibited per se. Rich added
    that in the mib review guidelines, page 31, it says something about
    it.
    From page 31:
    | - The status of a compliance statement is independent of the status
    |   of its members.  Thus, a current compliance statement MAY refer to
    |   deprecated object groups or notification groups.  This may be
    |   desirable in certain cases, e.g., a set of widely-deployed object
    |   or notification groups may be deprecated when they are replaced by
    |   a more up-to-date set of definitions, but compliance statements
    |   that refer to them may remain current in order to encourage
    |   continued implementation of the deprecated groups.
    
    Bert commented that this practice is not allowed.
    # AI: Kevin Marez to look into this issue further and propose a new
    # compliance statement addressing the issue.
    
    - Open issue #2
    The docsDevEvReporting object description doesn’t mesh well with the
    RFC3413 guidelines. This was reported by Randy.
    RFC3413 and RFC3014 overlaps with some logging objects in the CD MIB.
    During the meeting, Kevin proposed that a clarification can be made in
    the CD MIB that indicates that the CD MIB object only be applicable
    when running in SNMPv1/2 mode and that RFC3413 be applicable when
    running in Coexistence mode. Eduardo commented via jabber that that
    proposal may not work.
    # AI: Kevin to post pb statement and resolution to the list
    # done on 3/11
    Kevin also met with Randy after the IPCDN meeting and actually
    proposed the following in an email sent on March 11 to the ipcdn
    list:
    Kevin wrote:
    >My proposal would be to add another enumerated type (bit) for
    >stdInterface(9) which would indicate the usage of RFC3413/RFC3014
    >mechanisms for notifications.  There should be no problems with
    >concurrent usage/support of both mechanisms so it would be possible
    >to perform notifications in both places.  Or, do we want to consider
    >this being an xor situation?  It would be necessary to exclude
    >syslog(2) in this case, since neither RFC3413 nor RFC3014 covers this
    >functionality.  Essentially, (stdInterface && syslog) XOR (local &&
    >traps && localVolatile).
    
    - Open Issue #3
    The relationship between docsDevEventGroup, docsDevEventGroupv2 and
    RFC3014 needs to be defined. There was no real discussion on this item
    during the ipcdn meeting.
    # AI: Kevin to address this issue on the list together with issue #3.
    
    
    - Open Issue #4:
    What is the purpose of the docsDevFilterPolicyObsoleteGroup group?
    # Decision: since the objects have been obsoleted, we agreed to remove
    # the group entirely. If anyone objects to Kevin's recommendation,
    # please send your comments to the list.
    
    
    + RF MIB v2
      draft-ietf-ipcdn-docs-rfmibv2-13.txt
      Editor: Eduardo Cardona
      http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt
    We went through the slides which document the updates in draft 13. A
    number of issues need to be resolved to release what will hopefully be
    the last draft (see slide 18-21).
    Rich asked if anyone had questions or comments on the changes made to
    the draft: nobody had any comments.
    # AI: Eduardo to close the issues by proposing resolutions to the list
    # and release draft14 before June.
    
    
    + DOCSIS Event Notification MIB
      draft-ietf-ipcdn-docsisevent-mib-06.txt
      Editor: Greg Nakanishi
      http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-06.txt
    
    Greg commented that all AD comments were incorporated in draft06.
    Bert should provide an additional review shortly after IETF#62.  Bert
    asked the chairs to remind him.
    # AI: Bert to do a final check on draft 06 of the ipcdn docsis event mib
    # AI: chairs to remind Bert (done on 4/1/2005).
    
    4/ IPCDN IPCablecom/PacketCable MIB Updates
    
    + PacketCable/IPCablecom MTA MIB
      draft-ietf-ipcdn-pktc-mtamib-06.txt
      http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt
    
    The current status on MTA MIB draft 06 was presented by Jean-Francois.
    A number of comments were made by Bert on draft06 (see slide 31). The
    next step is to update the draft.
    # AI: MTA MIB authors to update the draft by the end of May and
    # release draft07.
    
    
    + PacketCable/IPCablecom Signaling MIB
      draft-ietf-ipcdn-pktc-signaling-08.txt
      http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.txt
    
    Sumanth is taking over editorship from Gordon Beacham (many thanks to
    Gordon for leading the 7 revisions of the draft to date).
    List of changes in draft07:
     http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01594.html
    
    Rich asked about the txGain and rxGain objects.  His understanding is
    that most vendors implement equivalent objects in private MIBs.  He is
    not concerned that these parameters cannot be set dynamically.  It is
    OK to configure them at device startup.  Some operators had to reduce
    the gain to reduce/prevent echo on the line.
    Note that a patent disclosure was brought to the attention of the WG
    by Jean-Francois Mule, ipcdn co-chair
     http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01593.html.
    
    There are no pending issues on this draft.
    # Decision: it was agreed by Bert and the chairs to issue a new WG
    # Last Call as the next step.
    
    + PacketCable/IPCablecom Management Event MIB
      draft-ietf-ipcdn-pktc-eventmess-04.txt
      http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.txt
    
    Sumanth also took over the editorship of this draft. The MIB is not
    widely implemented or tested at CableLabs to date (as it is not a core
    requirement for PacketCable 1.0). The MIB functionality will become
    mandatory for PacketCable 1.5 so Jean-Francois expressed interest in
    advancing this MIB module to WG last call ASAP.s
    
    Rich asks if this is the version of the MIB that gets rid of the
    distinction between fixed and programmable events. Answer is yes.
    
    Bert commented that if this MIB is being implemented it (under the
    CableLabs root while awaiting ipcdn RFC), it is better to get some MIB
    doctor review ASAP.
    
    # AI: chairs to send a note to request review from Randy and/or Bert
    
    5/ CableHome MIB modules
    The chairs would like to discuss the withdrawal of all the CableHome
    MIB Ids from our IETF IPCDN charter with the wg participants. We will
    then consider make this proposal to the ADs.
    
    There have been no updates to the IETF Internet-Drafts since June 2003.
    Bert asked if there is no activity in both IETF and CableLabs.
    Jean-Francois indicated that there has been some changes within the
    CableLabs MIBs. After consulting with some vendors participant in IETF
    and the internal CableLabs CableHome team in February 2005 (before
    IETF#62), there is not enough vendor or CableLabs support to
    advance those MIBs in IETF: we cannot find any committed resources to
    do this.
    see slide 41.
    Burt asks if the CableLabs CableHome MIBs were rooted under MIBII.
    The answer is 'no', there are under the CableLabs enterprise OID.
    Bert stated that if that is the case, we don't have to worry about it
    as much as we did for the DOCSIS mibs (from an IETF point of view).
    Rich Woundy and Greg N agree that the best path forward is to remove
    them from the charter. Bert accepted the chair proposal and is ok with
    charter update to remove them.
    
    As indicated in section 2/ of these notes:
    # Decision: wg and AD agreement to conclude the IPCDN CableHome work
    # AI: wg chairs to propose new updated IPCDN charter reflecting the
    # change
    
    
    6/ IPCDN WG next steps
    Beyond the action items noted above and implementation of the various
    decisions the wg agreed to, the following is our work plan:
     - Finish all DOCSIS MIBs by June 2004
     - Request publication for
       PacketCable/IPCablecom MTA MIB
       PacketCable/IPCablecom Signaling MIB
     - Advance expert + mib doctor reviews for Management Event MIB for
       MTAs
     - Revise IPCDN Charter Milestones
    
    >.end of the IETF#62 ipcdn meeting notes
    
    

    Slides

    Agenda