Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5974

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

Pages: 102
Experimental
Part 3 of 6 – Pages 26 to 41
First   Prev   Next

Top   ToC   RFC5974 - Page 26   prevText

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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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   ToC   RFC5974 - 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 page on part 4)

Next Section