tech-invite   World Map     

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

RFC 5974

Experimental
Pages: 102
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NSIS

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

Part 1 of 6, p. 1 to 6
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                         J. Manner
Request for Comments: 5974                              Aalto University
Category: Experimental                                    G. Karagiannis
ISSN: 2070-1721                            University of Twente/Ericsson
                                                             A. McDonald
                                                                    Roke
                                                            October 2010


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

Abstract

   This specification describes the NSIS Signaling Layer Protocol (NSLP)
   for signaling Quality of Service (QoS) reservations in the Internet.
   It is in accordance with the framework and requirements developed in
   NSIS.  Together with General Internet Signaling Transport (GIST), it
   provides functionality similar to RSVP and extends it.  The QoS NSLP
   is independent of the underlying QoS specification or architecture
   and provides support for different reservation models.  It is
   simplified by the elimination of support for multicast flows.  This
   specification explains the overall protocol approach, describes the
   design decisions made, and provides examples.  It specifies object,
   message formats, and processing rules.

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.

   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/rfc5974.

Page 2 
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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Overall Approach . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Protocol Messages  . . . . . . . . . . . . . . . . . .  9
       3.1.2.  QoS Models and QoS Specifications  . . . . . . . . . . 10
       3.1.3.  Policy Control . . . . . . . . . . . . . . . . . . . . 12
     3.2.  Design Background  . . . . . . . . . . . . . . . . . . . . 13
       3.2.1.  Soft States  . . . . . . . . . . . . . . . . . . . . . 13
       3.2.2.  Sender and Receiver Initiation . . . . . . . . . . . . 13
       3.2.3.  Protection against Message Re-ordering and
               Duplication  . . . . . . . . . . . . . . . . . . . . . 14
       3.2.4.  Explicit Confirmations . . . . . . . . . . . . . . . . 14
       3.2.5.  Reduced Refreshes  . . . . . . . . . . . . . . . . . . 14
       3.2.6.  Summary Refreshes and Summary Tear . . . . . . . . . . 15
       3.2.7.  Message Scoping  . . . . . . . . . . . . . . . . . . . 15
       3.2.8.  Session Binding  . . . . . . . . . . . . . . . . . . . 16
       3.2.9.  Message Binding  . . . . . . . . . . . . . . . . . . . 16
       3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17
       3.2.11. Support for Request Priorities . . . . . . . . . . . . 18
       3.2.12. Rerouting  . . . . . . . . . . . . . . . . . . . . . . 19
       3.2.13. Preemption . . . . . . . . . . . . . . . . . . . . . . 24
     3.3.  GIST Interactions  . . . . . . . . . . . . . . . . . . . . 24
       3.3.1.  Support for Bypassing Intermediate Nodes . . . . . . . 25
       3.3.2.  Support for Peer Change Identification . . . . . . . . 25
       3.3.3.  Support for Stateless Operation  . . . . . . . . . . . 26
       3.3.4.  Priority of Signaling Messages . . . . . . . . . . . . 26
       3.3.5.  Knowledge of Intermediate QoS-NSLP-Unaware Nodes . . . 26
   4.  Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 26
     4.1.  Sender-Initiated Reservation . . . . . . . . . . . . . . . 27
     4.2.  Sending a Query  . . . . . . . . . . . . . . . . . . . . . 28

Top      ToC       Page 3 
     4.3.  Basic Receiver-Initiated Reservation . . . . . . . . . . . 29
     4.4.  Bidirectional Reservations . . . . . . . . . . . . . . . . 31
     4.5.  Aggregate Reservations . . . . . . . . . . . . . . . . . . 33
     4.6.  Message Binding  . . . . . . . . . . . . . . . . . . . . . 34
     4.7.  Reduced-State or Stateless Interior Nodes  . . . . . . . . 38
       4.7.1.  Sender-Initiated Reservation . . . . . . . . . . . . . 38
       4.7.2.  Receiver-Initiated Reservation . . . . . . . . . . . . 40
     4.8.  Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 41
   5.  QoS NSLP Functional Specification  . . . . . . . . . . . . . . 42
     5.1.  QoS NSLP Message and Object Formats  . . . . . . . . . . . 42
       5.1.1.  Common Header  . . . . . . . . . . . . . . . . . . . . 42
       5.1.2.  Message Formats  . . . . . . . . . . . . . . . . . . . 44
       5.1.3.  Object Formats . . . . . . . . . . . . . . . . . . . . 47
     5.2.  General Processing Rules . . . . . . . . . . . . . . . . . 60
       5.2.1.  State Manipulation . . . . . . . . . . . . . . . . . . 61
       5.2.2.  Message Forwarding . . . . . . . . . . . . . . . . . . 62
       5.2.3.  Standard Message Processing Rules  . . . . . . . . . . 62
       5.2.4.  Retransmissions  . . . . . . . . . . . . . . . . . . . 62
       5.2.5.  Rerouting  . . . . . . . . . . . . . . . . . . . . . . 63
     5.3.  Object Processing  . . . . . . . . . . . . . . . . . . . . 65
       5.3.1.  Reservation Sequence Number (RSN)  . . . . . . . . . . 65
       5.3.2.  Request Identification Information (RII) . . . . . . . 66
       5.3.3.  BOUND-SESSION-ID . . . . . . . . . . . . . . . . . . . 67
       5.3.4.  REFRESH-PERIOD . . . . . . . . . . . . . . . . . . . . 67
       5.3.5.  INFO-SPEC  . . . . . . . . . . . . . . . . . . . . . . 68
       5.3.6.  SESSION-ID-LIST  . . . . . . . . . . . . . . . . . . . 70
       5.3.7.  RSN-LIST . . . . . . . . . . . . . . . . . . . . . . . 71
       5.3.8.  QSPEC  . . . . . . . . . . . . . . . . . . . . . . . . 71
     5.4.  Message Processing Rules . . . . . . . . . . . . . . . . . 72
       5.4.1.  RESERVE Messages . . . . . . . . . . . . . . . . . . . 72
       5.4.2.  QUERY Messages . . . . . . . . . . . . . . . . . . . . 77
       5.4.3.  RESPONSE Messages  . . . . . . . . . . . . . . . . . . 78
       5.4.4.  NOTIFY Messages  . . . . . . . . . . . . . . . . . . . 79
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 80
     6.1.  QoS NSLP Message Type  . . . . . . . . . . . . . . . . . . 81
     6.2.  NSLP Message Objects . . . . . . . . . . . . . . . . . . . 81
     6.3.  QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 82
     6.4.  QoS NSLP Error Classes and Error Codes . . . . . . . . . . 82
     6.5.  QoS NSLP Error Source Identifiers  . . . . . . . . . . . . 83
     6.6.  NSLP IDs and Router Alert Option Values  . . . . . . . . . 83
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 83
     7.1.  Trust Relationship Model . . . . . . . . . . . . . . . . . 85
     7.2.  Authorization Model Examples . . . . . . . . . . . . . . . 87
       7.2.1.  Authorization for the Two-Party Approach . . . . . . . 87
       7.2.2.  Token-Based Three-Party Approach . . . . . . . . . . . 88
       7.2.3.  Generic Three-Party Approach . . . . . . . . . . . . . 90
     7.3.  Computing the Authorization Decision . . . . . . . . . . . 90
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 91

Top      ToC       Page 4 
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 91
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 91
     10.2. Informative References . . . . . . . . . . . . . . . . . . 91
   Appendix A.  Abstract NSLP-RMF API . . . . . . . . . . . . . . . . 94
     A.1.  Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 94
     A.2.  Triggers from RMF/QOSM towards QOS-NSLP  . . . . . . . . . 96
     A.3.  Configuration Interface  . . . . . . . . . . . . . . . . . 99
   Appendix B.  Glossary  . . . . . . . . . . . . . . . . . . . . .  100

1.  Introduction

   This document defines a Quality of Service (QoS) NSIS Signaling Layer
   Protocol (NSLP), henceforth referred to as the "QoS NSLP".  This
   protocol establishes and maintains state at nodes along the path of a
   data flow for the purpose of providing some forwarding resources for
   that flow.  It is intended to satisfy the QoS-related requirements of
   RFC 3726 [RFC3726].  This QoS NSLP is part of a larger suite of
   signaling protocols, whose structure is outlined in the NSIS
   framework [RFC4080].  The abstract NTLP has been developed into a
   concrete protocol, GIST (General Internet Signaling Transport)
   [RFC5971].  The QoS NSLP relies on GIST to carry out many aspects of
   signaling message delivery.

   The design of the QoS NSLP is conceptually similar to RSVP [RFC2205]
   and uses soft-state peer-to-peer refresh messages as the primary
   state management mechanism (i.e., state installation/refresh is
   performed between pairs of adjacent NSLP nodes, rather than in an
   end-to-end fashion along the complete signaling path).  The QoS NSLP
   extends the set of reservation mechanisms to meet the requirements of
   RFC 3726 [RFC3726], in particular, support of sender- or receiver-
   initiated reservations, as well as a type of bidirectional
   reservation and support of reservations between arbitrary nodes,
   e.g., edge-to-edge, end-to-access, etc.  On the other hand, there is
   currently no support for IP multicast.

   A distinction is made between the operation of the signaling protocol
   and the information required for the operation of the Resource
   Management Function (RMF).  This document describes the signaling
   protocol, whilst [RFC5975] describes the RMF-related information
   carried in the QSPEC (QoS Specification) object in QoS NSLP messages.
   This is similar to the decoupling between RSVP and the IntServ
   architecture [RFC1633].  The QSPEC carries information on resources
   available, resources required, traffic descriptions, and other
   information required by the RMF.

Top      ToC       Page 5 
   This document is structured as follows.  The overall protocol design
   is outlined in Section 3.1.  The operation and use of the QoS NSLP is
   described in more detail in the rest of Section 3.  Section 4 then
   clarifies the protocol by means of a number of examples.  These
   sections should be read by people interested in the overall protocol
   capabilities.  The functional specification in Section 5 contains
   more detailed object and message formats and processing rules and
   should be the basis for implementers.  The subsequent sections
   describe IANA allocation issues and security considerations.

2.  Terminology

   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].

   The terminology defined by GIST [RFC5971] applies to this document.

   In addition, the following terms are used:

   QNE: an NSIS Entity (NE), which supports the QoS NSLP.

   QNI: the first node in the sequence of QNEs that issues a reservation
   request for a session.

   QNR: the last node in the sequence of QNEs that receives a
   reservation request for a session.

   P-QNE: Proxy-QNE, a node set to reply to messages with the PROXY
   scope flag set.

   Session: A session defines an association between a QNI and QNR
   related to a data flow.  Intermediate QNEs on the path, the QNI, and
   the QNR use the same identifier to refer to the state stored for the
   association.  The same QNI and QNR may have more than one session
   active at any one time.

   Session Identification (SESSION-ID, SID): This is a cryptographically
   random and (probabilistically) globally unique identifier of the
   application-layer session that is associated with a certain flow.
   Often, there will only be one data flow for a given session, but in
   mobility/multihoming scenarios, there may be more than one, and they
   may be differently routed [RFC4080].

   Source or message source: The one of two adjacent NSLP peers that is
   sending a signaling message (maybe the upstream or the downstream
   peer).  Note that this is not necessarily the QNI.

Top      ToC       Page 6 
   QoS NSLP operation state: State used/kept by the QoS NSLP processing
   to handle messaging aspects.

   QoS reservation state: State used/kept by the Resource Management
   Function to describe reserved resources for a session.

   Flow ID: This is essentially the Message Routing Information (MRI) in
   GIST for path-coupled signaling.

   Figure 1 shows the components that have a role in a QoS NSLP
   signaling session.  The flow sender and receiver would in most cases
   be part of the QNI and QNR nodes.  Yet, these may be separate nodes,
   too.

                        QoS NSLP nodes
  IP address            (QoS-unaware NSIS nodes are          IP address
  = Flow                 not shown)                          = Flow
  Source                 |          |            |           Destination
  Address                |          |            |           Address
                         V          V            V
  +--------+  Data +------+      +------+       +------+     +--------+
  |  Flow  |-------|------|------|------|-------|------|---->|  Flow  |
  | Sender |  Flow |      |      |      |       |      |     |Receiver|
  +--------+       | QNI  |      | QNE  |       | QNR  |     +--------+
                   |      |      |      |       |      |
                   +------+      +------+       +------+
                           =====================>
                           <=====================
                                 Signaling
                                   Flow

             Figure 1: Components of the QoS NSLP Architecture

   A glossary of terms and abbreviations used in this document can be
   found in Appendix B.



(page 6 continued on part 2)

Next RFC Part