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
<Reserve client object> ::= <Common Header> <QoS class>
[<Policy Data>] [<Priority>]
PATH:
<Path client object> ::= <Common Header> <QoS class>
[<Policy Data>] [<Priority>]
MODIFY:
<Modify client object> ::= <Common Header> <QoS class>
[<Policy Data>] [<Priority>]
TEAR:
<Tear client object> ::= <Common Header> [<Reason>]
[<Policy Data>] [<Priority>]
ACK:
<Ack client object> ::= <Common Header> <QoS class>
[<Policy Data>] [<Priority>]
NACK:
<Nack client object> ::= <Common Header> [<Reason>]
[<Policy Data>] [<Priority>]
Buchli et al. Expires - December 2003 [Page 19]