Network Working Group W A Simpson Internet Draft Daydreamer 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 email@example.com 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.
[This is a rough first draft. Need assessmentThere are also elements of needed fields, much more text describing usage. Autoconfiguration will bethe OSI ES-IS and IS-IS Hello. 1. Terminology The following terms have a precise meaning when used in this document: system a separate draft, sincedevice that implements the issues here are already getting too big.] 1. Criteria Multicast support. Nearly allInternet Protocol, IP . intermediate-system a system that forwards datagrams, as specified in . Often called a router or gateway. This does not include systems that, though capable of the respondents listed thisforwarding, 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 first or second desire stated.minimal implementation. This is not meant in a perjorative sense. It is notedintended that not all media supports multicast. Reduced net traffic. On one hand,every mechanism be defined in such a flood of hosts sending periodic advertisements;way that it is implementable on the other, 2 extra packets for every address request. Two solutions were proposed: 1) Sending the first packet to the all-systems multicast, and receivinga redirect. This reducesminimal system. smart an improved implementation, possibly requiring more internal resources, while using less external resources. multicast unless otherwise qualified, means the traffic from 3 to 2 packets. 2) Automatic router discovery. For those packetsuse of either IP multicast  or IP broadcast  service. link a communication facility or medium over which are clearly destined off net, the packetsystems can be sent directly tocommunicate at the next hop. Preference values were cited as useful. Also, carrying media addresses withinlink layer; that is, the router discoveryprotocol 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 redirect packets, so thatpoint-to-point links. multicast link a further query/response can be avoided. Low host overhead. A host should only retain information for those systems with with itlink over which IP multicast or IP broadcast service is directly communicating. Autoconfiguration. In particular, automatic address discoverysupported. This includes broadcast media such as LANs and automatic address prefix changes. Mobility support. Partly a subset of the above,satellite channels, single point-to-point links, and some store-and-forward networks such as relatedSMDS networks . interface a system's attachment point to dynamically changing addresses while moving. In addition, the "hidden transmitter" problem (you can hear another system, it can't hear you, but there isa path throughlink. It is possible (though unusual) for a thirdsystem which it can hear, completingto have more than one interface to the circuit). Thissame link. Interfaces are uniquely identified by an identifier; a single interface may have more than one such identifier. multicast interface an interface to a multicast link; that is, an interface to a link over which IP multicast or IP broadcast service is not well supported in anysupported. subnet either a single link of a subnetted IP network  or a single non-subnetted link. prefix the current protocols. Black hole detection. This was repeatedly cited as important. There ispart of an identifier which may be used for routing to a basic tradeoff between frequent queries and resources used. Explicit holding times were cited as useful. Media independence. There were many examples, such as point-to-point versus broadcast versus LPDN. Media level redirects between logical subnets onparticular subnet, defined by logically ANDing with its assigned subnet mask. More than one subnet prefix may identify the same physical media. The difficulties with carrying media addresses within packets, especially inlink. neighbor having an IP address belonging to the presencesame subnet. 2. Criteria Historically, the methods for discovery of multi-media bridges. This isthe 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 well supportedtake proper care in anydifferentiating 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. Optimal route determination.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 essentiallyan 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 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. 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 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 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. 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. 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. 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. [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 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.) 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. - 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. 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 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. 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 , Section 22.214.171.124, 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: 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 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  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  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. 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. - 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 intermediate-system advertisements (described above) contain a summary of all of the available information for the link. 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. - 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. 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 superset of next hop router discovery, combinedsystem can communicate with resource reservation and possible policy considerations,another system, it must learn that system's identifiers and the ability to redirect traffic under changing conditions.location. The very things that have been causing so much discussionDomain Name System (DNS) is usually used for this purpose. Therefore, the location of late.at least one DNS server must be learned. This is not well supported in any ofaccomplished through the current protocols. Simplicity. All ofservice advertisement messages described above. In the above desires, and they wantpast, 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 keep it simple, too. Proposed Solution Space. Nonea broadcast or multicast address. Both of the current protocols are extensible in dimensions that fix the desires above. While somethese methods have the ability to change in simple terms, such as larger addresses, none were designed to add new kindsserious drawbacks. Configuration files must be maintained manually (a significant administrative burden when ther are large numbers of informationsystems), and are unable to be carriedtrack dynamic changes in the same packet. This proposal describes two replacement packets, not much different from those already deployed. These familiar formsDNS availability. Periodic probes are re-packaged to join common functions into the same packet to reduce traffic,restricted from using recursion (see Host Requirements -- Application and Support , Section 126.96.36.199), and are designedthus limited to be more extensible ininformation about the future.local domain. In order to foster media independence, the packetspractice, only systems which are partusers or stub resolvers of ICMP, which allowsthe procotolsDNS 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 over broadcast, multicast, partial-mesh, and point-to-point media.for this purpose. Therefore, the location of at least one BOOTP server must be learned. This is similar toaccomplished through the service advertisement messages 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. 3.7. Prefix Discovery which define the positioningprefix mask for the link. The value ranges from 0 to 62. The value of ES-IS. All63 cannot be used, since at least 2 bits are reserved for a valid host portion of the advertisementmessages have expiration times.identifier. Each message is composed of "optional" parts, designed to allow flexibility and extensibility. One ofIS, 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 common partsprefix size is dynamically learned from matching against the media address, so that each message contains enough informationintermediate-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 returnbe a reply directly tocollection of systems which may be aggregated as the sender, without additional location traffic. Another common part issame next hop. A Zone may be as small as a list ofsingle link segment, or as large as an entire administrative domain. 3.8.1. Abstraction Algorithm The zones are learned from the routersintermediate-system advertisements, which cancontain the necessary prefix information. 3.9. Next Hop Determination Within a directly attached link, each system must be heard,able to locate other systems with which allows routersit desires to build a map ofcommunicate. This is accomplished using the paths between routers,Where-Are-You and routers to hosts.I-Am-Here messages described below. This solvesis independent of any specific media. When the "hidden transmitter" problem, when used together withsystem has heard one or more intermediate-system advertisements, it first uses these advertisements to determine if the well-known link-state class of routing protocols.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 3.9.3. Examples of use:Use Simple case -- J to K on the same fully-connected segment.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 segment.link. If no resource reservation or policy routing is desired, J simply sends its packets directly to the "best""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 "best""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 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. 2.4. Additional ICMP Packets The Packet format and basic facilities are already defined for ICMP , as modified for SIP . Up-to-date values of the ICMP Type field are specified in the most recent "Assigned Numbers" RFC . This document concerns the following values: <TBD> System SolicitationWhere-Are-You <TBD> System Advertisement 2.1. System SolicitationI-Am-Here 4.1. Where-Are-You A summary of the System SolicitationWhere-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 . 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. Extensions The Extensions field is variable in length and contains zero or more Extensions. These Extensions are described in a later section. 188.8.131.52.1.1. Description The System Solicitation (Where-Are-You)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. The message is sent on demand to the all-systems multicast, or to the best first hop router, as indicated by the Advertisement. The information is stored only by routers and the subject hosts. [Need more text describing use for each case, and for resource reservation and policy routing] 2.2. System Advertisement4.2. I-Am-Here A summary of the System AdvertisementI-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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Default Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask Size | | Area | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Extensions ... +-+-+-+-+-+-+-+-+-+-+-+-+ Type <TBD> Code The Code field is one octet. Up-to-date values of the System AdvertisementI-Am-Here Code field are specified in the most recent "Assigned Numbers" RFC . Current values are assigned as follows: 0 RESERVED 1 Intermediate SystemEnd-System Advertisement 2 End SystemIntermediate-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 System AdvertisementsI-Am-Heres sent. This number MUST include this advertisement. 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 IdentifiersOther-Identifier extension. Default Metric The Default Metric field is four octets in length, and indicates the preference level for use of this system as a default router. Lower values indicate greater preference. End Systems MUST set this field to zero. Mask Size The Mask Size field is one octet in length, and indicates the number of bits in the System Identifier which indicate the subnet mask for the interface. If the System Identifier does not indicate a valid local subnet, the value is zero. End Systems SHOULD have a Mask Size of 64. Area The Area field is one octet in length, and indicates the area that the system inhabits. A value of zero indicates that no area has been assigned. End Systems must set this field to zero. 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. End Systems must set this field to zero.Extensions The Extensions field is variable in length and contains zero or more Extensions. These Extensions are described in a later section. 184.108.40.206.2.1. Description The System Advertisement (I-Am-Here)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 systemintermediate-system periodically to the all-systems multicast. The information is stored by all systems. The message is also sent in response to a System Solicitation. End SystemsWhere-Are-You. End-Systems The message is sent in response to a System Solicitation.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. Remote Redirect The message is sent to indicate movement of a system beyond the local area.zone. The information is stored only by the affected systems. 3.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 . Current values are assigned as follows: 1 Media AccessMedia-Access 2 Other IdentifiersOther-Identifier 3 System HeardRouting-Information 4 Routing InformationSystem-Heard 5 Service InformationSecurity-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 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. 3.1. Media Access5.1. Media-Access A summary of the Media AccessMedia-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 . [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 AccessMedia-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-pointa message sent from a point-to-point interface, or in messages such as the Remote Redirect which pass through intermediate systems. 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 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, or in messagesas well as multi-homed systems. When a number of interfaces, such as point-to-point interfaces, may be aggregated with the Remote Redirect which pass through intermediate systems. 3.2. Other Identifierssame 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. 5.3. Routing-Information A summary of the Other IdentifiersRouting-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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask SizeMRU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Zone | PreferencePriority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + SystemInterface Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 23 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.Preference The Preference field is four octetsone octet in length, and indicates the preference level for use of this system to forward packets to the SystemInterface Identifier. LowerHigher values indicate greater preference. End Systems MUST set this field to zero. MaskDesignated 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 MaskPrefix Size field is one octetsix bits in length, and indicates the number of bits in the SystemInterface Identifier which indicatedefine the subnetprefix mask for the interface.link. The value ranges from 0 to 62. If the SystemInterface Identifier does not indicate a valid local subnet,prefix, the value is zero. End Systems SHOULD have a Mask SizeMRU 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 64. Every identifierzero indicates that no zone has been assigned. Priority The Priority field is one octet in length, and indicates the priority for every interfaceelection to Designated Backup. A value of zero indicates that the system is listednot eligible. Interface Identifier The Interface Identifier field is eight octets in each System Advertisement message. This supports multiple identifiers per interface, as well as multi-homed systems.length, and contains an identifier for this interface. This enables systems to determine the best next hop without sending a Solicitation when the next hopextension is on another interface attached to the same system. 3.3. System Heardsent only by Intermediate-Systems. 5.4. System-Heard A summary of the System HeardSystem-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 | Mask Size ||D|B|Prefix Size| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence NumberMRU | LifeTime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + System Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QualitySequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Remaining LifeTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRUQuality | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertisement Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Length 30 Sequence NumberDesignated Bit The Sequence Number fieldDesignated Bit indicates that the System Identifier is two octets in length, and containsthe last heard sequence number fromDesignated Router. Backup Bit The Backup Bit indicates that the system. LifeTimeSystem Identifier is the Backup Designated Router. Prefix Size The LifeTimePrefix Size field is two octetssix bits in length, and indicates the seconds remaining beforenumber of bits in the entry is considered invalid.System Identifier which define the prefix mask for the link. The value ranges from 0 to 62. If the System Identifier field is eight octets in length, and contains the primary identifier fordoes not indicate a valid prefix, the system. Qualityvalue is zero. End-Systems MUST have a Prefix Size of zero. MRU The QualityMaximum Receive Unit field is fourtwo octets in length, and contains an indication ofindicates the signal quality received from this system. Higher values indicate greater quality.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.link over which the advertisement or solicitation was heard. Higher values indicate greater speed. The speed value is related to the log2 of theint( 10 * ln( speed / 100 ) ) in bits per second. Unfortunately, there are several series which don't quite match. Is thereAfter 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 standard assignment out there?convenient button on the calculator.) 0 link is down 8 1,200 or lessis down 1 - 9 2,400 4,800 9,600reserved 10 14,400 19,200 12 28,800 38,400 14 57,600 64,000 17 128,000 18 153,600 19 256,000 22300 or less 24 1,200 96 1,544,000 T1 2331 2,400 99 2,048,000 E1 2438 4,800 106 4,000,000 Token Ring 42 7,200 110 6,312,000 T2 2545 9,600 115 10,000,000 Ethernet 2649 14,400 119 16,000,000 Token Ring 2852 19,200 130 44,736,000 T3 3056 28,800 59 38,400 142 155,520,000 STS-3/STM-1 3263 57,600 202 622,080,000 STS-12/STM-4 3464 64,000 216 2,488,320,000 STS-48/STM-16 Mask Size71 128,000 73 153,600 78 256,000 System Identifier The Mask SizeSystem Identifier field is one octeteight octets in length, and indicatescontains the number of bits inprimary identifier for the System Identifier which indicatesystem. Sequence Number The Sequence Number field is two octets in length, and contains the subnet mask forlast heard sequence number from the interface. Ifsystem. Remaining LifeTime The Remaining LifeTime field is two octets in length, and indicates the System Identifier does not indicate a valid local subnet,seconds remaining before the valueentry is zero. End Systems SHOULD have a Mask Sizeconsidered invalid. Quality The Quality field is four octets in length, and contains an indication of 64.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 CountError 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. 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 foursixteen octets in length, and indicates the number of errors which have been detected on the link with the identified system. The System Heardlength. This extension MUST beis included in every System Advertisement. 3.4. Routing Informationthe Intermediate-System I-Am-Here to indicate that it will accept transit traffic for the designated security compartments. 5.6. Service-Information A summary of the Routing InformationService-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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Designated BackupSystem Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 56 Length 14 Designated BackupSystem Identifier The Designated BackupSystem Identifier field is eight octets in length, and contains thean identifier of the designated backupfor this area.system. This extension is included inmay be another identifier for the Intermediate System Advertisement ofsame interface that sent the Designated Router, to assert its status asmessage, or may identify another interface on the Designated Router, and indicatesame system which sent the Designated Backup. 3.5. Service Informationmessage. 5.7. Transit-Information A summary of the Service InformationTransit-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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PreferenceMetric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 67 Length 6 QoS The Quality of Service field is two octets in length, and indicates a service for which transit will be accepted. Preference The Preference field is four octetsone octet in length, and indicates the preference level for use of this network to forward packets of the indicated service. Lower values indicate greater preference. This extension is included in the Intermediate System Advertisement to indicate that it will accept transit traffic. If this extension is not included, the system will treat the link as a stub network. 4. Abstraction Algorithm An Area is defined to be a collection of subnets which are aggregated as the same next hop. The areas are learned from the Advertisements, which contain the necessary subnet information. The subnets are assigned by hand. When the subnet mask shortens by at least one bit,a new level of area is created.service for which transit will be accepted. Metric The areaMetric field is defined by an area index (assigned by the designated router of the affected area),four octets in length, and indicates the countpreference level for use of bits commonthis network link to the subnet. This can be expressed as a pair of 8-bit numbers. Discovery of stub areas (probably the most common type) is easy and automatic. Discoveryforward packets of aggregate areas is made by routers one hop out fromthe area.indicated service. Lower values indicate greater preference. This extension is communicated through its Advertisements, which are heard by the routers bordering the area. This algorithm resultsincluded in a few, fairly large areas. There can never be more than 64 levels of area, and it is more likely to be 5 to 10 because of natural assignment boundaries. The numbering space also places a limit onthe number of routers bordering an areaIntermediate-System I-Am-Here to 255, butindicate that it will accept transit traffic. If this extension is highly unlikely. Fragmentation of areas simply results in automatic generation of internal areas, and has no effect on area levels farther out.not included, the system will treat the link as a stub network. Security Considerations Security issues are not discussed in this memo.References   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 Table of Contents 1. Criteria ..............................................Terminology ........................................... 1 2. Additional ICMP Packets ............................... 5 2.1 System Solicitation ............................. 6 2.1.1 Description ..................................... 6 2.2 System Advertisement ............................ 8 2.2.1 Description ..................................... 10Criteria .............................................. 2 3. Extensions ............................................ 11Design and Use ........................................ 7 3.1 Media Access .................................... 13System Identification ........................... 8 3.2 Other Identifiers ............................... 14Intermediate System Advertisements .............. 9 3.2.1 Constants ....................................... 10 3.2.2 Configuration ................................... 10 3.2.3 Implementation .................................. 12 3.3 Intermediate System Heard ....................................Discovery ................... 16 3.3.1 Configuration ................................... 16 3.3.2 Implementation .................................. 17 3.4 Routing Information .............................Initial Intermediate-System Solicitations ....... 19 3.4.1 Constants ....................................... 19 3.4.2 Implementation .................................. 19 3.5 Service InformationAdvertisments ........................... 22 3.5.1 Implementation .................................. 22 3.6 Service Discovery ............................... 24 3.6.1 Domain Name Service ............................. 20 4.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 ................................. 2128 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 ...................................... 2249 REFERENCES ................................................... 2249 ACKNOWLEDGEMENTS ............................................. 2249 CHAIR'S ADDRESS .............................................. 2249 AUTHOR'S ADDRESS ............................................. 2249