Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5974

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

Pages: 102
Experimental
Part 1 of 6 – Pages 1 to 6
None   None   Next

Top   ToC   RFC5974 - 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.
Top   ToC   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   RFC5974 - 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   RFC5974 - 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   RFC5974 - 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   RFC5974 - 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 Section