As per Relevance of the word multicast, we have this rfc below:
Network Working Group J.
Request for Comments: 2443 Bay
Category: Experimental A.
November 1998
A Distributed MARS Service Using
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 (1998). All Rights Reserved
This document describes a method for distributing a MARS
within a LIS[1]. This method uses the Server Cache
Protocol (SCSP)[2] to synchronize the MARS Server databases within
LIS. When SCSP is used to synchronize the caches of MARS Servers
a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
1.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [5].
The MARS is an extended analog of the ATMARP Server introduced
[4]. It provides the necessary connection and addressing
required by layer 3 multicast services over ATM. There are
basic elements to the MARS model. First, the MARS Server
manages and distributes layer 3 group membership information to
LIS. Second, MARS Clients which register with and query a single
Server for layer 3 multicast information. Third, MCS Clients
register with a single MARS Server and provide layer 3
forwarding services for a LIS
Both MARS Clients and MCS Clients explicitly register with the
Server before exchanging layer 3 multicast information. During
registration process MARS Clients are place on the Cluster Control
Luciani & Gallo Experimental [Page 1]
RFC 2443 MARS Service Using SCSP November 1998
(CCVC) and MCS Clients are placed on the Server Control VC (SCVC).
Both the CCVC and SCVC are then used to propagate layer 3
updates to the clients which make up a LIS. During the
process MARS Clients are also assigned a unique Cluster Member
(CMI) which is used to identify reflected packets in the presence
MCS Clients
In the Distributed MARS Model there MAY be multiple MARS Servers in
given LIS, and since any MARS Server within the LIS MUST be able
provide layer 3 multicast information about any multicast
within the LIS, there MUST be a method by which to
multicast information across all MARS Servers within the LIS
The Server Cache Synchronization Protocol (SCSP) solves
generalized server synchronization/cache-replication problem
distributed databases, and thus SCSP MAY be applied to the
Server database synchronization problem within a LIS. When SCSP
used to synchronize the caches of MARS Servers in a LIS, the
defines the boundary of and SCSP Server Group (SG).
SCSP is defined in two parts: the protocol independent part and
client/server protocol specific part. The protocol independent
is specified in [2] whereas this document will specify
client/server protocol specific part where the MARS Server is
client/server protocol
2.
All MARS Servers belonging to a LIS are said to belong to a
Group (SG). A SG is identified by, not surprisingly, its SGID
is contained in a field in all SCSP packets. All SCSP packets
a Protocol ID (PID) field as well. This PID field is set to 0x0003
signify that SCSP is synchronizing MARS Server databases as
to synchronizing some other protocol's databases. (see
B.2.0.1 of [2] for more details). In general, PIDs for SCSP will
assigned by IANA upon request given that a client/server
specific specification has been written. In the case of MARS Servers
the client/server protocol specific specification was written at
same time as SCSP, and thus a PID=0x0003 was assigned in [2].
SCSP places no topological requirements upon a MARS Server SG
Obviously, however, the resultant graph of MARS Servers must span
set of MARS Servers being synchronized. For more information
the client/server protocol independent part of SCSP, the reader
encouraged to see [2].
Luciani & Gallo Experimental [Page 2]
RFC 2443 MARS Service Using SCSP November 1998
When a SG is using SCSP for synchronization, a MARS Client or
Client will register with only one MARS Server although it is
to choose any MARS Server in the SG for this registration.
registration time the MARS Client or MCS Client will be added to
MARS Servers respective CCVC or SCVC. Also, MARS Clients will
issued a unique CMI for the entire LIS. This document assumes at
minimum each MARS Server in the SG will be configured with a
range of CMIs to assign to clients registering with that MARS Server
Use of some external means for allocating CMIs to MARS Servers in
SG is possible but beyond the scope of this document
When a MARS Client or MCS Client successfully registers with a
Server in the SG that MARS Server will propagate the
information to its peer MARS Servers. The same propagation will
for any subsequent group membership information learned from
clients. The peer MARS Server will then update its group
database and propagate the information out its own CCVC or SCVC
needed
In the case of a MARS Server failure all peer MARS Servers in the
MUST flush the client/group membership information learned from
failed MARS Server. The clients belonging to the failed MARS
CCVC and SCVC will migrate to the next available MARS Server
specified in Section 5.3 of [1]. When a client detects a failure
its MARS, it steps to the next backup MARS Server and attempts
register with the server. If the registration is successful
client will re-join all of its previous group membership information
If the registration fails, the process repeats until a
MARS Server is found
Determining the operational state of a MARS Servers in a SG
that each MARS Server send out an "alive" or "heartbeat"
similar to the MARS Redirect message sent out on the CCVC or SCVC
MARS Clients. However, this message will only be sent to MARS
in the SG and is from here on defined as the MARS Server
Entry
In order to detect that a MARS Server failure has occurred
server MUST update it's MARS Server Redirect Entry state at
every 2 minutes, it is RECOMMENDED that it is updated every 1 minute
Failure to receive two consecutive MARS Server Redirect Entry
from a given MARS Server in the SG will cause all
information learned from this server to be flushed. The MARS
Redirect Entry state is also used to create the MARS_REDIRECT_
messages sent out on CCVC for each MARS Server in the SG.
ordering of each server learned will be based on the MARS
SCSP Sender ID. The ordering of the MARS_REDIRECT_MAP will
Luciani & Gallo Experimental [Page 3]
RFC 2443 MARS Service Using SCSP November 1998
contain the list of MARS Servers learned via MARS Server
Entry updates in ascending order based on the SCSP Sender ID
followed by any externally configured or learned backup MARS Servers
In the case of a MARS Client or MCS Client failure where the
is unexpectedly removed from the CCVC or SCVC the MARS Server
notify its peer SG members via a proxy deregister for that client
Upon receiving a proxy deregister request from a peer SG member
membership information for the deregistering client MUST be removed
Any Clients sending multicast data to the failed client should
receive an unexpected removal of this client which will intern
the sending client to revalidate the multicast groups
membership as outlined in Section 5.1.5.1 of [1].
3. Format of the CSA Record MARS Specific
CSA Records in SCSP contain a "Client/Server Protocol Specific Part
which contains the non-protocol independent information for a
server's cache entry
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardware
Defines the type of "link layer" addresses being carried.
value is the ATM Forum 'address family number' specified in [3]
15 decimal (0x000F). This is the mar$afn field defined in [1].
Luciani & Gallo Experimental [Page 4]
RFC 2443 MARS Service Using SCSP November 1998
Protocol
This field is the protocol type number for the protocol using
from [3]. (IPv4 is 0x0800). This is the mar$pro.type field
[1].
Protocol
This field is the optional protocol SNAP extension to
type. This is the mar$pro.snap field from [1].
Version
0 MARS Specific part of the CSA record
0x01 Reserved for NHRP
0x02 - 0xEF Reserved for future use by the IETF
0xF0 - 0xFE Allocated for use by the ATM Forum
0xFF Experimental/Local use
Version Number for this document MUST be set to 0x00.
1 MARS Server Redirect Entry
2 MCS Serve/Register request
3 MARS Client Join/Register request
4 MARS Client Leave/Deregister request
5 MCS Unserve/Deregister request
All other State values should cause the CSA to be discarded
The flags field is used to contain several flags and is similar
the mar$flags field from [1].
mar$
Bit 15 - mar$flags.layer3
Bit 13 - mar$flags.
Bit 0-7 - mar$flags.
All remaining bits are reserved and MUST be zero.
mars$flags.sequence field is of local significance only to
Local Server (LS).
Cluster Member
This field contains the CMI which uniquely identifies each
within a LIS. This is the mar$cmi field from [1].
Src Addr
This field contains the length of the Source Protocol
field. For IPv4, the value is 4 if an address is specified. A
(non-existent) address MUST be coded as zero length, and no
allocated for it in the message body. This is the mar$spln
from [1].
Luciani & Gallo Experimental [Page 5]
RFC 2443 MARS Service Using SCSP November 1998
Group Addr
This field contains the length of the Group Protocol Address field
For IPv4, the value is 4 if an address is specified. A null (non
existent) address MUST be coded as zero length, and no
allocated for it in the message body. This is the mar$tpln
from [1].
ATM Addr T/
This field contains the type and length of the Source ATM
field. The type and length encoding is described in Section 5.1.2
of [1].
ATM SubAddr T/
This field contains the type and length of the Source
SubAddress field. The type and length encoding is described
Section 5.1.2 of [1].
Source Protocol
This is the internetwork address for the source of an
binding in a MARS server cache entry. If null, no storage will
allocated. This is the mar$spa field from [1].
Source ATM
This is the Source's ATM address of an address binding in a
server cache entry. The address, if specified, is E.164 or
Forum NSAPA. This is the mar$sha field from [1].
Source ATM
This is the Source's ATM subaddress of an address binding in a
server cache entry. The subaddress, if specified, is an ATM
NSAPA. If null, no storage will be allocated. This is the mar$
field from [1].
Minimum Multicast Group
This is the internetwork address of the lower bound on the range
multicast group addresses for the address binding in a MARS
cache entry. If null, no storage will be allocated. This is
mar$min.N field from [1].
Maximum Multicast Group
This is the internetwork address of the upper bound on the range
multicast group addresses for the address binding in a MARS
cache entry. If null, no storage will be allocated. This is
mar$max.N field from [1].
Luciani & Gallo Experimental [Page 6]
RFC 2443 MARS Service Using SCSP November 1998
4. Values for SCSP Protocol Independent
The following sections give values for fields of the SCSP
Independent Part of the various SCSP messages
4.1 Values for the SCSP "Mandatory Common Part
Protocol ID = 0x0003
Sender ID Len = 0x04
Recvr ID Len = 0x04
See Section B.2.0.1 of [2] for a detailed description of
fields
4.2 Values for the SCSP "CSAS Record
Cache Key Len = 0x04
Orig ID Len = 0x04
See Section B.2.0.2 of [2] for a detailed description of
fields
5. Detailed State
5.1 MARS Server Redirect Entry
The MARS Server Redirect Entry is used to determine the
state of a MARS Server in the SG. Each server MUST update it's
Server Redirect Entry state at least every 2 minutes, it
RECOMMENDED that it is updated every 1 minute
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Luciani & Gallo Experimental [Page 7]
RFC 2443 MARS Service Using SCSP November 1998
Hardware
This value is the ATM Forum 'address family number' specified
[3] as 15 decimal (0x000F).
Protocol
This field is the protocol type number for the protocol using
from [3]. (IPv4 is 0x0800).
Protocol
This field is the optional protocol SNAP extension to
type. This is the mar$pro.snap field from [1].
Version
Version Number for this document MUST be set to 0x00.
State value is coded as 1 decimal for a MARS Server Redirect Entry
The Flags, Cluster Member ID, Src Addr Len, and Group Addr Len
are unused and set to zero
The ATM Addr T/L, ATM SubAddr T/L, Source ATM Address, and Source
SubAddress fields define the ATM address for the source of the
Server Redirect Entry in the SG. The coding for these fields are
same as described in Section 3 of this document
Failure to receive two consecutive MARS Server Redirect Entry
from a given MARS Server in the SG will cause all
information learned from this server to be flushed. When a valid
Server Redirect Entry update is received the source of this
will be placed into the table of backup MARS Servers sent in
MARS_REDIRECT_MAP message. The ordering of servers in
MARS_REDIRECT_MAP will first contain the list of MARS Servers
via MARS Server Redirect Entry updates in ascending order based
the SCSP Sender ID, followed by any externally configured or
backup MARS Servers. The format of the MARS_REDIRECT_MAP can be
in Section 5.4.3 of [1].
5.2 MCS Serve/Register request
The MCS Serve/Register request is used to propagate the
or servicing of specific groups by an MCS Client within the
domain. It is similar to an MARS_MSERV request defined in
6.2.2 and 6.2.3 of [1]. When a MARS Server in the SG
adds a new MCS Client to it's SCVC or adds MCS support for a
group it MUST send a MCS Serve/Register request to the SG. An
Client can only register with one MARS Server in the SG
Luciani & Gallo Experimental [Page 8]
RFC 2443 MARS Service Using SCSP November 1998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardware
This value is the ATM Forum 'address family number' specified
[3] as 15 decimal (0x000F).
Protocol
This field is the protocol type number for the protocol using
from [3]. (IPv4 is 0x0800).
Protocol
This field is the optional protocol SNAP extension to
type. This is the mar$pro.snap field from [1].
Version
Version Number for this document MUST be set to 0x00.
State value is coded as 2 decimal for a MCS Serve/Register request
The flags field is used to contain several flags
Luciani & Gallo Experimental [Page 9]
RFC 2443 MARS Service Using SCSP November 1998
mar$
Bit 15 - mar$flags.layer3
Bit 13 - mar$flags.
Bit 0-7 - mar$flags.
The mar$flags.register bit MUST be set the same as in
originating MARS_MSERV request. The mar$flags.layer3grp bit MUST
zero and the mar$flags.sequence bits are of local significance
to the LS
Cluster Member
This field contains the CMI assigned by the MARS Server
processed the MARS_MSERV request and uniquely identifies the
Client in the MARS server cache
Src Addr
This field contains the length of the Source Protocol
field. For IPv4, the value is 4 if an address is specified. A
(non-existent) address MUST be coded as zero length, and no
allocated for it in the message body
Group Addr
This field contains the length of the Group Protocol Address field
If the register bit in the flags field is set to 1 in the
this field MUST be zero. If the register bit is zero in the
field the value of this field for IPv4 is 4.
ATM Addr T/
This field contains the type and length of the Source ATM
field for the MCS Client that originated the MARS_MSERV request
The type and length encoding is described in Section 3.
ATM SubAddr T/
This field contains the type and length of the Source
SubAddress field for the MCS Client that originated the MARS_
request. The type and length encoding is described in Section 3.
Source Protocol
This is the internetwork address for the source of an
binding in a MARS server cache entry. If Src Addr Len is set
zero no storage will be allocated
Source ATM
This is the MCS Client's ATM address of an address binding in
MARS server cache entry. The address is E.164 or ATM Forum NSAPA
Luciani & Gallo Experimental [Page 10]
RFC 2443 MARS Service Using SCSP November 1998
Source ATM
This is the MCS Client's ATM subaddress of an address binding in
MARS server cache entry. The subaddress, if specified, is an
Forum NSAPA. If null, no storage will be allocated
Minimum Multicast Group
This is the internetwork address of the lower bound on the range
multicast group addresses for the address binding in a MARS
cache entry. If Group Addr Len is set to zero no storage will
allocated
Maximum Multicast Group
This is the internetwork address of the upper bound on the range
multicast group addresses for the address binding in a MARS
cache entry. If Group Addr Len is set to zero no storage will
allocated
An MCS Client can only register with one MARS Server in the SG and
only placed on the SCVC for the MARS Server for which it
registered with
When a MCS Client Serve/Register request specifying a group
is received by a MARS Server it MUST create a cache entry
with this client. In addition to adding the cache entry it MUST
out a MARS_MIGRATE message on it's CCVC. This is needed so
clients using a mesh topology can migrate to a server based topology
Details regarding the MARS_MIGRATE message can be found in
5.1.6 of [1].
5.3 MARS Client Join/Register request
The MARS Client Join/Register request is used to propagate
registering or joining of specific group ranges by MARS
within the SG domain. It is similar to the MARS_JOIN request
in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the
successfully registers a new MARS Client or a registered client
a specific group address range the MARS Server MUST send a
Client Join/Register request to the SG. A MARS Client can
register with one MARS Server in the SG and is placed only on
servers CCVC
Luciani & Gallo Experimental [Page 11]
RFC 2443 MARS Service Using SCSP November 1998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardware
This value is the ATM Forum 'address family number' specified
[3] as 15 decimal (0x000F).
Protocol
This field is the protocol type number for the protocol using
from [3]. (IPv4 is 0x0800).
Protocol
This field is the optional protocol SNAP extension to
type. This is the mar$pro.snap field from [1].
Version
Version Number for this document MUST be set to 0x00.
State value is coded as 3 decimal for a MARS Client Join/
request
Luciani & Gallo Experimental [Page 12]
RFC 2443 MARS Service Using SCSP November 1998
The flags field is used to contain several flags
mar$
Bit 15 - mar$flags.layer3
Bit 13 - mar$flags.
Bit 0-7 - mar$flags.
The mars$flags.layer3grp and mar$flags.register bits MUST be
the same as in the originating MARS_JOIN request.
mar$flags.sequence bits are of local significance only to the LS
Cluster Member
This field contains the CMI assigned by the MARS Server
processed the MARS_JOIN request and uniquely identifies the
Client in the MARS server cache
Src Addr
This field contains the length of the Source Protocol
field. For IPv4, the value is 4 if an address is specified. A
(non-existent) address MUST be coded as zero length, and no
allocated for it in the message body
Group Addr
This field contains the length of the Group Protocol Address field
If the register bit in the flags field is set to 1 in the
this field MUST be zero. If the register bit is zero in the
field the value of this field for IPv4 is 4.
ATM Addr T/
This field contains the type and length of the Source ATM
field for the MARS Client that originated the MARS_JOIN request
The type and length encoding is described in Section 3.
ATM SubAddr T/
This field contains the type and length of the Source
SubAddress field for the MARS Client that originated the MARS_
request. The type and length encoding is described in Section 3.
Source Protocol
This is the internetwork address for the source of an
binding in a MARS server cache entry. If Src Addr Len is set
zero no storage will be allocated
Source ATM
This is the MARS Client's ATM address of an address binding in
MARS server cache entry. The address is E.164 or ATM Forum NSAPA
Luciani & Gallo Experimental [Page 13]
RFC 2443 MARS Service Using SCSP November 1998
Source ATM
This is the MARS Client's ATM subaddress of an address binding in
MARS server cache entry. The subaddress, if specified, is an
Forum NSAPA. If null, no storage will be allocated
Minimum Multicast Group
This is the internetwork address of the lower bound on the range
multicast group addresses for the address binding in a MARS
cache entry. If Group Addr Len is set to zero no storage will
allocated
Maximum Multicast Group
This is the internetwork address of the upper bound on the range
multicast group addresses for the address binding in a MARS
cache entry. If Group Addr Len is set to zero no storage will
allocated
An MARS Client can only register with one MARS Server in the SG
is only placed on the CCVC for the MARS Server for which it
registered with. If the mar$flags.layer3grp is set to 1 than
Minimum and Maximum Multicast Group Addresses MUST be equal for IPv4.
When a MARS Client Join/Register request is sent with
mar$flags.register bit set to 1 all of the servers in the SG
create a cache entry for this client using the information in
request
When a registered MARS Client issues a MARS_JOIN for a specific
address range a MARS Client Join/Register request MUST be sent to
servers in the SG. The actions taken by each server in the SG
on previous group membership actions and MCS supported groups
Each MARS Server MUST perform the necessary redistribution and
punching algorithms before propagating this request to the CCVC
SCVC on each server. The redistribution and hole punching
used for propagating join requests to the CCVC are the same
defined in Sections 6.1.2 and 6.2.4 of [1]. If the
MARS_JOIN request is a duplicate of a previously joined range
contains no group address range than a MARS Client Join/Register
NOT be sent to the SG
The redistribution and hole punching algorithms used for
join requests as MARS_SJOIN request on a SCVC is the same as
6.2.4 except for the following. Only the MARS Servers which
the registered MCS Clients for the target group ranges
propagate this information to their SCVCs
Luciani & Gallo Experimental [Page 14]
RFC 2443 MARS Service Using SCSP November 1998
5.4 MARS Client Leave/Deregister request
The MARS Client Leave/Deregister request is used to propagate
deregistering or leaving of specific group ranges by registered
Clients within the SG domain. It is similar to the MARS_LEAVE
defined in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in
SG successfully deregisters a registered MARS Client or a
client leaves a specific group address range for which it had
the MARS Server MUST send a MARS Client Leave/Deregister request
the SG. If a registered MARS Client is unexpectedly removed from
CCVC the MARS Server MUST act as a proxy and send a MARS
Leave/Deregister request to the SG
The format and meanings of the fields in a MARS
Leave/Deregister request are the same as in Section 5.3 except
State is coded as 4 decimal for a MARS Client Leave/
request
When a MARS Client Leave/Deregister request is sent with
mar$flags.register bit set to 1 all of the servers in the
receiving this update MUST purge all cache entries for this client
When a registered MARS Client issues a MARS_LEAVE for a
group address range a MARS Client LEAVE/Deregister request MUST
sent to the servers in the SG. The actions taken by each server
the SG depend on previous group membership actions and MCS
groups
Each MARS Server MUST perform the necessary redistribution and
punching algorithms before propagating this request to the CCVC
SCVC on each server. The redistribution and hole punching
used for propagating leave requests to the CCVC are the same
defined in Sections 6.1.2 and 6.2.4 of [1]. If the
MARS_LEAVE request does not correspond to a previously joined
or contains no group address range than a MARS
Leave/Deregister MUST NOT be sent to the SG
The redistribution and hole punching algorithms used for
leave requests as MARS_SLEAVE requests on a SCVC is the same
Section 6.2.4 except for the following. Only the MARS Servers
contain the registered MCS Clients for the target group ranges
propagate this information to their SCVCs
5.5 MCS Unserve/Deregister request
The MCS Unserve/Deregister request is used to propagate
deregistering or unservicing of specific groups by a registered
Client within the SG domain. It is similar to an MARS_MUNSERV
Luciani & Gallo Experimental [Page 15]
RFC 2443 MARS Service Using SCSP November 1998
defined in Section 6.2.2 and 6.2.3 of [1]. When a MARS Server in
SG successfully deregisters a registered MCS Client or registered
Client stops serving a specific group address range for which it
serviced the MARS Server MUST send a MCS Unserve/Deregister
to the SG. If a registered MCS Client is unexpectedly removed
the SCVC the MARS Server owning the SCVC MUST act as a proxy and
a MCS Unserve/Deregister request to the SG
The format and meanings of the fields in a MCS Unserve/
request are the same as in Section 5.2 except the State is coded as 5
decimal for a MCS Unserve/Deregister request
When a MCS Client Unserve/Deregister request is sent with
mar$flags.register bit set to 1 all of the servers in the
receiving this update MUST purge all cache entries for this client
When a registered MCS Client issues a MARS_MUNSERV for a
group address range being served a MCS Client Unserve/
request MUST be sent to the servers in the SG. The members of the
that receive this update must then clear the cache entry
with this MCS Client
In addition to clearing one or more cache entries associated
receiving a MCS Client Unserve/Deregister request each MARS
in the SG MUST send out a MARS_LEAVE message on it's CCVC in
for clients to change back to a mesh topology
6. Security
There is no mechanism to encrypt the CSA Record MARS Specific Part
the message exchanged between servers. However, there are base
security features in the SCSP Protocol Independent part [2] which
be used to protect against attacks
Any SCSP MARS is susceptible to Denial of Service (DOS) attacks.
rouge MARS Client can inundate its Server with MARS packets. This
a base MARS problem as currently defined by [1]. A rouge host
also inundate its neighboring SCSP MARS with SCSP packets. However
if the authentication option is used, the SCSP MARS databases
not become corrupted, as the bogus packets will be discarded when
authentication check fails
Due to the pair wise authentication model of SCSP MARS,
information received from any properly authenticated server
trusted and propagated throughout the server group. Consequently,
security of any SCSP MARS server is compromised, the entire
becomes vulnerable to corruption originating from the
server
Luciani & Gallo Experimental [Page 16]
RFC 2443 MARS Service Using SCSP November 1998
[1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
Networks", RFC 2022, November 1996.
[2] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "
Cache Synchronization Protocol", RFC 2334, April 1998.
[3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.
[4] Laubach, M., "Classic IP and ARP over ATM", RFC 1577,
1994.
[5] Bradner, S., "Key Words for use in RFCs to Indicate
Levels," BCP 14, RFC 2119, March 1997.
The authors would like to thank Grenville Armitage for his
distributed MARS work and also the members of the ION working
of the IETF, whose review and discussion of this document has
invaluable
Authors'
James V.
Bay Networks, Inc
3 Federal Street, BL3-04
Billerica, MA 01821
Phone: +1-508-916-4734
EMail: luciani@baynetworks.
Anthony M.
IBM, Networking Hardware
Dept. M6LA/B664
P.O. Box 12195
Research Triangle Park, NC 27709
Phone: +1-919-254-9889
EMail: gallo@raleigh.ibm.
Luciani & Gallo Experimental [Page 17]
RFC 2443 MARS Service Using SCSP November 1998
Full Copyright
Copyright (C) The Internet Society (1998). 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
Luciani & Gallo Experimental [Page 18]
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
