As per Relevance of the word subnetwork, we have this rfc below:
Network Working Group ANSI X3S3.3 86-118
Request for Comments: 995 ISO TC97/SC6/N 4053
April 1986
I S
INTERNATIONAL ORGANIZATION FOR
ORGANISATION INTERNATIONALE DE
______________________________________________________________________
| |
| ISO/TC 97/SC 6 |
| TELECOMMUNICATIONS AND INFORMATION |
| EXCHANGE BETWEEN SYSTEMS |
| Secretariat: USA (ANSI) |
| |
| |
|_____________________________________________________________________|
Title: End System to Intermediate System Routing Exchange
for use in conjunction with ISO 8473
Source: SC6/WG
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
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
1 Service Primitives for Underlying Service . . . . . . . . . . 12
2 Timer Primitives . . . . . . . . . . . . . . . . . . . . . . . 14
3 Categories of Protocol Functions . . . . . . . . . . . . . . . 25
4 Valid PDU Types . . . . . . . . . . . . . . . . . . . . . . . 28
List of
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
This Protocol is one of a set of International Standards produced
facilitate the interconnection of open systems. The set of
covers the services and protocols required to achieve such intercon
nection
This Protocol is positioned with respect to other related
by the layers defined in the Reference Model for Open System Inter
connection (ISO 7498) and by the structure defined in the
Organization of the Network Layer (DIS 8648). In particular, it is
protocol of the Network Layer. This protocol permits End Systems
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
concerned with communication among the intermediate systems that con
nect multiple subnetworks. This protocol addresses only the
aspects. It will be significantly enhanced by the cooperative opera
tion of an additional protocol that provides for the exchange
routing information among intermediate systems, but is useful
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
intermediate systems that can route NPDUs to destinations
subnetworks other than the one(s) to which the end system
directly connected
2. How do end systems discover the existence and reachability
other end systems on the same subnetwork (when
examination of the destination NSAP address does not
information about the destination subnetwork)?
3. How do intermediate systems discover the existence
reachability of end systems on each of the subnetworks
which they are directly connected
4. How do end systems decide which intermediate system to
to forward NPDUs to a particular destination when more than
intermediate system is accessible
The protocol assumes that
1. Routing to a specified subnetwork point of attachment
(SNPA) on the same subnetwork is carried out satisfactorily
the subnetwork itself
ISO N4053 [Page 5]
RFC 995 December 1986
2. The subnetwork is not, however, capable of routing on a
basis using the NSAP address alone to achieve
with a requested destination
Note
Consequently, it is not possible to use Application
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
end systems before they can begin to communicate with
end systems
2. minimize the amount of memory needed to store
information in end systems;
3. minimize the computational complexity of end system
algorithms
The protocol is also designed to operate in close conjunction
the Protocol for the Provision of the Connectionless-mode
Service (ISO 8473). Since routing styles are usually closely
to communication styles, the information that this protocol
to end systems and intermediate systems may or may not be
information for supporting routing functions when a Network
protocol other than ISO 8473 is used
2 Scope and Field of
This International Standard specifies a protocol which is used
Network Layer entities operating ISO 8473 in End Systems and Inter
mediate Systems (referred to herein as ES and IS respectively)
maintain routing information. The Protocol herein described
upon the provision of a connectionless-mode underlying service
This Standard specifies
a) procedures for the transmission of configuration and
information between network entities residing in End
and network entities residing in Intermediate Systems
b) the encoding of the protocol data units used for the
of the configuration and routing information
c) procedures for the correct interpretation of protocol
information;
d) the functional requirements for implementations
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
network entities through the exchange of protocol data units
b) the interactions between a network entity and an
service provider through the exchange of subnetwork
primitives
This protocol does not specify any protocol elements or algorithms
facilitating routing and relaying among Intermediate Systems.
functions are intentionally beyond the scope of this protocol
3
ISO 7498 Information Processing Systems --- Open Systems Intercon
nection - Basic Reference
DIS 7498/DAD1 Information Processing Systems --- Open Systems Intercon
nection - Addendum to ISO 7498 Covering Connectionless
mode
ISO 8348 Information Processing Systems --- Telecommunications
Information Exchange between Systems - Network
ISO 8348/AD1 Information Processing Systems --- Telecommunications
Information Exchange between Systems - Addendum to
Network Service Definition Covering Connectionless-
ISO 8348/AD2 Information Processing Systems --- Telecommunications
Information Exchange between Systems - Addendum to
Network Service Definition Covering Network Layer Address
ISO 8473 Information Processing Systems --- Telecommunications
Information Exchange between Systems - Protocol for Pro
viding the Connectionless Network
DIS 8648 Information Processing Systems --- Telecommunications
Information Exchange between Systems - Internal Organiza
tion of the Network
ISO N4053 [Page 7]
RFC 995 December 1986
SC21/N965 OSI Management Framework --- Seventh Working
DIS 8802 Local Area
ISO N4053 [Page 8]
RFC 995 December 1986
SECTION ONE.
4
4.1 Reference Model
This document makes use of the following concepts defined in ISO 7498:
(a) Network
(b) Network service access
(c) Network service access point
(d) Network
(e)
(f) Network
(g) Network
(h) Network protocol data
4.2 Network Layer Architecture
This document makes use of the following concepts from DIS 8648,
Organization of the Network Layer
(a)
(b) End
(c) Intermediate
(d) Subnetwork
(e) Subnetwork Access
(f) Subnetwork Independent Convergence
4.3 Network Layer Addressing
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
(b) Subnetwork point of
ISO N4053 [Page 9]
RFC 995 December 1986
4.4 Local Area Network
This document makes use of the following concepts from DIS 8802,
Area Networks
(a) multicast
(b) broadcast
4.5 Additional
For the purposes of this document, the following definitions apply
Configuration: The collection of End and Intermediate
attached to a single subnetwork, defined in terms of
system types, NSAP addresses present, Network
present, and the correspondence between systems and
addresses
Network Entity Title: An identifier for a network entity
has the same abstract syntax as an NSAP address, and
can be used to unambiguously identify a network entity
an End or Intermediate System
5 Symbols and
5.1 Data
PDU Protocol Data
SNSDU Subnetwork Service Data
5.2 Protocol Data
ESH PDU End System Hello Protocol Data
ISH PDU Intermediate System Hello Protocol Data
RD PDU Redirect Protocol Data
5.3 Protocol Data Unit
NPID Network Layer Protocol
LI Length
V/P Version/Protocol Identifier
TP
CS
NETL Network entity Title
NET Network entity
DAL Destination Address
DA Destination
SAL Source Address
SA Source
BSNPAL SN Address Length of better route to
BSNPA SN Address of better route to
ISO N4053 [Page 10]
RFC 995 December 1986
HT Holding
5.4
CT Configuration
RT Redirect
5.5
ES End
IS Intermediate
SN
SNACP Subnetwork Access
SNICP Subnetwork Independent Convergence
6 Overview of the
6.1 Information Provided by the
This Protocol provides two types of information to Network
which support its operation
a) Configuration Information,
b) Route Redirection
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
Systems. This information allows ESs and ISs attached to the
subnetwork to dynamically discover each other's existence and availa
bility, thus eliminating the need for manual intervention at ESs
ISs to establish the identity of Network entities that can be used
route NPDUs
Configuration Information also permits End Systems to obtain informa
tion about each other in the absence of an available
System
Note
The term "configuration information" is not intended in the
sense of configuration as used in the context of OSI
management. Rather, only the functions specifically defined
are intended
Route Redirection Information allows Intermediate Systems to
End Systems of (potentially) better paths to use when
NPDUs to a particular destination. A better path could either
another IS on the same subnetwork as the ES, or the destination
itself, if it on the same subnetwork as the source ES. Allowing
ISs to inform the ESs of routes minimizes the complexity of
decisions in End Systems and improves performance because the ESs
ISO N4053 [Page 11]
RFC 995 December 1986
make use of the better IS or local subnetwork access for
transmissions
6.2 Subsets of the
A Network Entity may choose to support either the Configuration In
formation, the Route Redirection Information, neither, or both.
the Configuration Information is supported, it is not required
it be employed over all subnetworks to which the Network entity
attached
6.3
The Source Address and Destination Address parameters referred to
this International Standard are OSI Network Service Access Point Ad
dresses. The syntax and semantics of an OSI Network Service
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
The underlying service required to support this protocol is
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
Note
These service primitives are used to describe the abstract
which exists between the protocol machine and an underlying
subnetwork or a Subnetwork Dependent Convergence Function
operates over a real subnetwork or real data link to provide
required underlying service
6.4.1 Subnetwork
The source and destination addresses specify the points of
to a public or private subnetwork(s) involved in the
(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
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
SN_Destination_Address parameter may take on one of the
multi-destination addresses in addition to a normal single destina
tion address
All End System Network
All Intermediate System Network
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
multi-destination addresses
When the SN_Destination_Address on the SN_UNITDATA.Request is
multi-destination address, the SN_Destination_Address parameter
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
The SN_Userdata is an ordered multiple of octets, and is
transparently between the specified subnetwork points of attachment
The underlying service is required to support a service data
size of at least that required to operate the Protocol for
the Connectionless Network Service (ISO 8473).
6.5 Service Assumed from Local
A timer service must be provided to allow the protocol entity
schedule events
There are three primitives associated with the S-TIMER service
1. the S--TIMER Request
2. the S--TIMER Response,
3. the S--TIMER Cancel
The S--TIMER Request primitive indicates to the local
that it should initiate a timer of the specified name and
and maintain it for the duration specified by the time parameter
The S--TIMER Response primitive is initiated by the local
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
parameter is not specified, then all timers with the specified
are canceled; otherwise, the timer of the given name and subscript
cancelled. If no timers correspond to the parameters specified,
local environment takes no action
The parameters of the S--TIMER service primitives are specified
Table 2.
___________________________________________
| | |
| S--TIMER .Request | S-Time, |
| | S-Name, |
| | S-Subscript |
| | |
| .Response | S-Name, |
| | S-Subscript |
|__________________________|_______________|
Table 2: Timer
The time parameter indicates the time duration of the specified ti
mer. An identifiying label is associated with a timer by means
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
timers.Any derivations described in this Standard are not mandatory
Timer values should be chosen so that the requested Quality
Service can be provided, given the known characteristics of
underlying service
6.6 Subnetwork
In order to evaluate the applicability of this protocol in
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,
3. the general topology
These subnetwork types are discussed in the following clauses
ISO N4053 [Page 14]
RFC 995 December 1986
6.6.1 Point-to-Point
A point-to-point subnetwork supports exactly two systems. The
systems may be either two End Systems, or an End System and a
Intermediate System. A single point-to-point data link connecting
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
informs the communicating Network entities of the following
1. Whether the topology consists only of two End Systems,
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-
protocol should be employed instead. However, there is no reason
the configuration information could not be employed in a IS-to-
environment to ascertain the topology and initiate operation of
IS-to-IS protocol
The Intermediate System is informed of the NSAP address(es)
by the Network entity in the End System. This permits
information and routing metrics concerning these NSAPs to be dissem
inated to other Intermediate Systems for the purpose of
routes to/from this End System
Route Redirection Information on a point-to-point Subnetwork.
Redirection Information is not employed on point-to-point
because there are never any alternate routes
6.6.2 Broadcast
A Broadcast subnetwork supports an arbitrary number of End
and Intermediate Systems, and additionally is capable of
a single SNPDU to all or a subset of these systems in response to
single SN_UNITDATA.Request.An example of a broadcast subnetwork is
LAN (local area network) conforming to DIS8802/2, type 1 operation
Configuration Information on a broadcast Subnetwork.On a
subnetwork the Configuration Information of this protocol is
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
subnetwork
ISO N4053 [Page 15]
RFC 995 December 1986
2. Intermediate Systems are informed of the NSAP addresses
by each End System and the Subnetwork address of the ES. Once
Intermediate System obtains this information,
information and routing metrics concerning these NSAPs may
disseminated to other ISs for the purpose of calculating
to/from each ES on the subnetwork
3. In the absence of an available Intermediate System, End Systems
query over a broadcast subnetwork to discover whether a
NSAP is reachable on the subnetwork, and if so, what SNPA
to use to reach that NSAP
Route Redirection Information on broadcast Subnetworks.Route Redirec
tion Information may be employed on broadcast subnetworks to
Intermediate Systems to inform End Systems of superior routes to
destination NSAP. The superior route might be another IS on the
subnetwork as the ES, or it might be the destination ES itself, if
is directly reachable on the same subnetwork as the source ES
6.6.3 General Topology
A general topology subnetwork supports an arbitrary number of
Systems and Intermediate Systems, but does not support a
multidestination connectionless transmission facility as does
broadcast subnetwork.An example of a general topology subnetwork is
subnetwork employing X.25 or ISO 8208.
Note
The crucial distinguishing characteristic between the
subnetwork and the general topology subnetwork is the "cost" of
n-way transmission to a potentially large subset of the systems
the subnetwork. On a general topology subnetwork, the cost is
to be close to the cost of sending an individual PDU to each SNPA
the subnetwork. Conversely, on a broadcast subnetwork the cost
assumed to be close to the cost of sending a single PDU to one
on the subnetwork. Intermediate situations between these
are of course possible. In such cases it would be possible to treat
subnetwork as either in the broadcast or general topology categories
Configuration Information on a general topology Subnetwork. On
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
subnetworks to permit Intermediate Systems to inform End Systems
superior routes to a destination NSAP. The superior route might
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
7 Protocol
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
correct behavior where requested functions are not implemented
7.1 Protocol
Many of the protocol functions are timer based. This means that
are executed upon expiration of a timer rather than upon receipt of
PDU or invocation of a service primitive. The two major types of ti
mers employed by the protocol are the Configuration Timer (CT)
the Holding Timer (HT).
7.1.1 Configuration
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
on the subnetwork will become aware when the reporting system
available or unavailable. The increased responsiveness must be
off against increased use of resources in the subnetwork and in
recipient systems
7.1.2 Holding
The Holding Timer applies to both Configuration Information and
Redirection Information. The value of the Holding Timer is set by
source of the information and transmitted in the appropriate PDU.
recipient of the information is expected to retain the information
longer than the Holding Timer. Old Configuration or Route
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
for their use may be found in annex 10.
7.2 Report Configuration
The Report Configuration Function is used by End Systems and Inter
mediate Systems to inform each other of their reachability
current subnetwork address. This function is invoked every time
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
An End System constructs and transmits one ESH PDU (ESH stands
"End System Hello") for each NSAP it serves, and issues
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
the Network entity arises from the lack of a formalized
between Network Entity Titles and NSAP addresses. If this
could be constrained to require that all NSAP addresses be assigned
leaf subdomains of a domain represented by the local Network entity'
Network entity Title, then a single ESH PDU could be
containing the ESs Network entity Title.The Network entity
would then imply which NSAPs might be present at that End system
The Holding Timer (HT) field is set to approximately twice the
Configuration Timer (CT) parameter. This variable is set to a
large enough so that even if every other ESH PDU is discarded (due
lack of resources), or otherwise lost in the subnetwork, the confi
guration information will still be maintained. The value must be
small enough so that Intermediate Systems can respond in a
fashion to End Systems becoming available or unavailable
The SN_Destination_Address parameter is set to the group address
indicates "All Intermediate System Network Entities". This
that a single transmission on a broadcast subnetwork will reach
of the active Intermediate Systems
Note
The actual value of the SN_Destination_Address used to mean "
Intermediate System Network Entities" is subnetwork dependent and
most likely vary from subnetwork to subnetwork. It would of course
desirable that on widely-used subnetwork types (such as those
on DIS 8802) that this value and the value of the "All End
Network Entities" group address, be standardized
7.2.2 Report Configuration by Intermediate
An Intermediate System constructs a single ISH PDU (ISH stands
"Intermediate System Hello") containing the ISs Network Entity
and issues one SN_UNITDATA.Request with the ISH PDU as the SNSDU
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
set to a value large enough so that even if every other ISH PDU
discarded (due to lack of resources), or otherwise lost in the sub
network, the configuration information will still be maintained.
value must be set small enough so that End Systems will quickly
ISO N4053 [Page 19]
RFC 995 December 1986
to use ISs that have failed, thus preventing "black holes" in
Network
The SN_Destination_Address parameter is set to the group address
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
The Record Configuration function receives ESH or ISH PDUs,
the configuration information, and adds or replaces the
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
only ISH PDUs and Intermediate Systems receive and process
ESH PDUs. If an ES so desires however, it may decide to process
PDUs as well (on a broadcast network this is easily done by
the appropriate group address). There is potentially some
improvement to be gained by doing this, at the expense of extra memory
and possibly extra processing cycles in the End System.
ES, by recording other ESs' Configuration information, may be
to route NPDUs directly to ESs on the local subnetwork without
being redirected by a Intermediate System
Similarly, Intermediate Systems may choose to receive the ISH
of other ISs, allowing this protocol to be used as the initialization
topology maintenance portion of a full IS-to-IS routing protocol
Both of these possibilities are for further study
7.4 Flush Old Configuration
The Flush Old Configuration Function is executed to remove Configura
tion entries in the routing information base whose Holding Timer
expired. When the Holding Time for an ES or IS expires, this func
tion removes the corresponding entry from the routing
base of the local Network Entity
7.5 Query Configuration
The Query Configuration Function is performed under the
circumstances
1. The End System is attached to a broadcast subnetwork
2. There is no Intermediate System currently reachable on
subnetwork (i.e. no ISH PDUs have been received since the
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
address to which to forward a PDU destined for a certain NSAP,
4. The SNPA address cannot be obtained either by a local
or a local table lookup
Note
Despite appearances, this is actually a quite common case, since
is likely that there will be numerous isolated Local Area
without Intermediate Systems to rely upon for obtaining
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
suffer unless manually-entered tables were present in each End
or all NSAPs of the subnetwork had the subnetwork SNPA
embedded in them
The End System, when needing to route an NPDU to a destination
whose SNPA is unknown issues an SN_UNITDATA.Request with the NPDU
the SN_Userdata.The SN_Destination_Address parameter is set to
group address that indicates "All End System Network Entities".
Subsequently an ESH PDU may be received containing the NSAP
along with the corresponding SNPA address (see clause 7.6). In such
case the End System executes the Record Configuration function
the NSAP, and therefore will be able to route subsequent PDUs to
destination using the specified SNPA. If no ESH PDU is received,
End System may declare the destination NSAP is not reachable.
length of time to wait for a response before indicating a failure
the possibility of repeating the process some number of times
returning a failure are local matters and are not specified in
standard
7.6 Configuration Response
The Configuration Response function is performed when an End
attached to a broadcast subnetwork receives an NPDU addressed to
of its NSAPs, with the SN_Destination_Address from
SN_UNITDATA.Indication set to the group address "All End
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
PDU constructed by the Report Configuration function (see
7.2.1) for the NSAP to which the received NPDU was addressed.It
transmits the ESH PDU to the source of the original NPDU by
an SN_UNITDATA.Request with the SN_Destination_Address set to
value of the SN_Source_Address received in the SN_UNITDATA.
with the original NPDU
ISO N4053 [Page 21]
RFC 995 December 1986
7.7 Request Redirect
The Request Redirect Function is present only in Intermediate
and is closely coupled with the Routing and Relaying Functions of In
termediate Systems. The Request Redirect Function is coupled with
"Route PDU Function" described in clause 6.5 of ISO 8473. The
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
Redirect Function first examines the SN_Source_Address
with the SN_UNITDATA.Indication which received the SNSDU (
this NPDU). If the SN_Source_Address is not from an End System on
local subnetwork (determined by examining the Configuration informa
tion obtained through the Record Configuration Function), then
function does no further processing of the NPDU
If the NPDU was received directly from an ES the output of the
Routing and Relaying function for this NPDU is examined. This
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
2. the Network entity title and subnetwork address of the IS to which
forward the NPDU,
3. the subnetwork address of the destination End System
The Request Redirect function must now determine if the source
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
directly reachable (at subnetwork address BSNPA) on the source
subnetwork,
2. The next hop is to a Intermediate System which is connected to
same subnetwork as the ES
If the better path exists, the IS first completes normal
of the received NPDU and forwards it.It then constructs a
PDU (RD PDU) containing the Destination Address of the original NPDU
the subnetwork address of the better next hop (BSNPA), the
Entity Title of the IS to which the ES is being redirected (
the redirect is to the destination ES), a Holding Time (HT),
Maintenance, Priority, and Security options that were present in
Data NPDU (these are simply copied from the Data PDU). The HT is
ISO N4053 [Page 22]
RFC 995 December 1986
to the value of the local Redirect Timer (RT). See Annex A for a dis
cussion of how to choose the value of RT. If there are
resources to both forward the original NPDU and to generate and
an RD PDU, the original NPDU must be given preference. The Inter
mediate System (assuming it has sufficient resources) then sends
RD PDU to the source End System using the SN_Source_Address of
received NPDU as the SN_Destination_Address for the SN_UNITDATA.-
Reqeust
7.8 Record Redirect
The Record Redirect Function is present only in End Systems.
function is invoked whenever an RD PDU is received. It extracts
redirect information and adds or replaces the corresponding redirec
tion information in the local Network entity's Routing
base. The essential information is the redirection mapping from
Destination Address to a subnetwork address, along with the Priority
Security, and QoS Maintenance options and the Holding Time for
this mapping is to be considered valid. If the Redirect was to anoth
er Intermediate System, the Network Entity Title of the IS is record
ed as well
Note
If insufficient memory is available to store new redirection information
the RD PDU may be safely discarded since the original
System will continue to forward PDUs on behalf of this Network
anyway
7.9 Refresh Redirect
The Refresh Redirect Function is present only in End Systems.
function is invoked whenever an NPDU is received by a destination ES
It is closely coupled with the function that processes received
at a destination Network Entity.This is the "PDU Decomposition" func
tion in ISO 8473. The purpose of this function is to increase
longevity of a redirection without allowing an incorrect route
persist indefinitely. The Source Address (SA), Priority, Security
and QoS options are extracted and compared to any Destination
and QoS parameters being maintained in the Routing Information
(such information would have been stored by the Record Redirect Func
tion). If a corresponding entry is found, the previous hop of the
is obtained from the SN_Source_Address parameter of
SN_Unitdata.Indication primitive by which it was received. If
address matches the next hop address stored with the redirection in
formation, the remaining holding time for the redirection is reset
the original holding timer that was obtained from the RD PDU
Note
The purpose of this function is to avoid timing out redirection
when the Network entity is receiving return traffic from the
via the same path over which it is currently sending traffic.This
ISO N4053 [Page 23]
RFC 995 December 1986
particularly useful when the destination system is on the same
as the source, since after one redirect no IS need be involved
the ES-to-ES traffic
This function must operate in a very conservative fashion however
to prevent the formation of black holes. The remaining holding
should be refreshed only under the exact conditions specified above
For a discussion of the issues surrounding the refresh of
information, see Annex 10.
7.10 Flush Old Redirect
The Flush Old Redirect Function is executed to remove
entries in the routing information base whose Holding Timer has ex
pired. When the Holding Time for an ES or IS expires, this
removes the corresponding entry from the routing information base
the local Network Entity
7.11 PDU Header Error
The PDU Header Error Detection function protects against failure
Intermediate or End System Network entities due to the processing
erroneous information in the PDU header.The function is realized by
checksum computed on the entire PDU header. The checksum is
at each point at which the PDU is processed. If the checksum calcula
tion fails, the PDU must be discarded
The use of the Header Error Detection function is optional and
selected by the originating Network Entity. If the function is
used, the checksum field of the PDU header is set to zero
If the function is selected by the originating Network Entity,
value of the checksum field causes the following formulf to be satis
fied
(The Sum from i=1 to L of a(i)) (mod 255) = 0
(The Sum from i=1 to L of (L - i + 1) * a(i)) (mod 255) = 0
where L = the number of octets in the PDU header, and a(i) = the value
the octet at position i. The first octet in the PDU header is considered
occupy position i = 0.
When the function is in use, neither octet of the checksum field may
set to zero
ISO N4053 [Page 24]
RFC 995 December 1986
7.12 Classification of
Implementations do not have to support all of the functions
in clause 7. Functions are divided into four categories
Type A: These functions must be supported in all cases
Type B: These functions must be supported by Systems which
the Configuration Information
Type C: These functions must be supported by Systems which
the Redirect Information
Type D: These functions are optional
If a PDU is received which invokes an optional function that is
implemented, that PDU is discarded
Table 3 shows how the functions are divided into these
categories, and to which type of system (ES, IS, or both) they apply
______________________________________________________________
| Function | Category | System Type |
|_______________________________|____________|_______________|
| Report Configuration | B | ES,IS |
| Record Configuration | B | ES,IS |
| Configuration Response | A | ES |
| Flush Old Configuration | B | ES,IS |
| Request Redirect | C | IS |
| Query Configuration | B | ES |
| Record Redirect | C | ES |
| Refresh Redirect | D | ES |
| Flush Old Redirect | C | ES |
| PDU Header Error Detection | A | ES,IS |
|_______________________________|____________|_______________|
Table 3: Categories of Protocol
8 Structure and Encoding of
Note
The encoding of the PDUs for this protocol is compatible with
used in ISO 8473.
Temporary Note
The method employed for describing the encoding of PDUs is provisional
Member bodies are requested to comment on whether
method (such as ASN.1 with an appropriate concrete syntax)
be preferable
ISO N4053 [Page 25]
RFC 995 December 1986
8.1
All Protocol Data Units shall contain an integral number
octets.The octets in a PDU are numbered starting from one (1) and in
creasing in the order in which they are put into an SNSDU. The
in an octet are numbered from one (1) to eight (8), where bit one (1)
is the low-order bit. When consecutive octets are used to
a binary number, the lower octet number has the most
value
Any subnetwork supporting this protocol is required to state in
specification the way octets are transferred, using the terms "
significant bit" and "least significant bit". The PDUs of this proto
col are defined using the terms "most significant bit" and "
significant bit".
Note
When the encoding of a PDU is represented using a diagram in
section, the following representation is used
a) octets are shown with the lowest numbered octet to the left
higher number octets being further to the right
b) within an octet, bits are shown with bit eight (8) to the left
bit one (1) to the right
PDUs shall contain, in the following order
1. the fixed part
2. the Network address part
3. the Subnetwork address part, if present;
4. the Options part, if present
8.2 Fixed
8.2.1
The fixed part contains frequently occurring parameters including
type code (ESH, ISH, or RD) of the protocol data unit.The length
the structure of the fixed part are defined by the PDU code
ISO N4053 [Page 26]
RFC 995 December 1986
The fixed part has the following format
________________________________________
| Network Layer Protocol Identifier | 1
|______________________________________|
| Length Indicator | 2
|______________________________________|
| Version/Protocol Id Extension | 3
|______________________________________|
| reserved (must be zero) | 4
|______________________________________|
| 0 |0 |0 | Type | 5
|___|__|__|____________________________|
| Holding Time | 6,7
|______________________________________|
| Checksum | 8,9
|______________________________________|
Figure 1: PDU Header -- Fixed
8.2.2 Network Layer Protocol
The value of this field shall be 1000 0010.
Temporary Note
The value 1000 0010 is provisional, pending resolution of the
issue in SC6.
This field identifies this Network Layer Protocol as ISO SC6/N4053,
End System to Intermediate System Routing Exchange Protocol for use
conjunction with ISO 8473.
8.2.3 Length
The length is indicated by a binary number, with a maximum value
254 (1111 1110).The length indicated is the length of the entire
(which consists entirely of header, since this protocol does not car
ry user data) in octets, as described in clause 8.1. The value 255
(1111 1111) is reserved for possible future extensions
8.2.4 Version/Protocol Identifier
The value of this field is binary 0000 0001. This identifies a stan
dard version of ISO xxxx, End System to Intermediate System
Exchange Protocol for use in conjunction with ISO 8473.
ISO N4053 [Page 27]
RFC 995 December 1986
8.2.5 Type
The Type code field identifies the type of the protocol data unit
Allowed values are given in table 4.
_____________________________________________________
| | Bits 5 4 3 2 1 |
|____________|______________________________________|
|____________|______________________________________|
|ESH PDU | 0 0 0 1 0 |
|____________|______________________________________|
|ISH PDU | 0 0 1 0 0 |
|____________|______________________________________|
|RD PDU | 0 0 1 1 0 |
|____________|______________________________________|
Table 4: Valid PDU
All other PDU type values are reserved
8.2.6 Holding
The Holding Time field specifies for how long the receiving
entity should retain the configuration/routing information
in this PDU. The receiving Network entity should discard any infor
mation obtained from this PDU from its internal state when the hold
ing time expires. The Holding time field is encoded as an
number of micro-fortnights
8.2.7 PDU
The checksum is computed on the entire PDU header. A checksum
of zero is reserved to indicate that the checksum is to be ignored
The operation of the PDU Header Error Detection function (
7.11) ensures that the value zero does not represent a valid check
sum. A non-zero value indicates that the checksum must be processed
If the checksum calculation fails, the PDU must be discarded
8.3 Network Address
8.3.1
Address parameters are distinguished by their location. The
PDU types carry different address parameters however.The ESH PDU car
ries a Source NSAP address (SA); the ISH PDU carries a
System Network entity Title (NET); and the RD PDU carries a Destina
tion NSAP address (DA), and 