Moby Dick Consolidated System Integration Plan

Moby Dick Consolidated System Integration Plan Moby Dick Consolidated System Integration Plan

kt.agh.edu.pl
from kt.agh.edu.pl More from this publisher
27.03.2014 Views

D0103v1.doc Version 1 6.7.2003 FDTariffS2 UNSIGNED TINYINT UNSIGNED TariffID (i.e. tariff) that will be applied, when a customer will use this service in his FOREIGN domain. ... No … … … … … FDTariffS6 TINYINT UNSIGNED ... No Table 20: Generic Moby Dick User Profile In order to allow a user the usage of applications and services in both, home network and foreign network, information about the user is necessary and services for authentication, authorization and accounting purpose. An AAAC service provides the needed information to authenticate a user and to establish authorized network service for a user. A main idea of a distributed AAAC service is that all data associated with users are stored centralized in the user database. All data in this database associated with the same user is called user profile of this user. 4.5.1.3 User Profile Distribution A User Profile generally is stored in a repository “close” to the AAAC.h server. Within this context, “closed” means that the AAAC.h server has all access capabilities to this repository required for Authentication and Authorization process. So an interface to the user profiles is the access over the AAAC.h to which a user has registered. After the AAAC.h received an authentication and authorization request over AAA protocol for a usage of an applications or a network service, the AAAC.h retrieves over this interface all needed information from the user profile, in order to make a decision. If the decision is successful the home AAAC server sends in the authentication and authorization response all attributes of the user profiles, which are needed to provide the service to the user. Usually the authentication and authorization decision is made from Home AAAC Server (decision enforcement point). Only the result of the decision and configuration data are send to AAA entity (i.e. AAAC.f), which has generated the authentication and authorization request. The whole user profile is never sent to other AAA entity for privacy and legal issues. Only AAAC.h has full knowledge of the user profile. The conveyance of user profile data over the AAA protocol must be secure. This means that at least data integrity for the end-to-end communication is guaranteed. 4.5.1.4 User Profile Management The User Profiles are stored in the user database of users Home Domain and also all management and maintenance tasks for the user profiles are performed in the home domain. The management and maintenance tasks involved: to create and to delete user profiles and to add, to modify and to delete static attributes. The registration process for a new user creates the user profile. It is assumed that this process is done “offline” and so it is out of the scope of Moby Dick. All these tasks are performed over the management interface to user database. This interface is not standardized in the AAA infrastructure. Usually the user database is stored either in database or in directory service. A user has no direct access to this user profile. To define and implement the management interface for the user database is out of the scope of the Moby Dick project. 4.5.1.5 Network View of user Profile (NVUP) - Global SLAs The following section describes an example NVUP. Name Service Class Relative Priority Service parameters Typical Usage Description SIG AF41 2 Unspecified Signalling (network usage) D0103v1.doc 108 / 168

D0103v1.doc Version 1 6.7.2003 S1 EF 1 Peak BW: 32 kbit/s Real time services S2 AF21 3 CIR: 256 kbit/s Priority (urgent) data transfer S3 AF1* 4 Three drop precedences (kbps): AF11 – 64 AF12 – 128 AF13 – 256 Olympic service (better than BE:streaming, ftp, etc) S4 BE 0 Peak bit rate: 32 kbit/s Best Effort (BE) S5 BE 0 Peak bit rate: 64 kbit/s Best effort S6 BE 0 Peak bit rate: 256 kbit/s Best effort S7 Request AAAC Table 21: SLA Note: 1 is highest priority, 4 lowest. 0 means no priority. 4.5.1.6 Test users – Profile Examples In the following a set of test-users are defined which will be represented in the repository of the database. In the AAAC system. According to this profile specifications the traffic is marked and services are provided. 4.5.1.6.1 Victor User Victor is a user subscribing a high bandwidth “Internet” and a “voice”. He would get a S6, a S1 and the SIG services attributed, no specific destination. Victor has full roaming possibilities, a fixed contract with not budget/quota limitations. The detailed profile can be found in the Annex. 4.5.1.6.2 Eric Eric - user subscribing a “Premium Internet” for company access, a voice and a “Traditional Internet”. It would get the SIG, the S1 and the S5 services, no specific destination, and a S2 with destiny equal to its company address. The detailed profile can be found in the Annex. 4.5.1.6.3 Hans Hans – user subscribing “Flexible Internet”. It would get SIG and S3, no specific destination. Hans is not allowed to roam. So this profile is only valid in the home domain. The detailed profile can be found in the Annex. 4.5.1.6.4 Michelle Michelle – user subscribing “Costless Internet”, “VideoService” and “voice”. It would get a S4, a SIG and a S1, without specific destination, and a S2, directed to a specific videoserver, and for specific protocols. Amardeo is able to roam. The detailed profile can be found in the Annex. 4.5.2 Diameter Entities As shown in Figure 79 the diameter server plays a central role in AAAC architecture. The diameter server maintains interfaces to other AAAC servers, Attendant on the access router, QoS broker via an ASM, and to other backend databases that are used for charging, accounting, policy etc. This section describes the interaction between Mobile Node (MN), Attendant, , AAAC Server foreign (AAAC.f), AAAC Server home (AAAC.h) and the home agent (HA) respectively in the framework of the Moby Dick project. The section further describes the parameters to be used. It is further a functional specification of the interaction between the different entities involved in AAAC and MIP. D0103v1.doc 109 / 168

D0103v1.doc Version 1 6.7.2003<br />

FDTariffS2<br />

UNSIGNED<br />

TINYINT<br />

UNSIGNED<br />

TariffID (i.e. tariff) that<br />

will be applied, when a<br />

customer will use this<br />

service in his FOREIGN<br />

domain.<br />

... No<br />

… … … … …<br />

FDTariffS6<br />

TINYINT<br />

UNSIGNED<br />

... No<br />

Table 20: Generic <strong>Moby</strong> <strong>Dick</strong> User Profile<br />

In order to allow a user the usage of applications and services in both, home network and foreign<br />

network, information about the user is necessary and services for authentication, authorization and<br />

accounting purpose. An AAAC service provides the needed information to authenticate a user and to<br />

establish authorized network service for a user. A main idea of a distributed AAAC service is that all data<br />

associated with users are stored centralized in the user database. All data in this database associated with<br />

the same user is called user profile of this user.<br />

4.5.1.3 User Profile Distribution<br />

A User Profile generally is stored in a repository “close” to the AAAC.h server. Within this context,<br />

“closed” means that the AAAC.h server has all access capabilities to this repository required for<br />

Authentication and Authorization process. So an interface to the user profiles is the access over the<br />

AAAC.h to which a user has registered.<br />

After the AAAC.h received an authentication and authorization request over AAA protocol for a usage of<br />

an applications or a network service, the AAAC.h retrieves over this interface all needed information<br />

from the user profile, in order to make a decision. If the decision is successful the home AAAC server<br />

sends in the authentication and authorization response all attributes of the user profiles, which are needed<br />

to provide the service to the user. Usually the authentication and authorization decision is made from<br />

Home AAAC Server (decision enforcement point). Only the result of the decision and configuration data<br />

are send to AAA entity (i.e. AAAC.f), which has generated the authentication and authorization request.<br />

The whole user profile is never sent to other AAA entity for privacy and legal issues. Only AAAC.h has<br />

full knowledge of the user profile.<br />

The conveyance of user profile data over the AAA protocol must be secure. This means that at least data<br />

integrity for the end-to-end communication is guaranteed.<br />

4.5.1.4 User Profile Management<br />

The User Profiles are stored in the user database of users Home Domain and also all management and<br />

maintenance tasks for the user profiles are performed in the home domain. The management and<br />

maintenance tasks involved: to create and to delete user profiles and to add, to modify and to delete static<br />

attributes. The registration process for a new user creates the user profile. It is assumed that this process is<br />

done “offline” and so it is out of the scope of <strong>Moby</strong> <strong>Dick</strong>. All these tasks are performed over the<br />

management interface to user database. This interface is not standardized in the AAA infrastructure.<br />

Usually the user database is stored either in database or in directory service. A user has no direct access to<br />

this user profile.<br />

To define and implement the management interface for the user database is out of the scope of the <strong>Moby</strong><br />

<strong>Dick</strong> project.<br />

4.5.1.5 Network View of user Profile (NVUP) - Global SLAs<br />

The following section describes an example NVUP.<br />

Name<br />

Service<br />

Class<br />

Relative<br />

Priority<br />

Service parameters<br />

Typical Usage Description<br />

SIG AF41 2 Unspecified Signalling (network usage)<br />

D0103v1.doc 108 / 168

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!