TUBA Working Group Dave Katz INTERNET-DRAFT cisco Systems March 1994 Suggested System ID Option for the ES-IS Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any Internet Draft. Abstract This memo specifies an upward-compatible extension to the OSI End System--Intermediate System routing protocol (ISO 9542:1988) [1] to allow end systems which are autoconfiguring their network layer (NSAP) addresses to suggest a value to be used as the System ID. It is primarily intended for use in the TUBA [2] environment, but is also applicable to a CATNIP [3] or pure OSI environment as well. This document specifies an experimental protocol for use in the Internet. In addition, this document will be submitted to ISO for consideration as an addendum to the ISO 9542 standard. Two interoperable implementations of this protocol extension currently exist. 1. Introduction ISO 9542 Amendment 1 [4] specifies a method for dynamic address assignment on hosts (End Systems). The protocol is straightforward- -the host simply multicasts a Request Address (RA) packet to the "All IS" multicast address. This packet contains essentially no information other than the subnetwork address (SNPA) of the requestor. A system implementing address assignment (note that it need not actually be a router) receives this request, and returns a unicast Assign Address (AA) packet containing the assigned network address (NET) and a holding time, specifying the length of time for which the assignment is considered to be valid. The host needs to again request an address assignment before the expiration of the holding timer, should it desire to continue communicating. It is customary (though not required) that the same network address be again assigned. The maximum holding time is roughly 18 hours. Note that this timeout mechanism, combined with the IS-IS [5] protocol's capability of carrying multiple area addresses, provides a way to easily assign new network addresses to hosts in an automated fashion. The assignment is advisory in nature; there may possibly be multiple responders (with different responses!), and it is up to the host to choose among the responses. As such, routers cannot assume that an assigned address in fact will be used; rather, they must wait for the host to issue an ES-IS End System Hello (ESH) to determine the binding between network and subnetwork address. The mechanism by which the assignor determines the network address is purposely unspecified in the standard so as to not constrain various implementation possibilities, ranging from straightforward algorithmic methods to tightly controlled, centralized systems. It is interesting, however, to consider the information available in making this decision. The RA packet specified in the standard carries only one piece of information from the host--the subnetwork address. This means that the assignor must use the subnetwork address, some randomly determined value (with care to ensure that values are not duplicated!), or some a priori information gleaned elsewhere. In practical terms, the only simple, stateless assignment that can be made is by algorithmic manipulation of the subnetwork address. In some cases, however, the host may wish to influence the network address that it will be assigned, assuming that it has some value that it knows a priori to be unique within the IS-IS area. (Note that, for all practical purposes, the value must be globally unique, since the host is not likely to understand the topology of IS-IS areas.) In the TUBA context, an obvious candidate is the IP address of the host. This capability can be achieved with a very simple extension to the Request Address packet. 2. Option Semantics and Elements of Procedure If a host wishes to influence the network address that it will be assigned, it does so by including the new Suggested System ID option in the RA packet. This option is variable in length, and contains the System ID that the host wishes to operate with. The assignor may then choose to honor the request, or it may provide a system ID of its own choosing. Note that the host *must not* assume that its request will be honored; rather, it must use the network address that it receives in the Assign Address packet. If the suggested system ID is longer than the system ID length in use in the routing domain, the assignor cannot use the suggested ID, and falls back to other means. If the system ID is smaller than the length in use in the domain, the assignor shall right-justify the suggested ID in the assigned address, padding on the left with zero octets. Assignors that do not understand this option will silently ignore it, and operate as they do today. 3. Option Syntax Standard options in the ES-IS protocol are {type, length, value} triplets. The Suggested System ID has the following form: Type 0xE3 Length length in octets of the suggested system ID Value value of the suggested system ID References [1] ISO, "End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473)," ISO 9542:1988. [2] Piscitello, D., "Use of ISO CLNP in TUBA Environments," RFC 1561, 1993. [3] Ullmann, R., "CATNIP--Common Architecture for Next-generation Internet Protocol," draft-ietf-catnip-base-02.txt, 1994. [4] ISO, "Dynamic Discovery of OSI NSAP Addresses by End Systems," ISO 9542 Amendment 1, 1992. [5] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. Author's Address Dave Katz cisco Systems 1525 O'Brien Dr. Menlo Park, CA 94025 USA Phone: +1-415-688-8284 Fax: +1-415-688-8282 Email: dkatz@cisco.com