idnits 2.17.1 draft-ietf-ipcdn-ip-over-mcns-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-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 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 == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 88: '... o MUST, SHALL, or MANDATORY -- th...' RFC 2119 keyword, line 91: '... o SHOULD or RECOMMEND -- this ite...' RFC 2119 keyword, line 94: '... o MAY or OPTIONAL -- the item is ...' RFC 2119 keyword, line 245: '...mbers of the LIS MUST have the same IP...' RFC 2119 keyword, line 255: '...members of a LIS MUST use ARP as the m...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 107 has weird spacing: '...n which the c...' -- 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 (26 February 1998) is 9553 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) == Unused Reference: 'MCNS1' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'MCNS2' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'MCNS3' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'IP2' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'IP3' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'IP5' is defined on line 496, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MCNS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'MCNS2' -- Possible downref: Non-RFC (?) normative reference: ref. 'MCNS3' -- Possible downref: Non-RFC (?) normative reference: ref. 'MCNS4' Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. White 3 INTERNET DRAFT Bay Networks, Inc 4 Expires 26 February 1998 6 26 August 1997 8 Logical IP Subnetworks over MCNS Data Link Services 10 Status of this Memo 12 This document is an Internet-Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet-Drafts draft documents are valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Work In Progress 30 This memo is work in progress in support of the activities of the IP 31 over Cable Data Networks (ipcdn) Working Group of the IETF. 33 Table of Contents 35 1. ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . 2 36 2. ACKNOWLEDGMENT . . . . . . . . . . . . . . . . . . . . . . . 2 37 3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 2 38 4. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3 39 5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . . 5 40 5.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 5 41 5.2 LIS Configuration Requirements . . . . . . . . . . . . . . 5 42 5.3 LIS Router Additional Configuration . . . . . . . . . . . . 6 43 6. IP PACKET FORMAT . . . . . . . . . . . . . . . . . . . . . . 6 44 7. IP BROADCAST ADDRESS . . . . . . . . . . . . . . . . . . . . 7 45 8. IP MULTICAST ADDRESS . . . . . . . . . . . . . . . . . . . . 7 46 9. IP INTEGRATED SERVICES SUPPORT . . . . . . . . . . . . . . . 8 47 10. FILTERING . . . . . . . . . . . . . . . . . . . . . . . . . 9 49 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 51 11 CM REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . 9 52 12. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 9 53 13. MIB SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 10 54 14. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 10 55 15. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 16. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 1. ABSTRACT 60 This memo defines an initial application of IP and ARP in an MCNS 61 Community Access Television (CATV) Residential Access Network 62 environment where the cable system is used for bi-directional data 63 transfer. The MCNS network provides a traditional Ethernet or 802.2 64 link layer service between a cable system head end and the customer 65 premises using the cable television system infrastructure. This 66 interface is available via IEEE 802.1D layer services to support IP 67 residential access networking services. 69 In this memo, the term Logical IP Subnetwork (LIS) is defined to 70 apply to traditional IP over Ethernet operating over MCNS services. 72 The recommendations in this draft rely on existing IETF standards for 73 IP and ARP over Broadcast Ethernet networks. 75 2. ACKNOWLEDGMENT 77 The author would like to thank the efforts of the MCNS working group 78 and the efforts of the IETF ipcdn working group. The basis of this 79 document was shamelessly stolen from Mark Laubach's draft for IP over 80 802.14. Wilson Sawyer of Bay Networks provided valuable early review 81 of the document. 83 3. CONVENTIONS 85 The following language conventions are used in the items of 86 specification in this document: 88 o MUST, SHALL, or MANDATORY -- the item is an absolute requirement 89 of the specification. 91 o SHOULD or RECOMMEND -- this item should generally be followed for 92 all but exceptional circumstances. 94 o MAY or OPTIONAL -- the item is truly optional and may be followed 95 or ignored according to the needs of the implementor. 97 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 99 4. INTRODUCTION 101 The goal of this specification is to allow compatible and 102 interoperable implementations of Logical IP Subnetworks over MCNS 103 services [MCNS1->4], including the transmission of IP datagrams and 104 Address Resolution Protocol (ARP) requests and replies. 106 It refers only to an MCNS network based on a two way capable cable 107 plant [MCNS4] in which the cable system is used for data transport 108 in both upstream and downstream directions. MCNS networks using non 109 cable system based return paths such as the telephone network are not 110 considered. 112 This memo specifies the default operational model which will always 113 be available in IP over MCNS implementations. Subsequent memos will 114 build upon and refine this model, however, in the absence or failure 115 of those extensions, operations will default to the specifications 116 contained in this memo. Consequently, this memo will not reference 117 these other extensions. 119 The MCNS subnetwork consists of a Cable Modem Termination System 120 (CMTS) typically located at the cable system head end and one or more 121 cable modems (CM). The CMTS and each CM are MCNS entities. The CMTS 122 is responsible for all aspects of packet processing, resource 123 sharing, and management of the MCNS Media Access Control (MAC) and 124 Physical (PHY) functions. A cable modem is essentially a slave of 125 the CMTS. 127 The organization of the CMTS to each CM is a strict rooted hierarchy: 128 i.e., it is a two-level tree where the CMTS is the root and CM's are 129 the children. In the downstream direction, a MCNS MAC Protocol Data 130 Unit (PDU) may be sent to an individual CM (unicast) or a group of 131 CM's (multicast and broadcast). In the upstream direction, all MAC 132 PDUs (individual or group addressed) are sent from the CM to the 133 CMTS. 135 The CMTS is active and originates and terminates all upstream MAC PDU 136 flows; that is, the CMTS processes the MAC PDUs and does not merely 137 repeat upstream MAC PDUs back on the downstream for station to 138 station communication. The CMTS MAC layer service function 139 determines whether information will be forwarded back on the 140 downstream as defined in [MCNS4]. This may be based on data-link- 141 layer (bridging) semantics, network-layer (routing) semantics or some 142 combination of the two. 144 The specific format of the MCNS MAC PDU is transparent to higher 145 level services, e.g. IP datagrams, and therefore not of specific 146 interest to this draft. However, it is useful to note that MCNS CMTS 148 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 150 and CM entities support a variable length MAC PDU which encapsulates 151 an Ethernet frame for transmission on the CATV network. The MCNS MAC 152 PDU is not presented to the IP layer. For the purposes of protocol 153 specification, IP may only access MCNS services via the 802.2 (LLC) / 154 802.1D (bridge) MAC frame interface, hereafter called the Ethernet 155 interface or Ethernet frame interface. 157 Note: the MCNS Ethernet interface provides 159 1) A frame based packet interface for the transmission of IP 160 datagrams and ARP packets via the MCNS link services. 162 2) An emulated Ethernet service between all CM's and the CMTS. 164 3) Subject to CMTS forwarding rules a bridged Ethernet service 165 between all CM's. 167 The MCNS system employs a link layer encryption mechanism to provide 168 basic data privacy. This is transparent to higher layer services. 170 Basic traffic management support and Quality of Service (QoS) support 171 is provided by the MCNS system. These mechanisms can be exploited to 172 provide for IP integrated services support. 174 The MCNS system specifications provide options to support 175 IEEE802.1D/p, and IEEE802.1Q Virtual LAN (VLAN) extensions. These 176 mechanisms may be used to facilitate support for IP integrated 177 services. 179 The characteristics for residential LISs using MCNS Ethernet frame 180 service interface are: 182 o Supports default IP and ARP over Ethernet services. 184 o Other IETF standards can be used to extend these services; e.g. 185 integrated services over 802.1D/p/Q. 187 o More than one LIS may be in operation over the same MCNS 188 subnetwork (MAC domain) . 190 o An MCNS host system may be a member of more than one LIS. 192 o Layer management services are available to the frame service 193 layer for the purposes of managing point-to-point services on the 194 downstream and upstream, and point-to-multipoint services on the 195 downstream. 197 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 199 o Layer management services are available to the frame service 200 layer for traffic management and Quality of Service (QoS) 201 control. 203 The scope of this specification covers implementation, 204 interoperability, and operational extension issues for delivering 205 Logical IP Subnetwork services via a residential access network 206 implemented via the MCNS standard. Due to the flexibility provided 207 by the MCNS system features, other IETF standards will be relied on 208 when appropriate to do so. 210 For the purposes of this memo, the MCNS subnetwork is intended to 211 support residential Logical IP Subnetwork services. This 212 specification does not preclude the operation of other multiple non- 213 IP services which may be in simultaneous service over the MCNS 214 subnetwork: e.g., voice or video integrated services. 216 5. IP SUBNETWORK CONFIGURATION 218 5.1 Background 220 The MCNS subnetwork can support multiple simultaneously operating 221 disjoint LISs over the same MAC domain. For each LIS a separate 222 administrative entity configures its hosts and routers within the 223 LIS. Each LIS operates and communicates independently of other LISs 224 on the same MCNS network. 226 In the classical model, hosts communicate directly via MCNS to other 227 hosts within the same LIS using the appropriate address resolution 228 service. In this case the ARP service is the mechanism for resolving 229 target IP addresses to target 48-bit IEEE MAC addresses. 231 As LISs are independent, inter-LIS protocol translation or address 232 resolution conversion services are beyond the scope of this memo. 233 Communication to hosts located outside of a LIS is provided via an IP 234 router. 236 The scope of an Ethernet LIS can span beyond an individual MCNS 237 subnetwork using traditional frame-based bridging; e.g., IEEE 802.1D 238 transparent bridging services. 240 5.2 Residential LIS Configuration Requirements 242 The requirements for IP members (hosts, routers) operating in an 243 MCNS-based LIS are: 245 o All members of the LIS MUST have the same IP network/subnet 247 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 249 number and address mask [IP4]. 251 o All members are directly connected 252 to the MCNS subnetwork or to an IEEE 802.1 bridged network 253 communicating with the MCNS subnetwork. 255 o All members of a LIS MUST use ARP as the mechanism for 256 resolving IP addresses to link addresses. 258 o All LIS members connected to the MCNS subnetwork via an 259 MCNS CM MUST be able to communicate via the MCNS 260 subnetwork to or beyond the MCNS CMTS. 261 The MCNS CMTS may be configured to not forward upstream 262 communications from one station to another downstream station 263 in the LIS; in this case, an IP router attached to or 264 colocated with the CMTS should provide the forwarding from 265 upstream to downstream. 267 o All LIS members connected to the MCNS subnetwork via an 268 MCNS CMTS MUST be able to communicate via the MCNS 269 subnetwork to or beyond any downstream MCNS station in the 270 LIS. 272 o A LIS MAY span more than one MCNS subnetwork. 273 Conventional Layer 2 bridging/switching MAY 274 interconnect more than one CMTS. 276 5.3 LIS Router Additional Configuration 278 Routers providing LIS functionality over the MCNS subnetwork MAY also 279 support the ability to interconnect multiple LISs. Routers that wish 280 to provide interconnection of differing LISs MUST be able to support 281 multiple sets of parameters (one set for each connected LIS) and be 282 able to associate each set of parameters to a specific IP 283 network/subnet number. In addition, a router MAY be able to provide 284 this multiple LIS support with a single physical MCNS interface with 285 a different link address per LIS. 287 6. IP PACKET FORMAT 289 Implementations built using the MCNS data link layer services MUST 290 support IP over Ethernet as described in [IP1]. The MTU of this 291 interface is 1500 octets. 293 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 295 7. IP BROADCAST ADDRESS 297 The MCNS downstream MAC PDU supports point-to-multipoint addressing. 298 For each LIS, the IP layer service support at the MCNS CMTS MUST 299 create a single downstream point-to-multipoint group whose membership 300 contains all MCNS CM's participating in that LIS. By default, all 301 downstream IP datagrams whose destination address specifies one of 302 the four forms of IP broadcast addresses mited, directed, subnet 303 directed, or all-subnets directed) [IP4] or an IP multicast address 304 MUST be sent to members of the LIS using this MAC address group. 306 Note: By default, all upstream IP datagrams are sent from the MCNS CM 307 to the CMTS on the single point-to-point connection. 309 Note: the above defaults do not preclude the use of additional 310 downstream point-to-point or point-to-multipoint, or additional 311 upstream point-to-point connections for handling of specific IP flows 312 for integrated-services or multicast distribution support; e.g., 313 mapping IP flows to specific additional connections. 315 In general, it is preferred that downstream data bandwidth resources 316 be used in an efficient manner. Therefore, IP over MCNS 317 implementations SHOULD only send one copy of a packet downstream per 318 IP broadcast transmission or IP multicast transmission. 320 8. IP MULTICAST ADDRESS 322 The MCNS downstream MAC service supports point-to-multipoint 323 addressing. MAC point-to-multipoint addresses can span LISs. 325 For efficiency reasons, a separate point-to-multipoint group MAY be 326 used to support downstream IP multicast datagram distribution. The 327 specific implementation is beyond the scope of this memo, however it 328 can be noted that single or multiple IP multicast groups MAY be 329 mapped to a MAC point-to-multipoint group subject to the abilities of 330 the MCNS CMTS and participating CM's. 332 Note: By default, all upstream IP datagrams are sent from the MCNS CM 333 to the CMTS on the single point-to-point connection. 335 Note: the above defaults do not preclude the use of additional 336 downstream point-to-multipoint or additional upstream point-to-point 337 connections for handling of specific IP flows for integrated-services 338 or multicast distribution support; e.g., mapping IP flows to specific 339 additional connections. 341 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 343 It is preferred that downstream data bandwidth resources be used in 344 an efficient manner, therefore IP over MCNS implementations MUST only 345 send one copy of a packet downstream per IP multicast transmission. 346 Specially, MAC point-to-multipoint groups used for IP multicast 347 datagram distribution may span LISs. 349 For example, there may be two LISs operating via an MCNS subnetwork, 350 LIS-1 and LIS-2. LIS1 may have station members ST-A, ST- B, and ST- 351 C. and LIS-2 may have station members ST-X, ST-Y, and ST-Z. The 352 Ethernet layer management services at the CMTS would have created two 353 point-to-multipoint groups PTM-1 and PTM-2 used for default 354 downstream broadcast and multicast transmission. The membership of 355 PTM-1 would be ST-A, ST-B, and ST-C. The membership of PTM-2 would 356 be ST-X, ST-Y, ST-Z. There may be another point-to-multipoint group 357 for distributing a specific IP multicast group, call this PTM-3. The 358 members of PTM-3 might be ST-B, ST-C, and ST-X therefore PTM-3 spans 359 LIS-1 and LIS-2. 361 The coupling of the MCNS layer management services responsible for 362 group management with that of IP Internet Group Management Protocol 363 (IGMP) is TBD. 365 9. IP INTEGRATED SERVICES SUPPORT 367 By default, the MCNS service delivers IP traffic on a best effort 368 basis. 370 The underlying protocol of MCNS is designed to support multiple 371 service classes with their associated Quality of Service requirements 372 (maximum data rate, guaranteed data rate, priority) subject to the 373 characteristics of the downstream and upstream channel rates. 374 Mappings from IP integrated services to IP over MCNS can be exploited 375 to provide traffic management and Quality of Service (QoS) on a per 376 IP flow basis, for unicast and multicast traffic. As such, these 377 capabilities are available for the support of integrated services and 378 RSVP over MCNS. 380 The MCNS MAC protocol contains the concept of Service IDs which 381 provide both device identification and quality-of-service management. 382 A Service ID defines a particular mapping between a CM and the CMTS. 383 This mapping is the basis on which bandwidth is allocated to the CM 384 by the CMTS and hence by which quality of service is implemented. 386 The CMTS MAY assign one or more Service IDs (SIDs) to each CM, 387 corresponding to the classes of service required by the CM. This 388 mapping MUST be negotiated between the CMTS and the CM during CM 389 registration. 391 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 393 In a basic CM implementation a single Service ID MAY be used to offer 394 best-effort IP service. However, the Service ID concept allows for 395 CMs to be developed with support for multiple service classes. This 396 allows for a service ID to be provided for each "data flow" on which 397 protocols such as RSVP and RTP are based. 399 The mechanism to achieve this is TBD. 401 10. FILTERING 403 The MCNS system provides for the use of filtering for IP and ARP 404 protocol packets. This filtering is available for use by the network 405 operator or the end user (subject to the operator's policy). 407 The MCNS system permits filters to be placed in the upstream and 408 downstream at the CM and the CMTS and independently for point-to- 409 point and point-to-multipoint connections. In addition, filters may 410 be placed at the CMTS in the service function responsible for 411 forwarding packets from upstream to downstream. 413 11. CM REQUIREMENTS 415 The IP over MCNS cable modem MUST be able to separately and 416 simultaneously reassemble or reconstruct packets for each point-to- 417 point or point-to-multipoint downstream connection being used for IP 418 LIS or IP Multicast services. 420 By default, all unicast, broadcast, and multicast communications from 421 an IP over MCNS CM MUST be sent using the point-to-point connection 422 to the MCNS CMTS. It is noted that the default behavior MAY be 423 modified in the future by providing additional connections for IP 424 traffic from the CM to the CMTS. 426 12. SECURITY 428 The MCNS system employs a DES based link security system between the 429 CMTS and all CM's to protect the confidentiality of communications 430 over the RF channels. The specific mechanisms are beyond the scope 431 of this memo, however it should be noted that 433 1) the security system is transparent to any higher layer protocol 434 (including IP). 436 2) the security system does not preclude the use of IPSEC methods for 437 providing additional security. 439 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 441 3) each MAC point-to-point connection is managed using different keys 442 making it difficult to snoop on another station's unicast MAC 443 traffic. 445 4) each MAC point-to-multipoint connection is managed using different 446 keys (stations only have keys for the MAC multicast groups of which 447 they are a member). 449 13. MIB SPECIFICATION 451 TBD. 453 14. OPEN ISSUES 455 o IEEE 802.1D/p and Q extensions, including GARP will be mentioned 456 in a future revision of this memo. 458 o RSVP coupling to MCNS service id is TBD. 460 o IGMP coupling to MCNS layer management is TBD. 462 15. REFERENCES 464 [MCNS1] MCNS Data Over Cable Service Interface Specification 465 Request for Proposals, December 11, 1995. 467 [MCNS2] MCNS Cable Modem Termination System 468 - Network-Side Interface Specification 469 SP-CMTS-NSID04-960409 (CMTS-NSI), April 9, 1996. 471 [MCNS3] MCNS Cable Modem to Customer Premise Equipment Interface 472 Specification SP-CMCID04-960409 (CMCI), April 9, 1996 474 [MCNS4] MCNS Radio Frequency Interface 475 Specification SP-RFII01-970326, March 26, 1997 477 [IP1] Hornig, C.., "A Standard for the Transmission for IP Datagrams 478 over Ethernet Networks", RFC-894, Symbolics Cambridge Research 479 Center, April, 1984. 481 [IP2] Plummer, D., "An Ethernet Address Resolution Protocol - or - 482 Converting Network Addresses to 48.bit Ethernet Address for 483 Transmission on Ethernet Hardware", 484 RFC-826, MIT, November 1982. 486 DRAFT Logical IP Subnetworks over MCNS Services 26 August 1997 488 [IP3] Postel, J., and Reynolds, J., "A Standard for the Transmission 489 of IP Datagrams over IEEE 802 Networks", RFC-1042, 490 USC/Information Sciences Institute, February 1988. 492 [IP4] Braden, R., "Requirements for Internet Hosts -- Communication 493 Layers", RFC-1122, USC/Information Sciences Institute, October 494 1989. 496 [IP5] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, 497 USC/Information Sciences Institute, August 1989. 499 16. AUTHOR 501 Gerry White 502 Broadband Technology Division 503 Bay Networks, Inc. 504 200 Bulfinch Drive 505 Andover, MA 01810 507 Phone: 508.692.1600 508 FAX: 508.692.3200 509 EMail: gwhite@baynetworks.com