Internet Draft M. StJohns (@Home Network) IPCDN Working Group Expires: 1 February 1998 draft-ietf-ipcdn-tor-00.txt IP Over Cable Data Networks - Terms of Reference STATUS OF THIS MEMO This document is an Internet-Draft. Internet Drafts are work- ing documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). INTRODUCTION This document describes a number of possible architectures and design considerations for an IP-over-Cable data system. It sets the basic framework for discussion and creation of the document set described in the charter for the working group. Distribution of this memo is unlimited. 1. Glossary HFC Hybrid fiber-coax. Older CATV systems were provisioned using only coaxial cable. Modern systems use fiber tran- sport from the head end to an optical node located in neighborhood to reduce system noise. Coax runs from the node to the subscriber. The fiber plant is generally a "star" configuration with all optical node fibers ter- minating at a headend. The coax part of the system is generally a trunk and branch configuration. M. StJohns [Page 1]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 Upstream The set of frequencies used to send data from a sub- scriber to the headend. Downstream The set of frequencies used to send data from a headend to a subscriber. Subsplit A frequency allocation plan where 5-42 MHz is used for upstream data and 50+MHz is used for downstream data. Midsplit A frequency allocation plan where 5-108 MHz is used for upstream data and 178+ is used for downstream data. Cable Modem Any device which modulates and demodulates digital data onto a CATV plant. Headend Central distribution point for a CATV system. Video sig- nals are received here from satellite (either co-located or remoted), frequency converted to the appropriate chan- nels, combined with locally originate signals, and rebroadcast onto the HFC plant. For a CATV data system, the headend is the typical place to link between the HFC system and any external data networks. Distribution HubA smaller or remote headend distribution point for a CATV system. Video signals are received here from another site (headend), and redistributed. Sometimes a small number of locally originated signals are added. Such signals might be city information channels, HFC cable modem signals or the like. Optical Node A device used to convert broadband RF (radio frequency, e.g. television signals) to/from a fiber optic signal. Fiber Node Also "Node". An optical node located in the outside plant distribution system which terminates the fiber based downstream signal as an electrical signal onto a coaxial RF cable. Each fiber node is defined to support a certain service area, either defined by number of homes passed, or total amplifier cascade (# of active amplif- iers in the longest line from the node to the end of the line.) Trunk Line A CATV "backbone" coaxial cable. This runs from an Opti- cal Node and through a specific neighborhood or serving area. Branch Line Also "Feeder Cable". A coax cable which runs from a trunk line to a subscriber drop point. M. StJohns [Page 2]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 Tap A passive device which divides the signal between the trunk or feeder lines and splits the signal into ports for subscriber drop access. Drop A subscriber access point. From the tap to the home and the actual coax connection and wiring in the subscribers home. Amplifier Amplifiers are used on coaxial segments of a CATV plant to restore signal levels lost due to attenuation through distance. Unfortunately amplifiers amplify noise as well as signal. Channel A specific frequency allocation and bandwidth. Downstream channels used for television in the US are 6MHz wide (NTSC). International systems such as PAL and SECAM use 8Mhz wide channels. CATV Originally Community Antenna Television. Now used to refer to any cable (coax/fiber) based system provision of television services. Homes Passed The number of homes or offices potentially servicable by a cable system either on a per node or per system basis. Telephony ReturnA variant of a cable data system where the return path from the subscriber cable modem goes via a dialup (or ISDN) connection instead of over an upstream channel. 2. CATV Data System Discussion In some sense, data over cable has its origins in the packet radio sys- tems developed in the 1970s. They both use a broadcast RF paradigm, and they both impose a particular protocol data discipline over RF channels. However a CATV system allows some improvements not available in an over-the-air system. Specifically, a CATV system can reuse frequencies by subdividing the plant into separate regions or nodes. Each node can carry the same signals, can carry a completely disjoint set of signals or can carry a mix of common signals and disjoint signals. This is especially important when considering the use of a CATV system for data. Modern HFC cable systems are designed around a 500-2500 homes passed per node figure of merit. From the view point of a data system, all of those homes share the same bandwidth pool allocated for data on that node. One of the simplest (but expensive) ways of increasing the per home bandwidth available is to build smaller nodes or to split existing nodes. M. StJohns [Page 3]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 Any cable data system is provisioned over the same plant as the common video services and must coexist with them gracefully. In addition, cable data systems may need to coexist with other services such as broadcast audio, video game channels and possibly even digital telephony. In any event, there seems to be almost as many approaches to providing data over cable as there are manufacturers of cable modem systems. The author has (somewhat arbitrarily) divided these into four categories: Bridged, Routed, Switched and Router-with-lots-of-virtual-interfaces. 2.1. Bridged A bridged system acts as a layer 2 (MAC) forwarding system. The systems typically present to the subscriber a standard layer 2 interface such as Ethernet V2 or 802.3 and then emulate that type of LAN over the cable system. IP awareness may be present in either or both of the subscriber or head end cable modems, but is typically used only for management (e.g. SNMP or software upgrades). 2.2. Routed Each of the cable modems in this type of system is fully IP aware and provides at least basic IP forwarding and routing functionality. The author knows of no implementations of this type of system. 2.3. Switched Each cable modem in this type of system is at the end of a virtual cir- cuit imposed over the cable RF plant running back to the head end cable modem. Connections among cable modems and between the cable head end and cable modems can logically treated as being switched. The systems typically present a standard layer 2 interface to the subscriber and function more or less as would an ethernet V2 or 802.3 switch. 2.4. Router-with-lots-of-virtual-interfaces. Cable modem systems of this configuration functionally look like a sin- gle router with lots of ports. Each subscriber cable modem is treated as an individual port. A virtual circuit discipline is imposed over the cable data transmission between the head end cable modem and the sub- scriber cable modem. From an external point of view, each subscriber cable modem is logical part of the head end cable modem/router. 3. Internet Protocol Service Interface Its difficult to say anything specific about the IP interface to an HFC cable modem system due to the range of possible approaches to the M. StJohns [Page 4]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 system. For the purposes of this document, assume that the cable modem system has at least the functionality of a common LAN technology such as an Ethernet or Token Ring. Where this is not or may not be true, the document will try to identify and suggest alternatives to achieve equivalent functionality. 3.1. IP Service Requirements Any data system has to provide some minimum functionalities if it wishes to pass IP traffic: It must be able to deliver traffic on a reasonably reliable (best effort) basis. It must provide for at least unicast delivery of traffic. It must provide a mechanism for mapping system specific addresses (MAC addresses) to specific IP addresses (table, algorithmic, ARP...). With these minimums, the system may pass IP traffic. But is this sufficient for an IP subnet today? Probably not. Some additional requirements and enhancements are: It should provide a broad- cast and multicast capability at the MAC layer. It should provide a Quality of Service capability (e.g. RSVP support). It should provide control over who may and may not send traffic on the system. 3.1.1. General Cable data systems (CDS) are ideally suited to provide broadcast delivery of traffic. They may also provide simple multicast services relatively easily. Ideally, pruning of multicast streams should ori- ginate down at the subscriber cable modem and flow back up through the head end gear into the IP multicast system. MAC level provisioning of multicast services should map cleanly to IP multicast. See the discus- sion below. Providing quality of service control for a CDS is a much more complex problem. Reduced to simple terms, a CDS is an N path (channel) packet radio system where N is 1 or more. QOS could be provided by time divi- sion multiplexing, time reservation, channel reservation, space division (e.g. separate plant), or cell or frame relay techniques, all imposed over the RF data transmission discipline. For the purposes of this document, a CDS QOS system should provide at least the ability to guarantee bandwidth for some number of identified streams and the abil- ity to map those guarantees against the RSVP protocol. In a typical LAN, control of who can and cannot access the system is generally controlled by physical access to the system. In a CDS, since physical access to the system is present in locations where access to the data service is not permitted (not subscribed), access control must be provided as part of the functionality of the modem/head end systems. Control of this access should be possible through normal network M. StJohns [Page 5]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 management tools such as SNMP and should be fairly resistant to sub- scriber fraud and manipulation. One other consideration not normal to most LAN technologies is sub- scriber privacy and protection. Instead of a homogeneous community of hosts all belonging to a single company following a single set of poli- cies, a CDS serves a diverse, possibly non-benign set of subscribers who may need to be protected from each other. 3.1.2. Routing & Tunneling A CDS may be looked at as either a transit or non-transit network. In the transit model, the subscribers may be end-systems (hosts) or routers with the routers connecting to other systems. In the non-transit model, only end-systems are supported and no routing traffic need transit the CDS. A CDS may also have a pure or mixed addressing model. In a pure system, all addresses on the CDS (or at least on the portion of a CDS confined to a single node) come from the same contiguous block of addresses. In the mixed model, more than one set of disjoint addresses may be over- layed onto the CDS, either for flexibility or for scaling. In certain other circumstances, private organizations may wish to export blocks of addresses to a CDS for use by their telecommuters. A CDS should be prepared to support both the transit and non-transit models of connectivity, but should provide mechanisms for the CDS opera- tor to deny its subscribers on a selective basis the ability to connect other networks for transit. For addressing, a CDS must be able to sup- port at least the pure addressing system, to include all normal IP con- siderations such as CIDR. A CDS should be able to support the mixed addressing model, especially as an aid to growth and renumbering. 3.1.3. Filtering In a typical intranet, a corporation may provide filters to isolate engineering traffic from the finance department traffic. Very rarely does a company need to or even want to isolate one engineer's host from another's located mere feet away. Unfortunately, in a CDS the equivalent may be required: to isolate one subscriber from another. A CDS must provide sufficient hooks and knobs so that one subscriber may be isolated from another or from the system as a whole and so that one subscriber may not adversely affect the operation of the CDS. In addi- tion, a CDS must be prepared to filter out address and routing related traffic such as ARP, and must also provide the ability to filter unwanted protocols (e.g. NETBEUI, Appletalk) both at he IP and at the MAC layer. M. StJohns [Page 6]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 3.2. Multicast Service Requirements Having an underlying broadcast medium, a CATV data system has at least the basis for providing IP multicast services. A CATV data system must at least emulate multicast through the provision of broadcast service. Any CATV data system should provide isolation of multicast streams at least down to a specific node and ideally down to a specific cable modem. As the concept of premium services over multicast takes hold (e.g. sports tickers, etc), secure isolation of multicast streams down to specific cable modems will be required. Ideally, a CDS will provide an interface to permit a management system to control multicast traffic offered or sourced from a subscriber. 3.3. Management Interface Requirements CATV data system management can be split in to two pieces: that dealing with the RF portion of the system, and that dealing with the digital portion of the system. The management of the RF portion of the system would not generally be a matter for this document or the IETF, but the addition of cable modems to the system gives the cable operator an opportunity to more closely monitor plant health. As is the case with any other IP capable device or system, the cable modem system must provide appropriate SNMP interfaces for the management of at least the digital portion of the system. The cable modem system should also provide access to management variables appropriate to the RF portion of the system to include bandwidth management, noise, signal strength and error characteristics. 4. Security Considerations 4.1. CATV System Management The monitoring and control of the RF portion of the plant, when done through or with the assistance of Cable Modem systems must provide at least the level of protection available as if the cable modem systems did not exist. In other words, introduction of a data service should not create problems in securing other systems on the cable and should not create path for denial of service attacks. Monitoring and management of Cable Modem assets is a problem due to the open (broadcast) nature of the cable system. The normal SNMP community (clear text password) string based authentication mechanism is not in itself secure enough for use within the system. Cable Modem systems must either provide cryptographic privacy within the system for the pro- tection of such strings, or provide a cryptographically enabled version of SNMP as the management client within the modem. M. StJohns [Page 7]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 4.2. Privacy CATV systems are primarily broadcast systems. This means that with the right equipment, anyone can eavesdrop on any traffic sent by or to any- one on the same segment of cable. A CATV system which provides one or two way data capabilities should provide a means for protecting the data at least on the cable plant. Digital encryption of such data appears to provide adequate protection for general privacy requirements assuming a robust enough encryption algorithm. Other alternative requirements may include the implementation of IPSEC protocols within the modem to provide an end to end private channel between the subscriber and a destination host. Such implementations may be required if the cable plant is to be used for other than IP home sub- scriber use (e.g. telecommuting). 5. Advanced Requirements 5.1. Multi-ISP (Internet Service Provider) Various laws and regulations on the books in the United States today require equal access from a subscriber telephone to all long-distance networks. At the current time, the same is generally not true (in the US) for other services such as IP or for services provided over the cable infrastructure. But, globally, the trend appears to be towards open access through whatever communication media is available. Given this trend, one requirement on future systems will almost cer- tainly be to provide subscriber access through the CDS to multiple ISPs. The simplest implementation of this would permit multiple ISPs on the cable plant, but only permit the subscriber to be associated with one of them at a time. The second, more complex, and unfortunately more prob- able to be required implementation is to permit the subscriber to be associated with multiple ISPs with the specific ISP association changing dynamically. E.g. Dad signs on and is serviced by an ISP paid for by his company. Mom and kids sign on and they are serviced by a residen- tial, family oriented ISP. The last and most complex implementation would have a single cable modem servicing multiple ISPs simultaneously. A CDS should provide the mechanism to at least permit a subscriber to specify and use any of a number of IP dialtone providers (ISPs) on a fairly static basis. It should allow the subscriber to change ISPs as a service change - e.g. requiring cable operator intervention and some non-immediate timeframe such as 24 hours. It may allow the subscriber to use multiple ISPs dynamically, in a non-simultaneous manner. It may allow the subscriber to use multiple ISPs simultaneously. M. StJohns [Page 8]
INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 If a CDS provides a multi-ISP capability, it must do so in a secure manner. Specifically, it must prevent subscribers from using ISPs for which they are not subscribed to. It must prevent L2 traffic from one ISPs subscriber pool from "leaking" into another ISPs virtual network. It must permit the various ISPs appropriate access to manage their sub- scribers. In the future, it is the author's belief that most of the above "shoulds" and "mays" will become "musts" as various legislative and regulatory actions take place. It may be in the best interest of a CDS developer to add the hooks to provide these services earlier rather than later. A. Bibliography These locations were current as of 28 July 1997. Neither 802.14 nor MCNS have completed and released for publication their complete suite of documents. This list will be updated as the documents are finalized and formally published. MCNS Released specifications: This site has the publicly released ver- sions of specifications and standards for cable data systems. MCNS (Multimedia Cable Network System) Partners Ltd is a partnership of a number of large cable companies founded with the specific goal of creat- ing and releasing standards for cable modems. Index of publications: http://www.cablemodem.com/public/pubtech.htm IEEE 802.14 specifications: IEEE 802.14 is the international standards group charged with developing standards for cable modems. 802.14 Requirements document (rev. 2): https://www.walkingdog.com/catv/94-002.pdf M. StJohns [Page 9]
