Network Working Group ANSI X3S3.3 86-118 Request for Comments: 995 ISO TC97/SC6/N 4053 April 1986 I S O INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ORGANISATION INTERNATIONALE DE NORMALISATION ______________________________________________________________________ | | | ISO/TC 97/SC 6 | | TELECOMMUNICATIONS AND INFORMATION | | EXCHANGE BETWEEN SYSTEMS | | Secretariat: USA (ANSI) | | | | | |_____________________________________________________________________| Title: End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 Source: SC6/WG2 Project 97.6.41 ___________________________________________________________________________ |This document is a progression of SC6/N3862, edited to incorporate member | |body comments and discussion at the Florence meeting of SC6/WG2. Pursuant | |to Recommendation 5 of that meeting, comments from member bodies on this | |revision text are requested for discussion at the Tokyo meeting of SC6 | |and WGs. | |__________________________________________________________________________| ISO N4053 [Page 1] RFC 995 December 1986 Contents 1 Introduction 5 2 Scope and Field of Application 6 3 References 7 SECTION ONE. GENERAL 9 4 Definitions 9 4.1 Reference Model Definitions . . . . . . . . . . . . . . . . . 9 4.2 Network Layer Architecture Definitions . . . . . . . . . . . 9 4.3 Network Layer Addressing Definitions . . . . . . . . . . . . 9 4.4 Local Area Network Definitions . . . . . . . . . . . . . . . 10 4.5 Additional Definitions . . . . . . . . . . . . . . . . . . . . 10 5 Symbols and Abbreviations 10 5.1 Data Units . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 Protocol Data Units . . . . . . . . . . . . . . . . . . . . . 10 5.3 Protocol Data Unit Fields . . . . . . . . . . . . . . . . . . 10 5.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 11 6 Overview of the Protocol 11 6.1 Information Provided by the Protocol . . . . . . . . . . . . . 11 6.2 Subsets of the Protocol. . . . . . . . . . . . . . . . . . . . 12 6.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4 Underlying Service Assumed by the Protocol . . . . . . . . . 12 6.4.1 Subnetwork Addresses . . . . . . . . . . . . . . . . . 12 6.4.2 Subnetwork User Data . . . . . . . . . . . . . . . . . 13 6.5 Service Assumed from Local Environment . . . . . . . . . . . . 13 6.6 Subnetwork Types . . . . . . . . . . . . . . . . . . . . . . . 14 6.6.1 Point-to-Point Subnetworks . . . . . . . . . . . . . . 15 6.6.2 Broadcast Subnetworks . . . . . . . . . . . . . . . . 15 6.6.3 General Topology Subnetworks . . . . . . . . . . . . . 16 SECTION TWO. SPECIFICATION OF THE PROTOCOL 18 7 Protocol Functions 18 7.1 Protocol Timers . . . . . . . . . . . . . . . . . . . . . . . 18 7.1.1 Configuration Timer . . . . . . . . . . . . . . . . . 18 7.1.2 Holding Timer . . . . . . . . . . . . . . . . . . . . 18 7.2 Report Configuration Function . . . . . . . . . . . . . . . . 18 7.2.1 Report Configuration by End Systems . . . . . . . . . 19 7.2.2 Report Configuration by Intermediate Systems . . . . . 19 7.3 Record Configuration Function . . . . . . . . . . . . . . . . 20 7.4 Flush Old Configuration Function . . . . . . . . . . . . . . 20 7.5 Query Configuration Function . . . . . . . . . . . . . . . . . 20 ISO N4053 [Page 2] RFC 995 December 1986 7.6 Configuration Response Function . . . . . . . . . . . . . . . 21 7.7 Request Redirect Function. . . . . . . . . . . . . . . . . . . 22 7.8 Record Redirect Function . . . . . . . . . . . . . . . . . . . 23 7.9 Refresh Redirect Function . . . . . . . . . . . . . . . . . . 23 7.10 Flush Old Redirect Function . . . . . . . . . . . . . . . . . 24 7.11 PDU Header Error Detection . . . . . . . . . . . . . . . . . 24 7.12 Classification of Functions . . . . . . . . . . . . . . . . . 25 8 Structure and Encoding of PDUs 25 8.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2 Fixed Part . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2.1 General . . . . . . . . . . . . . . . . . . . . . . . 26 8.2.2 Network Layer Protocol Identifier . . . . . . . . . . 27 8.2.3 Length Indicator . . . . . . . . . . . . . . . . . . . 27 8.2.4 Version/Protocol Identifier Extension . . . . . . . . 27 8.2.5 Type Code . . . . . . . . . . . . . . . . . . . . . . 28 8.2.6 Holding Time . . . . . . . . . . . . . . . . . . . . . 28 8.2.7 PDU Checksum . . . . . . . . . . . . . . . . . . . . . 28 8.3 Network Address Part . . . . . . . . . . . . . . . . . . . . . 28 8.3.1 General . . . . . . . . . . . . . . . . . . . . . . . 28 8.3.2 NPAI (Network Protocol Address Information) En- coding . . . . . . . . . . . . . . . . . . . . . . . . 28 8.3.3 Source Address Parameter for ESH PDU . . . . . . . . 29 8.3.4 Network Entity Title Parameter for ISH PDU . . . . . . 29 8.3.5 Destination Address Parameter for RD PDU . . . . . . . 30 8.4 Subnetwork Address Part . . . . . . . . . . . . . . . . . . . 30 8.4.1 Subnetwork Address Parameter for RD PDU . . . . . . . 31 8.5 Options Part . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.5.1 General . . . . . . . . . . . . . . . . . . . . . . . 31 8.5.2 Security . . . . . . . . . . . . . . . . . . . . . . . 32 8.5.3 Quality of Service Maintenance . . . . . . . . . . . . 33 8.5.4 Priority . . . . . . . . . . . . . . . . . . . . . . . 33 8.6 End System Hello (ESH) PDU . . . . . . . . . . . . . . . . . . 34 8.6.1 Structure . . . . . . . . . . . . . . . . . . . . . . 34 8.7 Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 35 8.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . 35 8.8 Redirect (RD) PDU. . . . . . . . . . . . . . . . . . . . . . . 36 8.8.1 Structure . . . . . . . . . . . . . . . . . . . . . . 36 9 Formal Description 37 10 Conformance 37 ANNEX A. SUPPORTING TECHNICAL MATERIAL 38 A.1 Use of Timers . . . . . . . . . . . . . . . . . . . . . . . . 38 A.1.1 Example of Holding Time for Route Redirection . . . . 38 A.1.2 Example of Holding Timer for Configuration Informa- tion . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.2 Refresh and timeout of Redirection information . . . . . . . . 39 A.3 System Initialization Considerations . . . . . . . . . . . . . 40 A.4 Optimizations for Flushing Redirects . . . . . . . . . . . . 41 ISO N4053 [Page 3] RFC 995 December 1986 List of Tables 1 Service Primitives for Underlying Service . . . . . . . . . . 12 2 Timer Primitives . . . . . . . . . . . . . . . . . . . . . . . 14 3 Categories of Protocol Functions . . . . . . . . . . . . . . . 25 4 Valid PDU Types . . . . . . . . . . . . . . . . . . . . . . . 28 List of Figures 1 PDU Header -- Fixed Part . . . . . . . . . . . . . . . . . . . 27 2 Address Parameters . . . . . . . . . . . . . . . . . . . . . 29 3 ESH PDU - Network Address Part . . . . . . . . . . . . . . . 29 4 ISH PDU - Network Address Part . . . . . . . . . . . . . . . . 30 5 RD PDU - Network Address Part . . . . . . . . . . . . . . . . 30 6 ESH PDU - Address Part . . . . . . . . . . . . . . . . . . . 31 7 All PDUs - Options Part . . . . . . . . . . . . . . . . . . . 31 8 Encoding of Option Parameters . . . . . . . . . . . . . . . . 32 9 ESH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 34 10 ISH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 35 11 RD PDU Format when Redirect is to an IS . . . . . . . . . . . 36 12 RD PDU Format when Redirect is to an ES . . . . . . . . . . . 37 ISO N4053 [Page 4] RFC 995 December 1986 1 Introduction This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such intercon- nection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open System Inter- connection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This protocol permits End Systems and Intermediate Systems to exchange configuration and routing informa- tion to facilitate the operation of the routing and relaying func- tions of the Network Layer. The aspects of Network Layer routing that are concerned with communi- cation between end systems and intermediate systems on the same sub- network are to a great extent separable from the aspects that are concerned with communication among the intermediate systems that con- nect multiple subnetworks. This protocol addresses only the former aspects. It will be significantly enhanced by the cooperative opera- tion of an additional protocol that provides for the exchange of routing information among intermediate systems, but is useful whether or not such an additional protocol is available. This protocol provides solutions for the following practical problems: 1. How do end systems discover the existence and reachability of intermediate systems that can route NPDUs to destinations on subnetworks other than the one(s) to which the end system is directly connected? 2. How do end systems discover the existence and reachability of other end systems on the same subnetwork (when direct examination of the destination NSAP address does not provide information about the destination subnetwork)? 3. How do intermediate systems discover the existence and reachability of end systems on each of the subnetworks to which they are directly connected? 4. How do end systems decide which intermediate system to use to forward NPDUs to a particular destination when more than one intermediate system is accessible? The protocol assumes that: 1. Routing to a specified subnetwork point of attachment address (SNPA) on the same subnetwork is carried out satisfactorily by the subnetwork itself. ISO N4053 [Page 5] RFC 995 December 1986 2. The subnetwork is not, however, capable of routing on a global basis using the NSAP address alone to achieve communication with a requested destination. Note: Consequently, it is not possible to use Application Layer communication to carry out the functions of this protocol. The protocol is connectionless, and is designed to: 1. minimize the amount of a priori state information needed by end systems before they can begin to communicate with other end systems; 2. minimize the amount of memory needed to store routing information in end systems; and 3. minimize the computational complexity of end system routing algorithms. The protocol is also designed to operate in close conjunction with the Protocol for the Provision of the Connectionless-mode Network Service (ISO 8473). Since routing styles are usually closely related to communication styles, the information that this protocol provides to end systems and intermediate systems may or may not be appropriate information for supporting routing functions when a Network Layer protocol other than ISO 8473 is used. 2 Scope and Field of Application This International Standard specifies a protocol which is used by Network Layer entities operating ISO 8473 in End Systems and Inter- mediate Systems (referred to herein as ES and IS respectively) to maintain routing information. The Protocol herein described relies upon the provision of a connectionless-mode underlying service. This Standard specifies: a) procedures for the transmission of configuration and routing information between network entities residing in End Systems and network entities residing in Intermediate Systems; b) the encoding of the protocol data units used for the transmission of the configuration and routing information; c) procedures for the correct interpretation of protocol control information; and d) the functional requirements for implementations claiming conformance to this Standard. ISO N4053 [Page 6] RFC 995 December 1986 The procedures are defined in terms of: a) the interactions between End System and Intermediate System network entities through the exchange of protocol data units; and b) the interactions between a network entity and an underlying service provider through the exchange of subnetwork service primitives. This protocol does not specify any protocol elements or algorithms for facilitating routing and relaying among Intermediate Systems. Such functions are intentionally beyond the scope of this protocol. 3 References ISO 7498 Information Processing Systems --- Open Systems Intercon- nection - Basic Reference Model DIS 7498/DAD1 Information Processing Systems --- Open Systems Intercon- nection - Addendum to ISO 7498 Covering Connectionless- mode Transmission ISO 8348 Information Processing Systems --- Telecommunications and Information Exchange between Systems - Network Service Definition ISO 8348/AD1 Information Processing Systems --- Telecommunications and Information Exchange between Systems - Addendum to the Network Service Definition Covering Connectionless-mode Transmission ISO 8348/AD2 Information Processing Systems --- Telecommunications and Information Exchange between Systems - Addendum to the Network Service Definition Covering Network Layer Address- ing ISO 8473 Information Processing Systems --- Telecommunications and Information Exchange between Systems - Protocol for Pro- viding the Connectionless Network Service DIS 8648 Information Processing Systems --- Telecommunications and Information Exchange between Systems - Internal Organiza- tion of the Network Layer ISO N4053 [Page 7] RFC 995 December 1986 SC21/N965 OSI Management Framework --- Seventh Working Draft DIS 8802 Local Area Networks ISO N4053 [Page 8] RFC 995 December 1986 SECTION ONE. GENERAL 4 Definitions 4.1 Reference Model Definitions This document makes use of the following concepts defined in ISO 7498: (a) Network layer (b) Network service access point (c) Network service access point address (d) Network entity (e) Routing (f) Network protocol (g) Network relay (h) Network protocol data unit 4.2 Network Layer Architecture Definitions This document makes use of the following concepts from DIS 8648, Internal Organization of the Network Layer: (a) Subnetwork (b) End System (c) Intermediate System (d) Subnetwork Service (e) Subnetwork Access Protocol (f) Subnetwork Independent Convergence Protocol 4.3 Network Layer Addressing Definitions This document makes use of the following concepts from DIS 8348/DAD2, Addendum to the Network Service Definition Covering Network Layer Ad- dressing: (a) Subnetwork address (b) Subnetwork point of attachment ISO N4053 [Page 9] RFC 995 December 1986 4.4 Local Area Network Definitions This document makes use of the following concepts from DIS 8802, Local Area Networks: (a) multicast address (b) broadcast medium 4.5 Additional Definitions For the purposes of this document, the following definitions apply: Configuration: The collection of End and Intermediate Systems attached to a single subnetwork, defined in terms of the system types, NSAP addresses present, Network Entities present, and the correspondence between systems and SNPA addresses. Network Entity Title: An identifier for a network entity which has the same abstract syntax as an NSAP address, and which can be used to unambiguously identify a network entity in an End or Intermediate System. 5 Symbols and Abbreviations 5.1 Data Units PDU Protocol Data Unit SNSDU Subnetwork Service Data Unit 5.2 Protocol Data Units ESH PDU End System Hello Protocol Data Unit ISH PDU Intermediate System Hello Protocol Data Unit RD PDU Redirect Protocol Data Unit 5.3 Protocol Data Unit Fields NPID Network Layer Protocol Identifier LI Length Indicator V/P Version/Protocol Identifier Extension TP Type CS Checksum NETL Network entity Title Length NET Network entity Title DAL Destination Address Length DA Destination Address SAL Source Address Length SA Source Address BSNPAL SN Address Length of better route to destination BSNPA SN Address of better route to destination ISO N4053 [Page 10] RFC 995 December 1986 HT Holding timer 5.4 Parameters CT Configuration Timer RT Redirect Timer 5.5 Miscellaneous ES End System IS Intermediate System SN Subnetwork SNACP Subnetwork Access Protocol SNICP Subnetwork Independent Convergence Protocol 6 Overview of the Protocol 6.1 Information Provided by the Protocol This Protocol provides two types of information to Network entities which support its operation: a) Configuration Information, and b) Route Redirection Information Configuration Information permits End Systems to discover the ex- istence and reachability of Intermediate Systems and permits Inter- mediate Systems to discover the existence and reachability of End Systems. This information allows ESs and ISs attached to the same subnetwork to dynamically discover each other's existence and availa- bility, thus eliminating the need for manual intervention at ESs and ISs to establish the identity of Network entities that can be used to route NPDUs. Configuration Information also permits End Systems to obtain informa- tion about each other in the absence of an available Intermediate System. Note: The term "configuration information" is not intended in the broad sense of configuration as used in the context of OSI system management. Rather, only the functions specifically defined herein are intended. Route Redirection Information allows Intermediate Systems to inform End Systems of (potentially) better paths to use when forwarding NPDUs to a particular destination. A better path could either be another IS on the same subnetwork as the ES, or the destination ES itself, if it on the same subnetwork as the source ES. Allowing the ISs to inform the ESs of routes minimizes the complexity of routing decisions in End Systems and improves performance because the ESs may ISO N4053 [Page 11] RFC 995 December 1986 make use of the better IS or local subnetwork access for subsequent transmissions. 6.2 Subsets of the Protocol A Network Entity may choose to support either the Configuration In- formation, the Route Redirection Information, neither, or both. If the Configuration Information is supported, it is not required that it be employed over all subnetworks to which the Network entity is attached. 6.3 Addressing The Source Address and Destination Address parameters referred to in this International Standard are OSI Network Service Access Point Ad- dresses. The syntax and semantics of an OSI Network Service Access Point Address are described in a separate document, ISO 8348/DAD2, Addendum to the Network Service Definition covering Network Layer Ad- dressing. 6.4 Underlying Service Assumed by the Protocol The underlying service required to support this protocol is defined by the primitives in Table 1. _________________________________________________________________ | SN_UNITDATA .Request | SN_Destination_Address, | | .Indication | SN_Source_Address, | | | SN_Quality_of_Service, | | | SN_Userdata | |_____________________________________|_________________________| Table 1: Service Primitives for Underlying Service Note: These service primitives are used to describe the abstract interface which exists between the protocol machine and an underlying real subnetwork or a Subnetwork Dependent Convergence Function which operates over a real subnetwork or real data link to provide the required underlying service. 6.4.1 Subnetwork Addresses The source and destination addresses specify the points of attachment to a public or private subnetwork(s) involved in the transmission (known as Subnetwork Points of Attachment, or SNPAs).Subnetwork ad- dresses are defined in the Service Definition of each individual sub- network. This protocol is designed to take advantage of subnetworks which support broadcast, multicast, or other forms of multi- ISO N4053 [Page 12] RFC 995 December 1986 destination addressing for n-way transmission. It is assumed that the SN_Destination_Address parameter may take on one of the following multi-destination addresses in addition to a normal single destina- tion address: All End System Network entities All Intermediate System Network entities Where a real subnetwork does not inherently support broadcast or oth- er forms of transmission to multi-destination addresses, a conver- gence function may be used to provide n-way transmission to these multi-destination addresses. When the SN_Destination_Address on the SN_UNITDATA.Request is a multi-destination address, the SN_Destination_Address parameter in the corresponding SN_UNITDATA.Indication shall be the same multi- destination address. The syntax and semantics of subnetwork addresses, except for the pro- perties described above, are not defined in this Protocol Standard. 6.4.2 Subnetwork User Data The SN_Userdata is an ordered multiple of octets, and is transferred transparently between the specified subnetwork points of attachment. The underlying service is required to support a service data unit size of at least that required to operate the Protocol for Providing the Connectionless Network Service (ISO 8473). 6.5 Service Assumed from Local Environment A timer service must be provided to allow the protocol entity to schedule events. There are three primitives associated with the S-TIMER service: 1. the S--TIMER Request, 2. the S--TIMER Response, and 3. the S--TIMER Cancel. The S--TIMER Request primitive indicates to the local environment that it should initiate a timer of the specified name and subscript and maintain it for the duration specified by the time parameter. The S--TIMER Response primitive is initiated by the local environment to indicate that the delay requested by the corresponding S-TIMER Re- quest primitive has elapsed. The S--TIMER Cancel primitive is an indication to the local environ- ISO N4053 [Page 13] RFC 995 December 1986 ment that the specified timer(s) should be canceled.If the subscript parameter is not specified, then all timers with the specified name are canceled; otherwise, the timer of the given name and subscript is cancelled. If no timers correspond to the parameters specified, the local environment takes no action. The parameters of the S--TIMER service primitives are specified in Table 2. ___________________________________________ | | | | S--TIMER .Request | S-Time, | | | S-Name, | | | S-Subscript | | | | | .Response | S-Name, | | | S-Subscript | |__________________________|_______________| Table 2: Timer Primitives The time parameter indicates the time duration of the specified ti- mer. An identifiying label is associated with a timer by means of the name parameter.The subscript parameter specifies a value to dis- tinguish timers with the same name. The name and subscript taken to- gether constitute a unique reference to the timer. Timers used in association with a specific protocol funtion are de- fined under that protocol function. Note: This International Standard does not define specific values for the timers.Any derivations described in this Standard are not mandatory. Timer values should be chosen so that the requested Quality of Service can be provided, given the known characteristics of the underlying service. 6.6 Subnetwork Types In order to evaluate the applicability of this protocol in particular configurations of End Systems, Intermediate Systems and subnetworks, three generic types of subnetwork are identified. These are: 1. the point-to-point subnetwork, 2. the broadcast subnetwork, and 3. the general topology subnetwork These subnetwork types are discussed in the following clauses. ISO N4053 [Page 14] RFC 995 December 1986 6.6.1 Point-to-Point Subnetworks A point-to-point subnetwork supports exactly two systems. The two systems may be either two End Systems, or an End System and a single Intermediate System. A single point-to-point data link connecting two Network Entities is an example of a point-to-point subnetwork. Configuration Information on a point-to-point Subnetwork.On a point- to-point subnetwork the Configuration Information of this protocol informs the communicating Network entities of the following: 1. Whether the topology consists only of two End Systems, or 2. One of the two systems is a Intermediate System. Note: On a point-to-point subnetwork, if both systems are Intermediate Systems, then this protocol is inapplicable to the situation, since a IS-to-IS protocol should be employed instead. However, there is no reason why the configuration information could not be employed in a IS-to-IS environment to ascertain the topology and initiate operation of a IS-to-IS protocol. The Intermediate System is informed of the NSAP address(es) supported by the Network entity in the End System. This permits reachability information and routing metrics concerning these NSAPs to be dissem- inated to other Intermediate Systems for the purpose of calculating routes to/from this End System. Route Redirection Information on a point-to-point Subnetwork. Route Redirection Information is not employed on point-to-point subnetworks because there are never any alternate routes. 6.6.2 Broadcast Subnetworks A Broadcast subnetwork supports an arbitrary number of End Systems and Intermediate Systems, and additionally is capable of transmitting a single SNPDU to all or a subset of these systems in response to a single SN_UNITDATA.Request.An example of a broadcast subnetwork is a LAN (local area network) conforming to DIS8802/2, type 1 operation. Configuration Information on a broadcast Subnetwork.On a broadcast subnetwork the Configuration Information of this protocol is employed to inform the communicating Network entities of the following: 1. End Systems are informed of the reachability, Network entity Title, and SNPA address(es) of each active Intermediate System on the subnetwork. ISO N4053 [Page 15] RFC 995 December 1986 2. Intermediate Systems are informed of the NSAP addresses supported by each End System and the Subnetwork address of the ES. Once the Intermediate System obtains this information, reachability information and routing metrics concerning these NSAPs may be disseminated to other ISs for the purpose of calculating routes to/from each ES on the subnetwork. 3. In the absence of an available Intermediate System, End Systems may query over a broadcast subnetwork to discover whether a particular NSAP is reachable on the subnetwork, and if so, what SNPA address to use to reach that NSAP. Route Redirection Information on broadcast Subnetworks.Route Redirec- tion Information may be employed on broadcast subnetworks to permit Intermediate Systems to inform End Systems of superior routes to a destination NSAP. The superior route might be another IS on the same subnetwork as the ES, or it might be the destination ES itself, if it is directly reachable on the same subnetwork as the source ES. 6.6.3 General Topology Subnetworks A general topology subnetwork supports an arbitrary number of End Systems and Intermediate Systems, but does not support a convenient multidestination connectionless transmission facility as does a broadcast subnetwork.An example of a general topology subnetwork is a subnetwork employing X.25 or ISO 8208. Note: The crucial distinguishing characteristic between the broadcast subnetwork and the general topology subnetwork is the "cost" of an n-way transmission to a potentially large subset of the systems on the subnetwork. On a general topology subnetwork, the cost is assumed to be close to the cost of sending an individual PDU to each SNPA on the subnetwork. Conversely, on a broadcast subnetwork the cost is assumed to be close to the cost of sending a single PDU to one SNPA on the subnetwork. Intermediate situations between these extremes are of course possible. In such cases it would be possible to treat the subnetwork as either in the broadcast or general topology categories. Configuration Information on a general topology Subnetwork. On a general topology subnetwork the Configuration Information is general- ly not employed because this protocol can be very costly in the util- ization (and charging for) subnetwork resources. Route Redirection Information on a general topology Subnetwork. Route Redirection Information may be employed on general topology subnetworks to permit Intermediate Systems to inform End Systems of superior routes to a destination NSAP. The superior route might be another IS on the same subnetwork as the ES, or it might be the des- tination ES itself, if it is directly reachable on the same subnet- ISO N4053 [Page 16] RFC 995 December 1986 work as the source ES. ISO N4053 [Page 17] RFC 995 December 1986 SECTION TWO. SPECIFICATION OF THE PROTOCOL 7 Protocol Functions This section describes the functions performed as part of the Proto- col. Not all of the functions must be performed by every implementa- tion. Clause 7.12 specifies which functions may be omitted and the correct behavior where requested functions are not implemented. 7.1 Protocol Timers Many of the protocol functions are timer based. This means that they are executed upon expiration of a timer rather than upon receipt of a PDU or invocation of a service primitive. The two major types of ti- mers employed by the protocol are the Configuration Timer (CT) and the Holding Timer (HT). 7.1.1 Configuration Timer The Configuration Timer is a local timer (i.e. maintained indepen- dently by each system) which performs the Report Configuration func- tion (see section 7.2). The timer determines how often a system re- ports its availability to the other systems on the same subnetwork. The shorter the Configuration Timer, the more quickly other systems on the subnetwork will become aware when the reporting system becomes available or unavailable. The increased responsiveness must be traded off against increased use of resources in the subnetwork and in the recipient systems. 7.1.2 Holding Timer The Holding Timer applies to both Configuration Information and Route Redirection Information. The value of the Holding Timer is set by the source of the information and transmitted in the appropriate PDU. The recipient of the information is expected to retain the information no longer than the Holding Timer. Old Configuration or Route Redirection information must be discarded after the Holding Timer expires to en- sure the correct operation of the protocol. Further discussion of the rationale for these timers and guidelines for their use may be found in annex 10. 7.2 Report Configuration Function The Report Configuration Function is used by End Systems and Inter- mediate Systems to inform each other of their reachability and current subnetwork address. This function is invoked every time the local Configuration Timer (CT) expires in an ES or IS. It is also in- voked upon receipt of a Query Configuration PDU from another End Sys- tem. ISO N4053 [Page 18] RFC 995 December 1986 7.2.1 Report Configuration by End Systems An End System constructs and transmits one ESH PDU (ESH stands for "End System Hello") for each NSAP it serves, and issues one SN_UNITDATA.- Request with the ESH PDU as the SNSDU on each subnet- work to which it is attached. Note: The necessity to transmit a separate ESH PDU for each NSAP served by the Network entity arises from the lack of a formalized relationship between Network Entity Titles and NSAP addresses. If this relationship could be constrained to require that all NSAP addresses be assigned as leaf subdomains of a domain represented by the local Network entity's Network entity Title, then a single ESH PDU could be transmitted containing the ESs Network entity Title.The Network entity Title would then imply which NSAPs might be present at that End system. The Holding Timer (HT) field is set to approximately twice the ESs Configuration Timer (CT) parameter. This variable is set to a value large enough so that even if every other ESH PDU is discarded (due to lack of resources), or otherwise lost in the subnetwork, the confi- guration information will still be maintained. The value must be set small enough so that Intermediate Systems can respond in a timely fashion to End Systems becoming available or unavailable. The SN_Destination_Address parameter is set to the group address that indicates "All Intermediate System Network Entities". This ensures that a single transmission on a broadcast subnetwork will reach all of the active Intermediate Systems. Note: The actual value of the SN_Destination_Address used to mean "All Intermediate System Network Entities" is subnetwork dependent and will most likely vary from subnetwork to subnetwork. It would of course be desirable that on widely-used subnetwork types (such as those based on DIS 8802) that this value and the value of the "All End System Network Entities" group address, be standardized. 7.2.2 Report Configuration by Intermediate Systems An Intermediate System constructs a single ISH PDU (ISH stands for "Intermediate System Hello") containing the ISs Network Entity Title and issues one SN_UNITDATA.Request with the ISH PDU as the SNSDU on each subnetwork to which it is attached. The Holding Timer (HT) field is set to approximately twice the Inter- mediate System's Configuration Timer (CT) parameter. This variable is set to a value large enough so that even if every other ISH PDU is discarded (due to lack of resources), or otherwise lost in the sub- network, the configuration information will still be maintained.The value must be set small enough so that End Systems will quickly cease ISO N4053 [Page 19] RFC 995 December 1986 to use ISs that have failed, thus preventing "black holes" in the Network. The SN_Destination_Address parameter is set to the group address that indicates "All End System Network Entities".This ensures that a sin- gle transmission on a broadcast subnetwork will reach all of the ac- tive End Systems. 7.3 Record Configuration Function The Record Configuration function receives ESH or ISH PDUs, extracts the configuration information, and adds or replaces the corresponding configuration information in the local Network entity's Routing In- formation base. If insufficient space is available to store new con- figuration information, the PDU is discarded. No Error Report is gen- erated. Note: The protocol is described such that End Systems receive and record only ISH PDUs and Intermediate Systems receive and process only ESH PDUs. If an ES so desires however, it may decide to process ESH PDUs as well (on a broadcast network this is easily done by enabling the appropriate group address). There is potentially some performance improvement to be gained by doing this, at the expense of extra memory, and possibly extra processing cycles in the End System.The ES, by recording other ESs' Configuration information, may be able to route NPDUs directly to ESs on the local subnetwork without first being redirected by a Intermediate System. Similarly, Intermediate Systems may choose to receive the ISH PDUs of other ISs, allowing this protocol to be used as the initialization and topology maintenance portion of a full IS-to-IS routing protocol. Both of these possibilities are for further study. 7.4 Flush Old Configuration Function The Flush Old Configuration Function is executed to remove Configura- tion entries in the routing information base whose Holding Timer has expired. When the Holding Time for an ES or IS expires, this func- tion removes the corresponding entry from the routing information base of the local Network Entity. 7.5 Query Configuration Function The Query Configuration Function is performed under the following circumstances: 1. The End System is attached to a broadcast subnetwork, 2. There is no Intermediate System currently reachable on the subnetwork (i.e. no ISH PDUs have been received since the last ISO N4053 [Page 20] RFC 995 December 1986 information was flushed by the Flush Old Configuration Function), 3. The Network Layer's Route PDU Function needs to obtain the SNPA address to which to forward a PDU destined for a certain NSAP, and 4. The SNPA address cannot be obtained either by a local transformation or a local table lookup. Note: Despite appearances, this is actually a quite common case, since it is likely that there will be numerous isolated Local Area Networks without Intermediate Systems to rely upon for obtaining routing information (e.g.via the Request Redirect Function of this protocol). Further, if the Intermediate System(s) are temporarily unavailable, without this capability communication on the local subnetwork would suffer unless manually-entered tables were present in each End System or all NSAPs of the subnetwork had the subnetwork SNPA address embedded in them. The End System, when needing to route an NPDU to a destination NSAP whose SNPA is unknown issues an SN_UNITDATA.Request with the NPDU as the SN_Userdata.The SN_Destination_Address parameter is set to the group address that indicates "All End System Network Entities". Subsequently an ESH PDU may be received containing the NSAP address along with the corresponding SNPA address (see clause 7.6). In such a case the End System executes the Record Configuration function for the NSAP, and therefore will be able to route subsequent PDUs to that destination using the specified SNPA. If no ESH PDU is received, the End System may declare the destination NSAP is not reachable. The length of time to wait for a response before indicating a failure or the possibility of repeating the process some number of times before returning a failure are local matters and are not specified in this standard. 7.6 Configuration Response Function The Configuration Response function is performed when an End System attached to a broadcast subnetwork receives an NPDU addressed to one of its NSAPs, with the SN_Destination_Address from the SN_UNITDATA.Indication set to the group address "All End System Netowrk Entities". This occurs as a result of another ES having per- formed the Query Configuration function described in clause 7.5. The End System constructs an ESH PDU identical in content to the ESH PDU constructed by the Report Configuration function (see clause 7.2.1) for the NSAP to which the received NPDU was addressed.It then transmits the ESH PDU to the source of the original NPDU by issuing an SN_UNITDATA.Request with the SN_Destination_Address set to the value of the SN_Source_Address received in the SN_UNITDATA.Indication with the original NPDU. ISO N4053 [Page 21] RFC 995 December 1986 7.7 Request Redirect Function The Request Redirect Function is present only in Intermediate Systems and is closely coupled with the Routing and Relaying Functions of In- termediate Systems. The Request Redirect Function is coupled with the "Route PDU Function" described in clause 6.5 of ISO 8473. The Request Redirect Function is performed after the Route PDU function has cal- culated the next hop of the Data PDU's path. When an NPDU is to be forwarded by a Intermediate System, the Request Redirect Function first examines the SN_Source_Address associated with the SN_UNITDATA.Indication which received the SNSDU (containing this NPDU). If the SN_Source_Address is not from an End System on the local subnetwork (determined by examining the Configuration informa- tion obtained through the Record Configuration Function), then this function does no further processing of the NPDU. If the NPDU was received directly from an ES the output of the ISs Routing and Relaying function for this NPDU is examined. This output will contain, among other things, the following pieces of informa- tion: 1. a local identifier for the subnetwork over which to forward the NPDU, plus either 2. the Network entity title and subnetwork address of the IS to which to forward the NPDU, or 3. the subnetwork address of the destination End System. The Request Redirect function must now determine if the source ES could have sent the NPDU directly to the Network entity the Inter- mediate System is about to forward the PDU to. If any of the follow- ing conditions hold, the source ESshould be informed of the "better" path (by sending an RD PDU to the originating ES): 1. The next hop is to the destination system, and the destination is directly reachable (at subnetwork address BSNPA) on the source ESs subnetwork, or 2. The next hop is to a Intermediate System which is connected to the same subnetwork as the ES. If the better path exists, the IS first complete