IPv4 over MAPOS Version 1

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright © The Internet Society (1997). All Rights Reserved.

Table of Contents

1.  Abstract
2.  Introduction
3.  Frame Format for Encapsulating IP Datagrams
4.  Address Mapping
    4.1.  ARP cache
    4.2.  Address Resolution Protocol (ARP)
        4.2.1.  Overview
        4.2.2.  ARP Frame Format
    4.3.  UNARP
    4.4.  ARP Cache Validation
    4.5.  IP Broadcast and multicast
5.  Security Considerations
6.  Acknowledgements
7.  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Abstract

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).

2.  Introduction

Multiple Access Protocol over SONET/SDH (MAPOS) [_XREF_1] (, “Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1," RFC-2171,” June 1997.) 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_2] (Simpson, W., “PPP in HDLC-like Framing," RFC-1662,” July 1994.) for PPP. A component called "Frame Switch" [_XREF_1] (, “Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1," RFC-2171,” June 1997.) 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 "SONET-LAN" can span over a wide geographical area. The Internet Protocol (IP) [_XREF_3] (Postel, J., “Internet Protocol (IP," RFC-791,” September 1981.) datagrams are transmitted in MAPOS HDLC frames [_XREF_1] (, “Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1," RFC-2171,” June 1997.).

This document describes a protocol for transmission of IP datagrams over MAPOS version 1 [_XREF_1] (, “Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1," RFC-2171,” June 1997.). It explains IP datagram encapsulation in HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for mapping between IP address and HDLC address.

3.  Frame Format for Encapsulating IP Datagrams

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 "MAPOS Version 1 Assigned Numbers" [_XREF_4] (, “Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned Numbers," RFC-2172,” June 1997.). The information field contains the IP datagram.

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_5] (, “Mogul, J. and S. Deering, "Path MTU Discovery," RFC-1191,” November 1990.) may be used.

4.  Address Mapping

This section explains MAPOS ARP and the mapping of special addresses.

4.1.  ARP cache

Each node on a MAPOS network maintains an "ARP cache" 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.

4.2.  Address Resolution Protocol (ARP)

This subsection describes MAPOS ARP protocol and its packet format.

4.2.1.  Overview

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.

4.2.2.  ARP Frame Format

The protocol field for an ARP frame must contain 0xFE01 (hexadecimal) as defined by the "MAPOS Version 1 Assigned Numbers" [_XREF_4] (, “Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned Numbers," RFC-2172,” June 1997.). The information field contains the ARP packet as shown below.

           +-------------------------+------------------------+
           |  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

Hardware Address Space (16 bits)

The hardware address space for MAPOS ARP is 25 in Decimal as assigned by IANA [_XREF_6] (, “IANA, "IANA-Assignments", http://www.iana.org/iana/assignments.html,” .).

Protocol Address Space (16 bits)

The protocol address space for IP is 2048 in Decimal.

Hardware Address Length (8 bits)

The hardware address length is 4.

Protocol Address Length (8 bits)

The protocol address length for IP is 4.

Operation Code (16 bits)

The operation code is 1 for request and 2 for response.

Sender hardware (HDLC) Address (32 bits)

Contains the sender'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)

Contains the sender's IP address in an ARP request, and the target IP address in an ARP response.

Target hardware (HDLC) Address (32 bits)

Contains unknown target HDLC address (all zeros) in an ARP request, and sender'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.

Target Protocol (IP) Address (32 bits)

Contains the target IP address in an ARP request, and the sender's IP address in an ARP response.

4.3.  UNARP

An implementation MUST provide an UNARP mechanism to flush obsolete ARP cache entries. The mechanism is similar to the ARP extension described in [_XREF_7] (Malkin, G., “ARP Extension - UNARP," RFC-1868,” November 1995.). 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:

     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)

Hardware Address Space (16 bits)

The hardware address space for MAPOS ARP is 25 in Decimal as assigned by IANA [_XREF_6] (, “IANA, "IANA-Assignments", http://www.iana.org/iana/assignments.html,” .).

Operation Code (16 bits)

The operation code is 23 for MAPOS-UNARP in Decimal as assigned by IANA [_XREF_6] (, “IANA, "IANA-Assignments", http://www.iana.org/iana/assignments.html,” .).

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.

4.4.  ARP Cache Validation

An implementation MUST provide a mechanism to remove out-of-date cache entries and it SHOULD provide options to configure the timeout value [_XREF_8] (Braden, R., “Requirements for Internet Hosts - Communication Layers," RFC-1122,” October 1989.). 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.

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.

4.5.  IP Broadcast and multicast

In broadcast and multicast frames, the most significant bit of the HDLC address must be 1 [_XREF_1] (, “Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1," RFC-2171,” June 1997.). In addition, the least significant bit must always be 1 to indicate the end of the field [_XREF_1] (, “Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1," RFC-2171,” June 1997.).

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).

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_9] (Deering, S., “Host Extensions for IP Multicasting," RFC-1112,” August 1989.). 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.

5.  Security Considerations

Security issues are not discussed in this memo.

6.  Acknowledgements

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.

7. References

Authors' Addresses

Full Copyright Statement

Copyright © The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.