As per Relevance of the word boundary, we have this rfc below:
Network Working Group M.
Request for Comments: 2776
Category: Standards Track D.
R.
February 2000
Multicast-Scope Zone Announcement Protocol (MZAP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document defines a protocol, the Multicast-Scope
Announcement Protocol (MZAP), for discovering the
administrative scope zones that are relevant at a
location. MZAP also provides mechanisms whereby
misconfigurations of administrative scope zones can be discovered
Table of
1 Introduction ................................................ 2
2 Terminology ................................................. 4
3 Overview .................................................... 5
3.1 Scope Nesting ............................................. 6
3.2 Other Messages ............................................ 7
3.3 Zone IDs .................................................. 7
4 Detecting Router Misconfigurations .......................... 8
4.1 Detecting non-convex scope zones .......................... 8
4.2 Detecting leaky boundaries for non-local scopes ........... 9
4.3 Detecting a leaky Local Scope zone ........................ 10
4.4 Detecting conflicting scope zones ......................... 10
5 Packet Formats .............................................. 11
5.1 Zone Announcement Message ................................. 14
5.2 Zone Limit Exceeded (ZLE) ................................. 15
5.3 Zone Convexity Message .................................... 15
Handley, et al. Standards Track [Page 1]
RFC 2776 MZAP February 2000
5.4 Not-Inside Message ........................................ 16
6 Message Processing Rules .................................... 17
6.1 Internal entities listening to MZAP messages .............. 17
6.2 Sending ZAMs .............................................. 18
6.3 Receiving ZAMs ............................................ 18
6.4 Sending ZLEs .............................................. 20
6.5 Receiving ZLEs ............................................ 20
6.6 Sending ZCMs .............................................. 21
6.7 Receiving ZCMs ............................................ 21
6.8 Sending NIMs .............................................. 21
6.9 Receiving NIMs ............................................ 22
7 Constants ................................................... 22
8 Security Considerations ..................................... 23
9 Acknowledgements ............................................ 24
10 References ................................................. 25
11 Authors' Addresses ......................................... 26
12 Full Copyright Statement ................................... 27
1.
The use of administratively-scoped IP multicast, as defined in
2365 [1], allows packets to be addressed to a specific range
multicast addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4)
such that the packets will not cross configured
boundaries, and also allows such addresses to be locally assigned
hence are not required to be unique across administrative boundaries
This property of logical naming both allows for address reuse,
well as provides the capability for infrastructure services such
address allocation, session advertisement, and service location
use well-known addresses which are guaranteed to have
significance within every organization
The range of administratively-scoped addresses can be subdivided
administrators so that multiple levels of administrative
can be simultaneously supported. As a result, a "multicast scope"
defined as a particular range of addresses which has been given
topological meaning
To support such usage, a router at an administrative boundary
configured with one or more per-interface filters, or "
scope boundaries". Having such a boundary on an interface means
it will not forward packets matching a configured range of
addresses in either direction on the interface
A specific area of the network topology which is within a
for a given scope is known as a "multicast scope zone". Since
same ranges can be reused within disjoint areas of the network,
may be many "multicast scope zones" for any given multicast scope.
Handley, et al. Standards Track [Page 2]
RFC 2776 MZAP February 2000
scope zone may have zero or more textual names (in
languages) for the scope, for human convenience. For example, if
range 239.192/14 were assigned to span an entire corporate network
it might be given (internally) the name "BigCo Private Scope".
Administrative scope zones may be of any size, and a particular
may be within many administrative scope zones (for different scopes
i.e., for non-overlapping ranges of addresses) of various sizes,
long as scope zones that intersect topologically do not intersect
address range
Applications and services are interested in various aspects of
scopes within which they reside
o Applications which present users with a choice of which scope
which to operate (e.g., when creating a new session, whether it
to be confined to a corporate intranet, or whether it should
out over the public Internet) are interested in the textual
which have significance to users
o Services which use "relative" multicast addresses (as defined
[1]) in every scope are interested in the range of addresses
by each scope, so that they can apply a constant offset
compute which address to use in each scope
o Address allocators are interested in the address range,
whether they are allowed to allocate addresses within the
range or not
o Some applications and services may also be interested in
nesting relationships among scopes. For example, knowledge of
nesting relationships can be used to perform "expanding-scope
searches in a similar, but better behaved, manner to the well
known expanding ring search where the TTL of a query is
increased until a replier can be found. Studies have also
that nested scopes can be useful in localizing multicast
traffic [8].
Two barriers currently make administrative scoping difficult
deploy and use
o Applications have no way to dynamically discover information
scopes that are relevant to them. This makes it difficult to
administrative scope zones, and hence reduces the incentive
deploy them
Handley, et al. Standards Track [Page 3]
RFC 2776 MZAP February 2000
o Misconfiguration is easy. It is difficult to detect scope
that have been configured so as to not be convex (the
path between two nodes within the zone passes outside the zone),
or to leak (one or more boundary routers were not
correctly), or to intersect in both area and address range
These two barriers are addressed by this document. In particular
this document defines the Multicast Scope Zone Announcement
(MZAP) which allows an entity to learn what scope zones it is within
Typically servers will cache the information learned from MZAP
can then provide this information to applications in a timely
upon request using other means, e.g., via MADCAP [9]. MZAP
provides diagnostic information to the boundary routers
that enables misconfigured scope zones to be detected
2.
The "Local Scope" is defined in RFC 2365 [1] and represents
smallest administrative scope larger than link-local, and
associated address range is defined as 239.255.0.0 to 239.255.255.255
inclusive (for IPv4, FF03::/16 for IPv6). RFC 2365 specifies
"239.255.0.0/16 is defined to be the IPv4 Local Scope. The
Scope is the minimal enclosing scope, and hence is not
divisible. Although the exact extent of a Local Scope is
dependent, locally scoped regions must obey certain
constraints. In particular, a Local Scope must not span any
scope boundary. Further, a Local Scope must be
contained within or equal to any larger scope. In the event
scope regions overlap in area, the area of overlap must be in
own Local Scope. This implies that any scope boundary is also
boundary for the Local Scope."
A multicast scope Zone Boundary Router (ZBR) is a router that
configured with a boundary for a particular multicast scope on one
more of its interfaces. Any interface that is configured with
boundary for any administrative scope zone MUST also have a
for the Local Scope zone, as described above
Such routers SHOULD be configured so that the router itself is
the scope zone. This is shown in Figure 1(a), where router A
inside the scope zone and has the boundary configuration
Handley, et al. Standards Track [Page 4]
RFC 2776 MZAP February 2000
............ ................
. . +B+--> . *B+-->
. . / . / .
. * . + .
. <---+A*---+C+-> . <---+A+---*C+->
. + . . + .
. / . . / .
. zone X <-- . . zone X <-- .
.............. ..................
A,B,C - routers * - boundary interface + -
(a) Correct zone boundary (b) Incorrect zone
Figure 1: Administrative scope zone boundary
It is possible for the first router outside the scope zone to
configured with the boundary, as illustrated in Figure 1(b)
routers B and C are outside the zone and have the
configuration, whereas A does not, but this is NOT RECOMMENDED.
rule does not apply for Local Scope boundaries, but applies for
other boundary routers
We next define the term "Zone ID" to mean the lowest IP address
by any ZBR for a particular zone for sourcing MZAP messages into
scope zone. The combination of this IP address and the
multicast address in the scope range serve to uniquely identify
scope zone. Each ZBR listens for messages from other ZBRs for
same boundary, and can determine the Zone ID based on the
addresses seen. The Zone ID may change over time as ZBRs come up
down
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [2].
Constants used by this protocol are shown as [NAME-OF-CONSTANT],
summarized in section 7.
3.
When a ZBR is configured correctly, it can deduce which side of
boundary is inside the scope zone and which side is outside it
Such a ZBR then sends periodic Zone Announcement Messages (ZAMs)
each zone for which it is configured as a boundary into that
zone, containing information on the scope zone's address range,
ID, and textual names. These messages are multicast to the well
Handley, et al. Standards Track [Page 5]
RFC 2776 MZAP February 2000
known address [MZAP-LOCAL-GROUP] in the Local Scope, and are
across Local Scope boundaries into all Local Scope zones within
scope zone referred to by the ZAM message, as shown in Figure 2.
###########################
# Zone1 = Zone2 # ##### = large scope zone
*E-----+--->A*-----+-x #
# | = v # ===== = Local Scope
# | ======*===*==#
# | = B F # ----> = path of ZAM originated by
G*<-----+--->C*-> | ^ #
# v = <-+---+ # ABCDE =
# D = Zone3 #
#######*################### * = boundary
Figure 2: ZAM Flooding
Any entity can thus listen on a single well-known group address
learn about all scopes in which it resides
3.1. Scope
MZAP also provides the ability to discover the nesting
between scope zones. Two zones are nested if one is comprised of
subset of the routers in the other, as shown in Figure 3.
+-----------+ +-----------+ +-------------+
| Zone 1 | | Zone 3 | | Zone 5 |
| +------+| | +------+ | .........|..
| |Zone 2|| | |Zone 4| | : Zone 6 | :
| +--A---+| | C | | D | :
+-----------+ +----+--B---+ +--------E----+ :
:..........:
(a) "Contained" (b) "Common Border" (c) "Overlap
Zone 2 nests Zone 4 nests Zones 5 and 6
inside Zone 1 inside Zone 3 do not
Figure 3: Zone nesting
A ZBR cannot independently determine whether one zone is
inside another. However, it can determine that one zone does
nest inside another. For example, in Figure 3:
o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2
from leaving zone 2. When ZBR A first receives a ZAM for zone 1,
it then knows that zone 1 does not nest within zone 2, but
cannot, however, determine whether zone 2 nests within zone 1.
Handley, et al. Standards Track [Page 6]
RFC 2776 MZAP February 2000
o ZBR B acts as ZBR for both zones 3 and 4, and hence
determine if one is nested inside the other. However, ZBR C
determine that zone 3 does not nest inside zone 4 when it
a ZAM for zone 3, since it is a ZBR for zone 4 but not zone 3.
o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can
that zone 5 does not nest inside zone 6 upon hearing a ZAM
zone 5. Similarly, ZBR E only acts as ZBR zone 5 and not 6,
ZBR E can deduce that zone 6 does not nest inside zone 5
hearing a ZAM for zone 6.
The fact that ZBRs can determine that one zone does not nest
another, but not that a zone does nest inside another, means
nesting must be determined in a distributed fashion. This is done
sending Not-Inside Messages (NIMs) which express the fact that a
X is not inside a zone Y. Such messages are sent to the well-
[MZAP-LOCAL-GROUP] and are thus seen by the same entities
to ZAM messages (e.g., MADCAP servers). Such entities can
determine the nesting relationship between two scopes based on
sustained absence of any evidence to the contrary
3.2. Other
Two other message types, Zone Convexity Messages (ZCMs) and
Limit Exceeded (ZLE) messages, are used only by routers, and
them to compare their configurations for consistency and
misconfigurations. These messages are sent to MZAP's
address within the scope range associated with the scope zone
which they refer, and hence are typically not seen by entities
than routers. Their use in detecting specific
scenarios will be covered in the next section
Packet formats for all messages are described in Section 5.
3.3. Zone
When a boundary router first starts up, it uses its lowest IP
which it considers to be inside a given zone, and which is
everywhere within the zone (for example, not a link-local address),
as the Zone ID for that zone. It then schedules ZCM (and ZAM
messages to be sent in the future (it does not send
immediately). When a ZCM is received for the given scope, the
is added to the local list of ZBRs (including itself) for that scope
and the Zone ID is updated to be the lowest IP address in the list
Entries in the list are eventually timed out if no further
are received from that ZBR, such that the Zone ID will converge
the lowest address of any active ZBR for the scope
Handley, et al. Standards Track [Page 7]
RFC 2776 MZAP February 2000
Note that the sender of ZAM messages MUST NOT be used in this way
This is because the procedure for detecting a leaky Local
described in Section 4.3 below relies on two disjoint zones for
same scope range having different Zone IDs. If ZAMs are used
compute Zone IDs, then ZAMs leaking across a Local Scope
will cause the two zones to converge to the same Zone ID
4. Detecting Router
In this section, we cover how to detect various error conditions.
any error is detected, the router should attempt to alert a
administrator to the nature of the misconfiguration. The means to
this lies outside the scope of MZAP
4.1. Detecting non-convex scope
Zone Convexity Messages (ZCMs) are used by routers to detect non
convex administrative scope zones, which are one
misconfiguration. Non-convex scope zones can cause problems
applications since a receiver may never see administratively-
packets from a sender within the same scope zone, since
travelling between them may be dropped at the boundary
In the example illustrated in Figure 4, the path between B and D
outside the scope (through A and E). Here, Router B and Router
send ZCMs within a given scope zone for which they each have
boundary, with each reporting the other boundary routers of the
from which they have heard. In Figure 4, Router D cannot see
B's messages, but can see C's report of B, and so can conclude
zone is not convex
#####*####========
# B # = ##### = non-convex scope
# |->A* =
# | # = ===== = other scope
# | ####*####
# | E # ----> = path of B's
# v D
# C # * = boundary
#####*############
Figure 4: Non-convexity
Handley, et al. Standards Track [Page 8]
RFC 2776 MZAP February 2000
Non-convex scope zones can be detected via three methods
(1) If a ZBR is listed in ZCMs received, but the next-hop
(according to the multicast RIB) towards that ZBR is outside
scope zone
(2) If a ZBR is listed in ZCMs received, but no ZCM is received
that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 4,
(3) ZAM messages can also be used in a manner similar to that
ZCMs in (1) above, as follows: if a ZAM is received from a ZBR
an interface inside a given scope zone, and the next-
interface (according to the multicast RIB) towards that ZBR
outside the scope zone
Zone Convexity Messages MAY also be sent and received by
configured ordinary hosts within a scope region, which may be
useful diagnostic facility that does not require privileged access
4.2. Detecting leaky boundaries for non-local
A "leaky" boundary is one which logically has a "hole" due to
router not having a boundary applied on an interface where one
to exist. Hence, the boundary does not completely surround a
of the network, resulting in scoped data leaking outside
Leaky scope boundaries can be detected via two methods
(1) If it receives ZAMs originating inside the scope boundary on
interface that points outside the zone boundary. Such a
message must have escaped the zone through a leak, and
back around behind the boundary. This is illustrated in
5.
=============#####*########
= Zone1 # A Zone2 # C = misconfigured
= +---->*E v #
= | # B # ##### = leaky scope
=======*=====#====*=======#
= D # | # ===== = other scope
= ^-----*C<--+ #
= Zone4 # Zone3 # ----> = path of
=============##############
Figure 5: ZAM
Handley, et al. Standards Track [Page 9]
RFC 2776 MZAP February 2000
(2) If a Zone Length Exceeded (ZLE) message is received. The
packet also contains a Zones Traveled Limit. If the number
Local Scope zones traversed becomes equal to the Zones
Limit, a ZLE message is generated (the suppression mechanism
preventing implosion is described later in the Processing
section). ZLEs detect leaks where packets do not return
another part of the same scope zone, but instead reach
Local Scope zones far away from the ZAM originator
In either case, the misconfigured router will be either the
origin, or one of the routers in the ZBR path list which is
in the message received (or perhaps a router on the path between
such ZBRs which ought to have been a ZBR itself).
4.3. Detecting a leaky Local Scope
A local scope is leaky if a router has an administrative
boundary on some interface, but does not have a Local Scope
on that interface as specified in RFC 2365. This can be detected
the following method
o If a ZAM for a given scope is received by a ZBR which is
boundary for that scope, it compares the Origin's Scope Zone ID
the ZAM with its own Zone ID for the given scope. If the two
not match, this is evidence of a misconfiguration. Since
temporary mismatch may result immediately after a recent change
the reachability of the lowest-addressed ZBR,
should be assumed only if the mismatch is persistent
The exact location of the problem can be found by doing an mtrace [5]
from the router detecting the problem, back to the ZAM origin,
any group within the address range identified by the ZAM. The
at fault will be the one reporting that a boundary was reached
4.4. Detecting conflicting scope
Conflicting address ranges can be detected via the following method
o If a ZBR receives a ZAM for a given scope, and the included
and end addresses overlap with, but are not identical to,
start and end addresses of a locally-configured scope
Conflicting scope names can be detected via the following method
o If a ZBR is configured with a textual name for a given scope
language, and it receives a ZAM or ZCM with a name for the
scope and language, but the scope names do not match
Handley, et al. Standards Track [Page 10]
RFC 2776 MZAP February 2000
Detecting either type of conflict above indicates that either
local router or the router originating the message is misconfigured
Configuration tools SHOULD strip white space from the beginning
end of each name to avoid accidental misconfiguration
5. Packet
All MZAP messages are sent over UDP, with a destination port
[MZAP-PORT] and an IPv4 TTL or IPv6 Hop Limit of 255.
When sending an MZAP message referring to a given scope zone, a
MUST use a source address which will have significance
within the scope zone to which the message refers. For example
link-local addresses MUST NOT be used
The common MZAP message header (which follows the UDP header),
shown below
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 |B| PTYPE |Address Family | NameCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Origin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone End Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Zone Name-1 (variable length) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | Encoded Zone Name-N (variable length) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The version defined in this document is version 0.
Handley, et al. Standards Track [Page 11]
RFC 2776 MZAP February 2000
"Big" scope bit (B):
If clear, indicates that the addresses in the scoped range are
subdividable, and that address allocators may utilize the
range. If set, address allocators should not use the
range, but should learn an appropriate sub-range via
mechanism (e.g., AAP [7]).
Packet Type (PTYPE):
The packet types defined in this document are
0: Zone Announcement Message (ZAM
1: Zone Limit Exceeded (ZLE
2: Zone Convexity Message (ZCM
3: Not-Inside Message (NIM
Address Family
The IANA-assigned address family number [10,11] identifying
address family for all addresses in the packet. The
defined for IP are
1: IPv
2: IPv
Name Count
The number of encoded zone name blocks in this packet. The
may be zero
Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
This gives the start address for the scope zone boundary.
example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255,
then Zone Start Address is 239.1.0.0.
Zone End Address: 32 bits (IPv4) or 128 bits (IPv6)
This gives the ending address for the scope zone boundary.
example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255,
then Zone End Address is 239.1.0.255.
Message Origin: 32 bits (IPv4) or 128 bits (IPv6)
This gives the IP address of the interface that originated
message
Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6)
This gives the lowest IP address of a boundary router that
been observed in the zone originating the message. Together
Zone Start Address and Zone End Address, it forms a unique ID
the zone. Note that this ID is usually different from the ID
the Local Scope zone in which the origin resides
Handley, et al. Standards Track [Page 12]
RFC 2776 MZAP February 2000
Encoded Zone Name
+--------------------+
|D| Reserved (7 bits)|
+--------------------+
| LangLen (1 byte) |
+--------------------+-----------+
| Language Tag (variable size) |
+--------------------+-----------+
| NameLen (1 byte) |
+--------------------+-----------+
| Zone Name (variable size) |
+--------------------------------+
The first byte contains flags, of which only the high bit
defined. The other bits are reserved (sent as 0, ignored
receipt).
"Default Language" (D) bit
If set, indicates a preference that the name in the
language should be used if no name is available in a
language
Language tag length (LangLen): 1
The length, in bytes, of the language tag
Language Tag: (variable size
The language tag, such as "en-US", indicating the language of
zone name. Language tags are described in [6].
Name Len
The length, in bytes, of the Zone Name field. The length MUST
be zero
Zone Name: multiple of 8
The Zone Name is an ISO 10646 character string in UTF-8
[4] indicating the name given to the scope zone (eg: "ISI-
Site"). It should be relatively short and MUST be less than 256
bytes in length. White space SHOULD be stripped from
beginning and end of each name before encoding, to
accidental conflicts
Padding (if needed):
The end of the MZAP header is padded with null bytes until it
4-byte aligned
Handley, et al. Standards Track [Page 13]
RFC 2776 MZAP February 2000
5.1. Zone Announcement
A Zone Announcement Message has PTYPE=0, and is periodically sent
a ZBR for each scope for which it is a boundary, EXCEPT
o the Local
o the Link-local
The format of a Zone Announcement Message is shown below
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are defined as follows
Zones Traveled (ZT): 8
This gives the number of Local Zone IDs contained in this
path
Zones Traveled Limit (ZTL): 8
This gives the limit on number of local zones that the packet
traverse before it MUST be dropped. A value of 0 indicates
no limit exists
Hold Time
The time, in seconds, after which the receiver should assume
scope no longer exists, if no subsequent ZAM is received.
should be set to [ZAM-HOLDTIME].
Handley, et al. Standards Track [Page 14]
RFC 2776 MZAP February 2000
Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6)
The zone path is a list of Local Zone ID Addresses (the Zone
Address of a local zone) through which the ZAM has passed, and
addresses of the router that forwarded the packet. The
router fills in the "Local Zone ID Address 0" field when
the ZAM. Every Local Scope router that forwards the ZAM across
Local Scope boundary MUST add the Local Zone ID Address of
local zone that the packet of the zone into which the message
being forwarded, and its own IP address to the end of this list
and increment ZT accordingly. The zone path is empty which
ZAM is first sent
5.2. Zone Limit Exceeded (ZLE
The format of a ZLE is shown below
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields are copied from the ZAM, except PTYPE which is set to one
5.3. Zone Convexity
A Zone Announcement Message has PTYPE=2, and is periodically sent
a ZBR for each scope for which it is a boundary (except the Link
local scope). Note that ZCM's ARE sent in the Local Scope
Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL
GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP
in the scope zone itself. The format of a ZCM is shown below
Handley, et al. Standards Track [Page 15]
RFC 2776 MZAP February 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZNUM | unused | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows
Number of ZBR addresses (ZNUM): 8
This field gives the number of ZBR Addresses contained in
message
Hold Time
The time, in seconds, after which the receiver should assume
sender is no longer reachable, if no subsequent ZCM is received
This should be set to [ZCM-HOLDTIME].
ZBR Address: 32 bits (IPv4) or 128 bits (IPv6)
These fields give the addresses of the other ZBRs from which
Message Origin ZBR has received ZCMs but whose hold time has
expired. The router should include all such addresses which
in the packet, preferring those which it has not included
if all do not fit
5.4. Not-Inside
A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by
ZBR which knows that a scope X does not nest within another scope
("X not inside Y"):
The format of a Not-Inside Message is shown below
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not-Inside Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Handley, et al. Standards Track [Page 16]
RFC 2776 MZAP February 2000
The fields are as follows
MZAP Header: Header fields identifying the scope X. The Name
may be 0.
Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6)
gives the start address for the scope Y
6. Message Processing
6.1. Internal entities listening to MZAP
Any host or application may join the [MZAP-LOCAL-GROUP] to listen
Zone Announcement Messages to build up a list of the scope zones
are relevant locally, and for Not-Inside Messages if it wishes
learn nesting information. However, listening to such messages
not the recommended method for regular applications to discover
information. These applications will normally query a
Multicast Address Allocation Server (MAAS) [3], which in turn
to Zone Announcement Messages and Not-Inside Messages to
scope information, and can be queried by clients via MADCAP messages
An entity (including a MAAS) lacking any such information can
assume that it is within the Global Scope, and the Local Scope,
of which have well-known address ranges defined in [1].
An internal entity (e.g., an MAAS) receiving a ZAM will parse
information that is relevant to it, such as the address range,
the names. An address allocator receiving such information MUST
use the "B" bit to determine whether it can add the address range
the set of ranges from which it may allocate addresses (specifically
it may add them only if the bit is zero). Even if the bit is zero
an MAAS SHOULD still store the range information so that clients
use relative- addresses can still obtain the ranges by
them from the MAAS
An internal entity (e.g., an MAAS) should assume that X nests
Y if
a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME
seconds ago,
b) it has not heard a NIM indicating that "X not inside Y" for
least [NIM-HOLDTIME] seconds
Handley, et al. Standards Track [Page 17]
RFC 2776 MZAP February 2000
6.2. Sending
Each ZBR should send a Zone Announcement Message for each scope
for which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30%
[ZAM-INTERVAL] each time to avoid message synchronisation
The ZAM packet also contains a Zones Traveled Limit (ZTL). If
number of Local Zone IDs in the ZAM path becomes equal to the
Traveled Limit, the packet will be dropped. The ZTL field is
when the packet is first sent, and defaults to 32, but can be set
a lower value if a network administrator knows the expected size
the zone
6.3. Receiving
When a ZBR receives a ZAM for some scope zone X, it uses
following rules
If the local ZBR does NOT have any configuration for scope X
(1) Check to see if the included start and end addresses
with, but are not identical to, the start and end addresses
any locally-configured scope Y, and if so, signal an
range conflict to a local administrator
(2) Create a local "X not inside" state entry, if such an entry
not already exist. The ZBR then restarts the entry's timer
[ZAM-HOLDTIME]. Existence of this state indicates that the
knows that X does not nest inside any scope for which it is
boundary. If the entry's timer expires (because no more ZAMs
X are heard for [ZAM-HOLDTIME]), the entry is deleted
If the local ZBR does have configuration for scope X
(1) If the ZAM originated from OUTSIDE the scope (i.e., received
a boundary interface for scope X):
a) If the Scope Zone ID in the ZAM matches the ZBR's own
Zone ID, then signal a leaky scope misconfiguration
b) Drop the ZAM (perform no further processing below).
example, router G in Figure 2 will not forward the ZAM.
rule is primarily a safety measure, since the placement of G
Figure 2 is not a recommended configuration, as
earlier
Handley, et al. Standards Track [Page 18]
RFC 2776 MZAP February 2000
2) If the ZAM originated from INSIDE the scope
a) If the next-hop interface (according to the multicast RIB
towards the Origin is outside the scope zone, then signal
non- convexity problem
b) If the Origin's Scope Zone ID in the ZAM does not match
Scope Zone ID kept by the local ZBR, and this
continues to occur, then signal a possible leaky scope warning
c) For each textual name in the ZAM, see if a name for the
scope and language is locally-configured; if so, but the
names do not match, signal a scope name conflict to a
administrator
d) If the ZAM was received on an interface which is NOT a
Scope boundary, and the last Local Zone ID Address in the
list is 0, the ZBR fills in the Local Zone ID Address of
local zone from which the ZAM was received
If a ZAM for the same scope (as identified by the origin Zone ID
first multicast address) was received in the last [ZAM-DUP-TIME
seconds, the ZAM is then discarded. Otherwise, the ZAM is cached
at least [ZAM-DUP-TIME] seconds. For example, when router C
Figure 2 receives the ZAM via B, it will not be forwarded, since
has just forwarded the ZAM from E
The Zones Travelled count in the message is then incremented, and
the updated count is equal to or greater than the ZTL field,
a ZLE to be sent as described in the next subsection and perform
further processing below
If the Zone ID of the Local Scope zone in which the ZBR resides
not already in the ZAM's path list, then the ZAM is immediately re
originated within the Local Scope zone. It adds its own address
the Zone ID of the Local Scope zone into which the message is
forwarded to the ZAM path list before doing so. A ZBR receiving
ZAM with a non-null path list MUST NOT forward that ZAM back into
Local Scope zone that is contained in the path list. For example,
Figure 2, router F, which did not get the ZAM via A due to
loss, will not forward the ZAM from B back into Zone 2 since the
list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears
In addition, the ZBR re-originates the ZAM out each interface with
Local Scope boundary (except that it is not sent back out
interface over which it was received, nor is it sent into any
scope zone whose ID is known and appears in the path list). In
such ZAM re-originated, the ZBR adds its own IP address to the
Handley, et al. Standards Track [Page 19]
RFC 2776 MZAP February 2000
list, as well as the Zone ID Address of the Local Scope Zone
which the ZAM is being sent, or 0 if the ID is unknown. (
example, if the other end of a point-to-point link also has
boundary on the interface, then the link has no Local Scope Zone ID.)
6.4. Sending
This packet is sent by a local-zone boundary router that would
exceeded the Zone Traveled Limit if it had forwarded a ZAM packet
To avoid ZLE implosion, ZLEs are multicast with a random delay
suppressed by other ZLEs. It is only scheduled if at least [ZLE
MIN-INTERVAL] seconds have elapsed since it previously sent a ZLE
any destination. To schedule a ZLE, the router sets a random
timer within the interval [ZLE-SUPPRESSION-INTERVAL], and listens
the [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs
If any are received before the random delay timer expires, the
is cleared and the ZLE is not sent. If the timer expires, the
sends a ZLE to the [MZAP-RELATIVE-GROUP] within the indicated scope
The method used to choose a random delay (T) is as follows
Choose a random value X from the uniform random interval [0:1]
Let C = 256
Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C
This equation results in an exponential random distribution
ensures that close to one ZBR will respond. Using a purely
distribution would begin to exhibit scaling problems as the number
ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE
before the time chosen, two routers choosing delays which differ
an amount less than the propagation delay between them will both
messages, consuming excess bandwidth. Hence it is desirable
minimize the number of routers choosing a delay close to the
delay chosen, and an exponential distribution is suitable for
purpose
A router SHOULD NOT send more than one Zone Limit Exceeded
every [ZLE-MIN-INTERVAL] regardless of destination
6.5. Receiving
When a router receives a ZLE, it performs the following actions
(1) If the router has a duplicate ZLE message scheduled to be sent
it unschedules its own message so another one will not be sent
(2) If the ZLE contains the router's own address in the Origin field
it signals a leaky scope misconfiguration
Handley, et al. Standards Track [Page 20]
RFC 2776 MZAP February 2000
6.6. Sending
Each ZBR should send a Zone Convexity Message (ZCM) for each
zone for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30%
of [ZCM-INTERVAL] each time to avoid message synchronisation
ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself
(For example, if the scope range is 239.1.0.0 to 239.1.0.255,
these messages should be sent to 239.1.0.252.) As these are
Locally-Scoped packets, they are simply multicast across the
zone itself, and require no path to be built up, nor any
processing by intermediate Local Scope ZBRs
6.7. Receiving
When a ZCM is received for a given scope X, on an interface which
inside the scope, it follows the rules below
(1) The Origin is added to the local list of ZBRs (including itself
for that scope, and the Zone ID is updated to be the lowest
address in the list. The new entry is scheduled to be timed
after [ZCM-HOLDTIME] if no further messages are received
that ZBR, so that the Zone ID will converge to the lowest
of any active ZBR for the scope
(2) If a ZBR is listed in ZCMs received, but the next-hop
(according to the multicast RIB) towards that ZBR is outside
scope zone, or if no ZCM is received from that ZBR for [ZCM
HOLDTIME] seconds, as in the example in Figure 4, then signal
non-convexity problem
(3) For each textual name in the ZCM, see if a name for the
scope and language is locally-configured; if so, but the
names do not match, signal a scope name conflict to a
administrator
6.8. Sending
Periodically, for each scope zone Y for which it is a boundary,
router originates a Not-Inside Message (NIM) for each "X not inside
entry it has created when receiving ZAMs. Like a ZAM, this
is multicast to the address [MZAP-LOCAL-GROUP] from one of
interfaces inside Y
Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL
seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization
Handley, et al. Standards Track [Page 21]
RFC 2776 MZAP February 2000
6.9. Receiving
When a ZBR receives a NIM saying that "X is not inside Y", it
forwarded, unmodified, in a manner similar to ZAMs
(1) If the NIM was received on an interface with a boundary
either X or Y, the NIM is discarded
(2) Unlike ZAMs, if the NIM was not received on the interface
the message origin (according to the Multicast RIB), the NIM
discarded
(3) If a NIM for the same X and Y (where each is identified by
first multicast address) was received in the last [ZAM-DUP-TIME
seconds, the NIM is not forwarded
(4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds
(5) The ZBR then re-originates the NIM (i.e., with the original
payload) into each local scope zone in which it has interfaces
except that it is not sent back into the local scope zone
which the message was received, nor is it sent out any
with a boundary for either X or Y
7.
[MZAP-PORT]: The well-known UDP port to which all MZAP messages
sent. Value: 2106.
[MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to
ZAMs are sent. All Multicast Address Allocation servers and
Boundary Routers listen to this group. Value: 239.255.255.252
IPv4.
[ZCM-RELATIVE-GROUP]: The relative group in each scope zone,
which ZCMs are sent. A Zone Boundary Router listens to the
group in each scope for which it is a boundary. Value: (last
address in scope range) - 3. For example, in the Local Scope,
relative group is the same as the [MZAP-LOCAL-GROUP] address
[ZAM-INTERVAL]: The interval at which a Zone Boundary
originates Zone Announcement Messages. Default value: 600
(10 minutes).
[ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD
set to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31
minutes).
Handley, et al. Standards Track [Page 22]
RFC 2776 MZAP February 2000
[ZAM-DUP-TIME]: The time interval after forwarding a ZAM,
which ZAMs for the same scope will not be forwarded. Default value
30 seconds
[ZCM-INTERVAL]: The interval at which a Zone Boundary
originates Zone Convexity Messages. Default value: 600 seconds (10
minutes).
[ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD
set to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31
minutes).
[ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose
random delay before sending a ZLE message. Default value: 300
seconds (5 minutes).
[ZLE-MIN-INTERVAL]: The minimum interval between sending
messages, regardless of destination. Default value: 300 seconds (5
minutes).
[NIM-INTERVAL]: The interval at which a Zone Boundary
originates Not-Inside Messages. Default value: 1800 seconds (30
minutes).
[NIM-HOLDTIME]: The holdtime to include the state within a NIM
This SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value
5460 (91 minutes
8. Security
While unauthorized reading of MZAP messages is relatively
(so encryption is generally not an issue), accepting
MZAP messages can be problematic. Authentication of MZAP
can be provided by using the IPsec Authentication Header (AH) [12].
In the case of ZCMs and ZLEs, an attacker can cause false logging
convexity and leakage problems. It is likely that is would be
an annoyance, and not cause any significant problem. (Such
could be authenticated, but since they may be sent within
scopes, the receiver may not be able to authenticate a non-
sender.)
ZAMs and NIMs, on the other hand, are sent within the Local Scope
where assuming a security relationship between senders and
is more practical
Handley, et al. Standards Track [Page 23]
RFC 2776 MZAP February 2000
In the case of NIMs, accepting unauthenticated messages can cause
false cancellation of nesting relationships. This would cause
section of the hierarchy of zones to flatten. Such a
would lessen the efficiency benefits afforded by the hierarchy
would not cause it to become unusable
Accepting unauthenticated ZAM messages, however, could
applications to believe that a scope zone exists when it does not
If these were believed, then applications may choose to use
non-existent administrative scope for their uses. Such
would be able to communicate successfully, but would be unaware
their traffic may be traveling further than they expected. As
result, any application accepting unauthenticated ZAMs MUST only
scope names as a guideline, and SHOULD assume that their traffic
to non-local scope zones might travel anywhere. The
of such traffic CANNOT be assumed from the fact that it was sent to
scoped address that was discovered using MZAP
In addition, ZAMs are used to inform Multicast Address
Servers (MAASs) of names and address ranges of scopes, and
unauthenticated ZAMs could result in false names being presented
users, and in wrong addresses being allocated to users. To
this, MAAS's authenticate ZAMs as follows
(1) A ZBR signs all ZAMs it originates (using an AH).
(2) A ZBR signs a ZAM it relays if and only if it can
the previous sender. A ZBR MUST still forward un-
ZAMs (to provide leak detection), but should propagate
authenticated ZAM even if an un-authenticated one was
with the last [ZAM-DUP-TIME] seconds
(3) A MAAS SHOULD be configured with the public key of the local
in which it resides. A MAAS thus configured SHOULD ignore
unauthenticated ZAM if an authenticated one for the same
has been received, and MAY ignore all unauthenticated ZAMs
9.
This document is a product of the MBone Deployment Working Group
whose members provided many helpful comments and suggestions,
Jacobson provided some of the original ideas that led to
protocol. The Multicast Address Allocation Working Group
provided useful feedback regarding scope names and interactions
applications
Handley, et al. Standards Track [Page 24]
RFC 2776 MZAP February 2000
10.
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
2365, July 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[3] Thaler, D., Handley, M. and D. Estrin, "The Internet
Address Allocation Architecture", Work in Progress
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
2279, January 1998.
[5] Fenner, W. and S. Casner, "A `traceroute' facility for
Multicast", Work in Progress
[6] Alvestrand, H., "Tags for the Identification of Languages",
1766, March 1995.
[7] Handley, M. and S. Hanna. "Multicast Address
Protocol (AAP)", Work in Progress
[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with
Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
Vancouver, Canada
[9] Hanna, S., Patel, B., and M. Shah. "Multicast Address
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[11] IANA, "Address Family Numbers", http://www.isi.edu/in
notes/iana/assignments/address-family-
[12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
Handley, et al. Standards Track [Page 25]
RFC 2776 MZAP February 2000
11. Authors'
Mark
AT&T Center for Internet Research at
1947 Center St, Suite 600
Berkely, CA 94704
EMail: mjh@aciri.
David
One Microsoft
Redmond, WA 98052
EMail: dthaler@microsoft.
Roger
Motorola Australian Research
12 Lord St
Botany, NSW 2019
EMail: Roger.Kermode@motorola.
Handley, et al. Standards Track [Page 26]
RFC 2776 MZAP February 2000
12. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Handley, et al. Standards Track [Page 27]
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
