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 4 of 5, p. 73 to 100
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 73 
4.6.2.  Bidirectional Operation

   This section describes the basic bidirectional operation and sequence
   of events/triggers of the RMD-QOSM.  The following basic operation
   cases are distinguished:

      * Successful and unsuccessful reservation (Section 4.6.2.1);
      * Refresh reservation (Section 4.6.2.2);
      * Modification of aggregated reservation (Section 4.6.2.3);
      * Release procedure (Section 4.6.2.4);
      * Severe congestion handling (Section 4.6.2.5);
      * Admission control using congestion notification based on probing
       (Section 4.6.2.6).

   It is important to emphasize that the content of this section is used
   for the specification of the following RMD-QOSM/QoS-NSLP signaling
   schemes, when basic unidirectional operation is assumed:

   *  "per-flow congestion notification based on probing";

Top      Up      ToC       Page 74 
   *  "per-flow RMD NSIS measurement-based admission control",

   *  "per-flow RMD reservation-based" in combination with the "severe
      congestion handling by the RMD-QOSM refresh" procedure;

   *  "per-flow RMD reservation-based" in combination with the "severe
      congestion handling by proportional data packet marking"
      procedure;

   *  "per-aggregate RMD reservation-based" in combination with the
      "severe congestion handling by the RMD-QOSM refresh" procedure;

   *  "per-aggregate RMD reservation-based" in combination with the
      "severe congestion handling by proportional data packet marking"
      procedure.

   For more details, please see Section 3.2.3.

   In particular, the functionality described in Sections 4.6.2.1,
   4.6.2.2, 4.6.2.3, 4.6.2.4, and 4.6.2.5 applies to the RMD
   reservation-based and NSIS measurement-based admission control
   methods.  The described functionality in Section 4.6.2.6 applies to
   the admission control procedure that uses the congestion notification
   based on probing.  The QNE Edge nodes maintain either per-flow QoS-
   NSLP operational and reservation states or aggregated QoS-NSLP
   operational and reservation states.

   RMD-QOSM assumes that asymmetric routing MAY be applied in the RMD
   domain.  Combined sender-receiver initiated reservation cannot be
   efficiently done in the RMD domain because upstream NTLP states are
   not stored in Interior routers.

   Therefore, the bidirectional operation SHOULD be performed by two
   sender-initiated reservations (sender&sender).  We assume that the
   QNE Edge nodes are common for both upstream and downstream
   directions, therefore, the two reservations/sessions can be bound at
   the QNE Edge nodes.  Note that if this is not the case, then the
   bidirectional procedure could be managed and maintained by nodes
   located outside the RMD domain, by using other procedures than the
   ones defined in RMD-QOSM.

   This (intra-domain) bidirectional sender&sender procedure can then be
   applied between the QNE Edge (QNE Ingress and QNE Egress) nodes of
   the RMD QoS signaling model.  In the situation in which a security
   association exists between the QNE Ingress and QNE Egress nodes (see
   Figure 15), and the QNE Ingress node has the REQUIRED <Peak Data
   Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters for
   both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress

Top      Up      ToC       Page 75 
   towards QNE Ingress, then the QNE Ingress MAY include both <Peak Data
   Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters (needed
   for both directions) into the RMD-QSPEC within a RESERVE message.  In
   this way, the QNE Egress node is able to use the QoS parameters
   needed for the "Egress towards Ingress" direction (QoS-2).  The QNE
   Egress is then able to create a RESERVE with the right QoS parameters
   included in the QSPEC, i.e., RESERVE (QoS-2).  Both directions of the
   flows are bound by inserting <BOUND-SESSION-ID> objects at the QNE
   Ingress and QNE Egress, which will be carried by bound end-to-end
   RESERVE messages.

     |------ RESERVE (QoS-1, QoS-2)----|
     |                                 V
     |           Interior/stateless QNEs
                 +---+     +---+
        |------->|QNE|-----|QNE|------
        |        +---+     +---+     |
        |                            V
      +---+                        +---+
      |QNE|                        |QNE|
      +---+                        +---+
         ^                           |
      |  |       +---+     +---+     V
      |  |-------|QNE|-----|QNE|-----|
      |          +---+     +---+
   Ingress/                         Egress/
   stateful  QNE                    stateful QNE
                                     |
   <--------- RESERVE (QoS-2) -------|

   Figure 16: The intra-domain bidirectional reservation scenario
              in the RMD domain

   Note that it is RECOMMENDED that the QNE implementations of RMD-QOSM
   process the QoS-NSLP signaling messages with a higher priority than
   data packets.  This can be accomplished as described in Section 3.3.4
   in [RFC5974] and the QoS-NSLP-RMF API [RFC5974].

   A bidirectional reservation, within the RMD domain, is indicated by
   the PHR <B> and PDR <B> flags, which are set in all messages.  In
   this case, two <BOUND-SESSION-ID> objects SHOULD be used.

   When the QNE Edges maintain per-flow intra-domain QoS-NSLP
   operational states, the end-to-end RESERVE message carries two BOUND-
   SESSION-IDs.  One BOUND-SESSION-ID carries the SESSION-ID of the
   tunneled intra-domain (per-flow) session that is using a Binding_Code
   with value set to code (Tunneled and end-to-end sessions).  Another

Top      Up      ToC       Page 76 
   BOUND-SESSION-ID carries the SESSION-ID of the bound bidirectional
   end-to-end session.  The Binding_Code associated with this BOUND-
   SESSION-ID is set to code (Bidirectional sessions).

   When the QNE Edges maintain aggregated intra-domain QoS-NSLP
   operational states, the end-to-end RESERVE message carries two BOUND-
   SESSION-IDs.  One BOUND-SESSION-ID carries the SESSION-ID of the
   tunneled aggregated intra-domain session that is using a Binding_Code
   with value set to code (Aggregated sessions).  Another BOUND-SESSION-
   ID carries the SESSION-ID of the bound bidirectional end-to-end
   session.  The Binding_Code associated with this BOUND-SESSION-ID is
   set to code (Bidirectional sessions).

   The intra-domain and end-to-end QoS-NSLP operational states are
   initiated/modified depending on the binding type (see Sections 4.3.1,
   4.3.2, and 4.3.3).

   If no security association exists between the QNE Ingress and QNE
   Egress nodes, the bidirectional reservation for the sender&sender
   scenario in the RMD domain SHOULD use the scenario specified in
   [RFC5974] as "bidirectional reservation for sender&sender scenario".
   This is because in this scenario, the RESERVE message sent from the
   QNE Ingress to QNE Egress does not have to carry the QoS parameters
   needed for the "Egress towards Ingress" direction (QoS-2).

   In the following sections, it is considered that the QNE Edge nodes
   are common for both upstream and downstream directions and therefore,
   the two reservations/sessions can be bound at the QNE Edge nodes.
   Furthermore, it is considered that a security association exists
   between the QNE Ingress and QNE Egress nodes, and the QNE Ingress
   node has the REQUIRED <Peak Data Rate-1 (p)> value of the local RMD-
   QSPEC <TMOD-1> parameters for both directions, i.e., QNE Ingress
   towards QNE Egress and QNE Egress towards QNE Ingress.

   According to Section 3.2.3, it is specified that only the "per-flow
   RMD reservation-based" in combination with the "severe congestion
   handling by proportional data packet marking" scheme MUST be
   implemented within one RMD domain.  However, all RMD QNEs supporting
   this specification MUST support the combination the "per-flow RMD
   reservation-based" in combination with the "severe congestion
   handling by proportional data packet marking" scheme.  If the RMD
   QNEs support more RMD-QOSM schemes, then the operator of that RMD
   domain MUST preconfigure all the QNE Edge nodes within one domain
   such that the <SCH> field included in the "PHR Container" (Section
   4.1.2) and the "PDR Container" (Section 4.1.3) will always use the
   same value, such that within one RMD domain, only one of the below
   described RMD-QOSM schemes is used at a time.

Top      Up      ToC       Page 77 
   All QNE nodes located within the RMD domain MUST read and interpret
   the <SCH> field included in the "PHR Container" before processing all
   the other <PHR Container> payload fields.  Moreover, all QNE Edge
   nodes located at the boarder of the RMD domain, MUST read and
   interpret the <SCH> field included in the "PDR container" before
   processing all the other <PDR Container> payload fields.

4.6.2.1.  Successful and Unsuccessful Reservations

   This section describes the operation of the RMD-QOSM where an RMD
   Intra-domain bidirectional reservation operation, see Figure 16 and
   Section 4.6.2, is either successfully or unsuccessfully accomplished.

   The bidirectional successful reservation is similar to a combination
   of two unidirectional successful reservations that are accomplished
   in opposite directions, see Figure 17.  The main differences of the
   bidirectional successful reservation procedure with the combination
   of two unidirectional successful reservations accomplished in
   opposite directions are as follows.  Note also that the intra-domain
   and end-to-end QoS-NSLP operational states generated and maintained
   by the end-to-end RESERVE messages contain, compared to the
   unidirectional reservation scenario, a different BOUND-SESSION-ID
   data structure (see Sections 4.3.1, 4.3.2, and 4.3.3).  In this
   scenario, the intra-domain RESERVE message sent by the QNE Ingress
   node towards the QNE Egress node is denoted in Figure 17 as RESERVE
   (RMD-QSPEC): "forward".  The main differences between the intra-
   domain RESERVE (RMD-QSPEC): "forward" message used for the
   bidirectional successful reservation procedure and a RESERVE (RMD-
   QSPEC) message used for the unidirectional successful reservation are
   as follows (see the QoS-NSLP-RMF API described in [RFC5974]):

   *  the <RII> object MUST NOT be included in the message.  This is
      because no RESPONSE message is REQUIRED.

   *  the <B> bit of the PHR container indicates a bidirectional
      reservation and it MUST be set to "1".

   *  the PDR container is also included in the RESERVE(RMD-QSPEC):
      "forward" message.  The value of the Parameter ID is "20", i.e.,
      "PDR_Reservation_Request".  Note that the response PDR container
      sent by a QNE Egress to a QNE Ingress node is not carried by an
      end-to-end RESPONSE message, but it is carried by an intra-domain
      RESERVE message that is sent by the QNE Egress node towards the
      QNE Ingress node (denoted in Figure 16 as RESERVE(RMD-QSPEC):
      "reverse").

   *  the <B> PDR bit indicates a bidirectional reservation and is set
      to "1".

Top      Up      ToC       Page 78 
   *  the <PDR Bandwidth> field specifies the requested bandwidth that
      has to be used by the QNE Egress node to initiate another intra-
      domain RESERVE message in the reverse direction.

   The RESERVE(RMD-QSPEC): "reverse" message is initiated by the QNE
   Egress node at the moment that the RESERVE(RMD-QSPEC): "forward"
   message is successfully processed by the QNE Egress node.

   The main differences between the RESERVE(RMD-QSPEC): "reverse"
   message used for the bidirectional successful reservation procedure
   and a RESERVE(RMD-QSPEC) message used for the unidirectional
   successful reservation are as follows:

QNE(Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE(Egress)
NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
    |                |               |               |              |
    |                |               |               |              |
    |RESERVE(RMD-QSPEC)              |               |              |
    |"forward"       |               |               |              |
    |                |    RESERVE(RMD-QSPEC):        |              |
    |--------------->|    "forward"  |               |              |
    |                |------------------------------>|              |
    |                |               |               |------------->|
    |                |               |               |              |
    |                |               |RESERVE(RMD-QSPEC)            |
    |      RESERVE(RMD-QSPEC)        | "reverse"     |<-------------|
    |      "reverse" |               |<--------------|              |
    |<-------------------------------|               |              |

     Figure 17: Intra-domain signaling operation for successful
                bidirectional reservation

   *  the <RII> object is not included in the message.  This is because
      no RESPONSE message is REQUIRED;

   *  the value of the <Peak Data Rate-1 (p)> field of the local RMD-
      QSPEC <TMOD-1> parameter is set equal to the value of the <PDR
      Bandwidth> field included in the RESERVE(RMD-QSPEC): "forward"
      message that triggered the generation of this RESERVE(RMD-QSPEC):
      "reverse" message;

   *  the <B> bit of the PHR container indicates a bidirectional
      reservation and is set to "1";

   *  the PDR container is included into the RESERVE(RMD-QSPEC):
      "reverse" message.  The value of the Parameter ID is "23", i.e.,
      "PDR_Reservation_Report";

Top      Up      ToC       Page 79 
   *  the <B> PDR bit indicates a bidirectional reservation and is set
      to "1".

   Figures 18 and 19 show the flow diagrams used in the case of an
   unsuccessful bidirectional reservation.  In Figure 18, the QNE that
   is not able to support the requested <Peak Data Rate-1 (p)> value of
   local RMD-QSPEC <TMOD-1> is located in the direction QNE Ingress
   towards QNE Egress.  In Figure 19, the QNE that is not able to
   support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC
   <TMOD-1> is located in the direction QNE Egress towards QNE Ingress.
   The main differences between the bidirectional unsuccessful procedure
   shown in Figure 18 and the bidirectional successful procedure are as
   follows:

   *  the QNE node that is not able to reserve resources for a certain
      request is located in the "forward" path, i.e., the path from the
      QNE Ingress towards the QNE Egress.

   *  the QNE node that is not able to support the requested <Peak Data
      Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M>
      bit, i.e., set to value "1", of the RESERVE(RMD-QSPEC): "forward".

QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)     QNE(Egress)
NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
    |                |             |              |               |
    |RESERVE(RMD-QSPEC):           |              |               |
    |  "forward"     |  RESERVE(RMD-QSPEC):       |               |
    |--------------->|  "forward"  |              M RESERVE(RMD-QSPEC):
    |                |--------------------------->M  "forward-M marked"
    |                |             |              M-------------->|
    |                |           RESPONSE(PDR)    M               |
    |                |        "forward - M marked"M               |
    |<------------------------------------------------------------|
    |RESERVE(RMD-QSPEC, K=0)       |              M               |
    |"forward - T tear"            |              M               |
    |--------------->|             |              M               |
    |                    RESERVE(RMD-QSPEC, K=1)  M               |
    |                |   "forward - T tear"       M               |
    |                |--------------------------->M               |
    |                |                  RESERVE(RMD-QSPEC, K=1)   |
    |                |                 "forward - T tear"         |
    |                |                            M-------------->|

  Figure 18: Intra-domain signaling operation for unsuccessful
             bidirectional reservation (rejection on path
             QNE(Ingress) towards QNE(Egress))

Top      Up      ToC       Page 80 
   The operation for this type of unsuccessful bidirectional reservation
   is similar to the operation for unsuccessful unidirectional
   reservation, shown in Figure 9.

   The main differences between the bidirectional unsuccessful procedure
   shown in Figure 19 and the in bidirectional successful procedure are
   as follows:

   *  the QNE node that is not able to reserve resources for a certain
      request is located in the "reverse" path, i.e., the path from the
      QNE Egress towards the QNE Ingress.

   *  the QNE node that is not able to support the requested <Peak Data
      Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M>
      bit, i.e., set to value "1", the RESERVE(RMD-QSPEC): "reverse".

Top      Up      ToC       Page 81 
QNE(Ingress)     QNE (int.)    QNE (int.)    QNE (int.)     QNE(Egress)
NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
    |                |                |                |              |
    |RESERVE(RMD-QSPEC)               |                |              |
    |"forward"       |  RESERVE(RMD-QSPEC):            |              |
    |--------------->|  "forward"     |           RESERVE(RMD-QSPEC): |
    |                |-------------------------------->|"forward"     |
    |                |   RESERVE(RMD-QSPEC):           |------------->|
    |                |    "reverse"   |                |              |
    |                |              RESERVE(RMD-QSPEC) |              |
    |    RESERVE(RMD-QSPEC):          M      "reverse" |<-------------|
    |   "reverse - M marked"          M<---------------|              |
    |<--------------------------------M                |              |
    |                |                M                |              |
    |RESERVE(RMD-QSPEC, K=0):         M                |              |
    |"forward - T tear"               M                |              |
    |--------------->|  RESERVE(RMD-QSPEC, K=0):       |              |
    |                |  "forward - T tear"             |              |
    |                |-------------------------------->|              |
    |                |                M                |------------->|
    |                |                M         RESERVE(RMD-QSPEC, K=0):
    |                |                M            "reverse - T tear" |
    |                |                M                |<-------------|
    |                                 M RESERVE(RMD-QSPEC, K=1)       |
    |                |                M "forward - T tear"            |
    |                |                M<---------------|              |
    |          RESERVE(RMD-QSPEC, K=1)M                |              |
    |          "forward - T tear"     M                |              |
    |<--------------------------------M                |              |

  Figure 19: Intra-domain signaling normal operation for unsuccessful
             bidirectional reservation (rejection on path QNE(Egress)
             towards QNE(Ingress)

   *  the QNE Ingress uses the information contained in the received PHR
      and PDR containers of the RESERVE(RMD-QSPEC): "reverse" and
      generates a tear intra-domain RESERVE(RMD-QSPEC): "forward - T
      tear" message.  This message carries a "PHR_Release_Request" and
      "PDR_Release_Request" control information.  This message is sent
      to the QNE Egress node.  The QNE Egress node uses the information
      contained in the "PHR_Release_Request" and the
      "PDR_Release_Request" control info containers to generate a
      RESERVE(RMD-QSPEC): "reverse - T tear" message that is sent
      towards the QNE Ingress node.

Top      Up      ToC       Page 82 
4.6.2.2.  Refresh Reservations

   This section describes the operation of the RMD-QOSM where an RMD
   intra-domain bidirectional refresh reservation operation is
   accomplished.

   The refresh procedure in the case of an RMD reservation-based method
   follows a scheme similar to the successful reservation procedure,
   described in Section 4.6.2.1 and depicted in Figure 17, and how the
   refresh process of the reserved resources is maintained and is
   similar to the refresh process used for the intra-domain
   unidirectional reservations (see Section 4.6.1.3).

   Note that the RMD traffic class refresh periods used by the bound
   bidirectional sessions MUST be equal in all QNE Edge and QNE Interior
   nodes.

   The main differences between the RESERVE(RMD-QSPEC): "forward"
   message used for the bidirectional refresh procedure and a
   RESERVE(RMD-QSPEC): "forward" message used for the bidirectional
   successful reservation procedure are as follows:

   *  the value of the Parameter ID of the PHR container is "19", i.e.,
      "PHR_Refresh_Update".

   *  the value of the Parameter ID of the PDR container is "21", i.e.,
      "PDR_Refresh_Request".

   The main differences between the RESERVE(RMD-QSPEC): "reverse"
   message used for the bidirectional refresh procedure and the RESERVE
   (RMD-QSPEC): "reverse" message used for the bidirectional successful
   reservation procedure are as follows:

   *  the value of the Parameter ID of the PHR container is "19", i.e.,
      "PHR_Refresh_Update".

   *  the value of the Parameter ID of the PDR container is "24", i.e.,
      "PDR_Refresh_Report".

4.6.2.3.  Modification of Aggregated Intra-Domain QoS-NSLP Operational
          Reservation States

   This section describes the operation of the RMD-QOSM where RMD intra-
   domain bidirectional QoS-NSLP aggregated reservation states have to
   be modified.

Top      Up      ToC       Page 83 
   In the case when the QNE Edges maintain, for the RMD QoS Model, QoS-
   NSLP aggregated reservation states and if such an aggregated
   reservation has to be modified (see Section 4.3.1), then similar
   procedures to Section 4.6.1.4 are applied.  In particular:

   *  When the modification request requires an increase of the reserved
      resources, the QNE Ingress node MUST include the corresponding
      value into the <Peak Data Rate-1 (p)> field local RMD-QSPEC
      <TMOD-1> parameter of the RMD-QOSM <QoS Desired>), which is sent
      together with "PHR_Resource_Request" control information.  If a
      QNE Edge or QNE Interior node is not able to reserve the number of
      requested resources, then the "PHR_Resource_Request" associated
      with the local RMD-QSPEC <TMOD-1> parameter MUST be marked.  In
      this situation, the RMD-specific operation for unsuccessful
      reservation will be applied (see Section 4.6.2.1).  Note that the
      value of the <PDR Bandwidth> parameter, which is sent within a
      "PDR_Reservation_Request" container, represents the increase of
      the reserved resources in the "reverse" direction.

   *  When the modification request requires a decrease of the reserved
      resources, the QNE Ingress node MUST include this value into the
      <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1>
      parameter of the RMD-QOSM <QoS Desired>).  Subsequently, an RMD
      release procedure SHOULD be accomplished (see Section 4.6.2.4).
      Note that the value of the <PDR Bandwidth> parameter, which is
      sent within a "PDR_Release_Request" container, represents the
      decrease of the reserved resources in the "reverse" direction.

4.6.2.4.  Release Procedure

   This section describes the operation of the RMD-QOSM, where an RMD
   intra-domain bidirectional reservation release operation is
   accomplished.  The message sequence diagram used in this procedure is
   similar to the one used by the successful reservation procedures,
   described in Section 4.6.2.1 and depicted in Figure 17.  However, how
   the release of the reservation is accomplished is similar to the RMD
   release procedure used for the intra-domain unidirectional
   reservations (see Section 4.6.1.5 and Figures 18 and 19).

   The main differences between the RESERVE (RMD-QSPEC): "forward"
   message used for the bidirectional release procedure and a RESERVE
   (RMD-QSPEC): "forward" message used for the bidirectional successful
   reservation procedure are as follows:

   *  the value of the Parameter ID of the PHR container is "18",
      i.e."PHR_Release_Request";

Top      Up      ToC       Page 84 
   *  the value of the Parameter ID of the PDR container is "22", i.e.,
      "PDR_Release_Request";

   The main differences between the RESERVE (RMD-QSPEC): "reverse"
   message used for the bidirectional release procedure and the RESERVE
   (RMD-QSPEC): "reverse" message used for the bidirectional successful
   reservation procedure are as follows:

   *  the value of the Parameter ID of the PHR container is "18", i.e.,
      "PHR_Release_Request";

   *  the PDR container is not included in the RESERVE (RMD-QSPEC):
      "reverse" message.

4.6.2.5.  Severe Congestion Handling

   This section describes the severe congestion handling operation used
   in combination with RMD intra-domain bidirectional reservation
   procedures.  This severe congestion handling operation is similar to
   the one described in Section 4.6.1.6.

4.6.2.5.1.  Severe Congestion Handling by the RMD-QOSM Bidirectional
            Refresh Procedure

   This procedure is similar to the severe congestion handling procedure
   described in Section 4.6.1.6.1.  The difference is related to how the
   refresh procedure is accomplished (see Section 4.6.2.2) and how the
   flows are terminated (see Section 4.6.2.4).

4.6.2.5.2.  Severe Congestion Handling by Proportional Data Packet
            Marking

   This section describes the severe congestion handling by proportional
   data packet marking when this is combined with an RMD intra-domain
   bidirectional reservation procedure.  Note that the detection and
   marking/re-marking functionality described in this section and used
   by Interior nodes, applies to NSIS-aware but also to NSIS-unaware
   nodes.  This means however, that the "not NSIS-aware" Interior nodes
   MUST be configured such that they can detect the congestion
   situations and re-mark packets in the same way as the Interior "NSIS-
   aware" nodes do.

   This procedure is similar to the severe congestion handling procedure
   described in Section 4.6.1.6.2.  The main difference is related to
   the location of the severe congested node, i.e., "forward" or
   "reverse" path.  Note that when a severe congestion situation occurs,
   e.g., on a forward path, and flows are terminated to solve the severe
   congestion in forward path, then the reserved bandwidth associated

Top      Up      ToC       Page 85 
   with the terminated bidirectional flows will also be released.
   Therefore, a careful selection of the flows that have to be
   terminated SHOULD take place.  An example of such a selection is
   given in Appendix A.5.

   Furthermore, a special case of this operation is associated with the
   severe congestion situation occurring simultaneously on the forward
   and reverse paths.  An example of this operation is given in Appendix
   A.6.

   Simulation results associated with these procedures can be found in
   [DiKa08].

QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)     QNE(Egress)
NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
user|                |             |              |               |
data|    user        |             |              |               |
--->|    data        | user data   |              |user data      |
    |--------------->|             |              S               |
    |                |--------------------------->S (#marked bytes)
    |                |             |              S-------------->|
    |                |             |              S(#unmarked bytes)
    |                |             |              S-------------->|Term
    |                |             |              S               |flow?
    |                |          NOTIFY (PDR)      S               |YES
    |<------------------------------------------------------------|
    |RESERVE(RMD-QSPEC)            |              S               |
    |"forward - T tear"            |              S               |
    |--------------->|             |           RESERVE(RMD-QSPEC):|
    |                |--------------------------->S"forward - T tear"
    |                |             |              S-------------->|
    |                |             |          RESERVE(RMD-QSPEC): |
    |                |             |           "reverse - T tear" |
    | RESERVE(RMD-QSPEC):          |              |<--------------|
    |"reverse - T tear"            |<-------------S               |
    |<-----------------------------|              S               |

  Figure 20: Intra-domain RMD severe congestion handling for
             bidirectional reservation (congestion on path
             QNE(Ingress) towards QNE(Egress))

   Figure 20 shows the scenario in which the severely congested node is
   located in the "forward" path.  The QNE Egress node has to generate
   an end-to-end NOTIFY (PDR) message.  In this way, the QNE Ingress
   will be able to receive the (#marked and #unmarked) that were
   measured by the QNE Egress node on the congested "forward" path.
   Note that in this situation, it is assumed that the "reverse" path is
   not congested.

Top      Up      ToC       Page 86 
   This scenario is very similar to the severe congestion handling
   scenario described in Section 4.6.1.6.2 and shown in Figure 14.  The
   difference is related to the release procedure, which is accomplished
   in the same way as described in Section 4.6.2.4.

   Figure 21 shows the scenario in which the severely congested node is
   located in the "reverse" path.  Note that in this situation, it is
   assumed that the "forward" path is not congested.  The main
   difference between this scenario and the scenario shown in Figure 20
   is that no end-to-end NOTIFY (PDR) message has to be generated by the
   QNE Egress node.

   This is because now the severe congestion occurs on the "reverse"
   path and the QNE Ingress node receives the (#marked and #unmarked)
   user data passing through the severely congested "reverse" path.  The
   QNE Ingress node will be able to calculate the number of flows that
   have to be terminated or forwarded in a lower priority queue.

Top      Up      ToC       Page 87 
QNE(Ingress)     QNE (int.)    QNE (int.)    QNE (int.)     QNE(Egress)
NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
user|                |                |           |               |
data|    user        |                |           |               |
--->|    data        | user data      |           |user data      |
    |--------------->|                |           |               |
    |                |--------------------------->|user data      |user
    |                |                |           |-------------->|data
    |                |                |           |               |--->
    |                |                |  user     |               |<---
    |   user data    |                |  data     |<--------------|
    | (#marked bytes)|                S<----------|               |
    |<--------------------------------S           |               |
    | (#unmarked bytes)               S           |               |
Term|<--------------------------------S           |               |
Flow?                |                S           |               |
YES |RESERVE(RMD-QSPEC):              S           |               |
    |"forward - T tear"               s           |               |
    |--------------->|  RESERVE(RMD-QSPEC):       |               |
    |                |  "forward - T tear"        |               |
    |                |--------------------------->|               |
    |                |                S           |-------------->|
    |                |                S         RESERVE(RMD-QSPEC):
    |                |                S       "reverse - T tear"  |
    |      RESERVE(RMD-QSPEC)         S           |<--------------|
    |      "reverse - T tear"         S<----------|               |
    |<--------------------------------S           |               |

  Figure 21: Intra-domain RMD severe congestion handling for
             bidirectional reservation (congestion on path
             QNE(Egress) towards QNE(Ingress))

   For the flows that have to be terminated, a release procedure, see
   Section 4.6.2.4, is initiated to release the reserved resources on
   the "forward" and "reverse" paths.

4.6.2.6.  Admission Control Using Congestion Notification Based on
          Probing

   This section describes the admission control scheme that uses the
   congestion notification function based on probing when RMD intra-
   domain bidirectional reservations are supported.

Top      Up      ToC       Page 88 
QNE(Ingress)    Interior    QNE (int.)      Interior       QNE(Egress)
NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
user|                |             |              |               |
data|                |             |              |               |
--->|                | user data   |              |user data      |
    |-------------------------------------------->S (#marked bytes)
    |                |             |              S-------------->|
    |                |             |              S(#unmarked bytes)
    |                |             |              S-------------->|
    |                |             |              S               |
    |                |           RESERVE(re-marked DSCP in GIST)):|
    |                |             |              S               |
    |-------------------------------------------->S               |
    |                |             |              S-------------->|
    |                |             |              S               |
    |                |          RESPONSE(unsuccessful INFO-SPEC)  |
    |<------------------------------------------------------------|
    |                |             |              S               |

  Figure 22: Intra-domain RMD congestion notification based on
             probing for bidirectional admission control (congestion
             on path from QNE(Ingress) towards QNE(Egress))

   This procedure is similar to the congestion notification for
   admission control procedure described in Section 4.6.1.7.  The main
   difference is related to the location of the severe congested node,
   i.e., "forward" path (i.e., path between QNE Ingress towards QNE
   Egress) or "reverse" path (i.e., path between QNE Egress towards QNE
   Ingress).

   Figure 22 shows the scenario in which the severely congested node is
   located in the "forward" path.  The functionality of providing
   admission control is the same as that described in Section 4.6.1.7,
   Figure 15.

   Figure 23 shows the scenario in which the congested node is located
   in the "reverse" path.  The probe RESERVE message sent in the
   "forward" direction will not be affected by the severely congested
   node, while the <DSCP> value in the IP header of any packet of the
   "reverse" direction flow and also of the GIST message that carries
   the probe RESERVE message sent in the "reverse" direction will be re-
   marked by the congested node.  The QNE Ingress is, in this way,
   notified that a congestion occurred in the network, and therefore it
   is able to refuse the new initiation of the reservation.

Top      Up      ToC       Page 89 
   Note that the "not NSIS-aware" Interior nodes MUST be configured such
   that they can detect the congestion/severe congestion situations and
   re-mark packets in the same way as the Interior "NSIS-aware" nodes
   do.

QNE(Ingress)     Interior    QNE (int.)     Interior        QNE(Egress)
NTLP stateful not NSIS aware  NTLP st.less not NSIS aware NTLP stateful
user|                |                |           |               |
data|                |                |           |               |
--->|                | user data      |           |               |
    |-------------------------------------------->|user data      |user
    |                |                |           |-------------->|data
    |                |                |           |               |--->
    |                |                |           |               |user
    |                |                |           |               |data
    |                |                |           |               |<---
    |                S                | user data |               |
    |                S  user data     |<--------------------------|
    |   user data    S<---------------|           |               |
    |<---------------S                |           |               |
    |  user data     S                |           |               |
    | (#marked bytes)S                |           |               |
    |<---------------S                |           |               |
    |                S           RESERVE(unmarked DSCP in GIST)): |
    |                S                |           |               |
    |----------------S------------------------------------------->|
    |                S          RESERVE(re-marked DSCP in GIST)   |
    |                S<-------------------------------------------|
    |<---------------S                |           |               |

  Figure 23: Intra-domain RMD congestion notification for
             bidirectional admission control (congestion on path
             QNE(Egress) towards QNE(Ingress))

4.7.  Handling of Additional Errors

   During the QSPEC processing, additional errors MAY occur.  The way in
   which these additional errors are handled and notified is specified
   in [RFC5975] and [RFC5974].

5.  Security Considerations

5.1.  Introduction

   A design goal of the RMD-QOSM protocol is to be "lightweight" in
   terms of the number of exchanged signaling message and the amount of
   state established at involved signaling nodes (with and without
   reduced-state operation).  A side effect of this design decision is

Top      Up      ToC       Page 90 
   to introduce second-class signaling nodes, namely QNE Interior nodes,
   that are restricted in their ability to perform QoS signaling
   actions.  Only the QNE Ingress and the QNE Egress nodes are allowed
   to initiate certain signaling messages.

   Moreover, RMD focuses on an intra-domain deployment only.

   The above description has the following implications for security:

   1) QNE Ingress and QNE Egress nodes require more security and fault
      protection than QNE Interior nodes because their uncontrolled
      behavior has larger implications for the overall stability of the
      network.  QNE Ingress and QNE Egress nodes share a security
      association and utilize GIST security for protection of their
      signaling messages.  Intra-domain signaling messages used for RMD
      signaling do not use GIST security, and therefore they do not
      store security associations.

   2) The focus on intra-domain QoS signaling simplifies trust
      management and reduces overall complexity.  See Section 2 of RFC
      4081 for a more detailed discussion about the complete set of
      communication models available for end-to-end QoS signaling
      protocols.  The security of RMD-QOSM does not depend on Interior
      nodes, and hence the cryptographic protection of intra-domain
      messages via GIST is not utilized.

   It is important to highlight that RMD always uses the message
   exchange shown in Figure 24 even if there is no end-to-end signaling
   session.  If the RMD-QOSM is triggered based on an end-to-end (E2E)
   signaling exchange, then the RESERVE message is created by a node
   outside the RMD domain and will subsequently travel further (e.g., to
   the data receiver).  Such an exchange is shown in Figure 3.  As such,
   an evaluation of an RMD's security always has to be seen as a
   combination of the two signaling sessions, (1) and (2) of Figure 24.
   Note that for the E2E message, such as the RESERVE and the RESPONSE
   message, a single "hop" refers to the communication between the QNE
   Ingress and the QNE Egress since QNE Interior nodes do not
   participate in the exchange.

Top      Up      ToC       Page 91 
          QNE             QNE             QNE            QNE
        Ingress         Interior        Interior        Egress
    NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
           |               |               |              |
           | RESERVE (1)   |               |              |
           +--------------------------------------------->|
           | RESERVE' (2)  |               |              |
           +-------------->|               |              |
           |               | RESERVE'      |              |
           |               +-------------->|              |
           |               |               | RESERVE'     |
           |               |               +------------->|
           |               |               | RESPONSE' (2)|
           |<---------------------------------------------+
           |               |               | RESPONSE (1) |
           |<---------------------------------------------+

                  Figure 24: RMD message exchange

   Authorizing quality-of-service reservations is accomplished using the
   Authentication, Authorization, and Accounting (AAA) framework and the
   functionality is inherited from the underlying NSIS QoS NSLP, see
   [RFC5974], and not described again in this document.  As a technical
   solution mechanism, the Diameter QoS application [RFC5866] may be
   used.  The end-to-end reservation request arriving at the Ingress
   node will trigger the authorization procedure with the backend AAA
   infrastructure.  The end-to-end reservation is typically triggered by
   a human interaction with a software application, such as a voice-
   over-IP client when making a call.  When authorization is successful
   then no further user initiated QoS authorization check is expected to
   be performed within the RMD domain for the intra-domain reservation.

5.2.  Security Threats

   In the RMD-QOSM, the Ingress node constructs both end-to-end and
   intra-domain signaling messages based on the end-to-end message
   initiated by the sender end node.

   The Interior nodes within the RMD network ignore the end-to-end
   signaling message, but they process, modify, and forward the intra-
   domain signaling messages towards the Egress node.  In the meantime,
   resource reservation states are installed, modified, or deleted at
   each Interior node along the data path according to the content of
   each intra-domain signaling message.  The Edge nodes of an RMD
   network are critical components that require strong security
   protection.

Top      Up      ToC       Page 92 
   Therefore, they act as security gateways for incoming and outgoing
   signaling messages.  Moreover, a certain degree of trust has to be
   placed into Interior nodes within the RMD-QOSM network, such that
   these nodes can perform signaling message processing and take the
   necessary actions.

   With the RMD-QOSM, we assume that the Ingress and the Egress nodes
   are not controlled by an adversary and the communication between the
   Ingress and the Egress nodes is secured using standard GIST security,
   (see Section 6 of [RFC5971]) mechanisms and experiences integrity,
   replay, and confidentiality protection.

   Note that this only affects messages directly addressed by these two
   nodes and not any other message that needs to be processed by
   intermediaries.  The <SESSION-ID> object of the end-to-end
   communication is visible, via GIST, to the Interior nodes.  In order
   to define the security threats that are associated with the RMD-QOSM,
   we consider that an adversary that may be located inside the RMD
   domain and could drop, delay, duplicate, inject, or modify signaling
   packets.

   Depending on the location of the adversary, we speak about an on-path
   adversary or an off-path adversary, see also RFC 4081 [RFC4081].

5.2.1.  On-Path Adversary

   The on-path adversary is a node, which supports RMD-QOSM and is able
   to observe RMD-QOSM signaling message exchanges.

   1) Dropping signaling messages

   An adversary could drop any signaling messages after receiving them.
   This will cause a failure of reservation request for new sessions or
   deletion of resource units (bandwidth) for ongoing sessions due to
   states timeout.

   It may trigger the Ingress node to retransmit the lost signaling
   messages.  In this scenario, the adversary drops selected signaling
   messages, for example, intra-domain reserve messages.  In the RMD-
   QOSM, the retransmission mechanism can be provided at the Ingress
   node to make sure that signaling messages can reach the Egress node.
   However, the retransmissions triggered by the adversary dropping
   messages may cause certain problems.  Therefore, disabling the use of
   retransmissions in the RMD-QOSM-aware network is recommended, see
   also Section 4.6.1.1.1.

Top      Up      ToC       Page 93 
   2) Delaying Signaling Messages

   Any signaling message could be delayed by an adversary.  For example,
   if RESERVE' messages are delayed over the duration of the refresh
   period, then the resource units (bandwidth) reserved along the nodes
   for corresponding sessions will be removed.  In this situation, the
   Ingress node does not receive the RESPONSE within a certain period,
   and considers that the signaling message has failed, which may cause
   a retransmission of the "failed" message.  The Egress node may
   distinguish between the two messages, i.e., the delayed message and
   the retransmitted message, and it could get a proper response.

   However, Interior nodes suffer from this retransmission and they may
   reserve twice the resource units (bandwidth) requested by the Ingress
   node.

   3) Replaying Signaling Messages

   An adversary may want to replay signaling messages.  It first stores
   the received messages and decides when to replay these messages and
   at what rate (packets per second).

   When the RESERVE' message carried an <RII> object, the Egress will
   reply with a RESPONSE' message towards the Ingress node.  The Ingress
   node can then detect replays by comparing the value of <RII> in the
   RESPONSE' messages with the stored value.

   4) Injecting Signaling Messages

   Similar to the replay-attack scenario, the adversary may store a part
   of the information carried by signaling messages, for example, the
   <RSN> object.  When the adversary injects signaling messages, it puts
   the stored information together with its own generated parameters
   (RMD-QSPEC <TMOD-1> parameter, <RII>, etc.) into the injected
   messages and then sends them out.  Interior nodes will process these
   messages by default, reserve the requested resource units (bandwidth)
   and pass them to downstream nodes.

   It may happen that the resource units (bandwidth) on the Interior
   nodes are exhausted if these injected messages consume too much
   bandwidth.

   5) Modifying Signaling Messages

   On-path adversaries are capable of modifying any part of the
   signaling message.  For example, the adversary can modify the <M>,
   <S>, and <O> parameters of the RMD-QSPEC messages.  The Egress node
   will then use the SESSION-ID and subsequently the <BOUND-SESSION-ID>

Top      Up      ToC       Page 94 
   objects to refer to that flow to be terminated or set to lower
   priority.  It is also possible for the adversary to modify the RMD-
   QSPEC <TMOD-1> parameter and/or <PHB Class> parameter, which could
   cause a modification of an amount of the requested resource units
   (bandwidth) changes.

5.2.2.  Off-Path Adversary

   In this case, the adversary is not located on-path and it does not
   participate in the exchange of RMD-QOSM signaling messages, and
   therefore is unable to eavesdrop signaling messages.  Hence, the
   adversary does not know valid <RII>s, <RSN>s, and <SESSION-ID>s.
   Hence, the adversary has to generate new parameters and constructs
   new signaling messages.  Since Interior nodes operate in reduced-
   state mode, injected signaling messages are treated as new once,
   which causes Interior nodes to allocate additional reservation state.

5.3.  Security Requirements

   The following security requirements are set as goals for the intra-
   domain communication, namely:

   *  Nodes, which are never supposed to participate in the NSIS
      signaling exchange, must not interfere with QNE Interior nodes.
      Off-path nodes (off-path with regard to the path taken by a
      particular signaling message exchange) must not be able to
      interfere with other on-path signaling nodes.

   *  The actions allowed by a QNE Interior node should be minimal
      (i.e., only those specified by the RMD-QOSM).  For example, only
      the QNE Ingress and the QNE Egress nodes are allowed to initiate
      certain signaling messages.  QNE Interior nodes are, for example,
      allowed to modify certain signaling message payloads.

   Note that the term "interfere" refers to all sorts of security
   threats, such as denial-of-service, spoofing, replay, signaling
   message injection, etc.

5.4.  Security Mechanisms

   An important security mechanism that was built into RMD-QOSM was the
   ability to tie the end-to-end RESERVE and the RESERVE' messages
   together using the BOUND-SESSION-ID and to allow the Ingress node to
   match the RESERVE' with the RESPONSE' by using the <RII>.  These
   mechanisms enable the Edge nodes to detect unexpected signaling
   messages.

Top      Up      ToC       Page 95 
   We assume that the RESERVE/RESPONSE is sent with hop-by-hop channel
   security provided by GIST and protected between the QNE Ingress and
   the QNE Egress.  GIST security mechanisms MUST be used to offer
   authentication, integrity, and replay protection.  Furthermore,
   encryption MUST be used to prevent an adversary located along the
   path of the RESERVE message from learning information about the
   session that can later be used to inject a RESERVE' message.

   The following messages need to be mapped to each other to make sure
   that the occurrence of one message is not without the other:

   a) the RESERVE and the RESERVE' relate to each other at the QNE
      Egress; and

   b) the RESPONSE and the RESERVE relate to each other at the QNE
      Ingress; and

   c) the RESERVE' and the RESPONSE' relate to each other.  The <RII> is
      carried in the RESERVE' message and the RESPONSE' message that is
      generated by the QNE Egress node contains the same <RII> as the
      RESERVE'.  The <RII> can be used by the QNE Ingress to match the
      RESERVE' with the RESPONSE'.  The QNE Egress is able to determine
      whether the RESERVE' was created by the QNE Ingress node since the
      intra-domain session, which sent the RESERVE', is bound to an end-
      to-end session via the <BOUND-SESSION-ID> value included in the
      intra-domain QoS-NSLP operational state maintained at the QNE
      Egress.

   The RESERVE and the RESERVE' message are tied together using the
   BOUND-SESSION-ID(s) maintained by the intra-domain and end-to-end
   QoS-NSLP operational states maintained at the QNE Edges (see Sections
   4.3.1, 4.3.2, and 4.3.3).  Hence, there cannot be a RESERVE' without
   a corresponding RESERVE.  The SESSION-ID can fulfill this purpose
   quite well if the aim is to provide protection against off-path
   adversaries that do not see the SESSION-ID carried in the RESERVE and
   the RESERVE' messages.

   If, however, the path changes (due to rerouting or due to mobility),
   then an adversary could inject RESERVE' messages (with a previously
   seen SESSION-ID) and could potentially cause harm.

   An off-path adversary can, of course, create RESERVE' messages that
   cause intermediate nodes to create some state (and cause other
   actions) but the message would finally hit the QNE Egress node.  The
   QNE Egress node would then be able to determine that there is
   something going wrong and generate an error message.

Top      Up      ToC       Page 96 
   The severe congestion handling can be triggered by intermediate nodes
   (unlike other messages).  In many cases, however, intermediate nodes
   experiencing congestion use refresh messages modify the <S> and <O>
   parameters of the message.  These messages are still initiated by the
   QNE Ingress node and carry the SESSION-ID.  The QNE Egress node will
   use the SESSION-ID and subsequently the BOUND-SESSION-ID, maintained
   by the intra-domain QoS-NSLP operational state, to refer to a flow
   that might be terminated.  The aspect of intermediate nodes
   initiating messages for severe congestion handling is for further
   study.

   During the refresh procedure, a RESERVE' creates a RESPONSE', see
   Figure 25.  The <RII> is carried in the RESERVE' message and the
   RESPONSE' message that is generated by the QNE Egress node contains
   the same <RII> as the RESERVE'.

   The <RII> can be used by the QNE Ingress to match the RESERVE' with
   the RESPONSE'.

   A further aspect is marking of data traffic.  Data packets can be
   modified by an intermediary without any relationship to a signaling
   session (and a SESSION-ID).  The problem appears if an off-path
   adversary injects spoofed data packets.

     QNE Ingress    QNE Interior   QNE Interior    QNE Egress
   NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
          |               |               |              |
          | REFRESH RESERVE'              |              |
          +-------------->| REFRESH RESERVE'             |
          | (+RII)        +-------------->| REFRESH RESERVE'
          |               | (+RII)        +------------->|
          |               |               | (+RII)       |
          |               |               |              |
          |               |               |     REFRESH  |
          |               |               |     RESPONSE'|
          |<---------------------------------------------+
          |               |               |     (+RII)   |

            Figure 25: RMD REFRESH message exchange

   The adversary thereby needs to spoof data packets that relate to the
   flow identifier of an existing end-to-end reservation that SHOULD be
   terminated.  Therefore, the question arises how an off-path adversary
   SHOULD create a data packet that matches an existing flow identifier
   (if a 5-tuple is used).  Hence, this might not turn out to be simple
   for an adversary unless we assume the previously mentioned
   mobility/rerouting case where the path through the network changes
   and the set of nodes that are along a path changes over time.

Top      Up      ToC       Page 97 
6.  IANA Considerations

   This section defines additional codepoint assignments in the QSPEC
   Parameter ID registry, in accordance with BCP 26 [RFC5226].

6.1.  Assignment of QSPEC Parameter IDs

   This document specifies the following QSPEC containers in the QSPEC
   Parameter ID registry created in [RFC5975]:

   <PHR_Resource_Request> (Section 4.1.2 above, ID=17)

   <PHR_Release_Request> (Section 4.1.2 above, ID=18)

   <PHR_Refresh_Update> (Section 4.1.2 above, ID=19)

   <PDR_Reservation_Request> (Section 4.1.3 above, ID=20)

   <PDR_Refresh_Request> (Section 4.1.3 above, ID=21)

   <PDR_Release_Request> (Section 4.1.3 above, ID=22)

   <PDR_Reservation_Report> (Section 4.1.3 above, ID=23)

   <PDR_Refresh_Report> (Section 4.1.3 above, ID=24)

   <PDR_Release_Report> (Section 4.1.3 above, ID=25)

   <PDR_Congestion_Report> (Section 4.1.3 above, ID=26)

7.  Acknowledgments

   The authors express their acknowledgement to people who have worked
   on the RMD concept: Z. Turanyi, R. Szabo, G. Pongracz, A. Marquetant,
   O. Pop, V. Rexhepi, G. Heijenk, D. Partain, M. Jacobsson, S.
   Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel, M.
   Zoumaro-Djayoon, M. Swanink, R. Klaver G. Stokkink, J. W. van
   Houwelingen, D. Dimitrova, T. Sealy, H. Chang, and J. de Waal.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

Top      Up      ToC       Page 98 
   [RFC5971]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
              Signaling Transport", RFC 5971, October 2010.

   [RFC5974]  Manner, J., Karagiannis, G., and A. McDonald, "NSIS
              Signaling Layer Protocol (NSLP) for Quality-of-Service
              Signaling", RFC 5974, October 2010.

   [RFC5975]  Ash, G., Bader, A., Kappler C., and D. Oran, "QSPEC
              Template for the Quality-of-Service NSIS Signaling Layer
              Protocol (NSLP)", RFC 5975, October 2010.

8.2.  Informative References

   [AdCa03]   Adler, M., Cai, J.-Y., Shapiro, J. K., Towsley, D.,
              "Estimation of congestion price using probabilistic packet
              marking", Proc. IEEE INFOCOM, pp. 2068-2078, 2003.

   [AnHa06]   Lachlan L. H. Andrew and Stephen V. Hanly, "The Estimation
              Error of Adaptive Deterministic Packet Marking", 44th
              Annual Allerton Conference on Communication, Control and
              Computing, 2006.

   [AtLi01]   Athuraliya, S., Li, V. H., Low, S. H., Yin, Q., "REM:
              active queue management", IEEE Network, vol. 15, pp.
              48-53, May/June 2001.

   [Chan07]   H. Chang, "Security support in RMD-QOSM", Masters thesis,
              University of Twente, 2007.

   [CsTa05]   Csaszar, A., Takacs, A., Szabo, R., Henk, T., "Resilient
              Reduced-State Resource Reservation", Journal of
              Communication and Networks, Vol. 7, No. 4, December 2005.

   [DiKa08]   Dimitrova, D., Karagiannis, G., de Boer, P.-T., "Severe
              congestion handling approaches in NSIS RMD domains with
              bi-directional reservations", Journal of Computer
              Communications, Elsevier, vol. 31, pp. 3153-3162, 2008.

   [JaSh97]   Jamin, S., Shenker, S., Danzig, P., "Comparison of
              Measurement-based Admission Control Algorithms for
              Controlled-Load Service", Proceedings IEEE Infocom '97,
              Kobe, Japan, April 1997.

   [GrTs03]   Grossglauser, M., Tse, D.N.C, "A Time-Scale Decomposition
              Approach to Measurement-Based Admission Control",
              IEEE/ACM Transactions on Networking, Vol. 11, No. 4,
              August 2003.

Top      Up      ToC       Page 99 
   [Part94]   C. Partridge, Gigabit Networking, Addison Wesley
              Publishers (1994).

   [RFC1633]  Braden, R., Clark, D., and S. Shenker, "Integrated
              Services in the Internet Architecture: an Overview", RFC
              1633, June 1994.

   [RFC2215]  Shenker, S. and J. Wroclawski, "General Characterization
              Parameters for Integrated Service Network Elements", RFC
              2215, September 1997.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Service", RFC 2475, December 1998.

   [RFC2638]  Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
              Differentiated Services Architecture for the Internet",
              RFC 2638, July 1999.

   [RFC2998]  Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
              Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
              Felstaine, "A Framework for Integrated Services Operation
              over Diffserv Networks", RFC 2998, November 2000.

   [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
              "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
              3175, September 2001.

   [RFC3726]  Brunner, M., Ed., "Requirements for Signaling Protocols",
              RFC 3726, April 2004.

   [RFC4125]  Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
              Constraints Model for Diffserv-aware MPLS Traffic
              Engineering", RFC 4125, June 2005.

   [RFC4127]  Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints
              Model for Diffserv-aware MPLS Traffic Engineering", RFC
              4127, June 2005.

   [RFC4081]  Tschofenig, H. and D. Kroeselberg, "Security Threats for
              Next Steps in Signaling (NSIS)", RFC 4081, June 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

Top      Up      ToC       Page 100 
   [RFC5866]  Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria,
              A., and G. Zorn, Ed., "Diameter Quality-of-Service
              Application", RFC 5866, May 2010.

   [RFC5978]  Manner, J., Bless, R., Loughney, J., and E. Davies, Ed.,
              "Using and Extending the NSIS Protocol Family", RFC 5978,
              October 2010.

   [RMD1]     Westberg, L., et al., "Resource Management in Diffserv
              (RMD): A Functionality and Performance Behavior Overview",
              IFIP PfHSN 2002.

   [RMD2]     G. Karagiannis, et al., "RMD - a lightweight application
              of NSIS" Networks 2004, Vienna, Austria.

   [RMD3]     Marquetant A., Pop O., Szabo R., Dinnyes G., Turanyi Z.,
              "Novel Enhancements to Load Control - A Soft-State,
              Lightweight Admission Control Protocol", Proc. of the 2nd
              Int. Workshop on Quality of Future Internet Services,
              Coimbra, Portugal, Sept 24-26, 2001, pp. 82-96.

   [RMD4]     A. Csaszar et al., "Severe congestion handling with
              resource management in diffserv on demand", Networking
              2002.

   [TaCh99]   P. P. Tang, T-Y Charles Tai, "Network Traffic
              Characterization Using Token Bucket Model", IEEE Infocom
              1999, The Conference on Computer Communications, no. 1,
              March 1999, pp. 51-62.

   [ThCo04]   Thommes, R. W., Coates, M. J., "Deterministic packet
              marking for congestion packet estimation" Proc. IEEE
              Infocom, 2004.


Next RFC Part