idnits 2.17.1 draft-rfced-info-murakami-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 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 3 instances of too long lines in the document, the longest one being 8 characters 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 180: '...n implementation MUST provide an UNARP...' RFC 2119 keyword, line 183: '... MUST broadcast an UNARP packet. It...' RFC 2119 keyword, line 208: '...de of the packet MUST clear the ARP en...' RFC 2119 keyword, line 213: '...n implementation MUST provide a mechan...' RFC 2119 keyword, line 214: '...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 (May 1997) is 9840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT EXPIRES NOVEMBER 1997 INTERNET-DRAFT 3 Network Working Group K. Murakami 4 INTERNET-DRAFT M. Maruyama 5 Category: Informational NTT Laboratories 6 May 1997 8 IPv4 over MAPOS Version 1 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Authors' Note 32 This memo documents a mechanism for supporting Version 4 of the 33 Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol 34 over SONET/SDH. This document is NOT the product of an IETF working 35 group nor is it a standards track document. It has not necessarily 36 benefited from the widespread and in-depth community review that 37 standards track documents receive. 39 Abstract 41 This document describes a protocol for transmission of the Internet 42 Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) 43 version 1. MAPOS is a link layer protocol and provides multiple 44 access capability over SONET/SDH links. IP runs on top of MAPOS. This 45 document explains IP datagram encapsulation in HDLC frame of MAPOS, 46 and the Address Resolution Protocol (ARP). 48 1. Introduction 50 Multiple Access Protocol over SONET/SDH (MAPOS) [1] is a high-speed 51 link-layer protocol that provides multiple access capability over 52 SONET/SDH. Its frame format is based on the HDLC-like framing [2] for 53 PPP. A component called ``Frame Switch'' [1] allows multiple nodes 54 to be connected together in a star topology to form a LAN. Using long 55 haul SONET/SDH links, the nodes on such a ``SONET-LAN'' can span over 56 a wide geographical area. The Internet Protocol (IP) [3] datagrams 57 are transmitted in MAPOS HDLC frames [1]. 59 This document describes a protocol for transmission of IP datagrams 60 over MAPOS version 1 [1]. It explains IP datagram encapsulation in 61 HDLC frame of MAPOS, and ARP (Address Resolution Protocol) for 62 mapping between IP address and HDLC address. 64 2. Frame Format for Encapsulating IP Datagrams 66 An IP datagram is transmitted in a MAPOS HDLC frame. The protocol 67 field of the frame must contain the value 0x0021 (hexadecimal) as 68 defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. The 69 information field contains the IP datagram. 71 The information field may be one to 65,280 octets in length; the 72 MTU(Maximum Transmission Unit) of MAPOS is 65,280 octets. Although 73 the large MTU size can suppress the overhead of IP header processing, 74 it may cause fragmentation anywhere along the path from the source to 75 the destination and result in performance degradation. To cope with 76 the issue, Path MTU discovery [5] may be used. 78 3. Address Mapping 80 This section explains MAPOS ARP and the mapping of special addresses. 82 3.1 ARP cache 84 Each node on a MAPOS network maintains an ``ARP cache'' that maps 85 destination IP addresses to their corresponding 8-bit HDLC addresses. 86 Entries are added to this cache either manually or by the Address 87 Resolution Protocol described below. Entries are removed from this 88 cache manually, by the UNARP mechanism, or by ARP cache validation 89 mechanism. An implementation must provide a mechanism for manually 90 adding or removing arbitrary ARP cache entries. 92 3.2 Address Resolution Protocol (ARP) 94 This subsection describes MAPOS ARP protocol and its packet format. 96 3.2.1 Overview 98 The MAPOS ARP is similar to that for ethernet. Prior to sending an 99 IP datagram, the node must know the destination HDLC address 100 corresponding to the destination IP address. When its ARP cache does 101 not contain the corresponding entry, it uses ARP to translate the IP 102 address to the HDLC address. That is, it broadcasts an ARP request 103 containing the destination IP address. In response to the request, 104 the node which has the IP address sends an ARP reply containing the 105 HDLC address. The returned HDLC address is stored in the ARP cache. 107 3.2.2 ARP Frame Format 109 The protocol field for an ARP frame must contain 0xFE01 (hexadecimal) 110 as defined by the ``MAPOS Version 1 Assigned Numbers'' [4]. The 111 information field contains the ARP packet as shown below. 113 +-------------------------+------------------------+ 114 | Hardware Address Space | Protocol Address Space | 115 | (25:MAPOS) | (2048 in Dec) | 116 | 16 bits | 16 bits | 117 +------------+------------+------------------------+ 118 | Hard Addr | Proto Addr | Operation Code | 119 | Length (4) | Length (4) |(1:Request 2:Response) | 120 | 8 bits | 8 bits | 16 bits | 121 +------------+------------+------------------------+ 122 | Sender HDLC Address 32 bits | 123 +--------------------------------------------------+ 124 | Sender IP Address 32 bits | 125 +--------------------------------------------------+ 126 | Target HDLC Address 32 bits | 127 +--------------------------------------------------+ 128 | Target IP Address 32 bits | 129 +--------------------------------------------------+ 131 Figure 5 ARP packet format 133 Hardware Address Space (16 bits) 135 The hardware address space for MAPOS ARP is 25 in Decimal as 136 assigned by IANA [6]. 138 Protocol Address Space (16 bits) 140 The protocol address space for IP is 2048 in Decimal. 142 Hardware Address Length (8 bits) 144 The hardware address length is 4. 146 Protocol Address Length (8 bits) 148 The protocol address length for IP is 4. 150 Operation Code (16 bits) 152 The operation code is 1 for request and 2 for response. 154 Sender hardware (HDLC) Address (32 bits) 156 Contains the sender's HDLC address in an ARP request, and the 157 target HDLC address in an ARP response. The 8-bit HDLC address is 158 placed in the least significant place of the 32-bit field. The 159 remaining bits should be zero. 161 Sender Protocol (IP) Address (32 bits) 163 Contains the sender's IP address in an ARP request, and the target 164 IP address in an ARP response. 166 Target hardware (HDLC) Address (32 bits) 168 Contains unknown target HDLC address (all zeros) in an ARP request, 169 and sender's HDLC address in an ARP response. The 8-bit HDLC 170 address is placed in the least significant place of the 32-bit 171 field. The remaining bits should be zero. 173 Target Protocol (IP) Address (32 bits) 175 Contains the target IP address in an ARP request, and the sender's 176 IP address in an ARP response. 178 3.3 UNARP 180 An implementation MUST provide an UNARP mechanism to flush obsolete 181 ARP cache entries. The mechanism is similar to the ARP extension 182 described in [7]. When a node detects that its port has came up, it 183 MUST broadcast an UNARP packet. It forces every other node to clear 184 the obsolete ARP entry which was created by the node previously 185 connected to the switch port. An UNARP is an ARP clear request with 186 the following values: 188 Hardware Address Space : 25 189 Protocol Address Space : 2048 190 Hardware Address Length : 4 191 Protocol Address Length : 4 192 Operation Code : 23 (MAPOS-UNARP) 193 Sender hardware (HDLC) Address : HDLC address of the node 194 Sender Protocol (IP) Address : 0.0.0.0 (unknown) 195 Target hardware (HDLC) Address : all 1 196 Target Protocol (IP) Address : 255.255.255.255 (broadcast) 198 Hardware Address Space (16 bits) 200 The hardware address space for MAPOS ARP is 25 in Decimal as 201 assigned by IANA [6]. 203 Operation Code (16 bits) 205 The operation code is 23 for MAPOS-UNARP in Decimal as assigned by 206 IANA [6]. 208 The receiving node of the packet MUST clear the ARP entry 209 corresponding to the Sender Hardware (HDLC) Address. 211 3.4 ARP Cache Validation 213 An implementation MUST provide a mechanism to remove out-of-date 214 cache entries and it SHOULD provide options to configure the timeout 215 value [8]. One approach is to periodically time-out the cache 216 entries, even if they are in use. This approach involves ARP cache 217 timeouts in the order of a minute or less. 219 3.5 IP Broadcast and multicast 220 In broadcast and multicast frames, the most significant bit of the 221 HDLC address must be 1 [1]. In addition, the least significant bit 222 must always be 1 to indicate the end of the field [1]. 224 In the case of IP broadcast, the remaining six bits of the HDLC 225 address must be all 1s. That is, it should be mapped to the HDLC 226 broadcast address 0xFF (hexadecimal). 228 In the case of IP multicast, the remaining six bits of the HDLC 229 address must contain the lowest-order six bits of the IP multicast 230 group address. It resembles IP multicast extension for ethernet 231 described in [9]. Exceptions arise when these six bits are either 232 all zeros or all ones, in which case they should be altered to the 233 bit sequence 111110. 235 4. Security Considerations 237 Security issues are not discussed in this memo. 239 References 241 [1] K. Murakami and M. Maruyama, "MAPOS - Multiple Access Protocol 242 over SONET/SDH, Version 1," May 1997. 244 [2] W. Simpson, editor, "PPP in HDLC-like Framing," RFC-1662, 245 July 1994. 247 [3] J. Postel, "Internet Protocol (IP)," RFC-791, September 1981. 249 [4] M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned Numbers," 250 May 1997. 252 [5] J. Mogul and S. Deering, "Path MTU Discovery," RFC1191, 253 Nov.1990 255 [6] IANA, "IANA-Assignments", http://www.isi.edu/div7/iana/assignments.html 257 [7] G. Malkin, "ARP Extension - UNARP," RFC-1868, November 1995. 259 [8] R. Braden, "Requirements for Internet Hosts - Communication 260 Layers," RFC-1122, October 1989. 262 [9] S. Deering, "Host Extensions for IP Multicasting," RFC-1112, 263 August 1989. 265 Acknowledgements 267 The authors would like to acknowledge the contributions and thoughtful 268 suggestions of John P. Mullaney, Clark Bremer, Masayuki Kobayashi, 269 Paul Francis, Toshiaki Yoshida, and Takahiro Sajima. 271 Author's Address 273 Ken Murakami 274 NTT Software Laboratories 275 3-9-11, Midori-cho 276 Musashino-shi 277 Tokyo-180, Japan 278 E-mail: murakami@ntt-20.ecl.net 280 Mitsuru Maruyama 281 NTT Software Laboratories 282 3-9-11, Midori-cho 283 Musashino-shi 284 Tokyo-180, Japan 285 E-mail: mitsuru@ntt-20.ecl.net