[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                        W A Simpson
Internet Draft                                                Daydreamer
expires in six months                                           May 1993



                          SIP System Discovery



Status of this Memo

   This memo is the product of the SIP Working Group of the Internet
   Engineering Task Force (IETF).  Comments on this memo should be
   submitted to the sip@caldera.usc.edu mailing list.

   Distribution of this memo is unlimited.

   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 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

Abstract

   This document specifies ICMP messages for the identification and
   location of adjacent SIP systems.  This is intended to replace ARP,
   ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP
   Mask, and OSPF Hello in the SIP environment.  There are also elements
   of the OSI ES-IS and IS-IS Hello.













Simpson                  expires in six months                  [Page i]


DRAFT                       system discovery                    May 1993


1.  Terminology

   The following terms have a precise meaning when used in this
   document:
   system          a device that implements the Internet Protocol, IP [9].

   intermediate-system
                   a system that forwards datagrams, as specified in [2].
                   Often called a router or gateway.  This does not include
                   systems that, though capable of forwarding, have that
                   capability turned off.  Nor does it include systems that
                   do forwarding only as required to obey Source Route
                   options.

   end-system      any system that is not acting as an intermediate-system.
                   Often called a host.

   dumb            the minimal implementation.  This is not meant in a
                   perjorative sense.  It is intended that every mechanism
                   be defined in such a way that it is implementable on a
                   minimal system.

   smart           an improved implementation, possibly requiring more
                   internal resources, while using less external resources.

   multicast       unless otherwise qualified, means the use of either IP
                   multicast [4] or IP broadcast [6] service.

   link            a communication facility or medium over which systems
                   can communicate at the link layer; that is, the protocol
                   layer immediately below IP.  The term "physical network"
                   has sometimes been used (imprecisely) for this.
                   Examples of links are LANs (possibly bridged to other
                   LANs), wide-area store-and-forward networks, satellite
                   channels, and point-to-point links.

   multicast link  a link over which IP multicast or IP broadcast service
                   is supported.  This includes broadcast media such as
                   LANs and satellite channels, single point-to-point
                   links, and some store-and-forward networks such as SMDS
                   networks [8].

   interface       a system's attachment point to a link.  It is possible
                   (though unusual) for a system to have more than one
                   interface to the same link.  Interfaces are uniquely
                   identified by an identifier; a single interface may have
                   more than one such identifier.




Simpson                  expires in six months                  [Page 1]


DRAFT                       system discovery                    May 1993


   multicast interface
                   an interface to a multicast link; that is, an interface
                   to a link over which IP multicast or IP broadcast
                   service is supported.

   subnet          either a single link of a subnetted IP network [7] or
                   a single non-subnetted link.

   prefix          the part of an identifier which may be used for routing
                   to a particular subnet, defined by logically ANDing with
                   its assigned subnet mask.  More than one subnet prefix
                   may identify the same link.

   neighbor        having an IP address belonging to the same subnet.

2.  Criteria

   Historically, the methods for discovery of the next hop evolved
   separately from those for location of neighbors and auto-
   configuration of systems.  With the advent of SIP, the old techniques
   must be re-implemented, usually due to larger field sizes.
   Unfortunately, older implementations frequently did not take proper
   care in differentiating existing variable field lengths, version
   numbers, and new types of messages.  Therefore, the techniques used
   for SIP are required to be distinguishable from previous versions.

   None of the current protocols are readily extensible.  While some
   have the ability to change in simple terms, such as larger addresses,
   none were designed to add new kinds of information to be carried in
   the same packet.

   This can be viewed is an opportunity to design a uniform and coherent
   method for accomplishing these goals, rather than a liability.

   Through prior experience, the following criteria were established, in
   order of relative importance.  It is understood that many of these
   criteria may conflict, and require numerous tradeoffs.

   Multicast support

      All SIP systems are required to support multicast.

      This is the primary technique for distinguishing the new messages.
      Older systems will ignore multicast messages at the link layer.

      There are numerous other advantages to using multicast for the new
      messages.  In particular, when compared to broadcast, reduced
      overhead for processing messages which are not ultimately intended



Simpson                  expires in six months                  [Page 2]


DRAFT                       system discovery                    May 1993


      for the local system.

      Not all media supports multicast.  Since multicast is directly
      supported by the SIP header, this technique will work even when
      using link-layer broadcast, or link-layer unicast to each
      recipient.

   Reduced net traffic

      Currently, there are separate packets sent for media address
      resolution, router discovery, and the Hello protocols for the
      various routing algorithms.  Since much of the same information is
      contained in each of these packets, it would be helpful to combine
      the functions in a single packet where possible.

      Also, the most common next hop resolution protocol, the Address
      Resolution Protocol (ARP), requires an additional two packets at
      the beginning of each connection.  The Request is sent, a Reply is
      received, and then the first datagram can be sent to the next hop.
      This causes a significant amount of traffic, and considerable
      latency in establishing a connection.

      The ISO solution (ES-IS) eliminates some of these problems.  Each
      end-system and intermediate-system sends Hellos on a periodic
      basis.  Each system must remember all of the media addresses for
      the other systems on the local network.  This does eliminate the
      latency of ARP, at the expense of many additional packets sent on
      a regular basis, and a large amount of storage overhead in each
      system.

      Two alternative solutions were proposed:

      1)    Sending the first packet destined for an unknown system to
            the all-systems multicast, or to a media multicast based on
            a hash function of the destination.  The appropriate system
            accepts the packet, and sends a redirect indicating the
            appropriate media address to be used for future packets.
            This reduces the traffic from 3 to 2 packets at the
            beginning of a connection, and eliminates the latency, as
            the discovery packet sent is also the data packet.  However,
            the destination identifer in the network header will be
            unicast, while the media address will be multicast, possibly
            resulting in some confusion.  Intermediate-systems would
            require extra intelligence to recognize those packets
            destined beyond the local link, while multi-homed end-
            systems require that capability already.  Also, this method
            is not extensible to include other information useful in
            mobile environments.



Simpson                  expires in six months                  [Page 3]


DRAFT                       system discovery                    May 1993


      2)    Using advertisements for the (fewer) intermediate systems,
            and an ARP-like protocol for those end-system connections
            that are on the local media.  For those packets which are
            clearly destined off the local media, the packet can be sent
            directly to the appropriate intermediate system.  When most
            of the traffic is between systems that are not on the same
            local media, this is very efficient.  When most of the
            traffic is between end-systems on the local media (client-
            server), the extra discovery packets will be rare.  The
            intelligence is split between the intermediate and end
            systems.

      The latter is the solution that is detailed here.  However, the
      former is not mutually exclusive, and could be used in parallel.

      Also, by carrying media addresses within the advertisements and
      redirect packets, a further ARP-like query/response can be avoided
      entirely.

   Low storage overhead

      It is desirable that systems require as little storage overhead as
      possible.  In particular, mobile systems often have significantly
      reduced processing power and memory.

      An end-system should only retain information for those end-systems
      with which it is directly communicating.  To improve efficiency
      and reduce net traffic, this design requires the storage of
      information about each intermediate-system which is heard.

      An intermediate-system may require more processing power and
      memory, since participation in routing protocols requires the
      knowledge of every neighboring intermediate-system.  It is not
      expected that in the general case the location of every end-system
      will be maintained.

   Autoconfiguration

      This design handles initial self-identification and propagation of
      changes in identification.  Other aspects of configuration are
      specified elsewhere, such as loading the operating system and
      environment, and additional facilities and servers for
      registration.

   Mobility support

      This is sometimes considered a subset of the above, as related to
      dynamically changing addresses while moving.  Other systems must



Simpson                  expires in six months                  [Page 4]


DRAFT                       system discovery                    May 1993


      be notified of the changes.

      In addition, the "hidden transmitter" problem is considered (you
      can hear another system, it can't hear you, but there is a path to
      a third system which it can hear, completing the circuit).  This
      is not well supported in any of the past protocols.

      Although basic support for mobility is provided, descriptions of
      additional facilities and servers are specified elsewhere.

   Black hole detection

      In determining whether the next hop system is still available,
      there is a basic tradeoff between frequent queries and resources
      used.  This design trades fewer queries against more information
      within each query and response.

      Explicit holding times are used to limit the exposure to black
      holes.  The times may be dynamically shortened by the responsible
      system when a resource is critical, or when the system is actively
      moving.

   Media independence

      There are many instances where system discovery is accomplished
      differently over different media, such as point-to-point versus
      broadcast versus Large Public Data Networks.  This design places
      the system discovery above the network layer, where it enjoys
      greater independence.  It also encompasses media level redirects
      between logical subnets on the same physical media.

      There are difficulties with carrying media addresses within
      packets, especially in the presence of multi-media bridges.
      Rather than allowing translation by bridges in the path, this
      design exercizes control at the destination system, and requires
      all such media addresses to be in canonical form,

   Optimal route determination

      This is essentially a superset of next hop discovery, combined
      with resource reservation and possible policy considerations, and
      the ability to redirect traffic under changing conditions.  This
      is not well supported in any of the current protocols.

      To balance system overhead against network traffic, this design
      attempts to adapt to a continuum of system capabilities.  Dumb
      end-systems may simply send packets to a default intermediate-
      system, and be redirected to the correct next hop by more capable



Simpson                  expires in six months                  [Page 5]


DRAFT                       system discovery                    May 1993


      intermediate-systems.  Smarter end-systems learn sufficient
      information to make informed choices.

   Simplicity

      All of the above desires, and they want to keep it simple, too.
      This design reduces the number of packet types which must be
      supported in a pure SIP system, and reduces the number of systems
      which recognize and respond to each type.  The extensions are
      designed with 32 and 64 bit boundaries for efficient processing.









































Simpson                  expires in six months                  [Page 6]


DRAFT                       system discovery                    May 1993


3.  Design and Use

   This proposal describes two packets, not much different from those
   already deployed.  These familiar forms are re-packaged to join
   common functions into the same packet to reduce traffic, and are
   designed to be more extensible in the future.

   In order to foster media independence, the packets are part of ICMP,
   which allows the protocols to be used over broadcast, multicast,
   partial-mesh, and point-to-point media.  This is similar to the
   positioning of ES-IS.

   The Where-Are-You solicitation is used to find other systems, and
   associated resources and services.  General solicitations are sent
   when a system interface is initialized.  Specific solicitations are
   sent when one system is ready to communicate with another particular
   system.

   The I-Am-Here advertisement is the answer to the Where-Are-You
   solicitation.  Advertisements are also sent on a periodic basis to
   indicate special resources and services.  Periodic advertisements
   from a few commonly requested systems result in less traffic than
   repeated solicitations from many systems.

   Each advertisement includes a lifetime field, specifying the maximum
   length of time that the advertisements are to be considered valid in
   the absence of further advertisements.  This ensures that other
   systems eventually forget about systems that become unreachable,
   whether that is because the system has failed, or it no longer
   provides the advertised service.

   Each message contains "optional" extensions, designed to allow
   flexibility and extensibility.

   One of the common extensions is the media address.  Each message
   contains enough information to return a reply directly to the sender,
   without additional location traffic.

   Another common extension is a list of the intermediate-systems which
   have been heard.  This allows intermediate-systems to build a map of
   the paths between intermediate-systems, and between intermediate-
   systems and end-systems.  This is designed to be used by most
   commonly deployed routing protocols.  This also solves the "hidden
   transmitter" problem, when used together with the well-known link-
   state class of routing protocols.

   Several methods of routing are supported.




Simpson                  expires in six months                  [Page 7]


DRAFT                       system discovery                    May 1993


3.1.  System Identification

   Zone numbers may be combined with the last hop media address to make
   a locally significant identifier.  This is useful for initial
   configuration and local communication within an administrative
   domain.  These identifiers may be routed in a similar manner to
   prefix-routed subnets.

   Prefix-routed subnet identifiers are supported for addressing
   globally connected networks in the metro/provider addressing model.
   The prefix part of each identifier may be used to locate the subnet
   link for the final hop.  This is the routing technique with which we
   have greatest familiarity.

   End-Point identifiers, or any other globally unique identifier, may
   be used with future routing techniques.  A mobile system may be
   treated as having an end-point identifier when it appears in a
   prefix-routed subnet, since it will not have the same prefix as other
   systems in the subnet.

   Facilities are provided for exchange of redirects and translation
   between the various forms of identifiers.





























Simpson                  expires in six months                  [Page 8]


DRAFT                       system discovery                    May 1993


3.2.  Intermediate System Advertisements

   Each intermediate-system peridodically sends the I-Am-Here message to
   advertise its forwarding capability.  End-systems discover the
   location of their neighboring intermediate-systems simply by
   listening for the advertisements.  This eliminates the need for
   manual configuration of intermediate-system addresses and is
   independent of any specific routing protocol.

   The advertisements include such important information as the media
   address to access the system, other subnets directly accessible
   through the intermediate-system, and neighboring intermediate-systems
   heard.

   Identifiers

      Each intermediate-system advertisement includes one or more
      identifier fields.  These indicate the identifiers which are
      presently in use for each interface of the intermediate-system.

   Prefix Size

      Each advertised identifier includes a prefix size field.  The
      value ranges from 0 to 62, and indicates the number of bits in the
      Identifier which define the prefix mask for the link.  A value of
      zero indicates an end-point identifier.  When the value is not
      zero, the identifier may be used to discern zone or prefix-routed
      subnet mapping.

   Preference

      Each advertised identifier includes a preference field.  This is
      used to choose a default intermediate-system for the first-hop
      when no other information is available (for a particular
      destination, the end-system has not yet been redirected or
      configured to use a specific intermediate-system).  The end-system
      is expected to choose from those intermediate-systems that have
      the highest preference level for the best prefix-routing match.
      When there is no match, or prefix-routing is not in use, the
      preference value is used alone.

      A network administrator can configure intermediate-system
      preference levels to encourage or discourage the use of particular
      intermediate-systems as the default first hop.  The use of
      separate preferences per prefix allows the choice of different
      intermediate-systems for each prefix, when there are multiple
      prefixes in use for the same link.  This may be useful where
      multiple organizations share resources.



Simpson                  expires in six months                  [Page 9]


DRAFT                       system discovery                    May 1993


      [I am not sure this works when there are multiple identifiers per
      end-system interface.]

      The preference value is not the same as the "metric" used in many
      routing protocols.  It is used only by end-systems in determining
      the default first-hop, rather than by intermediate-systems in
      choosing a link for transit traffic.  The values are not additive.
      Therefore, the range of values is smaller, and a higher value
      indicates a higher preference.


3.2.1.  Constants

      MAX_INITIAL_ADVERTISEMENTS        3 transmissions

      MAX_INITIAL_ADVERT_INTERVAL      16 seconds

      MAX_RESPONSE_DELAY                2 seconds


3.2.2.  Configuration

   An intermediate-system MUST allow the following variables to be
   configured by system management.  Default values are specified which
   make it unnecessary to re-configure these variables in most cases.

   For each interface:

   MaxAdvertisementInterval

      The maximum time (in seconds) allowed between sending
      intermediate-system advertisements from the interface.  Must be no
      less than 4 seconds and no greater than 1800 seconds.

      Default: 600 seconds

   MinAdvertisementInterval

      The minimum time (in seconds) allowed between sending unsolicited
      intermediate-system advertisements from the interface.  Must be no
      less than 1 second and no greater than MaxAdvertisementInterval.

      Default: 0.75 * MaxAdvertisementInterval

   AdvertisementLifetime

      The value (in seconds) to be placed in the Lifetime field of
      intermediate-system advertisements sent from the interface.  Must



Simpson                  expires in six months                 [Page 10]


DRAFT                       system discovery                    May 1993


      be no less than MaxAdvertisementInterval and no greater than 9000
      seconds.

      Default: 3 * MaxAdvertisementInterval


   For each of the identifiers of each interface:

   Advertise

      A flag indicating whether or not the identifier is to be
      advertised.

      Default: TRUE

   PreferenceLevel

      The preferability of the interface as a default intermediate-
      system choice, relative to other intermediate-system interfaces
      serving the same prefix on the same link.

      Values are in the range 0 to 255.  Higher values mean more
      preferable.  The minimum value 0 is used to indicate that the
      identifier, even though it may be advertised, is not to be used by
      neighboring end-systems as a default intermediate-system address.

      Default: 1

   It is useful to configure an identifier with a preference level of 0
   (rather than simply setting its Advertise flag to FALSE) when
   advertisements are being used for "black hole" detection.  In
   particular, an intermediate-system that is to be used to reach only
   specific destinations could advertise a preference level of 0 (so
   that neighboring end-systems will not use it as a default
   intermediate-system for reaching arbitrary destinations) and a non-
   zero lifetime (so that neighboring end-systems that have been
   redirected or configured to use it can detect its failure by timing
   out the reception of its advertisements).

   It has been suggested that, when the preference level of an
   identifier has not been explicitly configured, an intermediate-system
   could set it according to the metric of the intermediate-system's
   "default route" (if it has one), rather than defaulting as suggested
   above.  Thus, an intermediate-system with a better metric for its
   default route would advertise a higher preference level for its
   identifier.  (Note that routing metrics that are encoded such that
   "lower is better" would have to be inverted before being used as
   preference levels in intermediate-system advertisement messages.)



Simpson                  expires in six months                 [Page 11]


DRAFT                       system discovery                    May 1993


   Such a strategy might reduce the amount of redirect traffic on some
   links by making it more likely that an end-system's first choice for
   reaching an arbitrary destination is also the best choice.

   On the other hand, redirect traffic is rarely a significant load on a
   link, and there are some cases where such a strategy would result in
   more redirect traffic (on links from which the most frequently chosen
   destinations are best reached via intermediate-systems other than the
   one with the best default route).  Also, since the routing algorithms
   learn of neighboring intermediate-systems from the advertisements,
   and the default routes are learned from the routing algorithms, the
   calculated preference may be unstable from time to time.  This
   document makes no recommendation concerning this issue, and
   implementors are free to try such a strategy, as long as they also
   support static configuration of preference levels as specified above.


3.2.3.  Implementation

   Every SIP intermediate-system MUST implement Intermediate-System
   Advertisements.

   The intermediate-system joins the all-routers multicast group on all
   interfaces on which the intermediate-system supports multicast.

   The term "advertising interface" refers to any functioning and
   enabled interface that has at least one identifier whose configured
   Advertise flag is TRUE.

   From each advertising interface, the system transmits periodic
   advertisements containing the following values:

   -  In the Destination Address field of the SIP header: the all-
      systems multicast, with the scope set to local.

   -  In the Source Address field of the SIP header: the primary
      identifier of the system.  The same identifier is used for all
      interfaces.

   -  In the Code field of the ICMP header: 2 for Intermediate-System
      Advertisement.

   -  In the Lifetime field: the interface's configured
      AdvertisementLifetime.

   -  For each of that interface's identifiers whose Advertise flags are
      TRUE, the Routing-Information extension.




Simpson                  expires in six months                 [Page 12]


DRAFT                       system discovery                    May 1993


   -  For each of that system's other interface's identifiers which have
      not already been included through prefix subsumption, the Other-
      Identifier extension.

   -  For each service advertisement that is offered, or has been
      learned from another advertisement, the Service-Information
      extension.

   -  For each intermediate-system advertisement that has been heard,
      the System-Heard extension.

   -  For interfaces which are not point-to-point links, the Media-
      Access extension.

   In the unlikely event that not all extensions fit in a single
   advertisement, as constrained by the MTU of the link, multiple
   advertisements are sent, with each except the last containing as many
   extensions as can fit.

      CONTROVERSIAL:

      When an intermediate-system discovers that it is receiving its own
      advertisements, that is an indication that it has more than one
      interface on same link.  The system MUST choose only one
      advertising interface for each link.  Identifiers associated with
      the remaining interfaces on the same link are indicated with the
      Other-Identifier extension.  Redirect is used to move specific
      traffic to the alternate interfaces.

      An intermediate-system MAY proxy for the identifers of other
      systems, using the Other-Identifier extension.  This SHOULD only
      be used when the intermediate-system is translating to another
      network-layer protocol format.

   The advertisements are not strictly periodic.  The interval between
   subsequent transmissions is randomized to reduce the probability of
   synchronization with the advertisements from other intermediate-
   systems on the same link.  This is done by maintaining a separate
   transmission interval timer for each advertising interface.  Each
   time an advertisement is sent from an interface, that interface's
   timer is reset to a uniformly-distributed random value between the
   configured MinAdvertisementInterval and MaxAdvertisementInterval.
   Expiration of the timer causes the next advertisement to be sent, and
   a new random value to be chosen.

   It is recommended that intermediate-systems include some unique
   value, such as one of their interface or link-layer addresses, in the
   seed used to initialize their pseudo-random number generators.



Simpson                  expires in six months                 [Page 13]


DRAFT                       system discovery                    May 1993


   Although the randomization range is configured in units of seconds,
   the actual randomly-chosen values should not be in units of whole
   seconds, but rather in units of the highest available timer
   resolution.

   For the first few advertisements sent from an interface (up to
   MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is
   greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
   MAX_INITIAL_ADVERT_INTERVAL instead.  Using this smaller interval for
   the initial advertisements increases the likelihood of an
   intermediate-system being discovered quickly when it first becomes
   available, in the presence of possible packet loss.

   In addition to the periodic unsolicited advertisements, an
   intermediate-system sends advertisements in response to valid
   solicitations received on any of its advertising interfaces.  If the
   solicitation does not contain any Intermediate-Systems-Heard
   extension, and the time since the previous advertisement is greater
   than MAX_INITIAL_ADVERT_INTERVAL, the intermediate-system MUST
   multicast an advertisement from that interface.  The interface's
   interval timer is reset to a new random value, as with unsolicited
   advertisements.  The response MUST be delayed for a small random
   interval not greater than MAX_RESPONSE_DELAY, in order to prevent
   synchronization with other responding intermediate-systems, and to
   allow multiple closely-spaced solicitations to be answered with a
   single advertisement.

   An interface may become an advertising interface at times other than
   system startup, as a result of recovery from an interface failure or
   through actions of system management such as:

   -  enabling the interface, if it had been administratively disabled
      and it has one or more identifiers whose Advertise flag is TRUE,

   -  enabling SIP forwarding capability (changing the system from an
      end-system to an intermediate-system), when the interface has one
      or more identifiers whose Advertise flag is TRUE,

   -  setting the Advertise flag of one or more of the interface's
      identifiers to TRUE (or adding a new identifier with a TRUE
      Advertise flag), when previously the interface had no identifier
      whose Advertise flag was TRUE.

   In such cases, the intermediate-system must commence transmission of
   periodic advertisements on the new advertising interface, limiting
   the first few advertisements to intervals no greater than
   MAX_INITIAL_ADVERT_INTERVAL.  In the case of an end-system becoming
   an intermediate-system, the system must also join the all-routers



Simpson                  expires in six months                 [Page 14]


DRAFT                       system discovery                    May 1993


   multicast group on all interfaces on which the intermediate-system
   supports multicast (whether or not they are advertising interfaces).

   An interface may also cease to be an advertising interface, through
   actions of system management such as:

   -  shutting down the system,

   -  administratively disabling the interface,

   -  disabling SIP forwarding capability (changing the system from an
      intermediate-system to an end-system),

   -  setting the Advertise flags of all of the interface's identifiers
      to FALSE.

   In such cases, the intermediate-system SHOULD transmit a final
   multicast advertisement on the interface, identical to its previous
   transmission, but with a Lifetime field of zero.  In the case of an
   intermediate-system becoming an end-system, the system must also
   depart from the all-routers multicast group on all interfaces on
   which the intermediate-system supports multicast (whether or not they
   had been advertising interfaces).

   When the Advertise flag of one or more of an interface's identifiers
   are set to FALSE by system management, but there remain other
   identifiers on that interface whose Advertise flags are TRUE, the
   intermediate-system SHOULD send a single multicast advertisement
   containing only those identifiers whose Advertise flags were set to
   FALSE, with a Lifetime field of zero.





















Simpson                  expires in six months                 [Page 15]


DRAFT                       system discovery                    May 1993


3.3.  Intermediate System Discovery

   Before an end-system can send datagrams beyond its directly attached
   link, it must discover the location of at least one operational
   intermediate-system on that link.  This is accomplished through the
   intermediate-system advertisement messages described above.

   The advertisement messages do not constitute a routing protocol.
   They enable systems to discover the existence of neighboring
   intermediate-systems, but not necessarily which intermediate-system
   is best to reach a particular destination.  If a system chooses a
   poor intermediate-system for a particular destination, it should
   receive a redirect from that intermediate-system.

   However, the advertisements often contain sufficient information to
   make a good choice of first hop.  This may be important for choosing
   among intermediate-systems which are participating in a security
   group or policy-based routing.

   It should be understood that preference levels learned from
   intermediate-system advertisements do not affect any system's cached
   route entries.  For example, if a system has been redirected to use a
   particular intermediate-system to reach a specific destination, it
   continues to use that intermediate-system for that destination, even
   if it discovers another intermediate-system identifier with a higher
   preference level.  Preference levels influence the choice of
   intermediate-system only for a destination for which there is no
   cached or configured route, or whose cached route points to an
   intermediate-system that is subsequently determined to be
   unreachable.


3.3.1.  Configuration

   The Host Requirements -- Communication Layers [1], Section 3.3.1.6,
   specifies that each end-system must support a configurable list of
   default intermediate-system identifiers.  The purpose of the
   intermediate-system discovery messages is to eliminate the need to
   configure that list.  On links for which intermediate-system
   discovery is administratively disabled, it MAY continue to be
   necessary to configure the default intermediate-system list in each
   end-system.

   Each entry in the list contains (at least) the following configurable
   variables:






Simpson                  expires in six months                 [Page 16]


DRAFT                       system discovery                    May 1993


   RouterAddress

      An identifier of a default intermediate-system.

      Default: (none)

   PreferenceLevel

      The preferability of the RouterAddress as a default intermediate-
      system choice, relative to other intermediate-system interfaces
      serving the same prefix on the same link.  The Host Requirements
      RFC does not specify how this value is to be encoded.  The values
      used here are defined above.

      Default: 255


3.3.2.  Implementation

   To process an Intermediate-System Advertisement, an end-system scans
   the list of Routing-Information extensions contained in it.  For each
   identifier, the end-system does the following:

   -  If the prefix size is not zero, the identifier and prefix size are
      compared against any identifiers associated with the interface on
      which the message was received.  If there is a match, the
      interface prefix size is set to the advertised prefix size.

   -  If the identifier is not already present in the end-system's
      intermediate-system list, a new entry is added to the list,
      containing the identifier along with its accompanying preference
      level, and a timer initialized to the Lifetime value from the
      advertisement.

   -  If the identifier is already present in the end-system's
      intermediate-system list as a result of a previously-received
      advertisement, its preference level is updated and its timer is
      reset to the value in the newly-received advertisement.

   -  If the identifier is already present in the end-system's
      intermediate-system list as a result of system configuration, no
      change is made to its preference level.  There is no timer
      associated with a configured identifier.

   -  If a Media-Access extension is present, the intermediate-system
      list is updated with the location information.

   Whenever the timer expires in any entry that was created as a result



Simpson                  expires in six months                 [Page 17]


DRAFT                       system discovery                    May 1993


   of a received advertisement, that entry is discarded.

      Note that any intermediate-system identifiers acquired from the
      "Gateway" subfield of the vendor extensions field of a BOOTP
      packet [11] are considered to be configured identifiers; they are
      assigned the default preference level of 255, and they do not have
      an associated timer.

      Note further that any identifier found in the "giaddr" field of a
      BOOTP packet [3] identifies a BOOTP forwarder which is not
      necessarily a SIP intermediate-system; such an identifier should
      not be installed in the end-system's default intermediate-system
      list.

   To limit the storage needed for the default intermediate-system list,
   an end-system MAY choose not to store all of the intermediate-system
   identifiers discovered via advertisements.  The end-system SHOULD
   discard those identifiers with lower preference levels in favor of
   those with higher levels.  It is desirable to retain more than one
   default intermediate-system identifier in the list; if the current
   choice of default intermediate-system is discovered to be down, the
   end-system may immediately choose another default intermediate-system
   without having to wait for the next advertisement to arrive.

   Any intermediate-system identifier advertised with a preference level
   of zero is not to be used by the end-system as default intermediate-
   system identifier.  Such an identifier may be omitted from the
   default intermediate-system list, unless its timer is being use as a
   "black-hole" detection mechanism.






















Simpson                  expires in six months                 [Page 18]


DRAFT                       system discovery                    May 1993


3.4.  Initial Intermediate-System Solicitations

   When any end-system starts up, which is not otherwise sending
   periodic I-Am-Here advertisements, it MUST instead send the Where-
   Are-You solicitation to begin discovery of intermediate-systems.

   If (and only if) no advertisements from neighboring intermediate-
   systems are forthcoming, the end-system may retransmit the Where-
   Are-You a small number of times, but then must desist from sending
   more solicitations.

   Any systems that subsequently start up, or that were not discovered
   because of packet loss or temporary link partitioning, are eventually
   discovered by reception of their periodic (unsolicited)
   advertisements.  Links that suffer high packet loss rates or frequent
   partitioning are accommodated by increasing the rate of
   advertisements, rather than increasing the number of solicitations
   that systems are permitted to send.


3.4.1.  Constants

      MAX_SOLICITATIONS                 3 transmissions

      MAX_SOLICITATION_DELAY            1 second

      SOLICITATION_INTERVAL             3 seconds


3.4.2.  Implementation

   Every SIP system MUST implement the System Solicitation.

   Every SIP system joins the all-systems multicast group on all
   interfaces on which the system supports multicast.

   An end-system is permitted (but not required) to transmit up to
   MAX_SOLICITATIONS solicitation messages from any of its interfaces
   after any of the following events:

   -  The interface is initialized at system startup time.

   -  The interface is reinitialized after a temporary interface failure
      or after being temporarily disabled by system management.

   -  The system has its SIP forwarding capability turned off by system
      management.




Simpson                  expires in six months                 [Page 19]


DRAFT                       system discovery                    May 1993


   -  The system has its SIP service capability turned off by system
      management.

   From each such interface, the system transmits solicitations
   containing the following values:

   -  In the Destination Address field of the SIP header: the all-
      routers multicast, with the scope set to local.

   -  In the Source Address field of the SIP header: the primary
      identifier associated with that interface.  It MAY contain zero if
      the system has not yet determined an identifier for the interface.

   -  In the Code field of the ICMP header: 2 for Intermediate-System
      Solicitation.

   -  For each of that system's interface identifiers other than the
      primary identifier, the Other-Identifier extension, with the
      prefix size set to zero.

   -  For each intermediate-system advertisement that has been heard,
      the System-Heard extension.

   -  For interfaces which are not point-to-point links, the Media-
      Access extension.

   If a system chooses to send a solicitation after one of the above
   events, it should delay transmission for a random amount of time
   between 0 and MAX_SOLICITATION_DELAY.  This serves to alleviate
   congestion when many systems start up on a link at the same time,
   such as might happen after recovery from a power failure.

   It is recommended that systems include some unique value, such as one
   of their interface or link-layer identifiers, in the seed used to
   initialize their pseudo-random number generators.  Although the
   randomization range is specified in units of seconds, the actual
   randomly-chosen value should not be in units of whole seconds, but
   rather in units of the highest available timer resolution.

   The small number of retransmissions of a solicitation, which are
   permitted if no advertisement is received, should be sent at
   intervals of SOLICITATION_INTERVAL seconds, without further
   randomization.

   Upon receiving a valid advertisement from any intermediate-system
   subsequent to one of the above events, the system MUST NOT send any
   solicitation on that interface (even if none have been sent yet)
   until the next time one of the above events occurs.  The



Simpson                  expires in six months                 [Page 20]


DRAFT                       system discovery                    May 1993


   intermediate-system advertisements (described above) contain a
   summary of all of the available information for the link.

















































Simpson                  expires in six months                 [Page 21]


DRAFT                       system discovery                    May 1993


3.5.  Service Advertisments

   Each system offering one of the special configuration services
   detailed below, whether an end-system or intermediate-system,
   periodically sends the I-Am-Here message to advertise its service
   availablility.  All systems discover the location of these services
   simply by listening for the advertisements.  This eliminates the need
   for manual configuration, periodic probes, and special handling of
   certain packet types by intermediate-systems.

   The learned service information is included in any neighboring
   intermediate-system advertisements.  In this fashion, the
   intermediate-system advertisements provide a summary of all available
   network services, and pass information beyond the link where the
   advertisement originated.  This results in a reduction of network
   traffic when compared to the broadcast or multicast of service
   discovery requests/replies over a wide area.

   The service advertisements use similar configuration constants and
   variables as intermediate-system advertisements.


3.5.1.  Implementation

   Services offered by intermediate-systems are included in the
   intermediate-system advertisements described above.

   From each advertising interface, an end-system transmits periodic
   advertisements containing the following values:

   -  In the Destination Address field of the SIP header: the all-
      systems multicast, with the scope set to local.

   -  In the Source Address field of the SIP header: the primary
      identifier associated with that interface.

   -  In the Code field of the ICMP header: 1 for End-System
      Advertisement.

   -  In the Lifetime field: the interface's configured
      AdvertisementLifetime.

   -  For each of that system's interface identifiers other than the
      primary identifier, the Other-Identifier extension, with the
      prefix size set to zero.

   -  For each service advertisement that is offered, the Service-
      Information extension.



Simpson                  expires in six months                 [Page 22]


DRAFT                       system discovery                    May 1993


   -  For each intermediate-system advertisement that has been heard,
      the System-Heard extension.

   -  For interfaces which are not point-to-point links, the Media-
      Access extension.

   In the unlikely event that not all extensions fit in a single
   advertisement, as constrained by the MTU of the link, multiple
   advertisements are sent, with each except the last containing as many
   extensions as can fit.

   End-system service advertisements are sent using the same periodicity
   as intermediate-system advertisements.

   Advertising interfaces are established and terminated in the same
   manner as intermediate-system advertisements.

   When any system ceases to offer an advertised service, the system
   SHOULD transmit a final multicast advertisement on the interface,
   identical to its previous transmission, but with a Lifetime field of
   zero.






























Simpson                  expires in six months                 [Page 23]


DRAFT                       system discovery                    May 1993


3.6.  Service Discovery

   Because the service advertisements learned from a link are
   promulgated by the intermediate-system advertisements, no further
   effort is required to solicit service advertisements.

   [what to do when there are no IS Adverts]

   The services advertised are limited primarily to configuration.  The
   locations of other facilities may be learned from these basic
   servers.


3.6.1.  Domain Name Service

   Before a system can communicate with another system, it must learn
   that system's identifiers and location.  The Domain Name System (DNS)
   is usually used for this purpose.

   Therefore, the location of at least one DNS server must be learned.
   This is accomplished through the service advertisement messages
   described above.

   In the past, this was accomplished by reading a list of servers from
   a (possibly remote) configuration file at startup time.  Some systems
   discovered servers by sending periodic probes to a broadcast or
   multicast address.  Both of these methods have serious drawbacks.
   Configuration files must be maintained manually (a significant
   administrative burden when ther are large numbers of systems), and
   are unable to track dynamic changes in DNS availability.  Periodic
   probes are restricted from using recursion (see Host Requirements --
   Application and Support [2], Section 6.1.3.2), and are thus limited
   to information about the local domain.

   In practice, only systems which are users or stub resolvers of the
   DNS will use the DNS server advertisements.  Full-Service resolvers
   MUST continue to be manually configured to ensure a heirarchy of
   believability within the network.


3.6.2.  Self-Configuration Service

   Before a system can communicate with another system, it must learn
   its own identity.  The Bootstrap Protocol (BOOTP) is frequently used
   for this purpose.

   Therefore, the location of at least one BOOTP server must be learned.
   This is accomplished through the service advertisement messages



Simpson                  expires in six months                 [Page 24]


DRAFT                       system discovery                    May 1993


   described above.

   In the past, this was accomplished by ad hoc passing of BOOTP
   requests by routers.  This method has several serious drawbacks.
   Presence of the feature cannot be relied upon.  It is not of much use
   for mobile, roving or portable systems.













































Simpson                  expires in six months                 [Page 25]


DRAFT                       system discovery                    May 1993


3.7.  Prefix Discovery

   which define the prefix mask for the link.  The value ranges from 0
   to 62.

   The value of 63 cannot be used, since at least 2 bits are reserved
   for a valid host portion of the identifier.

   Each IS, when configured, or address assigned.  The prefixes are
   assigned by hand.  Can ask DNS or BOOTP.

   Unlike previous practice, an end-system prefix size MUST NOT be
   preconfigured.  Instead, the prefix size is dynamically learned from
   matching against the intermediate-system advertisements, as described
   in Intermediate-System Discovery above.

   more than one prefix on same link.



3.8.  Zone Discovery

   A Zone is defined to be a collection of systems which may be
   aggregated as the same next hop.  A Zone may be as small as a single
   link segment, or as large as an entire administrative domain.


3.8.1.  Abstraction Algorithm

   The zones are learned from the intermediate-system advertisements,
   which contain the necessary prefix information.




















Simpson                  expires in six months                 [Page 26]


DRAFT                       system discovery                    May 1993


3.9.  Next Hop Determination

   Within a directly attached link, each system must be able to locate
   other systems with which it desires to communicate.  This is
   accomplished using the Where-Are-You and I-Am-Here messages described
   below.  This is independent of any specific media.

   When the system has heard one or more intermediate-system
   advertisements, it first uses these advertisements to determine if
   the desired system is directly accessible on the local link.


   When an end-system has not heard any intermediate-system
   advertisements, it is assumed that all end-systems are only
   accessible on the local link.




3.9.1.  Configuration



3.9.2.  Implementation



























Simpson                  expires in six months                 [Page 27]


DRAFT                       system discovery                    May 1993


3.9.3.  Examples of Use

       Simple case -- J to K on the same fully-connected link.

           J sends the Where-Are-You (which contains its own media address)
           to all-systems.  K sends the I-Am-Here (which contains its own
           media address) directly to J.  At this point, they both know
           that they can talk directly to each other, without regard to
           subnet.

       Routed case -- J to K not on the same fully-connected link.

           If no resource reservation or policy routing is desired, J
           simply sends its packets directly to the "preferred" router that
           it has learned from the Advertisements.  If there is a better
           router for the first hop, that router sends the I-Am-Here
           redirect to J, but never-the-less forwards the packet.

           In the presence of RR or PR, J sends the Where-Are-You to the
           "preferred" router that it has learned from the Advertisements.
           That router always returns the I-Am-Here (even if the correct
           hop is itself), which contains the requested RR or PR status
           information.  J then sends its packets to the first hop router
           as determined from the I-Am-Here.

       General case -- J to K over disconnected partial mesh (radio/framerelay).

           J sends the Where-Are-You (which contains its own media address,
           and the addresses of its "heard" routers) to the all-systems
           address.  The routers use such messages to construct a map of
           the current state of the topology.  The routers now know who J
           hears, and who hears J.

           If the routing map doesn't contain a current whereabouts of K,
           the Destination Unreachable message is returned by the "best"
           router on J's "heard" list.

           If the routing map contains the current whereabouts of K, the
           "best" router on K's "heard" list sends a copy of the
           Where-Are-You to K, with a substitute list of routers which can
           hear K.  The list is ordered by the intersection of those
           routers which can also hear J, minimizing the number of hops.

           Of course, K may have heard J's Where-Are-You directly, in which
           case it adds its own address to the front of the list of routers.

           When K hears the J Where-Are-You, it sends the I-Am-Here to the
           all-systems address.  The "best" router on J's "heard" list



Simpson                  expires in six months                 [Page 28]


DRAFT                       system discovery                    May 1993


           sends a copy of the I-Am-Here to J, with a substitute list of
           routers which can hear J.  The list is ordered by the
           intersection of those routers which can also hear K.

           At this point, the routing fabric knows which routers are heard
           by J and K, and which routers can hear J and K.  J and K know
           whether they can hear each other directly.  If not, they know
           the "best" next hop router (which may not be the same in both
           directions).

           Unlike the fully-connected scenarios, this scheme requires that
           the I-Am-Here is sent from time to time to keep the map updated.
           However, only routers need store the information.






































Simpson                  expires in six months                 [Page 29]


DRAFT                       system discovery                    May 1993


4.  Additional ICMP Packets

   The Packet format and basic facilities are already defined for ICMP
   [3], as modified for SIP [1].

   Up-to-date values of the ICMP Type field are specified in the most
   recent "Assigned Numbers" RFC [2].  This document concerns the
   following values:

      <TBD>   Where-Are-You
      <TBD>   I-Am-Here








































Simpson                  expires in six months                 [Page 30]


DRAFT                       system discovery                    May 1993


4.1.  Where-Are-You

   A summary of the Where-Are-You message format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       System Identifier                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions ...
   +-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      <TBD>

   Code

      The Code field is one octet.  Up-to-date values of the I-Am-Here
      Code field are specified in the most recent "Assigned Numbers" RFC
      [2].  Current values are assigned as follows:

           0     RESERVED
           1     End-System Solicitation
           2     Intermediate-System Solicitation


   Checksum

      The ICMP Checksum.

   System Identifier

      The System Identifier field is eight octets in length, and
      contains the identifier of the system which is sought.  For an
      Intermediate-System Solicitation, the field is unused and remains
      zero filled.






Simpson                  expires in six months                 [Page 31]


DRAFT                       system discovery                    May 1993


   Extensions

      The Extensions field is variable in length and contains zero or
      more Extensions.  These Extensions are described in a later
      section.



4.1.1.  Description

   The Where-Are-You message is used to determine the presence and
   availability of the next hop.  This message is also used for resource
   reservation and policy route determination.






































Simpson                  expires in six months                 [Page 32]


DRAFT                       system discovery                    May 1993


4.2.  I-Am-Here

   A summary of the I-Am-Here message format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Sequence Number        |          LifeTime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       System Identifier                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions ...
   +-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      <TBD>

   Code

      The Code field is one octet.  Up-to-date values of the I-Am-Here
      Code field are specified in the most recent "Assigned Numbers" RFC
      [2].  Current values are assigned as follows:

           0     RESERVED
           1     End-System Advertisement
           2     Intermediate-System Advertisement
           3     Local Redirect
           4     Remote Redirect


   Checksum

      The ICMP Checksum.

   Sequence Number

      The Sequence Number field is two octets in length, and contains
      the number of I-Am-Heres sent.  This number MUST include this
      advertisement.





Simpson                  expires in six months                 [Page 33]


DRAFT                       system discovery                    May 1993


   LifeTime

      The LifeTime field is two octets in length, and indicates the
      seconds remaining before the entry is considered invalid.

   System Identifier

      The System Identifier field is eight octets in length, and
      contains the primary identifier for this system.  Other
      identifiers are indicated with the Other-Identifier extension.

   Extensions

      The Extensions field is variable in length and contains zero or
      more Extensions.  These Extensions are described in a later
      section.


4.2.1.  Description

   The I-Am-Here message is used to announce the presence of an
   intermediate or end system, to indicate changes in the topology, and
   to support system mobility.

   It contains all of the information now in the old Router
   Advertisement, ES Hello, IS Hello, OSPF Hello and RSPF Hello.


   Intermediate Systems

      The message is sent by each intermediate-system periodically to
      the all-systems multicast.  The information is stored by all
      systems.

      The message is also sent in response to a Where-Are-You.

   End-Systems

      The message is sent in response to a Where-Are-You.  The
      information is stored only by the affected systems.

   Local Redirect

      The message is sent in response to changes in the routing.  The
      information is stored only by the affected systems.






Simpson                  expires in six months                 [Page 34]


DRAFT                       system discovery                    May 1993


   Remote Redirect

      The message is sent to indicate movement of a system beyond the
      local zone.  The information is stored only by the affected
      systems.














































Simpson                  expires in six months                 [Page 35]


DRAFT                       system discovery                    May 1993


5.  Extensions

   Extensions allow variable amounts of information to be carried within
   each Advertisement or Solicitation packet.  Some extensions are
   common to both packet types.

   The end of the list of Extensions is indicated by the Payload Length
   of the SIP packet.

   A summary of the Extensions format is shown below.  The fields are
   transmitted from left to right.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      The Type field is one octet and indicates the type of Extension.
      Up-to-date values of the Extension Type field are specified in the
      most recent "Assigned Numbers" RFC [2].  Current values are
      assigned as follows:

           1     Media-Access
           2     Other-Identifier
           3     Routing-Information
           4     System-Heard
           5     Security-Information
           6     Service-Information
           7     Transit-Information


   Length

      The Length field is one octet and indicates the length of the Data
      field which has been used.

      Each Extension ends on an octet boundary which is an integral
      multiple of four octets.  Any unused portion of the Data field is
      padded with zeros.

      length          actual
      0 through 2        4
      3 through 6        8
      7 through 10      12



Simpson                  expires in six months                 [Page 36]


DRAFT                       system discovery                    May 1993


   Data

      The Data field is zero or more octets and contains the value or
      other information for this Extension.  The format and length of
      the Data field is determined by the Type and Length fields.














































Simpson                  expires in six months                 [Page 37]


DRAFT                       system discovery                    May 1993


5.1.  Media-Access

A summary of the Media-Access extension format is shown below.  The
fields are transmitted from left to right.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |           Media Type          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

     1

Length

     >= 3

Media Type

   The Media Type field is two octets in length.  The value of this
   field is the same as the Hardware Type used in ARP.  Up-to-date
   values of the Hardware Type field are specified in the most recent
   "Assigned Numbers" RFC [2].

      [Should we use the ifType from MIB-II instead?]

MAC Address

   The MAC Address field is variable in length, and contains the media
   address which is used to access this system.

   The MAC Address is always specified in Canonical order.

The Media-Access extension MUST be included in those messages sent from
an interface on a multi-access media.

It MUST NOT be included in a message sent from a point-to-point
interface, or in messages such as the Remote Redirect which pass through
intermediate systems.







Simpson                  expires in six months                 [Page 38]


DRAFT                       system discovery                    May 1993


5.2.  Other-Identifier

A summary of the Other-Identifier extension format is shown below.  The
fields are transmitted from left to right.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |                   |Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                      Interface Identifier                     +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

     2

Length

    14

Prefix Size

   The Prefix Size field is six bits in length, and indicates the number
   of bits in the Interface Identifier which define the prefix mask for
   the link.  The value ranges from 0 to 62.

   If the Interface Identifier does not indicate a valid prefix, the
   value is zero.

   End-Systems MUST have a Prefix Size of zero.

Metric

   The Metric field is four octets in length, and indicates the
   preference level for use of this system to forward packets to the
   Interface Identifier.  Lower values indicate greater preference.

   End-Systems MUST set this field to zero.

Interface Identifier

   The Interface Identifier field is eight octets in length, and



Simpson                  expires in six months                 [Page 39]


DRAFT                       system discovery                    May 1993


   contains an identifier for this system.  This may be another
   identifier for the same interface that sent the message, or may
   identify another interface on the same system which sent the message.

Every identifier for every interface is listed in each I-Am-Here
message.

This supports multiple identifiers per interface, as well as multi-homed
systems.

When a number of interfaces, such as point-to-point interfaces, may be
aggregated with the same prefix, only one extension need be included.

This enables end-systems to determine the best next hop without sending
a Where-Are-You solicitation when the next hop is on another interface
attached to the same advertising system.



































Simpson                  expires in six months                 [Page 40]


DRAFT                       system discovery                    May 1993


5.3.  Routing-Information

A summary of the Routing-Information extension format is shown below.
The fields are transmitted from left to right.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |  Preference   |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MRU              |     Zone      |   Priority    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                      Interface Identifier                     +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

     3

Length

    14

Preference

   The Preference field is one octet in length, and indicates the
   preference level for use of this system to forward packets to the
   Interface Identifier.  Higher values indicate greater preference.

Designated Bit

   The Designated Bit indicates that the System Identifier is the
   Designated Router.

Backup Bit

   The Backup Bit indicates that the System Identifier is the Backup
   Designated Router.

Prefix Size

   The Prefix Size field is six bits in length, and indicates the number
   of bits in the Interface Identifier which define the prefix mask for
   the link.  The value ranges from 0 to 62.




Simpson                  expires in six months                 [Page 41]


DRAFT                       system discovery                    May 1993


   If the Interface Identifier does not indicate a valid prefix, the
   value is zero.

MRU

   The Maximum Receive Unit field is two octets in length, and indicates
   the maximum size packet that the system will receive over the link.

Zone

   The Zone field is one octet in length, and indicates the zone for the
   link.  A value of zero indicates that no zone has been assigned.

Priority

   The Priority field is one octet in length, and indicates the priority
   for election to Designated Backup.  A value of zero indicates that
   the system is not eligible.

Interface Identifier

   The Interface Identifier field is eight octets in length, and
   contains an identifier for this interface.

This extension is sent only by Intermediate-Systems.


























Simpson                  expires in six months                 [Page 42]


DRAFT                       system discovery                    May 1993


5.4.  System-Heard

A summary of the System-Heard extension format is shown below.  The
fields are transmitted from left to right.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Speed     |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MRU              |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       System Identifier                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Sequence Number        |      Remaining LifeTime       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Quality                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Advertisement Count                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Error Count                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

     4

Length

    30

Designated Bit

   The Designated Bit indicates that the System Identifier is the
   Designated Router.

Backup Bit

   The Backup Bit indicates that the System Identifier is the Backup
   Designated Router.

Prefix Size

   The Prefix Size field is six bits in length, and indicates the number
   of bits in the System Identifier which define the prefix mask for the



Simpson                  expires in six months                 [Page 43]


DRAFT                       system discovery                    May 1993


   link.  The value ranges from 0 to 62.

   If the System Identifier does not indicate a valid prefix, the value
   is zero.

   End-Systems MUST have a Prefix Size of zero.

MRU

   The Maximum Receive Unit field is two octets in length, and indicates
   the maximum size packet that the system will receive over the link.

Speed

   The Speed field is one octet in length, and indicates the speed of
   the link over which the advertisement or solicitation was heard.
   Higher values indicate greater speed.  The speed value is related to
   int( 10 * ln( speed / 100 ) ) in bits per second.

      After considerable trial and error, this formula was used because
      it gave the best distribution for distinguishing medium speed
      links, and fit reasonably well in the realm of currently
      envisioned speeds.  It has an upper limit of 11.87 Terabits per
      second.  (It also has a convenient button on the calculator.)

        0      link is down
        1 - 9  reserved
       10      300 or less
       24    1,200                  96      1,544,000 T1
       31    2,400                  99      2,048,000 E1
       38    4,800                 106      4,000,000 Token Ring
       42    7,200                 110      6,312,000 T2
       45    9,600                 115     10,000,000 Ethernet
       49   14,400                 119     16,000,000 Token Ring
       52   19,200                 130     44,736,000 T3
       56   28,800
       59   38,400                 142    155,520,000 STS-3/STM-1
       63   57,600                 202    622,080,000 STS-12/STM-4
       64   64,000                 216  2,488,320,000 STS-48/STM-16
       71  128,000
       73  153,600
       78  256,000


System Identifier

   The System Identifier field is eight octets in length, and contains
   the primary identifier for the system.



Simpson                  expires in six months                 [Page 44]


DRAFT                       system discovery                    May 1993


Sequence Number

   The Sequence Number field is two octets in length, and contains the
   last heard sequence number from the system.

Remaining LifeTime

   The Remaining LifeTime field is two octets in length, and indicates
   the seconds remaining before the entry is considered invalid.

Quality

   The Quality field is four octets in length, and contains an
   indication of the signal quality received from this system.  Higher
   values indicate greater quality.

Advertisement Count

   The Advertisement Count field is four octets in length, and indicates
   the number of advertisements that have been heard from the identified
   system.

Error Count

   The Error Count field is four octets in length, and indicates the
   number of errors which have been detected on the link with the
   identified system.

The System Heard extension MUST be included in every I-Am-Here.






















Simpson                  expires in six months                 [Page 45]


DRAFT                       system discovery                    May 1993


5.5.  Security-Information

A summary of the Security-Information extension format is shown below.
The fields are transmitted from left to right.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                                                               |
|                         Compartments                          |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

     5

Length

    22

Compartments

   The Compartments field is sixteen octets in length.

This extension is included in the Intermediate-System I-Am-Here to
indicate that it will accept transit traffic for the designated security
compartments.














Simpson                  expires in six months                 [Page 46]


DRAFT                       system discovery                    May 1993


5.6.  Service-Information

A summary of the Service-Information extension format is shown below.
The fields are transmitted from left to right.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       System Identifier                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

     6

Length

    14

System Identifier

   The System Identifier field is eight octets in length, and contains
   an identifier for this system.  This may be another identifier for
   the same interface that sent the message, or may identify another
   interface on the same system which sent the message.



















Simpson                  expires in six months                 [Page 47]


DRAFT                       system discovery                    May 1993


5.7.  Transit-Information

A summary of the Transit-Information extension format is shown below.
The fields are transmitted from left to right.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |               |      QoS      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

     7

Length

     6

QoS

   The Quality of Service field is one octet in length, and indicates a
   service for which transit will be accepted.

Metric

   The Metric field is four octets in length, and indicates the
   preference level for use of this network link to forward packets of
   the indicated service.  Lower values indicate greater preference.

This extension is included in the Intermediate-System I-Am-Here to
indicate that it will accept transit traffic.  If this extension is not
included, the system will treat the link as a stub network.















Simpson                  expires in six months                 [Page 48]


DRAFT                       system discovery                    May 1993


Security Considerations



References

   [1]

   [2]


Acknowledgments



Chair's Address

   The working group can be contacted via the current chairs:





Author's Address

   Questions about this memo can also be directed to:

      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      P O Box 6205
      East Lansing, MI  48826-6205

      EMail: Bill.Simpson@um.cc.umich.edu

















Simpson                  expires in six months                 [Page 49]


DRAFT                       system discovery                    May 1993


                           Table of Contents


     1.     Terminology ...........................................    1

     2.     Criteria ..............................................    2

     3.     Design and Use ........................................    7
        3.1       System Identification ...........................    8
        3.2       Intermediate System Advertisements ..............    9
           3.2.1  Constants .......................................   10
           3.2.2  Configuration ...................................   10
           3.2.3  Implementation ..................................   12
        3.3       Intermediate System Discovery ...................   16
           3.3.1  Configuration ...................................   16
           3.3.2  Implementation ..................................   17
        3.4       Initial Intermediate-System Solicitations .......   19
           3.4.1  Constants .......................................   19
           3.4.2  Implementation ..................................   19
        3.5       Service Advertisments ...........................   22
           3.5.1  Implementation ..................................   22
        3.6       Service Discovery ...............................   24
           3.6.1  Domain Name Service .............................   24
           3.6.2  Self-Configuration Service ......................   24
        3.7       Prefix Discovery ................................   26
        3.8       Zone Discovery ..................................   26
           3.8.1  Abstraction Algorithm ...........................   26
        3.9       Next Hop Determination ..........................   27
           3.9.1  Configuration ...................................   27
           3.9.2  Implementation ..................................   27
           3.9.3  Examples of Use .................................   28

     4.     Additional ICMP Packets ...............................   30
        4.1       Where-Are-You ...................................   31
           4.1.1  Description .....................................   32
        4.2       I-Am-Here .......................................   33
           4.2.1  Description .....................................   34

     5.     Extensions ............................................   36
        5.1       Media-Access ....................................   38
        5.2       Other-Identifier ................................   39
        5.3       Routing-Information .............................   41
        5.4       System-Heard ....................................   43
        5.5       Security-Information ............................   46
        5.6       Service-Information .............................   47
        5.7       Transit-Information .............................   48

     SECURITY CONSIDERATIONS ......................................   49



Simpson                  expires in six months                 [Page ii]

DRAFT                       system discovery                    May 1993


     REFERENCES ...................................................   49

     ACKNOWLEDGEMENTS .............................................   49

     CHAIR'S ADDRESS ..............................................   49

     AUTHOR'S ADDRESS .............................................   49


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/