NSIS Working Group Attila Bader
INTERNET-DRAFT Lars Westberg
Ericsson
Expires: May 2005 Georgios Karagiannis
University of Twente
Cornelia Kappler
Siemens
Tom Phelan
Sonus
November 15, 2004
RMD-QSP: An NSIS QoS Signaling Policy for Networks Using
Resource Management in Diffserv (RMD)
<draft-ietf-nsis-rmd-00.txt>
Status of this memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
"Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html"
Abstract
This document describes an NSIS QoS Signaling Policy model for
networks that use the Resource Management in Diffserv (RMD)
concept. RMD is a technique for adding admission control to
Differentiated Services (Diffserv) networks. RMD complements
the Diffserv architecture by pushing complex classification,
conditioning and admission control functions to the edges of a
Diffserv domain and simplifying the operation of internal nodes.
Bader, et al. [Page 1]
INTERNET-DRAFT RMD-QSP
It allows feedback to systems outside of the Diffserv domain on
the availability of resources for individual sessions within the
domain while having the availability to aggregate inter domain
(end-to-end) resource reservations at the edge of the domain to
reduce the burden on internal nodes. The RMD QoS Signaling Policy
Model (RMD-QSP) allows devices to use the NSIS QoS-NSLP protocol to
signal reservation requests from devices outside the Diffserv domain
to edge nodes in the domain, edge nodes have the availability to
aggregate the requests and signal the aggregated requests
through internal nodes along the data path to the egress edge
nodes, and for Egress Edge nodes to signal the original,
disaggregated, requests to outside devices.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3
3. Overview of RMD and RMD-QSP . . . . . . . . . . . . . . . . .4
3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4
3.2 RMD-QSP . . . . . . . . . . . . . . . . . . . . . . . . .5
4. RMD QSP, detailed description . . . . . . . . . . . .. . . . 7
4.1 QSpec Definition . . . . . . . . . . . . . . . . . . . . 7
4.1.1 RMD-QSP descriptors . . . . . . . . . . . . . . . .8
4.1.2 PHR RMD-QSP control information . . . . . . . . . .8
4.1.3 PDR RMD-QSP control information . . . . . . . . .10
4.1.4 Mapping of QSpec parameters onto generic
QSpec Parameters . . . . . . . . . . . . . . . . .12
4.2 Role of QoS NSLP Entities (QNEs) . . . . . . . . . . . .12
4.3 Message format . . . . . . . . . . . . . . . . . . . . .13
4.4 State management . . . . . . . . . . . . . . . . . . . .14
4.5 Operation and sequence of events . . . . . . . . . . . .16
4.5.1 Edge discovery and addressing of messages . . . . 16
4.5.2 Basic unidirectional operation . . . . . . . . . .16
4.5.2.1 Successful reservation. . . . . . . . . . . .17
4.5.2.2 Unsuccessful reservation . . . . . . . . . . 22
4.5.2.3 RMD refresh reservation. . . . . . . . . . . 24
4.5.2.4 RMD modification of reservation. . . . . . . 28
4.5.2.5 RMD release procedure. . . . . . . . . . . . 28
4.5.2.6 Severe congestion. . . . . . . . . . . . . . 34
4.5.3 Bidirectional operation . . . . . . . . . . . . . 36
4.5.3.1 Successful and unsuccessful reservation . . .37
4.6 Handling of errors . . . . . . . . . . . . . . . . . . .41
5. Security Consideration. . . . . . . . . . . . . . . . . . . 41
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .42
7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .42
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .42
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 43
10. Normative References . . . . . . . . . . . . . . . . . . . 43
11. Informative References . . . . . . . . . . . . . . . . . . 44
12. Intellectual Property Rights . . . . . . . . . . . . . . . 45
Bader, et al. [Page 2]
INTERNET-DRAFT RMD-QSP
1. Introduction
This document describes an example of a Next Steps In Signaling
(NSIS) Quality of Service Signaling Model for networks that use the
Resource Management in Diffserv (RMD) framework ([RMD1], [RMD2],
[RMD3],[RMD4]). RMD is a method for devices external to a Diffserv
domain to dynamically reserve resources within the Diffserv domain.
It describes a procedure that can aggregate individual reservation
requests at the Ingress Edge of the domain, two possible modes of
operation for internal nodes to admit aggregated requests (a
stateless, measurement-based mode, and a reduced-state reservation
mode), and a method to forward the original requests across the
domain to the Egress Edge and on.
The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP)
[QoS-NSLP] specifies a generic model for carrying Quality of Service
(QoS) signal
ing information end-to-end in an IP network. Each
network along the end-to-end path is expected to implement a
specific QoS Signaling Model (QSP) that installs the necessary state
to ensure the requested QoS in a manner that is appropriate to the
technology in use in the network.
This document specifies the RMD QoS Signaling Policy Model
(RMD-QSP), as a specific implementation of a QoS-NSLP QSP, for use
in networks that use RMD technology. Internally to the Diffserv
network, RMD-QSP uses the stateless/reduced state operation mode of
QoS-NSLP and defines a scalable QoS signaling model in which per
flow QoS-NSLP and NTLP states are not stored but per flow signaling
is performed.
In the RMD-QSP, only routers at the edges of a Diffserv domain
support the QoS-NSLP stateful operation. Internal routers support
either the QoS-NSLP stateless operation, or a reduced-state
operation with coarser granularity than the edge nodes.
The remainder of this draft is structured following the suggestions
in Appendix B of [QSP-T] for description of QoS Signaling Policies:
After the terminology Section 2, we give an overview of RMD and the
RMDQSP in Sec. 3. In Sec. 4 we give a detailed description of the
RMD-QSP, including the role of QNEs, the definition of the QSpec,
mapping of QSpec generic parameters onto RMDQSP parameters, state
management in QNEs, and operation and sequence of events. Sec. 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 RFC 2119.
Bader, et al. [Page 3]
INTERNET-DRAFT RMD-QSP
3. Overview of RMD and RMD-QSP
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 basis
rather than per-flow 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 way for devices
outside the domain to dynamically reserve resources or receive
indications of network resource availability. In practice, service
providers rely on subscription-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 can aggregate
individual reservation request at the Ingress Edge of the domain,
two possible modes of operation for internal nodes to admit
aggregated requests (a stateless, measurement-based mode, and a
reduced-state reservation mode), and a method to forward the
original requests across the domain to the Egress Edge and on.
In RMD, scalability is achieved by separating a complex reservation
mechanism used in edge nodes of a Diffserv domain from a much
simpler reservation mechanism needed in the interior nodes. In
particular, it is assumed that edge nodes of a Diffserv domain
support per-flow (or aggregated flows) QoS states in order to
provide QoS guarantees for each flow (or aggregated flow). Interior
nodes use only one aggregated reservation state per traffic class or
no states at all. This solution allows fast processing of signaling
messages and makes it possible to handle large numbers of flows in
the interior nodes.
In RMD two basic operation modes are described: a measurement-based
admission control and a reservation-based admission control. The
measurement-based algorithm uses the requested and available
resources as input to query the aggregated reservation state per
traffic class in the interior nodes. The advantage of measurement
based resource management protocols is that they do not require
explicit reservation or release. Moreover, when the user traffic is
variable, measurement based admission control could provide higher
network utilization than, e.g., peak-rate reservation. However,
this requires more complex implementation in interior nodes and
introduces an uncertainty of the availability of the resources.
Bader, et al. [Page 4]
INTERNET-DRAFT RMD-QSP
With the reservation-based method, each node in the domain maintains
one reservation state per traffic class. The reservation is
quantified in terms of resource units. 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.
3.2. RMD-QSP
RMD-QSP is a QoS-NSLP QoS signaling model for networks that usees
RMD technology for processing reservations. In a RMD-QSP domain, an
inter-domain (end to end) QoS NSLP message that arrives at the
ingress edge generates an additional intra-domain (local) QoS NSLP
message containing a RMD QSpec and the inter-domain message is
tunneled towards the egress edge. Edge nodes use QoS-NSLP stateful
operation and interior nodes use either stateless operation
(for measurement-based admission) or reduced state operation (for
reservation-based admission).
The RMD-QSP uses a simple, hop-by-hop signaling mechanism. The QSpec
arrives in an QoS NSLP RESERVE message at the ingress node. The
ingress node uses the external QSpec to construct the RMD-QSPec for
intra-domain (local) RMD-QSP specific signaling, and sends it in a
RESERVE message to the Egress node. Each node on the data path, one
after the other, checks the availability of resources with either
the reservation-based or the measurement-based method. If an
intermediate node cannot accommodate the new request, it indicates
it by marking a single bit in the message, and continues forwarding
the message. When the message reaches the egress edge node, if no
intermediate node has denied the reservation, the generic request is
forwarded to the next domain. If an intermediate node has denied
the reservation, the reservation is denied.
In the simplest case the domain wherein the RMD-QSP
is applied is identical to a Diffserv administrative domain. The
boundary nodes of the domain are QoS-NSLP aware edge nodes (QNF
ingress and QNF Egress Edges) and the interior nodes are QoS-NSLP
aware interior nodes (QNF interior). In the interior nodes, RMD-QSP
uses the stateless/reduced state operation mode defined in QoS-NSLP.
In the edge nodes, RMD-QSP uses the stateful mode of operation.
The protocol model of the RMD-QSP is shown in Figure 1. The QNF
nodes leading up to the edge of the RMD-QSP domain process the QoS-
NSLP messages in a manner appropriate to their QoS technology. At
the ingress edge node of the RMD-QSP domain, the inter domain
(end-to-end) QoS-NSLP messages trigger the generation of
intra-domain (local) RMD-QSP QoS-NSLP messages. The QSpec of the
inter domain (end-to-end) QoS-NSLP message is translated into an
RMD-QSP QSpec.
Bader, et al. [Page 5]
INTERNET-DRAFT RMD-QSP
|------| |------| |------| |------|
| 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 QNF QNF QNF QNF QNR
(End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End)
st.ful: stateful, st.less: stateless
st.less red.st.: stateless or reduced state
Figure 1 Protocol model of stateless/reduced state operation
The original QoS-NSLP messages are sent directly to the next NTLP
stateful node, i.e. to the Egress Edge node, see Figure 2. The
intra-domain (local) QoS-NSLP messages are processed and
interpreted in all interior NSLP routers along the path, hop-by-hop,
up to the Egress Edge node.
RMD usually performs per flow signaling within the domain. However,
RMD can also support per aggregate signaling within the domain. In
the reservation-based method interior nodes add and remove the
requested resources per PHB. In case of the measurement-based
method the availability of resources are checked. In case of
unsuccessful reservation in a router, egress nodes are notified by
marking the corresponding control field of the Request message.
After successful or unsuccessful reservation a RESPONSE message is
sent from Egress to Ingress Edge.
The RMD reservation method uses soft states: reserved resources
should be refreshed periodically. If refresh messages are not
arrived within the refresh period the corresponding resource units
are removed. Resource units can be removed explicitly as well, by
sending Release messages containing the removable resource units.
Bader, et al. [Page 6]
INTERNET-DRAFT RMD-QSP
QNF QNF QNF QNF
ingress interior interior egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | | RESERVE
| | | +-------->
| | | | RESPONSE
| | | |<--------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
Figure 2: Sender-initiated reservation with Reduced State Interior
Nodes
4. RMD-QSP, Detailed Description
This section describes RMD-QSP in detail. Particularly, we explain
the role of stateless and reduced-state QNEs, define the RMD-QSP
QSpec Object, the format of RMD-QSP QoS-NSLP messages, how QSpecs
are processed and used, and the protocol operation.
4.1. QSpec Definition
This section describes the QSpec that is used by RMD-QSP. The RMD-
QSP QSpec object contains three fields, the "RMD-QSP QoS
descriptor", the (per hop reservation) "PHR RMD-QSP control
information" and the (per domain reservation) "PDR RMD-QSP control
information". The "RMD-QSP QoS descriptors" and the "PHR RMD-QSP
control information" fields are used and processed by all QoS-NSLP
nodes in the edge-to-edge domain, i.e., QNF (edge nodes) and QNF
(interior nodes). The "PDR RMD-QSP control information" field is
only used and processed by the QNF (edge nodes). The "PHR RMD-QSP
control information" field contains the QoS specific control
information for intra-domain communication and reservation. The
"PDR RMD-QSP control information" contains additional information
that is needed by the QNF (edge nodes) and is not available
(carried) by the "PHR RMD-QSP control information". RMD-QSP QSpec
parameters will be updated in line with
QSpec Template draft [QSP-T].
Bader, et al. [Page 7]
INTERNET-DRAFT RMD-QSP
4.1.1. RMD-QSP QoS descriptors
This section describes the parameters used by the "RMD-QSP QoS
descriptors field" field. The RMD QoS Description only contains the
object QoS Desired [QSP-T]. It does not contain the objects QoS
Available, QoS Reserved or Minimum QoS.
<QoS Desired> = <R> <PHB-DCLASS>
As described in [QSP-T].
4.1.2. PHR RMD-QSP control information
This section describes the parameters used by the "PHR RMD-QSP
control information" field. Except <Hop Count> these parameters are
currently not among the generic parameters defined by <QSM-T>.
<PHR type>:
4-bit field. This specifies the per hop reservation type.
For the reservation based RMD, the value MUST be 1. For the
measurement based PHR this value MUST be 2.
<Message Type>:
4 bit field, indicating the "PHR RMD-QSP control information"
type: PHR_Resource_Request, PHR_Release_Request,
PHR_Refresh_Update. It is used to further specify QoS-NSLP
RESERVE and RESPONSE messages.
"PHR_Resource_Request" (Message Type = 1): initiate or update
the traffic class reservation state on all nodes located on
the communication path between the QNF(ingress) and
QNF(egress) nodes.
"PHR_Refresh_Update" (Message Type = 2): refresh the traffic
class reservation soft state on all nodes located on the
communication path between the QNF(ingress) and QNF(egress)
nodes according to a resource reservation request that was
successfully processed by the "PHR RMD-QSP control
information" functionality during a previous refresh period.
"PHR_Release_Request" (Message Type = 3): explicitly release,
by subtraction, the reserved resources for a particular flow
from a traffic class reservation state.
<S> (Severe Congestion):
1 bit. In case of a route change refreshing RESERVE messages
follow the new data path, and hence resources are requested
there. However, on the new path resources may not be
sufficie
nt to accommodate the new traffic. Congested interior
nodes should notify edge QNFs about the congestion, in order
to terminate some of the sessions. The notification of the
Bader, et al. [Page 8]
INTERNET-DRAFT RMD-QSP
egress QNF is carried out by marking either the data packets
with dedicated DSCPs or by setting the S Field bit indicating
severe congestion in the refresh message. The egress QNF
decides which sessions should be terminated and sends a
RESPONSE message to the Ingress Edge with the session ID and
indicating the severe congestion. Since refresh messages are
usually sent less frequently than the data packets a more
efficient method for the notification is marking the data
packets by changing the DSCP field.
<Overload %>:
In case of severe congestion the level of overload can be
indicated by using e.g. proportional marking if data marking
is used. If RMD refresh messages are used, proportional
marking is not a feasible solution usually because of the low
number of refresh messages. Overload % can be used to
indicate the level of Overload %. Note that Overload % should
be higher than 0 if S bit is set. If overload in a node is
greater than the overload in a previous node then Overload %
should be updated.
<M>:
1 bit. In case of unsuccessful reservation in an interior
QNF, this QNF sets the M bit in order to notify the egress
QNF.
<Hop Count>:
8 bit field. The Hop Count is set to zero when a RESERVE
message enters a domain and increased by one at each interior
QNF. However when a QNF is reached that does not have
sufficient resources to admit the reservation, the M Bit is
set, and the Hop Count value is frozen. Hence the Hop Count
counts the number of hops where the reservation was
successful. In case of an unsuccessful reservation the M Bit
is set, and the egress QNF reacts by sending a RESPONSE
message containing the Hop Count to the ingress QNF. The
ingress QNF uses the Hop Count value to remove the unnecessary
reservations by an explicit tearing RESERVE message to the
nodes along the path where the reservation has already been
made.
<Hop_U> (Hop Count unset):
1-bit. The QNF(ingress) node MUST set the <Hop_U> parameter to
0. This parameter MAY be set to "1" by a node when the node
will not increase the <Hop Count> value. This is the case when
an RMD-QSM reservation-based node is not admitting the "RMDQSM
QoS descriptors" and "PHR_Resource_Request" control
information fields.
Bader, et al. [Page 9]
INTERNET-DRAFT RMD-QSP
<B>: 1 bit. Indicates bi-directional reservation.
<Time lag>: 8 bit field. The time lag used in a sliding window over
the refresh period.
More details on the required control information for RMD-QSP will be
provided in a future version of this draft.
4.1.3. PDR RMD-QSP control information
This section describes the parameters used by the "PDR RMD-QSP
control information" field.
<PDR type>:
4-bit field identifying the per domain reservation type.
<PDR Message Type>:
4-bit field identifying the type of "PDR RMD-QSP control
information" field.
"PDR_Reservation_Request" (Message Type = 1): generated by the
QNF(ingress) node in order to initiate or update the QoS-NSLP
per domain reservation state in the QNF(egress) node
"PDR_Refresh_Request" (Messsage Type = 2): generated by the
QNF(ingress) node and sent to the QNF(egress) node to refresh,
in case needed, the QoS-NSLP per domain reservation states
located in the QNF(egress) node
"PDR_Release_Request" (Message Type = 3): generated and sent
by the QNF(ingress) node to the QNF(egress) node to release
the per domain reservation states explicitly
"PDR_Reservation_Report" (Message Type = 4): generated and
sent by the QNF(egress) node to the QNF(ingress) node to
report that a "PHR_Resource_Request" and a
"PDR_Reservation_Request" control information fields have been
received and that the request has been admitted or rejected
"PDR_Refresh_Report" (Message Type = 5) generated and sent by
the QNF(egress) node in case needed, to the QNF(ingress) node
to report that a "PHR_Refresh_Update" control information
field has been received and has been processed
"PDR_Release_Report" (Message Type = 6) generated and sent by
the QNF(egress) node in case needed, to the QNF(ingress) node
to report that a "PHR_Release_Request" and a
"PDR_Release_Request" control information fields have been
received and have been processed
Bader, et al. [Page 10]
INTERNET-DRAFT RMD-QSP
"PDR_Request_Info" (Message Type =7): an object that can be
used as a common "PDR_Reservation_Request",
"PDR_Refresh_Request", "PDR_Release_Request" and
"PDR_Modification_Request"
"PDR_Congestion_Report" (Message Type = 8): generated and sent
by the
QNF(egress) node to the QNF(ingress) node and used for Severe
congestion notification
"PDR_Modification_Request" (Message Type = 9): generated and
sent by the QNF(ingress) node to the QNF(egress) node to
modify the per domain reservation states located in the
QNF(egress) node
"PDR_Modification_Report" (Message Type =10): generated and
sent by the QNF(egress) node to QNF(ingress) node to report
that the combination of either the "PHR_Resource_Request" and
the "PDR_Modification_Request" control information fields or
the "PHR_Release_Request" and the "PDR_Modification_Request"
control information fields have been received and processed
<PDR S> (Severe Congestion):
1-bit. Specifies if a severe congestion situation occurred.
It can also carry the <S> parameter of the
"PHR_Resource_Request" or "PHR_Refresh_Update" control
information fields. This parameter applies only to
"PDR_Reservation_Report", "PDR_Refresh_Report",
"PDR_Congestion_Report" and "PDR_Modification_Report" control
information fields.
<PDR_Overload %>:
8-bit. Indicates the level of overload to the ingress edge
node. It includes the Overload % of the
"PHR_Resource_Request" or "PHR_Refresh_Update" control
information fields. This parameter applies only to
"PDR_Reservation_Report", "PDR_Refresh_Report",
"PDR_Congestion_Report" and "PDR_Modification_Report" control
information fields.
<PDR M> (Marked):
1-bit. Carries the <M> value of the "PHR_Resource_Request" or
"PHR_Refresh_Update" control information fields. This
parameter applies only to "PDR_Reservation_Report",
"PDR_Refresh_Report", "PDR_Congestion_Report" and
"PDR_Modification_Report" control information fields.
<PDR B>: 1 bit Indicates bi-directional reservation.
Bader, et al. [Page 11]
INTERNET-DRAFT RMD-QSP
<PDR Hop Count>:
8-bit. The <Hop Count> value that has been carried by the
"PHR RMD control information" filed used to identify the RMD
reservation based node that could not admit or process a
"PHR_Resource_Request" control information field
<EP-Type>:
4-bit. Identifies the used external protocol (External
Protocol Type). If the external protocol is a QoS-NSLP then
this parameter carries the QoS-NSLP protocol ID. Only useful
when the intra-domain signaling procedures are use
d in
combination with non-QoS-NSLP inter-domain signaling
procedures. Every edge node MUST be configured to process the
EP-Type.
<PDR Reverse Requested Resources>
16 bits. This field only applies when the "B" flag is set to
"1". It specifies the requested number of units of resources
that have to be reserved by a node in the reverse direction
when the intra-domain signaling procedures require a bi-
directional reservation procedure.
<PDR BOUND_SESSION_ID>
128 bits. This parameter has the same format as the
BOUND_SESSION_ID field specified in [QoS-NSLP]. It represents
the SESSION_ID as specified in GIMPS of the intra domain
session that is bounded to the inter domain (end to end) session
4.1.4. Mapping of generic parameters onto RMD QSP parameters
To be provided in a future version of this draft.
4.2. Role of QoS NSLP Entities (QNEs)
Edge nodes of an RMD-QSP domain support both NSIS operation modes,
i.e., stateful and stateless/reduced state operation modes. As NSIS
stateful nodes the edge nodes store and administrate QoS-NSLP and
NTLP states.
The interior nodes are either completely stateless, i.e., they are
not supporting any QoS-NSLP or NTLP/GIMPS states as for measurement-
based operation, or they are reduced state nodes, i.e., they do not
store NTLP/GIMPS states but they store per PHB aggregated QoS-NSLP
states as in reservation-based operation.
Bader, et al. [Page 12]
INTERNET-DRAFT RMD-QSP
The reservation states are soft states that should be refreshed
periodically. In each refresh period the interior nodes count the
reserved resources and the expired reserved units and remove the
number of resource units per PHB that were not refreshed. The
refresh period can be refined using a sliding window algorithm
described in [RMD1], [RMD3].
Note that the RMD-QSP domain may contain interior nodes that are not
NSIS aware nodes. 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-QSP in the severe congestion
operation (see Section 4.5.2.6).
4.3. Message format
The format of the messages used by the RMD-QSP
complies with the QoS-NSLP specification. As specified in [QoS-
NSLP], for each QoS-NSLP message type, there is a set of rules for
the permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation should
create messages with the objects in the order shown here, but accept
the objects in any permissible order. More details on the message
formats will be provided in the future versions of this draft.
The format of a RESERVE message used by the
RMD-QSP is as follows:
RESERVE = COMMON_HEADER
RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] [ RMD-QSPEC]
The format of a Query message used by the
RMD-QSP is as follows:
QUERY = COMMON_HEADER
[ RII ][ BOUND_SESSION_ID ]
[ POLICY_DATA ] [ RMD-QSPEC ]
A QUERY message MUST contain an RII object to indicate a RESPONSE is
desired, unless the QUERY is being used to initiate reverse-path
state for a receiver-initiated reservation.
The format of a local RESPONSE message used by
the RMD-QSP is as follows:
RESPONSE = COMMON_HEADER
[ RII / RSN ] ERROR_SPEC
[ RMD-QSPEC ]
Bader, et al. [Page 13]
INTERNET-DRAFT RMD-QSP
The format of an end-to-end RESPONSE message that is used by the
RMD-QSP to carry the PDR RMD control information of
the RMD-QSPEC is as follows:
RESPONSE = COMMON_HEADER
[ RII / RSN ] ERROR_SPEC [ RMD-QSPEC ] [ *QSPEC ]
The format of a NOTIFY message used by the
RMD-QSP is as follows:
NOTIFY = COMMON_HEADER ERROR_SPEC [ RMD-QSPEC ]
All objects, except the RMD-QSPEC objects, are specified in [QoS-
NSLP]. Note that the intra-domain (local) messages used by the
RMD-QSP must operate in the NTLP/GIMPS Datagram mode (see [GIMPS]).
Therefore, the NSLP functionality available in all QoS NSLP nodes
that are able to support the RMD-QSP must require from the
intra-domain GIMPS functionality available in these nodes to operate
in the datagram mode, i.e., require from GIMPS to:
* operate in unreliable mode,
* do not create a message association state, which can be done by
configuration
* do not create a reverse path Message routing state, which can be
done by QoS-NSLP via API.
4.4. State management
The way of how the QoS-NSLP states are created and managed is
specified in [QoS-NSLP]. This section will describe how the
reservation states Resource Management Function of the reduced
states nodes are created and maintained.
The QNF interior nodes are either completely stateless, i.e., they
are not supporting any QoS-NSLP or NTLP/GIMPS states as for
measurement-based operation, or they are reduced state nodes, i.e.,
they do not store NTLP/GIMPS states but they store per PHB
aggregated QoS-NSLP states as in reservation-based operation.
In case of measurement-based method, an intra-domain RESERVE message
is sent to check the availability of resources before flows are
admitted. In the interior nodes two QoS-NSLP states per PHR group
are installed, which do not have to be maintained (by refresh)
during the connection. One state stores the measured user traffic
load associated to PHB and another state stores the maximum traffic
load per PHB group that can be admitted.
In case of reservation-based method, per PHB group aggregated
reservations states are installed and these are maintained by
sending intra-domain RESERVE messages.
Bader, et al. [Page 14]
INTERNET-DRAFT RMD-QSP
The reservation-based PHR installs and maintains one reservation
state per PHB, i.e., per DSCP, in all the nodes located in the
communication path from the QNF ingress node up to the NF egress
node. The reservation states can be represented by a constant
number or by a parameter set. This state represents the number of
currently reserved resource units that are carried by the PHR object
for the admitted incoming flows. Thus, the QNF ingress node
generates for each incoming flow a combination of the "RMD QoS
descriptors" field and the "PHR RMD control information" field, that
is included into an intra-domain RESERVE(RMD-QSPEC), signaling only
the resource units requested by this particular 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.
The per-PHB group reservation states can be created and maintained
by the combination of reservation soft state and explicit release
principles. When the reservation soft state principle is used, a
finite lifetime is set for the length of the reservation. These
reservation states are refreshed by sending periodic refresh
mes
sages. The reserved resources for a particular flow can also be
explicitly released from a PHB reservation state by means of a PHR
release message. The usage 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. The refresh period
can be refined using a sliding window algorithm described in [RMD1].
The QNF edges maintain either per flow, or aggregated QoS-NSLP
reservation states. Each per flow or aggregated QoS-NSLP
reservation state is identified by a NTLP SESSION_ID (see [GIMPS]).
In RMD, these states are denoted as PDR states. The per flow
reservation states can for example be Intserv per flow reservation
states [RFC2205] that are identified by a NTLP SESSION_ID (see
[GIMPS]).
In the situation where the QNF edges maintain per aggregated QoS-
NSLP reservation states then these states will have to maintain the
SESSION_ID of the aggregated state, the IP addresses of the ingress
and egress nodes, the PHB value and the size of the aggregated
reservation, e.g., reserved bandwidth.
The size of the aggregation is defined as it is specified in Section
1.4.4 of [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 it aggregates. Some 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 the
Bader, et al. [Page 15]
INTERNET-DRAFT RMD-QSP
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.5.2.4).
4.5. Operation and sequence of events
This section describes the operation and the sequence of events in
the RMD-QSP.
The transport characteristics for the intra-domain (local)
reservation model can be different from that of the inter domain
(end-to-end) reservation model. GIMPS can be used in a different
way for the edge-to-edge and hop-by-hop sessions, (i.e. sending of
messages in datagram mode, and not retaining optional path state,
i.e., NTLP stateless mode). The reduced state reservation can be
updated independently of the per-flow inter domain (end-to-end)
reservations.
4.5.1. Edge discovery and addressing of messages
Mainly, the Egress Edge discovery can be performed either by using
the GIMPS discovery mechanism [GIMPS] or by configuration. The
addressing of signaling messages depends on the used GIMPS transport
mode. The RMD QoS signaling messages that are processed only by the
edge nodes use the peer-peer addressing of the GIMPS connection mode
(C). RMD QoS signaling messages that are processed by all nodes of
the Diffserv domain, i.e., edges and interior nodes, use the end-end
addressing of the GIMPS datagram (D) mode. RMD messages addressed
to the end node are intercepted and terminated by the Egress Edge.
4.5.2. Basic unidirectional operation
This section describes the basic unidirectional operation and
sequence of events of the RMD-QSP. The following
basic operation cases are distinguished: Successful reservation,
Unsuccessful reservation, Refresh, Modification, Release and Severe
congestion.
Bader, et al. [Page 16]
INTERNET-DRAFT RMD-QSP
4.5.2.1. Successful reservation
This section describes the operation of the RMD-QSP
where a reservation is successfully accomplished. The QNI generates
the initial RESERVE message, and it is forwarded by the NTLP as
usual [GIMPS]. The QNFs at the edges of the RMD domain support two
types of QoS models, which process the RESERVE message differently.
When an inter-domain (end-to-end) reservation request (RESERVE)
arrives at the Ingress Edge node (QNF), after classifying it into
the appropriate PHB, it will calculate the requested resource unit
and makes the reservation in the QNF ingress. This state is
associated with the session ID. If the request was satisfied
locally, the ingress node generates two RESERVE messages:
inter-domain and intra-domain RESERVE messages. These are bounded
together including a BOUND_SESSION_ID in the intra-domain RESERVE
message. The inter-domain RESERVE message is sent to Egress QNF and
includes the inter domain (end-to-end) QSpec. This message is
forwarded using facilities provided by the NTLP to bypass the
stateless or reduced-state nodes, see Figure 3. After completing
the initial discovery phase, the GIMPS connection mode between the
QNF ingress and QNF egress can be used. The QNF ingress has to
request from NTLP to activate the QoS-NSLP-E2E-IGNORE feature
(its specification depends on NTLP and QoS-NSLP standardization) for
transporting inter-domain (end-to-end) QoS-NSLP messages. In this
way all the QNF interior nodes ignore the processing of the
inter-domain RESERVE message. At the egress node the RESERVE
message is then forwarded as usual [QoS-NSLP].
The QoS descriptor used by the QSpec of the inter domain
(end-to-end) QoS model is transformed into the <R> and <PHB-DCLASS>
RMD QoS descriptor (needed for the intra-domain QSpec). In order to
make a RMD query or a RMD reservation an intra-domain
RESERVE(RMD-QSPEC) message is generated by the QNF ingress edge.
This makes use of a QoS model suitable for a reduced state or
stateless form of operation (such as the RMD per hop reservation).
Before generating this message, the RMD-QSP functionality uses the
<R> RMD QoS descriptor for admission control.
* When the RMD reservation-based method is used, the resources
specified in <R>, if admitted, are added to the currently
reserved resources per traffic class (PHB) and, therefore,
they become a part of the per RMD traffic class (PHB)
reservation state. Furthermore, the value of the <Hop Count>
field in the "PHR RMD control information" field has to be set
to one. The <Hop Count> value is used to count the number of
RMD NSIS aware nodes that successfully processed the
reservation based RMD-QSPEC object.
* When the RMD measurement-based method is used, and admission
decision is positive, the MBAC algorithm is updated with these
resources.
Bader, et al. [Page 17]
INTERNET-DRAFT RMD-QSP
The session ID used by the intra-domain RESERVE (RMD-QSPEC) message
must be associated to a PHB value (<PHB-DCLASS>). The IP destination
address of this message must be the same as the IP destination
address of the inter-domain RESERVE message. The QNF ingress node
generates a reservation request "PHR RMD control information" field
denoted as "PHR_Resource_Request" and it may generate a reservation
request "PDR RMD control information" field denoted as
"PDR_Reservation_Re
quest". These two fields together with the "RMD
QoS descriptors" field form the RMD-QSPEC object. This intra-domain
RESERVE (RMD-QSPEC) message must include a "PHR RMD control
information" (PHR_Resource_Request) field, and it may include the
"PDR RMD control information", (PDR_Reservation_Request) field. The
non-default values of the objects contained in this intra-domain
RESERVE message must be set by the QNF ingress edge as follows:
* the value of the <RSN> object should be the same as the value
of the RSN object of the inter-domain RESERVE message.
the value of the <BOUND_SESSION_ID> object must be the session
ID associated to the inter-domain RESERVE message.
* the SCOPING flag should not be set, meaning that a default
scoping of the message is used. Therefore, the QNF edges must
be configured as boundary nodes and the QNF interior nodes
must be configured as interior (intermediary) nodes.
* the value of the <RII> object must contain the Response
Identification Information value of the ingress QNF, that is
unique within a session and different for each message (see
[(QoS-NSLP]). In general downstream nodes that desire
responses may keep track of this RII to identify the RESPONSE
when it passes back through them.
* the value of the <REFRESH_PERIOD> object must be calculated
and set by the QNF ingress node.
* the value of the <POLICY_DATA> object depends on the used policy.
* the PHR resource units must be included into the <R> parameter
of the "RMD QoS descriptor" field.
* the value of the <Message type> "parameter of the "PHR RMD
control information" filed object is set to 1, (i.e.,
PHR_Resource_Request)
* the value of the <Hop Count> parameter in the "PHR RMD control
information" has to be set to "1". The <Hop Count> value is
used to count the number of RMD reservation based NSIS aware
nodes that successfully processed the reservation based RMD-
QSPEC object.
* the value of the <Hop_U>parameter in the "PHR RMD control
information" has to be set to "0".
Bader, et al. [Page 18]
INTERNET-DRAFT RMD-QSP
* the flag "Acknowledge" (A) should be set "OFF"
* the "PDR RMD control information" field may not be included
into the message.
The RMD query procedure is needed in the case of the RMD measurement
based method, see e.g., [RIMA], while the RMD reservation procedure
is needed in case of reservation-based method, see e.g., [RODA].
When the intra-domain RESERVE (RMD-QSPEC) message is processed by
QNF interior (stateless) nodes, the QoS NSLP processing should not
keep state wherever possible, so that no QoS NSLP state is stored.
Some state, e.g. per traffic class, for the RMD-QSP related data may
be held at these interior nodes. The QoS NSLP also requests that
the NTLP uses different transport characteristics (i.e. sending of
messages in datagram mode, and not retaining optional path state).
Nodes, such as those in the interior of the stateless or reduced-
state domain, that do not retain reservation state (and so cannot
use summary refreshes) cannot send back RESPONSE messages.
The non-default values of the objects contained in the intra-domain
RESERVE(RMD- QSPEC) message must be set by each QNF interior node as
follows:
* the values of the <RSN>, <RII>, <REFRESH_PERIOD>,
<BOUND_SESSION_ID>, <POLICY_DATA> objects are not changed,
i.e., equal to the values set by the QNF ingress edge;
* the flag "Acknowledge" (A) should be set "OFF"
* the value of <R> parameter of the "RMD QoS
descriptors" field is used by the QNF interior node for
admission control;
* in case of the RMD reservation-based procedure, and if these
resources are admitted are going to be added to the currently
reserved resources per PHB and therefore they will become a
part of the per RMD traffic class (PHB) reservation state.
Furthermore, the value of the <Hop Count> parameter in the
"PHR RMD control information" field has to be increased by
one. The <Hop Count> value is used to count the number of RMD
reservation based NSIS aware nodes that successfully processed
the reservation based request, i.e., that successfully
processed the "PHR RMD control information" and "RMD QoS
descriptors" fields;
* in case of the RMD measurement based method, and if these
resources are admitted, using a MBAC algorithm, the number of
this resources will be used to update the MBAC algorithm.
When the intra-domain RESERVE (RMD-QSPEC) is received by the QNF
egress node the binding of the session associated with the intra-
Bader, et al. [Page 19]
INTERNET-DRAFT RMD-QSP
domain RESERVE (RMD-QSPEC) (the PHB session) with the session
included in its <BOUND_SESSION_ID> object must be accomplished. The
session included in the <BOUND_SESSION_ID> object is the session
associated with the inter-domain RESERVE message.
The "PHR RMD control information" field (and if available the "PDR
RMD control information") are read and processed by the RMD QoS
signaling model functionality. The value of <R> (and <PHB-DCLASS>)
of the "RMD QoS descriptors" field is used by the QNF egress node
for traffic class admission control.
* In case of the RMD reservation-based procedure, these
resources, if are admitted, are added to the currently
reserved resources per PHB and therefore they will become a
part of the per PHB reservation state. Furthermore, the value
of the <Hop Count> parameter in the "PHR RMD control
information" field has to be increased by one. The <Hop
Count> value is used to count the number of RMD reservation
based NSIS aware nodes that successfully processed the
reservation based "PHR RMD control information" and the "RMD
QoS descriptors" fields.
* In case of the RMD measurement-based method, the MBAC
algorithm is updated by the number of these resources, if the
admission control decision is positive.
At the QNF egress node the intra-domain RESERVE (RMD-QSPEC) message
is interpreted in conjunction with the reservation state from the
inter-domain RESERVE message (using information carried in the
message to correlate the signalling flows, i.e., BOUND_SESSION_ID).
The end to end RESERVE message is only forwarded further if the
processing of the intra-domain RESERVE (RMD-QSPEC) message was
successful at all nodes in the RMD domain, otherwise the inter
domain (end-to-end) reservation is considered as being failed.
Since NTLP neighbor relations are not maintained in the reduced-
state or stateless RMD domain, only sender initiated signaling can
be supported.
The QNF egress nodes should de-activate the
"NTLP QoS-NSLP-E2E-IGNORE" feature. Note that this is an
NTLP/GIMPS feature that is not yet specified in detail.
In return, after a positive response (i.e., successfully processed
inter-domain RESPONSE message) the inter-domain RESPONSE message
arrives at the QNF. The QNF egress must then include a "PDR RMD
control information" field (i.e., PDR_Reservation_Report) into this
end-to-end RESPONSE message. Note that for all upstream messages
the RAO is not set. Therefore, all interior nodes ignore the
end-to-end Response messages. The inter-domain RESPONSE (PDR)
message is sent to its upstream QoS-NSLP neighbor. Note that this
message will use a NTLP/GIMPS connection mode.
Bader, et al.
[Page 20]
INTERNET-DRAFT RMD-QSP
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| | | RESERVE
| | | |-->
| | | RESPONSE
| | | |<--
| |RESPONSE(PDR) | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
Figure 3: Basic operation of successful reservation procedure used by
the RMD-QSP
The non-default values of the objects contained in the inter-domain
RESPONSE message must be set by the QNF egress as follows:
* the values of the <RII/RSN>, <ERROR_SPEC> , [ *QSPEC ] objects
are set by the standard QoS-NSLP protocol functions;
* the value of the <PDR Message Type> parameter of the "PDR RMD
control information" field sould be set to 4 (i.e.,
PDR_Reservation_Report);
* the value of the <EP-Type> parameter of the "PDR RMD control
information" field should be equal to the QoS-NSLP protocol
ID;
* the value of the <PDR BOUND_SESSION_ID> of the "PDR RMD
control information" field should be equal to the SESSION_ID
of the bounded intra-domain RMD session.
This inter-domain RESPONSE (PDR) message is received by the QNF
ingress node. The non-default values of the objects contained in
the inter-domain RESPONSE message that is forwarded out the RMD
domain, must be set by the QNF ingress node as follows:
* the values of the <RII/RSN>, <ERROR_SPEC>, [ *QSPEC ] objects
are set by the standard QoS-NSLP protocol functions;
Bader, et al. [Page 21]
INTERNET-DRAFT RMD-QSP
* the "PDR RMD control information" field has to be processed
and removed by the RMD-QSP functionality in
the QNF ingress node. The RMD QoS model functionality is
notified by reading the <PDR M> parameter of the "PDR RMD
control information" that the reservation has been successful.
The QNF ingress nodes should also de-activate the
"NTLP QoS-NSLP-E2E-IGNORE" feature.
4.5.2.2. Unsuccessful reservation
This section describes the operation where a request for reservation
cannot be satisfied by the RMD-QSP.
The QNF ingress, the QNF interior and QNF egress nodes process and
forward the inter-domain RESERVE message and the intra-domain
RESERVE (RMD-QSPEC) message in the same way as specified in Section
4.5.2.1. The main difference between the unsuccessful operation and
successful operation is that one of the QNF nodes will not admit the
request due to lack of resources. This also means that the QNF edge
node does not forward the inter-domain RESERVE message towards the
QNR node and it is discarded.
When an inter-domain RESERVE message arrives to the QNF ingress and
if there are no resources available locally, the QNF ingress rejects
this inter-domain RESERVE message and sends a RESPONSE message back
to the sender, using a standard QoS-NSLP procedure.
Any QNF edge or QNF interior node that receives the "RMD QoS
descriptor" field and the "PHR_Resource_Request" control information
field it must identify the traffic class state (PHB).
In case of the RMD reservation based scenario, and if the
reservation request, i.e., "RMD QoS descriptors" and
"PHR_Resource_Request" control information fields, is not admitted
by the QNF node then the <Hop_U> and <M> parameters of the "PHR RMD
control information" have to be set to "1". In this case the <Hop
Count> counter value must not be increased.
In case of the RMD measurement based scenario, and if the
reservation request is not admitted by the MBAC algorithm used at
the QNF node, then the <M> parameter of the "PHR RMD control
information" field has to be set to "1".
In general, if a QNF interior node receives a "PHR RMD control
information" field, of type "PHR_Resource_Request", with the <M>
parameter set to "1" then this "PHR RMD control information" and the
"RMD QoS descriptors" fields must not be processed, i.e., their
parameters will not be read and/or modified.
Bader, et al. [Page 22]
INTERNET-DRAFT RMD-QSP
In both scenarios, i.e., RMD reservation based and RMD measurement
based scenario, when the <M> marked intra-domain RESERVE (RMD-QSPEC)
is received by the QNF egress node (see Figure 4) a binding 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 accomplished. The session included in the
<BOUND_SESSION_ID> object is the session associated with the end-to-
end RESERVE.
The QNF egress node must generate a inter-domain RESPONSE message
that will have to be sent to its previous stateful QoS-NSLP hop.
This message must include a "PDR RMD control information" field (of
type PDR_Reservation_Report). Note that this message will use a
NTLP/GIMPS connection mode. The QNF egress requests from NTLP/GIMPS
to activate the QoS-NSLP-E2E-IGNORE feature. The non-default values
of the objects contained in the inter-domain RESPONSE (PDR) message
must be set by the QNF egress node as follows:
* the values of the <RII/RSN>, <ERROR_SPEC>, [ *QSPEC] objects
are set by the standard QoS-NSLP protocol functions;
* the value of the <Message Type> field of the "PDR RMD control
information" field should be set to "4"
(PDR_Reservation_Report);
* the value of the <Hop Count> parameter of the "PHR RMD control
information" field included in the received <M> marked intra-
domain RESERVE (RMD-QSPEC) message must be included in the
<Hop Count> parameter of the "PDR RMD control information"
field;
* the value of the <PDR M> parameter of the "PDR RMD control
information" field must be set to "1";
* the value of the <EP-Type> parameter of the "PDR RMD control
information" field should be equal to the QoS-NSLP protocol
ID;
* the value of the <PDR BOUND_SESSION_ID> of the "PDR RMD
control information" field should be equal to the SESSION_ID
of the bounded intra-domain RMD session.
The non-default values of the objects contained in the inter-domain
RESPONSE (PDR) message must be set by the QNF ingress node, which
receives this message, as follows:
* the values of the <RII/RSN>, <ERROR_SPEC> ], [*QSPEC] objects
are set by standard QoS-NSLP protocol functions;
Bader, et al.
[Page 23]
INTERNET-DRAFT RMD-QSP
* the PDR object has to be processed and removed by the RMD QoS
signaling model functionality in the QNF ingress node. The
RMD QoS model functionality is notified by reading the <PDR M>
parameter of the "PDR RMD control information" that the
reservation has been unsuccessful. In case of a RMD
reservation based scenario, the RMD-QSP
functionality, has to start an RMD release procedure (see Section
4.5.2.5). The QNF ingress nodes should also de-activate the
"NTLP QoS-NSLP-E2E-IGNORE" feature.
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:M =1) |
| |------------------>| |
| | | RESERVE(RMD-QSPEC:M=1)
| | |------------------->|
| |RESPONSE(PDR) | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
Figure 4: Basic operation during unsuccessful reservation
initiation used by the RMD-QSP
4.5.2.3 RMD refresh reservation
In case of RMD measurement-based method, QoS-NSLP states in the RMD
domain are not maintained, therefore, the inter-domain RESERVE
(refresh) message is sent directly to the QNF egress edge.
The refresh procedure in case of RMD reservation-based method
follows a similar scheme as the reservation process, shown in Figure
3. If the RESERVE messages arrive within the time-out period, the
corresponding number of resource units is not removed. However, in
this scenario the generation of the inter-domain RESERVE message, by
the QNF edges, depends on the maintained refreshed period (see [QoS-
NSLP]). In other words the moment that the inter-domain refresh
RESERVE message is sent by the QNF egress node downstream to its
next hop, depends on the maintained refresh period and not on the
moment that the intra-domain RESERVE (RMD-QSPEC) message, which is
bound to it, is received by the QNF egress node. The QoS-NSLP-E2E-
IGNORE feature of NTLP/GIMPS must be activated by QNF ingress and
deactivated by the QNF egress node.
Bader, et al. [Page 24]
INTERNET-DRAFT RMD-QSP
The RMD-QSP functionality available in the QNF
ingress node must be able to generate intra-domain RESERVE (RMD-
QSPEC) messages that will be sent towards the QNF egress node, in
order to refresh the RMD traffic class state in the QNF edges and
interior nodes. Before generating this message, the RMD QoS
signaling model functionality is using the RMD traffic class (PHR)
resource units for refreshing the RMD traffic class state.
Note that the RMD traffic class refresh periods should be equal in
all QNF edge and QNF interior nodes and should be smaller (default:
more than two times) than the refresh period at the QNF ingress node
used by the inter-domain RESERVE message. This intra-domain RESERVE
(RMD-QSPEC) message must include a "RMD QoS descriptors" field and a
"PHR control information" field (i.e., PHR_Refresh_Update), and it
may include a "PDR RMD control information" field, (i.e.,
PDR_Refresh_Request).
The selection of the IP source and destination address of this
message depends on if and how the different inter domain
(end-to-end) flows can be aggregated by the QNF ingress node. Note
that this aggregation procedure is different than the RMD traffic
class aggregation procedure. One example approach is the approach
used by the RSVP aggregation scenario ([RFC3175]), where the IP
source address of this message is the IP address of the aggregator
(i.e., QNF ingress edge) and the IP destination address of this
message is the IP address of the De-aggregator (i.e., QNF egress).
Another example approach is the approach used in "RSVP Refresh
Overhead Reduction Extensions" ([RFC2961]). If no aggregation
procedure is possible then the IP destination address of this
message should be equal to the IP destination address of its
associated inter-domain RESERVE message.
An example of this RMD specific refresh operation can be seen in
Figure 5.
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| | | |
| |RESPONSE(RMD-QSPEC)| |
|<------------------------------------------------------------|
| | | |
Figure 5: Basic operation of RMD specific refresh procedure
Bader, et al. [Page 25]
INTERNET-DRAFT RMD-QSP
The most of the non-default values of the objects contained in this
message are set by the QNF ingress in the same way as described in
Section 4.5.2.1. The following objects are set differently:
* the flag "Acknowledge" (A) should be set "OFF"
* the PHR resource units must be included into the <R> parameter
of the "RMD QoS descriptors" field. The value of the <R>
parameter depends on how the different inter domain (end-to-end)
flows can be aggregated by the QNF ingress node (e.g., the sum of
all the PHR requested resources of the aggregated flows). If no
flow aggregation is accomplished by the QNF ingress node, then
the value of the <R> parameter should be equal to the <R>
parameter of its associated new (initial) intra-domain RESERVE
(RMD-QSPEC) message;
* the value of the <Message Type> parameter of the "PHR RMD
control information" field is set to "2" (i.e.,
PHR_Refresh_Update);
* the values of the "PDR RMD control information" field may not
be included into the message.
The intra-domain RESERVE (RMD-QSPEC) message is received and
processed by the QNF interior nodes. Any QNF edge or QNF interior
node that receives a "PHR_Refresh_Update" control information field
it must identify the traffic class state (PHB) (using the
<PHB-DCLASS> parameter). The most of the non default values of the
objects contained in this refresh intra-domain RESERVE (RMD- QSPEC)
message are set by a QNF interior node in the same way as described
in Section 4.5.2.1.
The following objects are set and processed differently:
* the value of <R> parameter of the "RMD QoS descripto
rs" field
is used by the QNF interior node for refreshing the RMD
traffic class state. These resources (included in <R>),
if reserved, are added to the currently reserved resources
per PHB and therefore they will become a part of the per traffic
class (per-PHB) reservation state. If the refresh procedure
cannot be fulfilled then the <M> parameter of the "PHR RMD
control information" has to be set to "1".
Any QNF edge or QNF interior node that receives a
"PHR_Resource_Release" Control information field, must identify the
traffic class state (PHB) and release the requested resources
included in the <R> parameter of the "RMD QoS descriptors" field.
Any "PHR RMD control information" of type "PHR_Refresh_Update", and
its associated "RMD QoS descriptors" filed (i.e., <R>), whether it
is marked or not, is always processed, but marked bits are not
changed.
Bader, et al. [Page 26]
INTERNET-DRAFT RMD-QSP
The intra-domain RESERVE (RMD-QSPEC) message is received and
processed by the QNF egress node. The "RMD QoS descriptors" and the
"PHR RMD control information" fields (and if available the "PDR RMD
control information") are read and processed by the RMD QoS
signaling model functionality. The value of <R> parameter of the
"RMD QoS descriptors" is used by the QNF egress node for refreshing
the RMD traffic class state. If the refresh procedure cannot be
fulfilled then the <M> parameter of the "PHR RMD control
information" field has to be set to "1".
A new intra-domain RESPONSE (PDR) message is generated by the
QNF egress node. This message must include a "PDR RMD control
information" (of type PDR_Refresh_Report).
This intra-domain RESPONSE (PDR) message must be sent to the QNF
ingress node, i.e., previous stateful hop. This can, for example,
be accomplished by using the value of the <RII> included in the
received intra-domain RESERVE(RMD- QSPEC) message. In general
downstream nodes that desire responses may keep track of this RII to
identify the RESPONSE when it passes back through them. This <RII>
value will be included in the <RII> object of the generated
intra-domain RESPONSE (PDR) message. The most of the non-default
values of the objects contained in this refresh intra-domain
RESPONSE (PDR) message are set by a QNF egress node in the same way
as described in Section 4.5.2.1.
The following objects are set and processed differently:
* the value of the <RII> object is equal to the value of the RII
that is used by the QNF ingress to identify the RESPONSE when
it passes back through it. This value was carried by the
intra-domain RESERVE (RMD-QSPEC) message in the <RII> object;
* the value of the <PDR Message Type> parameter of the "PDR RMD
control information" should be set to "5" (i.e.,
PDR_Refresh_Report);
* the value of the <PDR M> field of the "PDR RMD control
information" must be equal to the value of the <M> parameter
of the "PHR RMD control information" that was carried by its
associated intra-domain RESERVE (RMD-QSPEC) message.
* the value of the <PDR BOUND_SESSION_ID> of the "PDR RMD
control information" field should be equal to the SESSION_ID
of the bounded intra-domain RMD session.
When the intra-domain RESPONSE (PDR) message is received by
the QNF ingress node, then:
* the values of the <RII/RSN>, <ERROR_SPEC>, [ *QSPEC] objects
are processed by the standard QoS-NSLP protocol functions;
Bader, et al. [Page 27]
INTERNET-DRAFT RMD-QSP
* the "PDR RMD control information" has to be processed and
removed by the RMD-QSP functionality in the
QNF ingress node. The RMD-QSP functionality
is notified by reading the <PDR M> parameter of the "PDR RMD
control information" that the refresh procedure has been
successful or unsuccessful. All session(s) (in case of the
flow aggregation procedure there will be more than one
sessions) associated with this RMD specific refresh session
must be informed about the success or failure of the refresh
procedure. In case of failure, the NF ingress node has to
generate (in a standard QoS-NSLP way) an error inter-domain
RESPONSE message that will be sent towards QNI.
4.5.2.4. RMD modification of reservation
When the RMD QoS model functionality of the NF ingress node receives
an end- to-end RESERVE message that is requesting a modification on
the number of reserved resources then the following process can be
realized. When the modification request requires an increase on the
number of reserved resources, then the RMD QoS model functionality
of the ingress node will have to subtract the old and already
reserved number of resources from the number of resources included
in the new modification request. The result of this subtraction
should be introduced within the <R> parameter of the "RMD QoS
descriptors" field, which is sent together with a
"PHR_Resource_Request" control information field. If a QNF edge or
QNF interior node is not able to reserve the number of requested
resources, then the "PHR_Resource_Request" control information field
that is associated with the <R> parameter will be marked. In this
situation the RMD specific operation for a unsuccessful reservation
functionality will be applied for this case (see Section 4.5.2.2).
When the modification request requires a decrease on the number of
reserved resources, then the QNF ingress node will have to subtract
the number of resources included in the new modification request
from the old and already reserved number of resources. The result
of this subtraction should be introduced in the <R> parameter of the
"RMD QoS descriptors" field, which is sent together with a
PHR_Release_Request control information field. Subsequently a RMD
release procedure should be accomplished (see Section 4.5.2.5).
4.5.2.5 RMD release procedure
Resources in QNF interior nodes are removed after time-out if a
refresh message does not arrive in time in case of reservation-based
method.
This soft state behavior provides certain robustness for the system
ensuring that unused resources are not reserved for long time.
However, if even more efficient resource management is needed,
resources can be removed by explicit release procedure within the
refresh period.
Bader, et al. [Page 28]
INTERNET-DRAFT RMD-QSP
In general, when the RMD QoS model functionality of a QNF edge or
QNF interior node processes a "PHR_Release_Request" control
information field it must identify the value of the <PHB-DCLASS>
parameter included in the "RMD QoS descriptors" field, and estimate
the refresh period where it last signaled the resource usage (where
it last processed a "PHR_Refresh_Update" control information field).
This may be done by, for example, giving the opportunity to a QNF
ingress node to calculate the time lag, say "T_lag", between the
last sent "PHR_Refresh_Update" control information field and the
"PHR_Release_Request" control information field. The value of this
time lag "T_Lag", is first normalized to the length of the refresh
period, say "T_period". In other words, the ratio between this time
lag, "T_Lag", and the length of the refresh period, "T_period", is
calculated. This ratio is then introduced into the <Time Lag>
parameter of
the "PHR_Release_Request" control information field.
When a node (QNF edge or QNF interior) receives this
"PHR_Release_Request" control information, it must store its arrival
time. Then it must calculate the time difference, say "Tdiff",
between this arrival time and the start of the current refresh
period, "T_period". Furthermore, this node must derive the value of
the time lag "T_Lag", from the <Time Lag> parameter.
This can be found by multiplying the value included in the <Time
Lag> parameter with the length of the refresh period, "T_period".
If the derived time lag, "T_lag", is smaller than the calculated
time difference, "T_diff", then this node MUST decrease the PHB
reservation state with the number of resource units indicated in the
<R> parameter of the "RMD QoS descriptors" field that has been sent
together with the "PHR_Release_Request" control information field,
but not below zero.
An RMD specific release procedure can be triggered by an inter-domain
RESERVE with a TEAR flag set ON (see Section 4.5.2.5.1) or it can be
triggered by either a RESPONSE or NOTIFY message that includes a
marked (i.e., <PDR M> and/or <PDR S> parameters are set ON)
"PDR_Reservation_Report" control information field (see Section
4.2.2.2) or "PDR_Congestion_Report" control information field (see
Section 4.5.2.6).
4.5.2.5.1. Triggered by a RESERVE message
This RMD explicit release procedure can be triggered by a tear (TEAR
flag set ON) inter-domain RESERVE message. When a tear (TEAR flag
set ON) inter-domain RESERVE message arrives to the QNF ingress edge
then the QNF ingress node should process the message in a standard
QoS-NSLP way (see [QoS-NSLP]). In addition to this, the RMD QoS
signaling model functionality must be notified. It will generate an
intra-domain RESERVE (RMD-QSPEC) message. Before generating this
message, the RMD QoS model functionality is using the RMD traffic
class (PHR) resources (specified in <R>) and the PHB type (specified
in <PHB-DCLASS>) for a RMD release procedure. This can be achieved
by subtracting the amount of the requested resources from the total
reserved amount of resources stored in the RMD traffic class state.
Bader, et al. [Page 29]
INTERNET-DRAFT RMD-QSP
This intra-domain RESERVE (RMD-QSPEC) message must include a "RMD
QoS descriptors" field and a "PHR RMD control information" field,
(i.e., "PHR_Resource_Release") and it may include a "PDR RMD control
information" field, (i.e., PDR_Release_Request). An example of this
operation can be seen in Figure 6.
The most of the non default values of the objects contained in the
tear intra-domain RESERVE message are set by the QNF ingress node in
the same way as described in Section 4.5.2.1. The following objects
are set differently:
* the flag "Acknowledge" (A) should be set "OFF"
* The <RII> object is not included in this message. This is
because the QNF ingress node does not need to receive a
response from the QNF egress node;
* the TEAR flag is set to ON;
* the PHR resource units must be included into the <R> parameter
of the "RMD QoS descriptors" field;
* the value of the <Hop Count> parameter in the "PHR RMD control
information" field has to be set to one. The <Hop Count>
value is used to count the number of RMD reservation based
NSIS aware nodes that successfully processed the reservation
request.
* the value of the <Time Lag> parameter of the "PHR RMD control
information" is calculated by the RMD-QSP
functionality (see introductory part of Section 4.5.2.5)
the value of the <Message Type> parameter of "PHR RMD control
information" is set to "3" (i.e., PHR_Resource_Release)
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC:Tear=1) | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:Tear=1) |
| |------------------->| |
| | RESERVE(RMD-QSPEC:Tear=1)
| | |------------------->|
| | | RESERVE
| | | |-->
| | |
Figure 6: Explicit release triggered by RESERVE used by the RMD-QSP
Bader, et al. [Page 30]
INTERNET-DRAFT RMD-QSP
The intra-domain tear RESERVE (RMD-QSPEC) message is received and
processed by the QNF interior nodes. The most of the non default
values of the objects contained in this refresh intra-domain RESERVE
(RMD-QSPEC) message are set by a QNF interior node in the same way
as described in Section 4.5.2.1. The following objects are set and
processed differently:
* Any QNF interior node that receives the combination of the "RMD
QoS descriptors" filed and the "PHR_Resource_Release" control
information field, it must identify the traffic class state (PHB)
(specified in <PHB-DCLASS>) and release the requested resources
included in the <R> parameter. This can be achieved by subtracting
the amount of RMD traffic class requested resources, included in the
<R> parameter, from the total reserved amount of resources stored in
the RMD traffic class state. The value of the <Time Lag> parameter
of the "PHR_Resource_Release" control information field is used
during the release procedure as explained in the introductory part
of Section 4.5.2.5
The intra-domain tear RESERVE (RMD-QSPEC) message is received and
processed by the QNF egress node. The "RMD QoS descriptors" and the
"PHR RMD control field" (and if available the "PDR RMD control
information" field) are read and processed by the RMD QoS signaling
model functionality. The value of the <R> parameter of the "RMD QoS
descriptors" field and the value of the <Time Lag> field of the "PHR
RMD QoS control information" field must be used by the RMD release
procedure. This can be achieved by subtracting the amount of RMD
traffic class requested resources, included in the <R> parameter,
from the total reserved amount of resources stored in the RMD
traffic class state.
The inter-domain RESERVE message is forwarded by the next hop (i.e.,
QNF egress) only if the intra-domain tear RESERVE (RMD-QSPEC)
message arrives at the QNF egress node. The QoS-NSLP-E2E-IGNORE
feature of NTLP/GIMPS must be deactivated.
4.5.2.5.2 Triggered by a marked RESPONSE or NOTIFY message
This RMD explicit release procedure can be triggered by either an
inter-domain RESPONSE (PDR) message with a <PDR M> marked "PDR RMD
control information" field (see Section 4.5.2.2) or a intra-domain
NOTIFY (PDR) message (see Section 4.5.2.6) with a <M> or <S> marked
"PDR RMD control information" field. This RMD specific release
procedure can be terminated at any NF interior node or NF edge
node. The RMD specific explicit release procedure that is
terminated at a QNF interior (or QNF edge) node is denoted as RMD
specific partial release procedure. This
explicit release procedure
can be, for example, used during a RMD specific operation for
unsuccessful reservation (see Section 4.5.2.2) or severe congestion
(see Section 4.5.2.6). When the RMD QoS signaling model
functionality of a QNF ingress node receives a <M> or <S> marked
"PDR RMD control information" field of type "PDR_Reservation_Report"
Bader, et al. [Page 31]
INTERNET-DRAFT RMD-QSP
or "PDR_Congestion_Report", it must start an RMD partial release
procedure. The QNF ingress node generates a intra-domain RESERVE
(RMD-QSPEC) message. Before generating this message, the RMD-QSP
functionality is using the RMD traffic class (PHR) resource units
for a RMD release procedure. This can be achieved by subtracting
the amount of RMD traffic class requested resources from the total
reserved amount of resources stored in the RMD traffic class state.
When the generation of the intra-domain RESERVE (RMD-QSPEC) message
is triggered by a intra-domain NOTIFY (PDR) message then this
generated intra-domain RESERVE (RMD-QSPEC) message must include a
<RMD QoS descriptors> field and a <PHR RMD control information>
field, (i.e., PHR_Resource_Release) and a "PDR RMD control
information field", (i.e., PDR_Release_Request). An example of this
operation can be seen in Figure 7.
NF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | | |
| NOTIFY (PDR) | | |
|<-------------------------------------------------------|
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=SET) | |
| ---------------->|RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET) |
| | | |
| |----------------->| |
| | ESERVE(RMD-QSPEC:Tear=1, M=1,S=SET)
| | |----------------->|
Figure 7: Basic operation during RMD explicit release procedure
triggered by NOTIFY used by the RMD-QSP
When the generation of the intra-domain RESERVE (RMD-QSPEC) message
is triggered by an inter-domain RESPONSE (PDR) message then this
generated intra-domain RESERVE (RMD-QSPEC) message must include a
<RMD QoS descriptors> field and a <PHR RMD control information>
field, (i.e., PHR_Resource_Release) and a "PDR RMD control
information field", (i.e., PDR_Release_Request). An example of this
operation can be seen in Figure 8.
The most of the non default values of the objects contained in the
tear intra-domain RESERVE (RMD-QSPEC) message are set by the QNF
ingress node in the same way as described in Section 4.2.5.1.
The following objects are set differently:
* The value of the <M> parameter of the "PHR RMD control
information" must be set to "1".
* When the tear intra-domain RESERVE message is triggered by a
NOTIFY message, then the value of the <S> parameter of the
"PHR RMD control information" field must be set to "1". The
RESERVE message should include "PDR RMD control information".
Bader, et al. [Page 32]
INTERNET-DRAFT RMD-QSP
* When the tear intra-domain RESERVE message is triggered by a
RESPONSE (PDR) message, then the value of the <PDR Hop Count>
parameter of the "PDR RMD control information" field included in
the received <M> marked intra-domain RESPONSE (PDR) message must
be included in the <PDR Hop Count> parameter of the "PDR RMD
control information" field of the RESERVE message. The value of
the EP-Type parameter of the PDR message should be equal to the
QoS-NSLP protocol ID.
* When the generation of the intra-domain RESERVE (RMD-QSPEC)
message is triggered by a NOTIFY (PDR) message then this
generated intra-domain RESERVE (RMD- QSPEC) message does not
include a "PDR RMD control information" field.
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
Node that marked
PHR_Resource_Request
<PHR> object
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | | |
| RESPONSE (RMD-QSPEC: M=1) | |
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC: Tear=1, M=1, <PDR Hop Count>=<Hop Count>)|
|------------------->| | |
| | | |
Figure 8: Basic operation during RMD explicit release procedure
Triggered by RESPONSE used by the RMD-QSP
Any QNF edge or QNF interior node that receives a combination of the
"RMD QoS descriptors" field and the "PHR_Resource_Release" control
information field it must identify the traffic class state (PHB),
using the <PHB-DCLASS> parameter> and release the requested
resources included in the <R> field. This can be achieved by
subtracting the amount of RMD traffic class requested resources,
included in the <R> field, from the total reserved amount of
resources stored in the RMD traffic class state. The value of the
<Time Lag> parameter of the "PHR RMD control information" field is
used during the release procedure as explained in the introductory
part of Section 4.5.2.5. Furthermore, the <Hop Count> value included
in the "PHR RMD control information" field is increased by one. If
the value of <M> parameter of the "PHR_Resource_Release" control
information field is "1" and if the value of the <S> parameter is
set to "0" then the <PDR Hop Count> value included in the "PDR RMD
control information" field must be compared with the calculated
PHR <Hop Count> value. When these two values are equal then the
intra-domain RESERVE(RMD-QSPEC) has to be terminated and it will not
be forwarded downstream. The reason of this is that the QNF node
that is currently processing this message was the last QNF node that
successfully processed the "RMD QoS descriptors" and "PHR RMD
Bader, et al. [Page 33]
INTERNET-DRAFT RMD-QSP
control information" fields of its associated initial reservation
request (i.e., initial intra-domain RESERVE (RMD-QSPEC) message).
Its next QNF downstream node was unable to successfully process the
initial reservation request, and therefore this QNF node marked the
<M> parameter of the "PHR_Resource_Request" control information
field. When the values of the <M> and <S> parameters are set to
"0", then this message will not be terminated by a QNF interior
node, but it will be forwarded in the downstream direction. The QNF
egress node will receive and process the PHR_Resource_Release
control information field. Afterwards, the QNF egress node must
terminate the intra-domain RESERVE (RMD-QSPEC) object.
4.5.2.6. Severe congestion
This section describes the operation of the RMD-QSP
where a severe congestion occurs within the Diffserv domain.
Severe congestion can be considered as an undesirable state, which
may occur as a result of a route change. Congestion can also occur
in an interior node due to the underestimation of the data traffic,
inappropriate policer settings, or due to the uncertainty introduced
by the measurement method. Typically, routing algorithms are able
to adapt and change their routing decisions to reflect changes in
the topology (e.g., link failures) and traffic volume. In such
situations, the re-routed traffic follows a new path. Nodes located
on this new path may become overloaded after rerouting. Moreover,
when a link fails, the traffic passing through might be dropped,
degrading its performance.
In this situation the available resources may not be enough to meet
the required QoS for all the flows along the new path. Therefore,
one or more flows should be terminated. Interior nodes notify edge
nodes by data marking (proportional marking) or marking the refresh
messages using the <S> and < Overload %> parameters. In this
version of this draft only the severe congestion handling procedure
that uses the proportional marking is explained. Future versions of
this draft will specify the severe congestion handling procedure
that uses the marking of the refresh messages.
Congestion handling function of RMD can be used for implementing a
simple measurement based admission control within a Diffserv domain.
It is possible that not all the nodes along the path implement and
run admission control, only a few interior nodes are responsible for
admission control. In these nodes there may be predefined
thresholds that can be set for the different PHBs. If the threshold
is exceeded refresh messages or the data packets can be marked to
indicate the high load of different PHBs.
Bader, et al. [Page 34]
INTERNET-DRAFT RMD-QSP
4.5.2.6.1 Severe congestion using proportional data packet marking
In order to eliminate severe congestion the degree of overload can
also be indicated, e.g. by using proportional marking. Egress Edge
receiving the severe congestion notification measures the overload
and sends an intra-domain NOTIFY (PDR) message to the Ingress Edge
with the IDs of the sessions that should be terminated.
Severe congestion occurrence in the communication path has to be
notified to the QNF edge node that generated the RESERVE message.
The QNF Interior node detecting severe congestion marks data packets
passing of the node in which the severe congestion was detected.
For severe congestion marking of the data packet, three PHBÆs should
be allocated for each traffic class. One is used to indicate that
the packet is passed a congested node or not. The other code-point
can be used to indicate the degree of congestion. This can be done
for example using the proportional marking method, which means that
the marked bytes are proportional to the degree of congestion. The
QNF egress node is using a predefined policy to solve the severe
congestion, by selecting a number of inter domain (end-to-end)
flows that should be terminated. For these flows (sessions), the
QNF egress node generates and sends an intra-domain NOTIFY (PDR)
message to the QNF ingress node (its previous stateful QoS-NSLP hop)
to indicate the severe congestion in the communication path. This
message must include a "PDR RMD control information" field (of type
"PDR_Reservation_Report"). The value of the <PDR BOUND_SESSION_ID>
parameter of the "PDR_Reservation_Report" control information field
must be the same as the SESSION_ID of the flow that has to be
terminated. Note that this message should use a NTLP/GIMPS
connection mode.
The non-default values of the objects contained in the NOTIFY (PDR)
message must be set by the QNF egress node as follows:
* the values of the <ERROR_SPEC> object is set by the standard
QoS-NSLP protocol functions.
* the value of the <PDR Message Type> parameter of the "PDR RMD
control information" field object should be set to "8" (i.e.,
PDR_Congestion_Report).
* The value of the <PDR M> parameter of the "PDR RMD control
information" field must be set to "1".
* The value of the <PDR S> parameter of the "PDR RMD control
information" field must be set to "SET".
* the value of the <PDR BOUND_SESSION_ID> parameter of the
"PDR_Reservation_Report" control information field must be the
same as the SESSION_ID of the flow that has to be terminated.
Bader, et al. [Page 35]
INTERNET-DRAFT RMD-QSP
* the value of the EP-Type field of the "PDR RMD control
information" field should be the QoS-NSLP protocol ID.
Upon receiving this message, the QNF ingress node resolves the
severe congestion by a predefined policy, e.g., refusing new
incoming flows (sessions), terminating the affected and notified
flows (sessions), or shifted to an alternative RMD traffic class
(PHB). An example of such an operation is depicted in Figure 9.
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
user | | | |
data | user data | | |
------>|----------------->| user data | user data |
| |---------------->S(# marked bytes) |
| | S----------------->|
| | S(# unmarked bytes)|
| | S----------------->|Term.
| NOTIFY(PDR) |flow?
|<----------------|------------------|------------------|YES
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=SET) | |
| --------------->|RESERVE(RMD-QSPEC:T=1, M=1,S=SET) |
| | | |
| |----------------->| |
| | RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET)
| | |----------------->|
Figure: 9 RMD severe congestion handling
4.5.3. Bi-directional operation
RMD assumes asymmetric routing by default. Combined sender-receiver
initiated reservation cannot be done in the RMD domain because
upstream NTLP states are not stored in interior routers. Therefore
the bi-directional operation should be performed by two sender-
initiated reservations. We assume that the QNF edge nodes are
common for both upstream and downstream directions, therefore, the
two reservations/sessions can be bounded at the QNF edge nodes.
This bi-directional sender + sender procedure can then be applied
between the QNF edges (QNF ingress and QNF egress) nodes of the RMD
QoS signaling model. In the situation that a security/policy
association exists between the QNF ingress and QNF egress nodes (see
Figure 10), and the QNF ingress node has the required <R> parameters
for both directions, i.e., QNF ingress towards QNF egress and QNF
egress towards QNF ingress, then the QNF ingress may include both
<R> parameters (needed for both directions) into the RMD-QSPEC
within a RESERVE message. In this way the QNF egress node will be
able to use the QoS parameters needed for the "egress towards
ingress" direction (QoS-2). The QNF egress is then able to create a
RESERVE with the right QoS parameters included in the QSPEC, i.e.,
RESERVE (QoS-2).Both directions of the flows are bound by inserting
the <BOUND_SESSION_ID> object at the QNF ingress and QNF egress.
Bader, et al. [Page 36]
INTERNET-DRAFT RMD-QSP
|------ RESERVE
(QoS-1, QoS-2)----|
| V
| Interior/stateless QNEs
+---+ +---+
|------->|QNE|-----|QNE|------
| +---+ +---+ |
| V
+---+ +---+
|QNE| |QNE|
+---+ +---+
^ |
| | +---+ +---+ V
| |-------|QNE|-----|QNE|-----|
| +---+ +---+
Ingress/ Egress/
statefull QNE statefull QNE
|
<--------- RESERVE (QoS-2) -------|
Figure 10: The bi-directional reservation scenario in the RMD domain
A bidirectional reservation, within the RMD domain, is indicated by
the <B> and <PDR B>, which are set in all messages. Upstream end-
to-end messages include the session ID of downstream messages using
BOUND_SESSION_ID and vice versa.
In the situation that no security/policy association exists between
the QNF ingress and QNF egress nodes the Bi-directional reservation
for the sender + sender scenario in the RMD domain should use the
scenario specified in [QoS-NSLP] as Bi-directional reservation for
sender + sender scenario.
Note that in the following sections it is considered that the QNF
edge nodes are common for both upstream and downstream directions
and therefore, the two reservations/sessions can be bounded at the
QNF edge nodes. Furthermore, it is considered that a
security/policy association exists between the QNF ingress and QNF
egress nodes, and the QNF ingress node has the required <R>
parameters for both directions, i.e., QNF ingress towards QNF egress
and QNF egress towards QNF ingress.
4.5.3.1 Successful and unsuccessful reservations
This section describes the operation of the RMD-QSP
where a RMD bi-directional reservation operation is either
successfully or unsuccessfully accomplished.
The bi-directional successful reservation is similar to a
combination of two unidirectional successful reservations that are
accomplished in opposite directions, see Figure 11. The main
differences of the bi-directional successful reservation procedure
Bader, et al. [Page 37]
INTERNET-DRAFT RMD-QSP
with the combination of two unidirectional successful reservations
accomplished in opposite directions are as follows. The intra-
domain RESERVE message sent by the QNF ingress node towards the QNF
egress node, is denoted in Figure 11 as RESERVE (RMD-QSPEC):
"forward". The main differences between the RESERVE (RMD-QSPEC):
"forward" message used for the bi-directional successful reservation
procedure and a RESERVE (RMD-QSPEC message used for the
unidirectional successful reservation are as follows:
* the <B> bit of the "PHR RMD control information" field indicates
a bi-directional reservation and is set to "1".
* the "PDR RMD control information" field is included into the
RESERVE(RMD-QSPEC): "forward" message. The value of the PDR
<Message Type> is "1", i.e., "PDR_Reservation_Request".
* the <PDR B> bit indicates a bi-directional reservation and is set
to "1".
* the <PDR Reverse Requested Resources> field specifies the
requested bandwidth that has to be used by the QNF egress node to
initiate another intra-domain RESERVE message in the reverse
direction.
* the response "PDR RMD control information" field sent by a QNF
egress to a QNF ingress node is not carried by a RESPONSE
message, but it is carried by a RESERVE message that is sent by
the QNF egress node towards the QNF ingress node (denoted in
Figure 11 as RESERVE (RMD-QSPEC): "reverse").
The RESERVE (RMD-QSPEC): "reverse" message is initiated by the QNF
egress node at the moment that the RESERVE (RMD-QSPEC): "forward"
message is successfully processed by the QNF egress node. The main
differences between the RESERVE (RMD-QSPEC): "reverse" message used
for the bi-directional successful reservation procedure and a
RESERVE (RMD-QSPEC) message used for the unidirectional successful
reservation are as follows:
* the value of the <R> field is set equal to the value of the
<PDR Reverse Requested Resources> field included in the
RESERVE (RMD-QSPEC): "forward" message that triggered the
generation of this RESERVE (RMD-QSPEC): "reverse" message
* the <B> bit of the "PHR RMD control information" field
indicates a bi-directional reservation and is set to "1"
* the "PDR RMD control information" field is included into the
RESERVE(RMD-QSPEC): "reverse" message. The value of the PDR
<Message Type> is "4", i.e., "PDR_Reservation_Report"
* the <PDR B> bit indicates a bi-directional reservation and is
set to "1"
Bader, et al. [Page 38]
INTERNET-DRAFT RMD-QSP
* the value of the <PDR BOUND_SESSION_ID> field is set equal to
the SESSION_ID of the intra domain session associated with the
RESERVE (RMD-QSPEC): "forward" message that triggered the
generation of this RESERVE (RMD-QSPEC): "reverse" message.
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | | |
| | RESERVE(RMD-QSPEC): |
|------------------->| "forward" | |
| | | |
| |--------------------------------------->|
| | | |
| | | |
| | | RESERVE(RMD-QSPEC)|
| Reserve(RMD-QSPEC) | "reverse" |
| "reverse" | |<-------------------|
|<---------------------------------------| |
| | | |
Figure 11: Intra-domain signaling operation for successful
bi-directional reservation
Figure 12 and Figure 13 show the flow diagrams used in case of a
unsuccessful bi-directional reservation. In the former figure it is
considered that the QNF that is not able to support the requested
<R> is located in the direction QNF ingress towards QNF egress. In
the latter figure it is considered that the QNF that is not able to
support the requested <R> is located in the direction QNF egress
towards QNF ingress.
The main differences between the bi-directional unsuccessful
procedure shown in Figure 12 and the bi-directional successful
procedure are as follows:
* the QNF node that is not able to reserve resources for a
certain request is located in the "forward" path, i.e., path
from QNF ingress towards the QNF egress.
* the QNF node that is not able to support the requested <R> it
must mark the <M> bit, i.e., set to value "1", of the
RESERVE(RMD-QSPEC): "forward"
* the operation for this type of unsuccessful bi-directional
reservation is similar to the operation for unsuccessful uni-
directional reservat
ion shown in Figure 4. The main
difference is that the QNF egress generates an intra-domain
(local) RESPONSE(PDR) message that is sent towards QNF ingress
node.
Bader, et al. [Page 39]
INTERNET-DRAFT RMD-QSP
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
|RESERVE(RMD-QSPEC): | | |
| "forward" | RESERVE(RMD-QSPEC): |
|------------------->M "forward - M marked" |
| M---------------------------------------->|
| RESPONSE(PDR) M | |
| "forward - M marked" | |
|<-------------------------------------------------------------|
|RESERVE(RMD-QSPEC) M | |
|"forward - T tear" M | |
| M | |
|------------------->M | |
Figure 12: Intra-domain signaling operation for unsuccessful
bi-directional reservation (rejection on path QNF(ingress)
towards QNF(egress))
The main differences between the bi-directional unsuccessful
procedure shown in Figure 13 and the in bi-directional successful
procedure are as follows:
* the QNF node that is not able to reserve resources for a
certain request is located in the "reverse" path, i.e., path
from QNF egress towards the QNF ingress.
* the QNF node that is not able to support the requested <R> it
must mark the <M> bit, i.e., set to value "1", the
RESERVE(RMD-QSPEC): "reverse"
* the QNF ingress uses the information contained in the received
"PHR RMD control information" and "PDR RMD control
information" fields of the RESERVE (RMD-QSPEC): "reverse" and
generates a tear intra-domain (local) RESERVE(RMD-QSPEC):
"forward - T tear" message. This message carriers a
"PHR_Release_Request" and a "PDR_Release_Request" control
information fields. This message is sent towards QNF egress
node. The QNF egress node by using the information contained
in the "PHR_Release_Request" and the "PDR_Release_Request"
control information fields it generates a RESERVE(RMD-QSPEC):
"reverse - T tear" message that is sent towards the QNF
ingress node.
Bader, et al. [Page 40]
INTERNET-DRAFT RMD-QSP
QNF (ingress) QNF (interior) QNF (interior) QNF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | RESERVE(RMD-QSPEC): |
|------------------->| "forward" | |
| |---------------------------------------->|
| | RESERVE(RMD-QSPEC) |
| | "reverse" M |
| RESERVE(RMD-QSPEC) M<-------------------|
| "reverse - M marked" M |
|<----------------------------------------M |
| | M |
|RESERVE(RMD-QSPEC): | M |
|"forward - T tear) | M |
|------------------->| RESERVE(RMD-QSPEC) |
| | "forward - T tear" |
| |---------------------------------------->|
| | RESERVE(RMD-QSPEC) |
| | "reverse - T tear" |
| | M<-------------------|
Figure 13: Intra-domain signaling normal operation for unsuccessful
bi-directional reservation (rejection on path QNF(egress)
towards QNF(ingress))
More details on the operation of the bi-directional reservation
operation will be provided in future versions of this draft.
4.6 Handling of errors
During the QSpec processing, errors may occur. The way of how these
errors are handled and notified is specified in [QSP-T].
5. Security Consideration
The RMD QSP aims to be very lightweight signaling with regard to the
number of signaling message roundtrips and the amount of state
established at involved signaling nodes with and without reduced
state on QNEs. This implies the usage of the Datagram Mode which
cannot benefit from security protection. As such, RMD signaling is
target towards intra-domain signaling only. Still it must be
possible to provide some degree of security.
A router implementing a QoS signaling protocol can, similar to a
router without QoS signaling, do a lot of harm to a system. A router
can delay, drop, inject, duplicate or modify packets. A certain
degree of trust is, therefore, always assumed in most systems.
Bader, et al. [Page 41]
INTERNET-DRAFT RMD-QSP
In the context of RMD QSP signaling a classification between in-path
adversaries and off-path adversaries needs to be made. Furthermore,
it might be necessary to differentiate between always off-path nodes
and nodes which are only off-path with regard to a specific
signaling message.
The following paragraph aims to raise a discussion about the
requirements placed on the security properties of the signaling
message exchange:
- It seems to be desirable to prevent nodes, which are never supposed
to participate in the signaling exchange, to interfere with the RMD
QSP signaling nodes.
- It may be desirable to prevent nodes, which are off-path with
respect to a particular inter domain (end-to-end) signaling
session, to inject signaling messages.
- It might be possible to limit the amount of actions performed by
intermediate nodes to an acceptable degree.
6. IANA Considerations
If the document creates a new IANA registry, or reserves new
values for an existing IANA registry, an IANA considerations
section should be included, see RFC 2434.
7. Open issues
This section describes the open issues related to the RMD QoS
signaling model. More details on open issues will be provided in a
future version of this draft.
8. Acknowledgments
The authors express their acknowledgement to people who have worked
on the RMD concept: Z. Turanyi, R. Szabo, A. Csaszar, A. Takacs, G.
Pongracz, O. Pop, V. Rexhepi, D. Partain, M. Jacobsson, S.
Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel.
Bader, et al. [Page 42]
INTERNET-DRAFT RMD-QSP
9. Authors' Addresses
Attila Bader
Traffic Lab
Ericsson Research
Ericsson Hungary Ltd.
Laborc 1
Budapest, Hungary, H-1037
EMail: Attila.Bader@ericsson.com
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm, Sweden
EMail: Lars.Westberg@ericsson.com
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede, The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
Cornelia Kappler
Siem
ens AG
Siemensdamm 62
Berlin 13627, Germany
Email: cornelia.kappler@siemens.com
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich 81739, Germany
EMail: Hannes.Tschofenig@siemens.com
Tom Phelan
Sonus Networks
250 Apollo Dr.
Chelmsford, MA USA 01824
EMail: tphelan@sonusnet.com
10. Normative References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
"Resource ReSerVation Protocol (RSVP)-- Version 1 Functional
Specification", IETF RFC 2205, 1997.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.
and S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001.
Bader, et al. [Page 43]
INTERNET-DRAFT RMD-QSP
[RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
IETF RFC 3175, 2001.
11. Informative References
[GIMPS] Schulzrinne, H., Hancock, R., "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-04
(work in progress), Oct 2004.
[RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in
the Internet Architecture: an Overview", RFC 1633
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated Services", RFC
2475, December 1998
[RFC2638] Nichols K., Jacobson V., Zhang L. "A Two-bit
Differentiated Services Architecture for the Internet", RFC 2638,
July 1999
[RIMA] Westberg, L., Heijenk, G., Karagiannis, G., el Allali, H.,
Oosthoek, S., Partain, D., Rexhepi, V., Szabo, R., Wallentin, P,
"Resource Management in Diffserv Measurement-based Admission Control
PHR", Internet Draft, Work in progress.
[RODA] Westberg, L., Karagiannis, G., de Kogel, M., Partain, D.,
Oosthoek, S., Jacobsson, M., Rexhepi, V., Wallentin, P., "Resource
Management in Diffserv On DemAnd (RODA) PHR", Internet Draft, Work
in progress.
[QoS-NSLP] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 (work
in progress), May 2004.
[QSP-T] Ash, J., Bader, A., Kappler C., "QoS-NSLP QSpec Template"
draft-ash-nsis-nslp-QSpec-00 (work in progress), October 2004.
[RMD1] Westberg, L., et al., "Resource Management in Diffserv
(RMD): A Functionality and Performance Behavior Overview", IFIP
PFHSN'02
[RMD2] G. Karagiannis, et al., "RMD - a lightweight application
of NSIS" Networks 2004, Vienna, Austria.
[RMD3] Karagiannis, G., Rexhepi, V., Westberg, L., Partain, D.,
Oosthoek, S., Jacobsson, M., Szabo, R., Wallentin, P., "Resource
Management in Diffserv Framework", Internet draft, Work in progress.
[RMD4] A. Csaszar et al., "Severe congestion handling with
resource management in diffserv on demand", Networking 2002
Bader, et al. [Page 44]
INTERNET-DRAFT RMD-QSP
12. Intellectual Property Statement
IPR Statement about RMD
I hereby give the following IPR Disclosure in relation to the RMD
concept proposed by Ericsson and currently under discussion in IEFT
WG NSIS:
To the best of my knowledge there are no Ericsson patents or filed
patent applications on RMD protocol operation or basic principles.
To my knowledge there is only one Ericsson patent application family
that could possibly be relevant merely to particular implementation
of RMD. This patent family comprises US patent 6687655 and
counterparts in other countries.
To the best of my knowledge there is only one Ericsson owned
invention without any patent applications filed yet that could
possibly be relevant to particular implementation of RMD, but this
invention is not relevant to RMD protocol operation or basic
principles.
I have been authorized by Ericsson to give the following Licensing
Declaration in relation to the RMD concept proposed by Ericsson and
discussed in IEFT WG NSIS:
In case a license to a patent in the patent family above or a patent
issued/granted on an application for patent on the invention above
should be necessary for implementing any Internet Standard, Ericsson
is willing to grant to anybody a license to such patent on fair,
reasonable and non-discriminatory conditions for the implementation
of the standard, subject to reciprocity.
Attila Bader
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
Bader, et al. [Page 45]
INTERNET-DRAFT RMD-QSP
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Disclaimer of validity:
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
