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 3 of 6, p. 26 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 26 
4.  Examples of QoS NSLP Operation

   The QoS NSLP can be used in a number of ways.  The examples here give
   an indication of some of the basic processing.  However, they are not
   exhaustive and do not attempt to cover the details of the protocol
   processing.

Top      Up      ToC       Page 27 
4.1.  Sender-Initiated Reservation

   QNI        QNE        QNE        QNR
    |          |          |          |
    | RESERVE  |          |          |
    +--------->|          |          |
    |          | RESERVE  |          |
    |          +--------->|          |
    |          |          | RESERVE  |
    |          |          +--------->|
    |          |          |          |
    |          |          | RESPONSE |
    |          |          |<---------+
    |          | RESPONSE |          |
    |          |<---------+          |
    | RESPONSE |          |          |
    |<---------+          |          |
    |          |          |          |
    |          |          |          |

               Figure 7: Basic Sender-Initiated Reservation

   To make a new reservation, the QNI constructs a RESERVE message
   containing a QSPEC object, from its chosen QoS model, that describes
   the required QoS parameters.

   The RESERVE message is passed to GIST, which transports it to the
   next QNE.  There, it is delivered to the QoS NSLP processing, which
   examines the message.  Policy control and admission control decisions
   are made.  The exact processing also takes into account the QoS model
   being used.  The node performs appropriate actions (e.g., installing
   the reservation) based on the QSPEC object in the message.

   The QoS NSLP then generates a new RESERVE message (usually based on
   the one received).  This is passed to GIST, which forwards it to the
   next QNE.

   The same processing is performed at further QNEs along the path, up
   to the QNR.  The determination that a node is the QNR may be made
   directly (e.g., that node is the destination for the data flow), or
   using GIST functionality to determine that there are no more QNEs
   between this node and the data flow destination.

   Any node may include a request for a RESPONSE in its RESERVE
   messages.  It does so by including a Request Identification
   Information (RII) object in the RESERVE message.  If the message
   already includes an RII, an interested QNE must not add a new RII
   object or replace the old RII object.  Instead, it needs to remember

Top      Up      ToC       Page 28 
   the RII value so that it can match a RESPONSE message belonging to
   the RESERVE.  When it receives the RESPONSE, it forwards the RESPONSE
   upstream towards the RII originating node.

   In this example, the RESPONSE message is forwarded peer-to-peer along
   the reverse of the path that the RESERVE message took (using GIST
   path state), and so is seen by all the QNEs on this segment of the
   path.  It is only forwarded as far as the node that requested the
   RESPONSE originally.

   The reservation can subsequently be refreshed by sending further
   RESERVE messages containing the complete reservation information, as
   for the initial reservation.  The reservation can also be modified in
   the same way, by changing the QSPEC data to indicate a different set
   of resources to reserve.

   The overhead required to perform refreshes can be reduced, in a
   similar way to that proposed for RSVP in RFC 2961 [RFC2961].  Once a
   RESPONSE message has been received indicating the successful
   installation of a reservation, subsequent refreshing RESERVE messages
   can simply refer to the existing reservation, rather than including
   the complete reservation specification.

4.2.  Sending a Query

   QUERY messages can be used to gather information from QNEs along the
   path.  For example, they can be used to find out what resources are
   available before a reservation is made.

   In order to perform a query along a path, the QNE constructs a QUERY
   message.  This message includes a QSPEC containing the actual query
   to be performed at QNEs along the path.  It also contains an RII
   object used to match the response back to the query, and an indicator
   of the query scope (next node, whole path, proxy).  The QUERY message
   is passed to GIST to forward it along the path.

   A QNE receiving a QUERY message should inspect it and create a new
   message based on it, with the query objects modified as required.
   For example, the query may request information on whether a flow can
   be admitted, and so a node processing the query might record the
   available bandwidth.  The new message is then passed to GIST for
   further forwarding (unless it knows it is the QNR or is the limit for
   the scope in the QUERY).

   At the QNR, a RESPONSE message must be generated if the QUERY message
   includes an RII object.  Various objects from the received QUERY
   message have to be copied into the RESPONSE message.  It is then
   passed to GIST to be forwarded peer-to-peer back along the path.

Top      Up      ToC       Page 29 
   Each QNE receiving the RESPONSE message should inspect the RII object
   to see if it 'belongs' to it (i.e., it was the one that originally
   created it).  If it does not, then it simply passes the message back
   to GIST to be forwarded upstream.

   If there was an error in processing a RESERVE, instead of an RII, the
   RESPONSE may carry an RSN.  Thus, a QNE must also be prepared to look
   for an RSN object if no RII was present, and act based on the error
   code set in the INFO-SPEC of the RESPONSE.

4.3.  Basic Receiver-Initiated Reservation

   As described in the NSIS framework [RFC4080], in some signaling
   applications, a node at one end of the data flow takes responsibility
   for requesting special treatment -- such as a resource reservation --
   from the network.  Both ends then agree whether sender- or receiver-
   initiated reservation is to be done.  In case of a receiver-initiated
   reservation, both ends agree whether a "One Pass With Advertising"
   (OPWA) [opwa95] model is being used.  This negotiation can be
   accomplished using mechanisms that are outside the scope of NSIS.

   To make a receiver-initiated reservation, the QNR constructs a QUERY
   message, which MUST contain a QSPEC object from its chosen QoS model
   (see Figure 8).  The QUERY must have the RESERVE-INIT flag set.  This
   QUERY message does not need to trigger a RESPONSE message and
   therefore, the QNI must not include the RII object (Section 5.4.2) in
   the QUERY message.  The QUERY message may be used to gather
   information along the path, which is carried by the QSPEC object.  An
   example of such information is the "One Pass With Advertising" (OPWA)
   model [opwa95].  This QUERY message causes GIST reverse-path state to
   be installed.

Top      Up      ToC       Page 30 
    QNR        QNE        QNE        QNI
   sender                          receiver
     |          |          |          |
     | QUERY    |          |          |
     +--------->|          |          |
     |          | QUERY    |          |
     |          +--------->|          |
     |          |          | QUERY    |
     |          |          +--------->|
     |          |          |          |
     |          |          | RESERVE  |
     |          |          |<---------+
     |          | RESERVE  |          |
     |          |<---------+          |
     | RESERVE  |          |          |
     |<---------+          |          |
     |          |          |          |
     | RESPONSE |          |          |
     +--------->|          |          |
     |          | RESPONSE |          |
     |          +--------->|          |
     |          |          | RESPONSE |
     |          |          +--------->|
     |          |          |          |

              Figure 8: Basic Receiver-Initiated Reservation

   The QUERY message is transported by GIST to the next downstream QoS
   NSLP node.  There, it is delivered to the QoS NSLP processing, which
   examines the message.  The exact processing also takes into account
   the QoS model being used and may include gathering information on
   path characteristics that may be used to predict the end-to-end QoS.

   The QNE generates a new QUERY message (usually based on the one
   received).  This is passed to GIST, which forwards it to the next
   QNE.  The same processing is performed at further QNEs along the
   path, up to the flow receiver.  The receiver detects that this QUERY
   message carries the RESERVE-INIT flag and by using the information
   contained in the received QUERY message, such as the QSPEC,
   constructs a RESERVE message.

   The RESERVE is forwarded peer-to-peer along the reverse of the path
   that the QUERY message took (using GIST reverse-path state).  Similar
   to the sender-initiated approach, any node may include an RII in its
   RESERVE messages.  The RESPONSE is sent back to confirm that the
   resources are set up.  The reservation can subsequently be refreshed
   with RESERVE messages in the upstream direction.

Top      Up      ToC       Page 31 
4.4.  Bidirectional Reservations

   The term "bidirectional reservation" refers to two different cases
   that are supported by this specification:

   o  Binding two sender-initiated reservations together, e.g., one
      sender-initiated reservation from QNE A to QNE B and another one
      from QNE B to QNE A (Figure 9).

   o  Binding a sender-initiated and a receiver-initiated reservation
      together, e.g., a sender-initiated reservation from QNE A towards
      QNE B, and a receiver-initiated reservation from QNE A towards QNE
      B for the data flow in the opposite direction (from QNE B to QNE
      A).  This case is particularly useful when one end of the
      communication has all required information to set up both sessions
      (Figure 10).

   Both ends have to agree on which bidirectional reservation type they
   need to use.  This negotiation can be accomplished using mechanisms
   that are outside the scope of NSIS.

   The scenario with two sender-initiated reservations is shown in
   Figure 9.  Note that RESERVE messages for both directions may visit
   different QNEs along the path because of asymmetric routing.  Both
   directions of the flows are bound by inserting the BOUND-SESSION-ID
   object at the QNI and QNR.  RESPONSE messages are optional and not
   shown in the picture for simplicity.

      A          QNE        QNE        B
      |          |  FLOW-1  |          |
      |===============================>|
      |RESERVE-1 |          |          |
   QNI+--------->|RESERVE-1 |          |
      |          +-------------------->|QNR
      |          |          |          |
      |          |  FLOW-2  |          |
      |<===============================|
      |          |          |RESERVE-2 |
      |  RESERVE-2          |<---------+QNI
   QNR|<--------------------+          |
      |          |          |          |

      Figure 9: Bidirectional Reservation for Sender+Sender Scenario

Top      Up      ToC       Page 32 
   The scenario with a sender-initiated and a receiver-initiated
   reservation is shown in Figure 10.  In this case, QNI A sends out two
   RESERVE messages, one for the sender-initiated and one for the
   receiver-initiated reservation.  Note that the sequence of the two
   RESERVE messages may be interleaved.

          A          QNE        QNE        B
          |          |  FLOW-1  |          |
          |===============================>|
          |RESERVE-1 |          |          |
       QNI+--------->|RESERVE-1 |          |
          |          +-------------------->|QNR
          |          |          |          |
          |          |  FLOW-2  |          |
          |<===============================|
          |          |          |  QUERY-2 |
          |          |  QUERY-2 |<---------+QNR
       QNI|<--------------------+          |
          |          |          |          |
          |RESERVE-2 |          |          |
       QNI+--------->|RESERVE-2 |          |
          |          +-------------------->|QNR
          |          |          |          |

     Figure 10: Bidirectional Reservation for Sender+Receiver Scenario

Top      Up      ToC       Page 33 
4.5.  Aggregate Reservations

   In order to reduce signaling and per-flow state in the network, the
   reservations for a number of flows may be aggregated.

   QNI        QNE      QNE/QNI'     QNE'    QNR'/QNE      QNR
                     aggregator           deaggregator
    |          |          |          |          |          |
    | RESERVE  |          |          |          |          |
    +--------->|          |          |          |          |
    |          | RESERVE  |          |          |          |
    |          +--------->|          |          |          |
    |          |          | RESERVE  |          |          |
    |          |          +-------------------->|          |
    |          |          | RESERVE' |          |          |
    |          |          +=========>| RESERVE' |          |
    |          |          |          +=========>| RESERVE  |
    |          |          |          |          +--------->|
    |          |          |          | RESPONSE'|          |
    |          |          | RESPONSE'|<=========+          |
    |          |          |<=========+          |          |
    |          |          |          |          | RESPONSE |
    |          |          |          | RESPONSE |<---------+
    |          |          |<--------------------+          |
    |          | RESPONSE |          |          |          |
    |          |<---------+          |          |          |
    | RESPONSE |          |          |          |          |
    |<---------+          |          |          |          |
    |          |          |          |          |          |
    |          |          |          |          |          |

         Figure 11: Sender-Initiated Reservation with Aggregation

   An end-to-end per-flow reservation is initiated with the messages
   shown in Figure 11 as "RESERVE".

   At the aggregator, a reservation for the aggregated flow is initiated
   (shown in Figure 11 as "RESERVE'").  This may use the same QoS model
   as the end-to-end reservation but has an MRI identifying the
   aggregated flow (e.g., tunnel) instead of for the individual flows.

   This document does not specify how the QSPEC of the aggregate session
   can be derived from the QSPECs of the end-to-end sessions.

   The messages used for the signaling of the individual reservation
   need to be marked such that the intermediate routers will not inspect
   them.  In the QoS NSLP, the following marking policy is applied; see
   also RFC 3175.

Top      Up      ToC       Page 34 
   All routers use essentially the same algorithm for which messages
   they process, i.e., all messages at aggregation level 0.  However,
   messages have their aggregation level incremented on entry to an
   aggregation region and decremented on exit.  In this technique, the
   interior routers are not required to do any rewriting of the RAO
   values.  However, the aggregating/deaggregating routers must
   distinguish the interfaces and associated aggregation levels.  These
   routers also perform message rewriting at these boundaries.

   In particular, the Aggregator performs the marking by modifying the
   QoS NSLP default NSLPID value to an NSLPID predefined value; see
   Section 6.6.  A RAO value is then uniquely derivable from each
   predefined NSLPID.  However, the RAO does not have to have a one-to-
   one relation to a specific NSLPID.


             Aggregator                    Deaggregator

                +---+     +---+     +---+     +---+
                |QNI|-----|QNE|-----|QNE|-----|QNR|         aggregate
                +---+     +---+     +---+     +---+         reservation

   +---+     +---+     .....     .....     +---+     +---+
   |QNI|-----|QNE|-----.   .-----.   .-----|QNE|-----|QNR|  end-to-end
   +---+     +---+     .....     .....     +---+     +---+  reservation

                    Figure 12: Reservation Aggregation

   The deaggregator acts as the QNR for the aggregate reservation.
   Session binding information carried in the RESERVE message enables
   the deaggregator to associate the end-to-end and aggregate
   reservations with one another (using the BOUND-SESSION-ID).

   The key difference between this example and the one shown in
   Section 4.7.1 is that the flow identifier for the aggregate is
   expected to be different to that for the end-to-end reservation.  The
   aggregate reservation can be updated independently of the per-flow
   end-to-end reservations.

4.6.  Message Binding

   Section 4.5 sketches the interaction of an aggregated end-to-end flow
   and an aggregate.  For this scenario, and probably others, it is
   useful to have a method for synchronizing the exchanges of signaling
   messages of different sessions.  This can be used to speed up
   signaling, because some message exchanges can be started
   simultaneously and can be processed in parallel until further
   processing of a message from one particular session depends on

Top      Up      ToC       Page 35 
   another message from a different session.  For instance, Figure 11
   shows a case where inclusion of a new reservation requires that the
   capacity of the encompassing aggregate be increased first.  So the
   RESERVE (bound message) for the individual flow arriving at the
   deaggregator should wait until the RESERVE' (binding message) for the
   aggregate arrived successfully (otherwise, the individual flow cannot
   be included in the existing aggregate and cannot be admitted).
   Another alternative would be to increase the aggregate first and then
   to reserve resources for a set of aggregated individual flows.  In
   this case, the binding and synchronization between the (RESERVE and
   RESERVE') messages are not needed.

   A message binding may be used (depending an the aggregators policy)
   as follows: a QNE (aggregator QNI' in Figure 14) generates randomly a
   128-bit MSG-ID (same rules apply as for generating a SESSION-ID) and
   includes it as BOUND-MSG-ID object into the bound signaling message
   (RESERVE (1) in Figure 13) that should wait for the arrival of a
   related binding signaling message (RESERVE' (3) in Figure 13) that
   carries the associated MSG-ID object.  The BOUND-SESSION-ID should
   also be set accordingly.  Only one MSG-ID or BOUND-MSG-ID object per
   message is allowed.  If the dependency relation between the two
   messages is bidirectional, then the Message_Binding_Type flag is SET
   (value is 1).  Otherwise, the Message_Binding_Type flag is UNSET.  In
   most cases, an RII object must be included in order to get a
   corresponding RESPONSE back.

   Depending on the arrival sequence of the bound signaling message
   (RESERVE (1) in Figure 13) and the "triggering" binding signaling
   message (RESERVE' (3) in Figure 13), different situations can be
   identified:

   o  The bound signaling (RESERVE (1)) arrives first.  The receiving
      QNE enqueues (probably after some pre-processing) the signaling
      (RESERVE (1)) message for the corresponding session.  It also
      starts a MsgIDWait timer in order to discard the message in case
      the related "triggering" message (RESERVE' in Figure 13) does not
      arrive.  The timeout period for this time SHOULD be set to the
      default retransmission timeout period (QOSNSLP_REQUEST_RETRY).  In
      case a retransmitted RESERVE message arrives before the timeout,
      it will simply override the waiting message (i.e., the latter is
      discarded, and the new message is now waiting with the MsgIDWait
      timer being reset).

   At the same time, the "triggering" message including a MSG-ID object,
   carrying the same value as the BOUND-MSG-ID object is sent by the
   same initiating QNE (QNI' in Figure 13).  The intermediate QNE' sees
   the MSG-ID object, but can determine that it is not the endpoint for
   the session (QNR') and therefore simply forwards the message after

Top      Up      ToC       Page 36 
   normal processing.  The receiving QNE (QNR') as endpoint for the
   aggregate session (i.e., deaggregator) interprets the MSG-ID object
   and looks for a corresponding waiting message with a BOUND-MSG-ID of
   the same value whose waiting condition is satisfied now.  Depending
   on successful processing of the RESERVE' (3), processing of the
   waiting RESERVE will be resumed, and the MsgIDWait timer will be
   stopped as soon as the related RESERVE' arrived.

      QNI        QNE      QNE/QNI'     QNE'    QNR'/QNE      QNR
                        aggregator           deaggregator
       |          |          |          |          |          |
       | RESERVE  |          |          |          |          |
       +--------->|          |          |          |          |
       |          | RESERVE  |          |          |          |
       |          +--------->|          |          |          |
       |          |          | RESERVE  |          |          |
       |          |          |   (1)    |          |          |
       |          |          +-------------------->|          |
       |          |          | RESERVE' |          |          |
       |          |          |   (2)    |          |          |
       |          |          +=========>| RESERVE' |          |
       |          |          |          |   (3)    |          |
       |          |          |          +=========>| RESERVE  |
       |          |          |          |          |   (4)    |
       |          |          |          |          +--------->|
       |          |          |          | RESPONSE'|          |
       |          |          | RESPONSE'|<=========+          |
       |          |          |<=========+          |          |
       |          |          |          |          | RESPONSE |
       |          |          |          | RESPONSE |<---------+
       |          |          |<--------------------+          |
       |          | RESPONSE |          |          |          |
       |          |<---------+          |          |          |
       | RESPONSE |          |          |          |          |
       |<---------+          |          |          |          |
       |          |          |          |          |          |
       |          |          |          |          |          |


   (1):     RESERVE:  SESSION-ID=F, BOUND-MSG-ID=x, BOUND-SESSION-ID=A
   (2)+(3): RESERVE': SESSION-ID=A, MSG-ID=x
   (4):     RESERVE:  SESSION-ID=F  (MSG-ID object was removed)

               Figure 13: Example for Using Message Binding

Top      Up      ToC       Page 37 
   Several further cases have to be considered in this context:

   o  "Triggering message" (3) arrives before waiting (bound) message
      (1): In this case, the processing of the triggering message
      depends on the value of the Message_Binding_Type flag.  If
      Message_Binding_Type is UNSET (value is 0), then the triggering
      message can be processed normally, but the MSG-ID and the result
      (success or failure) should be saved for the waiting message.
      Thus, the RESPONSE' can be sent by the QNR' immediately.  If the
      waiting message (1) finally arrives at the QNR', it can be
      detected that the waiting condition was already satisfied because
      the triggering message already arrived earlier.  If
      Message_Binding_Type is SET (value is 1), then the triggering
      message interprets the MSG-ID object and looks for the
      corresponding waiting message with a BOUND-MSG-ID of the same
      value, which in this case has not yet arrived.  It then starts a
      MsgIDWait timer in order to discard the message in case the
      related message (RESERVE (1) in Figure 14) does not arrive.
      Depending on successful processing of the RESERVE (1), processing
      of the waiting RESERVE' will be resumed, the MsgIDWait timer will
      be stopped as soon as the related RESERVE arrives and the
      RESPONSE' can be sent by the QNR' towards the QNI'.

   o  The "triggering message" (3) does not arrive at all: this may be
      due to message loss (which will cause a retransmission by the QNI'
      if the RII object is included) or due to a reservation failure at
      an intermediate node (QNE' in the example).  The MsgIDWait timeout
      will then simply discard the waiting message at QNR'.  In this
      case, the QNR' MAY send a RESPONSE message towards the QNI
      informing it that the synchronization of the two messages has
      failed.

   o  Retransmissions should use the same MSG-ID because usually only
      one of the two related messages is retransmitted.  As mentioned
      above: retransmissions will only occur if the RII object is set in
      the RESERVE.  If a retransmitted message with a MSG-ID arrives
      while a bound message with the same MSG-ID is still waiting, the
      retransmitted message will replace the bound message.

   For a receiving node, there are conceptually two lists indexed by
   message IDs.  One list contains the IDs and results of triggering
   messages (those carrying a MSG-ID object), the other list contains
   the IDs and message contents of the bound waiting messages (those who
   carried a BOUND-MSG-ID).  The former list is used when a triggering
   message arrives before the bound message.  The latter list is used
   when a bound message arrives before a triggering message.

Top      Up      ToC       Page 38 
4.7.  Reduced-State or Stateless Interior Nodes

   This example uses a different QoS model within a domain, in
   conjunction with GIST and NSLP functionality that allows the interior
   nodes to avoid storing GIST and QoS NSLP state.  As a result, the
   interior nodes only store the QSPEC-related reservation state or even
   no state at all.  This allows the QoS model to use a form of
   "reduced-state" operation, where reservation states with a coarser
   granularity (e.g., per-class) are used, or a "stateless" operation
   where no QoS NSLP state is needed (or created).  This is useful,
   e.g., for measurement-based admission control schemes.

   The key difference between this example and the use of different QoS
   models in Section 4.5 is the transport characteristics for the
   reservation, i.e., GIST can be used in a different way for the edge-
   to-edge and hop-by-hop sessions.  The reduced-state reservation can
   be updated independently of the per-flow end-to-end reservations.

4.7.1.  Sender-Initiated Reservation

   The QNI initiates a RESERVE message (see Figure 14).  At the QNEs on
   the edges of the stateless or reduced-state region, the processing is
   different and the nodes support two QoS models.  At the ingress, the
   original RESERVE message is forwarded but ignored by the stateless or
   reduced-state nodes.  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 4.6).  The egress must reassign
   the QoS NSLP default NSLPID value to the original end-to-end RESERVE
   message.  An example of such operation is given in [RFC5977].

   The egress node is the next QoS-NSLP hop for the end-to-end RESERVE
   message.  Reliable GIST transfer mode can be used between the ingress
   and egress without requiring GIST state in the interior.  At the
   egress node, the RESERVE message is then forwarded normally.

   At the ingress, a second RESERVE' message is also built (Figure 14).
   This makes use of a QoS model suitable for a reduced-state or
   stateless form of operation (such as the RMD per-hop reservation).
   Since the original RESERVE and the RESERVE' messages are addressed
   identically, the RESERVE' message also arrives at the same egress QNE
   that was also traversed by the RESERVE message.  Message binding is
   used to synchronize the messages.

   When processed by interior (stateless) nodes, the QoS NSLP processing
   exercises its options to not keep state wherever possible, so that no
   per-flow QoS NSLP state is stored.  Some state, e.g., per class, for
   the QSPEC-related data may be held at these interior nodes.  The QoS
   NSLP also requests that GIST use different transport characteristics

Top      Up      ToC       Page 39 
   (e.g., sending of messages in unreliable GIST transfer mode).  It
   also requests the local GIST processing not to retain messaging
   association state or reverse message routing state.

   Nodes, such as those in the interior of the stateless or reduced-
   state domain, that do not retain reservation state cannot send back
   RESPONSE messages (and so cannot use the refresh reduction
   extension).

   At the egress node, the RESERVE' message is interpreted in
   conjunction with the reservation state from the end-to-end RESERVE
   message (using information carried in the message to correlate the
   signaling flows).  The RESERVE message is only forwarded further if
   the processing of the RESERVE' message was successful at all nodes in
   the local domain; otherwise, the end-to-end reservation is regarded
   as having failed to be installed.  This can be realized by using the
   message binding functionality described in Section 4.6 to synchronize
   the arrival of the bound signaling message (end-to-end RESERVE) and
   the binding signaling message (local RESERVE').

           QNE             QNE             QNE            QNE
         ingress         interior        interior        egress
     GIST stateful  GIST stateless  GIST stateless  GIST stateful
            |               A               B              |
    RESERVE |               |               |              |
   -------->| RESERVE       |               |              |
            +--------------------------------------------->|
            | RESERVE'      |               |              |
            +-------------->|               |              |
            |               | RESERVE'      |              |
            |               +-------------->|              |
            |               |               | RESERVE'     |
            |               |               +------------->|
            |               |               |  RESPONSE'   |
            |<---------------------------------------------+
            |               |               |              | RESERVE
            |               |               |              +-------->
            |               |               |              | RESPONSE
            |               |               |              |<--------
            |               |               |     RESPONSE |
            |<---------------------------------------------+
    RESPONSE|               |               |              |
   <--------|               |               |              |

    Figure 14: Sender-Initiated Reservation with Reduced-State Interior
                                   Nodes

Top      Up      ToC       Page 40 
   Resource management errors in the example above are reflected in the
   QSPEC and QoS model processing.  For example, if the RESERVE' fails
   at QNE A, it cannot send an error message back to the ingress QNE.
   Thus, the RESERVE' is forwarded along the intended path, but the
   QSPEC includes information for subsequent QNEs telling them an error
   happened upstream.  It is up to the QoS model to determine what to
   do.  Eventually, the RESERVE' will reach the egress QNE, and again,
   the QoS model then determines the response.

4.7.2.  Receiver-Initiated Reservation

   Since NSLP neighbor relationships are not maintained in the reduced-
   state region, only sender-initiated signaling can be supported within
   the reduced-state region.  If a receiver-initiated reservation over a
   stateless or reduced-state domain is required, this can be
   implemented as shown in Figure 15.

           QNE            QNE            QNE
         ingress        interior        egress
     GIST stateful  GIST stateless  GIST stateful
            |               |               |
    QUERY   |               |               |
   -------->| QUERY         |               |
            +------------------------------>|
            |               |               | QUERY
            |               |               +-------->
            |               |               | RESERVE
            |               |               |<--------
            |               |      RESERVE  |
            |<------------------------------+
            | RESERVE'      | RESERVE'      |
            |-------------->|-------------->|
            |               |     RESPONSE' |
            |<------------------------------+
    RESERVE |               |               |
   <--------|               |               |

   Figure 15: Receiver-Initiated Reservation with Reduced-State Interior
                                   Nodes

   The RESERVE message that is received by the egress QNE of the
   stateless domain is sent transparently to the ingress QNE (known as
   the source of the QUERY message).  When the RESERVE message reaches
   the ingress, the ingress QNE needs to send a sender-initiated
   RESERVE' over the stateless domain.  The ingress QNE needs to wait
   for a RESPONSE'.  If the RESPONSE' notifies that the reservation was
   accomplished successfully, then the ingress QNE sends a RESERVE
   message further upstream.

Top      Up      ToC       Page 41 
4.8.  Proxy Mode

   Besides the sender- and receiver-initiated reservations, the QoS NSLP
   includes a functionality we refer to as Proxy Mode.  Here a QNE is
   set by administrator assignment to work as a proxy QNE (P-QNE) for a
   certain region, e.g., for an administrative domain.  A node
   initiating the signaling may set the PROXY scope flag to indicate
   that the signaling is meant to be confined within the area controlled
   by the proxy, e.g., the local access network.

   The Proxy Mode has two uses.  First, it allows the QoS NSLP signaling
   to be confined to a pre-defined section of the path.  Second, it
   allows a node to make reservations for an incoming data flow.

   For outgoing data flows and sender-initiated reservations, the end
   host is the QNI, and sends a RESERVE with the PROXY scope flag set.
   The P-QNE is the QNR; it will receive the RESERVE, notice the PROXY
   scope flag is set and reply with a RESPONSE (if requested).  This
   operation is the same as illustrated in Figure 7.  The receiver-
   oriented reservation for outgoing flows works the same way as in
   Figure 8, except that the P-QNE is the QNI.

   For incoming data flows, the end host is the QNI, and it sends a
   RESERVE towards the data sender with the PROXY scope flag set.  Here
   the end host sets the MRI so that it indicates the end host as the
   receiver of the data, and sets the D-flag.

   GIST is able to send messages towards the data sender if there is
   existing message routing state or it is able to use the Upstream
   Q-mode Encapsulation.  In some cases, GIST will be unable to
   determine the appropriate next hop for the message, and so will
   indicate a failure to deliver it (by sending an error message).  This
   may occur, for example, if GIST attempts to determine an upstream
   next hop and there are multiple possible inbound routes that could be
   used.

   Bidirectional reservations can be used, as discussed in Section 4.4.
   The P-QNE will be the QNR or QNI for reservations.

   If the PROXY scope flag is set in an incoming QoS NSLP message, the
   QNE must set the same flag in all QoS NSLP messages it sends that are
   related to this session.


Next RFC Part