draft-ietf-sip-discovery-00.txt   draft-ietf-sip-discovery-01.txt 
skipping to change at page 1, line 32 skipping to change at page 1, line 32
cite them other than as a ``working draft'' or ``work in progress.'' cite them other than as a ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 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 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft. current status of any Internet Draft.
Abstract Abstract
This document specifies ICMP messages for the identification and This document specifies ICMP messages for the identification and
location of adjacent SIP systems. This is intended to replace ARP, location of adjacent SIP systems. This is intended to replace ARP,
ICMP Router Advertisement, ICMP Redirect, and OSPF Hello in the SIP ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP
environment. Mask, and OSPF Hello in the SIP environment. There are also elements
of the OSI ES-IS and IS-IS Hello.
[This is a rough first draft. Need assessment of needed fields, 1. Terminology
much more text describing usage. Autoconfiguration will be in a
separate draft, since the issues here are already getting too big.]
1. Criteria The following terms have a precise meaning when used in this
document:
system a device that implements the Internet Protocol, IP [9].
Multicast support. 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.
Nearly all of the respondents listed this as the first or end-system any system that is not acting as an intermediate-system.
second desire stated. It is noted that not all media Often called a host.
supports multicast.
Reduced net traffic. 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.
On one hand, a flood of hosts sending periodic smart an improved implementation, possibly requiring more
advertisements; on the other, 2 extra packets for every internal resources, while using less external resources.
address request.
Two solutions were proposed: multicast unless otherwise qualified, means the use of either IP
multicast [4] or IP broadcast [6] service.
1) Sending the first packet to the all-systems multicast, link a communication facility or medium over which systems
and receiving a redirect. This reduces the traffic from can communicate at the link layer; that is, the protocol
3 to 2 packets. 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.
2) Automatic router discovery. For those packets which are multicast link a link over which IP multicast or IP broadcast service
clearly destined off net, the packet can be sent directly is supported. This includes broadcast media such as
to the next hop. Preference values were cited as useful. LANs and satellite channels, single point-to-point
links, and some store-and-forward networks such as SMDS
networks [8].
Also, carrying media addresses within the router discovery interface a system's attachment point to a link. It is possible
and redirect packets, so that a further query/response can be (though unusual) for a system to have more than one
avoided. interface to the same link. Interfaces are uniquely
identified by an identifier; a single interface may have
more than one such identifier.
Low host overhead. 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.
A host should only retain information for those systems with subnet either a single link of a subnetted IP network [7] or
with it is directly communicating. a single non-subnetted link.
Autoconfiguration. 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.
In particular, automatic address discovery and automatic neighbor having an IP address belonging to the same subnet.
address prefix changes.
Mobility support. 2. Criteria
Partly a subset of the above, as related to dynamically Historically, the methods for discovery of the next hop evolved
changing addresses while moving. In addition, the "hidden separately from those for location of neighbors and auto-
transmitter" problem (you can hear another system, it can't configuration of systems. With the advent of SIP, the old techniques
hear you, but there is a path through a third system which it must be re-implemented, usually due to larger field sizes.
can hear, completing the circuit). This is not well Unfortunately, older implementations frequently did not take proper
supported in any of the current protocols. 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.
Black hole detection. 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 was repeatedly cited as important. There is a basic This can be viewed is an opportunity to design a uniform and coherent
tradeoff between frequent queries and resources used. method for accomplishing these goals, rather than a liability.
Explicit holding times were cited as useful.
Media independence. 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.
There were many examples, such as point-to-point versus Multicast support
broadcast versus LPDN. Media level redirects between logical
subnets on the same physical media. The difficulties with
carrying media addresses within packets, especially in the
presence of multi-media bridges. This is not well supported
in any of the current protocols.
Optimal route determination. All SIP systems are required to support multicast.
This is essentially a superset of next hop router discovery, This is the primary technique for distinguishing the new messages.
combined with resource reservation and possible policy Older systems will ignore multicast messages at the link layer.
considerations, and the ability to redirect traffic under
changing conditions. The very things that have been causing
so much discussion of late. This is not well supported in
any of the current protocols.
Simplicity. 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.
All of the above desires, and they want to keep it simple, Not all media supports multicast. Since multicast is directly
too. supported by the SIP header, this technique will work even when
using link-layer broadcast, or link-layer unicast to each
recipient.
Proposed Solution Space. Reduced net traffic
None of the current protocols are extensible in dimensions that fix Currently, there are separate packets sent for media address
the desires above. While some have the ability to change in simple resolution, router discovery, and the Hello protocols for the
terms, such as larger addresses, none were designed to add new kinds various routing algorithms. Since much of the same information is
of information to be carried in the same packet. contained in each of these packets, it would be helpful to combine
the functions in a single packet where possible.
This proposal describes two replacement packets, not much different Also, the most common next hop resolution protocol, the Address
from those already deployed. These familiar forms are re-packaged to Resolution Protocol (ARP), requires an additional two packets at
join common functions into the same packet to reduce traffic, and are 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. designed to be more extensible in the future.
In order to foster media independence, the packets are part of ICMP, In order to foster media independence, the packets are part of ICMP,
which allows the procotols to be used over broadcast, multicast, which allows the protocols to be used over broadcast, multicast,
partial-mesh, and point-to-point media. This is similar to the partial-mesh, and point-to-point media. This is similar to the
positioning of ES-IS. positioning of ES-IS.
All of the advertisementmessages have expiration times. 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.
Each message is composed of "optional" parts, designed to allow 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. flexibility and extensibility.
One of the common parts is the media address, so that each message One of the common extensions is the media address. Each message
contains enough information to return a reply directly to the sender, contains enough information to return a reply directly to the sender,
without additional location traffic. without additional location traffic.
Another common part is a list of the routers which can be heard, Another common extension is a list of the intermediate-systems which
which allows routers to build a map of the paths between routers, and have been heard. This allows intermediate-systems to build a map of
routers to hosts. This solves the "hidden transmitter" problem, when the paths between intermediate-systems, and between intermediate-
used together with the well-known link-state class of routing systems and end-systems. This is designed to be used by most
protocols. commonly deployed routing protocols. This also solves the "hidden
transmitter" problem, when used together with the well-known link-
state class of routing protocols.
Examples of use: Several methods of routing are supported.
Simple case -- J to K on the same fully-connected segment. 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 [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:
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 [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.
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 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
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 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.
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
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) 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 to all-systems. K sends the I-Am-Here (which contains its own
media address) directly to J. At this point, they both know media address) directly to J. At this point, they both know
that they can talk directly to each other, without regard to that they can talk directly to each other, without regard to
subnet. subnet.
Routed case -- J to K not on the same fully-connected segment. Routed case -- J to K not on the same fully-connected link.
If no resource reservation or policy routing is desired, J If no resource reservation or policy routing is desired, J
simply sends its packets directly to the "best" router that it simply sends its packets directly to the "preferred" router that
has learned from the Advertisements. If there is a better it has learned from the Advertisements. If there is a better
router for the first hop, that router sends the I-Am-Here to J, router for the first hop, that router sends the I-Am-Here
but never-the-less forwards the packet. 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 In the presence of RR or PR, J sends the Where-Are-You to the
"best" router that it has learned from the Advertisements. That "preferred" router that it has learned from the Advertisements.
router always returns the I-Am-Here (even if the correct hop is That router always returns the I-Am-Here (even if the correct
itself), which contains the requested RR or PR status hop is itself), which contains the requested RR or PR status
information. J then sends its packets to the first hop information. J then sends its packets to the first hop router
router as determined from the I-Am-Here. as determined from the I-Am-Here.
General case -- J to K over disconnected partial mesh (radio/framerelay). General case -- J to K over disconnected partial mesh (radio/framerelay).
J sends the Where-Are-You (which contains its own media address, J sends the Where-Are-You (which contains its own media address,
and the addresses of its "heard" routers) to the all-systems and the addresses of its "heard" routers) to the all-systems
address. The routers use such messages to construct a map of address. The routers use such messages to construct a map of
the current state of the topology. The routers now know who J the current state of the topology. The routers now know who J
hears, and who hears J. hears, and who hears J.
If the routing map doesn't contain a current whereabouts of K, If the routing map doesn't contain a current whereabouts of K,
skipping to change at page 5, line 5 skipping to change at page 30, line 5
At this point, the routing fabric knows which routers are heard 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 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 whether they can hear each other directly. If not, they know
the "best" next hop router (which may not be the same in both the "best" next hop router (which may not be the same in both
directions). directions).
Unlike the fully-connected scenarios, this scheme requires that Unlike the fully-connected scenarios, this scheme requires that
the I-Am-Here is sent from time to time to keep the map updated. the I-Am-Here is sent from time to time to keep the map updated.
However, only routers need store the information. However, only routers need store the information.
2. Additional ICMP Packets 4. Additional ICMP Packets
The Packet format and basic facilities are already defined for ICMP The Packet format and basic facilities are already defined for ICMP
[3], as modified for SIP [1]. [3], as modified for SIP [1].
Up-to-date values of the ICMP Type field are specified in the most Up-to-date values of the ICMP Type field are specified in the most
recent "Assigned Numbers" RFC [2]. This document concerns the recent "Assigned Numbers" RFC [2]. This document concerns the
following values: following values:
<TBD> System Solicitation <TBD> Where-Are-You
<TBD> System Advertisement <TBD> I-Am-Here
2.1. System Solicitation 4.1. Where-Are-You
A summary of the System Solicitation message format is shown below. A summary of the Where-Are-You message format is shown below. The
The fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ System Identifier + + System Identifier +
skipping to change at page 6, line 30 skipping to change at page 31, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<TBD> <TBD>
Code Code
0 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 Checksum
The ICMP Checksum. The ICMP Checksum.
System Identifier System Identifier
The System Identifier field is eight octets in length, and contains The System Identifier field is eight octets in length, and
the identifier of the system which is sought. contains the identifier of the system which is sought. For an
Intermediate-System Solicitation, the field is unused and remains
zero filled.
Extensions Extensions
The Extensions field is variable in length and contains zero or more The Extensions field is variable in length and contains zero or
Extensions. These Extensions are described in a later section. more Extensions. These Extensions are described in a later
section.
2.1.1. Description
The System Solicitation (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 4.1.1. Description
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 The Where-Are-You message is used to determine the presence and
reservation and policy routing] availability of the next hop. This message is also used for resource
reservation and policy route determination.
2.2. System Advertisement 4.2. I-Am-Here
A summary of the System Advertisement message format is shown below. A summary of the I-Am-Here message format is shown below. The fields
The fields are transmitted from left to right. are transmitted from left to right.
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | LifeTime | | Sequence Number | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ System Identifier + + System Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask Size | | Area | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<TBD> <TBD>
Code Code
The Code field is one octet. Up-to-date values of the System The Code field is one octet. Up-to-date values of the I-Am-Here
Advertisement Code field are specified in the most recent Code field are specified in the most recent "Assigned Numbers" RFC
"Assigned Numbers" RFC [2]. Current values are assigned as [2]. Current values are assigned as follows:
follows:
0 RESERVED 0 RESERVED
1 Intermediate System 1 End-System Advertisement
2 End System 2 Intermediate-System Advertisement
3 Local Redirect 3 Local Redirect
4 Remote Redirect 4 Remote Redirect
Checksum Checksum
The ICMP Checksum. The ICMP Checksum.
Sequence Number Sequence Number
The Sequence Number field is two octets in length, and contains The Sequence Number field is two octets in length, and contains
the number of System Advertisements sent. This number MUST the number of I-Am-Heres sent. This number MUST include this
include this advertisement. advertisement.
LifeTime LifeTime
The LifeTime field is two octets in length, and indicates the The LifeTime field is two octets in length, and indicates the
seconds remaining before the entry is considered invalid. seconds remaining before the entry is considered invalid.
System Identifier System Identifier
The System Identifier field is eight octets in length, and The System Identifier field is eight octets in length, and
contains the primary identifier for this system. Other contains the primary identifier for this system. Other
identifiers are indicated with the Other Identifiers extension. identifiers are indicated with the Other-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 Extensions
The Extensions field is variable in length and contains zero or The Extensions field is variable in length and contains zero or
more Extensions. These Extensions are described in a later more Extensions. These Extensions are described in a later
section. section.
2.2.1. Description 4.2.1. Description
The System Advertisement (I-Am-Here) message is used to announce the The I-Am-Here message is used to announce the presence of an
presence of an intermediate or end system, to indicate changes in the intermediate or end system, to indicate changes in the topology, and
topology, and to support system mobility. to support system mobility.
It contains all of the information now in the old Router It contains all of the information now in the old Router
Advertisement, ES Hello, IS Hello, OSPF Hello and RSPF Hello. Advertisement, ES Hello, IS Hello, OSPF Hello and RSPF Hello.
Intermediate Systems Intermediate Systems
The message is sent by each intermediate system periodically to The message is sent by each intermediate-system periodically to
the all-systems multicast. The information is stored by all the all-systems multicast. The information is stored by all
systems. systems.
The message is also sent in response to a System Solicitation. The message is also sent in response to a Where-Are-You.
End Systems End-Systems
The message is sent in response to a System Solicitation. The The message is sent in response to a Where-Are-You. The
information is stored only by the affected systems. information is stored only by the affected systems.
Local Redirect Local Redirect
The message is sent in response to changes in the routing. The The message is sent in response to changes in the routing. The
information is stored only by the affected systems. information is stored only by the affected systems.
Remote Redirect Remote Redirect
The message is sent to indicate movement of a system beyond the The message is sent to indicate movement of a system beyond the
local area. The information is stored only by the affected local zone. The information is stored only by the affected
systems. systems.
3. Extensions 5. Extensions
Extensions allow variable amounts of information to be carried within Extensions allow variable amounts of information to be carried within
each Advertisement or Solicitation packet. Some extensions are each Advertisement or Solicitation packet. Some extensions are
common to both packet types. common to both packet types.
The end of the list of Extensions is indicated by the Payload Length The end of the list of Extensions is indicated by the Payload Length
of the SIP packet. of the SIP packet.
A summary of the Extensions format is shown below. The fields are A summary of the Extensions format is shown below. The fields are
transmitted from left to right. transmitted from left to right.
skipping to change at page 11, line 30 skipping to change at page 36, line 30
| Type | Length | Data ... | Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
The Type field is one octet and indicates the type of Extension. 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 Up-to-date values of the Extension Type field are specified in the
most recent "Assigned Numbers" RFC [2]. Current values are most recent "Assigned Numbers" RFC [2]. Current values are
assigned as follows: assigned as follows:
1 Media Access 1 Media-Access
2 Other Identifiers 2 Other-Identifier
3 System Heard 3 Routing-Information
4 Routing Information 4 System-Heard
5 Service Information 5 Security-Information
6 Service-Information
7 Transit-Information
Length Length
The Length field is one octet and indicates the length of the Data The Length field is one octet and indicates the length of the Data
field which has been used. field which has been used.
Each Extension ends on an octet boundary which is an integral Each Extension ends on an octet boundary which is an integral
multiple of four octets. Any unused portion of the Data field is multiple of four octets. Any unused portion of the Data field is
padded with zeros. padded with zeros.
length actual length actual
0 through 2 4 0 through 2 4
3 through 6 8 3 through 6 8
7 through 10 12 7 through 10 12
Data Data
The Data field is zero or more octets and contains the value or The Data field is zero or more octets and contains the value or
other information for this Extension. The format and length of other information for this Extension. The format and length of
the Data field is determined by the Type and Length fields. the Data field is determined by the Type and Length fields.
3.1. Media Access 5.1. Media-Access
A summary of the Media Access extension format is shown below. The A summary of the Media-Access extension format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 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 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 | | Type | Length | Media Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address ... | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 42 skipping to change at page 38, line 42
[Should we use the ifType from MIB-II instead?] [Should we use the ifType from MIB-II instead?]
MAC Address MAC Address
The MAC Address field is variable in length, and contains the media The MAC Address field is variable in length, and contains the media
address which is used to access this system. address which is used to access this system.
The MAC Address is always specified in Canonical order. The MAC Address is always specified in Canonical order.
The Media Access extension MUST be included in those messages sent from The Media-Access extension MUST be included in those messages sent from
an interface on a multi-access media. an interface on a multi-access media.
It MUST NOT be included in a message sent from a point-to-point 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 interface, or in messages such as the Remote Redirect which pass through
intermediate systems. intermediate systems.
3.2. Other Identifiers 5.2. Other-Identifier
A summary of the Other Identifiers extension format is shown below. The A summary of the Other-Identifier extension format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 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 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 | | Mask Size | | Type | Length | |Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ System Identifier + + Interface Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
2 2
Length Length
14 14
System Identifier Prefix Size
The System Identifier field is eight octets in length, and contains The Prefix Size field is six bits in length, and indicates the number
an identifier for this system. This may be another identifier for of bits in the Interface Identifier which define the prefix mask for
the same interface that sent the message, or may identify another the link. The value ranges from 0 to 62.
interface on the same system which sent the message.
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, 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.
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 Preference
The Preference field is four octets in length, and indicates the The Preference field is one octet in length, and indicates the
preference level for use of this system to forward packets to the preference level for use of this system to forward packets to the
System Identifier. Lower values indicate greater preference. Interface Identifier. Higher values indicate greater preference.
End Systems MUST set this field to zero. Designated Bit
Mask Size The Designated Bit indicates that the System Identifier is the
Designated Router.
The Mask Size field is one octet in length, and indicates the number Backup Bit
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 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.
If the Interface Identifier does not indicate a valid prefix, the
value is zero. value is zero.
End Systems SHOULD have a Mask Size of 64. MRU
Every identifier for every interface is listed in each System The Maximum Receive Unit field is two octets in length, and indicates
Advertisement message. the maximum size packet that the system will receive over the link.
This supports multiple identifiers per interface, as well as multi-homed Zone
systems.
This enables systems to determine the best next hop without sending a The Zone field is one octet in length, and indicates the zone for the
Solicitation when the next hop is on another interface attached to the link. A value of zero indicates that no zone has been assigned.
same system.
3.3. System Heard Priority
A summary of the System Heard extension format is shown below. The 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.
5.4. System-Heard
A summary of the System-Heard extension format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 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 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 | | Type | Length | Speed |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | LifeTime | | MRU | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ System Identifier + + System Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality | | Sequence Number | Remaining LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | MRU | | Quality |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Count | | Advertisement Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Count | | Error Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
4 4
Length Length
30 30
Sequence Number Designated Bit
The Sequence Number field is two octets in length, and contains the The Designated Bit indicates that the System Identifier is the
last heard sequence number from the system. Designated Router.
LifeTime Backup Bit
The LifeTime field is two octets in length, and indicates the seconds The Backup Bit indicates that the System Identifier is the Backup
remaining before the entry is considered invalid. Designated Router.
System Identifier Prefix Size
The System Identifier field is eight octets in length, and contains The Prefix Size field is six bits in length, and indicates the number
the primary identifier for the system. of bits in the System Identifier which define the prefix mask for the
link. The value ranges from 0 to 62.
Quality If the System Identifier does not indicate a valid prefix, the value
is zero.
The Quality field is four octets in length, and contains an End-Systems MUST have a Prefix Size of zero.
indication of the signal quality received from this system. Higher
values indicate greater quality. 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 Speed
The Speed field is one octet in length, and indicates the speed of The Speed field is one octet in length, and indicates the speed of
the link. Higher values indicate greater speed. The speed value is the link over which the advertisement or solicitation was heard.
related to the log2 of the speed in bits per second. Higher values indicate greater speed. The speed value is related to
int( 10 * ln( speed / 100 ) ) in bits per second.
Unfortunately, there are several series which don't quite match. Is After considerable trial and error, this formula was used because
there a standard assignment out there? 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 0 link is down
8 1,200 or less 1 - 9 reserved
9 2,400 10 300 or less
4,800 24 1,200 96 1,544,000 T1
9,600 31 2,400 99 2,048,000 E1
10 14,400 38 4,800 106 4,000,000 Token Ring
19,200 42 7,200 110 6,312,000 T2
12 28,800 45 9,600 115 10,000,000 Ethernet
38,400 49 14,400 119 16,000,000 Token Ring
14 57,600 52 19,200 130 44,736,000 T3
64,000 56 28,800
17 128,000 59 38,400 142 155,520,000 STS-3/STM-1
18 153,600 63 57,600 202 622,080,000 STS-12/STM-4
19 256,000 64 64,000 216 2,488,320,000 STS-48/STM-16
22 1,544,000 T1 71 128,000
23 2,048,000 E1 73 153,600
24 4,000,000 Token Ring 78 256,000
6,312,000 T2
25 10,000,000 Ethernet
26 16,000,000 Token Ring
28 44,736,000 T3
30 155,520,000 STS-3/STM-1
32 622,080,000 STS-12/STM-4
34 2,488,320,000 STS-48/STM-16
Mask Size System Identifier
The Mask Size field is one octet in length, and indicates the number The System Identifier field is eight octets in length, and contains
of bits in the System Identifier which indicate the subnet mask for the primary identifier for the system.
the interface.
If the System Identifier does not indicate a valid local subnet, the Sequence Number
value is zero.
End Systems SHOULD have a Mask Size of 64. 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 Advertisement Count
The Advertisement Count field is four octets in length, and indicates The Advertisement Count field is four octets in length, and indicates
the number of advertisements that have been heard from the identified the number of advertisements that have been heard from the identified
system. system.
Error Count Error Count
The Error Count field is four octets in length, and indicates the The Error Count field is four octets in length, and indicates the
number of errors which have been detected on the link with the number of errors which have been detected on the link with the
identified system. identified system.
The System Heard extension MUST be included in every System The System Heard extension MUST be included in every I-Am-Here.
Advertisement.
3.4. Routing Information 5.5. Security-Information
A summary of the Routing Information extension format is shown below. A summary of the Security-Information extension format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 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 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 | | | Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Designated Backup + | |
| |
| Compartments |
| |
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
5 5
Length Length
14 22
Designated Backup Compartments
The Designated Backup field is eight octets in length, and contains The Compartments field is sixteen octets in length.
the identifier of the designated backup for this area.
This extension is included in the Intermediate System Advertisement of This extension is included in the Intermediate-System I-Am-Here to
the Designated Router, to assert its status as the Designated Router, indicate that it will accept transit traffic for the designated security
and indicate the Designated Backup. compartments.
3.5. Service Information 5.6. Service-Information
A summary of the Service Information extension format is shown below. A summary of the Service-Information extension format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 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 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 | | Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
6 6
Length Length
6 14
QoS System Identifier
The Quality of Service field is two octets in length, and indicates a The System Identifier field is eight octets in length, and contains
service for which transit will be accepted. 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 5.7. Transit-Information
The Preference field is four octets in length, and indicates the A summary of the Transit-Information extension format is shown below.
preference level for use of this network to forward packets of the The fields are transmitted from left to right.
indicated service. Lower values indicate greater preference.
This extension is included in the Intermediate System Advertisement to 0 1 2 3
indicate that it will accept transit traffic. If this extension is not 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
included, the system will treat the link as a stub network. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Abstraction Algorithm Type
An Area is defined to be a collection of subnets which are aggregated 7
as the same next hop.
The areas are learned from the Advertisements, which contain the Length
necessary subnet information. The subnets are assigned by hand.
When the subnet mask shortens by at least one bit, a new level of 6
area is created. The area is defined by an area index (assigned by
the designated router of the affected area), and the count of bits
common 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 QoS
automatic. Discovery of aggregate areas is made by routers one hop
out from the area. This is communicated through its Advertisements,
which are heard by the routers bordering the area.
This algorithm results in a few, fairly large areas. There can never The Quality of Service field is one octet in length, and indicates a
be more than 64 levels of area, and it is more likely to be 5 to 10 service for which transit will be accepted.
because of natural assignment boundaries. The numbering space also
places a limit on the number of routers bordering an area to 255, but
that is highly unlikely.
Fragmentation of areas simply results in automatic generation of Metric
internal areas, and has no effect on area levels farther out.
Security Considerations 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.
Security issues are not discussed in this memo. 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.
Security Considerations
References References
[1] [1]
[2] [2]
Acknowledgments Acknowledgments
Chair's Address Chair's Address
skipping to change at line 805 skipping to change at line 1780
William Allen Simpson William Allen Simpson
Daydreamer Daydreamer
Computer Systems Consulting Services Computer Systems Consulting Services
P O Box 6205 P O Box 6205
East Lansing, MI 48826-6205 East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.edu EMail: Bill.Simpson@um.cc.umich.edu
Table of Contents Table of Contents
1. Criteria .............................................. 1 1. Terminology ........................................... 1
2. Additional ICMP Packets ............................... 5 2. Criteria .............................................. 2
2.1 System Solicitation ............................. 6
2.1.1 Description ..................................... 6
2.2 System Advertisement ............................ 8
2.2.1 Description ..................................... 10
3. Extensions ............................................ 11 3. Design and Use ........................................ 7
3.1 Media Access .................................... 13 3.1 System Identification ........................... 8
3.2 Other Identifiers ............................... 14 3.2 Intermediate System Advertisements .............. 9
3.3 System Heard .................................... 16 3.2.1 Constants ....................................... 10
3.4 Routing Information ............................. 19 3.2.2 Configuration ................................... 10
3.5 Service Information ............................. 20 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. Abstraction Algorithm ................................. 21 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
SECURITY CONSIDERATIONS ...................................... 22 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
REFERENCES ................................................... 22 SECURITY CONSIDERATIONS ...................................... 49
REFERENCES ................................................... 49
ACKNOWLEDGEMENTS ............................................. 22 ACKNOWLEDGEMENTS ............................................. 49
CHAIR'S ADDRESS .............................................. 22 CHAIR'S ADDRESS .............................................. 49
AUTHOR'S ADDRESS ............................................. 22 AUTHOR'S ADDRESS ............................................. 49
 End of changes. 141 change blocks. 
325 lines changed or deleted 1326 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/