Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5977

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

Pages: 128
Experimental
Part 4 of 5 – Pages 73 to 100
First   Prev   Next

Top   ToC   RFC5977 - Page 73   prevText

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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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   ToC   RFC5977 - 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 page on part 5)

Next Section