rfc1768.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   While error reports are permitted on multicast PDUs, a PDU with a
   group Network address in the source address field shall not be
   responded to with an Error Report. This is to ensure that a multicast
   PDU does not generate another multicast PDU. If the source address is
   identified as a group address then an error report PDU shall not be
   generated and the original PDU shall be discarded.

5.3.6   Source routing functions

   No source routing capability is provided for multicast PDU transfer.
   The NS provider shall not accept a multicast PDU with source route
   parameters.

5.4     Scope control function

5.4.1   Overview

   The scope control function is an option for multicast PDU forwarding
   only. The scope control function allows the originator to limit the
   forwarding of the multicast PDU. The scope control function provides
   the capability to limit the relaying of a particular PDU based on the
   individual Network addressing hierarchy and/or limit the amount of
   multicast expansion which can take place. In cases where both forms
   of scope control are applied to the same PDU, forwarding will cease
   once either has reached its scope control limit.

5.4.2   Prefix Based Scope Control

   The prefix based scope control function allows the originator to
   specify a specific set of address prefixes where the multicast
   forwarding of a PDU by an Intermediate System occurs only if one of
   the prefixes matches the Network Entity Title (NET) of the



Marlow                                                         [Page 11]

RFC 1768                   CLNP Multicasting                  March 1995


   Intermediate System. Prefix based scope control may be selected only
   by the originator of a PDU. Prefix based scope control is
   accomplished using one or more address prefixes held in a parameter
   within the options part of the PDU header. The length of this
   parameter is determined by the originating network entity, and does
   not change during the lifetime of a PDU.

   When an Intermediate System receives a multicast PDU containing a
   prefix based scope control parameter, forwarding is only performed if
   every octet of one of the prefixes contained in the prefix based
   scope control parameter matches that Intermediate System's NET,
   starting from the beginning of its NET. If no such prefix match
   exists, the Intermediate System discards the PDU. The error reporting
   function shall not be invoked upon PDU discard.

5.4.3   Radius Scope Control

   The radius scope control function allows the originator to specify a
   maximum logical distance where multicast expansion can occur. It is
   closely associated with the header format analysis function. Each IS
   receiving a multicast PDU which is capable of expanding and which
   contains a Radius Scope Control parameter, decrements the Radius
   Scope Control field in the PDU by an administratively set amount
   between 0 and the maximum value of the field.  An IS, when it
   decrements the Radius Scope Control field, shall place a value of 0
   into this field if its current value is less than the amount it is to
   decrement by.   This function determines whether the PDU received may
   be forwarded or whether its Radius has been reached, in which case it
   shall be discarded. An Intermediate System shall not forward a
   multicast PDU containing a Radius Scope Control parameter with a
   value of 0. The error reporting function shall not be invoked upon
   PDU discard.

5.4.3.1 Radius Scope Control Example

   The Radius Scope Control parameter is useful where policies have been
   established across the potential forwarding path.  One possible
   policy for Internet use is for multicast capable routers to treat
   this field as a hop count within a domain (decrement by one unit) and
   for inter-domain routers to either decrement this field to an even
   multiple of 256 when crossing domains where prior agreements have
   been made or decrement this field to 0 (i.e., discard the packet) for
   other domains.








Marlow                                                         [Page 12]

RFC 1768                   CLNP Multicasting                  March 1995


5.5     Structure and Encoding of PDUs

   Multicast transmission is accomplished via the transfer of Multicast
   Data (MD) PDUs. The PDU type code for a MD PDU is "1 1 1 0 1". The
   format of the MD PDU is identical to that of the Data (DT) PDU.   The
   MD and DT PDU may contain the same optional parameters with the
   following exceptions: (1)The source routing parameter is permitted
   within DT PDUs but not MD PDUs; and (2)The scope control parameter is
   permitted within MD PDUs but not DT PDUs.

5.6     Optional parameters for multicast support

5.6.1   Prefix Based Scope Control

   The prefix based scope control parameter specifies one or more
   address prefixes for which Intermediate System forwarding requires a
   match of one of the contained prefixes with the beginning of the
   Intermediate System's NET.

   Parameter Code:         1100 0100

   Parameter Length:       variable

   Parameter Value:        a concatenation of address prefix entries

   The parameter value contains an address prefix list. The list
   consists of variable length address prefix entries. The first octet
   of each entry gives the length of the address prefix denominated in
   bits that comprises the remainder of the entry.  If the length field
   does not specify an integral number of octets then the prefix entry
   is followed by enough trailing zeroes to make the end of the entry
   fall on an octet boundary.  The list must contain at least one entry.

   The prefix shall end on a boundary that is legal in the abstract
   syntax of the address family from which it is derived.  For example,
   the encoding of a prefix whose DSP is expressed in decimal syntax
   must end on a semi-octet boundary, while the encoding of a prefix
   whose DSP is expressed in binary syntax can end on an arbitrary bit
   boundary. If the end of the prefix falls within the IDP, then the
   prefix must end on a semi-octet boundary and must not contain any
   padding characters.

   Note: The length of the prefix based scope control parameter is
   determined by the originator of the PDU and is not changed during the
   lifetime of the PDU.






Marlow                                                         [Page 13]

RFC 1768                   CLNP Multicasting                  March 1995


5.6.1.1 Prefix matching

   A prefix that extends into the DSP shall be compared directly against
   the encoded NET address, including any padding characters that may be
   present.  A prefix which does not extend into the DSP shall be
   compared against the derived quantity NET', which is obtained from
   the NET address by removing all padding characters (as defined by the
   binary encoding process of ISO 8348).

   The existence of a match shall be determined as follows:

   a)   If the encoded NET (or NET') contains fewer bits than the pre-
        fix, then there is no match.

   b)   If the encoded NET (or NET') contains at least as many bits as
        the prefix, and all bits of the prefix are identical to the
        corresponding leading bits of the encoded NET (or NET'), there
        is a match.  Otherwise, there is no match.

5.6.2   Radius Scope Control

   The radius scope control parameter specifies the logical distance
   that a multicast PDU can be forwarded.

   Parameter Code:         1100 0110

   Parameter Length:       two octets

   Parameter Value:        two octets which represents the remaining
                           distance, that the PDU can be forwarded,
                           in administratively set units.

5.7     Provision of the Underlying Service

   For a subnetwork that provides an inherent multicast capability, it
   is the functionality of the SNDCF to provide the mapping between
   group Network addresses and the corresponding addressing capability
   of the subnetwork.

5.8      Conformance

   All of the extensions provided to the functions to support multicast
   capability are optional. For an End System or Intermediate System
   which is not multicast capable these extensions are not applicable.
   An implementation claiming conformance as a multicast capable End
   System shall meet all of the requirements for an End System which is
   not multicast capable and also provide all of the multicast
   extensions provided here. An implementation claiming conformance as a



Marlow                                                         [Page 14]

RFC 1768                   CLNP Multicasting                  March 1995


   multicast capable Intermediate System shall meet all of the
   requirements for an Intermediate System which is not multicast
   capable and also provide all of the multicast extensions provided
   here.

6.      Extensions to the ES-IS Routeing Protocol

   This section provides optional extensions to the ES-IS Routeing
   Protocol [ES-IS], ISO 9542 to support the transfer of multicast PDUs.
   It is an explicit goal of this specification that ESs and ISs, some
   of which will have multicast capabilities and some without, will be
   able to fully function on the same subnetworks. This specification
   does not change any aspect of a currently defined (i.e., non-
   multicast) ISO 9542 implementation, it adds new optional
   functionality not modifying current functionality. Two basic
   functions are provided: multicast announcement and multicast address
   mapping.

6.1     Overview of the protocol

6.1.1   Operation of ESs receiving multicast PDUs

   ESs, upon initialization and periodically thereafter, will construct
   End System Group Hello (ESGH) PDUs identifying, by particular group
   Network addresses, the multicast PDUs it wishes to receive. The ES
   will periodically originate (announce) these ESGH PDUs on the
   subnetwork it wishes to receive these on. Reporting the same group
   Network address on multiple subnetworks may result in the reception
   of duplicate PDUs. ES-IS operations related to requesting the same
   group Network address on multiple subnetworks are handled totally
   independently (e.g., using different logical timers,...). It is
   permitted for an ES to report a number of group Network addresses in
   the same ESGH PDU.  The only restrictions placed on providing
   multiple group Network addresses within the same ESGH PDU are that
   all packets requested are to be received on the same subnet, with the
   same holding time and that the ESGH PDU be of length equal to or less
   that its maximum packet size constraint.  Note that each group
   Network address in the ESGH PDU is paired with its own SNPA
   (subnetwork point of attachment) address.

   An ES will always have an SNPA address associated with each of its
   active group Network addresses. An SNPA address is a subnetwork
   address, in the case of a subnetwork which uses IEEE 802 addresses
   the SNPA address is a 48 bit IEEE 802 MAC (media access control)
   address.  Of particular interest is the address used to mark the
   destination group.  For a subnetwork using IEEE 802 addressing a
   group SNPA address uses a particular bit position to "mark" group
   SNPA addresses.



Marlow                                                         [Page 15]

RFC 1768                   CLNP Multicasting                  March 1995


   Upon initialization the ES may have static SNPA address associations
   (Pre-configured SNPA addresses). For any group Network address
   without a Pre-configured SNPA address that the ES wishes to receive,
   the ES will associate the "All Multicast Capable End Systems" SNPA
   address.  Upon receiving a Multicast Address Mapping (MAM) PDU
   containing a group Network address that the ES is announcing, the ES
   will use the SNPA address pairing contained in the MAM PDU for that
   group Network address. Upon the expiration of the Mapping Holding
   Timer, the ES shall revert back to associating either the Pre-
   configured SNPA address if one exists or the "All Multicast Capable
   End Systems" SNPA address for the specific group Network address.
   While an ES is permitted to listen in on other ESs announcements
   (needed for the damping option), an ES is not permitted to change its
   group Network address to SNPA address mapping based on the
   announcement of other ESs.

   Optionally, the ES may perform damping (resetting a Multicast
   Announcement Timer corresponding to a particular group Network
   address) if the conditions necessary to withhold a particular
   announcement are met. In order to perform damping the following
   conditions must be met: (1)The ES must be processing other ES's
   announcements; (2)An ESGH PDU is received that identifies the exact
   same group Network address and SNPA address pairing on a particular
   subnetwork that this ES is announcing on; (3) The Multicast Holding
   Timer parameter value in the ESGH PDU received is equal to or greater
   than the Multicast Holding Timer value, for this subnetwork, that is
   being used by the ES processing this ESGH PDU.