IETF IPCDN Meeting Yokohama, Japan July 15, 2002 Reported by Ted Lemon (Ted.Lemon@nominum.com) Edited by Rich Woundy (rwoundy@broadband.att.com) 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. PacketCable/IPCablecom MIBs --------------------------- 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.