[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                      Stefano Salsano
October 2001                            Univ. of Rome "Tor Vergata"
Expiration: May 2002
File: draft-salsano-cops-dra-00.txt


     COPS Usage for Diffserv Resource Allocation (COPS-DRA)


     Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."


The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

     Copyright Notice
Copyright (C) The Internet Society (2001).  All Rights Reserved.


     Abstract

This document introduces a new client type for the COPS protocol to
support dynamic DiffServ resource allocation. The client type supports
both the Outsourcing and the Provisioning model to achieve a scalable,
efficient and flexible handling of network resources. The defined client
type can be used: i) on the interface between an Edge Router (Policy
Enforcement Point - PEP) and a Diffserv "Bandwidth Broker" (acting as
Policy Decision Point -PDP); ii) on the interface between a client of a
QoS enabled network (acting as PEP) and the access point of the network
provider (e.g. the Edge Router acting as PDP)





Salsano                    Expires Ma 2002                           1

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01



     Table of Contents

Abstract........................................................1
Glossary........................................................2
1. Introduction ................................................3
2. COPS-DRA: analysis of requirements ..........................4
3. COPS-DRA protocol operations ................................6
4. Message Content .............................................8
5. COPS-DRA Protocol Objects ...................................12
6. COPS-DRA Client-Specific data format ........................18
7. Security Considerations .....................................21
8. IANA Considerations .........................................21
9. Illustrative examples for COPS-DRA client ...................21
10.References ..................................................23
11.Author Information and Acknoledgements ......................24
APPENDIX: Discussion on Provisioning and Outsourcing models

Glossary

BB      Bandwidth Broker
ER      Edge Router
COPS    Common Open Policy Service. See [COPS]
PDP     Policy Decision Point. See [RAP]
PEP     Policy Enforcement Point. See [RAP]
RAR     Resource Allocation Request




























Salsano                    Expires May 2002                          2

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01



1.         Introduction


The COPS (Common Open Policy Service) protocol [COPS] is a simple query
and response protocol that allows policy servers (PDPs) to communicate
policy decisions to network devices (PEP). In order to be flexible, the
COPS protocol has been designed to support multiple types of policy
clients. Each client-type can be described in a different usage draft.
The purpose of this draft is to describe the use of COPS for dynamic
resource allocation in a Diffserv network. The new client-type is called
"COPS-DRA" (COPS- Outsourcing Diffserv Resource Allocation). This work
extends the previously defined client type which was called "COPS-ODRA"
(COPS- Outsourcing Diffserv Resource Allocation) [COPS-ODRA]. While
COPS-ODRA was only based on the outsourcing model, COPS-DRA combines the
outsourcing and provisioning model, providing a scalable, flexible and
efficient handling of network resources.

The COPS-DRA signaling mechanisms can be used on two different logical
interfaces:
i) On the interface between an Edge Router and the Diffserv "Bandwidth
   Broker" in order to handle the allocation of resources and to
   request the admission of new flows. In this case the Edge Router
   acts as PEP and the Bandwidth Broker as PDP.
ii)On the interface between a QoS client of a QoS enabled network and
   the access point of this network in order to signal dynamic request
   for QoS flows. In this case the QoS client acts as PEP and the
   network access point (e.g. the provider Edge Router) acts as PDP.

The requirements for the signaling mechanisms to be used on these
interfaces are different, yet they are related for a large extent. COPS-
DRA has been defined taking into account the superset of both types of
requirements in order to be used on both types of interfaces. Figure 1
below depicts a scenario for COPS-DRA.

                                 .--------.
                                 | PDP/BB |
                                 |        |
                                 '--------'
                                     |
                                     |
                                    /   COPS-DRA
                                   /
                                  /
      .------.                .------.
      | QoS  |    COPS-DRA    | Edge |
      |Client|<-------------->|Router|
      '------'                '------'

Figure 1: COPS-DRA to support dynamic Diffserv based IP QoS




Salsano                    Expires May 2002                          3

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


2.        COPS-DRA: analysis of requirements

2.1 Combination of Outsourcing and Provisioning

The use of a server to control the admission of traffic within a
Diffserv domain has been considered since the very beginning of the
discussion about the Diffserv architecture [2BIT]. The admission control
server is typically referred to as Bandwidth Broker (BB).
The communality between the BB and the PDP are described in [BBREQ]

Let us consider first the use of COPS-DRA on the interface between Edge
Device and the Bandwidth Broker. The Bandwidth Broker will be denoted by
PDP/BB. An intra-domain scenario is assumed, where the PDP/BB is in
charge of controlling resource for a network in a single administrative
domain. Note that [BBop] and [UCLA-BB] generically discusses the use of
COPS for resource admission control in a Diffserv network, but no
protocol definition is provided.

Two main models are supported by the COPS protocol: Outsourcing and
Provisioning. The reader is referred to [COPS-ODRA] sec. 1, for an
introduction to the Outsourcing and Provisioning models (for
convenience, the related text in [COPS-ODRA] is reported in the Appendix
of this document).

The COPS-ODRA was only based on the Outsourcing model. The advantage is
that a very efficient usage of resources can be achieved. The problem is
the scalability. While some mechanisms were introduced to aggregate
state information to achieve scalability in state information storage,
the scalability in terms of signaling messages was not achieved. In
particular a specific message is needed from the PEP to the PDP to
handle each single flow.

A model based on provisioning is much more scalable with respect to
signaling: there is no exchange of signaling messages related to single
requests. COPS-PR [COPS-PR] has been proposed to handle resources under
the provisioning model: the PDP installs configuration decisions so that
the client is able to handle events locally. If a "pure" provisioning
methods is used, it can be impossible, or inefficient to handle requests
for large amount of resources. If one wants to include outsourcing in
COPS-PR, the model is not so flexible: it is difficult to handle
modification of configured parameters in response to events like
resource requests (each modification is handled as a request for a new
configuration). It is even more difficult to handle single "special"
incoming request with the help of the PDP/BB.

From this analysis we derive the following three requirements for the
combined model of COPS-DRA:
i) it should offer the capability of provisioning resources to local
   nodes, in order to avoid high signaling burden;
ii)it should be easy for the local node to request the modification
   (increase, decrease) of the provisioned resource;
iii)    it should be possible to handle specific requests under the
   Outsourcing model.

Salsano                    Expires May 2002                          4

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01



Let us consider now the QoS client to QoS provider interface. On this
interface the QoS client sends QoS reservation requests to the provider,
who is in charge to accept or reject the request. In a typical scenario,
considering that the provider will not distribute resources in advance
to its clients, only the outsourcing model is relevant.

2.2 Components of the reservation requests.

The Resource Allocation Requests on the Edge Router to PDP/BB interface
are required to carry at least these two components (as already
mentioned, an intra-domain QoS scenario is assumed):

i) scope and amount of reservation (i.e. where the reservation applies
   and which is the required bandwidth)
ii)type of requested service (possibly including a set of QoS
   parameters)

On the basis of these two components, the admission control function can
be performed. Considering the QoS client to QoS provider interface, the
reservation request should contain an additional component:

iii)    flow identification (i.e. to which IP flow or aggregate of flows
   the reservation applies)

The QoS provider needs this information for operations related to the
access interface like classification, policing ecc.

More complex scenarios may require the addition of specific parameters
to these three components or the definition of further components in the
reservation request. As an example the "timing" of reservation
(immediate reservation, advance reservations and so on) has not been
considered in the three mentioned components. Work is ongoing to propose
a commonly agreed definition of the semantic content of reservation
requests, but this work is in a very early stage [SLS-INT]. For COPS-DRA
we took a pragmatic approach and a simple scenario has been considered
in order to derive the requirements:

i) the scope of the reservation is identified by an ingress and an
   egress point in the QoS enabled network and the amount of needed
   resource is identified by a traffic descriptor (e.g. a bandwidth in
   bytes/s, a token bucket...);
ii)the type of requested service is either a Diffserv code point or an
   index to a previously agreed list of services.
iii)    for the flow identification the source and destination IP
   addresses and TCP/UDP ports can be used;

Note that, thanks to its extensibility, further functionality may be
added to COPS DRA in a later stage.





Salsano                    Expires May 2002                          5

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


3.     COPS-DRA protocol operations


This section describes the interaction between a PDP and Diffserv
Resource Allocation COPS client.

3.1.   Start of operations

In order to start operations, the PEP must open the dialogue with its
PDP/BB. First, a TCP connection is established between the client and
server and the PEP sends a Client-Open message with the Client-Type =
COPS-DRA. If the PDP supports this client type, it responds with a
Client-Accept (CAT) message. If the client type is not supported, a
Client-Close (CC) message is returned by the PDP to the PEP. After
receiving the CAT message, the PEP can send requests to the server.

If the PEP will use the combined outsourcing and provisioning model
(typical case for the Edge Router to PDP/BB interface), it can send a
special "configuration request" to ask the PDB/BB to provide the initial
provisioning information. This message is a special case of the Resource
Allocation Request message described in the following subsection.

3.1 Common operations

Following the terminology in [BBREQ], the PEP will send "Resource
Allocation Requests" (RAR) to the PDP/BB once the connection is
established.

There are three types of Resource Allocation Requests:

-  Outsourced RAR
-  Aggregated RAR
-  Configuration RAR

A field in the Context object of the COPS-DRA Request message
discriminates among the three types.

The Outsourced RARs represent the requests for a single specific flow,
for which the PEP is outsourcing the admission control decision to the
PDP. The Aggregated RAR is a request for an amount of resources (i.e.
bandwidth) from an ingress point to an egress point that can be used by
the PEP to accommodate a set of flows. The Configuration RAR is sent by
the PEP at the beginning of the dialogue with the PDP, in order to
request provisioning information. This information is a set of allocated
resources (i.e. bandwidth) for ingress/egress points couples.

The Outsourced and Aggregated Resource Allocation Requests will always
contain:
-  scope and amount of reservation (e.g. ingress point and egress point
   in the Diffserv domain, bandwidth): see IPA, EPA and TD objects in
   section 5



Salsano                    Expires May 2002                          6

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


-  the type of the requested resource (e.g. the Diffserv code point or
   an index to a previously agreed list of services): see Rtype objects
   in section 5

When used on the QoS client to QoS provider interface, the Outsourced
Resource Allocation Requests may contain:
-  the flow identification information (e.g. source and destination IP
   addresses and TCP/UDP ports): see FlowIDI object in section 5

Outsourced and Aggregated RARs are used to release and to modify the
reservations, as explained in section 4.

The Outsourced and Aggregated RARs are used by the PDP to perform the
Admission Control procedure. According to the requirements of the
requested service, the PDP/BB will properly map the requested edge-to-
edge resources into network resources and will assure that such
resources are available throughout the Diffserv cloud. The discussion of
the Admission Control algorithms in the PDP/BB, of the mechanisms used
by the PDP/BB to get topological/routing information from the Diffserv
domain and the mechanism that could be used to actively control the
Diffserv routers are outside the scope of this document.

In response to the Outsourced and Aggregated RARs, the PDP sends a reply
where it accepts or rejects the RAR. On receiving the answer, the PEP
may activate its local QoS mechanisms as needed.

The Configuration RARs can either carry no specific request or a list of
Ingress / Egress couples and related requested resources. The PDP will
reply with a Decision message containing the set of Ingress / Egress
couples and allocated resources. Note that the list contained in the
Request message is only additional information that can be used by the
PDP. The PEP will simply install the information received by the PDP and
there is no acceptance / refusal of a Configuration RAR.


3.2 State information in PEP and PDP/BB

The COPS protocol is stateful in the sense that Request/Decision state
is shared between PEP and PDP. Depending on the COPS client type, one or
multiple states can be installed in the context of a single PEP/PDP
relationship. The "handle" object uniquely identifies a single installed
state at the PEP and at the PDP side. For example in case of RSVP client
type [COPS-RSVP], a different state is installed for each RSVP flow
(actually one PATH state and one RESV state). This implies that a lot of
state information is duplicated in the PEP and in the server.
In COPS-DRA the state information is aggregated as much as possible: the
state represents the set of resources allocated by the PDP/BB to a PEP.
Therefore a unique value for the handle object is used in the context of
a single PEP/PDP relationship. The handle is inserted by the PEP in the
first request and then it is used in every message by the PEP and by the
PDP/BB.
The state information in the PDP/BB is represented by the set of the
triples (resource type, ingress point, egress point) and the

Salsano                    Expires May 2002                          7

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


corresponding amount of allocated resources, per each different resource
type. The PDP/BB keeps this state information separately for each
different COPS-DRA client (i.e. for each connected PEP). The requests
for the same resource type, ingress point, egress point coming from the
same PEP are properly composed by the PDP/BB so that the aggregate
information is stored. The resources allocated for the outsourced
requests could to be recorded separately from those allocated for the
aggregated request.

This aggregate state information stored in PDP/BB is logically shared by
the PEP in the sense that it is the result of the sequence of Request
messages sent and of the Decision messages received. There is no need in
the PEP to evaluate and store the aggregate state information for
outsourced request: the client side (PEP) stores a set of "per flow"
outsourced reservation information. Moreover, the state for the
aggregated request is recorded separately from the state for outsourced
requests.

Temporary state information per each request must be stored in the PEP
and in the PDP/BB in order to correlate requests with decisions. To this
purpose the notion of request ID is needed and a corresponding client
specific protocol object is defined (see section 4). This temporary
information is deleted in the PDP/BB when the Decision message is sent
and in the PEP when this message is received.

3.3 Synchronization

Synchronization procedures are foreseen in COPS specification to cover
failure situations. The basic idea is that the PDP/BB can "reset" the
state and ask the PEP to rebuild it by sending proper resource
allocation Request messages. As for the "per-flow" state related to
outsourced requests, the PEP will send one Request message for each
active reservation. As for the aggregate state related to aggregated
request, the PEP will send aggregate Resource Allocation requests.
Selective re-submissions (i.e. for resource type, ingress or egress
point) can be supported.


4.       Message Content


The COPS protocol enables different COPS clients to define their own
"named", i.e. client-specific, information for various messages. This
section describes the messages exchanged between a COPS server (PDP) and
COPS DRA clients (PEP) that carry client-specific data objects.

4.1 Request (REQ)  PEP -> PDP

The REQ message is sent by COPS-DRA clients to issue a Resource
Allocation Request (RAR) to the PDP.

The Resource Allocation Request REQ is used to request new resources, to
modify a previous reservation, to release a reservation. It is used both

Salsano                    Expires May 2002                          8

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


for outsourced request related to single flows and for aggregated
request whose resources are used for a set of flows. The Resource
Allocation Request REQ is also used to issue a configuration request to
the PDP.

The Client Handle associated with the REQ message originated by the DRA
client must be unique for that client but otherwise has no protocol
significance at this time.

The context object specifies the types of request (Outsourced,
Aggregated, Configuration) and the requested operation (Add, Release,
Modify). See the description of Context object.

The Client Specific info object is used to specify the requested
resources and the request identifier.

The Outsourcing RAR REQ message contains a resource request for a single
flow. The PDP responds to the resource allocation request with a DEC
message containing the answer to the query.

The Aggregated RAR REQ may contain resource requests for more than an
aggregated flow (i.e. more than one record with ingress/egress point,
requested bandwidth, type of service). The PDP accepts or rejects the
requests as a whole with a DEC message.

The Configuration RAR REQ message contains a (possibly empty) set of
resource requests for aggregated flows. The PDP responds to the resource
allocation request with a DEC message containing the set of allocated
resources: the answer does not represent an acceptance / rejection of
the request.


The REQ message has the following format:

<Request> ::= <Common Header>
              <Client Handle>
              <Context = resource allocation>
              [<ClientSI: RAR data>]
              [<Integrity>]

Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are not
included in a COPS-DRA REQ message.
Note that resource allocation request messages can be generated and sent
to the PDP in response to the receipt of a Synchronize State Request
(SSQ) message.

4.2   Decision (DEC)  PDP -> PEP

The DEC message is sent from the PDP to a COPS-DRA client in response to
the REQ message received from the PEP. Unsolicited DEC messages cannot
be sent for this client type (therefore the solicited decision flag is
always set).


Salsano                    Expires May 2002                          9

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


The Client Handle must be the same Handle that was received in the REQ
message (it is identical for all requests).

The Decision object will contain in the Client Specific info the Request
ID, which is needed by the PEP to correlate the reply with the query.

Each DEC message contains a single decision.

The DEC message for the COPS-DRA client type has the following format:

<Decision Message> ::= <Common Header>
                       <Client Handle>
                       <Decision> | <Error>
                       [<Integrity>]

The decision object in turn has the following format:

<Decision> ::= <Context>
               <Decision: Flags>
               <Decision: Client SI data>

The context object will be the same as contained in the REQ message.
The Decision: Flags object will contain the answer in the Command-code
field according to the COPS specifications. In particular the Command-
code will be "Install" to mean a positive answer and "Remove" to mean a
negative answer. The following text clarifies how Install and Remove
Decisions map into the different request types, for Decisions related to
Outsourced and Aggregated RARs.


REQ (Context = Outsourced/Aggregated, Add)

     DEC (Dec Flag = Install) -> The requested resources are
                                 successfully allocated

     DEC (Dec Flag = Remove)  -> The requested resources are not
                                 allocated


REQ (Context = Outsourced/Aggregated, Release)

     DEC (Dec flag = Install) -> The resources are released

     DEC (Dec Flag = Remove)  -> The resources are still allocated.
                                 (This is syntactically correct, but
                                 it makes no sense)


REQ (Context = Outsourced/Aggregated, Modify)

     DEC (Dec flag = Install) -> The modification is accepted. The
                                 newly requested resources are
                                 allocated, while the previous ones

Salsano                    Expires May 2002                         10

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


                                 have been released

     DEC (Dec Flag = Remove)  -> The modification is not accepted. The
                                 previous allocation is still active.
                                 (This also makes sense only if the
                                 modification increases the allocated
                                 resource)

When the Decision message is related to a Configuration RAR, the answer
will always be an Install message:

REQ (Context = Configuration)

     DEC (Dec Flag = Install) -> The set of allocated resources is
                                 given in the message

The Error object is used to communicate COPS protocol error to the PEP,
according to the definition in [COPS]. No client specific error sub-
codes are used by COPS-DRA.

No report is sent by the PEP to confirm the reception of a Decision
message related to Outsourced / Aggregated RAR. Only in case of specific
errors, the PEP will send back a Report State message to the PDP/BB.

When a Decision message related to a Configuration RAR is received by
the PEP, the PEP must send a Report State Message notifying the success
or failure in accepting the allocated resources.


4.3 Report State (RPT)  PEP -> PDP

For COPS-DRA client type, the Report State message is sent by the PEP to
the PDP when receiving a Decision message related to a Configuration RAR
or in case of problems with a received Decision message. In particular,
it is used to communicate that the Decision contains a Request
identifier that cannot be correlated to a previous request. This event
is the manifestation of abnormal behavior. On reception of such Report
State message the PDP could start a Synchronization procedure.

The RPT message for the COPS-DRA client type has the following format:

<Report State Message> ::= <Common Header>
                           <Client Handle>
                           <Report Type>
                           <ClientSI: Req ID>
                           [<Integrity>]


4.4 Synchronize State Request (SSQ)  PDP -> PEP

The Synchronize State Request message is sent by the PDP to the PEP to
"reset" the state information. It requests the PEP to send the set of
resource allocation REQ messages needed to rebuild the state. The SSQ

Salsano                    Expires May 2002                         11

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


can apply to the whole set of PEP active reservations PEP, or to a
specific resource type and ingress-egress couple, depending on the
information contained in the Client SI object.

< Synchronize State> ::= <Common Header>
                         <Client Handle>
                         <ClientSI: SSQ scope>]
                         [<Integrity>]

Note that the COPS specification in [COPS] does not foresee a ClientSI
object in the SSQ message.

4.5 Synchronize State Complete (SSC)  PEP -> PDP

The Synchronize State Complete message is sent by the PEP to the PDP to
inform that all the REQ messages needed to rebuild the state have been
sent. The Client SI object is the same received in the SSQ message and
specifies the scope of the synchronization procedure which has been
completed.

< Synchronize State Complete> ::= <Common Header>
                                  <Client Handle>
                                  <ClientSI: SSQ scope>]
                                  [<Integrity>]

Note that the COPS specification in [COPS] does not foresee a ClientSI
object in the SSC message.


5.       COPS-DRA Protocol Objects


A new COPS client type for the policy provisioning client is defined:

   Client Type = 0x4002; Diffserv Resource Allocation Client (DRA
Client)

COPS messages sent between an DRA client and a COPS server contain a
COPS Common Header with this DRA Client type specified:

        0                 1                2               3
+---------------+---------------+---------------+---------------+
| Version| Flag |    Op Code    |     Client Type = 0x4002      |
+---------------+---------------+---------------+---------------+
|                        Message Length                         |
+---------------+---------------+---------------+---------------+


The COPS-DRA uses new COPS protocol objects that carry client-specific
information. This section defines those new objects.


The format for these new objects is as follows:

Salsano                    Expires May 2002                         12

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01



S-Num and S-Type are similar to the C-Num and C-Type used in the base
COPS objects. The difference is that S-Num and S-Type are used only for
ClientSI specific objects.

Length is a two-octet value that describes the number of octets
(including the header) that compose the object. If the length in octets
does not fall on a 32-bit word boundary, padding must be added to the
end of the object so that it is aligned to the next 32-bit boundary
before the object can be sent on the wire. On the receiving side, a
subsequent object boundary can be found by simply rounding up the
previous stated object length to the next 32-bit boundary.

5.1 Request ID Object (ReqID)

The Request ID object is used to correlate the Requests sent by the
COPS-DRA client with the responses coming from the PDP/BB. The ReqID
object is chosen by the PEP and it is opaque to the PDP/BB. A different
ReqID object is chosen by the PEP for each Request.
The ReqID object is carried in the Client Specific Information Object
for Request message (PEP -> PDP) and in the Decision ClientSI Data
Object (PDP -> PEP).
If the PEP receives a Decision with an unrecognized ReqID object, it
will send a Report State Message to the PDP to communicate the error.

S-Num = 1, S-Type = 1

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 1    |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|                         Request ID                            |
+---------------+---------------+---------------+---------------+

5.2 Ingress Point Address (IPA)

This object specifies the address of the Ingress Point into the Diffserv
domain.
The IPA object is carried in the Client Specific Information Object.
In a typical scenario the Ingress point coincides with the requesting
PEP itself.

S-Num = 2

S-Type = 1, Ipv4 Address.

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 2    |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|                       IPv4 Address format                     |
+---------------+---------------+---------------+---------------+


Salsano                    Expires May 2002                         13

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01



S-Type = 2, Ipv6 Address.

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 2    |  S-Type = 2   |
+---------------+---------------+---------------+---------------+
|                                                               |
+                                                               +
//                      Ipv6 Address format                    //
+                                                               +
|                                                               |
+---------------+---------------+---------------+---------------+

5.3 Egress Point Address Object (EPA)

This object specifies the address of the Egress Point from the Diffserv
domain.
The EPA object is carried in the Client Specific Information Object.


S-Num = 3

S-Type = 1, Ipv4 Address.
S-Type = 2, Ipv6 Address.

See Ingress Point Address for object coding.

5.4 Resource Type Object (RType)

This object specifies the type of the requested resources. The Rtype
object is carried in the Client Specific Information Object.
There are different ways to express the type of service. For this
purpose different "S-Type" are defined for this purpose. A possibility
is to specify an index to a pre-agreed list of services. The mechanisms
for the PEP and PDP to agree on this list of services are not covered by
this document. Another possibility is to specify a DS code point. When
Diffserv edge-to-edge services (Per-domain-behaviors) will be defined,
an additional "S-Type" could be defined.

S-Num = 4

S-Type = 1 Diffserv Codepoint (DSCP)

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 4    |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|           //////////////////////////          | // |   DSCP   |
+---------------+---------------+---------------+---------------+




Salsano                    Expires May 2002                         14

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


S-Type = 2 Index to an agreed list

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 4    |  S-Type = 2   |
+---------------+---------------+---------------+---------------+
|                               |             Index             |
+---------------+---------------+---------------+---------------+


5.5 Traffic Descriptor Object (TD)

This object specifies the amount of the requested resources.
The TD object is carried in the Client Specific Information Object.

S-Num = 5

S-Type = 1 (Bandwidth)

       0                1               2               3
+---------------+---------------+---------------+---------------+
|             Length            |  S-Num = 5    |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|                       Bandwidth (bytes/s)                     |
+---------------+---------------+---------------+---------------+

This description can be used if there is not a more accurate indication
on the policing at the ingress interface.

S-Type = 2 (Token Size and Measurement Interval)

       0                1               2               3
+---------------+---------------+---------------+---------------+
|             Length            |  S-Num = 5    |  S-Type = 2   |
+---------------+---------------+---------------+---------------+
|                       Token Size (bytes)                      |
+---------------+---------------+---------------+---------------+
|                    Measurement Interval (msec)                |
+---------------+---------------+---------------+---------------+

This description can be used if there is an indication on the policing
at the ingress interface. This information could be used by the PDP/BB
in the admission control algorithm.

5.6 Reject Reason Object (RejRea)

The RejRea object is used to provide the reason for a negative Decision.
It is carried in the Decision Client SI Data object.






Salsano                    Expires May 2002                         15

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


S-Num = 6, S-Type = 1

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 6    |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|           //////////////////////////          |  Reason code  |
+---------------+---------------+---------------+---------------+

Reason codes are:

Reason code = 1 : Resource unavailable
Reason code = 2 : Unsupported resource type
Reason code = 3 : Unacceptable Ingress Point
Reason code = 4 : Unacceptable Egress Point

5.7 Synchronize State scope (SSscope)

The SSQscope object is used to specify the scope of a Synchronize State
operation. The SSQscope object is carried in the Client Specific
Information Object for the SSQ and SSC messages.

S-Num = 7, S-Type = 1

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 7    |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|           //////////////////////////          |     Scope     |
+---------------+---------------+---------------+---------------+

Allowed value for Scope field are:

0 : Generic scope
1 : Specific scope

If the Scope is Generic, the Synchronize State operation refers to the
whole set of resource types and ingress-egress pairs.
If scope is Specific, the Synchronize State Request refers to the
specific resource type and ingress-egress pair contained in the rest of
the ClientSI Object for SSQ and SSR messages (see section 4).

5.8 Flow Identification Information (FlowIDI)

This object is a container for the flow identification information. It
will contain a Flow Reference ID (FRID) which is used to correlate
subsequent requests related to this flow and the SIPA, DIPA, SP and DP
objects, defined hereafter.






Salsano                    Expires May 2002                         16

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


S-Num = 16, S-Type = 1: Basic 4 fields identification

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 16   |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|                                                               |
                    <FlowIDI S-type 1 Content>
|                                                               |
+---------------+---------------+---------------+---------------+

<FlowIDI S-type 1 Content> ::= <Flow Reference ID>
                               [<Source IP Address>]
                               [<Destination IP Address>]
                               [<Source Port>]
                               [<Destination Port>]

The defined S-Type "Basic 4 fields identification" foresee that IP
source and destination addresses, transport protocol and source
destination port can be specified. If one of these components is
missing, it represents a wild card. For example if only source and
destination IP addressed are present, the packets will belong to this
flow regardless of the transport protocol type and port number. More
complex Flow identification mechanism (i.e. range of transport protocol
ports, range of IP addresses) are for further study and can be easily
added by defining additional S-Type for this object.

5.9 Flow Reference ID (FRID)

S-Num = 17, S-Type = 1

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 17   |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|                      Flow Reference ID                        |
+---------------+---------------+---------------+---------------+

The Flow Reference ID is uniquely assigned by the PEP to identify the
flow in future requests.

5.10 Source IP Address (SIPA)

S-Num = 18

S-Type = 1, Ipv4 Address.

S-Type = 2, Ipv6 Address.

See Ingress Point Address object for the representation of the object
structure.



Salsano                    Expires May 2002                         17

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


5.11 Destination IP Address (DIPA)

S-Num = 19

S-Type = 1, Ipv4 Address.

S-Type = 2, Ipv6 Address.

See Ingress Point Address object for the representation of the object
structure.

5.12 Source Port (SP)

S-Num = 20, S-Type = 1

       0                1               2               3
+---------------+---------------+---------------+---------------+
|              Length           |  S-Num = 20   |  S-Type = 1   |
+---------------+---------------+---------------+---------------+
|  /////        |  Protocol ID  |         Port Number           |
+---------------+---------------+---------------+---------------+

This object actually carries also the protocol type information. It can
be used to generically indicate a protocol type if the port Number is
set to 0x0000.

5.13 Destination Port (DP)

S-Num = 21, S-Type = 1

See Source Port object for the representation of the object structure.
This object actually carries also the protocol type information. It can
be used to generically indicate a protocol type if the port Number is
set to 0x0000.

6.       COPS-DRA Client-Specific data format


6.1 Context object

The context object specifies the type of request that triggered the
query. It is included in the REQ and in the DEC message. For COPS-DRA
client the Request Type flag is always set to 0x02 (Resource-Allocation
Request). The Message Type flag is used by the COPS-DRA client to
distinguish between Outsourced, Aggregated and Configuration requests.
The Message type flag also discriminates add, release and modify
requests. Depending on the M-Type, a different content of the ClientSI
object for REQ message is used.






Salsano                    Expires May 2002                         18

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


C-num = 2, C-Type = 1

R-Type = 0x02

M-Type = 1 : Outsourced Add
M-Type = 2 : Outsourced Release
M-Type = 3 : Outsourced Modify

M-Type = 9  : Aggregated Add
M-Type = 10 : Aggregated Release
M-Type = 11 : Aggregated Modify

M-Type = 16 : Configuration


6.2 Client Specific Information Object for REQ message.

The Client Specific Information Object carried in the REQ messages for
COPS-DRA client contains the description of the resources and has a
different format depending on the type of the request, as specified by
the context object.

If the Context object specifies an Outsourced Add or Outsourced Release
request, the ClientSI object has the following format:

<Client SI: RAR data> ::= <Request ID>
                          <Ingress Point Address>
                          <Egress Point Address>
                          <Resource Type>
                          <Traffic Description>
                          [<Flow IDI>]

The Flow Identification Information is optional. Typically it is used on
the QoS client to QoS provider interface is policing / classification
mechanisms need to be installed on the network access node, while it is
not needed on the Edge Router to PDP/BB interface.

If the Context object specifies an Outsourced Modify request, the
previous values for Resource Type and Traffic Description are also
reported

<ClientSI: RAR data> ::= <Request ID>
                         <Ingress Point Address>
                         <Egress Point Address>
                         <Resource Type> (new value)
                         <Traffic Description> (new value)
                         <Resource Type> (old value)
                         <Traffic Description> (old value)
                         [<Flow IDI>]

If a Flow IDI was present in the Add request, it must be included in
successive Modify and Release requests.


Salsano                    Expires May 2002                         19

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


In case of Aggregated Add, Release and Modify request, the format of the
Client SI RAR data is identical except that the Flow IDI cannot be
included. For example for the Aggregated Add and Aggregated Release:

<Client SI: RAR data> ::= <Request ID>
                          <Ingress Point Address>
                          <Egress Point Address>
                          <Resource Type>
                          <Traffic Description>

In case of Configuration Request, the format of the Client SI RAR data
is the following:

<Client SI: RAR data> ::= <Request ID>
                          [<Res. Req(s)>]

where:

<Res. Req(s)> ::= <Res. Req> | <Res. Req(s)> <Res. Req>

<Res. Req> ::= <Ingress Point Address>
               <Egress Point Address>
               <Resource Type>
               <Traffic Description>



6.3 Decision Client Specific Info Data object.

In case of an answer to Outsourced and Aggregated Requests, the Decision
ClientSI data object carries the information needed to correlate the
decision with the request and some optional information to explain
negative Decisions. It has the following format:

<Decision: Client SI data> ::= <Request ID>
                               <Reject Reason>

In case of an answer to Configuration Requests, the Decision ClientSI
data object carries the information needed to correlate the decision
with the request and the information related to the resources to be
allocated. It has the following format:

<Decision: Client SI data> ::= <Request ID>
                               [<Allocated resources>]

where Allocated resources is:

<Allocated resources> ::= <Res. Req(s)>






Salsano                    Expires May 2002                         20

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


6.4 Client Specific Information Object for SSQ and SSC messages.

The Client Specific Information Object carried in the SSQ messages for
COPS-DRA client describes the scope of the requested (for SSQ message)
and performed (for SSC message) synchronize operation. This object has
the following format:

<ClienSI: SSQ scope> ::= <SSQscope>
                        [<Resource Type>]
                        [<Ingress Point Address>]
                        [<Egress Point Address>]

If the "Specific scope" value is expressed in the SSQscope object, then
the Resource Type, Ingress Point Address and Egress Point Address object
must be included.

6.5 Report Type Object

The Report Type is contained in the Report State message.

C-num = 12, C-Type = 1

Report-Type = 1 : Success
Report-Type = 2 : Failure

6.6 Client Specific Information Object for Report State message.


The Client SI object for Report State message is used to communicate to
the PDP that a Request ID was not recognized.

<ClientSI: ReqID> ::= <Request ID>


7.       Security Considerations


This document relies on COPS for its signaling and its security. Please
refer to section "Security Considerations" in [COPS].

8.       IANA Considerations

Following the consideration in [COPS], the COPS Diffserv Resource
Allocation has been temporarily assigned a client-type value in the
range for private use. Future versions of the draft could define new
client-type value from the "First Come First Served" range.


9.       Illustrative examples for COPS-DRA client

This section details two examples related to a successful and to an
unsuccessful reservation respectively, for the case of Edge Router to
PDB/BB interface and the use of Outsourced requests.

Salsano                    Expires May 2002                         21

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01



In the following example the PEP requests the reservation of 1 Mb/s of
EF traffic between ingress point 192.168.1.1 and the egress point
192.168.129.1.

       PEP --> PDP   REQ := <Handle H>
                            <Context: Resource allocation, Outsourced
                             Add>
                            <ClientSI:
                                Request ID: X
                                IPA: 192.168.1.1
                                EPA: 192.168.129.1
                                Request type (DSCP): EF
                                TD (Bandwidth): 125kBytes/s
                            >

The PDP accepts the reservation.

       PDP --> PEP   DEC := <Handle H>
                            <Context: Resource allocation, Outsourced
                             Add>
                            <Decision: Command = Install>
                            <Decision: Client SI
                                Request ID: X
                            >


In the following example the PEP requests the reservation of 2 Mb/s of
EF traffic between ingress point 192.168.1.1 and the egress point
192.168.129.1. Note that the same Handle is used, while the Request ID
is different.

       PEP --> PDP   REQ := <Handle H>
                            <Context: Resource allocation, Outsourced
                             Add>
                            <ClientSI:
                                Request ID: Y
                                IPA: 192.168.1.1
                                EPA: 192.168.129.1
                                Request type (DSCP): EF
                                TD (Bandwidth): 250kBytes/s
                            >












Salsano                    Expires May 2002                         22

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


The PDP rejects the reservation.

       PDP --> PEP   DEC := <Handle H>
                            <Context: Resource allocation, Outsourced
                             Add>
                            <Context: Resource allocation, Add>
                            <Decision: Command = Remove>
                            <Decision: Client SI
                                Request ID: Y
                            >


10.       References


[2BIT]   K. Nichols, V. Jacobson, L. Zhang " A Two-bit Differentiated
         Services Architecture for the Internet "RFC 2638, July 1999
[BBop]   First Internet2 bandwidth broker operability event
         http://www.merit.edu/internet/working.groups/i2-qbone-
         bb/inter-op/index.htm
[BBREQ]  R. Neilson, J. Wheeler, F. Reichmeyer, S. Hares (Editors), "A
         Discussion of Bandwidth Broker Requirements for Internet2
         Qbone Deployment" Version 0.7
[COPS]   D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A.
         Sastry "The COPS (Common Open Policy Service) Protocol", IETF
         RFC 2748, January 2000
[COPS-ODRA]     S. Salsano "COPS usage for Outsourcing Diffserv Resource
         Allocation ", <draft-salsano-cops-odra-00.txt>, October 2001,
         Work in Progress
[COPS-RSVP] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A.
         Sastry, "COPS usage for RSVP ", IETF RFC 2749, January 2000
[COPS-PR]K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S.
         Herzog, F. Reichmeyer, R. Yavatkar, A. Smith "COPS Usage for
         Policy Provisioning (COPS-PR)", IETF RFC 3084, March 2001.
[ICC99]  A. Detti, M.Listanti, S.Salsano, L.Veltri, "Supporting RSVP in
         a Differentiated Service Domain: an Architectural Framework
         and a Scalability Analysis", ICC '99, June 1999, Vancouver,
         Canada.
[INTDIF] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer,
         R. Braden, J. Wrocklaski, E. Felstaine, A Framework for
         Integrated Services Operation Over Diffserv Networks, IETF RFC
         2998, November 2000
[IWQOS99]O. Schelen, A. Nilsson, J. Norrgard,S. Pink: Performance of
         QoS Agents for Provisioning Network Resources. In Proceedings
         of IFIP Seventh International Workshop on Quality of Service
         (IWQoS'99), London, UK, June 1999.
[PIB]    M. Fine, K. McCloghrie, J. Seligson, S. Hahn, K. Chan, A.
         Smith, "Framework Policy Information Base", <draft-ietf-rap-
         frameworkpib-03.txt>,November 2000, Work in Progress
[RAP]    R. Yavatkar, D.Pendarakis, R.Guerin, "A Framework for Policy
         Based Admission Control", IETF RFC 2753, January 2000.
[SLS-INT]Service Level Specification Interest Web Page, http://www.ist-
         tequila.org/sls.html

Salsano                    Expires May 2002                         23

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


[UCLA-BB]A. Terzis, J.Ogawa, S.Tsui, L.Wang, L.Zhang "A prototype
         Implementation of the Two-Tier Architecture for Differentiated
         Services" IEEE Workshop on QoS Support for Real-Time Internet
         Applications, June 2-4, 1999 Vancouver, Canada


11.       Author Information and Acknoledgements

Special thanks to Roberto Mameli, Luca Veltri, Vera Bonanni, Andrea
Ferraresi, Fabio Lazzarini, Eleonora Manconi, Donald Papalilo, Enzo
Sangregorio for their comments and suggestions and their work on the
prototype implementation.


Stefano Salsano
DIE - University of Rome "Tor Vergata"
Via di Tor Vergata, 110
00133 Roma - ITALY
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
email: salsano@coritel.it



    APPENDIX: Discussion on Provisioning and Outsourcing models

[This text is reported from draft-salsano-cops-odra-00.txt]

Two main models are supported by the COPS protocol: Outsourcing and
Provisioning. The COPS-ODRA client relies on the Outsourcing model. The
PEP explicitly asks the PDP/BB for a given amount of resources, from an
ingress point to an egress point. Note that per-flow state is not stored
in the PDP/BB. Instead, resource allocation requests are properly
aggregated and only aggregate state information is kept in the PDP/BB,
allowing for higher scalability. In this context, resource allocation is
strictly related to admission control: the server controls the
allocation of resources by admitting or rejecting the requests coming
from its clients.

An example application scenario for the COPS-ODRA is the Intserv
operation over Diffserv networks, as described in [INTDIF]. In this
scenario, the Edge Router includes the PEP and interacts with the PDB/BB
using COPS-ODRA according to the reservation requests coming from RSVP
messages. An architectural definition and scalability analysis of this
scenario can be found in [ICC99]

[...]

The Outsourcing model is used when there are "Trigger events" in the PEP
that require a policy decision (e.g. a dynamic request to admit a new
flow). The PEP delegates this decision to an external policy server
(PDP). It sends a query message to the PDP, typically waiting for the
response decision before admitting the new flow. See Figure A1 below.


Salsano                    Expires May 2002                         24

      COPS Usage for Diffserv Resource Allocation (COPS-DRA)    Oct-01


           Edge Device                    Policy Server
 +-----------------------------+          +--------------+
 |                             |          |              |
 |  +--------+                 |  COPS    |              |
 |  |Trigger |      +-----+    |  REQ()   |  +--------+  |
 |  | events |----->|     |----|----------|->|        |  |
 |  +--------+      | PEP |    |          |  | PDP/BB |  |
 |                  |     |<---|----------|--|        |  |
 |                  +-----+    |   COPS   |  +--------+  |
 |                             |   DEC()  |              |
 +-----------------------------+          +--------------+
               Figure A1: COPS-ODRA Outsourcing Model

On the other hand, the Provisioning model [COPS-PR] foresees that the
PDP proactively configures the PEP so that it knows how to run its QoS
mechanisms. The mechanisms to exchange the configuration information and
to store this information is based on the definition of a "Policy
Information Base", see [PIB].
In the Provisioning model, either there are no "Trigger events" at the
PEP (i.e. only packet classification, marking, scheduling, etc. is
performed at the PEP) or these events must be handled using local
information (i.e. mapped in the available resources provisioned by the
PDP).
The Provisioning model is very well suited when there are no such
dynamic requests coming to the PEP. In other scenarios, like for example
the RSVP/Diffserv interworking the dynamic requests are a fundamental
feature in the PEP/Edge Router. In this case a possible solution is to
fully rely on the Outsourcing model, so that a very simple PEP can be
defined. The drawback is the need of relatively frequent communication
with the PDP, but there are scenarios where this solution can be cost-
effective.
Note that the Outsourcing model lends itself to more sophisticated
solutions if scalability concerns arise. In fact the Outsourcing model
can be dynamically paced by the PEP in real-time. A straightforward
option is to pre-reserve some amount of bandwidth to limit the pace of
Resource Admission Requests. The definition of these mechanisms is out
of the scope of this document, which focuses on the protocol
specification for the COPS-ODRA client.
In general, a combination of Outsourcing and Provisioning model could be
used to provide a flexible and general solution for QoS in IP networks,
[...]













Salsano                    Expires May 2002                         25


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/