idnits 2.17.1 draft-ietf-ipcdn-ipover-802d14-01.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-16) 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 20 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 101: '... o MUST, SHALL, or MANDATORY -- th...' RFC 2119 keyword, line 104: '... o SHOULD or RECOMMEND -- this ite...' RFC 2119 keyword, line 107: '... o MAY or OPTIONAL -- the item is ...' RFC 2119 keyword, line 255: '...mbers of the LIS MUST have the same IP...' RFC 2119 keyword, line 262: '...members of a LIS MUST have a mechanism...' (20 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 (13 September 1998) is 9347 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 494, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 502, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 509, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 513, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 516, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 523, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 527, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 530, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 534, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 538, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 542, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 545, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 548, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 552, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 559, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 566, 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 (~~), 20 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 13 September 1998 5 13 March 1998 7 Logical IP Subnetworks over IEEE 802.14 Services 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet-Drafts draft documents are valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Work In Progress 29 This memo is work in progress in support of the activities of the IP 30 over Cable Data Networks (ipcdn) Working Group of the IETF. The IEEE 31 802.14 working group has reached a layer of stability necessary for 32 the activities the IETF ipcdn working group. This draft should be 33 considered as the initial work that will be updated over time in 34 concert with IEEE 802.14 development. This memo will track IEEE 35 802.14 progress with the goal of being complete when the IEEE 802.14 36 work reaches sponsor ballot in the IEEE standards process. 38 The IEEE 802.14 Cable-TV Access Method And Physical Layer 39 Specification is work in progress in the IEEE 802 LAN/MAN standards 40 committee. At the time of this draft, the IEEE 802.14 is planning 41 the release of its next comment ballot for July 1998. In the 42 previous ballot process, variable length (Ethernet) mode was removed 43 so as to differentiate the services from MCNS DOCSIS. 45 Table of Contents 47 1. ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. ACKNOWLEDGMENT . . . . . . . . . . . . . . . . . . . . . . . 2 49 3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3 51 5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . . 6 52 5.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 6 53 5.2 LIS Configuration Requirements . . . . . . . . . . . . . . 6 54 5.3 LIS Router Additional Configuration . . . . . . . . . . . . 7 55 6. IP PACKET FORMAT . . . . . . . . . . . . . . . . . . . . . . 8 56 7. IP BROADCAST ADDRESS . . . . . . . . . . . . . . . . . . . . 8 57 8. IP MULTICAST ADDRESS . . . . . . . . . . . . . . . . . . . . 8 58 9. IP INTEGRATED SERVICES SUPPORT . . . . . . . . . . . . . . . 9 59 10. FILTERING . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 11 STATION REQUIREMENTS . . . . . . . . . . . . . . . . . . . 10 61 12. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 13. MIB SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 11 63 14. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 11 64 15. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 16. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 1. ABSTRACT 69 This memo defines an initial application of classical IP and ARP in 70 an IEEE 802.14 Community Access Television (CATV) Residential Access 71 Network environment. IEEE 802.14 services provide two independent 72 link layer service interfaces which are available to support IP 73 residential access networking services: traditional Ethernet bridging 74 (via IEEE 802.1D layer services) and residential ATM networking 75 services. 77 In this memo, the term Logical IP Subnetwork (LIS) is defined to 78 apply to Classical IP over ATM LIS's operating over IEEE 802.14 79 services as well as traditional IP over Ethernet operating over IEEE 80 802.14 services. 82 The recommendations in this draft rely on existing IETF standards for 83 the family of Classical IP and ARP over ATM (IPOA) services and for 84 IP and ARP over Broadcast Ethernet networks. The tree-based 85 hierarchic nature of the IEEE 802.14 MAC subnetwork permits 86 convenient extensions to Classical IPOA model for broadcast and 87 multicast in the downstream direction of the CATV plant. 89 2. ACKNOWLEDGMENT 91 The author would like to thank the efforts of the IEEE 802.14 working 92 group and the efforts of the IETF ipcdn working group. Randy Frei 93 from Com21 provided early review of this memo and contributed to the 94 open issues list. 96 3. CONVENTIONS 98 The following language conventions are used in the items of 99 specification in this document: 101 o MUST, SHALL, or MANDATORY -- the item is an absolute requirement 102 of the specification. 104 o SHOULD or RECOMMEND -- this item should generally be followed for 105 all but exceptional circumstances. 107 o MAY or OPTIONAL -- the item is truly optional and may be followed 108 or ignored according to the needs of the implementor. 110 4. INTRODUCTION 112 The goal of this specification is to allow compatible and 113 interoperable implementations of Logical IP Subnetworks over IEEE 114 802.14 services [20], including the transmission of IP datagrams and 115 Address Resolution Protocol (ARP) requests (ARP or ATMARP) and 116 replies. 118 This memo specifies the default operational model which will always 119 be available in IP over IEEE 802.14 implementations. Subsequent memos 120 will build upon and refine this model, however, in the absence or 121 failure of those extensions, operations will default to the 122 specifications contained in this memo. Consequently, this memo will 123 not reference these other extensions. 125 The IEEE 802.14 subnetwork consists of a Head-end Controller (HC) and 126 one or more stations (ST). The HC and each station are 802.14 127 entities. The HC is responsible for all aspects of packet processing, 128 resource sharing, and management of the 802.14 Media Access Control 129 (MAC) and Physical (PHY) functions. A station is essentially a slave 130 of the HC. 132 The organization of the HC to each station is a strict rooted 133 hierarchy: i.e., it is a two-level tree where the HC is the root and 134 stations are the children. In the downstream direction, a 802.14 MAC 135 Protocol Data Unit (PDU) may be sent to an individual station 136 (unicast) or a group of stations (multicast and broadcast). In the 137 upstream direction, all MAC PDUs (individual or group addressed) are 138 sent from the station to the HC. The HC is active and originates and 139 terminates all upstream MAC PDU flows; that is, the HC processes the 140 MAC PDUs and does not merely repeat upstream MAC PDUs back on the 141 downstream for station to station communication. The HC MAC layer 142 service function determines whether information will be forwarded 143 back on the downstream; e.g. similar to Ethernet bridge forwarding 144 behavior. 146 The specific format of the IEEE 802.14 MAC PDU is transparent to 147 higher level services, e.g. IP datagrams, and therefore not of 148 specific interest to this draft. However, it is useful to note that 149 IEEE 802.14 HC and ST entities support an ATM format MAC PDU mode. 150 The IEEE 802.14 MAC PDU is not presented to the IP layer. For the 151 purposes of protocol specification, IP may only access IEEE 802.14 152 services via its ATM cell-based service interface 154 The IEEE 802.14 system employs a DES based link security system 155 between the HC and all stations to protect the confidentiality of 156 communications over the RF channels. The specific mechanisms are 157 beyond the scope of this memo, however it should be noted that 1) the 158 security system is transparent to any higher layer protocol (i.e. 159 IP, ATM, MPEG), 2) the security system does not preclude the use of 160 IPSEC methods for providing additional security for residential IP, 161 3) each MAC point-to-point connection is managed using different keys 162 making it difficult to snoop on another station's unicast MAC 163 traffic, and 4) each MAC point-to-multipoint connection is managed 164 using different keys (stations only have keys for the MAC multicast 165 groups of which they are a member). 167 The IEEE 802.14 system enables comprehensive traffic management 168 support and Quality of Service (QoS) support for ATM networking 169 purpose. As such, these mechanisms can be exploited to provide for 170 IP integrated services support. 172 The IEEE 802.14 system will provide support of IEEE802.1D/p, with 173 future support for IEEE802.1/Q Virtual LAN (VLAN) extensions. As 174 such, these mechanisms can be exploited for IP integrated services 175 support. 177 The characteristics for residential LISs using IEEE 802.14 ATM cell- 178 based service interface are: 180 o RFC1577, RFC1626, and RFC1755 provide default IP over ATM LIS 181 services. 183 o Other IETF standards can be used to extend these services; e..g 184 MARS, integrated services over ATM, etc. 186 o More than one LIS may be in operation over the same 802.14 187 subnetwork (MAC domain) . 189 o An IEEE 802.14 station may be a member of more than one LIS. 191 o Layer management services are available to the ATM layer for the 192 purposes of managing point-to-point services on the downstream 193 and upstream, and point-to-multipoint services on the downstream. 195 o Layer management services are available to the ATM layer for 196 traffic management and Quality of Service (QoS) control. 198 o An IP router/gateway function may be colocated at the HC, e.g. 199 in the case of an IEEE 802.14 "port card" in an IP router; or the 200 router/gateway may be connected via an ATM network to the HC. 201 This specification will not preclude either scenario. 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 IEEE 802.14 standard. Due to the flexibility 207 provided by the IEEE 802.14 system features, other IETF standards 208 will be relied on when appropriate to do so. For example the ATM 209 nature of the IEEE 802.14 system suggests that the existing IETF 210 classical IP over ATM family of specifications will apply in general, 211 with specific differences outlined in this memo for reasons of 212 operational efficiency or general IP over Cable Data Network issues. 214 For the purposes of this memo, the IEEE 802.14 subnetwork is intended 215 to support residential Logical IP Subnetwork services. This 216 specification does not preclude the operation of other multiple non- 217 IP services which may be in simultaneous service over the IEEE 802.14 218 subnetwork: e.g., voice or video integrated services. 220 5. IP SUBNETWORK CONFIGURATION 222 5.1 Background 224 The IEEE 802.14 subnetwork can support multiple simultaneously 225 operating disjoint LISs over the same MAC domain. For each LIS a 226 separate administrative entity configures its hosts and routers 227 within the LIS. Each LIS operates and communicates independently of 228 other LISs on the same IEEE 802.14 network. 230 In the classical model, hosts communicate directly via IEEE 802.14 to 231 other hosts within the same LIS using the appropriate address 232 resolution service. In the case of the Ethernet frame service, the 233 ARP service is the mechanism for resolving target IP addresses to 234 target 48-bit IEEE MAC addresses. In the case of the ATM service, the 235 ATMARP service is the mechanism for resolving target IP addresses to 236 target ATM endpoint addresses. 238 As LISs are independent, inter-LIS protocol translation or address 239 resolution conversion services are beyond the scope of this memo. 240 Communication to hosts located outside of a LIS is provided via an IP 241 router. 243 The scope of an Ethernet LIS can span beyond an individual IEEE 244 802.14 subnetwork using traditional frame-based bridging; e.g., IEEE 245 802.1D transparent bridging services. 247 The scope of an ATM LIS can span beyond an individual IEEE 802.14 248 subnetwork using conventional ATM networking. 250 5.2 Residential LIS Configuration Requirements 252 The requirements for IP members (hosts, routers) operating in an 253 IEEE 802.14-based LIS are: 255 o All members of the LIS MUST have the same IP network/subnet 256 number and address mask [8]. 258 o All members within a ATM cell-based LIS are directly connected to 259 the IEEE 802.14 subnetwork or to an ATM network connected to the 260 IEEE 802.14 subnetwork. 262 o All members of a LIS MUST have a mechanism for resolving IP 263 addresses to link addresses (ARP or ATMARP). 265 o All members of a LIS MUST have a mechanism for resolving link 266 addresses to IP addresses via an inverse address resolution 267 protocol (InARP or InATMARP). 269 o All LIS members connected to the IEEE 802.14 subnetwork via an 270 IEEE 802.14 station MUST be able to communicate via the IEEE 271 802.14 subnetwork to or beyond the IEEE 802.14 HC. By default, 272 the IEEE 802.14 HC optionally SHOULD not forward upstream 273 communications from one station to another downstream station in 274 the LIS; in this case, an IP router attached to or colocated with 275 the HC should provide the forwarding from upstream to downstream. 277 o All LIS members connected to the IEEE 802.14 subnetwork via an 278 IEEE 802.14 HC MUST be able to communicate via the IEEE 802.14 279 subnetwork to or beyond any downstream IEEE 802.14 station in the 280 LIS. 282 o A LIS MAY span more than one IEEE 802.14 subnetwork. In the case 283 of frame based, conventional Layer 2 bridging/switching MAY 284 interconnect more than one HC. In the case of ATM based, a 285 backend ATM network MAY interconnect more than one HC. 287 5.3 LIS Router Additional Configuration 289 Routers providing LIS functionality over the IEEE 802.14 subnetwork 290 MAY also support the ability to interconnect multiple LISs. Routers 291 that wish to provide interconnection of differing LISs MUST be able 292 to support multiple sets of parameters (one set for each connected 293 LIS) and be able to associate each set of parameters to a specific IP 294 network/subnet number. In addition, a router MAY be able to provide 295 this multiple LIS support with a single physical IEEE802.14 interface 296 with a different link address per LIS. 298 6. IP PACKET FORMAT 300 Implementations built using the IEEE 802.14 ATM cell based layer 301 services MUST support IEEE 802.2 LLC/SNAP encapsulation as described 302 in [2]. LLC/SNAP encapsulation is the default packet format for IP 303 datagrams running via IP over ATM networks. The default MTU of this 304 interface is 9180 octets. This memo recognizes that end-to-end 305 signaling within ATM may allow negotiation of encapsulation method or 306 MTU on a per-VC basis. 308 7. IP BROADCAST ADDRESS 310 The IEEE 802.14 downstream MAC PDU supports point-to-multipoint 311 addressing. For each LIS, the IP layer service support at the IEEE 312 802.14 HC MUST create a single downstream point-to-multipoint group 313 whose membership contains all IEEE 802.14 station participating in 314 that LIS. By default, all downstream IP datagrams whose destination 315 address specifies one of the four forms of IP broadcast addresses 316 (limited, directed, subnet directed, or all-subnets directed) [8] or 317 an IP multicast address MUST be sent to members of the LIS using this 318 MAC address group. 320 Note: By default, all upstream IP datagrams are sent from the IEEE 321 802.14 station to the HC on the single point-to-point connection. 323 Note: the above defaults do not preclude the use of additional 324 downstream point-to-point or point-to-multipoint, or additional 325 upstream point-to-point connections for handling of specific IP flows 326 for integrated-services or multicast distribution support; e.g., 327 mapping IP flows to specific additional connections. 329 In general, it is preferred that downstream data bandwidth resources 330 be used in an efficient manner. Therefore, IP over IEEE802.14 331 implementations SHOULD only send one copy of a packet downstream per 332 IP broadcast transmission or IP multicast transmission. 334 8. IP MULTICAST ADDRESS 336 The IEEE 802.14 downstream MAC service supports point-to-multipoint 337 addressing. MAC point-to-multipoint addresses can span LISs. 339 For efficiency reasons, a separate point-to-multipoint group MAY be 340 used to support downstream IP multicast datagram distribution. The 341 specific implementation is beyond the scope of this memo, however it 342 can be noted that single or multiple IP multicast groups MAY be 343 mapped to a MAC point-to-multipoint group subject to the abilities of 344 the IEEE 802.14 HC and participating stations. 346 Note: By default, all upstream IP datagrams are sent from the IEEE 347 802.14 station to the HC on the single point-to-point connection. 349 Note: the above defaults do not preclude the use of additional 350 downstream point-to-multipoint or additional upstream point-to-point 351 connections for handling of specific IP flows for integrated-services 352 or multicast distribution support; e.g., mapping IP flows to specific 353 additional connections. 355 It is preferred that downstream data bandwidth resources be used in 356 an efficient manner, therefore IP over IEEE 802.14 implementations 357 MUST only send one copy of a packet downstream per IP multicast 358 transmission. Specially, MAC point-to-multipoint groups used for IP 359 multicast datagram distribution may span LISs. 361 For example, there may be two LISs operating via an IEEE 802.14 362 subnetwork, LIS-1 and LIS-2. LIS1 may have station members ST-A, 363 ST-B, and ST-C. and LIS-2 may have station members ST-X, ST-Y, and 364 ST-Z. The Ethernet layer management services at the HC would have 365 created two point-to-multipoint groups PTM-1 and PTM-2 used for 366 default downstream broadcast and multicast transmission. The 367 membership of PTM-1 would be ST-A, ST-B, and ST-C. The membership of 368 PTM-2 would be ST-X, ST-Y, ST-Z. There may be another point-to- 369 multipoint group for distributing a specific IP multicast group, call 370 this PTM-3. The members of PTM-3 might be ST-B, ST-C, and ST-X 371 therefore PTM-3 spans LIS-1 and LIS-2. 373 The coupling of the IEEE 802.14 layer management services responsible 374 for group management with that of IP Internet Group Management 375 Protocol (IGMP) is TBD. 377 9. IP INTEGRATED SERVICES SPPORT 379 By default, the IEEE 802.14 service delivers IP traffic on a best 380 effort basis. 382 The underlying protocol of IEEE 802.14 is designed to support the ATM 383 service classes: Constant Bit Rate (CBR), real-time Variable Bit Rate 384 (rt-VBR), non-real-time Variable Bit Rate (nrt-VBR), Available Bit 385 Rate (ABR), and Unspecified Bit Rate (UBR), and their associated 386 Quality of Service requirements (delay, delay tolerance, cell loss 387 rate) subject to the characteristics of the downstream and upstream 388 channel rates. Mappings from IP integrated services to IP over ATM 389 can be exploited to provide traffic management and Quality of Service 390 (QoS) on a per IP flow basis, for unicast and multicast traffic. As 391 such, these capabilities are available for ATM cell-based access 392 Specifications for the support of integrated services and RSVP over 393 IEEE 802.14 are TBD. 395 10. FILTERING 397 The IEEE 802.14 system does not preclude the use of filtering for IP 398 and ARP protocol packets. Such filtering is TBD. 400 The IEEE 802.14 system permits filters to be placed in the upstream 401 and downstream at the ST and the HC and independently for point-to- 402 point and point-to-multipoint connections. In addition, filters may 403 be placed at the HC in the service function responsible for 404 forwarding packets from upstream to downstream. Such use of these 405 facilities is TBD. 407 11. Station Requirements 409 The IP over IEEE 802.14 station MUST be able to separately and 410 simultaneously reassemble or reconstruct packets for each point-to- 411 point or point-to-multipoint downstream connection being used for IP 412 LIS or IP Multicast services. 414 By default, all unicast, broadcast, and multicast communications from 415 an IP over IEEE802.14 station MUST be sent using the point-to-point 416 connection to the IEEE 802.14 HC. It is noted that the default 417 behavior MAY be modified in the future by providing additional 418 connections for IP traffic from the IEEE 802.14 station to the IEEE 419 802.14 HC. 421 Specifications for optional LIS forwarding requirements are TBD. 423 12. SECURITY 425 TBD. 427 13. MIB SPECIFICATION 429 The IEEE 802.14 MIB is TBD. 431 14. OPEN ISSUES 433 o ATM signaling support by IEEE 802.14 and specific HC 434 functionality in support of IP will be mentioned in a future 435 revision of this memo. 437 o IEEE 802.1D/p and Q extensions, including GARP will be mentioned 438 in a future revision of this memo. 440 o RSVP coupling to IEEE 802.14 layer management is TBD. 442 o IGMP coupling to IEEE 802.14 layer management is TBD. 444 o IETF Integrated Services support by IEEE 802.14 is TBD. 446 o May need to add comments about IP over Ethernet/RFC1483 447 implementations. 449 o The HC forwarding option results in routing intra-LIS. What 450 about subnet-directed broadcasts (blocked)? ARPs? Will the 451 headend proxy ARP for all stations? If the stations are members 452 of the same LIS, then they will try to talk directly and their 453 packets will have to be forced to the router (in frame mode, have 454 the headend proxy ARP for with the router's MAC for any LIS 455 members that are not local to that station). What about ATMARP 456 issues? ICMP redirects should be disabled from the router. Are 457 we assuming that members of an LIS may just be under the same 458 administrative control, and not not necessarily "friendly"? Like 459 an ISP subnet? This does give the administrator some extra 460 protection. 462 o In frame mode, what about multicast? Unicast packets sent to the 463 router will be routed back to the destination station, but 464 multicast assumes all stations can hear each other? Without a 465 specific broadcast facility upstream, do we have to build one for 466 multicast: receive multicast group membership, facilitate group 467 access control and forward multicast back downstream based on 468 this info? Or does 802.14 address this? For ATM mode would 469 something like MARS be needed? 471 What about NHRP (as opposed to ATM ARP)? 473 From Scott Brim: 475 The head end needs to be intelligent enough to do various 476 filtering at the PDU (not cell) level. Regardless of whether 477 it's used the code needs to be in there. This brings up two 478 questions -- tell me if I read it right: 480 * doesn't forwarding cells to the outside world (beyond the head 481 end) conflict with having frame-level intelligence? That is, 482 does the head end have to accumulate cells and reassemble frames 483 even if it's forwarding cells to the outside world (under any 484 conditions)? 486 * I can't tell if the head end is recommended to do IP forwarding 487 within the 802.14 LIS (there are 2 conflicting statements) but if 488 it doesn't, it still needs all the intelligence to examine 489 packets. Seems like a waste. Why isn't the head end either dumb 490 or smart? 492 15. REFERENCES 494 [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS 495 Service", RFC-1209, USC/Information Sciences Institute, March 496 1991. 498 [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation 499 Layer 5", RFC-1483, USC/Information Sciences Institute, July 500 1993. 502 [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - 503 Converting Network Addresses to 48.bit Ethernet Address for 504 Transmission on Ethernet Hardware", RFC-826, MIT, November 1982. 506 [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1340, USC/ 507 Information Sciences Institute, July 1992. 509 [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of 510 IP Datagrams over IEEE 802 Networks", RFC-1042, USC/Information 511 Sciences Institute, February 1988. 513 [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, 514 Geneva, 19-29 January 1993. 516 [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September 517 - 2 October 1992. 519 [8] Braden, R., "Requirements for Internet Hosts -- Communication 520 Layers", RFC-1122, USC/Information Sciences Institute, October 521 1989. 523 [9] ATM Forum, "ATM User-Network Interface (UNI) Specification 524 Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper 525 Saddle River, NJ, 07458, September, 1994. 527 [10] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, 528 USC/Information Sciences Institute, August 1989. 530 [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, 531 "Guidelines for OSI NSAP Allocation in the Internet", RFC-1237, 532 USC/Information Sciences Institute, July 1991. 534 [12] Bradely, T., and Brown, C., "Inverse Address Resolution 535 Protocol", RFC-1293, USC/Information Sciences Institute, January 536 1992. 538 [13] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol 539 Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 540 32-48, 1989. 542 [14] Knowles, S., "IESG Advice from Experience with Path MTU 543 Discovery, RFC-1435, IESG, March 1993. 545 [15] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, 546 Bucknell University, October 1993. 548 [16] Kent C., and J. Mogul, "Fragmentation Considered Harmful", 549 Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in 550 Computer Communications Technology, August 1987. 552 [17] Mogul, J., and S. Deering, "Path MTU Discovery", RFC-1191, 553 DECWRL, Stanford University, November 1990. 555 [18] Green, M., Luciani, J., White, K., Kuo, T., "Definitions of 556 Managed Objects for Classical IP and ARP over ATM Using SMIv2", 557 IETF, draft-ietf-ipatm-mib-01 (work in progress), February, 1996. 559 [19] ATM Forum, "ATM User-Network Interface (UNI) Specification 560 Version 4.0", ATM Forum specification afsig-0061.000, 561 ftp://ftp.atmforum.com/, July, 1996. 563 [20] IEEE 802 LAN/MAN, "IEEE 802.14 Draft 2 Revision 2", IEEE 802.14 564 Working Group work in progress, July, 1997. 566 [21] Hornig, C.., "A Standard for the Transmission for IP Datagrams 567 over Ethernet Networks", RFC-894, Symbolics Cambridge Research 568 Center, April, 1984. 570 16. AUTHOR 572 Mark Laubach 573 Com21, Inc. 574 750 Tasman Drive 575 Milpitas, CA 95035 577 Phone: 408.953.9175 578 FAX: 408.953.9299 579 EMail: laubach@com21.com