idnits 2.17.1 draft-ietf-ipcdn-tor-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. StJohns (@Home Network) 3 IPCDN Working Group Expires: 1 February 1998 4 draft-ietf-ipcdn-tor-00.txt 6 IP Over Cable Data Networks - Terms of Reference 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft. Internet Drafts are work- 11 ing documents of the Internet Engineering Task Force (IETF), 12 its areas, and its working Groups. Note that other groups may 13 also distribute working documents as Internet Drafts. 15 Internet-Drafts draft documents are valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To learn the current status of any Internet-Draft, please 22 check the "1id-abstracts.txt" listing contained in the 23 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West 26 Coast). 28 INTRODUCTION 30 This document describes a number of possible architectures and design 31 considerations for an IP-over-Cable data system. It sets the basic 32 framework for discussion and creation of the document set described in 33 the charter for the working group. 35 Distribution of this memo is unlimited. 37 1. Glossary 39 HFC Hybrid fiber-coax. Older CATV systems were provisioned 40 using only coaxial cable. Modern systems use fiber tran- 41 sport from the head end to an optical node located in 42 neighborhood to reduce system noise. Coax runs from the 43 node to the subscriber. The fiber plant is generally a 44 "star" configuration with all optical node fibers ter- 45 minating at a headend. The coax part of the system is 46 generally a trunk and branch configuration. 48 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 50 Upstream The set of frequencies used to send data from a sub- 51 scriber to the headend. 53 Downstream The set of frequencies used to send data from a headend 54 to a subscriber. 56 Subsplit A frequency allocation plan where 5-42 MHz is used for 57 upstream data and 50+MHz is used for downstream data. 59 Midsplit A frequency allocation plan where 5-108 MHz is used for 60 upstream data and 178+ is used for downstream data. 62 Cable Modem Any device which modulates and demodulates digital data 63 onto a CATV plant. 65 Headend Central distribution point for a CATV system. Video sig- 66 nals are received here from satellite (either co-located 67 or remoted), frequency converted to the appropriate chan- 68 nels, combined with locally originate signals, and 69 rebroadcast onto the HFC plant. For a CATV data system, 70 the headend is the typical place to link between the HFC 71 system and any external data networks. 73 Distribution HubA smaller or remote headend distribution point for a 74 CATV system. Video signals are received here from 75 another site (headend), and redistributed. Sometimes a 76 small number of locally originated signals are added. 77 Such signals might be city information channels, HFC 78 cable modem signals or the like. 80 Optical Node A device used to convert broadband RF (radio frequency, 81 e.g. television signals) to/from a fiber optic signal. 83 Fiber Node Also "Node". An optical node located in the outside 84 plant distribution system which terminates the fiber 85 based downstream signal as an electrical signal onto a 86 coaxial RF cable. Each fiber node is defined to support 87 a certain service area, either defined by number of homes 88 passed, or total amplifier cascade (# of active amplif- 89 iers in the longest line from the node to the end of the 90 line.) 92 Trunk Line A CATV "backbone" coaxial cable. This runs from an Opti- 93 cal Node and through a specific neighborhood or serving 94 area. 96 Branch Line Also "Feeder Cable". A coax cable which runs from a trunk 97 line to a subscriber drop point. 99 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 101 Tap A passive device which divides the signal between the 102 trunk or feeder lines and splits the signal into ports 103 for subscriber drop access. 105 Drop A subscriber access point. From the tap to the home and 106 the actual coax connection and wiring in the subscribers 107 home. 109 Amplifier Amplifiers are used on coaxial segments of a CATV plant 110 to restore signal levels lost due to attenuation through 111 distance. Unfortunately amplifiers amplify noise as well 112 as signal. 114 Channel A specific frequency allocation and bandwidth. Downstream 115 channels used for television in the US are 6MHz wide 116 (NTSC). International systems such as PAL and SECAM use 117 8Mhz wide channels. 119 CATV Originally Community Antenna Television. Now used to 120 refer to any cable (coax/fiber) based system provision of 121 television services. 123 Homes Passed The number of homes or offices potentially servicable by 124 a cable system either on a per node or per system basis. 126 Telephony ReturnA variant of a cable data system where the return path 127 from the subscriber cable modem goes via a dialup (or 128 ISDN) connection instead of over an upstream channel. 130 2. CATV Data System Discussion 132 In some sense, data over cable has its origins in the packet radio sys- 133 tems developed in the 1970s. They both use a broadcast RF paradigm, and 134 they both impose a particular protocol data discipline over RF channels. 135 However a CATV system allows some improvements not available in an 136 over-the-air system. Specifically, a CATV system can reuse frequencies 137 by subdividing the plant into separate regions or nodes. Each node can 138 carry the same signals, can carry a completely disjoint set of signals 139 or can carry a mix of common signals and disjoint signals. This is 140 especially important when considering the use of a CATV system for data. 142 Modern HFC cable systems are designed around a 500-2500 homes passed per 143 node figure of merit. From the view point of a data system, all of 144 those homes share the same bandwidth pool allocated for data on that 145 node. One of the simplest (but expensive) ways of increasing the per 146 home bandwidth available is to build smaller nodes or to split existing 147 nodes. 149 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 151 Any cable data system is provisioned over the same plant as the common 152 video services and must coexist with them gracefully. In addition, 153 cable data systems may need to coexist with other services such as 154 broadcast audio, video game channels and possibly even digital 155 telephony. 157 In any event, there seems to be almost as many approaches to providing 158 data over cable as there are manufacturers of cable modem systems. The 159 author has (somewhat arbitrarily) divided these into four categories: 160 Bridged, Routed, Switched and Router-with-lots-of-virtual-interfaces. 162 2.1. Bridged 164 A bridged system acts as a layer 2 (MAC) forwarding system. The systems 165 typically present to the subscriber a standard layer 2 interface such as 166 Ethernet V2 or 802.3 and then emulate that type of LAN over the cable 167 system. IP awareness may be present in either or both of the subscriber 168 or head end cable modems, but is typically used only for management 169 (e.g. SNMP or software upgrades). 171 2.2. Routed 173 Each of the cable modems in this type of system is fully IP aware and 174 provides at least basic IP forwarding and routing functionality. The 175 author knows of no implementations of this type of system. 177 2.3. Switched 179 Each cable modem in this type of system is at the end of a virtual cir- 180 cuit imposed over the cable RF plant running back to the head end cable 181 modem. Connections among cable modems and between the cable head end 182 and cable modems can logically treated as being switched. The systems 183 typically present a standard layer 2 interface to the subscriber and 184 function more or less as would an ethernet V2 or 802.3 switch. 186 2.4. Router-with-lots-of-virtual-interfaces. 188 Cable modem systems of this configuration functionally look like a sin- 189 gle router with lots of ports. Each subscriber cable modem is treated 190 as an individual port. A virtual circuit discipline is imposed over the 191 cable data transmission between the head end cable modem and the sub- 192 scriber cable modem. From an external point of view, each subscriber 193 cable modem is logical part of the head end cable modem/router. 195 3. Internet Protocol Service Interface 197 Its difficult to say anything specific about the IP interface to an HFC 198 cable modem system due to the range of possible approaches to the 199 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 201 system. For the purposes of this document, assume that the cable modem 202 system has at least the functionality of a common LAN technology such as 203 an Ethernet or Token Ring. Where this is not or may not be true, the 204 document will try to identify and suggest alternatives to achieve 205 equivalent functionality. 207 3.1. IP Service Requirements 209 Any data system has to provide some minimum functionalities if it wishes 210 to pass IP traffic: It must be able to deliver traffic on a reasonably 211 reliable (best effort) basis. It must provide for at least unicast 212 delivery of traffic. It must provide a mechanism for mapping system 213 specific addresses (MAC addresses) to specific IP addresses (table, 214 algorithmic, ARP...). With these minimums, the system may pass IP 215 traffic. 217 But is this sufficient for an IP subnet today? Probably not. Some 218 additional requirements and enhancements are: It should provide a broad- 219 cast and multicast capability at the MAC layer. It should provide a 220 Quality of Service capability (e.g. RSVP support). It should provide 221 control over who may and may not send traffic on the system. 223 3.1.1. General 225 Cable data systems (CDS) are ideally suited to provide broadcast 226 delivery of traffic. They may also provide simple multicast services 227 relatively easily. Ideally, pruning of multicast streams should ori- 228 ginate down at the subscriber cable modem and flow back up through the 229 head end gear into the IP multicast system. MAC level provisioning of 230 multicast services should map cleanly to IP multicast. See the discus- 231 sion below. 233 Providing quality of service control for a CDS is a much more complex 234 problem. Reduced to simple terms, a CDS is an N path (channel) packet 235 radio system where N is 1 or more. QOS could be provided by time divi- 236 sion multiplexing, time reservation, channel reservation, space division 237 (e.g. separate plant), or cell or frame relay techniques, all imposed 238 over the RF data transmission discipline. For the purposes of this 239 document, a CDS QOS system should provide at least the ability to 240 guarantee bandwidth for some number of identified streams and the abil- 241 ity to map those guarantees against the RSVP protocol. 243 In a typical LAN, control of who can and cannot access the system is 244 generally controlled by physical access to the system. In a CDS, since 245 physical access to the system is present in locations where access to 246 the data service is not permitted (not subscribed), access control must 247 be provided as part of the functionality of the modem/head end systems. 248 Control of this access should be possible through normal network 249 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 251 management tools such as SNMP and should be fairly resistant to sub- 252 scriber fraud and manipulation. 254 One other consideration not normal to most LAN technologies is sub- 255 scriber privacy and protection. Instead of a homogeneous community of 256 hosts all belonging to a single company following a single set of poli- 257 cies, a CDS serves a diverse, possibly non-benign set of subscribers who 258 may need to be protected from each other. 260 3.1.2. Routing & Tunneling 262 A CDS may be looked at as either a transit or non-transit network. In 263 the transit model, the subscribers may be end-systems (hosts) or routers 264 with the routers connecting to other systems. In the non-transit model, 265 only end-systems are supported and no routing traffic need transit the 266 CDS. 268 A CDS may also have a pure or mixed addressing model. In a pure system, 269 all addresses on the CDS (or at least on the portion of a CDS confined 270 to a single node) come from the same contiguous block of addresses. In 271 the mixed model, more than one set of disjoint addresses may be over- 272 layed onto the CDS, either for flexibility or for scaling. In certain 273 other circumstances, private organizations may wish to export blocks of 274 addresses to a CDS for use by their telecommuters. 276 A CDS should be prepared to support both the transit and non-transit 277 models of connectivity, but should provide mechanisms for the CDS opera- 278 tor to deny its subscribers on a selective basis the ability to connect 279 other networks for transit. For addressing, a CDS must be able to sup- 280 port at least the pure addressing system, to include all normal IP con- 281 siderations such as CIDR. A CDS should be able to support the mixed 282 addressing model, especially as an aid to growth and renumbering. 284 3.1.3. Filtering 286 In a typical intranet, a corporation may provide filters to isolate 287 engineering traffic from the finance department traffic. Very rarely 288 does a company need to or even want to isolate one engineer's host from 289 another's located mere feet away. Unfortunately, in a CDS the 290 equivalent may be required: to isolate one subscriber from another. 292 A CDS must provide sufficient hooks and knobs so that one subscriber may 293 be isolated from another or from the system as a whole and so that one 294 subscriber may not adversely affect the operation of the CDS. In addi- 295 tion, a CDS must be prepared to filter out address and routing related 296 traffic such as ARP, and must also provide the ability to filter 297 unwanted protocols (e.g. NETBEUI, Appletalk) both at he IP and at the 298 MAC layer. 300 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 302 3.2. Multicast Service Requirements 304 Having an underlying broadcast medium, a CATV data system has at least 305 the basis for providing IP multicast services. A CATV data system must 306 at least emulate multicast through the provision of broadcast service. 307 Any CATV data system should provide isolation of multicast streams at 308 least down to a specific node and ideally down to a specific cable 309 modem. As the concept of premium services over multicast takes hold 310 (e.g. sports tickers, etc), secure isolation of multicast streams down 311 to specific cable modems will be required. Ideally, a CDS will provide 312 an interface to permit a management system to control multicast traffic 313 offered or sourced from a subscriber. 315 3.3. Management Interface Requirements 317 CATV data system management can be split in to two pieces: that dealing 318 with the RF portion of the system, and that dealing with the digital 319 portion of the system. The management of the RF portion of the system 320 would not generally be a matter for this document or the IETF, but the 321 addition of cable modems to the system gives the cable operator an 322 opportunity to more closely monitor plant health. 324 As is the case with any other IP capable device or system, the cable 325 modem system must provide appropriate SNMP interfaces for the management 326 of at least the digital portion of the system. The cable modem system 327 should also provide access to management variables appropriate to the RF 328 portion of the system to include bandwidth management, noise, signal 329 strength and error characteristics. 331 4. Security Considerations 333 4.1. CATV System Management 335 The monitoring and control of the RF portion of the plant, when done 336 through or with the assistance of Cable Modem systems must provide at 337 least the level of protection available as if the cable modem systems 338 did not exist. In other words, introduction of a data service should 339 not create problems in securing other systems on the cable and should 340 not create path for denial of service attacks. 342 Monitoring and management of Cable Modem assets is a problem due to the 343 open (broadcast) nature of the cable system. The normal SNMP community 344 (clear text password) string based authentication mechanism is not in 345 itself secure enough for use within the system. Cable Modem systems 346 must either provide cryptographic privacy within the system for the pro- 347 tection of such strings, or provide a cryptographically enabled version 348 of SNMP as the management client within the modem. 350 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 352 4.2. Privacy 354 CATV systems are primarily broadcast systems. This means that with the 355 right equipment, anyone can eavesdrop on any traffic sent by or to any- 356 one on the same segment of cable. A CATV system which provides one or 357 two way data capabilities should provide a means for protecting the data 358 at least on the cable plant. Digital encryption of such data appears to 359 provide adequate protection for general privacy requirements assuming a 360 robust enough encryption algorithm. 362 Other alternative requirements may include the implementation of IPSEC 363 protocols within the modem to provide an end to end private channel 364 between the subscriber and a destination host. Such implementations may 365 be required if the cable plant is to be used for other than IP home sub- 366 scriber use (e.g. telecommuting). 368 5. Advanced Requirements 370 5.1. Multi-ISP (Internet Service Provider) 372 Various laws and regulations on the books in the United States today 373 require equal access from a subscriber telephone to all long-distance 374 networks. At the current time, the same is generally not true (in the 375 US) for other services such as IP or for services provided over the 376 cable infrastructure. But, globally, the trend appears to be towards 377 open access through whatever communication media is available. 379 Given this trend, one requirement on future systems will almost cer- 380 tainly be to provide subscriber access through the CDS to multiple ISPs. 381 The simplest implementation of this would permit multiple ISPs on the 382 cable plant, but only permit the subscriber to be associated with one of 383 them at a time. The second, more complex, and unfortunately more prob- 384 able to be required implementation is to permit the subscriber to be 385 associated with multiple ISPs with the specific ISP association changing 386 dynamically. E.g. Dad signs on and is serviced by an ISP paid for by 387 his company. Mom and kids sign on and they are serviced by a residen- 388 tial, family oriented ISP. The last and most complex implementation 389 would have a single cable modem servicing multiple ISPs simultaneously. 391 A CDS should provide the mechanism to at least permit a subscriber to 392 specify and use any of a number of IP dialtone providers (ISPs) on a 393 fairly static basis. It should allow the subscriber to change ISPs as a 394 service change - e.g. requiring cable operator intervention and some 395 non-immediate timeframe such as 24 hours. It may allow the subscriber to 396 use multiple ISPs dynamically, in a non-simultaneous manner. It may 397 allow the subscriber to use multiple ISPs simultaneously. 399 INTERNET-DRAFT IPCDN Terms of Reference 28 July 97 401 If a CDS provides a multi-ISP capability, it must do so in a secure 402 manner. Specifically, it must prevent subscribers from using ISPs for 403 which they are not subscribed to. It must prevent L2 traffic from one 404 ISPs subscriber pool from "leaking" into another ISPs virtual network. 405 It must permit the various ISPs appropriate access to manage their sub- 406 scribers. 408 In the future, it is the author's belief that most of the above 409 "shoulds" and "mays" will become "musts" as various legislative and 410 regulatory actions take place. It may be in the best interest of a CDS 411 developer to add the hooks to provide these services earlier rather than 412 later. 414 A. Bibliography 416 These locations were current as of 28 July 1997. Neither 417 802.14 nor MCNS have completed and released for publication 418 their complete suite of documents. This list will be updated 419 as the documents are finalized and formally published. 421 MCNS Released specifications: This site has the publicly released ver- 422 sions of specifications and standards for cable data systems. MCNS 423 (Multimedia Cable Network System) Partners Ltd is a partnership of a 424 number of large cable companies founded with the specific goal of creat- 425 ing and releasing standards for cable modems. 427 Index of publications: 428 http://www.cablemodem.com/public/pubtech.htm 430 IEEE 802.14 specifications: IEEE 802.14 is the international standards 431 group charged with developing standards for cable modems. 433 802.14 Requirements document (rev. 2): 434 https://www.walkingdog.com/catv/94-002.pdf