RFC 1195
Use of OSI IS-IS for routing in TCP/IP and dual environments
4 Subnetwork Dependent Functions 4.1 Link Demultiplexing Dual routers may receive a combination of OSI packets, and IP packets. It is necessary for the dual routers to be able to clearly and unambiguously distinguish the two protocol suites. This problem is not unique to the integrated IS-IS routing protocol. In fact, this problem will occur in any multi-protocol environment. This problem is currently being worked on independently, and is outside of the scope of this specification. In general, the link type is a configuration parameter. For example, whether to use PPP, HDLC, or some other point-to-point protocol over a point-to-point link would be configured. For any particular link type, a method must be defined for encapsulation of both OSI and IP packets. Definition of such methods for common link types is outside of the scope of this specification. IP packets are encapsulated directly over the underlying link layer service, using the normal method for transmssion of IP packets over each type of link. Similarly OSI packets are encapsulated directly over the underlying link layer service, using the normal method for transmission of OSI packets over each type of link. Finally, note that IS-IS packets are encapsulated using the normal method for
transmission of OSI packets over any particular link type. This implies that all IS-IS routers, including IP-only routers, must be able to receive IS-IS packets using the normal encapsulation for OSI packets. 4.2 Multiple IP Addresses per Interface The integrated IS-IS allows each router to have multiple IP addresses for each physical interface, up to the maximum number which may be contained in a single "IP Interface Address" field (i.e., up to a maximum of 63 addresses per interface). For example, where there are two logical subnets on the same LAN, the interface may have two IP addresses, one corresponding to each logical subnet. Each IS-IS Hello packet contains a list of IP addresses associated with the physical interface over which the Hello is transmitted. It is permissible to implement routers which conform to the Integrated IS-IS specification which restrict the number of IP addresses per interface. However, IP-capable routers must be able to interact correctly with other routers which assign multiple IP addresses per physical interface (up to the maximum of 63 addresses per interface). Where appropriate (for example, in some cases on point-to-point links), some interfaces may have no IP addresses assigned. In this case, the IS-IS Hello transmitted on that interface may omit the IP Interface Address field, or may include the IP Interface Address field with zero entries. 4.3 LANs, Designated Routers, and Pseudonodes The maintenance of designated routers and pseudonodes is specified in [1], and is not changed by this proposal. In the case that IP-only and dual routers (or OSI-only and dual routers) are mixed on the same LAN in a pure IP area (or a pure OSI area, respectively), any router on the LAN may be elected designated router. However, there is a fundamental difference in the way that OSI and TCP/IP deal with LANs, and other broadcast subnetworks. With OSI, the use of the ES-IS protocol (ISO 9542) allows the end systems and routers to automatically determine their connectivity, thereby allowing all end systems on the LAN to potentially route via any of the routers on the LAN. In contract, TCP/IP explictly assigns subnet identifiers to each local area network. In some cases, a single physical LAN could have multiple subnet identifiers assigned to it. In this case, end systems
(hosts) which have an address on one logical subnet are explicitly precluded from sending IP packets directly to a router whose address places it on a different logical subnet. Each router is manually configured to know which subnets it can reach on each interface. In the case that there are multiple logical subnets on the same LAN, each router can only exchange IP packets with those end systems which are on the same logical subnet. This implies that it is not sufficient for the pseudonode LSP to announce all subnets on the LAN (i.e., all [IP address, subnet mask] pairs reachable on the LAN). It is therefore necessary for each router to announce in its LSPs those subnets which it can reach on each interface, including interfaces to broadcast subnetworks such as LANs. The pseudonode LSP does not specify the IP addresses which are reachable on the LAN (i.e., does not contain the the IP reachability field). As specified elsewhere (see the forthcoming update to the "Requirements of IP Gateways" [4]), routers may send ICMP redirects only if: (i) the IP packet is being forwarded over the same physical interface over which it arrived; and (ii) the source address of the forwarded IP packet, the IP address of this router's interface (as indicated by the source address of the ICMP redirect), and the IP address of the router to which the packet is being redirected (again, as indicated in the ICMP redirect) are all on the same IP subnet. 4.4 Maintaining Router Adjacencies The IS-IS determines whether an adjacency is to be established between two routers using means which are independent of the IP interface addresses of the routers. Where multiple logical subnets occur on the same physical LAN, this potentially allows adjacencies to be brought up between two routers which share physical connectivity to each other, but which don't have a logical subnet in common. IP-capable IS-IS routers therefore must be able to forward IP packets over existing adjacencies to routers with which they share physical connectivity, even when the IP address of the adjacent interface of the neighboring router is on a different logical IP subnet. For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links. The "protocols supported" field (defined in section 5 below) must be present in all IS-IS Hello packets sent by dual and IP-only routers. If this field is missing, then it is assumed that the packet was transmitted by an OSI-only router. Similarly, those 9542 ISHs sent
over point-to-point links, where there is (or may be) another IS-IS router at the other end of the point-to-point link, must also contains the "protocols supported" field. Note that if this field is mistakenly sent in a 9542 ISH where there is an ordinary OSI-only End System at the other end of the link, then (in accordance to ISO 9542) the End System is required to ignore the field and interpret the ISH correctly. It is therefore safe to always include this field in ISHs sent over point-to-point links. Dual routers must operate in a dual fashion on every link in the routing domain over which they are running IS-IS. Thus, the value of the "protocols supported" field must be identical on every link (i.e., for any one router running IS-IS, all of the Hellos and LSPs transmitted by it must contain the same "protocols supported" values). 4.5 Forwarding to Incompatible Routers There may be times when a dual router has to forward an IP packet to an OSI-only router, or forward an OSI packet to an IP-only router. In this case the packet must be discarded. An error report may be transmitted, in accordance with the IP or ISO 8473 specification (respectively). The reason for discard specified in the error report should specify "destination host unreachable" (for IP), or "destination unreachable" (for OSI). Similarly, due to errors, in some cases an IP-only router may have to forward an IP packet to an OSI-only router. Again, the packet must be discarded, as specified above. This may only occur if IP-only and OSI-only routers occur in the same area, which is a configuration error. 5 Structure and Encoding of PDUs This clause describes the additional packet fields for use of the ISO IS-IS Intra-Domain Routing protocol in pure IP and dual environments. Specifically, the same packet types are used as in IS-IS [1], and all fixed fields remain the same. Additional variable length fields are defined in this section. 5.1 Overview of IS-IS PDUs The packets used in IS-IS routing protocol fall into three main classes: (i) Hello Packets; (ii) Link State Packets (LSPs); and (iii) Sequence Number Packets (SNPs). Hello packets are used to initialize and maintain adjacencies between neighboring routers. There are three types of IS-IS Hello packets:
(i) "Level 1 LAN IS to IS Hello PDUs" are used by level 1 routers on broadcast LANs. (ii) "Level 2 LAN IS to IS Hello PDUs" are used by level 2 routers on broadcast LANs. (iii) "Point-to-Point IS to IS Hello PDUs" are used on non-broadcast media, such as point-to-point links, or general topology subnetworks. On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links. Link State Packets (LSPs) are used to exchange link state information. There are two types of LSPs: (i) "Level 1 Link State PDUs" are transmitted by level 1 routers. (ii) "Level 2 Link State PDUs" are transmitted by level 2 routers. Note that level 2 routers will, in most cases, also be level 1 routers, and will therefore transmit both sorts of LSPs. Sequence number PDUs are used to ensure that neighboring routers have the same notion of what is the most recent LSP from each other router. The sequence number PDUs therefore serve a similar function to acknowledgement packets, but allow more efficient operation. There are four types of sequence number packets: (i) "Level 1 Complete Sequence Numbers PDU"; (ii) "Level 2 Complete Sequence Numbers PDU"; (iii) "Level 1 Partial Sequence Numbers PDU"; and (iv) "Level 2 Partial Sequence Numbers PDU". A partial sequence number packet lists the most recent sequence number of one or more LSPs, and operates much like an acknowlegement. A partial sequence number packet differs from an conventional acknowledgement in the sense that it may acknowlege multiple LSPs at once, and in the sense that it may act as a request for information. A complete sequence number packet contains the most recent sequence number of all LSPs in the database. A complete sequence number packet may therefore be used to ensure synchronization of the database between adjacent routers either periodically, or when a link first comes up. 5.2 Overview of IP-Specific Information for IS-IS There are six new fields defined for the Integrated IS-IS: (i) "Protocols Supported"; (ii) "IP Interface Address"; (iii) "Authentication Information"; (iv) "IP Internal Reachability Information"; (v) "IP External Reachability Information"; and (vi) "Inter-Domain Routing Protocol Information". The "Protocols Supported" field identifies the protocols which are
supported by each router. This field must be included in all IS-IS Hello packets and all LSPs with LSP number 0 transmitted by IP- capable routers. If this field is not included in an IS-IS Hello packet or an LSP with LSP number 0, it may be assumed that the packet was transmitted by an OSI-only router. The "Protocols Supported" field must also be included in ISO 9542 ISHs send by IP-capable routers over point-to-point links to other IS-IS routers. The "IP Interface Address" is included in all IS-IS Hello packets and LSPs transmitted by IP-only and dual routers. In the Hello packets, this field occurs once only, and contains the IP address(es) of the interface on which the Hello packet is transmitted (up to a maximum of 63 IP addresses on each interface). If an IS-IS Hello is transmitted over an interface which does not have an IP address assigned, then this field may be omitted, or may be included with zero entries. In Link State Packets, this field contains a list of one or more IP addresses corresponding to one or more interfaces of the router which originates the LSP. Each IP-capable router must include this field in its LSPs. This field may occur multiple times in an LSP, and may occur in an LSP with any LSP number. The "Authentication Information" field is optional in all IS-IS PDUs. If used, it contains information used to authenticate the packet. All IS-IS packets (including 9542 IS Hellos) may be authenticated by use of this field. The "IP Internal Reachability Information" field may be present in all LSPs transmitted by IP-capable routers. If present, it identifies a list of zero or more [IP address, subnet mask, metrics] reachable by the router which originates the LSP. Each entry must contain a default metric, and may contain delay, expense, and error metrics. If an IP-capable router does not directly reach any IP addresses, then it may omit this field, or may include the field with zero [IP address, subnet mask, metrics] entries. If included in level 1 LSPs, this field includes only entries directly reachable by the router which originates the LSP, via one of its interfaces. If included in level 2 LSPs, this field includes only entries reachable by the router which originates the LSP, either via one of its interfaces, or indirectly via level 1 routing. This field may occur multiple times in an LSP, and may occur in an LSP with any LSP number. The "IP External Reachability Information" field may be present in level 2 LSPs transmitted by level 2 IP-capable routers. If present, it identifies a list of zero or more [IP address, subnet mask, metrics] entries reachable by the router which originates the level 2 LSP. Each entry must contain a default metric, and may contain delay, expense, and error metrics. Each entry may contain metrics of type "internal", or of type "external". If a level 2 router does not have
any external routes (via neighboring routers in other routing domains), when it may omit this field, or may include the field with zero entries. This field includes only entries reachable by the router which originates the LSP, via a direct link to an external router. This field may occur multiple times in a level 2 LSP, and may occur in an LSP with any LSP number. The "Inter-Domain Routing Protocol Information" field may be present in level 2 LSPs transmitted by level 2 IP-capable routers. This field is transmitted for the convenience of the external routing protocol, and is not used by the IS-IS. For example, this may be used to allow border routers to find each other. This field may occur multiple times in a level 2 LSP, and may occur in an LSP with any LSP number. The DP 10589 version of the OSI IS-IS does not currently allow addition of TLV-encoded variable length fields to Sequence Number Packets. However, this is being corrected in future versions of 10589. In addition, this is expected to be the only correction to future versions of 10589 that is not backward-compatible with the DP version. The Integrated IS-IS therefore makes use of a corrected version of DP 10589, such that the encoding of SNPs has been fixed. The correct encoding of sequence number packets (as is expected to appear in future versions of ISO 10589) is given in Annex B of this specification. All IP-specific information is encoded in IS-IS packets as variable length fields. All variable length fields in IS-IS are encoded as follows: No. of Octets +---------------------------+ | CODE | 1 +---------------------------+ | LENGTH | 1 +---------------------------+ | VALUE | LENGTH +---------------------------+ Figure 3 - Encoding of Variable Length Fields Any codes in a received PDU that are not recognised shall be ignored and, for those packets which are forwarded (specifically Link State Packets), passed on unchanged. In general, an IS-IS PDU may contain multiple variable length fields, some of which contain OSI-specific information (specified in [1]) and some of which contain IP-specific information (specified below). Except where explicitly stated otherwise, these variable length
fields may occur in any order. 5.3 Encoding of IP-Specific Fields in IS-IS PDUs This section specifies the detailed encoding of all IP-specific fields in IS-IS PDUs. Where a particular field may be present in more than one type of PDU, the field is repeated for each type of PDU to which it applies. Bit and octet numbering is the same as in [1]. In particular, octets in a PDU are numbered starting from 1, in increasing order. Bits in an octet are numbered from 1 to 8, where bit 1 is the least significant bit and is pictured on the right. When consecutive octets are used to represent a number, the lower octet number has the most significant value. 5.3.1 Level 1 LAN IS to IS Hello PDU - Additional codes for IP support are: 7 Protocols Supported -- the set Network Layer Protocol Identifiers for Network Layer protocols that this Intermediate System is capable of relaying x CODE - 129 x LENGTH - total length of the value field (one octet per protocol supported). x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each supported data protocol. No. of Octets +---------------------------+ | NLPID | 1 +---------------------------+ : : : : |---------------------------| | NLPID | 1 +---------------------------+ NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier. 7 IP Interface Address -- the IP address(es) of the interface corresponding to the SNPA over which this PDU is to be transmitted. x CODE - 132 x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
7 Authentication Information -- Information used to authenticate the
PDU
x CODE - 133
x LENGTH - total length of the value field.
x VALUE - TBD.
5.3.2 Level 2 LAN IS to IS Hello PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
x CODE - 129
x LENGTH - total length of the value field (one octet per protocol
supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Address -- The IP address(es) of the interface
corresponding to the SNPA over which this PDU is to be transmitted.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.3 Point-to-Point IS to IS Hello PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
x CODE - 129
x LENGTH - total length of the value field (one octet per protocol
supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Address -- The IP address(es) of the interface
corresponding to the SNPA over which this PDU is to be transmitted.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.4 Level 1 Link State PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
This must appear once in LSP number 0.
x CODE - 129
x LENGTH - total length of the value field (one octet per protocol
supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Addresses -- The IP addresss of one or more interfaces
corresponding to the SNPAs enabled on this Intermediate system
(i.e., one or more IP addresses of this router).
This is permitted to appear multiple times, and in an LSP with
any LSP number.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
7 IP Internal Reachability Information -- IP addresses within the
routing domain reachable directly via one or more interfaces on
this Intermediate system.
This is permitted to appear multiple times, and in an LSP with any
LSP number. However, this field must not appear in pseudonode LSPs.
x CODE - 128.
x LENGTH - a multiple of 12.
x VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
DEFAULT METRIC is the value of the default metric for the link
to the listed neighbor. Bit 8 of this field is reserved, and
must be set to zero on tranmission and ignored on reception.
Bit 7 of this field (marked I/E) indicates the metric type
(internal or external) for all four TOS metrics, and must be
set to zero indicating internal metrics.
DELAY METRIC is the value of the delay metric for the link to the
listed neighbor. If this IS does not support this metric it shall
set the bit "S" to 1 to indicate that the metric is unsupported.
Bit 7 of this field is reserved, and must be set to zero on
transmission and ignored on reception.
EXPENSE METRIC is the value of the expense metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set to
zero on transmission and ignored on reception.
ERROR METRIC is the value of the error metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
IP ADDRESS is a 4-octet Internet address
SUBNET MASK is a 4 octet IP subnet mask.
5.3.5 Level 2 Link State PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
This must appear once in LSP number 0.
x CODE - 129
x LENGTH - total length of the value field (one octet per
protocol supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for
each supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Addresses -- The IP addresss of one or more interfaces
corresponding to the SNPAs enabled on this Intermediate system
(i.e., one or more IP addresses of this router).
This is permitted to appear multiple times, and in an LSP with
any LSP number. Where a router is both a level 1 and level 2 router,
it must include the same IP addresses in its level 1 and level 2 LSPs.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE-
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
7 IP Internal Reachability Information -- IP addresses within the
routing domain reachable directly via one or more interfaces on
this Intermediate system.
This is permitted to appear multiple times, and in an LSP with
any LSP number. However, this field must not appear in pseudonode
LSPs.
x CODE - 128.
x LENGTH - a multiple of 12.
x VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
DEFAULT METRIC is the value of the default metric for the link
to the listed neighbor. Bit 8 of this field is reserved, and must
be set to zero on transmission and ignored on reception. Bit 7
of this field indicates the metric type (internal or external)
for all four TOS metrics, and must be set to zero indicating
internal metrics.
DELAY METRIC is the value of the delay metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
EXPENSE METRIC is the value of the expense metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
ERROR METRIC is the value of the error metric for the link to the
listed neighbor. If this IS does not support this metric it shall
set the bit "S" to 1 to indicate that the metric is unsupported.
Bit 7 of this field is reserved, and must be set to zero on
transmission and ignored on reception.
IP ADDRESS is a 4-octet Internet address
SUBNET MASK is a 4 octet IP subnet mask.
7 IP External Reachability Information -- IP addresses outside the
routing domain reachable via interfaces on this Intermediate
system.
This is permitted to appear multiple times, and in an LSP with
any LSP number. However, this field must not appear in pseudonode LSPs.
x CODE - 130.
x LENGTH - a multiple of 12.
x VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
DEFAULT METRIC is the value of the default metric for the
path to the listed IP addresses. Bit 8 of this field is
reserved, and must be set to zero on transmission and ignored
on reception. Bit 7 of this field indicates the metric type
(internal or external) for all four TOS metrics, and may be
set to zero indicating internal metrics, or may be set to 1
indicating external metrics.
DELAY METRIC is the value of the delay metric for the path
to the listed IP addresses. If this IS does not support this
metric it shall set the bit "S" to 1 to indicate that the metric
is unsupported. Bit 7 of this field is reserved, and must be
set to zero on transmission and ignored on reception.
EXPENSE METRIC is the value of the expense metric for the link
to the listed IP addresses. If this IS does not support this
metric it shall set the bit "S" to 1 to indicate that the metric
is unsupported. Bit 7 of this field is reserved, and must be
set to zero on transmission and ignored on reception.
ERROR METRIC is the value of the error metric for the link to
the listed IP addresses. If this IS does not support this metric
it shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set to
zero on transmission and ignored on reception.
IP ADDRESS is a 4-octet Internet address
SUBNET MASK is a 4 octet IP subnet mask
7 Inter-Domain Routing Protocol Information -- Inter-domain routing
protocol information carried transparently through level 2 for
the convenience of any Inter-Domain protocol that may be running
in the boundary ISs.
This is permitted to appear multiple times, and in an LSP with
any LSP number.
x CODE - 131.
x LENGTH - total length of the value field
x VALUE -
No. of Octets
+-------------------------------+
| Inter-Domain Information Type | 1
+-------------------------------+
| External Information | VARIABLE
+-------------------------------+
INTER-DOMAIN INFORMATION TYPE indicates the type of the
external information which is encoded in the field.
EXTERNAL INFORMATION contains inter-domain routing protocol
information, and is passed transparently by the IS-IS protocol.
5.3.6 Level 1 Complete Sequence Numbers PDU
- Additional codes for IP support are:
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.7 Level 2 Complete Sequence Numbers PDU
- Additional codes for IP support are:
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.8 Level 1 Partial Sequence Numbers PDU
- Additional codes for IP support are:
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.9 Level 2 Partial Sequence Numbers PDU
- Additional codes for IP support are:
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.10 ISO 9542 ISH PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
This appears in ISO 9542 ISH PDUs transmitted on point-to-point
links.
x CODE - 129
x LENGTH - total length of the value field (one octet per
protocol supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for
each supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
6 Security Considerations
The integrated IS-IS has a provision for carrying authentication
information in all IS-IS packets. This is extensible to multiple
authentication mechanisms. However, currently the only defined
mechanism is a simple password, transmitted in the clear without
encryption (see Annex D). The use of a simple password does not
provide useful protection against intentional misbehavior. Rather,
this should be thought of as a weak protection against accidental
errors such as accidental mis-configuration. Definition of other
authentication mechanisms is beyond the scope of this document.
Other aspects of security are not discussed in this document.
7 Author's Address Ross Callon Digital Equipment Corporation 550 King Street, LKG 1-2/A19 Littleton, MA 01460-1289 508-486-5009 8 References [1] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 10589, February 1990. [2] "Protocol for Providing the Connectionless-Mode Network Service", ISO 8473, March 1987. [3] "End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service (ISO 8473)", ISO 9542, March 1988. [4] Braden,R., and Postel,J., "Requirements for Internet Gateways", RFC 1009, June 1987. [5] Moy,J., "The OSPF Specification", RFC 1131, October 1989. [6] Postel,J., "Internetwork Protocol", RFC 791, September 1981. [7] Postel,J., "Internet Control Message Protocol", RFC 792, September 1981. [8] "MIB for Use with the Extended OSI IS-IS in TCP/IP and Dual Environments", forthcoming. [9] GOSIP Advanced Requirements Group, "Government Open Systems Interconnection Profile (GOSIP) Version 2.0 [Final Text]", Federal Information Processing Standard, U.S. Department of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, October 1990. [10] "Standard for Local Area Networks and Metropolitan Area Networks: Overview and Architecture of Network Standards", IEEE Standard 802.1a-1990.
Annex A Inter-Domain Routing Protocol Information This annex specifies the contents and encoding of the Inter-Domain Routing Protocol Information (IDRPI) field. This annex is an integral part of the Integrated IS-IS specification. However, it is expected that this annex may be augmented or superceded by future efforts outside of the scope of the IS-IS specification. A.1 Inter-Domain Information Type As specified in sections 3.4 and 5.3, the IDRPI field consists of a one-octet inter-domain information type field, plus a variable external information field. This section specifies initial values for the inter-domain information type field. Other values for inter- domain information type will be assigned and maintained in future versions of the "Assigned Numbers" RFC. The following types have been assigned: Type = 0 reserved Type = 1 local (uses routing-domain specific format) Type = 2 AS Number Tag Type = 1 indicates that the inter-domain routing protocol information uses a format which is local to the routing domain. Type = 2 indicates that the inter-domain routing protocol information includes autonomous system information used to tag IP external reachability information. In this case the inter-domain routing protocol information entry must include a single AS number, which is used to tag all subsequent External IP Reachability entries until the end of the LSP, or until the next occurence of the Inter-Domain Routing Protocol Information field. A.2 Encoding As specified in section 5.3.5, the IDPRI entry is encoded as a variable length field, as follows: x CODE - 131 x LENGTH - total length of the value field x VALUE -
No. of Octets
+-------------------------------+
| Inter-Domain Information Type | 1
+-------------------------------+
| External Information | VARIABLE
+-------------------------------+
INTER-DOMAIN INFORMATION TYPE indicates the type of the
external information which is encoded in the field.
EXTERNAL INFORMATION contains inter-domain routing protocol
information, and is passed transparently by the IS-IS protocol.
The Inter-domain information type field indicates the type of
information which is contained in the external information field, as
follow:
Type = 0 is reserved (must not be sent, and must be ignored on receipt).
Type = 1 indicates that the external information field contains
information which follows a locally specified format.
Type = 2 indicates that the external information field contains an
autonomous system number tag, to be applied to subsequent IP external
reachability information entries. In this case, this "inter-domain
routing protocol information" entry must contain precisely one 2
octet AS number. The AS tag is associated with subsequent IP External
Reachability entries, until the end of the LSP, or until the next
occurence of the Inter-Domain Routing Protocol Information field.
In this case, the VALUE contains the following:
x VALUE -
No. of Octets
+---------------------------------+
| Inter-Domain Information Type=2 | 1
+---------------------------------+
| Autonomous System Number | 2
+---------------------------------+
Annex B Encoding of Sequence Number Packets The Integrated IS-IS protocol defined in this specification makes use of the ISO Draft Proposed standard for Intra-domain routing (ISO DP 10589 [1]) as the base routing protocol, upon which IP support may be added. However, DP 10589 contains a bug regarding encoding of the variable length fields in Sequence Number Packets. In particular, DP 10589 encodes the variable length fields in SNPs in a manner which is not flexible (additional variable length fields cannot be defined for sequence number packets), and which is inconsistent with the encoding of the variable length fields in all other IS-IS and ES-IS packets. The encoding of the variable length fields in SNPs is expected to be fixed in future versions of 10589. Also, this bug represents the only expected change to 10589 which cannot be made backward compatible with existing DP 10589 implementations. For these reasons, the current version of the Integrated IS-IS will use the anticipated future encoding of the variable length part of the SNPs. This should allow future versions of this specification to be compatible with implementations based on this specification. This annex specifies the encoding of SNPs, as amended to fix the encoding of variable length fields. This annex is an integral part of the Integrated IS-IS specification. The encoding of SNPs for OSI-only use is shown in this section. For IP-only or Integrated use, the additional variable length fields specified in sections 5.3.6 through 5.3.9 are also applicable to SNPs.
B.1 Level 1 Complete Sequence Numbers PDU No. of Octets +--------------------------------+ | INTRA-DOMAIN ROUTEING | 1 | PROTOCOL DISCRIMINATOR | +--------------------------------+ | LENGTH INDICATOR | 1 +--------------------------------+ | VERSION/PROTOCOL ID EXT | 1 +--------------------------------+ | RESERVED | 1 +--------------------------------+ | R | R | R | TYPE | 1 +--------------------------------+ | VERSION | 1 +--------------------------------+ | ECO | 1 +--------------------------------+ | USER ECO | 1 +--------------------------------+ | PDU LENGTH | 2 +--------------------------------+ | SOURCE ID | 7 +--------------------------------+ | START LSP ID | 8 +--------------------------------+ | END LSP ID | 8 +================================+==================== | VARIABLE LENGTH FIELDS | VARIABLE +--------------------------------+ - INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant - LENGTH INDICATOR - Header Length in octets (33.) - VERSION/PROTOCOL ID EXTENSION - 1 - RESERVED - transmitted as 0, ignored on receipt - TYPE (bits 1 through 5) - 24. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt. - VERSION - 1 - ECO - transmitted as zero, ignored on receipt
- USER ECO - transmitted as zero, ignored on receipt
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- SOURCE ID - 7 octet ID of Intermediate System (with zero Circuit ID)
generating this Sequence Numbers PDU.
- START LSP ID - 8 octet ID of first LSP in the range covered by this
Complete Sequence Numbers PDU.
- END LSP ID - 8 octet ID of last LSP in the range covered by this
Complete Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
Any codes in a received CSNP that are not recognised are ignored.
Currently defined codes are:
7 LSP Entries -- This may appear multiple times. The option fields,
if they appear more than once, shall appear sorted into ascending
LSPID order.
x CODE - 9
x LENGTH - total length of the value field.
x VALUE - a list of LSP entries of the form:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP SEQ NUMBER - Sequence number of LSP.
7 CHECKSUM - Checksum reported in LSP.
The entries shall be sorted into ascending LSPID order (the LSP
number octet of the LSPID is the least significant octet).
B.2 Level 2 Complete Sequence Numbers PDU No. of Octets +--------------------------------+ | INTRA-DOMAIN ROUTEING | 1 | PROTOCOL DISCRIMINATOR | +--------------------------------+ | LENGTH INDICATOR | 1 +--------------------------------+ | VERSION/PROTOCOL ID EXT | 1 +--------------------------------+ | RESERVED | 1 +--------------------------------+ | R | R | R | TYPE | 1 +--------------------------------+ | VERSION | 1 +--------------------------------+ | ECO | 1 +--------------------------------+ | USER ECO | 1 +--------------------------------+ | PDU LENGTH | 2 +--------------------------------+ | SOURCE ID | 7 +--------------------------------+ | START LSP ID | 8 +--------------------------------+ | END LSP ID | 8 +================================+==================== | VARIABLE LENGTH FIELDS | VARIABLE +--------------------------------+ - INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant - LENGTH INDICATOR - Header Length in octets (33.) - VERSION/PROTOCOL ID EXTENSION - 1 - RESERVED - transmitted as 0, ignored on receipt - TYPE (bits 1 through 5) - 25. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt. - VERSION - 1 - ECO - transmitted as zero, ignored on receipt
- USER ECO - transmitted as zero, ignored on receipt
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- SOURCE ID - 7 octet ID of Intermediate System (with zero Circuit ID)
generating this Sequence Numbers PDU.
- START LSP ID - 8 octet ID of first LSP in the range covered by this
Complete Sequence Numbers PDU.
- END LSP ID - 8 octet ID of last LSP in the range covered by this
Complete Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
Any codes in a received CSNP that are not recognised are ignored.
Currently defined codes are:
7 LSP Entries -- this may appear multiple times. The option fields,
if they appear more than once, shall appear sorted into ascending
LSPID order.
x CODE - 9
x LENGTH - total length of the value field.
x VALUE - a list of LSP entries of the form:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP SEQ NUMBER - Sequence number of LSP.
7 CHECKSUM - Checksum reported in LSP.
The entries shall be sorted into ascending LSPID order (the LSP
number octet of the LSPID is the least significant octet).
B.3 Level 1 Partial Sequence Numbers PDU No. of Octets +--------------------------------+ | INTRA-DOMAIN ROUTEING | 1 | PROTOCOL DISCRIMINATOR | +--------------------------------+ | LENGTH INDICATOR | 1 +--------------------------------+ | VERSION/PROTOCOL ID EXT | 1 +--------------------------------+ | RESERVED | 1 +--------------------------------+ | R | R | R | TYPE | 1 +--------------------------------+ | VERSION | 1 +--------------------------------+ | ECO | 1 +--------------------------------+ | USER ECO | 1 +--------------------------------+ | PDU LENGTH | 2 +--------------------------------+ | SOURCE ID | 7 +================================+==================== | VARIABLE LENGTH FIELDS | VARIABLE +--------------------------------+ - INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant - LENGTH INDICATOR - Header Length in octets (17.) - VERSION/PROTOCOL ID EXTENSION - 1 - RESERVED - transmitted as 0, ignored on receipt - TYPE (bits 1 through 5) 26. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt. - VERSION - 1 - ECO - transmitted as zero, ignored on receipt - USER ECO - transmitted as zero, ignored on receipt - PDU LENGTH - Entire Length of this PDU, in octets, including header - SOURCE ID - 7 octet ID of Intermediate system (with zero Circuit ID)
generating this Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
Any codes in a received PSNP that are not recognised are ignored.
Currently defined codes are:
7 LSP Entries - this may appear multiple times. The option fields,
if they appear more than once, shall appear sorted into ascending
LSPID order.
x CODE - 9
x LENGTH - total length of the value field.
x VALUE - a list of LSP entries of the form:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP SEQ NUMBER - Sequence number of LSP.
7 CHECKSUM - Checksum reported in LSP.
The entries shall be sorted into ascending LSPID order (the LSP number
octet of the LSPID is the least significant octet).
B.4 Level 2 Partial Sequence Numbers PDU No. of Octets +--------------------------------+ | INTRA-DOMAIN ROUTEING | 1 | PROTOCOL DISCRIMINATOR | +--------------------------------+ | LENGTH INDICATOR | 1 +--------------------------------+ | VERSION/PROTOCOL ID EXT | 1 +--------------------------------+ | RESERVED | 1 +--------------------------------+ | R | R | R | TYPE | 1 +--------------------------------+ | VERSION | 1 +--------------------------------+ | ECO | 1 +--------------------------------+ | USER ECO | 1 +--------------------------------+ | PDU LENGTH | 2 +--------------------------------+ | SOURCE ID | 7 +================================+==================== | VARIABLE LENGTH FIELDS | VARIABLE +--------------------------------+ - INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant - LENGTH INDICATOR - Header Length in octets (17.) - VERSION/PROTOCOL ID EXTENSION - 1 - RESERVED - transmitted as 0, ignored on receipt - TYPE (bits 1 through 5) - 27. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt. - VERSION - 1 - ECO - transmitted as zero, ignored on receipt - USER ECO - transmitted as zero, ignored on receipt - PDU LENGTH - Entire Length of this PDU, in octets, including header - SOURCE ID - 7 octet ID of Intermediate system (with zero Circuit ID)
generating this Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
Any codes in a received PSNP that are not recognised are ignored.
Currently defined codes are:
7 LSP Entries -- this may appear multiple times. The option fields,
if they appear more than once, shall appear sorted into ascending
LSPID order.
x CODE - 9
x LENGTH - total length of the value field.
x VALUE - a list of LSP entries of the form:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP SEQ NUMBER -Sequence number of LSP.
7 CHECKSUM - Checksum reported in LSP.
The entries shall be sorted into ascending LSPID order (the LSP
number octet of the LSPID is the least significant octet).
(next page on part 3)
