RFC 5974
NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
Pages: 102
Experimental
Experimental
Part 3 of 6 – Pages 26 to 41
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.
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
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.
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.
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.
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
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
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.
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
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.
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
(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.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.
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)