draft-ietf-sip-discovery-01.txt   draft-ietf-sip-discovery-02.txt 
skipping to change at page 1, line 70 skipping to change at page 1, line 70
multicast unless otherwise qualified, means the use of either IP multicast unless otherwise qualified, means the use of either IP
multicast [4] or IP broadcast [6] service. multicast [4] or IP broadcast [6] service.
link a communication facility or medium over which systems link a communication facility or medium over which systems
can communicate at the link layer; that is, the protocol can communicate at the link layer; that is, the protocol
layer immediately below IP. The term "physical network" layer immediately below IP. The term "physical network"
has sometimes been used (imprecisely) for this. has sometimes been used (imprecisely) for this.
Examples of links are LANs (possibly bridged to other Examples of links are LANs (possibly bridged to other
LANs), wide-area store-and-forward networks, satellite LANs), wide-area store-and-forward networks, satellite
channels, and point-to-point links. channels, and point-to-point circuits.
multicast link a link over which IP multicast or IP broadcast service multicast link a link over which IP multicast or IP broadcast service
is supported. This includes broadcast media such as is supported. This includes broadcast media such as
LANs and satellite channels, single point-to-point LANs and satellite channels, single point-to-point
links, and some store-and-forward networks such as SMDS circuits, and some store-and-forward networks such as
networks [8]. SMDS networks [8].
interface a system's attachment point to a link. It is possible interface a system's attachment point to a link. It is possible
(though unusual) for a system to have more than one (though unusual) for a system to have more than one
interface to the same link. Interfaces are uniquely interface to the same link.
identified by an identifier; a single interface may have
more than one such identifier.
multicast interface multicast interface
an interface to a multicast link; that is, an interface an interface to a multicast link; that is, an interface
to a link over which IP multicast or IP broadcast to a link over which IP multicast or IP broadcast
service is supported. service is supported.
identifier uniquely identifies each interface; a single interface
may have more than one such identifier.
primary identifier
uniquely identifies each system; only one such
identifier is used, to simplify discovery of neighbors.
subnet either a single link of a subnetted IP network [7] or subnet either a single link of a subnetted IP network [7] or
a single non-subnetted link. a single non-subnetted link.
prefix the part of an identifier which may be used for routing prefix the part of an identifier which may be used for routing
to a particular subnet, defined by logically ANDing with to a particular subnet, defined by logically ANDing with
its assigned subnet mask. More than one subnet prefix its assigned subnet mask. More than one subnet prefix
may identify the same link. may identify the same link.
neighbor having an IP address belonging to the same subnet. zone the part of a special identifier which indicates a
unique subnet within an administrative domain.
neighbor having an identifier belonging to the same subnet.
2. Criteria 2. Criteria
Historically, the methods for discovery of the next hop evolved Historically, the methods for discovery of the next-hop evolved
separately from those for location of neighbors and auto- separately from those for location of neighbors and auto-
configuration of systems. With the advent of SIP, the old techniques configuration of systems. With the advent of SIP, the old techniques
must be re-implemented, usually due to larger field sizes. must be re-implemented, usually due to larger field sizes.
Unfortunately, older implementations frequently did not take proper Unfortunately, older implementations frequently did not take proper
care in differentiating existing variable field lengths, version care in differentiating existing variable field lengths, version
numbers, and new types of messages. Therefore, the techniques used numbers, and new types of messages. Therefore, the techniques used
for SIP are required to be distinguishable from previous versions. for SIP are required to be distinguishable from previous versions.
None of the current protocols are readily extensible. While some None of the current protocols are readily extensible. While some
have the ability to change in simple terms, such as larger addresses, have the ability to change in simple terms, such as larger addresses,
skipping to change at page 3, line 19 skipping to change at page 3, line 30
recipient. recipient.
Reduced net traffic Reduced net traffic
Currently, there are separate packets sent for media address Currently, there are separate packets sent for media address
resolution, router discovery, and the Hello protocols for the resolution, router discovery, and the Hello protocols for the
various routing algorithms. Since much of the same information is various routing algorithms. Since much of the same information is
contained in each of these packets, it would be helpful to combine contained in each of these packets, it would be helpful to combine
the functions in a single packet where possible. the functions in a single packet where possible.
Also, the most common next hop resolution protocol, the Address Also, the most common next-hop resolution protocol, the Address
Resolution Protocol (ARP), requires an additional two packets at Resolution Protocol (ARP), requires an additional two packets at
the beginning of each connection. The Request is sent, a Reply is 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. received, and then the first datagram can be sent to the next-hop.
This causes a significant amount of traffic, and considerable This causes a significant amount of traffic, and considerable
latency in establishing a connection. latency in establishing a connection.
The ISO solution (ES-IS) eliminates some of these problems. Each Several alternative methods were proposed:
end-system and intermediate-system sends Hellos on a periodic
basis. Each system must remember all of the media addresses for
the other systems on the local network. This does eliminate the
latency of ARP, at the expense of many additional packets sent on
a regular basis, and a large amount of storage overhead in each
system.
Two alternative solutions were proposed: 1) 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.
1) Sending the first packet destined for an unknown system to 2) The first packet destined for an unknown system may be sent
the all-systems multicast, or to a media multicast based on to the all-systems multicast, or to a media multicast based
a hash function of the destination. The appropriate system on a hash function of the destination. The appropriate
accepts the packet, and sends a redirect indicating the system accepts the packet, and sends a redirect indicating
appropriate media address to be used for future packets. the appropriate media address to be used for future packets.
This reduces the traffic from 3 to 2 packets at the This reduces the traffic from 3 to 2 packets at the
beginning of a connection, and eliminates the latency, as beginning of a connection, and eliminates the latency, as
the discovery packet sent is also the data packet. However, the discovery packet sent is also the data packet. The
the destination identifer in the network header will be destination identifer in the network header will be unicast,
unicast, while the media address will be multicast, possibly while the media address will be multicast. Intermediate-
resulting in some confusion. Intermediate-systems would systems would require extra intelligence to recognize those
require extra intelligence to recognize those packets packets destined beyond the local link, while multi-homed
destined beyond the local link, while multi-homed end- end-systems require that capability already. Also, this
systems require that capability already. Also, this method method is not extensible to include other information useful
is not extensible to include other information useful in in mobile environments.
mobile environments.
2) Using advertisements for the (fewer) intermediate systems, 3) Using advertisements for the (fewer) intermediate systems,
and an ARP-like protocol for those end-system connections and an ARP-like protocol for those end-system connections
that are on the local media. For those packets which are that are on the local media. For those packets which are
clearly destined off the local media, the packet can be sent clearly destined off the local media, the packet can be sent
directly to the appropriate intermediate system. When most directly to the appropriate intermediate system. When most
of the traffic is between systems that are not on the same of the traffic is between systems that are not on the same
local media, this is very efficient. When most of the local media, this is very efficient. When most of the
traffic is between end-systems on the local media (client- traffic is between end-systems on the local media (client-
server), the extra discovery packets will be rare. The server), the extra discovery packets will be rare.
intelligence is split between the intermediate and end
systems.
The latter is the solution that is detailed here. However, the The solution that is detailed here is a combination of the best
former is not mutually exclusive, and could be used in parallel. 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 Also, by carrying media addresses within the advertisements and
redirect packets, a further ARP-like query/response can be avoided redirect packets, a further ARP-like query/response can be avoided
entirely. entirely.
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 systems often have significantly
reduced processing power and memory. reduced processing power and memory.
An end-system should only retain information for those end-systems An end-system need only retain information for those end-systems
with which it is directly communicating. To improve efficiency with which it is directly communicating.
and reduce net traffic, this design requires the storage of
information about each intermediate-system which is heard. This design requires sufficient storage in an end-system for
information about at least one intermediate-system. In addition,
storage is required for at least one location of each service
(such as a domain name server) which is used.
An intermediate-system may require more processing power and An intermediate-system may require more processing power and
memory, since participation in routing protocols requires the memory. Participation in routing protocols requires the knowledge
knowledge of every neighboring intermediate-system. It is not of every neighboring intermediate-system.
expected that in the general case the location of every end-system
will be maintained.
Autoconfiguration When subnet prefix-routing is in use, it is not necessary for an
intermediate-system to determine the location of an end-system
until traffic for the end-system arrives. If prefix-routing is
not used, particularly in radio and mobile environments, the
location of each reachable end-system must be continuously
retained.
Auto-configuration
It would be highly desirable that the connection procedures for a
configuring a new system are reduced to the minimal set of "plug
it in, turn on the power, and run".
- Each system, or more precisely each interface, should be
assigned an identifier, within the number space assigned to the
local subnet.
- Each system should be assigned a name within the local domain.
The name, and the associated identifiers, should be registered
in the local domain name server.
- The system should discover the external routes provided by the
intermediate-systems attached to the local subnet, so that it
can exchange packets with remote systems.
- The system should discover the location of servers that it
needs for configuration, loading, dumping, printing, and other
services.
In evaluating previous experience with autoconfiguration
procedures, the following constraints were determined:
1) It is not possible to embed an IEEE-802 component within
every SIP identifier, since the remaining prefix would be
too small for global routing. Using the 48-bit IEEE-802
number to identify one system within a local network that is
not designed to accomodate more than a few hundred systems
is considerable overkill. It may be worthwhile to use the
address during initial configuration.
2) Random identifier assignments are to be avoided. They do
not scale well to large networks, are difficult to track and
manage, and lead to administrative confusion. Relying on
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
human users. In particular, renumbering, and assignment of
alias identifiers as a mobile system moves should be
automatic.
4) End-system 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 system name which
is memorable and comfortable to them. The name should be
automatically registered, and changes to the associated
identifers should be maintained automatically.
This design handles initial self-identification and propagation of This design handles initial self-identification and propagation of
changes in identification. Other aspects of configuration are changes in identification. Other aspects of configuration, such
specified elsewhere, such as loading the operating system and as loading the operating system and environment, and additional
environment, and additional facilities and servers for facilities and servers for registration, are specified elsewhere.
registration.
Mobility support Mobility support
This is sometimes considered a subset of the above, as related to This is sometimes considered a subset of the above, as related to
dynamically changing addresses while moving. Other systems must dynamically changing addresses while moving. Other systems must
be notified of the changes. be notified of the changes.
In addition, the "hidden transmitter" problem is considered (you In addition, the "hidden transmitter" problem is considered (you
can hear another system, it can't hear you, but there is a path to can hear another system, it can't hear you, but there is a path to
a third system which it can hear, completing the circuit). This a third system which it can hear, completing the circuit). This
is not well supported in any of the past protocols. is not well supported in any of the past protocols.
Although basic support for mobility is provided, descriptions of Although basic support for mobility is provided, descriptions of
additional facilities and servers are specified elsewhere. additional facilities and servers are specified elsewhere.
Black hole detection Black hole detection
In determining whether the next hop system is still available, In determining whether the next-hop system is still available,
there is a basic tradeoff between frequent queries and resources there is a basic tradeoff between frequent queries and resources
used. This design trades fewer queries against more information used. This design trades fewer queries against more information
within each query and response. within 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 system when a resource is critical, or when the system is actively
moving. moving.
Media independence Media independence
There are many instances where system discovery is accomplished There are many instances where system 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 Large Public Data Networks. This design places
the system discovery above the network layer, where it enjoys the system discovery above the network layer, where it enjoys
greater independence. It also encompasses media level redirects greater independence. It also encompasses media level redirects
between logical subnets on the same physical media. 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 system, and requires
all such media addresses to be in canonical form, all 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 current protocols. is not well supported in any of the past protocols.
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 system capabilities. Dumb
end-systems may simply send packets to a default intermediate- end-systems may simply send packets to a default intermediate-
system, and be redirected to the correct next hop by more capable system, and be redirected to the correct next-hop by more capable
intermediate-systems. Smarter end-systems learn sufficient intermediate-systems. Smarter end-systems learn sufficient
information to make informed choices. information to make informed choices.
Simplicity Simplicity
All of the above desires, and they want to keep it simple, too. 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 SIP system, and reduces the number of systems
which recognize and respond to each type. The extensions are which recognize and respond to each type. The extensions are
designed with 32 and 64 bit boundaries for efficient processing. designed with 32 and 64 bit boundaries for efficient processing.
3. Design and Use 3. Design Overview
This proposal describes two packets, not much different from those This proposal describes two packets, not much different from those
already deployed. These familiar forms are re-packaged to join already deployed. These familiar forms are re-packaged to join
common functions into the same packet to reduce traffic, and are common functions into the same packet to reduce traffic, and are
designed to be more extensible in the future. designed to be more extensible in the future.
In order to foster media independence, the packets are part of ICMP, In order to foster media independence, the packets are part of ICMP,
which allows the protocols to be used over broadcast, multicast, which allows the protocols to be used over broadcast, multicast,
partial-mesh, and point-to-point media. This is similar to the partial-mesh, and point-to-point media. This is similar to the
positioning of ES-IS. positioning of ES-IS.
skipping to change at page 8, line 7 skipping to change at page 9, line 7
the paths between intermediate-systems, and between intermediate- the paths between intermediate-systems, and between intermediate-
systems and end-systems. This is designed to be used by most systems and end-systems. This is designed to be used by most
commonly deployed routing protocols. This also solves the "hidden commonly deployed routing protocols. This also solves the "hidden
transmitter" problem, when used together with the well-known link- transmitter" problem, when used together with the well-known link-
state class of routing protocols. state class of routing protocols.
Several methods of routing are supported. Several methods of routing are supported.
3.1. System Identification 3.1. System Identification
Zone numbers may be combined with the last hop media address to make Zone
a locally significant identifier. This is useful for initial
configuration and local communication within an administrative 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 domain. These identifiers may be routed in a similar manner to
prefix-routed subnets. 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 Prefix-routed subnet identifiers are supported for addressing
globally connected networks in the metro/provider addressing model. globally connected networks in the metropolitan and/or provider
The prefix part of each identifier may be used to locate the subnet addressing models.
link for the final hop. This is the routing technique with which we
have greatest familiarity.
End-Point identifiers, or any other globally unique identifier, may End-Point Identifiers
be used with future routing techniques. A mobile system may be
treated as having an end-point identifier when it appears in a End-Point identifiers, or any other globally unique identifier,
prefix-routed subnet, since it will not have the same prefix as other may be used with future routing techniques. An End-Point
systems in the subnet. 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 Facilities are provided for exchange of redirects and translation
between the various forms of identifiers. between the various forms of identifiers.
3.2. Intermediate System Advertisements 3.2. Multicast Support
Each intermediate-system peridodically sends the I-Am-Here message to Every SIP system MUST join the all-systems multicast group on all
advertise its forwarding capability. End-systems discover the interfaces on which the system supports multicast.
location of their neighboring intermediate-systems simply by
listening for the advertisements. This eliminates the need for
manual configuration of intermediate-system addresses and is
independent of any specific routing protocol.
The advertisements include such important information as the media Every SIP intermediate-system MUST also join the all-routers
address to access the system, other subnets directly accessible multicast group.
through the intermediate-system, and neighboring intermediate-systems
heard. 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 Identifiers
Each intermediate-system advertisement includes one or more Each intermediate-system advertisement includes one or more
identifier fields. These indicate the identifiers which are identifier fields. These indicate the identifiers which are
presently in use for each interface of the intermediate-system. 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 Prefix Size
Each advertised identifier includes a prefix size field. The Each advertised identifier includes a prefix size field. The
value ranges from 0 to 62, and indicates the number of bits in 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 Identifier which define the prefix mask for the link. A value of
zero indicates an end-point identifier. When the value is not zero indicates an end-point identifier. When the value is not
zero, the identifier may be used to discern zone or prefix-routed zero, the identifier may be used to discern prefix-routed subnet
subnet mapping. mapping.
If all advertised prefix values are zero, then subnet prefix-
routing is not in use on that link.
Preference Preference
Each advertised identifier includes a preference field. This is Each advertised identifier includes a preference field. This is
used to choose a default intermediate-system for the first-hop used to choose a default intermediate-system for the first-hop
when no other information is available (for a particular when the end-system has not yet been redirected or configured to
destination, the end-system has not yet been redirected or use a specific intermediate-system for a particular destination.
configured to use a specific intermediate-system). The end-system The end-system is expected to choose from those intermediate-
is expected to choose from those intermediate-systems that have systems that have the highest preference level for the best
the highest preference level for the best prefix-routing match. prefix-routing match. When there is no match, or prefix-routing
When there is no match, or prefix-routing is not in use, the is not in use, the preference value is used alone.
preference value is used alone.
A network administrator can configure intermediate-system A network administrator can configure intermediate-system
preference levels to encourage or discourage the use of particular preference levels to encourage or discourage the use of particular
intermediate-systems as the default first hop. The use of intermediate-systems as the default first-hop. The use of
separate preferences per prefix allows the choice of different separate preferences per prefix allows the choice of different
intermediate-systems for each prefix, when there are multiple intermediate-systems for each prefix, when there are multiple
prefixes in use for the same link. This may be useful where prefixes in use for the same link. This may be useful where
multiple organizations share resources. multiple organizations share resources.
[I am not sure this works when there are multiple identifiers per [I am not sure how this works when there are multiple identifiers
end-system interface.] per end-system interface.]
The preference value is not the same as the "metric" used in many The preference value is not the same as the "metric" used in many
routing protocols. It is used only by end-systems in determining routing protocols. It is used only by end-systems in determining
the default first-hop, rather than by intermediate-systems in the default first-hop, rather than by intermediate-systems in
choosing a link for transit traffic. The values are not additive. choosing a link for transit traffic. The values are not additive.
Therefore, the range of values is smaller, and a higher value Therefore, the range of values is smaller, and a higher value
indicates a higher preference. indicates a higher preference.
3.2.1. Constants 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_ADVERTISEMENTS 3 transmissions
MAX_INITIAL_ADVERT_INTERVAL 16 seconds MAX_INITIAL_ADVERT_INTERVAL 16 seconds
MAX_RESPONSE_DELAY 2 seconds MAX_RESPONSE_DELAY 2 seconds
3.2.2. Configuration 4.2.2. Configuration
An intermediate-system MUST allow the following variables to be An intermediate-system MUST allow the following variables to be
configured by system management. Default values are specified which configured by system management. Default values are specified which
make it unnecessary to re-configure these variables in most cases. make it unnecessary to re-configure these variables in most cases.
For each interface: For each interface:
MaxAdvertisementInterval MaxAdvertisementInterval
The maximum time (in seconds) allowed between sending The maximum time (in seconds) allowed between sending
skipping to change at page 12, line 20 skipping to change at page 17, line 28
more redirect traffic (on links from which the most frequently chosen more redirect traffic (on links from which the most frequently chosen
destinations are best reached via intermediate-systems other than the destinations are best reached via intermediate-systems other than the
one with the best default route). Also, since the routing algorithms one with the best default route). Also, since the routing algorithms
learn of neighboring intermediate-systems from the advertisements, learn of neighboring intermediate-systems from the advertisements,
and the default routes are learned from the routing algorithms, the and the default routes are learned from the routing algorithms, the
calculated preference may be unstable from time to time. This calculated preference may be unstable from time to time. This
document makes no recommendation concerning this issue, and document makes no recommendation concerning this issue, and
implementors are free to try such a strategy, as long as they also implementors are free to try such a strategy, as long as they also
support static configuration of preference levels as specified above. support static configuration of preference levels as specified above.
3.2.3. Implementation 4.2.3. Implementation
Every SIP intermediate-system MUST implement Intermediate-System
Advertisements.
The intermediate-system joins the all-routers multicast group on all The intermediate-system advertisement is sent to the all-systems
interfaces on which the intermediate-system supports multicast. multicast, with the scope set to local.
The term "advertising interface" refers to any functioning and The term "advertising interface" refers to any functioning and
enabled interface that has at least one identifier whose configured enabled interface that has at least one identifier whose configured
Advertise flag is TRUE. Advertise flag is TRUE.
From each advertising interface, the system transmits periodic From each advertising interface, the system MUST transmit periodic
advertisements containing the following values: I-Am-Here messages.
- In the Destination Address field of the SIP header: the all-
systems multicast, with the scope set to local.
- In the Source Address field of the SIP header: the primary
identifier of the system. The same identifier is used for all
interfaces.
- In the Code field of the ICMP header: 2 for Intermediate-System
Advertisement.
- In the Lifetime field: the interface's configured
AdvertisementLifetime.
- For each of that interface's identifiers whose Advertise flags are
TRUE, the Routing-Information extension.
- For each of that system's other interface's identifiers which have
not already been included through prefix subsumption, the Other-
Identifier extension.
- For each service advertisement that is offered, or has been
learned from another advertisement, the Service-Information
extension.
- For each intermediate-system advertisement that has been heard,
the System-Heard extension.
- For interfaces which are not point-to-point links, the Media-
Access extension.
In the unlikely event that not all extensions fit in a single
advertisement, as constrained by the MTU of the link, multiple
advertisements are sent, with each except the last containing as many
extensions as can fit.
CONTROVERSIAL: CONTROVERSIAL:
When an intermediate-system discovers that it is receiving its own When an intermediate-system discovers that it is receiving its own
advertisements, that is an indication that it has more than one advertisements, that is an indication that it has more than one
interface on same link. The system MUST choose only one interface on same link. The system MUST choose only one
advertising interface for each link. Identifiers associated with advertising interface for each link. Identifiers associated with
the remaining interfaces on the same link are indicated with the the remaining interfaces on the same link are indicated with the
Other-Identifier extension. Redirect is used to move specific Other-Identifier extension. Redirect is used to move specific
traffic to the alternate interfaces. traffic to the alternate interfaces.
skipping to change at page 13, line 50 skipping to change at page 18, line 19
subsequent transmissions is randomized to reduce the probability of subsequent transmissions is randomized to reduce the probability of
synchronization with the advertisements from other intermediate- synchronization with the advertisements from other intermediate-
systems on the same link. This is done by maintaining a separate systems on the same link. This is done by maintaining a separate
transmission interval timer for each advertising interface. Each transmission interval timer for each advertising interface. Each
time an advertisement is sent from an interface, that interface's time an advertisement is sent from an interface, that interface's
timer is reset to a uniformly-distributed random value between the timer is reset to a uniformly-distributed random value between the
configured MinAdvertisementInterval and MaxAdvertisementInterval. configured MinAdvertisementInterval and MaxAdvertisementInterval.
Expiration of the timer causes the next advertisement to be sent, and Expiration of the timer causes the next advertisement to be sent, and
a new random value to be chosen. a new random value to be chosen.
It is recommended that intermediate-systems include some unique It is recommended that intermediate-systems include some unique value
value, such as one of their interface or link-layer addresses, in the (such as one of their interface or link-layer addresses) in the seed
seed used to initialize their pseudo-random number generators. used to initialize their pseudo-random number generators. Although
the randomization range is configured in units of seconds, the actual
Although the randomization range is configured in units of seconds, randomly-chosen values should not be in units of whole seconds, but
the actual randomly-chosen values should not be in units of whole rather in units of the highest available timer resolution.
seconds, but rather in units of the highest available timer
resolution.
For the first few advertisements sent from an interface (up to For the first few advertisements sent from an interface (up to
MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is
greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
MAX_INITIAL_ADVERT_INTERVAL instead. Using this smaller interval for MAX_INITIAL_ADVERT_INTERVAL instead. Using this smaller interval for
the initial advertisements increases the likelihood of an the initial advertisements increases the likelihood of an
intermediate-system being discovered quickly when it first becomes intermediate-system being discovered quickly when it first becomes
available, in the presence of possible packet loss. available, in the presence of possible packet loss.
In addition to the periodic unsolicited advertisements, an
intermediate-system sends advertisements in response to valid
solicitations received on any of its advertising interfaces. If the
solicitation does not contain any Intermediate-Systems-Heard
extension, and the time since the previous advertisement is greater
than MAX_INITIAL_ADVERT_INTERVAL, the intermediate-system MUST
multicast an advertisement from that interface. The interface's
interval timer is reset to a new random value, as with unsolicited
advertisements. The response MUST be delayed for a small random
interval not greater than MAX_RESPONSE_DELAY, in order to prevent
synchronization with other responding intermediate-systems, and to
allow multiple closely-spaced solicitations to be answered with a
single advertisement.
An interface may become an advertising interface at times other than An interface may become an advertising interface at times other than
system startup, as a result of recovery from an interface failure or system startup, as a result of recovery from an interface failure or
through actions of system management such as: through actions of system management such as:
- enabling the interface, if it had been administratively disabled - enabling the interface, if it had been administratively disabled
and it has one or more identifiers whose Advertise flag is TRUE, and it has one or more identifiers whose Advertise flag is TRUE,
- enabling SIP forwarding capability (changing the system from an - enabling SIP forwarding capability (changing the system from an
end-system to an intermediate-system), when the interface has one end-system to an intermediate-system), when the interface has one
or more identifiers whose Advertise flag is TRUE, or more identifiers whose Advertise flag is TRUE,
skipping to change at page 15, line 7 skipping to change at page 19, line 10
whose Advertise flag was TRUE. whose Advertise flag was TRUE.
In such cases, the intermediate-system must commence transmission of In such cases, the intermediate-system must commence transmission of
periodic advertisements on the new advertising interface, limiting periodic advertisements on the new advertising interface, limiting
the first few advertisements to intervals no greater than the first few advertisements to intervals no greater than
MAX_INITIAL_ADVERT_INTERVAL. In the case of an end-system becoming MAX_INITIAL_ADVERT_INTERVAL. In the case of an end-system becoming
an intermediate-system, the system must also join the all-routers an intermediate-system, the system must also join the all-routers
multicast group on all interfaces on which the intermediate-system multicast group on all interfaces on which the intermediate-system
supports multicast (whether or not they are advertising interfaces). supports multicast (whether or not they are advertising interfaces).
An interface may also cease to be an advertising interface, through An interface MAY also cease to be an advertising interface, through
actions of system management such as: actions of system management such as:
- shutting down the system, - shutting down the system,
- administratively disabling the interface, - administratively disabling the interface,
- disabling SIP forwarding capability (changing the system from an - disabling SIP forwarding capability (changing the system from an
intermediate-system to an end-system), intermediate-system to an end-system),
- setting the Advertise flags of all of the interface's identifiers - setting the Advertise flags of all of the interface's identifiers
skipping to change at page 16, line 5 skipping to change at page 19, line 38
which the intermediate-system supports multicast (whether or not they which the intermediate-system supports multicast (whether or not they
had been advertising interfaces). had been advertising interfaces).
When the Advertise flag of one or more of an interface's identifiers When the Advertise flag of one or more of an interface's identifiers
are set to FALSE by system management, but there remain other are set to FALSE by system management, but there remain other
identifiers on that interface whose Advertise flags are TRUE, the identifiers on that interface whose Advertise flags are TRUE, the
intermediate-system SHOULD send a single multicast advertisement intermediate-system SHOULD send a single multicast advertisement
containing only those identifiers whose Advertise flags were set to containing only those identifiers whose Advertise flags were set to
FALSE, with a Lifetime field of zero. FALSE, with a Lifetime field of zero.
3.3. Intermediate System Discovery 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.
Before an end-system can send datagrams beyond its directly attached Whenever these response advertisements are sent, the advertisement
link, it must discover the location of at least one operational MUST be delayed for a small random interval not greater than
intermediate-system on that link. This is accomplished through the MAX_RESPONSE_DELAY, in order to prevent synchronization with other
intermediate-system advertisement messages described above. 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.
The advertisement messages do not constitute a routing protocol. 4.2.4. Receipt
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 All systems MUST silently discard any received Intermediate-System
make a good choice of first hop. This may be important for choosing Advertisement messages that do not satisfy the following validity
among intermediate-systems which are participating in a security checks:
group or policy-based routing.
It should be understood that preference levels learned from - ICMP Checksum is correct.
intermediate-system advertisements do not affect any system's cached
route entries. For example, if a system has been redirected to use a
particular intermediate-system to reach a specific destination, it
continues to use that intermediate-system for that destination, even
if it discovers another intermediate-system identifier with a higher
preference level. Preference levels influence the choice of
intermediate-system only for a destination for which there is no
cached or configured route, or whose cached route points to an
intermediate-system that is subsequently determined to be
unreachable.
3.3.1. Configuration - 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, The Host Requirements -- Communication Layers [1], Section 3.3.1.6,
specifies that each end-system must support a configurable list of specifies that each end-system must support a configurable list of
default intermediate-system identifiers. The purpose of the default intermediate-system identifiers. The purpose of the
intermediate-system discovery messages is to eliminate the need to intermediate-system discovery messages is to eliminate the need to
configure that list. On links for which intermediate-system configure that list. On links for which intermediate-system
discovery is administratively disabled, it MAY continue to be discovery is administratively disabled, it MAY continue to be
necessary to configure the default intermediate-system list in each necessary to configure the default intermediate-system list in each
end-system. end-system.
skipping to change at page 17, line 21 skipping to change at page 21, line 21
PreferenceLevel PreferenceLevel
The preferability of the RouterAddress as a default intermediate- The preferability of the RouterAddress as a default intermediate-
system choice, relative to other intermediate-system interfaces system choice, relative to other intermediate-system interfaces
serving the same prefix on the same link. The Host Requirements serving the same prefix on the same link. The Host Requirements
RFC does not specify how this value is to be encoded. The values RFC does not specify how this value is to be encoded. The values
used here are defined above. used here are defined above.
Default: 255 Default: 255
3.3.2. Implementation 4.3.2. Implementation
To process an Intermediate-System Advertisement, an end-system scans To process an Intermediate-System Advertisement, an end-system scans
the list of Routing-Information extensions contained in it. For each the list of Routing-Information extensions contained in it. For each
identifier, the end-system does the following: identifier, the end-system does the following:
- If the prefix size is not zero, the identifier and prefix size are - If the prefix size is not zero, the identifier and prefix size are
compared against any identifiers associated with the interface on compared against any identifiers associated with the interface on
which the message was received. If there is a match, the which the message was received. If there is a match, the
interface prefix size is set to the advertised prefix size. interface prefix size is set to the advertised prefix size.
skipping to change at page 19, line 5 skipping to change at page 23, line 5
choice of default intermediate-system is discovered to be down, the choice of default intermediate-system is discovered to be down, the
end-system may immediately choose another default intermediate-system end-system may immediately choose another default intermediate-system
without having to wait for the next advertisement to arrive. without having to wait for the next advertisement to arrive.
Any intermediate-system identifier advertised with a preference level Any intermediate-system identifier advertised with a preference level
of zero is not to be used by the end-system as default intermediate- of zero is not to be used by the end-system as default intermediate-
system identifier. Such an identifier may be omitted from the system identifier. Such an identifier may be omitted from the
default intermediate-system list, unless its timer is being use as a default intermediate-system list, unless its timer is being use as a
"black-hole" detection mechanism. "black-hole" detection mechanism.
3.4. Initial Intermediate-System Solicitations 5. End-System Discovery
When any end-system starts up, which is not otherwise sending Within a directly attached link, each system must be able to locate
periodic I-Am-Here advertisements, it MUST instead send the Where- end-systems with which it desires to communicate. This is
Are-You solicitation to begin discovery of intermediate-systems. accomplished using the Where-Are-You and I-Am-Here messages described
below. This is independent of any specific media.
If (and only if) no advertisements from neighboring intermediate- When an intermediate-system needs the location of an end-system, it
systems are forthcoming, the end-system may retransmit the Where- sends the Where-Are-You solicitation. The target end-system responds
Are-You a small number of times, but then must desist from sending with the I-Am-Here advertisement.
more solicitations.
Any systems that subsequently start up, or that were not discovered When no intermediate-system advertisements have been heard, an end-
because of packet loss or temporary link partitioning, are eventually system sends the Where-Are-You solicitation itself. The target end-
discovered by reception of their periodic (unsolicited) system responds with the I-Am-Here advertisement as usual.
advertisements. Links that suffer high packet loss rates or frequent
partitioning are accommodated by increasing the rate of
advertisements, rather than increasing the number of solicitations
that systems are permitted to send.
3.4.1. Constants 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.
MAX_SOLICITATIONS 3 transmissions 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.
MAX_SOLICITATION_DELAY 1 second 5.1. Solicitations
SOLICITATION_INTERVAL 3 seconds Every SIP system MUST implement End-System Solicitation for discovery
of local end-systems.
3.4.2. Implementation 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.
Every SIP system MUST implement the System Solicitation. 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.
Every SIP system joins the all-systems multicast group on all 5.1.1. Implementation
interfaces on which the system supports multicast.
An end-system is permitted (but not required) to transmit up to The end-system solicitation is sent to the all-systems multicast.
MAX_SOLICITATIONS solicitation messages from any of its interfaces
after any of the following events:
- The interface is initialized at system startup time. The end-system solicitations use the same configuration constants as
intermediate-system solicitations.
- The interface is reinitialized after a temporary interface failure Unlike intermediate-system solicitations, end-system solicitations
or after being temporarily disabled by system management. are sent only when a particular end-system location is needed, rather
than on startup.
- The system has its SIP forwarding capability turned off by system End-system solicitations are sent using the same periodicity
management. calculations as intermediate-system solicitations.
- The system has its SIP service capability turned off by system Upon receiving a valid advertisement from any intermediate-system, an
management. end-system MUST NOT send any end-system solicitations.
From each such interface, the system transmits solicitations 5.1.2. Receipt
containing the following values:
- In the Destination Address field of the SIP header: the all- An intermediate-system MUST silently discard any received End-System
routers multicast, with the scope set to local. Solicitation messages.
- In the Source Address field of the SIP header: the primary An end-system MUST silently discard any received End-System
identifier associated with that interface. It MAY contain zero if Solicitation messages that do not satisfy the following validity
the system has not yet determined an identifier for the interface. checks:
- In the Code field of the ICMP header: 2 for Intermediate-System - ICMP Checksum is correct.
Solicitation.
- For each of that system's interface identifiers other than the - ICMP length (derived from the payload length) is 16 or more
primary identifier, the Other-Identifier extension, with the octets.
prefix size set to zero.
- For each intermediate-system advertisement that has been heard, - Source Address is either 0 or the identifier of a neighbor (an
the System-Heard extension. 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).
- For interfaces which are not point-to-point links, the Media- 5.2. Advertisements
Access extension.
If a system chooses to send a solicitation after one of the above Every SIP end-system MUST implement End-System Advertisements.
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 Usually, end-system advertisements are sent in response to end-system
of their interface or link-layer identifiers, in the seed used to solicitations. In addition, mobile end-system advertisements and
initialize their pseudo-random number generators. Although the service end-system advertisements (described below) are sent on a
randomization range is specified in units of seconds, the actual periodic basis.
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 The end-system advertisements include such important information as
permitted if no advertisement is received, should be sent at the media address to access the system, and neighboring
intervals of SOLICITATION_INTERVAL seconds, without further intermediate-systems heard.
randomization.
Upon receiving a valid advertisement from any intermediate-system 5.2.1. Implementation
subsequent to one of the above events, the system MUST NOT send any
solicitation on that interface (even if none have been sent yet)
until the next time one of the above events occurs. The
intermediate-system advertisements (described above) contain a
summary of all of the available information for the link.
3.5. Service Advertisments 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 Each system offering one of the special configuration services
detailed below, whether an end-system or intermediate-system, detailed below, whether an end-system or intermediate-system,
periodically sends the I-Am-Here message to advertise its service includes that service availability in every advertisement that it
availablility. All systems discover the location of these services sends. All systems discover the location of these services simply by
simply by listening for the advertisements. This eliminates the need listening for the advertisements. This eliminates the need for
for manual configuration, periodic probes, and special handling of manual configuration, periodic probes, and special handling of
certain packet types by intermediate-systems. certain packet types by intermediate-systems.
The learned service information is included in any neighboring The learned service information is included in any neighboring
intermediate-system advertisements. In this fashion, the intermediate-system advertisements. In this fashion, the
intermediate-system advertisements provide a summary of all available intermediate-system advertisements provide a summary of all available
network services, and pass information beyond the link where the network services, and pass information beyond the link where the
advertisement originated. This results in a reduction of network advertisement originated. This results in a reduction of network
traffic when compared to the broadcast or multicast of service traffic when compared to the broadcast or multicast of service
discovery requests/replies over a wide area. discovery requests/replies over a wide area.
The service advertisements use similar configuration constants and The initial services listed here are primarily concerned with
variables as intermediate-system advertisements. configuration. The locations of other facilities may be learned from
these basic servers.
3.5.1. Implementation Domain Name Service
Services offered by intermediate-systems are included in the Before a system can communicate with another system, it must learn
intermediate-system advertisements described above. that system's identifiers and location. The Domain Name System
(DNS) is usually used for this purpose.
From each advertising interface, an end-system transmits periodic In the past, this was accomplished by reading a list of servers
advertisements containing the following values: 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 the Destination Address field of the SIP header: the all- In practice, only systems which are users or stub resolvers of the
systems multicast, with the scope set to local. 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.
- In the Source Address field of the SIP header: the primary Self-Configuration Service
identifier associated with that interface.
- In the Code field of the ICMP header: 1 for End-System Before a system can communicate with another system, it must learn
Advertisement. its own identity. The Bootstrap Protocol (BOOTP) is frequently
used for this purpose.
- In the Lifetime field: the interface's configured In the past, this was accomplished by ad hoc passing of BOOTP
AdvertisementLifetime. 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.
- For each of that system's interface identifiers other than the 6.1. Solicitations
primary identifier, the Other-Identifier extension, with the
prefix size set to zero.
- For each service advertisement that is offered, the Service- Every SIP end-system SHOULD implement End-System Solicitation for
Information extension. discovery of local services.
- For each intermediate-system advertisement that has been heard, When a system is ready to use a particular service, it examines its
the System-Heard extension. 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.
- For interfaces which are not point-to-point links, the Media- If (and only if) no advertisements from desired services are
Access extension. forthcoming, the system MAY retransmit the Where-Are-You a small
number of times, but then MUST desist from sending more
solicitations.
In the unlikely event that not all extensions fit in a single 6.1.1. Implementation
advertisement, as constrained by the MTU of the link, multiple
advertisements are sent, with each except the last containing as many
extensions as can fit.
End-system service advertisements are sent using the same periodicity The service solicitation is sent to the special multicast for each
as intermediate-system advertisements. 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 Advertising interfaces are established and terminated in the same
manner as intermediate-system advertisements. manner as intermediate-system advertisements.
When any system ceases to offer an advertised service, the system When any system ceases to offer an advertised service, the system
SHOULD transmit a final multicast advertisement on the interface, SHOULD transmit a final multicast advertisement on the interface,
identical to its previous transmission, but with a Lifetime field of identical to its previous transmission, but with a Lifetime field of
zero. zero.
3.6. Service Discovery 7. Self Discovery
Because the service advertisements learned from a link are
promulgated by the intermediate-system advertisements, no further
effort is required to solicit service advertisements.
[what to do when there are no IS Adverts] 7.1. End-Systems
The services advertised are limited primarily to configuration. The At startup, each SIP end-system solicits the advertisements of
locations of other facilities may be learned from these basic intermediate-systems, as described in Intermediate-System Discovery
servers. 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.
3.6.1. Domain Name Service 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.
Before a system can communicate with another system, it must learn 7.1.1. Zone Determination
that system's identifiers and location. The Domain Name System (DNS)
is usually used for this purpose.
Therefore, the location of at least one DNS server must be learned. Until an intermediate-system is discovered, an end-system assumes a
This is accomplished through the service advertisement messages zone number of zero. When combined with any IEEE-802 number found in
described above. the machine, or other identifier negotiated at the link level, this
yields a local identifier which is unique to the system.
In the past, this was accomplished by reading a list of servers from When an intermediate-system is discovered, the advertisements are
a (possibly remote) configuration file at startup time. Some systems examined for zone information, as described in Intermediate-System
discovered servers by sending periodic probes to a broadcast or Discovery above. If all advertised zone values are zero, then zone
multicast address. Both of these methods have serious drawbacks. routing is not available beyond that link. If more than one zone
Configuration files must be maintained manually (a significant number is discovered for the same interface, only the highest zone
administrative burden when ther are large numbers of systems), and number is used.
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 When there is more than one interface on a multi-homed end-system,
DNS will use the DNS server advertisements. Full-Service resolvers each interface MUST answer to all of the local identifers generated.
MUST continue to be manually configured to ensure a heirarchy of
believability within the network.
3.6.2. Self-Configuration Service 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.
Before a system can communicate with another system, it must learn 7.1.2. Initialization
its own identity. The Bootstrap Protocol (BOOTP) is frequently used
for this purpose.
Therefore, the location of at least one BOOTP server must be learned. Once a system has becomed locally addressable, it can engage in
This is accomplished through the service advertisement messages exchanges with local servers. Some of these local servers could be a
described above. 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.
In the past, this was accomplished by ad hoc passing of BOOTP When the registration service is unable to find a match for the
requests by routers. This method has several serious drawbacks. system, the system SHOULD request the operator to provide a name for
Presence of the feature cannot be relied upon. It is not of much use the system. The registration service would be responsible for
for mobile, roving or portable systems. ensuring uniqueness, and assigning appropriate identifiers for the
name.
3.7. Prefix Discovery Further specification of such services is beyond the scope of this
document.
which define the prefix mask for the link. The value ranges from 0 7.1.3. Identifier Determination
to 62.
The value of 63 cannot be used, since at least 2 bits are reserved Once the Domain Name has been determined for a system, the Domain
for a valid host portion of the identifier. 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 IS, when configured, or address assigned. The prefixes are Each DNS identifier has a Time-To-Live associated with it. When any
assigned by hand. Can ask DNS or BOOTP. identifier expires, another request SHOULD be made to the DNS for a
list of identifiers.
Unlike previous practice, an end-system prefix size MUST NOT be When there is more than one interface on a multi-homed end-system,
preconfigured. Instead, the prefix size is dynamically learned from each interface MUST answer to all of the identifers learned.
matching against the intermediate-system advertisements, as described
in Intermediate-System Discovery above.
more than one prefix on same link. 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.
3.8. Zone Discovery 7.1.4. Prefix Determination
A Zone is defined to be a collection of systems which may be The prefix size is dynamically learned from matching interface
aggregated as the same next hop. A Zone may be as small as a single identifiers against the intermediate-system advertisements, as
link segment, or as large as an entire administrative domain. described in Intermediate-System Discovery above.
3.8.1. Abstraction Algorithm 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.
The zones are learned from the intermediate-system advertisements, 7.1.5. Changing Identifiers
which contain the necessary prefix information.
3.9. Next Hop Determination 7.2. Intermediate-Systems
Within a directly attached link, each system must be able to locate The zones and prefixes are assigned by hand.
other systems with which it desires to communicate. This is
accomplished using the Where-Are-You and I-Am-Here messages described
below. This is independent of any specific media.
When the system has heard one or more intermediate-system 8. Next-Hop Determination
advertisements, it first uses these advertisements to determine if
the desired system is directly accessible on the local link.
When an end-system has not heard any intermediate-system When an end-system has not heard any intermediate-system
advertisements, it is assumed that all end-systems are only advertisements, it is assumed that all end-systems are only
accessible on the local link. accessible on the local link.
3.9.1. Configuration multi-homed
3.9.2. Implementation preferred router
3.9.3. Examples of Use smart selection
local redirect
remote redirect
8.1. Examples of Use
Simple case -- J to K on the same fully-connected link. Simple case -- J to K on the same fully-connected link.
J sends the Where-Are-You (which contains its own media address) J sends the Where-Are-You (which contains its own media address)
to all-systems. K sends the I-Am-Here (which contains its own to all-systems. K sends the I-Am-Here (which contains its own
media address) directly to J. At this point, they both know media address) directly to all-systems. At this point, they
that they can talk directly to each other, without regard to both know that they can talk directly to each other, without
subnet. regard to subnet.
Routed case -- J to K not on the same fully-connected link. Routed case -- J to K not on the same fully-connected link.
If no resource reservation or policy routing is desired, J If no resource reservation or policy routing is desired, J
simply sends its packets directly to the "preferred" router that simply sends its packets directly to the "preferred" router that
it has learned from the Advertisements. If there is a better it has learned from the Advertisements. If there is a better
router for the first hop, that router sends the I-Am-Here router for the first-hop, that router sends the I-Am-Here
redirect to J, but never-the-less forwards the packet. redirect to J, but never-the-less forwards the packet.
In the presence of RR or PR, J sends the Where-Are-You to the In the presence of RR or PR, J sends a Where-Are-You to the
"preferred" router that it has learned from the Advertisements. "preferred" router that it has learned from the Advertisements.
That router always returns the I-Am-Here (even if the correct That router always returns an I-Am-Here redirect (even if the
hop is itself), which contains the requested RR or PR status correct hop is itself), which contains the requested RR or PR
information. J then sends its packets to the first hop router status information. J then sends its packets to the first-hop
as determined from the I-Am-Here. router as determined from the I-Am-Here.
General case -- J to K over disconnected partial mesh (radio/framerelay). General case -- J to K over disconnected partial mesh (radio/framerelay).
J sends the Where-Are-You (which contains its own media address, J periodically sends the I-Am-Here (which contains its own media
and the addresses of its "heard" routers) to the all-systems address, and the addresses of its "heard" routers) to the
address. The routers use such messages to construct a map of all-routers multicast. The routers use such messages to
the current state of the topology. The routers now know who J construct a map of the current state of the topology. The
hears, and who hears J. routers now know who J hears, and who hears J.
If the routing map doesn't contain a current whereabouts of K, If the routing map doesn't contain a current whereabouts of K,
the Destination Unreachable message is returned by the "best" the Destination Unreachable message is returned by the "best"
router on J's "heard" list. router on J's "heard" list.
If the routing map contains the current whereabouts of K, the If the routing map contains the current whereabouts of K, the
"best" router on K's "heard" list sends a copy of the "best" router on K's "heard" list sends a Where-Are-You to K,
Where-Are-You to K, with a substitute list of routers which can with a list of routers which can hear K. The list is ordered by
hear K. The list is ordered by the intersection of those the intersection of those routers which can also hear J,
routers which can also hear J, minimizing the number of hops. minimizing the number of hops.
Of course, K may have heard J's Where-Are-You directly, in which
case it adds its own address to the front of the list of routers.
When K hears the J Where-Are-You, it sends the I-Am-Here to the 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 all-systems address. The "best" router on J's "heard" list
sends a copy of the I-Am-Here to J, with a substitute list of sends an I-Am-Here redirect to J, with a substitute list of
routers which can hear J. The list is ordered by the routers which can hear J. The list is ordered by the
intersection of those routers which can also hear K. 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 At this point, the routing fabric knows which routers are heard
by J and K, and which routers can hear J and K. J and K know by J and K, and which routers can hear J and K. J and K know
whether they can hear each other directly. If not, they know whether they can hear each other directly. If not, they know
the "best" next hop router (which may not be the same in both the "best" next-hop router (which may not be the same in both
directions). directions).
Unlike the fully-connected scenarios, this scheme requires that Unlike the fully-connected scenarios, this scheme requires that
the I-Am-Here is sent from time to time to keep the map updated. the I-Am-Here is sent from time to time to keep the map updated.
However, only routers need store the information. However, only routers need store the information.
4. Additional ICMP Packets 9. Additional ICMP Packets
The Packet format and basic facilities are already defined for ICMP The Packet format and basic facilities are already defined for ICMP
[3], as modified for SIP [1]. [3], as modified for SIP [1].
Up-to-date values of the ICMP Type field are specified in the most Up-to-date values of the ICMP Type field are specified in the most
recent "Assigned Numbers" RFC [2]. This document concerns the recent "Assigned Numbers" RFC [2]. This document concerns the
following values: following values:
<TBD> Where-Are-You <TBD> Where-Are-You
<TBD> I-Am-Here <TBD> I-Am-Here
4.1. Where-Are-You 9.1. Where-Are-You
A summary of the Where-Are-You message format is shown below. The A summary of the Where-Are-You message format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
skipping to change at page 31, line 45 skipping to change at page 35, line 45
1 End-System Solicitation 1 End-System Solicitation
2 Intermediate-System Solicitation 2 Intermediate-System Solicitation
Checksum Checksum
The ICMP Checksum. The ICMP Checksum.
System Identifier System Identifier
The System Identifier field is eight octets in length, and The System Identifier field is eight octets in length, and
contains the identifier of the system which is sought. For an contains an identifier of the system which is sought. When the
Intermediate-System Solicitation, the field is unused and remains identifer of the system is unknown, the field is zero filled.
zero filled.
Extensions Extensions
The Extensions field is variable in length and contains zero or The Extensions field is variable in length and contains zero or
more Extensions. These Extensions are described in a later more Extensions. These Extensions are described in a later
section. section.
4.1.1. Description The contents of the Reserved field are ignored. Future backward-
compatible changes to the protocol may specify the contents of the
Reserved field or of additional octets at the end of the message.
The Where-Are-You message is used to determine the presence and 9.1.1. End-System Solicitation
availability of the next hop. This message is also used for resource
reservation and policy route determination.
4.2. I-Am-Here The End-System Solicitation contains the following values:
- In the Destination Address field of the SIP header: For service
solicitations, the special multicast group associated with the
service. For other solicitations, the all-systems multicast. In
either case, the scope is set to local.
- In the Source Address field of the SIP header: any identifier
associated with the sending interface. It MAY contain zero if the
system has not yet determined an identifier for the interface.
- In the Code field of the ICMP header: 1 for End-System
Solicitation.
- 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
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 Intermediate-System Solicitation contains the following values:
- In the Destination Address field of the SIP header: the all-
routers multicast, with the scope set to local.
- In the Source Address field of the SIP header: any identifier
associated with the sending interface. It MAY contain zero if the
system has not yet determined an identifier for the interface.
- In the Code field of the ICMP header: 2 for Intermediate-System
Solicitation.
- For each of that system's interface identifiers other than the
primary identifier, the Other-Identifier extension, with the
prefix size set to zero.
- For each intermediate-system advertisement that has been heard,
the System-Heard extension.
- For interfaces which are not point-to-point links, the Media-
Access extension.
In the unlikely event that not all extensions fit in a single
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
A summary of the I-Am-Here message format is shown below. The fields A summary of the I-Am-Here message format is shown below. The fields
are transmitted from left to right. are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | LifeTime | | Sequence Number | LifeTime |
skipping to change at page 33, line 47 skipping to change at page 39, line 47
3 Local Redirect 3 Local Redirect
4 Remote Redirect 4 Remote Redirect
Checksum Checksum
The ICMP Checksum. The ICMP Checksum.
Sequence Number Sequence Number
The Sequence Number field is two octets in length, and contains The Sequence Number field is two octets in length, and contains
the number of I-Am-Heres sent. This number MUST include this the number of I-Am-Here messsages sent since the system was
advertisement. initialized. This number MUST include this advertisement.
LifeTime LifeTime
The LifeTime field is two octets in length, and indicates the The LifeTime field is two octets in length, and indicates the
seconds remaining before the entry is considered invalid. seconds remaining before the entry is considered invalid.
System Identifier System Identifier
The System Identifier field is eight octets in length, and The System Identifier field is eight octets in length, and
contains the primary identifier for this system. Other contains the primary identifier for this system. Other
identifiers are indicated with the Other-Identifier extension. identifiers are indicated with the Other-Identifier extension.
Extensions Extensions
The Extensions field is variable in length and contains zero or The Extensions field is variable in length and contains zero or
more Extensions. These Extensions are described in a later more Extensions. These Extensions are described in a later
section. section.
4.2.1. Description 9.2.1. End-System Advertisement
The I-Am-Here message is used to announce the presence of an The End-System Advertisement contains the following values:
intermediate or end system, to indicate changes in the topology, and
to support system mobility.
It contains all of the information now in the old Router - In the Destination Address field of the SIP header: For periodic
Advertisement, ES Hello, IS Hello, OSPF Hello and RSPF Hello. 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.
Intermediate Systems - In the Source Address field of the SIP header: For service
advertisements, the primary identifier associated with that
system. For responses to solicitations, the identifier specified
in the solicitation.
The message is sent by each intermediate-system periodically to - In the Code field of the ICMP header: 1 for End-System
the all-systems multicast. The information is stored by all Advertisement.
systems.
The message is also sent in response to a Where-Are-You. - In the Lifetime field: the interface's configured
AdvertisementLifetime.
End-Systems - For each of that system's interface identifiers other than the
primary identifier, the Other-Identifier extension, with the
prefix size set to zero.
The message is sent in response to a Where-Are-You. The - For each service advertisement that is offered, the Service-
information is stored only by the affected systems. Information extension.
Local Redirect - For each intermediate-system advertisement that has been heard,
the System-Heard extension.
The message is sent in response to changes in the routing. The - For interfaces which are not point-to-point links, the Media-
information is stored only by the affected systems. Access extension.
Remote Redirect 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.
The message is sent to indicate movement of a system beyond the 9.2.2. Intermediate-System Advertisement
local zone. The information is stored only by the affected
systems.
5. Extensions The Intermediate-System Advertisement contains the following values:
- In the Destination Address field of the SIP header: the all-
systems multicast, with the scope set to local.
- In the Source Address field of the SIP header: the primary
identifier of the system. The same identifier is used for all
interfaces.
- In the Code field of the ICMP header: 2 for Intermediate-System
Advertisement.
- In the Lifetime field: the interface's configured
AdvertisementLifetime.
- For each of that interface's identifiers whose Advertise flags are
TRUE, the Routing-Information extension.
- For each of that 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 Extensions allow variable amounts of information to be carried within
each Advertisement or Solicitation packet. Some extensions are each Advertisement or Advertisement packet. Some extensions are
common to both packet types. common to both packet types.
The end of the list of Extensions is indicated by the Payload Length The end of the list of Extensions is indicated by the Payload Length
of the SIP packet. of the SIP packet.
A summary of the Extensions format is shown below. The fields are A summary of the Extensions format is shown below. The fields are
transmitted from left to right. transmitted from left to right.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
skipping to change at page 36, line 31 skipping to change at page 43, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
The Type field is one octet and indicates the type of Extension. The Type field is one octet and indicates the type of Extension.
Up-to-date values of the Extension Type field are specified in the Up-to-date values of the Extension Type field are specified in the
most recent "Assigned Numbers" RFC [2]. Current values are most recent "Assigned Numbers" RFC [2]. Current values are
assigned as follows: assigned as follows:
1 Media-Access 1 Media-Access
2 Other-Identifier 2 Change-Identifier
3 Routing-Information 3 Other-Identifier
4 System-Heard 4 System-Heard
5 Security-Information 5 Routing-Information
6 Service-Information 6 Service-Information
7 Transit-Information 7 Transit-Information
8 Authentication
9 Security-Information
10 Redirected-Header
Length Length
The Length field is one octet and indicates the length of the Data The Length field is one octet and indicates the length of the Data
field which has been used. field which has been used.
Each Extension ends on an octet boundary which is an integral Each Extension ends on an octet boundary which is an integral
multiple of four octets. Any unused portion of the Data field is multiple of four octets. Any unused portion of the Data field is
padded with zeros. padded with zeros.
skipping to change at page 37, line 4 skipping to change at page 44, line 9
field which has been used. field which has been used.
Each Extension ends on an octet boundary which is an integral Each Extension ends on an octet boundary which is an integral
multiple of four octets. Any unused portion of the Data field is multiple of four octets. Any unused portion of the Data field is
padded with zeros. padded with zeros.
length actual length actual
0 through 2 4 0 through 2 4
3 through 6 8 3 through 6 8
7 through 10 12 7 through 10 12
Data Data
The Data field is zero or more octets and contains the value or The Data field is zero or more octets and contains the value or
other information for this Extension. The format and length of other information for this Extension. The format and length of
the Data field is determined by the Type and Length fields. the Data field is determined by the Type and Length fields.
5.1. Media-Access 10.1. Media-Access
A summary of the Media-Access extension format is shown below. The A summary of the Media-Access extension format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Media Type | | Type | Length | Media Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address ... | MAC Address ...
skipping to change at page 39, line 5 skipping to change at page 46, line 5
The MAC Address is always specified in Canonical order. The MAC Address is always specified in Canonical order.
The Media-Access extension MUST be included in those messages sent from The Media-Access extension MUST be included in those messages sent from
an interface on a multi-access media. an interface on a multi-access media.
It MUST NOT be included in a message sent from a point-to-point It MUST NOT be included in a message sent from a point-to-point
interface, or in messages such as the Remote Redirect which pass through interface, or in messages such as the Remote Redirect which pass through
intermediate systems. intermediate systems.
5.2. Other-Identifier 10.2. Change-Identifier
A summary of the Other-Identifier extension format is shown below. The A summary of the Change-Identifier extension format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |Prefix Size| | Type | Length | |Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Interface Identifier + + Old Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ New Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
2 2
Length Length
14 22
Prefix Size Prefix Size
The Prefix Size field is six bits in length, and indicates the number 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 of bits in both Identifiers which define the prefix mask for the
the link. The value ranges from 0 to 62. 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. End-Systems MUST have a Prefix Size of zero.
Metric Old Identifier
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. The Old Identifier field is eight octets in length, and contains the
old identifier for this interface.
Interface Identifier New Identifier
The Interface Identifier field is eight octets in length, and The New Identifier field is eight octets in length, and contains one
contains an identifier for this system. This may be another of the identifiers for this interface. This may be another
identifier for the same interface that sent the message, or may identifier for the same interface that sent the message, or may
identify another interface on the same system which sent the message. identify another interface on the same system which sent the message.
Every identifier for every interface is listed in each I-Am-Here 10.3. Other-Identifier
message.
This supports multiple identifiers per interface, as well as multi-homed
systems.
When a number of interfaces, such as point-to-point interfaces, may be
aggregated with the same prefix, only one extension need be included.
This enables end-systems to determine the best next hop without sending
a Where-Are-You solicitation when the next hop is on another interface
attached to the same advertising system.
5.3. Routing-Information
A summary of the Routing-Information extension format is shown below. A summary of the Other-Identifier extension format is shown below. The
The fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Preference |D|B|Prefix Size| | Type | Length | |Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | Zone | Priority | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Interface Identifier + + Interface Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
3 3
Length Length
14 14
Preference
The Preference field is one octet in length, and indicates the
preference level for use of this system to forward packets to the
Interface Identifier. Higher values indicate greater preference.
Designated Bit
The Designated Bit indicates that the System Identifier is the
Designated Router.
Backup Bit
The Backup Bit indicates that the System Identifier is the Backup
Designated Router.
Prefix Size Prefix Size
The Prefix Size field is six bits in length, and indicates the number 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 of bits in the Interface Identifier which define the prefix mask for
the link. The value ranges from 0 to 62. the link. The value ranges from 0 to 62.
If the Interface Identifier does not indicate a valid prefix, the If the Interface Identifier does not indicate a valid prefix, the
value is zero. value is zero.
MRU End-Systems MUST have a Prefix Size of zero.
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 Metric
link. A value of zero indicates that no zone has been assigned.
Priority 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.
The Priority field is one octet in length, and indicates the priority End-Systems MUST set this field to zero.
for election to Designated Backup. A value of zero indicates that
the system is not eligible.
Interface Identifier Interface Identifier
The Interface Identifier field is eight octets in length, and The Interface Identifier field is eight octets in length, and
contains an identifier for this interface. 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.
This extension is sent only by Intermediate-Systems. Every identifier for every interface is listed in each I-Am-Here
message.
5.4. System-Heard 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 A summary of the System-Heard extension format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Speed |D|B|Prefix Size| | Type | Length | Speed |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | | | MRU | |
skipping to change at page 44, line 38 skipping to change at page 51, line 38
0 link is down 0 link is down
1 - 9 reserved 1 - 9 reserved
10 300 or less 10 300 or less
24 1,200 96 1,544,000 T1 24 1,200 96 1,544,000 T1
31 2,400 99 2,048,000 E1 31 2,400 99 2,048,000 E1
38 4,800 106 4,000,000 Token Ring 38 4,800 106 4,000,000 Token Ring
42 7,200 110 6,312,000 T2 42 7,200 110 6,312,000 T2
45 9,600 115 10,000,000 Ethernet 45 9,600 115 10,000,000 Ethernet
49 14,400 119 16,000,000 Token Ring 49 14,400 119 16,000,000 Token Ring
52 19,200 130 44,736,000 T3 52 19,200
56 28,800 56 28,800 130 44,736,000 T3
59 38,400 142 155,520,000 STS-3/STM-1 59 38,400 142 155,520,000 STS-3,STM-1
63 57,600 202 622,080,000 STS-12/STM-4 63 57,600 202 622,080,000 STS-12,STM-4
64 64,000 216 2,488,320,000 STS-48/STM-16 64 64,000 216 2,488,320,000 STS-48,STM-16
71 128,000 71 128,000
73 153,600 73 153,600
78 256,000 78 256,000
System Identifier System Identifier
The System Identifier field is eight octets in length, and contains The System Identifier field is eight octets in length, and contains
the primary identifier for the system. the primary identifier for the system, taken from the Source Address
field of the advertisement heard.
Sequence Number Sequence Number
The Sequence Number field is two octets in length, and contains the The Sequence Number field is two octets in length, and contains the
last heard sequence number from the system. last heard sequence number from the system.
Remaining LifeTime Remaining LifeTime
The Remaining LifeTime field is two octets in length, and indicates The Remaining LifeTime field is two octets in length, and indicates
the seconds remaining before the entry is considered invalid. the seconds remaining before the entry is considered invalid.
skipping to change at page 45, line 33 skipping to change at page 52, line 34
The Advertisement Count field is four octets in length, and indicates The Advertisement Count field is four octets in length, and indicates
the number of advertisements that have been heard from the identified the number of advertisements that have been heard from the identified
system. system.
Error Count Error Count
The Error Count field is four octets in length, and indicates the The Error Count field is four octets in length, and indicates the
number of errors which have been detected on the link with the number of errors which have been detected on the link with the
identified system. identified system.
The System Heard extension MUST be included in every I-Am-Here. This extension is included in every I-Am-Here.
5.5. Security-Information 10.5. Routing-Information
A summary of the Security-Information extension format is shown below. A summary of the Routing-Information extension format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | | Type | Length | Preference |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | MRU | Zone | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | + Interface Identifier +
| |
| Compartments |
| |
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
5 5
Length Length
22 14
Compartments Preference
The Compartments field is sixteen octets in length. 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.
This extension is included in the Intermediate-System I-Am-Here to Designated Bit
indicate that it will accept transit traffic for the designated security
compartments.
5.6. Service-Information 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. A summary of the Service-Information extension format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | | Type | Length | Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Sequence Number | Remaining LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ System Identifier + + System Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
6 6
Length Length
14 >= 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 System Identifier
The System Identifier field is eight octets in length, and contains The System Identifier field is eight octets in length, and contains
an identifier for this system. This may be another identifier for the primary identifier for this system.
the same interface that sent the message, or may identify another
interface on the same system which sent the message.
5.7. Transit-Information 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. A summary of the Transit-Information extension format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | QoS | | Type | Length | | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
skipping to change at page 48, line 35 skipping to change at page 57, line 35
QoS QoS
The Quality of Service field is one octet in length, and indicates a The Quality of Service field is one octet in length, and indicates a
service for which transit will be accepted. service for which transit will be accepted.
Metric Metric
The Metric field is four octets in length, and indicates the The Metric field is four octets in length, and indicates the
preference level for use of this network link to forward packets of preference level for use of this network link to forward packets of
the indicated service. Lower values indicate greater preference. the indicated Quality of Service. Lower values indicate greater
preference.
This extension is included in the Intermediate-System I-Am-Here to This extension is included in the Intermediate-System I-Am-Here to
indicate that it will accept transit traffic. If this extension is not indicate that it will accept transit traffic. If this extension is not
included, the system will treat the link as a stub network. included, other intermediate-systems will treat the link as a stub
network.
10.8. Authentication
A summary of the Authentication 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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Length
22
Data
The Data field is variable in length, and contains information
specific to the authentication method,
This extension is included in any I-Am-Here.
10.9. Security-Information
A summary of the Security-Information extension format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compartments ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9
Length
22
Compartments
The Compartments field is sixteen octets in length.
This extension is included in the Intermediate-System I-Am-Here to
indicate that it will accept transit traffic for the designated security
compartments.
10.10. Redirected-Header
A summary of the Redirected-Header 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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIP Header ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
10
Length
22
SIP Header
The SIP Header field is 48 octets in length.
This extension is included in the Local or Remote Redirect to verifiy
the traffic that is being redirected.
Security Considerations Security Considerations
References References
[1] [1]
[2] [2]
Acknowledgments Acknowledgments
skipping to change at line 1784 skipping to change at line 2345
P O Box 6205 P O Box 6205
East Lansing, MI 48826-6205 East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.edu EMail: Bill.Simpson@um.cc.umich.edu
Table of Contents Table of Contents
1. Terminology ........................................... 1 1. Terminology ........................................... 1
2. Criteria .............................................. 2 2. Criteria .............................................. 2
3. Design and Use ........................................ 7 3. Design Overview ....................................... 8
3.1 System Identification ........................... 8 3.1 System Identification ........................... 9
3.2 Intermediate System Advertisements .............. 9 3.2 Multicast Support ............................... 10
3.2.1 Constants ....................................... 10
3.2.2 Configuration ................................... 10
3.2.3 Implementation .................................. 12
3.3 Intermediate System Discovery ................... 16
3.3.1 Configuration ................................... 16
3.3.2 Implementation .................................. 17
3.4 Initial Intermediate-System Solicitations ....... 19
3.4.1 Constants ....................................... 19
3.4.2 Implementation .................................. 19
3.5 Service Advertisments ........................... 22
3.5.1 Implementation .................................. 22
3.6 Service Discovery ............................... 24
3.6.1 Domain Name Service ............................. 24
3.6.2 Self-Configuration Service ...................... 24
3.7 Prefix Discovery ................................ 26
3.8 Zone Discovery .................................. 26
3.8.1 Abstraction Algorithm ........................... 26
3.9 Next Hop Determination .......................... 27
3.9.1 Configuration ................................... 27
3.9.2 Implementation .................................. 27
3.9.3 Examples of Use ................................. 28
4. Additional ICMP Packets ............................... 30 4. Intermediate-System Discovery ......................... 11
4.1 Where-Are-You ................................... 31 4.1 Solicitations ................................... 11
4.1.1 Description ..................................... 32 4.1.1 Constants ....................................... 12
4.2 I-Am-Here ....................................... 33 4.1.2 Implementation .................................. 12
4.2.1 Description ..................................... 34 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. Extensions ............................................ 36 5. End-System Discovery .................................. 23
5.1 Media-Access .................................... 38 5.1 Solicitations ................................... 23
5.2 Other-Identifier ................................ 39 5.1.1 Implementation .................................. 24
5.3 Routing-Information ............................. 41 5.1.2 Receipt ......................................... 24
5.4 System-Heard .................................... 43 5.2 Advertisements .................................. 24
5.5 Security-Information ............................ 46 5.2.1 Implementation .................................. 25
5.6 Service-Information ............................. 47
5.7 Transit-Information ............................. 48
SECURITY CONSIDERATIONS ...................................... 49 6. Service Discovery ..................................... 26
REFERENCES ................................................... 49 6.1 Solicitations ................................... 27
6.1.1 Implementation .................................. 27
6.2 Advertisements .................................. 28
6.2.1 Implementation .................................. 28
ACKNOWLEDGEMENTS ............................................. 49 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
CHAIR'S ADDRESS .............................................. 49 8. Next-Hop Determination ................................ 31
8.1 Examples of Use ................................. 32
AUTHOR'S ADDRESS ............................................. 49 9. Additional ICMP Packets ............................... 34
9.1 Where-Are-You ................................... 35
9.1.1 End-System Solicitation ......................... 37
9.1.2 Intermediate-System Solicitation ................ 38
9.2 I-Am-Here ....................................... 39
9.2.1 End-System Advertisement ........................ 41
9.2.2 Intermediate-System Advertisement ............... 42
10. Extensions ............................................ 43
10.1 Media-Access .................................... 45
10.2 Change-Identifier ............................... 46
10.3 Other-Identifier ................................ 48
10.4 System-Heard .................................... 50
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
REFERENCES ................................................... 61
ACKNOWLEDGEMENTS ............................................. 61
CHAIR'S ADDRESS .............................................. 61
AUTHOR'S ADDRESS ............................................. 61
 End of changes. 209 change blocks. 
568 lines changed or deleted 1125 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/