Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC

From: Gerald Ash <[email-masked]>
Date: Mon, 1 Mar 2010 11:20:25 -0800 (PST)

Minor editorial comments:
 
1. page 35:
"  the "Peak Data Rate-1 (p)" value of the <Bandwdith> parameter.
   When the QNE edges use aggregated intra-domain QoS-NSLP operational
   states, then the "Peak Data Rate-1 (p)" value of the <Bandwdith>"
substitute <TMOD-1> for <Bandwdith> 
 
2. page 101:
"  directions by using the procedure described in Section 4.6.2.3 and
   including in the  <Bandwith> parameter within the "RMD-QOSM QOS
   Description" field carried by the "forward" intra-domain RESERVE the"
substitute <TMOD-1> for <Bandwith>
 
Thanks,
Jerry

--- On Mon, 3/1/10, The IESG <[email-masked]> wrote:

From: The IESG <[email-masked]>
Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
To: "IETF-Announce" <[email-masked]>
Cc: [email-masked]
Date: Monday, March 1, 2010, 9:38 AM

The IESG has received a request from the Next Steps in Signaling WG 
(nsis) to consider the following document:

- 'RMD-QOSM - The Resource Management in Diffserv QOS Model '
   <draft-ietf-nsis-rmd-16.txt> as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2010-03-22. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-16.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12558&rfc_flag=0

_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 2 Mar 2010 10:33:12 +0100

Hi Jerry
 
Thank you very much for the catch!
 
We will update the draft accordingly!
 
Best regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gerald Ash
Sent: maandag 1 maart 2010 20:20
To: [email-masked]; [email-masked]
Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The
ResourceManagement in Diffserv QOS Model) to Experimental RFC

1. page 35:
 
2. page 101:
"  directions by using the procedure described in Section 4.6.2.3 <>  and
   including in the  <Bandwith> parameter within the "RMD-QOSM QOS
   Description" field carried by the "forward" intra-domain RESERVE the"
substitute <TMOD-1> for <Bandwith>
 
Thanks,
Jerry

From: The IESG <[email-masked]>
Subject: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource
Management in Diffserv QOS Model) to Experimental RFC
To: "IETF-Announce" <[email-masked]>
Cc: [email-masked]
Date: Monday, March 1, 2010, 9:38 AM

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] <http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>
mailing lists by 2010-03-22. Exceptionally, 
comments may be sent to [email-masked]
<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>  instead. In
either case, please 
retain the beginning of the Subject line to allow automated sorting.

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=125
58&rfc_flag=0> &dTag=12558&rfc_flag=0

_______________________________________________
nsis mailing list
[email-masked] <http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]> 
https://www.ietf.org/mailman/listinfo/nsis

---

From: Gerald Ash <[email-masked]>
Date: Tue, 2 Mar 2010 10:39:11 -0800 (PST)

One more comment:
 
Section 3.1 of the QSPEC draft http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.1 lists requirements for QOSM specifications including "QNE processing rules describing how QSPEC information is treated and interpreted"and "at least one bit-level QSPEC example".
 
While the RMD draft has examples in Appendix A of individual processing functions, there is no overall, end-to-end example given of QSPEC composition and processing from QNI to QNR and back again.  IMO this would greatly help an overall understanding of RMD functionality.
 
Such QSPEC processing examples are given in Sections 4.4 ("Processing Example") and 4.5 ("Bit-Level QSPEC Example") of the Y.1541-QOSM draft (http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.4)
and
Section 3.4 ("Example of QSPEC Processing") of the QSPEC draft (http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.4).
 
Thanks,
Jerry

--- On Mon, 3/1/10, Gerald Ash <[email-masked]> wrote:

From: Gerald Ash <[email-masked]>
Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
To: [email-masked], [email-masked]
Cc: "Jerry Ash" <[email-masked]>
Date: Monday, March 1, 2010, 2:20 PM

1. page 35:
 
2. page 101:
 
Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 02 Mar 2010 22:02:52 +0000

Hi Jerry

We will include in the Appendix a similar example as the one given in
Section 3.4 of the QSPEC draft.

Best regards,
Georgios

On 3/2/2010, "Gerald Ash" <[email-masked]> wrote:

>Section 3.4 ("Example of QSPEC Processing") of the QSPEC draft (http://toolsietf.org/html/draft-ietf-nsis-qspec-24#section-3.4).
> 
>Thanks,
>Jerry
>
>      )

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 18 Mar 2010 08:39:48 +0000

Hi all

Based on the suggestion of Jerry we have written an example on matching
the initiator QSPEC to a local RMD-QSPEC, see below!

We would like to include this section in Appendix A.6 of the new version
of the RMD-QOSM draft.

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

A.6.  Example on matching the initiator QSPEC to the local RMD-QSPEC

   Section 3.4 of [QSP-T] describes an example of how the QSPEC can be
used
   within QOS-NSLP. Figure A.4 illustrates a situation where a QNI and a
   QNR are using an end to end QOSM, denoted in this context as Z-e2e. It
   is considered that the QNI access network side is a wireless access
   network built on a generation "X" technology with QoS support as
defined
   by generation "X", while QNR access network is a wired/fixed access
   network with its own defined QoS support. Furthermore, it is considered
   that the shown QNE edges are located at the boundary of a RMD domain
and
   that the shown QNE Interior nodes are located inside the RMD domain.
The
   QNE edges are able to run both the Z-e2e QOSM and the RMD-QOSM, while
   the QNE interior nodes can only run the RMD-QOSM. The QNI that is
   considered to e.g., be a wireless laptop, while the QNR a PC.

     |------|   |------|                           |------|   |------|
     |Z-e2e |<->|Z-e2e |<------------------------->|Z-e2e |<->|Z-e2e |
     | QOSM |   | QOSM |                           | QOSM |   | QOSM |
     |      |   |------|   |-------|   |-------|   |------|   |      |
     | NSLP |   | NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP |   | NSLP |
     |Z-e2e |   |  RMD |   |  RMD  |   |  RMD  |   | RMD  |   | Z-e2e|
     | QOSM |   | QOSM |   | QOSM  |   | QOSM  |   | QOSM |   | QOSM |
     |------|   |------|   |-------|   |-------|   |------|   |------|
     -----------------------------------------------------------------
     |------|   |------|   |-------|   |-------|   |------|   |------|
     | NTLP |<->| NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP |<->| NTLP |
     |------|   |------|   |-------|   |-------|   |------|   |------|
       QNI         QNE        QNE         QNE         QNE       QNR
     (End)  (Ingress Edge) (Interior)  (Interior) (Egress Edge)  (End)

       Figure A.4. Example of Initiator & Local Domain QOSM Operation

   The QNI sets QoS Desired and QoS Available QSPEC objects in the
   initiator QSPEC, and initializes QoS Available to QoS Desired. In this
   example, the <Minimum QoS> object is not populated. The QNI populates
   QSPEC parameters to ensure correct treatment of its traffic in domains
   down the path. Additionally, to ensure correct treatment further down
   the path, the QNI includes <PHB Class> in <QoS Desired>.  The QNI
   therefore includes in the QSPEC

     QoS Desired = <TMOD> <PHB Class>
     QoS Available = <TMOD> <Path Latency>

   In this example it is assumed that the <TMOD> parameter is used to
   encode the traffic parameters of a VoIP application that uses RTP and
   the G.711 Codec, see Appendix B in [QSP-T].
   The below text is copied from [QSP-T].

   "In the simplest case the Minimum Policed Unit m is the sum of the
   IP-, UDP- and RTP- headers + payload. The IP header in the IPv4 case
   has a size of 20 octets (40 octets if IPv6 is used). The UDP header
   has a size of 8 octets and RTP uses a 12 octet header. The G.711
   Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming
   RTP transmits voice datagrams every 20ms, the payload for one
   datagram is 8000 octets/s * 0.02 s = 160 octets.

   IPv4+UDP+RTP+payload: m=20+8+12+160 octets = 200 octets
   IPv6+UDP+RTP+payload: m=40+8+12+160 octets = 220 octets

   The Rate r specifies the amount of octets per second. 50 datagrams
   Are sent per second.

   IPv4: r = 50 1/s * m = 10,000 octets/s
   IPv6: r = 50 1/s * m = 11,000 octets/s

   The bucket size b specifies the maximum burst. In this example a
   burst of 10 packets is used.

   IPv4: b = 10 * m = 2000 octets
   IPv6: b = 10 * m = 2200 octets ", from [QSP-T].

   In our example we will assume that IPV4 is used and therefore, the
   <TMOD-1> values will be set as follows:

   m = 200 octets
   r = 10000 octets/s
   b = 2000 octets

   The Peak Data Rate-1 (p) and MPS are not specified above, but in our
   example we will assume:

   p = r = 10000 octets/s
   MPS = 220 octets.

   The <PHB Class> is set in such a way that the Expedited Forwarding
   (EF) PHB is used.
   Since <Path Latency> and <QoS Class> are not vital parameters from
   the QNI's perspective, it does not raise their M flags.

   Each QNE, which supports the Z-e2e QOSM on the path, reads and
   interprets those parameters in the initiator QSPEC.

   When an end-to-end RESERVE message is received at a QNE Ingress node
   at the RMD domain border then the QNE ingress can 'hide' the
initiator
   end-to-end RESERVE message so that only the QNE edges process the
   initiator (end-to-end) RESERVE message, which then bypasses
   intermediate nodes between the edges of the domain, and issues its own
   local RESERVE message (see Section 6).  For this new local RESERVE
   message, the QNE Ingress node generates the local RMD-QSpec. The
   RMD-QSpec corresponding to the RMD-QOSM is generated based on
   the original initiator QSPEC according to the procedures described in
   Section 4.5 of [QoS-NSLP] and in Section 6 of this draft.  The RMD QNE
   ingress maps the <TMOD-1> parameters contained in the original
initiator
   QSPEC into the equivalent <TMOD-1> parameter representing only the peak
   bandwidth in the local RMD-QSpec.

   In this example the initial <TMOD-1> parameters are mapped into the
   RMD-QSpec <TMOD-1> parameters as follows.

   As specified the RMD-QOSM bandwidth equivalent <TMOD-1> parameter of
   RMD-QSpec should have:

      r = p of initial e2e <TMOD-1> parameter
      m = large;
      b = large;

   For the RMD-QSpec <TMOD-1> parameter the following values are
   calculated:

      r = p of initial e2e <TMOD-1> parameter = 10000 octets/s
      m is set in this example to large as follows:
      m = MPS of initial e2e <TMOD-1> parameter = 220 octets

   The maximum value of b = 250 Gbytes, but in our example this value is
   quite large. The b parameter specifies the extent to which the data
rate
   can exceed the sustainable level for short periods of time.
   In order to get a large b, in this example we consider that for a
   period of certain period of time the data rate can exceed the
   sustainable level, which in our example is the peak rate (p).

   Thus in our example we calculate b as:

      b = p * MPS * "period of time".

   For this VoIP example, we can assume that this period of time is 1,5
   seconds, see below:

      b = 10000 octets/s * 220 octets * 1,5 seconds = 3300000 octets

   Thus the local RMD-QSpec <TMOD-1> values are:

      r = 10000 octets/s
      p = 10000 octets/s
      m = 220 octets
      b = 3300000 octets
      MPS = 220 octets

   The local RMD QSPEC for example also needs <PHB Class>, which in this
   example is representing the EF PHB class.

   The RMD QNE egress node updates QoS Available on behalf of the entire
   RMD domain if it can.  If it cannot (since the M flag is not set for
   <Path Latency>) it raises the parameter-specific, 'not-supported'
flag,
   warning the QNR that the final latency value in QoS Available is
   imprecise.

   In the "Y" access domain, the initiator QSPEC is processed by the QNR
   in the similar was as it was processed in the "X" wireless access
   domain, by the QNI. If the reservation was successful, eventually the
   RESERVE request arrives at the QNR (otherwise the QNE at which the
   reservation failed would have aborted the RESERVE and sent an error
   RESPONSE back to the QNI).  If the RII was included in the QoS NSLP
   message, the QNR generates a positive RESPONSE with QSPEC objects QoS
   Reserved and QoS Available.  The parameters appearing in QoS Reserved
   are the same as in QoS Desired, with values copied from QoS Available.
   Hence, the QNR includes the following QSPEC objects in the RESPONSE:

    QoS Reserved = <TMOD> <PHB Class>
    QoS Available = <TMOD> <Path Latency>

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

Best regards,

Georgios

---

From: Gerald Ash <[email-masked]>
Date: Fri, 19 Mar 2010 10:48:39 -0700 (PDT)

Looks good, and adds clarity to how RMD-QOSM functions.  Two comments:
 
1. RE
"   Thus in our example we calculate b as:

      b = 10000 octets/s * 220 octets * 1,5 seconds = 3300000 octets"
 
IMO the above expression should not be multiplied by MPS, but rather should be
 
"   Thus in our example we calculate b as:

      b = p * "period of time".

   For this VoIP example, we can assume that this period of time is 1.5
   seconds, see below:

      b = 10000 octets/s * 1.5 seconds = 15000 octets"
 
Or, alternatively, b = ~ 68 MPS-size packets.
 
Also, perhaps the "1.5" notation should be used rather than the "1,5" notation?
 
2. It would further clarify if you put in the bit-level example of the RMD-QSPEC, as called for by QOSM requirements given in the QSPEC draft.  E.g., such a bit-level QSPEC example is given in Section 4.5 ("Bit-Level QSPEC Example") of the Y.1541-QOSM draft (http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.5).  This would clarify, for example, the QSPEC Procedure being used and other bit-level details.
 
Thanks,
Jerry

--- On Thu, 3/18/10, Georgios Karagiannis <[email-masked]> wrote:

From: Georgios Karagiannis <[email-masked]>
Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
To: "Gerald Ash" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thursday, March 18, 2010, 4:39 AM

Hi all

   m = 200 octets
   r = 10000 octets/s
   b = 2000 octets

   p = r = 10000 octets/s
   MPS = 220 octets.

      r = 10000 octets/s
      p = 10000 octets/s
      m = 220 octets
      b = 3300000 octets
      MPS = 220 octets

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

Best regards,

Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 20 Mar 2010 01:24:54 +0000

Hi Jerry

Thanks for the comments!

Please see in line!

>      b = 10000 octets/s * 1.5 seconds = 15000 octets"

Georgios: Okay, we will include this change!

>2. It would further clarify if you put in the bit-level example of the RMD-QSPEC, as called for by QOSM requirements given in the QSPEC draft.  E.g., such a bit-level QSPEC example is given in Secti…

Georgios: but this is already specified in Section 4.1. We could include
a sentence in the appendix: "The bit level format of the RMD-QSPEC is
specified in Section 4.1."

Best regards,
Georgios
r

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 20 Mar 2010 03:50:55 +0000

Hi Jerry

Based on your latest comments I have changed the new appendix section
A.6, see below:

   Section 3.4 of [QSP-T] describes an example of how the QSPEC can be
   Used within QOS-NSLP. Figure A.4 illustrates a situation where a QNI
   and a QNR are using an end to end QOSM, denoted in this context as Z-
   e2e. It is considered that the QNI access network side is a wireless
   access network built on a generation "X" technology with QoS support
   as defined by generation "X", while QNR access network is a
   wired/fixed access network with its own defined QoS support.
   Furthermore, it is considered that the shown QNE edges are located at
   the boundary of a RMD domain and that the shown QNE Interior nodes
   are located inside the RMD domain.
   The QNE edges are able to run both the Z-e2e QOSM and the RMD-QOSM,
   while the QNE interior nodes can only run the RMD-QOSM. The QNI that
   is considered to e.g., be a wireless laptop, while the QNR a PC.

   The QNI sets QoS Desired and QoS Available QSPEC objects in the
   initiator QSPEC, and initializes QoS Available to QoS Desired. In
   this example, the <Minimum QoS> object is not populated. The QNI
   populates QSPEC parameters to ensure correct treatment of its traffic
   in domains down the path. Additionally, to ensure correct treatment
   further down the path, the QNI includes <PHB Class> in <QoS Desired>.
   The QNI therefore includes in the QSPEC

   m = 200 octets
   r = 10000 octets/s
   b = 2000 octets

   p = r = 10000 octets/s
   MPS = 220 octets.

   When an end-to-end RESERVE message is received at a QNE Ingress node
   at the RMD domain border then the QNE ingress can 'hide' the
   initiator end-to-end RESERVE message so that only the QNE edges
   process the initiator (end-to-end) RESERVE message, which then
   bypasses intermediate nodes between the edges of the domain, and
   issues its own local RESERVE message (see Section 6).  For this new
   local RESERVE message, the QNE Ingress node generates the local RMD-
   QSpec. The RMD-QSpec corresponding to the RMD-QOSM is generated based
   on the original initiator QSPEC according to the procedures described
   in Section 4.5 of [QoS-NSLP] and in Section 6 of this draft.  The RMD
   QNE ingress maps the <TMOD-1> parameters contained in the original
   Initiator QSPEC into the equivalent <TMOD-1> parameter representing
   only the peak bandwidth in the local RMD-QSpec.

   rate can exceed the sustainable level for short periods of time.

      b = 10000 octets/s * 1.5 seconds = 15000 octets

      r = 10000 octets/s
      p = 10000 octets/s
      m = 220 octets
      b = 15000 octets
      MPS = 220 octets

   The bit level format of the RMD-QSPEC can be derived from Section 4.1.

   The RMD QNE egress node updates QoS Available on behalf of the entire
   RMD domain if it can.  If it cannot (since the M flag is not set for
   <Path Latency>) it raises the parameter-specific, 'not-supported'
   flag, warning the QNR that the final latency value in QoS Available
   is imprecise.

   are the same as in QoS Desired, with values copied from QoS
   Available. Hence, the QNR includes the following QSPEC objects in the

   RESPONSE:

Best regards,
Georgios

On 3/20/2010, "Georgios Karagiannis" <[email-masked]> wrote:

>>   For this VoIP example, we can assume that this period of time is 15
>>   seconds, see below:
>>
>>   QNR are using an end to end QOSM, denoted in this context as Z-e2e It

---

From: Gerald Ash <[email-masked]>
Date: Mon, 22 Mar 2010 12:11:00 -0700 (PDT)

Georgios,
 
I think it would be good to also include a bit-level example of the RMD-QSPEC, such as given in Section 4.5 of the Y.1541-QOSM draft (http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.5).  For one thing, the QSPEC specification requires "at least one bit-level QSPEC example" be given for all QOSM specifications (see Section 3.1 in http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.1).  Furthermore, an RMD-QSPEC example would add clarity to the RMD-QOSM specification and not be very difficult to include IMO.
 
Thanks,
Jerry

--- On Fri, 3/19/10, Georgios Karagiannis <[email-masked]> wrote:

From: Georgios Karagiannis <[email-masked]>
Subject: Re: [NSIS] Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
To: "Gerald Ash" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Friday, March 19, 2010, 11:50 PM

Hi Jerry

   m = 200 octets
   r = 10000 octets/s
   b = 2000 octets

   p = r = 10000 octets/s
   MPS = 220 octets.

      r = 10000 octets/s
      p = 10000 octets/s
      m = 220 octets
      b = 15000 octets
      MPS = 220 octets

   RESPONSE:

Best regards,
Georgios

---

From: Gerald Ash <[email-masked]>
Date: Mon, 22 Mar 2010 12:30:19 -0700 (PDT)

Hi Georgios,
 
RE:

>> 2. It would further clarify if you put in the bit-level example of the RMD-QSPEC, 
>> as called for by QOSM requirements given in the QSPEC draft.  E.g., such a 
>> bit-level QSPEC example is given in Section 4.5 ("Bit-Level QSPEC Example") 
>> of the Y.1541-QOSM draft
>> (http://tools.ietf.org/html/draft-ietf-nsis-y1541-qosm-10#section-4.5).  
>> This would clarify, for example, the QSPEC Procedure being used and other
>> bit-level details.

> specified in Section 4.1."
 
I don't see a full bit-level RMD-QSPEC example in Section 4.1  For one thing, the QSPEC header isn't given.  IMO it would be better to include a full bit-level example, including headers, etc., somewhere in Appendix A.
 
Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 22 Mar 2010 23:23:53 +0000

Hi Jerry

In my opinion the required bit example format is already
specified in Section 4.1.
I do not think that it is usefull to duplicate the information that
is already givel elsewhere and copy it into this section.

Regarding the bit level format example, what we are willing to do
is to inlcude the following text in the Appendix A.6, instead of copying
figures from elsewhere.

"The bit level format of the RMD-QSpec is given in Section 4.1. In
particular, The Initiator/Local QSPEC bit, i.e., <I> is set to "Local"
(i.e.,
   "1") and the <Qspec Proc> is set as follows:
   * Message Sequence = 0: Sender initiated
   * Object combination = 0: <QoS Desired> for RESERVE and
     <QoS Reserved> for RESPONSE

 The <QSPEC Version> used by RMD-QOSM is the default version, i.e.,
 "0", see [QSP-T]. The <QSPEC Type> value used by the RMD-QOSM is
 specified in [QSP-T] and is equal to: "2".
 The <Traffic Handling Directives> contains the following fields:

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

 The Per Hop Reservation container (PHR container) and
 the Per Domain Reservation container (PDR container) are specified
 in Section 4.1.2 and 4.1.3, respectively. The <PHR container>
 contains the traffic handling directives for intra-domain
 communication and reservation.  The <PDR container> contains
 additional traffic handling directives that is needed for
 edge-to-edge communication. The RMD-QOSM <QoS Desired> and
<QoS Reserved>, are specified in  Section 4.1.1.
In RMD-QOSM the <QoS Desired> and <QoS Reserved> objects contain the
following parameters:

 <QoS Desired> = <TMOD-1> <PHB Class> <Admission Priority>
 <QoS Reserved> = <TMOD-1> <PHB Class> <Admission Priority>

 The bit format of the <PHB Class> (see [QSP-T] and Figure 4 and
 Figure 5) and <Admission Priority> complies to the bit format
 specified in [QSP-T].

 Note that for this example the RMD reservation is established without an
 <Admission Priority> parameter, which is equivalent to a reservation
 established with an <Admission Priority> whose value is 1."

Best regards,
Georgios