idnits 2.17.1 

draft-ietf-nsis-rmd-13.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, updated by RFC 4748 on
     line 4822.

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

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

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


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

     No issues found here.

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

  == There are 7 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 IETF Trust 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 'SHOULD not' in this paragraph:
     
     Note that if the values of the <M> and <S> parameters included in
     the PHR container carried by a intra-domain tear RESERVE(RMD-QOSM) are
     set as ((<M>=0 and <S>=1) or (<M>=0 and <S>=0) or (<M>=1 and <S>=1)) then
     the <Max Admitted Hops> value SHOULD not be compared to the <Admitted
     Hops> value and the value of the <K> field MUST NOT be set. Any QNE edge
     or QNE Interior node that receives the intra-domain tear RESERVE it MUST
     check the <K> field included in the PHR Container. If the <K> fied is "0"
     then the traffic class state (PHB) has to be identified, using the <PHB
     Class> parameter, and the the requested resources included in the
     <Bandwidth> field have to be released. This can be achieved by
     subtracting the amount of RMD traffic class requested resources, included
     in the <Bandwidth> field, from the total reserved amount of resources
     stored in the RMD traffic class state.  The value of the <Time Lag>
     parameter of the PHR field is used during the release procedure as
     explained in the introductory part of Section 4.6.1.5. Afterwards, the
     QNE Egress node MUST terminate the tear intra-domain RESERVE(RMD-QSpec)
     message.

  == Unrecognized Status in 'Intended status: Experimental RFC', assuming
     Proposed Standard

     (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard',
     'Proposed Standard', 'Best Current Practice', 'Informational',
     'Experimental', 'Informational', 'Historic'.)

  -- 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.)

  -- Couldn't find a document date in the document -- date freshness check
     skipped.


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

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

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

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-nsis-qspec (ref. 'QSP-T')


     Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 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: 14 January 2009                           Georgios Karagiannis
5	                                                   University of Twente
6	                                                       Cornelia Kappler
7	                                                                Siemens
8	                                                             Tom Phelan
9	                                                                  Sonus

11	                                                         July. 14, 2008

13	       RMD-QOSM - The Resource Management in Diffserv QOS Model
14	                   <draft-ietf-nsis-rmd-13.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 January 14, 2009.

41	Copyright (C) The IETF Trust (2008).

43	Intended status: Experimental RFC
44	Abstract

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

60	Table of Contents

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

109	1.  Introduction

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

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

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

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

150	   Figure 1: Actors in the RMD-QOSM

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

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

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

170	2.  Terminology

172	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
173	   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
174	   document are to be interpreted as described in [RFC2119].

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

179	   In addition, the following terms are used:

181	   Edge node: a QoS-NSLP node on the boundary of some
182	   administrative domain.

184	   Ingress node: An edge node that handles the traffic as it enters the
185	   domain.

187	   Egress node: An edge node that handles the traffic as it leaves the
188	   domain.

190	   Interior nodes: the set of QOS-NSLP nodes which form an
191	   administrative domain, excluding the edge nodes.

193	3.  Overview of RMD and RMD-QOSM

195	3.1.  RMD

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

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

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

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

233	   The possible RMD-QOSM applicabilities are described in Section
234	   3.2.3. Two main basic admission control modes are supported:
235	   reservation-based and measurement-based admission control that can
236	   be used in combination with a severe congestion handling solution.
237	   The severe congestion handling solution is used in the situation
238	   that a link/node becomes severely congested due to the fact that the
239	   traffic supported by a failed link/node is rerouted and has to be
240	   processed by this link/node. Furthermore, RMD-QOSM supports both
241	   uni-directional and bi-directional reservations.

243	   Another important feature of RMD-QOSM is that the intra-domain
244	   sessions supported by the edges can be either per flow sessions or
245	   per aggregate sessions. In case of the per flow intra-domain
246	   sessions, the maintained per flow intra-domain states have a one-to-
247	   one dependency to the per flow end-to-end states supported by the
248	   same edge. In case of the per-aggregate sessions the maintained per-
249	   aggregate states have a one-to-many relationship to the per flow
250	   end-to-end states supported by the same edge.

252	   In the reservation-based method, each Interior node maintains
253	   only one reservation state per traffic class.  The Ingress edge
254	   nodes aggregate individual flow requests into PHB traffic classes,
255	   and signal changes in the class reservations as necessary.  The
256	   reservation is quantified in terms of resource units (or bandwidth).
257	   These resources are requested dynamically per PHB and reserved on
258	   demand in all nodes in the communication path from an Ingress node
259	   to an Egress node.

261	   The measurement-based algorithm continuously measures traffic levels
262	   and the actual available resources, and admits flows whose resource
263	   needs are within what is available at the time of the request. Once
264	   an admission decision is made, no record of the decision need be
265	   kept.  The advantage of measurement-based resource management
266	   protocols is that they do not require pre-reservation state nor
267	   explicit release of the reservations.  Moreover, when the user
268	   traffic is variable, measurement based admission control could
269	   provide higher network utilization than, e.g., peak-rate
270	   reservation.  However, this can introduce an uncertainty in the
271	   availability of the resources.

273	   Two types of measurement based admission control schemes are
274	   possible:

276	   * Congestion notification function based on probing:

278	   This method can be used to implement a simple measurement-based
279	   admission control within a Diffserv domain. In this scenario the
280	   interior nodes are not NSIS aware nodes. In these interior nodes
281	   thresholds are set for the traffic belonging to different PHBs in
282	   the measurement based admission control function. In this scenario
283	   an end-to-end NSIS message is used as a probe packet, meaning that
284	   the DSCP field in the header of the IP packet that carries the NSIS
285	   message is re-marked when the predefined congestion threshold is
286	   exceeded. Note that when the predefined congestion threshold is
287	   exceeded all packets are remarked by a node, including NSIS
288	   messages. In this way the edges can admit or reject flows that are
289	   requesting resources. The rate of the re-marked data packets is used
290	   to detect a congestion situation that can influence the admission
291	   control decisions.

293	   * NSIS measurement-based admission control:

295	   In this case the measurement-based admission control functionality
296	   is implemented in NSIS aware stateless routers. The main difference
297	   between this type of admission control and the congestion
298	   notification based on probing is related to the fact that this type
299	   of admission control is applied mainly on NSIS aware nodes, giving
300	   the possibility to apply measuring techniques, see e.g., [JaSh97],
301	   [GrTs03], that are using current and past information on NSIS
302	   sessions that requested resources from an NSIS aware interior node.
303	   The admission decision is positive if the currently carried traffic,
304	   as characterized by the measured statistics, plus the requested
305	   resources for the new flow exceeds the system capacity with a
306	   probability smaller than some alpha. Otherwise, the admission
307	   decision is negative.

309	   RMD describes the following procedures:

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

315	   * Hop-by-hop admission control based on a PHB within the
316	     domain. There are two possible modes of operation for internal
317	     nodes to admit requests. One mode is the stateless or
318	     measurement-based mode, where the resources within the domain are
319	     queried. Another mode of operation is the reduced-state
320	     reservation or reservation based mode, where the resources within
321	     the domain are reserved.

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

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

331	3.2. Basic features of RMD-QOSM

333	3.2.1 Role of the QNEs

335	   The protocol model of the RMD-QOSM is shown in Figure 2.  The figure
336	   shows QNI and QNR nodes, not part of the RMD network, that are the
337	   ultimate initiator and receiver of the QoS reservation requests.  It
338	   also shows QNE nodes that are the Ingress and Egress nodes in the
339	   RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are
340	   Interior nodes (QNE Interior).

342	   All nodes of the RMD domain are usually QoS-NSLP aware nodes.
343	   However, in the scenarios where the congestion notification function
344	   based on probing is used, then the interior nodes are not NSIS
345	   aware.  Edge nodes store and maintain QoS-NSLP and NTLP states and
346	   therefore are stateful nodes.  The NSIS aware Interior nodes are
347	   NTLP stateless. Furthermore they are either QoS-NSLP stateless (for
348	   NSIS measurement-based operation), or are reduced state nodes
349	   storing per PHB aggregated QoS-NSLP states (for reservation-based
350	   operation).

352	   Note that the RMD domain may contain Interior nodes that are
353	   not NSIS aware nodes (not shown in the figure).  These nodes are
354	   assumed to have sufficient capacity for flows that might be
355	   admitted.  Furthermore, some of these NSIS unaware nodes may be used
356	   for measuring the traffic congestion level on the data path. These
357	   measurements can be used by RMD-QOSM in the congestion control based
358	   on probing operation and/or severe congestion operation
359	   (see Section 4.6.1.6).

361	     |------|   |-------|                           |------|   |------|
362	     | e2e  |<->| e2e   |<------------------------->| e2e  |<->| e2e  |
363	     | QoS  |   | QoS   |                           | QoS  |   | QoS  |
364	     |      |   |-------|                           |------|   |------|
365	     |      |   |-------|   |-------|   |-------|   |------|   |      |
366	     |      |   | local |<->| local |<->| local |<->| local|   |      |
367	     |      |   | QoS   |   |  QoS  |   |  QoS  |   |  QoS |   |      |
368	     |      |   |       |   |       |   |       |   |      |   |      |
369	     | NSLP |   | NSLP  |   | NSLP  |   | NSLP  |   | NSLP |   | NSLP |
370	     |st.ful|   |st.ful |   |st.less/   |st.less/   |st.ful|   |st.ful|
371	     |      |   |       |   |red.st.|   |red.st.|   |      |   |      |
372	     |      |   |-------|   |-------|   |-------|   |------|   |      |
373	     |------|   |-------|   |-------|   |-------|   |------|   |------|
374	     ------------------------------------------------------------------
375	     |------|   |-------|   |-------|   |-------|   |------|   |------|
376	     | NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP |<->|NTLP  |
377	     |st.ful|   |st.ful |   |st.less|   |st.less|   |st.ful|   |st.ful|
378	     |------|   |-------|   |-------|   |-------|   |------|   |------|
379	       QNI         QNE        QNE         QNE          QNE       QNR
380	     (End)     (Ingress)   (Interior)  (Interior)   (Egress)    (End)

382	         st.ful: stateful, st.less: stateless
383	         st.less red.st.: stateless or reduced state

385	   Figure 2: Protocol model of stateless/reduced state operation

387	3.2.2 RMD-QOSM/QoS-NSLP Signaling

389	   The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The
390	   signalling scenarios are accomplished using the QoS-NSLP processing
391	   rules defined in [QoS-NSLP], in combination with the RMF triggers
392	   sent via the QoS-NSLP-RMF API described in [QoS-NSLP]. A RESERVE
393	   message is created by a QNI with an Initiator QSpec describing the
394	   reservation and forwarded along the path towards the QNR.  When the
395	   original RESERVE message arrives at the Ingress node, an RMD-QSpec
396	   is constructed based on the initial QSpec in the message (usually
397	   the Initiator QSpec).  The RMD-QSpec is sent in a intra-domain,
398	   independent RESERVE message through the Interior nodes towards the
399	   QNR. This intra-domain RESERVE message uses the  GIST datagram
400	   signaling mechanism. Note that the RMD-QOSM cannot directly specify
401	   that the GIST datagram mode should be used. This can however be
402	   notified by using the GIST API Transfer-Attributes, such as
403	   unreliable, low level of security and use of local policy.
404	   Meanwhile, the original RESERVE message is sent to the Egress node
405	   on the path to the QNR using the reliable transport mode of NTLP.

407	          QNE Ingress     QNE Interior     QNE Interior   QNE Egress
408	        NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
409	               |               |               |              |
410	       RESERVE |               |               |              |
411	      -------->| RESERVE       |               |              |
412	               +--------------------------------------------->|
413	               | RESERVE`      |               |              |
414	               +-------------->|               |              |
415	               |               | RESERVE`      |              |
416	               |               +-------------->|              |
417	               |               |               | RESERVE`     |
418	               |               |               +------------->|
419	               |               |               |     RESPONSE`|
420	               |<---------------------------------------------+
421	               |               |               |              | RESERVE
422	               |               |               |              +------->
423	               |               |               |              |RESPONSE
424	               |               |               |              |<-------
425	               |               |               |     RESPONSE |
426	               |<---------------------------------------------+
427	       RESPONSE|               |               |              |
428	      <--------|               |               |              |

430	   Figure 3: Sender-initiated reservation with Reduced State Interior
431	             Nodes

433	   Each QoS-NSLP node on the data path processes the intra-domain
434	   RESERVE message and checks the availability of resources with either
435	   the reservation-based or the measurement-based method.  When the
436	   message reaches the Egress node, and the reservation is successful
437	   in each Interior node, an intra-domain (local) RESPONSE` is sent
438	   towards the ingress node and the original (end-to-end) RESERVE
439	   message is forwarded to the next domain.  When the Egress node
440	   receives a RESPONSE message from the downstream end, it is forwarded
441	   directly to the Ingress node.

443	   If an intermediate node cannot accommodate the new request, it
444	   indicates this by marking a single bit in the message, and continues
445	   forwarding the message until the Egress node is reached. From the
446	   Egress node an intra-domain RESPONSE` and an original RESPONSE
447	   message are sent directly to the Ingress node.

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

456	3.2.3 RMD-QOSM Applicability and considerations

458	   The RMD-QOSM is a Diffserv-based bandwidth management methodology
459	   that is not able to provide a full Diffserv support. The reason of
460	   this is that the RMD-QOSM concept can only support the (Expedited
461	   Forwarding) EF-like functionality behavior, where the required
462	   bandwidth can be signaled in the <QoS Desired> parameter. The RMD-
463	   QOSM is not able to support the full set of (Assured Forwarding) AF-
464	   like functionality where multiple PHBs/DSCPs are used. This is
465	   because the signaled <QoS Desired> parameter should contain two
466	   token buckets needed to signal AF in full generality. Note however,
467	   that RMD-QOSM could also support a single AF PHB, when the traffic
468	   or the upper limit of the traffic can be characterized by a single
469	   bandwidth parameter.

471	   A very important consideration on using RMD-QOSM is that within one
472	   RMD domain only one of the following RMD-QOSM schemes can be used at
473	   a time. Thus a RMD router can never process and use two different
474	   RMD-QOSM signaling schemes at the same time. The operator of an RMD
475	   domain has to pre-configure all routers in the domain such that
476	   within one RMD domain only one of the below described RMD-QOSM
477	   schemes can be used at a time. Note however, that there is no single
478	   to implement scheme variant.

480	   It is important to note that the concepts described in Sections
481	   4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2 and 4.6.2.5.2 contributed to
482	   the PCN WG standardisation.

484	   The available RMD-QOSM/QoS-NSLP signaling schemes are:

486	   * per flow congestion notification based on probing" (see
487	     Sections 4.3.2, 4.6.1.7., 4.6.2.6.). Note that this scheme uses for
488	     severe congestion handling the "Severe congestion handling by
489	     proportional data packet marking", see Section 4.6.1.6.2,
490	     4.6.2.5.2)

492	   * "per flow RMD NSIS measurement based admission control" (see
493	     Sections 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses for
494	     severe congestion handling the "Severe congestion handling by
495	     proportional data packet marking", see Section 4.6.1.6.2,
496	     4.6.2.5.2)

498	   * "per flow RMD reservation based" in combination with "severe
499	     congestion handling by the RMD-QOSM refresh procedure" (see
500	     Sections 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this
501	     scheme uses for severe congestion handling the "Severe congestion
502	     handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1,
503	     4.6.2.5.1)

505	   * "per flow RMD reservation based" in combination with "severe
506	     congestion handling by proportional data packet marking" procedure
507	     (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that
508	     this scheme uses for severe congestion handling the "Severe
509	     congestion handling by proportional data packet marking" procedure,
510	     see Section 4.6.1.6.2, 4.6.2.5.2)

512	   * "per aggregate RMD reservation based" in combination with
513	     "severe congestion handling by the RMD-QOSM refresh procedure" (see
514	     Sections 4.3.1, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this
515	     scheme uses for severe congestion handling the "Severe congestion
516	     handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1,
517	     4.6.2.5.1)

519	   * "per aggregate RMD reservation based" in combination with
520	     "severe congestion handling by proportional data packet marking"
521	     procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, 4.6.2.5.2).
522	     Note that this scheme uses for severe congestion handling the
523	     "Severe congestion handling by proportional data packet marking"
524	     procedure, see Section 4.6.1.6.2, 4.6.2.5.2)

526	4.  RMD-QOSM, Detailed Description

528	   This section describes the RMD-QOSM in more detail.  In particular,
529	   it defines the role of stateless and reduced-state QNEs, the
530	   RMD-QOSM QSpec Object, the format of the RMD-QOSM QoS-NSLP messages
531	   and how QSpecs are processed and used in different protocol
532	   operations.

534	4.1.  RMD-QSpec Definition

536	   The RMD-QOSM uses the QSpec format specified in [QSP-T].
537	   The <I> flag is set to "Local" (i.e., "1") and the <Qspec Proc> is
538	   set as follows:
539	   * Message Sequence = 0: Sender initiated
540	   * Object combination = 1: <QoS Desired> for RESERVE and
541	     <QoS Reserved> for RESPONSE

543	   The <QSPEC Version> used by RMD-QOSM is the default version, see
544	  [QSP-T]. The <QSPEC Type> used by the RMD-QOSM is
545	   assigned by IANA, see Section 6. The <Traffic Handling Directives>
546	   contains the following fields:

548	   <Traffic Handling Directives> = <PHR container> <PDR container>

550	   The Per Hop Reservation container (PHR container) and
551	   the Per Domain Reservation container (PDR container) are specified
552	   in Section 4.1.2 and 4.1.3, respectively. The <PHR container>
553	   contains the traffic handling directives for intra-domain
554	   communication and reservation.  The <PDR container> contains
555	   additional traffic handling directives that is needed for
556	   edge-to-edge communication. The parameter IDs used by the <PHR
557	   container> and <PDR container> are assigned by IANA, see Section 6.
558	   For clarity Reasons we will assigned temporarily, the following names
559	   to the PHR and PDR containers:
560	       * PHR_1 to PHR_3 for the <PHR container>
561	       * PDR_4 to PDR_10 for the <PDR container>
562	   After IANA assigns the proper ID values to the PHR and PDR
563	   containers, then the above list has to be replaced accordingly.

565	   The "RMD-QOSM object combination", i.e., <QoS Desired> and
566	   <QoS Reserved>,  is specified in Section 4.1.1. The "RMD-
567	   QOSM QoS object combination" and the <PHR container> are used and
568	   processed by the Edge and Interior nodes.  The <PDR container> field
569	   is only processed by Edge nodes.

571	4.1.1.  RMD-QOSM object combination

573	   The "RMD-QOSM object combination" carried by the RESERVE message only
574	   contains the QoS Desired object [QSP-T]. The QoS Reserved object is
575	   carried by the RESPONSE message.

577	   "RMD-QOSM object combination" = <QoS Desired> for RESERVE
578	   "RMD-QOSM object combination" = <QoS Reserved> for RESPONSE
579	   <QoS Desired> = <Bandwidth> <PHB Class> <Admission Priority>
580	   <QoS Reserved> = <Bandwidth> <PHB Class> <Admission Priority>

582	   The bit format of the <PHB Class> (see [QSP-T] and Figure 4 and
583	    Figure 5) and
584	<Admission Priority> complies to the bit format specified in [QSP-T].
585	   The bit format used for the <Bandwidth> parameter is shown below and
586	   it is identical to the peak rate (p) <TMOD-1> parameter format
587	   specified in [QSP-T]. Note that after IANA assigns the proper ID
588	  value to the <Bandwdith> parameter then the Bandwdith_ID term has
589	   to be replaced accordingly.

591	     0                   1                   2                   3
592	     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
593	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
594	    |1|E|0|r|       Bandwidth_IDID    |r|r|r|r|          1            |
595	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596	    | Peak Data Rate-1 (p)  (32-bit IEEE floating point number)     |
597	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

599	            <Bandwidth> parameter format

601	   Note that for the RMD-QOSM a reservation established without an
602	   <Admission Priority> parameter is equivalent to a reservation
603	   established with an <Admission Priority> whose value is 1.

605	            0                   1
606	            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
607	           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
608	           | DSCP      |0 0 0 0 0 0 0 0 X 0|
609	           +---+---+---+---+---+---+---+---+

611	             Figure 4: DSCP parameter

613	            0                   1
614	            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
615	           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
616	           |    PHB ID code        |0 0 X X|
617	           +---+---+---+---+---+---+---+---+

619	            Figure 5: PHB ID Code parameter

621	4.1.2.  PHR Container

623	   This section describes the parameters used by the PHR container,
624	   which are used by the RMD-QOSM functionality available at the
625	   Interior nodes.

627	   <PHR container> = <Overload %>, <K>, <S>,<M>,
628	   <Admitted Hops>, <B>, <Hop_U>, <Time Lag>, <Max
629	   Admitted Hops>

631	   The bit format of the PHR container can be seen in Figure 6. Note
632	   that in Figure 6 <Hop U> is represented as <U>. Furthermore, note
633	   that in Figure 6 <Max Admitted Hops> is represented as
634	   <Max Adm Hops>.

636	     0                   1                   2                   3
637	     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
638	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
639	    |M|E|N|r|       Container ID    |r|r|r|r|          2            |
640	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
641	    |S|M| Admitted  Hops|B|U| Time  Lag     |  Overload %   |K|     |
642	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
643	    | Max Adm  Hops |                                               |
644	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

646	        Figure 6: PHR container

648	   Parameter/Container ID:
649	   8 bit field, indicating the PHR type: PHR_Resource_Request,
650	   PHR_Release_Request, PHR_Refresh_Update.

652	   "PHR_Resource_Request" (Container ID = PHR_1): initiate or update
653	   the traffic class reservation state on all nodes located on the
654	   communication path between the QNE(Ingress) and QNE(Egress) nodes.

656	   "PHR_Refresh_Update" (Container ID = PHR_2): refresh the
657	   traffic class reservation soft state on all nodes located on the
658	   communication path between the QNE(Ingress) and QNE(Egress)
659	   nodes according to a resource reservation request that was
660	   successfully processed during a previous refresh period.

662	   "PHR_Release_Request" (Container ID = PHR_3): explicitly release, by
663	   subtraction, the reserved resources for a particular flow
664	   from a traffic class reservation state.

666	   <S> (Severe Congestion):
667	   1 bit.  In case of a route change refreshing RESERVE messages
668	   follow the new data path, and hence resources are requested
669	   there.  If the resources are not sufficient to accommodate the new
670	   traffic severe congestion occurs.  Severe congested Interior nodes
671	   SHOULD notify Edge QNEs about the congestion by setting the S bit.

673	   <Overload %>:
674	   8 bits In case of severe congestion the level of overload is
675	   indicated by the Overload %.  Overload % SHOULD be higher than 0 if
676	   S bit is set.  If overload in a node is greater than the overload
677	   in a previous node then Overload % SHOULD be updated. For more
678	   details see Section 4.6.1.6.1.

680	   <M>:
681	   1 bit.  In case of unsuccessful resource reservation or resource
682	   query in an Interior QNE, this QNE sets the M bit in order to
683	   notify the Egress QNE.

685	   <Admitted Hops>:
686	   8 bit field.  The <Admitted Hops> counts the number of hops in the
687	   RMD domain where the reservation was successful.  The <Admitted
688	   Hops> is set to "0" when a RESERVE message enters a domain and it
689	   MUST be incremented by each Interior QNE, provided that the Hop_U bit
690	   is not set.  However when a QNE that does
691	   not have sufficient resources to admit the reservation is reached,
692	   the M Bit is set, and the <Admitted Hops> value is frozen, by setting
693	   the Hop_U bit to "1". Note that the <Admitted Hops> parameter in
694	   combinations with the <Max Admitted Hops> and <K> parameters are used
695	   during the RMD partial release procedures, see Section 4.6.1.5.2.

697	   <Hop_U> (NSLP_Hops unset):
698	   1-bit. The QNE(Ingress) node MUST set the <Hop_U> parameter to
699	   0.  This parameter SHOULD be set to "1" by a node when the node does
700	   not increase the <Admitted Hops> value. This is the case when an
701	   RMD-QOSM reservation-based node is not admitting the reservation
702	   request. When <Hop_U> is set "1" the <Admitted Hops> SHOULD NOT be
703	   changed. Note that this flag in combination with the <Admitted Hops>
704	   flag are used to locate the last node that successfully processed a
705	   reservation request, see Section 4.6.1.2.

707	   <B>: 1 bit.  When set to "1" it indicates bi-directional reservation.

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

712	   <K>: 1 bit. When set to "1" it indicates that the resources/bandwidth
713	   carried by a tearing RESERVE MUST NOT be released and the
714	   resources/bandwidth carried by a non tearing RESERVE MUST NOT be
715	   reserved/refreshed.

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

722	4.1.3.  PDR container

724	   This section describes the parameters of the PDR container, which are
725	   used by the RMD-QOSM functionality available at the
726	   Edge nodes.

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

730	   <PDR container> = <Overload %>  <S> <M> <Max
731	   Admitted Hops> <B> [<PDR Bandwidth>]

733	   Note that in Figure 7 <Max Admitted Hops> is represented as
734	   <Max Adm Hops>.

736	       0                   1                   2                   3
737	       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
738	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
739	      |M|E|N|r|   Container ID        |r|r|r|r|          2            |
740	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
741	      |S|M| Max Adm  Hops |B|  Overload %   |       Empty       |     |
742	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
743	      |PDR Bandwidth(32-bit IEEE floating point.number)               |
744	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

746	        Figure 7: PDR container

748	   Parameter/Container ID:

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

752	   "PDR_Reservation_Request" (Parameter/Container ID = PDR_4):
753	   Generated by the QNE(Ingress) node in order to initiate or update
754	   the QoS-NSLP per domain reservation state in the QNE(Egress) node

756	   "PDR_Refresh_Request" (Parameter/Container ID = PDR_5): generated by
757	   the QNE(Ingress) node and sent to the QNE(Egress) node to refresh,
758	   in case needed, the QoS-NSLP per domain reservation states
759	   located in the QNE(Egress) node

761	   "PDR_Release_Request" (Parameter/Container ID = PDR_6): generated
762	   and sent by the QNE(Ingress) node to the QNE(Egress) node to release
763	   the per domain reservation states explicitly
764	   "PDR_Reservation_Report" (Parameter/Container ID = PDR_7): generated
765	   and sent by the QNE(Egress) node to the QNE(Ingress) node to
766	   report that a "PHR_Resource_Request" and a
767	   "PDR_Reservation_Request" traffic handling directive fields have been
768	   received and that the request has been admitted or rejected

770	   "PDR_Refresh_Report" (Parameter/Container ID = PDR_8) generated and
771	   sent by the QNE(Egress) node in case needed, to the QNE(Ingress)
772	   node to report that a "PHR_Refresh_Update" traffic handling directive
773	   field has been received and has been processed

775	   "PDR_Release_Report" (Parameter/Container ID = PDR_9) generated and
776	   sent by the QNE(Egress) node in case needed, to the QNE(Ingress)
777	   node to report that a "PHR_Release_Request" and a
778	   "PDR_Release_Request" traffic handling directive fields have been
779	   received and have been processed.

781	   "PDR_Congestion_Report" (Parameter/Container ID = PDR_10): generated
782	   and sent by the QNE(Egress) node to the QNE(Ingress) node and used
783	   for congestion notification

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

790	   <Overload %>:
791	   8-bit.  It includes the Overload % of the
792	   "PHR_Resource_Request" or "PHR_Refresh_Update" control
793	   information fields, indicating the level of overload to the Ingress
794	   node.  For more details see Section 4.6.1.6.1.

796	   <M> (PDR Marked):
797	   1-bit.  Carries the <M> value of the "PHR_Resource_Request" or
798	   "PHR_Refresh_Update" traffic handling directive fields.

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

802	   <Max Admitted Hops>:
803	   8-bit.  The <Admitted Hops> value that has been carried by the
804	   PHR container field used to identify the RMD reservation based node
805	   that admitted or process a "PHR_Resource_Request"
806	   <PDR Bandwidth>:
807	   32 bits.  This field specifies the bandwidth that either applies
808	   when the "B" flag is set to "1" and when this parameter is carried
809	   by a RESPONSE message, or when a severe congestion occurs and the
810	   QNE edges maintain an aggregated intra-domain QoS-NSLP operational
811	   state and it is carried by a NOTIFY message.  In the situation that
812	   the "B" flag is set to "1" this parameter specifies the requested
813	   bandwidth that have to be reserved by a node in the reverse
814	   direction and when the intra-domain signaling procedures require a
815	   bi-directional reservation procedure.  In the severe congestion
816	   situation this parameter specifies the bandwidth that has to be
817	   released.

819	4.2.  Message Format

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

826	4.3.  RMD node state management

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

833	4.3.1 Aggregated operational and reservation states at the QNE Edges

835	   The QNE Edges maintain both the intra-domain QoS-NSLP operational
836	   and reservation states, while the QNE Interior nodes maintain only
837	   reservation states. The structure of the intra-domain QoS-NSLP
838	   operational state used by the QNE edges is specified in [QoS-NSLP].

840	   Note that the method of selecting the end-to-end sessions that form
841	   an aggregate is not specified in this document. An example how this
842	   can be accomplished is by monitoring the GIST routing states used by
843	   the end-to-end sessions and group the ones that use the same <PHB
844	   class>, QNE Ingress and QNE Egress addresses and the value of the
845	   priority level. Note that this priority level should be deduced from
846	   the priority parameters carried by the initial QSpec object.

848	   The operational state of this aggregated intra-domain session must
849	   contain a list with BOUND_SESSION_IDs.

851	   The structure of the list depends on whether a unidirectional
852	   reservation or a bidirectional reservation is supported.

854	   When the operational state (at QNE ingress and QNE egress) supports
855	   unidirectional reservations then this state must contain a list with
856	   BOUND_SESSION_IDs maintaining the SESSION_ID values of its bound
857	   end-to-end sessions. The BINDING_CODE associated with this
858	   BOUND_SESSION_ID is set to code (Aggregated sessions).  Thus the
859	   operational state maintains a list of BOUND_SESSION_IDs entries.
860	   Each entry is created when an end-to-end session joins the
861	   aggregated intra-domain session and is removed when an end-to-end
862	   session leaves the aggregate.

864	   It is important to emphasize that in this case, the operational
865	   state (at QNE ingress and QNE egress) that is maintained by each
866	   end-to-end session bound to the aggregated intra-domain session it
867	   must contain in the BOUND_SESSION_ID, the SESSION_ID value of the
868	   bound tunnelled intra-domain (aggregate) session. The BINDING_CODE
869	   associated with this BOUND_SESSION_ID is set to code (Aggregated
870	   sessions).

872	   When the operational state (at QNE ingress and QNE egress) supports
873	   bidirectional reservations then the operational state must contain a
874	   list of BOUND_SESSION_ID sets. Each set contain two
875	   BOUND_SESSION_IDs.  One of the BOUND_SESSION_IDs maintains the
876	   SESSION_ID value of one of bound end-to-end session. The
877	   BINDING_CODE associated with this BOUND_SESSION_ID is set to code
878	   (Aggregated sessions). Another BOUND_SESSION_ID, within the same set
879	   entry, maintains the SESSION_ID of the bidirectional bound end-to-
880	   end session. The BINDING_CODE associated with this BOUND_SESSION_ID
881	   is set to code (Bi-directional sessions).

883	   Note that in each set, a one to one relation exists between each
884	   BOUND_SESSION_ID with BINDING_CODE set to (Aggregate sessions) and
885	   each BOUND_SESSION_ID with BINDING_CODE set to (Bi-directional
886	   sessions). Each set is created when an end-to-end session joins the
887	   aggregated operational state and is removed when an end-to-end
888	   session leaves the aggregated operational state.

890	   It is important to emphasize that in this case, the operational
891	   state (at QNE ingress and QNE egress) that is maintained by each
892	   end-to-end session bound to the aggregated intra-domain session it
893	   must contain two types of BOUND_SESSION_IDs. One is the
894	   BOUND_SESSION_ID that must contain the SESSION_ID value of the bound
895	   tunelled aggregated intra-domain session that is using the
896	   BINDING_CODE set to (Aggregated sessions). The other
897	   BOUND_SESSION_ID maintains the SESSION_ID of the bound bidirectional
898	   end-to-end session. The BINDING_CODE associated with this
899	   BOUND_SESSION_ID is set to code (Bi-directional sessions).

901	   When the QNE Edges use aggregated QoS-NSLP reservation states, then
902	   the PHB class value and the size of the aggregated
903	   reservation, e.g., reserved bandwidth have to be maintained.
904	   Note that this type of aggregation is an edge to edge aggregation
905	   and is similar to the aggregation type specified in [RFC3175].

907	   The size of the aggregated reservations needs to be
908	   greater or equal to the sum of bandwidth of the inter domain
909	   (end-to-end) reservations/sessions it aggregates, see e.g., Section
910	   1.4.4 of [RFC3175].  A policy can be used
911	   to maintain the amount of required bandwidth on a given aggregated
912	   reservation by taking into account the sum of the underlying inter
913	   domain (end-to-end) reservations, while endeavouring to change
914	   reservation less frequently.  This MAY require a trend analysis.
915	   If there is a significant probability that in the next interval of
916	   time the current aggregated reservation is exhausted, the Ingress
917	   router MUST predict the necessary bandwidth and request it.  If the
918	   Ingress router has a significant amount of bandwidth reserved but
919	   has very little probability of using it, the policy MAY predict the
920	   amount of bandwidth required and release the excess.  To increase or
921	   decrease the aggregate, the RMD modification procedures SHOULD be
922	   used (see Section 4.6.1.4).

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

929	4.3.2  Measurement-based method

931	   The QNE Edges maintain per flow intra-domain QoS-NSLP operational
932	   and reservation states that are containing similar data structures
933	   as described in Section 4.3.1. The main difference is associated
934	   with the different types of the used MRI and the bound end-to-end
935	   sessions. The structure of the maintained BOUND_SESSION_IDs depends
936	   on whether a unidirectional reservation or a bidirectional
937	   reservation is supported.

939	   When unidirectional reservations are supported then the operational
940	   state associated with this per flow intra-domain session must
941	   contain in the BOUND_SESSION_ID the SESSION_ID value of its bound
942	   end-to-end session. The BINDING_CODE associated with this
943	   BOUND_SESSION_ID is set to code (Tunnelled and end-to-end sessions).

945	   It is important to emphasize that in this case, the operational
946	   state (at QNE ingress and QNE egress) that is maintained by the end-
947	   to-end session bound to the per-flow intra-domain session it must
948	   contain in the BOUND_SESSION_ID, the SESSION_ID value of the bound
949	   tunnelled per-flow intra-domain session. The BINDING_CODE associated
950	   with this BOUND_SESSION_ID is set to code (Tunnelled and end-to-end
951	   sessions).

953	   When bidirectional reservations are supported then the operational
954	   state (at QNE ingress and QNE egress) must contain two types of
955	   BOUND_SESSION_IDs. One is the BOUND_SESSION_ID that maintains the
956	   SESSION_ID value of the bound tunnelled per-flow intra-domain
957	   session.  The BINDING_CODE associated with this BOUND_SESSION_ID is
958	   set to code (Tunnelled and end-to-end sessions).
959	   The other BOUND_SESSION_ID maintains the SESSION_ID of the bound
960	   bidirectional end-to-end session. The BINDING_CODE associated with
961	   this BOUND_SESSION_ID is set to code (Bi-directional sessions).

963	   It is important to emphasize, in this case, that the operational
964	   state (at ingress and egress) that is maintained by the end-to-end
965	   session bound to the per-flow intra-domain session must contain two
966	   types of BOUND_SESSION_IDs.  One of the BOUND_SESSION_IDs must
967	   contain the SESSION_ID of its bound end-to-end session that is using
968	   a BINDING_CODE with value set to code (Tunnelled and end-to-end
969	   sessions).  Another BOUND_SESSION_ID maintains the SESSION_ID of the
970	   bound bidirectional end-to-end session. The BINDING_CODE associated
971	   with this BOUND_SESSION_ID is set to code (Bi-directional sessions).

973	   Furthermore, the QoS-NSLP reservation state maintains the PHB class
974	   value, the value of the bandwidth requested by the end-to-end
975	   session bound to the intra-domain session and the value of the
976	   priority level.

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

980	   * Congestion notification based on probing:

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

995	   In this scenario end-to-end NSIS message is used as a probe packet.
996	   In this case the DSCP field of the GIST message is re-marked when
997	   the predefined congestion notification threshold is exceeded in an
998	   interior node. In this way it is ensured that the end-to-end NSIS
999	   message passed through the node that it is congested. This feature
1000	   is very useful when ECMP (Equal Cost Multiple Path) based routing is
1001	   used to detect only flows that are passing through the congested
1002	   node. Note that in this situation, not only the probe packet is
1003	   remarked, but also data packets passing though the congested node
1004	   are re-marked.

1006	   * NSIS measurement-based admission control:

1008	   The measurement based admission control is implemented in NSIS aware
1009	   stateless routers. In particular, the QNE Interior nodes operating
1010	   in NSIS measurement-based mode are QoS-NSLP stateless nodes, i.e.,
1011	   they do not support any QoS-NSLP or NTLP/GIST states.  These
1012	   measurement-based nodes store two RMD-QOSM states per PHR group.
1013	   These states reflect the traffic conditions at the node and are not
1014	   affected by QoS-NSLP signaling. One state stores the measured user
1015	   traffic load associated with the PHR group and another state stores
1016	   the maximum traffic load threshold that can be admitted per PHR
1017	   group. When a measurement-based node receives a intra-domain RESERVE
1018	   message, it compares the requested resources to the available
1019	   resources (maximum allowed minus current load) for the requested PHR
1020	   group.  If there are insufficient resources, it sets the <M> bit in
1021	   the RMD-QSpec.  No change to the RMD-QSpec is made when there are
1022	   sufficient resources.

1024	4.3.3  Reservation-based method

1026	   The QNE Edges maintain intra-domain QoS-NSLP operational and
1027	   reservation states that are containing similar data structures as
1028	   described in Section 4.3.2.

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

1034	   The reservation-based PHR installs and maintains one reservation
1035	   state per PHB, in all the nodes located in the communication path
1036	   from the QNE Ingress node up to the QNE Egress node.  This state is
1037	   identified by the PHB class value and it maintains the number of
1038	   currently reserved resource units (or bandwidth).  Thus,
1039	   the QNE Ingress node signals only the resource units requested by
1040	   each flow.  These resource units, if admitted, are added to the
1041	   currently reserved resources per PHB.

1043	   For each PHB a threshold is maintained that specifies the maximum
1044	   number of resource units that can be reserved. This threshold
1045	   could, for example, be statically configured.

1047	   An example of how the admission control and its maintenance process
1048	   occurs in the interior nodes is described in Section 3 of [CsTa05].
1049	   The simplified concept that is used by the per traffic class
1050	   admission control process in the interior nodes, is based on the
1051	   following equation:
1052	        last + p <= T,
1053	   where p: requested bandwidth rate, T: admission threshold, which
1054	   reflects the maximum traffic volume that can be admitted in the
1055	   traffic class, last: a counter that records the aggregated sum of
1056	   the signaled bandwidth rates of previous admitted flows.

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

1068	   The reserved resources for a particular flow can also be
1069	   explicitly released from a PHB reservation state by means of a
1070	   intra-domain RESERVE release/tear message, which is generated by the
1071	   Ingress QNEs.  The usage of explicit release enables the
1072	   instantaneous release of the resources regardless of the length of
1073	   the refresh period.  This allows a longer refresh period, which also
1074	   reduces the number of periodic refresh messages.

1076	   Note that both in case of measurement- and (per-flow and aggregated)
1077	   RMD reservation-based methods,the way of how the maximum bandwidth
1078	   thresholds are maintained is out of the specification of this
1079	   document. However, when admission
1080	   priorities are supported, the Maximum Allocation [RFC4125] or the
1081	   Russian Dolls [RFC4127] bandwidth allocation model may be used. In
1082	   this case three types of priority traffic classes within the same
1083	   PHB, e.g., Expedited Forwarding, can be differentiated. These three
1084	   different priority traffic classes, which are associated to the same
1085	   PHB, are denoted in this document as PHB_low_priority,
1086	   PHB_normal_priority and PHB_high_priority, and are identified by the
1087	   PHB class value and the priority value, which is carried in the
1088	   <Admission Priority> RMD-QSpec parameter.

1090	4.4.  Transport of RMD-QOSM messages

1092	   The intra-domain messages used by the RMD-QOSM should operate
1093	   in the NTLP/GIST Datagram mode (see [GIST]).  Therefore, the NSLP
1094	   functionality available in all QoS NSLP nodes that are able to
1095	   support the RMD-QOSM MUST require, via the QoS-NSLP RMF API, see
1096	   [QoS-NSLP], from the intra-domain GIST functionality available in
1097	   these nodes to operate in the datagram mode, i.e., require GIST to:

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

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

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

1117	   * When the QNE Ingress has to send an initial intra-domain RESERVE
1118	     message, the QoS-NSLP sends this message by including in the GIST
1119	     API SendMessage primitive, the Unreliable and No security
1120	     attributes. The GIST then, will probably send this NSLP message
1121	     by piggybacking it on a GIST QUERY message. The GIST functionality
1122	     in each QNE Interior node will receive the GIST QUERY message and
1123	     by using the RecvMessage GIST API primitive it will pass the intra-
1124	     domain RESERVE message to the QoS-NSLP functionality. At the same
1125	     time the GIST functionality uses the Routing-State-Check boolean
1126	     to find out if the QoS-NSLP needs to create a routing state. The
1127	     QoS-NSLP sets this Boolean to inform GIST to not create a routing
1128	     state and to forward the GIST QUERY further downstream with the
1129	     modified QoS-NSLP payload, which will include the modified intra-
1130	     domain RESERVE message. The intra-domain RESERVE is sent in the
1131	     same way up to the QNE Egress. The QNE Egress needs to create a
1132	     routing state. Therefore at the moment that the GIST functionality
1133	     passes the intra-domain RESERVE message, via the GIST RecvMessage
1134	     primitive, to the QoS-NSLP, then at the same time the QoS-NSLP
1135	     sets the Routing-State-Check boolean such that a routing state is
1136	     created. The GIST creates the routing state using normal GIST
1137	     procedures. After this phase the QNE Ingress and QNE Egress have,
1138	     for the particular session, routing states that can route traffic
1139	     directly from QNE Ingress to QNE Egress and from QNE Egress to
1140	     QNE Ingress. The routing state at the QNE Egress can be used by
1141	     the QoS-NSLP and GIST to send an intra-domain RESPONSE or intra-
1142	     domain NOTIFY directly to the QNE Ingress using GIST Data
1143	     messages. Note that this routing state is refreshed using normal
1144	     GIST procedures.

1146	   * When the QNE Ingress needs to send an intra-domain RESERVE
1147	     message that is not an initial RESERVE, then the QoS-NSLP sends
1148	     this message by including in the GIST API SendMessage primitive
1149	     the Unreliable and No security attributes. Furthermore the Local
1150	     policy attribute is set such that GIST sends the intra-domain
1151	     RESERVE message in a Q-mode even if there is a routing state at
1152	     the QNE Ingress. In this way the GIST functionality uses its local
1153	     policy to send the intra-domain RESERVE message by piggybacking it
1154	     on a GIST DATA message and sending it in Q-mode even if there is a
1155	     routing state for this session. The intra-domain RESERVE message
1156	     is piggybacked on the GIST DATA message that is forwarded and
1157	     processed by the QNE Interior nodes up to the QNE Egress.

1159	   The transport of the original (end-to-end) RESERVE message is
1160	   accomplished in the following way:
1161	   At the QNE ingress the original (end-to-end) RESERVE message is
1162	   forwarded but ignored by the stateless or reduced-state nodes, see
1163	   Figure 3. The intermediate (interior) nodes are bypassed using
1164	   multiple levels of NSLP-ID values (see [QoS-NSLP]). This is
1165	   accomplished by marking the end-to-end RESERVE message, i.e.,
1166	   modifying the QoS-NSLP default NSLP-ID value to another NSLP-ID
1167	   predefined value.

1169	   The marking MUST be accomplished by the ingress by modifying the
1170	   QoS_NSLP default NSLP-ID value to a NSLP-ID predefined value. In
1171	   This way the egress MUST stop this marking process by reassigning
1172	   the QoS-NSLP default NSLP-ID value to the original (end-to-end)
1173	   RESERVE message. Note that the assignment of these NSLP-ID values is
1174	   a QOS-NSLP issue, which should be accomplished via IANA [QoS-NSLP].

1176	4.5  Edge discovery and message addressing

1178	   Mainly, the Egress node discovery can be performed either by using
1179	   the GIST discovery mechanism [GIST], manual configuration or any
1180	   other discovery technique.  The addressing of signaling messages
1181	   depends on the used GIST transport mode.  The RMD-QOSM/QoS-NSLP
1182	   signaling messages that are processed only by the Edge nodes use the
1183	   peer-peer addressing of the GIST connection (C) mode.  RMD-QOSM/QoS-
1184	   NSLP signaling messages that are processed by all nodes of the
1185	   Diffserv domain, i.e., Edges and Interior nodes, use the end-end
1186	   addressing of the GIST datagram (D) mode. Note that the RMD-QOSM
1187	   cannot directly specify that the GIST connection or the GIST datagram
1188	   mode should be used. This can only be specified by using, via the
1189	   QoS-NSLP-RMF API, the GIST API Transfer-Attributes, such as
1190	   reliable or unreliable, high or low level of
1191	   security and by the use of local policies. RMD QoS signaling
1192	   messages that are addressed to the data path end nodes are
1193	   intercepted by the Egress nodes. In particular, at the ingress and
1194	   for downstream intra-domain messages, the RMD-QOSM instructs the
1195	   GIST functionality, via the GIST API to use among others:

1197	   * unreliable and low level security Transfer-Attributes
1198	   * do not create a GIST routing state
1199	   * uses the D-mode MRI

1201	   The intra-domain RESERVE messages can then be transported by using
1202	   the Query D-mode, see Section 4.4..

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

1208	   *  unreliable and low level of security Transfer-Attributes

1210	   *  The GIST functionality uses the routing state associated with the
1211	      intra-domain session to send an upstream intra-domain message
1212	      directly to the QNE Ingress, see Section 4.4.

1214	4.6.  Operation and sequence of events

1216	4.6.1.  Basic unidirectional operation

1218	   This section describes the basic unidirectional operation and
1219	   sequence of events/triggers of the RMD-QOSM.  The following basic
1220	   operation cases are distinguished:

1222	   * Successful reservation (Section 4.6.1.1),
1223	   * Unsuccessful reservation (Section 4.6.1.2),
1224	   * RMD refresh reservation (Section 4.6.1.3),
1225	   * RMD modification of aggregated reservation (4.6.1.4)
1226	   * RMD release procedure (Section 4.6.1.5.)
1227	   * Severe congestion handling (Section 4.6.1.6.)
1228	   * Admission control using congestion notification based on probing
1229	     (Section 4.6.1.7.).

1231	   The QNEs at the Edges of the RMD domain support the RMD QoS Model and
1232	   end-to-end QoS models, which process the RESERVE message differently.
1233	   Note that the term end-to-end QoS model applies to any QoS model that
1234	   is initiated and terminated outside the RMD-QOSM aware domain.
1235	   However, there might be situations where a QoS model is initiated
1236	   and/or terminated by the QNE Edges and is considered to be an end-to-
1237	   end QoS model. This can occur when the QNE Edges can also operate as
1238	   either QNI or as QNR and at the same time they can operate as either
1239	   sender or receiver of the data path. Note that the described
1240	   functionality described in Sections 4.6.1.1, 4.6.1.2, 4.6.1.3,
1241	   4.6.1.5, and 4.6.1.6 applies to the RMD reservation-based and to
1242	   the NSIS measurement-basedadmission
1243	   control methods. The described functionality in Section 4.6.1.7
1244	   applies to the admission control procedure that uses the congestion
1245	   notification based on probing. The QNE Edge nodes maintain either per
1246	   flow QoS-NSLP operational and reservation states or aggregated QoS-
1247	   NSLP operational and reservation states.

1249	   When the QNE Edges maintain aggregated QoS-NSLP operational and
1250	   reservation states, the RMD-QOSM functionality may accomplish a RMD
1251	   modification procedure (see Section 4.6.1.4), instead of the
1252	   reservation initiation procedure that is described in this
1253	   subsection. Note that it is recommended that the QNE implementations
1254	   of RMD-QOSM process the QoS-NSLP signaling messages with a higher
1255	   priority than data packets. This can be accomplished as described in
1256	   Section 3.3.4 of [QoS-NSLP] and it can be requested via the QoS-NSLP-
1257	   RMF API described in [QoS-NSLP]. The signalling scenarios described
1258	   in this section are accomplished using the QoS-NSLP processing rules
1259	   defined in [QoS-NSLP], in combination with the RMF triggers sent via
1260	   the QoS-NSLP-RMF API described in [QoS-NSLP].

1262	4.6.1.1.  Successful reservation

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

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

1270	4.6.1.1.1. Operation in Ingress node

1272	   When an end-to-end reservation request (RESERVE) arrives at the
1273	   Ingress node (QNE), see Figure 8, it is processed based on the end-
1274	   to-end QoS model.   Subsequently, the RMD QoS Description:
1275	   <Bandwidth>, <PHB Class>, <Admission Priority> are derived from the
1276	   <QoS Desired> object of the initial QSpec.

1278	   The value of the <Bandwidth> parameter used by the RMD-Qspec is found
1279	   by copying the value of the "Peak Data Rate [p]" of the <TMOD-1>
1280	   parameter into the <Bandwidth> parameter.

1282	   If the initial QSpec does not contain the <PHB Class> parameter,
1283	   then the selection of the <PHB class> that is carried by the intra-
1284	   domain RMD-QSpec is defined by a local policy similar to the
1285	   procedures discussed in [RFC2998] and [RFC3175].
1286	   For example, in the situation that the initial QSpec is used by
1287	   the IntServ Controlled Load QOSM then the Expedited Forwarding (EF)
1288	   PHB is appropriate to set the <PHB class> parameter carried by the
1289	   intra-domain RMD-QSpec, see [RFC3175].

1291	   If the initial QSpec does not carry the <Admission Priority>
1292	   parameter then the <Admission Priority> parameter in the RMD-QSpec
1293	   will not be populated. If the initial QSpec does not carry the
1294	   <Admission Priority> parameter, but it carries other priority
1295	   parameters, then it is considered that edges as being stateful nodes,
1296	   are able to control the priority of the sessions that are
1297	   entering or leaving the RMD domain in accordance to the priority
1298	   parameters. Note that the RMF reservation states, see Section 4.3, in
1299	   the QNE edges store the value of the <Admission Priority> parameter
1300	   that is used within the RMD domain in case of pre-emption and severe
1301	   congestion situations, see Section 4.6.1.6.
1302	   If the RMD domain supports pre-emption during the admission control
1303	   process, then the QNE Ingress node can support the building
1304	   blocks specified in the [QoS-NSLP] and during the admission
1305	   control process use the example pre-emption handling algorithm
1306	   described in Appendix 4.
1307	   Note that in the above described case, the QNE egress uses, if
1308	   available, the tunnelled initial priority parameters, which can
1309	   be interpreted by the QNE egress.

1311	   If the initial QSpec carries the <Excess Treatment> parameter,
1312	   then the QNE ingress and QNE egress nodes MUST control the excess
1313	   traffic that is entering or leaving the RMD domain in accordance to
1314	   the <Excess Treatment> parameter. Note that the RMD-QSpec does not
1315	   carry the <Excess Treatment> parameter. However, by using the <PHB
1316	   class> parameter the RMD domain uses the excess treatment procedures
1317	   specified by the particular PHB standard.

1319	   If the requested <TMOD-1> parameter carried by the initial QSpec,
1320	   cannot be satisfied, then an end to end RESPONSE message has to be
1321	   generated. However, in order to decide whether the end-to-end
1322	   reservation request was locally (at the QNE Ingress) satisfied, also
1323	   a local(at the QNE_Ingress) RMD-QoSM admission control procedure has
1324	   to be performed. In other words, the RMD-QOSM functionality has to
1325	   verify whether the value included in the RMD-QOSM <Bandwidth> can be
1326	   reserved and stored in the RMD-QOSM reservation states, see Sections
1327	   4.6.1.1.2 and 4.3.

1329	   An initial QSpec object MUST be included in the end-to-end
1330	   RESPONSE message. The parameters included in the QSpec <QoS
1331	   Reserved> object are copied from the original <QoS Desired> values.
1332	   The "E" flag associated with the QSPEC <QoS Reserved> object and the
1333	   "E" flag associated with the <Bandwidth> parameter are set. In
1334	   addition, the INFO-SPEC object is included in the end to end RESPONSE
1335	   message. The error code used by this INFO-SPEC is:

1337	   Error severity class: Transient Failure
1338	   Error code value: Reservation failure
1339	   Furthermore, all the other RESPONSE parameters are set according to
1340	   the end-to-end QoS model or according to [QoS-NSLP] and [QSP-T].

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

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

1363	   If the QNE Ingress transmitted an intra-domain or end-to-end RESERVE
1364	   message with the RII object set and it fails to receive the
1365	   associated intra-domain or end-to-end RESPONSE, respectively, after
1366	   the QOSNSLP_REQUEST_RETRY period expires, it considers that the
1367	   reservation failed. In this case the QNE Ingress SHOULD generate an
1368	   end-to-end RESPONSE message that will include among others an
1369	   INFO-SPEC object. The error code used by this INFO-SPEC is:
1370	      Error severity class: Transient Failure
1371	      Error code value: Reservation failure

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

1376	   Note however, that if the retransmission within the RMD domain is not
1377	   disallowed then the procedure described in Appendix
1378	   A.5 SHOULD be used on QNE Interior nodes, see also [Chan07]. In this
1379	   case the stateful QNE Ingress uses the retransmission procedure
1380	   described in [QoS-NSLP].

1382	   If a rerouting takes place then the stateful QNE
1383	   ingress is following the procedures specified in [QoS-NSLP].

1385	   At this point the intra-domain and end-to-end operational states MUST
1386	   be initiated or modified according to the required binding
1387	   procedures.

1389	   The way of how the BOUND_SESSION_IDs are initiated and maintained in
1390	   the intra-domain and end-to-end QoS-NSLP operational states is
1391	   described in Section 4.3.1 and 4.3.2.

1393	   These two messages are bound together in the following way. The end-
1394	   to-end RESERVE SHOULD contain in the BOUND_SESSION_ID the SESSION_ID
1395	   of its bound intra-domain session.

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

1401	   In addition to this then the intra-domain and end-to-end RESERVE
1402	   messages are bound using the Message binding procedure described
1403	   in [QoS-NSLP]. In particular the <MSG_ID> object is included
1404	   in the intra-domain RESERVE message and its bound <BOUND_MSG_ID>
1405	   object is carried by the end-to-end RESERVE message. Furthermore, the
1406	   Message_Binding_Type flag is SET (value is 1), such that the message
1407	   dependency is bi-directional.

1409	    If the QOS-NSLP edges maintain aggregated intra-domain QoS-NSLP
1410	   operational states then the value of Binding_Code MUST be set to code
1411	   "Aggregated sessions".
1412	    Furthermore, in this case the retransmission within the RMD domain
1413	    SHOULD NOT be disallowed and the procedures described in Appendix
1414	    A.5 SHOULD be used on QNE Interior nodes. This is necessary due to
1415	    the fact that when retransmissions are disallowed then the
1416	    associated with (micro) flows belonging to the aggregate will loose
1417	    their reservations. Note that in this case the stateful QNE Ingress
1418	    uses the retransmission procedure described in [QoS-NSLP].

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

1431	   If no QOS-NSLP aggregation procedure at the QNE Edges is supported
1432	   then the IP source and IP destination address of this message MUST be
1433	   equal to the IP Source and IP destination addresses of the data flow.
1434	   The intra-domain RESERVE message is sent using the NTLP datagram
1435	   mode (see Sections 4.4, 4.5). Note that the GIST datagram mode can be
1436	   selected using the unreliable GIST API Transfer-Attributes. In
1437	   addition, the intra-domain RESERVE (RMD-QSpec) message MUST include a
1438	   PHR container (PHR_Resource_Request) and the "RMD-QOSM object
1439	   combination".

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

1444	   Note that after completing the initial discovery phase, the GIST
1445	   connection mode can be used between the QNE Ingress and QNE Egress.
1446	   Note that the GIST connection mode can be selected using the reliable
1447	   GIST API Transfer-Attributes.

1449	   The end-to-end RESERVE message is forwarded using the GIST
1450	   forwarding procedure to bypass the Interior stateless or reduced-
1451	   state QNE nodes, see Figure 8.  The bypassing procedure is
1452	   described in Section 4.4. At the QNE Ingress the end-to-end RESERVE
1453	   message is marked, i.e., modifying the QoS-NSLP default NSLP-ID value
1454	   to another NSLP-ID predefined value that will be used by the GIST
1455	   message carrying the end-to-end RESPONSE message to bypass the QNE
1456	   Interior nodes. Note that the QNE Interior nodes, see [GIST], are
1457	   configured to handle only certain NSLP-Ids, see [QoS-NSLP].

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

1466	   The (initial) intra-domain RESERVE message MUST be sent by the QNE
1467	   Ingress and it MUST contain the following values (see QoS-NSLP-RMF
1468	   API described in [QoS-NSLP]):
1469	   *  the value of the <RSN> object is generated and processed as
1470	      described in [QoS-NSLP];

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

1477	   *  the <RII> MUST be included in this message, see [QoS-NSLP].

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

1481	*  The value of the Message ID value carried by the <MSG_ID> object
1482	   is set according to [QoS-NSLP]. The value of the
1483	   Message_binding_Type is set to "1".

1485	*  the value of the <REFRESH_PERIOD> object MUST be calculated
1486	   and set by the QNE Ingress node as described in Section 4.6.1.3;

1488	*  the value of the <PACKET_CLASSIFIER> object is associated with
1489	   the path-coupled routing MRM, since RMD-QOSM is used with the
1490	   path-coupled MRM. The flag that has to be set is
1491	   the flag T (traffic class) meaning that the packet classification
1492	   of packets is based on the DSCP value included in the IP header of
1493	   the packets. Note that the DSCP value used in the MRI can be
1494	   derived by the value of <PHB class> parameter, which MUST be
1495	   carried by the intra-domain RESERVE message. Note that the QNE
1496	   Ingress being a QNI for the intra-domain session it can pass this
1497	   value to GIST, via the GIST API.

1499	*  the PHR resource units MUST be included into the <Bandwidth>
1500	   parameter of the "<QoS Desired> object. When the QNE edges
1501	   use per flow intra-domain QoS-NSLP states, then the value of the
1502	   <Bandwdith> parameter can be obtained by using the method of
1503	   copying the peak rate (p) field included in the <TMOD-1> parameter
1504	      carried by the initial QSpec into this <Bandwidth> parameter,
1505	      which is described above in this subsection. When the QNE edges
1506	      use aggregated intra-domain QoS-NSLP operational states, then the
1507	      value of the <Bandwdith> parameter can be obtained by using the
1508	      bandwidth aggregation method described in Section 4.3.1;

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

1515	   *  the value of the Parameter/Container ID field of the PHR container
1516	      MUST be set to PHR_1, (i.e., PHR_Resource_Request;)

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

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

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

1528	   * If the initial QSpec carried an <Admission Priority>
1529	     parameter, then this parameter should be copied into the RMD-QSpec
1530	     and carried by the
1531	     (initiating) intra-domain RESERVE. Note that for the RMD-QOSM a
1532	     reservation established without an <Admission Priority> parameter
1533	     is equivalent to a reservation with <Admission Priority> value 1.
1534	     Note that in this case each admission priority is associated with
1535	     a priority traffic class. The three priority traffic classes
1536	     (PHB_low_priority, PHB_normal_priority, PHB_high_priority) may be
1537	     associated with the same PHB, see Section 4.3.3.

1539	   *  In a single RMD domain case the PDR container MAY not be included
1540	      into the message.

1542	   Note that the intra-domain RESERVE message does not carry the
1543	   BOUND_SESSION_ID object. The reason of this is that the end-to-end
1544	   RESERVE carries in the BOUND_SESSION_ID object the SESSION_ID value
1545	   of the intra-domain session.

1547	   When an end-to-end RESPONSE message is received by the QNE
1548	   Ingress node, which was sent by a QNE Egress node see Section
1549	   4.6.1.1.3, then it is processed according to [QoS-NSLP]
1550	   and end-to-end QoS model rules.

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

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

1561	   Furthermore, the INFO_SPEC object is processed as defined in the
1562	   QoS-NSLP specification. In case of successful reservation the
1563	   INFO_SPEC object MUST have the following values:

1565	   * Error Severity Class: Success
1566	   * Error Code value: Reservation successful

1568	   If the end-to-end RESPONSE message has to be forwarded to a
1569	   node outside the RMD-QOSM aware domain then the values of
1570	   the objects contained in this message (i.e., <RII/RSN>, <INFO_SPEC>,
1571	   [QSPEC ]) MUST be set by the QOS-NSLP protocol functions
1572	   of the QNE. If an end-to-end QUERY is received by the QNE Ingress
1573	   then the same bypassing procedure has to be used as the one applied
1574	   for an end-to-end RESERVE message. In particular, it is forwarded
1575	   using the GIST forwarding procedure to bypass the Interior stateless
1576	   or reduced-state QNE nodes.

1578	4.6.1.1.2 Operation in the Interior nodes

1580	   Each QNE Interior node MUST use the QoS-NSLP and RMD-QOSM parameters
1581	   of the intra-domain RESERVE (RMD-QSpec) message as follows (see
1582	   QoS-NSLP-RMF API described in [QoS-NSLP]):

1584	  *   the values of the <RSN>, <RII>, <PACKET_CLASSIFIER>,
1585	      <REFRESH_PERIOD>, objects MUST NOT be changed.
1586	      The interior node is informed by the <PACKET_CLASSIFIER> object
1587	      that the packet classification should be done on the DSCP value.
1588	      The flag that has to be set in this case is the flag T (traffic
1589	      class). The value of the DSCP value MUST
1590	      be obtained via the MRI parameters that the QoS-NSLP receives from
1591	      GIST. A QNE Interior MUST be able to associate the value carried
1592	      by the RMD-QSpec <PHB class> parameter and the DSCP value obtained
1593	      via GIST. This is required, because there are situations that the
1594	      <PHB class> parameter is not carrying a DSCP value, but a "PHB ID
1595	      code", see Section 4.1.1.

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

1599	   *  when the RMD reservation based methods described in Section 4.3.1
1600	      and 4.3.3 are used, the value of <Bandwidth> parameter of the "RMD
1601	      QoS Description" field is used by the QNE Interior node for
1602	      admission control. Furthermore, if the <Admission Priority>
1603	      parameter is carried by the  <QoS Desired> object, then this
1604	      parameter is processed as described in the following bullets.

1606	   *  in case of the RMD reservation-based procedure, and if these
1607	      resources are admitted (see Section 4.3.1, 4.3.3), they are added
1608	      to the currently reserved resources. Furthermore, the value of the
1609	      <Admitted Hops> parameter in the PHR container has to be increased
1610	      by one.

1612	   *  If the bandwidth allocated for the PHB_high_priority traffic is
1613	      fully utilized, and a high priority request arrives, other
1614	      policies on allocating bandwidth can be used, which are beyond the
1615	      scope of this document.

1617	   *  If the RMD domain supports pre-emption during the admission
1618	      control process, then the QNE Interior node can support the
1619	      building blocks specified in the [QoS-NSLP] and during the
1620	      admission control process use the pre-emption handling algorithm
1621	      specified in Appendix 4.

1623	   *  in case of the RMD measurement based method (see Section 4.3.2),
1624	      and if the requested value of the <Bandwidth> parameter is
1625	      admitted, using a MBAC algorithm, then the number of this
1626	      resources will be used to update the MBAC algorithm according to
1627	      the operation described in Section 4.3.2.

1629	4.6.1.1.3 Operation in the Egress node

1631	   When the end-to-end RESERVE message is received by the egress node,
1632	   it is only forwarded further, towards QNR, if the processing of the
1633	   intra-domain RESERVE(RMD-QSpec) message was successful at all nodes
1634	   in the RMD domain. In this case, the QNE Egress MUST stop the marking
1635	   process that was used to bypass the QNE Interior nodes by reassigning
1636	   the QoS-NSLP default NSLP-ID value to the end-to-end RESERVE message,
1637	   see Section 4.4. Furthermore, the carried BOUND_SESSION_ID object
1638	   associated with the intra-domain session MUST be removed after
1639	   processing. Note that the received end to end RESERVE was tunneled
1640	   within the RMD domain. Therefore, the tunnelled initial QSpec
1641	   carried by the end-to-end RESERVE message has to be processed/set
1642	   according to the [QSP-T] specification.

1644	   If a rerouting takes place, then the stateful QNE egress is following
1645	   the procedures specified in [QoS-NSLP].
1646	   At this point the intra-domain and end-to-end operational states MUST
1647	   be initiated or modified according to the required binding
1648	   procedures.

1650	   The way of how the BOUND_SESSION_IDs are initiated and maintained in
1651	   the intra-domain and end-to-end QoS-NSLP operational states is
1652	   described in Section 4.3.1 and 4.3.2.

1654	   If the processing of the intra-domain RESERVE(RMD-QSpec) was not
1655	   successful at all nodes in the RMD domain then the inter-domain (end-
1656	   to-end) reservation is considered as being failed. Furthermore, note
1657	   that when the QNE Egress uses per flow intra-domain QoS-NSLP
1658	   operational states, see Sections 4.3.2 and 4.3.3, the QNE Egress
1659	   should support the message binding procedure described in [QoS-NSLP],
1660	   which can be used to synchronize the arrival of the end to end
1661	   RESERVE and the intra-domain RESERVE (RMD-QSpec) messages, see
1662	   Section 5.7 and QoS-NSLP-RMF API described in [QoS-NSLP]. Note that
1663	   the intra-domain RESERVE message carries the <MSG_ID> object and its
1664	   bound end-to-end RESERVE message carries the <BOUND_MSG_ID> object.
1665	   Both these objects carry the Message_Binding_Type flag set to the
1666	   value of 1. If these two messages do not arrive during the time
1667	   defined by the MsgIDWait timer, then the reservation is considered as
1668	   being failed. Note that the timer has to be pre-configured and it has
1669	   to have the same value in the RMD domain. In this case an end-to-end
1670	   RESPONSE message, see QoS-NSLP-RMF API described in [QoS-NSLP], is
1671	   sent towards the QNE ingress with the following INFO_SPEC values:

1673	   Error Class: Transient Failure
1674	   Error Code: Mismatch synchronization between end-to-end RESERVE
1675	   and intra-domain RESERVE
1676	   When the intra-domain RESERVE(RMD-QSpec) is received by the QNE
1677	   Egress node of the session associated with the intra-domain
1678	   RESERVE(RMD-QSpec) (the PHB session) with the session included in
1679	   its <BOUND_SESSION_ID> object MUST be bound according to the
1680	   specification given in [QoS-NSLP].  The SESSION_ID included
1681	   in the BOUND_SESSION_ID parameter stored in the intra-domain QoS-NSLP
1682	   operational state object is the SESSION_ID of the session associated
1683	   with the end-to-end RESERVE message(s). Note that if the QNE Edge
1684	   nodes maintain per flow intra-domain QoS NSLP operational states then
1685	   the value of Binding_Code = (Tunnel and end-to-end sessions) is used
1686	   If the QNE Edge nodes maintain per aggregated QoS-NSLP intra-domain
1687	   reservation states then the value of Binding_Code = (Aggregated
1688	   sessions), see Sections 4.3.1, 4.3.2.

1690	   If the RMD domain supports pre-emption during the admission control
1691	   process, then the QNE Egress node can support the building
1692	   blocks specified in the [QoS-NSLP] and during the admission
1693	   control process use the example pre-emption handling algorithm
1694	   described in Appendix 4.
1695	   The end-to-end RESERVE message is generated/forwarded further
1696	   upstream according to the [QoS-NSLP] and [QSP-T] specifications.

1698	   Furthermore, the "B" (BREAK) QoS-NSLP flag in the end to end
1699	   RESERVE message MUST NOT be set, see QoS-NSLP-RMF API described in
1700	   QoS-NSLP.

1702	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
1703	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1704	    |                    |                   |                    |
1705	RESERVE                  |                   |                    |
1706	--->|                    |                   |     RESERVE        |
1707	    |------------------------------------------------------------>|
1708	    |RESERVE(RMD-QSpec)  |                   |                    |
1709	    |------------------->|                   |                    |
1710	    |                    |RESERVE(RMD-QSpec) |                    |
1711	    |                    |------------------>|                    |
1712	    |                    |                   | RESERVE(RMD-QSpec) |
1713	    |                    |                   |------------------->|
1714	    |                    |RESPONSE(RMD-QSpec)|                    |
1715	    |<------------------------------------------------------------|
1716	    |                    |                   |                RESERVE
1717	    |                    |                   |                    |-->
1718	    |                    |                   |                RESPONSE
1719	    |                    |                   |                    |<--
1720	    |                    |RESPONSE           |                    |
1721	    |<------------------------------------------------------------|
1722	RESPONSE                 |                   |                    |
1723	<---|                    |                   |                    |

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

1728	 The QNE Egress MUST generate an intra-domain RESPONSE (RMD-Qspec)
1729	 message. The intra-domain RESPONSE (RMD-QSpec) message MUST
1730	 be sent to the QNE Ingress node, i.e., the previous stateful hop by
1731	 using the procedures described in Sections 4.4 and 4.5.
1732	 The values of the RMD-QSpec that is carried by the intra-domain
1733	 RESPONSE message MUST be used and/or set in the following way (see QoS-
1734	 NSLP-RMF API described in [QoS-NSLP]):

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

1740	   *  the value of the Parameter/Container ID field of the PDR container
1741	      MUST be set "PDR_7" (i.e., PDR_Reservation_Report);

1743	   *  the value of the <M> field of the PDR container MUST be equal to
1744	      the value of the <M> parameter of the PHR container that was
1745	      carried by its associated intra-domain RESERVE(RMD-QSpec)
1746	      message. This is required since the value of the <M> parameter is
1747	      used to indicate the status if the RMD reservation request to the
1748	      Ingress edge.

1750	   If the binding between the intra-domain session and the end-to-end
1751	   session uses a Binding_Code is (Aggregated sessions), and there is no
1752	   aggregated QoS-NSLP operational state associated with the intra-
1753	   domain session available, then the RMD
1754	   modification of aggregated reservation procedure described in Section
1755	   4.6.1.4. can be used.

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

1763	   * the values of the <RII/RSN>, <INFO_SPEC>, [ QSPEC ] objects are
1764	     set according to [QoS-NSLP] and/or [QSP-T]. The INFO_SPEC object
1765	     SHOULD be set by the QoS-NSLP functionality. In case of successful
1766	     reservation the INFO_SPEC object SHOULD have the following values:
1767	     Error Severity Class: Success,
1768	     Error Code value: Reservation successful,

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

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

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

1785	4.6.1.2.  Unsuccessful reservation

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

1790	   The QNE Ingress, the QNE Interior and QNE Egress nodes process and
1791	   forward the end-to-end RESERVE message and the intra-domain
1792	   RESERVE(RMD-QSpec) message in a similar way as specified in Section
1793	   4.6.1.1.  The main difference between the unsuccessful operation and
1794	   successful operation is that one of the QNE nodes does not admit the
1795	   request due to lack of resources.  This also means that the QNE edge
1796	   node MUST NOT forward the end-to-end RESERVE message towards the
1797	   QNR node.

1799	   Note that the described functionality applies to the RMD reservation-
1800	   based methods, see Sections 4.3.1, 4.3.2, and to the NSIS
1801	   measurement-based admission control method, see Section 4.3.2.
1802	   The QNE Edge nodes maintain either per flow QoS-NSLP reservation
1803	   states or aggregated QoS-NSLP reservation states. When the QNE edges
1804	   maintain aggregated QoS-NSLP reservation states, the RMD-QOSM
1805	   functionality may accomplish a RMD modification procedure (see
1806	   Section 4.6.1.4.), instead of the reservation initiation procedure
1807	   that is described in this subsection.

1809	4.6.1.2.1 Operation in the Ingress nodes

1811	   When an end-to-end RESERVE message arrives at the QNE Ingress and
1812	   if there are no resources available, the QNE Ingress MUST
1813	   reject this end-to-end RESERVE message and send an end-to-end
1814	   RESPONSE message back to the sender, as described in the QoS-NSLP
1815	   specification, see [QoS-NSLP] and [QSP-T].

1817	   When an end-to-end RESPONSE message is received by an Ingress
1818	   node, see Section 4.6.1.2.3, the values of the <RII/RSN>,
1819	   [<INFO_SPEC> ], [<QSPEC>] objects are processed according to the QoS-
1820	   NSLP procedures.

1822	   If the end-to-end RESPONSE message has to be forwarded upstream to a
1823	   node outside the RMD-QOSM aware domain then the values of
1824	   the objects contained in this message (i.e., <RII/RSN>, <INFO_SPEC>,
1825	   [ QSPEC ]) MUST be set by the QOS-NSLP protocol functions of the QNE.

1827	   When an intra-domain RESPONSE message is received by the QNE Ingress
1828	   node, which was sent by a QNE Egress, see Section 4.6.1.2.3, it uses
1829	   the QoS-NSLP procedures to match it to the earlier sent intra-domain
1830	   RESERVE message. After this phase, the RMD-QSpec has to be identified
1831	   and processed. Note that in this case the RMD Resource Management
1832	   Function (RMF) is notified that the reservation has been
1833	   unsuccessful, by reading the <M> parameter of the PDR container.
1834	   Note that when the QNE edges maintain a per flow QoS-NSLP reservation
1835	   state the RMD-QOSM functionality, has to start an RMD release
1836	   procedure (see Section 4.6.1.5). When the QNE edges maintain
1837	   aggregated QoS-NSLP reservation states the RMD-QOSM functionality MAY
1838	   start a RMD modification procedures (see Section 4.6.1.4.).

1840	4.6.1.2.2 Operation in the Interior nodes

1842	   In case of the RMD reservation based scenario, and if the
1843	   intra-domain reservation request is not admitted by the QNE Interior
1844	   node then the <Hop_U> and <M> parameters of the PHR container MUST be
1845	   set to "1".  The <Admitted Hops> counter MUST NOT be increased.
1846	   Moreover, the value of the <Max Admitted Hops> MUST be set equal to
1847	   the <Admitted Hops> value.
1848	   Furthermore, the "E" flag associated with the QSpec <QoS Desired>
1849	   object and the "E" flag associated with the <Bandwidth> parameter
1850	   SHOULD be set. In case of the RMD measurement based scenario, the
1851	   <M> parameter of the PHR container MUST be set to "1". Furthermore,
1852	   the "E" flag associated with the QSpec <QoS Desired> object and the
1853	   "E" flag associated with the <Bandwidth> parameter SHOULD be set.
1854	   Note that the <M> flag seems to be set in a similar way as the "E"
1855	   flag used by the <Bandwidth> parameter. However, the ways of how the
1856	   two flags are processed by a QNE are different.

1858	   In general, if a QNE Interior node receives a QSpec <Bandwidth>
1859	   parameter with the "E" flag set and a PHR container type
1860	   "PHR_Resource_Request", with the <M> parameter set to "1" , then this
1861	   "PHR Container" and the "RMD-QoSM object combination" (i.e., RMD-QOSM
1862	   <QoS Desired> object) MUST NOT be processed. Furthermore, when the
1863	   <K> parameter that is included in the "PHR Container" and carried by
1864	   a RESERVE message is set to "1", then this "PHR Container" and the
1865	   "RMD QoS Description" (i.e., RMD-QOSM <QoS Desired> object) MUST NOT
1866	   be processed.

1868	4.6.1.2.3 Operation in the Egress nodes

1870	   In the RMD reservation based, see Sections 4.3.3, and the RMD NSIS
1871	   measurement based scenario, see Section 4.3.2, when the <M> marked
1872	   intra-domain RESERVE(RMD-QSpec) is received by the QNE Egress node
1873	   (see Figure 9) the session associated with the intra-domain
1874	   RESERVE(RMD-QSpec) (the PHB session) and the end-to-end session MUST
1875	   be bound.

1877	   When the QNE Egress uses per flow intra-domain QoS-NSLP operational
1878	   states, see Section 4.3.2 and 4.3.3, then the QNE Egress node MUST
1879	   generate an end-to-end RESPONSE message that has to be sent to its
1880	   previous stateful QoS-NSLP hop (see QoS-NSLP-RMF API described in
1881	   [QoS-NSLP]).

1883	   *  the values of the <RII/RSN>, <INFO_SPEC> objects are set
1884	      by the standard QoS-NSLP protocol functions. In case of the
1885	      unsuccessful reservation the INFO_SPEC object SHOULD have the
1886	      following values:
1887	      Error Severity Class: Transient Failure
1888	      Error Code value: Reservation failure

1890	   The QSpec that was carried by the end to end RESERVE belonging to the
1891	   same session as this end-to-end RESPONSE is included in this message.

1893	   In particular, the parameters included in the QSpec <QoS Reserved>
1894	   object of the end-to-end RESPONSE message are copied
1895	   from the initial <QoS Desired> values included in its associated
1896	   end-to-end RESERVE message. The "E" flag associated with
1897	   the QSpec <QoS Reserved> object and the "E" flag associated with the
1898	   <TMOD-1> parameter included in the end-to-end RESPONSE are set.

1900	QNE (Ingress)    QNE (Interior)       QNE (Interior)      QNE (Egress)
1901	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1902	    |                    |                   |                    |
1903	RESERVE                  |                   |                    |
1904	--->|                    |                   |     RESERVE        |
1905	    |------------------------------------------------------------>|
1906	    |RESERVE(RMD-QSpec:M=0)                  |                    |
1907	    |------------------->|                   |                    |
1908	    |                    |RESERVE(RMD-QSpec:M =1)                 |
1909	    |                    |------------------>|                    |
1910	    |                    |                   | RESERVE(RMD-QSpec:M=1)
1911	    |                    |                   |------------------->|
1912	    |                    |RESPONSE(RMD-QOSM) |                    |
1913	    |<------------------------------------------------------------|
1914	    |                    |RESPONSE           |                    |
1915	    |<------------------------------------------------------------|
1916	RESPONSE                 |                   |                    |
1917	<---|                    |                   |                    |
1918	RESERVE(RMD-QSpec: Tear=1, M=1, <Admitted Hops>=<Max Admitted Hops>
1919	    |------------------->|                   |                    |
1920	                         |RESERVE(RMD-QSpec: Tear=1, M=1, K=1)    |
1921	    |                    |------------------>|                    |
1922	                         |    RESERVE(RMD-QSpec: Tear=1, M=1, K=1)|
1923	    |                    |                   |------------------->|

1925	Figure 9: Basic operation during unsuccessful reservation
1926	          initiation used by the RMD-QOSM

1928	   In addition to the above, similarly to the successful operation,
1929	   see Section 4.6.1.1.3, the QNE Egress MUST generate an intra-domain
1930	   RESPONSE message that has to be sent to its previous stateful QoS-
1931	   NSLP hop. The values of the <RII/RSN>, <INFO_SPEC> objects are set by
1932	   the standard QoS-NSLP protocol functions. In case of the unsuccessful
1933	   reservation the INFO_SPEC object SHOULD have the following values
1934	   (see QoS-NSLP-RMF API described in [QoS-NSLP]):

1936	      Error Severity Class: Transient Failure
1937	      Error Code value: Reservation failure

1939	   The values of the RMD-QSpec MUST be used and/or set
1940	   in the following way (see QoS-NSLP-RMF API described in [QoS-NSLP]):

1942	   *  the value of the <PDR Control Type> of the PDR container MUST be
1943	      set to "PDR_7" (PDR_Reservation_Report);

1945	   *  the value of the <Max Admitted Hops> parameter of the PHR
1946	       container included in the received <M> marked intra-domain
1947	      RESERVE (RMD-QSpec)  MUST be included
1948	      in the <Max Admitted Hops> parameter of the PDR container;

1950	   *  the value of the <M> parameter of the PDR container MUST be "1".

1952	4.6.1.3 RMD refresh reservation

1954	   In case of RMD measurement-based method, see Section 4.3.2, QoS-NSLP
1955	   reservation states in the RMD domain are typically not maintained,
1956	   therefore, this method typically does not use an intra-domain refresh
1957	   procedure. However, there are measurement based optimization schemes,
1958	   see [GrTs03], which may use the refresh procedures described in
1959	   Sections 4.6.1.3.1, and 4.6.1.3.3. However, this measurement based
1960	   optimization schemes can only be applied in the RMD domain if the QNE
1961	   edges are configured to perform intra-domain refresh procedures and
1962	   if all the QNE interior nodes are configured to perform the
1963	   measurement based optimization schemes. In the description given in
1964	   this subsection it is assumed that the RMD measurement based scheme
1965	   does not use the refresh procedures.

1967	   When the QNE edges maintain aggregated or per flow QoS-NSLP
1968	   operational and reservation states, see Sections 4.3.1 and 4.3.3,
1969	   then the refresh procedures are very similar. If the RESERVE messages
1970	   arrive within the soft state time-out period, the corresponding
1971	   number of resource units are not removed. However, the transmission
1972	   of the intra-domain and end-to-end (refresh) RESERVE message are not
1973	   necessarily synchronized. Furthermore, the generation of the end-to-
1974	   end RESERVE message, by the QNE edges, depends on the locally
1975	   maintained refreshed interval (see [QoS-NSLP]).

1977	4.6.1.3.1 Operation in the Ingress node

1979	   The Ingress node MUST be able to generate an intra-domain (refresh)
1980	   RESERVE(RMD-QSpec) at any time defined by the refresh period/timer.
1981	   Before generating this message, the RMD QoS signaling model
1982	   functionality is using the RMD traffic class (PHR) resource units for
1983	   refreshing the RMD traffic class state.

1985	   Note that the RMD traffic class refresh periods MUST be equal in
1986	   all QNE edge and QNE Interior nodes and SHOULD be smaller (default:
1987	   more than two times smaller) than the refresh period at the QNE
1988	   Ingress node used by the end-to-end RESERVE message. The intra-domain
1989	   RESERVE (RMD-QSpec) message MUST include a "RMD-QOSM object
1990	   combination" (i.e., RMD-QOSM <QoS Desired>) and a PHR container
1991	   (i.e., PHR_Refresh_Update).

1993	   An example of this refresh operation can be seen in Figure 10.

1995	QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)
1996	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1997	    |                    |                   |                    |
1998	    |RESERVE(RMD-QSpec)  |                   |                    |
1999	    |------------------->|                   |                    |
2000	    |                    |RESERVE(RMD-QSpec) |                    |
2001	    |                    |------------------>|                    |
2002	    |                    |                   | RESERVE(RMD-QSpec) |
2003	    |                    |                   |------------------->|
2004	    |                    |                   |                    |
2005	    |                    |RESPONSE(RMD-QSpec)|                    |
2006	    |<------------------------------------------------------------|
2007	    |                    |                   |                    |

2009	   Figure 10: Basic operation of RMD specific refresh procedure

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

2016	  *  the PHR resource units MUST be included into the <Bandwidth>
2017	     parameter. The value of the <Bandwidth> parameter depends on
2018	     how the different inter domain (end-to-end) flows are aggregated
2019	     by the QNE Ingress node (e.g., the sum of all the PHR requested
2020	     resources of the aggregated flows), see Section 4.3.1.  If no
2021	     QOS-NSLP aggregation is accomplished by the QNE Ingress node, the
2022	     value of the <Bandwidth> parameter SHOULD be equal to the
2023	     <Bandwidth> parameter of its associated new (initial) intra-domain
2024	     RESERVE (RMD-QSpec) message, see Section 4.3.3. ;

2026	   *  the value of the Parameter/Container field of the "PHR Container"
2027	       MUST be set to "PHR_2",
2028	      i.e., "PHR_Refresh_Update";

2030	   When the intra-domain RESPONSE (RMD-QSpec) message, see Section
2031	   4.6.1.3.3., is received by the QNE Ingress node, then:

2033	   *  the values of the <RII/RSN>, <INFO_SPEC>, [QSP-T] objects are
2034	      processed by the standard QoS-NSLP protocol functions (see Section
2035	      4.6.1.1.);

2037	   *  the "PDR Container" has to be processed by the RMD-QOSM
2038	      functionality in the QNE Ingress node.  The RMD-QOSM functionality
2039	      is notified by the <PDR M> parameter of the PDR container
2040	      that the refresh procedure has been successful or unsuccessful.
2041	      All session(s) (when aggregated QoS-NSLP operational and
2042	      reservation states are used, see Section 4.3.1, there
2043	      will be more than one sessions) associated with this RMD specific
2044	      refresh session MUST be informed about the success or failure of
2045	      the refresh procedure.  In case of failure, the QNE Ingress node
2046	      has to generate (in a standard QoS-NSLP way) an error end-to-end
2047	      RESPONSE message that will be sent towards QNI.

2049	4.6.1.3.2 Operation in the Interior node

2051	   The intra-domain RESERVE (RMD-QSpec) message is received and
2052	   processed by the QNE Interior nodes.  Any QNE edge or QNE Interior
2053	   node that receives a "PHR_Refresh_Update" field
2054	   MUST identify the traffic class state (PHB) (using the
2055	   <PHB Class> parameter).  Most of the parameters in this refresh
2056	   intra-domain RESERVE (RMD-QSpec) message MUST be used and/or set by
2057	   a QNE Interior node in the same way as described in Section 4.6.1.1.

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

2061	   * the value of <Bandwidth> parameter of the "RMD-QOSM object
2062	     combination" (i.e., the RMD-QOSM <QoS Desired>)
2063	     is used by the QNE Interior node for refreshing the RMD
2064	     traffic class state. These resources (included in <Bandwidth>),
2065	     if reserved, are added to the currently reserved resources
2066	     per PHB and therefore they will become a part of the per traffic
2067	     class (per-PHB) reservation state, see Sections 4.3.1 and 4.3.3. If
2068	     the refresh procedure cannot be fulfilled then the <M> and <S>
2069	     fields carried by the PHR container MUST be set to "1".

2071	   * Furthermore, the "E" flag associated with <QoS Desired> object and
2072	     the "E" flag associated with the <Bandwidth> parameter SHOULD be
2073	     set.

2075	   Any PHR container of type "PHR_Refresh_Update", and its associated
2076	   "RMD-QOSM object combination" (i.e., <Bandwidth>), whether it is
2077	   marked or not and independent of the "E" flag value of the
2078	   <Bandwdith> parameter, is always processed, but marked bits are not
2079	   changed.

2081	4.6.1.3.3 Operation in the Egress node

2083	   The intra-domain RESERVE(RMD-QSpec) message is received and
2084	   processed by the QNE Egress node.  A new intra-domain RESPONSE
2085	   (RMD-QSpec) message is generated by the QNE Egress node and MUST
2086	   include a PDR (type PDR_Refresh_Report).

2088	   The (refresh) intra-domain RESPONSE (RMD-QSpec) message MUST be sent
2089	   to the QNE Ingress node, i.e., the previous stateful hop. The
2090	   (refresh) intra-domain RESPONSE (RMD-QSpec) message MUST be
2091	   explicitly routed to the QNE Ingress node, i.e., the previous
2092	   stateful hop, using the procedures described in Section 4.5.

2094	   *  the values of the <RII/RSN>, <INFO_SPEC> objects are set
2095	     by the standard QoS-NSLP protocol functions, see [QoS-NSLP].

2097	   * The value of the <PDR Control Type> parameter of the PDR container
2098	     MUST be set "PDR_8" (i.e. PDR_Refresh_Report).
2099	     In case of successful reservation the INFO_SPEC object SHOULD
2100	     have the following values:
2101	     Error Severity Class: Success
2102	     Error Code value: Reservation successful

2104	   * In case of unsuccessful reservation the INFO_SPEC object SHOULD
2105	     have the following values:
2106	     Error Severity Class: Transient Failure
2107	     Error Code value: Reservation failure

2109	   The RMD-QSpec that was carried by the intra-domain RESERVE
2110	   belonging to the same session as this intra-domain RESPONSE is
2111	   included in the intra-domain RESPONSE message. The parameters
2112	   included in the QSPec <QoS Reserved> object are copied from the
2113	   original <QoS Desired> values. If the reservation is unsuccessful
2114	   then "E" flag associated with the QSpec <QoS Reserved> object and the
2115	   "E" flag associated with the <Bandwidth> parameter are set.
2116	    Furthermore, the <M> and <S> PDR Container bits are set to "1".

2118	4.6.1.4.  RMD modification of aggregated reservations

2120	   In the case when the QNE edges maintain QoS-NSLP aggregated
2121	   operational and reservation states and the aggregated reservation has
2122	   to be modified (see Section 4.3.1) the following procedure is
2123	   applied:

2125	   * When the modification request requires an increase of the reserved
2126	     resources, the QNE Ingress node MUST include the corresponding
2127	     value into the <Bandwidth> parameter of the "RMD-QOSM object
2128	     combination", (i.e., the RMD-QOSM <QoS Desired>)
2129	     which is sent together with a "PHR_Resource_Request" control
2130	     information.  If a QNE edge or QNE Interior node is not able to
2131	     reserve the number of requested resources, the
2132	     "PHR_Resource_Request" that is associated with
2133	     the <Bandwidth> parameter MUST be <M> marked, i.e., the <M> bit is
2134	     set to the value of "1".  In this situation the
2135	     RMD specific operation for unsuccessful reservation will be applied
2136	     (see Section 4.6.1.2).

2138	   * When the modification request requires a decrease of the
2139	     reserved resources, the QNE Ingress node MUST include this value
2140	     into the <Bandwidth> parameter of the "RMD-QOSM object combination"
2141	     (i.e., the RMD-QOSM <QoS Desired>). Subsequently an RMD release
2142	     procedure SHOULD be accomplished (see Section 4.6.1.5). Note that
2143	     if the complete bandwidth associated with the aggregated
2144	     reservation maintained at the QNE ingress does not have to be
2145	     released then the TEAR flag MUST be set to OFF. This is because the
2146	     NSLP operational states associated with the aggregated reservation
2147	     states at the edge QNEs must not be turned off. However, if the
2148	     complete bandwidth associated with the aggregated reservation
2149	     maintained at the QNE ingress has to be released, then the TEAR
2150	     flag MUST be set to ON.

2152	4.6.1.5  RMD release procedure

2154	   This procedure is applied to all RMD mechanisms that maintain
2155	   reservation states. If a refresh RESERVE message does not arrive at a
2156	   QNE Interior node within the refresh time-out period then the
2157	   bandwidth requested by this refresh RESERVE message is not updated.
2158	   This will mean that the reserved bandwidth associated with the
2159	   reduced state is decreased in the next refresh period by the amount
2160	   of the corresponding bandwidth that has not been refreshed, see
2161	   section 4.3.3. This soft state
2162	   behavior provides certain robustness for the system ensuring that
2163	   unused resources are not reserved for long time.  Resources can be
2164	   removed by an explicit release at any time. However, in the situation
2165	   that an end-to-end (tear) RESERVE is retransmitted, see Section 5.2.4
2166	   in [QoS-NSLP], then this message MUST NOT initiate an intra-domain
2167	   (tear) RESERVE message. This is because the amount bandwidth within
2168	    the RMD domain associated with the (tear) end-to-end RESERVE has
2169	    already been released and therefore, this amount of bandwidth within
2170	    the RMD domain MUST NOT once again be released.

2172	   When the RMD-RMF of a QNE edge or QNE Interior node processes a
2173	   "PHR_Release_Request"  PHR container it MUST identify the
2174	   <PHB Class> parameter and estimate the time period that elapsed
2175	   after the previous refresh, see also Section 3 of [CsTa05]. This MAY
2176	   be done by indicating the time lag, say "T_lag", between the last
2177	   sent "PHR_Refresh_Update" and the "PHR_Release_Request" control
2178	   information container by the QNE Ingress node, see [RMD1] and
2179	   [CsTa05] for more details.  The value of "T_Lag"
2180	   is first normalized to the length of the refresh period, say
2181	   "T_period".  The ratio between the "T_Lag" and the length of the
2182	   refresh period, "T_period", is calculated.  This ratio is then
2183	   introduced into the <Time Lag> field of the "PHR_Release_Request".

2185	   When a node (QNE Egress or QNE Interior) receives the
2186	   "PHR_Release_Request" PHR container, it MUST store the arrival
2187	   time.  Then it MUST calculate the time difference, "Tdiff", between
2188	   the arrival time and the start of the current refresh period,
2189	   "T_period".  Furthermore, this node MUST derive the value of the
2190	   "T_Lag", from the <Time Lag> parameter. "T_Lag" can be found by
2191	   multiplying the value included in the <Time Lag> parameter with the
2192	   length of the refresh period, "T_period". If the derived time lag,
2193	   "T_lag", is smaller than the calculated time difference, "T_diff",
2194	   then this node MUST decrease the PHB reservation state with the
2195	   number of resource units indicated in the <Bandwidth> parameter of
2196	   the "RMD-QOSM object combination" (i.e., the RMD-QOSM <QoS Desired>)
2197	   that has been sent together with the "PHR_Release_Request" "PHR
2198	   Container", but not below zero.

2200	   An RMD specific release procedure can be triggered by an end-to-end
2201	   RESERVE with a TEAR flag set ON (see Section 4.6.1.5.1) or it can be
2202	   triggered by either an intra-domain RESPONSE, an end-to-end RESPONSE
2203	    or an end-to-end NOTIFY message that includes a marked (i.e., PDR
2204	   <M> and/or PDR <S> parameters are set ON) "PDR_Reservation_Report" or
2205	   "PDR_Congestion_Report" and/or an INFO_SPEC object.

2207	4.6.1.5.1.  Triggered by a RESERVE message

2209	   This RMD explicit release procedure can be triggered by a tear (TEAR
2210	   flag set ON) end-to-end RESERVE message. When a tear (TEAR flag
2211	   set ON) end-to-end RESERVE message arrives to the QNE Ingress
2212	   then the QNE Ingress node SHOULD process the message in a standard
2213	   QoS-NSLP way (see [QoS-NSLP]). In addition to this, the RMD RMF
2214	   is notified, as specified in [QoS-NSLP].

2216	   Same as for the scenario described in Section 4.6.1.1., a bypassing
2217	   procedure has to be initiated by the QNE Ingress node. The bypassing
2218	   procedure is performed according to the description given in Section
2219	   4.4. At the QNE Ingress the end-to-end RESERVE message is marked,
2220	   i.e., modifying the QoS-NSLP default NSLP-ID value to another NSLP-ID
2221	   predefined value that will be used by the GIST message that carries
2222	   the end-to-end RESERVE message to bypass the QNE Interior nodes.

2224	   Before generating an intra-domain tear RESERVE, the RMD-QOSM has to
2225	   release the requested RMD-QOSM bandwidth from the RMD traffic class
2226	   state maintained at the QNE Ingress. This can be achieved by
2227	   identifying the traffic class (PHB) and then subtracting the amount
2228	   of RMD traffic class requested resources, included in the <Bandwidth>
2229	   parameter, from the total reserved amount of resources stored in the
2230	   RMD traffic class state. The <Time Lag> is used as explained in the
2231	   introductory part of Section 4.6.1.5.

2233	QNE (Ingress)     QNE (Interior)       QNE (Interior)    QNE (Egress)
2234	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
2235	    |                    |                   |                    |
2236	RESERVE                  |                   |                    |
2237	--->|                    |                   |     RESERVE        |
2238	    |------------------------------------------------------------>|
2239	    |RESERVE(RMD-QSpec:Tear=1)               |                    |
2240	    |------------------->|                   |                    |
2241	    |                    |RESERVE(RMD-QSpec:Tear=1)               |
2242	    |                    |------------------->|                   |
2243	    |                    |                 RESERVE(RMD-QSpec:Tear=1)
2244	    |                    |                   |------------------->|
2245	    |                    |                   |                RESERVE
2246	    |                    |                   |                    |-->

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

2250	   After that the required bandwidth is released from the RMD-QOSM
2251	   traffic class state at the QNE Ingress, an intra-domain RESERVE (RMD-
2252	   QOSM) message has to be generated. The intra-domain RESERVE (RMD-
2253	   QSpec) message MUST include a "RMD QoS object combination" field and
2254	   a PHR container, (i.e., "PHR_Resource_Release") and it MAY include a
2255	   PDR container, (i.e., PDR_Release_Request). An example of this
2256	   operation can be seen in Figure 11.

2258	   Most of the non default values of the objects contained in the
2259	   tear intra-domain RESERVE message are set by the QNE Ingress node in
2260	   the same way as described in Section 4.6.1.1.  The following objects
2261	   are set differently (see QoS-NSLP-RMF API described in [QoS-NSLP]):

2263	   *  The <RII> object MUST NOT be included in this message.  This is
2264	      because the QNE Ingress node does not need to receive a
2265	      response from the QNE Egress node;

2267	   *  If the release procedure is not applied for the RMD modification
2268	      of aggregated reservation procedure, see Section 4.6.1.4, then
2269	      the TEAR flag MUST be set to ON;

2271	   *  the PHR resource units MUST be included into the <Bandwidth>
2272	      parameter of the "RMD-QOSM object combination" (i.e., the RMD-QOSM
2273	      <QoS Desired>);

2275	   *  the value of the <Admitted Hops> parameter MUST be set to "1";
2276	   *  the value of the <Time Lag> parameter of the PHR container is
2277	      calculated by the RMD-QOSM functionality (see 4.6.1.5) the value
2278	      of the <Control Type> parameter of PHR container is set to "PHR_3"
2279	      (i.e., PHR_Resource_Release).

2281	   Any QNE Interior node that receives the combination of the RMD-
2282	   QOSM <Qos Desired> object and the "PHR_Resource_Release" control
2283	   information container  MUST identify the traffic class (PHB)
2284	   and release the requested resources included in the <Bandwidth>
2285	   parameter.  This can be achieved by subtracting the amount of RMD
2286	   traffic class requested resources, included in the <Bandwidth>
2287	   parameter, from the total reserved amount of resources stored in the
2288	   RMD traffic class state.  The value of the <Time Lag> parameter of
2289	   the "PHR_Resource_Release" container is used during the release
2290	   procedure as explained in the introductory part of Section 4.6.1.5.

2292	   The intra-domain tear RESERVE (RMD-QSpec) message is received and
2293	   processed by the QNE Egress node.  The "RMD-QOSM object combination"
2294	   (i.e., the RMD-QOSM <QoS Desired>) and the "PHR RMD-QOSM control"
2295	   container (and if available the "PDR Container") are read and
2296	   processed by the RMD QoS node.

2298	   The value of the <Bandwidth> parameter of the "RMD-QOSM object
2299	   combination" (i.e., the RMD-QOSM <QoS Desired>)
2300	   and the value of the <Time Lag> field of the PHR container MUST
2301	   be used by the RMD release procedure.  This can be achieved by
2302	   subtracting the amount of RMD traffic class requested resources,
2303	   included in the <Bandwidth> parameter, from the total reserved amount
2304	   of resources stored in the RMD traffic class state.

2306	   The end-to-end RESERVE message is forwarded by the next hop (i.e.,
2307	   the QNE Egress) only if the intra-domain tear RESERVE (RMD-QSpec)
2308	   message arrives at the QNE Egress node. Furthermore, the QNE Egress
2309	   MUST stop the marking process that was used to bypass the QNE
2310	   Interior nodes by reassigning the QoS-NSLP default NSLP-ID value to
2311	   the end-to-end RESERVE message, see Section 4.4.
2312	   Note that when the QNE edges maintain aggregated QoS-NSLP reservation
2313	   states the RMD-QOSM functionality may start a RMD modification
2314	   procedures (see Section 4.6.1.4.) that uses the explicit release
2315	   procedure described above, in this subsection. Note that
2316	   if the complete bandwidth associated with the aggregated reservation
2317	   maintained at the QNE ingress has to be released then the
2318	   TEAR flag MUST be set to ON. Otherwise, the TEAR
2319	   flag MUST be set to OFF, see Section 4.6.1.4.

2321	4.6.1.5.2   Triggered by a marked RESPONSE or NOTIFY message

2323	   This RMD explicit release procedure can be triggered by either an
2324	   intra-domain RESPONSE message with a PDR container carrying among
2325	   others the <M> and <S> parameters with values <M>=1 and <S>=0 (see
2326	   Section 4.6.1.2) an intra-domain (refresh) RESPONSE message carrying
2327	   a PDR Container with <M>=1 and <S>=1  (see Section 4.6.1.6.1) or an
2328	   end to end NOTIFY message (see Section 4.6.1.6.) with an INFO_SPEC
2329	   object with the following values:

2331	   Error Severity Class: Informational
2332	   Error Code value: Congestion situation

2334	   When the aggregated intra-domain QoS-NSLP operational states are used
2335	   then an end-to-end NOTIFY message used to trigger an RMD release
2336	   procedure may contain a PDR container that carries a <M> and a <S>
2337	   with values <M>=1 and <S>=1, and a bandwidth value in the <PDR
2338	   Bandwidth> parameter included in a "PDR_Refresh_Report" or
2339	   "PDR_Congestion_Report" container.

2341	   Note that in all explicit release procedures, before generating an
2342	   intra-domain tear RESERVE, the RMD-QOSM has to release the requested
2343	   RMD-QOSM bandwidth from the RMD traffic class state maintained at the
2344	   QNE Ingress. This can be achieved by identifying the traffic class
2345	   (PHB) and then subtracting the amount of RMD traffic class requested
2346	   resources, included in the <Bandwidth> parameter, from the total
2347	   reserved amount of resources stored in the RMD traffic class state.

2349	   Figure 12 shows the situation that the intra-domain tear RESERVE is
2350	   generated after being triggered by either an intra-domain (refresh)
2351	   RESPONSE message that carries a PDR Container with <M>=1 and <S>=1,
2352	   or by an end-to-end NOTIFY message that do not carry a PDR container,
2353	   but an INFO_SPEC object. The error code values carried by this NOTIFY
2354	   message are:

2356	   Error Severity Class: Informational
2357	   Error Code value: Congestion situation

2359	   Most of the non-default values of the objects contained in the
2360	   tear intra-domain RESERVE(RMD-QSpec) message are set by the QNE
2361	   Ingress node in the same way as described in Section 4.6.1.1.

2363	   The following objects MUST be used and/or set differently (see
2364	   QoS-NSLP-RMF described in [QoS-NSLP]):

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

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

2372	   *  The RESERVE message MAY include a PDR container. Note that this
2373	      is needed if bi-directional scenario is used, see Section 4.6.2.

2375	QNE (Ingress)     QNE (Interior)         QNE (Interior)    QNE (Egress)
2376	NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
2377	    |                  |                  |                  |
2378	    | NOTIFY           |                  |                  |
2379	    |<-------------------------------------------------------|
2380	    |RESERVE(RMD-QSpec:Tear=1,M=1,S=1)    |                  |
2381	    | ---------------->|RESERVE(RMD-QSpec:Tear=1, M=1,S=1)   |
2382	    |                  |                  |                  |
2383	    |                  |----------------->|                  |
2384	    |                  |           RESERVE(RMD-QSpec:Tear=1, M=1,S=1)
2385	    |                  |                  |----------------->|

2387	   Figure 12: Basic operation during RMD explicit release procedure
2388	   triggered by NOTIFY used by the RMD-QOSM.

2390	   Note that if the values of the <M> and <S> parameters included in the
2391	   PHR container carried by a intra-domain tear RESERVE(RMD-QOSM) are
2392	   set as ((<M>=0 and <S>=1) or (<M>=0 and <S>=0) or (<M>=1 and <S>=1))
2393	   then the <Max Admitted Hops> value SHOULD not be compared to the
2394	   <Admitted Hops> value and the value of the <K> field MUST NOT be set.
2395	   Any QNE edge or QNE Interior node that receives the intra-domain tear
2396	   RESERVE it MUST check the <K> field included in the PHR Container. If
2397	   the <K> fied is "0" then the traffic class state (PHB) has to be
2398	   identified, using the <PHB Class> parameter, and the the requested
2399	   resources included in the <Bandwidth> field have to be released.
2400	   This can be achieved by subtracting the amount of RMD traffic class
2401	   requested resources, included in the <Bandwidth> field, from the
2402	   total reserved amount of resources stored in the RMD traffic class
2403	   state.  The value of the <Time Lag> parameter of the PHR field
2404	   is used during the release procedure as explained in the introductory
2405	   part of Section 4.6.1.5. Afterwards, the QNE Egress node MUST
2406	   terminate the tear intra-domain RESERVE(RMD-QSpec) message.

2408	   The RMD specific release procedure that is triggered by an
2409	   intra-domain RESPONSE message with <M>=1 and <S>=0 PDR container (see
2410	   Section 4.6.1.2) generates an intra-domain tear RESERVE message
2411	   that uses the combination of <Max Admitted Hops> and <Admitted_Hops>
2412	   fields to calculate and specify when the <K> value carried by the
2413	   "PHR Container" can be set. When the <K> field is set, then the "PHR
2414	   Container" and the "RMD-QoSM object combination" carried by an
2415	   intra-domain tear RESERVE MUST NOT be processed.

2417	   The RMD specific explicit release procedure that uses the combination
2418	   of <Max Admitted Hops>, <Admitted_Hops> and <K> fields to release
2419	   resources/bandwidth in only a part of the RMD domain, is denoted as
2420	   RMD partial release procedure.  This explicit release procedure can
2421	   be used, for example, during unsuccessful reservation (see Section
2422	   4.6.1.2). When the RMD-QoSM/QoS-NSLP signaling model functionality
2423	   of a QNE Ingress node receives a  PDR container with values <M>=1
2424	   and <S>=0, of type "PDR_Reservation_Report", it MUST start an RMD
2425	   partial release procedure.

2427	   In this situation, after that the required bandwidth is released from
2428	   the RMD-QOSM traffic class state at the QNE Ingress, an intra-domain
2429	   RESERVE (RMD-QOSM) message has to be generated. An example of this
2430	   operation can be seen in Figure 13.

2432	   Most of the non-default values of the objects contained in the
2433	   tear intra-domain RESERVE(RMD-QSpec) message are set by the QNE
2434	   Ingress node in the same way as described in Section 4.6.1.1.

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

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

2441	   *  The RESERVE message MAY include a PDR container.

2443	* the value of the <Max Admitted Hops> carried by the "PHR
2444	     Container" MUST be set equal to the <Max Admitted Hops> value
2445	     carried by the "PDR Container" (with <M>=1 and <S.=0) carried by
2446	     the received intra-domain RESPONSE message that triggers the
2447	     release procedure.

2449	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
2450	                                     Node that marked
2451	                                    PHR_Resource_Request
2452	                                       <PHR> object
2453	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
2454	    |                    |                   |                    |
2455	    |                    |                   |                    |
2456	    | RESPONSE (RMD-QSpec: M=1)              |                    |
2457	    |<------------------------------------------------------------|
2458	RESERVE(RMD-QSpec: Tear=1, M=1, <Admit Hops>=<Max Admitted Hops>, K=0)
2459	    |------------------->|                   |                    |
2460	    |                    |RESERVE(RMD-QSpec: Tear=1, M=1, K=1)    |
2461	    |                    |------------------>|                    |
2462	    |                    |    RESERVE(RMD-QSpec: Tear=1, M=1, K=1)|
2463	    |                    |                   |------------------->|
2464	    |                    |                   |                    |

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

2469	   Any QNE edge or QNE Interior node that receives the intra-domain tear
2470	   RESERVE has to check the value of the <K> field in the "PHR
2471	   Container" before releasing the requested resources.

2473	   If the value of the <K> field is "1", then all the QNEs located
2474	   downstream, including the QNE Egress, MUST NOT process the carried
2475	   "PHR Container" and the "RMD-QOSM Object Combination" (i.e., RMD-QOSM
2476	   <QoS Desired> object) by the intra-domain tearing RESERVE.

2478	   If the <K> field value is "0", any QNE edge or QNE Interior node that
2479	   receives the intra-domain tear RESERVE can release the resources by
2480	   subtracting the amount of RMD traffic class requested resources,
2481	   included in the <Bandwidth> field, from the total reserved amount of
2482	   resources stored in the RMD traffic class state.  The value of the
2483	   <Time Lag> parameter of the PHR field is used during the release
2484	   procedure as explained in the introductory part of Section 4.6.1.5.
2485	   Furthermore, the QNE MUST perform the following procedures.
2486	   If the values of the <M> and <S> parameters included in the
2487	    "PHR_Resource_Release" PHR container are (<M=1> and <S>=0) then the
2488	   <Max Admitted Hops> value MUST be compared with the calculated
2489	   <Admitted Hops> value.  Note that each time that the intra-domain
2490	   tear RESERVE is processed and before being forwarded by a QNE, the
2491	   <Admitted Hops> value included in the PHR container is increased by
2492	   one.

2494	   When these two values are equal then the intra-domain
2495	   RESERVE(RMD-QSpec) that is forwarded further towards the QNE Egress
2496	   MUST set the <K> value of the carried "PHR Container" to "1".
2497	   The reason of doing this is that the QNE node that is currently
2498	   processing this message was the last QNE node that successfully
2499	   processed the "RMD-QOSM object combination" (i.e., the RMD-QOSM <QoS
2500	   Desired>) and PHR container of its associated initial reservation
2501	   request (i.e., initial intra-domain RESERVE(RMD-QSpec) message). Its
2502	   next QNE downstream node was unable to successfully process the
2503	   initial reservation request, therefore, this QNE node marked the <M>
2504	   and <Hop_U> parameters of the "PHR_Resource_Request".

2506	   Note that finally the QNE Egress node MUST terminate the intra-domain
2507	   RESERVE(RMD-QSpec) message.

2509	   Note that the above described RMD partial release procedure applies
2510	   to the situation that the QNE edges maintain a per flow QoS-NSLP
2511	   reservation state.

2513	   When the QNE edges maintain aggregated intra-domain QoS-NSLP
2514	   operational states and a severe congestion occurs, then the QNE
2515	   Ingress may receive an end to end NOTIFY message (see Section
2516	   4.6.1.6.) with a PDR container that carries the  <M>=0 and <S>=1
2517	   fields and a bandwidth value in the <PDR Bandwidth> parameter
2518	   included in a "PDR_Congestion_Report" container. Furthermore the
2519	   same end-to-end NOTIFY message carries an INFO_SPEC object with the
2520	   following values:

2522	   Error Severity Class: Informational
2523	   Error Code value: Congestion situation
2524	   The end-to-end session associated with this NOTIFY message maintains
2525	   the BOUND_SESSION_ID of the bound aggregated session, see Sections
2526	   4.3.1. The RMD-QOSM at QNE Ingress MUST start a RMD modification
2527	   procedures (see Section 4.6.1.4) that uses the RMD explicit release
2528	   procedure described above in this section. In particular, the RMD
2529	   explicit release procedure releases the bandwidth value included in
2530	   the <PDR Bandwidth> parameter, within the "PDR_Congestion_Report"
2531	   container, from the reserved bandwidth associated with the aggregated
2532	   intra-domain QoS-NSLP operational state.

2534	4.6.1.6. Severe congestion handling

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

2539	   When a failure in a communication path, e.g., a router or a link
2540	   failure occurs, the routing algorithms will adapt to failures by
2541	   changing the routing decisions to reflect changes in the topology and
2542	   traffic volume.  As a result, the re-routed traffic will follow a new
2543	   path, which may result in overloaded nodes as they need to support
2544	   more traffic.  This may cause severe congestion in the communication
2545	   path.  In this situation the available resources, are not enough to
2546	   meet the required QoS for all the flows along the new path.
2547	   Therefore, one or more flows SHOULD be terminated, or forwarded in a
2548	   lower priority queue.

2550	   Interior nodes notify edge nodes by data marking or marking the
2551	   refresh messages.

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

2555	   This procedure applies to all RMD scenarios that use a RMD refresh
2556	   procedure. The QoS-NSLP and RMD are able to cope with congested
2557	   situations using the refresh procedure, see Section 4.6.1.3. If the
2558	   refresh is not successful in an QNE Interior node, edge nodes are
2559	   notified by setting <S>=1 (<M>=1) marking the refresh messages and by
2560	   including the percentage of overload into the <Overload %> field in
2561	   the "PHR_Refresh_Update" container, carried by the intra-domain
2562	   RESERVE message. The intra-domain RESPONSE message that is sent by
2563	   the QNE Egress towards QNE Ingress will contain a PDR container with
2564	   a Parameter/Container ID = PDR_10, i.e., "PDR_Congestion_Report". The
2565	   values of the <M>, <S> and <Overload %> fields of this container
2566	   should be set equal to the values of the <M>, <S> and <Overload %>
2567	   fields, respectively, carried by the "PHR_Refresh_Update" container.
2568	   Part of the flows, corresponding to the <Overload %>, are terminated,
2569	   or forwarded in a lower priority queue. Note that an example of how
2570	   this value can be calculated is given in appendix A.1.1 and denoted
2571	   as the signaled_overload_rate parameter. The flows can be terminated
2572	   by the RMD release procedure described in Section 4.6.1.5.  Note that
2573	   the above described functionality applies to the RMD reservation-
2574	   based and to the NSIS measurement-based admission control schemes.
2575	   Furthermore, note that the above functionalities apply also for the
2576	   scenario where the QNE Edge nodes maintain either per flow QoS-NSLP
2577	   reservation states or aggregated QoS-NSLP reservation states.

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

2584	4.6.1.6.2 Severe congestion handling by proportional data packet marking

2586	   This severe congestion handling method requires the following
2587	   functionalities.

2589	4.6.1.6.2.1 Operation in the Interior nodes

2591	   The detection and marking/remarking functionality described in this
2592	   section applies to NSIS aware, but also to NSIS unaware nodes. This
2593	   means however, that the "not NSIS aware" nodes must be configured
2594	   such that they can detect the congestion/severe congestion situations
2595	   and remark packets in the same way as the "NSIS aware" nodes do.

2597	   The Interior node detecting severe congestion remarks data packets
2598	   passing the node. For this remarking, two additional DSCPs can be
2599	   allocated for each traffic class.  One DSCP MAY be used to indicate
2600	   that the packet passed a congested node. This type of DSCP is denoted
2601	   in this document as "affected DSCP" and is used to indicate that a
2602	   packet passed through a severe congested node. The use of this DSCP
2603	   type eliminates the possibility that, due to e.g. ECMP (Equal Cost
2604	   Multiple Paths) enabled routing, the egress node either does not
2605	   detect packets passed a severe congested node or erroneously detects
2606	   packets that actually did not pass the severe congested node.  Note
2607	   that this type of DSCP MUST only be used if all the nodes within the
2608	   RMD domain are configured to use it. Otherwise, this type of DSCP
2609	   MUST NOT be applied. The other DSCP MUST be used to indicate the
2610	   degree of congestion by marking the bytes proportionally to the
2611	   degree of congestion. This type of DSCP is denoted in this document
2612	   as "encoded DSCP".

2614	   Note that in this document the terms marked packets or marked bytes
2615	   refer to the "encoded DSCP". The terms unmarked packets or unmarked
2616	   bytes are representing the packets or the bytes belonging to these
2617	   packets that their DSCP is either the "affected DSCP" or the original
2618	   DSCP. Furthermore, in the algorithm described below it is considered
2619	   that the router may drop received packets. The counting/measuring of
2620	   marked or unmarked bytes described in this section is accomplished
2621	   within measurement periods. All nodes within a RMD domain use the
2622	   same, fixed measurement interval, say T seconds, which MUST be
2623	   pre-configured.

2625	   It is RECOMMENDED that the total number of additional (local and
2626	   experimental) DSCPs needed for severe congestion handling within an
2627	   RMD domain should be as low as possible and it should not exceed the
2628	   limit of 8. One possibility to reduce the number of used DSCPs is to
2629	   use only the "encoded DSCP" and not to use "affected DSCP" marking.
2630	   Another possible solution is for example, to allocate one DSCP for
2631	   severe congestion indication for each of the AF classes,
2632	   independently from their dropping precedence.

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

2636	4.6.1.6.2.2 Operation in the Egress nodes

2638	   When the QNE edges maintain a per flow intra-domain QoS-NSLP
2639	   operational state, see sections 4.3.2, 4.3.3, then the following
2640	   procedure is followed. The QNE Egress node applies a predefined
2641	   policy to solve the severe congestion situation, by selecting a
2642	   number of inter-domain (end-to-end) flows that SHOULD be terminated,
2643	   or forwarded in a lower priority queue.

2645	   When the RMD domain does not use the "affected DSCP"
2646	   marking then the egress MUST generate an ingress/egress pair
2647	   aggregated state, for each ingress and for each supported PHB. This
2648	   is because the edges must be able to detect in which ingress/egress
2649	   pair a severe congestion occurs. This is because otherwise the QNE
2650	   Egress will not have any information on which flows or groups of
2651	   flows were affected by the severe congestion. When the RMD domain
2652	   supports the "affected DSCP" marking then the egress is able to
2653	   detect all flows that are affected by the severe congestion
2654	   situation. Therefore, when the RMD domain supports the "affected
2655	   DSCP" marking, then the Egress MAY not generate and maintain the
2656	   ingress/egress pair aggregated reservation States. Note that these
2657	   aggregated reservation states may not be associated with aggregated
2658	   intra-domain QoS-NSLP operational states.

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

2664	   Some flows, belonging to the same PHB traffic class might get
2665	   other priority than other flows belonging to the same PHB traffic
2666	   class. This difference in priority can be notified to the egress and
2667	   ingress nodes either by the RESERVE message that carries the QSpec
2668	   associated with the end-to-end QoS model, e.g.,, <Preemption
2669	   Priority> & <Defending Priority> parameter, or by using a local
2670	   defined policy. The priority value is kept in the reservation states,
2671	   see Section 4.3, which might be used during admission control and/or
2672	   severe congestion handling procedures. The terminated flows are
2673	   selected from the flows having the same PHB traffic class as the PHB
2674	   of the marked (as "encoded DSCP") and "affected DSCP" (when applied
2675	   in the complete RMD domain) packets and (when the ingress/egress pair
2676	   aggregated states are available) that are belonging to the same
2677	   ingress/egress pair aggregate.

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

2684	   For the flows (sessions) that have to be terminated, the QNE Egress
2685	   node generates and sends an end-to-end NOTIFY message to the QNE
2686	   Ingress node (its upstream stateful QoS-NSLP peer) to indicate the
2687	   severe congestion in the communication path.

2689	   The non-default values of the objects contained in the NOTIFY
2690	   message MUST be set by the QNE Egress node as follows
2691	   (see QoS-NSLP-RMF API described in [QoS-NSLP]):

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

2696	   * the INFO_SPEC object MUST include information that notifies that
2697	     the end-to-end flow MUST be terminated. This information is as
2698	     follows:

2700	     Error Severity Class: Informational
2701	     Error Code value: Congestion situation

2703	   When the QNE edges maintain a per aggregate intra-domain QoS-NSLP
2704	   operational state, see sections 4.3.1 then the QNE Edge has to
2705	   calculate, per each aggregate intra-domain QoS-NSLP operational
2706	   state, the total bandwidth that has to be terminated in order to
2707	   solve the severe congestion. The total to be released bandwidth is
2708	   calculated in the same way as in the situation that the QNE edges
2709	   maintain per flow intra-domain QoS-NSLP operational states.
2710	   Note that for the aggregated sessions that are affected, the QNE
2711	   Egress node generates and sends one end-to-end NOTIFY message to the
2712	   QNE Ingress node(its upstream stateful QoS-NSLP peer) to indicate the
2713	   severe congestion in the communication path. Note that this end-to-
2714	   end NOTIFY message is associated with one of the end-to-end sessions
2715	   that is bound to the aggregated intra-domain QoS-NSLP operational
2716	   state.

2718	   The non-default values of the objects contained in the NOTIFY
2719	   message MUST be set by the QNE Egress node in the same way as the
2720	   ones used by the end-to-end NOTIFY message described above for the
2721	   situation that the QNE Egress maintains a per flow intra-domain
2722	   operational state. In addition to this the end-to-end NOTIFY MUST
2723	   carry the RMD-Qspec, which contains a PDR container with a
2724	   Parameter/Container ID = PDR_10, i.e., "PDR_Congestion_Report". The
2725	   value of the <S> should be set. Furthermore, the value of the <PDR
2726	   Bandwidth> parameter MUST contain the bandwidth, associated with the
2727	   aggregated QoS-NSLP operational state, which has to be released.

2729	   Furthermore, the number of end-to-end sessions that have to be
2730	   terminated will be calculated as in the situation that the QNE edges
2731	   maintain per flow intra-domain QoS-NSLP operational states. Similarly
2732	   for each, to be terminated, ongoing flow the egress will notify the
2733	  ingress in the same way as in the situation that the QNE edges
2734	   maintain per flow intra-domain QoS-NSLP operational states.

2736	   Note that QNE egress SHOULD restore the original DSCP
2737	   values of the remarked packets, otherwise multiple actions for the
2738	   same event might occur. However, this value MAY be left in its
2739	   remarking form if there is an SLA agreement between domains that a
2740	   downstream domain handles the remarking problem.

2742	   4.6.1.6.2.3 Operation in the Ingress nodes

2744	   Upon receiving the (end-to-end) NOTIFY message, the QNE Ingress node
2745	   resolves the severe congestion by a predefined policy, e.g., by
2746	   refusing new incoming flows (sessions), terminating the affected and
2747	   notified flows (sessions), and blocking their packets or shifting
2748	   them to an alternative RMD traffic class (PHB). This operation is
2749	   depicted in Figure 14, where the QNE Ingress, for each flow (session)
2750	   to be terminated, receives a NOTIFY message that carries the
2751	   "Congestion situation" error code.

2753	   When the QNE Ingress node receives the end-to-end NOTIFY message, it
2754	   associates this NOTIFY message with its bound intra-domain session,
2755	   see Sections 4.3.2, 4.3.3. via the BOUND_SESSION_ID information
2756	   included in the end-to-end per-flow QoS-NSLP state. The QNE Ingress
2757	   uses the operation described in Section 4.6.1.5.2 to terminate the
2758	   intra-domain session.

2760	 QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)

2762	  user  |                  |                 |                  |
2763	  data  |  user data       |                 |                  |
2764	 ------>|----------------->|     user data   | user data        |
2765	        |                  |---------------->S(# marked bytes)  |
2766	        |                  |                 S----------------->|
2767	        |                  |                 S(# unmarked bytes)|
2768	        |                  |                 S----------------->|Term.
2769	        |                 NOTIFY             S                  |flow?
2770	        |<-----------------|-----------------S------------------|YES
2771	        |RESERVE(RMD-QSpec:Tear=1,M=1,S=1)   S                  |
2772	        | ---------------->|RESERVE(RMD-QSpec:T=1, M=1,S=1)     |
2773	        |                  |                 S                  |
2774	        |                  |---------------->S                  |
2775	        |                  |       RESERVE(RMD-QSpec:Tear=1, M=1,S=1)
2776	        |                  |                 S----------------->|

2778	   Figure 14:  RMD severe congestion handling
2779	   Note that the above functionality applies to the RMD reservation-
2780	   Based, see Section 4.3.3 and to both measurement-based admission
2781	   control methods (i.e., congestion notification based on probing and
2782	   the NSIS measurement-based admission control), see Section 4.3.2.

2784	   In the case that the QNE edges support aggregated intra-domain QoS-
2785	   NSLP operational states the following actions take place. The QNE
2786	   Ingress may receive an end to end NOTIFY message with a PDR container
2787	   that carries a <S> marked and a bandwidth value in the <PDR
2788	   Bandwidth> parameter included in a "PDR_Congestion_Report" container.
2789	   Furthermore the same end-to-end NOTIFY message carries an INFO_SPEC
2790	   object with the "Congestion situation" error code.

2792	   When the QNE Ingress node receives this end-to-end  NOTIFY message,
2793	   it associates the NOTIFY message with the aggregated intra-domain
2794	   QoS-NSLP operational state via the BOUND_SESSION_ID information
2795	   included in the end-to-end per-flow QoS-NSLP operational state, see
2796	   Section 4.3.1.

2798	   The RMD-QOSM at the QNE Ingress node by using the
2799	   total to be released bandwidth value included in the <PDR Bandwidth>
2800	   parameter MUST reduce
2801	the bandwidth associated and reserved by the RMD aggregated session.
2802	   This is accomplished by triggering the RMD modification for
2803	   Aggregated reservations procedure described in Section 4.6.1.4.

2805	   In addition to the above, the QNE Ingress MUST select a number of
2806	   inter-domain (end-to-end) flows (sessions) that must be terminated.
2807	   This is accomplished in the same way as in the situation that the QNE
2808	   edges maintain per flow intra-domain QoS-NSLP operational states.

2810	   The terminated end-to-end sessions are selected from the end-to-end
2811	   sessions bound to the aggregated intra-domain QoS-NSLP operational
2812	   state. Note that the end-to-end session associated with the received
2813	   end-to-end NOTIFY message that notified the severe congestion must
2814	   also be selected for termination.
2815	   For the flows (sessions) that have to be terminated, the QNE Ingress
2816	   node generates and sends an end-to-end NOTIFY message upstream
2817	   towards the sender (QNI). The values carried by this message are:

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

2822	   * the INFO_SPEC object MUST include information that notifies that
2823	     the end-to-end flow MUST be terminated. This information is as
2824	     follows:

2826	     Error Severity Class: Informational
2827	     Error Code value: Congestion situation

2829	4.6.1.7 Admission control using congestion notification based on probing

2831	   The congestion notification function based on probing can be used to
2832	   implement a simple measurement-based admission control within a
2833	   Diffserv domain.  At interior nodes along the data path congestion
2834	   notification thresholds are set in the measurement based admission
2835	   control function for the traffic belonging to different PHBs. These
2836	   interior nodes are not NSIS aware nodes.

2838	4.6.1.7.1 Operation in Ingress nodes

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

2844	   The DSCP field of the GIST datagram message that is used to transport
2845	   this probe RESERVE message, SHOULD be marked with the same value of
2846	   DSCP as the data path packets associated with the same session. In
2847	   this way it is ensured that the end-to-end RESERVE (probe) packet
2848	   passed through the node that it is congested. This feature is very
2849	   useful when ECMP based routing is used to detect only flows that are
2850	   passing through the congested router.

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

2856	4.6.1.7.2 Operation in Interior nodes

2858	   These Interior nodes are not needed to be NSIS aware nodes and they
2859	   do not need to process NSIS functionality of NSIS messages. Note that
2860	   the "not NSIS aware" nodes must be configured such that they can
2861	   detect the congestion/severe congestion situations and remark packets
2862	   in the same way as the "NSIS aware" nodes do.

2864	   Using standard functionalities congestion notification thresholds are
2865	   set for the traffic belonging to different PHBs, see Section 4.3.2.
2866	   The end-to-end RESERVE message, see Figure 15, is used as a probe
2867	   packet.

2869	   The DSCP field of all data packets and of the GIST message carrying
2870	   the RESERVE message will be re-marked when the corresponding
2871	   "congestion notification" threshold is exceeded, see Section 4.3.2.
2872	   Note that when the data rate is higher than the congestion
2873	   notification threshold then also the data packets are remarked. An
2874	   example of the detailed operation of this procedure is given in
2875	   Appendix A.2.1.

2877	4.6.1.7.3 Operation in Egress nodes

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

2883	   For each ingress, the egress SHOULD generate an ingress/egress pair
2884	   aggregated (RMF) reservation state for each supported PHB. Note that
2885	   this aggregated reservation state does not require that also an
2886	   aggregated intra-domain QoS-NSLP operational state is needed.

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

2891	   If the request is rejected then the Egress node SHOULD
2892	   generate an (end-to-end) RESPONSE message to notify that the
2893	   reservation is unsuccesfull. In particular it will generate an
2894	   INFO_SPEC object of:
2895	     Error Severity Class: Transient Failure
2896	     Error Code value: Reservation failure

2898	   The QSpec that was carried by the end to end RESERVE belonging to
2899	   the same session as this end to end RESPONSE is included in this
2900	   message. The parameters included in the QSpec <QoS Reserved> object
2901	   are copied from the original <QoS Desired> values. The "E" flag
2902	   associated with the <QoS Reserved> object and the "E" flag associated
2903	   with <Bandwidth> parameter are also set. This RESPONSE message will
2904	   be sent to the Ingress node and it will be processed based on the
2905	   end-to-end QoS model.

2907	   Note that QNE egress SHOULD restore the original DSCP values of the
2908	   remarked packets, otherwise multiple actions for the same event might
2909	   occur. However, this value MAY be left in its remarking form if there
2910	   is an SLA agreement between domains that a downstream domain handles
2911	   the remarking problem. Note that the break "B" flag carried by the
2912	   end-to-end RESERVE message MUST NOT be set.

2914	QNE (Ingress)          Interior          Interior       QNE (Egress)
2915	                    (not NSIS aware) (not NSIS aware)
2916	  user  |                  |                 |                  |
2917	  data  |  user data       |                 |                  |
2918	 ------>|----------------->|     user data   |                  |
2919	        |                  |---------------->| user data        |
2920	        |                  |                 |----------------->|
2921	  user  |                  |                 |                  |
2922	  data  |  user data       |                 |                  |
2923	 ------>|----------------->|     user data   | user data        |
2924	        |                  |---------------->S(# marked bytes)  |
2925	        |                  |                 S----------------->|
2926	        |                  |                 S(# unmarked bytes)|
2927	        |                  |                 S----------------->|
2928	        |                  |                 S                  |
2929	RESERVE |                  |                 S                  |
2930	------->|                  |                 S                  |
2931	        |----------------------------------->S                  |
2932	        |                  |           RESERVE(re-marked DSCP in GIST)
2933	        |                  |                 S----------------->|
2934	        |                  |RESPONSE(unsuccessful INFO-SPEC)    |
2935	        |<------------------------------------------------------|
2936	 RESPONSE(unsuccessful INFO-SPEC)            |                  |
2937	 <------|                  |                 |                  |

2939	   Figure 15:  Using RMD congestion notification function for admission
2940	               control based on probing

2942	4.6.2  Bi-directional operation

2944	   RMD-QOSM assumes that asymmetric routing may be applied in the RMD
2945	   domain.  Combined sender-receiver initiated reservation cannot be
2946	   efficiently done in the RMD domain because upstream NTLP states are
2947	   not stored in Interior routers.  Therefore, the bi-directional
2948	   operation SHOULD be performed by two sender-initiated reservations
2949	   (sender&sender).  We assume that the QNE edge nodes are common for
2950	   both upstream and downstream directions, therefore, the two
2951	   reservations/sessions can be bound at the QNE edge nodes. Note that
2952	   if this is not the case then the bi-directional procedure could be
2953	   managed and maintained by nodes located outside the RMD domain, by
2954	   using other procedures than the ones defined in RMD-QOSM.

2956	   This bi-directional sender&sender procedure can then be applied
2957	   between the QNE edges (QNE Ingress and QNE Egress) nodes of the RMD
2958	   QoS signaling model.  In the situation a security association
2959	   exists between the QNE Ingress and QNE Egress nodes (see Figure 15),
2960	   and the QNE Ingress node has the required <Bandwidth> parameters
2961	   for both directions, i.e., QNE Ingress towards QNE Egress and QNE
2962	   Egress towards QNE Ingress, then the QNE Ingress MAY include both
2963	   <Bandwidth> parameters (needed for both directions) into the
2964	   RMD-QSpec within a RESERVE message.  In this way the QNE Egress node
2965	   is able to use the QoS parameters needed for the "Egress towards
2966	   Ingress" direction (QoS-2).  The QNE Egress is then able to create a
2967	   RESERVE with the right QoS parameters included in the QSpec, i.e.,
2968	   RESERVE (QoS-2). Both directions of the flows are bound by inserting
2969	   <BOUND_SESSION_ID> objects at the QNE Ingress and QNE Egress, which
2970	   will be carried by bound end-to-end RESERVE messages.

2972	     |------ RESERVE (QoS-1, QoS-2)----|
2973	     |                                 V
2974	     |           Interior/stateless QNEs
2975	                 +---+     +---+
2976	        |------->|QNE|-----|QNE|------
2977	        |        +---+     +---+     |
2978	        |                            V
2979	      +---+                        +---+
2980	      |QNE|                        |QNE|
2981	      +---+                        +---+
2982	         ^                           |
2983	      |  |       +---+     +---+     V
2984	      |  |-------|QNE|-----|QNE|-----|
2985	      |          +---+     +---+
2986	   Ingress/                         Egress/
2987	   statefull QNE                    statefull QNE
2988	                                     |
2989	   <--------- RESERVE (QoS-2) -------|

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

2993	   Note that it is recommended that the QNE implementations of RMD-QOSM
2994	   process the QoS-NSLP signaling messages with a higher priority than
2995	   data packets. This can be accomplished as described in Section 3.3.4
2996	   in [QoS-NSLP] and the QoS-NSLP-RMF API [QoS-NSLP].

2998	   A bidirectional reservation, within the RMD domain, is indicated by
2999	   the PHR <B> and PDR <B> flags, which are set in all messages. In this
3000	   case two BOUND_SESSION_ID objects SHOULD be used.

3002	   When the QNE edges maintain per-flow intra-domain QoS-NSLP
3003	   operational states then the end-to-end RESERVE message carries two
3004	   BOUND_SESSION_IDs. One BOUND_SESSION_ID carries the SESSION_ID of the
3005	   tunneled intra-domain (per-flow) session that is using a BINDING_CODE
3006	   with value set to code (Tunneled and end-to-end sessions).  Another
3007	   BOUND_SESSION_ID carries the SESSION_ID of the bound bidirectional
3008	   end-to-end session. The BINDING_CODE associated with this
3009	   BOUND_SESSION_ID is set to code (Bi-directional sessions).

3011	   When the QNE edges maintain aggregated intra-domain QoS-NSLP
3012	   operational states then the end-to-end RESERVE message carries two
3013	   BOUND_SESSION_IDs. One BOUND_SESSION_ID carries the SESSION_ID of the
3014	   tunneled aggregated intra-domain session that is using a BINDING_CODE
3015	   with value set to code (Aggregated sessions).  Another
3016	   BOUND_SESSION_ID carries the SESSION_ID of the bound bidirectional
3017	   end-to-end session. The BINDING_CODE associated with this
3018	   BOUND_SESSION_ID is set to code (Bi-directional sessions).

3020	   The intra-domain and end-to-end QoS-NSLP operational states are
3021	   initiated/modified depending on the binding type, see Section 4.3.1,
3022	   4.3.2, 4.3.3.

3024	   If no security association exists between the QNE Ingress and QNE
3025	   Egress nodes the bi-directional reservation for the sender&sender
3026	   scenario in the RMD domain SHOULD use the scenario specified in
3027	   [QoS-NSLP] as "Bi-directional reservation for sender&sender
3028	   scenario". This is because in this scenario the RESERVE message sent
3029	   from QNE Ingress to QNE Egress does not have to carry the QoS
3030	   parameters needed for the "Egress towards Ingress" direction (QoS-2).

3032	   In the following sections it is considered that the QNE
3033	   edge nodes are common for both upstream and downstream directions
3034	   and therefore, the two reservations/sessions can be bound at the
3035	   QNE edge nodes.  Furthermore, it is considered that a security
3036	   association exists between the QNE Ingress and QNE Egress nodes,
3037	   and the QNE Ingress node has the required <Bandwidth> parameters
3038	   for both directions, i.e., QNE Ingress towards QNE Egress and
3039	   QNE Egress towards QNE Ingress.

3041	4.6.2.1 Successful and unsuccessful reservations

3043	   This section describes the operation of the RMD-QOSM where a RMD
3044	   bi-directional reservation operation is either successfully or
3045	   unsuccessfully accomplished.

3047	   The bi-directional successful reservation is similar to a
3048	   combination of two unidirectional successful reservations that are
3049	   accomplished in opposite directions, see Figure 17. The main
3050	   differences of the bi-directional successful reservation procedure
3051	   with the combination of two unidirectional successful reservations
3052	   accomplished in opposite directions are as follows. Note also that
3053	   the intra-domain and end-to-end QoS-NSLP operational states generated
3054	   and maintained by the end-to-end RESERVE messages contain, compared
3055	   to the unidirectional reservation scenario, a different
3056	   BOUND_SESSION_ID data structure, see Section 4.3.1, 4.3.2, 4.3.3.
3057	   In this scenario the intra-domain RESERVE message sent by the QNE
3058	   Ingress node towards the QNE Egress node, is denoted in Figure 17 as
3059	   RESERVE (RMD-QSpec): "forward".  The main differences between the
3060	   intra-domain RESERVE (RMD-QSpec):"forward" message used for the bi-
3061	   directional successful reservation procedure and a RESERVE (RMD-
3062	   QSpec) message used for the unidirectional successful reservation are
3063	   as follows (see QoS-NSLP-RMF API described in [QoS-NSLP]):

3065	   *  the RII object MUST NOT be included in the message. This is
3066	      because no RESPONSE message is required.

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

3071	   *  the PDR container is also included into the RESERVE(RMD-QSpec):
3072	      "forward" message. The value of the Parameter/Container ID is
3073	      "PDR_4", i.e., "PDR_Reservation_Request".  Note that the response
3074	      PDR container sent by a QNE Egress to a QNE Ingress node is not
3075	      carried by an end-to-end RESPONSE message, but it is carried by an
3076	      intra-domain RESERVE message that is sent by the QNE Egress node
3077	      towards the QNE Ingress node (denoted in Figure 16 as
3078	      RESERVE(RMD-QSpec):"reverse").

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

3083	   *  the <PDR Bandwidth> field specifies the
3084	      requested bandwidth that has to be used by the QNE Egress node to
3085	      initiate another intra-domain RESERVE message in the reverse
3086	      direction.

3088	   The RESERVE(RMD-QSpec):"reverse" message is initiated by the QNE
3089	   Egress node at the moment that the RESERVE(RMD-QSpec):"forward"
3090	   message is successfully processed by the QNE Egress node.
3091	   The main differences between the RESERVE(RMD-QSpec):"reverse"
3092	   message used for the bi-directional successful reservation procedure
3093	   and a RESERVE(RMD-QSpec) message used for the unidirectional
3094	   successful reservation are as follows:

3096	QNE (Ingress)   QNE (int.)    QNE (int.)    QNE (int.)   QNE (Egress)
3097	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
3098	    |                |               |               |              |
3099	    |                |               |               |              |
3100	    |RESERVE(RMD-QSpec)              |               |              |
3101	    |"forward"       |               |               |              |
3102	    |                |    RESERVE(RMD-QSpec):        |              |
3103	    |--------------->|    "forward"  |               |              |
3104	    |                |------------------------------>|              |
3105	    |                |               |               |------------->|
3106	    |                |               |               |              |
3107	    |                |               |RESERVE(RMD-QSpec)            |
3108	    |      RESERVE(RMD-QSpec)        | "reverse"     |<-------------|
3109	    |      "reverse" |               |<--------------|              |
3110	    |<-------------------------------|               |              |

3112	      Figure 17: Intra-domain signaling operation for successful
3113	                 bi-directional reservation

3115	   *  the RII object is not included in the message. This is because no
3116	      RESPONSE message is required;

3118	   *  the value of the <Bandwidth> parameter is set equal to the value
3119	      of the <PDR Bandwidth> field included in the
3120	      RESERVE(RMD-QSpec):"forward" message that triggered the
3121	      generation of this RESERVE(RMD-QSpec): "reverse" message;

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

3126	   *  the PDR container is included into the
3127	      RESERVE(RMD-QSpec):"reverse" message.  The value of the
3128	      Parameter/Container ID is "PDR_7", i.e., "PDR_Reservation_Report";

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

3133	   Figure 18 and Figure 19 show the flow diagrams used in case of a
3134	   unsuccessful bi-directional reservation.  In Figure 18 it
3135	   is considered that the QNE that is not able to support the
3136	   requested <Bandwidth> is located in the direction QNE Ingress
3137	   towards QNE Egress.  In Figure 19 it is considered that the
3138	   QNE that is not able to support the requested <Bandwidth> is
3139	   located in the direction QNE Egress towards QNE Ingress.

3141	   The main differences between the bi-directional unsuccessful
3142	   procedure shown in Figure 18 and the bi-directional successful
3143	   procedure are as follows:

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

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

3153	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3154	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
3155	    |                |             |              |               |
3156	    |RESERVE(RMD-QSpec):           |              |               |
3157	    |  "forward"     |  RESERVE(RMD-QSpec):       |               |
3158	    |--------------->|  "forward"  |              M RESERVE(RMD-QSpec):
3159	    |                |--------------------------->M  "forward-M marked"
3160	    |                |             |              M-------------->|
3161	    |                |           RESPONSE(PDR)    M               |
3162	    |                |        "forward - M marked"M               |
3163	    |<------------------------------------------------------------|
3164	    |RESERVE(RMD-QSpec, K=0)       |              M               |
3165	    |"forward - T tear"            |              M               |
3166	    |--------------->|             |              M               |
3167	    |                    RESERVE(RMD-QSpec, K=1)  M               |
3168	    |                |   "forward - T tear"       M               |
3169	    |                |--------------------------->M               |
3170	    |                |                  RESERVE(RMD-QSpec, K=1)   |
3171	    |                |                 "forward - T tear"         |
3172	    |                |                            M-------------->|

3174	   Figure 18: Intra-domain signaling operation for unsuccessful
3175	              bi-directional reservation (rejection on path QNE(Ingress)
3176	              towards QNE(Egress))

3178	   The operation for this type of unsuccessful bi-directional
3179	   reservation is similar to the operation for unsuccessful uni-
3180	   directional reservation shown in Figure 9.

3182	   The main differences between the bi-directional unsuccessful
3183	   procedure shown in Figure 19 and the in bi-directional successful
3184	   procedure are as follows:

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

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

3194	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3195	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
3196	    |                |                |                |              |
3197	    |RESERVE(RMD-QSpec)               |                |              |
3198	    |"forward"       |  RESERVE(RMD-QSpec):            |              |
3199	    |--------------->|  "forward"     |           RESERVE(RMD-QSpec): |
3200	    |                |-------------------------------->|"forward"     |
3201	    |                |   RESERVE(RMD-QSpec):           |------------->|
3202	    |                |    "reverse"   |                |              |
3203	    |                |              RESERVE(RMD-QSpec) |              |
3204	    |    RESERVE(RMD-QSpec):          M      "reverse" |<-------------|
3205	    |   "reverse - M marked"          M<---------------|              |
3206	    |<--------------------------------M                |              |
3207	    |                |                M                |              |
3208	    |RESERVE(RMD-QSpec, K=0):         M                |              |
3209	    |"forward - T tear"               M                |              |
3210	    |--------------->|  RESERVE(RMD-QSpec, K=0):       |              |
3211	    |                |  "forward - T tear"             |              |
3212	    |                |-------------------------------->|              |
3213	    |                |                M                |------------->|
3214	    |                |                M         RESERVE(RMD-QSpec, K=0):
3215	    |                |                M             reverse - T tear" |
3216	    |                |                M                |<-------------|
3217	    |                                 M RESERVE(RMD-QSpec, K=1)       |
3218	    |                |                M "forward - T tear"            |
3219	    |                |                M<---------------|              |
3220	    |          RESERVE(RMD-QSpec, K=1)M                |              |
3221	    |          "forward - T tear"     M                |              |
3222	    |<--------------------------------M                |              |

3224	   Figure 19: Intra-domain signaling normal operation for unsuccessful
3225	             bi-directional reservation (rejection on path QNE(Egress)
3226	             towards QNE(Ingress)

3228	   *  the QNE Ingress uses the information contained in the received
3229	      PHR and PDR containers of the RESERVE(RMD-QSpec): "reverse" and
3230	      generates a tear intra-domain RESERVE(RMD-QSpec):
3231	      "forward - T tear" message.  This message carries a
3232	      "PHR_Release_Request" and a "PDR_Release_Request" control
3233	      information.  This message is sent to QNE Egress node.
3234	      The QNE Egress node uses the information contained in the
3235	      "PHR_Release_Request" and the "PDR_Release_Request" control
3236	      info containers to generate a RESERVE(RMD-QSpec):"reverse - T
3237	      tear" message that is sent towards the QNE Ingress node.

3239	4.6.2.2 Refresh reservations

3241	   This section describes the operation of the RMD-QOSM where a RMD
3242	   bi-directional refresh reservation operation is accomplished.
3243	   The refresh procedure in case of RMD reservation-based method
3244	   follows a similar scheme as the successful reservation procedure,
3245	   described in Section 4.6.2.1, and depicted in Figure 17 and the
3246	   way of how the refresh process of the reserved resources is
3247	   maintained, is similar to the refresh process used for the intra-
3248	   domain uni-directional reservations (see Section 4.6.1.3).

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

3254	   The main differences between the RESERVE(RMD-QSpec):"forward"
3255	   message used for the bi-directional refresh procedure
3256	   and a RESERVE(RMD-QSpec):"forward" message used for the bi-
3257	   directional successful reservation procedure are as follows:

3259	   *  the value of the Parameter/Container ID of the PHR container is
3260	      "PHR_2", i.e., "PHR_Refresh_Update".

3262	   *  the value of the Parameter/Container ID of the PDR container is
3263	      "PDR_5", i.e., "PDR_Refresh_Request".

3265	   The main differences between the RESERVE(RMD-QSpec):"reverse"
3266	   message used for the bi-directional refresh procedure and the RESERVE
3267	   (RMD-QSpec): "reverse" message used for the bi-directional successful
3268	   reservation procedure are as follows:

3270	   *  the value of the Parameter/Container ID of the PHR container is
3271	      "PHR_2", i.e., "PHR_Refresh_Update".

3273	   *  the value of the Parameter/Container ID of the PDR container is
3274	      "PDR_8", i.e., "PDR_Refresh_Report".

3276	4.6.2.3 Modification of aggregated intra-domain QoS-NSLP operational
3277	reservation states

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

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

3286	   * When the modification request requires an increase of the reserved
3287	   resources, the QNE Ingress node MUST include the corresponding value
3288	   into the <Bandwidth> parameter of the "RMD-QOSM object combination"
3289	   (i.e., the RMD-QOSM <QoS Desired>), which is sent together with a
3290	   "PHR_Resource_Request" control information.  If a QNE edge or QNE
3291	   Interior node is not able to reserve the number of requested
3292	   resources, then the "PHR_Resource_Request" associated with the
3293	   <Bandwidth> parameter MUST be marked.  In this situation the RMD
3294	   specific operation for unsuccessful reservation will be applied (see

3296	   Section 4.6.2.1). Note that the value of the <PDR Bandwidth>
3297	   parameter, which is sent within a "PDR_Reservation_Request"
3298	   container, represents the increase of the reserved resources in the
3299	   "reverse" direction.

3301	   * When the modification request requires a decrease of the
3302	   reserved resources, the QNE Ingress node MUST include this value
3303	   into the <Bandwidth> parameter of the "RMD-QOSM object combination"
3304	   (i.e., the RMD-QOSM <QoS Desired>). Subsequently an RMD release
3305	   procedure SHOULD be accomplished (see Section 4.6.2.4). Note that the
3306	   value of the <PDR Bandwidth> parameter, which is sent within a
3307	   "PDR_Release_Request" container, represents the decrease of the
3308	   reserved resources in the "reverse" direction.

3310	4.6.2.4 Release procedure

3312	   This section describes the operation of the RMD-QOSM where a RMD
3313	   bi-directional reservation release operation is accomplished.
3314	   The message sequence diagram used in this procedure is similar to the
3315	   one used by the successful reservation procedures, described in
3316	   Section 4.6.2.1, and depicted in Figure 17. However, the way of how
3317	   the release of the reservation is accomplished, is similar to the RMD
3318	   release procedure used for the intra-domain uni-directional
3319	   reservations (see Section 4.6.1.5 and Figure 18 and Figure 19).

3321	   The main differences between the RESERVE (RMD-QSpec):
3322	   "forward" message used for the bi-directional release procedure
3323	   and a RESERVE (RMD-QSpec): "forward" message used for the bi-
3324	   directional successful reservation procedure are as follows:

3326	   *  the value of the Parameter/Container ID of the PHR container is
3327	      "PHR_3", i.e."PHR_Release_Request";

3329	   *  the value of the Parameter/Container ID of the PDR container is
3330	      "PDR_6", i.e., "PDR_Release_Request";

3332	   The main differences between the RESERVE (RMD-QSpec): "reverse"
3333	   message used for the bi-directional release procedure and the RESERVE
3334	   (RMD-QSpec): "reverse" message used for the bi-directional successful
3335	   reservation procedure are as follows:

3337	   *  the value of the Parameter/Container ID of the PHR container is
3338	      "PHR_3", i.e., "PHR_Release_Request";

3340	   *  the PDR container is not included in the RESERVE (RMD-QSpec):
3341	      "reverse" message.

3343	4.6.2.5 Severe congestion handling

3345	   This section describes the severe congestion handling operation used
3346	   in combination with bi-directional reservation procedures.
3347	   This severe congestion handling operation is similar to the one
3348	   described in Section 4.6.1.6.

3350	4.6.2.5.1 Severe congestion handling by the RMD-QOSM bi-directional
3351	          refresh procedure

3353	   This procedure is similar to the severe congestion handling procedure
3354	   described in Section 4.6.1.6.1. The difference is related to how the
3355	   refresh procedure is accomplished, see Section 4.6.2.2 and to how the
3356	   flows are terminated, see Section 4.6.2.4.

3358	4.6.2.5.2 Severe congestion handling by proportional data packet marking

3360	   This section describes the severe congestion handling by proportional
3361	   data packet marking when this is combined with a bi-directional
3362	   reservation procedure. Note that the detection and marking/remarking
3363	   functionality described in this section and used by Interior nodes,
3364	   applies to NSIS aware, but also to NSIS unaware nodes. This means
3365	   however, that the "not NSIS aware" Interior nodes must be configured
3366	   such that they can detect the congestion situations and remark
3367	   packets in the same way as the Interior "NSIS aware" nodes do.

3369	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3370	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
3371	user|                |             |              |               |
3372	data|    user        |             |              |               |
3373	--->|    data        | user data   |              |user data      |
3374	    |--------------->|             |              S               |
3375	    |                |--------------------------->S (#marked bytes)
3376	    |                |             |              S-------------->|
3377	    |                |             |              S(#unmarked bytes)
3378	    |                |             |              S-------------->|Term
3379	    |                |             |              S               |flow?
3380	    |                |          NOTIFY (PDR)      S               |YES
3381	    |<------------------------------------------------------------|
3382	    |RESERVE(RMD-QSpec)            |              S               |
3383	    |"forward - T tear"            |              S               |
3384	    |--------------->|             |           RESERVE(RMD-QSpec):|
3385	    |                |--------------------------->S"forward - T tear"
3386	    |                |             |              S-------------->|
3387	    |                |             |          RESERVE(RMD-QSpec): |
3388	    |                |             |           "reverse - T tear" |
3389	    | RESERVE(RMD-QSpec):          |              |<--------------|
3390	    |"reverse - T tear"            |<-------------S               |
3391	    |<-----------------------------|              S               |

3393	Figure 20: Intra-domain RMD severe congestion handling for
3394	           bi-directional reservation (congestion on path QNE(Ingress)
3395	           towards QNE(Egress))

3397	   This procedure is similar to the severe congestion handling procedure
3398	   described in Section 4.6.1.6.2. The main difference is related to the
3399	   location of the severe congested node, i.e. "forward" or "reverse"
3400	   path. Note that when a severe congestion situation occurs on
3401	   e.g. on a forward path, and flows are terminated to solve the severe
3402	   congestion in forward path, then the reserved bandwidth associated
3403	   with the terminated bidirectional flows will also be released.
3404	   Therefore, a careful selection of the flows that have to be
3405	   terminated should take place. An example of such a selection is given
3406	   in Appendix A.3.1.

3408	   Furthermore, a special case of this operation is associated to the
3409	   severe congestion situation occurring simultaneously on the forward
3410	   and reverse paths. An example of this operation is given in Appendix
3411	   A.3.2.

3413	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3414	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
3415	user|                |                |           |               |
3416	data|    user        |                |           |               |
3417	--->|    data        | user data      |           |user data      |
3418	    |--------------->|                |           |               |
3419	    |                |--------------------------->|user data      |user
3420	    |                |                |           |-------------->|data
3421	    |                |                |           |               |--->
3422	    |                |                |  user     |               |<---
3423	    |   user data    |                |  data     |<--------------|
3424	    | (#marked bytes)|                S<----------|               |
3425	    |<--------------------------------S           |               |
3426	    | (#unmarked bytes)               S           |               |
3427	Term|<--------------------------------S           |               |
3428	Flow?                |                S           |               |
3429	YES |RESERVE(RMD-QSpec):              S           |               |
3430	    |"forward - T tear"               s           |               |
3431	    |--------------->|  RESERVE(RMD-QSpec):       |               |
3432	    |                |  "forward - T tear"        |               |
3433	    |                |--------------------------->|               |
3434	    |                |                S           |-------------->|
3435	    |                |                S         RESERVE(RMD-QSpec):
3436	    |                |                S       "reverse - T tear"  |
3437	    |      RESERVE(RMD-QSpec)         S           |<--------------|
3438	    |      "reverse - T tear"         S<----------|               |
3439	    |<--------------------------------S           |               |

3441	   Figure 21: Intra-domain RMD severe congestion handling for
3442	           bi-directional reservation (congestion on path QNE(Egress)
3443	           towards QNE(Ingress))

3445	   Figure 20 shows the scenario where the severe congested node is
3446	   located in the "forward" path. This scenario is very similar to the
3447	   severe congestion handling scenario described in Section 4.6.1.6.2
3448	   and shown in Figure 14. The difference is related to the release
3449	   procedure, which is accomplished in the same way as described in
3450	   Section 4.6.2.4.

3452	   Figure 21 shows the scenario where the severe congested node is
3453	   located in the "reverse" path. The main difference between this
3454	   scenario and the scenario shown in Figure 20 is that no
3455	   end-to-end NOTIFY(PDR) message has to be generated by the QNE Egress
3456	   node. This is because the (#marked and #unmarked) user data is
3457	   arriving at the QNE Ingress. The QNE Ingress node will be able to
3458	   calculate the number of flows that have to be terminated or forwarded
3459	   in a lower priority queue.

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

3465	4.6.2.6 Admission control using congestion notification based on
3466	          probing

3468	   This section describes the admission control scheme that uses the
3469	   congestion notification function based on probing when bi-directional
3470	   reservations are supported.

3472	QNE(Ingress)    Interior    QNE (int.)      Interior      QNE (Egress)
3473	NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
3474	user|                |             |              |               |
3475	data|                |             |              |               |
3476	--->|                | user data   |              |user data      |
3477	    |-------------------------------------------->S (#marked bytes)
3478	    |                |             |              S-------------->|
3479	    |                |             |              S(#unmarked bytes)
3480	    |                |             |              S-------------->|
3481	    |                |             |              S               |
3482	    |                |           RESERVE(re-marked DSCP in GIST)):|
3483	    |                |             |              S               |
3484	    |-------------------------------------------->S               |
3485	    |                |             |              S-------------->|
3486	    |                |             |              S               |
3487	    |                |          RESPONSE(unsuccessful INFO-SPEC)  |
3488	    |<------------------------------------------------------------|
3489	    |                |             |              S               |

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

3495	   This procedure is similar to the congestion notification for
3496	   admission control procedure described in Section 4.6.1.7. The main
3497	   difference is related to the location of the severe congested node,
3498	   i.e., "forward" path (i.e., path between QNE Ingress towards QNE
3499	   Egress) or "reverse" path (i.e., path between QNE Egress towards
3500	   QNE Ingress).

3502	   Figure 22 shows the scenario where the severe congested node is
3503	   located in the "forward" path. The functionality of providing
3504	   admission control is the same as the one described in Section
3505	   4.6.1.7, Figure 15.

3507	   Figure 23 shows the scenario where the congested node is located in
3508	   the "reverse" path. The probe RESERVE message sent in the "forward"
3509	   direction will not be affected by the severe congested node, while
3510	   the DSCP value in the IP header of any packet of the "reverse"
3511	   direction flow and also of the GIST message that carries the
3512	   probe RESERVE message sent in the "reverse" direction will be
3513	   remarked by the congested node. The QNE ingress is in this way
3514	   notified that a congestion occurred in the network and therefore it
3515	   is able to refuse the new initiation of the reservation.

3517	QNE (Ingress)    Interior    QNE (int.)     Interior       QNE (Egress)
3518	NTLP stateful not NSIS aware  NTLP st.less not NSIS aware NTLP stateful
3519	user|                |                |           |               |
3520	data|                |                |           |               |
3521	--->|                | user data      |           |               |
3522	    |-------------------------------------------->|user data      |user
3523	    |                |                |           |-------------->|data
3524	    |                |                |           |               |--->
3525	    |                |                |           |               |user
3526	    |                |                |           |               |data
3527	    |                |                |           |               |<---
3528	    |                S                | user data |               |
3529	    |                S  user data     |<--------------------------|
3530	    |   user data    S<---------------|           |               |
3531	    |<---------------S                |           |               |
3532	    |  user data     S                |           |               |
3533	    | (#marked bytes)S                |           |               |
3534	    |<---------------S                |           |               |
3535	    |                S           RESERVE(unmarked DSCP in GIST)): |
3536	    |                S                |           |               |
3537	    |----------------S------------------------------------------->|
3538	    |                S          RESERVE(re-marked DSCP in GIST)   |
3539	    |                S<-------------------------------------------|
3540	    |<---------------S                |           |               |

3542	   Figure 23: Intra-domain RMD congestion notification for
3543	           bi-directional admission control (congestion on path
3544	           QNE(Egress) towards QNE(Ingress))

3546	Note that the "not NSIS aware" Interior nodes must be configured such
3547	that they can detect the congestion/severe congestion situations and
3548	remark packets in the same way as the Interior "NSIS aware" nodes do.

3550	4.7 Handling of additional errors

3552	   During the QSpec processing, additional errors may occur. The way
3553	   in which these additional errors are handled and notified is
3554	   specified in [QSP-T] and [QoS-NSLP].

3556	5.  Security Considerations

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

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

3571	       QNE             QNE             QNE            QNE
3572	     Ingress         Interior        Interior        Egress
3573	 NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
3574	        |               |               |              |
3575	        | RESERVE (1)   |               |              |
3576	        +--------------------------------------------->|
3577	        | RESERVE` (2)  |               |              |
3578	        +-------------->|               |              |
3579	        |               | RESERVE`      |              |
3580	        |               +-------------->|              |
3581	        |               |               | RESERVE`     |
3582	        |               |               +------------->|
3583	        |               |               |              |
3584	        |               |               | RESPONSE` (2)|
3585	        |<---------------------------------------------+
3586	        |               |               | RESPONSE (1) |
3587	        |<---------------------------------------------+
3588	        |               |               |              |

3590	                 Figure 24: RMD message exchange

3592	   In the context of RMD-QOSM signaling a classification between
3593	   on-path adversaries and off-path adversaries needs to be made.
3594	   Furthermore, it might be necessary to differentiate between off-path
3595	   nodes that never participate in the RMD signaling exchange and nodes

3597	   that are only off-path with regard to a specific signaling session
3598	   whereby routing asymmetry might even mean that the downstream and the
3599	   upstream signaling direction matters for this classification.

3601	   Note that RMD always uses the message exchange shown in Figure 24
3602	   even if there is no end-to-end signaling session. If the RMD-QOSM is
3603	   triggered based on an E2E signaling exchange then the RESERVE message
3604	   is created by a node outside the RMD domain and will subsequently
3605	   travel further on (e.g., to the data receiver). Such an exchange is
3606	   shown in Figure 3. As such, an evaluation of RMD`s security must
3607	   always been seen as a combination of the two signaling sessions, (1)
3608	   and (2) of Figure 24.

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

3613	*  Nodes, which are never supposed to participate in the NSIS signaling
3614	   exchange, SHOULD NOT interfere with QNE Interior nodes. Off-path
3615	   nodes (off-path with regard to the path taken by a particular
3616	   signaling message exchange) SHOULD NOT be able to interfere with
3617	   other on-path signaling nodes.

3619	*  The actions allowed by a QNE Interior node SHOULD be minimal (i.e.,
3620	   only those specified by the RMD-QOSM). For example, only the QNE
3621	   Ingress and the QNE Egress nodes are allowed to initiate certain
3622	   signaling messages. QNE Interior nodes are, for example, allowed to
3623	   modify certain signaling message payloads.

3625	   Note that the term `interfere` refers to all sorts of security
3626	   threats, such as denial of service, spoofing, replay, signaling
3627	   message injection, etc.

3629	   If we assume that the RESERVE/RESPONSE is sent with hop-by-hop
3630	   channel security provided by GIST and protected between the QNE
3631	   Ingress and the QNE Egress node then we can
3632	   be sure that the payloads of these messages MUST be authenticated,
3633	   integrity, replay protected and encrypted. Encryption is necessary to
3634	   prevent an adversary that is located along the path of the RESERVE
3635	   message to learn information about the session that can later be used
3636	   to inject a valid RESERVE`. The following messages need to relate to
3637	   each other to make sure that the occurrence of one message is not
3638	   without the other one:

3640	   a) the RESERVE and the RESERVE` relate to each other at the QNE
3641	      Egress and

3643	   b) the RESPONSE and the RESERVE relate to each other at the QNE
3644	      Ingress and

3646	   c) the RESERVE` and the RESPONSE` relate to each other. The RII is
3647	   carried in the RESERVE` message and the RESPONSE` message that is
3648	   generated by the QNE Egress node contains the same RII as the
3649	   RESERVE`. The RII can be used by the QNE Ingress to match the
3650	   RESERVE` with the RESPONSE`. The QNE Egress is able to determine
3651	   whether the RESERVE` was created by the QNE Ingress node since the
3652	   intra-domain session, which sent the RESERVE`, is bound to an end-to-
3653	   end session via the BOUND_SESSION_ID value included in the intra-
3654	   domain QoS-NSLP operational state maintained at the QNE Egress.

3656	   The RESERVE and the RESERVE` message are tied together using the
3657	   BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end
3658	   QoS-NSLP operational states maintained at the QNE edges, see Section
3659	   4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a
3660	   corresponding RESERVE. The SESSION_ID can fulfill this purpose quite
3661	   well if the aim is to provide protection against off-path adversaries
3662	   that do not see the SESSION_ID carried in the RESERVE and the
3663	   RESERVE` messages. If, however, the path changes (due to re-routing
3664	   or due to mobility) then an adversary could inject RESERVE` messages
3665	   (with a previously seen SESSION_ID) and could potentially cause harm.

3667	   An off-path adversary can, of course, create RESERVE` messages that
3668	   cause intermediate nodes to create some state (and cause other
3669	   actions) but the message would finally hit the QNE Egress node. The
3670	   QNE Egress node would then be able to determine that there is
3671	   something going wrong and generate an error message.

3673	   The severe congestion handling can be triggered by intermediate nodes
3674	   (unlike other messages). In many cases, however, intermediate nodes
3675	   experiencing congestion use refresh messages modify the <S> and
3676	   <Overload %> parameters of the message. These messages are still
3677	   initiated by the QNE Ingress node and carry the SESSION_ID. The QNE
3678	   Egress node will use the SESSION_ID and subsequently the
3679	   BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational
3680	   state, to refer to a flow that might be terminated. The
3681	   aspect of intermediate nodes initiating messages for severe
3682	   congestion handling is for further study.

3684	   QNE Ingress    QNE Interior   QNE Interior    QNE Egress
3685	 NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
3686	        |               |               |              |
3687	        | REFRESH RESERVE`              |              |
3688	        +-------------->| REFRESH RESERVE`             |
3689	        | (+RII)        +-------------->| REFRESH RESERVE`
3690	        |               | (+RII)        +------------->|
3691	        |               |               | (+RII)       |
3692	        |               |               |              |
3693	        |               |               |     REFRESH  |
3694	        |               |               |     RESPONSE`|
3695	        |<---------------------------------------------+
3696	        |               |               |     (+RII)   |

3698	                 Figure 25: RMD REFRESH message exchange

3700	   During the refresh procedure a RESERVE` creates a RESPONSE`, see
3701	   Figure 25. The RII is carried in the RESERVE` message and the
3702	   RESPONSE` message that is generated by the QNE Egress node contains
3703	   the same RII as the RESERVE`.

3705	   The RII can be used by the QNE Ingress to match the RESERVE` with the
3706	   RESPONSE`.

3708	   A further aspect is marking of data traffic. Data packets can be
3709	   modified by an intermediary without any relationship to a signaling
3710	   session (and a SESSION_ID). The problem appears if an off-path
3711	   adversary injects spoofed data packets. The adversary thereby needs
3712	   to spoof data packets that relate to the flow identifier of an
3713	   existing end-to-end reservation that should be terminated. Therefore
3714	   the question arises how an off-path adversary should create a data
3715	   packet that matches an existing flow identifier (if a 5-tuple is
3716	   used). Hence, this might not turn out to be simple for an adversary
3717	   unless we assume the previously mentioned mobility/re-routing case
3718	   where the path through the network changes and the set of nodes that
3719	   are along a path changes over time.

3721	6.  IANA Considerations

3723	   A new QOSM ID ("RMD QOSM") needs to be assigned by IANA. The value
3724	   Has to be placed into the QSPEC Type registry that was created with
3725	   [QSP-T].

3727	   The following new parameters are registered in the Parameter ID
3728	   registry that was created with [QSP-T]:

3730	          Value          Parameter/Container ID
3731	 ------------------------+----------------
3732	 |To-be-assigned-by-IANA | PHR Container |
3733	 |To-be-assigned-by-IANA | Bandwidth     |
3734	 |To-be-assigned-by-IANA | PDR Container |
3735	 ------------------------+----------------

3737	   Note to the editor: in this draft a list with temporarily parameter
3738	   ID values are given to the Bandwidth parameter, PHR containers and
3739	   PDR containers, see Sections 4.1.1, 4.1.2 and 4.1.3. The temporarily
3740	   ID value given for the Bandwidth parameter ID is Bandwidth_ID, see
3741	   Section 4.1.1. The given PHR container ID values are in a range from
3742	   PHR_1 to PHR_3 and the given PDR container ID values are in the range
3743	   from PDR_4 to PDR_10. After the IANA will assign new parameter ID
3744	   values, then all these temporarily assigned values have to be
3745	   reassigned.

3747	7.  Acknowledgments

3749	   The authors express their acknowledgement to people who have worked
3750	   on the RMD concept: Z. Turanyi, R. Szabo, G. Pongracz, A. Marquetant,
3751	   O. Pop, V. Rexhepi, G. Heijenk, D. Partain, M. Jacobsson, S.
3752	   Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel, M.
3753	   Zoumaro-Djayoon, M. Swanink, R. Klaver G. Stokkink, J. W. van
3754	   Houwelingen, D. Dimitrova, T. Sealy, H. Chang.

3756	8.  Authors' Addresses

3758	   Attila Bader
3759	   Ericsson Research
3760	   Ericsson Hungary Ltd.
3761	   Laborc 1, Budapest, Hungary, H-1037
3762	   EMail: Attila.Bader@ericsson.com

3764	   Lars Westberg
3765	   Ericsson Research
3766	   Torshamnsgatan 23
3767	   SE-164 80 Stockholm, Sweden
3768	   EMail: Lars.Westberg@ericsson.com
3769	   Georgios Karagiannis
3770	   University of Twente
3771	   P.O.  BOX 217
3772	   7500 AE Enschede, The Netherlands
3773	   EMail: g.karagiannis@ewi.utwente.nl

3775	   Cornelia Kappler
3776	   DeZem GmbH   Knesebeckstr. 86/87
3777	   10623 Berlin
3778	   Germany
3779	   Email: cornelia.kappler@googlemail.com

3781	   Hannes Tschofenig
3782	   Nokia Siemens Networks
3783	   Linnoitustie 6
3784	   Espoo 02600
3785	   Finland
3786	   EMail: Hannes.Tschofenig@nsn.com
3787	   URI: http://www.tschofenig.priv.at

3789	   Tom Phelan
3790	   Sonus Networks
3791	   250 Apollo Dr.
3792	   Chelmsford, MA USA 01824
3793	   EMail: tphelan@sonusnet.com

3795	   Attila Takacs
3796	   Ericsson Research
3797	   Ericsson Hungary Ltd.
3798	   Laborc 1, Budapest, Hungary, H-1037
3799	   EMail: Attila.Takacs@ericsson.com

3801	   Andras Csaszar
3802	   Ericsson Research
3803	   Ericsson Hungary Ltd.
3804	   Laborc 1, Budapest, Hungary, H-1037
3805	   EMail: Andras.Csaszar@ericsson.com

3807	9.  Normative References

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

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

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

3819	10.  Informative References

3821	   [AdCa03] Adler, M., Cai, J.-Y., Shapiro, J. K., Towsley, D.,
3822	   "Estimation of congestion price using probabilistic packet marking",
3823	   Proc. IEEE INFOCOM, pp. 2068-2078, 2003.

3825	   [AnHa06] Lachlan L. H. Andrew and Stephen V. Hanly, "The Estimation
3826	   Error of Adaptive Deterministic Packet Marking", 44th Annual Allerton
3827	   Conference on Communication, Control and Computing, 2006.

3829	   [AtLi01] Athuraliya, S., Li, V. H., Low, S. H., Yin, Q., "REM: active
3830	   queue management", IEEE Network, vol. 15, pp. 48-53, May/June 2001.

3832	   [Chan07] H. Chang, "Security support in RMD-QOSM", Masters thesis,
3833	   University of Twente, 2007.

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

3839	   [JaSh97]  Jamin, S., Shenker, S., Danzig, P., "Comparison of
3840	   Measurement-based Admission Control Algorithms for Controlled-Load
3841	   Service", Proceedings IEEE Infocom `97, Kobe, Japan, April 1997.

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

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

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

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

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

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

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

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

3874	   [RMD1]  Westberg, L., et al., "Resource Management in Diffserv
3875	   (RMD): A Functionality and Performance Behavior Overview", IFIP
3876	   PFHSN`02

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

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

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

3890	   [RFC2998] Bernet Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
3891	   Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
3892	   Felstaine, "Integrated Services Operation Over Diffserv
3893	   Networks", RFC 2998, November 2000.

3895	   [ThCo04] Thommes, R. W., Coates, M. J., "Deterministic packet marking
3896	   for congestion packet estimation" Proc. IEEE Infocom, 2004.

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

3901	   Per supported PHB, the interior node can support the operation states
3902	   depicted in Figure A.1, when the per-flow congestion notification
3903	   based on probing signaling scheme is used in combination with this
3904	   severe congestion type. Figure A.2 depicts the same functionality
3905	   when the per-flow congestion notification based on probing scheme is
3906	   not used in combination with the severe congestion scheme. The
3907	   description given in this and the following appendices, focuses
3908	   on the situation that during the congestion notification state, the
3909	   "notified DSCP" marking and during the severe congestion state the
3910	   "encoded DSCP" and "affected DSCP" markings are used. In this case,
3911	   the "notified DSCP" marking is used during the
3912	   congestion notification state to mark all packets passing through an
3913	   interior node that operates in the congestion notification state. In
3914	   this way, and in combination with probing, an ECMP solution can be
3915	   provided for the congestion notification state. The "encoded DSCP"
3916	   marking is used to encode and signal the excess rate,
3917	   measured at interior nodes, to the egress nodes. The "affected DSCP"
3918	   marking is used to mark all packets that are passing through a severe
3919	   congested node and are not "encoded DSCP" marked.

3921	   Another possible situation could be derived where both congestion
3922	   notification and severe congestion state are using the "encoded DSCP"
3923	   marking, without using the "notified DSCP" marking. The "affected
3924	   DSCP" marking is used to mark all packets that are passing through
3925	   an Interior node that is in severe congestion state and are not
3926	   "encoded DSCP" marked. In addition, the probe packet that is carried
3927	   by an intra-domain RESERVE message and pass through Interior nodes
3928	   SHOULD be "encoded DSCP" marked if the Interior node is in
3929	   congestion notification or severe congestion states. Otherwise the
3930	   probe packet will remain unmarked. In this way an ECMP solution can
3931	   be provided for both congestion notification and severe congestion
3932	   states. The"encoded DSCP" packets are signaling excess rate that is
3933	   not only associated with interior nodes that are in severe congestion
3934	   state, but also with interior nodes that are in congestion
3935	    notification state.  The algorithm at the Interior node, is similar
3936	   to the algorithm described in the following appendix sections.
3937	   However, this method is not described in detail in this example.

3939	                ---------------------------------------------
3940	               |        event B                              |
3941	               |                                             V
3942	            ----------             -------------           ----------
3943	           | Normal   |  event A  | Congestion  | event B | Severe   |
3944	           |  state   |---------->| notification|-------->|congestion|
3945	           |          |           |  state      |         |  state   |
3946	            ----------             -------------           ----------
3947	             ^  ^                       |                     |
3948	             |  |      event C          |                     |
3949	             |   -----------------------                      |
3950	             |         event D                                |
3951	              ------------------------------------------------

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

3956	            ----------                 -------------
3957	           | Normal   |  event B      | Severe      |
3958	           |  state   |-------------->| congestion  |
3959	           |          |               |  state      |
3960	            ----------                 -------------
3961	                ^                           |
3962	                |      event E              |
3963	                 ---------------------------
3964	        Figure A.2: States of operation, severe congestion without
3965	        congestion notification based on probing

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

3969	   Normal state: represents the normal operation conditions of the
3970	   node,   i.e. no congestion
3971	   Severe congestion state: it represents the state when state the
3972	   interior node is severely congested related to a certain PHB

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

3977	   event A: this event occurs when the incoming PHB rate is higher than
3978	   the "congestion notification detection" threshold and lower than the
3979	   severe congestion detection". This threshold is used by the
3980	   congestion notification based on probing scheme, see
3981	   Section 4.6.1.7, 4.6.2.6.

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

3986	   event C: this event occurs when the incoming PHB rate is lower than
3987	   or equal to the "congestion notification detection" threshold.

3989	   event D: this event occurs when the incoming PHB rate is lower than
3990	   or equal to the "severe_congestion_restoration" threshold.

3992	   event E: this event occurs when the incoming PHB rate is lower than
3993	   or equal to the "severe congestion restoration" threshold.

3995	   Note that the "severe congestion detection", "severe congestion
3996	   restoration" and admission thresholds should be higher than the
3997	   "congestion notification detection" threshold, i.e.,:
3998	   "severe congestion detection" > "congestion notification detection"
3999	   and "severe congestion restoration" > "congestion notification
4000	   detection"

4002	   Furthermore, the "severe congestion detection" threshold should be
4003	   higher than or equal to the admission threshold that is used by the
4004	   reservation based and NSIS measurement based signaling schemes.
4005	   "severe congestion detection" >= admission threshold

4007	   Moreover, the "severe congestion restoration" threshold should be
4008	   lower than or equal to the "severe congestion detection" threshold
4009	   that is used by the reservation based and NSIS measurement based
4010	   signaling schemes, i.e.,:

4012	   "severe congestion restoration" <= "severe congestion detection"

4014	   During severe congestion the interior node calculates, per traffic
4015	   class (PHB), the incoming rate that is above the "severe congestion
4016	   restoration" threshold, denoted as signaled_overload_rate, in the
4017	   following way:

4019	   * A severe congested interior node should take into account that
4020	   packets might be dropped. Therefore, before queuing and eventually
4021	   dropping packets, the interior node should count the total number of
4022	   unmarked and remarked bytes received by the severe congested node,
4023	   denote this number as total_received_bytes. Note that there are
4024	   situations when more than one interior nodes in the same path become
4025	   severe congested. Therefore, any interior node located behind a
4026	   severe congested node may receive marked bytes.

4028	   When the "severe congestion detection" threshold per PHB is set
4029	   equal to the maximum capacity allocated to one PHB used by the RMD-
4030	   QOSM it means that if the maximum capacity associated to a PHB is
4031	   fully utilized and a packet belonging to this PHB arrives, then it is
4032	   assumed that the interior node will not forward this packet
4033	   downstream. In other words this packet will either be dropped or set
4034	   to another PHB. Furthermore, this also means that after the severe
4035	   congestion situation is solved, then the ongoing flows will be able
4036	   to send their associated packets up to a total rate equal to the
4037	   maximum capacity associated to the PHB. Therefore, when more than one
4038	   interior nodes located on the same path will be severe congested and
4039	   when the interior node receives "encoded DSCP" marked packets, then
4040	   it will mean that an interior node located upstream is also severely
4041	   congested.

4043	   When the "severe congestion detection" threshold per PHB
4044	   is set equal to the maximum capacity allocated to one PHB, then this
4045	   interior node must forward the "encoded DSCP" marked packets and it
4046	   should not consider these packets during its local remarking process.
4047	   In other words, the egress should see the excess rates encoded by the
4048	   different severe congested interior nodes as independent, and
4049	   therefore, these independent excess rates will be added.

4051	   When the "severe congestion detection" threshold per PHB
4052	   is not set equal to the maximum capacity allocated to one PHB then
4053	   this means that after the severe congestion situation is solved, the
4054	   ongoing flows will not be able to send their associated packets
4055	   up to a total rate equal to the maximum capacity associated to the
4056	   PHB, but only up to the "severe_congestion_threshold". When more than
4057	   one interior nodes located on the same communication path are severe
4058	   congested and when one of these interior node receives "encoded_DSCP"
4059	   marked packets then this interior node should not mark unmarked,
4060	   i.e., either "original DSCP" or "affected DSCP" or "notified DSCP""
4061	   encoded packets, up to a rate equal to the difference between the
4062	   maximum PHB capacity and the "severe congestion threshold", when the
4063	   incoming "encoded DSCP"" marked packets are already able to signal
4064	   this difference. In this case the "severe congestion threshold"
4065	   should be configured in all interior nodes, which are located in the
4066	   RMD domain, and equal to:

4068	  "severe_congestion_threshold" =
4069	   = Maximum PHB capacity - threshold_offset_rate
4070	   The threshold_offset_rate represents rate and should have the same
4071	   value in all interior nodes.

4073	   * before queuing and eventually dropping the packets, at the end of
4074	   each measurement interval of T seconds, calculate the current
4075	   estimated overloaded rate, say measured_overload_rate, by using the
4076	   following equation:

4078	   measured_overload_rate =
4079	   =((total_received_bytes)/T)-severe_congestion_restoration)

4081	   To provide reliable estimation of the encoded information several
4082	   techniques can be used, see [AtLi01], [AdCa03], [ThCo04], [AnHa06].
4083	   Note that since marking is done in interior nodes, the decisions are
4084	   made at egress nodes, and termination of flows are performed by
4085	   ingress nodes, there is a significant delay until the overload
4086	   information is learned by the ingress nodes, see Section 6 of
4087	   [CsTa05]). The delay consists of the trip time of data packets from
4088	   the severe congested interior node to the egress, the measurement
4089	   interval, i.e., T, and the trip time of the notification signaling
4090	   messages from egress to ingress. Moreover, until the overload
4091	   decreases at the severe congested interior node, an additional trip
4092	   time from the ingress node to the severe congested interior node must
4093	   expire. This is because immediately before receiving the congestion
4094	   notification, the ingress may have sent out packets in the flows that
4095	   were selected for termination. That is, a terminated flow may
4096	   contribute to congestion for a time longer that is taken from the
4097	   ingress to the interior node. Without considering the above, interior
4098	   nodes would continue marking the packets until the measured
4099	   utilization falls below the severe congestion restoration threshold.
4100	   In this way, at the end more flows will be terminated than necessary,
4101	   i.e., an over-reaction takes place. [CsTa05] provides a solution to
4102	   this problem, where the interior nodes use a sliding window memory to
4103	   keep track of the signaling overload in a couple of previous
4104	   measurement intervals. At the end of a measurement intervals, T,
4105	   before encoding and signaling the overloaded rate as "encoded DSCP"
4106	   packets, the actual overload is decreased with the sum of already
4107	   signaled overload stored in the sliding window memory, since that
4108	   overload is already being handled in the severe congestion handling
4109	   control loop. The sliding window memory consists of an integer number
4110	   of cells, i.e, n = maximum number of cells. Guidelines for
4111	   configuring the sliding window parameters are given in [CsTa05].

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

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

4121	   Sum_Mi =0
4122	   For i =1 to n
4123	   {
4124	   Sum_Mi = Sum_Mi + Mi
4125	   }

4127	   signaled_overload_rate = measured_overload_rate - Sum_Mi,

4129	   where Sum_Mi is calculated as above.

4131	   Next, the sliding memory is updated as follows:
4132	       for i = 1..(n-1): Mi <- Mi+1
4133	       Mn <- signaled_overload_rate

4135	   The bytes that have to be remarked to satisfy the signaled overload
4136	   rate: signaled_remarked_bytes, are calculated using the
4137	   following pseudo code:
4138	   IF severe_congestion_threshold <> Maximum PHB capacity
4139	   THEN
4140	    {
4141	     IF (incoming_encoded-DSCP_rate <> 0) AND
4142	        (incoming_encoded-DSCP_rate =< termination_offset_rate)
4143	     THEN
4144	        { signaled_remarked_bytes =
4145	         = ((signaled_overload_rate - incoming_encoded-DSCP_rate)*T)/N
4146	        }
4147	     ELSE IF (incoming_encoded-DSCP_rate > termination_offset_rate)
4148	     THEN signaled_remarked_bytes =
4149	         = ((signaled_overload_rate - termination_offset_rate)*T)/N
4150	     ELSE IF (incoming_encoded-DSCP_rate =0)
4151	     THEN signaled_remarked_bytes =
4152	         = signaled_overload_rate*T/N
4153	     }
4154	    ELSE signaled_remarked_bytes =  signaled_overload_rate *T/N

4156	    Where the incoming "encoded DSCP" rate is calculated as follows:
4157	    incoming_encoded-DSCP_rate =
4158	     = (received number of "encoded_DSCP" during T) * N)/T;

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

4165	   Note that in order to process an overload situation higher than 100%
4166	   of the maintained severe congestion threshold all the nodes within
4167	   the domain must be configured and maintain a scaling parameter, e.g.,
4168	   N used in the above equation, which in combination with the marked
4169	   bytes, e.g., signaled_remarked_bytes, such a high overload situation
4170	   can be calculated and represented. N can be equal or higher than 1.

4172	   Note that when incoming remarked bytes are dropped, the operation of
4173	   the severe congestion algorithm may be affected, e.g., the algorithm
4174	   may become in certain situations slower. An implementation of the
4175	   algorithm may assure as much as possible that the incoming marked
4176	   bytes are not dropped. This could for example be accomplished by
4177	   using different dropping rate thresholds for marked and unmarked
4178	   bytes.

4180	   Note that when the "affected DSCP" marking is used by a node
4181	   that is congested due to a a severe congestion situation then all
4182	   the outgoing packets that are not marked (i.e., by using the "encoded
4183	   DSCP") have to be remarked using the "affected DSCP" marking.
4184	   Furthermore, note that when the congestion notification based on
4185	   probing is used in combination with severe congestion, then in
4186	   addition to the possible "encoded DSCP" and "affected DSCP" another
4187	   DSCP for the remarking of the same PHB is used, see Section 4.6.1.7.
4188	   This additional DSCP is denoted in this document as "notified
4189	   DSCP". When an interior node operates
4190	   in the severe congested state, see Figure A.2, and receives "notified
4191	   DSCP" packets, these packets are considered to be unmarked packets
4192	   (but not "affected DSCP" packets). This means that during severe
4193	   congestion also the "notified DSCP" packets can be remarked and
4194	   encoded as either "encoded DSCP" or "affected DSCP" packets.

4196	Appendix A.1.2 Example of a detailed severe congestion operation in the
4197	Egress nodes

4199	   The states of operation in Egress nodes are similar to the ones
4200	   described in  A.1.1. The definition of the events, see below, is
4201	   however different than the definition of the events given in Figure
4202	   A.1 and Figure A.2:

4204	   * event A: when the egress receives a predefined rate of "notified
4205	   DSCP" marked bytes/packets then event_A is activated, see Section
4206	   4.6.1.7 and A.2.2. The predefined rate of "notified DSCP" marked
4207	   bytes is denoted as the congestion notification detection threshold.
4208	   Note this congestion notification detection threshold can also be
4209	   zero, meaning that the event_A is activated when the egress node,
4210	   during an interval T, receives at least one "notified DSCP" packet.

4212	   * event B: this event occurs when the egress receives packets marked
4213	   as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is
4214	   applied in the whole RMD domain).

4216	   * event C: this event occurs when the rate of incoming
4217	   "notified DSCP" packets decreases below the congestion notification
4218	   detection threshold. In the situation that the congestion
4219	   notification detection threshold is zero, this will mean that event C
4220	   is activated when the egress node, during an interval T, does not
4221	   receive any "notified DSCP" marked packets.

4223	   * event D: this event occurs when the egress, during an interval T,
4224	   does not receive packets marked as either "encoded DSCP" or "affected
4225	   DSCP" (when "affected DSCP" is applied in the whole RMD domain).

4227	   event E: this event occurs when the egress, during an interval T,
4228	   does not receive packets marked as either "encoded DSCP" or
4229	   "affected DSCP" (when "affected DSCP" is applied in the whole RMD
4230	   domain)

4232	   An example of the algorithm for calculation of the
4233	   number of flows associated with each priority class that have to be
4234	   terminated is explained by the pseudo-code below.

4236	   First, when the egress operates in the severe congestion state then
4237	   the total amount of remarked bandwidth associated with the PHB
4238	   traffic class, say total_congested_bandwidth, is calculated.
4239	   Note that when the node maintains information about
4240	   each ingress/egress pair aggregate, then the
4241	   total_congested_bandwidth must be calculated per ingress/egress pair
4242	   reservation aggregate. This bandwidth represents the severe congested
4243	   bandwidth that should be terminated. The total_congested_bandwidth
4244	   can be calculated as follows:

4246	   total_congested_bandwidth = N*input_remarked_bytes/T

4248	   Where, input_remarked_bytes represents the number of "encoded DSCP"
4249	   marked bytes that arrive at the egress, during one measurement
4250	   interval T, N is defined as in Section 4.6.1.6.2.1 and A.1.1. The
4251	   term denoted as terminated_bandwidth is a temporal variable
4252	   representing the total bandwidth that have to be terminated,
4253	   belonging to the same PHB traffic class. The
4254	   terminate_flow_bandwidth(priority_class) is the total of bandwidth
4255	   associated with flows of priority class equal to priority_class. The
4256	   parameter priority_class is an integer fulfilling

4258	   0 =< priority_class =< Maximum_priority.

4260	   The calculate_terminate_flows(priority_class) function determines the
4261	   flows for a given priority class and per PHB that has to be
4262	   terminated. This function also calculates the term
4263	   sum_bandwidth_terminate(priority_class), which is the sum of the
4264	   bandwith associated with the flows that will be terminated.
4265	   The constraint of finding the total number of flows that have to
4266	   be terminated is that sum_bandwidth_terminate(priority_class), should
4267	   be smaller or approximatelly equal to the variable
4268	   terminate_bandwidth(priority_class).

4270	     terminated_bandwidth = 0;
4271	     priority_class = 0;
4272	     while terminated_bandwidth < total_congested_bandwidth
4273	      {
4274	       terminate_bandwidth(priority_class) =
4275	       = total_congested_bandwidth - terminated_bandwidth
4276	       calculate_terminate_flows(priority_class);
4277	       terminated_bandwidth =
4278	       = sum_bandwidth_terminate(priority_class) + terminated_bandwidth;
4279	       priority_class = priority_class + 1;
4280	      }

4282	   If the egress node maintains ingress/egress pair reservation
4283	   aggregates, then the above algorithm is performed for each
4284	   ingress/egress pair reservation aggregate.

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

4289	   The predefined congestion notification threshold, see Appendix A.1.1,
4290	   is set according to, and usually less than, an engineered bandwidth
4291	   limitation, i.e., admission threshold, based on e.g. agreed Service
4292	   Level Agreement or a capacity limitation of specific links.
4293	   The difference between the congestion notification threshold and the
4294	   engineered bandwidth limitation, i.e., admission threshold, provides
4295	   an interval where the signaling information on resource limitation is
4296	   already sent by a node but the actual resource limitation is not
4297	   reached. This is due to the fact that data packets associated with an
4298	   admitted session have not yet arrived, while allows the admission
4299	   control process available at the egress to interpret the signaling
4300	   information and reject new calls before reaching congestion. Note
4301	   that in the situation when the data rate is higher than the
4302	   preconfigured congestion notification rate, also data packets are
4303	   re-marked, see section 4.6.1.6.2.1. To distinguish between congestion
4304	   notification and severe congestion, two methods may be used (see
4305	   Appendix 1.1.1):

4307	   * using different DSCP values (re-marked DSCP values). The remarked
4308	   DSCP that is used for this purpose is denoted as "notified DSCP" in
4309	   this document. When this method is used and when the interior node is
4310	   in "congestion notification" state, see A.1.1, then the node should
4311	   remark all the unmarked bytes passing through the node using the
4312	   "notified DSCP". Note that this method can only be applied if all
4313	   nodes in RMD domain use the "notified" DSCP marking. In this way,
4314	   also probe packets that will pass through the interior node that
4315	   operates in congestion notification state are being encoded using the
4316	   "notified DSCP" marking.

4318	   * Using the "encoded DSCP" marking for congestion notification and
4319	   severe congestion. This method is not described in detail in this
4320	   example appendix.

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

4325	   The admission control congestion notification procedure can be
4326	   applied only if the egress maintains the ingress/egress pair
4327	   aggregate. When the operation state of the ingress/egress pair
4328	   aggregate is the "congestion notification", see Appendix A.1.2, then
4329	   the implementation of the algorithm depends on how the congestion
4330	   notification situation is notified to the egress. As mentioned in
4331	   Section A.2.1, two methods are used:

4333	   * using the "notified DSCP". During a measurement interval T, the
4334	   egress counts the number of "notified DSCP" marked bytes that belong
4335	   to the same PHB and are associated with the same ingress/egress pair
4336	   aggregate, say input_notified_bytes. We denote the rate as
4337	   incoming_notified_rate.

4339	   * using the "encoded DSCP". In this case, during a measurement
4340	   interval T, the egress measures the input_notified_bytes by counting
4341	   the "encoded DSCP" bytes.

4343	   Below only the detail description of the first method is given.

4345	   The incoming congestion_rate can be then calculated as follows:

4347	   incoming_congestion_rate = input_notified_bytes/T

4349	   If the incoming_congestion_rate is higher than a preconfigured
4350	   congestion notification threshold, then the communication path
4351	   between ingress and egress is considered to be congested. Note that
4352	   the pre-congestion notification threshold can be set to zero. In this
4353	   case the egress node will operate in congestion notification state at
4354	   the moment that it receives at least one "notified DSCP" encoded
4355	   packet.

4357	   When the egress node operates in "congestion notification" state
4358	   and if the end-to-end RESERVE (probe) arrives at the egress, then
4359	   this request SHOULD be rejected. Note that this is happening
4360	   only when the probe packet is either "notified DSCP" or "encoded
4361	   DSCP" marked. In this way it is ensured that the end-to-end RESERVE
4362	   (probe) packet passed through the node that it is congested. This
4363	   feature is very useful when ECMP based routing is used to detect
4364	   Only flows that are passing through the congested router.

4366	   If such an ingress/egress pair aggregated state is not available when
4367	   the (probe) RESERVE message arrives at the egress, then this request
4368	   is accepted if the DSCP of the packet carrying the RESERVE messsage
4369	   is unmarked. Otherwise (if the packet is either "notified DSCP" or
4370	   "encoded DSCP" marked), it is rejected.

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

4375	   When a severe congestion occurs on e.g., in the forward path, and
4376	   when the algorithm terminates flows to solve the severe congestion in
4377	   forward path, then the reserved bandwidth associated with the
4378	   terminated bidirectional flows is also released. Therefore, a careful
4379	   selection of the flows that have to be terminated should take place.
4380	   A possible method of selecting the flows belonging to the same
4381	   priority type passing through the severe congestion point on a
4382	   unidirectional path can be the following:

4384	   * the egress node should select, if possible, first unidirectional
4385	   flows instead of bidirectional flows
4386	   * the egress node should select, if possible, bidirectional flows
4387	   that reserved a relatively small amount of resources on the path
4388	   reversed to the path of congestion.

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

4393	   This scenario describes a solution using the combination of the
4394	   severe congestion solutions described in Section 4.6.2.5.2.
4395	   It is considered that the severe congestion occurs simultaneously on
4396	   forward and reverse directions, which may affect the same bi-
4397	   directional flows.

4399	   When the QNE Edges maintain per-flow intra-domain QoS-NSLP
4400	   operational states then the steps can be the following, see Figure
4401	   A.3. Consider that the egress node selects a number of bi-directional
4402	   flows to be terminated. In this case the egress will send for each
4403	   bi-directional flows a NOTIFY message to ingress. If the Ingress
4404	   receives these NOTIFY messages and its operational state (associated
4405	   with reverse path) is in the severe congestion state (see Figure A.1
4406	   and A.2), then the ingress operates in the following way:

4408	QNE (Ingress)    NE (int.)    NE (int.)       NE (int.)    QNE (Egress)
4409	NTLP stateful                                             NTLP stateful
4410	data|    user        |                |           |               |
4411	--->|    data        | #unmarked bytes|           |               |
4412	    |--------------->S #marked bytes  |           |               |
4413	    |                S--------------------------->|               |
4414	    |                |                |           |-------------->|data
4415	    |                |                |           |               |--->
4416	    |                |                |           |              Term.?
4417	    |            NOTIFY               |           |               |Yes
4418	    |<------------------------------------------------------------|
4419	    |                |                |           |               |data
4420	    |                |                |  user     |               |<---
4421	    |   user data    |                |  data     |<--------------|
4422	    | (#marked bytes)|                S<----------|               |
4423	    |<--------------------------------S           |               |
4424	    | (#unmarked bytes)               S           |               |
4425	Term|<--------------------------------S           |               |
4426	Flow?                |                S           |               |
4427	YES |RESERVE(RMD-QSpec):              S           |               |
4428	    |"forward - T tear"               s           |               |
4429	    |--------------->|  RESERVE(RMD-QSpec):       |               |
4430	    |                |  "forward - T tear"        |               |
4431	    |                |--------------------------->|               |
4432	    |                |                S           |-------------->|
4433	    |                |                S         RESERVE(RMD-QSpec):
4434	    |                |                S       "reverse - T tear"  |
4435	    |      RESERVE(RMD-QSpec)         S           |<--------------|
4436	    |      "reverse - T tear"         S<----------|               |
4437	    |<--------------------------------S           |               |

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

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

4446	   * The ingress then calculates the total bandwidth that should be
4447	   released in the reverse direction (thus not in forward direction) if
4448	   the bidirectional flows will be terminated (preempted), say
4449	   "notify_reverse_bandwidth". This bandwidth can be calculated by the
4450	   sum of the bandwidth values associated with all the end-to-end
4451	   sessions that received a (severe congestion) NOTIFY message.

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

4459	   * The ingress then calculates the bandwidth of the additional flows
4460	   that have to be terminated, say "additional_reverse_bandwidth", in
4461	   order to solve the severe congestion in reverse direction, by taking
4462	   into account:

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

4468	   **  the total amount of bandwidth in the reverse direction that has
4469	   been calculated by using the received marked packets, i.e.,
4470	   "marked_reverse_bandwidth".
4471	   This additional bandwidth can be calculated using the following
4472	   algorithm:

4474	    IF ("marked_reverse_bandwidth" > "notify_reverse_bandwidth") THEN
4475	    "additional_reverse_bandwidth" =
4476	     = "marked_reverse_bandwidth"- "notify_reverse_bandwidth";
4477	    ELSE
4478	    "additional_reverse_bandwidth" = 0

4480	* Ingress terminates the flows that experienced a severe congestion
4481	in the "forward" path and received a (severe congestion) NOTIFY
4482	   message

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

4489	   * If the number of required uni-directional flows (to satisfy the
4490	   above issue) is not available, then a number of bi-directional flows
4491	   that are using the same egress-ingress reverse direction
4492	   communication path MAY be selected for pre-emption in order to
4493	   satisfy the release of a total bandiwtdh equal up to the:
4494	   "additional_reverse_bandwidth".  Note that using the guidelines given
4495	   in Appendix A.3.1, first the bidirectional flows that reserved a
4496	   relatively small amount of resources on the path reversed to the path
4497	   of congestion should be selected for termination.

4499	   When the QNE Edges maintain aggregated intra-domain QoS-NSLP
4500	   operational states then the steps can be the following.

4502	   * The egress calculates the bandwidth to be terminated using the same
4503	   method as described in Section 4.6.1.6.2.2. The egress includes this
4504	   bandwidth value in a <PDR Bandwidth> within a "PDR_Congestion_Report"
4505	   container that is carried by the end-to-end NOTIFY message.

4507	   * The Ingress receives the NOTIFY message and reads the <PDR
4508	   Bandwidth> value included in the "PDR_Congestion_Report" container.
4509	   Note that this value is denoted as "notify_reverse_bandwidth" in the
4510	   situation that the QNE edges maintain per flow intra-domain QoS-NSLP
4511	   operational states, but is calculated differently. The variables
4512	   "marked_reverse_bandwidth" and "additional_reverse_bandwidth are
4513	   calculated using the same steps as explained for the situation that
4514	   the QNE edges maintain per flow intra-domain QoS-NSLP states.

4516	   * Regarding the termination of flows that are using the same egress-
4517	   ingress reverse direction communication path, the Ingress can follow
4518	   the same procedures as the situation that the QNE edges
4519	   maintain per-flow intra-domain QoS-NSLP operational states.

4521	   The RMD aggregated (reduced state) reservations maintained by the
4522	   interior nodes, can be reduced in the "forward" and "reverse"
4523	   directions by using the procedure described in Section 4.6.2.3 and
4524	   including in the  <Bandwith> parameter within the "RMD-QOSM QOS
4525	   Description" field carried by the "forward" intra-domain RESERVE the
4526	   value equal to "notify_reverse_bandwidth" and by including the
4527	   "additional_reverse_bandwidth" value in the <PDR Bandwidth> parameter
4528	   within the "PDR_Release_Request" container that is carried by the
4529	   same intra-domain RESERVE message.

4531	Appendix A.4 Pre-emption handling during admission control

4533	   This section describes the mechanism that can be supported by the
4534	   QNE Ingress, QNE Interior and QNE Egress nodes to satisfy
4535	   pre-emption during the admission control process.
4536	   This mechanism uses the pre-emption building blocks specified in
4537	   [QoS-NSLP].

4539	A.4.1 Pre-emption handling in QNE Ingress nodes

4541	  If a QNE Ingress receives a RESERVE for a session that
4542	  causes other session(s) to be pre-empted, for each of these to be
4543	  pre-empted sessions, then the QNE Ingress follows the following steps:

4545	Step_1:

4547	  The QNE Ingress MUST send a tearing RESERVE downstream and add a
4548	  BOUND_SESSION_ID, with Binding_Code value equal to "Indicated session
4549	  caused pre-emption" that indicates the SESSION_ID of the session that
4550	  caused the pre-emption. Furthermore, an INFO-SPEC object with error
4551	  code value equal to "Reservation pre-empted" has to be included in
4552	  each of these tearing RESERVE messages..
4553	  The selection of which flows have to be preempted can be based on
4554	  predefined policies. For example, this selection process can be based
4555	  on the MRI associated with the high and low priority sessions. In
4556	  particular, the QNE Ingress can select low(er) priority session(s)
4557	  where their MRI is "close" (especially the target IP) to the one
4558	  associated with the higher priority session. This means that
4559	  typically the high priority session and the to be preempted lower
4560	  priority sessions are following the same communication path and are
4561	  passing through the same QNE Egress node.

4563	  Furthermore, the amount of lower priority sessions that have to be
4564	  pre-empted per each high priority session, has to be such that the
4565	  requested resources by the higher priority session should be lower or
4566	  equal than the sum of the reserved resources associated with the lower
4567	  priority sessions that have to be pre-empted.

4569	Step_2:

4571	  For each of the sent tearing RESERVE(s) the QNE Ingress will send a
4572	  NOTIFY message with an INFO-SPEC objects with error code value equal
4573	  to "Reservation pre-empted" towards the QNI.

4575	Step_3:

4577	  After sending the pre-empted (tearing) RESERVE(s), the Ingress QNE
4578	  will send the (reserving) RESERVE, which caused the pre-emption,
4579	  downstream towards the QNE Egress.

4581	A.4.2 Pre-emption handling in QNE Interior nodes

4583	  The QNE Interior upon receiving the first (tearing) RESERVE that
4584	  carries the BOUND_SESSION_ID object with Binding_Code value
4585	  equal to "Indicated session caused pre-emption" and an INFO-SPEC
4586	  object with error code value equal to "Reservation
4587	  preempted" it considers that this session has to be pre-empted.
4588	  In this case the QNE Interior creates a so called "pre-emption state",
4589	  which is identified by the SESSION_ID carried in the pre-emption
4590	  related BOUND_SESSION_ID object. Furthermore, this "pre-emption state"
4591	  will include the SESSION_ID of the session associated with the
4592	  (tearing) RESERVE. If subsequently additional tearing RESERVE(s) are
4593	  arriving including the same values of BOUND_SESSION_ID and INFO-SPEC
4594	  objects, then the associated SESSION_IDs of these (tearing) RESERVE
4595	  message will be included in the already created "pre-emption state".
4596	  The QNE will then set a timer, with a value that is high enough to
4597	  ensure that it will not expire before the (reserving) RESERVE arrives.
4598	  Note that when the "pre-emption state" timer expires then the
4599	  bandwidth associated with the pre-empted session(s) will have to be
4600	  released, following a normal RMD-QOSM bandwidth release procedure..
4601	  If the QNE interior node will not receive the all to be pre-empted
4602	  (tearing) RESERVE messages sent by the QNE Ingress before their
4603	  associated (reserving) RESERVE message arrives, then the (reserving)
4604	  RESERVE message will not reserve any resources and this message will
4605	  be "M" marked, see Section 4.6.1.2. Note that this situation is not a
4606	  typical situation. Typically, this situation can only occur when at
4607	  least one of (tearing) RESERVe messages are dropped due to an error
4608	  condition.

4610	  Otherwise, if the QNE Interior receives the all to be pre-empted
4611	  (tearing) RESERVE messages sent by the QNE Ingress, then the QNE
4612	  Interior will remove the pending resources, and make the new
4613	  reservation using normal RMD-QOSM bandwidth release and reservation
4614	  procedures.

4616	A.4.3 Pre-emption handling in QNE Egress nodes

4618	  Similar to the QNE Interior operation, the QNE Egress upon receiving
4619	  the first (tearing) RESERVE that carries the BOUND_SESSION_ID object
4620	  with Binding_Code value equal to "Indicated session caused
4621	  pre-emption" and an INFO-SPEC object with error code value equal to
4622	  "Reservation preempted" it considers that this session has to be pre-
4623	  empted. Similar to the QNE Interior operation the QNE Egress creates a
4624	  so called "pre-emption state", which is identified by the SESSION_ID
4625	  carried in the pre-emption related BOUND_SESSION_ID object. This "pre-
4626	  emption state" will store the same type of information and use the
4627	  same timer value as specified in section A.4.2.

4629	  If subsequently additional tearing RESERVE(s) are
4630	  arriving including the same values of BOUND_SESSION_ID and INFO-SPEC
4631	  objects, then the associated SESSION_IDs of these (tearing) RESERVE
4632	  message will be included in the already created "pre-emption state".
4633	  If the (reserving) RESERVE sent by the QNE Ingress node arrived and is
4634	  not "M" marked and if all the to be pre-empted (tearing) RESERVE
4635	  messages arrived then the QNE Egress will remove the pending resources
4636	  and make the new reservation using normal RMD-QOSM procedures.

4638	  If the QNE Egress receives a "M" marked RESERVE message then the QNE
4639	  Egress will use the normal partial RMD-QOSM procedure to release the
4640	  partial reserved resources associated with the "M" marked RESERVE, see
4641	  Section 4.6.1.2.

4643	  If the QNE Egress will not receive all the to be pre-empted (tearing)
4644	  RESERVE messages sent by the QNE Ingress before their associated and
4645	  not "M" marked (reserving) RESERVE message arrives, then the following
4646	  steps can be followed:

4648	 * If the QNE Egress uses an end-to-end QOSM supports the pre-emption
4649	   handling then the QNE Egress have to calculate and select new
4650	   lower priority sessions that have to be terminated. The way of how
4651	   the to be pre-empted sessions are selected and signalled to the
4652	   downstream QNEs is similar to the operation specified in Section
4653	   A.4.1.
4654	 * If the QNE Egress does not use an end-to-end QOSM that supports
4655	   the pre-emption handling then the QNE Egress has to reject the
4656	   requesting (reserving) RESERVE associated with the high priority
4657	   session, see Section 4.6.1.2.

4659	   Note that typically, the situation that the QNE Egress does not
4660	   receive all the to be pre-empted (tearing) RESERVE messages sent by
4661	   the QNE Ingress can only occur when at least one of (tearing) RESERVe
4662	   messages are dropped due to an error condition.

4664	A.5 Retransmission procedure within the RMD domain

4666	   If the retransmission of intra-domain RESERVE messages within the RMD
4667	   domain is not disallowed then all the QNE Interior nodes SHOULD use
4668	   the functionality described in this section.

4670	   In this situation we enable QNE Interior nodes to maintain a replay
4671	   cache in which each entry contains the <RSN>, <SESSION_ID> (available
4672	   via GIST), <REFRESH_PERIOD> (available via the QoS NSLP [QoS-NSLP])
4673	   and the last received "PHR Container" <Container ID> carried by the
4674	   RMD-QSpec for each session [QSP-T]. Thus this solution uses
4675	   information carried by QOS-NSLP objects [QoS-NSLP] and parameters
4676	   carried by the RMD-QSpec "PHR Container". The following phases can be
4677	   distinguished:

4679	   Phase 1: Create Replay Cache Entry

4681	   When an Interior node receives an intra-domain RESERVE
4682	   message and its cache is empty or there is no matching entry, it
4683	   reads the <Container ID> field of the "PHR container" of the received
4684	   message. If the <Container ID> is a PHR_RESOURCE_REQUEST, which
4685	   indicates that the intra-domain Reserve message is a reservation
4686	   request, then the QNE Interior node creates a new entry in the cache
4687	   and copies the <RSN>, <SESSION_ID> and <Container ID> to the entry
4688	   and sets the <REFRESH_PERIOD>.
4689	   By using the information stored in the List the Interior node
4690	   verifies whether the received intra-domain RESERVE message is sent
4691	   by an adversary or not. For example, if the
4692	   <SESSION_ID> and <RSN> of a received intra-domain RESERVE message
4693	   match the values stored in the List then the Interior node checks the
4694	   <Container ID> part.

4696	   If the <Container_ID> is different then:

4698	     Situation D1: <Container ID> in its own list is
4699	        PHR_RESOURCE_REQUEST, and <Container ID> in the message is
4700	        PHR_REFRESH_UPDATE;

4702	     Situation D2: <Container ID> in its own list is
4703	        PHR_RESOURCE_REQUEST or PHR_REFRESH_UPDATE, and <Container ID>
4704	        in the message is PHR_RELEASE_REQUEST;

4706	     Situation D3: <Container ID> in its own list is PHR_REFRESH_UPDATE,
4707	        and <Container ID> in the message is PHR_RESOURCE_REQUEST;

4709	    For Situation D1, the QNE Interior node processes this message by
4710	    RMD-QoSM default operation, reserves bandwidth, updates the entry
4711	    and passes the message to downstream nodes. For Situation D2, the
4712	    QNE Interior node processes this message by RMD-QoSM default
4713	    operation, releases bandwidth, deletes all entries associated with
4714	    the session and passes the message to downstream nodes. For
4715	    situation D3, the QNE Interior node does not use/process the
4716	    <Bandwidth> parameter carried by the received intra-domain RESERVE
4717	    message. Furthermore, the <K> flag in the "PHR Container"
4718	    have to be set such that the <Bandwidth> parameter carried by the
4719	    intra-domain RESERVE message is not processed/used by a QNE
4720	    Interior node.

4722	    If the <Container_ID> is the same then:

4724	     Situation S1: <Container ID> is equal to PHR_RESOURCE_REQUEST;
4725	     Situation S2: <Container ID> is equal to PHR_REFRESH_UPDATE;
4726	     For situation S1, the QNE Interior node does not process the
4727	     intra-domain RESERVE message but it just passes it to
4728	     downstream nodes, because
4729	     it might have been retransmitted by the QNE Ingress node;
4730	     For situation S2, the QNE Interior node processes the first
4731	     incoming intra-domain (refresh) RESERVE message within a refresh
4732	     period and updates the entry and forwards it to the downstream
4733	     nodes.

4735	    If only <Session_ID> is matched to the list, then the QNE Interior
4736	    Node checks the <RSN>. Here also two situations can be
4737	    distinguished:

4739	    If a rerouting takes place, see Section 5.2.5.2 in [QoS-NSLP], the
4740	    <RSN> in the message will be equal either to <RSN + 2> in the
4741	    stored list if it is not a tearing RESERVE or to <RSN -1> in the
4742	     stored list if it is a tearing RESERVE:

4744	     The QNE Interior node will check the <Container ID> part;

4746	     If the <RSN> in the message is equal to <RSN + 2> in the
4747	     stored list and the <Container ID> is a PHR_RESOURCE_REQUEST or
4748	     PHR_REFRESH_UPDATE then the received intra-domain RESERVE
4749	     message has to be interpreted and processed as a typical
4750	     (non tearing) RESERVE message, which is caused by rerouting, see
4751	      Section 5.2.5.2 in [QoS-NSLP].

4753	     If the <RSN> in the message is equal to <RSN-1> in the
4754	     stored list and the <Container ID> is a PHR_RELEASE_REQUEST
4755	     then the received intra-domain RESERVE message has to be
4756	     interpreted and processed as a typical (tearing) RESERVE
4757	     message, which is caused by rerouting, see Section 5.2.5.2 in
4758	     [QoS-NSLP].

4760	     If other situations occur than the ones described above, then
4761	     the QNE Interior node does not use/process the
4762	     <Bandwidth> parameter carried by the received intra-domain
4763	     RESERVE message. Furthermore, the <K> paramer has to be set, see
4764	     above.

4766	    Phase 2: Update Replay Cache Entry

4768	    When a QNE Interior node receives an intra-domain RESERVE message,
4769	    it retrieves the corresponding entry from the cache and compares the
4770	    values. If the message is valid, the Interior node will update
4771	    <Container ID> and <REFRESH_PERIOD> in the List entry.

4773	    Phase 3: Delete Replay Cache Entry

4775	    When a QNE Interior node receives an intra-domain (tear) RESERVE
4776	    message and an entry in the replay cache can be found, then the
4777	    QNE Interior node will delete this entry after processing the
4778	    message. Furthermore, the Interior node will delete cache entries,
4779	    if it did not receive an intra-domain (refresh) Reserve message
4780	    during the <REFRESH_PERIOD> period with a <Container_ID> value equal
4781	    to PHR_REFRESH_UPDATE.

4783	Intellectual Property Statement

4785	   The IETF takes no position regarding the validity or scope of any
4786	   Intellectual Property Rights or other rights that might be claimed
4787	   to pertain to the implementation or use of the technology
4788	   described in this document or the extent to which any license
4789	   under such rights might or might not be available; nor does it
4790	   represent that it has made any independent effort to identify any
4791	   such rights.  Information on the procedures with respect to rights
4792	   in RFC documents can be found in BCP 78 and BCP 79.

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

4801	   The IETF invites any interested party to bring to its attention
4802	   any copyrights, patents or patent applications, or other
4803	   proprietary rights that may cover technology that may be required
4804	   to implement this standard.  Please address the information to the
4805	   IETF at ietf-ipr@ietf.org.

4807	Full Copyright Statement

4809	   Copyright (C) The IETF Trust (2008).

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

4815	   This document and the information contained herein are provided on an
4816	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
4817	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
4818	   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
4819	   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
4820	   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
4821	   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
4822	   PURPOSE.