InfoMagic Standards 1993 July/Disc.iso/misc/merit/noop/tutorial/esisint.doc/text0000.txt

Text File | 1991-04-01 | 16.4 KB | 370 lines

Sue:
  I've formatted esis.intro.doc to have more uniform margins.
  Cheers,
    -- Guy




    A tutorial on the ES-IS protocol



by: Robert Hagens
    University of Wisconsin
    [e-mail]



Introduction



    On a typical OSI subnetwork, computers (systems) generally fall
    into two classes: End Systems (ES) and Intermediate Systems (IS).
    This classification is made from a layer point of view: both
    systems contain the OSI layers 1 (physical) through 3 (network).
    However, an ES also contains OSI layers 4 - 7. An IS does not. ****

    [**** Footnote: The distinction between ESs and ISs is gray when
    real systems are considered. For example, although an IS may
    primarily route packets, it may also have layers 4 - 7 present in
    order to operate network management protocols.]

    The basic idea is that ESs are systems that run applications that
    send and receive packets of information and ISs are systems that
    route the packets from source to destination. This general concept
    can be readily subdivided into two cases. The first case occurs
    when the source and destination ES are connected to the same
    subnetwork (see Figure 1, host A communicating with host B). Since
    A and B are on the same subnetwork, packets may flow directly
    between them without the intervention of an IS.  The second case
    occurs when the source and destination ES are not connected to the
    same subnetwork (Figure 1, host A communicating with host C). It is
    important to note that in the second case, packets flowing from
    A to C must be fowarded from one subnetwork to the other by IS D.

    The End System to Intermediate System routing exchange protocol
    (ISO 9542) is designed to aid the two types of communication
    between ESs and ISs described above. The protocol provides a means
    for ESs and ISs on a subnetwork to learn of each other's existence.
    This process, known as *configuration*, allows ESs and ISs to
    dynamically determine the existence of each other. The dynamic
    quality of the protocol eliminates the need for manual
    configuration of the different types of systems on a subnetwork.
    In addition to promoting the exchange of configuration information,
    the protocol provides a means for route *redirection* information
    to be sent from an IS to an ES. This allows an IS to inform an ES
    of a potentially better route towards a destination.

    As explained below, the ES-IS protocol distinguishes different
    types of subnetworks.  The operation of the protocol is quite
    different on each type of subnetwork.  The difference between the
    broadcast subnetwork (i.e., 802.3) version and the general topology
    subnetwork (i.e., X.25) version is so large that there are two
    distinct versions of the protocol defined.  This article will not
    describe the operation of ES-IS over X.25. Rather, it will concern
    itself with the operation of the ES-IS protocol when it is used in
    conjunction with the OSI connectionless-mode network protocol
    (ISO 8473).

Configuration Information

    Configuration information is transmitted by exchanging two types of
    packets: the End System Hello (ESH) packet is generated by ESs and
    transmitted to every IS on the subnetwork.  The Intermediate System
    Hello (ISH) packet is generated by ISs and transmitted to every ES
    on the subnetwork. The primary purpose of the hello packets is to
    convey the subnetwork and network layer address of the system that
    transmitted the packet. The ESH and the ISH packets are generated
    by a system when the system's configuration timer expires.  When
    the timer expires, a hello packet is transmitted and the timer
    reset to its initial value. The initial value of the timer is
    maintained locally by the system.  The interval between
    transmission of hello packets may be modified by adjusting this
    timer.

    The configuration interval must be coordinated with the value of
    the holding timer that is transmitted with the hello packet.  The
    holding timer indicates to the receiving system the number of
    seconds that the configuration information should be kept.  When
    the holding timer expires, the associated configuration information
    must be deleted. If the holding timer is smaller than the
    configuration timer, systems may "disappear" from the subnetwork
    for periods of time.


Redirection Information

    Redirection information is transmitted via a RD PDU. These PDUs are
    only generated by ISs. The purpose of an RD PDU is to inform an ES
    of a potentially better route towards its destination.

    During the forwarding process, an IS will determine the next system
    to which the packet should be sent. If an IS can determine that
    this "next hop" system can be reached directly, without the IS's
    intervention, then a RD PDU will be sent from the IS to the
    originator of the packet.

    The RD PDU may redirect an ES to either the destination ES or to a
    different IS. The lifetime of the information conveyed by the RD
    PDU is limited by a holding timer, just like the hello PDUs.

    Normally, the redirection information delivered in an RD PDU is
    specific to a single destination address.  However, as an option,
    it is possible for an RD PDU to indicate that the redirection
    information should be applied to a larger number of destination
    addresses.  This is accomplished by including an address mask which
    indicates the larger population of destination addresses.

Subnetwork Topology Considerations

    The ES-IS protocol identifies 3 common subnetwork topologies: a
    point-to-point subnetwork, a broadcast subnetwork, and a general
    topology subnetwork. The point-to-point subnetwork supports
    exactly two systems. The broadcast and general topology subnetworks
    support an arbitrary number of systems. The crucial difference
    between the latter two types is the cost of sending a packet to a
    large subset of the subnetwork population. If the cost of such an
    *n-way* transmission scales directly with the subset size, then the
    subnetwork topology is considered general (a common example is an
    X.25 subnetwork).  If the cost of an *n-way* transmission is close
    to the cost of a transmission to a single system, then the topology
    is broadcast (a common example is 802.3).  This difference affects
    the transmission of configuration information.

    Ideally, configuration information is sent to many systems on the
    subnetwork simultaneously.  When operating on a broadcast
    subnetwork, ESHs are sent to a special multicast address "all
    intermediate systems".  ISHs are sent to a special multicast
    address "all end systems".  This multicast address may be realized
    physically as a true multicast or as a broadcast to every system.
    When operating on a general topology subnetwork, configuration
    information is generally not transmitted due to the high cost of a
    multicast transmission.

Network and Subnetwork Addresses

    The addresses described so far have been network layer addresses.
    There are actually two different kinds of addresses that the ES-IS
    protocol conveys: network layer addresses and subnetwork addresses.

    Network layer addresses identify either the interface between layer
    3 and layer 4 in an OSI ES (called a Network Service Access Point,
    NSAP), or the network layer entity itself in an OSI IS (called a
    Network Entity Title, NET).  NSAP addresses and NETs are part of a
    name space which spans all OSI networks.

    These network layer addresses can be contrasted with a subnetwork
    point of attachment address (SNPA address).  The SNPA is the point
    where an ES or IS is physically attached to a subnetwork.  The SNPA
    address is used by the subnetwork to uniquely identify each system
    attached to the subnetwork.  For example, in an 802.3 subnetwork,
    the SNPA address corresponds to the 48 bit MAC address.

    When an ES or IS transmits a packet, it is necessary to determine
    the destination SNPA address.  This is generally accomplished by
    associating a NSAP address or NET with a specific SNPA address.
    Part of the configuration information transmitted by the ES-IS
    protocol is this NSAP address (or NET) to SNPA address mapping.

Operational Scenarios

    It is often useful to consider real-life scenarios in order to get
    an intuitive idea of how a protocol operates. In the following
    examples, please refer to Figure 1. Furthermore, assume that the
    subnetworks in Figure 1 are broadcast subnetworks and that capital
    letters are NSAP & NET addresses, whereas lower letters are
    corresponding SNPA addresses.

    Example 1:
    ES A wishes to send a packet to ES C.  ES A knows about IS D
    because it receives periodic ISH packets from IS D. Since D is an
    IS, and ISs should know how to route packets toward any
    destination, ES A will send its packet directly to IS D.  In
    addition to knowing that IS D is an intermediate system, ES A also
    knows the SNPA for IS D.  This information was taken from the ISH
    received from IS D.  Result: ES A sends the packet to IS D at SNPA
    d and IS D forwards the packet to ES C.

    Example 2a:
    ES A wishes to send a packet to ES B.  As in example 1, ES A knows
    about IS D due to receipt of ISH packets from D. Therefore, ES A
    will send its packet to IS D at SNPA d. IS D has knowledge about
    both ES A and ES B because it receives ESH packets from both.  When
    IS D receives the data packet from ES A, it computes that ES B is
    reachable via the same subnetwork as ES A, and forwards the data
    packet to ES B.  In addition, IS D computes that ES A could have
    sent the packet directly to ES B.  IS D notifies ES A of this fact
    by sending a RD PDU to ES A.  This RD PDU indicates that ES B may
    be reached by sending packets directly to SNPA b.  Further packets
    sent by ES A to ES B are directed toward ES B.

    Example 2b:
    This is the same scenario as 2a, but with a twist.  Assume that ES
    A's routing information states that ES B is on the *same
    subnetwork* as ES A. The only problem is that ES A does not know
    the SNPA for ES B.  ES A has two choices.  As in 2a, it could send
    the packet to IS D and receive a redirect.  Or, as an optimization,
    ES A could listen to ESH PDUs sent on the subnetwork.  If ES A
    eavesdropped, it would know the SNPA of B. ES A could then transmit
    the packet directly to ES B at SNPA b.

    Example 3:
    Similar to scenario 2b, assume that ES A wishes to send to ES B.
    In addition, ES A knows that ES B is on the same subnetwork.
    Furthermore, assume that ES A does not eavesdrop and IS D does not
    exist.  How can ES A determine the SNPA of ES B? In this situation,
    ES A will invoke a function of the ES-IS protocol called query
    configuration.  To do this, ES A will *broadcast* its *data* packet
    to all ESs on the subnetwork.  When ES B receives this broadcasted
    packet, it will note: 1) that the packet is a data packet sent to a
    broadcast SNPA address; 2) that the destination NSAP address of the
    broadcasted packet is ES B.  In this case, ES B will generate an
    ESH packet and send it directly to ES A.  This packet will inform
    ES A of the SNPA of ES B.

    A commonly asked question, when considering example 3, is "If ES A
    does not eavesdrop ESH packets, how can it receive the ESH sent
    directly by ES B ?" The key to the answer is SNPA addresses.  When
    an ES eavesdrops, it *enables* the reception of packets addressed
    to the multicast address "all intermediate systems" (because end
    systems send their ESH packets to the multicast address "all
    intermediate systems").   When ES B sends an ESH to ES A, it sends
    it directly to SNPA a. ES A will receive this packet even if the
    "all intermediate systems" multicast address is not enabled.

PDU formats

    Figure 2 and 3 show the format of the ESH and ISH packets.  The
    format of these packets is very similar: they both have a fixed
    header which is almost identical to the fixed part of an ISO 8473
    (CLNP) packet.  Following the fixed part, each hello packet has
    space to store a network address.  Note that an ESH has space for
    more than 1 NSAP address, (since an ES may support several NSAPs)
    whereas an ISH has space for only 1 NET.

    The discerning reader will note that there is no place in either
    the ESH or ISH packet to store an SNPA address.  How can this
    information be transmitted from system to system?  The answer lies
    in the subnetwork service definition. By fiat, when a packet is
    delivered by a subnetwork service, the delivery will include not
    only the data packet but also the subnetwork source and destination
    address.  Thus, when processing an ESH, the SNPA associated with
    the ES is taken from the *source SNPA address* which accompanies
    the delivery of the ESH.

Comparison to DoD Protocols

    The ES-IS routing exchange protocol does not have an exact
    counterpart in the DoD protocol suite.  The configuration
    information exchange function is similar to the function of the
    Address Resolution Protocol (ARP, RFC 826).  However, ARP was
    designed around an "on demand" approach, that is, query when the
    information is needed.  This is in contrast to ES-IS where the
    design is based around continual update messages (hello packets).
    It should be noted that the query configuration function (shown in
    example 3) is somewhat analogous to the ARP "on demand" approach.
    However, unlike ARP, query configuration requires that the entire
    data packet, rather than an ARP request, be broadcast on the
    subnetwork.

    The counterpart to the ES-IS redirection information function in
    the DoD protocol suite is the redirect message defined by the ICMP
    protocol (RFC 792). These two approaches to redirect differ in that
    ES-IS allows the target of a redirect to be either an ES or IS
    whereas an ICMP redirect can only refer to a gateway.


=============================================================================

Figure 1

          +-------+
          |       |
          | ES A  |------|
          |       |      |
          +-------+      |
                         |
                         |   +-------+   |
                         |   |       |   |
                         |---| IS D  |---|
                         |   |       |   |
                         |   +-------+   |     +-------+
                         |               |     |       |
          +-------+      |               |-----| ES C  |
          |       |      |                     |       |
          | ES B  |------|                     +-------+
          |       |
          +-------+

=============================================================================

Figure 2

    The ESH Packet Format

+-------------------------------------------------------------+
|               Network Layer Protocol Identifier
+-------------------------------------------------------------+
|                Length Indicator
+-------------------------------------------------------------+
|                Version/Protocol Id extension
+-------------------------------------------------------------+
|                Reserved
+-------------------------------------------------------------+
|  0  | 0 | 0 |   Type of Packet
+-------------------------------------------------------------+
|               Holding
|               Time
+-------------------------------------------------------------+
|               Checksum
|
+-------------------------------------------------------------+
|               Number of Source Addresses
+-------------------------------------------------------------+
|               Source Address Length
+-------------------------------------------------------------+
/
                Source Address
/
|
+-------------------------------------------------------------+
.
.
+-------------------------------------------------------------+


=============================================================================

Figure 3

    The ISH Packet Format

+-------------------------------------------------------------+
|               Network Layer Protocol Identifier
+-------------------------------------------------------------+
|                Length Indicator
+-------------------------------------------------------------+
|                Version/Protocol Id extension
+-------------------------------------------------------------+
|                Reserved
+-------------------------------------------------------------+
|  0  | 0 | 0 |   Type of Packet
+-------------------------------------------------------------+
|               Holding
|               Time
+-------------------------------------------------------------+
|               Checksum
|
+-------------------------------------------------------------+
|               Network Entity Title Length
+-------------------------------------------------------------+
/
                Network Entity Title
/
|
+-------------------------------------------------------------+