Next Steps in Signaling S. Van den Bosch Internet-Draft Alcatel Expires: August 16, 2004 G. Karagiannis University of Twente/Ericsson A. McDonald Siemens/Roke Manor Research February 16, 2004 NSLP for Quality-of-Service signaling draft-ietf-nsis-qos-nslp-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 August 16, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft describes an NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with the NTLP, 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. Van den Bosch, et al. Expires August 16, 2004 [Page 1] Internet-Draft NSLP for Quality-of-Service signaling February 2004 This version of the draft focuses on the basic protocol structure. It identifies the different message types and describes the basic operation of the protocol to create, refresh, modify and teardown a reservation or to obtain information on the characteristics of the associated data path. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Scope and background . . . . . . . . . . . . . . . . . . . . 5 1.2 Model of operation . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9 3.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 NTLP Interactions . . . . . . . . . . . . . . . . . . . . . 10 3.3 Authentication and authorization . . . . . . . . . . . . . . 10 3.4 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5 Examples of QoS NSLP Operation . . . . . . . . . . . . . . . 11 3.5.1 Simple Resource Reservation . . . . . . . . . . . . . . . . 12 3.5.2 Sending a Query . . . . . . . . . . . . . . . . . . . . . . 13 3.5.3 Use of Local QoS Models . . . . . . . . . . . . . . . . . . 14 3.5.4 Aggregate Reservations . . . . . . . . . . . . . . . . . . . 15 3.5.5 Reduced State or stateless Interior Nodes . . . . . . . . . 16 4. Design decisions . . . . . . . . . . . . . . . . . . . . . . 18 4.1 Message types . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.1 RESERVE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2 QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Control information . . . . . . . . . . . . . . . . . . . . 20 4.2.1 Message sequencing . . . . . . . . . . . . . . . . . . . . . 20 4.2.2 Requesting responses . . . . . . . . . . . . . . . . . . . . 21 4.2.3 Message scoping . . . . . . . . . . . . . . . . . . . . . . 22 4.2.4 State timers . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.5 Session binding . . . . . . . . . . . . . . . . . . . . . . 23 4.3 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.1 Local QoS models . . . . . . . . . . . . . . . . . . . . . . 23 4.3.2 Local control plane properties . . . . . . . . . . . . . . . 24 4.3.3 Aggregate reservations . . . . . . . . . . . . . . . . . . . 25 4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 25 4.5 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.6 Rerouting . . . . . . . . . . . . . . . . . . . . . . . . . 26 Van den Bosch, et al. Expires August 16, 2004 [Page 2] Internet-Draft NSLP for Quality-of-Service signaling February 2004 4.7 State storage . . . . . . . . . . . . . . . . . . . . . . . 28 4.8 Authentication and authorization . . . . . . . . . . . . . . 29 4.8.1 Policy Ignorant Nodes . . . . . . . . . . . . . . . . . . . 29 4.8.2 Policy Data . . . . . . . . . . . . . . . . . . . . . . . . 30 5. QoS-NSLP Functional specification . . . . . . . . . . . . . 31 5.1 QoS-NSLP Message Formats . . . . . . . . . . . . . . . . . . 31 5.1.1 Common header . . . . . . . . . . . . . . . . . . . . . . . 31 5.1.2 Object Formats . . . . . . . . . . . . . . . . . . . . . . . 32 5.1.3 RESERVE Messages . . . . . . . . . . . . . . . . . . . . . . 34 5.1.4 QUERY Messages . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.5 RESPONSE Messages . . . . . . . . . . . . . . . . . . . . . 38 5.1.6 NOTIFY Messages . . . . . . . . . . . . . . . . . . . . . . 40 6. IANA considerations . . . . . . . . . . . . . . . . . . . . 40 7. Requirements for the NSIS Transport Layer Protocol (NTLP) . 42 7.1 Session identification . . . . . . . . . . . . . . . . . . . 42 7.2 Support for bypassing intermediate nodes . . . . . . . . . . 42 7.3 Support for peer change identification . . . . . . . . . . . 42 7.4 Support for stateless operation . . . . . . . . . . . . . . 43 7.5 Last node detection . . . . . . . . . . . . . . . . . . . . 43 7.6 Re-routing detection . . . . . . . . . . . . . . . . . . . . 44 7.7 Priority of signalling messages . . . . . . . . . . . . . . 44 7.8 Knowledge of intermediate QoS NSLP unaware nodes . . . . . . 44 7.9 NSLP Data Size . . . . . . . . . . . . . . . . . . . . . . . 44 7.10 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 45 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45 8.1 Aggregation error handling . . . . . . . . . . . . . . . . . 45 8.2 Region scoping . . . . . . . . . . . . . . . . . . . . . . . 45 8.3 Priority of reservations . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . 46 9.1 Introduction and Threat Overview . . . . . . . . . . . . . . 46 9.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . 47 9.3 QoS Authorization . . . . . . . . . . . . . . . . . . . . . 49 9.3.1 Authorization for the two party approach . . . . . . . . . . 49 9.3.2 Token based three party approach . . . . . . . . . . . . . . 50 9.3.3 Generic three party approach . . . . . . . . . . . . . . . . 52 9.3.4 Computing the authorization decision . . . . . . . . . . . . 54 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 Normative References . . . . . . . . . . . . . . . . . . . . 55 Informative References . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57 A. Object Definitions . . . . . . . . . . . . . . . . . . . . . 58 A.1 RESPONSE_REQUEST Class . . . . . . . . . . . . . . . . . . . 58 A.2 RSN Class . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.3 REFRESH_PERIOD Class . . . . . . . . . . . . . . . . . . . . 59 A.4 SESSION_ID Class . . . . . . . . . . . . . . . . . . . . . . 60 A.5 SCOPING Class . . . . . . . . . . . . . . . . . . . . . . . 60 Van den Bosch, et al. Expires August 16, 2004 [Page 3] Internet-Draft NSLP for Quality-of-Service signaling February 2004 A.6 ERROR_SPEC Class . . . . . . . . . . . . . . . . . . . . . . 61 A.7 POLICY_DATA Class . . . . . . . . . . . . . . . . . . . . . 62 A.7.1 Base Format . . . . . . . . . . . . . . . . . . . . . . . . 62 A.7.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . 63 A.7.3 Policy Elements . . . . . . . . . . . . . . . . . . . . . . 64 A.8 QSPEC Class . . . . . . . . . . . . . . . . . . . . . . . . 66 Intellectual Property and Copyright Statements . . . . . . . 67 Van den Bosch, et al. Expires August 16, 2004 [Page 4] Internet-Draft NSLP for Quality-of-Service signaling February 2004 1. Introduction 1.1 Scope and background This document defines a Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This protocol establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. It is intended to satisfy the QoS-related requirements of [15]. This QoS-NSLP is part of a larger suite of signaling protocols, whose structure is outlined in [3]; this defines a common NSIS Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many aspects of signaling message delivery. The specification of the NTLP is done in another document [4]. The design of QoS-NSLP is conceptually similar to RSVP [6], 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 signaling application gateway would be possible in some circumstances. QoS-NSLP extends the set of reservation mechanisms to meet the requirements of [15], 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 Model', 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 [5]. It should be able to carry information for various QoS models; the specification of Integrated Services for use with RSVP given in [7] could form the basis of one QoS model. 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. It is adapted from the discussion in section 1 of [6]. The model is shown in Figure 1. Van den Bosch, et al. Expires August 16, 2004 [Page 5] Internet-Draft NSLP for Quality-of-Service signaling February 2004 +---------------+ | Local | |Applications or| |Management (e.g| |for aggregates)| +---------------+ ^ ^ V V +----------+ +----------+ +---------+ | QoS-NSLP | | Resource | | Policy | |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control | +----------+ +----------+ +---------+ . ^ | * ^ | V . * ^ +----------+ * ^ | NTLP | * ^ |Processing| * V +----------+ * V | | * V ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ . . * V | | * ............................. . . * . Traffic Control . | | * . +---------+. . . * . |Admission|. | | * . | Control |. +----------+ +------------+ . +---------+. <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | Packet | | Interface | .+----------+ +---------+. ===>|Processing|====| Selection |===.| Packet |====| Packet |.==> | | |(Forwarding)| .|Classifier| Scheduler|. +----------+ +------------+ .+----------+ +---------+. ............................. <.-.-> = signaling flow =====> = data flow (sender --> receiver) <<<>>> = control and configuration operations ****** = routing table manipulation 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. Van den Bosch, et al. Expires August 16, 2004 [Page 6] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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). 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 the NTLP. Only messages related to QoS are passed to the QoS-NSLP. The NTLP 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. 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 [16] and [17]. More generally, the processing of policy and resource management functions 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. 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; we refer to this as a QoS model. Our assumption is that the QoS-NSLP is independent of the QoS Van den Bosch, et al. Expires August 16, 2004 [Page 7] Internet-Draft NSLP for Quality-of-Service signaling February 2004 model, that is, QoS parameters (e.g. IntServ service elements) are interpreted only by the resource management and associated functions, and are opaque to the QoS-NSLP itself. QoS Models are discussed further in Section 3.1. 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 the NTLP module. Note that while Figure 1 shows a unidirectional data flow, the signaling messages can pass in both directions through the node, depending on the particular message and orientation of the reservation. 2. Terminology The terminology defined in [3] 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. QNR: the last node in the sequence of QNEs that receives a reservation request. 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. Van den Bosch, et al. Expires August 16, 2004 [Page 8] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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 | +--------+ | | | | | | +------+ +------+ +------+ =====================> <===================== Signaling Flow 3. Protocol Overview The QoS NSLP uses four message types: RESERVE, QUERY, RESPONSE and NOTIFY. These contain three types of objects: Control Information (CI), QSpecs, and Policy objects. The set of objects permissible depends on the message type. Messages are passed to the NTLP to be delivered to neighbouring NSIS nodes. Similarly, QoS NSLP data from NTLP messages is passed to the QoS NSLP component for processing. Additional meta-data (e.g. session identifier, NSLP identifier) can also be sent in both directions. The QoS NSLP separates the actual description of resources from the QoS signalling protocol used to transport them. It uses interchangeable QoS Models that allow the resource specification to be performed in various ways, and to provide different processing models (including reserve/commit models, measurement based models, etc). Control information objects carry general information for the QoS NSLP processing, such as sequence numbers or whether a response is required. QSpec objects describe the actual resources that are required and are specific to the QoS Model being used. Besides any resource description they may also contain QoS Model specific control information used by the QoS Model's processing. The Policy objects contain data used to authorise the reservation of resources. Van den Bosch, et al. Expires August 16, 2004 [Page 9] Internet-Draft NSLP for Quality-of-Service signaling February 2004 3.1 QoS Models A QoS model is a defined mechanism for achieving QoS as a whole. The specification of a QoS model 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 QoS model goes beyond the QoS-NSLP protocol level in that it could also describe underlying assumptions, conditions and/or specific provisioning mechanisms appropriate for it. A QoS model provides a specific set of parameters to be carried in the QSpec, or restricts the values these parameters can take. Integrated Services [5], Differentiated Services [9] and RMD [22] are all examples that could provide the basis of an NSIS QoS model. There is no restriction on the number of QoS models. QoS models 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 QoS model specification: [18], [19] and [20]. This specification will not attempt to select between the moppling number of possible QoS models. The QSpec contains a set of parameters and values describing the requested resources. It is opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and AdSpec specified in [6][7]. At each QNE, its content is interpreted by the resource management function for the purposes of policy control and traffic control (including admission control and configuration of the packet classifier and scheduler). 3.2 NTLP Interactions The QoS NSLP uses the NTLP for delivery of all its messages. Messages are normally passed from the NSLP to the NTLP via an API, which also specifies additional information, including an identifier for the signaling application (e.g. 'QoS-NSLP'), the flow/session identifier, and an indication of the intended direction - towards data sender or receiver. On reception, the NTLP provides the same information to the QoS-NSLP. 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 NTLP (as described in the requirement given in Section 7.10). 3.3 Authentication and authorization The QoS signaling protocol needs to exchange information which is subsequently used as input to the AAA infrastructure. The response Van den Bosch, et al. Expires August 16, 2004 [Page 10] Internet-Draft NSLP for Quality-of-Service signaling February 2004 from the AAA infrastructure must also returned and processed by the respective entities. +-------------+ | Entity | | authorizing | | resource | | request | +-----+-------+ | | /-\----+-----/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +-------------+ QoS signaling +---+--+ | Entity |<=================>| |<=========> | requesting | Data Flow | QNE | | resource |-------------------|------|----------> +-------------+ +------+ 3.4 Aggregation 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 facilities to provide similar aggregation facilities to [11]. However, the aggregation scenarios supported are wider than that proposed there. 3.5 Examples of QoS NSLP Operation The QoS NSLP can be used in a number 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. Van den Bosch, et al. Expires August 16, 2004 [Page 11] Internet-Draft NSLP for Quality-of-Service signaling February 2004 3.5.1 Simple Resource Reservation NI NF NF NR | | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | | | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | | | | | | | | | Figure 4: Basic Sender Initiated Reservation To make a new reservation, the QNI constructs a RESERVE message containing a QSpec object, from its chosen QoS model, which describes the required QoS parameters. The RESERVE message is passed to the NTLP which transports it to the next QoS NSLP node. 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 QoS Model 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 the NTLP, 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 NTLP functionality to determine that there are no more QNEs between this node and the data flow destination. Any node may include a request for a RESPONSE in its RESERVE messages. One such use is to confirm the installation of state, which allows the use of summary refreshes that later refer to that state. The RESPONSE is forwarded peer-to-peer along the reverse of the path that the RESERVE message took (using NTLP path state), and so is seen Van den Bosch, et al. Expires August 16, 2004 [Page 12] Internet-Draft NSLP for Quality-of-Service signaling February 2004 by all the QNEs on the reverse-path. It is only forwarded as far as the node which requested the RESPONSE. A RESPONSE message can also indicate an error when, for example, a reservation has failed to be installed. The reservation can subsquently 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 QoS model 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 [10]. 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. 3.5.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 QoS model specific objects containing the actual query to be performed at QoS NSLP nodes 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 the NTLP to forward it along the path. The NTLP may use datagram mode or connection mode for forwarding the QUERY message. 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 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 the NTLP 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 is generated. Into this is copied various objects from the received QUERY message. It is then passed to the NTLP to be forwarded peer-to-peer back along the path. This makes use of the neighbour state retained by the NTLP, and may use datagram or connection mode. Van den Bosch, et al. Expires August 16, 2004 [Page 13] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Each QNE receiving the RESPONSE message should inspect the ResponseRequest 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 the NTLP to be forwarded back down the path. 3.5.3 Use of Local QoS Models In some cases it may be required to use a different QoS Model 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). +--------+ +----+----+ +--------+ +----+----+ +--------+ | QM1 | |QM1 | QM2| | QM2 | |QM2 | QM1| | QM1 | +--------+ +----+----+ +--------+ +----+----+ +--------+ |QoS-NSLP| |QoS-NSLP | |QoS-NSLP| |QoS-NSLP | |QoS-NSLP| +--------+ +---------+ +--------+ +---------+ +--------+ | NTLP |===| NTLP |===| NTLP |===| NTLP |===| NTLP | +--------+ +---------+ +--------+ +---------+ +--------+ <-------> <--------------------> <-------> RESV{QSpec1} RESV{QSpec1,QSpec2} RESV{QSpec1} Figure 5: 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 QoS Model needs to be used. At the edge of this 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 the second QoS model. The RESERVE message to be sent out is constructed mostly as usual but with a second QSpec object added, which becomes the 'current' one. When this RESERVE message is received at the next node 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. Van den Bosch, et al. Expires August 16, 2004 [Page 14] Internet-Draft NSLP for Quality-of-Service signaling February 2004 3.5.4 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. NI NF NF/NI' NF' NR'/NF NR aggregator deaggregator | | | | | | | RESERVE | | | | | +--------->| | | | | | | RESERVE | | | | | +--------->| | | | | | | RESERVE | | | | | +-------------------->| | | | | RESERVE' | | | | | +=========>| RESERVE' | | | | | +=========>| RESERVE | | | | | +--------->| | | | | RESPONSE'| | | | | RESPONSE'|<=========+ | | | |<=========+ | | | | | | | RESPONSE | | | | | RESPONSE |<---------+ | | |<--------------------+ | | | RESPONSE | | | | | |<---------+ | | | | RESPONSE | | | | | |<---------+ | | | | | | | | | | | | | | | | Figure 6: Sender Initiated Reservation with Aggregation An end-to-end per-flow reservation is initiated as normal (with messages shown in Figure 6 as "RESERVE"). At the aggregator a reservation for the aggregated flow is initiated (shown in Figure 6 as "RESERVE'"). This may use the same QoS model as the end-to-end reservation but has a flow identifier for the aggregated flow (e.g. tunnel) instead of for the individual flows. Markings are used so that intermediate routers do not need to inspect the individual flow reservations. This might be done by creating an NTLP connection mode association between the aggregator and deaggregator for the end-to-end reservation. Van den Bosch, et al. Expires August 16, 2004 [Page 15] Internet-Draft NSLP for Quality-of-Service signaling February 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. For example, this is necessary so that the size of the aggregate reservation can be reduced when the end-to-end reservation is removed. 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. 3.5.5 Reduced State or stateless Interior Nodes This example uses a different QoS model within a domain, in conjunction with NTLP and NSLP functionality which allows the interior nodes to avoid storing NTLP and QoS NSLP state. As a result the interior nodes only store the QoS model specific reservation state, or even no state at all. This allows the QoS model 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 reservation state is needed (or created). The key difference between this example and the use of different QoS Models in Section 3.5.3 is that the transport characteristics for the 'local' reservation can be different from that of the end-to-end reservation, i.e. the NTLP 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 August 16, 2004 [Page 16] Internet-Draft NSLP for Quality-of-Service signaling February 2004 NF NF NF NF ingress interior interior egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | | RESERVE | | | +--------> | | | | RESPONSE | | | |<-------- | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | Figure 8: 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 the NTLP 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 using facilities provided by the NTLP to bypass the stateless or reduced-state nodes. After the initial discovery phase using datagram mode, connection 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 QoS model suitable for a reduced state or stateless form of operation (such as the RMD per hop reservation). When processed by interior (stateless) nodes the QoS NSLP processing excercises its options to not keep state wherever possible, so that no QoS NSLP state is stored. Some state, e.g. per class, for the QoS model related data may be held at these interior nodes. The QoS NSLP also requests that the NTLP use different transport characteristics (i.e. sending of messages in datagram mode, and not retaining optional path state). Nodes, such as those in the interior of the stateless or reduced-state domain, that do not retain reservation state (and so Van den Bosch, et al. Expires August 16, 2004 [Page 17] Internet-Draft NSLP for Quality-of-Service signaling February 2004 cannot use summary refreshes) cannot send back RESPONSE messages. 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 NTLP neighbour relations are not maintained in the reduced-state region, only sender initiated signalling can be supported. If a bi-directional reservation is required then the interior QoS model must provide an object that requests the egress node to generate a sender initiated session in the reverse direction. 4. Design decisions 4.1 Message types The QoS-NSLP specifies four message types: RESERVE, QUERY, RESPONSE and NOTIFY. The fundamental properties of each message determine how it is analyzed from the perspective of re-ordering, loss, end-to-end reliability and so on. It is important for applications to know whether NSLP messages can be repeated, discarded or merged and so on (e.g. for edge mobility support, rerouting, etc). Indeed, the ordering of messages that do not manipulate state at QNEs matters little, whereas the way that messages that manipulate state are interleaved matters very much. Therefore NSLP is designed such that the message type identifies whether a message is manipulating state (in which case it is idempotent) or not (it is impotent). 4.1.1 RESERVE The RESERVE message is the only message that manipulates QoS reservation state. It is used to create, refresh, modify and remove such state. The common message header contains a TEAR flag that indicates complete QoS NSLP state removal (as opposed to a reservation of zero resources). The TEAR flag indicates to the NTLP that the corresponding NTLP (reverse) state is not required. The NTLP the autonomously decides whether to keep such state or not. The RESERVE message opaquely transports one or more QSPEC objects, describing the desired service level and a POLICY_DATA object, authorizing the requestor of the service. It carries the lifetime of the reservation in the Common Control Information. Van den Bosch, et al. Expires August 16, 2004 [Page 18] Internet-Draft NSLP for Quality-of-Service signaling February 2004 RESERVE messages are sent peer-to-peer. This means that a QNE considers its adjacent upstream or downstream peer to be the source of the RESERVE message. The RESERVE message is idempotent; the resultant effect is the same whether a message is received once or many times. In addition, the ordering of RESERVE messages matters - an old RESERVE message should not replace a newer one. Both of these features are required for protocol robustness - messages may be re-ordered on route (e.g. because of mobility, or at intermediate NTLP nodes) or spuriously retransmitted. Message re-ordering is supported by the inclusion of the Reservation Sequence Number (RSN) in the RESERVE message. The sender of a RESERVE message may want to receive confirmation of successful state installation from a downstream node. Therefore, a RESERVE message optionally contains a RESPONSE_REQUEST object (Section 4.2.2). 4.1.2 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 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, nor does it cause state to be installed in nodes other than the one that generated the QUERY. A QUERY message contains 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. A QUERY message may be scoped if a RESPONSE message from some other node than the QNR is desired. A QUERY message must contain a RESPONSE_REQUEST object (Section 4.2.2), the contents of which allow matching back RESPONSE messages to the QUERY request. The RESPONSE_REQUEST object is transported unchanged along the data path and may be used to scope the RESPONSE to a QUERY message (Section 4.2.3). 4.1.3 RESPONSE The REPONSE 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 Van den Bosch, et al. Expires August 16, 2004 [Page 19] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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. For this purpose, the RESPONSE message carries one or more QSPEC objects. The RESPONSE message is impotent, it does not cause any state to be installed or modified. The forwarding of the RESPONSE message along the path does not necessarily imply the existence of NTLP reverse-path state at every node. For example, the NTLP may have a mechanism to pass a message directly from the egress to the ingress of a region of QNEs that do not store per-flow reverse-path state. 4.1.4 NOTIFY NOTIFY messages are used to convey information to a QNE. NOTIFY messages are impotent (they do not cause a change in state directly). They may carry one or more QSPEC objects. An example use of NOTIFY would be to indicate when a reservation has been pre-empted. NOTIFY messages differ from RESPONSE messages in that they need not refer to any particular state or previously received message. They are sent asynchronously. The NOTIFY message itself does not trigger or mandate any action in the receiving QNE. The information conveyed by a NOTIFY message is typically related to error conditions. One example would be notification to an upstream peer about state being torn down. 4.2 Control information Control information conveys information on how specific messages should be handled by a QNE, e.g. sequencing of messages. This may include some mechanisms that are useful for many QoS models (Common Control Information) and some that are for a particular QoS model only (QoS-model specific Control Information). QoS-model specific Control Information is specified together with a QoS model. 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. 4.2.1 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 Van den Bosch, et al. Expires August 16, 2004 [Page 20] Internet-Draft NSLP for Quality-of-Service signaling February 2004 will be stored at a QNE. Therefore, a QNE may need to detect re-ordered or duplicated RESERVE messages. Detection of RESERVE message re-ordering or duplication is supported by the Reservation Sequence Number (RSN). The RSN is a counter, locally chosen to be unique (on a hop-by-hop basis) within a session. 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, this means that we can make the Reservation Sequence Number unique just between a pair of neighboring stateful QNEs. By managing the sequence numbers in this manner, the source of the RESERVE does not need to determine how the next NSLP node will process the message. The RSN refers to a particular instance of the RESERVE state. This allows explicit acknowledgment of state installation actions (by including the RSN in a RESPONSE). It also allows 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, ...). Note that 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 RESPONSE_REQUEST to decide whether it wants to accept summary refreshes and provide this explicit acknowledgment. 4.2.2 Requesting responses Some QNEs may require explicit responses to messages they send. A QNE which sends a QUERY message (Section 4.1), for instance, will require a response with the requested information to be sent to it. A QNE which sends a RESERVE message may want explicit confirmation that the requested reservation state was installed. A QNE that desires an explicit response includes a RESPONSE_REQUEST object in its message. RESPONSE_REQUEST objects are used in RESERVE and QUERY messages. The RESPONSE_REQUEST object may be used in combination with message scoping (Section 4.2.3) to influence which QNE will respond. A message contains at most one RESPONSE_REQUEST object. The RESPONSE_REQUEST object contains Request Identification Information (RII) that is unique within a session and different for each message, Van den Bosch, et al. Expires August 16, 2004 [Page 21] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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. A message containing a RESPONSE_REQUEST object causes a RESPONSE message to be sent back. The RESPONSE message contains the original RESPONSE_REQUEST object and may be scoped, e.g. using the RII (Section 4.2.3), to influence which (upstream) QNEs will receive the RESPONSE. 4.2.3 Message scoping For some messages, QNEs may want to restrict message propagation. For a RESERVE message, this may be the case when state installation is required on part of the path towards the destination only. For a QUERY message, it allows limiting the nodes that can respond to the QUERY. For a RESPONSE message, it allows limiting the nodes that receive the RESPONSE. Message scoping is supported by a SCOPING object. Different scopes are supported. By default, no SCOPING object is present which indicates that the scope is either "whole path" or limited by configuration (and therefore not signalled). Other supported scopes are "single hop" and "back to me". The latter is supported by copying the RII from the RESPONSE_REQUEST object into the SCOPING object that is put in the RESPONSE message, so that its forwarding can be terminated by the node that requested the RESPONSE. It is currently an open issue whether a "region" should be supported as a separate scope or whether its application is sufficiently supported by configuration and/or aggregation. 4.2.4 State timers 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 seconds 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. The REFRESH_PERIOD 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 Van den Bosch, et al. Expires August 16, 2004 [Page 22] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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 given in Section 5. 4.2.5 Session binding Some QNEs may need to have knowledge of session binding. With session binding we mean that a relation exists between signalled sessions with potentially different SESSION_IDs and/or flow IDs. The SESSION_ID is defined in [4] This situation can occur in case of layering or aggregation where multiple reservations are aggregated together (and the flow ID changes) or when some local properties (e.g. connection mode) for the session change. Layering or aggregation may cause loss of information. If the edge QNEs of the aggregation domain want to maintain some end-to-end properties, they may establish a peering relation by sending the end-to-end message transparantly over the domain. 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, a session (e.g., end to end session), may contain a BOUND_SESSION_ID (the SESSION_ID of another session (e.g., the aggregate one) in addition to its own SESSION_ID to indicate session binding. This BOUND_SESSION_ID is called the session binding object. 4.3 Layering The 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. datagram mode instead of connection mode). They may also occur when several per-flow reservations are locally combined into an aggregate reservation. 4.3.1 Local QoS models Parameters of the QoS model 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 QoS models. The QoS NSLP supports this by allowing Van den Bosch, et al. Expires August 16, 2004 [Page 23] Internet-Draft NSLP for Quality-of-Service signaling February 2004 QSPEC objects to be stacked. When a domain wants to apply a certain QoS model 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 QoS model to apply for the reservation. 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. 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 QoS model parameters if needed. A QNE that receives a message with a QSPEC object stack of which the topmost object is not understood SHOULD send an error indication to its upstream neighbour. It is currently an open issue whether this QNE MAY search the stack for a QSPEC object it understands to recover from this situation. It is also an open issue if such a message can be forwarded and if and how the QSPEC object stack should be updated. 4.3.2 Local control plane properties The way signalling messages are handled is mainly determined by the parameters that are sent over the NTLP-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 datagram mode locally in the domain while still keeping e2e 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. The local session and the end-to-end session are bound at the egress QNE by means of the BOUND_SESSION_ID object. One approach could be that the end-to-end session carries the SESSION_ID of the local Van den Bosch, et al. Expires August 16, 2004 [Page 24] Internet-Draft NSLP for Quality-of-Service signaling February 2004 session in its session binding object. Another approach could be that the local session carries the SESSION_ID of the end-to-end session in its BOUND_SESSION_ID object. This allows the QNE that performs session binding to maintain end-to-end connection mode. 4.3.3 Aggregate reservations For scalability reasons, a domain MAY want to combine two or more end-to-end reservations into a single local aggregate reservation. The domain over which the aggregation is done is limited by configuration. The essential difference with the layering approaches described in Section 4.3.1 and Section 4.3.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 4.3.2 and to the RSVP aggregation solution (reference to 3175). In addition to the different FlowID, the aggregate session may specify a local QoS model and local control plane parameters as explained above. The aggregate reservation may or may not change source and destination IP addresses, i.e. either the end-to-end adresses may be used (if possible) or the IP address of ingress and egress of the domain may be used as source and destination IP address. In some cases, the latter option may cause data plane divergence between both sessions. RSVP solves this by using tunnelling between the edges of the domain. In any case, session binding and a solution for intermediate node bypass (as explained before) are required in this case as well. 4.4 Extensibility The QoS NSLP specification foresees future specification of new error codes and new Common Control Information objects. Specification of new messages is not foreseen but not explicitly precluded. Specification of new error codes and Common Control Information objects is subject to IANA approval and assignment of ClassNum and CType. ClassNum and CType of currently existing objects and error codes are described in Section 6. New Common Control Information objects need to specify whether they are mandatory or optional to implement. Mandatory CCI that is not understood by a QNE needs to generate an error. Optional CCI that is not understood by a QNE needs to be passed transparantly. Van den Bosch, et al. Expires August 16, 2004 [Page 25] Internet-Draft NSLP for Quality-of-Service signaling February 2004 The QoS NSLP specification allows future QoS model specific extensions, including the definition of new QoS models, the specification of new objects for existing QoS models, the specification of new processing rules for new or existing objects and the specification of new QoS model specific error codes. Different types of QoS models are foreseen: standardized QoS models, well-known QoS models and QoS models for private use. We assume the IANA registry of QoS models to distinguish between those. Apart from the QoS model ID, all QoS model specific extensions are opaque to the QoS NSLP (and have no impact on its IANA considerations section). 4.5 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 the GIMPS or QoS NSLP processing is the congested part or scarce resource. This specification requests the NTLP design to foresee a mechanism to support a number of levels of message priority that can be requested over the NSLP-NTLP API. Priority of certain reservations over others may be required when QoS resources are oversubscribed. In that case, existing reservations may be preempted in other 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 resource 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 QoS model specific issue and therefore outside the scope of this specification. However, the concepts of setup and holding priority are widely accepted and we expect the specification of a Priority object in the QSPEC template to be useful for a wide range of QoS models. 4.6 Rerouting The QoS NSLP needs to adapt to route changes in the data path. This assumes the capability to detect rerouting events, perform QoS Van den Bosch, et al. Expires August 16, 2004 [Page 26] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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 NTLP implementations may interact with local routing module to receive quick notification of route changes. This is largely implementation-specific and outside of the scope of NSIS. Second, route changes may be detected at the NTLP layer. This specification requests the NTLP 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 [6]. 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 automatically happens when a refreshing RESERVE message arrives at the QNE where the old and the new path diverge. 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 the NTLP peering relations (e.g. by TTL counting the number of NTLP hops between NSLP peers or the observing changes in the outgoing interface towards the NTLP peer). These mechanisms 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 sending a RESERVE message with RSN+2. 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 the NTLP 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. Then, a RESERVE message with the TEAR flag set (tearing RESERVE) and RSN+1 can be sent over the old branch of the path. Setting the RSN+1 ensures that the reservation will not be torn down if the neighbouring QNE has not, in fact, changed. Van den Bosch, et al. Expires August 16, 2004 [Page 27] Internet-Draft NSLP for Quality-of-Service signaling February 2004 4.7 State storage For each flow, the QoS NSLP stores QoS reservation state. This state includes QoS model specific state which is different for each QoS model 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 the NTLP. The state information for a given key includes: Flow ID Copied from the NTLP. Several entries are possible in case of mobility events. QoS model ID 8 bit identification of the QoS model. SII for each upstream and downstream peer The SII is a 128 bit identifier generated by the NTLP 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. State lifetime Van den Bosch, et al. Expires August 16, 2004 [Page 28] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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. 4.8 Authentication and authorization QoS NSLP requests allow particular user(s) to obtain preferential access to network resources. To prevent abuse, some form of an access control (or 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. 4.8.1 Policy Ignorant Nodes It is generally assumed that policy enforcement is likely to concentrate on border nodes between autonomous systems. Figure 9 below illustrates a simple autonomous domain with: o two boundary nodes (A, C), which represent QNEs authorized by AAA entities. o A core node (B) represents an Policy Ignorant QN (PIN) with capabilities limited to default admission control handling. Van den Bosch, et al. Expires August 16, 2004 [Page 29] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Authorizing Entity 1 Authorizing Entity 2 | | | | +---+ +---+ +---+ | A +---------+ B +---------+ C | +---+ +---+ +---+ QN1 PIN QN2 Figure 9: Autonomous Domain scenario Here, policy objects transmitted across the domain traverse an intermediate PIN node (B) that is allowed to process QoS NSLP message but considered non-trusted for handling policy information. 4.8.2 Policy Data The input to policy control is referred to as "Policy data", which QoS NSLP carries in the Policy 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 NSIS, which simply passes it to policy control when required. The policy data is independent from the QoS model 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 August 16, 2004 [Page 30] Internet-Draft NSLP for Quality-of-Service signaling February 2004 5. QoS-NSLP Functional specification 5.1 QoS-NSLP Message Formats An QoS-NSLP message consists of a common header, followed by a body consisting of a variable number of variable-length, typed "objects". The following subsections define the formats of the common header, the standard object header, and each of the QoS-NSLP message types. For each QoS-NSLP message type, there is a set of rules for the permissible choice of object types. These rules are specified using Backus-Naur Form (BNF) augmented (see [2]). with square brackets surrounding optional sub-sequences. 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 0 1 +---------------------------+---------------------------+ | Msg Type | Flags | +---------------------------+---------------------------+ The fields in the common header are as follows: Msg Type: 8 bits 1 = RESERVE 2 = QUERY 3 = RESPONSE 4 = NOTIFY Flags: 8 bits 1 = TEAR flag 2 = BIDIRECTIONAL flag Van den Bosch, et al. Expires August 16, 2004 [Page 31] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Other flags have to be defined. 5.1.2 Object Formats Every object consists of one or more 32-bit words with a one-word header, with the following format: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ An object header has the following fields: Length: A 16-bit field containing the total object length in bytes. Must always be a multiple of 4, and at least 4. Class-Num: Identifies the object class; values of this field are defined in Appendix A. Each object class has a name, which is always capitalized in this document. An QoS-NSLP implementation must recognize the following classes: RESPONSE_REQUEST: Contains the request for the generation of a response message and the Request Identification Information (RII). RSN: The Reservation Sequence Number (RSN) contains 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. RSN is a common control information object. Van den Bosch, et al. Expires August 16, 2004 [Page 32] Internet-Draft NSLP for Quality-of-Service signaling February 2004 REFRESH_PERIOD Contains the value for the refresh period R used by the creator of the message. Required in every RESERVE message. REFRESH_PERIOD is a common control information object. SESSION_ID It represents the SESSION_ID as specified in [3] of the session that must be bound to the session associated to the message carrying this object. SCOPING contains information that limits the scope of the message carrying this object. When no SCOPING object is available in a message it means that its scoping is either the whole path or it is defined by configuration. SCOPING is a common control information object. ERROR_SPEC Contains an error code and can be carried by a Response or a NOTIFY message. ERROR_SPEC is a common control information object. POLICY_DATA Carries authentication, authorization and accounting information. QSPEC Carries the information that is QoS model specific. This information consists of the QoS model specific control information and the QoS specification parameters. C-Type: Object type, unique within Class-Num. Values are defined in Appendix A. The maximum object content length is 65528 bytes. The Class- Num and C-Type fields may be used together as a 16-bit number to define a unique type for each object. The high-order two bits of the Class-Num are used to determine what Van den Bosch, et al. Expires August 16, 2004 [Page 33] Internet-Draft NSLP for Quality-of-Service signaling February 2004 action a node should take if it does not recognize the Class-Num of an object; 5.1.3 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 as follows: RESERVE = COMMON_HEADER RSN [ SCOPING ] [ RESPONSE_REQUEST ] REFRESH_PERIOD [ BOUND_SESSION_ID ] POLICY_DATA QSPEC [ *QSpec ] The QSPEC object(s) must occur at the end of the message. There are no other requirements on transmission order, although the above order is recommended. The SESSION_ID object must be included in the RESERVE message only if the session associated to this message has to be bound to another session. The content of the SESSION_ID object represents the SESSION_ID of the session that must be bound to the session associated to the RESERVE message carrying this object. The binding of these two sessions is only possible in stateful QNEs. The RESERVE message opaquely must transport a QSPEC object, describing the desired service level and a POLICY_DATA object, authorizing the requestor of the service. Based on configured local policy, a node may ignore the content of the POLICY_DATA object. Refresh timer management values are carried by the TIMER_VALUES object. The details of timer management and timer changes (slew handling and so on) are identical to the ones specified in Section 3.7 of [6]. 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 Van den Bosch, et al. Expires August 16, 2004 [Page 34] Internet-Draft NSLP for Quality-of-Service signaling February 2004 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 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 [25] 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. Van den Bosch, et al. Expires August 16, 2004 [Page 35] Internet-Draft NSLP for Quality-of-Service signaling February 2004 6. To improve robustness, a node may temporarily send refreshes more often than R after a state change (including initial state establishment). 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. Each node may insert a local QSPEC object provided it has a way of scoping this information (e.g. at the boundary of a domain or by using the SCOPING object). In some cases, a QNE needs to be able to distinguish between newly created, modified state or refreshed state based on the RESERVE message alone (not in combination with state information obtained from previous messages). Therefore, one or more additional flags that provide this differentiation may be needed. The specifictaion of these flags are QoS model specific. Therefore, the contents and encoding rules for this object are given in those QoS model specifications. In order to clearly distinguish between a RESERVE message that sets the reserved resources to zero and a RESERVE message that tears down QoS-NSLP state completely, a TEAR flag is foreseen that is carried in the common header. Note that the potential initiation of (reverse path) state removal at the NTLP is a separate issue. This will be signaled over the API between NTLP and QoS-NSLP. RESERVE messages are sent peer-to-peer. This means that a QNE considers its adjacent upstream or downstream peer to be the source of the RESERVE message. Note that two nodes that are adjacent at the QoS-NSLP layer may in fact be separated by several NTLP hops. A QoS- NSLP node may want to be able to detect changes in its QoS-NSLP peers, or send a message to an explicitly identified node, e.g. for tearing down a reservation on an old path. This functionality can be provided by keeping track of a Source Identification Information (SII) object that is similar in nature to the RSVP_HOP object described in [6]. We assume such an SII (section 7.2) to be available as a service from the NTLP. The RESERVE message is idempotent; the resultant effect is the same whether a message is received once or many times. In addition, the ordering of RESERVE messages matters - an old RESERVE message does not replace a newer one. Both of these features are required for protocol robustness - messages may be re-ordered on route (e.g. because of mobility, or at intermediate NTLP nodes) or spuriously retransmitted. Van den Bosch, et al. Expires August 16, 2004 [Page 36] Internet-Draft NSLP for Quality-of-Service signaling February 2004 In order to tackle these issues, the RESERVE message contains a Reservation Sequence Number (RSN) object. An RSN is 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 QNEs. Attempting to make an identifier that was unique in the context of a session identifier 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, this means that we can make the Reservation Sequence Number unique just between a pair of neighboring stateful QNEs. Note that an alternative might be for the NTLP to guarantee in-order delivery between the NSLP peers. A Flow identifier groups together state items for a single flow. The RSN is one of these state items, and is used to identify reordering of messages and to allow the use of partial refresh messages. The state items for a number of flows can be linked together and identified as part of a single reservation using a Session Identifier. The identifiers play complementary roles in the management of QoS NSLP state. The flow identifier is carried by the NTLP and it is augmented by additional flow identifying information in the QSPEC, which is QoS model specific. The sender of a RESERVE message may want to receive some confirmation from a downstream node. In this case the RESERVE message must contain a RESPONSE_REQUEST object. The RESPONSE_REQUEST object contains the Request Identification Information (RII) value used to match back a RESPONSE to a request in a RESERVE message. 5.1.4 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 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, nor does it cause state to be installed in nodes other than the one that generated the QUERY. The format of a QUERY message is as follows: Van den Bosch, et al. Expires August 16, 2004 [Page 37] Internet-Draft NSLP for Quality-of-Service signaling February 2004 QUERY = COMMON_HEADER [ SCOPING ] RESPONSE_REQUEST [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] POLICY_DATA QSPEC [ *QSPEC ] The QSPEC object(s) must occur at the end of the message. There are no other requirements on transmission order, although the above order is recommended. A QUERY message may be scoped using the SCOPING object. A QUERY message must contain a RESPONSE_REQUEST object, that carries the Request Identification Information (RII) that allows matching back RESPONSE to the QUERY request. It is transported unchanged along the data path and should be used in combination with the SCOPING object to scope the RESPONSE to a QUERY message. The QUERY message can gather information along the data path in a number of objects. Some of these objects may be part of the QoS model. Others may be generic to the QoS-NSLP protocol. The QUERY message opaquely must transport a QSPEC object, describing the desired service level and a POLICY_DATA object, authorizing the requestor of the service. Based on configured local policy, a node may ignore the content of the POLICY_DATA object. The QUERY message may carry the REFRESH_PERIOD object. It is RECOMMENDED that in case of a receiver initiated reservation, the QUERY message carries the REFRESH_PERIOD object. The SESSION_ID object must be included in the QUERY message only if the session associated to this message has to be bound to another session. The content of the SESSION_ID object represents the SESSION_ID of the session that must be bound to the session associated to the QUERY message carrying this object. The binding of these two sessions is only possible in stateful QNEs. 5.1.5 RESPONSE Messages The RESPONSE message is used to provide information about the result of a previous QoS-NSLP message, e.g. confirmation, error or information resulting from a query. The RESPONSE message is impotent, it does not cause any state to be installed or modified. Van den Bosch, et al. Expires August 16, 2004 [Page 38] Internet-Draft NSLP for Quality-of-Service signaling February 2004 The format of a RESPONSE message is as follows: RESPONSE = COMMON_HEADER [ RSN ] [ SCOPING ] [ ERROR_SPEC ] QSPEC [ *QSPEC] The QSPEC object(s) must occur at the end of the message. There are no other requirements on transmission order, although the above order is recommended. A QNE may want to receive a RESPONSE message to inform it that the reservation has been successfully installed. A RESERVE or a QUERY message may contain a RESPONSE_REQUEST object for this purpose. Such a RESPONSE_REQUEST object can be used to request an explicit confirmation of the state manipulation signaled in the RESERVE message. The forwarding of the RESPONSE message along the path does not necessarily imply the existence of NTLP reverse-path state at every node. For example, the NTLP may have a mechanism to pass a message directly from the egress to the ingress of a region of QNEs that do not store per-flow reverse-path state. A RESPONSE message may be scoped using the SCOPING object. A QUERY always causes a RESPONSE to be sent. Therefore, a QUERY message will always contain a RESPONSE_REQUEST object. A RESERVE may cause a RESPONSE to be sent if this is explicitly requested, by using a RESPONSE_REQUEST object or when an error occurs. The RESPONSE Identification Information (RII) included in the RESPONSE_REQUEST object should be included in the SCOPING object of a RESPONSE message. A RESPONSE message may carry an RSN object. The content of this object must be identical to the content of the RSN object contained in the RESERVE message that generated this RESPONSE message. If a QNE or the QNR is unable to provide the requested information or if the response is negative, the RESPONSE message must carry an ERROR_SPEC object. The RESPONSE message opaquely must transport a QSPEC object(s), describing the desired service level. Van den Bosch, et al. Expires August 16, 2004 [Page 39] Internet-Draft NSLP for Quality-of-Service signaling February 2004 5.1.6 NOTIFY Messages NOTIFY messages are used to convey information to a QNE. NOTIFY messages are impotent (they do not cause a change in state directly). NOTIFY messages differ from RESPONSE messagess in that they need not refer to any particular state or previously received message. They are sent asynchronously. The NOTIFY message itself does not trigger or mandate any action in the receiving QNE. The format of a NOTIFY message is as follows: NOTIFY = COMMON_HEADER [ ERROR_SPEC ] QSPEC The QSPEC object must occur at the end of the message. There are no other requirements on transmission order, although the above order is recommended. The information conveyed by a NOTIFY message may be related to error conditions. In this case the ERROR_SPEC object must be carried by the NOTIFY message. The NOTIFY message opaquely must transport a QSPEC object, describing the desired service level. 6. IANA considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the QoS-NSLP, in accordance with BCP 26 [8]. The QoS NSLP requires IANA to create two registries. One for QoS NSLP message types, the other for QoS NSLP objects. This specification defines four message types: RESERVE=1, QUERY=2, RESPONSE=3 and NOTIFY=4. Values are taken from the Message type name space (8 bits). New Message types may be defined and assigned values by IANA. For this, standards action is required. Common Control Information has a Class and C-type assigned by IANA. This specification defines the following Common Control Information objects Van den Bosch, et al. Expires August 16, 2004 [Page 40] Internet-Draft NSLP for Quality-of-Service signaling February 2004 RESPONSE_REQUEST: Class=1 C-type=1: empty C-type=2: Request Identification Information RSN: Class=2 C-type=1: RSN REFRESH_PERIOD: Class=3 C-type=1: REFRESH_PERIOD SESSION_ID: Class=4 C-type=1: SESSION_ID SCOPING: Class=5 C-type=1: single hop C-type=2: Region scoping C-type=3: RII scoping ERROR_SPEC: Class=6 C-type=1: empty IANA will assign new ClassNum values and/or C-type for Common Control Information upon specification. The required specification needs to indicate what the correct behaviour is in case the new ClassNum or C-type is not understood. This specification defines a QSPEC object with assigned class = 8. The C-type identifies the QoS model, which can be standardized, well-known or private. Standardized Standardized QoS models have a C-type value in the range of 1-64. C-type values for standardized QoS models are assigned by IANA and require standards action. Well-known Well-known QoS models have a C-type value in the range of 65-128. They are assigned by IANA and require IETF consensus. Van den Bosch, et al. Expires August 16, 2004 [Page 41] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Private C-type values from the range 129-256 are for private use. 7. Requirements for the NSIS Transport Layer Protocol (NTLP) For the moment this section will merely describe what we assume and/ or request to be available from the NTLP. This section will later be updated to describe the eventual interface when NTLP work gets finalized. 7.1 Session identification The QoS NSLP keeps message and reservation state per session. A session is identified by a Session Identifier (SESSION_ID). The SESSION_ID is the primary index for stored NSLP state and needs to be constant and unique (with a sufficiently high probability) along a path through the network. We rely on the NTLP to pick a value for the Session ID and pass it over the API. 7.2 Support for bypassing intermediate nodes The QoS NSLP may want to restrict the handling of its messages to specific nodes. This functionality is needed to support layering (explained in Section 4.3), when only the edge QNEs of a domain process the message. This requires a mechanism at the NTLP level (which can be invoked by the QoS NSLP) to bypass intermediates nodes between the edges of the domain. As a suggestion, we identified two ways for bypassing intermediate nodes. One solution is for the end-to-end session to carry a different protocol ID (QoS-NSLP-E2E-IGNORE protocol ID, similar to the RSVP-E2E-IGNORE that is used for RSVP aggregation ([11]). Another solution is based on the use of multiple levels of the router alert option. In that case, internal routers are configured to handle only certain levels of router alerts. The choice between both approaches or another approach that fulfills the requirement is left to the NTLP design. 7.3 Support for peer change identification There are several circumstances where it is necessary for a QNE to identify the adjacent QNE peer, which is the source of a signaling application message; for example, it may be to apply the policy that "state can only be modified by messages from the node that created it" or it might be that keeping track of peer identity is used as a (fallback) mechanism for rerouting detection at the NSLP layer. Van den Bosch, et al. Expires August 16, 2004 [Page 42] Internet-Draft NSLP for Quality-of-Service signaling February 2004 We rely on the NTLP to provide this functionality and suggest it be implemented as an opaque identifier (Source Identification Information (SII)) which, by default, all outgoing QoS-NSLP messages are tagged with at the NTLP layer. This identifier is propagated to the next QNE, where it can be used to identify the state associated with the message; The SII is logically similar to the RSVP_HOP object of [6]; however, any IP (and possibly higher level) addressing information is not interpreted in the QoS-NSLP. Indeed, the intermediate NTLP nodes could enforce topology hiding by masking the content of the SII (provided this is done in a stable way). Keeping track of the SII of a certain reservation also provides a means for the QoS-NSLP to detect route changes. When a QNE receives a RESERVE referring to existing state but with a different SII, it knows that its upstream peer has changed. It can then use the old SII to send initiate a teardown along the old section of the path. This functionality would require the NTLP to be able to route based on the SII. We would like this functionality to be available as a service from the NTLP. 7.4 Support for stateless operation Stateless or reduced state QoS-NSLP operation makes the most sense when some nodes are able to operate in a stateless way at the NTLP level as well. Such nodes should not worry about keeping reverse state, message fragmentation and reassembly (at the NTLP), congestion control or security associations. A stateless or reduced state QNE will be able to inform the underlying NTLP of this situation. We rely on the NTLP design to allow for a mode of operation that can take advantage of this information. 7.5 Last node detection There are situations in which a QNE needs to determine whether it is the last QNE on the data path (QNR), e.g. to construct and send a RESPONSE message. A number of conditions may result in a QNE determining that it is the QNR: o the QNE may be the flow destination o the QNE have some other prior knowledge that it should act as the QNR o the QNE may be the last NSIS-capable node on the path o the QNE may be the last NSIS-capable node on the path supporting the QoS NSLP Of these four conditions, the last two can only be detected by the NTLP. We rely on the NTLP to inform the QoS-NSLP about these cases by Van den Bosch, et al. Expires August 16, 2004 [Page 43] Internet-Draft NSLP for Quality-of-Service signaling February 2004 providing a trigger to the QoS-NSLP when it determines that it is the last NE on the path, which supports the QoS-NSLP. It requires the NTLP to have an error message indicating that no more NSLPs of a particular type are available on the path. 7.6 Re-routing detection Route changes may be detected at the NTLP layer or the information may be obtained by the NTLP through local interaction with or notification from routing protocols or modules. This specification requests the NTLP design to foresee notification of this information over the API. 7.7 Priority of signalling messages The QoS-NSLP will generate messages with a range of performance requirements for the NTLP. These requirements may result from a prioritization at the QoS-NSLP (Section 4.3) or from the responsiveness expected by certain applications supported by the QoS-NSLP. The NTLP design should be able to ensure that performance for one class of messages was not degraded by aggregation with other classes of messages. It is currently an open issue how many priority levels are required. 7.8 Knowledge of intermediate QoS NSLP unaware nodes In some cases it is useful to know that a reservation has not been installed at every router along the path. It is not possible to determine this using only NSLP functionality. The NTLP should be able to provide information to the NSLP about whether the message has passed through nodes that did not provide support for this NSLP. This might be realised by the NTLP by a mixture of NTLP node counting, and examination of the IP TTL or Hop Limit. The QoS NSLP, however, does not need to know the number of intermediate nodes, only that one or more exists. 7.9 NSLP Data Size When the NTLP passes the QoS NSLP data to the NSLP for processing, it must also indicate the size of that data. (It is assumed that the NTLP message structure will indicate how long this part of the NTLP message is.) Van den Bosch, et al. Expires August 16, 2004 [Page 44] Internet-Draft NSLP for Quality-of-Service signaling February 2004 7.10 NAT Traversal The QoS NSLP relies on the NTLP for NAT traversal. 8. Open issues 8.1 Aggregation error handling QSPEC objects may be stacked to allow aggregation and layering. In error-free conditions, the top of the QSPEC stack has the QSPEC object that is locally valid. A QNE may receive a QoS NSLP message with a QSPEC stack of which the top object is not recognised. This can occur under error conditions, e.g. when a domain boundary is misconfigured, or it me be the result from a policy to detect domain boundaries by encountering unrecognised QSPEC objects. In some situations, a QNE may be able to recover from the error condition by inspecting a larger portion of the stack.It is currently an open question whether o A QNE should be allowed to do that instead of or in addition to sending an error. o How far the stack can be inspected. o If and how the QNE should update the stack in case it finds a QSPEC it recognises. 8.2 Region scoping This specification allows QNEs to scope their messages, i.e. to restrict the extent to which messages may travel along and be interpreted on the path. For this, the scopes of whole path, single hop and back to me (RII) are defined. Also, a region can be configured administratively or it can be derived from some other means (e.g. RAO levels) in case of aggregation. It is currently an open question whether this specification should define and support a more generic notion of region (e.g. to implement region policies independent from aggregation regions,...). 8.3 Priority of reservations Priority of certain reservations over others may be required when QoS resources are oversubscribed. In that case, existing reservations may be preempted in other 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 Van den Bosch, et al. Expires August 16, 2004 [Page 45] Internet-Draft NSLP for Quality-of-Service signaling February 2004 then keeps track of the resource consumption at each priority level. Reservations are established when resource 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 QoS model specific issue and therefore outside the scope of this specification. However, the concepts of setup and holding priority are widely accept and we expect the specification of a Priority object in the QSPEC template to be useful for a wide range of QoS models. It is an open question to the NSIS community whether the concepts of setup and holding priority are useful enough to define a priority object in this specification. Alternatively, this could be left as QoS model specific. 9. Security Considerations 9.1 Introduction and Threat Overview The security requirement for the QoS NSLP is to protect the signaling exchange for establishing QoS reservations against identified security threats. For the signaling problem as a whole, these threats have been outlined in [21]; the NSIS framework [3] assigns a subset of the responsibility to the NTLP and the remaining threats need to be addressed by NSLPs. The main issues to be handled can be summarised as: Authorization: The QoS NSLP must assure that the network is protected against theft-of-service by offering mechanisms to authorize the QoS reservation requestor. A user requesting a QoS reservation might want proper resource accounting and protection against spoofing and other security vulnerabilities which lead to denial of service and financial loss. In many cases authorization is based on the authenticated identity. The authorization model must provide guarantees that replay attacks are either not possible or limited to a certain extent. Authorization can also be based on traits which enables the user to remain anonymous. Support for user identity confidentiality can be accomplished. Message Protection: Signaling message content should be protected against modification, replay, injection and eavesdropping while in transit. Authorization information, such as authorization tokens, need protection. This type of protection at the NSLP layer is neccessary to protect messages between NSLP nodes which includes Van den Bosch, et al. Expires August 16, 2004 [Page 46] Internet-Draft NSLP for Quality-of-Service signaling February 2004 end-to-middle, middle-to-middle and even end-to-end protection. In addition to the above-raised issues we see the following functionality provided at the NSLP layer: Prevention of Denial of Service Attacks: GIMPS and QoS NSLP nodes have finite resources (state storage, processing power, bandwidth). The protocol mechanisms suggested in this document should try to minimise exhaustion attacks against these resources when performing authentication and authorization for QoS resources. To some extent the QoS NSLP relies on the security mechanisms provided by GIMPS which by itself relies on existing authentication and key exchange protocols. Some signaling messages cannot be protected by GIMPS and hence should be used with care by the QoS NSLP. An API must ensure that the QoS NSLP implementation is aware of the underlying security mechanisms and must be able to indicate which degree of security is provided between two GIMPS peers. If a level of security protection for QoS NSLP messages is required which goes beyond the security offered by GIMPS or underlying security mechanisms, additional security mechanisms described in this document must be used. The different usage environments and the different scenarios where NSIS is used make it very difficult to make general statements without reducing its flexibility. 9.2 Trust Model For this version of the document we will rely on a model which requires trust between neighboring NSLP nodes to establish a chain-of-trust along the QoS signaling path. This model is simple to deploy, was used in previous QoS authorization environments (such as RSVP) and seems to provide sufficiently strong security properties. We refer to this model as the 'New Jersey Turnpike' model. On the New Jersey Turnpike, motorists pick up a ticket at a toll booth when entering the highway. At the highway exit the ticket is presented and payment is made at the toll booth for the distance driven. For QoS signaling in the Internet this procedure is roughly similar. In most cases the data sender is charged for transmitted data traffic whereby charging is provided only between neighboring entities. Van den Bosch, et al. Expires August 16, 2004 [Page 47] Internet-Draft NSLP for Quality-of-Service signaling February 2004 +------------------+ +------------------+ +------------------+ | Network | | Network | | Network | | X | | Y | | Z | | | | | | | | -----------> -----------> | | | | | | | | | | | | | +--------^---------+ +------------------+ +-------+----------+ | . | . | v +--+---+ Data Data +--+---+ | Node | ==============================> | Node | | A | Sender Receiver | B | +------+ +------+ Legend: ----> Peering relationship which allows neighboring networks/entities to charge each other for the QoS reservation and data traffic ====> Data flow ..... Communication to the end host Figure 16: New Jersey Turnpike Model The model shown in Figure 16 uses peer-to-peer relationships between different administrative domains as a basis for accounting and charging. As mentioned above, based on the peering relationship a chain-of-trust is established. There are several issues which come to mind when considering this type of model: o This model allows authorization on a request basis or on a per-session basis. Authorization mechanisms will be elaborated in Section 9.3. The duration for which the QoS authorization is valid needs to be controlled. Combining the interval with the soft-state interval is possible. Notifications from the networks also seem to be viable approach. o The price for a QoS reservation needs to be determined somehow and communicated to the charged entity and to the network where the charged entity is attached. Price distribution protocols are not covered in this version of the document. This model assumes, per default, that the data sender is authorizing the QoS reservation. Please note that this is only a simplification and further extensions are possible and left for a future version of this document. Van den Bosch, et al. Expires August 16, 2004 [Page 48] Internet-Draft NSLP for Quality-of-Service signaling February 2004 o This architecture seems to be simple enough to allow a scalable solution (ignoring reverse charging, multicast issues and price distribution). Charging the data sender as performed in this model simplifies security handling by demanding only peer-to-peer security protection. Node A would perform authentication and key establishment. The established security association (together with the session key) would allow the user to protect QoS signaling messages. The identity used during the authentication and key establishment phase would be used by Network X (see Figure 16) to perform the so-called policy-based admission control procedure. In our context this user identifier would be used to establish the necessary infrastructure to provide authorization and charging. Signaling messages later exchanged between the different networks are then also subject to authentication and authorization. The authenticated entity thereby is, however, the neighboring network and not the end host. The New Jersey Turnpike model is attractive because of its simplicity. S. Schenker et. al. [23] discuss various accounting implications and introduced the edge pricing model. The edge pricing model shows similarity to the model described in this section with the exception that mobility and the security implications itself are not addressed. 9.3 QoS Authorization Authorization is a necessary function in order to prevent theft-of-service and to enable charging. With regard to authorization a few issues still need to be resolved to specify the protocol interaction for a QoS NSLP with regard to authorization of resource requests. This section provides a description of the different approaches for providing authorization for QoS resource requests. Three different approaches are shown, whereby one is a two-party and two others describe a three party approach. 9.3.1 Authorization for the two party approach This section starts with the conceptually simpler two party approach. Van den Bosch, et al. Expires August 16, 2004 [Page 49] Internet-Draft NSLP for Quality-of-Service signaling February 2004 +-------------+ QoS request +--------------+ | Entity |----------------->| Entity | | requesting | | authorizing | | resource |granted / rejected| resource | | |<-----------------| request | +-------------+ +--------------+ ^ ^ +...........................+ financial establishment Figure 17: Two party approach Figure 17 describes the simple and basic approach where the authorization decision is purely executed between the two entities only or where previous (out-of-band) mechanisms separated the signaling protocol from executing other entities during NSIS protocol execution. The entity authorizing the resource request and the entity actually performing the QoS reservation are in the same administrative domain. Hence they are treated as a single logical entity. Examples for this type of model can be found between two neighboring networks (inter-domain signaling) where a long-term contract (or other out-of-band mechanisms) exists and allows both networks to know how to charge the other entity (i.e. how the authorizing entity finally gets paid for the consumed resources) and how to authorize the resource requesting entity (i.e. associating the identifier of the protected signaling message to the identity used in the authentication and key exchange protocol run and finally this identity to the user identity of the contract for the purpose of charging). No additional message signaling for authorization is required. In this scenario the identity used during the authentication and key exchange process is used for authorizing the same entity. The QoS NSLP needs to have access to this authenticated identity via an API. 9.3.2 Token based three party approach This section describes an approach which uses authorization tokens such as those introduced with [12] and [13] or with the Open Settlement protocol [26]. The former only associates two different signaling protocols and their authorization with each other whereas the latter is a form of digital money. In this text we refer to the former as the 'authorization tokens' and in the latter case as 'OSP tokens'. In case of authorization tokens the entity which requests Van den Bosch, et al. Expires August 16, 2004 [Page 50] Internet-Draft NSLP for Quality-of-Service signaling February 2004 authorization wants to run, for example, SIP with an entity in the local network and wants to experience quality of service for the media traffic. Some form of authorization will be provided at the SIP proxy, which acts as the resource authorizing entity in Figure 18. In case of a successful verification of the request SIP signaling returns an authorization token which is subsequently included in the QoS signaling protocol to refer to the previous authorization decision. The authorization decision can be passed by value or by reference. The advantage of the latter is that the token is smaller (i.e., effectively only a pointer to installed state in the network) with the disadvantage that the entity performing the QoS reservation has to query the state, possibly from a central entity. The token based approach assumes that the entity which authorizes the QoS request (and which also creates the token) is trusted by the entity which performs the QoS reservation. These two entities do not necessarily need to be in the same administrative domain. Security mechanisms must ensure that the token cannot be modified the token questing entity is authenticated and authorized at the token granting entity the token cannot be stolen and reused by an adversary Hence, to prevent an adversary from eavesdropping and stealing the authorization token it is necessary to establish at least a unilateral authenticated secure channel between entity A and B. As a side-effect it is possible to provide anonymous authorization since the authorization decision based on the received token by entity B does not need to be based on the identity of A. This assumes that entity C does not provide entity B with the identity. Van den Bosch, et al. Expires August 16, 2004 [Page 51] Internet-Draft NSLP for Quality-of-Service signaling February 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 18: Token based three party approach The token is only an attribute in the QoS NSLP message. The token acts as a form of voucher and is therefore a one-shot message. For the OSP token (or digital money) alike approach, as soon as the credits are consumed a new token needs to be requested in order. Refresh messages can therefore be used to trigger the transmission of new tokens. A trigger message from the network is necessary to request a new token. Tokens provide a good mechanism for the client to restrict the amount of spend resources and to quickly learn about the cost of a QoS reservation if tokens represent only a small value (such as those used in hash-chain based approaches). The refresh interval is therefore, in some sense, bound to the "charging" interval. Please note that OSP tokens only serve as an example here. The content of the OSP token is tailored towards its usage in the telephony environment. Therefore, we see OSP tokens as a prominent representative of authorization token usage. Since authorization tokens or OSP tokens can be fairly large fragmentation is possible or even likely. 9.3.3 Generic three party approach This section covers a generic three party approach. Figure 19 shows the intra-domain variant of the exchange. Van den Bosch, et al. Expires August 16, 2004 [Page 52] Internet-Draft NSLP for Quality-of-Service signaling February 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 19: Three party approach (intra-domain) The main difference between the scenario in Figure 19 and Figure 20 is the trust relationship between the participating entities. In Figure 20 the home AAA server is responsible for authoring the QoS request. This might be on a per-request basis, periodically, or on a per-session basis. In both cases the EAP authentication runs between the EAP Peer (entity A in Figure 19) and between the EAP Server (entity C in Figure 19). For the EAP method protocol run the Authenticator (entity B in Figure 19) is not actively involved. To fulfill the requirements of the EAP keying framework it is necessary to execute a protocol exchange between entity A and entity B subsequently to successful EAP authentication. This exchange should lead to a secure channel between these two entities. The main advantage of this exchange is that a number of authentication and key exchange protocols can be used in a very flexible fashion; these protocols can be tailed exactly to the needs of the architecture and the environment a secure channel can be established the protocol exchange is effectively a three party protocol authorization can be incorporated in a very flexible way which allows the home network (or some other entity) to give tight control over the sessions The disadvantage of this approach is that there is no out-of-the-box solution available. Further investigation is required here. Van den Bosch, et al. Expires August 16, 2004 [Page 53] Internet-Draft NSLP for Quality-of-Service signaling February 2004 +-----------------------------+ +-----------------+ | Local Network | | | | |QoS | | | +------------+ authz. req. +---------+ | | | Local |-----+----+--->| Home | | | | AAA | |QoS | | AAA | | | | Server |<----+----+----| Server | | | +---------+--+ authz. res. +---------+ | | ^ | | | | | | | <...financial...> | | QoS | QoS | settlement | | authz| authz| | | | | req.| res.| | | | | | | | | | | | v | | | +----------+ QoS +----+---------+ | | Users | |Entity | request | Entity | | | Home Network | |requesting|--+------->| performing | | +-----------------+ |resource |<-+--------| QoS | | +----------+ granted/ | reservation | | rejected +--------------+ | | | +-----------------------------+ Figure 20: Three party approach (inter-domain) 9.3.4 Computing the authorization decision Whenever an authorization decision has to be made then there is the question which information serves as an input to the authorizing entity. The following information items have been mentioned in the past for computing the authorization decision (in addition to the authenticated identity): Price QoS objects Policy rules Policy rules include attributes like time of day, subscription to certain services, membership, etc. into consideration when computing an authorization decision. A detailed description of the authorization handling will be left for a future version of this document. The authors assume that the QoS NSLP needs to provide a number of attributes to support the large range of scenarios. Van den Bosch, et al. Expires August 16, 2004 [Page 54] Internet-Draft NSLP for Quality-of-Service signaling February 2004 10. Change History Changes from -00 * Additional explanation of RSN versus Session ID differences. (Session IDs still need to be present and aren't replaced by RSNs. Explain how QoS-NSLP could react once it notes that it maintains stale state.) * Additional explanation of message types - why we don't just have RESERVE and RESPONSE. * Clarified that figure 1 is not an implementation restriction. Changes from -01 * Significant restructuring. * Added more concrete details of message formats and processing. * Added description of layering/aggregation concepts. * Added details of authentication/authorisation aspects. 11. Acknowledgements The authors would like to thank Eleanor Hepworth for her useful comments. 12. Contributors This draft combines work from three individual drafts. The following authors from these drafts also contributed to this document: Robert Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and Maarten Buechli (Dante) and Eric Waegeman (Alcatel). Yacine El Mghazli (Alcatel) contributed text on AAA. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Hancock, R., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-05 (work in progress), October 2003. [4] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-00 (work in progress), October 2003. Informative References Van den Bosch, et al. Expires August 16, 2004 [Page 55] Internet-Draft NSLP for Quality-of-Service signaling February 2004 [5] Braden, B., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [6] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [10] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [11] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [12] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003. [13] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003. [14] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003. [15] Brunner, M., "Requirements for Signaling Protocols", draft-ietf-nsis-req-09 (work in progress), August 2003. [16] Tschofenig, H., "NSIS Authentication, Authorization and Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress), March 2003. [17] Tschofenig, H., "QoS NSLP Authorization Issues", draft-tschofenig-nsis-qos-authz-issues-00 (work in progress), June 2003. [18] Ash, J., "NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept", Van den Bosch, et al. Expires August 16, 2004 [Page 56] Internet-Draft NSLP for Quality-of-Service signaling February 2004 draft-ash-nsis-nslp-qos-sig-proof-of-concept-01 (work in progress), February 2004. [19] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", draft-kappler-nsis-qosmodel-controlledload-00 (work in progress), February 2004. [20] Bader, A., "RMD (Resource Management in Diffserv) QoS-NSLP model", draft-bader-rmd-qos-model-00 (work in progress), February 2004. [21] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", draft-ietf-nsis-threats-03 (work in progress), October 2003. [22] Westberg, L., "Resource Management in Diffserv (RMD) Framework", draft-westberg-rmd-framework-04.txt, work in progress, September 2003. [23] Shenker, S., Clark, D., Estrin, D. and S. Herzog, "Pricing in computer networks: Reshaping the research agenda", Proc. of TPRC 1995, 1995. [24] Metro Ethernet Forum, "Ethernet Services Model", letter ballot document , August 2003. [25] Jacobson, V., "Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking , Vol. 2 , No. 2 , April 1994. [26] ETSI, "Telecommunications and internet protocol harmonization over networks (tiphon); open settlement protocol (osp) for inter- domain pricing, authorization, and usage exchange", Technical Specification 101 321, version 2.1.0. Authors' Addresses Sven Van den Bosch Alcatel Francis Wellesplein 1 Antwerpen B-2018 Belgium EMail: sven.van_den_bosch@alcatel.be Van den Bosch, et al. Expires August 16, 2004 [Page 57] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Georgios Karagiannis University of Twente/Ericsson P.O. Box 217 Enschede 7500 AE The Netherlands EMail: karagian@cs.utwente.nl Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK EMail: andrew.mcdonald@roke.co.uk Appendix A. Object Definitions The currentlly specified C-Types definitions are contained in this Appendix. To accommodate other address families, additional C-Types could easily be defined. All unused fields should be sent as zero and ignored on receipt. A.1 RESPONSE_REQUEST Class RESPONSE_REQUEST Class = 1. RESPONSE_REQUEST object: Class = 1, C-Type = 1 The object content is empty RESPONSE_REQUEST object: Class = 1, C-Type = 2 +-------------+-------------+-------------+-------------+ | Request Identification Information (RII)(4 bytes) | +-------------+-------------+-------------+-------------+ Van den Bosch, et al. Expires August 16, 2004 [Page 58] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Request Identification Information (RII) (4 bytes) An identifier which must be (probabilistically) unique within the context of a SESSION_ID, and SHOULD be different for each response request. Used by a node to match back a RESPONSE to a request in a RESERVE or QUERY message. A.2 RSN Class RSN class = 2. RSN object: Class = 2, C-Type = 1 +-------------+-------------+-------------+-------------+ | Reservation Sequence Number (RSN) (4 bytes) | +-------------+-------------+-------------+-------------+ Reservation Sequence Number (RSN) (4 bytes) An incrementing sequence number that indicates the order in which state modifying actions are performed by a QNE. It has local significance only, i.e. between a pair of neighbouring stateful QNEs. A.3 REFRESH_PERIOD Class REFRESH_PERIOD class = 3. REFRESH_PERIOD Object: Class = 3, C-Type = 1 +-------------+-------------+-------------+-------------+ | Refresh Period R (4 bytes) | +-------------+-------------+-------------+-------------+ Van den Bosch, et al. Expires August 16, 2004 [Page 59] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Refresh Period R (4 bytes) The refresh timeout period R used to generate this message; in milliseconds. A.4 SESSION_ID Class SESSION_ID class = 4. SESSION_ID Object: Class = 4, C-Type = 1 +-------------+-------------+-------------+-------------+ | | + + | | + SESSION_ID (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ SESSION_ID (16 bytes) It represents the SESSION_ID as specified in [3] of the session that must be bound to the session associated to the message carrying this object. A.5 SCOPING Class SCOPING class = 5. SCOPING Object: Class = 5, C-Type = 1 No content value. Selection of a single hop message scoping. Van den Bosch, et al. Expires August 16, 2004 [Page 60] Internet-Draft NSLP for Quality-of-Service signaling February 2004 SCOPING Object: Class = 5, C-Type = 2 +-------------+-------------+-------------+-------------+ | Region scoping (4 bytes) | +-------------+-------------+-------------+-------------+ Region scoping (4 bytes) Ordered number, forwarded by routers belonging to region with same or higher number; SCOPING Object: Class = 5, C-Type = 3 +-------------+-------------+-------------+-------------+ | RII scoping (4 bytes) | +-------------+-------------+-------------+-------------+ RII (back to me) scoping (4 bytes) An identifier which must be (probabilistically) unique within the context of a SESSION_ID, and SHOULD be different for each response request. Used by a node to match back a RESPONSE to a request in a RESERVE or QUERY message. A.6 ERROR_SPEC Class ERROR_SPEC class = 6. ERROR_SPEC object: Class = 6, C-Type = 1 +-------------+-------------+-------------+-------------+ | Error (4 bytes) | +-------------+-------------+-------------+-------------+ | Flags | Error Code | Error Value | +-------------+-------------+-------------+-------------+ Van den Bosch, et al. Expires August 16, 2004 [Page 61] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Error (4 bytes) To be done Flags (1 byte) To be done Error Code (1 byte) A one-octet error description. Error Value (2 bytes) A two-octet field containing additional information about the error. Its contents depend upon the Error Type. The values for Error Code and Error Value are defined in Appendix B (to be done). A.7 POLICY_DATA Class This section presents a set of specifications for supporting generic authorization in QoS NSLP. These specs include the standard format of POLICY_DATA objects, and a description of QoS NSLP handling of authorization events. This section does not advocate a particular authorization approach (2-party, 3-party, token-based 3-party). The traffic control block is responsible for controlling and enforcing access and usage policies. A.7.1 Base Format POLICY_DATA object: Class=7, C-Type=1 +-------------------------------------------------------+ | | // Option List // | | +-------------------------------------------------------+ | | // Policy Element List // | | Van den Bosch, et al. Expires August 16, 2004 [Page 62] Internet-Draft NSLP for Quality-of-Service signaling February 2004 +-------------------------------------------------------+ Option List: Variable length. See more details in Appendix A.7.2. Policy Element List: Variable length. See more details in Appendix A.7.3. A.7.2 Options This section describes a set of options that may appear in POLICY_DATA objects. Some policy options appear as QoS NSLP objects but their semantic is modified when used as policy data options. Policy Refresh TIME_VALUES (PRT) object: The Policy Refresh TIME_VALUES (PRT) option is used to slow policy refresh frequency for policies that have looser timing constraints relative to QoS NSLP. If the PRT option is present, policy refreshes can be withheld as long as at least one refresh is sent before the policy refresh timer expires. A minimal value for PRT is the NSLP session refresh period R; lower values are assumed to be R (neither error nor warning should be triggered). This option is especially useful to combine strong (high overhead) and weak (low overhead) authentication certificates as policy data. In such schemes the weak certificate can support admitting a reservation only for a limited time, after which the strong certificate is required. This approach may reduce the overhead of POLICY_DATA processing. Strong certificates could be transmitted less frequently, while weak certificates are included in every QoS NSLP refresh. Policy Source Identification Information (PSII) object: The Policy SII object identifies the neighbor/peer policy-capable QN that constructed the policy object. When policy is enforced at border QNEs, peer policy nodes may be several NSLP hops away from each other and the SII is the basis for the mechanism that allows them to recognize each other and communicate safely and directly. As stated above, we assume such an (P)SII to be available from a service from the NTLP. If no PSII object is present, the policy data is implicitly assumed to have been constructed by the QoS NSLP HOP indicated in the SII (i.e., the neighboring QoS NSLP node is policy-capable). Integrity object: The INTEGRITY object option inside POLICY_DATA object creates direct secure communications between non-neighboring policy aware nodes without involving PIN nodes. Van den Bosch, et al. Expires August 16, 2004 [Page 63] A.7.3 Policy Elements There are no requirements for all nodes to process this container. Policy data is opaque to NSLP, which simply passes it to policy control when required. The content of policy elements is opaque to the QoS NSLP layer. Only policy peers understand their internal format and NSLP layer simply passes it to policy control when required. Policy Elements have the following format: +-------------+-------------+-------------+-------------+ | Length | P-Type | +---------------------------+---------------------------+ | | // Policy information (Opaque to QoS NSLP) // | | +-------------------------------------------------------+ A.7.3.1 Authorization token Policy Element The AUTHZ_TOKEN policy element contains a list of fields, which describe the session, along with other attributes. +-------------+-------------+-------------+-------------+ | Length | P-Type = AUTHZ_TOKEN | +-------------+-------------+-------------+-------------+ // Session Authorization Attribute List // +-------------------------------------------------------+ Session Authorization Attribute List: variable length. The session authorization attribute list is a collection of objects which describes the session and provides other information necessary to verify the resource reservation request. See [12] for a details. Session Authorization Attributes. A session authorization attribute may contain a variety of information and has both an attribute type and subtype. The attribute itself MUST be a multiple of 4 octets in length, and any attributes that are not a multiple of 4 octets long MUST be padded to a 4-octet boundary. All padding bytes MUST have a value of zero. Van den Bosch, et al. Expires August 16, 2004 [Page 64] Internet-Draft NSLP for Quality-of-Service signaling February 2004 +--------+--------+--------+--------+ | Length | X-Type |SubType | +--------+--------+--------+--------+ | Value ... | +--------+--------+--------+--------+ Length: 16 bits The length field is two octets and indicates the actual length of the attribute (including Length, X-Type and SubType fields) in number of octets. The length does NOT include any bytes padding to the value field to make the attribute a multiple of 4 octets long. X-Type: 8 bits Session authorization attribute type (X-Type) field is one octet. IANA acts as a registry for X-Types as described in Section 6. Initially, the registry contains the following X-Types: 1 AUTH_ENT_ID: The unique identifier of the entity which authorized the session. 2 SESSION_ID: Unique identifier for this session. 3 SOURCE_ADDR: Address specification for the session originator. 4 DEST_ADDR: Address specification for the session end-point. 5 START_TIME: The starting time for the session. 6 END_TIME: The end time for the session. 7 RESOURCES: The resources which the user is authorized to request. 8 AUTHENTICATION_DATA: Authentication data of the session authorization policy element. SubType: 8 bits Session authorization attribute sub-type is one octet in length. The value of the SubType depends on the X-Type. Value: variable length The attribute specific information is defined in [12]. A.7.3.2 OSP Token Policy Element To be completed. A.7.3.3 User Identity Policy element To be completed. Van den Bosch, et al. Expires August 16, 2004 [Page 65] Internet-Draft NSLP for Quality-of-Service signaling February 2004 A.8 QSPEC Class QSPEC class = 8. QSPEC object: Class = 8, C-Type = (QoS model ID) This object contains the QSPEC (QoS specification) information. Its content has a variable length and it is QoS model specific. Such a QoS model can be a standardized one, a private one, or a well-known one. The C-Type contains the QoS model ID that identifies the used QSPEC. The contents and encoding rules for this object are specified in other documents, prepared by QoS model designers. Van den Bosch, et al. Expires August 16, 2004 [Page 66] Internet-Draft NSLP for Quality-of-Service signaling February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Van den Bosch, et al. Expires August 16, 2004 [Page 67] Internet-Draft NSLP for Quality-of-Service signaling February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Van den Bosch, et al. Expires August 16, 2004 [Page 68]