⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1195.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 5 页
字号:

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


1.4 Support of Mixed Routing Domains

   The integrated IS-IS proposal specifically allows for three types of
   routing domains:

   - Pure IP

   - Pure OSI

   - Dual

   In a pure IP routing domain, all routers must be IP-capable. IP-only
   routers may be freely mixed with dual routers. Some fields
   specifically related to OSI operation may be included by dual
   routers, and will be ignored by IP-only routers. Only IP traffic will
   be routed in an pure IP domain. Any OSI traffic may be discarded
   (except for the IS-IS packets necessary for operation of the routing
   protocol).

   In a pure OSI routing domain, all routers must be OSI-capable.  OSI-
   only routers may be freely mixed with dual routers. Some fields
   specifically related to IP operation may be included by dual routers,
   and will be ignored by OSI-only routers. Only OSI traffic will be
   routed in a pure OSI domain. Any IP traffic may be discarded.

   In a dual routing domain, IP-only, OSI-only, and dual routers may be
   mixed on a per-area basis. Specifically, each area may itself be
   defined to be pure IP, pure OSI, or dual.

   In a pure IP area within a dual domain, IP-only and dual routers may
   be freely mixed. Only IP traffic can be routed by level 1 routing
   within a pure-IP area.

   In a pure-OSI area within a dual domain, OSI-only and dual routers
   may be freely mixed. Only OSI traffic can be routed by level 1
   routing within a pure OSI area.

   In a dual area within a dual routing domain only dual routers may be
   used. Both IP and OSI traffic can be routed within a dual area.

   Within a dual domain, if both IP and OSI traffic are to be routed
   between areas then all level 2 routers must be dual.

1.5 Advantages of Using Integrated IS-IS

   Use of the integrated IS-IS protocol, as a single protocol for
   routing both IP and OSI packets in a dual environment, has
   significant advantages over using separate protocols for



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


   independently routing IP and OSI traffic.

   An alternative approach is known as "Ships In the Night" (S.I.N.).
   With the S.I.N. approach, completely separate routing protocols are
   used for IP and for OSI. For example, OSPF [5] may be used for
   routing IP traffic, and IS-IS [1] may be used for routing OSI
   traffic. With S.I.N., the two routing protocols operate more or less
   independently. However, dual routers will need to implement both
   routing protocols, and therefore there will be some degree of
   competition for resources.

   Note that S.I.N. and the integrated IS-IS approach are not really
   completely separate options. In particular, if the integrated IS-IS
   is used within a routing domain for routing of IP and OSI traffic, it
   is still possible to use other independent routing protocols for
   routing other protocol suites.

   In the future, optional extensions to IS-IS may be defined for
   routing other common protocol suites. However, such future options
   are outside of the scope of this document. This section will compare
   integrated IS-IS and S.I.N. for routing of IP and OSI only.

   A primary advantage of the integrated IS-IS relates to the network
   management effort required. Since the integrated IS-IS provides a
   single routing protocol, within a single coordinated routing domain
   using a single backbone, this implies that there is less information
   to configure. This combined with a single coordinated MIB simplifies
   network management.

   Note that the operation of two routing protocols with the S.I.N.
   approach are not really independent, since they must share common
   resources. However, with the integrated IS-IS, the interactions are
   explicit, whereas with S.I.N., the interactions are implicit. Since
   the interactions are explicit, again it may be easier to manage and
   debug dual routers.

   Another advantage of the integrated IS-IS is that, since it requires
   only one routing protocol, it uses fewer resources. In particular,
   less implementation resources are needed (since only one protocol
   needs to be implemented), less CPU and memory resources are used in
   the router (since only one protocol needs to be run), and less
   network resources are used (since only one set of routing packets
   need to be transmitted). Primarily this translates into a financial
   savings, since each of these three types of resources cost money.
   This implies that dual routers based on the integrated IS-IS should
   be less expensive to purchase and operate than dual routers based on
   S.I.N.




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


   Note that the operation of two routing protocols with the S.I.N.
   approach are not really independent, since they must share common
   resources. For example, if one routing protocol becomes unstable and
   starts to use excessive resources, the other protocol is likely to
   suffer. A bug in one protocol could crash the other. However, with
   the integrated IS-IS, the interactions are explicit and are defined
   into the protocol and software interactions. With S.I.N., the
   interactions are implicit.

   The use of a single integrated routing protocol similarly reduces the
   likely frequency of software upgrades. Specifically, if you have two
   different routing protocols in your router, then you have to upgrade
   the software any time EITHER of the protocols change. If you make use
   of a single integrated routing protocol, then software changes are
   still likely to be needed, but less frequently.

   Finally, routing protocols have significant real time requirements.
   In IS-IS, these real time requirements have been explicitly
   specified. In other routing protocols, these requirements are
   implicit. However, in all routing protocols, there are real time
   guarantees which must be met in order to ensure correct operation. In
   general, it is difficult enough to ensure compliance with real time
   requirements in the implementation of a single real time system. With
   S.I.N., implementation of two semi-independent real-time protocols in
   a single device makes this more difficult.

   Note that both integrated IS-IS and S.I.N. allow for independence of
   external routes (for traffic from/to outside of the routing domain),
   and allow for independent assignment of OSI and TCP/IP addresses.

2 Symbols and Abbreviations

AA              Administrative Authority
                (a three octet field in the GOSIP version 2.0 NSAP
                address format)

AFI             Authority and Format Identifier
                (the first octet of all OSI NSAP addresses -- identifies
                format of the rest of the address)

CLNP            Connection-Less Network Protocol
                (ISO 8473, the OSI connectionless network layer protocol
                -- very similar to IP)

DFI             DSP Format Identifier
                (a one octet field in the GOSIP version 2.0 NSAP address
                format)




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


ES              End System
                (The OSI term for a host)

ES-IS           End System to Intermediate System Routeing Exchange
                Protocol (ISO 9542 -- OSI protocol between routers
                and end systems)

ICD             International Code Designator
                (ISO standard for identifying organizations)

IP              Internetwork Protocol
                (an Internet Standard Network Layer Protocol)

IS              Intermediate System
                (The OSI term for a router)

IS-IS           Intermediate System to Intermediate System Routeing
                Exchange Protocol
                (the ISO protocol for routing within a single
                routing domain)

IS-IS Hello     An Hello packet defined by the IS-IS protocol
                (a type of packet used by the IS-IS protocol)

ISH             An Hello packet defined by ISO 9542 (ES-IS protocol).
                (not the same as IS-IS Hello)

ISO             International Organization for Standardization
                (an international body which is authorized to write
                standards of many kinds)

LSP             Link State Packet
                (a type of packet used by the IS-IS protocol)

NLPID           Network Layer Protocol ID
                (A one-octet field identifying a network layer protocol)

NSAP            Network Service Access Point
                (a conceptual interface point at which the network
                service is made available)

SEL             NSAP Selector
                (the last octet of NSAP addresses, also called NSEL)

OSI             Open Systems Interconnection
                (an international standard protocol architecture)





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


RD              Routing Domain
                (the set of routers and end systems using a single
                instance of a routing protocol such as IS-IS)

SNPA            Subnetwork Point of Attachment
                (a conceptual interface at which a subnetwork service
                is provided)

TCP             Transmission Control Protocol
                (an Internet Standard Transport Layer Protocol)

TCP/IP          The protocol suite based on TCP, IP, and related
                protocols (the Internet standard protocol
                architecture)

3 Subnetwork Independent Functions

3.1 Exchange of Routing Information

   The exchange of routing information between routers makes use of the
   normal routing packet exchange as defined in the OSI IS-IS routing
   spec, with additional IP-specific information added to the IS-IS
   routing packets.

   The IS-IS protocol provides for the inclusion of variable length
   fields in all IS-IS packets. These fields are encoded using a "Code,
   Length, Value" triplet, where the code and length are encoded in one
   octet each, and the value has the length specified (from 0 to 254
   octets). IS-IS requires that: "Any codes in a received PDU that are
   not recognised are ignored and passed through unchanged". This
   requirement applies to all routers implementing IS-IS, including
   OSI-only, IP-only, and dual routers. This allows IP-specific
   information to be encoded in a manner which OSI-only routers will
   ignore, and also allows OSI-specific information to be encoded in a
   manner which IP-only routers will ignore.

   IP-capable (i.e., all IP-only and dual) routers need to know what
   network layer protocols are supported by other routers in their area.
   This information is made available by inclusion of a "protocols
   supported" field in all IS-IS Hello and Link State Packets. This
   field makes use of the NLPID (Network Layer Protocol Identifier),
   which is a one-octet value assigned by ISO to identify network level
   protocols. NLPID values have been assigned to ISO 8473 and to IP.

   IP-capable routers need to know the IP address of the adjacent
   interface of neighboring routers. This is required for sending ICMP
   redirects (when an IP-capable router sends an ICMP redirect to a
   host, it must include the IP address of the appropriate interface of


⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -