idnits 2.17.1 

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

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

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

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

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

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

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

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

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

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


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

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


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

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

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     RFC 2119 keyword, line 295: '... RMD-QOSM domain MAY contain Interior ...'
     RFC 2119 keyword, line 298: '...f these NSIS unaware nodes MAY be used...'
     RFC 2119 keyword, line 488: '...curs.  Congested Interior nodes SHOULD...'
     RFC 2119 keyword, line 494: '...d %.  Overload % SHOULD be higher than...'
     RFC 2119 keyword, line 496: '...ode then Overload % SHOULD be updated....'
     (128 more instances...)


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

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

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'SHOULD not' in this paragraph:
     
     When a measurement-based node receives a local RESERVE message, it
     compares the requested resources to the available resources (maximum
     allowed minus current load) for the requested PHR group.  If there are
     insufficient resources, it sets the <M> bit in the RMD-QSpec. No change
     to the RMD-QSpec is made when there are sufficient resources.  In either
     case, the node then forwards the RESERVE along the path towards the
     destination.  REFRESH and RELEASE messages are not normally generated in
     the measurement-based mode, but if received SHOULD not be processed and
     forwarded unchanged.

  == 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:
     
     *  the SCOPING flag SHOULD not be set, meaning that a default
     scoping of the message is used.  Therefore, the QNE edges MUST be
     configured as boundary nodes and the QNE Interior nodes MUST be
     configured as Interior (intermediary) nodes;

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     The QNE Interior node detecting severe congestion marks data
     packets passing the node in which the severe congestion was detected. For
     the severe congestion marking, two additional DSCPs SHOULD be allocated
     for each traffic class.  One MAY be used to indicate that the packet
     passed a congested node.  The other DSCP MUST be used to indicate the
     degree of congestion by marking the bytes proportionally to the degree of
     congestion.  Note however, that it is RECOMMENDED that the total number
     of additional DSCPs within a RMD domain, needed for severe congestion
     handling MUST not exceed the limit of 16.

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

  -- The document date (June 15, 2005) is 6888 days in the past.  Is this
     intentional?


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

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

  == Missing Reference: 'RFC 3175' is mentioned on line 1164, but not defined

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

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

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

  == Outdated reference: A later version (-18) exists of
     draft-ietf-nsis-qos-nslp-05

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

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

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

  == Outdated reference: A later version (-20) exists of
     draft-ietf-nsis-ntlp-04

  == Outdated reference: A later version (-01) exists of
     draft-tschofenig-rsvp-doi-00


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

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

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

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

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

15	Status of this Memo

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

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

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

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

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

38	   This Internet-Draft will expire on December 15, 2005.

40	Copyright Notice

42	   Copyright (C) The Internet Society (2005).

44	Abstract

46	   This document describes an NSIS QoS Model for networks that use the
47	   Resource Management in Diffserv (RMD) concept.  RMD is a technique
48	   for adding admission control to Differentiated Services (Diffserv)
49	   networks.  RMD complements the Diffserv architecture by pushing
50	   complex classification, conditioning and admission control functions
51	   to the edges of a Diffserv domain and simplifying the operation of
52	   internal nodes.  The RMD QoS Model allows devices external to the
53	   RMD network to signal reservation requests to edge nodes in the RMD
54	   network. The RMD Ingress edge nodes classify the incoming flows into
55	   traffic classes and signals resource requests for the corresponding
56	   traffic class along the data path to the Egress edge nodes for each
57	   flow.  Egress nodes reconstitute the original requests and continue
58	   forwarding them along the data path towards the final destination.

60	Table of Contents

62	   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
63	   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3
64	   3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .4
65	      3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4
66	      3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 6
67	          3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .6
68	          3.2.2 RMD-QOSM signaling . . . . . . . . . . . . . . . . 7
69	   4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . .8
70	      4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . . 8
71	          4.1.1 RMD-QOSM QoS Description . . . . . . . . .  . . . .9
72	          4.1.2 PHR RMD-QOSM control information . . . . . . . . . 9
73	          4.1.3 PDR RMD-QOSM control information  . . . . . . . . 11
74	          4.1.4 Mapping of QSpec parameters onto generic
75	                QSpec Parameters . . . . . . . . . . . . . . . . .12
76	      4.2 Message format . . . . . . . . . . . . . . . . . . . . .13
77	      4.3 RMD node state management . . . . . . . . . . . . . . . 14
78	          4.3.1 Aggregated versus per flow reservations at the
79	                QNE edges . . . . . . . . . . . . . . . . . . . . 14
80	          4.3.2 Measurement-based method . . . . . . . . . . . . .15
81	          4.3.3 Reservation-based method . .. . . . . . . . . . . 15
82	      4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .16
83	      4.5 Edge discovery and addressing of messages . . . . . . . 16
84	      4.6 Operation and sequence of events . . . . . . . . . . . .16
85	          4.6.1 Basic unidirectional operation . . . . . . . . . .17
86	             4.6.1.1 Successful reservation. . . . . . . . . . . .17
87	             4.6.1.2 Unsuccessful reservation . . . . . . . . . . 21
88	             4.6.1.3 RMD refresh reservation. . . . . . . . . . . 23
89	             4.6.1.4 RMD modification of aggregated reservation . 27
90	             4.6.1.5 RMD release procedure. . . . . . . . . . . . 27
91	             4.6.1.6 Severe congestion handling  . . . . . . . . .33
92	          4.6.2 Bidirectional operation . . . . . . . . . . . . . 36
93	             4.6.2.1 Successful and unsuccessful reservation . . .38
94	             4.6.2.2 Refresh reservation . . . . . . . . . . . . .41
95	             4.6.2.3 Modification of aggregated reservation . . . 42
96	             4.6.2.4 Release procedure . . . . . . . . . . . . . .43
97	      4.7 Handling of additional errors . . . . . . . . . . . . . 46
98	   5. Security Consideration. . . . . . . . . . . . . . . . . . . 46
99	   6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .48
100	   7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .48
101	      7.1 Explicit congestion notification . . . . . . . . . . . .48
102	   8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .48
103	   9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 49
104	   10. Normative References . . . . . . . . . . . . . . . . . . . 50
105	   11. Informative References . . . . . . . . . . . . . . . . . . 50
106	   12. Intellectual Property Rights . . . . . . . . . . . . . . . 51

108	1.  Introduction

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

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

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

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

148	FIGURE 1: Actors in the RMD QOSM

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

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

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

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

171	2.  Terminology

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

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

180	   In addition, the following terms are used:

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

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

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

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

194	3.  Overview of RMD and RMD-QOSM

196	3.1.  RMD

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

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

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

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

234	   In RMD two basic admission control modes are described: measurement-
235	   based and reservation-based admission control.  The measurement-
236	   based algorithm continuously measures traffic levels and the actual
237	   available resources, and admits flows whose resource needs are
238	   within what is available at the time of the request.  Once
239	   an admission decision is made, no record of the decision need be
240	   kept.  The advantage of measurement-based resource management
241	   protocols is that they do not require pre-reservation state or
242	   explicit release of the reservations.  Moreover, when the user
243	   traffic is variable, measurement based admission control could
244	   provide higher network utilization than, e.g., peak-rate
245	   reservation.  However, this can introduce an uncertainty in the
246	   availability of the resources.

248	   With the reservation-based method, each Interior node maintains
249	   only one reservation state per traffic class.  The Ingress edge
250	   nodes aggregate individual flow requests into classes, and signal
251	   changes in the class reservations as necessary.  The reservation is
252	   quantified in terms of resource units.  These resources are
253	   requested dynamically per PHB and reserved on demand in all nodes in
254	   the communication path from an Ingress node to an Egress node.

256	   RMD describes the following procedures:

258	   * classification of individual resource reservation or resource
259	     query into Per Hop Behavior groups (PHB) at the Ingress node of
260	     the domain,

262	   * hop-by-hop admission control based on per PHB within the
263	     domain. There are two possible modes of operation for internal
264	     nodes to admit requests. One mode is the stateless or
265	     measurement-based mode, where the resources within the domain are
266	     queried. Another mode of operation is the reduced-state
267	     reservation or reservation based mode, where the resources within
268	     the domain are reserved.

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

273	   * a congestion control algorithm that is able to terminate the
274	     appropriate number of flows in case a of congestion due to a
275	     sudden failure (e.g., link, router) within the domain.

277	3.2. Basic features of RMD-QOSM

279	3.2.1 Role of the QNEs

281	   The protocol model of the RMD-QOSM is shown in Figure 2.  The figure
282	   shows QNI and QNR nodes, not part of the RMD network, that are the
283	   ultimate initiator and receiver of the QoS reservation requests.  It
284	   also shows QNE nodes that are the Ingress and Egress nodes in the
285	   RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are
286	   Interior nodes (QNE Interior).

288	   All nodes of the RMD domain are QoS-NSLP aware nodes.  Edge nodes
289	   store and maintain QoS-NSLP and NTLP states and therefore are
290	   stateful nodes.  The Interior nodes are NTLP stateless. Furthermore
291	   they are either QoS-NSLP stateless (for measurement-based
292	   operation), or are reduced state nodes storing per PHB aggregated
293	   QoS-NSLP states (for reservation-based operation).

295	   Note that the RMD-QOSM domain MAY contain Interior nodes that are
296	   not NSIS aware nodes (not shown in the figure).  These nodes are
297	   assumed to have sufficient capacity for flows that might be
298	   admitted.  Furthermore, some of these NSIS unaware nodes MAY be used
299	   for measuring the traffic congestion level on the data path. These
300	   measurements can be used by RMD-QOSM in the severe congestion
301	   operation (see Section 4.6.1.6).

303	     |------|   |-------|                           |------|   |------|
304	     | e2e  |<->| e2e   |<------------------------->| e2e  |<->| e2e  |
305	     | QoS  |   | QoS   |                           | QoS  |   | QoS  |
306	     |      |   |-------|                           |------|   |------|
307	     |      |   |-------|   |-------|   |-------|   |------|   |      |
308	     |      |   | local |<->| local |<->| local |<->| local|   |      |
309	     |      |   | QoS   |   |  QoS  |   |  QoS  |   |  QoS |   |      |
310	     |      |   |       |   |       |   |       |   |      |   |      |
311	     | NSLP |   | NSLP  |   | NSLP  |   | NSLP  |   | NSLP |   | NSLP |
312	     |st.ful|   |st.ful |   |st.less|   |st.less|   |st.ful|   |st.ful|
313	     |      |   |       |   |red.st.|   |red.st.|   |      |   |      |
314	     |      |   |-------|   |-------|   |-------|   |------|   |      |
315	     |------|   |-------|   |-------|   |-------|   |------|   |------|
316	     ------------------------------------------------------------------
317	     |------|   |-------|   |-------|   |-------|   |------|   |------|
318	     | NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP |<->|NTLP  |
319	     |st.ful|   |st.ful |   |st.less|   |st.less|   |st.ful|   |st.ful|
320	     |------|   |-------|   |-------|   |-------|   |------|   |------|
321	       QNI         QNE        QNE         QNE          QNE       QNR
322	     (End)  (Ingress) (Interior)  (Interior) (Egress)  (End)

324	         st.ful: stateful, st.less: stateless
325	         st.less red.st.: stateless or reduced state

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

329	3.2.2 RMD-QOSM signaling

331	   The basic RMD-QOSM signaling is shown in Figure 3.  A RESERVE
332	   message is created by a QNI with an Initiator QSpec describing the
333	   reservation and forwarded along the path towards the QNR.  When the
334	   original RESERVE message arrives at the Ingress node, an RMD-QSpec
335	   is constructed based on the top-most QSPEC in the message (usually
336	   the Initiator QSPEC).  The RMD-QSpec is sent in a local, independent
337	   RESERVE message through the Interior nodes towards the QNR. This
338	   local RESERVE message uses the NTLP hop-by-hop datagram signaling
339	   mechanism.  Meanwhile, the original RESERVE message is sent to the
340	   Egress node on the path to the QNR using the reliable transport mode
341	   of NTLP.

343	   Each QoS NSLP node on the data path processes the local RESERVE
344	   message and checks the availability of resources with either the
345	   reservation-based or the measurement-based method.  When the message
346	   reaches the Egress node, and the reservation is successful in each
347	   Interior nodes, the original RESERVE message is forwarded to the
348	   next domain.  When the Egress node receives a RESPONSE message from
349	   the downstream end, it is forwarded directly to the Ingress node.

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

356	              QNE             QNE             QNE            QNE
357	            Ingress         Interior        Interior        Egress
358	        NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
359	               |               |               |              |
360	       RESERVE |               |               |              |
361	      -------->| RESERVE       |               |              |
362	               +--------------------------------------------->|
363	               | RESERVE'      |               |              |
364	               +-------------->|               |              |
365	               |               | RESERVE'      |              |
366	               |               +-------------->|              |
367	               |               |               | RESERVE'     |
368	               |               |               +------------->|
369	               |               |               |              | RESERVE
370	               |               |               |              +------->
371	               |               |               |              |RESPONSE
372	               |               |               |              |<-------
373	               |               |               |     RESPONSE |
374	               |<---------------------------------------------+
375	       RESPONSE|               |               |              |
376	      <--------|               |               |              |

378	   Figure 3: Sender-initiated reservation with Reduced State Interior
379	             Nodes

381	   As a consequence in the stateless/reduced state domain only sender-
382	   initiated reservation can be performed and functions requiring per
383	   flow NTLP or QoS-NSLP states, like summary refreshes, cannot be
384	   used. One of the basic features of RMD is that, if per flow
385	   identification, is needed, i.e. associating the flows IDs for the
386	   reserved resources, Edge nodes act on behalf of Interior nodes.

388	4.  RMD-QOSM, Detailed Description

390	   This section describes RMD-QOSM in more detail.  In particular,
391	   it defines the role of stateless and reduced-state QNEs, the
392	   RMD-QOSM QSpec Object, the format of RMD-QOSM QoS-NSLP messages
393	   and how QSpecs are processed and used in different protocol
394	   operations.

396	4.1.  RMD-QSpec Definition

398	   The RMD-QOSM QSpec object contains three fields, the "RMD-QOSM QoS
399	   Description", the Per Hop Reservation "PHR RMD-QOSM control
400	   information" container (PHR container) and the Per Domain Reservation
401	   "PDR RMD-QOSM control information" container (PDR container). The
402	   "RMD-QOSM QoS Description" field and the "PHR RMD-QOSM control
403	   information" container are used and processed by edge and Interior
404	   nodes.  The "PDR RMD-QOSM control information" container field is
405	   only processed by edge nodes.  The "PHR RMD-QOSM control
406	   information" container contains the QoS specific control information
407	   for intra-domain communication and reservation.  The "PDR RMD-QOSM
408	   control information" container contains additional information that
409	   is needed for edge-to-edge communication.

411	4.1.1.  RMD-QOSM QoS Description

413	   This section describes the parameters used by the "RMD-QOSM QoS
414	   Description" field.  The RMD-QOSM QoS Description only contains the
415	   QoS Desired object [QSP-T]. It does not contain the QoS
416	   Available, QoS Reserved or Minimum QoS objects.

418	   <RMD-QOSM QoS Description> = <QoS Desired>

420	   <QoS Desired> = <Bandwidth> <PHB-CLASS>

422	   The bit format of the <Bandwidth> and <PHB-CLASS> conform to the
423	   bit format specified in [QSP-T] and can be seen in Figure 4 and
424	   Figure 5, respectively.

426	     0                   1                   2                   3
427	     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
428	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
429	    | Object ID = 1 |Parameter-ID=1 | Length = 5    | Empty         |
430	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
431	    |  Bandwidth       (32-bit IEEE floating point number)          |
432	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

434	             Figure 4: Bandwidth parameter

436	     0                   1                   2                   3
437	     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
438	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
439	    | Object ID = 1 |Parameter-ID=9 | Length = 1    | DSCP          |
440	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

442	             Figure 5: PHB_Class parameter

444	4.1.2.  PHR RMD-QOSM control information container (PHR container)

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

448	   <PHR RMD-QOSM control information> = <Overload %>, <S>,<M>,
449	   <Admitted Hops>, <B>, <Hop_U> <Time Lag>

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

454	     0                   1                   2                   3
455	     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
456	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
457	    | Object ID = 0 |Control_Type   | Length = 5    |   Overload %  |
458	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459	    |S|M| Admitted  Hops|B|U| Time  Lag     |  Empty                |
460	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

462	        Figure 6: PHR container

464	   Parameter/Container ID:
465	   8 bit field, indicating the PHR type: PHR_Resource_Request,
466	   PHR_Release_Request, PHR_Refresh_Update.  It is used to further
467	   specify QoS-NSLP RESERVE and RESPONSE messages.

469	   "PHR_Resource_Request" (Parameter/Container ID = 1): initiate or
470	   update the traffic class reservation state on all nodes located on
471	   the communication path between the QNE(Ingress) and
472	   QNE(Egress) nodes.

474	   "PHR_Refresh_Update" (Parameter/Container ID = 2): refresh the
475	   traffic class reservation soft state on all nodes located on the
476	   communication path between the QNE(Ingress) and QNE(Egress)
477	   nodes according to a resource reservation request that was
478	   successfully processed during a previous refresh period.

480	   "PHR_Release_Request" (Parameter/Container ID = 3): explicitly
481	   release, by subtraction, the reserved resources for a particular flow
482	   from a traffic class reservation state.

484	   <S> (Severe Congestion):
485	   1 bit.  In case of a route change refreshing RESERVE messages
486	   follow the new data path, and hence resources are requested
487	   there.  If the resources are not sufficient to accommodate the new
488	   traffic sever congestion occurs.  Congested Interior nodes SHOULD
489	   notify edge QNEs about the congestion, which is done by setting the
490	   S bit.

492	   <Overload %>:
493	   8 bits In case of severe congestion the level of overload is
494	   indicated by the Overload %.  Overload % SHOULD be higher than 0 if
495	   S bit is set.  If overload in a node is greater than the overload
496	   in a previous node then Overload % SHOULD be updated.

498	   <M>:
499	   1 bit.  In case of unsuccessful resource reservation or resource
500	   query in an Interior QNE, this QNE sets the M bit in order to
501	   notify the Egress QNE.

503	   <Admitted Hops>:
504	   8 bit field.  The <Admitted Hops> counts the number of hops in the
505	   RMD domain where the reservation was successful.  The <Admitted
506	   Hops>is set to "0" when a RESERVE message enters a domain and
507	   increased by one at each Interior QNE.  However when a QNE that does
508	   not have sufficient resources to admit the reservation is reached,
509	   the M Bit is set, and the <Admitted Hops> value is frozen.

511	   <Hop_U> (NSLP_Hops unset):
512	   1-bit. The QNE(Ingress) node MUST set the <Hop_U> parameter to
513	   0.  This parameter MAY be set to "1" by a node when the node will
514	   not increase the <Admitted Hops> value. This is the case when an
515	   RMD-QOSM reservation-based node is not admitting the reservation
516	   request. When <Hop_U> is set "1" the <Admitted Hops> SHOULD NOT be
517	   changed.

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

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

524	4.1.3.  PDR RMD-QOSM control information container (PDR container)

526	   This section describes the parameters of the PDR container.

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

530	   <PDR RMD-QOSM control information> = <Overload %>  <S> <M> <Max
531	   Admitted Hops> <B> [<PDR Reverse Requested Resources>]

533	   The bit format of the PDR container can be seen in Figure 7. Note
534	   that in Figure 7 <Max Admitted Hops> is represented as
535	   <Max Adm Hops>.

537	       0                   1                   2                   3
538	       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
539	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540	      | Object ID = 0 |Control_Type   | Length = 9    | Overload %    |
541	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
542	      |S|M| Max Adm  Hops |B| Empty                                   |
543	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
544	      |PDR Reverse Requested Resources(32-bit IEEE floating p.number) |
545	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

547	        Figure 7: PDR container

549	   Parameter/Container ID:

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

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

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

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

566	   "PDR_Reservation_Report" (Parameter/Container ID = 7): generated and
567	   sent by the QNE(Egress) node to the QNE(Ingress) node to
568	   report that a "PHR_Resource_Request" and a
569	   "PDR_Reservation_Request" control information fields have been
570	   received and that the request has been admitted or rejected

572	   "PDR_Refresh_Report" (Parameter/Container ID = 8) generated and sent
573	   by the QNE(Egress) node in case needed, to the QNE(Ingress) node
574	   to report that a "PHR_Refresh_Update" control information
575	   field has been received and has been processed

577	   "PDR_Release_Report" (Parameter/Container ID = 9) generated and sent
578	   by the QNE(Egress) node in case needed, to the QNE(Ingress) node
579	   to report that a "PHR_Release_Request" and a
580	   "PDR_Release_Request" control information fields have been
581	   received and have been processed.

583	   "PDR_Congestion_Report" (Parameter/Container ID = 10): generated and
584	   sent by the QNE(Egress) node to the QNE(Ingress) node and used for
585	   Severe congestion notification

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

592	   <Overload %>:
593	   8-bit.  It includes the Overload % of the
594	   "PHR_Resource_Request" or "PHR_Refresh_Update" control
595	   information fields, indicating the level of overload to the Ingress
596	   node.

598	   <M> (PDR Marked):
599	   1-bit.  Carries the <M> value of the "PHR_Resource_Request" or
600	   "PHR_Refresh_Update" control information fields.

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

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

609	   <PDR Reverse Requested Resources>
610	   32 bits.  This field only applies when the "B" flag is set to
611	   "1".  It specifies the requested number of units of resources
612	   that have to be reserved by a node in the reverse direction
613	   when the intra-domain signaling procedures require a bi-
614	   directional reservation procedure.

616	4.2.  Message format

618	   The format of the messages used by the RMD-QOSM complies with the
619	   QoS-NSLP specification.  As specified in [QoS-NSLP], for each
620	   QoS-NSLP message type, there is a set of rules for the permissible
621	   choice of object types.  These rules are specified using Backus-Naur
622	   Form (BNF) augmented with square brackets surrounding optional
623	   sub-sequences.  The BNF implies an order for the objects in a
624	   message.  However, in many (but not all) cases, object order makes no
625	   logical difference.  An implementation SHOULD create messages with
626	   the objects in the order shown here, but accept the objects in any
627	   permissible order.

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

632	   RESERVE = COMMON_HEADER
633	           RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
634	           [ POLICY_DATA ] [ RMD-QSPEC]

636	   The format of a Query message used by the RMD-QOSM is as follows:

638	   QUERY = COMMON_HEADER
639	              [ RII ][ BOUND_SESSION_ID ]
640	              [ POLICY_DATA ] [ RMD-QSPEC ]

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

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

649	   intra-domain RESPONSE = COMMON_HEADER
650	                 [ RII / RSN ] ERROR_SPEC
651	                 [ RMD-QSPEC ]

653	   The format of an end-to-end RESPONSE message that is used by the
654	   RMD-QOSM to carry an intra-domain RESPONSE message is as follows:

656	   RESPONSE = COMMON_HEADER
657	                 [ RII / RSN ] ERROR_SPEC [ RMD-QSPEC ] [ *QSPEC ]

659	   The format of a NOTIFY message used by the
660	   RMD-QOSM is as follows:

662	   NOTIFY = COMMON_HEADER ERROR_SPEC [ RMD-QSPEC ]

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

666	4.3.  RMD node state management

668	   The QoS-NSLP state creation and management is specified in
669	   [QoS-NSLP].  This section describes the state creation and
670	   management functions of the Resource Management Function (RMF) in
671	   the RMD nodes.

673	4.3.1 Aggregated versus per flow reservations at the QNE edges

675	   The QNE edges maintain for the RMD QoS model either per flow, or
676	   aggregated QoS-NSLP reservation states.  Each per flow or aggregated
677	   QoS-NSLP reservation state, associated with the RMD-QOS model, is
678	   identified by a NTLP SESSION_ID (see [GIMPS]).  In RMD, these states
679	   are denoted as PDR states.

681	   In the situation where the QNE edges maintain per aggregated QoS-
682	   NSLP reservation states then these states will have to maintain the
683	   SESSION_ID of the aggregated state, the IP addresses of the Ingress
684	   and Egress nodes, the PHB value and the size of the aggregated
685	   reservation, e.g., reserved bandwidth.

687	   The size of the aggregation is defined as it is specified in Section
688	   1.4.4 of [RFC 3175].  The size of the aggregated reservations needs
689	   to be greater or equal to the sum of bandwidth of the inter domain
690	   (end-to-end) reservations it aggregates.  Some policy can be used
691	   to maintain the amount of required bandwidth on a given aggregated
692	   reservation by taking into account the sum of the underlying inter
693	   domain (end-to-end) reservations, while endeavoring to change
694	   reservation less frequently.  This MAY require a trend analysis.
695	   If there is a significant probability that in the next interval of
696	   time the current aggregated reservation is exhausted, the Ingress
697	   router MUST predict the necessary bandwidth and request it.  If the
698	   Ingress router has a significant amount of bandwidth reserved but
699	   has very little probability of using it, the policy MAY predict the
700	   amount of bandwidth required and release the excess.  To increase or
701	   decrease the aggregate, the RMD modification procedures SHOULD be
702	   used (see Section 4.6.1.4).

704	4.3.2  Measurement-based method

706	   QNE Interior nodes operating in measurement-based mode are QoS-NSLP
707	   stateless nodes, i.e., they do not support any QoS-NSLP or
708	   NTLP/GIMPS states.  These measurement-based nodes do store two
709	   RMD-QOSM states per PHR group.  These states reflect traffic
710	   conditions at the node and are not affected by any QoS-NSLP
711	   signaling. One state stores the measured user traffic load
712	   associated with the PHR group and another state stores the
713	   maximum traffic load that can be admitted per PHR group.

715	   When a measurement-based node receives a local RESERVE message, it
716	   compares the requested resources to the available resources (maximum
717	   allowed minus current load) for the requested PHR group.  If there
718	   are insufficient resources, it sets the <M> bit in the RMD-QSpec.
719	   No change to the RMD-QSpec is made when there are sufficient
720	   resources.  In either case, the node then forwards the RESERVE
721	   along the path towards the destination.  REFRESH and RELEASE
722	   messages are not normally generated in the measurement-based mode,
723	   but if received SHOULD not be processed and forwarded unchanged.

725	4.3.3  Reservation-based method

727	   QNE Interior nodes operating in reservation-based mode are QoS-NSLP
728	   reduced state nodes, i.e., they do not store NTLP/GIMPS states but
729	   they do store per-PHB-aggregated QoS-NSLP states.

731	   The reservation-based PHR installs and maintains one reservation
732	   state per PHB, in all the nodes located in the
733	   communication path from the QNE Ingress node up to the QNE Egress
734	   node.  This state represents the number of currently reserved
735	   resource units.  Thus, the QNE Ingress node signals only the
736	   resource units requested by each flow.  These resource units if
737	   admitted are added to the currently reserved resources per PHB.

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

743	   The per-PHB group reservation states are soft states, which are
744	   refreshed by sending periodic refresh local RESERVE messages. If a
745	   refresh message corresponding to a number of reserved resource units
746	   is not received, the aggregated reservation state is decreased in
747	   the next refresh period by the corresponding amount of resources
748	   that were not refreshed. The refresh period can be refined using a
749	   sliding window algorithm described in [RMD3].

751	   The reserved resources for a particular flow can also be
752	   explicitly released from a PHB reservation state by means of a PHR
753	   release message.  The usage of explicit release enables the
754	   instantaneous release of the resources regardless of the length of
755	   the refresh period.  This allows a longer refresh period, which also
756	   reduces the number of periodic refresh messages.

758	4.4.  Transport of RMD-QOSM messages

760	   The intra-domain (local) messages used by the RMD-QOSM MUST operate
761	   in the NTLP/GIMPS Datagram mode (see [GIMPS]).  Therefore, the NSLP
762	   functionality available in all QoS NSLP nodes that are able to
763	   support the RMD-QOSM MUST require the intra-domain GIMPS
764	   functionality available in these nodes to operate in the datagram
765	   mode, i.e., require GIMPS to:

767	   * operate in unreliable mode. This can be satisfied by passing this
768	     requirement from the QoS-NSLP layer to the GIMPS layer via the API
769	     transfer-attributes.

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

775	   * do not create any NTLP routing state. This can be satisfied by
776	     passing this requirement from the QoS-NSLP layer to the GIMPS layer
777	     via the API.

779	   All the intra-domain local messages are transported using the GIMPS
780	   data messages (see [GIMPS]).

782	4.5  Edge discovery and addressing of messages

784	   Mainly, the Egress node discovery can be performed either by using
785	   the GIMPS discovery mechanism [GIMPS], manual configuration or any
786	   other discovery technique.  The addressing of signaling messages
787	   depends on the used GIMPS transport mode.  The RMD QoS signaling
788	   messages that are processed only by the edge nodes use the peer-peer
789	   addressing of the GIMPS connection mode (C).  RMD QoS signaling
790	   messages that are processed by all nodes of the Diffserv domain,
791	   i.e., edges and Interior nodes, use the end-end addressing of the
792	   GIMPS datagram (D) mode.  RMD QoS signaling messages addressed to
793	   the the data path end nodes are intercepted by the Egress nodes.

795	4.6.  Operation and sequence of events

797	   This section describes the operation and the sequence of events in
798	   the RMD-QOSM.

800	4.6.1.  Basic unidirectional operation

802	   This section describes the basic unidirectional operation and
803	   sequence of events of the RMD-QOSM.  The following basic operation
804	   cases are distinguished: Successful reservation, Unsuccessful
805	   reservation, Refresh, Modification, Release and Severe congestion.
806	   The QNEs at the edges of the RMD domain support the RMD
807	   QoS Model and end-to-end QoS models, which process the RESERVE
808	   message differently. Note that the term end-to-end QoS model applies
809	   to any QoS model that is initiated and terminated outside the
810	   RMD-QOSM aware domain. However, there might be situations where a QoS
811	   model is initiated and/or terminated by the QNE edges and is
812	   considered to be an end-to-end QoS model. This can occur when the QNE
813	   edge can also operate as a QNI or as a QNR.

815	4.6.1.1.  Successful reservation

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

820	   The QNI generates the initial RESERVE message, and it is forwarded
821	   by the NTLP as usual [GIMPS].

823	4.6.1.1.1. Operation in Ingress node

825	   When an end-to-end reservation request (RESERVE) arrives at the
826	   Ingress node (QNE), see Figure 8, it is processed based on the
827	   procedures defined by the end-to-end QoS model.  Subsequently, the
828	   RMD QoS Description: <Bandwidth> and <PHB-CLASS> are derived from
829	   the QoS Description of the end-to-end QSpec.

831	   As described in Section 4.3.1, the QNE edges maintain for the RMD
832	   QoS model either per flow, or aggregated QoS-NSLP reservation
833	   states, which are identified by (local NTLP) SESSION_IDs (see
834	   [GIMPS]). Note that this NTLP SESSION ID is a different one than
835	   the SESSION_ID associated with the end-to-end RESERVE message.

837	   If the request was satisfied locally (see Section 4.3), the Ingress
838	   QNE node generates two RESERVE messages: one intra-domain and
839	   one end-to-end RESERVE messages.  These are bounded together
840	   including BOUND_SESSION_ID in the intra-domain RESERVE message.

842	   The intra-domain RESERVE message is associated with the (local NTLP)
843	   SESSION ID mentioned above. The selection of the IP source and IP
844	   destination address of this message depends on if and how the
845	   different inter domain (end-to-end) flows can be aggregated by the
846	   QNE Ingress node (see Section 4.3.1). If no QOS-NSLP aggregation
847	   procedure at the QNE edges is possible then the IP source and IP
848	   destination address of this message MUST be equal to the IP Source
849	   and IP destination addresses of the data flow.  The intra-domain
850	   RESERVE message must be sent using the NTLP datagram mode, see
851	   Section 4.4. In addition, the intra-domain RESERVE (RMD-QSPEC)
852	   message MUST include a PHR container (PHR_Resource_Request) and the
853	   "RMD QOS Description" field.

855	   The end-to-end RESERVE message includes the end-to-end QSpec and it
856	   is sent to the Egress QNE.  If the end-to-end QSpec does not carry
857	   an RII object, then the A (Acknowledgment) flag MUST be set ON.
858	   Otherwise the A flag MUST be set OFF.

860	   Note that after completing the initial discovery phase, the GIMPS
861	   connection mode between the QNE Ingress and QNE Egress can be used.
862	   The end-to-end RESERVE message is forwarded using the GIMPS
863	   forwarding procedure to bypass the Interior stateless or reduced-
864	   state QNE nodes, see Figure 8.  Furthermore, note that the initial
865	   discovery phase and the process of sending the end-to-end RESERVE
866	   message towards the QNE Egress MAY be accomplished simultaneously.

868	   The (initiating) intra-domain RESERVE message MUST be used and/or
869	   set by the QNE Ingress as follows:

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

874	   *  the value of the <BOUND_SESSION_ID> object MUST be the session
875	      ID associated to the end-to-end RESERVE message;

877	   *  the SCOPING flag SHOULD not be set, meaning that a default
878	      scoping of the message is used.  Therefore, the QNE edges MUST
879	      be configured as boundary nodes and the QNE Interior nodes
880	      MUST be configured as Interior (intermediary) nodes;

882	   *  The <RII> object is not included in this message;

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

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

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

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

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

899	   *  the flag "Acknowledge" (A) MUST be set "OFF";
900	   *  In a single-domain case the PDR container MAY not be included into
901	      the message.

903	   When an end-to-end RESPONSE(PDR) message is received by the QNE
904	   Ingress node, the RMD-QSPEC, see Section 4.6.1.1.3, has to be
905	   identified, processed and removed from the end-to-end RESPONSE
906	   message.  The QoS-NSLP state in the QNE Ingress stores and maintains
907	   the binding between each end-to-end session and each intra-domain
908	   session. In this way the QNE Ingress can match the PHR container that
909	   has been carried by the intra-domain RESERVE with the received PDR
910	   container that has been carried by the end-to-end RESPONSE message.
911	   The RMD QoS model functionality is notified by r eading the <M>
912	   parameter of the "PDR RMD control information" container that the
913	   reservation has been successful.

915	   If the end-to-end RESPONSE message has to be forwarded to a
916	   node outside the RMD-QOSM aware domain then the non-default values of
917	   the objects contained in this message (i.e., <RII/RSN>, <ERROR_SPEC>,
918	   [ *QSPEC ]) MUST be used and set by the QOS-NSLP protocol functions
919	   of the QNE.

921	4.6.1.1.2 Operation in the Interior nodes

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

926	   *  the values of the <RSN>, <RII>, <REFRESH_PERIOD>,
927	      <BOUND_SESSION_ID>, <POLICY_DATA> objects are not changed,
928	      i.e., equal to the values set by the QNE Ingress. These values
929	      are not used by the QNE Interior;

931	   *  the flag "Acknowledge" (A) SHOULD be set "OFF";

933	   *  the value of <Bandwidth> parameter of the "RMD QoS
934	      Description" field is used by the QNE Interior node for
935	      admission control, see Section 4.3.2 and Section 4.3.3;

937	   *  in case of the RMD reservation-based procedure, and if these
938	      resources are admitted are going to be added to the currently
939	      reserved resources per PHB and therefore they will become a
940	      part of the per RMD traffic class (PHB) reservation state.
941	      Furthermore, the value of the <Admitted Hops> parameter in the
942	      PHR container has to be increased by one;

944	   *  in case of the RMD measurement based method, and if these
945	      resources are admitted, using a MBAC algorithm, the number of
946	      this resources will be used to update the MBAC algorithm.

948	4.6.1.1.3 Operation in the Egress node

950	   When the intra-domain RESERVE(RMD-QSPEC) is received by the QNE
951	   Egress node of the session associated with the intra-domain
952	   RESERVE(RMD-QSPEC) (the PHB session) with the session included in
953	   its <BOUND_SESSION_ID> object MUST be bounded.  The session included
954	   in the <BOUND_SESSION_ID> object is the session associated with the
955	   end-to-end RESERVE message.

957	   The end-to-end RESERVE message is only forwarded further, towards
958	   QNR, if the processing of the intra-domain RESERVE (RMD-QSPEC)
959	   message was successful at all nodes in the RMD domain. Otherwise the
960	   inter domain (end-to-end) reservation is considered as being failed.

962	   If the (A) flag carried by the end-to-end RESERVE message was set to
963	   ON, then a one hop (end-to-end) RESPONSE message MUST be generated
964	   by the QNE Egress. Otherwise, the QNE Egress MUST wait for the
965	   end-to-end RESPONSE message that has the same SESSION ID as the
966	   end-to-end RESERVE message forwarded towards QNR.

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

972	   *  the values of the <RII/RSN>, <ERROR_SPEC> , [ *QSPEC ] objects
973	      are set by the standard QoS-NSLP protocol functions.

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

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

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

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

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

995	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
996	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
997	    |                    |                   |                    |
998	RESERVE                  |                   |                    |
999	--->|                    |                   |     RESERVE        |
1000	    |------------------------------------------------------------>|
1001	    |RESERVE(RMD-QSPEC)  |                   |                    |
1002	    |------------------->|                   |                    |
1003	    |                    |RESERVE(RMD-QSPEC) |                    |
1004	    |                    |------------------>|                    |
1005	    |                    |                   | RESERVE(RMD-QSPEC) |
1006	    |                    |                   |------------------->|
1007	    |                    |                   |                RESERVE
1008	    |                    |                   |                    |-->
1009	    |                    |                   |                RESPONSE
1010	    |                    |                   |                    |<--
1011	    |                    |RESPONSE(PDR)      |                    |
1012	    |<------------------------------------------------------------|
1013	RESPONSE                 |                   |                    |
1014	<---|                    |                   |                    |

1016	Figure 8: Basic operation of successful reservation procedure used by
1017	          the RMD-QOSM

1019	4.6.1.2.  Unsuccessful reservation

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

1024	   The QNE Ingress, the QNE Interior and QNE Egress nodes process and
1025	   forward the end-to-end RESERVE message and the intra-domain
1026	   RESERVE (RMD-QSPEC) message in the same way as specified in Section
1027	   4.6.1.1.  The main difference between the unsuccessful operation and
1028	   successful operation is that one of the QNE nodes does not admit the
1029	   request due to lack of resources.  This also means that the QNE edge
1030	   node MUST NOT forward the end-to-end RESERVE message towards the
1031	   QNR node.

1033	4.6.1.2.1 Operation in the Ingress nodes

1035	   When an end-to-end RESERVE message arrives to the QNE Ingress and
1036	   if there are no resources available locally, the QNE Ingress MUST
1037	   reject this end-to-end RESERVE message and sends a RESPONSE message
1038	   back to the sender, using a standard QoS-NSLP procedure.

1040	   In case of the RMD reservation based scenario, and if the
1041	   intra-domain reservation request is not admitted by the QNE Interior
1042	   node then the <Hop_U> and <M> parameters of the PHR container MUST be
1043	   set to "1".  The <Admitted Hops> counter MUST NOT be increased.

1045	   In case of the RMD measurement based scenario, and if the
1046	   intra-domain reservation query (i.e., intra-domain
1047	   RESERVE(RMD-QSPEC) is not admitted by the MBAC algorithm then the
1048	   <M> parameter of the PHR container MUST be set to "1".

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

1056	   *  the values of the <RII/RSN>, <ERROR_SPEC> ], [*QSPEC] objects
1057	      are set by standard QoS-NSLP protocol functions

1059	   *  the RMD-QSPEC object, see Section 4.2, has to be processed
1060	      and removed.  The RMD Resource Management Function (RMF) is
1061	      notified by reading the <M> parameter of the PDR container that
1062	      the reservation has been unsuccessful.  In case of a RMD
1063	      reservation based scenario, the RMD-QOSM functionality, has to
1064	      start an RMD release procedure (see Section 4.6.1.5).

1066	4.6.1.2.2 Operation in the Interior nodes

1068	   In general, if a QNE Interior node receives a PHR container, of type
1069	   "PHR_Resource_Request", with the <M> parameter set to "1" then this
1070	   PHR container and the "RMD QoS Description" field MUST NOT be
1071	   Processed.

1073	4.6.1.2.3 Operation in the Egress nodes

1075	   In the RMD reservation based and RMD measurement based scenario, when
1076	   the <M> marked intra-domain RESERVE(RMD-QSPEC) is received by the
1077	   QNE Egress node (see Figure 9) the session associated with the intra-
1078	   domain RESERVE(RMD-QSPEC) (the PHB session) and the session included
1079	   in its BOUND_SESSION_ID object MUST be bounded.  The session included
1080	   in the <BOUND_SESSION_ID> object is the session associated with the
1081	   end-to-end RESERVE.

1083	   The QNE Egress node MUST generate an end-to-end RESPONSE message
1084	   that will have to be sent to its previous stateful QoS-NSLP hop.

1086	   *  the values of the <RII/RSN>, <ERROR_SPEC>, [ *QSPEC] objects
1087	      are set by the standard QoS-NSLP protocol functions;

1089	   In addition to the above, and similar to the successful operation,
1090	   see Section 4.6.1.1.3, the QNE Egress MUST also generate an RMD-QSPEC
1091	   object that is carried by the end-to-end RESPONSE message.

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

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

1099	   *  the value of the <Admitted Hops> parameter of the PHR container
1100	      included in the received <M> marked PDR container MUST be included
1101	      in the <Max_Admitted Hops> parameter of the PDR container;

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

1106	QNE (Ingress)    QNE (Interior)       QNE (Interior)      QNE (Egress)
1107	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1108	    |                    |                   |                    |
1109	RESERVE                  |                   |                    |
1110	--->|                    |                   |     RESERVE        |
1111	    |------------------------------------------------------------>|
1112	    |RESERVE(RMD-QSPEC)  |                   |                    |
1113	    |------------------->|                   |                    |
1114	    |                    |RESERVE(RMD-QSPEC:M =1)                 |
1115	    |                    |------------------>|                    |
1116	    |                    |                   | RESERVE(RMD-QSPEC:M=1)
1117	    |                    |                   |------------------->|
1118	    |                    |RESPONSE(PDR)      |                    |
1119	    |<------------------------------------------------------------|
1120	RESPONSE                 |                   |                    |
1121	<---|                    |                   |                    |
1122	RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max_Admitted Hops>
1123	    |------------------->|                   |                    |

1125	Figure 9: Basic operation during unsuccessful reservation
1126	          initiation used by the RMD-QOSM

1128	4.6.1.3 RMD refresh reservation

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

1134	   The refresh procedure in case of RMD reservation-based method
1135	   follows a similar scheme as the reservation process, shown in Figure
1136	   3. If the RESERVE messages arrive within the soft state time-out
1137	   period, the corresponding number of resource units are not removed.
1138	   However, the transmission of the intra-domain and end-to-end
1139	   (refresh) RESERVE message are not necessarily synchronized.
1140	   Furthermore, the generation of the end-to-end RESERVE
1141	   message, by the QNE edges, depends on the locally maintained
1142	   refreshed interval (see [QoS-NSLP]).

1144	4.6.1.3.1 Operation in the Ingress node

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

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

1158	   The selection of the IP source and destination address of this
1159	   message depends on if and how the different inter domain
1160	   (end-to-end) flows can be aggregated by the QNE Ingress node (see
1161	   Section 4.3.1).  Note that this QOS-NSLP aggregation procedure is
1162	   different than the RMD traffic class aggregation procedure.  One
1163	   example is the approach used by the RSVP aggregation scenario
1164	   ([RFC 3175]), where the IP source address of this message is the IP
1165	   address of the aggregator (i.e., QNE Ingress) and the IP destination
1166	   address of this message is the IP address of the De-aggregator
1167	   (i.e., QNE Egress).  Another example approach is the one used
1168	   in "RSVP Refresh Overhead Reduction Extensions" ([RFC2961]).  If no
1169	   QOS-NSLP aggregation procedure at the QNE edges is possible then the
1170	   IP source and IP destination address of this message MUST be equal to
1171	   the IP source and IP destination addresses of the data flow.

1173	   An example of this RMD specific refresh operation can be seen in
1174	   Figure 10.

1176	QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)
1177	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1178	    |                    |                   |                    |
1179	    |RESERVE(RMD-QSPEC)  |                   |                    |
1180	    |------------------->|                   |                    |
1181	    |                    |RESERVE(RMD-QSPEC) |                    |
1182	    |                    |------------------>|                    |
1183	    |                    |                   | RESERVE(RMD-QSPEC) |
1184	    |                    |                   |------------------->|
1185	    |                    |                   |                    |
1186	    |                    |RESPONSE(RMD-QSPEC)|                    |
1187	    |<------------------------------------------------------------|
1188	    |                    |                   |                    |

1190	   Figure 10: Basic operation of RMD specific refresh procedure

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

1197	   *  the flag "Acknowledge" (A) SHOULD be set "OFF"

1199	   *  the PHR resource units MUST be included into the <Bandwidth>
1200	      parameter.   The value of the <Bandwidth> parameter depends on
1201	      how the different inter domain (end-to-end) flows are aggregated
1202	      by the QNE Ingress node (e.g., the sum of all the PHR requested
1203	      resources of the aggregated flows).  If no QOS-NSLP aggregation is
1204	      accomplished by the QNE Ingress node, the value of the
1205	      <Bandwidth> parameter SHOULD be equal to the <Bandwidth>
1206	      parameter of its associated new (initial) intra-domain RESERVE
1207	      (RMD-QSPEC) message;

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

1213	   *  In a single-domain case the PDR container field
1214	      MAY not be included into the message.

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

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

1224	   *  the values of the <RII/RSN>, <ERROR_SPEC>, [ *QSPEC] objects
1225	      are processed by the standard QoS-NSLP protocol functions;

1227	   *  the PDR has to be processed and removed by the RMD-QOSM
1228	      functionality in the QNE Ingress node.  The RMD-QOSM functionality
1229	      is notified by the <PDR M> parameter of the PDR container
1230	      that the refresh procedure has been successful or unsuccessful.
1231	      All session(s) (in case of the flow aggregation procedure there
1232	      will be more than one sessions) associated with this RMD specific
1233	      refresh session MUST be informed about the success or failure of
1234	      the refresh procedure.  In case of failure, the QNE Ingress node
1235	      has to generate (in a standard QoS-NSLP way) an error end-to-end
1236	      RESPONSE message that will be sent towards QNI.

1238	4.6.1.3.2 Operation in the Interior node

1240	   The intra-domain RESERVE (RMD-QSPEC) message is received and
1241	   processed by the QNE Interior nodes.  Any QNE edge or QNE Interior
1242	   node that receives a "PHR_Refresh_Update" control information field
1243	   MUST identify the traffic class state (PHB) (using the
1244	   <PHB-CLASS> parameter).  Most of the parameters in this refresh
1245	   intra-domain RESERVE (RMD-QSPEC) message MUST be used and/or set by
1246	   a QNE Interior node in the same way as described in Section 4.6.1.1.

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

1250	   *  the value of <Bandwidth> parameter of the "RMD QoS Description"
1251	      field is used by the QNE Interior node for refreshing the RMD
1252	      traffic class state. These resources (included in <Bandwidth>),
1253	      if reserved, are added to the currently reserved resources
1254	      per PHB and therefore they will become a part of the per traffic
1255	      class (per-PHB) reservation state.  If the refresh procedure
1256	      cannot be fulfilled then the <M> parameter of the PHR container
1257	      has to be set to "1".

1259	   Any PHR container of type "PHR_Refresh_Update", and its associated
1260	   "RMD QoS Description" field (i.e., <Bandwidth>), whether it is
1261	   marked or not, is always processed, but marked bits are not changed.

1263	4.6.1.3.3 Operation in the Egress node

1265	   The intra-domain RESERVE(RMD-QSPEC) message is received and
1266	   processed by the QNE Egress node.  A new intra-domain RESPONSE
1267	   (RMD-QSPEC) message is generated by the QNE Egress node.  This
1268	   message MUST include a PDR (type PDR_Refresh_Report).

1270	   The intra-domain RESPONSE (RMD-QSPEC) message MUST be sent to the
1271	   QNE Ingress node, i.e., previous stateful hop. The address of the QNE
1272	   Ingress node can be found using the existing messaging association
1273	   between the QNE Egress and QNE Ingress nodes. This state is
1274	   associated with the end-to-end session and identified by the SESSION
1275	   ID that is bound to the session of the intra-domain
1276	   RESPONSE(RMD-QSPEC) message.

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

1280	   *  the value of the <PDR Control Type> parameter of the PDR container
1281	      MUST be set "8" (i.e. PDR_Refresh_Report).

1283	4.6.1.4.  RMD modification of aggregated reservations

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

1289	   * When the modification request requires an increase of the reserved
1290	   resources, the QNE Ingress node MUST include the corresponding value
1291	   into the <Bandwidth> parameter of the "RMD QoS Description" field,
1292	   which is sent together with a "PHR_Resource_Request" control
1293	   information.  If a QNE edge or QNE Interior node is not able to
1294	    reserve the number of requested resources, the
1295	   "PHR_Resource_Request" control information that is associated with
1296	   the <Bandwidth> parameter MUST be marked.  In this situation the RMD
1297	   specific operation for unsuccessful reservation will be applied (see
1298	   Section 4.6.1.2).

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

1306	4.6.1.5  RMD release procedure

1308	   If a refresh RESERVE message does not arrive at a QNE Interior node
1309	   within the refresh time-out period then the resources associated
1310	   with this message are removed.  This soft state behavior provides
1311	   certain robustness for the system ensuring that unused resources are
1312	   not reserved for long time.  Resources can be removed by explicit
1313	   release at any time.

1315	   When the RMD-RMF of a QNE edge or QNE Interior node processes a
1316	   "PHR_Release_Request" control information it MUST identify
1317	   the <PHB-CLASS> parameter and estimate the time period that elapsed
1318	   after the previous refresh. This MAY be done by indicating the time
1319	   lag, say "T_lag", between the last sent "PHR_Refresh_Update" and
1320	   the "PHR_Release_Request" control information container by the QNE
1321	   Ingress node.  The value of "T_Lag" is first normalized to the
1322	   length of the refresh period, say "T_period".  The ratio between the
1323	   "T_Lag" and the length of the refresh period, "T_period", is
1324	   calculated.  This ratio is then introduced into the <Time Lag>
1325	   parameter of the "PHR_Release_Request" control information. When a
1326	   node (QNE edge or QNE Interior) receives the "PHR_Release_Request"
1327	   control information, it MUST store the arrival time.  Then it MUST
1328	   calculate the time difference, say "Tdiff", between the arrival time
1329	   and the start of the current refresh period, "T_period".
1330	   Furthermore, this node MUST derive the value of the "T_Lag", from the
1331	   <Time Lag> parameter.

1333	   This can be found by multiplying the value included in the <Time
1334	   Lag> parameter with the length of the refresh period, "T_period".
1335	   If the derived time lag, "T_lag", is smaller than the calculated
1336	   time difference, "T_diff", then this node MUST decrease the PHB
1337	   reservation state with the number of resource units indicated in the
1338	   <Bandwidth> parameter of the "RMD QoS Description" field that has
1339	   been sent together with the "PHR_Release_Request" control
1340	   information container, but not below zero.

1342	   An RMD specific release procedure can be triggered by an end-to-end
1343	   RESERVE with a TEAR flag set ON (see Section 4.6.1.5.1) or it can be
1344	   triggered by either an intra-domain RESPONSE or an end-to-end NOTIFY
1345	   message that includes a marked (i.e., PDR <M> and/or PDR <S>
1346	   parameters are set ON) "PDR_Reservation_Report" or
1347	   "PDR_Congestion_Report".

1349	4.6.1.5.1.  Triggered by a RESERVE message

1351	   This RMD explicit release procedure can be triggered by a tear (TEAR
1352	   flag set ON) end-to-end RESERVE message.  When a tear (TEAR flag
1353	   set ON) end-to-end RESERVE message arrives to the QNE Ingress
1354	   then the QNE Ingress node SHOULD process the message in a standard
1355	   QoS-NSLP way (see [QoS-NSLP]).  In addition to this, the RMD RMF
1356	   MUST be notified.  It will generate an intra-domain
1357	   RESERVE(RMD-QSPEC) message.  Before generating this message, the RMD
1358	   RMF is using the RMD traffic class (PHR) resources (specified in
1359	   <Bandwidth>) and the PHB type (specified in <PHB-CLASS>) for a RMD
1360	   release procedure.  This can be achieved by subtracting the amount of
1361	   the requested resources from the total reserved amount of resources
1362	   stored in the RMD traffic class state.

1364	QNE (Ingress)     QNE (Interior)       QNE (Interior)    QNE (Egress)
1365	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1366	    |                    |                   |                    |
1367	RESERVE                  |                   |                    |
1368	--->|                    |                   |     RESERVE        |
1369	    |------------------------------------------------------------>|
1370	    |RESERVE(RMD-QSPEC:Tear=1)               |                    |
1371	    |------------------->|                   |                    |
1372	    |                    |RESERVE(RMD-QSPEC:Tear=1)               |
1373	    |                    |------------------->|                   |
1374	    |                    |                 RESERVE(RMD-QSPEC:Tear=1)
1375	    |                    |                   |------------------->|
1376	    |                    |                   |                RESERVE
1377	    |                    |                   |                    |-->
1378	    |                    |                   |

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

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

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

1393	   *  the flag "Acknowledge" (A) SHOULD be set "OFF";

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

1399	   *  the TEAR flag is set to ON;

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

1404	   *  the value of the <Admitted Hops> parameter has to be set to "1";

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

1411	   The intra-domain tear RESERVE (RMD-QSPEC) message is received and
1412	   processed by the QNE Interior nodes.  Most of the non-default
1413	   values of the objects contained in this refresh intra-domain RESERVE
1414	   (RMD-QSPEC) message are set by a QNE Interior node in the same way
1415	   as described in Section 4.6.1.1.  The following objects are set and
1416	   processed differently:

1418	   *  Any QNE Interior node that receives the combination of the "RMD
1419	   QoS Description" field and the "PHR_Resource_Release" control
1420	   information container, it MUST identify the traffic class (PHB)
1421	   and release the requested resources included in the <Bandwidth>
1422	   parameter.  This can be achieved by subtracting the amount of RMD
1423	   traffic class requested resources, included in the <Bandwidth>
1424	   parameter, from the total reserved amount of resources stored in the
1425	   RMD traffic class state.  The value of the <Time Lag> parameter of
1426	   the "PHR_Resource_Release" container is used during the release
1427	   procedure as explained in Section 4.6.1.5.

1429	   The intra-domain tear RESERVE (RMD-QSPEC) message is received and
1430	   processed by the QNE Egress node.  The "RMD QoS Description" and the
1431	   "PHR RMD-QOSM control " container (and if available the "PDR RMD-QOSM
1432	   control information" container) are read and processed by the RMD QoS
1433	   signaling model functionality.  The value of the <Bandwidth>
1434	   parameter of the "RMD QoS Description" field and the value of the
1435	   <Time Lag> field of the PHR container MUST be used by the RMD release
1436	   procedure.  This can be achieved by subtracting the amount of RMD
1437	   traffic class requested resources, included in the <Bandwidth>
1438	   parameter, from the total reserved amount of resources stored in the
1439	   RMD traffic class state.

1441	   The end-to-end RESERVE message is forwarded by the next hop (i.e.,
1442	   QNE Egress) only if the intra-domain tear RESERVE (RMD-QSPEC)
1443	   message arrives at the QNE Egress node.

1445	4.6.1.5.2   Triggered by a marked RESPONSE or NOTIFY message

1447	   This RMD explicit release procedure can be triggered by either an
1448	   end-to-end RESPONSE message with a <M> marked PDR container (see
1449	   Section 4.6.1.2) or an intra-domain NOTIFY (PDR) message (see Sectio
1450	   4.6.1.6) with a <M> or <S> marked PDR container.  This RMD specific
1451	   release procedure can be terminated at any QNE edge or any QNE
1452	   Interior node using the <Max_Admitted Hops> field.

1454	   The RMD specific explicit release procedure that is terminated at a
1455	   QNE Interior (or QNE edge) node is denoted as RMD specific partial
1456	   release procedure.  This explicit release procedure
1457	   can be used, for example, during a RMD specific operation for
1458	   unsuccessful reservation (see Section 4.6.1.2) or severe congestion
1459	   (see Section 4.6.1.6).  When the RMD QoS signaling model
1460	   functionality of a QNE Ingress node receives a <M> or <S> marked
1461	   PDR container of type "PDR_Reservation_Report" or
1462	   "PDR_Congestion_Report", it MUST start an RMD partial release
1463	   procedure.  The QNE Ingress node generates an intra-domain RESERVE
1464	   (RMD-QSPEC) message.  Before generating this message, the RMD-QOSM
1465	   functionality is using the RMD traffic class (PHR) resource units for
1466	   a RMD release procedure.  This can be achieved by subtracting the
1467	   amount of RMD traffic class requested resources from the total
1468	   reserved amount of resources stored in the RMD traffic class state.

1470	   When the generation of the intra-domain RESERVE (RMD-QSPEC) message
1471	   is triggered by an intra-domain NOTIFY(PDR) message then the
1472	   intra-domain RESERVE(RMD-QSPEC) message MUST include a
1473	   <RMD QoS Description> field and a PHR container, (i.e.,
1474	   PHR_Resource_Release) and it MAY include a PDR container, (i.e.,
1475	   PDR_Release_Request).  An example of this message exchange can be
1476	   seen in Figure 12.

1478	QNE (Ingress)     QNE (Interior)         QNE (Interior)    QNE (Egress)
1479	NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
1480	    |                  |                  |                  |
1481	    |                  |                  |                  |
1482	    | NOTIFY (PDR)     |                  |                  |
1483	    |<-------------------------------------------------------|
1484	    |RESERVE(RMD-QSPEC:Tear=1,M=1,S=SET)  |                  |
1485	    | ---------------->|RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET) |
1486	    |                  |                  |                  |
1487	    |                  |----------------->|                  |
1488	    |                  |           RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET)
1489	    |                  |                  |----------------->|

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

1494	   When the generation of the intra-domain RESERVE(RMD-QSPEC) message
1495	   is triggered by an end-to-end RESPONSE(PDR) message then this
1496	   generated intra-domain RESERVE(RMD-QSPEC) message MUST include a
1497	   <RMD QoS Description> field and a PDR container, (i.e.,
1498	   PHR_Resource_Release) and it MAY include a PDR container, (i.e.,
1499	   PDR_Release_Request).  An example of this operation can be seen in
1500	   Figure 13.

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

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

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

1511	   *  When the tear intra-domain RESERVE message is triggered by a
1512	      NOTIFY message, then the value of the <S> parameter of the
1513	      PHR container MUST be set to "1".

1515	   *  The RESERVE message MAY include PDR container.

1517	   *  When the tear intra-domain RESERVE message is triggered by an
1518	      intra-domain RESPONSE(RMD-QSPEC) message, then the value of the
1519	      <Max Admitted Hops> parameter of the PDR container included in the
1520	      received <M> marked intra-domain RESPONSE(PDR) message MUST be
1521	      included in the <Max Admitted Hops> parameter of the PDR container
1522	      of the RESERVE message.

1524	QNE (Ingress)     QNE (Interior)        QNE (Interior)    QNE (Egress)
1525	                                     Node that marked
1526	                                    PHR_Resource_Request
1527	                                       <PHR> object
1528	NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
1529	    |                    |                   |                    |
1530	    |                    |                   |                    |
1531	    | RESPONSE (RMD-QSPEC: M=1)                     |
1532	    |<------------------------------------------------------------|
1533	RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max_Admitted Hops>)
1534	    |------------------->|                   |                    |
1535	    |                    |                   |                    |

1537	   Figure 13: Basic operation during RMD explicit release procedure
1538	   Triggered by RESPONSE used by the RMD-QOSM
1539	   Any QNE edge or QNE Interior node that receives the
1540	   "RMD QoS Description" field and the PHR container MUST identify the
1541	   traffic class state (PHB), using the <PHB-CLASS> parameter, and
1542	   release the requested resources included in the <Bandwidth> field.
1543	   This can be achieved by subtracting the amount of RMD traffic class
1544	   requested resources, included in the <Bandwidth> field, from the
1545	   total reserved amount of resources stored in the RMD traffic class
1546	   state.  The value of the <Time Lag> parameter of the PHR field
1547	   is used during the release procedure as explained in Section 4.6.1.5.

1549	   The <Admitted Hops> value included in the PHR container is increased
1550	   by one.  If the value of <M> parameter of the "PHR_Resource_Release"
1551	   control information container is "1" and if the value of the <S>
1552	   parameter is set to "0" then the <Max_Admitted Hops> value included
1553	   in the PDR container MUST be compared with the calculated <Admitted
1554	   Hops> value.  When these two values are equal then the intra-domain
1555	   RESERVE(RMD-QSPEC) has to be terminated and it will not be forwarded
1556	   downstream.  The reason of this is that the QNE node that is
1557	   currently processing this message was the last QNE node that
1558	   successfully processed the "RMD QoS Description" field and
1559	   PHR container of its associated initial reservation request (i.e.,
1560	   initial intra-domain RESERVE(RMD-QSPEC) message).  Its next QNE
1561	   downstream node was unable to successfully process the initial
1562	   reservation request, therefore, this QNE node marked the <M>
1563	   parameter of the "PHR_Resource_Request" control information.  When
1564	   the values of the <M> and <S> parameters are set to "0", then this
1565	   message will not be terminated by a QNE Interior node, but it will be
1566	   forwarded in the downstream direction.  The QNE Egress node will
1567	   receive and process the PHR_Resource_Release control information.
1568	   Afterwards, the QNE Egress node MUST terminate the intra-domain
1569	   RESERVE(RMD-QSPEC) message.

1571	4.6.1.6. Severe congestion handling

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

1576	   When a failure in a communication path, e.g. router or link
1577	   failure occurs, the routing algorithms will adapt to failures by
1578	   changing the routing decisions to reflect changes in the topology and
1579	   traffic volume.  As a result the re-routed traffic will follow a new
1580	   path, which may result in overloaded nodes as they need to support
1581	   more traffic than their capacity allows.  This may cause a severe
1582	   congestion in the communication path.  In this situation
1583	   the available resources, may not be enough to meet the required QoS
1584	   for all the flows along the new path.  Therefore, one or more flows
1585	   SHOULD be terminated, or forwarded in a lower priority queue.

1587	   Interior nodes notify edge nodes by data marking (proportional
1588	   marking) or marking the refresh messages using the <S> and
1589	   <Overload %> parameters.

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

1593	   The QoS-NSLP and RMD are able to cope with congested situations
1594	   using the refresh procedure, see Section 4.6.1.3. If the refresh is
1595	   not successful in an QNE Interior node, edge nodes are notified by
1596	   "S" marking the refresh messages and by including the percentage of
1597	   overload into the <Overload %> field in the "PHR_Refresh_Update"
1598	   container, carried by the intra-domain RESERVE message.
1599	   The intra-domain RESPONSE message that is sent by the QNE Egress
1600	   towards QNE Ingress will contain a PDR container with a
1601	   Parameter/Container ID = 10, i.e., "PDR_Congestion_Report". The
1602	   values of the <S> and <Overload %> fields of this container should
1603	   be set equal to the values of the <S> and <Overload %> fields,
1604	   respectively, carried by the PHR_Refresh_Update" container.  The
1605	   flows that cannot be supported, i.e., based on the value included in
1606	   the <Overload %> parameter, are terminated, or forwarded in a lower
1607	   priority queue.  The flows can be terminated by using the RMD release
1608	   procedure described in Section 4.6.1.5.

1610	   In general, relying the soft state refresh mechanism solves the
1611	   congestion within the time frame of the refresh period. If this
1612	   mechanism is not fast enough additional functions SHOULD be used,
1613	   which are described in Section 4.6.1.6.2.

1615	4.6.1.6.2 Severe congestion handling by proportional data packet marking

1617	   This severe congestion handling method requires the following
1618	   additional functionalities.

1620	4.6.1.6.2.1 Operation in the Interior nodes

1622	   The QNE Interior node detecting severe congestion marks data packets
1623	   passing the node in which the severe congestion was detected.
1624	   For the severe congestion marking, two additional DSCPs SHOULD be
1625	   allocated for each traffic class.  One MAY be used to indicate that
1626	   the packet passed a congested node.  The other DSCP MUST be used to
1627	   indicate the degree of congestion by marking the bytes proportionally
1628	   to the degree of congestion.  Note however, that it is RECOMMENDED
1629	   that the total number of additional DSCPs within a RMD domain, needed
1630	   for severe congestion handling MUST not exceed the limit of 16.

1632	4.6.1.6.2.2 Operation in the Egress nodes

1634	   The QNE Egress node applies a predefined policy to solve the severe
1635	   congestion, by selecting a number of inter domain (end-to-end)
1636	   flows that SHOULD be terminated, or forwarded in a lower priority
1637	   queue.  For these flows (sessions), the QNE Egress node generates
1638	   and sends a NOTIFY(PDR) message to the QNE Ingress node (its
1639	   upstream stateful QoS-NSLP peer) to indicate the severe congestion
1640	   in the communication path.  This message MUST include a PDR container
1641	   ("PDR_Reservation_Report").

1643	   The non-default values of the objects contained in the NOTIFY(PDR)
1644	   message MUST be set by the QNE Egress node as follows:

1646	   *  the values of the <ERROR_SPEC> object is set by the standard
1647	      QoS-NSLP protocol functions.

1649	   *  the value of the Parameter/Container ID of the PDR container
1650	      SHOULD be set to "10" (i.e., PDR_Congestion_Report).

1652	   *  The value of the <M> parameter of the PDR container MUST be set to
1653	      "1".

1655	   *  The value of the <S> parameter of the PDR container MUST be set to
1656	      "1".

1658	   4.6.1.6.2.3 Operation in the Ingress nodes

1660	   Upon receiving the (end-to-end) NOTIFY message, the QNE Ingress node
1661	   resolves the severe congestion by a predefined policy, e.g., refusing
1662	   new incoming flows (sessions), terminating the affected and notified
1663	   flows (sessions), or shifting them to an alternative RMD traffic
1664	   class (PHB). Note that due to the fact that the QoS-NSLP state in the
1665	   QNE Ingress node maintains the binding between the end-to-end and
1666	   intra-domain sessions, the QNE Ingress node can associate the PDR
1667	   container to the right intra-domain session.

1669	 QNE (Ingress)    QNE (Interior)        QNE (Interior)    QNE (Egress)

1671	  user  |                  |                 |                  |
1672	  data  |  user data       |                 |                  |
1673	 ------>|----------------->|     user data   | user data        |
1674	        |                  |---------------->S(# marked bytes)  |
1675	        |                  |                 S----------------->|
1676	        |                  |                 S(# unmarked bytes)|
1677	        |                  |                 S----------------->|Term.
1678	        |                 NOTIFY(PDR)                           |flow?
1679	        |<----------------|------------------|------------------|YES
1680	        |RESERVE(RMD-QSPEC:Tear=1,M=1,S=SET) |                  |
1681	        | --------------->|RESERVE(RMD-QSPEC:T=1, M=1,S=SET)    |
1682	        |                 |                  |                  |
1683	        |                 |----------------->|                  |
1684	        |                 |       RESERVE(RMD-QSPEC:Tear=1, M=1,S=SET)
1685	        |                 |                  |----------------->|

1687	   Figure: 14  RMD severe congestion handling

1689	   The severe congestion notification function based on data marking
1690	   can be used for implementing a simple admission control within a
1691	   Diffserv domain, see Figure 14.  In one or a few nodes along the data
1692	   thresholds are set in the resource management function for the data
1693	   traffic belonging to different PHBs. If the threshold is exceeded,
1694	   the data packets are marked in the DSCP field to indicate the high
1695	   load of different PHBs. In this case the Egress node sends a
1696	   NOTIFY(PDR) message to the Ingress node, which MAY block the incoming
1697	   traffic belonging to the same PHB until the traffic volume decreases
1698	   below the threshold, or forwards it in a lower priority queue.

1700	4.6.2  Bi-directional operation

1702	   RMD assumes asymmetric routing by default.  Combined sender-receiver
1703	   initiated reservation cannot be efficiently done in the RMD domain
1704	   because upstream NTLP states are not stored in Interior routers.
1705	   Therefore the bi-directional operation SHOULD be performed by two
1706	   sender-initiated reservations (sender&sender).  We assume that the
1707	   QNE edge nodes are common for both upstream and downstream
1708	   directions, therefore, the two reservations/sessions can be bound at
1709	   the QNE edge nodes.

1711	   This bi-directional sender&sender procedure can then be applied
1712	   between the QNE edges (QNE Ingress and QNE Egress) nodes of the RMD
1713	   QoS signaling model.  In the situation that a security association
1714	   exists between the QNE Ingress and QNE Egress nodes (see Figure 15),
1715	   and the QNE Ingress node has the required <Bandwidth> parameters
1716	   for both directions, i.e., QNE Ingress towards QNE Egress and QNE
1717	   Egress towards QNE Ingress, then the QNE Ingress MAY include both
1718	   <Bandwidth> parameters (needed for both directions) into the
1719	   RMD-QSPEC within a RESERVE message.  In this way the QNE Egress node
1720	   is able to use the QoS parameters needed for the "Egress towards
1721	   Ingress" direction (QoS-2).  The QNE Egress is then able to create a
1722	   RESERVE with the right QoS parameters included in the QSPEC, i.e.,
1723	   RESERVE (QoS-2). Both directions of the flows are bound by inserting
1724	   the <BOUND_SESSION_ID> object at the QNE Ingress and QNE Egress.

1726	     |------ RESERVE (QoS-1, QoS-2)----|
1727	     |                                 V
1728	     |           Interior/stateless QNEs
1729	                 +---+     +---+
1730	        |------->|QNE|-----|QNE|------
1731	        |        +---+     +---+     |
1732	        |                            V
1733	      +---+                        +---+
1734	      |QNE|                        |QNE|
1735	      +---+                        +---+
1736	         ^                           |
1737	      |  |       +---+     +---+     V
1738	      |  |-------|QNE|-----|QNE|-----|
1739	      |          +---+     +---+
1740	   Ingress/                         Egress/
1741	   statefull QNE                    statefull QNE
1742	                                     |
1743	   <--------- RESERVE (QoS-2) -------|

1745	   Figure 15: The bi-directional reservation scenario in the RMD domain

1747	   A bidirectional reservation, within the RMD domain, is indicated by
1748	   the PHR <B> and PDR <B> flags, which are set in all messages.
1749	   Upstream end-to-end messages include the session ID of downstream
1750	   messages using BOUND_SESSION_ID and vice versa.

1752	   If no security association exists between the QNE Ingress and QNE
1753	   Egress nodes the bi-directional reservation for the sender&sender
1754	   scenario in the RMD domain SHOULD use the scenario specified in
1755	   [QoS-NSLP] as "Bi-directional reservation for sender&sender
1756	   scenario".

1758	   In the following sections it is considered that the QNE
1759	   edge nodes are common for both upstream and downstream directions
1760	   and therefore, the two reservations/sessions can be bounded at the
1761	   QNE edge nodes.  Furthermore, it is considered that a security
1762	   association exists between the QNE Ingress and QNE Egress nodes,
1763	   and the QNE Ingress node has the required <Bandwidth> parameters
1764	   for both directions, i.e., QNE Ingress towards QNE Egress and
1765	   QNE Egress towards QNE Ingress.

1767	4.6.2.1 Successful and unsuccessful reservations

1769	   This section describes the operation of the RMD-QOSM where a RMD
1770	   bi-directional reservation operation is either successfully or
1771	   unsuccessfully accomplished.

1773	   The bi-directional successful reservation is similar to a
1774	   combination of two unidirectional successful reservations that are
1775	   accomplished in opposite directions, see Figure 16. The main
1776	   differences of the bi-directional successful reservation procedure
1777	   with the combination of two unidirectional successful reservations
1778	   accomplished in opposite directions are as follows.  The intra-
1779	   domain RESERVE message sent by the QNE Ingress node towards the QNE
1780	   Egress node, is denoted in Figure 16 as RESERVE (RMD-QSPEC):
1781	   "forward".  The main differences between the RESERVE (RMD-QSPEC):
1782	   "forward" message used for the bi-directional successful reservation
1783	   procedure and a RESERVE (RMD-QSPEC) message used for the
1784	   unidirectional successful reservation are as follows:

1786	   *  the RII object is not included in the message. This is because no
1787	      RESPONSE message is expected to arrive.

1789	   *  the <B> bit of the PHR container
1790	      indicates a bi-directional reservation and is set to "1".

1792	   *  the PDR container is also included into the RESERVE(RMD-QSPEC):
1793	      "forward" message.  The value of the Parameter/Container ID is
1794	     "4"., i.e., "PDR_Reservation_Request".  Note that the response PDR
1795	      container sent by a QNE Egress to a QNE Ingress node is not
1796	      carried by an end-to-end RESPONSE message, but it is carried by an
1797	      intra-domain RESERVE message that is sent by the QNE Egress node
1798	      towards the QNE Ingress node (denoted in Figure 16 as
1799	      RESERVE(RMD-QSPEC):"reverse").

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

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

1809	   The RESERVE(RMD-QSPEC):"reverse" message is initiated by the QNE
1810	   Egress node at the moment that the RESERVE(RMD-QSPEC):"forward"
1811	   message is successfully processed by the QNE Egress node.
1812	   The main differences between the RESERVE(RMD-QSPEC):"reverse"
1813	   message used for the bi-directional successful reservation procedure
1814	   and a RESERVE(RMD-QSPEC) message used for the unidirectional
1815	   successful reservation are as follows:

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

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

1825	   *  the value of the [BOUND_SESSION_ID] object is set equal to
1826	      the SESSION_ID of the intra domain session associated with the
1827	      RESERVE(RMD-QSPEC):"forward" message that triggered the
1828	      generation of this RESERVE(RMD-QSPEC):"reverse" message;

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

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

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

1840	QNE (Ingress)   QNE (int.)    QNE (int.)    QNE (int.)   QNE (Egress)
1841	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
1842	    |                |               |               |              |
1843	    |                |               |               |              |
1844	    |RESERVE(RMD-QSPEC)              |               |              |
1845	    |"forward"       |               |               |              |
1846	    |                |    RESERVE(RMD-QSPEC):        |              |
1847	    |--------------->|    "forward"  |               |              |
1848	    |                |------------------------------>|              |
1849	    |                |               |               |------------->|
1850	    |                |               |               |              |
1851	    |                |               |RESERVE(RMD-QSPEC)            |
1852	    |      RESERVE(RMD-QSPEC)        | "reverse"     |<-------------|
1853	    |      "reverse"   |             |<--------------|              |
1854	    |<-------------------------------|               |              |

1856	      Figure 16: Intra-domain signaling operation for successful
1857	                 bi-directional reservation

1859	   Figure 17 and Figure 18 show the flow diagrams used in case of a
1860	   unsuccessful bi-directional reservation.  In Figure 17 it
1861	   is considered that the QNE that is not able to support the
1862	   requested <Bandwidth> is located in the direction QNE Ingress
1863	   towards QNE Egress.  In Figure 18 it is considered that the
1864	   QNE that is not able to support the requested <Bandwidth> is
1865	   located in the direction QNE Egress towards QNE Ingress.

1867	   The main differences between the bi-directional unsuccessful
1868	   procedure shown in Figure 17 and the bi-directional successful
1869	   procedure are as follows:

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

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

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

1885	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
1886	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
1887	    |                |             |              |               |
1888	    |RESERVE(RMD-QSPEC):           |              |               |
1889	    |  "forward"     |  RESERVE(RMD-QSPEC):       |               |
1890	    |--------------->|  "forward"  |              M RESERVE(RMD-QSPEC):
1891	    |                |--------------------------->M  "forward-M marked"
1892	    |                |             |              M-------------->|
1893	    |                |           RESPONSE(PDR)    M               |
1894	    |                |        "forward - M marked"M               |
1895	    |<------------------------------------------------------------|
1896	    |RESERVE(RMD-QSPEC)            |              M               |
1897	    |"forward - T tear"            |              M               |
1898	    |---------------->             |              M               |

1900	Figure 17: Intra-domain signaling operation for unsuccessful
1901	           bi-directional reservation (rejection on path QNE(Ingress)
1902	           towards QNE(Egress))

1904	   The main differences between the bi-directional unsuccessful
1905	   procedure shown in Figure 18 and the in bi-directional successful
1906	   procedure are as follows:

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

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

1916	   *  the QNE Ingress uses the information contained in the received
1917	      PHR and PDR containers of the RESERVE(RMD-QSPEC): "reverse" and
1918	      generates a tear intra-domain (local) RESERVE(RMD-QSPEC):
1919	      "forward - T tear" message.  This message carriers a
1920	      "PHR_Release_Request" and a "PDR_Release_Request" control
1921	      information.  This message is sent to QNE Egress node.
1922	      The QNE Egress node by using the information contained in the
1923	      "PHR_Release_Request" and the "PDR_Release_Request" control
1924	      info containers it generates a RESERVE(RMD-QSPEC):"reverse - T
1925	      tear" message that is sent towards the QNE Ingress node.

1927	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
1928	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
1929	    |                |                |                |              |
1930	    |RESERVE(RMD-QSPEC)               |                |              |
1931	    |"forward"       |  RESERVE(RMD-QSPEC):            |              |
1932	    |--------------->|  "forward"     |           RESERVE(RMD-QSPEC): |
1933	    |                |-------------------------------->|"forward"     |
1934	    |                |   RESERVE(RMD-QSPEC):           |------------->|
1935	    |                |    "reverse"   |                |              |
1936	    |                |              RESERVE(RMD-QSPEC) |              |
1937	    |    RESERVE(RMD-QSPEC):          M      "reverse" |<-------------|
1938	    |   "reverse - M marked"          M<---------------|              |
1939	    |<--------------------------------M                |              |
1940	    |                |                M                |              |
1941	    |RESERVE(RMD-QSPEC):              M                |              |
1942	    |"forward - T tear"               M                |              |
1943	    |--------------->|  RESERVE(RMD-QSPEC):            |              |
1944	    |                |  "forward - T tear"             |              |
1945	    |                |-------------------------------->|              |
1946	    |                |                M                |------------->|
1947	    |                |                M             RESERVE(RMD-QSPEC):
1948	    |                |                M             reverse - T tear" |
1949	    |                |                M                |<-------------|

1951	   Figure 18: Intra-domain signaling normal operation for unsuccessful
1952	             bi-directional reservation (rejection on path QNE(Egress)
1953	             towards QNE(Ingress))

1955	4.6.2.2 Refresh reservations

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

1960	   The refresh procedure in case of RMD reservation-based method
1961	   follows a similar scheme as the successful reservation procedure,
1962	   described in Section 4.6.2.1, and depicted in Figure 16 and the
1963	   way of how the refresh process of the reserved resources is
1964	   maintained, is similar to the refresh process used for the intra-
1965	   domain uni-directional reservations (see Section 4.6.1.3).

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

1971	   The main differences between the RESERVE(RMD-QSPEC):"forward"
1972	   message used for the bi-directional refresh procedure
1973	   and a RESERVE(RMD-QSPEC):"forward" message used for the bi-
1974	   directional successful reservation procedure are as follows:

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

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

1982	   The main differences between the RESERVE(RMD-QSPEC):"reverse"
1983	   message used for the bi-directional refresh procedure and the RESERVE
1984	   (RMD-QSPEC): "reverse" message used for the bi-directional successful
1985	   reservation procedure are as follows:

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

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

1993	4.6.2.3 Modification of aggregated reservations

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

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

2002	   * When the modification request requires an increase of the reserved
2003	   resources, the QNE Ingress node MUST include the corresponding value
2004	   into the <Bandwidth> parameter of the "RMD QoS Description" field,
2005	   which is sent together with a "PHR_Resource_Request" control
2006	   information.  If a QNE edge or QNE Interior node is not able to
2007	   reserve the number of requested resources, then the
2008	   "PHR_Resource_Request" control information associated with the
2009	   <Bandwidth> parameter MUST be marked.  In this situation the RMD
2010	   specific operation for unsuccessful reservation will be applied (see
2011	   Section 4.6.2.1).

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

2019	4.6.2.4 Release procedure

2021	   This section describes the operation of the RMD-QOSM where a RMD
2022	   bi-directional reservation release operation is accomplished.
2023	   The message sequence diagram used in this procedure is similar to the
2024	   one used by the successful reservation procedures, described in
2025	   Section 4.6.2.1, and depicted in Figure 16. However, the way of how
2026	   the release of the reservation is accomplished, is similar to the RMD
2027	   release procedure used for the intra-domain uni-directional
2028	   reservations (see Section 4.6.1.5 and Figure 17 and Figure 18).

2030	   The main differences between the RESERVE (RMD-QSPEC):

2032	   "forward" message used for the bi-directional release procedure

2034	   and a RESERVE (RMD-QSPEC): "forward" message used for the bi-
2035	   directional successful reservation procedure are as follows:

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

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

2043	   The main differences between the RESERVE (RMD-QSPEC): "reverse"
2044	   message used for the bi-directional release procedure and the RESERVE
2045	   (RMD-QSPEC): "reverse" message used for the bi-directional successful
2046	   reservation procedure are as follows:

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

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

2054	4.6.2.5 Severe congestion handling

2056	   This section describes the severe congestion handling operation used
2057	   in combination with bi-directional reservation procedures.
2058	   This severe congestion handling operation is similar to the one
2059	   described in Section 4.6.1.6.

2061	4.6.2.5.1 Severe congestion handling by the RMD-QOSM bi-directional
2062	          refresh procedure

2064	   This procedure is similar to the severe congestion handling procedure
2065	   described in Section 4.6.1.6.1. The difference is related to how the
2066	   refresh procedure is accomplished, see Section 4.6.2.2 and to how the
2067	   flows are terminated, see Section 4.6.2.4.

2069	4.6.2.5.2 Severe congestion handling by proportional data packet marking

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

2075	   This procedure is similar to the severe congestion handling procedure
2076	   described in Section 4.6.1.6.2. The main difference is related to the
2077	   location of the severe congested node, i.e., "forward" path (i.e.,
2078	   path between QNE Ingress towards QNE Egress) or "reverse" path (i.e.,
2079	   path between QNE Egress towards QNE Ingress).

2081	   Figure 19 shows the scenario where the severe congested node is
2082	   located in the "forward" path. This scenario is very similar to the
2083	   severe congestion handling scenario described in Section 4.6.1.6.2
2084	   and shown in Figure 14. The difference is related to the release
2085	   procedure, which is accomplished in the same way as described in
2086	   Section 4.6.2.4.

2088	QNE(Ingress)   QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
2089	NTLP stateful  NTLP st.less  NTLP st.less  NTLP st.less  NTLP stateful
2090	user|                |             |              |               |
2091	data|    user        |             |              |               |
2092	--->|    data        | user data   |              |user data      |
2093	    |--------------->|             |              S               |
2094	    |                |--------------------------->S (#marked bytes)
2095	    |                |             |              S-------------->|
2096	    |                |             |              S(#unmarked bytes)
2097	    |                |             |              S-------------->|Term
2098	    |                |             |              S               |flow?
2099	    |                |          NOTIFY (PDR)      S               |YES
2100	    |<------------------------------------------------------------|
2101	    |RESERVE(RMD-QSPEC)            |              S               |
2102	    |"forward - T tear"            |              S               |
2103	    |--------------->|             |           RESERVE(RMD-QSPEC):|
2104	    |                |--------------------------->S"forward - T tear"
2105	    |                |             |              S-------------->|
2106	    |                |             |          RESERVE(RMD-QSPEC): |
2107	    |                |             |           "reverse - T tear" |
2108	    | RESERVE(RMD-QSPEC):          |              |<--------------|
2109	    |"reverse - T tear"            |<-------------S               |
2110	    |<-----------------------------|              S               |

2112	Figure 19: Intra-domain RMD severe congestion handling for
2113	           bi-directional reservation (congestion on path QNE(Ingress)
2114	           towards QNE(Egress))

2116	   Figure 20 shows the scenario where the severe congested node is
2117	   located in the "reverse" path. The main difference between this
2118	   scenario and the scenario shown in Figure 19 is that no intra-domain
2119	   NOTIFY(PDR) message has to be generated by the QNE Egress node. This
2120	   is because the (#marked and #unmarked) user data is arriving at the
2121	   QNE Ingress. The QNE Ingress node will be able to calculate the
2122	   number of flows that have to be terminated or forwarded in a lower
2123	   priority queue.

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

2129	QNE (Ingress)    QNE (int.)    QNE (int.)    QNE (int.)    QNE (Egress)
2130	NTLP stateful   NTLP st.less  NTLP st.less  NTLP st.less   NTLP stateful
2131	user|                |                |           |               |
2132	data|    user        |                |           |               |
2133	--->|    data        | user data      |           |user data      |
2134	    |--------------->|                |           |               |
2135	    |                |--------------------------->|user data      |user
2136	    |                |                |           |-------------->|data
2137	    |                |                |           |               |--->
2138	    |                |                |           |               |user
2139	    |                |                |           |               |data
2140	    |                |                |  user     |               |<---
2141	    |   user data    |                |  data     |<--------------|
2142	    | (#marked bytes)|                S<----------|               |
2143	    |<--------------------------------S           |               |
2144	    | (#unmarked bytes)               S           |               |
2145	Term|<--------------------------------S           |               |
2146	Flow?                |                S           |               |
2147	YES |RESERVE(RMD-QSPEC):              S           |               |
2148	    |"forward - T tear"               s           |               |
2149	    |--------------->|  RESERVE(RMD-QSPEC):       |               |
2150	    |                |  "forward - T tear"        |               |
2151	    |                |--------------------------->|               |
2152	    |                |                S           |-------------->|
2153	    |                |                S         RESERVE(RMD-QSPEC):
2154	    |                |                S       "reverse - T tear"  |
2155	    |      RESERVE(RMD-QSPEC)         S           |<--------------|
2156	    |      "reverse - T tear"         S<----------|               |
2157	    |<--------------------------------S           |               |

2159	   Figure 20: Intra-domain RMD severe congestion handling for
2160	           bi-directional reservation (congestion on path QNE(Egress)
2161	           towards QNE(Ingress))

2163	4.7 Handling of additional errors

2165	   During the QSpec processing, additional errors may occur. The way
2166	   of how these additional errors are handled and notified is specified
2167	   in [QSP-T].

2169	5.  Security Consideration

2171	   A router implementing a QoS signaling protocol can, similar to a
2172	   router without QoS signaling, do a lot of harm to a system. A router
2173	   can delay, drop, inject, duplicate or modify packets. A certain
2174	   degree of trust is, therefore, always assumed in most systems.

2176	   The RMD QOSM aims to be very lightweight signaling with regard to
2177	   the number of signaling message roundtrips and the amount of state
2178	   established at involved signaling nodes with and without reduced
2179	   state on QNEs. This implies the usage of the Datagram Mode which
2180	   cannot benefit from security protection. As such, RMD signaling is
2181	   target towards intra-domain signaling only. Still it is possible
2182	   to provide some degree of security.

2184	   In the context of RMD QOSM signaling a classification between
2185	   in-path adversaries and off-path adversaries needs to be made.
2186	   Furthermore, it might be necessary to differentiate between always
2187	   off-path nodes and nodes which are only off-path with regard to a
2188	   specific signaling message.

2190	   The following paragraph aims to raise a discussion about the
2191	   requirements placed on the security properties of the signaling
2192	   message exchange:

2194	   First, it is necessary to protect the message communication between
2195	   the QNE Ingress and the QNE Egress. This is possible since these
2196	   nodes are meant to be stateful nodes and do not suffer from the same
2197	   constraints as network QNE Interior nodes. This mechanism already
2198	   ensures that intermediate or off-path nodes initiate some signaling
2199	   messages towards the edges. An adversary is therefore unable to
2200	   inject an NOTIFY message or a RESERVE message. Additionally, such a
2201	   security protection ensures that only selected fields can be
2202	   modified. To accomplish this type of protection two mechanisms need
2203	   to be considered that both require enhancements to the QoS NSLP.
2204	   Since the intra-domain RESERVE message travels along several
2205	   stateless nodes it is necessary to provide a protection at the
2206	   QoS-NSLP. Channel security at the GIMPS layer might in most cases
2207	   not be possible due to the nature of the NTLP datagram mode message.
2208	   One option is the usage of the Cryptographic Message Syntax (CMS) to
2209	   protect selected payloads at the QoS NSLP layer. A digital signature
2210	   is suitable if the QNE Ingress and the QNE Egress node do not need
2211	   to share a secret nor do they require an in-band exchange of
2212	   certificates due to the closed environment where a pre-distribution
2213	   of certificates can be assumed. Such a digital signature would
2214	   amount for about roughly 600 to 700 bytes of payloads within a
2215	   packet. Further implementation experience will be required to see
2216	   whether this message size is within the MTU limits for the entire
2217	   NSIS message. The usage of a digital signature for a one-shot packet
2218	   would, however, allow an adversary located within the intra-domain
2219	   network to flood the QNE Ingress or QNE Egress with digitally signed
2220	   messages. This would require heavy computation by the target nodes
2221	   and could lead to a denial of service. The usage of an out-of-band
2222	   authentication and key exchange protocol extending the Internet Key
2223	   Exchange Protocol using a Domain of Interpretation is a good
2224	   alternative. An example of this approach was exercised in [RSVP-DOI].

2226	   The QNE Ingress node should know its QNE Egress node based on e.g. an
2227	   end-to-end signaling communication. In the reverse direction routing
2228	   state has already been established as part of GIMPS signaling.

2230	   The congestion handling mechanism is very difficult to detect since
2231	   the malicious behavior might be hard to distinguish from regular
2232	   behavior. Hence, intrusion detection techniques and statistical
2233	   measurements could help to detect a malicious node within the RMD
2234	   aware network doamin. This technique has been suggested also for
2235	   DiffServ Codepoint packet marking (add ref. later). A general
2236	   observation can be made here that a router implementing a QoS
2237	   signaling protocol (and the RMD QOSM) can, similar to a router
2238	   without support for QoS signaling, do a lot of harm to a system.

2240	6.  IANA Considerations

2242	   RMD-QOSM requires a new IANA registry.

2244	7.  Open issues

2246	   This section describes the open issues related to the RMD QoS
2247	   signaling model.  More details on open issues will be provided in a
2248	   future version of this draft.

2250	7.1 Explicit congestion notification

2252	   Explicit congestion notification (ECN) described in RFC 3168 might
2253	   be used to complement RMD basic functions. Congestion notification
2254	   can be based on queue management, e.g. RED.

2256	8.  Acknowledgments

2258	   The authors express their acknowledgement to people who have worked
2259	   on the RMD concept: Z. Turanyi, R. Szabo, A. Csaszar, A. Takacs, G.
2260	   Pongracz, A. Marquetant, O. Pop, V. Rexhepi, D. Partain, M.
2261	   Jacobsson, S. Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M.
2262	   de Kogel,M. Zoumaro-djayoon, M. Swanink.

2264	9.  Authors' Addresses

2266	   Attila Bader
2267	   Traffic Lab
2268	   Ericsson Research
2269	   Ericsson Hungary Ltd.
2270	   Laborc 1
2271	   Budapest, Hungary, H-1037
2272	   EMail: Attila.Bader@ericsson.com

2274	   Lars Westberg
2275	   Ericsson Research
2276	   Torshamnsgatan 23
2277	   SE-164 80 Stockholm, Sweden
2278	   EMail: Lars.Westberg@ericsson.com

2280	   Georgios Karagiannis
2281	   University of Twente
2282	   P.O.  BOX 217
2283	   7500 AE Enschede, The Netherlands
2284	   EMail: g.karagiannis@ewi.utwente.nl

2286	   Cornelia Kappler
2287	   Siemens AG
2288	   Siemensdamm 62
2289	   Berlin 13627, Germany
2290	   Email: cornelia.kappler@siemens.com

2292	   Hannes Tschofenig
2293	   Siemens AG
2294	   Otto-Hahn-Ring 6
2295	   Munich  81739, Germany
2296	   EMail: Hannes.Tschofenig@siemens.com

2298	   Tom Phelan
2299	   Sonus Networks
2300	   250 Apollo Dr.
2301	   Chelmsford, MA USA 01824
2302	   EMail: tphelan@sonusnet.com

2304	10.  Normative References

2306	   [QoS-NSLP] Bosch, S., Karagiannis, G.  and A.  McDonald, "NSLP for
2307	   Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-05 (work
2308	   in progress), July 2005.

2310	   [QSP-T] Ash, J., Bader, A., Kappler C., "QoS-NSLP QSpec Template"
2311	   draft-ietf-nsis-QSpec-04 (work in progress), July 2005.

2313	11.  Informative References

2315	   [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
2316	   "Resource ReSerVation Protocol (RSVP)-- Version 1 Functional
2317	    Specification", IETF RFC 2205, 1997.

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

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

2327	   [GIMPS]  Schulzrinne, H., Hancock, R., "GIMPS: General Internet
2328	   Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-04
2329	   (work in progress), Oct 2004.

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

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

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

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

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

2349	   [RMD3] Marquetant A., Pop O., Szabo R., Dinnyes G., Turanyi Z.,
2350	   "Novel Enhancements to Load Control - A Soft-State, Lightweight
2351	   Admission Control Protocol", Proceedings of the 2nd International
2352	   Workshop on Quality of future Internet Services, Coimbra, Portugal,
2353	   Sept 24-26, 2001, pp. 82-96.

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

2358	   [RSVP-DOI] Tschofenig H., Schulzrinne H., "RSVP Domain of
2359	   Interpretation for ISAKMP ", draft-tschofenig-rsvp-doi-00.txt,
2360	   (work in progress), May 2003

2362	12.  Intellectual Property Statement

2364	   IPR Statement about RMD

2366	   I hereby give the following IPR Disclosure in relation to the RMD
2367	   concept proposed by Ericsson and currently under discussion in IEFT
2368	   WG NSIS:

2370	   To the best of my knowledge there are no Ericsson patents or filed
2371	   patent applications on RMD protocol operation or basic principles.
2372	   To my knowledge there is only one Ericsson patent application family
2373	   that could possibly be relevant merely to particular implementation
2374	   of RMD.  This patent family comprises US patent 6687655 and
2375	   counterparts in other countries.

2377	   To the best of my knowledge there is only one Ericsson owned
2378	   invention without any patent applications filed yet that could
2379	   possibly be relevant to particular implementation of RMD, but this
2380	   invention is not relevant to RMD protocol operation or basic
2381	   principles.

2383	   I have been authorized by Ericsson to give the following Licensing
2384	   Declaration in relation to the RMD concept proposed by Ericsson and
2385	   discussed in IEFT WG NSIS:

2387	   In case a license to a patent in the patent family above or a patent
2388	   issued/granted on an application for patent on the invention above
2389	   should be necessary for implementing any Internet Standard, Ericsson
2390	   is willing to grant to anybody a license to such patent on fair,
2391	   reasonable and non-discriminatory conditions for the implementation
2392	   of the standard, subject to reciprocity.

2394	   Attila Bader
2395	   The IETF takes no position regarding the validity or scope of any
2396	   Intellectual Property Rights or other rights that might be claimed
2397	   to pertain to the implementation or use of the technology
2398	   described in this document or the extent to which any license
2399	   under such rights might or might not be available; nor does it
2400	   represent that it has made any independent effort to identify any
2401	   such rights.  Information on the procedures with respect to rights
2402	   in RFC documents can be found in BCP 78 and BCP 79.

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

2411	   The IETF invites any interested party to bring to its attention
2412	   any copyrights, patents or patent applications, or other
2413	   proprietary rights that may cover technology that may be required
2414	   to implement this standard.  Please address the information to the
2415	   IETF at ietf-ipr@ietf.org.

2417	Disclaimer of Validity

2419	   This document and the information contained herein are provided
2420	   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
2421	   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
2422	   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
2423	   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
2424	   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
2425	   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
2426	   PARTICULAR PURPOSE.

2428	   Copyright (C) The Internet Society (2005).

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