home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / MISC / MERIT / 1991 / 91_175.TXT < prev    next >
Encoding:
Text File  |  1991-05-23  |  18.1 KB  |  435 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      D. Piscitello
  8. Request for Comments: 1209                                   J. Lawrence
  9.                                             Bell Communications Research
  10.                                                               March 1991
  11.  
  12.  
  13.          The Transmission of IP Datagrams over the SMDS Service
  14.  
  15. Status of this Memo
  16.  
  17.    This memo defines a protocol for the transmission of IP and ARP
  18.    packets over a Switched Multi-megabit Data Service Network configured
  19.    as a logical IP subnetwork.  This RFC specifies an IAB standards
  20.    track protocol for the Internet community, and requests discussion
  21.    and suggestions for improvements.  Please refer to the current
  22.    edition of the "IAB Official Protocol Standards" for the
  23.    standardization state and status of this protocol.  Distribution of
  24.    this memo is unlimited.
  25.  
  26. Abstract
  27.  
  28.    This memo describes an initial use of IP and ARP in an SMDS service
  29.    environment configured as a logical IP subnetwork, LIS (described
  30.    below).  The encapsulation method used is described, as well as
  31.    various service-specific issues.  This memo does not preclude
  32.    subsequent treatment of the SMDS Service in configurations other than
  33.    LIS; specifically, public or inter-company, inter-enterprise
  34.    configurations may be treated differently and will be described in
  35.    future documents.  This document considers only directly connected IP
  36.    end-stations or routers; issues raised by MAC level bridging are
  37.    beyond the scope of this paper.
  38.  
  39. Acknowledgment
  40.  
  41.    This memo draws heavily in both concept and text from [4], written by
  42.    Jon Postel and Joyce K. Reynolds of ISI and [5], written by David
  43.    Katz of Merit, Inc.  The authors would also like to acknowledge the
  44.    contributions of the IP Over SMDS Service working group of the
  45.    Internet Engineering Task Force.
  46.  
  47. Conventions
  48.  
  49.    The following language conventions are used in the items of
  50.    specification in this document:
  51.  
  52.       o MUST, SHALL, or MANDATORY -- the item is an absolute
  53.         requirement of the specification.
  54.  
  55.  
  56.  
  57.  
  58. IP over SMDS Working Group                                      [Page 1]
  59.  
  60.  
  61. RFC 1209            IP and ARP over the SMDS Service          March 1991
  62.  
  63.  
  64.       o SHOULD or RECOMMENDED -- the item should generally be followed
  65.         for all but exceptional circumstances.
  66.  
  67.       o MAY or OPTIONAL -- the item is truly optional and may be
  68.         followed or ignored according to the needs of the implementor.
  69.  
  70. Introduction
  71.  
  72.    The goal of this specification is to allow compatible and
  73.    interoperable implementations for transmitting IP datagrams and ARP
  74.    requests and replies.
  75.  
  76.    The characteristics of the SMDS Service and the SMDS Interface
  77.    Protocol (SIP) are presented in [3], [6], and in [7].  Briefly, the
  78.    SMDS Service is a connectionless, public, packet-switched data
  79.    service.  The operation and features of the SMDS Service are similar
  80.    to those found in high-speed data networks such as LANs:
  81.  
  82.       o The SMDS Service provides a datagram packet transfer, where each
  83.         data unit is handled and switched separately without the prior
  84.         establishment of a network connection.
  85.  
  86.       o The SMDS Service exhibits high throughput and low delay, and
  87.         provides the transparent transport and delivery of up to 9188
  88.         octets of user information in a single transmission.
  89.  
  90.       o No explicit flow control mechanisms are provided; instead, the
  91.         rate of information transfer on the access paths is controlled
  92.         both in the subscriber-to-network direction and in the network-
  93.         to-subscriber direction through the use of an access class
  94.         enforcement mechanism.
  95.  
  96.       o Both individually and group-addressed (multicast) packets can
  97.         be transferred.
  98.  
  99.       o In addition to these LAN-like features, a set of addressing-
  100.         related service features (source address validation, source and
  101.         destination address screening) are provided to enable a
  102.         subscriber or set of subscribers to create a logical private
  103.         network, or closed user group, over the SMDS Service.  The
  104.         access control provided by the closed user group mechanism is
  105.         supplied by the SMDS provider according to the specifications
  106.         stated in [3].
  107.  
  108.       o SMDS addresses are 60 bits plus a 4 bit Address Type.  The
  109.         Address Type subfield occupies the 4 most significant bits of
  110.         the destination and source address fields of the SIP Level 3
  111.         Protocol Data Unit (PDU).  It contains the value 1100 to
  112.  
  113.  
  114.  
  115. IP over SMDS Working Group                                      [Page 2]
  116.  
  117.  
  118. RFC 1209            IP and ARP over the SMDS Service          March 1991
  119.  
  120.  
  121.         indicate an individual address and the value 1110 for a 60-bit
  122.         group address.
  123.  
  124.    The SMDS Interface Protocol is based on the IEEE Standard 802.6,
  125.    Distributed Queue Dual Bus (DQDB) Connectionless MAC protocol [8].
  126.    The SMDS service layer corresponds to the IEEE 802 MAC sublayer.  The
  127.    remainder of the Data Link Service is provided by the IEEE 802.2
  128.    Logical Link Control (LLC) service [9].  The resulting stack of
  129.    services is illustrated in Figure 1:
  130.  
  131.                            +--------------------+
  132.                            |      IP/ARP        |
  133.                            +--------------------+
  134.                            |IEEE 802.2 LLC/SNAP |
  135.                            +--------------------+
  136.                            | SIP LEVEL 3 (MAC)  |
  137.                            +--------------------+
  138.                            | SIP LEVELS 1 & 2   |
  139.                            +--------------------+
  140.  
  141.             Figure 1.  Protocol stack for IP over SMDS Service
  142.  
  143.    This memo describes an initial use of IP and ARP in an SMDS Service
  144.    environment configured as a logical IP subnetwork (described below).
  145.    It does not preclude subsequent treatment of SMDS Service in
  146.    configurations other than logical IP subnetworks; specifically,
  147.    public or inter-company, inter-enterprise configurations may be
  148.    treated differently and will be described in future documents.  This
  149.    document does not address issues related to transparent data link
  150.    layer interoperability.
  151.  
  152. Logical IP Subnetwork Configuration
  153.  
  154.    This section describes the scenario for an SMDS Service that is
  155.    configured with multiple logical IP subnetworks, LIS (described
  156.    below).  The scenario considers only directly connected IP end-
  157.    stations or routers; issues raised by MAC level bridging are beyond
  158.    the scope of this paper.
  159.  
  160.    In the LIS scenario, each separate administrative entity configures
  161.    its hosts within a closed logical IP subnetwork.  Each LIS operates
  162.    and communicates independently of other LISs over the same network
  163.    providing SMDS.  Hosts connected to SMDS communicate directly to
  164.    other hosts within the same LIS.  Communication to hosts outside of
  165.    an individual LIS is provided via an IP router.  This router would
  166.    simply be a station attached to the SMDS Service that has been
  167.    configured to be a member of both logical IP subnetworks.  This
  168.    configuration results in a number of disjoint LISs operating over the
  169.  
  170.  
  171.  
  172. IP over SMDS Working Group                                      [Page 3]
  173.  
  174.  
  175. RFC 1209            IP and ARP over the SMDS Service          March 1991
  176.  
  177.  
  178.    same network supporting the SMDS Service.  It is recognized that with
  179.    this configuration, hosts of differing IP networks would communicate
  180.    via an intermediate router even though a direct path over the SMDS
  181.    Service may be possible.
  182.  
  183.    It is envisioned that the service will evolve to provide a more
  184.    public interconnection, allowing machines directly connected to the
  185.    SMDS Service to communicate without an intermediate router.  However,
  186.    the issues raised by such a large public interconnection, such as
  187.    scalability of address resolution or propagation of routing updates,
  188.    are beyond the scope of this paper.  We anticipate that future RFCs
  189.     will address these issues.
  190.  
  191.    The following is a list of the requirements for a LIS configuration:
  192.  
  193.       o All members have the same IP network/subnet number.
  194.  
  195.       o All stations within a LIS are accessed directly over SMDS.
  196.  
  197.       o All stations outside of the LIS are accessed via a router.
  198.  
  199.       o For each LIS a single SMDS group address has been configured
  200.         that identifies all members of the LIS.  Any packet transmitted
  201.         with this address is delivered by SMDS Service to all members
  202.         of the LIS.
  203.  
  204.    The following list identifies a set of SMDS Service specific
  205.    parameters that MUST be implemented in each IP station which would
  206.    connect to the SMDS Service.  The parameter values will be determined
  207.    at SMDS subscription time and will be different for each LIS.  Thus
  208.    these parameters MUST be user configurable.
  209.  
  210.       o SMDS Hardware Address (smds$ha).  The SMDS Individual address
  211.         of the IP station as determined at subscription time.  Each
  212.         host MUST be configured to accept datagrams destined for this
  213.         address.
  214.  
  215.       o SMDS LIS Group Address(smds$lis-ga).  The SMDS Group address
  216.         that has been configured at subscription time to identify the
  217.         SMDS Subscriber Network Interfaces (SNI) of all members of the
  218.         LIS connected to the SMDS Service.  All members of the LIS MUST
  219.         be prepared to accept datagrams addressed to smds$lis-ga.
  220.  
  221.       o SMDS Arp Request Address (smds$arp-req).  The SMDS address
  222.         (individual or group) to which arp requests are to be sent.  In
  223.         the initial LIS configuration this value is set to smds$lis-ga.
  224.         It is conceivable that in other configurations this value would
  225.         be set to some address other than that of smds$lis-ga (see
  226.  
  227.  
  228.  
  229. IP over SMDS Working Group                                      [Page 4]
  230.  
  231.  
  232. RFC 1209            IP and ARP over the SMDS Service          March 1991
  233.  
  234.  
  235.         section on Address Resolution).
  236.  
  237.    It is RECOMMENDED that routers providing LIS functionality over the
  238.    SMDS service also support the ability to interconnect differing LISs.
  239.    Routers that wish to provide interconnection of differing LISs MUST
  240.    be able to support multiple sets of these parameters (one set for
  241.    each connected LIS) and be able to associate each set of parameters
  242.    with a specific IP network/subnet number.  In addition, it is
  243.    RECOMMENDED that a router be able to provide this multiple LIS
  244.    support with a single physical SMDS interface that may have one or
  245.    more individual SMDS addresses.
  246.  
  247.    The following list identifies LIS specific parameters that MUST be
  248.    configured in the network supporting the SMDS Service.  For each LIS,
  249.    the IP network administrator MUST request the configuration of these
  250.    parameters at subscription time.  The administrator of each LIS MUST
  251.    update these parameters as each new station is added to the LIS.
  252.  
  253.       o SMDS LIS Group Address(smds$lis-ga).  An SMDS Group address MUST
  254.         be configured at subscription time to identify the SMDS
  255.         Subscriber Network Interfaces (SNI) of all members of the LIS
  256.         connected to the SMDS Service.
  257.  
  258.       o SMDS Address Screening Tables (Source and Destination).  The use
  259.         of SMDS screening tables is not necessary for the operation of
  260.         IP over SMDS Service.  If the SMDS screening tables are to be
  261.         used, both source and destination tables for each SNI MUST be
  262.         configured to allow, at minimum, both the direct communication
  263.         between all hosts in the same LIS and the use of the SMDS LIS
  264.         Group Address.
  265.  
  266. Packet Format
  267.  
  268.       Service SHALL be encapsulated within the IEEE 802.2 LLC and IEEE
  269.       802.1A Sub-Network Access Protocol (SNAP) [10] Data Link layers
  270.       and the 3-level SIP.  The SNAP MUST be used with an
  271.       Organizationally Unique Identifier Code indicating that the SNAP
  272.       header contains the EtherType code as listed in Assigned Numbers
  273.       [11] (see Figure 2).  Note that values specified in this document
  274.       follow Internet conventions: multi-byte fields are described in
  275.       big-endian order and bits within bytes are described as most
  276.       significant first [11].
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286. IP over SMDS Working Group                                      [Page 5]
  287.  
  288.  
  289. RFC 1209            IP and ARP over the SMDS Service          March 1991
  290.  
  291.  
  292.                                                        +-------+
  293.                                                        |IP/ARP | IP/ARP
  294.                               +----+----+----+----+----+-------+
  295.                               |   Org Code   |Ethertype|       | SNAP
  296.                +----+----+----+----+----+----+----+----+-------+
  297.                |DSAP|SSAP|Ctrl|                                | LLC
  298. +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
  299. |SIP..|HLPI|...|                                               | SIP L3
  300. +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
  301.  
  302.                     Figure 2.  Data Link Encapsulation
  303.  
  304.       o The value of HLPI in the SIP L3 Header is 1.
  305.  
  306.       o The total length of the LLC Header and the SNAP header is 8
  307.         octets.
  308.  
  309.       o The value of DSAP and SSAP in the LLC header is 170 (decimal),
  310.         AA (Internet hexadecimal).
  311.  
  312.       o The Ctrl (Control) value in the LLC header is 3 (Indicates Type
  313.         One Unnumbered Information).
  314.  
  315.       o The Org Code in the SNAP header is zero (000000 Internet
  316.         hexadecimal).
  317.  
  318.       o The EtherType for IP is 2048 (decimal), 0800 (Internet
  319.         hexadecimal).  The EtherType for ARP is 2054 (decimal), 0806
  320.         (Internet hexadecimal).
  321.  
  322.    IEEE 802.2 LLC Type One Unnumbered Information (UI) communication
  323.    (which must be implemented by all conforming IEEE 802.2 stations) is
  324.    used exclusively.  The Higher Layer Protocol Id (HLPI) field in the
  325.    SIP L3_PDU header MUST be set to the IEEE 802.6 assigned Protocol Id
  326.    value for LLC (decimal 1) [8].  All frames MUST be transmitted in
  327.    standard IEEE 802.2 LLC Type 1 Unnumbered Information format, with
  328.    the DSAP and the SSAP fields of the IEEE 802.2 header set to the
  329.    assigned global SAP value for SNAP (decimal 170) [10].  The 24-bit
  330.    Org Code (Organizationally Unique Identifier Code) in the SNAP MUST
  331.    be set to a value of zero, and the remaining 16 bits are set to the
  332.    EtherType value from Assigned Numbers [11] (2048 for IP, 2054 for
  333.    ARP).
  334.  
  335.    The data link encapsulation for IP packets is shown in Figure 3 and
  336.    for ARP in Figure 4.  All values shown are in Internet hexadecimal
  337.    format.
  338.  
  339.  
  340.  
  341.  
  342.  
  343. IP over SMDS Working Group                                      [Page 6]
  344.  
  345.  
  346. RFC 1209            IP and ARP over the SMDS Service          March 1991
  347.  
  348.  
  349.      +--------------+---------------------------------------+-------+
  350.      |      SIP     |             LLC / SNAP                |  IP   |
  351.      |              |                                       |       |
  352.      |SIP..|HLPI|...|DSAP|SSAP|Ctrl|   Org Code   |Ethertype|       |
  353.      +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
  354.      |SIP..| 01 |...| AA | AA | 03 |    000000    |  0800   | IP... |
  355.      +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
  356.  
  357.              Figure 3.  IP Data Link Encapsulation and Values
  358.  
  359.  
  360.  
  361.      +--------------+---------------------------------------+-------+
  362.      |      SIP     |             LLC / SNAP                |  ARP  |
  363.      |              |                                       |       |
  364.      |SIP..|HLPI|...|DSAP|SSAP|Ctrl|   Org Code   |Ethertype|       |
  365.      +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
  366.      |SIP..| 01 |...| AA | AA | 03 |    000000    |  0806   | ARP...|
  367.      +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
  368.  
  369.              Figure 4.  ARP Data Link Encapsulation and Values
  370.  
  371. Address Resolution
  372.  
  373.    The dynamic mapping of 32-bit Internet addresses to SMDS addresses
  374.    SHALL be done via the dynamic discovery procedure of the Address
  375.    Resolution Protocol (ARP) [2].
  376.  
  377.    Internet addresses are assigned independent of SMDS addresses.  Each
  378.    host implementation MUST know its own Internet address and SMDS
  379.    address and respond to Address Resolution requests appropriately.
  380.    Hosts MUST also use ARP to map Internet addresses to SMDS addresses
  381.    when needed.
  382.  
  383.    The ARP protocol has several fields that parameterize its use in any
  384.    specific context [2].  These fields are:
  385.  
  386.            ar$hrd   16 - bits     The Hardware Type Code
  387.            ar$pro   16 - bits     The Protocol Type Code
  388.            ar$hln    8 - bits     Octets in each hardware address
  389.            ar$pln    8 - bits     Octets in each protocol address
  390.            ar$op    16 - bits     Operation Code
  391.  
  392.       o The hardware type code assigned to SMDS addresses is 14
  393.         (decimal), 0E (Internet hexadecimal) [11].
  394.  
  395.       o The protocol type code for IP is 2048 (decimal), 0800
  396.         (Internet hexadecimal) [11].
  397.  
  398.  
  399.  
  400. IP over SMDS Working Group                                      [Page 7]
  401.  
  402.  
  403. RFC 1209            IP and ARP over the SMDS Service          March 1991
  404.  
  405.  
  406.       o The hardware address length for SMDS is 8.
  407.  
  408.       o The protocol address length for IP is 4.
  409.  
  410.       o The operation code is 1 for request and 2 for reply.
  411.  
  412.    The SMDS hardware addresses in ARP packets (ar$sha, ar$tha) MUST be
  413.    carried in SMDS native address format, with the most significant bit
  414.    of the Address Type sub-field as the high order bit of the first
  415.    octet.  Although outside the scope of this document, it is
  416.    RECOMMENDED that SMDS addresses be represented in this format in all
  417.    higher layer Internet protocols (e.g., SNMP).
  418.  
  419.    Traditionally, ARP requests are broadcast to all directly connected
  420.    stations.  For the SMDS Service, the ARP request packet is
  421.    transmitted to the smds$arp-req hardware address.  In the LIS
  422.    configuration, the smds$arp-req address is set to smds$lis-ga, (the
  423.    SMDS group address that identifies all members of the LIS).  It is
  424.    conceivable that in a larger scale, public configuration, the
  425.    smds$arp-req address would be configured to the address of some ARP-
  426.    server(s) instead of the group address that identifies the entire
  427.    LIS.
  428.  
  429. IP Broadcast Address
  430.  
  431.    There is no facility for complete hardware broadcast addressing over
  432.    the SMDS Service.  As discussed in the "LIS Configuration" section,
  433.    an SMDS group address (smds$lis-ga) SHALL be configured to include
  434.    all 
  435.