NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Mike St. Johns <stjohns@corp.home.net>
Masuma Ahmed <masuma.ahmed@lmco.com>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Jeffrey Burgan <burgan@home.net>
Mailing Lists:
General Discussion: ipcdn@terayon.com
To Subscribe: ipcdn-request@terayon.com
Archive: ftp://ftp.terayon.com/pub/ipcdn
Description of Working Group:
The goal of the IPCDN WG is to define how the Internet Protocol (IP) is to be supported on a Cable Television (CATV) Data Network. The working group will prepare a framework and requirements document describing a typical CATV infrastructure and how an IP based network might be architected to utilize this infrastructure. It will also address the service interface between IP and the CATV Data Network. The architecture document will discuss the technical details related to the differences between symmetric and asymmetric CATV Data Networks. A terms of reference document will also be published.
Currently, there are no standards available for supporting IP over a CATV Data Network. The IEEE 802.14 WG is chartered to specify the physical layer and data link layer protocols for the CATV Data Network. However, this does not address the issue of mapping higher level protocols onto the hybrid fiber coax (HFC) access networks. The IPCDN WG will define a specification of how IP is mapped onto HFC access networks. Both IPv4 and IPv6 will be addressed, although in separate documents. The following topics will be discussed: multicast, broadcast, address mapping and resolution (for IPv4) and neighbor discovery (for IPv6).
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. DHCP, RSVP, IPSEC, etc.) will operate unmodified. Also, depending on the capabilities provided by cable data network service, specific mappings of RSVP service classes to lower layer services might be desirable. If additional capabilities become necessary, these will be directed to the appropriate group. 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 WG is chartered to deliver the following set of documents:
· Informational RFCs covering the framework, architecture, requirements and terms of reference for Cable Data Networks.
· An IPv4-over-HFC access network document covering the mapping of IP over RF channels, encapsulation and framing of IPv4 packets, IP to modem and/or PC address resolution, multicast, and broadcast.
· An IPv6-over-HFC access network document covering the mapping of IP over RF channels , encapsulation and framing of IPv6 packets, IP to modem and/or PC address resolution, neighbor discovery, multicast, and broadcast.
· A media-specific mib for managing HFC spectrum.
· A mib for managing cable data network service including management of IP over cable data network.
Goals and Milestones:
Sep 96 |
|
Post Internet-Draft on CATV data network architecture framework and terminology document. |
Sep 96 |
|
Post Internet-Draft on IP over CATV data network service (IPC) document. |
Dec 96 |
|
Meet at San Jose IETF meeting to review the two Internet-Drafts and finalize any changes to the architecture framework document. |
Jan 97 |
|
Submit the architecture framework I-D to IESG for publication as an Informational RFC. |
Feb 97 |
|
Post I-D on the cable data network MIB/architecture document. |
Feb 97 |
|
Post I-D on the mailing list on the requirements document with pointers to the IETF standards. |
Feb 97 |
|
Post I-D on the HFC spectrum management MIB/architecture document. |
Apr 97 |
|
Begin the WG last call on the IP over CATV I-D. |
Apr 97 |
|
Met at Memphis IETF to finalize review of the IP over CATV requirements, review the document on pointers to the IETF standards and the MIB/architecture documents. |
Aug 97 |
|
Begin last call on the requirements document on pointer to the IETF standards and the MIB documents. |
Aug 97 |
|
Submit the IP over CATV to IESG for publication as an RFC |
Aug 97 |
|
Finalize review of the requirements document on pointers to the IETF standards and the MIBs. |
Dec 97 |
|
Conclude Working Group. |
Internet-Drafts:
· Cable Device Management Information Base for MCNS compliant Cable Modems and Cable Modem Termination Systems
· Radio Frequency (RF) Interface Management Information Base for MCNS compliant RF interfaces
· IP Over Cable Data Networks - Terms of Reference
· Logical IP Subnetworks over IEEE 802.14 Services
· Logical IP Subnetworks over MCNS Data Link Services
No Request For Comments
Minutes of the IP Over Cable Data Networks (ipcdn) Meeting
Agenda
I. Introduction and Agenda Bashing - StJohns
II. MCNS Status - Woundy (mcns-update.ppt, iscable.ppt)
III. IP Over 802.14 Document Draft (munich.pdf)- Laubach
IV. IP Over MCNS Document Plan (ipmcns1) - White
V. Architecture - Multicast Control in Public LANs - StJohns
VI. RF + Cable Modem MIB Markup - Roeck
VII. Recap & Assignments
IPCDN notes ( 8-14-97)
Mike StJohns began with introductions and agenda bashing/realignment. He informed the group that the Spectrum management MIB will probably be chartered as another WG due to its general nature. The area directors are discussing this.
Gerry White presented his outline of a how a document would be written to describe IP over MCNS:
· Introduction/definition of MCNS terms.
· MCNS MAC
· Broadcast/Multicast flexibility
· IP services
· QoS: SIDs, class of service/mapping to RSVP, data rates, priority, configuration
· Security - link-layer encryption
· Open Issues: VLAN support, RSVP, IGMP
· Questions
What does MCNS include for crypto? 56-bit, crippled 40-bit security encryption, but this is subject to change per export. Do you decrypt re-encrypt on broadcast? Yes. Are multicast groups also taken from ethernet? Yes. What do you expect to see for initial MCNS modems? Initial implementation will be external cable modems, but we expect some limited internal CMs.
The MCNS documents that have been released are available at www.cablemodems.com. StJohns explained the reasoning behind having 2 security documents (privacy/full security) for MCNS.
Rich Woundy gave an update on the MCNS/DOCSIS process: The RF SPEC is now using an engineering change request model as bugs are found in the draft standards. Twenty-six submissions so far. Interoperability testing is set for the released standards (e.g. MAC and PHYSICAL). Recent documents (CM MIB, TRI released, BPI coming out soon) and BPI MIB A MIB is in progress for the Baseline Privacy document. MIBs will not go to all vendors but to working group of vendors and MCNS
members first. The MIB will eventually be submitted through the IETF for validation.
Rich Woundy als presented on the relationship of integrated services/RSVP QoS to the MCNS standards.
Questions:
How much propagation delay is allowed within the MCNS local system? Roughly 2ms. Can you snoop on neighbor bandwidth allocation maps? Yes, maps are in clear. Mike: you may be able to tell volume they use but not necessarily who they are sending to. Is there any authentication - can you spoof RSVP? No authentication as yet, you may spoof RSVP. People could spoof and steal phone service. Mike: But
since you have no direct access to the MAC messages its hard to get the cable modem to play along.
Rich also called for volunteers to get their hands dirty working on the IPCDN/RSVP issues.
Mike spoke on the differences @Home is learning between cable modem systems and traditional ethernet.
Mark Laubach presented on his IP over 802.14 draft and the current status of the 802.14:
He gave some history on the three-year effort and indicated that it was getting near a comment ballot. This will hopefully occur in early 1998. There is a large difference from the MCNS MAC design (802.14 only MAC/PHY). It is ATM centric (with 2 modes cell or perhaps variable length) vs. the MCNS LLC.
802.14 will use DES on up/down links with D-H key mechanisms (with the same export key strengths as MCNS). He presented the Generic MAC model. The basic document design makes IP over 802.14 look a lot like the IP over ATM specs. Multiple logical IP subnet are supported. The draft is missing a section on recommended practices at this time
Questions:
· Is multicast supported? Multicast support exists, but may want to create additional p-to-mp VCs or use p-to-mp broadcast for support. No rues exit for this and all members will see mcasts. It is TBD as to how to segregate groups. How to integrate this with IGMP is also an open issue. This appears to be the same problem as with shortcut mulitcast as mentioned in other groups, this may be very complicated to get (once) down the wire. Policies have not been figured out for ATM or 802.14.
· What's the status with RSVP and integrated services? All TBD at this time.
· Can 802.14 use the same MIBs as MCNS? May be possible, but no one has looked at this. There will probably be some differences to account for MAC.
Without objection, the draft was adopted as a working group draft and will be published as draft-ietf-ipcdn-ip802.14-00.txt or similar name.
Guenter Roeck presented the Cable Device MIB:
He described the changes since the last draft. Discussion identified a need to do more for CM v. CMTS (Cable Modem Termination System) in the next draft. The group agreed that we need better specification for channel response and micro-reflections, but couldn't come to a conclusion on how this would best be implemented. This was referred to the mailing list for resolution or removal if no resolution could be found. Status codes should be referenced back to RF Interface document, App A, which is missing and will be provided via ECR. Are the preamble values useful? Without objection, they were removed as
not useful. Do we add privacy refs or Qos? These won't be added. Seperate MIBs will be built for privacy, and future versions of the MIB may add support for quality of service.
Mike: The RF MIB is close to being ready to go to working group last call with no substantive issues apparent.
Roeck presented the Cable device MIB changes.
Are the events listed the proper ones for the device? The will require some working group review.
Timeticks (10ms) GR: Change to seconds/INTEGER? OK. Other minor open issues were referred to the mailing list.
StJohns gave some specific editing changes that may be needed related to the cmEvControlEntry, CMNmAccess, security server, filterIP, event table and DocsCmRestNow entries.
StJohns held a brief discussion on multicast control in large public LANs. The major point of discussion here was how to relate low level mechanisms such as IGMP and MCNS key management with high-level policy controls such as "premium multicast". One such mechanism may be to have the cable modem
TRAP when it sees IGMP messages and then use the responses to the traps to set the appropriate policy mechanisms. Mark Laubach wondered if this might apply to other public LANs such as ADSL. Guenter Roeck asked if trap mechanism might be better replaced by RADIUS mechanism? Other questions
included concerns about how this might work in a multi-ISP system. StJohns accepted a work item to discuss with the area directors on how to proceed as this may affect other technologies and working groups. St. Johns summarized and adjourned.
None Received