idnits 2.17.1 

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

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

  ** The document seems to lack a License Notice according IETF Trust
     Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
     Section 6.b -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     (You're using the IETF Trust Provisions' Section 6.b License Notice from
     12 Feb 2009 rather than one of the newer Notices.  See
     https://trustee.ietf.org/license-info/.)


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

  -- The document date (2 March 2009) is 5527 days in the past.  Is this
     intentional?


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

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

  ** 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 (==), 2 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: 2 Sepetember 2009                         Georgios Karagiannis
5	                                                   University of Twente
6	                                                       Cornelia Kappler
7	                                                                Siemens
8	                                                             Tom Phelan
9	                                                                  Sonus

11	                                                           2 March 2009

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

16	Status of this Memo

18	   This Internet-Draft is submitted to IETF in full conformance with the
19	   provisions of BCP 78 and BCP 79.

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

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

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

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

37	   This Internet-Draft will expire on September 3, 2009.

39	Copyright Notice

41	   Copyright (c) 2009 IETF Trust and the persons identified as the
42	   document authors.  All rights reserved.

44	   This document is subject to BCP 78 and the IETF Trust's Legal
45	   Provisions Relating to IETF Documents in effect on the date of
46	   publication of this document (http://trustee.ietf.org/license-info).
47	   Please review these documents carefully, as they describe your rights
48	   and restrictions with respect to this document.

50	Intended status: Experimental RFC
51	Abstract

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

67	Table of Contents

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

116	1.  Introduction

118	   This document describes a Next Steps In Signaling (NSIS) QoS model
119	   for networks that use the Resource Management in Diffserv (RMD)
120	   framework ([RMD1], [RMD2], [RMD3], [RMD4]). RMD adds admission
121	   control to Diffserv networks and allows nodes external to the
122	   networks to dynamically reserve resources within the Diffserv
123	   domains.

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

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

141	                          Stateless or reduced state        Egress
142	   Ingress                RMD nodes                         Node
143	   Node                   (Interior Nodes; I-Nodes)        (Stateful
144	   (Stateful              |          |            |         RMD QoS
145	   RMD QoS NLSP           |          |            |         NSLP Node)
146	   Node)                  V          V            V
147	   +-------+   Data +------+      +------+       +------+     +------+
148	   |-------|--------|------|------|------|-------|------|---->|------|
149	   |       |   Flow |      |      |      |       |      |     |      |
150	   |Ingress|        |I-Node|      |I-Node|       |I-Node|     |Egress|
151	   |       |        |      |      |      |       |      |     |      |
152	   +-------+        +------+      +------+       +------+     +------+
153	            =================================================>
154	            <=================================================
155	                                  Signaling Flow

157	   Figure 1: Actors in the RMD-QOSM

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

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

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

177	2.  Terminology

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

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

186	   In addition, the following terms are used:

188	   NSIS domain: a NSIS signalling capable domain.

190	   RMD domain: a NSIS domain that is capable of supporting the RMD-QOSM
191	   signalling and operations.

193	   Edge node: a QoS-NSLP node on the boundary of some
194	   administrative domain that connects one NSIS domain to a node
195	   either in another NSIS domain or in a non NSIS domain.

197	   NSIS aware node: a node that is aware of NSIS signalling and RMD-
198	   QOSM operations, such as severe congestion detection and DSCP
199	   marking.

201	   NSIS unaware: a node that is unware of NSIS signalling, but is
202	   aware of RMD-QOSM operations such as severe congestion detection
203	   and DSCP marking.

205	   Ingress node: An edge node in its role in handling the traffic
206	   as it enters the NSIS domain.

208	   Egress node: An edge node in its role in handling the traffic
209	   as it leaves the NSIS domain.
210	   Interior node: a node in a NSIS domain that is not an edge node.

212	3.  Overview of RMD and RMD-QOSM

214	3.1.  RMD

216	   The Differentiated Services (Diffserv) architecture ([RFC2475],
217	   [RFC2638]) was introduced as a result of efforts to avoid the
218	   scalability and complexity problems of Intserv [RFC1633].
219	   Scalability is achieved by offering services on an aggregate
220	   rather than per-flow basis and by forcing as much of the per-flow
221	   state as possible to the edges of the network.  The service
222	   differentiation is achieved using the Differentiated Services (DS)
223	   field in the IP header and the Per-Hop Behavior (PHB) as the main
224	   building blocks.  Packets are handled at each node according to the
225	   PHB indicated by the DS field in the message header.

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

234	   RMD was introduced as a method for dynamic reservation of resources
235	   within a Diffserv domain.  It describes a method that is able to
236	   provide admission control for flows entering the domain and a
237	   congestion handling algorithm that is able to terminate flows in
238	   case of congestion due to a sudden failure (e.g., link, router)
239	   within the domain.

241	   In RMD, scalability is achieved by separating a fine-grained
242	   reservation mechanism used in the edge nodes of a Diffserv domain
243	   from a much simpler reservation mechanism needed in the Interior
244	   nodes.  Typically it is assumed that edge nodes support per-
245	   flow QoS states in order to provide QoS guarantees for each flow.
246	   Interior nodes use only one aggregated reservation state per traffic
247	   class or no states at all.  In this way it is possible to handle
248	   large numbers of flows in the Interior nodes. Furthermore, due to
249	   the limited functionality supported by the Interior nodes, this
250	   solution allows fast processing of signaling messages.

252	   The possible RMD-QOSM applicabilities are described in Section
253	   3.2.3. Two main basic admission control modes are supported:
254	   reservation-based and measurement-based admission control that can
255	   be used in combination with a severe congestion handling solution.
256	   The severe congestion handling solution is used in the situation
257	   that a link/node becomes severely congested due to the fact that the
258	   traffic supported by a failed link/node is rerouted and has to be
259	   processed by this link/node. Furthermore, RMD-QOSM supports both
260	   uni-directional and bi-directional reservations.

262	   Another important feature of RMD-QOSM is that the intra-domain
263	   sessions supported by the edges can be either per flow sessions or
264	   per aggregate sessions. In case of the per flow intra-domain
265	   sessions, the maintained per flow intra-domain states have a one-to-
266	   one dependency to the per flow end-to-end states supported by the
267	   same edge. In case of the per-aggregate sessions the maintained per-
268	   aggregate states have a one-to-many relationship to the per flow
269	   end-to-end states supported by the same edge.

271	   In the reservation-based method, each Interior node maintains
272	   only one reservation state per traffic class.  The Ingress edge
273	   nodes aggregate individual flow requests into PHB traffic classes,
274	   and signal changes in the class reservations as necessary.  The
275	   reservation is quantified in terms of resource units (or bandwidth).
276	   These resources are requested dynamically per PHB and reserved on
277	   demand in all nodes in the communication path from an Ingress node
278	   to an Egress node.

280	   The measurement-based algorithm continuously measures traffic levels
281	   and the actual available resources, and admits flows whose resource
282	   needs are within what is available at the time of the request. Once
283	   an admission decision is made, no record of the decision need be
284	   kept at the interior nodes.  The advantage of measurement-based
285	   resource management
286	   protocols is that they do not require pre-reservation state nor
287	   explicit release of the reservations at the interior nodes.
288	   Moreover, when the user
289	   traffic is variable, measurement based admission control could
290	   provide higher network utilization than, e.g., peak-rate
291	   reservation.  However, this can introduce an uncertainty in the
292	   availability of the resources.

294	   Two types of measurement based admission control schemes are
295	   possible:

297	   * Congestion notification function based on probing:

299	   This method can be used to implement a simple measurement-based
300	   admission control within a Diffserv domain. In this scenario the
301	   interior nodes are not NSIS aware nodes. In these interior nodes
302	   thresholds are set for the traffic belonging to different PHBs in
303	   the measurement based admission control function. In this scenario
304	   an end-to-end NSIS message is used as a probe packet, meaning that
305	   the DSCP field in the header of the IP packet that carries the NSIS
306	   message is re-marked when the predefined congestion threshold is
307	   exceeded. Note that when the predefined congestion threshold is
308	   exceeded all packets are remarked by a node, including NSIS
309	   messages. In this way the edges can admit or reject flows that are
310	   requesting resources. The rate of the re-marked data packets is used
311	   to detect a congestion situation that can influence the admission
312	   control decisions.

314	   * NSIS measurement-based admission control:

316	   In this case the measurement-based admission control functionality
317	   is implemented in NSIS aware stateless routers. The main difference
318	   between this type of admission control and the congestion
319	   notification based on probing is related to the fact that this type
320	   of admission control is applied mainly on NSIS aware nodes, giving
321	   the possibility to apply measuring techniques, see e.g., [JaSh97],
322	   [GrTs03], that are using current and past information on NSIS
323	   sessions that requested resources from an NSIS aware interior node.
324	   The admission decision is positive if the currently carried traffic,
325	   as characterized by the measured statistics, plus the requested
326	   resources for the new flow exceeds the system capacity with a
327	   probability smaller than some alpha. Otherwise, the admission
328	   decision is negative.

330	   RMD describes the following procedures:

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

336	   * Hop-by-hop admission control based on a PHB within the
337	     domain. There are two possible modes of operation for internal
338	     nodes to admit requests. One mode is the stateless or
339	     measurement-based mode, where the resources within the domain are
340	     queried. Another mode of operation is the reduced-state
341	     reservation or reservation based mode, where the resources within
342	     the domain are reserved.

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

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

352	3.2. Basic features of RMD-QOSM

354	3.2.1 Role of the QNEs

356	   The protocol model of the RMD-QOSM is shown in Figure 2.  The figure
357	   shows QNI and QNR nodes, not part of the RMD network, that are the
358	   ultimate initiator and receiver of the QoS reservation requests.  It
359	   also shows QNE nodes that are the Ingress and Egress nodes in the
360	   RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are
361	   Interior nodes (QNE Interior).

363	   All nodes of the RMD domain are usually QoS-NSLP aware nodes.
364	   However, in the scenarios where the congestion notification function
365	   based on probing is used, then the interior nodes are not NSIS
366	   aware.  Edge nodes store and maintain QoS-NSLP and NTLP states and
367	   therefore are stateful nodes.  The NSIS aware Interior nodes are
368	   NTLP stateless. Furthermore they are either QoS-NSLP stateless (for
369	   NSIS measurement-based operation), or are reduced state nodes
370	   storing per PHB aggregated QoS-NSLP states (for reservation-based
371	   operation).

373	   Note that the RMD domain may contain Interior nodes that are
374	   not NSIS aware nodes (not shown in the figure).  These nodes are
375	   assumed to have sufficient capacity for flows that might be
376	   admitted.  Furthermore, some of these NSIS unaware nodes may be used
377	   for measuring the traffic congestion level on the data path. These
378	   measurements can be used by RMD-QOSM in the congestion control based
379	   on probing operation and/or severe congestion operation
380	   (see Section 4.6.1.6).

382	     |------|   |-------|                           |------|   |------|
383	     | e2e  |<->| e2e   |<------------------------->| e2e  |<->| e2e  |
384	     | QoS  |   | QoS   |                           | QoS  |   | QoS  |
385	     |      |   |-------|                           |------|   |------|
386	     |      |   |-------|   |-------|   |-------|   |------|   |      |
387	     |      |   | local |<->| local |<->| local |<->| local|   |      |
388	     |      |   | QoS   |   |  QoS  |   |  QoS  |   |  QoS |   |      |
389	     |      |   |       |   |       |   |       |   |      |   |      |
390	     | NSLP |   | NSLP  |   | NSLP  |   | NSLP  |   | NSLP |   | NSLP |
391	     |st.ful|   |st.ful |   |st.less/   |st.less/   |st.ful|   |st.ful|
392	     |      |   |       |   |red.st.|   |red.st.|   |      |   |      |
393	     |      |   |-------|   |-------|   |-------|   |------|   |      |
394	     |------|   |-------|   |-------|   |-------|   |------|   |------|
395	     ------------------------------------------------------------------
396	     |------|   |-------|   |-------|   |-------|   |------|   |------|
397	     | NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP |<->|NTLP  |
398	     |st.ful|   |st.ful |   |st.less|   |st.less|   |st.ful|   |st.ful|
399	     |------|   |-------|   |-------|   |-------|   |------|   |------|
400	       QNI         QNE        QNE         QNE          QNE       QNR
401	     (End)     (Ingress)   (Interior)  (Interior)   (Egress)    (End)

403	         st.ful: stateful, st.less: stateless
404	         st.less red.st.: stateless or reduced state

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

408	3.2.2 RMD-QOSM/QoS-NSLP Signaling

410	   The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The
411	   signalling scenarios are accomplished using the QoS-NSLP processing
412	   rules defined in [QoS-NSLP], in combination with the RMF triggers
413	   sent via the QoS-NSLP-RMF API described in [QoS-NSLP]. A RESERVE
414	   message is created by a QNI with an Initiator QSpec describing the
415	   reservation and forwarded along the path towards the QNR.  When the
416	   original RESERVE message arrives at the Ingress node, an RMD-QSpec
417	   is constructed based on the initial QSpec in the message (usually
418	   the Initiator QSpec).  The RMD-QSpec is sent in a intra-domain,
419	   independent RESERVE message through the Interior nodes towards the
420	   QNR. This intra-domain RESERVE message uses the  GIST datagram
421	   signaling mechanism. Note that the RMD-QOSM cannot directly specify
422	   that the GIST datagram mode should be used. This can however be
423	   notified by using the GIST API Transfer-Attributes, such as
424	   unreliable, low level of security and use of local policy.
425	   Meanwhile, the original RESERVE message is sent to the Egress node
426	   on the path to the QNR using the reliable transport mode of NTLP.

428	          QNE Ingress     QNE Interior     QNE Interior   QNE Egress
429	        NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
430	               |               |               |              |
431	       RESERVE |               |               |              |
432	      -------->| RESERVE       |               |              |
433	               +--------------------------------------------->|
434	               | RESERVE`      |               |              |
435	               +-------------->|               |              |
436	               |               | RESERVE`      |              |
437	               |               +-------------->|              |
438	               |               |               | RESERVE`     |
439	               |               |               +------------->|
440	               |               |               |     RESPONSE`|
441	               |<---------------------------------------------+
442	               |               |               |              | RESERVE
443	               |               |               |              +------->
444	               |               |               |              |RESPONSE
445	               |               |               |              |<-------
446	               |               |               |     RESPONSE |
447	               |<---------------------------------------------+
448	       RESPONSE|               |               |              |
449	      <--------|               |               |              |

451	   Figure 3: Sender-initiated reservation with Reduced State Interior
452	             Nodes

454	   Each QoS-NSLP node on the data path processes the intra-domain
455	   RESERVE message and checks the availability of resources with either
456	   the reservation-based or the measurement-based method.  When the
457	   message reaches the Egress node, and the reservation is successful
458	   in each Interior node, an intra-domain (local) RESPONSE` is sent
459	   towards the ingress node and the original (end-to-end) RESERVE
460	   message is forwarded to the next domain.  When the Egress node
461	   receives a RESPONSE message from the downstream end, it is forwarded
462	   directly to the Ingress node.

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

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

477	3.2.3 RMD-QOSM Applicability and considerations

479	   The RMD-QOSM is a Diffserv-based bandwidth management methodology
480	   that is not able to provide a full Diffserv support. The reason of
481	   this is that the RMD-QOSM concept can only support the (Expedited
482	   Forwarding) EF-like functionality behavior, but is not able to
483	   support the full set of (Assured Forwarding) AF-like functionality.
484	   The bandwidth information required by the EF-like functionality
485	   behaviour can be supported by RMD-QOSM carrying the bandwidth
486	   information in the <QoS Desired> parameter, see [QSP-T]. The full set
487	   of (Assured Forwarding) AF-like functionality requires information
488	   that is specified in two token buckets. The RMD-QOSM is not
489	   supporting the use of two token buckets and therefore, it is not able
490	   to support the full set of AF-functionality. Note however,
491	   that RMD-QOSM could also support a single AF PHB, when the traffic
492	   or the upper limit of the traffic can be characterized by a single
493	   bandwidth parameter.

495	   A very important consideration on using RMD-QOSM is that within one
496	   RMD domain only one of the following RMD-QOSM schemes can be used at
497	   a time. Thus a RMD router can never process and use two different
498	   RMD-QOSM signaling schemes at the same time. The operator of an RMD
499	   domain has to pre-configure all routers in the domain such that
500	   within one RMD domain only one of the below described RMD-QOSM
501	   schemes can be used at a time. Note however, that there is no single
502	   to implement scheme variant.

504	   It is important to note that the concepts described in Sections
505	   4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2 and 4.6.2.5.2 contributed to
506	   the PCN WG standardisation.

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

510	   * per flow congestion notification based on probing" (see
511	     Sections 4.3.2, 4.6.1.7., 4.6.2.6.). Note that this scheme uses for
512	     severe congestion handling the "Severe congestion handling by
513	     proportional data packet marking", see Section 4.6.1.6.2,
514	     4.6.2.5.2). Furthermore, the interior nodes are considered to be
515	     Diffserv aware, but NSIS unaware nodes, see Section 4.3.2.

517	   * "per flow RMD NSIS measurement based admission control" (see
518	     Sections 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses for
519	     severe congestion handling the "Severe congestion handling by
520	     proportional data packet marking", see Section 4.6.1.6.2,
521	     4.6.2.5.2). Furthermore, the interior nodes are considered to be
522	     NSIS aware nodes, see Section 4.3.2.

524	   * "per flow RMD reservation based" in combination with "severe
525	     congestion handling by the RMD-QOSM refresh procedure" (see
526	     Sections 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this
527	     scheme uses for severe congestion handling the "Severe congestion
528	     handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1,
529	     4.6.2.5.1). Furthermore, the intra-domain sessions supported by the
530	     edge nodes are per flow sessions, see Section 4.3.3.

532	   * "per flow RMD reservation based" in combination with "severe
533	     congestion handling by proportional data packet marking" procedure
534	     (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that
535	     this scheme uses for severe congestion handling the "Severe
536	     congestion handling by proportional data packet marking" procedure,
537	     see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the intra-domain
538	     sessions supported by the edge nodes are per flow sessions, see
539	     Section 4.3.3.

541	   * "per aggregate RMD reservation based" in combination with
542	     "severe congestion handling by the RMD-QOSM refresh procedure" (see
543	     Sections 4.3.1, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this
544	     scheme uses for severe congestion handling the "Severe congestion
545	     handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1,
546	     4.6.2.5.1). Furthermore, the intra-domain sessions supported by the
547	     edge nodes are per aggregate sessions, see Section 4.3.1.

549	   * "per aggregate RMD reservation based" in combination with
550	     "severe congestion handling by proportional data packet marking"
551	     procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, 4.6.2.5.2).
552	     Note that this scheme uses for severe congestion handling the
553	     "Severe congestion handling by proportional data packet marking"
554	     procedure, see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the
555	     intra-domain sessions supported by the edge nodes are per aggregate
556	     sessions, see Section 4.3.1.

558	4.  RMD-QOSM, Detailed Description

560	   This section describes the RMD-QOSM in more detail.  In particular,
561	   it defines the role of stateless and reduced-state QNEs, the
562	   RMD-QOSM QSpec Object, the format of the RMD-QOSM QoS-NSLP messages
563	   and how QSpecs are processed and used in different protocol
564	   operations.

566	4.1.  RMD-QSpec Definition

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

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

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

582	   The Per Hop Reservation container (PHR container) and
583	   the Per Domain Reservation container (PDR container) are specified
584	   in Section 4.1.2 and 4.1.3, respectively. The <PHR container>
585	   contains the traffic handling directives for intra-domain
586	   communication and reservation.  The <PDR container> contains
587	   additional traffic handling directives that is needed for
588	   edge-to-edge communication. The parameter IDs used by the <PHR
589	   container> and <PDR container> are assigned by IANA, see Section 6.
590	   For clarity Reasons we will assigned temporarily, the following names
591	   to the PHR and PDR containers:
592	       * PHR_1 to PHR_3 for the <PHR container>
593	       * PDR_4 to PDR_10 for the <PDR container>
594	   After IANA assigns the proper ID values to the PHR and PDR
595	   containers, then the above list has to be replaced accordingly.

597	   The "RMD-QOSM object combination", i.e., <QoS Desired> and
598	   <QoS Reserved>,  is specified in Section 4.1.1. The "RMD-
599	   QOSM QoS object combination" and the <PHR container> are used and
600	   processed by the Edge and Interior nodes.  The <PDR container> field
601	   is only processed by Edge nodes.

603	4.1.1.  RMD-QOSM object combination

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

609	   "RMD-QOSM object combination" = <QoS Desired> for RESERVE
610	   "RMD-QOSM object combination" = <QoS Reserved> for RESPONSE
611	   <QoS Desired> = <Bandwidth> <PHB Class> <Admission Priority>
612	   <QoS Reserved> = <Bandwidth> <PHB Class> <Admission Priority>

614	   The bit format of the <PHB Class> (see [QSP-T] and Figure 4 and
615	   Figure 5) and <Admission Priority> complies to the bit format
616	   specified in [QSP-T]. The bit format used for the <Bandwidth>
617	   parameter is shown below and it is identical to the peak rate (p)
618	   <TMOD-1> parameter format specified in [QSP-T]. Note that after IANA
619	   assigns the proper ID value to the <Bandwdith> parameter then the
620	   Bandwdith_ID term has to be replaced accordingly.

622	     0                   1                   2                   3
623	     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
624	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
625	    |1|E|0|r|       Bandwidth_IDID    |r|r|r|r|          1            |
626	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
627	    | Peak Data Rate-1 (p)  (32-bit IEEE floating point number)     |
628	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

630	            <Bandwidth> parameter format

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

636	            0                   1
637	            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
638	           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
639	           | DSCP      |0 0 0 0 0 0 0 0 X 0|
640	           +---+---+---+---+---+---+---+---+

642	             Figure 4: DSCP parameter

644	            0                   1
645	            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
646	           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
647	           |    PHB ID code        |0 0 X X|
648	           +---+---+---+---+---+---+---+---+

650	            Figure 5: PHB ID Code parameter

652	4.1.2.  PHR Container

654	   This section describes the parameters used by the PHR container,
655	   which are used by the RMD-QOSM functionality available at the
656	   Interior nodes.

658	   <PHR container> = <Overload %>, <K>, <S>,<M>,
659	   <Admitted Hops>, <B>, <Hop_U>, <Time Lag>, <Max Admitted Hops>

661	   The bit format of the PHR container can be seen in Figure 6. Note
662	   that in Figure 6 <Hop U> is represented as <U>. Furthermore, in
663	   Figure 6 <Max Admitted Hops> is represented as <Max Adm Hops>.

665	     0                   1                   2                   3
666	     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
667	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
668	    |M|E|N|r|       Container ID    |r|r|r|r|          2            |
669	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
670	    |S|M| Admitted  Hops|B|U| Time  Lag     |  Overload %   |K|     |
671	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
672	    | Max Adm  Hops |                                               |
673	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

675	        Figure 6: PHR container

677	   Parameter/Container ID: 8 bit field, indicating the PHR type:
678	   PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update.

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

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

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

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

701	   <Overload %>:
702	   8 bits In case of severe congestion the level of overload is
703	   indicated by the Overload %.  Overload % SHOULD be higher than 0 if
704	   S bit is set.  If overload in a node is greater than the overload
705	   in a previous node then Overload % SHOULD be updated. For more
706	   details see Section 4.6.1.6.1.

708	   <M>:
709	   1 bit.  In case of unsuccessful resource reservation or resource
710	   query in an Interior QNE, this QNE sets the M bit in order to
711	   notify the Egress QNE.

713	   <Admitted Hops>:
714	   8 bit field.  The <Admitted Hops> counts the number of hops in the
715	   RMD domain where the reservation was successful.  The <Admitted
716	   Hops> is set to "0" when a RESERVE message enters a domain and it
717	   MUST be incremented by each Interior QNE, provided that the Hop_U bit
718	   is not set.  However when a QNE that does
719	   not have sufficient resources to admit the reservation is reached,
720	   the M Bit is set, and the <Admitted Hops> value is frozen, by setting
721	   the Hop_U bit to "1". Note that the <Admitted Hops> parameter in
722	   combinations with the <Max Admitted Hops> and <K> parameters are used
723	   during the RMD partial release procedures, see Section 4.6.1.5.2.

725	   <Hop_U> (NSLP_Hops unset):
726	   1-bit. The QNE(Ingress) node MUST set the <Hop_U> parameter to
727	   0.  This parameter SHOULD be set to "1" by a node when the node does
728	   not increase the <Admitted Hops> value. This is the case when an
729	   RMD-QOSM reservation-based node is not admitting the reservation
730	   request. When <Hop_U> is set "1" the <Admitted Hops> SHOULD NOT be
731	   changed. Note that this flag in combination with the <Admitted Hops>
732	   flag are used to locate the last node that successfully processed a
733	   reservation request, see Section 4.6.1.2.

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

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

740	   <K>: 1 bit. When set to "1" it indicates that the resources/bandwidth
741	   carried by a tearing RESERVE MUST NOT be released and the
742	   resources/bandwidth carried by a non tearing RESERVE MUST NOT be
743	   reserved/refreshed.

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

750	4.1.3.  PDR container

752	   This section describes the parameters of the PDR container, which are
753	   used by the RMD-QOSM functionality available at the
754	   Edge nodes.

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

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

761	   Note that in Figure 7 <Max Admitted Hops> is represented as
762	   <Max Adm Hops>.

764	       0                   1                   2                   3
765	       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
766	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
767	      |M|E|N|r|   Container ID        |r|r|r|r|          2            |
768	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
769	      |S|M| Max Adm  Hops |B|  Overload %   |       Empty       |     |
770	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
771	      |PDR Bandwidth(32-bit IEEE floating point.number)               |
772	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

774	        Figure 7: PDR container

776	   Parameter/Container ID:

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

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

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

789	   "PDR_Release_Request" (Parameter/Container ID = PDR_6): generated
790	   and sent by the QNE(Ingress) node to the QNE(Egress) node to release
791	   the per domain reservation states explicitly
792	   "PDR_Reservation_Report" (Parameter/Container ID = PDR_7): generated
793	   and sent by the QNE(Egress) node to the QNE(Ingress) node to
794	   report that a "PHR_Resource_Request" and a
795	   "PDR_Reservation_Request" traffic handling directive fields have been
796	   received and that the request has been admitted or rejected

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

803	   "PDR_Release_Report" (Parameter/Container ID = PDR_9) generated and
804	   sent by the QNE(Egress) node in case needed, to the QNE(Ingress)
805	   node to report that a "PHR_Release_Request" and a
806	   "PDR_Release_Request" traffic handling directive fields have been
807	   received and have been processed.

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

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

818	   <Overload %>:
819	   8-bit.  It includes the Overload % of the
820	   "PHR_Resource_Request" or "PHR_Refresh_Update" control
821	   information fields, indicating the level of overload to the Ingress
822	   node.  For more details see Section 4.6.1.6.1.

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

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

830	   <Max Admitted Hops>:
831	   8-bit.  The <Admitted Hops> value that has been carried by the
832	   PHR container field used to identify the RMD reservation based node
833	   that admitted or process a "PHR_Resource_Request"
834	   <PDR Bandwidth>:
835	   32 bits.  This field specifies the bandwidth that either applies
836	   when the "B" flag is set to "1" and when this parameter is carried
837	   by a RESPONSE message, or when a severe congestion occurs and the
838	   QNE edges maintain an aggregated intra-domain QoS-NSLP operational
839	   state and it is carried by a NOTIFY message.  In the situation that
840	   the "B" flag is set to "1" this parameter specifies the requested
841	   bandwidth that have to be reserved by a node in the reverse
842	   direction and when the intra-domain signaling procedures require a
843	   bi-directional reservation procedure.  In the severe congestion
844	   situation this parameter specifies the bandwidth that has to be
845	   released.

847	4.2.  Message Format

849	   The format of the messages used by the RMD-QOSM complies with the
850	   QoS-NSLP and QSpec template specifications.  The QSpec used by RMD-
851	   QOSM is denoted in this document as RMD-QSpec and is described in
852	   Section 4.1.

854	4.3.  RMD node state management

856	   The QoS-NSLP state creation and management is specified in
857	   [QoS-NSLP].  This section describes the state creation and
858	   management functions of the Resource Management Function (RMF) in
859	   the RMD nodes.

861	4.3.1 Aggregated operational and reservation states at the QNE Edges

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

868	   In this case the intra-domain sessions supported by the edges are per
869	   aggregate sessions that have a one-to-many relationship to the per
870	   flow end-to-end states supported by the same edge.
871	   Note that the method of selecting the end-to-end sessions that form
872	   an aggregate is not specified in this document. An example how this
873	   can be accomplished is by monitoring the GIST routing states used by
874	   the end-to-end sessions and group the ones that use the same <PHB
875	   class>, QNE Ingress and QNE Egress addresses and the value of the
876	   priority level. Note that this priority level should be deduced from
877	   the priority parameters carried by the initial QSpec object.

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

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

885	   When the operational state (at QNE ingress and QNE egress) supports
886	   unidirectional reservations then this state must contain a list with
887	   BOUND_SESSION_IDs maintaining the SESSION_ID values of its bound
888	   end-to-end sessions. The BINDING_CODE associated with this
889	   BOUND_SESSION_ID is set to code (Aggregated sessions).  Thus the
890	   operational state maintains a list of BOUND_SESSION_IDs entries.
891	   Each entry is created when an end-to-end session joins the
892	   aggregated intra-domain session and is removed when an end-to-end
893	   session leaves the aggregate.

895	   It is important to emphasize that in this case, the operational
896	   state (at QNE ingress and QNE egress) that is maintained by each
897	   end-to-end session bound to the aggregated intra-domain session it
898	   must contain in the BOUND_SESSION_ID, the SESSION_ID value of the
899	   bound tunnelled intra-domain (aggregate) session. The BINDING_CODE
900	   associated with this BOUND_SESSION_ID is set to code (Aggregated
901	   sessions).

903	   When the operational state (at QNE ingress and QNE egress) supports
904	   bidirectional reservations then the operational state must contain a
905	   list of BOUND_SESSION_ID sets. Each set contain two
906	   BOUND_SESSION_IDs.  One of the BOUND_SESSION_IDs maintains the
907	   SESSION_ID value of one of bound end-to-end session. The
908	   BINDING_CODE associated with this BOUND_SESSION_ID is set to code
909	   (Aggregated sessions). Another BOUND_SESSION_ID, within the same set
910	   entry, maintains the SESSION_ID of the bidirectional bound end-to-
911	   end session. The BINDING_CODE associated with this BOUND_SESSION_ID
912	   is set to code (Bi-directional sessions).

914	   Note that in each set, a one to one relation exists between each
915	   BOUND_SESSION_ID with BINDING_CODE set to (Aggregate sessions) and
916	   each BOUND_SESSION_ID with BINDING_CODE set to (Bi-directional
917	   sessions). Each set is created when an end-to-end session joins the
918	   aggregated operational state and is removed when an end-to-end
919	   session leaves the aggregated operational state.

921	   It is important to emphasize that in this case, the operational
922	   state (at QNE ingress and QNE egress) that is maintained by each
923	   end-to-end session bound to the aggregated intra-domain session it
924	   must contain two types of BOUND_SESSION_IDs. One is the
925	   BOUND_SESSION_ID that must contain the SESSION_ID value of the bound
926	   tunelled aggregated intra-domain session that is using the
927	   BINDING_CODE set to (Aggregated sessions). The other
928	   BOUND_SESSION_ID maintains the SESSION_ID of the bound bidirectional
929	   end-to-end session. The BINDING_CODE associated with this
930	   BOUND_SESSION_ID is set to code (Bi-directional sessions).

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

938	   The size of the aggregated reservations needs to be
939	   greater or equal to the sum of bandwidth of the inter domain
940	   (end-to-end) reservations/sessions it aggregates, see e.g., Section
941	   1.4.4 of [RFC3175].  A policy can be used
942	   to maintain the amount of required bandwidth on a given aggregated
943	   reservation by taking into account the sum of the underlying inter
944	   domain (end-to-end) reservations, while endeavouring to change
945	   reservation less frequently.  This MAY require a trend analysis.
946	   If there is a significant probability that in the next interval of
947	   time the current aggregated reservation is exhausted, the Ingress
948	   router MUST predict the necessary bandwidth and request it.  If the
949	   Ingress router has a significant amount of bandwidth reserved but
950	   has very little probability of using it, the policy MAY predict the
951	   amount of bandwidth required and release the excess.  To increase or
952	   decrease the aggregate, the RMD modification procedures SHOULD be
953	   used (see Section 4.6.1.4).

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

960	4.3.2  Measurement-based method

962	   The QNE Edges maintain per flow intra-domain QoS-NSLP operational
963	   and reservation states that are containing similar data structures
964	   as described in Section 4.3.1. The main difference is associated
965	   with the different types of the used MRI and the bound end-to-end
966	   sessions. The structure of the maintained BOUND_SESSION_IDs depends
967	   on whether a unidirectional reservation or a bidirectional
968	   reservation is supported.

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

976	   It is important to emphasize that in this case, the operational
977	   state (at QNE ingress and QNE egress) that is maintained by the end-
978	   to-end session bound to the per-flow intra-domain session it must
979	   contain in the BOUND_SESSION_ID, the SESSION_ID value of the bound
980	   tunnelled per-flow intra-domain session. The BINDING_CODE associated
981	   with this BOUND_SESSION_ID is set to code (Tunnelled and end-to-end
982	   sessions).

984	   When bidirectional reservations are supported then the operational
985	   state (at QNE ingress and QNE egress) must contain two types of
986	   BOUND_SESSION_IDs. One is the BOUND_SESSION_ID that maintains the
987	   SESSION_ID value of the bound tunnelled per-flow intra-domain
988	   session.  The BINDING_CODE associated with this BOUND_SESSION_ID is
989	   set to code (Tunnelled and end-to-end sessions).
990	   The other BOUND_SESSION_ID maintains the SESSION_ID of the bound
991	   bidirectional end-to-end session. The BINDING_CODE associated with
992	   this BOUND_SESSION_ID is set to code (Bi-directional sessions).

994	   It is important to emphasize, in this case, that the operational
995	   state (at ingress and egress) that is maintained by the end-to-end
996	   session bound to the per-flow intra-domain session must contain two
997	   types of BOUND_SESSION_IDs.  One of the BOUND_SESSION_IDs must
998	   contain the SESSION_ID of its bound end-to-end session that is using
999	   a BINDING_CODE with value set to code (Tunnelled and end-to-end
1000	   sessions).  Another BOUND_SESSION_ID maintains the SESSION_ID of the
1001	   bound bidirectional end-to-end session. The BINDING_CODE associated
1002	   with this BOUND_SESSION_ID is set to code (Bi-directional sessions).

1004	   Furthermore, the QoS-NSLP reservation state maintains the PHB class
1005	   value, the value of the bandwidth requested by the end-to-end
1006	   session bound to the intra-domain session and the value of the
1007	   priority level.

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

1011	   * Congestion notification based on probing:

1013	   In this scheme the interior nodes are Diffserv aware but not NSIS
1014	   aware nodes. Each interior node counts the bandwidth that is used
1015	   by each PHB traffic class. This counter value is stored in an
1016	   RMD_QOSM state. For each traffic belonging to a PHB traffic class a
1017	   predefined congestion threshold is set. The predefined congestion
1018	   notification threshold is set according to, an engineered bandwidth
1019	   limitation based on e.g. agreed Service Level Agreement or a
1020	   capacity limitation of specific links. The threshold is usually less
1021	   than the capacity limit, i.e., admission threshold, in order to
1022	   avoid congestion due to the error of estimating the actual traffic
1023	   load. The value of this threshold SHOULD be stored in another
1024	   RMD_QOSM state.

1026	   In this scenario end-to-end NSIS message is used as a probe packet.
1027	   In this case the DSCP field of the GIST message is re-marked when
1028	   the predefined congestion notification threshold is exceeded in an
1029	   interior node. In this way it is ensured that the end-to-end NSIS
1030	   message passed through the node that it is congested. This feature
1031	   is very useful when ECMP (Equal Cost Multiple Path) based routing is
1032	   used to detect only flows that are passing through the congested
1033	   node. Note that in this situation, not only the probe packet is
1034	   remarked, but also data packets passing though the congested node
1035	   are re-marked.

1037	   * NSIS measurement-based admission control:
1038	   The measurement based admission control is implemented in NSIS aware
1039	   stateless routers. Thus the main difference between this type of the
1040	   measurement-based admission control and the congestion notification-
1041	   based admission control is the fact that the interior nodes are NSIS
1042	   aware nodes. In particular, the QNE Interior nodes operating
1043	   in NSIS measurement-based mode are QoS-NSLP stateless nodes, i.e.,
1044	   they do not support any QoS-NSLP or NTLP/GIST states.  These
1045	   measurement-based nodes store two RMD-QOSM states per PHR group.
1046	   These states reflect the traffic conditions at the node and are not
1047	   affected by QoS-NSLP signaling. One state stores the measured user
1048	   traffic load associated with the PHR group and another state stores
1049	   the maximum traffic load threshold that can be admitted per PHR
1050	   group. When a measurement-based node receives a intra-domain RESERVE
1051	   message, it compares the requested resources to the available
1052	   resources (maximum allowed minus current load) for the requested PHR
1053	   group.  If there are insufficient resources, it sets the <M> bit in
1054	   the RMD-QSpec.  No change to the RMD-QSpec is made when there are
1055	   sufficient resources.

1057	4.3.3  Reservation-based method

1059	   The QNE Edges maintain intra-domain QoS-NSLP operational and
1060	   reservation states that are containing similar data structures as
1061	   described in Section 4.3.1.

1063	   In this case the intra-domain sessions supported by the edges are per
1064	   flow sessions that have a one-to-one relationship to the per
1065	   flow end-to-end states supported by the same edge.
1066	   The QNE Interior nodes operating in reservation-based mode are QoS-
1067	   NSLP reduced state nodes, i.e., they do not store NTLP/GIST states
1068	   but they do store per PHB-aggregated QoS-NSLP states.

1070	   The reservation-based PHR installs and maintains one reservation
1071	   state per PHB, in all the nodes located in the communication path.
1072	   This state is identified by the PHB class value and it maintains the
1073	   number of currently reserved resource units (or bandwidth).  Thus,
1074	   the QNE Ingress node signals only the resource units requested by
1075	   each flow.  These resource units, if admitted, are added to the
1076	   currently reserved resources per PHB.

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

1082	   An example of how the admission control and its maintenance process
1083	   occurs in the interior nodes is described in Section 3 of [CsTa05].
1084	   The simplified concept that is used by the per traffic class
1085	   admission control process in the interior nodes, is based on the
1086	   following equation:
1087	        last + p <= T,
1088	   where p: requested bandwidth rate, T: admission threshold, which
1089	   reflects the maximum traffic volume that can be admitted in the
1090	   traffic class, last: a counter that records the aggregated sum of
1091	   the signaled bandwidth rates of previous admitted flows.

1093	   The per-PHB group reservation states maintained in the interior
1094	   nodes are soft states, which are refreshed by sending periodic
1095	   refresh intra-domain RESERVE messages, which are initiated by the
1096	   Ingress QNEs. If a refresh message corresponding to a number of
1097	   reserved resource units (i.e., bandwidth) is not received, the
1098	   aggregated reservation state is decreased in the next refresh period
1099	   by the corresponding amount of resources that were not refreshed.
1100	   The refresh period can be refined using a sliding window algorithm
1101	   described in [RMD3].

1103	   The reserved resources for a particular flow can also be
1104	   explicitly released from a PHB reservation state by means of a
1105	   intra-domain RESERVE release/tear message, which is generated by the
1106	   Ingress QNEs.  The usage of explicit release enables the
1107	   instantaneous release of the resources regardless of the length of
1108	   the refresh period.  This allows a longer refresh period, which also
1109	   reduces the number of periodic refresh messages.

1111	   Note that both in case of measurement- and (per-flow and aggregated)
1112	   RMD reservation-based methods,the way of how the maximum bandwidth
1113	   thresholds are maintained is out of the specification of this
1114	   document. However, when admission
1115	   priorities are supported, the Maximum Allocation [RFC4125] or the
1116	   Russian Dolls [RFC4127] bandwidth allocation model may be used. In
1117	   this case three types of priority traffic classes within the same
1118	   PHB, e.g., Expedited Forwarding, can be differentiated. These three
1119	   different priority traffic classes, which are associated to the same
1120	   PHB, are denoted in this document as PHB_low_priority,
1121	   PHB_normal_priority and PHB_high_priority, and are identified by the
1122	   PHB class value and the priority value, which is carried in the
1123	   <Admission Priority> RMD-QSpec parameter.

1125	4.4.  Transport of RMD-QOSM messages

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

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

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

1142	   * the interior nodes do not create any NTLP routing state.
1143	     This can be satisfied by
1144	     passing this requirement from the QoS-NSLP layer to the GIST layer
1145	     via the API. However, between the QNE Egress and QNE Ingress
1146	     routing states that are associated with intra-domain sessions
1147	     should be created that can be used for the communication of GIST
1148	     Data messages sent by a QNE Egress directly to a QNE Ingress. This
1149	     type of routing state associated with an intra-domain session can
1150	     be generated and used in the following way:

1152	   * When the QNE Ingress has to send an initial intra-domain RESERVE
1153	     message, the QoS-NSLP sends this message by including in the GIST
1154	     API SendMessage primitive, the Unreliable and No security
1155	     attributes. The GIST then, will probably send this NSLP message
1156	     by piggybacking it on a GIST QUERY message. The GIST functionality
1157	     in each QNE Interior node will receive the GIST QUERY message and
1158	     by using the RecvMessage GIST API primitive it will pass the intra-
1159	     domain RESERVE message to the QoS-NSLP functionality. At the same
1160	     time the GIST functionality uses the Routing-State-Check boolean
1161	     to find out if the QoS-NSLP needs to create a routing state. The
1162	     QoS-NSLP sets this Boolean to inform GIST to not create a routing
1163	     state and to forward the GIST QUERY further downstream with the
1164	     modified QoS-NSLP payload, which will include the modified intra-
1165	     domain RESERVE message. The intra-domain RESERVE is sent in the
1166	     same way up to the QNE Egress. The QNE Egress needs to create a
1167	     routing state. Therefore at the moment that the GIST functionality
1168	     passes the intra-domain RESERVE message, via the GIST RecvMessage
1169	     primitive, to the QoS-NSLP, then at the same time the QoS-NSLP
1170	     sets the Routing-State-Check boolean such that a routing state is
1171	     created. The GIST creates the routing state using normal GIST
1172	     procedures. After this phase the QNE Ingress and QNE Egress have,
1173	     for the particular session, routing states that can route traffic
1174	     directly from QNE Ingress to QNE Egress and from QNE Egress to
1175	     QNE Ingress. The routing state at the QNE Egress can be used by
1176	     the QoS-NSLP and GIST to send an intra-domain RESPONSE or intra-
1177	     domain NOTIFY directly to the QNE Ingress using GIST Data
1178	     messages. Note that this routing state is refreshed using normal
1179	     GIST procedures.

1181	   * When the QNE Ingress needs to send an intra-domain RESERVE
1182	     message that is not an initial RESERVE, then the QoS-NSLP sends
1183	     this message by including in the GIST API SendMessage primitive
1184	     the Unreliable and No security attributes. Furthermore the Local
1185	     policy attribute is set such that GIST sends the intra-domain
1186	     RESERVE message in a Q-mode even if there is a routing state at
1187	     the QNE Ingress. In this way the GIST functionality uses its local
1188	     policy to send the intra-domain RESERVE message by piggybacking it
1189	     on a GIST DATA message and sending it in Q-mode even if there is a
1190	     routing state for this session. The intra-domain RESERVE message
1191	     is piggybacked on the GIST DATA message that is forwarded and
1192	     processed by the QNE Interior nodes up to the QNE Egress.

1194	   The transport of the original (end-to-end) RESERVE message is
1195	   accomplished in the following way:
1196	   At the QNE ingress the original (end-to-end) RESERVE message is
1197	   forwarded but ignored by the stateless or reduced-state nodes, see
1198	   Figure 3. The intermediate (interior) nodes are bypassed using
1199	   multiple levels of NSLP-ID values (see [QoS-NSLP]). This is
1200	   accomplished by marking the end-to-end RESERVE message, i.e.,
1201	   modifying the QoS-NSLP default NSLP-ID value to another NSLP-ID
1202	   predefined value.

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

1211	4.5  Edge discovery and message addressing

1213	   Mainly, the Egress node discovery can be performed either by using
1214	   the GIST discovery mechanism [GIST], manual configuration or any
1215	   other discovery technique.  The addressing of signaling messages
1216	   depends on the used GIST transport mode.  The RMD-QOSM/QoS-NSLP
1217	   signaling messages that are processed only by the Edge nodes use the
1218	   peer-peer addressing of the GIST connection (C) mode.  RMD-QOSM/QoS-
1219	   NSLP signaling messages that are processed by all nodes of the
1220	   Diffserv domain, i.e., Edges and Interior nodes, use the end-end
1221	   addressing of the GIST datagram (D) mode. Note that the RMD-QOSM
1222	   cannot directly specify that the GIST connection or the GIST datagram
1223	   mode should be used. This can only be specified by using, via the
1224	   QoS-NSLP-RMF API, the GIST API Transfer-Attributes, such as
1225	   reliable or unreliable, high or low level of
1226	   security and by the use of local policies. RMD QoS signaling
1227	   messages that are addressed to the data path end nodes are
1228	   intercepted by the Egress nodes. In particular, at the ingress and
1229	   for downstream intra-domain messages, the RMD-QOSM instructs the
1230	   GIST functionality, via the GIST API to use among others:

1232	   * unreliable and low level security Transfer-Attributes
1233	   * do not create a GIST routing state
1234	   * uses the D-mode MRI

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

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

1243	   *  unreliable and low level of security Transfer-Attributes

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

1249	4.6.  Operation and sequence of events

1251	4.6.1.  Basic unidirectional operation

1253	   This section describes the basic unidirectional operation and
1254	   sequence of events/triggers of the RMD-QOSM.  The following basic
1255	   operation cases are distinguished:

1257	   * Successful reservation (Section 4.6.1.1),
1258	   * Unsuccessful reservation (Section 4.6.1.2),
1259	   * RMD refresh reservation (Section 4.6.1.3),
1260	   * RMD modification of aggregated reservation (4.6.1.4)
1261	   * RMD release procedure (Section 4.6.1.5.)
1262	   * Severe congestion handling (Section 4.6.1.6.)
1263	   * Admission control using congestion notification based on probing
1264	     (Section 4.6.1.7.).

1266	   The QNEs at the Edges of the RMD domain support the RMD QoS Model and
1267	   end-to-end QoS models, which process the RESERVE message differently.
1268	   Note that the term end-to-end QoS model applies to any QoS model that
1269	   is initiated and terminated outside the RMD-QOSM aware domain.
1270	   However, there might be situations where a QoS model is initiated
1271	   and/or terminated by the QNE Edges and is considered to be an end-to-
1272	   end QoS model. This can occur when the QNE Edges can also operate as
1273	   either QNI or as QNR and at the same time they can operate as either
1274	   sender or receiver of the data path. Note that the described
1275	   functionality described in Sections 4.6.1.1, 4.6.1.2, 4.6.1.3,
1276	   4.6.1.5, and 4.6.1.6 applies to the RMD reservation-based and to
1277	   the NSIS measurement-basedadmission
1278	   control methods. The described functionality in Section 4.6.1.7
1279	   applies to the admission control procedure that uses the congestion
1280	   notification based on probing. The QNE Edge nodes maintain either per
1281	   flow QoS-NSLP operational and reservation states or aggregated QoS-
1282	   NSLP operational and reservation states.

1284	   When the QNE Edges maintain aggregated QoS-NSLP operational and
1285	   reservation states, the RMD-QOSM functionality may accomplish a RMD
1286	   modification procedure (see Section 4.6.1.4), instead of the
1287	   reservation initiation procedure that is described in this
1288	   subsection. Note that it is recommended that the QNE implementations
1289	   of RMD-QOSM process the QoS-NSLP signaling messages with a higher
1290	   priority than data packets. This can be accomplished as described in
1291	   Section 3.3.4 of [QoS-NSLP] and it can be requested via the QoS-NSLP-
1292	   RMF API described in [QoS-NSLP]. The signalling scenarios described
1293	   in this section are accomplished using the QoS-NSLP processing rules
1294	   defined in [QoS-NSLP], in combination with the RMF triggers sent via
1295	   the QoS-NSLP-RMF API described in [QoS-NSLP].

1297	4.6.1.1.  Successful reservation

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

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

1305	4.6.1.1.1. Operation in Ingress node

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

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

1317	   If the initial QSpec does not contain the <PHB Class> parameter,
1318	   then the selection of the <PHB class> that is carried by the intra-
1319	   domain RMD-QSpec is defined by a local policy similar to the
1320	   procedures discussed in [RFC2998] and [RFC3175].
1321	   For example, in the situation that the initial QSpec is used by
1322	   the IntServ Controlled Load QOSM then the Expedited Forwarding (EF)
1323	   PHB is appropriate to set the <PHB class> parameter carried by the
1324	   intra-domain RMD-QSpec, see [RFC3175].

1326	   If the initial QSpec does not carry the <Admission Priority>
1327	   parameter then the <Admission Priority> parameter in the RMD-QSpec
1328	   will not be populated. If the initial QSpec does not carry the
1329	   <Admission Priority> parameter, but it carries other priority
1330	   parameters, then it is considered that edges as being stateful nodes,
1331	   are able to control the priority of the sessions that are
1332	   entering or leaving the RMD domain in accordance to the priority
1333	   parameters. Note that the RMF reservation states, see Section 4.3, in
1334	   the QNE edges store the value of the <Admission Priority> parameter
1335	   that is used within the RMD domain in case of pre-emption and severe
1336	   congestion situations, see Section 4.6.1.6.
1337	   If the RMD domain supports pre-emption during the admission control
1338	   process, then the QNE Ingress node can support the building
1339	   blocks specified in the [QoS-NSLP] and during the admission
1340	   control process use the example pre-emption handling algorithm
1341	   described in Appendix 4.
1342	   Note that in the above described case, the QNE egress uses, if
1343	   available, the tunnelled initial priority parameters, which can
1344	   be interpreted by the QNE egress.

1346	   If the initial QSpec carries the <Excess Treatment> parameter,
1347	   then the QNE ingress and QNE egress nodes MUST control the excess
1348	   traffic that is entering or leaving the RMD domain in accordance to
1349	   the <Excess Treatment> parameter. Note that the RMD-QSpec does not
1350	   carry the <Excess Treatment> parameter. However, by using the <PHB
1351	   class> parameter the RMD domain uses the excess treatment procedures
1352	   specified by the particular PHB standard.

1354	   If the requested <TMOD-1> parameter carried by the initial QSpec,
1355	   cannot be satisfied, then an end to end RESPONSE message has to be
1356	   generated. However, in order to decide whether the end-to-end
1357	   reservation request was locally (at the QNE Ingress) satisfied, also
1358	   a local(at the QNE_Ingress) RMD-QoSM admission control procedure has
1359	   to be performed. In other words, the RMD-QOSM functionality has to
1360	   verify whether the value included in the RMD-QOSM <Bandwidth> can be
1361	   reserved and stored in the RMD-QOSM reservation states, see Sections
1362	   4.6.1.1.2 and 4.3.

1364	   An initial QSpec object MUST be included in the end-to-end
1365	   RESPONSE message. The parameters included in the QSpec <QoS
1366	   Reserved> object are copied from the original <QoS Desired> values.
1367	   The "E" flag associated with the QSPEC <QoS Reserved> object and the
1368	   "E" flag associated with the <Bandwidth> parameter are set. In
1369	   addition, the INFO-SPEC object is included in the end to end RESPONSE
1370	   message. The error code used by this INFO-SPEC is:

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

1377	   If the request was satisfied locally (see Section 4.3), the Ingress
1378	   QNE node generates two RESERVE messages: one intra-domain and
1379	   one end-to-end RESERVE message. Note however, that when the
1380	   aggregated QOS-NSLP operational and reservation states are used by
1381	   the QNE Ingress, then the generation of the intra-domain RESERVE
1382	   message depends on the availability of the aggregated QoS-NSLP
1383	   operational state. If this aggregated QoS-NSLP operational state is
1384	   available, then the RMD modification of aggregated reservations
1385	   described in section 4.6.1.4. is used.

1387	   It is important to note that when "per flow RMD reservation based"
1388	   scenario is used within the RMD domain, the retransmission within the
1389	   RMD domain SHOULD be disallowed. The reason of this is related to the
1390	   fact that the QNI Interior nodes are not able to differentiate
1391	   between a retransmitted RESERVE message associated with a certain
1392	   session and an initial RESERVE message belonging to another session.
1393	   However, the QNE Ingress have to report a failure situation upstream.
1394	   When the QNE Ingress transmits the (intra-domain or end-to-end)
1395	   RESERVE with RII object set, it waits for a RESPONSE from the QNE
1396	   Egress for a QOSNSLP_REQUEST_RETRY period.

1398	   If the QNE Ingress transmitted an intra-domain or end-to-end RESERVE
1399	   message with the RII object set and it fails to receive the
1400	   associated intra-domain or end-to-end RESPONSE, respectively, after
1401	   the QOSNSLP_REQUEST_RETRY period expires, it considers that the
1402	   reservation failed. In this case the QNE Ingress SHOULD generate an
1403	   end-to-end RESPONSE message that will include among others an
1404	   INFO-SPEC object. The error code used by this INFO-SPEC is:
1405	      Error severity class: Transient Failure
1406	      Error code value: Reservation failure

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

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

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

1420	   At this point the intra-domain and end-to-end operational states MUST
1421	   be initiated or modified according to the required binding
1422	   procedures.

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

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

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

1436	   In addition to this then the intra-domain and end-to-end RESERVE
1437	   messages are bound using the Message binding procedure described
1438	   in [QoS-NSLP]. In particular the <MSG_ID> object is included
1439	   in the intra-domain RESERVE message and its bound <BOUND_MSG_ID>
1440	   object is carried by the end-to-end RESERVE message. Furthermore, the
1441	   Message_Binding_Type flag is SET (value is 1), such that the message
1442	   dependency is bi-directional.

1444	    If the QOS-NSLP edges maintain aggregated intra-domain QoS-NSLP
1445	   operational states then the value of Binding_Code MUST be set to code
1446	   "Aggregated sessions".
1447	    Furthermore, in this case the retransmission within the RMD domain
1448	    SHOULD NOT be disallowed and the procedures described in Appendix
1449	    A.5 SHOULD be used on QNE Interior nodes. This is necessary due to
1450	    the fact that when retransmissions are disallowed then the
1451	    associated with (micro) flows belonging to the aggregate will loose
1452	    their reservations. Note that in this case the stateful QNE Ingress
1453	    uses the retransmission procedure described in [QoS-NSLP].

1455	   The intra-domain RESERVE message is associated with the (local NTLP)
1456	   SESSION_ID mentioned above. The selection of the IP source and IP
1457	   destination address of this message depends on how the
1458	   different inter-domain (end-to-end) flows are aggregated by the
1459	   QNE Ingress node (see Section 4.3.1). As described in Section 4.3.1,
1460	   the QNE Edges maintain either per flow, or aggregated QoS-NSLP
1461	   reservation states for the RMD QoS model, which are identified by
1462	   (local NTLP) SESSION_IDs (see [GIST]). Note that this NTLP SESSION ID
1463	   is a different one than the SESSION_ID associated with the end-to-end
1464	   RESERVE message.

1466	   If no QOS-NSLP aggregation procedure at the QNE Edges is supported
1467	   then the IP source and IP destination address of this message MUST be
1468	   equal to the IP Source and IP destination addresses of the data flow.
1469	   The intra-domain RESERVE message is sent using the NTLP datagram
1470	   mode (see Sections 4.4, 4.5). Note that the GIST datagram mode can be
1471	   selected using the unreliable GIST API Transfer-Attributes. In
1472	   addition, the intra-domain RESERVE (RMD-QSpec) message MUST include a
1473	   PHR container (PHR_Resource_Request) and the "RMD-QOSM object
1474	   combination".

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

1479	   Note that after completing the initial discovery phase, the GIST
1480	   connection mode can be used between the QNE Ingress and QNE Egress.
1481	   Note that the GIST connection mode can be selected using the reliable
1482	   GIST API Transfer-Attributes.

1484	   The end-to-end RESERVE message is forwarded using the GIST
1485	   forwarding procedure to bypass the Interior stateless or reduced-
1486	   state QNE nodes, see Figure 8.  The bypassing procedure is
1487	   described in Section 4.4. At the QNE Ingress the end-to-end RESERVE
1488	   message is marked, i.e., modifying the QoS-NSLP default NSLP-ID value
1489	   to another NSLP-ID predefined value that will be used by the GIST
1490	   message carrying the end-to-end RESPONSE message to bypass the QNE
1491	   Interior nodes. Note that the QNE Interior nodes, see [GIST], are
1492	   configured to handle only certain NSLP-Ids, see [QoS-NSLP].

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

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

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

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

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

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

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

1523	*  the value of the <PACKET_CLASSIFIER> object is associated with
1524	   the path-coupled routing MRM, since RMD-QOSM is used with the
1525	   path-coupled MRM. The flag that has to be set is
1526	   the flag T (traffic class) meaning that the packet classification
1527	   of packets is based on the DSCP value included in the IP header of
1528	   the packets. Note that the DSCP value used in the MRI can be
1529	   derived by the value of <PHB class> parameter, which MUST be
1530	   carried by the intra-domain RESERVE message. Note that the QNE
1531	   Ingress being a QNI for the intra-domain session it can pass this
1532	   value to GIST, via the GIST API.

1534	*  the PHR resource units MUST be included into the <Bandwidth>
1535	   parameter of the "<QoS Desired> object. When the QNE edges
1536	   use per flow intra-domain QoS-NSLP states, then the value of the
1537	   <Bandwdith> parameter can be obtained by using the method of
1538	   copying the peak rate (p) field included in the <TMOD-1> parameter
1539	      carried by the initial QSpec into this <Bandwidth> parameter,
1540	      which is described above in this subsection. When the QNE edges
1541	      use aggregated intra-domain QoS-NSLP operational states, then the
1542	      value of the <Bandwdith> parameter can be obtained by using the
1543	      bandwidth aggregation method described in Section 4.3.1;

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

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

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

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

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

1563	   * If the initial QSpec carried an <Admission Priority>
1564	     parameter, then this parameter should be copied into the RMD-QSpec
1565	     and carried by the
1566	     (initiating) intra-domain RESERVE. Note that for the RMD-QOSM a
1567	     reservation established without an <Admission Priority> parameter
1568	     is equivalent to a reservation with <Admission Priority> value 1.
1569	     Note that in this case each admission priority is associated with
1570	     a priority traffic class. The three priority traffic classes
1571	     (PHB_low_priority, PHB_normal_priority, PHB_high_priority) may be
1572	     associated with the same PHB, see Section 4.3.3.

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

1577	   Note that the intra-domain RESERVE message does not carry the
1578	   BOUND_SESSION_ID object. The reason of this is that the end-to-end
1579	   RESERVE carries in the BOUND_SESSION_ID object the SESSION_ID value
1580	   of the intra-domain session.

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

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

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

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

1600	   * Error Severity Class: Success
1601	   * Error Code value: Reservation successful

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

1613	4.6.1.1.2 Operation in the Interior nodes

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

1619	  *   the values of the <RSN>, <RII>, <PACKET_CLASSIFIER>,
1620	      <REFRESH_PERIOD>, objects MUST NOT be changed.
1621	      The interior node is informed by the <PACKET_CLASSIFIER> object
1622	      that the packet classification should be done on the DSCP value.
1623	      The flag that has to be set in this case is the flag T (traffic
1624	      class). The value of the DSCP value MUST
1625	      be obtained via the MRI parameters that the QoS-NSLP receives from
1626	      GIST. A QNE Interior MUST be able to associate the value carried
1627	      by the RMD-QSpec <PHB class> parameter and the DSCP value obtained
1628	      via GIST. This is required, because there are situations that the
1629	      <PHB class> parameter is not carrying a DSCP value, but a "PHB ID
1630	      code", see Section 4.1.1.

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

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

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

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

1652	   *  If the RMD domain supports pre-emption during the admission
1653	      control process, then the QNE Interior node can support the
1654	      building blocks specified in the [QoS-NSLP] and during the
1655	      admission control process use the pre-emption handling algorithm
1656	      specified in Appendix 4.

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

1664	4.6.1.1.3 Operation in the Egress node

1666	   When the end-to-end RESERVE message is received by the egress node,
1667	   it is only forwarded further, towards QNR, if the processing of the
1668	   intra-domain RESERVE(RMD-QSpec) message was successful at all nodes
1669	   in the RMD domain. In this case, the QNE Egress MUST stop the marking
1670	   process that was used to bypass the QNE Interior nodes by reassigning
1671	   the QoS-NSLP default NSLP-ID value to the end-to-end RESERVE message,
1672	   see Section 4.4. Furthermore, the carried BOUND_SESSION_ID object
1673	   associated with the intra-domain session MUST be removed after
1674	   processing. Note that the received end to end RESERVE was tunneled
1675	   within the RMD domain. Therefore, the tunnelled initial QSpec
1676	   carried by the end-to-end RESERVE message has to be processed/set
1677	   according to the [QSP-T] specification.

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

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

1689	   If the processing of the intra-domain RESERVE(RMD-QSpec) was not
1690	   successful at all nodes in the RMD domain then the inter-domain (end-
1691	   to-end) reservation is considered as being failed. Furthermore, note
1692	   that when the QNE Egress uses per flow intra-domain QoS-NSLP
1693	   operational states, see Sections 4.3.2 and 4.3.3, the QNE Egress
1694	   should support the message binding procedure described in [QoS-NSLP],
1695	   which can be used to synchronize the arrival of the end to end
1696	   RESERVE and the intra-domain RESERVE (RMD-QSpec) messages, see
1697	   Section 5.7 and QoS-NSLP-RMF API described in [QoS-NSLP]. Note that
1698	   the intra-domain RESERVE message carries the <MSG_ID> object and its
1699	   bound end-to-end RESERVE message carries the <BOUND_MSG_ID> object.
1700	   Both these objects carry the Message_Binding_Type flag set to the
1701	   value of 1. If these two messages do not arrive during the time
1702	   defined by the MsgIDWait timer, then the reservation is considered as
1703	   being failed. Note that the timer has to be pre-configured and it has
1704	   to have the same value in the RMD domain. In this case an end-to-end
1705	   RESPONSE message, see QoS-NSLP-RMF API described in [QoS-NSLP], is
1706	   sent towards the QNE ingress with the following INFO_SPEC values:

1708	   Error Class: Transient Failure
1709	   Error Code: Mismatch synchronization between end-to-end RESERVE
1710	   and intra-domain RESERVE
1711	   When the intra-domain RESERVE(RMD-QSpec) is received by the QNE
1712	   Egress node of the session associated with the intra-domain
1713	   RESERVE(RMD-QSpec) (the PHB session) with the session included in
1714	   its <BOUND_SESSION_ID> object MUST be bound according to the
1715	   specification given in [QoS-NSLP].  The SESSION_ID included
1716	   in the BOUND_SESSION_ID parameter stored in the intra-domain QoS-NSLP
1717	   operational state object is the SESSION_ID of the session associated
1718	   with the end-to-end RESERVE message(s). Note that if the QNE Edge
1719	   nodes maintain per flow intra-domain QoS NSLP operational states then
1720	   the value of Binding_Code = (Tunnel and end-to-end sessions) is used
1721	   If the QNE Edge nodes maintain per aggregated QoS-NSLP intra-domain
1722	   reservation states then the value of Binding_Code = (Aggregated
1723	   sessions), see Sections 4.3.1, 4.3.2.

1725	   If the RMD domain supports pre-emption during the admission control
1726	   process, then the QNE Egress node can support the building
1727	   blocks specified in the [QoS-NSLP] and during the admission
1728	   control process use the example pre-emption handling algorithm
1729	   described in Appendix 4.
1730	   The end-to-end RESERVE message is generated/forwarded further
1731	   upstream according to the [QoS-NSLP] and [QSP-T] specifications.

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

1737	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
1738	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1739	    |                    |                   |                    |
1740	RESERVE                  |                   |                    |
1741	--->|                    |                   |     RESERVE        |
1742	    |------------------------------------------------------------>|
1743	    |RESERVE(RMD-QSpec)  |                   |                    |
1744	    |------------------->|                   |                    |
1745	    |                    |RESERVE(RMD-QSpec) |                    |
1746	    |                    |------------------>|                    |
1747	    |                    |                   | RESERVE(RMD-QSpec) |
1748	    |                    |                   |------------------->|
1749	    |                    |RESPONSE(RMD-QSpec)|                    |
1750	    |<------------------------------------------------------------|
1751	    |                    |                   |                RESERVE
1752	    |                    |                   |                    |-->
1753	    |                    |                   |                RESPONSE
1754	    |                    |                   |                    |<--
1755	    |                    |RESPONSE           |                    |
1756	    |<------------------------------------------------------------|
1757	RESPONSE                 |                   |                    |
1758	<---|                    |                   |                    |

1760	Figure 8: Basic operation of successful reservation procedure used by
1761	          the RMD-QOSM

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

1771	   *  the RII object carried by the intra-domain RESERVE message, see
1772	      Section 4.6.1.1.1, has to be copied and carried by the
1773	      intra-domain RESPONSE message.

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

1778	   *  the value of the <M> field of the PDR container MUST be equal to
1779	      the value of the <M> parameter of the PHR container that was
1780	      carried by its associated intra-domain RESERVE(RMD-QSpec)
1781	      message. This is required since the value of the <M> parameter is
1782	      used to indicate the status if the RMD reservation request to the
1783	      Ingress edge.

1785	   If the binding between the intra-domain session and the end-to-end
1786	   session uses a Binding_Code is (Aggregated sessions), and there is no
1787	   aggregated QoS-NSLP operational state associated with the intra-
1788	   domain session available, then the RMD
1789	   modification of aggregated reservation procedure described in Section
1790	   4.6.1.4. can be used.

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

1798	   * the values of the <RII/RSN>, <INFO_SPEC>, [ QSPEC ] objects are
1799	     set according to [QoS-NSLP] and/or [QSP-T]. The INFO_SPEC object
1800	     SHOULD be set by the QoS-NSLP functionality. In case of successful
1801	     reservation the INFO_SPEC object SHOULD have the following values:
1802	     Error Severity Class: Success,
1803	     Error Code value: Reservation successful,

1805	   * Furthermore, an initial QSpec object MUST be included in the
1806	     end-to-end RESPONSE message. The parameters included in the QSPEC
1807	    <QoS Reserved> object are copied from the original <QoS Desired>
1808	     values.

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

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

1820	4.6.1.2.  Unsuccessful reservation

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

1825	   The QNE Ingress, the QNE Interior and QNE Egress nodes process and
1826	   forward the end-to-end RESERVE message and the intra-domain
1827	   RESERVE(RMD-QSpec) message in a similar way as specified in Section
1828	   4.6.1.1.  The main difference between the unsuccessful operation and
1829	   successful operation is that one of the QNE nodes does not admit the
1830	   request due to lack of resources.  This also means that the QNE edge
1831	   node MUST NOT forward the end-to-end RESERVE message towards the
1832	   QNR node.

1834	   Note that the described functionality applies to the RMD reservation-
1835	   based methods, see Sections 4.3.1, 4.3.2, and to the NSIS
1836	   measurement-based admission control method, see Section 4.3.2.
1837	   The QNE Edge nodes maintain either per flow QoS-NSLP reservation
1838	   states or aggregated QoS-NSLP reservation states. When the QNE edges
1839	   maintain aggregated QoS-NSLP reservation states, the RMD-QOSM
1840	   functionality may accomplish a RMD modification procedure (see
1841	   Section 4.6.1.4.), instead of the reservation initiation procedure
1842	   that is described in this subsection.

1844	4.6.1.2.1 Operation in the Ingress nodes

1846	   When an end-to-end RESERVE message arrives at the QNE Ingress and
1847	   if there are no resources available, the QNE Ingress MUST
1848	   reject this end-to-end RESERVE message and send an end-to-end
1849	   RESPONSE message back to the sender, as described in the QoS-NSLP
1850	   specification, see [QoS-NSLP] and [QSP-T].

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

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

1862	   When an intra-domain RESPONSE message is received by the QNE Ingress
1863	   node, which was sent by a QNE Egress, see Section 4.6.1.2.3, it uses
1864	   the QoS-NSLP procedures to match it to the earlier sent intra-domain
1865	   RESERVE message. After this phase, the RMD-QSpec has to be identified
1866	   and processed. Note that in this case the RMD Resource Management
1867	   Function (RMF) is notified that the reservation has been
1868	   unsuccessful, by reading the <M> parameter of the PDR container.
1869	   Note that when the QNE edges maintain a per flow QoS-NSLP reservation
1870	   state the RMD-QOSM functionality, has to start an RMD release
1871	   procedure (see Section 4.6.1.5). When the QNE edges maintain
1872	   aggregated QoS-NSLP reservation states the RMD-QOSM functionality MAY
1873	   start a RMD modification procedures (see Section 4.6.1.4.).

1875	4.6.1.2.2 Operation in the Interior nodes

1877	   In case of the RMD reservation based scenario, and if the
1878	   intra-domain reservation request is not admitted by the QNE Interior
1879	   node then the <Hop_U> and <M> parameters of the PHR container MUST be
1880	   set to "1".  The <Admitted Hops> counter MUST NOT be increased.
1881	   Moreover, the value of the <Max Admitted Hops> MUST be set equal to
1882	   the <Admitted Hops> value.
1883	   Furthermore, the "E" flag associated with the QSpec <QoS Desired>
1884	   object and the "E" flag associated with the <Bandwidth> parameter
1885	   SHOULD be set. In case of the RMD measurement based scenario, the
1886	   <M> parameter of the PHR container MUST be set to "1". Furthermore,
1887	   the "E" flag associated with the QSpec <QoS Desired> object and the
1888	   "E" flag associated with the <Bandwidth> parameter SHOULD be set.
1889	   Note that the <M> flag seems to be set in a similar way as the "E"
1890	   flag used by the <Bandwidth> parameter. However, the ways of how the
1891	   two flags are processed by a QNE are different.

1893	   In general, if a QNE Interior node receives a QSpec <Bandwidth>
1894	   parameter with the "E" flag set and a PHR container type
1895	   "PHR_Resource_Request", with the <M> parameter set to "1" , then this
1896	   "PHR Container" and the "RMD-QoSM object combination" (i.e., RMD-QOSM
1897	   <QoS Desired> object) MUST NOT be processed. Furthermore, when the
1898	   <K> parameter that is included in the "PHR Container" and carried by
1899	   a RESERVE message is set to "1", then this "PHR Container" and the
1900	   "RMD QoS Description" (i.e., RMD-QOSM <QoS Desired> object) MUST NOT
1901	   be processed.

1903	4.6.1.2.3 Operation in the Egress nodes

1905	   In the RMD reservation based, see Sections 4.3.3, and the RMD NSIS
1906	   measurement based scenario, see Section 4.3.2, when the <M> marked
1907	   intra-domain RESERVE(RMD-QSpec) is received by the QNE Egress node
1908	   (see Figure 9) the session associated with the intra-domain
1909	   RESERVE(RMD-QSpec) (the PHB session) and the end-to-end session MUST
1910	   be bound.

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

1918	   *  the values of the <RII/RSN>, <INFO_SPEC> objects are set
1919	      by the standard QoS-NSLP protocol functions. In case of the
1920	      unsuccessful reservation the INFO_SPEC object SHOULD have the
1921	      following values:
1922	      Error Severity Class: Transient Failure
1923	      Error Code value: Reservation failure

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

1928	   In particular, the parameters included in the QSpec <QoS Reserved>
1929	   object of the end-to-end RESPONSE message are copied
1930	   from the initial <QoS Desired> values included in its associated
1931	   end-to-end RESERVE message. The "E" flag associated with
1932	   the QSpec <QoS Reserved> object and the "E" flag associated with the
1933	   <TMOD-1> parameter included in the end-to-end RESPONSE are set.

1935	QNE (Ingress)    QNE (Interior)       QNE (Interior)      QNE (Egress)
1936	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1937	    |                    |                   |                    |
1938	RESERVE                  |                   |                    |
1939	--->|                    |                   |     RESERVE        |
1940	    |------------------------------------------------------------>|
1941	    |RESERVE(RMD-QSpec:M=0)                  |                    |
1942	    |------------------->|                   |                    |
1943	    |                    |RESERVE(RMD-QSpec:M =1)                 |
1944	    |                    |------------------>|                    |
1945	    |                    |                   | RESERVE(RMD-QSpec:M=1)
1946	    |                    |                   |------------------->|
1947	    |                    |RESPONSE(RMD-QOSM) |                    |
1948	    |<------------------------------------------------------------|
1949	    |                    |RESPONSE           |                    |
1950	    |<------------------------------------------------------------|
1951	RESPONSE                 |                   |                    |
1952	<---|                    |                   |                    |
1953	RESERVE(RMD-QSpec: Tear=1, M=1, <Admitted Hops>=<Max Admitted Hops>
1954	    |------------------->|                   |                    |
1955	                         |RESERVE(RMD-QSpec: Tear=1, M=1, K=1)    |
1956	    |                    |------------------>|                    |
1957	                         |    RESERVE(RMD-QSpec: Tear=1, M=1, K=1)|
1958	    |                    |                   |------------------->|

1960	Figure 9: Basic operation during unsuccessful reservation
1961	          initiation used by the RMD-QOSM

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

1971	      Error Severity Class: Transient Failure
1972	      Error Code value: Reservation failure

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

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

1980	   *  the value of the <Max Admitted Hops> parameter of the PHR
1981	       container included in the received <M> marked intra-domain
1982	      RESERVE (RMD-QSpec)  MUST be included
1983	      in the <Max Admitted Hops> parameter of the PDR container;

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

1987	4.6.1.3 RMD refresh reservation

1989	   In case of RMD measurement-based method, see Section 4.3.2, QoS-NSLP
1990	   reservation states in the RMD domain are typically not maintained,
1991	   therefore, this method typically does not use an intra-domain refresh
1992	   procedure. However, there are measurement based optimization schemes,
1993	   see [GrTs03], which may use the refresh procedures described in
1994	   Sections 4.6.1.3.1, and 4.6.1.3.3. However, this measurement based
1995	   optimization schemes can only be applied in the RMD domain if the QNE
1996	   edges are configured to perform intra-domain refresh procedures and
1997	   if all the QNE interior nodes are configured to perform the
1998	   measurement based optimization schemes. In the description given in
1999	   this subsection it is assumed that the RMD measurement based scheme
2000	   does not use the refresh procedures.

2002	   When the QNE edges maintain aggregated or per flow QoS-NSLP
2003	   operational and reservation states, see Sections 4.3.1 and 4.3.3,
2004	   then the refresh procedures are very similar. If the RESERVE messages
2005	   arrive within the soft state time-out period, the corresponding
2006	   number of resource units are not removed. However, the transmission
2007	   of the intra-domain and end-to-end (refresh) RESERVE message are not
2008	   necessarily synchronized. Furthermore, the generation of the end-to-
2009	   end RESERVE message, by the QNE edges, depends on the locally
2010	   maintained refreshed interval (see [QoS-NSLP]).

2012	4.6.1.3.1 Operation in the Ingress node

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

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

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

2030	QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)
2031	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
2032	    |                    |                   |                    |
2033	    |RESERVE(RMD-QSpec)  |                   |                    |
2034	    |------------------->|                   |                    |
2035	    |                    |RESERVE(RMD-QSpec) |                    |
2036	    |                    |------------------>|                    |
2037	    |                    |                   | RESERVE(RMD-QSpec) |
2038	    |                    |                   |------------------->|
2039	    |                    |                   |                    |
2040	    |                    |RESPONSE(RMD-QSpec)|                    |
2041	    |<------------------------------------------------------------|
2042	    |                    |                   |                    |

2044	   Figure 10: Basic operation of RMD specific refresh procedure

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

2051	  *  the PHR resource units MUST be included into the <Bandwidth>
2052	     parameter. The value of the <Bandwidth> parameter depends on
2053	     how the different inter domain (end-to-end) flows are aggregated
2054	     by the QNE Ingress node (e.g., the sum of all the PHR requested
2055	     resources of the aggregated flows), see Section 4.3.1.  If no
2056	     QOS-NSLP aggregation is accomplished by the QNE Ingress node, the
2057	     value of the <Bandwidth> parameter SHOULD be equal to the
2058	     <Bandwidth> parameter of its associated new (initial) intra-domain
2059	     RESERVE (RMD-QSpec) message, see Section 4.3.3. ;

2061	   *  the value of the Parameter/Container field of the "PHR Container"
2062	       MUST be set to "PHR_2",
2063	      i.e., "PHR_Refresh_Update";

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

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

2072	   *  the "PDR Container" has to be processed by the RMD-QOSM
2073	      functionality in the QNE Ingress node.  The RMD-QOSM functionality
2074	      is notified by the <PDR M> parameter of the PDR container
2075	      that the refresh procedure has been successful or unsuccessful.
2076	      All session(s) (when aggregated QoS-NSLP operational and
2077	      reservation states are used, see Section 4.3.1, there
2078	      will be more than one sessions) associated with this RMD specific
2079	      refresh session MUST be informed about the success or failure of
2080	      the refresh procedure.  In case of failure, the QNE Ingress node
2081	      has to generate (in a standard QoS-NSLP way) an error end-to-end
2082	      RESPONSE message that will be sent towards QNI.

2084	4.6.1.3.2 Operation in the Interior node

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

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

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

2106	   * Furthermore, the "E" flag associated with <QoS Desired> object and
2107	     the "E" flag associated with the <Bandwidth> parameter SHOULD be
2108	     set.

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

2116	4.6.1.3.3 Operation in the Egress node

2118	   The intra-domain RESERVE(RMD-QSpec) message is received and
2119	   processed by the QNE Egress node.  A new intra-domain RESPONSE
2120	   (RMD-QSpec) message is generated by the QNE Egress node and MUST
2121	   include a PDR (type PDR_Refresh_Report).

2123	   The (refresh) intra-domain RESPONSE (RMD-QSpec) message MUST be sent
2124	   to the QNE Ingress node, i.e., the previous stateful hop. The
2125	   (refresh) intra-domain RESPONSE (RMD-QSpec) message MUST be
2126	   explicitly routed to the QNE Ingress node, i.e., the previous
2127	   stateful hop, using the procedures described in Section 4.5.

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

2132	   * The value of the <PDR Control Type> parameter of the PDR container
2133	     MUST be set "PDR_8" (i.e. PDR_Refresh_Report).
2134	     In case of successful reservation the INFO_SPEC object SHOULD
2135	     have the following values:
2136	     Error Severity Class: Success
2137	     Error Code value: Reservation successful

2139	   * In case of unsuccessful reservation the INFO_SPEC object SHOULD
2140	     have the following values:
2141	     Error Severity Class: Transient Failure
2142	     Error Code value: Reservation failure

2144	   The RMD-QSpec that was carried by the intra-domain RESERVE
2145	   belonging to the same session as this intra-domain RESPONSE is
2146	   included in the intra-domain RESPONSE message. The parameters
2147	   included in the QSPec <QoS Reserved> object are copied from the
2148	   original <QoS Desired> values. If the reservation is unsuccessful
2149	   then "E" flag associated with the QSpec <QoS Reserved> object and the
2150	   "E" flag associated with the <Bandwidth> parameter are set.
2151	    Furthermore, the <M> and <S> PDR Container bits are set to "1".

2153	4.6.1.4.  RMD modification of aggregated reservations

2155	   In the case when the QNE edges maintain QoS-NSLP aggregated
2156	   operational and reservation states and the aggregated reservation has
2157	   to be modified (see Section 4.3.1) the following procedure is
2158	   applied:

2160	   * When the modification request requires an increase of the reserved
2161	     resources, the QNE Ingress node MUST include the corresponding
2162	     value into the <Bandwidth> parameter of the "RMD-QOSM object
2163	     combination", (i.e., the RMD-QOSM <QoS Desired>)
2164	     which is sent together with a "PHR_Resource_Request" control
2165	     information.  If a QNE edge or QNE Interior node is not able to
2166	     reserve the number of requested resources, the
2167	     "PHR_Resource_Request" that is associated with
2168	     the <Bandwidth> parameter MUST be <M> marked, i.e., the <M> bit is
2169	     set to the value of "1".  In this situation the
2170	     RMD specific operation for unsuccessful reservation will be applied
2171	     (see Section 4.6.1.2).

2173	   * When the modification request requires a decrease of the
2174	     reserved resources, the QNE Ingress node MUST include this value
2175	     into the <Bandwidth> parameter of the "RMD-QOSM object combination"
2176	     (i.e., the RMD-QOSM <QoS Desired>). Subsequently an RMD release
2177	     procedure SHOULD be accomplished (see Section 4.6.1.5). Note that
2178	     if the complete bandwidth associated with the aggregated
2179	     reservation maintained at the QNE ingress does not have to be
2180	     released then the TEAR flag MUST be set to OFF. This is because the
2181	     NSLP operational states associated with the aggregated reservation
2182	     states at the edge QNEs must not be turned off. However, if the
2183	     complete bandwidth associated with the aggregated reservation
2184	     maintained at the QNE ingress has to be released, then the TEAR
2185	     flag MUST be set to ON.

2187	4.6.1.5  RMD release procedure

2189	   This procedure is applied to all RMD mechanisms that maintain
2190	   reservation states. If a refresh RESERVE message does not arrive at a
2191	   QNE Interior node within the refresh time-out period then the
2192	   bandwidth requested by this refresh RESERVE message is not updated.
2193	   This will mean that the reserved bandwidth associated with the
2194	   reduced state is decreased in the next refresh period by the amount
2195	   of the corresponding bandwidth that has not been refreshed, see
2196	   section 4.3.3. This soft state
2197	   behavior provides certain robustness for the system ensuring that
2198	   unused resources are not reserved for long time.  Resources can be
2199	   removed by an explicit release at any time. However, in the situation
2200	   that an end-to-end (tear) RESERVE is retransmitted, see Section 5.2.4
2201	   in [QoS-NSLP], then this message MUST NOT initiate an intra-domain
2202	   (tear) RESERVE message. This is because the amount bandwidth within
2203	    the RMD domain associated with the (tear) end-to-end RESERVE has
2204	    already been released and therefore, this amount of bandwidth within
2205	    the RMD domain MUST NOT once again be released.

2207	   When the RMD-RMF of a QNE edge or QNE Interior node processes a
2208	   "PHR_Release_Request"  PHR container it MUST identify the
2209	   <PHB Class> parameter and estimate the time period that elapsed
2210	   after the previous refresh, see also Section 3 of [CsTa05]. This MAY
2211	   be done by indicating the time lag, say "T_lag", between the last
2212	   sent "PHR_Refresh_Update" and the "PHR_Release_Request" control
2213	   information container by the QNE Ingress node, see [RMD1] and
2214	   [CsTa05] for more details.  The value of "T_Lag"
2215	   is first normalized to the length of the refresh period, say
2216	   "T_period".  The ratio between the "T_Lag" and the length of the
2217	   refresh period, "T_period", is calculated.  This ratio is then
2218	   introduced into the <Time Lag> field of the "PHR_Release_Request".

2220	   When a node (QNE Egress or QNE Interior) receives the
2221	   "PHR_Release_Request" PHR container, it MUST store the arrival
2222	   time.  Then it MUST calculate the time difference, "Tdiff", between
2223	   the arrival time and the start of the current refresh period,
2224	   "T_period".  Furthermore, this node MUST derive the value of the
2225	   "T_Lag", from the <Time Lag> parameter. "T_Lag" can be found by
2226	   multiplying the value included in the <Time Lag> parameter with the
2227	   length of the refresh period, "T_period". If the derived time lag,
2228	   "T_lag", is smaller than the calculated time difference, "T_diff",
2229	   then this node MUST decrease the PHB reservation state with the
2230	   number of resource units indicated in the <Bandwidth> parameter of
2231	   the "RMD-QOSM object combination" (i.e., the RMD-QOSM <QoS Desired>)
2232	   that has been sent together with the "PHR_Release_Request" "PHR
2233	   Container", but not below zero.

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

2242	4.6.1.5.1.  Triggered by a RESERVE message

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

2251	   Same as for the scenario described in Section 4.6.1.1., a bypassing
2252	   procedure has to be initiated by the QNE Ingress node. The bypassing
2253	   procedure is performed according to the description given in Section
2254	   4.4. At the QNE Ingress the end-to-end RESERVE message is marked,
2255	   i.e., modifying the QoS-NSLP default NSLP-ID value to another NSLP-ID
2256	   predefined value that will be used by the GIST message that carries
2257	   the end-to-end RESERVE message to bypass the QNE Interior nodes.

2259	   Before generating an intra-domain tear RESERVE, the RMD-QOSM has to
2260	   release the requested RMD-QOSM bandwidth from the RMD traffic class
2261	   state maintained at the QNE Ingress. This can be achieved by
2262	   identifying the traffic class (PHB) and then subtracting the amount
2263	   of RMD traffic class requested resources, included in the <Bandwidth>
2264	   parameter, from the total reserved amount of resources stored in the
2265	   RMD traffic class state. The <Time Lag> is used as explained in the
2266	   introductory part of Section 4.6.1.5.

2268	QNE (Ingress)     QNE (Interior)       QNE (Interior)    QNE (Egress)
2269	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
2270	    |                    |                   |                    |
2271	RESERVE                  |                   |                    |
2272	--->|                    |                   |     RESERVE        |
2273	    |------------------------------------------------------------>|
2274	    |RESERVE(RMD-QSpec:Tear=1)               |                    |
2275	    |------------------->|                   |                    |
2276	    |                    |RESERVE(RMD-QSpec:Tear=1)               |
2277	    |                    |------------------->|                   |
2278	    |                    |                 RESERVE(RMD-QSpec:Tear=1)
2279	    |                    |                   |------------------->|
2280	    |                    |                   |                RESERVE
2281	    |                    |                   |                    |-->

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

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

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

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

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

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

2310	   *  the value of the <Admitted Hops> parameter MUST be set to "1";
2311	   *  the value of the <Time Lag> parameter of the PHR container is
2312	      calculated by the RMD-QOSM functionality (see 4.6.1.5) the value
2313	      of the <Control Type> parameter of PHR container is set to "PHR_3"
2314	      (i.e., PHR_Resource_Release).

2316	   Any QNE Interior node that receives the combination of the RMD-
2317	   QOSM <Qos Desired> object and the "PHR_Resource_Release" control
2318	   information container  MUST identify the traffic class (PHB)
2319	   and release the requested resources included in the <Bandwidth>
2320	   parameter.  This can be achieved by subtracting the amount of RMD
2321	   traffic class requested resources, included in the <Bandwidth>
2322	   parameter, from the total reserved amount of resources stored in the
2323	   RMD traffic class state.  The value of the <Time Lag> parameter of
2324	   the "PHR_Resource_Release" container is used during the release
2325	   procedure as explained in the introductory part of Section 4.6.1.5.

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

2333	   The value of the <Bandwidth> parameter of the "RMD-QOSM object
2334	   combination" (i.e., the RMD-QOSM <QoS Desired>)
2335	   and the value of the <Time Lag> field of the PHR container MUST
2336	   be used by the RMD release procedure.  This can be achieved by
2337	   subtracting the amount of RMD traffic class requested resources,
2338	   included in the <Bandwidth> parameter, from the total reserved amount
2339	   of resources stored in the RMD traffic class state.

2341	   The end-to-end RESERVE message is forwarded by the next hop (i.e.,
2342	   the QNE Egress) only if the intra-domain tear RESERVE (RMD-QSpec)
2343	   message arrives at the QNE Egress node. Furthermore, the QNE Egress
2344	   MUST stop the marking process that was used to bypass the QNE
2345	   Interior nodes by reassigning the QoS-NSLP default NSLP-ID value to
2346	   the end-to-end RESERVE message, see Section 4.4.
2347	   Note that when the QNE edges maintain aggregated QoS-NSLP reservation
2348	   states the RMD-QOSM functionality may start a RMD modification
2349	   procedures (see Section 4.6.1.4.) that uses the explicit release
2350	   procedure described above, in this subsection. Note that
2351	   if the complete bandwidth associated with the aggregated reservation
2352	   maintained at the QNE ingress has to be released then the
2353	   TEAR flag MUST be set to ON. Otherwise, the TEAR
2354	   flag MUST be set to OFF, see Section 4.6.1.4.

2356	4.6.1.5.2   Triggered by a marked RESPONSE or NOTIFY message

2358	   This RMD explicit release procedure can be triggered by either an
2359	   intra-domain RESPONSE message with a PDR container carrying among
2360	   others the <M> and <S> parameters with values <M>=1 and <S>=0 (see
2361	   Section 4.6.1.2) an intra-domain (refresh) RESPONSE message carrying
2362	   a PDR Container with <M>=1 and <S>=1  (see Section 4.6.1.6.1) or an
2363	   end to end NOTIFY message (see Section 4.6.1.6.) with an INFO_SPEC
2364	   object with the following values:

2366	   Error Severity Class: Informational
2367	   Error Code value: Congestion situation

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

2376	   Note that in all explicit release procedures, before generating an
2377	   intra-domain tear RESERVE, the RMD-QOSM has to release the requested
2378	   RMD-QOSM bandwidth from the RMD traffic class state maintained at the
2379	   QNE Ingress. This can be achieved by identifying the traffic class
2380	   (PHB) and then subtracting the amount of RMD traffic class requested
2381	   resources, included in the <Bandwidth> parameter, from the total
2382	   reserved amount of resources stored in the RMD traffic class state.

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

2391	   Error Severity Class: Informational
2392	   Error Code value: Congestion situation

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

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

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

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

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

2410	QNE (Ingress)     QNE (Interior)         QNE (Interior)    QNE (Egress)
2411	NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
2412	    |                  |                  |                  |
2413	    | NOTIFY           |                  |                  |
2414	    |<-------------------------------------------------------|
2415	    |RESERVE(RMD-QSpec:Tear=1,M=1,S=1)    |                  |
2416	    | ---------------->|RESERVE(RMD-QSpec:Tear=1, M=1,S=1)   |
2417	    |                  |                  |                  |
2418	    |                  |----------------->|                  |
2419	    |                  |           RESERVE(RMD-QSpec:Tear=1, M=1,S=1)
2420	    |                  |                  |----------------->|

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

2425	   Note that if the values of the <M> and <S> parameters included in the
2426	   PHR container carried by a intra-domain tear RESERVE(RMD-QOSM) are
2427	   set as ((<M>=0 and <S>=1) or (<M>=0 and <S>=0) or (<M>=1 and <S>=1))
2428	   then the <Max Admitted Hops> value SHOULD not be compared to the
2429	   <Admitted Hops> value and the value of the <K> field MUST NOT be set.
2430	   Any QNE edge or QNE Interior node that receives the intra-domain tear
2431	   RESERVE it MUST check the <K> field included in the PHR Container. If
2432	   the <K> fied is "0" then the traffic class state (PHB) has to be
2433	   identified, using the <PHB Class> parameter, and the the requested
2434	   resources included in the <Bandwidth> field have to be released.
2435	   This can be achieved by subtracting the amount of RMD traffic class
2436	   requested resources, included in the <Bandwidth> field, from the
2437	   total reserved amount of resources stored in the RMD traffic class
2438	   state.  The value of the <Time Lag> parameter of the PHR field
2439	   is used during the release procedure as explained in the introductory
2440	   part of Section 4.6.1.5. Afterwards, the QNE Egress node MUST
2441	   terminate the tear intra-domain RESERVE(RMD-QSpec) message.

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

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

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

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

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

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

2476	   *  The RESERVE message MAY include a PDR container.

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

2484	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
2485	                                     Node that marked
2486	                                    PHR_Resource_Request
2487	                                       <PHR> object
2488	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
2489	    |                    |                   |                    |
2490	    |                    |                   |                    |
2491	    | RESPONSE (RMD-QSpec: M=1)              |                    |
2492	    |<------------------------------------------------------------|
2493	RESERVE(RMD-QSpec: Tear=1, M=1, <Admit Hops>=<Max Admitted Hops>, K=0)
2494	    |------------------->|                   |                    |
2495	    |                    |RESERVE(RMD-QSpec: Tear=1, M=1, K=1)    |
2496	    |                    |------------------>|                    |
2497	    |                    |    RESERVE(RMD-QSpec: Tear=1, M=1, K=1)|
2498	    |                    |                   |------------------->|
2499	    |                    |                   |                    |

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

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

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

2513	   If the <K> field value is "0", any QNE edge or QNE Interior node that
2514	   receives the intra-domain tear RESERVE can release the resources by
2515	   subtracting the amount of RMD traffic class requested resources,
2516	   included in the <Bandwidth> field, from the total reserved amount of
2517	   resources stored in the RMD traffic class state.  The value of the
2518	   <Time Lag> parameter of the PHR field is used during the release
2519	   procedure as explained in the introductory part of Section 4.6.1.5.
2520	   Furthermore, the QNE MUST perform the following procedures.
2521	   If the values of the <M> and <S> parameters included in the
2522	    "PHR_Resource_Release" PHR container are (<M=1> and <S>=0) then the
2523	   <Max Admitted Hops> value MUST be compared with the calculated
2524	   <Admitted Hops> value.  Note that each time that the intra-domain
2525	   tear RESERVE is processed and before being forwarded by a QNE, the
2526	   <Admitted Hops> value included in the PHR container is increased by
2527	   one.

2529	   When these two values are equal then the intra-domain
2530	   RESERVE(RMD-QSpec) that is forwarded further towards the QNE Egress
2531	   MUST set the <K> value of the carried "PHR Container" to "1".
2532	   The reason of doing this is that the QNE node that is currently
2533	   processing this message was the last QNE node that successfully
2534	   processed the "RMD-QOSM object combination" (i.e., the RMD-QOSM <QoS
2535	   Desired>) and PHR container of its associated initial reservation
2536	   request (i.e., initial intra-domain RESERVE(RMD-QSpec) message). Its
2537	   next QNE downstream node was unable to successfully process the
2538	   initial reservation request, therefore, this QNE node marked the <M>
2539	   and <Hop_U> parameters of the "PHR_Resource_Request".

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

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

2548	   When the QNE edges maintain aggregated intra-domain QoS-NSLP
2549	   operational states and a severe congestion occurs, then the QNE
2550	   Ingress may receive an end to end NOTIFY message (see Section
2551	   4.6.1.6.) with a PDR container that carries the  <M>=0 and <S>=1
2552	   fields and a bandwidth value in the <PDR Bandwidth> parameter
2553	   included in a "PDR_Congestion_Report" container. Furthermore the
2554	   same end-to-end NOTIFY message carries an INFO_SPEC object with the
2555	   following values:

2557	   Error Severity Class: Informational
2558	   Error Code value: Congestion situation
2559	   The end-to-end session associated with this NOTIFY message maintains
2560	   the BOUND_SESSION_ID of the bound aggregated session, see Sections
2561	   4.3.1. The RMD-QOSM at QNE Ingress MUST start a RMD modification
2562	   procedures (see Section 4.6.1.4) that uses the RMD explicit release
2563	   procedure described above in this section. In particular, the RMD
2564	   explicit release procedure releases the bandwidth value included in
2565	   the <PDR Bandwidth> parameter, within the "PDR_Congestion_Report"
2566	   container, from the reserved bandwidth associated with the aggregated
2567	   intra-domain QoS-NSLP operational state.

2569	4.6.1.6. Severe congestion handling

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

2574	   When a failure in a communication path, e.g., a router or a link
2575	   failure occurs, the routing algorithms will adapt to failures by
2576	   changing the routing decisions to reflect changes in the topology and
2577	   traffic volume.  As a result, the re-routed traffic will follow a new
2578	   path, which may result in overloaded nodes as they need to support
2579	   more traffic.  This may cause severe congestion in the communication
2580	   path.  In this situation the available resources, are not enough to
2581	   meet the required QoS for all the flows along the new path.
2582	   Therefore, one or more flows SHOULD be terminated, or forwarded in a
2583	   lower priority queue.

2585	   Interior nodes notify edge nodes by data marking or marking the
2586	   refresh messages.

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

2590	   This procedure applies to all RMD scenarios that use a RMD refresh
2591	   procedure. The QoS-NSLP and RMD are able to cope with congested
2592	   situations using the refresh procedure, see Section 4.6.1.3. If the
2593	   refresh is not successful in an QNE Interior node, edge nodes are
2594	   notified by setting <S>=1 (<M>=1) marking the refresh messages and by
2595	   including the percentage of overload into the <Overload %> field in
2596	   the "PHR_Refresh_Update" container, carried by the intra-domain
2597	   RESERVE message. The intra-domain RESPONSE message that is sent by
2598	   the QNE Egress towards QNE Ingress will contain a PDR container with
2599	   a Parameter/Container ID = PDR_10, i.e., "PDR_Congestion_Report". The
2600	   values of the <M>, <S> and <Overload %> fields of this container
2601	   should be set equal to the values of the <M>, <S> and <Overload %>
2602	   fields, respectively, carried by the "PHR_Refresh_Update" container.
2603	   Part of the flows, corresponding to the <Overload %>, are terminated,
2604	   or forwarded in a lower priority queue. Note that an example of how
2605	   this value can be calculated is given in appendix A.1.1 and denoted
2606	   as the signaled_overload_rate parameter. The flows can be terminated
2607	   by the RMD release procedure described in Section 4.6.1.5.  Note that
2608	   the above described functionality applies to the RMD reservation-
2609	   based and to the NSIS measurement-based admission control schemes.
2610	   Furthermore, note that the above functionalities apply also for the
2611	   scenario where the QNE Edge nodes maintain either per flow QoS-NSLP
2612	   reservation states or aggregated QoS-NSLP reservation states.

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

2619	4.6.1.6.2 Severe congestion handling by proportional data packet marking

2621	   This severe congestion handling method requires the following
2622	   functionalities.

2624	4.6.1.6.2.1 Operation in the Interior nodes

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

2632	   The Interior node detecting severe congestion remarks data packets
2633	   passing the node. For this remarking, two additional DSCPs can be
2634	   allocated for each traffic class.  One DSCP MAY be used to indicate
2635	   that the packet passed a congested node. This type of DSCP is denoted
2636	   in this document as "affected DSCP" and is used to indicate that a
2637	   packet passed through a severe congested node. The use of this DSCP
2638	   type eliminates the possibility that, due to e.g. ECMP (Equal Cost
2639	   Multiple Paths) enabled routing, the egress node either does not
2640	   detect packets passed a severe congested node or erroneously detects
2641	   packets that actually did not pass the severe congested node.  Note
2642	   that this type of DSCP MUST only be used if all the nodes within the
2643	   RMD domain are configured to use it. Otherwise, this type of DSCP
2644	   MUST NOT be applied. The other DSCP MUST be used to indicate the
2645	   degree of congestion by marking the bytes proportionally to the
2646	   degree of congestion. This type of DSCP is denoted in this document
2647	   as "encoded DSCP".

2649	   Note that in this document the terms marked packets or marked bytes
2650	   refer to the "encoded DSCP". The terms unmarked packets or unmarked
2651	   bytes are representing the packets or the bytes belonging to these
2652	   packets that their DSCP is either the "affected DSCP" or the original
2653	   DSCP. Furthermore, in the algorithm described below it is considered
2654	   that the router may drop received packets. The counting/measuring of
2655	   marked or unmarked bytes described in this section is accomplished
2656	   within measurement periods. All nodes within a RMD domain use the
2657	   same, fixed measurement interval, say T seconds, which MUST be
2658	   pre-configured.

2660	   It is RECOMMENDED that the total number of additional (local and
2661	   experimental) DSCPs needed for severe congestion handling within an
2662	   RMD domain should be as low as possible and it should not exceed the
2663	   limit of 8. One possibility to reduce the number of used DSCPs is to
2664	   use only the "encoded DSCP" and not to use "affected DSCP" marking.
2665	   Another possible solution is for example, to allocate one DSCP for
2666	   severe congestion indication for each of the AF classes that can be
2667	   supported by RMD-QOSM.

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

2671	4.6.1.6.2.2 Operation in the Egress nodes

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

2680	   When the RMD domain does not use the "affected DSCP"
2681	   marking then the egress MUST generate an ingress/egress pair
2682	   aggregated state, for each ingress and for each supported PHB. This
2683	   is because the edges must be able to detect in which ingress/egress
2684	   pair a severe congestion occurs. This is because otherwise the QNE
2685	   Egress will not have any information on which flows or groups of
2686	   flows were affected by the severe congestion. When the RMD domain
2687	   supports the "affected DSCP" marking then the egress is able to
2688	   detect all flows that are affected by the severe congestion
2689	   situation. Therefore, when the RMD domain supports the "affected
2690	   DSCP" marking, then the Egress MAY not generate and maintain the
2691	   ingress/egress pair aggregated reservation States. Note that these
2692	   aggregated reservation states may not be associated with aggregated
2693	   intra-domain QoS-NSLP operational states.

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

2699	   Some flows, belonging to the same PHB traffic class might get
2700	   other priority than other flows belonging to the same PHB traffic
2701	   class. This difference in priority can be notified to the egress and
2702	   ingress nodes either by the RESERVE message that carries the QSpec
2703	   associated with the end-to-end QoS model, e.g.,, <Preemption
2704	   Priority> & <Defending Priority> parameter, or by using a local
2705	   defined policy. The priority value is kept in the reservation states,
2706	   see Section 4.3, which might be used during admission control and/or
2707	   severe congestion handling procedures. The terminated flows are
2708	   selected from the flows having the same PHB traffic class as the PHB
2709	   of the marked (as "encoded DSCP") and "affected DSCP" (when applied
2710	   in the complete RMD domain) packets and (when the ingress/egress pair
2711	   aggregated states are available) that are belonging to the same
2712	   ingress/egress pair aggregate.

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

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

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

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

2731	   * the INFO_SPEC object MUST include information that notifies that
2732	     the end-to-end flow MUST be terminated. This information is as
2733	     follows:

2735	     Error Severity Class: Informational
2736	     Error Code value: Congestion situation

2738	   When the QNE edges maintain a per aggregate intra-domain QoS-NSLP
2739	   operational state, see sections 4.3.1 then the QNE Edge has to
2740	   calculate, per each aggregate intra-domain QoS-NSLP operational
2741	   state, the total bandwidth that has to be terminated in order to
2742	   solve the severe congestion. The total to be released bandwidth is
2743	   calculated in the same way as in the situation that the QNE edges
2744	   maintain per flow intra-domain QoS-NSLP operational states.
2745	   Note that for the aggregated sessions that are affected, the QNE
2746	   Egress node generates and sends one end-to-end NOTIFY message to the
2747	   QNE Ingress node(its upstream stateful QoS-NSLP peer) to indicate the
2748	   severe congestion in the communication path. Note that this end-to-
2749	   end NOTIFY message is associated with one of the end-to-end sessions
2750	   that is bound to the aggregated intra-domain QoS-NSLP operational
2751	   state.

2753	   The non-default values of the objects contained in the NOTIFY
2754	   message MUST be set by the QNE Egress node in the same way as the
2755	   ones used by the end-to-end NOTIFY message described above for the
2756	   situation that the QNE Egress maintains a per flow intra-domain
2757	   operational state. In addition to this the end-to-end NOTIFY MUST
2758	   carry the RMD-Qspec, which contains a PDR container with a
2759	   Parameter/Container ID = PDR_10, i.e., "PDR_Congestion_Report". The
2760	   value of the <S> should be set. Furthermore, the value of the <PDR
2761	   Bandwidth> parameter MUST contain the bandwidth, associated with the
2762	   aggregated QoS-NSLP operational state, which has to be released.

2764	   Furthermore, the number of end-to-end sessions that have to be
2765	   terminated will be calculated as in the situation that the QNE edges
2766	   maintain per flow intra-domain QoS-NSLP operational states. Similarly
2767	   for each, to be terminated, ongoing flow the egress will notify the
2768	  ingress in the same way as in the situation that the QNE edges
2769	   maintain per flow intra-domain QoS-NSLP operational states.

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

2777	   4.6.1.6.2.3 Operation in the Ingress nodes

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

2788	   When the QNE Ingress node receives the end-to-end NOTIFY message, it
2789	   associates this NOTIFY message with its bound intra-domain session,
2790	   see Sections 4.3.2, 4.3.3. via the BOUND_SESSION_ID information
2791	   included in the end-to-end per-flow QoS-NSLP state. The QNE Ingress
2792	   uses the operation described in Section 4.6.1.5.2 to terminate the
2793	   intra-domain session.

2795	 QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)

2797	  user  |                  |                 |                  |
2798	  data  |  user data       |                 |                  |
2799	 ------>|----------------->|     user data   | user data        |
2800	        |                  |---------------->S(# marked bytes)  |
2801	        |                  |                 S----------------->|
2802	        |                  |                 S(# unmarked bytes)|
2803	        |                  |                 S----------------->|Term.
2804	        |                 NOTIFY             S                  |flow?
2805	        |<-----------------|-----------------S------------------|YES
2806	        |RESERVE(RMD-QSpec:Tear=1,M=1,S=1)   S                  |
2807	        | ---------------->|RESERVE(RMD-QSpec:T=1, M=1,S=1)     |
2808	        |                  |                 S                  |
2809	        |                  |---------------->S                  |
2810	        |                  |       RESERVE(RMD-QSpec:Tear=1, M=1,S=1)
2811	        |                  |                 S----------------->|

2813	   Figure 14:  RMD severe congestion handling
2814	   Note that the above functionality applies to the RMD reservation-
2815	   Based, see Section 4.3.3 and to both measurement-based admission
2816	   control methods (i.e., congestion notification based on probing and
2817	   the NSIS measurement-based admission control), see Section 4.3.2.

2819	   In the case that the QNE edges support aggregated intra-domain QoS-
2820	   NSLP operational states the following actions take place. The QNE
2821	   Ingress may receive an end to end NOTIFY message with a PDR container
2822	   that carries a <S> marked and a bandwidth value in the <PDR
2823	   Bandwidth> parameter included in a "PDR_Congestion_Report" container.
2824	   Furthermore the same end-to-end NOTIFY message carries an INFO_SPEC
2825	   object with the "Congestion situation" error code.

2827	   When the QNE Ingress node receives this end-to-end  NOTIFY message,
2828	   it associates the NOTIFY message with the aggregated intra-domain
2829	   QoS-NSLP operational state via the BOUND_SESSION_ID information
2830	   included in the end-to-end per-flow QoS-NSLP operational state, see
2831	   Section 4.3.1.

2833	   The RMD-QOSM at the QNE Ingress node by using the
2834	   total to be released bandwidth value included in the <PDR Bandwidth>
2835	   parameter MUST reduce
2836	   the bandwidth associated and reserved by the RMD aggregated session.
2837	   This is accomplished by triggering the RMD modification for
2838	   Aggregated reservations procedure described in Section 4.6.1.4.

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

2845	   The terminated end-to-end sessions are selected from the end-to-end
2846	   sessions bound to the aggregated intra-domain QoS-NSLP operational
2847	   state. Note that the end-to-end session associated with the received
2848	   end-to-end NOTIFY message that notified the severe congestion must
2849	   also be selected for termination.
2850	   For the flows (sessions) that have to be terminated, the QNE Ingress
2851	   node generates and sends an end-to-end NOTIFY message upstream
2852	   towards the sender (QNI). The values carried by this message are:

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

2857	   * the INFO_SPEC object MUST include information that notifies that
2858	     the end-to-end flow MUST be terminated. This information is as
2859	     follows:

2861	     Error Severity Class: Informational
2862	     Error Code value: Congestion situation

2864	4.6.1.7 Admission control using congestion notification based on probing

2866	   The congestion notification function based on probing can be used to
2867	   implement a simple measurement-based admission control within a
2868	   Diffserv domain.  At interior nodes along the data path congestion
2869	   notification thresholds are set in the measurement based admission
2870	   control function for the traffic belonging to different PHBs. These
2871	   interior nodes are not NSIS aware nodes.

2873	4.6.1.7.1 Operation in Ingress nodes

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

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

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

2891	4.6.1.7.2 Operation in Interior nodes

2893	   These Interior nodes are not needed to be NSIS aware nodes and they
2894	   do not need to process NSIS functionality of NSIS messages. Note that
2895	   the "not NSIS aware" nodes must be configured such that they can
2896	   detect the congestion/severe congestion situations and remark packets
2897	   in the same way as the "NSIS aware" nodes do.

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

2904	   The DSCP field of all data packets and of the GIST message carrying
2905	   the RESERVE message will be re-marked when the corresponding
2906	   "congestion notification" threshold is exceeded, see Section 4.3.2.
2907	   Note that when the data rate is higher than the congestion
2908	   notification threshold then also the data packets are remarked. An
2909	   example of the detailed operation of this procedure is given in
2910	   Appendix A.2.1.

2912	4.6.1.7.3 Operation in Egress nodes

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

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

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

2926	   If the request is rejected then the Egress node SHOULD
2927	   generate an (end-to-end) RESPONSE message to notify that the
2928	   reservation is unsuccesfull. In particular it will generate an
2929	   INFO_SPEC object of:
2930	     Error Severity Class: Transient Failure
2931	     Error Code value: Reservation failure

2933	   The QSpec that was carried by the end to end RESERVE belonging to
2934	   the same session as this end to end RESPONSE is included in this
2935	   message. The parameters included in the QSpec <QoS Reserved> object
2936	   are copied from the original <QoS Desired> values. The "E" flag
2937	   associated with the <QoS Reserved> object and the "E" flag associated
2938	   with <Bandwidth> parameter are also set. This RESPONSE message will
2939	   be sent to the Ingress node and it will be processed based on the
2940	   end-to-end QoS model.

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

2949	QNE (Ingress)          Interior          Interior       QNE (Egress)
2950	                    (not NSIS aware) (not NSIS aware)
2951	  user  |                  |                 |                  |
2952	  data  |  user data       |                 |                  |
2953	 ------>|----------------->|     user data   |                  |
2954	        |                  |---------------->| user data        |
2955	        |                  |                 |----------------->|
2956	  user  |                  |                 |                  |
2957	  data  |  user data       |                 |                  |
2958	 ------>|----------------->|     user data   | user data        |
2959	        |                  |---------------->S(# marked bytes)  |
2960	        |                  |                 S----------------->|
2961	        |                  |                 S(# unmarked bytes)|
2962	        |                  |                 S----------------->|
2963	        |                  |                 S                  |
2964	RESERVE |                  |                 S                  |
2965	------->|                  |                 S                  |
2966	        |----------------------------------->S                  |
2967	        |                  |           RESERVE(re-marked DSCP in GIST)
2968	        |                  |                 S----------------->|
2969	        |                  |RESPONSE(unsuccessful INFO-SPEC)    |
2970	        |<------------------------------------------------------|
2971	 RESPONSE(unsuccessful INFO-SPEC)            |                  |
2972	 <------|                  |                 |                  |

2974	   Figure 15:  Using RMD congestion notification function for admission
2975	               control based on probing

2977	4.6.2  Bi-directional operation

2979	   RMD-QOSM assumes that asymmetric routing may be applied in the RMD
2980	   domain.  Combined sender-receiver initiated reservation cannot be
2981	   efficiently done in the RMD domain because upstream NTLP states are
2982	   not stored in Interior routers.  Therefore, the bi-directional
2983	   operation SHOULD be performed by two sender-initiated reservations
2984	   (sender&sender).  We assume that the QNE edge nodes are common for
2985	   both upstream and downstream directions, therefore, the two
2986	   reservations/sessions can be bound at the QNE edge nodes. Note that
2987	   if this is not the case then the bi-directional procedure could be
2988	   managed and maintained by nodes located outside the RMD domain, by
2989	   using other procedures than the ones defined in RMD-QOSM.

2991	   This bi-directional sender&sender procedure can then be applied
2992	   between the QNE edges (QNE Ingress and QNE Egress) nodes of the RMD
2993	   QoS signaling model.  In the situation a security association
2994	   exists between the QNE Ingress and QNE Egress nodes (see Figure 15),
2995	   and the QNE Ingress node has the required <Bandwidth> parameters
2996	   for both directions, i.e., QNE Ingress towards QNE Egress and QNE
2997	   Egress towards QNE Ingress, then the QNE Ingress MAY include both
2998	   <Bandwidth> parameters (needed for both directions) into the
2999	   RMD-QSpec within a RESERVE message.  In this way the QNE Egress node
3000	   is able to use the QoS parameters needed for the "Egress towards
3001	   Ingress" direction (QoS-2).  The QNE Egress is then able to create a
3002	   RESERVE with the right QoS parameters included in the QSpec, i.e.,
3003	   RESERVE (QoS-2). Both directions of the flows are bound by inserting
3004	   <BOUND_SESSION_ID> objects at the QNE Ingress and QNE Egress, which
3005	   will be carried by bound end-to-end RESERVE messages.

3007	     |------ RESERVE (QoS-1, QoS-2)----|
3008	     |                                 V
3009	     |           Interior/stateless QNEs
3010	                 +---+     +---+
3011	        |------->|QNE|-----|QNE|------
3012	        |        +---+     +---+     |
3013	        |                            V
3014	      +---+                        +---+
3015	      |QNE|                        |QNE|
3016	      +---+                        +---+
3017	         ^                           |
3018	      |  |       +---+     +---+     V
3019	      |  |-------|QNE|-----|QNE|-----|
3020	      |          +---+     +---+
3021	   Ingress/                         Egress/
3022	   statefull QNE                    statefull QNE
3023	                                     |
3024	   <--------- RESERVE (QoS-2) -------|

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

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

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

3037	   When the QNE edges maintain per-flow intra-domain QoS-NSLP
3038	   operational states then the end-to-end RESERVE message carries two
3039	   BOUND_SESSION_IDs. One BOUND_SESSION_ID carries the SESSION_ID of the
3040	   tunneled intra-domain (per-flow) session that is using a BINDING_CODE
3041	   with value set to code (Tunneled and end-to-end sessions).  Another
3042	   BOUND_SESSION_ID carries the SESSION_ID of the bound bidirectional
3043	   end-to-end session. The BINDING_CODE associated with this
3044	   BOUND_SESSION_ID is set to code (Bi-directional sessions).

3046	   When the QNE edges maintain aggregated intra-domain QoS-NSLP
3047	   operational states then the end-to-end RESERVE message carries two
3048	   BOUND_SESSION_IDs. One BOUND_SESSION_ID carries the SESSION_ID of the
3049	   tunneled aggregated intra-domain session that is using a BINDING_CODE
3050	   with value set to code (Aggregated sessions).  Another
3051	   BOUND_SESSION_ID carries the SESSION_ID of the bound bidirectional
3052	   end-to-end session. The BINDING_CODE associated with this
3053	   BOUND_SESSION_ID is set to code (Bi-directional sessions).

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

3059	   If no security association exists between the QNE Ingress and QNE
3060	   Egress nodes the bi-directional reservation for the sender&sender
3061	   scenario in the RMD domain SHOULD use the scenario specified in
3062	   [QoS-NSLP] as "Bi-directional reservation for sender&sender
3063	   scenario". This is because in this scenario the RESERVE message sent
3064	   from QNE Ingress to QNE Egress does not have to carry the QoS
3065	   parameters needed for the "Egress towards Ingress" direction (QoS-2).

3067	   In the following sections it is considered that the QNE
3068	   edge nodes are common for both upstream and downstream directions
3069	   and therefore, the two reservations/sessions can be bound at the
3070	   QNE edge nodes.  Furthermore, it is considered that a security
3071	   association exists between the QNE Ingress and QNE Egress nodes,
3072	   and the QNE Ingress node has the required <Bandwidth> parameters
3073	   for both directions, i.e., QNE Ingress towards QNE Egress and
3074	   QNE Egress towards QNE Ingress.

3076	4.6.2.1 Successful and unsuccessful reservations

3078	   This section describes the operation of the RMD-QOSM where a RMD
3079	   bi-directional reservation operation is either successfully or
3080	   unsuccessfully accomplished.

3082	   The bi-directional successful reservation is similar to a
3083	   combination of two unidirectional successful reservations that are
3084	   accomplished in opposite directions, see Figure 17. The main
3085	   differences of the bi-directional successful reservation procedure
3086	   with the combination of two unidirectional successful reservations
3087	   accomplished in opposite directions are as follows. Note also that
3088	   the intra-domain and end-to-end QoS-NSLP operational states generated
3089	   and maintained by the end-to-end RESERVE messages contain, compared
3090	   to the unidirectional reservation scenario, a different
3091	   BOUND_SESSION_ID data structure, see Section 4.3.1, 4.3.2, 4.3.3.
3092	   In this scenario the intra-domain RESERVE message sent by the QNE
3093	   Ingress node towards the QNE Egress node, is denoted in Figure 17 as
3094	   RESERVE (RMD-QSpec): "forward".  The main differences between the
3095	   intra-domain RESERVE (RMD-QSpec):"forward" message used for the bi-
3096	   directional successful reservation procedure and a RESERVE (RMD-
3097	   QSpec) message used for the unidirectional successful reservation are
3098	   as follows (see QoS-NSLP-RMF API described in [QoS-NSLP]):

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

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

3106	   *  the PDR container is also included into the RESERVE(RMD-QSpec):
3107	      "forward" message. The value of the Parameter/Container ID is
3108	      "PDR_4", i.e., "PDR_Reservation_Request".  Note that the response
3109	      PDR container sent by a QNE Egress to a QNE Ingress node is not
3110	      carried by an end-to-end RESPONSE message, but it is carried by an
3111	      intra-domain RESERVE message that is sent by the QNE Egress node
3112	      towards the QNE Ingress node (denoted in Figure 16 as
3113	      RESERVE(RMD-QSpec):"reverse").

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

3118	   *  the <PDR Bandwidth> field specifies the
3119	      requested bandwidth that has to be used by the QNE Egress node to
3120	      initiate another intra-domain RESERVE message in the reverse
3121	      direction.

3123	   The RESERVE(RMD-QSpec):"reverse" message is initiated by the QNE
3124	   Egress node at the moment that the RESERVE(RMD-QSpec):"forward"
3125	   message is successfully processed by the QNE Egress node.
3126	   The main differences between the RESERVE(RMD-QSpec):"reverse"
3127	   message used for the bi-directional successful reservation procedure
3128	   and a RESERVE(RMD-QSpec) message used for the unidirectional
3129	   successful reservation are as follows:

3131	QNE (Ingress)   QNE (int.)    QNE (int.)    QNE (int.)   QNE (Egress)
3132	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
3133	    |                |               |               |              |
3134	    |                |               |               |              |
3135	    |RESERVE(RMD-QSpec)              |               |              |
3136	    |"forward"       |               |               |              |
3137	    |                |    RESERVE(RMD-QSpec):        |              |
3138	    |--------------->|    "forward"  |               |              |
3139	    |                |------------------------------>|              |
3140	    |                |               |               |------------->|
3141	    |                |               |               |              |
3142	    |                |               |RESERVE(RMD-QSpec)            |
3143	    |      RESERVE(RMD-QSpec)        | "reverse"     |<-------------|
3144	    |      "reverse" |               |<--------------|              |
3145	    |<-------------------------------|               |              |

3147	      Figure 17: Intra-domain signaling operation for successful
3148	                 bi-directional reservation

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

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

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

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

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

3168	   Figure 18 and Figure 19 show the flow diagrams used in case of a
3169	   unsuccessful bi-directional reservation.  In Figure 18 it
3170	   is considered that the QNE that is not able to support the
3171	   requested <Bandwidth> is located in the direction QNE Ingress
3172	   towards QNE Egress.  In Figure 19 it is considered that the
3173	   QNE that is not able to support the requested <Bandwidth> is
3174	   located in the direction QNE Egress towards QNE Ingress.

3176	   The main differences between the bi-directional unsuccessful
3177	   procedure shown in Figure 18 and the bi-directional successful
3178	   procedure are as follows:

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

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

3188	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3189	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
3190	    |                |             |              |               |
3191	    |RESERVE(RMD-QSpec):           |              |               |
3192	    |  "forward"     |  RESERVE(RMD-QSpec):       |               |
3193	    |--------------->|  "forward"  |              M RESERVE(RMD-QSpec):
3194	    |                |--------------------------->M  "forward-M marked"
3195	    |                |             |              M-------------->|
3196	    |                |           RESPONSE(PDR)    M               |
3197	    |                |        "forward - M marked"M               |
3198	    |<------------------------------------------------------------|
3199	    |RESERVE(RMD-QSpec, K=0)       |              M               |
3200	    |"forward - T tear"            |              M               |
3201	    |--------------->|             |              M               |
3202	    |                    RESERVE(RMD-QSpec, K=1)  M               |
3203	    |                |   "forward - T tear"       M               |
3204	    |                |--------------------------->M               |
3205	    |                |                  RESERVE(RMD-QSpec, K=1)   |
3206	    |                |                 "forward - T tear"         |
3207	    |                |                            M-------------->|

3209	   Figure 18: Intra-domain signaling operation for unsuccessful
3210	              bi-directional reservation (rejection on path QNE(Ingress)
3211	              towards QNE(Egress))

3213	   The operation for this type of unsuccessful bi-directional
3214	   reservation is similar to the operation for unsuccessful uni-
3215	   directional reservation shown in Figure 9.

3217	   The main differences between the bi-directional unsuccessful
3218	   procedure shown in Figure 19 and the in bi-directional successful
3219	   procedure are as follows:

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

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

3229	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3230	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
3231	    |                |                |                |              |
3232	    |RESERVE(RMD-QSpec)               |                |              |
3233	    |"forward"       |  RESERVE(RMD-QSpec):            |              |
3234	    |--------------->|  "forward"     |           RESERVE(RMD-QSpec): |
3235	    |                |-------------------------------->|"forward"     |
3236	    |                |   RESERVE(RMD-QSpec):           |------------->|
3237	    |                |    "reverse"   |                |              |
3238	    |                |              RESERVE(RMD-QSpec) |              |
3239	    |    RESERVE(RMD-QSpec):          M      "reverse" |<-------------|
3240	    |   "reverse - M marked"          M<---------------|              |
3241	    |<--------------------------------M                |              |
3242	    |                |                M                |              |
3243	    |RESERVE(RMD-QSpec, K=0):         M                |              |
3244	    |"forward - T tear"               M                |              |
3245	    |--------------->|  RESERVE(RMD-QSpec, K=0):       |              |
3246	    |                |  "forward - T tear"             |              |
3247	    |                |-------------------------------->|              |
3248	    |                |                M                |------------->|
3249	    |                |                M         RESERVE(RMD-QSpec, K=0):
3250	    |                |                M             reverse - T tear" |
3251	    |                |                M                |<-------------|
3252	    |                                 M RESERVE(RMD-QSpec, K=1)       |
3253	    |                |                M "forward - T tear"            |
3254	    |                |                M<---------------|              |
3255	    |          RESERVE(RMD-QSpec, K=1)M                |              |
3256	    |          "forward - T tear"     M                |              |
3257	    |<--------------------------------M                |              |

3259	   Figure 19: Intra-domain signaling normal operation for unsuccessful
3260	             bi-directional reservation (rejection on path QNE(Egress)
3261	             towards QNE(Ingress)

3263	   *  the QNE Ingress uses the information contained in the received
3264	      PHR and PDR containers of the RESERVE(RMD-QSpec): "reverse" and
3265	      generates a tear intra-domain RESERVE(RMD-QSpec):
3266	      "forward - T tear" message.  This message carries a
3267	      "PHR_Release_Request" and a "PDR_Release_Request" control
3268	      information.  This message is sent to QNE Egress node.
3269	      The QNE Egress node uses the information contained in the
3270	      "PHR_Release_Request" and the "PDR_Release_Request" control
3271	      info containers to generate a RESERVE(RMD-QSpec):"reverse - T
3272	      tear" message that is sent towards the QNE Ingress node.

3274	4.6.2.2 Refresh reservations

3276	   This section describes the operation of the RMD-QOSM where a RMD
3277	   bi-directional refresh reservation operation is accomplished.
3278	   The refresh procedure in case of RMD reservation-based method
3279	   follows a similar scheme as the successful reservation procedure,
3280	   described in Section 4.6.2.1, and depicted in Figure 17 and the
3281	   way of how the refresh process of the reserved resources is
3282	   maintained, is similar to the refresh process used for the intra-
3283	   domain uni-directional reservations (see Section 4.6.1.3).

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

3289	   The main differences between the RESERVE(RMD-QSpec):"forward"
3290	   message used for the bi-directional refresh procedure
3291	   and a RESERVE(RMD-QSpec):"forward" message used for the bi-
3292	   directional successful reservation procedure are as follows:

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

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

3300	   The main differences between the RESERVE(RMD-QSpec):"reverse"
3301	   message used for the bi-directional refresh procedure and the RESERVE
3302	   (RMD-QSpec): "reverse" message used for the bi-directional successful
3303	   reservation procedure are as follows:

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

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

3311	4.6.2.3 Modification of aggregated intra-domain QoS-NSLP operational
3312	reservation states

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

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

3321	   * When the modification request requires an increase of the reserved
3322	   resources, the QNE Ingress node MUST include the corresponding value
3323	   into the <Bandwidth> parameter of the "RMD-QOSM object combination"
3324	   (i.e., the RMD-QOSM <QoS Desired>), which is sent together with a
3325	   "PHR_Resource_Request" control information.  If a QNE edge or QNE
3326	   Interior node is not able to reserve the number of requested
3327	   resources, then the "PHR_Resource_Request" associated with the
3328	   <Bandwidth> parameter MUST be marked.  In this situation the RMD
3329	   specific operation for unsuccessful reservation will be applied (see

3331	   Section 4.6.2.1). Note that the value of the <PDR Bandwidth>
3332	   parameter, which is sent within a "PDR_Reservation_Request"
3333	   container, represents the increase of the reserved resources in the
3334	   "reverse" direction.

3336	   * When the modification request requires a decrease of the
3337	   reserved resources, the QNE Ingress node MUST include this value
3338	   into the <Bandwidth> parameter of the "RMD-QOSM object combination"
3339	   (i.e., the RMD-QOSM <QoS Desired>). Subsequently an RMD release
3340	   procedure SHOULD be accomplished (see Section 4.6.2.4). Note that the
3341	   value of the <PDR Bandwidth> parameter, which is sent within a
3342	   "PDR_Release_Request" container, represents the decrease of the
3343	   reserved resources in the "reverse" direction.

3345	4.6.2.4 Release procedure

3347	   This section describes the operation of the RMD-QOSM where a RMD
3348	   bi-directional reservation release operation is accomplished.
3349	   The message sequence diagram used in this procedure is similar to the
3350	   one used by the successful reservation procedures, described in
3351	   Section 4.6.2.1, and depicted in Figure 17. However, the way of how
3352	   the release of the reservation is accomplished, is similar to the RMD
3353	   release procedure used for the intra-domain uni-directional
3354	   reservations (see Section 4.6.1.5 and Figure 18 and Figure 19).

3356	   The main differences between the RESERVE (RMD-QSpec):
3357	   "forward" message used for the bi-directional release procedure
3358	   and a RESERVE (RMD-QSpec): "forward" message used for the bi-
3359	   directional successful reservation procedure are as follows:

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

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

3367	   The main differences between the RESERVE (RMD-QSpec): "reverse"
3368	   message used for the bi-directional release procedure and the RESERVE
3369	   (RMD-QSpec): "reverse" message used for the bi-directional successful
3370	   reservation procedure are as follows:

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

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

3378	4.6.2.5 Severe congestion handling

3380	   This section describes the severe congestion handling operation used
3381	   in combination with bi-directional reservation procedures.
3382	   This severe congestion handling operation is similar to the one
3383	   described in Section 4.6.1.6.

3385	4.6.2.5.1 Severe congestion handling by the RMD-QOSM bi-directional
3386	          refresh procedure

3388	   This procedure is similar to the severe congestion handling procedure
3389	   described in Section 4.6.1.6.1. The difference is related to how the
3390	   refresh procedure is accomplished, see Section 4.6.2.2 and to how the
3391	   flows are terminated, see Section 4.6.2.4.

3393	4.6.2.5.2 Severe congestion handling by proportional data packet marking

3395	   This section describes the severe congestion handling by proportional
3396	   data packet marking when this is combined with a bi-directional
3397	   reservation procedure. Note that the detection and marking/remarking
3398	   functionality described in this section and used by Interior nodes,
3399	   applies to NSIS aware, but also to NSIS unaware nodes. This means
3400	   however, that the "not NSIS aware" Interior nodes must be configured
3401	   such that they can detect the congestion situations and remark
3402	   packets in the same way as the Interior "NSIS aware" nodes do.

3404	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3405	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
3406	user|                |             |              |               |
3407	data|    user        |             |              |               |
3408	--->|    data        | user data   |              |user data      |
3409	    |--------------->|             |              S               |
3410	    |                |--------------------------->S (#marked bytes)
3411	    |                |             |              S-------------->|
3412	    |                |             |              S(#unmarked bytes)
3413	    |                |             |              S-------------->|Term
3414	    |                |             |              S               |flow?
3415	    |                |          NOTIFY (PDR)      S               |YES
3416	    |<------------------------------------------------------------|
3417	    |RESERVE(RMD-QSpec)            |              S               |
3418	    |"forward - T tear"            |              S               |
3419	    |--------------->|             |           RESERVE(RMD-QSpec):|
3420	    |                |--------------------------->S"forward - T tear"
3421	    |                |             |              S-------------->|
3422	    |                |             |          RESERVE(RMD-QSpec): |
3423	    |                |             |           "reverse - T tear" |
3424	    | RESERVE(RMD-QSpec):          |              |<--------------|
3425	    |"reverse - T tear"            |<-------------S               |
3426	    |<-----------------------------|              S               |

3428	Figure 20: Intra-domain RMD severe congestion handling for
3429	           bi-directional reservation (congestion on path QNE(Ingress)
3430	           towards QNE(Egress))

3432	   This procedure is similar to the severe congestion handling procedure
3433	   described in Section 4.6.1.6.2. The main difference is related to the
3434	   location of the severe congested node, i.e. "forward" or "reverse"
3435	   path. Note that when a severe congestion situation occurs on
3436	   e.g. on a forward path, and flows are terminated to solve the severe
3437	   congestion in forward path, then the reserved bandwidth associated
3438	   with the terminated bidirectional flows will also be released.
3439	   Therefore, a careful selection of the flows that have to be
3440	   terminated should take place. An example of such a selection is given
3441	   in Appendix A.3.1.

3443	   Furthermore, a special case of this operation is associated to the
3444	   severe congestion situation occurring simultaneously on the forward
3445	   and reverse paths. An example of this operation is given in Appendix
3446	   A.3.2.

3448	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
3449	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
3450	user|                |                |           |               |
3451	data|    user        |                |           |               |
3452	--->|    data        | user data      |           |user data      |
3453	    |--------------->|                |           |               |
3454	    |                |--------------------------->|user data      |user
3455	    |                |                |           |-------------->|data
3456	    |                |                |           |               |--->
3457	    |                |                |  user     |               |<---
3458	    |   user data    |                |  data     |<--------------|
3459	    | (#marked bytes)|                S<----------|               |
3460	    |<--------------------------------S           |               |
3461	    | (#unmarked bytes)               S           |               |
3462	Term|<--------------------------------S           |               |
3463	Flow?                |                S           |               |
3464	YES |RESERVE(RMD-QSpec):              S           |               |
3465	    |"forward - T tear"               s           |               |
3466	    |--------------->|  RESERVE(RMD-QSpec):       |               |
3467	    |                |  "forward - T tear"        |               |
3468	    |                |--------------------------->|               |
3469	    |                |                S           |-------------->|
3470	    |                |                S         RESERVE(RMD-QSpec):
3471	    |                |                S       "reverse - T tear"  |
3472	    |      RESERVE(RMD-QSpec)         S           |<--------------|
3473	    |      "reverse - T tear"         S<----------|               |
3474	    |<--------------------------------S           |               |

3476	   Figure 21: Intra-domain RMD severe congestion handling for
3477	           bi-directional reservation (congestion on path QNE(Egress)
3478	           towards QNE(Ingress))

3480	   Figure 20 shows the scenario where the severe congested node is
3481	   located in the "forward" path. This scenario is very similar to the
3482	   severe congestion handling scenario described in Section 4.6.1.6.2
3483	   and shown in Figure 14. The difference is related to the release
3484	   procedure, which is accomplished in the same way as described in
3485	   Section 4.6.2.4.

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

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

3500	4.6.2.6 Admission control using congestion notification based on
3501	          probing

3503	   This section describes the admission control scheme that uses the
3504	   congestion notification function based on probing when bi-directional
3505	   reservations are supported.

3507	QNE(Ingress)    Interior    QNE (int.)      Interior      QNE (Egress)
3508	NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
3509	user|                |             |              |               |
3510	data|                |             |              |               |
3511	--->|                | user data   |              |user data      |
3512	    |-------------------------------------------->S (#marked bytes)
3513	    |                |             |              S-------------->|
3514	    |                |             |              S(#unmarked bytes)
3515	    |                |             |              S-------------->|
3516	    |                |             |              S               |
3517	    |                |           RESERVE(re-marked DSCP in GIST)):|
3518	    |                |             |              S               |
3519	    |-------------------------------------------->S               |
3520	    |                |             |              S-------------->|
3521	    |                |             |              S               |
3522	    |                |          RESPONSE(unsuccessful INFO-SPEC)  |
3523	    |<------------------------------------------------------------|
3524	    |                |             |              S               |

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

3530	   This procedure is similar to the congestion notification for
3531	   admission control procedure described in Section 4.6.1.7. The main
3532	   difference is related to the location of the severe congested node,
3533	   i.e., "forward" path (i.e., path between QNE Ingress towards QNE
3534	   Egress) or "reverse" path (i.e., path between QNE Egress towards
3535	   QNE Ingress).

3537	   Figure 22 shows the scenario where the severe congested node is
3538	   located in the "forward" path. The functionality of providing
3539	   admission control is the same as the one described in Section
3540	   4.6.1.7, Figure 15.

3542	   Figure 23 shows the scenario where the congested node is located in
3543	   the "reverse" path. The probe RESERVE message sent in the "forward"
3544	   direction will not be affected by the severe congested node, while
3545	   the DSCP value in the IP header of any packet of the "reverse"
3546	   direction flow and also of the GIST message that carries the
3547	   probe RESERVE message sent in the "reverse" direction will be
3548	   remarked by the congested node. The QNE ingress is in this way
3549	   notified that a congestion occurred in the network and therefore it
3550	   is able to refuse the new initiation of the reservation.

3552	QNE (Ingress)    Interior    QNE (int.)     Interior       QNE (Egress)
3553	NTLP stateful not NSIS aware  NTLP st.less not NSIS aware NTLP stateful
3554	user|                |                |           |               |
3555	data|                |                |           |               |
3556	--->|                | user data      |           |               |
3557	    |-------------------------------------------->|user data      |user
3558	    |                |                |           |-------------->|data
3559	    |                |                |           |               |--->
3560	    |                |                |           |               |user
3561	    |                |                |           |               |data
3562	    |                |                |           |               |<---
3563	    |                S                | user data |               |
3564	    |                S  user data     |<--------------------------|
3565	    |   user data    S<---------------|           |               |
3566	    |<---------------S                |           |               |
3567	    |  user data     S                |           |               |
3568	    | (#marked bytes)S                |           |               |
3569	    |<---------------S                |           |               |
3570	    |                S           RESERVE(unmarked DSCP in GIST)): |
3571	    |                S                |           |               |
3572	    |----------------S------------------------------------------->|
3573	    |                S          RESERVE(re-marked DSCP in GIST)   |
3574	    |                S<-------------------------------------------|
3575	    |<---------------S                |           |               |

3577	   Figure 23: Intra-domain RMD congestion notification for
3578	           bi-directional admission control (congestion on path
3579	           QNE(Egress) towards QNE(Ingress))

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

3586	4.7 Handling of additional errors

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

3592	5.  Security Considerations

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

3600	   The RMD-QOSM aims to be very lightweight signaling with regard to
3601	   the number of signaling message roundtrips and the amount of state
3602	   established at involved signaling nodes with and without reduced
3603	   state on QNEs. This implies the usage of the Datagram Mode which
3604	   does not allow channel security to be used. As such, RMD signaling is
3605	   targeted towards intra-domain signaling only. Therefore, the security
3606	   considerations described in this section apply to all the supported
3607	   RMD-QOSM/QoS-NSLP signalling schemes, see Section 3.2.3.

3609	       QNE             QNE             QNE            QNE
3610	     Ingress         Interior        Interior        Egress
3611	 NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
3612	        |               |               |              |
3613	        | RESERVE (1)   |               |              |
3614	        +--------------------------------------------->|
3615	        | RESERVE` (2)  |               |              |
3616	        +-------------->|               |              |
3617	        |               | RESERVE`      |              |
3618	        |               +-------------->|              |
3619	        |               |               | RESERVE`     |
3620	        |               |               +------------->|
3621	        |               |               | RESPONSE` (2)|
3622	        |<---------------------------------------------+
3623	        |               |               | RESPONSE (1) |
3624	        |<---------------------------------------------+

3626	                 Figure 24: RMD message exchange

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

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

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

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

3649	*  Nodes, which are never supposed to participate in the NSIS signaling
3650	   exchange, MUST NOT interfere with QNE Interior nodes. Off-path
3651	   nodes (off-path with regard to the path taken by a particular
3652	   signaling message exchange) MUST NOT be able to interfere with
3653	   other on-path signaling nodes.

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

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

3665	   If we assume that the RESERVE/RESPONSE is sent with hop-by-hop
3666	   channel security provided by GIST and protected between the QNE
3667	   Ingress and the QNE Egress node then we can
3668	   be sure that the payloads of these messages MUST be authenticated,
3669	   integrity, replay protected and encrypted. Encryption is necessary to
3670	   prevent an adversary that is located along the path of the RESERVE
3671	   message to learn information about the session that can later be used
3672	   to inject a valid RESERVE`. The following messages need to relate to
3673	   each other to make sure that the occurrence of one message is not
3674	   without the other one:

3676	   a) the RESERVE and the RESERVE` relate to each other at the QNE
3677	      Egress and

3679	   b) the RESPONSE and the RESERVE relate to each other at the QNE
3680	      Ingress and

3682	   c) the RESERVE` and the RESPONSE` relate to each other. The RII is
3683	   carried in the RESERVE` message and the RESPONSE` message that is
3684	   generated by the QNE Egress node contains the same RII as the
3685	   RESERVE`. The RII can be used by the QNE Ingress to match the
3686	   RESERVE` with the RESPONSE`. The QNE Egress is able to determine
3687	   whether the RESERVE` was created by the QNE Ingress node since the
3688	   intra-domain session, which sent the RESERVE`, is bound to an end-to-
3689	   end session via the BOUND_SESSION_ID value included in the intra-
3690	   domain QoS-NSLP operational state maintained at the QNE Egress.

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

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

3709	   The severe congestion handling can be triggered by intermediate nodes
3710	   (unlike other messages). In many cases, however, intermediate nodes
3711	   experiencing congestion use refresh messages modify the <S> and
3712	   <Overload %> parameters of the message. These messages are still
3713	   initiated by the QNE Ingress node and carry the SESSION_ID. The QNE
3714	   Egress node will use the SESSION_ID and subsequently the
3715	   BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP operational
3716	   state, to refer to a flow that might be terminated. The
3717	   aspect of intermediate nodes initiating messages for severe
3718	   congestion handling is for further study.

3720	   QNE Ingress    QNE Interior   QNE Interior    QNE Egress
3721	 NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
3722	        |               |               |              |
3723	        | REFRESH RESERVE`              |              |
3724	        +-------------->| REFRESH RESERVE`             |
3725	        | (+RII)        +-------------->| REFRESH RESERVE`
3726	        |               | (+RII)        +------------->|
3727	        |               |               | (+RII)       |
3728	        |               |               |              |
3729	        |               |               |     REFRESH  |
3730	        |               |               |     RESPONSE`|
3731	        |<---------------------------------------------+
3732	        |               |               |     (+RII)   |

3734	                 Figure 25: RMD REFRESH message exchange

3736	   During the refresh procedure a RESERVE` creates a RESPONSE`, see
3737	   Figure 25. The RII is carried in the RESERVE` message and the
3738	   RESPONSE` message that is generated by the QNE Egress node contains
3739	   the same RII as the RESERVE`.

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

3744	   A further aspect is marking of data traffic. Data packets can be
3745	   modified by an intermediary without any relationship to a signaling
3746	   session (and a SESSION_ID). The problem appears if an off-path
3747	   adversary injects spoofed data packets. The adversary thereby needs
3748	   to spoof data packets that relate to the flow identifier of an
3749	   existing end-to-end reservation that should be terminated. Therefore
3750	   the question arises how an off-path adversary should create a data
3751	   packet that matches an existing flow identifier (if a 5-tuple is
3752	   used). Hence, this might not turn out to be simple for an adversary
3753	   unless we assume the previously mentioned mobility/re-routing case
3754	   where the path through the network changes and the set of nodes that
3755	   are along a path changes over time.

3757	6.  IANA Considerations

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

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

3766	            Value          Parameter/Container ID
3767	   ------------------------+----------------
3768	   |To-be-assigned-by-IANA | PHR Container |
3769	   |To-be-assigned-by-IANA | Bandwidth     |
3770	   |To-be-assigned-by-IANA | PDR Container |
3771	   ------------------------+----------------

3773	   Note to the editor: in this draft a list with temporarily parameter
3774	   ID values are given to the Bandwidth parameter, PHR containers and
3775	   PDR containers, see Sections 4.1.1, 4.1.2 and 4.1.3. The temporarily
3776	   ID value given for the Bandwidth parameter ID is Bandwidth_ID, see
3777	   Section 4.1.1. The given PHR container ID values are in a range from
3778	   PHR_1 to PHR_3 and the given PDR container ID values are in the range
3779	   from PDR_4 to PDR_10. After the IANA will assign new parameter ID
3780	   values, then all these temporarily assigned values have to be
3781	   reassigned.

3783	7.  Acknowledgments

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

3792	8.  Authors' Addresses

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

3800	   Lars Westberg
3801	   Ericsson Research
3802	   Torshamnsgatan 23
3803	   SE-164 80 Stockholm, Sweden
3804	   EMail: Lars.Westberg@ericsson.com
3805	   Georgios Karagiannis
3806	   University of Twente
3807	   P.O.  BOX 217
3808	   7500 AE Enschede, The Netherlands
3809	   EMail: g.karagiannis@ewi.utwente.nl

3811	   Cornelia Kappler
3812	   DeZem GmbH   Knesebeckstr. 86/87
3813	   10623 Berlin
3814	   Germany
3815	   Email: cornelia.kappler@googlemail.com

3817	   Hannes Tschofenig
3818	   Nokia Siemens Networks
3819	   Linnoitustie 6
3820	   Espoo 02600
3821	   Finland
3822	   EMail: Hannes.Tschofenig@nsn.com
3823	   URI: http://www.tschofenig.priv.at

3825	   Tom Phelan
3826	   Sonus Networks
3827	   250 Apollo Dr.
3828	   Chelmsford, MA USA 01824
3829	   EMail: tphelan@sonusnet.com

3831	   Attila Takacs
3832	   Ericsson Research
3833	   Ericsson Hungary Ltd.
3834	   Laborc 1, Budapest, Hungary, H-1037
3835	   EMail: Attila.Takacs@ericsson.com

3837	   Andras Csaszar
3838	   Ericsson Research
3839	   Ericsson Hungary Ltd.
3840	   Laborc 1, Budapest, Hungary, H-1037
3841	   EMail: Andras.Csaszar@ericsson.com

3843	9.  Normative References

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

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

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

3855	10.  Informative References

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3937	   Per supported PHB, the interior node can support the operation states
3938	   depicted in Figure A.1, when the per-flow congestion notification
3939	   based on probing signaling scheme is used in combination with this
3940	   severe congestion type. Figure A.2 depicts the same functionality
3941	   when the per-flow congestion notification based on probing scheme is
3942	   not used in combination with the severe congestion scheme. The
3943	   description given in this and the following appendices, focuses
3944	   on the situation that during the congestion notification state, the
3945	   "notified DSCP" marking and during the severe congestion state the
3946	   "encoded DSCP" and "affected DSCP" markings are used. In this case,
3947	   the "notified DSCP" marking is used during the
3948	   congestion notification state to mark all packets passing through an
3949	   interior node that operates in the congestion notification state. In
3950	   this way, and in combination with probing, an ECMP solution can be
3951	   provided for the congestion notification state. The "encoded DSCP"
3952	   marking is used to encode and signal the excess rate,
3953	   measured at interior nodes, to the egress nodes. The "affected DSCP"
3954	   marking is used to mark all packets that are passing through a severe
3955	   congested node and are not "encoded DSCP" marked.

3957	   Another possible situation could be derived where both congestion
3958	   notification and severe congestion state are using the "encoded DSCP"
3959	   marking, without using the "notified DSCP" marking. The "affected
3960	   DSCP" marking is used to mark all packets that are passing through
3961	   an Interior node that is in severe congestion state and are not
3962	   "encoded DSCP" marked. In addition, the probe packet that is carried
3963	   by an intra-domain RESERVE message and pass through Interior nodes
3964	   SHOULD be "encoded DSCP" marked if the Interior node is in
3965	   congestion notification or severe congestion states. Otherwise the
3966	   probe packet will remain unmarked. In this way an ECMP solution can
3967	   be provided for both congestion notification and severe congestion
3968	   states. The"encoded DSCP" packets are signaling excess rate that is
3969	   not only associated with interior nodes that are in severe congestion
3970	   state, but also with interior nodes that are in congestion
3971	    notification state.  The algorithm at the Interior node, is similar
3972	   to the algorithm described in the following appendix sections.
3973	   However, this method is not described in detail in this example.

3975	                ---------------------------------------------
3976	               |        event B                              |
3977	               |                                             V
3978	            ----------             -------------           ----------
3979	           | Normal   |  event A  | Congestion  | event B | Severe   |
3980	           |  state   |---------->| notification|-------->|congestion|
3981	           |          |           |  state      |         |  state   |
3982	            ----------             -------------           ----------
3983	             ^  ^                       |                     |
3984	             |  |      event C          |                     |
3985	             |   -----------------------                      |
3986	             |         event D                                |
3987	              ------------------------------------------------

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

3992	            ----------                 -------------
3993	           | Normal   |  event B      | Severe      |
3994	           |  state   |-------------->| congestion  |
3995	           |          |               |  state      |
3996	            ----------                 -------------
3997	                ^                           |
3998	                |      event E              |
3999	                 ---------------------------
4000	        Figure A.2: States of operation, severe congestion without
4001	        congestion notification based on probing

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

4005	   Normal state: represents the normal operation conditions of the
4006	   node,   i.e. no congestion
4007	   Severe congestion state: it represents the state when state the
4008	   interior node is severely congested related to a certain PHB. It is
4009	   important to emphasize that one of the targets of the severe
4010	   congestion state solution to change the severe congestion state
4011	   behaviour directly to the normal state.

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

4016	   event A: this event occurs when the incoming PHB rate is higher than
4017	   the "congestion notification detection" threshold and lower than the
4018	   severe congestion detection". This threshold is used by the
4019	   congestion notification based on probing scheme, see
4020	   Section 4.6.1.7, 4.6.2.6.

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

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

4028	   event D: this event occurs when the incoming PHB rate is lower than
4029	   or equal to the "severe_congestion_restoration" threshold. It is
4030	   important to emphasize that this even supports one of the targets of
4031	   the severe congestion state solution to change the severe congestion
4032	   state behaviour directly to the normal state.

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

4037	   Note that the "severe congestion detection", "severe congestion
4038	   restoration" and admission thresholds should be higher than the
4039	   "congestion notification detection" threshold, i.e.,:
4040	   "severe congestion detection" > "congestion notification detection"
4041	   and "severe congestion restoration" > "congestion notification
4042	   detection"

4044	   Furthermore, the "severe congestion detection" threshold should be
4045	   higher than or equal to the admission threshold that is used by the
4046	   reservation based and NSIS measurement based signaling schemes.
4047	   "severe congestion detection" >= admission threshold

4049	   Moreover, the "severe congestion restoration" threshold should be
4050	   lower than or equal to the "severe congestion detection" threshold
4051	   that is used by the reservation based and NSIS measurement based
4052	   signaling schemes, i.e.,:

4054	   "severe congestion restoration" <= "severe congestion detection"

4056	   During severe congestion the interior node calculates, per traffic
4057	   class (PHB), the incoming rate that is above the "severe congestion
4058	   restoration" threshold, denoted as signaled_overload_rate, in the
4059	   following way:

4061	   * A severe congested interior node should take into account that
4062	   packets might be dropped. Therefore, before queuing and eventually
4063	   dropping packets, the interior node should count the total number of
4064	   unmarked and remarked bytes received by the severe congested node,
4065	   denote this number as total_received_bytes. Note that there are
4066	   situations when more than one interior nodes in the same path become
4067	   severe congested. Therefore, any interior node located behind a
4068	   severe congested node may receive marked bytes.

4070	   When the "severe congestion detection" threshold per PHB is set
4071	   equal to the maximum capacity allocated to one PHB used by the RMD-
4072	   QOSM it means that if the maximum capacity associated to a PHB is
4073	   fully utilized and a packet belonging to this PHB arrives, then it is
4074	   assumed that the interior node will not forward this packet
4075	   downstream. In other words this packet will either be dropped or set
4076	   to another PHB. Furthermore, this also means that after the severe
4077	   congestion situation is solved, then the ongoing flows will be able
4078	   to send their associated packets up to a total rate equal to the
4079	   maximum capacity associated to the PHB. Therefore, when more than one
4080	   interior nodes located on the same path will be severe congested and
4081	   when the interior node receives "encoded DSCP" marked packets, then
4082	   it will mean that an interior node located upstream is also severely
4083	   congested.

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

4093	   When the "severe congestion detection" threshold per PHB
4094	   is not set equal to the maximum capacity allocated to one PHB then
4095	   this means that after the severe congestion situation is solved, the
4096	   ongoing flows will not be able to send their associated packets
4097	   up to a total rate equal to the maximum capacity associated to the
4098	   PHB, but only up to the "severe_congestion_threshold". When more than
4099	   one interior nodes located on the same communication path are severe
4100	   congested and when one of these interior node receives "encoded_DSCP"
4101	   marked packets then this interior node should not mark unmarked,
4102	   i.e., either "original DSCP" or "affected DSCP" or "notified DSCP""
4103	   encoded packets, up to a rate equal to the difference between the
4104	   maximum PHB capacity and the "severe congestion threshold", when the
4105	   incoming "encoded DSCP"" marked packets are already able to signal
4106	   this difference. In this case the "severe congestion threshold"
4107	   should be configured in all interior nodes, which are located in the
4108	   RMD domain, and equal to:

4110	  "severe_congestion_threshold" =
4111	   = Maximum PHB capacity - threshold_offset_rate
4112	   The threshold_offset_rate represents rate and should have the same
4113	   value in all interior nodes.

4115	   * before queuing and eventually dropping the packets, at the end of
4116	   each measurement interval of T seconds, calculate the current
4117	   estimated overloaded rate, say measured_overload_rate, by using the
4118	   following equation:

4120	   measured_overload_rate =
4121	   =((total_received_bytes)/T)-severe_congestion_restoration)

4123	   To provide reliable estimation of the encoded information several
4124	   techniques can be used, see [AtLi01], [AdCa03], [ThCo04], [AnHa06].
4125	   Note that since marking is done in interior nodes, the decisions are
4126	   made at egress nodes, and termination of flows are performed by
4127	   ingress nodes, there is a significant delay until the overload
4128	   information is learned by the ingress nodes, see Section 6 of
4129	   [CsTa05]). The delay consists of the trip time of data packets from
4130	   the severe congested interior node to the egress, the measurement
4131	   interval, i.e., T, and the trip time of the notification signaling
4132	   messages from egress to ingress. Moreover, until the overload
4133	   decreases at the severe congested interior node, an additional trip
4134	   time from the ingress node to the severe congested interior node must
4135	   expire. This is because immediately before receiving the congestion
4136	   notification, the ingress may have sent out packets in the flows that
4137	   were selected for termination. That is, a terminated flow may
4138	   contribute to congestion for a time longer that is taken from the
4139	   ingress to the interior node. Without considering the above, interior
4140	   nodes would continue marking the packets until the measured
4141	   utilization falls below the severe congestion restoration threshold.
4142	   In this way, at the end more flows will be terminated than necessary,
4143	   i.e., an over-reaction takes place. [CsTa05] provides a solution to
4144	   this problem, where the interior nodes use a sliding window memory to
4145	   keep track of the signaling overload in a couple of previous
4146	   measurement intervals. At the end of a measurement intervals, T,
4147	   before encoding and signaling the overloaded rate as "encoded DSCP"
4148	   packets, the actual overload is decreased with the sum of already
4149	   signaled overload stored in the sliding window memory, since that
4150	   overload is already being handled in the severe congestion handling
4151	   control loop. The sliding window memory consists of an integer number
4152	   of cells, i.e, n = maximum number of cells. Guidelines for
4153	   configuring the sliding window parameters are given in [CsTa05].

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

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

4163	   Sum_Mi =0
4164	   For i =1 to n
4165	   {
4166	   Sum_Mi = Sum_Mi + Mi
4167	   }

4169	   signaled_overload_rate = measured_overload_rate - Sum_Mi,

4171	   where Sum_Mi is calculated as above.

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

4177	   The bytes that have to be remarked to satisfy the signaled overload
4178	   rate: signaled_remarked_bytes, are calculated using the
4179	   following pseudo code:
4180	   IF severe_congestion_threshold <> Maximum PHB capacity
4181	   THEN
4182	    {
4183	     IF (incoming_encoded-DSCP_rate <> 0) AND
4184	        (incoming_encoded-DSCP_rate =< termination_offset_rate)
4185	     THEN
4186	        { signaled_remarked_bytes =
4187	         = ((signaled_overload_rate - incoming_encoded-DSCP_rate)*T)/N
4188	        }
4189	     ELSE IF (incoming_encoded-DSCP_rate > termination_offset_rate)
4190	     THEN signaled_remarked_bytes =
4191	         = ((signaled_overload_rate - termination_offset_rate)*T)/N
4192	     ELSE IF (incoming_encoded-DSCP_rate =0)
4193	     THEN signaled_remarked_bytes =
4194	         = signaled_overload_rate*T/N
4195	     }
4196	    ELSE signaled_remarked_bytes =  signaled_overload_rate *T/N

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

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

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

4214	   Note that when incoming remarked bytes are dropped, the operation of
4215	   the severe congestion algorithm may be affected, e.g., the algorithm
4216	   may become in certain situations slower. An implementation of the
4217	   algorithm may assure as much as possible that the incoming marked
4218	   bytes are not dropped. This could for example be accomplished by
4219	   using different dropping rate thresholds for marked and unmarked
4220	   bytes.

4222	   Note that when the "affected DSCP" marking is used by a node
4223	   that is congested due to a a severe congestion situation then all
4224	   the outgoing packets that are not marked (i.e., by using the "encoded
4225	   DSCP") have to be remarked using the "affected DSCP" marking.
4226	   Furthermore, note that when the congestion notification based on
4227	   probing is used in combination with severe congestion, then in
4228	   addition to the possible "encoded DSCP" and "affected DSCP" another
4229	   DSCP for the remarking of the same PHB is used, see Section 4.6.1.7.
4230	   This additional DSCP is denoted in this document as "notified
4231	   DSCP". When an interior node operates
4232	   in the severe congested state, see Figure A.2, and receives "notified
4233	   DSCP" packets, these packets are considered to be unmarked packets
4234	   (but not "affected DSCP" packets). This means that during severe
4235	   congestion also the "notified DSCP" packets can be remarked and
4236	   encoded as either "encoded DSCP" or "affected DSCP" packets.

4238	Appendix A.1.2 Example of a detailed severe congestion operation in the
4239	Egress nodes

4241	   The states of operation in Egress nodes are similar to the ones
4242	   described in  A.1.1. The definition of the events, see below, is
4243	   however different than the definition of the events given in Figure
4244	   A.1 and Figure A.2:

4246	   * event A: when the egress receives a predefined rate of "notified
4247	   DSCP" marked bytes/packets then event_A is activated, see Section
4248	   4.6.1.7 and A.2.2. The predefined rate of "notified DSCP" marked
4249	   bytes is denoted as the congestion notification detection threshold.
4250	   Note this congestion notification detection threshold can also be
4251	   zero, meaning that the event_A is activated when the egress node,
4252	   during an interval T, receives at least one "notified DSCP" packet.

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

4258	   * event C: this event occurs when the rate of incoming
4259	   "notified DSCP" packets decreases below the congestion notification
4260	   detection threshold. In the situation that the congestion
4261	   notification detection threshold is zero, this will mean that event C
4262	   is activated when the egress node, during an interval T, does not
4263	   receive any "notified DSCP" marked packets.

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

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

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

4278	   First, when the egress operates in the severe congestion state then
4279	   the total amount of remarked bandwidth associated with the PHB
4280	   traffic class, say total_congested_bandwidth, is calculated.
4281	   Note that when the node maintains information about
4282	   each ingress/egress pair aggregate, then the
4283	   total_congested_bandwidth must be calculated per ingress/egress pair
4284	   reservation aggregate. This bandwidth represents the severe congested
4285	   bandwidth that should be terminated. The total_congested_bandwidth
4286	   can be calculated as follows:

4288	   total_congested_bandwidth = N*input_remarked_bytes/T

4290	   Where, input_remarked_bytes represents the number of "encoded DSCP"
4291	   marked bytes that arrive at the egress, during one measurement
4292	   interval T, N is defined as in Section 4.6.1.6.2.1 and A.1.1. The
4293	   term denoted as terminated_bandwidth is a temporal variable
4294	   representing the total bandwidth that have to be terminated,
4295	   belonging to the same PHB traffic class. The
4296	   terminate_flow_bandwidth(priority_class) is the total of bandwidth
4297	   associated with flows of priority class equal to priority_class. The
4298	   parameter priority_class is an integer fulfilling

4300	   0 =< priority_class =< Maximum_priority.

4302	   The calculate_terminate_flows(priority_class) function determines the
4303	   flows for a given priority class and per PHB that has to be
4304	   terminated. This function also calculates the term
4305	   sum_bandwidth_terminate(priority_class), which is the sum of the
4306	   bandwith associated with the flows that will be terminated.
4307	   The constraint of finding the total number of flows that have to
4308	   be terminated is that sum_bandwidth_terminate(priority_class), should
4309	   be smaller or approximatelly equal to the variable
4310	   terminate_bandwidth(priority_class).

4312	     terminated_bandwidth = 0;
4313	     priority_class = 0;
4314	     while terminated_bandwidth < total_congested_bandwidth
4315	      {
4316	       terminate_bandwidth(priority_class) =
4317	       = total_congested_bandwidth - terminated_bandwidth
4318	       calculate_terminate_flows(priority_class);
4319	       terminated_bandwidth =
4320	       = sum_bandwidth_terminate(priority_class) + terminated_bandwidth;
4321	       priority_class = priority_class + 1;
4322	      }

4324	   If the egress node maintains ingress/egress pair reservation
4325	   aggregates, then the above algorithm is performed for each
4326	   ingress/egress pair reservation aggregate.

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

4331	   The predefined congestion notification threshold, see Appendix A.1.1,
4332	   is set according to, and usually less than, an engineered bandwidth
4333	   limitation, i.e., admission threshold, based on e.g. agreed Service
4334	   Level Agreement or a capacity limitation of specific links.
4335	   The difference between the congestion notification threshold and the
4336	   engineered bandwidth limitation, i.e., admission threshold, provides
4337	   an interval where the signaling information on resource limitation is
4338	   already sent by a node but the actual resource limitation is not
4339	   reached. This is due to the fact that data packets associated with an
4340	   admitted session have not yet arrived, while allows the admission
4341	   control process available at the egress to interpret the signaling
4342	   information and reject new calls before reaching congestion. Note
4343	   that in the situation when the data rate is higher than the
4344	   preconfigured congestion notification rate, also data packets are
4345	   re-marked, see section 4.6.1.6.2.1. To distinguish between congestion
4346	   notification and severe congestion, two methods may be used (see
4347	   Appendix 1.1.1):

4349	   * using different DSCP values (re-marked DSCP values). The remarked
4350	   DSCP that is used for this purpose is denoted as "notified DSCP" in
4351	   this document. When this method is used and when the interior node is
4352	   in "congestion notification" state, see A.1.1, then the node should
4353	   remark all the unmarked bytes passing through the node using the
4354	   "notified DSCP". Note that this method can only be applied if all
4355	   nodes in RMD domain use the "notified" DSCP marking. In this way,
4356	   also probe packets that will pass through the interior node that
4357	   operates in congestion notification state are being encoded using the
4358	   "notified DSCP" marking.

4360	   * Using the "encoded DSCP" marking for congestion notification and
4361	   severe congestion. This method is not described in detail in this
4362	   example appendix.

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

4367	   The admission control congestion notification procedure can be
4368	   applied only if the egress maintains the ingress/egress pair
4369	   aggregate. When the operation state of the ingress/egress pair
4370	   aggregate is the "congestion notification", see Appendix A.1.2, then
4371	   the implementation of the algorithm depends on how the congestion
4372	   notification situation is notified to the egress. As mentioned in
4373	   Section A.2.1, two methods are used:

4375	   * using the "notified DSCP". During a measurement interval T, the
4376	   egress counts the number of "notified DSCP" marked bytes that belong
4377	   to the same PHB and are associated with the same ingress/egress pair
4378	   aggregate, say input_notified_bytes. We denote the rate as
4379	   incoming_notified_rate.

4381	   * using the "encoded DSCP". In this case, during a measurement
4382	   interval T, the egress measures the input_notified_bytes by counting
4383	   the "encoded DSCP" bytes.

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

4387	   The incoming congestion_rate can be then calculated as follows:

4389	   incoming_congestion_rate = input_notified_bytes/T

4391	   If the incoming_congestion_rate is higher than a preconfigured
4392	   congestion notification threshold, then the communication path
4393	   between ingress and egress is considered to be congested. Note that
4394	   the pre-congestion notification threshold can be set to zero. In this
4395	   case the egress node will operate in congestion notification state at
4396	   the moment that it receives at least one "notified DSCP" encoded
4397	   packet.

4399	   When the egress node operates in "congestion notification" state
4400	   and if the end-to-end RESERVE (probe) arrives at the egress, then
4401	   this request SHOULD be rejected. Note that this is happening
4402	   only when the probe packet is either "notified DSCP" or "encoded
4403	   DSCP" marked. In this way it is ensured that the end-to-end RESERVE
4404	   (probe) packet passed through the node that it is congested. This
4405	   feature is very useful when ECMP based routing is used to detect
4406	   Only flows that are passing through the congested router.

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

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

4417	   When a severe congestion occurs on e.g., in the forward path, and
4418	   when the algorithm terminates flows to solve the severe congestion in
4419	   forward path, then the reserved bandwidth associated with the
4420	   terminated bidirectional flows is also released. Therefore, a careful
4421	   selection of the flows that have to be terminated should take place.
4422	   A possible method of selecting the flows belonging to the same
4423	   priority type passing through the severe congestion point on a
4424	   unidirectional path can be the following:

4426	   * the egress node should select, if possible, first unidirectional
4427	   flows instead of bidirectional flows
4428	   * the egress node should select, if possible, bidirectional flows
4429	   that reserved a relatively small amount of resources on the path
4430	   reversed to the path of congestion.

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

4435	   This scenario describes a solution using the combination of the
4436	   severe congestion solutions described in Section 4.6.2.5.2.
4437	   It is considered that the severe congestion occurs simultaneously on
4438	   forward and reverse directions, which may affect the same bi-
4439	   directional flows.

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

4450	QNE (Ingress)    NE (int.)    NE (int.)       NE (int.)    QNE (Egress)
4451	NTLP stateful                                             NTLP stateful
4452	data|    user        |                |           |               |
4453	--->|    data        | #unmarked bytes|           |               |
4454	    |--------------->S #marked bytes  |           |               |
4455	    |                S--------------------------->|               |
4456	    |                |                |           |-------------->|data
4457	    |                |                |           |               |--->
4458	    |                |                |           |              Term.?
4459	    |            NOTIFY               |           |               |Yes
4460	    |<------------------------------------------------------------|
4461	    |                |                |           |               |data
4462	    |                |                |  user     |               |<---
4463	    |   user data    |                |  data     |<--------------|
4464	    | (#marked bytes)|                S<----------|               |
4465	    |<--------------------------------S           |               |
4466	    | (#unmarked bytes)               S           |               |
4467	Term|<--------------------------------S           |               |
4468	Flow?                |                S           |               |
4469	YES |RESERVE(RMD-QSpec):              S           |               |
4470	    |"forward - T tear"               s           |               |
4471	    |--------------->|  RESERVE(RMD-QSpec):       |               |
4472	    |                |  "forward - T tear"        |               |
4473	    |                |--------------------------->|               |
4474	    |                |                S           |-------------->|
4475	    |                |                S         RESERVE(RMD-QSpec):
4476	    |                |                S       "reverse - T tear"  |
4477	    |      RESERVE(RMD-QSpec)         S           |<--------------|
4478	    |      "reverse - T tear"         S<----------|               |
4479	    |<--------------------------------S           |               |

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

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

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

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

4501	   * The ingress then calculates the bandwidth of the additional flows
4502	   that have to be terminated, say "additional_reverse_bandwidth", in
4503	   order to solve the severe congestion in reverse direction, by taking
4504	   into account:

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

4510	   **  the total amount of bandwidth in the reverse direction that has
4511	   been calculated by using the received marked packets, i.e.,
4512	   "marked_reverse_bandwidth".
4513	   This additional bandwidth can be calculated using the following
4514	   algorithm:

4516	    IF ("marked_reverse_bandwidth" > "notify_reverse_bandwidth") THEN
4517	    "additional_reverse_bandwidth" =
4518	     = "marked_reverse_bandwidth"- "notify_reverse_bandwidth";
4519	    ELSE
4520	    "additional_reverse_bandwidth" = 0

4522	* Ingress terminates the flows that experienced a severe congestion
4523	in the "forward" path and received a (severe congestion) NOTIFY
4524	   message

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

4531	   * If the number of required uni-directional flows (to satisfy the
4532	   above issue) is not available, then a number of bi-directional flows
4533	   that are using the same egress-ingress reverse direction
4534	   communication path MAY be selected for pre-emption in order to
4535	   satisfy the release of a total bandiwtdh equal up to the:
4536	   "additional_reverse_bandwidth".  Note that using the guidelines given
4537	   in Appendix A.3.1, first the bidirectional flows that reserved a
4538	   relatively small amount of resources on the path reversed to the path
4539	   of congestion should be selected for termination.

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

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

4549	   * The Ingress receives the NOTIFY message and reads the <PDR
4550	   Bandwidth> value included in the "PDR_Congestion_Report" container.
4551	   Note that this value is denoted as "notify_reverse_bandwidth" in the
4552	   situation that the QNE edges maintain per flow intra-domain QoS-NSLP
4553	   operational states, but is calculated differently. The variables
4554	   "marked_reverse_bandwidth" and "additional_reverse_bandwidth are
4555	   calculated using the same steps as explained for the situation that
4556	   the QNE edges maintain per flow intra-domain QoS-NSLP states.

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

4563	   The RMD aggregated (reduced state) reservations maintained by the
4564	   interior nodes, can be reduced in the "forward" and "reverse"
4565	   directions by using the procedure described in Section 4.6.2.3 and
4566	   including in the  <Bandwith> parameter within the "RMD-QOSM QOS
4567	   Description" field carried by the "forward" intra-domain RESERVE the
4568	   value equal to "notify_reverse_bandwidth" and by including the
4569	   "additional_reverse_bandwidth" value in the <PDR Bandwidth> parameter
4570	   within the "PDR_Release_Request" container that is carried by the
4571	   same intra-domain RESERVE message.

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

4575	   This section describes the mechanism that can be supported by the
4576	   QNE Ingress, QNE Interior and QNE Egress nodes to satisfy
4577	   pre-emption during the admission control process.
4578	   This mechanism uses the pre-emption building blocks specified in
4579	   [QoS-NSLP].

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

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

4587	Step_1:

4589	  The QNE Ingress MUST send a tearing RESERVE downstream and add a
4590	  BOUND_SESSION_ID, with Binding_Code value equal to "Indicated session
4591	  caused pre-emption" that indicates the SESSION_ID of the session that
4592	  caused the pre-emption. Furthermore, an INFO-SPEC object with error
4593	  code value equal to "Reservation pre-empted" has to be included in
4594	  each of these tearing RESERVE messages..
4595	  The selection of which flows have to be preempted can be based on
4596	  predefined policies. For example, this selection process can be based
4597	  on the MRI associated with the high and low priority sessions. In
4598	  particular, the QNE Ingress can select low(er) priority session(s)
4599	  where their MRI is "close" (especially the target IP) to the one
4600	  associated with the higher priority session. This means that
4601	  typically the high priority session and the to be preempted lower
4602	  priority sessions are following the same communication path and are
4603	  passing through the same QNE Egress node.

4605	  Furthermore, the amount of lower priority sessions that have to be
4606	  pre-empted per each high priority session, has to be such that the
4607	  requested resources by the higher priority session should be lower or
4608	  equal than the sum of the reserved resources associated with the lower
4609	  priority sessions that have to be pre-empted.

4611	Step_2:

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

4617	Step_3:

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

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

4625	  The QNE Interior upon receiving the first (tearing) RESERVE that
4626	  carries the BOUND_SESSION_ID object with Binding_Code value
4627	  equal to "Indicated session caused pre-emption" and an INFO-SPEC
4628	  object with error code value equal to "Reservation
4629	  preempted" it considers that this session has to be pre-empted.
4630	  In this case the QNE Interior creates a so called "pre-emption state",
4631	  which is identified by the SESSION_ID carried in the pre-emption
4632	  related BOUND_SESSION_ID object. Furthermore, this "pre-emption state"
4633	  will include the SESSION_ID of the session associated with the
4634	  (tearing) RESERVE. If subsequently additional tearing RESERVE(s) are
4635	  arriving including the same values of BOUND_SESSION_ID and INFO-SPEC
4636	  objects, then the associated SESSION_IDs of these (tearing) RESERVE
4637	  message will be included in the already created "pre-emption state".
4638	  The QNE will then set a timer, with a value that is high enough to
4639	  ensure that it will not expire before the (reserving) RESERVE arrives.
4640	  Note that when the "pre-emption state" timer expires then the
4641	  bandwidth associated with the pre-empted session(s) will have to be
4642	  released, following a normal RMD-QOSM bandwidth release procedure..
4643	  If the QNE interior node will not receive the all to be pre-empted
4644	  (tearing) RESERVE messages sent by the QNE Ingress before their
4645	  associated (reserving) RESERVE message arrives, then the (reserving)
4646	  RESERVE message will not reserve any resources and this message will
4647	  be "M" marked, see Section 4.6.1.2. Note that this situation is not a
4648	  typical situation. Typically, this situation can only occur when at
4649	  least one of (tearing) RESERVe messages are dropped due to an error
4650	  condition.

4652	  Otherwise, if the QNE Interior receives the all to be pre-empted
4653	  (tearing) RESERVE messages sent by the QNE Ingress, then the QNE
4654	  Interior will remove the pending resources, and make the new
4655	  reservation using normal RMD-QOSM bandwidth release and reservation
4656	  procedures.

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

4660	  Similar to the QNE Interior operation, the QNE Egress upon receiving
4661	  the first (tearing) RESERVE that carries the BOUND_SESSION_ID object
4662	  with Binding_Code value equal to "Indicated session caused
4663	  pre-emption" and an INFO-SPEC object with error code value equal to
4664	  "Reservation preempted" it considers that this session has to be pre-
4665	  empted. Similar to the QNE Interior operation the QNE Egress creates a
4666	  so called "pre-emption state", which is identified by the SESSION_ID
4667	  carried in the pre-emption related BOUND_SESSION_ID object. This "pre-
4668	  emption state" will store the same type of information and use the
4669	  same timer value as specified in section A.4.2.

4671	   If subsequently additional tearing RESERVE(s) are
4672	   arriving including the same values of BOUND_SESSION_ID and INFO-SPEC
4673	   objects, then the associated SESSION_IDs of these (tearing) RESERVE
4674	   message will be included in the already created "pre-emption state".
4675	   If the (reserving) RESERVE sent by the QNE Ingress node arrived and
4676	   is not "M" marked and if all the to be pre-empted (tearing) RESERVE
4677	   messages arrived then the QNE Egress will remove the pending
4678	   resources and make the new reservation using normal RMD-QOSM
4679	   procedures.

4681	   If the QNE Egress receives a "M" marked RESERVE message then the QNE
4682	   Egress will use the normal partial RMD-QOSM procedure to release the
4683	   partial reserved resources associated with the "M" marked RESERVE,
4684	   see Section 4.6.1.2.

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

4691	 * If the QNE Egress uses an end-to-end QOSM supports the pre-emption
4692	   handling then the QNE Egress have to calculate and select new
4693	   lower priority sessions that have to be terminated. The way of how
4694	   the to be pre-empted sessions are selected and signalled to the
4695	   downstream QNEs is similar to the operation specified in Section
4696	   A.4.1.
4697	 * If the QNE Egress does not use an end-to-end QOSM that supports
4698	   the pre-emption handling then the QNE Egress has to reject the
4699	   requesting (reserving) RESERVE associated with the high priority
4700	   session, see Section 4.6.1.2.

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

4707	A.5 Retransmission procedure within the RMD domain

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

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

4722	   Phase 1: Create Replay Cache Entry

4724	   When an Interior node receives an intra-domain RESERVE
4725	   message and its cache is empty or there is no matching entry, it
4726	   reads the <Container ID> field of the "PHR container" of the received
4727	   message. If the <Container ID> is a PHR_RESOURCE_REQUEST, which
4728	   indicates that the intra-domain Reserve message is a reservation
4729	   request, then the QNE Interior node creates a new entry in the cache
4730	   and copies the <RSN>, <SESSION_ID> and <Container ID> to the entry
4731	   and sets the <REFRESH_PERIOD>.
4732	   By using the information stored in the List the Interior node
4733	   verifies whether the received intra-domain RESERVE message is sent
4734	   by an adversary or not. For example, if the
4735	   <SESSION_ID> and <RSN> of a received intra-domain RESERVE message
4736	   match the values stored in the List then the Interior node checks the
4737	   <Container ID> part.

4739	   If the <Container_ID> is different then:

4741	     Situation D1: <Container ID> in its own list is
4742	        PHR_RESOURCE_REQUEST, and <Container ID> in the message is
4743	        PHR_REFRESH_UPDATE;

4745	     Situation D2: <Container ID> in its own list is
4746	        PHR_RESOURCE_REQUEST or PHR_REFRESH_UPDATE, and <Container ID>
4747	        in the message is PHR_RELEASE_REQUEST;

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

4752	    For Situation D1, the QNE Interior node processes this message by
4753	    RMD-QoSM default operation, reserves bandwidth, updates the entry
4754	    and passes the message to downstream nodes. For Situation D2, the
4755	    QNE Interior node processes this message by RMD-QoSM default
4756	    operation, releases bandwidth, deletes all entries associated with
4757	    the session and passes the message to downstream nodes. For
4758	    situation D3, the QNE Interior node does not use/process the
4759	    <Bandwidth> parameter carried by the received intra-domain RESERVE
4760	    message. Furthermore, the <K> flag in the "PHR Container"
4761	    have to be set such that the <Bandwidth> parameter carried by the
4762	    intra-domain RESERVE message is not processed/used by a QNE
4763	    Interior node.

4765	    If the <Container_ID> is the same then:

4767	     Situation S1: <Container ID> is equal to PHR_RESOURCE_REQUEST;
4768	     Situation S2: <Container ID> is equal to PHR_REFRESH_UPDATE;
4769	     For situation S1, the QNE Interior node does not process the
4770	     intra-domain RESERVE message but it just passes it to
4771	     downstream nodes, because
4772	     it might have been retransmitted by the QNE Ingress node;
4773	     For situation S2, the QNE Interior node processes the first
4774	     incoming intra-domain (refresh) RESERVE message within a refresh
4775	     period and updates the entry and forwards it to the downstream
4776	     nodes.

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

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

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

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

4796	     If the <RSN> in the message is equal to <RSN-1> in the
4797	     stored list and the <Container ID> is a PHR_RELEASE_REQUEST
4798	     then the received intra-domain RESERVE message has to be
4799	     interpreted and processed as a typical (tearing) RESERVE
4800	     message, which is caused by rerouting, see Section 5.2.5.2 in
4801	     [QoS-NSLP].

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

4809	    Phase 2: Update Replay Cache Entry

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

4816	    Phase 3: Delete Replay Cache Entry

4818	    When a QNE Interior node receives an intra-domain (tear) RESERVE
4819	    message and an entry in the replay cache can be found, then the
4820	    QNE Interior node will delete this entry after processing the
4821	    message. Furthermore, the Interior node will delete cache entries,
4822	    if it did not receive an intra-domain (refresh) Reserve message
4823	    during the <REFRESH_PERIOD> period with a <Container_ID> value equal
4824	    to PHR_REFRESH_UPDATE.