4.6.2. Bidirectional Operation This section describes the basic bidirectional operation and sequence of events/triggers of the RMD-QOSM. The following basic operation cases are distinguished: * Successful and unsuccessful reservation (Section 4.6.2.1); * Refresh reservation (Section 4.6.2.2); * Modification of aggregated reservation (Section 4.6.2.3); * Release procedure (Section 4.6.2.4); * Severe congestion handling (Section 4.6.2.5); * Admission control using congestion notification based on probing (Section 4.6.2.6). It is important to emphasize that the content of this section is used for the specification of the following RMD-QOSM/QoS-NSLP signaling schemes, when basic unidirectional operation is assumed: * "per-flow congestion notification based on probing";
* "per-flow RMD NSIS measurement-based admission control",
* "per-flow RMD reservation-based" in combination with the "severe
congestion handling by the RMD-QOSM refresh" procedure;
* "per-flow RMD reservation-based" in combination with the "severe
congestion handling by proportional data packet marking"
procedure;
* "per-aggregate RMD reservation-based" in combination with the
"severe congestion handling by the RMD-QOSM refresh" procedure;
* "per-aggregate RMD reservation-based" in combination with the
"severe congestion handling by proportional data packet marking"
procedure.
For more details, please see Section 3.2.3.
In particular, the functionality described in Sections 4.6.2.1,
4.6.2.2, 4.6.2.3, 4.6.2.4, and 4.6.2.5 applies to the RMD
reservation-based and NSIS measurement-based admission control
methods. The described functionality in Section 4.6.2.6 applies to
the admission control procedure that uses the congestion notification
based on probing. The QNE Edge nodes maintain either per-flow QoS-
NSLP operational and reservation states or aggregated QoS-NSLP
operational and reservation states.
RMD-QOSM assumes that asymmetric routing MAY be applied in the RMD
domain. Combined sender-receiver initiated reservation cannot be
efficiently done in the RMD domain because upstream NTLP states are
not stored in Interior routers.
Therefore, the bidirectional operation SHOULD be performed by two
sender-initiated reservations (sender&sender). We assume that the
QNE Edge nodes are common for both upstream and downstream
directions, therefore, the two reservations/sessions can be bound at
the QNE Edge nodes. Note that if this is not the case, then the
bidirectional procedure could be managed and maintained by nodes
located outside the RMD domain, by using other procedures than the
ones defined in RMD-QOSM.
This (intra-domain) bidirectional sender&sender procedure can then be
applied between the QNE Edge (QNE Ingress and QNE Egress) nodes of
the RMD QoS signaling model. In the situation in which a security
association exists between the QNE Ingress and QNE Egress nodes (see
Figure 15), and the QNE Ingress node has the REQUIRED <Peak Data
Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters for
both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress
towards QNE Ingress, then the QNE Ingress MAY include both <Peak Data Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters (needed for both directions) into the RMD-QSPEC within a RESERVE message. In this way, the QNE Egress node is able to use the QoS parameters needed for the "Egress towards Ingress" direction (QoS-2). The QNE Egress is then able to create a RESERVE with the right QoS parameters included in the QSPEC, i.e., RESERVE (QoS-2). Both directions of the flows are bound by inserting <BOUND-SESSION-ID> objects at the QNE Ingress and QNE Egress, which will be carried by bound end-to-end RESERVE messages. |------ RESERVE (QoS-1, QoS-2)----| | V | Interior/stateless QNEs +---+ +---+ |------->|QNE|-----|QNE|------ | +---+ +---+ | | V +---+ +---+ |QNE| |QNE| +---+ +---+ ^ | | | +---+ +---+ V | |-------|QNE|-----|QNE|-----| | +---+ +---+ Ingress/ Egress/ stateful QNE stateful QNE | <--------- RESERVE (QoS-2) -------| Figure 16: The intra-domain bidirectional reservation scenario in the RMD domain Note that it is RECOMMENDED that the QNE implementations of RMD-QOSM process the QoS-NSLP signaling messages with a higher priority than data packets. This can be accomplished as described in Section 3.3.4 in [RFC5974] and the QoS-NSLP-RMF API [RFC5974]. A bidirectional reservation, within the RMD domain, is indicated by the PHR <B> and PDR <B> flags, which are set in all messages. In this case, two <BOUND-SESSION-ID> objects SHOULD be used. When the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states, the end-to-end RESERVE message carries two BOUND- SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the tunneled intra-domain (per-flow) session that is using a Binding_Code with value set to code (Tunneled and end-to-end sessions). Another
BOUND-SESSION-ID carries the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND- SESSION-ID is set to code (Bidirectional sessions). When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states, the end-to-end RESERVE message carries two BOUND- SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the tunneled aggregated intra-domain session that is using a Binding_Code with value set to code (Aggregated sessions). Another BOUND-SESSION- ID carries the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions). The intra-domain and end-to-end QoS-NSLP operational states are initiated/modified depending on the binding type (see Sections 4.3.1, 4.3.2, and 4.3.3). If no security association exists between the QNE Ingress and QNE Egress nodes, the bidirectional reservation for the sender&sender scenario in the RMD domain SHOULD use the scenario specified in [RFC5974] as "bidirectional reservation for sender&sender scenario". This is because in this scenario, the RESERVE message sent from the QNE Ingress to QNE Egress does not have to carry the QoS parameters needed for the "Egress towards Ingress" direction (QoS-2). In the following sections, it is considered that the QNE Edge nodes are common for both upstream and downstream directions and therefore, the two reservations/sessions can be bound at the QNE Edge nodes. Furthermore, it is considered that a security association exists between the QNE Ingress and QNE Egress nodes, and the QNE Ingress node has the REQUIRED <Peak Data Rate-1 (p)> value of the local RMD- QSPEC <TMOD-1> parameters for both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress towards QNE Ingress. According to Section 3.2.3, it is specified that only the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme MUST be implemented within one RMD domain. However, all RMD QNEs supporting this specification MUST support the combination the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme. If the RMD QNEs support more RMD-QOSM schemes, then the operator of that RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR Container" (Section 4.1.2) and the "PDR Container" (Section 4.1.3) will always use the same value, such that within one RMD domain, only one of the below described RMD-QOSM schemes is used at a time.
All QNE nodes located within the RMD domain MUST read and interpret the <SCH> field included in the "PHR Container" before processing all the other <PHR Container> payload fields. Moreover, all QNE Edge nodes located at the boarder of the RMD domain, MUST read and interpret the <SCH> field included in the "PDR container" before processing all the other <PDR Container> payload fields. 4.6.2.1. Successful and Unsuccessful Reservations This section describes the operation of the RMD-QOSM where an RMD Intra-domain bidirectional reservation operation, see Figure 16 and Section 4.6.2, is either successfully or unsuccessfully accomplished. The bidirectional successful reservation is similar to a combination of two unidirectional successful reservations that are accomplished in opposite directions, see Figure 17. The main differences of the bidirectional successful reservation procedure with the combination of two unidirectional successful reservations accomplished in opposite directions are as follows. Note also that the intra-domain and end-to-end QoS-NSLP operational states generated and maintained by the end-to-end RESERVE messages contain, compared to the unidirectional reservation scenario, a different BOUND-SESSION-ID data structure (see Sections 4.3.1, 4.3.2, and 4.3.3). In this scenario, the intra-domain RESERVE message sent by the QNE Ingress node towards the QNE Egress node is denoted in Figure 17 as RESERVE (RMD-QSPEC): "forward". The main differences between the intra- domain RESERVE (RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure and a RESERVE (RMD- QSPEC) message used for the unidirectional successful reservation are as follows (see the QoS-NSLP-RMF API described in [RFC5974]): * the <RII> object MUST NOT be included in the message. This is because no RESPONSE message is REQUIRED. * the <B> bit of the PHR container indicates a bidirectional reservation and it MUST be set to "1". * the PDR container is also included in the RESERVE(RMD-QSPEC): "forward" message. The value of the Parameter ID is "20", i.e., "PDR_Reservation_Request". Note that the response PDR container sent by a QNE Egress to a QNE Ingress node is not carried by an end-to-end RESPONSE message, but it is carried by an intra-domain RESERVE message that is sent by the QNE Egress node towards the QNE Ingress node (denoted in Figure 16 as RESERVE(RMD-QSPEC): "reverse"). * the <B> PDR bit indicates a bidirectional reservation and is set to "1".
* the <PDR Bandwidth> field specifies the requested bandwidth that
has to be used by the QNE Egress node to initiate another intra-
domain RESERVE message in the reverse direction.
The RESERVE(RMD-QSPEC): "reverse" message is initiated by the QNE
Egress node at the moment that the RESERVE(RMD-QSPEC): "forward"
message is successfully processed by the QNE Egress node.
The main differences between the RESERVE(RMD-QSPEC): "reverse"
message used for the bidirectional successful reservation procedure
and a RESERVE(RMD-QSPEC) message used for the unidirectional
successful reservation are as follows:
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | | | |
| | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | | |
| |------------------------------>| |
| | | |------------->|
| | | | |
| | |RESERVE(RMD-QSPEC) |
| RESERVE(RMD-QSPEC) | "reverse" |<-------------|
| "reverse" | |<--------------| |
|<-------------------------------| | |
Figure 17: Intra-domain signaling operation for successful
bidirectional reservation
* the <RII> object is not included in the message. This is because
no RESPONSE message is REQUIRED;
* the value of the <Peak Data Rate-1 (p)> field of the local RMD-
QSPEC <TMOD-1> parameter is set equal to the value of the <PDR
Bandwidth> field included in the RESERVE(RMD-QSPEC): "forward"
message that triggered the generation of this RESERVE(RMD-QSPEC):
"reverse" message;
* the <B> bit of the PHR container indicates a bidirectional
reservation and is set to "1";
* the PDR container is included into the RESERVE(RMD-QSPEC):
"reverse" message. The value of the Parameter ID is "23", i.e.,
"PDR_Reservation_Report";
* the <B> PDR bit indicates a bidirectional reservation and is set
to "1".
Figures 18 and 19 show the flow diagrams used in the case of an
unsuccessful bidirectional reservation. In Figure 18, the QNE that
is not able to support the requested <Peak Data Rate-1 (p)> value of
local RMD-QSPEC <TMOD-1> is located in the direction QNE Ingress
towards QNE Egress. In Figure 19, the QNE that is not able to
support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC
<TMOD-1> is located in the direction QNE Egress towards QNE Ingress.
The main differences between the bidirectional unsuccessful procedure
shown in Figure 18 and the bidirectional successful procedure are as
follows:
* the QNE node that is not able to reserve resources for a certain
request is located in the "forward" path, i.e., the path from the
QNE Ingress towards the QNE Egress.
* the QNE node that is not able to support the requested <Peak Data
Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M>
bit, i.e., set to value "1", of the RESERVE(RMD-QSPEC): "forward".
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC): | | |
| "forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | M RESERVE(RMD-QSPEC):
| |--------------------------->M "forward-M marked"
| | | M-------------->|
| | RESPONSE(PDR) M |
| | "forward - M marked"M |
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC, K=0) | M |
|"forward - T tear" | M |
|--------------->| | M |
| RESERVE(RMD-QSPEC, K=1) M |
| | "forward - T tear" M |
| |--------------------------->M |
| | RESERVE(RMD-QSPEC, K=1) |
| | "forward - T tear" |
| | M-------------->|
Figure 18: Intra-domain signaling operation for unsuccessful
bidirectional reservation (rejection on path
QNE(Ingress) towards QNE(Egress))
The operation for this type of unsuccessful bidirectional reservation is similar to the operation for unsuccessful unidirectional reservation, shown in Figure 9. The main differences between the bidirectional unsuccessful procedure shown in Figure 19 and the in bidirectional successful procedure are as follows: * the QNE node that is not able to reserve resources for a certain request is located in the "reverse" path, i.e., the path from the QNE Egress towards the QNE Ingress. * the QNE node that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M> bit, i.e., set to value "1", the RESERVE(RMD-QSPEC): "reverse".
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress) NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful | | | | | |RESERVE(RMD-QSPEC) | | | |"forward" | RESERVE(RMD-QSPEC): | | |--------------->| "forward" | RESERVE(RMD-QSPEC): | | |-------------------------------->|"forward" | | | RESERVE(RMD-QSPEC): |------------->| | | "reverse" | | | | | RESERVE(RMD-QSPEC) | | | RESERVE(RMD-QSPEC): M "reverse" |<-------------| | "reverse - M marked" M<---------------| | |<--------------------------------M | | | | M | | |RESERVE(RMD-QSPEC, K=0): M | | |"forward - T tear" M | | |--------------->| RESERVE(RMD-QSPEC, K=0): | | | | "forward - T tear" | | | |-------------------------------->| | | | M |------------->| | | M RESERVE(RMD-QSPEC, K=0): | | M "reverse - T tear" | | | M |<-------------| | M RESERVE(RMD-QSPEC, K=1) | | | M "forward - T tear" | | | M<---------------| | | RESERVE(RMD-QSPEC, K=1)M | | | "forward - T tear" M | | |<--------------------------------M | | Figure 19: Intra-domain signaling normal operation for unsuccessful bidirectional reservation (rejection on path QNE(Egress) towards QNE(Ingress) * the QNE Ingress uses the information contained in the received PHR and PDR containers of the RESERVE(RMD-QSPEC): "reverse" and generates a tear intra-domain RESERVE(RMD-QSPEC): "forward - T tear" message. This message carries a "PHR_Release_Request" and "PDR_Release_Request" control information. This message is sent to the QNE Egress node. The QNE Egress node uses the information contained in the "PHR_Release_Request" and the "PDR_Release_Request" control info containers to generate a RESERVE(RMD-QSPEC): "reverse - T tear" message that is sent towards the QNE Ingress node.
4.6.2.2. Refresh Reservations This section describes the operation of the RMD-QOSM where an RMD intra-domain bidirectional refresh reservation operation is accomplished. The refresh procedure in the case of an RMD reservation-based method follows a scheme similar to the successful reservation procedure, described in Section 4.6.2.1 and depicted in Figure 17, and how the refresh process of the reserved resources is maintained and is similar to the refresh process used for the intra-domain unidirectional reservations (see Section 4.6.1.3). Note that the RMD traffic class refresh periods used by the bound bidirectional sessions MUST be equal in all QNE Edge and QNE Interior nodes. The main differences between the RESERVE(RMD-QSPEC): "forward" message used for the bidirectional refresh procedure and a RESERVE(RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure are as follows: * the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update". * the value of the Parameter ID of the PDR container is "21", i.e., "PDR_Refresh_Request". The main differences between the RESERVE(RMD-QSPEC): "reverse" message used for the bidirectional refresh procedure and the RESERVE (RMD-QSPEC): "reverse" message used for the bidirectional successful reservation procedure are as follows: * the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update". * the value of the Parameter ID of the PDR container is "24", i.e., "PDR_Refresh_Report". 4.6.2.3. Modification of Aggregated Intra-Domain QoS-NSLP Operational Reservation States This section describes the operation of the RMD-QOSM where RMD intra- domain bidirectional QoS-NSLP aggregated reservation states have to be modified.
In the case when the QNE Edges maintain, for the RMD QoS Model, QoS- NSLP aggregated reservation states and if such an aggregated reservation has to be modified (see Section 4.3.1), then similar procedures to Section 4.6.1.4 are applied. In particular: * When the modification request requires an increase of the reserved resources, the QNE Ingress node MUST include the corresponding value into the <Peak Data Rate-1 (p)> field local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>), which is sent together with "PHR_Resource_Request" control information. If a QNE Edge or QNE Interior node is not able to reserve the number of requested resources, then the "PHR_Resource_Request" associated with the local RMD-QSPEC <TMOD-1> parameter MUST be marked. In this situation, the RMD-specific operation for unsuccessful reservation will be applied (see Section 4.6.2.1). Note that the value of the <PDR Bandwidth> parameter, which is sent within a "PDR_Reservation_Request" container, represents the increase of the reserved resources in the "reverse" direction. * When the modification request requires a decrease of the reserved resources, the QNE Ingress node MUST include this value into the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>). Subsequently, an RMD release procedure SHOULD be accomplished (see Section 4.6.2.4). Note that the value of the <PDR Bandwidth> parameter, which is sent within a "PDR_Release_Request" container, represents the decrease of the reserved resources in the "reverse" direction. 4.6.2.4. Release Procedure This section describes the operation of the RMD-QOSM, where an RMD intra-domain bidirectional reservation release operation is accomplished. The message sequence diagram used in this procedure is similar to the one used by the successful reservation procedures, described in Section 4.6.2.1 and depicted in Figure 17. However, how the release of the reservation is accomplished is similar to the RMD release procedure used for the intra-domain unidirectional reservations (see Section 4.6.1.5 and Figures 18 and 19). The main differences between the RESERVE (RMD-QSPEC): "forward" message used for the bidirectional release procedure and a RESERVE (RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure are as follows: * the value of the Parameter ID of the PHR container is "18", i.e."PHR_Release_Request";
* the value of the Parameter ID of the PDR container is "22", i.e.,
"PDR_Release_Request";
The main differences between the RESERVE (RMD-QSPEC): "reverse"
message used for the bidirectional release procedure and the RESERVE
(RMD-QSPEC): "reverse" message used for the bidirectional successful
reservation procedure are as follows:
* the value of the Parameter ID of the PHR container is "18", i.e.,
"PHR_Release_Request";
* the PDR container is not included in the RESERVE (RMD-QSPEC):
"reverse" message.
4.6.2.5. Severe Congestion Handling
This section describes the severe congestion handling operation used
in combination with RMD intra-domain bidirectional reservation
procedures. This severe congestion handling operation is similar to
the one described in Section 4.6.1.6.
4.6.2.5.1. Severe Congestion Handling by the RMD-QOSM Bidirectional
Refresh Procedure
This procedure is similar to the severe congestion handling procedure
described in Section 4.6.1.6.1. The difference is related to how the
refresh procedure is accomplished (see Section 4.6.2.2) and how the
flows are terminated (see Section 4.6.2.4).
4.6.2.5.2. Severe Congestion Handling by Proportional Data Packet
Marking
This section describes the severe congestion handling by proportional
data packet marking when this is combined with an RMD intra-domain
bidirectional reservation procedure. Note that the detection and
marking/re-marking functionality described in this section and used
by Interior nodes, applies to NSIS-aware but also to NSIS-unaware
nodes. This means however, that the "not NSIS-aware" Interior nodes
MUST be configured such that they can detect the congestion
situations and re-mark packets in the same way as the Interior "NSIS-
aware" nodes do.
This procedure is similar to the severe congestion handling procedure
described in Section 4.6.1.6.2. The main difference is related to
the location of the severe congested node, i.e., "forward" or
"reverse" path. Note that when a severe congestion situation occurs,
e.g., on a forward path, and flows are terminated to solve the severe
congestion in forward path, then the reserved bandwidth associated
with the terminated bidirectional flows will also be released. Therefore, a careful selection of the flows that have to be terminated SHOULD take place. An example of such a selection is given in Appendix A.5. Furthermore, a special case of this operation is associated with the severe congestion situation occurring simultaneously on the forward and reverse paths. An example of this operation is given in Appendix A.6. Simulation results associated with these procedures can be found in [DiKa08]. QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress) NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful user| | | | | data| user | | | | --->| data | user data | |user data | |--------------->| | S | | |--------------------------->S (#marked bytes) | | | S-------------->| | | | S(#unmarked bytes) | | | S-------------->|Term | | | S |flow? | | NOTIFY (PDR) S |YES |<------------------------------------------------------------| |RESERVE(RMD-QSPEC) | S | |"forward - T tear" | S | |--------------->| | RESERVE(RMD-QSPEC):| | |--------------------------->S"forward - T tear" | | | S-------------->| | | | RESERVE(RMD-QSPEC): | | | | "reverse - T tear" | | RESERVE(RMD-QSPEC): | |<--------------| |"reverse - T tear" |<-------------S | |<-----------------------------| S | Figure 20: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion on path QNE(Ingress) towards QNE(Egress)) Figure 20 shows the scenario in which the severely congested node is located in the "forward" path. The QNE Egress node has to generate an end-to-end NOTIFY (PDR) message. In this way, the QNE Ingress will be able to receive the (#marked and #unmarked) that were measured by the QNE Egress node on the congested "forward" path. Note that in this situation, it is assumed that the "reverse" path is not congested.
This scenario is very similar to the severe congestion handling scenario described in Section 4.6.1.6.2 and shown in Figure 14. The difference is related to the release procedure, which is accomplished in the same way as described in Section 4.6.2.4. Figure 21 shows the scenario in which the severely congested node is located in the "reverse" path. Note that in this situation, it is assumed that the "forward" path is not congested. The main difference between this scenario and the scenario shown in Figure 20 is that no end-to-end NOTIFY (PDR) message has to be generated by the QNE Egress node. This is because now the severe congestion occurs on the "reverse" path and the QNE Ingress node receives the (#marked and #unmarked) user data passing through the severely congested "reverse" path. The QNE Ingress node will be able to calculate the number of flows that have to be terminated or forwarded in a lower priority queue.
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress) NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful user| | | | | data| user | | | | --->| data | user data | |user data | |--------------->| | | | | |--------------------------->|user data |user | | | |-------------->|data | | | | |---> | | | user | |<--- | user data | | data |<--------------| | (#marked bytes)| S<----------| | |<--------------------------------S | | | (#unmarked bytes) S | | Term|<--------------------------------S | | Flow? | S | | YES |RESERVE(RMD-QSPEC): S | | |"forward - T tear" s | | |--------------->| RESERVE(RMD-QSPEC): | | | | "forward - T tear" | | | |--------------------------->| | | | S |-------------->| | | S RESERVE(RMD-QSPEC): | | S "reverse - T tear" | | RESERVE(RMD-QSPEC) S |<--------------| | "reverse - T tear" S<----------| | |<--------------------------------S | | Figure 21: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion on path QNE(Egress) towards QNE(Ingress)) For the flows that have to be terminated, a release procedure, see Section 4.6.2.4, is initiated to release the reserved resources on the "forward" and "reverse" paths. 4.6.2.6. Admission Control Using Congestion Notification Based on Probing This section describes the admission control scheme that uses the congestion notification function based on probing when RMD intra- domain bidirectional reservations are supported.
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress) NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful user| | | | | data| | | | | --->| | user data | |user data | |-------------------------------------------->S (#marked bytes) | | | S-------------->| | | | S(#unmarked bytes) | | | S-------------->| | | | S | | | RESERVE(re-marked DSCP in GIST)):| | | | S | |-------------------------------------------->S | | | | S-------------->| | | | S | | | RESPONSE(unsuccessful INFO-SPEC) | |<------------------------------------------------------------| | | | S | Figure 22: Intra-domain RMD congestion notification based on probing for bidirectional admission control (congestion on path from QNE(Ingress) towards QNE(Egress)) This procedure is similar to the congestion notification for admission control procedure described in Section 4.6.1.7. The main difference is related to the location of the severe congested node, i.e., "forward" path (i.e., path between QNE Ingress towards QNE Egress) or "reverse" path (i.e., path between QNE Egress towards QNE Ingress). Figure 22 shows the scenario in which the severely congested node is located in the "forward" path. The functionality of providing admission control is the same as that described in Section 4.6.1.7, Figure 15. Figure 23 shows the scenario in which the congested node is located in the "reverse" path. The probe RESERVE message sent in the "forward" direction will not be affected by the severely congested node, while the <DSCP> value in the IP header of any packet of the "reverse" direction flow and also of the GIST message that carries the probe RESERVE message sent in the "reverse" direction will be re- marked by the congested node. The QNE Ingress is, in this way, notified that a congestion occurred in the network, and therefore it is able to refuse the new initiation of the reservation.
Note that the "not NSIS-aware" Interior nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way as the Interior "NSIS-aware" nodes do. QNE(Ingress) Interior QNE (int.) Interior QNE(Egress) NTLP stateful not NSIS aware NTLP st.less not NSIS aware NTLP stateful user| | | | | data| | | | | --->| | user data | | | |-------------------------------------------->|user data |user | | | |-------------->|data | | | | |---> | | | | |user | | | | |data | | | | |<--- | S | user data | | | S user data |<--------------------------| | user data S<---------------| | | |<---------------S | | | | user data S | | | | (#marked bytes)S | | | |<---------------S | | | | S RESERVE(unmarked DSCP in GIST)): | | S | | | |----------------S------------------------------------------->| | S RESERVE(re-marked DSCP in GIST) | | S<-------------------------------------------| |<---------------S | | | Figure 23: Intra-domain RMD congestion notification for bidirectional admission control (congestion on path QNE(Egress) towards QNE(Ingress)) 4.7. Handling of Additional Errors During the QSPEC processing, additional errors MAY occur. The way in which these additional errors are handled and notified is specified in [RFC5975] and [RFC5974]. 5. Security Considerations 5.1. Introduction A design goal of the RMD-QOSM protocol is to be "lightweight" in terms of the number of exchanged signaling message and the amount of state established at involved signaling nodes (with and without reduced-state operation). A side effect of this design decision is
to introduce second-class signaling nodes, namely QNE Interior nodes,
that are restricted in their ability to perform QoS signaling
actions. Only the QNE Ingress and the QNE Egress nodes are allowed
to initiate certain signaling messages.
Moreover, RMD focuses on an intra-domain deployment only.
The above description has the following implications for security:
1) QNE Ingress and QNE Egress nodes require more security and fault
protection than QNE Interior nodes because their uncontrolled
behavior has larger implications for the overall stability of the
network. QNE Ingress and QNE Egress nodes share a security
association and utilize GIST security for protection of their
signaling messages. Intra-domain signaling messages used for RMD
signaling do not use GIST security, and therefore they do not
store security associations.
2) The focus on intra-domain QoS signaling simplifies trust
management and reduces overall complexity. See Section 2 of RFC
4081 for a more detailed discussion about the complete set of
communication models available for end-to-end QoS signaling
protocols. The security of RMD-QOSM does not depend on Interior
nodes, and hence the cryptographic protection of intra-domain
messages via GIST is not utilized.
It is important to highlight that RMD always uses the message
exchange shown in Figure 24 even if there is no end-to-end signaling
session. If the RMD-QOSM is triggered based on an end-to-end (E2E)
signaling exchange, then the RESERVE message is created by a node
outside the RMD domain and will subsequently travel further (e.g., to
the data receiver). Such an exchange is shown in Figure 3. As such,
an evaluation of an RMD's security always has to be seen as a
combination of the two signaling sessions, (1) and (2) of Figure 24.
Note that for the E2E message, such as the RESERVE and the RESPONSE
message, a single "hop" refers to the communication between the QNE
Ingress and the QNE Egress since QNE Interior nodes do not
participate in the exchange.
QNE QNE QNE QNE Ingress Interior Interior Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | | RESERVE (1) | | | +--------------------------------------------->| | RESERVE' (2) | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | RESPONSE' (2)| |<---------------------------------------------+ | | | RESPONSE (1) | |<---------------------------------------------+ Figure 24: RMD message exchange Authorizing quality-of-service reservations is accomplished using the Authentication, Authorization, and Accounting (AAA) framework and the functionality is inherited from the underlying NSIS QoS NSLP, see [RFC5974], and not described again in this document. As a technical solution mechanism, the Diameter QoS application [RFC5866] may be used. The end-to-end reservation request arriving at the Ingress node will trigger the authorization procedure with the backend AAA infrastructure. The end-to-end reservation is typically triggered by a human interaction with a software application, such as a voice- over-IP client when making a call. When authorization is successful then no further user initiated QoS authorization check is expected to be performed within the RMD domain for the intra-domain reservation. 5.2. Security Threats In the RMD-QOSM, the Ingress node constructs both end-to-end and intra-domain signaling messages based on the end-to-end message initiated by the sender end node. The Interior nodes within the RMD network ignore the end-to-end signaling message, but they process, modify, and forward the intra- domain signaling messages towards the Egress node. In the meantime, resource reservation states are installed, modified, or deleted at each Interior node along the data path according to the content of each intra-domain signaling message. The Edge nodes of an RMD network are critical components that require strong security protection.
Therefore, they act as security gateways for incoming and outgoing signaling messages. Moreover, a certain degree of trust has to be placed into Interior nodes within the RMD-QOSM network, such that these nodes can perform signaling message processing and take the necessary actions. With the RMD-QOSM, we assume that the Ingress and the Egress nodes are not controlled by an adversary and the communication between the Ingress and the Egress nodes is secured using standard GIST security, (see Section 6 of [RFC5971]) mechanisms and experiences integrity, replay, and confidentiality protection. Note that this only affects messages directly addressed by these two nodes and not any other message that needs to be processed by intermediaries. The <SESSION-ID> object of the end-to-end communication is visible, via GIST, to the Interior nodes. In order to define the security threats that are associated with the RMD-QOSM, we consider that an adversary that may be located inside the RMD domain and could drop, delay, duplicate, inject, or modify signaling packets. Depending on the location of the adversary, we speak about an on-path adversary or an off-path adversary, see also RFC 4081 [RFC4081]. 5.2.1. On-Path Adversary The on-path adversary is a node, which supports RMD-QOSM and is able to observe RMD-QOSM signaling message exchanges. 1) Dropping signaling messages An adversary could drop any signaling messages after receiving them. This will cause a failure of reservation request for new sessions or deletion of resource units (bandwidth) for ongoing sessions due to states timeout. It may trigger the Ingress node to retransmit the lost signaling messages. In this scenario, the adversary drops selected signaling messages, for example, intra-domain reserve messages. In the RMD- QOSM, the retransmission mechanism can be provided at the Ingress node to make sure that signaling messages can reach the Egress node. However, the retransmissions triggered by the adversary dropping messages may cause certain problems. Therefore, disabling the use of retransmissions in the RMD-QOSM-aware network is recommended, see also Section 4.6.1.1.1.
2) Delaying Signaling Messages Any signaling message could be delayed by an adversary. For example, if RESERVE' messages are delayed over the duration of the refresh period, then the resource units (bandwidth) reserved along the nodes for corresponding sessions will be removed. In this situation, the Ingress node does not receive the RESPONSE within a certain period, and considers that the signaling message has failed, which may cause a retransmission of the "failed" message. The Egress node may distinguish between the two messages, i.e., the delayed message and the retransmitted message, and it could get a proper response. However, Interior nodes suffer from this retransmission and they may reserve twice the resource units (bandwidth) requested by the Ingress node. 3) Replaying Signaling Messages An adversary may want to replay signaling messages. It first stores the received messages and decides when to replay these messages and at what rate (packets per second). When the RESERVE' message carried an <RII> object, the Egress will reply with a RESPONSE' message towards the Ingress node. The Ingress node can then detect replays by comparing the value of <RII> in the RESPONSE' messages with the stored value. 4) Injecting Signaling Messages Similar to the replay-attack scenario, the adversary may store a part of the information carried by signaling messages, for example, the <RSN> object. When the adversary injects signaling messages, it puts the stored information together with its own generated parameters (RMD-QSPEC <TMOD-1> parameter, <RII>, etc.) into the injected messages and then sends them out. Interior nodes will process these messages by default, reserve the requested resource units (bandwidth) and pass them to downstream nodes. It may happen that the resource units (bandwidth) on the Interior nodes are exhausted if these injected messages consume too much bandwidth. 5) Modifying Signaling Messages On-path adversaries are capable of modifying any part of the signaling message. For example, the adversary can modify the <M>, <S>, and <O> parameters of the RMD-QSPEC messages. The Egress node will then use the SESSION-ID and subsequently the <BOUND-SESSION-ID>
objects to refer to that flow to be terminated or set to lower priority. It is also possible for the adversary to modify the RMD- QSPEC <TMOD-1> parameter and/or <PHB Class> parameter, which could cause a modification of an amount of the requested resource units (bandwidth) changes. 5.2.2. Off-Path Adversary In this case, the adversary is not located on-path and it does not participate in the exchange of RMD-QOSM signaling messages, and therefore is unable to eavesdrop signaling messages. Hence, the adversary does not know valid <RII>s, <RSN>s, and <SESSION-ID>s. Hence, the adversary has to generate new parameters and constructs new signaling messages. Since Interior nodes operate in reduced- state mode, injected signaling messages are treated as new once, which causes Interior nodes to allocate additional reservation state. 5.3. Security Requirements The following security requirements are set as goals for the intra- domain communication, namely: * Nodes, which are never supposed to participate in the NSIS signaling exchange, must not interfere with QNE Interior nodes. Off-path nodes (off-path with regard to the path taken by a particular signaling message exchange) must not be able to interfere with other on-path signaling nodes. * The actions allowed by a QNE Interior node should be minimal (i.e., only those specified by the RMD-QOSM). For example, only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. QNE Interior nodes are, for example, allowed to modify certain signaling message payloads. Note that the term "interfere" refers to all sorts of security threats, such as denial-of-service, spoofing, replay, signaling message injection, etc. 5.4. Security Mechanisms An important security mechanism that was built into RMD-QOSM was the ability to tie the end-to-end RESERVE and the RESERVE' messages together using the BOUND-SESSION-ID and to allow the Ingress node to match the RESERVE' with the RESPONSE' by using the <RII>. These mechanisms enable the Edge nodes to detect unexpected signaling messages.
We assume that the RESERVE/RESPONSE is sent with hop-by-hop channel
security provided by GIST and protected between the QNE Ingress and
the QNE Egress. GIST security mechanisms MUST be used to offer
authentication, integrity, and replay protection. Furthermore,
encryption MUST be used to prevent an adversary located along the
path of the RESERVE message from learning information about the
session that can later be used to inject a RESERVE' message.
The following messages need to be mapped to each other to make sure
that the occurrence of one message is not without the other:
a) the RESERVE and the RESERVE' relate to each other at the QNE
Egress; and
b) the RESPONSE and the RESERVE relate to each other at the QNE
Ingress; and
c) the RESERVE' and the RESPONSE' relate to each other. The <RII> is
carried in the RESERVE' message and the RESPONSE' message that is
generated by the QNE Egress node contains the same <RII> as the
RESERVE'. The <RII> can be used by the QNE Ingress to match the
RESERVE' with the RESPONSE'. The QNE Egress is able to determine
whether the RESERVE' was created by the QNE Ingress node since the
intra-domain session, which sent the RESERVE', is bound to an end-
to-end session via the <BOUND-SESSION-ID> value included in the
intra-domain QoS-NSLP operational state maintained at the QNE
Egress.
The RESERVE and the RESERVE' message are tied together using the
BOUND-SESSION-ID(s) maintained by the intra-domain and end-to-end
QoS-NSLP operational states maintained at the QNE Edges (see Sections
4.3.1, 4.3.2, and 4.3.3). Hence, there cannot be a RESERVE' without
a corresponding RESERVE. The SESSION-ID can fulfill this purpose
quite well if the aim is to provide protection against off-path
adversaries that do not see the SESSION-ID carried in the RESERVE and
the RESERVE' messages.
If, however, the path changes (due to rerouting or due to mobility),
then an adversary could inject RESERVE' messages (with a previously
seen SESSION-ID) and could potentially cause harm.
An off-path adversary can, of course, create RESERVE' messages that
cause intermediate nodes to create some state (and cause other
actions) but the message would finally hit the QNE Egress node. The
QNE Egress node would then be able to determine that there is
something going wrong and generate an error message.
The severe congestion handling can be triggered by intermediate nodes (unlike other messages). In many cases, however, intermediate nodes experiencing congestion use refresh messages modify the <S> and <O> parameters of the message. These messages are still initiated by the QNE Ingress node and carry the SESSION-ID. The QNE Egress node will use the SESSION-ID and subsequently the BOUND-SESSION-ID, maintained by the intra-domain QoS-NSLP operational state, to refer to a flow that might be terminated. The aspect of intermediate nodes initiating messages for severe congestion handling is for further study. During the refresh procedure, a RESERVE' creates a RESPONSE', see Figure 25. The <RII> is carried in the RESERVE' message and the RESPONSE' message that is generated by the QNE Egress node contains the same <RII> as the RESERVE'. The <RII> can be used by the QNE Ingress to match the RESERVE' with the RESPONSE'. A further aspect is marking of data traffic. Data packets can be modified by an intermediary without any relationship to a signaling session (and a SESSION-ID). The problem appears if an off-path adversary injects spoofed data packets. QNE Ingress QNE Interior QNE Interior QNE Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | | REFRESH RESERVE' | | +-------------->| REFRESH RESERVE' | | (+RII) +-------------->| REFRESH RESERVE' | | (+RII) +------------->| | | | (+RII) | | | | | | | | REFRESH | | | | RESPONSE'| |<---------------------------------------------+ | | | (+RII) | Figure 25: RMD REFRESH message exchange The adversary thereby needs to spoof data packets that relate to the flow identifier of an existing end-to-end reservation that SHOULD be terminated. Therefore, the question arises how an off-path adversary SHOULD create a data packet that matches an existing flow identifier (if a 5-tuple is used). Hence, this might not turn out to be simple for an adversary unless we assume the previously mentioned mobility/rerouting case where the path through the network changes and the set of nodes that are along a path changes over time.
6. IANA Considerations This section defines additional codepoint assignments in the QSPEC Parameter ID registry, in accordance with BCP 26 [RFC5226]. 6.1. Assignment of QSPEC Parameter IDs This document specifies the following QSPEC containers in the QSPEC Parameter ID registry created in [RFC5975]: <PHR_Resource_Request> (Section 4.1.2 above, ID=17) <PHR_Release_Request> (Section 4.1.2 above, ID=18) <PHR_Refresh_Update> (Section 4.1.2 above, ID=19) <PDR_Reservation_Request> (Section 4.1.3 above, ID=20) <PDR_Refresh_Request> (Section 4.1.3 above, ID=21) <PDR_Release_Request> (Section 4.1.3 above, ID=22) <PDR_Reservation_Report> (Section 4.1.3 above, ID=23) <PDR_Refresh_Report> (Section 4.1.3 above, ID=24) <PDR_Release_Report> (Section 4.1.3 above, ID=25) <PDR_Congestion_Report> (Section 4.1.3 above, ID=26) 7. Acknowledgments The authors express their acknowledgement to people who have worked on the RMD concept: Z. Turanyi, R. Szabo, G. Pongracz, A. Marquetant, O. Pop, V. Rexhepi, G. Heijenk, D. Partain, M. Jacobsson, S. Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel, M. Zoumaro-Djayoon, M. Swanink, R. Klaver G. Stokkink, J. W. van Houwelingen, D. Dimitrova, T. Sealy, H. Chang, and J. de Waal. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", RFC 5971, October 2010. [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010. [RFC5975] Ash, G., Bader, A., Kappler C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010. 8.2. Informative References [AdCa03] Adler, M., Cai, J.-Y., Shapiro, J. K., Towsley, D., "Estimation of congestion price using probabilistic packet marking", Proc. IEEE INFOCOM, pp. 2068-2078, 2003. [AnHa06] Lachlan L. H. Andrew and Stephen V. Hanly, "The Estimation Error of Adaptive Deterministic Packet Marking", 44th Annual Allerton Conference on Communication, Control and Computing, 2006. [AtLi01] Athuraliya, S., Li, V. H., Low, S. H., Yin, Q., "REM: active queue management", IEEE Network, vol. 15, pp. 48-53, May/June 2001. [Chan07] H. Chang, "Security support in RMD-QOSM", Masters thesis, University of Twente, 2007. [CsTa05] Csaszar, A., Takacs, A., Szabo, R., Henk, T., "Resilient Reduced-State Resource Reservation", Journal of Communication and Networks, Vol. 7, No. 4, December 2005. [DiKa08] Dimitrova, D., Karagiannis, G., de Boer, P.-T., "Severe congestion handling approaches in NSIS RMD domains with bi-directional reservations", Journal of Computer Communications, Elsevier, vol. 31, pp. 3153-3162, 2008. [JaSh97] Jamin, S., Shenker, S., Danzig, P., "Comparison of Measurement-based Admission Control Algorithms for Controlled-Load Service", Proceedings IEEE Infocom '97, Kobe, Japan, April 1997. [GrTs03] Grossglauser, M., Tse, D.N.C, "A Time-Scale Decomposition Approach to Measurement-Based Admission Control", IEEE/ACM Transactions on Networking, Vol. 11, No. 4, August 2003.
[Part94] C. Partridge, Gigabit Networking, Addison Wesley Publishers (1994). [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC2638] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999. [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC3726] Brunner, M., Ed., "Requirements for Signaling Protocols", RFC 3726, April 2004. [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005. [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005. [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5866] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, Ed., "Diameter Quality-of-Service Application", RFC 5866, May 2010. [RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, Ed., "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010. [RMD1] Westberg, L., et al., "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", IFIP PfHSN 2002. [RMD2] G. Karagiannis, et al., "RMD - a lightweight application of NSIS" Networks 2004, Vienna, Austria. [RMD3] Marquetant A., Pop O., Szabo R., Dinnyes G., Turanyi Z., "Novel Enhancements to Load Control - A Soft-State, Lightweight Admission Control Protocol", Proc. of the 2nd Int. Workshop on Quality of Future Internet Services, Coimbra, Portugal, Sept 24-26, 2001, pp. 82-96. [RMD4] A. Csaszar et al., "Severe congestion handling with resource management in diffserv on demand", Networking 2002. [TaCh99] P. P. Tang, T-Y Charles Tai, "Network Traffic Characterization Using Token Bucket Model", IEEE Infocom 1999, The Conference on Computer Communications, no. 1, March 1999, pp. 51-62. [ThCo04] Thommes, R. W., Coates, M. J., "Deterministic packet marking for congestion packet estimation" Proc. IEEE Infocom, 2004.