Admission Control Function for
Telecommunication Networks
Ricardo Alexandre Monteiro Silva Bandeira
Dissertação para obtenção do Grau de Mestre em
Engenharia de Redes de Comunicações
Júri
Presidente: Profª Teresa Maria Vazão
Orientador: Prof. Rui Manuel Rocha
Vogais: Prof. Mário Serafim Nunes
Eng. João Pedro Sousa
Outubro 2007
Aos meus Pais, Irmão, Família e Amigos por todo o
Apoio e Dedicação ao longo desta caminhada.
Às minhas Princesas (Tânia e Lara) por todo o Amor que me deram
e pela Paciência nos momentos de stress e ausência.
Agradecimentos aos meus Orientadores
(Prof. Rui Rocha, Eng. João Pedro Sousa e Eng. Gonçalo Pereira),
Um Grande Abraço em forma de agradecimento por toda ajuda e dedicação prestadas.
Abstract
The goal of the present work is to study, design and implement an Admission Control Architecture
capable of receiving requests to establish new service flows (e.g. VoIP, VoD) in a
telecommunications network, evaluate resources availability to ensure the target quality of service
level and to admit or deny the establishment of the referred flows, performing the appropriate
network nodes’ configurations. The Admission Control functionality depends on the network
technologies, the service properties, the procedure used for verifying resource availability and the
node types.
In order to accomplish this goal a model was defined based on the corresponding standard
models, which covers this Admission Control area. As such, a new architecture that fulfils the
functional requirements of the referred model was proposed. This architecture is splitted into
three independent tiers: the Service tier representing the component that manages the type of
services supported by the network; the QoS tier comprising the components responsible for
providing admission control in the network, being the heart of this architecture and known as the
Network Admission Controller (NAC); the Network tier including all network components where
services are handled and where the resources have to be managed.
The validation of the proposed Admission Control solution entailed the implementation of a
prototype composed by: a SIP SoftSwitch, the NAC, and the corresponding communication
interfaces. The SoftSwitch corresponds to the model’s Application Functions (AF) and is
responsible for managing VoIP calls. The NAC features two main modules, RCF and PDF, which
are responsible for providing admission control functionality. The communication interface
between NAC and AF was implemented with the help of a Diameter Protocol module, which
provided Authorization Control.
Real network elements were used to build a testbed with 2 DSLAMs, 3 Switches, 1 BRAS and 2
ADSL modems. These components are the points where admission control decisions are
enforced.
The testbed was used to perform functional validation of the architecture, as well as get basic
performance measurements. In validation tests, the principal features as call control with success
and rejection of a call due to unavailable resources, were tested. As for performance evaluation,
the NAC dimensioning and throughputs were tested. The obtained results led to the conclusion
that NAC can sustain throughputs of 10 clients/min, and support a number of simultaneously
clients in the order of tens of thousands.
I
Table of Contents
Abstract..................................................................................................................I
Table of Contents..................................................................................................II
List of Figures ...................................................................................................... V
List of Tables....................................................................................................... VI
List of Abbreviations........................................................................................... VII
1 Introduction ........................................................................................................1
1.1 Motivation and Goals.................................................................................................... 2
1.2 Outline ........................................................................................................................... 2
2 State-of-the-art ...................................................................................................4
2.1 General Overview ......................................................................................................... 4
2.1.1 Service Domain...................................................................................................... 5
2.1.2 Network Domain.................................................................................................... 5
2.1.2 QoS Request initiation and negotiation scenario................................................. 7
2.2 3GPP Model .................................................................................................................. 8
2.3 ITU-T Model ................................................................................................................. 9
2.4 Packet Cable Model .................................................................................................... 10
2.5 Multi-Service Forum Model....................................................................................... 11
3 Admission Control Model and Architecture ......................................................13
3.1 Admission Control Model .......................................................................................... 13
3.1.1 Service Tier .......................................................................................................... 14
3.1.2 QoS Tier ............................................................................................................... 14
3.1.3 Network Tier........................................................................................................ 16
3.1.4 QoS Management Functions in fixed Access Networks ................................... 17
3.1.5 Resource Reservation Mechanism...................................................................... 17
3.2 ACM and NAC Architecture...................................................................................... 18
3.2.1 End to End QoS Procedure.................................................................................. 19
3.2.2 NAC Architecture ................................................................................................ 20
3.2.3 Architecture Functional Elements ...................................................................... 21
3.2.3.1 Application Function ........................................................................................ 21
3.2.3.2 Policy Decision Function (PDF)...................................................................... 22
3.2.3.2.1 Install Policies .................................................................................... 23
3.2.3.3 Resource Control Function (RCF)................................................................... 24
3.2.3.3.1 Admission control process.............................................................. 24
3.2.3.4 DSLAM ............................................................................................................. 25
3.2.3.5 BRAS................................................................................................................. 26
3.2.3.6 NASS ................................................................................................................. 27
3.2.4 Architecture Interfaces ........................................................................................ 28
3.2.4.1 Rq Internal Interface (PDF – RCF) ................................................................. 28
3.2.4.2 NR Interface (PDF – AF) ................................................................................. 28
3.2.4.3 SI Infernal Interface (RFC – NASS) ............................................................... 29
3.2.4.4 TC Interface (PDF – BRAS)............................................................................ 29
3.2.4.5 NC Interface (RCF– DSLAM)......................................................................... 29
3.2.5 NAC Interaction Procedures ............................................................................... 30
II
3.2.5.1 Request Resource ..................................................................................... 30
3.2.5.2 Release Resource...................................................................................... 32
3.2.5.3 Resource Modification Request .............................................................. 33
4 Architecture Implementation ............................................................................35
4.1 Architecture implementation overview ..................................................................... 35
4.2 Functional Elements Implementation ........................................................................ 37
4.2.1 Application Function ........................................................................................... 37
4.2.1.1 External Call Control Capability ..................................................................... 37
4.2.1.2 Triggers and trigger processing ....................................................................... 39
4.2.1.2.1 Trigger Processing................................................................................. 43
4.2.1.2.2 Trigger configuration ............................................................................ 44
4.2.1.3 Admission Control feature ............................................................................... 45
4.2.2 Policy Decision Function .................................................................................... 47
4.2.3 Resource Control Function.................................................................................. 49
4.3 Interfaces implementation .......................................................................................... 52
4.3.1 NR Interface (PDF - AF)..................................................................................... 52
4.3.2 TC Interface (PDF - BRAS)................................................................................ 53
4.3.3 NC Interface (RFC - DSLAM) ........................................................................... 54
5 Application Scenario ........................................................................................55
5.1- Network General Description ................................................................................... 55
5.2 – Network Equipment Description ............................................................................ 57
5.2.1 – DSLAM ............................................................................................................. 57
5.2.2 – Switch ................................................................................................................ 59
5.2.3 BRAS.................................................................................................................... 61
5.2.4 ADSL Modem...................................................................................................... 62
6 Tests and Results ............................................................................................63
6.1 Validation Tests Specifications and Results.............................................................. 63
6.1.1 Request Resource................................................................................................. 63
6.1.2 Release Resource ................................................................................................. 65
6.1.3 Policies Enforcement........................................................................................... 65
6.2 Performance Tests Specification and Results ........................................................... 66
6.2.1 NAC Dimensioning Test ..................................................................................... 66
6.2.1.1 Memory Usage and Clients Max Number .............................................. 66
6.2.1.2 Throughputs .............................................................................................. 67
7. Conclusions ....................................................................................................69
ANNEX 1 - VoIP..................................................................................................71
ANNEX 2 - VoD ..................................................................................................74
ANNEX 3 - SIP....................................................................................................75
ANNEX 4 - RTP ..................................................................................................78
ANNEX 5 - RSTP................................................................................................80
ANNEX 6 - IP ......................................................................................................82
ANNEX 7 - Ethernet............................................................................................83
ANNEX 8 - VLAN ................................................................................................86
ANNEX 9 - XDSL ................................................................................................88
ANNEX 10 - Resource Reservation Request Information ...................................89
ANNEX 11 - Resource Modification Request Information ...................................90
III
ANNEX 12 - Resource Release and Abort Request Information ........................91
ANNEX 13 - PolicyDecisionFunction UML ..........................................................92
ANNEX 14 - Session UML ..................................................................................93
ANNEX 15 - Resource Control Function UML ....................................................94
ANNEX 16 - Link Edge UML ...............................................................................95
ANNEX 17 - Network Graph UML.......................................................................95
ANNEX 18 - NE Vertex UML...............................................................................95
ANNEX 19 - Association UML.............................................................................96
ANNEX 20 - BRAS UML .....................................................................................96
ANNEX 21 - DSLAM UML...................................................................................97
ANNEX 22 - EthBRAS UML................................................................................97
ANNEX 23 - EthPort UML ...................................................................................98
ANNEX 24 - Link UML ........................................................................................98
ANNEX 25 - Switch UML ....................................................................................99
ANNEX 26 - Traffic Classifier UML .....................................................................99
ANNEX 27 - XdslPort........................................................................................100
ANNEX 28 - DOM UML.....................................................................................101
ANNEX 29 - NASS.xml .....................................................................................102
ANNEX 30 - Physical-Logic_Model.xml ............................................................103
ANNEX 31 - Request Resource........................................................................110
ANNEX 32 - Release Resource Test ................................................................112
ANNEX 33 - Policies Enforcement Test............................................................114
References........................................................................................................115
IV
List of Figures
Figure 2.1 – ETSI-TISPAN Model …………………………………………………………………..
5
Figure 2.2 – ETSI-TISPAN Model detailed …………………………………………………………
6
Figure2.3 – The Flow Diagram for QoS request initiation ……………………………………….
7
Figure 2.4 – The 3GPP Model ……………………………………………………………………….
8
Figure 2.5 – The ITU-T Model ……………………………………………………………………….
9
Figure 2.6 – The Packet Cable Architecture ……………………………………………………….
10
Figure 2.7 – The MSF Architecture …………………………………………………………………
11
Figure 3.1 – The Admission Control Model ………………………………………………………...
14
Figure 3.2 – Admission Control Model ……………………………………………………………...
18
Figure 3.3 – The Flow Diagram for end-to-end QoS ……………………………………………...
19
Figure 3.4 – NAC Architecture ………………………………………………………………………
20
Figure 3.5 – Subscriber Attaches Procedure ………………………………………………………
27
Figure 3.6 – Resource Request Procedure ………………………………………………………..
30
Figure 3.7 – Resource Release Procedure ………………………………………………………...
32
Figure 3.8 - -Resource Modification Procedure……………………………………………………
33
Figure4.1 – Implementation Blocks Diagram ……………………………………………………...
37
Figure 4.2 – Trigger Types diagram ………………………………………………………………...
42
Figure 4.3 – Terminate Call Trigger Diagram ……………………………………………………...
43
Figure 4.4 – Trigger Configuration …………………………………………………………………..
45
Figure4.5 – Admission Control Feature Assigned ………………………………………………..
48
Figure 4.6 – Openblox package ……………………………………………………………………..
54
Figure 5.1 – Network Topology ……………………………………………………………………...
57
Figure 5.2 – DSLAM System Architecture ………………………………………………………….
59
Figure 5.3 – Switch System Architecture …………………………………………………………..
61
Figure 5.4 – XDSL Aggregation with the ERX System …………………………………………..
62
Figure 6.1 – Call Accepted…………………………………………………………………………….
65
Figure 6.2 – Call Rejected……………………………………………………………………………..
65
Figure 6.3 – Memory Usage Graph ………………………………………………………………….
67
Figure 6.4 – Timing between NAC and SoftSwitch ……………………………………………….
69
V
List of Tables
Table 4.1 – Functions of Policy Decision Function class ……………………………………
49
Table 4.2 – Functions of Telnet Session class …………………………………………………
50
Table 4.3 – Functions of Resource Control Function class …………………………………
52
VI
List of Abbreviations
3GPP - 3rd Generation Partnership Project
ACM – Admission Control Model
ADSL – Asynchronous Digital Subscriber Line
AF – Application Function
AN – Access Node
A-RCF – Access Resource Control Function
ATM – Asynchronous Transfer Mode
BGF – Border Gateway Function
BGN – Border Gateway Node
BRAS – Broadband Remote Access Server
CAC – Connection Admission Control
C-BGF – Core Border Gateway Function
COPS – Common Open Policy Service Protocol
CPE – Customers Premises Equipment
DSLAM – Digital Subscriber Line Access Multiplexer
ETSI – European Telecommunications Standards Institute
IP – Internet Protocol
ITU-T – International Telecommunication Union
MPLS – Multiple Protocol Label Switching
MSF – Multi-Service Forum
NAC – Network Admission Controller
NASS – Network Attachment Sub-System
NAT – Network Address Translation
NC – Network Controller
NGN – Next Generation Networks
NR – Network Requester
PDF – Policy Decision Function
QoS – Quality of Service
RACF – Resource Admission Control Function
RACS – Resource Admission Control Sub-System
RCF – Resource Control Function
RSTP – Real-Time Streaming Protocol
RTP – Real-Time Protocol
SCP – Service Control Point
VII
SDP – Session Description Protocol
SF – Service Functions
SI – Subscribers Interface
SIP – Session Initiation Protocol
SPDF – Service Policy Decision Function
SSP – Service Switching Point
STP – Spanning Tree Protocol
TC – Traffic Conditioning
VLAN – Virtual LAN
VoD – Video on Demand
VoIP – Voice over IP
VIII
1 Introduction
In today’s Telecommunications Networks the fixed-mobile network convergence is not a mirage
of the future but a reality of our days. Network operators are already deploying Next Generation
Networks (NGNs) and multi-service access networks that support real-time services like VoIP and
VoD.
In parallel, the activity level is high in forums and standardization bodies in order to define
standard architectures with the major objectives of increased speed to market for new
applications and services, uniform interfacing between application functions and network
functions.
The demand from NGNs is driving the industry towards the converged network architecture with
open interfaces and standard protocols. A key function in this architecture is the uniform end-toend service and bandwidth control. This function is commonly known as Bandwidth Manager,
QoS Manager, Network Resource Controller, etc. In this work we use the term Network
Admission Controller (NAC). We define the network admission control plane located between
application functions and the network elements. It provides unified interfaces, policy control,
admission control and support for network provisioning.
The Admission control is a network Quality of Service (QoS) technique responsible for
determining bandwidth allocation for streams with various requirements. An application that wants
to stream the flow of a new session into a network have to request a connection, which involves
informing the network about the characteristics of that traffic flow and the QoS level required. This
information has to be sent to the Network Admission Controller which have the network
provisioning and decides if was enough resources available to that connection. Then either
accepts or rejects the connection request, the policy control is used to enforce the admission
decision.
1
1.1 Motivation and Goals
The types of services (essentially VoIP and VoD) in NGNs are pretty demanding as they are
transmitted in real-time. These services are commonly supported by a packet network (IP in this
case). The principal motivation for considering Admission Control in such networks relates with
the need to cope with the sharing of the same link by a certain number of connections (e.g. VoIP
conversations or VoD sessions), while an even larger number of connections causes significant
degradation in all connections making them all useless.
The design of an appropriate model and the definition of a corresponding architecture are
important milestones for achieving cost-effective admission control solutions suitable for being
used in an access network of any telecommunications operator.
In this work is proposed a model design and corresponding architecture, which gives the
possibility to control the new sessions admission, in an access network with many real-time
services.
The goal of this work is the architecture validation and the attainment of performance results,
which gives the possibility to characterize the architecture as a valid solution to guarantee QoS in
packet networks.
1.2 Outline
This work is organized in 7 chapters. Chapter 2 deals with the state-of-the-art, which analyses
the standardisations activities being carried out in this area, namely in the scope of ITU-T, 3GPP,
Packet cable, Multi-service forum and ETSI-TISPAN.
Chapter 3 is devoted to the design of the model developed in the scope of this work, starting with
a general overview of the model and a typical end-to-end procedure. In chapter next sections we
explained the proposed architecture and the interaction procedures between architecture
elements.
Chapter 4 is devoted to the implementation of the architecture, which describes the
implementation blocks diagram and a detailed implementation of each element in the
architecture.
2
Chapter 5 deals with the Application Scenario which explains the test bed prepared to test the
architecture proposed in this work.
Chapter 6 is dedicated to validation tests and performance results, which validates the
architecture implemented and shows the performance of this solution when acting on a real
network.
Chapter 7 is dedicated to final conclusions and future work, which could be added to improve this
solution.
3
2 State-of-the-art
Network operators are already deploying next generation networks and multi-service access
networks using available solutions, namely VoIP, VoD and IpTv. In parallel, the activity level is
high in forums and standardisation bodies on defining standard models.
The scope of this chapter is to provide an overview of the resource and admission control models
with respect to forums and standardisation bodies.
2.1 General Overview
Generally, the most recognized standardisation bodies and forums in the telecommunications
world (ITU, 3GPP, ETSI, etc) had already started defining models which will provide QoS
guarantees in NGNs. There are some different techniques that can be used to enforce QoS in a
telecommunication network.
A technique called Resource and Admission Control has the main function of controlling the
service flows that are carried within a network. This type of technique can be based on the above
referred models, which are basically quite identical, although adapted to different network
technologies.
In order to better understand how these types of models are defined, we decided to give a
general explanation of the ETSI-TISPAN [1] standard because it was the starting point for the
architecture designed in the framework of this work. In the next sub-sections we just describe the
differences of the other standards that already have solutions in this area.
Usually, all the models are separated in two domains and normally composed by 3 principal
blocks. In figure 2.1, the Service and the Network Domains are represented. The first one is
composed by a block called Service Functions (SF) which includes the elements responsible for
controlling the establishment of new session’s corresponding to a certain service type. The
second one is usually composed by two blocks: one responsible to apply resource and admission
control on the network, called Resource and Admission Control Sub-System (RACS), and the
other that is being controlled and where the admission decisions are enforced, called Transport
Functions.
4
This separation into domains ensures an easy development split and maintenance. Those
components can evolve in the future, independently.
Service Functions
Service Domain
Network Domain
NASS
CPE
Resource and Admission
Control Sub-System
Transport Functions
Fig. 2.1: ETSI-TISPAN Model
2.1.1 Service Domain
The Service Domain consists of a Service Functions block that includes a functional element
called Application Function (AF), as illustrated in figure 2.2. This element is responsible for
receive the requests from the customer’s equipment in order to establish a new session (e.g. a
new VoIP call), to extract the parameters (source/destination address, bandwidth, etc) associated
to that session and send a resource request to Service Policy Decision Function (SPDF) in order
to control the admission of the respective session. The interaction between these two blocks (AFSPDF) is made through a reference point defined by ETSI and called Gq’.
2.1.2 Network Domain
The Network Domain comprises two different blocks which include some functional elements of
this model. The RACS is a block that includes two functional elements, the Service Policy
Decision Function and Access-Resource Control Function (A-RCF). The SPDF is an element
responsible to make admission control decisions and enforce them in the network. To make the
5
decisions it needs to have the knowledge of available resources in the network. For that it has
help of the other element A-RCF. This element is responsible to control all the resources in the
network. It knows the state of network in real-time. The interaction between these two elements
(SPDF - A-RCF) is made through a reference point called Rq.
The Network Attachment Sub-System (NASS) is an auxiliary element that provides user access
network management and configuration based on user profiles. It provides dynamic provision of
IP address and other user equipment configuration parameters, authentication of user access
network and authorisation of user access network based on user profiles.
The Transport Functions block includes two functional elements, as shown in figure 2.2. The
Core-Border Gateway Function is a packet to packet gateway that performs policy enforcement
functions under control of SPDF. It operates on micro-flows, i.e. on individual flows of packets of
service sessions. The C-BGF’s policy enforcement function is a dynamic gate that can block
individual flows or allow authorised flows to pass. Per admitted micro-flow, the SPDF may instruct
the C-BGF to apply a traffic-conditioning filter (policy) that limits the throughput of the flow to an
admitted level indicated by the SPDF. The reference point between these two elements is Ia.
The Resource Control Enforcement Function (RCEF) is a Layer 2 device that may be IP capable
and performs QoS mechanisms dealing with user traffic directly. It performs both policy
enforcement functions and collect network information functions under control of the A-RACF..
Fig. 2.2: ETSI-TISPAN Model detailed
6
2.1.2 QoS Request initiation and negotiation scenario
This scenario applies when Customers Premises Equipment (CPE) supports the application layer
signalling with QoS extensions. So it can initiate an explicit QoS request through the application
layer signalling (e.g. SDP/SIP). It is responsible to ‘extract’ the QoS requirement parameters from
the user service request, to request authorization from the RACF which control the transport layer
resource admission, reservation and allocation. A flow diagram for this scenario is provided in
figure 2.3.
Service Functions
(2)
(1)
RACS
NASS
(3)
CPE
Transport Functions
Fig. 2.3: The flow diagram for QoS request initiation
(1) The CPE requests an application-specific service by sending a “Service Request” (e.g.
SIP Invite, HTTP Get, etc.) to the SF. This Service Request doesn’t contain any explicit
QoS requirement parameters for this service.
(2) The SF determine the QoS requirement parameters (including bandwidth, delay, jitter,
loss etc.) of the requested service, and then requests authorization from the RACS by
sending a ‘Resource Request’ which contains these explicit QoS requirement
parameters.
(3) The RACS checks authorization based on user profile held in the NASS, on operator
specific policy rules and on resource availability. If admitted, the RACS sends the gate
control, packet marking and traffic control commands to the Transport Functions.
7
2.2 3GPP Model
The 3GPP model [2] is focused on 3G mobile networks and their interconnection over IP
networks. This standard is also composed by three blocks but it is not divided in domains. As
figure 2.4 illustrates, we have the Application Function (AF) which is an element that offers to
applications the possibility to request IP bearer resources, the Policy Decision Function (PDF)
that is responsible to make policy decisions on set-up information obtained from the AF and
authorizes QoS resources for a new session, and the Gateway that maps to previous BGF and is
where the policy decisions are enforced.
GGSN -Gateway GPRS
Support Node
Fig. 2.4: The 3GPP Model
8
2.3 ITU-T Model
The ITU-T Model [3] is similar to the ETSI-TISPAN in the sense they both are focused on QoS
control provisioning in fixed access networks. The ITU standard has other names for the
components but the functions are the same. The difference lies on the fact that this model has
elements to provide interconnection between other networks of the same type, like figure 2.5
illustrates.
The blocks of this model are also composed by functional elements that has the same functions
that the elements previous explained. In this model all the blocks have a new functional element
that is responsible for the interconnection with other networks.
Service Control Functions
Service Domain
NAAF
CPE
Resource and Admission
Control Functions
Other NGNs
Network Domain
Transport Functions
Fig. 2.5: The ITU-T Model
9
2.4 Packet Cable Model
The Packet Cable Model [4] is focused on IP services over cable TV access networks. They have
defined a multi-media architecture for IP multi-service, where the network resource controller is
named Policy Server. It provides admission control and dynamic configuration of gates in the
cable modem terminal system. The functionality of the policy server may range from only
handling user policies to having awareness of network provisioning and providing resource-based
admission control. The Packet Cable Multimedia architecture defines two reference points to the
Policy Server, like figure 2.6 illustrates. The Pkt-mm-3 is a reference point for requesting
bandwidth by the applications and currently defined as a COPS interface. The Pkt-mm-2 is a
reference point for enforcing policies and admission decisions in network elements.
Fig. 2.6: The Packet Cable Architecture
10
2.5 Multi-Service Forum Model
The MSF Model [5] is focused on large scale carrier networks. The architecture is depicted in
figure 2.7, where the network resource controller, as a whole, is named Bandwidth Manager. No
split is made in the architecture between policy control and admission control. The MSF defines
scalable and resilient carrier-grade architecture for deploying multiple bandwidth managers.
Fig. 2.7: The MSF Architecture
Being the most different model of those we have referred until now, it will be further detailed to
enhance its major particularities.
The call agent provides call control functions and interfaces to value added service platforms
such as feature servers and service brokers. It requests bandwidth from the underlying network
based on the information related to the call, such as the end points of the call and the codec’s
required.
The bandwidth manager forms the heart of the MSF QoS solution. It receives reservation
requests from the call agent, identifies and may determine the path through the network for the
call and allocates any resources required in the network. The bandwidth manager keeps track of
available bandwidth, either through tracking resources from a pool or through auditing, and
performs Call Admission Control (CAC) based on this information. Although the bandwidth
manager is shown as a single logical entity in the diagram, within a MSF solution, bandwidth
managers can be highly distributed platforms each of which is responsible for maintaining
resource reservations within a part of the end to end path.
11
The edge node may be a traditional edge router or it may be a layer two access node with some
limited additional classification and traffic marking capabilities. The bandwidth manager may
interface with the edge node to perform per flow pinhole control and or path selection using IF-3.
Pinhole control allows the bandwidth manager to install classifiers and traffic conditioners at the
edge node. This allows packet based flows that require the QoS services of the MSF network to
be identified, by the classifier, policed according to their contract and conditioned to have a
specific forwarding behaviour associated with them. In addition to interface for pinhole control the
MSF QoS architecture also defines IF-4 which enables the bandwidth manager to audit the
provisioned network resources (e.g., MPLS TE tunnels), retrieve alarms, and provision MPLS TE
tunnels through which traffic authorised by the bandwidth manager will flow. This allows an MSF
bandwidth manager to abstract complex core networks to a series of MPLS tunnels which it is
responsible for performing CAC into. These tunnels may be edge to edge through the core
network or alternatively may terminate in the core network, in which case a route is built over the
core network as a concatenation of tunnels.
The core node is a traditional core router. The bandwidth manager may interface with core
routers using IF-4. This is used for auditing the MPLS topology, retrieving alarms and for tunnel
provisioning if there was a requirement to terminate managed tunnels on the core node.
The Session border controllers may be used in voice and multimedia services to handle the case
where Network Address Translation (NAT)has been performed on the media and signalling,
either in the customer premises or at an intermediate network. The MSF QoS solution supports
NAT traversal functions within the edge node under the control of the bandwidth manager and or
call agent, however it does not mandate it and solutions continue to use stand alone Session
Border Controllers.
12
3 Admission Control Model and Architecture
When we talk about an IP over Ethernet network running real-time services, like VoIP and VOD,
we have to think in QoS guarantees. The Admission Control is a technique that ensures Quality
of Service. This technique can only be applied in packet networks like IP over Ethernet for
example, where the bandwidth associated to the subscribers is not permanently reserved.
To better understand the type of services and networks to which the Admission Control is applied,
it is described in the Annex’s 1 to 9 the behaviour of these services, the protocols (e.g.
SIP,SDP,RTP and RSTP) used by them and the network technologies (e.g. IP, Ethernet, VLAN’s,
etc) used in this work.
The goal of this chapter is to design a model and a corresponding architecture that, once
implemented, gives the possibility to control the admission of new sessions of a certain real-time
service in a telecommunication network.
In this chapter the design of an Admission Control Model (ACM) that is based on ETSI-TISPAN
standard, and the corresponding ACM architecture that was implemented and tested in the scope
of this work, will be described. In the architecture description we give a special attention to an
element called Network Admission Controller (NAC) because it is the heart of the architecture
being completely developed from the scratch. The other components and interfaces are opensource package that we reuse and instrument in order to adapt them to our architecture. In the
last section we can understand the interaction procedures between the functional elements.
3.1 Admission Control Model
The Admission Control Model designed in the scope of this work, is based on the ETSI-TISPAN
standard, is focused on fixed access networks and on end-to-end Next Generation Networks
(NGN’s). The model was defined with 3 independent tiers and reference points between them,
like figure 3.1 illustrates. The advantage to have 3 separated tiers is that each one of them can
grow without depending from the others and just have to keep the reference points to guarantee
model’s operation.
13
Fig. 3.1: The Admission Control Model
3.1.1 Service Tier
In the Service Tier are located all the functional elements related to services, responsible to
request resources and admission control for a media flow of a certain type of real-time service.
The Application Functions (AF) is responsible to request to NAC authorization to start a new
service session. When a request to start a new session for a certain service arrives to AF, it has
to create a new resource request and send them to NAC in order to check if the network is ready
to accept another session of this service. The interaction between these two tiers is made through
a reference point called Gq’ and defined in ETSI TISPAN standard [1]. The information
exchanged through this reference point is the identification of media flows and their required QoS
resources (e.g. Bandwidth, priority level).
3.1.2 QoS Tier
In the QoS Tier are the elements responsible to guarantee Quality of Service in the access
network. In this tier we have the principal element called Network Admission Controller and
secondary element called Network Attach Sub-System (NASS).
14
The NAC provides to applications a mechanism to request and reserve resources from the
access network. To achieve this, real-time multi-media services (VoIP, Videoconferencing and
Video on Demand) must be capable of triggering the QoS resource reservation, admission control
and policy control capabilities of the network, which implies that appropriate interfaces must be
defined between the application layer and the network layer of the multi-service bearer
architecture. NAC provides the means for an operator to enforce admission control and set the
respective bearer service policies. It provides the means for value-added services to obtain
network resources that are necessary to offer services to the end-user.
The NAC is resource-reservation session aware but application session agnostic (i.e. it can
support transport resource reservations for both session based and non-session based
applications).
.
Basically, NAC offers the following functionality:
•
Admission Control: NAC implements Admission Control to the access and aggregation
segment of the network. We can have various types of admission control going from a
strict admission control where any overbooking is to be prevented, to admission control
that allows for a certain degree of over subscription or even a trivial admission control
(when the authorization step is considered sufficient to grant access to the service).
•
Resource reservation: NAC implements a resource reservation mechanism that permits
applications to request bearer resources in the access network.
•
Policy Control: The NAC authorises QoS resources and defines polices that are
enforced by the bearer service network elements.
This model performs QoS resource reservation, admission control and policy control for the IPConnectivity Access Network bearer service in order to provide QoS and network capabilities for
the real-time multimedia services. The functions are performed on a per session basis.
The NAC is composed by two different blocks. The Resource Control block that is the element
responsible to collect the information about the network, like available resources and network
topology changes. The Policy Decision block is the other element that is the single point of
contact between the Service Tier and the Network Tier and is responsible to receive requests
from the AF, make the admission control for these requests, notify the AF with the responses and
enforce these decisions into the network.
15
The NASS is a secondary element responsible to provide user access network management and
configuration based on user profiles. It provides dynamic provision of IP address and other user
equipment configuration parameters.
3.1.3 Network Tier
In the Network Tier are the functional elements from which the NAC obtained the information
related with the access network and where the final admission decisions are enforced.
The Access Node (AN) in IP access network connects directly to CPE and terminates the link
signals at the network side. Generally, it is a Layer 2 device that may be IP capable and performs
QoS mechanisms dealing with user traffic directly. It performs both policy enforcement functions
and collect network information functions under control of the NAC. The reference point between
the AN and NAC is Re.
The Border Gateway Node (BGN) is a packet gateway function used to interconnect an
operator’s core network with another operator’s core network supporting the packet-based
services. It performs policy enforcement functions under control of NAC. It operates on microflows, i.e. on individual flows of packets of service sessions. The policy enforcement function is a
dynamic gate that can block individual flows or allow authorised flows to pass. For an admitted
flow the NAC instructs the BGN to open/close its gate for the particular flow.
16
3.1.4 QoS Management Functions in fixed Access Networks
In order to define the NAC architecture it is necessary to identify the possible QoS management
functions in the fixed access networks. Those functions can be categorised according to QoS
control capabilities and business models in the fixed environment.
To ensure QoS aware NGN service delivery, the following two architectures for dynamic QoS
control are considered for NAC:
o
Guaranteed QoS - service delivery with absolute bounds on some or all of the QoS
parameters, such as throughput, bandwidth and jitter. This is achieved by performing
admission control and enforcement of admission control decisions in the access network,
via throughput control and traffic policing
o
Relative QoS - the relative QoS model implies traffic class differentiation (DiffServ) by
means of separate queues dedicated to particular IP traffic classes and by performing
priority scheduling between these queues in the BGN of the access network .The IP QoS
profile defining the DiffServ QoS parameters is dynamically updated in the BGN at
request of the network.
3.1.5 Resource Reservation Mechanism
According to CPE capabilities the following QoS resource reservation mechanisms can be
invoked:
•
Proxied QoS reservation request with policy-push: the CPE does not itself support
native QoS signalling mechanisms. When a CPE invokes a specific service of an AF
using a signalling protocol (e.g. SIP), the AF will issue a request to the NAC for QoS
authorisation (policy control) and resource reservation. NAC ensures that, according the
guaranteed QoS model, the enforcement of admission control decisions, via throughput
control and traffic conditioning, are properly set in the BGN. NAC Policy decisions are
pushed to the policy enforcement function (BGN) in the xDSL access.
•
CPE-request QoS reservation with policy-pull: the CPE is capable of sending QoS
requests over a dedicate signalling in the user plane. BGN is responsible for pulling
police data from NAC using an Authorization Token. This token was obtained by the CPE
via the signalling application and sent in the reservation request to BRAS.
17
3.2 ACM and NAC Architecture
The ACM architecture is composed of five principal elements, as we can see in figure 3.2. They
are the application server (e.g. SoftSwitch or Media Server) that maps to application functions in
the model previous defined. This element is responsible to receive the signalling from the CPE
and to initiate the admission control process extracting the QoS parameters needed for a certain
service and sending them in a resource reservation requests to other element called Network
Admission Controller. This element is the heart of the model because is responsible to receive
resource reservation requests, make final admission decisions and enforce these decisions on
the network elements there are the Digital Subscriber Line Access Multiplexer (DSLAM) that
maps to the Access Node and Broadband Remote Access Server (BRAS) that maps to Border
Gateway Function, both of them previous defined in the model. Even in this architecture we have
other element called Network Attachment Sub-System that is the responsible to provide an
association between Subscriber location/IP address and to notify the NAC when a subscriber
attaches to the network.
Fig 3.2: Admission Control Architecture
18
3.2.1 End to End QoS Procedure
In this section it will be described the scenario that illustrates how CPE, AFs, NAC and BRAS
cooperate to provide QoS in the access network based on Resource and Admission Control.
In this scenario QoS requests are initiated by CPE through the application layer signalling with
QoS negotiation extensions. As the CPE supports the application layer signalling with QoS
negotiation extensions, it can initiate an explicit QoS request through the application layer
signalling (e.g. SDP/SIP). It is the Application Function's (e.g. SoftSwitch or Media Server)
responsibility to ‘extract’ the QoS requirement parameters from the user service request, to
request authorization from the NAC which control the transport layer resource admission,
reservation and allocation.
A flow diagram for this scenario is provided in Figure 3.3.
Fig 3.3: The Flow diagram for end to end QoS
(1) The CPE requests an application-specific service by sending a “Service Request” (e.g.
SIP Invite) to the Application Function. This Service Request contains the explicit QoS
requirement parameter for this service.
(2) The Application Function extracts the QoS requirement parameter (requested bandwidth.)
from the Service Request, and then requests authorization from the NAC by sending a
‘Resource Request’ which contains these explicit QoS requirement parameter.
(3) The NAC checks authorization based on resource availability. If admitted, the NAC sends
the gate control and traffic control commands to the BRAS.
19
3.2.2 NAC Architecture
The Network Admission Controller (NAC), as figure 3.4 illustrates, is composed by two functions
and one internal interface. The first - Policy Decision Function (PDF) - maps to the Policy
Decision block, previously defined, and being responsible for performing the admission decisions
and enforce them into the network. The second function - Resource Control Function (RCF) maps to the Resource Control block and it is responsible for controlling the network resources.
Fig 3.4: The NAC Architecture
NGN encompasses real-time services with Application Functions, which offers services that
require control of IP bearer resources. Examples of an AF are the Media Server in a service like
VoD and a SoftSwitch on VoIP. The AF maps the application layer QoS information, e.g. the
mapping of parameters defined in SDP, into QoS request information to be sent via the Network
Requests (NR) interface to the PDF.
The PDF provides the AF with a single point of contact. It receives the QoS request with the
resources needed for the new flow and then asks RCF if these resources are available in the
network. Then, if the RCF accepts the new request, the PDF is responsible for communicating
this decision to the AF and to enforce it in the BRAS, through the Traffic Conditioning (TC)
interface.
20
The RCF is responsible for controlling the segment’s resources. This element collects the
information about the resources available in the network via the Network Controller (NC)
interface. The RCF receives requests from the PDF and, based on the available resources that
have been previously stored, may accept or reject the new flows for a certain service. The
interaction with NASS to obtain subscribers information is made via the Subscriber Information
(SI) interface.
The DSLAM and the BRAS are the network elements that can interact with the NAC via the NC or
TC interfaces. The DSLAM is located in the access network and the BRAS may be found
between an access network and a core network. The principal services performed in these
elements under the control of the NAC are: Open/close gates, packet marking, policing of traffic
and exclusively in the BRAS resource allocation per flow.
For Resource and admission control the architecture provides a clear separation between layers
that allows an application service to run over different access networks without impacting the
application capabilities as long as the resources are available.
3.2.3 Architecture Functional Elements
In order to better understand the proposed architecture it is important to provide a description of
all the functions and their principal actions.
3.2.3.1 Application Function
The AF is not a stand-alone functional entity of NGN architecture. It is a convenient alias of the
functionality that exists in some Service Control Subsystems and Applications to interact with the
NAC.
The AF is expected to perform the following functionalities:
•
The AF shall provide information to the PDF: to identify media flows, to express the
expected service from the NAC, and the bandwidth that needs to be authorized and
allocated for those flows. Bandwidth requirements shall be complemented with class
based service information indicating service expectations such as QoS characteristics,
which transfer layer resources that should be used.
21
•
The AF shall be capable of issuing reservation modify and release messages that contain
the same reservation information as provided in reservation request. The AF shall further
be capable of updating time limited reservations through reservation modify messages
and through reservation refresh messages.
•
The AF may be capable of operating in such a mode which allows it to request resources
for media flows belonging to a single application session per resource request.
•
The AF may be capable of operating in any or all of the following modes:
-
a single resource reservation request per application session is issued by the AF;
-
multiple independent resource reservation requests per application session are
issued either from a single or multiple AFs, where each independent request is
intended to reserve a different set of resources within the network.
•
The AF is entitled to use Subscriber IP address to identify to NAC the resource being
requested. The decision of what information is provided to NAC depends on the type of
application, but in services like VoD and VoIP the bandwidth required for the service is
extremely needed.
In a service like VoIP using the SIP protocol to initiate a new call we can have a SoftSwitch that
receive the SIP Invite from a SIP client and extracts the Subscriber Information and the QoS
parameters (e.g. bandwidth used in the call) to send them in a QoS request to the PDF.
3.2.3.2 Policy Decision Function (PDF)
The PDF is a logical policy decision element for Service-Based Policy control. Its main functions
are:
- receiving QoS requests from the Application Function;
- sending these requests to the Resource Control Function and waiting for responses;
- performing final decisions, based on those responses, communicating them to the AF,
and enforce them into the network.
The information derived from the requests relates to the traffic characteristics to be requested for
individual media flows, including QoS parameters. These may be used by the PDF to set the
22
appropriate filters or packet marking policies to be applied in the BRAS and/or to describe to the
RCF the resource being requested.
The AF has the capability to send to PDF a resource reservation request with service priority level
assigned. As an example, in case of an emergency session, the AF indicates to PDF that has a
request corresponding to a priority session, which have to be treated first.
3.2.3.2.1 Install Policies
Traffic policies installed in the BRAS and/or DSLAM may result in traffic conditioning mechanisms
being applied to L2 and/or L3 in the transport data plane. The list below provides some examples
of traffic conditioning mechanisms in BRAS/DSLAM that are installed on request from RCF and or
PDF by means of generic transport policies:
- Pure L2 QoS mechanisms, e.g. VP/VC based for ATM networks, DLCI based for FR
networks, or VLAN tag for Ethernet;
- Intermediate L2/L3 QoS mechanisms, e.g. MPLS;
- Pure L3 QoS mechanisms, e.g. DiffServ;
- L3 over L2 QoS mechanisms, e.g. DiffServ over ATM or FR;
- L3 over intermediate L2/L3, e.g. DiffServ and MPLS seamless integration.
In the context of the present document, PDF shall deal only with L3 policies. The use of the
remaining policy types is not precluded to be applied by BRAS, which in that case would have to
perform a certain policy based on its own interpretation of the L2 parameters, or of the L2
parameters combined with others, included in pre-defined/provisioned traffic policies. This can be
achieved by allocating a particular Id to each policy.
As such, PDF shall be capable of:
- Providing an explicit description of the traffic policies to be applied. This option is only
applicable to L3 policies (e.g., DiffServ); and
- Attaching a pre-defined traffic policy to the media flow(s). In this case the PDF provides
a policy-id, which will be translated into specific traffic policies to be applied. This option is
applicable to both L3 and L2 policies.
23
3.2.3.3 Resource Control Function (RCF)
The RCF is a logical element for control the resource in the access network.
The main functions of this element are:
- Admission Control: The RCF receives requests for QoS resources from the
PDF, indicating
the desired QoS characteristics (e.g. bandwidth). The RCF shall use the QoS information
received from the PDF to perform admission control, i.e. the RCF checks whether the requested
QoS resources can be made available for the involved access. The RCF shall indicate to the PDF
whether a request for resources is granted or not.
- Network Policy Assembly: Access Network Policies are a set of rules that specify what
network policies should be applied to a particular access line. The RCF ensures that a request
from the PDF matches the access policies.
3.2.3.3.1 Admission control process
The NASS informs the RCF when a subscriber attaches to the network. The subscriber access
profiles received from the NASS consist of:
- Subscriber attachment info: Subscriber ID, Physical Access ID, Logical Access ID,
Access Network Type and Globally Unique IP Address;
- QoS Profile Information: Transport Service Class, UL Subscribed Bandwidth, DL
Subscribed Bandwidth, Maximum Priority, Media Type and Requestor Name.
- Initial Gate Setting: List of Allowed Destinations, UL Default Bandwidth, and DL Default
Bandwidth.
24
On the other hand, the PDF provides the following information that is relevant to RCF procedures
when it receives a request:
-
Subscriber Id or IP address;
-
Requestor Name / Service Class;
-
Media Description;
-
Service Priority.
The Physical Access ID, Logical Access ID and Access Network Type allow RCF to bind the
Subscriber ID and its IP Address to the topology information of the access and aggregation
networks hosted in RCF.
The RCF uses the Initial Gate Setting, the capabilities of the elements in the data plane as well as
access network policies, defined by the operator, to derive the initial traffic policies that must be
installed in the RCEF.
When a resource request is received from the PDF, based on the Subscriber Id and/or the IP
address, the RCF identifies the subscriber access profile previously received from the NASS.
The RCF first matches the Requestor Name in order to identify one or more QoS profile that
applies to the request. The RCF shall deny a request from the PDF if it is not permitted by the
selected QoS profile in accordance with local policies. The RCF only permits the request from the
PDF if all media can be accepted.
3.2.3.4 DSLAM
The DSLAM performs policy enforcement functions under control of the RCF and is responsible
to maintain the RCF informed about the situation of the network (e.g. resources used and
topology changes).
The DSLAM main functions are:
-
enforcement of the policies defined by the access provider;
-
opening and closing of gates in order to allow only authorized traffic to flow;
-
marking IP packets in accordance with the filtering criteria received from the
RCF;
-
policing upstream and downstream traffic to ensure that the traffic remains within
the authorized limits;
25
-
sending Traps to the RCF in case of network changes, as more resources
used/released and topology changes provoked by e.g. a link cut.
Unidirectional micro-flows are specified by the RCF towards the DSLAM in terms of a flow
classifier including the standard 5-tuple (source IP address, destination IP address, source port,
destination port, protocol).
3.2.3.5 BRAS
The BRAS is a packet-to-packet gateway for the user plane media traffic. This element performs
policy enforcement functions under the control of the PDF in each of the network segments:
access, aggregation and core.
The BRAS has a policy enforcement function that interacts through the TC interface with the
PDF. This element operates on micro-flows, i.e. on individual flows of packets belonging to a
particular application session. The policy enforcement function is a dynamic gate that can block
individual flows or allow authorized flows to pass. For an admitted flow the PDF instructs the
BRAS to open/close its gate for the particular flow, i.e. to allow the admitted flow to pass through
the router.
Possible resources that are managed by the BRAS include the handling of a pool of IP
addresses/ports and bit rate on the BRAS interfaces.
Unidirectional micro-flows are specified by the PDF towards the BRAS in terms of a flow classifier
including the standard 5-tuple (source IP address, destination IP address, source port, destination
port, protocol).
Per admitted micro-flow, the PDF may instruct the BRAS to apply policies (e.g. traffic-conditioning
filter) that limit the throughput of the flow to an admitted level indicated by the PDF.
26
3.2.3.6 NASS
The NASS is responsible for notifying the RCF when a subscriber attaches to the network. The
NASS provides to RCF an association between IP address, the bearer used in the access
network and additional subscriber access information.
In Figure 3.5 we design that associated procedure:
Fig. 3.5: Subscriber Attaches Procedure
1)
The NASS accepts a request from a customer equipment device to obtain bearer
resources to attach to the access network or a modification on a subscriber's access
profile that has been previously pushed to the NAC by NASS occurs.
2)
The NASS sends Access-Profile-Push to inform RCF.
3)
Based on Local Policies in the RCF and the information received from the NASS, the
RCF decides if any traffic policies need to be installed, changed or removed. The
application of the new local policies will apply to new PDF requests whereas the current
reservations are optionally handled according to previous local policies.
4)
The RCF requests the DSLAM to install traffic policies (depending on step 3).
5)
The DLSAM confirms the installation of the traffic policies (depending on step 4).
27
3.2.4 Architecture Interfaces
In order to provide admission control in a network the functions previous defined interact between
them through internal and external interfaces.
3.2.4.1 Rq Internal Interface (PDF – RCF)
The Rq internal interface provides interaction between the PDF and the RCF functional building
blocks of the NAC architecture. The Rq requirements are classified in functional and nonfunctional elements.
The RCF provides facilities for topology-aware resource reservation, resource reservation
tracking, and a resource-constraint-based admission control service that shall be addressed
through the Rq reference point.
The Rq reference point is used for QoS resource reservation information exchange between the
PDF and the RCF. Via the Rq reference point the PDF issues requests for resources in the
access network, indicating IP QoS characteristics.
The information exchanged over this interface it is described in ANNEX 10, 11, and 12.
3.2.4.2 NR Interface (PDF – AF)
The Network Resources (NR) interface maps to Gq’ interface of the ACM model and it was
normally defined as a Diameter Protocol.
This interface allows the AF to request resources from the NAC. Since the PDF functional entity
can only request policy enforcement from other elements in the NAC, this implies that the
resource reservations performed over NR will result, if authorized by the PDF, in derivative
resource reservations and/or service requests over Rq.
Functional requirements over NR are therefore a combination of the requirements over Rq
described. However, it should be noted that the NR interface is not a simple aggregation of
functions resulting in two separate information flows for Rq-related. The NR interface also allows
for reservations relevant to Rq to be requested by AFs as a single atomic request, which the PDF
28
can then split into separate requests and coordinate accordingly depending on the service
requested.
The resource reservation requests over NR shall be expressed using the same information
elements as those over the Rq explained in previous section.
3.2.4.3 SI Infernal Interface (RFC – NASS)
The Subscriber Information (SI) interface provides interaction between RFC and the NASS. That
interaction is used to exchange the information of the subscribers attached in the access network.
The information elements exchanged and the protocol used depends on the operator’s that
managed that access network. In section 4.3.4 we have an example of this information adopted
for our implementation.
3.2.4.4 TC Interface (PDF – BRAS)
The Traffic Conditioning (TC) interface maps to Ia interface of our ACM model and it was
normally defined as a network management protocol (e.g. SNMP). This is the interface between
PDF and the BRAS, and is used for enforcing policies and admission decisions in network
elements (gate control) after the PDF make the final admission decisions.
The information elements for the TC interface are not described in this section because it was the
internal information according to the protocol used to communicate with the network elements
and the operator that managed the access network. In section 4.3.2 we have an example of this
information adopted for our implementation.
3.2.4.5 NC Interface (RCF– DSLAM)
The Network Controller interface maps to Re interface of our ACM model and it was normally
defined as a network management protocol. This interface provides the interaction between RFC
and the DSLAM.
The NC interface is used for controlling the L2/L3 traffic policies performed in the transport plane
as requested by the resource management mechanisms, is used for controlling the usage of the
resources in the access network by the RCF and is also used to control network topology
changes.
29
3.2.5 NAC Interaction Procedures
In sections below we define the interaction procedures between architecture functional elements
in order to better understand how the architecture can perform the admission control into an
access network.
3.2.5.1 Request Resource
This clause provides the flows for resource reservation request from the AF towards the PDF.
Fig. 3.6: Resource Request Procedure
1)
An AF session initiation message is received or generated in AF. The AF identifies that
this session requires resources in the transport network in order to support the
associated media flows.
2)
The AF sends the service request information to the PDF.
3)
The PDF authorizes the request. This process consists of verifying if the required
resources for the AF session, present in the service request, are consistent with operator
policy rules defined in the PDF for that particular AF.
30
4)
In case the service is authorized, the PDF send Resources-Req to allocated resources of
the RCF and wait for the response.
5)
The RCF maps the request from PDF into the internal network topology. The RCF
performs authorization and admission control based on access network policies. The
RCF also decides if there are traffic policies to be installed in the DSLAM.
6)
The RCF requests the DSLAM to install the traffic policies to be applied to the associated
flows (depending on step 5).
7)
The DSLAM confirms the installation of the traffic policies (depending on step 6).
8)
The RCF sends Resource-Cnf to inform the PDF if the resources are reserved.
9)
The PDF has determined that serving this request requires sending a request to the
appropriate BRAS and therefore the PDF sends bgf_Req to the BRAS.
10) The BRAS performs the requested service (e.g. allocates the necessary resources to
insert a RTP relay function) and confirms the operation to the PDF.
11) The PDF forwards the result to the AF.
31
3.2.5.2 Release Resource
This clause provides the flows for resource release in RCF as well as a service termination in the
BRAS.
Fig. 3.7: Resource Release Procedure
1)
An AF session release message is received in AF. The AF identifies that the associated
resources shall be released.
2)
The AF sends a request to the PDF to relinquish the resources previously allocated.
3)
The PDF determines that serving this request requires sending a Resources-Rel to RCF.
4)
The RCF releases all associated resources. The RCF checks if there are traffic policies
to be removed from the DSLAM.
5)
The RCF requests the DSLAM to remove the associated traffic policies (depending on 4).
6)
The DSLAM confirms the removal of the traffic policies (depending on 5).
7)
The RCF informs the PDF that the resources were relinquished.
8)
The PDF determines that a release request is to be sent to the appropriate BRAS.
9)
The BRAS terminates the service (s) and confirms the operation to the PDF.
10) The PDF forwards the result to the AF.
32
3.2.5.3 Resource Modification Request
This procedure is used when the AF session signalling decides to modify the AF session. An
update of a previous reservation is requested from the PDF.
The following figure is applicable to both access sides of a session establishment.
Fig. 3.8: Resource Modification Procedure
1)
An AF session modification results in the need to change the existing resource
reservation.
2)
The AF sends the service request information to the PDF.
3)
The PDF shall authorize the request with the modified parameters. This authorization
consists of verifying if the modified QoS resources for the AF session, present in the
session description, are consistent with the operator policy rules defined in the PDF. The
SPDF send a Resources-Req to RCF and wait for the response.
4)
The PDF has determined that serving this request requires sending a Resources-Mod
message to the RCF.
5)
The RCF performs admission control based on access network policies with the new
QoS parameters.
6)
The RCF may request the DSLAM to modify the installed traffic policies that are applied
to the associated resource reservation session flows.
33
7)
The DSLAM confirms the modification of the traffic policies (depending on 6).
8)
The RCF informs the PDF that the resources requested are reserved.
9)
The PDF checks if there are also service (s) to be modified in BRAS. If yes, a bgf-req is
sent to the BRAS.
10) The BRAS modifies the service (s) and confirms the operation to the PDF.
11) The PDF sends the confirmation to the AF.
34
4 Architecture Implementation
The prototype implementation is the concretization phase of our work being a way of validating
the proposed model and corresponding architecture. The scope of this chapter is then the
implementation of the Admission Control Architecture which is composed by the elements
described in the chapter 3.
4.1 Architecture implementation overview
In order to implement our Admission Control Architecture we need to develop some elements.
In figure 4.1 we can see that an open-source SoftSwitch called SipExchange [6], developed by
the CafeSip team, was used to act like the application function. We had to modify that
implementation in order to give the SoftSwitch the possibility to operate with the Network
Admission Controller.
The communication between these two elements are made through the Diameter Protocol, for
that interface we used an Open-Source package called Openblox [7] that implements the
Diameter Protocol Base and the structure of messages for all the normalized standard interfaces
that use the Diameter protocol. In this work we have to use the Gq interface to make the
communication between the AF and the NAC, as it was explained before.
The NAC is composed by two java packages: RFC and PDF. Inside of these packages we have
the corresponding RFC.java and PDF.java and other auxiliary classes. Derived from the RFC
package we have other packages called RFC.domain, RFC.network and RFC.dom. All of them
are composed by auxiliary classes to RFC.java implementation.
Inside of NAC we used one open-source java package called JUNG [8] to build network graphs.
These graphs are useful to collect and represent the topology of the access network.
The communication between the NAC and the network elements is made through the Telnet
protocol, using the command line interface of the network elements. In the implementation of
these communication interfaces we used another java package that implements the Telnet
protocol and adapts them in order to be used inside NAC.
35
The NASS element is used for NAC initialization only. It is a XML file with user’s information.
Other XML file (Physical-Logic_Model.xml) is used in initialization with all information about the
network configuration (NE’s configuration and Links configuration). When NAC starts-up the first
time these files are written, using an open-source java package called DOM, being that
information passed to the NAC memory.
In figure 4.1 we can see a diagram of the implementation block used in this work. It’s important to
note that this is a full java implementation and inside NAC all java classes and XML files, except
JUNG, was specially developed and the java packages used have to be modified in order to
adapt them to our Admission Control architecture.
Fig. 4.1: Implementation blocks diagram
The implementation of all components is detailed explained in sections 4.2 and 4.3.
36
4.2 Functional Elements Implementation
In our implementation some elements are open-source packages that we reuse and modify in
order to adapt them to our architecture implementation.
In order to understand how the architecture elements are implemented it’s important to have a
description of the packages used and the modifications performed. PDF and RCF are the two
elements full developed by us in this work.
4.2.1 Application Function
We decided to use a VoIP service to test the Admission Control capabilities. In this type of
service a SoftSwitch was necessary, as explained before. The Application Function is
represented by the SipExchange, which is an open-source SoftSwitch is providing standard SIP
services like registration, proxy and presence. Using the SipExchange application, we can
simulate a service provider that offers VoIP services to their subscribers as well as other services
based on voice, video and instant messaging. SipExchange supports many of the standard
subscriber features offered by the traditional telephone exchanges and PABXs. In addition,
SipExchange supports external call control capabilities that software developers can use to
create new features and services rapidly and plug them into the SipExchange application. In this
work we used this capability to implement the Admission Control feature inside of SipExchange.
SipExchange has Java and J2EE technology as a basis for the architecture that is flexible,
scalable and easily extensible. It runs as an enterprise application inside the JBoss server and
takes advantage of many services that a J2EE server provides. SipExchange provides a webbased user interface that system administrators can use to manage subscribers and features as
well as perform other routine operations. SipExchange also provides a web-based user interface
that subscribers can use to customize the features they have subscribed to.
4.2.1.1 External Call Control Capability
As explained in the previous section, one of the primary functions of SipExchange is to setup and
tear down SIP call sessions between two or more parties. It also provides the business logic for
handling of features subscribed by the users. Examples of subscriber features include "call
forwarding", "call blocking" and in this work “Admission Control”. In this sense, SipExchange is a
37
call processing engine similar to telephone switches and PABXs. The call processing engine of
SipExchange consists of a number of components. They are:
1. Registration service: When a subscriber turns on the SIP phone, the phone registers
with the SipExchange server. This is like a login procedure. The registration is handled as
per procedures laid out by the SIP protocol. In addition to authenticating the user, the
SipExchange server stores the contact address of the subscriber in a location database.
A subscriber can be registered from multiple phones at multiple locations. The
SipExchange server also handles the "unregistration" and expiry of registration. In this
case, it removes the contact information from the location database.
2. Location database: The location database provides a persistent storage for storing
contact information for registered subscribers.
3. Proxy service: The proxy service handles incoming call requests from subscribers and
non-subscribers. When a session initiation request is received from a SIP phone, the
proxy service locates the called user from the location database and forwards the request
to the location(s) of the called user. Note that the proxy service does not forward
sessions from a non-subscriber to a non-subscriber. Therefore, it can only handle calls to
a subscriber and/or from a subscriber. During the processing of requests, SipExchange
also handles the special cases for features subscribed to by the calling and called
subscribers.
SipExchange provides hooks allowing external agents to control how the proxy service handles
the call setup. This process is called external call control. Using this mechanism, we can create
our own features and services. For example, we want to implement an "Admission Control"
feature. In this feature, when a user “A” try to call another user “B”, the call is forwarded to
SipExchange, the feature based on call parameters builds a resource request and send them to
NAC in order to request authorization to forward the call to user “B”.
It is impossible to implement this service on switching equipment not providing external call
control functionality, being the main reason for our choice of using SipExchange as the
application function of our architecture.
SipExchange provides external call control hooks very similar to those available in Advanced
Intelligent Network (AIN/IN) telephony solutions providing external call control hooks. In the
AIN/IN concept, there are basically two components:
38
1. Service switching point (SSP): The SSP provides the business logic for setting up and
tearing down calls. While processing a call, the SSP makes a determination based on
configuration that it needs to contact an external agent to determine how the call is to be
handled. It sends a message over the signalling network to the external agent. The
external agent sends a response specifying how the call should be handled, and the SSP
alters the call flow accordingly.
2. Service control point (SCP): The SCP is the external call control agent and acts as the
feature server. An SSP can contact different SCPs based on the configuration even while
processing a single call.
Let’s take an example of how this architecture provides an “admission control” feature. The SSP
receives a request to route an incoming call from user “A” to user “B”. In the process of making
the call from user “A”, it looks up in the subscriber database to determine if the subscriber has a
“MakeCall trigger” (explained below) condition attached to it. If this trigger condition is met, the
SSP sends a trigger message to the SCP with the subscriber and trigger information. The SCP
looks up in a database to determine if the subscriber has activated an admission control feature.
If not, it sends a “continue” response to the SSP; otherwise it executes the feature. This being the
case, it sends a resource request to NAC and waits for the admission response. According to the
admission decision, it sends a “continue” or a “terminate” response to the SSP in order to
continue forwarding the call or terminate the call. This is just an example of the interaction
between these two components inside of SipExchange implementation. The admission control
feature is detailed explained below.
4.2.1.2 Triggers and trigger processing
Triggers are points in the call where the SipExchange server communicates with an external SCP
in order to find out how to process the call. Certain calls may not encounter any trigger condition
and may be processed using the standard call processing logic while other calls will encounter
trigger
conditions
that
are
processed
by
the
SCP
to
alter
the
call
flow.
A trigger condition can be configured by system administrators from the SipConsole user
interface. Broadly speaking, there are two types of trigger conditions that can be configured. They
are:
1. Subscriber triggers: For any subscriber(s), you can configure one or more subscriber
triggers. When the call processing module processes a call from or to this subscriber, it
39
checks if a trigger condition matches and if the trigger has been configured for the
subscriber. The trigger conditions are explained in details below. If both these conditions
are satisfied, the SipExchange server sends a trigger message to the SCP and alters the
call flow based on the response from the SCP.
2. Domain triggers: Similarly, for any domain(s), you can configure one or more domain
triggers. When the call processing module processes a call from or to a user in this
domain, it checks if a trigger condition matches and if the trigger has been configured for
the domain. The trigger conditions are explained in details below. If both these conditions
are satisfied, the SipExchange server sends a trigger message to the SCP and alters the
call flow based on the response from the SCP.
In this work we just use Subscriber triggers because we are always working in the same domain;
admission control capability only makes sense when applied to subscribers.
The system currently supports the following types of triggers:
1. MakeCall: This trigger can be assigned to a subscriber. When the subscriber (calling
user) makes an outgoing call, this trigger is encountered.
2. TerminateCall: This trigger can be assigned to a subscriber. When the subscriber (caller
our called user) decides to terminate a call, this trigger is encountered.
3. ReceivedCall: This trigger can be assigned to a subscriber. When the subscriber (called
user) receives an incoming call, this trigger is encountered.
4. CalledBusy: This trigger can be assigned to a subscriber. When the subscriber (called
user) receives an incoming call and he/she declines the call or has the SIP phone set to
busy mode, this trigger is encountered.
5. CalledNoAnswer: This trigger can be assigned to a subscriber. When the subscriber
(called user) receives an incoming call and he/she does not answer the call, this trigger is
encountered.
6. CalledNotAvailable: This trigger can be assigned to a subscriber. When the subscriber
(called user) receives an incoming call and he/she is not registered, this trigger is
encountered.
40
The diagram shown in figure 4.2 illustrates when and how these triggers are encountered during
call processing. The diagram also shows how the call processing module processes incoming
calls and under what circumstances, the triggers are encountered.
Fig. 4.2: Trigger Types Diagram
In this work we just use three types of triggers. The MakeCall and ReceivedCall triggers are used
in the admission control process on the two lags of a VoIP call. Suppose we are trying to make a
call from the subscriber “A” to subscriber “B”. The first lag of the call it’s the path between the “A”
location and the BRAS, the second lag it’s the path between the BRAS and the “B” location.
These 2 lags form a completed call. For that the admission control process has to be performed
41
in the 2 lags for the call being established. In order to perform that verification, all the subscribers
present in SipExchange have to be assigned these two types of triggers, but with the same
feature that is admission control because the same subscriber can be the caller or called
subscriber. In these two situations a path has to be verified and the admission control process
has to be executed. For example, when the subscriber “A” try to call the subscriber “B” the
MakeCall trigger is invoked for “A” and the ReceivedCall trigger is invoked for “B”, but the feature
performed are the same for both. The call it just was established when the admission process
was succeed in the two lags of the call.
The other type of trigger used is the only that was created by us and we call him TerminateCall
trigger. As we can see on figure 4.3 this type of trigger was invoked when a user, that has an
established call, decide to terminate that call. When this situation occurs the NAC has to be
advised in order to release the resources previous reserved to that call. In this case all the
subscribers that use VoIP services has to be assigned the TerminateCall trigger with the
Admission Control feature.
Fig. 4.3: TerminateCall trigger diagram
42
4.2.1.2.1 Trigger Processing
When a trigger is encountered, the trigger condition is reported to the SCP using a
communications message. SipExchange uses JBOSS Remoting services for communication
between the SSP and the SCP. Basically, it allows Java objects to be passed between the client
and the server using one of the above protocols for transport. The SipExchange server acts as
the client and the SCP acts as the server. The client "invokes" a service on the server and the
server "responds" back after serving the request embedded in the invoke. The invocation is
similar to a remote procedure call and internally, "serialized" Java objects containing detailed
information about invoke and the response are exchanged between the client and the server. The
underlying serialization and messaging is transparent to the client and the server application.
Invocation request:
While invoking the SCP service, the SipExchange server sends the following information to the
SCP:
1. Feature
2. Trigger type
3. Parameter
4. Calling subscriber information from the subscriber database, if the caller is a subscriber
5. Called subscriber information from the subscriber database, if the called party is a
subscriber
6. Calling domain name if the caller belongs to a domain that the SipExchange server is
serving
7. Called domain name if the called party belongs to a domain that the SipExchange server is
serving
8. Trigger-specific parameter, if any
9. SIP message that caused the invocation.
43
Response:
The SCP may respond with one of the following options:
1. Continue: The SCP uses this response to tell the SipExchange server that it must
continue processing the call. The SipExchange server continues to process the call as if
the trigger was never encountered. The call may have more than one trigger associated
with this trigger point. In that case, the call processing service processes the invocation
for the next trigger. While continuing to process the call, if it encounters additional trigger
conditions, each invocation is sent to an SCP as required by the trigger.
2. Terminate: The SCP uses this response to tell the SipExchange server that it must
terminate (end) the call. The SipExchange server sends a response to that effect. The
status code and reason phrase sent in the SIP response message are those received
from the SCP in the SCP response message.
3. Re-route: The SCP uses this response to tell the SipExchange server that it must
forward or redirect the call to another address or to multiple addresses. The SipExchange
server acts accordingly. The difference between the forwarding and rerouting is that in
the latter case, the SipExchange server sends a REDIRECT SIP response to the calling
party.
4.2.1.2.2 Trigger configuration
The subscriber and domain triggers are configured from the SipConsole. We can get a list of
triggers configured for a domain or a subscriber by selecting the domain or the subscriber
respectively and by clicking on the "Triggers" button. From the list screen, we can add or remove
triggers. The following figure shows the parameters that we can enter.
Fig. 4.4: Trigger Configuration
44
Here is a more detailed explanation of the parameters:
1. Feature: Name of a feature that the SCP implements using this trigger. This information
is sent to the SCP in the trigger message.
2. Trigger: The type of the trigger as explained above.
3. Order: An integer number indicating the order in which this trigger is processed.
Basically, for a given trigger type, there may be one or more triggers assigned to the
subscriber/domain to implement one or more features. The order specifies in which order
the triggers are reported to the SCP.
4. Parameter: A trigger-dependent parameter can be entered here. For most triggers, this
may not have any significance except that this information is sent to the SCP in the
trigger message and may be used by the SCP to provide a particular type of treatment.
However, for the CalledAddress trigger, the pattern is specified using this field. As
mentioned earlier, the pattern is matched against the called user id to determine if the
trigger condition is encountered.
5. Service Controller: The URL of the service controller. The URL specifies the SCP host
name, port (optional) and the protocol using which the SCP communicates with the SSP.
As explained in the trigger processing section, SipExchange uses the JBOSS remoting
services for communication between the SSP and the SCP, and this URL follows the
same URL scheme.
4.2.1.3 Admission Control feature
Having seen as SipExchange call processing and external call control operates, let's take an
explanation of how the admission control feature, developed in the scope of this work and
plugged into the SipExchange, works in order to give him the possibility to interact with the
Network Admission Controller.
The Admission Control feature allows a subscriber to verify if the network can support other call
with QoS guarantees. When admission control is set, all calls from this subscriber are first verified
and then accepted or rejected.
45
1. A MakeCall / ReceivedCall / TerminateCall trigger are added to all the subscribers. The
service controller parameter contains the URL for the SCP providing the service logic for
this service.
2. When SipExchange receives a call (SIP Invite) from one of these subscribers, it
encounters the MakeCall trigger in the caller and the ReceivedCall trigger in the called
and he have to extract the calls parameters from the SDP packet. Then the SCP service
is invoked with that information.
3. The SCP tries to connect to NAC and send them a resource request with the information
of the subscriber who wants to initiate a call and with the bandwidth need to that call. If
the response was “admission rejected” the SCP sends a terminate response to
SipExchange and the call is not established. Otherwise, if the response was “admission
accepted” the SCP sends a continue response to SipExchange.
4. Then the process has to be repeated in the called subscribed, if the continue response
also was obtained the call is established.
5. When SipExchange receives a request to terminate a call (SIP Bye) from one of the
subscribers that participate in a call, it encounters the TerminateCall trigger and the SCP
service is also invoked, but at this time it just needs the information from the session and
the subscriber that wants to terminate the call.
6. The SCP tries to connect to NAC and send them a release request with the information of
the subscriber who wants to terminate the call. Then the NAC releases the resources
associated to that call (session) and send a continue response to the SipExchange and
the call will be terminated.
This feature was developed in the “AdmissionControl.java” class in SipExchange implementation.
We also have to modify 2 SipExchange classes called “SipExchange Proxy.java” and
“TriggerProcessor.java”. The first class is responsible to invoke the triggers and we have to
modify this class because in admission control feature before invoke the trigger we need to
extract the parameters of the call from the SDP packet and send that information in the trigger
invocation. The other class was modified because we have to add a new trigger called
TerminateCall trigger that is explained before.
46
In figure 4.5 we can see the feature Admission Control (AC) assigned to the subscriber
[email protected] for the moment when he makes a call or terminates a call.
Fig. 4.5: Admission Control feature assigned
4.2.2 Policy Decision Function
This element is responsible to receive the new resource requests and enforce the admission
decisions in the network elements. The PDF is represented in our implementation by a java
package also called PDF. This package contains 3 java classes that are the following:
Package PDF:
PolicyDecisionFunction.java
This class is the main class of that implementation. It is responsible to make the NAC initialization
using a function called “NACInit” and then waits for requests using a function called
“WaitingRequests”.
The NAC initialization is a process where the information about the network (NE´s and Links
configuration) that is in the Physical-Logic_Model.xml file and about users that is in the NASS.xml
file is passed to NAC memory, for further used in admission decisions.
Using that network information the NAC is capable to build a network graph that represents the
situation of the network that it is controlling. When PDF receive a new request, the user’s
information inside the NASS file is used to make an association between the IP address from the
request and the location (NE and port used) in the network of the user with that IP address.
Knowing this information and the network information the PDF is capable to evaluate the path in
47
the network for a certain request. The NASS information is also used in the enforcement of the
admission decisions because the PDF has to know the NE and the port where the policy has to
be applied.
In table 4.1 we have the functions that are comprised in the PolicyDecisionFunction.java class.
The class “createNetworkReqListener” and “AddAnswerConnectionParameters” are from the NR
interface implementation and are detailed explained in section 4.3.1.
The principal PDF functions are succinct in table below. A more detailed explanation can be
found in ANNEX 13 which has the PDF UML.
NAC_Init
Responsible to put in memory all the information related
with network and users.
WaitingRequests
Responsible to initialize the connection parameters
between PDF and AF and then waits for requests from
the AF.
EnforceBrasPolicys
Responsible to enforce admission decisions in the
network elements.
createNetworkReqListener
Used in Gq implementation.
AddAnswerConnectionParameters
Used in Gq implementation.
Main
Used to run NAC implementation.
Table 4.1: Functions of PolicyDecisionFunction class
SessionPDF.java
This is an auxiliary class from PDF implementation, it represents a new call. Because an
accepted request represents a new session and the PDF has to keep the sessions information.
A more detailed explanation can be found in ANNEX 14 which has the SessionPDF UML.
TelnetSession.java
This class represents the implementation of the interface TC between the PDF and the BRAS.
That interface is used to enforce the admission decisions in the network. It’s an open-source
implementation of the Telnet protocol.
48
The BRAS is the network element where the policies are enforced. The PDF has to connect to
this element in order to enforce these admission decisions, for that we use the Telnet protocol
and adapt them to our NAC implementation.
In this case in table 4.2 are the functions of the Telnet implementation that we use in our PDF
implementation, these functions appears inside of the previous PDF function called
“EnforceBrasPolicys”.
connect
Used to connect to BRAS.
login
Used to make the login corresponding to BRAS command line interface.
writeln
Used to send a command to BRAS.
sendln
Used to send a command to BRAS.
Table 4.2: Functions of TelnetSession class
4.2.3 Resource Control Function
The RCF it’s the other element of NAC implementation. It is an element responsible to control the
network resources. When a resource request arrives to PDF, it has to use some RFC functions in
order to decide if there are available resources to accept this new request. In our NAC
implementation the RCF element is represented by a java package also called RCF. That
package is composed by some classes that are detailed explained below.
Package RCF:
ResourceControlFunction.java
This is the principal class of that package because it has the functions responsible to initialize the
network and users information, these functions are used by the previous function “NACInit”
explained in the PDF implementation.
It’s important to understand the meaning of the 2 XML files. The NASS.xml is a file that only
contains associations between an IP address of a certain user and the corresponding NE id and
port id used by this user in the network. This is important because when PDF receives a request
it only receives an IP address of the user but doesn’t know the location of that user. In this case it
49
has to use the “FindAssociation” function to consult our internal memory and discover the location
of the corresponding user to know the path in the network that has to be evaluated.
The Physical-Logic_Model.xml is the other file used on NAC initialization. It has all the information
related to the network elements one by one port by port and the information of all the links that
composed that network. We assume in order to simplify the NAC implementation that when a
NAC is installed in one certain network, we a have a file like that because in this release NAC
doesn’t has the feature to learn the network composition. This is a feature to future work, it will be
interesting that NAC would be capable to learn the network composition and in case of network
changes it also could follow these changes.
These two files are used in the following “InitX” functions in order to pass all the information
previously explained for NAC memory.
It is also important to understand the meaning in this implementation of a Vertex, an Edge and
Network Graph. In this case in our implementation a Vertex represents a Network Element (NE)
and an Edge represents a link between two NE’s because in JUNG implementation a graph is
composed by Vertex’s connected by Edges. In our implementation a NetworkGraph is composed
by NE’s connected by links. The JUNG implementation give us the possibility to attach
information to Vertex’s and Edge’s and this is important because we can build a network graph
with all the information associated to network elements and with that we can have in memory a
replication of the real network.
The “BuildVertex” and “BuildEdgeList” functions are responsible to create the Vertex’s and the
Edge’s based on network elements and links information. The “BuildGraph” function is
responsible to create in memory a network graph that will be use to verify the available resources
for a certain request. We know that in IP/Ethernet we can only have one active path between to
points, but is commonly used with STP some redundant links that are inactive and are only used
in case of network failures. The “BuildEdgeList” function returns a list with all the links in the
network, but that links has information associated to them and one of the parameters is the state.
The “BuildGraph” function only create a network graph with the links that has the state active and
don’t consider the redundant links. In case of failure the NAC has the information necessary to
build a new network graph it the redundant link that was turned to active.
The most important parameter associated to these links is the capacity because is the parameter
that is verified when a new resource request arrives to PDF.
50
The principal RCF functions are succinct in table below. A more detailed explanation can be
found in ANNEX 15 which has the RFC UML.
In our implementation we have some other auxiliary packages with auxiliary classes and the
respective auxiliary functions.
The RFC.dom package is composed by the Dom.java file that has functions capable to extract
the information from the XML’s files. These functions are used by the “InitX” functions previously
explained.
A network link is also represented in this package, called RFC.network (ANNEX 16-18) that has 3
classes representing a NeVertex, LinkEdge and a NetworkGraph.
Other implemented package is the RFC.domain (ANNEX 19-27) that is composed by one class
for each type of network element and there components like Xdslports, Ethports and Traffic
Classifiers.
At Annexes 28, 29 and 30 we can find the RFC.dom UML and the XML files explained before.
InitNASS
Responsible to put in memory the association’s information.
InitDslams
Responsible to put in memory the Dslams information.
InitSwitchs
Responsible to put in memory the Switches information.
InitBras
Responsible to put in memory the BRAS information.
InitLinks
Responsible to put in memory the Links information.
FindAssociation
Responsible to find an association between an IP address and the
corresponding NEId and portId of that user.
BuildVertex
Responsible to create a NeVertex.
BuildGraph
Responsible to create a Network Graph.
BuildEdgeList
Responsible to create a LinkEdge List.
Table 4.3: Functions of ResourceControlFunction class
51
4.3 Interfaces implementation
The principal interface present in our implementation is the Network Requests (NR) that is the
Openblox package. This package represents a Diameter Protocol implementation and the
respective reference point Gq’. The other used interface is the Traffic Conditioning responsible to
establish the connection between the PDF and the BRAS in order to enforce the policies
corresponding to the admission decisions. This implementation is represented by the Telnet
implementation previously explained.
The Network Controller (NC) is an interface not yet implemented because is reserved for a
feature released where the NAC can have the capacity of learning the network composition, for
that needs an interface to receive that information.
4.3.1 NR Interface (PDF - AF)
The Network Resources (NR) interface is an implementation of Gq’ reference point. This
implementation is an open-source package that we reuse in our work and is called Openblox.
The OpenBloX is an Open Source set of directories and files, implementing in a whole or part of
the Diameter specifications. The package contain at minimum the Diameter base protocol as
described by IETF RFC 3588 and any interfaces provided by the specifications, in case of this
work we use the Gq’ interface.
The package contain utilities that are set to support access, formatting and parsing of software
components that are used either internally by the package or by the application implementing a
Diameter server or application.
The OpenBloX package contains the Diameter Base, the specified sub protocol interfaces and
(unlike most traditional stacks) a full state machine for each of the defined interfaces - this
enables the implementing user to stay focused on his own core expertise and not to become an
expert in internal Diameter functionality and of-course cuts implementation time and efforts by
supplying the interfaces Finite State Machine as part of the solution.
52
Fig. 4.6: Openblox package
The detailed implementation of all class that composed that Diameter protocol and Gq’ interface
implementation can be found in OpenBloX manual [7].
In our work we have to use some functions of these implementation in order to adapt that
interface to PDF and AF.
In the implementation of PDF we use the OpenBloX server API because interface of this API are
intended to work in server mode. The first step is the stack initiation that opens the server socket
and then it stay’s waiting for Authorization sessions.
In the AF implementation we use the OpenBlox client API because
in this case the stack
initialization just happens while a new request has to be send to the server and a response has to
be received. After that the connection with the server is closed, but the server in this case the
PDF it’s always running.
4.3.2 TC Interface (PDF - BRAS)
The Traffic Conditioning (TC) interface is the way of communication between the PDF and the
BRAS in order to enforce the policies corresponding to the admission decisions performed by the
PDF.
The BRAS has a command line interface that gives the possibility to PDF to use the telnet
protocol to send commands to them in order to block or allow ports corresponding to users.
The telnet implementation that we used to adapt to our implementation like is explained on
section 4.2.2 is an open-source package.
53
4.3.3 NC Interface (RFC - DSLAM)
The Network Controller (NC) interface is not yet implemented, but in future work it can be a
SNMP implementation. With this interface working we can implement a feature that gives to NAC
the possibility to learn network changes and with that it can react to network expansions.
54
5 Application Scenario
5.1- Network General Description
In order to test the implementation of our Network Admission Controller we needed an example of
an access network with the main components present in our architecture.
The main components of a next generation broadband network are: the DSL customer premises
equipments (modem), IP/Ethernet DSLAM, Ethernet aggregation layers (Switches), multi-service
edge routers, broadband remote access servers (BRAS) and home entertainment network (video
and content delivery solution).
At the lab we have an example of a small access network, illustrated in figure 5.1, where we
tested the implementation of the Network Admission Controller (NAC) developed in this work.
That access network is composed by:
-
2 ADSL modems to be used by the subscribers in order to having access to the
services, like VoIP and VoD.
-
Then we have an IP/Ethernet DSLAM (hiX5630) that is a network element which
includes the necessary service adaptation function to support the delivery of all type
of applications over Ethernet/IP networks. It operates as a multiplexer, which
consolidates the traffic originating from the subscribers lines (xDSL) into one or more
Ethernet uplink interfaces connected to IP/Ethernet network.
-
In the middle we have 3 Ethernet aggregation elements, commonly called Switches
(hiD6650) that forward the traffic coming from DSLAM Ethernet uplinks to the IP
router (ERX-Juniper). They form a loop protected by spanning tree protocol (STP),
because in Ethernet networks we can’t have loops but with STP one link of the loop is
cut and acts as a protection link. These Switches have the functionality to fast-switch
the packets by VLAN and we use it in order to differentiate the services traffic. In this
architecture the VLAN for the respective service was tagged in the DSLAM and
untagged in the BRAS.
55
-
The BRAS is an ERX-Juniper that aggregate the traffic coming from the DSLAMs and
route the traffic from this access network to the core network, giving the subscribers
connection to other networks in Internet. In this test no other networks are used, and
we just have 2 subscribers of the same access network communicating. This network
element is also the point where the QoS policies are enforced.
Fig. 5.1: Network Topology
It’s important to note that we use two ADSL2+ (8 Mbit/s) subscribers and all the links between the
network elements have the same capacity (1 GB) and a bottleneck is not present here. This is
important for validate tests results, because if we have a bottleneck all the results are affected for
the lower capacity of this link.
In order to test our NAC implementation we needed real-time services as was explained before.
We can see in figure 5.1 an Application Server representation. This element is a computer
running the open-source SIP SoftSwitch called SipExchange (detailed explained in section 4.2.1).
This element is necessary in a VoIP Scenario because is responsible to establish the connections
between two VoIP clients. In the same computer we also have installed an open-source media
56
server called VideoLan Server but specific for one test that is explained in chapter 6, all of other
tests had used VoIP service.
In our application scenario we also need VoIP clients that are the responsible to initiate a new
service flow. In this work they are two computers running an open-source softphone called X-Lite.
These clients are represented in figure 5.1 by the two CPE’s because they are the elements that
connected to the computers give them access to VoIP service.
The NAC and NASS elements in figure 5.1 are also software, developed by us in the scope of
this work, running in a computer.
5.2 – Network Equipment Description
In order to better understand the components present in our network topology we following have
a description of each one of the network elements.
5.2.1 – DSLAM
The DSLAM is a network element which includes the necessary service adaptation functions to
support the delivery of all types of applications over Ethernet/IP networks.
The hiX 5630 DSLAM operates as a multiplexer, which consolidates the traffic originating from a
number of subscriber lines (ADSL/ADSL2+/SHDSL) into one or more Ethernet uplink interfaces
connected to the Ethernet/IP network. For ADSL and SHDSL, the ATM layer (PVCs – Permanent
Virtual Connections) is terminated on the interface unit and translated to Ethernet to be
transported through an Ethernet/IP environment. The multiple PVCs/VLAN are usually mapped
into one or more VLANs and forwarded to the right destination with the appropriate CoS.
The hiX 5630 introduces the ADSL2+ technology, which provides up to 24 Mbit/s in downstream
direction and up to 1 Mbit/s in upstream direction. High bandwidths are reached by doubling the
frequency range reserved for the downstream transmission as specified in the ADSL2+ standard.
The voice bandwidth can still be separated from the data traffic using filters/splitters at the
costumer premise and central office location. The hiX 5630 also supports SHDSL interfaces to
provide services to business customers.
57
The following number of subscribers can be connected to the hiX5630 which provides up to 8
slots for plugging in xDSL interface units and two central slots reserved for active and redundant
switch fabric units (CXU_C):
-
Up to 384 DSL subscribers can be connected using 8 slots for 48-port ADSL
interface units (IU_ADSL48) and/or 48-port SHDSL interface units (IU_SHDSL48)
-
Up to 576 DSL subscribers can be connected using 8 slots for 72-port ADSL interface
units (IU_ADSL72)
The CXU_C plays the important role of switching the traffic, managing all components and
providing the network interfaces. The CXU_C contains 4 fixed electrical GE interfaces and 4
interfaces for optical GE uplinks. Maximal 4 of these 8 possible uplinks can be used. The uplinks
can be used as uplink towards the core network or they are used either to cascade other
DSLAMs or to connect to a collocated switch.
Fig.5.2: DSLAM System Architecture
58
5.2.2 – Switch
A Switch is a networking device that connects network segments. Low-end network switches
appear nearly identical to network hubs, but a switch contains more "intelligence" (and a slightly
higher price tag) than a network hub. Switches are capable of inspecting data packets as they are
received, determining the source and destination device of that packet, and forwarding it
appropriately. By delivering each message only to the connected device it was intended for, a
network switch conserves network bandwidth and offers generally better performance than a hub.
The Ethernet implementations of switches are the most common. Mainstream Ethernet network
switches support either 10/100 Mbit/s or 10/100/1000 Mbit/s ports Ethernet standards. Large
switches may have 10 Gbit/s ports.
The Switch plays an integral part in most Ethernet local area networks or LANs and they may
operate at one or more OSI layers, including physical (e.g. Mac-address), data link (e.g. Ethernet
frames, VLANs), network (IP address) and transport (i.e. end-to-end). Mid-to-large sized LANs
contain a number of linked managed switches
Most of the transport and service layers are Ethernet. Depending on the actual interconnecting
media (fiber/copper) and the port characteristics, the Switch hiD 6650 provide the following PHY
rates:
• 100 Mbps
• 1 Gbps
• 10 Gbps
Traffic from higher-level protocols is carried in Ethernet frames of varying sizes, each of which
contains the MAC addresses of the originating and destination stations. These frames are then
switched across the network by the Ethernet switches/bridges.
For the correct functioning of an Ethernet network, there can be only one single active path
connecting any two stations. This is guaranteed at the network level in a mesh configuration by
the Spanning Tree Protocol (STP), and its variants, RSTP and MSTP.
The hiD 6650 also provide the possibility to make the switching of the packets by VLAN. The
VLANS enable security, traffic separation, and optimization. They allow the separation of traffic
into virtual LANs based on certain criteria, usually the physical port by which traffic enters/leaves
the network or the IP subnet of the packets.
59
When an Ethernet frame enters the network by one of these ports, it is assigned a port VLAN
identifier, which will not change during the forwarding process. The choice of which VLAN ID to
use is a matter for the network operator, possibly with the help of the network management
system. From this point on, the Ethernet frame can only be transmitted on ports which are
members of that VLAN. Therefore a true separation of traffic is accomplished, and multiple
independent domains can be created over the same infrastructure.
The hiD 6650 system architecture is designed to provide total packet switching capacity from 160
Gbps in order to offer comprehensive services in Pure Packet networks. These services include:
• Services: Layer 2 VPNs, Layer 2 access to ISPs/ASPs, TDM Leased Lines and Layer 3
VPNs, with emphasis on using Ethernet as the main customer interface.
• Networking technologies: VLAN bridging, IP routing and MPLS.
The main system components are shown in Figure X. They include:
• Switching and Fabric Control (SFC) card – the main control card in the hiD system
and is responsible for its configuration and management.
• Switch Fabric Module (SFM) card – used as an additional switching fabric facility.
• Line Interface Cards (LICs) – There are several types of LICs related to various
interface types (copper, fiber, different line rates) and networking protocols and functions
(e.g., Ethernet bridging).
Fig. 5.3: Switch System Architecture
60
5.2.3 BRAS
A broadband remote access server (BRAS) routes traffic to and from the digital subscriber line
access multiplexers (DSLAM) on an Internet service provider's (ISP) network.
The BRAS sits at the core of an ISP's network, and aggregates user sessions from the access
network. It is at the BRAS that an ISP can inject policy management and IP Quality of Service
(QoS).
The specific tasks include:
- aggregation of DSLAMs outputs;
- provisioning of PPP, IP or ATM sessions;
- coordination with DHCP servers and local IP pools to assign IP addresses;
- enforcement of QoS policies;
- traffic routing into an Internet service provider’s backbone network.
A DSLAM collects data traffic from multiple subscribers into a centralized point so that it can be
uploaded to the router over a Frame Relay, ATM, or Ethernet connection.
The router provides the logical termination for PPP sessions. These may be PPP over Ethernet
(PPPoE) or PPP over ATM (PPPoA) encapsulated sessions. By acting as the PPP termination
point, the BRAS is responsible for assigning session parameters such as IP addresses to the
clients. The BRAS is also the first IP hop from the client to the Internet.
The BRAS is also the interface to authentication, authorization and accounting systems.
Fig. 5.4: xDSL aggregation with the ERX system
61
The ERX system then handles several functions:
• PPP session termination and authentication checking via PAP or
CHAP;
• Coordination with DHCP servers and local IP pools to assign IP address;
• Connection to RADIUS servers or use of domain names to associate subscriber with
user profile information;
• Support for RADIUS accounting to gather detailed billing information;
• Application of the user profile to the user traffic flow, which could include QoS, VPN, and
routing profiles.
The output of the ERX system is typically a high-speed link, such as OC3/STM1 or OC12/STM4,
to feed a core backbone router. Virtual routers can also be used to keep the traffic logically
separate and direct packets to different destinations. As shown in Figure 5.4, packets can be
directed to a CLEC, ISP, corporate VPN, or the Internet.
5.2.4 ADSL Modem
An asymmetric digital subscriber line transceiver, also known as an ADSL modem or DSL
modem, is a device used to connect a single computer to a DSL phone line, in order to use an
ADSL service. Some ADSL modems also manage the connection and sharing of the ADSL
service with a group of machines: in this case, the unit is termed a DSL router or residential
gateway.
A DSL modem acts as the ADSL Terminal Unit. The acronym NTBBA (network termination broad
band adapter, network termination broad band access) is also common in various countries.
Because a DSL modem is a bridge, it has no interface and the IP address that is configured to
the computer it is attached to is assigned to the device.
62
6 Tests and Results
Two different types of tests were considered. The Validation Test to validate our NAC
implementation and the Performance Tests which are important to assess the architecture
performance.
6.1 Validation Tests Specifications and Results
The Network Admission Controller (NAC) is the element responsible to treat the requests from
the Application Function (AF) and to enforce the admission decisions in network. In our NAC
implementation, we developed the capabilities to perform these functions.
In order to validate our implementation these capabilities had to be tested. These validation tests
and the obtained results are described in this section. It’s important to note that the type of
service used to make the tests it’s VoIP.
6.1.1 Request Resource
The Request Resource feature gives to NAC the capability to receive and treat resources
requests from the AF. This type of requests, are used by the AF when it tries to establish a new
connection, for example a new VoIP call.
The goal of this test is to guarantee that, for example, when user “A” try to call user “B” a
resource request is sent from the AF to the NAC. Before establishing the call, the admission
control process is verified.
In order to test the NAC behaviour when receive a new resource requests from the Application
Function. We test two situations.
The first situation is when NAC receives a resource request and the network doesn't have
congestion.
The second situation is when NAC receives a resource request but the network is congested.
The detailed steps performed to execute these tests are described in ANNEX 31.
63
In first situation we can observe that a call was successfully established after passing the
admission control process in the two lags of that call.
In figure 6.1 is a screenshot of the softphone used to perform this test with the message “Call
established”. In Annex 31 is with more detail the output of the NAC command log, where we can
see the verification of the network path and the new bandwidth values for that path, after that call
was established.
In the second situation we try to simulate a scenario where a call was rejected.
In figure 6.2 is a screenshot of the softphone that we use to perform this test with the message
“Authorization Rejected”. In Annex 32 is with more detail the output of the NAC command log,
where we can see the admission control process failed for this call, because the network path for
this call don’t have available bandwidth.
c
Fig. 6.1: Call Established
Fig. 6.2: Call Rejected
64
6.1.2 Release Resource
The Release Resource feature, gives to NAC the capability to treat resources release requests
from the AF. This type of requests, are used by the AF when it tries to terminate an established
connection, for example a call between to VoIP users.
The goal of this test is to guarantee that when two users has call established and one of them
decides to disconnect it, the AF terminates the call and notify the NAC to release the resources
reserved for that call.
This is a simple test just to prove that when a call is terminated by one of the user’s the NAC is
advised to readjust the values of the network path. In Annex 32 we can see the detailed steps to
perform this test and the NAC command log for a terminated call.
6.1.3 Policies Enforcement
In order to conclude the admission control process, the admission decisions has to be enforced
on the network elements. This feature is reached, applying network policies on the network
elements. We implement in the NAC this capability, in order to give it the possibility to allow or
deny the flow of certain call.
The objective of this test is to guarantee that, when the NAC receives a resource request for a
new call, If it is accepted, the VoIP traffic is allowed to clients participating in that call.
When a call is established and one of the clients terminates that call, the NAC has to block the
VoIP traffic from these clients.
This is a simple but important test because in our test bed we have to configure the BRAS to
block almost all the traffic of the subscribers, excepting the SIP traffic to the SoftSwitch. In that
way, we can guarantee that clients doesn’t send to network other types of traffic (RTP traffic in
case of VoIP) after a call has been established.
We observe that after the call was established, the 2 participants can talk one with other, in other
words, they can send RTP traffic into network.
After terminate the call the traffic coming for the participants was blocked, excepting the SIP
traffic to the SoftSwitch to give the possibility to start a new call.
After all these tests we can conclude that our NAC implementation is valid because all the NAC
capabilities implemented, are working like was expected.
In Annex 33 we can see the detailed steps to perform this test.
65
6.2 Performance Tests Specification and Results
After validation, it’s time to execute the performance tests. These types of tests are responsible to
ensure the performance, to define limits and requisites of this implementation. In this section it will
be specified these performance tests and describes the obtained results.
6.2.1 NAC Dimensioning Test
6.2.1.1 Memory Usage and Clients Max Number
In memory usage test we can know the memory needed by the NAC, to process requests
simultaneously.
Figure 6.3 represents the used memory by the NAC related with the number of requests that NAC
receives. We use for this test an interval of 10 requests. We can see that when NAC receives the
first request, it had already consumed approximately 170 Kbytes. This value it's related to NAC
initialization, where it needs more memory. With these results we can conclude that the NAC
uses 5,5 Kbytes per request, in average.
Usage Memory per client
250
Usage Memory (KBytes)
200
150
100
50
0
1
2
3
4
5
6
7
8
9
10
Nº Requests
Fig.6.3: Memory Usage Graph
66
In order to test the stability of the NAC, we try to find a limit, called max number of clients, which
represents the number of clients that can be simultaneously supported by the NAC. With the
results of these tests we can know how many VoIP calls, for example, can be simultaneously
controlled by the NAC.
The max number of clients is a value that depends of the physical memory in the machine where
NAC is running. For example, if we have a computer with 512 MB of physical memory the number
max of clients that NAC supports is approximately 99999.
6.2.1.2 Throughputs
In this section we test the throughputs that NAC can achieve. Two important results that measure
the performance are:
-
number of clients per minute (nº clients/min) that can be supported by the NAC.
-
timing between the NAC and the SoftSwitch to process a request.
The last is an important value because represents the time that a user have to wait to starts a
call.
In figure 6.4 we have the obtained results for this value. We use an interval of 20 requests and in
average we have 6, 05 sec per client. We noted that at the same time that the number of request
grows, the time needed to process a request is higher.
This increase is related with memory usage values because with more requests more memory is
used, which makes NAC's slower in the response.
Timing beween NAC and SoftSwitch
10
9
8
Time (sec)
7
6
5
4
3
2
1
0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20
Nº Requests
Fig. 6.4: Timing between NAC and SoftSwitch
67
We conclude that NAC can process approximately 10 clients/min. These values are affected by
the resources of the computer where NAC was running and by the time that the SoftSwitch needs
to perform the requests.
68
7. Conclusions
In this work is presented an Admission Control function. Based on the analysis of the standards
being developed in this area, on the type of services supported by next generation networks and
on the technologies used in telecommunications networks, we proposed and implemented an
architecture to provide Admission Control in the access networks.
This architecture is organized in three different tiers, each comprising several functional
elements. The chosen approach was the most simplified one and having three independent tiers
to keep corresponding functions as separated as possible, so that any changes or improvements
in some tier, does not impact on others tiers elements.
The Service tier represents the application function responsible to control sessions
establishments. The QoS tier represents the network admission controller where the admission
decisions are performed. Finally, the Network tier represents the network elements of our testbed.
The goal of this work was the architecture implementation, validation and the attainment of
performance results, which gives the possibility to characterize the architecture.
In order to validate this architecture, validation tests were performed with success, which prove
that this solution is ready to provide admission control in a telecommunication network.
In order to characterize the architecture, we tested the memory usage, the maximum number of
supported clients and corresponding throughputs. Unfortunately, there were some hardware
limitations in the testbed, which render the stability test of this solution virtually impossible.
Nevertheless, a stand-alone NAC test revealed an interesting performance with fast response.
However, the processing limitation of the application function elements turned out to be the
decisive factor for a significant performance degradation of the testbed as a whole.
We can conclude that admission control in IP networks can be based on bandwidth reservation,
because in this type of network the same link is shared by a lot of sessions. Without control, one
misbehaved link can deteriorate the overall performance of the access network.
69
In the future there are some features that can enhance the performance of this solution. The first
one is the learning capability of NAC, which is important to guarantee that this solution is scalable
to large scale network.
Other relevant feature in NAC is the capability to provide calls pre-emption. This means that when
a call with high priority (e.g. 112) arrives to NAC it will have always bandwidth to process this call.
If it’s not the case, NAC will be forced to “tear down” another less important call in order to
process the priority call.
It is also interesting to extend this architecture to networks with MPLS technology. This
technology has the advantage to give the possibility to make traffic engineering. This gives the
capability to have permanently allocated bandwidth to paths in a packet network.
70
ANNEX 1 - VoIP
Voice over Internet Protocol, also called VoIP is a method for taking analogue audio signals and
turning them into digital data that can be transmitted over the Internet or through any other IPbased network.
VoIP technology uses the Internet's packet-switching capabilities to provide phone service. VoIP
has several advantages over circuit switching. For example, packet switching allows several
telephone calls to occupy the amount of space occupied by only one in a circuit-switched
network. Using PSTN, that 10-minute phone call we talked about earlier consumed 10 full
minutes of transmission time at a cost of 128 Kbps. With VoIP, that same call may have occupied
only 3.5 minutes of transmission time at a cost of 64 Kbps, leaving another 64 Kbps free for that
3.5 minutes, plus an additional 128 Kbps for the remaining 6.5 minutes. Based on this simple
estimate, another three or four calls could easily fit into the space used by a single call under the
conventional system.
To convert analogue waveforms into digital information, both PSTN and VoIP solutions use
Codec’s or voice coder-decoder to do this. The process that achieves this conversion is complex
and well beyond the scope of this paper. For the purposes of this work, however, it is sufficient to
say that there are many ways to transform an analogue voice signal – all of which are governed
by industry standards and most of which are based on PCM.
Each encoding scheme has its own bandwidth needs based on its compression capabilities.
Table 1 lists some of the more important encoding standards covered by the ITU-T.
Table 1.1: ITU-T Encoding Standards
71
The signalling protocols implemented in a VoIP solution determine the features and functionality
available, as well as the way in which the VoIP solution components interact with one another.
Currently, a variety of VoIP protocols and implementations with a wide range of features are in
use, like SIP, H.323, MGCP and H.248.
In this work we use the IETF’s signaling protocol, SIP, to handle the setup and tear down of
multimedia sessions between endpoints. This lightweight, text-based signalling protocol is
transported over either Transmission Control Protocol (TCP) or UDP. SIP uses invitations to
create Session Description Protocol (SDP) messages to carry out capability exchange and to
setup call control channel use. These invitations allow participants to agree on a set of compatible
media types. The powerful SIP client-server application supports user mobility with two operating
modes: proxy and redirect. In proxy mode used in this work (shown in Figure X), SIP clients send
requests to the proxy server. The proxy server either handles the requests or forwards them to
other SIP servers.
When the SIP server is operating in redirect mode, the SIP client sends its signalling request to a
SIP server, which then looks up the destination address. The SIP server returns the destination
address to the originator of the call, who uses it to signal the destination SIP client.
Fig. 1.2: SIP Proxy Operation
The ability to proxy and redirect requests to the end user’s current location is critical to supporting
a highly mobile voice user base. SIP enables users to inform the SIP server of their current
location (IP address or URL) by sending a registration message to a registrar.
72
To complete a call, two endpoints must be able to open and sustain a communication session.
The public or private switches in the PSTN complete calls by connecting logical Digital Signal-0
(DS0) channels through the network. Each DS-0 is a 64 Kbps bi-directional channel that the
PSTN dedicates exclusively to the communication session for the duration of the call. The PSTN
uses Pulse Code Modulation (PCM) to represent analogue audio frequencies, enabling the
network to transmit the audio payload through these DS-0 channels as a digitally encoded pulse
amplitude value.
Like the PSTN, VoIP networks use PCM to encode the audio payload. However, instead of
transmitting the audio payload directly over a dedicated DS-0 channel, VoIP networks transport
the audio payload using shared network resources. To complete a connection, VoIP networks
place a set of one or more PCM samples, known as frames, into an IP datagram. The VoIP
solution formats the datagram’s according to the Real-Time Transport Protocol (RTP), and then
forwards them over a routed or packet-forwarded IP network. Because the IP network does not
allocate resources specifically for these RTP packets, ensuring high-quality VoIP communications
can pose a significant challenge to service providers and enterprises. The issues associated with
ensuring VoIP service quality is the scope of this work, we try to ensure the service quality using
our Admission control Model.
73
ANNEX 2 - VoD
Video on demand (VoD) systems allow users to select and watch video contents over a network
as part of an interactive television system. VoD systems either stream contents, allowing viewing
in real-time, or download it in which the program is brought in its entirety to a set-top box before
viewing starts.
Often, nowadays, the term encompasses a broader spectrum of delivery devices, referring not
only to set-top-boxes but also computers, mobile phones and indeed any system that can receive
on-demand audio-visual content over a network.
It is possible to put video servers on LANs, in which case they can provide very rapid response to
users. Streaming video servers can also serve a wider community via a WAN, in which case the
responsiveness may be reduced. Download VoD services are practical to homes equipped with
cable modems or DSL connections.
For streaming this type of service in the network we need bandwidth. This required bandwidth
can vary between 0, 5 Mbit/s to 9 Mbit/s depending on the video codec used (MPEG-2, MPEG-4
or DVD). If we want to test VoD we just need a small LAN, a Video Server and a client (for
example a Computer), the protocol used to stream the contents to the network shall be Real-time
Service Protocol (RSTP).
Like is explained before, this service can be a Real-time service. For that we need some QoS
guarantees, that issue is the scope of this work. We try to use Admission Control to verify if a new
session of VoD in the network can be established with good Quality.
Fig. 2.1: Possible VoD Scenario with Resource Control
74
ANNEX 3 - SIP
Session Initiation Protocol (SIP) is an application-layer control (signalling) protocol for creating,
modifying, and terminating sessions with one or more participants. It can be used to create twoparty, multiparty, or multicast sessions that include Internet telephone calls, multimedia
distribution, and multimedia conferences. SIP is designed to be independent of the underlying
transport layer. It can run on TCP, UDP or SCTP. It is widely used as a signalling protocol for
Voice over IP, along with H.323 and others.
Protocol Design
SIP clients use TCP or UDP (typically on port 5060) to connect to SIP servers and other SIP
endpoints. SIP is primarily used in setting up and tearing down voice or video calls. However, it
can be used in any application where session initiation is a requirement. These include Event
Subscription and Notification, Terminal mobility and so on. There are a large number of SIPrelated RFCs that define behaviour for such applications. All voice/video communications are
done over separate session protocols, typically RTP.
A motivating goal for SIP was to provide a signalling and call setup protocol for IP-based
communications that can support a superset of the call processing functions and features present
in the public switched telephone network (PSTN). SIP by itself does not define these features;
rather, its focus is call-setup and signalling. However, it has been designed to enable the building
of such features in network elements known as Proxy Servers and User Agents. These are
features that permit familiar telephone-like operations: dialling a number, causing a phone to ring,
hearing ring back tones or a busy signal. Implementation and terminology are different in the SIP
world but to the end-user, the behaviour is similar.
SIP works in concert with several other protocols and is only involved in the signalling portion of a
communication session. SIP acts as a carrier for the Session Description Protocol (SDP), which
describes the media content of the session, e.g. what IP ports to use, the codec being used etc.
In typical use, SIP "sessions" are simply packet streams of the Real-time Transport Protocol
(RTP). RTP is the carrier for the actual voice or video content itself.
75
SIP Call Flow
In this section a call will be analyzed in detail. In a SIP call there are several SIP transactions. A
SIP transaction consists of several requests and answers and the way to group them in the same
transaction is by means of CSeq parameter.
Fig. 3.1: The SIP Call Flow
- The first step is the user register: The users must register themselves to be found by other
users. In this case, the terminals send a REGISTER request, where the fields "from" and "to"
correspond to the registered user. The Proxy sends an OK message if there is no problem.
-The following transaction corresponds to a session establishment: This session consists of
an INVITE request of the user to the proxy. Immediately, the proxy sends a TRYING 100 to stop
the broadcastings and reroute the request to the B user. The B user sends a Ringing 180 when
the telephone begins to ring and it is also reroute by the proxy to the A user. Finally, the OK 200
message
corresponds
to
the
accept
process
(the
user
B
response
the
call).
76
-At this moment the call is established, and the RTP transport protocol starts with the
parameters
(ports,
addresses,
codecs,
etc.)
of
the
SDP
protocol.
-The last transaction corresponds to a session end: This is carried out with an only BYE
request to the Proxy, and later reroute to the B user. This user replies with an OK 200 message
to confirm that the final message has been received correctly.
SDP
Session Description Protocol (SDP) is the protocol used to describe multimedia session
announcement, multimedia session invitation and other forms of multimedia session initiation.
A multimedia session is defined, for these purposes, as a set of media streams that exist for
duration of time.
SDP packets usually include the following information:
Session information:
- Session name and purpose.
- Time(s) the session is active.
Since the resources necessary for participating in a session may be limited, it would be useful to
include the following additional information:
- Information about the bandwidth to be used by the session(related to used codec’s).
- Contact information for the person responsible for the session.
Media information:
- Type of media, such as video and audio.
- Transport protocol, such as RTP/UDP/IP and H.320
- Media format, such as H.261 video and MPEG video.
77
ANNEX 4 - RTP
The Real-time Transport Protocol (or RTP) defines a standardized packet format for delivering
audio and video over the Internet. It was developed by the Audio-Video Transport Working Group
of the IETF and published by RFC 3550.
RTP is generally configured to use ports 16384-32767 and he can carry any data with real-time
characteristics, such as interactive audio and video. Call setup and tear-down is usually
performed by the SIP protocol. The fact that RTP uses a dynamic port range makes it difficult for
it to traverse firewalls. In order to get around this problem, it is often necessary to set up a STUN
server.
It was originally designed as a multicast protocol, but has since been applied in many unicast
applications. It is frequently used in streaming media systems (in conjunction with RTSP) as well
as videoconferencing and push to talk systems (in conjunction with H.323 or SIP), making it the
technical foundation of the Voice over IP industry. Applications using RTP are less sensitive to
packet loss, but typically very sensitive to delays, so UDP is a better choice than TCP for such
applications.
The services provided by RTP include:
- Payload-type identification: Indication of what kind of content is being carried.
- Sequence numbering: PDU sequence number.
- Time stamping: Allow synchronization and jitter calculations.
- Delivery monitoring
The protocols themselves do not provide mechanisms to ensure timely delivery. They also do not
give any Quality of Service (QoS) guarantees. These things have to be provided by some other
mechanism.
Also, out of order delivery is still possible, and flow and congestion control are not supported
directly. However, the protocols do deliver the necessary data to the application to make sure it
can put the received packets in the correct order.
The position of RTP in the protocol stack is somewhat strange. It was decided to put RTP in user
space and have it (normally) run over UDP. It operates as follows. The multimedia application
consists of multiple audio, video, text, and possibly other streams. These are fed into the RTP
library, which is in user space along with the application. This library then multiplexes the streams
78
and encodes them in RTP packets, which it then stuffs into a socket. At the other end of the
socket (in the operating system kernel), UDP packets are generated and embedded in IP
packets. If the computer is on an Ethernet, the IP packets are then put in Ethernet frames for
transmission. As a consequence of this design, it is a little hard to say which layer RTP is in.
Since it runs in user space and is linked to the application program, it certainly looks like an
application protocol. On the other hand, it is a generic, application-independent protocol that just
provides transport facilities, so it also looks like a transport protocol. Probably the best description
is that it is a transport protocol that is implemented in the application layer.
79
ANNEX 5 - RSTP
The Real-time Streaming Protocol (RTSP), developed by the IETF, is a protocol for use in
streaming media systems which allows a client to remotely control a streaming media server,
issuing VCR-like commands such as “play” and “pause”, and allowing time-based access to files
on a server.
The most RTSP servers use the standard-based RTP as the transport protocol for the actual
audio/video data, acting somewhat as a metadata channel.
The protocol is similar in syntax and operation to HTTP but RTSP adds new requests. While
HTTP is stateless, RTSP is a stateful protocol. A session ID is used to keep track of sessions
when needed. This way, no permanent TCP connection is needed. RTSP messages are sent
from client to server, although some exceptions exist where the server will send to the client.
Below are the basic RTSP requests. A number of typical HTTP requests, like an OPTION
request, are also frequently used.
A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply data that can be
handled. The default port for the RTSP protocol is 554 for both UDP and TCP transports.
The reply includes the presentation description, typically in SDP format. Among other things, the
presentation description lists the media streams controlled with the aggregate URL. In the typical
case, there is one media stream for audio and one for video.
A SETUP request specifies how a single media stream must be transported. This must be done
before a PLAY request is sent.
The request contains the media stream URL and a transport specifier. This specifier typically
includes a local port for receiving RTP data (audio or video), and another for RTCP data (Meta
information).
The server reply usually confirms the chosen parameters, and fills in the missing parts, such as
the server's chosen ports. Each media stream must be configured using SETUP before an
aggregate play request may be sent.
We also can have a PLAY request that will cause one or all media streams to be played, a
PAUSE request that temporarily halts one or all media streams, a RECORD request that can be
80
used to send a stream to the server for storage and a TEARDOWN request that terminates a
session.
For example in case of Admission Control we can use the DESCRIBE request to get the
necessary information to send a request for the Network Admission controller in order to verify if a
new session can be streamed with bandwidth guarantees. That issue it will be better explained in
sections below.
81
ANNEX 6 - IP
The Internet Protocol (IP) is a data-oriented protocol used for communicating data across a
packet-switched network. IP is a network layer in the internet protocol suite and is encapsulated
in a data link layer protocol (e.g., Ethernet) like figure 3.1 illustrates. As a lower layer protocol, IP
provides the service of communicable unique global addressing amongst computers.
This protocol is a connectionless protocol, which means that there is no continuing connection
between the end points that are communicating. Each packet that travels through the internet is
treated as an independent unit of data without any relation to any other unit of data. The reason
the packets are put in the right order is because of Transmission Control Protocol (TCP), the
connection-oriented protocol that keeps track of the packet sequence in a message.
The most widely used version of IP today is Internet Protocol Version 4 (IPv4). However, IP
Version 6 (IPv6) is also beginning to be supported. IPv6 provides for much longer address and
therefore for the possibility of many more internet users. IPv6 includes the capabilities of IPv4 and
any server that can support IPv6 packets can also support IPv4 packets.
Fig 6.1: The OSI layer Model
82
ANNEX 7 - Ethernet
The term Ethernet refers to the family of local-area network (LAN) products covered by the IEEE
802.3 standard that defines what is commonly known as the CSMA/CD protocol. Ethernet
connects devices to a company or home network as well as to a cable modem or DSL modem for
internet access.
There are three data rates currently defined for operation in Ethernet ports and a fourth under
development. A 10/100 Ethernet port supports two speeds: 10 Mbps (10BaseT) and 100 Mbps
(100BaseT), Gigabit Ethernet (GigE) supports 1000 Mbps and is commonly used as a high-speed
link between switches and servers in LAN backbone systems, 10 – Gigabit Ethernet is the new
rate in development. Ethernet devices negotiate with each other and transmit at the highest
speed possible. However, if a 100 Mbps switch is communicating with a 10 Mbps client, the
slower speed is used.
The most used physical medium is the twisted pair cables and standard RJ-45 connectors, but to
extend distances fiber-optic cable is also used.
This data link protocol (layer 2 of the OSI model) transmits variable length frames from 72 to 1518
bytes, each containing a header with the addresses of the source and destination stations and a
trailer that contains error correction data. Higher-level protocols, such as IP, fragment long
messages into the frame size required by the Ethernet network being employed. The Ethernet
uses the CSMA/CD technology to broadcast each frame onto the physical medium (wire, fiber,
etc), because devices are connected to the cable and compete for medium access. All stations
attached to the Ethernet are “listening,” and the station with the matching destination address
accepts the frame and checks for errors.
XSTP
The Spanning-Tree Protocol was introduced by the IEEE as 802.1D and is a link management
protocol that provides path redundancy while undesirable loops in the network. For an Ethernet
network to function properly, only one active path can exist between two stations.
83
Multiple active paths between stations cause loops in the network. If a loop exists in the network
topology, the potential exists for duplication messages. When loops occur, some switches see
stations appear on both sides of the switch. This condition confuses the forwarding algorithm and
allows duplicate frames to be forwarded.
To provide path redundancy, Spanning-Tree Protocol defines a tree that spans all switches in an
extended network. Spanning-Tree Protocol forces certain redundant data paths into a standby
(blocked) state. If one network segment in the Spanning-Tree Protocol becomes unreachable, or
STP costs change, the spanning-tree algorithm reconfigures the spanning-tree topology and reestablishes the link by activating the standby path.
Spanning-Tree Protocol operation is transparent to end stations, which are unaware whether they
are connected to a single LAN segment or a switched LAN of multiple segments.
The STP has been around for some times and may still seem perfectly. However, by today’s
standards it is very slow. This slowness is the result of its re-convergence time, which can take 30
to 50 seconds. Since STP is so slow, it’s not practical for today’s applications and then a faster
protocol is needed.
The Rapid Spanning Tree Protocol (RSTP) was introduced by the IEEE as 802.1w. RTSP is
based upon the older STP standard and is backward compatible. RSTP and STP are similar in
many areas. RSTP was created to provide faster recovery (convergence time) from topology
changes.
This protocol provides faster recovery by monitoring the link status of each port and then
generating a topology change after a link status change.
In the case there is only one VLAN in the network like is explained in the previous section, single
STP or RSTP works appropriately. However, if the network contains more than one VLAN, the
logical network configured by single STP does not work.
84
Fig. 7.1: No path for VLAN 2 because of STP
The figure 7.1 shows the case where there are two VLANs in the network but only single STP is
enabled. Here you can see there is no path for VLAN 2 between the switches because STP has
blocked all the paths belonging to VLAN 2. Thus, a node in VLAN 2 of Switch #1 cannot
communicate with other nodes belonging to VLAN 2 in Switch #2.
To avoid this problem, one of the blocked links has to be active for VLAN 2.This will not cause a
network loop because no broadcast packets or any other traffic can get through the VLAN
borders, so there will be no logical loop between VLAN 1 and VLAN 2.
The Multiple Spanning Tree Protocol (MSTP) is another variant of STP and configures a separate
Spanning Tree for each VLAN and blocks the links that are redundant within each Spanning Tree.
Fig. 7.2: Multiple STP enabled
The figure 7.2 shows the two-VLAN network of figure 7.1 with Multiple STP enabled. Now VLAN 2
has an active communication path between Switches #1 and #2, with a redundant path that is
blocked but available in case the main path fails. There are no redundant paths between the
switches in VLAN 1, so STP action is necessary for VLAN 1.
85
ANNEX 8 - VLAN
A virtual LAN, commonly known as a VLAN, is a method of creating independent logical networks
within a physical network. Several VLANs can co-exist within such a network. This helps in
reducing the broadcast domain and aids in network administration by separating logical segments
of a LAN (like a service or subscriber) that should not exchange data using a LAN.
A VLAN is also a logical group of end-stations which appear to be on the same LAN regardless of
their physical location or connection point in the network. Thus users can share information and
resources as though located on the same LAN. VLANs are configured so that they can
communicate as if they were attached to the same physical connection, although they are in fact
located on a number of different LAN segments. A router is needed to forward traffic between
VLANs. Because VLANs are based on logical rather than physical connections, they are
extremely flexible.
In the context of Carrier Ethernet, VLANs are used by the service provider to identify different
customers or different services.
The Virtual LANs operate at Layer 2 (the data link layer) of the OSI model. However,
administrators often configure a VLAN to map directly to an IP network, or subnet, which gives
the appearance of involving Layer 3 (the network layer).
Traffic Management and QoS Network Policies
A network which offers quality of service has the ability to deliver data traffic with minimum delay
in an environment in which multiple users share the same network.
Basically, traffic management is the attempt to minimize congestion within a network. More
specifically, it is a method to separately monitor and control network application traffic by
allocating bandwidth (BW) based on need and delivery requirements. Network operators need to
support multiple service types – such as voice, data and video – on a variety of physical
infrastructures with maximum efficiency.
The network policies are a set of rules that should be applied to a particular traffic flow allowing
network service providers to implement packet forwarding and routing specifically tailored to their
86
customer’s requirements. Using policy management, they can implement policies that selectively
cause packets to take different paths.
Policy management enables them to selectively forward and route packets according to the
requirements. It uses policy routing to predefine a packet flow to a destination port without
performing a routing table lookup.
87
ANNEX 9 - XDSL
The digital subscriber line (XDSL) is a family of technologies that provide digital data transmission
over the wires of local telephone network.
The download speed of consumer DSL services ranges from 256 Kbit/s to 24 Mbit/s, like figure
10.1 illustrate, depending on DSL technology, line conditions and service level implemented.
Typically, upload speed is lower than download speed for Asymmetric Digital Subscriber Line
(ADSL) and equals to download speed for Symmetric Digital Subscriber Line (SDSL).
Some variants of DSL connections, like ADSL and VDSL, typically work by dividing the
frequencies used in a single phone line into two primary “bands”. The Internet Service Provider
(ISP) data is carried over the high frequency band (25 KHz and above) whereas the voice is
carried over the lower frequency band (4 KHz and below). The user typically installs a DSL filter
on each phone, this filter out the high frequencies (the human voice) and creating two
independent’s “bands”. Thus the DSL modem and the phone can simultaneously use the same
phone line without interfering with each other.
Technology
Transmission Rates
IDSL
128 Kbps, symmetric
ADSL (ADSL2, ADSL2+)
Down: 1.5 a 24 Mbps
Up: 16 a 1024 Kbps
UDSL
Down: 1.5 Mbps
ADSL Lite
Up: 500 Kbps
HDSL
ETSI : to 2.048 Mbps
EUA: to 1.544 Mbps
SHDSL/SDSL
192 Kbps to 2.3 Mbps
VDSL
Max. 52 Mbps
Fig. 9.1: XDSL Rates
88
ANNEX 10 - Resource Reservation Request Information
Resource Req ( PDF -> RCF)
Application Function Identifier Global unique Identifier for the application function
instance.
Resource Reservation
The reference is a unique resource reservation session
Session ID
identifier in the scope of the Application Function
Identifier.
Subscriber-ID
It identifies the subscriber attached to the access
(optional)
network.
Globally Unique IP Address
(optional)
Assigned IP Address
Address Realm
Requestor Name
Service Class
Service Priority (optional)
Duration of Reservation
(optional)
Media Description
Media Type
Media Id
Media Priority (optional)
Traffic Flow Parameters
Direction
Flow Id
IP Addresses
Ports
Protocol
Bandwidth
Reservation Class
(optional)
Commit Id
Globally Unique address that corresponds to the UNI
associated to the subscriber attached to the network.
The IP address [Ipv4 or Ipv6]
The addressing domain in which the IP address is
significant.
Identifies the NAC client requesting the resources (e.g.
name of a ASP or group of ASPs). This name
corresponds to the Requestor Name in a QoS profile
provided by NASS.
Service class requested by the PDF. It reflects the
service relationship between the RCF and PDF owners.
The set of Service Classes that are offered to an PDF is
an administrative matter.
The priority associated to the service request that
defines the handling precedence by the receiving entity.
Duration of the reservation requested by the client.
The media description.
The pre-defined type of the media for each flow (e.g.
Video).
Identifier for the specific media.
The priority associated to the media to be used in the
admission control process in RCF.
The traffic flow description of the media.
Direction of the flow.
Identifier for the specific flow.
Source and Destination IP addresses [Ipv4, Ipv6] and
Address Realm that each address belongs to.
Source and Destination Port Numbers.
Protocol Id (e.g. UDP, TCP).
The maximum request bit rate.
A particular index that identifies a set of traffic
characteristics of the flow (e.g. burstiness and packet
size).
Identify if request is to be committed.
Table 10.1: Resource Reservation Request - Information Elements
89
ANNEX 11 - Resource Modification Request Information
Resource Mod ( PDF -> RCF)
Application Function Identifier Global unique Identifier for the application function
instance.
Resource Reservation Session The reference is a unique resource reservation
ID
session identifier in the scope of the Application
Function (AF) Identifier.
Requestor Name
Identifies the NAC client requesting the resources
(e.g. name of a ASP or group of ASPs). This name
corresponds to the Requestor Name in a QoS profile
provided by NASS.
Service Class
Service class requested by the PDF. It reflects the
service relationship between the RCF and PDF
owners. The set of Service Classes that are offered to
an PDF is an administrative matter.
Duration of Reservation
Duration of the reservation requested by the client.
(optional)
Charging Correlation
Globally unique identifier for charging correlation
Information (optional)
purposes.
Service Priority (optional)
The priority associated to a service request that
defines the handling precedence by the receiving
entity.
Media Description
The media description.
Media Type
The pre-defined type of the media for each flow (e.g.
Video).
Media Id
Identifier for the specific media.
Media Priority (optional)
The priority associated to the media to be used in the
admission control process in RCF.
Traffic Flow Parameters
The traffic flow description of the media.
Direction
Direction of the flow.
Flow Id
Identifier for the specific flow.
IP Addresses
Source and Destination IP addresses [Ipv4, Ipv6] and
Address Realm that each address belongs to.
Ports
Source and Destination Port Numbers.
Protocol
Protocol Id (e.g. UDP, TCP).
Bandwidth
The maximum request bit rate.
Reservation Class
The particular index that identifies a set of traffic
(optional)
characteristics of the flow (e.g. burstiness and packet
size).
Transport Service Class Identifies the forwarding behaviour to be applied to
(optional)
the particular flow.
Commit Id
Identify if request is to be committed.
Table 11.1: Resource Modification Request - Information Elements
90
ANNEX 12 - Resource Release and Abort Request
Information
Resource Rel (PDF-> RCF)
Application Function Identifier
Global unique Identifier for the application function
instance.
Resource Reservation Session The reference is a unique session identifier in the
ID
scope of the Application Function Identifier (see
note).
NOTE: The presence of a wildcard in the session part of the reference indicates that
all resources identified associated to the Application Function Identifier shall
be released, otherwise only the specific session is released (it implies all
media in the session).
Table 12.1: Resource Release - Information Elements
Abort Res (RCF -> PDF)
Application Function Identifier
Global unique Identifier for the application
function instance.
Resource Reservation Session ID
The reference is a unique Resource
Reservation session identifier in the scope of
the Application Function Identifier.
Resource Bundle-Id (optional)
It represents a set of resource reservation
sessions grouped together by RCF policies. It
shall be possible to represent a hierarchy of
resources in the resource Bundle-Id associated
to that particular NAC resource reservation
session.
Time Stamp
The time when the resources were lost.
Cause
The cause that lead to the loss of the
reservation.
Table 12.2: Abort Reservation- Information Elements
91
ANNEX 13 - PolicyDecisionFunction UML
92
ANNEX 14 - Session UML
93
ANNEX 15 - Resource Control Function UML
94
ANNEX 16 - Link Edge UML
ANNEX 17 - Network Graph UML
ANNEX 18 - NE Vertex UML
95
ANNEX 19 - Association UML
ANNEX 20 - BRAS UML
96
ANNEX 21 - DSLAM UML
ANNEX 22 - EthBRAS UML
97
ANNEX 23 - EthPort UML
ANNEX 24 - Link UML
98
ANNEX 25 - Switch UML
ANNEX 26 - Traffic Classifier UML
99
ANNEX 27 - XdslPort
100
ANNEX 28 - DOM UML
101
ANNEX 29 - NASS.xml
<?xml version="1.0"?>
<NASS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="NASS.xsd">
<DSLAM>
<DSLAMid>1</DSLAMid>
<Xdslport>
<Id>1</Id>
<IPaddress>192.168.1.1</IPaddress>
</Xdslport>
<Xdslport>
<Id>2</Id>
<IPaddress>192.168.1.2</IPaddress>
</Xdslport>
<Xdslport>
<Id>3</Id>
<IPaddress>192.168.1.3</IPaddress>
</Xdslport>
</DSLAM>
<DSLAM>
<DSLAMid>2</DSLAMid>
<Xdslport>
<Id>1</Id>
<IPaddress>192.168.2.1</IPaddress>
</Xdslport>
<Xdslport>
<Id>2</Id>
<IPaddress>192.168.2.2</IPaddress>
</Xdslport>
<Xdslport>
<Id>3</Id>
<IPaddress>192.168.2.3</IPaddress>
</Xdslport>
</DSLAM>
</NASS>
102
ANNEX 30 - Physical-Logic_Model.xml
<?xml version="1.0"?>
<!--Modelo Físico/Lógico da rede-->
<Physical-Logic_Network_Model xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xsi:noNamespaceSchemaLocation="Physical-Logic_Model.xsd">
<!--Informação relativa aos portos Xdsl do DSLAM 1-->
<DSLAM>
<DSLAMid>1</DSLAMid>
<Xdslport>
<Id>1</Id>
<IPaddress>192.168.1.1</IPaddress>
<Capacity>100</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
</Trafficlassifier>
</Xdslport>
<Xdslport>
<Id>2</Id>
<IPaddress>192.168.1.2</IPaddress>
<Capacity>100</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>4</VlanId>
</Trafficlassifier>
</Xdslport>
<!--Informação relativa aos portos de Uplink do DSLAM 1-->
<Ethernetport>
<Id>201</Id>
<Capacity>100</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>202</Id>
103
<Capacity>100</Capacity>
<State>inactive</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
</DSLAM>
<!--Informação relativa aos portos Xdsl do DSLAM 2-->
<DSLAM>
<DSLAMid>2</DSLAMid>
<Xdslport>
<Id>1</Id>
<IPaddress>192.168.1.3</IPaddress>
<Capacity>100</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
</Trafficlassifier>
</Xdslport>
<Xdslport>
<Id>2</Id>
<IPaddress>192.168.1.4</IPaddress>
<Capacity>100</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>4</VlanId>
</Trafficlassifier>
</Xdslport>
<!--Informação relativa aos portos de Uplink do DSLAM 2-->
<Ethernetport>
<Id>201</Id>
<Capacity>100</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
104
<Ethernetport>
<Id>202</Id>
<Capacity>100</Capacity>
<State>inactive</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
</DSLAM>
<!-->Informação Física/Lógica Relativa aos portos de cada Switch-->
<Switch>
<SWITCHid>3</SWITCHid>
<Ethernetport>
<Id>1</Id>
<Capacity>1000</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>2</Id>
<Capacity>1000</Capacity>
<State>inactive</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>3</Id>
<Capacity>1000</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>4</Id>
105
<Capacity>1000</Capacity>
<State>inactive</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
</Switch>
<Switch>
<SWITCHid>4</SWITCHid>
<Ethernetport>
<Id>1</Id>
<Capacity>1000</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>2</Id>
<Capacity>1000</Capacity>
<State>inactive</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>3</Id>
<Capacity>1000</Capacity>
<State>active</State>
<Trafficlassifier>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>4</Id>
<Capacity>1000</Capacity>
<State>inactive</State>
<Trafficlassifier>
106
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
</Switch>
<!-->Informação Física/Lógica relativa ao BRAS-->
<BRAS>
<BRASid>5</BRASid>
<IPaddress>192.168.1.255</IPaddress>
<Ethernetport>
<Id>1</Id>
<Capacity>1000</Capacity>
<State>active</State>
<!-->IPaddress e respectiva capacidade maxima associada ao endereço (traffic
classifiers)-->
<Trafficlassifier>
<IPaddress>192.168.1.1</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
<Trafficlassifier>
<IPaddress>192.168.1.2</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
<Trafficlassifier>
<IPaddress>192.168.1.3</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
<Trafficlassifier>
<IPaddress>192.168.1.4</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
<Ethernetport>
<Id>2</Id>
<Capacity>1000</Capacity>
107
<State>inactive</State>
<!-->IPaddress e respectiva capacidade maxima associada ao endereço (traffic
classifiers)-->
<Trafficlassifier>
<IPaddress>192.168.1.1</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
<Trafficlassifier>
<IPaddress>192.168.1.2</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
<Trafficlassifier>
<IPaddress>192.168.1.3</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
<Trafficlassifier>
<IPaddress>192.168.1.4</IPaddress>
<IPaddressMaxCapacity>100</IPaddressMaxCapacity>
<VlanId>3</VlanId>
<VlanId>4</VlanId>
</Trafficlassifier>
</Ethernetport>
</BRAS>
<Physical_Links>
<!--Links físico dos DSLAMS-->
<Link>
<NeId>1</NeId>
<EthernetportId>201</EthernetportId>
<NeId>3</NeId>
<EthernetportId>1</EthernetportId>
</Link>
<Link>
<NeId>1</NeId>
<EthernetportId>201</EthernetportId>
<NeId>3</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
<Link>
108
<NeId>1</NeId>
<EthernetportId>202</EthernetportId> <!--Porto de redundância do DSLAM->
<NeId>3</NeId>
<EthernetportId>1</EthernetportId>
</Link>
<Link>
<NeId>1</NeId>
<EthernetportId>202</EthernetportId> <!--Porto de redundância do DSLAM->
<NeId>3</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
<Link>
<NeId>2</NeId>
<EthernetportId>201</EthernetportId>
<NeId>4</NeId>
<EthernetportId>1</EthernetportId>
</Link>
<Link>
<NeId>2</NeId>
<EthernetportId>201</EthernetportId>
<NeId>4</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
<Link>
<NeId>2</NeId>
<EthernetportId>202</EthernetportId> <!--Porto de redundância do DSLAM->
<NeId>4</NeId>
<EthernetportId>1</EthernetportId>
</Link>
<Link>
<NeId>2</NeId>
<EthernetportId>202</EthernetportId> <!--Porto de redundância do DSLAM->
<NeId>4</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
<!--Links físicos do BRAS-->
<Link>
<NeId>5</NeId>
<EthernetportId>1</EthernetportId>
<NeId>3</NeId>
<EthernetportId>3</EthernetportId>
</Link>
<Link>
<NeId>5</NeId>
<EthernetportId>1</EthernetportId>
109
<NeId>3</NeId>
<EthernetportId>4</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
<Link>
<NeId>5</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do BRAS-->
<NeId>3</NeId>
<EthernetportId>3</EthernetportId>
</Link>
<Link>
<NeId>5</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do BRAS-->
<NeId>3</NeId>
<EthernetportId>4</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
<Link>
<NeId>5</NeId>
<EthernetportId>1</EthernetportId>
<NeId>4</NeId>
<EthernetportId>3</EthernetportId>
</Link>
<Link>
<NeId>5</NeId>
<EthernetportId>1</EthernetportId>
<NeId>4</NeId>
<EthernetportId>4</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
<Link>
<NeId>5</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do BRAS-->
<NeId>4</NeId>
<EthernetportId>3</EthernetportId>
</Link>
<Link>
<NeId>5</NeId>
<EthernetportId>2</EthernetportId> <!--Porto de redundância do BRAS-->
<NeId>4</NeId>
<EthernetportId>4</EthernetportId> <!--Porto de redundância do Switch-->
</Link>
</Physical_Links>
</Physical-Logic_Network_Model>
ANNEX 31 - Request Resource
The executed tests are the following:
110
1- A resource request without network congestion
a. We have the SipExchange and NAC running in two different computers.
b. We have 2 VoIP clients using a softphone (X-Lite) both of them are registered in the
SoftSwitch (SipExchange) and with the necessary triggers and feature to participate in
the Admission Control process assigned (section 4.2.1).
c. Then we try to make a call from user “A” to user “B”.
2 – A resource request with network congestion
a. We have to put some unrealistic traffic in the network with a traffic generator called
smartbits in order to provoke network congestion, and give that knowledge to NAC
because he just know the traffic correspondent to the calls that he had accepted. It’s
impossible to establish the number of calls that provoke the network congestion, once
that the maximum bandwidth reserved per call can be 9 Mbit/s and the links have 1 Gbit/s
of capacity.
b. When we have simulated network congestion we try to make a call from user “A” to user
“B”.
The obtained results are the following:
In test 1 we can observe that a call was successfully establish after passes the admission control
process in the two lags of that call. In figure 31.1 is a screenshot of the softphone that we use to
perform this test with the message “Call established”. In Annex 32 we can see more detailed the
output of the NAC command log where we can see the verification of the network path and the
new bandwidth values for that path after that call has been established.
In test 2 we try to simulate a scenario where a call was been rejected due to there’s no available
bandwidth in the network. In figure 31.2 is a screenshot of the softphone that we use to perform
this test with the message “Authorization Rejected”. In Annex 33 we can see more detailed the
111
output of the NAC command log where we also can see the admission control process failed for
this call, because the network path for this call don’t have available bandwidth.
c
Fig. 31.1: Call Established
Fig. 31.2: Call Rejected
In the following figure is the NAC command log for the previous situation:
Fig. 31.3: Command Log Output
ANNEX 32 - Release Resource Test
112
The executed test is the following:
1 - A release request from the AF to NAC, to terminate a call.
a. The same steps from test 1/section 6.1.1.1 had been repeated.
b. Then after the call is established, one of the users terminates the call.
This is a simple test just to prove that when a call is terminated by one of the user’s the NAC is
advised to readjust the values of the network path used by this call
In the following figure is the NAC command log for previous test:
Fig. 32.1: Command Log Output
113
ANNEX 33 - Policies Enforcement Test
The executed tests are the following:
1- A resource request without network congestion
c. The same steps from test 1/section 6.1.1.1 had been repeated.
d. We try to have a conversion and verify with ethereal the type of traffic that is passing on
the network.
2- A release request to terminate a call
a.
The same steps from test 1/section 61.1.2 had been repeated.
b. Then it was verified that the traffic for the participants of the calls has been blocked.
The obtained results are the following:
This is a simple but important test because in out network we have to configure the BRAS in
order to block almost all the traffic of the subscribers except the SIP traffic to the SoftSwitch. In
that way we can guarantee that clients just send to network other type of traffic (rtp traffic in this
case) after a call has been established.
In test 1 we can observe that after the call be established, the 2 participants of that can talk one
with each other, in other words they can send rtp traffic to network.
In test 2 we can observe that after the termination of the call the traffic coming for the participants
is blocked, except the SIP traffic to the SoftSwitch in order to start a new call for example.
After all these tests we can conclude that our NAC implementation is valid because all the
features implemented works like was expected.
114
References
[1] ETSI-TISPAN: NGN Functional Architecture; (RACS); Release 1
[1] ETSI-TISPAN: Generic NGN Access Architecture System Description.
[1] ETSI ES 282 003 V1.1.1: Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN).
[1] ETSI ES 283 018 v1.1.1: Resource and Admission Control: H.248 Profile for controlling
Border Gateway Functions (BGF).
[1] ETSI ES 283 026 v1.1.1: Protocol for QoS reservation information exchange between the
Service Policy Decision Function (SPDF) and the Access-Resource Admission Control Function
(A-RACF).
[1] ETSI ES 183 017: DIAMETER protocol for session based policy set-up information exchange
between the Application Function (AF) and the Service Policy Decision Function (SPDF).
[2] 3GPP TS 23.107: Quality of Service (QoS) concept and architecture: TS 23.107 V6.2.0
[2] 3GPP TS 23.207: Technical Specification Group Services and System Aspects; End-to-end
Quality of Service (QoS) concept and architecture.
[3] ITU-T FGNGN-OD-00165: QoS Control Architecture for IP access networks.
115
[3] ITU-T FGNGN-OD-00168: Performance Measurement and Management for NGN.
[3] ITU-T FGNGN-OD-00169: Algorithms for Achieving End to End Performance Objectives.
[4] Packet Cable: Multi-media architecture for Admission Control.
[5] Multi Service Forum TR-ARCH-001: Next-Generation VoIP Network Architecture.
[5] Multi Service Forum TR-ARCH-005: Bandwidth Management in Next-Generation Networks.
[6] www.cafesip.org
[7] www.traffixsystems.com
[8] www.jung.org
116