rfc1629.txt

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

   IS-IS requires that the set of level 2 routers be connected.  Should
   the level 2 backbone become partitioned, there is no provision for
   use of level 1 links to repair a level 2 partition.

   Occasionally a single level 2 router may lose connectivity to the
   level 2 backbone.  In this case the level 2 router will indicate in
   its level 1 routing packets that it is not "attached", thereby
   allowing level 1 routers in the area to route traffic for outside of
   the area to a different level 2 router.  Level 1 routers therefore
   route traffic to destinations outside of their area only to level 2
   routers which indicate in their level 1 routing packets that they are
   "attached".

   A host may autoconfigure the area portion of its address by
   extracting the area portion of a neighboring router's address. If
   this is the case, then a host will always accept a router as a
   neighbor.  Since the standard does not specify that the host *must*
   autoconfigure its area address, a host may be pre-configured with an
   area address.

   Special treatment is necessary for broadcast subnetworks, such as
   LANs.  This solves two sets of issues: (i) In the absence of special
   treatment, each router on the subnetwork would announce a link to
   every other router on the subnetwork, resulting in O(n-squared) links
   reported; (ii) Again, in the absence of special treatment, each
   router on the LAN would report the same identical list of end systems
   on the LAN, resulting in substantial duplication.

   These problems are avoided by use of a "pseudonode", which represents
   the LAN.  Each router on the LAN reports that it has a link to the
   pseudonode (rather than reporting a link to every other router on the
   LAN).  One of the routers on the LAN is elected "designated router".
   The designated router then sends out a Link State Packet (LSP) on
   behalf of the pseudonode, reporting links to all of the routers on
   the LAN.  This reduces the potential n-squared links to n links.  In
   addition, only the pseudonode LSP includes the list of end systems on
   the LAN, thereby eliminating the potential duplication.






Colella, Callon, Gardner & Rekhter                             [Page 11]

RFC 1629                    NSAP Guidelines                     May 1994


   The IS-IS provides for optional Quality of Service (QOS) routing,
   based on throughput (the default metric), delay, expense, or residual
   error probability.

   IS-IS has a provision for authentication information to be carried in
   all IS-IS PDUs.  Currently the only form of authentication which is
   defined is a simple password.  A password may be associated with each
   link, each area, and with the level 2 subdomain.  A router not in
   possession of the appropriate password(s) is prohibited from
   participating in the corresponding function (i.e., may not initialize
   a link, be a member of the area, or a member of the level 2
   subdomain, respectively).

   Procedures are provided to allow graceful migration of passwords
   without disrupting operation of the routing protocol.  The
   authentication functions are extensible so that a stronger,
   cryptographically-based security scheme may be added in an upwardly
   compatible fashion at a future date.

3.3.  Overview of IDRP (ISO/IEC 10747)

   The Inter-Domain Routing Protocol (IDRP, ISO/IEC 10747), developed in
   ISO, provides routing for OSI environments.  In particular, IDRP is
   designed to work in conjuction with CLNP, ES-IS, and IS-IS.  This
   section briefly describes the manner in which IDRP operates.

   Consistent with the OSI Routing Framework [13], in IDRP the
   internetwork is partitioned into routing domains.  IDRP places no
   restrictions on the inter-domain topology.  A router that
   participates in IDRP is called a Boundary Intermediate System (BIS).
   Routing domains that participate in IDRP are not allowed to overlap -
   a BIS may belong to only one domain.

   A pair of BISs are called external neighbors if these BISs belong to
   different domains but share a common subnetwork (i.e., a BIS can
   reach its external neighbor in a single network layer hop).  Two
   domains are said to be adjacent if they have BISs that are external
   neighbors of each other.  A pair of BISs are called internal
   neighbors if these BISs belong to the same domain.  In contrast with
   external neighbors, internal neighbors don't have to share a common
   subnetwork -- IDRP assumes that a BIS should be able to exchange
   Network Protocol Date Units (NPDUs) with any of its internal
   neighbors by relying solely on intra-domain routing procedures.

   IDRP governs the exchange of routing information between a pair of
   neighbors, either external or internal.  IDRP is self-contained with
   respect to the exchange of information between external neighbors.
   Exchange of information between internal neighbors relies on



Colella, Callon, Gardner & Rekhter                             [Page 12]

RFC 1629                    NSAP Guidelines                     May 1994


   additional support provided by intra-domain routing (unless internal
   neighbors share a common subnetwork).

   To facilitate routing information aggregation/abstraction, IDRP
   allows grouping of a set of connected domains into a Routing Domain
   Confederation (RDC).  A given domain may belong to more than one RDC.
   There are no restrictions on how many RDCs a given domain may
   simultaneously belong to, and no preconditions on how RDCs should be
   formed --  RDCs may be either nested, or disjoint, or may overlap.
   One RDC is nested within another RDC if all members (RDs) of the
   former are also members of the latter, but not vice versa.  Two RDCs
   overlap if they have members in common and also each has members that
   are not in the other.  Two RDCs are disjoint if they have no members
   in common.

   Each domain participating in IDRP is assigned a unique Routing Domain
   Identifier (RDI).  Syntactically an RDI is represented as an OSI
   network layer address.  Each RDC is assigned a unique Routing Domain
   Confederation Identifier (RDCI).  RDCIs are assigned out of the
   address space allocated for RDIs -- RDCIs and RDIs are syntactically
   indistinguishable.  Procedures for assigning and managing RDIs and
   RDCIs are outside the scope of the protocol.  However, since RDIs are
   syntactically nothing more than network layer addresses, and RDCIs
   are syntactically nothing more than RDIs, it is expected that RDI and
   RDCI assignment and management would be part of the network layer
   assignment and management procedures.  Recommendations for RDI and
   RDCI assignment are provided in Section 6.5.

   IDRP requires a BIS to be preconfigured with the RDI of the domain to
   which the BIS belongs.  If a BIS belongs to a domain that is a member
   of one or more RDCs, then the BIS has to be preconfigured with RDCIs
   of all the RDCs the domain is in, and the information about relations
   between the RDCs - nested or overlapped.

   IDRP doesn't assume or require any particular internal structure for
   the addresses.  The protocol provides correct routing as long as the
   following guidelines are met:

   * End systems and intermediate systems may use any NSAP address or
     Network Entity Title (NET -- i.e., an NSAP address without the
     selector) that has been assigned under ISO 8348 [11] guidelines;

   * An NSAP prefix carried in the Network Layer Reachability
     Information (NLRI) field for a route originated by a BIS in a
     given routing domain should be associated with only that
     routing domain; that is, no system identified by the prefix
     should reside in a different routing domain; ambiguous routing
     may result if several routing domains originate routes whose



Colella, Callon, Gardner & Rekhter                             [Page 13]

RFC 1629                    NSAP Guidelines                     May 1994


     NLRI field contain identical NSAP address prefixes, since this
     would imply that the same system(s) is simultaneously located
     in several routing domains;

   * Several different NSAP prefixes may be associated with a single
     routing domain which contains a mix of systems which use NSAP
     addresses assigned by several different addressing authorities.

   IDRP assumes that the above guidelines have been satisfied,  but it
   contains no means to verify that this is so.  Therefore, such
   verification is assumed to be the responsibility of the
   administrators of routing domains.

   IDRP provides mandatory support for data integrity and optional
   support for data origin authentication for all of its messages.  Each
   message carries a 16-octet digital signature that is computed by
   applying the MD-4 algorithm (RFC 1320) to the context of the message
   itself.  This signature provides support for data integrity.  To
   support data origin authentication a BIS, when computing a digital
   signature of a message, may prepend and append additional information
   to the message.  This information is not passed as part of the
   message but is known to the receiver.

3.3.1.  Scaling Mechanisms in IDRP

   The ability to group domains in RDCs provides a simple, yet powerful
   mechanism for routing information aggregation and abstraction.  It
   allows reduction of topological information by replacing a sequence
   of RDIs carried by the RD_PATH attribute with a single RDCI.  It also
   allows reduction of the amount of information related to transit
   policies, since the policies can be expressed in terms of aggregates
   (RDCs), rather than individual components (RDs).  It also allows
   simplification of route selection policies, since these policies can
   be expressed in terms of aggregates (RDCs) rather than individual
   components (RDs).

   Aggregation and abstraction of Network Layer Reachability Information
   (NLRI) is supported by the "route aggregation" mechanism of IDRP.
   This mechanism is complementary to the Routing Domain Confederations
   mechanism.  Both mechanisms are intended to provide scalable routing
   via information reduction/abstraction.  However, the two mechanisms
   are used for different purposes: route aggregation for aggregation
   and abstraction of routes (i.e., Network Layer Reachability
   Information), Routing Domain Confederations for aggregation and
   abstraction of topology and/or policy information.  To provide
   maximum benefits, both mechanisms can be used together.  This implies
   that address assignment that will facilitate route aggregation does
   not conflict with the ability to form RDCs, and vice versa; formation



Colella, Callon, Gardner & Rekhter                             [Page 14]

RFC 1629                    NSAP Guidelines                     May 1994


   of RDCs should be done in a manner consistent with the address
   assignment needed for route aggregation.

3.4.  Requirements of IS-IS and IDRP on NSAPs

   The preferred NSAP format for IS-IS is shown in Figure 1.  A number
   of points should be noted from IS-IS:

   * The IDP is as specified in ISO 8348, the OSI network layer service
     specification [11];

   * The high-order portion of the DSP (HO-DSP) is that portion of the
     DSP whose assignment, structure, and meaning are not constrained by
     IS-IS;

   * The area address (i.e., the concatenation of the IDP and the
     HO-DSP) must be globally unique.  If the area address of an NSAP
     matches one of the area addresses of a router, it is in the
     router's area and is routed to by level 1 routing;

   * Level 2 routing acts on address prefixes, using the longest address
     prefix that matches the destination  address;

   * Level 1 routing acts on the ID field.  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.  The ID field is assumed to be
     flat.  The method presented in RFC 1526 [18] may optionally be
     used to assure globally unique IDs;

   * The one-octet NSAP Selector, SEL, determines the entity to receive
     the CLNP packet within the system identified by the rest of the
     NSAP (i.e., a transport entity) and is always the last octet of the
     NSAP; and,

   * A system shall be able to generate and forward data packets
     containing addresses in any of the formats specified by
     ISO 8348.  However, within a routing domain that conforms to IS-IS,
     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 IS-IS
     routing.  End systems with addresses which do not conform may
     require additional manual configuration and be subject to inferior
     routing performance.

   For purposes of efficient operation of the IS-IS routing protocol,
   several observations may be made.  First, although the IS-IS protocol
   specifies an algorithm for routing within a single routing domain,
   the routing algorithm must efficiently route both: (i) Packets whose
   final destination is in the domain (these must, of course, be routed



Colella, Callon, Gardner & Rekhter                             [Page 15]

RFC 1629                    NSAP Guidelines                     May 1994


   to the correct destination end system in the domain); and (ii)
   Packets whose final destination is outside of the domain (these must
   be routed to an appropriate "border" router, from which they will
   exit the domain).

   For those destinations which are in the domain, level 2 routing
   treats the entire area address (i.e., all of the NSAP address except
   the ID and SEL fields) as if it were a flat field.  Thus, the
   efficiency of level 2 routing to destinations within the domain is
   affected only by the number of areas in the domain, and the number of
   area addresses assigned to each area.

   For those destinations which are outside of the domain, level 2
   routing routes according to address prefixes.  In this case, there is
   considerable potential advantage (in terms of reducing the amount of