tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5977

 
 
 

RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv

Part 3 of 5, p. 46 to 73
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 46 
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

Top      Up      ToC       Page 47 
   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).

Top      Up      ToC       Page 48 
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.

Top      Up      ToC       Page 49 
   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

Top      Up      ToC       Page 50 
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.

Top      Up      ToC       Page 51 
   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.

Top      Up      ToC       Page 52 
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

Top      Up      ToC       Page 53 
      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).

Top      Up      ToC       Page 54 
   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,

Top      Up      ToC       Page 55 
      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

Top      Up      ToC       Page 56 
   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].

Top      Up      ToC       Page 57 
   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.

Top      Up      ToC       Page 58 
   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.

Top      Up      ToC       Page 59 
   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

Top      Up      ToC       Page 60 
   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)),

Top      Up      ToC       Page 61 
   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.

Top      Up      ToC       Page 62 
   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

Top      Up      ToC       Page 63 
   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

Top      Up      ToC       Page 64 
   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

Top      Up      ToC       Page 65 
   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

Top      Up      ToC       Page 66 
   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.

Top      Up      ToC       Page 67 
   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:

Top      Up      ToC       Page 68 
        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.

Top      Up      ToC       Page 69 
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

Top      Up      ToC       Page 70 
   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 situation

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

Top      Up      ToC       Page 71 
   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.

Top      Up      ToC       Page 72 
   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.

Top      Up      ToC       Page 73 
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)

Next RFC Part