TUBA Working Group                                             Dave Katz
INTERNET-DRAFT                                             cisco Systems
<draft-ietf-tuba-sysid-00.txt>                                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