rfc1237.txt

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

    
       * How a routing domain (especially a site) should organize its
         internal topology of areas or allocate portions of its NSAP
         address space; the relationship between topology and addresses is
         discussed, but the method of deciding on a particular topology or
         internal addressing plan is not; and,
    
    
       * Procedures for assigning the System Identifier (ID) portion of the
         NSAP.
    
    
    
    3   Background
    
    
    
    Some background information is provided in this section that is
    helpful in understanding the issues involved in NSAP allocation. A
    brief discussion of OSI routing is provided, followed by a review
    of the intra-domain protocol in sufficient detail to understand the
    issues involved in NSAP allocation. Finally, the specific constraints
    that the intra-domain protocol places on NSAPs are listed.
    
    
    
    
    Colella, Gardner, & Callon                                     [Page 6]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    3.1   OSI Routing Standards
    
    
    
    OSI partitions the routing problem into three parts:
    
    
       * routing exchanges between end systems and intermediate systems
         (ES-IS),
    
       * routing exchanges between ISs in the same routing domain (intra-
         domain IS-IS), and,
    
       * routing among routing domains (inter-domain IS-IS).
    
    
    ES-IS, international standard ISO9542 [13] approved in 1987, is
    available in vendor products and is planned for the next release of
    Berkeley UNIX (UNIX is a trademark of AT&T). It is also cited in GOSIP
    Version 2 [4], which became effective in April 1991 for all applicable
    federal procurements, and mandatory beginning eighteen months later in
    1992.
    
    
    Intra-domain IS-IS advanced to draft international standard (DIS)
    status within ISO in November, 1990 as DIS10589 [17]. It is reasonable
    to expect that final text for the intra-domain IS-IS standard will be
    available by mid-1991.
    
    
    There are two candidate proposals which address OSI inter-domain
    routing, ECMA TR/50 [3] and Border Router Protocol (BRP) [19], a
    direct derivative of the IETF Border Gateway Protocol [18]. ECMA TR/50
    has been proposed as base text in the ISO/IEC JTC1 SC6/WG2 committee,
    which is responsible for the Network layer of the ISO Reference Model
    [11 ].X3S3.3, the ANSI counterpart to WG2, has incorporated features
    of TR/50 into BRP and submitted this as alternate base text at the
    WG2 meeting in October, 1990. Currently, it is out for ISO Member
    Body comment. The proposed protocol is referred to as the Inter-domain
    Routing Protocol (IDRP) [20].
    
    
    This paper examines the technical implications of NSAP assignment
    under the assumption that ES-IS, intra-domain IS-IS, and IDRP routing
    are deployed to support CLNP.
    
    
    
    
    
    
    Colella, Gardner, & Callon                                     [Page 7]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    3.2   Overview of DIS10589
    
    
    
    The IS-IS intra-domain routing protocol, DIS10589, developed in ISO,
    provides routing for OSI environments. In particular, DIS10589 is
    designed to work in conjunction with CLNP and ES-IS. This section
    briefly describes the manner in which DIS10589 operates.
    
    
    In DIS10589, the internetwork is partitioned into routing domains.
    A routing domain is a collection of ESs and ISs that operate common
    routing protocols and are under the control of a single administra-
    tion. Typically, a routing domain may consist of a corporate network,
    a university campus network, a regional network, or a similar contigu-
    ous network under control of a single administrative organization. The
    boundaries of routing domains are defined by network management by
    setting some links to be exterior, or inter-domain, links. If a link
    is marked as exterior, no DIS10589 routing messages are sent on that
    link.
    
    
    Currently, ISO does not have a standard for inter-domain routing
    (i.e., for routing between separate autonomous routing domains). In
    the interim, DIS10589 uses manual configuration. An inter-domain link
    is statically configured with the set of address prefixes reachable
    via that link, and with the method by which they can be reached (such
    as the DTE address to be dialed to reach that address, or the fact
    that the DTE address should be extracted from the OSI NSAP address).
    
    
    DIS10589 routing makes use of two-level hierarchical routing. A
    routing domain is subdivided into areas (also known as level 1
    subdomains). Level 1 ISs know the topology in their area, including
    all ISs and ESs in their area. However, level 1 ISs do not know the
    identity of ISs or destinations outside of their area. Level 1 ISs
    forward all traffic for destinations outside of their area to a level
    2 IS within their area.
    
    
    Similarly, level 2 ISs know the level 2 topology and know which
    addresses are reachable via each level 2 IS. The set of all level 2
    ISs in a routing domain are known as the level 2 subdomain, which can
    be thought of as a backbone for interconnecting the areas. Level 2
    ISs do not need to know the topology within any level 1 area, except
    to the extent that a level 2 IS may also be a level 1 IS within a
    single area. Only level 2 ISs can exchange data packets or routing
    information directly with external ISs located outside of their
    
    
    
    Colella, Gardner, & Callon                                     [Page 8]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    routing domain.
    
    
    As illustrated in Figure 1, ISO addresses are subdivided into the
    Initial Domain Part (IDP) and the Domain Specific Part (DSP), as spec-
    ified in ISO8348/Addendum 2, the OSI network layer addressing standard
    [14 ](also RFC 941 [6]). The IDP is the part which is standardized by
    ISO, and specifies the format and authority responsible for assigning
    the rest of the address. The DSP is assigned by whatever addressing
    authority is specified by the IDP (see Appendix A for more discussion
    on the top level NSAP addressing authorities). The DSP is further
    subdivided, by DIS10589, into a High Order Part of DSP (HO-DSP), a
    system identifier (ID), and an NSAP selector (SEL). The HO-DSP may
    use any format desired by the authority which is identified by the
    IDP. Together, the combination of [IDP,HO-DSP] identify an area within
    a routing domain and, implicitly, the routing domain containing the
    area. The combination of [IDP,HO-DSP] is therefore referred to as the
    area address.
    
                  _______________________________________________
                  !____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 Hierarchical Address Structure.
    
    
    
    The ID field may be from one to eight octets in length, but must have
    a single known length in any particular routing domain. Each router is
    configured to know what length is used in its domain. The SEL field is
    always one octet in length. Each router is therefore able to identify
    the ID and SEL fields as a known number of trailing octets of the NSAP
    address. The area address can be identified as the remainder of the
    address (after truncation of the ID and SEL fields).
    
    
    Usually, all nodes in an area have the same area address. However,
    sometimes an area might have multiple addresses. Motivations for
    allowing this are several:
    
    
    Colella, Gardner, & Callon                                     [Page 9]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * It might be desirable to change the address of an area. The most
         graceful way of changing an area from having address A to having
         address B is to first allow it to have both addresses A and B, and
         then after all nodes in the area have been modified to recognize
         both addresses, one by one the ESs can be modified to forget
         address A.
    
       * It might be desirable to merge areas A and B into one area. The
         method for accomplishing this is to, one by one, add knowledge of
         address B into the A partition, and similarly add knowledge of
         address A into the B partition.
    
       * It might be desirable to partition an area C into two areas, A and
         B (where A might equal C, in which case this example becomes one
         of removing a portion of an area). This would be accomplished by
         first introducing knowledge of address A into the appropriate ESs
         (those destined to become area A), and knowledge of address B into
         the appropriate nodes, and then one by one removing knowledge of
         address C.
    
    
    
    Since the addressing explicitly identifies the area, it is very easy
    for level 1 ISs to identify packets going to destinations outside
    of their area, which need to be forwarded to level 2 ISs. Thus, in
    DIS10589 the two types of ISs route as follows:
    
    
       * Level 1 intermediate systems -- these nodes route based on the ID
         portion of the ISO address. They route within an area. Level 1 ISs
         recognize, based on the destination address in a packet, whether
         the destination is within the area. If so, they route towards the
         destination. If not, they route to the nearest level 2 IS.
    
       * Level 2 intermediate systems -- these nodes route based on address
         prefixes, preferring the longest matching prefix, and preferring
         internal routes over external routes. They route towards areas,
         without regard to the internal structure of an area; or towards
         level 2 ISs on the routing domain boundary that have advertised
         external address prefixes into the level 2 subdomain. A level 2 IS
         may also be operating as a level 1 IS in one area.
    
    
    
    A level 1 IS will have the area portion of its address manually
    configured. It will refuse to become a neighbor with an IS whose area
    addresses do not overlap its own area addresses. However, if a level 1
    IS has area addresses A, B, and C, and a neighbor has area addresses
    
    
    
    Colella, Gardner, & Callon                                    [Page 10] 
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    B and D, then the level 1 IS will accept the other IS as a level 1
    neighbor.
    
    
    A level 2 IS will accept another level 2 IS as a neighbor, regardless
    of area address. However, if the area addresses do not overlap, the
    link would be considered by both ISs to be level 2 only, and only
    level 2 routing packets would flow on the link. External links (i.e.,
    to other routing domains) must be between level 2 ISs in different
    routing domains.
    
    
    DIS10589 provides an optional partition repair function. In the
    unlikely case that a level 1 area becomes partitioned, this function,
    if implemented, allows the partition to be repaired via use of level 2
    routes.
    
    
    DIS10589 requires that the set of level 2 ISs 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.
    
    
    In unusual cases, a single level 2 IS may lose connectivity to the
    level 2 backbone. In this case the level 2 IS will indicate in its
    level 1 routing packets that it is not attached, thereby allowing
    level 1 ISs in the area to route traffic for outside of the area
    to a different level 2 IS. Level 1 ISs therefore route traffic to
    destinations outside of their area only to level 2 ISs which indicate
    in their level 1 routing packets that they are attached.
    
    
    An ES may autoconfigure the area portion of its address by extracting
    the area portion of a neighboring IS's address. If this is the case,
    then an ES will always accept an IS as a neighbor. Since the standard
    does not specify that the end system must autoconfigure its area
    address, an end system may be pre-configured with an area address. In
    this case the end system would ignore IS neighbors with non-matching
    area addresses.