2.4.7 IP over Cable Data Network (ipcdn)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-06-27

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-bpiplus-mib-15.txt
  • draft-ietf-ipcdn-device-mibv2-09.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
    RFC4036 Standard Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management

    Current Meeting Report


    IETF IPCDN Meeting Notes
    IETF#63, IP over Cable Data Networks WG
    Paris, France
    Monday, August 1, 2005

    Reported and edited by Jean-Francois Mule' (jfm@cablelabs.com)

    --- WG Meeting Summary
    --- ------------------
    About ten IETF participants attended the IPCDN WG meeting at IETF #63 in Paris on August 1st 2005. Total meeting time was one hour.

    There were no meeting materials prepared for this meeting as the goal was to use the time as a working session to resolve known issues on the main active drafts. The meeting essentially focused on the cable device MIB v2 and the top 4 remaining issues.

    The action items (AI) are outlined and called out in the text below.

    1/ Agenda Bashing
    A jabber session was also initiated and Rich Woundy, ipcdn co-chair participated remotely. The jabber chat room is: ipcdn@conference.ietf.jabber.com.
    The proposed agenda was accepted by the wg without modifications, it is also available at: http://www.ipcdn.org/meetings.html and as part of the IETF proceedings.

    2/ Administration
    We briefly discussed the re-chartering & milestone updates. Below is the newly proposed date corresponding to the "wg done" milestone.
     o DOCSIS Cable Device MIB version 2: Oct 2005
     o RF MIB v2:                         Oct 2005
     o MTA MIB:                           Oct 2005
     o Signaling MIB:                     Oct 2005
     o Management Event MIB:              Dec 2005
    
    It was commented that those dates look aggressive for some of the work items so co-authors should review the above.

    # Action Item (AI):
    # Upon review of notes by wg, if there is no comments on the above
    # milestones, Jean-Francois to send updated charter proposal to Bert
    # for approval.
    # Due by end of August 2005


    3/ IPCDN DOCSIS mibs

    3.1/ DOCSIS Cable Device MIB version 2
    draft-ietf-ipcdn-device-mibv2-09.txt
    Editors: Kevin Marez & Rich Woundy
    http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt

    We spent most of the meeting reviewing the 4 top remaining issues, see summary sent by Rich and Kevin in: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html

    + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces
    Raised by Randy, the issue is, in the defval we have a 4 octet value => How can systems with interfaces in a number not multiple of 8 interpret the DEFVAL value. Are bits ignored?

    Randy commented that he would be ok if there was some mention like 'octets containing bits corresponding to non-existent interfaces are ignored.' That said, if there are implementations that would reject a SET, then we need to say something about that.

    Rich commented that the DEFVAL was added due to prior MIB doctor comment and that the object is now deprecated. Bert asked whether there was any concern deleting the DEFVAL.

    Proposal for wg review:
    1. in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h }
    2. consider the following (NICE TO HAVE kind of fix) adding a sentence to say something like: bits set corresponding to non-existing interfaces is implementation specific (to warn the mgmt admin/apps that no assumptions should be made on existing implementations of this object. (Randy's suggestion)
    + ISSUE #2: docsDevNmAccessStatus
    -- Also, we should change the DESCRIPTION of docsDevCpeStatus
    -- and docsDevCpeInetRowStatus to document how the agent adds rows.

    See issue raised by Randy and the email summary provided by Rich for the context around this issue #2.

    We had some discussions around the persistency of those tables, the fact that the CM config file drives the row creation at boot-up and the fact that they are read-create tables so admins can also create entries as Bert pointed out.

    In most cases (except for docsDevEvControlTable), entries do not persist across CM reboots. Even in the case of docsDevEvControlTable, after some discussion, we believe that the entries are cleared and "recreated" after the CM reads the config file. That is the common understanding.

    Bert said: add a statement ("this is a deprecated table, this is vendor specific as to what vendors do with this table, mgmt app cannot expect a certain behavior").

    + ISSUE #3: docsDevEvReporting and local(0) rows
    Comment close: ID authors agree with Randy's comment re: local(0) rows MUST persist. Text will be revised.
    in docsDevFilterLLCTable:
    Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated.

    Proposal:
    DELETE above text if nobody complains after reading the meeting notes

    + ISSUE #4: docsDevFilterLLCTable
    Issue is around text for the level of requirements on table persistence. Agree with Rich's text proposal:
    |"Table entries MUST NOT persist across reboots for cable modems."
    Rich also proposed to apply this requirement to:
    NmAccess, FilterLLC, FilterIp, Policy, Tos, Cpe and InetCpe tables.

    It was suggested to use SHOULD NOT rather than MUST NOT but other than that, proposal is ok.

    + Other items on CD Device MIB:
    Randy added for consideration:
    wherever we have this "must not persist" langage in table definitions, it would be a plus to indicate that they may come back as entries may reappear when CM reboots and comes up with config file. Or consider adding this in the front paper as a consideration for users of the MIBs if that is too many little edits in the MIB objects.

    Proposal:
    add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading.

    A comment was made that in general, we should indicate the persistency model in each object rather than in the compliance section.

    Bert also commented on the compliance sections: if different requirements apply to CM and CMTS, suggestion is to make 2 different compliances. Rich added that the new compliance statement is designed like that.

    # AI: [authors: Kevin Marez & Rich Woundy]
    # Authors to summarize list of agreed changed and the technical
    # changes in the text per wg consensus and issue new draft after AD
    # review comments are in.
    # Due by early September?

    # AD review by Bert due by August 15

    3.2/ 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
    Not discussed due to time limit.
    # AD review by Bert due by August 15

    3.3/ IPCablecom/PacketCable MTA MIB
    draft-ietf-ipcdn-pktc-mtamib-06.txt
    http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt
    Not discussed due to time limit.
    # AD review by Bert due by August 15

    3.4/ Signaling MIB
    draft-ietf-ipcdn-pktc-signaling-08.txt
    http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.txt
    Not discussed due to time limit.

    # AI: authors to close one open issue on tone table by August 20.
    # Ask Randy to review final proposal.

    3.5/ Management Event MIB
    draft-ietf-ipcdn-pktc-eventmess-04.txt
    Not discussed due to time limit.
    # AI: chair (Jean-Francois) to ping authors to understand the status
    # of the document and define next steps accordingly.
    http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.txt


    4/ 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 September 2005
    • Update

    • PacketCable/IPCablecom MTA MIB
      PacketCable/IPCablecom Signaling MIB and request publication by October 2005
    • Advance expert + mib doctor reviews for Management Event MIB for MTAs
    >.end of the IETF#63 ipcdn meeting notes

    Slides

    Agenda