Moby Dick Consolidated System Integration Plan
Moby Dick Consolidated System Integration Plan Moby Dick Consolidated System Integration Plan
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
- Page 57 and 58: D0103v1.doc Version 1 6.7.2003 4.2.
- Page 59 and 60: D0103v1.doc Version 1 6.7.2003 Even
- Page 61 and 62: D0103v1.doc Version 1 6.7.2003 4.2.
- Page 63 and 64: D0103v1.doc Version 1 6.7.2003 Filt
- Page 65 and 66: D0103v1.doc Version 1 6.7.2003 4.2.
- Page 67 and 68: D0103v1.doc Version 1 6.7.2003 •
- Page 69 and 70: D0103v1.doc Version 1 6.7.2003 The
- Page 71 and 72: D0103v1.doc Version 1 6.7.2003 is t
- Page 73 and 74: D0103v1.doc Version 1 6.7.2003 4.3
- Page 75 and 76: D0103v1.doc Version 1 6.7.2003 4.3.
- Page 77 and 78: D0103v1.doc Version 1 6.7.2003 This
- Page 79 and 80: D0103v1.doc Version 1 6.7.2003 This
- Page 81 and 82: D0103v1.doc Version 1 6.7.2003 4.3.
- Page 83 and 84: D0103v1.doc Version 1 6.7.2003 4.3.
- Page 85 and 86: D0103v1.doc Version 1 6.7.2003 The
- Page 87 and 88: D0103v1.doc Version 1 6.7.2003 4.3.
- Page 89 and 90: D0103v1.doc Version 1 6.7.2003 be u
- Page 91 and 92: D0103v1.doc Version 1 6.7.2003 o Ma
- Page 93 and 94: D0103v1.doc Version 1 6.7.2003 Gene
- Page 95 and 96: D0103v1.doc Version 1 6.7.2003 Upli
- Page 97 and 98: D0103v1.doc Version 1 6.7.2003 Now
- Page 99 and 100: D0103v1.doc Version 1 6.7.2003 3. D
- Page 101 and 102: D0103v1.doc Version 1 6.7.2003 User
- Page 103 and 104: D0103v1.doc Version 1 6.7.2003 Inte
- Page 105 and 106: D0103v1.doc Version 1 6.7.2003 User
- Page 107: D0103v1.doc Version 1 6.7.2003 Serv
- Page 111 and 112: D0103v1.doc Version 1 6.7.2003 The
- Page 113 and 114: D0103v1.doc Version 1 6.7.2003 Old
- Page 115 and 116: D0103v1.doc Version 1 6.7.2003 This
- Page 117 and 118: D0103v1.doc Version 1 6.7.2003 Leng
- Page 119 and 120: D0103v1.doc Version 1 6.7.2003 4.5.
- Page 121 and 122: D0103v1.doc Version 1 6.7.2003 MN M
- Page 123 and 124: D0103v1.doc Version 1 6.7.2003 4.5.
- Page 125 and 126: D0103v1.doc Version 1 6.7.2003 Afte
- Page 127 and 128: D0103v1.doc Version 1 6.7.2003 Pack
- Page 129 and 130: D0103v1.doc Version 1 6.7.2003 4.5.
- Page 131 and 132: D0103v1.doc Version 1 6.7.2003 miss
- Page 133 and 134: D0103v1.doc Version 1 6.7.2003 Conn
- Page 135 and 136: D0103v1.doc Version 1 6.7.2003 4.5.
- Page 137 and 138: D0103v1.doc Version 1 6.7.2003 Acce
- Page 139 and 140: D0103v1.doc Version 1 6.7.2003 Logg
- Page 141 and 142: D0103v1.doc Version 1 6.7.2003 repr
- Page 143 and 144: D0103v1.doc Version 1 6.7.2003 Type
- Page 145 and 146: D0103v1.doc Version 1 6.7.2003 o DM
- Page 147 and 148: D0103v1.doc Version 1 6.7.2003 5 Mo
- Page 149 and 150: D0103v1.doc Version 1 6.7.2003 MN A
- Page 151 and 152: D0103v1.doc Version 1 6.7.2003 3 AA
- Page 153 and 154: D0103v1.doc Version 1 6.7.2003 give
- Page 155 and 156: D0103v1.doc Version 1 6.7.2003 9 Ha
- Page 157 and 158: D0103v1.doc Version 1 6.7.2003 MN 1
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