@prefix vivo: . @prefix edm: . @prefix ns0: . @prefix dcterms: . @prefix dc: . @prefix skos: . vivo:departmentOrSchool "Applied Science, Faculty of"@en, "Electrical and Computer Engineering, Department of"@en ; edm:dataProvider "DSpace"@en ; ns0:degreeCampus "UBCV"@en ; dcterms:creator "Woo, William"@en ; dcterms:issued "2009-03-06T22:16:01Z"@en, "1994"@en ; vivo:relatedDegree "Master of Applied Science - MASc"@en ; ns0:degreeGrantor "University of British Columbia"@en ; dcterms:description """Numerous efforts have been made in extending network connectivity to mobile computers using the Internet as a backbone. The Internet Engineering Task Force (IETF) has compiled a series of technical discussions into a basic IETF mobile-IP draft proposal. At the time of writing, the draft is in the process of becoming an Internet standard. In addition to this extension, there is a compatible route optimization scheme, Internet Mobile Host Protocol (IMHP), which can be employed to improve routing efficiency of the basic proposal. In a Wireless and Mobile Data Network (WMDN), handoffs are required whenever a mobile host crosses cell boundaries. These handoffs introduce momentary disruptions and could significantly reduce the throughput at the transport layer. In this research, a new Handoff Enhanced scheme is introduced to further extend IMHP to improve both the routing efficiency and the transport layer performance during handoffs. This new scheme uses finite size buffers to store inbound datagrams for mobile hosts during handoffs. As a result, datagram losses are eliminated. This is found to improve the transport layer performance by a significant extent. The transport layer performance of the three different schemes were evaluated using the OPNET simulation package. It is found that the IMHP yields very poor performance at high handoff rates. With the new enhanced scheme, the transport layer performance improves significantly. Besides, the new enhanced scheme employs route optimization and gives better performance than the basic IETF scheme."""@en ; edm:aggregatedCHO "https://circle.library.ubc.ca/rest/handle/2429/5685?expand=metadata"@en ; dcterms:extent "6021544 bytes"@en ; dc:format "application/pdf"@en ; skos:note "HANDOFF ENHANCEMENT IN MOBILE-IP ENVIRONMENT In W I L L I A M W O O Eng in Electronic and Communication Engineering, University of Birmingham, UK, 1991 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF T H E REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF ELECTRICAL ENGINEERING We accept this thesis as conforming to t^he required standard T H E UNIVERSITY OF BRITISH C O L U M B I A November 1996 © William Woo, 1996 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of Elttdxtcal &\\g^Vig&Wi The University of British Columbia Vancouver, Canada Date T X c 2 , m f a DE-6 (2/88) Abstract Numerous efforts have been made in extending network connectivity to mobile computers using the Internet as a backbone. The Internet Engineering Task Force (IETF) has compiled a series of technical discussions into a basic IETF mobile-IP draft proposal. At the time of writing, the draft is in the process of becoming an Internet standard. In addition to this extension, there is a compatible route optimization scheme, Internet Mobile Host Protocol (IMHP), which can be employed to improve routing efficiency of the basic proposal. In a Wireless and Mobile Data Network (WMDN), handoffs are required whenever a mobile host crosses cell boundaries. These handoffs introduce momentary disruptions and could significantly reduce the throughput at the transport layer. In this research, a new Handoff Enhanced scheme is introduced to further extend IMHP to improve both the routing efficiency and the transport layer performance during handoffs. This new scheme uses finite size buffers to store inbound datagrams for mobile hosts during handoffs. As a result, datagram losses are eliminated. This is found to improve the transport layer performance by a significant extent. The transport layer performance of the three different schemes were evaluated using the OPNET simulation package. It is found that the IMHP yields very poor performance at high handoff rates. With the new enhanced scheme, the transport layer performance improves signifi-cantly. Besides, the new enhanced scheme employs route optimization and gives better perfor-mance than the basic IETF scheme. Table of Contents Abstract ii List of Tables v List of Figures vii Acknowledgment ix Chapter 1 Introduction 1 1.1 Overview of Mobility Support over Internet Protocol 1 1.2 Motivation of Handoff Optimization and Scope of this Thesis 4 Chapter 2 Mobility Extension for Internet Protocol 6 2.1 Overview of Mobile-IP Extension over Internet Protocol 9 2.2 Registration Procedure for Mobile Hosts 10 2.3 Datagrams Delivery for Mobile Hosts. 13 2.4 Route Optimization Extension in Mobile-IP 14 Chapter 3 Performance Issues Related to Handoffs 16 3.1 Transport Control in TCP/TP 17 3.1.1 Karn' s Algorithm and Timer B ackoff 19 3.1.2 Response of TCP in congestion 19 3.2 Impact of Handoff in TCP/IP over Mobile-IP 20 3.3 Handoff in Basic Mobile-IP Scheme 21 3.4 Handoff in Route Optimization Scheme 25 Chapter 4 Handoff Enhanced Mobile-IP Scheme 28 4.1 Enhancement of Mobile-IP during Handoffs 28 4.2 Security Considerations 29 iii 4.3 Performance Considerations 31 Chapter 5 Design of Simulation Model 35 5.1 Overview of OPNET Simulator 36 5.1.1 Hierarchy within OPNET Simulator 36 5.2 Design of Simulation Models 40 5.3 . Network Configuration 41 5.4 Host Configuration .....44 5.4.1 Basic IETF Mobile-IP Scheme 47 5.4.2 IMHP Route Optimized Mobile-IP model 56 5.4.3 Handoff Enhanced Scheme 59 Chapter 6 Discussion of Simulation Results 61 6.1 Review of Simulation parameters 61 6.2 Simulation Results 69 6.3 Effect of the change in vulnerable period ; 71 6.4 Summary of Performance Comparison 77 Chapter 7 Conclusion 81 Glossary 84 R E F E R E N C E S 85 Appendix A. Supplementary Source Code of the IETF Model 88 Appendix B. Supplementary Source Code of the IMHP Model 103 Appendix C. Supplementary Source Code of the Handoff Enhanced Model 124 i v List of Tables Table 2.1 Mobile-IP protocol specification 11 Table 2.2 List of mobile registration extensions 11 Table 4.1 Registration authentication extension between Foreign Agents 34 Table 5.1 Mobility binding lists in basic mobile-IP 48 Table 5.2 Home agent binding entries in mobile-IP 48 Table 5.3 Foreign agent binding entries in basic mobile-IP 49 Table 5.4 Mobile host binding in basic mobile-IP 50 Table 5.5 State transition of mobile-ip unit in basic mobile-IP 51 Table 5.6 Responsibilities of home agent in basic mobile-IP 52 Table 5.7 State transition for reg unit of home agent in basic mobile-IP 53 Table 5.8 Responsibilities of foreign agent in basic mobile-IP 53 Table 5.9 State transition of reg unit for foreign agent in basic mobile-IP 54 Table 5.10 Responsibilities of mobile host in basic mobile-IP 54 Table 5.11 State transition of reg unit for mobile host in basic mobile-IP 55 Table 5.12 Responsibilities of cache agent 56 Table 5.13 Additional responsibilities for home agent to implement route optimization 56 Table 5.14 State transition of mobile-IP module in route optimized scheme 58 Table 5.15 State transition of mobile-ip unit for mobile host in handoff enhanced mobile-IP 60 Table 6.1 Parameter set 1 62 Table 6.2 Parameter set 2 71 Table 6.3 Parameter set 3 73 v Table 6.4 Performance comparison for parameter set 2 77 Table 6.5 Performance comparison for parameter set 3 '. 78 Table 6.6 Normalized TCP end-to-end delay with handoff every 40 sec 79 Table 6.7 Normalized TCP end-to-end delay with handoff every 2 sec 79 vi List of Figures Figure 1.1 Mobile-IP allowing hosts to be mobile and reachable simultaneously 2 Figure 2.1 Protocol architecture of the Internet 6 Figure 2.2 Conventional routing in Internet 7 Figure 2.3 Datagram encapsulation at Home Agent 10 Figure 2.4 Mobile registration message format 11 Figure 2.5 Datagram tunneling in mobile-IP ...13 Figure 2.6 Route optimization mechanism 15 Figure 3.1 Typical mobile handoff scenario ....17 Figure 3.2 Timing diagram during handoff in basic mobile-IP scheme 24 Figure 3.3 Timing diagram during handoff in JJVIHP scheme '. 27 Figure 4.1 Registration messages sent during handoff 29 Figure 4.2 Illustration of the Handoff Enhanced Scheme 30 Figure 4.3 Timing diagram during handoff in the Handoff Enhanced mobile-IP scheme 33 Figure 5.1 Hierarchy in OPNET with Networks, Nodes and Processes 37 Figure 5.2 An example of node layout of an Ethernet workstation 38 Figure 5.3 TCP manager employed within TCP/TP standard model 39 Figure 5.4 TCP connection management sub-process 39 Figure 5.5 Network configuration of the simulation 41 Figure 5.6 Host configuration within subnetworks 42 Figure 5.7 Core gateway model of the Internet model 43 Figure 5.8 Queuing at the Internet core gateway 44 Figure 5.9 Components of conventional host : 45 v i i Figure 5.10 Components of mobile host or mobile agent 46 Figure 5.11 State diagram for mobile-IP module for basic mobile-IP scheme 50 Figure 5.12 State diagram for mobile registration handling of mobile agent in basic mobile-IP. < ....52 Figure 5.13 State diagram of reg module of mobile host in basic mobile-IP 54 Figure 5.14 State diagram of cache agent using route optimization scheme 57 Figure 5.15 State diagram of mobile-IP module in route optimized scheme 57 Figure 5.16 State diagram of mobile-IP module using Enhanced mobile-IP scheme 59 Figure 6.1 Delay connection characteristics of basic mobile-IP scheme (handoffs every 40 sec) .' : 63 Figure 6.2 Delay characteristics of IMHP mobile-IP scheme (handoff every 40 sec) 64 Figure 6.3 Delay characteristics of handoff enhanced mobile-IP scheme (handoff every 40 sec) 65 Figure 6.4 Delay characteristics of basic mobile-IP scheme ....66 Figure 6.5 Delay characteristics of route optimized mobile-IP scheme , 67 Figure 6.6 Delay characteristics of handoff enhancement scheme 68 Figure 6.7 TCP performance for parameter set 1 '. 70 Figure 6.8 TCP performance for parameter set 2 72 Figure 6.9 TCP performance for parameter set 3 74 Figure 6.10 TCP performance with inserted propagation delay (handoff every 40 sec) 75 Figure 6.11 TCP performance with inserted propagation delay (handoff every 2 sec) 76 viii Acknowledgment I would like to take this opportunity to thank Dr. Victor Leung for his continuous support and suggestions throughout this research. This work was supported by Motorola Wireless Data Group, Richmond, B.C., Canada and by the Natural Sciences and Engineering Research Council under Grant OGP0044286. Besides, I would express my appreciation towards my family and friends for their emotional support. Chapter 1 Introduction Computer networks provide a solution to share data and resources between different terminals within the same network. This is an efficient way to share information and resources. As more and more of these networks are present, there is a further need of connecting these indepen-dent networks together into an even bigger network infrastructure. This internetworking of networks is commonly referred to as the Internet. The Internet started out as a project in the military service in the United States of America and has been in place for over two decades. New networks are attached to the Internet at a fast pace. Together, the network provides a vast resource of information. With the improvement in digital electronics technology, computers have been reduced in size. This makes a huge driving force for the market of mobile computing. There is a growing need for good computing power, mobility and network connectivity. The Internet is a prime candidate in providing network connectivity, since it is available globally. Current Internet implementation does not support host mobility and proposals have been made to address this issue. 1.1 Overview of Mobility Support over Internet Protocol As there is no central organization governing the Internet, it is almost self-regulatory with a few regulatory bodies which strive to improve and implement additional capabilities of Internet. Internet Engineering Task Force (IETF) is an example of one of the boards. The responsibility of IETF is to investigate new additional features. The addition and modification of protocols will undergo discussion and be analyzed before they are actually implemented. 1 Chapter 1 Introduction 2 Data units within the Internet layer is a datagram and has a standard format. By having a standard protocol, the Internet Protocol (IP), computer applications on different platforms can share information and access computers on other parts of the Internet. Each computer connected to the Internet has a unique Internet address, which is a four byte integer. Internet addresses on the same network have the same network prefix which is part of the Internet address. Routing is based on this prefix. Under current Internet routing scheme, datagrams are routed to the same network if the network prefixes of the Internet addresses are identical. Therefore, when a host has physically changed its attachment point in the Internet to a different network, it cannot retain its current Internet address. This presents a hindrance to mobile network computing where mobile computers may be attached to different networks at different times. As a result, there are numerous solutions suggested which have attempted to extend this functionality. A common scenario for mobile computing requirement is shown in Figure 1.1. The presence of a virtual connection, between A . l Host A.2 Mobile Host of Network A (Conventional host (C.1) does not have to be aware that host(A.2) is actually a mobile host) F i g u r e 1.1 M o b i l e - I P a l l o w i n g hosts to b e m o b i l e a n d r e a c h a b l e s i m u l t a n e o u s l y Chapter 1 Introduction 3 and A.2, allows the conventional host (C.l) to communicate with mobile host (A.2) via the home network router (A.l). This transparency enables any conventional hosts to be able to reach the mobile host irrespective of its current physical location. IETF has compiled a series of technical discussions regarding mobility support over the existing Internet, and a draft [1] has been proposed. In this draft, a basic extension of additional protocols over IP is listed which provides basic mobility support. No assumptions upon the types of underlying mobile network has been made. This provides a general extension to be adopted for future mobility support. Under this mobility extension, datagrams are delivered to the mobile host via its home network to its current location. The conventional host which is communicating with the mobile host could be physically very close to the mobile host. Under the basic IETF scheme, the datagrams are still routed to the home network first and then dispatched for the mobile host. There is a proposal [2] for optimizing the routing within the mobility extension. This proposal is compatible with existing IETF scheme. The basic idea of this scheme is to enable the conven-tional host to send datagrams directly to the mobile host's current residing network. It is not mandatory for hosts to support this scheme, therefore an extensive operating system upgrade is not required and is also backward compatible with the basic IETF scheme. If supported, this scheme is expected to deliver better performance over the basic scheme. Both of the schemes have not placed any limitations on the degree of mobility supported. For a wireless mobile host which moves quickly from one network to the other, a handoff procedure has to be performed before the new foreign network provides network services to this host. It is shown in [3] that the nomadic behaviour has great impact on the transport layer perfor-Chapter 1 Introduction 4 mance. This is a heavy performance penalty as most of the Internet applications are built around the transport layer protocols. Applications such as electronic mail (e-mail), file transfer protocol (FTP) and world wide web (WWW) all rely on the Transport Control Protocol (TCP) [4] for end-to-end data transportation. If a high performance penalty has to be paid, all these applications would be rendered useless over a highly mobile environment. 1.2 Motivation of Handoff Optimization and Scope of this Thesis The basic IETF scheme has provided a basic requirement for supporting mobility. The proposal in [2] addresses its shortcomings regarding routing efficiency. However, under both schemes, there is no provision regarding the impact on transport layer efficiency due to a highly nomadic host behaviour. During the handoff phase of mobile connection, datagrams are bound to be routed incorrectly under these current proposals. For the mobility extension to be worthwhile implementing, it is necessary to improve on these proposals. It is of great interest to improve performance in a handoff intensive environment. It is the main emphasis of this research to design a new scheme to address both the routing and the handoff issues, thus giving better end-to-end performance at the transport layer. This thesis gives performance analysis of the listed schemes and specifically monitors the performance during handoff periods. In the research, a new scheme is devised in order to enhance the performance during handoff. The end-to-end performance of each of the schemes is compared. Chapter two gives an overview of the basic IETF mobile-IP scheme and the route optimization extension. Chapter three lists the performance issues related in particular to handoff situation. Chapter four describes the new proposed handoff enhanced scheme. Chapter five outlines the simulation tool (OPNET), and the models for evaluating the protocols in [1], [2] and Chapter 1 Introduction 5 the new handoff enhanced scheme. Chapter six shows the results of various simulations and discussions of the results. Chapter seven summarizes the analysis and concludes the findings in the thesis. Chapter 2 Mobility Extension for Internet Protocol The Internet provides a global network that is accessible by any computers within any network connected to it. Unlike the OSI [5] seven layer model for computer network architecture, the Internet architecture is based on a relatively simple protocol stack, with a four-layer protocol suite, commonly referred to as the TCP/IP, as shown in Figure 2.1. Application FTP, Telnet, Rlogin Transport TCP, UDP Internet IP Network Ethernet, FDDI, etc. F i g u r e 2.1 P r o t o c o l a rch i tec ture o f the Internet , The network layer handles all network oriented and physical layer issues particular to individual networks. The Internet layer is responsible for the delivery and routing of standard data units (Internet datagrams) between networks. Datagrams destined for a different network are relayed by one or more routers until they have reached their destination. Internet datagrams have a common header structure and are understood by routers throughout the Internet. The protocol for this layer is known as the Internet Protocol (IP). Conventional IP routers analyze the header portion of incoming datagrams to make routing decisions, as shown in Figure 2.2. Suppose an application within host A has established a connection with another application at host B. The datagrams are relayed by two routers, router X and Y. Whenever a datagram arrives at a router and is pending for delivery, the router will read the destination address within the header portion. From the destination address, the router can determine to which network to send the datagram. If, 6 Chapter 2 Mobility Extension for Internet Protocol 7 however, host B has physically moved to another location within the Internet, existing routers cannot route datagrams to host B at its new location, since its IP address is still the same. Under the current Internet routing scheme, an IP address specifies a unique location within the Internet. Conventional IP routing through routers X and Y H o s t A H o s t B A p p l i c a t i o n T r a n s p o r t Internet N e t w o r k R o u t e r X R o u t e r Y A Internet i i nucnici i I N e t w o r k T I N e t w o r k T Internet A p p l i c a t i o n T r a n s p o r t t Internet N e t w o r k F i g u r e 2.2 C o n v e n t i o n a l r o u t i n g in Internet Proposals have been made to support host mobility. One of the requirements is to implement this host mobility using existing Internet routing mechanism. Under current Internet implementation, there are two ways to deliver datagrams to a mobile host; loose source routing (LSR) [6] and [7] in IP and encapsulation [1], [8]-[ll]. The idea of LSR is to record the path of the datagram and tag the path information at the end of the datagram itself. With this option, both parties, which are involved in the communication, know the exact location of each other. On the other hand, the idea of encapsulation is to carry a datagram within another datagram. The original datagram is carried piggyback by an outer datagram. It has been found [12] that some IP implementations, such as 4.3 BSD and SUN OS 4.1, do not process the LSR option correctly. This leads to encapsulation being a more feasible Chapter 2 Mobility Extension for Internet Protocol \" 8 solution for implementing host mobility within today's Internet without large scale operating system software changes. The IETF has come up with a proposal [1] for mobility extension to the current Internet Protocol. Within this new proposal, there are three new entities defined which do not exist within current Internet Protocol. They are mobile host, home agent, foreign agent and various types of mobility bindings. As opposed to a conventional host, a mobile host (MH) can have different points of attach-ment within the Internet at different times. Any host, regardless of the degree of mobility, which has that capability is classified as a mobile host. Therefore, a mobile host may be using an Ethernet interface at a foreign network or using a radio transceiver in a cellular radio network. A home agent (HA) is a router at the home network of a mobile host. It is responsible for routing datagrams, destined for the particular mobile host, to its current location. A foreign agent (FA) is an entity which is responsible for decapsulating tunnelled datagrams and providing routing services for mobile hosts. It also provides a care-of addresses for MHs so that the HAs know where to forward the datagrams for these MHs. However a M H can choose to obtain its care-of address by other means, thus acts as its own FA. Mobility bindings is a cache entry for routing lookup. HAs, FAs and MHs are required to maintain its own list of bindings. A l l of the above entities are new to the existing Internet Protocol. However, all the datagram traffic for these new entities make use of existing Internet routing mechanism. As a Chapter 2 Mobility Extension for Internet Protocol 9 result, all existing Internet routers can be used without modifications. 2.1 Overview of Mobile-IP Extension over Internet Protocol MHs have fixed IP addresses and the same network masks as their home networks. Datagrams for these hosts are routed to a router within their home network [13]. The next step is to encapsulate those datagrams at their home networks and forward them to the foreign networks at which the mobile hosts are currently attached. This re-routing is accomplished by establishing mobility bindings at both the home and foreign networks. Incoming datagrams for a M H is first routed to its home network. A HA at the home network checks its cache list mobility bindings to see if the host in question has moved to another network or not. If so, it encapsulates the datagrams and sends them to their corresponding care-of addresses. This is illustrated in Figure 2.3. Besides, H A is required to handle all registration requests and keep mobility bindings for nodes that have moved to another networks. Before a HA can forward datagrams to a mobile host at its current location, it has to know the care-of address for that mobile host. Each mobile host must obtain an appropriate care-of address reflecting its current location. Typically, foreign agents (FA) broadcast agent advertise-ments indicating the care-of addresses available for use. M H can then send registration request using one of those advertised addresses. Besides, a mobile host may obtain a care-of address by some other means such as Dynamic Host Configuration Protocol (DHCP) [14]. If the M H has its own care-of address, it may then function as its own foreign agent. The role of the host at the care-of address will be to decapsulate the tunnelled datagrams from the home agent and deliver them to their intended destination. Typically, a FA will have a cache list of bindings indicating the visiting mobile hosts' IP addresses and link-layer addresses. Chapter 2 Mobility Extension for Internet Protocol 10 Original IP datagram encapsulated within a new header SRC: HA DEST: FA Original IP datagram (Outer IP header}^ SRC: source IP address DEST: destination IP address SRC: C H DEST: M H Original IP payload (Original IP header) F i g u r e 2.3 D a t a g r a m e n c a p s u l a t i o n at H o m e A g e n t 2.2 Registration Procedure for Mobile Hosts Whenever a M H moves to a foreign network, or it is hopping from one foreign network to another, it has to send a registration request to the HA at its home network. This is mandatory as this is a request for a change in mobility binding and datagram routing. The H A has to authenti-cate the request to make sure that it is not a request from a malicious host. For each of those foreign networks, there is at least one FA beaconing the type of service available from that partic-ular network. A beacon message is sent as an Internet Control Message Protocol (ICMP) [15] message with appropriate extensions. Upon reception of these beacon messages, the M H is able to decide whether it is possible to acquire network service from this FA. In the basic mobile-IP protocol proposal [1], the mobile registration requests are sent to well-known port 434 of User. Datagram Protocol (UDP) [16]. Therefore, HAs and FAs have to listen to the UDP port 434 to retrieve any mobile registration requests. These registration messages are transported within standard UDP datagrams in the data portion. A standard mobile-IP registration message is shown in Figure 2.4. The mobile registration messages specification is listed in Table 2.1. In addition, there are extensions which can be tagged to registration messages in order to provide additional Chapter 2 Mobility Extension for Internet Protocol Jl UDP UDP UDP UDP SRC PORT DEST PORT UDP (434) L E N G T H C H E C K S U M DATA (UDP Datagram) Type Data (type specific) Extensions . Figure 2.4 Mobile registration message format information (e.g. mobi le - home authentication). In each m o b i l e registration message, there is a type field which specifies the type of message it represents. T h i s enables the mobile-IP software to know how to interpret the message received and be able to take appropriate actions. Table 2.1 Mobile-IP protocol specification M o b i l e R e g i s t r a t i o n M e s s a g e s S o u r c e D e s t i n a t i o n T y p e Registration Request Mobile Host Home Agent 1 Registration Reply Home Agent Mobile Host 3 For security reasons, it is very important to verify the authenticity of the request. This will prevent some malicious hosts from re-routing the datagram path for a particular host by sending counterfeit registration request. Therefore, each registration request must be accompanied by a mobile-home authentication extension. A list of extensions is shown in Table 2:2. An authentica-Table 2.2 List of mobile registration extensions M o b i l e R e g i s t r a t i o n E x t e n s i o n s T y p e Mobile-Home Authentication 32 Mobile-Foreign Authentication 33 Foreign-Home Authentication 34 Chapter 2 Mobility Extension for Internet Protocol 12 tion extension is a secret known only between the two parties involved. From the authentication extension, the two parties can deduce the encryption algorithm and the key. The default authenti-cation algorithm makes use of MD5 [17] with key sizes of 128 bits or more. To avoid replay attack, timestamps are mandatory with an option of nonce-based replay protection. This requires a good random number generator. Eastlake et al [18] provides more information on pseudo-random number generators which is a core requirement in implementing security keys. To acquire mobile network service from a foreign network, a M H will need to send a mobile registration request via a FA. After the FA has received this registration message, it determines the type of service requested. If the request is permitted, the FA will relay this registra-tion message to the H A specified in one of the fields within the request. After the request has reached the specified HA, the HA either grants or denies the request. In either case, the H A will send a registration reply to the FA which has relayed the request. If the request is approved, the HA sets up or updates the mobility binding for this M H . Note that each M H can register with more than one FA, depending whether the H A permits this. Hence, each M H can have more than one mobility binding at its H A . Each of the mobility bindings has a specific lifetime. It is the responsibility of the M H to send another mobile registration before the existing binding expires. Once the registration reply has reached the FA, it sets up or updates its cache binding list of visitors accordingly. The reply is finally delivered to the M H which has originated the request. N o n c e is a pa tent a s s i g n e d to I B M . Pa ten t #5 ,148 ,479 Chapter 2 Mobility Extension for Internet Protocol 2.3 Datagrams Delivery for Mobile Hosts. 13 Figure 2.5 Datagram tunneling in mobile-IP . As soon as a registration for a M H is approved by its HA, datagrams from a corresponding host (CH) for this M H will be captured by the H A , encapsulated and forwarded to the FA by means of tunnelling. Datagrams for the M H arrives at the H A from the C H via Path A in Figure 2.5. An outer header is tagged to each of the original datagrams. This newly formed datagram will have the IP address of HA in the source field, while the destination will take the IP address of the FA or the care-of address of the M H . This datagram is then delivered to the FA through Path B. As the datagram arrives at the FA, it is decapsulated and the visitor binding list is consulted. If there is a valid visitor binding, the FA then sends this datagram viathe corresponding mobile channel to the M H . On the other hand, datagrams originated from the M H are forwarded via the FA directly to the destination C H using Path C. Datagrams from C H to M H clearly follows a suboptimal route. The routing paths A, B and C form a routing triangle and is commonly referred to as \"triangular routing\". The inefficiency of triangular routing is much more apparent whenever a M H is located at a network which is closer to its C H than to its own home network. There are different proposals which attempt to address this issue. Chapter 2 Mobility Extension for Internet Protocol 14 2.4 Route Optimization Extension in Mobile-IP A route optimization method, incorporated in a superset of mobile-IP called the Internet Mobile Host Protocol (IMHP) [2], has been proposed. Route optimization is a backward compati-ble extension to the mobile-IP and requires a new type of entity, the cache agent (CA). The role of a CA is to keep a cache list of mobility bindings of hosts to which it has sent or routed datagrams to. Subsequently, the C A may tunnel datagrams directly to the care-of addresses of the MHs. As the name implies, the cache bindings that are stored at the CAs have limited lifetime. This is to avoid sending datagrams to an incorrect location, e.g. after a M H has moved to another foreign network. Generally, better performance can be achieved if a C H and its CA are co-located, to enable the delivery of datagrams to follow an optimal route right at the beginning. The idea of route optimization is illustrated in Figure 2.6 where a CA is assumed to be co-located with C H . Originally the first datagram from the C H for M H reaches H A as indicated by the path (1). By this time, the HA realizes that the C H does not have up-to-date location informa-tion of M H . The HA tunnels datagrams to the M H as indicated in (2) and (3). In addition, the HA will also send a binding warning message to,the CH, indicating that the C H does not have up-to-date location information. This is shown in message (4). If the C H supports this route optimiza-tion protocol, it can choose to be a cache agent (CA) for the M H . If the C H has the resources to function as a CA, it may send a binding update request to the HA, as in message (5). In response to that request, the HA sends location information of the M H , message (6), to the CA. The CA can update its cache location binding for the M H and subsequent datagram traffic travels directly to its care-of address, as in message (7). This will eliminate the routing inefficiency of sending via the HA. Chapter 2 Mobility Extension for Internet Protocol 15 2) d a t a g r a m t u n n e l l e d to F A 3) d a t a g r a m d e c a p s u l a t e d a n d d e l i v e r e d to M H 6) H A s e n d s b i n d i n g u p d a t e m e s s a g e to C H 4) H A s e n d s b i n d i n g w a r n i n g m e s s a g e to C H 7) S u b s e q u e n t d a t a g r a m s f o r M H sent to F A d i r e c t l y 5) C H s e n d s b i n d i n g reques t m e s s a g e to H A F i g u r e 2 .6 R o u t e o p t i m i z a t i o n m e c h a n i s m If there is no C A along the path between C H and HA, the binding warning message would simply be discarded when it has reached the C H . If more datagrams are arriving at the HA from the C H for the M H , the HA would be able to deduce that the C H does not or chooses not to support route optimization. The HA should then choose to send binding warning messages to the C H at a lower rate or simply not to send them during subsequent datagram arrivals. This would avoid unnecessary traffic within the network. After the M H has moved to another FA and has received registration approval from its own H A , the M H sends deregistration notification to its previous FA together with the current mobility binding. With this information, the previous FA can update the binding for this M H . The lifetime of this new binding is set at a value with the lifetime remaining in the original binding. Chapter 3 Performance Issues Related to Handoffs The basic IETF mobile-IP proposal places no restriction on the type of physical media that enables host mobility. Due to the much higher level of mobility supported by wireless and mobile data networks (WMDNs), these networks are prime candidates for application of mobile-IP and it is crucial that mobile-IP offers good performance in these network environments. To allow a high user density in a W M D N , some frequency reuse scheme has to be incorpo-rated, in a similar manner as the cellular telephone network. Each radio cell has a base station (BS) which provides connectivity between the W M D N and some wireline backbone. When a M H crosses over a cell boundary, a handoff operation is needed to transfer the MH's radio link from the old BS to the new BS. While handoffs are transparent to the IP and mobile-IP layers in centralized WMDNs which employ dedicated backbone facilities and internetwork with the Internet via a single router, in this research we are concerned with a distributed W M D N environment where each cell or a cluster of cells constitutes a mobile subnet interconnecting directly to the Internet via a mobile-IP supporting router providing FA function to MHs roaming in its coverage area. This scenario is applicable, e.g. in a campus-wide wireless local area network with attach-ment points at different departmental LANs, and may well provide a low cost solution to future wide area WMDNs as it eliminates the needs for dedicated backbones. In this scenario, mobile-IP is called upon to support handoffs, by creating new mobility bindings with the new FAs and terminating existing mobility bindings with the old FAs. A typical handoff scenario is shown in Figure 3.1. 16 Chapter 3 Performance Issues Related to Handoffs 17 F i g u r e 3.1 T y p i c a l m o b i l e h a n d o f f s c e n a r i o 3.1 Transport Control in TCP/IP The design philosophy of TCP/IP has taken the approach that the Internet layer consists of an unreliable network. This allows a variety of different types of networks to be connected together. The responsibility of reliable connection is taken up by the transport layer. Transmission reliability is dependent on the transport layer protocol. TCP [4], one of the most important protocol in the transport layer of TCP/IP, is a reliable, connection-oriented protocol, which means the end-to-end connection is monitored for error recovery and to preserve data sequencing. Data stream in TCP is composed of a sequence of bytes. Each of these sequence of data is called a segment. TCP expects an acknowledgment for each segment sent. There is a retransmis-sion timer for monitoring the acknowledgment time. If the retransmission timer expires before an acknowledgment is received, TCP will assume the segment is lost and will retransmit the lost segment. Round Trip Time is the time taken between a segment sent and the corresponding acknowledgment received. To account for a variation in delay within the Internet, TCP uses an adaptive retransmission algorithm. In essence, TCP monitors the round trip time required for the acknowledgment to come through. Based on that information, TCP will set the value of the timer Chapter 3 Performance Issues Related to Handoffs 18 for initiating the retransmission. Whenever it has received a new round trip time, TCP adjusts the retransmission timer value. TCP keeps an estimate of round trip time, RTT, and average RTT deviation, 8, as weighted averages and uses new round trip samples RTT to adjust RTT and 8 accordingly. To compute the new weighted averages, TCP uses a RTT gain factor, a , and a RTT deviation gain factor, X, where 0 < a, X < 1, to weigh the old averages against the new ones based on the following algorithm: Err = RTT -RTT (1 - a) • RTT + a • RTT'-> RTT S + \\(\\Err\\-S)->b New retransmission timeout = RTT + (3 • 8 Choosing a value of a close to 0 makes the weighted average adapt very slowly to the recent changes. If, however, a is chosen to be close to 1, the weighted average will be very sensitive to recent changes and disregards the long-term average RTT. Likewise, choosing a value of X close to 0 tends to disregard recent RTT deviation. RTT deviation constant, [3, is a scalar which specifies how long TCP layer will wait for the acknowledgment. If (3 is set to 1, TCP is overly eager to send retransmissions, which wastes network bandwidth. On the other hand, if (3 is set to too large a value, TCP will be waiting for too long before it realizes the packet is in fact lost. Again, the TCP throughput will suffer. It is therefore important to choose a value of (3 which is adequate but not excessive. The original specification recommends setting (3 to 2. Chapter 3 Performance Issues Related to Handoffs 19 3.1.1 Karn's Algorithm and Timer Backoff Consider the case where TCP has just sent a packet, and the acknowledgment has not been received before the retransmission timer expires. TCP will retransmit the packet, thinking the original packet has been lost. If the acknowledgment comes in soon after TCP has retransmitted the last packet, the new round trip time sample will be far too short and it is also ambiguous. To avoid this, TCP simply ignores the new RTT. This is known as Karn's algorithm [19]. The idea is to avoid this ambiguity altogether by only taking those round trip time samples from segments which have been transmitted only once. This would avoid the possibility of shortening the estimated round trip time erroneously. This is important as the estimate round trip time is used for determining the value for retransmission timer for the next transmission. Besides not updating the round trip time estimate, Karn's algorithm requires TCP layer to implement a timer backoff strategy. An initial timeout value will be computed as before. If the transmission has not been successful, the timeout value will be increased by a multiplicative factor until an upper bound has been reached. Having an upper bound will keep the timeout value from being infinitely long. This timer backoff will increase the timeout value exponentially if the delay has been exceedingly long. This stabilizes the TCP and adapts the retransmission timeout value to a suitable value. 3.1.2 Response of TCP in congestion TCP layer does not have a priori knowledge regarding the amount of delay that each data segment will undergo. Only after receiving the acknowledgment can it determine the exact round trip delay. During congestion in Internet, the segments will suffer from severe delays causing the retransmission timer to timeout. To the TCP layer, this timeout will trigger another retransmission Chapter 3 Performance Issues Related to Handoffs 20 which will certainly choke the already congested network. This will cause a congestion collapse. To avoid that, TCP reduces the amount of traffic through the network. Different versions of TCP, together with several proposals, have methods to accomplish this: slow start and multiplicative decrease. Multiplicative Decrease Congestion Avoidance is the reduction of the congestion window by half. This process is repeatedly done until the window size reaches one. For those segments in the reduced window size, the retransmission timer will be increased exponentially. Slow-Start Recovery specifies that at the start of transmission on a new connection or increasing traffic volume after congestion, the congestion window should be set to one segment. If acknowledgment has arrived before timeout, the window will be increased one at a time. It also limits a linear growth of the congestion window, while Multiplicative Decrease Congestion Avoidance sets exponential decrease in traffic sent. These will help to alleviate the congestion problem. There are efforts made [20]-[27] in establishing congestion control over TCP. Each of these methods introduce adaptive scheme for adjusting the retransmission timeout at the TCP layer. These methods stabilize the congested network by throttling the TCP throughput. 3.2 Impact of Handoff in TCP/IP over Mobile-IP The Internet Protocol layer is known as a best-effort delivery system. No guarantee is made upon the success of datagram delivery. Datagram losses is handled by the TCP layer which requests for retransmissions of lost datagrams. If retransmission is needed, there is a backoff algorithm in TCP to avoid choking the congested network with too many datagrams. Before the Chapter 3 Performance Issues Related to Handoffs 21 introduction of wireless networking and host mobility, TCP only deals with datagram losses primarily due to congestion. When a M H crosses cell boundaries within a W M D N , it has to perform a handoff procedure and send a new registration request to its H A before it can continue to receive network services from its HA. Momentary disruptions of communications are therefore inevitable during handoffs, under the basic IETF mobile-IP scheme. This has a detrimental effect to the perfor-mance of the transport layer employing TCP, since the datagram losses are interpreted as network congestion. During handoffs, datagrams cannot be tunneled to the new FA until the new binding is authenticated at the H A . The authentication can take a long time if the MH's home and visited networks are separated by a large transmission delay. In the case of IMHP, the delay may be worsened, since it is necessary to update the CAs with the new care-of address. As the retransmission is handled by the TCP layer, substantial datagram losses during handoffs would trigger the slow start procedure previously described. This could result in signifi-cant reduction in TCP throughput which takes a long time to recover. For a roaming M H , the rate of handoff could significantly affect the system performance experienced by the user. Caceres et al [28] has proposed a method for improving TCP performance during handoff. However, it requires modifications within the TCP implementation, which means that a vast majority of the Internet hosts today will not be able to make use of this improvement. 3.3 Handoff in Basic Mobile-IP Scheme Each handoff gives rise to a vulnerable period in which datagrams in transit to the M H are potentially lost. This is illustrated by the timing diagram in Figure 3.2, representing the typical Chapter 3 Performance Issues Related to Handoffs 22 handoff scenario in Figure 3.1. Message A is a datagram sent by the C H to the M H . The routing of the Internet will deliver the datagram to the home network of the M H . At the home network, the datagram will be routed to the MH's home agent, HA. As shown in Figure 3.2, the datagram will be tunnelled to foreign agent, FAj , which is currently registered with H A . FAj will decapsulate the tunnelled datagram and forward it to the M H . Message B is the datagram sent by the M H back to the CH. Since F A i is the MH's foreign agent, outbound datagrams from the M H will be first sent to F A i and then routed to the C H with existing Internet routing. In this case, no tunnelling or encapsula-tion is required. It is shown that message A has been routed in a suboptimal path, whereas message B has followed an optimal path. This, is commonly referred to as \"triangular routing\" and is shown in Figure 2.5. The M H has then moved to F A 2 and registration request has been sent. Before the registra-tion has been approved, message C arrives at F A i . F A i still thinks the M H is within its mobile region. FAj attempts to deliver the message to the M H via its mobile channel. Message C cannot reach the M H . During time period, DHF1, in Figure 3.2, the messages that arrive at the H A are routed incorrectly to FAj and are lost. Besides, during time period, DF2H-> messages arriving at H A cannot be delivered to the F A 2 yet, since H A has not received a registration request yet. Therefore, during every handoff, there is a period in which datagram delivery is susceptible to losses. After handoff registration has been completed, datagram delivery for M H can resume. Subsequent messages for the M H will be routed via F A 2 to the M H . It is shown that there is a period in which datagrams for the M H are prone to losses. The Chapter 3 Performance Issues Related to Handoffs 23 length of this vulnerable period is directly related to the packet delays between both the old and new FAs and the HA of the M H . The vulnerable period, Ty^, consists of the delay for datagrams sent prior to the handoff to reach F A 1 via HA, Dfjpj, and for the new registration request to reach HA via FA2,DF2H, During TVUL, datagrams will be incorrectly routed. Once the new registration is authenticated at HA, a new tunnel could be established to redirect datagrams to M H via F A 2 . Delays between M H and FAj or F A 2 are assumed negligible. Chapter 3 Performance Issues Related to Handoffs 24 M e s s a g e r e c e i v e d M e s s a g e B M H m o v e s to F A 2 Regist rat ion request M e s s a g e lost M e s s a g e lost Regist rat ion a p p r o v e d M e s s a g e lost M e s s a g e r e c e i v e d M e s s a g e F M e s s a g e r e c e i v e d • datagram arr iv ing node • datagram lost »- datagram sent ^ datagram encapsula ted and sent through tunnel F i g u r e 3.2 T i m i n g d i a g r a m d u r i n g h a n d o f f in b a s i c m o b i l e - I P s c h e m e Chapter 3 Performance Issues Related to Handoffs 25 3.4 Handoff in Route Optimization Scheme In chapter two, the route optimization scheme, IMHP, is expected to deliver better perfor-mance over the basic IETF scheme, since it has eliminated triangular routing. However, during a handoff, the C A sends datagrams to the previous FA. Hence, these datagrams are routed incorrectly. It is shown in previous sections that datagram losses in the IP layer can impose a serious performance penalty over the TCP layer. The performance of the IMHP scheme degrades as the rate of handoff increases. Whenever there is a handoff, a M H will perform registration with its HA as in the case of the basic IETF scheme. The C H therefore has outdated information regarding the MH's care-of address. Al l subsequent datagrams are sent to the previous FA. As a result, the IMHP scheme suffers from performance degradation during or immediately after handoffs. Timing diagram for the IMHP scheme is shown in Figure 3.3. It is assumed that C H and CA are collocated. The worst case vulnerable period include the delay between the corresponding host, C H and F A 1 ; before the handoff, DCF1, and the delay to update the new binding at either C H or F A i after the handoff, i.e., TVUL = DCFl+DF2H + m i n ( D H F 2 + D F 2 V 3 D H c ) (3-2) Dp2H is the delay to register the new binding with H A after handoff. D^p2 is the delay for the H A to reply with a registration confirmation. DF2i is the delay for F A 2 to give F A i the new binding. 3DHC is the delay for the H A to send a binding update invitation to the CH, a binding request from the C H to the HA, and the binding reply from the H A to the CH. Depending on the Chapter 3 Performance Issues Related to Handoffs 26 current congestion over the Internet, the vulnerable period with route optimization could easily exceed the vulnerable period for the case without route optimization. As before, TCP perfor-mance suffers under a high rate of handoffs or if the delays are long. Methods to minimize loss of datagrams during mobile handoffs are therefore necessary to optimize the performance of JJVIHP. Chapter 3 Performance Issues Related to Handoffs 27 Message received Message B MH moves toFA2 Registration request Message lost Registration approved Deregistration command Message received Message received Message F Message received • datagram arriving node • datagram lost • datagram sent ^ datagram encapsulated and sent through tunnel F i g u r e 3.3 T i m i n g d i a g r a m d u r i n g h a n d o f f in I M H P s c h e m e Chapter 4 Handoff Enhanced Mobile-IP Scheme In sections 2.3 and 3.2, it is shown that performance is suboptimal due to either triangular routing or datagram loss during handoff. In this research, one of the objectives is to devise a method which improves the routing efficiency during handoff. The idea of this proposal is to eliminate or minimize the vulnerable period, while keeping the route optimization extension as in IMHP. By doing so, datagram loss will be minimized and hence the impact on Transport Layer is kept to a minimum. While improving routing efficiency, the security robustness of the new scheme should not be compromised. 4.1 Enhancement of Mobile-IP during Handoffs The main emphasis of the scheme is to minimize datagram losses during handoffs and, at the same time, to yield better performance than the basic IETF scheme. This scheme uses a buffering technique at the previous FA which stores the inbound datagrams for the M H during the handoff period. Upon the reception of the registration confirmation at the previous FA, the stored datagrams are released to the M H . Each store buffer has its own lifetime. If an authenticated reply is not received within the time allowed, the contents of the buffer is flushed and the handoff is considered not successful. Route optimization is performed as in section 2.4. However, during handoffs, there are additional procedures to be done. For example, the M H has switched from one foreign agent to another, say FAj to F A 2 . During the handoff, the M H needs to send a new registration request via F A 2 to its own home agent H A . In this scheme, the M H sends two copies of the registration request. One is sent to the H A via F A 2 , while the other one is sent via F A ^ This is illustrated in 28 Chapter 4 Handoff Enhanced Mobile-IP Scheme 29 ( IP d a t a g r a m sent to F A j ) s o u r c e des t ina t ion M H F A , P a y l o a d ( IP d a t a g r a m sent to F A 2 ) s o u r c e d e s t i n a t i o n M H F A , P a y l o a d U D P h e a d e r T y p e 0 L i f e t i m e M H H A F A 2 . ( c o m m o n U D P d a t a g r a m ) R e g i s t r a t i o n m e s s a g e s sent to F A j a n d F A 2 d u r i n g h a n d o f f N o t e that the reg is t ra t ion m e s s a g e is c o m m o n i n b o t h IP d a t a g r a m s F i g u r e 4.1 R e g i s t r a t i o n m e s s a g e s sent d u r i n g h a n d o f f Figure 4.1 and the format of this type of message conforms to the.basic IETF proposal [1]. Note that the registration request contains both the MH's address and the new FA 2 ' s address. Upon receipt of this registration message, FAj can deduce that the M H is currently at the network of F A 2 and is pending for new registration approval. A finite size buffer is set up at FA± to store the incoming datagrams for the M H . At this point, the F A i still sends those datagram via its own mobile channel at which the M H has been registered with, since the new registration is still pending for approval. The size of this buffer, at F A i , is set to a specific size which is determined by FA^ccording to the resources available on that site. Once the registration has been completed, the M H will cancel the binding with FAj by sending a deregistration to FAj (registration request with lifetime set to 0). As soon as F A i has received this de-registration, it releases the contents of the buffer to the M H via F A 2 . This is illustrated in Figure 4.2. 4.2 Security Considerations One of the considerations of this new scheme is the security robustness compared with the Chapter 4 Handoff Enhanced Mobile-IP Scheme 30 M H sends registration request via FA2 2) Copy of registration request sent to FA1 Datagrams f o r M H - • (FA1 3) FA1 starts buffering incoming datagrams for M H Finite size buffer for temporary storage of MH's datagrams M H performing handoff from FA1 to FA2 2) Deregistration request sent to FA1 M H sends deregistration request toFAl M H 3) FA1 releasing contents for M H via FA2 Buffer being emptied from FA1 and sent to M H via FA2 M H performing deregistration with FA1 after successful registration with H A Figure 4.2 Illustration of the Handoff Enhanced Scheme existing Internet. Special care has been taken in order to avoid security loopholes. In this scheme, the incoming datagrams are stored in a buffer during handoff. Tbis avoids the possibility of replay Chapter 4 Handoff Enhanced Mobile-IP Scheme 31 attack in a W M D N environment. This is the reason that the datagrams are not forwarded to the new FA as soon as the previous FA knows about the handoff. In this case, even if a malicious host sends a forged registration to the FA (FA1), the inbound datagrams for the M H will not be re-directed to the malicious host. F A i waits for an authenticated registration reply before sending the stored datagrams. This scheme does not open up any additional opportunities for security attacks. Although wiretapping of datagrams (in WMDN) is still possible as in the case of the basic IETF scheme, it is considered, as in [1], that the scheme does not allow more security attacks than the existing Internet. As in the case of a wired Ethernet within a network, all local traffic are sent to the Ethernet interface, therefore wiretapping attack is also possible in the existing Internet. 4.3 Performance Considerations Provided that the previous and current FAs are close together, the mobile registration request arrives at the previous FA in a short time. Hence, the previous FA can start buffering the incoming datagrams for the M H . Therefore, the enhanced scheme does not suffer from a vulnera-ble period. However, there are two constraints that limits the effectiveness of this scheme. Firstly, the buffer temporarily storing datagrams for the M H has a finite size. For a IP throughput of 1 k byte/s and the registration delay is 1 sec, the buffer size required for each TCP connection is 1 k byte. If the IP throughput is more higher than that, buffer overflow can occur if the registration takes too long to complete. In this case, storing some datagrams might not be useful to the TCP layer, since it has to request retransmissions of the lost datagrams eventually. Besides memory constraints, if the delay between the registration and reply is long, the retransmission timer in TCP may time out before the buffered datagrams could be delivered and acknowledged by M H . Chapter 4 Handoff Enhanced Mobile-IP Scheme 32 Nominally, the retransmission timer of TCP is set at some multiples k of the round trip end-to-end delay between the C H and the M H , i.e. 2DCM. Therefore the proposed handoff optimization scheme offers transport performance enhancements only if the condition in equation (4.1) is met. The timing diagram for the enhanced scheme is shown in Figure 4.3. TDEL<2^-\\)DCM (4.1) However, the worst case scenario will only bring the performance down to the same as IMHP, but not worse. Note that it is possible to further enhance this scheme. Provided that the old and the current FAs are closely related and entrust each other, it is possible to start forwarding datagrams to the new care-of address location as soon as the old FA is aware of the fact that the M H has handed off to the new FA. This will require some form of security association to exist between the two FAs. The handoff registration message has to include this secret authentication as an extension. The proposed extension takes the format as described in section 2.2. The extended authentication is listed in the Table 4.1. However, as listed in [1], FAs are not expected to initiate any messages regarding mobile registration and reply. Having the FAs to negotiate the security association and redirect the routing is clearly violating the recommendations. Therefore, the proposed Handoff Enhanced Scheme adopts the method of storing the datagrams first as to comply with the security requirement laid down by [1]. This new scheme is expected to deliver better performance during handoff in a W M D N . Chapter 4 Handoff Enhanced Mobile-IP Scheme 33 F A 2 F A 2 M e s s a g e A M e s s a g e r e c e i v e d M e s s a g e C M e s s a g e D M e s s a g e E M e s s a g e r e c e i v e d M e s s a g e r e c e i v e d M e s s a g e B M H m o v e s to F A 2 Regis t ra t ion request Regis t ra t ion request c o p i e d to F A 1 I n c o m i n g message bu f fe red Regis t ra t ion a p p r o v e d Deregis t ra t ion c o m m a n d M e s s a g e r e c e i v e d C , D M e s s a g e r e c e i v e d M e s s a g e F • datagram arr iv ing node datagram lost datagram sent datagram encapsula ted and sent through tunnel F i g u r e 4.3 T i m i n g d i a g r a m d u r i n g h a n d o f f i n the H a n d o f f E n h a n c e d m o b i l e - I P s c h e m e Chapter 4 Handoff Enhanced Mobile-IP Scheme 34 T a b l e 4.1 R e g i s t r a t i o n au then t ica t ion e x t e n s i o n b e t w e e n F o r e i g n A g e n t s M o b i l e R e g i s t r a t i o n E x t e n s i o n s iiiiiiilllliiiiiii F o r e i g n - F o r e i g n A u t h e n t i c a t i o n 35 Chapter 5 Design of Simulation Model Another objective of this research is to evaluate the transport layer performance with the mobile-IP proposals and extensions. The network models of the various listed schemes are developed and the evaluation is performed in simulation. The network model should adhere to the protocol as closely as possible. Once a network model has been established, different statistics can be obtained and performance evaluation can be based on those statistics. Mobile-IP, like conventional IP, is an unreliable, connection-less layer. In order to assess the performance of the scheme, it is necessary to include the Transport and Application layer protocols. With these layers built into a mobile host, the host behaves as a real Internet host. It can negotiate a connection, assess connection status, request for retransmissions, and terminate connections, etc. Although all these modules are not within the Internet layer, it is necessary to include them in order to quantify the network performance on a connection-oriented standpoint. The Internet is a dynamic and complicated network. It contains different kinds of networks which are linked together using the common TCP/TP protocol. There are few restrictions on network topology and hence the Internet is very flexible. As a result, it has gained widespread acceptance. Defining an analytical model for its throughput statistics and variability becomes very difficult, as there is no standard connection pattern between the networks, Consequently, there is no analytical model for the current Internet based on TCP/IP. The evaluation in this study is based on simulation. The model is developed using OPNET 1 . Mobile-IP is based on the IP model in OPNET, but heavily modified to incorporate the extended capabilities. O P N E T is a n e t w o r k s i m u l a t o r s o f t w a r e d e v e l o p e d b y M I L 3, Inc . 35 Chapter 5 Design of Simulation Model 36 5.1 Overview of OPNET Simulator OPtimized Network Engineering Tools (OPNET) is a comprehensive engineering system capable of simulating large communications networks with detailed protocol modelling and performance analysis. OPNET features include: graphical specification of models; a dynamic, event-scheduled Simulation Kernel; integrated data analysis tools; and hierarchical, object-based modelling. OPNET's hierarchical modelling structure accommodates special problems such as distributed algorithm development. OPNET delivers open systems methodology and an advanced graphical user interface known as the MIL 3 User Interface. Due to its object-oriented design, complicated models can be set up and prototyping is made easier and more manageable. Each OPNET simulation is presented in a hierarchical fashion, and therefore, simulations written will have strong parallels with actual communication networks. Debug options are built into every OPNET simulation so that accurate state tracking is possible. A fully graphical interface makes model prototyping much clearer and less error-prone. OPNET has a lot of standard modules written and all of those modules can be modified to cater to different needs. It is also possible to set up an entirely new network model and fine tune its behavior using the C programming language. 5.1.1 Hierarchy within OPNET Simulator Each OPNET model consists of elements which are located in three different hierarchical domains: Network, Node and Process. Figure 5.1 depicts an application in OPNET. Network domain is where the topology of the network infrastructure is defined. A network can be made up of any number of subnetworks and nodes. Different types of links can be used to connect Chapter 5 Design of Simulation Model 37 F i g u r e 5.1 H i e r a r c h y i n O P N E T w i t h N e t w o r k s , N o d e s a n d P r o c e s s e s networks and nodes. Within a network, the smallest subdivision is a node. A node can perform different functions within the network; e.g. it can be a router or a workstation (e.g. gateway in Figure 5.1). The characteristics of each node model is defined by the modules within. There are different types of modules: processors, queues, generators, transmitters and receivers. Figure 5.2 showed an example of node layout of a conventional IP host over Ethernet. In the example, the host consists of different layers of protocols; each of these layers is responsible for different functions. The model is a close representation of real implementation of the protocol stack. Within the node, appl and app2 belong to the Application layer of TCP/IP. TCP layer is realized by a single module. Within this module, it forks a new connection process for each connections. There are a few parameters which can be set in the generators, transmitters and receivers. However, the main core of functionality in each node is determined by the processors and queues, which are fully Chapter 5 Designof Simulation Model 38 o rCh tcp • L___ i !' defer F i g u r e 5.2 A n e x a m p l e o f n o d e l a y o u t o f a n E t h e r n e t w o r k s t a t i o n programmable. Processors and queues are represented as finite state machines. It is a set of instructions which the node will perform under certain predefined conditions. Hence, a (parent) process can call upon other (children) processes. In Figure 5.2, the TCP layer is realized by a single TCP manager process as shown in Figure 5.3. The functions of the TCP manager is a relatively simple process involving only a few states. However, each TCP connection is handled by an independent TCP connection management sub-process. Thus, connection management is made simpler. Each connection management process is responsible for maintaining the state of the connection it is catered for. The connection management process being used in the simulation conforms to RFC 793 [4] and is shown in Figure 5.4 which is identical to the realization on pp. 199 of [13]. The main intelligence of connection control falls upon the ESTAB state within the TCP_CONN module. This type of process hierarchy abstraction can break down a complicated task into a modular system. This is very well suited for TCP/IP and other connection oriented Chapter 5 Design of Simulation Model 39 F i g u r e 5.4 T C P c o n n e c t i o n m a n a g e m e n t s u b - p r o c e s s protocols alike. The only limitation is the memory constraint of the workstation. This makes it Chapter 5 Design of Simulation Model 40 very suitable for simulations of \"Layered Protocols\". Information transfer can be classified into two main categories: packet driven and internal control interface (ICI). The normal way to communicate is to send information in data packets. There are occasions that a layer has to make certain control over other layers. For example, in the operating system implementing TCP/IP, the IP layer receives a UDP datagram and routes it to the appropriate destination. A UDP datagram does not contain information regarding the destination IP address due to the layering of protocols. It is obvious that absolute layer transparency is impossible [13]. Hence, that information is sent via internal control interface. The packet format and the ICI format can be selected using Parame-ter Editor in OPNET. * 5.2 Design of Simulation Models In previous chapters, a total of three different variations of the mobile-IP protocols were introduced. In order to assess the transport layer performance of each of these models, it is required to create three different models in OPNET™. Since UDP is used for delivering mobile registration messages, unlike a conventional TCP/IP model, there is a UDP layer in parallel with the TCP layer. Any host employing mobile-IP extension needs the UDP module in its node architecture in the simulation. UDP delivery system is not supported in standard OPNET modules. In standard OPNET TCP/IP libraries, protocol demultiplexing is not implemented. Therefore, modifications has to be made to accommodate this need. If the mobile-IP models developed are to be used with other standard modules (e.g. IP over ATM), a protocol demultiplexing module has to be added between the Transport and the Internet layer. The module has to demultiplex datagrams from network and send them to appropriate transport layer protocols. It also has to mark the protocol field in the Chapter 5 Design of Simulation Model 41 header so that the receiving side will know what type of datagram it is. If any of,the mobile-IP modules are to be used with other standard modules, this demultiplexing module has to be included to ensure proper interfacing. This demultiplexing unit is shown as ip_encap in Figure 5.10. ' 5.3 Network Configuration Analysis is based on the network model in Figure 5.5. There are two mobile hosts, MHj and M H 2 . M H ^ belongs to netj, whereas M H 2 belongs to net2. The networks net1; net2, and net3 are part of the Internet. They are drawn explicitly for clarity and to show the mobile connections with M H j and M H 2 . The two mobile hosts are designed to hop between foreign networks at predefined rates. Traffic characteristics were studied at different rates of handoffs. F i g u r e 5.5 N e t w o r k c o n f i g u r a t i o n o f the s i m u l a t i o n As both of the mobile hosts are away from home, each of them has to register with their respective home networks in order to acquire network service from them. Besides, they also have Chapter 5 Design of Simulation Model 42 To Internet core gateway Host A.3 Workstation at Network A j Host A. 1 Router at Network A |^ Virtual Connection Host A.2 Mobile Host of Network A F i g u r e 5.6 H o s t c o n f i g u r a t i o n w i t h i n s u b n e t w o r k s to rely on foreign agents to route their datagrams. Each of the networks (netl, net2 and net3) has a local router and a conventional host. Figure 5.6 depicts the connection topology within each of the networks in Figure 5;5. Host (A.l) is a local router. It serves as both FA and HA (i.e. it provides mobile-IP services for both visiting MHs and MHs belonging to the same network). Host (A.2) is a M H . It is connected via a virtual connection to its H A (host A. l ) . Host A.3 is a conventional host connected directly to its home router (host A. l ) . Since we are concentrating on Transport layer analysis, there is no assumption made upon the type network interface. In the simulation, each of the mobile-IP supporting router is named as a mobile agent (MA). MA, is therefore a router which delivers datagrams for both conventional hosts and MHs. The former is just conven-Chapter 5 Design of Simulation Model 43 tional IP routing, whereas the latter is by the use of mobile-IP. Standard OPNET Internet model uses routing table lookup method to implement route selection. Internet traffic within the local subnet is handled by the local router (MA). For traffic that goes beyond the network boundary, they are routed to a default core gateway. This core gateway is capable of routing any IP datagrams to their respective networks, where they will be distributed locally. This scheme is outlined in chapter 13 of [13]. Figure 5.7 shows the core gateway employed in this simulation. Figure 5.7 Core gateway model of the Internet model The use of this core gateway serves two functions in this simulation. First of all, it makes the conventional routing task simpler by having a relatively small routing table at each of the local routers. As the Internet today consists of a large number of hosts, it is therefore resource ineffi-cient to keep track of all the hosts' routing information on every host within Internet. In reality, existing local hosts keep minimal information regarding routing and rely on major gateways within Internet to do the rest of the routing. This is analogous to what is being implemented in OPNET. However, autonomous routing system concept is not implemented. An autonomous system advertises reachability information between routers. This is useful for indicating a certain Chapter 5 Design of Simulation Model 44 network, link or routing path is not functional. The system will then be able to route datagrams via a different path. In our simulation, since the number of networks involved is few and we have one core gateway only, implementing autonomous system would not bring any improvement. All the default traffic has to go through the core gateway, so datagrams follows a single queue waiting to be routed as in Figure 5.8. This introduces a varying delay which the existing Datagrams from various networks Single queue F i g u r e 5.8 Q u e u i n g at the Internet c o r e g a t e w a y Internet imposes in datagrams delivery. The delay for every non-local datagram is varied, giving a more realistic representation of the current Internet. This approach of simulating TCP/TP traffic is commonly used and there are many variations of it. The simulation model in [3] uses a similar approach by having a single core gateway. 5.4 Host Configuration There are basically three types of hosts in this simulation. They are conventional hosts, Chapter 5 Design of Simulation Model 45 mobile hosts (MH) and mobile agents (MA). Conventional hosts are those which will connect only to wireline hosts. It does not support any of the mobile-IP extensions. There is no UDP section within this type of hosts. It is shown in Figure 5.9. There is no assumption made upon the rcv_l xmt_l F i g u r e 5.9 C o m p o n e n t s o f c o n v e n t i o n a l hos t physical connection method. It is implemented as a direct link between hosts. Transmitters and receivers are point-to-point type. The IP module is the standard OPNET IP module. It is capable of handling fragmentation and assembly of IP datagrams. In addition, routing table is kept for making routing decisions. The ipencap module will provide interfacing between TCP and IP layers, exchanging information regarding source and destination addresses of the datagrams being handled. TCP is responsible for maintaining the end-to-end connections. Appl and app2 are sources and sinks of data sent over the network. MHs and MAs share an identical node layout, as shown in Figure 5.10. The difference between a M H and a M A is the registration handling unit - reg module. For a M H , the reg module calls a process which sends registration request to its HA. It also performs handoff at specific Chapter 5 Design of Simulation Model 46 Figure 5.10 Components of mobile host or mobile agent intervals. For a M A , the reg module calls a different process which handles registration requests and updates mobility binding for MHs. Either a M H or M A has to support conventional IP routing as well as mobile-IP routing. Mobile-IP routing is based on the contents of the mobility bindings stored in the mobile-IP layer, and is able to change its delivery path during the course of a connection. Several lists of mobility bindings have to be maintained in order to accomplish this. For a M H , it has a list of bindings storing the information of its home agent, foreign agent and link-layer address. For a HA, there is a list of H A bindings. Each of those will store the information for those MHs which have moved away from this network. For a FA, it has to keep a mobility binding for each visiting M H . Each of the M H sends a mobile registration when the simulation starts. Shortly before the lifetime of the registration expires or the M H has moved to another location, it sends a new registration request to the new FA. These mobile-IP messages are sent via UDP. Therefore, the ip_encap module has to demultiplex datagrams according to its type. When the mobile registra-Chapter 5 Design of Simulation Model 47 tion request reaches the reg module of a FA or a HA, it updates the appropriate list of mobility bindings. To accomplish this, the module interrupts the simulation flow and passes the necessary information via an ICI structure in OPNET. Routing implementation in mobile-IP is significantly different than the standard OPNET IP module. When mobile-IP layer is required to make a routing decision, it first consults its mobility binding lists. For a M H , it always looks for a FA to deliver its datagrams. Whereas for a mobile agent (either a H A or a FA), it has to consult its bindings list to determine where to route the datagram to. If there is no mobility binding related to the destination of the datagram and it is not a M H , conventional Internet routing is used for datagram delivery. 5.4.1 Basic IETF Mobile-IP Scheme This model has the basic features outlined in the basic IETF mobile-IP proposal [6]. In this model, mobile-IP routing, conventional Internet routing and fragmentation handling are supported. The mobility functions are separated in two different modules. The mobile routing and tunnelling are implemented within the mobile-IP layer, whereas the mobile registrations are kept in the application layer and transported via UDP. 5.4.1.1 Mobile-IP layer in basic Mobile-IP The mobile-IP module is developed to replace the standard IP module in OPNET. It handles all mobile routing and tunnelling. It also maintains the cache lists of bindings and removes expired bindings. This module is used by any hosts which supports mobile-IP extensions. The fragmentation handling within this module is based on the standard OPNET IP module, while the routing is Chapter 5 Design of Simulation Model 48 T a b l e 5.1 M o b i l i t y b i n d i n g l ists i n b a s i c m o b i l e - I P List Usage H o m e A g e n t L i s t S t o r i n g c a r e - o f a d d r e s s e s f o r e a c h m o b i l e h o s t F o r e i g n A g e n t L i s t S t o r i n g h o m e agent a d d r e s s f o r e a c h m o b i l e h o s t M o b i l e H o s t L i s t S t o r i n g h o m e agent a d d r e s s a n d f o r e i g n agent a d d r e s s rewritten to accommodate the additional features. Before a datagram is routed, the source and destination addresses in the datagram header are read. In order to find a route for the destination, the lists of mobility bindings are consulted. Figure 5.1 shows the types of mobility bindings that are kept within the mobile-IP layer. If there is no match in these lists for the current datagram to be sent, the datagram is sent via conventional routing. Binding entries are represented as a linked list in C programming language. Home agent binding entries are listed in Table 5.2. Note that in a HA binding list, it is possible to have multiple entries for a single M H . This is to enable a M H to acquire services from multiple FAs. In this case, datagrams for this M H are duplicated and sent to each valid care-of address. The identifier is for validating mobile registration request. This is a known secret between the HA and the M H for authentication purposes. Timeout value is the duration in seconds that this binding should be allowed to exist. Refresh handler is an OPNET T a b l e 5.2 H o m e a g e n t b i n d i n g entr ies i n m o b i l e - I P S e a r c h i d e n t i f i e r I l l l l l l l l l l l l l l l l iEl i^ U n i t M o b i l e H o s t IP a d d r e s s 4 - b y t e in teger C a r e - o f a d d r e s s ( u s u a l l y F o r e i g n A g e n t address ) 4 - b y t e in teger Ident i f ica t ion 4 - b y t e in teger T i m e o u t v a l u e 4 - b y t e in teger R e f r e s h E v e n t h a n d l e r E v e n t p o i n t e r i n O P N E T Chapter 5 Design of Simulation Model 49 T a b l e 5.3 F o r e i g n agent b i n d i n g entr ies i n b a s i c m o b i l e - I P S e a r c h i d e n t i f i e r Illlllililllll^ M o b i l e H o s t IP a d d r e s s 4 -by te in teger H o m e a g e n t IP a d d r e s s 4 -by te in teger L i n k - l a y e r a d d r e s s 4 - b y t e in teger T i m e o u t v a l u e 4 -by te in teger R e f r e s h E v e n t h a n d l e r E v e n t p o i n t e r i n O P N E T internal pointer which allows the module to cancel the binding refresh event. For example, if there is a deregistration before it has expired. It would then be necessary to cancel the refresh event as well to avoid accessing a stale binding after it has been deleted. FA binding entries are shown in Table 5.3. Similar to a H A binding, timeout value and refresh handler are for maintaining the binding within the allowed lifetime. Note that each M H can only have one HA address in the binding. When a FA first receives a mobile registration from a M H , it creates a temporary binding storing the link-layer address to which the M H is attached. When an encapsulated datagram is received, the FA determines whether it is the end of the tunnel for this datagram. If so, it decapsulates the datagram and checks the inner payload to find a match within its visitors' bindings. If a match is found, the datagram will be delivered locally according to the link-layer address in the binding. . For a M H , the binding is shown in Table 5.4. Whenever the M H is required to send a mobile registration, it determines which HA to register with and sends the registration to that IP address accordingly. (Note that there may be more than one HA available within a network.) The care-of address is obtained from the local FA which M H is acquiring network service from. The link-layer address is the physical layer address for routing. Identification serves as a common Chapter 5 Design of Simulation Model 50 T a b l e 5.4 M o b i l e host b i n d i n g i n b a s i c m o b i l e - I P Home agent information Foreign agent information Unit H o m e agent IP a d d r e s s 4 -by te in teger C a r e - o f a d d r e s s 4 -by te in teger l i n k - l a y e r a d d r e s s 4 -by te in teger i d e n t i f i c a t i o n 4 -by te in teger l i f e t i m e 4 -by te in teger R e f r e s h h a n d l e r E v e n t p o i n t e r i n O P N E T secret between the FA and the M H . The time of existence of this binding is specified by the lifetime field. The event handler provides a way to cancel the binding refresh event, should it become unnecessary. With all these bindings defined in the mobile-IP module, all MHs and M A s share a common mobile-IP module. The state diagram is shown in Figure 5.11. The state transition is F i g u r e 5.11 State d i a g r a m f o r m o b i l e - I P m o d u l e f o r b a s i c m o b i l e - I P s c h e m e outlined in Table 5.15. Note that there are two states which is called by the reg module. The two states are stream_update and list_update. Stream_update is for simulating handoff by connecting to a different physical stream, while the list_update is for maintaining the mobility bindings. The supplementary source code of the IETF model is listed in Appendix A. Chapter 5 Design of Simulation Model T a b l e 5.5 State t rans i t ion o f mobile-ip uni t i n b a s i c m o b i l e - I P 51 1111111111!!!!!!! Next state in i t i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s a n d d a t a g r a m arr ives a r r i v a l i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s a n d n o ar r iva ls ye t i d l e i d l e d a t a g r a m arr ives a r r iva l f i n i s h e d s e r v i c e f o r d a t a g r a m s v c _ c o m p l e t i o n s t ream update r e q u e s t e d b y reg m o d u l e s t r e a m _ u p d a t e b i n d i n g u p d a t e r e q u e s t e d b y reg m o d u l e l i s t_upda te a r r iva l s c h e d u l e d a t a g r a m f o r s e r v i c e svc_s ta r t a r r i v e d d a t a g r a m p l a c e d i n q u e u e i d l e s v c _ s t a r t start s e r v i c e , s c h e d u l e f o r f i n i s h i d l e s v c _ c o m p l e t i o n f i n i s h r o u t i n g ( i f m o r e d a t a g r a m s in q u e u e ) svc_s ta r t f i n i s h r o u t i n g ( i f n o m o r e d a t a g r a m s in q u e u e ) i d l e s t r e a m _ u p d a t e p e r f o r m s t ream u p d a t e (return c o n t r o l to reg m o d u l e ) i d l e l i s t_upda te p e r f o r m b i n d i n g update (act ivate b y reg o r cur ren t m o d u l e ) i d l e Chapters Design of Simulation Model 52 5.4.1.2 Mobile Registration modules in Basic Mobile-IP There are also modules in the application layer developed for handling mobile registration procedures. There are two different types of registration modules. One is for MHs, while the other one is for both FAs and HAs. It is expected that a mobile router can function both as a FA and a H A , 5.4.1.3 Home Agent in basic Mobile-IP The responsibilities for home agents in basic mobile-IP scheme is listed in Table 5.6. Each T a b l e 5.6 R e s p o n s i b i l i t i e s o f h o m e a g e n t i n b a s i c m o b i l e - I P 1 h a n d l e m o b i l e reg is t ra t ion reques t 2 s e n d m o b i l e reg is t ra t ion r e p l y set u p c a c h e b i n d i n g f o r m o b i l e hos t that has b e e n s u c c e s s f u l l y r e g i s t e r e d 4 t u n n e l d a t a g r a m s f o r r e g i s t e r e d m o b i l e hosts 5 p e r f o r m dereg is t ra t ion w h e n m o b i l e hos t has r e t u r n e d to h o m e n e t w o r k H A has two special units which handles the mobile datagram routing and registration procedures. They are shown in Figure 5.10 as the reg and the mobile-ip units. The reg unit analyzes all mobile registration requests and performs mobility binding updates. The state diagram for this registra-tion handling unit for a home agent is shown in Figure 5.12 and the corresponding state transition is shown in Table 5.7. F i g u r e 5 .12 State d i a g r a m f o r m o b i l e reg is t ra t ion h a n d l i n g o f m o b i l e agent i n b a s i c m o b i l e - I P Chapter 5 Design of Simulation Model 53 T a b l e 5.7 S ta te t rans i t ion f o r reg un i t o f h o m e agent i n b a s i c m o b i l e - I P S l a t e F u n c t i o n s N e x t S t a t e in i t i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s , s e n d i n i t i a l m o b i l e reg is t ra t ion i d l e i d l e p e n d i n g f o r m o b i l e reg is t ra t ion r e q u e s t r e v r e v a n a l y z e reg is t ra t ion reques t , u p d a t e m o b i l i t y b i n d i n g , s e n d reg is t ra t ion r e p l y i d l e Under this basic scheme, the reg unit takes a passive role in mobile registration manage-ment. HAs do not initiate any messages to FAs, MHs or other CHs. It only responds to mobile registration requests. 5.4.1.4 Foreign Agent in basic Mobile-IP: Foreign agent in this basic mobile-IP scheme plays a silent role as well. It merely relays the mobile registration message from the mobile host to its home agent. It analyzes the registra-tion requests and creates necessary mobility bindings according to the reply from the HAs. The functions of foreign agent is summarized in Table 5.8. These functions are realized and T a b l e 5.8 R e s p o n s i b i l i t i e s o f f o r e i g n agent i n b a s i c m o b i l e - I P 1 f o r w a r d m o b i l e reg is t ra t ion r e q u e s t r e l a y m o b i l e reg is t ra t ion r e p l y 3 m a i n t a i n c a c h e b i n d i n g f o r m o b i l e hos t that h a s b e e n s u c c e s s f u l l y r e g -is te red represented in a state diagram as shown in Figure 5.12. When a FA first receives a mobile registration request from an unregistered M H , it first checks its own available resources. If permitted, a temporary binding is created. As soon as the registration reply from the H A has been received, the FA updates the visitor binding for this particular M H . The registration reply is then delivered back to the M H . State transition is shown in Table 5.9. Chapter 5 Design of Simulation Model ' - 1 54 T a b l e 5.9 State t rans i t ion o f reg uni t f o r f o r e i g n agent i n b a s i c m o b i l e - I P S t a t e F u n c t i o n s N e x t s l a t e in i t i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s i d l e i d l e p e n d i n g f o r m o b i l e reg is t ra t ion requests o r r e p l i e s r e v r e v u p d a t e v i s i t o r b i n d i n g l ist a c c o r d i n g to the m e s s a g e r e c e i v e d i d l e 5.4.1.5 Mobile Hosts i n basic Mobile-IP: Under the basic mobile-IP scheme, MHs initiate all mobile registration requests. In addition, handoff management is also performed by the reg module. The responsibilities are outlined in Table 5.10. T a b l e 5 .10 R e s p o n s i b i l i t i e s o f m o b i l e h o s t i n b a s i c m o b i l e - I P 1 in i t iate n e w m o b i l e reg is t ra t ion request : p r o c e s s m o b i l e reg is t ra t ion reques t r e p l y s p r o c e s s m o b i l e reg is t ra t ion r e p l y 4 re t ransmi t m o b i l e reg is t ra t ion b e f o r e e x p i r y All of the above functions are implemented in the reg module and is implemented in a finite state machine in OPNET which is shown in Figure 5.13. F i g u r e 5.13 State d i a g r a m o f reg m o d u l e o f m o b i l e hos t in b a s i c m o b i l e - I P Chapter 5 Design of Simulation Model 55 Note that there is an extra handoff state within this module. The handoffs are simulated using a timer module within the state. Whenever the predefined handoff period expires, it registers with another FA. After the registration has been approved, the M H does not register with its previous FA. The previous FA deletes the binding when it has expired. The state transition is shown in Table 5.11. T a b l e 5.11 S ta te t rans i t ion o f reg un i t f o r m o b i l e hos t i n b a s i c m o b i l e - I P S l a t e F u n c t i o n s N e x t s ta te in i t i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n paramete rs i d l e i d l e p e n d i n g f o r reg is t ra t ion r e p l y p r o c e s s w a i t i n g f o r r e t r a n s m i s s i o n t i m e r to e x p i r e upda te w a i t i n g f o r h a n d o f f t i m e r to e x p i r e h a n d o f f p r o c e s s a n a l y z e reg is t ra t ion r e p l y , u p d a t e m o b i l i t y b i n d i n g i d l e u p d a t e s e n d r e t r a n s m i s s i o n i f reg is t ra t ion r e p l y not r e c e i v e d w i t h i n t i m e o u t p e r i o d i d l e h a n d o f f s e n d n e w m o b i l e reg is t ra t ion to another f o r e i g n agent w h e n e v e r h a n d o f f t i m e -o u t e x p i r e s i d l e Chapter 5 Design of Simulation Model . 5 6 5.4.2 IMHP Route Optimized Mobile-IP model For the IMHP scheme, all the basic mobile-IP features are supported. There is one additional feature as well. First of all, there is one more entity needed to be defined - cache agent (CA). The role of C A can be taken by any host along the path between the corresponding host and the home agent. Since datagrams can take on different path even though the endpoints of travel is the same, there is no guarantee that subsequent datagrams will take the exact same route during next travel. The responsibility of being a C A often falls upon the C H . The function of CA is to keep track of the care-of address of a certain mobile host. It would then be able to route datagrams for that particular address directly to its care-of address. Therefore, a cache list is kept at CA to indicate the MHs'care-of addresses. Obviously there are additional duties to be carried out by the CA and the HA for this route optimization scheme. They are outlined in Table 5.12 and Table 5.13 respectively. In supporting route optimization, the C H has to include an additional module in its application layer, the state T a b l e 5 .12 R e s p o n s i b i l i t i e s o f c a c h e a g e n t 1 a c k n o w l e d g e b i n d i n g u p d a t e reques t 2 s e n d b i n d i n g update reques t llllllllll m a i n t a i n c a c h e b i n d i n g l i s t ing f o r d i f fe rent m o b i l e hosts 4 de le te o u t d a t e d m o b i l i t y c a c h e b i n d i n g s T a b l e 5.13 A d d i t i o n a l r e s p o n s i b i l i t i e s f o r h o m e agent to i m p l e m e n t route o p t i m i z a t i o n 1 • s e n d b i n d i n g update w a r n i n g to i n d i c a t e a l a c k o f u p - t o - d a t e c a r e - o f a d d r e s s o f m o b i l e hos t : e x p o n e n t i a l l y b a c k o f f i n s e n d i n g b i n d i n g u p d a t e w a r n i n g after r e p e a t e d n o - r e s p o n s e f r o m C a c h e A g e n t s \\ p r o c e s s a n d authent icate b i n d i n g update r e q u e s t diagram is shown in Figure 5.14. The function of this module is normally pending for binding Chapter 5 Design of Simulation Model 57 F i g u r e 5.14 State d i a g r a m o f c a c h e agent u s i n g r o u t e o p t i m i z a t i o n s c h e m e update warning. If that type of message is received, the C H sends a corresponding binding update request to the HA which originates the warning. After the binding update message has arrived, the CA updates the cache binding list in mobile-IP layer. Subsequent datagrams for the same M H are sent directly to its care-of address. Figure 5.15 depicted the mobile-IP layer routing. The state transition is listed in Table 5.14. The supplementary source code for the IMHP scheme is shown in appendix B. ( ! Q U E U E _ E M P T Y ) F i g u r e 5.15 State d i a g r a m o f m o b i l e - I P m o d u l e i n route o p t i m i z e d s c h e m e Chapter 5 Design of Simulation Model T a b l e 5.14 State t rans i t ion o f m o b i l e - I P m o d u l e i n r o u t e o p t i m i z e d s c h e m e 58 S t a t e D e s c r i p t i o n N e \\ l M a t e in i t i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s , a n d n o ar r iva ls yet i d l e i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s , a n d d a t a g r a m ar r ives a r r i v a l i d l e d a t a g r a m arr ives a r r iva l d a t a g r a m r o u t i n g started m o b _ r t e s t ream update in terrupt r e c e i v e d s t rearn_update b i n d i n g u p d a t e reques t r e c e i v e d l i s t_upda te a r r iva l d a t a g r a m a r r i v e d a n d e n q u e u e d i d l e d a t a g r a m a r r i v e d a n d start s e r v i c e s v c _ s t a r t s v c _ s t a r t s e r v i c e f i n i s h t i m e s c h e d u l e d i d l e m o b _ r t e m o b i l e d a t a g r a m sent a n d s c h e d u l e nex t d a t a g r a m i n q u e u e f o r s e r v i c e s v c _ s t a r t r o u t i n g c o n v e n t i o n a l I P d a t a g r a m s v c _ c o m p l e t i o n m o b i l e d a t a g r a m sent a n d n o da ta -g r a m s i n q u e u e i d l e s v c _ c o m p l e t i o n f i n i s h e d s e n d i n g d a t a g r a m a n d no d a t a g r a m in q u e u e i d l e f i n i s h e d s e n d i n g d a t a g r a m a n d s c h e d -u l e next d a t a g r a m f o r s e r v i c e s v c _ s t a r t s t r e a m _ u p d a t e s w i t c h to nex t p h y s i c a l s t ream i d l e l i s t_upda te p e r f o r m b i n d i n g update r e q u e s t i d l e Chapter 5 Design of Simulation Model 59 5.4.3 Handoff Enhanced Scheme For the enhanced mobile-IP scheme, all the route optimization features are supported together with one additional function for the FA. Each FA has to set aside a specific amount of memory buffer for storing datagrams destined for MHs when they are undergoing new mobile registration procedures at another FAs. The state diagram for this scheme is shown in Figure 5.16. The buffering of datagrams make this scheme structurally different from any of the previous schemes described. It requires some memory to be set aside. Moreover, the state transition is more sophisticated. It has to store up data packets for any visiting hosts which have just left for other * (default) F i g u r e 5 .16 State d i a g r a m o f m o b i l e - I P m o d u l e u s i n g E n h a n c e d m o b i l e - I P s c h e m e destinations. Upon pending for authenticated replies, the host has to queue up the packets. The state transition is given in Table 5.15. The supplementary source code of the Handoff Enhanced Scheme is listed in appendix C. Chapter 5 Design of Simulation Model 60 T a b l e 5.15 State t rans i t ion o f mobile-ip uni t f o r m o b i l e host in h a n d o f f e n h a n c e d m o b i l e -I P S t a t e D e s c r i p t i o n N e x t s ta te in i t i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s a n d i f d a t a g r a m s ar r ive a r r i v a l i n i t i a l i z e v a r i a b l e s , r e a d s i m u l a t i o n p a r a m e t e r s a n d i f n o ar r iva ls ye t i d l e i d l e d a t a g r a m ar r ives a r r iva l f i n i s h e d s e r v i c e f o r d a t a g r a m m o b _ r t e s t ream update r e q u e s t e d b y reg m o d u l e s t r e a m _ u p d a t e b i n d i n g u p d a t e r e q u e s t e d b y reg m o d u l e l i s t _ u p d a t e a r r iva l s c h e d u l e d a t a g r a m f o r s e r v i c e svc_s ta r t a r r i v e d d a t a g r a m p l a c e d i n q u e u e i d l e s v c _ s t a r t start s e r v i c e , s c h e d u l e f o r finish i d l e m o b _ r t e finish s e n d i n g d a t a g r a m f o r m o b i l e hos t a n d i f there are m o r e d a t a g r a m s i n q u e u e s v c _ s t a r t n o m o b i l i t y b i n d i n g ex is ts , u s e c o n v e n -t i o n a l IP r o u t i n g s v c _ c o m p l e t i o n f i n i s h s e n d i n g d a t a g r a m a n d n o m o r e p e n d i n g d a t a g r a m s i n q u e u e i d l e s v c _ c o m p l e t i o n finish r o u t i n g ( i f m o r e d a t a g r a m s i n q u e u e ) s v c _ s t a r t finish r o u t i n g ( i f n o m o r e d a t a g r a m s in q u e u e ) i d l e s t r e a m _ u p d a t e p e r f o r m s t ream u p d a t e (return c o n t r o l to reg m o d u l e ) i d l e l i s t _ u p d a t e p e r f o r m b i n d i n g u p d a t e (return c o n t r o l to reg m o d u l e ) i d l e re lease b u f f e r c o m m a n d r e c e i v e d m o b _ r t e Chapter 6 Discussion of Simulation Results Simulations were performed using models developed in previous chapters. Performance analysis was based on connection-oriented traffic. The effect of those parameters will be discussed in relevant sections later in this chapter. 6.1 Review of Simulation parameters The simulation starts with the MHs initiating mobile registrations. The M H sends a mobile registration request to its HA. Upon receiving the registration request, the H A responds with a registration reply. The setup is listed in Figure 5.5. Normal TCP connection was set up between M H i and Internet C H ^ An identical connec-tion was set up between M H 2 and C H 2 . The TCP connections remained open for a period of 2000 seconds (over 30 minutes). Handoff was implemented by using an internal timer. When the time had expired, the M H would switch to another mobile link which was connected to another FA. That would enable the M H to receive mobile service from a new FA. During the period of the connection, MHj was set to hop between net2 and net3, while M H 2 was set to hop between neti and net3. It is specified in [1] that consecutive mobile registrations should not be less than 1 sec apart. Preliminary results also show that TCP end-to-end delay does not change significantly when time between handoffs is increased from 40 sees. Hence we chose the handoff period to be as follows. M H 2 was set to perform a handoff every 40 seconds, while the time between handoffs for M H , was varied in a range from 40 seconds down to 2 seconds. 61 Chapter 6 Discussion of Simulation Results 62 The TCP end-to-end delay of the connection was monitored as the prime interest of the study was the investigation of TCP traffic conditions over mobility links. The TCP end-to-end delay is defined as the time duration between the TCP segment entering the TCP layer of sending host and leaving for the application layer at the receiving host. T a b l e 6.1 P a r a m e t e r set 1 P a r a m e t e r type : M o b i l e l i n k da ta rate: 5 7 . 6 k b p s D a t a rate w i t h i n l o c a l n e t w o r k : 10 M b p s D a t a rate f r o m l o c a l n e t w o r k to Internet si tes: 2 5 6 k b p s M a x i m u m a c k n o w l e d g m e n t d e l a y : 2 s e c R T T g a i n ( a ) : 0 .125 R T T d e v i a t i o n g a i n (K): 0.25 R T T d e v i a t i o n c o n s t a n t (p) : 4 The data segment size was set at 1024 bytes and the generated traffic was exponentially distributed with a 0.1 second interarrival time. The simulation was repeated using ten different simulation seeds using the parameters shown in Figure 6.1. An ensemble average is taken to ensure that the simulation would give a more realistic picture as opposed to a single case study. The results were averaged and tabulated. Since M H 2 had a fixed rate of handoff, the performance over this link was used as a basis for comparison with other handoff rates. The mobile link data rate specifies the data rate from the MHs to the corresponding FAs. The data rate within local network is the data rate between a local router and conventional hosts within the same network. The data rate from local network to Internet sites shows the data rate from the local router to the Internet core gateway. The maximum acknowledgment delay is the maximum tirne allowed that the TCP layer will wait for an acknowledgment before sending Chapter 6 Discussion of Simulation Results 63 retransmissions. The RTT gain (a) and RTT deviation gain (k) are the weighing factors that the TCP layer uses in updating the RTT average and deviation respectively, while the RTT deviation constant ((3) is the multiplicative constant that TCP uses in generating a retransmission timeout value from the average RTT. 0 50 100 150 0 50 100 150 Sample time trace (sec.) Sample time trace (sec.) Figure 6.1 Delay connection characteristics of basic mobile-IP scheme (handoffs every 40 sec) Figure 6.1 shows end-to-end connections measurements of MHj and MFf 2 with handoff every 40 seconds. It is shown that at this rate, the delay is kept within a reasonable range. The performance of both MHs match up pretty closely as the link parameters are identical. The same setup and identical parameters are used for analyzing the route optimized mobile-IP scheme (IMHP). In this scheme, triangular routing is eliminated. It is expected that improved performance can be achieved. It can be seen that the minimum .floor end-to-end delay is Chapter 6 Discussion of Simulation Results 64 M H I ( h a n d o f f e v e r y 4 0 sees) M H 2 ( h a n d o f f e v e r y 4 0 sees) S a m p l e t i m e t race (sec. ) S a m p l e t i m e t race (sec. ) F i g u r e 6.2 D e l a y charac te r is t i cs o f I M H P m o b i l e - I P s c h e m e ( h a n d o f f e v e r y 4 0 sec) considerably lower than that of the basic mobile-IP version. This matches up with our analysis in chapter two. At relatively low handoff rate, the end-to-end connection delay has been improved. As a variant of route optimization scheme, the handoff enhanced scheme is expected to deliver similar performance as the route optimized scheme. The sample results are shown in Figure 6.3. The result verifies the analysis that at low handoff rate the handoff enhanced scheme delivers similar performance as the route optimized scheme. With this set of parameters, each of the schemes are capable of handling the traffic at an acceptable level. Therefore it is necessary to tighten the parameters in order to strain each of the schemes. From the experimental results in the first part, it is apparent that TCP end-to-end delay will occasionally exceed a 2 second range. In order to strain the handoffs, the time between handoffs Chapter 6 Discussion of Simulation Results 65 M H 1 ( h a n d o f f e v e r y 4 0 sees) M H 2 ( h a n d o f f e v e r y 4 0 sees) S a m p l e time t race (sec.) S a m p l e t i m e t race (sec. ) F i g u r e 6.3 D e l a y charac te r is t i cs o f h a n d o f f e n h a n c e d m o b i l e - I P s c h e m e ( h a n d o f f e v e r y 4 0 sec) were reduced to 2 seconds. The same set of parameters, in Table 6.1, were used. Only the handoff rate of MHj was changed. This is to ensure that the change in performance is due to the difference in handoff rates but not from other factors. The result for basic mobile-IP is shown in Figure 6.4. It is apparent that the performance of M F ^ has degraded tremendously compared with previous results (Figure 6.1). Although the floor level of the end-to-end delay is still quite low, there are delays which exceeds 10 seconds. On the other hand, M H 2 has similar performance compared to previous results. The change in performance is due to the handoff rate difference. With the same handoff rate change applied to M H j as in the case of the basic IETF mobile-IP scheme, the simulation was performed using the IMHP scheme. The result is shown in Chapter 6 Discussion of Simulation Results 66 M H 1 ( h a n d o f f e v e r y 2 sees) M H 2 ( h a n d o f f e v e r y 4 0 sees) 5 0 100 150 S a m p l e t i m e t race (sec.) F i g u r e 6.4 D e l a y charac te r is t i cs o f b a s i c m o b i l e - I P s c h e m e 5 0 100 150 S a m p l e t i m e t race (sec. ) Figure 6.5. It can be seen that the performance degrades even more than the basic mobile-IP scheme. This matches with the analysis in chapter two. The results collected were verified through the use of a built-in debugger in OPNET to make sure the datagrams are routed according to the protocol specification. The reason for the poor performance is that the datagrams are often routed to the incorrect location since M H i changes its point of attachment rapidly. This is because the CAs are delivering datagrams directly to the care-of addresses of MHs. This causes the TCP acknowledgment timer to expire. As described in section 3.2, TCP has mistakenly interpreted retransmissions as conges-tion within the network. TCP throttles the traffic by using exponential backoff strategy. Before TCP commences to send traffic down the link again, it sends SYN packets to establish the connec-Chapter 6 Discussion of Simulation Results 67 M H 1 ( h a n d o f f e v e r y 2 sees) M H 2 ( h a n d o f f e v e r y 4 0 sees) 0 5 0 100 150 0 5 0 100 150 S a m p l e time t race (sec.) S a m p l e t i m e t race (sec.) F i g u r e 6.5 D e l a y charac te r is t i cs o f r o u t e o p t i m i z e d m o b i l e - I P s c h e m e tion. As these packets are susceptible to losses as indicated, TCP ends up spending a great deal of time attempting to re-establish the connection. This scheme is deemed to have broken down under these network conditions. The same conditions were applied to the handoff enhanced scheme. The results are shown in Figure 6.6. Although the handoff enhancement scheme is based on the route optimized scheme, it does not suffer from the huge delays as its predecessor. Under this scheme, the datagrams for mobile hosts are buffered at FA if the M H is registering with another FA. As soon as the registra-tion completes, those buffered datagrams are sent to the M H . Nevertheless, these datagrams have to undergo a certain amount of delay before reaching their final destination. If however the travel time together with these delay still falls within the TCP retransmission count value, TCP does not Chapter 6 Discussion of Simulation Results 68 M H 1 ( h a n d o f f e v e r y 2 sees) 5 0 100 150 S a m p l e t i m e trace (sec. ) 3 h \"3 W 2 0 1 c w Oh U M H 2 ( h a n d o f f e v e r y 4 0 sees) 0 5 0 100 150 S a m p l e t i m e t race (sec. ) F i g u r e 6.6 D e l a y charac te r is t i cs o f h a n d o f f e n h a n c e m e n t s c h e m e try to synchronize and retransmit again. This is a major improvement over the route optimized scheme. It still remains a question whether the handoff enhancement scheme is better than the basic mobile-IP scheme under these handoff intensive situations. The basic mobile-IP scheme does not utilize any route optimizations. It relies on the H A to tunnel the datagrams. As soon as the HA receives the mobile registration request from the M H , the HA updates its bindings accord-ingly. Datagrams can then be routed using the most update care-of address of the M H . Correct routing is the key to good performance in basic mobile-IP scheme, since the performance penalty in losing datagrams during handoff is severe in the transport layer. The key of good transport layer performance is to keep from losing datagrams. Chapter 6 Discussion of Simulation Results 69 Although the enhanced scheme, as a variant of the route optimized scheme, cannot guarantee the correctness of the routing during handoff. However, it has overcome the problem with another approach. By buffering the datagrams and forwarding it as soon as the registration is completed, the enhanced scheme can ensure that those datagrams received during the handoff will reach the correct host. In order to pick a best scheme among the three, there is a need to acquire long term averages of measured performance. 6.2 Simulation Results Parameter set 1, in Table 6.1, is used and the result is shown in Figure 6.7. The time between handoffs ranges from 2 to 40 seconds, and the end-to-end delay of the basic mobile-IP scheme becomes the worst as it provides no route optimizations. For this situation with relatively few handoffs, the IMHP scheme performs the best with the end-to-end TCP delay about 0.2 seconds. As the handoff rate increases slightly, the end-to-end delay of the IMHP scheme increases sharply. This is because the datagram loss rate in the IMHP scheme is directly propor-tional to the number of incorrectly routed datagrams. Since route optimization scheme relies on CAs (often the corresponding host) to send the datagrams directly to FAs, those CAs do not have up-to-date information regarding the location of the MHs during handoffs. The FAs do not play any active role in rectifying the problem. As the IMHP scheme cannot avoid losing datagrams, TCP interprets the situation as network congestion and performs exponential backoff and slow start which magnifies the problem. As a result, the IMHP scheme is very sensitive to change in handoff rate. At low handoff rates, the new enhanced scheme shows a lower end-to-end delay compared with the basic mobile-IP scheme. However, as the handoff rate increases (i.e. the time between Chapter 6 Discussion of Simulation Results 70 T 3 c w CJ H 12 11 10 Y <5> E n d - t o - E n d P e r f o r m a n c e A n a l y s i s f o r V a r i o u s M o b i l e - I P s c h e m e s B a s i c S c h e m e — R o u t e O p t i m i z e d S c h e m e o-H a n d o f f E n h a n c e d S c h e m e s -10 15 2 0 2 5 3 0 T i m e b e t w e e n H a n d o f f s (sec. ) 35 4 0 F i g u r e 6.7 T C P p e r f o r m a n c e f o r p a r a m e t e r set 1 handoff decreases), the two schemes give very similar results. This is due to the fact that the vulnerable period of the basic mobile-IP scheme is much smaller than the IMHP scheme, as described in chapter three. A more detailed analysis shows that, for datagrams to be incorrectly routed, the datagrams must reach the H A during the handoff but before the H A is aware that the M H has moved to another FA. For this to happen, the datagrams must arrive during the time period marked as DHFX Chapter 6 Discussion of Simulation Results 71 in Figure 3.2. A straightforward inference is that the vulnerability of the basic mobile-IP scheme depends heavily on the amount of time required for registration to reach the H A during the handoff. If the H A is far away from the M H ' s current care-of address, the transport layer end-to-end performance of the basic mobile-IP scheme is worsen as its vulnerable period has been increased. 6.3 Effect of the change in vulnerable period From chapter four, it has been concluded that the handoff enhanced scheme does not suffer from vulnerable periods. The next parameter to be considered is the effect of the duration of vulnerable period imposed on the other two schemes. The time taken for each mobile registration from M H i to the H A at neti is increased, since the data rate to net! has been reduced. This is analogous in placing the H A at a location which is further away from the M H . The parameters were slightly changed from those in set 1. This is to ensure that change in performance is due primarily to the changed factor alone. Simulation was performed using parameters in Table 6.2. Simulations were performed for a 2000 second connection period. This was repeated using 10 different random seeds. The result is shown in Figure 6.8. With the increase in vulnerable period by reducing the data rate between neti and Internet T a b l e 6.2 P a r a m e t e r set 2 P a r a m e t e r t y p e : M o b i l e l i n k da ta rate: 5 7 . 6 k b p s D a t a rate w i t h i n l o c a l n e t w o r k : 10 M b p s D a t a rate f r o m n e t i to Internet g a t e w a y : 196 k b p s D a t a rate f r o m net2 a n d net3 to Internet g a t e w a y : 2 5 6 k b p s M a x i m u m a c k n o w l e d g m e n t d e l a y : 2 s e c • Chapter 6 Discussion of Simulation Results 72 T a b l e 6.2 P a r a m e t e r set 2 P a r a m e t e r t y p e : R T T g a i n : 0 .125 R T T d e v i a t i o n g a i n : 0 .25 R T T d e v i a t i o n constan t : 4 o c w I o C W u H 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 E n d - t o - E n d P e r f o r m a n c e A n a l y s i s f o r V a r i o u s M o b i l e - I P s c h e m e s 1 1 1 1 1 5 10 B a s i c S c h e m e — ^ -R o u t e O p t i m i z e d S c h e m e o-H a n d o f f E n h a n c e d S c h e m e — © -1 1 i . . i i . i i , 15 2 0 25 3 0 35 4 0 J_ T i m e b e t w e e n H a n d o f f s (sec. ) F i g u r e 6.8 T C P p e r f o r m a n c e f o r p a r a m e t e r set 2 core gateway, the IMHP scheme suffers even worse degradation than in parameter set 1. It fails sharply as soon as the time between handoff decreases. The IMHP scheme is therefore not a very Chapter 6 Discussion of Simulation Results desirable scheme under handoff intensive situations. 73 The basic mobile-IP scheme demonstrates a rather flat response regarding to changes in handoff rate. The immunity to handoff rate is due to the lack of optimization. Datagrams have to be tunnelled by the HA through to the M H regardless of its current location. As handoffs become more frequent, the basic mobile-IP scheme begins to show weakness as the system is inevitably losing more datagrams due to incorrect routing. The end-to-end delay pattern stays relatively flat for handoff period from 10 to 40 seconds. Throughout this simulation, the handoff enhanced scheme performs the best among all three schemes. Although the data rate from ne^ and the Internet gateway has been decreased, this does not degrade the TCP end-to-end delay in the handoff enhanced scheme with the same extent as this scheme does not suffer from this increase in vulnerable period. Once again, the handoff enhancement scheme has shown immunity to vulnerable period which verifies the analysis in chapter four. A third set of parameter was chosen for running the simulation. The parameters are shown in Table 6.3. T a b l e 6.3 P a r a m e t e r set 3 P a r a m e t e r t y p e : M o b i l e l i n k d a t a rate: 57 .6 k b p s D a t a rate w i t h i n l o c a l n e t w o r k : 10 M b p s D a t a rate f r o m net ! to Internet ga teway : 128 k b p s D a t a rate f r o m net2 a n d net3 to Internet ga teway : 2 5 6 k b p s M a x i m u m a c k n o w l e d g m e n t d e l a y : 2 sec R T T g a i n : 0 .125 R T T d e v i a t i o n g a i n : 0 .25 R T T d e v i a t i o n constant : 4 Chapter 6 Discussion of Simulation Results 74 The simulation were repeated with 10 different random seeds. The result-is shown in Figure 6.9. With the increased vulnerability of the basic scheme, the handoff enhanced scheme has shown improvement by a wider margin with a handoff period at the 2 second range. This is o W T 3 C pq CL, C J H 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 E n d - t o - E n d P e r f o r m a n c e A n a l y s i s f o r V a r i o u s M o b i l e - I P s c h e m e s H a n d o f f E n h a n c e d S c h e m e R o u t e O p t i m i z e d S c h e m e B a s i c S c h e m e 10 15 2 0 2 5 T i m e b e t w e e n H a n d o f f s (sec. ) 3 0 _L_L _ L 35 4 0 F i g u r e 6.9 T C P p e r f o r m a n c e f o r p a r a m e t e r set 3 due to that fact that the basic scheme is more vulnerable with the increased delay in handling mobile registrations. In addition, there is a clear margin of improvement throughout the entire handoff period range. Chapter 6 Discussion of Simulation Results 75 It has been shown that the registration delay has significant effect over the TCP end-to-end delay, the simulation model was modified to investigate the effect of further increasing propaga-t e C W T3 • C m CL, u End-to-End Performance Analysis with handoff every 40 sec Handoff Enhanced Scheme —e— Basic Scheme —a— •& J_ J_ 0 .0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Propagation delay between netl and gateway (sec.) Figure 6.10 TCP performance with inserted propagation delay (handoff every 40 sec) tion delay within the link from the H A at netj to the Internet core gateway. This additional propagation delay was varied between 0 to 0.9 sec. and the measurements were made over the TCP end-to-end delay for the connection over M H j . Simulations were performed using the basic IETF scheme and the new handoff enhanced scheme. The parameters set 3 was chosen. The same Chapter 6 Discussion of Simulation Results 76 TCP connection was maintained at the M H i for a period of 2000 seconds. The results are shown End-to-End Performance Analysis with handoff every 2 sec A pq T3 C pq CL, U H 4 h Handoff Enhanced Scheme — e — Basic Scheme — A — — A ' in Figure 6.10. 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Propagation delay between neti and gateway (sec.) Figure 6.11 T C P performance with inserted propagation delay (handoff every 2 sec) As the propagation delay between the HA at neti and the Internet core gateway increases, the probability of datagrams arriving during the vulnerable period increases. The increase in the measured TCP end-to-end delay is proportional to the increase in propagation delay. Again, this Chapter 6 Discussion of Simulation Results 77 agrees with the analysis in chapter three regarding the vulnerable period of the basic IETF scheme. In the case of the new enhanced scheme, the same amount of propagation delay has been inserted into the model. It is shown that the new scheme has an increasing margin of improvement of TCP end-to-end delay over the basic scheme as propagation delay increases. This is due to the fact the new scheme does not suffer from a vulnerable period in which datagrams are lost. The simulation was repeated with a higher handoff rate. In this case, the handoff period is changed to 2 seconds. The other parameters were kept the same as in the previous case. The result is shown in Figure 6.11. In this case of the basic IETF scheme, the TCP end-to-end delay is shown to have increased with the increase in the added propagation delay. This confirms that the TCP end-to-end performance of the basic IETF scheme is determined by the duration of vulnerable period. Once again, the new enhanced scheme has shown improvement in TCP end-to-end perfor-mance over the basic IETF scheme as the propagation delay increases. 6.4 Summary of Performance Comparison The performance comparison for parameter set 2 is tabulated in Table 6.4. The TCP end-to-end delays are normalized to the basic mobile-IP scheme end-to-end delay. The normalized TCP end-to-end delay for the IMHP scheme in parameter set 2 has only Table 6.4 Performance comparison for parameter set 2 T i m e b e t w e e n h a n d o f f s (sec) N o r m a l i z e d T C P e n d - t o - e n d d e l a y (%) R o u t e o p t i m i z e d s c h e m e E n h a n c e d s c h e m e 2 559 88 4 385 97 Chapter 6 Discussion of Simulation Results 78 T a b l e 6.4 P e r f o r m a n c e c o m p a r i s o n f o r p a r a m e t e r set 2 T i m i 1 b e t w e e n h a n d o f f s (sec) N o r m a l i z e d T C P e n d - t o - e n d d e l a y (%) R o u t e o p t i m i z e d s c h e m e E n h a n c e d s c h e m e 6 3 5 2 9 6 10 2 8 3 8 0 16 3 1 2 9 6 2 0 2 0 8 84 4 0 8 2 8 0 T a b l e 6.5 P e r f o r m a n c e c o m p a r i s o n f o r p a r a m e t e r set 3 T i m e b e t w e e n h a n d o f f s (sec) N o r m a l i z e d T C P e n d - t o - e n d d e l a y (%) R o u t e o p t i m i z e d s c h e m e E n h a n c e d s c h e m e 2 5 7 0 84 4 3 1 9 89 6 301 94 8 2 6 5 8 0 10 2 8 0 83 16 2 2 2 73 2 0 2 0 7 8 0 4 0 81 8 0 shown improvement over basic scheme when the handoff rate is very low. Whereas for the enhanced scheme, it shows consistent improvement over the basic scheme. With parameter set 3, the result is tabulated in Table 6.5. It is now evident that the handoff enhanced scheme is well suited for situations with high handoff rates. The IMHP scheme can only give better performance when the handoff rate is low. The improvement factor is about 12% for very low handoff situation. For the handoff enhanced scheme, it yields improvement of over 10% in most cases. The maximum gain from this scheme is 27%. Even at high handoff rate, the handoff enhanced scheme delivers performance improvement of over 12% for the system model and parameters considered. Chapter 6 Discussion of Simulation Results 79 With additional propagation delay at the link between the H A of neti and the Internet gateway, the results, for the system with handoffs every 40 seconds, are tabulated in Table 6.6. The TCP end-to-end delay is normalized against the basic IETF scheme. For the system setup and the parameters considered, improvements of up to 54% has been found in the new enhanced scheme. ; T a b l e 6 .6 N o r m a l i z e d T C P e n d - t o - e n d d e l a y w i t h h a n d o f f e v e r y 4 0 s e c P r o p a g a t i o n d e l a y (sec) N o r m a l i z e d T C P e n d - t o - e n d d e l a y (%) 0.0 8 0 0.1 66 0.2 57 0.3 58 0.4 52 0.5 52 0.6 4 6 0.7 50 0.8 51 0.9 51 For the system with handoffs every 2 seconds and additional propagation delay for the link between neti and the Internet, the results are tabulated and shown in Table 6.7. The TCP end-to-end delay are normalized against the values for the basic IETF scheme. The end-to-end performance of the new scheme is found to be better than the IETF T a b l e 6.7 N o r m a l i z e d T C P e n d - t o - e n d d e l a y w i t h h a n d o f f e v e r y 2 sec P r o p a g a t i o n d e l a y (sec) N o r m a l i z e d T C P e n d - t o - e n d d e l a y {%) . 0 . 0 85 0.1 8 2 0.2 78 Chapter 6 Discussion of Simulation Results _ 80 T a b l e 6.7 N o r m a l i z e d T C P e n d - t o - e n d d e l a y w i t h h a n d o f f e v e r y 2 s e c P r o p a g a t i o n d e l a y (sec) N o r m a l i z e d T C P e n d - t o - e n d d e l a y (%) 0.3 7 5 . 0.4 74 0.5 7 0 0.6 7 2 0.7 6 7 0.8 6 7 0.9 67 scheme. Improvements of up to 33% was found with the system setup considered. From the results, it is shown that the IMHP scheme can deliver improved performance over the basic IETF scheme under light handoff situation. The reduction of triangular routing does bring along improvement in overall performance. However, as the handoff rate increases, the scheme suffers greatly and is deemed unstable. It is evident that the improvements in TCP end-to-end delay performance has been achieved in most cases with the proposed handoff enhanced scheme. This scheme is proved to deliver better performance even when handoff intensity is high. Moreover, the scheme is able to withstand the change in mobile registration delay without compromising its performance, since it does not suffer from datagram losses during handoffs. Chapter 7 Conclusion In this study, a new handoff enhanced scheme was proposed. Together with two other different proposals of mobile-IP, these proposals were simulated in OPNET and the TCP end-to-end delays were measured by simulation. The basic IETF mobile-IP scheme proposed was the basis for comparison, since it had been approved as an Internet standard. It was found that this basic scheme provided a stable system. However the performance could not be improved, since it does not employ any optimiza-tion. Consequently, the routing in this scheme is suboptimal, and hence, wasting network bandwidth which is already scarce in mobile links. A route optimization (IMHP) scheme was analyzed to seek for improvement over the basic scheme. The scheme was found to be useful at low handoff rate. According to the simulation results, this new scheme degraded tremendously with a slight increase in handoff rate. Since datagrams were sent directly to the FAs, datagram loss became excessive during handoffs. As a result, the transport layer protocol had to devote a lot of bandwidth in synchronizing the connec-tion. This scheme is only suitable for those MHs with infrequent handoffs. The handoff enhanced scheme, being a variant of route optimization scheme, was shown by simulation that it could decrease the TCP end-to-end delay over the other two schemes. With the particular system model and parameters, it was found that the reduction in TCP end-to-end delay of up to 27% over the basic scheme could be achieved. When additional mobile registration delay had been introduced, it was found that the reduction in TCP end-to-end delay could be up to 54%. 81 Chapter 7 Conclusion 82 Besides, the handoff enhanced scheme did not suffer from instability problems as found in the IMHP scheme. In most cases, the buffering method prevented datagram loss. This had reduced the TCP end-to-end delay by a significant amount, since datagram losses had detrimental effects over TCP connection. By preventing possible datagram loss, the transport layer protocol would not mistakenly throttle the traffic. By eliminating that source of datagram losses, the new handoff enhanced scheme is found to be well suited for situations with frequent handoffs. In addition, this new scheme waits for registration reply before relaying datagrams immediately. This would prevent the security loophole of replay message attack on the foreign agent by a malicious host. Thus the security of the system is not compromised. Moreover, this scheme does not require any TCP layer modification to be made. As a result, the proposed handoff enhanced scheme for FAs can be easily applied. Hence, any TCP connections with MHs connected to these FAs can be improved. Chapter 7 Conclusion Possible Furtherwork: 83 • As there are a lot of variations within Internet, another approach to test the scheme is to implement it over a relative simple network. Possible choices are Linux and FreeBSD, as the source code for these operating systems are publicly available and has been quite stable in performance. (Note that a PC with 804861 (66MHz) processor could out-perform a SPARCstation2 IPX with the benchmark tests for Unix machines [29].) Starting from version 2.0 onwards, Linux kernel supports the-use of IP tunnelling. Adapting the proposed scheme into these operating systems are made quite straightforward. Besides, for mobile computing to be feasible, the operating system has to be able to run on PC or laptop computers. • Another interesting alternative would be to look at performance improvement with specialized code with the TCP layer to handle the handoff. This approach should give even more dramatic improvement. Indirect TCP scheme, for example, could be a good candidate for investigation.. •l 2 8 0 4 8 6 is a p r o d u c t d e v e l o p e d b y Intel C o r p o r a t i o n , Inc . S P A R C s t a t i o n is a reg is te red t r a d e m a r k o f S P A R C In ternat iona l , Inc . , l i c e n s e d e x c l u s i v e l y to S u n M i c r o -s y s t e m s , Inc . Glossary This section provides a list of acronyms used in this thesis. BS - Base Station C A - Cache Agent C H - Corresponding Host FA - Foreign Agent. HA - Home Agent ICI - Internal Control Interface IETF - Internet Engineering Task Force IMHP - Internet Mobile Host Protocol L A N - Local Area Network LSR - Loose Source Routing M A - Mobile Agent (Home Agent and Foreign Ag MOBILE-IP - Internet Protocol with mobility extension RTT - Round Trip Time TCP - Transport Control Protocol UDP - User Datagram Protocol W M D N - Wireless and Mobile Data Network 84 REFERENCES [I] C. Perkins, IP Mobility Support, RFC 2002, Oct. 1996. • [2] A. Myles, D. B. Johnson, and C. E. Perkins, \"A Mobile Host Protocol Supporting Route Optimization and Authentication,\" IEEE Journal on Selected Areas in Communications, vol. 13, pp. 839-849, June 1995. [3] P. Manzoni, D. Ghosal, and G. Serazzi, \"Impact of Mobility on TCP/IP: An Integrated Performance Study,\" IEEE Journal on Selected Areas in Communications, vol. 13, pp. 858-867, Jun. 1995. [4] J. Postel, Transmission Control Protocol, RFC793, Sep. 1981. [5] International Organization for Standardization, Basic Reference Model for Open Systems Interconnection, ISO 7498, 1984. [6] C. Perkins, \"Providing continuous network access to mobile hosts using TCP/IP,\" Comput. Networks, ISDN Syst., vol. 26, pp. 357-369, 1993. [7] D. B. Johnson, \"Mobile host internetworking using IP loose source routing,\" School of Comput. Sci., Carnegie Mellon Univ., Pittsburgh, PA, tech. rep. CMU-CS-93-128, Feb. 1993. [8] F. Teraoka, Y. Yokote, and M . Tokoro, \"A network architecture providing hosts migration transparency,\" in Proc. ACM SIGCOMM '91, Zurich, Switzerland, pp. 209-220, Sep. 1991. [9] J. Ioannidis, D. Duchamp, and G. Q. Maquire, \"IP based protocols for mobile internetworking,\" in Proc. ACM SIGCOMM '91, Zurich, Switzerland, pp. 235-245, Sep. 1991. [10] H. Wada, T. Yozawa, T. Ohhishi, and Y. Tanaka, \"Mobile computing environment based on Internet packet forwarding,\" in Proc. Winter 1993 Usenix Conf, San Diego, CA, Jan. 1993. [II] A. Myles and D. Skellern; \"Comparison of mobile host protocols for IP,\" Internetworking: Res., Experience, vol. 4, no. 4, Dec. 1993. 85 References 86 [12] C. E. Perkins and P. Bhagwat, \"A Mobile Networking System based on Internet Protocol,\" IEEE Personal Communications, pp. 32-41, First Quarter 1994. [13] D. E. Comer, Internetworking with TCP/IP, vol. 1, Prentice-Hall, 1991. [14] R. Droms, Dynamic Host Configuration Protocol, RFC 1541, Oct. 1993. [15] J.'Postal, Internet Control Message Protocol, RFC 792, Sep. 1981. [16] J. Postel, User Datagram Protocol, RFC 768, Aug. 1980. [17] Ronald L. Rivest, The MD5 Message-Digest Algorithm, RFC 1321, Apr. 1992. [18] D. E. Eastlake, S. D. Crocker, and J. I. Schiller, Randomness Requirements for Security, RFC 1750, Dec. 1994. [19] P. Karn, and C. Partridge, \"Improving Round-Trip Time Estimates in Reliable Transport Protocols,\" Proceedings of ACM SIGCOMM '87, pp. 2-7, 1987. [20] V. Jacobson, \"Congestion avoidance and control,\" in Proc. ACM SIGCOMM '88, Stanford, CA, pp. 314-329, Aug. 1988. [21] M . Ulema, K. Khalil, \"Access Traffic Characteristics of a Wide Area Network,\" Proceedings of Global Data Networking,-pp. 146-153, Dec. 1993. [22] J. Nagle, \"Congestion Control in TCP/IP Internetworks,\" ACM Communication Review, pp. 11-17, Oct. 1984. [23] S. Shenker, S. Zhang, and D. Clarck, \"A Theoretical Analysis of Feedback Flow Control,\" ACM Computer Communication Review, pp. 156-165, Sep. 1990. . [24] D. Chiu and R. Jain, \"Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks,\" Computer Networks and ISDN System, vol. 17, pp. 1-14,1989. [25] H. Zygmunt, \"Adaptive Admission Congestion Control,\" A C M Computer Communications Review, vol. 21, no. 5, pp. 58-76, Oct. 1991. References 87 [26] L. Huynh, R. Chang, and W. Chou, \"Performance Comparison between TCP Slow-Start and a new Adaptive Rate-Based Congestion Avoidance Scheme,\" MASCOTS '94: Modeling, Analysis, and Simulation I nt' I Workshop, pp. 300-307, 1994. [27] K. Khalil, and Y. S. Sun, \"Performance Considerations for TCP/IP in Wide Area Networks,\" Local Computer Networks, 19th Conference, pp. 166-175, 1994. [28] R. Caceres, and L. Iftode, \"Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments,\" IEEE Journal on Selected Areas in Communications, vol. 13, pp. 850-857, Jun. 1995. [29] R. Grehan, \"Our new algorithm-based Native Mode suite tests processor performance and FPU capabilities for a variety of CPUs,\" BYTE Magazine, pp. 73-82, Mar. 1995. Appendix A. Supplementary Source Code of the IETF Model /* mobile_rte_sup.ex.c */ /* Routing support procedures f o r the Mobile IP example model */ ttinclude (•include \"mobile-ip .h\" #include \"mobile_rte_sup.h\" #include \" i p _ r t e _ s u p . h \" #include \"protocol.h\" /* Functions c a l l e d by Process Module */ L i s t * mobile_rte__sup„table_setup ( f ile_name) char *file_name; { L i s t * m o b i l e _ s t r m _ l i s t _ p t r ; L i s t * l i n e _ l i s t _ p t r ; m o b i le_rte_table*table_ptr,-/* Provides comprehensive r o u t i n g t a b l e loading and p a r s i n g */ /* s e r v i c e s f o r Mobile IP module. */ FIN (mobile_rte_sup_table_setup (file_name, netO, nodeO, n e t i , nodel, net2, node2)) /* Load the l i s t of t e x t l i n e s from the s p e c i f i e d f i l e \" . */ /* Note: this\"procedure w i l l q u i t the simnulation i f */ /* f i l e cannot be loaded, so i t i s assumed that there */ /* are no problems upon r e t u r n i n g . */ l i n e _ l i s t _ _ p t r = mo b i l e _ r t e _ s u p _ t a b l e _ l o a d (file_name); /* Parse the contents of the obtained l i s t i n t o */ /* a r o u t i n g - i n s t r u c t i o n t a b l e . */ m o b i l e _ s t r m _ l i s t _ p t r = m o b i l e _ r t e _ s u p _ l i s t _ p a r s e ( l i n e _ l i s t _ p t r ) ; /* In debug mode, i f t r a c i n g i s a c t i v e , p r i n t the t a b l e */ i f (op_prg_odb_trace_active ()) { mo b i l e _ r t e _ s u p _ t a b l e _ p r i n t ( m o b i l e _ s t r m _ l i s t _ p t r ) ,-} FRET( m o b i l e _ s t r m _ l i s t _ p t r ) ,-} • . ' L i s t * m o b i l e _ r t e _ s u p _ t a b l e _ l o a d (file_name) char *file_name; { L i s t * l i n e _ l i s t _ p t r ; char e r r _ s t r [256],-/* Read i r i a r o u t i n g t a b l e from an a s c i i */ /* f i l e adhering to format defined above. */ FIN (mobile_rte_sup_table_load (file_name)) /* Open and read the f i l e i n t o the l i s t . */ l i n e _ l i s t _ p t r = op_prg_gdf_read ( f ile_name) ,-88 Appendix A. Supplementary Source Code of the IETF Model /* Test f o r e r r o r i n reading. */ i f ( l i n e _ l i s t _ p t r == OPC_NIL) • { s p r i n t f ( e r r _ s t r , \" F i l e Name: %s\", file_name); op_sim_end (\"Package : mobile_rte_sup\", \"Error : Unable to read r o u t i n g t a b l e f i l e r r _ s t r , \" \" ) ; \\ } ' ' /* Return the l i s t of. t e x t l i n e s . */ FRET ( l i n e _ l i s t _ p t r ) } L i s t * m o b i l e _ r t e _ s u p _ l i s t _ p a r s e ( l i n e _ l i s t _ p t r ) L i s t * l i n e _ l i s t _ p t r ; { L i s t * m o b i l e _ s t r e a m _ l i s t _ p t r ,-mo b i l e _ r t e _ t a b l e * m r t _ p t r ; i n t i , num_lines,-char* l i n e ; L i s t * f i e l d _ l i s t _ p t r ; /* E x t r a c t i n f o r m a t i o n from the l i n e s of an a s c i i r o u t i n g t a b l e */ /* and construct a corresponding r o u t i n g t a b l e s t r u c t u r e which */ /* contains r o u t i n g i n s t r u c t i o n s . */ FIN, ( m o b i l e _ r t e _ s u p _ l i s t _ p a r s e ( l i n e _ l i s t _ p t r ) ) /* A l l o c a t e a rou t i n g t a b l e s t r u c t u r e . */ ' • mrt_ptr = (mobile_rte_table*) op_prg_mem_alloc ( s i z e o f ( m o b i l e _ r t e _ t a b l e ) ) /* A l l o c a t e a temporary t a b l e f o r ho l d i n g l i s t s . */ mobile_stream_^list_ptr = o p _ p r g _ l i s t _ c r e a t e ( ) ; /* Scan through each of the l i n e s , one at a time. */ num_lines = o p _ p r g _ l i s t _ s i z e ( l i n e _ l i s t _ p t r ) ; f o r ( i = 0; i < num_lines; i++) { • /* Obtain the i _ t h l i n e . */ l i n e = o p _ p r g _ l i s t _ a c c e s s ( l i n e _ l i s t _ p t r , i ) ; /* Decompose i t i n t o f i e l d s ( f i e l d boundaries are */ /* i n d i c a t e d by spaces, tabs, slashes, or commas. */ f i e l d _ l i s t _ p t r = op_prg_str_decomp ( l i n e , \" , / \\ t \" ) , -/* Format f or a l i n e i s as f o l l o w s : */ /* */ /* Incomplete l i n e s are skipped. */ i f ( o p _ p r g _ l i s t _ s i z e ( f i e l d _ l i s t _ p t r ) < 4) continue ,-/* Create a r o u t i n g i n s t r u c t i o n s t r u c t u r e . */ • mrt_ptr = (mobile_rte_table*) op_prg__mem_alloc ( s i z e o f (mobile_rte_table) ) ; /* Transfer the parsed f i e l d s i n t o the s t r u c t u r e */ /* F i r s t o b t a i n the d e s t i n a t i o n stream and mtu f i e l d s . */ mrt_ptr->strearn = a t o i ( op _ p r g _ l i s t _ a c c e s s ( f i e l d _ l i s t _ p t r , MOBILE_TBL_OUTSTREAM)); mrt_ptr->mtu = a t o i ( op _ p r g _ l i s t _ a c c e s s ( f i e l d _ l i s t _ p t r , MOBILE_TBL_MTU)); Appendix A. Supplementary Source Code of the IETF Model mrt_ptr->careof.net = a t o i ( ' o p _ p r g _ l i s t _ a c c e s s ( f i e l d _ l i s t _ p t r , M0BILE_TBL_CAREOF_NET)); mrt_ptr->careof.node = a t o i ( o p _ p r g _ l i s t _ a c c e s s ( f i e l d _ l i s t _ p t r , MOBILE_TBL_CAREOF_NODE) ) ,-i f (mrt_ptr->mtu <= 0) mrt_ptr->mtu = 0x7FFFFFFF; i f (rnrt_ptr->careof-net == ADDRESS_UNDEFINED && mrt_ptr->careof.node == ADDRESS_UNDEFINED ) { /* careof address not implemented */ mrt_ptr->condition = CONDITION_ENABLED; } • e l s e { . /* d i s a b l e a l l c o n d i t i o n f l a g s i n i t i a l l y */ mrt_ptr->condition = CONDITION_DISABLED; } /* Append the r o u t i n g i n s t r u c t i o n to the temporary l i s t . */ o p _ p r g _ l i s t _ i n s e r t ( m o b i l e _ s t r e a m _ l i s t _ p t r , mrt_ptr, OPC_LISTPOS_TAIL) } FRET{ m o b i l e _ s t r e a m _ l i s t j > t r ) } v o i d / m o b i l e _ r t e _ s u p _ t a b l e _ p r i n t ( m o b i l e _ s t r e a m _ l i s t _ p t r ) L i s t * m o b i l e _ s t r e a m _ l i s t _ p t r ; { mobile_rte_table*table„entry; i n t i , s i z e ; char dne_str [128], dno_str [128],-char ' nne_str [128], nno_str [128], strO [512],-/* P r i n t the contents of 'a r o u t i n g t a b l e . */ FIN ( m o b i l e _ r t e _ s u p _ t a b l e _ p r i n t ( m o b i l e _ s t r e a m _ l i s t _ p t r ) ) s i z e = o p _ p r g _ l i s t _ s i z e ( m o b i l e _ s t r e a m _ l i s t _ p t r ),-i f ( s i z e == 0 ) { op_prg_odb_print_major (\"Routing t a b l e i s empty\", VOS_NIL) ,-} else{ op_prg_odb_print_major (\"Routing t a b l e contents :\", VOS_NIL); for ( i = 0,- i < s i z e ; i++) { table_entry'= (mobile_rte_table*) o p _ p r g _ l i s t _ a c c e s s ( m o b i l e _ s t r e a m _ l i s t _ p t r , i ) s p r i n t f f strO, \"Stream (%d): mtu (%d)\" , table_entry->stream, table_entry->mtu ); op_prg_odb_print_minor (strO, VOS_NIL); } } F O U T } Compcode Appendix A. Supplementary Source Code of the IETF Model 91 mobile_rte_sup_route_select ( ro u t e _ t a b l e , mobile_table, pkptr, i c i _ p t r , mobile_agnt_flag, p k _ i d , t t l , HA_bind_ptr, FA_bind_ptr,' MH_bind_ptr /* , home_netO, home_netl, home_net2 )*/ , ipO, i p l , ip2 ) i p _ r t e _ t a b l e * r o u t e _ t a b l e ; L i s t ' *mobile_table; Packet *pkptr; I c i * i c i _ p t r ; i n t m o bile_agnt_flag; i n t * p k _ i d ; i n t t t l ; L i s t *HA_bind_ptr, *FA_bind_ptr, *MH_bind_ptr; IP *ipO, * i p l , * i p 2 ; / * i n t home_netO, home_netl, home_net2;*/ { i n t i , j , num_bind, num_multi_bind; IP ' dest; ' • HA_mobility_binding*home_entry; F A _ m o b i l i t y _ b i n d i n g * v i s i t o r _ e n t r y ; . m u l t i _ b i n d i n g *multi_bind_entry; Compcode status,-0 FIN (mobile_rte_sup_route_select( r o u t e _ t a b l e , mobile_table, pkptr, ...)) op_pk_nfd_get( pkptr, \"dest_net\", Sdest.net ); op_pk_nfd_get ( pkptr, \"dest_node\", kdest.node ) ,-/* Se l e c t a route from the r o u t i n g t a b l e which matches the */ /* requested d e s t i n a t i o n network and node. */ i f ( !memcmp( &dest, ipO, s i z e o f ( I P ) ) I I !memcmp( &dest, i p l , s i z e o f ( I P ) ) I I !memcmp( i d e s t , ip2, s i z e o f ( I P ) ) ) • FRET ( OPC_COMPCODE_FAILURE ); i f ( send_via_FA( pkptr, MH_bind_ptr, mobile_table, i c i _ p t r , dest, mobile_agnt_flag ) == OPC_COMPCODE_SUCCESS ) FRET ( OPC_COMPCODE_SUCCESS ) el s e i f ( f o r w a r d _ t o _ v i s i t o r ( mobile_table, FA_bind_ptr, pkptr, i c i _ p t r - , dest ) = = OPC_COMPCODE_SUCCESS ) FRET ( OPC_COMPCODE_SUCCESS ) , el s e i f ( encap_packet( r o u t e _ t a b l e , HA_bind_ptr, pkptr, i c i _ p t r , ipO, dest, p k _ i d , t t l ) == OPC_COMPCODE_SUCCESS ) ' . FRET ( OPC_COMPCODE_SUCCESS ) el s e FRET ( OPC_COMPCODE_FAILURE ) •Compcode send_via_FA( pkptr, b i n d _ l i s t _ p t r , mobile_table, i c i _ p t r , dest, a g n t _ f l a g ) L i s t * b i n d _ l i s t _ p t r , *mobile_table; I c i * i c i _ p t r ; Packet *pkptr; IP dest; i n t • a g n t _ f l a g ; { i n t i , s i z e ; i n t copy = f a l s e ; i n t next_net, next_node, stream, mtu; Packet *cp_pkptr,-Compcode Status= OPC_COMPCODE_SUCCESS; MH_FA_binding *f a _ e n t r y ; Appendix A. Supplementary Source Code of the IETF Model r n o b i l e _ r t e _ t a b l e * t a b l e _ e n t r y ; char s t r 0 [ 8 0 ] , s t r l [ 8 0 ] ; FIN( send_via_FA( pkptr, b i n d _ l i s t _ p t r , mobile_table, i c i _ p t r , dest ) ) /* F i r s t of a l l , check i f packet i s for any enabled streams */ s i z e = o p _ p r g _ l i s t _ s i z e ( mobile_table ) ,-for ( i=0; i < s i z e ; ++i ) { ta b l e _ e n t r y = (m o b i l e _ r t e _ t a b l e *) o p _ p r g _ l i s t _ a c c e s s ( mobile„table, i ) i f ( IP_equal( table_entry->careof, dest ) && tabl e _ e n t r y - > c o n d i t i o n == C0NDITION_ENABLED ) { stream = table_entry->stream,-mtu = table_entry->mtu; next_net = ADDRESS_UNDEFINED; next_node = ADDRESS_UNDEFINED; de l i v e r _ p a c k e t ( pkptr, i c i _ p t r , next_net, next_node, stream, mtu ); FRET( OPC_COMPCODE_SUCCESS ) /* Now, check to see i f there i s any m o b i l i t y b i n d i n g */ s i z e = o p _ p r g _ l i s t _ s i z e ( b i n d _ l i s t _ p t r ) ,- • i f ( s i z e == 0 && a g n t _ f l a g )/* no bindings and not a mobile node */ FRET( OPC_COMPCODE_FAILURE ) /* each enabled FA w i l l r e c e i v e a copy of the packet */ fort i=0; i < s i z e ; ++i ) { fa_entry = (MH_FA_binding *) o p _ p r g _ l i s t _ a c c e s s ( b i n d _ l i s t _ p t r , i ); /* ob t a i n the stream a s s o c i a t e d w i t h the current b i n d i n g */ stream = fa_entry->stream; i f ( chk_strm_condition(•mobile_table, stream, &mtu ) == CONDITION_ENABLED { '•• • mtu = get_strm_mtu( mobile_table, stream );*/ i f ( mtu == MOBILE_STRM_NONEXISTENT ) { s p r i n t f (strO, \"Discarding packet (%d) \", op_pk_id (pkptr)) s p r i n t f ( s t r l , \"Stream non-existent\" ); op_prg_odb_print_major (strO, s t r l , OPC__NIL) ; op_pk_destroy ( pkptr ) ,-} e l s e { next_net = fa_entry->careof'.net ; next_node = fa_entry->careof.node; #if 1 #else d e l i v e r _ p a c k e t ( pkptr, i c i _ p t r , next_net, next_node, stream,, mtu FRET( 0PC_C0MPCODE_SUCCESS ) copy = true,-cp_pkptr = op_pk_copy( pkptr ) ,-Appendix A. Supplementary Source Code of the IETF Model d e l i v e r _ p a c k e t ( cp_pkptr, i c i _ p t r , nexC_net, next_node, stream, mtu ); itendif } /* have ,to d e a l l o c a t e o r i g i n a l packet s i n c e i t i s no longer needed */ i f ( copy ) { . op_pk_destroy ( pkptr ) ,-FRET( status ) FRET( OPC_COMPCODE_FAILURE ) Compcode encap_packet( r o u t e _ t a b l e , b i n d _ l i s t _ p t r , pkptr, i c i _ p t r , current, dest, p k _ i d , t t l i p _ r t e _ t a b l e *route_table,-L i s t Packet I c i IP i n t i n t * b i n d _ l i s t _ p t r , -*pkptr; * i c i _ p t r ; c urrent, dest; * p k _ i d ; t t l ; char str0[512], strl [512] , -Packet *encap_pkptr,-Packet *warn_pkptr; Packet . *warn_ipptr; i n t ' i , j , num_bind, num_multi_bind; i n t next_net, next_node, outstrm, mtu; IP o r i g ; i n t d a t a _ l e n ; i n t copy = f a l s e ; HA_mobility_binding*home_entry; rnul t i _ b i n d i n g * mu 11 i_bind_en t ry ; Compcode Status = OPC_COMPCODE_FAILURE; . FIN( encap_packet( r o u t e _ t a b l e , ...) ) num_bind = o p _ p r g _ l i s t _ s i z e ( b i n d _ l i s t _ p t r ); i f ( num_bind == 0 ) FRET( OPC_COMPCODE_FAILURE ); for (i=0; ihome_addr, s i z e o f ( I P ) ) ) { Status = OPC_COMPCODE_SUCCESS; num_multi_bind = o p _ p r g _ l i s t _ s i z e ( home_entry->multi_bind_list ) f o r i j=0; jmulti_bind_list, /* encap_j3kptr = op_pk_copy ( pkptr );*/ data_len = o p _ p k _ t o t a l _ s i z e _ g e t ( p k p t r ) / 8 ; Appendix A. Supplementary Source Code of the IETF Model 94 encap_pkptr = op_pk_create_fmt( \"ip_dgram\" ); op_pk_bulk_size„set( encap_pkptr, data_len*8 ) ,-copy = true; op_pk_nfd_set( op_pk_nfd_set ( op_pk_nfd_set( op_pk_nf d_set ( op_pk_nfd_set( op_pk_nfd_set( encap_pkptr, \"data\" , op_pk_copy(pkptr) ) ; encap_pkptr, \"protocol\"., P R 0 T O C 0 L _ E N C A P encap_pkptr, \"src_net\", current .net ) ,-encap_pkptr, \"src_node\", current.node ); encap_pkptr, \"dest_net\", multi_bind_entry->careof.net ); encap_pkptr, \"dest_node\", multi_blnd_entry->careof.node ); op_pk_nfd_set( encap_pkptr,\"orig_len\",data_len), op_pk_nfd_set( encap_pkptr,\"frag_len\",data_len), op_pk_nfd_set( encap_pkptr,\"ident\", (*pk_id)++); op_pk_nfd_set( encap_pkptr,\"frag\", 0 ) ; op_pk_nfd_set( encap_pkptr, \" t t l \" , t t l ) ; / * Determine the output stream on which to route i t . * / i f (ip_rte_sup_route_select (route_table , multi_bind_entry->careof.net , multi_bind_entry->careof.node , &next_net, &next_node, koutstrm, &mtu) = = OPC_COMP.CODE_FAILURE) { / * If no route is provided, destroy the packet. */ i f (op_prg_odb_ltrace_active (\"ip_errs\")) { ' -sprintf (strO, \"Discarding unroutable packet (%d)\" , op_pk_id (encap_pkptr)); sprintf (s t r l , \"Destination: net (%d), node (%d)\" , multi_bind_entry->careof.net , multi_bind_entry->careof.node); op_prg_odb_print_major (strO, s t r l , OPC_NIL); ) op_pk_destroy (encap_pkptr); } -else { • deliver_packet(encap_pkptr, i c i _pt r , next_net, next_node , outstrm, mtu ) ,-} . • -} #if 0 / * At this stage, i t is assumed that binding exists * for mobile node. Therefore send binding warning * message to original sender * / if- ( route_optim == true ) { warn_pkptr = op_pk_create_fmt ( \"bind_warn\" ) ,-op_pk_nfd_set( warn_pkptr, \"home_addr_net\" , home_entry->home_addr. net ).,-op_pk_nfd_set( warn_pkptr, \"home_addr_node\" , home_entry->home_addr.node ); data_len = op_pk_total_size_get(warn_pkptr)/8; warn_ipptr = op_pk_create_f mt ( \"ip_dgram\" ) ,-op_pk_nfd_set( warn_ipptr, \"data\", warn_pkptr); Appendix A. Supplementary Source Code of the IETF Model 95 op_pk_bulk_size_set(warn_ipptr,data_len*8); op_pk_nfd_set( warn_ipptr, \"src_net\", current.net ); op_pk_nfd_set( warn_ipptr, \"src_node\", current.node ); op__pk_nfd_get ( pkptr, \"src_net\", Sorig.net ); op_pk_nfd_get( pkptr, \"src_node\", Sorig.node ); op_pk_nfd_set( warn_ipptr, \"dest_net\", orig.net ); op_pk_nfd_set( warn_ipptr, \"dest_node\",orig.node ); op_pk_nfd_set( warn_ipptr,\"orig_len\",data_len); „ ' op_pk_nfd_set (' warn_ipptr, \" f r a g _ l e n \" , data_len) ; op_pk__nf d_set (' warn_ipptr, \" f rag\" , 0 ); 1 op_p'k_nf d_set ( warn_ipptr, \" ident\" ; ( *pk_id)-+ + ) ; op_pk_nf d_set ( warn_ipptr,\"protocol\", PROTOCOL_UDP ) ,-deliver_packet( warn_ipptr, } • ' #endif } } • i f ( copy ) op_pk_destroy( pkptr ); FRET( status ) ) v o i d d e l i v e r ^ packet ( pkptr, i c i _ p t r , . n e x t j e t , next_n'ode, outstrm, mtu ) Packet I c i i n t *pkptr,-* i c i _ p t r ; next net, next node, outstrm, mtu; char str0[512], strl [ 5 1 2 ] ; i n t i , len; i n t header_size, f r a g _ s i z e , data_size; i n t dest_nef, dest_node; i n t t t l ; . ' i n t frag_accum, frag, num_frags; Packet *ip_pkptr, *data_pkptr, *f r a g _ p t r ; FIN( deliver_packet( pkptr, ) .) /* obtain packet's d e s t i n a t i o n */ op_pk_nfd_get ( pkptr, \"dest_net\", &dest_net .) ,-op_pk_nfd_get ( pkptr, \"dest_node\", sd e s t j i o d e ) ; tr) /* Decrement the packet's t l m e - t o - l i v e f i e l d . If zero i s reached, */ /* d i s c a r d the packet rather than send i t on. */ op_pk_nfd_get (pkptr, \" t t l \" , & t t l ) ; t t l - - ; i f ( t t l ==0) , ' ' /* In debug mode, i n d i c a t e that a packet i s destroyed */ /* due to an expired t t l . */ • i f (op_prg_odb_ltrace_active (\"ip__errs\") ) . • • } else{ { } • s p r i n t f (strO, \"Discarding packet (%d) with expired TTL\", op_pk_id • (pkp-s p r i n t f (strl\", \"Destination: net (%d), node (%d)\", dest_net, dest_node); op_prg_odb_print_major (strO, s t r l , OPC_NIL);. op_pk_destroy (pkptr); /* Assign the new decremented value of t t l . */ Appendix A. Supplementary Source Code of the IETF Model 96 op_pk_nfd_set (pkptr, \" t t l \" , t t l ) ; / * In debug mode, trace the routing action. * / i f (op_prg_odb_ltrace_active (\"mobile-ip_rte\")) { sprintf (strO, \"Routing towards (%d, %d)\",' dest_net, dest_node) ,-sprintf (s t r l , \"Next hop (%d, %d), output stream (%d)\", next_net, hext_node, outstrm) ,-op_prg_odb_print_major (strO, s t r l , OPC_NIL); } • / * Install an Ici indicating to the lower layer what the */ / * address of the next (intermediate) node i s . * / op_ici_attr_set ( ici_ptr , \"next_node\", next_node); o p _ i c i _ i n s t a l l ( i c i_ptr ) ; / * Obtain the size in bytes of the fragment. * / frag_size = op_pk_total_size_get (pkptr) / 8; / * Obtain the number of bytes of data carried in this fragment * / op_pk_nfd_get (pkptr, \"frag_len\", &data_size) ,-/ * Also obtain the difference between the packet size * / / * and the length f i e l d : this is the size of the header. */ header_size = frag_size - data_size; / * If i t is smaller than the maximum transfer unit, send i t as i s . */ i f (frag_size <= mtu) { op_pk_send (pkptr, outstrm) •; } else{ / * Otherwise, break i t into fragments * / / * Each fragment can contain up to (mtu - header_size) bytes of data */ num_frags = (data_size + mtu - header_size - 1) / (mtu - header_size); / * In debug mode, indicate the fragmentation. */ i f (op_prg_odb_ltrace_active (\"ip_frag\")) { sprintf (strO, \"Breaking datagram into (%d) fragments\", num_frags); op_prg_odb_print_major (strO, OPC_NIL) ,-} / * If the fragment is carrying the original datagram given to IP, / * extract i t before copies are made. Only one fragment can carry / * the original packet for the reassembly model to work properly, i f (op_pk_nfd_is_set (pkptr, \"ip_dgram\")) op_pk_nfd_get (pkptr, \"ip_dgram\", &ip_pkptr); else ip_pkptr = OPC_NIL; / * If the packet is carrying any encapsulated data (normally this * / / * would happen only for a packet fragmented for the f i r s t time), * / / * extract this data packet so that i t w i l l not appear in each */ / * fragment generated by copying. * / i f (op_pk_nfd_is_set (pkptr, \"data\")) op_pk_nfd_get (pkptr, \"data\", &data_pkptr); • else data_pkptr = OPC_NIL; / * Loop through and create the fragments . */ for (frag_accum =0, i = 0; i < num_frags; i++) { , / * Make a copy of the original packet. * / . frag_ptr = op_pk_copy (pkptr); Appendix A. Supplementary Source Code of the IETF Model 97 /* In d i c a t e that the copy i s a fragment */ op_pk_nfd_set . ( f r a g _ p t r , \" f r a g \" , 1); /* for a l l but the l a s t fragment, the s i z e i s the mtu. */ /* and the encapsulated i p packet i s not includ e d . */ . i f ( i < num_frags - i ) . { \" • \\ • . op_pk__nfd_set ( f r a g _ p t r , \" f r a g _ l e n \" , mtu - header_size) ; o p _ p k _ t o t a l _ s i z e _ s e t ( f r a g _ p t r , 8 * mtu); frag_accum += (mtu - h e a d e r _ s i z e ) ; • else{ */ from the */ avoid */ now be */ len = d a t a _ s i z e - frag_accum; op_pk_nfd_set ( f r a g _ p t r , ' \" f r a g _ l e r i \" , len) ; op_pk_total__size_set ( f r a g ^ p t r , 8 * (header_size + l e n ) ) ; /* I f the o r i g i n a l packet was'not'a fragment, encapsulate i t /* i n t o the l a s t fragment created here. */ op_pk_nfd_get (pkptr, \" f r a g \" , k f r a g ) ; i f ( ! frag) • ' ' • { ' ' ' -• /* I f the packet contained encapsulated data ( i . e \" , / • . t r a n s p o r t ) , that data w i l l have been removed to /* i t s d u p l i c a t i o n i n the fragments. The .data should /* r e i n s e r t e d i n t o the o r i g i n a l packet. */ i f (data_pkptr != OPC_NIL) op_pk_nfd„set (pkptr, \"data\", d a t a _ p k p t r ) ; . /* In e i t h e r case t h e ' o r i g i n a l packet, i s */ /* encapsulated i n thhe fragment. */ op_pk_nfd_set ( f r a g _ p t r , \"ip„dgrarn\",' p k p t r ) ; } • gram */ fragment */ ated */ ip_pkptr) ; /* Otherwise the\"packet can be discarded. */ else{ op_pk_destroy ( p k p t r ) ; /* Also, i f the packet included the o r i g i n a l datagram /* from which i t was generated, t r a n s f e r that data-/* i n t o the l a s t fragment created'here.' */ /* Note that i t i s p o s s i b l e , i n the case where a /* i s i t s e l f being fragmented, that none'of the cre-•/* fragments w i l l c o n t a i n the o r i g i n a l datagram. */ i f ( i p _ p k p t r != OPC_NIL) • . { ' ' op_pk_nfd_set (frag _ p t r , ' \"ip_dgram\", /* Forward the datagram' fragment. */. op_pk_send ( f r a g _ p t r , outstrm); } FOUT; Appendix A. Supplementary Source Code of the IETF Model 98 } Compcode for w a r d _ t o _ v i s i t o r ( mobile_table, b i n d _ l i s t _ p t r , pkptr, i c i _ p t r , dest ) L i s t * b i n d _ l i s t _ p t r , *mobile_table; Packet *pkptr,-I c i * i c i _ p t r ; IP dest; { ' ' char str0[80], s t r l [ 8 0 ] ; Compcode status = OPC_COMPCODE_FAILURE; i n t i , s i z e ; i n t next_net, next_node, stream, mtu; i n t copy = f a l s e ; F A _ m o b i l i t y _ b i n d i n g * v i s i t o r _ e n t r y ; Packet *cp_pkptr; • • FIN( fo r w a r d _ t o _ v i s i t o r ( mobile_table, b i n d _ l i s t _ p t r , pkptr, i c i _ p t r , dest ) ) s i z e = op_prg_list_siz'e ( b i n d _ l i s t _ p t r ),-i f ( s i z e ==0 )/* l i s t does not e x i s t */ FRET ( OPC_COMPCODE_FAILURE ) for( i=0; irg_list_access( b i n d _ l i s t _ p t r , i ); i f ( !memcmp(. &dest, &visitor_entry->home_addr, s i z e o f ( I P ) ) ) { /* There i s a match */ i f ( visitor_entry->home_agnt.net != ADDRESS_UNDEFINED && visitor_entry->home_agnt.node != ADDRESS_UNDEFINED ) { status = OPC_COMPCODE_SUCCESS; next_net = visitor_entry->home_addr.net; next_node = visitor_entry->home_addr.node; stream = visitor_entry->stream; mtu = get_strm_mtu( mobile_table, stream ); i f ( mtu == MOBILE_STRM_NONEXISTENT ) { s p r i n t f (strO, \"Discarding packet (%d) \", op_pk_id (pkptr)); s p r i n t f ( s t r l , \"Stream non-existent\" ); op_prg_odb_print_major (strO, s t r l , OPC_NIL); op_pk_destroy( pkptr ); } e l s e { copy = true; ' • • cp_pkptr = op_pk_copy( pkptr ); deliver_packet ( cp_pkptr, ici _ j D t r , next_net, next_node, stream, mtu ); i f ( copy ) op_pk_destroy( pkptr ); FRET( status ); } Appendix A. Supplementary Source Code of the IETF Model 99 int get_strm_rntu ( strm__ptr, strm ) List*strrn_ptr ; int strm; { int i , s ize; mobile_rte_table*strm_entry; FIN( get_strm_mtu( strm_ptr, strm ) ) size = op_prg_list_size( strm_ptr ); for( i=0; istream == strm ) FRET ( strm_entry->mtu ) ,-} FRET( MOBILE_STRM_NONEXISTENT ); } int chk_strm_condition( mobile_table, stream, mtu ) Lis t *mobile_table; int stream; int *mtu; { • ' . . int i , s ize; mobile_rte_table*table_entry; FIN( chk_strm_condition( mobile_table, stream, mtu ) ) size = op_prg_list_size( mobile_table ) ; ' for( i=0; istream == stream ) { *mtu = table_entry->mtu; FRET( table_entry->condition ) } / * stream does not exist */ *mtu = MOBILE_STRM_NONEXISTENT; FRET( CONDITION_DISABLED ) } void get_careof_addr( mobile_table, i c i p t r ) List *mobile_table; Ici * i c i p t r ; { int i , size'; int stream; IP careof; Appendix A. Supplementary Source Code of the IETF Model 100 mobile_rte_table*table_entry; . FIN( get_careof_addr( mobile_table, i c i p t r ' ) ) op_ici_attr_get( i c i p t r , \"stream\", &stream ); size = op_prg_list_size ( mobile_table ) ,-fort i=0; istream == stream ) { o p _ i c i _ a t t r „ s e t ( i c i p t r , \"careof_net\", table_entry->careof .net ); op_ici_attr_set( i c i p t r , \"careof_node\", table_entry->careof.node ); op_ici_attr_set( i c ip t r , \"status\", OPC_COMPCODE_SUCCESS ); FOUT / * stream does not exist */ op_ici_attr_set( i c i p t r , \"careof_net\", ADDRESS_UNDEFINED ); op_ici_attr_set( i c i p t r , \"careof_node\", ADDRESS_UNDEFINED ] ' op_ici_attr_set ( i c i p t r , \"status\", OPC_COMPC0DE_FAILURE ) ; FOUT } void set_strm_condition( mobile_table, i c i p t r ) List *mobile_table; Ic i * i c i p t r ; { IP careof; int stream; int mode; int i , s ize; Compcodestatus = OPC_COMPCODE_FAILURE; mobile_rte_table*list_ptr; FIN( set_strm_condition( i c i p t r ) ) op_ici_attr_get ( i c i p t r , \"mode\", imode ) ,-op_ici_attr_get( i c i p t r , \"stream\", &stream ) ; size = op_prg_list_size( mobile_table ); for( i=0; icondition = CONDITION_DISABLED; Status = OPC_C0MPC0DE_SUCCESS; break; case DISABLE_ALL_EXCEPT__THIS : i f ( list_ptr->stream != stream ) , ' { list_ptr->condition = CONDITION_DISABLED; status = OPC_COMPCODE_SUCCESS; } Appendix A. Supplementary Source Code of the IETF Model 101 break; case DISABLE_THIS_ONLY: i f f list_ptr->stream == stream ) { ' op_ici_attr_set( i c i p t r , \"careof_net\", list_ptr->careof.net ); op_ici_attr_set( i c i p t r , \"careof_node\" , list_ptr->careof .node ) ,-list_ptr->condition = CONDITION_DISABLED; status = OPC_COMPCODE_SUCCESS; } break; case ENABLE_ALL: list_ptr->condition = C 0 N D I T I 0 N _ E N A B L E D ; status = OPC_COMPCODE_SUCCESS; break; case ENABLE_ALL_EXCEPT_THIS: i f f . list_ptr->stream != stream ) { list_ptr->condition = CONDITION_ENABLED; Status = OPC_COMPCODE_SUCCESS; . } . -break; case ENABLE_THIS_ONLY: i f f list_ptr->stream == stream ) { op_ici_attr_set ( i c i p t r , \"careof_net\", list_ptr->careof .net ) ,-op_ici_attr_set( i c i p t r , \"careof_node\", list_ptr->careof.node ); list_ptr->condition = CONDITTON_ENABLED; status = OPC_COMPCODE_SUCCESS; } break; default: status = OPC_COMPCODE_FAILURE; break; } op_ici_attr_set( i c i p t r , \"status\", status ); FOUT } ' void hop_to_next_strm( mobile_table, i c i p t r ) Lis t *mobile_table; Ic i * i c i p t r ; { int - j , i , s ize; int stream; mobile_rte_table*table_entry; FINf hop_to_next_strm( mobile_table, i c i p t r ) ) op_ici_attr_get( i c i p t r , \"stream\", &stream ); size = op_prg_list_size ( rnobile_table ); for ( i=0; istream == stream ) Appendix A. Supplementary Source Code of the IETF Model 102 } i f ( .( j = i + 1 ) == size ) j = o',-table_entry = ( mobile_rte_table * ) • ' o p _ p r g „ l i s t _ a c c e s s ( mobile_table, j )•; op_ici_attr_set( i c i p t r , '\"stream\" , table_entry->stream ); op_ici_attr_set( i c i p t r , \"careof_net\" , table_entry->careof..net) ; op_ici_attr_set( i c i p t r , \"careof_node\" ,table_entry->careof.node); / * Now, enabling this stream*/ table_entry->condition = C O N D I T I O N _ _ E N A B L E D ; op_ici_attr_set( i c i p t r , \"status\" , O P C _ C O M P C O D E _ S U C C E S S ) ; ' F O U T } . op_ici_attr_set( i c i p t r , \"status\", O P C _ C O M P C O D E _ F A I L U R E F O U T ' Appendix B. Supplementary Source Code of the IMHP Model /* mobile_rte_sup.ex. c */ -/* Routing support procedures f o r - t h e Mobile IP example model */ ((include ((include \"mobile-ip .h\" #include \"mobile_rte_sup .h\" tt i n c l u d e \" i p _ r t e _ s u p . h\" ttinclude \"protocol.h\" /* Functions c a l l e d by Process Module */ L i s t * mobile_rte_sup_table_setup (file_name) char- *file_name; m o b i l e _ r t e _ t a b l e * t a b l e _ p t r ; /* Provides comprehensive r o u t i n g t a b l e l o a d i n g and p a r s i n g */ /* s e r v i c e s f o r Mobile IP module. */ FIN (mobile_rte_sup_table_setup (file_name, netO, nodeO, n e t l , nodel, net2, node2)) /* Load the l i s t of t e x t l i n e s from the s p e c i f i e d f i l e . */ /* Note: t h i s procedure w i l l q u i t the simnulation i f */ /* f i l e cannot be loaded, so i t i s assumed that there */ /* are no problems upon r e t u r n i n g . */ l i n e _ l i s t _ p t r = mobile_rte_sup_^table_load (f ile_narne) ,-/* Parse the contents of the obtained l i s t i n t o */ /* a r o u t i n g - i n s t r u c t i o n t a b l e . */ m o b i l e _ s t r m _ l i s t _ p t r = m o b i l e _ r t e _ s u p _ l i s t _ p a r s e ( l i n e _ l i s t _ p t r ) ,-/* In debug mode, i f t r a c i n g i s a c t i v e , p r i n t the t a b l e */ i f (op_prg_odb_trace_active ()) L i s t * L i s t * m o b i l e _ s t r m _ l i s t _ p t r ,-l i n e _ l i s t _ p t r ,-m o b i l e _ r t e _ s u p _ t a b l e _ p r i n t ( r n o b i l e _ s t r m _ l i s t _ p t r ) ; } FRET( r n o b i l e _ s t r m _ l i s t _ p t r ) ,-L i s t * ' m o b i l e _ r t e _ s u p _ t a b l e _ l o a d (file_name) char * f ile__narne; { L i s t * l i n e _ l i s t _ p t r ,-char e r r _ s t r [256]; /* Read i n a r o u t i n g t a b l e from an a s c i i */ /* f i l e adhering to format de f i n e d above. */ FIN (mobile_rte_sup_table^load ( f i'le_name) ) /* Open and read the f i l e i n t o the l i s t . */ l i n e _ l i s t _ p t r = op_prg_gdf_read (file_name); /* Test for e r r o r i n reading. */ 103 Appendix B. Supplementary Source Code of the IMHP Model i f ( l ine_l is t_ptr == OPC_NIL) { sprintf (err_str, \" F i l e Name: %s\", file_name) ,-op_sim_end (\"Package : mobile_rte_sup\", \"Error : Unable- to read routing table f i l err_str, \".\" ) ; } • • / * Return the l i s t of text l ines . * / FRET (line_list_ptr) } List* mobile_rte_sup_list_parse ( l ine_list_ptr) List* line_list_ptr,-{ L is t* .mobile_stream_list_ptr; mobile_rte_table*mrt_ptr ,-int i , num_lines; char* l i n e ; Lis t * f i e l d _ l i s t _ p t r ; / * Extract information from the lines of an a s c i i routing table * / / * and construct a corresponding routing table structure'which */ / * contains routing instructions. */ FIN (mobile_rte_sup_list_parse ( l ine_list_ptr)) / * Allocate a routing table structure. * / mrt_ptr = (mobile_rte_table*) op_prg_mem_alloc (sizeof (mobile_rte_table)) / * Allocate a temporary table for holding l i s t s . */ mobile_stream_list_ptr = o p _ p r g _ l i s t „ c r e a t e (); / * Scan through each of the lines, one at a time. * / num_lines = op_prg_list_size (l ine_list_ptr) ,-for (i = 0; i < num_lines; i++) { / * Obtain the i_th l i n e . */ l ine = op_prg_list_access ( l ine_l is t_ptr , i ) ; / * Decompose i t into f ields (f ield boundaries are */ / * indicated by spaces, tabs, slashes, or commas. * / f i e l d _ l i s t _ p t r = op_prg_str_decomp (line, \" , A t \" ) ; / * Format for a l ine is as follows-: * / / * */ / * Incomplete lines are skipped. * / i f (op_prg_list_size (f ield_list_ptr) < 4) continue; / * Create a routing instruction structure. */ mrt_ptr = (mobile_rte_table*) op_prg_mem_alloc (sizeof (mobile_rte_table)); / * Transfer the parsed fields into the structure * / / * F i rs t obtain the destination stream and mtu f i e l d s . * / mrt_ptr->stream = atoi ( op_prg_list_access ( f ie ld_l is t_ptr , MOBILE_TBL_OUTSTREAM)); mrt_ptr->mtu' = atoi ( op_prg_list_access ( f i e ld_ l i s t_pt r , M0BILE_TBL_J4TU) ) ,-mrt_ptr->careof.net = atoi ( op_prg_list_access ( f ie ld_l is t_ptr , MOBILE_TBL_CAREOF_NET)) Appendix B. Supplementary Source Code of the IMHP Model mrt_ptr->careof.node = atoi ( op_prg_list_access ( f ie ld_l is t_ptr , MOBILE_TBL_CAREOF_NODE)); i f (mrt_ptr->mtu <= 0) mrt_ptr->mtu = 0x7FFFFFFF; i f (mrt_ptr->careof.net == ADDRESS_UNDEFINED && mrt_ptr->careof.node == ADDRESS_UNDEFINED ) { / * careof address not implemented */ mrt_ptr->condition = CONDITION_ENABLED; } else { / * disable a l l condition flags i n i t i a l l y * / ' mrt_ptr->condition = CONDITION_DISABLED; } ' / * Append the routing instruction to the temporary l i s t . * / op_prg_list_insert (mobile_stream_list_ptr, mrt_ptr, OPC_LISTPOS_TAIL) } FRET( mobile_stream_list_ptr ) } void mobile_rte_sup_table_print (mobile_stream_list_ptr) Lis t *mobile_stream_list_ptr,-{ mobile_rte_table*table_entry; int i , s i z e ; char dne_str [128], dno_str [128]; • . • char nne_str [128], nno_str [128], strO [512],-/ * Print the contents of a routing table. '*/ FIN (mobile_rte_sup_table_print (mobile_stream_list_ptr)) size = op_prg_list_size( mobile_stream_list_ptr ),-i f ( size == 0 ) {' op_prg_odb_print_major (\"Routing table is empty\", VOS_NIL) ,-} else{ op_prg_odb_print_major (\"Routing table contents : \" , VOS_NIL) ,-for (i = 0; i < size; i++) { table_entry = (mobile_rte_table*) op_prg_list_access( mobile_stream_list_ptr, i ) sprintf( strO, \"Stream (%d): mtu (%d)\" , table_entry->stream, table_entry->mtu ) ,-op_prg_odb_print_minor (strO, VOS_NIL) ,-} ) FOUT } Compcode mobile_rte_sup_route_select ( mobile_table, pkptr, i c i_ptr , objid •, agnt_flag, pk_id, t t l Appendix B. Supplementary Source Code of the IMHP Model 106 List Packet Ic i Objid int int int List List IP int int , HA_bind_ptr, FA_bind_ptr , CA_bind_ptr, MH_bind_ptr , ipO, i p l , ip2, route_optim, *mobile_table; *pkptr ,-* i c i _ p t r ; obj i d ; agnt_flag; *pk_id; t t l ; *HA_bind_ptr, *FA_bind_ptr; *CA_bind_ptr, *MH_bind_ptr; ipO, i p l , ip2; route_optim; trash_unsent__pk; trash_unsent_pk char Packet int int int IP IP strO[100]; * inner_pkptr; optim; protocol; i , j , num_bind, src', dest; home_agnt ,-num multi bind; HA_'mobility_binding*home_entry ; FA_mobility_binding*visitor_entry,-multi_binding *multi_bind_entry; FIN (mobile_rte_sup_route_select( mobile_table, pkptr, . ) ) op_pk_nfd_get( pkptr, \"src_net\", &src.net ); op_pk_nfd_get( pkptr, \"src_node\", &src.node ); op_pk_nfd_get( pkptr, \"dest_net\", &dest.net ); op_pk_nfd_get( pkptr, \"dest_node\", &dest.node ) / * / * i f { Select a route from the routing table which matches the */ requested destination network and node. * / ( IP_equal( dest, ipO ) II IP_equal( dest, i p l ) I I IP_equal( dest, op_pk_nfd_get( pkptr, \"protocol\", sprotocol ); ip2 ) ) / * Not encapsulated ( not for a v i s i t o r ) * / i f ( protocol != PROTOCOL_ENCAP ) FRET (' MOBILE_RTE_TO_IP ) op_pk_nf d_get ( pkptr, \"data\", &inner_pkptr ),-op_pk_destroy( pkptr ); pkptr = inner_pkptr; op_pk_nfd„get( pkptr, \"dest_net\", &dest.net ); op_pk_nf d__get ( pkptr, \"dest_node\", &dest.node ); i f ( forward_to_visitor( mobile_table, FA_bind_ptr, pkptr, i c i_pt r , dest ) == OPC_COMPCODE_FAILURE ) { i f ( route_optim ) { check_ca_list( CA_bind_ptr, dest, &home_agnt ); i f ( home_agnt.net == ADDRESS_UNDEFINED && home_agnt.node == ADDRESSJJNDEFINED ) { home_agnt = src; } generate_bind_warning( home_agnt, objid, dest, src ); } Appendix B. Supplementary Source Code of the IMHP Model 107 i f ( trash_unsent_pk } { i f (op_prg_odb_ltrace_active (\"handoff\").) { ' sprintf (strO, \"Trashing pk(%d) at (%d,%d)\" , op_pk_id (pkptr), ipO.net, ' ipO.node) ,-op_prg_odb_print_major (strO, OPC_NIL); } • encap_pk_destroy( pkptr ); FRET( MOBILE_RTE_FAILURE ) } else { i f (op_prg_odb„ltrace_act ive (\"handoff\")) { sprintf (strO, \"Resending pk(%d) at (%dj%d)\" , op_pk_id (pkptr), ipO.net, ipO.node); op_prg__odb_print_major (strO, OPC_NIL); } encap_pk_send( pkptr ); FRET( MOBILE„RTE_ENCAP ) } } else { / * packet sent to v i s i t o r * / FRET ( MOBILE_RTE_SUCCESS ) } } i f ( IP_equal( src, ipO ) I I IP_equal( src, i p l ) I I IP_equal( src, ip2 ) ) optim = false; else optim = route_optim; i f ( send_via_FA( pkptr, MH_bind_ptr, mobile_table, i c i_ptr , dest, agnt_flag ) == OPC_COMPCODE_SUCCESS ) FRET ( MOBILE_RTE_SUCCESS ) else i f ( forward_to_visitor( mobile_table, FA_bind_ptr, pkptr, i c i_pt r , dest ) == OPC_COMPCODE_SUCCESS ) FRET ( MOBILE_RTE_SUCCESS ) else i f ( encap_packet( HA_bind_ptr, CA_bind_ptr, pkptr, i c i_pt r , ipO, dest, pk_id, t t l , optim, objid ) == OPC_COMPCODE_SUCCESS ) • • FRET ( MOBILE_RTE_ENCAP ) else FRET ( MOBILE_RTE_TO_IP ) } • Compcode send_via_FA( pkptr, bind_list_ptr , mobile_table, i c i _ i 3 t r , dest, ma_flag ) Lis t • *bind_list_ptr , *mobile_table; Ic i * i c i_ptr ; Packet *pkptr; IP dest; int ma_flag; { int i , size; int copy = false; int next_net, next'_node, stream, mtu; Packet *cp_pkptr; Appendix B. Supplementary Source Code of the IMHP Model Compcode status= OPC_COMPC0DE_SUCCESS; MH_FA_j3inding *fa_entry; raobile_rte_table*table_entry; char str0[80], strl [80] ; FIN( send_via_FA(. pkptr, bind_list_ptr , mobile_table, i c i_ptr , dest, ma_flag ) ) / * F i rs t of a l l , check i f packet is for any enabled streams */ size = op_prg_list_size( mobile_table ) ,-for ( i=0; icareof, dest ) && table_entry->condition == CONDITION_ENABLED ) { stream = table_entry->stream; mtu = table_entry->mtu,-next_net = ADDRESS_UNDEFINED; next_node = ADDRESS_UNDEFINED; deliver_packet( pkptr, i c i_ptr , next_net, next_node, stream, mtu ); FRET( OPC_COMPCODE_SUCCESS ) / * Now, check to see i f there is any mobility binding */ size = op_prg__list_size ( bind__list_ptr ),-/ * i f ( size == 0 && ma_flag )/* no bindings and not a mobile node */ i f ( size == 0 )/* no bindings and not a mobile node */ FRET( OPC_COMPCODE_FAILURE ) / * each enabled FA w i l l receive a copy of the packet * / for.( i = 0; istream; . ' • i f ( chk_strm_condition( mobile_table, stream, &mtu ) == CONDITION_ENABLED { status = OPC_COMPCODE_SUCCESS; i f ( mtu ' = = MOBILE_STRM_NONEXISTENT ) { sprintf (strO, \"Discarding packet (%d) \", op_pk_id (pkptr)) sprintf (s tr l , \"Stream non-existent\" ); op_prg_odb_print_major (strO, s t r l , OPC_NIL); encap_pk_destroy ( pkptr ) ,-} else * i f 0 next_net = fa_entry->careof.net; next_node = fa_entry->careof .node,-deliver_packet( pkptr, i c i_ptr , next_net, next_node, stream, mtu ); Appendix B. Supplementary Source Code of the IMHP Model 109 FRET( OPC_COMPCODE_SUCCESS .) #else . • copy = true; cp_pkptr = op_pk_copy ( pkptr ),-deliver_packet( cp_pkptr, i c i_ptr , next_net, next_node, stream, mtu ttendif / * have to deallocate original packet since i t is no longer needed */ i f ( copy ) { ' encap_pk_destroy ( pkptr ); ' • •• FRET( status ) } FRET( OPC_COMPCODE_FAILURE ) } Compcode encap__packet ( HA_bind_ptr, CA_bind_ptr, pkptr, i c i_ptr , current, dest, pk_id, t t l , route_optim, feg_objid ) Lis t *HA_bind_ptr; Lis t *CA_bind_ptr ,-Packet . *pkptr; Ic i * i c i_ptr ; IP current, dest; int *pk_id; int t t l ; int route_optim; Obj id reg_objid; { ' • char str0[512], strl[512],• Packet ' *encap_pkptr ,-int i , j , num_bind, num_multi_bind; int next_net, next_node, outstrm, mtu; IP • or ig ; int data_len; int copy = false; HA_mobility_binding*home_entry; CA_mobility_binding*ca_entry ,-multi_binding *multi_bind_entry; Compcode status = OPC_COMPCODE_FAILURE; FIN( encap_packet ( HA_bind_j3tr, . . . ) ) num_bind = op_prg_list_size ( HA_bind_|3tr ) ; for (i=0; ihome_addr, sizeof(IP))) status = OPC_COMPCODE_SUCCESS; num_multi_bind = op_prg_list_size( home_entry->multi_bind_list ); fort j=0; jmulti_bind_list,' j ),-i f { Appendix B. Supplementary Source Code of the IMHP Model data_len = op_pk_total_size_get(pkptr)/8; encap_pkptr = op_pk_create_fmt( \"ip_dgram\" ); op_pk_bulk_size_set( encap_pkptr, data„len*8 ); copy = true; op_pk_nfd_set( op_pk_nfd_set( op_pk_nfd_set( op_pk_n fd_set( op_pk_nfd_set( op_pk_nfd_set( encap_pkptr, \"data\" , op_pk_copy(pkptr) ) ,-encap_pkptr, \"protocol encap_pkptr, \"src_net\", current.net ); encap_pkptr, \"src_node\", current.node ); encap_pkptr, \"dest_net\", multi_bind_entry->careof.net encap_pkptr, \"dest_node\", multi_bind_entry->careof.node PROTOCOL_ENCAP op_pk_nfd_set( encap_pkptr,\"orig_len\",data_len) op_pk_nfd_set( encap_pkptr,\"Erag_len\",data_len) op_pk_nfd_set( encap_pkptr,\"ident\", (*pk_id)++) op_pk_nfd_set( encap_pkptr,\"frag\", 0 ); op_pk_nfd_set( encap_pkptr, \" t t l \" , t t l ) ; i f (op_prg_odb_ltrace_active (\"encap_pk\")) { sprintf (strO, \"Encapsulating pk(%d) sent\" , op_pk_id (encap_pkptr) ) ,-sprintf (s t r l , \"Destination: net (%d), node (%d) , multi_bind_entry->careof.net , multi_bind_entry->careof.node ) op_prg_odb_print_major . ( strO, s t r l , OPC_NIL) ,-}. encap_pk_send( encap_pkptr ) ; / * At this stage, i t is assumed that HA binding exists -* for mobile node. Therefore send binding warning * message to original sender */ . i f ( route_optirn == true ) { °P_pk_nfd_get (' pkptr, \"src_net\", '&orig.net ) ,-op_pk_nfd_get ( pkptr, \"src_node\", &orig.node ),-generate_bind_warning( orig, reg_objid , home_entry->home_addr, current ); i f ( status == OPC_COMPCODE_SUCCESS ) { i f ( copy ) encap_pk_destroy( pkptr ); FRET( status ) } ttif 0 i f ( route_optim == false ) FRET( OPC_C0MPC0DE_FAILURE #endif num_bind = op_prg_list_size( CA_bind_ptr ); Appendix B. Supplementary Source Code of the IMHP Model 111 for( i=0; ihome_addr ) )' { status = OPC_C'OMPCODE_SUCCESS; data„len = op_pk_total_size_get( pkptr )/8; encap_pkptr = op_pk_create_fmt( \"ip_dgram\" ); op_pk_bulk_size_set ( encap_pkptrdata_len*8 ) ,-op_pk_nfd_set( encap_pkptr, \"data\", pkptr ); op_pk_nfd_set( encap_pkptr, \"protocol\" , PROTOCOL_ENCAP ) ; op_pk_nfd_set( encap_pkptr, \"src_net\", current.net ); op_pk_nfd_set( encap_pkptr, \"src_node\", current.node op_pk_nfd_set ( encap_pkptr, \"dest_net\" , ca_entry->careof .net ),-op_pk„nfd_set( encap_pkptr, \"dest_node\" , , ca_entry->careof .node ) .,-op_pk_nfd_set ( encap_pkptr, \"orig_len\", data_len ),-op_pk_nfd_set( encap_pkptr, \"frag_len\", ' data_len ); op_pk_nfd_set( encap_pkptr, \"ident\", (*pk_id)++ ); op_pkjifd_set( encap_pkptr, \"frag\", 0 ) ; -op_pk__nf d_set ( encap_pkptr, \" t t l \" / t t l ) ,-/ * Now schedule packet for. transmission- * / encap_pk_send( encap_pkptr ); FRET( OPC_COMPCODE_SUCCESS ) i f ( copy ) encapj>k_destroy( pkptr ) ; FRETt status ) void . ' deliver_packet( pkptr, i c i_pt r , next_net, next_node, outstrm, mtu ) Packet ' *pkptr; Ici * i c i _ p t r ; int . .'next_net, nextjiode, outstrm, mtu; { . • char str0[512], strl[512],-int ' i , len; ' '• int header_size, frag_size, data_size; int dest_net, dest_node; . int t t l ; int frag_accum, frag, num_frags; Packet *ip__pkptr, *data_pkptr, *frag_ptr; FIN( deliver_packet( pkptr, . . . ) ) . • / * obtain packet's destination */ op_pk_nf d_get ( pkptr, \"dest__net\", &dest_net ) ; ' -op_pk_nfd_get( pkptr, \"dest_node\", &dest_node ); / * Decrement the packet's t ime-to-live f i e l d . If zero is reached, * / / * discard the packet rather than send i t on. * / op_pk„nfd_get (pkptr, \" t t l \" , &t t l ) ; Appendix B. Supplementary Source Code of the IMHP Model 112 t t l - - ; i f ( t t l == 0). . • { / * In debug mode, indicate that a packet is destroyed */ / * due to an expired t t l . */ i f (op_prg_odb_ltrace_active (\"ip_errs\")) . { sprintf (strO, \"Discarding packet (%d) with expired TTL\", opj>k_id (pkp-tr ) ) ; sprintf (s t r l , \"Destination: net (%d), node (%d)\", dest_net, dest_node); op_prg_odb_print_major (strO, s t r l , ,OPC_NIL) ; } -op_pk_destroy (pkptr) ,-} else{ / * Assign the new decremented value of t t l . */ op_pk_nfd_set (pkptr, \" t t l \" , t t l ) ; / * In debug mode, trace the routing action. * / i f (op_prg_odb_ltrace_active (\"mobile-ip_rte\")) ( sprintf (strO, \"Routing towards (%d, %d)\", dest_net, dest_node); sprintf (s t r l , \"Next hop (%d, %d), output stream (%d)\", next_net, next_node, outstrm); op_prg_odb_print_major (strO, s t r l , OPC_NIL); } . / * Install an Ici indicating to the lower layer what the */ / * address of the next (intermediate) node i s . * / op_ici_attr_set ( ici_ptr , \"next_node\", next_node) ,-o p _ i c i _ i n s t a l l ( ic i_ptr ) ; / * Obtain the'size in bytes of the fragment. * / frag_size = op_pk_total_size_get (pkptr) / 8 ,-/ * Obtain the number of bytes of data carried in this fragment * / op_pk_nfd_get (pkptr, \"frag_len\", &data_size) ,-/ * Also obtain the difference between the packet size */ / * and the length f i e l d : this is the size of the header. */ header_size = frag_size - data_size,-/ * If i t is smaller than the maximum transfer unit; send i t as i s . */. i f (frag_size <= mtu) { op_pk_send (pkptr, outstrm); . } ' ' else{ • • / * Otherwise, break i t into fragments * / / * Each fragment can contain up to (mtu - header_size) bytes of data */ num_frags = (data_size + mtu - header_size - 1) / (mtu - header_size); / * In debug mode, indicate the fragmentation. */ i f (op_prg_odb_ltrace_active (\"ip_frag\")) { sprintf (strO, \"Breaking datagram into (%d) fragments\", num_frags); op_prg_odb_print_major (strO, OPC_NIL) ; } / * If the fragment is carrying the original datagram given to IP, .*/ / * extract i t before copies are made. Only .one fragment can carry */ / * the original packet for the reassembly model to work properly. * / i f (op_pk_nfd_is_set (pkptr, \"ip_dgram\")) op_pk_nfd_get (pkptr, \"ip_dgram\", &ip_pkptr); Appendix B. Supplementary Source Code of the IMHP Model 113 else ip_pkptr = 0PC_NIL; / * If the packet is carrying any encapsulated data (normally this */ / * would happen only for a packet fragmented for the f i r s t time), */ / * extract this data packet so that i t w i l l not appear in each */\" / * fragment generated by copying. * / i f (op_pk_nfd_is_set (pkptr, \"data\")) op_pk_nfd_get (pkptr, \"data\", &data_pkptr); else data_pkptr = OPC_NIL; / * Loop through and create the fragments . * / for (f rag_accum =0, i = 0,- i < num_frags; i + +) { : /.* Make a copy of the original packet. */ frag_ptr = op_pk_copy (pkptr); / * Indicate that the copy is a fragment */ op __pk_nfd_set (frag_ptr, \"frag\", 1); from the */ avoid */ now be */ / * for a l l but the last fragment, the size is the mtu. */ / * and the encapsulated ip packet is not included. * / i f (i < num_frags - 1) { op_pk_nfd_set '(frag_ptr, \"frag_len\", mtu - header_size); op_pk_total_size_set (frag_ptr, 8 * mtu); frag_accum += (mtu - header_size); } . • ' else{ len = data_size - frag_accum; op_pk_nfd_set (frag_ptr, \"frag_len\", len) ,-op_pk_total_size_set (frag_ptr,8 * (header_size + len)) ; / * If the original packet was not a fragment, encapsulate i t / * into the last fragment created here. */ op_pk_nfd_get (pkptr, \"frag\", &frag); i f (Ifrag) { / * If the packet contained encapsulated data ( i . e . , / * transport), that data w i l l have been removed to / * i ts duplication in the fragments. The data should / * reinserted into the original packet. * / i f (da'ta_pkptr !=OPC_NIL) •op_pk_nfd_set (pkptr, \"data\", data_pkptr); / * In either case the original packet is */ / * encapsulated in thhe fragment. * / .op_pk_nfd_set (frag_ptr, \"ip_dgram\", pkptr); gram */ fragment */ / * Otherwise the packet can-be discarded. * / else{ op_pk_destroy (pkptr); / * Also, i f the packet included the original datagram / * from which i t was generated, transfer that data-/ * into the last fragment created here. */ / * Note that i t is possible, in the case where a Appendix B. Supplementary Source Code of the IMHP Model 114 ated */ ip_pkptr) / * is i t s e l f being fragmented, that none of the cre-/ * fragments w i l l contain the original datagram. */ i f (ip_pkptr != OPC_NIL) { op_pk_nfd_set (frag_ptr, \"ip_dgram\", / * Forward the datagram fragment. * / op_pk_send (frag_ptr, outstrm); FOUT; } Compcode forward_to_visitor ( rnobile_table, bind_list_ptr , pkptr, i c i_pt r , dest ) List *bind_list_ptr , *mobile_table,-Packet *pkptr; Ic i * i c i_ptr ; IP dest; { char • str0[80], strl[80] ; Compcode status = OPC_COMPCODE_FAILURE; int i , s ize; int. next_net, next_node, stream, mtu; FA_mobility_binding*visitor_entry,-FIN( forward_to_visitor( mobile_table, bind_list_ptr , pkptr, i c i_pt r , dest ) ) size = op_prg_list_size( bind_list_ptr ); i f ( size == 0 )/* l i s t does not exist * / FRET ( OPC_COMPCODE_FAILURE ) ' ' for( i=0; ihome_addr, sizeof(IP) ) ) { / * There is a match */ i f ( visitor_entry->home_agnt.net != ADDRESS_UNDEFINED && visitor_entry->home_agnt.node != ADDRESS_UNDEFINED ) • { .. status = OPC_COMPCODE_SUCCESS; next__net = visitor__entry->home_addr .net ; next„node = visitor_entry->home_addr.node; stream = visitor_entry->stream; mtu = get_strm_mtu( mobile_table, stream ); i f ( mtu == MOBILE_STRM_NONEXISTENT ) • { • . ; sprintf (strO, \"Discarding packet (%d) \", op_pk_id (pkptr)); sprintf (s t r l , \"Stream non-existent\" ) ,-' op_prg_odb_print_major (strO, s t r l , OPC_NIL); °P_pk_destroy( pkptr ); } Appendix B. Supplementary Source Code of the IMHP Model 115 else • • { deliver_packet( pkptr, l c i_ptr , next_net, next_node, stream,' mtu ) ; } } } } FRET( status ); } int get_strm_mtu( strm_ptr, strm ) List*-strm_ptr ; int strm-; { int i , s ize; mobile_rte_table*strm_entry• FIN( get_strm_mtu( strm_ptr, strm ) ) size = op_prg_list_size('strm_ptr ); fort i=0; istream == strm ) FRETt strm_entry->mtu ); } ' • FRETt MOBILE_STRM_NONEXISTENT ); } int chk_strm_condi.tion( mobile_table, stream, mtu ) Lis t *mobile_table; int stream,-int *mtu; { int i , s ize; mobilelrte_table*table_entry ,-FIN( chk_strm_condition( mobile_table, stream, mtu ) ) size = op_prg_list_size( mobile_table ); fort i=0; istream == stream ) { *mtu = table_entry->mtu; FRET( table_entry->condition ) } } / * stream does not exist */ *mtu = MOBILE_STRM_NONEXISTENT; Appendix B. Supplementary Source Code of the IMHP Model 116 FRET( CONDITIONJDISABLED ) } void get_careof_addr( mobile_table, i c i p t r ) L is t *mobile_table,-Ic i *iciptr,-{ int i , s ize; int stream; IP careof; mobile_rte_table*table_entry; FIN( get_careof_addr( mobile_table, i c i p t r ) ) op_ici_attr_get ( i c i p t r , \"stream\", &stream ) ,-size = op_prg_list_size{ mobile_table ),-for( i=0; icondition = CONDITIOISLDISABLED;\" status = OPC_COMPCODE_SUCCESS; break; ' case DISABLE__ALL_EXCEPT_THIS : i f ( list_ptr->stream != stream ) ' . • . \" { . - ' . \" ' • . list_ptr->condition = CONDITION_DISABLED; status = OPC_COMPCODE_SUCCESS; } ' . . . break; case DISABLE_THIS_ONLY: ' • i f ( list_ptr->stream == stream ) { op^ici_attr_set( i c i p t r , \"careof_net\", list_ptr->careof.net ); op_ici_attr_set ( i c i p t r , • \"careof j o d e \" , list_ptr->careof .node ) ,-. list_ptr->condition = CONDITION_DISABLED; status = OPC_COMPCODE_SUCCESS; } ' ' • . break; case ENABLE_ALL: ' list_ptr->condition = CONDITION_ENABLED; -status = OPC_COMPCODE_SUCCESS; break; • • case ENABLE_ALL_EXCEPT_THIS:, ' , . i f f list_ptr->stream != stream ) ' . ' { l i s t _ptr->condition = CONDITTON_ENABLED; status = OPC_COMPCODE_SUCCESS; break; case ENABLE_THIS_ONLY: . ' i f ( list_ptr->stream _== stream ) { _ op_ici_attr_set( i c i p t r , \"careofjiet\" , llst_ptr->careof.net ); op_ici_attr_set ( i c i p t r , \"careof_node\", list_ptr->careof .node-•) ; list_ptr->coridition = CONDITION_ENABLED; status = OPC_COMPCODE_SUCCESS; } break; ' [ • default: status = OPC„COMPCODE„FAILURE; break; ' ' • • ' } } . ,. op_ici_attr_set( i c i p t r , \"status\", status ); FOUT >' ' ' ' ' ' • void •' hop_to_next_strm( mobile„table, i c i p t r ) Lis t ' *mobile_table;' Ic i * i c i p t r ; t • ' ' ' int j , i , s ize; ' int • stream; mobile_r.te_table*table_entry; : • FIN( hop_to_n'ext_strm( mobile_table, iciptr . ) ) . . . •' Appendix B. Supplementary Source Code of the IMHP Model op_ici_attr_get( i c i p t r , \"stream\", &stream ) ; size = op_prg_list_size( mobile_table ),-for ( i=0; istream == stream ) { i f ( ( j = i + 1 ) == size ) j = 0; table_entry = ( mobile_rte_table *•) op_prg_list_access ( mobile_table, j ) ,-op_ici_attr_set( i c i p t r , \"stream\" , table_entry->stream ) ; . •op_ici_attr_set( i c i p t r , \"careof_net\" ,table_entry->careof.net); o p „ i c i _ a t t r _ s e t ( i c i p t r , \"careof_node\" ,table_entry->careof.node); / * Now, enabling this stream */ table_entry->condition = CONDITION_ENABLED; op_ici_attr_set( i c i p t r , \"status\" , OPG_COMPCODE_SUCCESS ); FOUT } } . op_ici_attr_set( i c i p t r , \"status\", OPC_COMPCODE_FAILURE ); FOUT } void process_binding_warning( pkptr, i c i p t r , rcy_iciptr , ip_objid ) Packet • *pkptr; Ici *icip.tr; Ici *rcv_iciptr ; Objid ip_objid; { IP home_addr, rem, target, home_agnt; int rem_port; Packet *bind_pkptr; Compcode status; Ic i *bind_iciptr ; FIN( process_binding_warning( pkptr, i c i p t r , rcy_iciptr , ip_objid op_pk_nfd_get( pkptr, •\"home_addr_net\", &home_addr.net ); op_pk_nfd_get( pkptr, \"home_addr_node\", &home_addr.node );. op_pk_nf d_get ( pkptr, \" target_net\" , &target.net ),-op_pk_nf d_get ( pkptr, \" target_node\" , itarget.node ) ,-op_ici_attr_get ( rcv_iciptr , \"rern_net\", 6rem.net ); op_ici_attr_get( rcv_iciptr , \"rem_node\", &rem.node ); op_ici_attr_get ( rcv_iciptr , \"rern_port\", &rem_port ); / * creating binding for Mobile-ip query */ Appendix B. Supplementary Source Code of the IMHP Model 119 bind_iciptr = op_ici_create( \"binding_command\" ); op_ici_attr_set ( bind_iciptr , \"command\", READ_HA_BINDING ) ,-op_ici_attr_set( bind_iciptr , \"home_net\", home_addr.net ); op_ici_attr_set( bind_iciptr , \"home_node\", home_addr.node ); •op_ici_install( bind_iciptr ); op_intrpt_Eorce_remote( BINDING_MAINTENANCE, ip_objid ); op_ic i_instal l ( OPC_NIL ); op_ici_attr_get( bind_iciptr , \"status\", &status ) ,-i f . ( status == OPC_COMPCODE_SUCCESS ) { . / * send binding warning i f home addr is a registered MH */ bind_pkptr = op_pk_create_fmt( \"bind_warn\" ); op_pk_nfd_set ( bind_pkptr, \"home_addr_net\", home_addr.net ) ,-op_pk_nfd_set( bind_pkptr, \"home_addr_node\", home_addr.node ); op_pk_nf d_set ( bind_pkptr, \" target_net\" , .target.net ) ; op_pk_nfd_set( bind_pkptr, \" target„node\" , target.node ); udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , REG_REQUEST_PORT, target.net, target.node ) ,-} else { ' i i f 1 • _ / * f i r s t of a l l , check whether home addr is on cache l i s t * / op_ici_attr_set ( bind_iciptr , \"command\", READ„CA_BINDING ) ,-op_ici_instal l ( bind_iciptr ); op_intrpt_force_remote ( BINDING_MAINTENANCE, ip_obj id ) ,-op_ici_instal l ( OPC_NIL ); op_ici_attr_get ( bind_iciptr , \"status\", &status ) ,-i f ( status == OPC_COMPCODE_SUCCESS ) { / * Home addr on cache l i s t , send binding request to home addr */ op_ici_attr_get ( bind_iciptr , \"home_agnt_net\", &rem.net ) ,-op_ici_attr_get( bind_iciptr , \"home_agnt_node\", &rem.node ); bind_pkptr = op_pk_create_fmt ( \"bind_req\" ) ,-op_pk_nfd_set( bind_pkptr, \"home_addr_net\", home_addr.net ); op_pk_nfd_set( bind_pkptr, \"home_addr_node\", home_addr.node ); / * send the registration packet * / udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , REG_REQUEST_PORT, rem.net, rem.node ); } else { / * no binding found, send i t to target * / bind_pkptr = op_pk_create_fmt ( \"bind_req\" ) ,-op_pk_nf d_set ( bind__[3kptr, \"home_addr_net\" , home_addr.net ) ,-°P_pk_nfd_set( bind_pkptr, \"home_addr_node\", home_addr.node ); / * send the registration packet */ udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , REG_REQUEST_PORT, target.net, target.node ); } ttelse bind_pkptr = op_pk_create_fmt( \"bind_req\" ); op_pk_nfd_set ( bind_pkptr, \"home_addr_net\" , home_addr.net ) ,-op_pk_nfd_set ( bind_pkptr, \"home_addr_node\", home_addr .node ) ,-Appendix B. Supplementary Source Code of the IMHP Model #endif / * send the registration packet */ udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , rem_port, rem.net, rem.node ); / * deallocate resources after usage */ op_ici_destroy ( bind_iciptr .) ,-FOUT -void process_binding_request( pkptr, i c i p t r , rcv_iciptr , objid ) Packet1- *pkptr; Ic i • * i c i p t r ; Ic i *rcv_iciptr ; Objid objid; { Packet *bind_pkptr; IP home_addr,-IP careof; IP rem; int rem_port; Ic i * i p _ i c i p t r ; int status,-int l i fet ime; FIN( process_binding_request( pkptr, i c i p t r , rcv_iciptr , objid ) ) op_pk_nfd_get( pkptr, \"home_addr_net\", &home_addr.net ); op_pk_nfd_get ( pkptr, \"home_addr_node\" , &home_addr.node ) ,-op_ici_attr_get (• rcv_iciptr , \"rem_net\", trem.net ) ,-op_ici_attr_get ( rcv_ic iptr , \"rem_node\", Srem.node ) ,-op_ici_attr_get ( rcv_iciptr , \"rem_port\", &rem_port ) ,-i p _ i c i p t r = op_ici_create ( \"binding_command\" ),-op_ici_attr_set( i p _ i c i p t r , \"command\", READ_HA_BINDING ); op_ici_attr_set ( i p _ i c i p t r , \"home_net\", home_addr.net ) ,-op_ici_attr_set ( i p _ i c i p t r , \"home_node\", home_addr. node ),-op_ici_instal l ( i p _ i c i p t r ); op_intrpt_force_remote( BINDING_MAINTENANCE, objid ); op_ic i_instal l ( OPC_NIL ); op_ici_attr_get ( i p _ i c i p t r , \"status\", istatus ) ,-i f ( status == OPC_COMPCODE_FAILURE ) { careof = home_addr;/* no binding exists */ lifetime = 0 ,-} else { op_ici_attr_get( ip_ ic ip t r , \"careof_net\", &careof.net ) op_ici_attr_get ( ip_icii3tr, \"careof_node\", &careof.node op_ici_attr_get ( ip_ ic ip t r , \" l i fet ime\" , &lifetime ) ,-} • ' / * deallocate i c i pointer after use */ op_ici_destroy( ip_ic ipt r ); bind_pkptr = op_pk_create_f mt ( \"bind_update\" ),-op_pk_nfd_set( bind_pkptr, \"home_addr_net\", home_addr.net ); Appendix B. Supplementary Source Code of the IMHP Model 121 op_pk_nfd_set( bind_pkptr, \"home_addr_node\", home_addr.node ); ' op_pk_nfd_set( bind_pkptr, \"careof_net\", careof.net ); op_pk_nfd_set( bind_pkptr, \"careof_node\", careof.node ); op_pk_nfd_set( bind_pkptr, \" l i fet ime\" , lifetime ); / * send binding request via UDP port * / udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT, rem_port, rem.net, rem.node ), FOUT } void process_binding_update-( pkptr, i c i p t r , rcv_iciptr , objid ) Packet • *pkptr; Ic i * i c i p t r ; Ici *rcv_iciptr,- . . Objid objid; { Packet *bind_pkptr; IP home_addr; IP careof; IP rem; int rem_port; Ic i * i p _ i c i p t r ; int lifetime, ack, status; FIN( process_binding_update( pkptr, i c i p t r , rcv_iciptr , objid.) ) op_pk_nfd_get( pkptr, \"home_addr_net\", &home_addr.net ),-op_pk_nfd_get(. pkptr, \"home_addr_node\", &home_addr.node ); op_pk_nfd_get( pkptr, \"careof_net\", Scareof.net ); op_pk_nfd_get( pkptr, \"careof_node\", &careof.node ); op_pk_nfd_get( pkptr, \" l i fet ime\" , ^lifetime ) ,-op_pk_nf d_get ( pkptr, \"ack\", Sack ') ; op_ici_attr_get( rcv_iciptr , \"rem_net\", trem.net ); op_ici_attr_get( rcv_iciptr , \"rem_node\", Srem.node ); op_ici_attr_get ( rcv_iciptr , \"rem_port\", &rem_port ) ,-i p _ i c i p t r = op_ici_create( \"binding_command\" ); i f ( (careof.net == 0 && careof.node ==0) I I lifetime == 0 ) { op_ici_attr_set ( ip_ ic ip t r , \"command\", KILL_CA_BINDING ),-op_ici_attr_set ( i p _ i c i p t r , \"home_net\", home_addr.net ),-op_ici_attr_set ( ip_ ic ip t r , \"home_node\", home_addr .node ),-op_ici_instal l ( i p _ i c i p t r ); op_intrpt_force_remote( BINDING_MAINTENANCE, objid ); else { \"command\", EDIT_CA_BINDING ); \"home_net\", home_addr.net ) ,-\"home_node\", home_addr.node ) ; \"home_agnt_net\", rem.net ); \"home_agnt_node\", rem.node ); \"careof_net\", careof.net ),-\"careof_node\" , careof.node ),-\" l ifet ime\" , lifetime ); op_ici_instal l ( i p _ i c i p t r ); op_intrpt_force_remote( BINDING_MAINTENANCE, objid op_ici_instal l ( OPC_NIL ); op_ . i c i . . i n s t a l l ( OPC_ _NIL ) ; op_ .ici_ _attr_ .set ( ip. . i c i p t r op_ .ici_ _attr_ .set ( ip. . i c i p t r op_ .ici_ _attr_ .set ( ip_ . i c i p t r op_ _ici_ _attr_ .set ( ip_ . i c i p t r op_ .ici_ _attr_ .set ( ip_ . i c i p t r op_ . i c i . _attr_ .set ( ip_ . i c i p t r °P_ . i c i . _attr_ .set ( ip_ . i c i p t r op_ . i c i . _attr_ .set ( ip. . i c i p t r Appendix B. Supplementary Source Code of the IMHP Model 122 i f ( ack == true ) { bind_pkptr = op_pk_create_fmt( \"bind_ack\" ) ; op_pk_nfd_set( bind_pkptr, \"home_addr_net\", home_addr.net ); op_pk_nfd_set ( bind_pkptr, \"home_addr_node\" , home_addr .node ) ,-/ * send binding request via UDP port * / udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , rem_port, rem.net, rem.node ) ,-.} ' ' } ' . / * deallocate i c i pointer after use * / op_ici_destroy( i p _ i c i p t r ); FOUT } . void encap_pk_destroy( pkptr ) Packet *pkptr; { : Packet *outer_pkptr, *inner_pkptr; int i , num_fds, data_present; char fd_name[40]; FIN( encap_pk_destroy( pkptr ) ) . • outer_pkptr = pkptr; while ( 1 ) { num_fds = op_pk_f d_max_index (• outer_pkptr ); for ( data_present=false,i=0; i< num_fds; ++i ) { op_pk_fd_index_to_name( outer_pkptr, i , fd_name ); i f ( strcmpl fd_name, \"data\" ) == 0 ) { op_pk_nfd_get( outer_pkptr, \"data\", &inner_pkptr ); op_pk_destroy( outer_pkptr ); data_present = true; break; } } • . / * no. f ields with name \"data\" * / i f ( data_present == false ) break; outer_pkptr = inner_pkptr; } op_pk_destroy ( outer_[Dkptr ) ; FOUT } ' void generate_bind_warning( dest, reg_objid, home_addr, target ) IP dest, home_addr, target,-Objid reg_objid; { Appendix B. Supplementary Source Code of the IMHP Model Ici *warn_iciptr; FIN( generate_bind_warning( home_addr, ) ) warn_iciptr = op_ici_create(\"bind_warn_ici\") ; op_ici_attr_set( warn_iciptr, \"home_addr_net\", home_addr.net ) op_ici_attr_set( warn_iciptr, \"home_addr_node\", home_addr.node op_ici_attr_set( warn_iciptr, \"dest_net\", dest.net ); op_ici_attr_set ( warn_iciptr, \"dest_node\" , dest .node ) ,-op_ici_attr_set( warn_iciptr, \"target_net\", target.net ) ,-op_ici_attr_set( warn_iciptr, \"target_node\",target.node ); op_ici_instal l ( warn_iciptr ); op_intrpt_force_remote( BINDING_WARN_TYPE, reg_objid ); op_ici_instal l ( OPC_NIL ); op_ici_destroy( warn_iciptr ); FOUT } void encap_pk_send( pkptr ) Packet .*pkptr; { FIN( encap_pk_send( pkptr ) ) / * insert encapsulated packet at the beginning of the queue */ op_subq_pk_insert( 0, pkptr, OPC_QPOS_HEAD ); FOUT } void check_ca_list( l i s t_pt r , dest, home_agnt ) List * l i s t _ p t r ; IP dest; IP * home_agn t; { CA_mobility_binding*ca_entry ,-•int i , num_bind; FIN( check_ca_list( l i s t _ p t r , dest, home_agnt ) ) num_bind = op_prg_list_size( l i s t _ p t r ); for( i=0; ihome_addr ) ) { home_agnt->net = ca_entry->home_agnt.net; home_agnt->node = ca_entry->home_agnt .node ,-FOUT } } home_agnt->net = ADDRESS_UNDEFINED; home_agnt->node = ADDRESS_UNDEFINED; FOUT } Appendix C. Supplementary Source Code of the Handoff Enhanced Model / * mobile_rte_sup.ex,c */ / * Routing support procedures for the Mobile IP example model */ •include •include \"mobile-ip.h\" •include \"mobile_rte^sup.h\" •include \"ip_rte_sup.h\" •include \"protocol.h\" / * Functions called by Process Module */ Lis t* mobile_rte_sup_table_setup (file_name) char *file_name; { • • Lis t* mobile_strrn_list_ptr ; Lis t* l i n e _ l i s t _ p t r ; mobile_rte_table*table_ptr ,-/ * Provides comprehensive routing table loading and parsing */ / * services for Mobile IP module. */ FIN (rnobile_rte_sup_table_setup (file_name, netO, nodeO, netl , nodel, net2, node2) ) / * Load the l i s t of text lines from the specified f i l e . */ / * Note: this procedure w i l l quit the simnulation i f * / / * f i l e cannot be loaded, so i t is assumed that there */ / * are no problems upon returning. * / l ine_ l i s t_pt r = mobile_rte_sup_table_load (f ile_narne) ,-/ * Parse the contents of the obtained,list into */ / * a routing-instruction table. * / mobile_strm_list_ptr = mobile_rte_sup_list_parse ( l ine_l i s t_pt r ) ; / * In debug mode, i f tracing is active, print the table */ i f (op_prg_odb_trace_active ()) { mobile_rte_sup_table_print (mobile_strm_list_ptr) ,-} FRET( mobile_strm_list_ptr ); . } L is t* mobile_rte_sup_table_load (file_name) char *file_name; { Lis t* l i n e _ l i s t _ p t r ; char err_str [256]; / * Read in a routing table from an a s c i i */ / * f i l e adhering to format defined above.. */ FIN (mobile_rte_sup_table_load (file_name)) / * Open and read the f i l e into the l i s t . * / l ine_ l i s t_pt r = op_prg_gdf_read.(file_name); 124 Appendix C. Supplementary Source Code of the Handoff Enhanced Model 125 / * Test for error in reading. */ \" i f ( l ine_l is t_ptr == OPC_NIL) { -sprintf (err_str, \"F i le Name: %s\", file_name); op_sim_end (\"Package : mobile_rte_sup\", \"Error : Unable to read routing table f i l e \" , err_str, \"\") ; }. / * Return the l i s t of text 'lines^ */ FRET (line_list_ptr) > List* mobile_rte_sup_list_parse (l ine_list_ptr) Lis t* ' l i n e _ l i s t _ p t r ; { L is t* mobile_stream_list_ptr; mobile_rte_table*mrt_ptr,-int i , num_lines; char* l i n e ; List * f i e l d _ l i s t _ p t r ; / * Extract information from the lines of an asc i i routing table * / / * and construct a corresponding routing table structure.which */ / * contains routing instructions. * / . . FIN (mobile_rte_sup_list_parse (line_list_ptr)) / * Allocate a routing table structure. */ mrt_ptr = (mobile_rte_table*) op_prg_mem_alloc (sizeof (mobile_rte_table)); / * Allocate a temporary table for holding l i s t s . * / mobile_stream_list_ptr = op_prg_list_create (); '/* Scan through each of the lines, one at a time. * / num_lines =. op_prg_list_size ( l ine_list_ptr) ,-for (i = 0; i < num_lines; i++) { ' • • / * Obtain the i_th l i n e . * / l ine = op_prg_list_access ( l ine_lis t_ptr , i ) ; / * Decompose i t into f ields ( f ie ld boundaries are * / / * indicated by spaces, tabs, slashes, or commas. '*/ f i e l d _ l i s t _ p t r = op_prg_str_decornp (line, \" , A t \" ) ; / * Format for a l ine is as follows: * / / * */ / * Incomplete lines are skipped. * / i f (op_prg_list_size ( f i e l d „ l i s t _ p t r ) < 4) continue; / * Create a routing instruction structure. */ mrt_ptr = (mobile_rte_table*) cp_prg_mem_alloc (sizeof (mobile_rte_table) ). ,-/ * Transfer the parsed fields into the structure * / / * F i rs t obtain the destination stream and mtu f i e l d s . */ mrt_ptr->stream = atoi ( op_prg_list_access ( f i e ld_ l i s t_pt r , MOBILE_TBL_OUTSTREAM) ) ,-mrt_ptr->mtu = atoi ( op_prg_list_access ( f ie ld_l is t_ptr , MOBILE_TBL_MTU)); Appendix C. Supplementary Source Code of the Handoff Enhanced Model mrt_ptr->careof.net = atoi ( op_prg_list_access ( f ie ld_l is t_ptr , MOBILE_TBL_CAREOF_NET)); ' mrt_ptr->careof .node'= atoi ( op_prg_list_access ( f i e ld_ l i s t_pt r , MOBILE_TBL_CAREOF_NODE) ) ,-if^(mrt_ptr->mtu <= 0) mrt_ptr->mtu = 0x7FFFFFFF; i f (mrt_ptr->careof.net == ADDRESS_UNDEFINED && mrt_ptr->careof.node == ADDRESS_UNDEFINED ) { / * oareof address not implemented */ mrt_ptr->condition = CONDITION_ENABLED; } else { /•* disable a l l condition flags i n i t i a l l y */ mrt_ptr->condition = CONDITION_DISABLED; } / * Append the routing instruction to the temporary l i s t . */ op_prg_list_insert (rnobile_stream_list_ptr, mrt_ptr, OPC_LISTPOS_TAIL) . } FRET( mobile_strearn_list_ptr ) } void mobile_rte_sup_table_print (mobile_stream_list_ptr) Lis t *mobile_stream_list_ptr-; { mobile_rte_table*table_entry; int i , s i z e ; char dne_str [128], dno_str [128]; char nne_str [128], nno_str [128], strO [512]; / * Print the contents of a routing table. * / FIN (mobile_rte_sup_table_print (mobile_stream_list_ptr)) size = op_prg_list_size ( rnobile_stream_li-st_ptr ) ; i f ( size == 0 ) { - . op_prg_odb_print_major (\"Routing table is empty\", VOS_NIL) ,-} else{ op_prg_odb_print_major (\"Routing table contents : \" , VOS_NIL); for (i = 0; i < size; i++) { table_entry = (mobile_rte_table*) op_prg_list_access( mobile_stream_list_ptr, i ) sprintf ! strO, \"Stream (%d): mtu (%d)\" , table_entry->stream, table_entry->mtu ); op_prg_odb_print_minor (strO, VOS_NIL); } } FOUT } Compcode Appendix C. Supplementary Source Code of the Handoff Enhanced Model 127 mobile_rte_sup_route_select ( mobile_table, pkptr, i c i_pt r , objid agnt_flag, pk_id, t t l HA_bind_ptr, FA_bind_ptr CA_bind_ptr, MH_bind_ptr ipO, i p l , ip2, •route_optim, trash_unsent_pk buffer_ptr, buffer_ l i fe ) *mobilettable,• *pkptr; * ici_ptr,-obj i d ; agnt_flag; *pk_id; t t l ; *HA_bind_ptr, *FA_bind_ptr; *CA_bind_ptr, *MH_bind_ptr; ipO, i p l , ip2 ,-route_optim,-trash_unsent_pk; *buf f er_ptr,-buffer life,-Lis t Packet Ici Objid int int int Lis t Lis t IP int int Lis t double { char Packet Packet int int int IP IP strO [100] ,-* inner_pkptr; *buffer_pkptr; optim; protocol; i , . j , num_bind, src, dest; home_agnt ; num multi bind; HA_mobility_binding*home_entry; FA_mobility_binding*visitor_entry; multi_binding *multi_bind_entry; FIN (rnobile_rte_sup_route_select ( mobile_table, pkptr, . . .)) op_pk_nfd_get( pkptr, \"src_net\", &src.net ); op_pk_nfd_get( pkptr, \"src_node\", tsrc.node ); op_pk_nfd_get( pkptr, \"dest_net\", &dest.net ); 'op_pk_nfd_get( pkptr, \"dest_node\", &dest.node ); / * Select a route from the routing table which matches the */ / * requested destination network and node. */ i f ( 'IP_equal( dest, ipO ) II IP_equal( dest, i p l ) I I IP_equal( dest, ip2 ) ) ( • op_pk_nfd_get( pkptr, \"protocol\", &protocol ); / * Not encapsulated ( not for a v i s i t o r ) */ i f ( protocol != PROTOCOL_ENCAP ) FRET ( MOBILE_RTE_TO_IP ) op_pk_nfd_get( pkptr, \"data\", &inner_pkptr ); op_pk_destroy ( pkptr ) ,-pkptr = inner_pkptr; . op_pk_nfd_get( pkptr, \"dest_net\", &dest.net ) ; ' op_pk_nfd_get ( pkptr, \"dest_node\", &dest.node ),-/ * i f { ! trash_unsent_pk ) buffer_pkptr = op_pk_copy( pkptr ); * / i f ( insert_pk_buffer( buffer_ptr, buffer_life' , dest, pkptr ) == OPC_COMPCODE_SUCCESS ) { i f (op_prg_odb_ltrace_active (\"pk_buffer\")) Appendix C. Supplementary Source Code of the Handoff Enhanced Model 128 { sprintf (strO, \"Buffering pk(%d) at (%d,%d)\" , op_pk_id (pkptr), ipO.net, ipO.node); op_prg_odb_print_major (strO, OPC_NIL); } FRET(,MOBILE_RTE_SUCCESS ) else { / * op_pk_destroy ( buffer_pkptr ) ,- * / i f ( forward_to_visitor( mobile_table, FA_bind_ptr, pkptr, i c i_pt r , dest ) == OPC_COMPCODE_FAILURE )• { i f ( route_optim ) C check_ca_list( CA_bind_ptr, dest, &home_agnt ); i f ( home_agnt.net == ADDRESS_UNDEFINED && horne_agnt. node == ADDRESS_UNDEFINED ) { ' . home_agnt = src; . . . } generate_bind_warning ( home_agnt, objid, dest, src ),-} i f ( encap_packet( HA_bind„ptr, CA_bind_ptr, pkptr, i c i_pt r , ipO , dest, pk_id, t t l , optim, objid ) == OPC_COMPCODE_SUCCESS ) . { FRET( MOBILE_RTE_ENCAP ) • ' } else { i f ( trash_unsent_pk ) { i f (op_prg_odb_ltrace_active (\"pk_buffer\")) { sprintf (strO, \"Trashing pk(%d) at (%d,%d)\" , op_pk_id (pkptr), ipO.net, ipO.node); op_prg_odb_print_major (strO, OPC_NIL); } op_pk_destroy ( pkptr ) ,-} FRET( MOBILE_RTE_FAILURE ) } } else { / * packet sent to v i s i t o r */ FRET( MOBILE_RTE_SUCCESS ) > } i f ( IP_equal( src, ipO ) I I IP_equal( src, i p l ) I I IP_equal( src, ip2 ) ) optim = false; else . . . optim = route_optim; i f ( send_via_FA( pkptr, MH_bind_ptr, mobile_table, i c i_pt r , dest, agnt_flag )•== OPC_COMPCODE_SUCCESS ) FRET ( MOBILE_RTE_SUCCESS ) else i f ( forward_to_visitor( mobile_table, FA_bind_ptr, pkptr, i c i j t r , dest ) == OPC_COMPCODE_SUCCESS ) • • • Appendix,C. Supplementary Source Code of the Handoff Enhanced Model 129 FRET ( MOBILE_RTE„SUCCESS ) e l s e I f ( encap_packet ( HA_bind_ptr, CA_bind_ptr, pkptr, i c i _ p t r , ipO', dest, p k _ i d , t t l , optim, o b j i d ) == OPC_COMPCODE_SUCCESS ) ' . • ' FRET ( MOBILE_RTE_ENCAP ) .. . e l s e ' ' ' FRET ( MOBILE_RTE_TO_IP ) • • . Compcode, ' • • •send_via_FA( pkptr, b i n d _ l i s t _ p t r , mobile„table, i c i _ p t r , dest, ma_flag ) L i s t . • * b i n d _ l i s t _ p t r , *mobile_table; I c i * i c i _ p t r ; Packet *pkptr; IP dest; i n t ' ma_flag; { • ' i n t ' i , s i z e ; i n t copy = f a l s e ; i n t next_net, next_node, stream, mtu; Packet • . *cp_pkptr; Compcode status= OPC_COMPCODE_SUCCESS; MH_FA_binding * f a _ e n t r y ; m o b i 1 e _ r t e _ t a b l e * t a b l e _ e n t r y ; char . strO[80], s t r l [ 8 0 ] ; ' ' . FIN( send_via_FA( p k p t r , . b i n d _ l i s t _ p t r , mobile_table, i c i _ _ p t r , dest, ma_flag ) ) . /* F i r s t of a l l , check i f packet i s f o r any enabled streams.*/ s i z e = o p _ p r g _ l i s t _ s i z e ( m o b i l e t t a b l e ); for ( i=0; i < s i z e ; ++i ) ' { - ' t a b l e _ e n t r y = (mobile__rte__table *) o p _ p r g _ l i s t _ a c c e s s ( mobile_table, i ) \\ i f ( IP_equal( table_entry->careof, dest ) && tabl e _ e n t r y - > c o n d i t i o n == CONDITION_ENABLED ) stream = table_entry->stream; mtu = table_entry->mtu; next_net = ADDRESS_UNDEFINED; next_node = ADDRESS_UNDEFINED; ' d e l i v e f _ p a c k e t ( pkptr, i c i _ p t r , next_net, next_node, stream, mtu ); FRET( OPC_COMPCODE_SUCCESS ) /* Now, check to see i f there i s any m o b i l i t y b i n d i n g */ . s i z e = o p _ p r g _ l i s t _ s i z e ( b i n d _ l i s t _ p t r ),-/* i f ( s i z e == 0 && ma_flag )/* no bindings and not a mobile node */ i f ( s i z e ==0 )/* no bindings and not'a mobile node *•/ FRET( OPC_COMPCODE„FAILURE ) /* each enabled FA w i l l r e c e i v e a copy of' the packet *'/ f o r i i=0; i < s i z e ; ++i ) { fa_e n t r y = (MH_FA_binding *) Appendix C. Supplementary Source Code of the Handoff Enhanced Model 130 #if 0 #else ttendif op_prg_list_access( bind_list_ptr , i ); / * obtain the stream associated with the current binding */ stream = fa_entry->stream; i f ( chk_strm_condition( mobile_table, stream, &mtu ) == CONDITION_ENABLED { • status = OPC_COMPCODE_SUCCESS; i f ( mtu == MOBILE_STRM_NONEXISTENT ) { sprintf (strO, \"Discarding packet (%d) \", op_pk_id (pkptr)); sprintf (s tr l , \"Stream non-existent\" ); op_prg_odb_print_major (strO, s t r l , OPC„NIL); ''op_pk_destroy( pkptr ); } else { next_net = fa_entry->careof.net; next_node = f a_entry->careof .node ,-deliver_packet( pkptr, i c i_ptr , next_net, next_node, stream, mtu ); FRET( OPC_COMPCODE_SUCCESS ) copy = true; cp_pkptr = op_pk_copy( pkptr ); deliver_packet( cp_pkptr, i c i_p t r , next_net, next_node, stream, mtu ); / * have to deallocate original packet since i t is no longer needed */ i f ( copy ) { op_pk_destroy ( pkptr ) ,-FRET( status ) } FRET( OPC_COMPCODE_FAILURE ) } Compcode encap_packet( HA_bind_ptr, CA_bind_ptr, pkptr,. i c i_ptr , current, dest, pk_id, t t l , route_optim, reg_objid ) Lis t *HA_bind_ptr ,-Lis t • *CA_bind_ptr; Packet *pkptr; Ici * i c i _ p t r ; IP current, dest; int *pk_id; int t t l ; int route_optim; Objid reg_objid;' { char str0[512], strl[512]; Packet ' *encap_pkptr; int i , j , num_bind, num_multi_bind; int next_net, next_node, outstrm, mtu; IP orig ; int data_len; int • copy = false; Appendix C. Supplementary Source Code of the Handoff Enhanced Model HA_mobility_binding*home_entry,-CA_mobi1i ty_binding * ca_ent ry; multi_binding *multi_bind_entry,-Compcode status = OPC_COMPCODE_FAILURE; FIN( encap^packet( HA_bind_ptr, ...) ) num_bind = op_prg_list_size( HA_bind_ptr ); for (i=0; ihome_addr, sizeof(IP))) { ' Status = OPC_COMPCODE_SUCCESS; nuj__multi_bind = op_prg_list_size( home_entry->multi_bind_list for( j=0; jmulti_bind_list, data_len = op j>k_total_size_get(pkptr)/8,-encap_pkptr = op_pk_create_fmt ( \"ip_dgram\". ) ; op_pk_bulk_size_set( encap_pkptr, data_len*8 ); copy = true; op_pk_nfd_set( encap_pkptr, \"data\" , op_pk_copy(pkptr) ); op_pk_nfd_set( encap_pkptr, \"protocol\", PR0TOCOL_ENCAP ) op_pk_nfd_set( encap_pkptr, \"src_net\", current.net ); op_pk_nfd_set( encap_pkptr, \"src_node\", current.node ); op_pk_nfd_set( encap_pkptr, \"dest_net\", multi_bind_entry->careof.net ); op_pk_nfd_set( encap_pkptr, \"dest_node\", multi_bind_entry->careof.node ); op_pk_nfd_set ( encap_pkptr, \"orig_len\" , data_len) ,-op_j3k_nf d_set ( encap_pkptr, \" f rag_len\", data_len) ; op_pk_nfd_set( encap_pkptr,\"ident\", (*pk_id)++); op_pk_nfd_set ( encap_pkptr, \" frag\" , 0 ),-op_pk_nfd_set( encap_pkptr, \" t t l \" , t t l ) ; i f (op_prg_odb_ltrace_active (\"encap_pk\")) ( sprintf (strO, \"Encapsulating pk(%d) sent\" , op_pk_id (encap_pkptr) ) ,-sprintf (s t r l , \"Destination: net (%d), node (%d) , mul t i„bind_entry->careof .net , multi_bind_entry->careof.node ) op_prg_odb_print_major (strO, s t r l , OPC_NIL); } encap_pk_send( encap_pkptr ); / * At this stage, i t is assumed that HA binding exists * for mobile node. Therefore send binding warning * message to original sender * / i f ( route_optim == true ) Appendix C. Supplementary Source Code of the Handoff Enhanced Model 132 op_pk_nfd_get( pkptr, \"src_net\", &orig.net ); op„pk_nfd_get( pkptr, \"src_node\", &orig.node ) generate_bind_warning( orig, reg_objid , home_entry->home_addr, current ) ; i f ( status == 0PC_C0MPCODE_SUCCESS ) { i f ( copy ) op_pk_destroy( pkptr ); FRET( status ) } ttif 0 i f ( route_optim == false' ) FRET( OPC_COMPCODE_FAILURE ) #endif num_bind = pp_prg_list_size( CA_bind_ptr ); fort i=0; ihome_addr ) ) { status =. OPC_COMPC0DE_SUCCESS; data_len = op_pk_total_size_get( pkptr )/8; encap_pkptr = op_pk_create_fmt( \"ip_dgram\" ) ; op_pk_bulk_size_set( encap_pkptr, data_len*8 ); °p_pk_nf d„set ( encap_pkptr, \"data\", pkptr ) ; op_pk_nfd_set( encap_pkptr, \"protocol\" , PROTOCOL_ENCAP ); op_pk_nfd„set( encap_pkptr, \"src_net\", current.net ); op_pk_nfd_set( encap_pkptr, \"src_node\", current.node ) op_pk_nfd_set( encap_pkptr, \"dest_net\" • , ca_entry->careof.net ); op_pk_nfd_set(.encap_pkptr, \"dest_node\" , ca_entry->careof . node ) ,-op_pk_nfd_set( encap_pkptr, \"orig_len\", data_len ); op_pk_nfd_set( encap_pkptr, \"frag_len\", data_len ); op_pk_nfd_set ( encap_pkptr, \"ident\", (*pk_id)++ ) ,-op_pk_nfd_set ( encap_pkptr, \"frag\", 0 ) ,-' op_pk_nfd_set( encap_pkptr, \" t t l \" , t t l ); / * Now schedule packet for transmission */ encap_pk_send( encap_pkptr ); FRET( OPC_COMPCODE_SUCCESS ) i f ( copy ) op_pk_destroy ( pkptr ) ,-FRET( status ) } Appendix C. Supplementary Source Code of the Handoff Enhanced Model 133 void deliver_packet( pkptr, i c i_pt r , next_net, next_node, outstrm, mtu ) Packet *pkptr; Ic i * i c i_ptr ; int next_net, next_node, outstrm, mtu; { char str0[512], strl[512]; int i , len; int header_size, frag_size, data_size; int dest_net, dest_node; int t t l ; int frag_accum, frag, num_frags; Packet *ip_pkptr, *data_pkptr, *frag_ptr,-FIN( deliver_packet( pkptr, . . . ) ) ' / * obtain packet's destination */ op_pk_nfd_get( pkptr, \"dest_net\", &dest_net ); op_pk_nfd_get ( pkptr, \"dest_node\", &dest_n'ode ) ,-/ * Decrement the packet's t ime-to-live f i e l d . If zero is reached, * / / * discard the packet rather than send i t on. */ op_pk_nfd_get (pkptr, \" t t l \" , &t t l ) ; t t l - - ; i f ( t t l ==0) . • { / * In debug mode, indicate that a packet is destroyed */ / * due to an expired t t l . */ i f (op_prg_odb_ltrace_active ( \"ip_errs\" ).) { sprintf (strO, \"Discarding packet (%d) with expired TTL\", op_pk_id (pkp-sprintf (s tr l , \"Destination: net (%d), node (%d)\", dest_net, dest_node) ,-op_prg_odb__print_rnajor (strO, s t r l , OPC_NIL) ; . } op_pk_destroy (pkptr); } else{ / * Assign the new decremented value of t t l . */ op_pk_nfd_set .(pkptr, \" t t l \" , t t l ) ; / * In debug mode, trace the routing action. * / i f (op_prg_oclb_ltrace_active ( \"mobile-ip_rte\" ) ) { sprintf (strO, \"Routing towards (%d, %d)\", dest_net, dest_node) ,-sprintf (s tr l , \"Next hop (%d, %d), output stream (%d)\", next_net, next_node, outstrm); op_prg_odb_print_major (strO, s t r l , OPC_NIL); } / * Install an Ici indicating to the lower layer what the */ / * address of the next (intermediate) node i s . * / op_ici_attr_set ( ici_ptr , \"next_node\", next_node); o p _ i c i _ i n s t a l l ( i c i_ptr ) ; /'* Obtain the size in bytes of the fragment. * / frag_size = op_pk_total_size_get (pkptr) / 8; • / * Obtain the number of bytes of data carried in this fragment */ op_pk_nfd_get (pkptr, \"frag_len\", &data_size); / * Also obtain the difference between the packet size * / / * and the length f i e l d : this is the size of the header. * / header_size = frag_size - data_size,-Appendix C. Supplementary Source Code of the Handoff Enhanced Model 134 / * If i t is smaller than the maximum transfer unit, send i t as i s . */ i f (frag_size <= mtu) { opj>k_send (pkptr, outstrm) ,-} else{ / * Otherwise, break i t into fragments */ / * Each fragment can contain up to (mtu - header_size) bytes of data */ num_frags = (data_size + mtu - header_size - 1) / (mtu - header_size); /*' In debug mode, indicate the fragmentation. */ i f (op_prg_odb_ltrace_active ( \" i p „ f r a g \" ) ) • { \" sprintf (strO, \"Breaking datagram 'into (%d) fragments\", num_frags); op_prg_odb_print_major (strO, OPC_NIL) ,-} / * If the fragment is carrying the original datagram given to IP, */ / * extract i t before copies are made. Only one fragment can carry */ / * the original packet for the reassembly model to work properly. */ i f (op_pk_nfd_is_set (pkptr, \"ip^dgram\")) op_pk_nfd_get (pkptr, \"ip_dgram\", &ip_pkptr); else ip_pkptr = OPC_NIL; / * If the packet is carrying any encapsulated data (normally this * / / * would happen only for a packet fragmented for the f i r s t time), * / / * extract this' data packet so that i t w i l l not appear in each */ - / * fragment generated by copying. */ i f (op_pk_nfd_is_set (pkptr, \"data\")) op_pk_nfd_get (pkptr, \"data\", &data_pkptr); else data_pkptr = OPC_NIL; / * Loop through and' create the fragments . * / for (frag_accum =0, i = 0; i < num_frags; i++) { / * Make a copy of the original packet. */ frag_ptr = op_pk_copy (pkptr); / * Indicate that the copy is a fragment * / op_pk_nfd_set (frag_ptr, \"frag\", 1) ,-/ * for a l l but the last fragment, the size is the mtu. */ / * and the encapsulated ip packet is not included. * / i f (i < nurn_frags - 1) . { op_pk_nfd_set (frag_ptr, \"frag_len\", mtu - header_size); op_pk_total_size_set (frag_ptr, 8 * mtu); frag_accum += (mtu - header_size); } • • ' else{ len = data_size - frag_accum; op_pk_nfd_set (frag_ptr, \"frag_len\", len) ,-op_pk_total_size_set (frag_ptr,8 * (header_size + len) )•; / * If the original packet was not a fragment, encapsulate i t * / • / * into the last fragment created here. * / op_pk_nfd_get (pkptr, \"frag\", &frag); i f (!frag) { / * If the packet contained encapsulated data ( i . e . , from the */ / * transport), that data w i l l have been removed to avoid */ Appendix C. Supplementary Source Code of the Handoff Enhanced Model 135 now be */ / * i t s duplication in the fragments. The data should / * reinserted into the original packet! * / i f (data_pkptr != OPC_NIL) op_pk_nfd_set- (pkptr, \"data\", data_pkptr) ,-/ * In either case the original packet is */ / * encapsulated in thhe fragment. * / op_pk_nfd_set (frag_ptr, \"ip_dgram\", pkptr); • */ gram */ fragment */ ated */ ip_pkptr); / * Otherwise the packet can be discarded. * / else{ op_pk_destroy (pkptr); / * Also, i f the packet included the original datagram / * from which i t was generated, transfer that data-/ * into the last fragment created here. * / - / * Note that i t is possible, in the case where a / * is i t s e l f being fragmented, that none of the cre-/ * fragments w i l l contain the original datagram. */ i f (ip_pkptr != OPC_NIL) { op_pk_nfd_set (frag_ptr, \"ip_dgram\", } / * Forward the datagram fragment. opj>k_send (frag_ptr, outstrm); FOUT; } Compcode forward_to_visitor ( mobile_table', bind_list_ptr , pkptr, i c i_pt r , dest ) Lis t *bind_list_ptr , *mobile_table; Packet *pkptr; Ici *ici_ptr,-IP . • dest; { char str0[80], strl[80] ; Compcode status = OPC_COMPCODE_FAILURE; int i , s ize; int next_net, next_node, stream, mtu; FA_mobility_binding*visitor_entry; FIN( forward_to_visitor( mobile_table, bind_list_ptr , pkptr, i c i_pt r , dest size = op_prg_list_size( bind_list_ptr ); i f ( size ==0 )/* l i s t does not exist */ FRET ( OPC COMPCODE FAILURE ) fori i=0; ihome_addr, sizeof(IP) ) ) { / * There is a match */ i f ( visitor_entry->home_agnt.net'!= ADDRESS_UNDEFINED && visitor_entry->home_agnt.node != ADDRESS_UNDEFINED ) { Status = OPC_COMPCODE_SUCCESS; next_net = visitor_entry->home_addr.net; next_node = visitor_entry->home_addr.node; stream = visitor_entry->stream; mtu = get_strm_mtu( mobile_table, stream ),-i f ( mtu == MOBILE_STRM_NONEXISTENT ) { sprintf (strO, \"Discarding packet (%d) \", op_pk_id (pkptr)) sprintf (s t r l , \"Stream non-existent\" ); op_prg_odb_print_ma j or (strO, s t r l , OPC_NIL) ,-op_pk_destroy ( pkptr ),-} else { deliver_packet( pkptr, i c i_ptr , next_net, next_node, stream, mtu ); FRET( status ); } int get_strm_mtu( strm_ptr, strm ) List*strm_ptr; int strm; ' { int i , s ize; mobi1e_rte_tab1e*strm_entry; FIN( get_strm_mtu( strm_ptr, strm ) ) size = op_prg_list_size ( strm_ptr ),-for( i=0; istream == strm ) FRET{ strm_entry->mtu ); . •} ' ' : FRET( MOBILE_STRM_NONEXISTENT ); } int chk_strm_condition(-mobile_table, stream, mtu ) Lis t *mobile_table; int stream; int *mtu; { Appendix C. Supplementary Source Code of the Handoff Enhanced Model 137 int i , s ize; mobi1e_rte_tab1e*tab1e_entry; FIN( chk_strm_condition( mobile_table, stream, \"mtu ) ) size = op_prg_list_size( mobile_table ); for( i=0; istream == stream ) { *mtu = table_entry->mtu; FRET( table_entry->condition ) } } / * stream does not exist */ -*mtu = MOBILE_STRM_NONEXISTENT; ' FRET( CONDITION_DISABLED ) } void get_careof_addr( mobile_table, i c i p t r ) List *mobile_table; Ici \" * i c i p t r ; . .• { _ • int i , s ize; int stream; IP careof;• mobile_rte_table*table_entry; FIN( get_careof_addr( mobile_table, i c i p t r ) ) op_ici_attr_get ( i c i p t r , \"stream\", &stream ),-size = op_prg_list_size( mobile_table ); . fort i=0; istream == stream ) { op_ici_attr_set( i c i p t r , \"careof_net\", table_entry->careof.net ); op_ici_attr_set ( i c i p t r ; \"careof jiode\" , table_entry->careof .node ),-op_ici_attr_set ( i c i p t r , \"status\", OPC_COMPC0DE_SUCCESS ) ,-FOUT } } . . / * stream does not exist */ op_ici_attr_set( i c i p t r , \"careof_net\", ADDRESSJJNDEFINED ) op_icl_attr_set( i c i p t r , \"careof_node\",•ADDRESS_UNDEFINED op_ici_attr_set( i c i p t r , \"status\", OPC_COMPCODE_FAILURE ); FOUT void set_strm_condition( mobile_table, i c i p t r ) Appendix C. Supplementary Source Code of the Handoff Enhanced Model 138 List*mobile_table; Ici * i c i p t r ; { IP careof; int stream; int mode; int i , s ize; . ' . Compcodestatus = OPC_COMPCODE_FAILURE; mobile_rte_table*list_ptr; FIN( set_strm_condition( i c i p t r ) ) op_ici_attr_get( i c i p t r , \"mode\", &mode ); op_ici_attr_get( i c i p t r , \"stream\", &stream ); size = op_prg_list_size( mobile_table ); for( i=0; icondition = CONDITION_DISABLED; status = OPC_COMPCODE_SUCCESS; break; case DISABLE_ALL_EXCEPT_THIS: if{ list_ptr->stream != stream ) { list_ptr->condition = C0NDITION_DISABLED; status = OPC_C0MPC0DE_SUCCESS; } ' . break; case DISABLE_THIS_ONLY: i f ( list_ptr->stream == stream ) { op_ici_attr_set ( i c i p t r , \" c a r e o f „ n e t \" , list_ptr->careof .net ) ;\" op_ici_attr_set ( i c i p t r , \"careof_node\", list__ptr->careof .node ) ,-list_ptr->condition = CONDITION_DISABLED; status = OPC_COMPCODE_SUCCESS; } break,-case ENABLE_ALL: - '. ' l ist_i3tr->condition = CONDITION_ENABLED; ' Status = OPC_COMPCODE_SUCCESS; break ,-case ENABLE_ALL_EXCEPT_THIS: i f ( list_ptr->stream != stream ) { list_ptr->condition = CONDITION_ENABLED;' status = OPC_COMPCODE_SUCCESS; } break; case ENABLE_THIS_ONLY: i f ( list_ptr->stream == stream ) { op_ici_attr_set ( i c i p t r , \"careof_net\" , list_ptr->careof . net ) ,-op_ici_attr_set( i c i p t r , \"careof_node\", list_ptr->careof.node ); list_ptr->condition = CONDITION_ENABLED; status = OPC_COMPCODE_SUCCESS;. Appendix C. Supplementary Source Code of the Handoff Enhanced Model break; default: status = OPC_COMPCODE_FAILURE; break ,-} } op_ici_attr_set( i c i p t r , \"status\", status ); FOUT ) void hop_to_next_strm( mobile_table, i c i p t r ) Lis t *mobile_table ,-Ici * i c i p t r ; { int j , i , s ize; int stream; mobile_rte_table*table_entry,-FIN( hop_to_next_strm( mobile_table, i c i p t r ) ) op_ici_attr_get( i c i p t r , \"stream\", &stream ); size = op_prg_list_size( mobile_table ); for ( i=0; istream'== stream ) { i f ( ( j = i + 1 ) == size ) j = 0; table_entry = ( mobile_rte_table * ) op_prg_list_access( mobile_table, j op_ici_attr_set( i c i p t r , \"stream\" , . , table_entry->stream ); op_ici_attr_set( i c i p t r , \"careof_net\" ,table_entry->careof.net); op_ici_attr_set( i c i p t r , \"careof_node\" ,table_entry->careof.node); / . /*'Ndw, enabling this stream * / ' table_entry->condition = CONDITION_ENABLED; op_ici_attr_set( i c i p t r , \"status\" , OPC_COMPCODE_SUCCESS ); FOUT } } ' op_ici_attr_set( i c i p t r , \"status\", OPC_COMPCODE_FAILURE ); FOUT void process_binding_warning( pkptr, i c i p t r , rcv_iciptr , ip_objid ) Packet *pkptr; Appendix C. Supplementary Source Code of the Handoff Enhanced Model 140 I c i * i c i p t r ; I c i * r c v _ i c i p t r ; Objid i p _ o b j i d ; { IP horae_addr, rem, target, home_agnt; i n t rem_port; Packet *bind_pkptr; Compcode status; I c i * b i n d _ i c i p t r ,-FIN( process_binding_warning( pkptr, i c i p t r , r c v _ i c i p t r , i p _ o b j i d ) ) op_pk_nfd_get( pkptr, \"home_addr_net\" , &home_addr .net ) ,-op_pk_nfd_get( pkptr, \"home_addr_node\", &home_addr.node ); op_pk_nfd_get( pkptr, \"target_net\" , &target.net ); op_pk_nfd_get( pkptr, \"target_node\", &target.node ); . op_ici_a'ttr_get ( r c v _ i c i p t r , \"rem_net\", trem.net ) ; o p _ i c i _ a t t r _ g e t ( r c v _ i c i p t r , \"rem_node\", krem.node ),-o p _ i c i _ a t t r _ g e t ( r c v _ i c i p t r , \"rem_port\", &rem_port ) ,-/* c r e a t i n g binding for Mobile-ip query */ b i n d _ i c i p t r = o p _ i c i _ c r e a t e ( \"binding_command\" ); o p _ i c i _ a t t r _ s e t ( b i n d _ i c i p t r \" c o m m a n d \" , READ_HA_BINDING ) ,-o p _ i c i _ a t t r _ s e t ( b i n d _ i c i p t r , \"home_net\", home_addr.net ); o p _ i c i _ a t t r _ s e t ( b i n d _ i c i p t r , \"home_node\" , home_addr .node ) ;, o p _ i c i _ i n s t a l l ( b i n d _ i c i p t r ); op_intrpt_force_remote( BINDING_MAINTENANCE, i p _ o b j i d ); o p _ i c i _ i n s t a l l ( OPC_NIL ); o p _ i c i _ a t t r _ g e t ( b i n d _ i c i p t r , \"status\", &status ),-i f ( status == OPC_COMPCODE_SUCCESS ) { /* send binding warning i f home addr i s a- r e g i s t e r e d MH */ bind_pkptr = op_pk_create_fmt( \"bind_warn\" ); op_pk_nfd_set ( bind_pkptr, \"home_addr_net\", home_addr.net ),-op_pk_nfd_se't ( bind_pkptr, \"home_addr_node\" , home_addr.node ); op_pk_nfd_set( bind_pkptr, \"target_net\", target.net ); op_pk_nf d_set ( bind_pkptr, \"target_node\" , target.node ) ,-. udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , REG_REQUEST_PORT, target.net, target.node ); } e l s e { #if 1 /* f i r s t of a l l , check whether home addr i s on cache l i s t */ o p _ i c i _ a t t r _ s e t ( b i n d _ i c i p t r , \"command\", READ_CA_BINDING ),-o p _ i c i _ i n s t a l l ( b i n d _ i c i p t r ),-op_intrpt_force_remote( BINDING_MAINTENANCE, i p _ o b j i d ); o p _ i c i _ i n s t a l l ( OPC_NIL ); ' o p _ i c i _ a t t r _ g e t ( b i n d _ i c i p t r , \"status\", &status ); i f ( status == OPC_COMPCODE_SUCCESS ) { /* Home addr on cache l i s t , send binding request to home addr */ o p _ i c i _ a t t r _ g e t ( b i n d _ i c i p t r , \"home_agnt_net\", Screm.net ) ; o p _ i c i _ a t t r _ g e t ( b i n d _ i c i p t r , \"home_agnt_node\", krem.node ); bind_pkptr = op_pk_create_fmt( \"bind_req\" ); Appendix C. Supplementary Source Code of the Handoff Enhanced Model 141 Seise ttendif else op_pk_nfd_set( bind_pkptr, \"home_addr_net\", home_addr.net ); op_pk_nfd_set( bind_pkptr, \"home_addr_node\", home_addr.node ) / * send the registration packet */ udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , REG_REQUEST_PORT, rem.net, rem.node ); / * no binding found, send i t to target */ bind_pkptr = op_pk_create_f mt ( \"bind_req\" ),-op_pk_nfd_set( bind_pkptr, \"home_addr_net\", home_addr.net ); • op_pk_nfd_set ( bind_pkptr, .\"home_addr_node\" , home_addr.node ); / * send the registration packet */ , udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , REG_REQOEST_PORT, target.net, target.node ),-} bind_pkptr = op_pk_create_fmt( \"bind_req\" ); op_pk_nf d_set ( bind_pkptr, \"home_addr_net\", home_addr.net ) ,-op_pk_nfd_set( bind_pkptr, \"home_addr_node\", hbme_addr.node ) / * send the registration packet * / udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , rem_port, rem.net, . rem.node ); / * deallocate resources after usage */ • op_ici_destroy ( bind_iciptr ),-FOUT } void process_binding_request( pkptr, i c i p t r , rcv_iciptr , objid ) Packet *pkptr;' Ici * i c i p t r ; Ici . *rcv_iciptr ,-Objid objid; { Packet *bind_pkptr; IP home_addr; IP careof; IP rem; int rem_port; Ic i * i p _ i c i p t r ; int status,-int lifetime,-FIN( process_binding_request ( pkptr,- i c i p t r , rcv_iciptr , objid ) ) op_pk_nfd_get( pkptr, \"home_addr_net\", &home_addr.net ); op_pk_nfd_get ( pkptr, \"home_addr_node\" , &home_addr .node ) ;' op_ici_attr_get( r c v „ i c i p t r , \"rem_net\", trem.net ); op_ici_attr_get ( rcv_iciptr , \"rem_node\", &rem.node ) ,-op_ici_attr_get ( rcv_iciptr , \"rem_port\", &rem_port ) ,-i p _ i c i p t r = o p _ i c i „ c r e a t e ( \"binding_cornmand\" ); ' op_ici_attr_set( ip_ ic ip t r , \"command\", READ_HA_BINDING ); op_ici_attr_set( ip_ ic ip t r , \"home_net\", home_addr.net ); op_ici_attr_set( ip_ ic ip t r , \"home_node\", home_addr.node ); Appendix C. Supplementary Source Code of the Handoff Enhanced Model 142 o p _ i c i _ i n s t a l l ( i p _ i c i p t r ) ,-op_intrpt_force_remote( BINDING_MAINTENANCE, o b j i d ); o p _ i c i _ i n s t a l l (' OPC_NIL ) • o p _ i c i _ a t t r _ g e t ( i p _ i c i p t r , \" s t a t u s \" , t s c a t u s ) ; i f ( status == 0PC_COMPCODE_FAILURE ) { careof = home_addr;/* no bin d i n g e x i s t s */ l i f e t i m e = 0 ,-} . - . • • ' • ' e l s e { o p _ i c i _ a t t r _ g e t ( i p _ i c i p t r , \"careof_net\", &careof.net ); o p _ i c i _ a t t r _ g e t ( i p _ i c i p t r , \"careof_node\", Scareof .node ) ,-o p _ i c i _ a t t r _ g e t ( i p _ i c i p t r , \" l i f e t i m e \" , & l i f e t i m e ) ; } . . /* d e a l l o c a t e i c i p o i n t e r a f t e r use */ o p _ i c i _ d e s t r o y ( i p _ i c i p t r ); bind_pkptr = op_pk_create_fmt( \"bind_update\" ),-op_pk_nfd_set( bind_pkptr, \"home_addr_net\", home_addr.net ) ; op_pk_nf d_set ( bind_pkptr, \"home_addr_node\" , home_addr .node ) ,-op_pk_nf d_set ( bind_pkptr, \" careof_net\", careof.net ) ; op_pk_nf d_set ( bind_pkptr, \"careof_node\" , careof.node ) ; op_pk_nfd_set( bind_pkptr, \" l i f e t i m e \" , l i f e t i m e ); /* send b i n d i n g request v i a UDP port */ udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT, rem_port, rem.net, rem.node ); FOUT } vo i d process_binding_update( pkptr, i c i p t r , r c v _ i c i p t r , o b j i d ) Packet *pkptr; I c i * i c i p t r , -I c i * r c v _ i c i p t r ; O b j i d o b j i d ; { Packet *bind_pkptr; IP home_addr; IP careof; IP rem; i n t rem_port; I c i * i p _ i c i p t r , -i n t l i f e t i m e , ack, s t a t u s ; FIN( process_binding_update( .pkptr, i c i p t r , r c v _ i c i p t r , o b j i d ) ) op_pk_nfd_get ( pkptr, \"home_addr_net\" , Sthome_addr.net ); op_pk_nfd_get ( pkptr, \"home_addr_node\" , Schome_addr.node ),-op_pk_nf d_get ( pkptr, \"careof_net\" ,• sicareof.net ); op_pk_nfd_get ( pkptr, \"careof_node\" , Stcareof .node ); op_pk_nf d_get ( pkptr, \" l i f e t i m e \" , Stlifetime ) ; op_pk_nf d_get ( pkptr, \"ack\", Stack ) ; o p _ i c i _ a t t r _ g e t ( r c v _ i c i p t r , \"rem_net\", &rem.net ) ,-o p _ i c i _ a t t r _ g e t ( r c v _ i c i p t r , \"rem_node\", Strem.node •) ,-o p _ i c i _ a t t r _ g e t ( r c v _ i c i p t r , \"rem_iDort\",' &rem_port ) ,-i p _ i c i p t r = o p _ i c i _ c r e a t e ( \"binding_command\" ),-i f ( (careof.net == 0 && careof.node ==0) I I l i f e t i m e == 0 ) { o p _ i c i _ a t t r _ s e t ( i p _ i c i p t r , \"command\", KILL_CA_BINDING ), Appendix C. Supplementary Source Code of the Handoff Enhanced Model 143 op_ici_attr_set( ip_ ic ip t r , \"home_net\", home_addr.net ); op_ici_attr_set( ip_ ic ip t r , \"home_node\", home_addr.node ); o p _ i c i _ i n s t a l l ( i p _ i c i p t r ) ,-op_intrpt_force_remote( BINDING_MAINTENANCE, objid ); } else { op_ .ici_ _install( OPC _NIL ) ; op_ ,ici_ _attr_set ( ip. _ ic iptr , \"command\", EDIT_CA_BINDING op_ .ici_ _attr_set( ip. _ ic iptr , \"home_net\", home_addr.net ) op_ .ici_ _attr__set ( ip. _ ic iptr , \"home_node' , home_addr.node op_ .ici_ „ a t t r _ s e t ( ip. _ ic iptr , \"home_agnt_ .net\" , rem.net ) ; op_ _ici_ _attr_set( ip. _ ic iptr , \"home_agnt_ .node\", rem. node op_ .ioi_ „ a t t r _ s e t ( ip. _ ic iptr , \"careof_net\", carepf.net ); op_ .ici_ _attr_set ( ip. _ ic iptr , \"careof_node\", careof.node op_ .ici_ _attr_set( ip. _ ic iptr , \" l i fet ime\" , lifetime ); op_ .ici_ _ instal l ( ip_ i c iptr ) • op_intrpt_force_remote( BINDING_MAINTENANCE, objid ); o p _ i c i _ i n s t a l l ( OPC_NIL ) ; i f ( ack == true ) { bind_pkptr = op_pk_create_fmt ( \"bind_ack\" ) ,-op_pk_nfd_set ( bind_pkptr, \"home_addr_net\" ,\" home_addr .net ) ,-op_pk_nf d_set ( bind_pkptr, \"home_addr_node\" , home_addr . node ) ,-/ * send binding request via UDP port ' * / udp_app_send( i c i p t r , bind_pkptr, REG_REQUEST_PORT , rem_port, rem.net, rem.node ); } ' ' } / * deallocate i c i pointer after use */ op_ici_destroy( ip_ic ipt r ).,-FOUT } • • #if 0 void encap_pk_destroy( pkptr ) Packet *pkptr; { Packet *outer_pkptr, *inner_pkptr; int i , num_fds, data_present ,-char \" fd_name[40] ; 'FIN( encap_pk_destroy( pkptr ) ) outer_pkptr = pkptr; while ( 1 ) { num_fds = op_pk_fd_max_index ( outer_pkptr ),-for ( data_present=false,i=0; i< num_fds; ++i ) { ' ' . op_pk_fd_index_to_name( outer_pkptr, i , fd_name .); i f ( strcmp( fd_name, \"data\" ) ==0.) { \" op_pk_nfd_get( outer_pkptr, \"data\", &inner_pkptr ); op_pk_destroy( outer_pkptr ); • . Appendix C. Supplementary Source Code of the Handoff Enhanced Model 144 data_present = true; break,-} / * no fields with name \"data\" * / i f ( data_present == false ) break ,-outer_pkptr = inner_pkptr; op_pk_destroy( outer_pkptr ), FOUT } ttendif void generate_bind_warning( dest, reg_objid, home_addr, target ) IP dest, home_addr, target; Objid reg_objid; { Ici *warn_iciptr; FIN( generate_bind_warning( home_addr, ) ) warn_iciptr = op_ici_create(\"bind_warn_ici\"); op_ici_attr_set( warn_iciptr, \"home_addr_net\", home_addr.net ); op_ici_attr_set( warn_iciptr, \"home_addr_node\", home_addr.node ) op_ici_attr_set( warn_iciptr, \"dest_net\", dest.net ); op_ici_attr_set ( warn_iciptr, \"dest'_node\" , dest .node ) ; op_ici_attr_set ( warn_iciptr, \"target_net\", target.net ),-op_ici_attr_set ( warn_iciptr, \"target_node\" , target .node ) ,-op_ici_instal l ( warn_iciptr ); op_intrpt_force_remote ( BINDING_WARN_TYPE, reg_objid ) ,-. o p _ i c i _ i n s t a l l ( OPC_NIL .) ,-op_ici_destroy( warn_iciptr ); FOUT } void encap_pk_send( pkptr ) Packet *pkptr; { FIN( encap_pk_send( pkptr ) ) / * insert encapsulated packet at the beginning of the queue * / / * op_subq_pk_insert( 0, pkptr, 0PC_QP0S_HEAD );*/ op_subq_pk_insert( 0 , ' p k p t r , OPC_QP0S_HEAD ); FOUT } void check_ca_list( l i s t_pt r , dest, home_agnt ) List * l i s t _ p t r ; IP dest; IP *home_agnt; Appendix C. Supplementary Source Code of the Handoff Enhanced Model 145 CA_mobility_binding*ca_entry; int i , num_bind; FIN( check_ca_list( l i s t_pt r , dest, home_agnt ) ) nurn__bind = op_prg_list_size ( l i s t_ptr ); fori i=0; ihome_addr ) ) { . home_agnt->net = ca__entry->horne_agnt.net; home_agnt->node = ca_entry->home_agnt.node; FOUT } } home_agnt->net = ADDRESS_UNDEFINED; home„agnt->node = ADDRESS_UNDEFlNED; FOUT } Compcode i n s e r t j > k „ b u f f e r ( buffer_ptr, buffer_ l i fe , dest, pkptr ) Lis t *buffer_ptr; double b u f f e r _ l i f e ; IP dest; Packet *pkptr; { int i , size; packet_buffer*entry_ptr; Lis t *packet_list ,-Ic i , * i c i p t r ; FIN( insert_pk_buffer( buffer_ptr, buffer_ l i fe , dest, pkptr ) ) i f ( buffer_ l i fe <= 0.0 ) FRET( OPC_COMPCODE_FAILURE ) size = op_prg_list_size ( buffer_ptr ),-for ( i=0; idest ) ) { packet_list = entry_ptr->cache_list; op_prg_list_insert( packet_list, pkptr, OPC_LISTPOS_TAIL FRET( 0PC_COMPCODE_SUCCESS ) / * no buffer for this destintation yet */ FRET( OPC_COMPCODE_FAILURE ) "@en ; edm:hasType "Thesis/Dissertation"@en ; vivo:dateIssued "1997-05"@en ; edm:isShownAt "10.14288/1.0065102"@en ; dcterms:language "eng"@en ; ns0:degreeDiscipline "Electrical and Computer Engineering"@en ; edm:provider "Vancouver : University of British Columbia Library"@en ; dcterms:publisher "University of British Columbia"@en ; dcterms:rights "For non-commercial purposes only, such as research, private study and education. Additional conditions apply, see Terms of Use https://open.library.ubc.ca/terms_of_use."@en ; ns0:scholarLevel "Graduate"@en ; dcterms:title "Handoff enhancement in mobile-ip environment"@en ; dcterms:type "Text"@en ; ns0:identifierURI "http://hdl.handle.net/2429/5685"@en .