rfc2443.txt

RFC 的详细文档！

   Flags
     The flags field is used to contain several flags:

       mar$flags
          Bit 15   - mar$flags.layer3grp
          Bit 13   - mar$flags.register
          Bit 0-7  - mar$flags.sequence

     The mars$flags.layer3grp and mar$flags.register bits MUST be set
     the same as in the originating MARS_JOIN request. The
     mar$flags.sequence bits are of local significance only to the LS.

   Cluster Member CMI
     This field contains the CMI assigned by the MARS Server which
     processed the MARS_JOIN request and uniquely identifies the MARS
     Client in the MARS server cache.

   Src Addr Len
     This field contains the length of the Source Protocol Address
     field.  For IPv4, the value is 4 if an address is specified. A null
     (non-existent) address MUST be coded as zero length, and no space
     allocated for it in the message body.

   Group Addr Len
     This field contains the length of the Group Protocol Address field.
     If the register bit in the flags field is set to 1 in the request
     this field MUST be zero.  If the register bit is zero in the flags
     field the value of this field for IPv4 is 4.

   ATM Addr T/L
     This field contains the type and length of the Source ATM Address
     field for the MARS Client that originated the MARS_JOIN request.
     The type and length encoding is described in Section 3.

   ATM SubAddr T/L
     This field contains the type and length of the Source ATM
     SubAddress field for the MARS Client that originated the MARS_JOIN
     request.  The type and length encoding is described in Section 3.

   Source Protocol Address
     This is the internetwork address for the source of an address
     binding in a MARS server cache entry. If Src Addr Len is set to
     zero no storage will be allocated.

   Source ATM Address
     This is the MARS Client's ATM address of an address binding in a
     MARS server cache entry. The address is E.164 or ATM Forum NSAPA.




Luciani & Gallo               Experimental                     [Page 13]

RFC 2443                MARS Service Using SCSP            November 1998


   Source ATM SubAddress
     This is the MARS Client's ATM subaddress of an address binding in a
     MARS server cache entry. The subaddress, if specified, is an ATM
     Forum NSAPA.  If null, no storage will be allocated.

   Minimum Multicast Group Address
     This is the internetwork address of the lower bound on the range of
     multicast group addresses for the address binding in a MARS server
     cache entry. If Group Addr Len is set to zero no storage will be
     allocated.

   Maximum Multicast Group Address
     This is the internetwork address of the upper bound on the range of
     multicast group addresses for the address binding in a MARS server
     cache entry. If Group Addr Len is set to zero no storage will be
     allocated.

   An MARS Client can only register with one MARS Server in the SG and
   is only placed on the CCVC for the MARS Server for which it is
   registered with. If the mar$flags.layer3grp is set to 1 than the
   Minimum and Maximum Multicast Group Addresses MUST be equal for IPv4.

   When a MARS Client Join/Register request is sent with the
   mar$flags.register bit set to 1 all of the servers in the SG will
   create a cache entry for this client using the information in the
   request.

   When a registered MARS Client issues a MARS_JOIN for a specific group
   address range a MARS Client Join/Register request MUST be sent to the
   servers in the SG. The actions taken by each server in the SG depend
   on previous group membership actions and MCS supported groups.

   Each MARS Server MUST perform the necessary redistribution and hole
   punching algorithms before propagating this request to the CCVC and
   SCVC on each server. The redistribution and hole punching algorithms
   used for propagating join requests to the CCVC are the same as
   defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating
   MARS_JOIN request is a duplicate of a previously joined range or
   contains no group address range than a MARS Client Join/Register MUST
   NOT be sent to the SG.

   The redistribution and hole punching algorithms used for propagating
   join requests as MARS_SJOIN request on a SCVC is the same as Section
   6.2.4 except for the following. Only the MARS Servers which contain
   the registered MCS Clients for the target group ranges should
   propagate this information to their SCVCs.





Luciani & Gallo               Experimental                     [Page 14]

RFC 2443                MARS Service Using SCSP            November 1998


5.4  MARS Client Leave/Deregister request.

   The MARS Client Leave/Deregister request is used to propagate the
   deregistering or leaving of specific group ranges by registered MARS
   Clients within the SG domain. It is similar to the MARS_LEAVE request
   defined in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the
   SG successfully deregisters a registered MARS Client or a registered
   client leaves a specific group address range for which it had joined
   the MARS Server MUST send a MARS Client Leave/Deregister request to
   the SG. If a registered MARS Client is unexpectedly removed from the
   CCVC the MARS Server MUST act as a proxy and send a MARS Client
   Leave/Deregister request to the SG.

   The format and meanings of the fields in a MARS Client
   Leave/Deregister request are the same as in Section 5.3 except the
   State is coded as 4 decimal for a MARS Client Leave/Deregister
   request.

   When a MARS Client Leave/Deregister request is sent with the
   mar$flags.register bit set to 1 all of the servers in the SG
   receiving this update MUST purge all cache entries for this client.

   When a registered MARS Client issues a MARS_LEAVE for a specific
   group address range a MARS Client LEAVE/Deregister request MUST be
   sent to the servers in the SG. The actions taken by each server in
   the SG depend on previous group membership actions and MCS supported
   groups.

   Each MARS Server MUST perform the necessary redistribution and hole
   punching algorithms before propagating this request to the CCVC and
   SCVC on each server. The redistribution and hole punching algorithms
   used for propagating leave requests to the CCVC are the same as
   defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating
   MARS_LEAVE request does not correspond to a previously joined range
   or contains no group address range than a MARS Client
   Leave/Deregister MUST NOT be sent to the SG.

   The redistribution and hole punching algorithms used for propagating
   leave requests as MARS_SLEAVE requests on a SCVC is the same as
   Section 6.2.4 except for the following. Only the MARS Servers which
   contain the registered MCS Clients for the target group ranges should
   propagate this information to their SCVCs.

5.5  MCS Unserve/Deregister request.

   The MCS Unserve/Deregister request is used to propagate the
   deregistering or unservicing of specific groups by a registered MCS
   Client within the SG domain. It is similar to an MARS_MUNSERV request



Luciani & Gallo               Experimental                     [Page 15]

RFC 2443                MARS Service Using SCSP            November 1998


   defined in Section 6.2.2 and 6.2.3 of [1]. When a MARS Server in the
   SG successfully deregisters a registered MCS Client or registered MCS
   Client stops serving a specific group address range for which it had
   serviced the MARS Server MUST send a MCS Unserve/Deregister request
   to the SG. If a registered MCS Client is unexpectedly removed from
   the SCVC the MARS Server owning the SCVC MUST act as a proxy and send
   a MCS Unserve/Deregister request to the SG.

   The format and meanings of the fields in a MCS Unserve/Deregister
   request are the same as in Section 5.2 except the State is coded as 5
   decimal for a MCS Unserve/Deregister request.

   When a MCS Client Unserve/Deregister request is sent with the
   mar$flags.register bit set to 1 all of the servers in the SG
   receiving this update MUST purge all cache entries for this client.

   When a registered MCS Client issues a MARS_MUNSERV for a specific
   group address range being served a MCS Client Unserve/Deregister
   request MUST be sent to the servers in the SG. The members of the SG
   that receive this update must then clear the cache entry associated
   with this MCS Client.

   In addition to clearing one or more cache entries associated with
   receiving a  MCS Client Unserve/Deregister request each MARS Server
   in the SG MUST send out a MARS_LEAVE message on it's CCVC in order
   for clients to change back to a mesh topology.

6.  Security Considerations

   There is no mechanism to encrypt the CSA Record MARS Specific Part of
   the message exchanged between servers. However, there are base SCSP
   security features in the SCSP Protocol Independent part [2] which can
   be used to protect against attacks.

   Any SCSP MARS is susceptible to Denial of Service (DOS) attacks. A
   rouge MARS Client can inundate its Server with MARS packets. This is
   a base MARS problem as currently defined by [1]. A rouge host can
   also inundate its neighboring SCSP MARS with SCSP packets. However,
   if the authentication option is used, the SCSP MARS databases will
   not become corrupted, as the bogus packets will be discarded when the
   authentication check fails.

   Due to the pair wise authentication model of SCSP MARS, the
   information received from any properly authenticated server is
   trusted and propagated throughout the server group. Consequently, if
   security of any SCSP MARS server is compromised, the entire database
   becomes vulnerable to corruption originating from the compromised
   server.



Luciani & Gallo               Experimental                     [Page 16]

RFC 2443                MARS Service Using SCSP            November 1998


References

   [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
       Networks", RFC 2022, November 1996.

   [2] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server
       Cache Synchronization Protocol", RFC 2334, April 1998.

   [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       October 1994.  See also: http://www.iana.org/numbers.html

   [4] Laubach, M., "Classic IP and ARP over ATM", RFC 1577, January
       1994.

   [5] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
       Levels," BCP 14, RFC 2119, March 1997.

Acknowledgments

   The authors would like to thank Grenville Armitage for his previous
   distributed MARS work and also the members of the ION working group
   of the IETF, whose review and discussion of this document has been
   invaluable.

Authors' Addresses

   James V. Luciani
   Bay Networks, Inc.
   3 Federal Street, BL3-04
   Billerica, MA  01821

   Phone: [phone]
   EMail: [e-mail]


   Anthony M. Gallo
   IBM, Networking Hardware Division
   Dept. M6LA/B664
   P.O. Box 12195
   Research Triangle Park, NC 27709

   Phone: [phone]
   EMail: [e-mail]








Luciani & Gallo               Experimental                     [Page 17]

RFC 2443                MARS Service Using SCSP            November 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Luciani & Gallo               Experimental                     [Page 18]