tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5974

 
 
 

NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling

Part 2 of 6, p. 6 to 26
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 6 
3.  Protocol Overview

3.1.  Overall Approach

   This section presents a logical model for the operation of the QoS
   NSLP and associated provisioning mechanisms within a single node.
   The model is shown in Figure 2.

Top      Up      ToC       Page 7 
                                     +-----------------+
                                     |      Local      |
                                     | Applications or |
                                     |Management (e.g.,|
                                     | for aggregates) |
                                     +-----------------+
                                              ^
                                              V
                                              V
               +----------+             +----------+      +---------+
               | QoS NSLP |             | Resource |      | Policy  |
               |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
               +----------+             +----------+      +---------+
                 .  ^   |              *      ^
                 |  V   .            *        ^
               +----------+        *          ^
               |   NTLP   |       *           ^
               |Processing|       *           V
               +----------+       *           V
                 |      |         *           V
     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                 .      .         *           V
                 |      |         *     .............................
                 .      .         *     .   Traffic Control         .
                 |      |         *     .                +---------+.
                 .      .         *     .                |Admission|.
                 |      |         *     .                | Control |.
       +----------+    +------------+   .                +---------+.
   <-.-|  Input   |    | Outgoing   |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
       |  Packet  |    | Interface  |   .+----------+    +---------+.
   ===>|Processing|====| Selection  |===.|  Packet  |====| Packet  |.==>
       |          |    |(Forwarding)|   .|Classifier|     Scheduler|.
       +----------+    +------------+   .+----------+    +---------+.
                                        .............................
           <.-.-> = signaling flow
           =====> = data flow (sender --> receiver)
           <<<>>> = control and configuration operations
           ****** = routing table manipulation

                       Figure 2: QoS NSLP in a Node

   This diagram shows an example implementation scenario where QoS
   conditioning is performed on the output interface.  However, this
   does not limit the possible implementations.  For example, in some
   cases, traffic conditioning may be performed on the incoming
   interface, or it may be split over the input and output interfaces.

Top      Up      ToC       Page 8 
   Also, the interactions with the Policy Control component may be more
   complex, involving interaction with the Resource Management Function,
   and the AAA infrastructure.

   From the perspective of a single node, the request for QoS may result
   from a local application request or from processing an incoming QoS
   NSLP message.  The request from a local application includes not only
   user applications but also network management and the policy control
   module.  For example, a request could come from multimedia
   applications, initiate a tunnel to handle an aggregate, interwork
   with some other reservation protocol (such as RSVP), and contain an
   explicit teardown triggered by a AAA policy control module.  In this
   sense, the model does not distinguish between hosts and routers.

   Incoming messages are captured during input packet processing and
   handled by GIST.  Only messages related to QoS are passed to the QoS
   NSLP.  GIST may also generate triggers to the QoS NSLP (e.g.,
   indications that a route change has occurred).  The QoS request is
   handled by the RMF, which coordinates the activities required to
   grant and configure the resource.  It also handles policy-specific
   aspects of QoS signaling.

   The grant processing involves two local decision modules, 'policy
   control' and 'admission control'.  Policy control determines whether
   the user is authorized to make the reservation.  Admission control
   determines whether the network of the node has sufficient available
   resources to supply the requested QoS.  If both checks succeed,
   parameters are set in the packet classifier and in the link-layer
   interface (e.g., in the packet scheduler) to obtain the desired QoS.
   Error notifications are passed back to the request originator.  The
   Resource Management Function may also manipulate the forwarding
   tables at this stage to select (or at least pin) a route; this must
   be done before interface-dependent actions are carried out (including
   sending outgoing messages over any new route), and is in any case
   invisible to the operation of the protocol.

   Policy control is expected to make use of the authentication
   infrastructure or the authentication protocols external to the node
   itself.  Some discussion can be found in a separate document on
   authorization issues [qos-auth].  More generally, the processing of
   policy and Resource Management Functions may be outsourced to an
   external node, leaving only 'stubs' co-located with the NSLP node;
   this is not visible to the protocol operation.  A more detailed
   discussion of authentication and authorization can be found in
   Section 3.1.3.

Top      Up      ToC       Page 9 
   Admission control, packet scheduling, and any part of policy control
   beyond simple authorization have to be implemented using specific
   definitions for types and levels of QoS.  A key assumption is made
   that the QoS NSLP is independent of the QoS parameters (e.g., IntServ
   service elements).  These are captured in a QoS model and interpreted
   only by the resource management and associated functions, and are
   opaque to the QoS NSLP itself.  QoS models are discussed further in
   Section 3.1.2.

   The final stage of processing for a resource request is to indicate
   to the QoS NSLP protocol processing that the required resources have
   been configured.  The QoS NSLP may generate an acknowledgment message
   in one direction, and may forward the resource request in the other.
   Message routing is carried out by the GIST module.  Note that while
   Figure 2 shows a unidirectional data flow, the signaling messages can
   pass in both directions through the node, depending on the particular
   message and orientation of the reservation.

3.1.1.  Protocol Messages

   The QoS NSLP uses four message types:

   RESERVE: The RESERVE message is the only message that manipulates QoS
   NSLP reservation state.  It is used to create, refresh, modify, and
   remove such state.  The result of a RESERVE message is the same
   whether a message is received once or many times.

   QUERY: A QUERY message is used to request information about the data
   path without making a reservation.  This functionality can be used to
   make reservations or to support certain QoS models.  The information
   obtained from a QUERY may be used in the admission control process of
   a QNE (e.g., in case of measurement-based admission control).  Note
   that a QUERY does not change existing reservation state.

   RESPONSE: The RESPONSE message is used to provide information about
   the result of a previous QoS NSLP message.  This includes explicit
   confirmation of the state manipulation signaled in the RESERVE
   message, and the response to a QUERY message or an error code if the
   QNE or QNR is unable to provide the requested information or if the
   response is negative.  The RESPONSE message does not cause any
   reservation state to be installed or modified.

   NOTIFY: NOTIFY messages are used to convey information to a QNE.
   They differ from RESPONSE messages in that they are sent
   asynchronously and need not refer to any particular state or
   previously received message.  The information conveyed by a NOTIFY

Top      Up      ToC       Page 10 
   message is typically related to error conditions.  Examples would be
   notification to an upstream peer about state being torn down or
   notification when a reservation has been preempted.

   QoS NSLP messages are sent peer-to-peer.  This means that a QNE
   considers its adjacent upstream or downstream peer to be the source
   of each message.

   Each protocol message has a common header which indicates the message
   type and contains various flag bits.  Message formats are defined in
   Section 5.1.2.  Message processing rules are defined in Section 5.4.

   QoS NSLP messages contain three types of objects:

   1.  Control Information: Control information objects carry general
       information for the QoS NSLP processing, such as sequence numbers
       or whether a response is required.

   2.  QoS specifications (QSPECs): QSPEC objects describe the actual
       resources that are required and depend on the QoS model being
       used.  Besides any resource description, they may also contain
       other control information used by the RMF's processing.

   3.  Policy objects: Policy objects contain data used to authorize the
       reservation of resources.

   Object formats are defined in Section 5.1.3.  Object processing rules
   are defined in Section 5.3.

3.1.2.  QoS Models and QoS Specifications

   The QoS NSLP provides flexibility over the exact patterns of
   signaling messages that are exchanged.  The decoupling of QoS NSLP
   and QSPEC allows the QoS NSLP to be ignorant about the ways in which
   traffic, resources, etc., are described, and it can treat the QSPEC
   as an opaque object.  Various QoS models can be designed, and these
   do not affect the specification of the QoS NSLP protocol.  Only the
   RMF specific to a given QoS model will need to interpret the QSPEC.
   The Resource Management Function (RMF) reserves resources for each
   flow.

   The QSPEC fulfills a similar purpose to the TSpec, RSpec, and AdSpec
   objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC
   2210 [RFC2210].  At each QNE, the content of the QSPEC is interpreted
   by the Resource Management Function and the Policy Control Function
   for the purposes of traffic and policy control (including admission
   control and configuration of the packet classifier and scheduler).

Top      Up      ToC       Page 11 
   The QoS NSLP does not mandate any particular behavior for the RMF,
   instead providing interoperability at the signaling-protocol level
   whilst leaving the validation of RMF behavior to contracts external
   to the protocol itself.  The RMF may make use of various elements
   from the QoS NSLP message, not only the QSPEC object.

   Still, this specification assumes that resource sharing is possible
   between flows with the same SESSION-ID that originate from the same
   QNI or between flows with a different SESSION-ID that are related
   through the BOUND-SESSION-ID object.  For flows with the same
   SESSION-ID, resource sharing is only applicable when the existing
   reservation is not just replaced (which is indicated by the REPLACE
   flag in the common header).  We assume that the QoS model supports
   resource sharing between flows.  A QoS Model may elect to implement a
   more general behavior of supporting relative operations on existing
   reservations, such as ADDING or SUBTRACTING a certain amount of
   resources from the current reservation.  A QoS Model may also elect
   to allow resource sharing more generally, e.g., between all flows
   with the same Differentiated Service Code Point (DSCP).

   The QSPEC carries a collection of objects that can describe QoS
   specifications in a number of different ways.  A generic template is
   defined in [RFC5975] and contains object formats for generally useful
   elements of the QoS description, which is designed to ensure
   interoperability when using the basic set of objects.  A QSPEC
   describing the resources requested will usually contain objects that
   need to be understood by all implementations, and it can also be
   enhanced with additional objects specific to a QoS model to provide a
   more exact definition to the RMF, which may be better able to use its
   specific resource management mechanisms (which may, e.g., be link
   specific) as a result.

   A QoS Model defines the behavior of the RMF, including inputs and
   outputs, and how QSPEC information is used to describe resources
   available, resources required, traffic descriptions, and control
   information required by the RMF.  A QoS Model also describes the
   minimum set of parameters QNEs should use in the QSPEC when signaling
   about this QoS Model.

   QoS Models may be local (private to one network), implementation/
   vendor specific, or global (implementable by different networks and
   vendors).  All QSPECs should follow the design of the QSPEC template.

   The definition of a QoS model may also have implications on how local
   behavior should be implemented in the areas where the QoS NSLP gives
   freedom to implementers.  For example, it may be useful to identify
   recommended behavior for how a forwarded RESERVE message relates to a
   received one, or for when additional signaling sessions should be

Top      Up      ToC       Page 12 
   started based on existing sessions, such as required for aggregate
   reservations.  In some cases, suggestions may be made on whether
   state that may optionally be retained should be held in particular
   scenarios.  A QoS model may specify reservation preemption, e.g., an
   incoming resource request may cause removal of an earlier established
   reservation.

3.1.3.  Policy Control

   Getting access to network resources, e.g., network access in general
   or access to QoS, typically involves some kind of policy control.
   One example of this is authorization of the resource requester.
   Policy control for QoS NSLP resource reservation signaling is
   conceptually organized as illustrated below in Figure 3.

                                  +-------------+
                                  | Policy      |
                                  | Decision    |
                                  | Point (PDP) |
                                  +------+------+
                                         |
                                 /-\-----+-----/\
                             ////                \\\\
                           ||                        ||
                          |      Policy transport      |
                           ||                        ||
                             \\\\                ////
                                 \-------+------/
                                         |
   +-------------+ QoS signaling  +------+------+
   |  Entity     |<==============>| QNE = Policy|<=========>
   |  requesting | Data Flow      | Enforcement |
   |  resource   |----------------|-Point (PEP)-|---------->
   +-------------+                +-------------+

           Figure 3: Policy Control with the QoS NSLP Signaling

   From the QoS NSLP point of view, the policy control model is
   essentially a two-party model between neighboring QNEs.  The actual
   policy decision may depend on the involvement of a third entity (the
   Policy Decision Point, PDP), but this happens outside of the QoS NSLP
   protocol by means of existing policy infrastructure (Common Open
   Policy Service (COPS), Diameter, etc.).  The policy control model for
   the entire end-to-end chain of QNEs is therefore one of transitivity,
   where each of the QNEs exchanges policy information with its QoS NSLP
   policy peer.

Top      Up      ToC       Page 13 
   The authorization of a resource request often depends on the identity
   of the entity making the request.  Authentication may be required.
   The GIST channel security mechanisms provide one way of
   authenticating the QoS NSLP peer that sent the request, and so may be
   used in making the authorization decision.

   Additional information might also be provided in order to assist in
   making the authorization decision.  This might include alternative
   methods of authenticating the request.

   The QoS NSLP does not currently contain objects to carry
   authorization information.  At the time of writing, there exists a
   separate individual work [NSIS-AUTH] that defines this functionality
   for the QoS NSLP and the NAT and firewall (NATFW) NSLP.

   It is generally assumed that policy enforcement is likely to
   concentrate on border nodes between administrative domains.  This may
   mean that nodes within the domain are "Policy-Ignorant Nodes" that
   perform no per-request authentication or authorization, relying on
   the border nodes to perform the enforcement.  In such cases, the
   policy management between ingress and egress edge of a domain relies
   on the internal chain of trust between the nodes in the domain.  If
   this is not acceptable, a separate signaling session can be set up
   between the ingress and egress edge nodes in order to exchange policy
   information.

3.2.  Design Background

   This section presents some of the key functionality behind the
   specification of the QoS NSLP.

3.2.1.  Soft States

   The NSIS protocol suite takes a soft-state approach to state
   management.  This means that reservation state in QNEs must be
   periodically refreshed.  The frequency with which state installation
   is refreshed is expressed in the REFRESH-PERIOD object.  This object
   contains a value in milliseconds indicating how long the state that
   is signaled for remains valid.  Maintaining the reservation beyond
   this lifetime can be done by sending a RESERVE message periodically.

3.2.2.  Sender and Receiver Initiation

   The QoS NSLP supports both sender-initiated and receiver-initiated
   reservations.  For a sender-initiated reservation, RESERVE messages
   travel in the same direction as the data flow that is being signaled
   for (the QNI is at the side of the source of the data flow).  For a

Top      Up      ToC       Page 14 
   receiver-initiated reservation, RESERVE messages travel in the
   opposite direction (the QNI is at the side of the receiver of the
   data flow).

   Note: these definitions follow the definitions in Section 3.3.1 of
   RFC 4080 [RFC4080].  The main issue is about which node is in charge
   of requesting and maintaining the resource reservation.  In a
   receiver-initiated reservation, even though the sender sends the
   initial QUERY, the receiver is still in charge of making the actual
   resource request and maintaining the reservation.

3.2.3.  Protection against Message Re-ordering and Duplication

   RESERVE messages affect the installed reservation state.  Unlike
   NOTIFY, QUERY, and RESPONSE messages, the order in which RESERVE
   messages are received influences the eventual reservation state that
   will be stored at a QNE; that is, the most recent RESERVE message
   replaces the current reservation.  Therefore, in order to protect
   against RESERVE message re-ordering or duplication, the QoS NSLP uses
   a Reservation Sequence Number (RSN).  The RSN has local significance
   only, i.e., between a QNE and its downstream peers.

3.2.4.  Explicit Confirmations

   A QNE may require a confirmation that the end-to-end reservation is
   in place, or a reply to a query along the path.  For such requests,
   it must be able to keep track of which request each response refers
   to.  This is supported by including a Request Identification
   Information (RII) object in a QoS NSLP message.

3.2.5.  Reduced Refreshes

   For scalability, the QoS NSLP supports an abbreviated form of refresh
   RESERVE message.  In this case, the refresh RESERVE references the
   reservation using the RSN and the SESSION-ID, and does not include
   the full reservation specification (including QSPEC).  By default,
   state refresh should be performed with reduced refreshes in order to
   save bytes during transmission.  Stateless QNEs will require full
   refresh since they do not store the whole reservation information.

   If the stateful QNE does not support reduced refreshes, or there is a
   mismatch between the local and received RSN, the stateful QNE must
   reply with a RESPONSE carrying an INFO-SPEC indicating the error.
   Furthermore, the QNE must stop sending reduced refreshes to this peer
   if the error indicates that support for this feature is lacking.

Top      Up      ToC       Page 15 
3.2.6.  Summary Refreshes and Summary Tear

   For limiting the number of individual messages, the QoS NSLP supports
   summary refresh and summary tear messages.  When sending a refreshing
   RESERVE for a certain (primary) session, a QNE may include a SESSION-
   ID-LIST object where the QNE indicates (secondary) sessions that are
   also refreshed.  An RSN-LIST object must also be added.  The SESSION-
   IDs and RSNs are stacked in the objects such that the index in both
   stacks refer to the same reservation state, i.e., the SESSION-ID and
   RSN at index i in both objects refers to the same session.  If the
   receiving stateful QNE notices unknown SESSION-IDs or a mismatch with
   RSNs for a session, it will reply back to the upstream stateful QNE
   with an error.

   In order to tear down several sessions at once, a QNE may include
   SESSION-ID-LIST and RSN-LIST objects in a tearing reserve.  The
   downstream stateful QNE must then also tear down the other sessions
   indicated.  The downstream stateful QNE must silently ignore any
   unknown SESSION-IDs.

   GIST provides a SII-Handle for every downstream session.  The SII-
   Handle identifies a peer and should be the same for all sessions
   whose downstream peer is the same.  The QoS NSLP uses this
   information to decide whether summary refresh messages can be sent or
   when a summary tear is possible.

3.2.7.  Message Scoping

   A QNE may use local policy when deciding whether to propagate a
   message or not.  For example, the local policy can define/configure
   that a QNE is, for a particular session, a QNI and/or a QNR.  The QoS
   NSLP also includes an explicit mechanism to restrict message
   propagation by means of a scoping mechanism.

   For a RESERVE or a QUERY message, two scoping flags limit the part of
   the path on which state is installed on the downstream nodes that can
   respond.  When the SCOPING flag is set to zero, it indicates that the
   scope is "whole path" (default).  When set to one, the scope is
   "single hop".  When the PROXY scope flag is set, the path is
   terminated at a pre-defined Proxy QNE (P-QNE).  This is similar to
   the Localized RSVP [lrsvp].

   The propagation of a RESPONSE message is limited by the RII object,
   which ensures that it is not forwarded back along the path further
   than the node that requested the RESPONSE.

Top      Up      ToC       Page 16 
3.2.8.  Session Binding

   Session binding is defined as the enforcement of a relation between
   different QoS NSLP sessions (i.e., signaling flows with different
   SESSION-IDs (SIDs) as defined in GIST [RFC5971]).

   Session binding indicates a unidirectional dependency relation
   between two or more sessions by including a BOUND-SESSION-ID object.
   A session with SID_A (the binding session) can express its
   unidirectional dependency relation to another session with SID_B (the
   bound session) by including a BOUND-SESSION-ID object containing
   SID_B in its messages.

   The concept of session binding is used to indicate the unidirectional
   dependency relation between the end-to-end session and the aggregate
   session in case of aggregate reservations.  In case of bidirectional
   reservations, it is used to express the unidirectional dependency
   relation between the sessions used for forward and reverse
   reservation.  Typically, the dependency relation indicated by session
   binding is purely informative in nature and does not automatically
   trigger any implicit action in a QNE.  A QNE may use the dependency
   relation information for local resource optimization or to explicitly
   tear down reservations that are no longer useful.  However, by using
   an explicit binding code (see Section 5.1.3.4), it is possible to
   formalize this dependency relation, meaning that if the bound session
   (e.g., session with SID_B) is terminated, the binding session (e.g.,
   the session with SID_A) must be terminated also.

   A message may include more than one BOUND-SESSION-ID object.  This
   may happen, e.g., in certain aggregation and bidirectional
   reservation scenarios, where an end-to-end session has a
   unidirectional dependency relation with an aggregate session and at
   the same time it has a unidirectional dependency relation with
   another session used for the reverse path.

3.2.9.  Message Binding

   QoS NSLP supports binding of messages in order to allow for
   expressing dependencies between different messages.  The message
   binding can indicate either a unidirectional or bidirectional
   dependency relation between two messages by including the MSG-ID
   object in one message ("binding message") and the BOUND-MSG-ID object
   in the other message ("bound message").  The unidirectional
   dependency means that only RESERVE messages are bound to each other
   whereas a bidirectional dependency means that there is also a
   dependency for the related RESPONSE messages.  The message binding
   can be used to speed up signaling by starting two signaling exchanges
   simultaneously that are synchronized later by using message IDs.

Top      Up      ToC       Page 17 
   This can be used as an optimization technique, for example, in
   scenarios where aggregate reservations are used.  Section 4.6
   provides more details.

3.2.10.  Layering

   The QoS NSLP supports layered reservations.  Layered reservations may
   occur when certain parts of the network (domains) implement one or
   more local QoS models or when they locally apply specific transport
   characteristics (e.g., GIST unreliable transfer mode instead of
   reliable transfer mode).  They may also occur when several per-flow
   reservations are locally combined into an aggregate reservation.

3.2.10.1.  Local QoS Models

   A domain may have local policies regarding QoS model implementation,
   i.e., it may map incoming traffic to its own locally defined QoS
   models.  The QSPEC allows this functionality, and the operation is
   transparent to the QoS NSLP.  The use of local QoS models within a
   domain is performed in the RMF.

3.2.10.2.  Local Control Plane Properties

   The way signaling messages are handled is mainly determined by the
   parameters that are sent over the GIST-NSLP API and by the domain
   internal configuration.  A domain may have a policy to implement
   local transport behavior.  It may, for instance, elect to use an
   unreliable transport locally in the domain while still keeping end-
   to-end reliability intact.

   The QoS NSLP supports this situation by allowing two sessions to be
   set up for the same reservation.  The local session has the desired
   local transport properties and is interpreted in internal QNEs.  This
   solution poses two requirements: the end-to-end session must be able
   to bypass intermediate nodes, and the egress QNE needs to bind both
   sessions together.  Bypassing intermediate nodes is achieved with
   GIST.  The local session and the end-to-end session are bound at the
   egress QNE by means of the BOUND-SESSION-ID object.

3.2.10.3.  Aggregate Reservations

   In some cases, it is desirable to create reservations for an
   aggregate, rather than on a per-flow basis, in order to reduce the
   amount of reservation state needed as well as the processing load for
   signaling messages.  Note that the QoS NSLP does not specify how
   reservations need to be combined in an aggregate or how end-to-end
   properties need to be computed, but only provides signaling support
   for aggregate reservations.

Top      Up      ToC       Page 18 
   The essential difference with the layering approaches described in
   Sections 3.2.10.1 and 3.2.10.2 is that the aggregate reservation
   needs a MRI that describes all traffic carried in the aggregate
   (e.g., a DSCP in case of IntServ over Diffserv).  The need for a
   different MRI mandates the use of two different sessions, as
   described in Section 3.2.10.2 and in the RSVP aggregation solution in
   RFC 3175 [RFC3175].

   Edge QNEs of the aggregation domain that want to maintain some end-
   to-end properties may establish a peering relation by sending the
   end-to-end message transparently over the domain (using the
   intermediate node bypass capability described above).  Updating the
   end-to-end properties in this message may require some knowledge of
   the aggregated session (e.g., for updating delay values).  For this
   purpose, the end-to-end session contains a BOUND-SESSION-ID carrying
   the SESSION-ID of the aggregate session.

3.2.11.  Support for Request Priorities

   This specification acknowledges the fact that in some situations,
   some messages or reservations may be more important than others, and
   therefore it foresees mechanisms to give these messages or
   reservations priority.

   Priority of certain signaling messages over others may be required in
   mobile scenarios when a message loss during call setup is less
   harmful than during handover.  This situation only occurs when GIST
   or QoS NSLP processing is the congested part or scarce resource.

   Priority of certain reservations over others may be required when QoS
   resources are oversubscribed.  In that case, existing reservations
   may be preempted in order to make room for new higher-priority
   reservations.  A typical approach to deal with priority and
   preemption is through the specification of a setup priority and
   holding priority for each reservation.  The Resource Management
   Function at each QNE then keeps track of the resource consumption at
   each priority level.  Reservations are established when resources, at
   their setup priority level, are still available.  They may cause
   preemption of reservations with a lower holding priority than their
   setup priority.

   Support of reservation priority is a QSPEC parameter and therefore
   outside the scope of this specification.  The GIST specification
   provides a mechanism to support a number of levels of message
   priority that can be requested over the NSLP-GIST API.

Top      Up      ToC       Page 19 
3.2.12.  Rerouting

   The QoS NSLP needs to adapt to route changes in the data path.  This
   assumes the capability to detect rerouting events, create a QoS
   reservation on the new path, and optionally tear down reservations on
   the old path.

   From an NSLP perspective, rerouting detection can be performed in two
   ways.  It can either come through NetworkNotification from GIST, or
   from information seen at the NSLP.  In the latter case, the QoS NSLP
   node is able to detect changes in its QoS NSLP peers by keeping track
   of a Source Identification Information (SII) handle that provides
   information similar in nature to the RSVP_HOP object described in RFC
   2205 [RFC2205].  When a RESERVE message with an existing SESSION-ID
   and a different SII is received, the QNE knows its upstream or
   downstream peer has changed, for sender-oriented and receiver-
   oriented reservations, respectively.

   Reservation on the new path happens when a RESERVE message arrives at
   the QNE beyond the point where the old and new paths diverge.  If the
   QoS NSLP suspects that a reroute has occurred, then a full RESERVE
   message (including the QSPEC) would be sent.  A refreshing RESERVE
   (with no QSPEC) will be identified as an error by a QNE on the new
   path, which does not have the reservation installed (i.e., it was not
   on the old path) or which previously had a different previous-hop
   QNE.  It will send back an error message that results in a full
   RESERVE message being sent.  Rapid recovery at the NSLP layer
   therefore requires short refresh periods.  Detection before the next
   RESERVE message arrives is only possible at the IP layer or through
   monitoring of GIST peering relations (e.g., by monitoring the Time to
   Live (TTL), i.e., the number of GIST hops between NSLP peers, or
   observing the changes in the outgoing interface towards GIST peer).
   These mechanisms can provide implementation-specific optimizations
   and are outside the scope of this specification.

   When the QoS NSLP is aware of the route change, it needs to set up
   the reservation on the new path.  This is done by sending a new
   RESERVE message.  If the next QNE is in fact unchanged, then this
   will be used to refresh/update the existing reservation.  Otherwise,
   it will lead to the reservation being installed on the new path.

   Note that the operation for a receiver-initiated reservation session
   differs a bit from the above description.  If the routing changes in
   the middle of the path, at some point (i.e., the divergence point)
   the QNE that notices that its downstream path has changed (indicated
   by a NetworkNotification from GIST), and it must send a QUERY with
   the R-flag downstream.  The QUERY will be processed as above, and at
   some point hits a QNE for which the path downstream towards the QNI

Top      Up      ToC       Page 20 
   remains (i.e., the convergence point).  This node must then send a
   full RESERVE upstream to set up the reservation state along the new
   path.  It should not send the QUERY further downstream, since this
   would have no real use.  Similarly, when the QNE that sent the QUERY
   receives the RESERVE, it should not send the RESERVE further
   upstream.

   After the reservation on the new path is set up, the branching node
   may want to tear down the reservation on the old path (sooner than
   would result from normal soft-state timeout).  This functionality is
   supported by keeping track of the old SII-Handle provided over the
   GIST API.  This handle can be used by the QoS NSLP to route messages
   explicitly to the next node.

   If the old path is downstream, the QNE can send a tearing RESERVE
   using the old SII-Handle.  If the old path is upstream, the QNE can
   send a NOTIFY with the code for "Route Change".  This is forwarded
   upstream until it hits a QNE that can issue a tearing RESERVE
   downstream.  A separate document discusses in detail the effect of
   mobility on the QoS NSLP signaling [NSIS-MOB].

   A QNI or a branch node may wish to keep the reservation on the old
   branch.  For instance, this could be the case when a mobile node has
   experienced a mobility event and wishes to keep reservation to its
   old attachment point in case it moves back there.  For this purpose,
   a REPLACE flag is provided in the QoS NSLP common header, which, when
   not set, indicates that the reservation on the old branch should be
   kept.

   Note that keeping old reservations affects the resources available to
   other nodes.  Thus, the operator of the access network must make the
   final decision on whether this behavior is allowed.  Also, the QNEs
   in the access network may add this flag even if the mobile node has
   not used the flag initially.

   The latency in detecting that a new downstream peer exists or that
   truncation has happened depends on GIST.  The default QUERY message
   transmission interval is 30 seconds.  More details on how NSLPs are
   able to affect the discovery of new peers or rerouting can be found
   in the GIST specification.

3.2.12.1.  Last Node Behavior

   The design of the QoS NSLP allows reservations to be installed at a
   subset of the nodes along a path.  In particular, usage scenarios
   include cases where the data flow endpoints do not support the QoS
   NSLP.

Top      Up      ToC       Page 21 
   In the case where the data flow receiver does not support the QoS
   NSLP, some particular considerations must be given to node discovery
   and rerouting at the end of the signaling path.

   There are three cases for the last node on the signaling path:

   1)  the last node is the data receiver,

   2)  the last node is a configured proxy for the data receiver, or

   3)  the last node is not the data receiver and is not explicitly
       configured to act as a signaling proxy on behalf of the data
       receiver.

   Cases (1) and (2) can be handled by the QoS NSLP itself during the
   initial path setup, since the QNE knows that it should terminate the
   signaling.  Case (3) requires some assistance from GIST, which
   provides messages across the API to indicate that no further GIST
   nodes that support QoS NSLP are present downstream, and that probing
   of the downstream route change needs to continue once the reservation
   is installed to detect any changes in this situation.

   Two particular scenarios need to be considered in this third case.
   In the first, referred to as "Path Extension", rerouting occurs such
   that an additional QNE is inserted into the signaling path between
   the old last node and the data receiver, as shown in Figure 4.

           /-------\   Initial route
          /         v
              /-\
           /--|B|--\                +-+
          /   \-/   \               |x| = QoS NSLP aware
       +-+           /-\            +-+
   ----|A|           |D|
       +-+           \-/            /-\
          \   +-+   /               |x| = QoS NSLP unaware
           \--|C|--/                \-/
              +-+
          \         ^
           \-------/   Updated route

                         Figure 4: Path Extension

   When rerouting occurs, the data path changes from A-B-D to A-C-D.
   Initially the signaling path ends at A.  Despite initially being the
   last node, node A needs to continue to attempt to send messages
   downstream to probe for path changes, unless it has been explicitly

Top      Up      ToC       Page 22 
   configured as a signaling proxy for the data flow receiver.  This is
   required so that the signaling path change is detected, and C will
   become the new last QNE.

   In a second case, referred to as "Path Truncation", rerouting occurs
   such that the QNE that was the last node on the signaling path is no
   longer on the data path.  This is shown in Figure 5.

           /-------\   Initial route
          /         v
              +-+
           /--|B|--\                 +-+
          /   +-+   \                |x| = QoS NSLP aware
       +-+           /-\             +-+
   ----|A|           |D|
       +-+           \-/             /-\
          \   /-\   /                |x| = QoS NSLP unaware
           \--|C|--/                 \-/
              \-/
          \         ^
           \-------/   Updated route

                         Figure 5: Path Truncation

   When rerouting occurs, the data path again changes from A-B-D to
   A-C-D.  The signaling path initially ends at B, but this node is not
   on the new path.  In this case, the normal GIST path change detection
   procedures at A will detect the path change and notify the QoS NSLP.
   GIST will also notify the signaling application that no downstream
   GIST nodes supporting the QoS NSLP are present.  Node A will take
   over as the last node on the signaling path.

3.2.12.2.  Handling Spurious Route Change Notifications

   The QoS NSLP is notified by GIST (with the NetworkNotification
   primitive) when GIST believes that a rerouting event may have
   occurred.  In some cases, events that are detected as possible route
   changes will turn out not to be.  The QoS NSLP will not always be
   able to detect this, even after receiving messages from the 'new'
   peer.

   As part of the RecvMessage API primitive, GIST provides an SII-Handle
   that can be used by the NSLP to direct a signaling message to a
   particular peer.  The current SII-Handle will change if the signaling
   peer changes.  However, it is not guaranteed to remain the same after
   a rerouting event where the peer does not change.  Therefore, the QoS
   NSLP mechanism for reservation maintenance after a route change

Top      Up      ToC       Page 23 
   includes robustness mechanisms to avoid accidentally tearing down a
   reservation in situations where the peer QNE has remained the same
   after a 'route change' notification from GIST.

   A simple example that illustrates the problem is shown in Figure 6
   below.

           (1)                         +-+
         /-----\                       |x| = QoS NSLP aware
       +-+     /-\ (3) +-+             +-+
   ----|A|     |B|-----|C|----
       +-+     \-/     +-+             /-\
         \-----/                       |x| = QoS NSLP unaware
           (2)                         \-/

                    Figure 6: Spurious Reroute Alerting

   In this example, the initial route A-B-C uses links (1) and (3).
   After link (1) fails, the path is rerouted using links (2) and (3).
   The set of QNEs along the path is unchanged (it is A-C in both cases,
   since B does not support the QoS NSLP).

   When the outgoing interface at A has changes, GIST may signal across
   its API to the NSLP with a NetworkNotification.  The QoS NSLP at A
   will then attempt to repair the path by installing the reservation on
   the path (2),(3).  In this case, however, the old and new paths are
   the same.

   To install the new reservation, A will send a RESERVE message, which
   GIST will transport to C (discovering the new next peer as
   appropriate).  The RESERVE also requests a RESPONSE from the QNR.
   When this RESERVE message is received through the RecvMessage API
   call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged
   from its previous communications from A.

   A RESPONSE message will be sent by the QNR, and be forwarded from C
   to A.  This confirms that the reservation was installed on the new
   path.  The SII-Handle passed with the RecvMessage call from GIST to
   the QoS NSLP will be different to that seen previously, since the
   interface being used on A has changed.

   At this point, A can attempt to tear down the reservation on the old
   path.  The RESERVE message with the TEAR flag set is sent down the
   old path by using the GIST explicit routing mechanism and specifying
   the SII-Handle relating to the 'old' peer QNE.

Top      Up      ToC       Page 24 
   If RSNs were being incremented for each of these RESERVE and RESERVE-
   with-TEAR messages, the reservation would be torn down at C and any
   QNEs further along the path.  To avoid this, the RSN is used in a
   special way.  The RESERVE down the new path is sent with the new
   current RSN set to the old RSN plus 2.  The RESERVE-with-TEAR down
   the old path is sent with an RSN set to the new current RSN minus 1.
   This is the peer from which it was receiving RESERVE messages (see
   for more details).

3.2.13.  Preemption

   The QoS NSLP provides building blocks to implement preemption.  This
   specification does not define how preemption should work, but only
   provides signaling mechanisms that can be used by QoS models.  For
   example, an INFO-SPEC object can be added to messages to indicate
   that the signaled session was preempted.  A BOUND-SESSION-ID object
   can carry the Session ID of the flow that caused the preemption of
   the signaled session.  How these are used by QoS models is out of
   scope of the QoS NSLP specification.

3.3.  GIST Interactions

   The QoS NSLP uses GIST for delivery of all its messages.  Messages
   are passed from the NSLP to GIST via an API (defined in Appendix B of
   [RFC5971]), which also specifies additional information, including an
   identifier for the signaling application (e.g., 'QoS NSLP'), session
   identifier, MRI, and an indication of the intended direction (towards
   data sender or receiver).  On reception, GIST provides the same
   information to the QoS NSLP.  In addition to the NSLP message data
   itself, other meta-data (e.g., session identifier and MRI) can be
   transferred across this interface.

   The QoS NSLP keeps message and reservation state per session.  A
   session is identified by a Session Identifier (SESSION-ID).  The
   SESSION-ID is the primary index for stored NSLP state and needs to be
   constant and unique (with a sufficiently high probability) along a
   path through the network.  The QoS NSLP picks a value for Session-ID.

   This value is subsequently used by GIST and the QoS NSLP to refer to
   this session.

   Currently, the QoS NSLP specification considers mainly the path-
   coupled MRM.  However, extensions may specify how other types of MRMs
   may be applied in combination with the QoS NSLP.

   When GIST passes the QoS NSLP data to the NSLP for processing, it
   must also indicate the value of the 'D' (Direction) flag for that
   message in the MRI.

Top      Up      ToC       Page 25 
   The QoS NSLP does not provide any method of interacting with
   firewalls or Network Address Translators (NATs).  It assumes that a
   basic NAT traversal service is provided by GIST.

3.3.1.  Support for Bypassing Intermediate Nodes

   The QoS NSLP may want to restrict the handling of its messages to
   specific nodes.  This functionality is needed to support layering
   (explained in Section 3.2.10), when only the edge QNEs of a domain
   process the message.  This requires a mechanism at the GIST level
   (which can be invoked by the QoS NSLP) to bypass intermediate nodes
   between the edges of the domain.

   The intermediate nodes are bypassed using multiple levels of the
   router alert option.  In that case, internal routers are configured
   to handle only certain levels of router alerts.  This is accomplished
   by marking this message at the ingress, i.e., modifying the QoS NSLP
   default NSLPID value to an NSLPID predefined value (see Section 6.6).
   The egress stops this marking process by reassigning the QoS NSLP
   default NSLPID value to the original RESERVE message.  The exact
   operation of modifying the NSLPID must be specified in the relevant
   QoS model specification.

3.3.2.  Support for Peer Change Identification

   There are several circumstances where it is necessary for a QNE to
   identify the adjacent QNE peer, which is the source of a signaling
   application message.  For example, it may be to apply the policy that
   "state can only be modified by messages from the node that created
   it" or it might be that keeping track of peer identity is used as a
   (fallback) mechanism for rerouting detection at the NSLP layer.

   This functionality is implemented in the GIST service interface with
   SII-handle.  As shown in the above example, we assume the SII-
   handling will support both its own SII and its peer's SII.

   Keeping track of the SII of a certain reservation also provides a
   means for the QoS NSLP to detect route changes.  When a QNE receives
   a RESERVE referring to existing state but with a different SII, it
   knows that its upstream peer has changed.  It can then use the old
   SII to initiate a teardown along the old section of the path.  This
   functionality is supported in the GIST service interface when the
   peer's SII (which is stored on message reception) is passed to GIST
   upon message transmission.

Top      Up      ToC       Page 26 
3.3.3.  Support for Stateless Operation

   Stateless or reduced-state QoS NSLP operation makes the most sense
   when some nodes are able to operate in a stateless way at the GIST
   level as well.  Such nodes should not worry about keeping reverse
   state, message fragmentation and reassembly (at GIST), congestion
   control, or security associations.  A stateless or reduced-state QNE
   will be able to inform the underlying GIST of this situation.  GIST
   service interface supports this functionality with the Retain-State
   attribute in the MessageReceived primitive.

3.3.4.  Priority of Signaling Messages

   The QoS NSLP will generate messages with a range of performance
   requirements for GIST.  These requirements may result from a
   prioritization at the QoS NSLP (Section 3.2.11) or from the
   responsiveness expected by certain applications supported by the QoS
   NSLP.  GIST service interface supports this with the 'priority'
   transfer attribute.

3.3.5.  Knowledge of Intermediate QoS-NSLP-Unaware Nodes

   In some cases, it is useful to know that there are routers along the
   path where QoS cannot be provided.  The GIST service interface
   supports this by keeping track of IP-TTL and Original-TTL in the
   RecvMessage primitive.  A difference between the two indicates the
   number of QoS-NSLP-unaware nodes.  In this case, the QNE that detects
   this difference should set the "B" (BREAK) flag.  If a QNE receives a
   QUERY or RESERVE message with the BREAK flag set, and then generates
   a QUERY, RESERVE, or RESPONSE message, it can set the BREAK flag in
   those messages.  There are however, situations where the egress QNE
   in a local domain may have some other means to provide QoS [RFC5975].
   For example, in a local domain that is aware of RMD-QOSM [RFC5977]
   (or a similar QoS Model) and that uses either NTLP stateless nodes or
   NSIS-unaware nodes, the end-to-end RESERVE or QUERY message bypasses
   these NTLP stateless or NSIS-unaware nodes.  However, the reservation
   within the local domain can be signaled by the RMD-QOSM (or a similar
   QoS Model).  In such situations, the "B" (BREAK) flag in the end-to-
   end RESERVE or QUERY message should not be set by the edges of the
   local domain.



(page 26 continued on part 3)

Next RFC Part