Current Meeting Report
2.3.4 IP over Cable Data Network (ipcdn)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 06/24/2002
Aviv Goren <email@example.com>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Erik Nordmark <email@example.com>
Internet Area Advisor:
Thomas Narten <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: http://www.ietf.org/mailman/listinfo/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.
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.
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
- 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.
- 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.
- a MIB for CMTS based customer management
- 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 |
|FEB 00|| ||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. |
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
IETF IPCDN Meeting
July 15, 2002
Reported by Ted Lemon (Ted.Lemon@nominum.com)
Edited by Rich Woundy (firstname.lastname@example.org)
WG Meeting Summary
Approximately 30 members of the IP over Cable Data Networks WG met at the Yokohama IETF on July 15, 2002. The WG discussed the status of its work items, the four individual internet-draft submissions for PacketCable/IPCablecom (to support voice over IP over cable), and the ongoing charter revision. In addition to the four PacketCable/IPCablecom submissions, the WG has submitted three updates to existing internet-drafts since the last IETF meeting. Total meeting time was a little more than one hour.
Two WG drafts were submitted to the IESG for approval: "Application of the IGMP MIB to DOCSIS 1.1", and "DOCSIS Subscriber Management MIB". Other WG drafts require some fixes to address minor concerns raised in last-call before submission to the IESG.
WG Status and Charter Revision
Jean-Francois Mule from CableLabs is joining Rich Woundy as WG co-chair. This was confirmed by Thomas Narten during the WG meeting.
Thanks to coordination by Matt Osman, four new individual contributions related to PacketCable/IPCablecom technology have been submitted to the WG (see slides). Some of the draft authors are associated with CableLabs, some with ITU/ETSI. This is the first time this WG has seen cooperation on MIB drafts between North American and European cable technical bodies.
The WG needs to work on revised timelines and milestones for the WG charter. The WG faces a vortex of expired drafts; updates from authors need to start happening really soon. Richard Woundy may be resubmitting the DVB/Euromodem MIB drafts as historic or experimental, since all the authors are gone.
The WG needs tighter coordination with Cablelabs, particularly with the timing of CableLabs vendor product certification waves and RFC publication. The next CableLabs certification wave after this WG meeting is "Certification Wave 24" (CW24), which may result in the first certifications of PacketCable devices. It gets really difficult to modify the behavior of certified vendor devices (e.g. changing the MIB object implementations within the devices) after the cable operators have purchased and deployed millions of such devices, and built operational support systems around the original behavior. The WG needs to explore if we can do anything about this.
Matt Osman presented slides on the history, motivations, and high-level structures of the PacketCable MIBs. Matt was the key person who coordinated the efforts of many authors of the individual contributions.
The primary focus of the PacketCable/IPCablecom project is to enable voice services over cable networks, to copy most of the PSTN functionality into the cable network environment. PacketCable/IPCablecom will expand to support other multimedia services that require QoS over cable networks.
When CableLabs initiated the PacketCable project for the North American cable operators, they defined a number of MIBs associated with its Packetcable architecture. These MIBs were rooted under a private cablelabs branch.
The PacketCable architecture has been adopted by the ETSI and ITU for international use under the name of IPCablecom. The ETSI group requires some additional MIB objects in the IPCablecom Signaling MIB. The various cable technical bodies agreed to use a common definition of PacketCable/IPCablecom MIBs, managed by a neutral interested standards body, i.e. the IPCDN WG.
PacketCable/IPCablecom introduces four MIB internet-drafts (see slides). The first draft summarizes the management architecture and general MIB requirements. The other three drafts define the MIBs for basic management of the Multimedia Terminal Adapter (MTA), for VoIP signaling within the MTA, and event messaging for the MTA.
There are two basic flavors of MTAs: an embedded MTA is built within the cable modem enclosure, and a standalone MTA operates in conjunction with (but outside of) the cable modem. A new standalone MTA MIB is in the works, primarily to support secure software download to the standalone MTA.
A member of the WG asked what are the drivers for these MIBs: was it PacketCable or something else? Matt Osman responded that these drafts are PacketCable MIBS, and the goal is to make these MIBs into a WG item for IPCDN. Rich Woundy added that his understanding is that the European cable operators are going to leverage pretty much the same Voice over IP technology as the North America operators. Part of the problem is that both groups are making changes to the same MIB. We want to make it into a common MIB so that everybody can contribute to it in a coordinated fashion. The MIB drafts will be reviewed by both groups when there are changes. There has been some agreement so far that what has been submitted is passable to both groups.
A member asked whether there is effort for defining a Call Management Server (CMS) MIB. Matt responded that this is future work, and that the authors are concentrating on Packetcable 1.x technology. The authors have left placeholder OIDs in every MIB, with the anticipation that there will be other components. The authors are concentrating on what is required for CableLabs certification for Packetcable, and more immediate deployment plans by cable operators. Perhaps a CMS MIB will eventually be added; this will be an interesting project because the direction for Packetcable/Cablelabs has been CMS subscriber provisioning via XML messages.
A member asked whether there are any PacketCable MIB requirements for the CMTS. Matt responded that there are no specific PacketCable MIBs for the CMTS. When asked if there was a plan for any PacketCable CMTS MIBs, Matt replied that eventually some MIBs may be defined, but at present the CMTS requirement is to implement all the DOCSIS 1.1 MIBs.
Rich asked for a quick show of hands for how many members had read the drafts. No hands went up.
A member asked whether the Entity MIB was taken under consideration, with respect to the MTA MIB. The Entity MIB already includes the serial number, software, and memory information for a generic device, and might be more appropriate for a cable modem. Matt responded that the MTA has a separate IP address and is completely independent from the cable modem, even when it is embedded. Even if the cable modem and MTA are one physical unit, they have separate IP addresses and MAC addresses.
Rich wondered whether the management of the MTA and cable modem has been worked out. For example, if I see something happening with an MTA, how can I figure out which cable modem it is in. These comments are worth taking under advisement. It is one integrated device, but from the PacketCable architecture point of view this device is separately manageable: the data access provider could manage the CM component, and the telephony provider could manage the MTA component. Rich asked if any other cable operators were present; none spoke up. Rich noted that divided management of the MTA/CM between two independent companies doesn't seem to be an accurate model anymore.
As a side note, the PacketCable/IPCablecom MIB drafts are all private, individual submissions -- not WG drafts. The WG chairs are going to work with Thomas Narten to figure out what to do as the next step. Rich believes the WG will be able to add these drafts as WG items in our charter. The immediate question is, how should the WG respond to these particular drafts? Publish the existing drafts immediately as experimental or informational as a baseline, and then adopt the drafts as WG items? Or wait until IPCDN/IETF completes its own standards-track version? This is a topic of WG and IESG discussion.
Rich pointed out that DOCSIS 1.0 cable modems implemented an early, internet-draft version of the Cable Device MIB (the so-called "CD-4" MIB). Cable operators deployed these cable modems and used this pre-RFC MIB for CM configuration and network management. Later DOCSIS 1.0 modems implemented both the CD-4 MIB as well as the RFC 2669 MIB, so many operators continued to use the CD-4 MIB for backward compatibility with the existing installed base of CD-4-only modems. DOCSIS 1.1 requires that cable modems must only implement the RFC 2669 MIB, so cable operators have to discover whether a particular modem is 1.0 or 1.1 before using the CD-4/RFC 2669 MIB objects (or restrict the population of cable modems in the field to particular vendors/models, which limits the retail market). We would like to prevent this from happening again.
Status of WG Drafts
Application of the IGMP MIB to DOCSIS 1.1, and the Subscriber Management MIB. These two drafts have finished WG review and are on the IESG queue.
QoS MIB. There are two outstanding editorial issues (see slides), and the draft has expired. Rich will work this with the authors.
BPI+ MIB. There are three outstanding issues (see slides), and the draft has expired. Rich will work this with the author.
DOCSIS 2.0 RFI MIB (RFC 2670 update). Rich was curious about what people think about the maturity of this MIB. The WG attempted last call on this draft last year, but perhaps that was too early. The development of this MIB since then seems to have stabilized; perhaps one last version is needed before a successful WG last call
DOCSIS Cable Device MIB. Rich released a new draft version, and asked for some help with the disposition of docsDevNmAccessTable. On the one hand, docsDevNmAccessTable should be deprecated due to its overlap with the SNMP coexistence document (RFC 2576), e.g. the objects in SNMP-COMMUNITY-MIB. On the other hand, CableLabs still requires the implementation of docsDevNmAccessTable for backward compatibility reasons.
DVB/Euromodem MIBs. Rich proposed a September deadline to determine whether there is interest in the Euromodem technical community to continue the effort on the four (expired) drafts.
DOCSIS 1.1 event notifications. A whole new MIB draft is being circulated in CableLabs, that must be reconciled with this (expired) draft.
There are seven new internet drafts within the scope of the WG.
Charter Status and Close
What are we going to do in general about embedded DOCSIS devices (e.g. devices with an embedded DOCSIS cable modem)? This is a real problem for DHCP, SNMP, and many other protocols. What are we going to do about firmware management? If you have a device that's both a PacketCable MTA and a DOCSIS cable modem, which mechanism should be used for secure firmware downloads? Use RFC 2669 plus the secure download functionality in the BPI+ MIB? Or define a new MIB for secure download that includes HTTP as well as TFTP? What's the "maximum number of CPEs" that an embedded DOCSIS device should allow to forward traffic? AT&T Broadband thought that the number of CPEs included internal components like PacketCable MTAs, but it turns out that Time Warner Cable has been telling vendors the opposite. Different embedded DOCSIS devices use different values for DHCP option 60 -- is this destroying the value of DHCP option 60 with what we're doing?
Rich noted the need for new milestones for WG items.
Rich offered to build a small website for communication to the IPCDN WG, in addition to the standard IETF IPCDN website. This would prevent a recent incident where people couldn't find an (expired) draft on the IETF website, resulting in much mis-communication on CableLabs mailing lists.
A member asked about whether the WG was going to work on an Accounting MIB. Rich mentioned that there was mild interest in such a MIB about a year ago, but there was little cable operator interest and no author volunteers. Such a MIB can be discussed on the mailing list, but unless there's a MIB to discuss there's not much to say. An item doesn't have to be a MIB to be a WG item, but things we discuss in the WG are to be related to drafts.