RFC 5977
RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv
Pages: 128
Experimental
Experimental
Part 3 of 5 – Pages 46 to 73
4.6.1.2. Unsuccessful Reservation
This subsection describes the operation where a request for reservation cannot be satisfied by the RMD-QOSM. The QNE Ingress, the QNE Interior, and QNE Egress nodes process and forward the end-to-end RESERVE message and the intra-domain RESERVE(RMD-QSPEC) message in a similar way, as specified in Section 4.6.1.1. The main difference between the unsuccessful operation and successful operation is that one of the QNE nodes does not admit the
request, e.g., due to lack of resources. This also means that the QNE Edge node MUST NOT forward the end-to-end RESERVE message towards the QNR node. Note that the described functionality applies to the RMD reservation- based methods (see Sections 4.3.1 and 4.3.2) and to the NSIS measurement-based admission control method (see Section 4.3.2). The QNE Edge nodes maintain either per-flow QoS-NSLP reservation states or aggregated QoS-NSLP reservation states. When the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY accomplish an RMD modification procedure (see Section 4.6.1.4), instead of the reservation initiation procedure that is described in this subsection.4.6.1.2.1. Operation in the Ingress Nodes
When an end-to-end RESERVE message arrives at the QNE Ingress and if (1) the "Maximum Packet Size-1 (MPS)" included in the end-to-end QoS Model <TMOD-1> is larger than this smallest MTU value within the RMD domain or (2) there are no resources available, the QNE Ingress MUST reject this end-to-end RESERVE message and send an end-to-end RESPONSE message back to the sender, as described in the QoS-NSLP specification, see [RFC5974] and [RFC5975]. When an end-to-end RESPONSE message is received by an Ingress node (see Section 4.6.1.2.3), the values of the <RII>, <RSN>, <INFO-SPEC>, and [<QSPEC>] objects are processed according to the QoS-NSLP procedures. If the end-to-end RESPONSE message has to be forwarded upstream to a node outside the RMD-QOSM-aware domain, then the values of the objects contained in this message (i.e., <RII<, <RSN>, <INFO-SPEC>, [<QSPEC>]) MUST be set by the QoS-NSLP protocol functions of the QNE. When an intra-domain RESPONSE message is received by the QNE Ingress node, which was sent by a QNE Egress (see Section 4.6.1.2.3), it uses the QoS-NSLP procedures to match it to the intra-domain RESERVE message that was previously sent. After this phase, the RMD-QSPEC has to be identified and processed. Note that, in this case, the RMD Resource Management Function (RMF) is notified that the reservation has been unsuccessful, by reading the <M> parameter of the PDR container. Note that when the QNE Edges maintain a per-flow QoS-NSLP reservation state, the RMD-QOSM functionality, has to start an RMD release procedure (see Section 4.6.1.5). When the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY start an RMD modification procedure (see Section 4.6.1.4).
4.6.1.2.2. Operation in the Interior Nodes
In the case of the RMD reservation-based scenario, and if the intra- domain reservation request is not admitted by the QNE Interior node, then the <Hop_U> and <M> parameters of the PHR container MUST be set to "1". The <Admitted Hops> counter MUST NOT be increased. Moreover, the value of the <Max Admitted Hops> counter MUST be set equal to the <Admitted Hops> value. Furthermore, the <E> flag associated with the QSPEC <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set. In the case of the RMD measurement-based scenario, the <M> parameter of the PHR container MUST be set to "1". Furthermore, the <E> flag associated with the QSPEC <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set. Note that the <M> flag seems to be set in a similar way to the <E> flag used by the local RMD-QSPEC <TMOD-1> parameter. However, the ways in which the two flags are processed by a QNE are different. In general, if a QNE Interior node receives an RMD-QSPEC <TMOD-1> parameter with the <E> flag set and a PHR container type "PHR_Resource_Request", with the <M> parameter set to "1", then this "PHR Container" and the RMD-QOSM <QoS Desired> object) MUST NOT be processed. Furthermore, when the <K> parameter that is included in the "PHR Container" and carried by a RESERVE message is set to "1", then this "PHR Container" and the RMD-QOSM <QoS Desired> object) MUST NOT be processed.4.6.1.2.3. Operation in the Egress Nodes
In the RMD reservation-based (Section 4.3.3) and RMD NSIS measurement-based scenarios (Section 4.3.2), when the <M> marked intra-domain RESERVE(RMD-QSPEC) is received by the QNE Egress node (see Figure 9), the session associated with the intra-domain RESERVE(RMD-QSPEC) (the PHB session) and the end-to-end session MUST be bound. Moreover, if the initial QSPEC object (used by the end-to-end QoS Model) used an object combination of type 1 or 2 where the <QoS Available> is populated, and the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain, i.e., the intra-domain RESERVE(RMD-QSPEC) message is marked, it MUST be considered that the <QoS Available> is not satisfied and that the inter-domain (end-to- end) reservation is considered as to have failed.
When the QNE Egress uses per-flow intra-domain QoS-NSLP operational states (see Sections 4.3.2 and 4.3.3), then the QNE Egress node MUST generate an end-to-end RESPONSE message that has to be sent to its previous stateful QoS-NSLP hop (see the QoS-NSLP-RMF API described in [RFC5974]). * the values of the <RII>, <RSN> and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions. In the case of an unsuccessful reservation, the <INFO-SPEC> object SHOULD have the following values: Error severity class: Transient Failure Error code value: Reservation failure The QSPEC that was carried by the end-to-end RESERVE message that belongs to the same session as this end-to-end RESPONSE message is included in this message. In particular, the parameters included in the QSPEC <QoS Reserved> object of the end-to-end RESPONSE message are copied from the initial <QoS Desired> values included in its associated end-to-end RESERVE message. The <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the <TMOD-1> parameter included in the end-to-end RESPONSE are set. In addition to the above, similar to the successful operation, see Section 4.6.1.1.3, the QNE Egress MUST generate an intra-domain RESPONSE message that has to be sent to its previous stateful QoS- NSLP hop. The values of the <RII>, <RSN> and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions. In the case of an unsuccessful reservation, the <INFO-SPEC> object SHOULD have the following values (see the QoS-NSLP-RMF API described in [RFC5974]): Error severity class: Transient Failure Error code value: Reservation failure
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress) NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | --->| | | RESERVE | |------------------------------------------------------------>| |RESERVE(RMD-QSPEC:M=0) | | |------------------->| | | | |RESERVE(RMD-QSPEC:M=1) | | |------------------>| | | | | RESERVE(RMD-QSPEC:M=1) | | |------------------->| | |RESPONSE(RMD-QOSM) | | |<------------------------------------------------------------| | |RESPONSE | | |<------------------------------------------------------------| RESPONSE | | | <---| | | | RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max Admitted Hops> |------------------->| | | |RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) | | |------------------>| | | RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)| | | |------------------->| Figure 9: Basic operation during unsuccessful reservation initiation used by the RMD-QOSM The values of the RMD-QSPEC MUST be used and/or set in the following way (see the QoS-NSLP-RMF API described in [RFC5974]): * the value of the <PDR Control Type> of the PDR container MUST be set to "23" (PDR_Reservation_Report); * the value of the <Max Admitted Hops> parameter of the PHR container included in the received <M> marked intra-domain RESERVE (RMD-QSPEC) MUST be included in the <Max Admitted Hops> parameter of the PDR container; * the value of the <M> parameter of the PDR container MUST be "1".4.6.1.3. RMD Refresh Reservation
In the case of the RMD measurement-based method, see Section 4.3.2, QoS-NSLP reservation states in the RMD domain are not typically maintained, therefore, this method typically does not use an intra- domain refresh procedure.
However, there are measurement-based optimization schemes, see [GrTs03], that MAY use the refresh procedures described in Sections 4.6.1.3.1 and 4.6.1.3.3. However, this measurement-based optimization scheme can only be applied in the RMD domain if the QNE Edges are configured to perform intra-domain refresh procedures and if all the QNE Interior nodes are configured to perform the measurement-based optimization schemes. In the description given in this subsection, it is assumed that the RMD measurement-based scheme does not use the refresh procedures. When the QNE Edges maintain aggregated or per-flow QoS-NSLP operational and reservation states (see Sections 4.3.1 and 4.3.3), then the refresh procedures are very similar. If the RESERVE messages arrive within the soft state timeout period, the corresponding number of resource units are not removed. However, the transmission of the intra-domain and end-to-end (refresh) RESERVE message are not necessarily synchronized. Furthermore, the generation of the end-to-end RESERVE message, by the QNE Edges, depends on the locally maintained refreshed interval (see [RFC5974]).4.6.1.3.1. Operation in the Ingress Node
The Ingress node MUST be able to generate an intra-domain (refresh) RESERVE(RMD-QSPEC) at any time defined by the refresh period/timer. Before generating this message, the RMD QoS signaling model functionality is using the RMD traffic class (PHR) resource units for refreshing the RMD traffic class state. Note that the RMD traffic class refresh periods MUST be equal in all QNE Edge and QNE Interior nodes and SHOULD be smaller (default: more than two times smaller) than the refresh period at the QNE Ingress node used by the end-to-end RESERVE message. The intra-domain RESERVE (RMD-QSPEC) message MUST include an RMD-QOSM <QoS Desired> and a PHR container (i.e., PHR_Refresh_Update). An example of this refresh operation can be seen in Figure 10.
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress) NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | |RESERVE(RMD-QSPEC) | | | |------------------->| | | | |RESERVE(RMD-QSPEC) | | | |------------------>| | | | | RESERVE(RMD-QSPEC) | | | |------------------->| | | | | | |RESPONSE(RMD-QSPEC)| | |<------------------------------------------------------------| | | | | Figure 10: Basic operation of RMD-specific refresh procedure Most of the non-default values of the objects contained in this message MUST be used and set by the QNE Ingress in the same way as described in Section 4.6.1.1. The following objects are used and/or set differently: * the PHR resource units MUST be included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter. The <Peak Data Rate-1 (p)> field value of the local RMD-QSPEC <TMOD-1> parameter depends on how the different inter-domain (end-to-end) flows are aggregated by the QNE Ingress node (e.g., the sum of all the PHR-requested resources of the aggregated flows); see Section 4.3.1. If no QoS-NSLP aggregation is accomplished by the QNE Ingress node, the <Peak Data Rate-1 (p)> value of the local RMD- QSPEC <TMOD-1> parameter SHOULD be equal to the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of its associated new (initial) intra-domain RESERVE (RMD-QSPEC) message; see Section 4.3.3. * the value of the Container field of the <PHR Container> MUST be set to "19", i.e., "PHR_Refresh_Update". When the intra-domain RESPONSE (RMD-QSPEC) message (see Section 4.6.1.3.3), is received by the QNE Ingress node, then: * the values of the <RII>, <RSN>, <INFO-SPEC>, and [RFC5975] objects are processed by the standard QoS-NSLP protocol functions (see Section 4.6.1.1); * the "PDR Container" has to be processed by the RMD-QOSM functionality in the QNE Ingress node. The RMD-QOSM functionality is notified by the <PDR M> parameter of the PDR container that the refresh procedure has been successful or unsuccessful. All
sessions associated with this RMD-specific refresh session MUST be
informed about the success or failure of the refresh procedure.
(When aggregated QoS-NSLP operational and reservation states are
used (see Section 4.3.1), there will be more than one session.)
In the case of failure, the QNE Ingress node has to generate (in a
standard QoS-NSLP way) an error end-to-end RESPONSE message that
will be sent towards the QNI.
4.6.1.3.2. Operation in the Interior Node
The intra-domain RESERVE (RMD-QSPEC) message is received and
processed by the QNE Interior nodes. Any QNE Edge or QNE Interior
node that receives a <PHR_Refresh_Update> field MUST identify the
traffic class state (PHB) (using the <PHB Class> parameter). Most of
the parameters in this refresh intra-domain RESERVE (RMD-QSPEC)
message MUST be used and/or set by a QNE Interior node in the same
way as described in Section 4.6.1.1.
The following objects are used and/or set differently:
* the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1>
parameter of the RMD-QOSM <QoS Desired> is used by the QNE
Interior node for refreshing the RMD traffic class state. These
resources (included in the <Peak Data Rate-1 (p)> value of local
RMD-QSPEC <TMOD-1>), if reserved, are added to the currently
reserved resources per PHB and therefore they will become a part
of the per-traffic class (PHB) reservation state (see Sections
4.3.1 and 4.3.3). If the refresh procedure cannot be fulfilled
then the <M> and <S> fields carried by the PHR container MUST be
set to "1".
* furthermore, the <E> flag associated with <QoS Desired> object and
the <E> flag associated with the local RMD-QSPEC <TMOD-1>
parameter SHOULD be set.
Any PHR container of type "PHR_Refresh_Update", and its associated
local RMD-QSPEC <TMOD-1>, whether or not it is marked and independent
of the <E> flag value of the local RMD-QSPEC <TMOD-1> parameter, is
always processed, but marked bits are not changed.
4.6.1.3.3. Operation in the Egress Node
The intra-domain RESERVE(RMD-QSPEC) message is received and processed
by the QNE Egress node. A new intra-domain RESPONSE (RMD-QSPEC)
message is generated by the QNE Egress node and MUST include a PDR
(type PDR_Refresh_Report).
The (refresh) intra-domain RESPONSE (RMD-QSPEC) message MUST be sent to the QNE Ingress node, i.e., the previous stateful hop. The (refresh) intra-domain RESPONSE (RMD-QSPEC) message MUST be explicitly routed to the QNE Ingress node, i.e., the previous stateful hop, using the procedures described in Section 4.5. * the values of the <RII>, <RSN>, and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions, see [RFC5974]. * the value of the <PDR Control Type> parameter of the PDR container MUST be set "24" (i.e., PDR_Refresh_Report). In case of successful reservation, the <INFO-SPEC> object SHOULD have the following values: Error severity Class: Success Error code value: Reservation successful * In the case of unsuccessful reservation the <INFO-SPEC> object SHOULD have the following values: Error severity class: Transient Failure Error code value: Reservation failure The RMD-QSPEC that was carried by the intra-domain RESERVE belonging to the same session as this intra-domain RESPONSE is included in the intra-domain RESPONSE message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values. If the reservation is unsuccessful, then the <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter are set. Furthermore, the <M> and <S> PDR container bits are set to "1".4.6.1.4. RMD Modification of Aggregated Reservations
In the case when the QNE Edges maintain QoS-NSLP-aggregated operational and reservation states and the aggregated reservation has to be modified (see Section 4.3.1) the following procedure is applied: * 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)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>, which is sent together with a "PHR_Resource_Request" control information. If a QNE Edge or QNE Interior node is not able to reserve the number of requested resources, the "PHR_Resource_Request" that is associated with the local RMD-QSPEC <TMOD-1> parameter MUST be <M> marked,
i.e., the <M> bit is set to the value of "1". In this situation,
the RMD-specific operation for unsuccessful reservation will be
applied (see Section 4.6.1.2).
* 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)> value 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.1.5).
Note that if the complete bandwidth associated with the aggregated
reservation maintained at the QNE Ingress does not have to be
released, then the <TEAR> flag MUST be set to OFF. This is
because the NSLP operational states associated with the aggregated
reservation states at the Edge QNEs MUST NOT be turned off.
However, if the complete bandwidth associated with the aggregated
reservation maintained at the QNE Ingress has to be released, then
the <TEAR> flag MUST be set to ON.
It is important to emphasize that this RMD modification scheme only
applies to the following two RMD-QOSM schemes:
* "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.
4.6.1.5. RMD Release Procedure
This procedure is applied to all RMD mechanisms that maintain
reservation states. If a refresh RESERVE message does not arrive at
a QNE Interior node within the refresh timeout period, then the
bandwidth requested by this refresh RESERVE message is not updated.
This means that the reserved bandwidth associated with the reduced
state is decreased in the next refresh period by the amount of the
corresponding bandwidth that has not been refreshed, see Section
4.3.3.
This soft state behavior provides certain robustness for the system
ensuring that unused resources are not reserved for a long time.
Resources can be removed by an explicit release at any time.
However, in the situation that an end-to-end (tear) RESERVE is
retransmitted (see Section 5.2.4 in [RFC5974]), then this message
MUST NOT initiate an intra-domain (tear) RESERVE message. This is
because the amount of bandwidth within the RMD domain associated with
the (tear) end-to-end RESERVE has already been released, and therefore, this amount of bandwidth within the RMD domain MUST NOT once again be released. When the RMD-RMF of a QNE Edge or QNE Interior node processes a "PHR_Release_Request" PHR container, it MUST identify the <PHB Class> parameter and estimate the time period that elapsed after the previous refresh, see also Section 3 of [CsTa05]. This MAY be done by indicating the time lag, say "T_Lag", between the last sent "PHR_Refresh_Update" and the "PHR_Release_Request" control information container by the QNE Ingress node, see [RMD1] and [CsTa05] for more details. The value of "T_Lag" is first normalized to the length of the refresh period, say "T_period". The ratio between the "T_Lag" and the length of the refresh period, "T_period", is calculated. This ratio is then introduced into the <Time Lag> field of the "PHR_Release_Request". When the above mentioned procedure of indicating the "T_Lag" is used and when a node (QNE Egress or QNE Interior) receives the "PHR_Release_Request" PHR container, it MUST store the arrival time. Then, it MUST calculate the time difference, "T_diff", between the arrival time and the start of the current refresh period, "T_period". Furthermore, this node MUST derive the value of the "T_Lag", from the <Time Lag> parameter. "T_Lag" can be found by multiplying the value included in the <Time Lag> parameter with the length of the refresh period, "T_period". If the derived time lag, "T_Lag", is smaller than the calculated time difference, "T_diff", then this node MUST decrease the PHB reservation state with the number of resource units indicated in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> that has been sent together with the "PHR_Release_Request" "PHR Container", but not below zero. An RMD-specific release procedure can be triggered by an end-to-end RESERVE with a <TEAR> flag set to ON (see Section 4.6.1.5.1), or it can be triggered by either an intra-domain RESPONSE, an end-to-end RESPONSE, or an end-to-end NOTIFY message that includes a marked (i.e., PDR <M> and/or PDR <S> parameters are set to ON) "PDR_Reservation_Report" or "PDR_Congestion_Report" and/or an <INFO-SPEC> object.4.6.1.5.1. Triggered by a RESERVE Message
This RMD-explicit release procedure can be triggered by a tear (<TEAR> flag set to ON) end-to-end RESERVE message. When a tear (<TEAR> flag set ON) end-to-end RESERVE message arrives to the QNE Ingress, the QNE Ingress node SHOULD process the message in a standard QoS-NSLP way (see [RFC5974]). In addition to this, the RMD RMF is notified, as specified in [RFC5974].
Like the scenario described in Section 4.6.1.1., a bypassing procedure has to be initiated by the QNE Ingress node. The bypassing procedure is performed according to the description given in Section 4.4. At the QNE Ingress, the end-to-end RESERVE message is marked, i.e., modifying the QoS-NSLP default NSLPID value to another NSLPID predefined value that will be used by the GIST message that carries the end-to-end RESERVE message to bypass the QNE Interior nodes. Before generating an intra-domain tear RESERVE, the RMD-QOSM has to release the requested RMD-QOSM bandwidth from the RMD traffic class state maintained at the QNE Ingress. This can be achieved by identifying the traffic class (PHB) and then subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The <Time Lag> is used as explained in the introductory part of Section 4.6.1.5. QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress) NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | --->| | | RESERVE | |------------------------------------------------------------>| |RESERVE(RMD-QSPEC:Tear=1) | | |------------------->| | | | |RESERVE(RMD-QSPEC:Tear=1) | | |------------------->| | | | RESERVE(RMD-QSPEC:Tear=1) | | |------------------->| | | | RESERVE | | | |--> Figure 11: Explicit release triggered by RESERVE used by the RMD-QOSM After that, the REQUIRED bandwidth is released from the RMD-QOSM traffic class state at the QNE Ingress, an intra-domain RESERVE (RMD- QOSM) message has to be generated. The intra-domain RESERVE (RMD- QSPEC) message MUST include an <RMD QoS object combination> field and a PHR container, (i.e., "PHR_Release_Request") and it MAY include a PDR container, (i.e., PDR_Release_Request). An example of this operation can be seen in Figure 11.
Most of the non-default values of the objects contained in the tear intra-domain RESERVE message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1. The following objects are set differently (see the QoS-NSLP-RMF API described in [RFC5974]): * The <RII> object MUST NOT be included in this message. This is because the QNE Ingress node does not need to receive a response from the QNE Egress node; * if the release procedure is not applied for the RMD modification of aggregated reservation procedure (see Section 4.6.1.4), then the <TEAR> flag MUST be set to ON; * the PHR resource units MUST be included into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD- QOSM <QoS Desired>; * the value of the <Admitted Hops> parameter MUST be set to "1"; * the value of the <Time Lag> parameter of the PHR container is calculated by the RMD-QOSM functionality (see Section 4.6.1.5) the value of the <Control Type> parameter of the PHR container is set to "18" (i.e., PHR_Release_Request). Any QNE Interior node that receives the combination of the RMD-QOSM <QoS Desired> object and the "PHR_Release_Request" control information container MUST identify the traffic class (PHB) and release the requested resources included in the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter. This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The value of the <Time Lag> parameter of the "PHR_Release_Request" container is used during the release procedure as explained in the introductory part of Section 4.6.1.5. The intra-domain tear RESERVE (RMD-QSPEC) message is received and processed by the QNE Egress node. The RMD-QOSM <QoS Desired> and the "PHR RMD-QOSM control" container (and if available the "PDR Container") are read and processed by the RMD QoS node. The value of the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> and the value of the <Time Lag> field of the PHR container MUST be used by the RMD release procedure.
This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field value of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The end-to-end RESERVE message is forwarded by the next hop (i.e., the QNE Egress) only if the intra-domain tear RESERVE (RMD-QSPEC) message arrives at the QNE Egress node. Furthermore, the QNE Egress MUST stop the marking process that was used to bypass the QNE Interior nodes by reassigning the QoS-NSLP default NSLPID value to the end-to-end RESERVE message (see Section 4.4). Note that when the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY start an RMD modification procedure (see Section 4.6.1.4) that uses the explicit release procedure, described above in this subsection. Note that if the complete bandwidth associated with the aggregated reservation maintained at the QNE Ingress has to be released, then the <TEAR> flag MUST be set to ON. Otherwise, the <TEAR> flag MUST be set to OFF, see Section 4.6.1.4.4.6.1.5.2. Triggered by a Marked RESPONSE or NOTIFY Message
This RMD explicit release procedure can be triggered by either an intra-domain RESPONSE message with a PDR container carrying among others the <M> and <S> parameters with values <M>=1 and <S>=0 (see Section 4.6.1.2), an intra-domain (refresh) RESPONSE message carrying a PDR container with <M>=1 and <S>=1 (see Section 4.6.1.6.1), or an end-to-end NOTIFY message (see Section 4.6.1.6) with an <INFO-SPEC> object with the following values: Error severity class: Informational Error code value: Congestion situation When the aggregated intra-domain QoS-NSLP operational states are used, an end-to-end NOTIFY message used to trigger an RMD release procedure MAY contain a PDR container that carries an <M> and an <S> with values <M>=1 and <S>=1, and a bandwidth value in the <PDR Bandwidth> parameter included in a "PDR_Refresh_Report" or "PDR_Congestion_Report" container. Note that in all explicit release procedures, before generating an intra-domain tear RESERVE, the RMD-QOSM has to release the requested RMD-QOSM bandwidth from the RMD traffic class state maintained at the QNE Ingress. This can be achieved by identifying the traffic class (PHB) and then subtracting the amount of RMD traffic class requested
resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. Figure 12 shows the situation that the intra-domain tear RESERVE is generated after being triggered by either an intra-domain (refresh) RESPONSE message that carries a PDR container with <M>=1 and <S>=1 or by an end-to-end NOTIFY message that does not carry a PDR container, but an <INFO-SPEC> object. The error code values carried by this NOTIFY message are: Error severity class: Informational Error code value: Congestion situation Most of the non-default values of the objects contained in the tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1. The following objects MUST be used and/or set differently (see the QoS-NSLP-RMF described in [RFC5974]): * the value of the <M> parameter of the PHR container MUST be set to "1". * the value of the <S> parameter of the "PHR container" MUST be set to "1". * the RESERVE message MAY include a PDR container. Note that this is needed if a bidirectional scenario is used; see Section 4.6.2. QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress) NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | | NOTIFY | | | |<-------------------------------------------------------| |RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) | | | ---------------->|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) | | | | | | |----------------->| | | | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) | | |----------------->| Figure 12: Basic operation during RMD-explicit release procedure triggered by NOTIFY used by the RMD-QOSM Note that if the values of the <M> and <S> parameters included in the PHR container carried by a intra-domain tear RESERVE(RMD-QOSM) are set as ((<M>=0 and <S>=1) or (<M>=0 and <S>=0) or (<M>=1 and <S>=1)),
then the <Max Admitted Hops> value SHOULD NOT be compared to the <Admitted Hops> value and the value of the <K> field MUST NOT be set. Any QNE Edge or QNE Interior node that receives the intra-domain tear RESERVE MUST check the <K> field included in the PHR container. If the <K> field is "0", then the traffic class state (PHB) has to be identified, using the <PHB Class> parameter, and the requested resources included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter have to be released. This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The value of the <Time Lag> parameter of the PHR field is used during the release procedure, as explained in the introductory part of Section 4.6.1.5. Afterwards, the QNE Egress node MUST terminate the tear intra-domain RESERVE(RMD-QSPEC) message. The RMD-specific release procedure that is triggered by an intra- domain RESPONSE message with an <M>=1 and <S>=0 PDR container (see Section 4.6.1.2) generates an intra-domain tear RESERVE message that uses the combination of the <Max Admitted Hops> and <Admitted_Hops> fields to calculate and specify when the <K> value carried by the "PHR Container" can be set. When the <K> field is set, then the "PHR Container" and the RMD-QOSM <QoS Desired> carried by an intra-domain tear RESERVE MUST NOT be processed. The RMD-specific explicit release procedure that uses the combination of <Max Admitted Hops>, <Admitted_Hops> and <K> fields to release resources/bandwidth in only a part of the RMD domain, is denoted as RMD partial release procedure. This explicit release procedure can be used, for example, during unsuccessful reservation (see Section 4.6.1.2). When the RMD- QOSM/QoS-NSLP signaling model functionality of a QNE Ingress node receives a PDR container with values <M>=1 and <S>=0, of type "PDR_Reservation_Report", it MUST start an RMD partial release procedure. In this situation, after the REQUIRED bandwidth is released from the RMD-QOSM traffic class state at the QNE Ingress, an intra-domain RESERVE (RMD-QOSM) message has to be generated. An example of this operation can be seen in Figure 13. Most of the non-default values of the objects contained in the tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1.
The following objects MUST be used and/or set differently:
* the value of the <M> parameter of the PHR container MUST be set to
"1".
* the RESERVE message MAY include a PDR container.
* the value of the <Max Admitted Hops> carried by the "PHR
Container" MUST be set equal to the <Max Admitted Hops> value
carried by the "PDR Container" (with <M>=1 and <S>=0) carried by
the received intra-domain RESPONSE message that triggers the
release procedure.
Any QNE Edge or QNE Interior node that receives the intra-domain tear
RESERVE has to check the value of the <K> field in the "PHR
Container" before releasing the requested resources.
If the value of the <K> field is "1", then all the QNEs located
downstream, including the QNE Egress, MUST NOT process the carried
"PHR Container" and the RMD-QOSM <QoS Desired> object by the intra-
domain tearing RESERVE.
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
Node that marked
PHR_Resource_Request
<PHR> object
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | | |
| RESPONSE (RMD-QSPEC: M=1) | |
|<------------------------------------------------------------|
RESERVE(RMD-QSPEC: Tear=1, M=1, <Admit Hops>=<Max Admitted Hops>, K=0)
|------------------->| | |
| |RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) |
| |------------------>| |
| | RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)|
| | |------------------->|
| | | |
Figure 13: Basic operation during RMD explicit release procedure
triggered by RESPONSE used by the RMD-QOSM
If the <K> field value is "0", any QNE Edge or QNE Interior node that
receives the intra-domain tear RESERVE can release the resources by
subtracting the amount of RMD traffic class requested resources,
included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC
<TMOD-1> parameter, from the total reserved amount of resources
stored in the RMD traffic class state. The value of the <Time Lag> parameter of the PHR field is used during the release procedure as explained in the introductory part of Section 4.6.1.5. Furthermore, the QNE MUST perform the following procedures. If the values of the <M> and <S> parameters included in the "PHR_Release_Request" PHR container are (<M=1> and <S>=0) then the <Max Admitted Hops> value MUST be compared with the calculated <Admitted Hops> value. Note that each time that the intra-domain tear RESERVE is processed and before being forwarded by a QNE, the <Admitted Hops> value included in the PHR container is increased by one. When these two values are equal, the intra-domain RESERVE(RMD-QSPEC) that is forwarded further towards the QNE Egress MUST set the <K> value of the carried "PHR Container" to "1". The reason for doing this is that the QNE node that is currently processing this message was the last QNE node that successfully processed the RMD-QOSM <QoS Desired>) and PHR container of its associated initial reservation request (i.e., initial intra-domain RESERVE(RMD-QSPEC) message). Its next QNE downstream node was unable to successfully process the initial reservation request; therefore, this QNE node marked the <M> and <Hop_U> parameters of the "PHR_Resource_Request". Finally, note that the QNE Egress node MUST terminate the intra- domain RESERVE(RMD-QSPEC) message. Moreover, note that the above described RMD partial release procedure applies to the situation that the QNE Edges maintain a per-flow QoS- NSLP reservation state. When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states and a severe congestion occurs, then the QNE Ingress MAY receive an end-to-end NOTIFY message (see Section 4.6.1.6) with a PDR container that carries the <M>=0 and <S>=1 fields and a bandwidth value in the <PDR Bandwidth> parameter included in a "PDR_Congestion_Report" container. Furthermore, the same end-to-end NOTIFY message carries an <INFO-SPEC> object with the following values: Error severity class: Informational Error code value: Congestion situation
The end-to-end session associated with this NOTIFY message maintains the BOUND-SESSION-ID of the bound aggregated session; see Section 4.3.1. The RMD-QOSM at the QNE Ingress MUST start an RMD modification procedures (see Section 4.6.1.4) that uses the RMD explicit release procedure, described above in this section. In particular, the RMD explicit release procedure releases the bandwidth value included in the <PDR Bandwidth> parameter, within the "PDR_Congestion_Report" container, from the reserved bandwidth associated with the aggregated intra-domain QoS-NSLP operational state.4.6.1.6. Severe Congestion Handling
This section describes the operation of the RMD-QOSM when a severe congestion occurs within the Diffserv domain. When a failure in a communication path, e.g., a router or a link failure occurs, the routing algorithms will adapt to failures by changing the routing decisions to reflect changes in the topology and traffic volume. As a result, the rerouted traffic will follow a new path, which MAY result in overloaded nodes as they need to support more traffic. This MAY cause severe congestion in the communication path. In this situation, the available resources, are not enough to meet the REQUIRED QoS for all the flows along the new path. Therefore, one or more flows SHOULD be terminated, or forwarded in a lower priority queue. Interior nodes notify Edge nodes by data marking or marking the refresh messages.4.6.1.6.1. Severe Congestion Handling by the RMD-QOSM Refresh Procedure
This procedure applies to all RMD scenarios that use an RMD refresh procedure. The QoS-NSLP and RMD are able to cope with congested situations using the refresh procedure; see Section 4.6.1.3. If the refresh is not successful in an QNE Interior node, Edge nodes are notified by setting <S>=1 (<M>=1) marking the refresh messages and by setting the <O> field in the "PHR_Refresh_Update" container, carried by the intra-domain RESERVE message. Note that the overload situation can be detected by using the example given in Appendix A.1. In this situation, when the given signaled_overload_rate parameter given in Appendix A.1 is higher than 0, the value of the <Overload> field is set to "1". The calculation
of this is given in Appendix A.1 and denoted as the signaled_overload_rate parameter. The flows can be terminated by the RMD release procedure described in Section 4.6.1.5. The intra-domain RESPONSE message that is sent by the QNE Egress towards the QNE Ingress will contain a PDR container with a Parameter ID = 26, i.e., "PDR_Congestion_Report". The values of the <M>, <S>, and <O> fields of this container SHOULD be set equal to the values of the <M>, <S>, and <O> fields, respectively, carried by the "PHR_Refresh_Update" container. Part of the flows, corresponding to the <O>, are terminated, or forwarded in a lower priority queue. The flows can be terminated by the RMD release procedure described in Section 4.6.1.5. Furthermore, note that the above functionalities also apply to the scenario in which the QNE Edge nodes maintain either per-flow QoS- NSLP reservation states or aggregated QoS-NSLP reservation states. In general, relying on the soft state refresh mechanism solves the congestion within the time frame of the refresh period. If this mechanism is not fast enough, additional functions SHOULD be used, which are described in Section 4.6.1.6.2.4.6.1.6.2. Severe Congestion Handling by Proportional Data Packet Marking
This severe congestion handling method requires the following functionalities.4.6.1.6.2.1. Operation in the Interior Nodes The detection and marking/re-marking functionality described in this section applies to NSIS-aware and NSIS-unaware nodes. This means however, that the "not NSIS-aware" nodes MUST be configured such that they can detect the congestion/severe congestion situations and re- mark packets in the same way the "NSIS-aware" nodes do. The Interior node detecting severe congestion re-marks data packets passing the node. For this re-marking, two additional DSCPs can be allocated for each traffic class. One DSCP MAY be used to indicate that the packet passed a congested node. This type of DSCP is denoted in this document as an "affected DSCP" and is used to indicate that a packet passed through a severe congested node. The use of this DSCP type eliminates the possibility that, e.g., due to flow-based ECMP-enabled (Equal Cost Multiple Paths) routing, the Egress node either does not detect packets passed a severely
congested node or erroneously detects packets that actually did not pass the severely congested node. Note that this type of DSCP MUST only be used if all the nodes within the RMD domain are configured to use it. Otherwise, this type of DSCP MUST NOT be applied. The other DSCP MUST be used to indicate the degree of congestion by marking the bytes proportionally to the degree of congestion. This type of DSCP is denoted in this document as "encoded DSCP". In this document, note that the terms "marked packets" or "marked bytes" refer to the "encoded DSCP". The terms "unmarked packets" or "unmarked bytes" represent the packets or the bytes belonging to these packets that their DSCP is either the "affected DSCP" or the original DSCP. Furthermore, in the algorithm described below, it is considered that the router MAY drop received packets. The counting/measuring of marked or unmarked bytes described in this section is accomplished within measurement periods. All nodes within an RMD domain use the same, fixed-measurement interval, say T seconds, which MUST be preconfigured. It is RECOMMENDED that the total number of additional (local and experimental) DSCPs needed for severe congestion handling within an RMD domain SHOULD be as low as possible, and it SHOULD NOT exceed the limit of 8. One possibility to reduce the number of used DSCPs is to use only the "encoded DSCP" and not to use "affected DSCP" marking. Another possible solution is, for example, to allocate one DSCP for severe congestion indication for each of the AF classes that can be supported by RMD-QOSM. An example of a re-marking procedure can be found in Appendix A.1.4.6.1.6.2.2. Operation in the Egress Nodes When the QNE Edges maintain a per-flow intra-domain QoS-NSLP operational state (see Sections 4.3.2 and 4.3.3), then the following procedure is followed. The QNE Egress node applies a predefined policy to solve the severe congestion situation, by selecting a number of inter-domain (end-to-end) flows that SHOULD be terminated or forwarded in a lower priority queue. When the RMD domain does not use the "affected DSCP" marking, the Egress MUST generate an Ingress/Egress pair aggregated state, for each Ingress and for each supported PHB. This is because the Edges MUST be able to detect in which Ingress/Egress pair a severe congestion occurs. This is because, otherwise, the QNE Egress will not have any information on which flows or groups of flows were affected by the severe congestion.
When the RMD domain supports the "affected DSCP" marking, the Egress is able to detect all flows that are affected by the severe congestion situation. Therefore, when the RMD domain supports the "affected DSCP" marking, the Egress MAY not generate and maintain the Ingress/Egress pair aggregated reservation states. Note that these aggregated reservation states MAY not be associated with aggregated intra-domain QoS-NSLP operational states. The Ingress/Egress pair aggregated reservation state can be derived by detecting which flows are using the same PHB and are sent by the same Ingress (via the per-flow end-to-end QoS-NSLP states). Some flows, belonging to the same PHB traffic class might get other priority than other flows belonging to the same PHB traffic class. This difference in priority can be notified to the Egress and Ingress nodes by either the RESERVE message that carries the QSPEC associated with the end-to-end QoS Model, e.g.,, <Preemption Priority> and <Defending Priority> parameter or using a locally defined policy. The priority value is kept in the reservation states (see Section 4.3), which might be used during admission control and/or severe congestion handling procedures. The terminated flows are selected from the flows having the same PHB traffic class as the PHB of the marked (as "encoded DSCP") and "affected DSCP" (when applied in the complete RMD domain) packets and (when the Ingress/Egress pair aggregated states are available) that belong to the same Ingress/Egress pair aggregate. For flows associated with the same PHB traffic class, the priority of the flow plays a significant role. An example of calculating the number of flows associated with each priority class that have to be terminated is explained in Appendix A.2. For the flows (sessions) that have to be terminated, the QNE Egress node generates and sends an end-to-end NOTIFY message to the QNE Ingress node (its upstream stateful QoS-NSLP peer) to indicate the severe congestion in the communication path. The non-default values of the objects contained in the NOTIFY message MUST be set by the QNE Egress node as follows (see QoS-NSLP-RMF API described in [RFC5974]): * the values of the <INFO-SPEC> object is set by the standard QoS- NSLP protocol functions. * the <INFO-SPEC> object MUST include information that notifies that the end-to-end flow MUST be terminated. This information is as follows:
Error severity class: Informational
Error code value: Congestion situation
When the QNE Edges maintain a per-aggregate intra-domain QoS-NSLP
operational state (see Section 4.3.1), the QNE Edge has to
calculate, per each aggregate intra-domain QoS-NSLP operational
state, the total bandwidth that has to be terminated in order to
solve the severe congestion. The total bandwidth to be released
is calculated in the same way as in the situation in which the QNE
Edges maintain per-flow intra-domain QoS-NSLP operational states.
Note that for the aggregated sessions that are affected, the QNE
Egress node generates and sends one end-to-end NOTIFY message to
the QNE Ingress node (its upstream stateful QoS-NSLP peer) to
indicate the severe congestion in the communication path. Note
that this end-to-end NOTIFY message is associated with one of the
end-to-end sessions that is bound to the aggregated intra-domain
QoS-NSLP operational state.
The non-default values of the objects contained in the NOTIFY
message MUST be set by the QNE Egress node in the same way as the
ones used by the end-to-end NOTIFY message described above for the
situation that the QNE Egress maintains a per-flow intra-domain
operational state. In addition to this, the end-to-end NOTIFY
MUST carry the RMD-QSPEC, which contains a PDR container with a
Parameter ID = 26, i.e., "PDR_Congestion_Report". The value of
the <S> SHOULD be set. Furthermore, the value of the <PDR
Bandwidth> parameter MUST contain the bandwidth associated with
the aggregated QoS-NSLP operational state, which has to be
released.
Furthermore, the number of end-to-end sessions that have to be
terminated will be calculated as in the situation that the QNE
Edges maintain per-flow intra-domain QoS-NSLP operational states.
Similarly for each, to be terminated, ongoing flow, the Egress
will notify the Ingress in the same way as in the situation that
the QNE Edges maintain per-flow intra-domain QoS-NSLP operational
states.
Note that the QNE Egress SHOULD restore the original <DSCP> values
of the re-marked packets; otherwise, multiple actions for the same
event might occur. However, this value MAY be left in its re-
marking form if there is an SLA agreement between domains that a
downstream domain handles the re-marking problem.
An example of a detailed severe congestion operation in the Egress
Nodes can be found in Appendix A.2.
4.6.1.6.2.3. Operation in the Ingress Nodes Upon receiving the (end-to-end) NOTIFY message, the QNE Ingress node resolves the severe congestion by a predefined policy, e.g., by refusing new incoming flows (sessions), terminating the affected and notified flows (sessions), and blocking their packets or shifting them to an alternative RMD traffic class (PHB). This operation is depicted in Figure 14, where the QNE Ingress, for each flow (session) to be terminated, receives a NOTIFY message that carries the "Congestion situation" error code. When the QNE Ingress node receives the end-to-end NOTIFY message, it associates this NOTIFY message with its bound intra-domain session (see Sections 4.3.2 and 4.3.3) via the BOUND-SESSION-ID information included in the end-to-end per-flow QoS-NSLP state. The QNE Ingress uses the operation described in Section 4.6.1.5.2 to terminate the intra-domain session. QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress) user | | | | data | user data | | | ------>|----------------->| user data | user data | | |---------------->S(# marked bytes) | | | S----------------->| | | S(# unmarked bytes)| | | S----------------->|Term. | NOTIFY S |flow? |<-----------------|-----------------S------------------|YES |RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) S | | ---------------->|RESERVE(RMD-QSPEC:T=1,M=1,S=1) | | | S | | |---------------->S | | | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) | | S----------------->| Figure 14: RMD severe congestion handling Note that the above functionality applies to the RMD reservation- based (see Section 4.3.3) and to both measurement-based admission control methods (i.e., congestion notification based on probing and the NSIS measurement-based admission control; see Section 4.3.2). In the case that the QNE Edges support aggregated intra-domain QoS- NSLP operational states, the following actions take place. The QNE Ingress MAY receive an end-to-end NOTIFY message with a PDR container that carries an <S> marked and a bandwidth value in the <PDR
Bandwidth> parameter included in a "PDR_Congestion_Report" container. Furthermore, the same end-to-end NOTIFY message carries an <INFO- SPEC> object with the "Congestion situation" error code. When the QNE Ingress node receives this end-to-end NOTIFY message, it associates the NOTIFY message with the aggregated intra-domain QoS- NSLP operational state via the BOUND-SESSION-ID information included in the end-to-end per-flow QoS-NSLP operational state, see Section 4.3.1. The RMD-QOSM at the QNE Ingress node by using the total bandwidth value to be released included in the <PDR Bandwidth> parameter MUST reduce the bandwidth associated and reserved by the RMD aggregated session. This is accomplished by triggering the RMD modification for aggregated reservations procedure described in Section 4.6.1.4. In addition to the above, the QNE Ingress MUST select a number of inter-domain (end-to-end) flows (sessions) that MUST be terminated. This is accomplished in the same way as in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states. The terminated end-to-end sessions are selected from the end-to-end sessions bound to the aggregated intra-domain QoS-NSLP operational state. Note that the end-to-end session associated with the received end-to-end NOTIFY message that notified the severe congestion MUST also be selected for termination. For the flows (sessions) that have to be terminated, the QNE Ingress node generates and sends an end-to-end NOTIFY message upstream towards the sender (QNI). The values carried by this message are: * the values of the <INFO-SPEC> object set by the standard QoS-NSLP protocol functions. * the <INFO-SPEC> object MUST include information that notifies that the end-to-end flow MUST be terminated. This information is as follows: Error severity class: Informational Error code value: Congestion situation4.6.1.7. Admission Control Using Congestion Notification Based on Probing
The congestion notification function based on probing can be used to implement a simple measurement-based admission control within a Diffserv domain. At Interior nodes along the data path, congestion
notification thresholds are set in the measurement-based admission control function for the traffic belonging to different PHBs. These Interior nodes are not NSIS-aware nodes.4.6.1.7.1. Operation in Ingress Nodes
When an end-to-end reservation request (RESERVE) arrives at the Ingress node (QNE), see Figure 15, it is processed based on the procedures defined by the end-to-end QoS Model. The <DSCP> field of the GIST datagram message that is used to transport this probe RESERVE message, SHOULD be marked with the same value of DSCP as the data path packets associated with the same session. In this way, it is ensured that the end-to-end RESERVE (probe) packet passed through the node that it is congested. This feature is very useful when ECMP-based routing is used to detect only flows that are passing through the congested router. When a (end-to-end) RESPONSE message is received by the Ingress node,it will be processed based on the procedures defined by the end- to-end QoS Model.4.6.1.7.2. Operation in Interior nodes
These Interior nodes do not need to be NSIS-aware nodes and they do not need to process the NSIS functionality of NSIS messages. Note that the "not NSIS-aware" nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way the "NSIS-aware" nodes do. Using standard functionalities, congestion notification thresholds are set for the traffic that belongs to different PHBs (see Section 4.3.2). The end-to-end RESERVE message, see Figure 15, is used as a probe packet. The <DSCP> field of all data packets and of the GIST message carrying the RESERVE message will be re-marked when the corresponding "congestion notification" threshold is exceeded (see Section 4.3.2). Note that when the data rate is higher than the congestion notification threshold, the data packets are also re-marked. An example of the detailed operation of this procedure is given in Appendix A.2.4.6.1.7.3. Operation in Egress Nodes
As emphasized in Section 4.6.1.6.2.2, the Egress node, by using the per-flow end-to-end QoS-NSLP states, can derive which flows are using the same PHB and are sent by the same Ingress.
For each Ingress, the Egress SHOULD generate an Ingress/Egress pair aggregated (RMF) reservation state for each supported PHB. Note that this aggregated reservation state does not require that an aggregated intra-domain QoS-NSLP operational state is needed also. Appendix A.4 contains an example of how and when a (probe) RESERVE message that arrives at the Egress is admitted or rejected. If the request is rejected, then the Egress node SHOULD generate an (end-to-end) RESPONSE message to notify that the reservation is unsuccessful. In particular, it will generate an <INFO-SPEC> object of: Error severity class: Transient Failure Error code value: Reservation failure The QSPEC that was carried by the end-to-end RESERVE that belongs to the same session as this end-to-end RESPONSE is included in this message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values. The <E> flag associated with the <QoS Reserved> object and the <E> flag associated with local RMD-QSPEC <TMOD-1> parameter are also set. This RESPONSE message will be sent to the Ingress node and it will be processed based on the end-to-end QoS Model. Note that the QNE Egress SHOULD restore the original <DSCP> values of the re-marked packets; otherwise, multiple actions for the same event might occur. However, this value MAY be left in its re-marking form if there is an SLA agreement between domains that a downstream domain handles the re-marking problem. Note that the break <B> flag carried by the end-to-end RESERVE message MUST NOT be set.
QNE(Ingress) Interior Interior QNE(Egress) (not NSIS aware) (not NSIS aware) user | | | | data | user data | | | ------>|----------------->| user data | | | |---------------->| user data | | | |----------------->| user | | | | data | user data | | | ------>|----------------->| user data | user data | | |---------------->S(# marked bytes) | | | S----------------->| | | S(# unmarked bytes)| | | S----------------->| | | S | RESERVE | | S | ------->| | S | |----------------------------------->S | | | RESERVE(re-marked DSCP in GIST) | | S----------------->| | |RESPONSE(unsuccessful INFO-SPEC) | |<------------------------------------------------------| RESPONSE(unsuccessful INFO-SPEC) | | <------| | | | Figure 15: Using RMD congestion notification function for admission control based on probing
(page 73 continued on part 4)