Internet DRAFT - draft-ietf-ipcdn-ipover802d14

draft-ietf-ipcdn-ipover802d14



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 03:37:37 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 25 Aug 1997 13:41:00 GMT
ETag: "2f523f-7c1c-34018b6c"
Accept-Ranges: bytes
Content-Length: 31772
Connection: close
Content-Type: text/plain



Network Working Group                                       Mark Laubach
INTERNET DRAFT                                               Com21, Inc.
Expires 21 February 1998
<draft-ietf-ipcdn-ipover802d14-00.txt>                    21 August 1997
Obsoletes: <draft-laubach-ip-over-802d14-00.txt>




            Logical IP Subnetworks over IEEE 802.14 Services


Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet-Drafts draft documents are valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Work In Progress

   This memo is work in progress in support of the activities of the IP
   over Cable Data Networks (ipcdn) Working Group of the IETF.  The IEEE
   802.14 working group has reached a layer of stability necessary for
   the activities the IETF ipcdn working group.  This draft should be
   considered as the initial work that will be updated over time in
   concert with IEEE 802.14 development. This memo will track IEEE
   802.14 progress with the goal of being complete when the IEEE 802.14
   work reaches sponsor ballot in the IEEE standards process.

   The IEEE 802.14 Cable-TV Access Method And Physical Layer
   Specification is work in progress in the IEEE 802 LAN/MAN standards
   committee.  At the time of this draft, the IEEE 802.14 will be
   released for internal working group review and comment ballot based
   on the Draft2 Revision 2 specification released from the July 1997
   IEEE 802.14 working group meeting.  Comments on Draft2 Revision2 will
   be due by the September 1997 IEEE 802.14 interim meeting.



Laubach                                                         [Page 1]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


Table of Contents

      1. ABSTRACT  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
      2. ACKNOWLEDGMENT  . . . . . . . . . . . . . . . . . . . . . . .  2
      3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . .  3
      4. INTRODUCTION  . . . . . . . . . . . . . . . . . . . . . . . .  3
      5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . .  6
      5.1  Background  . . . . . . . . . . . . . . . . . . . . . . . .  6
      5.2  LIS Configuration Requirements  . . . . . . . . . . . . . .  6
      5.3  LIS Router Additional Configuration . . . . . . . . . . . .  7
      6. IP PACKET FORMAT  . . . . . . . . . . . . . . . . . . . . . .  8
      7. IP BROADCAST ADDRESS  . . . . . . . . . . . . . . . . . . . .  8
      8. IP MULTICAST ADDRESS  . . . . . . . . . . . . . . . . . . . .  8
      9. IP INTEGRATED SERVICES SUPPORT  . . . . . . . . . . . . . . .  9
      10. FILTERING . . . .  . . . . . . . . . . . . . . . . . . . . . 10
      11  STATION REQUIREMENTS   . . . . . . . . . . . . . . . . . . . 10
      12. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 10
      13. MIB SPECIFICATION  . . . . . . . . . . . . . . . . . . . . . 11
      14. OPEN ISSUES  . . . . . . . . . . . . . . . . . . . . . . . . 11
      15. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 12
      16. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.  ABSTRACT

   This memo defines an initial application of classical IP and ARP in
   an IEEE 802.14 Community Access Television (CATV) Residential Access
   Network environment.  IEEE 802.14 services provide two independent
   link layer service interfaces which are available to support IP
   residential access networking services: traditional Ethernet bridging
   (via IEEE 802.1D layer services) and residential ATM networking
   services.

   In this memo, the term Logical IP Subnetwork (LIS) is defined to
   apply to Classical IP over ATM LIS's operating over IEEE 802.14
   services as well as traditional IP over Ethernet operating over IEEE
   802.14 services.

   The recommendations in this draft rely on existing IETF standards for
   the family of Classical IP and ARP over ATM (IPOA) services and for
   IP and ARP over Broadcast Ethernet networks.  The tree-based
   hierarchic nature of the IEEE 802.14 MAC subnetwork permits
   convenient extensions to Classical IPOA model for broadcast and
   multicast in the downstream direction of the CATV plant.

2.  ACKNOWLEDGMENT

   The author would like to thank the efforts of the IEEE 802.14 working
   group and the efforts of the IETF ipcdn working group.  Randy Frei



Laubach                                                         [Page 2]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   from Com21 provided early review of this memo and contributed to the
   open issues list.

3.  CONVENTIONS

   The following language conventions are used in the items of
   specification in this document:

   o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
       of the specification.

   o   SHOULD or RECOMMEND -- this item should generally be followed for
       all but exceptional circumstances.

   o   MAY or OPTIONAL -- the item is truly optional and may be followed
       or ignored according to the needs of the implementor.

4.  INTRODUCTION

   The goal of this specification is to allow compatible and
   interoperable implementations of Logical IP Subnetworks over IEEE
   802.14 services [20], including the transmission of IP datagrams and
   Address Resolution Protocol (ARP) requests (ARP or ATMARP) and
   replies.

   This memo specifies the default operational model which will always
   be available in IP over IEEE 802.14 implementations. Subsequent memos
   will build upon and refine this model, however, in the absence or
   failure of those extensions, operations will default to the
   specifications contained in this memo. Consequently, this memo will
   not reference these other extensions.

   The IEEE 802.14 subnetwork consists of a Head-end Controller (HC) and
   one or more stations (ST).  The HC and each station are 802.14
   entities. The HC is responsible for all aspects of packet processing,
   resource sharing, and management of the 802.14 Media Access Control
   (MAC) and Physical (PHY) functions.  A station is essentially a slave
   of the HC.

   The organization of the HC to each station is a strict rooted
   hierarchy: i.e., it is a two-level tree where the HC is the root and
   stations are the children.  In the downstream direction, a 802.14 MAC
   Protocol Data Unit (PDU) may be sent to an individual station
   (unicast) or a group of stations (multicast and broadcast).  In the
   upstream direction, all MAC PDUs (individual or group addressed) are
   sent from the station to the HC. The HC is active and originates and
   terminates all upstream MAC PDU flows; that is, the HC processes the
   MAC PDUs and does not merely repeat upstream MAC PDUs back on the



Laubach                                                         [Page 3]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   downstream for station to station communication.  The HC MAC layer
   service function determines whether information will be forwarded
   back on the downstream; e.g. similar to Ethernet bridge forwarding
   behavior.

   The specific format of the IEEE 802.14 MAC PDU is transparent to
   higher level services, e.g. IP datagrams, and therefore not of
   specific interest to this draft. However, it is useful to note that
   IEEE 802.14 HC and ST entities support an ATM format MAC PDU mode by
   default, with an optional variable length MAC PDU mode.  The choice
   of MAC PDU is vendor and then operator specified. The IEEE 802.14 MAC
   PDU is not presented to the IP layer.  For the purposes of protocol
   specification, IP may only access IEEE 802.14 services via one or two
   layer service interfaces: the ATM cell-based service interface or the
   802.2 (LLC) / 802.1D (bridge) MAC frame interface, hereafter called
   the Ethernet interface or Ethernet frame interface.  The selection of
   ATM cell MAC PDU mode or variable MAC PDU mode transparent to the
   Ethernet frame interface.

   Note: the term Ethernet interface is meant to convey that a frame
   based packet interface exists for the transmission of IP datagrams
   and ARP packets via the IEEE 802.14 link services.  The use of this
   term does not imply at this time that IEEE 802.14 provides an
   emulated Ethernet service between all stations, and between all
   stations and the HC.

   The IEEE 802.14 system employs a DES based link security system
   between the HC and all stations to protect the confidentiality of
   communications over the RF channels.  The specific mechanisms are
   beyond the scope of this memo, however it should be noted that 1) the
   security system is transparent to any higher layer protocol (i.e.
   IP, ATM, MPEG), 2) the security system does not preclude the use of
   IPSEC methods for providing additional security for residential IP,
   3) each MAC point-to-point connection is managed using different keys
   making it difficult to snoop on another station's unicast MAC
   traffic, and 4) each MAC point-to-multipoint connection is managed
   using different keys (stations only have keys for the MAC multicast
   groups of which they are a member).

   The IEEE 802.14 system enables comprehensive traffic management
   support and Quality of Service (QoS) support for ATM networking
   purpose.  As such, these mechanisms can be exploited to provide for
   IP integrated services support.

   The IEEE 802.14 system will provide support of IEEE802.1D/p, with
   future support for IEEE802.1/Q Virtual LAN (VLAN) extensions.  As
   such, these mechanisms can be exploited for IP integrated services
   support.



Laubach                                                         [Page 4]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   The characteristics for residential LISs using IEEE 802.14 ATM cell-
   based service interface are:

   o   RFC1577, RFC1626, and RFC1755 provide default IP over ATM LIS
       services.

   o   Other IETF standards can be used to extend these services; e..g
       MARS, integrated services over ATM, etc.

   o   More than one LIS may be in operation over the same 802.14
       subnetwork (MAC domain) .

   o   An IEEE 802.14 station may be a member of more than one LIS.

   o   Layer management services are available to the ATM layer for the
       purposes of managing point-to-point services on the downstream
       and upstream, and point-to-multipoint services on the downstream.

   o   Layer management services are available to the ATM layer for
       traffic management and Quality of Service (QoS) control.

   o   An IP router/gateway function may be colocated at the HC, e.g.
       in the case of an IEEE 802.14 "port card" in an IP router; or the
       router/gateway may be connected via an ATM network to the HC.
       This specification will not preclude either scenario.

   The characteristics for residential LISs using IEEE 802.14 Ethernet
   frame service interface are:

   o   Supports default IP and ARP over Ethernet services.

   o   Other IETF standards can be used to extend these services; e..g
       integrated services over 802.1D/p/Q.

   o   More than one LIS may be in operation over the same 802.14
       subnetwork (MAC domain) .

   o   An IEEE 802.14 station may be a member of more than one LIS.

   o   Layer management services are available to the frame service
       layer for the purposes of managing point-to-point services on the
       downstream and upstream, and point-to-multipoint services on the
       downstream.

   o   Layer management services are available to the frame service
       layer for traffic management and Quality of Service (QoS)
       control.




Laubach                                                         [Page 5]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   The scope of this specification covers implementation,
   interoperability, and operational extension issues for delivering
   Logical IP Subnetwork services via a residential access network
   implemented via the IEEE 802.14 standard.  Due to the flexibility
   provided by the IEEE 802.14 system features, other IETF standards
   will be relied on when appropriate to do so. For example the ATM
   nature of the IEEE 802.14 system suggests that the existing IETF
   classical IP over ATM family of specifications will apply in general,
   with specific differences outlined in this memo for reasons of
   operational efficiency or general IP over Cable Data Network issues.

   For the purposes of this memo, the IEEE 802.14 subnetwork is intended
   to support residential Logical IP Subnetwork services.  This
   specification does not preclude the operation of other multiple non-
   IP services which may be in simultaneous service over the IEEE 802.14
   subnetwork: e.g., voice or video integrated services.

5.  IP SUBNETWORK CONFIGURATION

5.1 Background

   The IEEE 802.14 subnetwork can support multiple simultaneously
   operating disjoint LISs over the same MAC domain. For each LIS a
   separate administrative entity configures its hosts and routers
   within the LIS. Each LIS operates and communicates independently of
   other LISs on the same IEEE 802.14 network.

   In the classical model, hosts communicate directly via IEEE 802.14 to
   other hosts within the same LIS using the appropriate address
   resolution service. In the case of the Ethernet frame service, the
   ARP service is the mechanism for resolving target IP addresses to
   target 48-bit IEEE MAC addresses. In the case of the ATM service, the
   ATMARP service is the mechanism for resolving target IP addresses to
   target ATM endpoint addresses.

   As LISs are independent, inter-LIS protocol translation or address
   resolution conversion services are beyond the scope of this memo.
   Communication to hosts located outside of a LIS is provided via an IP
   router.

   The scope of an Ethernet LIS can span beyond an individual IEEE
   802.14 subnetwork using traditional frame-based bridging; e.g., IEEE
   802.1D transparent bridging services.

   The scope of an ATM LIS can span beyond an individual IEEE 802.14
   subnetwork using conventional ATM networking.





Laubach                                                         [Page 6]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


5.2 Residential LIS Configuration Requirements

   The requirements for IP members  (hosts, routers) operating in an
   IEEE 802.14-based LIS are:

   o   All members of the LIS MUST have the same IP network/subnet
       number and address mask [8].

   o   All members within a ATM cell-based LIS are directly connected to
       the IEEE 802.14 subnetwork or to an ATM network connected to the
       IEEE 802.14 subnetwork.

   o   All members within an Ethernet based LIS are directly connected
       to the IEEE 802.14 subnetwork or to an IEEE 802.1 bridged network
       communicating with the IEEE 802.14 subnetwork.

   o   All members of a LIS MUST have a mechanism for resolving IP
       addresses to link addresses (ARP or ATMARP).

   o   All members of a LIS MUST have a mechanism for resolving link
       addresses to IP addresses via an inverse address resolution
       protocol (InARP or InATMARP).

   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.

   o   All LIS members connected to the IEEE 802.14 subnetwork via an
       IEEE 802.14 HC MUST be able to communicate via the IEEE 802.14
       subnetwork to or beyond any downstream IEEE 802.14 station in the
       LIS.

   o   A LIS MAY span more than one IEEE 802.14 subnetwork. In the case
       of frame based, conventional Layer 2 bridging/switching MAY
       interconnect more than one HC.  In the case of ATM based, a
       backend ATM network MAY interconnect more than one HC.

5.3 LIS Router Additional Configuration

   Routers providing LIS functionality over the IEEE 802.14 subnetwork
   MAY also support the ability to interconnect multiple LISs.  Routers
   that wish to provide interconnection of differing LISs MUST be able
   to support multiple sets of parameters (one set for each connected
   LIS) and be able to associate each set of parameters to a specific IP



Laubach                                                         [Page 7]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   network/subnet number. In addition, a router MAY be able to provide
   this multiple LIS support with a single physical IEEE802.14 interface
   with a different link address per LIS.

6.  IP PACKET FORMAT

   Implementations built using the IEEE 802.14 Ethernet frame layer
   services MUST support IP over Ethernet as described in [21].  The MTU
   of this interface is 1500 octets.

   Implementations built using the IEEE 802.14 ATM cell based layer
   services MUST support IEEE 802.2 LLC/SNAP encapsulation as described
   in [2].  LLC/SNAP encapsulation is the default packet format for IP
   datagrams running via IP over ATM networks. The default MTU of this
   interface is 9180 octets.  This memo recognizes that end-to-end
   signaling within ATM may allow negotiation of encapsulation method or
   MTU on a per-VC basis.

7.  IP BROADCAST ADDRESS

   The IEEE 802.14 downstream MAC PDU supports point-to-multipoint
   addressing.  For each LIS, the IP layer service support at the IEEE
   802.14 HC MUST create a single downstream point-to-multipoint group
   whose membership contains all IEEE 802.14 station participating in
   that LIS.  By default, all downstream IP datagrams whose destination
   address specifies one of the four forms of IP broadcast addresses
   (limited, directed, subnet directed, or all-subnets directed) [8] or
   an IP multicast address MUST be sent to members of the LIS using this
   MAC address group.

   Note: By default, all upstream IP datagrams are sent from the IEEE
   802.14 station to the HC on the single point-to-point connection.

   Note: the above defaults do not preclude the use of additional
   downstream point-to-point or point-to-multipoint, or additional
   upstream point-to-point connections for handling of specific IP flows
   for integrated-services or multicast distribution support; e.g.,
   mapping IP flows to specific additional connections.

   In general, it is preferred that downstream data bandwidth resources
   be used in an efficient manner. Therefore, IP over IEEE802.14
   implementations SHOULD only send one copy of a packet downstream per
   IP broadcast transmission or IP multicast transmission.








Laubach                                                         [Page 8]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


8.  IP MULTICAST ADDRESS

   The IEEE 802.14 downstream MAC service supports point-to-multipoint
   addressing.  MAC point-to-multipoint addresses can span LISs.

   For efficiency reasons, a separate point-to-multipoint group MAY be
   used to support downstream IP multicast datagram distribution. The
   specific implementation is beyond the scope of this memo, however it
   can be noted that single or multiple IP multicast groups MAY be
   mapped to a MAC point-to-multipoint group subject to the abilities of
   the IEEE 802.14 HC and participating stations.

   Note: By default, all upstream IP datagrams are sent from the IEEE
   802.14 station to the HC on the single point-to-point connection.

   Note: the above defaults do not preclude the use of additional
   downstream point-to-multipoint or additional upstream point-to-point
   connections for handling of specific IP flows for integrated-services
   or multicast distribution support; e.g., mapping IP flows to specific
   additional connections.

   It is preferred that downstream data bandwidth resources be used in
   an efficient manner, therefore IP over IEEE 802.14 implementations
   MUST only send one copy of a packet downstream per IP multicast
   transmission.  Specially, MAC point-to-multipoint groups used for IP
   multicast datagram distribution may span LISs.

   For example, there may be two LISs operating via an IEEE 802.14
   subnetwork, LIS-1 and LIS-2.  LIS1 may have station members ST-A, ST-
   B, and ST-C. and LIS-2 may have station members ST-X, ST-Y, and ST-Z.
   The Ethernet layer management services at the HC would have created
   two point-to-multipoint groups PTM-1 and PTM-2 used for default
   downstream broadcast and multicast transmission.  The membership of
   PTM-1 would be ST-A, ST-B, and ST-C.  The membership of PTM-2 would
   be ST-X, ST-Y, ST-Z.  There may be another point-to-multipoint group
   for distributing a specific IP multicast group, call this PTM-3.  The
   members of PTM-3 might be ST-B, ST-C, and ST-X therefore PTM-3 spans
   LIS-1 and LIS-2.

   The coupling of the IEEE 802.14 layer management services responsible
   for group management with that of IP Internet Group Management
   Protocol (IGMP) is TBD.

9.  IP INTEGRATED SERVICES SPPORT

   By default, the IEEE 802.14 service delivers IP traffic on a best
   effort basis.




Laubach                                                         [Page 9]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   The underlying protocol of IEEE 802.14 is designed to support the ATM
   service classes: Constant Bit Rate (CBR), real-time Variable Bit Rate
   (rt-VBR), non-real-time Variable Bit Rate (nrt-VBR), Available Bit
   Rate (ABR), and Unspecified Bit Rate (UBR), and their associated
   Quality of Service requirements (delay, delay tolerance, cell loss
   rate) subject to the characteristics of the downstream and upstream
   channel rates.  Mappings from IP integrated services to IP over ATM
   can be exploited to provide traffic management and Quality of Service
   (QoS) on a per IP flow basis, for unicast and multicast traffic.  As
   such, these capabilities are available for ATM cell-based access as
   well as Ethernet frame mode access.  Specifications for the support
   of integrated services and RSVP over IEEE 802.14 are TBD.

10.  FILTERING

   The IEEE 802.14 system does not preclude the use of filtering for IP
   and ARP protocol packets.  Such filtering is TBD.

   The IEEE 802.14 system permits filters to be placed in the upstream
   and downstream at the ST and the HC and independently for point-to-
   point and point-to-multipoint connections.  In addition, filters may
   be placed at the HC in the service function responsible for
   forwarding packets from upstream to downstream.  Such use of these
   facilities is TBD.


11.  Station Requirements

   The IP over IEEE 802.14 station MUST be able to separately and
   simultaneously reassemble or reconstruct packets for each point-to-
   point or point-to-multipoint downstream connection being used for IP
   LIS or IP Multicast services.

   By default, all unicast, broadcast, and multicast communications from
   an IP over IEEE802.14 station MUST be sent using the point-to-point
   connection to the IEEE 802.14 HC.  It is noted that the default
   behavior MAY be modified in the future by providing additional
   connections for IP traffic from the IEEE 802.14 station to the IEEE
   802.14 HC.

   Specifications for optional LIS forwarding requirements are TBD.

12.  SECURITY

   TBD.






Laubach                                                        [Page 10]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


13.  MIB SPECIFICATION

   The IEEE 802.14 MIB is TBD.

14.  OPEN ISSUES

   o   ATM signaling support by IEEE 802.14 and specific HC
       functionality in support of IP will be mentioned in a future
       revision of this memo.

   o   IEEE 802.1D/p and Q extensions, including GARP will be mentioned
       in a future revision of this memo.

   o   RSVP coupling to IEEE 802.14 layer management is TBD.

   o   IGMP coupling to IEEE 802.14 layer management is TBD.

   o   IETF Integrated Services support by IEEE 802.14 is TBD.

   o   It is ambiguous about whether IP members must be connected via
       ATM mode or Ethernet mode.  802.14 will support either mode.
       Also, whether a mixture of 802.14 capable LIS members and
       bridged/switched connected LIS members is allowed on a HC or all
       stations must be of one type or the other.

   o   The HC forwarding option results in routing intra-LIS.  What
       about subnet-directed broadcasts (blocked)? ARPs?  Will the
       headend proxy ARP for all stations?  If the stations are members
       of the same LIS, then they will try to talk directly and their
       packets will have to be forced to the router (in frame mode, have
       the headend proxy ARP for with the router's MAC for any LIS
       members that are not local to that station).   What about ATMARP
       issues?  ICMP redirects should be disabled from the router.  Are
       we assuming that members of an LIS may just be under the same
       administrative control, and not not necessarily "friendly"?  Like
       an ISP subnet?  This does give the administrator some extra
       protection.

   o   In frame mode, what about multicast?  Unicast packets sent to the
       router will be routed back to the destination station, but
       multicast assumes all stations can hear each other? Without a
       specific broadcast facility upstream, do we have to build one for
       multicast: receive multicast group membership, facilitate group
       access control and forward multicast back downstream based on
       this info?  Or does 802.14 address this?  For ATM mode would
       something like MARS be needed?

   What about NHRP (as opposed to ATM ARP)?



Laubach                                                        [Page 11]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   From Scott Brim:

       The head end needs to be intelligent enough to do various
       filtering at the PDU (not cell) level.  Regardless of whether
       it's used the code needs to be in there.  This brings up two
       questions -- tell me if I read it right:

       * doesn't forwarding cells to the outside world (beyond the head
       end) conflict with having frame-level intelligence?  That is,
       does the head end have to accumulate cells and reassemble frames
       even if it's forwarding cells to the outside world (under any
       conditions)?

       * I can't tell if the head end is recommended to do IP forwarding
       within the 802.14 LIS (there are 2 conflicting statements) but if
       it doesn't, it still needs all the intelligence to examine
       packets.  Seems like a waste.  Why isn't the head end either dumb
       or smart?


15. REFERENCES

   [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
       Service", RFC-1209, USC/Information Sciences Institute, March
       1991.

   [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5", RFC-1483, USC/Information Sciences Institute, July
       1993.

   [3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Addresses to 48.bit Ethernet Address for
       Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.

   [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1340, USC/
       Information Sciences Institute, July 1992.

   [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
       IP Datagrams over IEEE 802 Networks", RFC-1042, USC/Information
       Sciences Institute, February 1988.

   [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
       Geneva, 19-29 January 1993.

   [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
       - 2 October 1992.





Laubach                                                        [Page 12]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   [8] Braden, R., "Requirements for Internet Hosts -- Communication
       Layers", RFC-1122, USC/Information Sciences Institute, October
       1989.

   [9] ATM Forum, "ATM User-Network Interface (UNI) Specification
       Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper
       Saddle River, NJ, 07458, September, 1994.

   [10] Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
       USC/Information Sciences Institute, August 1989.

   [11] Colella, Richard, and Gardner, Ella, and Callon, Ross,
       "Guidelines for OSI NSAP Allocation in the Internet", RFC-1237,
       USC/Information Sciences Institute, July 1991.

   [12] Bradely, T., and Brown, C., "Inverse Address Resolution
       Protocol", RFC-1293, USC/Information Sciences Institute, January
       1992.

   [13] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
       Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp.
       32-48, 1989.

   [14] Knowles, S., "IESG Advice from Experience with Path MTU
       Discovery, RFC-1435, IESG, March 1993.

   [15] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
       Bucknell University, October 1993.

   [16] Kent C., and J. Mogul, "Fragmentation Considered Harmful",
       Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in
       Computer Communications Technology, August 1987.

   [17] Mogul, J., and S. Deering, "Path MTU Discovery", RFC-1191,
       DECWRL, Stanford University, November 1990.

   [18] Green, M., Luciani, J., White, K., Kuo, T., "Definitions of
       Managed Objects for Classical IP and ARP over ATM Using SMIv2",
       IETF, draft-ietf-ipatm-mib-01 (work in progress), February, 1996.

   [19] ATM Forum, "ATM User-Network Interface (UNI) Specification
       Version 4.0", ATM Forum specification afsig-0061.000,
       ftp://ftp.atmforum.com/, July, 1996.

   [20] IEEE 802 LAN/MAN, "IEEE 802.14 Draft 2 Revision 2", IEEE 802.14
       Working Group work in progress, July, 1997.





Laubach                                                        [Page 13]

DRAFT       Logical IP Subnetworks over IEEE 802.14 Services August 1997


   [21] Hornig, C.., "A Standard for the Transmission for IP Datagrams
       over Ethernet Networks", RFC-894, Symbolics Cambridge Research
       Center, April, 1984.

16. AUTHOR

   Mark Laubach
   Com21, Inc.
   750 Tasman Drive
   Milpitas, CA 95035

   Phone: 408.953.9175
   FAX:   408.953.9299
   EMail: laubach@com21.com





































Laubach                                                        [Page 14]