tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5975

 
 
 

QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)

Part 3 of 4, p. 33 to 51
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 33 
5.  QSPEC Functional Specification

     This section defines the encodings of the QSPEC parameters.  We
     first give the general QSPEC formats and then the formats of the
     QSPEC objects and parameters.

     Network octet order ('big-endian') for all 16- and 32-bit integers,
     as well as 32-bit floating point numbers, is as specified in
     [RFC4506], [IEEE754], and [NETWORK-OCTET-ORDER].

5.1.  General QSPEC Formats

     The format of the QSPEC closely follows that used in GIST [RFC5971]
     and QoS NSLP [RFC5974].  Every object (and parameter) has the
     following general format:

Top      Up      ToC       Page 34 
   o  The overall format is Type-Length-Value (in that order).

   o  Some parts of the type field are set aside for control flags.

   o  Length has the units of 32-bit words, and measures the length of
      Value.  If there is no Value, Length=0.  The Object length
      excludes the header.

   o  Value is a whole number of 32-bit words.  If there is any padding
      required, the length and location MUST be defined by the object-
      specific format information; objects that contain variable-length
      types may need to include additional length subfields to do so.

   o  Any part of the object used for padding or defined as reserved
      ("r") MUST be set to 0 on transmission and MUST be ignored on
      reception.

   o  Empty QSPECs and empty QSPEC Objects MUST NOT be used.

   o  Duplicate objects, duplicate parameters, and/or multiple
      occurrences of a parameter MUST NOT be used.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Common QSPEC Header                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                       QSPEC Objects                         //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.1.  Common Header Format

   The Common QSPEC Header is a fixed 4-octet object containing the
   QSPEC Version, QSPEC Type, an identifier for the QSPEC Procedure (see
   Section 4.3), and an Initiator/Local QSPEC bit:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vers.|I|QSPECType|r|r|  QSPEC Proc.  |        Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers.: Identifies the QSPEC version number.  QSPEC Version 0 is
          assigned by this specification in Section 7 (IANA
          Considerations).

Top      Up      ToC       Page 35 
   QSPEC Type: Identifies the particular type of QSPEC, e.g., a QSPEC
               Type corresponding to a particular QOSM.  QSPEC Type 0
               (default) is assigned by this specification in Section 7
               (IANA Considerations).

   QSPEC Proc.: Identifies the QSPEC procedure and is composed of two
                times 4 bits.  The first field identifies the Message
                Sequence; the second field identifies the QSPEC Object
                Combination used for this particular message sequence:

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |Mes.Sq |Obj.Cmb|
                +-+-+-+-+-+-+-+-+

                The Message Sequence field can attain the following
                values:

                0: Sender-Initiated Reservations
                1: Receiver-Initiated Reservations
                2: Resource Queries

                The Object Combination field can take the values between
                1 and 3 indicated in the tables in Section 4.3:

                Message Sequence: 0
                Object Combination: 0, 1, 2
                Semantic: see Table 1 in Section 4.3.1

                Message Sequence: 1
                Object Combination: 0, 1, 2
                Semantic: see Table 2 in Section 4.3.2

                Message Sequence: 2
                Object Combination: 0
                Semantic: see Table 3 in Section 4.3.3

   I: Initiator/Local QSPEC bit identifies whether the QSPEC is an
      initiator QSPEC or a Local QSPEC, and is set to the following
      values:

               0: Initiator QSPEC
               1: Local QSPEC

   Length: The total length of the QSPEC (in 32-bit words) excluding the
           common header

Top      Up      ToC       Page 36 
   The QSPEC Objects field is a collection of QSPEC objects (QoS
   Desired, QoS Available, etc.), which share a common format and each
   contain several parameters.

5.1.2.  QSPEC Object Header Format

   QSPEC objects share a common header format:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|r|r|r|       Object Type     |r|r|r|r|         Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E Flag: Set if an error occurs on object level

   Object Type = 0: QoS Desired (parameters cannot be overwritten)
               = 1: QoS Available (parameters may be overwritten; see
                    Section 3.2)
               = 2: QoS Reserved (parameters cannot be overwritten)
               = 3: Minimum QoS (parameters cannot be overwritten)

   The r bits are reserved.

   Each QSPEC or QSPEC parameter within an object is encoded in the same
   way in TLV format using a similar parameter header:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|     Parameter ID      |r|r|r|r|         Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M Flag: When set, indicates the subsequent parameter MUST be
           interpreted.  Otherwise, the parameter can be ignored if not
           understood.

   E Flag: When set, indicates either a) a reservation failure where the
           QSPEC parameter is not met, or b) an error occurred when this
           parameter was being interpreted (see Section 4.2.1).

   N Flag: Not Supported QSPEC parameter flag (see Section 4.2.2).

   Parameter ID: Assigned consecutively to each QSPEC parameter.
                 Parameter IDs are assigned to each QSPEC parameter
                 defined in this document in Sections 5.2 and 7 (IANA
                 Considerations).

Top      Up      ToC       Page 37 
   Parameters are usually coded individually, for example, the <Excess
   Treatment> parameter (Section 5.2.11).  However, it is also possible
   to combine several sub-parameters into one parameter field, which is
   called 'container coding'.  This coding is useful if either a) the
   sub-parameters always occur together (as for example the 5 sub-
   parameters that jointly make up the TMOD), or b) in order to make
   coding more efficient when the length of each sub-parameter value is
   much less than a 32-bit word (as for example described in [RFC5977])
   and to avoid header overload.  When a container is defined, the
   Parameter ID and the M, E, and N flags refer to the container.
   Examples of container parameters are <TMOD> (specified below) and the
   PHR (Per Hop Reservation) container parameter specified in [RFC5977].

5.2.  QSPEC Parameter Coding

   The references in the following sections point to the normative
   procedures for processing the QSPEC parameters and sub-parameters.

5.2.1.  <TMOD-1> Parameter

   The <TMOD-1> parameter consists of the <r>, <b>, <p>, <m>, and <MPS>
   sub-parameters [RFC2212], which all must be populated in the <TMOD-1>
   parameter.  Note that a second TMOD QSPEC parameter <TMOD-2> is
   specified below in Section 5.2.2.

   The coding for the <TMOD-1> parameter is as follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|E|0|r|           1           |r|r|r|r|          5            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TMOD Rate-1 (r) (32-bit IEEE floating point number)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TMOD Size-1 (b) (32-bit IEEE floating point number)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Peak Data Rate-1 (p) (32-bit IEEE floating point number)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Minimum Policed Unit-1 (m) (32-bit unsigned integer)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Packet Size-1 (MPS) (32-bit unsigned integer)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <TMOD-1> parameters are represented by three floating point
   numbers in single-precision IEEE floating point format [IEEE754]
   followed by two 32-bit integers in network octet order.  The first
   floating point value is the rate (r), the second floating point value
   is the bucket size (b), the third floating point is the peak rate

Top      Up      ToC       Page 38 
   (p), the first unsigned integer is the minimum policed unit (m), and
   the second unsigned integer is the maximum packet size (MPS).  The
   values of r and p are measured in octets per second; b, m, and MPS
   are measured in octets.  When r, b, and p terms are represented as
   IEEE floating point values, the sign bit MUST be zero (all values
   MUST be non-negative).  Exponents less than 127 (i.e., 0) are
   prohibited.  Exponents greater than 162 (i.e., positive 35) are
   discouraged, except for specifying a peak rate of infinity.  Infinity
   is represented with an exponent of all ones (255), and a sign bit and
   mantissa of all zeroes.

5.2.2.  <TMOD-2> Parameter

   A second QSPEC <TMOD-2> parameter is specified as could be needed,
   for example, to support some Diffserv applications.

   The coding for the <TMOD-2> parameter is as follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           2           |r|r|r|r|          5            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TMOD Rate-2 (r) (32-bit IEEE floating point number)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TMOD Size-2 (b) (32-bit IEEE floating point number)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Peak Data Rate-2 (p) (32-bit IEEE floating point number)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Minimum Policed Unit-2 (m) (32-bit unsigned integer)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Packet Size-2 (MPS) (32-bit unsigned integer)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <TMOD-2> parameters are represented by three floating point
   numbers in single-precision IEEE floating point format [IEEE754]
   followed by two 32-bit integers in network octet order.  The first
   floating point value is the rate (r), the second floating point value
   is the bucket size (b), the third floating point is the peak rate
   (p), the first unsigned integer is the minimum policed unit (m), and
   the second unsigned integer is the maximum packet size (MPS).  The
   values of r and p are measured in octets per second; b, m, and MPS
   are measured in octets.  When r, b, and p terms are represented as
   IEEE floating point values, the sign bit MUST be zero (all values
   MUST be non-negative).  Exponents less than 127 (i.e., 0) are
   prohibited.  Exponents greater than 162 (i.e., positive 35) are

Top      Up      ToC       Page 39 
   discouraged, except for specifying a peak rate of infinity.  Infinity
   is represented with an exponent of all ones (255), and a sign bit and
   mantissa of all zeroes.

5.2.3.  <Path Latency> Parameter

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           3           |r|r|r|r|          1            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                Path Latency (32-bit unsigned integer)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path Latency [RFC2215] is a single 32-bit unsigned integer in
   network octet order.  The intention of the Path Latency parameter is
   the same as the Minimal Path Latency parameter defined in Section 3.4
   of [RFC2215].  The purpose of this parameter is to provide a baseline
   minimum path latency for use with services that provide estimates or
   bounds on additional path delay, such as in [RFC2212].  Together with
   the queuing delay bound offered by [RFC2212] and similar services,
   this parameter gives the application knowledge of both the minimum
   and maximum packet delivery delay.

   The composition rule for the <Path Latency> parameter is summation
   with a clamp of (2^32) - 1 on the maximum value.  The latencies are
   average values reported in units of one microsecond.  A system with
   resolution less than one microsecond MUST set unused digits to zero.
   An individual QNE can add a latency value between 1 and 2^28
   (somewhat over two minutes), and the total latency added across all
   QNEs can range as high as (2^32)-2.  If the sum of the different
   elements delays exceeds (2^32)-2, the end-to-end cumulative delay
   SHOULD be reported as indeterminate = (2^32)-1.  A QNE that cannot
   accurately predict the latency of packets it is processing MUST raise
   the Not Supported N flag and either leave the value of Path Latency
   as is, or add its best estimate of its lower bound.  A raised not-
   supported flag indicates the value of Path Latency is a lower bound
   of the real Path Latency.  The distinguished value (2^32)-1 is taken
   to mean indeterminate latency because the composition function limits
   the composed sum to this value; it indicates the range of the
   composition calculation was exceeded.

Top      Up      ToC       Page 40 
5.2.4.  <Path Jitter> Parameter

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           4           |r|r|r|r|          4            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |    Path Jitter STAT1(variance) (32-bit unsigned integer)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Path Jitter STAT3(minimum Latency) (32-bit unsigned integer)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Path Jitter STAT4(Reserved)     (32-bit unsigned integer)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path Jitter is a set of four 32-bit unsigned integers in network
   octet order [RFC3393, Y.1540, Y.1541].  As noted in Section 3.3.2,
   the Path Jitter parameter is called "IP Delay Variation" in
   [RFC3393].  The Path Jitter parameter is the combination of four
   statistics describing the Jitter distribution with a clamp of (2^32)
   - 1 on the maximum of each value.  The jitter STATs are reported in
   units of one microsecond.  A system with resolution less than one
   microsecond MUST set unused digits to zero.  An individual QNE can
   add jitter values between 1 and 2^28 (somewhat over two minutes), and
   the total jitter computed across all QNEs can range as high as
   (2^32)-2.  If the combination of the different element values exceeds
   (2^32)-2, the end-to-end cumulative jitter SHOULD be reported as
   indeterminate.  A QNE that cannot accurately predict the jitter of
   packets it is processing MUST raise the not-supported flag and either
   leave the value of Path Jitter as is, or add its best estimate of its
   STAT values.  A raised not-supported flag indicates the value of Path
   Jitter is a lower bound of the real Path Jitter.  The distinguished
   value (2^32)-1 is taken to mean indeterminate jitter.  A QNE that
   cannot accurately predict the jitter of packets it is processing
   SHOULD set its local Path Jitter parameter to this value.  Because
   the composition function limits the total to this value, receipt of
   this value at a network element or application indicates that the
   true Path Jitter is not known.  This MAY happen because one or more
   network elements could not supply a value or because the range of the
   composition calculation was exceeded.

   NOTE: The Jitter composition function makes use of the <Path Latency>
   parameter.  Composition functions for loss, latency, and jitter may
   be found in [Y.1541].  Development continues on methods to combine
   jitter values to estimate the value of the complete path, and
   additional statistics may be needed to support new methods (the
   methods are standardized in [RFC5481] and [COMPOSITION]).

Top      Up      ToC       Page 41 
5.2.5.  <Path PLR> Parameter

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           5           |r|r|r|r|          1            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |             Path Packet Loss Ratio (32-bit floating point)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path PLR is a single 32-bit single precision IEEE floating point
   number in network octet order [Y.1541].  As defined in [Y.1540], Path
   PLR is the ratio of total lost IP packets to total transmitted IP
   packets.  An evaluation interval of 1 minute is suggested in
   [Y.1541], in which the number of losses observed is directly related
   to the confidence in the result.  The composition rule for the <Path
   PLR> parameter is summation with a clamp of 10^-1 on the maximum
   value.  The PLRs are reported in units of 10^-11.  A system with
   resolution less than 10^-11 MUST set unused digits to zero.  An
   individual QNE adds its local PLR value (up to a maximum of 10^-2) to
   the total Path PLR value (up to a maximum of 10^-1) , where the
   acceptability of the total Path PLR value added across all QNEs is
   determined based on the QOSM being used.  The maximum limit of 10^-2
   on a QNE's local PLR value and the maximum limit (clamp value) of
   10^-1 on the accumulated end-to-end Path PLR value are used to
   preserve the accuracy of the simple additive accumulation function
   specified and to avoid more complex accumulation functions.
   Furthermore, if these maximums are exceeded, then the path would
   likely not meet the QoS objectives.  If the sum of the different
   elements' values exceeds 10^-1, the end-to-end cumulative PLR SHOULD
   be reported as indeterminate.  A QNE that cannot accurately predict
   the PLR of packets it is processing MUST raise the not-supported flag
   and either leave the value of Path PLR as is, or add its best
   estimate of its lower bound.  A raised not-supported flag indicates
   the value of Path PLR is a lower bound of the real Path PLR.  The
   distinguished value 10^-1 is taken to mean indeterminate PLR.  A QNE
   that cannot accurately predict the PLR of packets it is processing
   SHOULD set its local path PLR parameter to this value.  Because the
   composition function limits the composed sum to this value, receipt
   of this value at a network element or application indicates that the
   true path PLR is not known.  This MAY happen because one or more
   network elements could not supply a value or because the range of the
   composition calculation was exceeded.

Top      Up      ToC       Page 42 
5.2.6.  <Path PER> Parameter

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           6           |r|r|r|r|          1            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |             Path Packet Error Ratio (32-bit floating point)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path PER is a single 32-bit single precision IEEE floating point
   number in network octet order [Y.1541].  As defined in [Y.1540], Path
   PER is the ratio of total errored IP packets to the total of
   successful IP Packets plus errored IP packets, in which the number of
   errored packets observed is directly related to the confidence in the
   result.  The composition rule for the <Path PER> parameter is
   summation with a clamp of 10^-1 on the maximum value.  The PERs are
   reported in units of 10^-11.  A system with resolution less than
   10^-11 MUST set unused digits to zero.  An individual QNE adds its
   local PER value (up to a maximum of 10^-2) to the total Path PER
   value (up to a maximum of 10^-1) , where the acceptability of the
   total Path PER value added across all QNEs is determined based on the
   QOSM being used.  The maximum limit of 10^-2 on a QNE's local PER
   value and the maximum limit (clamp value) of 10^-1 on the accumulated
   end-to-end Path PER value are used to preserve the accuracy of the
   simple additive accumulation function specified and to avoid more
   complex accumulation functions.  Furthermore, if these maximums are
   exceeded, then the path would likely not meet the QoS objectives.  If
   the sum of the different elements' values exceeds 10^-1, the end-to-
   end cumulative PER SHOULD be reported as indeterminate.  A QNE that
   cannot accurately predict the PER of packets it is processing MUST
   raise the Not Supported N flag and either leave the value of Path PER
   as is, or add its best estimate of its lower bound.  A raised Not
   Supported N flag indicates the value of Path PER is a lower bound of
   the real Path PER.  The distinguished value 10^-1 is taken to mean
   indeterminate PER.  A QNE that cannot accurately predict the PER of
   packets it is processing SHOULD set its local path PER parameter to
   this value.  Because the composition function limits the composed sum
   to this value, receipt of this value at a network element or
   application indicates that the true path PER is not known.  This MAY
   happen because one or more network elements could not supply a value
   or because the range of the composition calculation was exceeded.

Top      Up      ToC       Page 43 
5.2.7.  <Slack Term> Parameter

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           7           |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Slack Term (S)  (32-bit unsigned integer)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Slack term S MUST be nonnegative and is measured in microseconds
   [RFC2212].  The Slack term, S, is represented as a 32-bit unsigned
   integer.  Its value can range from 0 to (2^32)-1 microseconds.

5.2.8.  <Preemption Priority> and <Defending Priority> Parameters

   The coding for the <Preemption Priority> and <Defending Priority>
   sub-parameters is as follows [RFC3181]:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           8           |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Preemption Priority        |      Defending Priority       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Preemption Priority: The priority of the new flow compared with the
      defending priority of previously admitted flows.  Higher values
      represent higher priority.

   Defending Priority: Once a flow is admitted, the preemption priority
      becomes irrelevant.  Instead, its defending priority is used to
      compare with the preemption priority of new flows.

   As specified in [RFC3181], <Preemption Priority> and <Defending
   Priority> are 16-bit integer values, and both MUST be populated if
   the parameter is used.

Top      Up      ToC       Page 44 
5.2.9.  <Admission Priority> Parameter

   The coding for the <Admission Priority> parameter is as follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           9           |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Y.2171 Adm Pri.|Admis. Priority|        (Reserved)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Two fields are provided for the <Admission Priority> parameter and
   are populated according to the following rules.

   <Y.2171 Admission Priority> values are globally significant on an
   end-to-end basis.  High priority flows, normal priority flows, and
   best-effort priority flows can have access to resources depending on
   their admission priority value, as described in [Y.2171], as follows:

   <Y.2171 Admission Priority>:

   0 - best-effort priority flow
   1 - normal priority flow
   2 - high priority flow

   If the QNI signals <Y.2171 Admission Priority>, it populates both the
   <Y.2171 Admission Priority> and <Admission Priority> fields with the
   same value.  Downstream QNEs MUST NOT change the value in the <Y.2171
   Admission Priority> field so that end-to-end consistency is
   maintained and MUST treat the flow priority according to the value
   populated.  A QNE in a local domain MAY reset a different value of
   <Admission Priority> in a Local QSPEC, but (as specified in Section
   4.1) the Local QSPEC MUST be consistent with the Initiator QSPEC.
   That is, the local domain MUST specify an <Admission Priority> in the
   Local QSPEC that is functionally equivalent to the <Y.2171 Admission
   Priority> specified by the QNI in the Initiator QSPEC.

   If the QNI signals admission priority according to [EMERGENCY-RSVP],
   it populates a locally significant value in the <Admission Priority>
   field and places all ones in the <Y.2171 Admission Priority> field.
   In this case, the functional significance of the <Admission Priority>
   value is specified by the local network administrator.  Higher values
   indicate higher priority.  Downstream QNEs and RSVP nodes MAY reset
   the <Admission Priority> value according to the local rules specified
   by the local network administrator, but MUST NOT reset the value of
   the <Y.2171 Admission Priority> field.

Top      Up      ToC       Page 45 
   A reservation without an <Y.2171 Admission Priority> parameter MUST
   be treated as a reservation with an <Y.2171 Admission Priority> = 1.

5.2.10.  <RPH Priority> Parameter

   The coding for the <RPH Priority> parameter is as follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           10          |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         RPH Namespace         | RPH Priority  |   (Reserved)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   [RFC4412] defines a resource priority header (RPH) with parameters
   "RPH Namespace" and "RPH Priority", and if populated is applicable
   only to flows with high admission priority.  A registry is created in
   [RFC4412] and extended in [EMERG-RSVP] for IANA to assign the RPH
   priority parameter.  In the extended registry, "Namespace Numerical
   Values" are assigned by IANA to RPH Namespaces and "Priority
   Numerical Values" are assigned to the RPH Priority.

   Note that the <Admission Priority> parameter MAY be used in
   combination with the <RPH Priority> parameter, which depends on the
   supported QOSM.  Furthermore, if more than one RPH namespace is
   supported by a QOSM, then the QOSM MUST specify how the mapping
   between the priorities belonging to the different RPH namespaces are
   mapped to each other.

   Note also that additional work is needed to communicate these flow
   priority values to bearer-level network elements
   [VERTICAL-INTERFACE].

   For the 4 priority parameters, the following cases are permissible
   (procedures specified in references):

   1 parameter:  <Admission Priority> [Y.2171]
   2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
   2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
   3 parameters: <Preemption Priority>, <Defending Priority>,
                 <Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
   4 parameters: <Preemption Priority>, <Defending Priority>,
                 <Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
                 3GPP-3]

Top      Up      ToC       Page 46 
   It is permissible to have <Admission Priority> without <RPH
   Priority>, but not permissible to have <RPH Priority> without
   <Admission Priority>.  (Alternatively, <RPH Priority> is ignored in
   instances without <Admission Priority>.)

   Functionality similar to enhanced Multi-Level Precedence and
   Preemption service (eMLPP; as defined in [3GPP-1, 3GPP-2]) specifies
   use of <Admission Priority> corresponding to the 'queuing allowed'
   part of eMLPP, as well as <Preemption/Defending Priority>
   corresponding to the 'preemption capable' and 'may be preempted'
   parts of eMLPP.

5.2.11.  <Excess Treatment> Parameter

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           11          |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Excess Trtmnt |Re-mark Val|             Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Excess Treatment: Indicates how the QNE SHOULD process out-of-profile
      traffic, that is, traffic not covered by the <TMOD> parameter.
      The Excess Treatment Parameter is set by the QNI.  Allowed values
      are as follows:

      0: drop
      1: shape
      2: re-mark
      3: no metering or policing is permitted

      If no Excess Treatment Parameter is specified, the default is that
      there are no guarantees to excess traffic, i.e., a QNE can do
      whatever it finds suitable.

      When excess treatment is set to 'drop', all marked traffic MUST be
      dropped by the QNE/RMF.

      When excess treatment is set to 'shape', it is expected that the
      QoS Desired object carries a TMOD parameter, and excess traffic is
      shaped to this TMOD.  The bucket size in the TMOD parameter for
      excess traffic specifies the queuing behavior, and when the
      shaping causes unbounded queue growth at the shaper, any traffic
      in excess of the TMOD for excess traffic SHOULD be dropped.  If
      excess treatment is set to 'shape' and no TMOD parameter is given,
      the E flag is set for the parameter and the reservation fails.  If

Top      Up      ToC       Page 47 
      excess treatment is set to 'shape' and two TMOD parameters are
      specified, then the QOSM specification dictates how excess traffic
      should be shaped in that case.

      When excess treatment is set to 're-mark', the Excess Treatment
      Parameter MUST carry the re-mark value, and the re-mark values and
      procedures MUST be specified in the QOSM specification document.
      For example, packets may be re-marked to pertain to a particular
      QoS class (Diffserv Code Point (DSCP) value).  In the latter case,
      re-marking relates to a Diffserv model where packets arrive marked
      as belonging to a certain QoS class / DSCP, and when they are
      identified as excess, they should then be re-marked to a different
      QoS Class (DSCP value) indicated in the 'Re-mark Value', as
      follows:

   Re-mark Value (6 bits): indicates DSCP value [RFC2474] to re-mark
      packets to when identified as excess

   If 'no metering or policing is permitted' is signaled, the QNE should
   accept the Excess Treatment Parameter set by the sender with special
   care so that excess traffic should not cause a problem.  To request
   the Null Meter [RFC3290] is especially strong, and should be used
   with caution.

   A NULL metering application [RFC2997] would not include the traffic
   profile, and conceptually it should be possible to support this with
   the QSPEC.  A QSPEC without a traffic profile is not excluded by the
   current specification.  However, note that the traffic profile is
   important even in those cases when the excess treatment is not
   specified, e.g., in negotiating bandwidth for the best-effort
   aggregate.  However, a "NULL Service QOSM" would need to be specified
   where the desired QNE Behavior and the corresponding QSPEC format are
   described.

   As an example behavior for a NULL metering, in the properly
   configured Diffserv router, the resources are shared between the
   aggregates by the scheduling disciplines.  Thus, if the incoming rate
   increases, it will influence the state of a queue within that
   aggregate, while all the other aggregates will be provided sufficient
   bandwidth resources.  NULL metering is useful for best-effort and
   signaling data, where there is no need to meter and police this data
   as it will be policed implicitly by the allocated bandwidth and,
   possibly, active queue management mechanism.

Top      Up      ToC       Page 48 
5.2.12.  <PHB Class> Parameter

   The coding for the <PHB Class> parameter is as follows [RFC3140]:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           12          |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PHB Field           |            (Reserved)         |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The above encoding is consistent with [RFC3140], and the following
   four figures show four possible formats based on the value of the PHB
   Field.

   Single PHB:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | DSCP      |0 0 0 0 0 0 0 0 0 0|
      +---+---+---+---+---+---+---+---+

   Set of PHBs:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | DSCP      |0 0 0 0 0 0 0 0 1 0|
      +---+---+---+---+---+---+---+---+

   PHBs not defined by standards action, i.e., experimental or local use
   PHBs as allowed by [RFC2474].  In this case, an arbitrary 12-bit PHB
   identification code, assigned by the IANA, is placed left-justified
   in the 16-bit field.  Bit 15 is set to 1, and bit 14 is zero for a
   single PHB or 1 for a set of PHBs.  Bits 12 and 13 are zero.

   Single non-standard PHB (experimental or local):

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      PHB ID CODE      |0 0 0 1|
      +---+---+---+---+---+---+---+---+

Top      Up      ToC       Page 49 
   Set of non-standard PHBs (experimental or local):

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      PHB ID CODE      |0 0 1 1|
      +---+---+---+---+---+---+---+---+

   Bits 12 and 13 are reserved either for expansion of the PHB
   identification code, or for other use, at some point in the future.

   In both cases, when a single PHBID is used to identify a set of PHBs
   (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB
   Scheduling Class (i.e., use of PHBs from the set MUST NOT cause
   intra-microflow traffic reordering when different PHBs from the set
   are applied to traffic in the same microflow).  The set of AF1x PHBs
   [RFC2597] is an example of a PHB Scheduling Class.  Sets of PHBs that
   do not constitute a PHB Scheduling Class can be identified by using
   more than one PHBID.

   The registries needed to use RFC 3140 already exist; see
   [DSCP-REGISTRY] and [PHBID-CODES-REGISTRY].  Hence, no new registry
   needs to be created for this purpose.

5.2.13.  <DSTE Class Type> Parameter

   A description of the semantic of the parameter values can be found in
   [RFC4124].  The coding for the <DSTE Class Type> parameter is as
   follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           13          |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |DSTE Cls. Type |                (Reserved)                     |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   DSTE Class Type: Indicates the DSTE class type.  Values currently
   allowed are 0, 1, 2, 3, 4, 5, 6, and 7.

Top      Up      ToC       Page 50 
5.2.14.  <Y.1541 QoS Class> Parameter

   The coding for the <Y.1541 QoS Class> parameter [Y.1541] is as
   follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|E|N|r|           14          |r|r|r|r|          1            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Y.1541 QoS Cls.|                (Reserved)                     |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Y.1541 QoS Class: Indicates the Y.1541 QoS Class.  Values currently
   allowed are 0, 1, 2, 3, 4, 5, 6, and 7.

      Class 0:
      Real-time, highly interactive applications, sensitive to jitter.
      Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <=
      10^-3.  Application examples include VoIP and video
      teleconference.

      Class 1:
      Real-time, interactive applications, sensitive to jitter.  Mean
      delay <= 400 ms, delay variation <= 50 ms, and loss ratio <=
      10^-3.  Application examples include VoIP and video
      teleconference.

      Class 2:
      Highly interactive transaction data.  Mean delay <= 100 ms, delay
      variation is unspecified, loss ratio <= 10^-3.  Application
      examples include signaling.

      Class 3:
      Interactive transaction data.  Mean delay <= 400 ms, delay
      variation is unspecified, loss ratio <= 10^-3.  Application
      examples include signaling.

      Class 4:
      Low Loss Only applications.  Mean delay <= 1 s, delay variation is
      unspecified, loss ratio <= 10^-3.  Application examples include
      short transactions, bulk data, and video streaming.

      Class 5:
      Unspecified applications with unspecified mean delay, delay
      variation, and loss ratio.  Application examples include
      traditional applications of default IP networks.

Top      Up      ToC       Page 51 
      Class 6:
      Applications that are highly sensitive to loss.  Mean delay <= 100
      ms, delay variation <= 50 ms, and loss ratio <= 10^-5.
      Application examples include television transport, high-capacity
      TCP transfers, and Time-Division Multiplexing (TDM) circuit
      emulation.

      Class 7:
      Applications that are highly sensitive to loss.  Mean delay <= 400
      ms, delay variation <= 50 ms, and loss ratio <= 10^-5.
      Application examples include television transport, high-capacity
      TCP transfers, and TDM circuit emulation.



(page 51 continued on part 4)

Next RFC Part