idnits 2.17.1 

draft-ietf-nsis-rmd-07.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 21.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 3801.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3778.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3785.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3791.

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     *  the SCOPING flag MUST not be set, meaning that a default scoping
     of the message is used.  Therefore, the QNE Edges MUST be configured as
     boundary nodes and the QNE Interior nodes MUST be configured as Interior
     (intermediary) nodes;

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     *  The <RII> object MUST not included in this message;

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     *  The <RII> object MUST not included in this message.  This is
     because the QNE Ingress node does not need to receive a response from the
     QNE Egress node;

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     The Interior node detecting severe congestion remarks data packets
     passing the node. For this remarking, two additional DSCPs can be
     allocated for each traffic class.  One DSCP MAY be used to indicate that
     the packet passed a congested node. This type of DSCP is denoted in this
     document as "affected DSCP" and is used to indicate that a packet passed
     through a severe congested node. The use of this DSCP type eliminates the
     possibility that, due to e.g. ECMP (Equal Cost Multiple Paths) enabled
     routing, the egress node either does not detect packets passed a severe
     congested node or erroneously detects packets that actually did not pass
     the severe congested node.  Note that this type of DSCP MUST only be used
     if all the nodes within the RMD domain are configured to use it.
     Otherwise, this type of DSCP MUST not be applied. The other DSCP MUST be
     used to indicate the degree of congestion by marking the bytes
     proportionally to the degree of congestion. This type of DSCP is denoted
     in this document as "encoded DSCP".

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (June 23, 2006) is 6515 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'QSPEC' is mentioned on line 1386, but not defined

  == Missing Reference: 'RMD-QSPEC' is mentioned on line 790, but not defined

  == Unused Reference: 'RFC2119' is defined on line 3184, but no explicit
     reference was found in the text

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-nsis-qos-nslp (ref. 'QoS-NSLP')

  -- No information found for draft-ietf-nsis-QSpec - is the name correct?

  -- Possible downref: Normative reference to a draft: ref. 'QSP-T' 


     Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	NSIS Working Group                                         Attila Bader
2	INTERNET-DRAFT                                            Lars Westberg
3	                                                               Ericsson
4	Expires: 23 December 2006                          Georgios Karagiannis
5	                                                   University of Twente
6	                                                       Cornelia Kappler
7	                                                                Siemens
8	                                                             Tom Phelan
9	                                                                  Sonus

11	                                                          June 23, 2006

13	       RMD-QOSM - The Resource Management in Diffserv QOS Model
14	                   <draft-ietf-nsis-rmd-07.txt>

16	Status of this Memo

18	   By submitting this Internet-Draft, each author represents that any
19	   applicable patent or other IPR claims of which he or she is aware
20	   have been or will be disclosed, and any of which he or she becomes
21	   aware will be disclosed, in accordance with Section 6 of BCP 79.

23	   Internet-Drafts are working documents of the Internet Engineering
24	   Task Force (IETF), its areas, and its working groups.  Note that
25	   other groups may also distribute working documents as Internet-
26	   Drafts.

28	   Internet-Drafts are draft documents valid for a maximum of six months
29	   and may be updated, replaced, or obsoleted by other documents at any
30	   time.  It is inappropriate to use Internet-Drafts as reference
31	   material or to cite them other than as "work in progress".

33	   The list of current Internet-Drafts can be accessed at
34	   http://www.ietf.org/ietf/1id-abstracts.txt.

36	   The list of Internet-Draft Shadow Directories can be accessed at
37	   http://www.ietf.org/shadow.html.

39	   This Internet-Draft will expire on December 23, 2006.

41	Copyright Notice

43	   Copyright (C) The Internet Society (2006).

45	Abstract

47	   This document describes an NSIS QoS Model for networks that use the
48	   Resource Management in Diffserv (RMD) concept.  RMD is a technique
49	   for adding admission control and preemption function to
50	   Differentiated Services (Diffserv) networks.  The RMD QoS Model
51	   allows devices external to the RMD network to signal reservation
52	   requests to edge nodes in the RMD network. The RMD Ingress edge nodes
53	   classify the incoming flows into traffic classes and signals resource
54	   requests for the corresponding traffic class along the data path to
55	   the Egress edge nodes for each flow.  Egress nodes reconstitute the
56	   original requests and continue forwarding them along the data path
57	   towards the final destination. In addition, RMD defines notification
58	   functions to indicate overload situations within the domain to the
59	   edge nodes.

61	Table of Contents

63	   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
64	   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4
65	   3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .4
66	      3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4
67	      3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 7
68	          3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .7
69	          3.2.2 RMD-QOSM signaling . . . . . . . . . . . . . . . . 8
70	          3.2.3 RMD-QOSM Applicability and considerations. . . . . 9
71	   4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . 10
72	      4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . .11
73	          4.1.1 RMD-QOSM QoS Description . . . . . . . . .  . . . 11
74	          4.1.2 PHR RMD-QOSM control information . . . . . . . . .12
75	          4.1.3 PDR RMD-QOSM control information  . . . . . . . . 14
76	      4.2 Message format . . . . . . . . . . . . . . . . . . . . .15
77	      4.3 RMD node state management . . . . . . . . . . . . . . . 16
78	          4.3.1 Aggregated versus per flow reservations at the
79	                QNE edges . . . . . . . . . . . . . . . . . . . . 17
80	          4.3.2 Measurement-based method . . . . . . . . . . . . .17
81	          4.3.3 Reservation-based method . .. . . . . . . . . . . 18
82	      4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .19
83	      4.5 Edge discovery and addressing of messages . . . . . . . 20
84	      4.6 Operation and sequence of events . . . . . . . . . . . .20
85	          4.6.1 Basic unidirectional operation . . . . . . . . . .20
86	             4.6.1.1 Successful reservation. . . . . . . . . . . .21
87	             4.6.1.2 Unsuccessful reservation . . . . . . . . . . 29
88	             4.6.1.3 RMD refresh reservation. . . . . . . . . . . 31
89	             4.6.1.4 RMD modification of aggregated reservation . 35
90	             4.6.1.5 RMD release procedure. . . . . . . . . . . . 36
91	             4.6.1.6 Severe congestion handling  . . . . . . . . .44
92	             4.6.1.7 Admission control using congestion
93	                     notification based on probing . . . . . .  . 49
94	          4.6.2 Bidirectional operation . . . . . . . . . . . . . 51
95	             4.6.2.1 Successful and unsuccessful reservation . . .53
96	             4.6.2.2 Refresh reservation . . . . . . . . . . . . .58
97	             4.6.2.3 Modification of aggregated reservation . . . 58
98	             4.6.2.4 Release procedure . . . . . . . . . . . . . .59
99	             4.6.2.5 Severe congestion handling . . . . . . . . . 60
100	             4.6.2.6 Admission control using congestion
101	                     notification based on probing . . . . . . . .63
102	      4.7 Handling of additional errors . . . . . . . . . . . . . 64
103	   5. Security Consideration. . . . . . . . . . . . . . . . . . . 65
104	   6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .68
105	   7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .68
106	   8. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 68
107	   9. Normative References . . . . . . . . . . . . . . . . . . . .69
108	   10. Informative References . . . . . . . . . . . . . . . . . . 69

110	1.  Introduction

112	   This document describes a Next Steps In Signaling (NSIS) QoS model
113	   for networks that use the Resource Management in Diffserv (RMD)
114	   framework ([RMD1], [RMD2], [RMD3], [RMD4]). RMD adds admission
115	   control to Diffserv networks and allows nodes external to the
116	   networks to dynamically reserve resources within the Diffserv
117	   domains.

119	   The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP)
120	   [QoS-NSLP] specifies a generic model for carrying Quality of Service
121	   (QoS) signaling information end-to-end in an IP network.  Each
122	   network along the end-to-end path is expected to implement a
123	   specific QoS Model (QOSM) that interprets the requests and installs
124	   the necessary mechanisms, in a manner that is appropriate to the
125	   technology in use in the network, to ensure the delivery of the
126	   requested QoS.

128	   This document specifies an NSIS QoS Model for RMD networks (RMD-
129	   QOSM), and an RMD-specific QSpec (RMD-QSPec) for expressing
130	   reservations in a suitable form for simple processing by internal
131	   nodes.  They are used in combination with the QoS-NSLP to provide
132	   QoS signaling service in an RMD network.  Figure 1 shows an RMD
133	   network with the respective entities.

135	                          Stateless or reduced state        Egress
136	   Ingress                RMD nodes                         Node
137	   Node                   (Interior Nodes; I-Nodes)        (Stateful
138	   (Stateful              |          |            |         RMD QoS
139	   RMD QoS NLSP           |          |            |         NSLP Node)
140	   Node)                  V          V            V
141	   +-------+   Data +------+      +------+       +------+     +------+
142	   |-------|--------|------|------|------|-------|------|---->|------|
143	   |       |   Flow |      |      |      |       |      |     |      |
144	   |Ingress|        |I-Node|      |I-Node|       |I-Node|     |Egress|
145	   |       |        |      |      |      |       |      |     |      |
146	   +-------+        +------+      +------+       +------+     +------+
147	            =================================================>
148	            <=================================================
149	                                  Signaling Flow

151	   FIGURE 1: Actors in the RMD-QOSM

153	   Internally to the RMD network, RMD-QOSM defines a scalable QoS
154	   signaling model in which per-flow QoS-NSLP and NTLP states are not
155	   stored in Interior nodes but per-flow signaling is performed (see
156	   [QoS-NSLP]).

158	   In the RMD-QOSM, only routers at the edges of a Diffserv domain
159	   (Ingress and Egress nodes) support the QoS-NSLP stateful operation.
160	   Interior nodes support either the QoS-NSLP stateless operation, or a
161	   reduced-state operation with coarser granularity than the edge nodes.

163	   The remainder of this draft is structured following the suggestions
164	   in Appendix B of [QSP-T] for the description of QoS Signaling
165	   Policies.

167	   After the terminology in Section 2, we give an overview of RMD and
168	   the RMD-QOSM in Section 3.  In Section 4 we give a detailed
169	   description of the RMD-QOSM, including the role of QNEs, the
170	   definition of the QSpec, mapping of QSpec generic parameters onto
171	   RMD-QOSM parameters, state management in QNEs, and operation and
172	   sequence of events.  Section 5 discusses security issues.

174	2.  Terminology

176	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
177	   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
178	   in this document are to be interpreted as described in RFC 2119.

180	   The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP]
181	   applies to this draft.

183	   In addition, the following terms are used:

185	   Edge node: an (NSIS-capable) node on the boundary of some
186	   administrative domain.

188	   Ingress node: An edge node that handles the traffic as it enters the
189	   domain.

191	   Egress node: An edge node that handles the traffic as it leaves the
192	   domain.

194	   Interior nodes: the set of (NSIS-capable) nodes which form an
195	   administrative domain, excluding the edge nodes.

197	3.  Overview of RMD and RMD-QOSM

199	3.1.  RMD

201	   The Differentiated Services (Diffserv) architecture ([RFC2475],
202	   [RFC2638]) was introduced as a result of efforts to avoid the
203	   scalability and complexity problems of Intserv [RFC1633].
204	   Scalability is achieved by offering services on an aggregate
205	   rather than per-flow basis and by forcing as much of the per-flow
206	   state as possible to the edges of the network.  The service
207	   differentiation is achieved using the Differentiated Services (DS)
208	   field in the IP header and the Per-Hop Behavior (PHB) as the main
209	   building blocks.  Packets are handled at each node according to the
210	   PHB indicated by the DS field in the message header.

212	   The Diffserv architecture does not specify any means for devices
213	   outside the domain to dynamically reserve resources or receive
214	   indications of network resource availability.  In practice, service
215	   providers rely on subscription-time Service Level Agreements (SLAs)
216	   that statically define the parameters of the traffic that will be
217	   accepted from a customer.

219	   RMD was introduced as a method for dynamic reservation of resources
220	   within a Diffserv domain.  It describes a method that is able to
221	   provide admission control for flows entering the domain and a
222	   congestion handling algorithm that is able to terminate flows in
223	   case of congestion due to a sudden failure (e.g., link, router)
224	   within the domain.

226	   In RMD, scalability is achieved by separating a fine-grained
227	   reservation mechanism used in the edge nodes of a Diffserv domain
228	   from a much simpler reservation mechanism needed in the Interior
229	   nodes.  In particular, it is assumed that edge nodes support per-
230	   flow QoS states in order to provide QoS guarantees for each flow.
231	   Interior nodes use only one aggregated reservation state per traffic
232	   class or no states at all.  In this way it is possible to handle
233	   large numbers of flows in the Interior nodes. Furthermore, due to
234	   the limited functionality supported by the Interior nodes, this
235	   solution allows fast processing of signaling messages.

237	   In RMD two basic admission control modes are described:
238	   reservation-based and measurement-based admission control.

240	   In the reservation-based method, each Interior node maintains
241	   only one reservation state per traffic class.  The Ingress edge
242	   nodes aggregate individual flow requests into classes, and signal
243	   changes in the class reservations as necessary.  The reservation is
244	   quantified in terms of resource units.  These resources are
245	   requested dynamically per PHB and reserved on demand in all nodes in
246	   the communication path from an Ingress node to an Egress node.

248	   The measurement-based algorithm continuously measures traffic levels
249	   and the actual available resources, and admits flows whose resource
250	   needs are within what is available at the time of the request. Once
251	   an admission decision is made, no record of the decision need be
252	   kept.  The advantage of measurement-based resource management
253	   protocols is that they do not require pre-reservation state nor
254	   explicit release of the reservations.  Moreover, when the user
255	   traffic is variable, measurement based admission control could
256	   provide higher network utilization than, e.g., peak-rate
257	   reservation.  However, this can introduce an uncertainty in the
258	   availability of the resources.

260	   Two types of measurement based admission control schemes are
261	   possible:

263	   * Congestion notification function based on probing:

265	   This method can be used to implement a simple measurement-based
266	   admission control within a Diffserv domain. In this scenario the
267	   interior nodes are not NSIS aware nodes. In these interior nodes
268	   thresholds are set for the traffic belonging to different PHBs in
269	   the measurement based admission control function. In this scenario
270	   an end-to-end NSIS message are used as a probe packet, meaning that
271	   the DSCP field in the header of the IP packet that carries the NSIS
272	   message is re-marked when the predefined congestion threshold is
273	   exceeded. In this way the edges can admit or reject flows that are
274	   requesting resources. Note that in this situation, in addition to the
275	   probe packet, also ordinary data packets passing though the congested
276	   node are re-marked.The rate of the re-marked data packets is used to
277	   detect a congestion situation that can influence the admission
278	   control decissions.

280	   * NSIS measurement-based admission control:

282	   In this case the measurement-based admission control functionality is
283	   implemented in NSIS aware stateless routers. The main difference
284	   between this type of admission control and the congestion
285	   notification based on probing is related to the fact that this type
286	   of admission control is applied mainly on NSIS aware nodes, giving
287	   the possibility to apply measuring techniques, see e.g., [JaSh97],
288	   [GrTs03], that are using current and past information on NSIS
289	   sessions that requested resources from an NSIS aware interior node.
290	   The admission decision is positive if the currently carried traffic,
291	   as characterized by the measured statistics, plus the requested
292	   resources for the new flow exceeds the system capacity with a
293	   probability smaller than some alpha. Otherwise, the admission
294	   decision is negative.

296	   RMD describes the following procedures:

298	   * Classification of an individual resource reservation or a resource
299	     query into Per Hop Behavior (PHB) groups at the Ingress node of
300	     the domain,

302	   * Hop-by-hop admission control based on a PHB within the
303	     domain. There are two possible modes of operation for internal
304	     nodes to admit requests. One mode is the stateless or
305	     measurement-based mode, where the resources within the domain are
306	     queried. Another mode of operation is the reduced-state
307	     reservation or reservation based mode, where the resources within
308	     the domain are reserved.

310	   * a method to forward the original requests across the domain up to
311	     the Egress node and beyond.

313	   * a congestion control algorithm that notifies the egress edge nodes
314	     about congestion. It is able to terminate the appropriate number
315	     of flows in case a of congestion due to a sudden failure (e.g.,
316	     link or router failure) within the domain.

318	3.2. Basic features of RMD-QOSM

320	3.2.1 Role of the QNEs

322	   The protocol model of the RMD-QOSM is shown in Figure 2.  The figure
323	   shows QNI and QNR nodes, not part of the RMD network, that are the
324	   ultimate initiator and receiver of the QoS reservation requests.  It
325	   also shows QNE nodes that are the Ingress and Egress nodes in the
326	   RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are
327	   Interior nodes (QNE Interior).

329	   All nodes of the RMD domain are mainly QoS-NSLP aware nodes.  Edge
330	   nodes store and maintain QoS-NSLP and NTLP states and therefore are
331	   stateful nodes.  The NSIS aware Interior nodes are NTLP stateless.
332	   Furthermore they are either QoS-NSLP stateless (for NSIS measurement-
333	   based operation), or are reduced state nodes storing per PHB
334	   aggregated QoS-NSLP states (for reservation-based operation).

336	     |------|   |-------|                           |------|   |------|
337	     | e2e  |<->| e2e   |<------------------------->| e2e  |<->| e2e  |
338	     | QoS  |   | QoS   |                           | QoS  |   | QoS  |
339	     |      |   |-------|                           |------|   |------|
340	     |      |   |-------|   |-------|   |-------|   |------|   |      |
341	     |      |   | local |<->| local |<->| local |<->| local|   |      |
342	     |      |   | QoS   |   |  QoS  |   |  QoS  |   |  QoS |   |      |
343	     |      |   |       |   |       |   |       |   |      |   |      |
344	     | NSLP |   | NSLP  |   | NSLP  |   | NSLP  |   | NSLP |   | NSLP |
345	     |st.ful|   |st.ful |   |st.less/   |st.less/   |st.ful|   |st.ful|
346	     |      |   |       |   |red.st.|   |red.st.|   |      |   |      |
347	     |      |   |-------|   |-------|   |-------|   |------|   |      |
348	     |------|   |-------|   |-------|   |-------|   |------|   |------|
349	     ------------------------------------------------------------------
350	     |------|   |-------|   |-------|   |-------|   |------|   |------|
351	     | NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP |<->|NTLP  |
352	     |st.ful|   |st.ful |   |st.less|   |st.less|   |st.ful|   |st.ful|
353	     |------|   |-------|   |-------|   |-------|   |------|   |------|
354	       QNI         QNE        QNE         QNE          QNE       QNR
355	     (End)     (Ingress)   (Interior)  (Interior)   (Egress)    (End)

357	         st.ful: stateful, st.less: stateless
358	         st.less red.st.: stateless or reduced state

360	   Figure 2: Protocol model of stateless/reduced state operation
361	   Note that the RMD domain may contain Interior nodes that are
362	   not NSIS aware nodes (not shown in the figure).  These nodes are
363	   assumed to have sufficient capacity for flows that might be
364	   admitted.  Furthermore, some of these NSIS unaware nodes may be used
365	   for measuring the traffic congestion level on the data path. These
366	   measurements can be used by RMD-QOSM in the congestion control based
367	    on probing operation and/or severe congestion operation
368	   (see Section 4.6.1.6).

370	3.2.2 RMD-QOSM Signaling

372	   The basic RMD-QOSM signaling is shown in Figure 3.  A RESERVE
373	   message is created by a QNI with an Initiator QSpec describing the
374	   reservation and forwarded along the path towards the QNR.  When the
375	   original RESERVE message arrives at the Ingress node, an RMD-QSpec
376	   is constructed based on the top-most QSPEC in the message (usually
377	   the Initiator QSPEC).  The RMD-QSpec is sent in a local, independent
378	   RESERVE message through the Interior nodes towards the QNR. This
379	   local RESERVE message uses the NTLP hop-by-hop datagram signaling
380	   mechanism.  Meanwhile, the original RESERVE message is sent to the
381	   Egress node on the path to the QNR using the reliable transport mode
382	   of NTLP.

384	              QNE             QNE             QNE            QNE
385	            Ingress         Interior        Interior        Egress
386	        NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
387	               |               |               |              |
388	       RESERVE |               |               |              |
389	      -------->| RESERVE       |               |              |
390	               +--------------------------------------------->|
391	               | RESERVE'      |               |              |
392	               +-------------->|               |              |
393	               |               | RESERVE'      |              |
394	               |               +-------------->|              |
395	               |               |               | RESERVE'     |
396	               |               |               +------------->|
397	               |               |               |              | RESERVE
398	               |               |               |              +------->
399	               |               |               |              |RESPONSE
400	               |               |               |              |<-------
401	               |               |               |     RESPONSE |
402	               |<---------------------------------------------+
403	       RESPONSE|               |               |              |
404	      <--------|               |               |              |

406	   Figure 3: Sender-initiated reservation with Reduced State Interior
407	             Nodes

409	   Each QoS-NSLP node on the data path processes the local RESERVE
410	   message and checks the availability of resources with either the
411	   reservation-based or the measurement-based method.  When the message
412	   reaches the Egress node, and the reservation is successful in each
413	   Interior nodes, the original RESERVE message is forwarded to the
414	   next domain.  When the Egress node receives a RESPONSE message from
415	   the downstream end, it is forwarded directly to the Ingress node.

417	   If an intermediate node cannot accommodate the new request, it
418	   indicates this by marking a single bit in the message, and continues
419	   forwarding the message until the Egress node is reached. From the
420	   Egress node a RESPONSE message is sent directly the Ingress node.

422	   As a consequence in the stateless/reduced state domain only sender-
423	   initiated reservation can be performed and functions requiring per
424	   flow NTLP or QoS-NSLP states, like summary refreshes, cannot be
425	   used. If per flow
426	   identification, is needed, i.e., associating the flow IDs for the
427	   reserved resources, Edge nodes act on behalf of Interior nodes.

429	3.2.3 RMD-QOSM Applicability and considerations

431	   The RMD-QOSM is a Diffserv-based bandwidth management methodology
432	   that is not able to provide a full Diffserv support. The reason of
433	   this is that the RMD-QOSM concept can only support the (Expedited
434	   Forwarding) EF-like functionality behavior, where the use bandwidth
435	   as a signaled <QoS Desired> parameter is required. The RMD-QOSM is
436	   not able to support the full set of (Assured Forwarding) AF-like
437	   functionality where multiple PHBs/DSCPs are used. This is because
438	   the signaled <QoS Desired> parameter should contain two token
439	   buckets needed to signal AF in full generality. Note however, that
440	   RMD-QOSM could also support a single AF PHB, as far as the traffic
441	   or the upper limit of the traffic can be characterized by a single
442	   bandwidth parameter.

444	   A very important consideration on using RMD-QOSM is that within one
445	   RMD domain only one of the following RMD-QOSM schemes can be used at
446	   a time. Thus a RMD router can never process and use two different
447	   RMD-QOSM signaling schemes at the same time.

449	   The available RMD-QOSM signaling schemes are:

451	   * per flow congestion notification based on probing (see
452	     Sections 4.3.2, 4.6.1.7, 4.6.2.6). Note that this scheme uses for
453	     severe congestion handling the Severe congestion handling by
454	     proportional data packet marking, see Section 4.6.1.6.2, 4.6.2.5.2)

456	   * per flow RMD NSIS measurement based admission control (see
457	     Sections 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses for
458	     severe congestion handling the Severe congestion handling by
459	     proportional data packet marking, see Section 4.6.1.6.2, 4.6.2.5.2)

461	   * per aggregate RMD NSIS measurement based admission control (see
462	     Sections 4.3.1, 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses
463	     for severe congestion handling the Severe congestion handling by
464	     proportional data packet marking, see Section 4.6.1.6.2, 4.6.2.5.2)

466	   * per flow RMD reservation based in combination with severe
467	     congestion handling by the RMD-QOSM refresh procedure (see Sections
468	     4.3.1, 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this scheme
469	     uses for severe congestion handling the Severe congestion handling
470	     by the RMD-QOSM refresh procedure, see Section 4.6.1.6.1,
471	     4.6.2.5.1)

473	   * per flow RMD reservation based in combination with severe
474	     congestion handling by proportional data packet marking procedure
475	     (see Sections 4.3.1, 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that
476	     this scheme uses for severe congestion handling the Severe
477	     congestion handling by proportional data packet marking procedure,
478	     see Section 4.6.1.6.2, 4.6.2.5.2)

480	   * per aggregate RMD reservation based in combination with
481	     severe congestion handling by the RMD-QOSM refresh procedure (see
482	     Sections 4.3.1, 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this
483	     scheme uses for severe congestion handling the Severe congestion
484	     handling by the RMD-QOSM refresh procedure, see Section 4.6.1.6.1,
485	     4.6.2.5.1)

487	   * per aggregate RMD reservation based in combination with
488	     severe congestion handling by proportional data packet marking
489	     procedure (see Sections 4.3.1, 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2).
490	     Note that this scheme uses for severe congestion handling the
491	     Severe congestion handling by proportional data packet marking
492	     procedure, see Section 4.6.1.6.2, 4.6.2.5.2)

494	4.  RMD-QOSM, Detailed Description

496	   This section describes the RMD-QOSM in more detail.  In particular,
497	   it defines the role of stateless and reduced-state QNEs, the
498	   RMD-QOSM QSpec Object, the format of the RMD-QOSM QoS-NSLP messages
499	   and how QSpecs are processed and used in different protocol
500	   operations.

502	4.1.  RMD-QSpec Definition

504	   The QSPEC format is specified in [QSP-T] and is as follows:

506	   QSPEC = <QSPEC Version> <QOSM ID> <QSPEC Control Information>
507	   <QoS Description>

509	   The <QSPEC Version> and <QoSM ID> used by the RMD-QOSM are
510	   assigned by IANA, see Section 6. The <QSPEC Control Information>
511	   contains the following fields:

513	   <QSPEC Control Information> = <PHR container> <PDR container>

515	   The Per Hop Reservation container (PHR container) and
516	   the Per Domain Reservation container (PDR container) are specified
517	   in Section 4.1.2 and 4.1.3, respectively. The <PHR container>
518	   contains the QoS specific control information for intra-domain
519	   communication and reservation.  The <PDR container> contains
520	   additional control information that is needed for edge-to-edge
521	   communication.

523	   The <QoS Description> contains the <RMD-QOSM QoS description field>
524	   that is specified in Section 4.1.1. The <RMD-QOSM QoS Description>
525	   field, the <PHR container> are used and processed by the Edge and
526	   Interior nodes.  The <PDR container> field is only processed by Edge
527	   nodes.

529	4.1.1.  RMD-QOSM QoS Description

531	   The RMD-QOSM QoS Description carried by the RESERVE message only
532	   contains the QoS Desired object [QSP-T]. The QoS Reserved object is
533	   carried by the RESPONSE message.

535	   <RMD-QOSM QoS Description> = <QoS Desired> for RESERVE

537	   <RMD-QOSM QoS Description> = <QoS Reserved> for RESPONSE

539	   <QoS Desired> = <Bandwidth> <PHB Class> <Admission Priority>

541	   <QoS Reserved> = <Bandwidth> <PHB Class> <Admission Priority>
542	   The bit format of the <Bandwidth> (see Figure 4), <PHB Class> (see
543	   Figure 5) and <Admission Priority> complies to the bit format
544	   specified in [QSP-T]. Note that for the RMD-QOSM a reservation
545	   established without an <Admission Priority> parameter is equivalent
546	   to a reservation established with an <Admission Priority> whose
547	   value is 1.

549	     0                   1                   2                   3
550	     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
551	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
552	    |1|E|0|T|           2           |r|r|r|r|          1            ||
553	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
554	    |  Bandwidth       (32-bit IEEE floating point number)          |
555	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

557	             Figure 4: Bandwidth parameter

559	    0                   1                   2                   3
560	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
561	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
562	   |1|E|0|T|           6           |r|r|r|r|          1            |
563	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
564	   | DSCP      |0 0 0 0 0 0 0 0 0 0|            Reserved           |
565	   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

567	            Figure 5: PHB_Class parameter

569	4.1.2.  PHR Container

571	   This section describes the parameters used by the PHR container.

573	   <PHR container> = <Overload %>, <S>,<M>,
574	   <Admitted Hops>, <B>, <Hop_U> <Time Lag>

576	   The bit format of the PHR container can be seen in Figure 6. Note
577	   that in Figure 6 <Hop U> is represented as <U>.

579	     0                   1                   2                   3
580	     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
581	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
582	    |0|E|N|T|       Container ID    |r|r|r|r|          1            |
583	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
584	    |S|M| Admitted  Hops|B|U| Time  Lag     |  Overload %   |       |
585	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

587	        Figure 6: PHR container

589	   Parameter/Container ID:
590	   8 bit field, indicating the PHR type: PHR_Resource_Request,
591	   PHR_Release_Request, PHR_Refresh_Update.  It is used to further
592	   specify QoS-NSLP RESERVE and RESPONSE messages.

594	   "PHR_Resource_Request" (Container ID = 1): initiate or
595	   update the traffic class reservation state on all nodes located on
596	   the communication path between the QNE(Ingress) and QNE(Egress)
597	   nodes.

599	   "PHR_Refresh_Update" (Container ID = 2): refresh the
600	   traffic class reservation soft state on all nodes located on the
601	   communication path between the QNE(Ingress) and QNE(Egress)
602	   nodes according to a resource reservation request that was
603	   successfully processed during a previous refresh period.

605	   "PHR_Release_Request" (Container ID = 3): explicitly release, by
606	   subtraction, the reserved resources for a particular flow
607	   from a traffic class reservation state.

609	   <S> (Severe Congestion):
610	   1 bit.  In case of a route change refreshing RESERVE messages
611	   follow the new data path, and hence resources are requested
612	   there.  If the resources are not sufficient to accommodate the new
613	   traffic sever congestion occurs.  Congested Interior nodes SHOULD
614	   notify Edge QNEs about the congestion by setting the
615	   S bit.

617	   <Overload %>:
618	   8 bits In case of severe congestion the level of overload is
619	   indicated by the Overload %.  Overload % SHOULD be higher than 0 if
620	   S bit is set.  If overload in a node is greater than the overload
621	   in a previous node then Overload % SHOULD be updated.

623	   <M>:
624	   1 bit.  In case of unsuccessful resource reservation or resource
625	   query in an Interior QNE, this QNE sets the M bit in order to
626	   notify the Egress QNE.

628	   <Admitted Hops>:
629	   8 bit field.  The <Admitted Hops> counts the number of hops in the
630	   RMD domain where the reservation was successful.  The <Admitted
631	   Hops> is set to "0" when a RESERVE message enters a domain and it is
632	   increased by one at each Interior QNE.  However when a QNE that does
633	   not have sufficient resources to admit the reservation is reached,
634	   the M Bit is set, and the <Admitted Hops> value is frozen.

636	   <Hop_U> (NSLP_Hops unset):
637	   1-bit. The QNE(Ingress) node MUST set the <Hop_U> parameter to
638	   0.  This parameter SHOULD be set to "1" by a node when the node does
639	   not increase the <Admitted Hops> value. This is the case when an
640	   RMD-QOSM reservation-based node is not admitting the reservation
641	   request. When <Hop_U> is set "1" the <Admitted Hops> SHOULD NOT be
642	   changed.

644	   <B>: 1 bit.  Indicates bi-directional reservation.

646	   <Time Lag>: 8 bit field.  The time lag used in a sliding window
647	   over the refresh period.

649	4.1.3.  PDR container

651	   This section describes the parameters of the PDR container.

653	   The bit format of the PDR container can be seen in Figure 7.

655	   <PDR container> = <Overload %>  <S> <M> <Max
656	   Admitted Hops> <B> [<PDR Reverse Requested Resources>]

658	   Note that in Figure 7 <Max Admitted Hops> is represented as
659	   <Max Adm Hops>.

661	       0                   1                   2                   3
662	       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
663	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
664	      |0|E|N|T|   Container ID        |r|r|r|r|          2            |
665	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
666	      |S|M| Max Adm  Hops |B|  Overload %   |       Empty       |     |
667	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
668	      |PDR Reverse Requested Resources(32-bit IEEE floating p.number) |
669	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

671	        Figure 7: PDR container

673	   Parameter/Container ID:

675	   8-bit field identifying the type of PDR container field.

677	   "PDR_Reservation_Request" (Parameter/Container ID = 4): generated by
678	   the QNE(Ingress) node in order to initiate or update the QoS-NSLP
679	   per domain reservation state in the QNE(Egress) node

681	   "PDR_Refresh_Request" (Parameter/Container ID = 5): generated by the
682	   QNE(Ingress) node and sent to the QNE(Egress) node to refresh,
683	   in case needed, the QoS-NSLP per domain reservation states
684	   located in the QNE(Egress) node

686	   "PDR_Release_Request" (Parameter/Container ID = 6): generated and
687	   sent by the QNE(Ingress) node to the QNE(Egress) node to release
688	   the per domain reservation states explicitly

690	   "PDR_Reservation_Report" (Parameter/Container ID = 7): generated and
691	   sent by the QNE(Egress) node to the QNE(Ingress) node to
692	   report that a "PHR_Resource_Request" and a
693	   "PDR_Reservation_Request" control information fields have been
694	   received and that the request has been admitted or rejected

696	   "PDR_Refresh_Report" (Parameter/Container ID = 8) generated and sent
697	   by the QNE(Egress) node in case needed, to the QNE(Ingress) node
698	   to report that a "PHR_Refresh_Update" control information
699	   field has been received and has been processed
700	   "PDR_Release_Report" (Parameter/Container ID = 9) generated and sent
701	   by the QNE(Egress) node in case needed, to the QNE(Ingress) node
702	   to report that a "PHR_Release_Request" and a
703	   "PDR_Release_Request" control information fields have been
704	   received and have been processed.

706	   "PDR_Congestion_Report" (Parameter/Container ID = 10): generated and
707	   sent by the QNE(Egress) node to the QNE(Ingress) node and used for
708	   congestion notification

710	   <S> (PDR Severe Congestion):
711	   1-bit.  Specifies if a severe congestion situation occurred.
712	   It can also carry the <S> parameter of the
713	   "PHR_Resource_Request" or "PHR_Refresh_Update" fields.

715	   <Overload %>:
716	   8-bit.  It includes the Overload % of the
717	   "PHR_Resource_Request" or "PHR_Refresh_Update" control
718	   information fields, indicating the level of overload to the Ingress
719	   node.

721	   <M> (PDR Marked):
722	   1-bit.  Carries the <M> value of the "PHR_Resource_Request" or
723	   "PHR_Refresh_Update" control information fields.

725	   <B>: 1 bit Indicates bi-directional reservation.

727	   <Max Admitted Hops>:
728	   8-bit.  The <Admitted Hops> value that has been carried by the
729	   PHR container field used to identify the RMD reservation based node
730	   that admitted or process a "PHR_Resource_Request"

732	   <PDR Reverse Requested Resources>:
733	   32 bits.  This field only applies when the "B" flag is set to
734	   "1".  It specifies the requested number of units of resources
735	   that have to be reserved by a node in the reverse direction
736	   when the intra-domain signaling procedures require a bi-
737	   directional reservation procedure.

739	4.2.  Message Format

741	   The format of the messages used by the RMD-QOSM complies with the
742	   QoS-NSLP specification.  As specified in [QoS-NSLP], for each
743	   QoS-NSLP message type, there is a set of rules for the permissible
744	   choice of object types.  These rules are specified using Backus-Naur
745	   Form (BNF) augmented with square brackets surrounding optional
746	   sub-sequences.  The BNF implies an order for the objects in a
747	   message.  However, in many (but not all) cases, object order makes no
748	   logical difference.  An implementation SHOULD create messages with
749	   the objects in the order shown here, but accept the objects in any
750	   permissible order.

752	   The format of a local (intra-domain) RESERVE message used by the
753	   RMD-QOSM is:

755	   RESERVE = COMMON_HEADER
756	           RSN [ RII ] [ REFRESH_PERIOD ]
757	           [ *BOUND_SESSION_ID ]
758	           [[ PACKET_CLASSIFIER ] [ RMD-QSPEC ]]

760	   The format of an intra-domain Query message that may be used by the
761	   RMD-QOSM is as follows:

763	   QUERY = COMMON_HEADER
764	       [ RII ] [ *BOUND_SESSION_ID ]
765	       [ PACKET_CLASSIFIER ] RMD-QSPEC

767	   A QUERY message MUST contain an RII object to indicate a RESPONSE is
768	   desired, unless the QUERY is being used to initiate reverse-path
769	   state for a receiver-initiated reservation.

771	   The format of a local (intra-domain) RESPONSE message used by
772	   the RMD-QOSM is as follows:

774	   intra-domain RESPONSE = COMMON_HEADER
775	                 [ RII / RSN ] INFO_SPEC [ RMD-QSPEC ]

777	   The format of an end-to-end RESPONSE message that is used by the
778	   RMD-QOSM to carry an intra-domain RMD-QSPEC object is as follows:

780	   RESPONSE = COMMON_HEADER [RII/RSN] INFO_SPEC [QSPEC] [RMD-QSPEC]

782	   The format of an intra-domain NOTIFY message used by the RMD-QOSM is
783	   as follows:

785	   NOTIFY = COMMON_HEADER INFO_SPEC [ RMD-QSPEC ]

787	   The format of an end-to-end NOTIFY message that is used by the
788	   RMD-QOSM to carry an intra-domain RMD-QSPEC object is as follows:

790	   NOTIFY = COMMON_HEADER INFO_SPEC [QSPEC] [RMD-QSPEC]

792	   All objects, except RMD-QSPEC objects, are specified in [QoS-NSLP].

794	4.3.  RMD node state management

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

801	4.3.1 Aggregated versus per flow reservations at the QNE Edges

803	   The QNE Edges maintain for the RMD QoS model either per flow, or
804	   aggregated QoS-NSLP reservation states.  Each per flow or aggregated
805	   QoS-NSLP reservation state, associated with the RMD-QOS model, is
806	   identified by a NTLP SESSION_ID (see [GIST]).  In RMD, these states
807	   are denoted as PDR states.

809	   When the QNE Edges use aggregated QoS-NSLP reservation states the
810	   SESSION_ID of the aggregated state, the IP addresses of the Ingress
811	   and Egress nodes, the PHB value and the size of the aggregated
812	   reservation, e.g., reserved bandwidth have to be maintained.

814	   The size of the aggregation is specified in Section 1.4.4 of
815	   [RFC3175].  The size of the aggregated reservations needs to be
816	   greater or equal to the sum of bandwidth of the inter domain
817	   (end-to-end) reservations it aggregates.  A policy can be used
818	   to maintain the amount of required bandwidth on a given aggregated
819	   reservation by taking into account the sum of the underlying inter
820	   domain (end-to-end) reservations, while endeavoring to change
821	   reservation less frequently.  This MAY require a trend analysis.
822	   If there is a significant probability that in the next interval of
823	   time the current aggregated reservation is exhausted, the Ingress
824	   router MUST predict the necessary bandwidth and request it.  If the
825	   Ingress router has a significant amount of bandwidth reserved but
826	   has very little probability of using it, the policy MAY predict the
827	   amount of bandwidth required and release the excess.  To increase or
828	   decrease the aggregate, the RMD modification procedures SHOULD be
829	   used (see Section 4.6.1.4).

831	4.3.2  Measurement-based method

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

835	   * Congestion notification based on probing:

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

850	   In this scenario end-to-end NSIS message is used as a probe packet.
851	   In this case the DSCP field of the GIST message is re-marked when the
852	   predefined congestion notification threshold is exceeded in an
853	   interior node. Note that in this situation, in addition to the probe
854	   packet, also ordinary data packets passing though the congested node
855	   are re-marked. The rate of the re-marked data packets is used to
856	   detect a congestion situation that can influence the admission
857	   control decissions.

859	   * NSIS measurement-based admission control:

861	   The measurement based admission control is implemented in NSIS aware
862	   stateless routers. In particular, the QNE Interior nodes operating in
863	   NSIS measurement-based mode are QoS-NSLP stateless nodes, i.e., they
864	   do not support any QoS-NSLP or NTLP/GIST states.  These measurement-
865	   based nodes store two RMD-QOSM states per PHR group.  These states
866	   reflect the traffic conditions at the node and are not affected by
867	   QoS-NSLP signaling. One state stores the measured user traffic load
868	   associated with the PHR group and another state stores the maximum
869	   traffic load threshold that can be admitted per PHR group. When a
870	   measurement-based node receives a local RESERVE message, it compares
871	   the requested resources to the available resources (maximum allowed
872	   minus current load) for the requested PHR group.  If there are
873	   insufficient resources, it sets the <M> bit in the RMD-QSpec.  No
874	   change to the RMD-QSpec is made when there are sufficient resources.

876	4.3.3  Reservation-based method

878	   QNE Interior nodes operating in reservation-based mode are QoS-NSLP
879	   reduced state nodes, i.e., they do not store NTLP/GIST states but
880	   they do store per PHB-aggregated QoS-NSLP states.

882	   The reservation-based PHR installs and maintains one reservation
883	   state per PHB, in all the nodes located in the communication path
884	   from the QNE Ingress node up to the QNE Egress node.  This state
885	   represents the number of currently reserved resource units.  Thus,
886	   the QNE Ingress node signals only the resource units requested by
887	   each flow.  These resource units, if admitted, are added to the
888	   currently reserved resources per PHB.

890	   For each PHB a threshold is maintained that specifies the maximum
891	   number of resource units that can be reserved. This threshold
892	   could, for example, be statically configured. An example of how the
893	   admission control and its maintenance process occurs in the interior
894	   nodes is described in Section 3 of [CsTa05]. The simplified concept
895	   that is used by the per traffic class admission control process, is
896	   based on the following equation:

898	        last + p <= T,

900	   where p: requested bandwidth rate, T: admission threshold, which
901	   reflects the maximum traffic volume that can be admitted in the
902	   traffic class, last: a counter that records the aggregated sum of
903	   the signaled bandwidth rates of previous admitted flows.

905	   The per-PHB group reservation states are soft states, which are
906	   refreshed by sending periodic refresh local RESERVE messages. If a
907	   refresh message corresponding to a number of reserved resource units
908	   is not received, the aggregated reservation state is decreased in
909	   the next refresh period by the corresponding amount of resources
910	   that were not refreshed. The refresh period can be refined using a
911	   sliding window algorithm described in [RMD3].

913	   The reserved resources for a particular flow can also be
914	   explicitly released from a PHB reservation state by means of a PHR
915	   release message.  The usage of explicit release enables the
916	   instantaneous release of the resources regardless of the length of
917	   the refresh period.  This allows a longer refresh period, which also
918	   reduces the number of periodic refresh messages.

920	   Note that both in case of measurement- and reservation-based methods,
921	   the way of how the maximum bandwidth thresholds are maintained is out
922	   of the specification of this document. However, when admission
923	   priorities are supported, the Maximum Allocation [RFC4125] or the
924	   Russian Dolls [RFC4127] bandwidth allocation model may be used. In
925	   this case three types of priority traffic classes within the same
926	   PHB, e.g., Expedited Forwarding, can be differentiated. These three
927	   different priority traffic classes, which are associated to the same
928	   PHB, are denoted in this document as PHB_low_priority,
929	   PHB_normal_priority and PHB_high_priority.

931	4.4.  Transport of RMD-QOSM messages

933	   The intra-domain (local) messages used by the RMD-QOSM MUST operate
934	   in the NTLP/GIST Datagram mode (see [GIST]).  Therefore, the NSLP
935	   functionality available in all QoS NSLP nodes that are able to
936	   support the RMD-QOSM MUST require the intra-domain GIST
937	   functionality available in these nodes to operate in the datagram
938	   mode, i.e., require GIST to:

940	   * operate in unreliable mode. This can be satisfied by passing this
941	     requirement from the QoS-NSLP layer to the GIST layer via the API
942	     transfer-attributes.

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

948	   * do not create any NTLP routing state. This can be satisfied by
949	     passing this requirement from the QoS-NSLP layer to the GIST layer
950	     via the API.

952	   All the intra-domain local messages are transported using the GIST
953	   data messages (see [GIST]). At the ingress the original (end-to-end)
954	   RESERVE message is forwarded but ignored by the stateless or reduced-
955	   state nodes, see Figure 3. The intermediate (interior) nodes are
956	   bypassed using multiple levels of the router alert option
957	  (see [QoS-NSLP]. In that
958	   case, interior routers are configured to handle only certain levels
959	   of router alert (RAO) values. This is accomplished by marking the
960	   end-to-end RESERVE message, i.e., modifying the QoS-NSLP default
961	   NSLP-ID value to another NSLP-ID predefined value.

963	   The marking MUST be accomplished by the ingress by modifying the
964	   QoS_NSLP default NSLP-ID value to a NSLP-ID predefined value. In this
965	   way the egress MUST stop this marking process by reassigning the
966	   QoS-NSLP default NSLP-ID value to the original (end-to-end) RESERVE
967	   message. Note that the assignment of these NSLP-ID values is a QOS-
968	   NSLP issue, which should be accomplished via IANA.

970	4.5  Edge discovery and message addressing

972	   Mainly, the Egress node discovery can be performed either by using
973	   the GIST discovery mechanism [GIST], manual configuration or any
974	   other discovery technique.  The addressing of signaling messages
975	   depends on the used GIST transport mode.  The RMD QoS signaling
976	   messages that are processed only by the Edge nodes use the peer-peer
977	   addressing of the GIST connection (C) mode.  RMD QoS signaling
978	   messages that are processed by all nodes of the Diffserv domain,i.e.,
979	   Edges and Interior nodes, use the end-end addressing of the GIST
980	   datagram (D) mode.  RMD QoS signaling messages that are addressed to
981	   the data path end nodes are intercepted by the Egress nodes.

983	4.6.  Operation and sequence of events

985	4.6.1.  Basic unidirectional operation

987	   This section describes the basic unidirectional operation and
988	   sequence of events of the RMD-QOSM.  The following basic operation
989	   cases are distinguished:

991	   * Successful reservation (Section 4.6.1.1),
992	   * Unsuccessful reservation (Section 4.6.1.2),
993	   * RMD refresh reservation (Section 4.6.1.3),
994	   * RMD modification of aggregated reservation (4.6.1.4)
995	   * RMD release procedure (Section 4.6.1.5)
996	   * Severe congestion handling (Section 4.6.1.6)
997	   * Admission control using congestion notification based on probing
998	     (Section 4.6.1.7).

1000	   The QNEs at the Edges of the RMD domain support the RMD QoS Model and
1001	   end-to-end QoS models, which process the RESERVE message differently.
1002	   Note that the term end-to-end QoS model applies to any QoS model that
1003	   is initiated and terminated outside the RMD-QOSM aware domain.
1004	   However, there might be situations where a QoS model is initiated
1005	   and/or terminated by the QNE Edges and is considered to be an end-to-
1006	   end QoS model. This can occur when the QNE Edge can also operate as a
1007	   QNI or as a QNR. Note that the described functionality applies to the
1008	   RMD reservation-based and to the NSIS measurement-based admission
1009	   control methods.  The QNE Edge nodes maintain either per flow QoS-
1010	   NSLP reservation states or aggregated QoS-NSLP reservation states.
1011	   When the QNE Edges maintain aggregated QoS-NSLP reservation states,
1012	   the RMD-QOSM functionality may accomplish a RMD modification
1013	   procedure (see Section 4.6.1.4), instead of the reservation
1014	   initiation procedure that is described in this subsection.

1016	4.6.1.1.  Successful reservation

1018	   This section describes the operation of the RMD-QOSM where a
1019	   reservation is successfully accomplished.

1021	   The QNI generates the initial RESERVE message, and it is forwarded
1022	   by the NTLP as usual [GIST].

1024	4.6.1.1.1. Operation in Ingress node

1026	   When an end-to-end reservation request (RESERVE) arrives at the
1027	   Ingress node (QNE), see Figure 8, it is processed based on the end-
1028	   to-end QoS model. Note that when the QOSM ID of the end-to-end QoS
1029	   model is not known to the Ingress node (QNE), the Ingress MUST
1030	   interpret at least the mandatory parameters (see [QSP-T]). If the
1031	   QSPEC object contains also optional parameters that are not used by
1032	   the RMD-QOSM, then the N-flag of each of these objects MUST be set.
1033	   Subsequently, the RMD QoS Description: <Bandwidth> and <PHB Class>
1034	   are derived from the QoS Description of the end-to-end QSpec. The
1035	   Ingress QNE performs then the following functionality.

1037	   If the requested <Bandwidth> parameter cannot be satisfied locally,
1038	   then an end to end RESPONSE message has to be generated. An end-to-
1039	   end QSpec object MUST be included in the RESPONSE message. The
1040	   parameters included in the QSPEC <QoS Reserved> object are copied
1041	   from the original <QoS Desired> values. The "E" flag associated with
1042	   the QSPEC <QoS Reserved> object and the "E" flag associated with the
1043	   <Bandwidth> parameter are set. In addition, the INFO-SPEC object is
1044	   included in the end to end RESPONSE message. The error code used by
1045	   this INFO-SPEC is:

1047	   Error severity class: 0x04 Transient Failure
1048	   Error code value: 0x07 Total reservation failure

1050	   Furthermore, all the other RESPONSE parameters are set according to
1051	   the end-to-end QoS model or according to [QoS-NSLP] and [QSP-T].

1053	   If the request was satisfied locally (see Section 4.3), the Ingress
1054	   QNE node generates two RESERVE messages: one intra-domain and
1055	   one end-to-end RESERVE messages. These are bound together
1056	   in the following way. The end-to-end RESERVE SHOULD contain in the
1057	   BOUND_SESSION_ID the SESSION_ID of its bound intra-domain session.
1058	   Furthermore, if the QNE Edge nodes maintain intra-domain per flow
1059	   QoS-NSLP reservation states then the value of Binding_Code MUST be
1060	   set to 0x01 (Tunnel and end-to-end sessions). If the QNE Edge nodes
1061	   maintain intra-domain aggregated QoS-NSLP reservation states then the
1062	   value of Binding_Code MUST be set to 0x03 (Aggregate sessions).

1064	   The intra-domain RESERVE SHOULD contain in the BOUND_SESSION_ID the
1065	   SESSION_ID of its bound end-to-end session. The value of the
1066	   Binding_Code MUST be set to 0x01 (Tunnel and end-to-end sessions).
1067	   Note that the end to end RESERVE is tunneled within the RMD domain.
1068	   Therefore, the T-flag of the QSPEC parameters has to be processed/set
1069	   according to the [QSP-T] specification.

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

1082	   If no QOS-NSLP aggregation procedure at the QNE Edges is possible
1083	   then the IP source and IP destination address of this message MUST be
1084	   equal to the IP Source and IP destination addresses of the data flow.
1085	   The intra-domain RESERVE message MUST be sent using the NTLP datagram
1086	   mode (see Section 4.4). In addition, the intra-domain RESERVE (RMD-
1087	   QSPEC) message MUST include a PHR container (PHR_Resource_Request)
1088	   and the "RMD QOS Description" field.

1090	   The end-to-end RESERVE message includes the end-to-end QSpec and it
1091	   is sent towards the Egress QNE.  If the end-to-end QSpec does not
1092	   carry an RII object, then an RII object has to be generated and
1093	   included into the end-to-end RESERVE message.

1095	   Note that after completing the initial discovery phase, the GIST
1096	   connection mode can be used between the QNE Ingress and QNE Egress.
1097	   The end-to-end RESERVE message is forwarded using the GIST
1098	   forwarding procedure to bypass the Interior stateless or reduced-
1099	   state QNE nodes, see Figure 8.  The bypassing procedure is
1100	   described in Section 4.4. At the QNE Ingress the end-to-end RESERVE
1101	   message is marked, i.e., modifying the QoS-NSLP default NSLP-ID value
1102	   to another NSLP-ID predefined value, which corresponds to a RAO value
1103	   that will be used by the GIST message carrying the end-to-end
1104	   RESPONSE message to bypass the QNE Interior nodes. Note that the QNE
1105	   Interior nodes, see [GIST], are configured to handle only certain
1106	   levels of router alert (RAO) values.

1108	   Furthermore, note that the initial discovery phase and the process of
1109	   sending the end-to-end RESERVE message towards the QNE Egress MAY be
1110	   done simultaneously.

1112	   The (initial) intra-domain RESERVE message MUST be sent by the QNE
1113	   Ingress and it MUST contain the following values:

1115	   *  the value of the <RSN> object SHOULD be the same as the value
1116	      of the RSN object of the end-to-end RESERVE message;

1118	   *  the value of the <BOUND_SESSION_ID> object MUST be the SESSION_ID
1119	      associated to the end-to-end RESERVE message. Furthermore, if
1120	      the QNE Edge nodes maintain per flow QoS-NSLP reservation states
1121	      then the value of Binding_Code MUST be set to 0x01 (Tunnel and
1122	      end-to-end sessions).

1124	   *  the SCOPING flag MUST not be set, meaning that a default
1125	      scoping of the message is used.  Therefore, the QNE Edges MUST
1126	      be configured as boundary nodes and the QNE Interior nodes
1127	      MUST be configured as Interior (intermediary) nodes;

1129	   *  The <RII> object MUST not included in this message;

1131	   *  The flag REPLACE MUST be set to FALSE = 0;

1133	   *  the value of the <REFRESH_PERIOD> object MUST be calculated
1134	      and set by the QNE Ingress node, see also Section 4.6.1.3;

1136	   *  the value of the <PACKET_CLASSIFIER> object SHOULD be associated
1137	      with the path-coupled routing MRM. The flag that has to be set is
1138	      the flag T (traffic class) meaning that the packet classification
1139	      of packets is based on the DSCP value included in the IP header of
1140	      the packets. Note that the DSCP value SHOULD be obtained from the
1141	      MRI values obtained from GIST.

1143	   *  the PHR resource units MUST be included into the <Bandwidth>
1144	      parameter of the "RMD QoS Description" field;

1146	   *  the value of the Parameter/Container ID field of the PHR container
1147	      MUST be set to 1, (i.e., PHR_Resource_Request;)

1149	   *  the value of the <Admitted Hops> parameter in the PHR container
1150	      MUST be set to "1";

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

1155	   * If the end-to-end RESERVE message carried an <Admission Priority>
1156	     parameter, then this parameter should be copied and carried by the
1157	     (initiating) intra-domain RESERVE. Note that for the RMD-QOSM a
1158	     reservation established without an <Admission Priority> parameter
1159	     is equivalent to a reservation with Admission Priority value 1.
1160	     Note that in this case each admission priority is associated with a
1161	     priority traffic class. The three priority traffic classes
1162	     (PHB_low_priority, PHB_normal_priority, PHB_high_priority) may be
1163	     associated with the same PHB.

1165	   *  In a single-domain case the PDR container MAY not be included into
1166	      the message.

1168	   When an end-to-end RESPONSE(PDR) message is received by the QNE
1169	   Ingress node, the RMD-QSPEC, see Section 4.6.1.1.3, has to be
1170	   identified, processed and removed from the end-to-end RESPONSE
1171	   message.  The QoS-NSLP state in the QNE Ingress stores and maintains
1172	   the binding between each end-to-end session and each intra-domain
1173	   session. In this way the QNE Ingress can match the PHR container that
1174	   has been carried by the intra-domain RESERVE with the received PDR
1175	   container that has been carried by the end-to-end RESPONSE message.

1177	   The RMD QoS model functionality is notified by reading the <M>
1178	   parameter of the "PDR RMD control information" container that the
1179	   reservation has been successful.

1181	   Furthermore, the INFO_SPEC object SHOULD be read by the QoS-NSLP
1182	   functionality. In case of successful reservation the INFO_SPEC object
1183	   SHOULD have the following values:

1185	   * Error Severity Class: 0x02 Success
1186	   * Error Code value: 0x01 Reservation successful

1188	   If the end-to-end RESPONSE message has to be forwarded to a
1189	   node outside the RMD-QOSM aware domain then the non-default values of
1190	   the objects contained in this message (i.e., <RII/RSN>, <INFO_SPEC>,
1191	   [ *QSPEC ]) MUST be set by the QOS-NSLP protocol functions
1192	   of the QNE.

1194	4.6.1.1.2 Operation in the Interior nodes

1196	    Each QNE Interior node MUST use the QoS-NSLP and RMD-QOSM parameters
1197	   of the intra-domain RESERVE (RMD-QSPEC) message as follows:

1199	  * the values of the <RSN>, <RII>, <PACKET_CLASSIFIER>,
1200	      <REFRESH_PERIOD>, <BOUND_SESSION_ID> objects MUST NOT be changed.
1201	      The interior node is informed by the <PACKET_CLASSIFIER> object
1202	      that the packet classification should be done on the DSCP value.
1203	      The value of the DSCP value SHOULD be obtained via the MRI
1204	      parameters that the QoS-NSLP receives from GIST.
1205	   *  The flag REPLACE MUST be set to FALSE = 0;

1207	   *  the value of <Bandwidth> parameter of the "RMD QoS Description"
1208	      field is used by the QNE Interior node for admission control, see
1209	      Section 4.3.2 and Section 4.3.3. Furthermore, if the <Admission
1210	      Priority> parameter is carried by the "RMD QoS Description" field
1211	      this parameter is processed as described in the following bullet.

1213	   *  in case of the RMD reservation-based procedure, and if these
1214	      resources are admitted (see Section 4.3.3), they are added to the
1215	      currently reserved resources. Furthermore, the value of the
1216	      <Admitted Hops> parameter in the PHR container has to be increased
1217	      by one.

1219	   *  If the bandwidth allocated for the PHB_high_priority traffic is
1220	      fully utilized, and a high priority request arrives, other
1221	      policies can be used, which are beyond the scope of this document.
1222	      One example for these policies can be that the high priority
1223	      session is admitted through preemption of ongoing lower priority
1224	      sessions, when the bandwidth reserved by the lower priority
1225	      sessions can satisfy the high priority bandwidth request.. When
1226	      the available bandwidth for the PHB_lower_priority
1227	      and for the PHB_normal_priority is not enough to support the high
1228	      priority traffic, then it will generate congestion for these PHB
1229	      traffic classes. A solution to this congestion problem can be
1230	      accomplished by using the severe congestion detection mechanism
1231	      specified in Section 4.6.1.6.2.1. The degree of this congested
1232	      bandwidth is indicated by using a specific DSCP (see Section
1233	      4.6.1.6.2.1) by marking the bytes proportionally to the degree of
1234	      congestion. Other mechanisms may also be used as queues for the
1235	      new high priority requests until capacity becomes available for
1236	      the high priority sessions.

1238	   *  in case of the RMD measurement based method, and if these
1239	      resources are admitted (see Section 4.3.2), using a MBAC
1240	      algorithm, the number of this resources will be used to update the
1241	      MBAC algorithm.

1243	4.6.1.1.3 Operation in the Egress node

1245	   When the end-to-end RESERVE message is received by the egress node,
1246	   it is only forwarded further, towards QNR, if the processing of the
1247	   intra-domain RESERVE(RMD-QSPEC) message was successful at all nodes
1248	   in the RMD domain. In this case, the QNE Egress MUST stop the marking
1249	   process that was used to bypass the QNE Interior nodes by reassigning
1250	   the QoS-NSLP default NSLP-ID value to the end-to-end RESERVE message,
1251	   see Section 4.4. Furthermore the carried BOUND_SESSION_ID object
1252	   associated with the intra-domain session SHOULD be removed.
1253	   Note that the received end to end RESERVE was tunneled within the RMD
1254	   domain. Therefore, the T-flag of the QSPEC parameters has to be
1255	   processed/set according to the [QSP-T] specification.

1257	   If the the processing of the intra-domain RESERVE(RMD-QSPEC) was not
1258	   successful at all nodes in the RMD domain then the inter domain (end-
1259	   to-end) reservation is considered as being failed. Furthermore, note
1260	   that the Egress should use a timer, that uses a pre-configured value,
1261	   which can be used to synchronize the arrival of the end to end
1262	   RESERVE and the intra-domain RESERVE (RMD-QSPEC) messages. If these
1263	   two messages do not arrive during the time defined by the timer, then
1264	   the reservation is considered as being failed. In this case a
1265	   RESPONSE message is sent towards the QNE ingress with the following
1266	   INFO_SPEC values:

1268	   Error Class: 0x04 Transient Failure
1269	   Error Code: 0x05 Mismatch synchronization between end-to-end RESERVE
1270	   and intra-domain RESERVE

1272	   When the intra-domain RESERVE(RMD-QSPEC) is received by the QNE
1273	   Egress node of the session associated with the intra-domain
1274	   RESERVE(RMD-QSPEC) (the PHB session) with the session included in
1275	   its <BOUND_SESSION_ID> object MUST be bound.  The session included
1276	   in the <BOUND_SESSION_ID> object is the session associated with the
1277	   end-to-end RESERVE message.
1278	   Note that if the QNE Edge nodes maintain per flow QoS-NSLP
1279	   reservation states then the value of Binding_Code = 0x01 (Tunnel and
1280	   end-to-end sessions) is used.

1282	   Note that when the interior nodes are using mechanisms to admit high
1283	   priority session through preemption of ongoing lower priority
1284	   sessions, the mechanisms of solving the congestion on a low priority
1285	   traffic PHB may use the solution specified in Section 4.6.1.6.2.2.

1287	   The QNE Egress MUST wait for the end-to-end RESPONSE message that has
1288	   the same SESSION ID and RII object as the end-to-end RESERVE message
1289	   forwarded towards QNR.

1291	   The non-default values of the objects contained in the end-to-end
1292	   RESPONSE(PDR) message MUST be used and/or set by the QNE Egress as
1293	   follows:

1295	   * the values of the <RII/RSN>, <INFO_SPEC>, [ QSPEC ] objects are
1296	     set according to [QoS-NSLP] and/or [QSP-T]..  The INFO_SPEC object
1297	     SHOULD be set by the QoS-NSLP functionality. In case of successful
1298	     reservation the INFO_SPEC object SHOULD have the following values:
1299	     Error Severity Class: 0x02 Success,
1300	     Error Code value: 0x01 Reservation successful,
1301	     Furthermore, an end-to-end QSpec object MUST be included in the
1302	     RESPONSE message. The parameters included in the QSPEC <QoS
1303	     Reserved> object are copied from the original <QoS Desired> values.

1305	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
1306	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1307	    |                    |                   |                    |
1308	RESERVE                  |                   |                    |
1309	--->|                    |                   |     RESERVE        |
1310	    |------------------------------------------------------------>|
1311	    |RESERVE(RMD-QSPEC)  |                   |                    |
1312	    |------------------->|                   |                    |
1313	    |                    |RESERVE(RMD-QSPEC) |                    |
1314	    |                    |------------------>|                    |
1315	    |                    |                   | RESERVE(RMD-QSPEC) |
1316	    |                    |                   |------------------->|
1317	    |                    |                   |                RESERVE
1318	    |                    |                   |                    |-->
1319	    |                    |                   |                RESPONSE
1320	    |                    |                   |                    |<--
1321	    |                    |RESPONSE(PDR)      |                    |
1322	    |<------------------------------------------------------------|
1323	RESPONSE                 |                   |                    |
1324	<---|                    |                   |                    |

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

1329	   In addition to the above, the QNE Egress MUST also generate a RMD-
1330	   QSPEC object that is carried by the end-to-end RESPONSE(PDR)
1331	   message, see Section 4.2.

1333	   The following parameters of the RMD-QSPEC object MUST be used and/or
1334	   set in the following way:

1336	   *  the value of the Parameter/Container ID field of the PDR container
1337	      MUST be set "7" (i.e., PDR_Reservation_Report);

1339	   *  the value of the <M> field of the PDR container MUST be equal to
1340	      the value of the <M> parameter of the PHR container that was
1341	      carried by its associated intra-domain RESERVE(RMD-QSPEC)
1342	      message.

1344	   The end-to-end RESPONSE(PDR) message is addressed and sent to its
1345	   upstream QoS-NSLP neighbor, i.e., QNE Ingress node. Note that for all
1346	   upstream messages the RAO is not set.  Therefore, all Interior nodes
1347	   ignore the end-to-end RESPONSE messages.

1349	4.6.1.2.  Unsuccessful reservation

1351	   This section describes the operation where a request for reservation
1352	   cannot be satisfied by the RMD-QOSM.

1354	   The QNE Ingress, the QNE Interior and QNE Egress nodes process and
1355	   forward the end-to-end RESERVE message and the intra-domain
1356	   RESERVE(RMD-QSPEC) message in the same way as specified in Section
1357	   4.6.1.1.  The main difference between the unsuccessful operation and
1358	   successful operation is that one of the QNE nodes does not admit the
1359	   request due to lack of resources.  This also means that the QNE edge
1360	   node MUST NOT forward the end-to-end RESERVE message towards the
1361	   QNR node.

1363	   Note that the described functionality applies to the RMD reservation-
1364	   based and to the NSIS measurement-based admission control methods.
1365	   The QNE Edge nodes maintain either per flow QoS-NSLP reservation
1366	   states or aggregated QoS-NSLP reservation states. When the QNE edges
1367	   maintain aggregated QoS-NSLP reservation states, the RMD-QOSM
1368	   functionality may accomplish a RMD modification procedure (see
1369	   Section 4.6.1.4), instead of the reservation initiation procedure
1370	   that is described in this subsection.

1372	4.6.1.2.1 Operation in the Ingress nodes

1374	   When an end-to-end RESERVE message arrives at the QNE Ingress and
1375	   if there are no resources available locally, the QNE Ingress MUST
1376	   reject this end-to-end RESERVE message and sends a RESPONSE message
1377	   back to the sender, as described in the QoS-NSLP specification, see
1378	   [QoS-NSLP] and [QSP-T].

1380	   When an end-to-end RESPONSE(PDR) message is received by an Ingress
1381	   node, see Section 4.6.1.2.3, the following actions take place. The
1382	   non-default values of the objects contained in the end-to-end
1383	   RESPONSE (PDR) message MUST be used and/or set by the QNE Ingress
1384	   node as follows:

1386	   *  the values of the <RII/RSN>, [<INFO_SPEC> ], [QSPEC] objects are
1387	      set according to the QoS-NSLP procedures. Furthermore, the
1388	      INFO_SPEC object, generated by the Egress is read by the QoS-NSLP
1389	      functionality.

1391	   *  the RMD-QSPEC object, see Section 4.2, has to be processed
1392	      and removed.  The RMD Resource Management Function (RMF) is
1393	      notified by reading the <M> parameter of the PDR container that
1394	      the reservation has been unsuccessful. Note that when the QNE
1395	      edges maintain a per flow QoS-NSLP reservation state the RMD-QOSM
1396	      functionality, has to start an RMD release procedure (see Section
1397	      4.6.1.5). When the QNE edges maintain aggregated QoS-NSLP
1398	      reservation states the RMD-QOSM functionality MAY start a RMD
1399	      modification procedures (see Section 4.6.1.4).

1401	4.6.1.2.2 Operation in the Interior nodes

1403	   In case of the RMD reservation based scenario, and if the
1404	   intra-domain reservation request is not admitted by the QNE Interior
1405	   node then the <Hop_U> and <M> parameters of the PHR container MUST be
1406	   set to "1".  The <Admitted Hops> counter MUST NOT be increased.
1407	   Furthermore, the "E" flag associated with the QSPEC <QoS Desired>
1408	   object and the "E" flag associated with the <Bandwidth> parameter
1409	   SHOULD be set. In case of the RMD measurement based scenario, the
1410	   <M> parameter of the PHR container MUST be set to "1". Furthermore,
1411	   the "E" flag associated with the QSPEC <QoS Desired> object and the
1412	   "E" flag associated with the <Bandwidth> parameter SHOULD be set.

1414	   In general, if a QNE Interior node receives a QSpec <Bandwidth>
1415	   parameter with the "E" flag set and a PHR container type
1416	   "PHR_Resource_Request", with the <M> parameter set to "1", then this
1417	   PHR container and the "RMD QoS Description" field MUST NOT be
1418	   processed.

1420	4.6.1.2.3 Operation in the Egress nodes

1422	   In the RMD reservation based and the RMD measurement based scenario,
1423	   when the <M> marked intra-domain RESERVE(RMD-QSPEC) is received by
1424	   the QNE Egress node (see Figure 9) the session associated with the
1425	   intra-domain RESERVE(RMD-QSPEC) (the PHB session) and the session
1426	   included in its BOUND_SESSION_ID object MUST be bound. The session
1427	   in the <BOUND_SESSION_ID> object is the session associated with the
1428	   end-to-end RESERVE.

1430	   The QNE Egress node MUST generate an end-to-end RESPONSE message
1431	   that has to be sent to its previous stateful QoS-NSLP hop.

1433	   *  the values of the <RII/RSN>, <INFO_SPEC> objects are set
1434	      by the standard QoS-NSLP protocol functions. In case of
1435	      unsuccessful reservation the INFO_SPEC object SHOULD have the
1436	      following values:
1437	      Error Severity Class: 0x04, Transient Failure
1438	      Error Code value: 0x07 Total reservation failure

1440	   The QSpec that was carried by the end to end RESERVE belonging to the
1441	   same session as this end-to-end RESPONSE is included in this message.
1442	   The parameters included in the QSPEC <QoS Reserved> object are copied
1443	   from the original <QoS Desired> values. The "E" flag associated with
1444	   the QSPEC <QoS Reserved> object and the "E" flag associated with the
1445	   <Bandwidth> parameter are set.

1447	QNE (Ingress)    QNE (Interior)       QNE (Interior)      QNE (Egress)
1448	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1449	    |                    |                   |                    |
1450	RESERVE                  |                   |                    |
1451	--->|                    |                   |     RESERVE        |
1452	    |------------------------------------------------------------>|
1453	    |RESERVE(RMD-QSPEC)  |                   |                    |
1454	    |------------------->|                   |                    |
1455	    |                    |RESERVE(RMD-QSPEC:M =1)                 |
1456	    |                    |------------------>|                    |
1457	    |                    |                   | RESERVE(RMD-QSPEC:M=1)
1458	    |                    |                   |------------------->|
1459	    |                    |RESPONSE(PDR)      |                    |
1460	    |<------------------------------------------------------------|
1461	RESPONSE                 |                   |                    |
1462	<---|                    |                   |                    |
1463	RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max_Admitted Hops>
1464	    |------------------->|                   |                    |

1466	Figure 9: Basic operation during unsuccessful reservation
1467	          initiation used by the RMD-QOSM

1469	   In addition to the above, similarly to the successful operation,
1470	   see Section 4.6.1.1.3, the QNE Egress MUST also generate an RMD-QSPEC
1471	   object that is carried by the end-to-end RESPONSE message.

1473	   The following fields of the RMD-QSPEC object MUST be used and/or set
1474	   in the following way:

1476	   *  the value of the <PDR Control Type> of the PDR container MUST be
1477	      set to "7" (PDR_Reservation_Report);

1479	   *  the value of the <Admitted Hops> parameter of the PHR container
1480	      included in the received <M> marked PDR container MUST be included
1481	      in the <Max_Admitted Hops> parameter of the PDR container;

1483	   *  the value of the <M> parameter of the PDR container MUST be set to
1484	      "1".

1486	4.6.1.3 RMD refresh reservation

1488	   In case of RMD measurement-based method, QoS-NSLP states in the RMD
1489	   domain are not maintained, therefore, the end-to-end RESERVE
1490	   (refresh) message is sent directly to the QNE Egress.

1492	   The refresh procedure in case of RMD reservation-based method
1493	   follows a similar scheme as the reservation process, shown in Figure
1494	   3. If the RESERVE messages arrive within the soft state time-out
1495	   period, the corresponding number of resource units are not removed.
1496	   However, the transmission of the intra-domain and end-to-end
1497	   (refresh) RESERVE message are not necessarily synchronized.
1498	   Furthermore, the generation of the end-to-end RESERVE message, by the
1499	   QNE edges, depends on the locally maintained refreshed interval (see
1500	   [QoS-NSLP]).

1502	4.6.1.3.1 Operation in the Ingress node

1504	   The Ingress node MUST be able to generate an intra-domain (refresh)
1505	   RESERVE(RMD-QSpec) at any time. Before generating this message, the
1506	   RMD QoS signaling model functionality is using the RMD traffic class
1507	   (PHR) resource units for refreshing the RMD traffic class state.

1509	   Note that the RMD traffic class refresh periods MUST be equal in
1510	   all QNE edge and QNE Interior nodes and SHOULD be smaller (default:
1511	   more than two times smaller) than the refresh period at the QNE
1512	   Ingress node used by the end-to-end RESERVE message. The intra-domain
1513	   RESERVE (RMD-QSPEC) message MUST include a "RMD QoS Description"
1514	   field and a PHR container (i.e., PHR_Refresh_Update).

1516	   The selection of the IP source and destination address of this
1517	   message depends on if and how the different inter domain
1518	   (end-to-end) flows can be aggregated by the QNE Ingress node (see
1519	   Section 4.3.1).  Note that this QoS-NSLP aggregation procedure is
1520	   different than the RMD traffic class aggregation procedure.  One
1521	   example is the approach used by the RSVP aggregation scenario
1522	   ([RFC3175]), where the IP source address of this message is the IP
1523	   address of the aggregator (i.e., QNE Ingress) and the IP destination
1524	   address of this message is the IP address of the De-aggregator
1525	   (i.e., QNE Egress).  An alternative approach is the one used
1526	   in "RSVP Refresh Overhead Reduction Extensions" ([RFC2961]).  If no
1527	   QOS-NSLP aggregation procedure at the QNE edges is possible then the
1528	   IP source and IP destination address of this message MUST be equal to
1529	   the IP source and IP destination addresses of the data flow.

1531	   An example of this RMD specific refresh operation can be seen in
1532	   Figure 10.

1534	QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)
1535	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1536	    |                    |                   |                    |
1537	    |RESERVE(RMD-QSPEC)  |                   |                    |
1538	    |------------------->|                   |                    |
1539	    |                    |RESERVE(RMD-QSPEC) |                    |
1540	    |                    |------------------>|                    |
1541	    |                    |                   | RESERVE(RMD-QSPEC) |
1542	    |                    |                   |------------------->|
1543	    |                    |                   |                    |
1544	    |                    |RESPONSE(RMD-QSPEC)|                    |
1545	    |<------------------------------------------------------------|
1546	    |                    |                   |                    |

1548	   Figure 10: Basic operation of RMD specific refresh procedure

1550	   Most of the non-default values of the objects contained in this
1551	   message MUST be used and set by the QNE Ingress in the same
1552	   way as described in Section 4.6.1.1.  The following objects are
1553	   used and/or set differently:

1555	  *  The flag REPLACE MUST be set to FALSE = 0;

1557	  *  the PHR resource units MUST be included into the <Bandwidth>
1558	     parameter. The value of the <Bandwidth> parameter depends on
1559	     how the different inter domain (end-to-end) flows are aggregated
1560	     by the QNE Ingress node (e.g., the sum of all the PHR requested
1561	     resources of the aggregated flows).  If no QOS-NSLP aggregation is
1562	     accomplished by the QNE Ingress node, the value of the <Bandwidth>
1563	     parameter SHOULD be equal to the <Bandwidth> parameter of its
1564	     associated new (initial) intra-domain RESERVE (RMD-QSPEC) message;

1566	   *  the value of the Parameter/Container field of the "PHR RMD-QOSM
1567	      control information" container MUST be set to "2",
1568	      i.e., "PHR_Refresh_Update";

1570	   *  In a single-domain case the PDR container field
1571	      is not needed in the message.

1573	   *  the value of the <RII> object MUST contain the Response
1574	      Identification Information value of the Ingress QNE, that is
1575	      unique within a session and different for each message (see
1576	      [QoS-NSLP]).

1578	   When the intra-domain RESPONSE (RMD-QSPEC) message, see Section
1579	   4.6.1.3.3., is received by the QNE Ingress node, then:

1581	   *  the values of the <RII/RSN>, <INFO_SPEC>, [*QSPEC] objects are
1582	      processed by the standard QoS-NSLP protocol functions (see Section
1583	      4.6.1.1);

1585	   *  the PDR has to be processed and removed by the RMD-QOSM
1586	      functionality in the QNE Ingress node.  The RMD-QOSM functionality
1587	      is notified by the <PDR M> parameter of the PDR container
1588	      that the refresh procedure has been successful or unsuccessful.
1589	      All session(s) (in case of the flow aggregation procedure there
1590	      will be more than one sessions) associated with this RMD specific
1591	      refresh session MUST be informed about the success or failure of
1592	      the refresh procedure.  In case of failure, the QNE Ingress node
1593	      has to generate (in a standard QoS-NSLP way) an error end-to-end
1594	      RESPONSE message that will be sent towards QNI.

1596	4.6.1.3.2 Operation in the Interior node

1598	   The intra-domain RESERVE (RMD-QSPEC) message is received and
1599	   processed by the QNE Interior nodes.  Any QNE edge or QNE Interior
1600	   node that receives a "PHR_Refresh_Update" control information field
1601	   MUST identify the traffic class state (PHB) (using the
1602	   <PHB Class> parameter).  Most of the parameters in this refresh
1603	   intra-domain RESERVE (RMD-QSPEC) message MUST be used and/or set by
1604	   a QNE Interior node in the same way as described in Section 4.6.1.1.

1606	   The following objects are used and/or set differently:

1608	   * the value of <Bandwidth> parameter of the "RMD QoS Description"
1609	     field is used by the QNE Interior node for refreshing the RMD
1610	     traffic class state. These resources (included in <Bandwidth>),
1611	     if reserved, are added to the currently reserved resources
1612	     per PHB and therefore they will become a part of the per traffic
1613	     class (per-PHB) reservation state, see Section 4.3.3. If the
1614	     refresh procedure cannot be fulfilled then the <M> parameter of the
1615	     PHR container MUST be set to "1". Furthermore, the "E" flag
1616	     associated with <QoS Desired> object and the "E" flag associated
1617	     with the <Bandwidth> parameter SHOULD be set.

1619	   Any PHR container of type "PHR_Refresh_Update", and its associated
1620	   "RMD QoS Description" field (i.e., <Bandwidth>), whether it is
1621	   marked or not and independent of the "E" flag value of the
1622	   <Bandwdith> parameter, is always processed, but marked bits are not
1623	   changed.

1625	4.6.1.3.3 Operation in the Egress node

1627	   The intra-domain RESERVE(RMD-QSPEC) message is received and
1628	   processed by the QNE Egress node.  A new intra-domain RESPONSE
1629	   (RMD-QSPEC) message is generated by the QNE Egress node and MUST
1630	   include a PDR (type PDR_Refresh_Report).

1632	   The intra-domain RESPONSE (RMD-QSPEC) message MUST be sent to the
1633	   QNE Ingress node, i.e., the previous stateful hop. The address of the
1634	   QNE Ingress node can be found using the existing messaging
1635	   association between the QNE Egress and QNE Ingress nodes. This state
1636	   is associated with the end-to-end session and identified by the
1637	   SESSION ID that is bound to the session of the intra-domain
1638	   RESPONSE(RMD-QSPEC) message.

1640	   *  the values of the <RII/RSN>, <INFO_SPEC> objects are set
1641	     by the standard QoS-NSLP protocol functions.

1643	   * The value of the <PDR Control Type> parameter of the PDR container
1644	     MUST be set "8" (i.e. PDR_Refresh_Report).
1645	     In case of successful reservation the INFO_SPEC object SHOULD
1646	     have the following values:
1647	     Error Severity Class: 0x02, Success
1648	     Error Code value: 0x01 Reservation successful

1650	   * In case of unsuccessful reservation the INFO_SPEC object SHOULD
1651	     have the following values:
1652	     Error Severity Class: 0x04, Transient Failure
1653	     Error Code value: 0x07 Total reservation failure

1655	   The RMD-QSpec that was carried by the intra-domain RESERVE
1656	   belonging to the same session as this intra-domain RESPONSE is
1657	   included in the intra-domain RESPONSE message. The parameters
1658	   included in the QSPEC <QoS Reserved> object are copied from the
1659	   original <QoS Desired> values. If the reservation is unsuccessful
1660	   then "E" flag associated with the QSPEC <QoS Reserved> object and the
1661	   "E" flag associated with the <Bandwidth> parameter are set.

1663	4.6.1.4.  RMD modification of aggregated reservations

1665	   In the case when the QNE edges maintain QoS-NSLP aggregated
1666	   reservation states and the aggregated reservation has to be
1667	   modified (see Section 4.3.1) the following procedure is applied:

1669	   * When the modification request requires an increase of the reserved
1670	     resources, the QNE Ingress node MUST include the corresponding
1671	     value into the <Bandwidth> parameter of the "RMD QoS Description"
1672	     field, which is sent together with a "PHR_Resource_Request" control
1673	     information.  If a QNE edge or QNE Interior node is not able to
1674	     reserve the number of requested resources, the
1675	     "PHR_Resource_Request" control information that is associated with
1676	     the <Bandwidth> parameter MUST be marked.  In this situation the
1677	     RMD specific operation for unsuccessful reservation will be applied
1678	     (see Section 4.6.1.2).

1680	   * When the modification request requires a decrease of the
1681	     reserved resources, the QNE Ingress node MUST include this value
1682	     into the <Bandwidth> parameter of the "RMD QoS Description" field.
1683	     Subsequently an RMD release procedure SHOULD be accomplished (see
1684	     Section 4.6.1.5).

1686	4.6.1.5  RMD release procedure

1688	   If a refresh RESERVE message does not arrive at a QNE Interior node
1689	   within the refresh time-out period then the resources associated
1690	   with this message are removed.  This soft state behavior provides
1691	   certain robustness for the system ensuring that unused resources are
1692	   not reserved for long time.  Resources can be removed by an explicit
1693	   release at any time.

1695	   When the RMD-RMF of a QNE edge or QNE Interior node processes a
1696	   "PHR_Release_Request" control information it MUST identify the
1697	   <PHB Class> parameter and estimate the time period that elapsed
1698	   after the previous refresh, see also Section 3 of [CsTa05]. This MAY
1699	   be done by indicating the time lag, say "T_lag", between the last
1700	   sent "PHR_Refresh_Update" and the "PHR_Release_Request" control
1701	   information container by the QNE Ingress node.  The value of "T_Lag"
1702	   is first normalized to the length of the refresh period, say
1703	   "T_period".  The ratio between the "T_Lag" and the length of the
1704	   refresh period, "T_period", is calculated.  This ratio is then
1705	   introduced into the <Time Lag> field of the "PHR_Release_Request"
1706	   control information.

1708	   When a node (QNE edge or QNE Interior) receives the
1709	   "PHR_Release_Request" control information, it MUST store the arrival
1710	   time.  Then it MUST calculate the time difference, "Tdiff", between
1711	   the arrival time and the start of the current refresh period,
1712	   "T_period".  Furthermore, this node MUST derive the value of the
1713	   "T_Lag", from the <Time Lag> parameter. "T_Lag" can be found by
1714	   multiplying the value included in the <Time Lag> parameter with the
1715	   length of the refresh period, "T_period". If the derived time lag,
1716	   "T_lag", is smaller than the calculated time difference, "T_diff",
1717	   then this node MUST decrease the PHB reservation state with the
1718	   number of resource units indicated in the <Bandwidth> parameter of
1719	   the "RMD QoS Description" field that has been sent together with the
1720	   "PHR_Release_Request" control information container, but not below
1721	   zero.

1723	   An RMD specific release procedure can be triggered by an end-to-end
1724	   RESERVE with a TEAR flag set ON (see Section 4.6.1.5.1) or it can be
1725	   triggered by either an intra-domain RESPONSE, an end-to-end RESPONSE
1726	    or an end-to-end NOTIFY message that includes a marked (i.e., PDR
1727	   <M> and/or PDR <S> parameters are set ON) "PDR_Reservation_Report" or
1728	   "PDR_Congestion_Report" and/or an INFO_SPEC object that includes one
1729	   of the following error codes, see Section 4.7:

1731	   0x01 - Informational
1732	   0x03 - Protocol error
1733	   0x04 - Transient Failure
1734	   0x05 - Permanent failure
1735	   0x06 - QoS-related Error

1737	4.6.1.5.1.  Triggered by a RESERVE message

1739	   This RMD explicit release procedure can be triggered by a tear (TEAR
1740	   flag set ON) end-to-end RESERVE message. When a tear (TEAR flag
1741	   set ON) end-to-end RESERVE message arrives to the QNE Ingress
1742	   then the QNE Ingress node SHOULD process the message in a standard
1743	   QoS-NSLP way (see [QoS-NSLP]). In addition to this, the RMD RMF
1744	   has to be notified.

1746	   Similar to Section 4.6.1.1, a bypassing procedure has to be initiated
1747	   by the QNE Ingress node. The bypassing procedure is performed
1748	   according to the description given in Section 4.4. At the QNE Ingress
1749	   the end-to-end RESERVE message is marked, i.e., modifying the QoS-
1750	   NSLP default NSLP-ID value to another NSLP-ID predefined value, which
1751	   corresponds to a RAO value that will be used by the GIST message that
1752	   carries the end-to-end RESPONSE message to bypass the QNE Interior
1753	   nodes. It will generate an intra-domain RESERVE(RMD-QSPEC) message.
1754	   Before generating this message, the RMD RMF is using the RMD traffic
1755	   class (PHR) resources (specified in <Bandwidth>) and the PHB type
1756	   (specified in <PHB Class>) for a RMD release procedure.  This can be
1757	   achieved by subtracting the amount of the requested resources from
1758	   the total reserved amount of resources stored in the RMD traffic
1759	   class state.

1761	QNE (Ingress)     QNE (Interior)       QNE (Interior)    QNE (Egress)
1762	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1763	    |                    |                   |                    |
1764	RESERVE                  |                   |                    |
1765	--->|                    |                   |     RESERVE        |
1766	    |------------------------------------------------------------>|
1767	    |RESERVE(RMD-QSPEC:Tear=1)               |                    |
1768	    |------------------->|                   |                    |
1769	    |                    |RESERVE(RMD-QSPEC:Tear=1)               |
1770	    |                    |------------------->|                   |
1771	    |                    |                 RESERVE(RMD-QSPEC:Tear=1)
1772	    |                    |                   |------------------->|
1773	    |                    |                   |                RESERVE
1774	    |                    |                   |                    |-->
1775	    |                    |                   |

1777	   Figure 11: Explicit release triggered by RESERVE used by the RMD-QOSM

1779	   The intra-domain RESERVE (RMD-QSPEC) message MUST include a "RMD
1780	   QoS Description" field and a PHR container, (i.e.,
1781	   "PHR_Resource_Release") and it MAY include a PDR container, (i.e.,
1782	   PDR_Release_Request).  An example of this operation can be seen in
1783	   Figure 11.

1785	   Most of the non default values of the objects contained in the
1786	   tear intra-domain RESERVE message are set by the QNE Ingress node in
1787	   the same way as described in Section 4.6.1.1.  The following objects
1788	   are set differently:

1790	   *  The flag REPLACE MUST be set to FALSE = 0;

1792	   *  The <RII> object MUST not included in this message.  This is
1793	      because the QNE Ingress node does not need to receive a
1794	      response from the QNE Egress node;

1796	   *  the TEAR flag MUST be set to ON;

1798	   *  the PHR resource units MUST be included into the <Bandwidth>
1799	      parameter of the "RMD QoS Description" field;

1801	   *  the value of the <Admitted Hops> parameter MUST be set to "1";

1803	   *  the value of the <Time Lag> parameter of the PHR container is
1804	      calculated by the RMD-QOSM functionality (see 4.6.1.5)the value of
1805	      the <Control Type> parameter of PHR container is set to "3" (i.e.,
1806	      PHR_Resource_Release).

1808	   The intra-domain tear RESERVE (RMD-QSPEC) message is received and
1809	   processed by the QNE Interior nodes.  Most of the non-default
1810	   values of the objects contained in this refresh intra-domain RESERVE
1811	   (RMD-QSPEC) message are set by a QNE Interior node in the same way
1812	   as described in Section 4.6.1.1.  The following objects are set and
1813	   processed differently:

1815	   *  Any QNE Interior node that receives the combination of the "RMD
1816	   QoS Description" field and the "PHR_Resource_Release" control
1817	   information container  MUST identify the traffic class (PHB)
1818	   and release the requested resources included in the <Bandwidth>
1819	   parameter.  This can be achieved by subtracting the amount of RMD
1820	   traffic class requested resources, included in the <Bandwidth>
1821	   parameter, from the total reserved amount of resources stored in the
1822	   RMD traffic class state.  The value of the <Time Lag> parameter of
1823	   the "PHR_Resource_Release" container is used during the release
1824	   procedure as explained in Section 4.6.1.5.

1826	   The intra-domain tear RESERVE (RMD-QSPEC) message is received and
1827	   processed by the QNE Egress node.  The "RMD QoS Description" and the
1828	   "PHR RMD-QOSM control " container (and if available the "PDR RMD-QOSM
1829	   control information" container) are read and processed by the RMD QoS
1830	   node.

1832	   The value of the <Bandwidth>
1833	   parameter of the "RMD QoS Description" field and the value of the
1834	   <Time Lag> field of the PHR container MUST be used by the RMD release
1835	   procedure.  This can be achieved by subtracting the amount of RMD
1836	   traffic class requested resources, included in the <Bandwidth>
1837	   parameter, from the total reserved amount of resources stored in the
1838	   RMD traffic class state.

1840	   The end-to-end RESERVE message is forwarded by the next hop (i.e.,
1841	   the QNE Egress) only if the intra-domain tear RESERVE (RMD-QSPEC)
1842	   message arrives at the QNE Egress node. Furthermore, the QNE Egress
1843	   MUST stop the marking process that was used to bypass the QNE
1844	   Interior nodes by reassigning the QoS-NSLP default NSLP-ID value to
1845	   the end-to-end RESERVE message, see Section 4.4.
1846	   Note that the above described procedure applies to the situation that
1847	   the QNE edges maintain a per flow QoS-NSLP reservation state. When
1848	   the QNE edges maintain aggregated QoS-NSLP reservation states the
1849	   RMD-QOSM functionality may start a RMD modification procedures (see
1850	   Section 4.6.1.4) that uses the explicit release procedure described
1851	   in this Section.

1853	4.6.1.5.2   Triggered by a marked RESPONSE or NOTIFY message

1855	   This RMD explicit release procedure can be triggered by either an
1856	   end-to-end RESPONSE message with a <M> marked PDR container (see
1857	   Section 4.6.1.2) an intra-domain RESPONSE message with a <S> marked
1858	   PDR container (see Section 4.6.1.6.1) or an end to end NOTIFY
1859	   message (see Section 4.6.1.6) with an INFO_SPEC object with the
1860	   following values:

1862	   Error Severity Class: 0x01 Informational
1863	   Error Code value: 0x05 Congestion situation

1865	   The RMD specific release procedure that is triggered by an
1866	   end-to-end RESPONSE message with a <M> marked PDR container (see
1867	   Section 4.6.1.2) can be terminated at any QNE edge
1868	   or any QNE Interior node using the <Max_Admitted Hops> field.

1870	   The RMD specific explicit release procedure that is terminated at a
1871	   QNE Interior (or QNE edge) node is denoted as RMD partial release
1872	   procedure.  This explicit release procedure can be used, for example,
1873	   during a RMD specific operation for unsuccessful reservation (see
1874	   Section 4.6.1.2). When the RMD QoS signaling model functionality of a
1875	   QNE Ingress node receives a <M> or <S> marked PDR container of type
1876	   "PDR_Reservation_Report" or "PDR_Congestion_Report", it MUST start an
1877	   RMD partial release procedure.  The QNE Ingress node generates an
1878	   intra-domain RESERVE (RMD-QSPEC) message.  Before generating this
1879	   message, the RMD-QOSM functionality is using the RMD traffic class
1880	   (PHR) resource units for a RMD release procedure.  This can be
1881	   achieved by subtracting the amount of RMD traffic class requested
1882	   resources from the total reserved amount of resources stored in the
1883	   RMD traffic class state.

1885	   When the generation of the intra-domain RESERVE (RMD-QSPEC) message
1886	   is triggered by an end-to-end NOTIFY message, which does not carry a
1887	   PDR container, but it carries an INFO_SPEC object with the following
1888	   values, then the intra-domain RESERVE(RMD-QSPEC) message MUST include
1889	   an <RMD QoS Description> field and a PHR container, (i.e.,
1890	   PHR_Resource_Release) and it MAY include a PDR container, (i.e.,
1891	   PDR_Release_Request). Note that this procedure is accomplished during
1892	   the severe congestion handling by proportional data packet marking,
1893	   see Section 4.6.1.6.2.  The error code values carried by this NOTIFY
1894	   message are:

1896	   Error Severity Class: 0x01 Informational
1897	   Error Code value: 0x05 Congestion situation

1899	   Furthermore, note that the tear intra-domain RESERVE message is
1900	   generated as it is shown in Figure 12, when it is triggered by either
1901	   a NOTIFY message or RESPONSE message that do not carry a PDR
1902	   container, but the INFO_SPEC object includes one of the following
1903	   error codes, see Section 4.7:

1905	     0x01 - Informational
1906	     0x03 - Protocol error
1907	     0x04 - Transient Failure
1908	     0x05 - Permanent failure
1909	     0x06 - QoS-related Error

1911	   An example of this message exchange can be seen in Figure 12.
1912	   Most of the non-default values of the objects contained in the
1913	   tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE
1914	   Ingress node in the same way as described in Section 4.6.1.1.

1916	   The following objects MUST be used and/or set differently:

1918	   *  The flag REPLACE MUST be set to FALSE;

1920	   *  The value of the <M> parameter of the PHR container MUST be set
1921	      to "1".

1923	   *  the value of the <S> parameter of the
1924	      PHR container MUST be set to "1".

1926	   *  The RESERVE message MAY include a PDR container.

1928	QNE (Ingress)     QNE (Interior)         QNE (Interior)    QNE (Egress)
1929	NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
1930	    |                  |                  |                  |
1931	    | NOTIFY           |                  |                  |
1932	    |<-------------------------------------------------------|
1933	    |RESERVE(RMD-QSPEC:Tear=1,M=1,S=SET)  |                  |
1934	    | ---------------->|RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET) |
1935	    |                  |                  |                  |
1936	    |                  |----------------->|                  |
1937	    |                  |           RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET)
1938	    |                  |                  |----------------->|

1940	   Figure 12: Basic operation during RMD explicit release procedure
1941	   triggered by NOTIFY used by the RMD-QOSM

1943	   When the generation of the intra-domain RESERVE(RMD-QSPEC) message
1944	   is triggered by an end-to-end RESPONSE(PDR) message then this
1945	   generated intra-domain RESERVE(RMD-QSPEC) message MUST include a
1946	   <RMD QoS Description> field and a PDR container, (i.e.,
1947	   PHR_Resource_Release) and it MAY include a PDR container, (i.e.,
1948	   PDR_Release_Request).  An example of this operation can be seen in
1949	   Figure 13.

1951	   Most of the non-default values of the objects contained in the
1952	   tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE
1953	   Ingress node in the same way as described in Section 4.6.1.1.

1955	   The following objects MUST be used and/or set differently:

1957	   *  The flag REPLACE MUST be set to FALSE;

1959	   *  The value of the <M> parameter of the PHR container MUST be set
1960	      to "1".

1962	   *  The RESERVE message MAY include a PDR container.

1964	   *  When the tear intra-domain RESERVE message is triggered by an
1965	      intra-domain RESPONSE(RMD-QSPEC) message, then the value of the
1966	      <Max Admitted Hops> parameter of the PDR container included in the
1967	      received <M> or <S> marked intra-domain RESPONSE(PDR) message
1968	      MUST be included in the <Max Admitted Hops> parameter of the PDR
1969	      container of the RESERVE message. Note that this procedure is
1970	      applied for the severe congestion handling by the RMD-QOSM refresh
1971	      procedure (see Section 4.6.1.6.1). The tear intra-domain RESERVE
1972	      message propagates in this case until the QNE egress (similar to
1973	      Figure 12).

1975	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
1976	                                     Node that marked
1977	                                    PHR_Resource_Request
1978	                                       <PHR> object
1979	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1980	    |                    |                   |                    |
1981	    |                    |                   |                    |
1982	    | RESPONSE (RMD-QSPEC: M=1)              |
1983	    |<------------------------------------------------------------|
1984	RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max_Admitted Hops>)
1985	    |------------------->|                   |                    |
1986	    |                    |                   |                    |

1988	   Figure 13: Basic operation during RMD explicit release procedure
1989	   Triggered by RESPONSE used by the RMD-QOSM

1991	   Any QNE edge or QNE Interior node that receives the
1992	   "RMD QoS Description" field and the PHR container MUST identify the
1993	   traffic class state (PHB), using the <PHB Class> parameter, and
1994	   release the requested resources included in the <Bandwidth> field.
1995	   This can be achieved by subtracting the amount of RMD traffic class
1996	   requested resources, included in the <Bandwidth> field, from the
1997	   total reserved amount of resources stored in the RMD traffic class
1998	   state.  The value of the <Time Lag> parameter of the PHR field
1999	   is used during the release procedure as explained in Section 4.6.1.5.

2001	   The <Admitted Hops> value included in the PHR container is increased
2002	   by one.  If the value of <M> parameter of the "PHR_Resource_Release"
2003	   control information container is "1" and if the value of the <S>
2004	   parameter is set to "0" then the <Max_Admitted Hops> value included
2005	   in the PDR container MUST be compared with the calculated <Admitted
2006	   Hops> value.  When these two values are equal then the intra-domain
2007	   RESERVE(RMD-QSPEC) has to be terminated and it will not be forwarded
2008	   downstream.  The reason of this is that the QNE node that is
2009	   currently processing this message was the last QNE node that
2010	   successfully processed the "RMD QoS Description" field and
2011	   PHR container of its associated initial reservation request (i.e.,
2012	   initial intra-domain RESERVE(RMD-QSPEC) message).  Its next QNE
2013	   downstream node was unable to successfully process the initial
2014	   reservation request, therefore, this QNE node marked the <M>
2015	   parameter of the "PHR_Resource_Request" control information.  When
2016	   the values of the <M> and <S> parameters are set to "0", then this
2017	   message will not be terminated by a QNE Interior node, but it will be
2018	   forwarded in the downstream direction.  The QNE Egress node will
2019	   receive and process the PHR_Resource_Release control information.
2020	   Afterwards, the QNE Egress node MUST terminate the intra-domain
2021	   RESERVE(RMD-QSPEC) message.

2023	   Note that the above described procedure applies to the situation that
2024	   the QNE edges maintain a per flow QoS-NSLP reservation state. When
2025	   the QNE edges maintain aggregated QoS-NSLP reservation states the
2026	   RMD-QOSM functionality MAY start a RMD modification procedures (see
2027	   Section 4.6.1.4) that uses the explicit release procedure described
2028	   in this section.

2030	4.6.1.6. Severe congestion handling

2032	   This section describes the operation of the RMD-QOSM when a severe
2033	   congestion occurs within the Diffserv domain.

2035	   When a failure in a communication path, e.g., a router or a link
2036	   failure occurs, the routing algorithms will adapt to failures by
2037	   changing the routing decisions to reflect changes in the topology and
2038	   traffic volume.  As a result, the re-routed traffic will follow a new
2039	   path, which may result in overloaded nodes as they need to support
2040	   more traffic.  This may cause severe congestion in the communication
2041	   path.  In this situation the available resources, are not enough to
2042	   meet the required QoS for all the flows along the new path.
2043	   Therefore, one or more flows SHOULD be terminated, or forwarded in a
2044	   lower priority queue.

2046	   Interior nodes notify edge nodes by data marking or marking the
2047	   refresh messages.

2049	4.6.1.6.1 Severe congestion handling by the RMD-QOSM refresh procedure

2051	   The QoS-NSLP and RMD are able to cope with congested situations
2052	   using the refresh procedure, see Section 4.6.1.3. If the refresh is
2053	   not successful in an QNE Interior node, edge nodes are notified by
2054	   "S" marking the refresh messages and by including the percentage of
2055	   overload into the <Overload %> field in the "PHR_Refresh_Update"
2056	   container, carried by the intra-domain RESERVE message.
2057	   The intra-domain RESPONSE message that is sent by the QNE Egress
2058	   towards QNE Ingress will contain a PDR container with a
2059	   Parameter/Container ID = 10, i.e., "PDR_Congestion_Report". The
2060	   values of the <S> and <Overload %> fields of this container should
2061	   be set equal to the values of the <S> and <Overload %> fields,
2062	   respectively, carried by the "PHR_Refresh_Update" message.  Part of
2063	   the flows, corresponding to the <Overload %>, are terminated, or
2064	   forwarded in a lower priority queue.  The flows can be terminated by
2065	   the RMD release procedure described in Section 4.6.1.5.  Note that
2066	   the above described functionality applies to the RMD reservation-
2067	   based and to the NSIS measurement-based admission control schemes.
2068	   Furthermore, note that the above functionalities apply also for the
2069	   scenario where the QNE Edge nodes maintain either per flow QoS-NSLP
2070	   reservation states or aggregated QoS-NSLP reservation states.

2072	   In general, relying on the soft state refresh mechanism solves the
2073	   congestion within the time frame of the refresh period. If this
2074	   mechanism is not fast enough additional functions should be used,
2075	   which are described in Section 4.6.1.6.2.

2077	4.6.1.6.2 Severe congestion handling by proportional data packet marking

2079	   This severe congestion handling method requires the following
2080	   functionalities.

2082	4.6.1.6.2.1 Operation in the Interior nodes

2084	   The Interior node detecting severe congestion remarks data packets
2085	   passing the node. For this remarking, two additional DSCPs can be
2086	   allocated for each traffic class.  One DSCP MAY be used to indicate
2087	   that the packet passed a congested node. This type of DSCP is denoted
2088	   in this document as "affected DSCP" and is used to indicate that a
2089	   packet passed through a severe congested node. The use of this DSCP
2090	   type eliminates the possibility that, due to e.g. ECMP (Equal Cost
2091	   Multiple Paths) enabled routing, the egress node either does not
2092	   detect packets passed a severe congested node or erroneously detects
2093	   packets that actually did not pass the severe congested node.  Note
2094	   that this type of DSCP MUST only be used if all the nodes within the
2095	   RMD domain are configured to use it. Otherwise, this type of DSCP
2096	   MUST not be applied. The other DSCP MUST be used to indicate the
2097	   degree of congestion by marking the bytes proportionally to the
2098	   degree of congestion. This type of DSCP is denoted in this document
2099	   as "encoded DSCP".

2101	   Note that in this document the terms marked packets or marked bytes
2102	   refer to the "encoded DSCP". The terms unmarked packets or unmarked
2103	   bytes are representing the packets or the bytes belonging to these
2104	   packets that their DSCP is either the "affected DSCP" or the original
2105	   DSCP. Furthermore, in the algorithm described below it is considered
2106	   that the router may drop received packets. The counting/measuring of
2107	   marked or unmarked bytes described in this section is accomplished
2108	   within measurement periods. All nodes within a RMD domain use the
2109	   same, fixed measurement interval, say T seconds, which MUST be
2110	   pre-configured.

2112	   It is RECOMMENDED that the total number of additional DSCPs needed
2113	   for severe congestion handling within an RMD domain should be as low
2114	   as possible and it should not exceed the limit of 16. One possibility
2115	   to reduce the number of used DSCPs is to use only the "encoded DSCP"
2116	   and not to use "affected DSCP" marking. Another possible solution is
2117	   for example, to allocate one DSCP for severe congestion indication
2118	   for each of the AF classes, independently from their dropping
2119	   precedence. Assuming 4 AF classes and 1 EF class, and using one DSCP
2120	   per traffic class then the number of DSCPs used in this situation for
2121	   severe congestion is 5. If two additional DSCP's are used then the
2122	   total number in this case is 10.

2124	   An example of a remarking procedure can be found in Appendix A.1.1.

2126	4.6.1.6.2.2 Operation in the Egress nodes

2128	   The QNE Egress node applies a predefined policy to solve the severe
2129	   congestion situation, by selecting a number of inter-domain (
2130	   end-to-end) flows that SHOULD be terminated, or forwarded in a lower
2131	   priority queue.

2133	   When the RMD domain does not use the "affected DSCP"
2134	   marking then the egress MUST generate an ingress/egress pair
2135	   aggregated state, for each ingress and for each supported PHB. This
2136	   is because the edges must be able to detect in which ingress/egress
2137	   pair a severe congestion occurs. When the RMD domain supports the
2138	   "affected DSCP" marking then the egress is able to detect all flows
2139	   that are affected by the severe congestion situation. Therefore, when
2140	   the RMD domain supports the "affected DSCP" marking, then the Egress
2141	   MAY not generate and maintain the ingress/egress pair aggregated
2142	   states.

2144	   The ingress/egress pair aggregated state can be derived by
2145	   detecting, which flows are using the same PHB and are sent by the
2146	   same Ingress (via the per flow end-to-end QoS-NSLP states).

2148	   Some flows, belonging to the same PHB traffic class might get
2149	   other priority than other flows belonging to the same PHB traffic
2150	   class. This difference in priority can be notified to the egress and
2151	   ingress nodes either by the RESERVE message that carries the QSPEC
2152	   associated with the end-to-end QoS model, i.e., <Preemption Priority>
2153	   & <Defending Priority> parameter, or by using a local defined policy.

2155	   The terminated flows are selected from the flows having the same PHB
2156	   traffic class as the PHB of the marked (as "encoded DSCP") and
2157	   "affected DSCP" (when applied in the complete RMD domain) packets and
2158	   (when the ingress/egress pair aggregated states are available).that
2159	   are belonging to the same ingress/egress pair aggregate.

2161	   For flows associated with the same PHB traffic class the priority of
2162	   the flow plays a significant role. An example of calculating the
2163	   number of flows associated with each priority class that have to be
2164	   terminated is explained in Appendix A.1.2.

2166	   For the flows (sessions) that have to be terminated, the QNE Egress
2167	   node generates and sends a NOTIFY message to the QNE Ingress node
2168	   (its upstream stateful QoS-NSLP peer) to indicate the severe
2169	   congestion in the communication path.

2171	   The non-default values of the objects contained in the NOTIFY
2172	   message MUST be set by the QNE Egress node as follows:

2174	   *  the values of the <INFO_SPEC> object is set by the standard
2175	      QoS-NSLP protocol functions.

2177	   * the INFO_SPEC object SHOULD include information that notifies that
2178	     the end-to-end flow SHOULD be terminated. This information is as
2179	     follows:

2181	     Error Severity Class: 0x01 Informational
2182	     Error Code value: 0x05 Congestion situation

2184	   The selection and notification process of the end-to-end is identical
2185	   for the scenarios where the QNE Edges maintain per-flow or aggregated
2186	   QoS-NSLP reservation states.

2188	   Furthermore, note that QNE egress SHOULD restore the original DSCP
2189	   values of the remarked packets, otherwise multiple actions for the
2190	   same event might occur. However, this value MAY not be restored if
2191	   there is an SLA agreement between domains that a downstream domain
2192	   handles the remarking problem.

2194	   4.6.1.6.2.3 Operation in the Ingress nodes

2196	   Upon receiving the (end-to-end) NOTIFY message, the QNE Ingress node
2197	   resolves the severe congestion by a predefined policy, e.g., by
2198	   refusing new incoming flows (sessions), terminating the affected and
2199	   notified flows (sessions), or shifting them to an alternative RMD
2200	   traffic class (PHB). This operation is depicted in Figure 14, where
2201	   the QNE Ingress, for each flow (session) to be terminated, receives a
2202	   NOTIFY message. The NOTIFY message SHOULD include an INFO-SPEC object
2203	   with the following information:

2205	   Error Severity Class: 0x1 Informational
2206	   Error Code value: 0x05 Congestion situation
2207	   When the QNE Ingress node receives the end-to-end NOTIFY message, it
2208	   associates this NOTIFY message with its bound intra-domain session,
2209	   via the BOUND_SESSION_ID information included in the end-to-end per-
2210	   flow QoS-NSLP state. The QNE Ingress uses the operation described in
2211	   Section 4.6.1.5.2 to terminate the intra-domain session.

2213	 QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)

2215	  user  |                  |                 |                  |
2216	  data  |  user data       |                 |                  |
2217	 ------>|----------------->|     user data   | user data        |
2218	        |                  |---------------->S(# marked bytes)  |
2219	        |                  |                 S----------------->|
2220	        |                  |                 S(# unmarked bytes)|
2221	        |                  |                 S----------------->|Term.
2222	        |                 NOTIFY                                |flow?
2223	        |<----------------|------------------|------------------|YES
2224	        |RESERVE(RMD-QSPEC:Tear=1,M=1,S=SET) |                  |
2225	        | --------------->|RESERVE(RMD-QSPEC:T=1, M=1,S=SET)    |
2226	        |                 |                  |                  |
2227	        |                 |----------------->|                  |
2228	        |                 |       RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET)
2229	        |                 |                  |----------------->|

2231	   Figure: 14  RMD severe congestion handling

2233	   Note that the above functionality applies to the RMD reservation-
2234	   based and to both measurement-based admission control methods (i.e.,
2235	   congestion notification based on probing and the NSIS measurement-
2236	   based admission control). The above functionality applies also for
2237	   the scenario where the QNE Edge nodes maintain either per flow QoS-
2238	   NSLP reservation states or aggregated QoS-NSLP reservation states.

2240	   In the case that the edges support aggregated QoS-NSLP reservation
2241	   states the following actions take place. When the QNE Ingress node
2242	   receives the end-to-end  NOTIFY message, it associates the NOTIFY
2243	   message with the intra-domain aggregated QoS-NSLP state via the
2244	   BOUND_SESSION_ID information included in the end-to-end per-flow QoS-
2245	   NSLP state. The QNE Ingress node should reduce the bandwidth
2246	   associated with the end-to-end flow from the aggregated bandwidth
2247	   associated with its bound aggregated QoS-NSLP reservation state. This
2248	   is accomplished by triggering the RMD modification for aggregated
2249	   reservations procedure described in Section 4.6.1.4.

2251	4.6.1.7 Admission control using congestion notification based on probing

2253	   The congestion notification function based on probing can be used to
2254	   implement a simple measurement-based admission control within a
2255	   Diffserv domain.  At interior nodes along the data path congestion
2256	   notification thresholds are set in the measurement based admission
2257	   control function for the traffic belonging to different PHBs. These
2258	   interior nodes are not NSIS aware nodes.

2260	4.6.1.7.1 Operation in Ingress nodes

2262	   When an end-to-end reservation request (RESERVE) arrives at the
2263	   Ingress node (QNE), see Figure 15, it is processed based on the
2264	   procedures defined by the end-to-end QoS model.

2266	   If the ingress is configured to neither process this type of
2267	   admission control nor any other admission control scheme specified in
2268	   the previous sections, then the <NON QOSM Hop> parameter that is
2269	   carried by the end-to-end QSpec SHOULD be set.

2271	   The DSCP field of the GIST datagram message that is used to transport
2272	   this probe RESERVE message, SHOULD be marked with the same value of
2273	   DSCP as the data path packets associated with the same session.

2275	   When (end-to-end) RESPONSE message is received by the Ingress node,it
2276	   will be processed based on the procedures defined by the end-to-end
2277	   QoS model.

2279	4.6.1.7.2 Operation in Interior nodes

2281	   These Interior nodes are not needed to be NSIS aware nodes and they
2282	   do not need to process NSIS functionality of NSIS messages. Using
2283	   standard functionalties congestion notification thresholds are set
2284	   for the traffic belonging to different PHBs, see Section 4.3.2.

2286	   The end-to-end RESERVE message, see Figure 15, is used as a probe
2287	   packet.

2289	   The DSCP field of the GIST message carrying the RESERVE message will
2290	   be re-marked when the corresponding "congestion notification"
2291	   threshold is exceeded, see Section 4.3.2. Note that when the data
2292	   rate is higher than the congestion notification threshold then also
2293	   the data packets are remarked. An example of the detailed operation
2294	   of this procedure is given in Appendix A.2.1.

2296	4.6.1.7.3 Operation in Egress nodes

2298	   As emphasised in Section 4.6.1.6.2.2, the egress node, by using the
2299	   per flow end-to-end QoS-NSLP states, can derive which flows are using
2300	   the same PHB and are sent by the same ingress.

2302	   For each ingress, the egress SHOULD generate an ingress/egress pair
2303	   aggregated state for each supported PHB.

2305	   In Appendix A.2.2 an example is described how and when a (probe)
2306	   RESERVE message that arrives at the egress, is admitted or rejected.

2308	   If the request is rejected then the Egress node SHOULD
2309	   generate an (end-to-end) RESPONSE message to notify that the
2310	   reservation is unsuccesfull. In particular it will generate an
2311	   INFO_SPEC object of:

2313	     Error Severity Class: 0x04, Transient failure
2314	     Error Code value: 0x07 Total reservation failure

2316	   The QSpec that was carried by the end to end RESERVE belonging to
2317	   the same session as this end to end RESPONSE is included in this
2318	   message. The parameters included in the QSPEC <QoS Reserved> object
2319	   are copied from the original <QoS Desired> values. The "E" flag
2320	   associated with the <QoS Reserved> object and the "E" flag associated
2321	   with <Bandwidth> parameter are also set. This RESPONSE message will
2322	   be sent to the Ingress node and it will be processed based on the
2323	   end-to-end QoS model.

2325	   Note that QNE egress SHOULD restore the original DSCP values of the
2326	   remarked packets, otherwise multiple actions for the same event might
2327	   occur. However, this value MAY not be restored if there is an
2328	   SLA agreement between domains that a downstream domain handles the
2329	   remarking problem.

2331	QNE (Ingress)          Interior          Interior       QNE (Egress)
2332	                    (not NSIS aware) (not NSIS aware)
2333	  user  |                  |                 |                  |
2334	  data  |  user data       |                 |                  |
2335	 ------>|----------------->|     user data   |                  |
2336	        |                  |---------------->| user data        |
2337	        |                  |                 |----------------->|
2338	  user  |                  |                 |                  |
2339	  data  |  user data       |                 |                  |
2340	 ------>|----------------->|     user data   | user data        |
2341	        |                  |---------------->S(# marked bytes)  |
2342	        |                  |                 S----------------->|
2343	        |                  |                 S(# unmarked bytes)|
2344	        |                  |                 S----------------->|
2345	        |                  |                 S                  |
2346	RESERVE |                  |                 S                  |
2347	------->|                  |                 S                  |
2348	        |----------------------------------->S                  |
2349	        |                  |           RESERVE(re-marked DSCP in GIST)
2350	        |                  |                 S----------------->|
2351	        |                  |RESPONSE(unsuccessful INFO-SPEC)    |
2352	        |<------------------------------------------------------|
2353	 RESPONSE(unsuccessful INFO-SPEC)            |                  |
2354	 <------|                  |                 |                  |

2356	   Figure: 15  Using RMD congestion notification function for admission
2357	               control based on probing

2359	4.6.2  Bi-directional operation

2361	   RMD assumes asymmetric routing by default.  Combined sender-receiver
2362	   initiated reservation cannot be efficiently done in the RMD domain
2363	   because upstream NTLP states are not stored in Interior routers.
2364	   Therefore, the bi-directional operation SHOULD be performed by two
2365	   sender-initiated reservations (sender&sender).  We assume that the
2366	   QNE edge nodes are common for both upstream and downstream
2367	   directions, therefore, the two reservations/sessions can be bound at
2368	   the QNE edge nodes.

2370	   This bi-directional sender&sender procedure can then be applied
2371	   between the QNE edges (QNE Ingress and QNE Egress) nodes of the RMD
2372	   QoS signaling model.  In the situation a security association
2373	   exists between the QNE Ingress and QNE Egress nodes (see Figure 15),
2374	   and the QNE Ingress node has the required <Bandwidth> parameters
2375	   for both directions, i.e., QNE Ingress towards QNE Egress and QNE
2376	   Egress towards QNE Ingress, then the QNE Ingress MAY include both
2377	   <Bandwidth> parameters (needed for both directions) into the
2378	   RMD-QSPEC within a RESERVE message.  In this way the QNE Egress node
2379	   is able to use the QoS parameters needed for the "Egress towards
2380	   Ingress" direction (QoS-2).  The QNE Egress is then able to create a
2381	   RESERVE with the right QoS parameters included in the QSPEC, i.e.,
2382	   RESERVE (QoS-2). Both directions of the flows are bound by inserting
2383	   the <BOUND_SESSION_ID> object at the QNE Ingress and QNE Egress.

2385	     |------ RESERVE (QoS-1, QoS-2)----|
2386	     |                                 V
2387	     |           Interior/stateless QNEs
2388	                 +---+     +---+
2389	        |------->|QNE|-----|QNE|------
2390	        |        +---+     +---+     |
2391	        |                            V
2392	      +---+                        +---+
2393	      |QNE|                        |QNE|
2394	      +---+                        +---+
2395	         ^                           |
2396	      |  |       +---+     +---+     V
2397	      |  |-------|QNE|-----|QNE|-----|
2398	      |          +---+     +---+
2399	   Ingress/                         Egress/
2400	   statefull QNE                    statefull QNE
2401	                                     |
2402	   <--------- RESERVE (QoS-2) -------|

2404	   Figure 16: The bi-directional reservation scenario in the RMD domain

2406	   A bidirectional reservation, within the RMD domain, is indicated by
2407	   the PHR <B> and PDR <B> flags, which are set in all messages.

2409	   In this case two BOUND_SESSION_ID objects SHOULD be used.
2410	   The first BOUND_SESSION_ID object is applied in the following way.
2411	   The end-to-end RESERVE SHOULD contain in the BOUND_SESSION_ID the
2412	   SESSION_ID of its bound intra-domain session. Furthermore, if the QNE
2413	   Edge nodes maintain intra-domain per flow QoS-NSLP reservation states
2414	   then the value of Binding_Code MUST be set to 0x01 (Tunnel and end-
2415	   to-end sessions). If the QNE Edge nodes maintain intra-domain
2416	   aggregated QoS-NSLP reservation states then the value of Binding_Code
2417	   MUST be set to 0x03 (Aggregate sessions).

2419	   The intra-domain RESERVE SHOULD contain in the BOUND_SESSION_ID the
2420	   SESSION_ID of its bound end to end session. The value of the
2421	   Binding_Code MUST be set to 0x01 (Tunnel and end-to-end sessions).

2423	   The SESSION_ID field of the second BOUND_SESSION_ID object depends on
2424	   the direction of the message. An upstream RMD QoS-NSLP message SHOULD
2425	   contain the SESSION_ID of the bound downstream end-to-end flow. A
2426	   downstream RMD QoS-NSLP message SHOULD contain the SESSION_ID of the
2427	   bound upstream end-to-end flow. In both cases the value of the
2428	   Binding_Code associated with this BOUND_SESSION_ID object SHOULD be
2429	   equal to 0x02.

2431	   If no security association exists between the QNE Ingress and QNE
2432	   Egress nodes the bi-directional reservation for the sender&sender
2433	   scenario in the RMD domain SHOULD use the scenario specified in
2434	   [QoS-NSLP] as "Bi-directional reservation for sender&sender
2435	   scenario".

2437	   In the following sections it is considered that the QNE
2438	   edge nodes are common for both upstream and downstream directions
2439	   and therefore, the two reservations/sessions can be bound at the
2440	   QNE edge nodes.  Furthermore, it is considered that a security
2441	   association exists between the QNE Ingress and QNE Egress nodes,
2442	   and the QNE Ingress node has the required <Bandwidth> parameters
2443	   for both directions, i.e., QNE Ingress towards QNE Egress and
2444	   QNE Egress towards QNE Ingress.

2446	4.6.2.1 Successful and unsuccessful reservations

2448	   This section describes the operation of the RMD-QOSM where a RMD
2449	   bi-directional reservation operation is either successfully or
2450	   unsuccessfully accomplished.

2452	   The bi-directional successful reservation is similar to a
2453	   combination of two unidirectional successful reservations that are
2454	   accomplished in opposite directions, see Figure 17. The main
2455	   differences of the bi-directional successful reservation procedure
2456	   with the combination of two unidirectional successful reservations
2457	   accomplished in opposite directions are as follows.  The intra-
2458	   domain RESERVE message sent by the QNE Ingress node towards the QNE
2459	   Egress node, is denoted in Figure 17 as RESERVE (RMD-QSPEC):
2460	   "forward".  The main differences between the RESERVE (RMD-QSPEC):
2461	   "forward" message used for the bi-directional successful reservation
2462	   procedure and a RESERVE (RMD-QSPEC) message used for the
2463	   unidirectional successful reservation are as follows:

2465	   *  Two BOUND_SESSION_ID objects MUST be used. The first
2466	      BOUND_SESSION_ID object contains the SESSION_ID of its bound
2467	      End-to-end session. The value of the Binding_Code MUST be set to
2468	      0x01 (Tunnel and end-to-end sessions). The SESSION_ID field of
2469	      the second BOUND_SESSION_ID object SHOULD contain the SESSION_ID
2470	      of the bound "reverse" end-to-end flow. The value of the
2471	      Binding_Code associated with this BOUND_SESSION_ID object SHOULD
2472	      be equal to 0x02.

2474	   *  the RII object MUST NOT included in the message. This is because
2475	      no RESPONSE message is expected to arrive.

2477	   *  the <B> bit of the PHR container indicates a bi-directional
2478	      reservation and it MUST be set to "1".

2480	   *  the PDR container is also included into the RESERVE(RMD-QSPEC):
2481	      "forward" message. The value of the Parameter/Container ID is
2482	     "4", i.e., "PDR_Reservation_Request".  Note that the response PDR
2483	      container sent by a QNE Egress to a QNE Ingress node is not
2484	      carried by an end-to-end RESPONSE message, but it is carried by an
2485	      intra-domain RESERVE message that is sent by the QNE Egress node
2486	      towards the QNE Ingress node (denoted in Figure 16 as
2487	      RESERVE(RMD-QSPEC):"reverse").

2489	   *  the <B> PDR bit indicates a bi-directional reservation and is set
2490	      to "1".

2492	   *  the <PDR Reverse Requested Resources> field specifies the
2493	      requested bandwidth that has to be used by the QNE Egress node to
2494	      initiate another intra-domain RESERVE message in the reverse
2495	      direction.

2497	   The RESERVE(RMD-QSPEC):"reverse" message is initiated by the QNE
2498	   Egress node at the moment that the RESERVE(RMD-QSPEC):"forward"
2499	   message is successfully processed by the QNE Egress node.
2500	   The main differences between the RESERVE(RMD-QSPEC):"reverse"
2501	   message used for the bi-directional successful reservation procedure
2502	   and a RESERVE(RMD-QSPEC) message used for the unidirectional
2503	   successful reservation are as follows:

2505	QNE (Ingress)   QNE (int.)    QNE (int.)    QNE (int.)   QNE (Egress)
2506	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
2507	    |                |               |               |              |
2508	    |                |               |               |              |
2509	    |RESERVE(RMD-QSPEC)              |               |              |
2510	    |"forward"       |               |               |              |
2511	    |                |    RESERVE(RMD-QSPEC):        |              |
2512	    |--------------->|    "forward"  |               |              |
2513	    |                |------------------------------>|              |
2514	    |                |               |               |------------->|
2515	    |                |               |               |              |
2516	    |                |               |RESERVE(RMD-QSPEC)            |
2517	    |      RESERVE(RMD-QSPEC)        | "reverse"     |<-------------|
2518	    |      "reverse"   |             |<--------------|              |
2519	    |<-------------------------------|               |              |

2521	      Figure 17: Intra-domain signaling operation for successful
2522	                 bi-directional reservation

2524	   *  two BOUND_SESSION_ID objects SHOULD be used.
2525	      The first BOUND_SESSION_ID object contains the SESSION ID of its
2526	       bound end to end session. The value of the Binding_Code = 0x01
2527	      (Tunnel and end-to-end sessions).   The SESSION_ID field of
2528	      the second BOUND_SESSION_ID object SHOULD contain the SESSION_ID
2529	      of the bound "forward" end-to-end flow. The value of the
2530	      Binding_Code associated with this BOUND_SESSION_ID object SHOULD
2531	      be equal to 0x02.

2533	   *  the RII object is not included in the message. This is because no
2534	      RESPONSE message is expected to arrive;

2536	   *  the value of the <Bandwidth> parameter is set equal to the value
2537	      of the <PDR Reverse Requested Resources> field included in the
2538	      RESERVE(RMD-QSPEC):"forward" message that triggered the
2539	      generation of this RESERVE(RMD-QSPEC): "reverse" message;

2541	   *  the <B> bit of the PHR container indicates a bi-directional
2542	      reservation and is set to "1";

2544	   *  the PDR container is included into the
2545	      RESERVE(RMD-QSPEC):"reverse" message.  The value of the
2546	      Parameter/Container ID is "7", i.e., "PDR_Reservation_Report";

2548	   *  the <B> PDR bit indicates a bi-directional reservation and is
2549	      set to "1".

2551	   Figure 18 and Figure 19 show the flow diagrams used in case of a
2552	   unsuccessful bi-directional reservation.  In Figure 18 it
2553	   is considered that the QNE that is not able to support the
2554	   requested <Bandwidth> is located in the direction QNE Ingress
2555	   towards QNE Egress.  In Figure 19 it is considered that the
2556	   QNE that is not able to support the requested <Bandwidth> is
2557	   located in the direction QNE Egress towards QNE Ingress.

2559	   The main differences between the bi-directional unsuccessful
2560	   procedure shown in Figure 18 and the bi-directional successful
2561	   procedure are as follows:

2563	   *  the QNE node that is not able to reserve resources for a
2564	      certain request is located in the "forward" path, i.e., path
2565	      from QNE Ingress towards the QNE Egress.

2567	   *  the QNE node that is not able to support the requested
2568	      <Bandwidth> it MUST mark the <M> bit, i.e., set to value "1", of
2569	      the RESERVE(RMD-QSPEC): "forward".

2571	   The operation for this type of unsuccessful bi-directional
2572	   reservation is similar to the operation for unsuccessful uni-
2573	   directional reservation shown in Figure 9.  The main difference
2574	   is that the QNE Egress generates an intra-domain (local)
2575	   RESPONSE(PDR) message that is sent towards QNE Ingress node.

2577	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
2578	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
2579	    |                |             |              |               |
2580	    |RESERVE(RMD-QSPEC):           |              |               |
2581	    |  "forward"     |  RESERVE(RMD-QSPEC):       |               |
2582	    |--------------->|  "forward"  |              M RESERVE(RMD-QSPEC):
2583	    |                |--------------------------->M  "forward-M marked"
2584	    |                |             |              M-------------->|
2585	    |                |           RESPONSE(PDR)    M               |
2586	    |                |        "forward - M marked"M               |
2587	    |<------------------------------------------------------------|
2588	    |RESERVE(RMD-QSPEC)            |              M               |
2589	    |"forward - T tear"            |              M               |
2590	    |---------------->             |              M               |

2592	   Figure 18: Intra-domain signaling operation for unsuccessful
2593	              bi-directional reservation (rejection on path QNE(Ingress)
2594	              towards QNE(Egress))

2596	   The main differences between the bi-directional unsuccessful
2597	   procedure shown in Figure 19 and the in bi-directional successful
2598	   procedure are as follows:

2600	   *  the QNE node that is not able to reserve resources for a
2601	      certain request is located in the "reverse" path, i.e., path
2602	      from QNE Egress towards the QNE Ingress.

2604	   *  the QNE node that is not able to support the requested
2605	      <Bandwidth> it MUST mark the <M> bit, i.e., set to value "1",
2606	      the RESERVE(RMD-QSPEC):"reverse".

2608	   *  the QNE Ingress uses the information contained in the received
2609	      PHR and PDR containers of the RESERVE(RMD-QSPEC): "reverse" and
2610	      generates a tear intra-domain (local) RESERVE(RMD-QSPEC):
2611	      "forward - T tear" message.  This message carriers a
2612	      "PHR_Release_Request" and a "PDR_Release_Request" control
2613	      information.  This message is sent to QNE Egress node.
2614	      The QNE Egress node by using the information contained in the
2615	      "PHR_Release_Request" and the "PDR_Release_Request" control
2616	      info containers it generates a RESERVE(RMD-QSPEC):"reverse - T
2617	      tear" message that is sent towards the QNE Ingress node.

2619	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
2620	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
2621	    |                |                |                |              |
2622	    |RESERVE(RMD-QSPEC)               |                |              |
2623	    |"forward"       |  RESERVE(RMD-QSPEC):            |              |
2624	    |--------------->|  "forward"     |           RESERVE(RMD-QSPEC): |
2625	    |                |-------------------------------->|"forward"     |
2626	    |                |   RESERVE(RMD-QSPEC):           |------------->|
2627	    |                |    "reverse"   |                |              |
2628	    |                |              RESERVE(RMD-QSPEC) |              |
2629	    |    RESERVE(RMD-QSPEC):          M      "reverse" |<-------------|
2630	    |   "reverse - M marked"          M<---------------|              |
2631	    |<--------------------------------M                |              |
2632	    |                |                M                |              |
2633	    |RESERVE(RMD-QSPEC):              M                |              |
2634	    |"forward - T tear"               M                |              |
2635	    |--------------->|  RESERVE(RMD-QSPEC):            |              |
2636	    |                |  "forward - T tear"             |              |
2637	    |                |-------------------------------->|              |
2638	    |                |                M                |------------->|
2639	    |                |                M             RESERVE(RMD-QSPEC):
2640	    |                |                M             reverse - T tear" |
2641	    |                |                M                |<-------------|

2643	   Figure 19: Intra-domain signaling normal operation for unsuccessful
2644	             bi-directional reservation (rejection on path QNE(Egress)
2645	             towards QNE(Ingress)

2647	4.6.2.2 Refresh reservations

2649	   This section describes the operation of the RMD-QOSM where a RMD
2650	   bi-directional refresh reservation operation is accomplished.

2652	   The refresh procedure in case of RMD reservation-based method
2653	   follows a similar scheme as the successful reservation procedure,
2654	   described in Section 4.6.2.1, and depicted in Figure 17 and the
2655	   way of how the refresh process of the reserved resources is
2656	   maintained, is similar to the refresh process used for the intra-
2657	   domain uni-directional reservations (see Section 4.6.1.3).

2659	   Note that the RMD traffic class refresh periods used by the bound bi-
2660	   directional sessions MUST be equal in all QNE edge and QNE Interior
2661	   nodes.

2663	   The main differences between the RESERVE(RMD-QSPEC):"forward"
2664	   message used for the bi-directional refresh procedure
2665	   and a RESERVE(RMD-QSPEC):"forward" message used for the bi-
2666	   directional successful reservation procedure are as follows:

2668	   *  the value of the Parameter/Container ID of the PHR container is
2669	      "2", i.e., "PHR_Refresh_Update".

2671	   *  the value of the Parameter/Container ID of the PDR container is
2672	      "5", i.e., "PDR_Refresh_Request".

2674	   The main differences between the RESERVE(RMD-QSPEC):"reverse"
2675	   message used for the bi-directional refresh procedure and the RESERVE
2676	   (RMD-QSPEC): "reverse" message used for the bi-directional successful
2677	   reservation procedure are as follows:

2679	   *  the value of the Parameter/Container ID of the PHR container is
2680	      "2", i.e., "PHR_Refresh_Update".

2682	   *  the value of the Parameter/Container ID of the PDR container is
2683	      "8", i.e., "PDR_Refresh_Report".

2685	4.6.2.3 Modification of aggregated reservations

2687	   This section describes the operation of the RMD-QOSM where a RMD

2689	   In the case when the QNE edges maintain, for the RMD QoS model,
2690	   QoS-NSLP aggregated reservation states and if such an aggregated
2691	   reservation has to be modified (see Section 4.3.1) then similar
2692	   procedures to Section 4.6.1.4 are applied. In particular:

2694	   * When the modification request requires an increase of the reserved
2695	   resources, the QNE Ingress node MUST include the corresponding value
2696	   into the <Bandwidth> parameter of the "RMD QoS Description" field,
2697	   which is sent together with a "PHR_Resource_Request" control
2698	   information.  If a QNE edge or QNE Interior node is not able to
2699	   reserve the number of requested resources, then the
2700	   "PHR_Resource_Request" control information associated with the
2701	   <Bandwidth> parameter MUST be marked.  In this situation the RMD
2702	   specific operation for unsuccessful reservation will be applied (see
2703	   Section 4.6.2.1).

2705	   * When the modification request requires a decrease of the
2706	   reserved resources, the QNE Ingress node MUST include this value
2707	   into the <Bandwidth> parameter of the "RMD QoS Description" field.
2708	   Subsequently an RMD release procedure SHOULD be accomplished (see
2709	   Section 4.6.2.4).

2711	4.6.2.4 Release procedure

2713	   This section describes the operation of the RMD-QOSM where a RMD
2714	   bi-directional reservation release operation is accomplished.
2715	   The message sequence diagram used in this procedure is similar to the
2716	   one used by the successful reservation procedures, described in
2717	   Section 4.6.2.1, and depicted in Figure 17. However, the way of how
2718	   the release of the reservation is accomplished, is similar to the RMD
2719	   release procedure used for the intra-domain uni-directional
2720	   reservations (see Section 4.6.1.5 and Figure 18 and Figure 19).

2722	   The main differences between the RESERVE (RMD-QSPEC):
2723	   "forward" message used for the bi-directional release procedure
2724	   and a RESERVE (RMD-QSPEC): "forward" message used for the bi-
2725	   directional successful reservation procedure are as follows:

2727	   *  the value of the Parameter/Container ID of the PHR container is
2728	      "3", i.e."PHR_Release_Request";

2730	   *  the value of the Parameter/Container ID of the PDR container is
2731	      "6", i.e., "PDR_Release_Request";

2733	   The main differences between the RESERVE (RMD-QSPEC): "reverse"
2734	   message used for the bi-directional release procedure and the RESERVE
2735	   (RMD-QSPEC): "reverse" message used for the bi-directional successful
2736	   reservation procedure are as follows:

2738	   *  the value of the Parameter/Container ID of the PHR container is
2739	      "3", i.e., "PHR_Release_Request";

2741	   *  the PDR container is not included in the RESERVE (RMD-QSPEC):
2742	      "reverse" message.

2744	4.6.2.5 Severe congestion handling

2746	   This section describes the severe congestion handling operation used
2747	   in combination with bi-directional reservation procedures.
2748	   This severe congestion handling operation is similar to the one
2749	   described in Section 4.6.1.6.

2751	4.6.2.5.1 Severe congestion handling by the RMD-QOSM bi-directional
2752	          refresh procedure

2754	   This procedure is similar to the severe congestion handling procedure
2755	   described in Section 4.6.1.6.1. The difference is related to how the
2756	   refresh procedure is accomplished, see Section 4.6.2.2 and to how the
2757	   flows are terminated, see Section 4.6.2.4.

2759	4.6.2.5.2 Severe congestion handling by proportional data packet marking

2761	   This section describes the severe congestion handling by proportional
2762	   data packet marking when this is combined with a bi-directional
2763	   reservation procedure.

2765	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
2766	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
2767	user|                |             |              |               |
2768	data|    user        |             |              |               |
2769	--->|    data        | user data   |              |user data      |
2770	    |--------------->|             |              S               |
2771	    |                |--------------------------->S (#marked bytes)
2772	    |                |             |              S-------------->|
2773	    |                |             |              S(#unmarked bytes)
2774	    |                |             |              S-------------->|Term
2775	    |                |             |              S               |flow?
2776	    |                |          NOTIFY (PDR)      S               |YES
2777	    |<------------------------------------------------------------|
2778	    |RESERVE(RMD-QSPEC)            |              S               |
2779	    |"forward - T tear"            |              S               |
2780	    |--------------->|             |           RESERVE(RMD-QSPEC):|
2781	    |                |--------------------------->S"forward - T tear"
2782	    |                |             |              S-------------->|
2783	    |                |             |          RESERVE(RMD-QSPEC): |
2784	    |                |             |           "reverse - T tear" |
2785	    | RESERVE(RMD-QSPEC):          |              |<--------------|
2786	    |"reverse - T tear"            |<-------------S               |
2787	    |<-----------------------------|              S               |

2789	Figure 20: Intra-domain RMD severe congestion handling for
2790	           bi-directional reservation (congestion on path QNE(Ingress)
2791	           towards QNE(Egress))

2793	   This procedure is similar to the severe congestion handling procedure
2794	   described in Section 4.6.1.6.2. The main difference is related to the
2795	   location of the severe congested node, i.e., "forward" path (i.e.,
2796	   path between QNE Ingress towards QNE Egress) or "reverse" path (i.e.,
2797	   path between QNE Egress towards QNE Ingress). Another difference is
2798	   associated with the way of how the egress node selects the flows that
2799	   have to be terminated. Note that when a severe congestion situation
2800	   occurs on e.g.a forward path, and flows are terminated to solve the
2801	   severe congestion in forward path, then the reserved bandwidth
2802	   associated with the terminated bidirectional flows will also be
2803	   released. Therefore, a careful selection of the flows that have to be
2804	   terminated should take place. An example of such a selection is given
2805	   in Appendix A.3.1.

2807	   Furthermore, a special case of this operation is associated to the
2808	   severe congestion situation occuring simultaneously on the forward
2809	   and reverse paths. An example of this operation is given in Appendix
2810	    A.3.2.

2812	   Figure 20 shows the scenario where the severe congested node is
2813	   located in the "forward" path. This scenario is very similar to the
2814	   severe congestion handling scenario described in Section 4.6.1.6.2
2815	   and shown in Figure 14. The difference is related to the release
2816	   procedure, which is accomplished in the same way as described in
2817	   Section 4.6.2.4.

2819	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
2820	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
2821	user|                |                |           |               |
2822	data|    user        |                |           |               |
2823	--->|    data        | user data      |           |user data      |
2824	    |--------------->|                |           |               |
2825	    |                |--------------------------->|user data      |user
2826	    |                |                |           |-------------->|data
2827	    |                |                |           |               |--->
2828	    |                |                |           |               |user
2829	    |                |                |           |               |data
2830	    |                |                |  user     |               |<---
2831	    |   user data    |                |  data     |<--------------|
2832	    | (#marked bytes)|                S<----------|               |
2833	    |<--------------------------------S           |               |
2834	    | (#unmarked bytes)               S           |               |
2835	Term|<--------------------------------S           |               |
2836	Flow?                |                S           |               |
2837	YES |RESERVE(RMD-QSPEC):              S           |               |
2838	    |"forward - T tear"               s           |               |
2839	    |--------------->|  RESERVE(RMD-QSPEC):       |               |
2840	    |                |  "forward - T tear"        |               |
2841	    |                |--------------------------->|               |
2842	    |                |                S           |-------------->|
2843	    |                |                S         RESERVE(RMD-QSPEC):
2844	    |                |                S       "reverse - T tear"  |
2845	    |      RESERVE(RMD-QSPEC)         S           |<--------------|
2846	    |      "reverse - T tear"         S<----------|               |
2847	    |<--------------------------------S           |               |

2849	   Figure 21: Intra-domain RMD severe congestion handling for
2850	           bi-directional reservation (congestion on path QNE(Egress)
2851	           towards QNE(Ingress))

2853	   Figure 21 shows the scenario where the severe congested node is
2854	   located in the "reverse" path. The main difference between this
2855	   scenario and the scenario shown in Figure 20 is that no intra-domain
2856	   NOTIFY(PDR) message has to be generated by the QNE Egress node. This
2857	   is because the (#marked and #unmarked) user data is arriving at the
2858	   QNE Ingress. The QNE Ingress node will be able to calculate the
2859	   number of flows that have to be terminated or forwarded in a lower
2860	   priority queue.

2862	   For the flows that have to be terminated a release procedure, see
2863	   Section 4.6.2.4, is initiated to release the reserved resources
2864	   on the "forward" and "reverse" paths.

2866	4.6.2.6 Admission control using congestion notification based on
2867	          probing

2869	   This section describes the admission control scheme that uses the
2870	   congestion notification function based on probing when bi-directional
2871	   reservations are supported.

2873	   This procedure is similar to the congestion notification for
2874	   admission control procedure described in Section 4.6.1.7. The main
2875	   difference is related to the location of the severe congested node,
2876	   i.e., "forward" path (i.e., path between QNE Ingress towards QNE
2877	   Egress) or "reverse" path (i.e., path between QNE Egress towards
2878	   QNE Ingress).

2880	QNE(Ingress)    Interior    QNE (int.)      Interior      QNE (Egress)
2881	NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
2882	user|                |             |              |               |
2883	data|                |             |              |               |
2884	--->|                | user data   |              |user data      |
2885	    |-------------------------------------------->S (#marked bytes)
2886	    |                |             |              S-------------->|
2887	    |                |             |              S(#unmarked bytes)
2888	    |                |             |              S-------------->|
2889	    |                |             |              S               |
2890	    |                |           RESERVE(re-marked DSCP in GIST)):|
2891	    |                |             |              S               |
2892	    |-------------------------------------------->S               |
2893	    |                |             |              S-------------->|
2894	    |                |             |              S               |
2895	    |                |          RESPONSE(unsuccessful INFO-SPEC)  |
2896	    |<------------------------------------------------------------|
2897	    |                |             |              S               |

2899	   Figure 22: Intra-domain RMD congestion notification based on probing
2900	              for bi-directional admission control (congestion on path
2901	              from QNE(Ingress) towards QNE(Egress))

2903	   Figure 22 shows the scenario where the severe congested node is
2904	   located in the "forward" path. The functionality of providing
2905	   admission control is very similar to the one described in Section
2906	   4.6.1.7, Figure 15.

2908	   Figure 23 shows the scenario where the congested node is located in
2909	   the "reverse" path. The probe RESERVE message sent in the "forward"
2910	   direction will not be affected by the severe congested node, while
2911	   the DSCP value in the IP header of the GIST message that carries the
2912	   probe RESERVE message sent in the "reverse" direction will be
2913	   remarked by the congested node. The QNE ingress is in this way
2914	   notified that a congestion occurred in the network and therefore it
2915	   is able to refuse the new initiation of the reservation.

2917	QNE (Ingress)    Interior    QNE (int.)     Interior       QNE (Egress)
2918	NTLP stateful not NSIS aware  NTLP st.less not NSIS aware NTLP stateful
2919	user|                |                |           |               |
2920	data|                |                |           |               |
2921	--->|                | user data      |           |               |
2922	    |-------------------------------------------->|user data      |user
2923	    |                |                |           |-------------->|data
2924	    |                |                |           |               |--->
2925	    |                |                |           |               |user
2926	    |                |                |           |               |data
2927	    |                |                |           |               |<---
2928	    |                S                | user data |               |
2929	    |                S  user data     |<--------------------------|
2930	    |   user data    S<---------------|           |               |
2931	    |<---------------S                |           |               |
2932	    |  user data     S                |           |               |
2933	    | (#marked bytes)S                |           |               |
2934	    |<---------------S                |           |               |
2935	    |                S           RESERVE(unmarked DSCP in GIST)):|
2936	    |                S             |              |               |
2937	    |----------------S------------------------------------------->|
2938	    |                S          RESERVE(re-marked DSCP in GIST)   |
2939	    |                S<-------------------------------------------|
2940	    |<---------------S             |              |               |

2942	   Figure 23: Intra-domain RMD congestion notification for
2943	           bi-directional admission control (congestion on path
2944	           QNE(Egress) towards QNE(Ingress))

2946	4.7 Handling of additional errors

2948	   During the QSpec processing, additional errors may occur. The way
2949	   of how these additional errors are handled and notified is specified
2950	   in [QSP-T] and [QoS-NSLP].

2952	5.  Security Considerations

2954	   A router implementing a QoS signaling protocol can, similar to a
2955	   router without QoS signaling, do a lot of harm to a system. If taken
2956	   over by an adversary, a router can delay, drop, inject, duplicate or
2957	   modify packets. Additional threats are, however, introduced with new
2958	   protocols and they are subject for a discussion below.

2960	   The RMD-QOSM aims to be very lightweight signaling with regard to
2961	   the number of signaling message roundtrips and the amount of state
2962	   established at involved signaling nodes with and without reduced
2963	   state on QNEs. This implies the usage of the Datagram Mode which
2964	   does not allow channel security to be used. As such, RMD signaling is
2965	   targeted towards intra-domain signaling only.

2967	   In the context of RMD-QOSM signaling a classification between
2968	   on-path adversaries and off-path adversaries needs to be made.
2969	   Furthermore, it might be necessary to differentiate between off-path
2970	   nodes that never participate in the RMD signaling exchange and nodes
2971	   that are only off-path with regard to a specific signaling session
2972	   whereby routing asymmetry might even mean that the downstream and the
2973	   upstream signaling direction matters for this classification.

2975	       QNE             QNE             QNE            QNE
2976	     Ingress         Interior        Interior        Egress
2977	 NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
2978	        |               |               |              |
2979	        | RESERVE (1)   |               |              |
2980	        +--------------------------------------------->|
2981	        | RESERVE' (2)  |               |              |
2982	        +-------------->|               |              |
2983	        |               | RESERVE'      |              |
2984	        |               +-------------->|              |
2985	        |               |               | RESERVE'     |
2986	        |               |               +------------->|
2987	        |               |               |              |
2988	        |               |               | RESPONSE (1) |
2989	        |<---------------------------------------------+
2990	        |               |               |              |

2992	                 Figure 24: RMD message exchange

2994	   Note that RMD always uses the message exchange shown in Figure 24
2995	   even if there is no end-to-end signaling session. If the RMD-QOSM is
2996	   triggered based on an E2E signaling exchange then the RESERVE message
2997	   is created by a node outside the RMD domain and will subsequently
2998	   travel further on (e.g., to the data receiver). Such an exchange is
2999	   shown in Figure 3. As such, an evaluation of RMD's security must
3000	   always been seen as a combination of the two signaling sessions, (1)
3001	   and (2) of Figure 24.

3003	   The following security requirements are set as goals for the
3004	   intra-domain communication, namely:

3006	*  Nodes, which are never supposed to participate in the NSIS signaling
3007	   exchange, SHOULD NOT interfere with QNE Interior nodes. Off-path
3008	   nodes (off-path with regard to the path taken by a particular
3009	   signaling message exchange) SHOULD NOT be able to interfere with
3010	   other on-path signaling nodes.
3011	*  The actions allowed by a QNE Interior node SHOULD be minimal (i.e.,
3012	   only those specified by the RMD-QOSM). For example, only the QNE
3013	   Ingress and the QNE Egress nodes are allowed to initiate certain
3014	   signaling messages. QNE Interior nodes are, for example, allowed to
3015	   modify certain signaling message payloads.

3017	   Note that the term 'interfere' refers to all sorts of security
3018	   threats, such as denial of service, spoofing, replay, signaling
3019	   message injection, etc.

3021	   If we assume that the RESERVE/RESPONSE is sent in C-Mode and
3022	   protected between the QNE Ingress and the QNE Egress node then we can
3023	   be sure that the payloads of these messages MUST be authenticated,
3024	   integrity, replay protected and encrypted. Encryption is necessary to
3025	   prevent an adversary that is located along the path of the RESERVE
3026	   message to learn information about the session that can later be used
3027	   to inject a valid RESERVE'. The following messages need to relate to
3028	   each other to make sure that the occurrence of one message is not
3029	   without the other one:

3031	   a) the RESERVE and the RESERVE' relate to each other at the QNE
3032	      Egress and

3034	   b) the RESPONSE and the RESERVE relate to each other at the QNE
3035	      Ingress and

3037	   c) the RESERVE' and the RESPONSE' (carried in the RESPONSE) relate to
3038	      each other

3040	   The RESERVE and the RESERVE' message are tied together using the
3041	   BOUND_SESSION_ID. Hence, there cannot be a RESERVE' without a
3042	   corresponding RESERVE. The SESSION_ID can fulfill this purpose quite
3043	   well if the aim is to provide protection against off-path adversaries
3044	   that do not see the SESSION_ID carried in the RESERVE and the
3045	   RESERVE' messages. If, however, the path changes (due to re-routing
3046	   or due to mobility) then an adversary could inject RESERVE' messages
3047	   (with a previously seen SESSION_ID) and could potentially cause harm.

3049	   An off-path adversary can, of course, create RESERVE' messages that
3050	   cause intermediate nodes to create some state (and cause other
3051	   actions) but the message would finally hit the QNE Egress node. The
3052	   QNE Egress node would then be able to determine that there is
3053	   something going wrong.

3055	   The severe congestion handling can be triggered by intermediate nodes
3056	   (unlike other messages). In many cases, however, intermediate nodes
3057	   experiencing congestion use refresh messages modify the <S> and
3058	   <Overload %> parameters of the message. These messages are still
3059	   initiated by the QNE Ingress node and carry the SESSION_ID. The QNE
3060	   Egress node will use the SESSION_ID and subsequently the
3061	   BOUND_SESSION_ID to refer to a flow that might be terminated. The
3062	   aspect of intermediate nodes initiating messages for severe
3063	   congestion handling is for further study.

3065	       QNE             QNE             QNE            QNE
3066	     Ingress         Interior        Interior        Egress
3067	 NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
3068	        |               |               |              |
3069	        | REFRESH       |               |              |
3070	        | RESERVE'      |               |              |
3071	        +-------------->| REFRESH       |              |
3072	        | (+RII)        | RESERVE'      |              |
3073	        |               +-------------->| REFRESH      |
3074	        |               | (+RII)        | RESERVE'     |
3075	        |               |               +------------->|
3076	        |               |               | (+RII)       |
3077	        |               |               |              |
3078	        |               |               |     REFRESH  |
3079	        |               |               |     RESPONSE'|
3080	        |<---------------------------------------------+
3081	        |               |               |     (+RII)   |
3082	        |               |               |              |

3084	                 Figure 25: RMD REFRESH message exchange

3086	   During the refresh procedure a RESERVE' creates a RESPONSE', see
3087	   Figure 25. The RII is carried in the RESERVE' message and the
3088	   RESPONSE' message that is generated by the QNE Egress node contains
3089	   the same RII as the RESERVE'.

3091	   The RII can be used by the QNE Ingress to match the RESERVE' with the
3092	   RESPONSE'. The QNE Egress is able to determine whether the RESERVE'
3093	   (as a refresh) was created by the QNE Ingress node since the
3094	   BOUND_SESSION_ID is included in the RESERVE' message.

3096	   With the initial RESERVE'/RESERVE exchange there is a one-to-one
3097	   mapping between the RESERVE and the RESERVE' message based on the
3098	   SESSION_ID that is used in the two messages and the BOUND_SESSION_ID.
3099	   With the REFRESH' message this is not the case since they relate to
3100	   one RESERVE message exchange.

3102	   A further aspect is marking of data traffic. Data packets can be
3103	   modified by an intermediary without any relationship to a signaling
3104	   session (and a SESSION_ID). The problem appears if an off-path
3105	   adversary injects spoofed data packets. The adversary thereby needs
3106	   to spoof data packets that relate to the flow identifier of an
3107	   existing end-to-end reservation that should be terminated. Therefore
3108	   the question arises how an off-path adversary should create a data
3109	   packet that matches an existing flow identifier (if a 5-tuple is
3110	   used). Hence, this might not turn out to be simple for an adversary
3111	   unless we assume the previously mentioned mobility/re-routing case
3112	   where the path through the network changes and the set of nodes that
3113	   are along a path changes over time.

3115	6.  IANA Considerations

3117	   RMD-QOSM requires a new IANA registry for RMD QoS Model
3118	   Identifiers. It is a 32-bit value carried in a QSPEC object [QSP-T].

3120	   RMD-QOSM defines 2 new objects for the QSPEC Template: PHR container
3121	   and PDR container, see 4.1.2 and 4.1.3. For these new containers, new
3122	   IDs in the QSPEC Template Object Type registry should be assigned.

3124	7.  Acknowledgments

3126	   The authors express their acknowledgement to people who have worked
3127	   on the RMD concept: Z. Turanyi, R. Szabo, G. Pongracz, A. Marquetant,
3128	   O. Pop, V. Rexhepi, G. Heijenk, D. Partain, M. Jacobsson, S.
3129	   Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel, M.
3130	   Zoumaro-Djayoon, M. Swanink, R. Klaver G. Stokkink, J. W. van
3131	   Houwelingen, D. Dimitrova

3133	8.  Authors' Addresses

3135	   Attila Bader
3136	   Ericsson Research
3137	   Ericsson Hungary Ltd.
3138	   Laborc 1, Budapest, Hungary, H-1037
3139	   EMail: Attila.Bader@ericsson.com

3141	   Lars Westberg
3142	   Ericsson Research
3143	   Torshamnsgatan 23
3144	   SE-164 80 Stockholm, Sweden
3145	   EMail: Lars.Westberg@ericsson.com
3146	   Georgios Karagiannis
3147	   University of Twente
3148	   P.O.  BOX 217
3149	   7500 AE Enschede, The Netherlands
3150	   EMail: g.karagiannis@ewi.utwente.nl

3152	   Cornelia Kappler
3153	   Siemens AG
3154	   Siemensdamm 62
3155	   Berlin 13627, Germany
3156	   Email: cornelia.kappler@siemens.com

3158	   Hannes Tschofenig
3159	   Siemens AG
3160	   Otto-Hahn-Ring 6
3161	   Munich  81739, Germany
3162	   EMail: Hannes.Tschofenig@siemens.com

3164	   Tom Phelan
3165	   Sonus Networks
3166	   250 Apollo Dr.
3167	   Chelmsford, MA USA 01824
3168	   EMail: tphelan@sonusnet.com

3170	   Attila Takacs
3171	   Ericsson Research
3172	   Ericsson Hungary Ltd.
3173	   Laborc 1, Budapest, Hungary, H-1037
3174	   EMail: Attila.Takacs@ericsson.com

3176	   Andras Csaszar
3177	   Ericsson Research
3178	   Ericsson Hungary Ltd.
3179	   Laborc 1, Budapest, Hungary, H-1037
3180	   EMail: Andras.Csaszar@ericsson.com

3182	9.  Normative References

3184	   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
3185	   Requirement Levels", RFC 2119, March 1997.

3187	   [QoS-NSLP] Manner, J., Karagiannis, G.,McDonald, A., Van de Bosch,
3188	    S., "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-
3189	    nslp (work in progress).

3191	   [QSP-T] Ash, J., Bader, A., Kappler C., "QoS-NSLP QSpec Template"
3192	   draft-ietf-nsis-QSpec (work in progress).

3194	10.  Informative References

3196	   [CsTa05]  Csaszar, A., Takacs, A., Szabo, R., Henk, T., "Resilient
3197	   Reduced-State Resource Reservation", Journal of Communication and
3198	   Networks, Vol. 7, Nr. 4, December 2005.

3200	   [JaSh97]  Jamin, S., Shenker, S., Danzig, P., "Comparison of
3201	   Measurement-based Admission Control Algorithms for Controlled-Load
3202	   Service", Proceedings IEEE Infocom '97, Kobe, Japan, April 1997

3204	   [GrTs03]  Grossglauser, M., Tse, D.N.C, "A Time-Scale Decomposition
3205	   Approach to Measurement-Based Admission Control",  IEEE/ACM
3206	   Transactions on Networking, Vol. 11, No. 4, August 2003

3208	   [RFC2961]   Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.
3209	   and S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
3210	   RFC 2961, April 2001.

3212	   [RFC3175]  Baker, F., Iturralde, C. Le Faucher, F., Davie, B.,
3213	   "Aggregation of RSVP for IPv4 and IPv6 Reservations",
3214	   IETF RFC 3175, 2001.

3216	   [RFC4125] Le Faucheur & Lai, "Maximum Allocation Bandwidth
3217	   Constraints Model for Diffserv-aware MPLS Traffic Engineering",
3218	   RFC 4125, June 2005.

3220	   [RFC4127] Le Faucheur et al, Russian Dolls Bandwidth Constraints
3221	   Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June
3222	   2005

3224	   [GIST]  Schulzrinne, H., Hancock, R., "GIST: General Internet
3225	   Messaging Protocol for Signaling", draft-ietf-nsis-ntlp
3226	   (work in progress).

3228	   [RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in
3229	   the Internet Architecture: an Overview", RFC 1633

3231	   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
3232	   and W.  Weiss, "An Architecture for Differentiated Services", RFC
3233	   2475, December 1998

3235	   [RFC2638] Nichols K., Jacobson V., Zhang L.  "A Two-bit
3236	   Differentiated Services Architecture for the Internet", RFC 2638,
3237	   July 1999

3239	   [RMD1]  Westberg, L., et al., "Resource Management in Diffserv
3240	   (RMD): A Functionality and Performance Behavior Overview", IFIP
3241	   PFHSN'02

3243	   [RMD2] G. Karagiannis, et al., "RMD - a lightweight application
3244	   of NSIS" Networks 2004, Vienna, Austria.

3246	   [RMD3] Marquetant A., Pop O., Szabo R., Dinnyes G., Turanyi Z.,
3247	   "Novel Enhancements to Load Control - A Soft-State, Lightweight
3248	   Admission Control Protocol", Proc. of the 2nd Int. Workshop on
3249	   Quality of Future Internet Services, Coimbra, Portugal,
3250	   Sept 24-26, 2001, pp. 82-96.

3252	   [RMD4] A. Csaszar et al., "Severe congestion handling with
3253	   resource management in diffserv on demand", Networking 2002

3255	Appendix A.1.1 Example of a remarking operation during severe
3256	congestion in the Interior nodes

3258	   Per supported PHB, the interior node can support the operation states
3259	   depicted in Figure A.1, when the per-flow congestion notification
3260	   based on probing signaling scheme is used in combination with this
3261	   severe congestion type. Figure A.2 depicts the same functionality
3262	   when the per-flow congestion notification based on probing scheme is
3263	   not used in combination with the severe congestion scheme.

3265	                ---------------------------------------------
3266	               |        event B                              |
3267	               |                                             V
3268	            ----------             -------------           ----------
3269	           | Normal   |  event A  | Congestion  | event B | Severe   |
3270	           |  state   |---------->| notification|-------->|congestion|
3271	           |          |           |  state      |         |  state   |
3272	            ----------             -------------           ----------
3273	             ^  ^                       |                     |
3274	             |  |                       |                     |
3275	             |  |      event C          |                     |
3276	             |   -----------------------                      |
3277	             |         event D                                |
3278	              ------------------------------------------------

3280	        Figure A.1: States of operation, severe congestion combined with
3281	        congestion notification based on probing

3283	            ----------                 -------------
3284	           | Normal   |  event B      | Severe      |
3285	           |  state   |-------------->| congestion  |
3286	           |          |               |  state      |
3287	            ----------                 -------------
3288	                ^                           |
3289	                |                           |
3290	                |      event E              |
3291	                 ---------------------------
3292	        Figure A.2: States of operation, severe congestion without
3293	        congestion notification based on probing

3295	   The terms used in Figure A.1 and Figure A.2 are:

3297	   Normal state: represents the normal operation conditions of the
3298	   node,   i.e. no congestion

3300	   Severe congestion state: it represents the state when state the
3301	   interior node is severely congested related to a certain PHB

3303	   Congestion notification: state where the load is relatively high,
3304	   close to the level when congestion can occur

3306	   event A: this event occurs when the incoming PHB rate is higher than
3307	   the "congestion notification detection" threshold. This threshold is
3308	   used by the congestion notification based on probing scheme, see
3309	   Section 4.6.1.7, 4.6.2.6.

3311	   event B: this event occurs when the incoming PHB rate is higher than
3312	   the "severe congestion detection" threshold.

3314	   event C: this event occurs when the incoming PHB rate is lower than
3315	   the "congestion notification detection" threshold.

3317	   event D: this event occurs when the incoming PHB rate is lower than
3318	   the "severe_congestion_restoration" threshold.

3320	   event E: this event occurs when the incoming PHB rate is lower than
3321	   the "severe congestion restoration" threshold.

3323	   Note that the "severe congestion detection", "severe congestion
3324	   restoration" and admission thresholds should be higher than the
3325	   "congestion notification detection" threshold, i.e.,:
3326	   "severe congestion detection" > "congestion notification detection"
3327	   and "severe congestion restoration" > "congestion notification
3328	   detection"

3330	   Furthermore, the "severe congestion detection" threshold should be
3331	   higher than or equal to the admission threshold that is used by the
3332	   reservation based and NSIS measurement based signaling schemes.
3333	   "severe congestion detection" >= admission threshold

3335	   Moreover, the "severe congestion restoration" threshold should be
3336	   lower than or equal to the "severe congestion detection" threshold
3337	   that is used by the reservation based and NSIS measurement based
3338	   signaling schemes, i.e.,:

3340	   "severe congestion restoration" <= "severe congestion detection"

3342	   During severe congestion the interior node calculates, per traffic
3343	   class (PHB), the incoming rate that is above the "severe congestion
3344	   restoration" threshold, denoted as signaled_overload_rate, in the
3345	   following way:

3347	   * A severe congested interior node should take into account that
3348	   packets might be dropped. Therefore, before queuing and eventually
3349	   dropping packets, the interior node should count the total number of
3350	   unmarked and remarked bytes received by the severe congested node,
3351	   denote this number as total_received_bytes. Note that there are
3352	   situations when more than one interior nodes in the same path become
3353	   severe congested. Therefore, any interior node located behind a
3354	   severe congested node may receive marked bytes.

3356	   * before queuing and eventually dropping the packets, at the end of
3357	   each measurement interval of T seconds, calculate the current
3358	   estimated overloaded rate, say measured_overload_rate, by using the
3359	   following equation:

3361	   measured_overload_rate =
3362	   =((total_received_bytes)/T) - severe_congestion_restoration)

3364	   Note that since marking is done in interior nodes, the decisions are
3365	   made at egress nodes, and termination of flows are performed by
3366	   ingress nodes, there is a significant delay until the overload
3367	   information is learned by the ingress nodes, see Section 6 of
3368	   [CsTa05]). The delay consists of the trip time of data packets from
3369	   the severe congested interior node to the egress, the measurement
3370	   interval, i.e., T, and the trip time of the notification signaling
3371	   messages from egress to ingress. Moreover, until the overload
3372	   decreases at the severe congested interior node, an additional trip
3373	   time from the ingress node to the severe congested interior node must
3374	   expire. This is because immediately before receiving the congestion
3375	   notification, the ingress may have sent out packets in the flows that
3376	   where selected for termination. That is, a terminated flow may
3377	   contribute to congestion for a time longer that is taken from the
3378	   ingress to the interior node. Without considering the above, interior
3379	   nodes would continue marking the packets until the measured
3380	   utilization falls below the severe congestion restoration threshold.
3381	   In this way, in the end more flows will be terminated than necessary,
3382	   i.e., an over-reaction takes place. [CsTa05] provides a solution to
3383	   this problem, where the interior nodes use a sliding window memory to
3384	   keep track of the signaling overload in a couple of previous
3385	   measurement intervals. At the end of a measurement intervals, T,
3386	   before encoding and signaling the overloaded rate as "encoded DSCP"
3387	   packets, the actual overload is decreased with the sum of already
3388	   signaled overload stored in the sliding window memory, since that
3389	   overload is already being handled in the severe congestion handling
3390	   control loop. The sliding window memory consists of an integer number
3391	   of cells, i.e, n = maximum number of cells. Guidelines for
3392	   configuring the sliding window parameters are given in [CsTa05].

3394	   At the end of each measurement interval, the newest calculated
3395	   overload is pushed into the memory, and the oldest cell is dropped.

3397	   If Mi is the overload_rate stored in ith memory cell (i = [1..n]),
3398	   then at the end of every measurement interval, the overload rate that
3399	   is signaled to the egress node, i.e., signaled_overload_rate is
3400	   calculated as follows:

3402	   Sum_Mi =0
3403	   For i =1 to n
3404	   {
3405	   Sum_Mi = Sum_Mi + Mi
3406	   }

3408	   signaled_overload_rate = measured_overload_rate - Sum_Mi,

3410	   where Sum_Mi is calculated as above.

3412	   Next, the sliding memory is updated as follows:

3414	       for i = 1..(n-1): Mi <- Mi+1
3415	       Mn <- signaled_overload_rate

3417	   The bytes that have to be remarked to satisfy the signaled overload
3418	   rate: signaled_remarked_bytes, are calculated as follows:

3420	   signaled_remarked_bytes = signaled_overload_rate*T/N

3422	   The signal_remarked_bytes represents also the number of
3423	   the outgoing packets (after the dropping stage) that must be
3424	   remarked, during each measurement interval T, by a node when operates
3425	   in severe congestion mode.

3427	   Note that in order to process an overload situation higher than 100%
3428	   of the maintained severe congestion threshold all the nodes within
3429	   the domain MUST be configured and maintain a scaling parameter, e.g.,
3430	   N used in the above equation, which in combination with the marked
3431	   bytes, e.g., signaled_remarked_bytes, such a high overload situation
3432	   ca be calculated and represented.

3434	   Note that when incoming remarked bytes are dropped, the operation of
3435	   the severe congestion algorithm may be affected, e.g., the algorithm
3436	   may become in certain situations slower. An implementation of the
3437	   algorithm may assure as much as possible that the incoming marked
3438	   bytes are not dropped. This could for example be accomplished by
3439	   using different dropping rate thresholds for marked and unmarked
3440	   bytes.

3442	   Note that when the "affected DSCP" marking is applied by a severe
3443	   congested node then all the outgoing packets that are not marked
3444	   (i.e., by using the "encoded DSCP") have to be remarked using the
3445	   "affected DSCP" code. Furthermore, note that when the congestion
3446	   notification based on probing is used in combination with severe
3447	   congestion, then in addition to the possible "encoded DSCP" and
3448	   "affected DSCP" another DSCP for the remarking of the same PHB might
3449	   be used, see Section 4.6.1.7. This additional DSCP might be denoted
3450	   in this document as "notified DSCP". When an interior node operates
3451	   in the severe congested state, see Figure A.2, and receives "notified
3452	   DSCP" packets, these packets are considered to be unmarked packets
3453	  (but not "affected DSCP" packets).

3455	Appendix A.1.2 Example of a detailed severe congestion operation in the
3456	Egress nodes

3458	   The states of operation in Egress nodes are similar to the ones
3459	   described in  A.1.1. The definition of the events, see below, is how
3460	   ever different than the definition of the events given in Figure A.1
3461	   and Figure A.2:

3463	   * event A: the egress node measures the rate of the incoming
3464	   "notified_DSCP" marked packets and compare it with a predefined
3465	   congestion notification detection threshold at the egress. When the
3466	   measured rate of "notified DSCP" bytes is higher than this threshold
3467	   then event_A is activated, see Section 4.6.1.7 and A.2.2. This is
3468	   applied when the whole RMD domain uses "notified DSCP" for this
3469	   purpose.  If the "notified DSCP" marking is not used in the whole RMD
3470	   domain, the "encoded_DSCP" marking is used to notify the congestion
3471	   notification state. In this case the egress should measure the rate
3472	   of the incoming "encoded_DSCP" marked packets and compare it with a
3473	   predefined congestion notification detection threshold and to a
3474	   severe congestion detection threshold in the egress. Note that the
3475	   detection thresholds used in the egress for congestion notification
3476	   and severe congestion may be different than the ones used in interior
3477	   nodes. When the measured rate of "encoded DSCP" bytes is higher than
3478	   the congestion notification threshold but lower than the severe
3479	   congestion threshold then event_A is activated.

3481	   * event B: this event occurs when the egress receives packets marked
3482	   as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is
3483	   applied in the whole RMD domain). However, when the "encoded_DSCP"
3484	   marking is also used for congestion notification detection purposes,
3485	   see description of event_A, then event_B is only activated if either
3486	   "affected DSCP" packets are received or if the rate of the incoming
3487	   "encoded_DSCP" marked packets is higher than the preconfigured severe
3488	   congestion detection egress threshold.

3490	   * event C: this event occurs when the rate of incoming
3491	   "notified DSCP" packets decreases below the congestion notification
3492	   detection threshold. This is applied when whole RMD domain uses
3493	   "notified DSCP" for this purpose. When the "encoded_DSCP" marking is
3494	   also used for congestion notification detection, see description of
3495	   event_A, then event_C is activated when the rate of incoming "encoded
3496	   DSCP" packets decreases below the congestion notification threshold.

3498	   * event D: this event occurs when the egress does not receive packets
3499	   marked as either "encoded DSCP" or "affected DSCP" (when "affected
3500	   DSCP" is applied in the whole RMD domain). When the "encoded_DSCP"
3501	   marking is also used for congestion notification detection, see
3502	   description of event_A, event_B, event_C, then the event_D is only
3503	   activated if either "affected DSCP" packets are not anymore received
3504	   or if the rate of the incoming "encoded_DSCP" marked packets is
3505	   slower than the preconfigured severe congestion restoration threshold
3506	   in egress.

3508	   * event E: this event occurs when the egress does not receive packets
3509	   marked as either "encoded DSCP" or "affected DSCP" (when
3510	   "affected DSCP" is applied in the whole RMD domain)

3512	   An example of the algorithm for calculation of the
3513	   number of flows associated with each priority class that have to be
3514	   terminated is explained by the pseudocode below.

3516	   First, when the egress operates in the severe congestion state then
3517	   the total amount of remarked bandwidth associated with the PHB
3518	   traffic class, say total_congested_bandwidth, is calculated.
3519	   Note that when the node maintains information about
3520	   each ingress/egress pair aggregate, then the
3521	   total_congested_bandwidth must be calculated per ingress/egress pair
3522	   aggregate. This bandwidth represents the severe congested bandwidth
3523	   that should be terminated. The total_congested_bandwidth can be
3524	   calculated as follows:

3526	   total_congested_bandwidth = N*input_remarked_bytes/T

3528	   Where, input_remarked_bytes represents the number of marked bytes
3529	   that arrive at the ingress, during one measurement interval T, N is
3530	   defined as in Section 4.6.1.6.2.1. The term denoted as
3531	   terminated_bandwidth is a temporal variable representing the total
3532	   bandwidth that have to be terminated, belonging to the same
3533	   PHB traffic class. The terminate_flow_bandwidth(priority_class) is
3534	   the total of bandwidth associated with flows of priority class equal
3535	   to priority_class. The parameter priority_class is an integer
3536	   fulfilling
3537	   0 < priority_class =< Maximum_priority.

3539	   The calculate_terminate_flows(priority_class) function determines the
3540	   Flows for a given priority class and per PHB that has to be
3541	   Terminated. This function also calculates the term
3542	   sum_bandwidth_terminate(priority_class), which is the sum of the
3543	   bandwith associated with the flows that will be terminated.
3544	   The constraint of finding the total number of flows that have to
3545	   be terminated is that sum_bandwidth_terminate(priority_class), should
3546	   be smaller or approximatelly equal to the variable
3547	   terminate_bandwidth(priority_class).

3549	     terminated_bandwidth = 0;
3550	     priority_class = 0;
3551	     while terminated_bandwidth < total_congested_bandwidth
3552	      {
3553	       terminate_bandwidth(priority_class) =
3554	       = total_congested_bandwidth - terminated_bandwidth
3555	       calculate_terminate_flows(priority_class);
3556	       terminated_bandwidth =
3557	       = sum_bandwidth_terminate(priority_class) + terminated_bandwidth;
3558	       priority_class = priority_class + 1;
3559	      }

3561	   If the egress node maintains ingress/egress pair aggregates, then the
3562	   above algorithm is performed for each ingress/egress pair aggregate.

3564	Appendix A.2.1 Example of a detailed remarking admission control
3565	(congestion notification) operation in Interior nodes

3567	   In particular, the predefined congestion notification threshold is
3568	   set according to, and usually less than, an engineered bandwidth
3569	   limitation, i.e., admission threshold, based on e.g. agreed Service
3570	   Level Agreement or a capacity limitation of specific links.

3572	   The difference between the congestion notification threshold and the
3573	   engineered bandwidth limitation, i.e., admission threshold, provides
3574	   an interval where the signaling information on resource limitation is
3575	   already sent by a node but the actual resource limitation is not
3576	   reached. This is due to the fact that data packets associated with an
3577	   admitted session have not yet arrived, while allows the admission
3578	   control process available at the egress to interpret the signaling
3579	   information and reject new calls before reaching congestion. Note
3580	   that in the situation when the data rate is higher than the
3581	   preconfigured congestion notification rate, also data packets are
3582	   re-marked, see section 4.6.1.6.2.1. To distinguish between congestion
3583	   notification and severe congestion, two methods may be used (see
3584	   Appendix 1.1.1):

3586	   * using different DSCP values (re-marked DSCP values). The remarked D
3587	   SCP that is used for this purpose is denoted as "notified DSCP" in
3588	   this document. When this method is used and when the interior node is
3589	   in "congestion notification" state, see A.1.1, then the node should
3590	   remark the unmarked bytes using the "notified DSCP". Note that this
3591	   method can only be applied if all nodes in RMD domain use the
3592	   "notified" DSCP marking.

3594	   * Using the "encoded DSCP" marking for congestion notification and
3595	   severe congestion. This situation is applied when the "notified DSCP"
3596	   marking is not applied in the RMD domain. When this method is used
3597	   and when the interior node is in "congestion notification" state, see
3598	   A.1.1, then the node should remark the unmarked bytes using the
3599	   "encoded DSCP".

3601	   Note that if a node starts dropping packets belonging to a PHB that
3602	   suports both "severe congestion" and "congestion notification"
3603	   states, see section 4.6.1.6.2.1, then it is considered that the
3604	   packet rate associated to this PHB is higher than the severe
3605	   congestion detection threshold and that the operation state of this
3606	   node has moved to the severe congestion state, see Appendix A.1.1.

3608	Appendix A.2.2 Example of a detailed admission control (congestion
3609	notification) operation in Egress nodes

3611	   The admission control congestion notification procedure can be
3612	   applied only if the egress maintais the ingress/egress pair
3613	   aggregate. When the operation state of the ingress/egress pair
3614	   aggregate is the "congestion notification", see Appendix A.1.2, then
3615	   the implementation of the algorithm depends on how the congestion
3616	   notification situation is notified to the egress. As mentioned in
3617	   Section A.2.1, two methods are used:

3619	   * using the "notified DSCP". During a measurement interval T, the
3620	   egress counts the number of "notified DSCP" marked bytes that belong
3621	   to the same PHB and are associated with the same ingress/egress pair
3622	   aggregate, say input_notified_bytes. We denote the rate as
3623	   incoming_notified_rate.

3625	   * using the "encoded DSCP". In this case, during a measurement
3626	   interval T, the egress measures the input_notified_bytes by counting
3627	   instead of the "notified DSCP", the "encoded DSCP" bytes.

3629	   The incoming congestion_rate can be then calculated as follows:

3631	incoming_congestion_rate = N*input_notified_bytes/T
3632	   If the incoming_congestion_rate is higher than a preconfigured
3633	   congestion notification threshold, then the communication path
3634	   between ingress and egress is considered to be congested. In this
3635	   situation if the end-to-end RESERVE (probe) arrives at the egress,
3636	   then this request SHOULD be rejected. Note that this choice is
3637	   independent of the DSCP marking status of the packet that carries the
3638	   RESERVE message.
3639	   If such an ingress/egress pair aggregated state is not available when
3640	   the (probe) RESERVE message arrives at the egress, then this request
3641	   is accepted if the DSCP of the packet carrying the RESERVE messsage
3642	   is unmarked. Otherwise (if the packet is either "notified DSCP" or
3643	   "encoded DSCP" marked), it is rejected.

3645	Appendix A.3.1 Example of selecting bi-directional flows for termination
3646	during severe congestion

3648	   When a severe congestion occurs on e.g., in the forward path, and
3649	   when the algorithm terminates flows to solve the severe congestion in
3650	   forward path, then the reserved bandwidth associated with the
3651	   terminated bidirectional flows is also released. Therefore, a careful
3652	   selection of the flows that have to be terminated should take place.
3653	   A possible method of selecting the flows belonging to the same
3654	   priority type passing through the severe congestion point on a
3655	   unidirectional path can be the following:

3657	   * the egress node should select, if possible, first unidirectional
3658	   flows instead of bidirectional flows
3659	   * the egress node should select, if possible, bidirectional flows
3660	   that reserved a relatively small amount of resources on the path
3661	   reversed to the path of congestion.

3663	Appendix A.3.2 Example of a severe congestion solution for bi-
3664	directional flows congested simultaneously on forward and reverse path

3666	   This scenario describes a solution using the combination of the
3667	   severe congestion solutions described in Section 4.6.2.5.2.
3668	   It is considered that the severe congestion occurs simultaneously on
3669	   forward and reverse directions, which may affect the same bi-
3670	   directional flows. This situation is depicted in Figure A.3. Consider
3671	   that the egress node selects a number of bi-directional flows to be
3672	   terminated. In this case the egress will send for each bi-directional
3673	   flows a NOTIFY message to ingress. If the Ingress receives these
3674	   NOTIFY messages and its operational state (associated with reverse
3675	   path) is in the severe congestion state (see Figure A.1 and A.2),
3676	   then the ingress operates in the following way:

3678	   * For each NOTIFY message, the Ingress should identify the
3679	   bidirectional flows have to be terminated.

3681	QNE (Ingress)    NE (int.)    NE (int.)       NE (int.)    QNE (Egress)
3682	NTLP stateful                                             NTLP stateful
3683	user|                |                |           |               |
3684	data|    user        |                |           |               |
3685	--->|    data        | #unmarked bytes|           |               |
3686	    |--------------->S #marked bytes  |           |               |
3687	    |                S--------------------------->|               |
3688	    |                |                |           |-------------->|data
3689	    |                |                |           |               |--->
3690	    |                  |                 |            |         |Term.?
3691	    |            NOTIFY               |           |               |Yes
3692	    |<------------------------------------------------------------|
3693	    |                |                |           |               |
3694	    |                |                |           |               |data
3695	    |                |                |           |               |data
3696	    |                |                |  user     |               |<---
3697	    |   user data    |                |  data     |<--------------|
3698	    | (#marked bytes)|                S<----------|               |
3699	    |<--------------------------------S           |               |
3700	    | (#unmarked bytes)               S           |               |
3701	Term|<--------------------------------S           |               |
3702	Flow?                |                S           |               |
3703	YES |RESERVE(RMD-QSPEC):              S           |               |
3704	    |"forward - T tear"               s           |               |
3705	    |--------------->|  RESERVE(RMD-QSPEC):       |               |
3706	    |                |  "forward - T tear"        |               |
3707	    |                |--------------------------->|               |
3708	    |                |                S           |-------------->|
3709	    |                |                S         RESERVE(RMD-QSPEC):
3710	    |                |                S       "reverse - T tear"  |
3711	    |      RESERVE(RMD-QSPEC)         S           |<--------------|
3712	    |      "reverse - T tear"         S<----------|               |
3713	    |<--------------------------------S           |               |

3715	  Figure A.3: Intra-domain RMD severe congestion handling for
3716	           bi-directional reservation (congestion on both forward and
3717	           reverse direction)

3719	   * The ingress then calculates the total bandwidth that should be
3720	   released in the reverse direction (thus not in forward direction) if
3721	   the bidirectional flows will be terminated (preempted), say
3722	   "notify_reverse_bandwidth".

3724	   * Furthermore, using the received marked packets (from the reverse
3725	   path) the ingress will calculate, using the algorithm used by an
3726	   egress and described in A.1.2, the total bandwidth that has to be
3727	   terminated in order to solve the congestion in the reverse path
3728	   direction, say "marked_reverse_bandwidth".

3730	   * The ingress then calculates the bandwidth of the additional flows
3731	   that have to be terminated, say "additional_reverse_bandwidth", in
3732	   order to solve the severe congestion in reverse direction, by taking
3733	   into account:

3735	   ** the bandwidth in the reverse direction of the bidirectional flows
3736	   that were appointed by the egress (the ones that received a NOTIFY
3737	   message) to be preempted, i.e., "notify_reverse_bandwidth"

3739	   **  the total amount of bandwidth in the reverse direction that has
3740	   been calculated by using the received marked packets, i.e.,
3741	   "marked_reverse_bandwidth".
3742	   This additional bandwidth can be calculated using the following
3743	   algorithm:

3745	    IF ("marked_reverse_bandwidth" > "notify_reverse_bandwidth") THEN
3746	    "additional_reverse_bandwidth" =
3747	     = "marked_reverse_bandwidth"- "notify_reverse_bandwidth";
3748	    ELSE
3749	    "additional_reverse_bandwidth" = 0

3751	   * Ingress terminates the flows that received a (preemption) NOTIFY
3752	   message

3754	   * If possible the ingress SHOULD terminate unidirectional flows that
3755	   are using the same egress-ingress reverse direction communication
3756	   path to satisfy the release of a total bandiwtdh up equal to the:
3757	   "additional_reverse_bandwidth", see Appendix 3.1.

3759	   * If the number of required uni-directional flows (to satisfy the
3760	   above issue) is not available, then a number of bi-directional flows
3761	   that are using the same egress-ingress reverse direction
3762	   communication path MAY be selected for preemption in order to satisfy
3763	   the release of a total bandiwtdh up equal to the:
3764	   "additional_reverse_bandwidth".  Note that using the guidelines given
3765	   in Appendix A.3.1, first the bidirectional flows that reserved a
3766	   relatively small amount of resources on the path reversed to the path
3767	   of congestion should be selected for termination.

3769	Intellectual Property Statement

3771	   The IETF takes no position regarding the validity or scope of any
3772	   Intellectual Property Rights or other rights that might be claimed
3773	   to pertain to the implementation or use of the technology
3774	   described in this document or the extent to which any license
3775	   under such rights might or might not be available; nor does it
3776	   represent that it has made any independent effort to identify any
3777	   such rights.  Information on the procedures with respect to rights
3778	   in RFC documents can be found in BCP 78 and BCP 79.

3780	   Copies of IPR disclosures made to the IETF Secretariat and any
3781	   assurances of licenses to be made available, or the result of an
3782	   attempt made to obtain a general license or permission for the use
3783	   of such proprietary rights by implementers or users of this
3784	   specification can be obtained from the IETF on-line IPR repository
3785	   at http://www.ietf.org/ipr.

3787	   The IETF invites any interested party to bring to its attention
3788	   any copyrights, patents or patent applications, or other
3789	   proprietary rights that may cover technology that may be required
3790	   to implement this standard.  Please address the information to the
3791	   IETF at ietf-ipr@ietf.org.

3793	Disclaimer of Validity
3794	   This document and the information contained herein are provided
3795	   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
3796	   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
3797	   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
3798	   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
3799	   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
3800	   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
3801	   PARTICULAR PURPOSE.

3803	   Copyright (C) The Internet Society (2006).

3805	   This document is subject to the rights, licenses and restrictions
3806	   contained in BCP 78, and except as set forth therein, the authors
3807	   retain all their rights.