diff options
Diffstat (limited to 'doc/rfc/rfc2443.txt')
| -rw-r--r-- | doc/rfc/rfc2443.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc2443.txt b/doc/rfc/rfc2443.txt new file mode 100644 index 0000000..da0934d --- /dev/null +++ b/doc/rfc/rfc2443.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group J. Luciani +Request for Comments: 2443 Bay Networks +Category: Experimental A. Gallo + IBM + November 1998 + + + A Distributed MARS Service Using SCSP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document describes a method for distributing a MARS service + within a LIS[1]. This method uses the Server Cache Synchronization + Protocol (SCSP)[2] to synchronize the MARS Server databases within a + LIS. When SCSP is used to synchronize the caches of MARS Servers in + a LIS, the LIS defines the boundary of an SCSP Server Group (SG). + +1. Introduction + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [5]. + + The MARS is an extended analog of the ATMARP Server introduced in + [4]. It provides the necessary connection and addressing services + required by layer 3 multicast services over ATM. There are three + basic elements to the MARS model. First, the MARS Server which + manages and distributes layer 3 group membership information to the + LIS. Second, MARS Clients which register with and query a single MARS + Server for layer 3 multicast information. Third, MCS Clients which + register with a single MARS Server and provide layer 3 multicast + forwarding services for a LIS. + + Both MARS Clients and MCS Clients explicitly register with the MARS + Server before exchanging layer 3 multicast information. During the + registration process MARS Clients are place on the Cluster Control VC + + + +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 multicast + updates to the clients which make up a LIS. During the registration + process MARS Clients are also assigned a unique Cluster Member ID + (CMI) which is used to identify reflected packets in the presence of + MCS Clients. + + In the Distributed MARS Model there MAY be multiple MARS Servers in a + given LIS, and since any MARS Server within the LIS MUST be able to + provide layer 3 multicast information about any multicast group + within the LIS, there MUST be a method by which to synchronize + multicast information across all MARS Servers within the LIS. + + The Server Cache Synchronization Protocol (SCSP) solves the + generalized server synchronization/cache-replication problem for + distributed databases, and thus SCSP MAY be applied to the MARS + Server database synchronization problem within a LIS. When SCSP is + used to synchronize the caches of MARS Servers in a LIS, the LIS + defines the boundary of and SCSP Server Group (SG). + + SCSP is defined in two parts: the protocol independent part and the + client/server protocol specific part. The protocol independent part + is specified in [2] whereas this document will specify the + client/server protocol specific part where the MARS Server is the + client/server protocol. + +2. Overview + + All MARS Servers belonging to a LIS are said to belong to a Server + Group (SG). A SG is identified by, not surprisingly, its SGID which + is contained in a field in all SCSP packets. All SCSP packets contain + a Protocol ID (PID) field as well. This PID field is set to 0x0003 to + signify that SCSP is synchronizing MARS Server databases as opposed + to synchronizing some other protocol's databases. (see Section + B.2.0.1 of [2] for more details). In general, PIDs for SCSP will be + assigned by IANA upon request given that a client/server protocol + specific specification has been written. In the case of MARS Servers, + the client/server protocol specific specification was written at the + 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 the + set of MARS Servers being synchronized. For more information about + the client/server protocol independent part of SCSP, the reader is + 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 MCS + Client will register with only one MARS Server although it is allowed + to choose any MARS Server in the SG for this registration. At + registration time the MARS Client or MCS Client will be added to that + MARS Servers respective CCVC or SCVC. Also, MARS Clients will be + issued a unique CMI for the entire LIS. This document assumes at a + minimum each MARS Server in the SG will be configured with a unique + range of CMIs to assign to clients registering with that MARS Server. + Use of some external means for allocating CMIs to MARS Servers in a + SG is possible but beyond the scope of this document. + + When a MARS Client or MCS Client successfully registers with a MARS + Server in the SG that MARS Server will propagate the registration + information to its peer MARS Servers. The same propagation will occur + for any subsequent group membership information learned from the + clients. The peer MARS Server will then update its group membership + database and propagate the information out its own CCVC or SCVC if + needed. + + In the case of a MARS Server failure all peer MARS Servers in the SG + MUST flush the client/group membership information learned from the + failed MARS Server. The clients belonging to the failed MARS Servers + CCVC and SCVC will migrate to the next available MARS Server as + specified in Section 5.3 of [1]. When a client detects a failure of + its MARS, it steps to the next backup MARS Server and attempts to + register with the server. If the registration is successful the + client will re-join all of its previous group membership information. + If the registration fails, the process repeats until a functional + MARS Server is found. + + Determining the operational state of a MARS Servers in a SG requires + that each MARS Server send out an "alive" or "heartbeat" message + similar to the MARS Redirect message sent out on the CCVC or SCVC for + MARS Clients. However, this message will only be sent to MARS Servers + in the SG and is from here on defined as the MARS Server Redirect + Entry. + + In order to detect that a MARS Server failure has occurred each + server MUST update it's MARS Server Redirect Entry state at least + every 2 minutes, it is RECOMMENDED that it is updated every 1 minute. + Failure to receive two consecutive MARS Server Redirect Entry updates + from a given MARS Server in the SG will cause all membership + information learned from this server to be flushed. The MARS Server + Redirect Entry state is also used to create the MARS_REDIRECT_MAP + messages sent out on CCVC for each MARS Server in the SG. The + ordering of each server learned will be based on the MARS Servers + SCSP Sender ID. The ordering of the MARS_REDIRECT_MAP will first + + + + +Luciani & Gallo Experimental [Page 3] + +RFC 2443 MARS Service Using SCSP November 1998 + + + contain the list of MARS Servers learned via MARS Server Redirect + 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 client + is unexpectedly removed from the CCVC or SCVC the MARS Server MUST + notify its peer SG members via a proxy deregister for that client. + Upon receiving a proxy deregister request from a peer SG member all + membership information for the deregistering client MUST be removed. + Any Clients sending multicast data to the failed client should also + receive an unexpected removal of this client which will intern cause + the sending client to revalidate the multicast groups current + membership as outlined in Section 5.1.5.1 of [1]. + +3. Format of the CSA Record MARS Specific Part + + CSA Records in SCSP contain a "Client/Server Protocol Specific Part" + which contains the non-protocol independent information for a given + 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 Type + Defines the type of "link layer" addresses being carried. This + value is the ATM Forum 'address family number' specified in [3] as + 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 Type + This field is the protocol type number for the protocol using MARS + from [3]. (IPv4 is 0x0800). This is the mar$pro.type field from + [1]. + + Protocol SNAP + This field is the optional protocol SNAP extension to protocol + type. This is the mar$pro.snap field from [1]. + + Version Number + 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. + + State + 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. + + Flags + The flags field is used to contain several flags and is similar to + the mar$flags field from [1]. + mar$flags + Bit 15 - mar$flags.layer3grp + Bit 13 - mar$flags.register + Bit 0-7 - mar$flags.sequence + + All remaining bits are reserved and MUST be zero. The + mars$flags.sequence field is of local significance only to the + Local Server (LS). + + Cluster Member CMI + This field contains the CMI which uniquely identifies each endpoint + within a LIS. This is the mar$cmi field from [1]. + + Src Addr Len + This field contains the length of the Source 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 space + allocated for it in the message body. This is the mar$spln field + from [1]. + + + +Luciani & Gallo Experimental [Page 5] + +RFC 2443 MARS Service Using SCSP November 1998 + + + Group Addr Len + 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 space + allocated for it in the message body. This is the mar$tpln field + from [1]. + + ATM Addr T/L + This field contains the type and length of the Source ATM Address + field. The type and length encoding is described in Section 5.1.2 + of [1]. + + ATM SubAddr T/L + This field contains the type and length of the Source ATM + SubAddress field. The type and length encoding is described in + Section 5.1.2 of [1]. + + Source Protocol Address + This is the internetwork address for the source of an address + binding in a MARS server cache entry. If null, no storage will be + allocated. This is the mar$spa field from [1]. + + Source ATM Address + This is the Source's ATM address of an address binding in a MARS + server cache entry. The address, if specified, is E.164 or ATM + Forum NSAPA. This is the mar$sha field from [1]. + + Source ATM SubAddress + This is the Source's ATM subaddress of an address binding in a MARS + server cache entry. The subaddress, if specified, is an ATM Forum + NSAPA. If null, no storage will be allocated. This is the mar$ssa + field from [1]. + + Minimum Multicast Group Address + This is the internetwork address of the lower bound on the range of + multicast group addresses for the address binding in a MARS server + cache entry. If null, no storage will be allocated. This is the + mar$min.N field from [1]. + + Maximum Multicast Group Address + This is the internetwork address of the upper bound on the range of + multicast group addresses for the address binding in a MARS server + cache entry. If null, no storage will be allocated. This is the + 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 Part + + The following sections give values for fields of the SCSP Protocol + 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 these + 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 these + fields. + +5. Detailed State Descriptions + +5.1 MARS Server Redirect Entry. + + The MARS Server Redirect Entry is used to determine the operational + state of a MARS Server in the SG. Each server MUST update it's MARS + Server Redirect Entry state at least every 2 minutes, it is + 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 Type + This value is the ATM Forum 'address family number' specified in + [3] as 15 decimal (0x000F). + + Protocol Type + This field is the protocol type number for the protocol using MARS + from [3]. (IPv4 is 0x0800). + + Protocol SNAP + This field is the optional protocol SNAP extension to protocol + type. This is the mar$pro.snap field from [1]. + + Version Number + Version Number for this document MUST be set to 0x00. + + State + 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 fields + are unused and set to zero. + + The ATM Addr T/L, ATM SubAddr T/L, Source ATM Address, and Source ATM + SubAddress fields define the ATM address for the source of the MARS + Server Redirect Entry in the SG. The coding for these fields are the + same as described in Section 3 of this document. + + Failure to receive two consecutive MARS Server Redirect Entry updates + from a given MARS Server in the SG will cause all membership + information learned from this server to be flushed. When a valid MARS + Server Redirect Entry update is received the source of this update + will be placed into the table of backup MARS Servers sent in the + MARS_REDIRECT_MAP message. The ordering of servers in the + MARS_REDIRECT_MAP will first contain the list of MARS Servers learned + via MARS Server Redirect Entry updates in ascending order based on + the SCSP Sender ID, followed by any externally configured or learned + backup MARS Servers. The format of the MARS_REDIRECT_MAP can be found + in Section 5.4.3 of [1]. + +5.2 MCS Serve/Register request. + + The MCS Serve/Register request is used to propagate the registering + or servicing of specific groups by an MCS Client within the SG + domain. It is similar to an MARS_MSERV request defined in Section + 6.2.2 and 6.2.3 of [1]. When a MARS Server in the SG successfully + adds a new MCS Client to it's SCVC or adds MCS support for a specific + group it MUST send a MCS Serve/Register request to the SG. An MCS + 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 Type + This value is the ATM Forum 'address family number' specified in + [3] as 15 decimal (0x000F). + + Protocol Type + This field is the protocol type number for the protocol using MARS + from [3]. (IPv4 is 0x0800). + + Protocol SNAP + This field is the optional protocol SNAP extension to protocol + type. This is the mar$pro.snap field from [1]. + + Version Number + Version Number for this document MUST be set to 0x00. + + State + State value is coded as 2 decimal for a MCS Serve/Register request. + + Flags + The flags field is used to contain several flags: + + + + + + + +Luciani & Gallo Experimental [Page 9] + +RFC 2443 MARS Service Using SCSP November 1998 + + + mar$flags + Bit 15 - mar$flags.layer3grp + Bit 13 - mar$flags.register + Bit 0-7 - mar$flags.sequence + + The mar$flags.register bit MUST be set the same as in the + originating MARS_MSERV request. The mar$flags.layer3grp bit MUST be + zero and the mar$flags.sequence bits are of local significance only + to the LS. + + Cluster Member CMI + This field contains the CMI assigned by the MARS Server which + processed the MARS_MSERV request and uniquely identifies the MCS + Client in the MARS server cache. + + Src Addr Len + This field contains the length of the Source 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 space + allocated for it in the message body. + + Group Addr Len + 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 request + this field MUST be zero. If the register bit is zero in the flags + field the value of this field for IPv4 is 4. + + ATM Addr T/L + This field contains the type and length of the Source ATM Address + field for the MCS Client that originated the MARS_MSERV request. + The type and length encoding is described in Section 3. + + ATM SubAddr T/L + This field contains the type and length of the Source ATM + SubAddress field for the MCS Client that originated the MARS_MSERV + request. The type and length encoding is described in Section 3. + + Source Protocol Address + This is the internetwork address for the source of an address + binding in a MARS server cache entry. If Src Addr Len is set to + zero no storage will be allocated. + + Source ATM Address + This is the MCS Client's ATM address of an address binding in a + 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 SubAddress + This is the MCS Client's ATM subaddress of an address binding in a + MARS server cache entry. The subaddress, if specified, is an ATM + Forum NSAPA. If null, no storage will be allocated. + + Minimum Multicast Group Address + This is the internetwork address of the lower bound on the range of + multicast group addresses for the address binding in a MARS server + cache entry. If Group Addr Len is set to zero no storage will be + allocated. + + Maximum Multicast Group Address + This is the internetwork address of the upper bound on the range of + multicast group addresses for the address binding in a MARS server + cache entry. If Group Addr Len is set to zero no storage will be + allocated. + + An MCS Client can only register with one MARS Server in the SG and is + only placed on the SCVC for the MARS Server for which it is + registered with. + + When a MCS Client Serve/Register request specifying a group address + is received by a MARS Server it MUST create a cache entry associated + with this client. In addition to adding the cache entry it MUST send + out a MARS_MIGRATE message on it's CCVC. This is needed so that + clients using a mesh topology can migrate to a server based topology. + Details regarding the MARS_MIGRATE message can be found in Section + 5.1.6 of [1]. + +5.3 MARS Client Join/Register request. + + The MARS Client Join/Register request is used to propagate the + registering or joining of specific group ranges by MARS Clients + within the SG domain. It is similar to the MARS_JOIN request defined + in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the SG + successfully registers a new MARS Client or a registered client joins + a specific group address range the MARS Server MUST send a MARS + Client Join/Register request to the SG. A MARS Client can only + register with one MARS Server in the SG and is placed only on that + 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 Type + This value is the ATM Forum 'address family number' specified in + [3] as 15 decimal (0x000F). + + Protocol Type + This field is the protocol type number for the protocol using MARS + from [3]. (IPv4 is 0x0800). + + Protocol SNAP + This field is the optional protocol SNAP extension to protocol + type. This is the mar$pro.snap field from [1]. + + Version Number + Version Number for this document MUST be set to 0x00. + + State + State value is coded as 3 decimal for a MARS Client Join/Register + request. + + + + + + + + + +Luciani & Gallo Experimental [Page 12] + +RFC 2443 MARS Service Using SCSP November 1998 + + + Flags + The flags field is used to contain several flags: + + mar$flags + Bit 15 - mar$flags.layer3grp + Bit 13 - mar$flags.register + Bit 0-7 - mar$flags.sequence + + The mars$flags.layer3grp and mar$flags.register bits MUST be set + the same as in the originating MARS_JOIN request. The + mar$flags.sequence bits are of local significance only to the LS. + + Cluster Member CMI + This field contains the CMI assigned by the MARS Server which + processed the MARS_JOIN request and uniquely identifies the MARS + Client in the MARS server cache. + + Src Addr Len + This field contains the length of the Source 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 space + allocated for it in the message body. + + Group Addr Len + 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 request + this field MUST be zero. If the register bit is zero in the flags + field the value of this field for IPv4 is 4. + + ATM Addr T/L + This field contains the type and length of the Source ATM Address + field for the MARS Client that originated the MARS_JOIN request. + The type and length encoding is described in Section 3. + + ATM SubAddr T/L + This field contains the type and length of the Source ATM + SubAddress field for the MARS Client that originated the MARS_JOIN + request. The type and length encoding is described in Section 3. + + Source Protocol Address + This is the internetwork address for the source of an address + binding in a MARS server cache entry. If Src Addr Len is set to + zero no storage will be allocated. + + Source ATM Address + This is the MARS Client's ATM address of an address binding in a + 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 SubAddress + This is the MARS Client's ATM subaddress of an address binding in a + MARS server cache entry. The subaddress, if specified, is an ATM + Forum NSAPA. If null, no storage will be allocated. + + Minimum Multicast Group Address + This is the internetwork address of the lower bound on the range of + multicast group addresses for the address binding in a MARS server + cache entry. If Group Addr Len is set to zero no storage will be + allocated. + + Maximum Multicast Group Address + This is the internetwork address of the upper bound on the range of + multicast group addresses for the address binding in a MARS server + cache entry. If Group Addr Len is set to zero no storage will be + allocated. + + An MARS Client can only register with one MARS Server in the SG and + is only placed on the CCVC for the MARS Server for which it is + registered with. If the mar$flags.layer3grp is set to 1 than the + Minimum and Maximum Multicast Group Addresses MUST be equal for IPv4. + + When a MARS Client Join/Register request is sent with the + mar$flags.register bit set to 1 all of the servers in the SG will + create a cache entry for this client using the information in the + request. + + When a registered MARS Client issues a MARS_JOIN for a specific group + address range a MARS Client Join/Register request MUST be sent to the + servers in the SG. The actions taken by each server in the SG depend + on previous group membership actions and MCS supported groups. + + Each MARS Server MUST perform the necessary redistribution and hole + punching algorithms before propagating this request to the CCVC and + SCVC on each server. The redistribution and hole punching algorithms + used for propagating join requests to the CCVC are the same as + defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating + MARS_JOIN request is a duplicate of a previously joined range or + contains no group address range than a MARS Client Join/Register MUST + NOT be sent to the SG. + + The redistribution and hole punching algorithms used for propagating + join requests as MARS_SJOIN request on a SCVC is the same as Section + 6.2.4 except for the following. Only the MARS Servers which contain + the registered MCS Clients for the target group ranges should + 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 the + deregistering or leaving of specific group ranges by registered MARS + Clients within the SG domain. It is similar to the MARS_LEAVE request + defined in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the + SG successfully deregisters a registered MARS Client or a registered + client leaves a specific group address range for which it had joined + the MARS Server MUST send a MARS Client Leave/Deregister request to + the SG. If a registered MARS Client is unexpectedly removed from the + CCVC the MARS Server MUST act as a proxy and send a MARS Client + Leave/Deregister request to the SG. + + The format and meanings of the fields in a MARS Client + Leave/Deregister request are the same as in Section 5.3 except the + State is coded as 4 decimal for a MARS Client Leave/Deregister + request. + + When a MARS Client Leave/Deregister request is sent with the + mar$flags.register bit set to 1 all of the servers in the SG + receiving this update MUST purge all cache entries for this client. + + When a registered MARS Client issues a MARS_LEAVE for a specific + group address range a MARS Client LEAVE/Deregister request MUST be + sent to the servers in the SG. The actions taken by each server in + the SG depend on previous group membership actions and MCS supported + groups. + + Each MARS Server MUST perform the necessary redistribution and hole + punching algorithms before propagating this request to the CCVC and + SCVC on each server. The redistribution and hole punching algorithms + used for propagating leave requests to the CCVC are the same as + defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating + MARS_LEAVE request does not correspond to a previously joined range + or contains no group address range than a MARS Client + Leave/Deregister MUST NOT be sent to the SG. + + The redistribution and hole punching algorithms used for propagating + leave requests as MARS_SLEAVE requests on a SCVC is the same as + Section 6.2.4 except for the following. Only the MARS Servers which + contain the registered MCS Clients for the target group ranges should + propagate this information to their SCVCs. + +5.5 MCS Unserve/Deregister request. + + The MCS Unserve/Deregister request is used to propagate the + deregistering or unservicing of specific groups by a registered MCS + Client within the SG domain. It is similar to an MARS_MUNSERV request + + + +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 the + SG successfully deregisters a registered MCS Client or registered MCS + Client stops serving a specific group address range for which it had + serviced the MARS Server MUST send a MCS Unserve/Deregister request + to the SG. If a registered MCS Client is unexpectedly removed from + the SCVC the MARS Server owning the SCVC MUST act as a proxy and send + a MCS Unserve/Deregister request to the SG. + + The format and meanings of the fields in a MCS Unserve/Deregister + 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 the + mar$flags.register bit set to 1 all of the servers in the SG + receiving this update MUST purge all cache entries for this client. + + When a registered MCS Client issues a MARS_MUNSERV for a specific + group address range being served a MCS Client Unserve/Deregister + request MUST be sent to the servers in the SG. The members of the SG + that receive this update must then clear the cache entry associated + with this MCS Client. + + In addition to clearing one or more cache entries associated with + receiving a MCS Client Unserve/Deregister request each MARS Server + in the SG MUST send out a MARS_LEAVE message on it's CCVC in order + for clients to change back to a mesh topology. + +6. Security Considerations + + There is no mechanism to encrypt the CSA Record MARS Specific Part of + the message exchanged between servers. However, there are base SCSP + security features in the SCSP Protocol Independent part [2] which can + be used to protect against attacks. + + Any SCSP MARS is susceptible to Denial of Service (DOS) attacks. A + rouge MARS Client can inundate its Server with MARS packets. This is + a base MARS problem as currently defined by [1]. A rouge host can + also inundate its neighboring SCSP MARS with SCSP packets. However, + if the authentication option is used, the SCSP MARS databases will + not become corrupted, as the bogus packets will be discarded when the + authentication check fails. + + Due to the pair wise authentication model of SCSP MARS, the + information received from any properly authenticated server is + trusted and propagated throughout the server group. Consequently, if + security of any SCSP MARS server is compromised, the entire database + becomes vulnerable to corruption originating from the compromised + server. + + + +Luciani & Gallo Experimental [Page 16] + +RFC 2443 MARS Service Using SCSP November 1998 + + +References + + [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM + Networks", RFC 2022, November 1996. + + [2] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server + 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.html + + [4] Laubach, M., "Classic IP and ARP over ATM", RFC 1577, January + 1994. + + [5] Bradner, S., "Key Words for use in RFCs to Indicate Requirement + Levels," BCP 14, RFC 2119, March 1997. + +Acknowledgments + + The authors would like to thank Grenville Armitage for his previous + distributed MARS work and also the members of the ION working group + of the IETF, whose review and discussion of this document has been + invaluable. + +Authors' Addresses + + James V. Luciani + Bay Networks, Inc. + 3 Federal Street, BL3-04 + Billerica, MA 01821 + + Phone: +1-508-916-4734 + EMail: luciani@baynetworks.com + + + Anthony M. Gallo + IBM, Networking Hardware Division + Dept. M6LA/B664 + P.O. Box 12195 + Research Triangle Park, NC 27709 + + Phone: +1-919-254-9889 + EMail: gallo@raleigh.ibm.com + + + + + + + + +Luciani & Gallo Experimental [Page 17] + +RFC 2443 MARS Service Using SCSP November 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Luciani & Gallo Experimental [Page 18] + |