<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<!--
     ASCII to XML transformation by Invisible Worlds, Inc.
     http://invisible.net/
     Last transformation: 03-Feb-1999, 02:04:17

     Cannonical version of this document is at:
     http://info.internet.isi.edu/in-notes/rfc/files/rfc2176.txt

     Implementors should verify all content with
     cannonical version.  Failure to do so may result in
     protocol failures.
-->

<rfc number="2176"
     category="info">
<front>
<title abbrev="MAPOS">IPv4 over MAPOS Version 1</title>
<author initials="K." surname="Murakami" fullname="Ken Murakami">
<organization>NTT Software Laboratories</organization>
<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>
<email>murakami@ntt-20.ecl.net</email>
</address>
</author>
<author initials="M." surname="Maruyama" fullname="Mitsuru Maruyama">
<organization>NTT Software Laboratories</organization>
<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>
<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>
<date month="June" year="1997"/>
<area>Internet</area>
<keyword>MAPOS</keyword>
<keyword>encapsulate</keyword>
<keyword>internet protocol version 4</keyword>
<keyword>synchronous optical network</keyword>
</front>
<middle>
<section title="Abstract">
<t>
   This document describes a protocol for transmission of the Internet
   Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS)
   version 1. MAPOS is a link layer protocol and provides multiple
   access capability over SONET/SDH links. IP runs on top of MAPOS. This
   document explains IP datagram encapsulation in HDLC frame of MAPOS,
   and the Address Resolution Protocol (ARP).
</t>
</section>
<!-- RFC original section: (1.) -->
<section title="Introduction">
<t>
   Multiple Access Protocol over SONET/SDH (MAPOS) <xref target="_XREF_1"/> is a high-speed
   link-layer protocol that provides multiple access capability over
   SONET/SDH. Its frame format is based on the HDLC-like framing <xref target="_XREF_2"/> for
   PPP.  A component called &quot;Frame Switch&quot; <xref target="_XREF_1"/> allows multiple nodes to
   be connected together in a star topology to form a LAN. Using long
   haul SONET/SDH links, the nodes on such a &quot;SONET-LAN&quot; can span over a
   wide geographical area. The Internet Protocol (IP) <xref target="_XREF_3"/> datagrams are
   transmitted in MAPOS HDLC frames <xref target="_XREF_1"/>.
</t>
<t>
   This document describes a protocol for transmission of IP datagrams
   over MAPOS version 1 <xref target="_XREF_1"/>. It explains IP datagram encapsulation in
   HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for
   mapping between IP address and HDLC address.
</t>
</section>
<!-- RFC original section: (2.) -->
<section title="Frame Format for Encapsulating IP Datagrams">
<t>
   An IP datagram is transmitted in a MAPOS HDLC frame.  The protocol
   field of the frame must contain the value 0x0021 (hexadecimal) as
   defined by the &quot;MAPOS Version 1 Assigned Numbers&quot; <xref target="_XREF_4"/>.  The
   information field contains the IP datagram.
</t>
<t>
   The information field may be one to 65,280 octets in length; the
   MTU(Maximum Transmission Unit) of MAPOS is 65,280 octets.  Although
   the large MTU size can suppress the overhead of IP header processing,
   it may cause fragmentation anywhere along the path from the source to
   the destination and result in performance degradation. To cope with
   the issue, Path MTU discovery <xref target="_XREF_5"/> may be used.
</t>
</section>
<!-- RFC original section: (3.) -->
<section title="Address Mapping">
<t>
   This section explains MAPOS ARP and the mapping of special addresses.
</t>
<!-- RFC original section: (3.1) -->
<section title="ARP cache">
<t>
   Each node on a MAPOS network maintains an &quot;ARP cache&quot; that maps
   destination IP addresses to their corresponding 8-bit HDLC addresses.
   Entries are added to this cache either manually or by the Address
   Resolution Protocol described below.  Entries are removed from this
   cache manually, by the UNARP mechanism, or by ARP cache validation
   mechanism.  An implementation must provide a mechanism for manually
   adding or removing arbitrary ARP cache entries.
</t>
</section>
<!-- RFC original section: (3.2) -->
<section title="Address Resolution Protocol (ARP)">
<t>
   This subsection describes MAPOS ARP protocol and its packet format.
</t>
<!-- RFC original section: (3.2.1) -->
<section title="Overview">
<t>
   The MAPOS ARP is similar to that for ethernet.  Prior to sending an
   IP datagram, the node must know the destination HDLC address
   corresponding to the destination IP address. When its ARP cache does
   not contain the corresponding entry, it uses ARP to translate the IP
   address to the HDLC address. That is, it broadcasts an ARP request
   containing the destination IP address.  In response to the request,
   the node which has the IP address sends an ARP reply containing the
   HDLC address. The returned HDLC address is stored in the ARP cache.
</t>
</section>
<!-- RFC original section: (3.2.2) -->
<section title="ARP Frame Format">
<t>
   The protocol field for an ARP frame must contain 0xFE01 (hexadecimal)
   as defined by the &quot;MAPOS Version 1 Assigned Numbers&quot; <xref target="_XREF_4"/>. The
   information field contains the ARP packet as shown below.
</t>
<figure><artwork>
           +-------------------------+------------------------+
           |  Hardware Address Space | Protocol Address Space |
           |       (25:MAPOS)        |     (2048 in Dec)      |
           |    16 bits              |   16 bits              |
           +------------+------------+------------------------+
           | Hard Addr  | Proto Addr |   Operation Code       |
           | Length (4) | Length (4) |(1:Request 2:Response)  |
           |   8 bits   |   8 bits   |         16 bits        |
           +------------+------------+------------------------+
           |    Sender HDLC Address        32 bits            |
           +--------------------------------------------------+
           |    Sender IP Address          32 bits            |
           +--------------------------------------------------+
           |    Target HDLC Address        32 bits            |
           +--------------------------------------------------+
           |    Target IP Address          32 bits            |
           +--------------------------------------------------+

                      Figure 5  ARP packet format
</artwork></figure>
<t>
     Hardware Address Space (16 bits)
</t>
<t>
     The hardware address space for MAPOS ARP is 25 in Decimal as
     assigned by IANA <xref target="_XREF_6"/>.
</t>
<t>
     Protocol Address Space (16 bits)
</t>
<t>
     The protocol address space for IP is 2048 in Decimal.
</t>
<t>
     Hardware Address Length (8 bits)
</t>
<t>
     The hardware address length is 4.
</t>
<t>
     Protocol Address Length (8 bits)
</t>
<t>
     The protocol address length for IP is 4.
</t>
<t>
     Operation Code (16 bits)
</t>
<t>
     The operation code is 1 for request and 2 for response.
</t>
<t>
     Sender hardware (HDLC) Address (32 bits)
</t>
<t>
     Contains the sender&apos;s HDLC address in an ARP request, and the
     target HDLC address in an ARP response.  The 8-bit HDLC address is
     placed in the least significant place of the 32-bit field. The
     remaining bits should be zero.
     Sender Protocol (IP) Address (32 bits)
</t>
<t>
     Contains the sender&apos;s IP address in an ARP request, and the target
     IP address in an ARP response.
</t>
<t>
     Target hardware (HDLC) Address (32 bits)
</t>
<t>
     Contains unknown target HDLC address (all zeros) in an ARP request,
     and sender&apos;s HDLC address in an ARP response.  The 8-bit HDLC
     address is placed in the least significant place of the 32-bit
     field.  The remaining bits should be zero.
</t>
<t>
     Target Protocol (IP) Address (32 bits)
</t>
<t>
     Contains the target IP address in an ARP request, and the sender&apos;s
     IP address in an ARP response.
</t>
</section>
</section>
<!-- RFC original section: (3.3) -->
<section title="UNARP">
<t>
   An implementation MUST provide an UNARP mechanism to flush obsolete
   ARP cache entries.  The mechanism is similar to the ARP extension
   described in <xref target="_XREF_7"/>.  When a node detects that its port has came up, it
   MUST broadcast an UNARP packet.  It forces every other node to clear
   the obsolete ARP entry which was created by the node previously
   connected to the switch port. An UNARP is an ARP clear request with
   the following values:
</t>
<figure><artwork>
     Hardware Address Space          :       25
     Protocol Address Space          :       2048
     Hardware Address Length         :       4
     Protocol Address Length         :       4
     Operation Code                  :       23 (MAPOS-UNARP)
     Sender hardware (HDLC) Address  :       HDLC address of the node
     Sender Protocol (IP) Address    :       IP address of the node
     Target hardware (HDLC) Address  :       all 1
     Target Protocol (IP) Address    :       255.255.255.255 (broadcast)
</artwork></figure>
<t><list><t>
     Hardware Address Space (16 bits)
</t>
<t>
     The hardware address space for MAPOS ARP is 25 in Decimal as
     assigned by IANA <xref target="_XREF_6"/>.
</t>
<t>
     Operation Code (16 bits)
</t>
<t>
     The operation code is 23 for MAPOS-UNARP in Decimal as assigned by
     IANA <xref target="_XREF_6"/>.
</t></list>
</t>
<t>
   The node MUST send three UNARP packets at 30 seconds intervals.  The
   receiving node of the packet MUST clear the ARP cache entry
   associated with the Sender Protocol (IP) Address, if and only if the
   corresponding Hardware (HDLC) Address is not equal to that contained
   in the UNARP packet.  That is, if both the Sender Hardware (HDLC)
   Address and the Sender Protocol(IP) Address match those of the cached
   entry, the entry is left unchanged.
</t>
</section>
<!-- RFC original section: (3.4) -->
<section title="ARP Cache Validation">
<t>
   An implementation MUST provide a mechanism to remove out-of-date
   cache entries and it SHOULD provide options to configure the timeout
   value <xref target="_XREF_8"/>.  One approach is to periodically time-out the cache
   entries, even if they are in use.  This approach involves ARP cache
   timeouts in the order of a minute or less.
</t>
<t>
   Furthermore, when the link is lost on an interface, all ARP cache
   entries associated with the interface MUST be removed immediately.
   Causes for link loss includes conditions such as loss of carrier and
   out-of-synchronization.
</t>
</section>
<!-- RFC original section: (3.5) -->
<section title="IP Broadcast and multicast">
<t>
   In broadcast and multicast frames, the most significant bit of the
   HDLC address must be 1 <xref target="_XREF_1"/>.  In addition, the least significant bit
   must always be 1 to indicate the end of the field <xref target="_XREF_1"/>.
</t>
<t>
   In the case of IP broadcast, the remaining six bits of the HDLC
   address must be all 1s.  That is, it should be mapped to the HDLC
   broadcast address 0xFF (hexadecimal).
</t>
<t>
   In the case of IP multicast, the remaining six bits of the HDLC
   address must contain the lowest-order six bits of the IP multicast
   group address.  It resembles IP multicast extension for ethernet
   described in <xref target="_XREF_9"/>.  Exceptions arise when these six bits are either
   all zeros or all ones, in which case they should be altered to the
   bit sequence 111110.
</t>
</section>
</section>
<!-- RFC original section: (4.) -->
<section title="Security Considerations">
<t>
   Security issues are not discussed in this memo.
</t>
</section>
<section title="Acknowledgements">
<t>
   The authors would like to acknowledge the contributions and
   thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
   Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima.
</t>
</section>
</middle>
<back>
<!-- BEGIN INCLUDE REFERENCES ** DO NOT REMOVE -->
<references>
<reference anchor="_XREF_1">
<front>
<title abbrev="Murakami">Murakami, K. and M. Maruyama, &quot;MAPOS - Multiple Access Protocol over SONET/SDH, Version 1,&quot; RFC-2171</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
</reference>
<reference anchor="_XREF_2">
<front>
<title>PPP in HDLC-like Framing,&quot; RFC-1662</title>
<author initials="W." surname="Simpson" fullname="W. Simpson">
<organization/>
</author>
<date month="July" year="1994"/>
</front>
</reference>
<reference anchor="_XREF_3">
<front>
<title>Internet Protocol (IP,&quot; RFC-791</title>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date month="September" year="1981"/>
</front>
</reference>
<reference anchor="_XREF_4">
<front>
<title abbrev="Maruyama">Maruyama, M. and K. Murakami, &quot;MAPOS Version 1 Assigned Numbers,&quot; RFC-2172</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
</reference>
<reference anchor="_XREF_5">
<front>
<title abbrev="Mogul">Mogul, J. and S. Deering, &quot;Path MTU Discovery,&quot; RFC-1191</title>
<author>
<organization/>
</author>
<date month="November" year="1990"/>
</front>
</reference>
<reference anchor="_XREF_6" target="http://www.iana.org/iana/assignments.html">
<front>
<title abbrev="IANA">IANA, &quot;IANA-Assignments&quot;, http://www.iana.org/iana/assignments.html</title>
<author>
<organization/>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="_XREF_7">
<front>
<title>ARP Extension - UNARP,&quot; RFC-1868</title>
<author initials="G." surname="Malkin" fullname="G. Malkin">
<organization/>
</author>
<date month="November" year="1995"/>
</front>
</reference>
<reference anchor="_XREF_8">
<front>
<title abbrev="Requirements for Internet Hosts">Requirements for Internet Hosts - Communication Layers,&quot; RFC-1122</title>
<author initials="R." surname="Braden" fullname="R. Braden">
<organization/>
</author>
<date month="October" year="1989"/>
</front>
</reference>
<reference anchor="_XREF_9">
<front>
<title abbrev="Host Extensions for IP Multicasting">Host Extensions for IP Multicasting,&quot; RFC-1112</title>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<date month="August" year="1989"/>
</front>
</reference>
</references>
<!-- END INCLUDE REFERENCES ** DO NOT REMOVE -->
</back>
</rfc>
