idnits 2.17.1 draft-ietf-ipcdn-ipcabledata-spec-00.txt: ** The Abstract section seems to be numbered 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-23) 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 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1202 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 20 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 66: '... * MUST, SHALL, or MANDATO...' RFC 2119 keyword, line 69: '... * SHOULD or RECOMMEND - t...' RFC 2119 keyword, line 72: '... * MAY or OPTIONAL - this ...' RFC 2119 keyword, line 149: '...nd cable data network MUST provide the...' RFC 2119 keyword, line 151: '...nology. A router MUST be used to provi...' (47 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In general, the router in the cable data network MUST support at least one subnetwork configuration (referred to as `router LIS configuration'). The hosts within the same subscriber premise MUST have direct access to the other hosts belonging to the same host subnet configuration but MUST not have direct access to the other cable data network service hosts supported in the same router LIS. All hosts within the same host LIS MUST have the same IP network/subnet number and address mask, i.e., all of the IP devices on each of the Ethernet interfaces of the subscriber CDMs MUST be on the same IP router subnet. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Hosts that are not within the same subscriber premise but within the same IP router subnet as well as of different IP router subnets MUST communicate via the IP router. Therefore, the hosts within the same router LIS MUST not have direct access to each other. The router MUST support sending IP packets to any and all hosts within the same router LIS as well as of differing router LISs but the hosts within the router LIS MUST send packets to the router only. Since it is expected that only a small amount of the cable data network service traffic will be from one host to another, this will not cause excessive relay traffic, but does have significant impact on the IP subnet model. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To avoid scaling and security problems with use of ARP over a large IP router subnet (e.g., 1,000 to 10,000 hosts), the router MUST not ARP for the MAC address of the host. Instead, the router MUST assume that DHCP is used by the IP hosts. In the process of relaying the DHCP requests between the hosts to the DHCP server, the router MUST capture the MAC address of the host and the host's IP address assigned by the server. The router MUST bind this information together into its ARP table. The entry in the ARP table MUST be flagged to prevent it from aging out normally. Unicast ARP MAY be used to validate the entry and refresh it. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Hosts ARPing other hosts attached to the same I/F1 interface MUST not leave the I/F1 interface. However, for hosts ARPing other hosts within the router LIS, the router MUST use the proxy ARP capability to answer these ARP requests. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Cable data network service providers may support different tiers of IP service using different charging schemes. Depending on the service tier subscribed to, a host can have access to different servers and application services such as premium web pages, guaranteed bit rate packet, multicast, etc. Different tiers of IP service MAY be supported using the IP access list. By arranging the IP address assigned to fall into one of several ranges, the number of access lists required may be reduced to a very small number. The router MAY support such capability by modifying the DHCP Address Assignment packet to include the subscriber's cable modem ID in the DHCP `client identifier' field. Note that the subscriber's hosts MUST not know the cable modem ID. This will be done transparently to them. -- 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.) -- The document date (October 1, 1996) is 10066 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 85 looks like a reference -- Missing reference section? '4' on line 306 looks like a reference -- Missing reference section? '5' on line 432 looks like a reference -- Missing reference section? '6' on line 511 looks like a reference -- Missing reference section? '7' on line 521 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 - 1 - 3 INTERNET-DRAFT October 1, 1996 5 IP Over Cable Data Network Service 7 draft-ietf-ipcdn-ipcabledata-spec-00.txt 9 October 1, 1996 11 Masuma Ahmed 12 mxa@terayon.com 13 Terayon Corporation 15 Guenter Roeck 16 groeck@cisco.com 17 Cisco 19 1. Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are 22 working documents of the Internet Engineering Task Force 23 (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by 29 other documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 To learn the current status of any Internet-Draft, please 34 check the "lid-abstracts.txt" listing contained in the 35 Internet-Drafts Shadow Directories on ds.internic.net (US 36 East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West 37 Coast), or munnari.oz.au (Pacific Rim). 39 2. Abstract 41 This document describes the application of IP over a cable 42 data network service environment configured as a logical IP 43 subnetwork (LIS). Specifically, this document describes the 44 cable data network interfaces to support IP, IP service 45 features, IP address assignment using Dynamic Host 46 Configuration Protocol (DHCP), Address Resolution Protocol 47 (ARP), and other service-specific issues relating to 48 supporting IP over cable data network service. This document 49 considers only directly connected IP end-stations and the 50 router operating in the conventional LAN based paradigm over 51 a cable data network. As background information, this 52 document also provides an overview of the cable data network 54 - 2 - 56 service, the architecture and the related network 57 interfaces. This document does not specify an Internet 58 Standard of any kind. It is presented for discussion 59 purposes only. 61 3. Conventions 63 The following language conventions are used in the items of 64 specifications in this document: 66 * MUST, SHALL, or MANDATORY - this item is an absolute 67 requirement of the specification. 69 * SHOULD or RECOMMEND - this item should generally be 70 followed for all but exceptional circumstances. 72 * MAY or OPTIONAL - this item is truly optional and may 73 be followed or ignored according to the needs of the 74 implementor. 76 4. Introduction 78 The goal of this specification is to allow compatible and 79 interoperable implementations for transmitting IP packets 80 over cable data network service. This memo defines only the 81 operation of IP over cable data network service and is not 82 meant to describe the operation of cable data network 83 service. Note that the cable data network service described 84 in this document is referred to as high speed cable data 85 service (HSCDS) in the Request For Proposals [1] (RFP) issued 86 by CableLabs. 88 The cable data network service is a public carrier service. 89 Therefore, supporting IP over a public carrier service has 90 issues such as security, scalability, fairness, charging 91 based on service tiers, traffic management and should be 92 dealt with appropriately. This document tries to address 93 some of these issues. 95 In this document, the cable data network is defined as an 96 end-to-end network consisting of three overlaid networks; IP 97 routed network, a data link layer subnetwork and the 98 physical HFC access networks. A functional diagram of the 99 end-to-end cable data network is shown in Figure 1. In this 100 configuration, IP packet data service is supported using the 102 - 3 - 104 packet data bearer service capabilities of the data link 105 layer cable sub-network which in turn is supported using the 106 physical transmission medium and the Medium Access Control 107 (MAC) protocol of the physical layer in the Hybrid Fiber 108 Coax (HFC) access networks. Note that the data link layer 109 subnetwork is a routable network unlike a bridged network 110 and may support functions such as Address Resolution 111 Protocol (ARP) filtering. 113 ________ IP Routed Network 114 |Router|--------------------------------------------|PC| 115 |______| Data Link Layer Subnetwork 116 |headend|----------------------------|modem| 117 |equip. | | | 118 HFC Access Network 119 ---------------------------- 121 Note: The Data link layer subnetwork shown here is 122 a routable network and is not a bridged network. 124 Figure 1: End-to-end Cable Data Network 126 The rest of the document details the support of IP, Address 127 Resolution Protocol (ARP), and IP address assignment over 128 cable data network service. As background information, a 129 brief overview of the cable data network service along with 130 the cable data network architecture is provided in 131 Appendices A and B. 133 5. Cable Data Network Architecture 135 As mentioned earlier, a cable data network consists of three 136 overlaid networks; IP overlaid network, data link layer 137 subnetwork and HFC access network. This section describes 138 the requirements associated with the IP network over the 139 cable data network service only. Specifications of the data 140 link layer and the physical layer networks are beyond the 141 scope of this document. As background information, a brief 142 description of the physical and data link layer networks is 143 provided in Appendix B. 145 - 4 - 147 5.1 IP Routed Network 149 The end-to-end cable data network MUST provide the 150 internetworking capabilities by using IP as the network 151 layer protocol technology. A router MUST be used to provide 152 the layer 3 connectivity between different customer 153 equipment and the wide area network. Therefore, the 154 interface provided by the router to the customer equipment 155 MUST be a network layer interface and the data transferred 156 MUST be a routable protocol which may be routed to the 157 backbone network belonging to the same carrier network or to 158 the Wide Area Network (WAN). The router MUST provide all 159 internetworking between customer equipment (e.g., PCs) 160 attached to the cable data modems and between cable modem 161 users and the WAN. 163 6. Cable Data Network Interfaces 165 The network components of the cable data network and the 166 related interfaces are shown in Figure 2. We followed the 167 conventions as much as possible with a few exceptions used 168 in the HSCDS RFP issued by CableLabs to name the network 169 elements and the associated interfaces of the cable data 170 network. The network components of the cable data network 171 include: 173 * cable data modem (CDM) and PC/WorkStation at 174 the subscriber premise 176 * cable data modem termination system (CDMTS) at 177 the distribution hub or headend 179 * router, Dynamic Host Configuration Protocol (DHCP) 180 server and local web servers at the headend 182 In the sections below, the router interfaces to support IP 183 over cable data network are described. Other relevant 184 interfaces of the end-to-end cable data network are also 185 briefly described. 187 - 5 - 189 Headend or 190 Distribution Hub 191 |------------------------| 192 |________ --------- | 193 ||Local | |Manage-| | 194 ||WWW | |ment | | 195 ||Server| |System | | 196 |---^---- -^----^-- | 197 | | | | | 198 | | |--|----|---| | 199 | | ---I/M1 ---I/M2| 200 | | | | 201 |___v___v_ |-v---|| I/F3 |-------| I/F2 |---|I/F1 ____ 202 I/F7 ||Router |<---|-->|CDMTS|<---|-->|HFC |<--|-->|CDM|<-|->|PC| 203 To <--|-->|_^_____| I/F4 |-----|| |Access | |---| |__| 204 WAN | | | | |Network| | 205 | | |<----------------|----|----------------------------->| 206 | ---I/F5 | I/F6 207 | | | 208 ||-v----| | 209 ||DHCP | | 210 ||Server| | 211 ||______| | 212 -------------------------- 214 I/F: Network Interface 215 I/M: Management Interface 217 Figure 2: Cable Data Network Interfaces 219 6.1 IF/1 Interface 221 The I/F1 is the interface between the CDM and the PC at the 222 subscriber premise. The I/F1 interface supports native 223 Ethernet and IEEE 802.3 Medium Access Control (MAC) 224 protocols over 10Base-T physical interface. The I/F1 225 interface carries transparently the higher layer protocols 226 (e.g., IP) above the data link layer protocol to the PC (or 227 workstation). The specification of this interface is beyond 228 the scope of this document. 230 - 6 - 232 6.2 I/F2 Interface 234 The I/F2 is the interface between the CDM and the HFC access 235 network. The I/F2 supports an RF digital transmission 236 interface between the CDM and the HFC access network and 237 performs upstream RF channel signal modulation and 238 downstream RF channel signal demodulation functions. In 239 addition, I/F2 supports a data link layer interface to the 240 HFC network providing network access control and data 241 delivery functions. The specification of this interface is 242 beyond the scope of this document. 244 6.3 I/F3 Interface 246 The I/F3 is the interface between CDMTS and the HFC access 247 network. The I/F3 interface performs almost the same 248 protocol functions as the I/F2 interface with a few 249 exceptions. The I/F3 interface at the CDMTS is used to 250 control and manage a number of CDMs in the HFC access 251 networks. Therefore, one of the primary functions of the 252 I/F3 interface is to manage and control the usage of 253 upstream and downstream RF channel resources by the 254 subscriber modems. Also, at the physical level, the 255 following differences exist between the I/F2 and I/F3 256 interfaces: 258 - upstream and downstream channel frequencies 259 (e.g., I/F3 upstream and downstream frequencies are 260 opposite to those at the I/F2) 262 - receive and transmit power levels 264 In addition, it is possible that the I/F3 may aggregate more 265 than one fiber nodes and as such the I/F3 interface may have 266 different Bit Error Rate (BER) and Signal to Noise Ratio 267 (SNR) than the I/F2 interface. The specification of this 268 interface is beyond the scope of this document. 270 6.4 I/F4 Interface 272 The I/F4 is the interface between the CDMTS and the router 273 located at the headend or the distribution hub. Separation 274 of the router and the CDMTS may be an implementation issue 275 and as such the I/F4 interface is vendor implementation 276 specific. Therefore, the specification of I/F4 interface is 278 - 7 - 280 beyond the scope of this document. 282 6.5 /F5 Interface 284 The I/F5 is the interface between the router and the IP 285 address server which in this case is the Dynamic Host 286 Configuration Protocol (DHCP) server. The I/F5 interface is 287 a traditional IP routed network from the headend router to 288 the DHCP server(s). As the data transmitted across this 289 network is native IP, the choice of LAN and WAN media is 290 extremely flexible. It is possible that the router or the 291 CDMTS itself may contain the DHCP server functions and thus 292 the I/F5 interface may support a proprietary interface 293 depending on a specific vendor's implementation. Therefore, 294 the specification of I/F5 interface is beyond the scope of 295 this document. 297 6.6 I/F6 Interface 299 The I/F6 is the IP interface between the router located at 300 the headend or distribution hub and the PC located at the 301 subscriber premise. The I/F6 interface MUST support the IP 302 network layer interface between the router located at the 303 distribution hub/headend and the PC (or workstation) located 304 at the subscriber premise. This interface MUST support 305 dynamic assignment of network layer address, i.e., the IP 306 address to the PC on PC power up using DHCP [4]. This 307 interface is described in detail in Section 8 below. 309 6.7 I/F7 Interface 311 The I/F7 is the Wide Area Network (WAN) interface between 312 the router and the public backbone network. This interface 313 supports all of the required standard WAN interfaces 314 supported in a public carrier network. Specification of the 315 I/F7 interface is beyond the scope of this document. 317 7. IP Service Features 319 The types of IP service features that may be supported over 320 cable data network service include: 322 - 8 - 324 * Guaranteed and best effort IP service delivery 325 (e.g., by using RSVP and Integrated services protocol) 327 * Packet/protocol filtering (e.g., packet access, 328 filtering, forwarding, and control) 330 * Subscription based service provisioning 331 (e.g., access to the IP service via a service order process) 333 * Dynamic and static configuration of IP addresses 334 to subscriber's end systems (using DHCP) 336 * Different tiers of IP service (e.g., using IP access list) 338 * IP multicast service 340 8. Logical IP Subnetwork Configuration 342 In the Logical IP Subnetwork (LIS) configuration, each 343 separate administrative entity configures its hosts and 344 routers within a closed logical IP subnetwork. Each cable 345 data network can be considered to be under one 346 administrative entity, i.e., under the jurisdiction of one 347 cable data network service provider. The cable data network 348 can be configured as a single or multiple IP subnetworks 349 depending on the geographic span and physical architecture 350 of the cable data network configuration and the number of 351 hosts supported in the network. 353 In general, the router in the cable data network MUST 354 support at least one subnetwork configuration (referred to 355 as `router LIS configuration'). The hosts within the same 356 subscriber premise MUST have direct access to the other 357 hosts belonging to the same host subnet configuration but 358 MUST not have direct access to the other cable data network 359 service hosts supported in the same router LIS. All hosts 360 within the same host LIS MUST have the same IP 361 network/subnet number and address mask, i.e., all of the IP 362 devices on each of the Ethernet interfaces of the subscriber 363 CDMs MUST be on the same IP router subnet. 365 Depending on the cable data network service requirements, it 366 is RECOMMENDED that the router providing LIS functionality 367 over the cable data network service be able to support more 368 than one LIS. Therefore, the router SHOULD be configured as 369 a member of one or more LISs. All members within a router 370 LIS MUST have the same IP network/subnet number and address 371 mask. 373 - 9 - 375 As mentioned in Appendix A, RF channels are used as the 376 physical transmission medium in the HFC access networks to 377 support cable data network service. In addition, separate RF 378 channels at different RF frequency spectrum are used for 379 upstream and downstream transmission. Also, depending on the 380 CATV network lay-out, two-way CATV data transmission may be 381 supported using a single downstream RF channel and multiple 382 upstream RF channels. For the purpose of this document, the 383 downstream RF channel and the associated upstream RF 384 channels used for two-way data transmission are considered 385 as a single two-way RF transmission entity. 387 Depending on the span of the cable data network and the 388 number of hosts supported per RF transmission entity, a 389 router LIS MUST be configured to support all hosts connected 390 to a single or multiple RF transmission entities. The 391 router providing interconnection of differing LISs MUST be 392 able to support multiple sets of parameters (one set for 393 each connected LIS) and be able to associate each set of 394 parameters to specific IP network/subnet number. The router 395 MUST be able to provide multiple LISs support with a single 396 physical I/F4 interface between itself and the CDMTS. 397 Similarly, a router MUST be able to support a single LIS 398 that spans over multiple CDMTSs. Also, the router MUST be 399 able to provide a single LIS support to more than one RF 400 transmission entities with a single physical I/F4 interface 401 between itself and the CDMTS. Note that, as mentioned 402 earlier, the router and the CDMTS functions may be combined 403 into a single entity. In such a case, the I/F4 related 404 requirements described here do not apply. 406 Hosts that are not within the same subscriber premise but 407 within the same IP router subnet as well as of different IP 408 router subnets MUST communicate via the IP router. 409 Therefore, the hosts within the same router LIS MUST not 410 have direct access to each other. The router MUST support 411 sending IP packets to any and all hosts within the same 412 router LIS as well as of differing router LISs but the hosts 413 within the router LIS MUST send packets to the router only. 414 Since it is expected that only a small amount of the cable 415 data network service traffic will be from one host to 416 another, this will not cause excessive relay traffic, but 417 does have significant impact on the IP subnet model. 419 8.1 Address Resolution Protocol 421 The hosts and router had the same subnet mask for the large 422 router subnet and the hosts that happened to talk to many 423 other hosts on the same router subnet may be required to 424 support very large (e.g., 10,000 entries) Address Resolution 425 Protocol (ARP) tables. Therefore, the router MUST view a 427 - 10 - 429 single or multiple RF transmission entities in the cable 430 data network as one subnet (e.g., 1,000 to 10,000 hosts). 432 Normally, ARP [5] is used between hosts and the router, and 433 between hosts. ARP used in the cable data network for each 434 of these cases is described below. 436 * Router to Host 438 To avoid scaling and security problems with use of ARP over 439 a large IP router subnet (e.g., 1,000 to 10,000 hosts), the 440 router MUST not ARP for the MAC address of the host. 441 Instead, the router MUST assume that DHCP is used by the IP 442 hosts. In the process of relaying the DHCP requests between 443 the hosts to the DHCP server, the router MUST capture the 444 MAC address of the host and the host's IP address assigned 445 by the server. The router MUST bind this information 446 together into its ARP table. The entry in the ARP table 447 MUST be flagged to prevent it from aging out normally. 448 Unicast ARP MAY be used to validate the entry and refresh 449 it. 451 * Host to Router 453 The DHCP MUST communicate the default IP gateway address to 454 the host. Through configuration in the DHCP server, the IP 455 address of the router MUST be supplied to the host. The host 456 MUST issue a normal ARP for the IP address of the router. 457 The subscriber CDM MUST encapsulate this packet to send it 458 upstream. The router MUST answer this ARP normally. 460 * Host to Host 462 Hosts ARPing other hosts attached to the same I/F1 interface 463 MUST not leave the I/F1 interface. However, for hosts ARPing 464 other hosts within the router LIS, the router MUST use the 465 proxy ARP capability to answer these ARP requests. 467 8.1.1 ICMP 469 Data from one host to another on the same 470 router subnet MUST be sent via the router. When two hosts 471 are on the same subnet, the router would normally send an 472 ICMP Redirect to inform the first host that a better (in 473 this case, direct) path exists. However, since the cable 474 media does not support direct host to host communications 475 within the same router subnet, the router MUST do the 476 forwarding and MUST suppress the ICMP messages. 478 - 11 - 480 8.2 IP Address Assignment 482 A host attached to the CDM at the subscriber premise MUST 483 use DHCP to obtain its configuration and IP address. The 484 router MUST participate in all DHCP exchanges between the 485 host and the DHCP server. For example, upon power-up, the 486 host may broadcast a DHCP message on its local Ethernet 487 segment. The host may optionally include any host 488 configuration parameters that it may need. The subscriber 489 modem transmits this packet upstream to the router. 491 Upon receiving the packet, the router adds its IP address to 492 the gateway IP address field in the DHCP packet and may 493 forward the packet to one or more DHCP servers. The DHCP 494 servers send DHCP packets to the router with each packet 495 containing offered IP addresses available for use which the 496 router forwards to the host. The host selects an offered IP 497 address and sends back a DHCP request message for a lease on 498 that address to the router which forwards the packet to the 499 DHCP server. The DHCP server sends an acknowledgement 500 indicating a successful lease of the address. The router 501 adds an ARP entry, binding the IP address to the Ethernet 502 MAC address of the host and forwards the DHCP 503 acknowledgement to the host. 505 8.2.1 IP Broadcast Address 507 It is RECOMMENDED that the 508 router and the hosts within the IP subnet of the cable data 509 network be able to receive and transmit IP packets with any 510 of the four standard IP broadcast addresses as specified in 511 RFC1122 [6]. Members upon receiving an IP broadcast or IP 512 subnet broadcast packets for their LIS, MAY process the 513 packet as if addressed to that station. However, depending 514 on the cable data network service requirements, the router 515 SHOULD have the capability to suppress packets received with 516 broadcast IP address. 518 8.2.2 IP Multicast Address 520 The IP multicasting method 521 specified in RFC1112 [7] requires a Network Service Interface 522 which provides a multicast-like ability to provide dynamic 523 access to the local network service interface operations: 525 - JoinLocalGroup (group-address) 527 - LeaveLocalGroup (group-address) 529 Security, subscription and subscriber billing related 530 implications associated with dynamic subscription and 531 removal from group address lists of any host in a router IP 532 subnetwork require further study. Also, methods to support 534 - 12 - 536 IP multicasting over data link layer protocol of the cable 537 data network service require further study and will be 538 addressed in the future. 540 8.3 IP Service Tiers 542 Cable data network service providers may support different 543 tiers of IP service using different charging schemes. 544 Depending on the service tier subscribed to, a host can have 545 access to different servers and application services such as 546 premium web pages, guaranteed bit rate packet, multicast, 547 etc. Different tiers of IP service MAY be supported using 548 the IP access list. By arranging the IP address assigned to 549 fall into one of several ranges, the number of access lists 550 required may be reduced to a very small number. The router 551 MAY support such capability by modifying the DHCP Address 552 Assignment packet to include the subscriber's cable modem ID 553 in the DHCP `client identifier' field. Note that the 554 subscriber's hosts MUST not know the cable modem ID. This 555 will be done transparently to them. 557 8.4 Security 559 The IP security issues such as supporting authenticated 560 end-to-end IP transmission, e.g., using data encryption are 561 beyond the scope of this document. 563 9. Issues 565 Issues associated with cable data network service 566 configurations to support capabilities such as IP 567 multicasting, IP tunneling and Virtual Private Network (VPN) 568 configuration include: 570 - procedures for performing routing updates between the 571 headend router and the modem router (in this case, the 572 modem at the subscriber premise supports routing 573 functions) 575 - ability to create virtual private IP routed network 577 - filtering of IP packets from outgoing routing protocol 578 updates 580 - 13 - 582 10. Acknowledgements 584 Special thanks to Jim Forster and Dennis Picker for their 585 valuable suggestions and critical review of the document. 586 In addition, the author would like to thank Amir Furhman 587 and Steve Lin for helpful discussions on the topic. 589 11. Appendix A: CATV Data Network Service 591 Examples of CATV data network service capabilities include: 593 *packet data delivery to subscriber cable data modem (CDM) with 594 minimum peak bit rate of 500 kbps in the downstream direction. 595 The maximum peak bit rate can be up to 40 Mbps. 597 *packet data delivery to subscriber cable data modem (CDM) with 598 maximum peak bit rate of 10 Mbps in the upstream direction. 599 The minimum peak bit rate can be as low as 28 kbps. 601 Various implementations of cable data network service 602 supporting a number of data link layer protocols are 603 available today. Most of these implementations support 604 data link layer protocol for the cable data network service 605 using slot and frame approach in both upstream and 606 downstream directions. In the HFC access network, the 607 downstream direction is described as the transmission of 608 data flow from the network to the subscriber and the 609 upstream direction is described as the transmission of data 610 flow from the subscriber to the network. In the downstream 611 direction, usually broadcast mode is used to distribute 612 traffic to the subscribers from the cable headend equipment. 613 In the upstream direction, the network resources are shared 614 and subscribers have to contend for it. As an upstream 615 resource arbiter, the cable headend equipment allocates and 616 manages upstream bandwidth to the subscribers using data 617 link layer bandwidth management algorithm. 619 Radio Frequency (RF) channels in the upstream and downstream 620 directions over HFC access networks are used as the physical 621 medium to transport the cable data network service. Various 622 combinations of the modulation techniques are used for 623 digital transmission of the cable data network service over 625 - 14 - 627 analog transmission medium of the HFC access networks. 628 Examples of different modulation techniques include: 630 * Spread spectrum modulation technique such as 631 Direct Sequence Spread Spectrum 633 * Quaternary Phase Shift Keying (QPSK) technique 635 * Quadrature Amplitude Modulation Technique (QAM) with modulation 636 order of 16, 64, and/or 256 638 *Orthogonal Frequency Division Multiplexing (OFDM) technique 640 The RF channels are configured to run between the cable 641 modem at the subscriber premise and the channel controller 642 at the headend. Upstream channel is shared among all the 643 subscribers in the HFC networks and various physical layer 644 access algorithms in addition to data link layer bandwidth 645 management algorithms are used to access the upstream 646 resources. One or a combination of the following physical 647 layer access algorithms is used to support cable data 648 network service in the upstream direction. 650 * Synchronous Code Division Multiple Access (S-CDMA) method 652 * Time Division Multiple Access (TDMA) method 654 *Frequency Division Multiple Access (FDMA) method 656 12. Appendix B: Cable Data Network Architecture and Interfaces 658 The physical and data link layer portion of the cable data 659 network architecture is described below. 661 B1. HFC Access Network 663 The physical HFC access network is a a shared-media, tree 664 and branch architecture with analog transmission over fiber 665 used for trunks and coaxial cable used for accessing the end 666 systems. The majority of the existing HFC access networks 667 support sub-split systems where the upstream frequency 668 spectrum is supported from 5 to 30 MHz (and 42 MHz in the 669 upgraded systems) and the downstream frequency spectrum is 671 - 15 - 673 from 50 to 550 MHz (and 750 MHz in the upgraded systems). 674 There are also systems that support mid-split (5 to 108 MHz 675 in the upstream direction, and 162 MHz and above in the 676 downstream direction) and high-split (5 to 174 MHz in the 677 upstream direction, and 243 MHz and above in the downstream 678 direction) systems, however, these systems are primarily 679 used in institutional networks. 681 A physical lay-out of the HFC access network is illustrated 682 in Figure 3. As shown, a typical HFC access network consists 683 of fiber nodes and cascaded amplifiers with remote 684 distribution hubs centrally controlled from a central cable 685 headend system. Depending on network configurations, a 686 single headend in the cable data network can support from 40 687 to 200 or larger number of fiber nodes and each fiber node 688 can support from 500 to 2000 or even larger number of 689 households. 691 - 16 - 693 To other<--//---| 694 DH or --//--->||<----SONET Ring ________ |<------> 695 HE || (digital) | | |Co-axial 696 || |------|Fiber |----|Distribut(500/ 697 || (analog) | | | |-ion 2000 698 _____||______ Fiber Optics| |--->|Node | |<------> homes 699 | |<-----//----| | |______| passed) 700 |Distribution|------//------| 701 |Hub (DH) | |<----------> 702 |or | ________ | 703 |Head End | Fiber Optics | |---|<-Co-axial (500/ 704 |(HE) |<-------//-------|Fiber | Distribution 2000 705 |____________|------//-------->|Node |---|<---------->homes 706 || |______| |<---------->passed) 707 || 20,000/100,000 708 To other <--//--|| homes passed 40 to 200 709 DH or --//--->| Fiber Nodes 710 HE 712 Figure 3: An Example HFC Access Network 714 RF channels usually 6 MHz wide are used to transport analog 715 services such as NTSC video, and digital services such as 716 cable data network service, in the HFC access networks. An 717 RF channel is the physical layer parameter of the HFC access 718 network that extends from the physical layer interface of 719 the cable data modem (CDM) located at the subscriber premise 720 to the cable data modem termination system (CDMTS) located 721 at the headend or distribution hub. Separate RF channels in 722 different frequency spectrum are used for upstream and 723 downstream transmission. Distribution hubs are remotely 724 located from the headend and are configured to support one 725 or more fiber nodes. These remote hubs are interconnected 726 back to a centralized headend via digital transmission 727 medium such as SONET ring. 729 13. Terminology 731 In this document, the following terminology is used 732 consistent with the Cablelabs HSCDS RFP. 734 * CDM is the cable data modem at the subscriber premise. 735 * CDMTS is the cable data modem termination system 736 at the headend or distribution hub. 738 - 17 - 740 * Customer equipment is the equipment at the subscriber premise 741 such as a PC or workstation. 742 * HE is the cable head end. 743 * DHE is the Distribution Hub Equipment. 744 * Carrier equipment is the equipment such as CDM, CDMTS, HE 745 that belongs to the public carrier network. 746 * I/F refers to the network interface in the CATV data network. 747 * I/M refers to the management interface in the CATV data network. 749 14. Authors' Addresses 751 Masuma Ahmed 752 Terayon Corporation 753 2952 Bunker Hill Lane 754 Santa Clara, CA 95054 755 Phone: (408) 486-5207 756 Fax: (408) 727-6205 757 Email: mxa@terayon.com 759 Guenter Roeck 760 Cisco 761 174 Tasman Drive 762 Santa Clara, CA 95054 763 Phone: (408) 527-3143 764 Fax: (408) 727-6205 765 Email: groeck@cisco.com 767 - 18 - 769 References 771 1. "High Speed Cable Data Service Request for Proposals", 772 Cable Television Laboratories, April 1995. 774 4. Droms, R., "Dynamic Host Configuration Protocol", 775 RFC1531, Bucknell University, October 1993. 777 5. Plummer, D., "An Ethernet Address Resolution Protocol - 778 or - Converting Network Addresses to 48 bit Ethernet 779 Address for Transmission on Ethernet Hardware", STD 37, 780 RFC826, MIT, November 1982. 782 6. Deering, S., "Requirements for Internet Hosts - 783 Communication Layers", STD 3, RFC1122, USC/Information 784 Sciences Institute, October 1992. 786 7. Deering, S., "Host Extensions for IP Multicasting", STD 787 5, RFC1112, Stanford University, August 1989.