RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv :: RFC5977
Internet Engineering Task Force (IETF) A. Bader
Request for Comments: 5977 L. Westberg
Category: Experimental Ericsson
ISSN: 2070-1721 G. Karagiannis
University of Twente
C. Kappler
ck technology concepts
T. Phelan
Sonus
October 2010
RMD-QOSM: The NSIS Quality-of-Service Model
for Resource Management in Diffserv
Abstract
This document describes a Next Steps in Signaling (NSIS) Quality-of-
Service (QoS) Model for networks that use the Resource Management in
Diffserv (RMD) concept. RMD is a technique for adding admission
control and preemption function to Differentiated Services (Diffserv)
networks. The RMD QoS Model allows devices external to the RMD
network to signal reservation requests to Edge nodes in the RMD
network. The RMD Ingress Edge nodes classify the incoming flows into
traffic classes and signals resource requests for the corresponding
traffic class along the data path to the Egress Edge nodes for each
flow. Egress nodes reconstitute the original requests and continue
forwarding them along the data path towards the final destination.
In addition, RMD defines notification functions to indicate overload
situations within the domain to the Edge nodes.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5977.
Bader, et al. Experimental [Page 1]
RFC 5977 RMD-QOSM October 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Overview of RMD and RMD-QOSM ....................................7
3.1. RMD ........................................................7
3.2. Basic Features of RMD-QOSM ................................10
3.2.1. Role of the QNEs ...................................10
3.2.2. RMD-QOSM/QoS-NSLP Signaling ........................11
3.2.3. RMD-QOSM Applicability and Considerations ..........13
4. RMD-QOSM, Detailed Description .................................15
4.1. RMD-QSPEC Definition ......................................16
4.1.1. RMD-QOSM and ..........16
4.1.2. PHR Container ......................................17
4.1.3. PDR Container ......................................20
4.2. Message Format ............................................23
4.3. RMD Node State Management .................................23
4.3.1. Aggregated Operational and Reservation
States at the QNE Edges ............................23
4.3.2. Measurement-Based Method ...........................25
4.3.3. Reservation-Based Method ...........................27
4.4. Transport of RMD-QOSM Messages ............................28
4.5. Edge Discovery and Message Addressing .....................31
4.6. Operation and Sequence of Events ..........................32
4.6.1. Basic Unidirectional Operation .....................32
4.6.1.1. Successful Reservation ....................34
4.6.1.2. Unsuccessful Reservation ..................46
4.6.1.3. RMD Refresh Reservation ...................50
4.6.1.4. RMD Modification of Aggregated
Reservations ..............................54
4.6.1.5. RMD Release Procedure .....................55
4.6.1.6. Severe Congestion Handling ................64
Bader, et al. Experimental [Page 2]
RFC 5977 RMD-QOSM October 2010
4.6.1.7. Admission Control Using Congestion
Notification Based on Probing .............70
4.6.2. Bidirectional Operation ............................73
4.6.2.1. Successful and Unsuccessful Reservations ..77
4.6.2.2. Refresh Reservations ......................82
4.6.2.3. Modification of Aggregated Intra-Domain
QoS-NSLP Operational Reservation States ...82
4.6.2.4. Release Procedure .........................83
4.6.2.5. Severe Congestion Handling ................84
4.6.2.6. Admission Control Using Congestion
Notification Based on Probing .............87
4.7. Handling of Additional Errors .............................89
5. Security Considerations ........................................89
5.1. Introduction ..............................................89
5.2. Security Threats ..........................................91
5.2.1. On-Path Adversary ..................................92
5.2.2. Off-Path Adversary .................................94
5.3. Security Requirements .....................................94
5.4. Security Mechanisms .......................................94
6. IANA Considerations ............................................97
6.1. Assignment of QSPEC Parameter IDs .........................97
7. Acknowledgments ................................................97
8. References .....................................................97
8.1. Normative References ......................................97
8.2. Informative References ....................................98
Appendix A. Examples .............................................101
A.1. Example of a Re-Marking Operation during Severe
Congestion in the Interior Nodes .........................101
A.2. Example of a Detailed Severe Congestion Operation in the
Egress Nodes .............................................107
A.3. Example of a Detailed Re-Marking Admission Control
(Congestion Notification) Operation in Interior Nodes ....111
A.4. Example of a Detailed Admission Control (Congestion
Notification) Operation in Egress Nodes ..................112
A.5. Example of Selecting Bidirectional Flows for Termination
during Severe Congestion .................................113
A.6. Example of a Severe Congestion Solution for
Bidirectional Flows Congested Simultaneously on Forward
and Reverse Paths ........................................113
A.7. Example of Preemption Handling during Admission Control ..117
A.8. Example of a Retransmission Procedure within the RMD
Domain ...................................................120
A.9. Example on Matching the Initiator QSPEC to the Local
RMD-QSPEC ................................................122
Bader, et al. Experimental [Page 3]
RFC 5977 RMD-QOSM October 2010
1. Introduction
This document describes a Next Steps in Signaling (NSIS) QoS Model
for networks that use the Resource Management in Diffserv (RMD)
framework ([RMD1], [RMD2], [RMD3], and [RMD4]). RMD adds admission
control to Diffserv networks and allows nodes external to the
networks to dynamically reserve resources within the Diffserv
domains.
The Quality-of-Service NSIS Signaling Layer Protocol (QoS-NSLP)
[RFC5974] specifies a generic protocol for carrying QoS signaling
information end-to-end in an IP network. Each network along the end-
to-end path is expected to implement a specific QoS Model (QOSM)
specified by the QSPEC template [RFC5975] that interprets the
requests and installs the necessary mechanisms, in a manner that is
appropriate to the technology in use in the network, to ensure the
delivery of the requested QoS. This document specifies an NSIS QoS
Model for RMD networks (RMD-QOSM), and an RMD-specific QSPEC (RMD-
QSPEC) for expressing reservations in a suitable form for simple
processing by internal nodes.
They are used in combination with the QoS-NSLP to provide QoS
signaling service in an RMD network. Figure 1 shows an RMD network
with the respective entities.
Stateless or reduced-state Egress
Ingress RMD Nodes Node
Node (Interior Nodes; I-Nodes) (Stateful
(Stateful | | | RMD QoS
RMD QoS-NLSP | | | NSLP Node)
Node) V V V
+-------+ Data +------+ +------+ +------+ +------+
|-------|--------|------|------|------|-------|------|---->|------|
| | Flow | | | | | | | |
|Ingress| |I-Node| |I-Node| |I-Node| |Egress|
| | | | | | | | | |
+-------+ +------+ +------+ +------+ +------+
=================================================>
<=================================================
Signaling Flow
Figure 1: Actors in the RMD-QOSM
Many network scenarios, such as the "Wired Part of Wireless Network"
scenario, which is described in Section 8.4 of [RFC3726], require
that the impact of the used QoS signaling protocol on the network
performance should be minimized. In such network scenarios, the
performance of each network node that is used in a communication path
Bader, et al. Experimental [Page 4]
RFC 5977 RMD-QOSM October 2010
has an impact on the end-to-end performance. As such, the end-to-end
performance of the communication path can be improved by optimizing
the performance of the Interior nodes. One of the factors that can
contribute to this optimization is the minimization of the QoS
signaling protocol processing load and the minimization of the number
of states on each Interior node.
Another requirement that is imposed by such network scenarios is that
whenever a severe congestion situation occurs in the network, the
used QoS signaling protocol should be able to solve them. In the
case of a route change or link failure, a severe congestion situation
may occur in the network. Typically, routing algorithms are able to
adapt and change their routing decisions to reflect changes in the
topology and traffic volume. In such situations, the rerouted
traffic will have to follow a new path. Interior nodes located on
this new path may become overloaded, since they suddenly might need
to support more traffic than for which they have capacity. These
severe congestion situations will severely affect the overall
performance of the traffic passing through such nodes.
RMD-QOSM is an edge-to-edge (intra-domain) QoS Model that, in
combination with the QoS-NSLP and QSPEC specifications, is designed
to support the requirements mentioned above:
o Minimal impact on Interior node performance;
o Increase of scalability;
o Ability to deal with severe congestion
Internally to the RMD network, RMD-QOSM together with QoS-NSLP
[RFC5974] defines a scalable QoS signaling model in which per-flow
QoS-NSLP and NSIS Transport Layer Protocol (NTLP) states are not
stored in Interior nodes but per-flow signaling is performed (see
[RFC5974]) at the Edges.
In the RMD-QOSM, only routers at the Edges of a Diffserv domain
(Ingress and Egress nodes) support the (QoS-NSLP) stateful operation;
see Section 4.7 of [RFC5974]. Interior nodes support either the
(QoS-NSLP) stateless operation or a reduced-state operation with
coarser granularity than the Edge nodes.
After the terminology in Section 2, we give an overview of RMD and
the RMD-QOSM in Section 3. This document specifies several RMD-QOSM/
QoS-NSLP signaling schemes. In particular, Section 3.2.3 identifies
which combination of sections are used for the specification of each
RMD-QOSM/QoS-NSLP signaling scheme. In Section 4 we give a detailed
description of the RMD-QOSM, including the role of QoS NSIS entities
Bader, et al. Experimental [Page 5]
RFC 5977 RMD-QOSM October 2010
(QNEs), the definition of the QSPEC, mapping of QSPEC generic
parameters onto RMD-QOSM parameters, state management in QNEs, and
operation and sequence of events. Section 5 discusses security
issues.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology defined by GIST [RFC5971] and QoS-NSLP [RFC5974]
applies to this document.
In addition, the following terms are used:
NSIS domain: an NSIS signaling-capable domain.
RMD domain: an NSIS domain that is capable of supporting the RMD-QOSM
signaling and operations.
Edge node: a QoS-NSLP node on the boundary of some administrative
domain that connects one NSIS domain to a node in either another NSIS
domain or a non-NSIS domain.
NSIS-aware node: a node that is aware of NSIS signaling and RMD-QOSM
operations, such as severe congestion detection and Differentiated
Service Code Point (DSCP) marking.
NSIS-unaware node: a node that is unaware of NSIS signaling, but is
aware of RMD-QOSM operations such as severe congestion detection and
DSCP marking.
Ingress node: an Edge node in its role in handling the traffic as it
enters the NSIS domain.
Egress node: an Edge node in its role in handling the traffic as it
leaves the NSIS domain.
Interior node: a node in an NSIS domain that is not an Edge node.
Congestion: a temporal network state that occurs when the traffic (or
when traffic associated with a particular Per-Hop Behavior (PHB))
passing through a link is slightly higher than the capacity allocated
for the link (or allocated for the particular PHB). If no measures
are taken, then the traffic passing through this link may temporarily
slightly degrade in QoS. This type of congestion is usually solved
using admission control mechanisms.
Bader, et al. Experimental [Page 6]
RFC 5977 RMD-QOSM October 2010
Severe congestion: the congestion situation on a particular link
within the RMD domain where a significant increase in its real packet
queue situation occurs, such as when due to a link failure rerouted
traffic has to be supported by this particular link.
3. Overview of RMD and RMD-QOSM
3.1. RMD
The Differentiated Services (Diffserv) architecture ([RFC2475],
[RFC2638]) was introduced as a result of efforts to avoid the
scalability and complexity problems of IntServ [RFC1633].
Scalability is achieved by offering services on an aggregate rather
than per-flow basis and by forcing as much of the per-flow state as
possible to the Edges of the network. The service differentiation is
achieved using the Differentiated Services (DS) field in the IP
header and the Per-Hop Behavior (PHB) as the main building blocks.
Packets are handled at each node according to the PHB indicated by
the DS field in the message header.
The Diffserv architecture does not specify any means for devices
outside the domain to dynamically reserve resources or receive
indications of network resource availability. In practice, service
providers rely on short active time Service Level Agreements (SLAs)
that statically define the parameters of the traffic that will be
accepted from a customer.
RMD was introduced as a method for dynamic reservation of resources
within a Diffserv domain. It describes a method that is able to
provide admission control for flows entering the domain and a
congestion handling algorithm that is able to terminate flows in case
of congestion due to a sudden failure (e.g., link, router) within the
domain.
In RMD, scalability is achieved by separating a fine-grained
reservation mechanism used in the Edge nodes of a Diffserv domain
from a much simpler reservation mechanism needed in the Interior
nodes. Typically, it is assumed that Edge nodes support per-flow QoS
states in order to provide QoS guarantees for each flow. Interior
nodes use only one aggregated reservation state per traffic class or
no states at all. In this way, it is possible to handle large
numbers of flows in the Interior nodes. Furthermore, due to the
limited functionality supported by the Interior nodes, this solution
allows fast processing of signaling messages.
The possible RMD-QOSM applicabilities are described in Section 3.2.3.
Two main basic admission control modes are supported: reservation-
based and measurement-based admission control that can be used in
Bader, et al. Experimental [Page 7]
RFC 5977 RMD-QOSM October 2010
combination with a severe congestion-handling solution. The severe
congestion-handling solution is used in the situation that a
link/node becomes severely congested due to the fact that the traffic
supported by a failed link/node is rerouted and has to be processed
by this link/node. Furthermore, RMD-QOSM supports both
unidirectional and bidirectional reservations.
Another important feature of RMD-QOSM is that the intra-domain
sessions supported by the Edges can be either per-flow sessions or
per-aggregate sessions. In the case of the per-flow intra-domain
sessions, the maintained per-flow intra-domain states have a one-to-
one dependency to the per-flow end-to-end states supported by the
same Edge. In the case of the per-aggregate sessions the maintained
per-aggregate states have a one-to-many relationship to the per-flow
end-to-end states supported by the same Edge.
In the reservation-based method, each Interior node maintains only
one reservation state per traffic class. The Ingress Edge nodes
aggregate individual flow requests into PHB traffic classes, and
signal changes in the class reservations as necessary. The
reservation is quantified in terms of resource units (or bandwidth).
These resources are requested dynamically per PHB and reserved on
demand in all nodes in the communication path from an Ingress node to
an Egress node.
The measurement-based algorithm continuously measures traffic levels
and the actual available resources, and admits flows whose resource
needs are within what is available at the time of the request. The
measurement-based algorithm is used to support a predictive service
where the service commitment is somewhat less reliable than the
service that can be supported by the reservation-based method.
A main assumption that is made by such measurement-based admission
control mechanisms is that the aggregated PHB traffic passing through
an RMD Interior node is high and therefore, current measurement
characteristics are considered to be an indicator of future load.
Once an admission decision is made, no record of the decision need be
kept at the Interior nodes. The advantage of measurement-based
resource management protocols is that they do not require pre-
reservation state nor explicit release of the reservations at the
Interior nodes. Moreover, when the user traffic is variable,
measurement-based admission control could provide higher network
utilization than, e.g., peak-rate reservation. However, this can
introduce an uncertainty in the availability of the resources. It is
important to emphasize that the RMD measurement-based schemes
described in this document do not use any refresh procedures, since
these approaches are used in stateless nodes; see Section 4.6.1.3.
Bader, et al. Experimental [Page 8]
RFC 5977 RMD-QOSM October 2010
Two types of measurement-based admission control schemes are
possible:
* Congestion notification function based on probing:
This method can be used to implement a simple measurement-based
admission control within a Diffserv domain. In this scenario, the
Interior nodes are not NSIS-aware nodes. In these Interior nodes,
thresholds are set for the traffic belonging to different PHBs in the
measurement-based admission control function. In this scenario, an
end-to-end NSIS message is used as a probe packet, meaning that the
field in the header of the IP packet that carries the NSIS
message is re-marked when the predefined congestion threshold is
exceeded. Note that when the predefined congestion threshold is
exceeded, all packets are re-marked by a node, including NSIS
messages. In this way, the Edges can admit or reject flows that are
requesting resources. The frequency and duration that the congestion
level is above the threshold resulting in re-marking is tracked and
used to influence the admission control decisions.
* NSIS measurement-based admission control:
In this case, the measurement-based admission control functionality
is implemented in NSIS-aware stateless routers. The main difference
between this type of admission control and the congestion
notification based on probing is related to the fact that this type
of admission control is applied mainly on NSIS-aware nodes. With the
measurement-based scheme, the requested peak bandwidth of a flow is
carried by the admission control request. The admission decision is
considered as positive if the currently carried traffic, as
characterized by the measured statistics, plus the requested
resources for the new flow exceeds the system capacity with a
probability smaller than a value alpha. Otherwise, the admission
decision is negative. It is important to emphasize that due to the
fact that the RMD Interior nodes are stateless, they do not store
information of previous admission control requests.
This could lead to a situation where the admission control accuracy
is decreased when multiple simultaneous flows (sharing a common
Interior node) are requesting admission control simultaneously. By
applying measuring techniques, e.g., see [JaSh97] and [GrTs03], which
use current and past information on NSIS sessions that requested
resources from an NSIS-aware Interior node, the decrease in admission
control accuracy can be limited. RMD describes the following
procedures:
Bader, et al. Experimental [Page 9]
RFC 5977 RMD-QOSM October 2010
* classification of an individual resource reservation or a resource
query into Per-Hop Behavior (PHB) groups at the Ingress node of the
domain,
* hop-by-hop admission control based on a PHB within the domain.
There are two possible modes of operation for internal nodes to
admit requests. One mode is the stateless or measurement-based
mode, where the resources within the domain are queried. Another
mode of operation is the reduced-state reservation or reservation-
based mode, where the resources within the domain are reserved.
* a method to forward the original requests across the domain up to
the Egress node and beyond.
* a congestion-control algorithm that notifies the Egress Edge nodes
about congestion. It is able to terminate the appropriate number
of flows in the case a of congestion due to a sudden failure (e.g.,
link or router failure) within the domain.
3.2. Basic Features of RMD-QOSM
3.2.1. Role of the QNEs
The protocol model of the RMD-QOSM is shown in Figure 2. The figure
shows QoS NSIS initiator (QNI) and QoS NSIS Receiver (QNR) nodes, not
part of the RMD network, that are the ultimate initiator and receiver
of the QoS reservation requests. It also shows QNE nodes that are
the Ingress and Egress nodes in the RMD domain (QNE Ingress and QNE
Egress), and QNE nodes that are Interior nodes (QNE Interior).
All nodes of the RMD domain are usually QoS-NSLP-aware nodes.
However, in the scenarios where the congestion notification function
based on probing is used, then the Interior nodes are not NSIS aware.
Edge nodes store and maintain QoS-NSLP and NTLP states and therefore
are stateful nodes. The NSIS-aware Interior nodes are NTLP
stateless. Furthermore, they are either QoS-NSLP stateless (for NSIS
measurement-based operation) or reduced-state nodes storing per PHB
aggregated QoS-NSLP states (for reservation-based operation).
Note that the RMD domain MAY contain Interior nodes that are not
NSIS-aware nodes (not shown in the figure).
These nodes are assumed to have sufficient capacity for flows that
might be admitted. Furthermore, some of these NSIS-unaware nodes MAY
be used for measuring the traffic congestion level on the data path.
These measurements can be used by RMD-QOSM in the congestion control
based on probing operation and/or severe congestion operation (see
Section 4.6.1.6).
Bader, et al. Experimental [Page 10]
RFC 5977 RMD-QOSM October 2010
|------| |-------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QoS | | QoS | | QoS | | QoS |
| | |-------| |------| |------|
| | |-------| |-------| |-------| |------| | |
| | | local |<->| local |<->| local |<->| local| | |
| | | QoS | | QoS | | QoS | | QoS | | |
| | | | | | | | | | | |
| NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP |
|st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful|
| | | | |red.st.| |red.st.| | | | |
| | |-------| |-------| |-------| |------| | |
|------| |-------| |-------| |-------| |------| |------|
------------------------------------------------------------------
|------| |-------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP |
|st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful|
|------| |-------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress) (Interior) (Interior) (Egress) (End)
st.ful: stateful, st.less: stateless
st.less red.st.: stateless or reduced-state
Figure 2: Protocol model of stateless/reduced-state operation
3.2.2. RMD-QOSM/QoS-NSLP Signaling
The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The
signaling scenarios are accomplished using the QoS-NSLP processing
rules defined in [RFC5974], in combination with the Resource
Management Function (RMF) triggers sent via the QoS-NSLP-RMF API
described in [RFC5974].
Due to the fact that within the RMD domain a QoS Model that is
different than the end-to-end QoS Model applied at the Edges of the
RMD domain can be supported, the RMD Interior node reduced-state
reservations can be updated independently of the per-flow end-to-end
reservations (see Section 4.7 of [RFC5974]). Therefore, two
different RESERVE messages are used within the RMD domain. One
RESERVE message that is associated with the per-flow end-to-end
reservations and is used by the Edges of the RMD domain and one that
is associated with the reduced-state reservations within the RMD
domain.
A RESERVE message is created by a QNI with an Initiator QSPEC
describing the reservation and forwarded along the path towards the
QNR.
Bader, et al. Experimental [Page 11]
RFC 5977 RMD-QOSM October 2010
When the original RESERVE message arrives at the Ingress node, an
RMD-QSPEC is constructed based on the initial QSPEC in the message
(usually the Initiator QSPEC). The RMD-QSPEC is sent in a intra-
domain, independent RESERVE message through the Interior nodes
towards the QNR. This intra-domain RESERVE message uses the GIST
datagram signaling mechanism. Note that the RMD-QOSM cannot directly
specify that the GIST Datagram mode SHOULD be used. This can however
be notified by using the GIST API Transfer-Attributes, such as
unreliable, low level of security and use of local policy.
Meanwhile, the original RESERVE message is sent to the Egress node on
the path to the QNR using the reliable transport mode of NTLP. Each
QoS-NSLP node on the data path processes the intra-domain RESERVE
message and checks the availability of resources with either the
reservation-based or the measurement-based method.
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE'|
|<---------------------------------------------+
| | | | RESERVE
| | | +------->
| | | |RESPONSE
| | | |<-------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
Figure 3: Sender-initiated reservation with reduced-state
Interior nodes
When the message reaches the Egress node, and the reservation is
successful in each Interior node, an intra-domain (local) RESPONSE'
is sent towards the Ingress node and the original (end-to-end)
RESERVE message is forwarded to the next domain. When the Egress
node receives a RESPONSE message from the downstream end, it is
forwarded directly to the Ingress node.
Bader, et al. Experimental [Page 12]
RFC 5977 RMD-QOSM October 2010
If an intermediate node cannot accommodate the new request, it
indicates this by marking a single bit in the message, and continues
forwarding the message until the Egress node is reached. From the
Egress node, an intra-domain RESPONSE' and an original RESPONSE
message are sent directly to the Ingress node.
As a consequence, in the stateless/reduced-state domain only sender-
initiated reservations can be performed and functions requiring per-
flow NTLP or QoS-NSLP states, like summary and reduced refreshes,
cannot be used. If per-flow identification is needed, i.e.,
associating the flow IDs for the reserved resources, Edge nodes act
on behalf of Interior nodes.
3.2.3. RMD-QOSM Applicability and Considerations
The RMD-QOSM is a Diffserv-based bandwidth management methodology
that is not able to provide a full Diffserv support. The reason for
this is that the RMD-QOSM concept can only support the (Expedited
Forwarding) EF-like functionality behavior, but is not able to
support the full set of (Assured Forwarding) AF-like functionality.
The bandwidth information REQUIRED by the EF-like functionality
behavior can be supported by RMD-QOSM carrying the bandwidth
information in the parameter (see [RFC5975]). The full
set of (Assured Forwarding) AF-like functionality requires
information that is specified in two token buckets. The RMD-QOSM is
not supporting the use of two token buckets and therefore, it is not
able to support the full set of AF-functionality. Note however, that
RMD-QOSM could also support a single AF PHB, when the traffic or the
upper limit of the traffic can be characterized by a single bandwidth
parameter. Moreover, it is considered that in case of tunneling, the
RMD-QOSM supports only the uniform tunneling mode for Diffserv (see
[RFC2983]).
The RMD domain MUST be engineered in such a way that each QNE Ingress
maintains information about the smallest MTU that is supported on the
links within the RMD domain.
A very important consideration on using RMD-QOSM is that within one
RMD domain only one of the following RMD-QOSM schemes can be used at
a time. Thus, an RMD router can never process and use two different
RMD-QOSM signaling schemes at the same time.
However, all RMD QNEs supporting this specification MUST support the
combination of the "per-flow RMD reservation-based" and 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 field included in the "PHR container" (Section
Bader, et al. Experimental [Page 13]
RFC 5977 RMD-QOSM October 2010
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.
The congestion situations (see Section 2) are solved using an
admission control mechanism, e.g., "per-flow congestion notification
based on probing", while the severe congestion situations (see
Section 2), are solved using the severe congestion handling
mechanisms, e.g., "severe congestion handling by proportional data
packet marking".
The RMD domain MUST be engineered in such a way that RMD-QOSM
messages could be transported using the GIST Query and DATA messages
in Q-mode; see [RFC5971]. This means that the Path MTU MUST be
engineered in such a way that the RMD-QOSM message are transported
without fragmentation. Furthermore, the RMD domain MUST be
engineered in such a way to guarantee capacity for the GIST Query and
Data messages in Q-mode, within the rate control limits imposed by
GIST; see [RFC5971].
The RMD domain has to be configured such that the GIST context-free
flag (C-flag) MUST be set (C=1) for QUERY messages and DATA messages
sent in Q-mode; see [RFC5971].
Moreover, the same deployment issues and extensibility considerations
described in [RFC5971] and [RFC5978] apply to this document.
It is important to note that the concepts described in Sections
4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2, and 4.6.2.5.2 contributed to the PCN
WG standardization.
The available RMD-QOSM/QoS-NSLP signaling schemes are:
* "per-flow congestion notification based on probing" (see Sections
4.3.2, 4.6.1.7, and 4.6.2.6). Note that this scheme uses, for
severe congestion handling, the "severe congestion handling by
proportional data packet marking" (see Sections 4.6.1.6.2 and
4.6.2.5.2). Furthermore, the Interior nodes are considered to be
Diffserv aware, but NSIS-unaware nodes (see Section 4.3.2).
* "per-flow RMD NSIS measurement-based admission control" (see
Sections 4.3.2, 4.6.1, and 4.6.2). Note that this scheme uses, for
severe congestion handling, the "severe congestion handling by
proportional data packet marking" (see Sections 4.6.1.6.2 and
4.6.2.5.2). Furthermore, the Interior nodes are considered to be
NSIS-aware nodes (see Section 4.3.2).
Bader, et al. Experimental [Page 14]
RFC 5977 RMD-QOSM October 2010
* "per-flow RMD reservation-based" in combination with the "severe
congestion handling by the RMD-QOSM refresh" procedure (see
Sections 4.3.3, 4.6.1, 4.6.1.6.1, and 4.6.2.5.1). Note that this
scheme uses, for severe congestion handling, the "severe congestion
handling by the RMD-QOSM refresh" procedure (see Sections 4.6.1.6.1
and 4.6.2.5.1). Furthermore, the intra-domain sessions supported
by the Edge nodes are per-flow sessions (see Section 4.3.3).
* "per-flow RMD reservation-based" in combination with the "severe
the congestion handling by proportional data packet marking"
procedure (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, and 4.6.2.5.2).
Note that this scheme uses, for severe congestion handling, the
"severe congestion handling by proportional data packet marking"
procedure (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the
intra-domain sessions supported by the Edge nodes are per-flow
sessions (see Section 4.3.3).
* "per-aggregate RMD reservation-based" in combination with the
"severe congestion handling by the RMD-QOSM refresh" procedure (see
Sections 4.3.1, 4.6.1, 4.6.1.6.1, and 4.6.2.5.1). Note that this
scheme uses, for severe congestion handling, the "severe congestion
handling by the RMD-QOSM refresh" procedure (see Sections 4.6.1.6.1
and 4.6.2.5.1). Furthermore, the intra-domain sessions supported
by the Edge nodes are per-aggregate sessions (see Section 4.3.1).
Moreover, this scheme can be considered to be a reservation-based
scheme, since the RMD 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.
* "per-aggregate RMD reservation-based" in combination with the
"severe congestion handling by proportional data packet marking"
procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, and 4.6.2.5.2).
Note that this scheme uses, for severe congestion handling, the
"severe congestion handling by proportional data packet marking"
procedure (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the
intra-domain sessions supported by the Edge nodes are per-aggregate
sessions (see Section 4.3.1). Moreover, this scheme can be
considered to be a reservation-based scheme, since the RMD 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.
4. RMD-QOSM, Detailed Description
This section describes the RMD-QOSM in more detail. In particular,
it defines the role of stateless and reduced-state QNEs, the RMD-QOSM
QSPEC Object, the format of the RMD-QOSM QoS-NSLP messages, and how
QSPECs are processed and used in different protocol operations.
Bader, et al. Experimental [Page 15]
RFC 5977 RMD-QOSM October 2010
4.1. RMD-QSPEC Definition
The RMD-QOSM uses the QSPEC format specified in [RFC5975]. The
Initiator/Local QSPEC bit, i.e., is set to "Local" (i.e., "1")
and the is set as follows:
* Message Sequence = 0: Sender initiated
* Object combination = 0: for RESERVE and
for RESPONSE
The used by RMD-QOSM is the default version, i.e.,
"0", see [RFC5975]. The value used by the RMD-QOSM is
specified in [RFC5975] and is equal to "2". The contains the following fields:
=
The Per-Hop Reservation container (PHR container) and the Per-Domain
Reservation container (PDR container) are specified in Sections 4.1.2
and 4.1.3, respectively. The contains the traffic
handling directives for intra-domain communication and reservation.
The contains additional traffic handling directives
that are needed for edge-to-edge communication. The parameter IDs
used by the and are assigned by IANA;
see Section 6.
The RMD-QOSM and , are specified in
Section 4.1.1. The RMD-QOSM and and the
are used and processed by the Edge and Interior
nodes. The field is only processed by Edge nodes.
4.1.1. RMD-QOSM and
The RESERVE message contains only the object [RFC5975].
The object is carried by the RESPONSE message.
In RMD-QOSM, the and objects contain the
following parameters:
= =
The bit format of the (see [RFC5975] and Figures 4 and 5)
and complies with the bit format specified in
[RFC5975].
Bader, et al. Experimental [Page 16]
RFC 5977 RMD-QOSM October 2010
Note that for the RMD-QOSM, a reservation established without an
parameter is equivalent to a reservation
established with an whose value is 1.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 X 0|
+---+---+---+---+---+---+---+---+
Figure 4: DSCP parameter
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID code |0 0 X X|
+---+---+---+---+---+---+---+---+
Figure 5: PHB ID Code parameter
4.1.2. PHR Container
This section describes the parameters used by the PHR container,
which are used by the RMD-QOSM functionality available at the
Interior nodes.
= , ,
