rfc1195.txt

中、英文RFC文档大全打包下载完全版 .

   domain. The ID must be assigned such that every router in the routing
   domain has a unique value. It is recommended that one of the
   following methods is used:

   1)use a unique IEEE 802 48 bit station ID

   2)use the value hex "02 00" prepended to an IP address of the router.

   IEEE 802 addresses, if used, must appear in IEEE canonical format.

   Since the IEEE 802 station IDs are assigned to be globally unique,
   use of these values clearly assures uniqueness in the area. Also, all
   assigned IEEE 802 station IDs have the global/local bit set to zero.
   Prepending the indicated pattern to the front of the IP address
   therefore assures that format (2) illustrated above cannot produce
   addresses which collide with format (1). Finally, to the extent that
   IP addresses are also globally unique, format (2) will produce unique
   IDs for routers.

   The indicated hex value is specified in IEEE 802 canonical form [10].
   In IEEE 802 addresses, the multicast bit is the least significant bit
   of the first byte. The global/local bit is the next least significant
   bit of the first byte. The indicated prefix therefore sets the
   global/local bit to 1, and all other bits in the first two octets to
   0.

   Note that within an area, whether ISO addresses are configured into
   the routers through ISO address assignment, or whether the ISO-style
   address is generated directly from the AS number and IP address, all
   routers within an area must have the same high order part of address
   (AFI, ICD, DFI, AA, RD, and Area). This ISO-style address is used in
   IS-IS Hello messages and is the basis by which routers recognize
   whether neighbor nodes are in or out of their area.




Callon                                                         [Page 21]

RFC 1195         OSI ISIS for IP and Dual Environments     December 1990


3.4 External Links

   External connectivity (i.e., communications with routers outside of
   the routing domain) is done only by level 2 routers. The ISO version
   of IS-IS allows external OSI routes to be reported as "reachable
   address prefixes" in level 2 LSPs. The integrated IS-IS also allows
   external IP reachable addresses (i.e., IP addresses reachable via
   inter-domain routing) to be reported in level 2 LSPs in the "IP
   external reachability information" field. External OSI and external
   IP routes are handled independently.

   The routes announced in IP external reachability information entries
   include all routes to outside of the routing domain. This includes
   routes learned from OSPF, EGP, RIP, or any other external protocol.

   External routes may make use of "internal" or "external" metrics.
   Internal metrics are comparable with the metrics used for internal
   routes. Thus in choosing between an internal route, and an external
   route using internal metrics, the metric values may be directly
   compared. In contrast, external metrics cannot be directly compared
   with internal metrics. Any route defined solely using internal
   metrics is always preferred to any route defined using external
   metrics. When an external route using external metrics must be used,
   the lowest value of the external metric is preferred regardless of
   the internal cost to reach the appropriate exit point.

   It is useful, in the operation of external routing protocols, to
   provide a mechanism for border routers (i.e., routers in the same
   routing domain, which have the ability to route externally to other
   domains) to determine each other's existence, and to exchange
   external information (in a form understood only by the border routers
   themselves). This is made possible by inclusion of "inter-domain
   routing protocol information" fields in level 2 LSPs. The inter-
   domain routing protocol information field is not included in
   pseudonode LSPs.

   In general there may be multiple types of external inter-domain
   routing protocol information exchanged between border routers. The
   IS-IS therefore specifies that each occurance of the inter-domain
   routing protocol information field include a "type" field, which
   indicates the type of inter-domain routing protocol information
   enclosed. Values to be used in the type field will be specified in
   future versions of the "Assigned Numbers" RFC. Initial values for
   this field are specified in Annex A of this specification.

   Information contained in the inter-domain routing protocol
   information field will be carried in level 2 LSPs, and will therefore
   need to be stored by all level 2 routers in the domain. However, only



Callon                                                         [Page 22]

RFC 1195         OSI ISIS for IP and Dual Environments     December 1990


   those level 2 routers which are directly involved in external routing
   will use this information. In designing the use of this field, it is
   important to carefully consider the implications that this may have
   on storage requirements in level 2 routers (including those level 2
   routers which are not directly involved in external routing).

   The protocols used to exchange routing information directly between
   border routers, and external routers (in other routing domains /
   autonomous systems) are outside of the scope of this specification.

3.5 Type of Service Routing

   The integrated IS-IS protocol provides IP Type of Service (TOS)
   routing, through use of the Quality of Service (QOS) feature of IS-
   IS. This allows for routing on the basis of throughput (the default
   metric), delay, expense, or residual error probability. Note than any
   particular packet may be routed on the basis of any one of these four
   metrics. Routing on the basis of general combinations of metrics is
   not supported.

   The support for TOS/QOS is optional. If a particular packet calls for
   a specific TOS, and the correct path from the source to destination
   is made up of routers all of which support that particular TOS, then
   the packet will be routed on the optimal path. However, if there is
   no path from the source to destination made up of routers which
   support that particular type of service, then the packet will be
   forwarded using the default metric instead. This allows for TOS
   service in those environments where it is needed, while still
   providing acceptable service in the case where an unsupported TOS is
   requested.

   NOTE - IP does not have a cost TOS. There is therefore no mapping of
   IP TOS metrics which corresponds to the minimum cost metric.

   The IP TOS field is mapped onto the four available metrics as
   follows:

   Bits 0-2 (Precedence):  This field does not affect the route, but
                           rather may affect other aspects of packet
                           forwarding.

   Bits 3 (Delay), 4 (Throughput) and 5 (Reliability):

           000     (all normal)            Use default metric

           100     (low delay)             Use delay metric

           010     (high throughput)       Use default metric



Callon                                                         [Page 23]

RFC 1195         OSI ISIS for IP and Dual Environments     December 1990


           001     (high reliabiity)       Use reliability metric

           other                           Use default metric

3.6 Multiple LSPs and SNPs

   In some cases, IS-IS packets (specifically Link State Packets and
   Complete Sequence Number Packets) may be too large to fit into one
   packet. The OSI IS-IS [1] allows for LSPs and CSNPs to be split into
   multiple packets. This is independent of ISO 8473 segmentation, and
   is also independent of IP fragmentation. Use of independent multiple
   packets has the advantages (with respect to segmentation or
   fragmentation) that: (i) when information in the IS-IS changes, only
   those packets effected need to be re-issued; (ii) when a single
   packet is received, it can be processed without the need to receive
   all other packets of the same type from the same router before
   beginning processing.

   The Integrated IS-IS makes use of the same multiple packet function,
   as defined in [1]. IP-specific fields in IS-IS packets may be split
   across multiple packets. As specified in section 5 ("Structure and
   Encoding of PDUs"), some of the IP-specific fields (those which may
   be fairly long) may be split into several occurences of the same
   field, thereby allowing splitting of the fields across different
   packets.

   Multiple LSPs from the same router are distinguished by LSP number.
   Generally, most variable length fields may occur in an LSP with any
   LSP number. Some specific variable length fields may be required to
   occur in LSP number 0. Except where explicitly stated otherwise, when
   an IS-IS router issues multiple LSPs, the IP-specific fields may
   occur in an LSP with any LSP number.

   Complete Sequence Number Packets may be split into multiple packets,
   with the range to which each packet applies explicitly reported in
   the packet. Partial Sequence Number Packets are inherently partial,
   and so can easily be split into multiple packets if this is
   necessary. Again, where applicable, IP-specific fields may occur in
   any SNP.

3.7 IP-Only Operation

   For IP-only routers, the format for IS-IS packets remains unchanged.
   However, there are some variable length fields from the IS-IS packets
   that can be omitted. Specifically:






Callon                                                         [Page 24]

RFC 1195         OSI ISIS for IP and Dual Environments     December 1990


   IS-IS Hello Packets:

           - no change

   IS-IS Link State Packets:

           - the "End Systems Neighbours" entries are omitted

           - the "Prefix Neighbours" entries are omitted

   IS-IS Sequence Number Packets:

           - no change

3.8 Encapsulation

   Future versions of the Integated IS-IS may specify optional
   encapsulation mechanisms for partition repair, and for forwarding
   packets through incompatible routers (i.e., for forwarding OSI
   packets through IP-only routers, and forwarding IP packets through
   OSI-only routers). The details of encapsulation and decapsulation are
   for further study. Routers complying with the Integrated IS-IS are
   not required to implement encapsulation nor decapsulation.

3.9 Authentication

   The authentication field allows each IS-IS packet to contain
   information used to authenticate the originator and/or contents of
   the packet.  The authentication information contained in each packet
   is used to authenticate the entire packet, including OSI and IP
   parts. If a packet is received which contains invalid authentication
   information, then the entire packet is discarded. If an LSP or SNP is
   split into multiple packets (as described in section 3.6), then each
   is authenticated independently.

   Use of the authentication field is optional. Routers are not required
   to be able to interpret authentication information. As with other
   fields in the integrated IS-IS, if a router does not implement
   authentication then it will ignore any authentication field that may
   be present in an IS-IS packet.

   Annex D specifies a proposed use of the authentication field.

3.10 Order of Preference of Routes / Dijkstra Computation

   We define the term "IP reachability entry" to mean the combination of
   the [IP address, subnet mask]. The Dijkstra calculation must
   calculate routes to each distinct IP reachability entry. For the



Callon                                                         [Page 25]

RFC 1195         OSI ISIS for IP and Dual Environments     December 1990


   Dijkstra calculation, each IP reachability entry can be treated in
   much the same manner as an OSI end system. Naturally, each IP
   reachability entry is treated as distinct from any OSI end systems
   which may also be reachable in the same area or routing domain.

   For any particular IP reachability entry, this is the same as another
   entry if and only if: (i) the subnet masks are identical; and (ii)
   for each bit in the subnet mask which has the value "1", the IP
   address is identical. This can easily be tested by zeroing those bits
   in the IP address which correspond to a zero bit in the mask, and
   then treating the entry as a 64 bit quantity, and testing for
   equality between different 64 bit quantities. The actual calculation
   of routes to IP reachability entries is therefore no more complex
   than calculation of routes to OSI end systems (except for the
   replacement of a 48-bit test with a 64-bit test).

   The Dijkstra computation does not take into consideration whether a
   router is IP-only, OSI-only, or dual. The topological restrictions
   specified in section 1.4 ensure that IP pac