rfc1526.txt

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

Network Working Group                                      D. Piscitello
Request for Comments: 1526                                      Bellcore
Category: Informational                                   September 1993


          Assignment of System Identifiers for TUBA/CLNP Hosts

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This document describes conventions whereby the system identifier
   portion of an RFC 1237 style NSAP address may be guaranteed
   uniqueness within a routing domain for the purpose of
   autoconfiguration in TUBA/CLNP internets. The mechanism is extensible
   and can provide a basis for assigning system identifiers in a
   globally unique fashion.

Introduction

   This memo specifies methods for assigning a 6 octet system identifier
   portion of the OSI NSAP address formats described in "Guidelines for
   OSI NSAP Allocation in the Internet" [1], in a fashion that ensures
   that the ID is unique within a routing domain. It also recommends
   methods for assigning system identifiers having lengths other than 6
   octets. The 6 octet system identifiers recommended in this RFC are
   assigned from 2 globally administered spaces (IEEE 802 or "Ethernet",
   and IP numbers, administered by the Internet Assigned Numbers
   Authority, IANA).

   At this time, the primary purpose for assuring uniqueness of system
   identifiers is to aid in autoconfiguration of NSAP addresses in
   TUBA/CLNP internets [2]. The guidelines in this paper also establish
   an initial framework within which globally unique system identifiers,
   also called endpoint identifiers, may be assigned.

Acknowledgments

   Many thanks to Radia Perlman, Allison Mankin, and Ross Callon of for
   their insights and assistance. Thanks also to the Ethernet connector
   to my MAC, which conveniently and quite inobtrusively fell out,
   enabling me to get an entire day's worth of work done without email
   interruptions.




Piscitello                                                      [Page 1]

RFC 1526              System Identifiers for TUBA         September 1993


1.  Background

   The general format of OSI network service access point (NSAP)
   addresses is illustrated in Figure 1.

          _______________________________________________
          |____IDP_____|_______________DSP______________|
          |__AFI_|_IDI_|_____HO-DSP______|___ID___|_SEL_|

                IDP     Initial Domain Part
                AFI     Authority and Format Identifier
                IDI     Initial Domain Identifier
                DSP     Domain Specific Part
                HO-DSP  High-order DSP
                ID      System Identifier
                SEL     NSAP Selector

                Figure 1: OSI NSAP Address Structure.

   The recommended encoding and allocation of NSAP addresses in the
   Internet is specified in RFC 1237. RFC 1237 makes the following
   statements regarding the system identifier (ID) field of the NSAPA:

  1.  the ID field may be from one to eight octets in length

  2.  the ID must have a single known length in any particular
      routing domain

  3.  the ID field must be unique within an area for ESs and
      level 1 ISs, and unique within the routing domain for level
      2 ISs.

  4.  the ID field is assumed to be flat

   RFC 1237 further indicates that, within a routing domain that
   conforms to the OSI intradomain routing protocol [3] the lower-order
   octets of the NSAP should be structured as the ID and SEL fields
   shown in Figure 1 to take full advantage of intradomain IS-IS
   routing. (End systems with addresses which do not conform may require
   additional manual configuration and be subject to inferior routing
   performance.)

   Both GOSIP Version 2 (under DFI-80h, see Figure 2a) and ANSI DCC NSAP
   addressing (Figure 2b) define a common DSP structure in which the
   system identifier is assumed to be a fixed length of 6 octets.






Piscitello                                                      [Page 2]

RFC 1526              System Identifiers for TUBA         September 1993


               _______________
               |<--__IDP_-->_|___________________________________
               |AFI_|__IDI___|___________<--_DSP_-->____________|
               |_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_|
        octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__|

                    Figure 2 (a): GOSIP Version 2 NSAP structure.
               ______________
               |<--_IDP_-->_|_____________________________________
               |AFI_|__IDI__|____________<--_DSP_-->_____________|
               |_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_|
        octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__|

                     IDP   Initial Domain Part
                     AFI   Authority and Format Identifier
                     IDI   Initial Domain Identifier
                     DSP   Domain Specific Part
                     DFI   DSP Format Identifier
                     ORG   Organization Name (numeric form)
                     Rsvd  Reserved
                     RD    Routing Domain Identifier
                     Area  Area Identifier
                     ID    System Identifier
                     SEL   NSAP Selector


                 Figure 2(b): ANSI NSAP address format for DCC=840

2.  Autoconfiguration

   There are provisions in OSI for the autoconfiguration of area
   addresses. OSI end systems may learn their area addresses
   automatically by observing area address identified in the IS-Hello
   packets transmitted by routers using the ISO 9542 End System to
   Intermediate System Routing Protocol, and may then insert their own
   system identifier. (In particular, RFC 1237 explains that when the ID
   portion of the address is assigned using IEEE style 48-bit
   identifiers, an end system can reconfigure its entire NSAP address
   automatically without the need for manual intervention.) End systems
   that have not been pre-configured with an NSAPA may also request an
   address from an intermediate system their area using [5].

2.1  Autoconfiguration and 48-bit addresses

   There is a general misassumption that the 6-octet system identifier
   must be a 48-bit IEEE assigned (ethernet) address.  Generally
   speaking, autoconfiguration does not rely on the use of a 48-bit
   ethernet style address; any system identifier that is globally



Piscitello                                                      [Page 3]

RFC 1526              System Identifiers for TUBA         September 1993


   administered and is unique will do. The use of 48-bit/6 octet system
   identifiers is "convenient...because it is the same length as an 802
   address", but more importantly, choice of a single, uniform ID length
   allows for "efficient packet forwarding", since routers won't have to
   make on the fly decisions about ID length (see [6], pages 156-157).
   Still, it is not a requirement that system identifiers be 6 octets to
   operate the the IS-IS protocol, and IS-IS allows for the use of IDs
   with lengths from 1 to 8 octets.

3.  System Identifiers for TUBA/CLNP

   Autoconfiguration is a desirable feature for TUBA/CLNP, and is viewed
   by some as "essential if a network is to scale to a truly large size"
   [6].

   For this purpose, and to accommodate communities who do not wish to
   use ethernet style addresses, a generalized format that satisfies the
   following criteria is desired:

   o the format is compatible with installed end systems
     complying to RFC 1237

   o the format accommodates 6 octet, globally unique system
     identifiers that do not come from the ethernet address space

   o the format accommodates globally unique system identifiers
     having lengths other than 6 octets

   The format and encoding of a globally unique system identifier that
   meets these requirements is illustrated in Figure 3:

      Octet 1     Octet 2     Octet 3 ...     Octet LLL-1  Octet LLLL
   +-----------+-----------+-----------+- ...-+-----------+-----------+
   | xxxx TTGM | xxxx xxxx | xxxx xxxx |      | xxxx xxxx | xxxx xxxx |
   +-----------+-----------+-----------+- ...-+-----------+-----------+

                   Figure 3. General format of the system identifier

3.1  IEEE 802 Form of System Identifier

   The format is compatible with globally assigned IEEE 802 addresses,
   since it carefully preserves the semantics of the global/local and
   group/individual bits.  Octet 1 identifies 2 qualifier bits, G and M,
   and a subtype (TT) field whose semantics are associated with the
   qualifier bits.  When a globally assigned IEEE 802 address is used as
   a system identifier, the qualifier bit M, representing the
   multicast/unicast bit, must always be set to zero to denote a unicast
   address. The qualifier bit G may be either 0 or 1, depending on



Piscitello                                                      [Page 4]