home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ion-marsmcs-01.txt < prev    next >
Text File  |  1996-11-19  |  41KB  |  1,056 lines
  1.  
  2. Internet Engineering Task Force                            Talpade and Ammar
  3. INTERNET-DRAFT                               Georgia Institute of Technology
  4.                                                            November 18, 1996
  5.  
  6.                                                          Expires:  May, 1996
  7.  
  8.  
  9.                       <draft-ietf-ion-marsmcs-01.txt>
  10.       Multicast Server Architectures for MARS-based ATM multicasting.
  11.  
  12.  
  13. Status of this Memo
  14.  
  15. This document is an Internet-Draft.  Internet-Drafts are working documents
  16. of the Internet Engineering Task Force (IETF), its areas, and its working
  17. groups.  Note that other groups may also distribute working documents as
  18. Internet-Drafts.
  19.  
  20. Internet-Drafts are draft documents valid for a maximum of six months and
  21. may be updated, replaced, or obsoleted by other documents at any time.  It
  22. is inappropriate to use Internet- Drafts as reference material or to cite
  23. them other than as ``work in progress.''
  24.  
  25. To learn the current status of any Internet-Draft, please check the
  26. ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
  27. Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  28. ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  29.  
  30.  
  31.  
  32.  
  33.                                   Abstract
  34.  
  35.  
  36. A mechanism to support the multicast needs of layer 3 protocols in general,
  37. and IP in particular, over UNI 3.0/3.1 based ATM networks has been
  38. described in RFC 2022.  Two basic approaches exist for the intra-subnet
  39. (intra-cluster) multicasting of IP packets.  One makes use of a mesh of
  40. point to multipoint VCs (the 'VC Mesh' approach), while the other uses a
  41. shared point to multipoint tree rooted on a Multicast Server (MCS). This
  42. memo provides details on the design and implementation of an MCS, building
  43. on the core mechanisms defined in RFC 2022.  It also provides a mechanism
  44. for using multiple MCSs per group for providing fault tolerance.  This
  45. approach can be used with RFC 2022 based MARS server and clients, without
  46. needing any change in their functionality.
  47.  
  48.  
  49.  
  50. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. 1 Introduction
  58.  
  59. A solution to the problem of mapping layer 3 multicast service over the
  60. connection-oriented ATM service provided by UNI 3.0/3.1, has been presented
  61. in [GA96].  A Multicast Address Resolution Server (MARS) is used to
  62. maintain a mapping of layer 3 group addresses to ATM addresses in that
  63. architecture.  It can be considered to be an extended analog of the ATM ARP
  64. Server introduced in RFC 1577 ([ML93]).  Hosts in the ATM network use the
  65. MARS to resolve layer 3 multicast addresses into corresponding lists of ATM
  66. addresses of group members.  Hosts keep the MARS informed when they need to
  67. join or leave a particular layer 3 group.
  68.  
  69. The MARS manages a "cluster" of ATM-attached endpoints.  A "cluster" is
  70. defined as
  71.  
  72. "The set of ATM interfaces choosing to participate in direct ATM
  73. connections to achieve multicasting of AALSDUs between themselves."
  74.  
  75. In practice, a cluster is the set of endpoints that choose to use the same
  76. MARS to register their memberships and receive their updates from.
  77.  
  78. A sender in the cluster has two options for multicasting data to the group
  79. members.  It can either get the list of ATM addresses constituting the
  80. group from the MARS, set up a point-to-multipoint virtual circuit (VC) with
  81. the group members as leaves, and then proceed to send data out on it.
  82. Alternatively, the source can make use of a proxy Multicast Server (MCS).
  83. The source transmits data to such an MCS, which in turn uses a
  84. point-to-multipoint VC to get the data to the group members.
  85.  
  86. The MCS approach has been briefly introduced in [GA96].  This memo presents
  87. a detailed description of MCS architecture and proposes a simple mechanism
  88. for supporting multiple MCSs for fault tolerance.  We assume an
  89. understanding of the IP multicasting over UNI 3.0/3.1 ATM network concepts
  90. described in [GA96], and access to it.  This document is organized as
  91. follows.  Section 2 presents interactions with the local UNI 3.0/3.1
  92. signaling entity that are used later in the document and have been
  93. originally described in [GA96].  Section 3 presents an MCS architecture,
  94. along with a description of its interactions with the MARS. Section 4
  95. describes the working of an MCS. The possibility of using multiple MCSs for
  96. the same layer 3 group, and the mechanism needed to support such usage, is
  97. described in section 5.  A comparison of the VC Mesh approach and the MCS
  98.  
  99.  
  100.  
  101.  
  102. Talpade and Ammar                                                   [Page 2]
  103.  
  104.  
  105.  
  106. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  107.  
  108.  
  109. approach is presented in Appendix A.
  110.  
  111.  
  112.  
  113.  
  114. 2 Interaction with the local UNI 3.0/3.1 signaling entity
  115.  
  116. The following generic signaling functions are presumed to be available to
  117. local AAL Users:
  118.  
  119. LCALL-RQ - Establish a unicast VC to a specific endpoint.
  120. LMULTI-RQ - Establish multicast VC to a specific endpoint.
  121. LMULTI-ADD - Add new leaf node to previously established VC.
  122. LMULTI-DROP - Remove specific leaf node from established VC.
  123. LRELEASE - Release unicast VC, or all Leaves of a multicast VC.
  124.  
  125. The following indications are assumed to be available to AAL Users,
  126. generated by by the local UNI 3.0/3.1 signaling entity:
  127.  
  128. LACK - Succesful completion of a local request.
  129. LREMOTE-CALL - A new VC has been established to the AAL User.
  130. ERRL-RQFAILED - A remote ATM endpoint rejected an LCALLRQ,
  131.                       LMULTIRQ, or L-MULTIADD.
  132. ERRL-DROP - A remote ATM endpoint dropped off an existing VC.
  133. ERRL-RELEASE - An existing VC was terminated.
  134.  
  135.  
  136.  
  137. 3 MCS Architecture
  138.  
  139. The MCS acts as a proxy server which multicasts data received from a source
  140. to the group members in the cluster.  All multicast sources transmitting to
  141. an MCS-based group send the data to the specified MCS. The MCS then
  142. forwards the data over a point to multipoint VC that it maintains to group
  143. members in the cluster.  Each multicast source thus maintains a single
  144. point-to-multipoint VC to the designated MCS for the group.  The designated
  145. MCS terminates one point-to-multipoint VC from each cluster member that is
  146. multicasting to the layer 3 group.  Each group member is the leaf of the
  147. point-to-multipoint VC originating from the MCS.
  148.  
  149. A brief introduction to possible MCS architectures has been presented in
  150. [GA96].  The main contribution of that document concerning the MCS approach
  151. is the specification of the MARS interaction with the MCS. The next section
  152. lists control messages exchanged by the MARS and MCS.
  153.  
  154.  
  155.  
  156.  
  157.  
  158. Talpade and Ammar                                                   [Page 3]
  159.  
  160.  
  161.  
  162. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  163.  
  164.  
  165. 3.1 Control Messages exchanged by the MCS and the MARS
  166.  
  167. The following control messages are exchanged by the MARS and the MCS.
  168.  
  169.  
  170. operation code                Control Message
  171.  
  172.       1                       MARS_REQUEST
  173.       2                       MARS_MULTI
  174.       3                       MARS_MSERV
  175.       6                       MARS_NAK
  176.       7                       MARS_UNSERV
  177.       8                       MARS_SJOIN
  178.       9                       MARS_SLEAVE
  179.      12                       MARS_REDIRECT_MAP
  180.  
  181.  
  182.  
  183. MARSMSERV and MARS-UNSERV are identical in format to the MARSJOIN message.
  184. MARSSJOIN and MARS-SLEAVE are also identical in format to MARSJOIN. As
  185. such, their formats and those of MARSREQUEST, MARS-MULTI, MARSNAK and
  186. MARSREDIRECT-MAP are described in [GA96].  Their usage is described in
  187. section 4.  All control messages are LLC/SNAP encapsulated as described in
  188. section 4.2 of [GA96].  (The "mar$" notation used in this document is
  189. borrowed from [GA96], and indicates a specific field in the control
  190. message.)  Data messages are reflected without any modification by the MCS.
  191.  
  192.  
  193.  
  194. 3.2 Association with a layer 3 group
  195.  
  196. The simplest MCS architecture involves taking incoming AALSDUs from the
  197. multicast sources and sending them out over the point-to-multipoint VC to
  198. the group members.  The MCS can service just one layer 3 group using this
  199. design, as it has no way of distinguishing between traffic destined for
  200. different groups.  So each layer 3 MCS-supported group will have its own
  201. designated MCS.
  202.  
  203. However it is desirable in the interests of saving resources to utilize the
  204. same MCS to support multiple groups.  This can be done by adding minimal
  205. layer 3 specific processing into the MCS. The MCS can now look inside the
  206. received AALSDUs and determine which layer 3 group they are destined for.
  207. A single instance of such an MCS could register its ATM address with the
  208. MARS for multiple layer 3 groups, and manage multiple point-to-multipoint
  209. VCs, one for each group.  This capability is included in the MCS
  210. architecture, as is the capability of having multiple MCSs per group
  211.  
  212.  
  213.  
  214. Talpade and Ammar                                                   [Page 4]
  215.  
  216.  
  217.  
  218. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  219.  
  220.  
  221. (section 5).
  222.  
  223.  
  224.  
  225.  
  226. 4 Working of MCS
  227.  
  228. An MCS MUST NOT share its ATM address with any other cluster member (MARS
  229. or otherwise).  However, it may share the same physical ATM interface (even
  230. with other MCSs or the MARS), provided that each logical entity has a
  231. different ATM address.  This section describes the working of MCS and its
  232. interactions with the MARS and other cluster members.
  233.  
  234.  
  235.  
  236. 4.1 Usage of MARSMSERV and MARS-UNSERV
  237.  
  238.  
  239. 4.1.1 Registration (and deregistration) with the MARS
  240.  
  241. The ATM address of the MARS MUST be known to the MCS by out-of-band means
  242. at startup.  One possible approach for doing this is for the network
  243. administrator to specify the MARS address at command line while invoking
  244. the MCS. On startup, the MCS MUST open a point-to-point control VC (MARSVC)
  245. with the MARS. All traffic from the MCS to the MARS MUST be carried over
  246. the MARSVC. The MCS MUST register with the MARS using the MARS-MSERV
  247. message on startup.  To register, a MARSMSERV MUST be sent by the MCS to
  248. the MARS over the MARSVC. On receiving this MARS-MSERV, the MARS adds the
  249. MCS to the ServerControlVC. The ServerControlVC is maintained by the MARS
  250. with all MCSs as leaves, and is used to disseminate general control
  251. messages to all the MCSs.  The MCS MUST terminate this VC, and MUST expect
  252. a copy of the MCS registration MARSMSERV on the MARS-VC from the MARS.
  253.  
  254. An MCS can deregister by sending a MARSUNSERV to the MARS. A copy of this
  255. MARSUNSERV MUST be expected back from the MARS. The MCS will then be
  256. dropped from the ServerControlVC.
  257.  
  258. No protocol specific group addresses are included in MCS registration
  259. MARSMSERV and MARS-UNSERV. The mar$flags.register bit MUST be set, the
  260. mar$cmi field MUST be set to zero, the mar$flags.sequence field MUST be set
  261. to zero, the source ATM address MUST be included and a null source protocol
  262. address MAY be specified in these MARSMSERV and MARS-UNSERV. All other
  263. fields are set as described in section 5.2.1 of [GA96] (the MCS can be
  264. considered to be a cluster member while reading that section).  It MUST
  265. keep retransmitting (section 4.1.3) the MARSMSERV/MARS-UNSERV over the
  266. MARSVC until it receives a copy back.
  267.  
  268. In case of failure to open the MARSVC, or error on it, the reconnection
  269.  
  270. Talpade and Ammar                                                   [Page 5]
  271.  
  272.  
  273.  
  274. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  275.  
  276.  
  277. procedure outlined in section 4.5.2 is to be followed.
  278.  
  279.  
  280.  
  281. 4.1.2 Registration (and deregistration) of layer 3 groups
  282.  
  283. The MCS can register with the MARS to support particular group(s).  To
  284. register a group X, a MARSMSERV with a <min, max> pair of <X, X> MUST be
  285. sent to the MARS. The MCS MUST expect a copy of the MARSMSERV back from the
  286. MARS. The retransmission strategy outlined in section 4.1.3 is to be
  287. followed if no copy is received.  Multiple groups can be supported by
  288. sending a separate MARSMSERV for each group.
  289.  
  290. The MCS MUST similarly use MARSUNSERV if it wants to withdraw support for a
  291. specific layer 3 group.  A copy of the group MARSUNSERV MUST be received,
  292. failing which the retransmission strategy in section 4.1.3 is to be
  293. followed.
  294.  
  295. The mar$flags.register bit MUST be reset and the mar$flags.sequence field
  296. MUST be set to zero in the group MARSMSERV and MARS-UNSERV. All other
  297. fields are set as described in section 5.2.1 of [GA96] (the MCS can be
  298. considered to be a cluster member when reading that section).
  299.  
  300.  
  301.  
  302. 4.1.3 Retransmission of MARSMSERV and MARS-UNSERV
  303.  
  304.  
  305. Transient problems may cause loss of control messages.  The MCS needs to
  306. retransmit MARSMSERV/MARS-UNSERV at regular intervals when it does not
  307. receive a copy back from the MARS. This interval should be no shorter than
  308. 5 seconds, and a default value of 10 seconds is recommended.  A maximum of
  309. 5 retransmissions are permitted before a failure is logged.  This MUST be
  310. considered a MARS failure, which SHOULD result in the MARS reconnection
  311. mechanism described in section 4.5.2.
  312.  
  313. A "copy" is defined as a received message with the following fields
  314. matching the previously transmitted MARSMSERV/MARS-UNSERV:
  315.  
  316.  
  317.    -  mar$op
  318.    -  mar$flags.register
  319.    -  mar$pnum
  320.    -  Source ATM address
  321.    -  first <min, max> pair
  322.  
  323.  
  324. In addition, a valid copy MUST have the following field values:
  325.  
  326. Talpade and Ammar                                                   [Page 6]
  327.  
  328.  
  329.  
  330. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  331.  
  332.  
  333.    -  mar$flags.punched = 0
  334.    -  mar$flags.copy = 1
  335.  
  336.  
  337. If either of the above is not true, the message MUST be dropped without
  338. resetting of the MARSMSERV/MARS-UNSERV timer.  There MUST be only one
  339. MARSMSERV or MARS-UNSERV outstanding at a time.
  340.  
  341.  
  342.  
  343. 4.1.4 Processing of MARSMSERV and MARS-UNSERV
  344.  
  345. The MARS transmits copies of group MARSMSERV and MARS-UNSERV on the
  346. ServerControlVC. So they are also received by MCSs other than the
  347. originating one.  This section discusses the processing of these messages
  348. by the other MCSs.
  349.  
  350. If a MARSMSERV is seen that refers to a layer 3 group not supported by the
  351. MCS, it MUST be used to track the Server Sequence Number (section 4.5.1)
  352. and then silently dropped.
  353.  
  354. If a MARSMSERV is seen that refers to a layer 3 group supported by the MCS,
  355. the MCS learns of the existence of another MCS supporting the same group.
  356. This possibility is incorporated (of multiple MCSs per group) in this
  357. version of the MCS approach and is discussed in section 5.
  358.  
  359.  
  360.  
  361.  
  362. 4.2 Usage of MARSREQUEST and MARS-MULTI
  363.  
  364. As described in section 5.1, the MCS learns at startup whether it is an
  365. active or inactive MCS. After successful registration with the MARS, an MCS
  366. which has been designated as inactive for a particular group MUST NOT
  367. register to support that group with the MARS. It instead proceeds as in
  368. section 5.4.  The active MCS for a group also has to do some special
  369. processing, which we describe in that section.  The rest of section 4
  370. describes the working of a single active MCS, with section 5 describing the
  371. active MCSs actions for supporting multiple MCSs.
  372.  
  373. After the active MCS registers to support a layer 3 group, it uses
  374. MARSREQUEST and MARS-MULTI to obtain information about group membership
  375. from the MARS. These messages are also used during the revalidation phase
  376. (section 4.5) and when no outgoing VC exists for a received layer 3 packet
  377. (section 4.3).
  378.  
  379. On registering to support a particular layer 3 group, the MCS MUST send a
  380. MARSREQUEST to the MARS. The mechanism to retrieve group membership and the
  381.  
  382. Talpade and Ammar                                                   [Page 7]
  383.  
  384.  
  385.  
  386. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  387.  
  388.  
  389. format of MARSREQUEST and MARS-MULTI is described in section 5.1.1 and
  390. 5.1.2 of [GA96] respectively.  The MCS MUST use this mechanism for sending
  391. (and retransmitting) the MARSREQUEST and processing the returned
  392. MARSMULTI(/s).  The MARS-MULTI MUST be received correctly, and the MCS MUST
  393. use it to initialize its knowledge of group membership.
  394.  
  395. On successful reception of a MARSMULTI, the MCS MUST attempt to open the
  396. outgoing point-to-multipoint VC using the mechanism described in section
  397. 5.1.3 of [GA96], if any group members exist.  The MCS however MUST start
  398. transmitting data on this VC after it has opened it successfully with at
  399. least one of the group members as a leaf, and after it has attempted to add
  400. all the group members at least once.
  401.  
  402.  
  403.  
  404. 4.3 Usage of outgoing point-to-multipoint VC
  405.  
  406. Cluster members which are sources for MCS-supported layer 3 groups send
  407. (encapsulated) layer 3 packets to the designated MCSs.  An MCS, on
  408. receiving them from cluster members, has to send them out over the specific
  409. point-to-multipoint VC for that layer 3 group.  This VC is setup as
  410. described in the previous section.  However, it is possible that no group
  411. members currently exist, thus causing no VC to be setup.  So an MCS may
  412. have no outgoing VC to forward received layer 3 packets on, in which case
  413. it MUST initiate the MARSREQUEST and MARS-MULTI sequence described in the
  414. previous section.  This new MARSMULTI could contain new members, whose
  415. MARSSJOINs may have been not received by the MCS (and the loss not detected
  416. due to absence of traffic on the ServerControlVC).
  417.  
  418. If an MCS learns that there are no group members (MARSNAK received from
  419. MARS), it MUST delay sending out a new MARSREQUEST for that group for a
  420. period no less than 5 seconds and no more than 10 seconds.
  421.  
  422. Layer 3 packets received from cluster members, while no outgoing
  423. point-to-multipoint VC exists for that group, MUST be silently dropped
  424. after following the guidelines in the previous paragraphs.  This might
  425. result in some layer 3 packets being lost until the VC is setup.
  426.  
  427. Each outgoing point-to-multipoint VC has a revalidate flag associated with
  428. it.  This flag MUST be checked whenever a layer 3 packet is sent out on
  429. that VC. No action is taken if it is not set.  If it is set, the packet is
  430. sent out, the revalidation procedure (section 4.5.3) MUST be initiated for
  431. this group, and the flag MUST be reset.
  432.  
  433. In case of error on a point-to-multipoint VC, the MCS MUST initiate
  434. revalidation procedures for that VC as described in section 4.5.3.
  435.  
  436.  
  437.  
  438. Talpade and Ammar                                                   [Page 8]
  439.  
  440.  
  441.  
  442. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  443.  
  444.  
  445. Once a point-to-multipoint VC has been setup for a particular layer 3
  446. group, the MCS MUST hold the VC open and mark it as the outgoing path for
  447. any subsequent layer 3 packets being sent for that group address.  A
  448. point-to-multipoint VC MUST NOT have an activity timer associated with it.
  449. It is to remain up at all times, unless the MCS explicitly stops supporting
  450. that layer 3 group, or no more leaves exist on the VC which causes it to be
  451. shut down.  The VC is kept up inspite of non-existent traffic to reduce the
  452. delay suffered by MCS supported groups.  If the VC were to be shut down on
  453. absence of traffic, the VC reestablishment procedure (needed when new
  454. traffic for the layer 3 group appears) would further increase the initial
  455. delay, which can be potentially higher than the VC mesh approach anyway as
  456. two VCs need to be setup in the MCS case (one from source to MCS, second
  457. from MCS to group) as opposed to only one (from source to group) in the VC
  458. Mesh approach.  This approach of keeping the VC from the MCS open even in
  459. the absense of traffic is experimental.  A decision either way can only be
  460. made after gaining experience (either through implementation or simulation)
  461. about the implications of keeping the VC open.
  462.  
  463. If the MCS supports multiple layer 3 groups, it MUST follow the procedure
  464. outlined in the four previous subsections for each group that it is an
  465. active MCS. Each incoming data AALSDU MUST be examined for determining its
  466. recipient group, before being forwarded onto the appropriate outgoing
  467. point-to-multipoint VC.
  468.  
  469.  
  470.  
  471. 4.3.1 Group member dropping off a point-to-multipoint VC
  472.  
  473. AN ERRL-DROP may be received during the lifetime of a point-to-multipoint
  474. VC indicating that a leaf node has terminated its participation at the ATM
  475. level.  The ATM endpoint associated with the ERRL-DROP MUST be removed from
  476. the locally held set associated with the VC. The revalidate flag on the VC
  477. MUST be set after a random interval of 1 through 10 seconds.
  478.  
  479. If an ERRL-RELEASE is received for a VC, then the entire set is cleared and
  480. the VC considered to be completely shutdown.  A new VC for this layer 3
  481. group will be established only on reception of new traffic for the group
  482. (as described in section 4.3).
  483.  
  484.  
  485.  
  486.  
  487. 4.4 Processing of MARSSJOIN and MARS-SLEAVE
  488.  
  489. The MARS transmits equivalent MARSSJOIN/MARS-SLEAVE on the ServerControlVC
  490. when it receives MARSJOIN/MARS-LEAVE from cluster members.  The MCSs keep
  491. track of group membership updates through these messages.  The format of
  492. these messages are identical to MARSJOIN and MARS-LEAVE, which are
  493.  
  494. Talpade and Ammar                                                   [Page 9]
  495.  
  496.  
  497.  
  498. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  499.  
  500.  
  501. described in section 5.2.1 of [GA96].  It is sufficient to note here that
  502. these messages carry the ATM address of the node joining/leaving the
  503. group(/s), the group(/s) being joined or left, and a Server Sequence Number
  504. from MARS.
  505.  
  506. When a MARSSJOIN is seen which refers to (or encompasses) a layer 3 group
  507. (or groups) supported by the MCS, the following action MUST be taken.  The
  508. new member's ATM address is extracted from the MARSSJOIN. An L-MULTIADD is
  509. issued for the new member for each of those referred groups which have an
  510. outgoing point-to-multipoint VC. An LMULTI-RQ is issued for the new member
  511. for each of those refered groups which have no outgoing VCs.
  512.  
  513. When a MARSSLEAVE is seen that refers to (or encompasses) a layer 3 group
  514. (or groups) supported by the MCS, the following action MUST be taken.  The
  515. leaving member's ATM address is extracted.  An LMULTI-DROP is issued for
  516. the member for each of the refered groups which have an outgoing
  517. point-to-multipoint VC.
  518.  
  519. There is a possibility of the above requests (LMULTI-RQ or LMULTIADD or
  520. LMULTI-DROP) failing.  The UNI 3.0/3.1 failure cause must be returned in
  521. the ERRL-RQFAILED signal from the local signaling entity to the AAL User.
  522. If the failure cause is not 49 (Quality of Service unavailable), 51 (user
  523. cell rate not available - UNI 3.0), 37 (user cell rate not available - UNI
  524. 3.1), or 41 (Temporary failure), the endpoint's ATM address is dropped from
  525. the locally held view of the group by the MCS. Otherwise, the request MUST
  526. be re-attempted with increasing delay (initial value between 5 to 10
  527. seconds, with delay value doubling after each attempt) until it either
  528. succeeds or the multipoint VC is released or a MARSSLEAVE is received for
  529. that group member.  If the VC is open, traffic on the VC MUST continue
  530. during these attempts.
  531.  
  532. MARSSJOIN and MARS-SLEAVE are processed differently if multiple MCSs share
  533. the members of the same layer 3 group (section 5.4).  MARSSJOIN and
  534. MARSSLEAVE that do not refer to (or encompass) supported groups MUST be
  535. used to track the Server Sequence Number (section 4.5.1), but are otherwise
  536. ignored.
  537.  
  538.  
  539.  
  540. 4.5 Revalidation Procedures
  541.  
  542. The MCS has to initiate revalidation procedures in case of certain failures
  543. or errors.
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550. Talpade and Ammar                                                  [Page 10]
  551.  
  552.  
  553.  
  554. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  555.  
  556.  
  557. 4.5.1 Server Sequence Number
  558.  
  559.  
  560. The MCS needs to track the Server Sequence Number (SSN) in the messages
  561. received on the ServerControlVC from the MARS. It is carried in the mar$msn
  562. of all messages (except MARSNAK) sent by the MARS to MCSs.  A jump in SSN
  563. implies that the MCS missed the previous message(/s) sent by the MARS. The
  564. MCS then sets the revalidate flag on all outgoing point-to-multipoint VCs
  565. after a random delay of between 1 and 10 seconds, to avoid all MCSs
  566. inundating the MARS simultaneously in case of a more general failure.
  567.  
  568. The only exception to the rule is if a sequence number is detected during
  569. the establishment of a new group's VC (i.e.  a MARSMULTI was correctly
  570. received, but its mar$msn indicated that some previous MARS traffic had
  571. been missed on ClusterControlVC). In this case every open VC, EXCEPT the
  572. one just being established, MUST have its revalidate flag set at some
  573. random interval between 1 and 10 seconds from the time the jump in SSN was
  574. detected.  (The VC being established is considered already validated in
  575. this case).
  576.  
  577. Each MCS keeps its own 32 bit MCS Sequence Number (MSN) to track the SSN.
  578. Whenever a message is received that carries a mar$msn field, the following
  579. processing is performed:
  580.  
  581.  
  582.         Seq.diff = mar$msn - MSN
  583.  
  584.         mar$msn -> MSN
  585.  
  586.         (.... process MARS message ....)
  587.  
  588.         if ((Seq.diff != 1) && (Seq.diff != 0))
  589.               then (.... revalidate group membership information ....)
  590.  
  591.  
  592. The mar$msn value in an individual MARSMULTI is not used to update the MSN
  593. until all parts of the MARSMULTI (if > 1) have arrived.  (If the mar$msn
  594. changes during reception of a MARSMULTI series, the MARS-MULTI is discarded
  595. as described in section 5.1.1 of [GA96]).
  596.  
  597. The MCS sets its MSN to zero on startup.  It gets the current value of SSN
  598. when it receives the copy of the registration MARSMSERV back from the MARS.
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606. Talpade and Ammar                                                  [Page 11]
  607.  
  608.  
  609.  
  610. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  611.  
  612.  
  613. 4.5.2 Reconnecting to the MARS
  614.  
  615.  
  616. The MCSs are assumed to have been configured with the ATM address of at
  617. least one MARS at startup.  MCSs MAY choose to maintain a table of ATM
  618. addresses, each address representing alternative MARS which will be
  619. contacted in case of failure of the previous one.  This table is assumed to
  620. be ordered in descending order of preference.
  621.  
  622. An MCS will decide that it has problems communicating with a MARS if:
  623.  
  624.  
  625.    * It fails to establish a point-to-point VC with the MARS.
  626.  
  627.    * MARSREQUEST generates no response (no MARSMULTI or MARS-NAK returned).
  628.  
  629.    * ServerControlVC fails.
  630.  
  631.    * MARSMSERV or MARSUNSERV do not result in their respective copies being
  632.      received.
  633.  
  634.  
  635. (reconnection as in section 5.4 in [GA96], with MCS-specific actions used
  636. where needed).
  637.  
  638.  
  639. 4.5.3 Revalidating a point-to-multipoint VC
  640.  
  641.  
  642. The revalidation flag associated with a point-to-multipoint VC is checked
  643. when a layer 3 packet is to be sent out on the VC. Revalidation procedures
  644. MUST be initiated for a point-to-multipoint VC that has its revalidate flag
  645. set when a layer 3 packet is being sent out on it.  Thus more active groups
  646. get revalidated faster than less active ones.  The revalidation process
  647. MUST NOT result in disruption of normal traffic on the VC being
  648. revalidated.
  649.  
  650. The revalidation procedure is as follows.  The MCS reissues a MARSREQUEST
  651. for the VC being revalidated.  The returned set of members is compared with
  652. the locally held set; LMULTI-ADDs MUST be issued for new members, and
  653. LMULTI-DROPs MUST be issued for non-existent ones.  The revalidate flag
  654. MUST be reset for the VC.
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662. Talpade and Ammar                                                  [Page 12]
  663.  
  664.  
  665.  
  666. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  667.  
  668.  
  669. 5 Multiple MCSs for a layer 3 group
  670.  
  671. Having a single MCS for a layer 3 group can cause it to become a single
  672. point of failure and a bottleneck for groups with large numbers of active
  673. senders.  It is thus desirable to introduce a level of fault tolerance by
  674. having multiple MCS per group.  Support for load sharing is not introduced
  675. in this version of the draft so as to reduce the complexity of the
  676. protocol.
  677.  
  678.  
  679.  
  680. 5.1 Outline
  681.  
  682. The protocol described in this draft offers fault tolerance by using
  683. multiple MCSs for the same group.  This is achieved by having a standby MCS
  684. take over from a failed MCS which had been supporting the group.  The MCS
  685. currently supporting a group is refered to as the active MCS, while the one
  686. or more standby MCSs are refered to as inactive MCSs.  There is only one
  687. active MCS existing at any given instant for an MCS-supported group.  The
  688. protocol makes use of the HELLO messages as described in [LA96].
  689.  
  690. To reduce the complexity of the protocol, the following operational
  691. guidelines need to be followed.  These guidelines need to be enforced by
  692. out-of-band means which are not specified in this document and can be
  693. implementation dependent.
  694.  
  695.  
  696.    * The set of (one or more) MCSs (``mcslist'') that support a particular
  697.      IP Multicast group is predetermined and fixed.  This set MUST be known
  698.      to each MCS in the set at startup, and the ordering of MCSs in the set
  699.      is the same for all MCSs in the set.  An implementation of this would
  700.      be to maintain the set of ATM addresses of the MCSs in a file, an
  701.      identical copy of which is kept at each MCS in the set.
  702.  
  703.    * All MCSs in ``mcslist'' have to be started up together, with the first
  704.      MCS in ``mcslist'' being the last to be started.
  705.  
  706.    * A failed MCS cannot be started up again.
  707.  
  708.  
  709.  
  710.  
  711. 5.2 Discussion of Multiple MCSs in operation
  712.  
  713. An MCS on startup determines its position in the ``mcslist''.  If the MCS
  714. is not the first in ``mcslist'', it does not register for supporting the
  715. group with the MARS. If the MCS is first in the set, it does register to
  716.  
  717.  
  718. Talpade and Ammar                                                  [Page 13]
  719.  
  720.  
  721.  
  722. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  723.  
  724.  
  725. support the group.
  726.  
  727. The first MCS thus becomes the active MCS and supports the group as
  728. described in section 4.  The active MCS also opens a point-to-multipoint VC
  729. (HelloVC) to the remaining MCSs in the set (the inactive MCSs).  It starts
  730. sending HELLO messages on this VC at a fixed interval (HelloInterval
  731. seconds).  The inactive MCSs maintain a timer to keep track of the last
  732. received HELLO message.  If an inactive MCS does not receive a message
  733. within HelloInterval* DeadFactor seconds (values of HelloInterval and
  734. DeadFactor are the same at all the MCSs), or if the HelloVC is closed, it
  735. assumes failure of the active MCS and attempts to elect a new one.  The
  736. election process is described in section 5.5.
  737.  
  738. If an MCS is elected as the new active one, it registers to support the
  739. group with the MARS. It also initiates the transmission of HELLO messages
  740. to the remaining inactive MCSs.
  741.  
  742.  
  743.  
  744. 5.3 Inter-MCS control messages
  745.  
  746. The protocol uses HELLO messages in the heartbeat mechanism, and also
  747. during the election process.  The format of the HELLO message is based on
  748. that described in [LA96].  The Hello message type code is 5.
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.     0                   1                   2                   3
  756.     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
  757.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  758.    | Sender Len    |    Recvr Len  | State | Type  |    unused     |
  759.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  760.    |         HelloInterval         |          DeadFactor           |
  761.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  762.    |                        IP Multicast address                   |
  763.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  764.    |                    Sender ATM address (variable length)       |
  765.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  766.    |                  Receiver ATM address (variable length)       |
  767.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  768.  
  769.    Sender Len
  770.      This field holds the length in octets of the Sender ATM address.
  771.  
  772.  
  773.  
  774. Talpade and Ammar                                                  [Page 14]
  775.  
  776.  
  777.  
  778. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  779.  
  780.  
  781.    Recvr Len
  782.      This field holds the length in octets of the Receiver ATM
  783.      address.
  784.  
  785.    State
  786.      Currently two states: No-Op (0x00) and Elected (0x01).
  787.      It is used by a candidate MCS to indicate if it was successfully
  788.      elected.
  789.  
  790.    Type
  791.      This is the code for the message type.
  792.  
  793.    HelloInterval
  794.      The hello interval advertises the time between sending of
  795.      consecutive Hello Messages by an active MCS.  If the time between
  796.      Hello messages exceeds the HelloInterval then the Hello is to be
  797.      considered late by the inactive MCS.
  798.  
  799.    DeadFactor
  800.      This is a multiplier to the HelloInterval. If an inactive MCS
  801.      does not receive a Hello message within the interval
  802.      HelloInterval*DeadFactor from an active MCS that advertised
  803.      the HelloInterval then the inactive MCS MUST consider the active
  804.      one to have failed.
  805.  
  806.    IP Multicast address
  807.      This field is used to indicate the group to associate the HELLO
  808.      message with. It is useful if MCSs can support more than one
  809.      group.
  810.  
  811.    Sender ATM address
  812.      This is the protocol address of the server which is sending the
  813.      Hello.
  814.  
  815.    Receiver ATM address
  816.      This is the protocol address of the server which is to Reply to
  817.      the Hello.  If the sender does not know this address then the
  818.      sender sets it to zero. (This happens in the HELLO messages sent
  819.      from the active MCS to the inactive ones, as they are multicast
  820.      and not sent to one specific receiver).
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830. Talpade and Ammar                                                  [Page 15]
  831.  
  832.  
  833.  
  834. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  835.  
  836.  
  837. 5.4 The Multiple MCS protocol
  838.  
  839. As is indicated in section 5.1, all the MCSs supporting the same IP
  840. Multicast group MUST be started up together.  The set of MCSs (``mcslist'')
  841. MUST be specified to each MCS in the set at startup.  After registering to
  842. support the group with the MARS, the first MCS in the set MUST open a
  843. point-to-multipoint VC (HelloVC) with the remaining MCSs in the ``mcslist''
  844. as leaves, and thus assumes the role of active MCS. It MUST send HELLO
  845. messages HelloInterval seconds apart on this VC. The Hello message sent by
  846. the active MCS MUST have the Receiver Len set to zero, the State field set
  847. to "Elected", with the other fields appropriately set.  The Receiver ATM
  848. address field does not exist in this HELLO message.  The initial value of
  849. HelloInterval and DeadFactor MUST be the same at all MCSs at startup.  The
  850. active MCS can choose to change these values by introducing the new value
  851. in the HELLO messages that are sent out.  The active MCS MUST support the
  852. group as described in section 4.
  853.  
  854. The other MCSs in ``mcslist'' determine the identity of the first MCS from
  855. the ``mcslist''.  They MUST NOT register to support the group with the
  856. MARS, and become inactive MCSs.  On startup, an inactive MCS expects HELLO
  857. messages from the active MCS. The inactive MCS MUST terminate the HelloVC.
  858. A timer MUST be maintained, and if the inactive MCS does not receive HELLO
  859. message from the active one within a period HelloInterval*DeadFactor
  860. seconds, it assumes that the active MCS died, and initiates the election
  861. process as described in section 5.5.  If a HELLO message is received within
  862. this period, the inactive MCS does not initiate any further action, other
  863. than restarting the timer.  The inactive MCSs MUST set their values of
  864. HelloInterval and DeadFactor to those specified by the active MCS in the
  865. HELLO messages.
  866.  
  867. On failure of the active MCS, a new MCS assumes its role as described in
  868. section 5.5.  In this case, the remaining inactive MCSs will expect HELLO
  869. messages from this new active MCS as described in the previous paragraph.
  870.  
  871.  
  872.  
  873. 5.5 Failure handling
  874.  
  875.  
  876. 5.5.1 Failure of active MCS
  877.  
  878. The failure of the active MCS is detected by the inactive MCSs if no HELLO
  879. message is received within an interval of HelloInterval*DeadFactor seconds,
  880. or if the HelloVC is closed.  In this case the next MCS in ``mcslist''
  881. becomes the candidate MCS. It MUST open a point-to-multipoint VC to the
  882. remaining inactive MCSs (HelloVC) and send a HELLO message on it with the
  883. State field set to No-Op.  The rest of the message is formatted as
  884.  
  885.  
  886. Talpade and Ammar                                                  [Page 16]
  887.  
  888.  
  889.  
  890. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  891.  
  892.  
  893. described earlier.
  894.  
  895. On receiving a HELLO message from a candidate MCS, an inactive MCS MUST
  896. open a point-to-point VC to that candidate.  It MUST send a HELLO message
  897. back to it, with the Sender and Receiver fields appropriately set (not
  898. zero), and the State field being No-Op.  If a HELLO message is received by
  899. an inactive MCS from a non-candidate MCS, it is ignored.  If no HELLO
  900. message is received from the candidate with the State field set to
  901. "Elected" in HelloInterval seconds, the inactive MCS MUST retransmit the
  902. HELLO. If no HELLO message with State field set to "Elected" is received by
  903. the inactive MCSs within an interval of HelloInterval*DeadFactor seconds,
  904. the next MCS in ``mcslist'' is considered as the candidate MCS. Note that
  905. the values used for HelloInterval and DeadFactor in the election phase are
  906. the default ones.
  907.  
  908. The candidate MCS MUST wait for a period of HelloInterval*DeadFactor
  909. seconds for receiving HELLO messages from inactive MCSs.  It MUST transmit
  910. HELLO messages with State field set to No-Op at HelloInterval seconds
  911. interval during this period.  If it receives messages from atleast half of
  912. the remaining inactive MCSs during this period, it considers itself elected
  913. and assumes the active MCS role.  It then registers to support the group
  914. with the MARS, and starts sending HELLO messages at HelloInterval second
  915. intervals with State field set to "Elected" on the already existing
  916. HelloVC. The active MCS can then alter the HelloInterval and DeadFactor
  917. values if desired, and communicate the same to the inactive MCSs in the
  918. HELLO message.
  919.  
  920.  
  921.  
  922. 5.5.2 Failure of inactive MCS
  923.  
  924. If an inactive MCS drops off the HelloVC, the active MCS MUST attempt to
  925. add that MCS back to the VC for three attempts, spaced
  926. HelloInterval*DeadFactor seconds apart.  If even the third attempt fails,
  927. the inactive MCS is considered dead.
  928.  
  929. An MCS, active or inactive, MUST NOT be started up once it has failed.
  930. Failed MCSs can only be started up by manual intervention after shutting
  931. down all the MCSs, and restarting them together.
  932.  
  933.  
  934. 5.6 Compatibility with future MARS and MCS versions
  935.  
  936. Future versions of MCSs can be expected to use an enhanced MARS for load
  937. sharing and fault tolerance ([TA96]).  The MCS architecture described in
  938. this document is compatible with the enhanced MARS and the future MCS
  939. versions.  This is because the active MCS is the only one which
  940.  
  941.  
  942. Talpade and Ammar                                                  [Page 17]
  943.  
  944.  
  945.  
  946. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  947.  
  948.  
  949. communicates with the MARS about the group.  Hence the active MCS will only
  950. be informed by the enhanced MARS about the subset of the group that it is
  951. to support.  Thus MCSs conforming to this document are compatible with
  952. [GA96] based MARS, as well as enhanced MARS.
  953.  
  954.  
  955. 6 Summary
  956.  
  957. This draft describes the architecture of an MCS. It also provides a
  958. mechanism for using multiple MCSs per group for providing fault tolerance.
  959. This approach can be used with [GA96] based MARS server and clients,
  960. without needing any change in their functionality.  It uses the HELLO
  961. packet format as described in [LA96] for the heartbeat messages.
  962.  
  963.  
  964. 7 Acknowledgements
  965.  
  966. We would like to acknowledge Grenville Armitage (Bellcore) for reviewing
  967. the draft and suggesting improvements towards simplifying the multiple MCS
  968. functionalities.  Discussion with Joel Halpern (Newbridge) helped clarify
  969. the multiple MCS problem.  Anthony Gallo (IBM RTP) pointed out security
  970. issues that are not adequately addressed in the current draft.
  971.  
  972.  
  973.  
  974.  
  975. 8 Authors' Address
  976.  
  977. Rajesh Talpade - taddy@cc.gatech.edu - (404)-894-6737
  978. Mostafa H. Ammar - ammar@cc.gatech.edu - (404)-894-3292
  979.  
  980. College of Computing
  981. Georgia Institute of Technology
  982. Atlanta, GA 30332-0280
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998. Talpade and Ammar                                                  [Page 18]
  999.  
  1000.  
  1001.  
  1002. INTERNET-DRAFT       <draft-ietf-ion-marsmcs-01.txt>       November 18, 1996
  1003.  
  1004.  
  1005. References
  1006.  
  1007. [GA96]   Armitage, G.J., "Support for Multicast over UNI 3.0/3.1 based ATM
  1008.          networks", RFC 2022.
  1009.  
  1010. [BK95]   Birman, A., Kandlur, D., Rubas, J., "An extension to the MARS
  1011.          model", Internet Draft, draft-kandlur-ipatm-mars-directvc-00.txt,
  1012.          November 1995.
  1013. [LM93]   Laubach, M., "Classical IP and ARP over ATM", RFC1577,
  1014.          Hewlett-Packard Laboratories, December 1993.
  1015.  
  1016. [LA96]   Luciani, J., G. Armitage, and J. Halpern, "Server Cache
  1017.          Synchronization Protocol (SCSP) - NBMA", Internet Draft,
  1018.          draft-luciani-rolc-scsp-02.txt, April 1996.
  1019.  
  1020. [TA96]   Talpade, R., and Ammar, M.H., "Multiple MCS support using an
  1021.          enhanced version of the MARS server.", Internet Draft (work in
  1022.          progress), draft-talpade-ion-multmcs-00.txt, June 1996.
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054. Talpade and Ammar                                                  [Page 19]
  1055.  
  1056.