Subject: [ipcdn] IPCDN meeting minutes from the Yokohama IETF

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 22 Oct 2002 07:46:36 -0600

Folks,

I finally finished editing the IPCDN meeting minutes. Sorry about how long
this lingered on my hard drive.

-- Rich

IETF IPCDN Meeting
Yokohama, Japan
July 15, 2002

Reported by Ted Lemon ([email-masked])
Edited by Rich Woundy ([email-masked])

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.

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn