doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2603.txt b/doc/rfc/rfc2603.txt
new file mode 100644
index 0000000..c851817
--- /dev/null
+++ b/doc/rfc/rfc2603.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       M. Davison
+Request for Comments: 2603                               Cisco Systems
+Category:  Standards Track                                   June 1999
+
+
+                  ILMI-Based Server Discovery for NHRP
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This memo defines how ILMI-based Server Discovery, which provides a
+   method for ATM-attached hosts and routers to dynamically determine
+   the ATM addresses of servers, shall be used to locate NHRP servers.
+
+1. Introduction
+
+   Presently, configuring a host or router to use NHRP [1] is cumbersome
+   and error-prone since it requires at least one ATM address to be
+   statically configured on each host or router in the network.
+   Further, it is impossible to implement a diskless host to use NHRP
+   since local configuration is required.  ILMI-based Server Discovery,
+   hereafter referred to as "server discovery," provides a solution to
+   these problems.
+
+   A brief overview of the Integrated Local Management Interface (ILMI)
+   and the Service Registry MIB, as defined by the ATM Forum, are
+   provided in this memo. The reader should consult [2] for a complete
+   description of ILMI and this MIB, but the information contained here
+   is sufficient for an understanding of its use to support NHRP server
+   discovery.
+
+2. Integrated Local Management Interface
+
+   The Integrated Local Management Interface (ILMI) [2] provides a
+   mechanism for ATM-attached devices, such as hosts, routers, and ATM
+   switches, to transfer management information. It is based on the
+   Simple Network Management Protocol (SNMP), Version 1, and supports
+
+
+
+Davison                     Standards Track                     [Page 1]
+
+RFC 2603          ILMI-Based Server Discovery for NHRP         June 1999
+
+
+   get, get-next, set and trap operations.
+
+   The ILMI specification designates the switch side of the ATM link as
+   the 'network side' and the host/router side of the ATM link as the '
+   user side.' The Service Registry MIB, which is outlined in Section 3,
+   is implmented on the network side and is queried from the user side.
+
+3. ILMI 4.0 Service Registry MIB
+
+   Server discovery utilizes the Service Registry MIB defined by the ATM
+   Forum in ILMI Specification Version 4.0 [2]. To support the existing
+   framework for IP over ATM, ATM switches must support the Service
+   Registry MIB.
+
+   A row in the service registry table [2] is defined as:
+
+      AtmfSrvcRegEntry ::= SEQUENCE {
+          atmfSrvcRegPort          INTEGER,
+          atmfSrvcRegServiceID     OBJECT IDENTIFIER,
+          atmfSrvcRegATMAddress    AtmAddress,
+          atmfSrvcRegAddressIndex  INTEGER,
+          atmfSrvcRegParm1         OCTET STRING
+      }
+
+   The definition of each field in this structure is:
+
+      atmfSrvcRegPort - The ATM port number for which this entry
+          contains management information. The value of zero may be used
+          to indicate the ATM interface over which a management request
+          was received.
+
+      atmfSrvcRegServiceID - This is the service identifier that
+          uniquely identifies the type of service at the address
+          provided in the table. (See Section 3.2 for NHRP OID.)
+
+      atmfSrvcRegATMAddress - This is the full address of the service.
+          The ATM client will use this address to establish a connection
+          with the service.
+
+      atmfSrvcRegAddressIndex - An arbitrary integer to differentiate
+          multiple rows containing different ATM addresses for the same
+          service on the same port.
+
+      atmfSrvcRegParm1 - An octet string whose size and meaning is
+          determined by the value of atmfSrvcRegServiceID.
+
+   The service registry table is indexed by atmfSrvcRegPort,
+   atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.
+
+
+
+Davison                     Standards Track                     [Page 2]
+
+RFC 2603          ILMI-Based Server Discovery for NHRP         June 1999
+
+
+3.1 Service Parameter String
+
+   A generic parameter string is defined in the service registry table,
+   thus allowing protocol-specific parameters to be specified. To be
+   consistent with [1], the parameter string for NHRP shall be:
+
+       ar$pro.type   16   bits     Protocol type
+       ar$pro.snap   40   bits     Optional extension to protocol type
+       ar$plen        8   bits     Length of protocol address
+       ar$addr       plen octets   Network address
+       ar$mask       plen octets   Network mask
+
+   Where
+
+       ar$pro.type   - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD)
+
+       ar$pro.snap   - See [1]. (IPv4 and IPv6 are 0)
+
+       ar$plen       - Length of the protocol address.
+                        (IPv4 is 4, IPv6 is 16)
+
+       ar$addr       - Network address represented in network byte
+                        order
+
+       ar$mask       - Network mask represented in network byte order
+
+
+3.2 Service Object Identifier
+
+   This OID, assigned in the ATM Forum Service Registry MIB, names
+   ATMARP within the context of server discovery.
+
+     atmfSrvcRegNHRP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.5 }
+
+
+      It does not name any managed objects, rather is used to locate
+      appropriate rows in the service registery table.
+
+4. Next Hop Client Behavior
+
+   An Next Hop Client NHC) will access the service registry table via
+   ILMI using the SNMP GetNext operator to "sweep" (SNMP parlance for a
+   linear search) beginning with {Port = 0, ServiceID = <see Section
+   3.2>, Index = 0} while holding the port number and the serviceID
+   constant. (Port number 0 is used within ILMI to indicate "this
+   port.")
+
+   An NHC with no local configuration, such as a diskless workstation,
+
+
+
+Davison                     Standards Track                     [Page 3]
+
+RFC 2603          ILMI-Based Server Discovery for NHRP         June 1999
+
+
+   must use the row with the lowest index value if multiple Next Hop
+   Server (NHS), possibly for multiple networks, are listed.
+
+   NHC that have local IP configuration must use a row that has the
+   appropriate IP address.  For example, consider the case where an IP
+   router has 3 logical interfaces defined on a single physical
+   interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and
+   171.69.150.226/24. The router will sweep the service registry table
+   looking for rows that have atmfSrvcRegParm1 values as shown below:
+
+     Net number/mask  atmfSrvcRegParm1
+     ---------------- --------------------------------------------------
+     1.0.0.0/8        08 00 00 00 00 00 00  04  01 00 00 00  ff 00 00 00
+     128.10.0.0/16    08 00 00 00 00 00 00  04  80 0a 00 00  ff ff 00 00
+     171.69.150.0/24  08 00 00 00 00 00 00  04  ab 45 96 00  ff ff ff 00
+
+   When the correct atmfSrvcRegParm1 values are located, the router may
+   then establish an SVC to the selected NHS and perform the appropriate
+   protocol operations.
+
+   Redundant NHS are supported with multiple rows in the service
+   registry table. This list of NHS is ordered with the primary NHS
+   having the lowest index value. The NHC must attempt to utilize the
+   primary NHS before utilizing a secondary NHS. Administrators must
+   ensure that the listed NHS are synchronized.
+
+5. NHRP Server (NHS) Behavior
+
+   A Next Hop Server (NHS) shall be locally configured. The NHS may
+   retrieve the NHRP service registry data to validate the results. If
+   an incorrect row is retrieved the error may be flagged in a locally
+   significant way.
+
+6. Relationship with PNNI Augmented Routing
+
+   An augmented version PNNI ("PNNI Augmented Routing," or PAR) [3] has
+   been developed by the ATM Forum. PAR can distribute data such as NHS
+   addresses. Further, the ATM Forum is developing a proxy mechanism for
+   PAR (Proxy PAR) that would allow a UNI-attached host or router to
+   access PAR data without a full PAR implementation.
+
+   These mechanisms offer a promising way to manage the service registry
+   tables maintained on each switch in an ATM network, yet would not
+   require changes to the mechanism defined in this memo. Hosts and
+   routers can continue to utilize ILMI-based or Proxy PAR-based server
+   discovery and network administrators could manage the service
+   registry data with local configuration or via PAR and Proxy PAR.
+
+
+
+
+Davison                     Standards Track                     [Page 4]
+
+RFC 2603          ILMI-Based Server Discovery for NHRP         June 1999
+
+
+7. Security Considerations
+
+   The server discovery mechanism is built on the ILMI managment
+   framework and the security embodied in that framework. Access, to
+   user- or network-side information is controlled by MIB design rather
+   than protocol security mechanisms.
+
+   The service registery MIB, the table containing information for
+   server discovery, is defined in [2] with read-only access. This means
+   that any user-side device may query the service registry, but may not
+   modify the service registry via ILMI. Instead, the sevice registry
+   table must be modified via local configuration on the ATM switch.
+
+References
+
+   [1]  Luciani, J., et al., "NBMA Next Hop Resolution Protocol", RFC
+        2332, April 1998.
+
+   [2]  ATM Forum, "Integrated Local Management Interface (ILMI)
+        Specification Version 4.0," af-ilmi-0065.000, September 1996.
+
+   [3]  ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0," af-ra-
+        0104, January 1999.
+
+Author's  Address
+
+   Mike Davison
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, California 95134
+
+   Phone: (408) 526-4000
+   EMail: mike.davison@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davison                     Standards Track                     [Page 5]
+
+RFC 2603          ILMI-Based Server Discovery for NHRP         June 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davison                     Standards Track                     [Page 6]
+