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

Versions: 00

Internet Draft                                       Roberto Mameli
Expiration: August 2000                              Stefano Salsano
File: draft-mameli-issll-is-ds-cops-00.txt           CoRiTeL



      Integrated services over DiffServ network using COPS-ODRA


                         February 22, 2000



     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 (2000).  All Rights Reserved.


     Abstract

This document details the IntServ operation over a DiffServ network in
the case of dynamic admission control procedure supported by the COPS
protocol. An RSVP aware Edge Router uses the COPS protocol in order to
query a Bandwidth Broker, which manages the resources within the
DiffServ domain. This document relies on the COPS extensions proposed in
the companion draft "COPS usage for Outsourcing DiffServ Resource
Allocation" [COPS-ODRA].



Mameli                   Expires August 2000                         1

     Integrated services over DiffServ network using COPS-ODRA  Feb-00



     Table of Contents

Abstract........................................................1
Table of Contents...............................................2
1  Introduction.................................................2
2  IntServ over DiffServ: the role of the Edge Router...........3
3  RSVP/COPS interaction........................................5
4  Traffic control in the RSVP daemon...........................8
5  References...................................................9
6  Author Information and acknoledgements.......................10


Glossary


API     Application Programming Interface
BB      Bandwidth Broker
COPS    Common Open Policy Service
ER      Edge Router
LPDP    Local Policy Decision Point
LLDAL   Link Layer Dependent Adaptation Layer
ODRA    Outsourcing Diffserv Resource Allocation
PDP     Policy Decision Point
PEP     Policy Enforcement Point
QoS     Quality of Service
RSVP    ReSerVation Protocol
SLS     Service Level Specification



1.        Introduction


The Integrated Service Architecture (IntServ _ see [INTSERV] and
[RFC2210]) and the Differentiated Service Architecture (DiffServ _ see
[2BIT] and [DSARCH]) have been proposed in the IETF to address the
support of QoS in IP networks. A combination of the two approaches is
proposed in [INTDIF], which provides a general framework while leaving
open several architectural issues. In particular three options for
resource management in the DiffServ network are listed: 1) statically
provisioned resources, 2) dynamically provisioned resources by means of
RSVP, 3) dynamically provisioned resources by other means (e.g., a form
of Bandwidth Broker).

In this draft we consider the third scenario where the Admission Control
in the DiffServ network is based on a Bandwidth Broker. The Edge Router
communication with the Bandwidth Broker is realized by means of an
extension to the COPS protocol described in the related proposed
document [COPS-ODRA]. The COPS is used to exchange resource allocation
requests/responses. The Edge Router contains the PEP _ Policy
Enforcement Point (client side of the COPS protocol), while the


Mameli                   Expires August 2000                         2

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


Bandwidth Broker plays the role of the PDP _ Policy Decision Point
(server side of the COPS protocol).

The goal of this document is to define the scenario for the interworking
of RSVP and COPS protocols and to describe the interaction between them.
Note that in the Edge Router, the implementations of the RSVP and of the
COPS protocols can be seen as two different entities that need to
communicate. The detailed description of the related communication
mechanism is outside the scope of this document. A proposal for such
communication mechanism, based on an API library is described in a
companion draft [CCAPI].



2. IntServ over DiffServ: the role of the Edge Router

This section briefly recall the main concepts behind the IntServ over
DiffServ operation as described in [INTDIF]; it focuses on the specific
scenario of dynamic admission control and analyzes in detail the role of
the Edge Router. The reference network configuration is depicted in
Figure 1.


             ________         ________         _______
            /        \       /        \       /       \
           /          \     /          \     /         \
    +---+ |            |---|            |---|           | +---+
    |Tx |-|            |ER1|            |ER2|           |-| Rx|
    +---+ |            |-- |            |---|           | +---+
           \          /     \          /     \         /
            \________/       \________/       \_______/

    IntServ Access Region    DiffServ Core   IntServ Access Region

                 Figure 1: Reference Network Configuration


As explained in [INTDIF], such a solution tries to conjugate benefits of
both the IntServ and the DiffServ approaches to QoS provisioning. In
fact, it achieves scalability due to the DiffServ aggregation in the
core, while keeping the advantages of end-to-end signaling.

The Edge Router (ER) plays a key role in this scenario. The ER is the
router placed at the boundary between the IntServ access network and the
DiffServ core. Differently from core routers, it is RSVP aware and
stores per-flow states; nevertheless, it is capable of managing packets
both on a micro-flow basis and on an aggregate basis. The choice between
the two possibilities depends on the role of the Edge Router. When it
acts as ingress ER, i.e. for packets from the originating IntServ
network to the DiffServ core it forwards packets in an aggregate fashion
on the outgoing interface, while it can handle micro-flows on the
incoming interface. Instead, when it behaves as egress ER, i.e. for
packets from the DiffServ core to the destination IntServ network, it is

Mameli                   Expires August 2000                         3

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


able to distinguish micro-flows on the outgoing interface. Note,
however, that the distinction between ingress and egress edge router
depends only on the direction of the data stream. This means that the
same ER may be ingress ER for a flow and egress ER for another one in
the opposite direction.

As previously stated, the Edge Router is one of the main actors in the
situation depicted in Figure 1. This is especially true for the ingress
Edge Router, since it provides some important functionality. Among them
we cite:

 - Classification: it performs per micro-flow classification, i.e. it is
       able to distinguish the different Intserv flows.
 - Mapping: it performs mapping of IntServ service classes into DiffServ
       PHBs; it is also in charge of aggregating IntServ micro-flows
       into DiffServ aggregates.
 - Marking: it marks (or remarks) the DS field of incoming packets
       according to the target PHB, that in turn results from the
       mapping operation explained above.
 - ADSPEC update: for GS flows the exported terms in the ADSPEC (i.e. C
       and D) must be properly updated with a value depending upon the
       topology and the characteristics of the DiffServ core.
 - Admission Control: this is one of the main tasks performed by the
       ingress Edge Router. The Admission Control is applied to the
       virtual hop represented by the DiffServ core network. The
       purpose of this procedure is to ensure that Diffserv resources
       are available in the Diffserv domain to support the requested
       Intserv flow. In a "pure" DiffServ network per flow Admission
       Control is not needed, as simpler "aggregate" policing at
       ingress points based on provisioning can be used. As explained
       in [INTDIFF], the purpose of per-flow admission control is to
       increase network utilization and/or to support tighter end-to-
       end QoS guarantees (at the expense of increased complexity).

Let us focus on the Admission Control functionality performed by the
Edge Router at the ingress boundary of the DiffServ cloud. There are
basically two distinct approaches to this task:

- Distributed:  in this case Admission Control is based on information
            locally available in the ingress Edge Router.
- Centralized:  differently from the previous choice, Admission Control
            is realized by means of a Bandwidth Broker (BB), i.e.
            logically centralized entity acting as an Admission Control
            server. The BB could use global knowledge of both the
            network topology and the resource allocation (see Figure 2)
            to take Admission control decisions. The definition of
            mechanisms and algorithms used for the BB operation is
            outside the scope of this document and will not be further
            detailed here. Related work can be found in [IWQOS99].





Mameli                   Expires August 2000                         4

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


                              +------+
                         +----|  BB  |----+
                         |    +------+    |
             ________    |    ________    |    ________
            /        \   |   /        \   |   /        \
           /          \  |  /          \  |  /          \
    +---+ |            |---|            |---|            | +---+
    |Tx |-|            |ER1|            |ER2|            |-| Rx|
    +---+ |            |-- |            |---|            | +---+
           \          /     \          /     \          /
            \________/       \________/       \________/

    IntServ Access Region    DiffServ Core   IntServ Access Region

                 Figure 2: Centralized Bandwidth Broker


The distributed solution is quite simple to implement, but it is also
rather inaccurate, since each ER exploits information with a local
scope, without the overall vision of the network status. In contrast,
the second approach raises some non-trivial issues in terms of
complexity and scalability, but allows better resource utilization
within the DiffServ cloud.

In this document the centralized solution of Figure 2 is analyzed. A
protocol for the communication between the ER and the centralized server
is needed. The use of the COPS [COPS] is considered here. The COPS
protocol can be extended to support new Client types. The extensions
proposed in [COPS-ODRA] are suited to support the Intserv operation on
Diffserv network.

Note that the scenario depicted in Figure 2 refers to a single DiffServ
core domain (intra-domain case). In a multi-domain scenario, one could
simply use of RSVP as end-to-end signaling (raising scalability
concerns) or more complex communication mechanisms between BBs of
different domains could be defined. These inter-domain aspects are
outside the scope of this document.



3.   RSVP/COPS interaction

From now on the architecture represented in Figure 2 will be assumed as
the reference scenario. As previously explained, the Edge Router
comprises most of the functionality needed for interworking, including
admission control on a micro-flow basis. Obviously, for proper
operation, RSVP and COPS signaling should properly interact. To clarify
this mechanism let us consider the sequence of operations involved in an
end-to-end reservation, that is described in detail in [INTDIF] and
reported here in a simplified form. We are considering unicast
reservations:



Mameli                   Expires August 2000                         5

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


  - The sender application on Tx generates an RSVP PATH message
    carrying the flow's characteristics (i.e. the Tspec). The message
    is carried towards the receiver Rx; in the IntServ access regions
    it is subject to standard RSVP/IntServ processing, while in the
    DiffServ core it is forwarded transparently.

  - When the receiving host Rx receives the PATH it generates the
    corresponding RSVP RESV message, that is carried back towards the
    sending host. As before, the RESV message undergoes standard
    RSVP/IntServ processing in the IntServ access regions and is simply
    ignored in the DiffServ core. During his travel backwards, assuming
    that it not rejected before for resource unavailability, it reaches
    the ingress Edge Router ER1.

  - In ER1, the RESV message triggers a query to the Bandwidth Broker.
    The latter, based on the information carried in the RESV message
    and on its view on the utilization of network resources, decides to
    admit or reject the request. The total amount of available
    resources is determined by Diffserv provisioning mechanisms.

  - If ER1 approves the request, the RESV message is admitted and is
    allowed to continue upstream towards the sender. If it rejects the
    request, the RESV is not forwarded and the appropriate RSVP error
    messages are sent.


As described in the list above, queries from the ingress ER to the BB
are triggered whenever the former receives a RESV message from the
downstream DiffServ domain. Note that in this situation RSVP and COPS
are synchronized. A possible choice in the implementation of RSVP/COPS
interaction would be to keep this synchronization. This would imply a
blocking behavior; whenever the RSVP daemon triggers a query it blocks
indefinitely waiting for a response. This raises the obvious problem of
managing situations in which a response from the PDP/BB is not
temporarily available. In fact, in such cases, the blocking behavior
should be avoided, in order to be able to manage other events and to
avoid soft state expirations.

As a consequence the RSVP should be properly adapted in order to manage
requests and responses asynchronously. After a query and before getting
the response, processing of other events should be possible. A possible
way to realize this behavior could be the introduction of pending
reservation states in the RSVP daemon. Consider as an example the
reception of a RESV message by the ingress Edge Router ER1, that in turn
triggers an admission control query towards the PDP/BB. In this case the
RSVP daemon could set up a reservation state before retrieving the
response, marking it as pending. No further operations related to this
state should be performed until it remains pending, i.e. until the
response from the PDP/BB is available; this means, for example, that the
RESV message should not be forwarded upstream. In the case of positive
response (i.e. reservation request accepted), the corresponding
reservation should be instantiated on the egress interface of ER1, and
the RESV message should be forwarded upstream. In the case of rejection,

Mameli                   Expires August 2000                         6

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


e.g. due to unavailability of resources, a blockade state should be set
up in ER1 and a RESVERR message should be propagated downstream towards
Rx, according to standard RSVP behavior. The introduction of pending
reservation states could allow the RSVP daemon to perform normal
processing related to states other than the one considered. This
obviously includes refresh operations triggered by timeout expirations.
Note that a timeout could also be defined for pending states. In this
case, when the timeout of a pending reservation state expires, and no
response has been received in the meanwhile, the RSVP could either
reject the request or revert to local decision based on LPDP
functionality in the ER.

Figure 4 and Figure 5 show the typical sequence of operations involved
in a reservation, both in the case of acceptance and in the case of
rejection. As stated above, the interface between the PEP in the ER and
the PDP/BB is realized by means of the COPS protocol extension described
in [COPS-ODRA], while the interface between the RSVP daemon and the PEP
within the ER is described in a companion draft [CCAPI].

                                  +---------+
                 +----------------| PDP/BB  |----------------+
                 |                +---------+                |
            +---------+                                 +---------+
            |   ER1   |                                 |   ER2   |
            +---------+                                 +---------+
           RSVP      PEP            PDP/BB             RSVP

             |        |     RSVP RESV MESSAGE            |
             |<-------+---------------+------------------|
             |        |               |                  |
             |request |               |                  |
             |message | COPS-ODRA     |                  |
      +      |------->| REQ MESSAGE   |                  |
      |      |        |-------------->|                  |
   pending   |        | Add           |                  |
   reserv.   |        |               |                  |
    state    |        | COPS-ODRA     |                  |
      |      |dispatch| DEC MESSAGE   |                  |
      +      |message |<--------------|                  |
      +      |<-------| Install       |                  |
  normal     |   OK   |               |                  |
  reservation|        |               |                  |
  state      |        |               |                  |
      |      |        |               |                  |
     ...    ...      ...             ...                ...

              Figure 3: Reservation successfully accepted







Mameli                   Expires August 2000                         7

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


                                  +---------+
                 +----------------| PDP/BB  |----------------+
                 |                +---------+                |
            +---------+                                 +---------+
            |   ER1   |                                 |   ER2   |
            +---------+                                 +---------+
           RSVP      PEP            PDP/BB             RSVP

             |        |     RSVP RESV MESSAGE            |
             |<-------+---------------+------------------|
             |request |               |                  |
             |message | COPS-ODRA     |                  |
      +      |------->| REQ MESSAGE   |                  |
      |      |        |-------------->|                  |
   pending   |        | Add           |                  |
   reserv.   |        |               |                  |
   state     |        | COPS-ODRA     |                  |
      |      |dispatch| DEC MESSAGE   |                  |
      +      |message |<--------------|                  |
      +      |<-------| Remove        |                  |
      |      |  NO    |     RSVP RESVERR MESSAGE         |
   blockade  |--------+---------------+----------------->|
    state    |        |               |                  |
      |     ...      ...             ...                ...

                    Figure 4: Reservation rejected


Finally, Figure 5 shows the sequence of events involved in the release
of resources. When a RESV TEAR is received a COPS-ODRA REQ message is
sent to the PDP/BB, in order to let it keep track of resource usage.
After the reception of the corresponding DEC message the PEP notifies
the RSVP, which in turn releases the reservation and forward upstream
the RESV TEAR. Note however that the same sequence of operations happens
in the case of PATH TEAR or in the case of timeout expiration.



















Mameli                   Expires August 2000                         8

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


                                  +---------+
                 +----------------| PDP/BB  |----------------+
                 |                +---------+                |
            +---------+                                 +---------+
            |   ER1   |                                 |   ER2   |
            +---------+                                 +---------+
           RSVP      PEP            PDP/BB             RSVP

             |        |     RSVP RESV TEAR MESSAGE       |
             |<-------+---------------+------------------|
             |request |               |                  |
             |message | COPS-ODRA     |                  |
      +      |------->| REQ MESSAGE   |                  |
      |      |        |-------------->|                  |
      |      |        | Release       |                  |
   reserv.   |        |               |                  |
   state     |        | COPS-ODRA     |                  |
      |      |dispatch| DEC MESSAGE   |                  |
      |      |message |<--------------|                  |
      +      |<-------| Install       |                  |
   <---------|  OK    |               |                  |
    RESV TEAR|        |               |                  |
     MESSAGE...      ...             ...                ...

                    Figure 5: Resource release


4.  Traffic control in the RSVP daemon

The previous paragraph explains how RSVP and COPS can interact within
the same Edge Router. Obviously the need for interaction between them
requires some modifications in the normal operations performed by RSVP.
An example of this is represented by the introduction of pending
reservation states (see the previous paragraph). Another modification
deals with the interface between RSVP and Traffic Control, described in
[RFC2205]. As explained there, it may be desirable to organize an RSVP
implementation into two parts: a core that performs link-layer
independent processing, and a link-layer dependent adaptation layer
(LLDAL). A suitable interface between these layers is specified in
[RFC2205] (see Figure 6):














Mameli                   Expires August 2000                         9

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


                      +--------------------+
                      |     Link Layer     |
                      |     Independent    |
                      |        Core        |
                      +--------------------+ RSVP/Traffic Control
                  -------------------------------------
                      +--------------------+ Interface
                      |     Link Layer     |
                      |      Dependent     |
                      |  Adaptation Layer  |
                      |      (LLDAL)       |
                      +--------------------+

             Figure 6: Organization of an RSVP implementation


The realization of the scenarios depicted in Figure 1 and in Figure 2
requires some minor changes to this interface. In fact, let us focus on
the TC_AddFlowspec() call:

   Rhandle = TC_AddFlowspec( Interface, TC_Flowspec, TC_Tspec,
                             TC_Adspec, Police_Flags )

In a pure RSVP/IntServ scenario, whenever the upper layer executes a
TC_AddFlowspec() call, the LLDAL performs Admission Control and, in case
of success, it sets up the reservation (i.e. it adds the proper traffic
control objects, such as schedulers and classifiers, on the interface
involved in the reservation). This makes sense, since in this case
Admission Control is based on the local availability of resources, whose
usage is likely to be known at the Link Layer dependent level.

The situation is slightly different when dealing with the interoperation
between IntServ and DiffServ. In fact, in this case Admission Control
requires the knowledge of the resource usage of the whole DiffServ
domain, and such an information is obviously outside the local scope of
the LLDAL. The entity that is aware of the whole domain is the Bandwidth
Broker, and this implies that it must be involved in the decision, i.e.
it must be queried by the RSVP. There are obviously two possible choices
to perform this operation. The first one is to keep the Admission
Control functionality at the LLDAL level, making it responsible of
interfacing with the COPS-ODRA PEP; the second one is to move this
functionality at the upper layer, thus realizing RSVP/COPS
intercommunication in the Link Layer Independent Core. The first choice
is preferable, since it leaves unchanged the semantic of the original
TC_AddFlowspec() call and  complies with the philosophy behind the
scenario of Figure 2. In fact, from the RSVP viewpoint the DiffServ core
network can be seen as a single virtual trunk, i.e. a sort of virtual
link layer.

Note however that a new piece of information is required for Admission
Control in the situation depicted above. In fact, since the availability
of resources concerns a network, and not a single link, it should also
take into account some topological information, i.e. typically the IP

Mameli                   Expires August 2000                        10

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


addresses of the ingress and egress Edge Routers. The former is known,
because it coincides with the IP address of the ingress router involved
in the operation. The latter, instead, should be retrieved from the RESV
message and passed through the interface of Figure 5 for proper
Admission Control. This would imply a change of the TC_AddFlowspec()
call, that would become:

   Rhandle = TC_AddFlowspec( Interface, TC_Flowspec, TC_Tspec,
                             TC_Adspec, Police_Flags, Egress_Point )

where Egress_Point contains the IP address of the egress Edge Router.

Figure 7 summarizes the considerations explained in this paragraph. It
depicts the situation in the Edge Router ER, where the RSVP daemon and
the COPS-ODRA Client run as independent and concurrent processes. As
mentioned before the communication between them is realized by an API,
described in a companion document [CCAPI], that is used to support
communication at the LLDAL level.


    +-----------------------------------------------------------+
    |                                          Edge Router (ER) |
    |   +------------------------------------+                  |
    |   |    +--------------------+   RSVP   |  +-----------+   |
    |   |    |     Link Layer     |          |  |           |   |
    |   |    |     Independent    |          |  |           |   |
    |   |    |        Core        | Modified |  |           |   |
    |   |    +--------------------+ RSVP/TC  |  | COPS-ODRA |   |
    |   | ---------------------------------- |  |  Client   |   |
    |   |    +--------------------+ Interface|  |  (PEP)    |   |
    |   |    |     Link Layer     |          |  |           |   |
    |   |    |      Dependent     |__________|__|           |   |
    |   |    |  Adaptation Layer  |   CCAPI  |  |           |   |
    |   |    |      (LLDAL)       |          |  |           |   |
    |   |    +--------------------+          |  +-----------+   |
    |   +------------------------------------+                  |
    |                                                           |
    +-----------------------------------------------------------+

          Figure 7: RSVP/COPS interaction in the Edge Router




5.   References


[INTSERV]       R. Braden, D. Clark, S. Shenker, "Integrated Services in
        the Internet Architecture: an Overview", IETF RFC 1633, June
        1994
[RFC2210]       J. Wroclawski, "The Use of RSVP with Integrated
        Services", IETF RFC 2210, September 1997


Mameli                   Expires August 2000                        11

     Integrated services over DiffServ network using COPS-ODRA  Feb-00


[RFC2205]       R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
        "Resource ReSerVation Protocol (RSVP) - Version 1 Functional
        Specification ", IETF RFC 2205, September 1997
[2BIT]  K. Nichols, V. Jacobson, L. Zhang "A Two-bit Differentiated
        Services Architecture for the Internet", IETF RFC 2638, July
        1999
[DSARCH]S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss,
        "An Architecture for Differentiated Services", IETF RFC 2475,
        December 1998
[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
        <draft-ietf-issll-diffserv-rsvp-03.txt>, September 1999, Work
        in Progress
[IWQOS99]       O. Schelen, A. Nilsson, J. Norrgard, S. Pink,
        "Performance of QoS Agents for Provisioning Network Resources",
        Proceedings of IFIP Seventh Internation Workshop on QoS
        (IWQoS'99), London, UK, June 1999
[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-issll-cops-odra-00.txt>,
        February 2000, Work in Progress
[CCAPI] R. Mameli, "The CCAPI (COPS Client Application Programming
        Interface", <draft-mameli-issll-cops-api-00.txt>, February
        2000, Work in Progress



6.   Author Information and acknoledgements

Special thanks to Andrea Ferraresi and Eleonora Manconi for their
comments and suggestions and their work on the prototype implementation.


   Stefano Salsano
   CoRiTeL consortium
   Via di Tor Vergata 135
   00133 _ Roma (Italy)

   Phone: +39 06 20410029
   EMail: salsano@coritel.it


   Roberto Mameli
   CoRiTeL consortium
   Via di Tor Vergata 135
   00133 _ Roma (Italy)

   Phone: +39 06 20410038
   EMail: mameli@coritel.it


Mameli                   Expires August 2000                        12


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