idnits 2.17.1 draft-rfced-info-maruyama-00.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-20) 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 is 1 instance 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 182: '...n implementation MUST provide an UNARP...' RFC 2119 keyword, line 185: '... MUST broadcast an UNARP packet. It...' RFC 2119 keyword, line 200: '...de of the packet MUST clear the ARP en...' RFC 2119 keyword, line 205: '...n implementation MUST provide a mechan...' RFC 2119 keyword, line 206: '...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 (January 1997) is 9957 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. -------------------------------------------------------------------------------- 1 Internet-Draft Expires: June 1997 Internet-Draft 2 Network Working Group K. Murakami 3 Internet-Draft M. Maruyama 4 Category: Informational NTT Laboratories 5 January 1997 7 IP over MAPOS Version 1 8 10 Status of this Memo 12 This document is an Internet-Draft.Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 This document provides information for the Internet community. This 30 memo does not specify an Internet standard of any kind. Distribution 31 of this memo is unlimited. 33 This memo documents a mechanism for supporting the Internet Protocol 34 (IP) on Version 1 of the Multiple Access Protocol over SONET/SDH. 35 This protocol is NOT the product of an IETF working group nor is it a 36 standards track document. It has not necessarily benefited from the 37 widespread and in-depth community review that standards track 38 documents receive. 40 Abstract 42 This document describes a protocol for transmission of the Internet 43 Protocol (IP) over Multiple Access Over SONET/SDH (MAPOS) version 1. 44 MAPOS is a link layer protocol and provides multiple access 45 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 information 70 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 | (1:ethernet) | (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 MAPOS ARP uses the same value as Ethernet ARP. The hardware 137 address space assigned for Ethernet networks is 1. ARP packets 138 should thus be transmitted with a hardware-type code of 1 and 139 should be accepted if and only if its hardware-type code is 1. 141 Protocol Address Space (16 bits) 143 The protocol address space for IP is 2048 in Decimal. 145 Hardware Address Length (8 bits) 147 The hardware address length is 4. 149 Protocol Address Length (8 bits) 151 The protocol address length for IP is 4. 153 Operation Code (16 bits) 155 The operation code is 1 for request and 2 for reply. 157 Sender hardware (HDLC) Address (32 bits) 159 Contains the sender's HDLC address in an ARP request, and the 160 target HDLC address in an ARP response. The 8-bit HDLC address is 161 placed in the least significant place of the 32-bit field. The 162 remaining bits should be zero. 164 Sender Protocol (IP) Address (32 bits) 165 Contains the sender's IP address in an ARP request, and the target 166 IP address in an ARP response. 168 Target hardware (HDLC) Address (32 bits) 170 Contains unknown target HDLC address (all zeros) in an ARP request, 171 and sender's HDLC address in an ARP response. The 8-bit HDLC 172 address is placed in the least significant place of the 32-bit 173 field. The remaining bits should be zero. 175 Target Protocol (IP) Address (32 bits) 177 Contains the target IP address in an ARP request, and the sender's 178 IP address in an ARP response. 180 3.3 UNARP 182 An implementation MUST provide an UNARP mechanism to flush obsolete 183 ARP cache entries. The mechanism is similar to the ARP extension 184 described in [6]. When a node detects that its port has came up, it 185 MUST broadcast an UNARP packet. It forces every other node to clear 186 the obsolete ARP entry which was created by the node previously 187 connected to the switch port. An UNARP is an ARP clear request with 188 the following values: 190 Hardware Address Space : 1 191 Protocol Address Space : 2048 192 Hardware Address Length : 4 193 Protocol Address Length : 4 194 Operation Code : 3 (clear request) 195 Sender hardware (HDLC) Address : HDLC address of the node 196 Sender Protocol (IP) Address : 0.0.0.0 (unknown) 197 Target hardware (HDLC) Address : all 1 198 Target Protocol (IP) Address : 255.255.255.255 (broadcast) 200 The receiving node of the packet MUST clear the ARP entry 201 corresponding to the Sender Hardware (HDLC) Address. 203 3.4 ARP Cache Validation 205 An implementation MUST provide a mechanism to remove out-of-date 206 cache entries and it SHOULD provide options to configure the timeout 207 value [7]. One approach is to periodically time-out the cache 208 entries, even if they are in use. This approach involves ARP cache 209 timeouts in the order of a minute or less. 211 3.5 IP Broadcast and multicast 213 In broadcast and multicast frames, the most significant bit of the 214 HDLC address must be 1 [1]. In addition, the least significant bit 215 must always be 1 to indicate the end of the field [1]. 217 In the case of IP broadcast, the remaining six bits of the HDLC 218 address must be all 1s. That is, it should be mapped to the HDLC 219 broadcast address 0xFF (hexadecimal). 221 In the case of IP multicast, the remaining six bits of the HDLC 222 address must contain the lowest-order six bits of the IP multicast 223 group address. It resembles IP multicast extension for ethernet 224 described in [8]. Exceptions arise when these six bits are either 225 all zeros or all ones, in which case they should be altered to the 226 bit sequence 111110. 228 4. Security Considerations 230 Security issues are not discussed in this memo. 232 References 234 [1] K. Murakami and M. Maruyama, "Multiple Access Protocol over 235 SONET/SDH, Version 1," January 1997. 237 [2] W. Simpson, editor, "PPP in HDLC-like Framing," RFC-1662, 238 July 1994. 240 [3] J. Postel, "Internet Protocol (IP)," RFC-791, September 1981. 242 [4] M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned 243 Numbers," January 1997. 245 [5] J. Mogul and S. Deering, "Path MTU Discovery," RFC1191, 246 Nov.1990 248 [6] G. Malkin, "ARP Extension - UNARP," RFC-1868, November 1995. 250 [7] R. Braden, "Requirements for Internet Hosts - Communication 251 Layers," RFC-1122, October 1989. 253 [8] S. Deering, "Host Extensions for IP Multicasting," RFC-1112, 254 August 1989. 256 Acknowledgements 258 The authors would like to acknowledge the contributions and thoughtful 259 suggestions of John P. Mullaney, Clark Bremer, Masayuki Kobayashi, 260 Paul Francis, Toshiaki Yoshida, and Takahiro Sajima. 262 Author's Address 264 Ken Murakami 265 NTT Software Laboratories 266 3-9-11, Midori-cho 267 Musashino-shi 268 Tokyo-180, Japan 269 E-mail: murakami@ntt-20.ecl.net 271 Mitsuru Maruyama 272 NTT Software Laboratories 273 3-9-11, Midori-cho 274 Musashino-shi 275 Tokyo-180, Japan 276 E-mail: mitsuru@ntt-20.ecl.net 278 Internet-Draft Expires: June 1997 Internet-Draft