home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipcdn-ip-over-mcns-00.txt < prev    next >
Text File  |  1997-08-29  |  23KB  |  661 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. White
  8. INTERNET DRAFT                                     Bay Networks, Inc
  9. Expires 26 February 1998
  10.  
  11. <draft-ietf-ipcdn-ip-over-mcns-00.txt>                26 August 1997
  12.  
  13.  
  14.  
  15.           Logical IP Subnetworks over MCNS Data Link Services
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet-Draft.  Internet Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups. Note that other groups may also distribute
  22.    working documents as Internet Drafts.
  23.  
  24.    Internet-Drafts draft documents are valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time. It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as "work in progress."
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  31.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  32.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33.    ftp.isi.edu (US West Coast).
  34.  
  35. Work In Progress
  36.  
  37.    This memo is work in progress in support of the activities of the IP
  38.    over Cable Data Networks (ipcdn) Working Group of the IETF.
  39.  
  40. Table of Contents
  41.  
  42.    1. ABSTRACT  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  43.    2. ACKNOWLEDGMENT  . . . . . . . . . . . . . . . . . . . . . . .  2
  44.    3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . .  2
  45.    4. INTRODUCTION  . . . . . . . . . . . . . . . . . . . . . . . .  3
  46.    5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . .  5
  47.    5.1  Background  . . . . . . . . . . . . . . . . . . . . . . . .  5
  48.    5.2  LIS Configuration Requirements  . . . . . . . . . . . . . .  5
  49.    5.3  LIS Router Additional Configuration . . . . . . . . . . . .  6
  50.    6. IP PACKET FORMAT  . . . . . . . . . . . . . . . . . . . . . .  6
  51.    7. IP BROADCAST ADDRESS  . . . . . . . . . . . . . . . . . . . .  7
  52.    8. IP MULTICAST ADDRESS  . . . . . . . . . . . . . . . . . . . .  7
  53.    9. IP INTEGRATED SERVICES SUPPORT  . . . . . . . . . . . . . . .  8
  54.    10. FILTERING . . . .  . . . . . . . . . . . . . . . . . . . . .  9
  55.  
  56.  
  57.  
  58. White                                                          [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  65.  
  66.  
  67.    11  CM REQUIREMENTS .  . . . . . . . . . . . . . . . . . . . . .  9
  68.    12. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  69.    13. MIB SPECIFICATION  . . . . . . . . . . . . . . . . . . . . . 10
  70.    14. OPEN ISSUES  . . . . . . . . . . . . . . . . . . . . . . . . 10
  71.    15. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 10
  72.    16. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  73.  
  74. 1. ABSTRACT
  75.  
  76.    This memo defines an initial application of IP and ARP in an MCNS
  77.    Community Access Television (CATV) Residential Access Network
  78.    environment where the cable system is used for bi-directional data
  79.    transfer. The MCNS network provides a traditional Ethernet or 802.2
  80.    link layer service between a cable system head end and the customer
  81.    premises using the cable television system infrastructure.  This
  82.    interface is available via IEEE 802.1D layer services to support IP
  83.    residential access networking services.
  84.  
  85.    In this memo, the term Logical IP Subnetwork (LIS) is defined to
  86.    apply to traditional IP over Ethernet operating over MCNS services.
  87.  
  88.    The recommendations in this draft rely on existing IETF standards for
  89.    IP and ARP over Broadcast Ethernet networks.
  90.  
  91. 2. ACKNOWLEDGMENT
  92.  
  93.    The author would like to thank the efforts of the MCNS working group
  94.    and the efforts of the IETF ipcdn working group.  The basis of this
  95.    document was shamelessly stolen from Mark Laubach's draft for IP over
  96.    802.14. Wilson Sawyer of Bay Networks provided valuable early review
  97.    of the document.
  98.  
  99. 3. CONVENTIONS
  100.  
  101.    The following language conventions are used in the items of
  102.    specification in this document:
  103.  
  104.    o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
  105.        of the specification.
  106.  
  107.    o   SHOULD or RECOMMEND -- this item should generally be followed for
  108.        all but exceptional circumstances.
  109.  
  110.    o   MAY or OPTIONAL -- the item is truly optional and may be followed
  111.        or ignored according to the needs of the implementor.
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118. White                                                          [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  125.  
  126.  
  127. 4. INTRODUCTION
  128.  
  129.    The goal of this specification is to allow compatible and
  130.    interoperable implementations of Logical IP Subnetworks over MCNS
  131.    services [MCNS1->4], including the transmission of IP datagrams and
  132.    Address Resolution Protocol (ARP) requests and replies.
  133.  
  134.    It refers only to an MCNS network based on a two way capable cable
  135.    plant [MCNS4] in which  the cable system is used for data transport
  136.    in both upstream and downstream directions.  MCNS networks using non
  137.    cable system based return paths such as the telephone network are not
  138.    considered.
  139.  
  140.    This memo specifies the default operational model which will always
  141.    be available in IP over MCNS implementations. Subsequent memos will
  142.    build upon and refine this model, however, in the absence or failure
  143.    of those extensions, operations will default to the specifications
  144.    contained in this memo. Consequently, this memo will not reference
  145.    these other extensions.
  146.  
  147.    The MCNS subnetwork consists of a Cable Modem Termination System
  148.    (CMTS) typically located at the cable system head end and one or more
  149.    cable modems (CM).  The CMTS and each CM are MCNS entities. The CMTS
  150.    is responsible for all aspects of packet processing, resource
  151.    sharing, and management of the MCNS Media Access Control (MAC) and
  152.    Physical (PHY) functions.  A cable modem is essentially a slave of
  153.    the CMTS.
  154.  
  155.    The organization of the CMTS to each CM is a strict rooted hierarchy:
  156.    i.e., it is a two-level tree where the CMTS is the root and CM's are
  157.    the children.  In the downstream direction, a MCNS MAC Protocol Data
  158.    Unit (PDU) may be sent to an individual CM (unicast) or a group of
  159.    CM's (multicast and broadcast).  In the upstream direction, all MAC
  160.    PDUs (individual or group addressed) are sent from the CM to the
  161.    CMTS.
  162.  
  163.    The CMTS is active and originates and terminates all upstream MAC PDU
  164.    flows; that is, the CMTS processes the MAC PDUs and does not merely
  165.    repeat upstream MAC PDUs back on the downstream for station to
  166.    station communication.  The CMTS MAC layer service function
  167.    determines whether information will be forwarded back on the
  168.    downstream as defined in [MCNS4].  This may be based on data-link-
  169.    layer (bridging) semantics, network-layer (routing) semantics or some
  170.    combination of the two.
  171.  
  172.    The specific format of the MCNS MAC PDU is transparent to higher
  173.    level services, e.g. IP datagrams, and therefore not of specific
  174.    interest to this draft. However, it is useful to note that MCNS CMTS
  175.  
  176.  
  177.  
  178. White                                                          [Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  185.  
  186.  
  187.    and CM entities support a variable length MAC PDU which encapsulates
  188.    an Ethernet frame for transmission on the CATV network.  The MCNS MAC
  189.    PDU is not presented to the IP layer.  For the purposes of protocol
  190.    specification, IP may only access MCNS services via the 802.2 (LLC) /
  191.    802.1D (bridge) MAC frame interface, hereafter called the Ethernet
  192.    interface or Ethernet frame interface.
  193.  
  194.    Note: the MCNS Ethernet interface provides
  195.  
  196.    1) A frame based packet interface for the transmission of IP
  197.    datagrams and ARP packets via the MCNS link services.
  198.  
  199.    2) An emulated Ethernet service between all CM's and the CMTS.
  200.  
  201.    3) Subject to CMTS forwarding rules a bridged Ethernet service
  202.    between all CM's.
  203.  
  204.    The MCNS system employs a link layer encryption mechanism to provide
  205.    basic data privacy.  This is transparent to higher layer services.
  206.  
  207.    Basic traffic management support and Quality of Service (QoS) support
  208.    is provided by the MCNS system.  These mechanisms can be exploited to
  209.    provide for IP integrated services support.
  210.  
  211.    The MCNS system specifications provide options to support
  212.    IEEE802.1D/p, and IEEE802.1Q Virtual LAN (VLAN) extensions. These
  213.    mechanisms may be used to facilitate support for IP integrated
  214.    services.
  215.  
  216.  
  217.    The characteristics for residential LISs using MCNS Ethernet frame
  218.    service interface are:
  219.  
  220.    o   Supports default IP and ARP over Ethernet services.
  221.  
  222.    o   Other IETF standards can be used to extend these services; e.g.
  223.        integrated services over 802.1D/p/Q.
  224.  
  225.    o   More than one LIS may be in operation over the same MCNS
  226.        subnetwork (MAC domain) .
  227.  
  228.    o   An MCNS host system may be a member of more than one LIS.
  229.  
  230.    o   Layer management services are available to the frame service
  231.        layer for the purposes of managing point-to-point services on the
  232.        downstream and upstream, and point-to-multipoint services on the
  233.        downstream.
  234.  
  235.  
  236.  
  237.  
  238. White                                                          [Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  245.  
  246.  
  247.    o   Layer management services are available to the frame service
  248.        layer for traffic management and Quality of Service (QoS)
  249.        control.
  250.  
  251.  
  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 MCNS standard.  Due to the flexibility provided
  256.    by the MCNS system features, other IETF standards will be relied on
  257.    when appropriate to do so.
  258.  
  259.    For the purposes of this memo, the MCNS subnetwork is intended to
  260.    support residential Logical IP Subnetwork services.  This
  261.    specification does not preclude the operation of other multiple non-
  262.    IP services which may be in simultaneous service over the MCNS
  263.    subnetwork: e.g., voice or video integrated services.
  264.  
  265. 5. IP SUBNETWORK CONFIGURATION
  266.  
  267.  5.1 Background
  268.  
  269.    The MCNS subnetwork can support multiple simultaneously operating
  270.    disjoint LISs over the same MAC domain. For each LIS a separate
  271.    administrative entity configures its hosts and routers within the
  272.    LIS. Each LIS operates and communicates independently of other LISs
  273.    on the same MCNS network.
  274.  
  275.    In the classical model, hosts communicate directly via MCNS to other
  276.    hosts within the same LIS using the appropriate address resolution
  277.    service. In this case the ARP service is the mechanism for resolving
  278.    target IP addresses to target 48-bit IEEE MAC addresses.
  279.  
  280.    As LISs are independent, inter-LIS protocol translation or address
  281.    resolution conversion services are beyond the scope of this memo.
  282.    Communication to hosts located outside of a LIS is provided via an IP
  283.    router.
  284.  
  285.    The scope of an Ethernet LIS can span beyond an individual MCNS
  286.    subnetwork using traditional frame-based bridging; e.g., IEEE 802.1D
  287.    transparent bridging services.
  288.  
  289.  5.2 Residential LIS Configuration Requirements
  290.  
  291.    The requirements for IP members  (hosts, routers) operating in an
  292.    MCNS-based LIS are:
  293.  
  294.    o   All members of the LIS MUST have the same IP network/subnet
  295.  
  296.  
  297.  
  298. White                                                          [Page 5]
  299.  
  300.  
  301.  
  302.  
  303.  
  304. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  305.  
  306.  
  307.        number and address mask [IP4].
  308.  
  309.    o   All members are directly connected
  310.        to the MCNS subnetwork or to an IEEE 802.1 bridged network
  311.        communicating with the MCNS subnetwork.
  312.  
  313.    o   All members of a LIS MUST use ARP as the mechanism for
  314.        resolving IP addresses to link addresses.
  315.  
  316.    o   All LIS members connected to the MCNS subnetwork via an
  317.        MCNS CM MUST be able to communicate via the MCNS
  318.        subnetwork to or beyond the MCNS CMTS.
  319.        The MCNS CMTS may be configured to not forward upstream
  320.        communications from one station to another downstream station
  321.        in the LIS; in this case, an IP router attached to or
  322.        colocated with the CMTS should provide the forwarding from
  323.        upstream to downstream.
  324.  
  325.    o   All LIS members connected to the MCNS subnetwork via an
  326.        MCNS CMTS MUST be able to communicate via the MCNS
  327.        subnetwork to or beyond any downstream MCNS station in the
  328.        LIS.
  329.  
  330.    o   A LIS MAY span more than one MCNS subnetwork.
  331.        Conventional Layer 2 bridging/switching MAY
  332.        interconnect more than one CMTS.
  333.  
  334.  5.3 LIS Router Additional Configuration
  335.  
  336.    Routers providing LIS functionality over the MCNS subnetwork MAY also
  337.    support the ability to interconnect multiple LISs.  Routers that wish
  338.    to provide interconnection of differing LISs MUST be able to support
  339.    multiple sets of parameters (one set for each connected LIS) and be
  340.    able to associate each set of parameters to a specific IP
  341.    network/subnet number. In addition, a router MAY be able to provide
  342.    this multiple LIS support with a single physical MCNS interface with
  343.    a different link address per LIS.
  344.  
  345. 6. IP PACKET FORMAT
  346.  
  347.    Implementations built using the MCNS data link layer services MUST
  348.    support IP over Ethernet as described in [IP1].  The MTU of this
  349.    interface is 1500 octets.
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358. White                                                          [Page 6]
  359.  
  360.  
  361.  
  362.  
  363.  
  364. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  365.  
  366.  
  367. 7. IP BROADCAST ADDRESS
  368.  
  369.    The MCNS downstream MAC PDU supports point-to-multipoint addressing.
  370.    For each LIS, the IP layer service support at the MCNS CMTS MUST
  371.    create a single downstream point-to-multipoint group whose membership
  372.    contains all MCNS CM's participating in that LIS.  By default, all
  373.    downstream IP datagrams whose destination address specifies one of
  374.    the four forms of IP broadcast addresses mited, directed, subnet
  375.    directed, or all-subnets directed) [IP4] or an IP multicast address
  376.    MUST be sent to members of the LIS using this MAC address group.
  377.  
  378.    Note: By default, all upstream IP datagrams are sent from the MCNS CM
  379.    to the CMTS on the single point-to-point connection.
  380.  
  381.    Note: the above defaults do not preclude the use of additional
  382.    downstream point-to-point or point-to-multipoint, or additional
  383.    upstream point-to-point connections for handling of specific IP flows
  384.    for integrated-services or multicast distribution support; e.g.,
  385.    mapping IP flows to specific additional connections.
  386.  
  387.    In general, it is preferred that downstream data bandwidth resources
  388.    be used in an efficient manner. Therefore, IP over MCNS
  389.    implementations SHOULD only send one copy of a packet downstream per
  390.    IP broadcast transmission or IP multicast transmission.
  391.  
  392.  
  393.  
  394.  
  395. 8. IP MULTICAST ADDRESS
  396.  
  397.    The MCNS downstream MAC service supports point-to-multipoint
  398.    addressing.  MAC point-to-multipoint addresses can span LISs.
  399.  
  400.    For efficiency reasons, a separate point-to-multipoint group MAY be
  401.    used to support downstream IP multicast datagram distribution. The
  402.    specific implementation is beyond the scope of this memo, however it
  403.    can be noted that single or multiple IP multicast groups MAY be
  404.    mapped to a MAC point-to-multipoint group subject to the abilities of
  405.    the MCNS CMTS and participating CM's.
  406.  
  407.    Note: By default, all upstream IP datagrams are sent from the MCNS CM
  408.    to the CMTS on the single point-to-point connection.
  409.  
  410.    Note: the above defaults do not preclude the use of additional
  411.    downstream point-to-multipoint or additional upstream point-to-point
  412.    connections for handling of specific IP flows for integrated-services
  413.    or multicast distribution support; e.g., mapping IP flows to specific
  414.    additional connections.
  415.  
  416.  
  417.  
  418. White                                                          [Page 7]
  419.  
  420.  
  421.  
  422.  
  423.  
  424. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  425.  
  426.  
  427.    It is preferred that downstream data bandwidth resources be used in
  428.    an efficient manner, therefore IP over MCNS implementations MUST only
  429.    send one copy of a packet downstream per IP multicast transmission.
  430.    Specially, MAC point-to-multipoint groups used for IP multicast
  431.    datagram distribution may span LISs.
  432.  
  433.    For example, there may be two LISs operating via an MCNS subnetwork,
  434.    LIS-1 and LIS-2.  LIS1 may have station members ST-A, ST- B, and ST-
  435.    C. and LIS-2 may have station members ST-X, ST-Y, and ST-Z.  The
  436.    Ethernet layer management services at the CMTS would have created two
  437.    point-to-multipoint groups PTM-1 and PTM-2 used for default
  438.    downstream broadcast and multicast transmission.  The membership of
  439.    PTM-1 would be ST-A, ST-B, and ST-C.  The membership of PTM-2 would
  440.    be ST-X, ST-Y, ST-Z.  There may be another point-to-multipoint group
  441.    for distributing a specific IP multicast group, call this PTM-3.  The
  442.    members of PTM-3 might be ST-B, ST-C, and ST-X therefore PTM-3 spans
  443.    LIS-1 and LIS-2.
  444.  
  445.    The coupling of the MCNS layer management services responsible for
  446.    group management with that of IP Internet Group Management Protocol
  447.    (IGMP) is TBD.
  448.  
  449. 9. IP INTEGRATED SERVICES SUPPORT
  450.  
  451.    By default, the MCNS service delivers IP traffic on a best effort
  452.    basis.
  453.  
  454.    The underlying protocol of MCNS is designed to support multiple
  455.    service classes with their associated Quality of Service requirements
  456.    (maximum data rate, guaranteed data rate, priority) subject to the
  457.    characteristics of the downstream and upstream channel rates.
  458.    Mappings from IP integrated services to IP over MCNS can be exploited
  459.    to provide traffic management and Quality of Service (QoS) on a per
  460.    IP flow basis, for unicast and multicast traffic.  As such, these
  461.    capabilities are available for the support of integrated services and
  462.    RSVP over MCNS.
  463.  
  464.    The MCNS MAC protocol contains the concept of Service IDs which
  465.    provide both device identification and quality-of-service management.
  466.    A Service ID defines a particular mapping between a CM and the CMTS.
  467.    This mapping is the basis on which bandwidth is allocated to the CM
  468.    by the CMTS and hence by which quality of service is implemented.
  469.  
  470.    The CMTS MAY assign one or more Service IDs (SIDs) to each CM,
  471.    corresponding to the classes of service required by the CM. This
  472.    mapping MUST be negotiated between the CMTS and the CM during CM
  473.    registration.
  474.  
  475.  
  476.  
  477.  
  478. White                                                          [Page 8]
  479.  
  480.  
  481.  
  482.  
  483.  
  484. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  485.  
  486.  
  487.    In a basic CM implementation a single Service ID MAY be used to offer
  488.    best-effort IP service. However, the Service ID concept allows for
  489.    CMs to be developed with support for multiple service classes. This
  490.    allows for a service ID to be provided for each "data flow" on which
  491.    protocols such as RSVP and RTP are based.
  492.  
  493.    The mechanism to achieve this is TBD.
  494.  
  495. 10. FILTERING
  496.  
  497.    The MCNS system provides for the use of filtering for IP and ARP
  498.    protocol packets.  This filtering is available for use by the network
  499.    operator or the end user (subject to the operator's policy).
  500.  
  501.    The MCNS system permits filters to be placed in the upstream and
  502.    downstream at the CM and the CMTS and independently for point-to-
  503.    point and point-to-multipoint connections.  In addition, filters may
  504.    be placed at the CMTS in the service function responsible for
  505.    forwarding packets from upstream to downstream.
  506.  
  507.  
  508. 11. CM REQUIREMENTS
  509.  
  510.    The IP over MCNS cable modem MUST be able to separately and
  511.    simultaneously reassemble or reconstruct packets for each point-to-
  512.    point or point-to-multipoint downstream connection being used for IP
  513.    LIS or IP Multicast services.
  514.  
  515.  
  516.    By default, all unicast, broadcast, and multicast communications from
  517.    an IP over MCNS CM MUST be sent using the point-to-point connection
  518.    to the MCNS CMTS.  It is noted that the default behavior MAY be
  519.    modified in the future by providing additional connections for IP
  520.    traffic from the CM to the CMTS.
  521.  
  522.  
  523. 12. SECURITY
  524.  
  525.    The MCNS system employs a DES based link security system between the
  526.    CMTS and all CM's to protect the confidentiality of communications
  527.    over the RF channels.  The specific mechanisms are beyond the scope
  528.    of this memo, however it should be noted that
  529.  
  530.    1) the security system is transparent to any higher layer protocol
  531.    (including IP).
  532.  
  533.    2) the security system does not preclude the use of IPSEC methods for
  534.    providing additional security.
  535.  
  536.  
  537.  
  538. White                                                          [Page 9]
  539.  
  540.  
  541.  
  542.  
  543.  
  544. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  545.  
  546.  
  547.    3) each MAC point-to-point connection is managed using different keys
  548.    making it difficult to snoop on another station's unicast MAC
  549.    traffic.
  550.  
  551.    4) each MAC point-to-multipoint connection is managed using different
  552.    keys (stations only have keys for the MAC multicast groups of which
  553.    they are a member).
  554.  
  555. 13. MIB SPECIFICATION
  556.  
  557.    TBD.
  558.  
  559. 14. OPEN ISSUES
  560.  
  561.  
  562.    o   IEEE 802.1D/p and Q extensions, including GARP will be mentioned
  563.        in a future revision of this memo.
  564.  
  565.    o   RSVP coupling to MCNS service id is TBD.
  566.  
  567.    o   IGMP coupling to MCNS layer management is TBD.
  568.  
  569. 15. REFERENCES
  570.  
  571.  
  572.    [MCNS1] MCNS Data Over Cable Service Interface Specification
  573.            Request for Proposals, December 11, 1995.
  574.  
  575.    [MCNS2] MCNS Cable Modem Termination System
  576.            - Network-Side Interface Specification
  577.            SP-CMTS-NSID04-960409 (CMTS-NSI), April 9, 1996.
  578.  
  579.    [MCNS3] MCNS Cable Modem to Customer Premise Equipment Interface
  580.            Specification SP-CMCID04-960409 (CMCI), April 9, 1996
  581.  
  582.    [MCNS4] MCNS Radio Frequency Interface
  583.            Specification SP-RFII01-970326, March 26, 1997
  584.  
  585.  
  586.    [IP1] Hornig, C.., "A Standard for the Transmission for IP Datagrams
  587.          over Ethernet Networks", RFC-894, Symbolics Cambridge Research
  588.          Center, April, 1984.
  589.  
  590.    [IP2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  591.          Converting Network Addresses to 48.bit Ethernet Address for
  592.          Transmission on Ethernet Hardware",
  593.          RFC-826, MIT, November 1982.
  594.  
  595.  
  596.  
  597.  
  598. White                                                         [Page 10]
  599.  
  600.  
  601.  
  602.  
  603.  
  604. DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997
  605.  
  606.  
  607.    [IP3] Postel, J., and Reynolds, J., "A Standard for the Transmission
  608.          of IP Datagrams over IEEE 802 Networks", RFC-1042,
  609.          USC/Information Sciences Institute, February 1988.
  610.  
  611.    [IP4] Braden, R., "Requirements for Internet Hosts -- Communication
  612.          Layers", RFC-1122, USC/Information Sciences Institute, October
  613.          1989.
  614.  
  615.    [IP5] Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
  616.          USC/Information Sciences Institute, August 1989.
  617.  
  618. 16. AUTHOR
  619.  
  620.    Gerry White
  621.    Broadband Technology Division
  622.    Bay Networks, Inc.
  623.    200 Bulfinch Drive
  624.    Andover, MA 01810
  625.  
  626.    Phone: 508.692.1600
  627.    FAX:   508.692.3200
  628.    EMail: gwhite@baynetworks.com
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658. White                                                         [Page 11]
  659.  
  660.  
  661.