summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2176.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2176.txt')
-rw-r--r--doc/rfc/rfc2176.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2176.txt b/doc/rfc/rfc2176.txt
new file mode 100644
index 0000000..b1acba8
--- /dev/null
+++ b/doc/rfc/rfc2176.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group K. Murakami
+Request for Comments: 2176 M. Maruyama
+Category: Informational NTT Laboratories
+ June 1997
+
+
+ IPv4 over MAPOS Version 1
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Authors' Note
+
+ This memo documents a mechanism for supporting Version 4 of the
+ Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol
+ over SONET/SDH. This document is NOT the product of an IETF working
+ group nor is it a standards track document. It has not necessarily
+ benefited from the widespread and in-depth community review that
+ standards track documents receive.
+
+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).
+
+1. Introduction
+
+ Multiple Access Protocol over SONET/SDH (MAPOS) [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 [2] for
+ PPP. A component called "Frame Switch" [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 "SONET-LAN" can span over a
+ wide geographical area. The Internet Protocol (IP) [3] datagrams are
+ transmitted in MAPOS HDLC frames [1].
+
+ This document describes a protocol for transmission of IP datagrams
+ over MAPOS version 1 [1]. It explains IP datagram encapsulation in
+ HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for
+ mapping between IP address and HDLC address.
+
+
+
+
+Murakami & Maruyama Informational [Page 1]
+
+RFC 2176 MAPOS June 1997
+
+
+2. 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" [4]. 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 [5] may be used.
+
+3. Address Mapping
+
+ This section explains MAPOS ARP and the mapping of special addresses.
+
+3.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.
+
+3.2 Address Resolution Protocol (ARP)
+
+ This subsection describes MAPOS ARP protocol and its packet format.
+
+3.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.
+
+3.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" [4]. The
+ information field contains the ARP packet as shown below.
+
+
+
+Murakami & Maruyama Informational [Page 2]
+
+RFC 2176 MAPOS June 1997
+
+
+ +-------------------------+------------------------+
+ | 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 [6].
+
+ 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.
+
+
+
+Murakami & Maruyama Informational [Page 3]
+
+RFC 2176 MAPOS June 1997
+
+
+ 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.
+
+3.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 [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:
+
+ 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 [6].
+
+ Operation Code (16 bits)
+
+ The operation code is 23 for MAPOS-UNARP in Decimal as assigned by
+ IANA [6].
+
+
+
+
+
+Murakami & Maruyama Informational [Page 4]
+
+RFC 2176 MAPOS June 1997
+
+
+ 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.
+
+3.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 [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.
+
+ 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.
+
+
+3.5 IP Broadcast and multicast
+
+ In broadcast and multicast frames, the most significant bit of the
+ HDLC address must be 1 [1]. In addition, the least significant bit
+ must always be 1 to indicate the end of the field [1].
+
+ 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 [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.
+
+4. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+Murakami & Maruyama Informational [Page 5]
+
+RFC 2176 MAPOS June 1997
+
+
+References
+
+ [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol
+ over SONET/SDH, Version 1," RFC-2171, June 1997.
+
+ [2] Simpson, W., editor, "PPP in HDLC-like Framing," RFC-1662,
+ July 1994.
+
+ [3] Postel, J., "Internet Protocol (IP)," RFC-791, September 1981.
+
+ [4] Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
+ Numbers," RFC-2172, June 1997.
+
+ [5] Mogul, J. and S. Deering, "Path MTU Discovery," RFC-1191,
+ Nov. 1990.
+
+ [6] IANA, "IANA-Assignments",
+ http://www.iana.org/iana/assignments.html
+
+ [7] Malkin, G., "ARP Extension - UNARP," RFC-1868, November 1995.
+
+ [8] Braden, R., "Requirements for Internet Hosts - Communication
+ Layers," RFC-1122, October 1989.
+
+ [9] Deering, S., "Host Extensions for IP Multicasting," RFC-1112,
+ August 1989.
+
+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.
+
+Author's Address
+
+ Ken Murakami
+ NTT Software Laboratories
+ 3-9-11, Midori-cho
+ Musashino-shi
+ Tokyo-180, Japan
+ E-mail: murakami@ntt-20.ecl.net
+
+ Mitsuru Maruyama
+ NTT Software Laboratories
+ 3-9-11, Midori-cho
+ Musashino-shi
+ Tokyo-180, Japan
+ E-mail: mitsuru@ntt-20.ecl.net
+
+
+
+Murakami & Maruyama Informational [Page 6]
+