Next Steps in Signalling S. Van den Bosch Internet-Draft Alcatel Expires: April 25, 2005 G. Karagiannis University of Twente/Ericsson A. McDonald Siemens/Roke Manor Research October 25, 2004 NSLP for Quality-of-Service signalling draft-ietf-nsis-qos-nslp-05.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This draft describes an NSIS Signalling Layer Protocol (NSLP) for signalling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Van den Bosch, et al. Expires April 25, 2005 [Page 1] Internet-Draft NSLP for Quality-of-Service signalling October 2004 Together with GIMPS, 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 draft explains the overall protocol approach, design decisions made and provides examples. It specifies object and message formats and processing rules. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Scope and background . . . . . . . . . . . . . . . . . . . 5 1.2 Model of operation . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 10 3.1 Overall approach . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 GIMPS Interactions . . . . . . . . . . . . . . . . . . 10 3.1.2 Protocol messages . . . . . . . . . . . . . . . . . . 10 3.1.3 QoS Signalling Models and QoS specifications . . . . . 11 3.1.4 Authentication and authorization . . . . . . . . . . . 12 3.2 Design decisions . . . . . . . . . . . . . . . . . . . . . 15 3.2.1 Soft-state . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Sender-receiver initiation . . . . . . . . . . . . . . 15 3.2.3 Message sequencing . . . . . . . . . . . . . . . . . . 15 3.2.4 Explicit state installation confirmation and responses . . . . . . . . . . . . . . . . . . . . . . 16 3.2.5 Summary refreshes . . . . . . . . . . . . . . . . . . 16 3.2.6 Message scoping . . . . . . . . . . . . . . . . . . . 16 3.2.7 Session binding . . . . . . . . . . . . . . . . . . . 17 3.2.8 Layering . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.9 Priority . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.10 Rerouting (SII) . . . . . . . . . . . . . . . . . . 19 4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . 21 4.1 Basic sender-initiated reservation . . . . . . . . . . . . 21 4.2 Sending a Query . . . . . . . . . . . . . . . . . . . . . 22 4.3 Basic receiver-initiated reservation . . . . . . . . . . . 23 4.4 Bidirectional Reservations . . . . . . . . . . . . . . . . 25 4.5 Use of Local QoS Models . . . . . . . . . . . . . . . . . 26 4.6 Aggregate Reservations . . . . . . . . . . . . . . . . . . 27 4.7 Reduced State or Stateless Interior Nodes . . . . . . . . 29 4.8 Re-routing scenario . . . . . . . . . . . . . . . . . . . 32 4.9 Authorization Model Examples . . . . . . . . . . . . . . . 33 4.9.1 Authorization for the two party approach . . . . . . . 33 4.9.2 Token based three party approach . . . . . . . . . . . 33 4.9.3 Generic three party approach . . . . . . . . . . . . . 34 5. QoS NSLP Functional specification . . . . . . . . . . . . . 36 Van den Bosch, et al. Expires April 25, 2005 [Page 2] Internet-Draft NSLP for Quality-of-Service signalling October 2004 5.1 QoS NSLP Message and Object Formats . . . . . . . . . . . 36 5.1.1 Common header . . . . . . . . . . . . . . . . . . . . 36 5.1.2 Message formats . . . . . . . . . . . . . . . . . . . 37 5.1.3 Object Formats . . . . . . . . . . . . . . . . . . . . 39 5.2 General Processing Rules . . . . . . . . . . . . . . . . . 43 5.2.1 State Manipulation . . . . . . . . . . . . . . . . . . 44 5.2.2 Message Forwarding . . . . . . . . . . . . . . . . . . 45 5.2.3 Standard Message Processing Rules . . . . . . . . . . 45 5.3 Object Processing . . . . . . . . . . . . . . . . . . . . 45 5.3.1 Reservation Sequence Number (RSN) . . . . . . . . . . 45 5.3.2 Request Identification Information (RII) . . . . . . . 46 5.3.3 BOUND_SESSION_ID . . . . . . . . . . . . . . . . . . . 47 5.3.4 REFRESH_PERIOD . . . . . . . . . . . . . . . . . . . . 47 5.3.5 ERROR_SPEC . . . . . . . . . . . . . . . . . . . . . . 49 5.3.6 QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 49 5.4 Message Processing Rules . . . . . . . . . . . . . . . . . 50 5.4.1 RESERVE Messages . . . . . . . . . . . . . . . . . . . 50 5.4.2 QUERY Messages . . . . . . . . . . . . . . . . . . . . 52 5.4.3 RESPONSE Messages . . . . . . . . . . . . . . . . . . 53 5.4.4 NOTIFY Messages . . . . . . . . . . . . . . . . . . . 54 6. IANA considerations . . . . . . . . . . . . . . . . . . . . 55 7. QoS use of GIMPS service interface . . . . . . . . . . . . . 56 7.1 Example sender-initiated reservation . . . . . . . . . . . 56 7.2 Session identification . . . . . . . . . . . . . . . . . . 57 7.3 Support for bypassing intermediate nodes . . . . . . . . . 57 7.4 Support for peer change identification . . . . . . . . . . 58 7.5 Support for stateless operation . . . . . . . . . . . . . 58 7.6 Last node detection . . . . . . . . . . . . . . . . . . . 58 7.7 Re-routing detection . . . . . . . . . . . . . . . . . . . 59 7.8 Priority of signalling messages . . . . . . . . . . . . . 59 7.9 Knowledge of intermediate QoS NSLP unaware nodes . . . . . 59 7.10 NSLP Data Size . . . . . . . . . . . . . . . . . . . . . 60 7.11 Notification of GIMPS 'D' flag value . . . . . . . . . . 60 7.12 NAT Traversal . . . . . . . . . . . . . . . . . . . . . 60 8. Assumptions on the QSM . . . . . . . . . . . . . . . . . . . 61 8.1 Resource sharing . . . . . . . . . . . . . . . . . . . . . 61 8.2 Reserve/commit support . . . . . . . . . . . . . . . . . . 61 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 62 9.1 Peering agreements on interdomain links . . . . . . . . . 62 9.2 Protocol Operating Environment Assumptions . . . . . . . . 62 10. Security Considerations . . . . . . . . . . . . . . . . . . 64 10.1 Introduction and Threat Overview . . . . . . . . . . . . 64 10.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . 65 10.3 Computing the authorization decision . . . . . . . . . . 67 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 68 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 Van den Bosch, et al. Expires April 25, 2005 [Page 3] Internet-Draft NSLP for Quality-of-Service signalling October 2004 14.1 Normative References . . . . . . . . . . . . . . . . . . . 72 14.2 Informative References . . . . . . . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 74 A. POLICY_DATA Class . . . . . . . . . . . . . . . . . . . . . 76 A.1 Base Format . . . . . . . . . . . . . . . . . . . . . . . 76 A.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . 76 A.3 Policy Elements . . . . . . . . . . . . . . . . . . . . . 77 A.3.1 Authorization token Policy Element . . . . . . . . . . 77 A.3.2 OSP Token Policy Element . . . . . . . . . . . . . . . 79 A.3.3 User Identity Policy element . . . . . . . . . . . . . 79 Intellectual Property and Copyright Statements . . . . . . . 80 Van den Bosch, et al. Expires April 25, 2005 [Page 4] Internet-Draft NSLP for Quality-of-Service signalling October 2004 1. Introduction 1.1 Scope and background This document defines a Quality of Service (QoS) NSIS Signalling 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 signalling protocols, whose structure is outlined in the NSIS framework [I-D.ietf-nsis-fw]; this defines a common NSIS Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many aspects of signalling message delivery. A specification of the NTLP, GIMPS [I-D.ietf-nsis-ntlp] is done in another document. The design of QoS-NSLP is conceptually similar to RSVP, RFC 2205 [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 signalling path). Although there is no backwards compatibility at the level of protocol messages, interworking with RSVP at a signalling application gateway would be possible in some circumstances. 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 bi-directional reservation and support of reservations between arbitrary nodes, e.g. edge-to-edge, end-to-access, etc. On the other hand, there is no support for IP multicast. QoS-NSLP does not mandate any specific 'QoS Signalling Model' (QSM), i.e. a particular QoS provisioning method or QoS architecture; this is similar to (but stronger than) the decoupling between RSVP and the IntServ architecture, RFC 1633 [RFC1633]. It should be able to carry information for various QSMs; the specification of Integrated Services for use with RSVP given in RFC 2210 [RFC2210] could form the basis of one QSM. This document is structured as follows. The overall approach to protocol design is outlined in Section 3.1. The operation and use of QoS NSLP is then clarified by means of a number of examples in Section 4. These sections should be read by readers interested in the protocol capabilities. The functional specification Section 5 contains more detailed object and message formats and processing rules and should be the basis for implementers. The subsequent sections describe extensibility (IANA), requirements on GIMPS API and security considerations. Van den Bosch, et al. Expires April 25, 2005 [Page 5] Internet-Draft NSLP for Quality-of-Service signalling October 2004 1.2 Model of operation This section presents a logical model for the operation of the QoS-NSLP and associated provisioning mechanisms within a single node. The model is shown in Figure 1. +---------------+ | Local | |Applications or| |Management (e.g| |for aggregates)| +---------------+ ^ ^ V V +-------------+ +------------+----------+ +---------+ |Common NSLP | |QSM-specific| Resource | | Policy | | Processing +<<>>>| NSLP |Mgmt. Fct.|<<>| Control | | | | Processing | | | | +-------------+ +------------+----------+ +---------+ . ^ | * ^ | V . * ^ +----------+ * ^ | GIMPS | * ^ |Processing| * V +----------+ * V | | * V ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ . . * V | | * ............................. . . * . Traffic Control . | | * . +---------+. . . * . |Admission|. | | * . | Control |. +----------+ +------------+ . +---------+. <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | Packet | | Interface | .+----------+ +---------+. ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> | | |(Forwarding)| .|Classifier| Scheduler|. +----------+ +------------+ .+----------+ +---------+. ............................. <.-.-> = signalling flow =====> = data flow (sender --> receiver) <<<>>> = control and configuration operations ****** = routing table manipulation Van den Bosch, et al. Expires April 25, 2005 [Page 6] Internet-Draft NSLP for Quality-of-Service signalling October 2004 Figure 1: QoS-NSLP in a Node This diagram shows an example implementation scenario where QoS conditioning is performed on the output interface. However, this does not limit the possible implementations. For example, in some cases traffic conditioning may be performed on the incoming interface, or it may be split over the input and output interfaces. From the perspective of a single node, the request for QoS may result from a local application request, or from processing an incoming QoS- NSLP message. o The 'local application case' includes not only user applications (e.g. multimedia applications) but also network management (e.g. initiating a tunnel to handle an aggregate, or interworking with some other reservation protocol - such as RSVP) and the policy control module (e.g. for explicit teardown triggered by AAA). In this sense, the model does not distinguish between hosts and routers. o The 'incoming message' case requires NSIS messages to be captured during input packet processing and handled by GIMPS. Only messages related to QoS are passed to the QoS-NSLP. GIMPS may also generate triggers to the QoS-NSLP (e.g. indications that a route change has occurred). The QoS request is handled by a local 'resource management' function, which coordinates the activities required to grant and configure the resource. It also handles QoS Signalling Policy-specific message aspects. o The grant processing involves two local decision modules, 'policy control' and 'admission control'. Policy control determines whether the user has administrative permission to make the reservation. Admission control determines whether the node has sufficient available resources to supply the requested QoS. o If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. Error notifications are passed back to the request originator. The resource management function may also manipulate the forwarding tables at this stage, to select (or at least pin) a route; this must be done before interface-dependent actions are carried out (including forwarding outgoing messages over any new route), and is in any case invisible to the operation of the protocol. Policy control is expected to make use of a AAA service external to the node itself. Some discussion can be found in a separate document on AAA issues [I-D.tschofenig-nsis-aaa-issues] and one on auhorization issues [I-D.tschofenig-nsis-qos-authz-issues]. More generally, the processing of policy and resource management functions Van den Bosch, et al. Expires April 25, 2005 [Page 7] Internet-Draft NSLP for Quality-of-Service signalling October 2004 may be outsourced to an external node leaving only 'stubs' co-located with the NSLP; this is not visible to the protocol operation, although it may have some influence on the detailed design of protocol messages to allow the stub to be minimally complex. A more detailed discussion on authentication and authorization can be found in Section 3.1.4. The definition of the POLICY_DATA class is given in Appendix A. The group of user plane functions, which implement QoS for a flow (admission control, packet classification, and scheduling) is sometimes known as 'traffic control'. Admission control, packet scheduling, and any part of policy control beyond simple authentication have to be implemented using specific definitions for types and levels of QoS; Our assumption is that the QoS-NSLP is independent of the QoS parameters (e.g. IntServ service elements). These are captured in a QoS Signalling Policy and interpreted only by the resource management and associated functions, and are opaque to the QoS-NSLP itself. QoS Signalling Policy is discussed further in Section 3.1.3. The final stage of processing for a resource request is to indicate to the QoS-NSLP protocol processing that the required resources have been configured. The QoS-NSLP may generate an acknowledgement message in one direction, and may propagate the resource request forwards in the other. Message routing is (by default) carried out by GIMPS module. Note that while Figure 1 shows a unidirectional data flow, the signalling messages can pass in both directions through the node, depending on the particular message and orientation of the reservation. Van den Bosch, et al. Expires April 25, 2005 [Page 8] Internet-Draft NSLP for Quality-of-Service signalling October 2004 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. The terminology defined by GIMPS [I-D.ietf-nsis-ntlp] applies to this draft. 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. Source or message source: The one of two adjacent NSLP peers that is sending a signalling message (maybe the upstream or the downstream peer). NB: this is not necessarily the QNI. QoS NSLP operation state: state used/kept by QoS NSLP processing to handle messaging aspects. QoS reservation state: state used/kept by Resource Management Function to describe reserved resources for a session. QoS NSLP nodes IP address (QoS unware 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 | +--------+ | | | | | | +------+ +------+ +------+ =====================> <===================== Signalling Flow Van den Bosch, et al. Expires April 25, 2005 [Page 9] Internet-Draft NSLP for Quality-of-Service signalling October 2004 3. Protocol Overview 3.1 Overall approach 3.1.1 GIMPS Interactions The QoS NSLP uses GIMPS for delivery of all its messages. Messages are normally passed from the NSLP to the GIMPS via an API, which also specifies additional information, including an identifier for the signalling application (e.g. 'QoS-NSLP'), the flow/session identifier, and an indication of the intended direction - towards data sender or receiver. On reception, GIMPS provides the same information to the QoS-NSLP. In addition to the NSLP message data itself, other meta-data (e.g. session identifier, flow routing information) can be transferred across this interface. The QoS NSLP does not provide any method of interacting with firewalls or Network Address Translators (NATs). It assumes that a basic NAT traversal service is provided by the GIMPS. 3.1.2 Protocol messages The QoS NSLP uses four message types: RESERVE: The RESERVE message is the only message that manipulates QoS NSLP reservation state. It is used to create, refresh, modify and remove such state. The RESERVE message is idempotent; the resultant effect is the same whether a message is received once or many times. QUERY: A QUERY message is used to request information about the data path without making a reservation. This functionality can be used to 'probe' the network for path characteristics, for receiver-initiated reservations or for support of certain QoS models. The information obtained from a QUERY may be used in the admission control process of a QNE (e.g. in case of measurement-based admission control). Note that a QUERY does not change existing reservation state. It does not cause QoS NSLP state to be installed in nodes other than the one that generated the QUERY. RESPONSE: The RESPONSE message is used to provide information about the result of a previous QoS-NSLP message. This includes explicit confirmation of the state manipulation signaled in the RESERVE message, the response to a QUERY message or an error code if the QNE or QNR is unable to provide the requested information or if the response is negative. The RESPONSE message is impotent, it does not cause any reservation state to be installed or modified. Van den Bosch, et al. Expires April 25, 2005 [Page 10] Internet-Draft NSLP for Quality-of-Service signalling October 2004 NOTIFY: NOTIFY messages are used to convey information to a QNE. They differ from RESPONSE messages in that they are sent asynchronously and need not refer to any particular state or previously received message. The information conveyed by a NOTIFY message is typically related to error conditions. Examples would be notification to an upstream peer about state being torn down or to indicate when a reservation has been pre-empted. QoS-NSLP messages are sent peer-to-peer. This means that a QNE considers its adjacent upstream or downstream peer to be the source of the each message. Each protocol message has a common header which indicates the message type and contains flags. Message formats are defined in Section 5.1.2. Message processing rules are defined in Section 5.4. QoS NSLP messages contain three types of objects: Control Information: Control information objects carry general information for the QoS NSLP processing, such as sequence numbers or whether a response is required. This may include some mechanisms that are useful for many QSMs (Common Control Information) and some that are for a particular QSM only (QSM specific Control Information). QSM specific Control Information is specified together with a QSM. This specification only defines Common Control Information. Currently, Common Control Information is defined for session identification, message sequencing, response request, message scoping and session lifetime. QoS specifications (QSPECs): QSPEC objects describe the actual resources that are required and are specific to the QSM being used. Besides any resource description they may also contain QSM specific control information used by the QSM's processing. Policy objects: Policy objects contain data used to authorise the reservation of resources. Object formats are defined in Section 5.1.3. Object processing rules are defined in Section 5.3. 3.1.3 QoS Signalling Models and QoS specifications A QoS Signalling Model (QSM) is a mechanism which allows QNEs to signal for QoS reservations in the Internet using QoS NSLP. It does not define new QoS provisioning methods or architectures, which we collectively denote as a "QoS model", but rather enables signalling for existing ones. Integrated Services [RFC1633], Differentiated Services [RFC2475] and RMD [I-D.westberg-rmd-framework] are all examples of QoS architectures for which a QSM can be specified. Van den Bosch, et al. Expires April 25, 2005 [Page 11] Internet-Draft NSLP for Quality-of-Service signalling October 2004 There is no restriction on the number of QSMs that can be defined. QSMs may be local (private to one network), implementation/vendor specific, or global (implementable by different networks and vendors). The authors are currently aware of three efforts related to QSM specification: IntServ Controlled Load [I-D.kappler-nsis-qosmodel-controlledload], based on ITU [I-D.ash-nsis-nslp-qos-sig-proof-of-concept] and Resource Management for DiffServ (RMD) [I-D.bader-rmd-qos-model][I-D.bader-nsis-rmd-diffserv-qsm]. The specification of a QSM includes a description of its QoS parameter information, as well as how that information should be treated or interpreted in the network. In that sense, the QSM goes beyond the QoS NSLP protocol level in that it could also describe the role of QNEs in this QoS Model and a certain QSPEC. Specification of a certain QSPEC may include specifying generic and optional parameters (including how generic parameters not used in this QSM are mapped onto parameters defined therein) and QSM-specific message formats or state management. The information needed to signal for a QSM is carried in QoS NSLP inside a QoS specification (QSPEC) object. The QSPEC is opaque to the QoS NSLP and similar in purpose to the TSpec, RSpec and AdSpec specified in RFC 2205 [RFC2205] and RFC 2210 [RFC2210]. At each QNE, its content is interpreted by the Resource Management Function and the Policy Control Function for the purposes of policy control and traffic control (including admission control and configuration of the packet classifier and scheduler). An ongoing effort attempts to specify a QSPEC template. The QSPEC template contains object formats for generally useful elements of the QoS description, which is expected to enhance interoperability. The QSPEC template defines a QSM ID, QSM-specific Control Information and a QoS Description. A QSM specifies which generic parameters may be carried in the QSPEC, or restricts the values these parameters can take. A QSM may also define additional QSM-specific parameters. 3.1.4 Authentication and authorization The QoS signalling protocol needs to exchange information which is subsequently used as input to the AAA infrastructure. The response from the AAA infrastructure must also be returned and processed by the respective entities. Van den Bosch, et al. Expires April 25, 2005 [Page 12] Internet-Draft NSLP for Quality-of-Service signalling October 2004 +-------------+ | Entity | | authorizing | | resource | | request | +-----+-------+ | | /-\----+-----/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +-------------+ QoS signalling +---+--+ | Entity |<=================>| |<=========> | requesting | Data Flow | QNE | | resource |-------------------|------|----------> +-------------+ +------+ QoS NSLP requests allow particular user(s) to obtain preferential access to network resources. To prevent abuse, some form of an access control (also known as policy based admission control) will generally be required on users who make reservations. Typically, such authorization is expected to make use of an AAA service external to the node itself. In any case, cryptographic user identification and selective admission will generally be needed when a reservation is requested. The QoS NSLP request is handled by a local 'resource management' function, which coordinates the activities required to grant and configure the resource. The grant processing involves two local decision modules, 'policy control' and 'admission control'. Policy control determines whether the user is sufficiently authorized to make the reservation. Admission control determines whether the node has sufficient available resources to offer the requested QoS. 3.1.4.1 Policy Ignorant Nodes It is generally assumed that policy enforcement is likely to concentrate on border nodes between administrative domains. Figure 4 below illustrates a simple administrative domain with: o two boundary nodes (A, C), which represent QNEs authorized by AAA entities. o A core node (B) represents an Policy Ignorant QNE (PIN) with capabilities limited to default admission control handling. Van den Bosch, et al. Expires April 25, 2005 [Page 13] Internet-Draft NSLP for Quality-of-Service signalling October 2004 Authorizing Entity 1 Authorizing Entity 2 | | | | +---+ +---+ +---+ | A +---------+ B +---------+ C | +---+ +---+ +---+ QNE1 PIN QNE2 Figure 4: Administrative Domain scenario Here, policy objects transmitted across the domain traverse an intermediate PIN node (B) that is allowed to process QoS NSLP message but does not handle policy information. 3.1.4.2 Policy Data The input to policy control is referred to as "Policy data", which QoS NSLP carries in the POLICY_DATA object. Policy data may include credentials identifying entities and traits depending on the authorization model in use (2-party, 3-party, token-based 3-party). There are no requirements for all nodes to process this object. Policy data itself is opaque to the QoS NSLP, which simply passes it to policy control when required. The policy data is independent from the QSM in use. Policy control depends on successful user authentication and authorization of a QoS NSLP reservation request. The authorization decision might be valid for a certain amount of time or even for the entire lifetime of the session. It is a decision of the involved party to trigger a re-authorization procedure. This feature is supported by the Policy Refresh Timer (PRT) option of the Policy object. Policy objects are carried by QoS NSLP messages and contain policy information. All policy-capable nodes (at any location in the network) can generate, modify, or remove policy objects, even when senders or receivers do not provide, and may not even be aware of policy data objects. The exchange of Policy objects between policy-capable QNEs along the data path, supports the generation of consistent end-to-end policies. Furthermore, such policies can be successfully deployed across multiple administrative domains when border nodes manipulate and translate Policy objects according to established sets of bilateral agreements. Van den Bosch, et al. Expires April 25, 2005 [Page 14] Internet-Draft NSLP for Quality-of-Service signalling October 2004 3.2 Design decisions QoS NSLP was designed according to the principles and supports the functionality outlined below. 3.2.1 Soft-state The NSIS protocol suite takes a soft-state approach to state management. This means that reservation state in QNEs must be periodically refreshed. The frequency with which state installation is refreshed is expressed in the REFRESH_PERIOD object. This object contains a value in milliseconds indicating how long the state that is signalled for remains valid. Maintaining the reservation beyond this lifetime can be done by sending a ("refreshing") RESERVE message. 3.2.2 Sender-receiver initiation QoS NSLP supports both sender-initiated and receiver-initiated reservations. For a sender-initiated reservation, RESERVE messages travel in the same direction as the dataflow that is being signalled for (the QNI is at the side of the source of the dataflow). For a receiver-initiated reservation, RESERVE messages travel in the opposite direction (the QNI is at the side of the receiver of the data flow) 3.2.3 Message sequencing RESERVE messages affect the installed reservation state. Unlike NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE messages are received influences the eventual reservation state that will be stored at a QNE. Therefore, QoS NSLP supports detection of RESERVE message re-ordering or duplication with Reservation Sequence Number (RSN). The RSN has local significance only, i.e. between QNEs. Attempting to make an identifier that was unique in the context of a SESSION_ID but the same along the complete path would be very hard. Since RESERVE messages can be sent by any node on the path that maintains reservation state (e.g. for path repair) we would have the difficult task of attempting to keep the identifier synchronized along the whole path. Since message ordering only ever matters between a pair of peer QNEs, we can make the RSN unique just between a pair of neighbouring stateful QNEs. By managing the sequence numbers in this manner, the source of the RESERVE does not need to determine how the next QNE will process the message. Note that, since the RSN is unique within a SESSION_ID, it can be Van den Bosch, et al. Expires April 25, 2005 [Page 15] Internet-Draft NSLP for Quality-of-Service signalling October 2004 used together with a SESSION_ID to refer to particular installed state. 3.2.4 Explicit state installation confirmation and responses A QNE may desire an explicit confirmation of its state installation actions from the immediate upstream or downstream peer. This is achieved by using an ACKNOWLEDGE (A) flag in the message header. In addition to this, a QNE may require other information such as a confirmation that the end-to-end reservation is in place or a reply to a query along the path. For such requests, it must be able to keep track of which request each response refers to. This is supported by including a Request Identification Information (RII) object in a QoS NSLP message. 3.2.5 Summary refreshes For scalability, QoS NSLP supports an abbreviated form of refreshing RESERVE message ("summary refresh"). In this case, the refreshing RESERVE references the reservation using the RSN and the SESSION_ID, rather than including the full reservation specification (including QSPEC, ...). Summary refreshes require an explicit acknowledgment of state installation to ensure that the RSN reference will be understood. It is up to a QNE that receives a message containing an RII to decide whether it wants to accept summary refreshes and provide this explicit acknowledgment. 3.2.6 Message scoping A QNE may use local policy when deciding whether to propagate a message or not. The QoS NSLP also includes an explicit mechanism to restrict message propagation by means of a scoping mechanism. For a RESERVE or a QUERY message, a SCOPING flag limits the part of the path on which state is installed or the downstream nodes that can respond. When set to zero, it indicates that the scope is "whole path" (default). When set to one, the scope is "single hop". The propagation of a RESPONSE message is limited by the RII object, which ensures that it is not forwarded back along the path further than the node that requested the RESPONSE. This specification does not support an explicit notion of a region scope or "to the CRN". If needed, this can be easily proposed as an extension later on,e.g. based on LRSVP [I-D.manner-lrsvp]. Van den Bosch, et al. Expires April 25, 2005 [Page 16] Internet-Draft NSLP for Quality-of-Service signalling October 2004 3.2.7 Session binding Session binding is defined as the enforcement of a relation between different QoS NSLP sessions (i.e. signalling flows with different SESSION_ID (SID) as defined in GIMPS [I-D.ietf-nsis-ntlp]). Session binding indicates a (possibly asymmetric) dependency relation between two or more sessions by including a BOUND_SESSION_ID object. A session with SID_A (the binding session) can express its relation to another session with SID_B (the bound session) by including a BOUND_SESSION_ID object containing SID_B in its messages. The dependency is asymmetric if the session with SID_B does not carry a BOUND_SESSION_ID object containing SID_A. The concept of session binding is used to indicate the dependency between the end-to-end session and the aggregate session in case of aggregate reservations. In case of bidirectional reservations, it is used to express the dependency between the sessions used for forward and reverse reservation. Note that the dependency indicated by session binding is purely informative in nature and does not automatically trigger any action in a QNE. However, a QNE may use the information for local resource optimisation or to tear down reservations that are no longer useful. 3.2.8 Layering QoS NSLP supports layered reservations. Layered reservations may occur when certain parts of the network (domains) implement one or more local QoS models, or when they locally apply specific control plane characteristics (e.g. GIMPS unreliable transfer mode instead of reliable transfer mode). They may also occur when several per-flow reservations are locally combined into an aggregate reservation. 3.2.8.1 Local QoS models A domain may have local policies regarding QSM implementation, i.e. it may map incoming traffic to its own locally defined QSMs. QoS NSLP supports this by allowing QSPEC objects to be stacked. When a domain wants to apply a certain QSM to an incoming per-flow reservation request, each edge of the domain is configured to map the incoming QSPEC object to a local QSPEC object and push that object onto the stack of QSPEC objects (typically immediately following the Common Control Information, i.e. the first QSPEC that is found in the message). QNEs inside the domain look at the top of the QSPEC object stack to determine which QSM to apply for the reservation. Van den Bosch, et al. Expires April 25, 2005 [Page 17] Internet-Draft NSLP for Quality-of-Service signalling October 2004 The position of the local QSPEC object in the stack implies a tradeoff between the speed with which incoming messages can be processed and the time it takes to construct the outgoing message (if any). By mandating the locally valid object to be on top of the stack we value ease of processing over ease of message construction. 3.2.8.2 Local control plane properties The way signalling messages are handled is mainly determined by the parameters that are sent over GIMPS-NSLP API and by the Common Control Information. A domain may have a policy to implement local control plane behaviour. It may, for instance, elect to use an unreliable transport locally in the domain while still keeping end-to-end reliability intact. The QoS NSLP supports this situation by allowing two sessions to be set up for the same reservation. The local session has the desired local control plane properties and is interpreted in internal QNEs. This solution poses two requirements: the end-to-end session must be able to bypass intermediate nodes and the egress QNE needs to bind both sessions together. Intermediate node bypass is achieved with GIMPS. The local session and the end-to-end session are bound at the egress QNE by means of the BOUND_SESSION_ID object. 3.2.8.3 Aggregate reservations In some cases it is desirable to create reservations for an aggregate, rather than on a per-flow basis, in order to reduce the amount of reservation state needed as well as the processing load for signalling messages. The QoS NSLP, therefore, provides aggregation facilities similar to RFC 3175 [RFC3175]. However, the aggregation scenarios supported are wider than that proposed there. Note that QoS NSLP does not specify how reservations need to be combined in an aggregate or how end-to-end properties need to be computed but only provides signalling support for it. The essential difference with the layering approaches described in Section 3.2.8.1 and Section 3.2.8.2 is that the aggregate reservation needs a FlowID that describes all traffic carried in the aggregate (e.g. a DSCP in case of IntServ over DiffServ). The need for a different FlowID mandates the use of two different sessions, similar to Section 3.2.8.2 and to the RSVP aggregation solution RFC 3175 [RFC3175]. Edge QNEs of the aggregation domain that want to maintain some end-to-end properties may establish a peering relation by sending the Van den Bosch, et al. Expires April 25, 2005 [Page 18] Internet-Draft NSLP for Quality-of-Service signalling October 2004 end-to-end message transparantly over the domain (using the intermediate node bypass capability described above). Updating the end-to-end properties in this message may require some knowledge of the aggregated session (e.g. for updating delay values). For this purpose, the end-to-end session contains a BOUND_SESSION_ID carrying the SESSION_ID of the aggregate session. 3.2.9 Priority This specification acknowledges the fact that in some situations, some messages or some reservations may be more important than others and therefore foresees mechanisms to give these messages or reservations priority. Priority of certain signalling messages over others may be required in mobile scenarios when a message loss during call set-up is less harmful then during handover. This situation only occurs when GIMPS or QoS NSLP processing is the congested part or scarce resource. This specification requests GIMPS design to foresee a mechanism to support a number of levels of message priority that can be requested over the NSLP-GIMPS API. Priority of certain reservations over others may be required when QoS resources are oversubscribed. In that case, existing reservations may be preempted in order to make room for new higher-priority reservations. A typical approach to deal with priority and preemption is through the specification of a setup priority and holding priority for each reservation. The resource management function at each QNE then keeps track of the resource consumption at each priority level. Reservations are established when resources, at their setup priority level, are still available. They may cause preemption of reservations with a lower holding priority than their setup priority. Support of reservation priority is a QSM specific issue and therefore outside the scope of this specification. 3.2.10 Rerouting (SII) QoS NSLP needs to adapt to route changes in the data path. This assumes the capability to detect rerouting events, perform QoS reservation on the new path and optionally tear down reservations on the old path. Rerouting detection can be performed at three levels. First, routing modules may detect route changes through their interaction with routing protocols. Certain QNEs or GIMPS implementations may interact with local routing module to receive quick notification of Van den Bosch, et al. Expires April 25, 2005 [Page 19] Internet-Draft NSLP for Quality-of-Service signalling October 2004 route changes. This is largely implementation-specific and outside of the scope of NSIS. Second, route changes may be detected at GIMPS layer. This specification requests GIMPS design to foresee notification of this information over the API. This is outside the scope of the QoS NSLP specification. Third, rerouting may be detected at the NSLP layer. A QoS NSLP node is able to detect changes in its QoS NSLP peers by keeping track of a Source Identification Information (SII) object that is similar in nature to the RSVP_HOP object described in RFC 2205 [RFC2205]. When a RESERVE message with an existing SESSION_ID and a different SII is received, the QNE knows its upstream peer has changed. Reservation on the new path happens when a refreshing RESERVE message arrives at the QNE where the old and the new path diverge. The refreshing RESERVE will be interpreted as a new RESERVE on the new path. Depending on the transfer mode, this may require installation of a new messaging association. Rapid recovery at the NSLP layer therefore requires short refresh periods. Detection before the next RESERVE message arrives is only possible at the IP layer or through monitoring of GIMPS peering relations (e.g. by TTL counting the number of GIMPS hops between NSLP peers or the observing changes in the outgoing interface towards GIMPS peer). These mechanisms can provide implementation specific optimisations, and are outside the scope of this specification. When the QoS NSLP is aware of the route change, it needs to set up the reservation on the new path. This is done by incrementing the RSN and then sending a new RESERVE message. On links that are common to the old and the new path, this RESERVE message is interpreted as a refreshing RESERVE. On new links, it creates the reservation. After the reservation on the new path is set up, the branching node or the merging node may want to tear down the reservation on the old path (faster than what would result from normal soft-state time-out). This functionality is supported by keeping track of the old SII. This specification requests GIMPS design to provide support for an SII that is interpreted as a random identifier at the QoS NSLP but that allows, when passed over the API, to forward QoS NSLP messages to the QNE identified by that SII. A QNI or a branch node may wish to keep the reservation on the old branch. This could for instance be the case when a mobile node has experienced a mobility event and wishes to keep reservation to its old attachment point in case it moves back there. For this purpose, a REPLACE flag is foreseen in the common header, which, when set to FALSE, indicates that the reservation on the old branch should be kept. Van den Bosch, et al. Expires April 25, 2005 [Page 20] Internet-Draft NSLP for Quality-of-Service signalling October 2004 4. Examples of QoS NSLP Operation The QoS NSLP can be used in a number of ways. The examples given here give an indication of some of the basic processing. However, they are not exhaustive and do not attempt to cover the details of the protocol processing. 4.1 Basic sender-initiated reservation QNI QNE QNE QNR | | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | | | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | | | | | | | | | Figure 5: Basic Sender Initiated Reservation To make a new reservation, the QNI constructs a RESERVE message containing a QSPEC object, from its chosen QSM, which describes the required QoS parameters. The RESERVE message is passed to GIMPS which transports it to the next QNE. There it is delivered to the QoS NSLP processing which examines the message. Policy control and admission control decisions are made. The exact processing also takes into account the QSM being used. The node performs appropriate actions (e.g. installing reservation) based on the QSPEC object in the message. The QoS NSLP then generates a new RESERVE message (usually based on the one received). This is passed to GIMPS, which forwards it to the next QNE. The same processing is performed at further QNEs along the path, up to the QNR. The determination that a node is the QNR may be made directly (e.g. that node is the destination for the data flow), or using some GIMPS functionality to determine that there are no more Van den Bosch, et al. Expires April 25, 2005 [Page 21] Internet-Draft NSLP for Quality-of-Service signalling October 2004 QNEs between this node and the data flow destination. A node can ask a confirmation of the installed state from its immediate peer. It does so by setting the A flag, which causes a RESPONSE message to be sent by the immediate peer. One use of this is to confirm the installation of state, which allows the use of summary refreshes that later refer to that state. A RESPONSE message can also indicate an error when, for example, a reservation has failed to be installed. Any node may include a request for a RESPONSE in its RESERVE messages. It does so by including a Request Identification Information (RII) object in the RESERVE message. The RESPONSE is forwarded peer-to-peer along the reverse of the path that the RESERVE message took (using GIMPS path state), and so is seen by all the QNEs on the reverse-path. It is only forwarded as far as the node which requested the RESPONSE. The reservation can subsequently be refreshed by sending further RESERVE messages containing the complete reservation information, as for the initial reservation. The reservation can also be modified in the same way, by changing the QSM-specific data to indicate a different set of resources to reserve. The overhead required to perform refreshes can be reduced, in a similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a RESPONSE message has been received indicating the successful installation of a reservation, subsequent refreshing RESERVE messages can simply refer to the existing reservation, rather than including the complete reservation specification. 4.2 Sending a Query QUERY messages can be used to gather information from QNEs along to path. For example, it can be used to find out what resources are available before a reservation is made. In order to perform a query along a path, the QNE constructs a QUERY message. This message includes QSM-specific objects containing the actual query to be performed at QNEs along the path. It also contains an object used to match the response back to the query, and an indicator of the query scope (next node, whole path). The QUERY message is passed to GIMPS to forward it along the path. A QNE (including the QNR) receiving a QUERY message should inspect it and create a new message, based on that received with the query objects modified as required. For example, the query may request Van den Bosch, et al. Expires April 25, 2005 [Page 22] Internet-Draft NSLP for Quality-of-Service signalling October 2004 information on whether a flow can be admitted, and so a node processing the query might record the available bandwidth. The new message is then passed to GIMPS for further forwarding (unless it knows it is the QNR, or is the limit for the scope in the QUERY). At the QNR, a RESPONSE message must be generated if the QUERY message includes a Request Identification Information (RII) object. Into this is copied various objects from the received QUERY message. It is then passed to GIMPS to be forwarded peer-to-peer back along the path. Each QNE receiving the RESPONSE message should inspect the RII object to see if it 'belongs' to it (i.e. it was the one that originally created it). If it does not then it simply passes the message back to GIMPS to be forwarded back down the path. 4.3 Basic receiver-initiated reservation As described in the NSIS framework [I-D.ietf-nsis-fw] in some signalling applications, a node at one end of the data flow takes responsibility for requesting special treatment - such as a resource reservation - from the network. Both ends then agree whether sender or receiver-initiated reservation is to be done. In case of a receiver initiated reservation, both ends agree whether a "One Pass With Advertising" (OPWA) [_XREF_OPWA95] model is being used. This negotiation can be accomplished using mechanisms that are outside the scope of NSIS, see Section 9.2. To make a receiver-initiated reservation, the QNI constructs a QUERY message, which may contain a QSPEC object from its chosen QSM (see Figure 6). This QUERY message does not need to trigger a RESPONSE message and therefore, the QNI must not include the RII object (Section 5.4.2), into the QUERY message. The QUERY message may be used to gather information along the path, which is carried by the QSPEC object. An example of such information is the "One Pass With Advertising" (OPWA) [_XREF_OPWA95]. This QUERY message causes GIMPS reverse-path state to be installed. Van den Bosch, et al. Expires April 25, 2005 [Page 23] Internet-Draft NSLP for Quality-of-Service signalling October 2004 QNR QNE QNE QNI sender receiver | | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | | | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | | | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | Figure 6: Basic Receiver Initiated Reservation The QUERY message is transported by GIMPS to the next downstream QoS NSLP node. There it is delivered to the QoS NSLP processing which examines the message. The exact processing also takes into account the QSM being used and may include gathering information on path characteristics that may be used to predict the end-to-end QoS. The QoS NSLP then generates a new QUERY message (usually based on the one received). This is passed to GIMPS, which forwards it to the next QNE. The same processing is performed at further QNEs along the path, up to the receiver, which in this situation is the QNR. The QNR detects that this QUERY message does not carry an RII object and by using the information contained in the received QUERY message, such as the QSPEC, constructs a RESERVE message. The RESERVE is forwarded peer-to-peer along the reverse of the path that the QUERY message took (using GIMPS reverse path state). Similar to the sender-initiated approach, any node may include an RII in its RESERVE messages. The reservation can subsequently be refreshed in the same way as for the sender-initiated approach. This RESERVE message may be also used Van den Bosch, et al. Expires April 25, 2005 [Page 24] Internet-Draft NSLP for Quality-of-Service signalling October 2004 to refresh GIMPS reverse path state. Alternatively, refreshing GIMPS reverse path state could be performed by sending periodic QUERY messages, which are needed in case of route changes anyway. 4.4 Bidirectional Reservations Bidirectional reservations are supported by binding two uni-directional sessions together. We distinguish two cases: o Binding two sender-initiated reservations, e.g. one sender-initiated reservation from QNE A to QNE B and another one from QNE B to QNE A. o Binding a sender-intiated and a receiver-initiated reservation, e.g. a sender-initiated reservation from QNE A towards QNE B, and a receiver-initiated reservation from QNE A towards QNE B for the data flow in the opposite direction (from QNE B to QNE A). This case is particularly useful when one end of the communication has all required information to set up both sessions. Both ends have to agree on which bi-directional reservation type they need to use. This negotiation/agreement can be accomplished using mechanisms that are outside the scope of NSIS, see Section 9.2. The scenario with two sender-initiated reservation is shown on Figure 7. Note that RESERVE messages for both directions may visit different QNEs along the path because of asymmetric routing. Both directions of the flows are bound by inserting the BOUND_SESSION_ID object at the QNI and QNR. RESPONSE messages are optional and not shown on the picture for simplicity. A QNE QNE B | | FLOW-1 | | |===============================>| |RESERVE-1 | | | QNI+--------->|RESERVE-1 | | | +-------------------->|QNR | | | | | | FLOW-2 | | |<===============================| | | |RESERVE-2 | | RESERVE-2 |<---------+QNI QNR|<--------------------+ | | | | | Figure 7: Bi-directional reservation for sender+sender scenario The scenario with a sender-initiated and a receiver-initiated reservation is shown on Figure 8. In this case, QNI B sends out two RESERVE messages, one for the sender-initiated and one for the Van den Bosch, et al. Expires April 25, 2005 [Page 25] Internet-Draft NSLP for Quality-of-Service signalling October 2004 receiver-initiated reservation. A QNE QNE B | | FLOW-1 | | |===============================>| | QUERY-1 | | | QNI+--------->| QUERY-1 | | | +-------------------->|QNR | | | | |RESERVE-1 | | | QNI+<---------|RESERVE-1 | | | +<--------------------|QNR | | | | | | FLOW-2 | | |<===============================| | | |RESERVE-2 | |RESERVE-2 | |<---------+QNI QNR|<--------------------+ | | | | | Figure 8: Bi-directional reservation for sender+receiver scenario 4.5 Use of Local QoS Models In some cases it may be required to use a different QSM along a particular segment of the signalling. In this case a node at the edge of this region needs to map between the two resource descriptions (and any auxiliary data). +-------- QSM2 domain --------+ | | | | +----+ +----+ +----+ +----+ +----+ |QNI | |edge| |int.| |edge| |QNR | | |========>|QNE |========>|QNE |========>|QNE |========>| | +----+ RESERVE +----+ RESERVE +----+ RESERVE +----+ RESERVE +----+ QSPEC1 | QSPEC2 QSPEC2 | QSPEC1 | {QSPEC1} {QSPEC1} | | | +-----------------------------+ Figure 9: Reservation with local QoS Models This initially proceeds as for the basic example, with peer-to-peer installation of reservations. However, within a region of the network a different QSM (QSM2) needs to be used. At the edge of this Van den Bosch, et al. Expires April 25, 2005 [Page 26] Internet-Draft NSLP for Quality-of-Service signalling October 2004 region the QNEs support both the end-to-end and local QoS models. When the RESERVE message reaches the QNE at the ingress, the initial processing of the RESERVE proceeds as normal. However, the QNE also determines the appropriate description using QSM2. The RESERVE message to be sent out is constructed mostly as usual but with a second QSPEC object added on top, which becomes the 'current' one. When this RESERVE message is received at an node internal to the QSM2 domain the QoS NSLP only uses the QSPEC at the top of the stack (i.e. the 'current' one), rather than the end-to-end QSPEC. Otherwise, processing proceeds as usual. The RESERVE message that it generates should include the complete stack of QSPECs from the message it received. At the QNE at the egress of the region the local QSPEC is removed from the message so that subsequent QNEs receive only the end-to-end QSPEC. QSPECs can be stacked in this way to an arbitrary depth. 4.6 Aggregate Reservations In order to reduce signalling and per-flow state in the network, the reservations for a number of flows may be aggregated together. Van den Bosch, et al. Expires April 25, 2005 [Page 27] Internet-Draft NSLP for Quality-of-Service signalling October 2004 QNI QNE QNE/QNI' QNE' QNR'/QNE QNR aggregator deaggregator | | | | | | | RESERVE | | | | | +--------->| | | | | | | RESERVE | | | | | +--------->| | | | | | | RESERVE | | | | | +-------------------->| | | | | RESERVE' | | | | | +=========>| RESERVE' | | | | | +=========>| RESERVE | | | | | +--------->| | | | | RESPONSE'| | | | | RESPONSE'|<=========+ | | | |<=========+ | | | | | | | RESPONSE | | | | | RESPONSE |<---------+ | | |<--------------------+ | | | RESPONSE | | | | | |<---------+ | | | | RESPONSE | | | | | |<---------+ | | | | | | | | | | | | | | | | Figure 10: Sender Initiated Reservation with Aggregation An end-to-end per-flow reservation is initiated as normal (with messages shown in Figure 10 as "RESERVE"). At the aggregator a reservation for the aggregated flow is initiated (shown in Figure 10 as "RESERVE'"). This may use the same QSM as the end-to-end reservation but has a flow identifier for the aggregated flow (e.g. tunnel) instead of for the individual flows. This document does not specify how the QSPEC of the aggregate session can be derived from the QSPECs of the end-to-end sessions. Markings are used so that intermediate routers do not need to inspect the individual flow reservations. The deaggregator then becomes the next hop QNE for the end-to-end per-flow reservation. Van den Bosch, et al. Expires April 25, 2005 [Page 28] Internet-Draft NSLP for Quality-of-Service signalling October 2004 Aggregator Deaggregator +---+ +---+ +---+ +---+ |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate +---+ +---+ +---+ +---+ reservation +---+ +---+ ..... ..... +---+ +---+ |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end +---+ +---+ ..... ..... +---+ +---+ reservation The deaggregator acts as the QNR for the aggregate reservation. Information is carried in the reservations to enable the deaggregator to associate the end-to-end and aggregate reservations with one another. The key difference between this example, and previous ones is that the flow identifier for the aggregate is expected to be different to that for the end-to-end reservation. The aggregate reservation can be updated independently of the per-flow end-to-end reservations. 4.7 Reduced State or Stateless Interior Nodes This example uses a different QSM within a domain, in conjunction with GIMPS and NSLP functionality which allows the interior nodes to avoid storing GIMPS and QoS NSLP state. As a result the interior nodes only store the QSM-specific reservation state, or even no state at all. This allows the QSM to use a form of "reduced-state" operation, where reservation states with a coarser granularity (e.g. per-class) are used, or a "stateless" operation where no QoS NSLP state is needed (or created). The key difference between this example and the use of different QSMs in Section 4.5 is that the transport characteristics for the 'local' reservation can be different from that of the end-to-end reservation, i.e. GIMPS can be used in a different way for the edge-to-edge and hop-by-hop sessions. The reduced state reservation can be updated independently of the per-flow end-to-end reservations. Van den Bosch, et al. Expires April 25, 2005 [Page 29] Internet-Draft NSLP for Quality-of-Service signalling October 2004 QNE QNE QNE QNE ingress interior interior egress GIMPS stateful GIMPS stateless GIMPS stateless GIMPS stateful | | | | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | | RESERVE | | | +--------> | | | | RESPONSE | | | |<-------- | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | Figure 12: Sender-initiated reservation with Reduced State Interior Nodes The QNI performs the same processing as before to generate the initial RESERVE message, and it is forwarded by GIMPS as usual. At the QNEs at the edges of the stateless or reduced-state region the processing is different and the nodes support two QoS models. At the ingress the original RESERVE message is forwarded but ignored by the stateless or reduced-state nodes. The egress node is the next QoS NSLP hop for that session. After the initial discovery phase using unreliable GIMPS transfer mode, reliable GIMPS transfer mode between the ingress and egress can be used. At the egress node the RESERVE message is then forwarded normally. At the ingress a second RESERVE' message is also built. This makes use of a QSM suitable for a reduced state or stateless form of operation (such as the RMD per hop reservation). Since the original RESERVE and the RESERVE' messages are addressed identically, RESERVE' visits the same nodes that were visited, including the egress QNE. When processed by interior (stateless) nodes the QoS NSLP processing excercises its options to not keep state wherever possible, so that no per flow QoS NSLP state is stored. Some state, e.g. per class, for the QSM related data may be held at these interior nodes. The QoS NSLP also requests that GIMPS use different transport Van den Bosch, et al. Expires April 25, 2005 [Page 30] Internet-Draft NSLP for Quality-of-Service signalling October 2004 characteristics (i.e. sending of messages in unreliable GIMPS transfer mode). It also requests the local GIMPS processing not to retain messaging association state or reverse message routing state. Nodes, such as those in the interior of the stateless or reduced-state domain, that do not retain reservation state cannot send back RESPONSE messages (and so cannot use summary refreshes). At the egress node the RESERVE' message is interpreted in conjunction with the reservation state from the end-to-end RESERVE message (using information carried in the message to correlate the signalling flows). The RESERVE message is only forwarded further if the processing of the RESERVE' message was successful at all nodes in the local domain, otherwise the end-to-end reservation is regarded as having failed to be installed. Since GIMPS neighbour relations are not maintained in the reduced-state region, only sender initiated signalling can be supported. If a receiver-initiated reservation over a stateless or reduced state domain is required this can be implemented as shown below. QNE QNE QNE ingress interior egress GIMPS stateful GIMPS stateless GIMPS stateful | | | QUERY | | | -------->| QUERY | | +------------------------------>| | | | QUERY | | +--------> | | | RESERVE | | |<-------- | | RESERVE | |<------------------------------+ | RESERVE | RESERVE | |-------------->|-------------->| RESERVE | | | <--------| | | Figure 13: Receiver-initiated reservation with Reduced State Interior Nodes The RESERVE message that is received by the egress QNE of the stateless domain is sent transparantly to the ingress QNE (known as the source of the QUERY message). When the RESERVE message reaches the ingress, the ingress QNE knows it needs to send both a sender-initiated RESERVE over the stateless domain and send a RESERVE Van den Bosch, et al. Expires April 25, 2005 [Page 31] Internet-Draft NSLP for Quality-of-Service signalling October 2004 message further upstream. 4.8 Re-routing scenario The QoS NSLP needs to adapt to route changes in the data path. This assumes the capability to detect rerouting events, perform QoS reservation on the new path and optionally tear down reservations on the old path. When the QoS NSLP is aware of the route change, it needs to set up the reservation on the new path. This is done by incrementing the RSN and sending a RESERVE message. On links that are common to the old and the new path, this RESERVE message is interpreted as a refreshing RESERVE. On new links, it creates the reservation. After the reservation on the new path is set up, the branching node or the merging node may want to tear down the reservation on the old path (faster than what would result from normal soft-state time-out). This functionality is supported by keeping track of the old SII. This specification requests GIMPS design to provide support for an SII. The SII is opaque to the QoS NSLP, i.e. QoS NSLP does not make any assumptions on how this identifier is constructed. When passed over the API, it allows QoS NSLP to indicate that its messages should be sent to the QNE identified by that SII. In case of a receiver-initiated reservation, a QNE can detect a route change by receiving a RESERVE message with a different SII. In case of a sender-initiated reservation, the same information is learned from a RESPONSE message, or from a NOTIFY message sent by the downstream peer. A QNE that has detected the route change via the SII change sends a RESERVE message towards the QNR on the old path (using the old SII) with the TEAR flag set. Note that in case of receiver-initiated reservations, this involves A QNE that is notified of the route change in another way and wants to tear down the old branch needs to send the RESERVE on the new path with an RII object. When it receives the RESPONSE message back, it can check whether its peer has effectively changed and send a RESERVE with the TEAR flag set if it has. Otherwise, teardown is not needed. A QNE that is unable to support an RII or does not receive a RESPONSE needs to rely on soft-state timeout on the old branch. A QNI or a branch node may wish to keep the reservation on the old branch. This could for instance be the case when a mobile node has experienced a mobility event and wishes to keep reservation to its old attachment point in case it moves back there. In that case, it sets the REPLACE flag in the common header to zero. Van den Bosch, et al. Expires April 25, 2005 [Page 32] Internet-Draft NSLP for Quality-of-Service signalling October 2004 4.9 Authorization Model Examples Various authorization models can be used in conjunction with the QoS NSLP. 4.9.1 Authorization for the two party approach The two party approach is conceptually the simplest authorization model. +-------------+ QoS request +--------------+ | Entity |----------------->| Entity | | requesting | | authorizing | | resource |granted / rejected| resource | | |<-----------------| request | +-------------+ +--------------+ ^ ^ +...........................+ financial establishment Figure 14: Two party approach In this example the authorization decision only involves the two entities, or makes use of previous authorisation using an out-of-band mechanism to avoid the need for active participation of an external entity during the NSIS protocol execution. This type of model may be applicable, for example, between two neighbouring networks (inter-domain signalling) where a long-term contract (or other out-of-band mechanisms) exists to manage charging and provides sufficient information to authorize individual requests. 4.9.2 Token based three party approach An alternative approach makes use of authorization tokens, such as those described in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the Open Settlement Protocol [OSP]. The former ('authorization tokens') are used to associate two different signalling protocols (i.e. SIP and NSIS) and their authorization with each other whereas the latter is a form of digital money. As an example, with the authorization token mechanism, some form of authorization is provided by the SIP proxy, which acts as the resource authorizing entity in Figure 15. If the request is authorized, then the SIP signalling returns an authorization token which can be included in the QoS signalling protocol messages to refer to the previous authorization decision. The tokens themselves may take a number of different forms, some of which may require the entity performing the QoS reservation to query external state. Van den Bosch, et al. Expires April 25, 2005 [Page 33] Internet-Draft NSLP for Quality-of-Service signalling October 2004 Authorization Token Request +--------------+ +-------------->| Entity C | financial settlement | | authorizing | <..................+ | | resource | . | +------+ request | . | | +--------------+ . | | . | |Authorization . | |Token . | | . | | . | | . | | QoS request . +-------------+ + Authz. Token +--------------+ . | Entity |----------------->| Entity B | . | requesting | | performing | . | resource |granted / rejected| QoS | <..+ | A |<-----------------| reservation | +-------------+ +--------------+ Figure 15: Token based three party approach For the digital money type of systems (e.g. OSP tokens), the token represents a limited amount of credit. So, new tokens must be sent with later refresh messages once the credit is exhausted. 4.9.3 Generic three party approach Another method is for the node performing the QoS reservation to delegate the authorization decision to a third party, as illustrated in Figure 16. Van den Bosch, et al. Expires April 25, 2005 [Page 34] Internet-Draft NSLP for Quality-of-Service signalling October 2004 +--------------+ | Entity C | | authorizing | | resource | | request | +-----------+--+ ^ | | | QoS | | QoS authz| |authz req.| | res. | | QoS | v +-------------+ request +--+-----------+ | Entity |----------------->| Entity B | | requesting | | performing | | resource |granted / rejected| QoS | | A |<-----------------| reservation | +-------------+ +--------------+ Figure 16: Three party approach Authorization may be performed on a per-request basis, periodically, or on a per-session basis. The authorization request might make use of EAP authentication between entities A and C, and a subsequent protocol exchange between A and B to create a secure channel for further communications. Such a technique gives flexibility in terms of the authentication and key exchange protocols used. A further extension to this model is to allow Entity C to reference a AAA server in the user's home network when making the authorization decision. Van den Bosch, et al. Expires April 25, 2005 [Page 35] Internet-Draft NSLP for Quality-of-Service signalling October 2004 5. QoS NSLP Functional specification 5.1 QoS NSLP Message and Object Formats A QoS NSLP message consists of a common header, followed by a body consisting of a variable number of variable-length, typed "objects". The common header and other objects are encapsulated together in a GIMPS NSLP-Data object. The following subsections define the formats of the common header and each of the QoS NSLP message types. In the message formats, the common header is denoted as COMMON_HEADER. For each QoS NSLP message type, there is a set of rules for the permissible choice of object types. These rules are specified using the Augmented Backus-Naur Form (BNF) specified in RFC 2234 [RFC2234]. The BNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation should create messages with the objects in the order shown here, but accept the objects in any permissible order. 5.1.1 Common header All GIMPS NSLP-Data objects for the QoS NSLP MUST contain this common header as the first 32 bits of the object. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the common header are as follows: Msg Type: 16 bits 1 = RESERVE 2 = QUERY 3 = RESPONSE 4 = NOTIFY Flags: 16 bits The set of appropriate flags depends on the particular message being processed. Any bit not defined as a flag for a particular message MUST be set to zero on sending and MUST be ignored on receiving. Van den Bosch, et al. Expires April 25, 2005 [Page 36] Internet-Draft NSLP for Quality-of-Service signalling October 2004 5.1.2 Message formats 5.1.2.1 RESERVE The format of a RESERVE message is as follows: RESERVE = COMMON_HEADER RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] [ POLICY_DATA ] [ *QSPEC ] The RSN is the only mandatory object and MUST always be present. If any QSPEC objects are present, they MUST occur at the end of the message. There are no other requirements on transmission order, although the above order is recommended. Four flags are defined for use in the common header with the RESERVE message. These are: TEAR (T) - when set, indicates that reservation state and QoS NSLP operation state should be torn down. This is indicated to the RMF. SCOPING (S) - when set, indicates that the message is scoped and should not travel down the entire path but only as far as the next QNE (scope="next hop"). By default, this flag is not set (default scope="whole path"). ACKNOWLEDGE (A) - when set, indicates that an explicit confirmation of the state installation action is REQUIRED. This flag SHOULD be set on transmission by default. REPLACE (R) - when set, indicates that a RESERVE with different Flow Routing Information (FRI) replaces an existing one, so the old one MAY be torn down immediately. This is the default situation. This flag may be unset to indicate a desire from an upstream node to keep an existing reservation on an old branch in place. If the REFRESH_PERIOD is not present, a default value of 30 seconds is assumed. Van den Bosch, et al. Expires April 25, 2005 [Page 37] Internet-Draft NSLP for Quality-of-Service signalling October 2004 If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION_ID of that other session in a BOUND_SESSION_ID object. 5.1.2.2 QUERY The format of a QUERY message is as follows: QUERY = COMMON_HEADER [ RII ][ BOUND_SESSION_ID ] [ POLICY_DATA ] [ *QSPEC ] A QUERY message MUST contain an RII object to match an incoming RESPONSE to the QUERY, unless the QUERY is being used to initiate reverse-path state for a receiver-initiated reservation. A QUERY message MAY contain one or more QSPEC objects and a POLICY_DATA object. The QSPEC object describes what is being queried for and may contain objects that gather information along the data path. The POLICY_DATA object authorizes the requestor of the QUERY message. If any QSPEC objects are present, they MUST occur at the end of the message. There are no other requirements on transmission order, although the above order is recommended. One flag is defined for use in the common header with the QUERY message. This is: SCOPING - when set, indicates that the message is scoped an should not travel down the entire path but only as far as the next QNE (scope="next hop"). By default, this flag is not set (default scope="whole path"). If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION_ID of that other session in a BOUND_SESSION_ID object. 5.1.2.3 RESPONSE The format of a RESPONSE message is as follows: RESPONSE = COMMON_HEADER [ RII / RSN ] ERROR_SPEC [ *QSPEC ] Van den Bosch, et al. Expires April 25, 2005 [Page 38] Internet-Draft NSLP for Quality-of-Service signalling October 2004 A RESPONSE message MUST contain an ERROR_SPEC object which indicates the success of a reservation installation or an error condition. Depending on the value of the ERROR_SPEC, the RESPONSE MAY also contain a QSPEC object. If any QSPEC objects are present, they MUST occur at the end of the message. There are no other requirements on transmission order, although the above order is recommended. One flag is defined for use in the common header with the RESPONSE message. This is: SCOPING - when set, indicates that the message is scoped and should not travel down the entire path but only as far as the next QNE (scope="next hop"). By default, this flag is not set (default scope="whole path"). 5.1.2.4 NOTIFY The format of a NOTIFY message is as follows: NOTIFY = COMMON_HEADER ERROR_SPEC [ QSPEC ] A NOTIFY message MUST contain an ERROR_SPEC object indicating the reason for the notification. Depending on the ERROR_SPEC value, it MAY contain a QSPEC providing additional information. No flags are defined for use with the NOTIFY message. 5.1.3 Object Formats The QoS NSLP uses the Type-Length-Value (TLV) object format defined by GIMPS [I-D.ietf-nsis-ntlp]. Every object consists of one or more 32-bit words with a one-word header. For convenience the standard object header is shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |r|r|r|r| Type |r|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value for the Type field comes from GIMPS object type space. The Length field is given in units of 32 bit words and and measures the Van den Bosch, et al. Expires April 25, 2005 [Page 39] Internet-Draft NSLP for Quality-of-Service signalling October 2004 length of the Value component of the TLV object (i.e. it does not include the standard header). The object diagrams here use '//' to indicate a variable sized field and ':' to indicate a field that is optionally present. A QoS NSLP implementation must recognize objects of the following types: RII, RSN, REFRESH_PERIOD, BOUND_SESSION_ID, ERROR_SPEC, QSPEC and POLICY_DATA. NB: This draft does not currently include the codepoints for the QoS NSLP related object types. To aid those writing experimental early implementations a temporary set of NSIS-related numbers are given at . The object header is followed by the Value field, which varies for different objects. The format of the Value field for currently defined objects is specified below. 5.1.3.1 Request Identification Information (RII) Type: RII Length: Fixed - 1 32-bit word Value: An identifier which must be (probabilistically) unique within the context of a SESSION_ID, and SHOULD be different every time a RESPONSE is desired. Used by a QNE to match back a RESPONSE to a request in a RESERVE or QUERY message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response Identification Information (RII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.3.2 Reservation Sequence Number (RSN) Type: RSN Length: Fixed - 1 32-bit word Value: An incrementing sequence number that indicates the order in which state modifying actions are performed by a QNE. The RSN has local significance only, i.e. between a pair of neighbouring stateful QNEs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reservation Sequence Number (RSN) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Van den Bosch, et al. Expires April 25, 2005 [Page 40] Internet-Draft NSLP for Quality-of-Service signalling October 2004 5.1.3.3 REFRESH_PERIOD Type: REFRESH_PERIOD Length: Fixed - 1 32-bit word Value: The refresh timeout period R used to generate this message; in milliseconds. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Period (R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.3.4 BOUND_SESSION_ID Type: BOUND_SESSION_ID Length: Fixed - 4 32-bit words Value: Specifies the SESSION_ID (as specified in GIMPS [I-D.ietf-nsis-ntlp]) of the session that must be bound to the session associated with the message carrying this object. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.3.5 ERROR_SPEC The error object shares a common format with GIMPS and is specified in the GIMPS [I-D.ietf-nsis-ntlp] specification. Type: ERROR Length: Variable Value: Contains a 1 byte error class and 3 byte error code, an error source identifier and optionally variable length error-specific information. Van den Bosch, et al. Expires April 25, 2005 [Page 41] Internet-Draft NSLP for Quality-of-Service signalling October 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Class | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESI-Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Error Source Identifier // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional error-specific information // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first byte of the error code indicates the severity level. The currently defined severity levels are: o 0x01 - Informational o 0x02 - Success o 0x03 - Protocol Error o 0x04 - Transient Failure o 0x05 - Permanent Failure Within each severity class a number of error values are defined. o Informational: * 0x01000001 - Unknown BOUND_SESSION_ID: the message refers to an unknown SESSION_ID in its BOUND_SESSION_ID object. o Success: * 0x02000001 - State installation succeeded * 0x02000002 - Reservation created: reservation installed on complete path (sent by last node). * 0x02000003 - Reservation accepted: reservation installed at this QNE, but not yet installed on the rest of the path. * 0x02000004 - Reservation created but modified: reservation installed, but bandwidth reserved was not the maximum requested. o Protocol Error: * 0x03000001 - Illegal message type: the type given in the Message Type field of the common header is unknown. * 0x03000002 - Wrong message length: the length given for the message does not match the length of the message data. * 0x03000003 - Bad flags value: an undefined flag or combination of flags was set. * 0x03000004 - Mandatory object missing: an object required in a message of this type was missing. * 0x03000005 - Illegal object present: an object was present which must not be used in a message of this type. * 0x03000006 - Unknown object present: an object of an unknown type was present in the message. * 0x03000007 - Wrong object length: the length given for the object did not match the length of the object data present. * 0x03000008 - Unknown QSPEC type (Unknown QSM): the QSM ID refers to a QSM which is not known by this QNE. Van den Bosch, et al. Expires April 25, 2005 [Page 42] Internet-Draft NSLP for Quality-of-Service signalling October 2004 o Transient Failure: * 0x04000001 - Requested resources not available * 0x04000002 - Insufficient bandwidth available * 0x04000003 - Delay requirement cannot be met * 0x04000004 - Transient QSM-specific error * 0x04000005 - Resources pre-empted * 0x04000006 - No GIMPS reverse-path forwarding state * 0x04000007 - NSLP soft-state expired o Permanent Failure: * 0x05000001 - Authentication failure * 0x05000002 - Unable to agree transport security with peer * 0x05000003 - Internal or system error * 0x05000004 - Resource request denied (authorization failed) * 0x05000005 - Permanent QSM-specific error 5.1.3.6 QSPEC Type: QSPEC Length: Variable Value: This object contains a 4 byte QSM ID and a variable length QSPEC (QoS specification) information, which is QSM specific. Such a QSM can be a standardized one, a private one, or a well-known one. The contents and encoding rules for this object are specified in other documents, prepared by QSPEC template designers. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS Signaling Policy Identifier (QSP ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // QSpec Data // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.3.7 POLICY_DATA POLICY_DATA objects may contain various items to authenticate the user and allow the reservation to be authorised. Some possible contents are given in Appendix A, and some issues are also discussed in Section 3.1.4. 5.2 General Processing Rules Van den Bosch, et al. Expires April 25, 2005 [Page 43] Internet-Draft NSLP for Quality-of-Service signalling October 2004 5.2.1 State Manipulation The processing of a message and its component objects involves manipulating the QoS NSLP and reservation state of a QNE. For each flow, a QNE stores (QSM specific) reservation state which is different for each QSM and QoS NSLP operation state which includes non-persistent state (e.g. the API parameters while a QNE is processing a message) and persistent state which is kept as long as the session is active. The persistent QoS NSLP state is conceptually organised in a table with the following structure. The primary key (index) for the table is the SESSION_ID: SESSION_ID A large identifier provided by GIMPS or set locally. The state information for a given key includes: Flow ID Copied from GIMPS. Several entries are possible in case of mobility events. QSM ID 32 bit identification of the QSM. SII for each upstream and downstream peer The SII is a large identifier (minimum 128 bits) generated by the QoS NSLP and passed over the API. RSN from each upstream peer The RSN is a 32 bit counter. Current own RSN A 32 bit random number. List of RII for outstanding responses with processing information the RII is a 32 bit number. Van den Bosch, et al. Expires April 25, 2005 [Page 44] Internet-Draft NSLP for Quality-of-Service signalling October 2004 State lifetime The state lifetime indicates how long the state that is being signalled for remains valid. BOUND_SESSION_ID The BOUND_SESSION_ID is a 128 bit random number. Adding the state requirements of all these items gives an upper bound on the state to be kept by a QNE. The need to keep state depends on the desired functionality at the NSLP layer. 5.2.2 Message Forwarding QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP does not have the concept of a message being sent along the entire path. Instead, messages are received by a QNE, which may then send another message (which may be identical to the received message, or contain some subset of objects from it) to continue in the same direction (i.e. towards QNI or QNR) as the message received. The decision on whether to generate a message to forward may be affected by the value of the SCOPING flag or by the presence of an RII object. 5.2.3 Standard Message Processing Rules If a mandatory object is missing from a message then the receiving QNE MUST NOT propagate the message any further. It MUST construct an RESPONSE message indicating the error condition and send it back to the peer QNE that sent the message. If a message contains an object of an unrecognised type, then the behaviour depends on the object type value. 5.3 Object Processing 5.3.1 Reservation Sequence Number (RSN) A QNE's own RSN is a sequence number which applies to a particular NSIS signalling session (i.e. with a particular GIMPS SESSION_ID). It MUST be incremented for each new RESERVE message where the reservation for the session changes. Once the RSN has reached its maximum value, the next value it takes is zero. When receiving a RESERVE message a QNE uses the RSN given in the Van den Bosch, et al. Expires April 25, 2005 [Page 45] Internet-Draft NSLP for Quality-of-Service signalling October 2004 message to determine whether the state being requested is different to that already stored. If the RSN is the same as for the current reservation the current state MUST be refreshed. If the RSN is greater than the current stored value, the current reservation MUST be modified appropriately (provided that admission control and policy control succeed), and the stored RSN value updated to that for the new reservation. If the RSN is less than the current value, then it indicates an out-of-order message and the RESERVE message MUST be discarded. If the QNE does not store per-session state (and so does not keep any previous RSN values) then it MAY ignore the value of the RSN. It MUST also copy the same RSN into the RESERVE message (if any) it sends as a consequence of receiving this one. 5.3.2 Request Identification Information (RII) A QNE sending some types of messages may require a response to be sent. It does so by including a Request Identification Information (RII) object. When creating an RII object the sender MUST select the value for the RII such that it is probabilistically unique within the given session. A number of choices are available when implementing this. Possibilities might include using a totally random value, or a node identifier together with a counter. If the value is selected by another QNE then RESPONSE messages may be incorrectly terminated, and not passed back to the node that requested them. When sending a message containing an RII object the sending node MUST remember the value used in the RII to match back any RESPONSE received. It SHOULD use a timer to identify situations where it has taken too long to receive the expected RESPONSE. If the timer expires without receiving a RESPONSE it MAY perform a retransmission. When receiving a message containing an RII object the node MUST send a RESPONSE if either o The SCOPING flag is set to one ('next hop' scope), or o This QNE is the last one on the path for the given session. and the QNE keeps per-session state for the given session. A message contains at most one RII object that is unique within a session and different for each message, in order to allow responses to be matched back to requests (without incorrectly matching at other nodes). Downstream nodes that desire responses may keep track of this RII to identify the RESPONSE when it passes back through them. Van den Bosch, et al. Expires April 25, 2005 [Page 46] Internet-Draft NSLP for Quality-of-Service signalling October 2004 5.3.3 BOUND_SESSION_ID As shown in the examples in Section 4, the QoS NSLP can relate multiple sessions together. It does this by including the SESSION_ID from one session in a BOUND_SESSION_ID object in messages in another session. When receiving a message with a BOUND_SESSION_ID object, a QNE MUST copy the BOUND_SESSION_ID object into all messages it sends for the same session. A QNE that stores per-session state SHOULD store the value of the BOUND_SESSION_ID. The BOUND_SESSION_ID is only indicative in nature. However, a QNE implementation MAY use BOUND_SESSION_ID information to optimize resource allocation, e.g. for bidirectional reservations. When receiving a tearing RESERVE for an aggregate reservation, it MAY use this information to initiate a tearing RESERVE for end-to-end sessions bound to the aggregate. 5.3.4 REFRESH_PERIOD Refresh timer management values are carried by the REFRESH_PERIOD object which has local significance only. At the expiration of a "refresh timeout" period, each QNE independently examines its state and sends a refreshing RESERVE message to the next QNE peer where it is absorbed. This peer-to-peer refreshing (as opposed to the QNI initiating a refresh which travels all the way to the QNR) allows QNEs to choose refresh intervals as appropriate for their environment. For example, it is conceivable that refreshing intervals in the backbone, where reservations are relatively stable, are much larger than in an access network. The "refresh timeout" is calculated within the QNE and is not part of the protocol; however, it must be chosen to be compatible with the reservation lifetime as expressed by the REFRESH_PERIOD, and an assessment of the reliability of message delivery. The details of timer management and timer changes (slew handling and so on) are identical to the ones specified in Section 3.7 of RFC 2205 [RFC2205]. There are two time parameters relevant to each QoS NSLP state in a node: the refresh period R between generation of successive refreshes for the state by the neighbor node, and the local state's lifetime L. Each RESERVE message may contain a REFRESH_PERIOD object specifying the R value that was used to generate this (refresh) message. This R value is then used to determine the value for L when the state is received and stored. The values for R and L may vary from peer to peer. This peer-to-peer refreshing (as opposed to the QNI initiating Van den Bosch, et al. Expires April 25, 2005 [Page 47] Internet-Draft NSLP for Quality-of-Service signalling October 2004 a refresh which travels all the way to the QNR) allows QNEs to choose refresh intervals as appropriate for their environment. For example, it is conceivable that refreshing intervals in the backbone, where reservations are relatively stable, are much larger than in an access network. In more detail: 1. Floyd and Jacobson [_XREF_FJ94] have shown that periodic messages generated by independent network nodes can become synchronized. This can lead to disruption in network services as the periodic messages contend with other network traffic for link and forwarding resources. Since QoS NSLP sends periodic refresh messages, it must avoid message synchronization and ensure that any synchronization that may occur is not stable. For this reason, it is recommended that the the refresh timer should be randomly set to a value in the range [0.5R, 1.5R]. 2. To avoid premature loss of state, L must satisfy L >= (K + 0.5)*1.5*R, where K is a small integer. Then in the worst case, K-1 successive messages may be lost without state being deleted. To compute a lifetime L for a collection of state with different R values R0, R1, ..., replace R by max(Ri). Currently K = 3 is suggested as the default. However, it may be necessary to set a larger K value for hops with high loss rate. K may be set either by manual configuration per interface, or by some adaptive technique that has not yet been specified. 3. Each RESERVE message carries a REFRESH_PERIOD object containing the refresh time R used to generate refreshes. The recipient node uses this R to determine the lifetime L of the stored state created or refreshed by the message. 4. The refresh time R is chosen locally by each node. If the node does not implement local repair of reservations disrupted by route changes, a smaller R speeds up adaptation to routing changes, while increasing the QOS-NSLP overhead. With local repair, a router can be more relaxed about R since the periodic refresh becomes only a backstop robustness mechanism. A node may therefore adjust the effective R dynamically to control the amount of overhead due to refresh messages. The current suggested default for R is 30 seconds. However, the default value Rdef should be configurable per interface. 5. When R is changed dynamically, there is a limit on how fast it may increase. Specifically, the ratio of two successive values R2/R1 must not exceed 1 + Slew.Max. Currently, Slew.Max is 0.30. With K = 3, one packet may be lost without state timeout while R is increasing 30 percent per refresh cycle. 6. To improve robustness, a node may temporarily send refreshes more often than R after a state change (including initial state establishment). Van den Bosch, et al. Expires April 25, 2005 [Page 48] Internet-Draft NSLP for Quality-of-Service signalling October 2004 7. The values of Rdef, K, and Slew.Max used in an implementation should be easily modifiable per interface, as experience may lead to different values. The possibility of dynamically adapting K and/or Slew.Max in response to measured loss rates is for future study. 5.3.5 ERROR_SPEC ERROR_SPEC processing rules are still to be defined in more detail. 5.3.6 QSPEC The contents of the QSPEC depends on the QSM being used. It may be that parts of the QSPEC are standardised across multiple QSMs. This topic is currently under further study. Upon reception, the complete QSPEC is passed to the Resource Management Function (RMF). A QNE that receives a QSPEC stack MUST only look at the top QSPEC in the stack. If this QSPEC is not understood by the RMF, the QNE MUST send an RESPONSE containing an ERROR_SPEC and MUST NOT attempt to recover by inspecting the rest of the stack. Parameters of the QSM that is being signalled for are carried in the QSPEC object. A domain may have local policies regarding QoS model implementation, i.e. it may map incoming traffic to its own locally defined QSMs. The QoS NSLP supports this by allowing QSPEC objects to be stacked. When a domain wants to apply a certain QSM to an incoming per-flow reservation request, each edge of the domain is configured to map the incoming QSPEC object to a local QSPEC object and push that object onto the stack of QSPEC objects (typically immediately following the Common Control Information, i.e. the first QSPEC that is found in the message). A QNE that knows it is the last QNE to understand a local QSPEC object (e.g. by configuration of the egress QNEs of a domain) SHOULD remove the topmost QSPEC object from the stack. It SHOULD update the underlying QSM parameters if needed. A QNE that receives a message with a QSPEC object stack of which the topmost object is not understood MUST NOT forward the message and MUST send an error indication to its upstream neighbour. It MUST NOT attempt local recovery by inspecting the stack for a QSPEC object it understands. Van den Bosch, et al. Expires April 25, 2005 [Page 49] Internet-Draft NSLP for Quality-of-Service signalling October 2004 If the RMF indicates it cannot process the QSPEC, e.g. because the QSM is not supported the QNE sends a RESPONSE with the appropriate ERROR_SPEC. 5.4 Message Processing Rules 5.4.1 RESERVE Messages The RESERVE message is used to manipulate QoS reservation state in QNEs. A RESERVE message may create, refresh, modify or remove such state. The format of a RESERVE message is repeated here for convenience: RESERVE = COMMON_HEADER RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] [ POLICY_DATA ] [ *QSPEC ] RESERVE messages MUST only be sent towards the QNR. A QNE that receives a RESERVE message checks the message format. In case of malformed messages, the QNE sends a RESPONSE message with the appropriate ERROR_SPEC. Before performing any state changing actions a QNE MUST determine whether the request is authorized. It SHOULD exercise its local policy in conjunction with the POLICY_DATA object to do this. When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags. If the TEAR flag is set, the message is a tearing RESERVE which indicates complete QoS NSLP state removal (as opposed to a reservation of zero resources). On receiving such a RESERVE message the QNE MUST inform the RMF that the reservation is no longer required. The QNE SHOULD remove the QoS NSLP state. It MAY signal to GIMPS (over the API) that reverse path state for this reservation is no longer required. If the QNE has reservations which are bound to this session (they contained the SESSION_ID of this session in their BOUND_SESSION_ID object), it MUST send a NOTIFY message for each of these reservations with an appropriate ERROR_SPEC. The QNE MAY elect to send RESERVE messages with the TEAR flag set for these reservations. The default behaviour of a QNE that receives a RESERVE with a SESSION_ID for which it already has state installed but with a different flow ID is to replace the existing reservation (and tear down the reservation on the old branch if the RESERVE is received with a different SII). Van den Bosch, et al. Expires April 25, 2005 [Page 50] Internet-Draft NSLP for Quality-of-Service signalling October 2004 In some cases, this may not be the desired behaviour. In that case, the QNI or a QNE may set the REPLACE flag in the common header to zero to indicate that the new session does not replace the existing one. A QNE that receives a RESERVE with the REPLACE flag set to zero but with the same SII will update the flow ID and indicate REPLACE=0 to the RMF (where it will be used for the resource handling). If the SII is different, this means that the QNE is a merge point. In that case, the REPLACE=0 also indicates that a tearing RESERVE SHOULD NOT be sent on the old branch. When a QNE receives a (refreshing) RESERVE message with an unknown SESSION_ID, it MAY send a NOTIFY message to its upstream peer, indicating the unknown SESSION_ID. This indicates a downstream route change to the upstream peer. The upstream peer SHOULD send a complete RESERVE on the new path (new SII). It identifies the old signalling association (old SII) and MAY start sending complete RESERVE messages for other SESSION_IDs linked to this association. At a QNE, resource handling is performed by the RMF. For sessions with the REPLACE flag set to zero, we assume that the QSP includes directions to deal with resource sharing. This may include, adding the reservations, or taking the maximum of the two or more complex mathematical operations. This resource handling mechanism in the QSM is also applicable to sessions with different SESSION_ID but related through the BOUND_SESSION_ID object. Session replacement is not an issue here, but the QSM may specify whether to let the sessions that are bound together share resources on common links or not. Finally, it is possible that a RESERVE is received with no QSPEC at all. This is the case of a summary refresh. In this case, rather than sending a refreshing RESERVE with the full QSPEC, only the SESSION_ID and the SII are sent to refresh the reservation. Note that this mechanism just reduces the message size (and probably eases processing). One RESERVE per session is still needed. If the REPLACE flag is set, the QNE SHOULD update the reservation state according to the QSPEC contained in the message. It MUST update the lifetime of the reservation. If the REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation state if the SII which is passed by GIMPS over the API is different than the SII that was stored for this reservation. The QNE MAY elect to keep sending refreshing RESERVE messages. If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state installation action. It does so by sending a RESPONSE with an ERROR_SPEC value of 0x02000003, indicating that the reservation is Van den Bosch, et al. Expires April 25, 2005 [Page 51] Internet-Draft NSLP for Quality-of-Service signalling October 2004 installed at the QNE. If the SCOPING flag is set, or if the QNE is the last QNE on the path to the destination, the QNE MUST send a RESPONSE message. When a QNE receives a RESERVE message, its processing may involve sending out another RESERVE message. When sending a RESERVE message, the QNE may insert or remove 'local' QSPEC objects from the top of the stack. If there are one or more QSPECs in the received RESERVE message, the last QSPEC MUST NOT be removed when sending on the RESERVE message. Upon transmission, a QNE SHOULD set the ACKNOWLEDGE flag. It MUST do so if it wishes to use the reduced overhead refresh mechanism described in Section 3.2.3. It MUST NOT send a reduced overhead refresh message (i.e. a RESERVE with a non-incremented RSN and no QSPEC) unless it has received a RESPONSE message for that RESERVE message. If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION_ID of that other session in a BOUND_SESSION_ID object. In case of receiver-initiated reservations, the RESERVE message must follow the same path that has been followed by the QUERY message. Therefore, GIMPS is informed, over the QoS NSLP/GIMPS API, to pass the message upstream, i.e., by setting GIMPS "D" flag, see GIMPS [I-D.ietf-nsis-ntlp]. 5.4.2 QUERY Messages A QUERY message is used to request information about the data path without making a reservation. This functionality can be used to 'probe' the network for path characteristics or for support of certain QoS models. The format of a QUERY message is as follows: QUERY = COMMON_HEADER [ RII ] [ BOUND_SESSION_ID ] [ POLICY_DATA ] [ *QSPEC ] On receiving a QUERY message, a QNE checks whether an RII object is present. If not, the QUERY is an empty QUERY which is used to install reverse path state. In this case, if the QNE is not the QNR, it creates a new QUERY message to send downstream. If the QUERY Van den Bosch, et al. Expires April 25, 2005 [Page 52] Internet-Draft NSLP for Quality-of-Service signalling October 2004 contained a QSPEC, this MUST be passed to the RMF where it MAY be modified by QSM specific QUERY processing. If the QNE is the QNR, the QNE creates a RESERVE message, which contains a QSPEC received from the RMF and which MAY be based on the received QSPEC. If this node was not expecting to perform a receiver-initiated reservation then an error MUST be sent back along the path. If an RII object is present, and if the QNE is the QNR or the SCOPING flag is set, the QNE MUST generate a RESPONSE message and pass it back along the reverse of the path used by the QUERY. When generating a QUERY to send out to pass the query further along the path, the QNE MUST copy the RII object (if present) into the new QUERY message unchanged. A QNE that is also interested in the response to the query keeps track of the RII to identify the RESPONSE when it passes through it. 5.4.3 RESPONSE Messages The RESPONSE message is used to provide information about the result of a previous QoS NSLP message, e.g. confirmation of a reservation or information resulting from a query. The RESPONSE message is impotent, it does not cause any state to be installed or modified. The format of a RESPONSE message is repeated here for convenience: RESPONSE = COMMON_HEADER [ RII / RSN ] ERROR_SPEC [ *QSPEC ] A RESPONSE message MUST be sent where the QNE is the last node to process a RESERVE or QUERY message containing an RII object (based on scoping of the RESERVE or QUERY, or because this is the last node on the path). In this case, the RESPONSE MUST copy the RII object from the RESERVE or QUERY. In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE flag is set or when an error occurs while processing a received message. If the received message contains an RII object, this object MUST be put in the RESPONSE, as described above. If the RESPONSE is sent as a result of the receipt of a RESERVE message without an RII object, then the RSN of the received RESERVE message MUST be copied into the RESPONSE message. On receipt of a RESPONSE message containing an RII object, the QNE MUST attempt to match it to the outstanding response requests for Van den Bosch, et al. Expires April 25, 2005 [Page 53] Internet-Draft NSLP for Quality-of-Service signalling October 2004 that signalling session. If the match succeeds, then the RESPONSE MUST NOT be forwarded further along the path. If the match fails, then the QNE MUST attempt to forward the RESPONSE to the next peer QNE. On receipt of a RESPONSE message containing an RSN object, the QNE MUST compare the RSN to that of the appropriate signalling session. If the match succeeds then the ERROR_SPEC MUST be processed. The RESPONSE message MUST NOT be forwarded further along the path whether or not the match succeeds. 5.4.4 NOTIFY Messages NOTIFY messages are used to convey information to a QNE asynchronously. The format of a NOTIFY message is as follows: NOTIFY = COMMON_HEADER ERROR_SPEC [ QSPEC ] NOTIFY messages are impotent. They do not cause any state to be installed or modified and they do do not directly cause other messages to be sent. NOTIFY messages are sent asynchronously, rather than in response to other messages. They may be sent in either direction (upstream or downstream). Van den Bosch, et al. Expires April 25, 2005 [Page 54] Internet-Draft NSLP for Quality-of-Service signalling October 2004 6. IANA considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the QoS NSLP, in accord