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
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.
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. 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.
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.
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
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
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.
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. 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
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
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
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.
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. 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
(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
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. 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.
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.