HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 03:27:05 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 25 Jul 1997 14:55:00 GMT ETag: "2edce2-4062-33d8be44" Accept-Ranges: bytes Content-Length: 16482 Connection: close Content-Type: text/plain Internetworking Over NBMA James V. Luciani INTERNET-DRAFT (Bay Networks) Anthony M. Gallo (IBM) Expires December 1997 A Distributed MARS Service Using SCSP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 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 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 (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. In [5] several distributed MARS models are discussed along with various trade offs of each. The document provides a description of the problems that need to be addressed from the MARS protocol's point of view in a distributed system. 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 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]. 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 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]. 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 Register request. 3 MARS Client Join/Register request. 4 MARS Client Leave/Deregister request. 5 MCS Deregister request. 6 MCS Join request. 7 MCS Leave request. All other State values should cause the CSA to be discarded. 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-existant) 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]. 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- existant) 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 encodings are 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 encodings are described in Section 5.1.2 of [1]. Flags Th 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]. 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. 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. This is the mar$max.N field from [1]. 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 (Under Construction) 5.1 MARS Server Redirect Entry. TBD.... 5.2 MCS Register request. TBD.... 5.3 MARS Client Join/Register request. TBD.... 5.4 MARS Client Leave/Deregister request. TBD.... 5.5 MCS Deregister request. TBD.... 5.6 MCS Join request. TBD.... 5.7 MCS Leave request. TBD.... 6. Security Consideration Security is not addressed in this document but is addressed in the SCSP Protocol Independent part [2]. References [1] "Support for Multicast over UNI 3.0/3.1 based ATM Networks", Armitage, RFC2022. [2] "Server Cache Synchronization Protocol", Luciani, Armitage, Halpern, draft-ietf-ion-scsp-01.txt. [3] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. [4] "Classic IP and ARP over ATM", Mark Laubach, RFC 1577. [5] "Redundant MARS architectures and SCSP, Armitage, draft-armitage-ion-mars-scsp-03.txt. 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. Author's Address 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@raliegh.ibm.com