AU7812600A

AU7812600A - Internet protocol mobility architecture framework

Info

Publication number: AU7812600A
Application number: AU78126/00A
Authority: AU
Inventors: Haseeb Akhtar; March H. Barnes; Carey B. Becker; Russell C. Coffin; Mohamed Khalil; Liem Q. Le; Raja Narayanan; Basavaraj B. Patil; Emad A. Qaddoura; Rambabu Tummala; Donald L. Wurch; Zemin Zhu
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 1999-09-08
Filing date: 2000-09-08
Publication date: 2001-04-10
Also published as: WO2001019050A2; WO2001019050A3; EP1214828A2

Description

WO 01/19050 PCT/IBOO/01553 1 INTERNET PROTOCOL MOBILITY ARCHITECTURE FRAMEWORK CLAIM OF PRIORITY This application claims priority from U.S. Provisional Patent Application No. 60/152,916 entitled 5 "IP MOBILITY ARCHITECTURE FRAMEWORK" filed on behalf of Haseeb Akhtar, et al, on September 8, 1999 (Attorney Docket No. 11060RRUS01P) This application also claims priority from U.S. Provisional Patent Application No. 60/157,449 entitled 10 "KEY EXCHANGE FOR NETWORK ARCHITECTURE (KENA)" filed on behalf of Mohamed Khalil, et al, on October 4, 1999 (Attorney Docket No. 11349RR). This application also claims priority from U.S. Provisional Patent Application No. 60/156,669 entitled 15 "ROUTING MECHANISM FOR AAA PROTOCOL" filed on behalf of Haseeb Akhtar, et al, on September 29, 1999 (Attorney Docket No. 10578RRP). This application also claims priority from U.S. Provisional Patent Application No. 60/157,289 entitled 20 "NETWORK ACCESS ARBITRATOR" filed on behalf of Donald Wurch, et al, on October 1, 1999 (Attorney Docket No. 10740RRP). This application also claims priority from U.S. Provisional Patent Application No. 60/192,411 entitled 25 "USER SUPPORT FOR MULTIPLE DEVICES" filed on behalf of Khalil, et al, on March 27, 2000, (Attorney Docket No. 11943RR). TECHNICAL FIELD The invention relates generally to communications 30 and, more particularly, to a communications architecture WO 01/19050 PCT/IBOO/01553 2 that provides for mobile communications based on an Internet Protocol. BACKGROUND The advent of lightweight portable computers and 5 hand-held devices, the spread of wireless networks and services, and the popularity of the Internet combine to make mobile computing a key requirement for future networks. However, the heterogeneous nature of today's wireline networks (e.g., dial-up, xDSL, cable), wireless 10 networks (e.g., GSM, CDMA, TDMA), and enterprise networks (e.g., LAN, WAN) significantly limits the scope of mobility between these heterogeneous networks. What is needed is a mobility architecture framework by which the various types of networks and access thereto 15 may converge into a unified homogeneous network that will carry multiple types of traffic and permit access to the network irrespective of the MN's location and the type of access media used to access the network. SUMMARY 20 The present invention, accordingly, provides a communications architecture for enabling IP-based mobile communications. The architecture includes at least one Local Service Function (LSF) component configured to serve as an IP-based serving area network for a set of x 25 Access Networks (xAN), and at least one Network Service Function (NSF) component configured to serve as an IP based home network by managing an MN's subscription and associated profile so that the MN is authorized to use the resources of the LSF. At least one xAN is 30 interconnected to the LSF and NSF for providing WO 01/19050 PCT/IBOO/01553 3 heterogeneous Layer 2 access for MNs irrespective of access technology. BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present 5 invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: FIGURE 1 is a schematic drawing which depicts a representative high-level view of a network embodying 10 features of the present invention; FIGURE 2 depicts a distributed and an integrated local service function (LSF) and network service function (NSF) embodying features of the present invention; FIGURE 3 shows a home network view and a visited 15 network view of a network embodying features of the present invention; FIGURES 4A and 4B depict the architectural components of LSFs and NSFs embodying features of the present invention; 20 FIGURES 4C and 4D show the components of HCDM and SCDM functions, respectively; FIGURES 4E and 4F show the component functions of NSF and LSF AAA functions, respectively; FIGURE 5 show DDNS and DHCP functions embodying 25 features of the present invention; FIGURE 5A is a flow which depicts the operation of the DDNS; FIGURE 5B, SC and 5D are flows which depicts the alternate embodiments of storing MN's COA in the DNS; 30 FIGURE 6 shows directory services embodying features of the present invention; WO 01/19050 PCT/IBOO/01553 4 FIGURE 6A is a schema relationship diagram which specifies a preferred relationship between object classes utilized by UDS and LDS subsystems; FIGURES 6B and 6C depict class inheritance trees 5 which specify a preferred hierarchy of object classes shown in FIG. 6A; FIGURE 6D depicts a preferred Directory Information Tree (DIT) which shows how sub-directories are organized in the UDS and LDS for storing the object classes shown 10 in FIGS. 6A. 6B, and 6C; FIGURES 6E, 6F, 6G, 6H, 61, 6J, 6K, and 6L are tables which exemplify attributes preferably associated with the object classes shown in FIGS. 6A, 6B, 6C, and 6D; 15 FIGURE 6M is a schematic diagram exemplifying a UDS database and its interfaces with other components; FIGURE 7 shows routing areas within an LSF embodying features of the present invention; FIGURE 8 shows a security framework embodying 20 features of the present invention; FIGURE 9 shows security associations (SAs) between LSFs and NSFs embodying features of the present invention; FIGURE 10 shows Mobile Node (MN) and Correspondent 25 Node Security embodying features of the present invention; FIGURE 11 shows an AAA framework embodying features of the present invention; FIGURE 12 shows AAA function locations in a network 30 embodying features of the present invention; WO 01/19050 PCT/IBOO/01553 5 FIGURE 13 shows security for AAA functions embodying features of the present invention; FIGURE 14 shows interfaces embodying features of the present invention; 5 FIGURES 14A and 14B depicts the embodying features of the interface between an xAN and an LSF; FIGURE 15 shows a mobility Security Association (SA) between LSF and Home NSF AAA functions embodying features of the present invention; 10 FIGURE 16 shows mobility SA between NSFs embodying features of the present invention; FIGURE 17 shows a single IP router in an LSF embodying features of the present invention; FIGURE 18 shows multiple IP routers in an LSF 15 embodying features of the present invention; FIGURE 19 shows a hierarchical mobility router embodying features of the present invention; FIGURE 20 shows MN Components embodying features of the present invention; 20 FIGURE 20A shows origination and destination points of IPM messages; FIGURE 20B shows a general format for an IPM message; FIGURE 20C shows a preferred general format for a 25 general MIP extension; FIGURE 20D shows the message format of an Authentication Information Extension; FIGURE 20E shows the message format of a Call Information Extension; 30 FIGURE 20F shows the message format of a CN List Extension; WO 01/19050 PCT/IBOO/01553 6 FIGURE 20G shows the message format of an LSF NAI Extension; FIGURE 20H shows the message format of an MN's L2 address extension; 5 FIGURE 201 shows an NAI extension; FIGURE 20J shows an IPM Routing Area Extension; FIGURE 20K shows a Terminal Information Extension; FIGURE 20L shows the message format of a Registration Request message; 10 FIGURE 20M shows the message format for a Registration Reply message; FIGURE 20N shows the message format for a Prepare for System Change message; FIGURE 200 shows the message format for a System 15 Change message; FIGURE 20P shows a preferred general format for an IPM message; FIGURE 20Q shows the message format for an Activate Packet Service message; 20 FIGURE 20R shows the message format for an Activate Packet Service Ack message; FIGURE 20S shows a message format for an Add L2 IP Association message; FIGURE 20T shows the format for a Buffer Data 25 message; FIGURE 20U shows the format for a Buffer Data Ack message; FIGURE 20V shows the format for a Cleanup message; FIGURE 20X shows the format for a Correspondent Node 30 List message; WO 01/19050 PCT/IBOO/01553 7 FIGURE 20Y shows the format for a Correspondent Node List Ack message; FIGURE 20Z shows the format for a Forward Data message; 5 FIGURE 20AA shows the format for a Forward Data Ack; FIGURE 20AB shows the format for a Handoff Required message; FIGURE 20AC shows the format for a Handoff Required Ack; 10 FIGURE 20AD shows the format for an Access Request extension; FIGURE 20AE shows the format for an Access Accept/Reject extension; FIGURE 20AF shows the format for a Simple IPM 15 Registration Request message; FIGURE 20AG shows the format for a Simple IP Registration Reply message; FIGURE 21 is an event sequence diagram showing the flow of events for an Initial Registration, wherein a MN 20 has a publicly routable IP Address; FIGURE 22 is an event sequence diagram showing the flow of events for a Initial Registration, wherein an MN has a publicly non-Routable IP Address; FIGURE 23 is an event sequence diagram showing the 25 flow of events for a Initial Registration, wherein an MN has no IP address; FIGURE 24 is an event sequence diagram showing the flow of events for an Initial Registration using hierarchical routers; 30 FIGURE 25 is an event sequence diagram showing the flow of events for an MN moving to new LSF WO 01/19050 PCT/IBOO/01553 8 FIGURE 26 is an event sequence diagram showing the flow of events for an MN moving to a new RA, new xAN, same LSF; FIGURE 27 is an event sequence diagram showing the 5 flow of events for an MN moving to a new RA, same xAN/LSF, new COA; FIGURE 28 is an event sequence diagram showing the flow of events for an MN moving to a new RA, same xAN/LSF, same COA; 10 FIGURE 29 is an event sequence diagram showing the flow of events for an MN moving to a Home Network; FIGURE 30 is an event sequence diagram showing the flow of events for an MN moving to a new RA, new LSF, no movement indication; 15 FIGURE 31 is an event sequence diagram showing the flow of events for a De-registration packet data session; FIGURE 32 is an event sequence diagram showing the flow of events for an inter system handoff; FIGURE 33 is an event sequence diagram showing the 20 flow of events for an inter xAN handoff, Same LSF; FIGURE 34 is an event sequence diagram showing the flow of events for an inter xAN handoff, same LSF, hierarchical routers; and FIGURES 35 is an event sequence diagram showing the 25 flow of events when an IPM MN registers from an IPM LSF; FIGURE 36 is an event sequence diagram showing the flow of events when an IPM MN registers from an IPM NSF; FIGURE 37 is an event sequence diagram showing the flow of events when an IPM MN registers from a Mobile IP 30 (MIP) FA; WO 01/19050 PCT/IBOO/01553 9 FIGURE 38 is an event sequence diagram showing the flow of events when an MIP MN registers from an IPM LSF; FIGURE 39 is an event sequence diagram showing the flow of events for an IPM MN disconnect detection; 5 FIGURE 40 is an event sequence diagram showing the flow of events when an IPM MN re-registers from an IPM LSF; FIGURE 41 is an event sequence diagram showing the flow of events when an IPM MN re-registers from an IPM 10 NSF; FIGURE 42 is an event sequence diagram showing the flow of events when an IPM MN re-registers from an MIP FA; FIGURE 43 is an event sequence diagram showing the 15 flow of events when an IPM MN re-registers from an IPM LSF; FIGURE 44 is an event sequence diagram showing the flow of events when an IPM MN de-registers from an IPM LSF; 20 FIGURE 45 is an event sequence diagram showing the flow of events when an IPM MN de-registers from an IPM NSF; FIGURE 46 is an event sequence diagram showing the flow of events when an IPM MN de-registers from an MIP 25 FA; FIGURE 47 is an event sequence diagram showing the flow of events when an IPM MN handoffs from ANI to ANI in the same SMM but different ITS; FIGURE 48 is an event sequence diagram showing the 30 flow of events when an IPM MN handoffs from ANI to ANI in the same SMM and same ITS; WO 01/19050 PCT/IBOO/01553 10 FIGURE 49 is an event sequence diagram showing the flow of events when as IPM MN handoffs from SMM to SMM; FIGURE 50 is an event sequence diagram showing the flow of events when an IPM MN handoffs from LSF to NSF; 5 FIGURE 51 is an event sequence diagram showing the flow of events when an IPM MN handoffs from NSF to LSF; FIGURE 52 is an event sequence diagram showing the flow of events of an IPM MN handoff from an IPM ANI to FA, wherein the FA does not support smooth handoffs; 10 FIGURE 53 is an event sequence diagram showing the flow of events of an IPM MN handoff from an FA to an IPM ANI, wherein the FA does not support smooth handoffs; FIGURE 54 is an event sequence diagram showing the flow of events of an IPM MN handoff from an IPM ANI to 15 FA, wherein the FA does support smooth handoffs; FIGURE 55 is an event sequence diagram showing the flow of events of an MIP MN handoff from an IPM ANI to an FA, wherein the FA does not support smooth handoffs; FIGURE 56 is an event sequence diagram showing the 20 flow of events of an IPM MN handoff from an FA to an IPM ANI, wherein the FA supports smooth handoffs; FIGURE 57 is an event sequence diagram showing the flow of events of an MIP MN handoff from an FA to an IPM ANI, wherein the FA does not support smooth handoffs; 25 FIGURE 58 is an event sequence diagram showing the flow of events of an MIP MN handoff from an IPM ANI to an FA, wherein the FA supports smooth handoffs; FIGURE 59 is an event sequence diagram showing the flow of events of an MIP MN handoff from an NSF to an FA, 30 wherein the FA does not support smooth handoffs; WO 01/19050 PCT/IBOO/01553 11 FIGURE 60 is an event sequence diagram showing the flow of events of an MIP MN handoff from an FA to an IPM ANI, wherein the FA supports smooth handoffs; FIGURE 61 is an event sequence diagram showing the 5 flow of events of an MIP MN handoff from an FA to an NSF, wherein the FA does not support smooth handoffs; FIGURE 62 is an event sequence diagram showing the flow of events of an MIP MN handoff from an NSF to an FA, wherein the FA supports smooth handoffs; and 10 FIGURE 63 is an event sequence diagram showing the flow of events of an MIP MN handoff from an FA to an NSF, wherein the FA supports smooth handoffs. DETAILED DESCRIPTION In the following discussion, numerous specific 15 details are set forth to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention may be practiced without such specific details. In other instances, well-known elements have been illustrated in 20 schematic or block diagram form in order not to obscure the present invention in unnecessary detail. Additionally, for the most part, details concerning telecommunication networks, the InterWorking of networks with legacy networks such as the PSTN, and the like, have 25 been omitted inasmuch as such details are not necessary to obtain a complete understanding of the present invention and are within the skills of persons of ordinary skill in the relevant art. It is noted that RFC documents referenced herein are 30 available from the IETF, including the IETF Internet web page located at http://www.ietf.org. All references to WO 01/19050 PCT/IBOO/01553 12 Layer 2 (L2) and Layer 3 (L3) are made in accordance with the Open System Interconnection (OSI) Reference Model defined by the International Standard Organization (ISO), and are considered to be well-known to those skilled in 5 the art. It is further noted that, unless indicated otherwise, all functions described herein are performed by a processor such as computer or electronic data processor in accordance with code such as computer 10 program code or software or Integrated Circuits that are coded to perform certain functions. In addition to the following discussion and description, details of the present invention are further described and disclosed in an Appendix, entitled Base 15 Protocol Specifications, which is attached herewith and hereby incorporated by reference. 1. ACRONYMS AND DEFINITIONS 1.1 ACRONYMS In the interest of conciseness, various components 20 are referred to herein by the following acronyms: AAA Authentication, Authorization, and Accounting ANI Access Network Interface BCCH Broadcast Control Channel CA Certificate Authority 25 C/GOS Class/Grade of Service CN Correspondent Node COA Care Of Address (RFC 2002) COPS Common Open Policy Service DAP Directory Access Protocol 30 DHCP Dynamic Host Configuration Protocol DHCS Dynamic Host Configuration Services WO 01/19050 PCT/IBOO/01553 13 DDNS Dynamic Domain Name Services DNS Domain Name Server ESP Encapsulating Security Payload FA Foreign Agent 5 GSM Global System for Mobile Communications HCDM Home Control and Data Manager HLR Home Location Register HMM Home Mobility Manager IETF Internet Engineering Task Force 10 IP Internet Protocol IPM IP Mobility IPSec IP Security ISAKMP Internet Security Associations and Key Management Protocol 15 ISC IPM Security Center ITS IPM Tunnel Service ITU International Telecommunications Union LAN Local Area Network L2 Layer 2 20 L2TP Layer 2 Tunneling Protocol LDAP Lightweight Directory Access Protocol LSF Local Service Function MIP Mobile IP MN Mobile Node (also referred to as a mobile 25 station or a mobile user) NAC North American Cellular NAI Network Access Identifier NAT Network Address Translator NG Next Generation 30 NSF Network Service Function PSTN Public Switched Telephone Network WO 01/19050 PCT/IBOO/01553 14 QoS Quality of Service RAN Radio Access Network SA Security Association SCDM Serving Control and Data Manager 5 SLA Service Level Agreement SMG Security Messaging Gateway SMM Serving Mobility Manager SOHO Small Office Home Office TCP Transmission Control Protocol 10 UDS Unified Directory Service VLR Visitor Location Register WAN Wide Area Network xAN x(any type) of Access Network 1.2 DEFINITIONS 15 In the interest of conciseness, various components are referred to herein by the following defined terms: An "Access Network Interface" .(ANI) is the logical entity that indicates the existence of an SMM to the mobile user. ANI preferably also implements mechanisms 20 to implement the response to a solicitation and supports handoffs between itself and another ANI within the context of the same SMM. The deployment options for the ANI are very flexible. The ANI may reside in the context of the same LSF or reside outside the LSF in an access 25 network. A "Home Mobility Manager" "HMM" is the logical entity that manages and tracks a users state in the NSF by implementing the IPM protocol state machine. The HMM updates the user's current point of attachment into the 30 UDS and interfaces with the ISC to validate a user's security requirements. The HMM interfaces with the ANI WO 01/19050 PCT/IBOO/01553 15 and ITS at the home domain such that a subscriber may be serviced at home. The HMM supports both IPM clients as well as pure MIP (per RFC2002) clients. A "home network" for a user is defined herein as a 5 network, such as an LSF, an NSF, or a combination thereof, owned by a common administrative domain, with which a user has subscribed his services. A home network thus owns the user's subscription, and is responsible for authenticating and registering its users. 10 "Devices" include a mobile node, a mobile station, a cell phone, a Personal Digital Assistant (PDA), a personal computer (including a laptop computer), and the like. Devices are preferably addressed by IPv4/IPv6 addresses. Local device addresses (e.g. IEEE MAC, MIN, 15 IMSI) preferably are specific to an access network, and are transparent to IPM. Devices may support their own L2 access protocols. "IPM Tunnel Service" (ITS) provides basic IP-in-IP tunneling and de-tunneling functions that are required to 20 support mobility, as discussed in RFC 2003. It also provides gratuitous ARP and proxy ARP functions as needed by the SMM and HMM for mobility management so that IP packets may be routed to an appropriate COA of the MN. "Location updating" tracks the location of a device, 25 and of a user also when the user is using the device. Location updating also updates the network databases as a user moves with the device so that the network is able to route information to the user. The location updates may be done automatically based on policies defined by a 30 service provider (such as America Online, AOL), e.g. on initial registration, and the like.

WO 01/19050 PCT/IBOO/01553 16 "Mobile Node" (MN) and refers to a mobile station, a cell phone, a device, a personal digital assistant (PDA), a personal computer (including a laptop computer), and the like. The MN preferably includes an IP mobility 5 client with dual mode behavior which interpret IP Mobility as well as IETF Mobile IP messaging (as per RFC 2002). The MN preferably supports signaling and dataflow arbitration between multiple access. interfaces and implements an IPM state machine. The MN preferably 10 maintains Security Associations (SA) with a home network as identified by the user's NAI or permanent IP address (if in a Mobile IP serving domain). In the case of a user's NAI, the IPM client may support dynamic allocation of IP address either at the home network or at the 15 visited network. An MN node may also support handoffs between LSFs. MNs are also provided with IP stacks and all service applications are data oriented to accommodate end-to-end IP packet data. "Mobility" refers to user location tracking, 20 handoff, and routing management functions to deliver data to the user, and generally includes personal mobility, device mobility, and service mobility. "Mobility enabled IP centric networks" refers to networks that use IP addressing and routing protocols in 25 concert with a mobility protocol to deliver multimedia traffic to roaming users. The term "users" includes "subscribers". "Registration" binds a user (or a user's persona) to one or more devices.

WO 01/19050 PCT/IBOO/01553 17 "Routing management" refers to the ability to deliver datagrams from a host on a network to a roaming user's MN. A "Secure Messaging Gateway" (SMG) supports IETF AAA 5 requirements and routes all IPM messages between an LSF and NSF. The SMG also provides a secure tunnel for signaling messages between an NSF and LSF. A "Serving Mobility Manager" (SMM) preferably tracks the user state and protocol state of a user in an LSF. 10 From a signaling perspective, the SMM supports user authentication, security, and billing functions. The SMM directs enforcement of the tunnel endpoints and provides support for dynamic configuration mechanisms. The SMM supports both IPM clients as well as pure MIP (per RFC 15 2002) clients. An "xAN" denotes any type of access network, including both wireless (e.g., RAN and GSM), wireline access networks (e.g., PSTN, IP Network, and DSL) and IEEE 802 LANs such as IEEE 802.3 Eithernet LAN and 802.11 20 Wireless LAN. 2. IPM ARCHITECTURE FRAMEWORK The IPM Architecture of the present invention is discussed below in terms of functional components, interfaces, and messaging required to provide mobility. 25 2.1 MOBILITY ENABLED NETWORK REFERENCE MODEL(S) Referring to FIGURE 1 of the drawings, the reference numeral 100 generally designates an IPM Architecture embodying features of the present invention. The IPM Architecture 100 includes a single network 102 shown in 30 dashed outline, which is owned and administered by a single service provider. The single network 102 includes WO 01/19050 PCT/IBOO/01553 18 a Network Service Function (NSF) 104 and at least one Local Service Function (LSF) 106, interconnected together using conventional means, such as wires or wireless Radio Frequency (RF) interfaces or the like. One or more x 5 Access Networks (xAN) 110 are connected to respective LSFs 106, and one or more Mobile Nodes (MNs) 112 are connected to respective xANs 110. Also shown are a user 114 interfacing with an MN 112, and a Correspondent Node (CN, discussed further below) 116 connected to the IP 10 network, though the CN 116 may alternatively be connected to other points in the IPM Architecture 100, such as at an xAN 110. Each LSF 106 constitutes a serving area network for a group of xANs 110, and is owned by the network operator 15 and is delimited by geographical parameters. Each LSF 106 may also support multiple xANs 110 where each xAN 110 is associated with a different technology, e.g. one xAN may be associated with an NAC wireless access network, another xAN may be associated with a GSM wireless access 20 network, and yet another xAN may be associated with an Ethernet enterprise network. Each LSF 106 is configured for receiving messages from an MN 112 via a respective xAN 110 and forwarding such message to a suitable NSF 104 or the IP Network 108. The LSF 106 also provides a 25 mobility manager (discussed further below) for user mobility across the xANs 110 that it serves. Each LSF 106 also routes data to the MN 112 via the IP address that the MN 112 is currently.using. Each LSF 106 also supports access to multiple NSFs 104 from the same MN 30 112.

WO 01/19050 PCT/IBOO/01553 19 The NSF 104 constitutes a home network that owns the subscription associated with the MN 112. The NSF 104 is a user subscription "defined" entity. In the context of the IPM Architecture 100, the NSF 104 is the home network 5 and "owns" the MN user's subscription and associated profile. The NSF 104 also supports a "unified" directory (discussed below) for user profiles and policies independent of the type of xAN 110. The NSF 104 also provides mobility to users 114 on a larger scale. The 10 user can roam into any LSF 106 and the handling of the mobility is achieved by the NSF 104. A Home Mobility Manager entity (HMM, discussed below) in the NSF 104 is responsible for maintaining the current location of the MN 112 of the user 114. The NSF 104 also provides 15 routing information to anyone requesting establishment of communications with the MN 112. The NSF 104 may also provide the Authentication and Authorization functions (discussed below) for MNs 112 that consider the NSF 104 to be their home network. 20 The xAN 110 denotes any type of access (e.g., wireless or wireline) technology. In the context of the IPM Architecture 100, the xAN 110 preferably provides access network resource management, physical connectivity to the MN 112, and local MN mobility within the xAN 110. 25 The IP Network 108 provides a routing backbone for delivering packets between network elements. The IP network 108 may be the public Internet or a closed network that can access the public Internet. A service provider's network may logically be 30 composed of a single NSF 104 with multiple LSFs 106 to which it provides home network functionality. Such LSFs WO 01/19050 PCT/IB00/01553 20 106 may be physically (i.e., geographically) located anywhere. MNs 112 that are homed in the NSF 104 can roam in any of the LSFs 106 that are associated with this NSF and be considered to be in their home network. 5 FIGURE 2 illustrates a network 200 similar to the IPM Architecture 100 described above with respect to FIGURE 1, comprising the single network 102 interconnected with the IP network 108, and further comprising an integrated network 202 interconnected via 10 the IP network 108 to the single network 102. The integrated network 202 performs the functions of both the NSF and the LSF, thereby providing both access and home network functions to a group of MNs 110. 2.1.1 HOME NETWORKS AND VISITED NETWORKS 15 As defined above, and from a user's perspective, a Home Network is the network, e.-g., an ISP, that owns a user's subscription. The home network is, furthermore, responsible for authenticating and registering a user. When a user roams into and accesses a network that 20 is not part of his/her home network, the user is said to be roaming into a visited network. The network that the user is currently using is referred to herein as a serving network. The serving network may be either the home network or a visited 25 network. FIGURE 3 depicts a IPM Architecture 300 similar to the IPM Architecture 100 (FIG. 1) which more clearly distinguishes the foregoing differences between a home network and a visited network. Accordingly, in the 30 network 300, the NSF 104A and an NSF 104B constitute a home network 302, one or more LSFs 106 constitute a WO 01/19050 PCT/IBOO/01553 21 visited network 304, and the IP network 108 interconnecting the NSFs 104A and 104B to the LSFs 106 constitutes a backbone network 306. The user 114's home NSF is the NSF 104B, and a service level agreement (SLA) 5 is established between the NSFs 104A and 104B, thereby permitting the user 112 with his/her MN 112 to roam in the network of NSF 104A. When roaming in the NSF 104A, via an xAN 110 and an LSF 106, the NSF 104A is considered in FIG. 3 to be a visited network since the user 114 is 10 not homed in NSF 104A. The NSF 104A in FIG. 3 is also referred to as a "serving network" since it provides network access to the roaming user. 2.1.2 NSF AND LSF COMPONENTS FIGURES 4A and 4B depict a high-level overview of 15 the architectural mobility components, discussed below, preferably included within an NSF, LSF, and xAN, represented herein by the NSF 104, the LSF 106, and the xAN 110, respectively, in accordance with the present invention. A number of such mobility components are used 20 to support at least two types of xAN applications, namely, LAN and WAN applications, for each NSF 104, LSF 106, and xAN 110. As shown in FIGS. 4A and 4B, the NSF 104 includes a bus 400 for interconnecting LAN and WAN mobility 25 components that constitute the NSF 104. LAN components interconnected to the bus 400 within the NSF 104 include a billing component 402 and a policy component 404. WAN components interconnected to the bus 400 within the NSF 104 include a server farm 406, a service management 30 component 408, and a desktop management component 410. The components 402, 404, 406, 408, 410 are considered to WO 01/19050 PCT/IBOO/01553 22 be well-known in the art and will, therefore, not be discussed in further detail herein, except insofar as necessary to describe the present invention. The NSF 104 further includes a Secure Messaging Gateway (SMG) 454, 5 discussed further below, through which the NSF 104 is connected to the IP Network 108 and, through the IP Network 108, to an Accounting Service Bureau 470 and to a Service Agreement Broker 472. The bureau 470 and broker 472 are considered to be well-known in the art and, 10 therefore, will not be discussed in further detail herein, except insofar as relevant to the description of the present invention. As further shown in FIGS. 4A and 4B, the LSF 106 includes a bus 411 for interconnecting LAN and WAN 15 mobility components that constitute the LSF 106. LAN components interconnected to the bus 411 within the LSF 106 include a policy component 412, a server farm 414, a VPN Proxy firewall 416, an OA&M component 418, an SS7/PTI gateway 420, and a voice gateway 422. WAN components 20 interconnected to the bus 411 within the LSF 106 include a local services component 424, a DDNS 426, a router switch 428, a billing component 432, a gateway call manager 433, and a call manager proxy 434 for providing. The components 412, 414, 416, 418, 420, 422, 424, 426, 25 428, 432, 433, and 434 are considered to be well-known in the art and will, therefore, not be discussed in further detail herein, except insofar as necessary to describe the present invention. The LSF 104 further includes an SMG 466, discussed further below, through which the LSF 30 106 is connected to the bus 400 of the NSF 104 and to the IP Network 108 and, through the IP Network 108, to the WO 01/19050 PCT/IBOO/01553 23 Accounting Service Bureau 470 and to the Service Agreement Broker 472. The LSF 106 is further connected via the SS7/PRI Gateway 420 and the Voice Gateway 422 to the Public Switched Telephone Network (PSTN) 474. 5 As still further shown in FIGS. 4A and 4B, the xAN 110 includes a bus 435 for interconnecting LAN and WAN mobility components that constitute the xAN 110. LAN components interconnected to the bus 435 within the xAN 110 include an RF Management component 436, a Location 10 Tracking component 438, an ARP component 440, a router switch 442, an Access Control component 444, and a Connect Control component 446. WAN components interconnected to the bus 435 within the xAN 110 include a one or more Cellsite Interfaces 448 which interface 15 with cellsites 449, such as MNs 112. The components 436, 438, 440, 442, 444, 446, and 448 are considered to be well-known in the art and will, therefore, not be discussed in further detail herein, except insofar as necessary to describe the present invention. The xAN 110 20 is connected to the LSF 106 via Router Switches 428 and 442. 2.1.2.lNSF COMPONENTS As shown in FIG. 4B, the NSF 104 also includes an AAA function 450 configured for distributing requests for 25 authentication, authorization, and the like, for MNs 112 that are homed in their network using suitable servers dedicated to those tasks. Specifically, with reference to FIGURE 4E, the AAA function 450 includes an AAA routing function 450a, an authentication function 450b, 30 an authorization function 450c, an accounting function 450d, and a security function 450e interconnected via a WO 01/19050 PCT/IBOO/01553 24 bus 450f, which is connected to the bus 400. The AAA function 450 and the functions contained therein are considered to be well-known in the art and, therefore, will not be discussed in further detail herein, except 5 insofar as necessary to describe the present invention. The NSF 104 further includes a Home Mobility Manager (HMM) function 452 which constitutes the mobility component in the NSF. As shown in FIGURE 4C, the HMM function 452 includes an Access Network Interface (ANI) 10 452a, an HMM 452b, and an IPM Tunneling Service (ITS) 452c interconnected via a bus 452d, which is connected to the bus 400. The HMM function 452 interfaces to the AAA function 450 in the NSF 104. The AAA function 450 preferably includes mobility extensions that are used to 15 exchange mobility related control messages with the LSFs 106. Communications between an LSF 106 Serving Mobility Manager (SMM, discussed further below) and the HMM function 452 are effected by configuring multiple AAA functions 450 to serve as peer-to-peer components. The 20 HMM function 452 is preferably configured for maintaining current location information regarding the movement of MNs 112 within different LSFs 106, assigning an IP address to a user's MN 112, forwarding datagrams to MNs 112 if policies are suitably set, binding users to MN's 25 (e.g., devices), binding MNs to IP COAs, and sending COA updates to Correspondent Nodes (CNs) that the user is currently communicating with. CNs include any user nodes, whether mobile or fixed, that are connected to the IPM Architecture. 30 A Secure Messaging Gateway (SMG) 454 is provided for protecting the NSF 104 from the public IP network 108.

WO 01/19050 PCT/IBOO/01553 25 Policies are defined for the SMG 454 to filter incoming and outgoing traffic. As discussed further below, the NSF 104 also utilizes a DNS 456 (including a dynamic DNS function), a 5 DHCP 458, and a Unified Directory Service (UDS) subsystem 460 for providing IP address management, mobility management, and policy management. Services are provided to users by application servers, such as the Server Farm 406, the Server Management component 408, and the Desktop 10 Management component 410 on the NSF 104, and the Server Farm 414 and Local Services 424 on the LSF 106. 2.1.2.2 LSF COMPONENTS As discussed above, the LSF 106 provides access to the NSF 104 for a group of xANs 110. The LSF 106 15 preferably also provides local mobility management, i.e. management of the mobility of MNs 112 within the xAN 110, and across xANs and LSF boundaries that it serves, as discussed further below. As depicted in FIG. 4B, the LSF 106 preferably 20 includes a local AAA function 462 that supports Authentication, Authorization, Accounting (AAA), and mobility functions by routing messages to appropriate AAA function 450 that resides on the NSF 104. Specifically, with reference to FIGURE 4F, the AAA function 462 25 includes an AAA routing function 462a, an authentication function 462b, an authorization function 462c, an accounting function 462d, and a security function 462e interconnected via a bus 462d, which is connected to the bus 411. The AAA function 462 and the functions 30 contained therein are considered to be well-known in the art and, therefore, will not be discussed in further WO 01/19050 PCT/IBOO/01553 26 detail herein, except insofar as necessary to describe the present invention. When a user 114 accesses an LSF 106, the local AAA function 462 contacts the user's home NSF AAA function 5 450. An AAA routing function 450a (FIG. 4E) within the home AAA function 450 forwards requests to an appropriate function, e.g., authentication requests are forwarded to an authentication function 450b (FIG. 4E), and mobility requests are forwarded to the HMM function 452. The LSF 10 local AAA function 462 and the NSF AAA function 450 communicate over a secure link to transmit AAA data. The LSF 106 includes a Serving Mobility Manager (SMM) function 464 that handles mobility management for MNs 112 as they roam between different xANs 110 that are 15 served by the LSF 106. As shown in FIGURE 4D, the SCDM 464 includes an Access Network Interface (ANI) 464a, an SMM 464b, and an IPM Tunneling Service (ITS) 464c interconnected via a bus 464d, which is connected to the bus 411. The point of connection between the MNs 112 and 20 the NSF 104 may remain the same from an NSF perspective. The LSF 106 may hide the actual access network point of attachment of the MN 112 from the NSF 104. This is achieved using a set of ANIs between the LSF 106 and the xANs 110, as described further below with respect to 25 FIG. 14. The LSF 106 also supports access to multiple different NSFs 104 from the same MN 112. Each NSF 104 access is associated with a different Network Access Identifier (NAI, discussed below) since the subscriptions owned by a an NSF 104 are unique across NSFs. 30 The SCDM 464 interfaces with the xAN 110 from an access network perspective and to an HCDM 452, discussed WO 01/19050 PCT/IBOO/01553 27 above, from a core network perspective. The SCDM 464 is preferably configured for registering users, managing handoffs between xANs and LSFs, providing care-of addresses (COA, defined in RFC 2002) for tunnel datagrams 5 to the user's MN 112, user location tracking, and providing an interface to networks that support Mobile IP. The LSF 106 is protected and secured from the Internet by a Secure Messaging Gateway (SMG) 466. All 10 inbound and outbound data must flow through the SMG 466. Policies are defined in the LSF 106 that protect the LSF 106 resources from the MNs 112. The LSF 106 includes Dynamic Host Configuration Protocol (DHCP) 468 for providing MN 112 home addresses. 15 Local directory servers, discussed below, may be used to store policies related to the LSF 106, user MN location, and the like. These components may be available locally in the LSF or may be located centrally elsewhere in the network and serve a set of LSFs 106. The LSF 106 may 20 also include the DNS 426 with the Dynamic DNS function (discussed below). It is noted that the NSF 104 and LSF 106 may be integrated together to form the integrated network 202 (FIG. 2) and, when so integrated, only require one of 25 each of the foregoing components to perform the appropriate roles based on their association with an MN 112. 2.1.2.3 DYNAMIC HOST CONFIGURATION SERVICE (DHCS) AND DYNAMIC DOMAIN NAME SERVICES (DDNS) 30 FIGURE 5 is a schematic diagram showing a portion of the IPM architecture framework 500 as providing DHCP WO 01/19050 PCT/IBOO/01553 28 servers 458 and 468 for allocating network resources. DHCS enables devices to automatically obtain configuration parameters they need to participate in Intranet and Internet communications. Because any CN 5 requires a unique IP address and an appropriate subnet mask, a DHCP is used to effectively automate the task of coordinating and assigning IP address information. The DHCP server 458 interacts with the DNS servers 456 and 468 in coordination with the HMM 456 and SMM 464, 10 respectively, to update the current IP address assigned to an MN 112. While the DHCP servers 458 and 468 both use DHCP and reside in the NSF 104 and the LSF 106, respectively, the DHCP servers have different functions. In the NSF 104, 15 the DHCP server 458 may be used to assign temporary IP addresses to roaming MNs 112 that do not have pre configured IP addresses, or that request IP addresses. In the LSF 106, the DHCP server 468 may be used to assign co-located COAs, in addition to MN 112 home address, to 20 the MN 112 that accesses the serving network, such as LSF 106. The DHCP servers 458 and 468 may also use DHCP to configure the MN 112 with other parameters such as identification of the NTP server, the NNTP server, and 25 the like. FIGURE 5 also shows a portion of the IPM Architecture 400 providing a DDNS function using the DNS components 456 and 426 which support the HCDM 452 and SCDM 464, respectively. At the LSF 106 and at the NSF 30 104, the DDNS is a protocol used to update the DNS 426 WO 01/19050 PCT/IBOO/01553 29 and 456 respetviely with the MN's IP address allocated by DHCP 468 and 458. FIGURE 5A is a flow which depicts the operation of the DDNS. Accordingly, when an MN 112 registers with an 5 LSF 106, in step 502 the HMM/SMM send a message to the DHCP 458 or 468 (which DHCP is only accessible by the HMM/SMM) requesting the IP Address of an attached NAI. In step 504, the DHCP allocates the IP address of the NAI and, in step 506, transmits the IP address (which may be 10 public or private IP address) to the DNS in accordance with DDNS protocol. In step 508, the DHCP transmits the IP address to the requesting HMM/SMM and, in step 510, the HMM/SMM receives the IP Address. In step 511, the HMM/SMM thus proxies the address management on behalf of 15 the MN and renews the lease time of the address of each IPM re-registration. At de-registration of the MN 112, the IP Address is released, as described in step 511. In step 512, the DNS stores the IP Address. In step 514, a CN sends a message to the DNS requesting the IP 20 address of the NAI. In step 516, the DNS looks up the IP address and, in step 518, transmits the IP address to the requesting IP Address to the requesting CN. In step 520, the CN receives the IP Address. If the user 112 of the MN 114 is roaming, then the 25 DDNS protocol is used to update the DNS 426 and/or DNS 456 with the COA of the MN 114. The HMM 452B interacts with the DNS server 456 to keep the MN's COA current. DNS servers 426 similar to the DNS server 456 may reside in the LSF 106 and SMM 464 will update the DNS 30 server 456 with the COA of the MN 112 during the initial Registration of the user 114 with the MN 112.

WO 01/19050 PCT/IB00/01553 30 The DNS server 456 at the LSF 106 may also have a reference (in its look-up table against the user 114's NAI) to the DNS server 426 -at the NSF 104. In that case, any DNS query initiated against the user 114's NAI at the 5 LSF 106 is redirected to the DNS server 426 at the NSF 104. The DNS server 426 at the NSF 104 then provides the COA of the MN 112. The DNS server 426 at the NSF 104 may have a reference (in its look-up table against the user 114's 10 NAI) to the DNS server 456 at the LSF 106. In that case, any DNS query initiated against the user 114's NAI at the NSF 104 is redirected to the DNS server 456 at the LSF 106. The DNS server 456 at the LSF 106 then provides the COA of the MN 112. 15 Figure 5B is a flow that depicts an operation of the DNS that stores the COA of the MN. Accordingly, in step 530, the HMM and/or SMM sends a message to DNS 456 and/or DNS 426 store the MN 112's COA against the user 114's NAI. In step 532, the NSF DNS 456 and/or LSF DNS 426 20 stores the MN 112's COA against the user 114's NAI. In step 534, the CN 116 sends a message with the user 114's NAI to the NSF DNS 456 and/or LSF DNS 426 requesting the COA of the MN 112. In step 536, the NSF DNS 456 and/or LSF DNS 426 look up the MN 112's COA. In step 538, the 25 NSF DNS 456 and/or LSF DNS 426 transmits the COA of the MN 112 to the CN 116. And finally, in step 540, the CN 116 receives the COA of the MN 112. Figure 5C is a flow that depicts an operation of the DNS 426 that stores the NAI of the user 114 against the 30 reference of the DNS 456. Accordingly, in step 550, the HMM 452 sends a message to NSF DNS 456 to store the COA WO 01/19050 PCT/IBOO/01553 31 of the MN 112 against the NAI of the user 114. In step 552, the NSF DNS 456 stores the COA of MN 112 against the NAI of the user 114 in a look-up table. In step 553, the HMM 452 sends a message to SMM 464 to initiate storing 5 the reference of the DNS 456 aginst the NAI of the user 114. In step 554, the SMM 464 sends a message to LSF DNS 426 to store the reference of the NSF DNS 456 against the NAI of the user 114. In step 556, the LSF DNS 426 stores the reference of the NSF DNS 456 against the NAI of the 10 user 114 in a look-up table. In step 558, the CN 116 sends a message with the user 114's NAI to the LSF DNS 426 requesting the COA of the MN 112. In step 560, the LSF DNS 426 looks up the reference of the NSF DNS 456 and sends a message to NSF DNS 456 with the NAI of the user 15 114 requesting the COA of the MN 112. In step 562, the NSF DNS 456 transmits the COA of the MN 112 to the LSF DNS 426. In step 564, the LSF DNS 426 receives the COA of the MN 112 and then the LSF DNS 426 transmits the COA of the MN 112 to the CN 116. In step 566, the CN 116 20 receives the COA of the MN 112. Figure 5D is a flow that depicts an operation of the NSF DNS 456 that stores the NAI of the user 114 against the reference of the LSF DNS 426. Accordingly, in step 570, the SMM 464 sends a message to LSF DNS 426 to store 25 the COA of the MN 112 against the NAI of the user 114. In step 572, the NSF DNS 426 stores the COA of MN 112 against the NAI of the user 114 in a look-up table. In step 573, the SMM 464 sends a message to HMM 452 to initiate storing the reference of the LSF DNS 426 aginst 30 the NAI of the user 114. In step 574, the HMM 452 sends a message to NSF DNS 456 to store the reference of the LSF WO 01/19050 PCT/IBOO/01553 32 DNS 426 against the NAI of the user 114. In step 576, the NSF DNS 456 stores the reference of the LSF DNS 426 against the NAI of the user 114 in a look-up table. In step 578, the CN 116 sends a message with the user 114's 5 NAI to the NSF DNS 456 requesting the COA of the MN 112. In step 580, the NSF DNS 456 looks up the reference of the LSF DNS 426 and sends a message to LSF DNS 426 with the NAI of the user 114 requesting the COA of the MN 112. In step 582, the LSF DNS 426 transmits the COA of the MN 10 112 to the NSF DNS 456. In step 584, the NSF DNS 456 receives the COA of the MN 112 and then the NSF DNS 456 transmits the COA of the MN 112 to the CN 116. In step 586, the CN 116 receives the COA of the MN 112. 2.1.2.4 UNIFIED AND LOCAL DIRECTORY SERVICES 15 Each NSF 104 and each integrated LSF/NSF 202 includes a Unified Directory Service (UDS) subsystem, and each LSF includes a Local Directory Service (LDS) subsystem. Referring to FIGS. 4A and 4B, each UDS subsystem is based on a Client-Server architecture and 20 comprises a UDS server 460, a UDS database 461, and *a number of UDS clients, such as the mobility manager 452, the billing component 402, the policy server 404, the server farm 406, the service manager 408, the desktop manager 410, and the AAA function 450 interconnected via 25 the bus 400. Each LDS subsystem is also based on a Client-Server architecture and comprises an LDS server 430, an LDS database 431, and a number of LDS clients, such as the policy server 412, the AAA function 462, the mobility manager 464, the server farm and local services 30 414, the OA&M component 418, and the billing component 431 interconnected via the bus 435.

WO 01/19050 PCT/IBOO/01553 33 The UDS subsystem and the LDS subsystem serve similar functions, though at different levels of breadth. For example, a UDS subsystem for a particular network service provider (e.g., ATTm, GTEm, AOLm) represented by 5 the NSF 104 or a integrated LSF/NSF 202, maintains information in databases (discussed below) for all users 112 of mobile and fixed nodes and for all networks who subscribe to services provided by, or who provide services to, the particular network service provider. 10 Each respective LDS subsystem maintains information in databases (discussed below) only for users 112 of mobile and fixed nodes and for networks who are connected via RANs or xANs 110 to a respective LSF 106. As discussed further below, the information maintained in the UDS and 15 LDS databases 431 and 461 includes, for example, user profiles ("unified" in the sense that they ar.e independent of the xAN 110 serving the user 112), user policies, network usage, network policies, security policies, and information related to availability of 20 services and their location. Because the functionality of the UDS subsystem and the LDS subsystem are substantially similar, that functionality will be described representatively herein with respect primarily to the UDS subsystem, and more 25 specifically, with respect to the UDS subsystem of the integrated LSF/NSF 202, as representative of the NSF 104 and LSF 106 as well. Accordingly, FIGURE 6 depicts an integrated LSF/NSF 202 as comprising a UDS subsystem having a UDS server 460, and two UDS databases 461 30 connected to the UDS server 460. It is understood that, WO 01/19050 PCT/IBOO/01553 34 while only two databases 461 are shown, one or more such databases may be connected to the UDS server 460. UDS client software is installed in each LSF/NSF 202 component, and each LSF/NSF Server or Manager interfaces 5 with the UDS server 460 through the UDS client. Details of the operation of the UDS server are thereby hidden from the respective NSF/LSF Server or Manager hosting the UDS Client. For example, an LSF/NSF component may utilize a Lightweight Directory Access Protocol (LDAP) 10 Client which would hide the details of Client/Server protocol from the UDS Client. The UDS Server 460 is associated with the LSF/NSF 202 for enforcing a common information model for NSF components that access the UDS subsystem 460. The common 15 information model is a schema for each Directory Information Tree (DIT), discussed further below with respect to FIGURE 6D. The schema identifies object classes, such as "ipmUser", and attributes that may comprise a directory entry into the UDS database 461. 20 The schema also lists attributes that an entry with an object class of "ipmUser" must have (e.g., a common name) and those attributes that an entry of object class "ipmUser" may, but is not required to, have (e.g. naiUser). The attributes are discussed in greater detail 25 below with respect to FIGS. 6E-6L. The UDS Server 460 incorporates UDS clients that interface to UDS databases 461 where data is physically stored. The one or more UDS Databases 461 are utilized to physically store information. The interface between the 30 UDS Server 460 and a given UDS database 461 may be proprietary or standards-based. The physical WO 01/19050 PCT/IBOO/01553 35 organization of the data is hidden from the NSF 104 components that interface with the UDS subsystem. The term "schema" is used herein to describe a type of data that may be included in the UDS subsystem. The 5 schema includes object classes and attributes that may be used to meet most UDS server 461 requirements. An object class defines a collection of attributes that may be used to define an entry, and provides a convenient way for a UDS-client to retrieve a subset of data entries during a 10 search operation to provide for a particular service. Object classes generally define a set of required and optional attributes. Attributes contain information about a specific descriptive aspect of an entry, and each attribute consists of an attribute type and value, as are 15 discussed in greater detail below with respect to FIGS. 6E-6L. FIGURE 6A is a schema relationship diagram which specifies a preferred relationship between object classes utilized by the UDS subsystem (as well as the LDS 20 subsystem) in accordance with the present invention. As shown, the UDS subsystem includes eight object classes, namely, an ipmUser object class 620, an ipmUserDevice object class 622, an ipmUserProfile object class 624, an ipmClassOfService object class 626, an ipmLsfDomain 25 object class 628, an ipnLsfSubnet object class 630, an ipmNsfSubnet object class 632, and an ipmLsfSubnet object class 634, described in further detail below. The schema relationship diagram of FIG. 6A is depicted utilizing conventional database drawing 30 techniques that are considered to be well-known in the art. Accordingly, the number "1" indicates one object WO 01/19050 PCT/IBOO/01553 36 class, "1. .*" indicates one or more object classes, and "0..*" indicates zero or more object classes. For example, the ipmUser object class 620 may be related to zero or one or more ipmUserDevice object classes 622, and 5 the ipmUserDevice object classes 622 must be related to one or more ipmUser object classes 620. The attributes of each object class are described below. FIGURE 6B depicts a class inheritance tree which specifies a preferred hierarchy of the object classes 10 620, 622, 624, and 626 described above with respect to FIG. 6A, and identifies preferred attributes associated with each object class. Notably, the ipmUser object class 620 is an auxiliary object class, indicating that it is common to all sub-trees. Also depicted are a group 15 640 of four object classes well-known in the prior art, namely, a top object class 642, a person object class 644, an organizationperson class 646, and an inetOrgPerson object class 648. Because the object classes 642, 64, 646, and 648 contained within the group 20 640 are considered to be well-known they will not be discussed in further detail herein. The object class 620 may inherit, either singly or in any combination, from any of the prior art classes 642, 644, 646, or 648. FIGURE 6C depicts a class inheritance tree which 25 specifies a preferred hierarchy of the object classes 628, 630, 632, and 634 described above with respect to FIG. 6A, and identifies preferred attributes associated with each object class. Notably, the object classes 628, 630, 632, and 634 are auxiliary object classes, 30 indicating that they are common to all sub-trees. Also depicted are a group 650 of two object classes well-known WO 01/19050 PCT/IBOO/01553 37 in the prior art, namely, a top object class 652 and an organizationUnit object class 654. Because the object classes 652 and 654 contained within the group 650 are considered to be well-known, they will not be discussed 5 in further detail herein. The object classes 628, 630, 632, and 634 may be inherit, either singly or any in any combination thereof, from either of the prior art classes 652 and 654. FIGURE 6D depicts a preferred Directory Information 10 Tree (DIT) which shows how sub-directories are organized in the UDS and LDS for storing the object classes 620, 622, 624, 626, 628, 630, 632, 634, and 636 discussed above with respect to FIGS. 6A, 6B, and 6C. Accordingly, all object classes 620, 622, 624, 626, 628, 630, 632, 15 634, and 636 for all users 114 are organized under suitable sub-directories organized under a main IPM management organizational directory 660a. Specifically, the object classes 634 (IPM NSF Domain) and 628 (IPM LSF Domain) for all users 114 are stored under respective 20 sub-directories 634a and 628a, which are organized under the directory 660a. The object classes 632 (IPM NSF Subnet), 620 (IPM User), 622 (IPM User Device), 624 (IPM User Profile), and 626 (IPM Class of Service) for all users 114 are stored under respective sub-directories 25 632a, 620a, 622a, 624a, and 626a, which are organized under the sub-directory 634a. The object class 630 (IPM LSF Subnet) for all users 114 is stored under a sub directory 630a, which is organized under the sub directory 634a. 30 FIGURES 6E, 6F, 6G, 6H, 61, 6J, 6K, and 6L are tables which exemplify attributes preferably associated WO 01/19050 PCT/IBOO/01553 38 with each of the object classes 620, 622, 624, 626, 628, 630, 632, 634, and 636, respectively, discussed above with respect to FIGS. 6A, 6B, 6C, and 6D. Each attribute is defined in the schema as having a given "syntax" 5 (e.g., DirectoryString) and, as indicating whether a respective attribute may only have a single value, or rather may be multi-valued (e.g., an "ipmUser" may have a "userEmail" attribute that has several values for multiple e-mail addresses). Matching Rules are 10 associated with the attribute so that the directory understands how to establish such relationships as "equality" when comparing the values of the attribute from different entries. For example, the matching rule "caseIgnoreString" ignores the case of the characters 15 when comparing strings. The information stored in the UDS database 461 thus includes objects in a network infrastructure, which objects preferably comprise unified user profiles, server locations, applications, hubs, routers, network usage 20 policies, security policies, and information related to availability of services and their location, and the like. The UDS subsystem thus provides structure to complex and heterogeneous networks by enabling access to, and management of, networks, such as home networks 302, 25 visited networks 304, backbone networks 306, xANs 110, and the like. It is noted that the UDS subsystem 602 is preferably based on X.500, an International Telecommunications Union (ITU) standard for directories used in telecommunications. 30 The UDS subsystem also provides an interface to the UDS databases 461. Clients of the UDS subsystem WO 01/19050 PCT/IBOO/01553 39 preferably access the information contained in the UDS databases -461 via a standard access protocol such as Directory Access Protocol (DAP) or Lightweight DAP (LDAP). 5 The UDS database 461 schema, the type of UDS database 461, and storage techniques used by the UDS database 461 are preferably transparent to clients of the UDS database 461. The UDS subsystem receives information requests from clients, and retrieves the requested 10 information from the UDS databases 461. The interface between the UDS server 460 and the databases 461 may be proprietary or based on standards. The UDS server 460 formats information retrieved from the UDS databases 461, and then sends the formatted information back to the UDS 15 client in an appropriate response message, discussed further below. FIGURE 6M is a schematic diagram exemplifying how the UDS database 461 may interface with other components. The UDS database 461 includes a memory 461a configured 20 for storing attributes 461b defining the behavior of a user 114, and for storing services 461c that the user 114 subscribes to. A single interface 461d, preferably an LDAP interface, is provided for provisioning the attributes 461b and services 461c into the UDS database 25 memory 461a. The UDS database 461 further includes one or more interface 461e, preferably LDAP interfaces, configured for enabling the UDS database 461 to interface with other components of a local NSF 104. The UDS database 461 additionally includes one or more interfaces 30 461e, preferably LDAP interfaces, configured for WO 01/19050 PCT/IB00/01553 40 connecting to xANs 110, exemplified as GSM, an IP Network, and DSL, of other network service providers. As discussed in further detail below, the UDS database 461 is operable for providing to the local NSF 5 104 or other service providers via the interfaces 461e and 461f and the xANs 110 user profile information selectively drawn from the attributes 461b for services 461c to which a user subscribes. By the use of the UDS subsystem 602 described 10 herein, a common schema is provided between any number of services, thereby enabling common subscriber management and portability of applicable service data across data types. For example, User Authentication, DNS entries, and QoS may be made common across DSL and UMTS data 15 environments. 2.1.2.5 SECURE MESSAGING GATEWAY The Secure Messaging Gateways (SMGs) 454 and 466 (FIG. 4B) serve both as routers and as firewalls that protect a network by monitoring and filtering incoming 20 and outgoing traffic based on policies defined by administrators of a network, such as the home network 302, the visited network 304, the backbone network 306, the xANs 110, or the like. The SMGs 454 and 466 are located at the edge of the network and protect, for 25 example, an internal network (e.g., the Intranet) from a public network (e.g., the Internet). The SMGs 454 and 466 preferably implement -IPSec to provide secure (e.g., encrypted) communication links between networks. The term "firewall" customarily refers to a 30 collection of hardware, software, and policy that is placed between a private network (e.g., LSF/NSF), and an WO 01/19050 PCT/IBOO/01553 41 external network (e.g., the Internet). Packet filters and application gateways, either individually or in combination, normally constitute a firewall. Various firewall configurations may be set up based on the degree 5 of security required and policies defined. 2.1.3 NETWORK TYPES The IPM Architecture, such as designated by the reference numeral 100 in FIG. 1, will, in accordance with the present invention, support a number of different 10 types of networks. For example, the IPM Architecture 100 will support a Private Network also referred to as an Intranet, which is defined as a network that is protected from a public network, such as the Internet 108 (FIG. 1), by an SMG 454 and 466, or the like, that enforces access 15 restrictions via a predefined set of policies. A private network may use IP addresses, sometimes referred to as public addresses or public IP addresses, which are routable on the public Internet 108. Therefore hosts on the public Internet 108 are able to "directly" 20 address hosts on a private network. An example of this type of network may be a Small Office or Home Office (SOHO). Alternatively, a private network may use IP addresses, sometimes referred to as private addresses or 25 private IP addresses, which are not routable on the public Internet. Hosts on the Internet may not then be able to "directly" address hosts on a private network. The private network can support some type of predefined access setup, e.g. SOCKS (RFC 1928) and tunneling, e.g., 30 Layer 2 Tunneling Protocol (L2TP), IP tunneling, or the like, for sending data into the private network. The WO 01/19050 PCT/IBOO/01553 42 private networks may also use Network Address Translators (NATs) so their hosts may establish connections to hosts on the public Internet. The IPM Architecture of the present invention is 5 preferably configured to also support LSF control plane messaging to a private network's NSF. The IPM Architecture of the present invention is preferably configured to also support Non-Private Networks, defined to be a network that does not restrict 10 access into its network. Hence, all hosts in such a network have routable public Internet IP addresses. The IPM Architecture of the present invention is preferably configured to also support LSF control plane messaging to the non-private network's NSF. 15 The IPM Architecture of the present invention is preferably configured to also support LSFs and NSFs that are non-private networks. Even though an LSF/NSF does not restrict access into the LSF/NSF, they provide a mechanism to allow encrypted data between itself and 20 other networks. The IPM Architecture of the present invention is preferably configured to also support LSFs and NSFs that are private networks with routable IP addresses. The LSF/NSF provides a mechanism to allow encrypted data 25 between itself and other networks. The LSF/NSF also supports connectivity to enterprises, such as a SOHO, that do not 'support encrypted data services. The IPM Architecture of the present invention is preferably configured to also support NSFs that are 30 private networks and have private addresses that are not routable by the general Internet. The most common WO 01/19050 PCT/IBOO/01553 43 scenario for this is when a roaming user wants to perform a service at his home private network. Before a user's service can be established, the user's application must transverse the home network's security messaging gateway. 5 Given the flexibility of the types of networks supported by the mobility architecture framework of the present invention, users roaming within the LSFs are able to connect to a number of different types of home NSF types, such as, for example, private network ISPs that 10 support L2TP, private network ISPs that support IP tunneling, non-private network ISPs, a company's private (or non-private) network, and the like. The IPM Architecture of the present invention is preferably configured to also support Layer 3 tunneling 15 mechanisms between LSFs and NSFs. 2.2 FRAMEWORKS The present invention defines a number of different frameworks for handling various aspects of the IPM Architecture, which frameworks are responsible either 20 directly or indirectly for providing mobility in the core network. The frameworks, discussed below in greater detail, include (1) a User Identity and Network Route Addressing Framework, (2) a Security Framework, (3) an Authentication, Authorization, and Accounting (AAA) 25 Framework, (4) a Mobility Manager Framework, and (5) a Service Mobility Framework. 2.2.1 USER IDENTITY AND NETWORK ROUTE ADDRESSING FRAMEWORK In accordance with the IPM Architecture of the 30 present invention, the linkage between the users 114 and their devices, such as MN 112, is separated by assigning WO 01/19050 PCT/IBOO/01553 44 a unique identity to each user, and by assigning a unique identity to each device. This unique identity of these devices owned by the user 114 is linked to the NAI of the user 114 so that the identity of any of these devices can 5 be linked to the user 114. Furthermore, the unique identity of the device is of the form of NAI which includes attritbutes of both the device and the user. Some examples these unique identities based on NAI are, johndoe.mobilephone@anyserviceprovider.com and 10 johndoe.pager@anyserviceprovider.com. 2.2.1.lUSER IDENTITY A number of standardization methods for uniquely identifying users have been proposed, each with its own advantages and disadvantages. All proposals, though, 15 require that the globally unique user identity must be resident in a "home database" that is accessible by all. Because the network of the present invention is an IP-based network modeled on the Internet, the user name space must be consistent with what already exists within 20 the Internet. Current Internet naming is based on domain names. Accordingly, the IPM Architecture of the present invention supports unique identifiers as specified in the Internet RFC 2486, entitled "The Network Access 25 Identifier" by B. Aboba; July 1998. The network access identifier (NAI) defined in this document is based on Internet domain names. The format of the identifiers is "user@realm" and may be, for example, "John.Doe@ISPxyz". The NAI may be used to identify users and to identify 30 devices, such as routers. The NAI is not an e-mail WO 01/19050 PCT/IBOO/01553 45 address; however, in the most limited sense, an NAI may be a user's actual e-mail address. When a user 112 accesses an LSF 106, the MN 114 sends the user's NAI in the system access message. The 5 NAI is used to access the user's profile in a UDS database 461 or LDS database 431 and to help perform other functions of the LSF 106. There are a number of ways a user 114/MN 112 is able to supply an NAI. The NAI may be on the user's User 10 Identity Module (SIM) card (similar to the SIM card used in GSM), configured in the MN 112, or may have to be input by users 114 when they want to access the LSF 106. 2.2.1.2 NETWORK ROUTE ADDRESSING Since the IPM Architecture is designed to support 15 IP-based networks, network addressing is based on the Internet Protocol (IP) . The IPM Architecture described herein is configured to support both IP version 4 (IPv4) and IP version 6 (IPv6) and is, generally, independent of the IP version. For the sake of illustration, however, 20 routing within the IPM Architecture of the present invention will be described with respect to IPv4. An MN 112 used by a user 114 will terminate (i.e., receive) IP datagrams destined to the user's application that is executing at a CN. To do this, the MN 112 must 25 have an IP address. The IPM Architecture, such as depicted by the reference numeral 100 in FIG. 1, supports two mechanisms for MNs 112 to acquire an IP address. First, an MN 112 may acquire a permanent IP address that is configured at or on the MN 112. Alternatively, an MN 30 112 may acquire an IP address that the IPM Architecture allocates dynamically. It should be noted that, the WO 01/19050 PCT/IBOO/01553 46 expression "MN allocated IP address" is used herein to refer to an MN IP address independent of how the MN actually acquired the IP address. In accordance with the present invention, at least 5 five IP address allocation scenarios may be used either to allocate a permanent IP address that is configured at or on the MN 112, or to dynamically allocate an IP address by the IPM Architecture. In a first scenario, an MN 112 owned by a user 114 is provided with a permanent 10 IP address associated with the user's home network 104B, depicted in FIG. 3. In a second scenario, a user desires to use an MN 112 which is not his/her own MN 112, and which MN 112 has a permanent IP address that is associated with a current point of attachment (associated 15 with a visited LSF 106) . In a third scenario, the user 114 desires to use an MN 112 which is not his/her MN 112, and which MN 112 has a permanent IP address that is not associated with his/her home network or the current point of attachment (associated with the visited LSF 106). In 20 a fourth scenario, the MN 112 owned by the user 114 does not have a permanent IP address and, hence, when the user roams with his/her MN 112, the IPM Architecture will dynamically allocate an IP address. In a fifth scenario, similar to the fourth scenario, the device the user 25 desires to use is an MN 112 which is not his/her MN 112 and which MN 112 does not have a permanent IP address, thereby resulting in a dynamic allocation of an IP address by a network as the user 114 roams with the MN 112 through the network, as discussed above with respect 30 to FIG. 5.

WO 01/19050 PCT/IBOO/01553 47 The IPM Architecture of the present invention enables an MN 112 to use either direct routing or a phenomena known as "triangle routing." Triangle routing is defined to have a data path that always passes through 5 an anchor point between the MN and a host (e.g., a CN) somewhere in the IPM Architecture. The anchor point stays fixed throughout the entire data session irrespective of the MN's movement. In the network of the present invention, the anchor 10 point for the triangle route may be established at either a user's home NSF 104 or at a visited LSF 106, depending on how the user's roaming address is allocated. If the visited LSF 106 is configured to allocate an MN IP Address, the anchor point will be in the visited 15 LSF 106, referred to herein as an anchor LSF 106. This would result from MN allocated IP address of the LSF 106 being updated in the user's home DDNS 456. An advantage of the anchor LSF 106 allocating the IP address is that, as discussed below, a CN may send datagrams directly to 20 the MN 112 via an MN allocated IP address that is topologically correct with the anchor LSF 106. However, there are several issues that must be addressed before a CN may send datagrams directly to the MN 112 via an LSF topologically correct MN allocated IP address. 25 First, as the user 114 roams and registers in new LSFs, each LSF's MN allocated IP address will replace a previous MN allocated IP address in the user's home DDNS 456. This may result in a window through which the CN may acquire a wrong IP address. 30 Second, since a CN's local DDNS 426 ~may cache the previous IP address, the CN applications will not be able WO 01/19050 PCT/IBOO/01553 48 to communicate with the user' s application 414 or 424. This may be overcome by setting the Time To Live (TTL) contained within the record of the home DDNS 456 to zero, indicating that the CN's DDNS should not cache the IP 5 address. When this is done, consideration must be given to the additional capacity/performance that is incurred on the network and the home's DDNS 456 since other DDNSs 456/426 of other NSF and/or LSF networks will not be caching the additional records. 10 Third, when a user 114 initiates a TCP/IP application with a CN on the Internet, the TCP/IP application of the node on the Internet is given the current IP address of the MN 112, which is the IP address allocated by the anchor LSF 106. When the user 114 roams 15 with the MN 112 from the anchor LSF 106 to one or more other LSFs, the Internet node's application data will still be routed to the anchor LSF which will then forward the datagrams through as many LSFs as the user has transversed, incurring more routing hops that datagrams 20 must transverse. Fourth, the preceding issue of incurring additional routing hops is resolved when the user 114's session datagrams are finally terminated, at which time the anchor LSF and any other LSFs in the routing determine 25 when they may "clean up," e.g., return the MN's IP address to the DHCP 468, remove routing information from the memory, and de-allocate all the resources used by the previous session. If the visited MN's home NSF 104, rather than the 30 visited LSF 106, is responsible for allocating the MN IP Address, the anchor point will be in the home NSF 104.

WO 01/19050 PCT/IBOO/01553 49 The advantages of the NSF 104 allocating the IP address are that CNs will always have a correct MN IP. The disadvantage is that a triangle route is created with the user's home NSF 104 serving as the anchor. To alleviate 5 this issue, the IPM Architecture of the present invention provides a mechanism to inform CNs of the LSF's/MN's COA so it can send (tunnel) datagrams directly to the MN 112 of the user 114 and avoid a triangle route. This is discussed in further detail below with respect to the 10 Mobility Manager Framework. If a CN does not have software to support tunneling of datagrams, the IPM Architecture of the present invention supports policies defined at the user's home NSF 106 that allow for defining where the MN IP Address 15 is allocated. For example, such a policy may provide for the home NSF 104 to permit an LSF 106 to allocate MN IP Addresses or, if the home NSF 104 wants to "hide" the location of the roaming user 114, then the home NSF may allocate the MN's IP address. However, the home NSF 104 20 would preferably allocate the MN's IP address. The IPM Architecture of the present invention also supports a policy at the NSF 104 that permits triangle routing. Such policy may be set when the NSF wants to hide the location of a user 114 from CNs. 25 2. 2.1. 3 ROUTING AREA (RA) FIGURE 7 shows Routing Areas (RAs) 702 within the same LSF 704 served by a single SMM 706. The RA 702 is the sub-network point of attachment at the edge of the xAN 708. The format of an RA is a Network Access 30 Identifier (NAI) as defined in RFC 2486. Each xAN 708 is configured to map the NAI to a set of partitions WO 01/19050 PCT/IB00/01553 50 provisioned for the NAI. There may be more than one RA served by a single SMM 706. 2.2.2 SECURITY FRAMEWORK Security is applicable to the control plane, data 5 plane, and management plane of the IPM Architecture. Within the architecture, security is preferably provided to control plane messages, including registration messages, authentication messages, location update messages, and the like. Depending on the application and 10 the policies defined, security is preferably provided at different levels in the data plane. There are a number of security alternatives that are used within conventional wireless and wireline networks. The IPM Architecture of the present invention defines a 15 security framework that consolidates all the alternatives into one framework, as discussed further below. The Internet Engineering Task Force (IETF) security work group has defined a security architecture referred to as IPSec, discussed in further detail in an Internet Draft 20 entitled "Security Architecture for the Internet Protocol", by Steve Kent and Randall Atkinson, July 1998, and has defined the associated protocols and cryptographic algorithms to support it. IPSec affords at least five services. First, a 25 security service referred to as Access Control prevents unauthorized use of a resource. A second service, referred to as Connectionless Integrity, detects modification of an individual datagram, without regard to the ordering of the datagram in a stream of traffic. 30 Third, a security service referred to as Data Origin Authentication, verifies the identity of a claimed source WO 01/19050 PCT/IBOO/01553 51 of data. Fourth, a security service referred to as Replay Protection prevents data from being intercepted and/or for intercepted data to be used at a subsequent time to gain access. Fifth, a security service, referred 5 to as Confidentiality, protects data from unauthorized disclosure. The foregoing five services are considered to be well-known in the art and, therefore, will not be described in further detail herein , except insofar as necessary to describe the present invention. 10 Two protocols have been specified to provide the foregoing five IPSec services. First, a preferred protocol is referred to as Authentication Header (AH) described by R. Atkinson, in an article entitled "IP Authentication Header", RFC 1826, August 1995. Second, 15 an alternative protocol is Encapsulated Security Payload (ESP) described in an article entitled "IP Encapsulating Security Payload" by R. Atkinson, RFC 1827, August 1995. In the architecture framework of the present invention, IPSec is the preferred security architecture because 20 IPSec provides interoperable, high quality, cryptographically based security for IPV4 and IPV6 at the IP layer. Furthermore, IPSec may be used in a many ways to implement VPNs, tunneling, security, and firewall transversals. IPSec is preferably used within the 25 control plane and data plane of the security framework. 2.2.2.1NETWORK SECURITY ASSOCIATIONS FIGURE 8 depicts network security associations within an IPM Architecture 800 of the present invention, comprising an LSF network 106, an NSF network 104, and 30 security messaging gateways (SMGs) 806, and wherein a user is roaming with an MN 114 in a visited LSF 106. As WO 01/19050 PCT/IBOO/01553 52 discussed below, at least five Security Associations (SA) may exist in the context of the IPM Architecture 800. First, an SA may exist as an IPSec SA between SMGs of (1) LSFs and (2) LSFs and NSFs, as exemplified in FIG. 5 8 by an IPSec SA1. For example, an IPSec SAl is shown connected between the SMGs 806 and protects all data that flows between the networks 104 and 106. An SA between SMGs is always in tunnel mode and uses ESP (RFC 2406). As shown in FIG. 8, the LSF network 106 is the network a 10 user MN 112 is currently visiting. The NSF network 104 is the home network for the user 114. The IPSec SAl between the SMGs 806 of the two networks 104 and 106 is preferably set up on a permanent basis, as per a roaming agreement established between the two networks. While 15 FIG. 8 only shows the IPSec SAl as between the LSF 106 and the NSF 104, the IPSec SAl may also exist between multiple LSFs 106. Second, an SA may exist between AAA function functions of two networks. Even though there is security 20 between the LSF 106 and the NSF 104 via the SMGs 806, the respective AAA functions 462 and 450 have their own SAs, depicted in FIG. 2 as IPSec SA2. The IPSec SA2 is setup for end-to-end AH authentication to allow for verifying the networks 106 and 104. However, IPSec SA2 may also 25 employ ESP to provide for data integrity. The IPSec SA2 is preferably set up on a permanent basis, as per a roaming agreement established between the two networks 104 and 106. Third, an IPSec SA3 may be established between the 30 MN 114 and the SMM 464 in the LSF 106. The IPSec SA3 allows for encrypting data via ESP. The IPSec SA3 is WO 01/19050 PCT/IBOO/01553 53 preferred if the access to the network LSF 106 is unsecured (e.g., wireless without encryption or cable modem). Fourth, depending on security policies defined, an 5 IPSec SA4 may be established between the MN 112 and a CN 116, preferably in the data plane. The IPSec SA4 between the MN 112 and the CN 116 that the MN is communicating with protects the traffic between the two entities. It should be noted, though, that the existence or non 10 existence of the IPSec SA4 is transparent to the IPM Architecture. Fifth, depending on the security environment at the LSF 106, the MN 112 may establish an IPSec SA5 with an edge router 816 of the visited LSF network 106 for 15 securing its data path. The IPSec SA5 will ensure secure data transfer between the MN 112 and the edge of the LSF network 106 being accessed. The NSFs 106 preferably have service roaming agreements between one another and hence have security 20 associations established between the SMGs of their respective NSFs and LSFs. For example, in FIGURE 9, where IPSec SAs are designated schematically by dashed lines with arrows, the NSF 104 may have an SA with the LSFs of the integrated LSF/NSF 202, and the LSF/NSF 202 25 may have SAs with LSFs 106 of the NSF 104. The SAs are preferably initially pre-configured when the SLA is established or, alternatively, the SAs may be initially dynamically established via Internet Security Associations and Key Management Protocol (ISAKMP) . SAs 30 may also be established between LSFs 106 in order to manage inter-system handoffs in a secure fashion.

WO 01/19050 PCT/IBOO/01553 54 SAs of the type described herein are more fully disclosed and discussed in co-pending U.S. Patent Application Serial No. _/-, , entitled "SECURITY FRAMEWORK FOR IP MOBILITY SYSTEMS USING VARIABLE BASED 5 SECURITY ASSOCIATIONS AND BROKER REDIRECTION", filed June 16, 2000 on behalf of Basavaraj B. Patil, et al, (Attorney Docket No. 10726RRUS02U) which is hereby incorporated in its entirety by reference. 2.2.2.2 SECURITY BETWEEN A NETWORK'S LSF(S) AND NSF 10 A home network 102 may comprise a number of LSFs 106 associated with an NSF 104. Each LSF 106 and NSF 104 may be treated as a private subnet that is protected by an SMG. The LSFs 106 have an SA in place between their SMGs and the NSF's SMG. In FIGURE 9, this is shown by the SAs 15 902 between NSF 104 and the LSFs 106 shown in dashed outline 102. The NSF 104 combined with the LSFs 106 shown in dashed outline 102 may constitute a home network, or a virtual private network (VPN). An integrated network 202 also has LSF and NSF 20 functions combined, i.e., the components are physically located together. In such a scenario, the LSF/NSF network 202 has an SMG 904 that protects its network from the IP Network 108. An NSF, such as the NSF 906, may not control any 25 LSFs 106. In such case, users 114 of the NSF 906 will always be in other systems when it roams. 2.2.2.3 SECURITY IN THE DATA PLANE FIGURE 10 shows IPM architecture 1000, having a user 114 roaming in an LSF 106b and homed in a private network 30 102 NSF 104a. The user 114 wishes to establish a session with a Correspondent Node (CN) 116 within his/her home WO 01/19050 PCT/IBOO/01553 55 NSF 104a. To establish the session, the user 114 establishes an IPSec SA 1008, designated schematically by dashed lines with arrows, with the home NSF 104a to which an SMG 1010 has access. Such IPSec SA 1008 permits the 5 SMG 1010 to validate IPSec AH datagrams sent by the user 114 MN 112 to the home network 102. The SA 1008 is preferably pre-configured at the MN 112 and the home NSF 104a to allow the user 114 to roam. If a roaming user 114 wants to contact CNs 1004 in other private networks, 10 each of the private networks must have an SA established with the user 114 to permit the user to traverse the network's SMG. If end-to-end security (e.g., encryption) between the MN user 114 and another user (not shown) were 15 mandated based on decisions established by the home networks 102 of respective users 114, then the MN user 114 would establish an IPSec SA 1012 with the CN 116. Such an IPSec SA 1012 may be dynamically established at the time of session connection via ISAKMP, or the SA may 20 be pre-configured. It should be noted, however, that the existence or non-existence of such IPSec SA 1012 is transparent to the IPM architecture framework 1000. 2.2.2.3.1 PROTECTION OF MN LOCATION Security policies associated with an MN 112 may 25 warrant a home NSF 104 to not disclose the MN's current network point of attachment to CNs. In such cases, CNs may send datagrams destined to the MN 112 through the user's home network 102. The home network 102 is responsible for tunneling the datagrams to the LSF 106 30 currently serving the MN 112.

WO 01/19050 PCT/IBOO/01553 56 2.2.3 AUTHENTICATION, AUTHORIZATION, AND ACCOUNTING (AAA) FRAMEWORK FIGURE 11 illustrates an IPM Architecture framework 1100 that utilizes an AAA protocol for performing 5 authentication, authorization, and accounting operations. An AAA protocol provides a common messaging scheme, defined by standards, used between networks. The IPM architecture framework 1100 includes a visited network 304 and a home network 302, and is based on requirements 10 established by the AAA Business Operations Framework (BOF) that exists within the Internet Engineering Task Force (IETF) . The AAA protocol is extensible so that it may define other functions and provide solutions to different problem domains. In the architecture framework 15 1100 of the present invention, a Diameter-based AAA with extensions for IP mobility is preferred, though another AAA protocol such as Radius may also be used. Both Diameter and Radius are considered to be well-known in the art and, therefore, will not be discussed in further 20 detail herein, except insofar as necessary to describe the present invention. AAA services are accessed through AAA functions 450 and 462 which, while not providing the function of Authentication, Authorization or Accounting, do provide 25 an interface to the appropriate servers that implement AAA functions. The AAA functions 450 and 462 provide a standard means for addressing AAA messages sent between NSFs and LSFs, respectively, and, to that end, are located at the NSF 104 and LSF 106 shown in FIG. 11. 30 The AAA function 462 at the LSF 106, using the Network Access Identifier (NAI) received from an MN, is WO 01/19050 PCT/IBOO/01553 57 responsible for determining the NSF 104 that is home to a user 114 and for forwarding AAA messages to that user's home NSF 104. The AAA function 450 at the NSF 104 presents an 5 integrated AAA interface (through a single IP address) to the rest of the IP Network 108 and is configured for forwarding AAA messages to the appropriate function within the NSF 104 (FIGS. 4A, 4B, 4E, and 4F) responsible for a particular function. This allows an operator 10 specific internal architecture of an NSF 104 to be hidden from other NSFs and LSFs and provides a homogeneous interface for the IPM Architecture. A mobility extension to the AAA protocol enables mobility manager components, e.g., the SMM 464 in the LSF 15 106 and the HMM 452 in the NSF 104, to communicate with each other. The AAA functions 450 and 462 provide a secure means of exchanging mobility related control messages. The SMM 464 and HMM 452 interface to respective AAA functions 462 and 450 via the mobility 20 extension for their communication. Security between AAA functions 450 and 462 is based on IPSec. 2.2.3. 1 AUTHENTICATION Authentication in the context of the present invention exemplified in the IPM Architecture AAA 25 framework 1100 refers to authentication of an MN 112 and its user 114 by the authentication functions 450b and 462b (FIGS. 4E and 4F). Authentication of a user 114 is a process of validating the identity of the user 114, and includes a combination of certificate authority (CA) 30 1116, a key management system, and digital signature verification services. The authentication functions 450b WO 01/19050 PCT/IBOO/01553 58 and 462b interface with respective AAA functions 450 and 462 and validate authentication requests by MN users 114 as they access a network from either the home network 302 or the foreign (visiting) network 304. 5 Conventional networks support two types of authentication methods, namely, strong authentication and weak authentication. Strong authentication is preferred in the present invention for use by the authentication functions 450b and 462b, and makes use of symmetric and 10 asymmetric public key cryptography techniques. Examples of strong authentication include the use of digital signatures, public key cryptography using x.509 certificates, and the like. Weak authentication includes systems that use password-based protection mechanisms. 15 The core network 101 (FIG. 1) preferably supports multiple types of authentication mechanisms. The AAA authentication functions 450a and 462a are front-ends or relays that securely carry authentication parameters of a user 114 from the LSF 106 of the visited 20 network 304 to the home network 302 where the user 114 may be authenticated. The authentication function 450b supports existing authentication protocols, such as PAP, CHAP, EAP, and the like. These functions may be provided by a RADIUS server, by an x.509 based CA, by an 25 Authentication function in a wireless network, or the like. If the Authentication function 450b uses x.509 certificates, then a Certificate Authority (CA) 1114 may be a third party CA 1116. The NSF 104 may also have it's own CA 1114 in order to authenticate certificates. 30 As a result of advances made in cryptography, as well as for security reasons, digital signatures and WO 01/19050 PCT/IBOO/01553 59 x.509 certificates for authentication are preferred in the present invention. 2.2.3.2 AUTHORIZATION Authorization is a process performed by the 5 authorization functions 450c and 462c for determining which services and resources a user 114 is allowed to use. It is based on policies defined for the user and for the requested resource or service. Authorization may occur during authentication, or as a separate process. 10 An authorization function 450c or 462c may consult the policy server 404 or 412, respectively, that contains a user 114's profile, including services that the user has subscribed to. 2.2.3.3 ACCOUNTING 15 The accounting aspect of AAA is performed by the accounting functions 450d and 462d to transport accounting records generated for the user 114 in a visited system, such as the visited network 304. An accounting entity in the xAN 110/LSF 106 generates 20 records that contain such information for each MN 112 user 114 served by a network 302 or 304. The AAA function 450d or 462d is used as a front-end or relay to securely carry the accounting records from the visited network 304 to the accounting function 450d in the user's 25 NSF 104 or, alternatively, to an accounting function in the accounting service bureau 470 (FIG. 4B), if the bureau 470 supports an AAA accounting protocol. The accounting functions 450d and 462d are back-end servers that store the network usage records of MN users 30 114. The AAA function 450 in the NSF 104 interfaces with the accounting function 450d to transfer accounting WO 01/19050 PCT/IB00/01553 60 records generated by the LSFs 106 and/or the NSF 104. The accounting messages defined for AAA may carry the actual records or may provide a means to initiate the transfer of records in bulk. Since accounting records 5 are the source of revenue to service providers (i.e., owners of an NSF 104 and/or LSF 106), security must be provided between the links that are involved in the transfer of accounting records. An Accounting function (not shown) may also be 10 located on the Internet, and be hosted by the Accounting Service Bureau 470 (FIG. 4B) . In such a scenario the AAA Accounting function 450d in the NSF 104 would interface with the Accounting function in the service bureau 470. A security association (SA) may be established between 15 such entities to protect data. The Accounting functions 450d and 462d may in turn interface with billing servers 402 or 432, respectively, in an hierarchical manner. 2.2. 3. 4 MOBILITY 20 The mobility manager components SMM 464 and the HMM 452 of the IPM Architecture framework 1100 use the AAA protocol for its control plane messaging. The AAA protocol preferably includes support for mobility control messages. The mobility manager components SMM 464 and 25 HMM 452 of the respective LSF 106 and NSF 104 interface to the AAA functions 462 and 450 in their respective domains. 2.2.3.5AAA FUNCTION LOCATIONS IN THE NETWORK FIGURE 12 shows various configurations of AAA 30 functions in an IPM Architecture framework 1200 embodying features of the present invention. The framework 1200 WO 01/19050 PCT/IBOO/01553 61 includes the IP Network 108 through which are connected NSFs 104A and 104B, and respective LSFs 106A and 106B, the integrated LSF/NSF 202, the Accounting Service Bureau 470, the Security Agreement Broker 472, and the CA 1116. 5 The NSFs 104A and 104B include respective AAA functions 450A and 450B, and the LSFs 106A and 106B include respective AAA functions 462A and 462B. The NSF 104A and LSFs 106A constitute a network 102A, and the NSF 104B and LSF 106B constitute a network 102B. The Accounting 10 Service Bureau 470, and the Security Agreement Broker 472 include respective AAA functions 470a and 472a. A number of xANs 110 are shown connected to an LSF 110, and may be similarly connected to any of the LSFs 106A or 106B, or to the integrated LSF/NSF 202. 15 When an entity of the LSF 106A, 106B or 202, such as the AAA function 462 or the mobility manager SMM 464, performs an AAA function, that entity generates an AAA message and sends it to a "local" AAA function. The "local" AAA function is defined with respect to FIG. 12 20 as the AAA function 462A, 462B, or 450C located at the LSF 106A, 106B, or 202, respectively, of the visited network 304, or the AAA function 450A or 450B located at the NSF 104A or 104B, respectively, of the home network 302, to which -an MN 112 interfaces. The local AAA 25 function is responsible for routing the AAA message to the MN user 114's home AAA function, such as the AAA function 450A or 450B, or, alternatively, for accounting, it may be routed to the AAA function 470a in the accounting service bureau 470. The type of routing of 30 AAA messages described herein is more fully disclosed and discussed in co-pending U.S. Patent Application Serial WO 01/19050 PCT/IBOO/01553 62 No. 09/551,811, entitled "Apparatus and Method for Routing AAA Messages Between Domains of a Network", filed on behalf of Haseeb Akhtar, et al, on April 18, 2000 (Attorney Docket No. 10578RR) which is hereby 5 incorporated in its entirety by reference. The "local" AAA function thus determines where to send an AAA message. The "local" AAA function uses the domain portion of the user's NAI to identify the home network 302 of the user 114. If a service agreement (SA) 10 is established between a respective NSF 102A or NSF 102B of the home network 302 and a respective LSF 106A or 106B or the LSF/NSF 202 of the visited network 304, the AAA message is forwarded to the home AAA function 104A or 104B of the user 114. If there is no roaming agreement 15 (i.e., no SA) between the networks, the visited network 304 may, depending on its policy 412, forward the AAA message to the AAA function 470a of the service bureau 470. The accounting service bureau 470 is an organization 20 that has established service level agreements (SLAs) with other network service providers (i.e., owners of NSFs) and/or other service bureaus (such as 472) . The SLAs permit MNs 112 to roam between NSF and LSF networks that have not directly entered into SLAs with each other. In 25 a global roaming scenario it may not be possible for an NSF 104 to enter into SLAs with every other NSF in the world. Therefore, having entered into an SLA with a Service Agreement Broker 472 may increase the scope of roaming that a user 112 of an MN 114 may enjoy through 30 its NSF 104.

WO 01/19050 PCT/IBOO/01553 63 It may be desirable to locate the "local" AAA function, that would otherwise be located at a respective LSF, at a visited system's NSF 104A or 104B when the service provider of the respective NSF owns a number of 5 LSFs to avoid incurring the cost of an AAA function 462 in every LSF. However, depending on where the NSF 104 is located, e.g., if the location of the NSF necessitates that a message from the LSF to the NSF traverse a public IP-based network such as the Internet, the service 10 provider will need to determine whether to provide secure links, such as an IPSec link, between the AAA function 462 located at the NSF 104, and LSF 106 components, such as the SMM 464. Alternatively, security between an LSF and NSF may be .provided by an AAA protocol configured to 15 only forward AAA messages to the NSF 104A or 104B, which then performs a domain lookup to forward the AAA messages to the user's home NSF 104A or 104B. In still another alternative, a service provider of an LSF 106A or 106B may use the AAA function 472a of the Broker 472 as its 20 "local" AAA function. 2.2.3.6 SECURITY IN THE AAA FRAMEWORK FIGURE 13 exemplifies security associations (SAs) that may be provided on a one-to-one basis between AAA functions in an IPM Architecture framework 1300 embodying 25 feature of the present invention. SAs are represented in FIG. 13 as dashed lines with arrows on each end of the line. For example, FIG. 13 depicts an SA 1302 between an AAA function 450C of an NSF 202 and an AAA function 450B in an NSF 104B. SAs are setup for end-to-end 30 authentication using IPSec's AH to allow for verifying a network's authenticity. However, an SA may also employ WO 01/19050 PCT/IBOO/01553 64 ESP to enhance data integrity. An SA is preferably set up on a permanent basis, in accordance with a roaming agreement, e.g., an SLA, established between the two networks. 5 In FIG. 13, a number of different types of NSFs are depicted: an NSF 104A having separate LSFs 106A, an NSF 202 having an integrated LSF, and an NSF 104B having no access networks. The SA 1302 between the NSF 202 AAA function 450C 10 and the NSF 104B AAA function 450B enables users of the NSF 104B to roam into the NSF 202 network. When users of the NSF 104B roam into LSF 106A, however, the NSF 104A is not able to identify the user's domain (i.e., home NSF) because the NSF 104A does not have an SLA established 15 with the NSF 104B. However, an SLA and an IPSec SA 1304 are established between the NSF 104A and the Service Agreement Broker 472, thereby creating a trust relationship therebetween. Hence, the NSF 104A may relay AAA messages to the AAA function 472a of the Broker 472. 20 An SLA and an SA 1306 are also established between the Broker 472 and the NSF 104B. Therefore, the broker 472 is able to forward the AAA message received from the NSF 104A to the NSF 104B. Because of the SLAs between the NSFs 104A and 104B and the broker 472, the broker 472 25 is able to forward all requests between the NSF 104A and the NSF 104B. The broker 472 may remove itself from being the "middle man" for forwarding requests, by using ISAKMP to negotiate the creation of an SA (not shown) between the 30 AAA function 450A of the NSF 104a and the AAA function 450B of the NSF 104B. Once the SA is established, the WO 01/19050 PCT/IBOO/01553 65 NSF 104A and the NSF 104B may communicate directly to each other. Also shown in FIG. 13 are an SA 1310 between the LSF 106A and the NSF 104A, an SA 1312 between the SMGs 806A 5 and 806B, and an SA 1314 between the AAA function 450C and the AAA function 472a. 2.2.4 MOBILITY MANAGER FRAMEWORK As mentioned above, the IPM Architecture of the present invention also includes a mobility manager 10 framework. The mobility manager framework supports nomadic roaming users and roaming MN users who roam into wireline networks and wireless networks. The term "nomadic users" is used herein to refer to users who, when they move from a first location to a 15 second location, physically disconnect from a first point-of-attachment at the first location, and then physically re-connect at a second point-of-attachment at the second location. Nomadic users normally connect to wireline access networks, e.g., LAN connections and 20 dialup connections. In contrast to the term "nomadic users", the term "MN users" is used herein to refer to users who do not need to disconnect from a point-of-attachment when they roam. MN users normally connect to wireless access 25 networks, e.g., NAC, GSM, and the like. Conventionally, wireline networks and wireless networks each have their own unique infrastructures to achieve their respective user mobility. According to C. Perkins, editor of "IP Mobility Support", RFC 2002, 30 October 1996, wireline networks use mobile IP to support user mobility, and the wireless networks use either NAC WO 01/19050 PCT/IBOO/01553 66 or GSM/UMTS standards. In contrast to conventional networks, the mobility manager framework of the present invention insures that there is seamless user mobility between wireline networks and wireless networks. 5 As discussed in further detail below, the mobility manager framework (including for example the SMM 464 and HMM 452) supports a number of functions, including, such as, for example, protocol interfaces between network components (e.g., as shown in FIGS. 4A and 4B), unique 10 identification of users, user security, network security, user location tracking, user packet data service activation to one or more service providers from the same device, user packet data service deactivation, user/MN context management, inter system (inter LSF) handoffs, 15 intra system (intra LSF) handoffs between two xRANs, unified directory service that contains user profiles, roaming MN address resolution, IP router configurations, and mobility interface to the wireline networks. 2.2.4.1 PROTOCOL INTERFACES BETWEEN NETWORK COMPONENTS 20 As users 114 roam between heterogeneous access LSF and NSF networks, the access media used by the user 114 is very specific to the access type, e.g., GSM has air interface characteristics, dialup connections have wireline dialup characteristics, and the like. As a 25 consequence of the different characteristics, each of the access networks has its own access protocol. However, to seamlessly integrate different access networks, the protocols needed between several interfaces are defined so that user mobility may be supported throughout the 30 network. FIGURE 14 depicts an IPM Architecture network WO 01/19050 PCT/IBOO/01553 67 1400 having four of these interfaces between which protocols are defined. First, in accordance with the present invention, a protocol is defined for a interface between the MN 112 5 and an LSF 106B, depicted in FIG. 14 as an MN/LSF interface 1402. The protocol that defines the interface 1402 is a Layer 3 protocol that enables users 114 to request access to the network 1400 through the LSF 106A and to obtain IPM services. With respect to the 10 interface 1402, the network 1400 uses a mobile IP protocol as a base protocol with a number of enhancements to support functionality of the IPM, as discussed in further detail below with respect to FIGS. 21-63. Second, in accordance with the present invention, a 15 protocol is defined for a interface between the xAN and LSF, depicted in FIG. 14 as an xAN/LSF interface 1404. The protocol that defines the xAN/LSF interface 1404 is a Layer 3 protocol that translates xAN-LSF messages into MN-LSF messages so that an MN may communicate with an LSF 20 using IPM messages, and a user 114 may thereby roam within a LSF and between LSFs. The xAN/LSF 'interface 1404 is described in further detail below with respect to FIGS. 20A-63 Third, in accordance with the present invention, a 25 protocol is defined for an interface between LSFs and NSFs, depicted in FIG. 14 as an LSF/NSF Interface 1406. The protocol that defines the interface 1406 provides information for user location tracking and for providing user profile information between the SMMs. 464A and 464B 30 and the user's HMM 452.

WO 01/19050 PCT/IBOO/01553 68 Fourth, in accordance with the present invention, a protocol is defined for an interface between LSFs 106A and 106B, depicted in FIG. 14 as an LSF/LSF Interface 1408. The protocol that defines this interface provides 5 information for coordinating seamless mobility between two LSFs. The LSF/LSF Interface 1406 is described in further detail below with respect to FIGS. 21-63. It is noted that a conventional interface is defined between the MN 112 and an xAN 110, depicted in FIG. 14 as 10 an MN/xAN interface 1410. The interface 1410 is defined by a Layer 2 protocol and uses any interface, such as, for example, NAC, GSM, DSL, IEEE 802.3, IEEE 802.11, and the like. In light of the foregoing, the present invention 15 enables an MN 112 to communicate with an LSF 106 at the Layer 2 level via the MN/xAN interface 1410 and the xAN/LSF interface 1404, and at the Layer 3 level via the MN/LSF interface 1402. Two alternatives exist for defining the protocols 20 for the LSF/NSF interface 1406 and the LSF/LSF 1408 interfaces described above. A preferred alternative is to extend the AAA protocol to support the required mobility functions SMM 464 and HMM 452. A second alternative is to define a protocol that is independent 25 of the AAA protocol. The mobility framework of the present invention extends the AAA protocol to include an SMM 464 and an HMM 452, for at least two reasons: first, the AAA protocol (preferably based on Diameter) is an extensible protocol 30 that already includes many basic AAA functions and, WO 01/19050 PCT/IBOO/01553 69 second, the SMM 464 and an HMM 452 may take advantage of the AAA function's security associations. 2.2.4.2 USER AND NETWORK MOBILITY SECURITY FIGURE 15 shows a network 1500 having an LSF 106 5 being accessed by a roaming user 114.. Prior to being accessed, the LSF 106 must determine whether the user 114 is a valid user. To make such a determination, two levels of security must preferably be established. First, the user 114 and a home NSF 104A should establish 10 an IPSec SA. 1502 that is used to authenticate the user 114. Second, the LSF 106 and the NSF 104A must have an IPSec SA 1502 that is used to validate whether the LSF 106 and NSF 104A have a service level agreement (SLA) established between them. 15 The SA 1502 established between the user 114 and the home NSF 104A may support one of a number of different types of authentication algorithms: preferably, digital certificates or, alternatively, symmetric keys, asymmetric keys, or the like. Hence, when a user 20 accesses an LSF 106, the MN 112 will need to send the user's digital signature and the NAI to the xAN. The LSF sends this information to the home NSF so that the home NSF can authenticate the user. The home NSF uses the NAI to access the user's profile in a directory service and 25 initiate the user's authentication. Alternatively, the LSF 106 may determine whether the user 114 is a valid user by requesting that the home NSF 104A of the user 114 send to the LSF 106 authentication information, such as, for example, the user's private 30 key, so that the LSF 106 may authenticate the user 114. In still another alternative, the integrated LSF/NSF 202 WO 01/19050 PCT/IB00/01553 70 may support the concept of a unique authentication challenge (similar to the CHAP unique challenge). The SA 1502 between the LSF 106 and the NSF 104A is established when the LSF and NSF execute their SLAs. The 5 SA 1502 is based on IPSec. FIGURE 15 thus depicts an option for a mobility SA between a serving LSF 106 and the MN User's home NSF 104A when the LSF 106 has an AAA function 462. FIGURE 16 is similar to FIG. 15, but for the 10 addition of an NSF 104B which is designated as the home NSF of the user 114, and an IPSec SA 1602 established between the AAA function 450A and the AAA function 450B. The AAA function 450B is then utilized by an LSF 106 to authenticate the user 114. 15 If the user 114 is accessing his/her home LSF 106 in an integrated LSF/NSF, such as the LSF/NSF 202 described above with respect to FIG. 2, there may be no need to establish an SA between the LSF 106 and NSF 104. However, the service provider of the respective 20 integrated LSF/NSF may desire security within its own "closed" network. This may be achieved by establishing SAs between the multiple AAA functions within the closed network. 2.2.4.3 USER LOCATION TRACKING 25 The expression "user location tracking" as used herein refers to the functions and data required to reliably discern where an MN is physically located at any time. There are two basic functions involved in user location tracking. First, a user's MN 112 must determine 30 that a user 114 has moved to a different subnet (e.g., an IP network) and inform the network of such. Second, MNs WO 01/19050 PCT/IBOO/01553 71 112 that are executing one or more applications must be tracked as they move (i.e., handoff) between different subnets. As a user 114 roams within an access network (xAN 5 110), his/her MN 112 determines whether it has changed its subnet point-of-attachment (as defined in RFC 2002). If the MN's subnet point-of-attachment has changed, then the MN 112 informs the network. When a user 114 first accesses a system (e.g., an 10 LSF) via an xAN 110, the user's MN 112 sends a Registration message to the LSF's SMM 464 via the MN/LSF interface. The SMM has several functions it must perform, such as, for example, it must allocate a Care Of Address (COA, discussed further below with respect to MN 15 Addresses), maintain local information pertaining to the MN, and the like. The SMM 464 will use the LSF/NSF Interface, such as the LSF/NSF interface 1406 (FIG. 14), which is based on the AAA protocol, to authenticate and register the user 20 114 with its home NSF 104. The home NSF 104 uses information in the Registration message to update the user's location in the UDS 460. The LSF 106 supports the ability to restrict user 114 access within certain IP subnets. With the advent of 25 global deployment of networks, there may be reasons for restricting users (or particular network domains) from accessing certain IP administrative domains. The ability to restrict user 114 access within certain IP subnets is a user authorization function that is configured and 30 enforced at the LSFs by policy.

WO 01/19050 PCT/IBOO/01553 72 Finally, the LSF SMM 464 supports mobility between serving LSFs 106 via an LSF/LSF Interface. One of the functions the SMM 464 insures is that there is no loss of data during a transition (i.e., a handoff). LSFs 106 may 5 also chare the same security associations between the MN and the LSF (e.g., SA3 and SA5 as depicted in FIG. 8). 2.2.4.4 REGISTRATION ESTABLISHES A PACKET DATA SESSION The term "architecture" as used herein supports the concept of a user 114 establishing a packet data session 10 (i.e., an IP packet data session) with multiple home networks (NSFs 104) from the user's current device, which is the same concept as found in GPRS and IMT2000. However, since each home network is a unique network, the user 114 will need to send a unique and separate 15 registration request to each network, and each request will contain a unique NAI associated with the network to which the user desires to establish the packet data session. In accordance with the IPM Architecture of the 20 present invention, a packet data session is preferably established when an MN 112 sends a Registration Request. The Registration Request may be sent in two scenarios: first, when the user initially powers on the MN and, second, when a user wants to establish another packet 25 data session with another home network (service provider, e.g., a second or third home network). The user 114 may have one provider for access (e.g. ATT, AOL, or the like). This necessitates that the user have two "subscriptions," one to use (and be 30 authenticated on) the access system, and another to use (and be authenticated on) the data services.

WO 01/19050 PCT/IBOO/01553 73 In accordance with the architecture of the present invention, it is not necessary for a user 114 to have a subscription with an access provider if the access provider is not providing the user's services. The 5 actual service provider (i.e., the user's home network) only needs to perform the user's authentication, because the access provider (e.g., an LSF and/or an NSF) will preferably have established an SLA with the user's home NSF 104, which provides the necessary trust relationship 10 between the networks. If a user is not paying his bills, the home NSF is responsible for refusing access for the user. 2.2.4.5 DE-REGISTRATION OF A PACKET DATA SESSION Occasionally, a user will need to explicitly 15 terminate a packet data session. This may be achieved conventionally by hanging up a phone to a dial-up ISP, or by terminating a wireless data call. It may not always be so simple in future networks. For example, where a user has multiple packet data sessions, he/she may want 20 to terminate only one of them. Also, there may be some shared fixed device that several users may use. For example, a first user may "slide" a User Identity Module (SIM) card in the device and "perform" his data session to some ISP. When that user is done, the packet data 25 session is terminated so another user may use the device. The IPM Architecture of the present invention supports de-registration by sending a Registration Request with an indication that the user wants to terminate his/her packet data session.

WO 01/19050 PCT/IBOO/01553 74 2.2.4.6 MOBILE NODE ADDRESSES To route datagrams to a roaming user's MN 112, an IP address must be allocated to the MN 112 that the user is currently using to send and receive datagrams. This 5 address is stored in the home DDNS server 456 where it is available to anyone, such as a correspondent node (CN) that wishes to establish an application session with the user 114. There are at least two alternative methods for 10 assigning an IP address to an MN 112, henceforth referred to as the MN's allocated IP address. First, the MN's allocated IP address may be assigned when the MN is configured, wherein the allocated IP address is permanent and the MN always has the same IP address. Second, if 15 the MN does not have a configured IP address, an IP address may be dynamically allocated (i.e., auto configuration is executed) to the MN when the MN accesses an LSF 106 for the first time. In this scenario there are two options for dynamically allocating the IP 20 address: (1) allocation by the visited LSF, and (2) allocation by the user's home NSF. In accordance with the present invention, it is preferable that IP address be assigned by the user's home NSF so that the IP address is topologically associated with the user's home NSF. 25 When a CN (anywhere on the Internet) wants to establish an application session with a roaming user, the CN will acquire the user's allocated IP address via a DDNS request to the user's home NSF. Since the allocated IP address is associated with the user's home NSF, the 30 Internet will route the data to the home NSF. For the home NSF to send the datagrams to the user, the serving WO 01/19050 PCT/IBOO/01553 75 LSF allocates an IP address, called a care-of address (COA), which may be used to tunnel. datagrams from the user's home NSF to the LSF router associated with the COA. The LSF router de-tunnels the packet and forwards 5 it to the user. This creates the infamous "triangle routing," which is not an optimal path for data to transverse. To help alleviate "triangle routing," the user's MN COA is given to the CN. In accordance with the present 10 invention, there are at least two scenarios for giving the user's MN COA to the CN. First, when the home NSF receives data destined for a roaming user, the home NSF sends a message to the CN to update the CN with the user's COA. The NSF supports a policy that indicates 15 that the NSF should hide or not hide the MN user's network location from the CN. If the policy is set for "do not hide, " the NSF will send the COA to the CN; otherwise, the NSF will not send the MN's COA to the CN. Second, the CN is given the COA in a DDNS response 20 when the CN application requested the user's allocated IP address. This mechanism provides a more expeditious session setup between the CN and the MN user, and alleviates triangle routing. A policy at the NSF may dictate the need for sending the COA to the CN. However, 25 prior to selecting this second option, there are number of issues that should be considered, which issues are exactly the same issues as discussed above with respect to Network Route Addressing for the case where the LSF allocates the MN's IP address. 30 With the addressing foundation established, the techniques will be applied to the five address allocation WO 01/19050 PCT/IBOO/01553 76 scenarios described above with respect to Network Route Addressing. First, the device (e.g., MN 112) owned by the user 114 has a permanent IP address associated with his home 5 network NSF. The MN will use the permanent IP address to terminate MN datagrams. And the LSF's COA is used to tunnel datagrams to the LSF. Second, the device the user is about to use is not his/her device and the device has a permanent IP address 10 that is associated with the current point of attachment (associated with the visited LSF) . The NSF will then allocate an IP address for the MN to be used by the MN to terminate datagrams, and the LSF COA is used to tunnel datagrams to the LSF. 15 Third, the device the user is about to use is not his/her device and the device has a permanent IP address that is not associated with his/her home network or the current point of attachment (associated with the visited LSF). The NSF will allocate an IP address for the MN to 20 be used by the MN to terminate datagrams and the LSF COA is used to tunnel datagrams to the LSF. Fourth, the device owned by the user does not have a permanent IP address, hence, when the user roams with this device, the network will dynamically allocate an IP 25 address. The NSF will allocate an IP address for the MN to be used by the MN to terminate datagrams and the LSF COA is used to tunnel datagrams to the LSF. Fifth, the device the user is about to use is not his/her device, and the device does not have a permanent 30 IP address, hence, when the user roams with this device, the network will dynamically allocate an IP address. The WO 01/19050 PCT/IBOO/01553 77 NSF will allocate an IP address for the MN to be used by the MN to terminate datagrams, and the LSF COA is used to tunnel datagrams to the LSF. In each of the above address allocation scenarios, 5 if the user's home network is a private network that supports non-routable IP addresses, the LSF must allocate a co-located COA (as defined in RFC 2002) for the MN. This allows the home network to tunnel datagrams directly to the MN instead of tunneling datagrams to the LSF. 10 Allocating a co-located COA to the MN is necessary since there may be another user who is roaming in the same network that has an MN with the same allocated IP address from a network that supports routable IP addresses. Allocating a co-located COA to the MN eliminates two MNs 15 having the same IP address. 2.2.4.7 UPDATING CORRESPONDENT NODES WITH COA'S To alleviate triangle routing at the user's home network, the COA that represents the MN's current point of attachment is sent to the CN. When the home NSF 20 receives data destined for a roaming user, the home NSF sends a message to the CN to update the CN with the user's COA. Alternatively, when an MN re-registers, the registration will include a CN IP address for each application with which the user is currently in session. 25 In an alternative to the home NSF updating the CN, if the MN is given the COA (during registration), it may send the COA update directly to the CNs. However, this latter method may require increased airwave bandwidth. When the CN receives the COA update, the CN must 30 update its routing table to trigger the appropriate tunneling.

WO 01/19050 PCT/IBOO/01553 78 For the CN to insure that the COA it receives is valid, the user's NSF (or MN) should have a security association (SA) established with the CN or the CN's network to insure the validity of the COA updates. 5 The list of CNs included in the registration message may be prioritized based on some criteria, e.g., application Quality of Service (QoS). 2.2.4.8 IP ROUTER CONFIGURATIONS There are a number of IP router configurations that 10 may be supported by an LSF of the present invention, several of which configurations are described in greater detail below. Router configurations should preferably support a single COA tunnel point into the LSF, i.e., a single router at the "top" of a hierarchy that provides 15 the COA and tunneling. This minimizes the updating of a COA to a user's home network and the CNs the user is in correspondence with. 2.2.4.8.1 SINGLE IP ROUTER IN LSF Since a CN and/or home NSF requires a COA to deliver 20. datagrams to a roaming user, it is preferable to have an LSF assign a single COA to a MN as a user roams within the LSF. In accordance with the present invention, and as depicted in FIGURE 17, this is achieved by configuring a single router 1702 in an LSF 106 that has a COA 1704 25 for all MNs 112 roaming in an LSF 106 between, for example, two routers 1706A and 1706B which interface via Radio Access Networks (RANs) with the MN 112. It is noted that all routers shown in FIGURES 17-19 may include the ANI and/or the ITS functions.

WO 01/19050 PCT/IBOO/01553 79 2.2.4.8.2 MULTIPLE IP ROUTERS IN THE LSF In some LSFs, it may be necessary to equip an LSF with more than one router to, for example, increase router capacity. As exemplified in FIGURE 18, each xAN 5 110A and 110B preferably has a router 1706A and 1706B, respectively, that is considered to be at the edge of the xAN 110 and LSF 106. In the configuration exemplified in FIG. 18, the LSF 106 supports two COAs 1704A and 1704B, one for each 10 router 1702A and 1702B, respectively, for serving the xAN 110A and xAN 110B, respectively. It should be noted with respect to the configuration shown ,that the CN 116 and/or home NSF 104 must be updated with the respective MN's new COA 1704A and 1704B when the MN 112 moves between xANs 15 110A and 110B attached to different routers 1706A and 1706B. 2.2.4.8.3 HIERARCHICAL MOBILITY ROUTER To alleviate the burden of supporting more than one COA at an LSF, the LSF may support a hierarchical router 20 configuration. FIGURE 19 exemplifies such an hierarchical router configuration, wherein the MNs 112 may all be associated with a single COA 1704, which is the COA of a single router 1902 connected to the two routers 1702A and 1702B in the LSF 106. 25 2.2.4.9 IMPLEMENTATION SCENARIOS The IPM Architecture framework of the present invention provides flexibility in deploying an SMM 464 within an LSF 106. When deploying SMMs, however, there are a number of issues to consider. For example, in 30 general, an ITS function may be implemented in the router since it on the data plane. An ANI/SMM may be deployed WO 01/19050 PCT/IB00/01553 80 in the router or in different computing machines depending on the size and capacity of the LSF. An SMM 464 may be deployed on a standalone server, without other IPM components. The SMM 464 may also be deployed on a 5 server, with other IPM components, such as the AAA function 462. The SMM 464 may also be deployed on a router. Additionally, there may be more than one SMM 464 in an LSF 106. The choice of deployment turns on the type of IP 10 router configuration being used and the LSF performance desired. For example, in a single IP router configured in an LSF, such as depicted in FIG. 17, it may be preferable for the SMM 464 to be positioned on the router 1702, instead of on a standalone server. This type of 15 deployment looks similar to the IWF/PDSN data model in 2 nd and 2

.

5 "d generation cellular system. As the network grows and there is a need for more routers at the xAN/LSF interface, this could evolve into the Hierarchical Mobility Router configuration depicted in FIG. 19. 20 The xAN and LSF may be configured such that there are multiple routers at the LSF and xAN, and the SMM 464 is on a server in the LSF 106, as depicted in FIGS. 18 and 19. A service provider may desire to assign a unique COA to each of these routers, as in FIG. 18 relating to 25 multiple IP routers in an LSF. The MN is informed of which COA to use via the xAN/LSF interface. This information is then relayed to the SMM through a Registration Request message between the MN and the SMM. This scenario also allows the service provider to balance 30 the IP datagram load across these routers, e.g., they may WO 01/19050 PCT/IBOO/01553 81 assign different routing areas to each router (if the xAN supports this functionality). 2.2.4.10 MOBILE NODE COMPONENTS To support seamless roaming between heterogeneous 5 networks, the MN 112 must support an architecture that is different from architectures conventionally used in diverse data technologies. FIGURE 20 provides an overview of components needed by the MN 112 to support seamless roaming. As discussed further below, the 10 components include Layer 2 access cards 2002, a Layer 2 access arbitrator 2004, and a registration control 2006. Components needed by the MN 112 to support seamless roaming of the type described herein are still more fully disclosed and discussed in co-pending U.S. Patent 15 Application Serial No. / , , entitled "Method and System for Switching Between Two Network Access Technologies Without Interrupting Interractive Active Network Applications", filed on behalf of Donald. Wurch et al, on August 2, 2000 (Attorney Reference No. 10740RR) 20 which is hereby incorporated in its entirety by reference. 2.2.4.10.1 LAYER 2 ACCESS CARDS Each Layer 2 (L2) access card 2002 supports a specific wireless access protocol, e.g., L2 access card 1 25 may support CDMA+, L2 access card 2 may support TDMA+, and L2 access card N may be an Ethernet card. The "+" sign appended to CDMA and TDMA indicates that those wireless access protocols need to develop further to work in the IPM Architecture. 30 The wireless access cards 2002 perform functions similar to those performed in 2G and 3G systems. For WO 01/19050 PCT/IBOO/01553 82 example, the wireless access cards 2002 may be used to monitor the Broadcast Channel (BCCH) associated with its access protocol. The wireless access cards 2002 may also be used in handoffs with a Radio Access Network (RAN), 5 discussed further below. The wireless access cards 2002 may also perform Layer 2 access requests, similar to a conventional registration, but the cards 2002 are not user-oriented and does not go beyond the access network (xAN 110). 10 Layer 2 access informs the access network that the MN 112 is on its system. In a channelized RAN this would, logically, put the MN 112 in a standby/dormant mode. In accordance with the present invention, the L2 access cards 2002 may also pass information to the Layer 15 2 Arbitrator 2004 via a standardized interface. This information may be LSF system information obtained in the BCCH and/or information generated by the Layer 2 access card, e.g., Received Signal Strength Indication (RSSI) values. 20 2.2.4.10.2 LAYER 2 ARBITRATOR AND REGISTRATION CONTROL There are a number of functions performed by the Layer 2 (L2) Arbitrator 2004. For example, the L2 Arbitrator 2004 may be used to obtain information from 25 each L2 Access Card 2002 that will allow the Arbitrator to determine which access is the best. When the L2 Arbitrator 2004 selects a new L2 Access Card 2002, the Arbitrator may be used to update a routing table with the appropriate L2 interface driver. The L2 Arbitrator 2004 30 may be used to coordinate L2 Access Card 2002 changes with the Registration Control Object 2006. The L2 WO 01/19050 PCT/IBOO/01553 83 Arbitrator 2004 may also be used to obtain information from current L2 access, and to inform the Registration Control Object 2006 that it is still on the same subnet point-of-attachment (i.e., it basically generates an 5 agent advertisement or its equivalent). Use of the L2 Arbitrator 2004 is exemplified as follows. The L2 Arbitrator 2004 receives information from each of the L2 Access Cards 2002 through a standardized API. With the information, the Arbitrator 10 2004 decides which access is best. When the Arbitrator 2004 decides that a new Access Card 2002 should be used, the Arbitrator 2004 informs the Registration Control Object 2006 so it may perform the appropriate functions, e.g., send the old LSF 106 a Registration that indicates 15 movement. After the Registration Control Object 2006 performs its functions, the Arbitrator 2004 updates the routing table with the new L2 access driver. The Arbitrator 2004 will next receive information from the new Access Card 2002 indicating the current point of 20 attachment which it would pass on to the Registration Control Object 2006. 2.2.4.11 ANY(X) ACCESS NETWORKS The any(x) Access Network (xAN), also referred to herein as xAN 110, is configured for providing Layer 2 25 access for devices used by MN users. From a mobility perspective, the functions of the xAN include providing LSF system access parameters to the MN via a BCCH, e.g., SMM IP address, an LSF NAI, and the like. Further functions of the xAN include micro mobility (i.e., MN 30 handoffs within the xAN). Still further functions of the xAN include providing the LSF with a handoff indication WO 01/19050 PCT/IBOO/01553 84 when the MN is handed off to a different system (e.g., a different LSF or xAN). The IPM architecture framework of the present invention supports traditional channelized xANs, e.g., 5 RAN, TDMA and CDMA, where a dedicated radio resource is used to generate BCCH messages. The MN's Layer 2 Access Card relays the information that is provided in the BCCH to help other components in the MN provide user mobility. It is anticipated that future xANs will not be 10 channelized. They will be designed to be a broadband access medium similar to 802.11 wireless LANs. It is also expected that there will still be some type of BCCH, similar to the 802.11 beacon which may be used to facilitate handoffs between xANs. Such developments are 15 supported by the IPM architecture framework of the present invention. It should be noted that Ethernet Layer 2 is a broadband access medium that does not have a BCCH. Since the Ethernet Layer 2 architecture is based on Mobile IP 20 (MIP), MNs attached to an Ethernet access use an agent advertisement to acquire system information. This provides an alternative to the future broadband (non channelized) xANs. It is not necessary that they have system information in their BCCHs. They can rely on 25 agent advertisements (or whatever agent advertisements may evolve to). The following specifies a preferred messaging -interface between the xAN, also referred to herein as the xAN 110, and the LSF 106 components as defined above with 30 respect to the IPM Architecture Framework of the present invention.

WO 01/19050 PCT/IBOO/01553 85 2.2.4.11.1 IP MOBILITY MESSAGES IPM Messages consist of existing Mobile IP (MIP) messages, as defined in RFC 2002, MIP messages with changes, and completely new messages. In addition, the 5 IPM Architecture of the present invention makes use of existing MIP extension(s) and defines new extensions. All of the extensions may be used with any IPM message. IPM messages uses the same port (number 434) as Mobile IP. IPM Messages are built to insure interoperability 10 and compatibility with existing implementations of MIP. MIP-based IPM messages are relevant to the xAN-LSF interface include, for example, Registration Request messages, Registration Reply messages, Prepare for System Change messages, and System Change messages. 15 New IPM messages that are relevant to the xAN-LSF interface include, for example, Activate Packet Service messages, Activate Packet Service Ack messages, Add L2 IP Association messages, Buffer Data messages, Buffer Data Ack messages, Cleanup messages, Cleanup Ack messages, 20 Correspondent Node List messages, Correspondent Node List Ack messages, Forward Data messages, Forward Data Ack messages, Handoff Required messages, and Handoff Required Ack messages. FIGURE 14A and 14B depict an interface between a xAN 25 110 and a LSF 106 embodying features of the present invention. Accordingly, in step 1420, a MN 112 of a user 114 initiates a L2 session to a xAN 110. In step 1422, the xAN 110 terminates the L2 session that was initiated by the MN 112. In step 1424, the xAN 110 sends a 30 notification of L2 termination to the MN 112. In step 1426, the MN 112 receives the notification of termination WO 01/19050 PCT/IBOO/01553 86 of L2 session from the xAN 110. In step 1428, the MN 112 initiates an IPM L3 session with the LSF 106. In step 1430, the LSF 106 establishes an IPM L3 session and sends IPM messages to NSF 104. In step 1431, the NSF 104 5 receives IPM messages from the LSF 106. In step 1432, the NSF 104 sends IPM response messages to MN 112 via LSF 106. In step 1434, LSF 106 receives IPM messages from NSF that are destined for the MN 112. In step 143,6, the LSF 106 initiates resource 10 management request to xAN 110. This resource management task includes a function for mapping between L2 and L3, a function for allocating routing resources for buffering and forwarding data packets, a function for initiating a inter-LSF or intra-LSF handoff of data sessions and a 15 function for reclaiming any unused routing resources. These functions are described in further detail below. In step 1438, the xAN 110 receives a resource management request from LSF 106. In step 1440, the xAN 110 manage its resources as requested by the LSF 106. In 20 step 1442, the xAN 110 notifies the LSF 106 that it has completed the task of resource management. In step 1444, the LSF 106 receives a notification that the xAN 110 has managed the resources requested by LSF 106. In step 1446, the LSF 106 sends the IPM messages to the MN 112. In step 25 1448, the MN 112 receives the IPM messages from the LSF 106. FIGURE 20A shows origination and destination points of the IPM messages. As shown, the MN 112 originates a message exchange by sending to the LSF 106 at least one 30 of a Registration Request message, a Prepare for System Change message, a System Change message, and a WO 01/19050 PCT/IBOO/01553 87 Correspondent Node List. In response, the LSF 106 may send one of a Registration Reply message, and a Correspondent Node List Ack message. The LSF 106 may also send to the xAN, 110 at least 5 one of an Add L2 IP Association message, an Activate Packet Service message, a Buffer Data message, a Forward Data message, and a Cleanup message. In response to a message from the LSF 106, the xAN 110 may send a suitable one of an Activate Packet Service message, a Buffer Data 10 Ack message, a Forward Data Ack message, and a Cleanup Ack message. The xAN 110 may also send a Handoff Required message to the LSF 106, in response to which the LSF may respond with a Handoff Required Ack message. 15 FIGURE 20B shows a general format for an IPM message 20B02. As discussed further- below, the message 20B02 includes an IP Header field 20B04, a UDP field 20B06, a message field 20B08 for carrying an existing MIP message or a new IPM message, and an IPM extension(s) field 20 20B08. As discussed in further detail below, the IPM extension(s) field 20B08 may comprise a base MIP extension such as an NAI extension, or may comprise a new IPM extension in accordance with the present invention, 25 such as an Authentication extension, a Call Information extension, a CN List extension, a LSF NAI extension, a Routing Area extension, an MN Layer 2 extension, or a Terminal Information extension. FIGURE 20C shows a preferred general format for 30 general MIP extensions, such as described below with respect to FIGS. 20D-20K. The MIP extension depicted by WO 01/19050 PCT/IBOO/01553 88 FIG. 20C comprises a type field, a length field, and a data field. The type field defines the extension type. The length field represents the length of data in bytes, which may range from 0 to 255 bytes. The data field 5 contains the data of the extension. FIGURE 20D shows the message format of an Authentication Information Extension, which is used to pass a user's Digital Signature. FIGURE 20E shows the message format of a Call 10 Information Extension, which is used to pass a user's call related information. FIGURE 20F shows the message format of a CN List Extension, which is used to distribute .Correspondent Nodes associated with the MN. 15 FIGURE 20G shows the message format of an LSF NAI Extension, which is used during handoff scenarios. FIGURE 20H shows the message format of an MN's L2 address extension, which identifies the inherent Layer 2 (L2) address, such as IMSI, MAC, and the like, of the 20 mobile device's technology. The L2 Address is required to identify an MN that does not have any IP address assigned to it. It is expected that in such cases the xAN would keep a mapping between the L2 and IP addresses of the MN. 25 FIGURE 201 shows the NAI extension, which identifies the user and home domain of the user. It is of type user@realm as defined in RFC 2486. FIGURE 20J shows an IPM Routing Area Extension, which identifies the Routing Area (RA) that the MN is 30 being served in. The format of a routing area is an NAI as defined in RFC 2486.

WO 01/19050 PCT/IBOO/01553 89 FIGURE 20K shows a Terminal Information Extension, which is used to identify terminal (e.g., the MN 112) capabilities, such as whether the terminal is SIP capable, H.323 capable, and the like). 5 FIGURE 20L shows the message format of a Registration Request message, which is based upon the MIP message as specified in RFC 2002. Notably, the Registration Request message includes a number of mandatory IPM extensions, such as NAI extensions, an 10 Authentication extension, a Routing Area extension, and an MN Layer 2 extension. The Registration Request message may optionally also include a Terminal Information extension. FIGURE 20M shows the message format for a 15 Registration Reply message, which is based upon the MIP message as specified in RFC 2002. Notably, the Registration Request Reply message includes at least two mandatory IPM extensions, including NAI extensions and an MN Layer 2 extension. 20 FIGURE 20N shows the message format for a Prepare for System Change message, which is based on the MIP Registration Request message as specified in RFC 2002. Notably, the Prepare for System Change message includes a number of mandatory IPM extensions, such as NAI 25 extensions, a Routing Area extension, and an LSF NAI extension. The Prepare for System Change message may optionally also include an Authentication extension and a Terminal Information extension. FIGURE 200 shows the message format for a System 30 Change message, which is based on the MIP Registration Request message as specified in RFC 2002. Notably, the WO 01/19050 PCT/IB00/01553 90 System Change message includes a number of mandatory IPM extensions, such as NAI extensions, a Routing Area extension, and an LSF NAI extension, an Authentication extension, and an MN Layer 2 extension. The System 5 Change message may optionally also include a Terminal Information extension. FIGURE 20P shows a preferred general format for IPM messages, such as described below with respect to FIGS. 20Q-20AC. The IPM message depicted by FIG. 20P comprises 10 a type field, a length field, and a data field. The type field defines the extension type. The length field represents the length of data in bytes, which may range from 0 to 255 bytes. The data field contains the data of the extension. 15 FIGURE 20Q shows the message format for an Activate Packet Service message, which is used to prepare the target xAN for allocating resources. Notably, the Activate Packet Service message includes at least two mandatory IPM extensions, including a Call Information 20 extension and an MN Layer 2 extension. FIGURE 20R shows the message format for an Activate Packet Service Ack message, which is a reply to Activate Packet Service message. Notably, the Activate Packet Service Ack message includes at least one mandatory IPM 25 extensions, namely, an MN Layer 2 extension. FIGURE 20S shows a message format for an Add L2 IP Association message, which is used to notify the xAN of the User's IP Address and the MN's Layer 2 address. It is sent to the edge router at the xAN (as indicated by 30 the RA). Notably, the Add L2 IP Association message WO 01/19050 PCT/IBOO/01553 91 includes at least two mandatory IPM extensions, including NAI extensions and an MN Layer 2 extension. FIGURE 20T shows the format for a Buffer Data message, which is used to request that the xAN buffer 5 data that is destined to a particular user. FIGURE 20U shows the format for a Buffer Data Ack message, which is used reply to Buffer Data message. Notably, the Result Code may be set either to one to indicate that a buffer is not allocated, or to zero to 10 indicate that the buffer is allocated to buffer data packets during handoffs. FIGURE 20V shows the format for a Cleanup message, which is sent to the xAN at de-registration for freeing up resources. 15 FIGURE 20W shows the format for a Cleanup Ack, which is sent in reply to the Cleanup message. FIGURE 20X shows the format for a Correspondent Node List message, which contains a list of CNs that are contemporaneously in session with the user. Notably, the 20 Correspondent Node List message includes at least two mandatory IPM extensions, including NAI extensions and a CN List extension. FIGURE 20Y shows the format for a Correspondent Node List Ack message, which is sent in reply to a 25 Correspondent Node List message. FIGURE 20Z shows the format for a Forward Data message, which is used to start forwarding buffered data from an old (previous) LSF to a new COA. FIGURE 20AA shows the format for a Forward Data Ack, 30 which is sent in reply to a Forward Data message.

WO 01/19050 PCT/IBOO/01553 92 FIGURE 20AB shows the format for a Handoff Required message, which is used to notify an old (previous) LSF about handoff requirement. Notably, the Handoff Required message includes at least one mandatory IPM extension, 5 namely, an MN Layer 2 extension. FIGURE 20AC shows the format for a Handoff Required Ack, which is sent in reply to a Handoff message. Notably, the Handoff Required Ack message includes at least one mandatory IPM extension, namely, an MN Layer 2 10 extension. 2.2.4.11.2 QOS AND POLICY ENFORCEMENT The local directory server (LDS) 430 and database 431 at the LSF 106 is the repository for mobile user's home policy rules. 15 The QoS and Policy Server 412 that have an LDAP interface can retrieve an MN user's home policy -rules from the LDS 430 and database 431. The enforcement of these policies is part of xAN implementation. One way of implementing an LDAP client-server 20 interface is specified in RFC 1823 and in "Unified Directory Service MLD Phase II" by Mark O'Brien of Nortel Networks. 2.2.4.11.3 SIMPLE IP SUPPORT A driving factor for Simple IP (i.e., wireline IP) 25 is the requirement that MNs that do not support MIP may be able to access LSFs and the IP network for Internet service and/or for private network service. Application nodes, i.e., CNs without MIP, accessing the serving system in the Simple IP mode are assigned 30 addresses dynamically by an LSF 106, which plays the role of an access manager.

WO 01/19050 PCT/IBOO/01553 93 The xAN/LSF interface as defined below retains IPM messaging between the xAN and LSF and encapsulates Access Request/Reject/Accept messaging. IPM includes at least two new extensions to be 5 defined for Simple IP, namely, an Access Request extension and an Access Accept/Reject extension, discussed further below with respect to FIGS. 20AD and 20AE. FIGURE 20AD shows the format for an Access Request 10 extension for encapsulating Access Request messages as specified in RFC 2138. FIGURE 20AE shows the format for an Access Accept/Reject extension for encapsulating an Access Accept/Reject message as specified in RFC 2138. 15 IPM also defines two new message types for Simple IP. One is a new type for IPM registration message and the second is a new type of registration reply, as discussed further below with respect to FIGS. 20AF and 20AG. 20 FIGURE 20AF shows the format for a Simple IPM Registration Request message, which is based upon the MIP message as specified in RFC 2002. Notably, the Simple IPM Registration Request message includes a number of mandatory IPM extensions, such as NAI extensions, a 25 Routing Area extension, a CN (without MIP) Layer 2 extension, and an Access Request extension. The Simple IPM Registration Request message may optionally also include an Authentication extension and a Terminal Information extension. 30 FIGURE 20AG shows the format for a Simple IP Registration Reply message, which is based upon the MIP WO 01/19050 PCT/IBOO/01553 94 message as specified in RFC 2002. Notably, the Simple IPM Registration Request message includes a number of mandatory IPM extensions, such as NAI extensions, an MN Layer 2 extension, and an Access Accept/Reject extension. 5 3. INTERFACES BETWEEN FRAMEWORK MODULES There are a number of different scenarios by which the components of the IPM architecture framework of the present invention may interface with each other and by which messages may flow between components. These 10 scenarios are enumerated as follows: 1. MN and xAN 2. MN and LSF 3. xAN and the LSF 4. Mobility manager functions between the LSF and 15 NSF 5. Mobility manager functions between LSFs 6. Mobility manager function and DDNS 7. Mobility manager function and DHCP 8. Mobility manager function and policy server 20 9. AAA function and the mobility manager servers 10. AAA function and the Authentication servers 11. AAA function and the policy server 12. AAA function and the accounting function 13. Accounting functions and billing systems 25 14. DDNS and DHCS 15. NSF and MNs 16. Directory Service Interface 17. Security messaging gateways and policy servers This document has described, to varying levels of 30 detail, the functionality of each of these interfaces. The remainder of this chapter will provide a consolidated WO 01/19050 PCT/IBOO/01553 95 list of interface requirements for several of the items on the above list and a set of message flows for registration, routing area update, and inter system handoff scenarios. 5 The interface requirements and message flows depict how user mobility is achieved in the "final" vision of the architecture, where the basic fundamental requirements are: " All service providers will provide data services for 10 their users. Therefore, it is not necessary.for the user to have a subscription with a specific wireless network provider just to gain access to the wireless networks. * A user's home network must create SLAs with all 15 networks, LSFs and Service Brokers, it wants it users to roam in. * IPSec AH and/or ESP are used for all security associations " The AAA protocol is used for all LSF to LSF and LSF 20 to NSF mobility functions. " For private network access, all tunneling is layer 3 tunneling (IP tunneling). There will be no layer 2 tunneling, e.g., L2TP. * There is no triangle routing unless there is a NSF 25 "hide the user" policy. Therefore, an LSF will maintain COAs for its network. 3.1 ROAMING MESSAGE FLOWS In operation, the present invention is adaptable to message flows for a number of different mobility WO 01/19050 PCT/IBOO/01553 96 scenarios, which scenarios may be categorized into at least three groups. A first group includes user registrations. A second group includes users roaming to new routing areas where there are no applications running 5 (i.e., where no data is being transferred). A third group includes users roaming to new routing areas where there are applications running (e.g., handoffs). The message flows for each scenario makes a number of different assumptions. For example, it is assumed 10 that there is at least one router at the edge of an xAN/LSF interface, and that an IP router is considered to be part of the xAN. It is further assumed that all messages sent between system components include fields (i.e., parameters). 15 However, the number of fields that may be included in a message are not limited by the fields described herein, and there may be a greater number of fields. It is still further assumed that an AAA function located in an LSF has full functionality, i.e., it has 20 knowledge of SLAs in place between itself and the NSFs, and it provides a mechanism for determining where a user's home AAA function is. It is also assumed that SAs have all been pre-established. It is still further assumed that the xAN's BCCHs are 25 broadcasting the IP address of an SMM, unless otherwise indicated. It is still further assumed that xANs are channelized xANs, such as TDMA, unless otherwise indicated. 30 It is still further assumed that, in handoff scenarios for channelized xANs, the xAN is responsible WO 01/19050 PCT/IBOO/01553 97 for buffering datagrams that are destined for the MN. In unchannelized xANs, the router at the xAN/LSF will be responsible for buffering. 3.1.1 INITIAL REGISTRATION, MN CONFIGURED WITH A 5 ROUTABLE IP ADDRESS FIGURE 21 is a message flow event sequence diagram which represents a user MN 112 establishing a packet data session (i.e., logging in) with his/her home network 104. The MN 112 is configured with a permanent IP address that 10 is associated with the user's home network 104. The home network 104 is configured with routable IP addresses. The message flow sequence shown in FIG. 21 is applicable to at least two scenarios: first, when the MN 112 is initially powered-on and, second, when a user 114 15 wants to connect the MN 112 to another service provider, e.g., a second or third service provider. The concept of "always on, always ready to receive/send data" is used herein to refer to an MN 112 configured to establish a connection with its home 20 network service provider 104 when the MN 112 is powered on. When the user wants to connect to another service provider, e.g., a second or third service provider, the user will initiate the connection by accessing a user 25 interface (not shown), by pushing a pre-configured button (not shown) on the MN 112, or the like, to thereby cause the MN 112 to send a Registration Request to the user's home network 104. Completion of the registration process results in a packet data session being established 30 between the user, via the LSF 106, and the user's home NSF 104.

WO 01/19050 PCT/IBOO/01553 98 Referring to FIG. 21, in an event 2102, after the user 114 powers-on the MN 112 (or initiates another service provider connection request), the MN 112 sends a Registration message to the xAN 110 of the user's home 5 network 104. The Registration message is sent to the IP address (i.e., the IP address of the SMM 464B ) that was contained in the BCCH. The Registration message includes a number of parameters (i.e., fields) 2102a 2102g. An NAI 2102a indicates the user who wants to 10 establish the data session. An IP Addr parameter 2102b is the configured permanent IP address of the MN 112, if the MN has a configured IP address. An Auth parameter 2102c is the user's authentication parameter, i.e., the user's digital signature. A Profile Type parameter 2102d 15 indicates the profile that the user wants to use. The profile may indicate the type of services the user has, the type of access into the network, and the like. A Terminal Info parameter 2102e contains information about capabilities of the terminal, such as whether support is 20 provided for L2 addresses, SIP, H.323, and the like. A RegType parameter 2102f indicates the type of registration being performed. An RA parameter indicates the name (NAI) of the current subnet point of attachment. In event 2104, the SMM 464B creates an AAA 25 Authentication Request, comprising the NAI parameter 2102a and Auth parameter 2102c, and forwards the Authentication Request to the LSF 106 local AAA function 462. In event 2106, the local AAA function 462 uses the 30 domain portion of the user's NAI to determine the home NSF 104 of the user 114. A lookup is performed to WO 01/19050 PCT/IBOO/01553 99 determine the IP address of the user's home AAA function 450 and the type of security association (SA) established between the LSF 106 and the NSF 104. IPSec authentication (AH) is preferably used for security. The 5 local AAA function 462 will then send the Authentication Request to the user's home AAA function 450. Before the packet is sent, an IPSec authentication (AH) is preferably performed on the message. In event 2108, the user's home AAA function 450 10 receives the Authentication Request. The AAA function will first validate the IPSec AH, and then perform a lookup to determine which server it should forward the message to. The user's home AAA function 450 then forwards the Authentication Request to the authentication 15 server 450b. In event 2110, the authentication server 450b authenticates the user 114. The authentication server 450b may perform a number of functions, all depending on the type of authentication. Digital signatures are 20 preferably used, so that the authentication server 450b would have received the user's digital signature. In the present case, the authentication server 450b would acquire the user's public key in a directory, which it would use to authenticate the user. In this case, the 25 user 114 has been authenticated. The authentication server 450b then generates an Authentication Response message that includes the user's NAI and a Flag 2110a that indicates the authentication passed. The authentication server 450b then sends the Authentication 30 Response to its home AAA function 462.

WO 01/19050 PCT/IBOO/01553 100 NOTE: It may be possible for the authentication server 450b to send information to the LSF 106 that will permit the LSF 106 to authenticate the user 114 while the user roams in the LSF. However, the LSF 106 must be able 5 to support the authentication mechanism required by the user 114. In event 2112, the home AAA function 462 will generate an IPSec AH and send the IPSec AH to the local AAA function 462 serving the user 114. 10 In event 2114, the local AAA function 462 validates the IPSec AH and passes it to the SMM 464B . The events 2104-2114 constitute the Authentication Procedure of FIG. 21. In event 2116, the SMM 464B establishes a packet 15 data session with the user's home NSF 104. This is achieved by sending the home NSF 104 a registration request. At least two parameters 2116a and 2116b, not included in the Registration Request of the event 2102, are added to the Request. First, an LSF Info parameter 20 2116a is added which will contain information about the LSF 106 and user mobility. Second, a COA parameter 2116b is added which includes an IP address that is used by the home NSF 104 router and correspondent nodes to tunnel datagrams to the MN 112 and LSF 106. The LSF Info 25 parameter 2116a also includes an indication of the type of COA, i.e., whether the COA is a router COA or an MN co-located COA. In event 2118, the local AAA function 462 uses the domain portion of the user's NAI to determine the home 30 system 106 of the user 114. A lookup is performed to determine the IP address of the user's home AAA function WO 01/19050 PCT/IBOO/01553 101 462 and the type of security association (SA) established between the LSF 106 and NSF 104. The local AAA function 462 will then send the Registration Request message to the user's home AAA function 450. Before the 5 Registration Request message is sent, an IPSec authentication (AH) is preferably performed on the message. In event 2120, the user's home AAA function 450 receives the Registration Request message. The AAA 10 function 450 first validates the IPSec AH, and then performs a lookup function to determine which server the message should be forwarded to. Since the message is a Registration Request, the home AAA function 450 forwards the message to the HMM 452B. 15 In event 2122, the HMM 452B performs at least three functions. First, the HMM 452B updates the local directory with the LSF 106 and mobility info. Second, the HMM 452B sends a route update message to the local router so that it can update the MN's IP address and COA. 20 Third, the HMM 452B creates a Registration Reply message that includes the user's NAI and the user's profile. The profile will contain, at a minimum, the maximum bandwidth to be allocated to the user 114. The HMM 452B then sends the Registration Reply to its home AAA function 450. 25 In event 2124, the home AAA function 450 will create an IPSec AH message and send it to the local AAA function 462 serving the user 114. In event 2126, the local AAA function 462 validates the IPSec AH message and passes it to the SMM 464B 30 The events 2116-2126 constitute the Registration Procedure of FIG. 21.

WO 01/19050 PCT/IB00/01553 102 In event 2128, the SMM 464B informs the xAN 110 of the User's NAI, the User's IP address and the MN's layer 2 address. The xAN 110 uses this information to route information to the MN 112. 5 In event 2130, the SMM 464B updates its local directory with the appropriate info. It also updates the policy database with the user's maximum bandwidth allowed. The SMM 464B may create an encryption key to be used by the user's MN 112 for over-the-air encryption. 10 The SMM 464B sends a Registration Reply to the xAN/LSF 106 router. In event 2132, the mobility agent at the xAN/LSF router must update the router's routing table to include the IP address of the MN 112. The xAN 110 must be 15 informed of the "binding" between the MN's IP Address and the MN's L2 Address. The xAN 110 then sends the registration reply to the MN 112. In event 2126, the local AAA function 462 validates the IPSec AH message and passes it to the SMM 464B . The events 2128-2132 20 constitute the Registration Reply Procedure of FIG. 21. 3.1.2 INITIAL REGISTRATION, MN CONFIGURED WITH A NON ROUTABLE IP ADDRESS FIGURE 22 is an message flow event sequence diagram 25 showing the flow of messages for a user connecting to his/her home network 104, wherein the MN 112 and the user's home network 104 are configured with non-routable IP addresses. FIGURE 22 is similar to FIG. 21 but for the MN 112 being provided with a co-located COA, i.e., an 30 IP address that may be used with nodes on the Internet to tunnel datagrams directly to the MN 112.

WO 01/19050 PCT/IB00/01553 103 The message flow depicted by FIG. 22 is applicable to at least two scenarios: first, when the MN 112 is initially powered-on and, second, when a user 114 wants to connect to another service provider, such as a second 5 or third service provider. In event 2202, the user has powered on the MN 112 (or initiated another service provider connection request). The MN 112 is configured to send a registration message to the user's home network. The 10 registration message is sent to the IP address (which is the IP address of the SMM) that was contained in the BCCH. The parameters are the same as described above with respect to FIG. 21. Event 2204 represents an authentication procedure 15 which similar to the authentication procedure described above with respect to events 2104-2114 of FIG. 21, and will therefore not be described in further detail herein. In event 2206, the SMM now needs to establish the packet data session with the user's home network 104. 20 This is achieved by sending the home network 104 a Registration Request. Two additional parameters are added to the registration message, namely, an LSF Info parameter 2206a and a COA parameter 2206b. The LSF Info parameter 2206a includes information about the LSF and 25 user mobility. The COA parameter 2206b contains the IP address that is used by the home network router and correspondent nodes to tunnel datagrams to the MN 112 and LSF 106. There is an indication of the type of COA (not co-located). 30 In event 2208, the local AAA function uses the domain portion of the user's NAI to determine the home WO 01/19050 PCT/IB00/01553 104 system of the user. A lookup is performed to determine the IP address of the user's home AAA function and the type of security association (SA) established between the LSF and NSF. The local AAA function will then send the 5 message to the user's home AAA function. Before the packet is sent, an IPSec authentication (AH) is performed on the message. In event 2210, the user's home AAA function receives the message. The AAA function will first validate the 10 IPSec AH. It then performs a lookup to see what server it should forward the message to. Since this is a registration request, it forwards the message to the HMM. In event 2212, the HMM 452B performs at least two functions. First, the HMM 452B updates the local 15 directory with the LSF 106 and mobility information. Second, the HMM 452B realizes that the COA is not an MN co-located COA which is necessary for MN's that are associated with private networks with non-routable IP addresses. The HMM 452B then creates a Registration 20 Reply message that includes the user's NAI, the user's profile, and an indication that an MN co-located COA must be allocated. The HMM 452B then sends the registration reply to its home AAA function 450 and a request for a co-located IP address. The HMM 452B then sends the 25 Registration Reply to its home AAA function 450. In event 2214, the AAA function 450 generates an IPSec AH message and sends it to the local AAA function 462 serving the user 114. In event 2216, the local AAA function 462 validates 30 the IPSec AH and forwards the IPSec AH message to the SMM 464B WO 01/19050 PCT/IB00/01553 105 In event 2218, the SMM 464B updates its local directory with the appropriate information. The SMM 464B also updates the policy database with the user's maximum bandwidth allowed. The SMM 464B is configured to then 5 allocate a co-located IP address for the MN 112. A request is made to the DHCP to allocate the address. The SMM 464B creates an Address Update Request message with the MN co-located COA to send to the HMM 452B. The Address Update Request message is then forwarded to the 10 local AAA function 462. In event 2220, the local AAA function 462 uses the domain portion of the user's NAI to determine the home NSF 104 of the user 114. A lookup is performed to determine the IP address of the user's home AAA function 15 450 and the type of security association (SA) established between the LSF 106 and the NSF 104. An IPSec authentication (AH) is then performed on the message. The local AAA function 462 then sends the Address Update Request message to the user's home AAA function 450. 20 In event 2222, the user's home AAA 450 server receives the Address Update Request message. The AAA function 450 will first validate the IPSec AH. It then performs a lookup to see what server it should forward the Address Update Request message to. Since the message 25 is an Address Update Request, it forwards the message to the HMM 452B. In event 2224, the HMM 452B will perform at least two additional functions. Send a route update message to the local router so it can update the MN's IP address and 30 MN 112 co-located COA. The HMM 452B then creates an Address Update Response message that includes the user's WO 01/19050 PCT/IB00/01553 106 NAI. The HMM function 452 then sends the Address Update Response message to its home AAA function 450. In event 2226, the home AAA function 450 will create an IPSec AH and send the Address Update Response message 5 to the local AAA function 462 serving the user 114. In event 2228, the local AAA function 462 validates the IPSec AH and passes the message on to the SMM 464B In event 2230, the SMM 464B will update its local 10 directory with the appropriate information. The SMM 464B may create an encryption key to be used by the user's MN 112. The SMM 464B will send-a Registration Reply to a mobility agent on the xAN 110/LSF 106 router. In event 2232, the mobility agent at the xAN 110/LSF 15 106 router updates the router's routing table to include the MN's IP address. The xAN 110 is notified of the "binding" between the MN's IP Address and the MN's L2 Address. The mobility agent then sends the Registration Reply to the MN 112. 20 3.1.3 INITIAL REGISTRATION IN THE CASE WHERE THE MN DOES NOT HAVE AN IP ADDRESS Figure 23 is a message flow event sequence diagram showing the flow of messages for a user connecting to his/her home network, wherein the MN and the user's home 25 network are configured with non-routable IP addresses. FIGURE 21 is similar to FIG. 23 but for the MN is not - configured with an IP address. The home network is, however, configured with routable IP addresses and will allocate a routable IP address to the MN. 30 This flow also applies to two scenarios: 1) when the MN is initially powered-on and, second, when a user wants WO 01/19050 PCT/IB00/01553 107 to connect to another service provider, such as a second or third service provider. In event 2302, the user has powered on the MN (or initiated another service provider connection request). 5 The MN is configured to send a registration message to the user's home network. The registration message is sent to the IP address (which is the IP address of the SMM) that was contained in the BCCH. The parameters are the same as defined in section 3.1.1. NOTE: the MN IP 10 Address should be set to zero (0.0.0.0). In event 2304, the authentication procedure is performed. See section 3.1.1 for details. In event 2306, the SMM now needs to establish the packet data session with the user's home network. This 15 is achieved by sending the home network a registration request. The registration message contains two additional parameters. First, the LSF Info will contain information about the LSF and user mobility. Second, the COA is the IP address that is used by the home network 20 router and correspondent nodes to tunnel datagrams to the MN/LSF. There is also an indication of the type of COA (not co-located). In event 2308, he local AAA function uses the domain portion of the user's NAI to determine the home system of 25 the user. A lookup is performed to determine the IP address of the user's home AAA function and the type of security association (SA) established between the LSF and NSF. The local AAA function will then send the message to the user's home AAA function. Before the packet is 30 sent, an IPSec authentication (AH) is performed on the message.

WO 01/19050 PCT/IB00/01553 108 In event 2310, the user's home AAA function receives the message. The AAA function will first validate the IPSec AH. It then performs a lookup to see what server it should forward the message to. Since this is a 5 registration request, it forwards the message to the HMM. In event 2312, the HMM updates the local directory with the LSF and mobility info. Additionally, since the MN does not have a permanent IP address, the HMM will also allocate an IP address via DHCP for the MN. The MN 10 IP address is dynamically updated in the home network's DDNS. Furthermore, the HMM sends a route update message to the local router to update the MN's IP address and COA. Moreover, the HMM creates a registration reply message 15 that includes the user's NAI, the user's profile, and the newly created MN IP address. After these functions are completed, the HMM sends the registration reply to its home AAA function. In event 2314, the AAA function will create an IPSec 20 AH and send the message to the local AAA function serving the user. In event 2316, the local AAA function validates the IPSec AH and passes the message on to the SMM. In event 2318, the SMM updates its local directory 25 with the appropriate information. It will also update the policy database with the user's maximum bandwidth allowed. The SMM realizes that the MN does not have an IP address. The SMM will send a registration reply to a mobility agent on the xAN/LSF router. The SMM will 30 include the MN's layer 2 address in the reply. The xAN WO 01/19050 PCT/IB00/01553 109 will use the layer 2 address to send the registration reply. In event 2320, the mobility agent at the xAN/LSF router must update the router's routing table to include 5 the MN's .IP address. The xAN must be told of the "binding" between the MN's IP Address and the MN's L2 Address. The mobility agent "updates" the datagram's destination address to be a broadcast address sends the registration reply to the xAN software and includes the 10 MN's L2 address so the xAN can route it to the MN. NOTE: If the xAN is an Ethernet access point, the broadcast message will be sent to all MNs on the link. 3.1.4 INITIAL REGISTRATION, HIERARCHICAL ROUTERS Figure 24 is a message flow event sequence diagram 15 showing the flow of messages for a user connecting to its home network where the home network is configured with routable IP addresses. FIGURE 21 is similar to FIG. 24 but for the hierarchy of routers in the LSF/xAN. Particularly, the xAN has a router at edge of the xAN/LSF 20 interface and there is another router, called the LSF router, which has a COA that is used to tunnel datagrams to. In event 2402, the user has powered on the MN (or initiated another service provider connection request). 25 The MN is configured to send a registration message to the user's home network. The registration message is sent to the IP address (which is the IP address of the SMM) that was contained in the BCCH. The parameters are the same as defined in section 3.1.1. 30 In event 2404, the authentication procedure is performed. See section 3.1.1 for details.

WO 01/19050 PCT/IBOO/01553 110 In event 2406, the registration procedure is performed. See section 3.1.1 for details. NOTE: The COA sent in the registration message is the COA of the LSF router. 5 In event 2408, the SMM will update its local directory with the appropriate information. The SMM will send a registration reply to a mobility agent on the xAN/LSF router. In event 2410, the mobility agent at the xAN/LSF 10 router must update the router's routing table to include the MN's IP address. When this occurs, some routing protocol, such as RIP, will update the local network with routing information so datagrams can be delivered to the xAN router, such as when the LSF router will receive a 15 route update and will know how to forward de-tunneled datagrams. The xAN must be told of the "binding" between the MN's IP Address and the MN's L2 Address. The mobility agent then sends the registration reply to the MN. 20 3.1.5 MN MOVES TO A NEW ROUTING AREA, NEW LSF When a user roams between LSFs, the user changes subnet points-of-attachments, therefore, the user changes Routing Areas. The LSF requires notification of the RA changes to re-authenticate the user to avoid fraudulent 25 users. In an IP centric network, it is advisable to always have the LSF authenticate the user. Additionally, the user may have access restrictions within the new RA, or a different IP router may need to provide tunneling services, via a new COA, to the MN while it is in the new 30 RA, both of which require notification of the LSF.

WO 01/19050 PCT/IBOO/01553 111 In this architecture, before the MN moves to the new LSF, it will send a registration request message to old LSF that indicates the MN is about to move to the new LSF. This triggers the old LSF to start queuing MN 5 datagrams. Figure 25 is a message flow event sequence diagram showing the flow of messages for a user roaming between LSFs. This mechanism is used whenever the user is changing RAs. 10 This type of movement indication would be most beneficial in access networks that do not depend on paging the MN. In other types of access networks, the messaging overhead incurred by sending the LSF an indication of a user/MN moving may not be as beneficial 15 because the number of MN's that will actually receive data during this process should be very small. Moreover, in RANs that are channelized, the LSF is still going to page the MN. When the registration process is invoked, it may be 20 necessary to perform registration for multiple users, all of who may be registered with their respective ISPs. The preferred method of registration occurs when the MN sends a registration message for each NAI that is in an active packet data session. 25 Registration may also occur when the MN sends a single registration message that includes all the NAIs and their associated parameters. A single registration message could result in a large message transmitted over the air, prone to transmission errors and, hence, requiring 30 retransmissions of long messages.

WO 01/19050 PCT/IBOO/01553 112 Furthermore, the MN can register by sending a single registration message for only one of the NAIs e.g. the one associated with the first active data session. If the LSF has a policy to authenticate users, the LSF will 5 request authentication for the single NAI. This may be a little risky since the authentication mechanism may be a weak authentication, such as a login ID and password, which is more prone to fraud (this is subject to the architecture supporting legacy authentication 10 mechanisms). Furthermore still, the MN can register by sending a single registration message that does not include any NAIs. The LSF could have a policy that initiates a unique challenge for each NAI associated with the MN 15 (NAIs should be associated with the MN's L2 Addr). If it is assumed that the LSF will always want the MN's NAI authenticated, however, the unique challenge scenario applied to each NAI produces more messaging as compared to first registration procedure described above. 20 FIGURE 35 is a message flow event sequence diagram showing the flow of messages for a MN moving from a first routing area on a first LSF to a second routing area on a second LSF. The initial procedure involves the System Change 25 Procedure, as indicated by events 2502-10. The first event 2502, the MN detects it will move to a new system (new LSF) and informs the current system (old xAN/LSF) of the impending move by sending a registration message to the "old" system (LSF) with a registration type of 30 "Prepare for System Change". The "old" system will have its router (xAN) start queuing datagrams for the MN. The WO 01/19050 PCT/IBOO/01553 113 parameters are the same as defined in section 3.1.1. The parameters in [brackets] are optional. In event 2504, the authentication procedure is performed, if necessary. See section 3.1.1 for details. 5 The authentication procedure may not be necessary if the MN and the LSF have established keys to be used for over the air encryption. In event 2506, the SMM informs the mobility agent on the old router to start buffering datagrams destined to 10 the user's MN. To complete the System Change Procedure, acknowledgements are sent by the router, event 2508, and the SMM, event 2510. In event 2512, the MN has determined it has crossed 15 over a LSF boundary (via a new system ID). The MN sends a registration message to the IP address (which is the IP address of the SMM) that is contained in the BCCH. The MN will send a registration request message for each active packet data session it has. In this scenario, 20 there is only one active packet data session. The message includes the old LSF's system ID. The SMM detects that the registration type is "System Change" and that the message includes the Old LSF ID. As a result, the SMM initiates the Contect Request 25 Procedure, as indicated by events 2514-22, to request MN information from the old LSF and have the old LSF start buffering datagrams destined to the MN. This is achieved by sending the old LSF a context request message via the local AAA function, event 2514. The SMM will put the old 30 LSF's NAI in the message so the local AAA function can route the message (to simplify this, the SMM may pass the WO 01/19050 PCT/IBOO/01553 114 IP address of the old LSF; this is an implementation detail. If there is more than one active packet data session for the MN, the MN will send a registration 5 request message for each active packet data session it has. This will incur multiple context requests being issued by the new LSF, but sending a single context request that includes the MN's L2 Addr to the old LSF can optimize it. 10 The context response includes MN information for all active packet data sessions. Hence, the new LSF will not have to send a context request message for each registration message. The local AAA function uses the domain portion of 15 the old LSF's NAI to determine the LSF's system. A lookup is performed to determine the IP address of LSF's AAA function and the type of security association (SA) established between the old LSF and new LSF. The local AAA function will then send the message to the LSF's AAA 20 function. Before the packet is sent, an IPSec authentication (AH) is performed on the message. In event 2516, he old LSF's AAA function receives the message. The AAA function will first validate the IPSec AH. It then performs a lookup to determine to 25 which server it should forward the message. Since this is a context request, it forwards the message to the SMM. In event 2518, the SMM informs the mobility agent on the old router to start buffering datagrams destined to the user's MN. The buffer data request can have 30 multiple MN IP addresses. Additionally, if the SMM had previously initiated a buffer request, such as during the WO 01/19050 PCT/IBOO/01553 115 System Change Procedure, the SMM does not have to reissue the request here. In event 2520, the router mobility agent updates the local router to start queuing datagrams destined to 5 the MN and then sends an ack message back to the SMM. In event 2522, the SMM creates a context response message with the MN's IP address(es) and sends it back to the new LSF SMM, in addition to performing normal AAA server functions. It is not necessary to send the user's 10 profile since it will be retrieved during the registration procedure described below. In event 2524, the Authentication Procedure is performed. See section 3.1.1 for details. In event 2526, the Registration Procedure is 15 performed. See section 3.1.1 for details. In event 2528, the Registration Reply Procedure is performed. See section 3.1.1 for details. In the Binding Update Procedure, indicated by events 2530-36, updates the MN's binding to include the 20 new LSF before the binding to the old LSF is canceled. In event 2530, the new LSF's SMM creates a Binding Update request message that includes the user's NAI and the COA of the router that the MN's datagrams need to be tunneled to and sends it to the old LSF's SMM, in 25 addition to performing all normal AAA server functions. This request will allow the old LSF to start forwarding the MN's datagrams. In event 2532, the old LSF's SMM sends a Forward Packets message to the mobility agent on the LSF/xAN 30 router to request that the router start forwarding datagrams to the new router's COA.

WO 01/19050 PCT/IBOO/01553 116 In event 2534, the mobility agent acknowledges the forward packets request. In event 2536, the SMM creates a Binding Update response message with the user's NAI and sends it to the 5 new LSF's SMM, in addition to performing normal AAA server functions. After the Binding Update Procedure is completed, the Registration Cancellation procedure, indicated by events 2538-44, cancels the registration of the MN to the 10 old LSF. In event 2538, after the user's home NSF performed the registration, it sends the old LSF a registration cancellation message, in addition to performing normal AAA server functions. The reason for sending the 15 registration cancellation is that there is a window where the home NSF may have sent a CN a binding update that had the old LSF's COA. The home NSF must now update the CN with the new COA and then perform the registration cancellation procedure. This will insure that the old 20 LSF will not stop forwarding datagrams to the MN prematurely. The registration procedure is being performed in parallel to the Binding Update procedure, which was initiated by the new LSF in event 2528. Also, it is not necessary for the NSF to have a retry counter 25 associated with the registration cancellation request. In event 2540, the old LSF's SMM initiates the cleanup after the Binding Update and the registration cancellation has completed. In event 2542, the router's mobility agent acks the message, and the old LSF acks the 30 registration cancellation reques in event. All the normal AAA server functions are performed.

WO 01/19050 PCT/IBOO/01553 117 3.1.6 MN MOVES TO A NEW RA, NEW XAN, SAME LSF FIGURE 26 is a message flow event sequence diagram showing the flow of messages for a user roaming between xANs within the same LSF. The registration request 5 message sent through the old xAN indicates movement to another system (xAN) and triggers the LSF to start queuing MN datagrams at the old xAN. In event 2602, the System Update procedure is performed. See section 3.1.1 for details. 10 In event 2604, the MN determines a xAN boundary has been crossed via a new system ID. The MN sends a registration message to the IP address, which is the IP address of the SMM, contained in the BCCH or Agent Advertisement. The MN sends a registration request 15 message for each active packet data session. In this scenario, there is only one active packet data session. The message includes the old LSF's system ID. In event 2606, the Authentication procedure is performed. See section 3.1.1 for details. 20 In event 2608, the Address Update procedure is performed. See section 3.1.1 for details. In event 2610, the Registration Reply procedure is performed. See section 3.1.1 for details. In event 2612, the LSF's SMM sends a Forward Packets 25 message to the mobility agent on the old xAN router to request that the router start forwarding datagrams to the new router's COA. These datagrams will be tunneled to the new router's COA. In event 2614, the mobility agent informs the 30 xAN/router to start forwarding packets and acks the Forward Data request.

WO 01/19050 PCT/IBOO/01553 118 In event 2616, the Registration Cancellation procedure is performed. See section 3.1.1 for details. 3.1.7 MN MOVES TO A NEW ROUTING AREA, SAME XAN/LSF, NEW COA 5 FIGURE 27 is a message flow event sequence diagram showing the flow of messages for a user roaming between RAs within the same xAN/LSF. At the xAN/LSF boundary, however, there are multiple routers and, hence, multiple routing areas each having their own COA. When the user 10 roams in a new RA, the associated COA must be updated at the user's home network. Alternatively, instead of allocating a new COA and updating the COA at the user's home network, the original router may be updated with information on how to route MN 15 datagrams to the new router(s). Since the present invention tries to avoid such configurations, it is preferred to update the COAs. In event 2702, the System Change Procedure is performed. See section 3.1.5 for details. 20 In event 2704, the MN has determined it has crossed over a routing area boundary. The MN sends a registration message for each active packet data session. In this scenario, there is only one active packet data session. The parameters are the same as defined in 25 section 3.1.1, brackets indicating optional parameters. In event 2706, the Authentication Procedure is performed. See section 3.1.1 for details. In event 2708, the SMM informs the mobility agent on the old router to start buffering datagrams destined to 30 the user's MN. The SMM, however, will not issue the WO 01/19050 PCT/IBOO/01553 119 buffer data request if it was performed during the System Change Procedure. In event 2710, the router mobility agent acknowledges the message. 5 In event 2712, the Address Update Procedure is performed. See section 3.1.2 for details. In event 2714, the Registration Reply Procedure is performed. See section 3.1.1 for details. In event 2716, the SMM informs the mobility agent on 10 the old router to start forwarding datagrams destined to the user's MN. These datagrams will be tunneled to the new router's COA. In event 2718, the router mobility agent acknowledges the message. 15 In event 2720, the SMM informs the mobility agent on the old router to have the xAN clean up its resources. In event 2722, the router mobility agent acknowledges the message. 3.1.8 MN MOVES TO A NEW ROUTING AREA, SAME XAN/LSF, 20 SAME COA FIGURE 28 is a message flow event sequence diagram showing the flow of messages for a user roaming to a new routing area where the MN's COA does not change. It should be noted that the MN does not know that the COA 25 will not change. During the system change procedure, however, the SMM will know and will not have to buffer datagrams destined to the MN. In event 2802, the System Change Procedure is performed. See section 3.1.5 for details. 30 In event 2804, the MN has determined it has moved to a new routing area. The MN sends a registration message WO 01/19050 PCT/IB00/01553 120 for each active packet data session. In this scenario, there is only one active packet data session. The parameters are the same as defined in section 3.1.1. The parameters in [brackets] are optional. 5 In event 2806, the Authentication Procedure is performed. See section 3.1.1 for details. In event 2808, if the user was authenticated, the SMM updates its local directory with the new RA and send a registration reply to the MN. Since a new COA was not 10 allocated for the user, there are no other functions that the SMM needs to perform. 3.1.9 MN MOVES BACK TO THE USER'S HOME NETWORK, COMBINED LSF/NSF FIGURE 29 is a message flow event sequence diagram 15 showing the flow of messages for a user roaming back into his/her home network, wherein the network is a combined LSF/NSF and the home subnet is accessed over some radio interface (RAN), not over an Ethernet connection. The combined LSF/NSF may be on the same subnet. 20 In event 2902, the System Change Procedure is performed. See section 3.1.5 for details. In event 2904, the MN determines it has crossed over a LSF boundary via a new system ID. The MN sends a registration message to the IP address, which is the IP 25 address of the SMM, contained in the BCCH. The MN will send a registration request message for each active packet data session. In this scenario, there is only one active packet data session. The message includes the old LSF's system ID. 30 In event 2906, the Context Request Procedure is performed. See section 3.1.5 for details.

WO 01/19050 PCT/IBOO/01553 121 In event 2908, the SMM creates an AAA Authentication Request and forwards it to the LSF's local AAA function. If the SMM and the Auth center are on the same subnet, or the same server, it is not necessary to have the 5 Authentication Request go through the AAA function. In event 2910, the local AAA function uses the domain portion of the user's NAI to determine the home system of the user. A lookup is performed to determine the IP address of the user's home AAA function and the 10 type of security association (SA) established between the LSF and NSF. The AAA function realizes it is its own network, so it forwards the message directly to the authentication server. In event 2912, the authentication server 15 authenticates the user. The authentication server then sends an authentication response to its home AAA function. In event 2914, the AAA function realizes it is its own network, so it forwards the message directly to the 20 SMM. In event 2916, the SMM creates a registration request message and forwards it to the LSF's local AAA function. If the SMM and the HMM are on the same subnet or the same server, it is not necessary to have the 25 Authentication Request go through a AAA function In event 2918, the local AAA function uses the domain portion of the user's NAI to determine the home system of the user. A lookup is performed to determine the IP address of the user's home AAA function and the 30 type of security association (SA) established between the LSF and NSF. The AAA function realizes it is its own WO 01/19050 PCT/IBOO/01553 122 network, so it forwards the message directly to the Authentication Server. In event 2920, the HMM updates the local directory with the LSF and mobility information. Additionally, the 5 HMM sends a route update message to the local router to can update the MN's IP address, which is the MN's IP address in this scenario. Moreover, the HMM creates a registration reply message that includes the user's NAI and sends the registration reply to its AAA function. 10 In event 2922, the AAA function realizes it is its own network, so it forwards the message directly to the SMM. In event 2924, the Registration Reply Procedure is performed. See section 3.1.1 for details. 15 In event 2926, the Binding Update Procedure is performed. See section 3.1.5 for details. In event 2928, the Registration Cancellation Procedure is performed. See section 3.1.5 for details. 3.1.10 MN MOVES TO A NEW RA, NEW LSF, NO MOVEMENT 20 INDICATION FIGURE 30 is a message flow event sequence diagram showing the flow of messages for a user roaming between LSFs wherein the MN does not send a registration request message to the old LSF that indicates the MN is about to 25 move. FIGURE 30 is similar to FIGURE 25 but for during the MN's transition to the new LSF, there is a window where the old LSF may lose datagrams destined to the MN while the MN was accessing the new LSF. This event sequence helps to minimize this window by having the new 30 LSF request the old LSF to start queuing datagrams for the MN. The size of the window may vary since the old WO 01/19050 PCT/IBOO/01553 123 LSF may be in the process of paging the MN and, hence, already queuing the datagrams. In event 3002, the MN has determined it has crossed over a LSF boundary (via a new system ID). The MN will 5 send a registration message for each active packet data session. In this scenario, there is only one active packet data session. In event 3004, the Context Request Procedure is performed. See section 3.1.5 for details. 10 In event 3006, the Authentication Procedure is performed. See section 3.1.1 for details. In event 3008, the Registration Procedure is performed. See section 3.1.1 for details. In event 3010, the Registration Reply Procedure is 15 performed. See section 3.1.1 for details. In event 3012, the Binding Update Procedure is performed. See section 3.1.5 for details. In event 3014, the Registration Cancellation Procedure is performed. See section 3.1.1 for details. 20 3.1.11 USER PACKET DATA SESSION DE-REGISTRATION FIGURE 31 is a message flow event sequence diagram showing the flow of messages for a user terminating a connection to their service provider. In event 3102, the user wants to disconnect (log 25 off) from their service provider. Via some interface or configured button, the user selects the provider they want to disconnect from. The MN sends the de registration message with the RegType field set to de registration. 30 In event 3104, the authentication procedure is performed. See section 3.1.1 for details.

WO 01/19050 PCT/IBOO/01553 124 In event 3106, the SMM sends a registration request with the to the local AAA function. In event 3108, the local AAA function uses the domain portion of the user's NAI to determine - the home 5 system of the user. A lookup is performed to determine the IP address of the user's home AAA function and the type of security association (SA) established between the LSF and NSF. The local AAA function will then send the message to the user's home AAA function. Before the 10 packet is sent, an IPSec authentication (AH) is performed on the message. In event 3110, the user's home AAA function receives the message. The AAA function will first validate the IPSec AH. It then performs a lookup to see what server 15 it should forward the message to. It forwards the message to the HMM. In event 3112, the HMM sends a route update message to the local router to remove the MN's IP address and COA from the routing table. Additionally, the HMM updates 20 the local directory and the user's entry in the DDNS. Furthermore, if the MN's IP address was allocated via DHCP, the HMM will release the IP address. The HMM then creates a deactivate response message that includes the user's NAI and sends it to its home AAA function. 25 In event 3114, the AAA function will create an IPSec AH and send the message to the local AAA function serving the user. In event 3116, the local AAA function validates the IPSec AH and passes the message on to the SMM.

WO 01/19050 PCT/IBOO/01553 125 In event 3118, the SMM will cleanup and send the registration reply to the mobility agent at the xAN/LSF router. In event 3118, the mobility agent will remove the 5 MN's IP address from the router's route table and forward the registration reply to the-MN. 3.1.12 INTER SYSTEM (INTER LSF) HANDOFF FIGURE 32 is a message flow event sequence diagram showing the flow of messages for a handoff between two 10 LSFs. In this sequence of events, the old LSF recieves a handoff indication from the xAN to insure that the MN's datagrams are queued. The xAN must send the handoff required message in the event that the MN's registration 15 request, with RegType set to "Prepare for System Change", is not received by the old LSF's SMM. In order to prevent loss of data, datagrams destined to the MN are buffered. In event 3202, the System Update Procedure is 20 performed. See section 3.1.5 for details. In event 3204, the xAN via the mobility agent sends the SMM a handoff required message, which indicates the target LSF for the handoff. The Handoff Procedure, as illustrated by events 25 3206-12, allocates the required resources to facilitate the communication with the new LSF. In event 3206, the SMM forwards the handoff required message to the new LSF SMM. All normal AAA functions are performed. The Call Info field includes the current 30 active data session for the MN. The LSF domain is sent WO 01/19050 PCT/IBOO/01553 126 to identify the old LSF to the SMM in the new LSF. The LSF domain can be used by the new LSF's SMM for routing. The LSF does not have to get involved with the actual handoff. The Handoff Procedure can be performed 5 by the xANs themselves. If the xANs do perform the procedure, they are responsible for queuing the MN's datagrams. In event 3208, the handoff required message indicates the target for the handoff. The SMM sends an 10 activate packet service request to the xAN to allocate the appropriate resources. An activate packet service request is sent for every active session that is listed in the Call Info field. In event 3210, the xAN allocates the appropriate 15 resources and sends an activate packet service response back to the SMM. In event 3212, the new SMM sends a handoff required acknowledgement to the old SMM. Normal AAA functions are performed. 20 In event 3214, the SMM sends a Handoff required acknowledgement message to the mobility agent on the xAN router to indicate that the handoff initialized. The handoff required message also triggers the queing of datagrams. 25 In event 3216, the MN retunes to the appropriate frequency. The MN realizes it has crossed over a LSF boundary via a new system ID. It also realizes that there are active application sessions, and, hence, it will set the RegType to be "SystemHO". The MN sends a 30 registration request message for each active packet data session. In this scenario, there is only one active WO 01/19050 PCT/IBOO/01553 127 packet data session. The message includes the old LSF's system ID. In event 3218, the Context Request Procedure is performed. See section 3.1.5 for details. If the LSF is 5 responsible for performing the Handoff Procedure, this step does not have to be performed. In event 3220, the Authentication Procedure is performed. See section 3.1.1 for details. While authentication does not need to be performed at this 10 step, it is preferred. Alternatively, a unique challenge to authenticate the user may be performed upon handoff completion. In event 3222, the Registration Procedure is performed. See section 3.1.1 for details. 15 In event 3224, the Registration Reply Procedure is performed. See section 3.1.1 for details. In event 3226, the Binding Update Procedure is performed. See section 3.1.5 for details. The Update CN Procedure, events 3228-38, updates 20 the correspondence nodes with which it is MN is in communication. In event 3228, the MN realizes that it is in a new system and has active application session; hence, it sends the SMM a list of correspondent nodes with which it 25 is in communications. Alternatively, the home network can request the CN list from the MN after the home network was updated with the new COA. In event 3230, the SMM forwards the message to the HMM at the MN's NSF. Normal AAA functions are performed.

WO 01/19050 PCT/IBOO/01553 128 In event 3232, the HMM acknowledges the correspondent node list. Normal AAA functions are performed. In event 3232, the SMM forwards the message to the 5 MN. In event 3234, the HMM receives the CN list and sends binding updates that include the MN's new COA to the CNs. In event 3236, the CNs acknowledge the binding 10 update. In event 3238, the Registration Cancellation Procedure is performed. See section 3.1.5 for details. 3.1.13 INTER XAN HANDOFF, SAME LSF FIGURE 33 is a message flow event sequence diagram 15 showing the flow of messages for a handoff between two xANs on the same LSF. In event 3302, the System Change Procedure is performed. See section 3.1.5 for details. In event 3304, the xAN via the mobility agent sends 20 the SMM a handoff required message, which indicates the target LSF for the handoff. In event 3306, the Handoff Procedure is performed. See section 3.1.12 for details. In event 3308, the SMM sends a Handoff required 25 acknowledgement message to the mobility agent on the xAN router to inform the xAN that handoff is initialized. The handoff requided acknowledgement also triggers the queuing of datagrams for the MN. In event 3310, the MN retunes to the appropriate 30 frequency. The MN realizes it has crossed over a LSF boundary via a new system ID. Additionally, the MN WO 01/19050 PCT/IBOO/01553 129 realizes that there are active application sessions and sets the RegType to be "SystemHO". The MN sends a registration request message for each active packet data session. In this scenario, there is only one active 5 packet data session. The message includes the old LSF's system ID. In event 3312, the Authentication Procedure is performed. See section 3.1.1 for details. In event 3314, the Registration Procedure is 10 performed. See section 3.1.1 for details. In event 3316, the Registration Reply Procedure is performed. See section 3.1.1 for details. In event 3318, the old LSF's SMM sends a Forward Packets message to the mobility agent on the LSF/xAN 15 router to request the router start forwarding datagrams to the new router's COA. These datagrams will be tunneled to the new router's COA. In event 3320, the mobility agent informs the xAN/router to start forwarding packets. 20 In event 3322, the MN realizes that it is in a new system and has active application sessions; hence, it sends its home network a list of correspondent nodes with which it is in communication. Alternative the home network may request the CN list from the MN after the 25 home network was updated with the new COA. In event 3324, the HMM acks the correspondent node list. In event 3326, after the HMM receives the CN list and the new COA, it will send binding updates, which 30 include the new COA to the CNs.

WO 01/19050 PCT/IB00/01553 130 In event 3328, the CNs will acknowledge the binding update. In event 3330, the Registration Cancellation Procedure is performed. See section 3.1.5 for details. 5 3.1.14 INTER XAN HANDOFF, SAME LSF, HIERARCHICAL ROUTERS FIGURE 34 is a message flow event sequence diagram showing the flow of messages for a handoff between two xANs on the same LSF. FIG. 34 is similar to FIGURE 33 10 but for the FIG. 34 includes a hierarchy of routers in the LSF/xAN. In event 3402, the System Change Procedure is performed. See section 3.1.5 for details. In event 3404, the xAN via the mobility agent on the 15 xAN router sends the SMM a handoff required message which indicates the target LSF for the handoff. In event 3406, the Handoff Procedure is performed. See section 3.1.12 for details. In event 3408, the SMM sends a Handoff required 20 acknowledgement message to the mobility agent on the xAN router to indicate that handoff is initilized. Additionally, the handoff required acknowledgement triggers datagram queuing for the MN. In event 3410, the MN retunes to the appropriate 25 frequency. The MN realizes it has crossed over a LSF boundary via a new system ID. It also realizes that there are active application sessions, hence it will set the RegType to be "SystemHO". The MN will send a registration request message for each active packet data 30 session. In this scenario, there is only one active WO 01/19050 PCT/IBOO/01553 131 packet data session. The message includes the old LSF's system ID. In event 3412, the Authentication Procedure is performed. See section 3.1.1 for details. 5 In event 3414, the Registration Procedure is performed. See section 3.1.1 for details. In event 3416, the SMM updates its local directory with the appropriate information. The SMM will send a registration reply to a mobility agent on the xAN/LSF 10 router. In event 3418, the mobility agent at the xAN/LSF router must update the router's routing table to include the MN's IP address. When this occurs, some routing protocol, e.g., RIP, updates the local network with 15 routing information so datagrams can be del-ivered to the xAN router, i.e., the LSF router will receive a route update and will know how to forward de-tunneled datagrams. The xAN must be told of the "binding" between the MN's IP Address and the MN's L2 Address. The 20 mobility agent then sends the registration reply to the MN. In event 3420, the old LSF's SMM sends a Forward Packets message to the mobility agent on the LSF/xAN router to request that the router start forwarding 25 datagrams to the new router's COA. These datagrams will be tunneled to the new router's COA. In event 3422, the mobility agent informs the xAN/router to start forwarding packets. In event 3424, the Update CN Procedure is performed. 30 See section 3.1.12 for details.

WO 01/19050 PCT/IBOO/01553 132 In event 3426, the Registration Cancellation Procedure is performed. See section 3.1.5 for details 4. BASE PROTOCOL SPECIFICATIONS 4.1 INTRODUCTION 5 4.2 IPM MESSAGE FLOWS 4.2.1 IPM MN REGISTERS FROM THE IPM LSF Referring to FIGURE 35, Agent Discovery, events 3502-3504, is the method by which a Mobile Node (MN) determines whether it is currently connected to its home 10 network or to a foreign network, and by which a MN can detect when it has moved from one network to another. Home agents and foreign agents may advertise their availability on each link for which they provide service. A newly arrived MN can send a solicitation on the link to 15 learn if any prospective agents are present. The Agent Discovery Process is primarily handled through Agent Solicitation and Agent Advertisement. Agent Solicitation, event 3502, is the broadcast/multicast message sent by the IPM MN to detect 20 a Service Provider in the event that the IPM MN has not received an Advertising Agent message. The Agent Solicitation message contains, as the source address, the Mobile IP address belonging to the interface from which this message is sent, or 0. The destination address is 25 the configured solicitation address. In addition to a checksum value, a type value of 10 and a code value of 0 is contained in the message. In event 3504, Agent Advertisement messages are sent periodically, either as a broadcast or multicast for the 30 visiting IPM MN to recognize the availability of service and to keep track of their point of attachment. The WO 01/19050 PCT/IBOO/01553 133 message contains: a source address of the IP address belonging to the interface from which this message is sent; a destination address of the configured Advertisement Address or the IP address of a neighboring 5 host; a type field of 9; a code field of 0; a checksum value, the number of router addresses advertised in this message; the number of 32-bit words of information per each router address (2, in the version of the protocol described here); the maximum number of seconds that the 10 router addresses may be considered valid; the sending router's IP address(es) on the interface from which this message is sent; and the preferability of each router address as a default router address, relative to other router addresses on the same subnet. Additionally, the 15 Agent Advertisement message contains the Mobility Agent Advertisement and ANI-NAI Extensions. The purpose of the Registration Process, events 3506-3540, is for the IPM MN to inform the HMM of the NSF (Network Serving Function) of its current location to 20 which data packets can be forwarded to the IPM MN. The Registration process also includes the authenticating and authorizing of the IPM MN to have access to the visited network or LSF (Local Serving Function). In event 3506-3508, the Registration Request message 25 is sent by the IPM MN to the SMM to register for the service. The Registration Request contains: the source IP address of the MN; the destination address of the COA within the ANI component; a type field of 0; the flags as in RFC2002; the lifetime requested by MN from the HMM or 30 Home; the home IP address of the MN; the Home Agent's address of the MN; the Care-of-Address of the MN; and the WO 01/19050 PCT/IBOO/01553 134 identification, to provide replay protection. Additionally, the User-NAI Extension, L2-Address Extension (Optional), MN-Home Authentication Extension, Registration-Type Extension, Previous-SMM-NAI Extension 5 (Optional), ANI-NAI Extension (Optional), MN-SMM Authentication Extension (Optional), ANI-SMM Authentication Extension (Optional), and ANI-HMM Authentication (Optional) are used in the Registration Request. The extensions are described further in section 10 4.4. In events 3510-14, the AAA-Registration-Request message is used to carry out various kinds of registrations; these registrations are encapsulated in the IPM-Registration-Type AVP. This message is used by 15 SMM to authenticate and authorize the user. The AAA-Registration-Request message is of the format of DIAMETER. The SMM sends the message to HMM with at least the mandatory fields of Command Code AVP of 335; User-Name AVP; Host-Name AVP; IPM-Registration-Request 20 AVP; IPM-Registration-Request AVP; IPM-Care-of-Address AVP; and the IPM-Routing-Area-NAI AVP. The IPM Registration-Request AVP is the AVP which carries the message received from the MN, which is encapsulated in the AVP format for the Home domain to authenticate the 25 user. The HMM processes this message based on the Registration-Type AVP, which carries the type of registration requested. The AVPs that can optionally be used in the Registration Request message include, and are further 30 explained in section 4.5, Destination-NAI AVP, IPM Client-Address AVP, Home-Agent-Address AVP, IPM-SMM-NAI WO 01/19050 PCT/IBOO/01553 135 AVP, IPM-Terminal-Type AVP, IPM-Profile-Type AVP, Proxy State AVP, Timestamp AVP, Nonce AVP, and Integrity-Check Value AVP. In event 3516, the Service Request message is sent 5 from the HMM to the ISC (IPM Security Center) to authenticate a user or message, generate, renew, or delete session secret keys. It also can be sent from the PPS Manager to the ISC to generate or construct the IPMC. The Service Request message contains: a type of 10 USERSERVICEREQUESTMSG; a sub-type of 0; the length of the message payload including all the extensions; a 64 bit number used for matching User Service Request messages with User Service Reply messages, and for protecting against replay attacks of User Service Request 15 messages; and, in phase I, this extension has the user NAI and in the future will have an index which will be used to index the user data in the UDS. The Service Request message uses the extensions, which are explained in further detail in section 4.4, 20 User Authentication Information Extension, Control Message Authentication Extension, Session Key Allocation Extension 0..N, Session Key Lifetime Renewal Extension 0..N, and Session Key Delete Extension 0..N. In event 3518, the Service Reply message is sent 25 from the ISC (IPM Security Center) to the HMM in response to a Service Request message. The message exchanged between the ISC and the HMM contains: a type of USERSERVICEREPLYMSG; a sub-type of 0; the length of the message payload including all the 30 extensions; a code; a 64-bit number used for matching User Service Request messages with User Service Reply WO 01/19050 PCT/IBOO/01553 136 messages, and for protecting against replay attacks of User Service Request messages; and a User NAI, which in phase I has the user NAI and in the future will have an index which will be used to index the user data in the 5 UDS. The code value is defined as the following hexadecimal values: 00000001 User Authenticated successfully. 00000002 All required keys have been allocated. 10 00000003 Some keys have been allocated. 00000004 User Authentication failed. 00000005 Key Lifetime Renewal is completely honoured. 00000006 Key Lifetime Renewal is partially 15 honoured. 00000007 User Account is created successfully. 00000008 User is deleted successfully. Additionally, the following Extensions, which are described in greater detail in section 4.4, are used in 20 the Service Response message: Control Message Authentication Extension; Session Key Allocation Extension 0..N; Session Key Lifetime Renewal Extension 0..N; and Session Key Delete Extension 0..N. In event 3524, the Add Tunnel Entry message is sent 25 by the HMM to instruct the ITS to set up a tunnel entry point. The message exchanged between the HMM and the ITS contains: a code of 1; the length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender 30 must ensure the identifier in a message is locally unique at any given time.

WO 01/19050 PCT/IBOO/01553 137 Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Add Tunnel Entry message: Host NAI Extension, Flag Extension, Lifetime Extension, Mobile Node IP Address 5 Extension, User NAI Extension (Optional), and Tunnel Entry IP Address Extension. In event 3526, the Add Tunnel Entry Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Entry message. The message exchanged between the ITS and 10 the HMM contains: a code of 2; the length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. 15 Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Add Tunnel Entry message: Host NAI Extension, Result Code Extension, Mobile Node IP Address Extension (Optional), and User NAI Extension (Optional). 20 In events 3528-32, the AAA Registration Reply message is the response message sent by the HMM to the SMM to indicate the result of the AAA-Registration Request message. The AAA-Registration Reply message is of the format 25 of DIAMETER, and contains a DIAMETER Header, a Command Code AVP of 336, a Destination-NAI AVP, Host-Name AVP, User-Name AVP, IPM-Registration-Response-Code AVP, IPM Client-Address AVP, and IPM-Registration-Reply AVP. The HMM sends a message to the SMM with at least the 30 mandatory fields in response to AAA-Registration Request message. The IPM-Registration Response Code AVP indicates WO 01/19050 PCT/IBOO/01553 138 the success or failure of the request. The IPM Registration Reply message AVP contains the reply message built by HMM with authentication. The SMM has to use this AVP to send a reply to ANI/MN. 5 Additionally, the Registration Reply message can optionally use the following AVPs, which are discussed in further detail in section 4.5: IPM-Profile AVP, IPM-SMM MN-Key AVP, IPM-HMM-NAI AVP, Proxy-State AVP, Time AVP, Nonce AVP, and Integrity-Check-Value AVP. 10 In event 3534, the Add Tunnel Exit message is sent by the SMM to instruct the ITS to set up a tunnel exit point. The message exchanged between the SMM and the ITS contains: a code of 3; the length of the message including the header fields; and an identification used 15 in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. Additionally, the Extensions, which are explained further in section 4.4, used in the Add Tunnel Exit 20 message are: Host NAI Extension, Lifetime Extension, Mobile Node IP Address Extension, User NAI Extension (Optional), and Tunnel Exit IP Address Extension. In event 3536, the Add Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel 25 Exit message. The message exchanged between the ITS and the SMM contains: a code of 4; the length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique 30 at any given time.

WO 01/19050 PCT/IBOO/01553 139 Additionally, the Extensions, which are explained further in the section 4.5, used in the Add Tunnel Exit Acknowledgement message are: Host NAI Extension, Result Code Extension, Mobile Node IP Address Extension 5 (Optional), User NAI Extension (Optional), and Tunnel Forwarding IP Address Extension. In events 3538-40, the Registration Reply message is sent by the SMM to the IPM MN to indicate the result of the Registration Request message sent. The message 10 exchanged between the SMM and the IPM MN contains: a type of 3; a code for all the existing MIP Response codes, this field is being extended to include IPM specific items; the Home lifetime for the registration; the IP address of the MN; the Home Agent's address of the 15 MN; and the identification, to provide replay protection. Additionally, the Extensions, which are explained further in section 4.4, used in the Registration Reply message are: User-NAI Extension, SMM-Key Extension (Optional), MN-Home Authentication Extension, Local 20 Registration Lifetime Extension (Optional), SMM-NAI Extension (Optional), MN-SMM Authentication Extension (Optional), and ANI-SMM Authentication Extension (Optional). 4.2.2 IPM MN REGISTERS FROM IPM NSF 25 FIGURE 36 is a message flow event sequence diagram showing the flow of messages for IPM MN register from IPM NSF. In events 3602-3604, the Agent Discovery Process is 30 performed. See section 4.2.1 for details.

WO 01/19050 PCT/IB00/01553 140 In event 3606-3608, the Registration Request message is sent by the IPM MN to the HMM to register for the service. See section 4.2.1 for the message exchanged between the IPM MN and the HMM. 5 In event 3610, the Service Request message is sent. See section 4.2.1 for details. In event 3612, the Service Response message is sent. See section 4.2.1 for details. In event 3614-16, the Registration Reply message is 10 sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See section 4.2.1 for details. 15 4.2.3 IPM MN DISCONNECT DETECTION FIGURE 37 is a message flow event sequence diagram showing the flow of messages for IPM MN disconnect detection. In event 3702, the Registration Request message is 20 sent by the IPM MN to the ANI when a disconnect is detected. See section 4.2.1 for details but for MN-Home Authentication Extension (Optional). In event 3704, the Registration Reply message is sent by the ANI to the IPM MN to indicate the result of 25 the Registration Request message sent. See section 4.2.1 for details but for the MN-Home Authentication Extension (Optional).

WO 01/19050 PCT/IBOO/01553 141 4.2.4 IPM MN RE-REGISTERS FROM IPM LSF FIGURE 38 is a message flow event sequence diagram showing the flow of messages for IPM MN re-registers from IPM LSF. 5 In event 3802-3804, the Registration Request message is sent. See section 4.2.1 for details. In event 3806-10, the AAA-Registration Request message is sent. See section 4.2.1 for details. In event 3812, the Service Request message is sent. 10 See section 4.2.1 for details. In event 3814, the Service Reply message is sent. See section 4.2.1 for details. In event 3816-20, the AAA-Registration Reply message is sent. See section 4.2.1 for details. 15 In event 3822-24, the Registration Reply message is sent. See section 4.2.1 for details.

WO 01/19050 PCT/IBOO/01553 142 4.2.5 IPM MN RE-REGISTERS FROM IPM NSF FIGURE 39 is a message flow event sequence diagram showing the flow of messages for IPM MN re-registers from IPM NSF. 5 In events 3902-3904, the Registration Request message is sent. See section 4.2.1 for details. In event 3906, the Service Request message is sent. See section 4.2.1 for details. In event 3908, the Service Reply message is sent. 10 See section 4.2.1 for details. In events 3910-3912, the Registration Reply message is sent. See section 4.2.1 for details. 4.2.6 IPM MN DE-REGISTERS FROM IPM LSF 15 FIGURE 40 is a message flow event sequence diagram showing the flow of messages for IPM MN de-registers from IPM LSF. In events 4002-4004, the Registration Request message is sent. See section 4.2.1 for details. 20 In events 4006-4010, the AAA-Registration Request message is sent. See section 4.2.1 for details. In event 4012, the Service Request message is sent. See section 4.2.1 for details. In event 4014, the Service Reply message is sent. 25 See section 4.2.1 for details. In event 4016, the Delete Tunnel Entry message is sent by the HMM to instruct the ITS to delete a tunnel entry point. The message exchanged between the HMM and the ITS contains: a code of 7; a length of the message 30 including the header fields; an identification used in matching requests and acknowledgements. The sender must WO 01/19050 PCT/IBOO/01553 143 ensure the identifier in a message is locally unique at any given time. Additionally, extensions, which are discussed further in section 4.4, used in the Delete Tunnel Entry message are: Host NAI Extension; Mobile 5 Node IP Address Extension; and User NAI Extension (Optional). In event 4018, the Delete Tunnel Entry Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Entry message. The identification field 10 should be used for matching with the Delete Tunnel Entry message. The message exchanged between the ITS and the HMM contains: a code of 8; a length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender 15 must ensure the identifier in a message is locally unique at any given time. Additionally, extensions, which are discussed further in section 4.4, used in the Delete Tunnel Entry Acknowledgement message are: Host NAI Extension; Result Code Extension; Mobile Node IP Address 20 Extension (Optional); andUser NAI Extension (Optional). In events 4020-4024, the AAA-Registration Reply message is sent. See section 4.2.1 for details. In event 4026, the Delete Tunnel Exit message is sent by the SMM to instruct the ITS to delete a tunnel 25 exit point. The message exchanged between the SMM and the ITS contains: a code of 9; a length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique 30 at any given time. Additionally, extensions, which are discussed further in section 4.4, used in the Delete WO 01/19050 PCT/IBOO/01553 144 Tunnel Exit message are: Host NAI Extension; Mobile Node IP Address Extension (Optional); User NAI Extension (Optional); and Tunnel Exit IP Address Extension. In event 4028, the Delete Tunnel Exit 5 Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. The message exchanged between the ITS and the SMM contains: a code of 10; the length of the message 10 including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. . Additionally, extensions, which are discussed further in section 4.4, used in the Delete 15 Tunnel Exit Acknowledgement message are: Host NAI Extension; Result Code Extension; Mobile Node IP Address Extension (Optional); and User NAI Extension (Optional). In events 4030-32, the Registration Reply message is sent. See section 4.2.1 for details. 20 4.2.7 IPM MN DE-REGISTERS FROM IPM NSF FIGURE 41 is a message flow event sequence diagram showing the flow of messages for IPM MN De-registers from IPM NSF. In events 4102-4104, the Registration Request 25 message is sent. See section 4.2.1 for details. In event 4106, the Service Request message is sent. See section 4.2.1 for details. In events 4108, the Service Reply message is sent. See section 4.2.1 for details. 30 In events 4110-4112, the Registration Reply message is sent. See section 4.2.1 for details.

WO 01/19050 PCT/IBOO/01553 145 4.2.8 IPM MN HANDOFFS FROM ANI TO ANI IN THE SAME SMM (DIFFERENT ITS) FIGURE 42 is a message flow event sequence diagram 5 showing the flow of messages for IPM MN handoffs from ANI to ANI in the same SMM, different ITS. In events 4202-4204, the Registration Request message is sent. See section 4.2.1 for details. In events 4206, 4212, and 4218, the AAA-Registration 10 Request message is sent. See section 4.2.1 for details. In event 4208, the Add Tunnel Exit message is sent. See section 4.2.1 for details. In event 4210, the Tunnel Forwarding message is sent by the SMM to instruct the ITSO to set up tunnel 15 forwarding. The message exchanged between the SMM and the ITSO contains: a code of 5; a length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique 20 at any given time. Additionally, extensions, which are discussed further in section 4.4, used in the Tunnel Forwarding message are: Host NAI Extension; Mobile Node IP Address Extension; User NAI Extension (Optional); Lifetime Extension; and Tunnel Exit IP Address Extension. 25 In event 4214, the Add Tunnel Exit Acknowledgement message is sent. See section 4.2.1 for details. In event 4216, the Tunnel Forwarding Acknowledgement message is sent by the ITSO to acknowledge the Tunnel Forwarding message. The identification field should be 30 used for matching with the Tunnel Forwarding message. The message exchanged between the ITSO and the SMM WO 01/19050 PCT/IBOO/01553 146 contains: a code of 6; a length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given 5 time. Additionally, extensions, which are discussed further in section 4.4, used in the Tunnel Forwarding Acknowledgement message are: Host NAI Extension; Mobile Node IP Address Extension; User NAI Extension (Optional); and Result Code Extension. 10 In. event 4220, the Add Tunnel Entry message is sent. See section 4.2.1 for details. In event 4222, the Add Tunnel Entry Acknowledgement message is sent. See section 4.2.1 for details. In event 4224-4228, the AAA-Registration Reply 15 message is sent. See section 4.2.1 for details. In event 4230, the Delete Tunnel Exit message is sent. See section 4.2.6 for details. In event 4232, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.2.6 for 20 details. In event 4234-36, the Registration Reply message is sent. See section 4.2.1 for details. 4.2.9 IPM MN HANDOFFS FROM ANI TO ANI IN THE SAME SMM (SAME ITS) 25 FIGURE 43 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from ANI to ANI in the same SMM, same ITS. In event 4302-4304, the Registration Request message is sent. See section 4.2.1 for details. 30 In event 4310-4314, the AAA-Registration Request message is sent. See section 4.2.1 for details.

WO 01/19050 PCT/IBOO/01553 147 In event 4316-4320, the AAA-Registration Reply message is sent. See section 4.2.1 for details. In event 4322-4324, the Registration Reply message is sent. See section 4.2.1 for details. 5 4.2.10 IPM MN HANDOFFS FROM SMM TO SMM FIGURE 44 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from SMM to SMM message is sent. See section 4.2.1 for details. In events 4402-4404, the Registration Request 10 message is sent. See section 4.2.1 for details. In events 4406, 4408, and 4410, the AAA-Registration Request message is sent. See section 4.2.1 for details. In events 4407, 4409, and 4411, the AAA-Context Request message is sent by the current SMM of the User to 15 the previous SMM to request the Context-Data of the User's session. The AAA-Context-Request message is of the format of DIAMETER. The current SMM of the MN sends this message to previous SMM, to request for the context of the user's 20 data and also to request to forward the data to the current COA. The current SMM sends the IPM-Registration Request AVP that encapsulates the incoming IPM Registration-Request message for the previous SMM to authenticate before forwarding the data. The IPM-Context 25 Request-Type AVP informs the previous SMM what kind of action is requested. Additionally, AVPs, which are discussed further in section 4.5, optionally used in the AAA-Context-Request message are: IPM-Registration Request AVP; IPM-SMM-NAI AVP; Proxy-State AVP; Time AVP; 30 Nonce AVP; and Integrity-Check-Value AVP.

WO 01/19050 PCT/IBOO/01553 148 In events 4413, 4415, and 4419, the AAA-Context Response message is sent by previous SMM of the User to the current SMM in response to the AAA-Context-Request message. The AAA-Context-Response message is of the 5 format of DIAMETER. The previous SMM of the MN sends this message to current SMM, to response to the AAA-Context Request message. The successful message must have IPM Context-Data AVP in the message. Additionally, AVPs, which are discussed further in section 4.5, optionally 10 used in the AAA-Context-Request message are: IPM Context-Data AVP; Proxy-State AVP; Time AVP; Nonce AVP; *and Integrity-Check-Value AVP. In event 4414, the Service Response message is sent. See section 4.2.1 for details. 15 In event 4416, the Add Tunnel Entry message is sent. See section 4.2.1 for details. In event 4418, the Add Tunnel Entry Acknowledgement message is sent. See section 4.2.1 for details. In events 4420, 4422, and 4424, the AAA-Registration 20 Reply message is sent. See section 4.2.1 for details. In events 4426, the Registration Reply message is sent. See section 4.2.1 for details. In events 4427 and. 4428, the AAA-Binding-Update Request message is sent by the current SMM of the User to 25 the previous SMM to complete the hand-off of the User's session. The AAA-Binding-Update Request message is of the format of DIAMETER. The current SMM of the MN sends this message to the previous SMM, to complete the hand off of the User's session and clean up of the resources 30 that are allocated for the user. The message contains: a Command-Code of 341; Destination-NAI AVP; Host-Name WO 01/19050 PCT/IBOO/01553 149 AVP; User-Name AVP; IPM-Client-Address AVP; and IPM-Care of-Address AVP. Additionally, AVPs, which are discussed further in section 4.5, optionally used in the AAA Binding-Update Request message are: IPM-SMM-NAI AVP; 5 Proxy-State AVP; Time AVP; Nonce AVP; and Integrity Check-Value AVP. In events 4430 and 4432, the AAA-Binding-Update Response message is sent by the previous SMM of the User to the current SMM in response to the AAA-Binding-Update 10 Request message. The AAA-Binding-Update Response message is of the format of DIAMETER. The previous SMM of the MN sends this message to the current SMM, in response to the AAA-Binding-Update Request message. The successful message completes the hand-off of the MN from SMM to SMM. 15 The AAA-Binding-Update Response message contains: Command-Code of 342; Destination-NAI AVP; Host-Name AVP; User-Name AVP; and Result-Code AVP. Additionally, AVPs, which are discussed further in section 4.5, optionally used in the AAA-Binding-Update Request message are: 20 Proxy-State AVP; Time AVP; Nonce AVP; and Integrity Check-Value AVP. 4.2.11 IPM MN HANDOFFS LSF TO NSF (HOME ANI) FIGURE 45 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs LSF to 25 NSF, home ANI. In events 4502-4504, the Registration Request message is sent. See section 4.2.1 for details. In event 4506, the Service Request message is sent. See section 4.2.1 for details. 30 In event 4508, the Service Reply message is sent. See section 4.2.1 for details.

WO 01/19050 PCT/IB00/01553 150 In event 4510, the Delete Tunnel Entry message is sent. See section 4.2.6 for details. In event 4512, the Delete Tunnel Entry Acknowledgement message is sent. See section 4.2.6 for 5 details. In events 4514 and 4516, the Registration Reply message is sent. See section 4.2.1 for details. In events 4515, 4517, and 4518, the AAA-Registration Cancellation message is sent by the HMM to the SMM to 10 cancel the existing User's registration at the visiting system. The AAA-Registration Cancellation message is of the format of DIAMETER. The HMM sends the message to the SMM with at least the mandatory fields to cancel the registration of the user. The IPM-Registration 15 Cancellation-Reason AVP indicates the reason for the cancellation of the registration. The AAA-Registration Cancellation message contains: Command-Code of 337; Destination-NAI AVP; Host-Name AVP; User-Name AVP; and IPM-Registration-Cancellation-Reason AVP. Additionally, 20 AVPs, which are discussed further in section 4.5, optionally used in the- AAA-Binding-Update Request message are: IPM-Client-Address AVP; Proxy-State AVP; Time AVP; Nonce AVP; and Integrity-Check-Value AVP. In events 4520-24, the AAA-Registration Cancellation 25 Acknowledgement message is sent by the SMM to acknowledge the AAA-Registration Cancellation message. The AAA Registration Cancellation Acknowledgement message is of the format of DIAMETER. The SMM sends the message to the HMM with at least the mandatory fields. The Response-Code 30 AVP indicates the failure or success of the AAA Registration Cancellation message. The AAA-Registration WO 01/19050 PCT/IBOO/01553 151 Cancellation Acknowledgement message contains: Command Code of 338; Destination-NAI AVP; Host-Name AVP; User Name AVP; and Result-Code AVP. Additionally, AVPs, which are discussed further in section 4.5, optionally used in 5 the AAA-Binding-Update Request message are: Proxy-State AVP; Time AVP; Nonce AVP; and Integrity-Check-Value AVP. 4.2.12 IPM MN HANDOFFS NSF (HOME ANI) TO LSF FIGURE 46 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs NSF, 10 home ANI, to LSF. In events 4602-4604, the Registration Request message is sent. See section 4.2.1 for details. In events 4606-4610, the AAA-Registration Request message is sent. See section 4.2.1 for details. 15 In event 4612, the Service Request message is sent. See section 4.2.1 for details. In event 4614, the Service Reply message is sent. See section 4.2.1 for details. In event 4616, the Add Tunnel Entry message is sent. 20 See section 4.2.1 for details. In event 4618, the Add Tunnel Entry Acknowledgement message is sent. See section 4.2.1 for details. In events 4620-24, the AAA-Registration Reply message is sent. See section 4.2.1 for details. 25 In event 4626, the Add Tunnel Exit message is sent. See section 4.2.1 for details. In event 4628, the Add Tunnel Exit Acknowledgement message is sent. See section 4.2.1 for details. In events 4630-32, the Registration Reply message is 30 sent. See section 4.2.1 for details.

WO 01/19050 PCT/IBOO/01553 152 4.2.13 IPM MN HANDOFFS FROM LSF TO NSF (FOREIGN ANI) FIGURE 47 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from LSF to NSF, foreign ANI. 5 In events 4702-4704, the Registration Request message is sent. See section 4.2.1 for details. In event 4706, the Service Request message is sent. See section 4.2.1 for details. In event 4708, the Service Reply message is sent. 10 See section 4.2.1 for details. In event 4710, the Add Tunnel Exit message is sent. See section 4.2.1 for details. In event 4711, the Add Tunnel Entry message is sent. See section 4.2.1 for details. 15 In event 4712, the Add Tunnel Exit Acknowledgement message is sent. See section 4.2.1 for details. In events 4713, the Add Tunnel Entry Acknowledgement message is sent. See section 4.2.1 for details. In events 4714 and 4716, the Registration Reply 20 message is sent. See section 4.2.1 for details. In events 4715, 4717, and 4718, the AAA Registration Cancellation message is sent. See section 4.2.11 for details. In events 4720-24, the AAA Registration Cancellation 25 Acknowledgement message is sent. See section 4.2.11 for details. 4.2.14 IPM MN HANDOFFS FROM NSF (FOREIGN ANI) TO LSF FIGURE 48 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from 30 NSF, foreign ANI, to LSF.

WO 01/19050 PCT/IBOO/01553 153 In events 4802-4804, the Registration Request message is sent. See section 4.2.1 for details. In events 4806-4810, the AAA Registration Request message is sent. See section 4.2.1 for details. 5 In event 4812, the Service Request message is sent. See section 4.2.1 for details. In event 4814, the Service Reply message is sent. See section 4.2.1 for details. In event 4816, the Add Tunnel Entry message is sent. 10 See section 4.2.1 for details. In event 4817, the Delete Tunnel Exit message is sent. See section 4.2.6 for details. In event 4818, the Add Tunnel Entry Acknowledgement message is sent. See section 4.2.1 for details. 15 In event 4819, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.2.6 for details. In events 4820-24, the AAA Registration Reply message is sent. See section 4.2.1 for details. 20 In event 4826, the Add Tunnel Exit message is sent. See section 4.2.1 for details. In event 4828, the Add Tunnel Exit Acknowledgement message is sent. See section 4.2.1 for details. In events 4830-32, the Registration Reply message is 25 sent. See section 4.2.1 for details. 4.2.15 IPM MN HANDOFFS FROM FOREIGN ANI TO FOREIGN ANI IN THE SAME NSF FIGURE 49 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from 30 foreign ANI to foreign ANI in the same NSF.

WO 01/19050 PCT/IBOO/01553 154 In events 4902-4904, the Registration Request message is sent. See section 4.2.1 for details. In event 4906, the Add Tunnel Exit message is sent. See section 4.2.1 for details. 5 In event 4908, the Tunnel Forwarding message is sent. See section 4.2.1 for details. In event 4910, the Service Request message is sent. See section 4.2.1 for details. In event 4912, the Add Tunnel Exit Acknowledgement 10 message is sent. See section 4.2.1 for details. In event 4914, the Tunnel Forwarding Acknowledgement message is sent. See section 4.2.1 for details. In event 4916, the Service Reply message is sent. See section 4.2.1 for details. 15 In event 4918, the Add Tunnel Entry message is sent. See section 4.2.1 for details. In event 4920, the Add Tunnel Entry Acknowledgement message is sent. See section 4.2.1 for details. In events 4922 and 4926, the Registration Reply 20 message is sent. See section 4.2.1 for details. In event 4924, the Delete Tunnel Exit message is sent. See section 4.2.1 for details. In event 4928, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.2.1 for 25 details. 4.2.16 IPM MN HANDOFFS FROM HOME ANI TO FOREIGN ANI IN THE SAME NSF FIGURE 50 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from 30 foreign ANI to foreign ANI in the same NSF.

WO 01/19050 PCT/IBOO/01553 155 In events 5002-5004, the Registration Request message is sent. See section 4.2.1 for details. In event 5006, the Service Request message is sent. See section 4.2.1 for details. 5 In event 5008, the Service Reply message is sent. See section 4.2.1 for details. In event 5010, the Add Tunnel Entry message is sent. See section 4.2.1 for details. In event 5012, the Add Tunnel Exit message is sent. 10 See section 4.2.1 for details. In event 5014, the Add Tunnel Entry Acknowledgement message is sent. See section 4.2.1 for details. In event 5016, the Add Tunnel Exit Acknowledgement message is sent. See section 4.2.1 for details. 15 In events 5018-5020, the Registration Reply message is sent. See section 4.2.1 for details. 4.2.17 IPM MN HANDOFFS FROM FOREIGN ANI TO HOME ANI IN THE SAME NSF 20 FIGURE 51 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from foreign ANI to home ANI in the same NSF. In events 5102-5104, the Registration Request message is sent. See section 4.2.1 for details. 25 In event 5106, the Service Request message is sent. See section 4.2.1 for details. In event 5108, the Service Reply message is sent. See section 4.2.1 for details. In event 5110, the Delete Tunnel Entry message is 30 sent. See section 4.2.6 for details.

WO 01/19050 PCT/IBOO/01553 156 In event 5112, the Delete Tunnel Exit .message is sent. See section 4.2.6 for details. In event 5114, the Delete Tunnel Entry Acknowledgement message is sent. See section 4.2.6 for 5 details. In event 5116, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.2.6 for details. In events 5118-20, the Registration Reply message is 10 sent. See section 4.2.1 for details. 4.3 INTERWORKING MESSAGE FLOW IPM-MIP 4.3.1 IPM MN REGISTERS FROM MIP FA FIGURE 52 is a message flow event sequence diagram showing the flow of messages for IPM MN registers from 15 MIP FA. Agent Discovery, events 5202-5204, is the method by which a Mobile Node (MN) determines whether it is currently connected to its home network or to a foreign network, and by which a MN can detect when it has moved 20 from one network to another. Home agents and foreign agents may advertise their availability on each link for which they provide service. A newly arrived MN can send a solicitation on the link to learn if any prospective agents are present. The Agent Discovery Process is 25 primarily handled through Agent Solicitation and Agent Advertisement. In event 5202, the Agent Solicitation is the broadcast/multicast message sent by the IPM MN to detect a Service Provider in the event that the IPM MN has not 30 received an Advertising Agent message. The message exchanged between the IPM MN and the MIP FA contains: a WO 01/19050 PCT/IBOO/01553 157 Mobile IP address belonging to the interface from which this message is sent, or 0; the configured solicitation address as the destination address; a type of 10; a code of 0; and a checksum value. 5 In step 5204, the Agent Advertisement are messages sent periodically, either as a broadcast or multicast for the visiting IPM MN to recognize the availability of service and to keep track of their point of attachment. The message exchanged between the MIP FA and the IPM MN 10 contains: an IP address belonging to the interface from which this message is sent; the configured Advertisement Address or the IP address of a neighboring host as a destination address; a type of 9; a code of 0; a checksum value; the number of router addresses advertised in this 15 message; the number of 32-bit words of information per each router address (2, in the version of the protocol described here) ; the maximum number of seconds that the router addresses may be considered valid; the sending router's IP address(es) on the interface from which this 20 message is sent; and the preferability of each router address [i] as a default router address, relative to other router addresses on the same subnet. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in 25 the Agent Advertisement message: Mobility Agent Advertisement Extension; Prefix-Lengths Extension (Optional); and One-Byte Padding Extension (Optional). In events 5206-5208, Registration Request message is sent by the IPM MN to the HMM to register for the 30 service. The Registration process also includes the WO 01/19050 PCT/IBOO/01553 158 authenticating and authorizing of the IPM MN to have access to the visited network or FA. The purpose of registration is for the IPM MN to inform the HMM of the NSF (Network Serving Function) of 5 its current location to which data packets can be forwarded to the IPM MN. The Registration process also includes the authenticating and authorizing of the MIP MN to have access to the visited network or LSF (Local Serving Function). 10 The message exchanged between the IPM MN and the HMM contains: an IP address of the MN; the COA within the ANI component as the destination address; a type of 0; the flags as filed with RFC2002; the lifetime requested by MN from the HMM or Home; the IP address of the MN; the 15 Home Agent's address of the MN; the Care-of-Address of the MN; and the identification, to provide replay protection. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in 20 the Registration Request message: Mobile-Home Authentication Extension; Mobile-Foreign Authentication Extension (Optional); and Foreign-Home Authentication Extension (Optional). In event 5210, the Service Request message is sent 25 from the HMM to the ISC (IPM Security Center) to authenticate a user or message, generate, renew, or delete session secret keys. It also can be sent from the PPS Manager to the ISC to generate or construct the IPMC. The message exchanged between the HMM and the ISC 30 contains: a type of USERSERVICEREQUESTMSG; a sub type of 0; a length of the message payload including all WO 01/19050 PCT/IBOO/01553 159 the extensions; an identification number used for matching User Service Request messages with User Service Reply messages, and for protecting against replay attacks of User Service Request messages; and a User NAI. 5 Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Service Request message: User Authentication Information Extension; Control Message Authentication Extension; Session Key Allocation Extension 0..N; 10 Session Key Lifetime Renewal Extension 0. .N; and Session Key Delete Extension 0..N. In event 5212, the Service Reply message is sent from the ISC (IPM Security Center) to the HMM in response to a Service Request message. The message exchanged 15 between the ISC and the HMM contains: a type of USERSERVICEREPLYMSG; a sub-type of 0; the length of the message payload including all the extensions; a code; an identification number used for matching User Service Request messages with User Service Reply messages, and 20 for protecting against replay attacks of User Service Request messages; and a User NAI. The value of the code is defined as the following hexadecimal value: 00000001 User Authenticated successfully. 00000002 All required keys have been allocated. 25 00000003 Some keys have been allocated. 00000004 User Authentication failed. 00000005 Key Lifetime Renewal is completely honoured. 00000006 Key Lifetime Renewal is partially 30 honoured. 00000007 User Account is created successfully.

WO 01/19050 PCT/IB00/01553 160 00000008 User is deleted successfully. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Service Reply message: Control Message 5 Authentication Extension; Session Key Allocation Extension 0..N; Session Key Lifetime Renewal Extension 0..N; and Session Key Delete Extension 0..N. In event 5214, the Add Tunnel Entry message is sent by the HMM to instruct the ITS to set up a tunnel entry 10 point. The message exchanged between the HMM and the ITS contains: a code of 1; the length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique 15 at any given time. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Add Tunnel Entry message: Host NAI Extension; Flag Extension; Lifetime Extension; Mobile Node IP Address 20 Extension; User NAI Extension (Optional); and Tunnel Entry IP Address Extension. In event 5216, the Add Tunnel Entry Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Entry message. The message exchanged between the ITS and 25 the HMM contains: a code of 2; a length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. 30 Additionally, the following extensions, which are explained in further detail in section 4.4, are used in WO 01/19050 PCT/IBOO/01553 161 the Add Tunnel Entry Acknowledgement message: Host NAI Extension; Result Code Extension; Mobile Node IP Address Extension (Optional); and User NAI Extension (Optional). In events 5218-22, the Registration Reply message is 5 sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. The message exchanged between the HMM and the IPM MN contains: a type of 3; the MIP Response codes; the Home lifetime for the registration; theIP address of the MN; the Home 10 Agent's address of the MN; and the identification, to provide replay protection. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Registration Reply message: Mobile-Home 15 Authentication Extension; Foreign-Home Authentication Extension (Optional); and Mobile-Foreign Authentication Extension (Optional). 4.3.2 IPM MN RE-REGISTERS FROM MIP FA FIGURE 53 is a message flow event sequence diagram 20 showing the flow of messages for IPM MN re-registers from MIP FA. In events 5302-5304, the Registration Request message is sent. See section 4.3.1 for details. In event 5306, the Service Request message is sent. 25 See section 4.3.1 for details. In event 5308, the Service Reply message is sent. See section 4.3.1 for details. In events 5310-14, the Registration Reply message is sent. See section 4.3.1 for details. 30 WO 01/19050 PCT/IBOO/01553 162 4.3.3 IPM MN DE-REGISTERS FROM MIP FA FIGURE 54 is a message flow event sequence diagram showing the flow of messages for IPM MN de-registers from MIP FA. 5 In events 5402-5404, the Registration Request message is sent. See section 4.3.1 for details. In event 5406, the Service Request message is sent. See section 4.3.1 for details. In event 5408, the Service Reply message is sent. 10 See section 4.3.1 for details. In event 5410, the Delete Tunnel Entry message is sent by the HMM to instruct the ITS to delete a tunnel entry point. The message exchanged between the HMM and the ITS contains: a code of 7; the length of the message 15 including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. Additionally, the following extensions, which are 20 explained in further detail in section 4.4, are used in the Delete Tunnel Entry message: Host NAI Extension; Mobile Node IP Address Extension; and User NAI Extension (Optional). In event 5412, the Delete Tunnel Entry 25 Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Entry message. The identification field should be used for matching with the Delete Tunnel Entry message. The message exchanged between the ITS and the HMM contains: a code of 8; the length of the message 30 including the header fields; and an identification used in matching requests and acknowledgements. The sender WO 01/19050 PCT/IBOO/01553 163 must ensure the identifier in a message is locally unique at any given time. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in 5 the Delete Tunnel Entry Acknowledgement message: Host NAI Extension; Result Code Extension; Mobile Node IP Address Extension (Optional); and User NAI Extension (Optional). In events 5414-18, the Registration Reply message is 10 sent. See section 4.3.1 for details. 4.3.4 IPM MN HANDOFFS FROM IPM ANI TO FA (NO SMOOTH HANDOFF) FIGURE 55 is a message flow event sequence diagram showing the flow of messages for IPM MN de-registers from 15 MIP FA. In events 5502-5504, the Registration Request message is sent. See section 4.3.1 for details. In event.5506, the Service Request message is sent. See section 4.3.1 for details. 20 In event 5508, the Service Reply message is sent. See section 4.3.1 for details. In event 5510, the Add Tunnel Entry message is sent. See section 4.3.1 for details. In event 5512, the Add Tunnel Entry Acknowledgement 25 message is sent. See section 4.3.1 for details. In events 5514 and 5418, the Registration Reply message is sent. See section 4.3.1 for details. In events 5516, 5520, and. 5522, the AAA-Registration Cancellation message is sent by the HMM to the SMM to 30 cancel the existing User's registration at the visiting system.

WO 01/19050 PCT/IBOO/01553 164 The AAA-Registration Cancellation message is of the format of DIAMETER. The HMM sends the message to the SMM with at least the mandatory fields to cancel the registration of the user. The IPM-Registration 5 Cancellation-Reason AVP indicates the reason for the cancellation of the registration. The AAA-Registration Cancellation message contains: Command-Code AVP of 337, Destination-NAI AVP; Host-Name AVP; User-Name AVP; and IPM-Registration-Cancellation-Reason AVP. 10 Additionally, the AAA-Registration Cancellation message can optionally use the following AVPs, which are discussed in further detail in section 4.5: IPM-Client Address AVP; Proxy-State AVP; Time AVP; Nonce AVP; and Integrity-Check-Value AVP. 15 In event 5524, the Delete Tunnel Exit message is sent by the SMM to instruct the ITS to delete a tunnel exit point. The message exchanged between the SMM and the ITS contains: a code of 9; the length of the message including the header fields; and an identification used 20 in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in 25 the Delete Tunnel Exit message: Host NAI Extension; Mobile Node IP Address Extension (Optional); and Tunnel Exit IP Address Extension. In event 5526, the Delete Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge 30 the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit WO 01/19050 PCT/IBOO/01553 165 message. The message exchanged between the ITS and the SMM contains: a code of 10; the length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender 5 must ensure the identifier in a message is locally unique at any given time. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Delete Tunnel Exit message: Host NAI Extension; 10 Result Code Extension; Mobile Node IP Address Extension (Optional); and User NAI Extension (Optional). In events 5528-32, the AAA-Registration Cancellation Acknowledgement message is sent by the SMM to the HMM in response to the AAA-Registration Cancellation message. 15 The AAA-Registration Cancellation Acknowledgement message is of. the format of DIAMETER. The SMM sends the message to the HMM with at least the mandatory fields. The Response-Code AVP indicates the failure or success of the AAA-Registration Cancellation message. The message 20 exchanged between the SMM and the HMM contains: Command Code AVP of 338, Destination-NAI AVP; Host-Name AVP; User-Name AVP; and Result-Code AVP. Additionally, the AAA-Registration Cancellation Acknowledgement message can optionally use the following 25 AVPs, which are discussed in further detail in section 4.5: Proxy-State AVP; Time AVP; Nonce AVP; and Integrity-Check-Value AVP.

WO 01/19050 PCT/IBOO/01553 166 4.3.5 IPM MN HANDOFFS FROM IPM ANI TO FA (SMOOTH HANDOFF) FIGURE 56 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from IPM 5 ANI to FA, smooth handoff. In events 5602-5604, the Registration Request message is sent. See section 4.3.1 for details. In events 5606 and 5609, the Binding Update message is used for notification of a MN's current mobility 10 binding. It should be sent by the MN's home agent in response to a Binding Request message, a Binding Warning message, or the reception of a Binding Warning extension to a Registration Request message. It should also be sent by a MN, or by the foreign agent with which the MN is 15 registering, when notifying the MN's previous foreign agent that the MN has moved. The message exchanged between the MIP FA and the SMM contains: a type of 18; the 'A' (acknowledge) bit is set by the node sending the Binding Update message to request a Binding Acknowledge 20 message be returned; the 'I' (identification present) bit is set by the node sending the Binding Update message if the identification field is present in the message; if the 'M' (minimal encapsulation) bit is set, datagrams MAY be tunneled to the MN using the minimal encapsulation 25 protocol; if the 'G' (Generic Record Encapsulation, or GRE) bit is set, datagrams MAY be tunneled to the MN using GRE; the number of seconds remaining before the binding cache entry must be considered expired; the home address of the MN to which the Binding Update message 30 refers; the current care-of-address of the MN (when set equal to the home address of the MN, the Binding Update WO 01/19050 PCT/IBOO/01553 167 message instead indicates that no binding cache entry for the MN should be created, and any existing binding cache entry and visitor list entry, in the case of a MN's previous foreign agent for the MN should be deleted); and 5 an identification used to assist in matching requests with replies, and in protection against replay attacks. In event 5608, the Service Request message is sent. See section 4.3.1 for details. In event 5610, the Service Reply message is sent. 10 See section 4.3.1 for details. In event 5612, the Tunnel Forwarding message is sent by the SMM to instruct the ITS to set up a tunnel forwarding. The message exchanged between the SMM and the ITS contains: a code of 5; the length of the message 15 including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. Additionally, the following extensions, which are 20 explained in further detail in section 4.4, are used in the Tunnel Forwarding message: Host NAI Extension; Mobile Node IP Address Extension; User NAI Extension (Optional); Lifetime Extension; and Tunnel Exit IP Address Extension. 25 In event 5614, the Add Tunnel Entry message is sent. See section 4.3.1 for details. In event 5616, the Tunnel Forwarding Acknowledgement message is sent by the ITS to acknowledge the Tunnel Forwarding message. The identification field should be 30 used for matching with the Tunnel Forwarding message. The message exchanged between the ITS and the SMM WO 01/19050 PCT/IBOO/01553 168 contains: a code of 6; the length of the message including the header fields; and an identification used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique 5 at any given time. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Tunnel Forwarding Acknowledgement message: Host NAI Extension; Mobile Node IP Address Extension; User NAI 10 Extension (Optional); and Result Code Extension. In event 5618, the Add Tunnel Entry Acknowledgement message is sent. See section 4.3.1 for details. In events 5620,5626, and 5632, the Binding Acknowledge message is used to acknowledge receipt of a 15 Binding Update message. It SHOULD be sent by a node receiving a Binding Update message if the acknowledge (A) bit is set in the Binding Update message. The message exchanged between the SMM and the MN contains: a type of 19; the status (if the Status is nonzero, this 20 acknowledgement is negative); a Mobile Node Home Address copied from the Binding Update message being acknowledged; and an identification. In events 5622 and 5628, the Registration Reply message is sent. See section 4.3.1 for details. 25 In events 5624, 5630, and 5634, the AAA-Registration Cancellation message is sent. See section 4.3.1 for details. In event 5636, the Delete Tunnel Exit message is sent. See section 4.3.1 for details.

WO 01/19050 PCT/IBOO/01553 169 In event 5638, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.3.1 for details. In events 5640-44, the AA-Registration Cancellation 5 Acknowledgement message is sent. See section 4.3.1 for details. 4.3.6 IPM MN HANDOFFS FROM FA TO IPM ANI (NO SMOOTH HANDOFF) FIGURE 57 is a message flow event sequence diagram 10 showing the flow of messages for IPM MN handoffs from FA to IPM ANI, no smooth handoff. In events 5702-5704, the Registration Request message is sent. See section 4.3.1 for details. In events 5706-10, the AAA-Registration-Request 15 message is used to carry out various kinds of registrations; these registrations are encapsulated in the IPM-Registration-Type AVP. This message is used by SMM to authenticate and authorize the user. The AAA Registration-Request message is of the format of 20 DIAMETER. The SMM sends the message to HMM with at least these mandatory fields. The IPM-Registration-Request AVP is the AVP which carries the message received from the MN, which is encapsulated in the AVP format for the Home domain to authenticate the user. The HMM processes this 25 message based on the Registration-Type AVP, which carries the type of registration requested. The message exchanged between the SMM and the HMM contains: Command-Code AVP of 335; User-Name AVP; Host-Name AVP; IPM-Registration-Type AVP; IPM-Registration-Request AVP; 30 IPM-Care-of-Address AVP; and IPM-Routing-Area-NAI AVP.

WO 01/19050 PCT/IB00/01553 170 Additionally, the AAA-Registration Cancellation Acknowledgement message can optionally use the following AVPs, which are discussed in further detail in section 4.5: Destination-NAI AVP; IPM-Client-Address AVP; Home 5 Agent-Address AVP; IPM-SMM-NAI AVP; IPM-Terminal-Type AVP; IPM-Profile-Type AVP; Proxy-State AVP; Timestamp AVP; Nonce AVP; and Integrity-Check-Value AVP. In event 5712, the Service Request message is sent. See section 4.3.1 for details. 10 In event 5714, the Service Reply message is sent. See section 4.3.1 for details. In event 5716, the Add Tunnel Entry message is sent. See section 4.3.1 for details. In event 5718, the Add Tunnel Entry Acknowledgement 15 message is sent. See section 4.3.1 for details. In events 5720-24, the AAA Registration Reply message is sent by the HMM to the SMM to indicate the result of the AAA-Registration Request message. The AAA-Registration Reply message is of the format 20 of DIAMETER. The HMM sends a message to the SMM with at least the mandatory fields in response to AAA Registration Request message. The IPM-Registration Response Code AVP indicates the success or failure of the request. The IPM Registration Reply message AVP contains 25 the reply message built by HMM with authentication. The SMM has to use this AVP to send a reply to ANI/MN. The message exchanged between the HMM and the SMM contains: Command-Code AVP of 336; Destination-NAI AVP; Host-Name AVP; User-Name AVP; IPM-Registration-Response-Code AVP; 30 IPM-Client-Address AVP; and IPM-Registration-Reply AVP.

WO 01/19050 PCT/IBOO/01553 171 Additionally, the Registration Reply message can optionally use the following AVPs, which are discussed in further detail in section 4.5: IPM-Profile AVP; IPM-SMM MN-Key AVP; IPM-HMM-NAI AVP; Proxy-State AVP; Time AVP; 5 Nonce AVP; and Integrity-Check-Value AVP. In events 5726 and 5732, the Registration Reply message is sent. See section 4.3.1 for details. In event 5728, the Add Tunnel Exit message is sent by the SMM to instruct the ITS to set up a tunnel exit 10 point. The message exchanged between the SMM and the ITS contains: a code of 3, the length of the message including the header fields; and an indication used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at 15 any given time. Additionally, the following extensions, which are explained in further detail in section 4.4, are used in the Add Tunnel Exit message: Host NAI Extension; Lifetime Extension; Mobile Node IP Address Extension; 20 User NAI Extension (Optional); and Tunnel Exit IP Address Extension. In event 5730, the Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Exit message. The message exchanged between the ITS and 25 the SMM contains: a code of 4; the length of the message including the header fields; and an indication used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. 30 Additionally, the following extensions, which are explained in further detail in section 4.4, are used in WO 01/19050 PCT/IBOO/01553 172 the Add Tunnel Exit Acknowledgement message: Host NAI Extension; Result Code Extension; Mobile Node IP Address Extension (Optional); User NAI Extension (Optional); and Tunnel Forwarding IP Address Extension. 5 4.3.7 IPM MN HANDOFFS FROM FA TO IPM ANI (SMOOTH HANDOFF) FIGURE 58 is a message flow event sequence diagram showing the flow of messages for IPM MN handoffs from FA to IPM ANI, smooth handoff. 10 In events 5802-5804, the Registration Request message is sent. See section 4.3.1 for details. In events 5806, 5812, and 5818, the AAA-Registration Request message is sent. See section 4.3.6 for details. In events 5808 and 5814, the Binding Update message 15 is used for notification of a MN's current mobility binding. It should be sent by the MN's home agent in response to a Binding Request message, a Binding Warning message, or the reception of a Binding Warning extension to a Registration Request message. It should also be sent 20 by a MN, or by the foreign agent with which the MN is registering, when notifying the MN's previous foreign agent that the MN has moved See section 4.3.5 for details. In event 5810, the Add Tunnel Exit message is sent. 25 See section 4.3.6 for details. In event 5816, the Add Tunnel Exit Acknowledgement message is sent. See section 4.3.6 for details. In event 5820, the Service Request message is sent. See section 4.3.1 for details. 30 In event 5822, the Binding Acknowledge message is sent. See section 4.3.5 for details.

WO 01/19050 PCT/IBOO/01553 173 In event 5824, the Service Reply message is sent. See section 4.3.1 for details. In event 5828, the Add Tunnel Entry message is sent. See section 4.3.1 for details. 5 In event 5830, the Add Tunnel Entry Acknowledgement message is sent. See section 4.3.1 for details. In events 5832-36, the AAA-Registration Reply message is sent. See section 4.3.6 for details. In events 5838-40, the Registration Reply message is 10 sent. See section 4.3.1 for details. 4.3.8 MIP MN REGISTERS FROM IPM LSF FIGURE 59 is a message flow event sequence diagram showing the flow of messages for MIP MN registers from IPM LSF. 15 In event 5902, the Agent Solicitation message is sent. See section 4.3.1 for details. In event 5904, the Agent Advertisement message is sent. See section 4.3.1 for details. In events 5906-10, the Registration Request message 20 is sent. See section 4.3.1 for details. In events 5912 and 5918-20, the Registration Reply message is sent. See section 4.3.1 for details. In event 5914, the Add Tunnel Exit message is sent. See section 4.3.6 for details. 25 In events 5916, the Add Tunnel Exit Acknowledgement message is sent. See section 4.3.6 for details. 4.3.9 MIP MN RE-REGISTERS FROM IPM LSF FIGURE 60 is a message flow event sequence diagram showing the flow of messages for MIP MN re-registers from 30 IPM LSF.

WO 01/19050 PCT/IBOO/01553 174 In event 6002, the Agent Solicitation message is sent. See section 4.3.1 for details. In event 6004, the Agent Advertisement message is sent. See section 4.3.1 for details. 5 In events 6006-10, the Registration Request message is sent. See section 4.3.1 for details. In events6012-16, the Registration Reply message is sent. See section 4.3.1 for details. 10 4.3.10 MIP MN HANDOFFS FROM IPM ANI TO FA (NO SMOOTH HANDOFF) FIGURE 61 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from IPM ANI to FA, no smooth handoff. 15 In events 6102-6104, the Registration Request message is sent. See section 4.3.1 for details. In events 6106-6108, the Registration Reply message is sent. See section 4.3.1 for details. In event 6110, the Delete Tunnel Exit message is 20 sent. See section 4.3.4 for details. In event 6112, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.3.4 for details. 4.3.11 MIP MN HANDOFFS FROM IPM ANI TO FA (SMOOTH 25 HANDOFF) FIGURE 62 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from IPM ANI to FA, smooth handoff. In events 6202-6204, the Registration Request 30 message is sent. See section 4.3.1 for details.

WO 01/19050 PCT/IBOO/01553 175 In event 6206, the Binding Update message is sent. See section 4.3.5 for details. In events 6208 and 6212, the Registration Reply message is sent. See section 4.3.1 for details. 5 In event 6214, the Tunnel Forwarding message is sent. See section 4.3.5 for details. In event 6216, the Tunnel Forwarding Acknowledgement message is sent. See section 4.3.5 for details. In events 6218-22, the Binding Acknowledge message 10 is sent. See section 4.3.5 for details. In event 6224, the Delete Tunnel Exit message is sent. See section 4.3.4 for details. In event 6226, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.3.4 for 15 details. 4.3.12 MIP MN HANDOFFS FROM FA TO IPM ANI (NO SMOOTH HANDOFF) FIGURE 63 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from IPM 20 ANI to FA, no smooth handoff. In events 6302-6306, the Registration Request message is sent. See section 4.3.1 for details. In events 6308 and 6314-16, the Registration Reply message is sent. See section 4.3.1 for details. 25 In event 6310, the Add Tunnel Exit message is sent. See section 4.3.6 for details. In event 6312, the Add Tunnel Exit Acknowledgement message is sent. See section 4.3.6 for details.

WO 01/19050 PCT/IBOO/01553 176 4.3.13 MIP MN HANDOFFS FROM FA TO IPM ANI (SMOOTH HANDOFF) FIGURE 64 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from IPM 5 ANI to FA, no smooth handoff. In events 6402-6406, the Registration Request message is sent. See section 4.3.1 for details. In events 6408 and 6414, the Binding Update message is sent. See section 4.3.5 for details. 10 In event 6410, the Add Tunnel Exit message is sent. See section 4.3.6 for details. In events 6412, 6418, and 6422, the Registration Reply message is sent. See section 4.3.1 for details. In event 6416, the Add Tunnel Exit Acknowledgement 15 message is sent. See section 4.3.6 for details. In events 6420 and 6424, the Binding Acknowledge message is sent. See section 4.3.5 for details. 4.3.14 MIP MN HANDOFFS FROM NSF TO FA (NO SMOOTH HANDOFF) 20 FIGURE 65 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from NSF to FA, no smooth handoff. In events 6502-6504, the Registration Request message is sent. See section 4.3.1 for details. 25 In events 6506-6508, the Registration Reply message is sent. See section 4.3.1 for details. In event 6510, the Delete Tunnel Exit message is sent. See section 4.3.4 for details. In event 6512, the Delete Tunnel Exit 30 Acknowledgement message is sent. See section 4.3.4 for details.

WO 01/19050 PCT/IBOO/01553 177 4.3.15 MIP MN HANDOFFS FROM NSF TO FA (SMOOTH HANDOFF) FIGURE 66 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from NSF 5 to FA, smooth handoff. In events 6602-6604, the Registration Request message is sent. See section 4.3.1 for details. In events 6606 and 6610, the Binding Update message is sent. See section 4.3.5 for details. 10 In events 6608 and 6612, the Registration Reply message is sent. See section 4.3.1 for details. In event 6614, the Tunnel Forwarding message is sent. See section 4.3.5 for details. In event 6616, the Tunnel Forwarding Acknowledgement 15 message is sent. See section 4.3.5 for details. In events 6618-6622, the Binding Acknowledge message is sent. See section 4.3.5 for details. In event 6624, the Delete Tunnel Exit message is sent. See section 4.3.4 for details. 20 In event 6626, the Delete Tunnel Exit Acknowledgement message is sent. See section 4.3.1 for details. 4.3.16 MIP MN HANDOFFS FROM FA TO NSF (NO SMOOTH 25 HANDOFF) FIGURE 67 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from FA to NSF, no smooth handoff. In events 6702-6706, the Registration Request 30 message is sent. See section 4.3.1 for details. In events 6708 and 6714-16, the Registration Reply message is sent. See section 4.3.1 for details.

WO 01/19050 PCT/IBOO/01553 178 In event 6710, the Add Tunnel Exit message is sent. See section 4.3.6 for details. In event 6712, the Add Tunnel Exit Acknowledgement message is sent. See section 4.3.6 for details. 5 4.3.17 MIP MN HANDOFFS FROM FA TO NSF (SMOOTH HANDOFF) FIGURE 68 is a message flow event sequence diagram showing the flow of messages for MIP MN handoffs from FA to NSF, smooth handoff. 10 In events 6802-6806, the Registration Request message is sent. See section 4.3.1 for details. In events 6808, the Binding Update message is sent. See section 4.3.5 for details. In events 6810 and 6820, the Registration Reply 15 message is sent. See section 4.3.1 for details. In events 6812 and 6816, the Binding Acknowledge message is sent. See section 4.3.5 for details. In event 6814, the Add Tunnel Exit message is sent. See section 4.3.6 for details. 20 In event 6818, the Add Tunnel Exit Acknowledgement message is sent. See section 4.3.6 for details. 4.4 EXTENSIONS 25 4.4.1 AGENT DISCOVERY EXTENSIONS 4.4.1.1ANI-NAI EXTENSION The ANI-NAI Extension is used to carry the ANI information, such as ANI's NAI (Network Access 30 Identifier). This extension contains: a type of IPM VENDOR-SPECIFIC-EXTENSION or 255; a length field; a sub type of 0; and the NAI string of the ANI.

WO 01/19050 PCT/IBOO/01553 179 4.4.1.2 MOBILITY AGENT ADVERTISEMENT EXTENSION The Mobility Agent Advertisement Extension is added to the ICMP Router Advertisement message to indicate to 5 MNs that this is an Agent Advertisement message (not an Router Advertisement message) with the specified Care-of Addresses. This extension contains: a type of 16; a length of the message including the Care-of-Addresses; the count of Agent Advertisement messages sent since the 10 agent was initialized; the longest lifetime (measured in seconds) that this agent is willing to accept in any Registration Request message; advertised foreign agent Care-of-Addres(es) provided by this foreign agent; and indicator bits for Registration Required, Busy, Home 15 Agent, Foreign Agent, Minimal Encapsulation, GRE Encapsulation, and Van Jackson header compression. An Agent Advertisement message MUST include at least one Care-of Address if the Foreign Agent bit is set. The length field in the extension determines the number of 20 Care-of-Address(es) present. 4.4.1.3 ONE-BYTE PADDING EXTENSION Some IP protocol implementations insist upon padding ICMP messages to an even number of bytes. If the ICMP length of an Agent Advertisement message is odd, this 25 extension may be included in order to make the ICMP length even. This extension is not intended to be a general purpose extension to be included in order to word or long align the various fields of the Agent Advertisement message. An Agent Advertisement message 30 should not include more than one One-byte Padding WO 01/19050 PCT/IB00/01553 180 Extension, and if present, this extension should be the last extension in the Agent Advertisement message. Note that unlike other extensions used in Mobile IP, the One-byte Padding Extension is encoded as a single 5 byte, with no "Length" or "Data" field present, with a value of zero. 4.4.1.4 PREFIX-LENGTHS EXTENSION The Prefix-Lengths Extension MAY follow the Mobility Agent Advertisement Extension. It is used to indicate the 10 number of bits of network prefix that applies to each Router Address listed in the ICMP Router Advertisement portion of the Agent Advertisement message. Note that the prefix lengths given do not apply to care-of address(es) listed in the Mobility Agent Advertisement Extension. 15 This extension contains: a type of 19; the value (possibly zero) of the NUM Addrs field in the ICMP Router Advertisement portion of the Agent Advertisement message; and the number of leading bits that define the network number of the corresponding Router Address listed in the 20 ICMP Router Advertisement portion of the message. The prefix length for each Router Address is encoded as a separate byte, in the order that the Router Addresses are listed in the ICMP Router Advertisement portion of the message. 25 4.4.2 ITS CONTROL EXTENSIONS All of the extensions for ITS Messages contain a code, an extension length, and data fields.: 4.4.2.1 AUTHENTICATION EXTENSION 30 The Authentication Extension is used by the ITS to authenticate the requesting message before performing the WO 01/19050 PCT/IBOO/01553 181 requested action. The code value is 10 and the extension length and data fields are user dependent. 4.4.2.2 FLAG EXTENSION The Flag Extension is used only if the message type 5 is Add Tunnel Entry. If this Extension is missing, the application should assume that all flags are zero. The code value is 3, the extension length is 6 bytes, and the data field is a 16-bit value with the lower byte contains the flags as defined in RFC 2002 for Registration Request 10 message. 4.4.2.3 HOST NAI EXTENSION The Host NAI Extension is used to let the IPM Tunnel Service (ITS) server know which node a request message comes from. The ITS can maintain the request information 15 per each requesting node so that it can clean up resources for that requesting node when necessary. (Ex. Requesting node is down abnormally). The code value is 1, the extension length is variable, and the data field contains a Host NAI string. 20 4.4.2.4 LIFETIME EXTENSION The Lifetime Extension is required for Add Tunnel Entry, Add Tunnel Exit, and Tunnel Forwarding. It is required for ITS to implement the session timeout. The code value is 4, the extension length is 8 bytes and the 25 data field is a 32-bit value. 4.4.2.5MOBILE NODE IP ADDRESS EXTENSION The Mobile Node IP Address Extension is required for all messages except Delete all... messages. The code value is 5, the extension length is 8 bytes for Ipv4 and 20 30 bytes for Ipv6, and the data field contains the IP address of the MN.

WO 01/19050 PCT/IBOO/01553 182 4.4.2.6 RESULT CODE EXTENSION The Result Code Extension is required for all acknowledgement messages. The code value is 9, the extension length is 6 bytes, and the data field contains 5 the result code of the previous request message. 4.4.2.7 TUNNEL ENTRY IP ADDRESS EXTENSION The Tunnel Entry IP Address Extension is required only for Add Tunnel Entry and Delete Tunnel Entry. The code value is 6, the extension length is 8 bytes for Ipv4 10 and 20 bytes for Ipv6, and the data field contains the IP address of the Tunnel Entry IP Address. 4.4.2.8 TUNNEL EXIT IP ADDRESS EXTENSION The Tunnel Exit IP Address Extension is required only for Add Tunnel Exit, Tunnel Forwarding, and Delete 15 Tunnel Exit. The code value is 7, the extension length is 8 bytes for Ipv4 and 20 bytes for Ipv6, and the data field contains the IP address of the Tunnel Exit' IP Address. 4.4.2.9 TUNNEL FORWARDING IP ADDRESS EXTENSION 20 The Tunnel Forwarding IP Address Extension is only required for Tunnel Forwarding. The code value is 8, the extension length is 8 bytes for Ipv4 and 20 bytes for Ipv6, and the data field contains Contains the IP address of the Tunnel Forwarding IP Address. 25 4.4.2.10 USER-NAI EXTENSION The User-NAI Extension contains the User NAI string. The code value is 2, the extension length is variable, and the data field contains the User-NAI string.

WO 01/19050 PCT/IBOO/01553 183 4.4.3 IPM REGISTRATION EXTENSIONS 4.4.3.lANI-HMM AUTHENTICATION EXTENSION The ANI-HMM Authentication Extension is used in the Registration messages to carry the Authentication 5 Extension between ANI and HMM. This extension contains: a type of IPMVENDORSPECIFICEXTENSION (255); the length of the extension; a sub-type of 6; and the authenticator calculated over the entire message up to the extension header. 10 4.4.3.2 ANI-SMM AUTHENTICATION EXTENSION The ANI-SMM Authentication Extension is used in the Registration essages to carry the Authentication Extension between ANI and SMM. This extension contains: a type of IPM-VENDOR-SPECIFIC-EXTENSION (255); the length 15 of the extension; a sub-type of 5; and the authenticator calculated over the entire message up to the extension header. 4.4.3.3 L2-ADDRESS EXTENSION The L2-Address Extension is used in the Registration 20 Request message to carry the MN's L2 Address. This extension contains: a type of IPM-VENDOR-SPECIFIC EXTENSION (255); the length of the address plus the header; a sub-type of 9; the Address-Type of the MN; and the layer 2 address of the MN. The Address-Type may be 25 802.3 Address, 802.11 Address, IMSI, or MIN 4.4.3.4 LOCAL REGISTRATION LIFETIME EXTENSION The Local Registration Lifetime Extension is used to carry the lifetime of local registration. This extension contains: a type of IMPVENDORSPECIFICEXTENSION (255); 30 a length of 6 bytes; a sub-type of 10; and the lifetime allowed by SMM for local re-registration in seconds.

WO 01/19050 PCT/IBOO/01553 184 4.4.3.5 MN-HOME AUTHENTICATION EXTENSION The MN-Home Authentication Extension is used in the Registration messages to carry the Authentication Extension between the MN and Home. This extension 5 contains: a type. of IPM-VENDOR-SPECIFIC-EXTENSION (255); the length of the authenticator plus the header; a sub type of 3; and the authenticator calculated over the entire message up to the extension header. 4.4.3.6 MN-SMM AUTHENTICATION EXTENSION 10 The MN-SMM Authentication Extension is used in the Registration message to carry the Authentication Extension between MN and SMM. This extension contains: a type of IPM-VENDOR-SPECIFIC-EXTENSION (255); a length of Authenticator plus the header; a sub-type of 4; and 15 the authenticator calculated over the entire message up to the extension header. 4.4.3.7 FOREIGN-HOME AUTHENTICATION EXTENSION The Foreign-Home Authentication Extension MAY be included in Registration Requests and Reply messages in 20 cases in which a mobility security association exists between the foreign agent and the home agent. This extension contains: a type of 34; a length of authenticator plus the header; the Security Parameter Index; and a variable length Authenticator. 25 4.4.3.8 MOBILE-FOREIGN AUTHENTICATION EXTENSION The Mobile-Foreign Authentication Extension MAY be included in Registration Requests and Reply message in cases in which a mobility security association exists between the mobile node and the foreign agent. This 30 extension contains: a type of 33; a length of the WO 01/19050 PCT/IBOO/01553 185 Authenticator plus the header; the Security Parameter Index; and a variable length Authenticator. 4.4.3.9 MOBILE-HOME AUTHENTICATION EXTENSION 5 Exactly one Mobile-Home Authentication Extension MUST be present in all Registration Requests and Registration Reply messages, and is intended to eliminate problems, which can result from the uncontrolled propagation of remote redirects in the Internet. The 10 location of the extension marks the end of the authenticated data. This extension contains: a type of 32; a length of the Authenticator plus the header; the Security Parameter Index; and a variable length Authenticator. 15 4.4.3.10 PREVIOUS-SMM-NAI EXTENSION The Previous-SMM-NAI Extension is used in the Registration Request message to carry the previous SMM's NAI. This extension is not applicable with Registration 20 type of "Initial Registration". This extension contains: a type of IPM-VENDOR-SPECIFIC-EXTENSION (255); the length of the SMM-NAI string plus the header; a sub-type of 8; and the NAI string of the SMM. .4.4.3.11 4REGISTRATION-TYPE EXTENSION 25 The Registration-Type Extension is used in the Registration Request message to indicate what type of registration is requested. This extension contains: a type of IPM-VENDOR-SPECIFIC-EXTENSION (255); a length of 6 bytes; a sub-type of 2; and the Registration type. The 30 Registration types include, among others, Initial Registration (0), De-Registration (1), System-Change (2), WO 01/19050 PCT/IBOO/01553 186 ANI-Change (3), Local Re-Registration (4), Re Registration (5), and Clean-up (6). 4.4.3.12 SMM KEY EXTENSION The SMM Key Extension is used to carry the shared 5 secret key that is to be used between the SMM and MN. This extension contains: a type of IMPVENDORSPECIFICEXTENSION (255); a length of the SMM Key plus the header; a sub-type of 7; and the SMM-Key, which is encrypted using the MN-Home shared secret key. 10 4.4.3.13 SMM-NAI EXTENSION The SMM-NAI Extension carries the SMM-NAI in the IPM messages. This extension contains: a type of IMPVENDORSPECIFICEXTENSION (255); the length of the SMM-NAI string plus the header; a sub-type of 0; and the 15 NAI string of the SMM. 4.4.3.14 USER-NAI EXTENSION The User-NAI Extension contains the User NAI string. This extension contains: a type of 131; the length of User-NAI; and the User-NAI string. 20 4.4.4 IPM SECURITY EXTENSIONS 4.4.4.1CONTROL MESSAGE AUTHENTICATION REQUEST EXTENSION This extension contains: a type of IPMEXT; a sub type of CNTLMSGAUTHEXT; the length of all the 25 attributes values; and the attribute values. If the Sub Type is: 0, then there is no Attribute; 1 then the Data Authentication Request Attribute applies; and 2 then the Data Authentication Reply Attribute applies. The attributes are explained in further detail in section 30 4.6.

WO 01/19050 PCT/IBOO/01553 187 4.4.4.2 CONTROL MESSAGE AUTHENTICATION REPLY EXTENSION This extension contains: a type of IPMEXT; a sub type of CNTRLMSGAUTHEXT; the length of all the attributes values; and the attribute values. If the Sub 5 Type is: 0 then there is no Attribute; 1 then the Data Authentication Request Attribute applies; and 2 then the Data Authentication Reply Attribute applies. The attributes are explained in further detail in section 4.6. 10 4.4.4.3 SESSION KEY ALLOCATION EXTENSION The Session Key Allocation Extension is used when allocation of a secret or a public session key is required. The sub-type field value of this extension determines if it is used in the Request or Reply message. 15 This extension contains: a type of KEYALLOCATION_ EXT; a sub-type; the length of all the attributes values; and the Attribute values. The Sub-Type is: 1 for the Session Key Allocation Request Extension; 2 for the Session Key Allocation Reply Extension, single key 20 allocated; and 3 for the Session Key Allocation Reply Extension, duplicate key allocated. If the Sub-Type is: 1, the Secret Key Request Data Attribute applies; 2, the Single Secret Key Reply Data Attribute applies; and 3, the Duplicate Secret Key Reply Data Attribute applies. 25 The attributes are explained in further detail in section 4.6. 4.4.4.4 SESSION KEY DELETE EXTENSION The Session Key Delete Extension is used when the delete of a secret or public session key is required. 30 This extension contains: a type of IPMEXTENSIONS; a sub-type of SESSIONKEY DELETEREQUESTEXT; a length of WO 01/19050 PCT/IBOO/01553 188 the extension including the Key IDs; and the Key ID assigned by the User Authentication Server. 4.4.4.5 SESSION KEY LIFETIME RENEWAL EXTENSION The Session Key Lifetime Renewal Extension is used 5 when the renewal of a secret or public session key lifetime is required. Also, it is added to the User Service Reply message if the request is honored by the User Authentication Server. This extension contains: a type of IPMEXTENSIONS; a sub-type of 10 SESSIONKEYLIFETIMERENEWALEXT, a length of the extension including the Key IDs; the required new lifetime for the key; and the ID for the key to extend his lifetime. 4.4.4.6 USER AUTHENTICATION INFORMATION EXTENSION 15 The User Authentication Information Extension can only be sent in the User Service Request message. It contains all the needed data attributes, which contain the required information about the user for the process of verification and authentication (e.g. SSN, Account 20 Number, etc.). This extension contains: a type of USERAUTHINFOEXT; a sub-type of 0; the length of all the attributes values. The Attributes used in the User Authentication Information Extension are: Account Number Data Attribute; SSN Data Attribute (Optional); User Name 25 Data Attribute (Recommended); User Birthday Data Attribute (Recommended); User Password Data Attribute (Optional); User Address Data Attribute (Optional); User Home Phone Number Data Attribute (Optional); User Work Phone Number Data Attribute (Optional); User NAI Data 30 Attribute (Recommended); User PIN Number Data Attribute (Optional); and Digital Signature Data Attribute WO 01/19050 PCT/IBOO/01553 189 (Recommended) . The Attributes are discussed further in section 4.6. 4.5 AVPS AVPs is a method of encapsulating information 5 relevant to the DIAMETER message. DIAMETER AVPs carry specific authentication, accounting and authorization information, security information as well as configuration details for the request and reply messages. 10 The AVP format is shown below and must be sent in network byte order. The AVPs contain: an AVP Code that identifies the attribute uniquely; the AVP length of this attribute including the AVP Code, AVP Length, AVP Flags, Reserved, The Tag and Vendor ID fields if present and the 15 AVP data; AVP flags that inform the DIAMETER host how each attribute must be handled; a Vendor ID field; a Tag field to provide a means of grouping attributes in the same message which refer to the same set; and a Data field, which contains information specific. to the 20 attribute. The AVP Flags include, among others: Reserved Bits; a mandatory bit, indicates whether support of the AVP is required; a Vendor-Specific bit, indicates whether the optional Vendor ID field is present in the AVP header; 25 and a Tag bit, is used to group sets of AVPs together. The Data Field may be one of several types, among others. First, the data may contain a variable length of arbitrary data. Unless otherwise noted, the AVP Length field MUST be set to at least 9. Second, the data may 30 contain a non-NULL terminated variable length string using the UTF-8 character set. Unless otherwise noted, WO 01/19050 PCT/IB00/01553 190 the AVP Length field MUST be set to at least 9. Third, it may be an address as a 32 bit (Ipv4) or -128 bit (Ipv6) address, most significant octet first. The format of the address (Ipv4 or Ipv6) is determined by the length. If 5 the attribute value is an Ipv4 address, the AVP Length field MUST be 12, otherwise the AVP Length field MUST be set to 24 for Ipv6 addresses. Fourth, it may be a 32-bit value, in network byte order. The AVP Length field MUST be set to 12. Fifth, it may be a 64-bit value, in 10 network byte order. The AVP Length field MUST be set to 16. Sixth, it may be indicate a time as a 32-bit unsigned value, in network byte order, and contains the seconds since 00:00:00 GMT, January 1, 1900. The AVP Length field MUST be set to 12. Finally, it may be a 15 complex data type is reserved for AVPs that includes multiple information fields, and therefore do not fit within any of the AVP types defined above. Complex AVPs must provide the data format, and the expected length of the AVP. 20 4.5.1 COMMAND-CODE AVP The Command-Code AVP must be the first AVP following the DIAMETER header. A DIAMETER message must have at most one Command-Code AVP, and it is used in order to communicate the command associated with the message. 25 The code value is 256 and the type is Integer32. 4.5.2 DESTINATION-NAI AVP This AVP is used to carry the NAI of the destination. The code value is 269 and the type is String. 30 WO 01/19050 PCT/IBOO/01553 191 4.5.3 HOME-AGENT-ADDRESS AVP This AVP contains the MN's Home Agent Address. The code value is 334 and the type is Address. 4.5.4 HOST-NAME AVP 5 The Host-Name AVP is used to inform a DIAMETER peer of the sender's identity. All DIAMETER messages MUST include the Host-Name AVP, which contains the host name of the originator of the DIAMETER message that MUST follow the NAI naming conventions. The code value is 32 10 and the type is String. 4.5.5 IPM-CARE-OF-ADDRESS AVP This AVP is used to carry the MN's Care-of-Address. The code value is 362 and the type is Address. 4.5.6 IPM-CLIENT-ADDRESS AVP 15 This AVP is used to carry the MN's IP Address, either Static or Dynamic. The code value is 360 and the type is Address. 4.5.7 IPM-CONTEXT-DATA AVP This AVP carries the Context Data of the User at 20 previous SMM. The complex data could contain AVP format data. The Context-Data could potentially carry the QOS information that MN was receiving at previous SMM. The code value is 373 and the type is Data. 4.5.8 IPM-CONTEXT-REQUEST-TYPE AVP 25 This AVP carries the Context requested by the SMM. The code value is 372 and the type is Integer32. The Context-Request is: 0; 1 with IP-Forwarding; and 2 with IP-Buffering. 4.5.9 IPM-HMM-NAI AVP 30 This AVP is used to carry the HMM's NAI. The code value is 364 and the type is String.

WO 01/19050 PCT/IBOO/01553 192 4.5.10 IPM-L2-ADDRESS AVP - This AVP carries the L2-Address of IPM Client connection. The AVP carries both the types of Address and Data. The code value is 374 and the type is Data. The 5 types of Addresses include, among others, 802.3 Address (0), 802.11 Address (1), IMSI (2), and MIN (3). 4.5.11 IPM-PROFILE AVP This AVP carries the Profile of the User, who is registering. The complex data could contain AVP format 10 data. The code value is 371 and the type is Data. 4.5.12 IPM-PROFILE-TYPE AVP This AVP carries the user Profile requested by SMM with the IRR message. The code value is 370 and the type is Integer32. The Profile types include, among others: 15 Partial (0) - Minimal Profile required; and Full (1) Complete Profile of the user. 4.5.13 IPM-REGISTRATION-CANCELLATION-REASON AVP This AVP carries the reason for the Registration Cancellation message being sent by MNN to SMM. The code 20 value is 375 and the type is Integer32. 4.5.14 IPM-REGISTRATION-REPLY AVP This AVP carries IPM Registration-Reply message received from the HMM to SMM. The code value is 367 and the type is Data. 25 4.5.15 IPM-REGISTRATION-REQUEST AVP This AVP carries either complete or partial IPM Registration Request message received from the MN. The code value is 366 and the type is Data. 4.5.16 IPM-REGISTRATION-RESPONSE-CODE AVP 30 This AVP carries the Registration-Response-Code. The code value is 368 and the type is Integer32.

WO 01/19050 PCT/IBOO/01553 193 4.5.17 IPM-REGISTRATION-TYPE AVP This AVP is used to carry the type of Registration. The code value is 361 and the type is Integer32. The types of Registration include, among others: Initial 5 Registration (0); De-Registration (1); System-Change (2); ANI-Change (3); Local Re-Registration (4); Re Registration (5); Clean-Up (6); Location-Update (7); and Admin-Initiated-Clean-Up (8). 4.5.18 IPM-ROUTING-AREA-NAI AVP 10 This AVP carries the ANI's NAI, where the MN is currently registered. The code value is 365 and the type is String. 4.5.19 IPM-SMM-MN-KEY AVP This AVP carries the shared secret key between SMM 15 and MN. This key is only valid for the session. The code value is 376 and the type is Data. 4.5.20 IPM-SMM-NAI AVP This AVP carries the SMM's NAI. The code value is 363 and the type is String. 20 4.5.21 IPM-TERMINAL-TYPE AVP This AVP carries the Terminal Type of MN. The code value is 369 and the type is Integer32. The Terminal Types include, among others: 802.3 Type Terminal (1); 802.11 Type Terminal (1); IS91 Type Terminal (2); IS36 25 Type Terminal (3); IS96 Type Terminal (4); Modem (5); and Unknown Terminal (#ffffffff). 4.5.22 INTEGRITY-CHECK-VALUE AVP The Integrity-Check-Value AVP is used for hop-by-hop message authentication and integrity. The code value is 30 259 and the type is Complex.

WO 01/19050 PCT/IBOO/01553 194 4.5.23 NONCE AVP The Nonce AVP MUST be present prior to the Integrity-Check-Value AVPs within a message and is used to ensure randomness within a message. The code value 5 is 261 and the type is Data. 4.5.24 PROXY-STATE AVP The Proxy-State AVP is used by proxy servers when forwarding requests and contains opaque data that is used *by the proxy to further process the response. The code 10 value is 33 and the type is Address. 4.5.25 RESULT-CODE AVP The Result-Code AVP indicates whether a particular request was completed successfully or whether an error occurred. The code value is 268 and the type is 15 Complex. 4.5.26 TIMESTAMP AVP The Timestamp AVP is used to add replay protection to the DIAMETER protocol. This AVP MSUT appear prior to the Integrity-Check-Value AVP or any other message 20 integrity AVP defined in separate extensions. The code value is 262 and the type is Time. 4.5.27 USER-NAME AVP The User-Name AVP contains the User-Name in a format consistent with the NAI specification. All DIAMETER 25 systems SHOULD support usernames of at least 72 octets in length. The code value is 1 and the type is String. 4.6 ATTRIBUTES Data Attribute is a payload for extensions. The format of the Data Attributes provides the flexibility 30 for representation of many different types of information. There can be multiple Data Attributes within WO 01/19050 PCT/IBOO/01553 195 any extension payload. The length of Data Attributes will either be 2 octets or defined by the payload length field. Data Attributes contain: an Attr Type (AT), a unique identifier for each type of attribute; a Sub-Type, 5 which defines the attribute sub-type; an Attribute Format (AF) that format indicates whether the data attribute follows the type Type/Value (TV) format (AF=l) or follows the Type/Length/Value (TLV) format (AF=0); the length of the attribute value; and a variable length attribute 10 value. 4.6.1 ACCOUNT NUMBER DATA ATTRIBUTE The Account Number Data Attribute defines the User's account number assigned by the ISP. The AF is 0, the AT is 1, the length is 4, and the attribute value is the 15 Account Number Value. The sub-type values are: 0, for the default value; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain 20 public key. 4.6.2 DATA AUTHENTICATION REPLY ATTRIBUTE The Data Authentication Reply Attribute carries the authenticator, which is the result of running the hash function on the authentication data provided in the Data 25 Authentication Request Attribute. The AF is 0, the AT is 24, the length is variable, and the attribute value is the Authenticator Data. The sub-type values are: 0 for the default sub-type; 1 for secret key encryption using the shared secret key between the user and its home 30 domain; 2 for public key encryption using the user's WO 01/19050 PCT/IBOO/01553 196 private key; and 3 for public key encryption using the home domain public key. 4.6.3 DATA AUTHENTICATION REQUEST ATTRIBUTE The Data Authentication Request Attribute is used to 5 carry the data, which needs to be authenticated by the IPM Security Center by running the hash function on this data. The AF is 0, the AT is 23, the length is variable, and the attribute value is the Authentication Data. The Authentication Data is is the control message 10 data, which needs to be authenticated by the IPM Security Center by running the hash function on this data. The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public 15 key encryption using the user's private key; and 3 for public key encryption using the home domain public key. 4.6.4 DIGITAL SIGNATURE DATA ATTRIBUTE The Digital Signature Data Attribute defines the User's Digital Signature, which is created by running a 20 hash function H (e.g. MD5) over a message fragment. This Attribute should be encrypted using the full secret key between the MN and its home domain or the private key for the MN. The AF is 0, the AT is 11, the length is variable, and the attribute value is the Digital 25 Signature Value. The Digital Signature Value is a sequence of bytes generated from running a hash function over all the attribute's payload for the User Authentication Information Extension. 30 The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret WO 01/19050 PCT/IBOO/01553 197 key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain public key. 4.6.5 DUPLICATE SECRET KEY REPLY DATA ATTRIBUTE 5 The Duplicate Secret Key Reply Data Attribute carries the session key information, which is allocated by IPM Security Center. Another encrypted copy is generated and sent in conjunction with the original one. This attribute can be included in the Session Key 10 Allocation Extension when the extension sub-type field value is 3. The AF is 0, the AT is 22, the length is variable, and the attribute value is the Key ID (the key unique identifier issued by the IPM Security Center), Key Data (the secret key generated by the IPM Security 15 Center), and the Encrypted Duplicate Key Data (a copy from the key data encrypted by the method defined by the sub-type field). The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret 20 key between the user and its home domain; and 2 for public key encryption using the user's private key. 4.6.6 SSN DATA ATTRIBUTE The SSN Data Attribute defines the User's SSN. The AF is 0, the AT is 2, the length is 4, and the 25 attribute value is the SSN Value. The Digital Signature Value is a sequence of bytes generated from running a hash function over all the attribute's payload for the User Authentication Information Extension. 30 The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret WO 01/19050 PCT/IBOO/01553 198 key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain public key. 4.6.7 SECRET KEY REQUEST DATA ATTRIBUTE 5 The Secret Key Request Data Attribute is used to request a dynamically allocated session secret key with a specific length from the IPM Security Center. The Session Key Allocation Request Extension may have multiple Secret Key Request Data Attributes. . The AF is 1, the AT is 10 20, the length is variable, and the attribute value is the Encryption Type, Key length, and a request number. The sub-type values are: 0 for a single key to be allocated and encrypted using the Encryption type; and 1 for a single key to be allocated and duplicated, the 15 duplicate will be encrypted by the encryption method defined by the Encryption Type field The Encryption Type values are: 0 for the default sub-type; 1 for secret key encryption using the shared secret key between the user and its home domain; and 2 20 for public key encryption using the user's private key. The request number is a number that distinguishes between the different key allocation requests issued to the IPM Security Center. The issuer of the request will use the request number to match the key allocation 25 request with the Key Allocation Reply. 4.6.8 SINGLE SECRET KEY REPLY DATA ATTRIBUTE The Single Secret Key Reply Data Attribute carries the session key information, which is allocated by the IPM Security Center. This attribute is carried by the 30 Session Key Allocation Extension when the extension Sub Type value is 2. The AF is 0, the AT is 21, the length WO 01/19050 PCT/IBOO/01553 199 is variable, and the attribute value is the key lifetime, a Security Parameter Index, a Key ID, and the Key Data The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret 5 key between the user and its home domain; and 2 for public key encryption using the user's private key. The Security Parameter Index in conjunction with the generated key will be used to define a security association between two entities (e.g. MN and HMM, MN and 10 SMM). 4.6.9 USER ADDRESS DATA ATTRIBUTE The User Address Data Attribute defines the User's current address. The AF is 0, the AT is 6, the length is variable, and the attribute value is the User Address 15 Value. The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for 20 public key encryption using the home domain public key. The User Address Value contains the country, state, city, street, and apartment number. 4.6.10 USER BIRTHDAY DATA ATTRIBUTE The User Birthday Data Attribute defines the User's 25 birthday. The AF is 0, the AT is 4, the length is variable, and the attribute value is the User Birthday Value. The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret 30 key between the user and its home domain; 2 for public WO 01/19050 PCT/IB00/01553 200 key encryption using the user's private key; and 3 for public key encryption using the home domain public key. The User Birthday contains the month, day, and year. 4.6.11 USER HOME PHONE NUMBER DATA ATTRIBUTE 5 The User Home Phone Number Data Attribute defines the User's home phone number. The AF is 0, the AT is 7, the length is variable, and the attribute value is the User Home Phone Number Value. The sub-type values are: 0 for the default sub 10 type; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain public key. 4.6.12 USER NAI DATA ATTRIBUTE 15 The User NAI Data Attribute defines the User Network Access Identifier. The AF is 0, the AT is 9, the length is variable, and the attribute value is the User NAI Data. The sub-type values are: 0 for the default sub 20 type; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain public key. The User NAI contains a string representing the User 25 Network Access Identifier. 4.6.13 USER NAME DATA ATTRIBUTE The User Name Data Attribute defines the User's full name. The AF is 0, the AT is 3, the length is variable, and the attribute value is the User Name Data. 30 The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret WO 01/19050 PCT/IB00/01553 201 key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain public key. The User Name Value contains the user's first, 5 middle, and last name. 4.6.14 USER PASSWORD DATA ATTRIBUTE The User Password Data Attribute defines the User's password. The AF is 0, the AT is 5, the length is variable, and the attribute value is the User Password 10 Data. The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for 15 public key encryption using the home domain public key. The User Password Data is a string representing the user's password. 4.6.15 USER PIN NUMBER DATA ATTRIBUTE It is an integer value selected by the user to 20 secure access to his account This Attribute may be included with User Authentication Information Extension. The AF is 0, the AT is 10, the length is variable, and the attribute value is the User PIN Number Data. The sub-type values are: 0 for the default sub 25 type; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain public key. 4.6.16 USER WORK PHONE NUMBER DATA ATTRIBUTE 30 The User Work Phone Number Data Attribute defines the User's work phone number. One or more of these WO 01/19050 PCT/IB00/01553 202 Attributes may be included with the User Authentication Information Extension. The AF is 0, the AT is 8, the length is variable, and the attribute value is the User Work Phone Number Data. 5 The sub-type values are: 0 for the default sub type; 1 for secret key encryption using the shared secret key between the user and its home domain; 2 for public key encryption using the user's private key; and 3 for public key encryption using the home domain public key. 10 The use of the present invention results in a flexible and scalable architecture that supports user mobility across heterogeneous access networks in a totally IP centric network. Furthermore, the present invention achieves these results and provides a Mobility 15 Enabled Network using many existing and/or proposed IP technologies and philosophies (defined, e.g., by the IETF or ITU) to achieve the foregoing results. Such a network may be used for a number for purposes. For example, the network may be used to evolve existing Cellular Networks 20 and/or become the Next Generation (NG) Network base reference; the network may be used to provide an enhanced Intranet for enterprise, that is, an Intranet that supports seamless mobility for users between subnets, access technologies, and has an integrated voice and data 25 network; the network may be used as a product offering for Mobility Internet Service Provider (ISP) services offering; and/or the network may be used to provide "Always-On" loop access. It is understood that the present invention may take 30 many forms and embodiments. Accordingly, several variations may be made in the foregoing without departing 202 WO 01/19050 PCT/IB00/01553 203 from the spirit or the scope of the invention. For example, while the Internet may constitute a public domain network, the present invention may comprise an IP based network that is not necessarily part of the public 5 Internet. Having thus described the present invention by reference to certain of its preferred embodiments, it is noted that the embodiments disclosed are illustrative rather than limiting in nature and that a wide range of 10 variations, modifications, changes, and substitutions are contemplated in the foregoing disclosure and, in some instances, some features of the present invention may be employed without a corresponding use of the other features. Many such variations and modifications may be 15 considered obvious and desirable by those skilled in the art based upon a review of the foregoing description of preferred embodiments. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention. 203 WO 01/19050 PCT/IB00/01553 204 BASE PROTOCOL SPECIFICATIONS IP Mobility Group Nortel Networks 2221 Lakeside Boulevard Richardson, Texas 75082, USA Page 1 of 138 WO 01/19050 PCT/IB00/01553 205 1. INTRODUCTION................................................................................................ 12 2. IPM MESSAGE FLOWS....................................................................................... 13 2.1 IPM MN REGISTERS FROM THE IPM LSF ................................................ 13 2.1.1 AGENT DISCOVERY PROCESS.................................................................. 13 2.1.1.1 Agent Solicitation and Message Format .............................................. 13 2.1.1.2 Agent Advertisement and Message Format ...................................... 14 2.1.2 REGISTRATION PROCESS ............................................................................ 15 2.1.2.1 Registration Request and Message Format ...................................... 15 2.1.2.2 AAA-Registration Request and Message Format ............................. 16 2.1.2.3 Service Request and Message Format.............................................. 17 2.1.2.4 Service Response and Message Format ........................................... 18 2.1.2.5 Add Tunnel Entry and Message Format........................................... 18 2.1.2.6 Add Tunnel Entry Acknowledgement and Message Format ............ 19 2.1.2.7 AAA-Registration Reply and Message Format................................ 20 2.1.2.8 Add Tunnel Exit and Message Format.............................................. 21 2.1.2.9 Add Tunnel Exit Acknowledgement and Message Format............... 21 2.1.2.10 Registration Reply and Message Format........................................... 22 2.2 IPM MN REGISTERS FROM IPM NSF ......................................................... 24 2.2.1 AGENT DISCOVERY PROCESS.................................................................. 24 2.2.1.1 Agent Solicitation and Message Format ........................................... 24 2.2.1.2 Agent Advertisement and Message Format ...................................... 24 2.2.2 REGISTRATION PROCESS ............................................................................ 24 2.2.2.1 Registration Request and Message Format ...................................... 24 2.2.2.2 Service Request and Message Format.............................................. 24 2.2.2.3 Service Response and Message Format ........................................... 24 2.2.2.4 Registration Reply and Message Format........................................... 25 2.3 IPM MN DISCONNECT DETECTION .......................................................... 26 2.3.1 REGISTRATION PROCESS ............................................................................ 26 2.3.1.1 Registration Request and Message Format ...................................... 26 2.3.1.2 Registration Reply and Message Format........................................... 26 2.4 IPM MN RE-REGISTERS FROM IPM LSF................................................... 27 2.4.1 REGISTRATION PROCESS .......................................................................... 27 2.4.1.1 Registration Request and Message Format ...................................... 27 2.4.1.2 AAA-Registration Request and Message Format ............................ 27 2.4.1.3 Service Request and Message Format.............................................. 27 2.4.1.4 Service Response and Message Format ........................................... 27 2.4.1.5 AAA-Registration Reply and Message Format................................ 27 2.4.1.6 Registration Reply and Message Format........................................... 27 2.5 IPM MN RE-REGISTERS FROM IPM NSF .................................................. 28 2.5.1 REGISTRATION PROCESS ............................................................................ 28 2.5.1.1 Registration Request and Message Format ...................................... 28 2.5.1.2 Service Request and Message Format............................................. 28 2.5.1.3 Service Response and Message Format ........................................... 28 2.5.1.4 Registration Reply and Message Format........................................... 28 2.6 IPM MN DE-REGISTERS FROM IPM LSF................................................... 29 2.6.1 REGISTRATION PROCESS .......................................................................... 29 2.6.1.1 Registration Request and Message Format ...................................... 29 Page 2 of 138 WO 01/19050 PCT/IB00/01553 206 2.6.1.2 AAA-Registration Request and Message Format ................................ 29 2.6.1.3 Service Request and Message Format ............................................. 29 2.6.1.4 Service Response and Message Format ........................................... 29 2.6.1.5 Delete Tunnel Entry and Message Format ....................................... 29 2.6.1.6 Delete Tunnel Entry Acknowledgement and Message Format........ 30 2.6.1.7 AAA-Registration Reply and Message Format................................ 31 2.6.1.8 Delete Tunnel Exit and Message Format ......................................... 31 2.6.1.9 Delete Tunnel Exit Acknowledgement and Message Format .......... 31 2.6.1.10 Registration Reply and Message Format........................................... 32 2.7 IPM MN DE-REGISTERS FROM IPM NSF .................................................. 33 2.7.1 REGISTRATION PROCESS ............................................................................ 33 2.7.1.1 Registration Request and Message Format ...................................... 33 2.7.1.2 Service Request and Message Format.............................................. 33 2.7.1.3 Service Response and Message Format ........................................... 33 2.7.1.4 Registration Reply and Message Format......................................... 33 2.8 IPM MN HANDOFFS FROM ANI TO ANI IN THE SAME SMM....... 34 (D IFFEREN T ITS)...................................................................................... 34 2.8.1 R EGISTRATION PROCESS ............................................................................ 34 2.8.1.1 Registration Request and Message Format ...................................... 34 2.8.1.2 AAA-Registration Request and Message Format ............................ 34 2.8.1.3 Add Tunnel Exit and Message Format.............................................. 34 2.8.1.4 Tunnel Forwarding and Message Format......................................... 34 2.8.1.5 Add Tunnel Exit Acknowledgement and Message Format.............. 35 2.8.1.6 Tunnel Forwarding Acknowledgement and Message Format.......... 35 2.8.1.7 Add Tunnel Entry and Message Format........................................... 36 2.8.1.8 Add Tunnel Entry Acknowledgement and Message Format ........... 36 2.8.1.9 AAA-Registration Reply and Message Format................................ 36 2.8.1.10 Delete Tunnel Exit and Message Format ......................................... 36 2.8.1.11 Delete Tunnel Exit Acknowledgement and Message Format .......... 36 2.8.1.12 Registration Reply and Message Format........................................... 37 2.9 IPM MN HANDOFFS FROM ANI TO ANI IN THE SAME SMM....... 38 (SA M E IT S)................................................................................................. 38 2.9.1 REGISTRATION PROCESS ............................................................................ 38 2.9.1.1 Registration Request and Message Format ...................................... 38 2.9.1.2 AAA-Registration Request and Message Format ............................ 38 2.9.1.3 AAA-Registration Reply and Message Format................................ 38 2.9.1.4 Registration Reply and Message Format........................................... 38 2.10 IPM MN HANDOFFS FROM SMM TO SMM .............................................. 39 2.10.1 REGISTRATION PROCESS ......................................................................... 39 2.10.1.1 Registration Request and Message Format ...................................... 39 2.10.1.2 AAA-Registration Request and Message Format ............................ 39 2.10.1.3 AAA-Context Request and Message Format .................................... 39 2.10.1.4 Service Request and Message Format.............................................. 40 2.10.1.5 AAA-Context Response and Message Format.................................. 40 2.10.1.6 Service Response and Message Format ........................................... 41 2.10.1.7 Add Tunnel Entry and Message Format............................................ 41 2.10.1.8 Add Tunnel Entry Acknowledgement and Message Format ............ 41 2.10.1.9 AAA-Registration Reply and Message Format................................ 41 2.10.1.10 Registration Reply and Message Format......................................... 41 Page 3 of 138 WO 01/19050 PCT/IB00/01553 207 2.10.1.11 AAA-Binding-Update Request and Message Format ...................... 41 2.10.1.12 AAA-Binding Update Response and Message Format .................... 42 2.11 IPM MN HANDOFFS LSF TO NSF (HOME ANI).................. 44 2.11.1 REGISTRATION PROCESS ......................................................................... 44 2.11.1.1 Registration Request and Message Format ...................................... 44 2.11.1.2 Service Request and Message Format............................................. 44 2.11.1.3 Service Response and Message Format .......................................... 44 2.11.1.4 Delete Tunnel Entry and Message Format ........................................ 44 2.11.1.5 Delete Tunnel Entry Acknowledgement and Message Format........ 45 2.11.1.6 Registration Reply and Message Format........................................... 45 2.11.1.7 AAA-Registration Cancellation and Message Format ..................... 45 2.11.1.8 AAA-Registration Cancellation Ack. and Message Format ............ 45 2.12 IPM MN HANDOFFS NSF (HOME ANI) TO LSF.................. 47 2.12.1 REGISTRATION PROCESS ......................................................................... 47 2.12.1.1 Registration Request and Message Format ...................................... 47 2.12.1.2 AAA-Registration Request and Message Format ............................. 47 2.12.1.3 Service Request and Message Format............................................. 47 2.12.1.4 Service Response and Message Format .......................................... 47 2.12.1.5 Add Tunnel Entry and Message Format........................................... 47 2.12.1.6 Add Tunnel Entry Acknowledgement and Message Format ........... 48 2.12.1.7 AAA-Registration Reply and Message Format................................ 48 2.12.1.8 Add Tunnel Exit and Message Format............................................. 48 2.12.1.9 Add Tunnel Exit Acknowledgement and Message Format.............. 48 2.12.1.10 Registration Reply and Message Format........................................... 48 2.13 IPM MN HANDOFFS FROM LSF TO NSF (FOREIGN ANI).......... 49 2.13.1 REGISTRATION PROCESS ......................................................................... 49 2.13.1.1 Registration Request and Message Format ...................................... 49 2.13.1.2 Service Request and Message Format........................ .. 49 2.13.1.3 Service Response and Message Format .......................................... 49 2.13.1.4 Add Tunnel Exit and Message Format............................................. 49 2.13.1.5 Add Tunnel Entry and Message Format........................................... 50 2.13.1.6 Add Tunnel Exit Acknowledgement and Message Format.............. 50 2.13.1.7 Add Tunnel Entry Acknowledgement and Message Format ............ 50 2.13.1.8 Registration Reply and Message Format........................................... 50 2.13.1.9 AAA Registration Cancellation and Message Format ...................... 50 2.13.1.10 AAA Registration Cancellation Ack. and Message Format.............. 50 2.14 IPM MN HANDOFFS FROM NSF (FOREIGN ANI) TO LSF.......... 51 2.14.1 REGISTRATION PROCESS ......................................................................... 51 2.14.1.1 Registration Request and Message Format ...................................... 51 2.14.1.2 AAA Registration Request and Message Format............................. 51 2.14.1.3 Service Request and Message Format............................................. 51 2.14.1.4 Service Response and Message Format ........................................... 51 2.14.1.5 Add Tunnel Entry and Message Format........................................... 51 2.14.1.6 Delete Tunnel Exit and Message Format .......................................... 52 2.14.1.7 Add Tunnel Entry Acknowledgement and Message Format ........... 52 2.14.1.8 Delete Tunnel Exit Acknowledgement and Message Format.......... 52 2.14.1.9 AAA Registration Reply and Message Format ................................. 52 2.14.1.10 Add Tunnel Exit and Message Format............................................. 52 2.14.1.11 Add Tunnel Exit Acknowledgement and Message Format.............. 52 Page 4 of 138 WO 01/19050 PCT/IB00/01553 208 2.14.1.12 Registration Reply and Message Format........................................... 52 2.15 IPM MN HANDOFFS FROM FOREIGN ANI TO FOREIGN ANI IN......... 53 TH E SA M E N SF ........................................................................................... 53 2.15.1 REGISTRATION PROCESS ......................................................................... 53 2.15.1.1 Registration Request and Message Format ................... 53 2.15.1.2 Add Tunnel Exit and Message Format......................53 2.15.1.3 Tunnel Forwarding and Message Format .................... 53 2.15.1.4 Service Request and Message Format......................54 2.15.1.5 Add Tunnel Exit Acknowledgement and Message Format ........ 54 2.15.1.6 Tunnel Forwarding Acknowledgement and Message Format......54 2.15.1.7 Service Response and Message Format ...................................... 54 2.15.1.8 Add Tunnel Entry and Message Format............................................... 54 2.15.1.9 Add Tunnel Entry Acknowledgement and Message Format............... 54 2.15.1.10 Registration Reply and Message Format.............................................. 55 2.15.1.11 Delete Tunnel Exit and Message Format.................... 55 2.15.1.12 Delete Tunnel Exit Acknowledgement and Message Format....... 55 2.16 1PM MN HANDOFFS FROM HOME ANI TO FOREIGN ANI IN THE 5 6 SAME NSF and.Mesa...................t............................................... 56 2.16.1 REGISTRATION PROCESS........................................................... 56 2.16.1 .1 Registration Request and Message Format............................... 56 2.16.1.2 Service Request and M essage Format............................................... 56 2.16.1.3 Service Response and Messaag Format ....................... 56 2.16.1.4 Add Tunnel Entry and Message Format.......................................... 56 2.16.1.5 Add Tunnel Exit and M essage Format ............................................. 57 2.16.1.6 Add Tunnel Entry Acknowledgement and Message Format....... 57 2.16.1.7 Add Tunnel Exit Acknowledgement and Message Format............ 57 2.16.1.8 Registration Reply and Message Format.................................. 57 2.17 IPM MN HANDOFFS FROM FOREIGN ANI TO HOME ANI IN THE 58 SA M E N SF .................................................................................................... 58 2.17.1 REGISTRATION PROCESS ......................................................................... 58 2.17.1.1 Registration Request and Message Format ...................................... 58 2.17.1.2 Service Request and Message Format............................................. 58 2.17.1.3 Service Response and Message Format ........................................... 58 2.17.1.4 Delete Tunnel Entry and Message Format................... 58 2.17.1.5 Delete Tunnel Exit and Message Format.................... 59 2.17.1.6 Delete Tunnel Entry Acknowledgement and Message Format ...... 59 2.17.1.7 Delete Tunnel Exit Acknowledgement and Message Format....... 59 2.17.1.8 Registration Reply and Message Format........................................... 59 3. INTERWORKING MESSAGE FLOWS IPM-MIP ................... 60 3.1 1PM MN REGISTERS FROM MIP FA...........................................................60 3.1.1 AGENT D ISCOVERY PROCESS ..................................................................... 60 3.1.1.1 Agent Solicitation and Message Format ....................................... 60 3.1.1.2 Agent Advertisement and Message Format...................61 3 7..2 REGISTRATION PROCESS ............. ............................................ 62 3.1.2.1 Registration Request and Message Format ....................................... 62 3.1.2.2 Service Request and Message Format ......................................... 63 PageS5 of 138 WO 01/19050 PCT/IB00/01553 209 3.1.2.3 Service Response and Message Format .......................................... 64 3.1.2.4 Add Tunnel Entry and Message Format........................................... 65 3.1.2.5 Add Tunnel Entry Acknowledgement and Message Format ........... 65 3.1.2.6 Registration Reply and Message Format........................................... 66 3.2 IPM MN RE-REGISTERS FROM MIP FA..................................................... 67 3.2.1 REGISTRATION PROCESS ......................................................................... 67 3.2.1.1 Registration Request and Message Format ...................................... 67 3.2.1.2 Service Request and Message Format............................................. 67 3.2.1.3 Service Response and Message Format .......................................... 67 3.2.1.4 Registration Reply and Message Format........................................... 67 3.3 IPM MN DE-REGISTERS FROM MIP FA .................................................... 68 3.3.1 REGISTRATION PROCESS ......................................................................... 68 3.3.1.1 Registration Request and Message Format ...................................... 68 3.3.1.2 Service Request and Message Format............................................. 68 3.3.1.3 Service Response and Message Format .......................................... 68 3.3.1.4 Delete Tunnel Entry and Message Format ........................................ 68 3.3.1.5 Delete Tunnel Entry Acknowledgement and Message Format........ 69 3.3.1.6 Registration Reply and Message Format........................................... 69 3.4 IPM MN HANDOFFS FROM IPM ANI TO FA (NO SMOOTH ......... 71 H A N D O FF)................................................................................................. 71 3.4.1 REGISTRATION PROCESS ......................................................................... 71 3.4.1.1 Registration Request and Message Format ...................................... 71 3.4.1.2 Service Request and Message Format............................................. 71 3.4.1.3 Service Response and Message Format .......................................... 71 3.4.1.4 Add Tunnel Entry and Message Format........................................... 71 3.4.1.5 Add Tunnel Entry Acknowledgement and Message Format ........... 72 3.4.1.6 Registration Reply and Message Format........................................... 72 3.4.1.7 AAA-Registration Cancellation and Message Format ..................... 72 3.4.1.8 Delete Tunnel Exit and Message Format .......................................... 72 3.4.1.9 Delete Tunnel Exit Acknowledgement and Message Format .......... 73 3.4.1.10 AAA-Registration Cancellation Ack. and Message Format ............. 74 3.5 IPM MN HANDOFFS FROM IPM ANI TO FA (SMOOTH HANDOFF) 75 3.5.1 REGISTRATION PROCESS ......................................................................... 75 3.5.1.1 Registration Request and Message Format ...................................... 75 3.5.1.2 Binding Update and Message Format ............................................... 75 3.5.1.3 Service Request and Message Format............................................. 76 3.5.1.4 Service Response and Message Format ........................................... 76 3.5.1.5 Tunnel Forwarding and Message Format......................................... 77 3.5.1.6 Add Tunnel Entry and Message Format........................................... 77 3.5.1.7 Tunnel Forwarding Acknowledgement and Message Format.......... 77 3.5.1.8 Add Tunnel Entry Acknowledgement Format and Message F orm at .............................................................................................. . 78 3.5.1.9 Binding Update Acknowledge and Message Format ........................ 78 3.5.1.10 Registration Reply and Message Format........................................... 79 3.5.1.11 AAA-Registration Cancellation and Message Format ..................... 79 3.5.1.12 Delete Tunnel Exit and Message Format .......................................... 79 3.5.1.13 Delete Tunnel Exit Acknowledgement and Message Format .......... 79 3.5.1.14 AAA-Registration Cancellation Ack. and Message Format ............. 79 Page 6 of 138 WO 01/19050 PCT/IB00/01553 210 3.6 IPM MN HANDOFFS FROM FA TO IPM ANI.................... 80 (NO SM OOTH HANDOFF) ........................................................................ 80 3.6.1 REGISTRATION PROCESS ......................................................................... 80 3.6.1.1 Registration Request and Message Format ...................................... 80 3.6.1.2 AAA-Registration Request and Message Format ............................ 80 3.6.1.3 Service Request and Message Format............................................. 81 3.6.1.4 Service Response and Message Format ........................................... 81 3.6.1.5 Add Tunnel Entry and Message Format........................................... 81 3.6.1.6 Add Tunnel Entry Acknowledgement and Message Format ........... 81 3.6.1.7 AAA-Registration Reply and Message Format................................ 82 3.6.1.8 Registration Reply and Message Format........................................... 82 3.6.1.9 Add Tunnel Exit and Message Format............................................. 83 3.6.1.10 Add Tunnel Exit Acknowledgement and Message Format.............. 83 3.7 IPM MN HANDOFFS FROM FA TO IPM ANI (SMOOTH HANDOFF) 85 3.7.1 REGISTRATION PROCESS ......................................................................... 85 3.7.1.1 Registration Request and Message Format ...................................... 85 3.7.1.2 AAA-Registration Request and Message Format ............................ 85 3.7.1.3 Binding Update and Message Format ............................................... 85 3.7.1.4 Add Tunnel Exit and Message Format............................................. 86 3.7.1.5 Add Tunnel Exit Acknowledgement and Message Format.............. 86 3.7.1.6 Service Request and Message Format............................................. 86 3.7.1.7 Binding Acknowledge and Message Format..................................... 86 3.7.1.8 Service Response and Message Format ........................................... 86 3.7.1.9 Add Tunnel Entry and Message Format........................................... 86 3.7.1.10 Add Tunnel Entry Acknowledgement and Message Format ........... 86 3.7.1.11 AAA-Registration Reply and Message Format................................ 86 3.7.1.12 Registration Reply and Message Format........................................... 86 3.8 MIP MN REGISTERS FROM IPM LSF ......................................................... 88 3.8.1 AGENT DISCOVERY PROCESS.................................................................. 88 3.8.1.1 Agent Solicitation and Message Format .......................................... 88 3.8.1.2 Agent Advertisement and Message Format ...................................... 88 3.8.2 REGISTRATION PROCESS ......................................................................... 88 3.8.2.1 Registration Request and Message Format ...................................... 88 3.8.2.2 Registration Reply and Message Format........................................... 89 3.8.2.3 Add Tunnel Exit and Message Format............................................. 89 3.8.2.4 Add Tunnel Exit Acknowledgement and Message Format............... 89 3.9 MIP MN RE-REGISTERS FROM IPM LSF................................................... 90 3.9.1 AGENT DISCOVERY PROCESS.................................................................. 90 3.9.1.1 Agent Solicitation and Message Format ........................................... 90 3.9.1.2 Agent Advertisement and Message Format ...................................... 90 3.9.2 REGISTRATION PROCESS ......................................................................... 90 3.9.2.1 Registration Request and Message Format ...................................... 90 3.9.2.2 Registration Reply and Message Format........................................... 91 3.10 MIP MN HANDOFFS FROM IPM ANI TO FA .................... 92 (NO SM OOTH HANDOFF) ........................................................................ 92 3.10.1 REGISTRATION PROCESS ............................................................................ 92 3.10.1.1 Registration Request and Message Format ...................................... 92 3.10.1.2 Registration Reply and Message Format........................................... 92 Page 7 of 138 WO 01/19050 PCT/IBOO/01553 211 3.10.1.3 Delete Tunnel Exit and Message Format ........................................ 92 3.10.1.4 Delete Tunnel Exit Acknowledgement and Message Format.......... 92 3.11 MIP MN HANDOFFS FROM IPM ANI TO FA (SMOOTH HANDOFF) 93 3.11.1 REGISTRATION PROCESS ......................................................................... 93 3.11.1.1 Registration Request and Message Format ...................................... 93 3.11.1.2 Binding Update and M essage Format ............................................... 93 3.11.1.3 Registration Reply and Message Format........................................... 93 3.11.1.4 Tunnel Forwarding and Message Format......................................... 94 3.11.1.5 Tunnel Forwarding Acknowledgement and Message Format........... 94 3.11.1.6 Binding Acknowledge and Message Format.................................... 94 3.11.1.7 Delete Tunnel Exit and Message Format ........................................ 94 3.11.1.8 Delete Tunnel Exit Acknowledgement and Message Format ........... 94 3.12 MIP MN HANDOFFS FROM FA TO IPM ANI.................... 95 (NO SM OOTH HANDOFF) ........................................................................ 95 3.12.1 REGISTRATION PROCESS ......................................................................... 95 3.12.1.1 Registration Request and Message Format ...................................... 95 3.12.1.2 Registration Reply and Message Format........................................... 95 3.12.1.3 Add Tunnel Exit and Message Format............................................. 95 3.12.1.4 Add Tunnel Exit Acknowledgement and Message Format.............. 95 3.13 MIP MN HANDOFFS FROM FA TO IPM ANI (SMOOTH HANDOFF) 96 3.13.1 REGISTRATION PROCESS ......................................................................... 96 3.13.1.1 Registration Request and Message Format ...................................... 96 3.13.1.2 Binding Update and Message Format ............................................... 96 3.13.1.3 Add Tunnel Exit and Message Format............................................. 96 3.13.1.4 Registration Reply and Message Format........................................... 97 3.13.1.5 Add Tunnel Exit Acknowledgement and Message Format.............. 97 3.13.1.6 Binding Acknowledge and Message Format.................................... 97 3.14 MIP MN HANDOFFS FROM NSF TO FA.................................................. 98 (NO SM OOTH HANDOFF) ........................................................................ 98 3.14.1 REGISTRATION PROCESS ......................................................................... 98 3.14.1.1 Registration Request and Message Format ...................................... 98 3.14.1.2 Registration Reply and Message Format........................................... 98 3.14.1.3 Delete Tunnel Exit and Message Format .......................................... 98 3.14.1.4 Delete Tunnel Exit Acknowledgement and Message Format ........... 99 3.15 MIP MN HANDOFFS FROM NSF TO FA (SMOOTH HANDOFF) ..... 100 3.15.1 REGISTRATION PROCESS .......................................................................... 100 3.15.1.1 Registration Request and Message Format .................. 100 3.15.1.2 Binding Update and Message Format......................100 3.15.1.3 Registration Reply and Message Format .................... 101 3.15.1.4 Tunnel Forwarding and Message Format ................... 101 3.15.1.5 Tunnel Forwarding Acknowledgement and Message Format......101 3.15.1.6 Binding Acknowledge and Message Format ...................................... 101 3.15.1.7 Delete Tunnel Exit and Message Format.................... 101 3.15.1.8 Delete Tunnel Exit Acknowledgement and Message Format ............ 101 3.16 MIP MN HANDOFFS FROM FA TO NSF................................................... 103 (NO SM OOTH HANDOFF) .......................................................................... 103 Page 8 of 138 WO 01/19050 PCT/IBOO/01553 212 3.16.1 R EGISTRATION PROCESS .......................................................................... 103 3.16.1.1 Registration Request and Message Format ........................................ 103 3.16.1.2 Registration Reply and Message Format............................................ 103 3.16.1.3 Add Tunnel Exit and Message Format............................................... 103 3.16.1.4 Add Tunnel Exit Acknowledgement and Message Format................ 104 3.17 MIP MN HANDOFFS FROM FA TO NSF (SMOOTH HANDOFF) ..... 105 3.17.1 REGISTRATION PROCESS .......................................................................... 105 3.17.1.1 Registration Request and Message Format ........................................ 105 3.17.1.2 Binding Update and Message Format ................................................ 105 3.17.1.3 Registration Reply and Message Format............................................ 105 3.17.1.4 Binding Acknowledge and Message Format...................................... 106 3.17.1.5 Add Tunnel Exit and Message Format............................................... 106 3.17.1.6 Add Tunnel Exit Acknowledgement and Message Format................ 106 4. EXTENSIONS....................................................................................................... 107 4.1 AGENT DISCOVERY EXTENSIONS ......................................................... 107 4.1.1 A N I-N A I EXTENSION .............................................................................. 107 4.1.2 MOBILITY AGENT ADVERTISEMENT EXTENSION ..................................... 107 4.1.3 ONE-BYTE PADDING EXTENSION ............................................................. 108 4.1.4 PREFIX-LENGTHS EXTENSION.................................................................. 108 4.2 ITS CONTROL EXTENSIONS..................................................................... 109 4.2.1 AUTHENTICATION EXTENSION ................................................................. 109 4.2.2 FLAG EXTENSION ..................................................................................... 109 4.2.3 H OST N A I EXTENSION............................................................................. 109 4.2.4 LIFETIM E EXTENSION............................................................................... 110 4.2.5 MOBILE NODE IP ADDRESS EXTENSION .................................................. 110 4.2.6 RESULT CODE EXTENSION ....................................................................... 110 4.2.7 TUNNEL ENTRY IP ADDRESS EXTENSION ................................................ 110 4.2.8 TUNNEL EXIT IP ADDRESS EXTENSION ................................................... 110 4.2.9 TUNNEL FORWARDING IP ADDRESS EXTENSION ..................................... 111 4.2.10 U SER-N A I EXTENSION ............................................................................ Il1 4.3 IPM REGISTRATION EXTENSIONS.......................................................1 l1 4.3.1 ANI-HMM AUTHENTICATION EXTENSION ........................................... Ill1 4.3.2 ANI-SMM AUTHENTICATION EXTENSION ........................................... Ill 4.3.3 L2-ADDRESS EXTENSION......................................................................... 112 4.3.4 LOCAL REGISTRATION LIFETIME EXTENSION .......................................... 112 4.3.5 MN-HOME AUTHENTICATION EXTENSION .............................................. 113 4.3.6 MN-SMM AUTHENTICATION EXTENSION ............................................... 113 4.3.7 FOREIGN-HOME AUTHENTICATION EXTENSION....................................... 113 4.3.8 MOBILE-FOREIGN AUTHENTICATION EXTENSION.................................... 114 4.3.9 MOBILE-HOME AUTHENTICATION EXTENSION ........................................ 114 4.3.10 PREvIoUS-SMM-NAI EXTENSION .......................................................... 114 4.3.11 REGISTRATION-TYPE EXTENSION ............................................................ 115 4.3.12 SM M K EY EXTENSION ............................................................................ 115 4.3.13 SM M -N A I EXTENSION............................................................................ 115 4.3.14 U SER-N A I EXTENSION ............................................................................ 116 4.4 IPM SECURITY EXTENSIONS ................................................................... 116 4.4.1 CONTROL MESSAGE AUTHENTICATION REQUEST EXTENSION................. 116 4.4.2 CONTROL MESSAGE AUTHENTICATION REPLY EXTENSION ..................... 116 Page 9 of 138 WO 01/19050 PCT/IBOO/01553 213 4.4.3 SESSION KEY ALLOCATION EXTENSION .................................................. 117 4.4.4 SESSION KEY DELETE EXTENSION ........................................................... 118 4.4.5 SESSION KEY LIFETIME RENEWAL EXTENSION........................................ 118 4.4.6 USER AUTHENTICATION INFORMATION EXTENSION ................................ 119 5. A V PS ...................................................................................................................... 120 5.1 COM M AN D -COD E AV P .............................................................................. 121 5.2 DESTIN ATION -N A I A VP ............................................................................ 121 5.3 HOM E-AGENT-ADDRESS AVP ................................................................. 121 5.4 H O ST-N A M E A V P ........................................................................................ 122 5.5 IPM -CARE-OF-ADDRESS AVP .................................................................. 122 5.6 IPM -CLIENT-ADDRESS AVP ..................................................................... 122 5.7 IPM -CONTEXT-DATA AVP........................................................................ 122 5.8 IPM-CONTEXT-REQUEST-TYPE AVP...................................................... 122 5.9 IPM -H M M -N A I A V P..................................................................................... 122 5.10 IPM -L2-ADDRESS AV P ............................................................................... 123 5.11 IPM -PR O FILE A V P ....................................................................................... 123 5.12 IPM -PROFILE-TYPE AVP............................................................................ 123 5.13 IPM-REGISTRATION-CANCELLATION-REASON AVP ........................ 123 5.14 IPM-REGISTRATION-REPLY AVP ............................................................ 124 5.15 IPM-REGISTRATION-REQUEST AVP....................................................... 124 5.16 IPM-REGISTRATION-RESPONSE-CODE AVP ........................................ 124 5.17 IPM-REGISTRATION-TYPE AVP............................................................... 124 5.18 IPM-ROUTING-AREA-NAI AVP ................................................................ 124 5.19 IPM -SM M -M N-KEY AVP ............................................................................ 125 5.20 IPM -SM M -N A I A V P ..................................................................................... 125 5.21 IPM -TERM INAL-TYPE AVP ...................................... :................................ 125 5.22 INTEGRITY-CHECK-VALUE AVP ............................................................ 125 5.23 N O N C E A V P .................................................................................................. 125 5.24 PROX Y -STA TE A V P .................................................................................... 126 5.25 RESU LT-COD E A V P .................................................................................... 126 5.26 TIM ESTA M P A V P ........................................................................................ 126 5.27 U SER -N A M E A V P ........................................................................................ 126 6. ATTRIBUTES....................................................................................................... 128 6.1 ACCOUNT NUMBER DATA ATTRIBUTE......................128 6.2 DATA AUTHENTICATION REPLY ATTRIBUTE ................ 129 6.3 DATA AUTHENTICATION REQUEST ATTRIBUTE .............. 129 6.4 DIGITAL SIGNATURE DATA ATTRIBUTE................................. 130 6.5 DUPLICATE SECRET KEY REPLY DATA ATTRIBUTE................. 130 6.6 SSN DATA ATTRIBUTE......................................................... 131 6.7 SECRET KEY REQUEST DATA ATTRIBUTE............................... 132 6.8 SINGLE SECRET KEY REPLY DATA ATTRIBUTE....................... 133 6.9 USER ADDRESS DATA ATTRIBUTE......................................... 133 6.10 USER BIRTHDAY DATA ATTRIBUTE....................................... 134 6.11 USER HOME PHONE NUMBER DATA ATTRIBUTE...................... 135 6.12 USER NAI DATA ATTRIBUTE................................................. 135 6.13 USER NAME DATA ATTRIBUTE ............................................. 136 6.14 USER PASSWORD DATA ATTRIBUTE..................................... 137 Page 10 of 138 WO 01/19050 PCT/IBOO/01553 214 6.15 USER PIN NUMBER DATA ATTRIBUTE ................................................. 137 6.16 USER WORK PHONE NUMBER DATA ATTRIBUTE ............................. 138 Page 11 of 138 WO 01/19050 PCT/IBOO/01553 215 1. INTRODUCTION This protocol specifies the functional description and the messaging interface between IPM components. It also describes the details of the messages. Page 12 of 138 WO 01/19050 PCT/IBOO/01553 216 2. IPM MESSAGE FLOWS 2.1 IPM MN REGISTERS FROM THE IPM LSF IAN L2S 1L NSF N A S 1M S-AAA H At t Solicit n Ag .. Ader se nen Regis ration Req e t (Init. Reg) R stration Re juest (IniL 1eg.) AMRgsrae Request- AAA Registration Reqest AAA Ro Rone est .......................... ~ ~ ~ ~ ~ ~ ~ ~ Se vtc e...............e.......st.......................................I................................................................................... ............ D NSFesr . . .A.. .............. ... . .... .. AAA Regstaton Replys RA AAzstra on Rep lye stervic Requ t p AAM MNgiarvi cegitpr fo 2.1.1.AgentNSiscoveryessocess A(22 inn ErcyAc AAA Repsrainlysl R pstration R ply IPM MN registers from IPM LSF 2.1.1 Agent Discovery Process Agent Discovery is the method by which a Mobile Node (MN) determines whether it is currently connected to its home network or to a foreign network, and by which a MN can detect when it has moved from one network to another. Home agents and foreign agents may advertise their availability on each link for which they provide service. A newly arrived MN can send a solicitation on the link to learn if any prospective agents are present. The Agent Discovery Process is primarily handled through Agent Solicitation and Agent Advertisement. 2.1.1.1 Agent Solicitation and Message Format Agent Solicitation is the broadcast/multicast message sent by the IPM MN to detect a Service Provider in the event that the IPM MN has not received an Advertising Agent message. The message format exchanged between the IPM MN and the ANI is as follows: Type Code Checksum Reserved Page 13 of 138 WO 01/19050 PCT/IBOO/01553 217 e Source Address - An Mobile IP address belonging to the interface from which this message is sent, or 0. This is part of the standard heading. * Destination Address - The configured Solicitation Address. This is part of the standard heading. * Type - 10 " Code -0 * Checksum - The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0. " Reserved - Sent as 0; ignored on reception. There are no Extensions for Agent Solicitation. 2.1.1.2 Agent Advertisement and Message Format Agent Advertisement are messages sent periodically, either as a broadcast or multicast for the visiting IPM MN to recognize the availability of service and to keep track of their point of attachment. The message format exchanged between the ANI and the IPM MN is as follows: Type Code Checksum Num Addrs Addr Entry Size Lifetime Router Address [1] Preference Level [1] Router Address [2] Preference Level [2] * Source Address - An IP address belonging to the interface from which this message is sent. This is part of the of the standard heading. " Destination Address - The configured Advertisement Address or the IP address of a neighboring host. This is part of the of the standard heading. e Type - 9 " Code -0 " Checksum - The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0. " Num Addrs - The number of router addresses advertised in this message. * Addr Entry Size - The number of 32-bit words of information per each router address (2, in the version of the protocol described here). Page 14 of 138 WO 01/19050 PCT/IBOO/01553 218 " Lifetime - The maximum number of seconds that the router addresses may be considered valid. * Router Address [i], i = 1..Num Addrs - The sending router's IP address(es) on the interface from which this message is sent. " Preference Level [i], i = 1..Num Addrs - The preferability of each router address [i] as a default router address, relative to other router addresses on the same subnet. A signed, two-complement value; higher values mean more preferable. The Extensions that can be used in Agent Advertisement message are, e Mobility Agent Advertisement Extension " ANI-NAI Extension and can be explained further in the Extension Section 4. 2.1.2 Registration Process The purpose of registration is for the IPM MN to inform the HMM of the NSF (Network Serving Function) of its current location to which data packets can be forwarded to the IPM MN. The Registration process also includes the authenticating and authorizing of the IPM MN to have access to the visited network or LSF (Local Serving Function). 2.1.2.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the SMM to register for the service. The message format exchanged between the IPM MN and the SMM is as follows: Type (8) Flags (8) Lifetime (16) Home Address (32) Home Agent (32) Care-of-Address (32) Identification (64) * Source Address - An IP address of the MN. This is part of the standard heading. " Destination Address - The COA within the ANI component. This is part of the standard heading. " Type - The type of the message is "0", which is the Registration Request message. " Flags - The flags filed are the same as RFC2002. Page 15 of 138 WO 01/19050 PCT/IBOO/01553 219 * Lifetime - The lifetime requested by MN from the HMM or Home. e Home Address - The IP address of the MN. " Home Agent - The Home Agent's address of the MN. " Care-of-Address - The Care-of-Address of the MN. " Identification - The identification, to provide replay protection. The Extensions used in the Registration Request are, " User-NAI Extension " L2-Address Extension (Optional) * MN-Home Authentication Extension * Registration-Type Extension * Previous-SMM-NAI Extension (Optional) " ANI-NAI Extension (Optional) e MN-SMM Authentication Extension (Optional) " ANI-SMM Authentication Extension (Optional) * ANI-HMM Authentication (Optional) and can be explained further in the Extension Section 4. 2.1.2.2 AAA-Registration Request and Message Format The AAA-Registration-Request message is used to carry out various kinds of registrations; these registrations are encapsulated in the IPM-Registration-Type AVP. This message is used by SMM to authenticate and authorize the user. The message format exchanged between the SMM and the HMM is as follows: AAA-Registration-Request <DIAMETER Header> <Command-Code AVP = 335> <User-Name AVP> <Host-Name AVP> <IPM-Registration-Type AVP> <IPM-Registration-Request AVP> <IPM-Care-of-Address AVP> <IPM-Routing-Area-NAI AVP> The AAA-Registration-Request message is of the format of DIAMETER. The SMM sends the message to HMM with at least these mandatory fields. The IPM Registration-Request AVP is the AVP which carries the message received from the MN, which is encapsulated in the AVP format for the Home domain to authenticate the user. The HMM processes this message based on the Registration-Type AVP, which carries the type of registration requested. The AVPs that can optionally be used in the Registration Request message are, Page 16 of 138 WO 01/19050 PCT/IB00/01553 220 * Destination-NAI AVP e IPM-Client-Address AVP e Home-Agent-Address AVP * IPM-SMM-NAI AVP * IPM-Terminal-Type AVP e IPM-Profile-Type AVP * Proxy-State AVP e Timestamp AVP * Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVP Section 5. 2.1.2.3 Service Request and Message Format The Service Request message is sent from the HMM to the ISC (IPM Security Center) to authenticate a user or message, generate, renew, or delete session secret keys. It also can be sent from the PPS Manager to the ISC to generate or construct the IPMC. The message format exchanged between the HMM and the ISC is as follows: Type Sub-Type Payload Length Identification User NAI " Type - USERSERVICE REQUESTMSG. " Sub-Type-0. " Payload Length - Length of the message payload including all the extensions. " Identification - A 64-bit number used for matching User Service Request messages with User Service Reply messages, and for protecting against replay attacks of User Service Request messages. * User NAI - In phase I, this extension has the user NAI and in the future will have an index which will be used to index the user data in the UDS. The Extensions used in the Service Request message are, * User Authentication Information Extension e Control Message Authentication Extension " Session Key Allocation Extension O..N e Session Key Lifetime Renewal Extension O..N " Session Key Delete Extension O..N Page 17 of 138 WO 01/19050 PCT/IBOO/01553 221 and can be explained further in the Extension Section 4. 2.1.2.4 Service Reply and Message Format The Service Reply message is sent from the ISC (IPM Security Center) to the HMM in response to a Service Request message. The message format exchanged between the ISC and the HMM is as follows: Type Sub-Type Payload Length Code Identification User NAI * Type - USERSERVICEREPLYMSG. * Sub-Type - 0. * Payload Length - Length of the message payload including all the extensions. * Code - The following are the hex values of the defined codes: - 00000001 User Authenticated successfully. - 00000002 All required keys have been allocated. - 00000003 Some keys have been allocated. - 00000004 User Authentication failed. - 00000005 Key Lifetime Renewal is completely honoured. - 00000006 Key Lifetime Renewal is partially honoured. - 00000007 User Account is created successfully. - 00000008 User is deleted successfully. * Identification - A 64-bit number used for matching User Service Request messages with User Service Reply messages, and for protecting against replay attacks of User Service Request messages. " User NAI - In phase I, this extension has the user NAI and in the future will have an index which will be used to index the user data in the UDS. The Extensions used in the Service Response message are, e Control Message Authentication Extension * Session Key Allocation Extension O..N e Session Key Lifetime Renewal Extension O..N e Session Key Delete Extension O..N and can be explained further in the Extension Section 4. 2.1.2.5 Add Tunnel Entry and Message Format Page 18 of 138 WO 01/19050 PCT/IBOO/01553 222 The Add Tunnel Entry message is sent by the HMM to instruct the ITS to set up a tunnel entry point. The message format exchanged between the HMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... * Code - 1, for Add Tunnel Entry message. " Message Length - Length of the message including the header fields. * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Entry message are, * Host NAI Extension e Flag Extension e Lifetime Extension e Mobile Node IP Address Extension " User NAI Extension (Optional) * Tunnel Entry IP Address Extension and can be explained further in the Extension Section 4. 2.1.2.6 Add Tunnel Entry Acknowledgement and Message Format The Add Tunnel Entry Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Entry message. The message format exchanged between the ITS and the HMM is as follows: Code (16) Message Length (16) Identification (64) Extensions... * Code -2, for Add Tunnel Entry Acknowledgement message. " Message Length - Length of the message including the header fields. Page 19 of 138 WO 01/19050 PCT/IBOO/01553 223 e Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Entry message are, " Host NAI Extension * Result Code Extension e Mobile Node IP Address Extension (Optional) " User NAI Extension (Optional) and can be explained further in the Extension Section 4. 2.1.2.7 AAA-Registration Reply and Message Format The AAA Registration Reply message is the response message sent by the HMM to the SMM to indicate the result of the AAA-Registration Request message. The message format exchanged between the HMM and the SMM is as follows: AAA-Registration-Response <DIAMETER Header> <Command-Code AVP = 336> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <IPM-Registration-Response-Code AVP> <IPM-Client-Address AVP> <IPM-Registration-Reply AVP> The AAA-Registration Reply message is of the format of DIAMETER. The HMM sends a message to the SMM with at least the mandatory fields in response to AAA-Registration Request message. The IPM-Registration Response Code AVP indicates the success or failure of the request. The IPM Registration Reply message AVP contains the reply message built by HMM with authentication. The SMM has to use this AVP to send a reply to ANI/MN. The AVPs that can optionally be used in the Registration Reply message are, " IPM-Profile AVP " IPM-SMM-MN-Key AVP * IPM-HMM-NAI AVP " Proxy-State AVP * Time AVP * Nonce AVP * Integrity-Check-Value AVP Page 20 of 138 WO 01/19050 PCT/IBOO/01553 224 and can be explained further in the AVPs Section 5. 2.1.2.8 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the SMM to instruct the ITS to set up a tunnel exit point. The message format exchanged between the SMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 3, for Add Tunnel Exit message. * Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Exit message are, e Host NAI Extension e Lifetime Extension e Mobile Node IP Address Extension * User NAI Extension (Optional) * Tunnel Exit IP Address Extension and can be explained further in the Extension Section 4. 2.1.2.9 Add Tunnel Exit Acknowledgement and Message Format The Add Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Exit message. The message format exchanged between the ITS and the SMM is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 4, for Add Tunnel Exit Acknowledgement message. " Message Length - Length of the message including the header fields. Page 21 of 138 WO 01/19050 PCT/IBOO/01553 225 e Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Exit Acknowledgement message are, " Host NAI Extension * Result Code Extension * Mobile Node IP Address Extension (Optional) " User NAI Extension (Optional) " Tunnel Forwarding IP Address Extension and can be explained further in the Extension Section 4. 2.1.2.10 Registration Reply and Message Format The Registration Reply message is sent by the SMM to the IPM MN to indicate the result of the Registration Request message sent. The message format exchanged between the SMM and the IPM MN is as follows: Type (8) Code (8) Lifetime Home Address (32) Home Agent (32) Identification (64) * Type - The type of the message is 3, which is the Registration Request message. * Code - All the existing MIP Response codes, this field is being extended to include IPM specific items. " Lifetime - The Home lifetime for the registration. * Home Address - The IP address of the MN. " Home Agent - The Home Agent's address of the MN. " Identification - The identification, to provide replay protection. The Extensions used in the Registration Reply message are, * User-NAI Extension * SMM-Key Extension (Optional) * MN-Home Authentication Extension * Local Registration Lifetime Extension (Optional) " SMM-NAI Extension (Optional) * MN-SMM Authentication Extension (Optional) e ANI-SMM Authentication Extension (Optional) Page 22 of 138 WO 01/19050 PCT/IBOO/01553 226 and can be explained further in the Extension Section 4. Page 23 of 138 WO 01/19050 PCT/IBOO/01553 227 2.2 IPM MN REGISTERS FROM IPM NSF IPM NSF MN [jNI AAA I MM ITS ISC IHC IDNS . .ent So.citatton- - -. - -- - - -- .---------.

.............

a Agent Advertisement b Registration Request (Init. Reg.) Reg station Req -est (Init. e )d etvice Req iest ................................. e.................... ..... . . . . . .. Res nse. Optionally locate M 's IP Addr s from D} CP and Update DDNS iftn cessary Registrar on Reply Registration Reply IPM MN registers from IPM NSF 2.2.1 Agent Discovery Process See Section 2.1.1 2.2.1.1 Agent Solicitation and Message Format See Section 2.1.1.1 2.2.1.2 Agent Advertisement and Message Format See Section 2.1.1.2 2.2.2 Registration Process See Section 2.1.2 2.2.2.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.2.2.2 Service Request and Message Format See Section 2.1.2.3 2.2.2.3 Service Reply and Message Format Page 24 of 138 WO 01/19050 PCT/IBOO/01553 228 See Section 2.1.2.4 2.2.2.4 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. Page 25 of 138 WO 01/19050 PCT/IBOO/01553 229 2.3 IPM MN DISCONNECT DETECTION M LSF NSF MN ANI ITS SMM S-AAA H- HMM ITS SC DHCP Regis aton Re ue (LocalR - ;.) .R ... *.................... ................ ..... ..... ~.. . IPM MN Disconnect Detection 2.3.1 Registration Process See Section 2.1.2 2.3.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the ANI when it detects a disconnect. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the ANI. The exception of the Extensions used in the Registration Request is, e MN-Home Authentication Extension (Optional) 2.3.1.2 Registration Reply and Message Format The Registration Reply message is sent by the ANI to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the ANI and the IPM MN. The exception of the Extensions used in the Registration Reply is, e MN-Home Authentication Extension (Optional) Page 26 of 138 WO 01/19050 PCT/IB00/01553 230 2.4 IPM MN RE-REGISTERS FROM IPM LSF LSF NSF S A TS MM S-AAA I Regis action R et (Re-regisi ation) Re station Re auest (Re re dstration) ..... ...- ................. ............. ... .. ...... ........ .. ... . . ...... .................. ........... .. .............. .... ........ . . . . . .. b AA . Regisrati Request d AAA Regisgratan .n..... ... Rep y.. .. Regisr tioueept AAA . ... .. ................. . ... ........ service Req fest ...... .................................. .................. ......... .... . . . .-.. . ....................................... .. . e .. eR .n .g................. .......... | ptionally r new MN lP Addre s AAA stratio) epily AAA Registration Reply R tration Rtpy tration~ ~ R. .... . . . . . .. . . . . . .. .... IPM MN re-registers from IPM LSF 2.4.1 Registration Process See Section 2.1.2 2.4.1.1 Registration Request and Message Format See Section 2.1.2.1 2.4.1.2 AAA-Registration Request and Message Format See Section 2.1.2.2 2.4.1.3 Service Request and Message Format See Section 2.1.2.3 2.4.1.4 Service Reply and Message Format See Section 2.1.2.4 2.4.1.5 AAA-Registration Reply and Message Format See Section 2.1.2.7 2.4.1.6 Registration Reply and Message Format See Section 2.1.2.10 Page 27 of 138 WO 01/19050 PCT/IBOO/01553 231 2.5 IPM MN RE-REGISTERS FROM IPM NSF IPM NSF MN N AAA MM IS CP DNS Registration Request (Re-registration) Reg strationReq res (Re reraion)b service Reqest C e ce Resy onse OP onally rene MN's IP ddress wii D~ P Registrar on Reply Registraion Reply IPM MN re-registers from IPM NSF 2.5.1 Registration Process See Section 2.1.2 2.5.1.1 Registration Request and Message Format The Registration Request message is sent from the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.5.1.2 Service Request and Message Format See Section 2.1.2.3 2.5.1.3 Service Reply and Message Format See Section 2.1.2.4 2.5.1.4 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. Page 28 of 138 WO 01/19050 PCT/IBOO/01553 232 2.6 IPM MN DE-REGISTERS FROM IPM LSF LSF NSF M ANI ITS SMM SAAA H- HMM ITS SC DHCP Regis tonRe t (De-egis action) Regis ation Requ st (De-r t action) AAA egisstrto equeRse AAA Registration Request d AAA egse ReR ........ ................. ................ .... ..... ......... I....... .................................................... u................................................ ........ ......... e ServiceR e S -.. ... ... ... ... Service Re nse . Optiona iy release INos IP A Jrss to COIP ........ ............. . .. . . . ... .................. ......... . .... I............... . . ...... ........ De 5n !................. - ................ ........ ... ........... . ............ I....... Del M Tunel T Cy A Hk ...... ..... .... .... ... .. .... .................... ....... . . . . . . . . ........... ............... .... ... ..... ................ ... ........ . ............... .... . ..... ............... . . .... .................. ..................... ......... . . . . . . . . . ... . . . .A............. ........................................................................ ...-- 1 1.......- ..... ... AAAA Registraeon Reply Reriice ReplyRe t etc Taose Exsit ~ .. .... .......... ........ - .... .............. ......................................- . ............. ................................ ............. .. ........... ..... Dee it Ack ................... I....... - ..... ......... ... ....... ...... ...... ...................... ..................................................................................................... .SrtvRion Replyi .................. i .. ............ ............... .............. . ...... _ ............. ............... ...... ........ ....... .. q yPM MN de-registers from rPM LSF 2.6.1 Registration Process See Section 2.1.2 2.6.1.1 Registration Request and Message Format See Section 2.1.2.1 2.6.1.2 AAA-Registration Request and Message Format See Section 2.1.2.2 2.6.1.3 Service Request and Message Format See Section 2.1.2.3 2.6.1.4 Service Reply and Message Format See Section 2.1.2.4 2.6.1.5 Delete Tunnel Entry and Message Format Page 29 of 138 WO 01/19050 PCT/IBOO/01553 233 The Delete Tunnel Entry message is sent by the HMM to instruct the ITS to delete a tunnel entry point. The message format exchanged between the HMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... * Code - 7, for Delete Tunnel Entry message. * Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Entry message are, * Host NAI Extension e Mobile Node IP Address Extension 0 User NAI Extension (Optional) and can be explained further in the Extension Section 4. 2.6.1.6 Delete Tunnel Entry Acknowledgement and Message Format The Delete Tunnel Entry Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Entry message. The identification field should be used for matching with the Delete Tunnel Entry message. The message format exchanged between the ITS and the HMM is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 8, for Delete Tunnel Entry Acknowledgement message. " Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Entry Acknowledgement message are, Page 30 of 138 WO 01/19050 PCT/IBOO/01553 234 e Host NAI Extension e Result Code Extension * Mobile Node IP Address Extension (Optional) * User NAI Extension (Optional) and can be explained further in the Extension Section 4. 2.6.1.7 AAA-Registration Reply and Message Format See Section 2.1.2.7 2.6.1.8 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the SMM to instruct the ITS to delete a tunnel exit point. The message format exchanged between the SMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 9, for Delete Tunnel Exit message. " Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Exit message are, * Host NAI Extension * Mobile Node IP Address Extension (Optional) * User NAI Extension (Optional) * Tunnel Exit IP Address Extension and can be explained further in the Extension Section 4. 2.6.1.9 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. The message format exchanged between the ITS and the SMM is as follows: Code (16) Message Length (16) Page 31 of 138 WO 01/19050 PCT/IBOO/01553 235 Identification (64) Extensions... * Code - 10, for Delete Tunnel Exit Acknowledgement message. * Message Length - Length of the message including the header fields. * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Exit Acknowledgement message are, * Host NAI Extension " Result Code Extension * Mobile Node IP Address Extension (Optional) " User NAI Extension (Optional) and can be explained further in the Extension Section 4. 2.6.1.10 Registration Reply and Message Format See Section 2.1.2.10 Page 32 of 138 WO 01/19050 PCT/IBOO/01553 236 2.7 IPM MN DE-REGISTERS FROM IPM NSF NSF MN LANIAAA MM S SC CP DNS RegistraRtion Requet (De-regestr a- r T - ~ervice Reeta , Registrat on ... e Registration Reply 1PM MN de-registers from 1PM NSF 2.7.1 Registration Process See Section 2.1.2 2.7.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.7.1.2 Service Request and Message Format See Section 2.1.2.3 2.7.1.3 Service Reply and Message Format See Section 2.1.2.4 2.7.1.4 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. Page 33 of 138 WO 01/19050 PCT/IBOO/01553 237 2.8 IPM MN HANDOFFS FROM ANI TO ANI IN THE SAME SMM (DIFFERENT ITS) pmLSF NSF N ANI ITS ANIN ITS SMM 1 AAA HAAA MM ITS HCP Registration Request (A U Chan Regi ration Re guest (AN range) AAA Regi ation Re t (AN! Change) SMM Aut 1entication Ad anel Exi T nel Fora ding AAA RegRstration Request A T u n n el. . t A c k........ . . . . . . . . . . ...... ...... . . Tunnel FomrijAk 1. AAA Re istration Rei uest HMN Authentic ition Ad Tunnieln Add 'unne Ent Ark. ...... ....... ............. ............ ...................... .... ........... ....... I................. ........... ............................ .............. ... ..... AAA istration teply AAA Registration Reply.......................... .. . ........ AA .. Reply............................statin.. Delete tunnell Exi Delete Ta mel Exit A k Reg._ egistrat n Reply IPM MN handoffs from ANI to ANI in the same SMM (different ITS) 2.8.1 Registration Process See Section 2.1.2 2.8.1.1 Registration Request and Message Format See Section 2.1.2.1 2.8.1.2 AAA-Registration Request and Message Format See Section 2.1.2.2 2.8.1.3 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the SMM to instruct the ITSN to set up a tunnel exit point. See Section 2.1.2.8 for the message format exchanged between the SMM and the ITSN. 2.8.1.4 Tunnel Forwarding and Message Format Page 34 of 138 WO 01/19050 PCT/IBOO/01553 238 The Tunnel Forwarding message is sent by the SMM to instruct the ITSO to set up a tunnel forwarding. The message format exchanged between the SMM and the ITSO is as follows: Code (16) Message Length (16) Identification (64) Extensions... * Code - 5, for Tunnel Forwarding message. * Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Tunnel Forwarding message are, e Host NAI Extension e Mobile Node IP Address Extension " User NAI Extension (Optional) e Lifetime Extension * Tunnel Exit IP Address Extension and can be explained further in the Extension Section 4. 2.8.1.5 Add Tunnel Exit Acknowledgement and Message Format The Add Tunnel Exit Acknowledgement message is sent by the ITSN to acknowledge the Add Tunnel Exit message. See Section 2.1.2.9 for the message format exchanged between the ITSN and the SMM. 2.8.1.6 Tunnel Forwarding Acknowledgement and Message Format The Tunnel Forwarding Acknowledgement message is sent by the ITSO to acknowledge the Tunnel Forwarding message. The identification field should be used for matching with the Tunnel Forwarding message. The message format exchanged between the ITSO and the SMM is as follows: Code (16) Message Length (16) Page 35 of 138 WO 01/19050 PCT/IBOO/01553 239 Identification (64) Extensions... " Code - 6, for Tunnel Forwarding Acknowledgement message. * Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Tunnel Forwarding message are, " Host NAI Extension " Mobile Node IP Address Extension " User NAI Extension (Optional) * Result Code Extension and can be explained further in the Extension Section 4. 2.8.1.7 Add Tunnel Entry and Message Format See Section 2.1.2.5 2.8.1.8 Add Tunnel Entry Acknowledgement and Message Format See Section 2.1.2.6 2.8.1.9 AAA-Registration Reply and Message Format See Section 2.1.2.7 2.8.1.10 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the SMM to instruct the ITSO to delete a tunnel exit point. See Section 2.6.1.8 for the message format exchanged between the SMM and the ITSO. 2.8.1.11 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITSO to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. Page 36 of 138 WO 01/19050 PCT/IB00/01553 240 See Section 2.6.1.9 for the message format exchanged between the ITSO and the SMM. 2.8.1.12 Registration Reply and Message Format See Section 2.1.2.10 Page 37 of 138 WO 01/19050 PCT/IBOO/01553 241 2.9 IPM MN HANDOFFS FROM ANI TO ANI IN THE SAME SMM (SAME ITS) LSF NSF N ANI ITS ANIN SMM S-AAA H-AAA MM ITS ISC CP Registration Request (A l a .............. . .... C .......... ......... ....... ........... ......... I . ... ......... . . . .... . . ......................................... .... .I........ ....... . ........... ............ I .d.... . AAA Registration Requst U date Location) AAA Registration Request AAA1 egistration F quest AA kgegistratioi Reply ........... ~~~~~~~ ~ ~ ~ ~ ~ ~ ~ ..... ........................................................... I................................................................................. .............. . h..... 1 4 AAA Registration Reply ....... .... i ten...... ion... ..... ..... .................... . . ..... .. k R. g tration Rly R gstration ply IPM MN handoffs from ANI to ANI in the same SMM (same ITS) 2.9.1 Registration Process See Section 2.1.2 2.9.1.1 Registration Request and Message Format See Section 2.1.2.1 2.9.1.2 AAA-Registration Request and Message Format See Section 2.1.2.2 2.9.1.3 AAA-Registration Reply and Message Format See Section 2.1.2.7 2.9.1.4 Registration Reply and Message Format See Section 2.1.2.10 Page 38 of 138 WO 01/19050 PCT/IBOO/01553 242 2.10 IPM MN HANDOFFS FROM SMM TO SMM INew LSF Old LSF INSF N I TS S IM TAA ANI ITS S M S-AAA [ H-AAA M I S 2 C HCP Rei ~ u tSytm hanged) --.- a Registrati - e.-

..

AAA R ont Request -- -- AA C e est AAA R, gistration equest AAA Cont xt Reques AAA eg F request AA unetR est A - -..... -Service Re uest .. . . . . . . . . . . . . .. . . . . ......... z ... , ............................ ............ ............... f IMAuthe tication AAj C eponse Fo rd Data ection SM"Rve posse AAACont .Respons. ..... - ...... . . . ...... ..............- ....... h AA/dponselntry Ack Add I >bile NodE Section ---- ------- *------- AAA es Rt ply SRegistrati Reply AA/ Binding U date -- - - -- -AA datea Delete obile Nod ) Section AAA E nd e Response AAA I nding Upd te Respon IPM MN handoffs from SMM to SMM 2.10.1 Registration Process See Section 2.1.2 2.10.1.1 Registration Request and Message Format See Section 2.1.2.1 2.10.1.2 AAA-Registration Request and Message Format See Section 2.1.2.2 2.10.1.3 AAA-Context Request and Message Format The AAA-Context-Request message is sent by the current SMM of the User to the previous SMM to request the Context-Data of the User's session. The message format exchanged between the current SMM and the previous SMM is as follows: Page 39 of 138 WO 01/19050 PCT/IBOO/01553 243 AAA-Context-Request <DIAMETER Header> <Command-Code AVP = 339> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <IPM-Context-Request-Type AVP> <IPM-Care-of-Address AVP> The AAA-Context-Request message is of the format of DIAMETER. The current SMM of the MN sends this message to previous SMM, to request for the context of the user's data and also to request to forward the data to the current COA. The current SMM sends the IPM-Registration-Request AVP that encapsulates the incoming IPM-Registration-Request message for the previous SMM to authenticate before forwarding the data. The IPM-Context-Request-Type AVP informs the previous SMM what kind of action is requested. The AVPs that can optionally be used in the AAA-Context-Request message are, e IPM-Registration-Request AVP e IPM-SMM-NAI AVP * Proxy-State AVP * Time AVP e Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. 2.10.1.4 Service Request and Message Format See Section 2.1.2.3 2.10.1.5 AAA-Context Response and Message Format The AAA-Context-Response message is sent by previous SMM of the User to the current SMM in response to the AAA-Context-Request message. The message format exchanged between the previous SMM and the current SMM is as follows: AAA-Context-Response <DIAMETER Header> <Command-Code AVP = 340> <Destination-NAI AVP> <Host-Name AVP> Page 40 of 138 WO 01/19050 PCT/IBOO/01553 244 <User-Name AVP> <Result-Code AVP> The AAA-Context-Response message is of the format of DIAMETER. The previous SMM of the MN sends this message to current SMM, to response to the AAA-Context-Request message. The successful message must have IPM-Context Data AVP in the message. The AVPs that can optionally be used in the AAA-Context-Response message are, " IPM-Context-Data AVP " Proxy-State AVP e Time AVP e Nonce AVP e Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. 2.10.1.6 Service Response and Message Format See Section 2.1.2.4 2.10.1.7 Add Tunnel Entry and Message Format See Section 2.1.2.5 2.10.1.8 Add Tunnel Entry Acknowledgement and Message Format See Section 2.1.2.6 2.10.1.9 AAA-Registration Reply and Message Format See Section 2.1.2.7 2.10.1.10 Registration Reply and Message Format See Section 2.1.2.10 2.10.1.11 AAA-Binding-Update Request and Message Format The AAA-Binding-Update Request message is sent by the current SMM of the User to the previous SMM to complete the hand-off of the User's session. The message format exchanged between the current SMM and the previous SMM is as follows: Page 41 of 138 WO 01/19050 PCT/IBOO/01553 245 AAA-Binding-Update Request <DIAMETER Header> <Command-Code AVP = 341> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <IPM-Client-Address AVP> <IPM-Care-of-Address AVP> The AAA-Binding-Update Request message is of the format of DIAMETER. The current SMM of the MN sends this message to the previous SMM, to complete the hand-off of the User's session and clean up of the resources that are allocated for the user. The AVPs that can optionally be used in the AAA-Binding-Update Request message are, * IPM-SMM-NAI AVP e Proxy-State AVP * Time AVP e Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. 2.10.1.12 AAA-Binding Update Response and Message Format The AAA-Binding-Update Response message is sent by the previous SMM of the User to the current SMM in response to the AAA-Binding-Update Request message. The message format exchanged between the previous SMM and the current SMM is as follows: AAA-Binding-Update Response <DIAMETER Header> <Command-Code AVP = 342> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <Result-Code AVP> The AAA-Binding-Update Response message is of the format of DIAMETER. The previous SMM of the MN sends this message to the current SMM, in response to the AAA-Binding-Update Request message. The successful message completes the hand-off of the MN from SMM to SMM. The AVPs that can optionally be used in the AAA-Binding-Update Response message are, Page 42 of 138 WO 01/19050 PCT/IBOO/01553 246 e Proxy-State AVP * Time AVP " Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. Page 43 of 138 WO 01/19050 PCT/IBOO/01553 247 2.11 IPM MN HANDOFFS LSF TO NSF (HOME ANI) LSF NSF M ANI ITS SMM S-AAA AN A MM SH I SC HCP egistration. equest (Sy tem Change) egntstrton R quest (Syste Change) Service Rey uest vieR:ponse De etTunl :ntryAck Riton Replyg A A Rett-t on Cancelle ton Registra ott Reply h AAA Registeation Cancellation AAA Regstrtio Cancellation. . . . Delete Ilobile Nod) Section AAA Regi t n C lation Ack AAA Registtation Cancellation Ack AAA Regi tation c elation Ack IPM MN handoffs from LSF to NSF (Home ANI) 2.11.1 Registration Process See Section 2.1.2 2.11.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.11.1.2 Service Request and Message Format See Section 2.1.2.3 2.11.1.3 Service Reply and Message Format See Section 2.1.2.4 2.11.1.4 Delete Tunnel Entry and Message Format The Delete Tunnel Entry message is sent by the HMM to instruct the ITSH to delete a tunnel entry point. See Section 2.6.1.5 for the message format exchanged between the HMM and the ITSH. Page 44 of 138 WO 01/19050 PCT/IBOO/01553 248 2.11.1.5 Delete Tunnel Entry Acknowledgement and Message Format The Delete Tunnel Entry Acknowledgement message is sent by the ITSH to acknowledge the Delete Tunnel Entry message. The identification field should be used for matching with the Delete Tunnel Entry message. See Section 2.6.1.6 2.11.1.6 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. 2.11.1.7 AAA-Registration Cancellation and Message Format The AAA-Registration Cancellation message is sent by the HMM to the SMM to cancel the existing User's registration at the visiting system. AAA-Registration Cancellation <DIAMETER Header> <Command-Code AVP = 337> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <IPM-Registration-Cancellation-Reason AVP> The AAA-Registration Cancellation message is of the format of DIAMETER. The HMM sends the message to the SMM with at least the mandatory fields to cancel the registration of the user. The IPM-Registration-Cancellation-Reason AVP indicates the reason for the cancellation of the registration. The AVPs that can optionally be used in the AAA-Registration Cancellation message are, " IPM-Client-Address AVP " Proxy-State AVP * Time AVP " Nonce AVP * Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. 2.11.1.8 AAA-Registration Cancellation Acknowledgement and Message Format Page 45 of 138 WO 01/19050 PCT/IBOO/01553 249 The AAA-Registration Cancellation Acknowledgement message is sent by the SMM to acknowledge the AAA-Registration Cancellation message. The message format exchanged between the SMM and the HMM is as follows: AAA-Registration Cancellation <DIAMETER Header> Acknowledgement <Command-Code AVP = 338> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <Result-Code AVP> The AAA-Registration Cancellation Acknowledgement message is of the format of DIAMETER. The SMM sends the message to the HMM with at least the mandatory fields. The Response-Code AVP indicates the failure or success of the AAA-Registration Cancellation message. The AVPs that can optionally be used in the AAA-Registration Cancellation Acknowledgement message are, " Proxy-State AVP * Time AVP " Nonce AVP e Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. Page 46 of 138 WO 01/19050 PCT/IB00/01553 250 2.12 IPM MN HANDOFFS NSF (HOME ANI) TO LSF I LSF. NSF N AN TIS M M AA A ANIH HAAA M M ISH SC DCP Regi nRe st (System :hange) Regi ration Req est (Syst Change) ................ ...... . .I........... ...... . . .......... ....... ... . .... -... -.. .... . . . . ............. ............. .......... ............. ... ...... ........ b. ...... AAA Request AAA Registration Request 1 d AAA egisr eqop uest ................ ............................................................................................................ ......... . . . . . . . . . . . . . . . . .fIP 11 1111 1,1-1 - 1--,,--*,11 Serice Ret uestf Sice Re ponse .. .... ........ ......... .... .... ......... ...... . ........................... .......... ................. ............... ....... I.............. ......................... ......... . . . ..... It .- ~Add Tun Entryh AAA Ie r ply .................... . .AAA Registration Reply i.dTunex t . . .. m A d .it.Ack - Re ;istration R ply gistration R p y R IPM MN handoffs from NSF (Home ANI) to LSF 2.12.1 Registration Process See Section 2.1.2 2.12.1.1 Registration Request and Message Format See Section 2.1.2.1 2.12.1.2 AAA-Registration Request and Message Format See Section 2.1.2.2 2.12.1.3 Service Request and Message Format See Section 2.1.2.3 2.12.1.4 Service Reply and Message Format See Section 2.1.2.4 2.12.1.5 Add Tunnel Entry and Message Format The Add Tunnel Entry message is sent by the HMM to instruct the ITSH to set up a tunnel entry point. See Section 2.1.2.5 for the message format exchanged between the HMM and the ITSH. Page 47 of 138 WO 01/19050 PCT/IBOO/01553 251 2.12.1.6 Add Tunnel Entry Acknowledgement and Message Format The Add Tunnel Entry Acknowledgement message is sent by the ITSH to acknowledge the Add Tunnel Entry message. See Section 2.1.2.6 for the message format exchanged between the ITSH and the HMM. 2.12.1.7 AAA-Registration Reply and Message Format See Section 2.1.2.7 2.12.1.8 Add Tunnel Exit and Message Format See Section 2.1.2.8 2.12.1.9 Add Tunnel Exit Acknowledgement and Message Format See Section 2.1.2.9 2.12.1.10 Registration Reply and Message Format See Section 2.1.2.10 Page 48 of 138 WO 01/19050 PCT/IBOO/01553 252 2.13 IPM MN HANDOFFS FROM LSF TO NSF (FOREIGN ANI) LSF NSF I7] I NSTMM1 1 I -A MN AN TSAMIAAIN TSF AA A M IVM STH C DCP tegistrattonRReques (Syse Change) ....... .......... ... .. .... . . . . ..... ba ................................................................. .ServiceR R est SveRe ...... ponse ........... ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ d T..... .......... Exi.........t.. ............. .....................-. ........................... .............................. ........ ............... ............ ..... e.. Add T nnel Exit A~d TunLttry Add Tunnel Exit Ack Registra ion ReplyAd i ry Ack ..................... ............. ............ ......................... .......... ................. ........................... . . . . 4.......................................g... ....... A AARegistra aonn Canceln aon ...- - --.. ......- ..................... .............................. .. . .. ... .........h AAA Registration C cellationI AAA~ R~iraion Canicellation, Delete Ilobile Nod Section AAA Regi traction C tilation Ack AAA Registration Cance lation Ack -"' I ~~~~.... ......... ..........F........... ... ... . ......... 1................ ...... 0........... ................ -AAA Regi :tato C cIlation Ack IPM MN handoffs from LSF to NSF (Foreign ANI) 2.13.1 Registration Process See Section 2.1.2 2.13.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.13.1.2 Service Request and Message Format See Section 2.1.2.3 2.13.1.3 Service Reply and Message Format See Section 2.1.2.4 2.13.1.4 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the HMM to instruct the ITSF to set up a tunnel exit point. See Section 2.1.2.8 for the message format exchanged between the HMM and the ITSF. Page 49 of 138 WO 01/19050 PCT/IBOO/01553 253 2.13.1.5 Add Tunnel Entry and Message Format The Add Tunnel Entry message is sent by the HMM to instruct the ITSH to set up a tunnel entry point. See Section 2.1.2.5 for the message format exchanged between the HMM and the ITSH. 2.13.1.6 Add Tunnel Exit Acknowledgement and Message Format The Add Tunnel Exit Acknowledgement message is sent by the ITSF to acknowledge the Add Tunnel Exit message. See Section 2.1.2.9 for the message format exchanged between the ITSF and the HMM. 2.13.1.7 Add Tunnel Entry Acknowledgement and Message Format The Add Tunnel Entry Acknowledgement message is sent by the ITSH to acknowledge the Add Tunnel Entry message. See Section 2.1.2.6 for the message format exchanged between the ITSH and the HMM. 2.13.1.8 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. 2.13.1.9 AAA Registration Cancellation and Message Format See Section 2.11.1.7 2.13.1.10 AAA Registration Cancellation Acknowledgement and Message Format See Section 2.11.1.8 Page 50 of 138 WO 01/19050 PCT/IBOO/01553 254 2.14 IPM MN HANDOFFS FROM NSF (FOREIGN ANI) TO LSF I LSF NSF S NI ITS SMM S-AAA AN TSF -AA MM SH SC HCP Regi ration Reu st (System hang) Regi ration Req est (Syste Change) AA Regstrati Reqest AAA Registration Re uest AAA egt Foequest SeviceRest ....... f S Nice. Re os Delete T, cccl Exit Add Tj cl Entiy Ack Delete Taco I Exit Ack ... AAA RegistAatiAA eply I AAi el ...... ............. ............. - A...... ........................... ....... I............I........... . . . . . ........................ ............ ................. . . .... . A dfaa itxAck Re :istration R ply R gistrationR R .. .......... I ...................

p IPM MN handoffs from NSF (Foreign ANI) to LSF 2.14.1 Registration Process See Section 2.1.2 2.14.1.1 Registration Request and Message Format See Section 2.1.2.1 2.14.1.2 AAA Registration Request and Message Format See Section 2.1.2.2 2.14.1.3 Service Request and Message Format See Section 2.1.2.3 2.14.1.4 Service Reply and Message Format See Section 2.1.2.4 2.14.1.5 Add Tunnel Entry and Message Format The Add Tunnel Entry message is sent by the HMM to instruct the ITSH to set up a tunnel entry point. See Section 2.1.2.5 for the message format exchanged between the HMM and the ITSH. Page 51 of 138 WO 01/19050 PCT/IBOO/01553 255 2.14.1.6 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the HMM to instruct the ITSF to delete a tunnel exit point. See Section 2.6.1.8 for the message format exchanged between the HMM and the ITSF. 2.14.1.7 Add Tunnel Entry Acknowledgement and Message Format The Add Tunnel Entry Acknowledgement message is sent by the ITSH to acknowledge the Add Tunnel Entry message. See Section 2.1.2.6 for the message format exchanged between the ITSH and the HMM. 2.14.1.8 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITSF to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. See Section 2.6.1.9 for the message format exchanged between the ITSF and the HMM. 2.14.1.9 AAA Registration Reply and Message Format See Section 2.1.2.7 2.14.1.10 Add Tunnel Exit and Message Format See Section 2.1.2.8 2.14.1.11 Add Tunnel Exit Acknowledgement and Message Format See Section 2.1.1.9 2.14.1.12 Registration Reply and Message Format See Section 2.1.2.10 Page 52 of 138 WO 01/19050 PCT/IBOO/01553 256 2.15 IPM MN HANDOFFS FROM FOREIGN ANI TO FOREIGN ANI IN THE SAME NSF NSF Reisraio Rqes (N]CANg) IN TN N A1 1 TSO AAA. HMM ITSH I SC CP Registration Request (A I Change) HtMMAuientication Add Tur nel Exit - - - - - - - Add Tunn A Exit Ack d A d unnel Ent yAc Reeistrati> Repl Registration Reply h IPM MN handoffs from foreign ANI to foreign ANI in the same NSF 2.15.1 Registration Process See Section 2.1.2 2.15.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.15.1.2 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the HMM to instruct the ITSN to set up a tunnel exit point. See Section 2.1.2.8 for the message format exchanged between the HMM and the ITSN. 2.15.1.3 Tunnel Forwarding and Message Format Page 53 of 138 WO 01/19050 PCT/IBOO/01553 257 The Tunnel Forwarding message is sent by the HMM to instruct the ITSO to set up a tunnel forwarding. See Section 2.8.1.4 for the message format exchanged between the HMM and the ITSO. 2.15.1.4 Service Request and Message Format See Section 2.1.2.3 2.15.1.5 Add Tunnel Exit Acknowledgement and Message Format The Add Tunnel Exit Acknowledgement message is sent by the ITSN to acknowledge the Add Tunnel Exit message. See Section 2.1.2.9 for the message format exchanged between the ITSN and the HMM. 2.15.1.6 Tunnel Forwarding Acknowledgement and Message Format The Tunnel Forwarding Acknowledgement message is sent by the ITSO to acknowledge the Tunnel Forwarding message. The identification field should be used for matching with the Tunnel Forwarding message. See Section 2.8.1.6 for the message format exchanged between the ITSO and the HMM. 2.15.1.7 Service Reply and Message Format See Section 2.1.2.4 2.15.1.8 Add Tunnel Entry and Message Format The Add Tunnel Entry message is sent by the HMM to instruct the ITSH to set up a tunnel entry point. See Section 2.1.2.5 for the message format exchanged between the HMM and the ITSH. 2.15.1.9 Add Tunnel Entry Acknowledgement and Message Format The Add Tunnel Entry Acknowledgement message is sent by the ITSH to acknowledge the Add Tunnel Entry message. See Section 2.1.2.6 for the message format exchanged between the ITSH and the HMM. Page 54 of 138 WO 01/19050 PCT/IBOO/01553 258 2.15.1.10 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. 2.15.1.11 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the HMM to instruct the ITSO to delete a tunnel exit point. See Section 2.6.1.8 for the message format exchanged between the HMM and the ITSO. 2.15.1.12 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITSO to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. See Section 2.6.1.9 for the message format exchanged between the ITSO and the HMM. Page 55 of 138 WO 01/19050 PCT/IBOO/01553 259 2.16 IPM MN HANDOFFS FROM HOME ANI TO FOREIGN ANI IN THE SAME NSF NSF AN ITSF ANI ITSHIH AA I MM SC IHCP Registration Request (ANI Change) Registratis Request (A Il Change)b .......................... ....... .................................. ................... . ..

equest ......................................... ............. .. c...... Service e aest Sevce ntse. d Add Ta tel Entry AddT elErt Add Taaae !=L4~ Add Taaa, I Exit Ack ....................... t.......................... . .ratio el.................f Registration Reply ........ ............. .......... ..................... I............................................................. ..................... ............................... .......................... ............... ......... .... h ...... ..................................................... ...................................... .. I......... .......................................... ............... .... J ..... ............ ....... IPM MN handoffs from home ANI to foreign ANI in the same NSF 2.16.1 Registration Process See Section 2.1.2 2.16.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.16.1.2 Service Request and Message Format See Section 2.1.2.3 2.16.1.3 Service Reply and Message Format See Section 2.1.2.4 2.16.1.4 Add Tunnel Entry and Message Format The Add Tunnel Entry message is sent by the HMM to instruct the ITSH to set up a tunnel entry point. See Section 2.1.2.5 for the message format exchanged between the HMM and the ITSH. Page 56 of 138 WO 01/19050 PCT/IB00/01553 260 2.16.1.5 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the HMM to instruct the ITSF to set up a tunnel exit point. See Section 2.1.2.8 for the message format exchanged between the HMM and the ITSF. 2.16.1.6 Add Tunnel Entry Acknowledgement and Message Format The Add Tunnel Entry Acknowledgement message is sent by the ITSH to acknowledge the Add Tunnel Entry message. See Section 2.1.2.6 for the message format exchanged between the ITSH and the HMM. 2.16.1.7 Add Tunnel Exit Acknowledgement and Message Format The Add Tunnel Exit Acknowledgment message is sent by the ITSF to acknowledge the Add Tunnel Exit message. See Section 2.1.2.9 for the message format exchanged between the ITSF and the HMM. 2.16.1.8 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. Page 57 of 138 WO 01/19050 PCT/IBOO/01553 261 2.17 IPM MN HANDOFFS FROM FOREIGN ANI TO HOME ANI IN THE SAME NSF NSF AN SF NIH SH AAA MM SC CP Registration Request (ANI Change) Registration ttuest (Aa I .Change 5SrviceRe t Delete T .nn Entry umlteT el~ delete Tur el Ent24 Delete Ta i Exit Ac ........... ................... I .............................. ~~~~~~~~~~....... 1 1...........I............................................................... .. . ....... I........... e i t io p y. .................... ... ....... Registration Reply IPM MN handoffs from foreign ANI to home ANI in the same NSF 2.17.1 Registration Process See Section 2.1.2 2.17.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. See Section 2.1.2.1 for the message format exchanged between the IPM MN and the HMM. 2.17.1.2 Service Request and Message Format See Section 2.1.2.3 2.17.1.3 Service Reply and Message Format See Section 2.1.2.4 2.17.1.4 Delete Tunnel Entry and Message Format The Delete Tunnel Entry message is sent by the HMM to instruct the ITSH to delete a tunnel entry point. See Section 2.6.1.5 for the message format exchanged between the HMM and the ITSH. Page 58 of 138 WO 01/19050 PCT/IBOO/01553 262 2.17.1.5 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the HMM to instruct the ITSF to delete a tunnel exit point. See Section 2.6.1.8 for the message format exchanged between the HMM and the ITSF. 2.17.1.6 Delete Tunnel Entry Acknowledgement and Message Format The Delete Tunnel Entry Acknowledgement message is sent by the ITSH to acknowledge the Delete Tunnel Entry message. See Section 2.6.1.6 for the message format exchanged between the ITSH and the HMM. 2.17.1.7 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITSF to acknowledge the Delete Tunnel Exit message. See Section 2.6.1.9 for the message format exchanged between the HMM and the ITSF. 2.17.1.8 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 2.1.2.10 for the message format exchanged between the HMM and the IPM MN. Page 59 of 138 WO 01/19050 PCT/IBOO/01553 263 3. INTERWORKING MESSAGE FLOWS IPM-MIP 3.1 IPM MN REGISTERS FROM MIP FA NSF MN MIP FA I ITSI SCI2HCP DNS Agent Soliitation .enpvetisemen t -.. b Registration Request t Reg.) Registration Request (Init. Reg.) d service Req est e Optionally allocate M 's IP Addr from DI CP and Update DDNS if n cessary .. .... .... .d .tr ...... ......... .. ...................... Ac unnelE y Ack h Rgtaon R )ly Registration RReply Registration Reply IPM MN registers from MIP FA 3.1.1 Agent Discovery Process Agent Discovery is the method by which a Mobile Node (MN) determines whether it is currently connected to its home network or to a foreign network, and by which a MN can detect when it has moved from one network to another. Home agents and foreign agents may advertise their availability on each link for which they provide service. A newly arrived MN can send a solicitation on the link to learn if any prospective agents are present. The Agent Discovery Process is primarily handled through Agent Solicitation and Agent Advertisement. 3.1.1.1 Agent Solicitation and Message Format Agent Solicitation is the broadcast/multicast message sent by the IPM MN to detect a Service Provider in the event that the IPM MN has not received an Advertising Agent message. The message format exchanged between the IPM MN and the MIP FA is as follows: Type Code Checksum Reserved Page 60 of 138 WO 01/19050 PCT/IBOO/01553 264 e Source Address - An Mobile IP address belonging to the interface from which this message is sent, or 0. This is part of the standard heading. " Destination Address - The configured Solicitation Address. This is part of the standard heading. * Type - 10 * Code -0 " Checksum - The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0. * Reserved - Sent as 0; ignored on reception. There are no Extensions for Agent Solicitation. 3.1.1.2 Agent Advertisement and Message Format Agent Advertisement are messages sent periodically, either as a broadcast or multicast for the visiting IPM MN to recognize the availability of service and to keep track of their point of attachment. The message format exchanged between the MIP FA and the IPM MN is as follows: Type Code Checksum Num Addrs Addr Entry Size Lifetime Router Address [1] Preference Level [1] Router Address [2] Preference Level [2] " Source Address - An IP address belonging to the interface from which this message is sent. This is part of the of the standard heading. " Destination Address - The configured Advertisement Address or the IP address of a neighboring host. This is part of the of the standard heading. * Type-9 * Code -0 " Checksum - The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0. " Num Addrs - The number of router addresses advertised in this message. " Addr Entry Size - The number of 32-bit words of information per each router address (2, in the version of the protocol described here). " Lifetime - The maximum number of seconds that the router addresses may be considered valid. Page 61 of 138 WO 01/19050 PCT/IBOO/01553 265 * Router Address [i], i = 1..Num Addrs - The sending router's IP address(es) on the interface from which this message is sent. * Preference Level [i], i = 1..Num Addrs - The preferability of each router address [i] as a default router address, relative to other router addresses on the same subnet. A signed, two-complement value; higher values mean more preferable. The Extensions that can be used in Agent Advertisement message are, " Mobility Agent Advertisement Extension * Prefix-Lengths Extension (Optional) " One-Byte Padding Extension (Optional) and can be explained further in the Extension Section 4. 3.1.2 Registration Process The purpose of registration is for the IPM MN to inform the HMM of the NSF (Network Serving Function) of its current location to which data packets can be forwarded to the IPM MN. The Registration process also includes the authenticating and authorizing of the MIP MN to have access to the visited network or LSF (Local Serving Function). 3.1.2.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the HMM to register for the service. The Registration process also includes the authenticating and authorizing of the IPM MN to have access to the visited network or FA. The message format exchanged between the IPM MN and the HMM is as follows: Type (8) Flags (8) Lifetime (16) Home Address (32) Home Agent (32) Care-of-Address (32) Identification (64) e Source Address - An IP address of the MN. This is part of the standard heading. * Destination Address - The COA within the ANI component. This is part of the standard heading. * Type - The type of the message is 0, which is the Registration Request message. * Flags - The flags filed are the same as RFC2002. Page 62 of 138 WO 01/19050 PCT/IBOO/01553 266 * Lifetime - The lifetime requested by MN from the HMM or Home. * Home Address - The IP address of the MN. " Home Agent - The Home Agent's address of the MN. " Care-of-Address - The Care-of-Address of the MN. " Identification - The identification, to provide replay protection. The Extensions used in the Registration Request are, " Mobile-Home Authentication Extension e Mobile-Foreign Authentication Extension (Optional) e Foreign-Home Authentication Extension (Optional) and can be explained further in the Extension Section 4. 3.1.2.2 Service Request and Message Format The Service Request message is sent from the HMM to the ISC (IPM Security Center) to authenticate a user or message, generate, renew, or delete session secret keys. It also can be sent from the PPS Manager to the ISC to generate or construct the IPMC. The message format exchanged between the HMM and the ISC is as follows: Type Sub-Type Payload Length Identification User NAI * Type - USERSERVICEREQUESTMSG. * Sub-Type -0. * Payload Length - Length of the message payload including all the extensions. * Identification - A 64-bit number used for matching User Service Request messages with User Service Reply messages, and for protecting against replay attacks of User Service Request messages. " User NAI - In phase I, this extension has the user NAI and in the future will have an index which will be used to index the user data in the UDS. The Extensions used in the Service Request message are, " User Authentication Information Extension * Control Message Authentication Extension * Session Key Allocation Extension 0..N * Session Key Lifetime Renewal Extension 0..N * Session Key Delete Extension O..N Page 63 of 138 WO 01/19050 PCT/IBOO/01553 267 and can be explained further in the Extension Section 4. 3.1.2.3 Service Reply and Message Format The Service Reply message is sent from the ISC (IPM Security Center) to the HMM in response to a Service Request message. The message format exchanged between the ISC and the HMM is as follows: Type Sub-Type Payload Length Code Identification User NAI * Type - USERSERVICEREPLYMSG. e Sub-Type - 0. * Payload Length - Length of the message payload including all the extensions. " Code - The following are the hex values of the defined codes: - 00000001 User Authenticated successfully. - 00000002 All required keys have been allocated. - 00000003 Some keys have been allocated. - 00000004 User Authentication failed. - 00000005 Key Lifetime Renewal is completely honoured. - 00000006 Key Lifetime Renewal is partially honoured. - 00000007 User Account is created successfully. - 00000008 User is deleted successfully. * Identification - A 64-bit number used for matching User Service Request messages with User Service Reply messages, and for protecting against replay attacks of User Service Request messages. * User NAI - In phase I, this extension has the user NAI and in the future will have an index which will be used to index the user data in the UDS. The Extensions used in the Service Response message are, e Control Message Authentication Extension " Session Key Allocation Extension O..N e Session Key Lifetime Renewal Extension O..N " Session Key Delete Extension O..N and can be explained further in the Extension Section 4. Page 64 of 138 WO 01/19050 PCT/IBOO/01553 268 3.1.2.4 Add Tunnel Entry and Message Format The Add Tunnel Entry message is sent by the HMM to instruct the ITS to set up a tunnel entry point. The message format exchanged between the HMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 1, for Add Tunnel Entry message. " Message Length - Length of the message including the header fields. * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Entry message are, 0 Host NAI Extension e Flag Extension 0 Lifetime Extension e Mobile Node IP Address Extension * User NAI Extension (Optional) 0 Tunnel Entry IP Address Extension and can be explained further in the Extension Section 4. 3.1.2.5 Add Tunnel Entry Acknowledgement and Message Format The Add Tunnel Entry Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Entry message. The message format exchanged between the ITS and the HMM is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 2, for Add Tunnel Entry Acknowledgement message. " Message Length - Length of the message including the header fields. Page 65 of 138 WO 01/19050 PCT/IBOO/01553 269 * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Entry message are, " Host NAI Extension " Result Code Extension * Mobile Node IP Address Extension (Optional) * User NAI Extension (Optional) and can be explained further in the Extension Section 4. 3.1.2.6 Registration Reply and Message Format The Registration Reply message is sent by the HMM to the IPM MN to indicate the result of the Registration Request message sent. The message format exchanged between the HMM and the IPM MN is as follows: Type (8) Code (8) Lifetime Home Address (32) Home Agent (32) Identification (64) * Type - The type of the message is 3, which is the Registration Request message. * Code - All the existing MIP Response codes, this field is being extended to include IPM specific items. * Lifetime - The Home lifetime for the registration. * Home Address - The IP address of the MN. * Home Agent - The Home Agent's address of the MN. * Identification - The identification, to provide replay protection. The Extensions used in the Registration Reply message are, * Mobile-Home Authentication Extension * Foreign-Home Authentication Extension (Optional) " Mobile-Foreign Authentication Extension (Optional) and can be explained further in the Extension Section 4. Page 66 of 138 WO 01/19050 PCT/IB00/01553 270 3.2 IPM MN RE-REGISTERS FROM MIP FA IP NSF MN MIP A AAA MM IS SC CP DNS Regi action Request (Re-r i traction) Registration Request (Re-registration) f ......... ervice Req est f ce ResT >nsed . . . . . . . . . . ............ .. e. Optionally enewMN' IPAddre R............. ... .......... Registration Reply Registration Reply ....-....... .......................... . ,,.......... ....... . ... ... . h IPM MN re-registers from MIP FA 3.2.1 Registration Process See Section 3.1.2 3.2.1.1 Registration Request and Message Format See Section 3.1.2.1 3.2.1.2 Service Request and Message Format See Section 3.1.2.2 3.2.1.3 Service Reply and Message Format See Section 3.1.2.3 3.2.1.4 Registration Reply and Message Format See Section 3.1.2.6 Page 67 of 138 WO 01/19050 PCT/IBOO/01553 271 3.3 IPM MN DE-REGISTERS FROM MIP FA NSF M M1 FAH-AA HMM ITS ISC CP DNS Reg tron Request (De- itraton) Registration Request (De-registration).....b service Req est e caRe nse | Optionally release M *s IP Add:s back to OHCP De ete Tunne ntry -Del e Tu iltry Ack R- tonR >ly Registration Replyb Registration Reply IPM MN de-registers from MIP FA 3.3.1 Registration Process See Section 3.1.2 3.3.1.1 Registration Request and Message Format See Section 3.1.2.1 3.3.1.2 Service Request and Message Format See Section 3.1.2.2 3.3.1.3 Service Reply and Message Format See Section 3.1.2.3 3.3.1.4 Delete Tunnel Entry and Message Format The Delete Tunnel Entry message is sent by the HMM to instruct the ITS to delete a tunnel entry point. The message format exchanged between the HMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 7, for Delete Tunnel Entry message. " Message Length - Length of the message including the header fields. Page 68 of 138 WO 01/19050 PCT/IBOO/01553 272 e Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Entry message are, " Host NAI Extension e Mobile Node IP Address Extension * User NAI Extension (Optional) and can be explained further in the Extension Section 4. 3.3.1.5 Delete Tunnel Entry Acknowledgement and Message Format The Delete Tunnel Entry Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Entry message. The identification field should be used for matching with the Delete Tunnel Entry message. The message format exchanged between the ITS and the HMM is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 8, for Delete Tunnel Entry Acknowledgement message. " Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Entry Acknowledgement message are, e Host NAI Extension " Result Code Extension " Mobile Node IP Address Extension (Optional) " User NAI Extension (Optional) and can be explained further in the Extension Section 4. 3.3.1.6 Registration Reply and Message Format See Section 3.1.2.6 Page 69 of 138 WO 01/19050 PCT/IBOO/01553 273 Page 70 of 138 WO 01/19050 PCT/IBOO/01553 274 3.4 IPM MN HANDOFFS FROM IPM ANI TO FA (NO SMOOTH HANDOFF) LSF NSF N MIP FA ANI ITS MM AAA H-AA IMM TS SC HCP Regi ration Request (Syste change) a Registration request (S tern Chanj e) ............... ................................................................................. Sevice.Re.ra Service Re t aet ................. S rvceRe nse )ptionally r new MN's Address Add Ts Entry ......... ... ......... .......... -........ .................................. ........ ...... ... ... ... ... ... .... ...1 egistration eply AAA e i ancellation Registration Reply .... .. ... ........ ....- .......... ..................... ..................... ............................................................ ....... AAA registration (acellation Del :.x t ...... ............................. . - ....................... .. . ...... .. ... . ......... . . . ! . . . . . . .. . . . . Delete n i Ack ..

AA k R - Cancellatio Ack .AAA Re trto lc tion Ack-m AAA Regis ration Ca e jation Ack 1PM MN handoff from 1PM ANI To FA (FA does not support smooth handoff) 3.4.1 Registration Process See Section 3.1.2 3.4.1.1 Registration Request and Message Format See Section 3.1.2.1 3.4.1.2 Service Request and Message Format See Section 3.1.2.2 3.4.1.3 Service Reply and Message Format See Section 3.1.2.3 3.4.1.4 Add Tunnel Entry and Message Format See Section 3.1.2.4 Page 71 of 138 WO 01/19050 PCT/IBOO/01553 275 3.4.1.5 Add Tunnel Entry Acknowledgement and Message Format See Section 3.1.2.5 3.4.1.6 Registration Reply and Message Format See Section 3.1.2.6 3.4.1.7 AAA-Registration Cancellation and Message Format The AAA-Registration Cancellation message is sent by the HMM to the SMM to cancel the existing User's registration at the visiting system. AAA-Registration Cancellation <DIAMETER Header> <Command-Code AVP = 337> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <IPM-Registration-Cancellation-Reason AVP> The AAA-Registration Cancellation message is of the format of DIAMETER. The HMM sends the message to the SMM with at least the mandatory fields to cancel the registration of the user. The IPM-Registration-Cancellation-Reason AVP indicates the reason for the cancellation of the registration. The AVPs that can optionally be used in the AAA-Registration Cancellation message are, e IPM-Client-Address AVP e Proxy-State AVP * Time AVP e Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. 3.4.1.8 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the SMM to instruct the ITS to delete a tunnel exit point. The message format exchanged between the SMM and the ITS is as follows: Code (16) Message Length (16) Page 72 of 138 WO 01/19050 PCT/IBOO/01553 276 Identification (64) Extensions... * Code - 9, for Delete Tunnel Exit message. 0 Message Length - Length of the message including the header fields. * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Exit message are, e Host NAI Extension e Mobile Node IP Address Extension (Optional) e User NAI Extension (Optional) * Tunnel Exit IP Address Extension and can be explained further in the Extension Section 4. 3.4.1.9 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. The message format exchanged between the ITS and the SMM is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 10, for Delete Tunnel Exit Acknowledgement message. " Message Length - Length of the message including the header fields. " Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Delete Tunnel Exit Acknowledgement message are, " Host NAI Extension " Result Code Extension " Mobile Node IP Address Extension (Optional) * User NAI Extension (Optional) Page 73 of 138 WO 01/19050 PCT/IBOO/01553 277 and can be explained further in the Extension Section 4. 3.4.1.10 AAA-Registration Cancellation Acknowledgement and Message Format The AAA-Registration Cancellation Acknowledgement message is sent by the SMM to the HMM in response to the AAA-Registration Cancellation message. The message format exchanged between the SMM and the HMM is as follows: AAA-Registration Cancellation <DIAMETER Header> Acknowledgement <Command-Code AVP = 338> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <Result-Code AVP> The AAA-Registration Cancellation Acknowledgement message is of the format of DIAMETER. The SMM sends the message to the HMM with at least the mandatory fields. The Response-Code AVP indicates the failure or success of the AAA-Registration Cancellation message. The AVPs that can optionally be used in the AAA-Registration Cancellation Acknowledgement message are, e Proxy-State AVP * Time AVP * Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. Page 74 of 138 WO 01/19050 PCT/IBOO/01553 278 3.5 IPM MN HANDOFFS FROM IPM ANI TO FA (SMOOTH HANDOFF) IPM LSF NSF MN MIPFA ANi ITS S M S.A AA H A M T iSC HCP Regi rtion Request (Syste hange) Registration equest (S tern Chant e) Binding Update N Service Re jest B indn I L Service Re lnee Tun 1i F -ng Add u Entry Tunnel o r Ack kn. d T nnl try Ack AAA .e istration (ancellation .................... ... .... ............ . . . ..... .. . h Binding Aknowledg egistration Replyth AgAAAA ( cancellation ................ . . De . .atAck ... .Registr o Cancellatio Ack.. R k AAA Reg station C c llation Ack AAA Regis ron C nation Ack 1PM MN handoff from IPM ANI To FA (FA supports smooth handoff) 3.5.1 Registration Process See Section 3.1.2 3.5.1.1 Registration Request and Message Format See Section 3.1.2.1 3.5.1.2 Binding Update and Message Format The Binding Update message is used for notification of a MN's current mobility binding. It SHOULD be sent by the MN's home agent in response to a Binding Request message, a Binding Warning message, or the reception of a Binding Warning extension to a Registration Request message. It SHOULD also be sent by a MN, or by the foreign agent with which the MN is registering, when notifying the MN's previous foreign agent that the MN has moved. The message format exchanged between the MIP FA and the SMM is as follows: Page 75 of 138 WO 01/19050 PCT/IBOO/01553 279 Type A I M G Rsvd Lifetime Mobile Node Home Address Care-of-Address Identification Extensions.... * Type - 18. * A - The 'A' (acknowledge) bit is set by the node sending the Binding Update message to request a Binding Acknowledge message be returned. * I - The 'I' (identification present) bit is set by the node sending the Binding Update message if the identification field is present in the message. * M - If the 'M' (minimal encapsulation) bit is set, datagrams MAY be tunneled to the MN using the minimal encapsulation protocol. * G - If the 'G' (Generic Record Encapsulation, or GRE) bit is set, datagrams MAY be tunneled to the MN using GRE. * Rsvd - Reserved. Set as 0; ignored on reception. * Lifetime - The number of seconds remaining before the binding cache entry must be considered expired. A value of all ones indicates infinity. A value of zero indicates that no binding cache entry for the MN should be created and that any existing binding cache entry (and visitor list entry, in the case of a MN's previous foreign agent) for the MN should be deleted. The lifetime is typically equal to the remaining lifetime of the MN's registration. 0 Mobile Node Home Address - The home address of the MN to which the Binding Update message refers. 0 Care-of-Address - The current care-of-address of the MN. When set equal to the home address of the MN, the Binding Update message instead indicates that no binding cache entry for the MN should be created, and any existing binding cache entry (and visitor list entry, in the case of a MN's previous foreign agent) for the MN should be deleted. 0 Identification - If present, a 64-bit number, assigned by the node sending the Binding Request message, is used to assist in matching requests with replies, and in protection against replay attacks. 3.5.1.3 Service Request and Message Format See Section 3.1.2.2 3.5.1.4 Service Reply and Message Format See Section 3.1.2.3 Page 76 of 138 WO 01/19050 PCT/IB00/01553 280 3.5.1.5 Tunnel Forwarding and Message Format The Tunnel Forwarding message is sent by the SMM to instruct the ITS to set up a tunnel forwarding. The message format exchanged between the SMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... * Code - 5, for Tunnel Forwarding message. * Message Length - Length of the message including the header fields. * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Tunnel Forwarding message are, * Host NAI Extension e Mobile Node IP Address Extension * User NAI Extension (Optional) e Lifetime Extension e Tunnel Exit IP Address Extension and can be explained further in the Extension Section 4. 3.5.1.6 Add Tunnel Entry and Message Format See Section 3.1.2.4 3.5.1.7 Tunnel Forwarding Acknowledgement and Message Format The Tunnel Forwarding Acknowledgement message is sent by the ITS to acknowledge the Tunnel Forwarding message. The identification field should be used for matching with the Tunnel Forwarding message. The message format exchanged between the ITS and the SMM is as follows: Code (16) Message Length (16) Identification (64) Page 77 of 138 WO 01/19050 PCT/IBOO/01553 281 Extensions... * Code - 6, for Tunnel Forwarding Acknowledgement message. * Message Length - Length of the message including the header fields. * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Tunnel Forwarding Acknowledgement message are, * Host NAI Extension * Mobile Node IP Address Extension " User NAI Extension (Optional) * Result Code Extension and can be explained further in the Extension Section 4. 3.5.1.8 Add Tunnel Entry Acknowledgement Format and Message Format See Section 3.1.2.5 3.5.1.9 Binding Update Acknowledge and Message Format The Binding Acknowledge message is used to acknowledge receipt of a Binding Update message. It SHOULD be sent by a node receiving a Binding Update message if the acknowledge (A) bit is set in the Binding Update message. The message format exchanged between the SMM and the MN is as follows: Type Reserved Status Mobile Node Home Address Care-of-Address Identification * Type - 19. * Status - If the Status is nonzero, this acknowledgement is negative. For instance, if the Binding Update was not accepted, but the incoming datagram has the Acknowledge flag set, then the status code should be set appropriately in the Binding Acknowledge message. * Reserved- Sent as 0; ignored on reception. * Mobile Node Home Address- Copied from the Binding Update message being acknowledged. Page 78 of 138 WO 01/19050 PCT/IBOO/01553 282 e Identification - Copied from the Binding Update message being acknowledged, if present there. 3.5.1.10 Registration Reply and Message Format See Section 3.1.2.6 3.5.1.11 AAA-Registration Cancellation and Message Format See Section 3.4.1.7 3.5.1.12 Delete Tunnel Exit and Message Format See Section 3.4.1.8 3.5.1.13 Delete Tunnel Exit Acknowledgement and Message Format See Section 3.4.1.9 3.5.1.14 AAA-Registration Cancellation Acknowledgement and Message Format See Section 3.4.1.10 Page 79 of 138 WO 01/19050 PCT/IBOO/01553 283 3.6 IPM MN HANDOFFS FROM FA TO IPM ANI (NO SMOOTH HANDOFF) LSF NSF MN MP FA [ANI TSJ 2 MMJAAAJ [-AA MM jTS SCJHC Registration request (System Change) I Regi rion Req est (Syst n Change) AA/ R Request AAP Registrati request A AlRegistrat a Reqaest Service Re< est S vice Re! onse . .................... Add Tau Entry . d Tunne.... try Ack A A Reta i ado Reply .............................................................................. ....... ..... ......... _....... ............ .......... . . . . . .. .. . . . . . ...... m. egitra on Replyelio Rexit Ad t lAck - . . . . Registration Reply .... ...................... .............. .. ................... ~~~~~~~~~.................... ............................................................ ............................................... I........ ........... q 1PM MN handoff from FA To 1PM ANI (FA does not support smooth handoff) 3.6.1 Registration Process See Section 3.1.2 3.6.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the SMM to register for the service. See Section 3.1.2.1 for the message format between the IPM MN and the SMM. 3.6.1.2 AAA-Registration Request and Message Format The AAA-Registration-Request message is used to carry out various kinds of registrations; these registrations are encapsulated in the IPM-Registration-Type AVP. This message is used by SMM to authenticate and authorize the user. The message format exchanged between the SMM and the HMM is as follows: AAA-Registration-Request <DIAMETER Header> <Command-Code AVP = 335> Page 80 of 138 WO 01/19050 PCT/IBOO/01553 284 <User-Name AVP> <Host-Name AVP> <IPM-Registration-Type AVP> <IPM-Registration-Request AVP> <IPM-Care-of-Address AVP> <IPM-Routing-Area-NAI AVP> The AAA-Registration-Request message is of the format of DIAMETER. The SMM sends the message to HMM with at least these mandatory fields. The IPM Registration-Request AVP is the AVP which carries the message received from the MN, which is encapsulated in the AVP format for the Home domain to authenticate the user. The HMM processes this message based on the Registration-Type AVP, which carries the type of registration requested. The AVPs that can optionally be used in the Registration Request message are, " Destination-NAI AVP " IPM-Client-Address AVP * Home-Agent-Address AVP * IPM-SMM-NAI AVP * IPM-Terminal-Type AVP * IPM-Profile-Type AVP e Proxy-State AVP " Timestamp AVP * Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVP Section 5. 3.6.1.3 Service Request and Message Format See Section 3.1.2.2 3.6.1.4 Service Reply and Message Format See Section 3.1.2.3 3.6.1.5 Add Tunnel Entry and Message Format See Section 3.1.2.4 3.6.1.6 Add Tunnel Entry Acknowledgement and Message Format See Section 3.1.2.5 Page 81 of 138 WO 01/19050 PCT/IBOO/01553 285 3.6.1.7 AAA-Registration Reply and Message Format The AAA Registration Reply message is sent by the HMM to the SMM to indicate the result of the AAA-Registration Request message. The message format exchanged between the HMM and the SMM is as follows: AAA-Registration-Response <DIAMETER Header> <Command-Code AVP = 336> <Destination-NAI AVP> <Host-Name AVP> <User-Name AVP> <IPM-Registration-Response-Code AVP> <IPM-Client-Address AVP> <IPM-Registration-Reply AVP> The AAA-Registration Reply message is of the format of DIAMETER. The HMM sends a message to the SMM with at least the mandatory fields in response to AAA-Registration Request message. The IPM-Registration Response Code AVP indicates the success or failure of the request. The IPM Registration Reply message AVP contains the reply message built by HMM with authentication. The SMM has to use this AVP to send a reply to ANI/MN. The AVPs that can optionally be used in the Registration Reply message are, " IPM-Profile AVP * IPM-SMM-MN-Key AVP * IPM-HMM-NAI AVP " Proxy-State AVP e Time AVP " Nonce AVP " Integrity-Check-Value AVP and can be explained further in the AVPs Section 5. 3.6.1.8 Registration Reply and Message Format The Registration Reply message is sent by the SMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the SMM and the IPM MN. Page 82 of 138 WO 01/19050 PCT/IBOO/01553 286 3.6.1.9 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the SMM to instruct the ITS to set up a tunnel exit point. The message format exchanged between the SMM and the ITS is as follows: Code (16) Message Length (16) Identification (64) Extensions... * Code - 3, for Add Tunnel Exit message. * Message Length - Length of the message including the header fields. * Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Exit message are, " Host NAI Extension " Lifetime Extension e Mobile Node IP Address Extension * User NAI Extension (Optional) " Tunnel Exit IP Address Extension and can be explained further in the Extension Section 4. 3.6.1.10 Add Tunnel Exit Acknowledgement and Message Format The Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Exit message. The message format exchanged between the ITS and the SMM is as follows: Code (16) Message Length (16) Identification (64) Extensions... " Code - 4, for Add Tunnel Exit Acknowledgement message. " Message Length - Length of the message including the header fields. Page 83 of 138 WO 01/19050 PCT/IBOO/01553 287 e Identification - Is used in matching requests and acknowledgements. The sender must ensure the identifier in a message is locally unique at any given time. The Extensions used in the Add Tunnel Exit Acknowledgement message are, " Host NAI Extension * Result Code Extension * Mobile Node IP Address Extension (Optional) e User NAI Extension (Optional) e Tunnel Forwarding IP Address Extension and can be explained further in the Extension Section 4. Page 84 of 138 WO 01/19050 PCT/IBOO/01553 288 3.7 IPM MN HANDOFFS FROM FA TO IPM ANI (SMOOTH HANDOFF) LSF NSF MIPAN S M IAAA HAA MM TS SC HCP RegiRtraeqon request (System Change). e Regi ration Req e~st Ssr Change) b AM RegsranRequest

.

Binding Update d Tunnelit . .- . . . . . . . . AM Regitrtin equestd Binding g Upndate A Tu ne it Ack ~AA Registratnr Request Service Re aest Binding Acknwledge Binding Acknusnledre .... ............. ....-............ ...... . . . . . . . I..................... . . . . . . I....... ......... ................... ............. I.......... ........ ............... h. ....... ..... - ........... ........ ... ........ ....... I... . . ..... . . . . .- ............... .... AA. . ............. ....................... .............. _..d ~ r a .n A.... .. ...... ....... A/ A Regtstera Reply AA eply egistrat an Reply If error, remt ve tunnel xit Registration Replya IPM MN handoff from FA To IPM ANI (FA supports smooth handoff) 3.7.1 Registration Process See Section 3.1.2 3.7.1.1 Registration Request and Message Format The Registration Request message is sent by the IPM MN to the SMM to register for the service. See Section 3.1.2.1 for the message format exchanged between the IPM MN and the SMM. 3.7.1.2 AAA-Registration Request and Message Format See Section 3.6.1.2 3.7.1.3 Binding Update and Message Format The Binding Update message is used for notification of a MN's current mobility binding. It SHOULD be sent by the MN's home agent in response to a Binding Request message, Page 85 of 138 WO 01/19050 PCT/IBOO/01553 289 a Binding Warning message, or the reception of a Binding Warning extension to a Registration Request message. It SHOULD also be sent by a MN, or by the foreign agent with which the MN is registering, when notifying the MN's previous foreign agent that the MN has moved. See Section 3.5.1.2 for the message format exchanged between the SMM and the MIP FA. 3.7.1.4 Add Tunnel Exit and Message Format See Section 3.6.1.9 3.7.1.5 Add Tunnel Exit Acknowledgement and Message Format See Section 3.6.1.10 3.7.1.6 Service Request and Message Format See Section 3.1.2.2 3.7.1.7 Binding Acknowledge and Message Format The Binding Update Acknowledge message is used to acknowledge receipt of a Binding Update message. It SHOULD be sent by a node receiving a Binding Update message if the acknowledge (A) bit is set in the Binding Update message. See Section 3.5.1.9 for the message format exchanged between the MIP FA and the IPM MN. 3.7.1.8 Service Reply and Message Format See Section 3.1.2.3 3.7.1.9 Add Tunnel Entry and Message Format See Section 3.1.2.4 3.7.1.10 Add Tunnel Entry Acknowledgement and Message Format See Section 3.1.2.5 3.7.1.11 AAA-Registration Reply and Message Format See Section 3.6.1.7 3.7.1.12 Registration Reply and Message Format Page 86 of 138 WO 01/19050 PCT/IB00/01553 290 The Registration Reply message is sent by the SMM to the IPM MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the SMM and the IPM MN. Page 87 of 138 WO 01/19050 PCT/IBOO/01553 291 3.8 MIP MN REGISTERS FROM IPM LSF N A ITS SMM S-AA MIP HA Regis at on Req ae t ~c Registration Requst Registration Reply c t A ck. . . !egistra on Reply R gistration R ply ...... ................ ......................... ................... . . . . . . . . .................... ..................... .. ................................ MIP MN registers from IPM LSF 3.8.1 Agent Discovery Process See Section 3.1.1 3.8.1.1 Agent Solicitation and Message Format Agent Solicitation is the broadcast/multicast message sent by the MIP MN to detect a Service Provider in the event that the MIP MN has not received an Advertising Agent message. See Section 3.1.1.1 for the message format exchanged between the MIP MN and the ANI. 3.8.1.2 Agent Advertisement and Message Format Agent Advertisement are messages sent periodically, either as a broadcast or multicast for the visiting MIP MN to recognize the availability of service and to keep track of their point of attachment. See Section 3.1.1.2 for the message format exchanged between the ANI and the MIP MN. 3.8.2 Registration Process The purpose of registration is for the MIP MN to inform the MIP HA of its current location to which data packets can be forwarded to the MIP MN. The Registration process also includes the authenticating and authorizing of the MIP MN to have access to the visited network or LSF (Local Serving Function). 3.8.2.1 Registration Request and Message Format Page 88 of 138 WO 01/19050 PCT/IBOO/01553 292 The Registration Request message is sent by the MIP M4N to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.8.2.2 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and the MIP MN. 3.8.2.3 Add Tunnel Exit and Message Format See Section 3.6.1.9 3.8.2.4 Add Tunnel Exit Acknowledgement and Message Format See Section 3.6.1.10 Page 89 of 138 WO 01/19050 PCT/IBOO/01553 293 3.9 MIP MN RE-REGISTERS FROM IPM LSF MN AN ITS 5MM S-AAA HA Ag Advertis eat b Regis. action Re et Registratioa Rd Registration Request Registration Reply Rc 6stration R ply intention R y~ --. * - ......... ............... . . . ...... ... ... .... ... ... . ...... . . . . . . . . . . . ........ ..... ..... ......... ... ......... .. ........ ...... k ..... I MIP MN re-registers from IPM LSF 3.9.1 Agent Discovery Process See Section 3.1.1 3.9.1.1 Agent Solicitation and Message Format Agent Solicitation is the broadcast/multicast message sent by the MIP MN to detect a Service Provider in the event that the MIP MN has not received an Advertising Agent message. See Section 3.1.1.1 for the message format exchanged between the MIP MN and the ANI. 3.9.1.2 Agent Advertisement and Message Format Agent Advertisement are messages sent periodically, either as a broadcast or multicast for the visiting MIP MN to recognize the availability of service and to keep track of their point of attachment. See Section 3.1.1.2 for the message format exchanged between the ANI and the MIP MN. 3.9.2 Registration Process See Section 3.8.2 3.9.2.1 Registration Request and Message Format Page 90 of 138 WO 01/19050 PCT/IBOO/01553 294 The Registration Request message is sent by the MIP MN to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.9.2.2 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and the MIP MN. Page 91 of 138 WO 01/19050 PCT/IBOO/01553 295 3.10 MIP MN HANDOFFS FROM IPM ANI TO FA (NO SMOOTH HANDOFF) MIPLSF MIP MN MIP FA ANI TS j MM S-A A HA Regisraion Request 1 I._-___________R____q-_u ._....Registn ion Reque - ...... ... I b .L_ Registr _ion Reply egistration Reply - . . . ANI T meout SM Timeout e D e N inE~xit ....................- ............................................................................. ............................................. ...... ........................ f Dele Tunel t Ack MIP MN handoff from IPM ANI to FA(FA does not support smooth han doff) 3.10.1 Registration Process See Section 3.8.2 3.10.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP 4N to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.10.1.2 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and the MIP MN. 3.10.1.3 Delete Tunnel Exit and Message Format See Section 3.4.1.8 3.10.1.4 Delete Tunnel Exit Acknowledgement and Message Format See Section 3.4.1.9 Page 92 of 138 WO 01/19050 PCT/IBOO/01553 296 3.11 MIP MN HANDOFFS FROM IPM ANI TO FA (SMOOTH HANDOFF) MIP LSF MIP MN MIPFA NI ITSI M -AAA HA Registration Req est a Regisr ion Reque b Binding Update Regisin tion Reply d Binding pdUt Registration Reply ............................................................... !L 2 Ing .............. .......................... ........... f Tun. el or ng Ack Binding A knowledge .1 Binding Acknowledge Binding Acknowledge ANI Tieout: SM Tineout Dl Tunnel Exit Delel Tune it Ack MIP MN handoff from IPM ANI to FA(FA supports smooth handoff) 3.11.1 Registration Process See Section 3.8.2 3.11.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP MN to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.11.1.2 Binding Update and Message Format See Section 3.5.1.2 3.11.1.3 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and the MIP MN. Page 93 of 138 WO 01/19050 PCT/IBOO/01553 297 3.11.1.4 Tunnel Forwarding and Message Format See Section 3.5.1.5 3.11.1.5 Tunnel Forwarding Acknowledgement and Message Format See Section 3.5.1.7 3.11.1.6 Binding Acknowledge and Message Format See Section 3.5.1.9 3.11.1.7 Delete Tunnel Exit and Message Format See Section 3.4.1.8 3.11.1.8 Delete Tunnel Exit Acknowledgement and Message Format See Section 3.4.1.9 Page 94 of 138 WO 01/19050 PCT/IBOO/01553 298 3.12 MIP MN HANDOFFS FROM FA TO IPM ANI (NO SMOOTH HANDOFF) MIPLSF MIP MN MIP FA AN ITS M Sj M I SAA HA Regist tion Request Registration eReques Registration Reply Ad Tu tAck ita nReply Registration Reply MIP MN handoff from FA to IPM ANI (FA does not support smooth handoff) 3.12.1 Registration Process See Section 3.8.2 3.12.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP MN to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.12.1.2 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and MIP MN. 3.12.1.3 Add Tunnel Exit and Message Format See Section 3.6.1.9 3.12.1.4 Add Tunnel Exit Acknowledgement and Message Format See Section 3.6.1.10 Page 95 of 138 WO 01/19050 PCT/IBOO/01553 299 3.12 MIP MN HANDOFFS FROM FA TO IPM ANI (NO SMOOTH HANDOFF) MIPLSF MIP MN MIP FA AN ITS M Sj M I SAA HA Regist tion Request Registration eReques Registration Reply Ad Tu tAck ita nReply Registration Reply MIP MN handoff from FA to IPM ANI (FA does not support smooth handoff) 3.12.1 Registration Process See Section 3.8.2 3.12.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP MN to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.12.1.2 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and MIP MN. 3.12.1.3 Add Tunnel Exit and Message Format See Section 3.6.1.9 3.12.1.4 Add Tunnel Exit Acknowledgement and Message Format See Section 3.6.1.10 Page 95 of 138 WO 01/19050 PCT/IBOO/01553 300 3.13.1.4 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and the MIP MN. 3.13.1.5 Add Tunnel Exit Acknowledgement and Message Format See Section 3.6.1.10 3.13.1.6 Binding Acknowledge and Message Format The Binding Acknowledge message is used to acknowledge receipt of a Binding Update message. It SHOULD be sent by a node receiving a Binding Update message if the acknowledge (A) bit is set in the Binding Update message. See Section 3.5.1.9 for the message format exchanged between the MIP FA and the MIP MN Page 97 of 138 WO 01/19050 PCT/IBOO/01553 301 3.14 MIP MN HANDOFFS FROM NSF TO FA (NO SMOOTH HANDOFF) MI MP MIP NSF MN FA AHA MM4TS1JC1 CP Registration Request F J Regi straioon Request b................................................... . . Registration Reply Registration ReplyR :ANI imeout : HMM' imeout D lete Tune Esit Del et E -tAckg MIP MN handoff from NSF to FA (FA does not support smooth handoff) 3.14.1 Registration Process See Section 3.8.2 3.14.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP MN to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.14.1.2 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and the MIP MN. 3.14.1.3 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the HMM to instruct the ITS to delete a tunnel exit point. See Section 3.4.1.8 for the message format exchanged between the HMM and the ITS. Page 98 of 138 WO 01/19050 PCT/IBOO/01553 302 3.14.1.4 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. See Section 3.4.1.9 for the message format exchanged between the ITS and the HMM. Page 99 of 138 WO 01/19050 PCT/IBOO/01553 303 3.15 MIP MN HANDOFFS FROM NSF TO FA (SMOOTH HANDOFF) NSF MPMIP MIPNS MN FA HA ANI AAA MM fIITS ISC DHCP Registration Request Registra y.............. .. .......... ..... RegistrationRequest b Bindin. Update Registration Reply Binding Jpdate Registration Reply Ti nel-o ding ending .cknonledg. Binding Ack owledge Binding Acknowledge AN] T meout HMM Timgout D lete Tun el Eit Del to ann E it Ack .................................... . ........... .... ......... .. ....... ..... .... J.... ............... ... 1 **1*1,1111111 1. ... . . .... .... . . . . . . MIP MN handoff from NSF to FA (FA supports smooth handoff) 3.15.1 Registration Process See Section 3.8.2 3.15.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP MN to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.15.1.2 Binding Update and Message Format The Binding Update message is used for notification of a MN's current mobility binding. It SHOULD be sent by the MN's home agent in response to a Binding Request message, a Binding Warning message, or the reception of a Binding Warning extension to a Registration Request message. It SHOULD also be sent by a MN, or by the foreign agent with which the MN is registering, when notifying the MN's previous foreign agent that the MN has moved. See Section 3.5.1.2 for the message format exchanged between the MIP FA and the HMM. Page 100 of 138 WO 01/19050 PCT/IB00/01553 304 3.15.1.3 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message flow exchanged between the MIP HA and the MIP MN. 3.15.1.4 Tunnel Forwarding and Message Format The Tunnel Forwarding message is sent by the HMM to instruct the ITS to set up a tunnel forwarding. See Section 3.5.1.5 for the message format exchanged between the HMM and the ITS. 3.15.1.5 Tunnel Forwarding Acknowledgement and Message Format The Tunnel Forwarding Acknowledgement message is sent by the ITS to acknowledge the Tunnel Forwarding message. The identification field should be used for matching with the Tunnel Forwarding message. See Section 3.5.1.7 for the message format exchanged between the ITS and the HMM. 3.15.1.6 Binding Acknowledge and Message Format The Binding Acknowledge message is used to acknowledge receipt of a Binding Update message. It SHOULD be sent by a node receiving a Binding Update message if the acknowledge (A) bit is set in the Binding Update message. See Section 3.5.1.9 3.15.1.7 Delete Tunnel Exit and Message Format The Delete Tunnel Exit message is sent by the HMM to instruct the ITS to delete a tunnel exit point. See Section 3.4.1.8 for the message format exchanged between the HMM and the ITS. 3.15.1.8 Delete Tunnel Exit Acknowledgement and Message Format The Delete Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Delete Tunnel Exit message. The identification field should be used for matching with the Delete Tunnel Exit message. Page 101 of 138 WO 01/19050 PCT/IB00/01553 305 See Section 3.4.1.9 for the message format exchanged between the ITS and the HMM. Page 102 of 138 WO 01/19050 PCT/IB00/01553 306 3.16 MIP MN HANDOFFS FROM FA TO NSF (NO SMOOTH HANDOFF) NSF MN FA HA A AAA MM ITS SC HCP Registration Request _ a Registratio Request Registratio Request _ Registrati- n Reply A Id TunE ite Add T e Ei Ack Reitat> Reply ________________________ Registration Repl y ____________ k MIP MN handoff from FA to NSF (FA does not support smooth handoff) 3.16.1 Registration Process See Section 3.8.2 3.16.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP MN to the MIP HA to register for the service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.16.1.2 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MN to indicate the result of the Registration Request message sent. See Section 3.1.2.6 for the message format exchanged between the MIP HA and MIP MN. 3.16.1.3 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the HMM to instruct the ITS to set up a tunnel exit point. See Section 3.6.1.9 for the message format exchanged between the HMM and the ITS. Page 103 of 138 WO 01/19050 PCT/IB00/01553 307 3.16.1.4 Add Tunnel Exit Acknowledgement and Message Format The Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Exit message. See Section 3.6.1.10 for the message format exchanged between the ITS and the HMM. Page 104 of 138 WO 01/19050 PCT/IB00/01553 308 3.17 MIP MN HANDOFFS FROM FA TO NSF (SMOOTH HANDOFF) NSF MIPMPMI MN IHA AN -AAA MM TS ISC HCP Registration Request _ I a . .. . . . . . . . . . . . .Registratiot R Registratio i Request _ Binding Update Registrati- Reply Binding Acknowledge A Id T -nneLE it Binding Acknowledge Add T I Ack 14 Registration Reply ........ .. .......... ............. ..... .............. .1.......... ................................ .. ..... ....... k.... ... ...... ..... .. .......... .... .............. ......... ... .. ... ..... ....... .... MIP MN handoff from FA to NSF (FA supports smooth handoff) 3.17.1 Registration Process See Section 3.8.2 3.17.1.1 Registration Request and Message Format The Registration Request message is sent by the MIP MN to the MIP HA to register for service. See Section 3.1.2.1 for the message format exchanged between the MIP MN and the MIP HA. 3.17.1.2 Binding Update and Message Format The Binding Update message is used for notification of a MN's current mobility binding. It SHOULD be sent by the MN's home agent in response to a Binding Request message, a Binding Warning message, or the reception of a Binding Warning extension to a Registration Request message. It SHOULD also be sent by a MN, or by the foreign agent with which the MN is registering, when notifying the MN's previous foreign agent that the MN has moved. See Section 3.5.1.2 for the message format exchanged between the HMM and the MIP FA. 3.17.1.3 Registration Reply and Message Format The Registration Reply message is sent by the MIP HA to the MIP MAN to indicate the result of the Registration Request message sent. Page 105 of 138 WO 01/19050 PCT/IB00/01553 309 See Section 3.1.2.6 for the message format exchanged between the MIP HA and the MIP MN. 3.17.1.4 Binding Acknowledge and Message Format The Binding Acknowledge message is used to acknowledge receipt of a Binding Update message. It SHOULD be sent by a node receiving a Binding Update message if the acknowledge (A) bit is set in the Binding Update message. See Section 3.5.1.9 for the message format exchanged between the MIP FA and the MIP MN. 3.17.1.5 Add Tunnel Exit and Message Format The Add Tunnel Exit message is sent by the HMM to instruct the ITS to set up a tunnel exit point. See Section 3.6.1.9 for the message format exchanged between the HMM and the ITS. 3.17.1.6 Add Tunnel Exit Acknowledgement and Message Format The Tunnel Exit Acknowledgement message is sent by the ITS to acknowledge the Add Tunnel Exit message. See Section 3.6.1.10 for the message format exchanged between the ITS and the HMM. Page 106 of 138 WO 01/19050 PCT/IB00/01553 310 4. EXTENSIONS 4.1 AGENT DISCOVERY EXTENSIONS 4.1.1 ANI-NAI Extension The ANI-NAI Extension is used to carry the ANI information, such as ANI's NAI (Network Access Identifier). Type (8) Length (8) Sub-Type (8) Rsvd (8) ANI-NAI... * Type - IPM-VENDOR-SPECIFIC-EXTENSION (255). * Length - Length of the ANI-NAI string + 2 bytes. " Sub-Type - The sub-type of extension (1). " Rsvd - Reserved byte. * ANI-NAI - The NAI string of the ANI. 4.1.2 Mobility Agent Advertisement Extension The Mobility Agent Advertisement Extension is added to the ICMP Router Advertisement message to indicate to MNs that this is an Agent Advertisement message (not an Router Advertisement message) with the specified Care-of Addresses. Type Length Sequence Number Registration Lifetime R B |H F M G V Reserved Zero or more Care-of-Address(es) e Type-16 " Length - (6 + 4*N), where N is the number of Care-of-Address(es) advertised. * Sequence Number - The count of Agent Advertisement messages sent since the agent was initialized. " Registration Lifetime - The longest lifetime (measured in seconds) that this agent is willing to accept in any Registration Request message. A value of Oxffff indicates infinity. This field has no relation to the "lifetime" field within the ICMP router advertisement portion of the Agent Advertisement message. o R - Registration required. Registration with this foreign agent (or another foreign agent on this link) is required rather than using a co-located Care-of-Address. " B - Busy. The foreign agent will not accept registrations from additional MNs. Page 107 of 138 WO 01/19050 PCT/IBOO/01553 311 * H - Home agent. This agent offers service as a home agent on the link on which this Agent Advertisement message is sent. e F - Foreign agent. This agent offers service as a foreign agent on the link on which this Agent Advertisement message is sent. * M - Minimal encapsulation. This agent implements receiving tunneled datagrams that use minimal encapsulation [15]. * G - GRE encapsulation. This agent implements receiving tunneled datagrams that use GRE encapsulation [8]. " V - Van Jacobson header compression. This agent support use of Van Jacobson header compression [10] over the link with any registered MN. " Reserved - Sent as zero; ignored on reception. * Care-of-Address(es) - The advertised foreign agent Care-of Addres(es) provided by this foreign agent. An Agent Advertisement message MUST include at least one Care-of Address if the 'F' bit is set. The length field in the extension determines the number of Care-of-Address(es) present. 4.1.3 One-byte Padding Extension Some IP protocol implementations insist upon padding ICMP messages to an even number of bytes. If the ICMP length of an Agent Advertisement message is odd, this extension MAY be included in order to make the ICMP length even. This extension is NOT intended to be a general purpose extension to be included in order to word or long align the various fields of the Agent Advertisement message. An Agent Advertisement message SHOULD NOT include more than one One-byte Padding Extension, and if present, this extension SHOULD be the last extension in the Agent Advertisement message. Note that unlike other extensions used in Mobile IP, the One-byte Padding Extension is encoded as a single byte, with no "Length" not "Data" field present. Type Type - 0 (One-byte Padding Extension) 4.1.4 Prefix-Lengths Extension The Prefix-Lengths Extension MAY follow the Mobility Agent Advertisement Extension. It is used to indicate the number of bits of network prefix that applies to each Router Address listed in the ICMP Router Advertisement portion of the Agent Advertisement message. Note that the prefix lengths given DO NOT apply to care-of address(es) listed in the Mobility Agent Advertisement Extension. Type Length Prefix Length * Type - 19 (Prefix-Lengths Extension) Page 108 of 138 WO 01/19050 PCT/IBOO/01553 312 * Length - N, where N is the value (possibly zero) of the NUM Addrs field in the ICMP Router Advertisement portion of the Agent Advertisement message. " Prefix Length(s) - The number of leading bits that define the network number of the corresponding Router Address listed in the ICMP Router Advertisement portion of the message. The prefix length for each Router Address is encoded as a separate byte, in the order that the Router Addresses are listed in the ICMP Router Advertisement portion of the message. 4.2 ITS CONTROL EXTENSIONS All of the extensions for ITS Messages have the following format: Code (16) 1 Extension Length (16) Data.... * Code - Defined. * Extension Length - Length of the extension including header fields. * Data - Variable depending upon the extension type. 4.2.1 Authentication Extension The Authentication Extension is used by the ITS to authenticate the requesting message before performing the requested action. " Code - 10, for Authentication Extension type. " Extention Length - TBD * Data - TBD 4.2.2 Flag Extension The Flag Extension is used only if the message type is Add Tunnel Entry. If this Extension is missing, the application should assume that all flags are zero. " Code - 3, for Flag Extension type. " Extension Length - Length is 6 bytes. " Data - Is a 16-bit value with the lower byte contains the flags as defined in RFC 2002 for Registration Request message. 4.2.3 Host NAI Extension The Host NAI Extension is used to let the IPM Tunnel Service (ITS) server know which node a request message comes from. The ITS can maintain the request information Page 109 of 138 WO 01/19050 PCT/IBOO/01553 313 per each requesting node so that it can clean up resources for that requesting node when necessary. (Ex. Requesting node is down abnormally). " Code - 1, for Host NAI Extension type. e Extension Length - Variable. " Data - Contains a Host NAI string. 4.2.4 Lifetime Extension The Lifetime Extension is required for Add Tunnel Entry, Add Tunnel Exit, and Tunnel Forwarding. It is required for ITS to implement the session timeout. " Code - 4, for Lifetime Extension type. " Extension Length - Length is 8 bytes. " Data - Is a 32-bit value. 4.2.5 Mobile Node IP Address Extension The Mobile Node IP Address Extension is required for all messages except Delete all... messages. " Code - 5, for Mobile Node IP Address Extension type. " Extension Length - 8 bytes for Ipv4 and 20 bytes for Ipv6. " Data - Contains the IP address of the MN. 4.2.6 Result Code Extension The Result Code Extension is required for all acknowledgement messages. " Code - 9, for Result Code Extension type. " Extension Length - 6 bytes. * Data - Contains the result code of the previous request message. - 0 = No error. " 1 = TBD, etc. 4.2.7 Tunnel Entry IP Address Extension The Tunnel Entry IP Address Extension is required only for Add Tunnel Entry and Delete Tunnel Entry. * Code - 6, for Tunnel Entry IP Address Extension type. " Extension Length - 8 bytes for Ipv4 and 20 bytes for Ipv6. * Data - Contains the IP address of the Tunnel Entry IP Address. 4.2.8 Tunnel Exit IP Address Extension Page 110 of 138 WO 01/19050 PCT/IBOO/01553 314 The Tunnel Exit IP Address Extension is required only for Add Tunnel Exit, Tunnel Forwarding, and Delete Tunnel Exit. " Code - 7, for Tunnel Exit IP Address Extension type. " Extension Length - 8 bytes for Ipv4 and 20 bytes for Ipv6. " Data - Contains the IP address of the Tunnel Exit IP Address. 4.2.9 Tunnel Forwarding IP Address Extension The Tunnel Forwarding IP Address Extension is only required for Tunnel Forwarding. " Code - 8, for Tunnel Forwarding IP Address Extension type. " Extension Length - 8 bytes for Ipv4 and 20 bytes for Ipv6. " Data - Contains the IP Address of the Tunnel Forwarding IP Address. 4.2.10 User-NAI Extension The User-NAI Extension contains the User NAI string. " Code - 2, for User NAI Extension type. " Extension Length - Variable. " Data - The User-NAI string. 4.3 IPM REGISTRATION EXTENSIONS 4.3.1 ANI-HMM Authentication Extension The ANI-HMM Authentication Extension is used in the Registration messages to carry the Authentication Extension between ANI and HMM. Type (8) Length (8) Sub-Type (8) Rsvd (8) Authenticator (32) e Type - IPMVENDORSPECIFIC__EXTENSION (255) e Length - Length of Authenticator + 2 bytes. * Sub-Type - Sub-type of the extension (6). " Rsvd - Reserved byte. * Authenticator - The authenticator calculated over the entire message up to the extension header. 4.3.2 ANI-SMM Authentication Extension The ANI-SMM Authentication Extension is used in the Registration essages to carry the Authentication Extension between ANI and SMM. Page 111 of 138 WO 01/19050 PCT/IBOO/01553 315 Type (8) Length (8) Sub-Type (8) Rsvd (8) Authenticator " Type - IPM-VENDOR-SPECIFIC-EXTENSION (255). " Length - Length of authenticator + 2 bytes. " Sub-Type - The sub-type of extension (5). " Rsvd - Reserved byte. " Authenticator - The authenticator calculated over the entire message up to the extension header. 4.3.3 L2-Address Extension The L2-Address Extension is used in the Registration Request message to carry the MN's L2 Address. Type (8) Length (8) Sub-Type (8) Address Type (8) Address e Type - IPM-VENDOR-SPECIFIC-EXTENSION (255). * Length - Length of the address + 2 bytes. * Sub-Type - The sub-type of extension (9). " Address Type - The Address-Type of the MN. The current address types are: " 802.3 Address - 802.11 Address - IMSI = MIN " Address - Layer 2 address of the MN. 4.3.4 Local Registration Lifetime Extension The Local Registration Lifetime Extension is used to carry the lifetime of local registration. Type (8) Length (8) Sub-Type (8) Rsvd (8) Lifetime (32) " Type - IMPVENDORSPECIFICEXTENSION (255) e Length - 6 bytes. * Sub-Type - The sub-type of the extension (10). " Rsvd - Reserved byte. * Lifetime - The lifetime allowed by SMM for local re-registration in seconds. Page 112 of 138 WO 01/19050 PCT/IBOO/01553 316 4.3.5 MN-Home Authentication Extension The MN-Home Authentication Extension is used in the Registration messages to carry the Authentication Extension between the MN and Home. Type (8) Length (8) Sub-Type (8) Rsvd (8) Authenticator * Type - IPM-VENDOR-SPECIFIC-EXTENSION (255). " Length - Length of authenticator + 2 bytes. " Sub-Type - The sub-type of extension (3). " Rsvd - Reserved byte. * Authenticator - The authenticator calculated over the entire message up to the extension header. 4.3.6 MN-SMM Authentication Extension The MN-SMM Authentication Extension is used in the Registration message to carry the Authentication Extension between MN and SMM. Type (8) Length (8) Sub-Type (8) Rsvd (8) Authenticator " Type - IPM-VENDOR-SPECIFIC-EXTENSION (255). " Length - Length of Authenticator + 2 bytes. " Sub-Type - The sub-type of extension (4). " Rsvd - Reserved byte. . Authenticator - The authenticator calculated over the entire message up to the extension header. 4.3.7 Foreign-Home Authentication Extension The Foreign-Home Authentication Extension MAY be included in Registration Requests and Reply messages in cases in which a mobility security association exists between the foreign agent and the home agent. Type Length SPI .... ... SPI (cont.) Authenticator ... * Type-34. " Length - 4 plus the number of bytes in the Authenticator. " SPI - Security Parameter Index (4 bytes). An opaque identifier. " Authenticator - Variable length. Page 113 of 138 WO 01/19050 PCT/IBOO/01553 317 4.3.8 Mobile-Foreign Authentication Extension The Mobile-Foreign Authentication Extension MAY be included in Registration Requests and Reply message in cases in which a mobility security association exists between the mobile node and the foreign agent. Type Length SPI .... ... SPI (cont.) Authenticator ... e Type - 33. " Length - 4 plus the number of bytes in the Authenticator. * SPI - Security Parameter Index (4 bytes). An opaque identifier. " Authenticator - Variable length. 4.3.9 Mobile-Home Authentication Extension Exactly one Mobile-Home Authentication Extension MUST be present in all Registration Requests and Registration Reply messages, and is intended to eliminate problems, which can result from the uncontrolled propagation of remote redirects in the Internet. The location of the extension marks the end of the authenticated data. Type Length SPI .... ... SPI (cont.) Authenticator ... " Type-32. " Length - 4 plus the number of bytes in the Authenticator. " SPI - Security Parameter Index (4 bytes). An opaque identifier. " Authenticator - Variable length. 4.3.10 Previous-SMM-NAI Extension The Previous-SMM-NAI Extension is used in the Registration Request message to carry the previous SMM's NA. This extension is not applicable with Registration type of "Initial Registration". Type (8) Length (8) Sub-Type (8) Rsvd (8) SMM-NAI... " Type - IPM-VENDOR-SPECIFIC-EXTENSION (255). " Length - Length of the SMM-NAI string + 2 bytes. " Sub-Type - The sub-type of extension (8). * Rsvd - Reserved byte. * SMM-NAI - The NAI string of the SMM. Page 114 of 138 WO 01/19050 PCT/IBOO/01553 318 4.3.11 Registration-Type Extension The Registration-Type Extension is used in the Registration Request message to indicate what type of registration is requested. Type (8) Length (8) 1 Sub-Type (8) Rsvd (8) Registration-Type (32) e Type - IPM-VENDOR-SPECIFIC-EXTENSION (255). * Length - Length is 6 bytes. * Sub-Type - The sub-type of extension (2). * Rsvd - Reserved byte. * Registration-Type - Registration types. Currently, the types of Registration are: - Initial Registration (0) = De-Registration (1) = System-Change (2) = ANI-Change (3) - Local Re-Registration (4) = Re-Registration (5) - Clean-up (6) 4.3.12 SMM Key Extension The SMM Key Extension is used to carry the shared secret key that is to be used between the SMM and MN. Type (8) Length (8) Sub-Type (8) Rsvd (8) SMM-Key " Type - IMP_VENDORSPECIFICEXTENSION (255) e Length - Length of the SMM Key + 2 bytes. " Sub-Type - The sub-type of the extension (7). " Rsvd - Reserved byte. " SMM Key - The SMM Key, which is encrypted using the MN Home shared secret key. 4.3.13 SMM-NAI Extension The SMM-NAI Extension carries the SMM-NAI in the IPM messages. Type (8) Length (8) 1 Sub-Type (8) Rsvd (8) SMM-NAI... * Type - IMP_VENDORSPECIFICEXTENSION (255) Page 115 of 138 WO 01/19050 PCT/IBOO/01553 319 " Length - Length of the SMM-NAI string + 2 bytes. " Sub-Type - The sub-type of the extension (0). * Rsvd - Reserved byte. " SMM-NAI - The NAI string of the SMM. 4.3.14 User-NAI Extension The User-NAI Extension contains the User NAI string. Type (8) Length (8) User-NAI... * Type - Extension (131). " Length - Length of User-NAI. * User-NAI - The User-NAI string. 4.4 IPM SECURITY EXTENSIONS 4.4.1 Control Message Authentication Request Extension The Control Message Authentication Request Extension is used when Type Sub-Type Payload Length Attribute Values......... " Type - IPMEXT. * Sub-Type: - CNTLMSGAUTHEXT. * Payload Length - Length of all the attributes values. " Attribute Values: The Attributes used in the Control Message Authentication Extension are, * Data Authentication Request Attribute depending upon these variables: " When the Sub-Type is 0, there is no Attribute. - When the Sub-Type is 1, the Data Authentication Request Attribute applies. " When the Sub-Type is 2, the Data Authentication Reply Attribute applies. and can be explained further in the Attribute Section 6. 4.4.2 Control Message Authentication Reply Extension Page 116 of 138 WO 01/19050 PCT/IB00/01553 320 The Control Message Authentication Reply Extension is used when Type I Sub-Type Payload Length Attribute Values......... * Type - IPMEXT.. " Sub-Type: = CNTRLMSGAUTHEXT. " Payload Length - Length of all the attributes values. " Attribute Values: The Attributes used in the Control Message Authentication Extension are, * Data Authentication Reply Attribute depending upon these variables: - When the Sub-Type is 0, there is no Attribute. - When the Sub-Type is 1, the Data Authentication Request Attribute applies. = When the Sub-Type is 2, the Data Authentication Reply Attribute applies. and can be explained further in the Attribute Section 6. 4.4.3 Session Key Allocation Extension The Session Key Allocation Extension is used when allocation of a secret or a public session key is required. The sub-type field value of this extension determines if it is used in the Request or Reply message. Type Sub-Type Payload Length Attribute Values......... " Type - KEYALLOCATION_ EXT. " Sub-Type: " I (Session Key Allocation Request Extension) - 2 (Session Key Allocation Reply Extension, single key allocated) - 3 (Session Key Allocation Reply Extension, duplicate key allocated) " Payload Length - Length of all the attributes values. Page 117 of 138 WO 01/19050 PCT/IBOO/01553 321 e Attribute Values: The Attributes used in the Session Key Allocation Extension are, * Secret Key Request Data Attribute * Single Secret Key Reply Data Attribute " Duplicate Secret Key Reply Data Attribute depending upon these variables: - When the Sub-Type is 1, the Secret Key Request Data Attribute applies. - When the Sub-Type is 2, the Single Secret Key Reply Data Attribute applies. - When the Sub-Type is 3, the Duplicate Secret Key Reply Data Attribute applies. and can be explained further in the Attribute Section 6. 4.4.4 Session Key Delete Extension The Session Key Delete Extension is used when the delete of a secret or public session key is required. Type Sub-Type Payload Length Key ID 0 Key ID N e Type - IPMEXTENSIONS. " Sub-Type - SESSIONKEYDELETE_REQUESTEXT. " Payload Length - 4 + 4 * Number of Keys (octets). * Key ID - The Key ID assigned by the User Authentication Server. 4.4.5 Session Key Lifetime Renewal Extension The Session Key Lifetime Renewal Extension is used when the renewal of a secret or public session key lifetime is required. Also, it is added to the User Service Reply message if the request is honored by the User Authentication Server. Type Sub-Type Payload Length Lifetime 0 Page 118 of 138 WO 01/19050 PCT/IBOO/01553 322 Key ID 0 Lifetime N Key ID N e Type - IPMEXTENSIONS. * Sub-Type - SESSIONKEYLIFETIMERENEWALEXT. * Payload Length - 4 + 8 * Number of Keys (octets). * Lifetime - Required new lifetime for the key. * Key ID - It is the ID for the key to extend his lifetime. 4.4.6 User Authentication Information Extension The User Authentication Information Extension can only be sent in the User Service Request message. It contains all the needed data attributes, which contain the required information about the user for the process of verification and authentication (e.g. SSN, Account Number, etc.). Type Sub-Type Payload Length Data Attributes * Type - USERAUTHINFOEXT. * Sub-Type - 0. " Payload Length - Length of all the attributes values. The Attributes used in the User Authentication Information Extension are, e Account Number Data Attribute e SSN Data Attribute (Optional) * User Name Data Attribute (Recommended) e User Birthday Data Attribute (Recommended) * User Password Data Attribute (Optional) * User Address Data Attribute (Optional) * User Home Phone Number Data Attribute (Optional) " User Work Phone Number Data Attribute (Optional) " User NAI Data Attribute (Recommended) e User PIN Number Data Attribute (Optional) * Digital Signature Data Attribute (Recommended) and can be explained further in the Attribute Section 6. Page 119 of 138 WO 01/19050 PCT/IBOO/01553 323 5. AVPS AVPs is a method of encapsulating information relevant to the DIAMETER message. DIAMETER AVPs carry specific authentication, accounting and authorization information, security information as well as configuration details for the request and reply messages. The AVP format is shown below and MUST be sent in network byte order. AVP Code AVP Length Reserved P T V IR M Vendor ID (Optional) Tag (Optional) Data... (depends on the particular AVP) e AVP Code - The AVP Code identifies the attribute uniquely. " AVP Length - The AVP Length field is two octets, and indicates the length of this attribute including the AVP Code, AVP Length, AVP Flags, Reserved, The Tag and Vendor ID fields if present and the AVP data. " AVP Flags - The AVP Flags field informs the DIAMETER host how each attribute must be handled. - "R" bit and Reserved Bit - Are used and should be set to 0 and ignored on receipt, while the "P" bit is defined. - "M" bit - Known as the mandatory bit, indicates whether support of the AVP is required. - "V" bit - Known as the Vendor-Specific bit, indicates whether the optional Vendor ID field is present in the AVP header. - "T" bit - Known as the Tag bit, is used to group sets of AVPs together. Grouping AVPs is necessary when more than one AVP is needed to express a condition. " Vendor ID - The Vendor ID field is present in the "V" bit and is set in the AVP Flags field. " Tag - The Tag field is four octet in length and is intended to provide a means of grouping attributes in the same message which refer to the same set. If the Tag field is unused, the "T" bit MUST NOT be set. " Data - The Data field is zero or more octets and contains information specific to the attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the value field MAY be one of seven data types. Page 120 of 138 WO 01/19050 PCT/IBOO/01553 324 m Data - The data contains a variable length of arbitrary data. Unless otherwise noted, the AVP Length field MUST be set to at least 9. - String - The data contains a non-NULL terminated variable length string using the UTF-8 [24] character set. Unless otherwise noted, the AVP Length field MUST be set to at least 9. = Address - 32 bit (Ipv4) [17] or 128 bit (Ipv6) [16] address, most significant octet first. The format of the address (Ipv4 or Ipv6) is determined by the length. If the attribute value is an Ipv4 address, the AVP Length field MUST be 12, otherwise the AVP Length field MUST be set to 24 for Ipv6 addresses. " Integer32 - 32-bit value, in network byte order. The AVP Length field MUST be set to 12. " Integer64 - 64-bit value, in network byte order. The AVP Length field MUST be set to 16. - Time - 32-bit unsigned value, in network byte order, and contains the seconds since 00:00:00 GMT, January 1, 1900. The AVP Length field MUST be set to 12. " Complex - The complex data type is reserved for AVPs that includes multiple information fields, and therefore do not fit within any of the AVP types defined above. Complex AVPs MUST provide the data format, and the expected length of the AVP. 5.1 COMMAND-CODE AVP The Command-Code AVP MUST be the first AVP following the DIAMETER header. A DIAMETER message MUST have at most one Command-Code AVP, and it is used in order to communicate the command associated with the message. " Code -256 * Type - Integer32 5.2 DESTINATION-NAI AVP This AVP is used to carry the NAI of the destination. o Code -269 * Type - String 5.3 HOME-AGENT-ADDRESS AVP This AVP contains the MN's Home Agent Address. * Code - 334 * Type - Address Page 121 of 138 WO 01/19050 PCT/IBOO/01553 325 5.4 HOST-NAME AVP The Host-Name AVP is used to inform a DIAMETER peer of the sender's identity. All DIAMETER messages MUST include the Host-Name AVP, which contains the host name of the originator of the DIAMETER message that MUST follow the NAI naming conventions. * Code - 32 * Type - String 5.5 IPM-CARE-OF-ADDRESS AVP This AVP is used to carry the MN's Care-of-Address. * Code - 362 " Type - Address 5.6 IPM-CLIENT-ADDRESS AVP This AVP is used to carry the MN's IP Address, either Static or Dynamic. * Code - 360 * Type - Address 5.7 IPM-CONTEXT-DATA AVP This AVP carries the Context Data of the User at previous SMM. The complex data could contain AVP format data. The Context-Data could potentially carry the QOS information that MN was receiving at previous SMM. . Code - 373 " Type - Data 5.8 IPM-CONTEXT-REQUEST-TYPE AVP This AVP carries the Context requested by the SMM. * Code - 372 " Type- Integer32 These carry the current types of various Context Requests. - Context-Request (0) - Context-Request with IP-Forwarding (1) - Context-Request with IP-Buffering (2) 5.9 IPM-HMM-NAI AVP Page 122 of 138 WO 01/19050 PCT/IBOO/01553 326 This AVP is used to carry the HMM's NAI. * Code -364 * Type - String 5.10 IPM-L2-ADDRESS AVP This AVP carries the L2-Address of IPM Client connection. The AVP carries both the types of Address and Data. " Code-374 e Type - Data These are the current types supported. - 802.3 Address (0) - 802.11 Address (1) - IMSI (2) - MIN (3) 5.11 IPM-PROFILE AVP This AVP carries the Profile of the User, who is registering. The complex data could contain AVP format data. " Code - 371 e Type - Data 5.12 IPM-PROFILE-TYPE AVP This AVP carries the user Profile requested by SMM with the IRR message. * Code - 370 * Type - Integer32 The current Profile types are: - Partial (0) - Minimal Profile required. - Full (1) - Complete Profile of the user. 5.13 IPM-REGISTRATION-CANCELLATION-REASON AVP This AVP carries the reason for the Registration Cancellation message being sent by MNN to SMM. Page 123 of 138 WO 01/19050 PCT/IBOO/01553 327 " Code - 375 " Type - Integer32 5.14 IPM-REGISTRATION-REPLY AVP This AVP carries IPM Registration-Reply message received from the HMM to SMM. " Code - 367 * Type - Data 5.15 IPM-REGISTRATION-REQUEST AVP This AVP carries either complete or partial IPM-Registration Request message received from the MN. " Code - 366 " Type - Data 5.16 IPM-REGISTRATION-RESPONSE-CODE AVP This AVP carries the Registration-Response-Code. * Code -368 * Type - Integer32 5.17 IPM-REGISTRATION-TYPE AVP This AVP is used to carry the type of Registration. " Code - 361 " Type - Integer32 These are the current values supported: - Initial Registration (0) - De-Registration (1) - System-Change (2) - ANI-Change (3) " Local Re-Registration (4) - Re-Registration (5) " Clean-Up (6) - Location-Update (7) - Admin-Initiated-Clean-Up (8) 5.18 IPM-ROUTING-AREA-NAI AVP Page 124 of 138 WO 01/19050 PCT/IBOO/01553 328 This AVP carries the ANI's NAI, where the MN is currently registered. 0 Code-365 * Type - String 5.19 IPM-SMM-MN-KEY AVP This AVP carries the shared secret key between SMM and MN. This key is only valid for the session. " Code - 376 * Type - Data 5.20 IPM-SMM-NAI AVP This AVP carries the SMM's NAI. " Code - 363 * Type - String 5.21 IPM-TERMINAL-TYPE AVP This AVP carries the Terminal Type of MN. " Code -369 e Type - Integer32 These are the current Terminal-Types supported. * 802.3 Type Terminal (1) * 802.11 Type Terminal (1) * IS91 Type Terminal (2) * IS36 Type Terminal (3) * IS96 Type Terminal (4) * Modem (5) * Unknown Terminal (#ffffffff) 5.22 INTEGRITY-CHECK-VALUE AVP The Integrity-Check-Value AVP is used for hop-by-hop message authentication and integrity. " Code -259 " Type - Complex 5.23 NONCE AVP Page 125 of 138 WO 01/19050 PCT/IBOO/01553 329 The Nonce AVP MUST be present prior to the Integrity-Check-Value AVPs within a message and is used to ensure randomness within a message. * Code -261 * Type - Data 5.24 PROXY-STATE AVP The Proxy-State AVP is used by proxy servers when forwarding requests and contains opaque data that is used by the proxy to further process the response. * Code-33 " Type - Address 5.25 RESULT-CODE AVP The Result-Code AVP indicates whether a particular request was completed successfully or whether an error occurred. 0 Code -268 * Type - Complex 5.26 TIMESTAMP AVP The Timestamp AVP is used to add replay protection to the DIAMETER protocol. This AVP MSUT appear prior to the Integrity-Check-Value AVP or any other message integrity AVP defined in separate extensions. " Code -262 " Type - Time 5.27 USER-NAME AVP The User-Name AVP contains the User-Name in a format consistent with the NAI specification. All DIAMETER systems SHOULD support usernames of at least 72 octets in length. " Code - 1 * Type - String Page 126 of 138 WO 01/19050 PCT/IBOO/01553 330 Page 127 of 138 WO 01/19050 PCT/IBOO/01553 331 6. ATTRIBUTES Data Attribute is a payload for extensions. The format of the Data Attributes provides the flexibility for representation of many different types of information. There can be multiple Data Attributes within any extension payload. The length of Data Attributes will either be 2 octets or defined by the payload length field. Attr Type AF Sub-Type Payload Length Attribute Value AF = 0 TLV; AF = 1 TV * Attr Type (1 octet) - Unique identifier for each type of attribute. * Sub-Type ( 1 octet) - Defines the attribute sub-type. * AF Bit - Attribute format indicates whether the data attribute follows the type Type/Value (TV) format (AF=1) or follows the Type/Length/Value (TLV) format (AF=O). * Payload Length (2 octets) - Length in octets of the attribute value. When the AF bit is 1, the attribute value is 2 octets and payload length field is not present. * Attribute Value (Variable Length) - It is the value of the attribute. If the AF bit is 0, this field has a variable length defined by the payload length field. If the AF is 1, the attribute value has a length of 2 octets. 6.1 ACCOUNT NUMBER DATA ATTRIBUTE The Account Number Data Attribute defines the User's account number assigned by the ISP. Attr Type = 1 AF Sub-Type Payload Length = 4 Account Number Value e AF - 0. " Attr Type - 1. " Sub-Type - The following sub-types are defined for this attribute: - 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. " 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - 4. " Account Number Value - It is the value of the account number. Page 128 of 138 WO 01/19050 PCT/IBOO/01553 332 6.2 DATA AUTHENTICATION REPLY ATTRIBUTE The Data Authentication Reply Attribute carries the authenticator, which is the result of running the hash function on the authentication data provided in the Data Authentication Request Attribute. Attr Type =24 AF Sub-Type Payload Length Authenticator Data.......... * AF - 0. * Attr Type - 24. * Sub-Type - The following sub-types are defined for this attribute: - 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. * Payload Length - Variable. * Authenticator Data - It is the data resulted from running the hash function on the authentication data provided by the Data Authentication Request Attribute. 6.3 DATA AUTHENTICATION REQUEST ATTRIBUTE The Data Authentication Request Attribute is used to carry the data, which needs to be authenticated by the IPM Security Center by running the hash function on this data. Attr Type =23 1 AF Sub-Type Payload Length Authentication Data.......... * AF-0. * Attr Type - 23. * Sub-Type - The following sub-types are defined for this attribute: - 0, The default sub-type, the value is sent in clear. = 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. = 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. Page 129 of 138 WO 01/19050 PCT/IBOO/01553 333 = 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - Variable. " Authentication Data - It is the control message data, which needs to be authenticated by the IPM Security Center by running the hash function on this data. 6.4 DIGITAL SIGNATURE DATA ATTRIBUTE The Digital Signature Data Attribute defines the User's Digital Signature, which is created by running a hash function H (e.g. MD5) over a message fragment. This Attribute should be encrypted using the full secret key between the MN and its home domain or the private key for the MN. Attr Type = 11 AF Sub-Type Payload Length Digital Signature Value.......... * AF - 0. " Attr Type - 11. " Sub-Type - The following sub-types are defined for this attribute: a 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - Variable. " Digital Signature Value - Is a sequence of bytes generated from running a hash function over all the attribute's payload for the User Authentication Information Extension. 6.5 DUPLICATE SECRET KEY REPLY DATA ATTRIBUTE The Duplicate Secret Key Reply Data Attribute carries the session key information, which is allocated by IPM Security Center. Another encrypted copy is generated and sent in conjunction with the original one. This attribute can be included in the Session Key Allocation Extension when the extension sub-type field value is 3. Attr Type = | AF Sub-Type Payload Length Page 130 of 138 WO 01/19050 PCT/IBOO/01553 334 22 Rsv Rn Key Length rsv Liftetime Key ID SPI Key Data............ Encrypted Deuplicate Key Data........... " Attr Type -22 " AF - 0 e Sub-Type - The following types are defined: N 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides only data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. . * Payload Length (2 octets) - It is 8 + SPI length + key data length. * Lifetime - It is the key lifetime. After a lifetime expires the same key might be reassigned to somebody else. * SPI (4 octets) - It is the Security Parameter Index. This SPI in conjunction with the generated key will be used to define a security association between two entities (e.g. MN and HMM, MN and SMM). * Key ID (4 octets) - It is the key unique identifier issued by the IPM Security Center. " Key Data (Variable) - It is the secret key generated by the IPM Security Center. " Encrypted Duplicate Key Data - A copy from the key data encrypted by the method defined by the sub-type field. 6.6 SSN DATA ATTRIBUTE The SSN Data Attribute defines the User's SSN. Attr Type = 2 AF Sub-Type Payload Length = 4 SSN Value " AF-0. * Attr Type -2. " Sub-Type - The following sub-types are defined for this attribute: = 0, The default sub-type, the value is sent in clear. Page 131 of 138 WO 01/19050 PCT/IBOO/01553 335 - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. * Payload Length - 4. " SSN Value - The value of the SSN. 6.7 SECRET KEY REQUEST DATA ATTRIBUTE The Secret Key Request Data Attribute is used to request a dynamically allocated session secret key with a specific length from the IPM Security Center. The Session Key Allocation Request Extension MAY have multiple Secret Key Request Data Attributes. Attr Type = 20 1AF Sub-Type Key Length ET rn * Attr Type -20 * AF - 1 * Sub-Type - The following types are defined: * 0, A single key will be allocated and encrypted using the Encryption type. * 1, A single key is allocated and duplicated. The duplicate will be encrypted by the encryption method defined by the Encryption Type field. * Encryption Type (ET) - The following Encryption Types are defined: - 0, The default sub-sype, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides only data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provided data confidentiality and digital signature. * Key Length - Length of the key needed to be allocated. * rn - It is a number from 1 to 15 which distinguishes between the different key allocation requests issued to the IPM Security Center. The issuer of the request will use the rn to match the key allocation request with the Key Allocation Reply. Page 132 of 138 WO 01/19050 PCT/IBOO/01553 336 6.8 SINGLE SECRET KEY REPLY DATA ATTRIBUTE The Single Secret Key Reply Data Attribute carries the session key information, which is allocated by the IPM Security Center. This attribute is carried by the Session Key Allocation Extension when the extension Sub-Type value is 2. Attr Type = 21 AF Sub-Type Payload Length Rsv Rn Key Length rsv Liftetime Key ID SPI Key Data............ * Attr Type - 21 * AF - 0 * Sub-Type - The following types are defined: M 0, The default Sub-Type, the value is sent in clear. m 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides only data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. . " Payload Length (2 octets) - It is 8 + SPI length + key data length. * Lifetime (4octets) - It is the key lifetime. * SPI (4 octets) - It is the Security Parameter Index. This SPI in conjunction with the generated key will be used to define a security association between two entities (e.g. MN and HMM, MN and SMM). " Key ID (4 octets) - It is the key unique identifier issued by the IPM Security Center. " Key Data (Variable) - It is the secret key generated by the IPM Security Center. 6.9 USER ADDRESS DATA ATTRIBUTE The User Address Data Attribute defines the User's current address. Attr Type = 6 AF Sub-Type I Payload Length User Address Value.......... " AF-0. " Attr Type - 6. " Sub-Type - The following sub-types are defined for this attribute: Page 133 of 138 WO 01/19050 PCT/IBOO/01553 337 - 0, The default sub-type, the value is sent in clear. " 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - Variable. * User Address Value - This field contains a string of the following format: User Address::= country +(" ") State +(" ") city +(" ") Street [+(" ") aptn] country::= "cny" "=" String state::= "ste" "=" String city::= "cty" "=" String street::= "str" "=" String aptn::= "apt" "=" String 6.10 USER BIRTHDAY DATA ATTRIBUTE The User Birthday Data Attribute defines the User's birthday. Attr Type= 4 AF Sub-Type Payload Length User Birthday Value.......... " AF - 0. " Attr Type - 4. " Sub-Type - The following sub-types are defined for this attribute: - 0, The default sub-type, the value is sent in clear. a 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. " 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - Variable. " User Birthday Value - This field contains a string of the following format: User Birthday ::= month +(" ") day + (" ")+ year Page 134 of 138 WO 01/19050 PCT/IBOO/01553 338 Month ::= "mth" "=" String Day ::= "day" "=" String Year ::= "yer" "" String Example: mt=07 day=09 yer=1966 6.11 USER HOME PHONE NUMBER DATA ATTRIBUTE The User Home Phone Number Data Attribute defines the User's home phone number. Attr Type = 7 AF Sub-Type Payload Length User Home Phone Number.......... " AF - 0. " Attr Type - 7. " Sub-Type - The following sub-sypes are defined for this attribute: - 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - Variable. " User Home Phone Number - This field contains a string representing the user phone number. Example: 972-685-1234 6.12 USER NAI DATA ATTRIBUTE The User NAI Data Attribute defines the User Network Access Identifier. Attr Type = 9 AF Sub-Type Payload Length NAI...... * AF - 0. " Attr Type - 9. " Sub-Type - The following sub-types are defined for this attribute: - 0, The default sub-type, the value is sent in clear. Page 135 of 138 WO 01/19050 PCT/IBOO/01553 339 - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. * Payload Length - Variable. " User NAI - This field contains a string representing the User Network Access Identifier. Example: mkhalil@nortelnetworks.com 6.13 USER NAME DATA ATTRIBUTE The User Name Data Attribute defines the User's full name. Attr Type= 3 AF Sub-Type I Payload Length User Name Value ........... * AF - 0. . Attr Type - 3. * Sub-Type - The following sub-types are defined for this attribute: - 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the full secret key between the user and its home domain. This type of encryption provides data confidentiality - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - Variable. * User Name Value - This field contains a string of the following format: UserName ::= lastname +(" ") first-name +(" ") mid-name Lastname ::= LASTNAME "=" String First _name ::= FIRSTNAME "=" String midname ::= MIDNAME "=" String LAST NAME ::= "In" FIRST NAME ::= "fn" mid name ::= "m" Page 136 of 138 WO 01/19050 PCT/IB00/01553 340 6.14 USER PASSWORD DATA ATTRIBUTE The User Password Data Attribute defines the User's password. Attr Type =5 AF Sub-Type Payload Length Password Value.......... " AF - 0. * Attr Type - 5. * Sub-Type - The following sub-types are defined for this attribute: - 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. - 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. * Payload Length - Variable. * Password Value - The string which represents the User's password. 6.15 USER PIN NUMBER DATA ATTRIBUTE It is an integer value selected by the user to secure access to his account This Attribute MAY be included with User Authentication Information Extension. Attr Type =10 AF Sub-Type I Payload Length User PIN Number.......... SAF - 0. * Attr Type - 10. * Sub-Type - The following sub-types are defined for this attribute: 0 0, The default sub-type, the value is sent in clear. 8 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. E 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. E 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. * Payload Length - 4 octets. Page 137 of 138 WO 01/19050 PCT/IBOO/01553 341 e User PIN Number - This field contains a string representing the User PIN number. Example: 1234abcd567 6.16 USER WORK PHONE NUMBER DATA ATTRIBUTE The User Work Phone Number Data Attribute defines the User's work phone number. One or more of these Attributes may be included with the User Authentication Information Extension. Attr Type =8 AF Sub-Type Payload Length User Work Phone Number.......... * AF - 0. * Attr Type - 8. * Sub-Type - The following sub-types are defined for this attribute: N 0, The default sub-type, the value is sent in clear. - 1, Secret key encryption using the shared secret key between the user and its home domain. This type of encryption provides data confidentiality. - 2, Public key encryption using the user's private key. This type of encryption provides data confidentiality and digital signature. = 3, Public key encryption using the home domain public key. This type of encryption provides data confidentiality. " Payload Length - Variable. * User Work Phone Number - This field contains a string representing the User work phone number. Example: 972-685-1234 Page 138 of 138

Claims

1. A communications architecture configured to enable IP-based mobile communications comprising: a) at least one Local Service Function (LSF) 5 component configured to serve as an IP-based serving area network for a group of x-Access Networks (xANs); b) at least one Network Service Function (NSF) component connected in communication with the LSF and configured to serve as an IP-based home network by 10 managing a mobile node's (MN's) subscription and associated profile so that the MN is authorized to use the resources of the LSF; and c) at least one xAN connected in communication with the LSF for providing heterogeneous Layer 2 access 15 for MNs irrespective of access technology.

2. The architecture of Claim 1 wherein the xAN comprises at least one of a wireless network and a wireline network.

3. The architecture of Claim 1 further comprising 20 an Internet Protocol (IP) network for routing packets between the LSF, NSF, and xAN.

4. The architecture of Claim 1 further comprising an Internet Protocol (IP) network for routing packets between the LSF, NSF, and xAN, wherein the IP network is 25 a public Internet. WO 01/19050 PCT/IBOO/01553 343

5. The architecture of Claim 1 further comprising an Internet Protocol (IP) network for routing packets between the LSF, NSF, and xAN, wherein the IP network is a closed network that can access the public Internet. 5

6. The architecture of Claim 1 wherein the LSF, NSF, and xAN are enabled for using Authentication, Authorization, and Accounting (AAA) protocols for effecting IP-based mobile communications.

7. The architecture of Claim 1 wherein the LSF and 10 NSF further comprise security messaging gateways for securing the communication links between the xAN, LSF, and NSF.

8. The architecture of Claim 1 wherein at least one of the LSF and the NSF further comprise directory 15 services that comprise at least one of unified user profiles, network usage policies, security policies, and information related to availability and location of services.

9. The architecture of Claim 1 wherein the LSF and 20 NSF are configured for executing policy management services for at least one of configuration management, security, and quality of service (QoS).

10. The architecture of Claim 1 wherein the NSF is effective for executing domain name services (DDNS) for 25 resolving address conflicts. WO 01/19050 PCT/IBOO/01553 344

11. The architecture of Claim 1 wherein the NSF is effective for executing Dynamic Host Configuration Services (DHCS) for allocating network resources.

12. A method for allocating an IP address, 5 comprising the steps performed by a Domain Name Server (DNS) of: a) receiving from a Mobility Manager a message to store a Care-Of Address (COA) of a Mobile Node (MN) identified by a particular Network Access Identifier 10 (NAI); b) storing the COA of the MN in a look-up table; c) receiving a message from a correspondent node (CN) requesting the COA of the MN identified by the NAI; d) looking up in the look-up table the COA of the MN 15 identified by the NAI; and e) transmitting the COA of the MN to the CN.

13. The method of Claim 12, wherein the DNS constitutes a component of a Network Service Function (NSF), and the mobility manager is a home mobility 20 manager (HMM) of the NSF.

14. The method of Claim 12, wherein the DNS constitutes a component of a Local Service Function (LSF), and the mobility manager is a serving mobility manager (SMM) of the LSF. 25

15. A method for allocating an IP address, comprising the steps performed by a Correspondent Node (CN) of: WO 01/19050 PCT/IBOO/01553 345 a) sending a message to a Domain Name Server (DNS) requesting the Care-Of Address (COA) of a Mobile Node (MN) ; and b) receiving from the DNS the COA of the MN. 5

16. The method of Claim 15, wherein the DNS constitutes a component of a Network Service Function (NSF).

17. The method of Claim 15, wherein the DNS constitutes a component of a Local Service Function 10 (LSF).

18. A method for allocating an IP address, comprising the steps performed by a Domain Name Server (DNS) at a Local Serving Function (LSF) of: a) receiving a message from a serving mobility 15 manager (SMM) to store the IP address of a DNS at a Network Serving Function (NSF) against a user's Network Access Identifier (NAI) in a look-up table; b) storing in a look-up table the IP Address of the NSF DNS against the user's NAI; 20 c) receiving a message from a correspondent node (CN) requesting a COA of an MN identified by the particular NAI; d) looking up the IP address of the NSF DNS; e) requesting the COA of the MN from the NSF DNS at 25 the IP address; f) receiving the COA of the MN from the NSF DNS; and g) transmitting the COA of the MN to the CN. WO 01/19050 PCT/IBOO/01553 346

19. A method for allocating an IP address, comprising the steps performed by a Domain Name Server (DNS) at a Network Serving Function (NSF) of: a) receiving a message from a home mobility manager 5 (HMM) to store the IP address of a DNS at a Local Serving Function (LSF) against a user's Network Access Identifier (NAI) in a look-up table; b) storing in a look-up table the IP Address of the NSF DNS against a user's NAI; 10 c) receiving a message from a correspondent node (CN) requesting a COA of an MN identified by the NAI; d) looking up the IP address of the LSF DNS; e) requesting the COA of the MN from the LSF DNS at the IP address; 15 f) receiving the COA of the MN from the LSF DNS; and g) transmitting the COA of the MN to the CN.

20. A system for allocating addresses, comprising: a) Network Service Function (NSF) having a bus connected to an IP Network for receiving address 20 requests; b) a Dynamic Host Configuration Protocol (DHCP) connected to the bus, the DHCP including computer program code executable by the DHCP for determining an address; c) a Dynamic Domain Name Services (DDNS) connected to 25 the bus, the DDNS including computer program code executable by the DDNS for identifying addresses; and d) a Home Mobility Manager (HMM) connected to the bus. WO 01/19050 PCT/IBOO/01553 347

21. A Unified Directory Service (UDS) architecture configured for serving an IP mobility communications architecture, the UDS comprising: a) a Home Control and Data Manager (HCDM) connected 5 to a Network Service Function (NSF) bus, the HMM comprising: an Access Network Interface (ANI) configured for enabling the MN to discover and distinguish an IPM Network to a sub-network level, and for replying 10 to a discovery request from an MN, wherein the IPM network is one of a Local Service Function (LSF) or a Network Service Function (NSF), and wherein the discovery request comprises at least one of an SMM IP address, an SMM NAI, support for available 15 security protocols, and support for local HMM; a Home Mobility Manager (HMM) configured for receiving an IP Address allocated by a DHCP, assigning the allocated IP address to the MN, authenticating the user (AAA), and updating the UDS 20 with a user's mobility related information; and an IP Mobility (IPM) Tunnel Service (ITS) for providing tunneling and de-tunneling; b) a UDS Function connectable to the NSF bus for storing static and dynamic information about a user and 25 making the information available to any application that interfaces with the UDS; c) at least one database connected to the UDS Function via the NSF bus, the database being configured for storing an Internet Protocol Mobility (IPM) user 30 profile comprising at least the COA of the devices used by the user, the type of devices used by the user, the WO 01/19050 PCT/IBOO/01553 348 status of the devices at any time, the LSF information that any device is connected to, the user's preference between the devices registered at any time.

22. The UDS of Claim 21 further comprising computer 5 program code for sending data selected from the user profile to a visited network.

23. The UDS of Claim 21, wherein ITS further comprises computer program code for providing at least one of a proxy Address Resolution Protocol (ARP), a 10 gratutitous ARP, and forwarding of data.

24. The UDS of Claim 21 wherein the local HMM is a HMM function located at the LSF that provides a subset of HMM functions.

25. The UDS of Claim 21, wherein the mobility 15 related information includes at least one of the COA of an MN, the NAI of the LSF, and the GPS coordinates of the MN.

26. The UDS of Claim 21, wherein the HMM further comprises at least one of: 20 computer program code for managing the lease of the IP address; computer program code for querying the UDS to check the service validation of the user computer program code for interfacing with an AAA 25 function to authenticate the user WO 01/19050 PCT/IBOO/01553 349 computer program code for retrieving user profiles, defining QoS and policy related information to be used by non-IPM components, including at least one of the QoS manager, the Policy Enforcement Point (PEP), and Policy 5 Decision Point (PDP) of the home network or by the serving network; and computer program code for de-registering an MN to allow resources, including the IP Address, to be re claimed. 10

27. The UDS of Claim 21, wherein the HMM further comprises at least one of: a) computer program code for managing the lease of the IP address; b) computer program code for querying the UDS to 15 check the service validation of the user c) computer program code for interfacing with an AAA function to authenticate the user d) computer program code for retrieving user profiles to be used by non-IPM components of the home network or 20 by the serving network; and e) computer program code for de-registering an MN to allow resources to be re-claimed.

28. The UDS of Claim 21 wherein the IPM user profile comprises a plurality of object classes including 25 an ipmUser object class, an ipmUserProfile object class, an ipmUserDevice object class, and an ipmClassOfService object class. WO 01/19050 PCT/IB00/01553 350

29. The UDS of Claim 21 wherein the IPM user profile comprises a user name, a mobile node address, a class of service, an account number, and a care of address. 5

30. The UDS of Claim 21 wherein the UDS is a home UDS, and the NSF is a home NSF, and the home UDS further comprises an interface connectable to a visited NSF having a visited UDS configured for transmitting to the server of the home UDS a Registration Request message 10 requesting the IPM user profile of a user subscribed to the home NSF to permit the user to access services provided by the visited NSF.

31. The UDS of Claim 21 wherein the UDS is a home UDS, and the NSF is a home NSF, and the home UDS further 15 comprises: a) an interface connectable to a visited NSF having a visited UDS configured for transmitting to the server of the home UDS a Registration Request message requesting the IPM user profile of a user subscribed to the home NSF 20 to enable the user to access services provided by the visited NSF; and b) computer program code responsive to receipt of the Registration Request message for retrieving the user profile and transmitting the user profile in a 25 Registration Reply message to the visited NSF.

32. The UDS of Claim 21 wherein the UDS is a home UDS, and the NSF is a home NSF, and the home UDS further comprises: WO 01/19050 PCT/IBOO/01553 351 a) an interface connectable to a visited NSF having a visited UDS configured for using an Authentication, Authorization, and Accounting (AAA) protocol to transmit to the server of the home UDS a Registration Request 5 message requesting the IPM user profile of a user subscribed to the home NSF to enable the user to access services provided by the visited NSF; and b) computer program code responsive to receipt of the Registration Request message for retrieving the user 10 profile and using the AAA protocol to transmit the user profile in a Registration Reply message over the interface to the visited NSF.

33. .The UDS of Claim 21 wherein the UDS is a home UDS, and the NSF is a home NSF, and the home UDS further 15 comprises: a) an interface connectable to a visited NSF having a visited UDS configured for using Diamond Authentication, Authorization, and Accounting (AAA) protocol to transmit to the server of the home UDS a Registration Request 20 message requesting the IPM user profile of a user subscribed to the home NSF to enable the user to access services provided by the visited NSF; and computer program code responsive to receipt of the Registration Request message for retrieving the user 25 profile and using the Diamond AAA protocol to transmit the user profile in a Registration Reply message over the interface to the visited NSF. WO 01/19050 PCT/IBOO/01553 352

34. A Unified Directory Service (UDS) schema for a database configured to store information about a user of an IP-based mobile communications architecture, the schema comprising: 5 a) an ipmUser object class for storing information about the user, which information is required for services a user is subscribed to; b) one or more ipmUserProfile object classes related in the database to the ipmUser object class for storing 10 information selected from the ipmUser object class which is required for each service to which a user is subscribed; c) zero or more ipmUserDevice object classes related in the database to the ipmUser object class and to the 15 ipmUserProfile object class for storing information about each device through which a user is authorized to communicate with a network; d) one or more ipmClassOfService object classes related in the database to the ipmUserProfile object 20 class for storing information about the class of service a user is entitled to receive for each service the user is subscribed to; e) one or more ipmLsfDomain object classes related in the database to the ipmClassOfService object class for 25 storing information about a serving network through which a user is contemporaneiously accessing; f) one or more ipmLsfSubnet object classes related in the database to the ipmLsfDomain object class for storing the IP address of a subnetwork that a user is 30 contemporaneously accessing; WO 01/19050 PCT/IBOO/01553 353 g) one or more ipmNsfSubnet object classes related in the database to the ipmUser object class for storing information about an IP subnetwork at a user's home network; and 5 h) an ipmNsfDomain object class related in the database to the ipmNsfSubnet object class for storing information about a user's home network.

35. The UDS schema of Claim 34 wherein the ipmUser object class comprises 10

36. The UDS schema of Claim 34 wherein the IPM user profile comprises a plurality of object classes including an ipmUser object class, an ipmUserProfile object class, an ipmUserDevice object class, and an ipmClassOfService object class. 15

37. The UDS schema of Claim 34 wherein the IPM user profile comprises a user name, a mobile node address, a class of service, an account number, and a care of address.

38. A method for any Access Network (xAN) to 20 provide an interface between a Mobile Node (MN) and a Local Service Function (LSF), comprising the following steps performed by the xAN: a) receiving a message from the MN to initiate an OSI Layer 2 session with an access network; 25 b) terminating the L2 session between the MN and the access network; WO 01/19050 PCT/IBOO/01553 354 c) sending notification of OSI Layer 2 termination to the Mobile Node; d) receiving an xAN resource management request from the LSF; 5 e) managing xAN resources as requested by the LSF; and f) notifying the LSF that all resouce management is complete.

39. The method of Claim 38, wherein the step of 10 terminating further comprises terminating the L2 protocol and permitting the MN to initate L3 IPM messaging with the LSF components.

40. The method of Claim 38, wherein the step of sending notification further comprises providing the MN 15 with at least the SMM IP address and SMM NAI to access the LSF so that the MN may communicate directly with the LSF.

41. The method of Claim 38, wherein the step of managing xAN resources further comprises: 20 a) mapping L2 and L3 addresses; b) allocating computing resources for buffering data packets destined for the MN; c) forwarding the data packets to a second LSF when the MN moves from a first LSF to the second LSF; 25 d) detecting L2 movement of the MN from the first LSF to the second LSF; e) translating L2 movement of the MN from the first LSF to the second LSF into L3; and WO 01/19050 PCT/IBOO/01553 355 f) re-claiming the computing and routing resources when not used by the MN.

42. A method for providing IP-connectivity between a Mobile Node (MN) and a Local Service Function (LSF), 5 comprising the following steps performed by the LSF: a) receiving a first message from the MN to initiate an IPM session with the LSF; b) establishing an IPM OSI Layer 3 (L3) session with the MN; 10 c) sending an IPM first message to a Network Service Function (NSF) to initiate an IPM OSI L3 session between the MN and the LSF; d) receiving from the NSF one or more IPM messages that are destined for the MN; 15 e) generate resource management request to the xAN; f) receive notification from the xAN that resource management is complete; and sending said one or more IPM messages generated by NSF to the MN.