tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5975

 
 
 

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

Part 2 of 4, p. 7 to 33
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 7 
3. QSPEC Framework

   The overall framework for the QoS NSLP is that [RFC5974] defines QoS
   signaling and semantics, the QSPEC template defines the container and
   semantics for QoS parameters and objects, and informational
   specifications define QoS methods and procedures for using QoS
   signaling and QSPEC parameters/objects within specific QoS
   deployments.  QoS NSLP is a generic QoS signaling protocol that can
   signal for many QOSMs.

3.1.  QoS Models

   A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ
   Controlled Load [CL-QOSM], Resource Management with Diffserv
   [RFC5977], and QoS signaling for Y.1541 QoS classes [RFC5976].  A
   QOSM specifies a set of QSPEC parameters that describe the QoS
   desired and how resources will be managed by the RMF.  The RMF
   implements functions that are related to resource management and
   processes the QSPEC parameters.

   QOSMs affect the operation of the RMF in NSIS-capable nodes and the
   information carried in QSPEC objects.  Under some circumstances
   (e.g., aggregation), they may cause a separate NSLP session to be
   instantiated by having the RMF as a QNI.  QOSM specifications may
   define RMF triggers that cause the QoS NSLP to run semantics within
   the underlying QoS NSLP signaling state and messaging processing
   rules, as defined in Section 5.2 of [RFC5974].  New QoS NSLP message
   processing rules can only be defined in extensions to QoS NSLP.  If a
   QOSM specification defines triggers that deviate from existing QoS
   NSLP processing rules, the fallback for QNEs not supporting that QOSM
   are the QoS NSLP state transition/message processing rules.

   The QOSM specification includes how the requested QoS resources will
   be described and how they will be managed by the RMF.  For this
   purpose, the QOSM specification defines a set of QSPEC parameters it
   uses to describe the desired QoS and resource control in the RMF, and
   it may define additional QSPEC parameters.

Top      Up      ToC       Page 8 
   When a QoS NSLP message travels through different domains, it may
   encounter different QOSMs.  Since QOSMs use different QSPEC
   parameters for describing resources, the QSPEC parameters included by
   the QNI may not be understood in other domains.  The QNI therefore
   can flag those QSPEC parameters it considers vital with the M flag.
   QSPEC parameters with the M flag set must be interpreted by the
   downstream QNEs, or the reservation fails.  QSPEC parameters without
   the M flag set should be interpreted by the downstream QNEs, but may
   be ignored if not understood.

   A QOSM specification SHOULD include the following:

   - role of QNEs, e.g., location, frequency, statefulness, etc.
   - QSPEC definition including QSPEC parameters
   - QSPEC procedures applicable to this QOSM
   - QNE processing rules describing how QSPEC information is treated
     and interpreted in the RMF, e.g., admission control, scheduling,
     policy control, QoS parameter accumulation (e.g., delay)
   - at least one bit-level QSPEC example
   - QSPEC parameter behavior for new QSPEC parameters that the QOSM
     specification defines
   - a definition of what happens in case of preemption if the default
     QNI behavior (teardown preempted reservation) is not followed (see
     Section 4.3.5)

   A QOSM specification MAY include the following:

   - definitions of additional QOSM-specific error codes, as discussed
     in Section 4.2.3
   - the QoS-NSLP options a QOSM wants to use, when several options are
     available for a QOSM (e.g., Local QSPEC to either a) hide the
     Initiator QSPEC within a local domain message, or b) encapsulate
     the Initiator QSPEC).

   QOSMs are free, subject to IANA registration and review rules, to
   extend QSPECs by adding parameters of any of the kinds supported by
   the QSPEC.  This includes traffic description parameters, constraint
   parameters, and traffic handling directives.  QOSMs are not
   permitted, however, to reinterpret or redefine the QSPEC parameters
   specified in this document.  Note that signaling functionality is
   only defined by the QoS NSLP document [RFC5974] and not by this
   document or by QOSM specification documents.

Top      Up      ToC       Page 9 
3.2.  QSPEC Objects

   The QSPEC is the object of QoS NSLP containing QSPEC objects and
   parameters.  QSPEC objects are the main building blocks of the QSPEC
   parameter set that is input or output of an RMF operation.  QSPEC
   parameters are the parameters appearing in a QSPEC, which must
   include the traffic model parameter (TMOD), and may optionally
   include constraints (e.g., path latency), traffic handling directives
   (e.g., excess treatment), and traffic classifiers (e.g., PHB class).
   The RMF implements functions that are related to resource management
   and processes the QSPEC parameters.

   The QSPEC consists of a QSPEC version number and QSPEC objects.  IANA
   assigns a new QSPEC version number when the current version is
   deprecated or deleted (as required by a specification).  Note that a
   new QSPEC version number is not needed when new QSPEC parameters are
   specified.  Later QSPEC versions MUST be backward compatible with
   earlier QSPEC versions.  That is, a version n+1 device must support
   QSPEC version n (or earlier).  On the other hand, if a QSPEC version
   n (or earlier) device receives an NSLP message specifying QSPEC
   version n+1, then the version n device responds with an 'Incompatible
   QSPEC' error code (0x0f) response, as discussed in Section 4.2.3,
   allowing the QNE that sent the NSLP message to retry with a lower
   QSPEC version.

   This document provides a template for the QSPEC in order to promote
   interoperability between QOSMs.  Figure 1 illustrates how the QSPEC
   is composed of up to 4 QSPEC objects, namely QoS Desired, QoS
   Available, QoS Reserved, and Minimum QoS.  Each of these QSPEC
   objects consists of a number of QSPEC parameters.  A given QSPEC may
   contain only a subset of the QSPEC objects, e.g., QoS Desired.  The
   QSPEC objects QoS Desired, QoS Available, QoS Reserved and Minimum
   QoS MUST all be supported by QNEs and MAY appear in any QSPEC object
   carried in any QoS NSLP message (RESERVE, QUERY, RESPONSE, NOTIFY).
   See [RFC5974] for descriptions of the QoS NSLP RESERVE, QUERY,
   RESPONSE, and NOTIFY messages.

Top      Up      ToC       Page 10 
   +---------------------------------------+
   |            QSPEC Objects              |
   +---------------------------------------+

   \________________ ______________________/
                    V
   +----------+----------+---------+-------+
   |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
   +----------+----------+---------+-------+

   \____ ____/\___ _____/\___ ____/\__ ___/
        V         V          V        V

   +-------------+...     +-------------+...
   |QSPEC Para. 1|        |QSPEC Para. n|
   +-------------+...     +-------------+...

       Figure 1: Structure of the QSPEC

   Use of the 4 QSPEC objects (QoS Desired, QoS Available, QoS Reserved,
   and Minimum QoS) is described in Section 4.3 for 3 message sequences
   and 7 object combinations.

   The QoS Desired Object describe the resources the QNI desires to
   reserve, and hence this is a read-only QSPEC object in that the QSPEC
   parameters carried in the object may not be overwritten.  QoS Desired
   is always included in a RESERVE message and sometimes included in the
   QUERY message (see Section 4.3 for details).

   As described in Section 4.3, the QoS Available object may travel in a
   RESERVE message, RESPONSE Message, or QUERY message and may collect
   information on the resources currently available on the path.  In
   this case, QoS Available is a read-write object, which means the
   QSPEC parameters contained in QoS Available may be updated, but they
   cannot be deleted.  As such, each QNE MUST inspect all parameters of
   this QSPEC object, and if resources available to this QNE are less
   than what a particular parameter says currently, the QNE MUST adapt
   this parameter accordingly.  Hence, when the message arrives at the
   recipient of the message, <QoS Available> reflects the bottleneck of
   the resources currently available on a path.  It can be used in a
   QUERY message, for example, to collect the available resources along
   a data path.

   When QoS Available travels in a RESPONSE message, it in fact just
   transports the result of a previous measurement performed by a
   RESERVE or QUERY message back to the initiator.  Therefore, in this

Top      Up      ToC       Page 11 
   case, QoS Available is read-only.  In one other instance described in
   Section 4.3.2 (Case 3), QoS Available is sent by the QNI in a RESERVE
   message as a read-only QSPEC object (see Section 4.3.2 for details).

   The QoS Reserved object reflects the resources that are being
   reserved.  It is a read-only object and is always included in a
   RESPONSE message if QoS Desired is included in the RESERVE message
   (see Section 4.3 for details).

   Minimum QoS does not have an equivalent in RSVP.  It allows the QNI
   to define a range of acceptable QoS levels by including both the
   desired QoS value and the minimum acceptable QoS in the same message.
   Note that the term "minimum" is used generically, since for some
   parameters, such as loss rate and latency, what is specified is the
   maximum acceptable value.  It is a read-only object, and may be
   included in a RESERVE message, RESPONSE message, or QUERY message
   (see Section 4.3 for details).  The desired QoS is included with a
   QoS Desired and/or a QoS Available QSPEC object seeded to the desired
   QoS value.  The minimum acceptable QoS value MAY be coded in the
   Minimum QoS QSPEC object.  As the message travels towards the QNR,
   QoS Available is updated by QNEs on the path.  If its value drops
   below the value of Minimum QoS, the reservation fails and is aborted.
   When this method is employed, the QNR signals back to the QNI the
   value of QoS Available attained in the end, because the reservation
   may need to be adapted accordingly (see Section 4.3 for details).

   Note that the relationship of QSPEC objects to RSVP objects is
   covered in Appendix A.

3.3.  QSPEC Parameters

   QSPEC parameters provide a common language for building QSPEC
   objects.  This document defines a number of QSPEC parameters;
   additional parameters may be defined in separate QOSM specification
   documents.  For example, QSPEC parameters are defined in [RFC5976]
   and [RFC5977].

   One QSPEC parameter, <TMOD>, is special.  It provides a description
   of the traffic for which resources are reserved.  This parameter must
   be included by the QNI, and it must be interpreted by all QNEs.  All
   other QSPEC parameters are populated by a QNI if they are applicable
   to the underlying QoS desired.  For these QSPEC parameters, the QNI
   sets the M flag if they must be interpreted by downstream QNEs.  If
   QNEs cannot interpret the parameter, the reservation fails.  QSPEC
   parameters populated by a QNI without the M flag set should be
   interpreted by downstream QNEs, but may be ignored if not understood.

Top      Up      ToC       Page 12 
   In this document, the term 'interpret' means, in relation to RMF
   processing of QSPEC parameters, that the RMF processes the QSPEC
   parameter according to the commonly accepted normative procedures
   specified by references given for each QSPEC parameter.  Note that a
   QNE need only interpret a QSPEC parameter if it is populated in the
   QSPEC object by the QNI; if not populated in the QSPEC, the QNE does
   not interpret it of course.

   Note that when an ingress QNE in a local domain defines a Local QSPEC
   and encapsulates the Initiator QSPEC, the QNEs in the interior local
   domain need only process the Local QSPEC and can ignore the Initiator
   (encapsulated) QSPEC.  However, edge QNEs in the local domain indeed
   must interpret the QSPEC parameters populated in the Initiator QSPEC
   with the M flag set and should interpret QSPEC parameters populated
   in the Initiator QSPEC without the M flag set.

   As described in the previous section, QoS parameters may be
   overwritten depending on which QSPEC object and which message they
   appear in.

3.3.1.  Traffic Model Parameter

   The <Traffic Model> (TMOD) parameter is mandatory for the QNI to
   include in the Initiator QSPEC and mandatory for downstream QNEs to
   interpret.  The traffic description specified by the TMOD parameter
   is a container consisting of 5 sub-parameters [RFC2212]:

   o  rate (r) specified in octets per second
   o  bucket size (b) specified in octets
   o  peak rate (p) specified in octets per second
   o  minimum policed unit (m) specified in octets
   o  maximum packet size (MPS) specified in octets

   The TMOD parameter takes the form of a token bucket of rate (r) and
   bucket size (b), plus a peak rate (p), minimum policed unit (m), and
   maximum packet size (MPS).

   Both b and r MUST be positive.  The rate, r, is measured in octets of
   IP packets per second, and can range from 1 octet per second to as
   large as 40 teraoctets per second.  The bucket depth, b, is also
   measured in octets and can range from 1 octet to 250 gigaoctets.  The
   peak rate, p, is measured in octets of IP packets per second and has
   the same range and suggested representation as the bucket rate.

   The peak rate is the maximum rate at which the source and any
   reshaping (defined below) may inject bursts of traffic into the
   network.  More precisely, it is a requirement that for all time
   periods the amount of data sent cannot exceed MPS+pT, where MPS is

Top      Up      ToC       Page 13 
   the maximum packet size and T is the length of the time period.
   Furthermore, p MUST be greater than or equal to the token bucket
   rate, r.  If the peak rate is unknown or unspecified, then p MUST be
   set to infinity.

   The minimum policed unit, m, is an integer measured in octets.  All
   IP packets less than size m will be counted, when policed and tested
   for conformance to the TMOD, as being of size m.

   The maximum packet size, MPS, is the biggest packet that will conform
   to the traffic specification; it is also measured in octets.  The
   flow MUST be rejected if the requested maximum packet size is larger
   than the MTU of the link.  Both m and MPS MUST be positive, and m
   MUST be less than or equal to MPS.

   Policing compares arriving traffic against the TMOD parameters at the
   edge of the network.  Traffic is policed to ensure it conforms to the
   token bucket.  Reshaping attempts to restore the (possibly distorted)
   traffic's shape to conform to the TMOD parameters, and traffic that
   is in violation of the TMOD is discovered because the reshaping fails
   and the reshaping buffer overflows.

   The token bucket and peak rate parameters require that traffic MUST
   obey the rule that over all time periods, the amount of data sent
   cannot exceed MPS+min[pT, rT+b-MPS], where r and b are the token
   bucket parameters, MPS is the maximum packet size, and T is the
   length of the time period (note that when p is infinite, this reduces
   to the standard token bucket requirement).  For the purposes of this
   accounting, links MUST count packets that are smaller than the
   minimum policing unit as being of size m.  Packets that arrive at an
   element and cause a violation of the MPS + min[pT, rT+b-MPS] bound
   are considered non-conformant.

   All 5 of the sub-parameters MUST be included in the TMOD parameter.
   The TMOD parameter can be set to describe the traffic source.  If,
   for example, TMOD is set to specify bandwidth only, then set r = peak
   rate = p, b = large, and m = large.  As another example, if TMOD is
   set for TCP traffic, then set r = average rate, b = large, and p =
   large.

   When the 5 TMOD sub-parameters are included in QoS Available, they
   provide information, for example, about the TMOD resources available
   along the path followed by a data flow.  The value of TMOD at a QNE
   is an estimate of the TMOD resources the QNE has available for
   packets following the path up to the next QNE, including its outgoing
   link, if this link exists.  Furthermore, the QNI MUST account for the
   resources of the ingress link, if this link exists.  Computation of

Top      Up      ToC       Page 14 
   the value of this parameter SHOULD take into account all information
   available to the QNE about the path, taking into consideration
   administrative and policy controls, as well as physical resources.

   The output composed value is the minimum of the QNE's value and the
   input composed value for r, b, p, and MPS, and the maximum of the
   QNE's value and the input composed value for m.  This quantity, when
   composed end-to-end, informs the QNR (or QNI in a RESPONSE message)
   of the minimal TMOD resources along the path from QNI to QNR.

   Two TMOD parameters are defined in Section 5, <TMOD-1> and <TMOD-2>,
   where the second parameter (<TMOD-2>) is specified as could be needed
   to support some Diffserv applications.  For example, it is typically
   assumed that Diffserv Expedited Forwarding (EF) traffic is shaped at
   the ingress by a single rate token bucket.  Therefore, a single TMOD
   parameter is sufficient to signal Diffserv EF traffic.  However, for
   Diffserv Assured Forwarding (AF) traffic, two sets of token bucket
   parameters are needed -- one for the average traffic and one for the
   burst traffic.  [RFC2697] defines a Single Rate Three Color Marker
   (srTCM), which meters a traffic stream and marks its packets
   according to three traffic parameters, Committed Information Rate
   (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be
   either green, yellow, or red.  A packet is marked green if it does
   not exceed the CBS; yellow if it does exceed the CBS, but not the
   EBS; and red otherwise.  [RFC2697] defines specific procedures using
   two token buckets that run at the same rate.  Therefore, 2 TMOD
   parameters are sufficient to distinguish among 3 levels of drop
   precedence.  An example is also described in the Appendix to
   [RFC2597].

3.3.2.  Constraints Parameters

   <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QSPEC
   parameters describing the desired path latency, path jitter, packet
   loss ratio, and path packet error ratio, respectively.  Since these
   parameters are cumulative, an individual QNE cannot decide whether
   the desired path latency, etc., is available, and hence they cannot
   decide whether a reservation fails.  Rather, when these parameters
   are included in <Desired QoS>, the QNI SHOULD also include
   corresponding parameters in a QoS Available QSPEC object in order to
   facilitate collecting this information.

   The <Path Latency> parameter accumulates the latency of the packet
   forwarding process associated with each QNE, where the latency is
   defined to be the mean packet delay, measured in microseconds, added
   by each QNE.  This delay results from the combination of link
   propagation delay, packet processing, and queuing.  Each QNE MUST add
   the propagation delay of its outgoing link, if this link exists.

Top      Up      ToC       Page 15 
   Furthermore, the QNI SHOULD add the propagation delay of the ingress
   link, if this link exists.  The composition rule for the <Path
   Latency> parameter is summation with a clamp of (2^32) - 1 on the
   maximum value.  This quantity, when composed end-to-end, informs the
   QNR (or QNI in a RESPONSE message) of the minimal packet delay along
   the path from QNI to QNR.  The purpose of this parameter is to
   provide a minimum path latency for use with services that provide
   estimates or bounds on additional path delay [RFC2212].

   The <Path Jitter> parameter accumulates the jitter of the packet
   forwarding process associated with each QNE, where the jitter is
   defined to be the nominal jitter, measured in microseconds, added by
   each QNE.  IP packet jitter, or delay variation, is defined in
   [RFC3393], Section 3.4 (Type-P-One-way-ipdv), and where the [RFC3393]
   selection function includes the packet with minimum delay such that
   the distribution is equivalent to 2-point delay variation in
   [Y.1540].  The suggested evaluation interval is 1 minute.  This
   jitter results from packet-processing limitations, and includes any
   variable queuing delay that may be present.  Each QNE MUST add the
   jitter of its outgoing link, if this link exists.  Furthermore, the
   QNI SHOULD add the jitter of the ingress link, if this link exists.
   The composition method for the <Path Jitter> parameter is the
   combination of several statistics describing the delay variation
   distribution with a clamp on the maximum value (note that the methods
   of accumulation and estimation of nominal QNE jitter are specified in
   clause 8 of [Y.1541]).  This quantity, when composed end-to-end,
   informs the QNR (or QNI in a RESPONSE message) of the nominal packet
   jitter along the path from QNI to QNR.  The purpose of this parameter
   is to provide a nominal path jitter for use with services that
   provide estimates or bounds on additional path delay [RFC2212].

   The <Path PLR> parameter is the unit-less ratio of total lost IP
   packets to total transmitted IP packets.  <Path PLR> accumulates the
   packet loss ratio (PLR) of the packet-forwarding process associated
   with each QNE, where the PLR is defined to be the PLR added by each
   QNE.  Each QNE MUST add the PLR of its outgoing link, if this link
   exists.  Furthermore, the QNI MUST add the PLR of the ingress link,
   if this link exists.  The composition rule for the <Path PLR>
   parameter is summation with a clamp on the maximum value. (This
   assumes sufficiently low PLR values such that summation error is not
   significant; however, a more accurate composition function is
   specified in clause 8 of [Y.1541].)  This quantity, when composed
   end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
   minimal packet PLR along the path from QNI to QNR.

   Packet error ratio [Y.1540, Y.1541] is the unit-less ratio of total
   errored IP packet outcomes to the total of successful IP packet
   transfer outcomes plus errored IP packet outcomes in a population of

Top      Up      ToC       Page 16 
   interest, with a resolution of at least 10^-9.  If lesser resolution
   is available in a value, the unused digits MUST be set to zero.  Note
   that the number of errored packets observed is directly related to
   the confidence in the result.  The <Path PER> parameter accumulates
   the packet error ratio (PER) of the packet forwarding process
   associated with each QNE, where the PER is defined to be the PER
   added by each QNE.  Each QNE MUST add the PER of its outgoing link,
   if this link exists.  Furthermore, the QNI SHOULD add the PER of the
   ingress link, if this link exists.  The composition rule for the
   <Path PER> parameter is summation with a clamp on the maximum value.
   (This assumes sufficiently low PER values such that summation error
   is not significant; however, a more accurate composition function is
   specified in clause 8 of [Y.1541].)  This quantity, when composed
   end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
   minimal packet PER along the path from QNI to QNR.

   The slack term parameter is the difference between desired delay and
   delay obtained by using bandwidth reservation, and it is used to
   reduce the resource reservation for a flow [RFC2212].

3.3.3.  Traffic-Handling Directives

   An application MAY like to reserve resources for packets and also
   specify a specific traffic-handling behavior, such as <Excess
   Treatment>.  In addition, as discussed in Section 3.1, an application
   MAY like to define RMF triggers that cause the QoS NSLP to run
   semantics within the underlying QoS NSLP signaling state / messaging
   processing rules, as defined in Section 5.2 of [RFC5974].  Note,
   however, that new QoS NSLP message processing rules can only be
   defined in extensions to the QoS NSLP.  As with constraints
   parameters and other QSPEC parameters, Traffic Handling Directives
   parameters may be defined in QOSM specifications in order to provide
   support for QOSM-specific resource management functions.  Such QOSM-
   specific parameters are already defined, for example, in [RFC5976],
   [RFC5977], and [CL-QOSM].  Generally, a Traffic Handling Directives
   parameters is expected to be set by the QNI in <QoS Desired>, and to
   not be included in <QoS Available>.  If such a parameter is included
   in <QoS Available>, QNEs may change their value.

   The <Preemption Priority> parameter is the priority of the new flow
   compared with the <Defending Priority> of previously admitted flows.
   Once a flow is admitted, the preemption priority becomes irrelevant.
   The <Defending Priority> parameter is used to compare with the
   preemption priority of new flows.  For any specific flow, its
   preemption priority MUST always be less than or equal to the
   defending priority.  <Admission Priority> and <RPH Priority> provide
   an essential way to differentiate flows for emergency services,
   Emergency Telecommunications Service (ETS), E911, etc., and assign

Top      Up      ToC       Page 17 
   them a higher admission priority than normal priority flows and best-
   effort priority flows.

   The <Excess Treatment> parameter describes how the QNE will process
   out-of-profile traffic.  Excess traffic MAY be dropped, shaped,
   and/or re-marked.

3.3.4.  Traffic Classifiers

   An application MAY like to reserve resources for packets with a
   particular Diffserv per-hop behavior (PHB) [RFC2475].  Note that PHB
   class is normally set by a downstream QNE to tell the QNI how to mark
   traffic to ensure the treatment that is designated by admission
   control; however, setting of the parameter by the QNI is not
   precluded.  An application MAY like to reserve resources for packets
   with a particular QoS class, e.g., Y.1541 QoS class [Y.1541] or
   Diffserv-aware MPLS traffic engineering (DSTE) class type [RFC3564,
   RFC4124].  These parameters are useful in various QOSMs, e.g.,
   [RFC5976], [RFC5977], and other QOSMs yet to be defined (e.g., DSTE-
   QOSM).  This is intended to provide guidelines to QOSMs on how to
   encode these parameters; use of the PHB class parameter is
   illustrated in the example in the following section.

3.4.  Example of QSPEC Processing

   This section illustrates the operation and use of the QSPEC within
   the NSLP.  The example configuration in shown in Figure 2.

   +----------+      /-------\       /--------\       /--------\
   | Laptop   |     |   Home  |     |  Cable   |     | Diffserv |
   | Computer |-----| Network |-----| Network  |-----| Network  |----+
   +----------+     | No QOSM |     |DQOS QOSM |     | RMD QOSM |    |
                     \-------/       \--------/       \--------/     |
                                                                     |
                     +-----------------------------------------------+
                     |
                     |    /--------\      +----------+
                     |   |    XG    |     | Handheld |
                     +---| Wireless |-----|  Device  |
                         | XG QOSM  |     +----------+
                          \--------/

      Figure 2: Example Configuration of QoS-NSLP/QSPEC Operation

   In this configuration, a laptop computer and a handheld wireless
   device are the endpoints for some application that has QoS
   requirements.  Assume initially that the two endpoints are stationary
   during the application session, later we consider mobile endpoints.

Top      Up      ToC       Page 18 
   For this session, the laptop computer is connected to a home network
   that has no QoS support.  The home network is connected to a
   CableLabs-type cable access network with dynamic QoS (DQOS) support,
   such as specified in the [DQOS] for cable access networks.  That
   network is connected to a Diffserv core network that uses the
   Resource Management in Diffserv QoS Model [RFC5977].  On the other
   side of the Diffserv core is a wireless access network built on
   generation "X" technology with QoS support as defined by generation
   "X".  And finally, the handheld endpoint is connected to the wireless
   access network.

   We assume that the laptop is the QNI, and the handheld device is the
   QNR.  The QNI will signal an Initiator QSPEC object to achieve the
   QoS desired on the path.

   The QNI sets QoS Desired, QoS Available, and possibly Minimum QoS
   QSPEC objects in the Initiator QSPEC, and initializes QoS Available
   to QoS Desired.  Each QNE on the path reads and interprets those
   parameters in the Initiator QSPEC and checks to see if QoS Available
   resources can be reserved.  If not, the QNE reduces the respective
   parameter values in QoS Available and reserves these values.  The
   minimum parameter values are given in Minimum QoS, if populated; they
   are zero if Minimum QoS is not included.  If one or more parameters
   in QoS Available fails to satisfy the corresponding minimum values in
   Minimum QoS, the QNE generates a RESPONSE message to the QNI and the
   reservation is aborted.  Otherwise, the QNR generates a RESPONSE to
   the QNI with the QoS Available for the reservation.  If a QNE cannot
   reserve QoS Desired resources, the reservation fails.

   The QNI populates QSPEC parameters to ensure correct treatment of its
   traffic in domains down the path.  Let us assume the QNI wants to
   achieve QoS guarantees similar to IntServ Controlled Load service,
   and also is interested in what path latency it can achieve.
   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>

   Since <Path Latency> and <PHB Class> are not vital parameters from
   the QNI's perspective, it does not raise their M flags.

   There are three possibilities when a RESERVE message is received at a
   QNE at a domain border; they are described in the example:

   - the QNE just leaves the QSPEC as is.

Top      Up      ToC       Page 19 
   - the QNE can add a Local QSPEC and encapsulate the Initiator QSPEC
     (see discussion in Section 4.1; this is new in QoS NSLP -- RSVP
     does not do this).

   - the QNE can 'hide' the initiator RESERVE message so that only the
     edge QNE processes the initiator RESERVE message, which then
     bypasses intermediate nodes between the edges of the domain and
     issues its own local RESERVE message (see Section 3.3.1 of
     [RFC5974]).  For this new local RESERVE message, the QNE acts as
     the QNI, and the QSPEC in the domain is an Initiator QSPEC.  A
     similar procedure is also used by RSVP in making aggregate
     reservations, in which case there is not a new intra-domain
     (aggregate) RESERVE for each newly arriving inter-domain (per-flow)
     RESERVE, but the aggregate reservation is updated by the border QNE
     (or QNI) as need be.  This is also how RMD works [RFC5977].

   For example, at the RMD domain, a local RESERVE with its own RMD
   Initiator QSPEC corresponding to the RMD-QOSM is generated based on
   the original Initiator QSPEC according to the procedures described in
   Section 4.5 of [RFC5974] and in [RFC5977].  The ingress QNE to the
   RMD domain maps the TMOD parameters contained in the original
   Initiator QSPEC to the equivalent TMOD parameter representing only
   the peak bandwidth in the Local QSPEC.  The local RMD QSPEC for
   example also needs <PHB Class>, which in this case was provided by
   the QNI.

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

   In the XG domain, the Initiator QSPEC is translated into a local
   QSPEC using a similar procedure as described above.  The Local QSPEC
   becomes the current QSPEC used within the XG domain, and the
   Initiator QSPEC is encapsulated.  This saves the QNEs within the XG
   domain the trouble of re-translating the Initiator QSPEC, and
   simplifies processing in the local domain.  At the egress edge of the
   XG domain, the translated Local QSPEC is removed, and the Initiator
   QSPEC returns to the number one position.

   If the reservation was successful, eventually the RESERVE request
   arrives at the QNR (otherwise, the QNE at which the reservation
   failed aborts the RESERVE and sends 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

Top      Up      ToC       Page 20 
   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>

   If the handheld device on the right of Figure 2 is mobile, and moves
   through different XG wireless networks, then the QoS might change on
   the path since different XG wireless networks might support different
   QOSMs.  As a result, QoS NSLP/QSPEC processing will have to
   renegotiate the QoS Available on the path.  From a QSPEC perspective,
   this is like a new reservation on the new section of the path and is
   basically the same as any other rerouting event -- to the QNEs on the
   new path, it looks like a new reservation.  That is, in this mobile
   scenario, the new segment may support a different QOSM than the old
   segment, and the QNI would now signal a new reservation explicitly
   (or implicitly with the next refreshing RESERVE message) to account
   for the different QOSM in the XG wireless domain.  Further details on
   rerouting are specified in [RFC5974].

   For bit-level examples of QSPECs, see the documents specifying QOSMs:
   [CL-QOSM], [RFC5976], and [RFC5977].

4.  QSPEC Processing and Procedures

   Three flags are used in QSPEC processing, the M flag, E flag, and N
   flag, which are explained in this section.  The QNI sets the M flag
   for each QSPEC parameter it populates that MUST be interpreted by
   downstream QNEs.  If a QNE does not support the parameter, it sets
   the N flag and fails the reservation.  If the QNE supports the
   parameter but cannot meet the resources requested by the parameter,
   it sets the E flag and fails the reservation.

   If the M flag is not set, the downstream QNE SHOULD interpret the
   parameter.  If the QNE does not support the parameter, it sets the N
   flag and forwards the reservation.  If the QNE supports the parameter
   but cannot meet the resources requested by the parameter, it sets the
   E flag and fails the reservation.

4.1.  Local QSPEC Definition and Processing

   A QNE at the edge of a local domain may either a) translate the
   Initiator QSPEC into a Local QSPEC and encapsulate the Initiator
   QSPEC in the RESERVE message, or b) 'hide' the Initiator QSPEC
   through the local domain and reserve resources by generating a new

Top      Up      ToC       Page 21 
   RESERVE message through the local domain containing the Local QSPEC.
   In either case, the Initiator QSPEC parameters are interpreted at the
   local domain edges.

   A Local QSPEC may allow a simpler control plane in a local domain.
   The edge nodes in the local domain must interpret the Initiator QSPEC
   parameters.  They can either initiate a parallel session with Local
   QSPEC or define a Local QSPEC and encapsulate the Initiator QSPEC, as
   illustrated in Figure 3.  The Initiator/Local QSPEC bit identifies
   whether the QSPEC is an Initiator QSPEC or a Local QSPEC.  The QSPEC
   Type indicates, for example, that the initiator of the local QSPEC
   uses to a certain QOSM, e.g., CL-QSPEC Type.  It may be useful for
   the QNI to signal a QSPEC Type based on some QOSM (which will
   necessarily entail populating certain QOSM-related parameters) so
   that a downstream QNE can chose amongst various QOSM-related
   processes it might have.  That is, the QNI populates the QSPEC Type,
   e.g., CL-QSPEC Type and sets the Initiator/Local QSPEC bit to
   'Initiator'.  A local QNE can decide, for whatever reasons, to insert
   a Local QSPEC Type, e.g., RMD-QSPEC Type, and set the local QSPEC
   Type = RMD-QSPEC and set the Initiator/Local QSPEC bit to 'Local'
   (and encapsulate the Initiator QSPEC in the RESERVE or whatever NSLP
   message).

   +--------------------------------+\
   |   QSPEC Type, QSPEC Procedure  | \
   +--------------------------------+ / Common QSPEC Header
   |   Init./Local QSPEC bit=Local  |/
   +================================+\
   |  Local-QSPEC Parameter 1       | \
   +--------------------------------+  \
   |             ....               |   Local-QSPEC Parameters
   +--------------------------------+  /
   |  Local-QSPEC Parameter n       | /
   +--------------------------------+/
   | +----------------------------+ |
   | | QSPEC Type, QSPEC Procedure| |
   | +----------------------------+ |
   | | Init./Local QSPEC bit=Init.| |
   | +============================+ |
   | |                            | | Encapsulated Initiator QSPEC
   | |          ....              | |
   | +----------------------------+ |
   +--------------------------------+

                 Figure 3: Defining a Local QSPEC

Top      Up      ToC       Page 22 
   Here the QoS-NSLP only sees and passes one QSPEC up to the RMF.
   Thus, the type of the QSPEC may change within a local domain.  Hence:

   o  the QNI signals its QoS requirements with the Initiator QSPEC,

   o  the ingress edge QNE in the local domain translates the Initiator
      QSPEC parameters to equivalent parameters in the local QSPEC,

   o  the QNEs in the local domain only interpret the Local QSPEC
      parameters, and

   o  the egress QNE in the local domain processes the Local QSPEC and
      also interprets the QSPEC parameters in the Initiator QSPEC.

   The Local QSPEC MUST be consistent with the Initiator QSPEC.  That
   is, it MUST NOT specify a lower level of resources than specified by
   the Initiator QSPEC.  For example, in RMD the TMOD parameters
   contained in the original Initiator QSPEC are mapped to the
   equivalent TMOD parameter representing only the peak bandwidth in the
   Local QSPEC.

   Note that it is possible to use both a) hiding a QSPEC through a
   local domain by initiating a new RESERVE at the domain edge, and b)
   defining a Local QSPEC and encapsulating the Initiator QSPEC, as
   defined above.  However, it is not expected that both the hiding and
   encapsulating functions would be used at the same time for the same
   flow.

   The support of Local QSPECs is illustrated in Figure 4 for a single
   flow to show where the Initiator and Local QSPECs are used.  The QNI
   initiates an end-to-end, inter-domain QoS NSLP RESERVE message
   containing the Initiator QSPEC for the Y.1541 QOSM.  As illustrated
   in Figure 4, the RESERVE message crosses multiple domains supporting
   different QOSMs.  In this illustration, the Initiator QSPEC arrives
   in a QoS NSLP RESERVE message at the ingress node of the local-QOSM
   domain.  At the ingress edge node of the local-QOSM domain, the end-
   to-end, inter-domain QoS-NSLP message triggers the generation of a
   Local QSPEC, and the Initiator QSPEC is encapsulated within the
   messages signaled through the local domain.  The local QSPEC is used
   for QoS processing in the local-QOSM domain, and the Initiator QSPEC
   is used for QoS processing outside the local domain.

   In this example, the QNI sets <QoS Desired>, <Minimum QoS>, and <QoS
   Available> objects to include objectives for the <Path Latency>,
   <Path Jitter>, and <Path PER> parameters.  The QNE / local domain
   sets the cumulative parameters, e.g., <Path Latency>, that can be
   achieved in the <QoS Available> object (but not less than specified
   in <Minimum QoS>).  If the <QoS Available> fails to satisfy one or

Top      Up      ToC       Page 23 
   more of the <Minimum QoS> objectives, the QNE / local domain notifies
   the QNI and the reservation is aborted.  If any QNE cannot meet the
   requirements designated by the Initiator QSPEC to support a QSPEC
   parameter with the M bit set to zero, the QNE sets the N flag for
   that parameter to one.  Otherwise, the QNR notifies the QNI of the
   <QoS Available> for the reservation.

   |------|   |------|                           |------|   |------|
   | e2e  |<->| e2e  |<------------------------->| e2e  |<->| e2e  |
   | QOSM |   | QOSM |                           | QOSM |   | QOSM |
   |      |   |------|   |-------|   |-------|   |------|   |      |
   | NSLP |   | NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP |   | NSLP |
   |Y.1541|   |local |   |local  |   |local  |   |local |   |Y.1541|
   | 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 4: Example of Initiator and Local Domain QOSM Operation

4.2.  Reservation Success/Failure, QSPEC Error Codes, and INFO-SPEC
      Notification

   A reservation may not be successful for several reasons:

   - a reservation may fail because the desired resources are not
     available.  This is a reservation failure condition.

   - a reservation may fail because the QSPEC is erroneous or because of
     a QNE fault.  This is an error condition.

   A reservation may be successful even though some parameters could not
   be interpreted or updated properly:

   - a QSPEC parameter cannot be interpreted because it is an unknown
     QSPEC parameter type.  This is a QSPEC parameter not supported
     condition.  However, the reservation does not fail.  The QNI can
     still decide whether to keep or tear down the reservation depending
     on the procedures specified by the QNI's QOSM.

   The following sections provide details on the handling of
   unsuccessful reservations and reservations where some parameters
   could not be met, as follows:

Top      Up      ToC       Page 24 
   - details on flags used inside the QSPEC to convey information on
     success or failure of individual parameters.  The formats and
     semantics of all flags are given in Section 5.

   - the content of the INFO-SPEC [RFC5974], which carries a code
     indicating the outcome of reservations.

   - the generation of a RESPONSE message to the QNI containing both
     QSPEC and INFO-SPEC objects.

   Note that when there are routers along the path between the QNI and
   QNR where QoS cannot be provided, then the QoS-NSLP generic flag
   BREAK (B) is set.  The BREAK flag is discussed in Section 3.3.5 of
   [RFC5974].

4.2.1.  Reservation Failure and Error E Flag

   The QSPEC parameters each have a 'reservation failure error E flag'
   to indicate which (if any) parameters could not be satisfied.  When a
   resource cannot be satisfied for a particular parameter, the QNE
   detecting the problem raises the E flag in this parameter.  Note that
   the TMOD parameter and all QSPEC parameters with the M flag set MUST
   be examined by the RMF, and all QSPEC parameters with the M flag not
   set SHOULD be examined by the RMF, and the E flag set to indicate
   whether the parameter could or could not be satisfied.  Additionally,
   the E flag in the corresponding QSPEC object MUST be raised when a
   resource cannot be satisfied for this parameter.  If the reservation
   failure problem cannot be located at the parameter level, only the E
   flag in the QSPEC object is raised.

   When an RMF cannot interpret the QSPEC because the coding is
   erroneous, it raises corresponding reservation failure E flags in the
   QSPEC.  Normally, all QSPEC parameters MUST be examined by the RMF,
   and the erroneous parameters appropriately flagged.  In some cases,
   however, an error condition may occur and the E flag of the error-
   causing QSPEC parameter is raised (if possible), but the processing
   of further parameters may be aborted.

   Note that if the QSPEC and/or any QSPEC parameter is found to be
   erroneous, then any QSPEC parameters not satisfied are ignored and
   the E Flags in the QSPEC object MUST NOT be set for those parameters
   (unless they are erroneous).

   Whether E flags denote reservation failure or error can be determined
   by the corresponding error code in the INFO-SPEC in QoS NSLP, as
   discussed below.

Top      Up      ToC       Page 25 
4.2.2.  QSPEC Parameter Not Supported N Flag

   Each QSPEC parameter has an associated 'Not Supported N flag'.  If
   the Not Supported N flag is set, then at least one QNE along the data
   transmission path between the QNI and QNR cannot interpret the
   specified QSPEC parameter.  A QNE MUST set the Not Supported N flag
   if it cannot interpret the QSPEC parameter.  If the M flag for the
   parameter is not set, the message should continue to be forwarded but
   with the N flag set, and the QNI has the option of tearing down the
   reservation.

   If a QNE in the path does not support a QSPEC parameter, e.g., <Path
   Latency>, and sets the N flag, then downstream QNEs that support the
   parameter SHOULD still update the parameter, even if the N flag is
   set.  However, the presence of the N flag will indicate that the
   cumulative value only provides a bound, and the QNI/QNR decides
   whether or not to accept the reservation with the N flag set.

4.2.3.  INFO-SPEC Coding of Reservation Outcome

   As prescribed by [RFC5974], the RESPONSE message always contains the
   INFO-SPEC with an appropriate 'error' code.  It usually also contains
   a QSPEC with QSPEC objects, as described in Section 4.3 ("QSPEC
   Procedures").  The RESPONSE message MAY omit the QSPEC in case of a
   successful reservation.

   The following guidelines are provided for setting the error codes in
   the INFO-SPEC, based on the codes provided in Section 5.1.3.6 of
   [RFC5974]:

   - NSLP error class 2 (Success) / 0x01 (Reservation Success):
     This code is set when all QSPEC parameters have been satisfied.  In
     this case, no E Flag is set; however, one or more N flags may be
     set.

   - NSLP error class 4 (Transient Failure) / 0x07 (Reservation
     Failure):
     This code is set when at least one QSPEC parameter could not be
     satisfied, or when a QSPEC parameter with M flag set could not be
     interpreted.  E flags are set for the parameters that could not be
     satisfied at each QNE up to the QNE issuing the RESPONSE message.
     The N flag is set for those parameters that could not be
     interpreted by at least one QNE.  In this case, QNEs receiving the
     RESPONSE message MUST remove the corresponding reservation.

Top      Up      ToC       Page 26 
   - NSLP error class 3 (Protocol Error) / 0x0c (Malformed QSPEC):
     Some QSPEC parameters had associated errors, E Flags are set for
     parameters that had errors, and the QNE where the error was found
     rejects the reservation.

   - NSLP error class 3 (Protocol Error) / 0x0f (Incompatible QSPEC):
     A higher version QSPEC is signaled and not supported by the QNE.

   - NSLP error class 6 (QoS Model Error):
     QOSM error codes can be defined by QOSM specification documents.  A
     registry is defined in Section 7, IANA Considerations.

4.2.4.  QNE Generation of a RESPONSE Message

   - Successful Reservation Condition

     When a RESERVE message arrives at a QNR and no E Flag is set, the
     reservation is successful.  A RESPONSE message may be generated
     with INFO-SPEC code 'Reservation Success' as described above and in
     Section 4.3 ("QSPEC Procedures").

   - Reservation Failure Condition

     When a QNE detects that a reservation failure occurs for at least
     one parameter, the QNE sets the E Flags for the QSPEC parameters
     and QSPEC object that failed to be satisfied.  According to
     [RFC5974], the QNE behavior depends on whether it is stateful or
     not.  When a stateful QNE determines the reservation failed, it
     formulates a RESPONSE message that includes an INFO-SPEC with the
     'reservation failure' error code and QSPEC object.  The QSPEC in
     the RESPONSE message includes the failed QSPEC parameters marked
     with the E Flag to clearly identify them.

     The default action for a stateless QoS NSLP QNE that detects a
     reservation failure condition is that it MUST continue to forward
     the RESERVE message to the next stateful QNE, with the E Flags
     appropriately set for each QSPEC parameter.  The next stateful QNE
     then formulates the RESPONSE message as described above.

   - Malformed QSPEC Error Condition

     When a stateful QNE detects that one or more QSPEC parameters are
     erroneous, the QNE sets the error code 'malformed QSPEC' in the
     INFO-SPEC.  In this case, the QSPEC object with the E Flags
     appropriately set for the erroneous parameters is returned within
     the INFO-SPEC object.  The QSPEC object can be truncated or fully
     included within the INFO-SPEC.

Top      Up      ToC       Page 27 
     According to [RFC5974], the QNE behavior depends on whether it is
     stateful or not.  When a stateful QNE determines a malformed QSPEC
     error condition, it formulates a RESPONSE message that includes an
     INFO-SPEC with the 'malformed QSPEC' error code and QSPEC object.

     The QSPEC in the RESPONSE message includes, if possible, only the
     erroneous QSPEC parameters and no others.  The erroneous QSPEC
     parameter(s) are marked with the E Flag to clearly identify them.
     If QSPEC parameters are returned in the INFO-SPEC that are not
     marked with the E flag, then any values of these parameters are
     irrelevant and MUST be ignored by the QNI.

     The default action for a stateless QoS NSLP QNE that detects a
     malformed QSPEC error condition is that it MUST continue to forward
     the RESERVE message to the next stateful QNE, with the E Flags
     appropriately set for each QSPEC parameter.  The next stateful QNE
     will then act as described in [RFC5974].

     A 'malformed QSPEC' error code takes precedence over the
     'reservation failure' error code, and therefore the case of
     reservation failure and QSPEC/RMF error conditions are disjoint,
     and the same E Flag can be used in both cases without ambiguity.

4.2.5.  Special Case of Local QSPEC

     When an unsuccessful reservation problem occurs inside a local
     domain where a Local QSPEC is used, only the topmost (local) QSPEC
     is affected (e.g., E flags are raised, etc.).  The encapsulated
     Initiator QSPEC is untouched.  However, when the message (RESPONSE
     in case of stateful QNEs; RESERVE in case of stateless QNEs)
     reaches the edge of the local domain, the Local QSPEC is removed.
     The edge QNE must update the Initiator QSPEC on behalf of the
     entire domain, reflecting the information received in the Local
     QSPEC.  This update concerns both parameter values and flags.  Note
     that some intelligence is needed in mapping the E flags, etc., from
     the local QSPEC to the Initiator QSPEC.  For example, even if there
     is no direct match between the parameters in the local and
     Initiator QSPECs, E flags could still be raised in the latter.

4.3.  QSPEC Procedures

     While the QSPEC template aims to put minimal restrictions on usage
     of QSPEC objects, interoperability between QNEs and between QOSMs
     must be ensured.  We therefore give below an exhaustive list of
     QSPEC object combinations for the message sequences described in
     QoS NSLP [RFC5974].  A specific QOSM may prescribe that only a
     subset of the procedures listed below may be used.

Top      Up      ToC       Page 28 
     Note that QoS NSLP does not mandate the usage of a RESPONSE
     message.  A positive RESPONSE message will only be generated if the
     QNE includes an RII (Request Identification Information) in the
     RESERVE message, and a negative RESPONSE message is always
     generated in case of an error or failure.  Some of the QSPEC
     procedures below, however, are only meaningful when a RESPONSE
     message is possible.  The QNI SHOULD in these cases include an RII.

4.3.1.  Two-Way Transactions

     Here, the QNI issues a RESERVE message, which may be replied to by
     a RESPONSE message.  The following 3 cases for QSPEC object usage
     exist:

     MESSAGE  | OBJECT      | OBJECTS INCLUDED   | OBJECTS INCLUDED
     SEQUENCE | COMBINATION | IN RESERVE MESSAGE | IN RESPONSE MESSAGE
     -----------------------------------------------------------------
     0        | 0           | QoS Desired        | QoS Reserved
              |             |                    |
     0        | 1           | QoS Desired        | QoS Reserved
              |             | QoS Available      | QoS Available
              |             |                    |
     0        | 2           | QoS Desired        | QoS Reserved
              |             | QoS Available      | QoS Available
              |             | Minimum QoS        |

       Table 1: Message Sequence 0: Two-Way Transactions
                Defining Object Combinations 0, 1, and 2

     Case 1:

     If only QoS Desired is included in the RESERVE message, the
     implicit assumption is that exactly these resources must be
     reserved.  If this is not possible, the reservation fails.  The
     parameters in QoS Reserved are copied from the parameters in QoS
     Desired.  If the reservation is successful, the RESPONSE message
     can be omitted in this case.  If a RESPONSE message was requested
     by a QNE on the path, the QSPEC in the RESPONSE message can be
     omitted.

     Case 2:

     When QoS Available is included in the RESERVE message also, some
     parameters will appear only in QoS Available and not in QoS
     Desired.  It is assumed that the value of these parameters is
     collected for informational purposes only (e.g., path latency).

Top      Up      ToC       Page 29 
     However, some parameters in QoS Available can be the same as in QoS
     Desired.  For these parameters, the implicit message is that the
     QNI would be satisfied by a reservation with lower parameter values
     than specified in QoS Desired.  For these parameters, the QNI seeds
     the parameter values in QoS Available to those in QoS Desired
     (except for cumulative parameters such as <Path Latency>).

     Each QNE interprets the parameters in QoS Available according to
     its current capabilities.  Reservations in each QNE are hence based
     on current parameter values in QoS Available (and additionally
     those parameters that only appear in QoS Desired).  The drawback of
     this approach is that, if the resulting resource reservation
     becomes gradually smaller towards the QNR, QNEs close to the QNI
     have an oversized reservation, possibly resulting in unnecessary
     costs for the user.  Of course, in the RESPONSE the QNI learns what
     the actual reservation is (from the QoS RESERVED object) and can
     immediately issue a properly sized refreshing RESERVE.  The
     advantage of the approach is that the reservation is performed in
     half-a-roundtrip time.

     The QSPEC parameter IDs and values included in the QoS Reserved
     object in the RESPONSE message MUST be the same as those in the QoS
     Desired object in the RESERVE message.  For those QSPEC parameters
     that were also included in the QoS Available object in the RESERVE
     message, their value is copied from the QoS Available object (in
     RESERVE) into the QoS Reserved object (in RESPONSE).  For the other
     QSPEC parameters, the value is copied from the QoS Desired object
     (the reservation would fail if the corresponding QoS could not be
     reserved).

     All parameters in the QoS Available object in the RESPONSE message
     are copied with their values from the QoS Available object in the
     RESERVE message (irrespective of whether they have also been copied
     into the QoS Desired object).  Note that the parameters in the QoS
     Available object can be overwritten in the RESERVE message, whereas
     they cannot be overwritten in the RESPONSE message.

     In this case, the QNI SHOULD request a RESPONSE message since it
     will otherwise not learn what QoS is available.

     Case 3:

     This case is handled as case 2, except that the reservation fails
     when QoS Available becomes less than Minimum QoS for one parameter.
     If a parameter appears in the QoS Available object but not in the
     Minimum QoS object, it is assumed that there is no minimum value
     for this parameter.

Top      Up      ToC       Page 30 
     Regarding Traffic Handling Directives, the default rule is that all
     QSPEC parameters that have been included in the RESERVE message by
     the QNI are also included in the RESPONSE message by the QNR with
     the value they had when arriving at the QNR.  When traveling in the
     RESPONSE message, all Traffic Handling Directives parameters are
     read-only.  Note that a QOSM specification may define its own
     Traffic Handling Directives parameters and processing rules.

4.3.2.  Three-Way Transactions

     Here, the QNR issues a QUERY message that is replied to by the QNI
     with a RESERVE message if the reservation was successful.  The QNR
     in turn sends a RESPONSE message to the QNI.  The following 3 cases
     for QSPEC object usage exist:

     MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED   |OBJECTS INCLUDED
     SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
     -------------------------------------------------------------------
     1   |0   |QoS Desired      |QoS Desired        |QoS Reserved
         |    |                 |                   |
     1   |1   |QoS Desired      |QoS Desired        |QoS Reserved
         |    |(Minimum QoS)    |QoS Available      |QoS Available
         |    |                 |(Minimum QoS)      |
         |    |                 |                   |
     1   |2   |QoS Desired      |QoS Desired        |QoS Reserved
         |    |QoS Available    |QoS Available      |

       Table 2: Message Sequence 1: Three-Way Transactions
                Defining Object Combinations 0, 1, and 2

     Cases 1 and 2:

     The idea is that the sender (QNR in this scenario) needs to inform
     the receiver (QNI in this scenario) about the QoS it desires.  To
     this end, the sender sends a QUERY message to the receiver
     including a QoS Desired QSPEC object.  If the QoS is negotiable, it
     additionally includes a (possibly zero) Minimum QoS object, as in
     Case 2.

     The RESERVE message includes the QoS Available object if the sender
     signaled that QoS is negotiable (i.e., it included the Minimum QoS
     object).  If the Minimum QoS object received from the sender is
     included in the QUERY message, the QNI also includes the Minimum
     QoS object in the RESERVE message.

Top      Up      ToC       Page 31 
     For a successful reservation, the RESPONSE message in case 1 is
     optional (as is the QSPEC inside).  In case 2, however, the
     RESPONSE message is necessary in order for the QNI to learn about
     the QoS available.

     Case 3:

     This is the 'RSVP-style' scenario.  The sender (QNR in this
     scenario) issues a QUERY message with a QoS Desired object
     informing the receiver (QNI in this scenario) about the QoS it
     desires, as above.  It also includes a QoS Available object to
     collect path properties.  Note that here path properties are
     collected with the QUERY message, whereas in the previous case, 2
     path properties were collected in the RESERVE message.

     Some parameters in the QoS Available object may be the same as in
     the QoS Desired object.  For these parameters, the implicit message
     is that the sender would be satisfied by a reservation with lower
     parameter values than specified in QoS Desired.

     It is possible for the QoS Available object to contain parameters
     that do not appear in the QoS Desired object.  It is assumed that
     the value of these parameters is collected for informational
     purposes only (e.g., path latency).  Parameter values in the QoS
     Available object are seeded according to the sender's capabilities.
     Each QNE remaps or approximately interprets the parameter values
     according to its current capabilities.

     The receiver (QNI in this scenario) signals the QoS Desired object
     as follows: For those parameters that appear in both the QoS
     Available object and QoS Desired object in the QUERY message, it
     takes the (possibly remapped) QSPEC parameter values from the QoS
     Available object.  For those parameters that only appear in the QoS
     Desired object, it adopts the parameter values from the QoS Desired
     object.

     The parameters in the QoS Available QSPEC object in the RESERVE
     message are copied with their values from the QoS Available QSPEC
     object in the QUERY message.  Note that the parameters in the QoS
     Available object can be overwritten in the QUERY message, whereas
     they cannot be overwritten in the RESERVE message.

     The advantage of this model compared to the sender-initiated
     reservation is that the situation of over-reservation in QNEs close
     to the QNI (as described above) does not occur.  On the other hand,
     the QUERY message may find, for example, a particular bandwidth is

Top      Up      ToC       Page 32 
     not available.  When the actual reservation is performed, however,
     the desired bandwidth may meanwhile have become free.  That is, the
     'RSVP style' may result in a smaller reservation than necessary.

     The sender includes all QSPEC parameters it cares about in the
     QUERY message.  Parameters that can be overwritten are updated by
     QNEs as the QUERY message travels towards the receiver.  The
     receiver includes all QSPEC parameters arriving in the QUERY
     message also in the RESERVE message, with the value they had when
     arriving at the receiver.  Again, QOSM-specific QSPEC parameters
     and procedures may be defined in QOSM specification documents.

     Also in this scenario, the QNI SHOULD request a RESPONSE message
     since it will otherwise not learn what QoS is available.

     Regarding Traffic Handling Directives, the default rule is that all
     QSPEC parameters that have been included in the RESERVE message by
     the QNI are also included in the RESPONSE message by the QNR with
     the value they had when arriving at the QNR.  When traveling in the
     RESPONSE message, all Traffic Handling Directives parameters are
     read-only.  Note that a QOSM specification may define its own
     Traffic Handling Directives parameters and processing rules.

4.3.3.  Resource Queries

     Here, the QNI issues a QUERY message in order to investigate what
     resources are currently available.  The QNR replies with a RESPONSE
     message.

     MESSAGE  | OBJECT      | OBJECTS INCLUDED   | OBJECTS INCLUDED
     SEQUENCE | COMBINATION | IN QUERY MESSAGE   | IN RESPONSE MESSAGE
     -----------------------------------------------------------------
     2        | 0           | QoS Available      | QoS Available

           Table 3: Message Sequence 2: Resource Queries
                    Defining Object Combination 0

     Note that the QoS Available object when traveling in the QUERY
     message can be overwritten, whereas in the RESPONSE message it
     cannot be overwritten.

     Regarding Traffic Handling Directives, the default rule is that all
     QSPEC parameters that have been included in the RESERVE message by
     the QNI are also included in the RESPONSE message by the QNR with
     the value they had when arriving at the QNR.  When traveling in the
     RESPONSE message, all Traffic Handling Directives parameters are
     read-only.  Note that a QOSM specification may define its own
     Traffic Handling Directives parameters and processing rules.

Top      Up      ToC       Page 33 
4.3.4.  Bidirectional Reservations

     On a QSPEC level, bidirectional reservations are no different from
     unidirectional reservations, since QSPECs for different directions
     never travel in the same message.

4.3.5.  Preemption

     A flow can be preempted by a QNE based on QNE policy, where a
     decision to preempt a flow may account for various factors such as,
     for example, the values of the QSPEC preemption priority and
     defending priority parameters as described in Section 5.2.8.  In
     this case, the reservation state for this flow is torn down in the
     QNE, and the QNE sends a NOTIFY message to the QNI, as described in
     [RFC5974].  The NOTIFY message carries an INFO-SPEC with the error
     code as described in [RFC5974].  A QOSM specification document may
     specify whether a NOTIFY message also carries a QSPEC object.  The
     QNI would normally tear down the preempted reservation by sending a
     RESERVE message with the TEAR flag set using the SII of the
     preempted reservation.  However, the QNI can follow other
     procedures as specified in its QOSM specification document.

4.4.  QSPEC Extensibility

     Additional QSPEC parameters MAY need to be defined in the future
     and are defined in separate informational documents.  For example,
     QSPEC parameters are defined in [RFC5977] and [RFC5976].

     Guidelines on the technical criteria to be followed in evaluating
     requests for new codepoint assignments for QSPEC objects and QSPEC
     parameters are given in Section 7, IANA Considerations.



(page 33 continued on part 3)

Next RFC Part