idnits 2.17.1 draft-ietf-ion-discov-atmarp-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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 101 has weird spacing: '...ar$addr a oct...' == Line 102 has weird spacing: '...ar$mask a oct...' == Line 134 has weird spacing: '...er/mask atmfS...' -- 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 15, 1998) is 9477 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) -- No information found for draft-ietf-ion-classic2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Mike Davison 3 Cisco Systems 4 May 15, 1998 6 ILMI-Based Server Discovery for ATMARP 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 This memo defines how ILMI-based Server Discovery, which provides a 31 method for ATM-attached hosts and routers to dynamically determine 32 the ATM address of servers, shall be used to locate ATMARP servers. 34 1. Introduction 36 Presently, configuring a host or router to use ATMARP [1,2] is 37 cumbersome and error-prone since it requires at least one ATM 38 addresses to be statically configured on each host or router in the 39 network. Further, it is impossible to implement a diskless host to 40 use ATMARP since local configuration is required. ILMI-based Server 41 Discovery, hereafter referred to as "server discovery," provides a 42 solution to these problems. 44 A brief overview of the Service Registry MIB, as defined by the ATM 45 Forum, is provided in this memo. The reader should consult [3] for a 46 complete description of this MIB, but the information contained here 47 is sufficient for an understanding of its use to support ATMARP 48 server discovery. 50 2. ILMI 4.0 Service Registry MIB 52 Server discovery utilizes the Service Registry MIB defined by the ATM 53 Forum in ILMI Specification Version 4.0 [3]. To support the existing 54 framework for IP over ATM, ATM switches must support the Service 55 Registry MIB. 57 A row in the service registry table [3] is defined as: 59 AtmfSrvcRegEntry ::= SEQUENCE { 60 atmfSrvcRegPort INTEGER, 61 atmfSrvcRegServiceID OBJECT IDENTIFIER, 62 atmfSrvcRegATMAddress AtmAddress, 63 atmfSrvcRegAddressIndex INTEGER, 64 atmfSrvcRegParm1 OCTET STRING 65 } 67 The definition of each field in this structure is: 69 atmfSrvcRegPort - The port number for which this entry contains 70 management information. The value of zero may be used to 71 indicate the ATM interface over which a management request 72 was received. 74 atmfSrvcRegServiceID - This is the service identifier which 75 uniquely identifies the type of service at the address 76 provided in the table. (See Appendix for ATMARP OID.) 78 atmfSrvcRegATMAddress - This is the full address of the service. 80 The ATM client will use this address to establish a connection 81 with the service. 83 atmfSrvcRegAddressIndex - An arbitrary integer to differentiate 84 multiple rows containing different ATM addresses for the same 85 service on the same port. 87 atmfSrvcRegParm1 - An octet string whose size and meaning is 88 determined by the value of atmfSrvcRegServiceID. 90 The service registry table is indexed by atmfSrvcRegPort, 91 atmfSrvcRegServiceID and atmfSrvcRegAddressIndex. 93 3. Service Parameter String 95 A generic parameter string is defined in the service registry table, 96 thus allowing protocol-specific parameters to be specified. To be 97 consistent with [1,2], the parameter string for ATMARP shall be: 99 ar$pro 16 bits Protocol type 100 ar$plen 8 bits Length of protocol address (a) 101 ar$addr a octets Network address 102 ar$mask a octets Network mask 104 Where 106 ar$pro - see Assigned Numbers for protocol type number for 107 protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD) 109 ar$plen - Length of the protocol address. (IPv4 is 4, IPv6 is 16) 111 ar$addr - Network address represented in network byte order 113 ar$mask - Network mask represented in network byte order 115 4. ATMARP Client Behavior 117 An ATMARP client will access the service registry table via ILMI 118 using the SNMP GetNext operator to "sweep" (SNMP parlance for a 119 linear search) beginning with {Port = 0, ServiceID = , 120 Index = 0} while holding the port number and the serviceID constant. 121 (Port number 0 is used within ILMI to indicate "this port.") 123 An ATMARP client with no local configuration, such as a diskless 124 workstation, must use the row with the lowest index value if multiple 125 ATMARP servers, possibly for multiple networks, are listed. 127 ATMARP clients that have local IP configuration must use a row that 128 has the appropriate IP address. For example, consider the case where 129 an IP router has 3 logical interfaces defined on a single physical 130 interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and 131 171.69.150.226/24. The router will sweep the service registry table 132 looking for a rows that have atmfSrvcRegParm1 values as shown below: 134 Network number/mask atmfSrvcRegParm1 135 -------------------- -------------------------------------- 136 1.0.0.0/8 08 00 04 01 00 00 00 ff 00 00 00 137 128.10.0.0/16 08 00 04 80 0a 00 00 ff ff 00 00 138 171.69.150.0/24 08 00 04 ab 45 96 00 ff ff ff 00 140 When the correct atmfSrvcRegParm1 values are located, the router may 141 then establish an SVC to the selected server and perform the 142 appropriate protocol operations. 144 Redundant ATMARP servers are supported with multiple rows in the 145 service registry table. This list of ATMARP servers is ordered with 146 the primary ATMARP server having the lowest index value. The ATMARP 147 client must attempt to utilize the primary ATMARP server before 148 utilizing a secondary ATMARP server. Administrators must ensure that 149 the listed ATMARP servers are synchronized via [4]. 151 5. ATMARP Server Behavior 153 An ATMARP server shall be locally configured. The ATMARP server may 154 retrieve the ATMARP service registry data to validate the results. If 155 an incorrect row is retrieved the error may be flagged in a locally 156 significant way. 158 6. Relationship with PNNI Augmented Routing 160 An augmented version PNNI ("PNNI Augmented Routing," or PAR) [5] is 161 being developed by the ATM Forum. PAR could potentially distribute 162 data such as ATMARP server addresses. Further, the ATM Forum is 163 developing a proxy mechanism for PAR (Proxy PAR) [6] that would allow 164 a UNI-attached host or router to access PAR data without a full PAR 165 implementation. 167 These mechanisms offer a promising way to manage the service registry 168 tables maintained on each switch in an ATM network, yet would not 169 require changes to the mechanism defined in this memo. Hosts and 170 routers can continue to utilize ILMI-based or Proxy PAR-based server 171 discovery and network administrators could manage the service 172 registry data with local configuration or via PAR and Proxy PAR. 174 7. Security Considerations 176 The server discovery mechanism is intended for environments where a 177 given ATM switch and its attached hosts or routers are in the same 178 administrative domain, hence no authentication is required. 180 Appendix - ATMARP Server Discovery MIB 182 SERVER-DISCOVERY-ATMARP DEFINITIONS ::= BEGIN 184 -- 185 -- This OID, assigned in the ATM Forum Service Registry MIB, names 186 -- ATMARP within the context of server discovery. It does not name 187 -- any managed objects. 188 -- 189 atmfSrvcRegATMARP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.3 } 191 END 193 References 195 [1] Laubach, M., "Classical IP and ARP over ATM," RFC 1577, 196 Hewlett-Packard Laboratories, December 1993. 198 [2] Laubach, M. Halpern, J., "Classical IP and ARP over ATM," 199 draft-ietf-ion-classic2-02.txt, (update to RFC 1577), March 1997. 201 [3] ATM Forum, "Integrated Local Management Interface (ILMI) 202 Specification Version 4.0," af-ilmi-0065.000, September, 1996. 204 [4] Luciani, J., and Fox, B., "A distributed ATMARP Service Using 205 SCSP," , April, 1997. 207 [5] Callon, R., et al., "An Overview of PNNI Augmented Routing," 208 ATM-Forum 96-0354, April, 1996. 210 [6] Przygienda, T., and Droz, P., "Proxy PAR," ATM-Forum 97-0495, 211 July, 1997. 213 Author's Address 215 Mike Davison 216 Cisco Systems 217 170 West Tasman Drive 218 San Jose, California 95134 220 Phone: (408) 526-4000 221 EMail: mike.davison@cisco.com