rfc1768.txt

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

Network Working Group                                          D. Marlow
Request for Comments: 1768                                       NSWC-DD
Category: Experimental                                        March 1995


              Host Group Extensions for CLNP Multicasting

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This memo documents work performed in the TUBA (TCP/UDP over Bigger
   Addresses) working group of IPng area prior to the July 1994 decision
   to utilize SIPP-16 as the basis for IPng.  The TUBA group worked on
   extending the Internet Protocol suite by the use of ISO 8473 (CLNP)
   and its related routing protocols.  This memo describes multicast
   extensions to CLNP and its related routing protocols for Internet
   multicast use.  Publication of this memo does not imply acceptance by
   any IETF Working Group for the ideas expressed within.

   This memo provides a specification for multicast extensions to the
   CLNP protocol similar to those provided to IP by RFC1112.  These
   extensions are intended to provide the mechanisms needed by a host
   for multicasting in a CLNP based Internet.  This memo covers
   addressing extensions to the CLNP addressing structure, extensions to
   the CLNP protocol and extensions to the ES-IS protocol.  An appendix
   discusses the differences between IP multicast and the CLNP multicast
   approach provided in this memo.

Acknowledgments

   The specification provided here was developed by a number of
   individuals in the IETF TUBA working group as well as the ANSI X3S3.3
   and ISO SC6 WG2 committees.  Key contributions were made by Steve
   Deering, Joel Halpern, Dave Katz and Dave Oran.











Marlow                                                          [Page 1]

RFC 1768                   CLNP Multicasting                  March 1995


Table of Contents

   1.  Introduction ..........................................  2
   2.  Levels of Conformance..................................  3
   3.  Group Network Addresses................................  4
   4.  Model of a CLNP End System Multicast Implementation....  8
   5.  Extensions to the CLNP Protocol........................  8
   6.  Extensions to the ES-IS Routeing Protocol ............. 15
   7.  Security Considerations ............................... 39
   Appendix A.  Differences with RFC 1112 .................... 40
   Appendix B.  Issues Under Study ........................... 43
   References ................................................ 44
   Author's Address .......................................... 45

1.      Introduction

   This memo provides a specification for multicast extensions for CLNP
   in order to provide a CLNP based Internet the capabilities provided
   for IP by RFC 1112 (Host Extensions for IP Multicasting) [RFC1112].
   This memo uses an outline similar to that of RFC 1112.

   Paraphrasing RFC 1112, "CLNP multicasting is the transmission of a
   CLNP datagram to a "host group", a set of zero or more End Systems
   identified by a single group Network address (GNA). A multicast
   datagram is delivered to all members of its destination host group
   with the same "best-efforts" reliability as regular unicast CLNP
   datagrams, i.e., the datagram is not guaranteed to arrive intact at
   all members of the destination group or in the same order relative to
   other datagrams.

   "The membership of a host group is dynamic; that is End Systems may
   join and leave groups at any time. There is no restrictions on the
   location or number of members in a host group. An End System may be a
   member of more than one group at a time. An End System need not be a
   member of a group to send datagrams to it.

   "A host group may be permanent or transient. A permanent group has an
   administratively assigned GNA. It is the address, not the membership
   of the group, that is permanent; at any time a permanent group may
   have any number of members, even zero.

   "Internetwork forwarding of CLNP multicast datagrams is handled by
   "multicast capable" Intermediate Systems which may be co-resident
   with unicast capable Intermediate Systems.

   The multicast extensions to the CLNP addressing structure defines
   group Network addresses which identify host groups.  The multicast
   extensions to CLNP provides a means for identifying a CLNP packet and



Marlow                                                          [Page 2]

RFC 1768                   CLNP Multicasting                  March 1995


   provides scope control mechanisms for CLNP multicast packets. The
   multicast extensions to the ES-IS protocol provide the mechanisms
   needed for a host to exchange control information with multicast
   capable routers.  These extensions to the ES-IS protocol provide for
   a host to "announce" which multicast packets are of interest and for
   a multicast capable router to dynamically "map" group Network
   addresses to subnetwork addresses.

   This memo specifies the extensions required by an End System to make
   use of CLNP multicast. In addition the requirements placed upon
   multicast capable Intermediate Systems to exchange information with
   multicast capable End Systems is specified. No specifications are
   provided related to the information exchanges between Intermediate
   Systems to support multicast route selection or multicast Protocol
   Data Unit (PDU) forwarding. A discussion of multicast route selection
   and PDU forwarding has been written by Steve Deering [Deering91].
   Note that for these multicast extensions to work there must exist an
   uninterrupted path of multicast capable routers between the End
   Systems comprising a host group (such paths may utilize tunneling
   (i.e., unicast CLNP encapsulated paths between multicast capable CLNP
   routers)).   In order to support multicast route selection and
   forwarding for a CLNP based internet additional specifications are
   needed. Specifications of this type could come in the form of new
   protocols, extensions to the current CLNP based routing protocols or
   use of a technique out of the IETF's Inter-Domain Multicast Routing
   (IDMR) group. The IDMR group is currently investigating multicast
   protocols for routers which utilize a router's unicast routing
   protocols, this approach may extend directly to CLNP routers.

   While many of the techniques and assumptions of IP multicasting (as
   discussed in RFC 1112) are used in CLNP multicasting, there are
   number of differences. Appendix A describes the differences between
   CLNP multicasting and IP multicasting. This memo describes techniques
   brought in directly from projects within ISO to incorporate multicast
   transmission capabilities into CLNP [MULT-AMDS].

2.      Levels of Conformance

   There are three levels of conformance for End Systems to this
   specification:

   Level 0: no support for CLNP multicasting.

   There is no requirement for a CLNP End System (or Intermediate
   System) to support CLNP multicasting. Level 0 hosts should be
   unaffected by the presence of multicast activity. The destination
   addresses used in support of multicast transfers, the GNA, should not
   be enabled by a non-multicast capable End System and the PDUs



Marlow                                                          [Page 3]

RFC 1768                   CLNP Multicasting                  March 1995


   themselves are marked differently than unicast PDUs and thus should
   be quietly discarded.

   Level 1: support for sending but not receiving CLNP multicast PDUs.

   An End System originating multicast PDUs is required to know whether
   a multicast capable Intermediate System is attached to the
   subnetwork(s) that it originates multicast PDUs (i.e., to determine
   the destination SNPA (subnet) address). An End System with Level 1
   conformance is required to implement all parts of this specification
   except for those supporting only Multicast Announcement.  An End
   System is not required to know the current Multicast Address Mapping
   to start originating multicast PDUs.

   Note: It is possible for End System not implementing Multicast
   Address Mapping to successfully originate multicast PDUs (but with
   the End System knowing of the existence of a multicast capable
   Intermediate System). Such operation may lead to inefficient
   subnetworks use.  Thus when an End System continues (or may continue)
   to originate multicast PDUs destined for the same group,
   implementations are to provide Multicast Address Mapping support.

   Level 2: full support for CLNP multicasting.

   Level 2 allows a host to join and leave host groups as well as send
   CLNP PDUs to host groups. It requires implementation by the End
   System of all parts of this specification.

3.      Group Network Addresses

   Individual Network addresses used by CLNP for End System addressing
   are called Network Service Access Points (NSAPs). RFC 1237 defines
   the NSAP address for use in the Internet. In order to provide an
   address for a group of End Systems, this specification does not
   change the definition of the NSAP address, but adds a new type of
   identifier - the group Network address - that supports a multicast
   Network service (i.e., between a single source NSAP, identified by an
   individual Network address, and a group of destination NSAPs,
   identified by a group Network address). Host groups are identified by
   group Network addresses.

   In the development of multicast address extensions to CLNP,
   requirements were identified for: (1)"easily distinguishing" group
   addresses at the Network layer from NSAP addresses; (2)leaving the
   currently allocated address families unaffected and (3)ensuring that
   the approach taken would not require the establishment of new
   addressing authorities. In addition, it was agreed that providing
   multicast options for all OSI Network layer users was desirable and



Marlow                                                          [Page 4]

RFC 1768                   CLNP Multicasting                  March 1995


   thus the group Network addressing solution should support options for
   all address formats covered by ISO/IEC 8348 | CCITT Recommendation
   X.213. The only viable means identified for meeting all requirements
   was via creating a new set of AFI values with a fixed one-to-one
   mapping between each of the existing AFI values and a corresponding
   group AFI value.

   Group Network addresses are defined by creating a new set of AFI
   values, one for each existing AFI value, and a fixed one-to-one
   mapping between each of the existing AFI values and a corresponding
   group AFI value. The syntax of a group Network address is identical
   to the syntax of an individual Network address, except that the value
   of the AFI in an individual Network address may be only one of the
   values already allocated for individual Network addresses, whereas
   the value of the AFI in a group Network address may be only one of
   the values allocated here for group Network addresses. The AFI values
   allocated for group Network addresses have been chosen in such a way
   that they do not overlap, in the preferred encoding defined by
   ISO/IEC 8348 | CCITT Recommendation X.213, with any of the AFI values
   that have already been allocated for individual Network addresses.

3.1     Definitions

   group Network address: an address that identifies a set of zero or
   more Network service access points; these may belong to multiple
   Network entities, in different End Systems.

   individual Network address: an address that identifies a single NSAP.

3.2     CLNP Addresses

   A discussion of the CLNP address format is contained in RFC 1237. The
   structure of all CLNP addresses is divided into two parts the Initial
   Domain Part (IDP) and the Domain Specific Part (DSP). The first two
   octets of the IDP are the Authority and Format Identifier (AFI)
   field. The AFI has an abstract syntax of two hexadecimal digits with
   a value in the range of 00 to FF. In addition to identifying the
   address authority responsible for allocating a particular address and
   the format of the address, the AFI also identifies whether an address
   is an individual Network address or a group Network address. There
   are 90 possible AFI values to support individual Network address
   allocations. In addition, when the AFI value starts with the value
   "0" this identifies that the field contains an incomplete individual
   Network address (i.e., identifies an escape code).

   Table 1 allocates 90 possible AFI values to support group Network
   address allocations. In addition if the first two digits of the IDP
   are hexadecimal FF, this indicates the presence of an incomplete



Marlow                                                          [Page 5]

RFC 1768                   CLNP Multicasting                  March 1995


   group Network address. The allocation of group addresses is
   restricted to be only from the AFI values allocated for the
   assignment of group addresses in Table 1. An addressing authority in
   allocating either Network addresses or authorizing one or more
   authorities to allocate addresses, allocates both individual and the