As per Relevance of the word multicast, we have this rfc below:
Network Working Group S.
Request for Comments: 1112 Stanford
Obsoletes: RFCs 988, 1054 August 1989
Host Extensions for IP
1. STATUS OF THIS
This memo specifies the extensions required of a host
of the Internet Protocol (IP) to support multicasting. It is
recommended standard for IP multicasting in the Internet
Distribution of this memo is unlimited
2.
IP multicasting is the transmission of an IP datagram to a "
group", a set of zero or more hosts identified by a single
destination address. A multicast datagram is delivered to
members of its destination host group with the same "best-efforts
reliability as regular unicast IP datagrams, i.e., the datagram
not guaranteed to arrive intact at all members of the
group or in the same order relative to other datagrams
The membership of a host group is dynamic; that is, hosts may
and leave groups at any time. There is no restriction on
location or number of members in a host group. A host may be
member of more than one group at a time. A host need not be a
of a group to send datagrams to it
A host group may be permanent or transient. A permanent group has
well-known, administratively assigned IP address. It is the address
not the membership of the group, that is permanent; at any time
permanent group may have any number of members, even zero. Those
multicast addresses that are not reserved for permanent groups
available for dynamic assignment to transient groups which exist
as long as they have members
Internetwork forwarding of IP multicast datagrams is handled
"multicast routers" which may be co-resident with, or separate from
internet gateways. A host transmits an IP multicast datagram as
local network multicast which reaches all immediately-
members of the destination host group. If the datagram has an
time-to-live greater than 1, the multicast router(s) attached to
local network take responsibility for forwarding it towards all
networks that have members of the destination group. On those
member networks that are reachable within the IP time-to-live,
attached multicast router completes delivery by transmitting
Deering [Page 1]
RFC 1112 Host Extensions for IP Multicasting August 1989
datagram as a local multicast
This memo specifies the extensions required of a host
implementation to support IP multicasting, where a "host" is
internet host or gateway other than those acting as
routers. The algorithms and protocols used within and
multicast routers are transparent to hosts and will be specified
separate documents. This memo also does not specify how
network multicasting is accomplished for all types of network
although it does specify the required service interface to
arbitrary local network and gives an Ethernet specification as
example. Specifications for other types of network will be
subject of future memos
3. LEVELS OF
There are three levels of conformance to this specification
Level 0: no support for IP multicasting
There is, at this time, no requirement that all IP
support IP multicasting. Level 0 hosts will, in general,
unaffected by multicast activity. The only exception arises on
types of local network, where the presence of level 1 or 2 hosts
cause misdelivery of multicast IP datagrams to level 0 hosts.
datagrams can easily be identified by the presence of a class D
address in their destination address field; they should be
discarded by hosts that do not support IP multicasting. Class
addresses are described in section 4 of this memo
Level 1: support for sending but not receiving multicast
datagrams
Level 1 allows a host to partake of some multicast-based services
such as resource location or status reporting, but it does not
a host to join any host groups. An IP implementation may be
from level 0 to level 1 very easily and with little new code.
sections 4, 5, and 6 of this memo are applicable to level 1
implementations
Level 2: full support for IP multicasting
Level 2 allows a host to join and leave host groups, as well as
IP datagrams to host groups. It requires implementation of
Internet Group Management Protocol (IGMP) and extension of the IP
local network service interfaces within the host. All of
following sections of this memo are applicable to level 2
implementations
Deering [Page 2]
RFC 1112 Host Extensions for IP Multicasting August 1989
4. HOST GROUP
Host groups are identified by class D IP addresses, i.e., those
"1110" as their high-order four bits. Class E IP addresses, i.e.,
those with "1111" as their high-order four bits, are reserved
future addressing modes
In Internet standard "dotted decimal" notation, host group
range from 224.0.0.0 to 239.255.255.255. The address 224.0.0.0
guaranteed not to be assigned to any group, and 224.0.0.1 is
to the permanent group of all IP hosts (including gateways). This
used to address all multicast hosts on the directly
network. There is no multicast address (or any other IP address)
all hosts on the total Internet. The addresses of other well-known
permanent groups are to be published in "Assigned Numbers".
Appendix II contains some background discussion of several
related to host group addresses
Deering [Page 3]
RFC 1112 Host Extensions for IP Multicasting August 1989
5. MODEL OF A HOST IP
The multicast extensions to a host IP implementation are specified
terms of the layered model illustrated below. In this model,
and (for level 2 hosts) IGMP are considered to be implemented
the IP module, and the mapping of IP addresses to local
addresses is considered to be the responsibility of local
modules. This model is for expository purposes only, and should
be construed as constraining an actual implementation
| |
| Upper-Layer Protocol Modules |
|__________________________________________________________|
--------------------- IP Service Interface -----------------------
__________________________________________________________
| | | |
| | ICMP | IGMP |
| IP |______________|______________|
| Module |
| |
|__________________________________________________________|
---------------- Local Network Service Interface -----------------
__________________________________________________________
| | |
| Local | IP-to-local address mapping |
| Network | (e.g., ARP) |
| Modules |_____________________________|
| (e.g., Ethernet) |
| |
To provide level 1 multicasting, a host IP implementation
support the transmission of multicast IP datagrams. To provide
2 multicasting, a host must also support the reception of
IP datagrams. Each of these two new services is described in
separate section, below. For each service, extensions are
for the IP service interface, the IP module, the local
service interface, and an Ethernet local network module.
to local network modules other than Ethernet are mentioned briefly
but are not specified in detail
Deering [Page 4]
RFC 1112 Host Extensions for IP Multicasting August 1989
6. SENDING MULTICAST IP
6.1. Extensions to the IP Service
Multicast IP datagrams are sent using the same "Send IP"
used to send unicast IP datagrams; an upper-layer protocol
merely specifies an IP host group address, rather than an
IP address, as the destination. However, a number of extensions
be necessary or desirable
First, the service interface should provide a way for the upper-
protocol to specify the IP time-to-live of an outgoing
datagram, if such a capability does not already exist. If
upper-layer protocol chooses not to specify a time-to-live, it
default to 1 for all multicast IP datagrams, so that an
choice is required to multicast beyond a single network
Second, for hosts that may be attached to more than one network,
service interface should provide a way for the upper-layer
to identify which network interface is be used for the
transmission. Only one interface is used for the
transmission; multicast routers are responsible for forwarding to
other networks, if necessary. If the upper-layer protocol
not to identify an outgoing interface, a default interface should
used, preferably under the control of system management
Third (level 2 implementations only), for the case in which the
is itself a member of a group to which a datagram is being sent,
service interface should provide a way for the upper-layer
to inhibit local delivery of the datagram; by default, a copy of
datagram is looped back. This is a performance optimization
upper-layer protocols that restrict the membership of a group to
process per host (such as a routing protocol), or that
loopback of group communication at a higher layer (such as
multicast transport protocol).
6.2. Extensions to the IP
To support the sending of multicast IP datagrams, the IP module
be extended to recognize IP host group addresses when
outgoing datagrams. Most IP implementations include the
logic
if IP-destination is on the same local network
send datagram locally to IP-
send datagram locally to GatewayTo( IP-destination )
Deering [Page 5]
RFC 1112 Host Extensions for IP Multicasting August 1989
To allow multicast transmissions, the routing logic must be
to
if IP-destination is on the same local
or IP-destination is a host group
send datagram locally to IP-
send datagram locally to GatewayTo( IP-destination )
If the sending host is itself a member of the destination group
the outgoing interface, a copy of the outgoing datagram must
looped-back for local delivery, unless inhibited by the sender
(Level 2 implementations only.)
The IP source address of the outgoing datagram must be one of
individual addresses corresponding to the outgoing interface
A host group address must never be placed in the source address
or anywhere in a source route or record route option of an
IP datagram
6.3. Extensions to the Local Network Service
No change to the local network service interface is required
support the sending of multicast IP datagrams. The IP module
specifies an IP host group destination, rather than an individual
destination, when it invokes the existing "Send Local" operation
6.4. Extensions to an Ethernet Local Network
The Ethernet directly supports the sending of local multicast
by allowing multicast addresses in the destination field of
packets. All that is needed to support the sending of multicast
datagrams is a procedure for mapping IP host group addresses
Ethernet multicast addresses
An IP host group address is mapped to an Ethernet multicast
by placing the low-order 23-bits of the IP address into the low-
23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex).
Because there are 28 significant bits in an IP host group address
more than one host group address may map to the same
multicast address
6.5. Extensions to Local Network Modules other than
Other networks that directly support multicasting, such as rings
buses conforming to the IEEE 802.2 standard, may be handled the
Deering [Page 6]
RFC 1112 Host Extensions for IP Multicasting August 1989
way as Ethernet for the purpose of sending multicast IP datagrams
For a network that supports broadcast but not multicast, such as
Experimental Ethernet, all IP host group addresses may be mapped to
single local broadcast address (at the cost of increased overhead
all local hosts). For a point-to-point link joining two hosts (or
host and a multicast router), multicasts should be
exactly like unicasts. For a store-and-forward network like
ARPANET or a public X.25 network, all IP host group addresses
be mapped to the well-known local address of an IP multicast router
a router on such a network would take responsibility for
multicast delivery within the network as well as among networks
7. RECEIVING MULTICAST IP
7.1. Extensions to the IP Service
Incoming multicast IP datagrams are received by upper-layer
modules using the same "Receive IP" operation as normal,
datagrams. Selection of a destination upper-layer protocol is
on the protocol field in the IP header, regardless of the
IP address. However, before any datagrams destined to a
group can be received, an upper-layer protocol must ask the IP
to join that group. Thus, the IP service interface must be
to provide two new operations
JoinHostGroup ( group-address, interface )
LeaveHostGroup ( group-address, interface )
The JoinHostGroup operation requests that this host become a
of the host group identified by "group-address" on the given
interface. The LeaveGroup operation requests that this host give
its membership in the host group identified by "group-address" on
given network interface. The interface argument may be omitted
hosts that support only one interface. For hosts that may
attached to more than one network, the upper-layer protocol
choose to leave the interface unspecified, in which case the
will apply to the default interface for sending multicast
(see section 6.1).
It is permissible to join the same group on more than one interface
in which case duplicate multicast datagrams may be received. It
also permissible for more than one upper-layer protocol to
membership in the same group
Both operations should return immediately (i.e., they are non
blocking operations), indicating success or failure.
operation may fail due to an invalid group address or
Deering [Page 7]
RFC 1112 Host Extensions for IP Multicasting August 1989
identifier. JoinHostGroup may fail due to lack of local resources
LeaveHostGroup may fail because the host does not belong to the
group on the given interface. LeaveHostGroup may succeed, but
membership persist, if more than one upper-layer protocol
requested membership in the same group
7.2. Extensions to the IP
To support the reception of multicast IP datagrams, the IP
must be extended to maintain a list of host group
associated with each network interface. An incoming
destined to one of those groups is processed exactly the same way
datagrams destined to one of the host's individual addresses
Incoming datagrams destined to groups to which the host does
belong are discarded without generating any error report or
entry. On hosts with more than one network interface, if a
arrives via one interface, destined for a group to which the
belongs only on a different interface, the datagram is
discarded. (These cases should occur only as a result of
multicast address filtering in a local network module.)
An incoming datagram is not rejected for having an IP time-to-live
1 (i.e., the time-to-live should not automatically be decremented
arriving datagrams that are not being forwarded). An
datagram with an IP host group address in its source address field
quietly discarded. An ICMP error message (Destination Unreachable
Time Exceeded, Parameter Problem, Source Quench, or Redirect)
never generated in response to a datagram destined to an IP
group
The list of host group memberships is updated in response
JoinHostGroup and LeaveHostGroup requests from upper-layer protocols
Each membership should have an associated reference count or
mechanism to handle multiple requests to join and leave the
group. On the first request to join and the last request to leave
group on a given interface, the local network module for
interface is notified, so that it may update its multicast
filter (see section 7.3).
The IP module must also be extended to implement the IGMP protocol
specified in Appendix I. IGMP is used to keep neighboring
routers informed of the host group memberships present on
particular local network. To support IGMP, every level 2 host
join the "all-hosts" group (address 224.0.0.1) on each
interface at initialization time and must remain a member for as
as the host is active
Deering [Page 8]
RFC 1112 Host Extensions for IP Multicasting August 1989
(Datagrams addressed to the all-hosts group are recognized as
special case by the multicast routers and are never forwarded
a single network, regardless of their time-to-live. Thus, the all
hosts address may not be used as an internet-wide broadcast address
For the purpose of IGMP, membership in the all-hosts group is
necessary only while the host belongs to at least one other group
However, it is specified that the host shall remain a member of
all-hosts group at all times because (1) it is simpler, (2)
frequency of reception of unnecessary IGMP queries should be
enough that overhead is negligible, and (3) the all-hosts address
serve other routing-oriented purposes, such as advertising
presence of gateways or resolving local addresses.)
7.3. Extensions to the Local Network Service
Incoming local network multicast packets are delivered to the
module using the same "Receive Local" operation as local
unicast packets. To allow the IP module to tell the local
module which multicast packets to accept, the local network
interface is extended to provide two new operations
JoinLocalGroup ( group-address )
LeaveLocalGroup ( group-address )
where "group-address" is an IP host group address.
JoinLocalGroup operation requests the local network module to
and deliver up subsequently arriving packets destined to the given
host group address. The LeaveLocalGroup operation requests the
network module to stop delivering up packets destined to the given
host group address. The local network module is expected to map
IP host group addresses to local network addresses as required
update its multicast reception filter. Any local network module
free to ignore LeaveLocalGroup requests, and may deliver up
destined to more addresses than just those specified
JoinLocalGroup requests, if it is unable to filter incoming
adequately
The local network module must not deliver up any multicast
that were transmitted from that module; loopback of multicasts
handled at the IP layer or higher
7.4. Extensions to an Ethernet Local Network
To support the reception of multicast IP datagrams, an
module must be able to receive packets addressed to the
multicast addresses that correspond to the host's IP host
addresses. It is highly desirable to take advantage of any
Deering [Page 9]
RFC 1112 Host Extensions for IP Multicasting August 1989
filtering capabilities that the Ethernet hardware interface may have
so that the host receives only those packets that are destined to it
Unfortunately, many current Ethernet interfaces have a small limit
the number of addresses that the hardware can be configured
recognize. Nevertheless, an implementation must be capable
listening on an arbitrary number of Ethernet multicast addresses
which may mean "opening up" the address filter to accept
multicast packets during those periods when the number of
exceeds the limit of the filter
For interfaces with inadequate hardware address filtering, it may
desirable (for performance reasons) to perform Ethernet
filtering within the software of the Ethernet module. This is
mandatory, however, because the IP module performs its own
based on IP destination addresses
7.5. Extensions to Local Network Modules other than
Other multicast networks, such as IEEE 802.2 networks, can be
the same way as Ethernet for the purpose of receiving multicast
datagrams. For pure broadcast networks, such as the
Ethernet, all incoming broadcast packets can be accepted and
to the IP module for IP-level filtering. On point-to-point
store-and-forward networks, multicast IP datagrams will arrive
local network unicasts, so no change to the local network
should be necessary
Deering [Page 10]
RFC 1112 Host Extensions for IP Multicasting August 1989
APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP
The Internet Group Management Protocol (IGMP) is used by IP hosts
report their host group memberships to any immediately-
multicast routers. IGMP is an asymmetric protocol and is
here from the point of view of a host, rather than a
router. (IGMP may also be used, symmetrically or asymmetrically
between multicast routers. Such use is not specified here.)
Like ICMP, IGMP is a integral part of IP. It is required to
implemented by all hosts conforming to level 2 of the IP
specification. IGMP messages are encapsulated in IP datagrams,
an IP protocol number of 2. All IGMP messages of concern to
have the following format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Unused | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This memo specifies version 1 of IGMP. Version 0 is
in RFC-988 and is now obsolete
There are two types of IGMP message of concern to hosts
1 = Host Membership
2 = Host Membership
Unused field, zeroed when sent, ignored when received
The checksum is the 16-bit one's complement of the one'
complement sum of the 8-octet IGMP message. For
the checksum, the checksum field is zeroed
Group
In a Host Membership Query message, the group address
Deering [Page 11]
RFC 1112 Host Extensions for IP Multicasting August 1989
is zeroed when sent, ignored when received
In a Host Membership Report message, the group address
holds the IP host group address of the group being reported
Informal Protocol
Multicast routers send Host Membership Query messages (
called Queries) to discover which host groups have members on
attached local networks. Queries are addressed to the all-
group (address 224.0.0.1), and carry an IP time-to-live of 1.
Hosts respond to a Query by generating Host Membership
(hereinafter called Reports), reporting each host group to which
belong on the network interface from which the Query was received
In order to avoid an "implosion" of concurrent Reports and to
the total number of Reports transmitted, two techniques are used
1. When a host receives a Query, rather than sending
immediately, it starts a report delay timer for each of
group memberships on the network interface of the
Query. Each timer is set to a different, randomly-
value between zero and D seconds. When a timer expires,
Report is generated for the corresponding host group. Thus
Reports are spread out over a D second interval instead
all occurring at once
2. A Report is sent with an IP destination address equal to
host group address being reported, and with an
time-to-live of 1, so that other members of the same group
the same network can overhear the Report. If a host hears
Report for a group to which it belongs on that network,
host stops its own timer for that group and does not
a Report for that group. Thus, in the normal case, only
Report will be generated for each group present on
network, by the member host whose delay timer expires first
Note that the multicast routers receive all IP
datagrams, and therefore need not be addressed explicitly
Further note that the routers need not know which
belong to a group, only that at least one host belongs to
group on a particular network
There are two exceptions to the behavior described above. First,
a report delay timer is already running for a group membership when
Query is received, that timer is not reset to a new random value,
rather allowed to continue running with its current value. Second,
report delay timer is never set for a host's membership in the all
hosts group (224.0.0.1), and that membership is never reported
Deering [Page 12]
RFC 1112 Host Extensions for IP Multicasting August 1989
If a host uses a pseudo-random number generator to compute
reporting delays, one of the host's own individual IP address
be used as part of the seed for the generator, to reduce the
of multiple hosts generating the same sequence of delays
A host should confirm that a received Report has the same IP
group address in its IP destination field and its IGMP group
field, to ensure that the host's own Report is not cancelled by
erroneous received Report. A host should quietly discard any
message of type other than Host Membership Query or Host
Report
Multicast routers send Queries periodically to refresh
knowledge of memberships present on a particular network. If
Reports are received for a particular group after some number
Queries, the routers assume that that group has no local members
that they need not forward remotely-originated multicasts for
group onto the local network. Queries are normally sent
(no more than once a minute) so as to keep the IGMP overhead on
and networks very low. However, when a multicast router starts up
it may issue several closely-spaced Queries in order to build up
knowledge of local memberships quickly
When a host joins a new group, it should immediately transmit
Report for that group, rather than waiting for a Query, in case it
the first member of that group on the network. To cover
possibility of the initial Report being lost or damaged, it
recommended that it be repeated once or twice after short delays. (
simple way to accomplish this is to act as if a Query had
received for that group only, setting the group's random report
timer. The state transition diagram below illustrates
approach.)
Note that, on a network with no multicast routers present, the
IGMP traffic is the one or more Reports sent whenever a host joins
new group
State Transition
IGMP behavior is more formally specified by the state
diagram below. A host may be in one of three possible states,
respect to any single IP host group on any single network interface
- Non-Member state, when the host does not belong to the
on the interface. This is the initial state for
memberships on all network interfaces; it requires no
in the host
Deering [Page 13]
RFC 1112 Host Extensions for IP Multicasting August 1989
- Delaying Member state, when the host belongs to the group
the interface and has a report delay timer running for
membership
- Idle Member state, when the host belongs to the group on
interface and does not have a report delay timer running
that membership
There are five significant events that can cause IGMP
transitions
- "join group" occurs when the host decides to join the group
the interface. It may occur only in the Non-Member state
- "leave group" occurs when the host decides to leave the
on the interface. It may occur only in the Delaying
and Idle Member states
- "query received" occurs when the host receives a valid
Host Membership Query message. To be valid, the Query
must be at least 8 octets long, have a correct
checksum and have an IP destination address of 224.0.0.1.
A single Query applies to all memberships on
interface from which the Query is received. It is ignored
memberships in the Non-Member or Delaying Member state
- "report received" occurs when the host receives a valid
Host Membership Report message. To be valid, the
message must be at least 8 octets long, have a correct
checksum, and contain the same IP host group address in its
destination field and its IGMP group address field. A
applies only to the membership in the group identified by
Report, on the interface from which the Report is received
It is ignored for memberships in the Non-Member or Idle
state
- "timer expired" occurs when the report delay timer for
group on the interface expires. It may occur only in
Delaying Member state
All other events, such as receiving invalid IGMP messages, or
messages other than Query or Report, are ignored in all states
There are three possible actions that may be taken in response to
above events
- "send report" for the group on the interface
Deering [Page 14]
RFC 1112 Host Extensions for IP Multicasting August 1989
- "start timer" for the group on the interface, using a
delay value between 0 and D seconds
- "stop timer" for the group on the interface
In the following diagram, each state transition arc is labelled
the event that causes the transition, and, in parentheses,
actions taken during the transition
________________
| |
| |
| |
| |
--------->| Non-Member |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| leave group | join group | leave
| (stop timer) |(send report, |
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying Member | (start timer) | Idle Member |
| |------------------->| |
| | report received | |
| | (stop timer) | |
|_________________|------------------->|_________________|
timer
(send report
The all-hosts group (address 224.0.0.1) is handled as a special case
The host starts in Idle Member state for that group on
interface, never transitions to another state, and never sends
report for that group
Protocol
The maximum report delay, D, is 10 seconds
Deering [Page 15]
RFC 1112 Host Extensions for IP Multicasting August 1989
APPENDIX II. HOST GROUP ADDRESS
This appendix is not part of the IP multicasting specification,
provides background discussion of several issues related to IP
group addresses
Group Address
The binding of IP host group addresses to physical hosts may
considered a generalization of the binding of IP unicast addresses
An IP unicast address is statically bound to a single local
interface on a single IP network. An IP host group address
dynamically bound to a set of local network interfaces on a set of
networks
It is important to understand that an IP host group address is
bound to a set of IP unicast addresses. The multicast routers do
need to maintain a list of individual members of each host group
For example, a multicast router attached to an Ethernet
associate only a single Ethernet multicast address with each
group having local members, rather than a list of the members
individual IP or Ethernet addresses
Allocation of Transient Host Group
This memo does not specify how transient group address are allocated
It is anticipated that different portions of the IP transient
group address space will be allocated using different techniques
For example, there may be a number of servers that can be
to acquire a new transient group address. Some higher-
protocols (such as VMTP, specified in RFC-1045) may generate higher
level transient "process group" or "entity group" addresses which
then algorithmically mapped to a subset of the IP transient
group addresses, similarly to the way that IP host group
are mapped to Ethernet multicast addresses. A portion of the
group address space may be set aside for random allocation
applications that can tolerate occasional collisions with
multicast users, perhaps generating new addresses until a
"quiet" one is found
In general, a host cannot assume that datagrams sent to any
group address will reach only the intended hosts, or that
received as a member of a transient host group are intended for
recipient. Misdelivery must be detected at a level above IP,
higher-level identifiers or authentication tokens.
transmitted to a host group address should be encrypted or
by administrative routing controls if the sender is concerned
unwanted listeners
Deering [Page 16]
RFC 1112 Host Extensions for IP Multicasting August 1989
Author's
Steve
Stanford
Computer Science
Stanford, CA 94305-2140
Phone: (415) 723-9427
EMail: deering@PESCADERO.STANFORD.
Deering [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
