idnits 2.17.1 draft-ietf-ion-discov-nhrp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == Mismatching filename: the document gives the document name as 'draft-ietf-ion-discov-nhrp-03', but the file name used is 'draft-ietf-ion-discov-nhrp-05' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 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 7 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 167 has weird spacing: '...er/mask atmfS...' == Line 230 has weird spacing: '...for the purpo...' -- 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 (Nov 15, 1997) is 9659 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Mike Davison 3 Cisco Systems 4 Nov 15, 1997 6 ILMI-Based Server Discovery for NHRP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 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 months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow 24 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 This memo provides information for the Internet community. This memo 29 does not specify an Internet standard of any kind. Distribution of 30 this memo is unlimited. 32 Abstract 34 This memo defines how ILMI-based Server Discovery, which provides a 35 method for ATM-attached hosts and routers to dynamically determine 36 the ATM addresses of servers, shall be used to locate NHRP servers. 38 1. Introduction 40 Presently, configuring a host or router to use NHRP [1] is cumbersome 41 and error-prone since it requires at least one ATM addresses to be 42 statically configured on each host or router in the network. 43 Further, it is impossible to implement a diskless host to use NHRP 44 since local configuration is required. ILMI-based Server Discovery, 45 hereafter referred to as "server discovery," provides a solution to 46 these problems. 48 A brief overview of the Integrated Local Management Interface (ILMI) 49 and the Service Registry MIB, as defined by the ATM Forum, are 50 provided in this memo. The reader should consult [2] for a complete 51 description of ILMI and this MIB, but the information contained here 52 is sufficient for an understanding of its use to support NHRP server 53 discovery. 55 2. Integrated Local Management Interface 57 The Integrated Local Management Interface (ILMI) [2] provides a 58 mechanism for ATM-attached devices, such as hosts, routers, and ATM 59 switches, to transfer management information. It is based on the 60 Simple Network Management Protocol (SNMP), Version 1, and supports 61 get, get-next, set and trap operations. 63 The ILMI specification designates the switch side of the ATM link as 64 the 'network side' and the host/router side of the ATM link as the 65 'user side.' The Service Registry MIB, which is outlined in Section 66 3, is implmented on the network side and is queried from the user 67 side. 69 3. ILMI 4.0 Service Registry MIB 71 Server discovery utilizes the Service Registry MIB defined by the ATM 72 Forum in ILMI Specification Version 4.0 [2]. To support the existing 73 framework for IP over ATM, ATM switches must support the Service 74 Registry MIB. 76 A row in the service registry table [2] is defined as: 78 AtmfSrvcRegEntry ::= SEQUENCE { 79 atmfSrvcRegPort INTEGER, 80 atmfSrvcRegServiceID OBJECT IDENTIFIER, 81 atmfSrvcRegATMAddress AtmAddress, 82 atmfSrvcRegAddressIndex INTEGER, 83 atmfSrvcRegParm1 OCTET STRING 84 } 86 The definition of each field in this structure is: 88 atmfSrvcRegPort - The ATM port number for which this entry 89 contains 90 management information. The value of zero may be used to 91 indicate the ATM interface over which a management request 92 was received. 94 atmfSrvcRegServiceID - This is the service identifier that 95 uniquely identifies the type of service at the address 96 provided in the table. (See Section 3.2 for NHRP OID.) 98 atmfSrvcRegATMAddress - This is the full address of the service. 99 The ATM client will use this address to establish a connection 100 with the service. 102 atmfSrvcRegAddressIndex - An arbitrary integer to differentiate 103 multiple rows containing different ATM addresses for the same 104 service on the same port. 106 atmfSrvcRegParm1 - An octet string whose size and meaning is 107 determined by the value of atmfSrvcRegServiceID. 109 The service registry table is indexed by atmfSrvcRegPort, 110 atmfSrvcRegServiceID and atmfSrvcRegAddressIndex. 112 3.1 Service Parameter String 114 A generic parameter string is defined in the service registry table, 115 thus allowing protocol-specific parameters to be specified. To be 116 consistent with [1], the parameter string for NHRP shall be: 118 ar$pro.type 16 bits Protocol type 119 ar$pro.snap 40 bits Optional extension to protocol type 120 ar$plen 8 bits Length of protocol address 121 ar$addr plen octets Network address 122 ar$mask plen octets Network mask 124 Where 126 ar$pro.type - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD) 127 ar$pro.snap - See [1]. (IPv4 and IPv6 are 0) 129 ar$plen - Length of the protocol address. 130 (IPv4 is 4, IPv6 is 16) 132 ar$addr - Network address represented in network byte 133 order 135 ar$mask - Network mask represented in network byte order 137 3.2 Service Object Identifier 139 This OID, assigned in the ATM Forum Service Registry MIB, names 140 ATMARP within the context of server discovery. 142 atmfSrvcRegNHRP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.5 } 144 It does not name any managed objects, rather is used to locate 145 appropriate rows in the service registery table. 147 4. Next Hop Client Behavior 149 An Next Hop Client NHC) will access the service registry table via 150 ILMI using the SNMP GetNext operator to "sweep" (SNMP parlance for a 151 linear search) beginning with {Port = 0, ServiceID = , Index = 0} while holding the port number and the serviceID 153 constant. (Port number 0 is used within ILMI to indicate "this 154 port.") 156 An NHC with no local configuration, such as a diskless workstation, 157 must use the row with the lowest index value if multiple Next Hop 158 Server (NHS), possibly for multiple networks, are listed. 160 NHC that have local IP configuration must use a row that has the 161 appropriate IP address. For example, consider the case where an IP 162 router has 3 logical interfaces defined on a single physical 163 interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and 164 171.69.150.226/24. The router will sweep the service registry table 165 looking for rows that have atmfSrvcRegParm1 values as shown below: 167 Net number/mask atmfSrvcRegParm1 168 ---------------- -------------------------------------------------- 169 1.0.0.0/8 08 00 00 00 00 00 00 04 01 00 00 00 ff 00 00 00 170 128.10.0.0/16 08 00 00 00 00 00 00 04 80 0a 00 00 ff ff 00 00 171 171.69.150.0/24 08 00 00 00 00 00 00 04 ab 45 96 00 ff ff ff 00 173 When the correct atmfSrvcRegParm1 values are located, the router may 174 then establish an SVC to the selected NHS and perform the appropriate 175 protocol operations. 177 Redundant NHS are supported with multiple rows in the service 178 registry table. This list of NHS is ordered with the primary NHS 179 having the lowest index value. The NHC must attempt to utilize the 180 primary NHS before utilizing a secondary NHS. Administrators must 181 ensure that the listed NHS are synchronized. 183 5. NHRP Server (NHS) Behavior 185 A Next Hop Server (NHS) shall be locally configured. The NHS may 186 retrieve the NHRP service registry data to validate the results. If 187 an incorrect row is retrieved the error may be flagged in a locally 188 significant way. 190 6. Relationship with PNNI Augmented Routing 192 An augmented version PNNI ("PNNI Augmented Routing," or PAR) [3] has 193 been developed by the ATM Forum. PAR can distribute data such as NHS 194 addresses. Further, the ATM Forum is developing a proxy mechanism for 195 PAR (Proxy PAR) that would allow a UNI-attached host or router to 196 access PAR data without a full PAR implementation. 198 These mechanisms offer a promising way to manage the service registry 199 tables maintained on each switch in an ATM network, yet would not 200 require changes to the mechanism defined in this memo. Hosts and 201 routers can continue to utilize ILMI-based or Proxy PAR-based server 202 discovery and network administrators could manage the service 203 registry data with local configuration or via PAR and Proxy PAR. 205 7. Security Considerations 207 The server discovery mechanism is built on the ILMI managment 208 framework and the security embodied in that framework. Access, to 209 user- or network-side information is controlled by MIB design rather 210 than protocol security mechanisms. 212 The service registery MIB, the table containing information for 213 server discovery, is defined in [2] with read-only access. This means 214 that any user-side device may query the service registry, but may not 215 modify the service registry via ILMI. Instead, the sevice registry 216 table must be modified via local configuration on the ATM switch. 218 Appendix - Copyright 220 Copyright (C) The Internet Society (date). All Rights Reserved. 222 This document and translations of it may be copied and furnished to 223 others, and derivative works that comment on or otherwise explain it 224 or assist in its implmentation may be prepared, copied, published and 225 distributed, in whole or in part, without restriction of any kind, 226 provided that the above copyright notice and this paragraph are 227 included on all such copies and derivative works. However, this 228 document itself may not be modified in any way, such as by removing 229 the copyright notice or references to the Internet Society or other 230 Internet organizations, except as needed for the purpose of 231 developing Internet standards in which case the procedures for 232 copyrights defined in the Internet Standards process must be 233 followed, or as required to translate it into languages other than 234 English. 236 The limited permissions granted above are perpetual and will not be 237 revoked by the Internet Society or its successors or assigns. 239 This document and the information contained herein is provided on an 240 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 241 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 242 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 243 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 244 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 246 References 248 [1] Luciani, J., et al., "NBMA Next Hop Resolution Protocol," 249 , March, 1997. 251 [2] ATM Forum, "Integrated Local Management Interface (ILMI) 252 Specification Version 4.0," af-ilmi-0065.000, September, 1996. 254 [3] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0," 255 af-ra-0104, January, 1999. 257 Author's Address 259 Mike Davison 260 Cisco Systems 261 170 West Tasman Drive 262 San Jose, California 95134 264 Phone: (408) 526-4000 265 EMail: mike.davison@cisco.com