RFC 5977
RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv
Pages: 128
Experimental
Experimental
Part 2 of 5 – Pages 23 to 46
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-
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].
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).
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
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,
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).
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
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.
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.
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";
* "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
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
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.
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
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].
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.
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
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.
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.
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.
* 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-
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.
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.
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)