Internet Engineering Task Force                                   Working Group
Internet Draft                                                   H. Schulzrinne
                                      Columbia U./Siemens/U. Goettingen/Siemens
3 March 2003
Expires: September 2003

        A Quality-of-Service Resource Allocation Client for CASP


   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

To view the list Internet-Draft Shadow Directories, see


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

     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

     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


     · 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

     · 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

     · 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

     · 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

     · 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

       - C-Type: 8 bits

         Object type, unique within Class-Num. Values are to be defined


         Indicates the minimum flowspec the application would accept.


         Indicates the maximum possible flowspec the application would

       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

B Authors' Address

Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027

Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich

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:

Jochen Eisl
Siemens AG
Otto-Hahn-Ring 6
81739 Munich

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

[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

[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

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]