draft-ietf-sip-discovery-02.txt   draft-ietf-sip-discovery-03.txt 
Network Working Group W A Simpson Network Working Group W A Simpson
Internet Draft Daydreamer Internet Draft Daydreamer
SIP System Discovery expires in six months December 1993
SIPP Neighbor Discovery
draft-ietf-sip-discovery-03.txt
Status of this Memo Status of this Memo
This memo is the product of the SIP Working Group of the Internet This memo is the product of the SIPP Working Group of the Internet
Engineering Task Force (IETF). Comments on this memo should be Engineering Task Force (IETF). Comments on this memo should be
submitted to the sip@caldera.usc.edu mailing list. submitted to the sipp@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. Internet Drafts are draft working documents as Internet Drafts.
documents valid for a maximum of six months. Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time. It Internet Drafts are draft documents valid for a maximum of six
is not appropriate to use Internet Drafts as reference material or to months. Internet Drafts may be updated, replaced, or obsoleted by
cite them other than as a ``working draft'' or ``work in progress.'' 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 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, ds.internic.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 discusses the identification and location of adjacent
location of adjacent SIP systems. This is intended to replace ARP, SIPP nodes.
ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP
Mask, and OSPF Hello in the SIP environment. There are also elements
of the OSI ES-IS and IS-IS Hello.
1. Terminology 1. Goals
The following terms have a precise meaning when used in this Historically, the methods for determination of the next-hop media
document: address evolved separately from those for location of neighbors or
system a device that implements the Internet Protocol, IP [9]. auto-configuration of systems. With the advent of SIPP, the old
techniques must be re-implemented, usually due to larger field sizes.
intermediate-system Unfortunately, older implementations frequently did not take proper
a system that forwards datagrams, as specified in [2]. care in differentiating existing variable field lengths, version
Often called a router or gateway. This does not include numbers, and new types of messages. None of the current protocols
systems that, though capable of forwarding, have that are readily extensible. While some have the ability to change in
capability turned off. Nor does it include systems that simple terms, such as larger addresses, none were designed to add new
do forwarding only as required to obey Source Route kinds of information to be carried in the same packet.
options.
end-system any system that is not acting as an intermediate-system. Therefore, the techniques used for SIPP are required to be
Often called a host. distinguishable from previous IP versions. This is an opportunity to
design a uniform and coherent method for accomplishing these goals.
dumb the minimal implementation. This is not meant in a Find Neighbors
perjorative sense. It is intended that every mechanism
be defined in such a way that it is implementable on a
minimal system.
smart an improved implementation, possibly requiring more Each SIPP node needs to determine the availability of other SIPP
internal resources, while using less external resources. nodes as demand for communication occurs.
multicast unless otherwise qualified, means the use of either IP Each SIPP host needs to detect the presence of available SIPP
multicast [4] or IP broadcast [6] service. routers.
link a communication facility or medium over which systems Redirect
can communicate at the link layer; that is, the protocol
layer immediately below IP. The term "physical network"
has sometimes been used (imprecisely) for this.
Examples of links are LANs (possibly bridged to other
LANs), wide-area store-and-forward networks, satellite
channels, and point-to-point circuits.
multicast link a link over which IP multicast or IP broadcast service A redirect is used when a packet could be sent more directly to
is supported. This includes broadcast media such as the SIPP next-hop, or to indicate that another SIPP router should
LANs and satellite channels, single point-to-point be used for forwarding specific packets.
circuits, and some store-and-forward networks such as
SMDS networks [8].
interface a system's attachment point to a link. It is possible Resolve Media Address
(though unusual) for a system to have more than one
interface to the same link.
multicast interface Each SIPP node which desires to send to another SIPP node needs to
an interface to a multicast link; that is, an interface know the appropriate media address, when the link is not a point
to a link over which IP multicast or IP broadcast to point link. It is more efficient to learn this in the same
service is supported. transaction as the neighbor is found or traffic is redirected.
identifier uniquely identifies each interface; a single interface Learn Prefix
may have more than one such identifier.
primary identifier When prefix-routing is in use, it is necessary to determine the
uniquely identifies each system; only one such prefix(es) for a local subnet. Local prefixes and multiple
identifier is used, to simplify discovery of neighbors. providers are supported.
subnet either a single link of a subnetted IP network [7] or Change Prefix
a single non-subnetted link.
prefix the part of an identifier which may be used for routing When a prefix changes, it is necessary to update the nodes.
to a particular subnet, defined by logically ANDing with
its assigned subnet mask. More than one subnet prefix
may identify the same link.
zone the part of a special identifier which indicates a Mobility
unique subnet within an administrative domain.
neighbor having an identifier belonging to the same subnet. The same mechanisms which support wired identification and
location are used to provide mobile beaconing and roaming within
clusters.
2. Criteria 2. Criteria
Historically, the methods for discovery of the next-hop evolved
separately from those for location of neighbors and auto-
configuration of systems. With the advent of SIP, the old techniques
must be re-implemented, usually due to larger field sizes.
Unfortunately, older implementations frequently did not take proper
care in differentiating existing variable field lengths, version
numbers, and new types of messages. Therefore, the techniques used
for SIP are required to be distinguishable from previous versions.
None of the current protocols are readily extensible. While some
have the ability to change in simple terms, such as larger addresses,
none were designed to add new kinds of information to be carried in
the same packet.
This can be viewed is an opportunity to design a uniform and coherent
method for accomplishing these goals, rather than a liability.
Through prior experience, the following criteria were established, in Through prior experience, the following criteria were established, in
order of relative importance. It is understood that many of these order of relative importance. It is understood that many of these
criteria may conflict, and require numerous tradeoffs. criteria require various tradeoffs.
Multicast support Multicast support
All SIP systems are required to support multicast. All SIPP systems are required to support multicast techniques.
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 There are numerous advantages to using multicast for the new
messages. In particular, when compared to broadcast, reduced messages. In particular, when compared to broadcast, reduced
overhead for processing messages which are not ultimately intended overhead for processing messages which are not ultimately intended
for the local system. for the local system.
This is the primary technique for distinguishing the new messages.
Older systems will discard SIPP multicast messages at the link
layer.
Not all media supports multicast. Since multicast is directly Not all media supports multicast. Since multicast is directly
supported by the SIP header, this technique will work even when supported by the SIPP header, this technique will work even when
using link-layer broadcast, or link-layer unicast to each using link-layer broadcast, or link-layer unicast to each
recipient. recipient. Older systems should discard SIPP headers at the
network layer.
Reduced net traffic Reduced net traffic
Currently, there are separate packets sent for media address Currently, separate packets are sent for media address resolution,
resolution, router discovery, and the Hello protocols for the router discovery, and the Hello protocols for the various routing
various routing algorithms. Since much of the same information is algorithms. Since much of the same information is contained in
contained in each of these packets, it would be helpful to combine each of these packets, it would be helpful to combine the
the functions in a single packet where possible. 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.
Several alternative methods were proposed:
1) The ISO solution (ES-IS) eliminates some of these problems.
Each end-system and intermediate-system sends Hellos on a
periodic basis. Every 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.
2) The first packet destined for an unknown system may be sent
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. The
destination identifer in the network header will be unicast,
while the media address will be multicast. 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.
3) 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 solution that is detailed here is a combination of the best
features of the preceding techniques.
Intermediate-systems advertise their locations. When an
intermediate-system needs the location of an end-system, it
requests the location of the end-system, and the end-system
replies. Knowledge about end-systems is concentrated in the
intermediate-systems, but only for the systems that are actually
communicating.
End-systems send all datagrams directly to the intermediate-
systems. If there is a more direct path to the end-system,
because it is directly accessible on the local link or another
intermediate-system would be more appropriate, the intermediate-
system issues a redirect.
Also, by carrying media addresses within the advertisements and This is particularly important in broadcast mobile environments,
redirect packets, a further ARP-like query/response can be avoided due to the time for setup of transmission, the increased per frame
entirely. overhead for contention resolution, and forward error correction.
Low storage overhead Low storage overhead
It is desirable that systems require as little storage overhead as It is desirable that systems require as little storage overhead as
possible. In particular, mobile systems often have significantly possible. In particular, mobile nodes often have significantly
reduced processing power and memory. reduced processing power and memory.
An end-system need only retain information for those end-systems A host should only retain information for those hosts with which
with which it is directly communicating. it is directly communicating.
This design requires sufficient storage in an end-system for There must be sufficient storage in a host for information about
information about at least one intermediate-system. In addition, at least one router. In addition, storage is required for at
storage is required for at least one location of each service least one location of each service (such as a domain name server)
(such as a domain name server) which is used. which is used.
An intermediate-system may require more processing power and A router may require more processing power and memory.
memory. Participation in routing protocols requires the knowledge Participation in routing protocols requires the knowledge of every
of every neighboring intermediate-system. neighboring router.
When subnet prefix-routing is in use, it is not necessary for an When prefix-routing is in use, it is not necessary for a router to
intermediate-system to determine the location of an end-system determine the location of a host until traffic for the host
until traffic for the end-system arrives. If prefix-routing is arrives. If prefix-routing is not used, particularly in mobile
not used, particularly in radio and mobile environments, the environments, the location of each reachable host must be
location of each reachable end-system must be continuously
retained. retained.
Auto-configuration Auto-configuration
It would be highly desirable that the connection procedures for a The connection procedures for a configuring a new system are
configuring a new system are reduced to the minimal set of "plug reduced to the minimal set of "plug it in, turn on the power, and
it in, turn on the power, and run". run".
- Each system, or more precisely each interface, should be - Each node is assigned an identifier, usually within the number
assigned an identifier, within the number space assigned to the space assigned to the local subnet.
local subnet.
- Each system should be assigned a name within the local domain. - The node discovers the routers attached to the local subnet, so
The name, and the associated identifiers, should be registered that it can exchange packets with remote systems.
in the local domain name server.
- The system should discover the external routes provided by the - The node discovers the location of servers that it needs for
intermediate-systems attached to the local subnet, so that it configuration, loading, dumping, printing, and other services.
can exchange packets with remote systems.
- The system should discover the location of servers that it - If desired, each node is assigned a name within the local
needs for configuration, loading, dumping, printing, and other domain. The name, and the associated identifiers, can be
services. registered in the local domain name server.
In evaluating previous experience with autoconfiguration In evaluating previous experience with autoconfiguration
procedures, the following constraints were determined: procedures, the following constraints were determined:
1) It is not possible to embed an IEEE-802 component within 1) Using the 48-bit IEEE-802 number to identify one node within
every SIP identifier, since the remaining prefix would be a local subnetwork that is not designed to accomodate more
too small for global routing. Using the 48-bit IEEE-802 than a few hundred systems is considerable overkill.
number to identify one system within a local network that is
not designed to accomodate more than a few hundred systems However, it may be worthwhile to use an IEEE-802 number
is considerable overkill. It may be worthwhile to use the during initial configuration, until a globally routable
address during initial configuration. identifier can be assigned.
2) Random identifier assignments are to be avoided. They do 2) Random identifier assignments are to be avoided. They do
not scale well to large networks, are difficult to track and not scale well to large networks, are difficult to track and
manage, and lead to administrative confusion. Relying on manage, and lead to administrative confusion.
broadcast collision resolution procedures for avoiding
duplicate assignments results in conflicts when systems
occupy partitioned subnets, or are frequently powered down
or taken off-line.
3) Reassignment of identifiers should be transparent to the Relying on broadcast collision resolution procedures for
human users. In particular, renumbering, and assignment of avoiding duplicate assignments results in conflicts when
alias identifiers as a mobile system moves should be nodes occupy partitioned subnets, or are frequently powered
automatic. down or taken off-line.
4) End-system users should not be concerned with routing 3) Changes of identifiers should be transparent to the human
prefixes, or the routing methods extant on the local users. In particular, renumbering for changes of providers,
network. When used, such prefixes should be automatically and assignment of alias identifiers as a mobile node moves,
determined, and dynamic changes should propagate should be automatic.
automatically.
5) It is important to allow users to choose a system name which 4) Users should not be concerned with routing prefixes, or the
routing methods extant on the local network. When used,
such prefixes should be automatically determined, and
dynamic changes should propagate automatically.
5) It is important to allow users to choose a node name which
is memorable and comfortable to them. The name should be is memorable and comfortable to them. The name should be
automatically registered, and changes to the associated automatically registered, and changes to the associated
identifers should be maintained automatically. identifers should be maintained automatically.
This design handles initial self-identification and propagation of This design provides initial self-identification and propagation
changes in identification. Other aspects of configuration, such of changes in identification. Other aspects of configuration,
as loading the operating system and environment, and additional such as loading the operating system and environment, and
facilities and servers for registration, are specified elsewhere. additional facilities and servers for registration, are outside
the scope of neighbor discovery.
Mobility support Mobility
This is sometimes considered a subset of the above, as related to As mentioned repeatedly above, mobility is an important
dynamically changing addresses while moving. Other systems must consideration when evaluating these criteria.
be notified of the changes.
In addition, the "hidden transmitter" problem is considered (you When identification is dynamically changing while moving, other
can hear another system, it can't hear you, but there is a path to nodes must be notified of the changes.
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 In addition, the "half link" problem has to be considered. This
additional facilities and servers are specified elsewhere. occurs when node J can hear node K, but K cannot hear J. If there
is a path from J to a router which K can hear, completing the
circuit, communication can still occur.
Only basic support for mobility is provided. Other aspects of
mobility, such as registration and caching, are outside the scope
of neighbor discovery.
Black hole detection Black hole detection
In determining whether the next-hop system is still available, In determining whether the next-hop node is still available, there
there is a basic tradeoff between frequent queries and resources is a basic tradeoff between frequent queries and resources used.
used. This design trades fewer queries against more information This design trades fewer queries against more information within
within each query and response. each query and response.
Explicit holding times are used to limit the exposure to black Explicit holding times are used to limit the exposure to black
holes. The times may be dynamically shortened by the responsible holes. The times may be dynamically shortened by the responsible
system when a resource is critical, or when the system is actively node when a resource is critical, or when the node is actively
moving. moving.
Media independence Media independence
There are many instances where system discovery is accomplished There are many instances where node discovery is accomplished
differently over different media, such as point-to-point versus differently over different media, such as point-to-point versus
broadcast versus Large Public Data Networks. This design places broadcast versus Public Data Networks. This design places the
the system discovery above the network layer, where it enjoys neighbor discovery above the network layer, where it enjoys
greater independence. It also encompasses media level redirects greater independence.
between multiple logical subnets on the same physical media.
There are difficulties with carrying media addresses within There are difficulties with carrying media addresses within
packets, especially in the presence of multi-media bridges. packets, especially in the presence of multi-media bridges.
Rather than allowing translation by bridges in the path, this Rather than allowing translation by bridges in the path, this
design exercizes control at the destination system, and requires design exercizes control at the destination node, and requires all
all such media addresses to be in canonical form, such media addresses to be in canonical form.
Optimal route determination Optimal route determination
This is essentially a superset of next-hop discovery, combined This is essentially a superset of next-hop discovery, combined
with resource reservation and possible policy considerations, and with resource reservation and possible policy considerations, and
the ability to redirect traffic under changing conditions. This the ability to redirect traffic under changing conditions. This
is not well supported in any of the past protocols. is not well supported in any of the past protocols.
The design encompasses media level redirects between multiple
logical subnets on the same physical media, and provides for the
absence of logical subnetting information when visiting mobile
hosts continue to use their native identifiers.
To balance system overhead against network traffic, this design To balance system overhead against network traffic, this design
attempts to adapt to a continuum of system capabilities. Dumb attempts to adapt to a continuum of machine capabilities. Dumb
end-systems may simply send packets to a default intermediate- hosts may simply send packets to a default router, and be
system, and be redirected to the correct next-hop by more capable redirected to the correct next-hop by the more capable routers.
intermediate-systems. Smarter end-systems learn sufficient Smarter hosts learn sufficient information to make informed
information to make informed choices. choices.
Simplicity 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 This design reduces the number of packet types which must be
supported in a pure SIP system, and reduces the number of systems supported in a pure SIPP node, and reduces the number of nodes
which recognize and respond to each type. The extensions are which recognize and respond to each type. The packets are
designed with 32 and 64 bit boundaries for efficient processing. designed with 32 and 64 bit boundaries for efficient processing.
3. Design Overview 3. Historic Methods
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
A Zone is defined to be a collection of links which may be
accessed as the same next-hop. A Zone is usually a single link,
or a collection of bridged links. When a single intermediate-
system is connected to multiple point-to-point links, these links
may be collected into a single zone.
The Zone number is a fixed size. The value 0 is only used to
indicate the local zone. The values 1 through 255 indicate each
zone within an administrative domain.
Zone numbers may be combined with an interface media address to
make a locally significant identifier. This is useful for initial
configuration and local communication within the administrative
domain. These identifiers may be routed in a similar manner to
prefix-routed subnets.
The generation of these local identifiers depends upon the
availability of a registered unique number, such as an IEEE-802
number. When there is no IEEE-802 number to be found anywhere in
the machine, such as when the machine is connected exclusively to
point-to-point links, an external link-level mechanism MUST be
used to negotiate a unique identifier. Such a mechanism is beyond
the scope of this document.
Prefix
A Prefix is similar to a Zone, in that it identifies a collection
of links which may be accessed as the same next-hop. The Prefix
may indicate a single zone, a collection of zones, an entire
administrative domain, or a collection of administrative domains.
The Prefix is variable in size. The Prefix Size ranges from 1 to
62. The value of 63 cannot be used, since at least 2 bits of the
SIP 64-bit identifier are reserved to identify a particular
system.
Prefix-routed subnet identifiers are supported for addressing
globally connected networks in the metropolitan and/or provider
addressing models.
End-Point Identifiers
End-Point identifiers, or any other globally unique identifier,
may be used with future routing techniques. An End-Point
Identifier is indicated as having a Prefix Size of 0. 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. Multicast Support
Every SIP system MUST join the all-systems multicast group on all
interfaces on which the system supports multicast.
Every SIP intermediate-system MUST also join the all-routers
multicast group.
Every SIP end-system which offers a particular service MUST also join
the multicast group for that service. Intermediate-systems do not
join the service multicast group, as their services are discovered
under a separate process.
4. 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
intermediate-system advertisement messages.
The intermediate-system advertisements also serve to indicate zone
and subnet prefixes for each link, and to establish neighbor
relationships with other intermediate-systems.
Each intermediate-system periodically sends the I-Am-Here message to
advertise its forwarding capability. End-systems and intermediate-
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 advertisement messages do not constitute a routing protocol,
although they might be used by a routing protocol to build a map.
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.
4.1. Solicitations
Every SIP end-system MUST implement Intermediate-System Solicitation.
When any end-system starts up, it MUST send the Where-Are-You
solicitation to prompt the advertisement of intermediate-systems.
This is also used by the intermediate-systems to construct a map of
accessible end-systems, to discover partitions in the local subnet,
and to support mobile 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 intermediate-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
intermediate-system advertisements, rather than increasing the number
of solicitations that end-systems are permitted to send.
4.1.1. Constants
MAX_SOLICITATIONS 3 transmissions
MAX_SOLICITATION_DELAY 1 second
SOLICITATION_INTERVAL 3 seconds
4.1.2. Implementation
The intermediate-system solicitation is sent to the all-routers
multicast, with the scope set to local.
An end-system is required to transmit up to MAX_SOLICITATIONS Where-
Are-You 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 forwarding capability turned off by system
management.
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.
4.1.3. Receipt
An end-system MUST silently discard any received Intermediate-System
Solicitation messages.
An intermediate-system MUST silently discard any received
Intermediate-System Solicitation messages that do not satisfy the
following validity checks:
- ICMP Checksum is correct.
- ICMP length (derived from the payload length) is 16 or more
octets.
- Source Address is either 0 or the identifier of a neighbor (an
identifier that matches one of the intermediate-system's own
identifiers on the arrival interface under the prefix mask
associated with that identifer, or the zone associated with that
interface).
4.2. Advertisements
Every SIP intermediate-system MUST implement Intermediate-System
Advertisements.
The intermediate-system advertisements include such important
information as the media address to access the system, other subnets
directly accessible through the system, services available through
the 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.
Zone
Each advertised identifier includes a zone field. The value
ranges from 0 to 255, and indicates a subnet number which is
unique to the administrative domain. A value of zero indicates
that no zone number has been assigned. It may be combined with an
interface media address to make a locally significant identifier.
If all advertised zone values are zero, then zone routing is not
available beyond that link. This does not prevent the use of
locally significant identifiers for communication with other
systems on the local link.
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 prefix-routed subnet
mapping.
If all advertised prefix values are zero, then subnet prefix-
routing is not in use on that link.
Preference
Each advertised identifier includes a preference field. This is
used to choose a default intermediate-system for the first-hop
when the end-system has not yet been redirected or configured to
use a specific intermediate-system for a particular destination.
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 how 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.
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.
4.2.1. Constants
MAX_INITIAL_ADVERTISEMENTS 3 transmissions
MAX_INITIAL_ADVERT_INTERVAL 16 seconds
MAX_RESPONSE_DELAY 2 seconds
4.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.
4.2.3. Implementation
The intermediate-system advertisement is sent to the all-systems
multicast, with the scope set to local.
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 MUST transmit periodic
I-Am-Here messages.
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.
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.
In addition to the periodic unsolicited advertisements, an
intermediate-system MUST send advertisements in response to valid
advertisements or solicitations received on any of its advertising
interfaces. If the advertisement or solicitation does not contain
any System-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.
Whenever these response advertisements are sent, the advertisement
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. The
interface's interval timer is reset to a new random value, as with
unsolicited advertisements.
4.2.4. Receipt
All systems MUST silently discard any received Intermediate-System
Advertisement messages that do not satisfy the following validity
checks:
- ICMP Checksum is correct.
- ICMP length (derived from the payload length) is 16 or more
octets.
- At least one Routing-Information extension.
- For interfaces which are not point-to-point links, the Media-
Access extension.
4.3. Processing Advertisements
Every intermediate-system saves the information contained in the
advertisements, in order to respond to future requests. Any other
action on receipt of such messages by an intermediate-system (for
example, as part of a "peer discovery" process) is beyond the scope
of this document.
An end-system saves the information contained in the advertisements,
in order to determine the first-hop when sending datagrams. First-
hop determination is elaborated in a subsequent section.
4.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
4.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.
5. End-System Discovery
Within a directly attached link, each system must be able to locate
end-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 an intermediate-system needs the location of an end-system, it
sends the Where-Are-You solicitation. The target end-system responds
with the I-Am-Here advertisement.
When no intermediate-system advertisements have been heard, an end-
system sends the Where-Are-You solicitation itself. The target end-
system responds with the I-Am-Here advertisement as usual.
When an end-system has heard one or more intermediate-system
advertisements, the default behavior is to send all datagrams to the
preferred intermediate-system. If the target end-system is
accessible on the local link, the intermediate-system sends a
redirect back indicating the appropriate media address.
When an end-system has heard one or more intermediate-system
advertisements, and no zone or prefix-routing is being used, or no
prefix matches any current interface identifier, the end-system can
assume that it is operating as a mobile end-system. The mobile end-
system advertises on a periodic basis, just as an intermediate-
system.
5.1. Solicitations
Every SIP system MUST implement End-System Solicitation for discovery
of local end-systems.
When a system is ready to send a datagram to another system, it
examines its cache of system locations. If no intermediate-system
advertisements have been received, the system MUST send the Where-
Are-You solicitation to prompt the advertisement of the target
system.
If (and only if) no advertisements from the target system are
forthcoming, the system MAY retransmit the Where-Are-You a small
number of times, but then MUST desist from sending more
solicitations.
5.1.1. Implementation
The end-system solicitation is sent to the all-systems multicast.
The end-system solicitations use the same configuration constants as
intermediate-system solicitations.
Unlike intermediate-system solicitations, end-system solicitations
are sent only when a particular end-system location is needed, rather
than on startup.
End-system solicitations are sent using the same periodicity
calculations as intermediate-system solicitations.
Upon receiving a valid advertisement from any intermediate-system, an
end-system MUST NOT send any end-system solicitations.
5.1.2. Receipt
An intermediate-system MUST silently discard any received End-System
Solicitation messages.
An end-system MUST silently discard any received End-System
Solicitation messages that do not satisfy the following validity
checks:
- ICMP Checksum is correct.
- ICMP length (derived from the payload length) is 16 or more
octets.
- Source Address is either 0 or the identifier of a neighbor (an
identifier that matches one of the end-system's own identifiers on
the arrival interface under the prefix mask associated with that
identifer, or the zone associated with that interface).
5.2. Advertisements
Every SIP end-system MUST implement End-System Advertisements.
Usually, end-system advertisements are sent in response to end-system
solicitations. In addition, mobile end-system advertisements and
service end-system advertisements (described below) are sent on a
periodic basis.
The end-system advertisements include such important information as
the media address to access the system, and neighboring
intermediate-systems heard.
5.2.1. Implementation
The periodic mobile end-system advertisement is sent to the all-
routers multicast.
The single end-system advertisement in respnse to a solicitation is
sent to the all-systems multicast.
In either case, the scope is set to local.
CONTROVERIAL: The all-systems multicast is used for end-system
advertisements, rather than responding directly to the soliciting
system. This is under the assumption that all intermediate-
systems need to update the list of active end-systems, when the
query is sent by a router. Logically, the response could be sent
to all-routers.
However, when the query is sent by an end-system, there are no
routers present. The response could be sent directly to the
requesting end-system.
There is no easy way to determine that the sender was an
intermediate-system rather than an end-system. The only multicast
which covers both cases is all-systems.
Mobile advertisements use similar configuration constants and
variables as intermediate-system advertisements.
Mobile advertisements are sent using the same periodicity
calculations as intermediate-system advertisements.
Advertising interfaces are established and terminated in the same
manner as intermediate-system advertisements.
6. Service Discovery
Each system offering one of the special configuration services
detailed below, whether an end-system or intermediate-system,
includes that service availability in every advertisement that it
sends. 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 initial services listed here are primarily concerned with
configuration. The locations of other facilities may be learned from
these basic servers.
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.
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 can use the DNS server advertisements. Full-Service resolvers
MUST continue to be manually configured to ensure a heirarchy of
believability within the network.
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.
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.
6.1. Solicitations
Every SIP end-system SHOULD implement End-System Solicitation for
discovery of local services.
When a system is ready to use a particular service, it examines its
cache of such services. If no intermediate-system or other service
advertisements have been received, the system MAY send the Where-
Are-You solicitation to prompt the advertisement of the service.
If (and only if) no advertisements from desired services are
forthcoming, the system MAY retransmit the Where-Are-You a small
number of times, but then MUST desist from sending more
solicitations.
6.1.1. Implementation
The service solicitation is sent to the special multicast for each
particular service, with the scope set to local.
The service solicitations use the same configuration constants as
intermediate-system and end-system solicitations.
Unlike intermediate-system solicitations, service solicitations are
sent only when a particular service is utilized, rather than on
startup.
Service solicitations are sent using the same periodicity
calculations as intermediate-system and end-system solicitations.
Upon receiving a valid advertisement from any intermediate-system,
the system MUST NOT send any service solicitation.
Service solicitations require the same validity checks as end-system
solicitations.
6.2. Advertisements
Like intermediate-system and mobile end-system advertisements,
service end-systems advertisements are sent on a periodic basis.
Services offered by intermediate-systems are included in the
intermediate-system advertisements described above.
6.2.1. Implementation
The service advertisement is sent to the all-systems multicast, with
the scope set to local.
CONTROVERIAL: The all-systems multicast is used for service
advertisements, rather than different multicasts for each service.
This is under the assumption that all systems need to learn of
services.
This corresponds to the design for intermediate-system
advertisements. Thus, intermediate-system advertisements can be
viewed as a special case of service advertisements.
This ensures that the design will operate when there are no
routers, and when the routing protocols are still initializing.
The service advertisements use similar configuration constants and
variables as intermediate-system advertisements.
Service advertisements are sent using the same periodicity
calculations 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.
7. Self Discovery
7.1. End-Systems
At startup, each SIP end-system solicits the advertisements of
intermediate-systems, as described in Intermediate-System Discovery
above. Until an intermediate-system is discovered, an end-system is
limited to accessing systems and services for the links to which it
is directly attached.
In the absence of an intermediate-system, each SIP end-system
solicits the advertisements of services as described in Service
Discovery above. Until self-configuration services are discovered,
an end-system is limited to accessing systems and services according
to prior configuration.
7.1.1. Zone Determination
Until an intermediate-system is discovered, an end-system assumes a
zone number of zero. When combined with any IEEE-802 number found in
the machine, or other identifier negotiated at the link level, this
yields a local identifier which is unique to the system.
When an intermediate-system is discovered, the advertisements are
examined for zone information, as described in Intermediate-System
Discovery above. If all advertised zone values are zero, then zone
routing is not available beyond that link. If more than one zone
number is discovered for the same interface, only the highest zone
number is used.
When there is more than one interface on a multi-homed end-system,
each interface MUST answer to all of the local identifers generated.
When more than one IEEE-802 number is available, the primary system
identifier is composed of the highest zone discovered, combined with
the highest IEEE-802 number found.
7.1.2. Initialization
Once a system has becomed locally addressable, it can engage in
exchanges with local servers. Some of these local servers could be a
bootstrap service, for loading and configuring the system. Another
server could be a registration service, in charge of managing the
local name and identifier space.
When the registration service is unable to find a match for the
system, the system SHOULD request the operator to provide a name for
the system. The registration service would be responsible for
ensuring uniqueness, and assigning appropriate identifiers for the
name.
Further specification of such services is beyond the scope of this
document.
7.1.3. Identifier Determination
Once the Domain Name has been determined for a system, the Domain
Name Service SHOULD be consulted to determine the globally advertised
identifiers for the system. In this fashion, system is coordinated
with the most current information actually propagated within the
internet.
Each DNS identifier has a Time-To-Live associated with it. When any
identifier expires, another request SHOULD be made to the DNS for a
list of identifiers.
When there is more than one interface on a multi-homed end-system,
each interface MUST answer to all of the identifers learned.
When more than one identifier is returned for a system, the primary
system identifier is the identifier with the highest TTL, or the
first listed identifier of those with the highest TTL.
7.1.4. Prefix Determination
The prefix size is dynamically learned from matching interface
identifiers against the intermediate-system advertisements, as
described in Intermediate-System Discovery above.
Unlike previous practice, an end-system prefix sizes SHOULD NOT be
preconfigured. Any preconfigured value MUST be superceded by new
values and changes propagated in intermediate-system advertisements.
7.1.5. Changing Identifiers
7.2. Intermediate-Systems
The zones and prefixes are assigned by hand.
8. Next-Hop Determination
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.
multi-homed
preferred router
smart selection
local redirect
remote redirect
8.1. Examples of Use
Simple case -- J to K on the same fully-connected link.
J sends the Where-Are-You (which contains its own media address)
to all-systems. K sends the I-Am-Here (which contains its own
media address) directly to all-systems. At this point, they
both know that they can talk directly to each other, without
regard to subnet.
Routed case -- J to K not on the same fully-connected link.
If no resource reservation or policy routing is desired, J
simply sends its packets directly to the "preferred" router that
it has learned from the Advertisements. If there is a better
router for the first-hop, that router sends the I-Am-Here
redirect to J, but never-the-less forwards the packet.
In the presence of RR or PR, J sends a Where-Are-You to the
"preferred" router that it has learned from the Advertisements.
That router always returns an I-Am-Here redirect (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 periodically sends the I-Am-Here (which contains its own media
address, and the addresses of its "heard" routers) to the
all-routers multicast. 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 Where-Are-You to K,
with a 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.
When K hears the Where-Are-You, it sends the I-Am-Here to the
all-systems address. The "best" router on J's "heard" list
sends an I-Am-Here redirect 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.
Of course, J may have heard K's I-Am-Here directly.
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.
9. Additional ICMP Packets
The Packet format and basic facilities are already defined for ICMP
[3], as modified for SIP [1].
Up-to-date values of the ICMP Type field are specified in the most
recent "Assigned Numbers" RFC [2]. This document concerns the
following values:
<TBD> Where-Are-You
<TBD> I-Am-Here
9.1. Where-Are-You
A summary of the Where-Are-You message format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<TBD>
Code
The Code field is one octet. Up-to-date values of the I-Am-Here
Code field are specified in the most recent "Assigned Numbers" RFC
[2]. Current values are assigned as follows:
0 RESERVED
1 End-System Solicitation
2 Intermediate-System Solicitation
Checksum
The ICMP Checksum.
System Identifier
The System Identifier field is eight octets in length, and ARP
contains an identifier of the system which is sought. When the
identifer of the system is unknown, the field is zero filled.
Extensions The most common next-hop resolution protocol, the Address Resolution
Protocol (ARP), is done at the link level rather than the network
level. It requires an additional two media packets at the beginning
of each connection. A 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, particularly when multiple hops need to
use ARP.
The Extensions field is variable in length and contains zero or ARP is simple, and has low storage overhead.
more Extensions. These Extensions are described in a later
section.
The contents of the Reserved field are ignored. Future backward- ARP is deemed inadequate because it is a broadcast rather than a
compatible changes to the protocol may specify the contents of the multicast technique, is frequently media dependent, is not easily
Reserved field or of additional octets at the end of the message. extensible for auto-configuration or mobility support, and it does
not directly support black-hole detection.
9.1.1. End-System Solicitation ICMP Router Discovery
The End-System Solicitation contains the following values: The ICMP Router Discovery messages provide some of the desired
features. Each router sends Hellos on a periodic basis. After
determining that a destination is not on the local media, a host can
send packets directly to a "preferred" router, which forwards the
packet to the correct destination. If a better next-hop is known,
the router sends a redirect to the host.
- In the Destination Address field of the SIP header: For service This can reduce the traffic from 3 to 2 packets at the beginning of a
solicitations, the special multicast group associated with the connection. Unfortunately, the technique is not widely implemented
service. For other solicitations, the all-systems multicast. In in the current generation of protocols.
either case, the scope is set to local.
- In the Source Address field of the SIP header: any identifier It does not provide a comprehensive solution to auto-configuration,
associated with the sending interface. It MAY contain zero if the mobility, black-hole detection, or media independence.
system has not yet determined an identifier for the interface.
- In the Code field of the ICMP header: 1 for End-System ES-IS Hellos
Solicitation.
- For each intermediate-system advertisement that has been heard, The ISO solution (ES-IS) addresses some of these problems. Each host
the System-Heard extension. and router sends Hellos on a periodic basis. Every node must
remember all of the media addresses for the other systems on the
local network.
- For interfaces which are not point-to-point links, the Media- However, the traffic overhead of many packets sent by every node on a
Access extension. regular basis eliminates it from consideration. Also, it requires a
large amount of storage overhead in each node.
In the unlikely event that not all extensions fit in a single Media Multicast
solicitaion, as constrained by the MTU of the link, the remaining
extensions are removed. Only a single solicitation is sent.
9.1.2. Intermediate-System Solicitation The first packet destined for an unknown node might be sent to the
all-systems multicast, or to a media multicast based on a hash
function of the destination. The appropriate node would accept the
packet, and send a redirect indicating the appropriate media address
to be used for future packets.
The Intermediate-System Solicitation contains the following values: This reduces the traffic from 3 to 2 packets at the beginning of a
connection, and eliminates the latency of ARP, as the probe packet
sent is also the data packet. This also eliminates the queuing of
datagrams waiting for the ARP reply.
- In the Destination Address field of the SIP header: the all- However, the destination identifier in the network header will be
routers multicast, with the scope set to local. unicast, while the media address will be multicast.
- In the Source Address field of the SIP header: any identifier If this method were used exclusively, routers would be required to
associated with the sending interface. It MAY contain zero if the listen to all multicasts, and recognize those packets destined beyond
system has not yet determined an identifier for the interface. the local link.
- In the Code field of the ICMP header: 2 for Intermediate-System Multi-homed hosts also require the capability to decide which link to
Solicitation. use, and are not supportable using this technique alone.
- For each of that system's interface identifiers other than the This method is not extensible to include other information useful in
primary identifier, the Other-Identifier extension, with the mobile environments, resource reservation, and policy routing.
prefix size set to zero.
- For each intermediate-system advertisement that has been heard, 4. Solution Overview
the System-Heard extension.
- For interfaces which are not point-to-point links, the Media- This design is a combination of the best features of the preceding
Access extension. techniques.
In the unlikely event that not all extensions fit in a single 4.1. Packets
solicitaion, as constrained by the MTU of the link, multiple
solicitations are sent, with each except the last containing as many
extensions as can fit.
9.2. I-Am-Here This solution 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.
A summary of the I-Am-Here message format is shown below. The fields In order to foster media independence, the packets are part of ICMP,
are transmitted from left to right. 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.
0 1 2 3 4.1.1. Solicitations
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-+-+-+-+-+
Type The Where-Are-You solicitation is used to find other nodes, and
associated resources and services. Router solicitations are sent
when a node interface is initialized. Specific solicitations are
sent when one node is ready to communicate with another particular
node.
<TBD> 4.1.2. Advertisements
Code 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 nodes result in less traffic than
repeated solicitations from many nodes.
The Code field is one octet. Up-to-date values of the I-Am-Here 4.1.3. LifeTime
Code field are specified in the most recent "Assigned Numbers" RFC
[2]. Current values are assigned as follows:
0 RESERVED A lifetime is associated with each node location, specifying the
1 End-System Advertisement maximum length of time that the location is to be considered valid in
2 Intermediate-System Advertisement the absence of further information. The lifetime is set when a
3 Local Redirect solicitation is sent, or when an advertisement is received.
4 Remote Redirect
Checksum This prevents the sending of repeated solicitations, and limits
exposure to black holes. This ensures that other nodes eventually
forget about nodes that become unreachable, whether that is because
the node has failed, or it no longer provides the advertised service.
The ICMP Checksum. 4.1.4. Extensions
Sequence Number Each message contains "optional" extensions, designed to allow
flexibility and extensibility.
The Sequence Number field is two octets in length, and contains One of the common extensions is the media address. Each message
the number of I-Am-Here messsages sent since the system was contains enough information to return a reply directly to the sender,
initialized. This number MUST include this advertisement. without additional location traffic. By carrying media addresses
within the advertisements and redirect packets, a further ARP-like
query/response can be avoided entirely. This reduces traffic, and
further prevents black-holes when forwarding tables are not updated
due to packet loss.
LifeTime Another common extension is a list of the routers which have been
heard. This allows routers to build a map of the paths between
routers, and between routers and hosts. This is designed to be used
by most commonly deployed routing protocols. This also solves the
"half link" problem, when used together with the well-known link-
state class of routing protocols.
The LifeTime field is two octets in length, and indicates the 4.2. Router Discovery
seconds remaining before the entry is considered invalid.
System Identifier Routers advertise their locations periodically. The number of
routers are usually fewer than the number of hosts.
The System Identifier field is eight octets in length, and When a router is present, a host learns whether the local media uses
contains the primary identifier for this system. Other prefix routing. The host sends datagrams directly to its preferred
identifiers are indicated with the Other-Identifier extension. router for all destinations which it cannot determine to be on the
local media. The router issues a redirect when another router would
be more appropriate or the destination is directly accessible on the
local media.
Extensions When most of the traffic is between nodes that are not on the same
local media, this is very efficient. When most of the traffic is
between hosts on the local media (client-server), the extra redirect
packets will be rare.
The Extensions field is variable in length and contains zero or 4.3. Host Discovery
more Extensions. These Extensions are described in a later
section.
9.2.1. End-System Advertisement When a host or router needs the location of a target host on the
local media, it sends a media multicast solicitation for the location
of the host, followed by a media multicast of the original data
packet. The target node issues an advertisement which indicates its
current reachability.
The End-System Advertisement contains the following values: When most of the traffic is between hosts on the local media
(client-server), the extra solicitation and advertisement packets
will be rare.
- In the Destination Address field of the SIP header: For periodic 5. Sending Datagrams
mobile end-system advertisements, the all-routers multicast. For
other end-system advertisements, the all-systems multicast. In
either case, the scope is set to local.
- In the Source Address field of the SIP header: For service The internetwork layer chooses the next hop for each datagram sent.
advertisements, the primary identifier associated with that If the destination is on the local media, the datagram is sent
system. For responses to solicitations, the identifier specified directly to the destination. Otherwise, it has to be sent to a
in the solicitation. router.
- In the Code field of the ICMP header: 1 for End-System 5.1. Local/Remote Decision
Advertisement.
- In the Lifetime field: the interface's configured To decide if the destination is on the local media, the following
AdvertisementLifetime. algorithm MUST be used:
- For each of that system's interface identifiers other than the (a) For a multicast destination, simply pass the datagram to the
primary identifier, the Other-Identifier extension, with the link layer for any indicated interface(s).
prefix size set to zero.
- For each service advertisement that is offered, the Service- (b) A list of routing-prefixes is maintained for each interface.
Information extension. This prefix MAY be configured, or learned from Router
Advertisements. The prefix size is the number of valid bits in
the prefix.
- For each intermediate-system advertisement that has been heard, (c) If an interface prefix exactly matches the destination prefix
the System-Heard extension. extracted by the same prefix size, then the destination is on
the corresponding local media, and the datagram is to be
transmitted directly to the destination.
- For interfaces which are not point-to-point links, the Media- (d) If there are no matches, and no Router Advertisements have been
Access extension. heard, then the destination is on the local media. The
datagram is multicast on all interfaces.
In the unlikely event that not all extensions fit in a single (e) If there are no matches, and one or more Router Advertisements
advertisement, as constrained by the MTU of the link, multiple have been heard, then the destination is accessible only
advertisements are sent, with each except the last containing as many through a router. Selection of a router is described in "SIPP
extensions as can fit. Router Discovery" [$].
9.2.2. Intermediate-System Advertisement The host MUST operate correctly in a minimal network environment.
For example, if the host insists on finding at least one router to
initialize, the host will be unable to operate on an isolated
network.
The Intermediate-System Advertisement contains the following values: 5.2. Media Address Determination
- In the Destination Address field of the SIP header: the all- When the media address for a destination is unknown, the following
systems multicast, with the scope set to local. procedure is used:
- In the Source Address field of the SIP header: the primary (a) For a multi-homed host, the datagram is duplicated on all
identifier of the system. The same identifier is used for all
interfaces. interfaces.
- In the Code field of the ICMP header: 2 for Intermediate-System (b) If an interface has no broadcast capability (a point-to-point
Advertisement. link), and the peer entity is unknown, the datagram is sent on
the interface.
- 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 interface's recently changed identifiers, the
Change-Identifier 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 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.
10. Extensions
Extensions allow variable amounts of information to be carried within
each Advertisement or Advertisement packet. Some extensions are
common to both packet types.
The end of the list of Extensions is indicated by the Payload Length
of the SIP packet.
A summary of the Extensions format is shown below. The fields are
transmitted from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The Type field is one octet and indicates the type of Extension.
Up-to-date values of the Extension Type field are specified in the
most recent "Assigned Numbers" RFC [2]. Current values are
assigned as follows:
1 Media-Access
2 Change-Identifier
3 Other-Identifier
4 System-Heard
5 Routing-Information
6 Service-Information
7 Transit-Information
8 Authentication
9 Security-Information
10 Redirected-Header
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.
10.1. Media-Access
A summary of the Media-Access extension format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Media Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1
Length
>= 3
Media Type
The Media Type field is two octets in length. The value of this
field is the same as the Hardware Type used in ARP. Up-to-date
values of the Hardware Type field are specified in the most recent
"Assigned Numbers" RFC [2].
[Should we use the ifType from MIB-II instead?]
MAC Address
The MAC Address field is variable in length, and contains the media
address which is used to access this system.
The MAC Address is always specified in Canonical order.
The Media-Access extension MUST be included in those messages sent from
an interface on a multi-access media.
It MUST NOT be included in a message sent from a point-to-point
interface, or in messages such as the Remote Redirect which pass through
intermediate systems.
10.2. Change-Identifier
A summary of the Change-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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Old Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ New Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
2
Length
22
Prefix Size
The Prefix Size field is six bits in length, and indicates the number
of bits in both Identifiers which define the prefix mask for the
link. The value ranges from 0 to 62.
End-Systems MUST have a Prefix Size of zero.
Old Identifier
The Old Identifier field is eight octets in length, and contains the
old identifier for this interface.
New Identifier
The New Identifier field is eight octets in length, and contains one
of the identifiers for this interface. 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.
10.3. 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
3
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 one of the identifiers 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.
10.4. System-Heard
A summary of the System-Heard extension format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Speed |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Remaining LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
4
Length
30
Designated Bit
The Designated Bit indicates that the System Identifier is the
Designated Router.
Backup Bit
The Backup Bit indicates that the System Identifier is the Backup
Designated Router.
Prefix Size
The Prefix Size field is six bits in length, and indicates the number
of bits in the System Identifier which define the prefix mask for the
link. The value ranges from 0 to 62.
If the System Identifier does not indicate a valid prefix, the value
is zero.
End-Systems MUST have a Prefix Size of zero.
MRU
The Maximum Receive Unit field is two octets in length, and indicates
the maximum size packet that the system will receive over the link.
Speed
The Speed field is one octet in length, and indicates the speed of
the link over which the advertisement or solicitation was heard.
Higher values indicate greater speed. The speed value is related to
int( 10 * ln( speed / 100 ) ) in bits per second.
After considerable trial and error, this formula was used because
it gave the best distribution for distinguishing medium speed
links, and fit reasonably well in the realm of currently
envisioned speeds. It has an upper limit of 11.87 Terabits per
second. (It also has a convenient button on the calculator.)
0 link is down
1 - 9 reserved
10 300 or less
24 1,200 96 1,544,000 T1
31 2,400 99 2,048,000 E1
38 4,800 106 4,000,000 Token Ring
42 7,200 110 6,312,000 T2
45 9,600 115 10,000,000 Ethernet
49 14,400 119 16,000,000 Token Ring
52 19,200
56 28,800 130 44,736,000 T3
59 38,400 142 155,520,000 STS-3,STM-1
63 57,600 202 622,080,000 STS-12,STM-4
64 64,000 216 2,488,320,000 STS-48,STM-16
71 128,000
73 153,600
78 256,000
System Identifier
The System Identifier field is eight octets in length, and contains
the primary identifier for the system, taken from the Source Address
field of the advertisement heard.
Sequence Number
The Sequence Number field is two octets in length, and contains the
last heard sequence number from the system.
Remaining LifeTime
The Remaining LifeTime field is two octets in length, and indicates
the seconds remaining before the entry is considered invalid.
Quality
The Quality field is four octets in length, and contains an
indication of the signal quality received from this system. Higher
values indicate greater quality.
Advertisement Count
The Advertisement Count field is four octets in length, and indicates
the number of advertisements that have been heard from the identified
system.
Error Count
The Error Count field is four octets in length, and indicates the
number of errors which have been detected on the link with the
identified system.
This extension is included in every I-Am-Here.
10.5. 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
5
Length
14
Preference
The Preference field is one octet in length, and indicates the
preference level for use of this system to forward packets to the
Interface Identifier. Higher values indicate greater preference.
Designated Bit
The Designated Bit indicates that the system is the Designated
Router.
Backup Bit
The Backup Bit indicates that the system 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.
MRU
The Maximum Receive Unit field is two octets in length, and indicates
the maximum size packet that the system will receive over the link.
Zone
The Zone field is one octet in length, and indicates the zone for the
link. A value of zero indicates that no zone has been assigned.
Priority
The Priority field is one octet in length, and indicates the priority
for election to Designated Backup. A value of zero indicates that
the system is not eligible.
Interface Identifier
The Interface Identifier field is eight octets in length, and
contains one of the identifiers for this interface.
This extension is sent only by Intermediate-Systems.
When more than one of these extensions is present, the Designated and
Backup bits, MRU, Zone and Priority fields MUST be the same in each
copy.
10.6. Service-Information
A summary of the Service-Information extension format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Remaining LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
6
Length
>= 14
Service
The Service field is two octets in length. The value of this field
is usually the same as the well-known port number. Up-to-date values
of the Service field are specified in the most recent "Assigned
Numbers" RFC [2].
Sequence Number
The Sequence Number field is two octets in length, and contains the
last heard sequence number from the system.
Remaining LifeTime
The Remaining LifeTime field is two octets in length, and indicates
the seconds remaining before the entry is considered invalid.
System Identifier
The System Identifier field is eight octets in length, and contains
the primary identifier for this system.
Data
The Data field is variable in length, and contains information
specific to the service. For example, it could contain a string with
the description of the service.
The format of the Data field is entirely service dependent, and is
always treated as a binary value.
10.7. Transit-Information
A summary of the Transit-Information extension format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7
Length
6 (c) If an interface has no broadcast capability (an X.25 or Frame-
Relay link), the datagram is duplicated on each virtual circuit
for which there is no known peer entity, as if they were each a
separate point-to-point interface on a multi-homed host.
QoS (d) If an interface has no multicast capability, the datagram is
sent as a link-layer broadcast. The SIPP Destination is
unchanged.
The Quality of Service field is one octet in length, and indicates a (e) For an interface with multicast capability, the datagram is
service for which transit will be accepted. sent as a link-layer multicast. The multicast address used is
the exclusive-or of every octet of the SIPP Destination, added
to the selected-systems multicast. The SIPP Destination is
unchanged.
Metric (f) Immediately following the datagram, when there is no entry in
the route cache, a Where-Are-You solicitation is sent,
utilizing the same SIPP Destination as the datagram.
The Metric field is four octets in length, and indicates the (g) When there is an entry in the route cache, for an unknown media
preference level for use of this network link to forward packets of address, no further solicitations are sent until the cache
the indicated Quality of Service. Lower values indicate greater entry expires.
preference.
This extension is included in the Intermediate-System I-Am-Here to On receipt of a unicast datagram from a broadcast or multicast media
indicate that it will accept transit traffic. If this extension is not address, the datagram is silently discarded if the SIPP Destination
included, other intermediate-systems will treat the link as a stub does not match any SIPP identifying-address of the node.
network.
10.8. Authentication On receipt of a Where-Are-You solicitation, the target node sends a
multicast I-Am-Here advertisement to the all-systems multicast.
A summary of the Authentication extension format is shown below. The On receipt of a multicast I-Am-Here advertisement, all nodes which
fields are transmitted from left to right. have a route cache entry for the SIPP Source update the cache entry
with the current LifeTime and media address.
0 1 2 3 5.3. Route Cache
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To efficiently route a series of datagrams to the same destination,
the source host MUST keep a "route cache" of mappings to
destinations. A host uses the following basic algorithm on this
cache to route a datagram:
8 (a) If the cache contains information for a particular destination,
the interface and media address are used to send the datagram.
Length This entry might point directly to the destination, or to a
router which handles the destination.
22 (b) If the cache contains no information for a particular
destination, a determination is made whether the destination is
on the local media.
Data (c) When the destination is determined to be accessible through a
router, the cache entry for the router is used to send the
datagram. The router cache entry might be duplicated, or a
system of pointers could be used. In any case, the cache entry
for the destination MUST have the same LifeTime as the cache
entry for the router.
The Data field is variable in length, and contains information (d) When the destination is determined to be on the local media,
specific to the authentication method, the media address is solicited. A new cache entry is made,
with a limited LifeTime, to inhibit sending of repeated
solicitations.
This extension is included in any I-Am-Here. Each route cache entry needs to include the following items.
10.9. Security-Information (1) LifeTime
(2) Next-hop interface (for a multi-homed host)
(3) Next-hop media address
(4) Destination SIPP identifying-address
(5) Destination prefix size
(6) Source SIPP identifying-address (for a multi-homed host)
(7) Flow number
A summary of the Security-Information extension format is shown below. Field (4) MAY be the full SIPP identifying-address of the
The fields are transmitted from left to right. destination, or only the destination network number. This is
determined by the prefix size in (5).
0 1 2 3 Field (7) SHOULD be included.
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 DISCUSSION:
Each route cache entry defines the endpoints of an internetwork
path. Although the connecting path may change dynamically in an
arbitrary way, the transmission characteristics of the path tend
to remain approximately constant over a time period longer than a
single typical host-host transport connection. Therefore, a route
cache entry is a natural place to cache data on the properties of
the path.
9 Examples of such properties might be the maximum unfragmented
datagram size, or the average round-trip delay measured by a
transport protocol. This data will generally be both gathered and
used by a higher layer protocol (that is, by TCP, or by an
application using UDP). Experiments are currently in progress on
caching path properties in this manner.
Length There is no consensus on whether the route cache should be keyed
on destination host addresses alone, or allow both host and
network addresses. Those who favor the use of only host addresses
argue that:
22 (1) Redirect messages will generally result in entries keyed on
destination host addresses. The simplest and most general
scheme would be to use host addresses always.
Compartments (2) The IP layer may not always know the prefix size for a
network address in a complex subnetted environment.
The Compartments field is sixteen octets in length. (3) The use of only host addresses allows the destination
address to be used as a pure 64-bit number, which may allow
the Internet architecture to be more easily extended in the
future without any change to the hosts.
This extension is included in the Intermediate-System I-Am-Here to The opposing view is that allowing a mixture of destination hosts
indicate that it will accept transit traffic for the designated security and networks in the route cache:
compartments.
10.10. Redirected-Header (1) Saves memory space.
A summary of the Redirected-Header extension format is shown below. The (2) Leads to a simpler data structure, easily combining the
fields are transmitted from left to right. cache with the tables of default and static routes.
0 1 2 3 (3) Provides a more useful place to cache path properties.
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIP Header ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type IMPLEMENTATION:
The cache needs to be large enough to include entries for the maximum
number of destination hosts that may be in use at one time.
10 A route cache entry may also include control information used to
choose an entry for replacement. This might take the form of a
"recently used" bit, a use count, or a last-used timestamp, for
example. It is recommended that it include the time of last
modification of the entry, for diagnostic purposes.
Length An implementation may wish to reduce the overhead of scanning the
route cache for every datagram to be transmitted. This may be
accomplished with a hash table to speed the lookup, or by giving a
connection-oriented transport protocol a "hint" or temporary handle
on the appropriate cache entry, to be passed to the IP layer with
each subsequent datagram.
22 Although we have described the route cache, the lists of default
routers, and a table of static routes as conceptually distinct, in
practice they may be combined into a single "routing table" data
structure.
SIP Header 5.4. Configuration
The SIP Header field is 48 octets in length. Default routers and preference levels MUST NOT be configured
manually. Instead, "SIPP Router Discovery" [$] MUST be used.
This extension is included in the Local or Remote Redirect to verifiy The routing-prefix(es) for an interface SHOULD NOT be configured
the traffic that is being redirected. manually. When a node is multi-homed, the node discovery multicast
MUST be sent on all interfaces which have not discovered the presence
of a router.
Security Considerations Security Considerations
References References
[1] [1]
[2] [2]
Acknowledgments Acknowledgments
The document was initially composed of quotations from the RFC-1122
Host Requirements, and selections of text contributed by Fred Baker
(ACC), Dino Farinacci (Cisco), Christian Huitema (INRIA), Frank
Kastenholz (FTP Software), Tony Li (Cisco), Dave Piscitello
(Bellcore), and Garrett Wollman (UVM?).
Chair's Address Chair's Address
The working group can be contacted via the current chairs: The working group can be contacted via the current chairs:
Stephen Deering Paul Francis
3333 Coyote Hill Road 445 South St. 2L-281
Palo Alto, CA 94304 Morristown, NJ 07960
415-812-4839 201-829-4484
Deering@PARC.Xerox.com francis@thumper.bellcore.com
Robert M Hinden
2550 Garcia Avenue
Mountain View, CA 94043-1100
415-336-2082
hinden@Eng.Sun.com
Author's Address Author's Address
Questions about this memo can also be directed to: Questions about this memo can also be directed to:
William Allen Simpson William Allen Simpson
Daydreamer Daydreamer
Computer Systems Consulting Services Computer Systems Consulting Services
P O Box 6205 1384 Fontaine
East Lansing, MI 48826-6205 Madison Heights, Michigan 48071
EMail: Bill.Simpson@um.cc.umich.edu Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
Table of Contents Table of Contents
1. Terminology ........................................... 1 1. Goals ................................................. 1
2. Criteria .............................................. 2 2. Criteria .............................................. 2
3. Design Overview ....................................... 8 3. Historic Methods ...................................... 7
3.1 System Identification ........................... 9
3.2 Multicast Support ............................... 10
4. Intermediate-System Discovery ......................... 11
4.1 Solicitations ................................... 11
4.1.1 Constants ....................................... 12
4.1.2 Implementation .................................. 12
4.1.3 Receipt ......................................... 13
4.2 Advertisements .................................. 13
4.2.1 Constants ....................................... 15
4.2.2 Configuration ................................... 15
4.2.3 Implementation .................................. 17
4.2.4 Receipt ......................................... 20
4.3 Processing Advertisements ....................... 20
4.3.1 Configuration ................................... 20
4.3.2 Implementation .................................. 21
5. End-System Discovery .................................. 23
5.1 Solicitations ................................... 23
5.1.1 Implementation .................................. 24
5.1.2 Receipt ......................................... 24
5.2 Advertisements .................................. 24
5.2.1 Implementation .................................. 25
6. Service Discovery ..................................... 26
6.1 Solicitations ................................... 27
6.1.1 Implementation .................................. 27
6.2 Advertisements .................................. 28
6.2.1 Implementation .................................. 28
7. Self Discovery ........................................ 29
7.1 End-Systems ..................................... 29
7.1.1 Zone Determination .............................. 29
7.1.2 Initialization .................................. 29
7.1.3 Identifier Determination ........................ 30
7.1.4 Prefix Determination ............................ 30
7.1.5 Changing Identifiers ............................ 30
7.2 Intermediate-Systems ............................ 30
8. Next-Hop Determination ................................ 31
8.1 Examples of Use ................................. 32
9. Additional ICMP Packets ............................... 34 4. Solution Overview ..................................... 9
9.1 Where-Are-You ................................... 35 4.1 Packets ......................................... 9
9.1.1 End-System Solicitation ......................... 37 4.1.1 Solicitations ................................... 9
9.1.2 Intermediate-System Solicitation ................ 38 4.1.2 Advertisements .................................. 9
9.2 I-Am-Here ....................................... 39 4.1.3 LifeTime ........................................ 9
9.2.1 End-System Advertisement ........................ 41 4.1.4 Extensions ...................................... 10
9.2.2 Intermediate-System Advertisement ............... 42 4.2 Router Discovery ................................ 10
4.3 Host Discovery .................................. 10
10. Extensions ............................................ 43 5. Sending Datagrams ..................................... 12
10.1 Media-Access .................................... 45 5.1 Local/Remote Decision ........................... 12
10.2 Change-Identifier ............................... 46 5.2 Media Address Determination ..................... 12
10.3 Other-Identifier ................................ 48 5.3 Route Cache ..................................... 13
10.4 System-Heard .................................... 50 5.4 Configuration ................................... 16
10.5 Routing-Information ............................. 53
10.6 Service-Information ............................. 55
10.7 Transit-Information ............................. 57
10.8 Authentication .................................. 58
10.9 Security-Information ............................ 59
10.10 Redirected-Header ............................... 60
SECURITY CONSIDERATIONS ...................................... 61 SECURITY CONSIDERATIONS ...................................... 17
REFERENCES ................................................... 61 REFERENCES ................................................... 17
ACKNOWLEDGEMENTS ............................................. 61 ACKNOWLEDGEMENTS ............................................. 17
CHAIR'S ADDRESS .............................................. 61 CHAIR'S ADDRESS .............................................. 18
AUTHOR'S ADDRESS ............................................. 61 AUTHOR'S ADDRESS ............................................. 18
 End of changes. 166 change blocks. 
2168 lines changed or deleted 486 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/