< draft-rfced-info-maruyama-00.txt		draft-rfced-info-maruyama-01.txt >
	Internet-Draft Expires: June 1997 Internet-Draft		INTERNET-DRAFT EXPIRES OCTOBER 1997 INTERNET-DRAFT
	Network Working Group K. Murakami		Network Working Group K. Murakami
	Internet-Draft M. Maruyama		INTERNET-DRAFT M. Maruyama
	Category: Informational NTT Laboratories		Category: Informational NTT Laboratories
	January 1997		April 1997
	IP over MAPOS Version 1		IPv4 over MAPOS Version 1
	<draft-rfced-info-maruyama-00.txt>		<draft-rfced-info-maruyama-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft.Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its
	and its working groups. Note that other groups may also distribute		areas, and its working groups. Note that other groups may also
	working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet- Drafts		documents at any time. It is inappropriate to use Internet-
	as reference material or to cite them other than as ``work in		Drafts as reference material or to cite them other than as ``work
	progress.''		in progress.''
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check
	``1id-abstracts.txt'' listing contained in the Internet- Drafts		the ``1id-abstracts.txt'' listing contained in the Internet-
	Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or		(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
	ftp.isi.edu (US West Coast).		Coast), or ftp.isi.edu (US West Coast).
	This document provides information for the Internet community. This		Author's Note:
	memo does not specify an Internet standard of any kind. Distribution
	of this memo is unlimited.
	This memo documents a mechanism for supporting the Internet Protocol		This memo documents a mechanism for supporting Version 4 of the
	(IP) on Version 1 of the Multiple Access Protocol over SONET/SDH.		Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol
	This protocol is NOT the product of an IETF working group nor is it a		over SONET/SDH. This document is NOT the product of an IETF working
	standards track document. It has not necessarily benefited from the		group nor is it a standards track document. It has not necessarily
	widespread and in-depth community review that standards track		benefited from the widespread and in-depth community review that
	documents receive.		standards track documents receive.
	Abstract		Abstract
	This document describes a protocol for transmission of the Internet		This document describes a protocol for transmission of the Internet
	Protocol (IP) over Multiple Access Over SONET/SDH (MAPOS) version 1.		Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS)
	MAPOS is a link layer protocol and provides multiple access		version 1. MAPOS is a link layer protocol and provides multiple
	capability over SONET/SDH links. IP runs on top of MAPOS. This		access capability over SONET/SDH links. IP runs on top of MAPOS. This
	document explains IP datagram encapsulation in HDLC frame of MAPOS,		document explains IP datagram encapsulation in HDLC frame of MAPOS,
	and the Address Resolution Protocol (ARP).		and the Address Resolution Protocol (ARP).
	1. Introduction		1. Introduction
	Multiple Access Protocol over SONET/SDH (MAPOS) [1] is a high-speed		Multiple Access Protocol over SONET/SDH (MAPOS) [1] is a high-speed
	link-layer protocol that provides multiple access capability over		link-layer protocol that provides multiple access capability over
	SONET/SDH. Its frame format is based on the HDLC-like framing [2] for		SONET/SDH. Its frame format is based on the HDLC-like framing [2] for
	PPP. A component called ``Frame Switch'' [1] allows multiple nodes		PPP. A component called ``Frame Switch'' [1] allows multiple nodes
	to be connected together in a star topology to form a LAN. Using long		to be connected together in a star topology to form a LAN. Using long
	skipping to change at page 1, line 71 ¶		skipping to change at page 1, line 70 ¶
	This document describes a protocol for transmission of IP datagrams		This document describes a protocol for transmission of IP datagrams
	over MAPOS version 1 [1]. It explains IP datagram encapsulation in		over MAPOS version 1 [1]. It explains IP datagram encapsulation in
	HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for		HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for
	mapping between IP address and HDLC address.		mapping between IP address and HDLC address.
	2. Frame Format for Encapsulating IP Datagrams		2. Frame Format for Encapsulating IP Datagrams
	An IP datagram is transmitted in a MAPOS HDLC frame. The protocol		An IP datagram is transmitted in a MAPOS HDLC frame. The protocol
	field of the frame must contain the value 0x21 (hexadecimal) as		field of the frame must contain the value 0x21 (hexadecimal) as
	defined by the MAPOS Version 1 Assigned Numbers [4]. The information		defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. The
	field contains the IP datagram.		information field contains the IP datagram.
	The information field may be one to 65,280 octets in length; the		The information field may be one to 65,280 octets in length; the
	MTU(Maximum Transmission Unit) of MAPOS is 65,280 octets. Although		MTU(Maximum Transmission Unit) of MAPOS is 65,280 octets. Although
	the large MTU size can suppress the overhead of IP header processing,		the large MTU size can suppress the overhead of IP header processing,
	it may cause fragmentation anywhere along the path from the source to		it may cause fragmentation anywhere along the path from the source to
	the destination and result in performance degradation. To cope with		the destination and result in performance degradation. To cope with
	the issue, Path MTU discovery [5] may be used.		the issue, Path MTU discovery [5] may be used.
	3. Address Mapping		3. Address Mapping
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	IP datagram, the node must know the destination HDLC address		IP datagram, the node must know the destination HDLC address
	corresponding to the destination IP address. When its ARP cache does		corresponding to the destination IP address. When its ARP cache does
	not contain the corresponding entry, it uses ARP to translate the IP		not contain the corresponding entry, it uses ARP to translate the IP
	address to the HDLC address. That is, it broadcasts an ARP request		address to the HDLC address. That is, it broadcasts an ARP request
	containing the destination IP address. In response to the request,		containing the destination IP address. In response to the request,
	the node which has the IP address sends an ARP reply containing the		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.		HDLC address. The returned HDLC address is stored in the ARP cache.
	3.2.2 ARP Frame Format		3.2.2 ARP Frame Format
	The protocol field for an ARP frame must contain 0xfe01 (hexadecimal)		The protocol field for an ARP frame must contain 0xFE01 (hexadecimal)
	as defined by the MAPOS Version 1 Assigned Numbers [4]. The		as defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. The
	information field contains the ARP packet as shown below.		information field contains the ARP packet as shown below.
	+-------------------------+------------------------+		+-------------------------+------------------------+
	| Hardware Address Space | Protocol Address Space |		| Hardware Address Space | Protocol Address Space |
	| (1:ethernet) | (2048 in Dec) |		| (25:MAPOS) | (2048 in Dec) |
	| 16 bits | 16 bits |		| 16 bits | 16 bits |
	+------------+------------+------------------------+		+------------+------------+------------------------+
	| Hard Addr | Proto Addr | Operation Code |		| Hard Addr | Proto Addr | Operation Code |
	| Length (4) | Length (4) |(1:Request 2:Response) |		| Length (4) | Length (4) |(1:Request 2:Response) |
	| 8 bits | 8 bits | 16 bits |		| 8 bits | 8 bits | 16 bits |
	+------------+------------+------------------------+		+------------+------------+------------------------+
	| Sender HDLC Address 32 bits |		| Sender HDLC Address 32 bits |
	+--------------------------------------------------+		+--------------------------------------------------+
	| Sender IP Address 32 bits |		| Sender IP Address 32 bits |
	+--------------------------------------------------+		+--------------------------------------------------+
	| Target HDLC Address 32 bits |		| Target HDLC Address 32 bits |
	+--------------------------------------------------+		+--------------------------------------------------+
	| Target IP Address 32 bits |		| Target IP Address 32 bits |
	+--------------------------------------------------+		+--------------------------------------------------+
	Figure 5 ARP packet format		Figure 5 ARP packet format
	Hardware Address Space (16 bits)		Hardware Address Space (16 bits)
	MAPOS ARP uses the same value as Ethernet ARP. The hardware		The hardware address space for MAPOS ARP is 25 in Decimal as
	address space assigned for Ethernet networks is 1. ARP packets		defined by the ``MAPOS Version 1 Assigned Numbers'' [4].
	should thus be transmitted with a hardware-type code of 1 and
	should be accepted if and only if its hardware-type code is 1.
	Protocol Address Space (16 bits)		Protocol Address Space (16 bits)
	The protocol address space for IP is 2048 in Decimal.		The protocol address space for IP is 2048 in Decimal.
	Hardware Address Length (8 bits)		Hardware Address Length (8 bits)
	The hardware address length is 4.		The hardware address length is 4.
	Protocol Address Length (8 bits)		Protocol Address Length (8 bits)
	The protocol address length for IP is 4.		The protocol address length for IP is 4.
	Operation Code (16 bits)		Operation Code (16 bits)
	The operation code is 1 for request and 2 for reply.		The operation code is 1 for request and 2 for response.
	Sender hardware (HDLC) Address (32 bits)		Sender hardware (HDLC) Address (32 bits)
	Contains the sender's HDLC address in an ARP request, and the		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		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		placed in the least significant place of the 32-bit field. The
	remaining bits should be zero.		remaining bits should be zero.
	Sender Protocol (IP) Address (32 bits)		Sender Protocol (IP) Address (32 bits)
	Contains the sender's IP address in an ARP request, and the target		Contains the sender's IP address in an ARP request, and the target
	IP address in an ARP response.		IP address in an ARP response.
	Target hardware (HDLC) Address (32 bits)		Target hardware (HDLC) Address (32 bits)
	Contains unknown target HDLC address (all zeros) in an ARP request,		Contains unknown target HDLC address (all zeros) in an ARP request,
	and sender's HDLC address in an ARP response. The 8-bit HDLC		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		address is placed in the least significant place of the 32-bit
	field. The remaining bits should be zero.		field. The remaining bits should be zero.
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 27 ¶
	3.3 UNARP		3.3 UNARP
	An implementation MUST provide an UNARP mechanism to flush obsolete		An implementation MUST provide an UNARP mechanism to flush obsolete
	ARP cache entries. The mechanism is similar to the ARP extension		ARP cache entries. The mechanism is similar to the ARP extension
	described in [6]. When a node detects that its port has came up, it		described in [6]. When a node detects that its port has came up, it
	MUST broadcast an UNARP packet. It forces every other node to clear		MUST broadcast an UNARP packet. It forces every other node to clear
	the obsolete ARP entry which was created by the node previously		the obsolete ARP entry which was created by the node previously
	connected to the switch port. An UNARP is an ARP clear request with		connected to the switch port. An UNARP is an ARP clear request with
	the following values:		the following values:
	Hardware Address Space : 1		Hardware Address Space : 25
	Protocol Address Space : 2048		Protocol Address Space : 2048
	Hardware Address Length : 4		Hardware Address Length : 4
	Protocol Address Length : 4		Protocol Address Length : 4
	Operation Code : 3 (clear request)		Operation Code : 23 (MAPOS-UNARP)
	Sender hardware (HDLC) Address : HDLC address of the node		Sender hardware (HDLC) Address : HDLC address of the node
	Sender Protocol (IP) Address : 0.0.0.0 (unknown)		Sender Protocol (IP) Address : 0.0.0.0 (unknown)
	Target hardware (HDLC) Address : all 1		Target hardware (HDLC) Address : all 1
	Target Protocol (IP) Address : 255.255.255.255 (broadcast)		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
			defined by the ``MAPOS Version 1 Assigned Numbers'' [4].
			Operation Code (16 bits)
			The operation code is 23 for MAPOS-UNARP in Decimal as defined by
			the ``MAPOS Version 1 Assigned Numbers'' [4].
	The receiving node of the packet MUST clear the ARP entry		The receiving node of the packet MUST clear the ARP entry
	corresponding to the Sender Hardware (HDLC) Address.		corresponding to the Sender Hardware (HDLC) Address.
	3.4 ARP Cache Validation		3.4 ARP Cache Validation
	An implementation MUST provide a mechanism to remove out-of-date		An implementation MUST provide a mechanism to remove out-of-date
	cache entries and it SHOULD provide options to configure the timeout		cache entries and it SHOULD provide options to configure the timeout
	value [7]. One approach is to periodically time-out the cache		value [7]. One approach is to periodically time-out the cache
	entries, even if they are in use. This approach involves ARP cache		entries, even if they are in use. This approach involves ARP cache
	timeouts in the order of a minute or less.		timeouts in the order of a minute or less.
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 25 ¶
	described in [8]. Exceptions arise when these six bits are either		described in [8]. Exceptions arise when these six bits are either
	all zeros or all ones, in which case they should be altered to the		all zeros or all ones, in which case they should be altered to the
	bit sequence 111110.		bit sequence 111110.
	4. Security Considerations		4. Security Considerations
	Security issues are not discussed in this memo.		Security issues are not discussed in this memo.
	References		References
	[1] K. Murakami and M. Maruyama, "Multiple Access Protocol over		[1] K. Murakami and M. Maruyama, "MAPOS - Multiple Access Protocol
	SONET/SDH, Version 1," January 1997.		over SONET/SDH, Version 1," April 1997.
	[2] W. Simpson, editor, "PPP in HDLC-like Framing," RFC-1662,		[2] W. Simpson, editor, "PPP in HDLC-like Framing," RFC-1662,
	July 1994.		July 1994.
	[3] J. Postel, "Internet Protocol (IP)," RFC-791, September 1981.		[3] J. Postel, "Internet Protocol (IP)," RFC-791, September 1981.
	[4] M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned		[4] M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned Numbers,"
	Numbers," January 1997.		April 1997.
	[5] J. Mogul and S. Deering, "Path MTU Discovery," RFC1191,		[5] J. Mogul and S. Deering, "Path MTU Discovery," RFC1191,
	Nov.1990		Nov.1990
	[6] G. Malkin, "ARP Extension - UNARP," RFC-1868, November 1995.		[6] G. Malkin, "ARP Extension - UNARP," RFC-1868, November 1995.
	[7] R. Braden, "Requirements for Internet Hosts - Communication		[7] R. Braden, "Requirements for Internet Hosts - Communication
	Layers," RFC-1122, October 1989.		Layers," RFC-1122, October 1989.
	[8] S. Deering, "Host Extensions for IP Multicasting," RFC-1112,		[8] S. Deering, "Host Extensions for IP Multicasting," RFC-1112,
	skipping to change at line 279 ¶		skipping to change at line 286 ¶
	Tokyo-180, Japan		Tokyo-180, Japan
	E-mail: murakami@ntt-20.ecl.net		E-mail: murakami@ntt-20.ecl.net
	Mitsuru Maruyama		Mitsuru Maruyama
	NTT Software Laboratories		NTT Software Laboratories
	3-9-11, Midori-cho		3-9-11, Midori-cho
	Musashino-shi		Musashino-shi
	Tokyo-180, Japan		Tokyo-180, Japan
	E-mail: mitsuru@ntt-20.ecl.net		E-mail: mitsuru@ntt-20.ecl.net
	Internet-Draft Expires: June 1997 Internet-Draft		INTERNET-DRAFT EXPIRES OCTOBER 1997 INTERNET-DRAFT
End of changes. 22 change blocks.
	45 lines changed or deleted		53 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/