NSIS working group Internet Draft M. Buchli E. Waegeman A. Conte Document: draft-buchli-nsis-nslp-00.txt Alcatel Expires: December 2003 June 2003 A Network Service Layer Protocol for QoS signaling Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract The Next Steps In Signaling (NSIS) working group within the IETF is currently in the process of defining a signaling protocol. Consensus was reached to split the protocol into two layers; a general-purpose transport layer and a client layer that is application specific. The subject of this document is the specification of a client layer that can be used to request Quality of Service (QoS) to a network. 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 [2]. Table of Contents Buchli et al. Expires - December 2003 [Page 1] A Network Service Layer Protocol for QoS June 2003 1. Terminology....................................................2 2. Introduction...................................................2 3. Message types..................................................3 4. Object types...................................................4 5. Message flows..................................................4 5.1 Setup of reservation.......................................5 5.2 Modification of reservation................................7 5.3 Teardown of reservation....................................8 6. Route changes and mobility.....................................9 6.1 Rerouting..................................................9 6.2 Mobility with address changes.............................10 7. Open issues...................................................12 Security Considerations..........................................12 Reference........................................................13 Acknowledgments..................................................14 Author's Addresses...............................................14 Appendix A: Object specification.................................14 Appendix B: Client object layout.................................18 1. Terminology Session Application layer flow of information for which some network control state information is to be manipulated or monitored [3]. The state is identified by a globally unique session identifier. Flow A flow is defined by the source and destination IP address pair that are associated with the data sender and receiver. NSIS Entity The function within a node which implements an NSIS protocol. 2. Introduction The signaling protocol consists of two layers; a generic transport layer (NTLP) that provides neighbor discovery, detection of routechange and mobility events, reliable delivery, security and soft state management. The transport layer has a hop-by-hop scope (i.e. signaling node to signaling node). An implementation based on the CASP proposal is discussed in [4]. The client layer (NSLP) has an end-to-end scope and contains application specific functionality. The scope of this document is to present a specification for a client layer for QoS signaling. Buchli et al. Expires - December 2003 [Page 2] A Network Service Layer Protocol for QoS June 2003 The protocol layer model is depicted in figure 1. As depicted, certain functionalities of the transport layer can be implemented by existing (and proven) transport and security protocols. +=========================================+ | | | Client layer (NSLP) | | | +=========================================+ | | - | Transport layer | \ |.........................................| | | [security protocols (IPSec, TLS)] | | NTLP |.........................................| | | transport protocol (TCP, SCTP, UDP) | / +=========================================+ - | IPv4, IPv6 | +=========================================+ Figure 1:Protocol layer model 3. Message types The following message types are defined for the QoS NSLP. PATH The PATH message does not trigger any admission control at the client layer. It may, however, trigger e.g. authorization verification procedures. Furthermore, the transport layer will install routing state. This allows, for instance, for receiver initiated reservations. RESERVE The RESERVE message will trigger an admission control decision in an NSIS Entity. MODIFY The MODIFY message can be used to change the amount of reserved resources, the QoS Class or to add/remove a microflow (e.g. identified by port nrs in case of IPv4) for an existing session between a certain source and destination IP address. TEAR The TEAR message requests to release the allocated resources for a certain session. ACK Buchli et al. Expires - December 2003 [Page 3] A Network Service Layer Protocol for QoS June 2003 The ACK message confirms the success of a RESERVE, PATH, MODIFY or TEAR message. NACK The NACK message indicates an error resulting from a RESERVE, PATH, MODIFY or TEAR message. 4. Object types The client object that is exchanged between the transport and client layer consists of a common client header and a variable number of objects. The following objects are defined (see Appendix A for the object format specification). QoS class The QoS class specifies a subflow and its QoS requirements. The subflow is associated to a session (=src/dest IP address) and is defined by e.g. the source/destination IP port nrs and protocol id in case of IPv4. For each subflow a desired and a minimal QoS can be specified. A signaling node should reject the request if the minimal QoS requirement cannot be satisfied. Multiple subflows may be specified in a QoS class object in order to support several flows between two hosts. Reason class The reason class indicates why a certain request has been rejected or why a certain reservation has been released. Priority class The priority class can indicate whether the reservation is used for e.g. an emergency call. According to the local policy of the NSIS Entity other reservations may be preempted for instance. Furthermore, other (local) objects may be required in the client object for e.g. authorization purposes. For instance, RSVP POLICY DATA objects [6][7] may be included. Furthermore, there may be a need to define new objects, e.g. to carry OSP [8] authorization tokens. 5. Message flows Protocol messages are exchanged between signaling nodes. Three types of signaling nodes are distinguished [3]: * NSIS Initiator (NI): the signaling entity which makes the resource request, usually as a result of user application request. Buchli et al. Expires - December 2003 [Page 4] A Network Service Layer Protocol for QoS June 2003 * NSIS Responder (NR): the signaling entity that acts as the endpoint for the signaling and can optionally interact with applications as well. * NSIS Forwarder (NF): the signaling entity an NI and NR which propagates NSIS signaling further through the network. 5.1 Setup of reservation The QoS signaling protocol can be used for sender and receiver initiated reservations. The message flows are respectively shown in sequence diagram 1 and 2. An example of an unsuccessful reservation request is depicted in sequence diagram 3. NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | | | 1. RESERVE | | | | -------------> | 2. RESERVE | | | | ---------------> | 3. RESERVE | | | | ------------> | | | | 4. ACK | | | 5. ACK | <------------ | | 6. ACK | <--------------- | | | <------------- | | | | | | | Sequence diagram 1: Sender initiated reservation setup NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | | | 1. PATH | | | | -------------> | 2. PATH | | | | ---------------> | 3. PATH | | | | ------------> | | | | 4. RESERVE | | | 5. RESERVE | <------------ | | 6. RESERVE | <--------------- | | | <------------- | | | | 7. ACK | | | | -------------> | 8. ACK | | | | ---------------> | 9. ACK | | | | ------------> | | | | | Buchli et al. Expires - December 2003 [Page 5] A Network Service Layer Protocol for QoS June 2003 Sequence diagram 2: Receiver initiated reservation setup NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | | | 1. PATH | | | | -------------> | 2. PATH | | | | ---------------> | 3. PATH | | | | ------------> | | | | 4. RESERVE | | | 5. RESERVE | <------------ | | | <--------------- | | | 6. NACK | | | | <------------- | 7. NACK | | | | ---------------> | 8. NACK | | | | ------------> | | | | | Sequence diagram 3: Reservation request rejected by NF1 In the previous sequence diagrams the resources are reserved and commited in a single round trip. However, in certain scenarios it may be preferable to separate these two phases. For instance, in case of voice over IP, resources may be reserved (i.e. admission control) during call setup. When the receiver accepts the session the resources may be commited (e.g. creating a pinehole in a firewall, installing a policer). Note that this will require an additional round trip. There are two solutions to provide for this functionality: - Define an additional flag in the RESERVE message to indicate whether it reserves or commits the resources. - Define a new COMMIT protocol message. Sequence diagram 4 shows an example where the reserve and commit phases are seperated. In this example an additional COMMIT message is used. NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | | | 1. RESERVE | | | | -------------> | 2. RESERVE | | | | ---------------> | 3. RESERVE | | | | ------------> | | | | 4. ACK | Buchli et al. Expires - December 2003 [Page 6] A Network Service Layer Protocol for QoS June 2003 | | 5. ACK | <------------ | | 6. ACK | <--------------- | | | <------------- | | | // | 7. COMMIT | | | | -------------> | 8. COMMIT | | | | ---------------> | 9. COMMIT | | | | ------------> | | | | 10. ACK | | | 11. ACK | <------------ | | 12. ACK | <--------------- | | | <------------- | | | Sequence diagram 4: Separate reserve and commit of resources 5.2 Modification of reservation An existing reservation can be modified by either the NI or the NR. This is depicted in respectively sequence diagram 5 and 6. NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | | | 1. MODIFY | | | | -------------> | 2. MODIFY | | | | ---------------> | 3. MODIFY | | | | ------------> | | | | 4. ACK | | | 5. ACK | <------------ | | 6. ACK | <--------------- | | | <------------- | | | | | | | Sequence diagram 5: Modification initiated by QI NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | 1. MODIFY | | | 2. MODIFY | <------------ | | 3. MODIFY | <--------------- | | | <------------- | | | | 4. ACK | | | | -------------> | 5. ACK | | | | ---------------> | 6. ACK | | | | ------------> | | | | | Buchli et al. Expires - December 2003 [Page 7] A Network Service Layer Protocol for QoS June 2003 Sequence diagram 6: Modification initiated by QR 5.3 Teardown of reservation A reservation can be released by the NI (sequence diagram 7), the NR or an intermediate NF (sequence diagram 8). The latter may be the case if the NF determines that a neighbor is down. The response message (ACK) should have the tear-bit set such that the transport state is released. The TEAR message must not have the tear-bit set since the routing state is required for the response message. NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | | | 1. TEAR | | | | -------------> | | | | 2. ACK | | | | <------------- | | | | | 3. TEAR | | | | ---------------> | | | | 4. ACK | | | | <--------------- | | | | | 5. TEAR | | | | ------------> | | | | 6. ACK | | | | <------------ | | | | | Sequence diagram 7: Teardown initiated by the NI NSIS Initiator NSIS Forwarder1 NSIS Forwarder2 NSIS Responder | | | | | | 1. TEAR | | | | <--------------- | 2. TEAR | | | 3. ACK | ------------> | | | ---------------> | 4. ACK | | 5. TEAR | | <------------ | | <------------- | | | | 6. ACK | | | | -------------> | | | | | | | Sequence diagram 8: Teardown initiated by NF2 Buchli et al. Expires - December 2003 [Page 8] A Network Service Layer Protocol for QoS June 2003 6. Route changes and mobility An important requirement for the QoS signaling layer is to process route change and mobility events. The transport layer will detect these events and will trigger the client layer. The client layer is responsible to initiate the necessary actions to respond on a route change or mobility event; including the removal of transport/client state on the old path. 6.1 Rerouting Route changes should be detected by the transport layer. When a route change has been detected the transport layer should determine all sessions that are impacted. For each impacted session it will notify the associated client layer. When the QoS signaling client layer receives a trigger from the transport layer about a route change it will do the following: 1. Send a RESERVE message on the new route. The transport layer will detect that the next hop in the transport state differs from the current next hop. As a result it will create a new branch that includes the new next hop. When more than one outgoing branches are installed the signaling node becomes a branching point. The RESERVE message traverses towards the merging point, the point where the old and the new path merge again. Each intermediate signaling node should do admission control. A signaling node can detect that it is a merging point by the fact that there are two incoming branches with the same outgoing branch for a certain session. 2a. In case no resources are available on the new path the branching point will receive a NACK message. In that case it will send TEAR message in both the up- and downstream direction to release the session. 2b. In case the resources are available on the new path the client layer at the branching point will receive an ACK message. It will then send a TEAR message on the branch of the old path to remove the state at the signaling nodes between the branching and merging point. The route change has been processed now completely. This procedure for processing route changes is depicted in sequence diagram 9 for the topology of figure 2. Buchli et al. Expires - December 2003 [Page 9] A Network Service Layer Protocol for QoS June 2003 +-----+ +--+ NF2 +--+ / +-----+ \ / \ +-----+/ : \+-----+ ---+ NF1 | : | NF4 +--- +-----+\ v /+-----+ \ +-----+ / +---+ NF3 +---+ +-----+ Figure 2: Topology for route change scenario NF1 NF2 NF3 NF4 Route->| | | | change | 1. RESERVE | | | --------------------------------> | | | | | 2. RESERVE | | | | ------------> | | | | 3. ACK | | | | <------------ | | 4. ACK | | | <-------------------------------- | | | 5. TEAR | | | | -------------> | | | | 6. ACK | | | | <------------- | | | | | 7. TEAR | | | -------------------------------> | | | 8. ACK | | | <------------------------------- | | | | | Sequence diagram 9: Route change 6.2 Mobility with address changes Mobility events should be detected by the transport layer. This event is characterized by the change of the IP address of one of the end nodes. This may be the case for instance when a mobile node changes its care-of-address in case of Mobile IP. The main difference with a route change scenario is the fact that the flow ID (source, destination IP address) should be updated along the entire chain of NSIS entities that are involved with the session that has been impacted by a mobility event. In order to update the flow ID end-to-end the merging point may decide to: Buchli et al. Expires - December 2003 [Page 10] A Network Service Layer Protocol for QoS June 2003 - forward the RESERVE message further towards the destination, - send a signaling message without a client data object. It may be desirable to explicitly teardown the reservation at the old path. There are several possibilities here: - The end node still has connection with the old path and can send a TEAR message itself. - The Access Node (AN) detects loss of connectivity with the end node and sends a TEAR message to release the reservation on the old path. - The merging point will remove the reservation on the old path. It may be part of a standard procedure when it detects it is the merging point in case of a mobility scenario. Another option may be to use a flag that can be set by the end point in the RESERVE message that indicates that the merging point should release the reservation on the old path (similar to the dead-branch-removal flag in CASP). A mobility scenario is depicted in figure 3 and the associated signaling sequence diagram 10. +---+ +-----+ | S |----| AN1 |--+ +---+ +-----+ \ . \ . \+-----+ . + NF1 |--- v /+-----+ +---+ +-----+ / | S |----| AN2 |--+ +---+ +-----+ Figure 3: Topology for mobility event scenario S AN1 AN2 NF1 mob. ->| 1. RESERVE | | event | -------------------------------> | | | | | 2. RESERVE | | | | -------------> | | | | // Update Flow ID at remainder of path Buchli et al. Expires - December 2003 [Page 11] A Network Service Layer Protocol for QoS June 2003 | | | // | | | 3. ACK | | | | <------------- | | 4. ACK | | | <------------------------------- | | | | 5. TEAR | | | <------------------------------- | | | 6. ACK | | | -------------------------------> | | 7. TEAR | | | | <------------- | | | | 8. ACK | | | | -------------> | | | | | | | Sequence diagram 10: Mobility event Interaction with mobility protocols (Context Transfer, Fast Handover, etc.) is not considered in this version of the document. 7. Open issues - NAT traversal; the port numbers are not specified in the transport state anymore. If NAT devices are only NTLP aware only IP address translation can be used, NAPT (port translation) will not be possible. Should the source/destination port information be duplicated at the transport layer? - Is there a need for specifying both a desired and minimal bandwidth in the QoS object? What to do if upon a route change the new path can only support the minimal QoS and the rest of the path has allocated the desired QoS. How is the endpoint notified of this modification? Security Considerations Security is an important aspect for a (QoS) signaling protocol in order to prevent an adversary from utilizing resources without any authorization (e.g. theft-of-service). Since each signaling node involved with a certain session is assumed to support the specific client layer hop-by-hop security at the transport layer will be sufficient for most scenarios. At the client layer there may still be a need to secure certain objects that require other than hop-by-hop protection. For instance, when the client object contains an OSP token that provides Buchli et al. Expires - December 2003 [Page 12] A Network Service Layer Protocol for QoS June 2003 authorization from a clearinghouse there is a need for end-to- end/middle integrity of the object. More background on security threats and authorization issues can be found in [10] and [11]. Reference 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and Van den Bosch, S., "Next steps in signaling: Framework", Internet Engineering Task Force, draft-ietf-nsis-fw-02.txt, work in progress, March 2003. 4 Buchli, M., Waegeman, E., Van den Bosch, S., "Implementation of CASP NTLP", draft-buchli-nsis-ntlp-00.txt, work in progress, May 2003. 5 Schulzrinne, H., Tschofenig, H., Fu, X., McDonald, A., "CASP - Cross-Application Signaling Protocol", draft-schulzrinne-nsis- casp-01.txt, work in progress, March 2003. 6 Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog ,S., "Identity Representation for RSVP", RFC 2752, Internet Engineering Task Force, January 2000. 7 Hamer, L-N., Gage, B., Kosinski, B., Shieh, H., "Session Authorization Policy Element", RFC 3520, Internet Engineering Task Force, April 2003. 8 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. 9 Pan, P., Hahne, E., and Schulzrinne, H., "BGRP: Sink-tree-based aggregation for inter-domain reservations", Journal of Communications and Networks, Vol. 2, No. 2, pp. 157-167, http://www.cs.columbia.edu/pingpan/papers/bgrp.pdf, 2000. 10 Tschofenig, H., Kroeselberg, D., "Security Threats for NSIS", draft-ietf-nsis-threats-01.txt, work in progress, January 2003. Buchli et al. Expires - December 2003 [Page 13] A Network Service Layer Protocol for QoS June 2003 11 Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne, H., "NSIS Authentication, Authorization and Accounting Issues", draft-tschofenig-nsis-aaa-issues-01.txt, work in progress, March 2003. 12 Crocker, D. and Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Engineering Task Force, November 1997. Acknowledgments We would like to thank Philippe Dauchy and Sven Van den Bosch for their input on this work. Author's Addresses Maarten Buchli Alcatel Francis Wellesplein 1 B-2018 Antwerpen, BELGIUM Email: maarten.buchli@alcatel.be Eric Waegeman Alcatel Francis Wellesplein 1 B-2018 Antwerpen, BELGIUM Email: eric.waegeman@alcatel.be Alberto Conte Alcatel CIT Route de Nozay 91460 Marcoussis, FRANCE Alberto.Conte@alcatel.fr Appendix A: Object specification The client object as received from or sent to the transport layer has a common client object header and a variable number of objects. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [12]. A.1 Common client object header Buchli et al. Expires - December 2003 [Page 14] A Network Service Layer Protocol for QoS June 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------+-------+---------------+-------------------------------+ |Version| Flags | Msg-type | Length | +-------+-------+---------------+-------------------------------+ o Version: 4 bits Default value = 1 o Flags: 4 bits Reserved for future use. o Msg Type: 8 bits 1. Reserve 2. Path 3. Modify 4. Tear 5. Ack 6. Nack o Length: 16 bits Length of the Signaling objects in bytes, this length includes the common header. A.2 Common object header Each object within the client object consists of one or more 32-bit words with a one-word header with the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Length (bytes) | Class-Num | C-Type | +---------------+---------------+---------------+---------------+ | | // (Object contents) // | | +---------------+---------------+---------------+---------------+ An object header has the following fields: o Length: 16 bits The length field contains the total object length (excluding padding) in bytes, including the object header. o Class-Num: 8 bits Identifies the object class. The QoS NSLP must recognize the Buchli et al. Expires - December 2003 [Page 15] A Network Service Layer Protocol for QoS June 2003 following classes: QOS, REASON, and PRIORITY. o C-Type: 8 bits Object type, unique within Class-Num. Each object MUST be padded to align on a 32-bit (word) boundary, using the minimal number of additional bytes. The length of the padding is not included in the Length field of the object. A.3 QOS Class Is a list of microflow reservations, for every microflow a minimal and a desirable bandwidth is specified. The minimal bandwidth field should be ignored when set to zero. The number of microflows can be derived from the object length. QOS Class = 1. IPv4 QOS object: Class = 1, C-Type = 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | Source Port | Destination Port | +---------------+---------------+-------------------------------+ | Protocol | QoS Class | /// | +---------------+---------------+-------------------------------+ | Maximum bitrate (desirable) (32-bit IEEE floating point num) | +---------------------------------------------------------------+ | Maximum bitrate (minimal) (32-bit IEEE floating point num) | +---------------------------------------------------------------+ IPSec IPv4 QOS object: Class = 1, C-Type = 2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | SPI | +---------------+---------------+-------------------------------+ | Protocol | QoS Class | /// | +---------------+---------------+-------------------------------+ | Maximum bitrate (desirable) (32-bit IEEE floating point num) | +---------------------------------------------------------------+ | Maximum bitrate (minimal) (32-bit IEEE floating point num) | +---------------------------------------------------------------+ Buchli et al. Expires - December 2003 [Page 16] A Network Service Layer Protocol for QoS June 2003 IPv6 QOS object: Class = 1, C-Type = 3 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-----------------------+---------------------------------------+ | /// | Flow label (20 bits) | +---------------+-------+-------+-------------------------------+ | Protocol | QoS Class | /// | +---------------+---------------+-------------------------------+ | Maximum bitrate (desirable) (32-bit IEEE floating point num) | +---------------------------------------------------------------+ | Maximum bitrate (minimal) (32-bit IEEE floating point num) | +---------------------------------------------------------------+ o Protocol: 8 bits The IP Protocol Identifier for the data flow. For the IPv4 with IPsec FLOW_ID this should indicate either AH or ESP. o Source Port: 8 bits The UDP/TCP/SCTP (or similar) source port for the session. o Destination Port: 8 bits The UDP/TCP/SCTP (or similar) destination port for the session. o Flow Label: 20 bits The IPv6 flow label for the data flow. o Protocol: 8 bits The IP Protocol Identifier for the data flow. o QoS Class: 8 bits Values to be specified. o Maximum bitrate (desirable): 32 bits The desirable bitrate to be reserved for a data flow. o Maximum bitrate (minimal): 32 bits The desirable bitrate to be reserved for a data flow. A.4 REASON Class REASON Class = 2 Reason object: Class = 2, C-Type = 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ Buchli et al. Expires - December 2003 [Page 17] A Network Service Layer Protocol for QoS June 2003 | /// | Reason code | Reason value | +---------------+---------------+-------------------------------+ o Reason Code: 8 bits 1. Session ID Not Correct 2. Impossible routing 3. Resource shortage 4. Bad parameter 5. Preemption 6. Network fault 7. End-user disconnected 8. End of session Additional codes may be added in future. o Reason Value: 16 bits This field contains additional information about the reason. Its contents depend upon the Reason Code. For example for the Reason Code 4 (bad parameter) the Reason Value should indicate the class number of the wrong parameter. A Reason Value = 0 means ôno additional informationö. A.5 PRIORITY Class PRIORITY Class = 3 PRIORITY object: Class = 3, C-Type = 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | /// | Priority | +-------------------------------+-------------------------------+ o Priority: 16 bits This field indicates the priority of the reservation, e.g. a reservation that is used for an emergency call. According to local policy of a signaling node the message may receive preferential treatment. The priority codes are to be defined. Appendix B: Client object layout RESERVE: Buchli et al. Expires - December 2003 [Page 18] A Network Service Layer Protocol for QoS June 2003 ::= [] [] PATH: ::= [] [] MODIFY: ::= [] [] TEAR: ::= [] [] [] ACK: ::= [] [] NACK: ::= [] [] [] Buchli et al. Expires - December 2003 [Page 19]