idnits 2.17.1 draft-rfced-info-maruyama-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 76 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 181: '...n implementation MUST provide an UNARP...' RFC 2119 keyword, line 184: '... MUST broadcast an UNARP packet. It...' RFC 2119 keyword, line 209: '...de of the packet MUST clear the ARP en...' RFC 2119 keyword, line 214: '...n implementation MUST provide a mechan...' RFC 2119 keyword, line 215: '...e entries and it SHOULD provide option...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1997) is 9870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT EXPIRES OCTOBER 1997 INTERNET-DRAFT 4 Network Working Group K. Murakami 5 INTERNET-DRAFT M. Maruyama 6 Category: Informational NTT Laboratories 7 April 1997 9 IPv4 over MAPOS Version 1 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as ``work 23 in progress.'' 25 To learn the current status of any Internet-Draft, please check 26 the ``1id-abstracts.txt'' listing contained in the Internet- 27 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 28 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 29 Coast), or ftp.isi.edu (US West Coast). 31 Author's Note: 33 This memo documents a mechanism for supporting Version 4 of the 34 Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol 35 over SONET/SDH. This document is NOT the product of an IETF working 36 group nor is it a standards track document. It has not necessarily 37 benefited from the widespread and in-depth community review that 38 standards track documents receive. 40 Abstract 42 This document describes a protocol for transmission of the Internet 43 Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) 44 version 1. MAPOS is a link layer protocol and provides multiple 45 access capability over SONET/SDH links. IP runs on top of MAPOS. This 46 document explains IP datagram encapsulation in HDLC frame of MAPOS, 47 and the Address Resolution Protocol (ARP). 49 1. Introduction 51 Multiple Access Protocol over SONET/SDH (MAPOS) [1] is a high-speed 52 link-layer protocol that provides multiple access capability over 53 SONET/SDH. Its frame format is based on the HDLC-like framing [2] for 54 PPP. A component called ``Frame Switch'' [1] allows multiple nodes 55 to be connected together in a star topology to form a LAN. Using long 56 haul SONET/SDH links, the nodes on such a ``SONET-LAN'' can span over 57 a wide geographical area. The Internet Protocol (IP) [3] datagrams 58 are transmitted in MAPOS HDLC frames [1]. 60 This document describes a protocol for transmission of IP datagrams 61 over MAPOS version 1 [1]. It explains IP datagram encapsulation in 62 HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for 63 mapping between IP address and HDLC address. 65 2. Frame Format for Encapsulating IP Datagrams 67 An IP datagram is transmitted in a MAPOS HDLC frame. The protocol 68 field of the frame must contain the value 0x21 (hexadecimal) as 69 defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. The 70 information field contains the IP datagram. 72 The information field may be one to 65,280 octets in length; the 73 MTU(Maximum Transmission Unit) of MAPOS is 65,280 octets. Although 74 the large MTU size can suppress the overhead of IP header processing, 75 it may cause fragmentation anywhere along the path from the source to 76 the destination and result in performance degradation. To cope with 77 the issue, Path MTU discovery [5] may be used. 79 3. Address Mapping 81 This section explains MAPOS ARP and the mapping of special addresses. 83 3.1 ARP cache 85 Each node on a MAPOS network maintains an ``ARP cache'' that maps 86 destination IP addresses to their corresponding 8-bit HDLC addresses. 87 Entries are added to this cache either manually or by the Address 88 Resolution Protocol described below. Entries are removed from this 89 cache manually, by the UNARP mechanism, or by ARP cache validation 90 mechanism. An implementation must provide a mechanism for manually 91 adding or removing arbitrary ARP cache entries. 93 3.2 Address Resolution Protocol (ARP) 95 This subsection describes MAPOS ARP protocol and its packet format. 97 3.2.1 Overview 99 The MAPOS ARP is similar to that for ethernet. Prior to sending an 100 IP datagram, the node must know the destination HDLC address 101 corresponding to the destination IP address. When its ARP cache does 102 not contain the corresponding entry, it uses ARP to translate the IP 103 address to the HDLC address. That is, it broadcasts an ARP request 104 containing the destination IP address. In response to the request, 105 the node which has the IP address sends an ARP reply containing the 106 HDLC address. The returned HDLC address is stored in the ARP cache. 108 3.2.2 ARP Frame Format 110 The protocol field for an ARP frame must contain 0xFE01 (hexadecimal) 111 as defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. The 112 information field contains the ARP packet as shown below. 114 +-------------------------+------------------------+ 115 | Hardware Address Space | Protocol Address Space | 116 | (25:MAPOS) | (2048 in Dec) | 117 | 16 bits | 16 bits | 118 +------------+------------+------------------------+ 119 | Hard Addr | Proto Addr | Operation Code | 120 | Length (4) | Length (4) |(1:Request 2:Response) | 121 | 8 bits | 8 bits | 16 bits | 122 +------------+------------+------------------------+ 123 | Sender HDLC Address 32 bits | 124 +--------------------------------------------------+ 125 | Sender IP Address 32 bits | 126 +--------------------------------------------------+ 127 | Target HDLC Address 32 bits | 128 +--------------------------------------------------+ 129 | Target IP Address 32 bits | 130 +--------------------------------------------------+ 132 Figure 5 ARP packet format 134 Hardware Address Space (16 bits) 136 The hardware address space for MAPOS ARP is 25 in Decimal as 137 defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. 139 Protocol Address Space (16 bits) 141 The protocol address space for IP is 2048 in Decimal. 143 Hardware Address Length (8 bits) 145 The hardware address length is 4. 147 Protocol Address Length (8 bits) 149 The protocol address length for IP is 4. 151 Operation Code (16 bits) 153 The operation code is 1 for request and 2 for response. 155 Sender hardware (HDLC) Address (32 bits) 157 Contains the sender's HDLC address in an ARP request, and the 158 target HDLC address in an ARP response. The 8-bit HDLC address is 159 placed in the least significant place of the 32-bit field. The 160 remaining bits should be zero. 162 Sender Protocol (IP) Address (32 bits) 164 Contains the sender's IP address in an ARP request, and the target 165 IP address in an ARP response. 167 Target hardware (HDLC) Address (32 bits) 169 Contains unknown target HDLC address (all zeros) in an ARP request, 170 and sender's HDLC address in an ARP response. The 8-bit HDLC 171 address is placed in the least significant place of the 32-bit 172 field. The remaining bits should be zero. 174 Target Protocol (IP) Address (32 bits) 176 Contains the target IP address in an ARP request, and the sender's 177 IP address in an ARP response. 179 3.3 UNARP 181 An implementation MUST provide an UNARP mechanism to flush obsolete 182 ARP cache entries. The mechanism is similar to the ARP extension 183 described in [6]. When a node detects that its port has came up, it 184 MUST broadcast an UNARP packet. It forces every other node to clear 185 the obsolete ARP entry which was created by the node previously 186 connected to the switch port. An UNARP is an ARP clear request with 187 the following values: 189 Hardware Address Space : 25 190 Protocol Address Space : 2048 191 Hardware Address Length : 4 192 Protocol Address Length : 4 193 Operation Code : 23 (MAPOS-UNARP) 194 Sender hardware (HDLC) Address : HDLC address of the node 195 Sender Protocol (IP) Address : 0.0.0.0 (unknown) 196 Target hardware (HDLC) Address : all 1 197 Target Protocol (IP) Address : 255.255.255.255 (broadcast) 199 Hardware Address Space (16 bits) 201 The hardware address space for MAPOS ARP is 25 in Decimal as 202 defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. 204 Operation Code (16 bits) 206 The operation code is 23 for MAPOS-UNARP in Decimal as defined by 207 the ``MAPOS Version 1 Assigned Numbers'' [4]. 209 The receiving node of the packet MUST clear the ARP entry 210 corresponding to the Sender Hardware (HDLC) Address. 212 3.4 ARP Cache Validation 214 An implementation MUST provide a mechanism to remove out-of-date 215 cache entries and it SHOULD provide options to configure the timeout 216 value [7]. One approach is to periodically time-out the cache 217 entries, even if they are in use. This approach involves ARP cache 218 timeouts in the order of a minute or less. 220 3.5 IP Broadcast and multicast 221 In broadcast and multicast frames, the most significant bit of the 222 HDLC address must be 1 [1]. In addition, the least significant bit 223 must always be 1 to indicate the end of the field [1]. 225 In the case of IP broadcast, the remaining six bits of the HDLC 226 address must be all 1s. That is, it should be mapped to the HDLC 227 broadcast address 0xFF (hexadecimal). 229 In the case of IP multicast, the remaining six bits of the HDLC 230 address must contain the lowest-order six bits of the IP multicast 231 group address. It resembles IP multicast extension for ethernet 232 described in [8]. Exceptions arise when these six bits are either 233 all zeros or all ones, in which case they should be altered to the 234 bit sequence 111110. 236 4. Security Considerations 238 Security issues are not discussed in this memo. 240 References 242 [1] K. Murakami and M. Maruyama, "MAPOS - Multiple Access Protocol 243 over SONET/SDH, Version 1," April 1997. 245 [2] W. Simpson, editor, "PPP in HDLC-like Framing," RFC-1662, 246 July 1994. 248 [3] J. Postel, "Internet Protocol (IP)," RFC-791, September 1981. 250 [4] M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned Numbers," 251 April 1997. 253 [5] J. Mogul and S. Deering, "Path MTU Discovery," RFC1191, 254 Nov.1990 256 [6] G. Malkin, "ARP Extension - UNARP," RFC-1868, November 1995. 258 [7] R. Braden, "Requirements for Internet Hosts - Communication 259 Layers," RFC-1122, October 1989. 261 [8] S. Deering, "Host Extensions for IP Multicasting," RFC-1112, 262 August 1989. 264 Acknowledgements 266 The authors would like to acknowledge the contributions and thoughtful 267 suggestions of John P. Mullaney, Clark Bremer, Masayuki Kobayashi, 268 Paul Francis, Toshiaki Yoshida, and Takahiro Sajima. 270 Author's Address 272 Ken Murakami 273 NTT Software Laboratories 274 3-9-11, Midori-cho 275 Musashino-shi 276 Tokyo-180, Japan 277 E-mail: murakami@ntt-20.ecl.net 279 Mitsuru Maruyama 280 NTT Software Laboratories 281 3-9-11, Midori-cho 282 Musashino-shi 283 Tokyo-180, Japan 284 E-mail: mitsuru@ntt-20.ecl.net