RFC 5974
NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
Pages: 102
Experimental
Experimental
Part 1 of 6 – Pages 1 to 6
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 SignalingAbstract
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.
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
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
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 . . . . . . . . . . . . . . . . . . . . . 1001. 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.
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.
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)