Development and Implementation Report on the QoS Components ...

IST-2000-25394 Project Moby Dick
D0202
<strong>Development</strong> <strong>and</strong> <strong>Implementation</strong>
<strong>Report</strong> on the QoS Components for
Moby Dick
Contractual Date of Delivery to the CEC: May 31, 2003
Actual Date of Delivery to the CEC: June 05, 2003
Author(s): partners in WP2 (cf. page 3)
Participant(s):
partners in WP2
Workpackage:
WP2
Security:
Public
Nature:
<strong>Report</strong>
Version: 1.0
Total number of pages: 97
Abstract:
Future telecommunication networks, <strong>and</strong> in particular networks beyond 3 rd Generation, will be based on
an “all-IP” architecture. Issues such as Quality of Service (QoS), Mobility <strong>and</strong> Authentication,
Authorization, Accounting <strong>and</strong> Charging (AAAC), <strong>and</strong> their respective interoperation, must be h<strong>and</strong>led in
such scenarios. This document describes the specifications, implementations <strong>and</strong> tests of the different
components of the Moby Dick QoS architecture, i.e. the QoS Manager, the QoS Broker, the Radio
Convergence Function, <strong>and</strong> the DSCP Marking Software, <strong>and</strong> their interactions with the Moby Dick
mobility <strong>and</strong> security entities.
Keyword list:
<strong>Implementation</strong>, QoS Broker, QoS Manager, DSCP Marking Software, AAAC <strong>and</strong> mobility
interaction with QoS entities.
CEC Deliverable Number D0202 1 / 97

WP2-D0202 Version 1.0 4.6.2003
Executive Summary
This document describes the specification, implementation <strong>and</strong> tests of the different components of the
Moby Dick QoS architecture, including the QoS Manager, the QoS Broker, the Radio Convergence
Function, <strong>and</strong> the DSCP Marking Software, as well as their interactions with the Moby Dick mobility <strong>and</strong>
security sub-systems.
CEC Deliverable Number D0202 2 / 97

WP2-D0202 Version 1.0 4.6.2003
Authors
Partner Name Phone / Fax / E-mail
CRM
CRM
UC3M
UC3M
UC3M
PTIn
PTIn
PTIn
PTIn
EURECOM
Christophe Beaujean
Phone: +33 1 69 35 25 83
Fax: +33 1 69 35 25 01
E-mail: mailto:christophe.beaujean@crm.mot.com
Nesrine Chaher
Phone: +33 1 69 35 48 12
Fax: +33 1 69 35 25 01
E-mail: mailto:nesrine.chaher@crm.mot.com
Antonio Cuevas
Phone: +34 91-624-8747
Fax: +34 91 6248749
E-mail : mailto:acuevas@it.uc3m.es
Carlos Garcia Garcia
Phone: +34 91-624-8747
Fax: +34 91 6248749
E-mail : mailto:cgarcia@it.uc3m.es
Pedro Antonio Vico Solano
Phone: +34 916249959
Fax: +34 916248749
E-mail: pvico@it.uc3m.es
Victor Marques
Phone: +351 234 403654
Fax: +351 234 420722
E-mail: victor-m-marques@ptinovacao.pt
Pedro Gonçalves
Phone: +351 234 403654
Fax: +351 234 420722
E-mail: pasg@av.it.pt
Rui Aguiar
Phone: +351 234 403654
Fax: +351 234 420722
E-mail: mailto:ruilaa@av.it.pt
Francisco Fontes
Phone: +351 234 403654
Fax: +351 234 420722
Michelle Wetterwald
Phone: +33 (0) 4.93.00.26.31
Fax: +33 (0) 4.93.00.26.27
E-mail: mailto:michelle.wetterwald@eurecom.fr
CEC Deliverable Number D0202 3 / 97

WP2-D0202 Version 1.0 4.6.2003
UKR
Piotr Pacyna
Phone: +48 12 6345582
Fax: +48 12 6342372
E-mail: pacyna@kt.agh.edu.pl
CEC Deliverable Number D0202 4 / 97

WP2-D0202 Version 1.0 4.6.2003
Table of Contents
1. TERMINOLOGY ........................................................................................ 9
2. THE MOBY DICK QOS ARCHITECTURE.............................................. 13
2.1 Scenarios........................................................................................................................................13
2.1.1 User registration <strong>and</strong> authentication........................................................................................13
2.1.2 Service request <strong>and</strong> authorisation............................................................................................13
2.1.3 H<strong>and</strong>over.................................................................................................................................14
2.2 QoS delivery process.....................................................................................................................14
2.3 DSCP codes....................................................................................................................................15
3. SOFTWARE SPECIFICATION................................................................ 15
3.1 Overview of the software components.........................................................................................15
3.2 QoS Manager.................................................................................................................................16
3.2.1 Overview of the functionalities...............................................................................................16
3.2.2 Procedures...............................................................................................................................17
3.3 QoS Broker....................................................................................................................................19
3.3.1 WebGUI..................................................................................................................................21
3.3.2 NetProbe .................................................................................................................................21
3.3.3 QBrokerEngine .......................................................................................................................21
3.3.4 QoS Broker Interfaces.............................................................................................................21
3.3.4.1 BrokerInterface ...................................................................................................................21
3.3.4.2 NMSInterface......................................................................................................................21
3.3.4.3 AAACInterface...................................................................................................................22
3.3.4.4 RouterInterface ...................................................................................................................22
3.3.4.5 NMSInterface......................................................................................................................22
3.3.4.6 RGWClient .........................................................................................................................22
3.3.4.7 Data format for communications between Radio Gateway <strong>and</strong> QoSBroker.......................22
3.3.4.8 Messages exchanged between Radio Gateway <strong>and</strong> QoSBroker .........................................23
3.3.5 <strong>Implementation</strong> details of selected interfaces .........................................................................23
3.3.5.1 AAACInterface...................................................................................................................23
3.3.5.2 RouterInterface ...................................................................................................................23
3.3.5.3 VirtualRouter ......................................................................................................................24
3.3.5.4 CLIDriver............................................................................................................................24
3.3.5.5 COPSDriver ........................................................................................................................25
3.3.5.6 Messages exchanged between AR <strong>and</strong> QoSBroker ............................................................26
3.3.6 Interface summary ..................................................................................................................27
3.3.7 <strong>Implementation</strong> of databases...................................................................................................27
3.3.7.1 NetworkDB.........................................................................................................................27
3.3.7.2 NetStatus.............................................................................................................................28
3.4 The DSCP marking software .......................................................................................................28
3.4.1 Operation ................................................................................................................................29
3.4.2 DMS Architecture...................................................................................................................29
3.4.3 DSCP Matching ......................................................................................................................29
3.4.3.1 Packet filtering....................................................................................................................29
3.4.3.2 DSCP Matching Table ........................................................................................................32
3.4.4 DSCP marking ........................................................................................................................34
3.4.5 Packet re-marking...................................................................................................................34
3.4.6 DSCP updates .........................................................................................................................34
CEC Deliverable Number D0202 5 / 97

WP2-D0202 Version 1.0 4.6.2003
3.5 The radio resource management .................................................................................................35
4. QOS SIGNALING IN MOBY DICK.......................................................... 36
4.1 Signaling between QoS Manager <strong>and</strong> QoS Broker ....................................................................36
4.1.1 Router registration ..................................................................................................................37
4.1.2 QoS configuration dialogue ....................................................................................................37
4.1.3 Resource allocation dialogue ..................................................................................................40
4.1.4 Queues state report..................................................................................................................42
4.1.5 FHO context transfer from the old Access Router to the QoS Broker....................................43
4.1.6 FHO QoS Context transfer from the QoS Broker to the new AR (nAR)................................44
4.1.7 Connection check dialogue .....................................................................................................47
4.1.8 Closing COPS connection.......................................................................................................48
4.2 Signaling between the QoSB.f <strong>and</strong> the AAAC.f..........................................................................49
5. TESTS AND PERFORMANCES ............................................................. 50
5.1 QoS manager tests ........................................................................................................................50
5.1.1 Test conditions........................................................................................................................50
5.1.2 COPS sequences <strong>and</strong> st<strong>and</strong>ard compliance tests.....................................................................51
5.1.2.1 Access Router initialization ................................................................................................51
5.1.2.2 Access Router resource allocation ......................................................................................52
5.1.2.3 Access Router queues state report.......................................................................................53
5.1.2.4 Access Router mobility signaling messages .......................................................................54
5.1.2.5 Access Router timeout connection deletion........................................................................56
5.1.2.6 Access Router connection check dialogue ..........................................................................56
5.1.2.7 Access Router closing COPS connection............................................................................57
5.1.3 Quality of Service tests ...........................................................................................................59
5.1.3.1 Denying access to a non-authorized traffic .........................................................................59
5.1.3.2 Access interface QoS test....................................................................................................60
5.1.3.3 Core interface policing test .................................................................................................61
5.1.3.4 Dynamic reconfiguration test..............................................................................................62
5.2 QoS Broker <strong>and</strong> DSCP marking tests .........................................................................................63
5.2.1 First tests series.......................................................................................................................63
5.2.1.1 Filters loading .....................................................................................................................64
5.2.1.2 Packet marking....................................................................................................................64
5.2.2 Second tests series...................................................................................................................65
5.2.2.1 DSCP values loaded from the network ...............................................................................65
5.2.2.2 Destination Option ..............................................................................................................66
5.2.2.3 Hop-by-hop Option.............................................................................................................67
5.2.2.4 Sub-options .........................................................................................................................67
5.2.2.5 Fragment header..................................................................................................................67
5.2.2.6 Routing header....................................................................................................................68
5.2.2.7 Authentication header .........................................................................................................68
5.2.2.8 ESP header..........................................................................................................................68
5.2.2.9 ICMPv6 header ...................................................................................................................68
5.2.2.10 Tunneled packets inner header........................................................................................68
5.3 Radio resource management tests ...............................................................................................68
6. CONCLUSIONS ...................................................................................... 69
7. REFERENCES ........................................................................................ 70
8. APPENDIX A: QUALITY OF SERVICE CONFIGURATION ................... 71
CEC Deliverable Number D0202 6 / 97

WP2-D0202 Version 1.0 4.6.2003
8.1 QoSBroker configuration files .....................................................................................................71
8.2 QoS <strong>and</strong> policing trees created on the Router ............................................................................74
8.3 QoS re-configuration ....................................................................................................................77
8.4 Outsourced policing towards core network................................................................................78
9. APPENDIX B: DEBUG MODE ACCESS ROUTER OUTPUT LINES..... 80
9.1 Access Router Initialisation..........................................................................................................80
9.2 Access Router Resource allocation..............................................................................................82
9.3 Access Router queues state report...............................................................................................83
9.4 Access Router mobility signaling messages ................................................................................84
9.4.1 Old Access Router ..................................................................................................................84
9.4.2 New Access Router.................................................................................................................84
9.5 Access Router timeout connection deletion ................................................................................85
9.6 Access Router Connection check dialogue..................................................................................85
9.7 Access Router closing COPS connection.....................................................................................85
9.8 Denying access to a non-authorized traffic test..........................................................................85
CEC Deliverable Number D0202 7 / 97

WP2-D0202 Version 1.0 4.6.2003
Introduction
The Moby Dick project aims to define, implement <strong>and</strong> evaluate an IPv6-based mobility-enabled end-toend
QoS architecture. The implementation supports three different technologies: TD-CDMA (UMTS),
Wireless LAN (802.11) <strong>and</strong> Ethernet. The QoS architecture leads to a potentially scalable infrastructure,
<strong>and</strong> is based on a DiffServ model [1]. The architecture provides a complete QoS management solution,
including the definition of QoS Brokers (enhanced B<strong>and</strong>width Brokers) <strong>and</strong> QoS Attendants (QoS proxies
located in each access router), a set of interactions with AAAC <strong>and</strong> Mobile IP, specific signaling
solutions, <strong>and</strong> techniques for QoS mapping between different layers <strong>and</strong> technologies.
The different Moby Dick QoS entities, <strong>and</strong> their interactions with mobility <strong>and</strong> security components were
described in deliverable [2] <strong>and</strong> in [3].
In this document, we provide specify different QoS components implemented <strong>and</strong> integrated in the Moby
Dick test-bed. First, in section 2, we recall the main dynamics of the Moby Dick QoS architecture, <strong>and</strong>
the main functionalities <strong>and</strong> interactions of its components. This section provides a brief description of
the User Registration, Service Request <strong>and</strong> Authorisation as well as H<strong>and</strong>over processes. In section 3, we
detail the specifications of the different QoS software components, while section 4 describes the
interactions between these components, the information they exchange, <strong>and</strong> the messages formats. The
last section 5 is focused on the various tests <strong>and</strong> measurements intended to demonstrate the quality of the
overall implementation.
CEC Deliverable Number D0202 8 / 97

WP2-D0202 Version 1.0 4.6.2003
1. Terminology
This section defines the terminology used within the Work Package 2 (WP2) of the Moby Dick project.
AAAC Architecture
The AAAC Architecture defines the overall architecture of those modules <strong>and</strong> components required to
offer a full set of AAAC tasks.
AAAC Attendant
A AAAC Attendant is an agent in the AR that attends to the client's requests. It is likely to require that the
client provide some credentials that can be authenticated before access to the resources is permitted. The
attendant for instance can contact the local AAA server, who in turn communicates with the home AAA
server of the mobile node.
AAAC Server
The AAA server is an entity that receives service requests from the Service Equipment or from other
AAA servers. A request received by the AAA server is inspected <strong>and</strong> evaluated considering policies
stored in a Policy Repository. To evaluate policy conditions, it may be necessary to consult other AAA
servers or the service equipment. The AAA server also performs policy actions itself. It holds session <strong>and</strong>
transaction states, records accounting data, <strong>and</strong> logs events. The event log can be used for verifying the
systems behaviour or for a later auditing process. A AAAC.h will always refer to a AAAC Server in the
user home domain, <strong>and</strong> AAAC.f to a AAAC Server in a foreign domain.
Access Network (AN)
An IP network, which includes one or more Access Network Routers. The terms Access Network <strong>and</strong>
(administrative) domain are often used interchangeably since often an Access Network has its own
administration.
Access Router (AR)
An Access Network Router residing on the edge of an Access Network <strong>and</strong> connected to one or more
access points. An Access Router offers IP connectivity to MHs. The Access Router may include
intelligence beyond a simple forwarding service offered by ordinary IP routers.
Accounting
Accounting is the process of collecting information for billing <strong>and</strong> resource usage management.
Administrative Domain (AD)
An intranet, or a collection of networks, computers, <strong>and</strong> databases under a common administration.
Computer entities operating in a common administration may be assumed to share administratively
created security associations.
Auditing
Auditing is the process of examining information on a provided service to check whether the service has
been provided correctly <strong>and</strong> the contractual negotiated parameters have been met. Auditing could be
performed by an independent third party in order to prevent fraud.
Authentication
Authentication is the verification of the claimed identity of a subject performing an action. The subject
can be a service user or a service provider.
Authorization
The act of determining if a particular right, such as access to some resource, can be granted to the
presenter of a particular credential.
Charging
Charging is the process of deriving (monetary) costs for service usage based on accounting data, service
<strong>and</strong> customer specific tariffs.
Classification
Classification is the process of selecting a packet in a traffic stream based on the content of some portion
of the packet header. The result of this process is the assignment of a DSCP, i.e. a CoS, to a traffic stream.
CEC Deliverable Number D0202 9 / 97

WP2-D0202 Version 1.0 4.6.2003
Class of Service (CoS)
A CoS is a way of categorizing the traffic. A set of QoS parameters is applied to each of those classes,
<strong>and</strong> all the flows needing to optimize the same QoS parameters have the same CoS.
Core Network (CN)
A Core Network is a typical wired IP network, supporting DiffServ. Each AR is connected to a Core
Network.
Core Router (CR)
A CR is an interior node of a Core network.
Correspondent Node (CN)
An IP node with which the mobile node communicates.
DiffServ Code Point (DSCP)
A DSCP is a field in the IP header of each packet. This field represents the CoS of the traffic stream the
packet belongs to. However, for a same CoS, a DSCP may have different values in different DS Domains.
DiffServ (DS) Domain
A DS Domain is an AD in which DiffServ is supported by all the nodes. All these nodes use the same
DSCPs.
Egress Router (ER)
An ER is DS Domain boundary node connecting two DS Domains together. An ER is seen as a boundary
node by which the traffic leaves the DS Domain.
Fast H<strong>and</strong>over module (FHm)
A software module implementing Fast H<strong>and</strong>Over (FHO) procedures.
Horizontal H<strong>and</strong>over
From the IP point of view a horizontal h<strong>and</strong>over happens if the MN communicates with its old AR <strong>and</strong> its
new AR via the same network interface. Horizontal h<strong>and</strong>over is typically also an intra-technology
h<strong>and</strong>over but it can be an inter-technology h<strong>and</strong>over if the MN can do a h<strong>and</strong>over between two different
technologies without changing the network interface seen by the IP layer.
Ingress Router (IR)
An IR is DS Domain boundary node connecting two DS Domains together. An IR is seen as a boundary
node by which the traffic enters in the DS Domain.
Inter-Domain H<strong>and</strong>over
When the MH moves to a new AD then this h<strong>and</strong>over occurs. This requires some sort of host mobility
across ADs, which has to be provided by the external IP core. Note that this would have to involve the
assignment of a new IP address to the MH.
Intra-Domain H<strong>and</strong>over
When the MH changes ARs inside the same AD then this h<strong>and</strong>over occurs. Such a h<strong>and</strong>over is not
necessarily visible outside the AD. In case the ANG serving the MH changes, this h<strong>and</strong>over is seen
outside the AD due to a change in the routing paths. The IP address by which the MH is reachable does
not change. Note that the ANG may change for only some of the MH's data flows.
Marking
Marking is the process of setting the DSCP field of the IP packets with a value that corresponds to a CoS.
Metering
Metering is the process of determining the packets compliance to the traffic parameters. The goal of this
process is to verify if the traffic is in-profile or out-of-profile.
Mobile IP for Linux (MIPL)
A Mobile IP implementation for Linux.
Mobile Node (MN), Mobile Terminal (MT)
An IP node capable of changing its point of attachment to the network. The Mobile Node may have
routing functionality.
Mobile Terminal Networking Manager (MTNM)
A MT entity in charge of taking the decision to execute the h<strong>and</strong>over <strong>and</strong> attach procedures.
CEC Deliverable Number D0202 10 / 97

WP2-D0202 Version 1.0 4.6.2003
Network Management System (NMS) Server.
A NMS Server is an entity that makes core network configuration <strong>and</strong> defines the available resources for
the QoS Brokers in each moment.
Network View of the User Profile (NVUP)
From the network point of view, only a small set of that data stored in the User Profile is needed. This is
the NVUP, which contains QoS relevant information concerning the services available to the user.
Per Domain Behavior (PDB)
A PDB is a specific PHB (or, if applicable, list of PHBs) <strong>and</strong> traffic conditioning requirements in DS
domain. So, a PDB is a service that is applied to flows through the domain. It is the expected treatment
that an identifiable or target group of packets will receive from "edge-to-edge" of a DS domain.
Per Hop Behavior (PHB)
A PHB is the way packets will be processed by a DiffServ-capable network node. A PHB is defined as
an externally observable forwarding behaviour applied at a DiffServ-compliant node to a DiffServ
behaviour aggregate.
Policy Decision Point (PDP)
A logical entity that makes policy decisions for itself or for other network elements that request such
decisions.
Policy Enforcement Point (PEP)
A logical entity that enforces policy decisions.
Policy Repository (PR)
A policy repository can be defined from two perspectives: (a) A specific data store that holds policy rules,
their conditions <strong>and</strong> actions, <strong>and</strong> related policy data. A database or directory would be an example of such
a store. (b) A logical container representing the administrative scope <strong>and</strong> naming of policy rules, their
conditions <strong>and</strong> actions, <strong>and</strong> related policy data. A “QoS policy” domain would be an example of such a
container. This logical perspective will be used within this document. A Policy Repository is a model
abstraction representing an administratively defined, logical container for reusable policy elements.
Policy Server (PS)
A policy server determines a marketing term whose definition is not precise. Originally, [WSS+01]
referenced a policy server. As the RFC evolved, this term became more precise <strong>and</strong> known as the Policy
Decision Point (PDP). Today, the term policy server is used in marketing brochures <strong>and</strong> other literature to
refer specifically to a PDP or to another entity that uses/services policies.
Quality-of-Service (QoS)
Quality of Service (QoS) means providing consistent, predictable data delivery service. QoS is to the
ability of a network element (e.g. an application, host or router) to have some level of assurance that its
traffic <strong>and</strong> service requirements can be satisfied. To enable QoS requires the cooperation of all network
layers from top-to-bottom, as well as every network element from end-to-end.
QoS Manager
The QoS manager is a software entity located in the Access Router. It will be in charged of identifying
<strong>and</strong> forwarding services requests coming from a mobile terminal, <strong>and</strong> it will receive <strong>and</strong> execute orders
coming from the QoS Brokers in order to allocate resources.
QoS Broker (QoSB)
The QoS Broker is an entity that performs network resources management. This entity is responsible of
resource allocation to the customer, <strong>and</strong> unused resources release. Resources will be allocated by the QoS
Broker only in the AGs. Besides, a QoS Broker interacts with AAA to manage service requests coming
from the user. A QoSB.h will always refer to a QoS Broker in the user home domain, <strong>and</strong> QoSB.f to a
QoS Broker in a foreign domain.
QoS Mapping
QoS Mapping is the process of translating QoS attributes (or QoS needs) from a upper layer to a lower
layer. For example, DiffServ QoS attributes (at IP level) can be mapped into UMTS QoS attributes.
QoS Provisioning
The installation <strong>and</strong> configuration of the QoS services in the network nodes.
CEC Deliverable Number D0202 11 / 97

WP2-D0202 Version 1.0 4.6.2003
Radio Convergence Function (RCF)
An interface with the radio layer, mapping the IP-level QoS requirements into radio QoS parameters.
Radio Gateway (RG)
Radio Gateway is an entity that supports interworking between the IPv6 backbone <strong>and</strong> the TD-CDMA
access network. It can be used with the Moby Dick TD-CDMA access as well as others (e.g.
IEEE802.11e, etc).
Scheduling
Scheduling allows, thanks to queuing techniques like Weight Fair Queuing (WFQ), to offer a fair share of
resources to each flow according to its priority.
Service
A service is a performance offered by a provider. In contrast to goods, services are usually intangible <strong>and</strong>
production <strong>and</strong> consuming happens simultaneously. Services can be very different. A service can be for
instance a 2 hour videoconference including audio, video <strong>and</strong> whiteboard, the guaranteed transmission of
100000 packets with a high priority, the provisioning of accounting records, etc.
Service Level Agreement (SLA)
A SLA is defined as a ‘service contract that specifies the forwarding service a customer should receive’.
It can also include information that is ‘of pricing, contractual or other business nature’. It might also
include technical information that is not part of the DiffServ architecture per se (e.g. service availability).
Service Level Specification (SLS)
‘A Service Level Specification (SLS) is a set of parameters <strong>and</strong> their values which together define the
service offered to a traffic stream by a DS domain.’
Shaping
Shaping is the process of achieving a target flow rate. It generally consists in limiting the maximum
output rate of flow with special queue management techniques, like the Token Bucket for example.
User Profile
A User Profile is associated with each user. The User Profile stores all information related with that user,
such as information about the SLA, Authentication, Authorization, Accounting, Charging, etc.
Vertical H<strong>and</strong>over
In a vertical h<strong>and</strong>over the MH's network interface to the Access Network changes. Vertical h<strong>and</strong>over is
typically an inter-technology h<strong>and</strong>over but it may also be an intra-technology h<strong>and</strong>over if the MH has
several interfaces of the same type.
CEC Deliverable Number D0202 12 / 97

WP2-D0202 Version 1.0 4.6.2003
2. The Moby Dick QoS architecture
Workpackage 2 (WP2) aims to define <strong>and</strong> implement the Moby Dick QoS components, i.e. QoS Broker,
QoS Attendant in the AR, QoS middleware for Mobile Terminal <strong>and</strong> radio support for QoS. WP2 also
defines, in collaboration with WP3 <strong>and</strong> WP4, the interactions between the QoS, mobility <strong>and</strong> AAAC subsystems
for different scenarios. In this section we briefly describe these scenarios, <strong>and</strong> track the
processing of a single packet in different levels of the protocol stack in each QoS component of the QoS
architecture, i.e the way a packet can receive appropriate QoS treatment.
2.1 Scenarios
Moby Dick network is based on a DiffServ model which is associated with CAC algorithms <strong>and</strong> resource
management performed by QoS Brokers. Before a user is allowed to use network resources, he or she
must be authenticated <strong>and</strong> authorised, <strong>and</strong> only then the admission control will be performed for the
specific service that will be used. If the resource requirements are within the profile of a user <strong>and</strong> the
resources are available, the QoS broker will allocate them <strong>and</strong> the user will be able to use the service.
After this process is concluded, the infrastructure maintains the allocated resources while the user moves
between different access networks within <strong>and</strong> between administrative domains.
2.1.1 User registration <strong>and</strong> authentication
First, when a user enters the network, he has to register. The user is supposed to have a Service Level
Agreement (SLA) with his network operator which defines a set of services. The goal of the registration
is to authenticate the user, i.e. to give him the right to access the network. The MT is connected to an
Access Router (AR).
An AAAC Attendant, located in the AR, acts as a proxy to the AAAC Server: it detects the user
registration request <strong>and</strong> forwards it to the AAAC Server for user authentication. First, the AAAC
Attendant sends an AA request over AAA protocol to his AAAC.f (i.e. the AAAC server in the foreign
domain), which forwards the request to the AAAC.h (i.e. the AAAC server in the home domain)
according to the Network Address Identifier (NAI). Note that in case the user is not roaming, the AAAC.f
is identical to the AAAC.h. The AAAC.h authenticates <strong>and</strong> authorises the user <strong>and</strong> sends a AAA protocol
reply back to the AAAC.f. In this message the network permissions of the user are already indicated. The
AAAC.f may then perform local authorisation decisions. The AAAC.f sends back a reply to the AR,
which forwards all relevant data to the MN via the user registration protocol.
Besides, the AAAC.f maintains a User Profile containing information about the user, such as its current
IP address, as well as QoS-relevant information. During the authentication process, in order to prepare the
authorisation or denial of the future Service Requests coming from the MT, the QoSB.f (QoS Broker in
the foreign domain) receives a subset of this profile - in particular the QoS-related information - from the
AAAC.f. These steps are shown in Figure 1.
1: AA Req.
6: AA Resp.
(DSCPs)
AAAC
2: AA Req.
Server
5a: AA Resp.
AR
3: AA Req.
4: AA Resp.
5b: NVUP Dump
QoS
Broker
AAAC
Server
Foreign
Domain
Home
Domain
Figure 1: QoS-related steps in the user registration process
2.1.2 Service request <strong>and</strong> authorisation
After being registered, the user is entitled to request a service. A service request is implicit, i.e. contained
in data packets. In fact, the MT directly sends data packets marked with a DiffServ Code Point (DSCP)
identifying the requested QoS service. For the purpose of the demonstration of the capabilities, the
CEC Deliverable Number D0202 13 / 97

WP2-D0202 Version 1.0 4.6.2003
services in Moby Dick test-bed are differentiated in terms of Class of Service (CoS) <strong>and</strong> b<strong>and</strong>width. Upon
receiving a user’s first packet marked with a certain DSCP, a QoS Attendant, located in the AR, triggers a
service request to the QoS Broker on behalf of the user, according to this DSCP.
Based on the QoS related part of the user profile received from the AAAC Server, the QoS Broker, which
is in charge of managing access network resources, verifies if the user is authorised to access the service
he is asking for. Next, if the resources are available, the QoS Broker allocates the needed resources in the
AR, by configuring the output queues <strong>and</strong>/or shaping the traffic, <strong>and</strong> in the RG (when a TD-CDMA
equipment is used), by triggering a QoS mapping between the IP QoS class <strong>and</strong> the radio QoS class, <strong>and</strong>
by consequently configuring the appropriate radio bearers. Thus, Moby Dick can support QoS without
explicit reservations at call-setup time, as in Figure 2.
1: 1 st packet
AR1
4: 1 st Packet AR2 7: 1 st Packet
4/8: Service
7: Service Reject
Reject
2: Service Req.
3: AR Config.
QoS
Broker
Domain 1
6: AR Config.
5: Service Req.
QoS
Broker
Domain 2
Figure 2: Service request <strong>and</strong> service authorisation
2.1.3 H<strong>and</strong>over
When a MT moves across the network, a few actions are required to maintain QoS. We only consider the
case of an intra-domain h<strong>and</strong>over: the inter-domain h<strong>and</strong>over is similar to a re-registration of the user in a
new foreign domain.
The following steps are required in order to enable a Fast H<strong>and</strong>over (FHO) while maintaining a user’s
QoS. When a h<strong>and</strong>over is initiated, some information about the services the MT is currently using, or is
authorised to use, is forwarded to the new QoS Broker managing the new AR (Figure 3).
Consequently, the new QoS Broker is able to configure the new AR. This step allows the MT to quickly
access the network resources from the new AR, without getting the AAAC architecture involved.
2: Router Solicitation for proxy
1: Router Adv.
nAR
3c: AR Config.
n. QoS
Broker
3: HO Initiate
4: HO Ack
3b: HoA, nCoA, DSCPs
5 <strong>and</strong> subsequent steps
oAR
3a: nAR, oCoA, nCoA
o. QoS
Broker
Figure 3: QoS-related steps in FHO process
2.2 QoS delivery process
Packet-by-packet QoS differentiation requires marking them with a DSCP. The network operator assigns
to each DSCP a certain level of QoS (in terms of b<strong>and</strong>width <strong>and</strong> priority). The marking operation is done
in the MT, at the IPv6 level, <strong>and</strong> is transparent to the applications. Applications are assumed to be QoSunaware
legacy applications which generate packets normally. Then, the packets are filtered at the IP
CEC Deliverable Number D0202 14 / 97

WP2-D0202 Version 1.0 4.6.2003
level, thanks to filters which are configurable at the user level <strong>and</strong> stored at the Linux kernel level. The
multi-field packet classification is done with these filters, <strong>and</strong> when there is a match the packet is marked
with the appropriate DSCP. The filtering <strong>and</strong> marking process is done when a packet is ready to be
transmitted to layer 2, i.e. when the header(s) of the packet contain(s) all the information needed to
identify the applications the packets belong to. Thus, for example, it is possible to mark a ftp flow by
filtering the UDP destination port of each packet.
When a packet is transmitted by an authenticated user, <strong>and</strong> uses an authorised service, the QoS Manager,
in the AR, places the packet in the appropriate outgoing queue, according to the DSCP. If the user sends a
packet with a wrong DSCP (i.e. usese an unauthorised service), the packet is simply dropped at the AR.
Finally, when a packet crosses a TD-CDMA equipment, the RG maps the IP QoS class of the packet into
a radio QoS class (at layer 2), <strong>and</strong> makes the packet use the appropriate radio QoS resources (the radio
bearers) allocated for it.
2.3 DSCP codes
Table 1. presents the DSCP used in the Moby Dick test bed:
Service Relative
Typical Usage
Name Class Priority
Service parameters
Description
DSCP
SIG AF41 2 Unspecified Signaling (network usage) 0x22
S1 EF 1 Peak BW: 32 kbit/s Real time services 0x2e
S2 AF21 3 CIR: 256 kbit/s
Priority (urgent)
data transfer
0x12
Three drop precedences (kbps): Olympic service
S3 AF1* 4
AF11 – 64
AF12 – 128
(better then
BE:streaming, ftp,
0x0a
0x0c
AF13 – 256
etc) 0x0e
S4 BE 0 Peak bit rate: 32 kbit/s Best Effort (BE) 0x00
S5 BE 0 Peak bit rate: 64 kbit/s Best effort 0x02
S6 BE 0 Peak bit rate: 256 kbit/s Best effort 0x04
Table 1: Classes of Service <strong>and</strong> associated DSCP codes
‘1’ denotes the highest priority, ‘4’ the lowest. ‘0’ means ‘no priority’. Note that the previous priorities
defined in D0201 were: 2a, 1, 2b, 2c, 3, 3 <strong>and</strong> 3. There is a one-to-one correspondence between Services
<strong>and</strong> DSCP. In all Moby Dick domains, <strong>and</strong> for the test-bed purpose only, the DSCPs are assumed to be
the same for same classes of service. This is called a ‘per world behavior’.
3. Software specification
To make different parts of the network architecture (security, mobility <strong>and</strong> QoS) work together, Moby
Dick defines several specific modules fulfilling specific functions, such as resource management, or
entities for interfacing AAAC-QoS-Mobility. In this section, we describe the software components
involved in the global QoS delivery process. These components, integrated at different levels of the
protocols stack, are located in three network entities: the Mobile Terminal, the Access Router <strong>and</strong> the
QoS Broker.
3.1 Overview of the software components
If a QoS Broker can be considered as a st<strong>and</strong>alone <strong>and</strong> independent entity, as shown in Figure 1, then
other QoS software components are often located in the same entity, <strong>and</strong> are part of the same protocol
stack, though they operate at different levels.
CEC Deliverable Number D0202 15 / 97

WP2-D0202 Version 1.0 4.6.2003
Mobile Terminal
NCP
IPv6, MIPL, IPsec,
DSCP marking
MTNM
RCF
Net. Device Drivers
Access Router
QoS
Attendant
FHm
AAA
Attendant
IPv6,IPsec, DiffServ
packet filter
Net. Device Drivers
Blocks developed inside the AAAC architecture
Blocks developed inside the QoS architecture
Blocks developed inside the Mobility architecture
Blocks not defined by Moby Dick
Figure 4: Software blocks in the MT <strong>and</strong> the AR
3.2 QoS Manager
3.2.1 Overview of the functionalities
In Moby Dick, the AR (shown in Figure 4.) performs functions typical of a DiffServ Edge Router: traffic
policing <strong>and</strong> shaping. Marking function in Moby Dick is not performed by the QoS Manager but by the
MT. Further the QoS Attendant located in the Access Router also manages the different priority queues,
<strong>and</strong> per hop behaviours. Thanks to a QoS Manager, the AR delegates the admission control decisions to
the QoS Broker, following the COPS (Common Open Policy Service) model, the AR being the Policy
Enforcement Point (PEP) <strong>and</strong> the QoS Broker the Policy Decision Point (PDP). The AR monitors the
traffic going from the access interfaces to the core interfaces, extracts some parameters of the packets <strong>and</strong>
constructs the query to the QoS Broker with these parameters.
In Moby Dick, the AR also plays a role in the FHO. With the Fast H<strong>and</strong>over module (FHm), the old AR
(oAR) notifies the QoS Broker of the preparation of a FHO to a new AR (nAR). If the QoS Broker
decides that the FHO can be made, it will push the QoS configuration to the new AR.
The AR performs also Per Hop Behaviour (PHB). PHBs are provided in the access interfaces for the
packets going from the core network to the access network, which an be e.g. a radio link with scarce
resources. DiffServ queue management <strong>and</strong> packet scheduling mechanisms are used to perform the PHB.
QoS guarantees are achieved in cooperation between the PHB enforcement at the AR <strong>and</strong> resource
management by QoS Broker following the COPS provisioning model. The AR informs the QoS Broker of
the load of its queues <strong>and</strong> the QoS Broker may reconfigure them.
These two functions (Policing/Shapping <strong>and</strong> PHP) of the QoS Manager are represented in Figure 5.
QoSManager in Access Router
Access
Network
PHB
Policing <strong>and</strong> Shapping
Policing deccissions
are outsourced
Core
Network
PHB is configured using
Provisionning model
QoSBroker
Interfaces
Packet flow
COPS
messages
Figure 5: Software blocks in the MT <strong>and</strong> the AR
CEC Deliverable Number D0202 16 / 97

WP2-D0202 Version 1.0 4.6.2003
The behaviour of the QoS Manager can be represented using a state machine, described in Figure 6 <strong>and</strong>
explained in Table 2.
0
Q4
Send REQ(FHOi)
4
5
7
8
Q5
Send KA
Q0
Send CO
Q2
1 Q1
2 3 Q3 16
Configure
Send REQ(conf)
Wait
Send RS(conf)
Q9
Clean up
Send CC
15
Q7 Wait for
QoSBmessage
6
13
9
10
Q6
Send RS(acc)
6b
14
Q8
Install
filter
11
12
Q7
Send REQ(AF)
Figure 6: QoS Manager state machine
No.
Signal
0 Start
1 CA received
2 DEC(conf) received
3 Always
4 Signal from FHO module FAST_HANDOVER_INI
5 Always (or DEC from QoSB)
6 Signal from FHO module: START_QOSB_LISTEN
6b Unsolicited DEC(Context Transfer) message received
7 KA timer expires
8 KA received
9 Accountig timer expires
10 Always
11 Time out to check for new packets <strong>and</strong> packet with new (CoA,DSCP,DestAddress) found
12 Positive DEC(AF) received
13 Always
14 Negative DEC(AF) received
15 DEC(AF) with reconf. Flag set received
16 End
Table 2: QoS Manager state machine
3.2.2 Procedures
The following procedure describes the decision making process (DEC) in case of a packet which does not
match any filter (Fig. 8):
CEC Deliverable Number D0202 17 / 97

WP2-D0202 Version 1.0 4.6.2003
unknown (CoA,DSCP)
Request Authorization
to the QoSB
-Send Autho. REQ to BB
Process
QoSB response
DEC from the QoSB received
DEC is negative
Unauthorized
Flow
END
Configure
DiffServ
logic
DEC is positive
-Install new filter using
The apropiate API functions
Update
DSCP table
-Add entry with the
(CoA,DSCP) <strong>and</strong> TTL
END
Figure 8: Decision making process for packet with unknown DSCP
When a FHO is initiated in the oAR, the following procedure is launched (Figure 9):
FHI received
Initiate FH
procedures as oAR
-Send the nAR, oCoA, nCoA to BB
END
Figure 9: FHO process in the oAR
Procedure depicted in Figure 10 describes a QoS context transfer in the AR when a FHO occurs:
DEC received
Update QoS context
-Update DSCP tabe
-configure filters in DiffServ
logic
END
Figure 10: Context transfer during FHO process in the oAR
The following procedure (Figure 11) occurs when the QoS Manager is (re)configured:
CEC Deliverable Number D0202 18 / 97

WP2-D0202 Version 1.0 4.6.2003
Inicite (re)configuration
Delete old
configuration
Query QoSB for new
Configuration
-Send conf. REQ to QoSB
DEC received
Configure
DiffServ
logic
-Install new queues using
The apropiate API functions
Send <strong>Report</strong>
To BB
END
Figure 11: QoS Manager re-configuration
This procedure is launched at start up of the QoS Manager (Figure 11):
AR startup
Open COPS
connection
- Send CO message <strong>and</strong>
Receive CA message
Configuration
procedure
END
Figure 12: FHO process in the oAR
3.3 QoS Broker
This section describes the software specification of the B<strong>and</strong>width Broker (QoS Broker).
A b<strong>and</strong>width broker is an entity that takes admission control decisions <strong>and</strong> configures all access
network components, according to a set of conditions given by administration entities:
It will enumerate the Moby Dick components that interact with the QoS Broker, the broker’s
interfaces, <strong>and</strong> all its internal description.
On each QoS Broker interface we will discuss the messages changed between the QoS Broker <strong>and</strong>
the other MobyDick’s components, its format <strong>and</strong> when they will occur. In the end of the document we
will present the QoS Broker databases format, <strong>and</strong> discuss its purpose.
Figure 13. shows a view of all the entities of the Moby Dick QoS-related entities that interact with
QoSBroker.
CEC Deliverable Number D0202 19 / 97

WP2-D0202 Version 1.0 4.6.2003
AAAC
Server
NMS
Entity
Router
QBroker
QBroker2
Computer
Cisco/Linux
Linux Router
Radio tower
Cisco
Router
Cisco
Router
Laptop
Telephone
Workstation
Server
Figure 13: Moby Dick QoS-related entities
These entities are:
• AAAC Server. The entity responsible for authenticating user information,
identifying the proper SLA (Service Level Agreement), keeping accounting
<strong>and</strong> charging information.
• NMS Server. The entity that makes core network configuration <strong>and</strong> defines
the available resources for the broker in each moment.
• “Other brokers”. Each broker has his own domain of action. To keep endto-end
QoS all brokers in the path need to interact.
• Network routers. Routers have to be configured according to the user
profile, <strong>and</strong> network conditions, so that QoS conditions can be achieved.
The Qos broker will be the responsible for the router configuration.
Figure 14. represents a block diagram of the QoS Broker components <strong>and</strong> internal communication flows.
AAACInterf
QBroker
FHOInterf
NMSInterf
NetworkDB
User
Profile
Data
QBrokerEngine
NetStatus
RGWClient
NetProbe
WebGUI
RouterInterface
Figure 14: QoS Broker components
The subsequent sections lists all the components with a brief description for each of them.
CEC Deliverable Number D0202 20 / 97

WP2-D0202 Version 1.0 4.6.2003
3.3.1 WebGUI
WebGUI is the module that enables the contact with the human operator. It was developed with
two proposes:
• it enables the QoSBroker configuration with the data edition in the NetworkDB database;
• it shows the network use status, showing the active reservations <strong>and</strong> the profiles authorised;
3.3.2 NetProbe
NetProbe is the entity that monitors network status. The collected information is inserted in a
database named NetStatus. This information <strong>and</strong> the information given by the NMSInterface represent the
network status, at every instant. QBrokerEngine will user this information to decide if it should or not
allow a new access to the network resources.
3.3.3 QBrokerEngine
QBrokerEngine is a process that manages several threads, one for each interface. The threads wait for
requests from the outside world. We will have:
• AAACAttendant – AAACAttendant will receive <strong>and</strong> answer the AAAC requests
• InterBrokerAttendant – InterBrokerAttendant receives external FHO data needed by
nQoSBroker to configure nAR.
• RouterAttendant – RouterAttendant will receive router requests that after processing the
QoSBroker answers. Those requests can to be summarized as follows:
o Data flow authorizing requests: AR requests QoSBroker to accept some data flow, <strong>and</strong>
QoSBroker after analysing network resource state answers accepting or rejecting that
flow;
o FHO requests: oAR contacts QoSBroker requesting the FHO process sending oCoA,
nCoA <strong>and</strong> nAR addresses. QoSBroker looks for nAR address
QBrokerEngine is responsible to launch, stop <strong>and</strong> manage those threads.
3.3.4 QoS Broker Interfaces
QoS Broker has several interfaces, one towards each Moby Dick architecture components. Figure 15.
shows this important aspect of the architecture. The interfaces are then characterised in the following
sections.
AAACInterf
RGWClient
QoSBroker
NMSInterf
RouterInterface
WebServer
BrokerInterface
Attendant
BrokerClient
Figure 15: QoS Broker interfaces
3.3.4.1 BrokerInterface
BrokerInterface is the module that interfaces with the neighbouring Brokers. This interface is used to
exchange external FHO information between oQosBroker <strong>and</strong> nQoSBroker. As soon as oQoSBroker
realises that nAR belongs to a domain of another QoSBroker it collects NVUP information <strong>and</strong>
reservation information related to the oCoA <strong>and</strong> sends it to the nQoSBroker. The communication between
QoSBroker is made using COPS protocol <strong>and</strong> the COPS API (COPSApi) is developed to enable
communications between the AAAC, the AR <strong>and</strong> the QoSBroker.
3.3.4.2 NMSInterface
This is the interface with NMS (Network Management System) entity that allows the NMS entity to
define the network resources that can be used by this broker. The interface should also allow access to
CEC Deliverable Number D0202 21 / 97

WP2-D0202 Version 1.0 4.6.2003
policy, alarm processing <strong>and</strong> service translation functions. This interface should also to be connected to
the database that keeps the network information, named NetStatus. It will receive a message
SendQoSBConfigData with parameter QOSB_CONFIGDATA.
3.3.4.3 AAACInterface
AAACInterface interfaces with the AAAC server. It defines the service QoS parameters at QoSBroker
start-up time, <strong>and</strong> dumps NVUP information to QoSBroker when any user registers in AAAC system.
Once the AAAC server starts running it connects with the QoSBroker <strong>and</strong> sends a message defining
QoS parameters used in the available services <strong>and</strong> the corresponding DSCP codes. Those parameters are
used in the network QoS management that QoSBroker does during its operation.
After user registration in the AAAC system, the AAAC server dumps NVUP information into the
QoSBroker defining the list of services that user will be able to use. The NVUP information contains
information such as CoA, authorisation timeout, <strong>and</strong> a list of services described by a source address,
destination address <strong>and</strong> a DSCP. It is also possible to have different timers to different services, because
each service may have its own timeout.
3.3.4.4 RouterInterface
RouterInterface is the entity that will interface the routers. It will have two modes of operation:
• receives the router request reservations: when a host starts sending a packet flow, the
Access Router (AR) will send a request to the QoSBroker through COPSDriver making a
resource reservation. QoSBroker analyses network usage state <strong>and</strong> sends an answer
accepting the new flow, or denying it.
• sends router configuration information: during AR startup, <strong>and</strong> when AR requests for a
configuration, the QoSBroker sends a set of parameters configuring the queues of the AR.
3.3.4.5 NMSInterface
NMSInterface is the interface through which the QoSBroker learns the resources of the core network that
are available for its own use.
The definition of those resources will be made by a data structure like:
UpstreamResoucesData
UpstreamBW
UpstreamDelay
This data will be sent to the QosBroker by a message like
SendQoSConfigData(UpstreamResoucesData);
3.3.4.6 RGWClient
This interface is used to open a radio barrier in the radio gateway.
3.3.4.7 Data format for communications between Radio Gateway <strong>and</strong> QoSBroker
qosb_radio_bearer_info_t: This structure defines a radio bearer information. It conveys the following
information:
- dscp;
- radio_QoS_class;
- status;
radio_access_allocation_msg_t: This structure defines a message QoSBroker sends to Radio Gateway
- type: Only one type of message, but keep it for compatibility;
- nb_entries: number of valid entries in info array;
- Home_Addr: home address of the MT attached to radio gateway;
- qosb_radio_bearer_info_t: an array of radio barer information structures;
CEC Deliverable Number D0202 22 / 97

WP2-D0202 Version 1.0 4.6.2003
3.3.4.8 Messages exchanged between Radio Gateway <strong>and</strong> QoSBroker
OpenChanel: QoSBroker sends a message to Radio Gateway opening a radio barer.
3.3.5 <strong>Implementation</strong> details of selected interfaces
Now we will describe the implementation of the interfaces <strong>and</strong> databases. We start with the
interface description. In later sections we analyse the databases used by the broker <strong>and</strong> their structure <strong>and</strong>
define the data that is used in messages exchanged over the interfaces.
3.3.5.1 AAACInterface
AAACInterface interfaces with the AAAC server.
3.3.5.1.1 Data format interchanged between QoSBroker <strong>and</strong> AAAC
NVUP (Network View of User Profile). It represents the subset of the user profile that the network needs
to know. The subset includes:
-User ID / NAI;
-Home Domain / Home service provider;
-Source address;
-N services: number of services a user subscribes;
-Array of N elements with:
-Destination address;
-Authorisation timeout;
-DSCP signalling code;
DSCP signalling code can be very useful in a situation of a foreign domain access with different QoS
signalling. For each user a set of N services that can be used by him is defined. Each service has an
authorisation timeout, a destination address, a QoS Profile describing QoS parameters for this service, <strong>and</strong>
a DSCP signalling code. Translation of user profiles in different domains is a task of AAAC.
QoSProfile – QosProfile represents the QoS conditions of some profile. The profile defines several
parameters:
-DSCP;
-B<strong>and</strong>width;
-Priority;
-Minimum Delay;
3.3.5.1.2 Messages exchanged between AAAC <strong>and</strong> QoSBroker
Several messages are used in this communications at different time instants:
1. Before Operation: SendQoSProfile(QoSProfile) – Used by the AAAC to define to the
QoSBroker the QoS Profiles, <strong>and</strong> its QoS parameters;
2. Registration time: AuthorizeProfile(NVUP) - AAAC signals QoSBroker to allow resource
usage (for a user). Resources are not yet reserved, this is done at session setup time;
3. Deregistration time: DeAuthorizeProfile(NVUP) – AAAC signals to QoSBroker to release
resources used by that user;
The communication between the AAAC <strong>and</strong> the QoSBroker is carried on using a COPSApi that
implement a COPS-like protocol as messages aren't answered by the QoSBroker. The reason is that it was
decided for scalability reasons that the AAAC server shouldn't wait for the QoSBroker answer each time
it sends a message.
3.3.5.2 RouterInterface
As stated before RouterInterface is the interface to other routers. Figure 16. shows its internals.
CEC Deliverable Number D0202 23 / 97

WP2-D0202 Version 1.0 4.6.2003
QBroker
QBrokerEngine
NetProbe
VirtualRouter
CLIDriver
COPSDriver
Linux Router
Figure 16: RouterInterface internals
The elements in Figure 16. include:
• VirtualRouter: It chooses the driver that should to be used to communicate with some
specific router;
• CLIDriver: CLIDriver is the driver used to communicate with routers that we should
communicate by Comm<strong>and</strong> Line Interface;
• COPSDriver: COPSDriver is the driver used to communicate through COPS.
The incoming messages from the routers that request some network resource are mapped from the
COPSDriver directly to the QBrokerEngine. The outgoing messages, from the QBrokerEngine to the
routers, messages to make some configuration, or simply to analyse the network status are passed to the
VirtualRouter. Next we describe in more detail, these components <strong>and</strong> their implementation.
3.3.5.3 VirtualRouter
VirtualRouter which is shown in Figure 17. is a kind of virtual driver that will interface the Router
Interface <strong>and</strong> the router drivers that broker use to configure the routers. It has a database that keeps
information about the routers, its vendors, its models, <strong>and</strong> its communication format.
Router Interface
VirtualRouter
Engine
Router
List
Database
CLIDriver
COPSDriver
Cisco
Router
Linux Router
Figure 17: Virtual Router
When a virtual router receives a message that should be sent to a router it should verify routers
communication format <strong>and</strong> the use the correct driver to send that message. Like that we are able to have
different protocols to be used to “talk” with different routers. Such a architecture was chosen because:
• The program uses the drivers as an abstraction to communicate with all the routers without
taking care about specific router communication details, making development easier;
• Makes the program evolution easier, when a new router arise the only thing needed is to add a
new entry in the database <strong>and</strong> add the specific router comm<strong>and</strong>s in the database.
3.3.5.4 CLIDriver
CLIDriver is the driver that will communicate with the routers using Comm<strong>and</strong> Line Interface (Figure
18). It will receive requests from the VirtualRouter <strong>and</strong> then forward them to the routers through a set of
instructions that are present in the database.
CEC Deliverable Number D0202 24 / 97

WP2-D0202 Version 1.0 4.6.2003
Router Interface
VirtualRouter
Engine
Router
List
Database
CLIDriver
Engine
CLI
Comm<strong>and</strong>
Cisco
Router
Router
When a Virtual Router receives a message for a CLI router, it sends this message to this driver.
CLIDriver checks in this database how to format the message in routers CLI comm<strong>and</strong>s. Then it will send
the list of comm<strong>and</strong>s one by one to the router, making the message configuration.
3.3.5.5 COPSDriver
COPS protocol was specially designed to exchange network policy information between the policy
decision point (QoS Broker) <strong>and</strong> the policy enforcement points (ARs) – Figure 19. When the router starts
receiving a set of packets from a user with some QoSProfile code, it will ask the QoSBroker for resources
reservation for that flow. After analysing the network conditions the QoSBroker will send an answer that
will be applied by the router. In order to supply the QoSBroker with all needed information to the router
<strong>and</strong> the QoSBroker should change some messages with some data.
User
Profile
Data
Figure 18: CLIDriver
QBroker
QBrokerEngine
NetStatus
RouterInterface
COPSDriver
Linux Router
Figure 19: COPSDriver as a PDP interface
COPS communication between AR <strong>and</strong> QoSBroker is made by the COPSApi. The Api implements a
COPS-RSVP-like protocol, with the exception in the FHO message that is the only unsolicited message
that the Api supports. This interface uses the exchange of Keep-Alive messages in order to to announce
its running state to the network elements that they are connected.
3.3.5.5.1 Data format interchanged between AR <strong>and</strong> QoSBroker
BehaviourData: It describes the QoSManager queues parameters. This structure contains numerous
parameters:
- dscp_b;
- dest_addr;
- queue_type;
CEC Deliverable Number D0202 25 / 97

WP2-D0202 Version 1.0 4.6.2003
- behaviuor;
- borrow_flag;
- min_gred_queue;
- max_gred_queue;
- prob_gred_queue;
At a start-up time of a QoSManager it requests the configuration from QoSBroker. QoSBroker collects an
array of BehaviourData from describing QoSManager queues information <strong>and</strong> sends them to
QoSManager.
RD (Resource Description). It describes the resource that is being requested to the AR by a host. The
description contains:
-Source address;
-Destination address;
-DSCP signalling code;
FHOData(Fast H<strong>and</strong>over data). It describes the FHO process being requested to the QoSBroker. This
structures contains:
- oCoA ( the old CoA): the address used by a MN that is making a FHO;
- nCoA ( the new CoA): the address that will be used by the MN after the FHO process;
- nAR ( new AR): the address of the router that will connect the MN after the FHO.
FHOServReserv (Fast H<strong>and</strong>over Service Reservation): is the fast h<strong>and</strong>over registered service
description sent by the QoSBroker to the nAR after a FHO decision was taken. This data structures
contains:
- SourceAddress (Source address): is the source address of the registered service for the MN;
- DestAddress (Destination address): is the destination address of the service registered to that
MN;
- DSCP: is the DSCP of the registered service;
- PolicyBW (Policy B<strong>and</strong>width): are the b<strong>and</strong>width-related values sent to nAR ; used for the data
rate parameters of the queue that is created to keep this service packets;
- PolicyBurst (Policy Burst): is the burst rate value that defines the burst rate of the queue that
AR will create to keep this service packets;
A FHO answer is sent from QoSBroker to the nAR having a FHOServReserv for each registered service
that the MN owns in the QoSBroker. For a MN having N registered services in the QoSBroker the
message has an array of N FHOServReserv structures defining those services.
3.3.5.6 Messages exchanged between AR <strong>and</strong> QoSBroker
During AR <strong>and</strong> QoSBroker operation several messages are exchanged between the two:
- ConfigRequest: is a configuration request made by AR in order to know configuration it
should give to its interface queues. This message is sent at AR start-up <strong>and</strong> after QoSBroker
shows its configuration intention flag. Each time QoSBroker detects the need of reconfiguring
AR it will wait for the next AR requests <strong>and</strong> then the QoSBroker will set the reconfiguration flag
in the answer it send to AR. After receiving the message with this flag AR makes a configuration
request to QoSBroker.
- ConfigDec: is the configuration message sent by the QoSBroker to the AR describing the
interface queues parameters. This message sends data
- ResourceRequest: the message sent by QoSManager to QoSBroker requesting for accepting a
flow described by the RG structure. QoSBroker, accepting or denying that flow acceptance
answers this message.
- ReleaseResource: the message send by QoSManager requesting QoSBroker to deallocate those
resources described in the RG structure.
- FHORequest: the FHO request sent by oAR to QoSBroker that defines the oCoA, the nCoA
<strong>and</strong> nAR. QoSBroker analyses this request <strong>and</strong> send an answer to oAR.
CEC Deliverable Number D0202 26 / 97

WP2-D0202 Version 1.0 4.6.2003
- FHODecision: the FHO decision sent form QoSBroker to oAR. After analysing the FHO
request <strong>and</strong> network resource availability QoSBroker sends an answer to nAR.
3.3.6 Interface summary
The following table summarises all the interface information, messages, data exchanged <strong>and</strong> message
timing:
Interface Timing Message Send data
AAAC
QoSBroker SendQoSProfile
Services Description
start-up
User
AuthoriseProfile
NVUP
registration time
User
registration
removal
DeAutorizeProfile
AR
Before run-time ConfigRequest
RouterConfig
ChangeConfig
Run-time ResourceRequest
Resource
ResourceRelease
In a h<strong>and</strong>over H<strong>and</strong>overRequest
H<strong>and</strong>overResource
H<strong>and</strong>overDec
NMS Any time SendQoSConfig QoSResourceData
QoSBrokerInterface External RequestH<strong>and</strong>over
H<strong>and</strong>overResource
Hanover
process
Radio Gateway In a new Radio
Gateway flow
OpenChannel
radio_access_allocation_msg_t
3.3.7 <strong>Implementation</strong> of databases
QoS Broker has several databases. Depending on their size <strong>and</strong> frequency of queries these
databases are stored in memory or in a file.
3.3.7.1 NetworkDB
NetworkDBs is the database that keeps the information about the network topology. It keeps information
about each router that the broker manages, its load information, the queues defined to each of its
interfaces, the scheduling algorithm applied to each interface, the occupancy of each queue <strong>and</strong> the
resources that the NMS assigned in this broker. The database has six tables:
• Router. Router table keeps information such as router memory, processing capacity, router
load, <strong>and</strong> its state;
• Interface. Represents the router interfaces. It keeps information such as Interface address,
the scheduling discipline used by the interface, <strong>and</strong> interface state;
• Queue. Represents the interface queues. It keeps the queue memory, queue occupancy,
queue priority;
• QueueConf: Defines the parameters of the AR queues;
• RadioGW: Lists the radio gateways that are part of a QoSBroker domain. It stores the radio
network address, as well as its network address <strong>and</strong> network mask;
• NetService: It describes the QoSBroker network services, as well as the mapping existing
between services <strong>and</strong> radio classes;
CEC Deliverable Number D0202 27 / 97

WP2-D0202 Version 1.0 4.6.2003
PK,FK1,FK2
PK
QueueConf
DSCP
InterfaceBW
B<strong>and</strong>width
AgregNumb
Borrow
MinGRED
MaxGRED
DropNumb
LimitGRED
QueueID
PK,FK1
FK2
Interface
InterfaceID
Address
Active
IsCoreInterface
TotalB<strong>and</strong>width
RefDisciplineID
RefRouterID
QueueID
PK
FK1
Router
RouterID
Active
AvailBW
Login
Pass
EnablePass
Name
RefBrokerID
InterfaceID
Broker
PK
Queue
QueueID
DSCP
DropNumber
SentNumber
YellowMarked
RedMArked
Occupation
OverLimits
BurtSize
Rate
BufferSize
YellowThreshold
RedThreshold
RefInterfaceID
NetService
PK DSCP
Name
RadioClass
FK1 QueueID
PK,FK1,FK2
PK
RadioGW
BrokerID
Address
Active
RadioGWID
CoreInterf
NetInterf
RefInterfaceID
RefBrokerID
Figure 20: NetStatus database structure
3.3.7.2 NetStatus
NetStatus database (Figures 20 <strong>and</strong> 22) keeps the information about the network state including
information about network usage <strong>and</strong> authorised user profiles in this network. This database has the
following tables:
- NVUP: Keeps the information about the NVUP of the registered user;
- NetService: Has the authorised service list of the registered users;
- Reservations: Keeps a list of network services in use by a network user;
NVUP
NetService
Reservations
PK
NVUPID
PK
ServiceID
PK
ReservID
NAI
CoA
Timeout
FK1
SourceAddress
DestAddress
DSCP
Timeout
RefNVUPID
SourceAddress
DestAddress
DSCP
Timeout
RefRouterID
Figure 22: NetStatus database
3.4 The DSCP marking software
The DSCP marking software (DMS) has been developed in two steps. A first version of the software,
tested <strong>and</strong> integrated in the Moby Dick test bed in Madrid, in October 2002, provided only a very limited
CEC Deliverable Number D0202 28 / 97

WP2-D0202 Version 1.0 4.6.2003
set of filtering capabilities, based on the IPv6 main header <strong>and</strong> the transport headers (TCP <strong>and</strong> UDP)
fields.
The second version of the DMS, provided <strong>and</strong> integrated in Nice at the end of March 2003, provided
additional filtering capabilities, including the possibility to filter different IPv6 extension headers fields,
the ICMPv6 header fields <strong>and</strong> the inner-header DSCP of tunneled packets. These new capabilities allow
the user, or the MT administrator, to define filters based on a large panel of fields in the outgoing packets.
They also offer the possibility to clearly distinguish signalling packets from data packets. The importance
of this last aspect of the DMS resides in the fact the signalling traffic has high priority in the network. The
signaling CoS is often not charged by the network operator, even if the amount of signalling traffic each
MT is authorised to send through the network is limited. Another enhancement of this second version was
to allow each MT to load from the network the DSCP values in use in each domain.
In this section, we only describe the final specifications of the DMS.
3.4.1 Operation
When a new packet is ready to be transmitted to the layer two, the DMS inspects its header <strong>and</strong> consults a
DSCP Matching Table. This table contains a set of filters to apply on the information extracted from the
header, <strong>and</strong> the values of the associated DSCPs. Then, if one of the filters matches perfectly with this
information, the packet is marked with the value of the DSCP associated with this filter.
3.4.2 DMS Architecture
Kernel Space
User Space
DSCP Marking
Function (IPv6)
Table update
Module
Service
Table
DSCP
Matching
Table
Filters
Db
Rules1.txt
Rules2.txt
Rules3.txt
Figure 23: DMS Components
The DMS contains five components, as in Figure 23:
• a DSCP Matching Table (DMT): this table contains the definition of every filter <strong>and</strong> the
DSCP associated with it in the Linux kernel space,
• a DSCP Marking Function (DMF): this is the DMS engine, which consults the fields in the
different headers of each packet, compares it with the filters in the DMT, <strong>and</strong> decides to
mark or not the packet with a new DSCP; it is located in the Linux kernel (in the IPv6 code),
• a Filters Database (FD): this file (or set of files) contains the definitions of all the filters, in
the user space,
• a Table Update Module (TUM): this is a Linux module in charge of updating the DSCP
Matching Table with the data stored in the Filters Database,
• a Service Table (ST): this table, only used by the TUM, associates a DSCP with each
service.
3.4.3 DSCP Matching
The packet marking process is based on the search of a table containing all the filters definitions
whenever a packet is ready to be transmitted. In this section, we describe how these filters are introduced
by a user, <strong>and</strong> how the DMT is built <strong>and</strong> updated.
3.4.3.1 Packet filtering
The description of a filter is as follows:
CEC Deliverable Number D0202 29 / 97

WP2-D0202 Version 1.0 4.6.2003
Filter
Description
TCPDestPort
IP6SrcAddr
CoS
10
FTPFilter
21
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
S1
The complete descriptions of the filters are stored in one or several files (the FD). Each file is loaded in
the DMT with help of the TUM. Then, when a packet is ready to be delivered to the lower layer, the DMF
consults the DMT, <strong>and</strong> marks the packet with the DSCP associated with the first filter that matches with
the information of its header(s).
A filter contains:
• An identifier (the ‘Description’ field), which also represents its priority. Thus, if two filters
match, only the first one, i.e. the one with the lowest identifier, is considered.
• A description, i.e. a filter name.
• A CoS: the value of this field can be either a service identifier (S1, S2, …) or a DSCP. If this
value is a service identifier, then the DSCP associated with the filter will be found by the TUM
in the ST.
• A list of items, with their values. The number of items is not limited, <strong>and</strong> a list of items can be
empty (then, all the packets are marked with the DSCP associated with the filter). Packets are
marked with the DSCP associated with the filter only if all the items values are equal to the
corresponding fields values in the different headers of the packet. On the previous example, a
packet will be marked with the ‘101110’ DSCP (which is associated with the S1 service in the
ST) only if, in the packet headers, the TCP Destination Port is set to ‘21’ <strong>and</strong> the IPv6 Source
Address is set to ‘FEDC:…:3210’. If only one value doesn’t match, then the filter also doesn’t
match.
Typically, each description can use all the possible fields of the different headers added by the network
<strong>and</strong> the transport layers. This software supports a large subset of these fields, in the following headers:
IPv6 main header, TCP, UDP, Destination option (including the Binding Update, Binding
Acknowledgment, Binding Request, <strong>and</strong> Home Address options), Routing option, Hop-by-hop option,
Authentication option, Encapsulating Security Payload (ESP) option, Fragment option, IPv6 (tunneling),
<strong>and</strong> ICMPv6.
The goal of this software is simple: the filtering rules will not be directly written in the. In fact, the
software will offer the possibility to filter packets using a more or less complete subset of the different
header fields. Only the user, <strong>and</strong>/or the network administrator, thanks to their good knowledge of the
network protocols, will be able to define precisely these rules. Thus, the code of the software will be the
same in all the different entities of the network using it, <strong>and</strong> in all the different QoS domains. Only the
contents of the filters will change from an entity to another, or from a QoS domain to another.
A filter can support the following fields (Table 3):
Field name Format Description
Control fields (m<strong>and</strong>atory)
Filter Decimal (0 to 99) Number <strong>and</strong> priority of the filter
Description Text (without spaces) Name of the filter
CoS String (S) Service Identifier (S1, S2, …SN) or DSCP
or Binary (1 to 6 bits)
IPv6 main header fields
IP6DSCP Binary (6 bits) Current DSCP of the packet
IP6FlowLbl Decimal (0 to 16777215) Flow label of the packet
IP6PayloadLen Decimal (0 to 655350) Length of the data after the IPv6 header
IP6HopLim Decimal (0 to 255) TTL of the packet
IP6SrcAddr IPv6 address format
IPv6 source address of the packet
(Hexadecimal):
X:X:X:X:X:X:X:X
with X=FEC0 or X=3245,
…
‘::’ is supported
IP6DestAddr IPv6 address format
IPv6 destination address of the packet
(Hexadecimal)
ICMPv6 header fields
CEC Deliverable Number D0202 30 / 97

WP2-D0202 Version 1.0 4.6.2003
ICMP6Header Decimal (1 or 0) ICMPv6 packet detection
ICMP6Type Decimal (0 to 255) ICMPv6 packet type
ICMP6Code Decimal (0 to 255) ICMPv6 packet code
Binding Update fields (part of the Destination Option)
ExtBU Decimal (1 or 0) Binding Update detection
ExtBULg Decimal (0 to 255) Binding Update length
ExtBUA Binary (1 bit) Binding Update acknowledgement request
ExtBUH Binary (1 bit) Home Agent request
ExtBUR Binary (1 bit) Mobile Router
ExtBUD Binary (1 bit) Duplicate Address Detection request
ExtBUMAPReg Binary (1 bit) MAP registration
ExtBUBicast Binary (1 bit) Bicasting request
ExtBUResv Binary (2 bits) Binding Update reserved/unused bits
ExtBUPrefLg Decimal (0 to 255) Length of the prefix to use for MT addresses
ExtBUSeq Decimal (0 to 65535) Binding Update sequence number
ExtBULTime Decimal (0 to 4294967295) Association lifetime
Binding Acknowledgement fields (part of the Destination Option)
ExtBA Decimal (1 or 0) Binding Acknowledgement detection
ExtBALg Decimal (0 to 255) Binding Acknowledgement length
ExtBAStatus Decimal (0 to 255) Binding Acknowledgement status
ExtBASeq Decimal (0 to 65535) Binding Acknowledgement sequence number
ExtBALTime Decimal (0 to 4294967295) Association lifetime
ExtBARefresh Decimal (0 to 4294967295) Refreshing period
Binding Request fields (part of the Destination Option)
ExtBR Decimal (1 or 0) Binding Request detection
ExtBRLg Decimal (0 to 255) Binding Request length
Home Address fields (part of the Destination Option)
ExtHoA Decimal (1 or 0) Home Address detection
ExtHoALg Decimal (0 to 255) Home Address length
ExtHoAAddr IPv6 address format
Main Home Address
(Hexadecimal)
Sub-options detection (for Destination Option only)
ExtSoptUI Decimal (1 or 0) Unique Identifier sub-option
ExtSoptACoA Decimal (1 or 0) Alternate Care-of-Address sub-option
ExtSoptAD Decimal (1 or 0) Authentication Data sub-option
Hop-by-hop Option fields
ExtHop Decimal (1 or 0) Hop-by-Hop option detection
ExtHopType Decimal (0 to 255) Hop-by-Hop option type
ExtHopLg Decimal (0 to 255) Hop-by-Hop option length
ExtHopRAVal Decimal (0 to 65535) Router Alert value
ExtHopJDataLg Decimal (0 to 255) Jumbo packet data length
Fragment header fields
ExtFrag Decimal (1 or 0) Fragment header detection
ExtFragPlace Decimal (0 to 8191) Place of the fragment in the data
ExtFragM Binary (1 bit) Fragment header M bit
ExtFragId Decimal (0 to 4294967295) Packet identifier (same ID for all the fragments of a
same packet)
Routing header fields
ExtRout Decimal (1 or 0) Routing header detection
ExtRoutLg Decimal (0 to 255) Header length in number of 64 bits words minus one
ExtRoutType Decimal (0 to 255) Routing header type
ExtRoutSeg Decimal (0 to 255) Number of remaining segments (nodes to cross)
ExtRoutAddrN IPv6 address format
One address to search into the address list
(Hexadecimal)
ExtRoutAddrDest IPv6 address format
Destination address in the address list
(Hexadecimal)
Authentication header fields
ExtAuth Decimal (1 or 0) Authentication header detection
CEC Deliverable Number D0202 31 / 97

WP2-D0202 Version 1.0 4.6.2003
ExtAuthResv Decimal (0 to 65535) Reserved bits
ExtAuthSeq Decimal (0 to 4294967295) Sequence number
ExtAuthSPI Decimal (0 to 4294967295) Security Parameters Index (SPI)
ExtAuthData Boolean (1 or 0) Authentication data
ESP header fields
ExtESP Decimal (1 or 0) ESP header detection
ExtESPSPI Decimal (0 to 4294967295) Security Parameters Index (SPI)
ExtESPSeq Decimal (0 to 4294967295) Sequence number
TCP header fields
TCPHeader Boolean (1 or 0) TCP header detection
TCPSrcPort Decimal (0 to 65535) TCP source port
TCPDestPort Decimal (0 to 65535) TCP destination port
TCPSeq Decimal (0 to 4294967295) TCP sequence number
TCPAckSeq Decimal (0 to 4294967295) TCP acknowledgement sequence number
TCPDataOff Decimal (0 to 63) Offset of the data in the TCP header
TCPRsv Decimal (0 to 15) 4 reserved bits in the TCP header
TCPCtrlCwr Binary (1 bit) Congestion Window Reduced bit
TCPCtrlEce Binary (1 bit) ECN-Echo bit
TCPCtrlUrg Binary (1 bit) Urgent bit
TCPCtrlAck Binary (1 bit) Acknowledgement bit
TCPCtrlPsh Binary (1 bit) Push bit
TCPCtrlRst Binary (1 bit) Reset bit
TCPCtrlSyn Binary (1 bit) Synchronization bit
TCPCtrlFin Binary (1 bit) Fin bit (end of transmission)
TCPWin Decimal (0 to 65535) Size of the window the receiver is able to receive
TCPUrgPtr Decimal (0 to 65535) Urgent data pointer
UDP header fields
UDPHeader Boolean (1 or 0) UDP header detection
UDPSrcPort Decimal (0 to 65535) UDP source port
UDPDestPort Decimal (0 to 65535) UDP destination port
UDPLen Decimal (0 to 65535) Length of the UDP datagram
Tunneled packet fields
Tunnel Boolean (1 or 0) Tunneled IPv6 packet detection
TunnelDSCP Binary (6 bits) DSCP of the inner packet
Table 3: Filtering rules list
3.4.3.2 DSCP Matching Table
When a user, or a network administrator, triggers a modification of the filters descriptions, the TUM
modifies the DMT automatically. In this section, we describe how this table is organized.
Filter number
(= line number)
0
1
2
3
4
…
N
Filter Pointer
Filter0Ptr
NULL
Filter2Ptr
Filter3Ptr
NULL
…
FilterNPtr
Table 4: Format of the DMT
Each line of the table only contains a pointer to a complete description of a filter loaded in the memory
(see Table 4).
CEC Deliverable Number D0202 32 / 97

WP2-D0202 Version 1.0 4.6.2003
Each filter is a simple structure containing a description, the DSCP (CoS) used to mark each packet that
matches this filter, a set of bits identifying the different headers to examine, <strong>and</strong> a pointer to a list of items
representing the different fields of the packet header that are to be inspected (see Figure 24). Thus, the
number of fields in a filter is variable. The bits identifying the different headers to examine accelerate the
filtering process. Indeed, if a filter contains items related to TCP fields, <strong>and</strong> if the packet does not contain
a TCP header, the filter doesn’t match, <strong>and</strong> browsing its items list <strong>and</strong> the header fields’ values becomes
useless. The use of these bits avoids useless treatments in the DMF.
Every item of this list contains an identification of the field to inspect, i.e. a value identifying the name of
the field in the kernel (IP6_SRC_ADDR is equivalent to the IP6SrcAddr field in the FD,
TCP_SRC_PORT is equivalent to the TCPSrcPort field, etc.), the expected value of this field, <strong>and</strong> a
pointer to the next item.
Desc.: ANiceFilter
Headers: IP6, TCP
CoS: 101101
Items list: item1
Ident.: IP6_SRC_ADDR
Value: FEC0::1
Next: item2
Ident.: IP6_DSCP
Value: 010110
Next: item3
Ident.: TCP_SRC_PORT
Value: 21
Next: NULL
Figure 24: Representation of a filter in the Linux kernel
It is possible that the information extracted from the packet header matches with several filters. Only the
first filter is taken into account. Thus, the number of the filter, which is the range of the filter in the table,
represents its priority. The lower is this number, the greater is the priority of the filter. So, it is important
to sort the filters from the more detailed to the less detailed.
Table updates
The TUM modifies the DMT each time the user, or the network administrator, modifies the FD <strong>and</strong>
communicates it to the module (Figure 25). The modified FD – which is a single text file – is forwarded
to the module over a simple Linux character device (/dev/dscp). This solution is the simplest way to
communicate information from the user space (here, the FD) to the kernel space where the DMT is
located.
Thus, the user only has to write on this device with the contents of the FD (by the ‘cat filters_database.txt
> /dev/dscp’ comm<strong>and</strong> for ex.). Then, the TUM automatically reads the text written on the device, <strong>and</strong>
updates the DMT in the Linux kernel. Note that it is not necessary to write the entire FD on the device to
update properly the DMT: only a file containing new filters, or a subset of modified filters can be
communicated to the TUM.
User
AAAC
Table update
Module
3b
Filtering Rules & DSCP
1 2 3a
Service
Table
Character device
/dev/dscp
1: Filters writing
2: Filters reading
DSCP
Matching
Table
3a: DSCP update
3b: Filters update
CEC Deliverable Number D0202 33 / 97

WP2-D0202 Version 1.0 4.6.2003
Figure 25: DMT <strong>and</strong> SC update process
For the moment, the table update process is triggered manually, by writing on the /dev/dscp character
device. However, it is possible to make the AAAC system update the FD, in the same way than the DSCP
update (see section 3.4.6) or triggering automatic updates regularly, in the user space.
3.4.4 DSCP marking
DSCP marking is done thanks to a modification of the Traffic Class <strong>and</strong> Flow Label fields in the IPv6
header. When the information of the packet header matches with a filter, the corresponding DSCP is
marked in the header of the packet: the four first bits of the DSCP are stored in the last four bits of the
Traffic Class field, <strong>and</strong> the last two bits, plus two bits set to ‘0’, are stored in the four first bits of the Flow
Label field.
DSCP
Vers
TC
…..
Flow Label
Figure 26: DSCP bits in the IPv6 main header
3.4.5 Packet re-marking
This operation is supported by the DMT, if the DMS is installed in a Linux router. To re-mark packets,
the network administrator has just to add a new filter, containing a ‘IP6DSCP’ item, in the FD. This filter
evaluates the DSCP in the new packet header, <strong>and</strong> associates a new value with it.
3.4.6 DSCP updates
In the first version of the DMS, provided in October 2002, the ‘CoS’ field value in each filter in the FD
was only a DSCP (e.g. ‘110110’, …). However, if we consider that several users can be located on the
same MT, but with different QoS contracts, the same applications may use different QoS services for two
different users. Thus, when a user enters in a new domain, she has to load the proper DSCP for each
service she’s authorized to ask for, <strong>and</strong> to associate each service to each application she can launch. The
second version of the DMS, provided in March 2003, offers the possibility to the user to use both DSCP
values <strong>and</strong> service identifiers in her filters. In fact, a user can write a service identifier in the ‘CoS’ field
instead of a DSCP, <strong>and</strong> the TUM associates itself this service identifier with a DSCP value, loaded from
the network, thanks to the Service Table.
So, when a user registers, the AAAC module in the MT simply sends a list of service identifiers, with
their associated DSCPs, to the TUM, via the /dev/dscp character device (see Figure 25). For example, it
can write ‘SIG 50’, ‘S1 5’, ‘S2 10’, ‘S3 15’, …, ‘S7 35’ on the device. Then the ST looks like in Table 5.
Service DSCP
SIG 50
S1 5
S2 10
S3 15
S4 20
S5 25
S6 30
S7 35
Table 5: Service Table example
What we call here a ‘service’ is only a marking type. The service notion in the MT is lightly different
from the service notion in the network. In fact, S1 means ‘the first service marking type’. So, if the user is
CEC Deliverable Number D0202 34 / 97

WP2-D0202 Version 1.0 4.6.2003
authorized to use only a subset of the network services, it is possible that several marking types will have
the same value, which means that different applications associated with different service names may, in
fact, use the same DSCP.
During the user registration, the MT will always receive seven DSCP codes, which is the number of CoS
defined in Moby Dick. The filters will also be the same in all the Mobile Terminals.
By default, all the DSCPs are set to 0, excepted the SIG value, which is set to 34 (100010 in binary). Each
DSCP can be manually initialised, by the user or the MT administrator himself, by writing ‘SX DSCPX’
on the /dev/dscp character device, where X is the service number. However, a manual initialisation of the
DSCPs is probably useless, considering that a user cannot send traffic towards the network without
registering first.
3.5 The radio resource management
All Radio Resource Management (RRM) functions located in the Core Network of traditional UMTS
infrastructures have disappeared, as we implemented a True-IP signaling approach. The IP QoS Control
procedures, based on DiffServ codepoints, must now be directly mapped onto the physical layer
(replacing the former UMTS RRM procedures). Figure 4 has presented the Mobile Terminal <strong>and</strong> Access
Router components involved in the h<strong>and</strong>ling of TD-CDMA radio resources.
This new approach is controlled by the QoS Broker. When a new service is started, it maps the IP DSCP
code of the first packet received by the Access Router onto one of the Radio QoS classes <strong>and</strong> sends a
request to the QoS Mapping component in the Radio Gateway, requesting the allocation of the
corresponding resources. This entity stores the mapping information <strong>and</strong> forwards the request to the
Radio Resource Control (RRC) entity of the Radio Interface Protocols constituting the Access Stratum.
The process in the TD-CDMA Access Stratum is shown in Figure 27.
NAS
Config generation
DSCP, Radio class N°, RB N°
RRM
IP class UMTS class Qos parameters (BER, delay, ..)
S1
S3
S4
S5
S6
Broadcast
FACH RACH
RG Config
Mapping Table
MS0
MS1
RRC RG
…
Config table
Figure 27: Computing of TD-CDMA radio parameters in the Radio Gateway
With the help of a new RRM entity, the RRC computes the changes of the radio parameters needed in the
RG <strong>and</strong> the MT to ensure a proper operation of the other Radio Interface Protocols shown in Figure 28:
PDCP, RLC, MAC <strong>and</strong> PHY. The list of the parameters to compute is described in specification [1].
A mapping table in the RRC provides a set of UMTS parameters such as BER, delay according to the
requested Radio QoS class. The computation of the radio parameters is based both on this set of
parameters, <strong>and</strong> on the existing configuration <strong>and</strong> allocated resources. .
These parameters are also transferred from the Radio Gateway to the Mobile Terminal using the RRC
protocol.
CEC Deliverable Number D0202 35 / 97

WP2-D0202 Version 1.0 4.6.2003
IPv6 Protocol Stack
Non-Access Stratum (Driver)
IP/Radio QoS Mapping
Control
Data
RRC+RRM
PDCP
RLC / Radio Bearers
MAC / Logical & Transport Channels
Access Stratum
RRC: Radio Resource Control
RRM: Radio Resource Management
RLC: Radio Link Control
MAC: Medium Access Control
PDCP: Packet Data Convergence Protocol
PHY: Physical Layer
PHY / Physical Channels
Radio Interface
Figure 28: Layered vision of the MT <strong>and</strong> AR TD-CDMA architecture (Radio QoS)
Their loading in both network components enables the opening of a new radio bearer, usually mapped
onto dedicated logical, transport <strong>and</strong> physical channels, as shown in Figure 28. Once this radio bearer is
available, the Non Access Stratum can use it to transfer user data through the PDCP <strong>and</strong> the lower layers,
according to the previously stored mapping. When the user traffic is over, the QoS Broker can close the
radio bearer in the exact same manner.
4. QoS signaling in Moby Dick
The Moby Dick QoS entities interact between them, but also with both security <strong>and</strong> mobility entities.
Signaling messages are exchanged between:
• The QoS Manager <strong>and</strong> the QoS Broker with:
o A router registration: the AR opens a COPS connection with the QoS Broker,
o QoS configurations: the QoS Broker configure the AR queues with CBQ <strong>and</strong> RIO
parameters,
o Resource allocations: the QoS Broker allocates resources for each new couple ,
o Queues state monitoring: the QoS Manager reports the state of its queues to the QoS
Broker,
o FHO context transfers from old ARs to new ARs, towards the QoS Broker,
o Connection checks: the QoS Manager sends ‘Keep alive’ messages to the QoS Broker
to maintain the communication,
o End of communication: the QoS Manager ends the communication with the QoS
Broker.
• The QoS Broker <strong>and</strong> the AAAC Server, to dump the NVUP to the QoS Broker during the user
registration process
4.1 Signaling between QoS Manager <strong>and</strong> QoS Broker
By means of the COPS protocol (Common Open Policy Service) the Access Router communicates with
the QoS Broker. The COPS protocol is client-server. Thus all the petitions are initiated by the client with
the sole exception of the FHO message from the QoS Broker to the new AR (nAR). In our environment
the AR is the COPS client (PEP) <strong>and</strong> the QoS Broker the server (PDP). In this section, we present the
messages sequence that takes place when the AR starts.
CEC Deliverable Number D0202 36 / 97

WP2-D0202 Version 1.0 4.6.2003
4.1.1 Router registration
Once the TCP connection is open, the Router begins the COPS dialog sending the registration message
“Client-Open”. In this message, apart from the header that has the client's type identifier (0xff02 in this
case), a COPS object called ‘PEPID’ is sent. The PEPID is a text string, finished with the null character,
which identifies uniquely the client. In our development we have chosen to put the DNSv6 name of the
client machine in this field, which should be smaller than 30 characters.
The “Client-Open” message is the following one (Fig. 29):
Ver 1 Flg 0 Op. Code 6 Client Type: 0xFF02
Message length: 8+[4+len(PEPID)+padding] (bytes)
Leng: 4+len(PEPID)+padding C-Num 11 C-Type 1
PEPID (max. 30 characters = 30 bytes)
NULL
Padding: 0x00..00
Figure 29: COPS Client-Open message. AR->QoS Broker
Once the QoS Broker (PDP) checks this message <strong>and</strong>, if it is correct, it responds to the Router with a
“Client-Accept” message. This message contains a ‘KATimer’ object <strong>and</strong> an ‘AcctTimer’ object. The
“Client-Accept” message is the following one (Fig. 30):
Ver 1 Flg 0 OP. Code 7 Client Type: 0xFF01
Message Length: 24 (bytes)
Object length: 8 C-Num 10 C-Type 1
0x0000 KA Timer Value: 120
Object length: 8 C-Num 15 C-Type 1
0x0000 AcctTimer value: 20
Figure 30: COPS Client-Accept message. QoS Broker->AR
The registration sequence can be represented as in Fig. 31:
Client Open
QoS Broker
Client Accept
Access
Router
Figure 31: Router registration sequence
4.1.2 QoS configuration dialogue
Once the router has registered correctly in the QoS Broker, it requests to the Broker the QoS queues
configuration, which must be applied in its access interface for packets going from the core to the access.
For this purpose three COPS messages are exchanged: first the Router requests the configuration, later the
CEC Deliverable Number D0202 37 / 97

WP2-D0202 Version 1.0 4.6.2003
QoS Broker responds with the configuration, <strong>and</strong> finally the Router informs the QoS Broker about the
configuration result. We pass to see these messages.
The first one is a ‘Request’ message, which only contains m<strong>and</strong>atory objects <strong>and</strong> an ‘Out Interface’ object
identifying the AR interface where QoS queues are going to be configured. In the m<strong>and</strong>atory objects, we
have to highlight two important fields: the ‘h<strong>and</strong>le’ in the ‘Client H<strong>and</strong>le’ object, <strong>and</strong> the ‘R-Type’ in the
‘Context’ object. These objects are filled with the values of ‘0’ (signaling h<strong>and</strong>le) <strong>and</strong> ‘8’ respectively.
The last value (8) means: ‘Configuration Request’.
The ‘Out Interface’ object is a st<strong>and</strong>ard COPS object used to identify the outgoing interface to which a
specific request applies. It contains an IPv6 address <strong>and</strong> the Access Router interface index number. The
first one is always a loop back address (::1) because the PEP is the destination of this message. The
second one is an integer which identifies the interface; this integer can be obtained with the TC API
function mapNameToInterface() or with the C st<strong>and</strong>ard function if_nametoindex().
The “Configuration Request” message is defined in Fig. 32:
Ver 1 Flg 0 Op Code 1 Client Type: 0xFF02
Message length: 48 (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le: 0x00000000
Object length: 8 C-Num 2 C-Type 1
R-Type 8
M-Type
Object length: 24 C-Num 4 C-Type 2
struct in6_addr sender = ::1
int ifindex
Figure 32: COPS configuration request message. AR->QoS Broker
Once the QoS Broker receives, identifies <strong>and</strong> checks the previous message, it builds a decision message
based on the behavior data that it reads from a file during its start up. Those data, sent as ‘ClientSI
Decision Data’ objects, are used to create the QoS tree structure in the DiffServ Logic in AR. For that
purpose, the PEP in the AR uses the IBM TC API with the following parameters:
- DSCP: 8 bits char field with the DSCP of the traffic to enqueue.
- Agreg_Number: 8 bits char field with the CBQ queue number.
- BW: 16 bits short integer field with the traffic b<strong>and</strong>width.
- Borrow_flag: 16 bits short integer field with a flag for request (or not) unused b<strong>and</strong>width.
- min_gred_queue: 16 bits short integer field with the RIO queue average minimum capacity
value.
- max_gred_queue: 16 bits short integer field with the RIO queue average maximum capacity
value.
- limit_gred_queue: 16 bits short integer field with the RIO queue limit capacity value.
- prob_gred_queue: 16 bits short integer field with the RIO discard probability value.
Negative values are not allowed (they are treated as unsigned). We will see in the following section the
detailed QoS queues implementation in our Router. The “Configuration Decision” message is the
following one (Fig. 33):
Ver 1 Flg 0 Op. Code 2 Client Type: 0xFF01
Message Length: 32+20·N (bytes)

WP2-D0202 Version 1.0 4.6.2003
H<strong>and</strong>le Obj.>
#1
H<strong>and</strong>le: 0x00000000
Object length: 8 C-Num 2 C-Type 1
R-Type 8
M-Type
Object length: 8 C-Num 6 C-Type 1
Comm<strong>and</strong> Code: 1
Flags
Object length: 20 C-Num 6 C-Type 4
DSCP: 0x00 Agreg. No. 0 B<strong>and</strong>width: 0
Borrow_flag: 0 Min_gred_queue: 0
Max_gred_queue: 0 Limit_gred_queue: 0
prob_gred_queue: 0
Padding: 0x0000
. . . . . .
#N
Object length: 20 C-Num 6 C-Type 4
DSCP: 0x0e Agreg. No. 5 B<strong>and</strong>width: 50
Borrow_flag: 0 Min_gred_queue: 3
Max_gred_queue: 10 Limit_gred_queue: 15
prob_gred_queue: 50
Padding: 0x0000
Figure 33: COPS configuration decision message. QoS Broker->AR
Even if the creation of the traffic control tree has been carried out with success or if not, the Router
communicates it to the QoS Broker (Fig. 35) with the following “Configuration <strong>Report</strong>” message – Figure
34.:
Ver 1 Flg 1 Op. Code 3 Client Type: 0xFF02
Message length: 24 (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le: 0x00000000
Object length: 8 C-Num 12 C-Type 1
<strong>Report</strong>-Type: 1 or 2
0x0000
Figure 34: COPS configuration report message. AR -> QoS Broker
In this message we can see how the ‘solicited message flag’ is enabled in the COPS common header.
Reference is also made to the signaling h<strong>and</strong>le (0) <strong>and</strong> in the ‘<strong>Report</strong>-Type’ object the router tells the QoS
Broker if it was able to create with success the QoS queues (<strong>Report</strong>-Type = 1) or not (<strong>Report</strong>-Type = 2).
In the last case, our Router would close the connection with the corresponding “Client-Close” message
<strong>and</strong> error code ‘8’ (client failure).
If everything works out with success, <strong>and</strong> after sending an affirmative 'Configuration <strong>Report</strong>’, the AR
initialises the shared memory segment with the traffic capturer <strong>and</strong> it begins to listen to traffics.
CEC Deliverable Number D0202 39 / 97

WP2-D0202 Version 1.0 4.6.2003
Config Request
QoS Broker
Config Decision
Config <strong>Report</strong>
Access
Router
Figure 35: COPS configuration sequence
4.1.3 Resource allocation dialogue
This dialogue takes place when the Router observes an exiting traffic going from the access interface to
the core interface that is not in its authorization table or when the lifetime of a previously installed traffic
has expired.
It also takes place when the Router observes an exiting traffic going from the core interface to the access
interface. In this case, no authorization <strong>and</strong> configuration of a token bucket is needed, this dialog is just to
inform the QoS Broker about that traffic.
The Router, in those cases, must generate a ‘Resource Allocation Request’ message for the captured
traffic asking the Broker whether to put this traffic in a token bucket (whose parameters are specified by
the QoS Broker) or to block it. For that, it sends to the QoS Broker a ‘Request’ message specifying: the
existing interface of the traffic (Out Interface object), the traffic source <strong>and</strong> destination address <strong>and</strong> its
DSCP (ClientSI object). The “Resource Allocation Request” message is the next one (Fig. 36):
Ver 1 Flg 0 Op. code 1 Client Type: 0xFF02
Message length: 88 (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le
R-Type 2 M-Type
Object length: 24 C-Num 4 C-Type 2
Struct in6_addr sender = ::1
int ifindex
Object length: 40 C-Num 9 C-Type 20
struct in6_addr ‘source_addr’ (16 bytes = 128 bits)
struct in6_addr ‘dest_addr’ (16 bytes = 128 bits)
DSCP
Padding: 0x000000
Figure 36: COPS resource allocation request message. AR->QoS Broker
CEC Deliverable Number D0202 40 / 97

WP2-D0202 Version 1.0 4.6.2003
We can observe how the captured parameters have been introduced in a ‘ClientSI’ object. The two
m<strong>and</strong>atory upper objects are the ‘Client H<strong>and</strong>le’, which contains the captured connection h<strong>and</strong>ler, <strong>and</strong> the
‘Context’ object, which will inform the QoS Broker that this message is a ‘Resource Allocation Request’
by using its ‘R-Type’ field. Following these objects, the ‘Out Interface’ informs the QoS Broker about the
traffic’ outgoing interface. Let us recall that the ‘h<strong>and</strong>le’ identifies a state installed on the Router, so here
it is provisional.
Once the QoS Broker receives <strong>and</strong> decodes the message, it checks if the AAAC.f previously installed the
traffic the Router is requesting for. If the traffic is installed in the QoS Broker, it sends the Router an
affirmative decision message. Otherwise the decision will be negative. The “Affirmative Resource
Allocation Decision” message is the following one (Fig 37):
Ver 1 Flg 0 Op. Code 2 Client Type: 0xFF01
Message length: 44 (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le
Object length: 8 C-Num 2 C-Type 1
R-Type 2
M-Type
Object length: 8 C-Num 6 C-Type 1
Comm<strong>and</strong> code: 1 Flags : 0 or 2
Object length: 12 C-Num 6 C-Type 4
unsigned int BW_policer (kbps)
unsigned int burst_policer (Bytes)
Figure 37: COPS affirmative resource allocation decision message. QoS Broker->AR
The “Negative Resource Allocation Decision” message is defined in Figure 38:
Ver 1 Flg 0 Op. Code 2 Client Type: 0xFF01
Message length: 32 (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le
Object length: 8 C-Num 2 C-Type 1
R-Type 2
M-Type
Object length: 8 C-Num 6 C-Type 1
Comm<strong>and</strong> code: 2 Flags : 0 or 2
Figure 38: COPS negative resource allocation decision message. QoS Broker->AR
Note that, in these messages, the ‘h<strong>and</strong>le’ value must be the same that the one in the Request message.
In both messages, the ‘Decision Flags’ object indicates to the Router two important things. The first one
is that it should or not install a filter/policer to provide QoS to the traffic according to its DSCP; this is
indicated in the ‘comm<strong>and</strong> code’ field with a ‘1’ for yes <strong>and</strong> a ‘2’ for no. The main difference between an
affirmative <strong>and</strong> a negative message is the ‘Decision ClientSI data’ object. If the traffic is installed in the
QoS Broker, it sends the Router –in that object– the token-bucket policer parameters: b<strong>and</strong>width (in kbps)
<strong>and</strong> burst (in bytes, > MTU). It obtains these parameters from the politics table <strong>and</strong> they can differ for
each traffic, although they are filtered towards the same queue discipline.
The second characteristic of the ‘Decision Flags’ object is that the ‘Flags’ field may indicate that the
Router has to request the QoS Broker a QoS queues configuration again. When set to ‘0’, this field
CEC Deliverable Number D0202 41 / 97

WP2-D0202 Version 1.0 4.6.2003
indicates that the Router should continue with its current queues. When set to ‘2’, the Router must redo
the COPS configuration sequence seen in a previous section <strong>and</strong> apply them (reconfiguration).
Once the Access Router has received <strong>and</strong> decoded a ‘Resource Allocation decision’ message, it proceeds
to install/actualize or remove a TC API filter/policer towards its associated queue. Even if the Router is
able to process the QoS Broker decision or if not, it must send a ‘Resource allocation <strong>Report</strong>’ message to
inform the QoS Broker about the Decision implementation state. The ‘Resource allocation <strong>Report</strong>’
message is defined in Figure 39:
Ver 1 Flg 1 Op. Code 3 Client Type: 0xFF02
Message length: 24 (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le
Object length: 8 C-Num 12 C-Type 1
<strong>Report</strong>-Type: 1 or 2
0x0000
Figure 39: COPS Resource allocation <strong>Report</strong> message. AR->QoS Broker
The ‘h<strong>and</strong>le’ identifies the referenced state <strong>and</strong> the ‘<strong>Report</strong>-Type’ informs the QoS Broker if the decision
has worked out (1) or not (2). If the decision fails, the COPS connection will be close with an error
message <strong>and</strong> the router will terminate its operation.
In the following graph (Fig. 40) we can see the messages sequence that forms a resource allocation
dialogue when, in the answer, the ‘reconfiguration flag’ value is ‘2’. In case it is ‘0’, only the three first
messages will be sent:
R.A. Request
R.A. Decision
R.A. <strong>Report</strong>
QoS Broker
Config Request
Config
Access
Router
Config <strong>Report</strong>
Figure 40: Resource allocation sequence with reconfiguration
4.1.4 Queues state report
As we saw in previous sections, when the Router starts up, it obtains, in the ‘Client-Accept’ message, the
accounting report timer value (AcctTimer). This counter is used in the Router to know how much time it
has to wait until asking the TC API for statistics, <strong>and</strong> to generate an ‘Accounting <strong>Report</strong>’ message to the
QoS Broker. A ‘0’ value in the ‘AcctTimer’ means that this type of message must not be sent. The
accounting value is specified in seconds.
This message is a typical ‘<strong>Report</strong>’ message to which are added so many ‘ClientSI’ objects as GRED
queues disciplines exist plus another ‘ClientSI’ object with the parent CBQ queue discipline statistics.
Once explained the ‘ClientSI’ content, we just have to draw the COPS ‘Accounting <strong>Report</strong>’ message (Fig.
41):
Ver 1 Flg 1 Op. Code 3 Client Type: 0xFF02
Message length: 24·(N+1) (bytes)

WP2-D0202 Version 1.0 4.6.2003
H<strong>and</strong>le Obj.>
H<strong>and</strong>le: 0x00000000
Object length: 8 C-Num 12 C-Type 1
<strong>Report</strong>-Type: 3
0x0000
Object length: 24 C-Num 9 C-Type 21
#1
struct account_data #1 ‘statistics’ (20 bytes)
. . . . . .
Object length: 24 C-Num 9 C-Type 21
#N
struct account_data #N ‘statistics’ (20 bytes)
Figure 41: COPS Accounting <strong>Report</strong> message. AR->QoS Broker
In this message it is necessary to highlight the use of the ‘signaling h<strong>and</strong>ler’ (‘0’) <strong>and</strong> how the ‘<strong>Report</strong>-
Type’ field of the ‘<strong>Report</strong>-Type’ object contains the number ‘3’ indicating that this is a ‘Accounting
report’ message.
Queues state report sequence:
QoS Broker
Accounting
Access
Router
Figure 42: Queues state report sequence
4.1.5 FHO context transfer from the old Access Router to the QoS Broker
During a FHO, the old access router has to inform the QoS Broker that a user is going to move to another
AR <strong>and</strong> free its local QoS configuration. Later the QoS Broker pushes the QoS configuration to the new
access router.
The communication between the old AR <strong>and</strong> the QoS Broker is based on a new COPS <strong>Report</strong> message
called ‘Fast H<strong>and</strong>-Over <strong>Report</strong>’ message. This message is an unidirectional report message.
The ‘Fast H<strong>and</strong>-Over <strong>Report</strong>’ message is as in Fig. 43:
Ver 1 Flg 1 Op. Code 3 Client Type: 0xFF02
Message length: 76 (bytes)

WP2-D0202 Version 1.0 4.6.2003
H<strong>and</strong>le Obj.>
H<strong>and</strong>le: 0x00000000
Object length: 8 C-Num 12 C-Type 1
<strong>Report</strong>-Type: 4
0x0000
Object length: 52 C-Num 9 C-Type 22
Struct FHO_data (48 bytes)
Figure 43: COPS Fast H<strong>and</strong>-Over <strong>Report</strong> message. oldAR->QoS Broker
In this message it is necessary to highlight the use of the ‘signaling h<strong>and</strong>ler’ (‘0’) <strong>and</strong> how the ‘<strong>Report</strong>-
Type’ field of the ‘<strong>Report</strong>-Type’ object contains the number ‘4’ indicating that this is a ‘Fast-Over report’
message. The previous structure is encapsulated in a ‘ClientSI’ object with C-Type = 22.
This message is only sent when the MIP module interrupts the QoS Manager informing it about a user’s
H<strong>and</strong>-Over.
The current mobility sequence is shown below in Figure 44:
QoS Broker
Fast-HO <strong>Report</strong>
Old Access
Router
Figure 44: Current mobility sequence
We recall that the message sent form the QoS Broker to the new Access Router must still to be
implemented.
4.1.6 FHO QoS Context transfer from the QoS Broker to the new AR (nAR)
When the QoS Broker receives the message described in the previous section, it processes that petition
<strong>and</strong> pushes to the new access router the result of it. If the new AR is not on the QoS Broker domain
network, the old QoS Broker must pass all user’s configuration towards the new QoS Broker <strong>and</strong> then this
last one will push the FHO result to the new AR. The FHO decision pushed to the nAR can indicate three
different things:
• Affirmative FHO message including all user’s traffics <strong>and</strong> policing parameters.
• Affirmative FHO message without information (only for advertising the FHO module)
• Negative FHO message. The FHO could not be realized.
If we are in the first case, the QoSBroker will push towards the nAR all user’s traffics related, i.e. source
address (CoA), destination addresses, DSCPs <strong>and</strong> policing information. The message used to transfer this
CEC Deliverable Number D0202 44 / 97

WP2-D0202 Version 1.0 4.6.2003
information will be an unsolicited ‘Decision message’ containing as many of the following structures as
client’s traffics are moved:
struct FHO_U_DEC_data {
unsigned int BW_policer;
unsigned int Burst_policer;
struct in6_addr source_addr;
struct in6_addr dest_addr;
unsigned char dscp;
};
We can see in the C structure the mentioned fields. The structure size is 41 bytes so padding is needed.
All this information will be encapsulated in a ‘Decision ClientSI data’ object.
The ‘Affirmative Unsolicited Fast H<strong>and</strong>-Over Decision’ message with data will be the following one –
Fig. 45:
Ver 1 Flg 0 Op. Code 2 Client Type: 0xFF01
Message length: 32+48N (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le: 0 (signaling)
R-Type 16 M-Type
Object length: 8 C-Num 6 C-Type 1
Comm<strong>and</strong> code: 1 Flags: 0
Object length: 48 C-Num 6 C-Type 4
unsigned int BW_policer (kbps)
unsigned int burst_policer (Bytes)
struct in6_addr ‘source_addr’ (16 bytes = 128 bits)
struct in6_addr ‘dest_addr’ (16 bytes = 128 bits)
DSCP
Padding: 0x000000
. . .
. . .
Object length: 48 C-Num 6 C-Type 4
unsigned int BW_policer (kbps)
unsigned int burst_policer (Bytes)
struct in6_addr ‘source_addr’ (16 bytes = 128 bits)
CEC Deliverable Number D0202 45 / 97

WP2-D0202 Version 1.0 4.6.2003
struct in6_addr ‘dest_addr’ (16 bytes = 128 bits)
DSCP
Padding: 0x000000
Figure 45 COPS Affirmative Fast H<strong>and</strong>over Unsolicited Decision message with data.
QoS Broker->new AR
In this message it is important to highlight the use of the ‘signaling h<strong>and</strong>ler’ (‘0’) <strong>and</strong> how the ‘R-Type’
field on the ‘Context’ object contains the number ‘16’ indicating that this is a ‘Fast-Over decision’
message. The nAR will determine that this is an affirmative message with data based on the ‘comm<strong>and</strong>
code’ field, here it will be ‘2’ (Install traffics). The previous data structure is encapsulated in a ‘ClientSI
Decision data’ object.
Once the nAR has decoded the last message, it tries to install in its core interface all the traffics that the
QoSBroker has comm<strong>and</strong>ed to do. In order to report the Broker about the traffics’ h<strong>and</strong>lers <strong>and</strong>
implementation states, the router sends as many ‘Resource Allocation <strong>Report</strong>’ messages as traffics are
installed <strong>and</strong> by installation order. The RA <strong>Report</strong> message was defined in section 2.3.
If we are in the second case, the QoSBroker will only push towards the nAR an unsolicited ‘Decision
message’ containing no client data. This occurs when the FHO is done correctly but no traffics are
transferred towards the nAR (because the MT is on st<strong>and</strong>by). The aim of this event is to inform the FHO
module about a correct transfer.
The ‘Affirmative Unsolicited Fast H<strong>and</strong>-Over Decision’ message without data will be the
following one – Fig. 46.:
Ver 1 Flg 0 Op. Code 2 Client Type: 0xFF01
Message length: 32+48N (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le: 0 (signaling)
Object length: 8 C-Num 2 C-Type 1
R-Type 16
M-Type
Comm<strong>and</strong> code: 0 Flags: 0
Figure 46: Affirmative Fast H<strong>and</strong>-Over Unsolicited Decision message without data. QoSBroker-
>newAR
The nAR will determine that this is an affirmative FHO message without data based on the ‘comm<strong>and</strong>
code’ field on the ‘Decision Flags’ object, here it will be ‘0’ (no configuration data available). The router
will send a ‘Configuration Resource Allocation <strong>Report</strong>’ message if the decision has worked out (code 1)
or not (code 2). The RA <strong>Report</strong> message was defined in section 2.2.
If we are in the third case, the QoSBroker will push towards the nAR an unsolicited ‘Decision message’
containing a code that indicates to the router that the FHO could not be realized. No client data is pushed.
This occurs when the FHO is in error or is not authorized. The aim of this event is to inform the FHO
module about a incorrect transfer.
The ‘Negative Unsolicited Fast H<strong>and</strong>-Over Decision’ message is in Figure 47:

WP2-D0202 Version 1.0 4.6.2003
header>
Message length: 32+48N (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le: 0 (signaling)
Object length: 8 C-Num 2 C-Type 1
R-Type 16
M-Type
Object length: 8 C-Num 6 C-Type 1
Comm<strong>and</strong> code: 2 Flags: 0
Figure 47 Negative Fast H<strong>and</strong>-Over Unsolicited Decision message. QoSBroker->newAR
The nAR will determine that this is a negative FHO message based on the ‘comm<strong>and</strong> code’ field on the
‘Decision Flags’ object, here it will be ‘2’ (reject). The router will send a ‘Configuration Resource
Allocation <strong>Report</strong>’ message if the decision has worked out (code 1) or not (code 2). The RA <strong>Report</strong>
message was defined in section 2.2.
Al these messages are only received when the MIP module interrupts the nAR’s QoSManager informing
it about a user’s H<strong>and</strong>-Over.
If we have an affirmative FHO with client data, we can see in Figure 48 its sequence:
QoSBroker
Fast-HO Decision
RA <strong>Report</strong>s...
new Access
Router
Figure 48 FHO QoS context transfer from QoSB to nAR
4.1.7 Connection check dialogue
As we saw, when the Router starts up it obtains, in the ‘Client-Accept’ message that the QoS Broker
sends to it, the connection check timer value: ‘KATimer’. This value is used in the router to control the
generation of ‘Keep-Alive’ messages. They are sent r<strong>and</strong>omly between ¼ <strong>and</strong> ¾ of the ‘KATimer’
(counting time since the last message was sent). A ‘0’ value indicates that these messages are not used.
The timer value is specified in seconds. The “Keep-Alive” message is shown in Figure 49:
Ver 1 Flg 0 Op. Code 9 Client Type: 0x0000
Message length: 8 (bytes)
Figure 49: COPS Keep-alive message. AR->QoS Broker <strong>and</strong> its reply.
This simple message is the one that the client should generate <strong>and</strong> the PDP should respond with the same
message. It is important to emphasize that the ‘client type’ field in the header must be ‘0’.
If the server doesn't receive a ‘Keep-Alive’ message after the ‘KATimer’ time, it considers a client hangs
up <strong>and</strong> it closes the connection sending a ‘Client-Close’ message before. If the PEP doesn't receive the
‘Keep-alive’ echo of a message that it sent, it does the same things that the server does: send a ‘Client-
Close’ with the corresponding error code <strong>and</strong> close the connection.
CEC Deliverable Number D0202 47 / 97

WP2-D0202 Version 1.0 4.6.2003
Here is the connection check dialogue sequence – figure 50:
Keep-ALive
QoS Broker
Keep-Alive
Access
Router
Figure 50: COPS Connection integrity check
4.1.8 Closing COPS connection
Programs must send the message that we will see next, close the TCP/IPv6 connection <strong>and</strong> end its
execution when one of the following problem occurs: program abrupt termination (Ctrl-C), error during
connection/execution, bad COPS message, Keep-alive temporization failure, etc.
The ‘Client-Close’ message does not belong to any sequence. It can be sent at any time by any program
(PDP or PEP). As the connection is closed after sending the message, the other program can not send
messages thru the socket. If one tries to send a message it gets a connection failure <strong>and</strong> ends.
The ‘Client-Close’ message is the following one – Figure 51:
Ver 1 Flg 0 Op. Code 8 Client Type: 0xFF0X
Message length: 16 (bytes)
Object length: 8 C-Num 8 C-Type 1
Error code: X Error Sub-code: 0
Figure 51: COPS Client-Close message. ARQoS Broker
In the message, the ‘Client-Type’ field (in the COPS header) is filled with the sender code. Inside the
error object is placed the error code informing the other client why the connection is going to be closed.
In the next figure we show how to close a COPS connection. Note that it is unidirectional. We represent
that in Figue 52:
QoS Broker
Client-Close
Access
Router
QoS Broker
Client-Close
Access
Router
Figure 52: Closing COPS connection
CEC Deliverable Number D0202 48 / 97

WP2-D0202 Version 1.0 4.6.2003
4.2 Signaling between the QoSB.f <strong>and</strong> the AAAC.f
We list now the COPS messages exchanged between the AAAC.f (which acts as a COPS client) <strong>and</strong> the
QoSB.f (which acts as a COPS server).
To open the COPS connection COPS Client-Open <strong>and</strong> Client-Accept messages without optional COPS
objects are exchanged. The AAAC server client type is 65283 (in decimal).
To close the COPS connection a COPS ClientClose Message is sent without optional COPS objects.
To send the NetServices Description to the QoSB.f a REQuest message is sent with optional cops
“Client Specific Information Objects”. The format of these objects (<strong>and</strong> of the entire REQuest message) is
given below. The QoSB.f answers to this message with a DECission message without optional COPS
objects.
The format of the REQuest message (fields length is in bytes) is in the following Figure 53:
#1
Ver 1 Flg 0 Op. code 1 Client Type: 0xFF03
Message length: 52+N*28 (bytes)
Object length: 8 C-Num 1 C-Type 1
H<strong>and</strong>le
Object length: 8 C-Num 2 C-Type 1
R-Type 2
M-Type
Object length: 28 C-Num 9 C-Type 131
Struct in6_addr dest. Addr.
BW
Burst Size
priority DSCP Padding 00 00
Object length: 28 C-Num 9 C-Type 131
#N
struct in6_addr dest. Addr
BW
Burst Size
Priority DSCP Padding 00 00
Figure 53: Closing COPS connection
dest. Addr is set to 0 when it is unused.
To dump the NVUP, we send a REPORT STATE message with optional COPS “Client Specific
Information Objects”. The format of these objects (<strong>and</strong> of the entire REPORT STATE message) is given
below:
Format of the REPort message (fields length is in bytes) as in Fig. 54:

WP2-D0202 Version 1.0 4.6.2003
TTL
Object length: 24 C-Num 9 C-Type 138
#2
in6_addr dest. Addr
DSCP Padding 00 00 00
Object length: 24 C-Num 9 C-Type 138
#N
in6_addr dest. Addr
DSCP Padding 00 00 00
Figure 54: Closing COPS connection
dest. Addr is set to 0 when it is unused.
5. Tests <strong>and</strong> performances
5.1 QoS manager tests
5.1.1 Test conditions
For these tests we used the following scenario (Fig. 55).
escorpion.ipv6 pulga.ipv6 escarabajo.ipv6
garrapata.ipv6
Eth1
Eth1
Eth2
Ethernet Access Network
2001:0720:0410:1004::/64
Eth1
Eth1
Core Network (Simulated)
2001:0720:0410:1003::/64
Figure 55: MobyDick QoS test scenario
In all machines is used the Red Hat Linux 7.1 operating system with a 2.4.16 kernel.
The machines functionality were the following ones:
- escorpion.ipv6 (MT): IPv6 traffic generator towards ‘garrapata.ipv6’ in policing tests <strong>and</strong>
receptor in QoS tests. For policing <strong>and</strong> QoS tests we used unidirectional UDP traffic generated
with the ‘mgen6’ tool.
- pulga.ipv6 (AR): QoS Manager that routed all packets coming from the 2001:720:410: 1004::/64
network towards the 2001:720:410:1003::/64 network <strong>and</strong> vice versa. It also applied QoS
queuing on its ‘eth2’ interface <strong>and</strong> delegated policing on its ‘eth1’ interface.
- escarabajo.ipv6 (AAAC): in this machine resided the AAAC.
- garrapata.ipv6 (QoS Broker): this machine was the transceptor of escorpion’s traffics. It also
gathered some traffic statistics. The QoS Broker resided in this machine.
CEC Deliverable Number D0202 50 / 97

WP2-D0202 Version 1.0 4.6.2003
Test specification
The test consisted on:
- Verifying the correct COPS messages sequence as well as their integrity with the st<strong>and</strong>ard.
- Verifying the correct QoS/policing configuration <strong>and</strong> implementation.
Before carrying out the tests, it was necessary to start up the QoS Broker in ‘garrapata.ipv6', the AAAC in
‘escarabajo.ipv6’ <strong>and</strong> the traffic capturer <strong>and</strong> Access Router in ‘pulga.ipv6 '. We had to verify that both
COPS clients had a correct registration on the QoS Broker, that the access router received the behaviour
table, <strong>and</strong> the router installed the QoS classes on its access interface.
5.1.2 COPS sequences <strong>and</strong> st<strong>and</strong>ard compliance tests
For these tests, a complete COPS messages interaction was captured between the Router <strong>and</strong> the QoS
Broker. All COPS message parts were validated. The captures were realized with the ‘ethereal’ program
<strong>and</strong> the router’s program output was copy from an execution in debug mode.
5.1.2.1 Access Router initialization
This capture includes two COPS sequences. First a ‘Router Registration’ <strong>and</strong> later a ‘QoS configuration
dialogue’ (Fig. 56).
Figure 56: Access Router initialisation capture
CEC Deliverable Number D0202 51 / 97

WP2-D0202 Version 1.0 4.6.2003
In this sequence, the Access Router began the connection with a ‘Client-Open’ sent to the QoS Broker, to
what it responded with a ‘Client-Accept’ in which it sent the ‘KATimer’ <strong>and</strong> the ‘AcctTimer’. Later, the
Router requested the access interface QoS configuration data in a ‘Configuration Request’ to what the
QoS Broker responded it with a ‘Configuration Decision’ in which it sent the QoS queues configuration
data. Once the Router had tried to apply the configuration, it sent to the QoS Broker the result of it.
All COPS messages <strong>and</strong> objects were revised, being according to the st<strong>and</strong>ard (RFC 2748).
In the appendix B section 9.1, the printed debug text lines that the router prints out on an initialisation are
presented.
5.1.2.2 Access Router resource allocation
This capture shows the ‘Resource Allocation’ COPS sequence. First we can see the ethereal capture (Fig.
57):
Figure 57: Access Router resource allocation capture
In this sequence, the capturer program informed the router about a new detected traffic. Then, the router
requested the QoS Broker about authorization for the traffic (policing). The ‘Resource allocation request’
message that was generated included the traffic’s source <strong>and</strong> destination addresses <strong>and</strong> its DSCP.
When the QoS Broker decoded the last message, it searched in its list for the received traffic. In this
simulation we previously generated a ‘ping6’ traffic from ‘escorpion.ipv6’ to ‘garrapata.ipv6’ <strong>and</strong>
installed it in the QoS Broker. The Broker answered the router with an ‘Affirmative Resource Allocation
Decision’ message, thus this message also contained policing information in its ‘ClientSI Decision Data’
object.
When the router classified the traffic towards the class 1:1 <strong>and</strong> applied a token-bucket policer, it reported
the QoS Broker with the TCAPI implementation state. It was done thru a ‘Resource Allocation <strong>Report</strong>’
Message.
CEC Deliverable Number D0202 52 / 97

WP2-D0202 Version 1.0 4.6.2003
All COPS messages <strong>and</strong> objects were revised, being according to the st<strong>and</strong>ard (RFC 2748).
In the appendix B section 9.2 the printed debug text lines that the router prints out on an affirmative
resource allocation sequence are presented.
5.1.2.3 Access Router queues state report
This capture shows the Queues state report COPS message. First we can see the ethereal capture (Fig.
58):
Figure 58: Access Router queues report capture
Due to the value of the ‘AcctTimer’ (20 seconds here), the access router sent periodically to the QoS
Broker ‘Queues state report’ messages for the access interface. In the captured message we can see four
‘ClientSI’ objects according to the four GRED child queues.
The COPS message <strong>and</strong> its objects were revised, being according to RFC 2748.
In the appendix B section 9.3 you can see the printed debug text lines that the router prints out on a
queues state report sequence (Fig. 59).
CEC Deliverable Number D0202 53 / 97

WP2-D0202 Version 1.0 4.6.2003
MobyDick
QoS Broker:
garrapata.ipv6
1 FHO
report
2 FHO Uns.
decision
5 <strong>Report</strong>s
4 policed
Traffic(s)
COPS
oldAR:
cucaracha.ipv6
nNewAR:
termita.ipv6
3 Traffic(s)
Figure 59: FHO scenario <strong>and</strong> messages diagram
5.1.2.4 Access Router mobility signaling messages
For this test we have to create a new scenario. A simplified version appears below.
A mobile terminal sending authorized packets towards ‘garrapata.ipv6’ thru the AR cucaracha.ipv6 (old)
performs a h<strong>and</strong>-over to ‘termita.ipv6’ (new).
All the policed traffics in use were transferred to the newAR via the FHO module <strong>and</strong> COPS messages.
The following captures probe all the process.
The first capture shows the FHO COPS <strong>Report</strong> message. First we can see the ethereal capture in Fig. 60:
Figure 60: old Access Router FHO report capture
CEC Deliverable Number D0202 54 / 97

WP2-D0202 Version 1.0 4.6.2003
In the previous capture we can see a real message sent to the QoS Broker performing a Fast H<strong>and</strong>-Over.
This message was a ‘<strong>Report</strong>’ one with a <strong>Report</strong>-type = 4 <strong>and</strong> a signaling h<strong>and</strong>ler = 0. In the last message
object (the ClientSI) we can see the following addresses:
oldCoA: 2001:720:410:1006:204:e2ff:fe2a:460c
newCoA: 2001:720:410:1007:204:e2ff:fe2a:460c
newAR: 2001:720:410:1007:204:e2ff:fe08:c8c (termita.ipv6)
We can see in these addresses how, when the MIP module interrupted the oAR, it passed to the QoS
Manager all the FHO addresses related. Also we advertise how the mobile module changed correctly the
IPv6 prefixes <strong>and</strong> it acquired the nAR address. Immediately, the oAR passed this information to the QoS
Manager. In the appendix B section 9.4.1 the printed debug text lines that the router prints out on a FHO
report sequence are presented.
The second capture shows the Affirmative Unsolicited FHO COPS decision message with data towards
the nAR. First we can see the ethereal capture (Fig. 61):
Figure 61: QoS Broker FHO decision <strong>and</strong> nAR reports capture
In the previous capture we can see first the message sent to the nAR performing a Fast H<strong>and</strong>-Over
notification. This message was an unsolicited Decision one with a R-type = 16 <strong>and</strong> a signaling h<strong>and</strong>ler =
0. Only one ‘ClientSI Decision Data’ objects was attached due to the mobile terminal had only one active
traffic with ‘garrapata.ipv6’. Its structure was:
BW_policer_1 = 50
Burst_policer_1 = 1514
Source_addr_1 = 2001:720:410:1007:204:e2ff:fe2a:460c (newCoA)
dest_addr_1 = 2001:720:410:1003:204:75ff:fe7b:943e (garrapata.ipv6)
dscp_1 = 0x00
CEC Deliverable Number D0202 55 / 97

WP2-D0202 Version 1.0 4.6.2003
The nAR processed the last message <strong>and</strong> installed the solicited traffic. Once the traffic was installed
correctly, the nAR informed the QoS Broker thru a ‘Resource Allocation <strong>Report</strong>’ message. In this
message was indicated to the QoS Broker the connection h<strong>and</strong>ler <strong>and</strong> its implementation state. In the
capture we can see this kind of message.
The nAR began to listen for an ‘Unsolicited Decision message’ when the MIP module interrupted its
normal execution. When all the FHO process was over, the nAR reported to the MIP module the final
state. In the appendix B section 9.4.2 the printed debug text lines that the router prints out on a FHO
decision sequence are presented.
5.1.2.5 Access Router timeout connection deletion
This capture shows the Delete Request State COPS message. First we can see the ethereal capture:
Figure 62: Access Router Delete Request State capture
In the previous capture we can see the message that the AR sent to the QoS Broker when an installed state
expired (more than 60 seconds inactive). This message was an unidirectional Delete Request with a
Reason = 5 (timeout) <strong>and</strong> a h<strong>and</strong>ler = 1 (equal to the number of the expired connection).
The COPS message <strong>and</strong> its objects were revised, being according to the st<strong>and</strong>ard (RFC 2748).
In the appendix B section 9.5 the printed debug text lines that the router prints out on a timeout
connection deletion sequence are presented.
5.1.2.6 Access Router connection check dialogue
This capture shows the COPS connection check sequence. First we can see the ethereal capture (Fig. 63):
CEC Deliverable Number D0202 56 / 97

WP2-D0202 Version 1.0 4.6.2003
Figure 63: Access Router connection check capture
Due to the value of the ‘KATimer’ (120 seconds here), the access router sent r<strong>and</strong>omly between ¼ <strong>and</strong> ¾
of the ‘KATimer’ (counting time since the last KA message was sent) a ‘Keep-Alive’ message to the QoS
Broker. In the captured message we can also see the answer to the Keep-Alive message that the QoS
Broker generated towards the QoS Manager.
In the appendix B section 9.6 the printed debug text lines that the router prints out on a connection check
sequence are presented.
5.1.2.7 Access Router closing COPS connection
This capture shows a COPS connection close. First we can see the ethereal capture (Fig. 64):
CEC Deliverable Number D0202 57 / 97

WP2-D0202 Version 1.0 4.6.2003
Figure 64: Access Router connection close capture
In this capture we can see how the router ends a COPS session. Here, the router was stopped by pressing
the ‘Ctrl-C’ keyboard combination. Hence, the ‘Error-code’ field in the ‘Error’ object indicates: ‘Shutting
down’.
In the appendix B section 9.7 the printed debug text lines that the router printed out in the previous
connection close sequence are presented.
CEC Deliverable Number D0202 58 / 97

WP2-D0202 Version 1.0 4.6.2003
5.1.3 Quality of Service tests
In this section we present four QoS <strong>and</strong> policing tests performed with our Access Router using a UDP
traffic generator (mgen6) or an ICMP application (ping6). In the first one, we show how the router denies
the access to a non-authorized traffic, the second one is a demonstration of QoS classification on the
access interface, the third one is a policed based authorization test <strong>and</strong> the last one is a dynamic
reconfiguration test.
5.1.3.1 Denying access to a non-authorized traffic
The first test is simple: it shows the router capacity of denying access to the core network. This test
required that the ‘best-effort’ class in the behaviour file activated the ‘borrow flag’ in order to receive the
answers from ‘garrapata.ipv6’ marked with the 0x00 DSCP. This way, only non-authorized or default
(DSCP = 0x00) packets thru the core interface were dropped by the router.
In this test we used the files exposed in Appendix A 8.1. The traffic generator program was ‘ping6’; this
program generates bi-directional ICMPv6 packets <strong>and</strong> can mark the IPv6 TClass field.
The operation procedure was very simple: execute the ‘ping6’ program sending packets to
‘garrapata.ipv6’ <strong>and</strong> install or uninstall the traffic in the QoS Broker via the AAAC.
For this test an ICMPv6 traffic was generated towards ‘garrapata.ipv6’, the ICMPv6 data size was 992
Bytes, the IPv6 TClass was 0x88 (DSCP = 0x22) <strong>and</strong> the time interval between packets was 1 second.
The test’s result is in Fig. 65 (the sequence will be explain later):
escorpion:~/mgen6/> sudo /usr/sbin/ping6 garrapata.ipv6 -s 992 -P 88 -i 1
PING garrapata.ipv6(garrapata.ipv6.it.uc3m.es) 992 data bytes
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=33 hops=63 time=857 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=34 hops=63 time=800 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=35 hops=63 time=846 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=36 hops=63 time=812 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=37 hops=63 time=794 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=38 hops=63 time=822 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=39 hops=63 time=784 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=40 hops=63 time=816 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=41 hops=63 time=784 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=42 hops=63 time=800 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=43 hops=63 time=835 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=44 hops=63 time=817 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=45 hops=63 time=797 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=46 hops=63 time=823 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=47 hops=63 time=790 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=48 hops=63 time=768 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=49 hops=63 time=805 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=50 hops=63 time=827 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=51 hops=63 time=842 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=52 hops=63 time=774 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=53 hops=63 time=811 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=54 hops=63 time=811 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=55 hops=63 time=800 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=56 hops=63 time=792 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=57 hops=63 time=800 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=58 hops=63 time=792 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=87 hops=63 time=779 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=88 hops=63 time=794 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=90 hops=63 time=776 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=91 hops=63 time=778 usec
1000 bytes from garrapata.ipv6.it.uc3m.es: icmp_seq=92 hops=63 time=756 usec
--- garrapata.ipv6 ping statistics ---
93 packets transmitted, 46 packets received, 50% packet loss
round-trip min/avg/max/mdev = 0.756/0.805/0.857/0.035 ms
Figure 65: Access to the core network sequence test
Once the router was working, we tried to send traffic towards ‘garrapata.ipv6’. Then we executed the
‘ping6’ program <strong>and</strong>, as we can see, no packet was able to reach ‘garrapata.ipv6’. This is due to the
properties of the token-bucket algorithm with 8bps <strong>and</strong> 1 bytes of burst.
Later, we installed the ICMPv6 traffic into the QoS Broker with the correct DSCP <strong>and</strong>, when the QoS
Manager asked the QoS Broker for it, the Broker answered it affirmatively. Then the traffic was
CEC Deliverable Number D0202 59 / 97

WP2-D0202 Version 1.0 4.6.2003
authorized <strong>and</strong> a policer with 90kbps of b<strong>and</strong>width <strong>and</strong> a burst of 1514 bytes were applied. Packets
started then to go out thru the interface (green ones).
Later we used the AAAC to uninstall the traffic in the QoS Broker <strong>and</strong> we can see how packets were now
dropped (icmp_sec=58 to 87). To end up the test, we stopped the router program <strong>and</strong> we can see in the
sequence that packets began to cross the router (blue ones).
In the appendix B section 9.8 the printed debug text lines that the router printed out in the previous test
are presented. Also it was a complete router operation.
5.1.3.2 Access interface QoS test
The goal of this test was to probe the correct application on the router’s access interface of QoS Broker’s
QoS configuration. It is important to highlight that all the interaction between QoS Manager <strong>and</strong>
management & planning algorithms in the kernel was done via TC API functions.
In this section the QoS configuration were static, i.e. the QoS Broker did not request a ‘Router
reconfiguration’.
The application used in this test to generate unidirectional UDP/IPv6 traffic from ‘garrapata.ipv6’ to
‘escorpion.ipv6’ is called ‘mgen6’. This program needs a DSCP traffic marker to simulate different
DiffServ traffics.
Also note that, in these tests, the program ‘mgen6’ was utilized to saturate the queues capacity with more
binary rate that the queues support. We tested the real binary data that the queues were able to forward.
In the following tests, we used the configuration files exposed in Appendix A 8.1.
In order to provide QoS to a traffic <strong>and</strong> obtain statistics from it we followed the following steps:
- With the marking software we marked the DSCP of all traffic’s packets that ‘garrapata.ipv6’ sent
to ‘escorpion.ipv6’.
- The MT packet flow was simulated with the ‘mgen6’ application: UDP/IPv6 traffic towards
‘escorpion.ipv6’.
- When that traffic passed thru ‘pulga.ipv6’, the QoS logic installed on the access interface
classified packets based on the DSCP towards their QoS queue.
Once the previous steps were realized, we were able to check the amount of binary rate <strong>and</strong> drops per
queue. Repeating the process for all the possible DSCPs we probe the whole QoS configuration on the
access router. In Table 6 we present the measured performance :
AF
Low drop
probability
Médium
drop
probability
High drop
probability
Class 1 (180kbps) Class 2 (270kbps) Class 3 (900kbps) Class 4 (1800kbps)
Data
binary
rate
176 kbps
176 kbps
176 kbps
Drops
1514
(75,7%)
1542
(77,1%)
1547
(77,3%)
Data
binary
rate
262 kbps
263 kbps
263 kbps
Drops
851
(42,5%)
1115
(55,7%)
1244
(62,2%)
Data
binary
rate
889 kbps
889 kbps
889 kbps
Drops
7289
(72,8%)
7382
(73,8%)
7481
(74,8%)
Data
binary
rate
1772
kbps
1772
kbps
1772
kbps
Drops
4888
(48,8%)
4988
(49,8%)
5085
(50,8%)
Table 6: Obtained QoS Test without policing (saturated queues)
In this test we utilized the ‘mgen6’ program with two different binary rates. For classes 3 <strong>and</strong> 4 were
generated a 500pps (packets per second), 1000Bpp (Bytes per packet) traffic with a duration of 20
seconds. The binary data rate that we tried to post towards these classes was 4Mbps (500pac/s ·
1000Bytes/pac · 8bits/Byte). In the same way, for a 20 seconds test, 10000 packets (20seg · 500pac/s)
were sent.
For classes 1 <strong>and</strong> 2, a 100pps, 1000 Bpp UDP traffic with a 20 seconds duration was generated. The
binary data rate that we tried to post towards these classes was 800kbps (100pac/s · 1000Bytes/pac ·
8bits/Byte). In the same way, for a 20 seconds test, 2000 packets (20seg · 100pac/s) were sent.
As we know, the UDP header measures 8 bytes, the IPv6 header without options has 40 bytes <strong>and</strong> the
Ethernet header measures 14 bytes. With these data we know that if a packet has 1000 data bytes, the
CEC Deliverable Number D0202 60 / 97

WP2-D0202 Version 1.0 4.6.2003
transmitted packet is 1062 bytes long (1000+8+40+14). Therefore, to determine the link binary rate, we
will need to multiply the binary data rate –that the program returns– for a 1.062 factor.
Looking test’s results, we can confirm the correct operation of queues disciplines. For class 4, the link
binary rate reserved was 1800kbps (700+600+500 kbps) <strong>and</strong> the test showed up a link binary rate of
1881kbps (1772 · 1.062). Also we can observe in this class how, with the same sent traffic, three different
drop discard probabilities were obtained. Basically, the CBQ class (WRR algorithm) fix the binary rate
<strong>and</strong> the RIO planning algorithm fix the packet dropping in CBQ bursts.
For class 3, the link binary rate reserved was 900kbps (400+300+200 kbps) <strong>and</strong> the test showed up a link
binary rate of 944kbps (889 · 1.062) in all its queues. For class 2, the link binary rate reserved was
270kbps (100+90+80 kbps) <strong>and</strong> the test showed up a link binary rate of 278kbps (263 · 1.062) in all its
queues. Finally, for class 1, the link binary rate reserved was 180kbps (70+60+50 kbps) <strong>and</strong> the test
showed up a link binary rate of 186kbps (176 · 1.062) in all its queues. We can observe in all of them how
different drop probabilities are obtained based on packet’s DSCP. Remember that GRED parameters
change form one traffic to another but the CBQ burst is the same.
5.1.3.3 Core interface policing test
In this test we demonstrated the policer operation functionality on the core interface. Note that policers
were applied for each filter (traffic) <strong>and</strong> all filters classified towards the same queue discipline (1:1).
Therefore, the binary rate of that class had to be equal to the interface speed (100Mbps in this case). With
policers we were able to control traffic’s rates <strong>and</strong> prevent that a traffic from getting all the binary rate of
its class to itself. The token-bucket policer algorithm shaped <strong>and</strong> controlled the packet flow according to
the transferred binary rate <strong>and</strong> burst (Fig. 66).
Figure 66: Token-bucket policer schematic
The traffic generator program was ‘mgen6’ from ‘escorpion.ipv6’ to ‘garrapata.ipv6’ <strong>and</strong> it also was
utilized saturating the queues capacity with more binary rate that the queues support.
In this test we used the same files exposed in Appendix A 8.1, <strong>and</strong> we followed the following steps in
order to authorize <strong>and</strong> police a traffic:
- With the AAAC simulation program we had to request the QoS Broker for the traffic’s DSCP
we wanted to test. To probe the class AF1m, the NVUP with 8kbps had to be installed on the
QoS Broker, with priority set to 12 <strong>and</strong> a burst size set to 1514 bytes. The QoS Broker returned
the DSCP code for that traffic (0x0C) to the AAAC.
- With the marking software we marked the DSCP of all traffic’s packets that ‘escorpion.ipv6’
sent to ‘garrapata.ipv6’. The DSCP was the code returned by the QoS Broker.
- The MT packet flow was simulated with the ‘mgen6’ application: UDP/IPv6 traffic towards
‘garrapata.ipv6’.
- When that traffic passed thru ‘pulga.ipv6’, the QoS Manager detected it with the capturer
module <strong>and</strong> requested the QoS Broker to authorize that traffic <strong>and</strong>, in an affirmative case, the
policing parameters.
- The QoS Broker answered it affirmatively <strong>and</strong> then the router applied a filter towards the class
1:1 <strong>and</strong> a token-bucket policer.
CEC Deliverable Number D0202 61 / 97

WP2-D0202 Version 1.0 4.6.2003
The performance measures are presented in Table 7:
AF
Low drop
probability
Medium
drop
probability
High drop
probability
Class 1 (180kbps) Class 2 (270kbps) Class 3 (900kbps) Class 4 (1800kbps)
Data
binary
rate
9.2 kbps
Drops
97
(80.8%)
8.3 kbps 96 (80%)
7.3 kbps
101
(84.1%)
Data
binary
rate
29.2
kbps
19.9
kbps
10.2
kbps
Drops
47
(39.1%)
70
(58.3%)
93
(77.5%)
Data
binary
rate
58.6
kbps
49 kbps
39.3
kbps
Drops
253
(63.2%)
277
(69.2%)
302
(75.5%)
Data
binary
rate
80.5
kbps
77.9
kbps
68.3
kbps
Drops
199
(49.7%)
205
(51.2%)
229
(57.2%)
Table 7: Obtained QoS Test with policing (saturated queues)
In this test we utilized the ‘mgen6’ program with two different binary rates. For classes 3 <strong>and</strong> 4 were
generated a 20pps, 1000Bpp traffic with a duration of 20 seconds. The binary data rate that we tried to
post towards these traffics was 160kbps (20pac/s · 1000Bytes/pac · 8bits/Byte). In the same way, 20
seconds test, 400 packets (20seg · 20pac/s) were sent.
For classes 1 <strong>and</strong> 2 were generated a 6pps, 1000 Bpp UDP traffic with a duration of 20 seconds. The
binary data rate that we tried to post towards these traffics was 48kbps (6pac/s · 1000Bytes/pac ·
8bits/Byte). In the same way, for 20 seconds test, 120 packets (20seg · 6pac/s) were sent.
When the policer works well, the traffic transferred in each case must be the same that is specified in the
‘politics file’ <strong>and</strong> that the QoS Broker sends to the Access router. We can observe how the tests
completed the expectations:
- AF4l = 85.5 kbps, AF4m = 82.7 kbps, AF4h = 72.5 kbps (link binary rate, factor 1.062),
- AF3l = 62.2 kbps, AF3m = 52 kbps, AF3h = 41.7 kbps (link binary rate, factor 1.062),
- AF2l = 31 kbps, AF2m = 21.1 kbps, AF2h = 10.8 kbps (link binary rate, factor 1.062),
- AF1l = 9.7 kbps, AF1m = 8.8 kbps, AF1h = 7.7 kbps (link binary rate, factor 1.062),
Looking test’s results, we can confirm the correct operation of policer function.
5.1.3.4 Dynamic reconfiguration test
In this test we probe the router’s access interface QoS reconfiguration mechanism under a QoS Broker’s
petition. As the test name indicates, we present the traffic’s binary rate time evolution.
The application used in this test to generate the traffic was ‘mgen6’ from ‘garrapata.ipv6’ to
‘escorpion.ipv6’, but a new program was used to receive the traffic. A modified receptor processed all the
received packets, calculated the binary rate in time intervals <strong>and</strong> wrote this values in an Excel file. Later,
these values were treated to generate a graph.
The steps we had to execute are the following ones: insert in a class a traffic that saturates its queue
capacity. When the QoS Broker receives the queues statistics thru the COPS protocol it calls the
‘BW_control_function’. This function, as it is programmed, processes the behaviour data list <strong>and</strong> the
queues statistics <strong>and</strong> requests (or not) the QoS Manager a queues reconfiguration.
Our ‘BW_control_function’ operated in the following way: if the queue was more than 20 drops per
second it incremented the queues b<strong>and</strong>width in a 1.3 factor <strong>and</strong> requested the access router a
reconfiguration. Note that statistics were obtained from each GRED class, not for each filter, so this
function operated at class level.
For this test an 800kbps UDP data traffic was generated. It was marked as an AF1h class (DSCP = 0x0e).
We used here the behaviour file seen in Appendix A 8.1. On the initial behaviour file, this traffic had
assigned an 180kbps link data rate (70+60+50kbps). For this reason the CBQ queue was saturated <strong>and</strong> the
result of a 200 second test sequence is showin in Fig. 67.
CEC Deliverable Number D0202 62 / 97

WP2-D0202 Version 1.0 4.6.2003
AF1 Class
Binary rate (kbps)
900
800
700
600
500
400
300
200
100
0
0 50 100 150 200 250
Time (s)
Figure 67: Dynamic reconfiguration test
In the graph we can see how, at the beginning, the traffic was classified towards its corresponding
180kbps AF1h queue. Later, the router obtained <strong>and</strong> sent statistics from the queues to the QoS Broker.
Those statistics inform the QoS Broker about binary rates, packets, drops <strong>and</strong> overlays per second.
The QoS Broker, looking at queue’s statistics (more than 20 drops/s), decided an increment in the class
AF1 of a 1.3 factor. The Broker changed then the queues virtual values of that CBQ class: the first to
91kbps (70·1.3), the second to 78 kbps (60·1.3) <strong>and</strong> the third to 65 kbps (50·1,3). In the end, the class AF1
got a 234kbps binary rate (91+78+65kbps). In a same way, it also activated the reconfiguration flag.
When the Router needed to actualise the traffic, it had to send a petition to the QoS Broker <strong>and</strong> then the
QoS Broker requested to the router a reconfiguration. The Router did a configuration sequence applying
the new queues.
Obviously, with a 234 kbps binary rate, the number of drops per second is more than 20 yet <strong>and</strong> the
process kept on repeating until reaching the traffic value. The theoretical steps values according to the
factor that the QoS Broker applied were: 180, 234, 304, 395, 514, 668kbps <strong>and</strong> finally the maximum (800
kbps). The obtained results are in the graph above <strong>and</strong> they are quite faithful to the theoretical values.
The reconfiguration’s duration was so short that it was not appreciated that momentarily all traffics were
classified towards the ‘reconfiguration class’ with a 500kbps binary rate.
5.2 QoS Broker <strong>and</strong> DSCP marking tests
Two versions of the DSCP marking software was provided. A first version, integrated in the Moby Dick
test bed in October 2002, in Madrid, could only filter packets on the IPv6 main header <strong>and</strong> the transport
(UDP, TCP) headers fields. Besides, in this first version, the ‘CoS’ field in each filter of the Filters
Database did not represent a service (e.g. S1, S2, …) but only a DSCP (e.g. ‘101010’, …). In the second
version of the software, provided in March 2003, the value of the CoS field became either a service
identifier or a DSCP, <strong>and</strong> its filtering capabilities were extended to the IPv6 extension headers, the
ICMPv6 header <strong>and</strong> the tunneled packets.
In this section, we present the individual tests done for the DSCP marking software. A first part describes
the tests provided for the first version of the software, <strong>and</strong> a second part describes the tests provided for
the second version.
5.2.1 First tests series
The first tests series validates both the main functionalities of the software components, i.e. the filters
loading, the DMT updates <strong>and</strong> the packet marking, <strong>and</strong> the very first set of filtering capabilities offered by
the DMS.
CEC Deliverable Number D0202 63 / 97

WP2-D0202 Version 1.0 4.6.2003
5.2.1.1 Filters loading
The first part of the software tests consisted in validating the Table Update Module.
We mainly verified:
• all the possible fields defined in Table 3 were recognized,
• the user could not use unexpected values (more than a maximum, less than a minimum, a
decimal value instead of a binary one, …) in the filters,
• all the legal IPv6 addresses formats could be used,
• the DSCP Matching Table was correctly initialized <strong>and</strong> updated (incorrectly written filters were
missing, existing filters were correctly replaced by new ones, filters were really placed at the
range defined by the ‘Filter’ field, <strong>and</strong> so on).
All these tests was done thanks to detailed prints in the ‘/var/log/messages’ file, such as:
Apr 10 16:43:37 hathor kernel: +New filter: 2
Apr 10 16:43:37 hathor kernel: --New filter description: Try
Apr 10 16:43:37 hathor kernel: --New field list
Apr 10 16:43:37 hathor kernel: ...Field name: IP6DSCP
Apr 10 16:43:37 hathor kernel: ...Value: 0
Apr 10 16:43:37 hathor kernel: --New filter DSCP: 0xA
Apr 10 16:43:37 hathor kernel: +New filter: 3
Apr 10 16:43:37 hathor kernel: --New filter description: Try
Apr 10 16:43:37 hathor kernel: --New field list
Apr 10 16:43:37 hathor kernel: ...Field name: IP6DSCP
Apr 10 16:43:37 hathor kernel: ...Value: 1
Apr 10 16:43:37 hathor kernel: --New filter DSCP: 0xF
Apr 10 16:43:37 hathor kernel: +2 Filters loaded
5.2.1.2 Packet marking
The second part of the software tests consisted in validating the DSCP Marking Function. Most of the
fields in the IPv6 main header, <strong>and</strong> in the transport headers (UDP <strong>and</strong> TCP) were tested thanks to three
applications allowing the emission of IPv6 packets (ping6, mgen6 <strong>and</strong> telnet), <strong>and</strong> one application
allowing to inspect all the fields of the different headers (Ethereal).
5.2.1.2.1 IPv6 tests
All these tests were done with ping6, which is able to initialize the Traffic Class <strong>and</strong> Flow Label fields.
Besides, it sends ICMPv6 packets. With a simple “Echo Request”, it is possible to test all the IPv6 main
header fields, including the ICMPv6 packet detection (thanks to the Next Header field). The Payload
Length <strong>and</strong> Hop Limit fields are always initialized to 64, by default. The ping6 –P option initializes the
packet DSCP with a decimal value, <strong>and</strong> the –F option initializes the Flow Label with a decimal value.
With the following filter, <strong>and</strong> the ‘ping6 –P 180 –F 512 ::1’, we verified, thanks to Ethereal, that packets
were marked with the ‘101010’ DSCP:
Filter 0
Description IP6_Filter
IP6DSCP 101101
IP6SrcAddr ::1
IP6DestAddr ::1
IP6FlowLbl 512
IP6PayloadLen 64
IP6HopLim 64
IP6ICMP 1
CoS 101010
Note that ping6 initializes the eight bits of the Traffic Class field, instead of only the six left bits, as
defined in the DiffServ architecture. So, to initialize the DSCP with ‘101101’, we must use the ‘180’
value (‘10110100’ in binary). In a same way, Ethereal interprets all of the eight bits of the Traffic Class
field. So, when Ethereal reads the ‘168’ value in this field (‘10101000’ in binary), it corresponds to the
‘101010’ DSCP.
CEC Deliverable Number D0202 64 / 97

WP2-D0202 Version 1.0 4.6.2003
We also verified that, with ‘ping6 –P 180 –F 400 ::1’, the DSCP of the packet stayed unchanged.
5.2.1.2.2 UDP tests
All these tests were done with mgen6. This application is able to generate UDP packets on the top of
IPv6. The following comm<strong>and</strong> was executed: ‘mgen6 –b ::1,2037 –r 1 –s 1050 –d 1 –i eth0 –p 20000’.
The ‘-r’, ‘-s’, <strong>and</strong> ‘-d’ options define respectively the output rate (in packets per second), the size of the
packets, <strong>and</strong> the duration of the UDP flow. The ‘-b’ option defines both the destination address (::1) <strong>and</strong>
the destination port (2037). The ‘-p’ option defines the source port (20000). The Length of the packet sent
with this comm<strong>and</strong> is 1058.
With the following filter, <strong>and</strong> Ethereal, we verified that packets were marked with the ‘101010’ DSCP:
Filter 1
Description UDP_Filter
UDPSrcPort 20000
UDPDestPort 2037
UDPLen 1058
CoS 101010
We also verified that, if we changed the source or the destination port with mgen6, then the packets
stayed unmarked.
5.2.1.2.3 TCP tests
All these tests were done with telnet.
Telnet is a very simple way to test filters on TCP fields. The very first packet sent with a telnet uses the
source port number 32769.
The telnet connection establishment needs two packets:
• From the source to the destination: the source port is 32769, the destination port is 23, the
header length is 40 bytes, the window size is 32762, <strong>and</strong> the synchronization bit is set to 1;
• From the destination to the source: the source port is 23, the destination port is 32769, <strong>and</strong>
when the connection is refused, the header length is always 20, the window size is 0, <strong>and</strong> both
the acknowledgement <strong>and</strong> reset bits are set to 1.
Only the sequenced number is very difficult to foresee in this case. So, we did not test it.
The following filters were defined:
Filter 2
Filter 3
Description TCP_Filter_Init Description TCP_Filter_Ack
TCPSrcPort 32769
TCPSrcPort 23
TCPDestPort 23
TCPDestPort 32769
TCPLen 40
TCPLen 20
TCPCtrlSyn 1
TCPCtrlAck 1
CoS 101010
TCPCtrlRst 1
CoS 101110
With these filters, during the very first ‘telnet ::1’ execution (no telnet daemon was launched, <strong>and</strong> the
connection had to be refused), Ethereal showed that the packets were correctly marked. Then, if we
executed this comm<strong>and</strong> a second time, then the packets stayed unmarked, because the source port of the
first packet sent had changed (32770).
5.2.2 Second tests series
This second tests series only validated the new filtering capabilities added in the second version of the
software. Only the ‘CoS’ was tested again, but only because the format of this field had changed: in the
first version, the value of the field was only a DSCP (e.g. 101100), <strong>and</strong> in the second version, a service
identifier (e.g. S1, S2,…) could also be used instead.
5.2.2.1 DSCP values loaded from the network
We firstly associated new DSCP decimal values to the different services, by writing the following lines
on the /dev/dscp character device:
SIG 50
S1 5
S2 10
CEC Deliverable Number D0202 65 / 97

WP2-D0202 Version 1.0 4.6.2003
In /var/log/messages, the TUM prints were:
S3 15
S4 20
S5 25
S6 30
S7 35
Apr 10 16:43:37 hathor kernel: dscp: open
Apr 10 16:43:37 hathor kernel: dscp: write
Apr 10 16:43:37 hathor kernel: Service 0 = Name: SIG - DSCP: 0x32
Apr 10 16:43:37 hathor kernel: Service 1 = Name: S1 - DSCP: 0x 5
Apr 10 16:43:37 hathor kernel: Service 2 = Name: S2 - DSCP: 0x A
Apr 10 16:43:37 hathor kernel: Service 3 = Name: S3 - DSCP: 0x F
Apr 10 16:43:37 hathor kernel: Service 4 = Name: S4 - DSCP: 0x14
Apr 10 16:43:37 hathor kernel: Service 5 = Name: S5 - DSCP: 0x19
Apr 10 16:43:37 hathor kernel: Service 6 = Name: S6 - DSCP: 0x1E
Apr 10 16:43:37 hathor kernel: Service 7 = Name: S7 - DSCP: 0x23
Apr 10 16:43:37 hathor kernel: dscp: release
Then, we used the following filter:
Filter 1
Description Service_ID
IP6DSCP 0
CoS
S4
Finally, we verified with Ethereal that all the outgoing packets (with the DSCP initialized to ‘0’) were
marked with the S4 DSCP value, i.e. 20 (14 in hexadecimal).
5.2.2.2 Destination Option
5.2.2.2.1 Binding Update (BU)
The different BU fields were tested by triggering h<strong>and</strong>overs. When a MT enters in a new domain, a BU is
sent to its HA. This BU is identified thanks to its option type value set to 198, <strong>and</strong> contains the following
values:
• the option length is set to ‘8’,
• the association life time is set to ‘10000’,
• the length of the prefix to use for MT addresses is set to ‘0’,
• the BU acknowledgement request, the HA request, <strong>and</strong> the Mobile Router bits are set to ‘1’,
while the Duplicate Address Detection request, the MAP registration, the Bicasting request <strong>and</strong>
the two reserved bits are set to ‘0’,
• the BU sequence number is linearly increased, so that we were able to foresee a specific value;
in this test, we have triggered several h<strong>and</strong>overs while the sequenced number reached the value
‘80’.
So, the following filter was defined:
Filter 1
Description BU_Filter
ExtBULg 8
ExtBUA 1
ExtBUH 1
ExtBUR 1
ExtBUD 0
ExtBUMAPReg 0
ExtBUBicast 0
ExtBUResv 0
ExtBUSeqNum 80
ExtBULTime 10000
CoS
SIG
CEC Deliverable Number D0202 66 / 97

WP2-D0202 Version 1.0 4.6.2003
Note that the ExtBU filtering rule only allows the detection of a BU in each packet. We tested this field
by replacing all the previous rules by the following one: ‘ExtBU 1’.
5.2.2.2.2 Binding Acknowledgement (BA)
When a BU is sent with a BU acknowledgment request bit set to ‘1’, the HA sends a BA to the MT. So,
during the same test than the BU, we monitored <strong>and</strong> filtered the outgoing packets on the HA. The
following filter was used:
Filter 1
Description BA_Filter
ExtBALg 11
ExtBAStatus 131
ExtBASeq 0
ExtBALTime 1000
ExtBARefresh 10000
CoS
SIG
Due to configuration issues, the BU sent by the MT to the HA was systematically refused, which was a
good opportunity to test a particular value of the BA status (131).
5.2.2.2.3 Home Address (HoA)
The HoA option is included in the same packet than the BU, <strong>and</strong> is sent to the CN. So, this test could be
done at the same time than the BU test, with a second filter:
Filter 2
Description HoA_Filter
ExtHoALg 16
ExtHoAAddr fec0::1234:a:b:c:d
CoS
SIG
Of course, ‘fec0::1234:a:b:c:d’ was the MT HoA, <strong>and</strong> was a 16 bytes length address.
5.2.2.2.4 Binding Request (BR)
Not tested.
5.2.2.3 Hop-by-hop Option
Not tested.
5.2.2.4 Sub-options
Not tested. However, the option <strong>and</strong> sub-option detection is done by a same function able to parse options
encoded with the TLV format. This function has been successfully tested with the different Destination
Options, <strong>and</strong> the Pad <strong>and</strong> PadN options. So, it seems reasonable to think that sub-options detection cannot
cause any problem.
5.2.2.5 Fragment header
The original Maximum Transmission Unit (MTU) of an IPv6 packet is 1500 bytes. To test the fragment
header fields, we generated a UDP flow with a packet size set to 2000 bytes, thanks to the ‘mgen6’
comm<strong>and</strong>, with the ‘-s 2000’ option. During the test, the fragment identifier was increasing linearly, so
that we could foresee a packet with this identifier set to ‘10’. The M bit in the fragment header is set to ‘1’
in all the fragments of the same packet, excepted for the last one. With a packet size set to ‘2000’, each
packet was divided in two fragments, <strong>and</strong> only the first fragment had the M bit set to ‘1’, <strong>and</strong> the
fragment place set to ‘0’. All these fields were tested with the following filter:
Filter 1
Description Fragment_Filter
ExtFragId 10
ExtFragM 1
ExtFragPlace 0
CoS
S6
CEC Deliverable Number D0202 67 / 97

WP2-D0202 Version 1.0 4.6.2003
The ExtFrag filtering rule was tested separately, with a filter containing only one rule: ‘ExtFrag 1’.
5.2.2.6 Routing header
The routing header fields were tested at the same time than the BU, BA <strong>and</strong> HoA. In fact, the packet
which contained the BA going from the HA to the AR also contained a routing header. The goal of this
routing header was to impose the path the BA had to follow, including the destination. For these tests, the
HA was directly linked to the AR. Thus, the path contained only the destination, i.e. the MT address
(fec0::1234:a:b:c:d), the route length was set to ‘2’ (this is the size of the path in number of 64 bits
words), the route type set to ‘0’ (i.e. source routing) <strong>and</strong> the number of remaining segments set to ‘1’.
Two filters were used successively, with the same results:
Filter 1
Filter 1
Description Routing_Header Description Routing_Header
ExtRoutLg 2
ExtRoutLg 2
ExtRoutType 0
ExtRoutType 0
ExtRoutSeg 1
ExtRoutSeg 1
ExtRoutAddrN fec0::1234:a:b:c:d ExtRoutAddrDest fec0::1234:a:b:c:d
CoS
SIG
CoS
SIG
5.2.2.7 Authentication header
Only the presence of the header was tested.
5.2.2.8 ESP header
Only the presence of the header was tested.
5.2.2.9 ICMPv6 header
ping6 <strong>and</strong> mgen6 were both used. The detection of an ICMPv6 packet (i.e. the ICMP6Header field) was
tested with ‘ping6 ::1’. The type <strong>and</strong> code fields of each ICMPv6 packet were tested with mgen6. By
initiating a UDP flow on a bad output port (50235, for ex.), with ‘mgen6 –b ::1,50235’, an ICMPv6
packet was created with type set to ‘1’ <strong>and</strong> code set to ‘4’ (port unreachable). Then, these two fields could
be tested at the same time with the following filter:
Filter 1
Description ICMP6_Filter
ICMP6Type 1
ICMP6Code 4
CoS
SIG
5.2.2.10 Tunneled packets inner header
Only the presence of the header was tested.
5.3 Radio resource management tests
These test have been performed as part of several integration meetings.
The first test took place in the last quarter of 2002. At this first stage, when the RRC connection is
established, it triggers the automatic establishment of the signaling radio bearers for the control path, <strong>and</strong>
of a single dedicated channel for the data path. The Transport Channels used are: the BCH (Broadcast
Channel), the FACH / RACH (common channels) <strong>and</strong> one DCH (dedicated channel, mainly for data).
The data channel provides a data rate of 144 kbps on the Uplink (MT to RG), 384 kbps peak rate on the
Downlink (RG to UE). The main parameters used for configuring theses channels are: 3 time slots, 5
Transport Formats, a convolution code ½, a TTI of 10 ms <strong>and</strong> the RLC in AM mode.
Several types of traffic could flow through the interface: ICMPv6 (PING), Web (http), video
transmission.
We could visualize the correct slot utilization according to the desired TDD configuration.
This test validated the execution of the Real Time TD-CDMA over the air interface <strong>and</strong> its direct
interconnection to IPv6.
CEC Deliverable Number D0202 68 / 97

WP2-D0202 Version 1.0 4.6.2003
The second session tested the whole chain: Mobile Terminal- Radio Gateway – Access Router. When the
TD-CDMA Radio Gateway is started, we can monitor the transmission of the broadcast, containing the
common channels (RACH-FACH) configuration determined in the Access Stratum.
When the TD-CDMA Mobile Terminal is started, it monitors the broadcast channel <strong>and</strong> retrieves the
common channels parameters. When the attachment to the network is triggered, we can monitor the setup
of the common transport channels based on the retrieved parameters <strong>and</strong> then of the signalling radio
bearers.
Then a PING6 comm<strong>and</strong> is entered in the MT. This triggers the computation of a new configuration in the
RRM <strong>and</strong> the upload of this configauration in the Mobile Terminal, resulting in the set-up of a radio
bearer for data transmission <strong>and</strong>, when ready, the transmission of the PING6 packet up to the Access
Router <strong>and</strong> backwards. The DSCP Marking Software has been installed as well <strong>and</strong> we could verify that
the packets could be marked on request.
As before, we could visualize the correct slot utilization according to the desired TDD configuration.
For the last seesion, the RRM entity was modified to provide configurations for up to 3 MTs, having each
one 2 different radio bearers, according to the requested QoS class.
o For class R2, mapped from service S1 (class EF), the RB is a duplex DCH 32 kbps,
with real-time capabilities
o For class R9, mapped from service S6 (class BE), the RB is a DCH with 256 kbps DL
<strong>and</strong> RACH for the UL
The signalling traffic is on the common channels, whose b<strong>and</strong>width has been increased.
This is shown in picture 68 taken during the last test, where vic was demonstrated.
Figure 68: Picture from the integration test in Stuttgart
This picture shows the Radio Gateway <strong>and</strong> the Mobile Terminal during the test. On the left monitor the
TD-CDMA visualization tool shows the traffic flowing on the TDD slots in the Radio Gateway. The
yellow shows the amplitude of the received signal on the time line. The red shows the power of signal
received in the slots. The video is received on the Mobile Terminal.
6. Conclusions
In summary, the main milestones of Workpackage 2 effort can be mapped to three integration meetings
that were held for integration, test <strong>and</strong> evaluation purposes within the framework of WP5:
• Our first integration meeting was in Madrid in October 2002. The first version of a running QoS
Broker was deployed <strong>and</strong> its communication with a AAAC Attendant running pep6 was tested.
Likewise, the QoS Attendant was successfully installed <strong>and</strong> tested.
• The second integration meeting, held in Nice in March 2003, gave us the opportunity to test the
interface between two QoS Brokers, as well as the interaction between a QoS Broker <strong>and</strong> the
CEC Deliverable Number D0202 69 / 97

WP2-D0202 Version 1.0 4.6.2003
B<strong>and</strong>width Manager. We also updated the Access Router interface in order to enable it to receive
FHO messages so that we could test the support for Fast H<strong>and</strong>over mechanisms. Finally, we also
updated the AAAC interface to receive QoS profiles definition. Note that although the QoS
mapping between IP <strong>and</strong> radio was already defined at that time, only one MT <strong>and</strong> one data
channel were supported then.
• During the last integration meeting in Stuttgart in May 2003 we came up with a complete QoS
solution including the QoS Broker with its complete functionality. These QoS components were
integrated with the AAAC system <strong>and</strong> the mobility system. Based on this architecture, we
demonstrated three QoS scenarios.
The integration is now almost finished: all should be finished by mid-June 2003. We plan to start the
measurements then, in order to have performance evaluation of our test-bed, before the trials with real,
non technical users begin in July 2003.
7. References
[1] An Architecture for Differentiated Service. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss. December 1998.
[2] A. Mokhtar, N. Chaher, Ch. Beaujean, P. Pacyna, J. Gozdecki, K. Dolzer, J. Gerke, V. Marques, R.
Aguiar, J. I. Moreno, C. Garcia, T. Ziegler, Y. Moret, M. Wetterwald, „Initial Design <strong>and</strong>
Specification of the Moby Dick QoS Architecture“, Moby Dick Deliverable D0201, 85 pages, April
2002.
[3] V. Marques et al, An IP-based QoS architecture for 4G operator scenarios, IEEE Wireless
Communications, 2003.
[4] 3GPP TS 25.331 V4.5.0 (2002-06), 3rd Generation Partnership Project; Technical Specification
Group Radio Access Network; Radio Resource Control (RRC); Protocol Specification (Release 4)
CEC Deliverable Number D0202 70 / 97

WP2-D0202 Version 1.0 4.6.2003
8. APPENDIX A: QUALITY OF SERVICE CONFIGURATION
In this section we will see both QoS <strong>and</strong> policing structures that are created when Router starts up
governed by the configuration files in the QoSBroker. Also we are going to present the authorization <strong>and</strong>
reconfiguration processes.
8.1 QoSBroker configuration files
When the QoSBroker starts up it loads two configuration files. The first of them is called the ‘politics file’
that is the one in charge of associating traffics’ policing specification parameters –as the b<strong>and</strong>width, the
burst <strong>and</strong> the priority– to traffic’s DSCPs. Indeed this file is not loaded by the QoSBroker locally but sent
to it by the AAAC.f. The second file is called the ‘behaviour file’ <strong>and</strong> it is the one in charge of associating
the DiffServ DSCPs to different QoS queues configurations (PHBs).
The politics file has a list structure <strong>and</strong> is used when the AAAC.f indicates the QoSBroker the DSCPs that
the MTs, in this domain, will use to mark traffics. The AAAC.f also communicates to the QoSBroker the
policing parameters of the “NetServices” that these DSCPs require. Those DSCPs are also forwarded to
the MT <strong>and</strong> it will use them to mark its packets. When those packets pass through the Access Router, it
makes a petition to the QoSBroker to know if it should police that traffic towards the core network or if it
should not give policing to them, i.e. discard them. The QoSBroker looks at their installed connections
<strong>and</strong> responds it yes or not. When the QoSBroker authorizes a traffic towards the MobyDick’s core
network, the router also obtains from this file the policing information (BW <strong>and</strong> burst) necessary in the
QoSManager. The policy file used in the test is shown in Table 8:
Destination
address
Traffic’s BW
(kbps)
Burst size
(Bytes)
Priority DSCP
(hex)
::0 0 0 0 0
::0 100 1514 1 2e
::0 90 1514 2 22
::0 80 1514 2 24
::0 70 1514 2 26
::0 60 1514 3 1a
::0 50 1514 3 1c
::0 40 1514 3 1e
::0 30 1514 4 12
::0 20 1514 4 14
::0 10 1514 4 16
::0 9 1514 5 0a
::0 8 1514 5 0c
::0 7 1514 5 0e
Table 8: politics file table used in the tests
It must be noted that this table is only used for tests, moby dick will employ the following Table 9:
Destination
address
Traffic’s
BW (kbps)
Burst size
(Bytes)
Priority DSCP
(hex)
::0 1 1514 2 0x22
::0 32 1514 1 0x2e
::0 256 1514 3 0x12
::0 64 1514 4 0x0a
::0 128 1514 4 0x0c
::0 256 1514 4 0x0e
::0 32 1514 0 0x00
::0 64 1514 0 0x02
::0 256 1514 0 0x04
Table 9: Policy table used in Moby Dick
CEC Deliverable Number D0202 71 / 97

WP2-D0202 Version 1.0 4.6.2003
The first column in this table describes the traffic’s destination address allowed to send packets to having
the DSCP indicated on the fifth column. If this value is ‘::0’ all destination addresses are authorized. The
second <strong>and</strong> third columns are the policer information, the fourth the priority <strong>and</strong> the fifth is the DiffServ
DSCP authorized field.
Experimental tests have shown that the minimum burst size depends on the b<strong>and</strong>width this way:
min_ burst _ size = b<strong>and</strong>width ⋅5⋅
MTU
With the 'b<strong>and</strong>width' in Mbps. The obtained result units are bytes. If the result is smaller than the MTU
the burst size must be the MTU.
The behaviour file has also a list structure <strong>and</strong> is used when the Router requests the QoSBroker the
access interface QoS configuration queues <strong>and</strong> its associates DSCPs.
The first time that the configuration list is transferred is, as we have already seen, when the Router starts
up. It is transferred line by line in a COPS ‘Configuration Decision’ message.
In the following Table 10 we can see the behaviour list that we have used for the tests. Next we will
comment all its fields <strong>and</strong> properties.
DSCP
(hex)
Aggregate
number
BW
(kbps)
Borrow
BW?
RIO minimum
queue size
(kB)
RIO maximum
queue size
(kB)
RIO limit
queue size
(kB)
RIO queue
discard
Probability(%)
0 0 0 1 0 0 0 0
2e 1 800 0 0 0 0 0
22 2 700 0 500 700 1000 10
24 2 600 0 400 600 750 25
26 2 500 0 300 500 600 50
1a 3 400 0 250 500 750 10
1c 3 300 0 200 400 600 25
1e 3 200 0 150 300 400 50
12 4 100 0 150 250 300 10
14 4 90 0 100 200 250 25
16 4 80 0 50 100 150 50
0a 5 70 0 10 40 60 10
0c 5 60 0 5 15 25 25
0e 5 50 0 3 10 15 50
Table 10: Behaviour file table employed for the tests
We must note that the previous table was only used for the tests. Moby dick should employ the following
table (Table 11). In this table (tailored to 100 Mbps Ethernet access interface) only the first two columns
are immutable. The rest can be changed <strong>and</strong> build, for instance, a table valid for 2Mbps WLAN access
interface.
DSCP
(hex)
Aggregate
number
BW
(kbps)
Borrow
BW?
RIO
minimum
queue
size (kB)
RIO
maximum
queue
size (kB)
RIO limit
queue
size (kB)
RIO queue
discard
Probability(%)
0x00 0 15000 1 0 0 0 0
0x2e 1 25000 0 0 0 0 0
0x22 2 5000 0 250 500 600 10
0x12 3 25000 0 1250 2500 3000 10
0x0a 4 15000 0 750 1500 2000 10
0x0c 4 10000 0 500 1000 1250 25
0x0e 4 5000 0 250 500 600 50
Table 11: Example of behaviour table employed in Moby Dick
CEC Deliverable Number D0202 72 / 97

WP2-D0202 Version 1.0 4.6.2003
Its fields are:
- DSCP: all packets thru the access interface having the specified DSCP will be routed to the
queue described by the other fields of the row.
- Aggregate number: this value indicates to which queue (CBQ discipline class) a flow must be
routed on the access interface. This field has the following particularities:
o The ‘0’ aggregate number is reserved for the default or best-effort traffic. This traffic
doesn't need a RIO/GRED queue planning so all the following parameters are ignored.
We can only have a line with this number. All the access flows having a DSCP not
registered in the table will be headed to this queue. If we put in this aggregate 0 kbps,
all default packets will be discarded.
o The ‘1’ aggregate number is reserved for the maximum priority traffic called Expedited
Forwarding (EF) <strong>and</strong> for signaling. Towards this aggregate all messages that the Router
generates, including those of the COPS, DIAMETER <strong>and</strong> ICMPv6 protocol will be
routed. This traffic doesn't need a RIO/GRED queue planning so all the following
parameters are ignored. We can only have a row with this number.
o The other aggregate numbers (from ‘2’) are used for Assured Forwarding (AF) or
independent classes, <strong>and</strong> their priorities descend in the same value that their aggregate
number. This aggregate type allows 4 configurations:
A CBQ independent class: if there is only a row with this aggregate number
<strong>and</strong> if it doesn't have the RIO discipline parameters. In this case a CBQ class is
created for that DSCP without RIO planning.
A CBQ independent class with RIO discipline: if there is only a row with this
aggregate number <strong>and</strong> it has the RIO discipline parameters. In that case a CBQ
class is created for that DSCP with its indicated RIO queue planner.
More than a CBQ class: if there are several rows with the same aggregate
number <strong>and</strong> they don't have any RIO discipline parameters. In this case only
one CBQ class is created for all the DSCPs (DSCP class) without RIO
planning. The CBQ class b<strong>and</strong>width will be the b<strong>and</strong>width rows sum.
More than a CBQ class with RIO disciplines (typical AF): if there are several
rows with the same aggregate number <strong>and</strong> they all have the RIO discipline
parameters. In this case only a CBQ class is created for all the DSCPs (DSCP
class) with an independent RIO queue planner for each DSCP as their
parameters indicate. Usually, in AF, there are three rows with the same
aggregate number; this is because inside an AF class there are three traffic
types according to the queues capacities. The Router checks the aggregate
number repetitions in this field <strong>and</strong> adds its b<strong>and</strong>widths in one CBQ class.
Also, the Router creates a RIO planning algorithm for each DSCP with the
parameters that we will see later.
- B<strong>and</strong>width: the third parameter is the reserved b<strong>and</strong>width for each DSCP. When a class is
formed by several DSCPs (usually in AF) the b<strong>and</strong>width of that class will be the sum of all the
rows’ b<strong>and</strong>widths with the same aggregate number. This value is expressed in kbps.
- B<strong>and</strong>width Borrow Flag: this interesting parameter allows, to the aggregate which has it set to
‘1’, to use the b<strong>and</strong>width that other classes are not using <strong>and</strong>/or the remaining BW on the
interface. Related with this parameter there is another one called ‘isolated class’ that allows a
class not to lend its remaining b<strong>and</strong>width. In our Router we have chosen to enable in all classes
the previous hidden flag. Therefore, the maximum class b<strong>and</strong>width that is created when the
borrow flag is activated will vary in function of the other classes occupation but having a
minimum b<strong>and</strong>width benchmark equals to the reserved with its ‘BW’ parameter in the list. In
some tests we have used this field for the ‘best-effort’ traffic.
- (Average) minimum RIO queue size: This parameter indicates the average minimum RIO
queue capacity associated to a DSCP. If the average enqueued size surpasses this capacity the
packet dropping will begin. In ‘0’ <strong>and</strong> ‘1’ aggregates this parameter is obviated. The RIO queue
will be created by means of a GRED discipline. This parameter is expressed in kBytes.
- (Average) maximum RIO queue size: This parameter indicates the average maximum RIO
queue capacity associated to a DSCP. The queue size that reaches this value (in average) will
experience a drop probability in their packets similar to the value that is indicated in the ‘RIO
drop probability’ parameter. Beyond this threshold all new packets that surpass the size will be
discarded. In ‘0’ <strong>and</strong> ‘1’ aggregates this parameter is obviated. This parameter is expressed in
kBytes.
- RIO limit queue size: This parameter indicates the physical capacity that the TC API reserves to
a RIO queue associated to a DSCP. If the real queue capacity (not average) reaches this value, all
CEC Deliverable Number D0202 73 / 97

WP2-D0202 Version 1.0 4.6.2003
new packets will be discarded for any average occupation value. In the ‘0’ <strong>and</strong> ‘1’ aggregates
this parameter is obviated. This parameter is expressed in kBytes.
- RIO queue drop probability: This parameter indicates the discard probability that a packet has
if the average maximum RIO queue size is reached. This parameter, together with the two first
ones, fixes the RIO discard probability straight line (see TC API RIO implementation for details
on this). In ‘0’ <strong>and</strong> ‘1’ aggregates this parameter is obviated. This parameter is expressed as a
percent of discards.
We have to highlight that in the described behaviour list we have used the IANA DSCPs st<strong>and</strong>ard codes
assigned to BE, EF <strong>and</strong> AFxy classes. Nevertheless, the file does not tie DSCPs with queue types:
changing values on the DSCP column we could assign, for example, to the ‘0x0E’ DSCP the EF queue by
putting in it the ‘1’ aggregate number.
It is also important to recall that the GRED queue disciplines choose the RIO queue associated to a packet
in function of the last three bits of the DSCP, that is because the Router extracts these bits of the DSCP
field <strong>and</strong> creates its corresponding RIO queue (VQ). Nevertheless, for a good operation, the router needs
that in each AF class exists a DSCP finished in ‘100’ (4) to take it as the default RIO queue.
8.2 QoS <strong>and</strong> policing trees created on the Router
When the router starts up, it opens two netlink socket sessions with the kernel’s DiffServ logic (one for
each interface) <strong>and</strong> obtains the necessary interfaces information to be able to execute TC API functions.
Once done this, it proceeds to register <strong>and</strong> to request the configuration to the QoSBroker by means of the
COPS protocol, as we have already seen. At the end of this whole process, the Router has two open TC
API sessions <strong>and</strong> the same behaviour list that the QoSBroker.
It is now when the Router should be able to interpret the received list <strong>and</strong> to generate the QoS tree that the
QoSBroker has transmitted to it for its access interface. Also the router initialises the basic TC API
structures for the core interface. For that, the following steps are executed:
1. ACCESS: The root queuing discipline associated directly to the device is created, this will be a
DSMARK qdisc to be able to copy the TClass to the ‘skb->tc_index’ structure. Its h<strong>and</strong>ler will
be the 1:0.
2. ACCESS: To the previous discipline a TCINDEX filter is associated. It will modify the TClass
value stored in the ‘skb->tc_index’. The final result that will stay in this field will be the last
three bits of the DSCP, necessary to choose the appropriated RIO queue in case that the packet
will be headed towards an AF queue.
3. ACCESS: A CBQ queuing discipline is created as a child of the DSMARK queuing discipline.
Its h<strong>and</strong>ler will be the 2:0.
4. ACCESS: Next, the Router creates the CBQ class 2:62, where the whole traffic will be redirected
during the time that a reconfiguration lasts.
5. CORE: The root queuing discipline associated directly to this device is created, this will be a
CBQ qdisc to support filters with policing. Its h<strong>and</strong>ler will be the 1:0.
6. CORE: the Router creates then the unique CBQ class 1:1, where the whole traffic will be
redirected. The functionality in this interface will reside on the dynamic filters.
7. CORE: next, the signaling filters are created: three U32 filters not applying policing to the
packets that the router generates thru theirs. Packets will be routed towards the previous CBQ
class sharing the whole interface b<strong>and</strong>width. One of them will classify packets with the linklocal
AR source address <strong>and</strong> the others packets with both DNSv6 AR source addresses. Their
number will be #1, #2 <strong>and</strong> #3.
8. CORE: the router creates now the default filter that will classify all not-classified packets
towards the CBQ class 1:1 but using a policer with 8bps of b<strong>and</strong>width <strong>and</strong> a burst size of 1 Byte.
That’s is: traffics routed towards this filter will be blocked. The filter number will be #255.
9. ACCESS: Subsequently the router looks for the ‘0’ aggregate in the received list <strong>and</strong> creates for
it the CBQ class 2:63 with its list parameters, priority 8 <strong>and</strong> without RIO. It also adds a U32
filter (#255) to the CBQ discipline to guide all not classified packets to this class.
10. ACCESS: Next, the router looks for the ‘1’ aggregate in the list <strong>and</strong> creates for it the CBQ class
2:1 with its parameters, priority 1 <strong>and</strong> without RIO. It also adds four U32 filters to the CBQ
discipline. The first <strong>and</strong> the second ones (#2 & #3) will guide packets having the Router access
<strong>and</strong> core interface DNSv6 IPv6 source addresses towards this class. Thus, the high level
signaling packets that the Router generates (including the COPS <strong>and</strong> DIAMETER protocol
messages) will have the best quality. The third U32 filter added (#4), will guide all packets
having the Router access interface Link Local address towards this class. Thus, low-level
CEC Deliverable Number D0202 74 / 97

WP2-D0202 Version 1.0 4.6.2003
signaling packets (as ICMPv6 messages) will have the best quality. Finally, the fourth filter (#5)
is the st<strong>and</strong>ard filter that will guide all packets having the DSCP specified in the aggregate
number ‘1’ towards the class 2:1.
11. ACCESS: To finish the initialisation, the router creates so many AF/independent classes as
aggregates bigger than ‘1’ are in the list. Their priority <strong>and</strong> class h<strong>and</strong>ler will be its aggregate
number. The router sums individual b<strong>and</strong>widths (in repeated aggregates) <strong>and</strong> creates a RIO
discipline for each DSCP if RIO parameters are set. The router also adds so many U32 filter as
aggregates/DSCP classes (the first three bits of the DSCP field) have been received. These filters
will guide packets to classes based on the DSCP class.
CEC Deliverable Number D0202 75 / 97

WP2-D0202 Version 1.0 4.6.2003
The trees that are obtained for the previously exposed list will have the following Figure 69:
Root queuing
discipline DSMARK
H<strong>and</strong>le 1:0
set tc index = true
TCINDEX filter
mask: 0x1C
Shift: 2
Fall_thru: yes
CBQ queuing
discipline
H<strong>and</strong>le 2:0
Avg. Pack. size: 1000
U32 filter number 4
Test Link Local
Router U32 source filter address, number 3
maps Test it towards U32 DNSv6 filter 2:1 Router number 2
source Test a address, DNSv6 Router
maps it source towards address, 2:1
maps it towards 2:1
U32 filter number 5
If DSCP class: 101b maps to 2:1
U32 filter number 6
If DSCP class=100b maps to 2:2
U32 filter number 7
If DSCP class=011b maps to 2:3
U32 filter number 8
If DSCP class=010b maps to 2:4
U32 filter number 9
If DSCP class=001b maps to 2:5
U32 filter number 255
No conditions
(default)
Maps to 2:63 class
CBQ class
ClassID = 2:1
BW = 800 kbps
borrow BW = No
CBQ Class
ClassID = 2:3
BW = 900 kbps
borrow BW = No
CBQ class
ClassID = 2:5
BW = 180 kbps
borrow BW = No
CBQ class
ClassID = 2:63
BW = 0
borrow BW=yes
CBQ class
ClassID = 2:2
BW = 1800 kbps
borrow BW = No
CBQ class
ClassID = 2:4
BW = 270 kbps
borrow BW = No
CBQ class
ClassID = 2:62
BW=RECONFIG
borrow BW = No
qDisc
GRED
h<strong>and</strong>le: 3:0
numDP: 8
qDisc
GRED
h<strong>and</strong>le: 4:0
numDP: 8
qDisc
GRED
h<strong>and</strong>le: 5:0
numDP: 8
qDisc
GRED
h<strong>and</strong>le: 6:0
numDP: 8
VQ 2
(010b)
P:10%
VQ 4
(100b)
P:25%
VQ 6
(110b)
P:50%
VQ 2
(010b)
P:10%
VQ 4
(100b)
P:25%
VQ 6
(110b)
P:50%
VQ 2
(010b)
P:10%
VQ 4
(100b)
P:25%
VQ 6
(110b)
P:50%
VQ 2
(010b)
P:10%
VQ 4
(100b)
P:25%
VQ 6
(110b)
P:50%
Figure 69: QoS tree created on the router’s access interface
CEC Deliverable Number D0202 76 / 97

WP2-D0202 Version 1.0 4.6.2003
In this simplified graph (only the most important configuration parameters appear) is represented the QoS
tree that the Router creates when it receives the behaviour file at start up. In it we can see all the classes,
disciplines <strong>and</strong> filters that we have explained in the configuration sequence for the access interface. We
have also drawn a blue square ’ ’ in the place where the reconfiguration filter will be placed.
The TCAPI tree created on the core interface in the initialisation is Figure 70:
Root CBQ queuing
discipline
H<strong>and</strong>le 1:0
Avg. Pack. size: 1000
CBQ class
ClassID = 1:1
BW = 100 Mbps
borrow BW=Yes
U32 filter number 3
Test Link Local Router
source U32 filter address, number 2
maps If it DNSv6 towards U32 Router filter 1:1 number source 1
If a DNSv6 address, Router source
maps to 1:1 (no address, policing)
maps to 1:1 (no policing)
U32 filter number 255
No conditions
(default),
maps to 1:1 (Blocking)
Figure 70: QoS tree created on the router’s core interface
We have added a red circle ‘O’ in the place where, during operation, filters are added <strong>and</strong> removed
classifying traffics towards the class 1:1 applying policers. By default all packets are sent to class 1:1 <strong>and</strong>
blocked as the filter 255 indicates.
While the Router is creating the trees with the TC API functions it records in a variable the result of all
the comm<strong>and</strong>s. Once the trees creation sequence is completed <strong>and</strong>, if some function has failed, this
variable would cause the ‘<strong>Report</strong> Configuration’ message to be negative <strong>and</strong> the QoSManager will close
the connection. Otherwise the report will be affirmative <strong>and</strong> the process will follow its course.
8.3 QoS re-configuration
As we have already commented, the QoSBroker can request the Router for a reconfiguration in the QoS
queues of the access interface at any time during its execution.
The PDP, by means of queues use reports that the Router sends to it <strong>and</strong> by its network & traffic
administration algorithms, can modify the behaviour data list <strong>and</strong> request the Router a configuration
sequence repetition.
In the COPS messages sequences we saw how, by means of the ‘flags’ field in the decision messages,
QoSBroker can request the Router a reconfiguration. We pass now to detail the operation sequence that
the PEP carries out in an event of this type.
If the received flag value is ‘2’:
1. The installed CBQ classes are counted (except the reconfiguration class that is not counted).
2. The list where the Router keeps the configuration that the QoSBroker sent to it previously is
initialised. This is necessary since the number of CBQ disciplines that the QoSBroker wants to
install can be smaller than those that are now installed.
3. The first part of a configuration request sequence is done. Therefore, a ‘Configuration Request’
message is sent <strong>and</strong> the QoSBroker responds it with a ‘Configuration Decision’ message in
which the new behaviour file goes, overwriting this way our empty behaviour list. Let us recall
that the previous disciplines <strong>and</strong> filters still continue working.
4. A U32 filter is settled at the beginning of the filters line (#1). It provisionally will send all
packets to the 2:62 CBQ class queue that has a b<strong>and</strong>width of ‘RECONFIG_BW’ kbps.
5. All the installed DSCP class filters are deleted. The default (#255) <strong>and</strong> the signaling filters (#2,
#3 <strong>and</strong> #4) are also removed. This is done because installed filters cannot be conserved towards a
class that maybe won’t be reconstructed or has another number.
6. It is now when all the CBQ classes are removed except the 2:62. It should be made this way
because TC API doesn’t allow removing a class that is being used. At this time we have the
certainty that all packets are sent to the reconfiguration class 2:62.
7. It is now when the received classes in the configuration message are created. They were stored in
our behaviour list.
8. Now the QoSBroker is informed about the QoS queues applying result on the Router’s access
interface by sending to it the last configuration message: the ‘Configuration <strong>Report</strong>’ message.
9. The temporal filter (#1) that classifies towards the reconfiguration class is removed.
10. Finally it sets the flag to ‘0’ again, the statistics structures are initialised <strong>and</strong> the new default
DSCP is obtained.
CEC Deliverable Number D0202 77 / 97

WP2-D0202 Version 1.0 4.6.2003
As an explanation, we draw the QoS tree that stays during the short reconfiguration time interval – Figure
Root queuing
discipline DSMARK
H<strong>and</strong>le 1:0
set tc index = true
TCINDEX filter
mask: 0x1C
Shift: 2
Fall_thru: yes
CBQ queuing
discipline
H<strong>and</strong>le 2:0
Avg. Pack. size: 1000
U32 filter number 1
No conditions
(default)
Maps to 2:62 class
71:
CBQ class
ClassID = 2:62
BW=RECONFIG_BW
borrow BW = No
Figure 71: Temporal reconfiguration access interface QoS tree
In it we can see how all the CBQ classes except the reconfiguration one have been removed. Removing a
class or discipline erases all its children; the TC API does not care if they are disciplines, filters or other
classes.
In a same way, all filters have been removed. With this temporary tree we can create new filters <strong>and</strong> CBQ
classes without traffic interaction <strong>and</strong> also, it allows to configure the temporary traffic properties thru the
2:62 class modifying its TC API parameters via ‘defines’.
8.4 Outsourced policing towards core network
As we explained in the COPS message sequence section, the Router requests the QoSBroker the
treatment that it should give to a traffic when: (a) it detects an exiting traffic thru its core interface that it
is not installed yet or (b) when the time to live of a previously installed traffic expires.
According to the case <strong>and</strong> the answer that the QoSBroker returns, the router knows if it should install a
filter/policer, remove it or doesn’t do anything. We pass to see the different cases:
Active traffic not installed at this time
The Router checks periodically the active traffic’s captures from the access interface to the core one <strong>and</strong>
if they don't have the default DSCP. This information is provided to it by its associated capturing
program. Subsequently, it compares each active traffic with the traffics already installed in its list. If it
was already installed, the Router doesn't do anything but if not, the Router asks the QoSBroker <strong>and</strong>
according to its answer it works in the following way:
- Negative answer: nothing is done with the traffic (it is blocked). The traffic’s parameters are
added to the ‘forbidden’ table. This table prevents to ask for a rejected traffic every time the
router checks the capturer table. In case it continues being active, the Router will request for a
policer when the time to live of that traffic in the forbidden table is over. The traffic will
continue being blocked until then.
- Affirmative answer: then it records in its ‘installed connections’ list the traffic information
(source, destination address <strong>and</strong> DSCP) <strong>and</strong> the time in which it has been authorized. Then it
installs a filter towards the class 1:1 with a token-bucket policer. The parameters that the policer
needs are obtained from the ‘Affirmative Resource allocation’ COPS message.
Expired installed traffic
Periodically the router also verifies if some of the installed connections have its ‘lifetime’ expired <strong>and</strong> if
the MT is sending traffic. If the connection is installed but the MT is not transmitting packets, the router
CEC Deliverable Number D0202 78 / 97

WP2-D0202 Version 1.0 4.6.2003
will wait 60 seconds until remove the connection <strong>and</strong> its filter. This way, we avoid remove a temporally
sleeping traffic. If the traffic wakes up before 60 seconds of inactivity, the router will ask for it. The time
guard of 60 seconds is configurable in the QoSManager.
If the connection has expired <strong>and</strong> still has traffic, a petition to the QoSBroker is made <strong>and</strong>, according to
its answer, the following operations are carried out:
- Negative answer: it removes the TC API filter/policer that directs the traffic to the 1:1 class.
Also it removes the connection in the ‘installed connections’ list.
- Affirmative answer: In this case the only thing that it is necessary to do is to actualize the
connection lifetime. The filter/policer continues staying.
As a security mechanism <strong>and</strong>, in Router failures, the program has a function that removes connections
<strong>and</strong> filters that remain installed too much time.
To clarify how a traffic is added <strong>and</strong> removed from the TC API core tree we will expose later a figure.
But before, we want to highlight that the filters are ordered according to their number in a filter list. On a
packet arrival the TC begins to check the filters in order <strong>and</strong>, as soon as one verifies its conditions, it
redirects the packet to its programmed policer <strong>and</strong> class.
The core filter numbers ‘1’, ‘2’ <strong>and</strong> ‘3’are reserved for signaling. Starting from those numbers ordinary
filters are created according to the following number: connection h<strong>and</strong>le + 3.
In the following graph of Fig. 72 we present a tree with two policer filters installed:
Root CBQ queuing
discipline
H<strong>and</strong>le 1:0
Avg. Pack. size: 1000
CBQ class
ClassID = 1:1
BW = 100 Mbps
borrow BW=Yes
U32 filter number 3
Test Link Local Router
source U32 filter address, number 2
maps If it DNSv6 towards U32 Router filter 1:1 number source 1
If a DNSv6 address, Router source
maps to 1:1 address, (no policing)
maps to 1:1 (no policing)
U32 filter number 4
Match Adresses1 <strong>and</strong>
DSCP1 to class 1:1. Policer
parameters: BW=100kbps,
Burst= 1540Bytes.
U32 filter number 5
Match Adresses2 <strong>and</strong>
DSCP2 to class 1:1. Policer
parameters: BW=20kbps,
Burst= 1514Bytes.
U32 filter number 255
No conditions
(default),
maps to 1:1 (Blocking)
Figure 72: Example of an active policing tree on the core interface
When a connection disappears or is deauthorized the Router removes its corresponding filter. The filter’s
line is reconstructed automatically by joining the previous <strong>and</strong> later filters.
CEC Deliverable Number D0202 79 / 97

9. APPENDIX B: DEBUG MODE ACCESS ROUTER OUTPUT LINES
9.1 Access Router Initialisation
pulga:~/mobydick/QoS Manager/programs/> sudo ./router garrapata.ipv6 eth1 100 eth2 100 -d
Password:
************************************************************************************
**** IPv6 QoS/Policing ACCESS ROUTER [MobyDick] (COPS CLIENT, 2 interfaces) ****
************************************************************************************
- Debug mode enabled.
Core Interface speed: 104857600 bps
Access Interface speed: 104857600 bps
Debug: logger created
Reading file /proc/net/if_inet6...
-------------------------------------------------------------
Address: 00000000000000000000000000000001, interface: lo
Address: fe8000000000000002c026fffea0b2a0, interface: eth1
Address: fe8000000000000002c026fffe10217c, interface: eth0
Address: fe8000000000000002c026fffea0ad36, interface: eth2
Address: 200107200410100402c026fffea0ad36, interface: eth2
Address: 200107200410100302c026fffea0b2a0, interface: eth1
-------------------------------------------------------------
Opening connection with: garrapata.ipv6.it.uc3m.es (2001:720:410:1003:204:75ff:fe7b:943e)
---------------------------------------------
Sending CLIENT OPEN message to server
Message from QoS Broker
CLIENT ACCEPT message received
Received a KEEP-ALIVE object
Received an AcctTimer object
KATimer value: 120, AcctTimer value: 20
Sending a CONFIGURATION REQUEST message to server
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=0
Received a CONTEXT object
Received a DECISION FLAGS object
CONFIGURATION DECISION RECEIVED O.K.
CEC Deliverable Number 80 / 97

WP2-D0202 Version 1.0 4.6.2003
--------------------------------------------
BEHAVIOUR TABLE received:
DSCP | Agre. | B<strong>and</strong>width | BW Borrow | RIO min queue | RIO max queue | RIO limit queue| RIO drop|
| Number| (kbps) | flag | length (kB) | length (kB) | length (kB) | prob.(%)|
--------------------------------------------------------------------------------------------------
0x00 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
0x2e | 1 | 800 | 0 | 0 | 0 | 0 | 0 |
0x22 | 2 | 700 | 0 | 500 | 700 | 1000 | 10 |
0x24 | 2 | 600 | 0 | 400 | 600 | 750 | 25 |
0x26 | 2 | 500 | 0 | 300 | 500 | 600 | 50 |
0x1a | 3 | 400 | 0 | 250 | 500 | 750 | 10 |
0x1c | 3 | 300 | 0 | 200 | 400 | 600 | 25 |
0x1e | 3 | 200 | 0 | 150 | 300 | 400 | 50 |
0x12 | 4 | 100 | 0 | 150 | 250 | 300 | 10 |
0x14 | 4 | 90 | 0 | 100 | 200 | 250 | 25 |
0x16 | 4 | 80 | 0 | 50 | 100 | 150 | 50 |
0x0a | 5 | 70 | 0 | 10 | 40 | 60 | 10 |
0x0c | 5 | 60 | 0 | 5 | 15 | 25 | 25 |
0x0e | 5 | 50 | 0 | 3 | 10 | 15 | 50 |
--------------------------------------------------------------------------------------------------
Note: For the behaviour table see section 8.1
***** STARTING IBM TC API *****
Creating root qdisc associated with interfaces: eth1 & eth2...
ACCESS: Starting queue(s) discipline(s) on the eth2 interface...
ACCESS: Creating DSMARK qdisc as root with h<strong>and</strong>ler 1:0, rc=0
ACCESS: Creating TCINDEX filter for root to get the AF RIO queue code (000XXX from DSCP), rc=0
ACCESS: Creating child CBQ qdisc with h<strong>and</strong>ler 2:0, rc=0
ACCESS: Creating RECONFIG cbq class 2:62, with 512000 bps, (Bounded, isolated), rc=0
CORE: Starting queue(s) discipline(s) on the eth1 interface...
CORE: Creating root CBQ qdisc with h<strong>and</strong>ler 1:0, rc=0
CORE: Creating cbq class 1:1, with 104857600 bps, (Not-Bounded, isolated), rc=0
CORE: Created u32 Signaling filter to map AR addr (fe80:0000:0000:0000:02c0:26ff:fea0:b2a0) into class/PHB 2:1, filter h<strong>and</strong>ler 0:1, rc=0
CORE: Created u32 Signaling filter to map AR addr (2001:0720:0410:1003:02c0:26ff:fea0:b2a0) into class/PHB 2:1, filter h<strong>and</strong>ler 0:2, rc=0
CORE: Creating a u32 default filter that drops everything not classified, filter h<strong>and</strong>ler 0:255, rc=0
ACCESS: Adding default (BEST-EFFORT) class (2:63) <strong>and</strong> its filter. Will have 0 kbps...
ACCESS: Creating cbq class 2:63, with 8 bps, Bounded in BW?: 0, rc=0
ACCESS: Creating a u32 default filter that maps not classified traffic to class 2:63, filter h<strong>and</strong>ler 0:255, rc=0
ACCESS: Adding EXPEDITED FORWARDING class (2:1). Will have 800 kbps...
ACCESS: Creating cbq class 2:1, with 819200 bps, Bounded in BW?: 1, rc=0
CEC Deliverable Number D0202 81 / 97

WP2-D0202 Version 1.0 4.6.2003
ACCESS: Created u32 Signaling filter to map AR addr (fe80:0000:0000:0000:02c0:26ff:fea0:ad36) into class/PHB 2:1, filter h<strong>and</strong>ler 0:2, rc=0
ACCESS: Created u32 Signaling filter to map AR addr (2001:0720:0410:1004:02c0:26ff:fea0:ad36) into class/PHB 2:1, filter h<strong>and</strong>ler 0:3, rc=0
ACCESS: Created u32 filter to map the DSCP class 5 into class/PHB 2:1, filter h<strong>and</strong>ler 0:4, result: rc=0
4 ASSURED FORWARDING/INDEPENDENT queue(s) to create:
Adding AF/Independent Class/PHB 2:2, will have a BW: 1800 kbps...
ACCESS: Creating cbq class 2:2, with 1843200 bps, Bounded in BW?: 1, rc=0
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:2, h<strong>and</strong>ler 3:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 4 into class/PHB 2:2, filter h<strong>and</strong>ler 0:5, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:2 <strong>and</strong> GRED qdisc 3:0, min: 500 kB, max: 700 kB, limit: 1000, prob: 10 %, rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:2 <strong>and</strong> GRED qdisc 3:0, min: 400 kB, max: 600 kB, limit: 750, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:2 <strong>and</strong> GRED qdisc 3:0, min: 300 kB, max: 500 kB, limit: 600, prob: 50 %, rc=0
Adding AF/Independent Class/PHB 2:3, will have a BW: 900 kbps...
ACCESS: Creating cbq class 2:3, with 921600 bps, Bounded in BW?: 1, rc=0
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:3, h<strong>and</strong>ler 4:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 3 into class/PHB 2:3, filter h<strong>and</strong>ler 0:6, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:3 <strong>and</strong> GRED qdisc 4:0, min: 250 kB, max: 500 kB, limit: 750, prob: 10 %, rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:3 <strong>and</strong> GRED qdisc 4:0, min: 200 kB, max: 400 kB, limit: 600, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:3 <strong>and</strong> GRED qdisc 4:0, min: 150 kB, max: 300 kB, limit: 400, prob: 50 %, rc=0
Adding AF/Independent Class/PHB 2:4, will have a BW: 270 kbps...
ACCESS: Creating cbq class 2:4, with 276480 bps, Bounded in BW?: 1, rc=0
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:4, h<strong>and</strong>ler 5:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 2 into class/PHB 2:4, filter h<strong>and</strong>ler 0:7, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:4 <strong>and</strong> GRED qdisc 5:0, min: 150 kB, max: 250 kB, limit: 300, prob: 10 %, rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:4 <strong>and</strong> GRED qdisc 5:0, min: 100 kB, max: 200 kB, limit: 250, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:4 <strong>and</strong> GRED qdisc 5:0, min: 50 kB, max: 100 kB, limit: 150, prob: 50 %, rc=0
Adding AF/Independent Class/PHB 2:5, will have a BW: 180 kbps...
ACCESS: Creating cbq class 2:5, with 184320 bps, Bounded in BW?: 1, rc=0
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:5, h<strong>and</strong>ler 6:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 1 into class/PHB 2:5, filter h<strong>and</strong>ler 0:8, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:5 <strong>and</strong> GRED qdisc 6:0, min: 10 kB, max: 40 kB, limit: 60, prob: 10 %, rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:5 <strong>and</strong> GRED qdisc 6:0, min: 5 kB, max: 15 kB, limit: 25, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:5 <strong>and</strong> GRED qdisc 6:0, min: 3 kB, max: 10 kB, limit: 15, prob: 50 %, rc=0
------------------------------------------------------------------------------------
** TCAPI QUEUES READY!!... Sending to BB a CONFIGURATION REPORT COMPLETED message **
------------------------------------------------------------------------------------
ACCESS: Obtaining Stats from all the qDisc... (Previous netlink_dump errors are normal), rc = 0
The shared memory segment for capture table is OK. Waiting for captures...
9.2 Access Router Resource allocation
*---------------------------------------------
Sending petition to BB for install a filter.
CEC Deliverable Number D0202 82 / 97

WP2-D0202 Version 1.0 4.6.2003
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 1 (install traffic filter)
Adding filter
H<strong>and</strong>le: 1
Tocken Bucket policer rate: 90 kbps
Tocken Bucket policer burst: 1514 Bytes
CORE: Created u32 filter to map IPv6 source <strong>and</strong> destination addresses <strong>and</strong> DSCP into class/PHB 1:1, filter h<strong>and</strong>ler 0:3,
result: rc=0
With Tocken-Bucket Policer: 92160 bps, burst: 1514 bytes
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
9.3 Access Router queues state report
**** ACCESS: Obtaining Stats from all the qDisc... (Previous netlink_dump errors are normal), rc = 0
T_dif: 20 *** Number: 0, ACCOUNT=> Average BW: 82 (kbps), Packets ps: 10, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 1, ACCOUNT=> Average BW: 82 (kbps), Packets ps: 10, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 2, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 3, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
**---------------------------------------------
CEC Deliverable Number D0202 83 / 97

WP2-D0202 Version 1.0 4.6.2003
9.4 Access Router mobility signaling messages
9.4.1 Old Access Router
Read from FHO-module 52 bytes
Received START_QOS_FHO message!!!
The old CoA is:
2001:720:410:1006:204:e2ff:fe2a:460c
The new CoA is:
2001:720:410:1007:204:e2ff:fe2a:460c
The new AR is:
2001:720:410:1007:204:e2ff:fe08:c8c
Sending FHO report to QoS Broker!!!
9.4.2 New Access Router
Read from FHO-module 52 bytes
Received START_QOSB_LISTEN!!!
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=0
Received a CONTEXT object
Received a DECISION FLAGS object
UNSOLICITED FHO DECISION RECEIVED O.K.
Installing FHO connection number 1 ...
CoA IPv6 address= 2001:720:410:1007:204:e2ff:fe2a:460c
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x00
Adding filter
H<strong>and</strong>le: 1
Tocken Bucket policer rate: 50 kbps
Tocken Bucket policer burst: 1514 Bytes
CEC Deliverable Number D0202 84 / 97

WP2-D0202 Version 1.0 4.6.2003
CORE: Created u32 filter to map IPv6 source <strong>and</strong> destination addresses <strong>and</strong> DSCP into class/PHB 1:1, filter h<strong>and</strong>ler 0:4,
result: rc=0
With Tocken-Bucket Policer: 51200 bps, burst: 1514 bytes
Sending a 1 code in a R.A. <strong>Report</strong> message to the QoS Broker...
---------------------------------------------
sending QOS_FHO_ACK to the FHO-module (value QOS_AVAILABLE)
---------------------------------------------
9.5 Access Router timeout connection deletion
Filter 1 NO LONGER VALID. Deleting Filter!.
Sending a Delete Request State...
Deleted the u32 filter with h<strong>and</strong>le 0:4, in discipline: 1:0, result: rc=0
9.6 Access Router Connection check dialogue
---------------------------------------------
Sending KEEP ALIVE message.
KEEP ALIVE message received
9.7 Access Router closing COPS connection
CAPTURED 'Ctrl-C' signal. CLOSING CLIENT. Sending CLIENT-CLOSE message to the BB.
Closing connetion with server...
Cleaning all the root QDISC on the interface eth1, rc=0
Cleaning all the root QDISC on the interface eth2, rc=0
Debug: logger destroyed
Closing client...
9.8 Denying access to a non-authorized traffic test
CEC Deliverable Number D0202 85 / 97

WP2-D0202 Version 1.0 4.6.2003
pulga:~/mobydick/QoS Manager/programs/> sudo ./router garrapata.ipv6 eth1 -d
************************************************************************************
**** IPv6 QoS/Policing ACCESS ROUTER [MobyDick] (COPS CLIENT, 2 interfaces) ****
************************************************************************************
- Debug mode enabled.
Core Interface speed: 104857600 bps
Access Interface speed: 104857600 bps
Debug: logger created
Reading file /proc/net/if_inet6...
-------------------------------------------------------------
Address: 00000000000000000000000000000001, interface: lo
Address: fe8000000000000002c026fffea0b2a0, interface: eth1
Address: fe8000000000000002c026fffe10217c, interface: eth0
Address: fe8000000000000002c026fffea0ad36, interface: eth2
Address: 200107200410100402c026fffea0ad36, interface: eth2
Address: 200107200410100302c026fffea0b2a0, interface: eth1
-------------------------------------------------------------
Opening connection with: garrapata.ipv6.it.uc3m.es (2001:720:410:1003:204:75ff:fe7b:943e)
---------------------------------------------
Sending CLIENT OPEN message to server
Message from QoS Broker
CLIENT ACCEPT message received
Received a KEEP-ALIVE object
Received an AcctTimer object
KATimer value: 120, AcctTimer value: 20
Sending a CONFIGURATION REQUEST message to server
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=0
Received a CONTEXT object
CEC Deliverable Number D0202 86 / 97

WP2-D0202 Version 1.0 4.6.2003
Received a DECISION FLAGS object
CONFIGURATION DECISION RECEIVED O.K.
--------------------------------------------
BEHAVIOUR TABLE received:
DSCP | Agre. | B<strong>and</strong>width | BW Borrow | RIO min queue | RIO max queue | RIO limit queue| RIO drop|
| Number| (kbps) | flag | length (kB) | length (kB) | length (kB) | prob.(%)|
--------------------------------------------------------------------------------------------------
0x00 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
0x2e | 1 | 800 | 0 | 0 | 0 | 0 | 0 |
0x22 | 2 | 700 | 0 | 500 | 700 | 1000 | 10 |
0x24 | 2 | 600 | 0 | 400 | 600 | 750 | 25 |
0x26 | 2 | 500 | 0 | 300 | 500 | 600 | 50 |
0x1a | 3 | 400 | 0 | 250 | 500 | 750 | 10 |
0x1c | 3 | 300 | 0 | 200 | 400 | 600 | 25 |
0x1e | 3 | 200 | 0 | 150 | 300 | 400 | 50 |
0x12 | 4 | 100 | 0 | 150 | 250 | 300 | 10 |
0x14 | 4 | 90 | 0 | 100 | 200 | 250 | 25 |
0x16 | 4 | 80 | 0 | 50 | 100 | 150 | 50 |
0x0a | 5 | 70 | 0 | 10 | 40 | 60 | 10 |
0x0c | 5 | 60 | 0 | 5 | 15 | 25 | 25 |
0x0e | 5 | 50 | 0 | 3 | 10 | 15 | 50 |
--------------------------------------------------------------------------------------------------
Note: For the behaviour table see section 8.1
***** STARTING IBM TC API *****
Creating root qdisc associated with interfaces: eth1 & eth2...
ACCESS: Starting queue(s) discipline(s) on the eth2 interface...
ACCESS: Creating DSMARK qdisc as root with h<strong>and</strong>ler 1:0, rc=0
ACCESS: Creating TCINDEX filter for root to get the AF RIO queue code (000XXX from DSCP), rc=0
ACCESS: Creating child CBQ qdisc with h<strong>and</strong>ler 2:0, rc=0
ACCESS: Creating RECONFIG cbq class 2:62, with 512000 bps, (Bounded, isolated), rc=0
CORE: Starting queue(s) discipline(s) on the eth1 interface...
CORE: Creating root CBQ qdisc with h<strong>and</strong>ler 1:0, rc=0
CEC Deliverable Number D0202 87 / 97

WP2-D0202 Version 1.0 4.6.2003
CORE: Creating cbq class 1:1, with 104857600 bps, (Not-Bounded, isolated), rc=0
CORE: Created u32 Signaling filter to map AR addr (fe80:0000:0000:0000:02c0:26ff:fea0:b2a0) into class/PHB 2:1, filter
h<strong>and</strong>ler 0:1, rc=0
CORE: Created u32 Signaling filter to map AR addr (2001:0720:0410:1003:02c0:26ff:fea0:b2a0) into class/PHB 2:1, filter
h<strong>and</strong>ler 0:2, rc=0
CORE: Creating a u32 default filter that drops everything not classified, filter h<strong>and</strong>ler 0:255, rc=0
ACCESS: Adding default (BEST-EFFORT) class (2:63) <strong>and</strong> its filter. Will have 0 kbps...
ACCESS: Creating cbq class 2:63, with 8 bps, Bounded in BW?: 0, rc=0
ACCESS: Creating a u32 default filter that maps not classified traffic to class 2:63, filter h<strong>and</strong>ler 0:255, rc=0
ACCESS: Adding EXPEDITED FORWARDING class (2:1). Will have 800 kbps...
ACCESS: Creating cbq class 2:1, with 819200 bps, Bounded in BW?: 1, rc=0
ACCESS: Created u32 Signaling filter to map AR addr (fe80:0000:0000:0000:02c0:26ff:fea0:ad36) into class/PHB 2:1,
filter h<strong>and</strong>ler 0:2, rc=0
ACCESS: Created u32 Signaling filter to map AR addr (2001:0720:0410:1004:02c0:26ff:fea0:ad36) into class/PHB 2:1,
filter h<strong>and</strong>ler 0:3, rc=0
ACCESS: Created u32 filter to map the DSCP class 5 into class/PHB 2:1, filter h<strong>and</strong>ler 0:4, result: rc=0
4 ASSURED FORWARDING/INDEPENDENT queue(s) to create:
Adding AF/Independent Class/PHB 2:2, will have a BW: 1800 kbps...
ACCESS: Creating cbq class 2:2, with 1843200 bps, Bounded in BW?: 1, rc=0
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:2, h<strong>and</strong>ler 3:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 4 into class/PHB 2:2, filter h<strong>and</strong>ler 0:5, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:2 <strong>and</strong> GRED qdisc 3:0, min: 500 kB, max: 700 kB, limit: 1000, prob: 10 %,
rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:2 <strong>and</strong> GRED qdisc 3:0, min: 400 kB, max: 600 kB, limit: 750, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:2 <strong>and</strong> GRED qdisc 3:0, min: 300 kB, max: 500 kB, limit: 600, prob: 50 %, rc=0
Adding AF/Independent Class/PHB 2:3, will have a BW: 900 kbps...
ACCESS: Creating cbq class 2:3, with 921600 bps, Bounded in BW?: 1, rc=0
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:3, h<strong>and</strong>ler 4:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 3 into class/PHB 2:3, filter h<strong>and</strong>ler 0:6, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:3 <strong>and</strong> GRED qdisc 4:0, min: 250 kB, max: 500 kB, limit: 750, prob: 10 %, rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:3 <strong>and</strong> GRED qdisc 4:0, min: 200 kB, max: 400 kB, limit: 600, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:3 <strong>and</strong> GRED qdisc 4:0, min: 150 kB, max: 300 kB, limit: 400, prob: 50 %, rc=0
Adding AF/Independent Class/PHB 2:4, will have a BW: 270 kbps...
ACCESS: Creating cbq class 2:4, with 276480 bps, Bounded in BW?: 1, rc=0
CEC Deliverable Number D0202 88 / 97

WP2-D0202 Version 1.0 4.6.2003
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:4, h<strong>and</strong>ler 5:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 2 into class/PHB 2:4, filter h<strong>and</strong>ler 0:7, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:4 <strong>and</strong> GRED qdisc 5:0, min: 150 kB, max: 250 kB, limit: 300, prob: 10 %, rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:4 <strong>and</strong> GRED qdisc 5:0, min: 100 kB, max: 200 kB, limit: 250, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:4 <strong>and</strong> GRED qdisc 5:0, min: 50 kB, max: 100 kB, limit: 150, prob: 50 %, rc=0
Adding AF/Independent Class/PHB 2:5, will have a BW: 180 kbps...
ACCESS: Creating cbq class 2:5, with 184320 bps, Bounded in BW?: 1, rc=0
ACCESS: Creating RIO (GRED) qdisc as child of CBQ class 2:5, h<strong>and</strong>ler 6:0, rc=0
ACCESS: Created u32 filter to map the DSCP class 1 into class/PHB 2:5, filter h<strong>and</strong>ler 0:8, result: rc=0
ACCESS: Creating VQ 2, in CBQ class: 2:5 <strong>and</strong> GRED qdisc 6:0, min: 10 kB, max: 40 kB, limit: 60, prob: 10 %, rc=0
ACCESS: Creating VQ 4, in CBQ class: 2:5 <strong>and</strong> GRED qdisc 6:0, min: 5 kB, max: 15 kB, limit: 25, prob: 25 %, rc=0
ACCESS: Creating VQ 6, in CBQ class: 2:5 <strong>and</strong> GRED qdisc 6:0, min: 3 kB, max: 10 kB, limit: 15, prob: 50 %, rc=0
------------------------------------------------------------------------------------
** TCAPI QUEUES READY!!... Sending to BB a CONFIGURATION REPORT COMPLETED message **
------------------------------------------------------------------------------------
ACCESS: Obtaining Stats from all the qDisc... (Previous netlink_dump errors are normal), rc = 0
Previous netlink_talk errors are normal, going on...
The shared memory segment for capture table is OK. Waiting for captures...
**---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
*---------------------------------------------
Sending petition to BB for install a filter.
CEC Deliverable Number D0202 89 / 97

WP2-D0202 Version 1.0 4.6.2003
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
* ACCESS: Obtaining Stats from all the qDisc... (Previous netlink_dump errors are normal), rc = 0
Previous netlink_talk errors are normal, going on...
T_dif: 20 *** Number: 0, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 1, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 2, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 3, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
CEC Deliverable Number D0202 90 / 97

WP2-D0202 Version 1.0 4.6.2003
---------------------------------------------
*---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
*---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
*---------------------------------------------
Sending petition to BB for install a filter.
CEC Deliverable Number D0202 91 / 97

WP2-D0202 Version 1.0 4.6.2003
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
* ACCESS: Obtaining Stats from all the qDisc... (Previous netlink_dump errors are normal), rc = 0
Previous netlink_talk errors are normal, going on...
T_dif: 20 *** Number: 0, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 1, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 2, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 3, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
CEC Deliverable Number D0202 92 / 97

WP2-D0202 Version 1.0 4.6.2003
---------------------------------------------
*---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
*---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 1 (install traffic filter)
Adding filter
H<strong>and</strong>le: 1
Tocken Bucket policer rate: 90 kbps
Tocken Bucket policer burst: 1514 Bytes
CEC Deliverable Number D0202 93 / 97

WP2-D0202 Version 1.0 4.6.2003
CORE: Created u32 filter to map IPv6 source <strong>and</strong> destination addresses <strong>and</strong> DSCP into class/PHB 1:1, filter h<strong>and</strong>ler 0:3,
result: rc=0
With Tocken-Bucket Policer: 92160 bps, burst: 1514 bytes
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
* Connection already installed, nothing to do..
*---------------------------------------------
Sending filter update request.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 1 (filter update)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
---------------------------------------------
ACCESS: Obtaining Stats from all the qDisc... (Previous netlink_dump errors are normal), rc = 0
Previous netlink_talk errors are normal, going on...
T_dif: 20 *** Number: 0, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 1, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 2, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 3, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
Connection already installed, nothing to do..
* Connection already installed, nothing to do..
*---------------------------------------------
Sending filter update request.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
CEC Deliverable Number D0202 94 / 97

WP2-D0202 Version 1.0 4.6.2003
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 1 (filter update)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
---------------------------------------------
Connection already installed, nothing to do..
* Connection already installed, nothing to do..
*---------------------------------------------
Sending filter update request.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=1
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO updade the filter)
Deleting filter...
Deleted the u32 filter with h<strong>and</strong>le 0:3, in dicipline: 1:0, result: rc=0
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
---------------------------------------------
---------------------------------------------
Sending KEEP ALIVE message.
KEEP-ALIVE message received
---------------------------------------------
ACCESS: Obtaining Stats from all the qDisc... (Previous netlink_dump errors are normal), rc = 0
Previous netlink_talk errors are normal, going on...
T_dif: 20 *** Number: 0, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
CEC Deliverable Number D0202 95 / 97

WP2-D0202 Version 1.0 4.6.2003
T_dif: 20 *** Number: 1, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 2, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
T_dif: 20 *** Number: 3, ACCOUNT=> Average BW: 0 (kbps), Packets ps: 0, Drops ps: 0, Overlimits ps: 0
---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=2
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
*---------------------------------------------
Sending petition to BB for install a filter.
CoA IPv6 address= 2001:720:410:1004:204:75ff:fe7b:9450
Destination IPv6 address= 2001:720:410:1003:204:75ff:fe7b:943e
DSCP= 0x22
Message from QoS Broker
DECISION message received
Received a HANDLE object
H<strong>and</strong>le=2
Received a CONTEXT object
Received a DECISION FLAGS object
Received Flag: 0
Received comm<strong>and</strong>: 2 (NO install filter)
Sending a Success R.A. <strong>Report</strong> message to the QoS Broker...
Debug: SvcAuth record inserted
---------------------------------------------
CEC Deliverable Number D0202 96 / 97

WP2-D0202 Version 1.0 4.6.2003
CAPTURED 'Ctrl-C' signal. CLOSING CLIENT. Sending CLIENT-CLOSE message to the BB.
Closing connetion with server...
Cleaning all the root QDISC on the interface eth1, rc=0
Previous netlink_talk errors are normal, going on...
Cleaning all the root QDISC on the interface eth2, rc=0
Previous netlink_talk errors are normal, going on...
Debug: logger destroyed
Closing client...
CEC Deliverable Number D0202 97 / 97