RFC 5975
QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
Pages: 64
Experimental
Experimental
Part 3 of 4 – Pages 33 to 51
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:
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).
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
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).
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
(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
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.
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]).
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.
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.
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.
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.
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]
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
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.
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| +---+---+---+---+---+---+---+---+
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.
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.
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)