rfc995.txt

RFC 相关的技术文档

   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 completes normal processing
   of the received NPDU and forwards it.It then constructs a Redirect
   PDU (RD PDU) containing the Destination Address of the original NPDU,
   the subnetwork address of the better next hop (BSNPA), the Network
   Entity Title of the IS to which the ES is being redirected (unless
   the redirect is to the destination ES), a Holding Time (HT), QoS
   Maintenance, Priority, and Security options that were present in the
   Data NPDU (these are simply copied from the Data PDU). The HT is set



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 insufficient
   resources to both forward the original NPDU and to generate and send
   an RD PDU, the original NPDU must be given preference.  The Inter-
   mediate System (assuming it has sufficient resources) then sends the
   RD PDU to the source End System using the SN_Source_Address of the
   received NPDU as the SN_Destination_Address for the SN_UNITDATA.-
   Reqeust.

7.8   Record Redirect Function

   The Record Redirect Function is present only in End Systems. This
   function is invoked whenever an RD PDU is received. It extracts the
   redirect information and adds or replaces the corresponding redirec-
   tion information in the local Network entity's Routing Information
   base. The essential information is the redirection mapping from a
   Destination Address to a subnetwork address, along with the Priority,
   Security, and QoS Maintenance options and the Holding Time for which
   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 Intermediate
     System will continue to forward PDUs on behalf of this Network entity
     anyway.

7.9   Refresh Redirect Function

   The Refresh Redirect Function is present only in End Systems. This
   function is invoked whenever an NPDU is received by a destination ES.
   It is closely coupled with the function that processes received NPDUs
   at a destination Network Entity.This is the "PDU Decomposition" func-
   tion in ISO 8473.  The purpose of this function is to increase the
   longevity of a redirection without allowing an incorrect route to
   persist indefinitely.  The Source Address (SA), Priority, Security,
   and QoS options are extracted and compared to any Destination Address
   and QoS parameters being maintained in the Routing Information base
   (such information would have been stored by the Record Redirect Func-
   tion). If a corresponding entry is found, the previous hop of the PDU
   is obtained from the SN_Source_Address parameter of the
   SN_Unitdata.Indication primitive by which it was received.  If this
   address matches the next hop address stored with the redirection in-
   formation, the remaining holding time for the redirection is reset to
   the original holding timer that was obtained from the RD PDU.

                                       Note:
     The purpose of this function is to avoid timing out redirection entries
     when the Network entity is receiving return traffic from the destination
     via the same path over which it is currently sending traffic.This is



ISO N4053                                                      [Page 23]

RFC 995                                                    December 1986


     particularly useful when the destination system is on the same subnetwork
     as the source, since after one redirect no IS need be involved in
     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 time
     should be refreshed only under the exact conditions specified above.
     For a discussion of the issues surrounding the refresh of redirection
     information, see Annex 10.

7.10   Flush Old Redirect Function