Modified the route change discussion in Section 7.1, adding a new Section 7.1.4
covering the possibility that there may be multiple routes in use in parallel
(either because of load splitting or very rapid route flapping).  The new
subsection includes some of the text from the old section 1.1, and also
introduces the SII concept.

New section 7.1.4:

7.1.4.  Load Splitting and Route Flapping

   The Q-mode encapsulation rules of Section 5.8 try to ensure that the
   Query messages discovering the path mimic the flow as accurately as
   possible.  However, in environments where there is load balancing
   over multiple routes, and this is based on header fields differing
   between flow and Q-mode packets or done on a round-robin basis, the
   path discovered by the Query may vary from one handshake to the next
   even though the underlying network is stable.  This will appear to
   GIST as a route flap; route flapping can also be caused by problems
   in the basic network connectivity or routing protocol operation.

   This specification does not define mechanisms for GIST to manage
   multiple parallel routes or an unstable route.  The algorithms
   already described always maintain the concept of the current route,
   i.e. the latest peer discovered for a particular flow.  Instead, GIST
   allows the use of prior signalling paths for some period while the
   signalling applications still need them.  Since NSLP peers are a
   single GIST hop apart, the necessary information to represent a path
   can be just an entry in the node's routing state table for that flow
   (more generally, anything that uniquely identifies the peer, such as
   the NLI, could be used).  Rather than requiring GIST to maintain
   multiple generations of this information, it is provided to the
   signalling application in the same node in an opaque form for each
   message that is received from the peer.  The signalling application
   can store it if necessary and provide it back to the GIST layer in
   case it needs to be used.  Because this is a reference to information
   about the source of a prior signalling message, it is denoted 'SII-
   Handle' (for Source Identification Information) in the abstract API
   of Appendix B.

   Note that GIST if possible SHOULD use the same SII-Handle for
   multiple sessions to the same peer, since this then allows signalling
   applications to aggregate some signalling, such as summary refreshes
   or bulk teardowns.  Messages sent using the SII-Handle MUST bypass
   the routing state tables at the sender, and this MUST be indicated by
   setting the E flag in the common header (Appendix A.1).  Messages
   other than Data messages MUST NOT be sent in this way.  At the
   receiver, GIST MUST NOT validate the MRI/SID/NSLPID against local
   routing state and instead indicates the mode of reception to
   signalling applications through the API (Appendix B.2).  Signalling
   applications should validate the source and effect of the message
   themselves, and if appropriate should in particular indicate to GIST
   (see Appendix B.5) that routing state is no longer required for this
   flow.  This is necessary to prevent GIST in nodes on the old path
   initiating routing state refresh and thus causing state conflicts at
   the crossover router.

   GIST notifies signalling applications about route modifications as
   two types of event, additions and deletions.  An addition is notified
   as a change of the current routing state according to the Bad/
   Tentative/Good classification above, while deletion is expressed as a
   statement that an SII handle no longer lies on the path.  Both can be
   reported through the NetworkNotification API call (Appendix B.4).  A
   minimal implementation MAY notify a route change as a single (add,
   delete) operation; however, a more sophisticated implementation MAY
   delay the delete notification, for example if it knows that the old
   route continues to be used in parallel, or that the true route is
   flapping between the two.  It is then a matter of signalling
   application design whether to tear down state on the old path, leave
   it unchanged, or modify it in some signalling application specific
   way to reflect the fact that multiple paths are operating in
   parallel.