home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-murakami-01.txt < prev    next >
Text File  |  1997-05-01  |  13KB  |  351 lines
  1.  
  2. INTERNET-DRAFT             EXPIRES NOVEMBER 1997        INTERNET-DRAFT
  3.  
  4.  
  5. Network Working Group                                   K. Murakami
  6. INTERNET-DRAFT                                          M. Maruyama
  7. Category: Informational                                 NTT Laboratories
  8.                                                         May 1997
  9.  
  10.  
  11.                        IPv4 over MAPOS Version 1
  12.                    <draft-rfced-info-murakami-01.txt>
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This document is an Internet-Draft.  Internet-Drafts are working
  18.    documents of the Internet Engineering task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups may also distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six
  23.    months and may be updated, replaced, or obsoleted by other
  24.    documents at any time.  It is inappropriate to use Internet-Drafts
  25.    as reference material or to cite them other than as "work in
  26.    progress".
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  30.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  31.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  32.    ftp.isi.edu (US West Coast).
  33.  
  34. Authors' Note
  35.  
  36.    This memo documents a mechanism for supporting Version 4 of the
  37.    Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol
  38.    over SONET/SDH.  This document is NOT the product of an IETF working
  39.    group nor is it a standards track document.  It has not necessarily
  40.    benefited from the widespread and in-depth community review that
  41.    standards track documents receive.
  42.  
  43. Abstract
  44.  
  45.    This document describes a protocol for transmission of the Internet
  46.    Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS)
  47.    version 1. MAPOS is a link layer protocol and provides multiple
  48.    access capability over SONET/SDH links. IP runs on top of MAPOS. This
  49.    document explains IP datagram encapsulation in HDLC frame of MAPOS,
  50.    and the Address Resolution Protocol (ARP).
  51.  
  52. 1. Introduction
  53.  
  54.    Multiple Access Protocol over SONET/SDH (MAPOS) [1] is a high-speed
  55.    link-layer protocol that provides multiple access capability over
  56.    SONET/SDH. Its frame format is based on the HDLC-like framing [2] for
  57.    PPP.  A component called ``Frame Switch'' [1] allows multiple nodes
  58.    to be connected together in a star topology to form a LAN. Using long
  59.    haul SONET/SDH links, the nodes on such a ``SONET-LAN'' can span over
  60.    a wide geographical area. The Internet Protocol (IP) [3] datagrams
  61.    are transmitted in MAPOS HDLC frames [1].
  62.  
  63.    This document describes a protocol for transmission of IP datagrams
  64.    over MAPOS version 1 [1]. It explains IP datagram encapsulation in
  65.    HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for
  66.    mapping between IP address and HDLC address.
  67.  
  68. 2. Frame Format for Encapsulating IP Datagrams
  69.  
  70.    An IP datagram is transmitted in a MAPOS HDLC frame.  The protocol
  71.    field of the frame must contain the value 0x0021 (hexadecimal) as
  72.    defined by the ``MAPOS Version 1 Assigned Numbers'' [4].  The
  73.    information field contains the IP datagram.
  74.  
  75.  
  76.  
  77. Murakami, Maruyama                                              [Page 1]
  78.  
  79. I/D                  IPv4 over MAPOS Version 1                May 1997
  80.  
  81.  
  82.    The information field may be one to 65,280 octets in length; the
  83.    MTU(Maximum Transmission Unit) of MAPOS is 65,280 octets.  Although
  84.    the large MTU size can suppress the overhead of IP header processing,
  85.    it may cause fragmentation anywhere along the path from the source to
  86.    the destination and result in performance degradation. To cope with
  87.    the issue, Path MTU discovery [5] may be used.
  88.  
  89. 3. Address Mapping
  90.  
  91.    This section explains MAPOS ARP and the mapping of special addresses.
  92.  
  93. 3.1 ARP cache
  94.  
  95.    Each node on a MAPOS network maintains an ``ARP cache'' that maps
  96.    destination IP addresses to their corresponding 8-bit HDLC addresses.
  97.    Entries are added to this cache either manually or by the Address
  98.    Resolution Protocol described below.  Entries are removed from this
  99.    cache manually, by the UNARP mechanism, or by ARP cache validation
  100.    mechanism.  An implementation must provide a mechanism for manually
  101.    adding or removing arbitrary ARP cache entries.
  102.  
  103. 3.2 Address Resolution Protocol (ARP)
  104.  
  105.    This subsection describes MAPOS ARP protocol and its packet format.
  106.  
  107. 3.2.1 Overview
  108.  
  109.    The MAPOS ARP is similar to that for ethernet.  Prior to sending an
  110.    IP datagram, the node must know the destination HDLC address
  111.    corresponding to the destination IP address. When its ARP cache does
  112.    not contain the corresponding entry, it uses ARP to translate the IP
  113.    address to the HDLC address. That is, it broadcasts an ARP request
  114.    containing the destination IP address.  In response to the request,
  115.    the node which has the IP address sends an ARP reply containing the
  116.    HDLC address. The returned HDLC address is stored in the ARP cache.
  117.  
  118. 3.2.2 ARP Frame Format
  119.  
  120.    The protocol field for an ARP frame must contain 0xFE01 (hexadecimal)
  121.    as defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. The
  122.    information field contains the ARP packet as shown below.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139. Murakami, Maruyama                                              [Page 2]
  140.  
  141. I/D                  IPv4 over MAPOS Version 1                May 1997
  142.  
  143.  
  144.  
  145.            +-------------------------+------------------------+
  146.            |  Hardware Address Space | Protocol Address Space |
  147.            |       (25:MAPOS)        |     (2048 in Dec)      |
  148.            |    16 bits              |   16 bits              |
  149.            +------------+------------+------------------------+
  150.            | Hard Addr  | Proto Addr |   Operation Code       |
  151.            | Length (4) | Length (4) |(1:Request 2:Response)  |
  152.            |   8 bits   |   8 bits   |         16 bits        |
  153.            +------------+------------+------------------------+
  154.            |    Sender HDLC Address        32 bits            |
  155.            +--------------------------------------------------+
  156.            |    Sender IP Address          32 bits            |
  157.            +--------------------------------------------------+
  158.            |    Target HDLC Address        32 bits            |
  159.            +--------------------------------------------------+
  160.            |    Target IP Address          32 bits            |
  161.            +--------------------------------------------------+
  162.  
  163.                             Figure 5  ARP packet format
  164.  
  165.  
  166.      Hardware Address Space (16 bits)
  167.  
  168.      The hardware address space for MAPOS ARP is 25 in Decimal as
  169.      assigned by IANA [6].
  170.  
  171.      Protocol Address Space (16 bits)
  172.  
  173.      The protocol address space for IP is 2048 in Decimal.
  174.  
  175.      Hardware Address Length (8 bits)
  176.  
  177.      The hardware address length is 4.
  178.  
  179.      Protocol Address Length (8 bits)
  180.  
  181.      The protocol address length for IP is 4.
  182.  
  183.      Operation Code (16 bits)
  184.  
  185.      The operation code is 1 for request and 2 for response.
  186.  
  187.      Sender hardware (HDLC) Address (32 bits)
  188.  
  189.      Contains the sender's HDLC address in an ARP request, and the
  190.      target HDLC address in an ARP response.  The 8-bit HDLC address is
  191.      placed in the least significant place of the 32-bit field. The
  192.      remaining bits should be zero.
  193.  
  194.      Sender Protocol (IP) Address (32 bits)
  195.  
  196.      Contains the sender's IP address in an ARP request, and the target
  197.      IP address in an ARP response.
  198.  
  199.  
  200.  
  201. Murakami, Maruyama                                              [Page 3]
  202.  
  203. I/D                  IPv4 over MAPOS Version 1                May 1997
  204.  
  205.  
  206.      Target hardware (HDLC) Address (32 bits)
  207.  
  208.      Contains unknown target HDLC address (all zeros) in an ARP request,
  209.      and sender's HDLC address in an ARP response.  The 8-bit HDLC
  210.      address is placed in the least significant place of the 32-bit
  211.      field.  The remaining bits should be zero.
  212.  
  213.      Target Protocol (IP) Address (32 bits)
  214.  
  215.      Contains the target IP address in an ARP request, and the sender's
  216.      IP address in an ARP response.
  217.  
  218. 3.3 UNARP
  219.  
  220.    An implementation MUST provide an UNARP mechanism to flush obsolete
  221.    ARP cache entries.  The mechanism is similar to the ARP extension
  222.    described in [7].  When a node detects that its port has came up, it
  223.    MUST broadcast an UNARP packet.  It forces every other node to clear
  224.    the obsolete ARP entry which was created by the node previously
  225.    connected to the switch port. An UNARP is an ARP clear request with
  226.    the following values:
  227.  
  228.      Hardware Address Space          :       25
  229.      Protocol Address Space          :       2048
  230.      Hardware Address Length         :       4
  231.      Protocol Address Length         :       4
  232.      Operation Code                  :       23 (MAPOS-UNARP)
  233.      Sender hardware (HDLC) Address  :       HDLC address of the node
  234.      Sender Protocol (IP) Address    :       0.0.0.0 (unknown)
  235.      Target hardware (HDLC) Address  :       all 1
  236.      Target Protocol (IP) Address    :       255.255.255.255 (broadcast)
  237.  
  238.      Hardware Address Space (16 bits)
  239.  
  240.      The hardware address space for MAPOS ARP is 25 in Decimal as
  241.      assigned by IANA [6].
  242.  
  243.      Operation Code (16 bits)
  244.  
  245.      The operation code is 23 for MAPOS-UNARP in Decimal as assigned by
  246.      IANA [6].
  247.  
  248.    The receiving node of the packet MUST clear the ARP entry
  249.    corresponding to the Sender Hardware (HDLC) Address.
  250.  
  251. 3.4 ARP Cache Validation
  252.  
  253.    An implementation MUST provide a mechanism to remove out-of-date
  254.    cache entries and it SHOULD provide options to configure the timeout
  255.    value [8].  One approach is to periodically time-out the cache
  256.    entries, even if they are in use.  This approach involves ARP cache
  257.    timeouts in the order of a minute or less.
  258.  
  259. 3.5 IP Broadcast and multicast
  260.  
  261.  
  262.  
  263. Murakami, Maruyama                                              [Page 4]
  264.  
  265. I/D                  IPv4 over MAPOS Version 1                May 1997
  266.  
  267.  
  268.    In broadcast and multicast frames, the most significant bit of the
  269.    HDLC address must be 1 [1].  In addition, the least significant bit
  270.    must always be 1 to indicate the end of the field [1].
  271.  
  272.    In the case of IP broadcast, the remaining six bits of the HDLC
  273.    address must be all 1s.  That is, it should be mapped to the HDLC
  274.    broadcast address 0xFF (hexadecimal).
  275.  
  276.    In the case of IP multicast, the remaining six bits of the HDLC
  277.    address must contain the lowest-order six bits of the IP multicast
  278.    group address.  It resembles IP multicast extension for ethernet
  279.    described in [9].  Exceptions arise when these six bits are either
  280.    all zeros or all ones, in which case they should be altered to the
  281.    bit sequence 111110.
  282.  
  283. 4. Security Considerations
  284.  
  285.    Security issues are not discussed in this memo.
  286.  
  287. References
  288.  
  289.    [1]   K. Murakami and M. Maruyama, "MAPOS - Multiple Access Protocol
  290.          over SONET/SDH, Version 1," May 1997.
  291.  
  292.    [2]   W. Simpson, editor, "PPP in HDLC-like Framing," RFC-1662,
  293.          July 1994.
  294.  
  295.    [3]   J. Postel, "Internet Protocol (IP)," RFC-791, September 1981.
  296.  
  297.    [4]   M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned Numbers,"
  298.          May 1997.
  299.  
  300.    [5]   J. Mogul and S. Deering, "Path MTU Discovery," RFC1191,
  301.          Nov.1990
  302.  
  303.    [6]   IANA, "IANA-Assignments", http://www.isi.edu/div7/iana/assignments.html
  304.  
  305.    [7]   G. Malkin, "ARP Extension - UNARP," RFC-1868, November 1995.
  306.  
  307.    [8]   R. Braden, "Requirements for Internet Hosts - Communication
  308.          Layers," RFC-1122, October 1989.
  309.  
  310.    [9]   S. Deering, "Host Extensions for IP Multicasting," RFC-1112,
  311.          August 1989.
  312.  
  313. Acknowledgements
  314.  
  315.    The authors would like to acknowledge the contributions and thoughtful
  316.    suggestions of John P. Mullaney, Clark Bremer, Masayuki Kobayashi,
  317.    Paul Francis, Toshiaki Yoshida, and Takahiro Sajima.
  318.  
  319. Author's Address
  320.  
  321.      Ken Murakami
  322.  
  323.  
  324.  
  325. Murakami, Maruyama                                              [Page 5]
  326.  
  327. I/D                  IPv4 over MAPOS Version 1                May 1997
  328.  
  329.  
  330.      NTT Software Laboratories
  331.      3-9-11, Midori-cho
  332.      Musashino-shi
  333.      Tokyo-180, Japan
  334.      E-mail: murakami@ntt-20.ecl.net
  335.  
  336.      Mitsuru Maruyama
  337.      NTT Software Laboratories
  338.      3-9-11, Midori-cho
  339.      Musashino-shi
  340.      Tokyo-180, Japan
  341.      E-mail: mitsuru@ntt-20.ecl.net
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348. Murakami, Maruyama                                              [Page 6]
  349.  
  350. INTERNET-DRAFT               EXPIRES NOVEMBER 1997       INTERNET-DRAFT
  351.