home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipcdn-tor-00.txt < prev    next >
Text File  |  1997-07-29  |  22KB  |  521 lines

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