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 2 of 5 – Pages 23 to 46
First   Prev   Next

Top   ToC   RFC5977 - Page 23   prevText

4.2. Message Format

The format of the messages used by the RMD-QOSM complies with the QoS-NSLP and QSPEC template specifications. The QSPEC used by RMD- QOSM is denoted in this document as RMD-QSPEC and is described in Section 4.1.

4.3. RMD Node State Management

The QoS-NSLP state creation and management is specified in [RFC5974]. This section describes the state creation and management functions of the Resource Management Function (RMF) in the RMD nodes.

4.3.1. Aggregated Operational and Reservation States at the QNE Edges

The QNE Edges maintain both the intra-domain QoS-NSLP operational and reservation states, while the QNE Interior nodes maintain only reservation states. The structure of the intra-domain QoS-NSLP operational state used by the QNE Edges is specified in [RFC5974]. In this case, the intra-domain sessions supported by the Edges are per-aggregate sessions that have a one-to-many relationship to the per-flow end-to-end states supported by the same Edge. Note that the method of selecting the end-to-end sessions that form an aggregate is not specified in this document. An example of how this can be accomplished is by monitoring the GIST routing states used by the end-to-end sessions and grouping the ones that use the same <PHB Class>, QNE Ingress and QNE Egress addresses, and the value of the priority level. Note that this priority level should be deduced from the priority parameters carried by the initial QSPEC object. The operational state of this aggregated intra-domain session MUST contain a list with BOUND-SESSION-IDs. The structure of the list depends on whether a unidirectional reservation or a bidirectional reservation is supported. When the operational state (at QNE Ingress and QNE Egress) supports unidirectional reservations, then this state MUST contain a list with BOUND-SESSION-IDs maintaining the <SESSION-ID> values of its bound end-to-end sessions. The Binding_Code associated with this BOUND-
Top   ToC   RFC5977 - Page 24
   SESSION-ID is set to code (Aggregated sessions).  Thus, the
   operational state maintains a list of BOUND-SESSION-ID entries.  Each
   entry is created when an end-to-end session joins the aggregated
   intra-domain session and is removed when an end-to-end session leaves
   the aggregate.

   It is important to emphasize that, in this case, the operational
   state (at QNE Ingress and QNE Egress) that is maintained by each end-
   to-end session bound to the aggregated intra-domain session MUST
   contain in the BOUND-SESSION-ID, the <SESSION-ID> value of the bound
   tunneled intra-domain (aggregate) session.  The Binding_Code
   associated with this BOUND-SESSION-ID is set to code (Aggregated
   sessions).

   When the operational state (at QNE Ingress and QNE Egress) supports
   bidirectional reservations, the operational state MUST contain a list
   of BOUND-SESSION-ID sets.  Each set contains two BOUND-SESSION-IDs.
   One of the BOUND-SESSION-IDs maintains the <SESSION-ID> value of one
   of bound end-to-end session.  The Binding_Code associated with this
   BOUND-SESSION-ID is set to code (Aggregated sessions).  Another
   BOUND-SESSION-ID, within the same set entry, maintains the SESSION-ID
   of the bidirectional bound end-to-end session.  The Binding_Code
   associated with this BOUND-SESSION-ID is set to code (Bidirectional
   sessions).

   Note that, in each set, a one-to-one relation exists between each
   BOUND-SESSION-ID with Binding_Code set to (Aggregate sessions) and
   each BOUND-SESSION-ID with Binding_Code set to (bidirectional
   sessions).  Each set is created when an end-to-end session joins the
   aggregated operational state and is removed when an end-to-end
   session leaves the aggregated operational state.

   It is important to emphasize that, in this case, the operational
   state (at QNE Ingress and QNE Egress) that is maintained by each end-
   to-end session bound to the aggregated intra-domain session it MUST
   contain two types of BOUND-SESSION-IDs.  One is the BOUND-SESSION-ID
   that MUST contain the <SESSION-ID> value of the bound tunneled
   aggregated intra-domain session that is using the Binding_Code set to
   (Aggregated sessions).  The other BOUND-SESSION-ID maintains 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 use aggregated QoS-NSLP reservation states, then
   the <PHB Class> value and the size of the aggregated reservation,
   e.g., reserved bandwidth, have to be maintained.  Note that this type
   of aggregation is an edge-to-edge aggregation and is similar to the
   aggregation type specified in [RFC3175].
Top   ToC   RFC5977 - Page 25
   The size of the aggregated reservations needs to be greater or equal
   to the sum of bandwidth of the inter-domain (end-to-end)
   reservations/sessions it aggregates (e.g., see Section 1.4.4 of
   [RFC3175]).

   A policy can be used to maintain the amount of REQUIRED bandwidth on
   a given aggregated reservation by taking into account the sum of the
   underlying inter-domain (end-to-end) reservations, while endeavoring
   to change reservation less frequently.  This MAY require a trend
   analysis.  If there is a significant probability that in the next
   interval of time the current aggregated reservation is exhausted, the
   Ingress router MUST predict the necessary bandwidth and request it.
   If the Ingress router has a significant amount of bandwidth reserved,
   but has very little probability of using it, the policy MAY predict
   the amount of bandwidth REQUIRED and release the excess.  To increase
   or decrease the aggregate, the RMD modification procedures SHOULD be
   used (see Section 4.6.1.4).

   The QNE Interior nodes are reduced-state nodes, i.e., they do not
   store NTLP/GIST states, but they do store per PHB-aggregated QoS-NSLP
   reservation states.  These reservation states are maintained and
   refreshed in the same way as described in Section 4.3.3.

4.3.2. Measurement-Based Method

The QNE Edges maintain per-flow intra-domain QoS-NSLP operational and reservation states that contain similar data structures as those described in Section 4.3.1. The main difference is associated with the different types of the used Message-Routing-Information (MRI) and the bound end-to-end sessions. The structure of the maintained BOUND-SESSION-IDs depends on whether a unidirectional reservation or a bidirectional reservation is supported. When unidirectional reservations are supported, the operational state associated with this per-flow intra-domain session MUST contain in the BOUND-SESSION-ID the <SESSION-ID> value of its bound end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Tunneled and end-to-end sessions). When bidirectional reservations are supported, the operational state (at QNE Ingress and QNE Egress) MUST contain two types of BOUND- SESSION-IDs. One is the BOUND-SESSION-ID that maintains the <SESSION-ID> value of the bound tunneled per-flow intra-domain session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Tunneled and end-to-end sessions).
Top   ToC   RFC5977 - Page 26
   The other BOUND-SESSION-ID maintains 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).

   Furthermore, the QoS-NSLP reservation state maintains the <PHB Class>
   value, the value of the bandwidth requested by the end-to-end session
   bound to the intra-domain session, and the value of the priority
   level.

   The measurement-based method can be classified in two schemes:

   * Congestion notification based on probing:

   In this scheme, the Interior nodes are Diffserv-aware but not NSIS-
   aware nodes.  Each Interior node counts the bandwidth that is used by
   each PHB traffic class.  This counter value is stored in an RMD_QOSM
   state.  For each PHB traffic class, a predefined congestion
   notification threshold is set.  The predefined congestion
   notification threshold is set according to an engineered bandwidth
   limitation based, e.g., on a Service Level Agreement or a capacity
   limitation of specific links.  The threshold is usually less than the
   capacity limit, i.e., admission threshold, in order to avoid
   congestion due to the error of estimating the actual traffic load.
   The value of this threshold SHOULD be stored in another RMD_QOSM
   state.

   In this scenario, an end-to-end NSIS message is used as a probe
   packet.  In this case, the <DSCP> field of the GIST message is re-
   marked when the predefined congestion notification threshold is
   exceeded in an Interior node.  It is required that the re-marking
   happens to all packets that belong to the congested PHB traffic class
   so that the probe can't pass the congested router without being re-
   marked.  In this way, it is ensured that the end-to-end NSIS message
   passed through the node that is congested.  This feature is very
   useful when flow-based ECMP (Equal Cost Multiple Path) routing is
   used to detect only flows that are passing through the congested
   node.

   * NSIS measurement-based admission control:

   The measurement-based admission control is implemented in NSIS-aware
   stateless routers.  Thus, the main difference between this type of
   the measurement-based admission control and the congestion
   notification-based admission control is the fact that the Interior
   nodes are NSIS-aware nodes.  In particular, the QNE Interior nodes
   operating in NSIS measurement-based mode are QoS-NSLP stateless
   nodes, i.e., they do not support any QoS-NSLP or NTLP/GIST states.
   These measurement-based nodes store two RMD-QOSM states per PHR
Top   ToC   RFC5977 - Page 27
   group.  These states reflect the traffic conditions at the node and
   are not affected by QoS-NSLP signaling.  One state stores the
   measured user traffic load associated with the PHR group and another
   state stores the maximum traffic load threshold that can be admitted
   per PHR group.  When a measurement-based node receives a intra-domain
   RESERVE message, it compares the requested resources to the available
   resources (maximum allowed minus current load) for the requested PHR
   group.  If there are insufficient resources, it sets the <M> bit in
   the RMD-QSPEC.  No change to the RMD-QSPEC is made when there are
   sufficient resources.

4.3.3. Reservation-Based Method

The QNE Edges maintain intra-domain QoS-NSLP operational and reservation states that contain similar data structures as described in Section 4.3.1. In this case, the intra-domain sessions supported by the Edges are per-flow sessions that have a one-to-one relationship to the per-flow end-to-end states supported by the same Edge. The QNE Interior nodes operating in reservation-based mode are QoS- NSLP reduced-state nodes, i.e., they do not store NTLP/GIST states but they do store per PHB-aggregated QoS-NSLP states. The reservation-based PHR installs and maintains one reservation state per PHB, in all the nodes located in the communication path. This state is identified by the <PHB Class> value and it maintains the number of currently reserved resource units (or bandwidth). Thus, the QNE Ingress node signals only the resource units requested by each flow. These resource units, if admitted, are added to the currently reserved resources per PHB. For each PHB, a threshold is maintained that specifies the maximum number of resource units that can be reserved. This threshold could, for example, be statically configured. An example of how the admission control and its maintenance process occurs in the Interior nodes is described in Section 3 of [CsTa05]. The simplified concept that is used by the per-traffic class admission control process in the Interior nodes, is based on the following equation: last + p <= T,
Top   ToC   RFC5977 - Page 28
   where p is the requested bandwidth rate, T is the admission
   threshold, which reflects the maximum traffic volume that can be
   admitted in the traffic class, and last is a counter that records the
   aggregated sum of the signaled bandwidth rates of previous admitted
   flows.

   The PHB group reservation states maintained in the Interior nodes are
   soft states, which are refreshed by sending periodic refresh intra-
   domain RESERVE messages, which are initiated by the Ingress QNEs.  If
   a refresh message corresponding to a number of reserved resource
   units (i.e., bandwidth) is not received, the aggregated reservation
   state is decreased in the next refresh period by the corresponding
   amount of resources that were not refreshed.  The refresh period can
   be refined using a sliding window algorithm described in [RMD3].

   The reserved resources for a particular flow can also be explicitly
   released from a PHB reservation state by means of a intra-domain
   RESERVE release/tear message, which is generated by the Ingress QNEs.

   The use of explicit release enables the instantaneous release of the
   resources regardless of the length of the refresh period.  This
   allows a longer refresh period, which also reduces the number of
   periodic refresh messages.

   Note that both in the case of measurement- and (per-flow and
   aggregated) RMD reservation-based methods, the way in which the
   maximum bandwidth thresholds are maintained is out of the
   specification of this document.  However, when admission priorities
   are supported, the Maximum Allocation [RFC4125] or the Russian Dolls
   [RFC4127] bandwidth allocation models MAY be used.  In this case,
   three types of priority traffic classes within the same PHB, e.g.,
   Expedited Forwarding, can be differentiated.  These three different
   priority traffic classes, which are associated with the same PHB, are
   denoted in this document as PHB_low_priority, PHB_normal_priority,
   and PHB_high_priority, and are identified by the <PHB Class> value
   and the priority value, which is carried in the <Admission Priority>
   RMD-QSPEC parameter.

4.4. Transport of RMD-QOSM Messages

As mentioned in Section 1, the RMD-QOSM aims to support a number of additional requirements, e.g., Minimal impact on Interior node performance. Therefore, RMD-QOSM is designed to be very lightweight signaling with regard to the number of signaling message round trips and the amount of state established at involved signaling nodes with and without reduced state on QNEs. The actions allowed by a QNE Interior node are minimal (i.e., only those specified by the RMD- QOSM).
Top   ToC   RFC5977 - Page 29
   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.  Moreover, RMD signaling is targeted towards intra-domain
   signaling only.  Therefore, RMD-QOSM relies on the security and
   reliability support that is provided by the bound end-to-end session,
   which is running between the boundaries of the RMD domain (i.e., the
   RMD-QOSM QNE Edges), and the security provided by the D-mode.  This
   implies the use of the Datagram Mode.

   Therefore, the intra-domain messages used by the RMD-QOSM are
   intended to operate in the NTLP/GIST Datagram mode (see [RFC5971]).
   The NSLP functionality available in all RMD-QOSM-aware QoS-NSLP nodes
   requires the intra-domain GIST, via the QoS-NSLP RMF API see
   [RFC5974], to:

   * operate in unreliable mode.  This can be satisfied by passing this
     requirement from the QoS-NSLP layer to the GIST layer via the API
     Transfer-Attributes.

   * not create a message association state.  This requirement can be
     satisfied by a local policy, e.g., the QNE is configured to not
     create a message association state.

   * not create any NTLP routing state by the Interior nodes.  This can
     be satisfied by passing this requirement from the QoS-NSLP layer to
     the GIST layer via the API.  However, between the QNE Egress and
     QNE Ingress routing states SHOULD be created that are associated
     with intra-domain sessions and that can be used for the
     communication of GIST Data messages sent by a QNE Egress directly
     to a QNE Ingress.  This type of routing state associated with an
     intra-domain session can be generated and used in the following
     way:

   * When the QNE Ingress has to send an initial intra-domain RESERVE
     message, the QoS-NSLP sends this message by including, in the GIST
     API SendMessage primitive, the Unreliable and No security
     attributes.  In order to optimize this procedure, the RMD domain
     MUST be engineered in such a way that GIST will piggyback this NSLP
     message on a GIST Query message.  Furthermore, GIST sets the C-flag
     (C=1), see [RFC5971] and uses the Q-mode.  The GIST functionality
     in each QNE Interior node will receive the GIST Query message and
     by using the RecvMessage GIST API primitive it will pass the intra-
     domain RESERVE message to the QoS-NSLP functionality.  At the same
     time, the GIST functionality uses the Routing-State-Check boolean
     to find out if the QoS-NSLP needs to create a routing state.  The
     QoS-NSLP sets this boolean to inform GIST to not create a routing
     state and to forward the GIST Query further downstream with the
Top   ToC   RFC5977 - Page 30
     modified QoS-NSLP payload, which will include the modified intra-
     domain RESERVE message.  The intra-domain RESERVE is sent in the
     same way up to the QNE Egress.  The QNE Egress needs to create a
     routing state.

     Therefore, at the same moment that the GIST functionality passes
     the intra-domain RESERVE message, via the GIST RecvMessage
     primitive, to the QoS-NSLP, the QoS-NSLP sets the Routing-State-
     Check boolean such that a routing state is created.  The GIST
     creates the routing state using normal GIST procedures.  After this
     phase, the QNE Ingress and QNE Egress have, for the particular
     session, routing states that can route traffic directly from QNE
     Ingress to QNE Egress and from QNE Egress to QNE Ingress.  The
     routing state at the QNE Egress can be used by the QoS-NSLP and
     GIST to send an intra-domain RESPONSE or intra-domain NOTIFY
     directly to the QNE Ingress using GIST Data messages.  Note that
     this routing state is refreshed using normal GIST procedures.  Note
     that in the above description, it is considered that the QNE
     Ingress can piggyback the initial RESERVE (NSLP) message on the
     GIST Query message.  If the piggybacking of this NSLP (initial
     RESERVE) message would not be possible on the GIST Query message,
     then the GIST Query message sent by the QNE Ingress node would not
     contain any NSLP data.  This GIST Query message would only be
     processed by the QNE Egress to generate a routing state.

     After the QNE Ingress is informed that the routing state at the QNE
     Egress is initiated, it would have to send the initial RESERVE
     message using similar procedures as for the situation that it would
     send an intra-domain RESERVE message that is not an initial
     RESERVE, see next bullet.  This procedure is not efficient and
     therefore it is RECOMMENDED that the RMD domain MUST be engineered
     in such a way that the GIST protocol layer, which is processed on a
     QNE Ingress, will piggyback an initial RESERVE (NSLP) message on a
     GIST Query message that uses the Q-mode.

   * When the QNE Ingress needs to send an intra-domain RESERVE message
     that is not an initial RESERVE, then the QoS-NSLP sends this
     message by including in the GIST API SendMessage primitive such
     attributes that the use of the Datagram Mode is implied, e.g., the
     Unreliable attribute.  Furthermore, the Local policy attribute is
     set such that GIST sends the intra-domain RESERVE message in a
     Q-mode even if there is a routing state at the QNE Ingress.  In
     this way, the GIST functionality uses its local policy to send the
     intra-domain RESERVE message by piggybacking it on a GIST Data
     message and sending it in Q-mode even if there is a routing state
     for this session.  The intra-domain RESERVE message is piggybacked
     on the GIST Data message that is forwarded and processed by the QNE
     Interior nodes up to the QNE Egress.
Top   ToC   RFC5977 - Page 31
   The transport of the original (end-to-end) RESERVE message is
   accomplished in the following way:

   At the QNE Ingress, the original (end-to-end) RESERVE message is
   forwarded but ignored by the stateless or reduced-state nodes, see
   Figure 3.

   The intermediate (Interior) nodes are bypassed using multiple levels
   of NSLPID values (see [RFC5974]).  This is accomplished by marking
   the end-to-end RESERVE message, i.e., modifying the QoS-NSLP default
   NSLPID value to another NSLPID predefined value.

   The marking MUST be accomplished by the Ingress by modifying the
   QoS_NSLP default NSLPID value to a NSLPID predefined value.  In this
   way, the Egress MUST stop this marking process by reassigning the
   QoS-NSLP default NSLPID value to the original (end-to-end) RESERVE
   message.  Note that the assignment of these NSLPID values is a QoS-
   NSLP issue, which SHOULD be accomplished via IANA [RFC5974].

4.5. Edge Discovery and Message Addressing

Mainly, the Egress node discovery can be performed by using either the GIST discovery mechanism [RFC5971], manual configuration, or any other discovery technique. The addressing of signaling messages depends on which GIST transport mode is used. The RMD-QOSM/QoS-NSLP signaling messages that are processed only by the Edge nodes use the peer-peer addressing of the GIST Connection (C) mode. RMD-QOSM/QoS-NSLP signaling messages that are processed by all nodes of the Diffserv domain, i.e., Edges and Interior nodes, use the end- to-end addressing of the GIST Datagram (D) mode. Note that the RMD- QOSM cannot directly specify that the GIST Connection or the GIST Datagram mode SHOULD be used. This can only be specified by using, via the QoS-NSLP-RMF API, the GIST API Transfer-Attributes, such as Reliable or Unreliable, high or low level of security, and by the use of local policies. RMD QoS signaling messages that are addressed to the data path end nodes are intercepted by the Egress nodes. In particular, at the ingress and for downstream intra-domain messages, the RMD-QOSM instructs the GIST functionality, via the GIST API to do the following: * use unreliable and low level security Transfer-Attributes, * do not create a GIST routing state, and * use the D-mode MRI.
Top   ToC   RFC5977 - Page 32
   The intra-domain RESERVE messages can then be transported by using
   the Query D-mode; see Section 4.4.

   At the QNE Egress, and for upstream intra-domain messages, the RMD-
   QOSM instructs the GIST functionality, via the GIST API, to use among
   others:

   * unreliable and low level security Transfer-Attributes

   * the routing state associated with the intra-domain session to send
     an upstream intra-domain message directly to the QNE Ingress; see
     Section 4.4.

4.6. Operation and Sequence of Events

4.6.1. Basic Unidirectional Operation

This section describes the basic unidirectional operation and sequence of events/triggers of the RMD-QOSM. The following basic operation cases are distinguished: * Successful reservation (Section 4.6.1.1), * Unsuccessful reservation (Section 4.6.1.2), * RMD refresh reservation (Section 4.6.1.3), * RMD modification of aggregated reservation (Section 4.6.1.4), * RMD release procedure (Section 4.6.1.5.), * Severe congestion handling (Section 4.6.1.6.), * Admission control using congestion notification based on probing (Section 4.6.1.7.). The QNEs at the Edges of the RMD domain support the RMD QoS Model and end-to-end QoS Models, which process the RESERVE message differently. Note that the term end-to-end QoS Model applies to any QoS Model that is initiated and terminated outside the RMD-QOSM-aware domain. However, there might be situations where a QoS Model is initiated and/or terminated by the QNE Edges and is considered to be an end-to- end QoS Model. This can occur when the QNE Edges can also operate as either QNI or as QNR and at the same time they can operate as either sender or receiver of the data path. It is important to emphasize that the content of this section is used for the specification of the following RMD-QOSM/QoS-NSLP signaling schemes, when basic unidirectional operation is assumed: * "per-flow congestion notification based on probing"; * "per-flow RMD NSIS measurement-based admission control";
Top   ToC   RFC5977 - Page 33
   * "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.1.1,
   4.6.1.2, 4.6.1.3, 4.6.1.5, 4.6.1.4, and 4.6.1.6 applies to the RMD
   reservation-based and to the NSIS measurement-based admission control
   methods.  The described functionality in Section 4.6.1.7 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.

   When the QNE Edges maintain aggregated QoS-NSLP operational and
   reservation states, the RMD-QOSM functionality MAY accomplish an RMD
   modification procedure (see Section 4.6.1.4), instead of the
   reservation initiation procedure that is described in this
   subsection.  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 of [RFC5974] and it can be requested via the QoS-NSLP-
   RMF API described in [RFC5974].  The signaling scenarios described in
   this section are accomplished using the QoS-NSLP processing rules
   defined in [RFC5974], in combination with the RMF triggers sent via
   the QoS-NSLP-RMF API described in [RFC5974].

   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
Top   ToC   RFC5977 - Page 34
   4.1.2) and the "PDR Container" (Section 4.1.3) will always use the
   same value, such that within one RMD domain only one of the below
   described RMD-QOSM schemes is used at a time.

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

4.6.1.1. Successful Reservation
This section describes the operation of the RMD-QOSM where a reservation is successfully accomplished. The QNI generates the initial RESERVE message, and it is forwarded by the NTLP as usual [RFC5971].
4.6.1.1.1. Operation in Ingress Node
When an end-to-end reservation request (RESERVE) arrives at the Ingress node (QNE) (see Figure 8), it is processed based on the end- to-end QoS Model. Subsequently, the combination of <TMOD-1>, <PHB Class>, and <Admission Priority> is derived from the <QoS Desired> object of the initial QSPEC. The QNE Ingress MUST maintain information about the smallest MTU that is supported on the links within the RMD domain. The <Maximum Packet Size-1 (MPS)> value included in the end-to-end QoS Model <TMOD-1> parameter is compared with the smallest MTU value that is supported by the links within the RMD domain. If the "Maximum Packet Size-1 (MPS)" is larger than this smallest MTU value within the RMD domain, then the end-to-end reservation request is rejected (see Section 4.6.1.1.2). Otherwise, the admission process continues. The <TMOD-1> parameter contained in the original initiator QSPEC is mapped into the equivalent RMD-Qspec <TMOD-1> parameter representing only the peak bandwidth in the local RMD-QSPEC. This can be accomplished by setting the RMD-QSPEC <TMOD-1> fields as follows: token rate (r) = peak traffic rate (p), the bucket depth (b) = large, and the minimum policed unit (m) = large. Note that the bucket size, (b), is measured in bytes. Values of this parameter may range from 1 byte to 250 gigabytes; see [RFC2215]. Thus, the maximum value that (b) could be is in the order of 250
Top   ToC   RFC5977 - Page 35
   gigabytes.  The minimum policed unit, [m], is an integer measured in
   bytes and must be less than or equal to the Maximum Packet Size
   (MPS).  Thus, the maximum value that (m) can be is (MPS).  [Part94]
   and [TaCh99] describe a method of calculating the values of some
   Token Bucket parameters, e.g., calculation of large values of (m) and
   (b), when the token rate (r), peak rate (p), and MPS are known.

   The <Peak Data Rate-1 (p)> value of the end-to-end QoS Model <TMOD-1>
   parameter is copied into the <Peak Data Rate-1 (p)> value of the
   <Peak Data Rate-1 (p)> value of the local RMD-Qspec <TMOD-1>.

   The MPS value of the end-to-end QoS Model <TMOD-1> parameter is
   copied into the MPS value of the local RMD-Qspec <TMOD-1>.

   If the initial QSPEC does not contain the <PHB Class> parameter, then
   the selection of the <PHB Class> that is carried by the intra-domain
   RMD-QSPEC is defined by a local policy similar to the procedures
   discussed in [RFC2998] and [RFC3175].

   For example, in the situation that the initial QSPEC is used by the
   IntServ Controlled Load QOSM, then the Expedited Forwarding (EF) PHB
   is appropriate to set the <PHB Class> parameter carried by the intra-
   domain RMD-QSPEC (see [RFC3175]).

   If the initial QSPEC does not carry the <Admission Priority>
   parameter, then the <Admission Priority> parameter in the RMD-QSPEC
   will not be populated.  If the initial QSPEC does not carry the
   <Admission Priority> parameter, but it carries other priority
   parameters, then it is considered that Edges, as being stateful
   nodes, are able to control the priority of the sessions that are
   entering or leaving the RMD domain in accordance with the priority
   parameters.

   Note that the RMF reservation states (see Section 4.3) in the QNE
   Edges store the value of the <Admission Priority> parameter that is
   used within the RMD domain in case of preemption and severe
   congestion situations (see Section 4.6.1.6).

   If the RMD domain supports preemption during the admission control
   process, then the QNE Ingress node can support the building blocks
   specified in [RFC5974] and during the admission control process use
   the example preemption handling algorithm described in Appendix A.7.

   Note that in the above described case, the QNE Egress uses, if
   available, the tunneled initial priority parameters, which can be
   interpreted by the QNE Egress.
Top   ToC   RFC5977 - Page 36
   If the initial QSPEC carries the <Excess Treatment> parameter, then
   the QNE Ingress and QNE Egress nodes MUST control the excess traffic
   that is entering or leaving the RMD domain in accordance with the
   <Excess Treatment> parameter.  Note that the RMD-QSPEC does not carry
   the <Excess Treatment> parameter.

   If the requested <TMOD-1> parameter carried by the initial QSPEC,
   cannot be satisfied, then an end-to-end RESPONSE message has to be
   generated.  However, in order to decide whether the end-to-end
   reservation request was locally (at the QNE Ingress) satisfied, a
   local (at the QNE_Ingress) RMD-QOSM admission control procedure also
   has to be performed.  In other words, the RMD-QOSM functionality has
   to verify whether the value included in the <Peak Data Rate-1 (p)>
   field of RMD-QOSM <TMOD-1> can be reserved and stored in the RMD-QOSM
   reservation states (see Sections 4.6.1.1.2 and 4.3).

   An initial QSPEC object MUST be included in the end-to-end RESPONSE
   message.  The parameters included in the QSPEC <QoS Reserved> object
   are copied from the original <QoS Desired> values.

   The <E> flag associated with the QSPEC <QoS Reserved> object and the
   <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter are
   set.  In addition, the <INFO-SPEC> object is included in the end-to-
   end RESPONSE message.  The error code used by this <INFO-SPEC> is:

   Error severity class: Transient Failure Error code value: Reservation
   failure

   Furthermore, all of the other RESPONSE parameters are set according
   to the end-to-end QoS Model or according to [RFC5974] and [RFC5975].

   If the request was satisfied locally (see Section 4.3), the Ingress
   QNE node generates two RESERVE messages: one intra-domain and one
   end-to-end RESERVE message.  Note however, that when the aggregated
   QoS-NSLP operational and reservation states are used by the QNE
   Ingress, then the generation of the intra-domain RESERVE message
   depends on the availability of the aggregated QoS-NSLP operational
   state.  If this aggregated QoS-NSLP operational state is available,
   then the RMD modification of aggregated reservations described in
   Section 4.6.1.4 is used.

   It is important to note that when the "per-flow RMD reservation-
   based" scenario is used within the RMD domain, the retransmission
   within the RMD domain SHOULD be disallowed.  The reason for this is
   related to the fact that the QNI Interior nodes are not able to
   differentiate between a retransmitted RESERVE message associated with
   a certain session and an initial RESERVE message belonging to another
   session.  However, the QNE Ingress have to report a failure situation
Top   ToC   RFC5977 - Page 37
   upstream.  When the QNE Ingress transmits the (intra-domain or end-
   to-end) RESERVE with the <RII> object set, it waits for a RESPONSE
   from the QNE Egress for a QOSNSLP_REQUEST_RETRY period.

   If the QNE Ingress transmitted an intra-domain or end-to-end RESERVE
   message with the <RII> object set and it fails to receive the
   associated intra-domain or end-to-end RESPONSE, respectively, after
   the QOSNSLP_REQUEST_RETRY period expires, it considers that the
   reservation failed.  In this case, the QNE Ingress SHOULD generate an
   end-to-end RESPONSE message that will include, among others, an
   <INFO-SPEC> object.  The error code used by this <INFO-SPEC> object
   is:

      Error severity class: Transient Failure
      Error code value: Reservation failure

   Furthermore, all of the other RESPONSE parameters are set according
   to the end-to-end QoS Model or according to [RFC5974] and [RFC5975].

   Note however, that if the retransmission within the RMD domain is not
   disallowed, then the procedure described in Appendix A.8 SHOULD be
   used on QNE Interior nodes; see also [Chan07].  In this case, the
   stateful QNE Ingress uses the retransmission procedure described in
   [RFC5974].

   If a rerouting takes place, then the stateful QNE Ingress is
   following the procedures specified in [RFC5974].

   At this point, the intra-domain and end-to-end operational states
   MUST be initiated or modified according to the REQUIRED binding
   procedures.  The way of how the BOUND-SESSION-IDs are initiated and
   maintained in the intra-domain and end-to-end QoS-NSLP operational
   states is described in Sections 4.3.1 and 4.3.2.

   These two messages are bound together in the following way.  The end-
   to-end RESERVE SHOULD contain, in the BOUND-SESSION-ID, the SESSION-
   ID of its bound intra-domain session.

   Furthermore, if the QNE Edge nodes maintain intra-domain per-flow
   QoS-NSLP reservation states, then the value of Binding_Code MUST be
   set to code "Tunnel and end-to-end sessions" (see Section 4.3.2).

   In addition to this, the intra-domain and end-to-end RESERVE messages
   are bound using the Message binding procedure described in [RFC5974].
Top   ToC   RFC5977 - Page 38
   In particular the <MSG-ID> object is included in the intra-domain
   RESERVE message and its bound <BOUND-MSG-ID> object is carried by the
   end-to-end RESERVE message.  Furthermore, the <Message_Binding_Type>
   flag is SET (value is 1), such that the message dependency is
   bidirectional.

   If the QoS-NSLP Edges maintain aggregated intra-domain QoS-NSLP
   operational states, then the value of Binding_Code MUST be set to
   code "Aggregated sessions".

   Furthermore, in this case, the retransmission within the RMD domain
   is allowed and the procedures described in Appendix A.8 SHOULD be
   used on QNE Interior nodes.  This is necessary due to the fact that
   when retransmissions are disallowed, then the associated with (micro)
   flows belonging to the aggregate will loose their reservations.  Note
   that, in this case, the stateful QNE Ingress uses the retransmission
   procedure described in [RFC5974].

   The intra-domain RESERVE message is associated with the (local NTLP)
   SESSION-ID mentioned above.  The selection of the IP source and IP
   destination address of this message depends on how the different
   inter-domain (end-to-end) flows are aggregated by the QNE Ingress
   node (see Section 4.3.1).  As described in Section 4.3.1, the QNE
   Edges maintain either per-flow, or aggregated QoS-NSLP reservation
   states for the RMD QoS Model, which are identified by (local NTLP)
   SESSION-IDs (see [RFC5971]).  Note that this NTLP SESSION-ID is a
   different one than the SESSION-ID associated with the end-to-end
   RESERVE message.

   If no QoS-NSLP aggregation procedure at the QNE Edges is supported,
   then the IP source and IP destination address of this message MUST be
   equal to the IP source and IP destination addresses of the data flow.
   The intra-domain RESERVE message is sent using the NTLP datagram mode
   (see Sections 4.4 and 4.5).  Note that the GIST Datagram mode can be
   selected using the unreliable GIST API Transfer-Attributes.  In
   addition, the intra-domain RESERVE (RMD-QSPEC) message MUST include a
   PHR container (PHR_Resource_Request) and the RMD QOSM <QoS Desired>
   object.

   The end-to-end RESERVE message includes the initial QSPEC and it is
   sent towards the Egress QNE.

   Note that after completing the initial discovery phase, the GIST
   Connection mode can be used between the QNE Ingress and QNE Egress.
   Note that the GIST Connection mode can be selected using the reliable
   GIST API Transfer-Attributes.
Top   ToC   RFC5977 - Page 39
   The end-to-end RESERVE message is forwarded using the GIST forwarding
   procedure to bypass the Interior stateless or reduced-state QNE
   nodes; see Figure 8.  The bypassing procedure is described in Section
   4.4.

   At the QNE Ingress, the end-to-end RESERVE message is marked, i.e.,
   modifying the QoS-NSLP default NSLPID value to another NSLPID
   predefined value that will be used by the GIST message carrying the
   end-to-end RESPONSE message to bypass the QNE Interior nodes.  Note
   that the QNE Interior nodes (see [RFC5971]) are configured to handle
   only certain NSLP-IDs (see [RFC5974]).

   Furthermore, note that the initial discovery phase and the process of
   sending the end-to-end RESERVE message towards the QNE Egress MAY be
   done simultaneously.  This can be accomplished only if the GIST
   implementation is configured to perform that, e.g., via a local
   policy.  However, the selection of the discovery procedure cannot be
   selected by the RMD-QOSM.

   The (initial) intra-domain RESERVE message MUST be sent by the QNE
   Ingress and it MUST contain the following values (see the QoS-NSLP-
   RMF API described in [RFC5974]):

      *  the <RSN> object, whose value is generated and processed as
         described in [RFC5974];

      *  the <SCOPING> flag MUST NOT be set, meaning that a default
         scoping of the message is used.  Therefore, the QNE Edges MUST
         be configured as RMD boundary nodes and the QNE Interior nodes
         MUST be configured as Interior (intermediary) nodes;

      *  the <RII> MUST be included in this message, see [RFC5974];

      *  the <REPLACE> flag MUST be set to FALSE = 0;

   *  The value of the <Message ID> value carried by the <MSG-ID> object
      is set according to [RFC5974].  The value of the
      <Message_Binding_Type> is set to "1".

   *  the value of the <REFRESH-PERIOD> object MUST be calculated and
      set by the QNE Ingress node as described in Section 4.6.1.3;

   *  the value of the <PACKET-CLASSIFIER> object is associated with the
      path-coupled routing Message Routing Message (MRM), since RMD-QOSM
      is used with the path-coupled MRM.  The flag that has to be set is
      the <T> flag (traffic class) meaning that the packet
      classification of packets is based on the <DSCP> value included in
      the IP header of the packets.  Note that the <DSCP> value used in
Top   ToC   RFC5977 - Page 40
      the MRI can be derived by the value of <PHB Class> parameter,
      which MUST be carried by the intra-domain RESERVE message.  Note
      that the QNE Ingress being a QNI for the intra-domain session it
      can pass this value to GIST, via the GIST API.

   *  the PHR resource units MUST be included in the <Peak Data Rate-1
      (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the <QoS
      Desired> object.

      When the QNE Edges use per-flow intra-domain QoS-NSLP states, then
      the <Peak Data Rate-1 (p)> value included in the initial QSPEC
      <TMOD-1> parameter is copied into the <Peak Data Rate-1 (p)> value
      of the local RMD-QSPEC <TMOD-1> parameter.

      When the QNE Edges use aggregated intra-domain QoS-NSLP
      operational states, then the <Peak Data Rate-1 (p)> value of the
      local RMD-QSPEC <TMOD-1> parameter can be obtained by using the
      bandwidth aggregation method described in Section 4.3.1;

   *  the value of the <PHB Class> parameter can be defined by using the
      method of copying the <PHB Class> parameter carried by the initial
      QSPEC into the <PHB Class> carried by the RMD-QSPEC, which is
      described above in this subsection.

   *  the value of the <Parameter ID> field of the PHR container MUST be
      set to "17", (i.e., PHR_Resource_Request).

   *  the value of the <Admitted Hops> parameter in the PHR container
      MUST be set to "1".  Note that during a successful reservation,
      each time an RMD-QOSM-aware node processes the RMD-QSPEC, the
      <Admitted Hops> parameter is increased by one.

   *  the value of the <Hop_U> parameter in the PHR container MUST be
      set to "0".

   *  the value of the <Max Admitted Hops> is set to "0".

   *  If the initial QSPEC carried an <Admission Priority> parameter,
      then this parameter SHOULD be copied into the RMD-QSPEC and
      carried by the (initiating) intra-domain RESERVE.

      Note that for the RMD-QOSM, a reservation established without an
      <Admission Priority> parameter is equivalent to a reservation with
      <Admission Priority> value of 1.
Top   ToC   RFC5977 - Page 41
      Note that, in this case, each admission priority is associated
      with a priority traffic class.  The three priority traffic classes
      (PHB_low_priority, PHB_normal_priority, and PHB_high_priority) MAY
      be associated with the same PHB (see Section 4.3.3).

   *  In a single RMD domain case, the PDR container MAY not be included
      in the message.

   Note that the intra-domain RESERVE message does not carry the <BOUND-
   SESSION-ID> object.  The reason for this is that the end-to-end
   RESERVE carries, in the <BOUND-SESSION-ID> object, the <SESSION-ID>
   value of the intra-domain session.

   When an end-to-end RESPONSE message is received by the QNE Ingress
   node, which was sent by a QNE Egress node (see Section 4.6.1.1.3),
   then it is processed according to [RFC5974] and end-to-end QoS Model
   rules.

   When an intra-domain RESPONSE message is received by the QNE Ingress
   node, which was sent by a QNE Egress (see Section 4.6.1.1.3), it uses
   the QoS-NSLP procedures to match it to the earlier sent intra-domain
   RESERVE message.  After this phase, the RMD-QSPEC has to be
   identified and processed.

   The RMD QOSM reservation has been successful if the <M> bit carried
   by the "PDR Container" is equal to "0" (i.e., not set).

   Furthermore, the <INFO-SPEC> object is processed as defined in the
   QoS-NSLP specification.  In the case of successful reservation, the
   <INFO-SPEC> object MUST have the following values:

   * Error severity class: Success
   * Error code value: Reservation successful

   If the end-to-end RESPONSE message has to be forwarded to a node
   outside the RMD-QOSM-aware domain, then the values of the objects
   contained in this message (i.e., <RII> <RSN>, <INFO-SPEC>, [<QSPEC>])
   MUST be set by the QoS-NSLP protocol functions of the QNE.  If an
   end-to-end QUERY is received by the QNE Ingress, then the same
   bypassing procedure has to be used as the one applied for an end-to-
   end RESERVE message.  In particular, it is forwarded using the GIST
   forwarding procedure to bypass the Interior stateless or reduced-
   state QNE nodes.
Top   ToC   RFC5977 - Page 42
4.6.1.1.2. Operation in the Interior Nodes
Each QNE Interior node MUST use the QoS-NSLP and RMD-QOSM parameters of the intra-domain RESERVE (RMD-QSPEC) message as follows (see QoS- NSLP-RMF API described in [RFC5974]): * the values of the <RSN>, <RII>, <PACKET-CLASSIFIER>, <REFRESH- PERIOD>, objects MUST NOT be changed. The Interior node is informed by the <PACKET-CLASSIFIER> object that the packet classification SHOULD be done on the <DSCP> value. The flag that has to be set in this case is the <T> flag (traffic class). The value of the <DSCP> value MUST be obtained via the MRI parameters that the QoS-NSLP receives from GIST. A QNE Interior MUST be able to associate the value carried by the RMD- QSPEC <PHB Class> parameter and the <DSCP> value obtained via GIST. This is REQUIRED, because there are situations in which the <PHB Class> parameter is not carrying a <DSCP> value but a PHB ID code, see Section 4.1.1. * the flag <REPLACE> MUST be set to FALSE = 0; * when the RMD reservation-based methods, described in Section 4.3.1 and 4.3.3, are used, the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter is used by the QNE Interior node for admission control. Furthermore, if the <Admission Priority> parameter is carried by the RMD-QOSM <QoS Desired> object, then this parameter is processed as described in the following bullets. * in the case of the RMD reservation-based procedure, and if these resources are admitted (see Sections 4.3.1 and 4.3.3), they are added to the currently reserved resources. Furthermore, the value of the <Admitted Hops> parameter in the PHR container has to be increased by one. * If the bandwidth allocated for the PHB_high_priority traffic is fully utilized, and a high priority request arrives, other policies on allocating bandwidth can be used, which are beyond the scope of this document. * If the RMD domain supports preemption during the admission control process, then the QNE Interior node can support the building blocks specified in the [RFC5974] and during the admission control process use the preemption handling algorithm specified in Appendix A.7.
Top   ToC   RFC5977 - Page 43
   *  in the case of the RMD measurement-based method (see Section
      4.3.2), and if the requested into the <Peak Data Rate-1 (p)> value
      of the local RMD-QSPEC <TMOD-1> parameter is admitted, using a
      measurement-based admission control (MBAC) algorithm, then the
      number of this resource will be used to update the MBAC algorithm
      according to the operation described in Section 4.3.2.

4.6.1.1.3. Operation in the Egress Node
When the end-to-end RESERVE message is received by the egress node, it is only forwarded further, towards QNR, if the processing of the intra-domain RESERVE(RMD-QSPEC) message was successful at all nodes in the RMD domain. In this case, the QNE Egress MUST stop the marking process that was used to bypass the QNE Interior nodes by reassigning the QoS-NSLP default NSLPID value to the end-to-end RESERVE message (see Section 4.4). Furthermore, the carried <BOUND- SESSION-ID> object associated with the intra-domain session MUST be removed after processing. Note that the received end-to-end RESERVE was tunneled within the RMD domain. Therefore, the tunneled initial QSPEC carried by the end-to-end RESERVE message has to be processed/set according to the [RFC5975] specification. If a rerouting takes place, then the stateful QNE Egress is following the procedures specified in [RFC5974]. At this point, the intra-domain and end-to-end operational states MUST be initiated or modified according to the REQUIRED binding procedures. The way in which the BOUND-SESSION-IDs are initiated and maintained in the intra-domain and end-to-end QoS-NSLP operational states is described in Sections 4.3.1 and 4.3.2. If the processing of the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain, then the inter-domain (end-to-end) reservation is considered to have failed. Furthermore, if the initial QSPEC object used an object combination of type 1 or 2 where the <QoS Available> is populated, and the intra- domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain MUST be considered that the <QoS Available> is not satisfied and that the inter-domain (end-to-end) reservation is considered to have failed. Furthermore, note that when the QNE Egress uses per-flow intra-domain QoS-NSLP operational states (see Sections 4.3.2 and 4.3.3), the QNE Egress SHOULD support the message binding procedure described in [RFC5974], which can be used to synchronize the arrival of the end-
Top   ToC   RFC5977 - Page 44
   to-end RESERVE and the intra-domain RESERVE (RMD-QSPEC) messages, see
   Section 5.7, and QoS-NSLP-RMF API described in [RFC5974].  Note that
   the intra-domain RESERVE message carries the <MSG-ID> object and its
   bound end-to-end RESERVE message carries the <BOUND-MSG-ID> object.
   Both these objects carry the <Message_Binding_Type> flag set to the
   value of "1".  If these two messages do not arrive during the time
   defined by the MsgIDWait timer, then the reservation is considered to
   have failed.  Note that the timer has to be preconfigured and it has
   to have the same value in the RMD domain.  In this case, an end-to-
   end RESPONSE message, see QoS-NSLP-RMF API described in [RFC5974], is
   sent towards the QNE Ingress with the following <INFO-SPEC> values:

   Error class: Transient Failure
   Error code: Mismatch synchronization between end-to-end RESERVE
   and intra-domain RESERVE

   When the intra-domain RESERVE (RMD-QSPEC) is received by the QNE
   Egress node of the session associated with the intra-domain
   RESERVE(RMD-QSPEC) (the PHB session) with the session included in its
   <BOUND-SESSION-ID> object MUST be bound according to the
   specification given in [RFC5974].  The SESSION-ID included in the
   BOUND-SESSION-ID parameter stored in the intra-domain QoS-NSLP
   operational state object is the SESSION-ID of the session associated
   with the end-to-end RESERVE message(s).  Note that if the QNE Edge
   nodes maintain per-flow intra-domain QoS-NSLP operational states,
   then the value of Binding_Code = (Tunnel and end-to-end sessions) is
   used.  If the QNE Edge nodes maintain per-aggregated QoS-NSLP intra-
   domain reservation states, then the value of Binding_Code =
   (Aggregated sessions), see Sections 4.3.1 and 4.3.2.

   If the RMD domain supports preemption during the admission control
   process, then the QNE Egress node can support the building blocks
   specified in the [RFC5974] and during the admission control process
   use the example preemption handling algorithm described in Appendix
   A.7.

   The end-to-end RESERVE message is generated/forwarded further
   upstream according to the [RFC5974] and [RFC5975] specifications.
   Furthermore, the <B> (BREAK) QoS-NSLP flag in the end-to-end RESERVE
   message MUST NOT be set, see the QoS-NSLP-RMF API described in QoS-
   NSLP.
Top   ToC   RFC5977 - Page 45
QNE(Ingress)      QNE(Interior)         QNE(Interior)     QNE(Egress)
NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
    |                    |                   |                    |
RESERVE                  |                   |                    |
--->|                    |                   |     RESERVE        |
    |------------------------------------------------------------>|
    |RESERVE(RMD-QSPEC)  |                   |                    |
    |------------------->|                   |                    |
    |                    |RESERVE(RMD-QSPEC) |                    |
    |                    |------------------>|                    |
    |                    |                   | RESERVE(RMD-QSPEC) |
    |                    |                   |------------------->|
    |                    |RESPONSE(RMD-QSPEC)|                    |
    |<------------------------------------------------------------|
    |                    |                   |                RESERVE
    |                    |                   |                    |-->
    |                    |                   |                RESPONSE
    |                    |                   |                    |<--
    |                    |RESPONSE           |                    |
    |<------------------------------------------------------------|
RESPONSE                 |                   |                    |
<---|                    |                   |                    |

  Figure 8: Basic operation of successful reservation procedure
            used by the RMD-QOSM

   The QNE Egress MUST generate an intra-domain RESPONSE (RMD-Qspec)
   message.  The intra-domain RESPONSE (RMD-QSPEC) message MUST be sent
   to the QNE Ingress node, i.e., the previous stateful hop by using the
   procedures described in Sections 4.4 and 4.5.

   The values of the RMD-QSPEC that are carried by the intra-domain
   RESPONSE message MUST be used and/or set in the following way (see
   the QoS-NSLP-RMF API described in [RFC5974]):

   *  the <RII> object carried by the intra-domain RESERVE message, see
      Section 4.6.1.1.1, has to be copied and carried by the intra-
      domain RESPONSE message.

   *  the value of the <Parameter ID> field of the PDR container MUST be
      set to "23" (i.e., PDR_Reservation_Report);

   *  the value of the <M> field of the PDR container MUST be equal to
      the value of the <M> parameter of the PHR container that was
      carried by its associated intra-domain RESERVE(RMD-QSPEC) message.
      This is REQUIRED since the value of the <M> parameter is used to
      indicate the status if the RMD reservation request to the Ingress
      Edge.
Top   ToC   RFC5977 - Page 46
   If the binding between the intra-domain session and the end-to-end
   session uses a Binding_Code that is (Aggregated sessions), and there
   is no aggregated QoS-NSLP operational state associated with the
   intra-domain session available, then the RMD modification of
   aggregated reservation procedure described in Section 4.6.1.4 can be
   used.

   If the QNE Egress receives an end-to-end RESPONSE message, it is
   processed and forwarded towards the QNE Ingress.  In particular, the
   non-default values of the objects contained in the end-to-end
   RESPONSE message MUST be used and/or set by the QNE Egress as follows
   (see the QoS-NSLP-RMF API described in [RFC5974]):

   *  the values of the <RII>, <RSN>, <INFO-SPEC>, [<QSPEC>] objects are
      set according to [RFC5974] and/or [RFC5975].  The <INFO-SPEC>
      object SHOULD be set by the QoS-NSLP functionality.  In the case
      of successful reservation, the <INFO-SPEC> object SHOULD have the
      following values:

      Error severity class: Success Error code value: Reservation
      successful

   *  furthermore, an initial QSPEC object MUST be included in the end-
      to-end RESPONSE message.  The parameters included in the QSPEC
      <QoS Reserved> object are copied from the original <QoS Desired>
      values.

   The end-to-end RESPONSE message is delivered as normal, i.e., is
   addressed and sent to its upstream QoS-NSLP neighbor, i.e., the QNE
   Ingress node.

   Note that if a QNE Egress receives an end-to-end QUERY that was
   bypassed through the RMD domain, it MUST stop the marking process
   that was used to bypass the QNE Interior nodes.  This can be done by
   reassigning the QoS-NSLP default NSLPID value to the end-to-end QUERY
   message; see Section 4.4.



(page 46 continued on part 3)

Next Section