idnits 2.17.1 draft-ietf-ipcdn-ipover-802d14-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-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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. ** There are 19 instances of too long lines in the document, the longest one being 1 character 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 108: '... o MUST, SHALL, or MANDATORY -- th...' RFC 2119 keyword, line 111: '... o SHOULD or RECOMMEND -- this ite...' RFC 2119 keyword, line 114: '... o MAY or OPTIONAL -- the item is ...' RFC 2119 keyword, line 306: '...mbers of the LIS MUST have the same IP...' RFC 2119 keyword, line 317: '...members of a LIS MUST have a mechanism...' (21 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 'SHOULD not' in this paragraph: o All LIS members connected to the IEEE 802.14 subnetwork via an IEEE 802.14 station MUST be able to communicate via the IEEE 802.14 subnetwork to or beyond the IEEE 802.14 HC. By default, the IEEE 802.14 HC optionally SHOULD not forward upstream communications from one station to another downstream station in the LIS; in this case, an IP router attached to or colocated with the HC should provide the forwarding from upstream to downstream. -- 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 (21 February 1998) is 9562 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: '1' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 575, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 579, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 582, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 586, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 598, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 602, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 605, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 609, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 613, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 617, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 620, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 623, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 627, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 630, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 634, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1483 (ref. '2') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1340 (ref. '4') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1237 (ref. '11') (Obsoleted by RFC 1629) ** Obsolete normative reference: RFC 1293 (ref. '12') (Obsoleted by RFC 2390) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 1435 (ref. '14') ** Obsolete normative reference: RFC 1541 (ref. '15') (Obsoleted by RFC 2131) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- No information found for draft-ietf-ipatm-mib - is the name correct? -- Possible downref: Normative reference to a draft: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 17 errors (**), 0 flaws (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mark Laubach 3 INTERNET DRAFT Com21, Inc. 4 Expires 21 February 1998 5 21 August 1997 6 Obsoletes: 8 Logical IP Subnetworks over IEEE 802.14 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. The IEEE 32 802.14 working group has reached a layer of stability necessary for 33 the activities the IETF ipcdn working group. This draft should be 34 considered as the initial work that will be updated over time in 35 concert with IEEE 802.14 development. This memo will track IEEE 36 802.14 progress with the goal of being complete when the IEEE 802.14 37 work reaches sponsor ballot in the IEEE standards process. 39 The IEEE 802.14 Cable-TV Access Method And Physical Layer 40 Specification is work in progress in the IEEE 802 LAN/MAN standards 41 committee. At the time of this draft, the IEEE 802.14 will be 42 released for internal working group review and comment ballot based 43 on the Draft2 Revision 2 specification released from the July 1997 44 IEEE 802.14 working group meeting. Comments on Draft2 Revision2 will 45 be due by the September 1997 IEEE 802.14 interim meeting. 47 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 49 Table of Contents 51 1. ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. ACKNOWLEDGMENT . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . . 6 56 5.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5.2 LIS Configuration Requirements . . . . . . . . . . . . . . 6 58 5.3 LIS Router Additional Configuration . . . . . . . . . . . . 7 59 6. IP PACKET FORMAT . . . . . . . . . . . . . . . . . . . . . . 8 60 7. IP BROADCAST ADDRESS . . . . . . . . . . . . . . . . . . . . 8 61 8. IP MULTICAST ADDRESS . . . . . . . . . . . . . . . . . . . . 8 62 9. IP INTEGRATED SERVICES SUPPORT . . . . . . . . . . . . . . . 9 63 10. FILTERING . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 11 STATION REQUIREMENTS . . . . . . . . . . . . . . . . . . . 10 65 12. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 13. MIB SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 11 67 14. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 11 68 15. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 16. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. ABSTRACT 73 This memo defines an initial application of classical IP and ARP in 74 an IEEE 802.14 Community Access Television (CATV) Residential Access 75 Network environment. IEEE 802.14 services provide two independent 76 link layer service interfaces which are available to support IP 77 residential access networking services: traditional Ethernet bridging 78 (via IEEE 802.1D layer services) and residential ATM networking 79 services. 81 In this memo, the term Logical IP Subnetwork (LIS) is defined to 82 apply to Classical IP over ATM LIS's operating over IEEE 802.14 83 services as well as traditional IP over Ethernet operating over IEEE 84 802.14 services. 86 The recommendations in this draft rely on existing IETF standards for 87 the family of Classical IP and ARP over ATM (IPOA) services and for 88 IP and ARP over Broadcast Ethernet networks. The tree-based 89 hierarchic nature of the IEEE 802.14 MAC subnetwork permits 90 convenient extensions to Classical IPOA model for broadcast and 91 multicast in the downstream direction of the CATV plant. 93 2. ACKNOWLEDGMENT 95 The author would like to thank the efforts of the IEEE 802.14 working 96 group and the efforts of the IETF ipcdn working group. Randy Frei 98 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 100 from Com21 provided early review of this memo and contributed to the 101 open issues list. 103 3. CONVENTIONS 105 The following language conventions are used in the items of 106 specification in this document: 108 o MUST, SHALL, or MANDATORY -- the item is an absolute requirement 109 of the specification. 111 o SHOULD or RECOMMEND -- this item should generally be followed for 112 all but exceptional circumstances. 114 o MAY or OPTIONAL -- the item is truly optional and may be followed 115 or ignored according to the needs of the implementor. 117 4. INTRODUCTION 119 The goal of this specification is to allow compatible and 120 interoperable implementations of Logical IP Subnetworks over IEEE 121 802.14 services [20], including the transmission of IP datagrams and 122 Address Resolution Protocol (ARP) requests (ARP or ATMARP) and 123 replies. 125 This memo specifies the default operational model which will always 126 be available in IP over IEEE 802.14 implementations. Subsequent memos 127 will build upon and refine this model, however, in the absence or 128 failure of those extensions, operations will default to the 129 specifications contained in this memo. Consequently, this memo will 130 not reference these other extensions. 132 The IEEE 802.14 subnetwork consists of a Head-end Controller (HC) and 133 one or more stations (ST). The HC and each station are 802.14 134 entities. The HC is responsible for all aspects of packet processing, 135 resource sharing, and management of the 802.14 Media Access Control 136 (MAC) and Physical (PHY) functions. A station is essentially a slave 137 of the HC. 139 The organization of the HC to each station is a strict rooted 140 hierarchy: i.e., it is a two-level tree where the HC is the root and 141 stations are the children. In the downstream direction, a 802.14 MAC 142 Protocol Data Unit (PDU) may be sent to an individual station 143 (unicast) or a group of stations (multicast and broadcast). In the 144 upstream direction, all MAC PDUs (individual or group addressed) are 145 sent from the station to the HC. The HC is active and originates and 146 terminates all upstream MAC PDU flows; that is, the HC processes the 147 MAC PDUs and does not merely repeat upstream MAC PDUs back on the 149 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 151 downstream for station to station communication. The HC MAC layer 152 service function determines whether information will be forwarded 153 back on the downstream; e.g. similar to Ethernet bridge forwarding 154 behavior. 156 The specific format of the IEEE 802.14 MAC PDU is transparent to 157 higher level services, e.g. IP datagrams, and therefore not of 158 specific interest to this draft. However, it is useful to note that 159 IEEE 802.14 HC and ST entities support an ATM format MAC PDU mode by 160 default, with an optional variable length MAC PDU mode. The choice 161 of MAC PDU is vendor and then operator specified. The IEEE 802.14 MAC 162 PDU is not presented to the IP layer. For the purposes of protocol 163 specification, IP may only access IEEE 802.14 services via one or two 164 layer service interfaces: the ATM cell-based service interface or the 165 802.2 (LLC) / 802.1D (bridge) MAC frame interface, hereafter called 166 the Ethernet interface or Ethernet frame interface. The selection of 167 ATM cell MAC PDU mode or variable MAC PDU mode transparent to the 168 Ethernet frame interface. 170 Note: the term Ethernet interface is meant to convey that a frame 171 based packet interface exists for the transmission of IP datagrams 172 and ARP packets via the IEEE 802.14 link services. The use of this 173 term does not imply at this time that IEEE 802.14 provides an 174 emulated Ethernet service between all stations, and between all 175 stations and the HC. 177 The IEEE 802.14 system employs a DES based link security system 178 between the HC and all stations to protect the confidentiality of 179 communications over the RF channels. The specific mechanisms are 180 beyond the scope of this memo, however it should be noted that 1) the 181 security system is transparent to any higher layer protocol (i.e. 182 IP, ATM, MPEG), 2) the security system does not preclude the use of 183 IPSEC methods for providing additional security for residential IP, 184 3) each MAC point-to-point connection is managed using different keys 185 making it difficult to snoop on another station's unicast MAC 186 traffic, and 4) each MAC point-to-multipoint connection is managed 187 using different keys (stations only have keys for the MAC multicast 188 groups of which they are a member). 190 The IEEE 802.14 system enables comprehensive traffic management 191 support and Quality of Service (QoS) support for ATM networking 192 purpose. As such, these mechanisms can be exploited to provide for 193 IP integrated services support. 195 The IEEE 802.14 system will provide support of IEEE802.1D/p, with 196 future support for IEEE802.1/Q Virtual LAN (VLAN) extensions. As 197 such, these mechanisms can be exploited for IP integrated services 198 support. 200 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 202 The characteristics for residential LISs using IEEE 802.14 ATM cell- 203 based service interface are: 205 o RFC1577, RFC1626, and RFC1755 provide default IP over ATM LIS 206 services. 208 o Other IETF standards can be used to extend these services; e..g 209 MARS, integrated services over ATM, etc. 211 o More than one LIS may be in operation over the same 802.14 212 subnetwork (MAC domain) . 214 o An IEEE 802.14 station may be a member of more than one LIS. 216 o Layer management services are available to the ATM layer for the 217 purposes of managing point-to-point services on the downstream 218 and upstream, and point-to-multipoint services on the downstream. 220 o Layer management services are available to the ATM layer for 221 traffic management and Quality of Service (QoS) control. 223 o An IP router/gateway function may be colocated at the HC, e.g. 224 in the case of an IEEE 802.14 "port card" in an IP router; or the 225 router/gateway may be connected via an ATM network to the HC. 226 This specification will not preclude either scenario. 228 The characteristics for residential LISs using IEEE 802.14 Ethernet 229 frame service interface are: 231 o Supports default IP and ARP over Ethernet services. 233 o Other IETF standards can be used to extend these services; e..g 234 integrated services over 802.1D/p/Q. 236 o More than one LIS may be in operation over the same 802.14 237 subnetwork (MAC domain) . 239 o An IEEE 802.14 station may be a member of more than one LIS. 241 o Layer management services are available to the frame service 242 layer for the purposes of managing point-to-point services on the 243 downstream and upstream, and point-to-multipoint services on the 244 downstream. 246 o Layer management services are available to the frame service 247 layer for traffic management and Quality of Service (QoS) 248 control. 250 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 252 The scope of this specification covers implementation, 253 interoperability, and operational extension issues for delivering 254 Logical IP Subnetwork services via a residential access network 255 implemented via the IEEE 802.14 standard. Due to the flexibility 256 provided by the IEEE 802.14 system features, other IETF standards 257 will be relied on when appropriate to do so. For example the ATM 258 nature of the IEEE 802.14 system suggests that the existing IETF 259 classical IP over ATM family of specifications will apply in general, 260 with specific differences outlined in this memo for reasons of 261 operational efficiency or general IP over Cable Data Network issues. 263 For the purposes of this memo, the IEEE 802.14 subnetwork is intended 264 to support residential Logical IP Subnetwork services. This 265 specification does not preclude the operation of other multiple non- 266 IP services which may be in simultaneous service over the IEEE 802.14 267 subnetwork: e.g., voice or video integrated services. 269 5. IP SUBNETWORK CONFIGURATION 271 5.1 Background 273 The IEEE 802.14 subnetwork can support multiple simultaneously 274 operating disjoint LISs over the same MAC domain. For each LIS a 275 separate administrative entity configures its hosts and routers 276 within the LIS. Each LIS operates and communicates independently of 277 other LISs on the same IEEE 802.14 network. 279 In the classical model, hosts communicate directly via IEEE 802.14 to 280 other hosts within the same LIS using the appropriate address 281 resolution service. In the case of the Ethernet frame service, the 282 ARP service is the mechanism for resolving target IP addresses to 283 target 48-bit IEEE MAC addresses. In the case of the ATM service, the 284 ATMARP service is the mechanism for resolving target IP addresses to 285 target ATM endpoint addresses. 287 As LISs are independent, inter-LIS protocol translation or address 288 resolution conversion services are beyond the scope of this memo. 289 Communication to hosts located outside of a LIS is provided via an IP 290 router. 292 The scope of an Ethernet LIS can span beyond an individual IEEE 293 802.14 subnetwork using traditional frame-based bridging; e.g., IEEE 294 802.1D transparent bridging services. 296 The scope of an ATM LIS can span beyond an individual IEEE 802.14 297 subnetwork using conventional ATM networking. 299 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 301 5.2 Residential LIS Configuration Requirements 303 The requirements for IP members (hosts, routers) operating in an 304 IEEE 802.14-based LIS are: 306 o All members of the LIS MUST have the same IP network/subnet 307 number and address mask [8]. 309 o All members within a ATM cell-based LIS are directly connected to 310 the IEEE 802.14 subnetwork or to an ATM network connected to the 311 IEEE 802.14 subnetwork. 313 o All members within an Ethernet based LIS are directly connected 314 to the IEEE 802.14 subnetwork or to an IEEE 802.1 bridged network 315 communicating with the IEEE 802.14 subnetwork. 317 o All members of a LIS MUST have a mechanism for resolving IP 318 addresses to link addresses (ARP or ATMARP). 320 o All members of a LIS MUST have a mechanism for resolving link 321 addresses to IP addresses via an inverse address resolution 322 protocol (InARP or InATMARP). 324 o All LIS members connected to the IEEE 802.14 subnetwork via an 325 IEEE 802.14 station MUST be able to communicate via the IEEE 326 802.14 subnetwork to or beyond the IEEE 802.14 HC. By default, 327 the IEEE 802.14 HC optionally SHOULD not forward upstream 328 communications from one station to another downstream station in 329 the LIS; in this case, an IP router attached to or colocated with 330 the HC should provide the forwarding from upstream to downstream. 332 o All LIS members connected to the IEEE 802.14 subnetwork via an 333 IEEE 802.14 HC MUST be able to communicate via the IEEE 802.14 334 subnetwork to or beyond any downstream IEEE 802.14 station in the 335 LIS. 337 o A LIS MAY span more than one IEEE 802.14 subnetwork. In the case 338 of frame based, conventional Layer 2 bridging/switching MAY 339 interconnect more than one HC. In the case of ATM based, a 340 backend ATM network MAY interconnect more than one HC. 342 5.3 LIS Router Additional Configuration 344 Routers providing LIS functionality over the IEEE 802.14 subnetwork 345 MAY also support the ability to interconnect multiple LISs. Routers 346 that wish to provide interconnection of differing LISs MUST be able 347 to support multiple sets of parameters (one set for each connected 348 LIS) and be able to associate each set of parameters to a specific IP 350 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 352 network/subnet number. In addition, a router MAY be able to provide 353 this multiple LIS support with a single physical IEEE802.14 interface 354 with a different link address per LIS. 356 6. IP PACKET FORMAT 358 Implementations built using the IEEE 802.14 Ethernet frame layer 359 services MUST support IP over Ethernet as described in [21]. The MTU 360 of this interface is 1500 octets. 362 Implementations built using the IEEE 802.14 ATM cell based layer 363 services MUST support IEEE 802.2 LLC/SNAP encapsulation as described 364 in [2]. LLC/SNAP encapsulation is the default packet format for IP 365 datagrams running via IP over ATM networks. The default MTU of this 366 interface is 9180 octets. This memo recognizes that end-to-end 367 signaling within ATM may allow negotiation of encapsulation method or 368 MTU on a per-VC basis. 370 7. IP BROADCAST ADDRESS 372 The IEEE 802.14 downstream MAC PDU supports point-to-multipoint 373 addressing. For each LIS, the IP layer service support at the IEEE 374 802.14 HC MUST create a single downstream point-to-multipoint group 375 whose membership contains all IEEE 802.14 station participating in 376 that LIS. By default, all downstream IP datagrams whose destination 377 address specifies one of the four forms of IP broadcast addresses 378 (limited, directed, subnet directed, or all-subnets directed) [8] or 379 an IP multicast address MUST be sent to members of the LIS using this 380 MAC address group. 382 Note: By default, all upstream IP datagrams are sent from the IEEE 383 802.14 station to the HC on the single point-to-point connection. 385 Note: the above defaults do not preclude the use of additional 386 downstream point-to-point or point-to-multipoint, or additional 387 upstream point-to-point connections for handling of specific IP flows 388 for integrated-services or multicast distribution support; e.g., 389 mapping IP flows to specific additional connections. 391 In general, it is preferred that downstream data bandwidth resources 392 be used in an efficient manner. Therefore, IP over IEEE802.14 393 implementations SHOULD only send one copy of a packet downstream per 394 IP broadcast transmission or IP multicast transmission. 396 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 398 8. IP MULTICAST ADDRESS 400 The IEEE 802.14 downstream MAC service supports point-to-multipoint 401 addressing. MAC point-to-multipoint addresses can span LISs. 403 For efficiency reasons, a separate point-to-multipoint group MAY be 404 used to support downstream IP multicast datagram distribution. The 405 specific implementation is beyond the scope of this memo, however it 406 can be noted that single or multiple IP multicast groups MAY be 407 mapped to a MAC point-to-multipoint group subject to the abilities of 408 the IEEE 802.14 HC and participating stations. 410 Note: By default, all upstream IP datagrams are sent from the IEEE 411 802.14 station to the HC on the single point-to-point connection. 413 Note: the above defaults do not preclude the use of additional 414 downstream point-to-multipoint or additional upstream point-to-point 415 connections for handling of specific IP flows for integrated-services 416 or multicast distribution support; e.g., mapping IP flows to specific 417 additional connections. 419 It is preferred that downstream data bandwidth resources be used in 420 an efficient manner, therefore IP over IEEE 802.14 implementations 421 MUST only send one copy of a packet downstream per IP multicast 422 transmission. Specially, MAC point-to-multipoint groups used for IP 423 multicast datagram distribution may span LISs. 425 For example, there may be two LISs operating via an IEEE 802.14 426 subnetwork, LIS-1 and LIS-2. LIS1 may have station members ST-A, ST- 427 B, and ST-C. and LIS-2 may have station members ST-X, ST-Y, and ST-Z. 428 The Ethernet layer management services at the HC would have created 429 two point-to-multipoint groups PTM-1 and PTM-2 used for default 430 downstream broadcast and multicast transmission. The membership of 431 PTM-1 would be ST-A, ST-B, and ST-C. The membership of PTM-2 would 432 be ST-X, ST-Y, ST-Z. There may be another point-to-multipoint group 433 for distributing a specific IP multicast group, call this PTM-3. The 434 members of PTM-3 might be ST-B, ST-C, and ST-X therefore PTM-3 spans 435 LIS-1 and LIS-2. 437 The coupling of the IEEE 802.14 layer management services responsible 438 for group management with that of IP Internet Group Management 439 Protocol (IGMP) is TBD. 441 9. IP INTEGRATED SERVICES SPPORT 443 By default, the IEEE 802.14 service delivers IP traffic on a best 444 effort basis. 446 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 448 The underlying protocol of IEEE 802.14 is designed to support the ATM 449 service classes: Constant Bit Rate (CBR), real-time Variable Bit Rate 450 (rt-VBR), non-real-time Variable Bit Rate (nrt-VBR), Available Bit 451 Rate (ABR), and Unspecified Bit Rate (UBR), and their associated 452 Quality of Service requirements (delay, delay tolerance, cell loss 453 rate) subject to the characteristics of the downstream and upstream 454 channel rates. Mappings from IP integrated services to IP over ATM 455 can be exploited to provide traffic management and Quality of Service 456 (QoS) on a per IP flow basis, for unicast and multicast traffic. As 457 such, these capabilities are available for ATM cell-based access as 458 well as Ethernet frame mode access. Specifications for the support 459 of integrated services and RSVP over IEEE 802.14 are TBD. 461 10. FILTERING 463 The IEEE 802.14 system does not preclude the use of filtering for IP 464 and ARP protocol packets. Such filtering is TBD. 466 The IEEE 802.14 system permits filters to be placed in the upstream 467 and downstream at the ST and the HC and independently for point-to- 468 point and point-to-multipoint connections. In addition, filters may 469 be placed at the HC in the service function responsible for 470 forwarding packets from upstream to downstream. Such use of these 471 facilities is TBD. 473 11. Station Requirements 475 The IP over IEEE 802.14 station MUST be able to separately and 476 simultaneously reassemble or reconstruct packets for each point-to- 477 point or point-to-multipoint downstream connection being used for IP 478 LIS or IP Multicast services. 480 By default, all unicast, broadcast, and multicast communications from 481 an IP over IEEE802.14 station MUST be sent using the point-to-point 482 connection to the IEEE 802.14 HC. It is noted that the default 483 behavior MAY be modified in the future by providing additional 484 connections for IP traffic from the IEEE 802.14 station to the IEEE 485 802.14 HC. 487 Specifications for optional LIS forwarding requirements are TBD. 489 12. SECURITY 491 TBD. 493 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 495 13. MIB SPECIFICATION 497 The IEEE 802.14 MIB is TBD. 499 14. OPEN ISSUES 501 o ATM signaling support by IEEE 802.14 and specific HC 502 functionality in support of IP will be mentioned in a future 503 revision of this memo. 505 o IEEE 802.1D/p and Q extensions, including GARP will be mentioned 506 in a future revision of this memo. 508 o RSVP coupling to IEEE 802.14 layer management is TBD. 510 o IGMP coupling to IEEE 802.14 layer management is TBD. 512 o IETF Integrated Services support by IEEE 802.14 is TBD. 514 o It is ambiguous about whether IP members must be connected via 515 ATM mode or Ethernet mode. 802.14 will support either mode. 516 Also, whether a mixture of 802.14 capable LIS members and 517 bridged/switched connected LIS members is allowed on a HC or all 518 stations must be of one type or the other. 520 o The HC forwarding option results in routing intra-LIS. What 521 about subnet-directed broadcasts (blocked)? ARPs? Will the 522 headend proxy ARP for all stations? If the stations are members 523 of the same LIS, then they will try to talk directly and their 524 packets will have to be forced to the router (in frame mode, have 525 the headend proxy ARP for with the router's MAC for any LIS 526 members that are not local to that station). What about ATMARP 527 issues? ICMP redirects should be disabled from the router. Are 528 we assuming that members of an LIS may just be under the same 529 administrative control, and not not necessarily "friendly"? Like 530 an ISP subnet? This does give the administrator some extra 531 protection. 533 o In frame mode, what about multicast? Unicast packets sent to the 534 router will be routed back to the destination station, but 535 multicast assumes all stations can hear each other? Without a 536 specific broadcast facility upstream, do we have to build one for 537 multicast: receive multicast group membership, facilitate group 538 access control and forward multicast back downstream based on 539 this info? Or does 802.14 address this? For ATM mode would 540 something like MARS be needed? 542 What about NHRP (as opposed to ATM ARP)? 544 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 546 From Scott Brim: 548 The head end needs to be intelligent enough to do various 549 filtering at the PDU (not cell) level. Regardless of whether 550 it's used the code needs to be in there. This brings up two 551 questions -- tell me if I read it right: 553 * doesn't forwarding cells to the outside world (beyond the head 554 end) conflict with having frame-level intelligence? That is, 555 does the head end have to accumulate cells and reassemble frames 556 even if it's forwarding cells to the outside world (under any 557 conditions)? 559 * I can't tell if the head end is recommended to do IP forwarding 560 within the 802.14 LIS (there are 2 conflicting statements) but if 561 it doesn't, it still needs all the intelligence to examine 562 packets. Seems like a waste. Why isn't the head end either dumb 563 or smart? 565 15. REFERENCES 567 [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS 568 Service", RFC-1209, USC/Information Sciences Institute, March 569 1991. 571 [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation 572 Layer 5", RFC-1483, USC/Information Sciences Institute, July 573 1993. 575 [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - 576 Converting Network Addresses to 48.bit Ethernet Address for 577 Transmission on Ethernet Hardware", RFC-826, MIT, November 1982. 579 [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1340, USC/ 580 Information Sciences Institute, July 1992. 582 [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of 583 IP Datagrams over IEEE 802 Networks", RFC-1042, USC/Information 584 Sciences Institute, February 1988. 586 [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, 587 Geneva, 19-29 January 1993. 589 [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September 590 - 2 October 1992. 592 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 594 [8] Braden, R., "Requirements for Internet Hosts -- Communication 595 Layers", RFC-1122, USC/Information Sciences Institute, October 596 1989. 598 [9] ATM Forum, "ATM User-Network Interface (UNI) Specification 599 Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper 600 Saddle River, NJ, 07458, September, 1994. 602 [10] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, 603 USC/Information Sciences Institute, August 1989. 605 [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, 606 "Guidelines for OSI NSAP Allocation in the Internet", RFC-1237, 607 USC/Information Sciences Institute, July 1991. 609 [12] Bradely, T., and Brown, C., "Inverse Address Resolution 610 Protocol", RFC-1293, USC/Information Sciences Institute, January 611 1992. 613 [13] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol 614 Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 615 32-48, 1989. 617 [14] Knowles, S., "IESG Advice from Experience with Path MTU 618 Discovery, RFC-1435, IESG, March 1993. 620 [15] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, 621 Bucknell University, October 1993. 623 [16] Kent C., and J. Mogul, "Fragmentation Considered Harmful", 624 Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in 625 Computer Communications Technology, August 1987. 627 [17] Mogul, J., and S. Deering, "Path MTU Discovery", RFC-1191, 628 DECWRL, Stanford University, November 1990. 630 [18] Green, M., Luciani, J., White, K., Kuo, T., "Definitions of 631 Managed Objects for Classical IP and ARP over ATM Using SMIv2", 632 IETF, draft-ietf-ipatm-mib-01 (work in progress), February, 1996. 634 [19] ATM Forum, "ATM User-Network Interface (UNI) Specification 635 Version 4.0", ATM Forum specification afsig-0061.000, 636 ftp://ftp.atmforum.com/, July, 1996. 638 [20] IEEE 802 LAN/MAN, "IEEE 802.14 Draft 2 Revision 2", IEEE 802.14 639 Working Group work in progress, July, 1997. 641 DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 643 [21] Hornig, C.., "A Standard for the Transmission for IP Datagrams 644 over Ethernet Networks", RFC-894, Symbolics Cambridge Research 645 Center, April, 1984. 647 16. AUTHOR 649 Mark Laubach 650 Com21, Inc. 651 750 Tasman Drive 652 Milpitas, CA 95035 654 Phone: 408.953.9175 655 FAX: 408.953.9299 656 EMail: laubach@com21.com