Internet Engineering Task Force Working Group
Internet Draft H. Schulzrinne
Columbia U./Siemens/U. Goettingen/Siemens
draft-schulzrinne-nsis-casp-qos-01.txt
3 March 2003
Expires: September 2003
A Quality-of-Service Resource Allocation Client for CASP
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
Signaling resource reservations is one of the possible applications of
the Cross-Application Signaling Protocol (CASP). This document describes
a client protocol that supports per-flow resource reservation in both
sender- and receiver-directed modes operation.
H. Schulzrinne et. al. [Page 1]
Internet Draft CASP QoS 3 March 2003
1 Introduction
CASP-QOS is a client protocol for the Cross-Application Signaling
Protocol (CASP) [1]. It is one of a
family of CASP signaling client protocols (NSLPs) and offers per-flow
resource allocation and reservation.
CASP-QOS has the following properties:
Direction-neutral: The protocol supports both receiver-oriented and
sender-oriented reservations. In each mode, the non-reserving
side can suggest QoS parameters. For example, the data
receiver can send the first CASP message to indicate the range
of bandwidths and QoS parameters it is willing to tolerate,
but the data sender makes the actual reservation within that
range.
Bidirectional reservation: Bidirectional reservation refers to
three different modes of operation. In the first, there is a
single reservation message for both directions, i.e., a
traffic selector that specifies traffic flowing in both
directions, typically with reversed source and destination
address and port numbers. Such reservation is only feasible if
the route is symmetric. Its main advantage is atomicity, so
that a reservation in the forward direction is made only if
traffic in the backward direction can also be accomodated.
A second, looser form of bidirectional has messages from the
originator and the destination cause reservations to be set
up. As before, this requires symmetric routes for in-band
signaling messages and AS-symmetric routes for per-AS
reservation. As shown in [2], a majority of routes are not
symmetric at the AS level.
Thirdly, a reservation from the initiator may trigger an
independent signaling session from the responder to the
initiator. This mode works even if the data path is asymmetric
and requires no particular protocol support at the CASP
messaging layer.
CASP QOS supports all three modes.
Reservation range: To reduce the number of reservation message
exchanges, the bandwidth object contains a lower and upper
bandwidth range. Nodes attempt to reserve the highest amount
of resources below the maximum and update the amount
accordingly. Nodes with higher reservations than the path
H. Schulzrinne et. al. [Page 2]
Internet Draft CASP QoS 3 March 2003
minimum are updated on the return path.
Partial reservation: CASP-QOS messages can indicate whether they
are satisfied to obtain partial reservations, i.e.,
reservations that only succeed on some routers [3].
Query/reserve/commit mechanism: If desired, an end system can query
for available resources, reserve them and commit them. Only
committed resources can be used.
2 Operation
CASP-QOS defines five message types:
Query: The QUERY message determines if a particular path has
sufficient resources, but does not reserve or commit any
resources.
Reserve: The RESERVE message requests a particular reservation. It
generates a RESPONSE indicating the degree of success or
failure. It may request a COMMIT message. The RESERVE message
can also contain a response to an earlier reservation, thus
allowing bidirectional reservation with bifurcated paths in
one message exchange.
Commit: The COMMIT message commits resources reserved previously
with RESERVE if the reservation timestamp is the same as the
original reservation. If not, it creates and commits a new
reservation, removing the original one. A COMMIT message that
uses an existing reservation SHOULD NOT fail. Each COMMIT
message carries a BANDWIDTH object just in case it visits a
node that has not seen a RESERVE before.
Release: The RELEASE message releases all resources for this
session, regardless of the version. It generates a RESPONSE
indicating success or failure with the Status object.
Success: The SUCCESS response message indicates the requested
reservation has been succeeded (not needed if the destination
returns a Commit in response to a Reserve); includes sequence
number of Reserve or Commit.
Error: The ERROR response message indicates reservation has been
failed; may also release all resources already made for this
session. It includes a sequence number of the failed Reserve
or Commit message, and the node address where the Reserve or
Commit request failed.
H. Schulzrinne et. al. [Page 3]
Internet Draft CASP QoS 3 March 2003
There are two types of (QoS NSLP) states: Reserve state and Commit
state, established and refreshed by Reserve and Commit messages,
respectively. An Error message may remove both states, if a "removal"
indicator is provided.
Two examples for CASP-QoS operations are shown in Figure 1, where (a)
shows an example for sender-directed operations, while (b) illustrates a
possible handling of reservation failure and partial reservations.
3 Objects
CASP-QOS messages can carry objects described below.
3.1 Version (V)
The version indication is used to quickly determine which Resource
object is used in the session, and what semantics should be assumed for
that Resource object (FlowSpec).
3.2 Partial Reservation (P)
The Partial Reservation object describes how many failed reservations
are allowed before reservation attempts terminate. There are two up
counters that tally the number of routers where admission control
failed, including due to a failed admission control procedure, and the
number of routers where reservation could not be performed since the
node did not speak CASP or CASP-QOS. Two additional down counters are
set by the originating node to the maximum number of routers that can
fail or be indeterminate before the message fails.
4 Messages
The table below indicates which objects MAY (O), MUST NOT (--) or MUST
(M) appear in each message type.
Definitions of CASP-QoS message formats are give in Appendix A.
Object Abbr. Query Reserve Success Commit
Release Error
-------------------------------------------------------------------
Version V M M M -- M
Partial Reservation P O O -- O -- M
Bandwidth B M M -- M -- O
H. Schulzrinne et. al. [Page 4]
Internet Draft CASP QoS 3 March 2003
S NE(s) D S NE(s) NE D
| Reserve | | Reserve |
-------+--------------->|;initial +----------->|
^ | |;reservation| |;an NE can't offer
| | Success |;request | Error(R) | requested resources,
| |<---------------+ |<-----------|
| | |;reserved | |;it returns an Error
| | Commit | | |;with Removal flag on
| --+--------------->|;commit | . |;to remove resources
^ | |;the | . |;already reserved
R | | Success |;reservation| . |
| |<---------------+ | . |
| | | |;resources | |
| | | |;can be used| |;some time later, S
| R |. | | |;wants to reserve
V | |. Reserve | | Reserve(PR)|;if resource can be
------|-+--------------->| +----------->|;partially fulfilled
| | |;refresh | |
| | Success |;reserve | Success |
| |<---------------|;state |<-----------+
| | | | |;partial reservation
V | Commit | | Commit(PR) |;has been made
----+--------------->|;refresh +----------->|
| |;commit | |;commit the resources
| Success |;state | Success |;partially reserved
|<---------------+ |<-----------+
|. | | . |
|. Query | | . Query |
+--------------->|;query at |<-----------|;intermediate nodes
| |;any time | |;can also query
| Success |;is possible| Success |;resource status
|<---------------| +------------|;provided that
|. |;a report of| . |;it satisfies the
|. |;current | . |;security measures
|. |;available | . |
|. Release |;resources | . Release |
|--------------->| |----------->|;typically explicit
| |;finally | |;release message is
| Success |;release the| Success |;used; otherwise
|<---------------|;reserved |<-----------+;state will be
| |;resources | |;time out
a)Sender-directed reservation; b)Failure & partial reservations
Figure 1: Two CASP-QoS Examples
H. Schulzrinne et. al. [Page 5]
Internet Draft CASP QoS 3 March 2003
5 Resource Objects
A set of objects are used to request resources. Additional objects are
likely to be defined in the future. It is possible to include several
such objects if it is allowed for the CASP node to satisfy any one of
them, starting with the one listed first. The response indicates which
resource was used.
5.1 Bandwidth (B)
The Bandwidth object contains two bandwidth values, an upper and a lower
bound. Each node attempts to reserve the upper bound. If it obtains
resources that are below the upper bound and above the lower bound, it
updates the upper bound to that lower value. The return message then
updates all reservation to the upper bound seen by the destination.
Others have proposed a loss rate or explicit delay indication,
possibly with a violation probability. It is not clear that
there are scheduling and admission control mechanisms that can
usefully guarantee such behavior on a per-flow basis. Thus,
this memo does not include them.
5.2 PHB
The PHB object requests that traffic matching the traffic selector is
assigned a certain per-hop behavior, such as AF12 [4].
5.3 IntServ Flowspec
The IntServ Flowspec object describes reserved resources for Integrated
Services [5].
5.4 L2 Properties
The L2 object describes layer-two properties abstractly, such as "low
delay, but do not care about packet losses" or "high reliability". These
requests then set up specific link layer behavior. This feature
requires further study.
6 Local Information
Usually, QoS-related information is generated by a host and sent to a
peer representing the opposite terminating point of the path. The data
has significance all along the signalling path. CASP offers the
possibility to restrict the scope of signalling information to a section
of the path, e.g, to a specific AS or subnet within an AS. CASP-QoS
information can be added and deleted anywhere in the network. This path
H. Schulzrinne et. al. [Page 6]
Internet Draft CASP QoS 3 March 2003
is referred to as localized path. Local scoping has the advantage that
QoS signalling information can be limited to certain sections of the
path without the need for end-to-end transport. The localized path is
determined by a source node, which adds specific QoS signalling
information and a sink node, which deletes the data with local scope.
Authentication of source and sink node for the path segment is required
to enable message integrity for the carried QoS signalling data.
The transport of local information is useful for a number of
applications, some of which are enumerated below:
Authorization token: An authorization token is a CMS encapsulated
(digitally signed or encrypted) collection of objects. Such a
token can be included for example by a policy decision point
to allow other CASP nodes along the path (within the same
administrative domain) to execute policy based admission
control securely without need to retrigger a PEP<->PDP
communication. Furthermore linking authorization of protocols
is an other example. Protecting information which is relevant
and secured within a local domain only is possible.
DSCP (DiffServ codepoint): Specific codepoints may be used within
an AS for definition of a certain per-hop behaviour (PHB).
The codepoint may be set by an ingress router or by the end
host. The DSCP in this situation is valid within the local AS
and has to be mapped to a different value when entering the
next AS. A new mapping may be required because codepoint
values are used differently or there is no exact mapping of
the PHB between two neighbouring ASs.
Aggregation information: Information about the aggregation of
signalling state can be transferred between the aggregation
ingress and the aggregation egress point. This includes
information about granularity of aggregation and the role
(aggregation or de-aggregation) a node should act for a
specific flow
Reservation priority: Information about the reservation priority
may be shared along CASP-QoS capable nodes to determine the
priority of a resource reservation request in the packet
forwarding plane.
Accounting: Accounting and charging information (as authorization
tokens) can be distributed along the signaling path to enable
the creation of proper accounting records.
H. Schulzrinne et. al. [Page 7]
Internet Draft CASP QoS 3 March 2003
Operator information: Any kind of operator information may be
shared by CASP-QoS nodes along the signalling path.
There is an optional Local Object to carry local QoS information. Each
object carries an identification and a type indicator. The scope field
provides hints about the scope of the local data since the processing of
local data may depend on the current scope value. There is no syntax
definition for the object's data structure as part of the CASP-QoS
protocol. Following this concept much flexibility is given for the
syntax definition of local data, e.g the CASP-QoS protocol does not care
about the structuring of accounting information within a certain AS. As
well the determination of proper source and sink nodes for local data
has to be handled by some mechanism other than CASP-QoS.
Nesting of local information is possible, so that within a path segment
local data is transported and there is a further subsegment along the
same path which nests further local information. The local data is
associated with a scope level. Each CASP-QoS node depending on the value
of the scope has to decide whether it should process specific local data
or ignore it. With the example of nesting local information, the nested
path can be associated with a higher value for the scope field than the
original path. This way local data associated with the original path can
transparently pass the nested path. Each local object carries data for a
specific path or path segment avoiding the necessity to carry local data
with different scope in a single object.
7 Route Change and Mobility Considerations
The separation between M-layer state and C-layer state in CASP is
logically (and not physically). Hence a route change also requires to
create a new reservation along the new path until the merge point
(cross-over router) is reached. The separation between the Session ID
and the Traffic Selector enables the merge point to associate an
existing reservation with the Session ID provided by the incoming
signaling message. As a difference between a standard route change and a
mobility scenario the possibility of a Traffic Selector change should be
mentioned. Typically the former does not require signaling messages to
be forwarded beyond the merge point. The situation might be different in
case of mobility and the used Traffic Selector. Thus there is an
interaction with a micro/macro-mobility scheme. Using a micro-mobility
scheme which is able to trigger CASP would therefore further limit
double reservations and would speed the reservation setup time.
A signaling message initiator can request the deletion of the old
reservation (along the old path). deleting a reservation along an old
path might not always be desired. The initiator is thereby a CASP node
which detects the route change first. There are some reasons why such a
behavior might not be necessary or desired (for example bi-casting of
H. Schulzrinne et. al. [Page 8]
Internet Draft CASP QoS 3 March 2003
data traffic to both access routers).
Particularly of interest for Candidate Access Router (CAR) discovery is
the QUERY message which allows to discover the resource availability
information (and possibly reservations costs) along new candidate paths.
Subsequently a few basic mobility signaling message exchanges are
described. The first exchange covers a QoS reservation for upstream
traffic. Subsequently the implication for downstream traffic is
explained. Thereby the interworking with micro-mobility schemes is
briefly described based on Context Transfer and Hierarchical Mobile IP.
Figure 2 shows a message flow for an upstream reservation in CASP-QOS.
Initially a mobile node establishes state information (and a QoS
reservation) between the old access router (oAR) and the CN via several
routers along the path. The mobile node has obtained a care-of address
(oCoA) and might additionally have additional IP addresses for mobility
(e.g. home address). The implications of selecting a Traffic Selector
are discussed at the end of this section.
As soon as the mobile node detects a route change due to mobility (e.g.
based on a layer 2 trigger) mobility related protocols are triggered. A
CASP signaling message is required either triggered by the refresh timer
or by a mobility management component at the mobile node. The signaling
message establishes new state and a new reservation at the new access
router (because no existing state is found for the provided Session
Identifier). The signaling message is then forwarded until it reaches
the cross-over router (CR). The cross-over router is identified
automatically since it is the first node along the path where state
information identified with the provided Session ID exists. Security
issues (referred as Session/Reservation Ownership) are covered in [1]
since they are independent of a particular client layer protocol.
As previously mentioned it is possible (and sometimes desired) to remove
the old reservation. A dead-branch-removal flag allows the cross-over
router to trigger a RELEASE message along the old path. The signaling
message is then forwarded towards the CN. How far to forward depends on
the used Traffic Selector and on the micro-/macro-mobility scheme.
If reservations along the old path are not released then they time out
(soft-state principle). The lifetime of a reservation depends on the
selected refresh interval (lifetime) which is allowed to vary between
peers in the CASP chain.
Figure 3 shows a downstream reservation. Without mobility protocol
interaction data packets would simply follow the new path toward the new
care-of address. Hence the protocol interaction can be considered as a
H. Schulzrinne et. al. [Page 9]
Internet Draft CASP QoS 3 March 2003
<-- old path -->
oCoA +------------+
+-+ | Old Access | <
| | -------- | Router | --- > --- ^
+-+ | (oAR) | < Release
MN +------------+
|
| +-------+ +------+ < + -----+
| |HoA(MN)| | CR | --- > ---| CN |
V +-------+ +------+ < +------+
Query/Reserve /
nCoA ---> +------------+ /
+-+ | New Access | < /
| | -------- | Router | --- > ---/
+-+ | (nAR) | <
MN +------------+
<-- new path -->
Figure 2: Upstream Reservation due to Mobility
regular route change behavior. An interaction with a mobility protocol
would however enable a performance improvement. When a mobile node
transmits a Binding Update/Registration Request to update its mobility
binding for example at the MAP (in case of Hierarchical Mobile IP) then
such a message could be used to trigger a downstream reservation. As
described in the previous example the old reservation can also be
removed if desired. It is worth noting that the signaling message
exchange described in 2 cannot be used to trigger a downstream
reservation immediately since the two paths (and the cross-over point
for the upstream and the downstream traffic) might be different.
Figure 4 shows the implications for CASP when Context Transfer (CT) is
used. CT allows QoS and security state established at the old access
router to be forwarded to the new access router. Although various
performance improving techniques would be possible, a generic approach
would be to trigger the Context Transfer procedure and then to send a
CASP CREATE message to the new access router. Note that the new access
router could transmit this message on behalf of the mobile node.
Depending on the micro-mobility scheme and on the routes used by the
data traffic either a cross-over router appears somewhere along the path
(e.g. router R1) or in case of host-specific routes (and tunnels) which
forward traffic from the old to the new access router. CT would also
provide a simplification to the security aspects in the following three
H. Schulzrinne et. al. [Page 10]
Internet Draft CASP QoS 3 March 2003
+----+ +-----+
| MN +------------+ oAR +-----
+----+ +-----+
| Release
Movement <-----
|
|
|
| MN<->MAP +--+---+ + -----+
| Binding Update |----> | MAP +---------------+ CN |
| |-------- +--+---+ +------+
| |-------- /
v |------ /
+----+ +-----+ /
| MN +------------+ nAR +--------/
+----+ +-----+ Reserve
<------
Figure 3: Downstream Reservation due to Mobility
areas:
· Session Ownership would not cause problems for mobility in the
local domain since a proof of session ownership is possible by
comparing an incoming request from the mobile node with the
stored state at nAR in a similar manner as at oAR.
· The existing security association can be used without restarting
a new authentication and key agreement protocol run. This
provides performance improvements for mobility within an
administrative domain. A few IPSec Context Transfer protocol
proposals have already been proposed. Note that some adjustment
to a security association is necessary to reflect a new care-of
address.
· If a user was authorized for the indicated amount of resources
then it is fair to assume that this authorization is also valid
at other routers within the same domain. If the same amount of
resources are available at a different path might however be a
different issue. A query message could provide more information
about resource availability. Avoiding an other authorization step
with a possible involvement of a PDP, AAA and backend database is
likely to provide performance advantages.
H. Schulzrinne et. al. [Page 11]
Internet Draft CASP QoS 3 March 2003
+----+ +-----+
| MN +------------+ oAR +-----
+----+ +--+--+
| ^^
| ||
| ||
| ||
Movement Context
| Transfer +--+---+ + -----+
| || | R1 +---------------+ CN |
| || +--+---+ +------+
| || /
| || /
| || /
v vv /
+----+ +--+--+ /
| MN +------------+ nAR +-------/
+----+ +-----+
Figure 4: Context Transfer Implications
As a summary the goals of CASP (and NSIS in general) with regard to
mobility signaling can be characterized as follows:
· Whenever possible the signaling message exchange caused by
mobility should be kept local. This means that an end-to-end
state information update along the path should not be required.
· CASP is designed to work without requiring a specific micro-
and/or macro-mobility protocol. The protocol should therefore not
be strongly coupled with such a protocol. An interaction with
these protocols might be useful (as a trigger mechanism using an
API) to provide more efficient QoS reservations.
· Mobility management introduces elements and mechanisms which
modify routing. Hence it is important to have a mechanism which
allows Traffic Selector updates mid-path and mid-session.
· Avoiding double reservations between the cross-over router and
the correspondent node (for upstream reservations).
· Optionally removing a reservation between the cross-over router
and the old access router.
H. Schulzrinne et. al. [Page 12]
Internet Draft CASP QoS 3 March 2003
Finally it should be mentioned that the selection of Traffic Selector
values has some implications for signaling and security. If a regular
5-tuple is used then mobility is likely to require a signaling message
exchange along the path between the MN and the CN to adjust the Traffic
Selector. The same is true for a flow label and a regular end-to-end
IPSec protected data traffic. If macro- and/or micro-mobility scheme is
used and the Traffic Selector reflects this circumstance then a
signaling message exchange can be kept local. As noted in [6] an
adversary might use identity spoofing (in this case the header of ip
packets) to enable its own traffic to experience preferential treatment.
Marking of packets with DSCP is an extreme example which allows packet
treatment without having end point addresses in the identifier.
8 Security Considerations
CASP relies on the security mechanisms described in [1]. Securing the
messaging layer in a CASP peer-to-peer fashion is provided either by
IPsec or TLS. Non peer-to-peer protection of client layer objects is
provided by CMS which allows resource objects and related objects
defined in this document to be encapsulated and protected by CMS. Hence
no separate specification within CASP is necessary to describe the
format of these objects. This allows some flexibility in including
protected objects to link the authorization step of different protocols
(for example CASP and SIP) and to transport local information within
domains. The functionality described in [7] and [8] can be provided
without substantial protocol modification/extensions.
9 Open Issues
· CASP can use a Next object indicates the next request that the
receiver should generate if the request itself was successful.
For example, if a RESERVE message contains Next = COMMIT, the
receiver of the RESERVE commits the resources just reserved.
The Next request feature is a flexible concept. Is this degree of
flexibility desired?
· CASP can use a Priority object to indicate the priority of the
resource request. Depending on local policy, high-priority
requests may either be treated preferentially compared to those
with lower priority when queueing for resources or may be allowed
to preempt existing resource reservations with lower priority.
This facility may be used for emergency telecommunications
services. Local policy determines whether a particular user is
authorized to exercise a priority level.
· Advance reservation -- CASP-QOS allows to define the start and
end time of a resource reservation, to support advance
H. Schulzrinne et. al. [Page 13]
Internet Draft CASP QoS 3 March 2003
reservations. The Time object describes the time the resource
reservation is to be effective, expressed as a start and ending
time written in NTP time format. (TBD: One could express periodic
reservations in the style of iCal [9], but the complexity seems
unwarranted.) A start time of zero indicates an immediate start.
Note that the CASP state has to be maintained between the time
the first message is sent requesting the reservation and the end
of the reservation. A requestor SHOULD use a suitably long
lifetime. TBD: Should there be a notification to the initiator
at the beginning of the actual reservation that indicates a new,
lower refresh interval?
For resources related to conferences, it is often
insufficient to find out at the time of the conference
that resources are unavailable, after much effort has
been expended on agreeing on a common time. A reservation
for the first available time slot seems an attractive
service, but difficult to set up due to the need for
coordination.
· CASP-QOS, like CASP, can support source-specific multicast (SSM)
[10]. It does not support receiver diversity, reservation styles,
blockade states and NBMA next-hops. Note that some aspects of
reservation styles can be supported by appropriate traffic
selectors.
· Allow multiple types of resource objects in one request?
· Usage scenarios for non-repudiation need to be described.
· Interaction with accounting/charging and related protocols (for
example AAA) needs to be elaborated.
· Should there be a notification to indicate a change in refresh
interval?
· The usage of authorization tokens needs to be described in more
detail (message formats and an indication of useful objects).
· It might be useful to allow a traffic sink to ask the traffic
source to set up a resource reservation. The sink would send a
CASP request directly to the source, which would start a normal
CASP reservation. For some applications, this can be done
already, e.g., using SIP.
H. Schulzrinne et. al. [Page 14]
Internet Draft CASP QoS 3 March 2003
10 Acknowledgements
Robert Hancock provided useful feedback.
A CASP-QoS Message Formats
A CASP-QoS message consists of a common header, followed by a body
consisting of a variable number of variable-length objects, which are
identified as being of a particular type. The following subsections
define the format of the common header, the standard object header, and
the construction of CASP-QoS messages.
A.1 Common Header
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) |
+---------------+---------------+---------------+---------------+
|C R P U / / / /| Flow Identifier |
+---------------+---------------+---------------+---------------+
| |
+ +
| Flow |
+ Identifier +
| (continue, padded when necessary) |
+ +
| |
+---------------+---------------+---------------+---------------+
The fields in the common header are:
· Length. Indicates the length of the CASP message in bytes. This
includes the length of the common header (including the length
field itself).
· Flags: 8 bits
Currently four flags are defined:
- The Commit (C) bit indicates that the message receiver should
send back a Commit message in the opposite direction.
- The Removal (R) bit indicates that this message removes all
CASP-QoS state (Reserve and Commit states, if any) for the
H. Schulzrinne et. al. [Page 15]
Internet Draft CASP QoS 3 March 2003
CASP-QoS session. If not set, the message establishes or
refreshes CASP-QoS state.
- The Partial Reservation (P) bit requests that a partial
reservation is acceptable. If not set, the reservation from the
sender to the receiver should be tried if possible.
- The unsecure (U) (or "tainted") bit indicates that the message
has traversed a hop without channel security.
· Type: 8 bits The CASP-QoS message type. Currentl valid types are:
- Type 1: CASP-QoS Reserve Message
- Type 2: CASP-QoS Commit Message
- Type 3: CASP-QoS Release Message
- Type 4: CASP-QoS Success Message
- Type 5: CASP-QoS Error Message
· Flow Identifier
Contains information about the flow which should receive a
particular QoS treatment. It contains the IP addresses of the
data sender and data receiver, and possibly some additional
demultiplexing information (such as protocol type, source and
destination ports, SPI or flow label).
A.2 Object Formats
Each 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) //
| |
+---------------+---------------+---------------+---------------+
H. Schulzrinne et. al. [Page 16]
Internet Draft CASP QoS 3 March 2003
An object header has the following fields:
· Length: 16 bits
The length field contains the total object length in bytes,
including the object header.
· Class-Num: 8 bits
Identifies the object class; values of this field are to be
provided. Each object class has a name, which is always
capitalised in this document. A CASP-QoS implementation must
recognize the following classes:
- ERROR_NODE
Indicates the IPv4 or IPv6 address where a reservation failed.
- VERSION
Indicates which type of flowspec is used. This is used to
easily detect a new flowspecs, rather than including the
flowspec itself. Currently Version = 0 indicates IntServ
Flowspec.
- C-Type: 8 bits
Object type, unique within Class-Num. Values are to be defined
later.
- MINIMUM_FLOWSPEC
Indicates the minimum flowspec the application would accept.
- DESIRED_FLOWSPEC
Indicates the maximum possible flowspec the application would
desire.
The format of an IntServ Controlled Load FLOWSPEC is given as
follows. Note during a session, only one flowspec should be
included unless the user wants nodes to "upgrade" the reservation
if possible.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
H. Schulzrinne et. al. [Page 17]
Internet Draft CASP QoS 3 March 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 5 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 5 (Controlled-Load)
(d) - Length of controlled-load data, 6 words not including
per-service header
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including per-service
header
B Authors' Address
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Xiaoming Fu
Institute for Informatics
University of Goettingen
H. Schulzrinne et. al. [Page 18]
Internet Draft CASP QoS 3 March 2003
Lotzestrasse 16-18
37083 Goettinge
Germany EMail: fu@cs.uni-goettingen.de
Jochen Eisl
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Jochen.Eisl@icn.siemens.de
C Bibliography
[1] H. Schulzrinne, H. Tschofenig, X. Fu, and A. McDonald, "Casp -
cross-application signaling protocol," internet draft, Internet
Engineering Task Force, 2003. Work in progress.
[2] L. Amini and H. Schulzrinne, "Observations from router-level
internet traces," in DIMACS Workshop on Internet and WWW Measurement,
Mapping and Modeling, (Piscataway, New Jersey) , Feb. 2002.
[3] P. Pan and H. Schulzrinne, "Processing overhead studies in resource
reservation protocols," in 17th International Teletraffic Congress ,
(Salvador da Bahia, Brazil), Sept. 2001.
[4] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured
forwarding PHB group," RFC 2597, Internet Engineering Task Force, June
1999.
[5] J. Wroclawski, "The use of RSVP with IETF integrated services," RFC
2210, Internet Engineering Task Force, Sept. 1997.
[6] H. Tschofenig and D. Kroeselberg, "Security threats for nsis,"
internet draft, Internet Engineering Task Force, 2003. Work in
progress.
[7] L. Hamer, B. Gage, and H. Shieh, "Framework for session set-up with
media authorization," Internet Draft, Internet Engineering Task Force,
July 2002. Work in progress.
[8] L. Hamer, B. Gage, M. Broda, B. Kosinski, and H. Shieh, "Session
authorization for RSVP," Internet Draft, Internet Engineering Task
Force, July 2002. Work in progress.
[9] F. Dawson and D. Stenerson, "Internet calendaring and scheduling
core object specification (icalendar)," RFC 2445, Internet Engineering
Task Force, Nov. 1998.
H. Schulzrinne et. al. [Page 19]
Internet Draft CASP QoS 3 March 2003
[10] H. Holbrook and B. Cain, "Source-specific multicast for IP,"
Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in
progress.
H. Schulzrinne et. al. [Page 20]
Internet Draft CASP QoS 3 March 2003
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2 Operation . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Objects . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Version (V) . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Partial Reservation (P) . . . . . . . . . . . . . . . . . 4
4 Messages . . . . . . . . . . . . . . . . . . . . . . . . 4
5 Resource Objects . . . . . . . . . . . . . . . . . . . . 6
5.1 Bandwidth (B) . . . . . . . . . . . . . . . . . . . . . . 6
5.2 PHB . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3 IntServ Flowspec . . . . . . . . . . . . . . . . . . . . 6
5.4 L2 Properties . . . . . . . . . . . . . . . . . . . . . . 6
6 Local Information . . . . . . . . . . . . . . . . . . . . 6
7 Route Change and Mobility Considerations . . . . . . . . 8
8 Security Considerations . . . . . . . . . . . . . . . . . 13
9 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 13
10 Acknowledgements . . . . . . . . . . . . . . . . . . . . 15
A CASP-QoS Message Formats . . . . . . . . . . . . . . . . 15
A.1 Common Header . . . . . . . . . . . . . . . . . . . . . . 15
A.2 Object Formats . . . . . . . . . . . . . . . . . . . . . 16
B Authors' Address . . . . . . . . . . . . . . . . . . . . 18
C Bibliography . . . . . . . . . . . . . . . . . . . . . . 19
H. Schulzrinne et. al. [Page 1]