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