Last Modified: 2003-02-03
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 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.
|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.|
|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|
Vienna.IETF IPCDN MeetingSan Francisco, CA USAMarch 19, 2003 Reported by Greg Nakanishi (email@example.com)Edited by Rich Woundy (firstname.lastname@example.org .com) WG Meeting Summary ------------------ 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 hour. 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, <http://www.ipcdn.org />. 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 meeting ended. Interim Meeting --------------- 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 websites. Review of DOCSIS MIBs --------------------- 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 draft. 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 June. 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 review. 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 CMTS. 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 review. 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 review. 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 list. 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 byte. 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 object. 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 DiffServ-friendly. 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 difficulties. Review of PacketCable/IPCablecom MIBs ------------------------------------- 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 authors' MIBs. 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 TFTP. 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 servers). [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. "ca@ ca.company.com".] 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 WG. 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 MIB. 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. Review of CableHome MIBs ------------------------ 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 charter. 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 overlap. 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 charter. Miscellaneous Items ------------------- 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 items. 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' work. Greg White (jabber participant) requested a timeline for getting the DOCSIS MIBs from internet-draft status to RFC, for coordination with CableLabs standardization