Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5975

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

Pages: 64
Experimental
Part 1 of 4 – Pages 1 to 7
None   None   Next

Top   ToC   RFC5975 - Page 1
Internet Engineering Task Force (IETF)                       G. Ash, Ed.
Request for Comments: 5975                                          AT&T
Category: Experimental                                     A. Bader, Ed.
ISSN: 2070-1721                                                 Ericsson
                                                         C. Kappler, Ed.
                                                  ck technology concepts
                                                            D. Oran, Ed.
                                                     Cisco Systems, Inc.
                                                            October 2010


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

Abstract

The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Top   ToC   RFC5975 - Page 2
   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5975.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC5975 - Page 3

Table of Contents

1. Introduction ....................................................4 1.1. Conventions Used in This Document ..........................6 2. Terminology .....................................................6 3. QSPEC Framework .................................................7 3.1. QoS Models .................................................7 3.2. QSPEC Objects ..............................................9 3.3. QSPEC Parameters ..........................................11 3.3.1. Traffic Model Parameter ............................12 3.3.2. Constraints Parameters .............................14 3.3.3. Traffic-Handling Directives ........................16 3.3.4. Traffic Classifiers ................................17 3.4. Example of QSPEC Processing ...............................17 4. QSPEC Processing and Procedures ................................20 4.1. Local QSPEC Definition and Processing .....................20 4.2. Reservation Success/Failure, QSPEC Error Codes, and INFO-SPEC Notification ................................23 4.2.1. Reservation Failure and Error E Flag ...............24 4.2.2. QSPEC Parameter Not Supported N Flag ...............25 4.2.3. INFO-SPEC Coding of Reservation Outcome ............25 4.2.4. QNE Generation of a RESPONSE Message ...............26 4.2.5. Special Case of Local QSPEC ........................27 4.3. QSPEC Procedures ..........................................27 4.3.1. Two-Way Transactions ...............................28 4.3.2. Three-Way Transactions .............................30 4.3.3. Resource Queries ...................................32 4.3.4. Bidirectional Reservations .........................33 4.3.5. Preemption .........................................33 4.4. QSPEC Extensibility .......................................33 5. QSPEC Functional Specification .................................33 5.1. General QSPEC Formats .....................................33 5.1.1. Common Header Format ...............................34 5.1.2. QSPEC Object Header Format .........................36 5.2. QSPEC Parameter Coding ....................................37 5.2.1. <TMOD-1> Parameter .................................37 5.2.2. <TMOD-2> Parameter .................................38 5.2.3. <Path Latency> Parameter ...........................39 5.2.4. <Path Jitter> Parameter ............................40 5.2.5. <Path PLR> Parameter ...............................41 5.2.6. <Path PER> Parameter ...............................42 5.2.7. <Slack Term> Parameter .............................43 5.2.8. <Preemption Priority> and <Defending Priority> Parameters .........................................43 5.2.9. <Admission Priority> Parameter .....................44 5.2.10. <RPH Priority> Parameter ..........................45 5.2.11. <Excess Treatment> Parameter ......................46 5.2.12. <PHB Class> Parameter .............................48
Top   ToC   RFC5975 - Page 4
           5.2.13. <DSTE Class Type> Parameter .......................49
           5.2.14. <Y.1541 QoS Class> Parameter ......................50
   6. Security Considerations ........................................51
   7. IANA Considerations ............................................51
   8. Acknowledgements ...............................................55
   9. Contributors ...................................................55
   10. Normative References ..........................................57
   11. Informative References ........................................59
   Appendix A. Mapping of QoS Desired, QoS Available, and QoS
      Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ .62
   Appendix B. Example of TMOD Parameter Encoding ....................62

1. Introduction

The QoS NSIS signaling layer protocol (NSLP) [RFC5974] is used to signal QoS reservations for a data flow, provide forwarding resources (QoS) for that flow, and establish and maintain state at nodes along the path of the flow. The design of QoS NSLP is conceptually similar to the decoupling between RSVP [RFC2205] and the IntServ architecture [RFC2210], where a distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). [RFC5974] describes the signaling protocol, while this document describes the RMF-related information carried in the QSPEC (QoS Specification) object carried in QoS NSLP messages. [RFC5974] defines four QoS NSLP messages -- RESERVE, QUERY, RESPONSE, and NOTIFY -- each of which may carry the QSPEC object, while this document describes a template for the QSPEC object. The QSPEC object carries information on traffic descriptions, resources required, resources available, and other information required by the RMF. Therefore, the QSPEC template described in this document is closely tied to QoS NSLP, and the reader should be familiar with [RFC5974] to fully understand this document. A QoS-enabled domain supports a particular QoS model (QOSM), which is a method to achieve QoS for a traffic flow. A QOSM incorporates QoS provisioning methods and a QoS architecture, and defines the behavior of the RMF that reserves resources for each flow, including inputs and outputs. The QoS NSLP protocol is able to signal QoS reservations for different QOSMs, wherein all information specific to a QOSM is encapsulated in the QSPEC object, and only the RMF specific to a given QOSM will need to interpret the QSPEC. Examples of QOSMs are IntServ, Diffserv admission control, and those specified in [CL-QOSM], [RFC5976], and [RFC5977].
Top   ToC   RFC5975 - Page 5
   QSPEC parameters include, for example:

      o  a mandatory traffic model (TMOD) parameter,
      o  constraints parameters such as path latency and path jitter,
      o  traffic handling directives such as excess treatment, and
      o  traffic classifiers such as PHB class.

   While the base protocol is QOSM-agnostic, the parameters that can be
   carried in the QSPEC object are possibly closely coupled to specific
   models.

   QSPEC objects loosely correspond to the TSpec, RSpec, and AdSpec
   objects specified in RSVP and may contain, respectively, a
   description of QoS Desired, QoS Reserved, and QoS Available.  Going
   beyond RSVP functionality, the QSPEC also allows indicating a range
   of acceptable QoS by defining a QSPEC object denoting minimum QoS.
   Usage of these QSPEC objects is not bound to particular message
   types, thus allowing for flexibility.  A QSPEC object collecting
   information about available resources may travel in any QoS NSLP
   message, for example, a QUERY message or a RESERVE message, as
   defined in [RFC5974].  The QSPEC travels in QoS NSLP messages but is
   opaque to the QoS NSLP and is only interpreted by the RMF.

   Interoperability between QoS NSIS entities (QNEs) in different
   domains is enhanced by the definition of a common set of QSPEC
   parameters.  A QoS NSIS initiator (QNI) initiating the QoS NSLP
   signaling adds an Initiator QSPEC object containing parameters
   describing the desired QoS, normally based on the QOSM it supports.
   QSPEC parameters flagged by the QNI must be interpreted by all QNEs
   in the path, else the reservation fails.  In contrast, QSPEC
   parameters not flagged by the QNI may be skipped if not understood.
   Additional QSPEC parameters can be defined by informational
   specification documents, and thereby ensure the extensibility and
   flexibility of QoS NSLP.

   A Local QSPEC can be defined in a local domain with the Initiator
   QSPEC encapsulated, where the Local QSPEC must be functionally
   consistent with the Initiator QSPEC in terms of defined source
   traffic and other constraints.  That is, a domain-specific local
   QSPEC can be defined and processed in a local domain, which could,
   for example, enable simpler processing by QNEs within the local
   domain.

   In Section 3.4, an example of QSPEC processing is provided.
Top   ToC   RFC5975 - Page 6

1.1. Conventions Used in This Document

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

2. Terminology

Initiator QSPEC: The Initiator QSPEC is included in a QoS NSLP message by the QNI/QNR. It travels end-to-end to the QNR/QNI and is never removed. Local QSPEC: A Local QSPEC is used in a local domain and is domain specific. It encapsulates the Initiator QSPEC and is removed at the egress of the local domain. Minimum QoS: QSPEC object that, together with a description of QoS Desired or QoS Available, allows the QNI to specify a QoS range, i.e., an upper and lower bound. If the QoS Desired cannot be reserved, QNEs are going to decrease the reservation until the minimum QoS is hit. 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. QNE: QoS NSIS Entity, a node supporting QoS NSLP. QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. QoS Available: QSPEC object containing parameters describing the available resources. They are used to collect information along a reservation path. QoS Desired: QSPEC object containing parameters describing the desired QoS for which the sender requests reservation. QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load; specifies the subset of QSPEC QoS constraints and traffic handling directives that a QNE implementing that QOSM is capable of supporting and how resources will be managed by the RMF. QoS Reserved: QSPEC object containing parameters describing the reserved resources and related QoS parameters. QSPEC: the object of QoS NSLP that contains all QoS-specific information.
Top   ToC   RFC5975 - Page 7
   QSPEC parameter: Any parameter appearing in a QSPEC; for example,
   traffic model (TMOD), path latency, and excess treatment parameters.

   QSPEC Object: Main building blocks containing a QSPEC parameter set
   that is the input or output of an RMF operation.

   QSPEC Type: Identifies a particular QOSM used in the QSPEC

   Resource Management Function (RMF): Functions that are related to
   resource management and processing of QSPEC parameters.



(page 7 continued on part 2)

Next Section