Editor's note: These minutes have not been edited. I've added some text, primarily to answer some of the questions asked the first day - my text appears in brackets [] after the questions. ================================================================ Notes from ipcdn WG meetings 9-10 Dec 1996 Reported by Ken Calvert and Stuart Cheshire Abbreviations: CDN = Cable Data Network HE = Head End CM = Cable Modem CP = Customer Premises Monday 9 Dec 1996, 10-11:30 a.m. Masuma Ahmed went over the WG objectives and deliverables. The initial objectives of the working group are to specify operations for IP over CDNs, and to describe the architecture and needed support for services. Deliverables include: Architecture RFC -- framework, terminology, interfaces IP over CATV RFC -- deal with CATV-specific issues, including spectrum/bandwidth management, framing & encapsulation, security. CATV network requirements RFC [Note: IESG has forbidden the use of the term "requirements" in titles of RFCs, so this should be a "recommendations" RFC.] MIBS -- generic "data over cable", RF management. 1. Mike St Johns discussed new "IP Over Cable Data Networks" architecture Internet Draft. His major point was that there are so many different current, planned and possible approaches that specifying a common architecture. The group is (not yet) specifically specifically addressing "IP over 802.14", or "IP over MCNS", but the architecture needs to work for all of them. Discussion continued with descriptions of current Cable modem implementations: Emulating a full broadcast Ethernet, emulating thousands of point-to- point links, or emulating a switched Ethernet with thousands of ports. Other points were brought up and discussed: Cable TV is inherently broadcast, which can cause probems. The group noted that this brings security problems into sharper focus than dial-up modems do. How can we achieve appropriate security at a price point appropriate to the Cable TV industry? Cable TV providers usually want to sell Web browsing to the masses. How can (should) they deal with home users setting up their own Web server and monopolizing the upstream channel? (Like how they deal with home users who plug their CB radios into the cable jack?) Questions from the audience: Should the system carry transit traffic? Should cryptography capabilities also be used to limit access to only legitimate paying subscribers? Masuma Ahmed: Is switched Ethernet is the same as ATM circuit switching with connection set-up/tear-down etc.? [I think this shows how hard we need to work to bridge the gulf between our two communities.] How many houses in typical system? Can be broken down to a fairly fine-grained level; about 500 houses per system. 2. Mark Laubach described the current state of 802.14 standard effort. They are currently in the "consensus-building" phase, with many decisions already made. Ballot is expected 7/97, which would imply IEEE standard in 7/98. 802.14 will have a single MAC layer with multiply PHY layers under it, and will support the standard 802 LLC service. It is designed to be compatible with ATM service. In particular, ATM cell transport is mandatory in CM and HE, while support for transport of variable-length packets is optional in both. Issues still to be addressed include security, bridging, and VLANs. The 802.14 specification consists has the following properties: 5-40MHz upstream channel;50-550/750MHz downstream channel; 64 QAM on downstream channel (about 27Mb/s after FEC);QPSK / 16QUAM for the upstream channels. 3. Michelle Kuska of TCI described the Multimedia Cable Network System (MCNS) effort, which is defining i/f's internal and external to CDN systems. They are in the "third phase", have just released security and RF documents. [MCNS docs are at www.cablemodem.com.] 4. Masuma Ahmed discussed the IP over CATV draft that was put out in early October, before the WG really got going. That document raised a good deal of discussion about topics such as ARP and what constitutes a LIS when topological "neighbors" on the cable cannot communicate directly with each other, either because the link-layer protocol doesn't support it or because of security restrictions enforced by the respective CDMs. Eventually it was agreed that the architecture document needed to be in place to provide a framework for more detailed discussions of the IP over CATV draft. Discussion: 1) Needs to support guaranteed IP service as well as best- effort. [Best effort is contention e.g. CSMA/CD while guaranteed might be CBR cell based protocols.] 2) Needs to support dynamic and static address assignment? [Generally, yes - both models work, but scales are different. Static works if you either have a very small system or you *never* expect to have to renumber.] 3) Needs to support different tiers of IP service: e.g. different types of Web site? [This is almost more of a commercial issue than a protocol issue, but valid nonetheless. Basically, the model of paying more for more or better service for public internet service is hard when the system is as open as a cable system is. So issue is to ensure knobs exist at each entry point (cable modem) to tune for appropriate dollar value.] 4) What about IP Multicast and Broadcast? [Requirement exists for both, but concept of "premium" multicast services has crept in which means support for these in system has to allow system manager greater access to what content streams can and can't get through.] 5) Question about whether IBM owns (or has applied for) patent on certain uses of DHCP? [Chair recieved email from IBM employee indicating that certain uses of DHCP might be covered by patent. Point is noted for further investigation before standards submission. ] 6) Question from the audience: Hosts in the same LIS (Logical IP Subnet) communicate with each other via router. Hosts cannot communicate directly. Then in what sense is it a subnet? Certainly not in the sense of "a set of mutually reachable IP hosts". [Substantial discussion on this topic without identifiable closure. This is tied up in the n-version model of how you might implement IP over cable - see above]. Discussion continued into ARP issues peculiar to a cable data system: Router does not use ARP; it captures mappings from observing DHCP packets. (What if the router crashes and loses this state?) When hosts talk to router it uses ARP to find router's address. (Why? If host can only talk to router, why does it need to address the destination? Why is it not just like a point-to-point link?) Concensus seems to be that ARP over the coax is not necessary. Of course the Cable/Ethernet bridge in the user's home may need to generate proxy ARP replies on the Ethernet interface, because hosts on the Ethernet most likely will be running unmodified networking software that doesn't know about the concept of an Ethernet subnet where the hosts can't talk to each other. [Wouldn't it be more straightforward to just use switched Ethernet techniques to provide an Ethernet where the hosts *can* talk to each other? That way they could also do AppleTalk, IPX, etc. as well as just IP, if they wanted to.] Tuesday 10 December (9-11:30) Mike St Johns led more discussion of architecture document. Salient points included: -- Document should not assume Ethernet as the level-2 interace to the subscriber. Some CDMs will have a card that plugs directly into a PC. -- Architecture should accomodate the possibility of a home network, not just a single PC. -- It was pointed out that dial-up IP service evolved in a somewhat haphazard way, and now nobody is very happy. Goal should be to avoid hacking things together to get it to work. (Example: passing DNS configuration to subscriber in a PPP/IPCP msg.) -- There is a possibility of multiple providers on a single network -- not necessarily multiple wires, but multiple service providers. -- There should be a caveat in the document that what the user "sees" may be different from what's going on underneath. [Why?] [Chair's note: what the customer might see may look like a slightly peculiar ethernet - what may be happening on the cable is probably much more complex and may bear little resemblence to what happens on an ethernet coax. -- Possibility of hybrid paths, of which "telco return" (upstream via dialup) is one example. -- We should not be influenced too much by existing implementations. -- Traditional "corporate" configuration methods are not adequate, e.g. relying on MAC address only. -- Fraud possibilities are a concern. -- [How] should providers offer tunneling services? E.g. some orgs want to import part of their corporate address space into a local office via CDN. -- Is there any reason the thing at the HE should look like anything other than a plain old router [to subscribers]? -- What about QoS if the i/f is Ethernet? -- Link-level service should/must be separated out from IP service? Goal (per MSJ): at the end of the process, mfrs can look at the document and say "I can provide this IP service". It was proposed that we needed some pictures to hang concepts on. Mike Patrick volunteered to draw. He proposed the following as a starting point: Customer Premises |---| - - - - - - - |-----| |-|PC | ----- | | CDM |--| |---| | | R |-| | |-----| | ----- | / | |---| | | | |------| | / |-|PC | |-|CDM-TS|-------------------------- |---| | | |------| | \ ^ LAN \|---| | - - - - - - - - - - |CDM|... Shared-media LAN Head End |---| It was noted that the routing function might be combined with the CDM-terminating system in a single box at the head end (dotted line above) or indeed that the routing function might extend all the way to the CDM itself, but the consensus seemed to be that none of these should make any difference to the way subscriber's "PC" boxes "see" the IP network. Then someone (John Pickens?) offered a more generic architectural view: -------------- -------------- | \ fwding / | | \ fwding / | | \ fnct / | | \ fnct / | | \ / | | \ / | | \ / |<- E.g., 802.14, | \ / | | \ / | MCNS, SCTE, | \ / | | \/ | DAVIC,... |Cable \/ | | || Cable| |MAC || | | || MAC | | || | |______||______| |______||______| | | Cable medium | | HE|_| |_____________________________________| |___| subscr. i/f| | i/f Attributes when Forwarding Function is Router (IP) - Forwarding - Routes - Multicast - QoS - Filtering - Segmentation Attributes when Forwarding Function is Bridge (802.1D/P/Q) - Forwarding - Learning - Multicast - QoS - Filtering - VLAN Attributes of HFC MAC/Link - unicast and multicast downstream - unicast upstream - fixed (ATM) framing with AAL5 for variable framing* - variable framing with code point for ATM* - VLAN* - Encryption* - QoS* * not all technologies There was consensus in the room that these pictures provide a reasonable starting point. Action items to the chair include getting the current version of the the architecture document posted as an Internet Draft.