applying different types of mobility on one network...
TRANSCRIPT
UNIVERSITY OF OSLO
Department of Informatics
Applying different types of mobility on one network (particular case: Mobile IP and SIP)
Maria Selivanova
Cand Scient Thesis
30th of October 2002
i
Foreword This thesis is a part of my Cand Scient degree in Communication systems at the University of Oslo, Department of Informatics. The work has been done in collaboration with TELENOR R&D, where my supervisors have been Frédéric Paint and Do van Thanh.
First of all, I would like to express my largest gratitude to my supervisors, Frédéric Paint and Do van Thanh for continuous encouragement, perfect guidance, meaningful discussions, substantial feedback and constructive critics.
I remain grateful to Endre Skolt who made the collaboration with TELENOR R&D possible.
I would also like to express my thanks to Pål Engelstad for many useful discussions, interesting ideas and helpful explanations.
Thank you to Luis Arturo Flores for new ideas, to Thor Gunnar Eskedal for informative articles, to Kjell Myskvoll, Joar Løvsletten, Erik Lillevold, Erik Gjerdrum, Morten Engelsåstrø, Svein Arnesen, Ivar Jørstad and all the people working in The Wireless World group for a friendly atmosphere and unforgettable teamwork at TELENOR R&D.
Fornebu, 30th of October, 2002
ii
Abstract The importance of mobility nowadays is growing exponentially and who knows what we can expect in future from all the new wireless technologies? Thus there is an inexorable increase in need for mobile networking that is aimed to support the requirements of today’s new class of Internet users as they roam about with sophisticated laptop computers and digital wireless data communication devices. As the number of advanced network services increases and they become more and more available, every network device will take advantage of mobile networking technology to offer maximum flexibility to the customers needing those devices. Actually, it is only imagination, what is setting limitations on what we can expect in future.
Mobile networking technology comprises different mobility aspects, which are described in this thesis. All of these aspects have already been thoroughly studied and possible solutions, supporting each particular type, have been proposed. However, it is unknown how all these solutions will behave when implemented together on one network. We shall through our thesis study this problem on a particular case of terminal mobility and personal mobility, where the first one is supported by Mobile IP and the latter one is supported by SIP.
Mobile IP is an IETF protocol that handles the terminal mobility at the network layer, leaving transport and other higher layers unaffected, so that none of the existing routing mechanisms, hosts and applications need to be modified. In our thesis we give an overview of this protocol, paying special attention to the details that are of vital importance for providing terminal mobility along with the other types of mobility.
The Session Initiation Protocol is an IETF protocol for establishing, modifying and termination multimedia sessions on IP-based network. In our thesis we give an introduction to SIP, and especially focus on its capabilities, which are used for providing personal mobility.
After that we provide four approaches for how these two protocols may interact when being implemented on the same network. For each approach we provide an overview of its functionality and a detailed description of message flow and how these messages are processed by units. All the required additional functionality is highlighted along with the advantages and disadvantages of each approach, provided in the analysis-section.
Last we provide an evaluation of the approaches where we compare them in order to be able to propose the one, which is suited best for being implemented in practice as a solution for the problem.
iii
Contents FOREWORD ..............................................................................................................I
ABSTRACT............................................................................................................... II
CONTENTS .............................................................................................................III
LIST OF FIGURES............................................................................................... VII
LIST OF TABLES................................................................................................... IX
1. INTRODUCTION ............................................................................................... 10 1.1. PROBLEM DEFINITION...................................................................................... 11 1.2. METHODOLOGY ............................................................................................... 12
1.2.1. Theoretical part ....................................................................................... 12 1.2.2. Practical part ........................................................................................... 12
1.3. OUTLINE .......................................................................................................... 13
2. MOBILITY ASPECTS........................................................................................ 14 2.1. CLASSIFICATION ACCORDING TO THE CATEGORY OF USER............................... 14
2.1.1. Personal mobility..................................................................................... 14 2.1.2. Terminal mobility..................................................................................... 15 2.1.3. Application mobility................................................................................. 15 2.1.4. Session mobility ....................................................................................... 15 2.1.5. Role mobility ............................................................................................ 15
2.2. CLASSIFICATION ACCORDING TO THE AVAILABILITY OF SERVICES................... 15 2.2.1. Continuous mobility................................................................................. 16 2.2.2. Discrete mobility...................................................................................... 16
2.3. CORRELATION BETWEEN MOBILITY CLASSES ................................................... 17 2.3.1. Personal continuous mobility .................................................................. 17 2.3.2. Personal discrete mobility ....................................................................... 17 2.3.3. Terminal continuous mobility .................................................................. 17 2.3.4. Terminal discrete mobility ....................................................................... 18 2.3.5. Application continuous mobility .............................................................. 18 2.3.6. Application discrete mobility ................................................................... 18
2.4. INTRODUCING SEVERAL TYPES OF MOBILITY.................................................... 18
3. TERMINAL MOBILITY AND MOBILE IP ................................................... 19 3.1. IP MOBILITY.................................................................................................... 19
3.1.1. Mobility within one subnet....................................................................... 19 3.1.2. Mobility between different subnets .......................................................... 20 3.1.3. The need for Mobile IP ............................................................................ 23
3.2. OVERVIEW OF MOBILE IP ................................................................................ 23 3.2.1. Mobile IP Related Terms ......................................................................... 23
iv
3.2.2. Registration procedure .............................................................................24 3.2.3. Routing in Mobile IP ................................................................................26 3.2.4. TCP performance .....................................................................................28 3.2.5. Dynamic Home Agent...............................................................................28
3.3. BENEFITS OF MOBILE IP ...................................................................................32
4. PERSONAL MOBILITY AND SESSION INITIATION PROTOCOL.........33 4.1. OVERVIEW OF SIP ............................................................................................33
4.1.1. A simple end-to-end user call flow ...........................................................33 4.1.2. SIP servers and clients .............................................................................35 4.1.3. Call flow with SIP Proxy Server...............................................................36 4.1.4. Call flow with SIP Redirect Server...........................................................39 4.1.5. SIP Registration example .........................................................................39 4.1.6. SIP call transfer........................................................................................40
4.2. COMPUTING DESTINATION FOR REQUEST..........................................................42 4.2.1. Fully Qualified Domain Name (FQDN)...................................................42 4.2.2. MN with FQDN ........................................................................................43 4.2.3. MN without FQDN ...................................................................................43
4.3. BENEFITS OF SIP...............................................................................................44
5. PROBLEM DEFINITION...................................................................................45 5.1. CHALLENGES IN IMPLEMENTING MOBILE IP AND SIP ON THE SAME NETWORK45 5.2. ASSUMPTIONS AND LIMITATIONS......................................................................46 5.3. GENERAL NETWORK MODEL............................................................................47
6. APPROACH 1 ......................................................................................................49 6.1. OVERVIEW........................................................................................................49 6.2. DETAILED DESCRIPTION...................................................................................50
6.2.1. Handover “Home Network – Foreign Network” .....................................50 6.2.2. Handover “Foreign Network – Foreign Network”..................................54 6.2.3. Login procedure from Foreign Network ..................................................54
6.3. REQUIRED ADDITIONAL FUNCTIONALITY FOR APPROACH 1.............................55 6.4. ANALYSIS .........................................................................................................56
6.4.1. Complexity ................................................................................................56 6.4.2. Route efficiency.........................................................................................56 6.4.3. Security issues ..........................................................................................56 6.4.4. Handover issues........................................................................................56 6.4.5. Protocol impacts.......................................................................................56 6.4.6. Extensibility ..............................................................................................57
7. APPROACH 2 ......................................................................................................58 7.1. OVERVIEW........................................................................................................58
7.1.1. FA CoA vs. co-located CoA......................................................................59 7.2. DETAILED DESCRIPTION ...................................................................................60
7.2.1. Handover “Home Network – Foreign Network” .....................................60 7.2.2. Handover “Foreign Network – Foreign Network”..................................63 7.2.3. Login procedure from the Foreign Network.............................................64
7.3. REQUIRED ADDITIONAL FUNCTIONALITY FOR APPROACH 2.............................64
v
7.4. ANALYSIS ........................................................................................................ 64 7.4.1. Complexity ............................................................................................... 64 7.4.2. Route efficiency........................................................................................ 64 7.4.3. Security issues.......................................................................................... 65 7.4.4. Handover issues ....................................................................................... 65 7.4.5. Protocol impacts ...................................................................................... 65 7.4.6. Extensibility ............................................................................................. 65
8. APPROACH 3...................................................................................................... 66 8.1. OVERVIEW ....................................................................................................... 66 8.2. DETAILED DESCRIPTION .................................................................................. 67
8.2.1. Handover “Home Network – Foreign Network” .................................... 67 8.2.2. Handover “Foreign Network – Foreign Network” ................................. 68 8.2.3. Login procedure from Foreign Network.................................................. 70
8.3. REQUIRED ADDITIONAL FUNCTIONALITY FOR APPROACH 3 ............................ 71 8.4. ANALYSIS ........................................................................................................ 71
8.4.1. Complexity ............................................................................................... 71 8.4.2. Route efficiency........................................................................................ 72 8.4.3. Security issues.......................................................................................... 72 8.4.4. Handover issues ....................................................................................... 72 8.4.5. Protocol impacts ...................................................................................... 72 8.4.6. Extensibility ............................................................................................. 72
9. APPROACH 4...................................................................................................... 73 9.1. DESCRIPTION ................................................................................................... 73 9.2. WEAK POINTS OF THE ALLOCATION PROCEDURE.............................................. 74
9.2.1. Ongoing session and HA allocation ........................................................ 75 9.2.2. Availability on the new HA. ..................................................................... 76 9.2.3. MN with co-located Care-of Address ...................................................... 76
9.3. MN WITH REGISTERED FQDN......................................................................... 77 9.3.1. Handover “Home Network – Foreign Network” .................................... 78 9.3.2. Handover “Foreign Network – Foreign Network” ................................. 80 9.3.3. Login procedure from the Foreign Network............................................ 81
9.4. MN WITHOUT REGISTERED FQDN .................................................................. 81 9.4.1. Handover “Home Network – Foreign Network” .................................... 81 9.4.2. Handover “Foreign Network – Foreign Network” ................................. 83 9.4.3. Login procedure from the Foreign Network............................................ 83
9.5. REQUIRED ADDITIONAL FUNCTIONALITY FOR APPROACH 4 ............................ 83 9.6. ANALYSIS ........................................................................................................ 85
9.6.1. Complexity ............................................................................................... 85 9.6.2. Route efficiency........................................................................................ 85 9.6.3. Security issues.......................................................................................... 85 9.6.4. Handover issues ....................................................................................... 85 9.6.5. Protocol impacts ...................................................................................... 86 9.6.6. Extensibility ............................................................................................. 86
10. EVALUATION OF THE APPROACHES...................................................... 87 10.1. COMPARATIVE QUALITATIVE ANALYSIS ........................................................ 87
vi
10.1.1. Route Efficiency......................................................................................88 10.1.2. Performance of transport protocols .......................................................88 10.1.3. Additional functionality ..........................................................................88 10.1.4. Handover “Home Network – Foreign Network” ...................................88 10.1.5. Handover “Foreign Network – Foreign Network”................................89 10.1.6. Signalling Overhead...............................................................................89
10.2. CONCLUSION ..................................................................................................89
11. CONCLUSION ...................................................................................................91 11.1. ACHIEVEMENTS AND RESULTS........................................................................91 11.2. CRITICAL REVIEW...........................................................................................92 11.3. FUTURE WORK................................................................................................92
11.3.1. Specification of additional functionality ................................................92 11.3.2. Practical implementation .......................................................................92 11.3.3. Performance of transport protocols .......................................................92 11.3.4. Interaction between SIP, Mobile IP and NAT ........................................93
A. APPENDIX – PREDECESSOR TO SIP: H.323...............................................94 A.1. ELEMENTS OF AN H.323 NETWORK..................................................................94 A.2. H.323 CALL FLOW EXAMPLE............................................................................95 A.3. COMPARISON OF H.323 AND SIP .....................................................................97
B. REFERENCES.....................................................................................................99
vii
List of Figures FIGURE 2-1 MOBILITY CLASSIFICATION ACCORDING TO THE CATEGORY OF USERS..... 14 FIGURE 2-2 CONTINUOUS MOBILITY ........................................................................... 16 FIGURE 2-3 DISCRETE MOBILITY................................................................................. 16 FIGURE 3-1 WIRELESS ACCESS.................................................................................... 19 FIGURE 3-2 NETWORK MODEL FOR THE EXAMPLE....................................................... 21 FIGURE 3-3 JOHN MOVES TO THE UNIVERSITY ............................................................ 21 FIGURE 3-4 ABC LTD. START RE-SENDING OF PACKETS ............................................. 22 FIGURE 3-5 MORE OR LESS COMPLETE PICTURE OF PROBLEMS WITHIN IP................... 22 FIGURE 3-6 OVERVIEW OF MOBILE IP ARCHITECTURE ............................................... 24 FIGURE 3-7 REGISTRATION WITH FA COA ................................................................. 25 FIGURE 3-8 REGISTRATION WITH FA COA ................................................................. 25 FIGURE 3-9 TRIANGLE ROUTING ................................................................................. 26 FIGURE 3-10 ENCAPSULATION OF IP PACKETS............................................................ 27 FIGURE 3-11 REVERSE TUNNELING............................................................................. 27 FIGURE 3-12 ALLOCATION OF HA .............................................................................. 30 FIGURE 3-13 DIAMETER MOBILE IPV4 APPLICATION INTERFACES ............................. 31 FIGURE 4-1 END-TO-END BASIC CALL-FLOW............................................................... 34 FIGURE 4-2 INVITE MESSAGE.................................................................................... 34 FIGURE 4-3 CALL FLOW EXAMPLE WITH SIP PROXY SERVER...................................... 37 FIGURE 4-4 FORWARDING THE INVITE-MESSAGE ..................................................... 38 FIGURE 4-6 FORWARDING 180 RINGING RESPONSE ................................................. 38 FIGURE 4-7 CALL FLOW EXAMPLE WITH SIP REDIRECT SERVER................................. 39 FIGURE 4-8 SIP REGISTRATION EXAMPLE .................................................................. 40 FIGURE 4-9 REGISTRATON MESSAGE .......................................................................... 40 FIGURE 4-10 SIP CALL TRANSFER.............................................................................. 41 FIGURE 4-11 SIP CALL TRANSFER MESSAGE FLOW .................................................... 41 FIGURE 4-12 COMPUTING DESTINATION WHEN MN HAS FQDN................................. 43 FIGURE 4-13 COMPUTING DESTINATION ADDRESS WHEN MN DOESN'T HAVE FQDN . 44 FIGURE 5-1 GENERAL NETWORK MODEL..................................................................... 48 FIGURE 6-1 SCENARIO 1.............................................................................................. 49 FIGURE 6-2 THE MN IS IN ITS HOME NETWORK ......................................................... 50 FIGURE 6-3 RTP SESSION BEHAVIOUR WITHOUT REVERSE TUNNELLING .................... 51 FIGURE 6-4 RTP SESSION BEHAVIOUR WITH REVERSE TUNNELLING........................... 52 FIGURE 6-5 ROUTING OF THE PACKETS. WORST CASE................................................ 53 FIGURE 6-6 HANDOVER " FOREIGN NETWORK - FOREIGN NETWORK" ....................... 54 FIGURE 6-7 SESSION INITIATION FROM FOREIGN NETWORK........................................ 55 FIGURE 6-8 SESSION INITIATION FROM FOREIGN NETWORK W/REVERSE TUNNELLING 55 FIGURE 7-1 SCENARIO 2.............................................................................................. 58 FIGURE 7-2 FA CARE-OF ADDRESS VS. CO-LOCATED CARE-OF ADDRESS ................. 60 FIGURE 7-3 RTP SESSION RELOCATION...................................................................... 61 FIGURE 7-4 HANDOVER “HOME NETWORK – FOREIGN NETWORK”............................ 62
viii
FIGURE 7-5 HANDOVER " FOREIGN NETWORK - FOREIGN NETWORK" ........................63 FIGURE 8-1 SCENARIO 3 ..............................................................................................66 FIGURE 8-2 MOBILE IP HANDOVER FOLLOWED BY SIP CALL TRANSFER.....................67 FIGURE 8-3 SESSION BEFORE THE NEXT HANDOVER ....................................................69 FIGURE 8-4 DESIRED HANDOVER MANAGEMENT .........................................................70 FIGURE 8-5 LOGIN PROCEDURE FROM THE FOREIGN NETWORK..................................70 FIGURE 9-1 SKETCH FOR APPROACH 4.........................................................................73 FIGURE 9-2 RELOCATION OF ONE END POINT OF THE SESSION......................................75 FIGURE 9-3 RELOCATION OF ONE END POINT OF THE TUNNEL......................................75 FIGURE 9-4 CO-LOCATED CARE-OF ADDRESS AND ROUTER........................................77 FIGURE 9-5 ALLOCATION OF HA IN THE FOREIGN DOMAIN ........................................78 FIGURE 9-6 SESSION INITIATION WHEN MN HAS AN FQDN........................................79 FIGURE 9-7 HANDOVER " FOREIGN NETWORK - FOREIGN NETWORK" ........................80 FIGURE 9-8 SESSION INITIATION WHEN MN DOESN'T HAVE AN FQDN........................83 FIGURE 9-9 MONITORING FUNCTION ALGORITHM.......................................................84 FIGURE 9-10 TRIGGER FUNCTION ALGORITHM............................................................84 FIGURE A-1 ELEMENTS OF AN H.323 NETWORK..........................................................94 FIGURE A-2 H.323 CALL FLOW EXAMPLE...................................................................96
ix
List of Tables TABLE 2-1 CORRELATION BETWEEN MOBILITY CLASSES ............................................ 17 TABLE 10-1 COMPARISON OF APPROACH 1 AND 4...................................................... 88
10
1. Introduction Nowadays the use of packet switched services is growing exponentially, while the use of circuit switched services is decreasing. Although, the use of circuit switched services is still predominating, it is unknown what is going to happen in future: either the use of PS services will stop growing and the use of CS services will stop decreasing so that both services will be used at the equal level or the use of the packet switched services will continue to grow and the use of the circuit switched services will continue to decrease. In either case it is difficult to imagine future without Internet, and this term will soon become a part of everyone’s vocabulary.
At the same time users are setting more and more demands on the ability for being mobile, i.e. to be able to move freely without being dependent on their phones and computers, which have fixed points of attachment to the networks. Nowadays mobility at the best possible degree can be achieved due to GSM, which is circuit switched. When using this standard a user can move freely inside the coverage area of his operator and inside the coverage area of the other operators (provided that there exists an agreement between these operators to support each other’s users) and remain available for the corresponding parties at the same time as his mobility is transparent for these parties.
But mobility comprises not only the possibility to be available for the corresponding parties but also the possibility to get access to the same services, which a user has access to when using a stationary terminal. As the packet switched networks offer a larger number of services than the circuit switched ones, it is natural that the users desire to get access to them independently of their locations. This desire gives a growth for the demand on the mobility in the packet switched environment.
Several attempts have been undertaken in order to meet this requirement, and they have resulted in a new standard, known as General Packet Radio Services (GPRS), which is being deployed nowadays. What is likely to be deployed after GPRS is a standard, which is in the development phase now, known as Universal Mobile Telecommunication Systems (UMTS). Although both of these offer much more benefits, concerning packet switched services, than GSM, they are incapable of providing mobility on the global scale like GSM, because of great difference in the functionality of circuit switched and packet switched networks.
The motivation of this work is to contribute to the general problem of providing mobility on the global scale. This problem comprises not only the ability to change geographical points of location but also to provide different types of mobility, regardless of user’s location.
This paper assumes that the readers are familiar with the basic concepts of IP networking, such as IP address structure, routing in IP networks and Network Reference Models TCP/IP and OSI.
11
1.1. Problem Definition There exist three major types of mobility: terminal mobility, personal mobility and application mobility. There have also been developed several solutions for providing each of these types and examples of them are Mobile IP for terminal mobility, Session Initiation Protocol (SIP) for personal mobility and Grasshopper Agent Platform for application mobility. Although some of them have already been deployed, they consider each mobility type separately and are unaware of other mobility types. However, in real life there is a need for providing all the types of mobility simultaneously, and it is unknown how each solution will behave in the presence of the others.
In this work we choose to look at the problem of providing terminal and personal mobility at the same time, and we base our discussion on the two existing solutions: Mobile IP and SIP. In our paper we will examine whether it is possible to apply both of them on one network, in what way the implementation should be done, what changes are required to these protocols and to the underlying protocols in order to make terminal and personal mobility possible.
The problem has been defined as following: How can the terminal and personal mobility be provided on the one network?
As terminal mobility and personal mobility are general terms, there is a need to look at the more particular cases, i.e. Mobile IP and SIP, which are used for providing these types of mobility. Thus, the problem can be narrowed to the problem of defining how these protocols would interact and what should be done in order to provide such interaction. In such a way we are going to provide a particular proposal for a general problem. It is clear that this proposal cannot be applied to the problem, when other particular cases, different from Mobile IP and SIP are considered.
The problem can be divided into some smaller problems, but in order to understand them, it is first necessary to understand the functionality of Mobile IP and SIP. We provide a list of these sub problems here nevertheless, in order to give a reader overview of what aspects are of primary importance for the further discussion.
So, the sub problems are:
• How would SIP behave if the IP address of the terminal changes?
• Is there a need for modifying SIP, in order to force it to handle changes in the IP address? If yes, in what way should SIP be modified?
• How will the behaviour of SIP influence the behaviour of Mobile IP and vice versa.
• Is there a need for modifying Mobile IP? If yes, in what way should the Mobile IP be modified?
• How will other network elements be influenced by the presence of both, SIP and Mobile IP at the same time?
12
• What consequences will the interaction between Mobile IP and SIP have for other problems, such as route optimization and TCP performance?
1.2. Methodology The methodology used to solve the defined problem can be divided into two major parts: a theoretical, or background, part and a practical part.
1.2.1. Theoretical part Before we could start analyzing the problem of applying terminal and personal mobility on one network, we needed to understand the basics of the IP networking, study different mobility aspects and obtain a detailed knowledge on Mobile IP and SIP functionality.
First, we looked at the basics of IP networking, where we paid special attention to how IP address is structured, how routing of packets is carried out and what approaches exist for structuring all the processes, which are carried out on a computer.
Second step was to study different mobility aspects and to get an understanding of each of them. The knowledge on the aspects, which are defined per today, were obtained from the lectures in the course “Mobile Communication”, given at the University of Oslo in 2001. These mobility aspects are the basics of the mobile communications, and it is impossible to deal with problems of mobility, without knowledge of these.
While studying Mobile IP, the most of information was obtained from the specification, made by IETF. When we started our work the latest version of the specification was RFC 2002 [18], so the most of the work is based on this specification. Although later versions of this specification appeared during our work, the essentials of the contents have not changed. These later versions were mainly aimed at providing more detailed description of some functions and correcting the unclear points of the document.
In order to understand SIP functionality, we first studied the book of Alan B. Johnson “Understanding the Session Initiation Protocol”. This book is written in a simple and easily understandable language, so that it was not a problem to get an overview of SIP. But however, this book doesn’t deal with the technical details of this protocol and thus we had to refer to the IETF’s specification of SIP, RFC 3261. Through this document we obtained the detailed technical information, which is closely related to our thesis.
With the background information mentioned above, we started the work directly on the defined problem.
1.2.2. Practical part Although we call it practical part, it should not be understood in the way that we have implemented something in practice. It is rather called so because in this part we
13
describe different approaches we have proposed for providing both terminal and personal mobility in practice.
We have in all proposed four different approaches, where we start with the approach, which is “straight forward” method of implementing both protocols, then figure out the disadvantages of that approach and try to solve them in the next approach. So, we describe the second approach and find out that it also has its own disadvantages. Thus, we introduce the third approach, where we again try to cope with the disadvantages of the first approach, but by means, different from those used in the second approach. As the third approach also has some disadvantages, a fourth approach is presented.
In all the approaches we provide an analysis of each of them, paying special attention to the following issues: complexity, routing efficiency, security issues, handover issues, protocol impacts and extensibility.
After we are finished with the description of each approach in particular, we provide an evaluation of them, where we compare different aspects of the first and of the fourth approach. Why we do not consider the second and the third approaches is explained in that chapter.
1.3. Outline Chapter 2 gives an overview of different mobility aspects and provides examples of the available solutions for each aspect.
Chapter 3 is an introduction to the functionality of Mobile IP. It provides also description of additional functionality, provided by Diameter Mobile IPv4 application, as this functionality is of great importance for the problem discussion.
Chapter 4 gives an introduction to the functionality of SIP. In addition to the basic SIP methods, it provides also a description of one additional method which is used later in the problem discussion.
Chapter 5 provides a detailed description of the problem along with the assumptions and limitations. The network model, which the further approaches are based on, are provided in this chapter as well.
Chapters 6-9 describe the four approaches to the problem and provide analysis of each approach.
Chapter 10 provides the comparative analysis of the approaches, which are most suited for being implemented in practice.
Chapter 11 concludes the work of this thesis. It summarizes the results in a critical view and proposes future works.
14
2. Mobility Aspects Mobility in the whole can be classified in two dimensions: category of user and the availability of services [8]. In this chapter we give a classification according to the category of user first, then comes classification according to availability of services. After that we describe how these two main classes intersect with each other and at the end of this chapter we give a short summary on what types of mobility we are going to work on.
2.1. Classification according to the category of user Different types of users can benefit from mobility. These are: a human being, hardware and software. These give arise to three fundamental types of mobility: personal mobility, terminal mobility and application mobility. Session and role mobility come as an addition to them.
User
/* create socket */ sd = socket(AF_INET, SOCK_STREAM, 0); if(sd<0) { perror("cannot open socket "); return ERROR; }
/* bind server port */ servAddr.sin_family = AF_INET; servAddr.sin_addr.s_addr = htonl(INADDR_ANY); servAddr.sin_port = htons(SERVER_PORT);
Hardware
Human being
Software
Terminal mobility
Personal mobility
Applicationmobility
Figure 2-1 Mobility classification according to the category of users
2.1.1. Personal mobility Personal mobility allows a human being to access or to be accessed by the network independently of where the access point and terminal used are located in the network and maintaining all services contained in the personal subscription. An example can
15
be a person who wants to be contacted on his stationary PC in the office during the working hours and by an IP-phone at home the rest of the day.
2.1.2. Terminal mobility Terminal mobility permits a terminal to change location while maintaining all the services. Terminal mobility can be provided at different layers and thus, different approaches exist. Mobile IP is an example of how terminal mobility can be achieved on the network layer. The following definition is valid in the context of Mobile IP: “terminal mobility is the ability of a node to change its point-of-attachment from one link to another while maintaining all existing communications and using the same IP-address at its new link” [8]. However, this definition is not applicable to other approaches that do not rely on the network layer, because they permit change of an IP-address at a new link.
2.1.3. Application mobility Application mobility allows a software process to be relocated from one machine to another or even moved between machines while processing.
2.1.4. Session mobility Session mobility is defined as an added feature to those mentioned above. This mobility is ensuring that active sessions are not disrupted while terminals, persons or applications are moving or being relocated (However, sessions may be brought to a well-defined halt state in order to be resumed later). One example of session mobility is call transfer, e.g. a user can move from one terminal with multimedia presentation capabilities to one with voice-only capabilities or vice-versa. The presentation mechanism will change to meet the requirements of the new environment. Another example is handover in cellular systems, permitting calls to continue while the mobile terminal moves from one cell to another. In GSM, the session is maintained without interruption, i.e. without loss of information during handover.
2.1.5. Role mobility Role mobility is a new type of mobility arising recently. As a member of the society, each individual has usually multiple roles, e.g. employee of a company, head of a family, etc. Furthermore, an individual may have several job positions in different companies and hence different roles. For each role, there is defined a set of services with distinct preferences, rights and limitations. Role mobility aims to assist the user to move from one role to another easily and smoothly.
2.2. Classification according to the availability of services By definition, services can be available all the time, partially available and unavailable. As there is no need to talk about mobility in the context of unavailable services, there are two types: continuous mobility and discrete mobility.
16
2.2.1. Continuous mobility Continuous mobility enables continuous availability of services while the user moves. Continuous mobility is offered in cellular networks. This type of mobility is making use of the mechanisms of session mobility. This type of mobility is desired to achieve on the global scale.
Intersection betweencoverage areas
Figure 2-2 Continuous mobility
2.2.2. Discrete mobility Discrete mobility enables the availability of services within certain areas and for certain access points, e.g. home and office, but not while moving form one area to another. Portability is an example of discrete terminal mobility, where it is only allowed to move a terminal from one plug to another. In this case too, session mobility may be required in order to ensure that sessions are halted and maintained in well-defined states while the terminal is being relocated.
Nointersection
Figure 2-3 Discrete mobility
17
2.3. Correlation between mobility classes We have so far described two classes of mobility each taken separately. But these classes cannot exist independently of each other and they correlate orthogonally. See Table 1 for the interconnection between the classes. Further we give a description for each interconnection. Table 2-1 Correlation between mobility classes
Continuous mobility Discrete mobility
Personal mobility Mechanism exists, not implemented Widely used
Terminal mobility Mechanism exists, not implemented Widely used
Application mobility Mechanism exists, not implemented Widely used
2.3.1. Personal continuous mobility Personal continuous mobility is not yet supported on the global scale, but the mechanism for supporting it already exists. This mechanism is a Session Initiation Protocol, which is described in chapter 4. It allows a person to move freely between different domains and terminals and remain available for the calling parts without additional notification of them on the user’s current IP address. This means that information about a certain user is kept on a server and is updated each time the user’s IP address changes. So, anyone, who wants to contact this user, contacts this server first and the server is responsible for finding the called part. After both parts have found each other, a session between them is initiated and information exchange can proceed.
2.3.2. Personal discrete mobility Personal discrete mobility is widely implemented today on different types of LANs by providing each user with a login name and a password, which he afterwards uses to log on to the system. All the other users, who are currently logged on to the same system can find out on which machine a specific user is working and initiate a session with him. An example of this functionality are “finger” and “talk” Unix commands, which are relatively responsible for finding information about a user and for initiating a chat session between them.
However, a support for session mobility is needed in both, personal continuous and personal discrete mobility. Without it users are not able to change the terminals and continue talking to the counter parts without re-initiating the session.
2.3.3. Terminal continuous mobility As for personal continuous mobility, terminal continuous mobility is not yet implemented on the global scale but the mechanism for supporting it already exists. This mechanism is Mobile Internet Protocol, which is described in chapter 3. It allows one terminal to travel between different domains and each time obtain new IP addresses and still remain available to the counter parts without additional notification of them on the terminal’s current IP address. Mobile IP supports session
18
mobility as well. Due to the additional units, Home Agent and Foreign Agent, which are involved in the communication process, a terminal is able to change its IP address and keep the ongoing session.
2.3.4. Terminal discrete mobility Terminal discrete mobility is widely used nowadays. When a terminal is connected to a WLAN it can be moved freely inside the coverage area of this WLAN. The terminal can even change its point of attachment as long as it is on the same subnet as the previous point of attachment. In this case the session mobility is supported on the link level and the ongoing sessions do not suffer from this handover.
2.3.5. Application continuous mobility Application continuous mobility is not achieved on the global scale either. As for personal and terminal continuous mobility a technique for it exists. It is known as a Mobility Agent. Mobility Agent is a program that executes on behalf of a person or an organization, which in addition may migrate from host to host during the execution process. Some implementations of this technique already exist and Grasshopper and Voyager can be mentioned as examples.
2.3.6. Application discrete mobility A well-known Java Applet is an example of application discrete mobility. It is actually software, residing on one host, which is downloaded to another host in order to be executed there. In contrast to Mobile Agent, it cannot migrate forward to another host.
2.4. Introducing several types of mobility However, providing a certain type of mobility is one problem and providing different types of mobility at the same time is another problem. Even if all the mechanisms are developed for the types to be provided, it should be investigated how these would perform when implemented together. In this paper we look at the particular case where we wish to provide both terminal mobility and personal mobility by means of Mobile IP and SIP.
19
3. Terminal mobility and Mobile IP In this chapter we describe how terminal mobility is supported in IP today. We discuss this topic in the context of wireless access to the network and do not consider fixed access at all, because only portability can be achieved in this case. We show why terminal mobility cannot be supported with the existing mechanism and identify the need for a totally new solution.
As a particular case of such a solution we use Mobile IP and provide a description of it. Although there exist other solutions for the problem of terminal mobility, we base our paper on this one because of the benefits, described in the end of the chapter.
As we are not going to touch any other aspects of mobility in this chapter except terminal mobility, we omit “terminal” and use only “mobility”, but still mean terminal mobility.
3.1. IP Mobility In order to show to what degree IP mobility is provided today, we describe first a situation when a user changes his point of attachment within one subnet, and after that give a description of the situation where points of attachment are in different subnets.
3.1.1. Mobility within one subnet Consider a wireless local area network (WLAN), which has two transmitting/receiving antennas - two points of attachment, A and B, and a host NN, attached to A, communicating to another remote host MM on another subnet (see Figure 3-1).
Default router
NN
A
B
Internet
MM
Figure 3-1 Wireless access.
20
If host NN moves from the coverage area of point A, and moves into the coverage area of point B, the active session between NN and MM is not interrupted and they can continue to communicate as before. As both points are on the same subnet, the host NN is not required to change its IP address after the relocation and handover from one point to another is carried out on the link-layer, without involving the upper layer protocols into the process. How WLAN manages this handover is out of scope of this document.
Thus, terminal mobility is implicitly provided within one subnet.
3.1.2. Mobility between different subnets We are now concerned with a situation when a mobile node moves between two subnets. Recall that two subnets have different network prefixes by definition.
Assume that a MN is being relocated from one subnet to another. Upon entering the new subnet, it acquires a new IP address be means of e.g. DHCP [10]. It is clear that the user can no longer receive the packets, destined to it, because they arrive at the old subnet, but it is also clear that none of the terminals, willing to establish a connection to this terminal, is able to do that, because they simply don’t know at which address it is currently available. So, the first problem is how can all the other terminals remain able to establish a connection to this terminal, if they are not aware of its new IP address.
The second problem is that there may exist an ongoing session, while moving to another subnet. It is possible to notify the corresponding party on the new IP address, and then this party will need to start sending packets to that new IP address. It will also need to be able to re-send all the packets that have not been acknowledged, and thus synchronize the packet transmission between the two IP addresses. If there were several ongoing sessions, then all the corresponding parties had to be notified on the new IP-address and all of them had to synchronize the transmission, what makes the situation worse. Thus, the second problem is session mobility management. We have not mentioned security issues, concerned with the notification of the corresponding parties, in order to provide an overview of the problem.
The overall picture becomes more complicated if the terminal moves to a third subnet, before the correspondent parties have finished the synchronization process.
To clarify the problem, let’s look at the example where a student John is writing his thesis on a laptop and has to change his location.
For the sake of simplicity we assume a network model as showed in Figure 3-2. In this model we are dealing with two subnets, each of which has only one transmitting/receiving antenna, i.e. only one point of attachment to the network. John’s apartment is in the coverage area of subnet 1, while his University is in subnet 2.
21
Subnetwork 2Network Prefix:
202.202.202
Subnetwork 1Network Prefix:
101.101.101
Internet
Home UNIVERSITY
University
Figure 3-2 Network model for the example
Consider a situation when John is at home and his laptop is attached to the network and its IP-address is 101.101.101.101. Then John finds out that he doesn’t have enough information and has to go to the University’s library and work there. He takes his laptop with him and goes to the University. Thus, the laptop is now in the coverage area of another antenna, where it gets access to the subnet 2 and is assigned a new IP-address, e.g. 202.202.202.202, by means of DHCP. From now on John is able to look for the information, available on the subnet 2 as well as on the Internet.
Subnetwork 2Subnetwork 1
ABC Ltd.
John's direction
Packets' direction
HomeIP: 101.101.101.101 UNIVERSITY
UniversityIP: 202.202.202.202
Figure 3-3 John moves to the University
But what if there was an active session between John and a company “ABC Ltd.”, which is providing him with some useful material on his essay? This company knows nothing about his new IP-address and sends the material to 101.101.101.101 (see Figure 3-3). It seems reasonable that John should inform them on his terminal’s new IP-address, and they should start sending their messages to 202.202.202.202 instead of 101.101.101.101 (see Figure 3-4).
22
Subnetwork 2Subnetwork 1
ABC Ltd.IP: 303.303.303.303
John's direction
Packets' directionJohn's information
HomeIP: 101.101.101.101 UNIVERSITY
UniversityIP: 202.202.202.202
Figure 3-4 ABC Ltd. start re-sending of packets
Now, what about messages, which are already sent to 101.101.101.101? How can the company find out whether John has received them or not? How can the synchronization of packets be managed in such a way, that the handover becomes as seamless as possible? And what if John moves to another place, e.g. job, where his terminal is assigned a new IP address 303.303.303.303 before the synchronization is completed? What if there are several active sessions? (See Figure 3-5)
Subnetwork 3
Subnetwork 2Subnetwork 1
ABC Ltd.
John's direction
Packets' directionJohn's information
XYZ Ltd.
HomeIP: 101.101.101.101 UNIVERSITY
UniversityIP: 202.202.202.202
JobIP: 303.303.303.303
Figure 3-5 More or less complete picture of problems within IP
Too many questions as one can see. And these are not all the questions that arise when John moves from one place to another and his laptop uses only IPv4 for routing purposes.
23
As Charles E. Perkins says in his book, the problem with mobility is that mobile computers move from one IP subnet to another, but have the wrong subnet prefix for the destination subnet [34].
So, the problem with mobility in IP is that it can only support local mobility, but not the global one. What it can offer us today on the global level is only portability.
3.1.3. The need for Mobile IP As we have seen in the previous section, there is a problem with routing of packets to the terminal if its IP-address changes while there exist active session. Not only does it reside in the fact that all the corresponding parties need to be notified on the new IP-address, but also in that it affects transport of packets. Recall that each TCP-connection is identified with destination’s and source’s IP-addresses and port numbers. Thus there is a need to modify transport protocol in the way, that it would be able to handle changing IP-addresses. This modification comes in addition to the need for a mechanism that would route packets to the appropriate destinations.
In order to provide mobility on the global scale, there has been proposed a mechanism, called Mobile IP that solves the arisen problems. It solves the problem with routing of packets (see next chapter for description) in such a way that it doesn’t require any modifications to the existing transport protocols. But, however, Mobile IP seriously affects the performance of them (see chapter 3.2.4) and the interaction between Mobile IP and these protocols remains an open issue.
3.2. Overview of Mobile IP In this chapter we give an overview of the major issue of Mobile IP, i.e. routing of packets. We provide also a description of two procedures, registration and allocation of Home Agent in a Foreign Network, and a description of the TCP performance in the Mobile IP environment, as these are essential for further discussions. Security aspects of Mobile IP are out of scope of this document, because they are not a critical issue for the problem, discussed in this paper.
3.2.1. Mobile IP Related Terms Mobile IP is a protocol that is intended to solve the problem, described in section 3.1.2. It allows a terminal to move freely between subnets, while maintaining all the ongoing communications. At the same time the terminal’s mobility remain transparent for the corresponding parties, i.e. they are not aware of the terminal’s relocation.
In order to be able to achieve such a transparency, the corresponding parties should always send their packets for that particular terminal to one IP address. Thus, each mobile terminal is assigned one IP address, which remains unchanged regardless of the point of attachment to the Internet. This IP address is known as a Home Address of the terminal. This address can also be though of as a terminal’s static IP address. Hence, a network, having the same network prefix as Home Address is called a terminal’s Home Network.
24
Any other networks, which is different from the Home Network is called Foreign Network. When a terminal connects to the Foreign Network, it receives a temporary IP address for use while on this network, and this address is called a Care-of Address (CoA).
Tunnel A
Home Network
HA
Foreign Network
FA Care-of Address
FA
Foreign Network
Co-located Care-of Address
Internet
Tunnel B
Figure 3-6 Overview of Mobile IP architecture
Mobile IP makes it possible for this node to receive the packets, which arrive to its Home Network, while it is connected to the Foreign Network. This feature is enabled due to the two new network elements, Home Agent and Foreign Agent, and a process of tunnelling the packets (see Figure 3-6, Tunnel A). Home Agent (HA) is a router on the terminal’s Home Network, which stores information on the terminal’s current location and tunnels all the packets to that location. Tunnelling includes encapsulation of the original packet into an outer IP packet, forwarding the resulting packet to the appropriate Care-of Address and de-encapsulation of this packet at that address. De-encapsulation is performed by the terminal’s Foreign Agent (FA) – a router on the Foreign Network, that provides routing services to the terminal while registered. Hence, the node’s Care-of Address in this case is called FA Care-of Address.
But it may happen that the Foreign Network doesn’t support Mobile IP, thus cannot provide a terminal with the FA functionality. In this case the packets are tunnelled directly to the terminal, where the de-encapsulation of the packets is performed by the terminal itself (see Figure 3-6, Tunnel B). The terminal’s CoA is thus called co-located Care-of Address.
3.2.2. Registration procedure In this section we are only concerned with the registration, initiated from a Foreign Network, because registration initiated from a Home Network is of no interest for the further discussion.
Upon entering a Foreign Network, a Mobile Node should find out whether this network provides FA functionality or not. How this is done is described in RFC 2002 and is out of scope of this document. If there is an available FA the MN obtains a FA CoA, otherwise it uses co-located CoA. In any case the MN should register with its
25
Home Agent, in order to provide it with the information on the MN’s current location.
Registration with FA CoA Registration procedure with FA Care-of Address is shown in Figure 3-7.
Home Network
HA
Foreign Network
FA CoA
FA
Internet
1) 2)
4) 3)
Figure 3-7 Registration with FA CoA
MN starts the registration procedure by sending a Registration Request to the available FA, where it provides the information on its Home Address, HA IP address and the acquired Care-of Address (1). This FA relays the request to the HA of the MN (2). Upon receiving this request, HA updates the mapping <MN’s Home Address; MN’s Care-of Address> for this MN and sends a Registration Reply to the MN’s FA CoA (3). When FA receives this Reply, it updates the mapping <MN’s Home Address; MN’s Link Layer Address> and relays the Reply to the Mobile Node (4). Upon receiving the Registration Reply, the MN should configure its routing tables appropriately for its current point of attachment.
Registration with co-located CoA Registration procedure with co-located Care-of Address is shown in Figure 3-8.
Home Network
HA
Foreign Network
Co-located CoA Internet
1)
2)
Figure 3-8 Registration with FA CoA
The difference between the registration with FA CoA and with co-located CoA is that in the latter case the Registration Request and Reply are exchanged directly between the MN and it’s HA. The same parameters as in the previous case are provided in the Registration Request, and the same updates are made on the HA and the MN.
26
3.2.3. Routing in Mobile IP In this section we provide a description of such routing considerations in Mobile IP as triangle routing, tunneling and reverse tunneling.
Triangle routing
Tunnel
Home Network
HA
Foreign Network
FA Care-of Address
FA
Internet
Corresponding party
Packets to the MNPackets from the MN
Figure 3-9 Triangle routing
Mobile IP introduces one more term, which is worth noting. This term is known as triangle routing.
Consider the Figure 3-9. When there is an ongoing session between a MN and a corresponding party, all the packets, destined to the Mobile Node are first routed to the MN’s Home Network and after that are tunnelled to the MN’s Foreign Network. But the packets from that MN are routed directly to the corresponding party, as it is showed in the figure. Thus, the path followed by the packets to and from the MN forms a triangle and is therefore called triangle routing.
All the packets, flowing from the MN to the corresponding party, have as a source address the Home Address of the MN. Hence, the network prefix of the source address of these packets is different from the network prefix of the network, in which they were originated. This is not a problem as long as the Foreign Network doesn’t implement a filter, known as ingress filter [13], which doesn’t allow the packets with the network prefix in the source address, different from that network’s prefix, to leave the network. This problem is solved through the reverse tunnelling, described in the section 0.
Tunneling When tunneling packets from Home Network to Foreign Network, the original IP packet is encapsulated into an outer IP packet, as shown in the Figure 3-10. In the original packet neither of the fields are modified in order to deliver it to the destination in its original state. The outer packet is a usual IP packet, which Source Address is the IP address of the terminals HA, and Destination Address is the terminal’s Care-of Address. When the encapsulated packet arrives at the destination
27
address, it is de-encapsulated and the original IP packet is delivered to the upper layers in the same way as if no encapsulation were present.
Original IP packet
Encapsulating IP packet
Figure 3-10 Encapsulation of IP packets
It is distinguished between three encapsulation types: IP in IP Encapsulation [17], Minimal Encapsulation [19] and Generic Routing Encapsulation (GRE) [12]. As we are only concerned with tunnelling in general, the description of these types is out of scope of this document.
Reverse Tunneling If during tunneling the packets are transported from the Home Network to the Foreign Network, then during reverse tunneling they are transported in the reverse direction: from the Foreign Network to the Home Network. This form for tunneling is used for solving the problem that Mobile IP faces if a Foreign Network implements ingress filtering.
The problem is that the packets, leaving the network, have a source address with the network prefix, which is different from the network prefix of that network. Thus, ingress filtering stops them for the purposes of security.
Tunnel
Home Network
HA
Foreign Network
FA Care-of Address
FA
Internet
Corresponding party
Packets to the MNPackets from the MN
Figure 3-11 Reverse tunneling
With the reverse tunneling, however, the original IP packet can be encapsulated into the outer IP packet, which is then tunneled to the MN’s HA, where it is de-encapsulated and sent to the correspondent node (see Figure 3-11). When such an encapsulated packet leaves the Foreign Network, its source address is the MN’s Care-of Address, which has the same network prefix as the Foreign Network itself and is thus not stopped by the filter.
28
3.2.4. TCP performance TCP is a de-facto standard implemented for packet transport over the Internet. It is a reliable, full-duplex and connection-oriented protocol and its performance in Mobile IP is affected mainly by dogleg (triangle) route overhead and handover overhead.
Dogleg route overhead influences TCP performance in two ways. First of all, packets need to travel a longer way before they reach the destination than in usual IP routing. This means that they should go through more intermediate routers, thus increasing round-trip time and delay. Second is resource consumption aspect: it is obvious that in triangle routing both the original packets and tunneled packets can use the same parts of their paths from source to destination, thus doubling the link usage while the actual throughput remains the same [15]. As the dogleg route overhead is the main contributor to the drop in TCP performance, it would be desirable to reduce it or eliminate. A proposed solution to that is Route Optimization, which is based on that the CH supports mobility and that MN notifies it of changes in its current point of attachment.
Handover overhead is the time introduced into the packet transmission during the handover from one network to another. When a tunnel from HA to FA is set, a TCP connection is established between these two entities. The two IP-addresses and two corresponding port numbers uniquely identify this connection. Once one of these parameters is changed the connection is disrupted and lost. A new connection should be set up by HA upon receiving information about MN’s current location, thus interrupting all ongoing communications and causing handover overhead. The consequences of it is that a MN is disconnected from the network for a period of time (>1sec?) and that when the connection is established again, TCP should perform slow-start and resend all the packets, which have timed out.
Tunneling overhead, arising during tunneling of packets, and fragmentation overhead, arising during fragmentation of packets that are larger than maximum transfer unit (MTU), contributes to the overall TCP performance too, but this contribution is negligible in contrary to the dogleg and handover overheads [15].
3.2.5. Dynamic Home Agent We have so far seen at the possibility to allocate different FAs for the MN as it moves between subnets, while its HA remains static. However, dynamic allocation of HA in other networks, different from the Home Network, is allowed as well. This procedure is made possible due to an application, which utilizes two protocols, Mobile IPv4 and Diameter, and is thus called a Diameter Mobile IPv4 application [3].
In order to get an idea of what Diameter protocol is aimed at, it is necessary to understand the concept of Authentication, Authorization and Accounting (AAA) first. Thus, we start this section by describing AAA and giving a glimpse of what Diameter protocol is, and afterwards we give an overview of how a Diameter Mobile IPv4 application allows HA to be allocated in the Foreign Network.
29
AAA Computer networks are designed in the way that they allow their users to share resources. E.g., several users can use disk storage of one server to store the information, but not all the users want their files to be accessible for someone else. So these files are given appropriate access permissions, which show what users are able to read/modify/execute the file. Application software is run on this server in order to check if the user requesting access to these files can actually do that.
Anyone who claims access to the network should first of all be recognized by that network to protect it from the main security issues: unauthorized access, modification and/or destruction [8]. Networks should also verify user’s type as long as different users have different access restrictions to the network’s files/services. And the third, there is a need for a mechanism that can meter user’s connection time to the Internet or amount of data sent to/by user to provide network’s ISP with billing and accounting information.
Meeting these challenges in a simplified and scalable manner is the main task of Authentication, Authorization, and Accounting (AAA). AAA defines a framework for coordinating these individual disciplines across multiple network technologies and platforms.
Authentication is defined by IETF as the act of verifying a claimed identity, in the form of a pre-existing label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication) [2]. In other words, authentication is validation of end users’ identity prior to permitting them network access (entity authentication). This process is based on that fact that the end user has some kind of unique information, e.g. a username/password combination, a secret key, biometric data, which identifies him unambiguously. The AAA server compares the user-supplied authentication data with the user-associated data stored in its database, and if the credentials match, the user is granted network access. A nonmatch results in an authentication failure and a denial of network access.
Authorization is defined by IETF as the act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential [2]. For example, if a user who doesn’t have permission to access a concrete type of network’s service tries to access it anyway, it results in a denial of service and possible notification about user’s access permissions. Authentication and authorization are usually performed together in an AAA-managed environment.
IETF definition of accounting is the act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation [2]. Auditing involves verifying of the procedure’s correctness, billing is preparing of the invoice and cost allocation is allocation of costs between entities, where cost of unit per resource may need to be determined.
The first AAA client-server protocols were RADIUS (Remote Access Dial-In User Service) [21] and TACACS+ (Terminal Access Controller Access Control
30
Systems) [14]. They offer much of the same functionality, but have some differences as well. Further description of these protocols is out of scope of this document.
Though these protocols are well known and widespread, both were originally engineered for small network devices supporting just a few end-users requiring simple server-based authentication. But it turned out that there is a need to support AAA services across ISP boundaries in a secure and scalable manner.
The recent step in AAA protocols’ development was designing DIAMETER protocol [6]. This is a lightweight, peer-based protocol, which from the beginning was meant to be scalable and to support roaming and mobile users, while it can also be run on the existing networks. It employs many of the same mechanisms as RADIUS trying to correct some of ancestor’s limitations at the same time.
Allocation of Home Agent in the Foreign Network We have so far only dealt with static HAs, which means that the MNs should be configured with a Home Address, the IP address of the Home Agent and a security information shared between the MN and its HA. Diameter Mobile IPv4 application allows a MN to be configured only with it’s Network Access Identity (NAI) [1] along with some security information shared with AAA server in the Home Network, all the other information will be determined automatically during the Mobile IP registration. It should be noted that the MN without static HA will set the “HA’s IP address”-field in the Mobile IP Registration Requests to the value of 0.0.0.0.
We describe the procedure of allocation of Home Agent in the Foreign Network in short, without dealing with the details and assuming the case, when a MN is configured with its NAI and when no encryption between the units is required. The reader is referred to [6] for a more detailed description.
Internet
AAAF
MS
AAAH
Foreign Domain Home Domain
FA
HA
1) 8)
2)
7)
3)
6)
5)
4)
Figure 3-12 Allocation of HA
This procedure introduces three new terms: Visited Home Agent (VHA or Visited HA), which identifies a dynamically allocated HA for a MN in a foreign network,
31
AAAH, which identifies an AAA server in the Home Network, and AAAF, which identifies an AAA server in the Foreign Network. All the parties, involved in the process of allocation of Home Agent, are showed in the Figure 3-12.
Figure 3-12 shows also what messages are exchanged during this process. When a mobile node enters a new subnet, it receives a new IP address and sends a registration request to a Foreign Agent (1). The FA detects that a HA address is equal to 0.0.0.0 and requests allocation of HA in the Foreign Network by sending an appropriate message to AAAF (2). If the AAAF is willing and is able to assign a Home Agent to the MN, it informs an AAAH on that and includes in the message the identity of the Home Agent that would be assigned to the MN and the identity of the AAAF (3). When the AAAH receives this messages it first of all checks the authentication data supplied by the MN and decides whether the authorization can be granted. It detects also that the AAAF has a possibility to allocate a HA in the foreign network. Thus, it checks whether its own policy allows a MN to have a HA allocated in the foreign network. If authorization is granted and if the MN is allowed to have a HA in the foreign network, the AAAH sends a Mobile IP registration request to the VHA, proposed by the AAAF (4). When the VHA has answered with registration reply (5), the AAAH sends a reply to AAAF, notifying it on that the MN has been permitted to allocate a HA in the foreign network and that it already is registered with this VHA (6) and AAAF forwards it to the FA (7). The registration reply is then sent to the MN (8).
AAAF
MS
AAAH
FA Visited HA
Mobile IP
Diameter
Diameter
Diamete
r
Figure 3-13 Diameter Mobile IPv4 Application interfaces
Note that all the communication between MN and FA are carried out by means of Mobile IP, while all the other messages are sent by means of Diameter protocol (see Figure 3-13).
After the registration is finished, all the responsibilities of the original HA become the responsibilities of the Visited HA.
32
3.3. Benefits of Mobile IP Although Mobile IP is not the only protocol that provides terminal mobility, it still remains unique in its ability to support session mobility at the same time. This major advantage of Mobile IP allows mobile users to move freely between subnets and maintain active sessions, regardless of their point of attachment to the network.
Mobile IP has two additional advantages as well. These are [5]:
• It relies on the network layer, not an application layer as SIP, thus providing sufficient support for both “mobility aware” and “mobility not aware” applications, e.g., TCP-based applications.
• It reuses other existing protocols for support of terminal mobility. This feature makes it possible to base the core network either on wired or on wireless technology, thus making it a media-independent protocol.
33
4. Personal Mobility and Session
Initiation Protocol In this chapter we describe how personal mobility is supported in IP today. As a particular case we use Session Initiation Protocol and provide a description of it.
SIP is a signaling protocol for Internet conferencing and telephony. In contradiction to other existing communication protocols, which are computer-computer oriented, SIP is rather a human-human oriented protocol concerned with end-user’s SIP-enabled devices. This feature enables SIP to support personal mobility and this is why we base our paper on this protocol.
In this chapter we give an overview of SIP components and functionality. Some examples on SIP call flows are included as well. The last point covered in the chapter is benefits of SIP.
In Appendix A a reader would find some information on the predecessor to SIP, H.323, as well as comparison of these two protocols.
4.1. Overview of SIP Signalling can be defined as a process of establishing a connection between two or more users, comprising addressing, alerting, line supervision, provision of information on line status, management and maintenance of the line [8].
As SIP is a signalling protocol, its task is to set up, monitor and tear down sessions between users of SIP-enabled devices. These sessions may include telephone call, Multimedia call, a chat session, a game session etc. Format of SIP messages is simple and can be put on the same level with HTTP and SMTP, thus it would not be a problem for people, familiar with HTTP to read SIP messages.
We give an introduction to SIP functionality by describing two examples of call flow between SIP-enabled devices. Through studying them a reader is getting an insight into SIP related terms as well as into the SIP message format. A classification of SIP clients and servers is given as well.
4.1.1. A simple end-to-end user call flow SIP enables communication between IP-based devices equipped with SIP User Agent (UA) software. Each UA acts on a behalf of one particular user. Any UA may act both as a client and as a server. A UA acts as a client when it originates the request and as a server when it receives a request and sends a response. A Client-Server role may switch during a session and the next example shows how this may be done.
34
Assume that John and Bob have two phones, both of which are equipped with SIP UA software and know each other’s IP address. When John is calling Bob (see Figure 4-1) John’s SIP UA acts as a client and sends an initial INVITE-message to Bob’s SIP UA, which acts as a server.
200 OK
BYE
Media Session
ACK
200 OK
180 RINGING
1 2 34 5 67 8 9
* 8 #
John
1 2 34 5 67 8 9
* 8 #
Bob
INVITEClient Server
ClientServer
Figure 4-1 End-to-end basic call-flow
The INVITE-message is shown in Figure 4-2. This message has a header list and a message body, separated from each other by a blank line. While message headers are used mostly for routing info, information in the message body is needed in order to specify what type of session (audio, video, gaming) a client wishes to establish. Otherwise SIP makes no assumption about that [16].
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP uio.no:5060To: Bob <sip:[email protected]>From: John <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: sip: [email protected]: application/sdpContent-Length: 158
v=0o=John 2890844526 2890844526 IN IP4 uio.nos=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=RTPMAP:0 pcmu/8000
Figure 4-2 INVITE message
35
Upon receiving the INVITE, server (Bob’s SIP UA) sends a 180 RINGING message to the client, indicating that the it has received the INVITE and that alerting is taking place. When Bob answers the phone, a 200 OK message is sent indicating that the called party has accepted the call and that a type of media session proposed by the client is acceptable. The client sends an ACK to confirm that session is established and from this point the media session runs over another protocol, specified in the SIP message. It may be, e.g. RTP, a protocol well suited for transmission of audio and video over IP.
Note that during session establishment, Johns SIP UA acted as a client and Bob’s as a server. During the session their roles can change e.g. if Bob wishes to terminate the session. Then his SIP UA acts as a client and sends a BYE message to John’s phone, which now acts as a server. The server confirms session termination by sending a 200 OK message to the client.
This example shows that SIP is a point-to-point signalling protocol. Thus two end-points, equipped with SIP software and knowing each other’s IP addresses can set up a session between them without need for a SIP network or a SIP server.
4.1.2. SIP servers and clients Although previous example showed that there is no need for SIP servers if end-points know each other’s IP addresses, this would not always be the case. There are numerous reasons for why an IP address of a node can change. And not only nodes’ IP addresses are changed, but also persons use different nodes to connect to the IP network. Thus it is unreliable to identify a person on the network by his current IP address. So, there is a need for unique identification of each person independent of his current location.
Solution to this problem used in SIP is simple. It uses addresses, very similar to mail-addresses, to identify persons. These are called SIP Uniform Resource Locators (URL) and have a form of sip:[email protected], e.g. sip:[email protected]. This address is intended to identify a person, connected to the network, rather than an electronic device, and can thus be used regardless of which computer and where the person currently uses.
There are three types of logical servers: SIP Proxy server, SIP Redirect server and SIP Registrar server. Note that the SIP UA, which acted as a server in the example of chapter 4.1.1 doesn’t fall under any type. It acts on behalf of an end-user and is therefore called a SIP UA. It contains both a client application and a server application and its task is to set up, maintain and tear down sessions with other user agents. As showed in the example, the client-server role of SIP UA may be switched during the session, what cannot happen to SIP server. Another difference between SIP UA and a SIP server is that servers do not have any media capabilities and can only be used for signalling.
A SIP Proxy server is an application that acts on behalf of a UA and its task is to map given SIP URL to the appropriate IP-address upon receiving requests from UAs, to forward these requests to that particular IP-address and to respond to these requests. It usually has access to a database or to a location service to determine the IP-
36
address. A distinguishing feature of a SIP Proxy server is that it doesn’t issue any requests, it can only respond to them.
Proxy servers can be either stateless or stateful. Stateless servers just process messages and keep no tracks of them. Thus, they don’t provide a reliable delivery of messages but benefits in its simplicity and speed of data processing. Stateful servers keep information about processed messages and use this information in processing future requests and responses. They can e.g. start a timer when a request is forwarded, and if no response is received in the timer period, server retransmits this request, relieving the UA of this task.
A SIP Redirect server never forwards messages in contradiction to SIP Proxy servers. Upon receiving requests from a UA, it looks up in the database or a location service for a given receiver and his current IP-address. A redirection response, which contains this IP-address, is returned to the UA, and a transaction between the UA and a Redirect server is concluded. The call then proceeds in the same way as in Figure 4-1 with the messages being identical.
A SIP Registration server’s responsibility is to authenticate users, requiring registration, and to update their contact information, stored in the databases or location services. However, SIP doesn’t define interface between servers and databases. After the information is updated it is available for other SIP servers within the same administrative domain.
Another type of logical application is a SIP Gateway. It is needed to connect together two networks, utilizing different signalling protocol. It can be regarded as a special type of a UA, which acts on behalf of another protocol rather than a human being. Another major difference of a Gateway from a UA is the number of users supported. While a UA usually supports a single user, a Gateway can support up to hundreds or thousands of users. SIP Gateway differs from SIP servers in the way that it has not only signalling capabilities, but can also terminate media path, which is not supported by SIP servers.
4.1.3. Call flow with SIP Proxy Server In this section we describe a more typical example when John (whose SIP URL is sip:[email protected]) doesn’t know Bob’s IP-address in advance, but only SIP URL: sip:[email protected]. So, the INVITE message should be first routed to SIP Proxy server that handles domain telenor.com (see Figure 4-3).
37
database/location service
200 OK
BYE
Media Session
ACK
1 2 34 5 67 8 9
* 8 #
John
1 2 34 5 67 8 9
* 8 #
Bob
200 OK
180 RINGING
INVITE
200 OK
180 RINGING
INVITE
SIP Proxy server
Figure 4-3 Call flow example with SIP Proxy server
When the Proxy receives this INVITE it locates Bob’s IP-address and forwards the INVITE message to Bob’s UA with the addition of a second Via-header, which contains the address of the proxy proxy.telenor.com (see Figure 4-4). Bob’s UA receives an INVITE message with two Via-headers, and concludes that the message was routed through a Proxy server. It starts alerting Bob by ringing the phone and sends a 180 RINGING response to Proxy server, at this time without information in the message body. This is indicated by the header Content-Length: 0. The message still contains two Via-headers. The Proxy server removes one Via-header, which contains its coordinates, and forwards the message to John (see Figure 4-5). Contact-header is absent, because it is never included in the responses. Note the To- and From-headers in the 180 RESPONSE are the same as they were in the INVITE-message and are not reversed. To-header still contains Bob, in spite of that message is sent from Bob. This is because these headers are used to indicate the originator of the request, not the direction of the message.
38
The original message:
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 100.101.102.103:5060To: Bob <sip:[email protected]>From: John <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: sip: [email protected]: application/sdpContent-Length: 158
v=0o=John 2890844526 2890844526 IN IP4proxy.telenor.coms=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=RTPMAP:0 pcmu/8000
Forwarded message:
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP proxy.telenor.com:5060Via: SIP/2.0/UDP 100.101.102.103:5060To: Bob <sip:[email protected]>From: John <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: sip: [email protected]: application/sdpContent-Length: 158
v=0o=John 2890844526 2890844526 IN IP4proxy.telenor.coms=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=RTPMAP:0 pcmu/8000
Figure 4-4 Forwarding the INVITE-message
Forwarded 180 RINGING message:
SIP/2.0 180 RINGINGVia: SIP/2.0/UDP 100.101.102.103:5060To: Bob <sip:[email protected]>From: John <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContent-Length: 0
180 RINGING message:
SIP/2.0 180 RINGINGVia: SIP/2.0/UDP proxy.telenor.com:5060Via: SIP/2.0/UDP 100.101.102.103:5060To: Bob <sip:[email protected]>From: John <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContent-Length: 0
Figure 4-5 Forwarding 180 RINGING response
When Bob answers the phone, a 200 OK-message is sent to Proxy server. At this time the message body contains information on the media-session to be set up. There are still two Via-headers, one of which will be removed by the Proxy server later. Presence of the Contact-header (Contact: sip:[email protected]) makes it possible for John’s UA to contact Bob’s UA directly, bypassing the Proxy server.
From this point all the communications between John and Bob continues as in the example of section 4.1.1. But proxy server is able to force both parties to route their messages through it by inserting as special header. An example of a server that may wish to use this feature is a firewall proxy server. But even if all the signalling messages are routed through the proxy, media session is still bypassing it, because SIP servers have no media capabilities.
Although we have only one proxy server in this example, a message can pass several proxies on its way. If, e.g., a DNS query made by John’s UA doesn’t return IP-address of the Proxy that handles domain telenor.com, then an INVITE-messages is routed first to the SIP Proxy server that handles domain uio.no, where John belongs,
39
and after that to the proxy server that handles domain telenor.com, where it is delivered to the receiver.
4.1.4. Call flow with SIP Redirect Server If John doesn’t know Bob’s IP-address, a SIP Redirect server can be used. There are no special restrictions on whether a logical SIP Proxy or SIP Redirect server should be used, it depends just on the physical server’s setup.
When John sends an INVITE-message to Bob, without knowing his IP-address, the message is routed to SIP Redirect server, which handles Bob’s domain (see Figure 4-6).
1 2 3
4 5 67 8 9
* 8 #
John
1 2 3
4 5 67 8 9
* 8 #
Bobdatabase/
location service
SIP Redirect server
200 OK
BYE
Media Session
ACK
200 OK
180 RINGING
INVITE
ACK
302 Moved Temporarily
INVITE
Figure 4-6 Call flow example with SIP Redirect server
Upon receiving the requests, the Redirect server maps the given SIP URL to the appropriate IP-address, by contacting database/location service. It then sends a 302 Moved Temporarily-response to John’s UA including Bob’s IP-address in the Contact-header and with empty message body. John’s UA sends an ACK-message back to the Redirect server, and from this point John’s UA can contact Bob’s UA directly. Further call flow is the same as in the example of the chapter 4.1.1.
4.1.5. SIP Registration example Until now we have referred to the fact that a Proxy/Redirect server maps given SIP URL to the appropriate IP-address, by contacting database/location service. In this chapter we’ll describe how do databases/location services acquire information about these mappings. The process for this is called “registration” and is depicted in Figure 4-7.
40
1 2 34 5 67 8 9
* 8 #
Alice
200 OK
Register
SIP Registrar server
Figure 4-7 SIP Registration example
Alice (sip:[email protected]), who is willing to register, sends a Register-message to the SIP Registrar server. The first line of the message shows that this is a Register-request and contains the address of the Registrar server. The To-header of it contains Alice’s SIP URL. As the From-header should also contain Alice’s URL, this leads to both headers being identical (see Figure 4-8). When the Registrar server receives this message, it sees both Alice’s SIP URL and her IP-address, stores this pair in the database, which can be accessed by a proxy/redirect server, and sends a 200 OK-response to Alice.
REGISTER sip:registrar.telenor.com SIP/2.0Via: SIP/2.0/UDP 300.301.302.303:5060To: Alice <sip:[email protected]>From: Alice <sip:[email protected]>Call-ID: [email protected]: 1 REGISTERContact: sip:[email protected]: 0
Figure 4-8 Registraton message
4.1.6. SIP call transfer We give a short description of SIP call transfer, which utilizes SIP REFER method [24]. This description is only intended to give a reader an idea of what it is. The more detailed call transfer procedure is found in [23].
SIP call transfer procedure is used when a person, participating in a session, wants to change a terminal and thus has to transfer the counter part to another point in that session. There are three actors in a given transfer event: Transferee, Transferor and Transfer Target. Transferee is a party being transferred to the Transfer Target, Transferor is the party initiating the transfer and Transfer Target is the new party being introduced into a call with Transferee.
41
1 2 34 5 67 8 9
* 8 #
TransferorBob’s SIP Phone
Transfer TargetBob’s Laptop
Ongoing Session
Ong
oing
Ses
sion
1 2 3
4 5 67 8 9
* 8 #
TransfereeAlice’s SIP Phone
Figure 4-9 SIP Call Transfer
The situation is depicted in Figure 4-9: Bob wants to change from his SIP phone to a laptop, while the session between him and Alice is in progress. In this case SIP User Agent on the Bob’s SIP phone is a Transferor, SIP User Agent on the Alice’s SIP phone is a Transferee and SIP User Agent on the laptop is a Transfer Target.
1 2 3
4 5 67 8 9
* 8 #
TransferorBob’s SIP Phone
Transfer TargetBob’s Laptop
1 2 3
4 5 67 8 9
* 8 #
TransfereeAlice’s SIP Phone
INVITE/200 OK/ACK
INVITE (hold)200 OK
ACKREFER
202 ACCEPTEDINVITE/200 OK/ACK
NOTIFY (200 OK)200 OK
BYE/200 OK
BYE/200 OK
Generic Session
Generic Session
Figure 4-10 SIP Call Transfer message flow
The message flow between these three entities is depicted in Figure 4-10. The first thing the Transferor does is placing the Transferee on hold by exchanging appropriate messages with it. Then the Transferor has to inform the Transferee on the reference’s URI and on the method, which should be used for contacting this reference. SIP REFER method is used for this purpose. The method comprises two messages: REFER and NOTIFY.
42
First, a SIP REFER request is constructed as defined in [RFC3261]. As it is stated in [23], a REFER request must contain exactly one Refer-To header field value. This field can take different values, but in our case, it would look like the following:
Refer-To: <sip:[email protected];method=INVITE>
Upon receiving this request, SIP User Agent B contacts the resource, identified by the URI in the REFER request, by sending an INVITE message to it. When the UA C has answered with the 200 OK message, a session between Alice’s SIP phone and Bob’s laptop is established and UA B should notify UA A on the outcome of the procedure, by sending a NOTIFY message. In our case, this message will contain the body:
SIP/2.0 200 OK
showing that the call has been successfully transferred.
The session between Bob’s SIP phone and Alice’s SIP phone may be torn down after that, but this is not a requirement.
4.2. Computing destination for request As we are considered with routing problems in this paper, it is important to understand how do the SIP entities derive an IP address from a SIP URI.
In order to be able to understand that, it should be explained what Fully Qualified Domain Name (FQDN) is and how it is related to SIP.
4.2.1. Fully Qualified Domain Name (FQDN) Fully Qualified Domain Name is a complete domain name consisting of a host name, the second-level domain name, and the top-level domain name. For example, monet.uio.no is a FQDN, where monet is the host name; uio is the second-level domain name; and .no is the top-level domain name.
FQDN uniquely identifies a MN on the network and thus it is this name, which is used in the DNS mappings <FQDN; IP address> to bind an FQDN with an appropriate IP address.
An abstract SIP service, called location service, has already been mentioned. Its responsibility is to maintain a mapping between user’s SIP URI, which is unique and known to everyone, and a SIP URI, which tells the SIP Proxy server where this user is currently available. For instance, when Bob (sip:[email protected]) logs on to the terminal with the FQDN monet.uio.no, SIP registration procedure is carried out, telling the location service that Bob should now be contacted on the SIP URI sip:[email protected]. A record is then created for Bob in the location service: <sip:[email protected]; sip:[email protected]>.
Although it is preferred that all the SIP URIs contain an FQDN in the right-hand side, it is not always the case, because many MNs do not have registered domain names, and, as follows, FQDNs. If a MN doesn’t have an FQDN, its IP address is used instead. For instance, when Bob logs on to the terminal which has an IP address
43
101.102.103.104, but doesn’t have FQDN, a record, created in the location service for Bob, looks like the following: <sip:[email protected]; sip:[email protected]>.
We shall now show how the presence or absence of FQDN influences the procedure of computing the destination for request. We shall in the both subsections consider the same example as in chapter 4.1.3, where John (sip:[email protected]) is trying to contact Bob (sip:[email protected]).
4.2.2. MN with FQDN We assume here that Bob is already registered with SIP server and a record in the location service for Bob looks like the following: <sip:[email protected]; sip:[email protected]>. A DNS entry for Bob’s terminal exists and maps terminal’s FQDN to IP address 101.102.103.104: <monet.uio.no; 101.102.103.104>.
location service
1 2 34 5 67 8 9
* 8 #
John
1 2 34 5 67 8 9
* 8 #
Bob1) INVITE
SIP Proxy server
DNS
6) INVITE3)2) 4)
5)
Figure 4-11 Computing destination when MN has FQDN
See Figure 4-11 for the interaction between units and message flow during the computation of the destination address. When John wants to contact Bob, John’s SIP UA creates a SIP INVITE message and sends it to SIP Proxy server (1). SIP Proxy server examines the message and finds out that it is destined to sip:[email protected]. In order to find out, where Bob is currently located, SIP Proxy server contacts location service (2), which returns the SIP URI sip:[email protected] to the server (3). However, this information cannot be used for routing purposes, and SIP server has to send a request to DNS, in which it should ask DNS to provide an IP address, which corresponds to FQDN monet.uio.no (4). After DNS has returned a response containing an IP address, in our case it is 101.102.103.104 (5), the INVITE message can be routed to the destination (6).
4.2.3. MN without FQDN In this case we assume that Bob is already registered with SIP server and a record in the location service for Bob looks like the following: <sip:[email protected]; sip:[email protected]>.
44
location service
1 2 3
4 5 67 8 9
* 8 #
John
1 2 3
4 5 67 8 9
* 8 #
Bob1) INVITE
SIP Proxy server
DNS
4) INVITE
3)2)
Figure 4-12 Computing destination address when MN doesn't have FQDN
Figure 4-12 depicts the interaction and message flow between the units during the computation of the destination address. As one can see, in this case SIP server doesn’t send a request to DNS, because SIP location server has returned a location-specific SIP URI, which already contains an IP address, which can be used for routing purposes. This is the major difference between the presence of the FQDN and its absence, when we are concerned with computing destination for request.
4.3. Benefits of SIP The benefits of SIP are:
• Fast call setup, which results in better bandwidth utilization, then in other signalling protocols.
• The simplicity of the protocol itself and of its messages. SIP was based largely on HTTP, which is an example of extremely successful IETF protocol, and has inherited its simplicity. That’s why implementers’ expectations are that SIP will have the same success as HTTP and that it will achieve similar positive results.
• Scalability, due to which there exist a possibility of setting up a larger number of sessions through one SIP server, than through the servers, supporting other signalling methods.
• Simple addressing scheme, where only one parameter, SIP URI, is used for addressing users.
• Conferencing capabilities, where the number of the participants is not limited.
Thus, it is possible to predict that the developers of the new advanced services and features will likely base their developments on SIP.
45
5. Problem Definition We have so far discussed Mobile IP and SIP, the two protocols that are intended to provide terminal and personal mobility respectively on the Internet. With terminal mobility provided by Mobile IP a person with a terminal is able to move freely between subnets and keep the ongoing sessions, but if the person changes the terminal, he is not reachable for the corresponding parties any longer, as they don’t know where he is situated now. With personal mobility provided by SIP, a user can stay reachable for corresponding parties even if he changes terminals and these parties don’t need to be aware of user’s current location.
In future wireless networks that are IP-based networks, both Mobile IP and SIP are needed, although they serve for different purposes. It is, however, quite undefined how the integration of these two protocols should be done. Before proceeding with challenge description it is prudent to mention the philosophy behind Mobile IP and SIP.
In Mobile IP the motivation is to force a terminal to handle changes in the IP address in such a way, that the process of changing remains seamless to a user. Mobile IP belongs to the network-layer of the TCP/IP protocol stack and is thus not concerned with whether the user of the terminal is the same person or not.
One of the motivations behind SIP is to be able to contact a user independently of his current point of attachment to the network, rather find it out by means of a unique identifier, which each user gets assigned. SIP belongs to the Application-layer of the TCP/IP stack, what makes it a more “user-oriented” protocol than Mobile IP.
5.1. Challenges in implementing Mobile IP and SIP on the same network
The start point for all the problems of mobility is the need to change IP address, when subnet changes. Mobile IP was originally designed to cope with this problem, but SIP doesn’t have any mechanisms to register that the current IP address of the user has changed, unless the user logs off the SIP application and logs on to it again. Note, that we use term current IP address to identify the IP address of the terminal on the physical level: current IP address can be its Home Address when the terminal is in its home network and it can be Foreign Address, when the terminal is in the foreign network.
So, there are several intercepting problems, concerning implementation of Mobile IP and SIP on the same network:
• How would SIP behave if the IP address of the terminal changes?
46
• Is there a need for modifying SIP, in order to force it to handle changes in the IP address? If yes, in what way should SIP be modified?
• How will the behaviour of SIP influence the behaviour of Mobile IP and vice versa.
• Is there a need for modifying Mobile IP? If yes, in what way should the Mobile IP be modified?
• How will other network elements be influenced by the presence of both, SIP and Mobile IP at the same time?
• What consequences will the interaction between Mobile IP and SIP have for other problems, such as route optimization and TCP performance?
There exist several possible solutions to each of these problems, and they cannot be regarded separately. Each solution only makes sense when considered along with the other solutions, when they are regarded as one problem. Thus, we have in all identified four possible approaches for Mobile IP and SIP interaction. In each of the approaches the above problems are solved in different ways, but nevertheless they contribute to one common solution either acceptable or not.
The approaches will be discussed throughout this thesis according to the following plan: first we give a short description, a sketch, for each approach. Second, we go thoroughly through the details of each approach in order to show what entities would be involved and how the message exchange would flow in each case. To achieve a better overview of this detailed description, we have divided it into three parts: “Handover ‘Home Network – Foreign Network’”, “Handover ‘Foreign Network – Foreign Network’” and “Login Procedure from the Foreign Network”. Third, we emphasize the advantages and disadvantages of each of them for the following points: Complexity, Bandwidth utilization, Protocol impacts, Security issues, Handover issues and Extensibility.
After we are finished with all the approaches, we compare them and try to give an orientation on from which one the user will benefit most.
Note that in our further discussion we use 3 different terms: User, SIP User Agent (SIP UA) and Terminal. Terminal identifies any terminal (phone, computer, PDA, etc.) used by a person, SIP User Agent identifies a SIP User Agent installed on that terminal and User identifies a person, who is moving around with the Terminal B and is using SIP User Agent to identify himself over a SIP server.
5.2. Assumptions and limitations Although the problem of implementing Mobile IP and SIP on the same network is huge and has many different aspects, we’ve made some limitations to the problem, according to which we shall proceed.
1. First of all, we are looking only at the IPv4 and do not consider IPv6 at all. Although IPv6 is already defined, it is quite unsure when the implementation on the global scale will start. As the first implementations of Mobile IP and SIP will be truly based on IPv4, we choose to base our paper on this protocol
47
rather than IPv6. Another reason for why we do not consider IPv6 is that IPv6 provides many other functions, which are not provided by IPv4. Thus, the problems that appear in the implementation of Mobile IPv4 and SIP are different from the problems of Mobile IPv6 and SIP.
2. Second, we do not take into consideration a proposed solution for route optimization in Mobile IPv4 [20], in spite of that we are always trying to optimize route as much as possible in our work. This solution adds a new data structure, the binding cache, to correspondent nodes and to Foreign Agents. This means that in order to be able to benefit from route optimization all the CNs and all the FAs should implement this new data structure. It is obvious that such a requirement is somewhat difficult to achieve for all the CNs, thus it is very unlikely that it will be deployed widely in the near future. There are also other drawbacks in that solution, but all of them are out of the scope of this document.
3. Third, when talking about a session between the calling and the called parties, we mean just a generic session, whether it is TCP, RTP or UDP doesn’t matter for us, because our goal is to look at the problem and try to suggest solutions in general, not for a specific transmission protocol.
4. Fourth, we do not discuss the problems of security as long as they do not open for severe security holes in the system, because methods for secure communication are implicitly provided by both protocols. We do not pay attention to the problem of NAT in the SIP or Mobile IP environment either, because this topic is worth a separate paper.
5. Fifth limitation is that we are not concerned with the situations when a person changes terminals or when several persons are using the same terminal. We are interested in one particular case: how would SIP and Mobile IP behave when one user is moving between network segments using the same terminal all the time.
6. Sixth limitation is that we do not look at the problem of accounting at all, because this problem is a general problem of Mobile IP and solution to it requires detailed investigation.
7. The last thing to be mentioned here is that we are only concerned with the case when SIP server is in the terminal’s Home Network. SIP server in the Foreign Network requires further definition within SIP framework and we don’t wish to address that point in this work.
5.3. General Network Model We provide a description of general network model, which is we rely on in our paper. This model is shown in Figure 5-1.
48
AAAF
DHCPServer FA
SIP Proxyserver
Foreign Network Home Network
Home NetworkForeign Network
HA
AAAH
SIP locationservice
Internet
dynDNS
Mobile Node
SIP UA
Figure 5-1 General network model
As one can see, we differ between Mobile Node (MN) and SIP User Agent (SIP UA) installed on that MN. Although these two will always be relocated together, it is sufficient to separate them for the sake of better understanding.
We differ also between two networks: Foreign Network and Home Network.
The units in the Home Network are:
• Home Agent (HA) - A router on a mobile node's Home Network, which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node [18]. (Note that when HA is allocated dynamically, it may be situated in the Foreign Network as well, but will serve the same purposes as before.)
• SIP Proxy server with SIP location service – a SIP application, which is responsible for mapping SIP URIs to IP addresses, for forwarding the incoming requests to these addresses and responding to the requests [16].
• AAAH – Authentication, Authorization and Accounting unit in the Home Network.
• dynDNS – a Domain Name System where the entries can be updated dynamically on the terminal’s demand.
The units in the Foreign Network are:
• Foreign Agent (FA) – a router on a mobile node’s Foreign Network, which provides routing services to it while registered [18].
• DHCP Server – a server responsible for dynamic configuration of a terminal, entering that network, and for updating dynDNS with the appropriate data.
• AAAF – Authentication, Authorization and Accounting unit in the Foreign Network.
49
6. Approach 1
6.1. Overview This approach is a “straight forward” method of integration of Mobile IP and SIP, where Mobile IP is responsible for terminal and session mobility, and SIP is responsible for session initiation. As we have assumed that we always deal with one user, who is using only one terminal, personal mobility is implicitly provided by Mobile IP in this approach and the user remains motionless to SIP server.
Message flow for Approach 1 is sketched in Figure 6-1. In short, the message flow for this approach can be described this way: User A wants to communicate to User B and SIP UA A sends a SIP-Invite message, which is first routed to SIP server, where location of User B is determined and the message is routed to his Home Address. Home Agent forwards this message to the FA, which currently serves Terminal B, without any concern on what kind of message it is. When SIP UA B answers the Invite message, it sends a 200 OK response to the SIP server, which then sends it to SIP UA A. A session between the terminals is set up.
SIP sends all the messages only to the Home Address of the user, without any knowledge on whether the user is moving or not. The user appears to be at the same IP-address all the time for SIP.
FA
MN BSIP UA B
MN ASIP UA A
SIP Server
1) IN
VITE4)
200 O
K
Session Initation
Session
HA2) INVITE3) 200 OK
Figure 6-1 Scenario 1
In this approach we are only concerned with the case when FA Care-of Address is used when a MN is in the foreign network. We do not pay attention at the case of co-
50
located Care-of Address as the situation will be exactly the same for either of Care of Addressing mechanisms.
We do not consider whether the terminal has registered FQDN or not in this case, because the same information is provided to the SIP Registrar during the registration procedure all the time independent of the current IP address of the terminal. This is because the Home address, and consequently the name to address resolution, is permanent. Thus we will assume that an IP address is used to identify the terminal and network connection point.
Recall, that SIP registration request is always sent to SIP server when the user is logged on to the terminal and not when the terminal has received a new IP address. This is because SIP is aimed at providing personal mobility. Thus SIP cannot assume that a person can be permanently associated with a specific terminal and a specific network connection point, e.g. IP address.
We would like to divide this chapter into three sections: “Handover ‘Home Network – Foreign Network’”, “Handover ‘Foreign Network – Foreign Network’” and “Login procedure from the Foreign Network”. The first one describes how the handover procedure is handled if User B moves from Home Domain to Foreign Domain without logging off the SIP application, i.e. SIP registration procedure is not carried out after the handover. The second one describes how the handover is handled if User B moves from one Foreign Domain to another Foreign Domain without logging off the SIP application. The third subsection describes what happens if User B starts SIP application while staying in the Foreign Network, i.e. how the SIP registration proceeds.
6.2. Detailed Description
6.2.1. Handover “Home Network – Foreign Network” Let’s first look at the situation when User B is logged on the Terminal B while in his Home Network (see Figure 6-2). We assume that the terminal has already registered it’s home address with the Home Agent. Upon users in logging a SIP-registration is carried out, notifying the SIP location service of the IP address, on which the user is reachable. Then the user is ready to communicate to other parties through standard SIP and Mobile IP.
SIP Proxy Server
Internet
Terminal A/SIP UA A
HA
Terminal B/SIP UA B
1) INVITE
4) 200 OK
2) INVITE
3) 200 OK
Session
Figure 6-2 The MN is in its Home Network
51
When User A wants to contact User B, SIP is responsible for setting up a session between them. The message flow is depicted in Figure 6-2. SIP UA A sends first an initial INVITE message to SIP server (message 1), which forwards this message to SIP UA B (message 2). When User B accepts the call, SIP UA B sends a 200 OK response to SIP UA A via SIP server (messages 3 and 4). After SIP UA A has received this response a session is set up between Terminal A and Terminal B with the parameters, which were negotiated through SDP during the setup phase. These parameters include connection IP address, media format, port number, media transport protocol, media encoding and sampling rate.
If the session is ended before User B has moved to another network segment, no problems occur. In this case a MN functions in the same way as a stationary computer. But we would like to look at the situation when User B moves to another segment before the session is ended. In this case the session mobility is provided by Mobile IP as shown in Figure 6-3. Note that in this figure we’ve depicted one session as two different arrows: one from Terminal A via HA to Terminal B and one from Terminal B directly to Terminal A. This is done to show the presence of triangle routing, where packets destined to Mobile Node travel to Home Agent first and then to the Mobile Node, but packets sent from Mobile Node travel directly to the destination. Exception here would be networks with ingress filtering, where Mobile Node must use reverse tunnelling. This is shown in Figure 6-4, where one session is depicted as one arrow.
Internet
Session
Terminal A
HA
Terminal B
FA
SIP Proxy Server
Figure 6-3 RTP Session behaviour without reverse tunnelling
52
Internet
Session
Terminal A
HA
Terminal B
FA
SIP Proxy Server
Figure 6-4 RTP Session behaviour with reverse tunnelling
Relocation of the terminal would cause a need to forward all the packets to its new IP address, which in turn would influence data transmission between Terminal A and Terminal B in that way that packets would have to travel a longer distance, than they would have to if they were sent directly to Terminal B and also that they would have to be processed in HA. This would have consequences for both non-real-time services and for real-time services. Non-real-time services would suffer in that way that longer delay will be introduced and more retransmissions will be needed in order to deliver all the necessary data packets that were lost on the way. All these factors would influence the total transmission time, but wouldn't influence the quality of the received data, as the application would wait until the last packet is received. Either transmission protocol or service itself would control the amount and sequence numbers of the received packets.
The situation is worse for real-time services. Data packets, used in such services, usually have an expiration time, during which they should be "used". If they are not used during this time they should be cancelled. That's why these services have very high demands on delay. First let's look how the processing in the HA would influence the service.
In order to process all the incoming packets, it should store them in a local buffer first. The size of this buffer cannot guarantee that it won't get overloaded and no packets would be cancelled because of this. It is especially the case when the transmitted data are synchronized video and audio streams of high quality, e.g. an animated movie with high resolution. For the service such overloading of the buffer would mean absence of data packets which it needs at a certain period of time and for the end user of the service it would mean a disturbed or even stopped movie, if the amount of cancelled packets is too large.
Now let's look how the real-time service would be influenced by the longer distance, that the packets have to travel. Actually, they would suffer from the same problem as during the processing in the HA, because they would have to travel via routers,
53
which have a similar principle of work. This means that in the routers they would be stored in local buffers very much like in the HA, but the processing time would differ. A router only has to forward packets to the correct output, by comparing the subnet portion of the destination IP address of a packet to the available outputs. The HA has to encapsulate the original packet in outer packet, traverse the list of all the MNs it serves to find the address of the FA, where this MN is currently attached, and to forward the encapsulated packet to that FA.
Recall that we are now talking about a situation when a user is logged into his terminal while staying at his Home Network. It is obvious that it won’t be a trivial situation that a user would travel as far away as 10 000 km from his Home Network while staying logged on. However, this is not impossible and if we take into consideration the worst case, the complete picture would look like in Figure 6-5. An example for this situation can be the following: User B, whose Home Agent is placed in Norway, is currently in USA and is communicating to User A, which is also in USA at the moment. It is clear that their communication, either audio or video, would suffer greatly from the delay, caused by distance the packets have to travel.
Terminal BFA
RTP Session
Terminal A
HA
Figure 6-5 Routing of the packets. Worst Case.
Although the problems described in the last paragraphs are a part of Mobile IP’s functionality, they can be avoided in some cases where the SIP environment is present. The situation where one can escape processing of packets in HA is described in section “Scenario 2” and the advantages and disadvantages are highlighted as well.
If User B still remains in the foreign domain and wants to end the session, SIP UA B simply sends BYE message to SIP UA A and awaits a 200 OK message from it, a kind of confirmation that User A accepts session’s tear down. After this confirmation is received the session is ended. What happens if User B wants to move to a new subnet if the session is not ended is described in the next section.
54
6.2.2. Handover “Foreign Network – Foreign Network” If User B moves to another subnet, the handover is handled by Mobile IP, as defined by RFC 2002. SIP is not aware of user’s relocation, because SIP registration is not carried out in this case.
InternetTerminal A
HA
FA 1
Terminal B
FA 2
Session
Figure 6-6 Handover " Foreign Network - Foreign Network"
Figure 6-6 shows how Mobile IP handles such relocation. MN’s HA acts as a control unit, which controls the handover. What actually happens is that HA deletes an old tunnel to the old FA and establishes a new tunnel to the new FA and start forwarding all the packets to that new FA.
Since it is a pure Mobile IP handover, we won’t discuss it in more details here. As before, SIP server continues to forward all the packets to the MN’s Home Address.
6.2.3. Login procedure from Foreign Network Now consider the situation when User B is in the Foreign network. Assume that the terminal receives an IP address and Mobile IP registration procedure is carried out. When the user logs on the terminal and to the SIP application, SIP user agent sends a REGISTER request to SIP Registrar. This request contains either FQDN of the terminal or the original IP address of it, i.e. Home Address, in the To-field. After the User B is registered with this IP address in the SIP location service, all the SIP messages, destined to User B are forwarded to the terminal’s Home Address.
SIP messages will include Home Address of the terminal rather than Foreign Address due to Mobile IP. This feature of Mobile IP applies to all the applications and processes, which are placed above Mobile IP, i.e. above network layer, in the TCP/IP protocol stack. Mobile IP is responsible for hiding all the information, regarding terminal mobility, from the rest of the system.
After the User B has registered with SIP Registrar, the session set up proceeds as shown in Figure 6-7. The same messages, as in Figure 6-2, are exchanged between the units in the same sequence. The difference is that messages from SIP Proxy server to SIP UA B are now encapsulated by the HA and are decapsulated by the FA on their way to Terminal B. On their way back they go directly to SIP Proxy server.
55
If foreign network implements ingress filtering, reverse tunnelling is required. In this case both messages, to and from Terminal B, have to go through the tunnel between HA and FA (see Figure 6-8).
Internet
Session
Terminal A
HA
Terminal B
FA
SIP Proxy Server
1) INVITE
2) IN
VITE
3) 200 OK
4) 200 OK
Figure 6-7 Session initiation from Foreign network
Internet
Session
Terminal A
HA
Terminal B
FA
SIP Proxy Server
1) INVITE
2) IN
VITE
3) 20
0 OK
4) 200 OK
Figure 6-8 Session initiation from Foreign network w/reverse tunnelling
When a session is initiated, a complete picture of packets’ routes would be the same as in Figure 6-3 after the User B has moved to another network. If User B moves to another subnet while a session is on, the handover is handled by Mobile IP in the same way as in Figure 6-6.
6.3. Required Additional Functionality for Approach 1 As this approach is a “straight-forward” method of implementing Mobile IP and SIP, no additional functionality is required.
56
6.4. Analysis
6.4.1. Complexity The whole system in Approach 1 functions without any additional elements, either protocols or units, being introduced. This makes it rather simple to implement and administrate. The unambiguous advantage of this approach is that it doesn’t require any modifications to be done into neither SIP nor Mobile IP. There is no need to design additional functionality to make them work together.
6.4.2. Route efficiency As it is described in this chapter, messages, destined to the terminal, travel always via its HA, independently of how far the terminal is from the HA. If reverse tunnelling is required, then also the message from the terminal have to travel via its HA. This leads to a very inefficient routing, compared to the case when the packets can take the shortest path between the corresponding parties. Little attention is paid to the problem of routing efficiency in this approach in order to provide user’s mobility at the best possible degree.
6.4.3. Security issues Approach 1 is a “straight forward” method of implementing Mobile IP and SIP in the same network. It doesn’t open for other security threats and thus doesn’t demand any additional mechanisms, besides the ones that already exist for Mobile IP and SIP. As the security solutions for these problems are already described in the Mobile IP and SIP specifications, this topic is omitted here.
6.4.4. Handover issues Approach 1 provides full mobility for a MN and supports all the types of handovers, independently whether it is handover between two subnets in one domain or between two administrative domains. In theory, this mechanism is free from faults, but in practice it would suffer from long delay during the handovers. This delay is introduced by the time it takes a MN to receive a dynamic IP from the subnet, it has just entered, the Mobile IP registration time, the time it takes HA to establish a tunnel to the FA (or co-located Care-of Address) and, in the case of TCP connection, the time needed to re-send all the packets, that have been lost during the handover. It is obvious, that the handover is far from being seamless and that both parties will experience disturbance in the conversation during it. The problem of diminishing the time it takes to perform a handover remains an open issue.
6.4.5. Protocol impacts Approach 1 doesn’t require any changes to be done to other protocols, as it utilizes both SIP and Mobile IP in exactly the same way as is proposed in their specifications. We have not identified any need for modifying any other protocols either thus proving once again that Approach 1 is a “straight forward” method.
57
6.4.6. Extensibility We can think of extensibility of any approach in two ways: the extensibility from the IP stack’s point of view and from the network architecture’s point of view. The first term implies introduction of new protocols into the system and of new extensions to the existing protocols, while the latter one implies expansion of the networks by introducing more units, which have the same functionality as the ones that already are installed on the network.
There are no extensibility issues others than those faced by Mobile IP and SIP.
58
7. Approach 2
7.1. Overview The purpose of this approach is to achieve optimized routing of the messages, exchanged between Terminal A and Terminal B. In Approach 1 all the messages flow through the HA on their way to or from the recipient, thus increasing end-to-end delay and reducing the efficiency of routing. In Approach 2 we avoid the tromboning effect by avoiding the use of the HA in the routing path
SIP is used as a mean for optimizing the route. When a SIP UA sends an initial INVITE or a 200 OK message as a response to the INVITE, it provides its local point of attachment, i.e. Care-of Address, instead of its Home Address, to the corresponding party such that further communications will not be routed through the Home Agent. However the Home Address is still the one registered in the SIP server for reachability purposes. This is similar to the previous approach. We will however discuss the different weaknesses of this scheme in the following sections.
We will in this chapter assume the simplest case, when Terminal A is fixed and User A is thus not able to relocate. Also SIP server is configured in the way that it simply relays the messages from one SIP UA to another, without checking the contents of these messages. Thus, if we come to a conclusion that this approach doesn’t work with the simplest case, this conclusion will also apply to all other cases, when more complex configuration is used.
HA
MN BSIP UA B
MN ASIP UA A
SIP Server
1) IN
VITE4)
200 O
K
3) 200 OK
Session Initation
2) INVITE
Session
Figure 7-1 Scenario 2
A sketch for message flow for Approach 2 is shown in Figure 7-1. In the previous approach HA was used to route all messages from User A to User B. In this one only the SIP-Invite message is routed through HA, further communications take place
59
directly between SIP UA B and SIP Server in the session initiation phase, Terminal A and Terminal B in the conversation phase and SIP UA A and SIP UA B in the session tear down phase.
With this approach User B can experience the best possible quality, because no additional processing in HA is required. But there is a number of problems, involved in this approach. These problems are reviewed in the following discussion, solutions to these problems are discussed and advantages and disadvantages are highlighted as well.
In Approach 1 we have only discussed a case when a FA Care-of Address is used, assuming that no sufficient difference will appear if a co-located Care-of Address is used instead. In Approach 2, however, we cannot make the same assumption, because the situation will be completely different for FA Care-of Address and for co-located Care-of Address. The reason for this is described in the section 7.1.1. Thus, a requirement for this approach is that a MN always uses co-located Care-of Address when in the Foreign network.
As in Approach 1, we are not concerned with whether the terminal has registered FQDN or not in this case either, because the same information is provided to the SIP Registrar during the registration procedure all the time and User B remains motionless for SIP server.
In this chapter we give a detailed review of what messages are sent between the units, involved in the communication process, what information they carry and how they are processed by the units. As we describe these details, we identify the problems, from which the whole communication process would suffer and propose possible solutions to these problems.
In the same way as for the Approach 1, we are going to describe Approach 2 from three points of view: “Handover ‘Home Network – Foreign Network’”, “Handover ‘Foreign Network – Foreign Network’” and “Login procedure from the Foreign Network”.
7.1.1. FA CoA vs. co-located CoA In Mobile IP several MNs can share the same FA Care-of Address, while a particular co-located Care-of Address is owned by only one MN. Thus, a FA would function differently for either of the care-of address types. Consider Figure 7-2, which shows how packets are routed to the MNs with different address types on the Foreign network. In this figure we consider a situation when the MN with co-located CoA is connected to the network, which provides FA service. Although it doesn’t need to be the case all the time, we use it to show the difference in the FA functionality.
60
HA
Internet
FA Care-of Address
FA 2
Co-located Care-of Address
FA 1
Figure 7-2 FA Care-of Address vs. Co-located Care-of Address
When a MN has a FA Care-of Address, the FA serves as a tunnel end-point for the packets. Each FA keeps track of all the MNs it serves in the form of visiting list, where, along with other MNs data, its Home Address is stored. Upon receiving an encapsulated packet, the FA inspects the destination address of the inner packet and compares it to the entries in the visitor list. If no entries match, the packet is silently discarded.
When a MN has a co-located Care-of Address, FA doesn’t serve as tunnel’s end-point any longer, but rather as a usual router, which routes the packets to the appropriate destination. In this case the packet is not decapsulated by the FA and the inner packet is not inspected. The packet is only forwarded to the address, which is stated in the destination field, by the FA. The MN itself is responsible for de-encapsulation of the packet in this case.
This difference in FA’s functionality has a great influence on Approach 2. If we want the packets, destined to the MN on a foreign link, travel directly to that MN, only co-located Care-of Address is allowed in this case. If we just imagine a situation that a CN learns the MNs FA CoA and tries to send a packet, which is not encapsulated, to this address, the packet will be discarded by the FA, as it won’t be able to determine which MN this packet is destined to.
7.2. Detailed Description
7.2.1. Handover “Home Network – Foreign Network” When the terminal is turned on while staying in its home network and User B is logged on to this terminal, a Mobile IP registration and SIP registrations are carried out in the same way as in Approach 1, i.e. in the same way as described in the Mobile IP and SIP specifications. Until the user stays in the terminal’s home network no problems in the communication process occur and no differences between Approach 1 and Approach 2 appear.
The situation gets completely different when the User B decides to move from the home network to another network. Upon entering a new network Terminal B obtains a co-located Care-of Address and registers with its HA with this address. After that, a
61
tunnel is established between this HA and this terminal and all the messages, destined to it, should be sent using this tunnel. This is how the conversation proceeds according to the Mobile IP specification and this is how it proceeds in Approach 1.
The goal of Approach 2 is, however, to optimize the route between Terminal A and Terminal B as much as possible, i.e. to adjust all the circumstances so that messages can flow directly from A to B and vice versa.
Let’s study in details, what happens when the User B changes the subnet. As the User B doesn’t log off in this case, SIP registration is not carried out when this terminal receives a new IP address. Even if the user had re-logged on, it wouldn’t have any influence, because Mobile IP would have provided for the registration with the Home Address. Thus, SIP is not aware of User B’s relocation, and does not influence the handover.
Terminal B
Internet
HA
Terminal B
Session after the handover
Session before the handover
Terminal A
Figure 7-3 RTP Session relocation
Our goal is to force the session to be moved as shown in Figure 7-3, in order to optimize the route of the packets. As one can see from the figure, one end-point of the session remains the same as before (Terminal A), and the other one (Terminal B) is being relocated and the Terminal B is being assigned a new IP address. The parameters, identifying session’s end-points, no longer correspond to the ones that were provided to the Terminal A in the session set-up phase. From now on Terminal B appears to be a completely new host for the Terminal A. Thus, Terminal B has to authorize itself over Terminal A by some means and after that Terminal A has to move the session’s end point. Even if we assume that such authorization is possible, it is still undefined how Terminal A will handle session relocation.
Thus, it is not possible to keep the ongoing session and obtain a direct connection between sender and receiver with Mobile IPv4.
So, if it is not possible to keep an ongoing session during the handover, we would like to look at the situation when the session is stopped before the handover and started again as a new session, where Terminal B provides its FA care-of address to the counter part.
62
Of the same reasons as in the previous approach, SIP server is not aware of user’s relocation. Thus, when User A invites User B to a new session, the INVITE message is sent first to the SIP server, which forwards the message to the IP address, with which User B is registered on the server. This IP address is the Home Address of the Terminal B. So, the INVITE message is routed to the HA of the Terminal B first and only after that it is tunnelled to the co-located Care-of Address, i.e. to the Terminal B. When SIP User Agent B receives this INVITE message it may answer either using reverse tunnelling or sending the response directly to the SIP server (see Figure Sc1-9 for message flow without reverse tunnelling). But in both cases Mobile IP would provide for inserting terminal’s Home Address into response. All the further communications would go via the HA, as neither SIP server nor User A are aware of User B’s relocation. Such a situation is not desirable in Approach 2.
InternetTerminal A/SIP UA A
Terminal B/SIP UA B
Session
1) INVITE
3) 200 OK
SIP Proxy Server
HA4) 200 OK
2) IN
VITE
Figure 7-4 Handover “Home Network – Foreign Network”
According to the sketch of Approach 2, given in the description of this scenario, the message flow should look like the one showed in the Figure 7-4. When User A invites User B to the new session, SIP UA A sends an INVITE message to the SIP server, which forwards it to the Home Address of the Terminal B, and the HA then forwards the message to the terminal. Upon receiving this message SIP UA B sends a response directly to the SIP server. If we compare the session initiation phase of this figure with the session initiation phase of Figure 6-7 of Approach 1, we would notice that the message flows are identical, except that the tunnel’s end point has been moved because of co-located CoA.
The major difference, however, resides in the Contact – field of the messages, sent by SIP UA B. In Figure 6-7 this field contains the Home Address of the Terminal B, while in Figure 7-4 it is desirable to insert the Terminal B’s co-located Care-of Address into this field. In order to be able to do that, an additional mechanism is required, that would make it possible to insert terminal’s co-locate Care-of Address into the appropriate fields of SIP messages instead of the address, provided by Mobile IP, i.e. the terminals Home Address. This mechanism is described in the section 7.3.
63
When the 200 OK response arrives at the SIP server, SIP server simply forwards it to User A, without examining the content of the response. This is because it is a general SIP rule that most SIP requests are end-to-end messages between user agents, what means that proxies simply forward the messages they receive from the UAs, relying on the UAs to generate that message.
After the 200 OK response has been received by SIP UA A, a session is established between Terminal A and Terminal B.
In the next section we show what happens when User B decides to move to another Foreign network while ongoing sessions exist.
7.2.2. Handover “Foreign Network – Foreign Network” If User B decides to move to another Foreign network while ongoing sessions exist, we get the same problem of session relocation, as in the previous section, which is depicted in Figure 7-3. As it has been shown in the previous section, it is not possible to relocate a session in the way, depicted in the figure, thus, it is necessary to stop the session and start it again after the terminal has been relocated.
We now assume that all the ongoing sessions are stopped, but user doesn’t log of the SIP application. Although the current IP address of the terminal changes, SIP registration is not carried out and SIP server is not notified on the new IP address, on which User B is currently available. User B remains registered on the SIP server with the Home Address of the Terminal B.
InternetTerminal A/SIP UA A
Terminal B/SIP UA B
1) INVITE
3) 200 OK
SIP Proxy Server
HA4) 200 OK
2) IN
VITE
Session
Foreign Network 1
Foreign Network 2
Figure 7-5 Handover " Foreign Network - Foreign Network"
When User A wishes to invite User B to a session, session initiation phase, depicted in Figure 7-5, is almost identical to that of Figure 7-4. The only difference is that now User B is in another Foreign network, thus it has a different co-located Care-of Address, which it provides in the Contact-field of the 200 OK message.
64
7.2.3. Login procedure from the Foreign Network As in this approach User B remains “motionless” for SIP server, very much like in the previous approach, there is no need to notify SIP location service on the co-located Care-of Address of the terminal B. Thus, the login procedure is carried out in the same way as in Approach 1 and is described in section 6.2.3.
After the registration procedure is finished, session setup proceeds in the same way as in Figure 7-4.
7.3. Required Additional Functionality for Approach 2 Approach 2 requires only one additional mechanism in order to achieve the desired functionality.
This mechanism should be a kind of interface between Mobile IP and SIP, which should be responsible for providing a terminal’s CoA to SIP for inserting into the Contact-field of the responses. In all the other cases it should provide the terminal’s Home Address.
In order to be able to do that a terminal should always be aware of the terminal’s co-located CoA, and monitor creation of SIP messages. Each time a 200 OK response is created, the interface should force SIP UA to provide the co-located address (if there is one) in the Contact-field. It should also control that the terminal’s Home Address is used in all the other fields. If no co-located CoA is available, i.e. the terminal is in its Home Network, the terminal’s Home Address should be provided in all the fields of the response.
7.4. Analysis
7.4.1. Complexity When considering the amount of additional mechanisms needed, this approach cannot be considered to be complex, as it requires only one interface, serving one function, be developed.
But from the end-user’s point of view, the approach is very complex, as it requires all the ongoing sessions be ended before changing the subnet and started again upon finishing relocation. Such a feature is very inconvenient and disturbing for the end user.
As for the whole system, the complexity of the approach is also very high, because the system possesses a lot of features, provided by Mobile IP, but the most of them are not used, as they are replaced by other solutions in this approach.
7.4.2. Route efficiency Approach 2 is the approach where the route efficiency is provided at the best possible degree by providing a direct route between the two communicating parties. Some signalling messages, however, have to travel to the SIP Proxy server and to the HA, but they don’t carry large amounts of the information compared to those, carried by the session-packets, and can therefore be ignored.
65
7.4.3. Security issues A great security hole appears in this approach, when User B sends a 200 OK response, inserting the terminals co-located CoA into the Contact-field of the message. Then a malicious user can intercept the initial INVITE message and send a response pretending to be User B, where he would try to fake the address in the Contact-field. In order to avoid it, SIP UA A should perform User-to-User Authentication [7] upon receiving 200 OK from SIP UA B.
In the rest of the Approach 2 no other security problems are arisen and thus it is enough to implement security mechanisms specified for Mobile IP and SIP.
7.4.4. Handover issues Approach 2 doesn’t support any types of handovers, as it has been showed in this chapter. The reason for this is that we are trying to optimize the route as much as possible, thus implicitly avoiding Mobile IP from serving its primary purpose in this approach, i.e. providing terminal mobility and session mobility. SIP, however, doesn’t provide session mobility along with personal mobility, thus making it difficult to perform a seamless handover. When user relocates, all the sessions need to be stopped and started again after the relocation.
7.4.5. Protocol impacts This approach influences Mobile IP in that way, that it doesn’t utilize its primary functionality at all. The only thing Mobile IP is used for is to route the initial message to the appropriate IP address, at which user is currently available. The same functionality can be provided by SIP location service, if we force SIP UA to update the information on that service each time the terminal changes subnet, provided that User B remains logged on to the SIP application. With such a functionality we get a pure SIP environment, where Mobile IP is not involved at all, hence making this protocol unnecessary for the whole system.
7.4.6. Extensibility It is not a problem to extend the network of Approach 2 from SIP point of view, as this protocol is not affected by this approach at all. What about Mobile IP, we have already shown that this protocol is not serving its primary purposes in this case, thus, it becomes meaningless to provide extensibility from Mobile IP point of view.
66
8. Approach 3
8.1. Overview In Approach 2 we were trying to provide support for terminal mobility by SIP. As SIP was not developed and should not provide this type of mobility (the feature, known as Layer independency, which provides that the goals of different layers should not intercept), it was shown to be an awkward approach to solving the problem. In Approach 3 we are trying to cope with the limitations of the previous approach by combining the handover management mechanisms of SIP and Mobile IP. The SIP refer method is used for that purpose. This method is usually used for supporting change of terminal while in an active session. We use that method here as changing IP address could be seen as a similar case to changing terminal (which implies a change of IP address).
HAMN ASIP UA A
SIP Server
2) REFER
Session Initation
MN BSIP UA B
1) Session after Mobile IP handover
3) INVITE5) Session after SIP call transfer
4) 200 OK
Figure 8-1 Scenario 3
A sketch for message flow is depicted in Figure 8-1. It is assumed that a session between Terminal A and Terminal B is already started when User B moves to another subnet. The handover is first handled by Mobile IP as defined by RFC 2002. After that SIP call transfer procedure is started by SIP UA B. During this procedure User A is “referred” to B’s new IP address at the same terminal, Terminal B. After that SIP UA A sends a new INVITE message to SIP UA B and a new session is established between Terminal A and Terminal B.
In this approach we utilize a Mobile IP handover procedure along with the SIP call transfer procedure [23]. Of the same reasons as in the previous approach, only co-
67
located care-of addresses may be used by the MNs when in Foreign Network and SIP UA should always use the terminal’s IP address when sending SIP registration request.
This chapter is divided into the same subsections as the two previous chapters: “Handover ‘Home Network – Foreign Network’”, “Handover ‘Foreign Network – Foreign Network’” and “Login procedure from the Foreign Network”.
8.2. Detailed Description
8.2.1. Handover “Home Network – Foreign Network” When talking about handover from Home Network to Foreign Network we assume that all the registration procedures are carried out and a session between Terminal A and Terminal B is in progress.
A description of handover Approach 3 is depicted in Figure 8-2. When the Terminal B changes the subnet, the handover is handled by the Mobile IP and the session between Terminal A and Terminal B proceeds in the same way as in Approach 1, i.e. a tunnel is established between the HA and the Terminal B and all the packets are tunneled to the Terminal B.
At this point, after the Mobile IP handover has succeeded, the UA B can start SIP call transfer procedure, where one terminal, Terminal B, will act as both Transferor and Transfer Target at the same time. The difference is however, that it will use its Home Address when acting as a Transferor and its co-located care-of address when acting as a Transfer Target. The Terminal A will act as a Transferee.
Internet
1) Session after Mobile IP Handover
4) 200 OK
3) INVITE
2) REFER
Terminal A/SIP UA A
Terminal B/SIP UA B
5) Session after SIP call transfer
SIP Proxy Server
HA
Figure 8-2 Mobile IP Handover followed by SIP call transfer
When sending a REFER request, SIP UA B should provide the Terminal B’s co-located care-of address in the Refer-To field of the request and send it to SIP UA A using Home Address as the source address of the packet. Thus, the UA A will
68
assume that User B is changing a terminal and will send an INVITE to the IP address provided in the Refer-To field, i.e. to the co-located care-of address. As such feature is not supported by today’s Mobile IP and SIP, there is a need for an additional mechanism that would be responsible for inserting the appropriate IP addresses into the appropriate fields of SIP REFER message.
Upon receipt of REFER message, SIP UA A sends an INVITE to SIP UA B at the co-located care-of address. When sending a 200 OK response to it, SIP UA B should provide only the terminal’s co-located CoA in all the fields of the response. Thus, there is also a need for a mechanism that would control the insertion of the appropriate IP addresses into the SIP messages.
After the SIP UA A has received the 200 OK response, two sessions are in progress between Terminal A and Terminal B, but that of them, which goes through the HA, is remained on hold. Although REFER method doesn’t require the original session to be torn down, in this approach it should be done anyway. This is because there is no reason to keep two ongoing sessions, which are transporting the same data packets, between two parties, especially when one of them is introducing much longer delay than the other one.
The existence of two similar outgoing sessions on the Terminal A arises the problem of packet synchronization between these sessions. This means that an application, used in the communication process should be able to distinguish between the sessions and to synchronize the packets sent to the different “parties” during the call transfer until only one session is remained. Thus, this approach sets as a requirement that all the applications, providing any communication service for two or more parties, should be able to handle such a re-establishment of the session. It is clear, that such a requirement would be difficult to meet, as there exist a large number of applications today, that do not offer such a mobility support.
Although this approach places some requirements on the software, it provides terminal and personal mobility so far. We shall now examine what happens if User B moves to the new subnet.
8.2.2. Handover “Foreign Network – Foreign Network” We assume here that before User B moves to another subnet, only one direct session exists between Terminal A and Terminal B (see Figure 8-3).
69
InternetTerminal A
HA
Terminal B
SIP Proxy Server
Session before the next handoverForeign Network 1
Foreign Network 2
Figure 8-3 Session before the next handover
As it is shown in the figure, HA is not involved in the communication process, hence it would be difficult to force it handle handover to another Foreign Network. The natural thing to do in this case is to force this handover procedure, i.e. handover from one Foreign Network to another, be handled in the same way as the handover from the Home Network to a Foreign Network. This implies that there is one element in the Foreign Network 1, which tunnels all the packets to the Foreign Network 2 until SIP REFER procedure has succeeded. If we just “convert” Home Network – Foreign Network handover procedure to the Foreign Network – Foreign Network handover, we get the situation depicted in the Figure 8-4.
According to the Home Network – Foreign Network handover procedure, after the relocation of the MN and before the call transfer, the packets should first travel to Foreign Network 1, the tunnel should be established between that network and the packets should be tunneled to the MN in the Foreign Network 2. However, Mobile IP doesn’t support tunneling of packets between two Foreign Networks, thus, such a handover management is not possible to achieve with Mobile IP as it is defined per today.
The possibility of redefining Mobile IP in such a way that it could be able to support tunneling of packets between two Foreign Subnets shouldn’t be excluded. If we were to do that, the first problem we would have met is allocation of a unit in Foreign Network 1 that would be responsible for tunneling of packets to the Foreign Network 2. Recall, that the Terminal B has co-located Care-of Address and thus no units serve this terminal in Foreign Network 1. This leads to a requirement that all the networks should implement a FA in order to be able to handle such a tunneling. This requirement would be difficult to meet for Mobile IPv4 as the number of existing subnets is sufficient and in spite of it is possible to install such a unit in each subnet in theory, it will be infeasible to do that in practice.
70
3) INVITE
InternetTerminal A/SIP UA A
HA
5) Session after SIP call transfer4) 200 OK
Terminal B/SIP UA B
Foreign Network 1
Foreign Network 2
FA
2) REFER
1) Session after Mobile IP Handover
Figure 8-4 Desired handover management
8.2.3. Login procedure from Foreign Network In this approach the HA’s functionality is only used when user moves from Home Network to Foreign Network and there are ongoing sessions. Thus, when a user is already in the Foreign Network and logs on to SIP application, there is no need to provide the terminal’s Home Address in the SIP registration, which is carried out upon log on.
When SIP registration is carried out, the terminal’s co-located CoA should be provided in the SIP registration request as an address, on which User B is currently available. Thus, the additional mechanism, which was mentioned in the previous section, should also be utilized during the SIP registration.
InternetTerminal A/SIP UA A
Terminal B/SIP UA B
Session
1) INVITE
3) 200 OK
SIP Proxy Server
HA4) 200 OK
2) INVITE
Figure 8-5 Login Procedure from the Foreign Network
71
Then, if User A wishes to invite User B to a session, session initiation phase is a usual SIP procedure, where Mobile IP is not involved (see Figure 8-5).
If User B decides to move to another Foreign Network after the session is initiated, the handover should be handled in the same way as in the section 8.2.2.
8.3. Required Additional Functionality for Approach 3 Approach 3 requires five additional mechanisms in order to achieve the desired functionality.
The first one is a trigger that would force SIP REFER procedure to be carried out each time, when the terminal’s co-located CoA changes, provided that there are also ongoing sessions and that a tunnel from HA to FA is established. Thus, this gives a need for the second new mechanism, that would find out whether there are ongoing sessions or not and provide this information to the trigger. The same trigger should also include a feature, that would force the session, going via the HA, to be torn down, after the SIP REFER procedure has succeeded.
The third mechanism is a kind of interface between Mobile IP and SIP, which should be responsible for controlling the creation of such SIP messages as REFER, 200 OK and REGISTER, and provide for insertion of the appropriate IP addresses into the appropriate fields of the messages.
The fourth requirement of this approach is that all the applications should be able to support session’s relocation in order to synchronize the packets between the old and the new session. It is clear, that such a requirement is difficult to meet, because it would cause a need to upgrade all the applications, which exist today, in order to support this feature.
The fifth functionality, which is required, is that Mobile IP should support tunnelling of the packets from one Foreign Network to another, without involving the terminal’s HA. Not only the mechanism itself is complex, it also places an additional requirement on the networks, that all of them should implement FA functionality in order to make such tunnelling possible. This requirement is difficult to meet in practice because of the amount of the existing networks.
8.4. Analysis
8.4.1. Complexity In this approach the amount of work needed to be done in order to implement this approach in practice, makes this approach extremely complex for daily use because of the amount and the complexity of additional features.
But not only the installation phase of this approach is complex, it is complex for the end-user as well. If, in spite of the limitations of it, this approach were implemented any way, the user would loose the ability to move freely between the foreign subnets and would be forced to stop all the sessions each time co-located CoA changes, which is not convenient.
72
8.4.2. Route efficiency Route efficiency of this approach suffers from the need to have two sessions, carrying the same information, between two same units for some period of time (after the SIP call transfer procedure is finished and before the original session, which goes via HA, is torn down). But after the original session is torn down, the route efficiency issue is the same as for Approach 2, i.e. it is provided at the best possible degree.
8.4.3. Security issues As Approach 3 utilizes SIP REFER method, it also suffers from a general security problem of this method. The problem is how can the Transferee be sure that the Transfer Target is a legal user. This opens for a security threat, called fabrication, where one user (Transferor) can refer another user (Transferee) to the third user (Transfer Target), which is not an authorized user of SIP services. Thus the Transfer Target can pretend to be another legal user and send fabricated information to the Transferee.
8.4.4. Handover issues Approach 3 supports only one type of handover, i.e. handover from Home Network to Foreign Network.
One great disadvantage of this handover is that it takes longer time than usual Mobile IP handover or usual SIP REFER procedure, because both of them should be carried out in turn. Thus, this approach is not attractive for users, who change subnets often.
Another disadvantage of this approach implies for the users, who are participating in a chat session. In this case a user has more that one corresponding parties, thus, all of them need to notified on the user’s new IP address. This will lead to a longer time, needed by the sessions to be re-established, thus to a longer delay in the re-establishment procedure and insufficient bandwidth utilization.
Other types of handover, as stated earlier, are not possible to achieve with Mobile IP as it is defined per today. Thus, this approach is not a suitable solution for integration of Mobile IP and SIP.
8.4.5. Protocol impacts This approach requires huge changes made to Mobile IP in order to support handover from one Foreign Network to another. The changes are so many, that it can even be regarded as a totally new protocol, developed on the basis of Mobile IP.
No changes are required for SIP in this approach.
8.4.6. Extensibility As we have already showed that this approach cannot serve as a solution for integration of Mobile IP and SIP, it is obvious that there is no need to extend this approach.
73
9. Approach 4
9.1. Description As we have shown, Approaches 2 and 3 have strong disadvantages, as they don’t support seamless handovers between subnets. The reason for this is that we were trying to utilize mechanisms, available in SIP, in order to provide route optimization. Thus, we propose Approach 4, where we utilize Diameter Mobile IPv4 application in order to achieve route efficiency, at the same time as SIP provides personal mobility and Mobile IP provides terminal and session mobility.
This application introduces a new unit, responsible for Authentication, Authorization and Accounting, hence its name is AAA. The application makes use of two such units, AAAH and AAAF, where the first one indicates AAA in the Home Domain, while the latter one indicates AAA in the Foreign Domain.
Visiting Domain
MN B
9) 10)
HA
Home Domain
SIP Server
FA
4)
AAAF
AAAH
8)
2)
6)
MN ASIP UA A
SIP UA B
Mobile IP Registration
Session Initation
16)
14)
15)
dynDNS
13)
1)
7)
3)5)
11)
12)
DNS Update
Sess
ion
Figure 9-1 Sketch for Approach 4
74
In Approach 4 we make use of a unit, which was not mentioned before, known as dynamic DNS (dynDNS) [4]. The difference between usual (or static) and dynamic DNS is that in the latter one the entries can be updated dynamically, on a terminal’s demand and without any need for configuring the DNS manually.
A sketch for this approach is showed in Figure 9-1. What happens in this scenario is that upon entering a new domain MN B acquires a new IP address, a procedure of allocation of HA in the foreign network is carried out (messages 1 to 8) and a DNS entry for this terminal is updated (messages 9 to 10). When SIP server receives a request for User B (message 11), it will inquire dynDNS on the user’s current IP address (messages 12 and 13). After this is done, SIP will send the request for User B directly to the IP address, registered in DNS for this user (message 14). When User B accepts the incoming request, SIP UA B sends a response to SIP server (message 15), which forwards it to the originator of the request (message 16).
This approach solves the routing problem of Approach 1, the problems of Approach 2 and 3. Along with these advantages it has some disadvantages as well. They are not directly concerned with the integration of SIP and Mobile IP, but rather with the procedure of allocation of Home Agent in the Foreign Network. They are highlighted in the next section “Weak Points of Allocation Procedure”. We consider these disadvantages in our further description of the approach.
The two following sections are “MN with Registered FQDN” and “MN without Registered FQDN”. Recall from SIP chapter that it is preferred that a MN provides its FQDN in the Contact-header of a request, but numeric IP addresses are also permitted because many MNs do not have registered domain names. Thus, the approach will be different for each of these situations, that’s why it is necessary to study both of them.
We have divided sections “MN with Registered FQDN” and “MN without Registered FQDN” into three subsections. The first one describes how the handover procedure is handled if User B moves from Home Domain to Foreign Domain without logging off the SIP application, i.e. SIP registration procedure is not carried out after the handover. The second one describes how the handover is handled if User B moves from one Foreign Domain to another Foreign Domain without logging off the SIP application. The third subsection describes what happens if User B starts SIP application while staying in the Foreign Network, i.e. how the SIP registration proceeds.
The fourth section, “Required Additional Functionality for Approach 4”, summarizes all the additional functionality, which is required for Approach 4 and proposes an algorithm for software with that functionality.
9.2. Weak points of the allocation procedure We have identified some weak points in the allocation procedure described in chapter “Mobile IP”.
75
9.2.1. Ongoing session and HA allocation HA
Internet
FA
Client A
Client B
VHA
Client B
Session
Figure 9-2 Relocation of one end point of the session
First of all, the MN is not able to have an ongoing session and change an original HA to the Visited HA at the same time. This requires that the tunnel, established between the HA and the FA, is deleted and the session end point is moved to another location (see Figure 9-2).
HA
Internet
FA 1
Client A
Client B
FA 2
Client B
Session
Figure 9-3 Relocation of one end point of the tunnel
Session’s end-point relocation is only possible to fulfill when a node changes its FA but its HA remains the same (see Figure 9-3). In this case the HA plays a role of controlling unit, which is responsible for moving one tunnel’s end point to another location with minimal losses. However, when the HA changes, this tunnel is no longer needed and one of the session’s end points should be moved. We have identified three possibilities for providing a seamless handover between the HAs.
The first one is to force an application on the correspondent party’s terminal to handle relocation of the session’s end-point in such a way that it would be seamless to the end-users. This solution requires development of such a complicated application first, and second, it should be supported by absolutely all the nodes, supporting IPv4. As it is obvious that the latter requirement is impossible to achieve because of large amount of such nodes, this solution is also reprehensible.
76
The second solution is to continue to communicate to the correspondent party using the original HA until the session is torn down, and allocate a new HA only when no active sessions exist. This solution requires an additional function that would monitor all the processes on the terminal and would determine whether there are ongoing sessions or not, based on the responses received from that processes. It would also be a requirement that every time, before sending registration request, Mobile IP should contact this monitoring function, wait for the response from it and after that insert an appropriate value into the Home Address field.
The third solution is to inform the old HA on the MNs new Home Address and force that HA to forward all the packets to that address in the same way as if it were a FA Care-of Address. In this case additional requirements are placed on the new HA. To provide the MN with an ability to receive packets from the old HA, the new one should be able to distinguish between the encapsulated packets and usual IP packets, de-encapsulate the first ones and forward them to the appropriate MN. In other words, the new HA should be able in addition to a HA functionality support part of a FA functionality for a particular MN, thus forming a totally new type of Mobile IP node.
We have already said the first solution is not possible to achieve in practice. Among the two last solutions, the second solution is the most preferable for implementation as it doesn’t require any changes done to the HAs and the FAs. The disadvantage of the second solution is, however, that a delay before sending a request is introduced, but it is negligible compared to the delay introduced by the third solution, where one packet should be processed in two Mobile IP nodes.
9.2.2. Availability on the new HA. The second weak point is how would the other nodes be able to learn the new Home Address of the MN. When a MN has a static Home Address, the DNS of the MN’s Home Network is configured with a mapping <MN’s FQDN; MN’s Home Address>. If the MN’s Home Address changes, the mapping will then contain wrong IP address. The solution for this problem is to require that all the MNs, configured with FQDN, carry out a dynamic update of the DNS in the Home Network in order to associate their FQDNs with the new Home Addresses. Such an update should be performed in a secure way, as described in [11]. Details of this procedure are out of scope of this document.
Note that a MN can get its Home Address assigned by DHCP (or some other similar protocol) before the procedure of allocation of HA in the Foreign Domain is started, or it can get it assigned by the new HA during this procedure. In any case DNS update should be carried out after both the AAAH and AAAF has “allowed” allocation of the HA in that domain.
9.2.3. MN with co-located Care-of Address The fourth point is that this procedure is only aimed at networks where FAs are already deployed. Recall that all the communications between the MN and the FA are carried out by means of Mobile IP and between all the other units, participating in the procedure, by Diameter. So, if the MN is using co-located Care-of Address, it
77
should communicate directly to AAAF, but the application doesn’t define which protocol the MN should use in order to communicate to AAAF. Thus, it is impossible to carry out procedure of allocation of HA in the Foreign Domain in the networks where FAs have not yet been deployed, because router R (see Figure 9-4), via which MN communicate to AAAF, understands neither Mobile IP nor Diameter. It can be regarded as a possible solution that this router should be modified in such a way that it would be able to understand Mobile IP message and to send corresponding Diameter messages. In other words, it should function as a Foreign Agent and should be deployed on each network. But as we have already seen, the latter requirement is difficult to meet.
AAAF
MS
AAAH
R Visited HA
IPv4
Diameter
Diameter
IPv4
Figure 9-4 Co-located Care-of Address and Router
Our suggestion is to look at the MN with co-located Care-of Address as at the MN with the built-in FA. In this case this built-in FA serves only one MN and all the communications between the MN and FA are carried out inside the MN and the MN communicates directly to AAAF by means of Diameter. The problem which arises in this case is how would this FA discover the AAAF and how would it communicate to the AAAF if it doesn’t have a security association with it.
9.3. MN with registered FQDN In this section we are studying a case when a MN has a registered domain name, FQDN. We’ll assume that the Terminal’s B FQDN is micro.telenor.com and a DNS record for this FQDN exists, mapping this FQDN to the terminal’s IP address: <micro.telenor.com; 101.102.103.104>.
We will also assume that there are two users, User A and User B, who have the same Home network, and User A wants to initiate a session to User B.
78
9.3.1. Handover “Home Network – Foreign Network” Let’s now consider the following situation: User B has started a SIP application on the Terminal B while staying in the Terminal’s Home Network. This has caused SIP registration to be carried out, after which a record in the SIP Location Service for User B is created. This record is a mapping between the user’s SIP URI, which is unique, and user’s SIP URI, which is location-specific: <sip:[email protected]; sip:[email protected]>.
If user A wants to initiate a session to User B, while B is in his Home Network, no problems occur and the situation is identical to that described in chapter “SIP”. We are, however, interested in how would the initial INVITE message be routed to B, if B moves to another subnet. We assume that User B remains logged on to the Terminal B, but doesn’t have any ongoing sessions, when the subnet is changed.
Mobile IP considerations We’ll first describe what happens when Terminal B enters a new subnet, and then we describe what happens when A wants to contact User B. Upon entering a new subnet, terminal B first of all discovers an available FA and sends a Mobile IP registration request to it. As no ongoing sessions exist, the HA IP address field of the registration is set to 0.0.0.0. When the FA has detected that HA may be allocated dynamically, procedure of allocation of the HA in the Foreign network is started and it proceeds in exactly the same way as described in chapter “Mobile IP” (see Figure 9-5, messages 1 to 8).
dynDNS
Internet
FA
SIP Proxy Server
AAAF
HA AAAH
MN ASIP UA A
MN BSIP UA B
1)8)
7)2) 3)
6)
5)
4)
9)
10)
Mobile IP Registration
DNS Update
Home DomainForeign Domain
Figure 9-5 Allocation of HA in the Foreign Domain
What is worth attention during this procedure and what is linked directly to our problem, is the basis for decision whether a MN is allowed to have a HA allocated in a particular domain or not, carried out by the AAAH. This decision shouldn’t be based only on the local policy of the AAAH, as it is stated in [3], but also on the
79
distance between the AAAH and the AAAF or, with other words, whether a HA in the Foreign domain would help to optimize the route or not. How the AAAH would find that out is not defined yet, thus we propose a possible solution for that.
Upon receipt of the message from the AAAF, showing that this AAAF is able and willing to allocate a HA for a particular MN (message nr. 3 in Figure 9-5), the AAAH should ping the AAAF and measure the round-trip-time of the ICMP-packet. After that, this round-trip-time value should be compared to the value, which AAAH should be configured with manually. If the RTT value were greater than the pre-configured value, than the new HA would contribute to route optimization. If RTT value were less than the pre-configured value, the new HA wouldn’t contribute and in this case other criteria should be considered. This is just the basics of the algorithm, which has many smaller details, which are out of scope of this document.
DNS considerations After the new HA has been successfully allocated, the DNS in the home domain needs to be updated, in order that other nodes should be able to contact this terminal on the new IP address. If we assume that the new Home Address is 201.202.203.204, then the entry in the DNS should be updated from <micro.telenor.com; 101.102.103.104> to <micro.telenor.com; 201.202.203.204> (messages 9 and 10 in Figure 9-5). How this update can be carried out in a secure manner is described in [11] and is out of scope of this document, but there is a need for a trigger that would trig this update after the Home Address has changed.
SIP considerations When the DNS entry is updated, MN is ready to communicate to other nodes. Thus the second thing we describe is what happens when User A initiates a session to User B. The whole session initiation procedure is depicted in Figure 9-6.
dynDNSInternet
FA
SIP Proxy Server
AAAF
HA AAAH
MN ASIP UA A
MN BSIP UA B
6) 200 OK1) INVITE
Home DomainForeign Domain
2)3)
4) INVITE
5) 200 OK
Session Initation
Session
Figure 9-6 Session Initiation when MN has an FQDN
80
First, SIP UA A constructs an initial INVITE message and sends it to SIP proxy server. SIP Proxy server finds out an IP address of destination by contacting SIP location service first and DNS afterwards, in the same way as described in chapter “SIP”. (Note that location service is not depicted in Figure 9-1, as it is an abstract service and there are no physical units in the network with that functionality. All the communications between SIP Proxy server and location service are carried out inside one physical unit.) The response, received from DNS, indicates that User B is currently on the IP address 201.202.203.204, thus SIP Proxy server sends the INVITE message to that IP address. After that, the session initiation proceeds in the same way as described in chapter “SIP” and as a result of it, a session is set up between two parties.
The next section describes what happens if User B relocates before the session is finished.
9.3.2. Handover “Foreign Network – Foreign Network” If User B moves from one subnet, on which its new HA is situated, to another one, not supported by that HA, and there is an ongoing session, then the handover is managed by Mobile IP only and SIP is not involved. It is a pure Mobile IP handover, as it is described in chapter “Mobile IP”, when the FA is allocated for the MN in the Foreign network and all the packets are tunnelled by the HA to the FA (see Figure 9-7). In this situation neither DNS nor SIP location service are updated, thus the mobility of the MN is transparent to these units.
dynDNSInternet
SIP Proxy Server
AAAF
HA AAAH
MN ASIP UA A
Home DomainVisited Domain
MN BSIP UA B
FA
Session
Figure 9-7 Handover " Foreign Network - Foreign Network"
The same implies to the case if the MN moves to another subnet without an ongoing session, but of some reasons keeps the same HA, as before. By this we means that all the packets, regardless of their types, are tunnelled to the FA of the MN, and the mobility of the MN is transparent to DNS and SIP location service.
81
9.3.3. Login procedure from the Foreign Network We have so far only been considered with the situation when User B is logged on to the terminal and the SIP application is started, when he changes subnets. Now we shall take a look at the situation when User B logs on to the terminal and starts a SIP application while staying in the Foreign network. We assume that Mobile IP registration is already carried out, a HA in that network is allocated and DNS is updated with the new Home Address of the terminal.
When User B logs on to the SIP application, SIP registration request is sent to SIP Registrar. As the MN has a registered FQDN, SIP registration will inform SIP Registrar, and consequently, SIP location service on that User B, whose SIP URI is sip:[email protected], is currently available on the sip:[email protected]. Actually, this won’t change any data, if there are any, on the SIP location service, because regardless of where Terminal B is, it has the same FQDN.
Thus, when SIP Proxy server receives an INVITE for sip:[email protected], it will contact SIP location service and DNS and will receive an IP address, corresponding to that SIP URI. As one can see, no problems arise during the registration procedure from the Foreign Network, provided that a MN has a registered FQDN. SIP registration and location service update procedures are carried out as described in RFC 3261 [7].
9.4. MN without registered FQDN In this section we are studying the case when a MN doesn’t have a registered FQDN, thus, no entries for this terminal exist in DNS. The terminal’s IP address is 101.102.103.104.
As in the previous section, we assume that there are two users, User A and User B, who have the same Home Network and User A wants to initiate a session to User B.
9.4.1. Handover “Home Network – Foreign Network” Let’s now consider the following situation: User B has started a SIP application on the Terminal B while staying in the Home Network. This has caused SIP registration to be carried out, after which a record in the SIP Location Service for User B is created. This record is a mapping between the user’s SIP URI, which is unique, and user’s SIP URI, which is location-specific: <sip:[email protected]; sip:[email protected]>. The terminal’s IP address is used in the location-specific URI, because no FQDN is present.
If user A wants to initiate a session to User B, while B is in his Home Network, no problems occur and the situation is identical to that described in chapter “SIP:Computing:noFQDN”. We are, however, interested in how would the initial INVITE message be routed to B, if B moves to another subnet. We assume that User B remains logged on to the Terminal B and to the SIP application, but doesn’t have any ongoing sessions, when the subnet is changed.
82
Mobile IP considerations When Terminal B enters a new subnet, procedure of allocation of HA in Foreign network is carried out in exactly the same way as when FQDN of the terminal is present (see Figure 9-5, messages 1 to 8). We assume that after that, a HA for the terminal is allocated in the Foreign network and that it’s new Home Address is 201.202.203.204.
DNS considerations As there are no entries for Terminal B in the DNS, no updates are requires and thus, there is no interaction between the terminal and DNS at all.
SIP considerations Recall that the SIP application has not been turned off before the relocation, thus no SIP registration procedure has been carried out after the terminal’s IP address has changed, because SIP, as defined by RFC 3261, doesn’t support changing of IP addresses.
As the SIP registration has not been carried out, SIP location service has not been updated and an old entry for User B <sip:[email protected]; sip:[email protected]> exists in the location service. Thus, when User A wants to contact User B, an initial INVITE message is constructed and sent by SIP UA A to SIP Proxy server. The SIP server will then inquire SIP location service for User B’s location-specific SIP URI. The received SIP URI will be sip:[email protected] and the INVITE message will be sent to IP address 101.102.103.104. As User B is no longer available on this IP address, the INVITE message will not reach its destination and the session initiation will fail.
In order to cope with this problem, SIP location service needs to be updated at the same time, when the Home Address of the terminal changes. There are several ways of updating location service, but the only suitable in our case is to update it through the registration. To cause the registration to be carried out, User B has to log off the SIP application and log on to it again, what can be disturbing and annoying for the user. Thus, it cannot be a solution for the problem. Registration should be carried out in the background, without involving user in this process, thus a trigger is required, that would trig the SIP registration to be carried out when the terminal’s Home Address changes in order to update SIP location database with the recent data. The trigger is described in section 6.3.
So, if we assume that the location database is updated with the new SIP URI of User B, i.e. the mapping for User B looks like <sip:[email protected]; sip:[email protected]>, and User A wants to contact User B, an initial INVITE message is constructed by SIP UA A and is sent to SIP Proxy server. SIP Proxy server contacts SIP location database and finds out that the messages should be sent to the IP address 201.202.203.204. Thus, the INVITE message is routed to SIP UA B, a 200 OK response is sent back to SIP UA A and a session is initiated between User A and User B (see Figure 9-8).
83
dynDNSInternet
FA
SIP Proxy Server
AAAF
HA AAAH
MN ASIP UA A
MN BSIP UA B
6) 200 OK1) INVITE
Home DomainForeign Domain
4) INVITE
5) 200 OK
Session Initation
Session
Figure 9-8 Session initiation when MN doesn't have an FQDN
9.4.2. Handover “Foreign Network – Foreign Network” Handover “Foreign Network – Foreign Network” is identical to the handover of the same type when the MN has an FQDN, described earlier in this paper. Thus, the reader is referred to chapter 9.3.2.
9.4.3. Login procedure from the Foreign Network As the login procedure from the Foreign Network has been implicitly describe in chapter 0, it is omitted here.
9.5. Required Additional Functionality for Approach 4 The summarized list of the additional functionality, which is needed in order to enable practical implementation of Approach 4, is the following:
1. Monitoring of all the current processes on the terminal in order to be able to determine whether there are ongoing sessions or not.
2. A trigger that would trig dynamic DNS update when MN has an FQDN.
3. A trigger that would trig SIP registration when MN doesn’t have an FQDN.
4. An AAAH procedure that would determine whether allocation of new HA would contribute to route optimization.
Figure 9-9 proposes an algorithm for the monitoring function, which is No. 1 in the list, and Figure 9-10 proposes one algorithm for both triggers, which are No. 2 and No. 3 in the list. The description of the AAAH procedure, which is No. 4 in the list, has already been given earlier in this paper.
84
Class Monitor { //this method is called from outside before //a Mobile IP registration request is sent. //If ”true” is returned, the old HA IP address //is inserted into the request. //if ”false” is returned, 0.0.0.0 is inserted. boolean areThereActiveSessions() { Process [ ] ListOfProcesses = getListOfProcesses(); i=0; while (ListOfProcesses[i] != null){ if (ListOfProcesses[i].activeSession()) return true; i++; } return false; } Process [ ] getListOfProcesses () { make a query to obtain a list of all the ongoing processes and return it; }}
class Process { boolean activeSession () { find out whether a particular process has active sessions or not and return an appropriate Boolean value; }
} Figure 9-9 Monitoring Function Algorithm
class Trigger { //this method is called from outside after //a Mobile IP registration reply is received. void trigger () { if (!previousHA_IP.equals(newHA_IP)) if (fqdn()) updateDNS(); else updateSIP(); } } boolean fqdn () { find out whether a particular MN has FQDN or not and return an appropriate Boolean value; } void updateDNS () { start secure dynamic DNS update; } void updateSIP () { start SIP registration; }}
Figure 9-10 Trigger function Algorithm
85
9.6. Analysis Approach 4 supports both: MNs that have registered FQDN and MNs that do not have one. But the following analysis is not divided into two parts, because the issues, discussed in it are common for both types of MNs.
9.6.1. Complexity Implementation of Approach 4 requires that a new protocol, Diameter, be introduced into the system. This makes Approach 4 more complex than the other approachess because more protocols mean more messages exchanged and thus more complex synchronization between the protocols. By synchronization between the protocols we mean that the order, in which different units send their messages, should be fixed and in order to achieve that all the possible combinations of exchanged messages should be tested.
Additional functionality, required in Approach 4, also contributes to the complexity of the system. This functionality will result in additional software, which each terminal, supporting SIP and/or Mobile IP, should be equipped with.
9.6.2. Route efficiency In this approach the route, followed by the packets of the session, is not the most effective one, compared to the route of the packets, which travel directly from the calling party to the called party. But as we have seen in the approach’s description, this condition cannot be always met, especially when a user moves between subnets. In order to support mobility we need some extra units that would control message flow, thus the most efficient routing cannot be provided in this case. So, if we compare at what degree route efficiency is provided in other approaches, we can say that Approach 4 offers user’s mobility on the lowest route efficiency cost per today.
9.6.3. Security issues The Diameter Mobile IPv4 Application explicitly solves the problem of security in Mobile IP in Approach 4. It is used for authentication and authorization purposes and once a MN is authorized and authenticated by means of this application Mobile IP doesn’t need to be concerned with the security aspects. Functionality of this application limits only to Mobile IP and doesn’t apply to SIP. Nevertheless, we didn’t identify any security problems for SIP, specific for this approach. All the security problems, which affect SIP in this approach, are general for SIP and are covered in RFC 3261.
9.6.4. Handover issues Mobile IP in Approach 4 supports only those handovers which doesn’t require change of the HA or the VHA. This doesn’t seem to be a great problem because a terminal has to be far away from the HA in order to change it and it is almost unlikely that a user is going to travel such a long distance with his MN being turned on all the time. However if such a case occurs nevertheless, there is a possibility to
86
keep the old HA and allocate a new one only after the old is no longer needed, i.e. when all the ongoing sessions are finished.
Handovers where only change of FA is required are carried out in the same way as those described in Approach 1. As there is no difference between them and they suffer from the same problems, the user is referred to chapter “Approach 1” for details.
9.6.5. Protocol impacts Three protocols are actively involved in Approach 4: SIP, Mobile IP and Diameter protocol. None of them needs to be modified in Approach 4, but in order to make the integration of them possible, additional functionality to some units, involved in the communication process, should be provided.
9.6.6. Extensibility Approach 4 is more flexible to changes made into SIP, Mobile IP and Diameter than the other approaches, but it is an open issue, how this approach will behave if new types of mobility, such as application mobility are introduced.
87
10. Evaluation of the Approaches We have thus far described and analysed several approaches for implementation of Mobile IP and SIP on the same network and given an analysis of each approach. Our analysis shows that Approaches 2 and 3 are not suitable as:
• Approach 2 doesn’t utilize Mobile IP’s primary purpose
• Technical requirements of Approach 3 would be difficult to meet in practice.
Thus we limit our comparative analysis to approach 1 and approach 4.
In this chapter we compare these approaches by listing the pros and cons for each of them. Thereafter we evaluate the achieved results and make a recommendation for an implementation.
10.1. Comparative Qualitative analysis In order to be able to conduct a fair evaluation of the two approaches we first describe evaluation parameters:
• Bandwidth utilization
• Performance of transport protocols
• Necessary additional functionality
• Handover support “Home Network – Foreign Network”
• Handover support “Foreign Network – Foreign Network”
• Signalling.
We have not included such aspects as ‘necessary modifications to SIP’ and ‘necessary modifications to Mobile IP’ because neither Approach 1 nor Approach 4 requires such modifications.
Table 10-1 shows what advantages Approach 1 has in preference to Approach 4 and vice versa. If a field in this table contains “1”, this means that the approach, corresponding to this field, has an advantage over another approach in this aspect. If none of the fields for a specific parameter contains “1”, this means that none of the approaches has advantage over another one.
88
Table 10-1 Comparison of Approach 1 and 4
Approach 1 Approach 4 Route Efficiency 0 1
Performance of transport protocols 0 1 Additional software 1 0
Handover “Home- Foreign” 0 0 Handover “Foreign - Foreign” 0 1
Signalling 1 0
Next, we provide additional explanation on each particular aspect, considered in Table 10-1.
10.1.1. Route Efficiency Approach 4 has an advantage over Approach 1 in route efficiency, because it solves the problem of Approach 1, depicted in Figure 6-5, where both, Terminal A and Terminal B are in USA and B’s HA is situated in Norway. In Approach 4 HA is dynamically allocated for the terminal B in USA and the messages doesn’t need to travel all the way to Norway and then back to USA, like they have to do in Approach 1.
10.1.2. Performance of transport protocols A better performance of transport protocols in Approach 4 is a consequence of more efficient routing. As the packets doesn’t need to cover such a long distance as in Approach 1, delay, caused by the time it takes to cover that distance, is not introduced and the packets can thus reach the destination faster. This is the only factor that provides for better performance of transport protocols in Approach 4, because other factors, such as tunnelling and processing in HA and FA, remain common for these approaches.
10.1.3. Additional functionality As Approach 1 is a “straight-forward” method of implementing Mobile IP and SIP on the same network, it does not require any additional software to be developed and installed. Thus, Approach 1 has a great advantage over Approach 4 in this regard, because the latter approach requires at least 3 additional processes with several configuration parameters in order to achieve the desired functionality.
10.1.4. Handover “Home Network – Foreign Network” When talking about this aspect we consider the handover latency as well as the ability to perform handover from Home Network to Foreign Network without loosing the ongoing session. It is not a problem to perform such a handover in Approach 1. In Approach 4 it is not a problem either, but the handover is supported in the same way as in Approach 1, i.e. without changing the HA. Thus, the handover is performed in exactly the same way for both approaches, which results in equal
89
handvor latency. Hence, both of the approaches are in equal conditions when compared from this point of view.
10.1.5. Handover “Foreign Network – Foreign Network” When talking about this aspect we again consider the handover latency and the ability to perform handover from one Foreign Network to another Foreign Network without loosing the ongoing session. It is not a problem to perform such a handover in either of the approaches, but the handover latency will be larger for Approach 1, since the HA will be on average at a longer distance from the terminal, than in Approach 4. Thus, Approach 4 has an advantage over the Approach 1 in this aspect.
10.1.6. Signalling Overhead Approach 4 requires a lot of signalling messages being sent between the units during the allocation of the HA in the Foreign Network. Allocation of the FA in the Foreign Network as described in RFC 2002 doesn’t involve that much signalling, thus making the allocation of the HA more time-consuming and bandwidth-utilizing procedure. Consequently, Approach 1 has an advantage over Approach 4 in this aspect.
10.2. Conclusion As Table 10-1 shows, both approaches possess some advantages and disadvantages. As it is difficult to say advantages of which approach are of more importance, it would be beneficial to combine these two approaches together in order to obtain as many strengths as possible.
Combination of Approaches 1 and 4 would result in the need for a mobile terminal to be able to decide, which of the approaches should be used in different cases.
E.g., if a terminal changes subnets often, it would not benefit from the Approach 4, which provides for dynamic allocation of Home Agent in a Foreign Network. The reason for this is that if the subnets are changed often, then a procedure of allocation of HA should also be carried out often, but at the signalling overhead of this procedure is large, it will result in long handover latency and inefficient bandwidth utilization.
Another example is opposite to the previous one. Imagine a terminal, whish has been moved to a subnet, different from the one, where the terminal’s HA is allocated, and is going to stay in this network for some period of time. In this case it would be beneficial to use Approach 4, as the time signalling would take and the bandwidth it would utilize is negligible compared to the time, the terminal will stay in this network and the bandwidth it will utilize during the sessions, initiated from this network.
Thus, the requirement of this paper is that a mobile terminal possesses an algorithm, due to which it can be able to decide what approach should be used. The main principles of this algorithm are:
90
• Always keep track of how often the last e.g. 10 subnets were changed in order to be able to calculate the probability of how long the user will stay in the next subnet.
• When entering a new subnet, wait for some period of time, in order to find whether it is desirable to allocate a HA in that network or not. This period of time should be longer if the probability for relocating to another subnet, calculated in the previous point, is high. If no relocation is detected after that period of time, allocate a new HA.
Of course, this algorithm won’t give a 100% correct answer on whether the user is going to move to another subnet or not, because there is always some uncertainty when predictions are made. But if the choice of such parameters as the number of last networks kept in memory and the basic value for the period of time is based on the results, achieved during thorough research and testing, it would give pretty high certainty of the prediction made.
91
11. Conclusion
11.1. Achievements and results We have thus studied two protocols, Mobile IP and SIP, which are intended to provide terminal and personal mobility respectively. We have through this paper also seen at the possibility of providing both of these mobility types on one network and this work has resulted in four proposed approaches for the integration of these two protocols.
Approach 1 is a “straight forward” proposal for implementing Mobile IP and SIP. It doesn’t require any additional functionality and is thus the simplest one for implementing. But this simple implementation is possible on the cost of insufficient routing and unnecessary bandwidth utilization on average. In order to cope with these problems, Approach 2 has been proposed.
In Approach 2 we’ve seen at the possibility of utilizing SIP for management of terminal mobility and thus improving routing efficiency and bandwidth utilization. However, we have not succeeded in utilizing SIP in that way, because SIP is an Application Layer protocol and due to Layer independency, it cannot handle terminal mobility, which is the problem of the Network Layer. So, Approach 3 was introduced.
Approach 3 is a combination of Mobile IP handover management and SIP session relocation management. In this approach Mobile IP was used for terminal mobility support, while SIP was used for optimizing the route between the corresponding parties. Nevertheless, this approach showed out to be unacceptable either, because of large number of requirements, which it set on Mobile IP.
Thus, we ended in Approach 4, where Mobile IP and SIP serve their primary purposes, along with an additional application, Diameter Mobile IPv4 application, which allows dynamic allocation of Home Agent in the Foreign Network. We saw that with this approach it was possible to provide terminal and personal mobility along with efficient routing.
After all the approaches were described and analyzed separately, we’ve made an evaluation of Approach 1 and Approach 4. We did not consider Approaches 2 and 3 in this evaluation, because we have shown earlier that these two are not capable of providing terminal mobility. The evaluation has resulted in the conclusion that an end-user will benefit from the combination of Approaches 1 and 4. This, in its turn, leaded to the need for a terminal to decide which of the approaches should be used in different circumstances.
92
11.2. Critical review Our work on this thesis has been purely theoretical. We have not implemented any of the approaches in practice. It could therefore been argued that our achieved results and conclusions are correct.
Another critical issue is that we have not paid attention to the security aspects in this document. Some may say, that as we are dealing with mobile communications, this aspect should be the most important one, as mobile communications are most vulnerable to different kinds of attacks. Our point is that security is implicitly provided by Mobile IP and SIP in our approaches and as long as they don’t open for severe security holes, the security issues can be omitted.
It may also be argued that Diameter Mobile IPv4 application may be used as a remedy for providing terminal and personal mobility, because we have shown that it has some weak points and the application itself doesn’t face these problems. Thus, we cannot be sure on the behaviour of this application without thorough research.
11.3. Future work During our work with this thesis we have discovered several interesting and unsolved issues. These issues are out of scope of this thesis and left for further studies. We describe briefly some of these issues here.
11.3.1. Specification of additional functionality We have in this thesis discovered that some additional functionality is needed in order to fulfil the requirements of the approaches and to be able to implement Mobile IP and SIP on one network. We have proposed this additional functionality, but each proposal should be investigated and studied further. It is important to consider all possible issues of the operation of this functionality and hence some work should be done to design the new functionality.
11.3.2. Practical implementation It would be also interesting and informative to implement the Approaches 1 and 4 in a test bed, as this can reveal new issues, which are not able to reveal through theoretical studies and which are thus not covered in this paper.
11.3.3. Performance of transport protocols Performance of transport protocols needs further investigation also. In our paper we have only shown how the performance will be influenced in theory, but we have not proved our statements with any data, derived from performance analysis and simulations. Thus, this problem should be studied closer and the data for the packet delay and handover latency should be obtained, as this issue is critical for real-time applications.
93
11.3.4. Interaction between SIP, Mobile IP and NAT In our paper we have neither considered the problems of interworking of Mobile IP and Network Address Translator (NAT) nor of SIP and NAT, because these two issues have already been solved. But it is still unknown how these solutions would perform if both, Mobile IP and SIP, were implemented on one network, on which NAT is installed. So, this issue needs further investigations as well.
94
A. Appendix – Predecessor to SIP: H.323 H.323 is an umbrella recommendation that covers all aspects of multimedia communication over the IP-network [16]. It was originally meant to provide multimedia communications over a single LAN-segment. But the development of VoIP led to the need for a standard that would set up a connection between a PC-based phone on a packet-switched network and a usual phone on a circuit-switched network. This resulted in the 2nd version of H.323. But this version still had some limitations that didn’t allow for communication over larger networks. This feature and others, such as fax-over-packet networks, gatekeeper-to-gatekeeper communications, fast-connection mechanisms etc., were included in the 3rd version of H.323. As H.323 was designed to be backward compatible, a version 1 compliant terminal can communicate with a version 3 gatekeeper.
A.1. Elements of an H.323 network
H.323 network PSTN network
Gateway
Gatekeeper
TerminalTerminal
MCU
PSTN phone
Figure A-1 Elements of an H.323 network
A H.323 network has four main elements: a terminal, a gateway, a gatekeeper and an MCU (See Figure A-1). An H.323 terminal is the LAN endpoint that allows users to communicate with each other in real time. It can be either a PC or a phone, or any other device that supports H.323. Its responsibility is to originate and terminate such media streams as audio, video or data, or any combination of them. Support of audio transmission by a H.323 terminal is compulsory, while video and data are optional. These terminals can communicate with each other without any additional server, though their capabilities are severely limited in such a case.
Another component of an H.323 network is a gateway. Its responsibility is to enable connectivity between H.323 networks and other networks that do not support H.323, e.g. ISDN or PSTN networks. Thus, it becomes possible to set up a connection
95
between a H.323 terminal and a terminal, that does not support it, allowing all parties to carry on a meaningful conference.
A H.323 gatekeeper is an optional element in a H.323 network. An advantage of implementing one in a network is that it increases capabilities of a H.323 terminal, by providing them with supplementary services. Gatekeepers are required to perform four functions. First, they must translate terminal and gateway LAN aliases to IP or IPX addresses. Second, gatekeepers perform bandwidth control, which involves allocating bandwidth during a call. This means that there is an upper limit for amount of connections that can be established simultaneously, and if this limit is reached, gatekeeper can refuse to establish more connections. A third gatekeeper task is admissions control. If a gatekeeper is present, all terminals should register with it. The fourth required function is zone management, which involves performing the previous three tasks for all terminals, gateways, and MCUs within its zone, called an administrative domain.
Gatekeepers can also perform several optional functions. One is call-control signalling, which permits the gatekeeper to process Q.931 signalling messages. A gatekeeper may also perform bandwidth management, an extension of bandwidth control, which means it can determine when there is no available bandwidth for a call, or if there is no more available bandwidth when a call in progress requests more. Other optional gatekeeper services include call authorization, which involves the acceptance or rejection of calls based on criteria such as time of day, type of service, and lack of bandwidth. Gatekeepers also may perform call management, which involves keeping track of H.323 calls in progress to know which terminals are busy. This helps gatekeepers redirect calls or save call-setup time by not trying to reach a terminal already in use [20].
A Multipoint Control Unit (MCU) enables H.323 terminals to establish conferences with a large number of participants. Without this device the number of participants in a conference is limited to three.
A.2. H.323 call flow example In this chapter we describe a simple call flow example in a H.323 network (see Figure A-2). We assume that Jessica is calling Peter and that both terminals have already registered with a gatekeeper.
Jessica opens a TCP connection to the gatekeeper and sends and Admission Request (ARQ) message to the gatekeeper, containing Peter’s address and the type of session desired. We assume that in this example there is enough bandwidth and the gatekeeper allows the call to continue by sending an Admission Confirmation (ACF) message to the calling party. ACF-message includes Peter’s IP-address, which is the result of address translation, and an indication on what type of signalling to be used. Gatekeeper can require either a direct signalling between the calling and the called party or a gatekeeper routed signalling, where the gatekeeper acts like a proxy and forwards all messages between the terminals. The TCP connection can now be closed.
96
Jessica is now able to open a TCP connection to Peter, sends a Setup-message to the called terminal and receives a Call Proceeding message in response. Before the called party accepts the call, it exchanges ARQ and ACF messages with gatekeeper in order to get a permission to do so. Upon receiving ACF, it starts alerting Peter and sends an Alerting message to the calling party. When Peter answers the phone, a Connect message is sent. Because of using TCP, acknowledgements from the calling party are not required.
The following call setup can be divided into three phases: connection negotiation, Master-Slave determination and opening of two logical channels, which are used to set up and control the media channels. These phases are indicated in Figure A-2 and we will give a brief description of them without going deep into the details.
RLC
{}
}
ARQ
OpenLogicalChannelAck
ConnectAlerting
1 2 34 5 67 8 9
* 8 #
Jessica
1 2 34 5 67 8 9
* 8 #
Peter
ACF
ARQ
Gatekeeper
Media Session
Setup
Call Proceeding
MasterSlaveDeterminationAck
MasterSlaveDetermination
TermianlCapabillitySetAck
TermianlCapabillitySet
TermianlCapabillitySetAck
TermianlCapabillitySet
OpenLogicalChannelAck
OpenLogicalChannel
OpenLogicalChannel
EndSessionCommand
EndSessionCommand
ACF
DRQDCF
DCFDRQ
Phase 1
Phase 3
Phase 2
Figure A-2 H.323 Call Flow example
97
In phase 1 both parties exchange information on media capabilities, thus negotiating parameters of the connection to be set up. This phase comprises four messages: two messages with the relevant information and two acknowledgements. Phase 2 is needed to fulfil the requirement of H.323 that one terminal should be selected as a master. The calling party sends a message to the counter part, containing its terminal type and a random number. All the terminals types in SIP are organized in a hierarchical manner, so the terminal on the higher level becomes master. In the case, when both terminals are placed on the same level, the random number is used to determine the master. The counter part acknowledges this message, and phase 2 is finished with only two messages. Phase 3 is the final phase in call setup. In this phase two logical channels are opened between parties in order to setup and control the media channels. As opening of one channel requires two messages to be exchanged, one message with information needed and one acknowledgement, the whole phase comprises four messages.
After the phase 3 is finished, Peter can start talking to Jessica. This information is transported over the network as RTP media packets along with RTCP control packets. Any party can initiate the call teardown. Sending an EndSessionCommand message to the counter part does this. The counter part is then responsible for sending EndSessionCommand message in reply and for closing the control signalling connection. When the initiator receives reply from the counter part, he sends a Disengage Request (DRQ) message to the gatekeeper, informing it that the resources used in the call have now been freed up. Gatekeeper confirms this by sending Disengage Confirmation (DCF) message in reply. Now, the initiator of the call teardown can send a Release Complete (RLC) message to the counter part and close the call signalling connection. The counter part exchanges DRQ and DCF messages with the gatekeeper and the call is finished.
A.3. Comparison of H.323 and SIP H.323 and SIP are both intended to provide signalling in an IP-network by introducing mechanisms for call establishment, call tear-down, call control and supplementary services. Although they have much in common and with each new version they acquire more and more common features, there are, however, some significant differences between them.
One difference is clear from comparing call flow examples in SIP and in H.323 (Figure 4-3 and Figure A-2). As one can see, SIP terminals need to exchange only 4 messages to set up a session, versus 18 messages in H.323. Smaller number of messages leads to faster call setup and less network load, releasing large part of bandwidth, which is considered to be a scarce recourse.
In the context of differences in complexity one can compare the size of the standard’s documents. It is 178 pages for SIP versus 726 pages for H.323. Although this comparison criteria are not fair enough, it is rather descriptive to prove that H.323 is not as simple as SIP.
Another difference resides in the scalability of the two protocols. As H.323 was originally developed to cope with the need for signalling over a single LAN segment, it has many scalability issues, but the scalability of the gatekeeper is an open
98
problem. The factor, restricting the capacity of a zone, is the impossibility to have more than one gatekeeper in the zone. The gatekeeper is responsible for storing call state and connection information for each call, thus the number of simultaneous calls through an H.323 zone is limited. The situation is quite opposite for SIP. Although it is usually enough to have on SIP server for one network segment, there are no limitations on how many servers and gateways can be placed in one segment. Also use of UDP transport and stateless proxies leads to the ability of setting up more connections by one SIP server.
Loop detection in H.323 is only possible in stateful way, while in SIP both stateful and stateless servers possess mechanisms for message loop detection.
H.323 and SIP differ also in message transport. H.323 requires TCP to be used, because there are no timers and message transmission schemes that could make UDP transmission possible. Multiple TCP connections should be opened while call setup between the gatekeeper and the terminals and due TCP’s handshake, maximum transfer unit and slow-start additional round-trip delay is introduced. SIP, however, allows for both UDP and TCP transport. It needs only one connection to establish the call in the case when TCP is used. This connection can be terminated when the call setup is finished and re-opened again to terminate the call. In the case of UDP situation is simpler. UDP packets are sent in the appropriate direction and lost messages are handled by SIP.
Addressing in H.323 and SIP are also different. H.323 uses a number of schemes, which include aliases, e-mail addresses, phone numbers, URLs and others, while SIP uses only URLs to address its users. SIP can through DNS queries set up a call without requiring a proxy server to do address resolution, but this is not a case for H.323: a gatekeeper should always resolve address unless the H.323 terminal knows the IP address of the called party.
Conferencing capabilities are also worth mentioning when we talk about differences in H.323 and SIP. As it was already mentioned earlier in this chapter, H.323 terminals are able to perform conferencing, but the number of participants is limited to three. If one wishes to have a conference with a number of participants exceeding three, one should use MCU, which also has built-in conference management features. In SIP there are no limitations on the number of participants and no additional unit is required to be used under the conference. Conference management and statistics in SIP are provided by RTCP.
H.323 and SIP differ also in their encoding systems. H.323 uses packed encoding rule (PER) to encode its messages. This binary encoding scheme is used to minimize the number of bits required to transport a given field. This results in setting limitations on how many characters a field in H.323 can have and in expensive test sets that are used for troubleshooting, because they should possess specific software to decode a H.323 message. SIP uses text-based encoding, which leads to extremely flexible and loosely defined fields and the ability for any network sniffer to read unencrypted SIP messages, as all the headers and parameters are in plain text.
99
B. References [1] B. Aboba and M. Beadles. “The Network Access Identifier”. RFC 2486, IETF.
January 1999.
[2] B. Aboba and J. Wood. “Authentication, Authorization and Accounting (AAA) Transport Profile”. Internet draft, IETF. 2001.
[3] J. Arkko, P. R. Calhoun, E. Guttman and others. “Diameter Base Protocol”. Internet Draft, IETF. October 2002.
[4] J. Bound, Y. Rekhter, S. Thomson and P. Vixie. “Dynamic Updates in the Domain Name System (DNS UPDATE)”. RFC 2136, IETF. April 1997.
[5] E. Bustos, L. Morand, F. Paint, A. Sanmateu, A. M. Sollund and S. Tessier. “Using Mobile IP for provision of seamless handoff between heterogenous access networks, or how a network can support the Always-On concept”. EUERESCOM Summit 2001. Novermber 2001.
[6] P. R. Calhoun, T. Johansson and C. E Perkins. “Diameter Mobile IPv4 Application”. Internet draft, IETF. February 2002
[7] G. Camarillo, M. Handley, A. Johnston and others. “SIP: Session Initiation Protocol”. RFC 3261, IETF. June 2002.
[8] Do van Thanh. “Mobile Communications”. University of Oslo (lecture notes in Mobile Communications). 2001.
[9] S. Deering. “ICMP Router Discovery Messages”. RFC 1256, IETF. September 1991.
[10] R.Droms. “Dynamic Host Configuration Protocol”. RFC 2131, IETF. March 1997.
[11] D. Eastlake 3rd. “Secure Domain Name System Dynamic Update”. RFC 2137, IETF. April 1997.
[12] D. Farinacci, S. Hanks and P. Traina. “Generic Routing Encapsulation (GRE)”. RFC 1701. October 1994.
[13] P. Ferguson and D. Senie. “Network Ingress Filtering”. RFC 2827, IETF. May 2000.
[14] C. Finseth. “An Access Control Protocol, Sometimes Called TACACS”. RFC 1492, IETF. July 1993.
[15] Foo Chun Choong. “TCP Performance in Mobile IP”. Dep of Electrical Engineering, national University of Singapore. October 1999.
[16] A. B. Johnson. “Understanding the Session Initiation Protocol”. Artech House Publishing. 2001.
[17] C. Perkins. “IP Encapsulation within IP”. RFC 2003, IETF. October 1996.
100
[18] C. Perkins. “IP Mobility Support”. RFC 2002, IETF. October 1996.
[19] C. Perkins. “Minimal Encapsulation within IP”. RFC 2003, IETF. October 1996.
[20] C. Perkins and D. B. Johnson. “Route Optimization in Mobile IP”. Internet Draft, IETF. February 1999.
[21] C. Rigney, A. Rubens, W. Simpson and S. Willens. “Remote Authentication Dial-In User Service (RADIUS)”. RFC 2138, IETF. June 2000.
[22] J.D. Solomon. “Mobile IP. The Internet Unplugged”. New Jersey: Prentice Hall. 1998.
[23] R. Sparks. “SIP Call Control – Transfer”. Internet Draft, IETF. July 2001.
[24] R. Sparks. “The SIP Refer Method”. Internet Draft, IETF. July 2002