Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
5 Moby Dick Signalling Flow Specification
This chapter reports about the specification of signalling and message flows for initial registration, fast
intra-domain handover, inter-domain handover and Paging with respect to mobility, QoS and AAA. Thus,
this version contains all required information for a reader to understand the way, how the components as
described in the previous chapter will interact in the deployed Moby Dick architecture.
Since the specification allows several possible implementations, the structure of the following section
comprises for all scenarios the functional specification and the detailed implementation specification.
5.1 Assumptions
This section lists the assumptions and specifies the interface between WP2 (QoS), WP3 (Mobility) and
WP4 (AAA), especially with respect to implementation issues, since there is the need for ‘message
combination’ during the Moby Dick key scenarios, which are registration, handover signalling within and
between administrative domains, session setup, paging, Auditing and charging. Interaction and Interfaces
between all involved components as described in the previous chapter have been defined.
5.1.1 Security Associations
Within the current Moby Dick approach, the following security associations are assumed:
Static
MN - AAAC.h
AAAC.h – HA
MN – HA
oARx – nAR
AAAC.f - AAAC.h
AR - AAAC.f
MN – PA
PA - ARx
Dynamic
MN – ARx
MN - PA
Table 45: Security Associations
In the framework of Moby Dick, we assume a security association of neighbour Access Routers within an
administrative domain. This assumption is also part of the fast-handover draft [draft-ietf-mobileip -fastmipv6-03.txt;
section 5.2.1].
This means that dynamic attachment of a user to a domain is out of the scope of Moby Dick. It is assumed
that each user has a fixed home domain where he is registered and when asking for resources, this so
called home domain is asked for enabling this resources vouching for the user towards any visiting
domain.
5.1.2 Distinction: Registration, fast intra-domain and inter-domain handover
There is the need to distinguish between Registration, fast intra-domain and inter-domain handover, since
all the scenarios require different handling / procedures. This section identifies the entity on which the
decision algorithm should be located and presents the parameters on which the decision is based.
Intra-domain handover requires a fast handover procedure (i.e., communication between new Access
Router and old Access Router), while for the registration and for inter-domain handover the involvement
of AAAC.h and Home Agent is required. The reason for this distinction is the assumption, that the
provider of a domain a MN is about to leave, in the following called old domain, has not necessarily any
contractual relationship with the provider of the domain the MN is about to join, in the following called
new domain. But both providers, the provider of the old domain and the provider of the new domain have
a business relationship with the provider of the home domain of the user currently using the MN. Within
the framework of Moby Dick, special focus will be on intra-domain handover, since inter-domain
handovers are expected to occur more rarely and will not be seamless, since the involvement of ‘far
away’ network entities is required.) In order to keep this decision transparent to the Mobile IP stack, it is
suggested to place this decision algorithm ‘below’ Mobile IP (i.e., in the MTNM).
The parameters on which the decision is based are:
• Binding cache (i.e., no entry: registration; valid entry: handover)
• Analysis of the router advertisement prefix, in order to distinguish between intra and interdomain
Several theoretical work is ongoing to extend and to enhance this decision finding process by AAA, QoS
and possibly higher layer input such ay payment preferences and so on.
D0103v1.doc 147 / 168