idnits 2.17.1 draft-itsumo-hmmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 29) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 44 instances of too long lines in the document, the longest one being 71 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 570: '... that the mobile SHALL always be authe...' RFC 2119 keyword, line 688: '...e SIP user agent SHALL be augmented wi...' RFC 2119 keyword, line 780: '...eously, the DHCP SHALL update the DNS ...' RFC 2119 keyword, line 794: '... - The DHCP SHALL interact with the ...' RFC 2119 keyword, line 795: '... SIP INFO method SHALL be able to conv...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1145 has weird spacing: '...ader of recei...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 81 looks like a reference -- Missing reference section? '2' on line 81 looks like a reference -- Missing reference section? '3' on line 199 looks like a reference -- Missing reference section? '6' on line 97 looks like a reference -- Missing reference section? '4' on line 101 looks like a reference -- Missing reference section? '5' on line 101 looks like a reference -- Missing reference section? '7' on line 104 looks like a reference -- Missing reference section? '8' on line 104 looks like a reference -- Missing reference section? '9' on line 294 looks like a reference -- Missing reference section? '10' on line 294 looks like a reference -- Missing reference section? '14' on line 488 looks like a reference -- Missing reference section? '16' on line 587 looks like a reference -- Missing reference section? '21' on line 499 looks like a reference -- Missing reference section? '22' on line 500 looks like a reference -- Missing reference section? '13' on line 836 looks like a reference -- Missing reference section? '17' on line 675 looks like a reference -- Missing reference section? '18' on line 675 looks like a reference -- Missing reference section? '19' on line 1013 looks like a reference -- Missing reference section? '20' on line 1013 looks like a reference -- Missing reference section? '11' on line 763 looks like a reference -- Missing reference section? '12' on line 764 looks like a reference -- Missing reference section? 'RFC 2136' on line 782 looks like a reference -- Missing reference section? '15' on line 783 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Faramak Vakil 2 INTERNET DRAFT Ashutosh Dutta 3 draft-itsumo-hmmp-00.txt Jyh-Cheng Chen 4 Date: October 1999 Telcordia Technologies 5 Expires: April 2000 6 Shinichi Baba 7 Yasuro Shobatake 8 Toshiba Research America,Inc. 10 Host Mobility Management Protocol 11 Extending SIP to 3G-IP Networks 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet- Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 The distribution of this memo is unlimited. It is filed as , and expires April, 2000. Please send comments to 35 either farm@research.telcordia.com or sbaba@tari.toshiba.com. 37 Copyright Notice 39 Copyright (C) The Internet Society (1999). All Rights Reserved. 41 ABSTRACT 43 Host mobility management protocol (HMMP) is a protocol for supporting 44 real-time and non-real-time multimedia applications on mobile 45 terminals of 3G-IP networks. HMMP utilizes as well as extends session 46 initiation protocol (SIP) to provide means of domain hand-off (i.e., 47 roaming), and subnet hand-off (i.e., macro mobility) so that users 48 can access the network from any location using their own mobile 49 terminal. An advantage of HMMP is that it can spoof constant 50 endpoints for mobile TCP connections and supports mobile TCP 51 applications in a SIP environment without any changes to the TCP. 53 The objective of this document is to present the preliminary 54 specifications of HMMP, identify the impact of mobility on SIP, and 55 propose necessary extensions to ensure that SIP can support roaming 56 users adequately. Specifically, it proposes that 58 a. the SIP INFO method provides a means of profile verification 59 and/or replication, and address binding, b. the SIP REGISTER 60 method designates a "RHO" 61 CONTACT that allows the registrar to obtain a new address from the 62 DHCP on behalf of the mobile, c. the SIP user agent is equipped 63 with a SIP_EYE agent that maintains 64 a record of ongoing TCP connections of the mobile, and d. the SIP 65 user agent understands address binding INFO messages and 66 takes necessary actions. 68 Furthermore, it proposes that either the DHCP interact with the DNS 69 and update it dynamically, or a new protocol be developed to allow 70 applications to use SIP registrar for name to address and address to 71 name mappings. 73 1.Introduction 75 1.1 The Rationale 77 Driving the trend towards third generation wireless IP (3G-IP) 78 technology are users' demand for perpetual ubiquitous access to the 79 Internet, rapid proliferation of mobile Internet appliances, and 80 providers' desire for deploying a flexible wireless and wireline IP 81 platform that supports heterogeneous services economically [1, 2, 3]. 82 Furthermore, the current wisdom is that the existing circuit switched 83 and 1G/2G (i.e., 1G and 2G) wireless systems will eventually evolve 84 and merge into an end-to-end IP platform that provides ubiquitous 85 real-time as well as non-real-time services. In a nutshell, it is 86 envisioned that an end-to-end wireless/wireline IP platform 87 comprising 3G wireless access networks and a wireline IP backbone 88 will support real-time and non-real-time multimedia services in the 89 future. Thus, supporting roaming users is an essential feature of the 90 end-to-end signaling and control system of IP networks as well as a 91 critical topic for consideration in the IETF SIP working group. 93 1.2 3G-IP Requirements and Issues 95 A 3G-IP network is a wireless platform that will enable mobile users' 96 IP appliances to access multimedia services on end-to-end 97 wireline/wireless IP platforms in future [6]. We envision that it 98 will 100 - eventually be built upon the packet mode capabilities of the 3G 101 wireless technologies such as IMT-2000 [4, 5], 103 - support mobile real-time and non-real-time services such as mobile 104 telephony, mobile web access, and mobile data services [7, 8], 106 - provide means of global roaming, offer intelligent services (e.g., 107 call forwarding, etc.) similar to those of today's intelligent 108 networks, 110 - strive to ensure that the quality (and price) of their service 111 offerings will be comparable to those of today's wireless 112 telephony and data services, and 114 - be built upon enhancements of the current IETF standards to the 115 extent possible so that the design and development cycle is 116 minimized. 118 Among the key issues in the design of the signaling and control 119 system of 3G-IP networks are how to 121 + support terminal as well as personal/user mobility, 123 + satisfy the quality of service (QoS) requirements of services, 124 particularly those of real-time applications for roaming users, 126 + ensure privacy and security of the users as well as the network 127 resources, 129 + perform billing and accounting, and 131 + maintain smooth interworking with the public switched telephone 132 network (PSTN) and its 1G/2G wireless access networks. 134 Although each of these issues may have some impact on the signaling 135 protocols of IP networks that are being developed in the SIP working 136 group, addressing all of them is beyond the scope of this document. 137 This document exclusively focuses on the specifications of a mobility 138 management protocol that uses an extended version of SIP to support 139 multimedia services of roaming users. 141 1.3 Scope and Purpose 143 The objective of this document is to present the preliminary 144 specifications of host mobility management protocol (HMMP). We 145 - build upon the personal mobility feature of SIP to design HMMP that 146 suppots terminal as well as personal mobility, 147 - identify the impact of mobility on SIP, and 148 - propose necessary extensions to ensure that SIP can support roaming 149 users via HMMP adequately. 151 HMMP is a protocol for supporting real-time and non-real-time 152 multimedia applications on mobile terminals. It provides means of 153 domain hand-off (i.e., roaming), and subnet hand-off (i.e., macro 154 mobility). However, HMMP primarily relies on the link layer to 155 support the cell-hand-off (i.e., micro-mobility). HMMP also spoofs 156 constant endpoints for mobile TCP connections and supports mobile TCP 157 applications in a SIP environment without any changes to the TCP. 159 1.4 Related IETF Documents 161 HMMP is primarily built upon the session initiation protocol (SIP) as 162 specified in RFC 2543. Other related IETF documents are 163 - SDP: Session Description Protocol (RFC 2327), 164 - DHCP: Dynamic Host configuration Protocol (RFC 2131), 165 - IP Encapsulation within IP (RFC 2003), and 166 - Minimal Encapsulation within IP (RFC2004). 168 1.5 Organization of the Document 170 This document is organized as follows. HMMP's assumptions on the 171 underlying network environment are summarized in Section 2, where 172 Section 2.1 describes the architecture of a 3G-IP network, and 173 Section 2.2 summarizes its signaling architecture that is the 174 substrate of HMMP. Section 3 provides an overview of the HMMP 175 operation and underscores the need for augmenting the SIP user agent 176 with a SIP_EYE agent that tacks ongoing TCP connections of the mobile 177 station. Section 4 contains the detailed specifications of HMMP 178 where we describe how HMMP utilizes SIP to provide means of 179 registration, location service, and hand-off to roaming users. The 180 function and basic operation of the SIP_EYE agent are described in 181 Section 5. In Section 6, we summarize the impact of supporting 182 mobility via HMMP on SIP specifications, and highlight necessary 183 extensions for supporting mobility with SIP. Finally, Section 7 184 concludes the document with open issues for further study. 186 2. Assumptions: A 3G-IP Environment 188 This Section provides an overview of a 3G-IP network and its 189 signaling architecture that serves as the foundation of HMMP. 191 2.1 Architecture of a 3G-IP Network 192 Figure 1 depicts the end-to-end packet platform of a 3G-IP network, 193 which comprises 3G-IP access networks and a packet switched IP 194 backbone network. The IP backbone network is an end-to-end wireline 195 IP infrastructure that will comprise regional providers' wireline IP 196 networks that are connected through the Internet. Besides mobile 197 stations/terminals, a wireless access network usually comprises a set 198 of base stations, base station controllers, and mobile switching 199 centers [3]. In order to support the needs of its users, a wireless 200 access network interacts with the network control and signaling 201 entities that are shown as "Signaling & MAAAQ" in Figure 1. What 202 follows is a brief description of these elements and their functions. 204 Mobile Station (MS) 206 It is the user mobile terminal that allows users to communicate, and 207 also provides means of interaction (i.e., signaling) between users 208 and the network. 210 Base Station (BS) 212 It is an adaptive remote radio multiplexer/demultiplexer that 213 provides physical and link layer functions and essentially serves as 214 a MAC layer repeater. In IMT-2000 programmable software radios can 215 be used to provide flexibility across frequency bands at the MS and 216 the BS. 218 Base Station Controller (BSC) 220 It is a multi-port bridge (or switch) with an IP interface to MSC 221 that interacts with the network control and management system (via 222 the MSC) to control and manage base stations. A BSC may control one 223 or more BSs. 225 Mobile Switching Center (MSC) 227 An MSC is an IP router that connects the wireless access network and 228 the regional wireline IP network. In the IP parlance, each MSC is 229 the default gateway of all IP MSs that are supported by BSCs that are 230 connected to it. A couple of points are worth noting. First, 231 different BSCs may be connected to different ports of an MSC. 232 Second, the BSC and MSC functions may be implemented either in a 233 single physical entity, or as two separate entities. 235 +-----------+ 236 -->| Signaling |<-- 237 / | & MAAAQ | \ 238 /--------/ +-----------+ \--------\ 239 / | \ 240 \/ | \/ 241 +-----------+ | +----------+ 242 | Signaling | | | Signaing | 243 | & MAAAQ | <-------------|---------------> | & MAAAQ | 244 +-----------+ | +----------+ 245 | | | 246 ___|___ ____|__ ___|___ 247 / \ / \ / \ 248 / \ / \ / \ 249 /Regional IP\________/ Internet \_________ /Regional IP\ 250 \ Network / \ / \ etwork / 251 \ / \ / \ / 252 \_______/ \_______/ \_______/ 253 | | 254 | | 255 +-----+ +-----+ 256 | MSC | | MSC | 257 +-----+ +-----+ 258 | | 259 | | 260 +----------+ +----------+ 261 | BSC | | BSC | 262 +----------+ +----------+ 263 | | | | 264 | | | | 265 +----+ +----+ +----+ +----+ 266 | BS | | BS | | BS | | BS | 267 +----+ +----+ +----+ +----+ 268 | | | 269 | | | 270 +-----+ +-----+ +-----+ 271 | MS | | MS | | MS | 272 +-----+ +-----+ +-----+ 274 Figure 1. End-to-end network architecture of a 3G-IP network 276 Signaling & MAAAQ 278 Signaling provides connection management as well as means of 279 interaction between users and network control system and interaction 280 among network control entities. MAAAQ (Mobility, Authentication, 281 Authorization, Accounting, and QoS) entities support mobility 282 management, AAA, and QoS management functions for mobile users. These 283 functional entities usually reside on the wireline backbone, and are 284 part of the overall signaling and control system of the end-to-end 285 platform. As Figure 1 indicates the home and visiting signaling & 286 MAAAQ entities may either interact directly or via a third party 287 signaling & MAAAQ entity on the global Internet. In the latter case, 288 the third party signaling & MAAAQ entity serves as a trusted broker 289 between the home and visiting network signaling and MAAAQ entities. 291 2.2 A Signaling Architecture for 3G-IP Networks 293 The overall signaling architecture of a 3G-IP is shown in Figure 2. 294 It uses session initiation protocol (SIP) [9, 10] as the basis of its 295 end-to-end signaling and control architecture. The rationales for the 296 choice of SIP are that: 298 - SIP is a lightweight end-to-end protocol with a small set of 299 messages that can be used for user as well as network node 300 signaling. 301 - SIP uses a single request message for session initiation, and scales 302 well over wide-area networks. 303 - SIP is ideal for IP mobiles, enables mobiles to perform some 304 intelligent networking functions themselves, and supports non-IP 305 mobiles via a customer gateway. 306 - SIP provides a means of personal mobility that is a crucial part of 307 mobility management in wireless environments. 309 Visiting Network Home Network 310 <--------------------> <--------------------> 312 Visiting Registrar Home Registrar 313 +----+ +----+ 314 | VR | | HR | 315 +----+ +----+ 316 | | 317 | | 318 +-----------+ +-----------+ 319 | MAAAQ | | MAAAQ | 320 +-----------+ +-----------+ 321 | SIP Server| <-----------------------------> | SIP Server|<... 322 +-----------+ +-----------+ . 323 | | . 324 ___|___ _______ ___|___ . 325 / \ / \ / \ . 326 / \ / \ / \ . 327 /Regional IP\________/ Internet \_________ /Regional IP\ . 328 \ Network / \ / \ Network / . 329 \ / \ / \ / . 330 \_______/ \_______/ \_______/ . 331 | | SIP 332 | | . 333 ___|___ ___|___ . 334 / \ / \ . 335 / \ / \ . 336 / 3G Access \ / 3G Acces \ . 337 \ Network / \ Network / . 338 \ / |\ /| . 339 \_______/ | \_______/ | . 340 | | | . 341 | | | . 342 | | | . 343 | | | . 344 +-----+ +-----+ +-----+.. 345 | MS | | MS | | MS | 346 +-----+ +-----+ +-----+ 348 Figure 2. A signaling architecture for 3G-IP networks 350 All MSs and fixed hosts have SIP user agents that provide means of 351 interactions with the SIP servers (i.e., proxy servers, redirect 352 servers, and registrar) within the network. In Figure 2, the SIP 353 server entity of a regional IP network represents the set of SIP 354 proxy and SIP redirect servers within the regional network that 355 perform the network control and signaling functions. Similarly, the 356 registrar represents the server (or set of servers) that accepts 357 (accept) SIP REGISTER requests and provides (provide) location 358 services that are similar to those of the home/visiting location 359 registries (HLR/VLR) in today's wireless telephony. As Figure 2 shows 360 the MAAAQ entity is built on top of SIP, and uses the location and 361 signaling services of SIP to support roaming users. 363 The illustration of the MAAAQ entities and SIP server as a single 364 module in Figure 2 shall not be interpreted as a requirement for 365 having a centralized SIP server or MAAAQ entity per regional network. 366 Figure 2 only shows the required functions, though each of the SIP 367 and MAAAQ entities comprise a set of distributed agents. Similarly, 368 the SIP registrars (i.e., HR and VR) may be implemented as either 369 central or distributed databases. 371 The remainder of this document focuses primarily on the 372 specifications of a HMMP for the mobility management entity as well 373 as necessary extensions to SIP for supporting roaming users. 375 3. An Overview of HMMP 377 Figure 3 depicts an end-to-end 3G-IP platform in relative detail. Let 378 us consider the scenario where a corresponding host communicates with 379 a mobile host. For the sake of discussion, let us assume that 380 - the mobile has already registered with its home network using SIP 381 REGISTER method, and 382 - its communication with the corresponding host starts when it is at 383 point A and continues as it moves towards point D. 384 In general, a mobility management protocol shall provide three 385 functions to the mobile users. These functions are 386 i.cell hand-off (micro mobility): that allows users to move from a 387 cell to another, i.e., moving between base stations from A to B, 388 ii.subnet hand-off (macro mobility): that allows users to move 389 between different subnets within the same administrative domain 390 from B to C, and 391 iii.roaming (global mobility): that allows users to roam between 392 different subnets that belong to different administrative domains 393 from C to D. 395 Visiting Network Home Network 396 <--------------------> <--------------------> 398 Visiting Registrar Home Registrar 399 +----+ +----+ 400 | VR | | HR | 401 +----+ +----+ 402 | | 403 | | 404 +-----------+ +-----------+ 405 | MAAAQ | | MAAAQ | 406 +-----------+ +-----------+ 407 | SIP Server| <-----------------------------> | SIP Server| 408 +-----------+ +-----------+ 409 | | 410 | | 411 | | 412 ___|___ ______ ___|___ 413 / \ / \ / \ +----+ 414 / \ / \ / \----| CH | 415 /Regional IP\________/ Internet \_ ________ /Regional IP\ +----+ 416 \ Network / \ / \ Network / 417 \ / \ / |\ /|* 418 \______/ \______/ | \_______/ |* 419 | | |* | | |* 420 | | |* 421 +-------+ +-------+ +-------+ 422 | MSC 3 | | MSC 2 | | MSC 1 | 423 +-------+ +-------+ +-------+ 424 | | |* 425 | | |* 426 +----------+ +-------+ +----------+ 427 | BSC 3 | | BSC 2 | | BSC 1 | 428 +----------+ +-------+ +----------+ 429 | | | |* | 430 | | | |* | 431 +----+ +----+ +----+ +----+ +----+ 432 | BS | | BS | | BS | | BS | | BS | 433 +----+ +----+ +----+ +----+ +----+ 434 | | |* | 435 | | |* | 436 +-----+ +-----+ +-----+ +-----+ 437 | MS | | MS | | MS | | MS | 438 +-----+ +-----+ +-----+ +-----+ 439 D C B A 441 Figure 3. Cell hand-off in HMMP 443 The cell hand-off (i.e., micro mobility) is not part of HMMP and is 444 usually handled at the link layer, while HMMP uses SIP to provide the 445 subnet hand-off (i.e., macro mobility) and roaming (i.e., global 446 mobility) functions for mobile hosts on 3G-IP networks. What follows 447 is a walk through the operation of HMMP using this example. 449 3.1 Cell hand-off 451 As the mobile moves from A to B, then the link layer mobility 452 management entity 454 * binds the mobile's MAC address (or CDMA sequence) to the BSC port 455 destined for base station B, and 456 * updates the label translation table in BSC 1, so that the 457 information destined for the mobile host is routed to base station 458 B. Note that the label translation table refers to a table in the 459 BSC that contains the binding of mobile's MAC addresses to BSC 460 ports. 462 If the mobile can communicate with two adjacent base stations 463 simultaneously, the mobile's binding to base station A may be 464 maintained for a time-out period after the hand-off so that the 465 hand-off is soft and transient packets are not lost. Note that the IP 466 address of the mobile remains the same. 468 3.2 Subnet hand-off 470 The mobile moves further from B to C, and it is still registered with 471 the network. HMMP supports subnet hand-off (i.e., macro mobility) 472 during the session as follows. 474 + The mobile asks a new temporary address from DHCP. The mobile 475 requests a new address either directly (see Section 4.1.1) or via a 476 SIP registrar (see Section 4.1.2). The DHCP gives the mobile a 477 temporary IP address, the address of its default gateway, and the 478 subnet mask. Furthermore, the DHCP updates the domain name system 479 (DNS) simultaneously. 480 + In public networks, the network authenticates the mobile as a 481 protection against fraud. In principle, it is always desirable to 482 authenticate a mobile before assigning network resources such as 483 adresses to it. For instance, PPP has its own registration scheme 484 using CHAP during session initiation and the MIP extension using 485 NAI for registration prpose has been proposed. The registration 486 approach described in Section 4.1.2 as well as the Dynamic 487 Registration and Configuration Protocol(DRCP) proposed in McAuley, 488 et.al [14] both can authenticate and assign an address to 489 it simultaneously. 490 + The mobile or SIP server re-invites the corresponding host to the 491 temporary address (similar to the approach proposed by Wedlund and 492 Schulzrinne [16]). 493 + SIP server and network resource reservation scheme should create a 494 new route with adequate resources between the corresponding host 495 and the mobile. 496 a. This new route with adequate resources is only created for 497 real-time applications like voice. There have been several 498 proposal for the use of Resource ReServation Protocol 499 (RSVP)[21] for resource reservation in wireline networks that 500 have SIP signaling [22]. However, due to its receiver 501 initiated reservation scheme, RSVP is not suitable for a mobile 502 wireless netwok. The specifications of a resource reservation 503 mechanism for supporting real-time mobile applications and its 504 interaction with SIP require further study, and are beyond the 505 scope of this document. 506 b. The non-real-time applications are allowed to traverse the 507 network hop-by-hop. 508 + The mobile or SIP server ensures that the transient data is 509 forwarded to the new address, i.e., it creates a short-lived tunnel 510 between MSC 1 and MSC 2 to reduce loss of the transient data due to 511 hand-off. In order to create this tunnel, the mobile or SIP server 512 informs MSC-1 to bind the previous address of the mobile to its 513 current one for a time-out period. This requires 514 * SIP user agents at all MSCs (i.e., subnet routers), and 515 * the address of the most recent MSC which is the most recent 516 default gateway. 518 Visiting Network Home Network 519 <--------------------> <--------------------> 521 Visiting Registrar Home Registrar 522 +----+ +----+ 523 | VR | | HR | 524 +----+ +----+ 525 | | 526 | | 527 +-----------+ +-----------+ 528 | MAAAQ | | MAAAQ | 529 +-----------+ +-----------+ 530 | SIP Server| <-----------------------------> | SIP Server| 531 +-----------+.... ....+-----------+ 532 | | | | 533 | +----+ +----+ | 534 | |DHCP| |DHCP| | 535 | +----+ +----+ | 536 ___|___ | _______ _ | ___|___ 537 / \.... / \ _ ..../ \ +----+ 538 / \ / \ _ **/*********\----| CH | 539 /Regional IP\________/ Internet \__________*/Regional IP\ +----+ 540 \ Network / \ / *\ Network /| 541 \ / \ / *|\ / | 542 \_______/ \ ______/ *| \______/ | 543 | *| | 544 | *| | 545 | *| | 546 +-------+ +-------+ +-------+ 547 | MSC 3 | | MSC 2 |====| MSC 1 | 548 +-------+ +-------+ +-------+ 549 | *| | 550 | *| | 551 +----------+ +-------+ +----------+ 552 | BSC 3 | | BSC 2 | | BSC 1 | 553 +----------+ +-------+ +----------+ 554 | | *| | | 555 | | *| | | 556 +----+ +----+ +----+ +----+ +----+ 557 | BS | | BS | | BS | | BS | | BS | 558 +----+ +----+ +----+ +----+ +----+ 559 | *| | | 560 | *| | | 561 +-----+ +-----+ +-----+ +-----+ 562 | MS | | MS | | MS | | MS | 563 +-----+ +-----+ +-----+ +-----+ 564 D C B A 566 Figure 4. Subnet hand-off in HMMP 568 3.3 Roaming 570 Except for the fact that the mobile SHALL always be autheticated, 571 roaming in HMMP is similar to subnet hand-off described in Section 572 3.2. As the mobile moves further to D, HMMP operates as follows: 574 + The mobile requests for a temporary address and receives one from 575 DHCP. The DHCP updates the DNS simultaneously. 576 + The mobile re-registers with its temporary address in the new domain 577 using the SIP REGISTER method. 578 * The mobile profile is added to the visiting registrar (VR), 579 i.e., its profile is replicated either through interaction of 580 the VR with the HR or by pre-planned profile replications [13] 581 in the neighboring VRs. The pre-planned profile replications 582 reflect the mobility pattern of the mobile, and its effective 583 realization requires continuous monitoring of users' mobility 584 patterns. 585 + The mobile or SIP server re-invites the corresponding host to the 586 temporary address (similar to the approach proposed by Wedlund and 587 Schulzrinne [16]). 588 + SIP server and network resource reservation scheme should create a 589 new route with adequate resources between the corresponding host and 590 the mobile. 591 a. This new route with adequate resources is only created for 592 real-time applications like voice. The specifications of a 593 resource reservation mechanism for supporting real-time mobile 594 applications and its interaction with SIP require further 595 study, and are beyond the scope of this document. 596 b. The non-real-time applications are allowed to traverse the 597 network hop-by-hop. 598 + The mobile or SIP server ensures that the transient data is 599 forwarded to the new address, i.e., it creates a short-lived tunnel 600 between MSC 2 and MSC 3 to reduce loss of the transient information 601 + The mobile or SIP server informs MSC-2 to bind the previous address 602 of the mobile to its current one for a time-out period. This 603 requires 604 * SIP user agents at all MSCs (i.e., subnet routers), and 605 * the address of the most recent MSC which is the most recent 606 default gateway. 608 Visiting Network Home Network 609 <--------------------> <--------------------> 611 Visiting Registrar Home Registrar 612 +----+ +----+ 613 | VR | | HR | 614 +----+ +----+ 615 | | 616 | | 617 +-----------+ +-----------+ 618 | MAAAQ | | MAAAQ | 619 +-----------+ +-----------+ 620 | SIP Server| <-----------------------------> | SIP Server| 621 +-----------+.... ....+-----------+ 622 | | | | 623 | +----+ +----+ | 624 | |DHCP| |DHCP| | 625 | +----+ +----+ | 626 ___|___ | _______ | ___|___ 627 / \.... / \ ..../ \ +----+ 628 /*********\***********/*********\*************/*********\----| CH | 629 /Regional IP\_________/ Internet \__________ /Regional IP\ +----+ 630 \*Network / \ / \ Network / 631 \* / \ / |\ /| 632 *\_______/ \______ / | \_______/ | 633 *| | | 634 *| | | 635 *| | | 636 +-------+ +-------+ +-------+ 637 | MSC 3 |===============================| MSC 2 | | MSC 1 | 638 +-------+ +-------+ +-------+ 639 *| | | 640 *| | | 641 +----------+ +-------+ +----------+ 642 | BSC 3 | | BSC 2 | | BSC 1 | 643 +----------+ +-------+ +----------+ 644 | *| | | | 645 | *| | | | 646 +----+ +----+ +----+ +----+ +----+ 647 | BS | | BS | | BS | | BS | | BS | 648 +----+ +----+ +----+ +----+ +----+ 649 *| | | | 650 *| | | | 651 +-----+ +-----+ +-----+ +-----+ 652 | MS | | MS | | MS | | MS | 653 +-----+ +-----+ +-----+ +-----+ 654 D C B A 656 Figure 5. Roaming in HMMP 658 3.4 Supporting TCP Applications with HMMP 660 Internet applications that require a reliable service from the 661 transport mechanism, e.g., file transfer protocol (FTP), primarily 662 use TCP. Thus, it is essential that HMMP support mobile TCP 663 applications without requiring any changes to the TCP. 665 Although the fundamental abstraction of both SIP and TCP is the 666 connection, they identify it differently. A session/call ID 667 identifies a SIP connection/session, while a pair of endpoints 668 identifies a TCP connection. Each TCP endpoint is identified with a 669 pair of integers (host, port) where host is IP address of the 670 endpoint, and port is the TCP port on the host. However, as a mobile 671 roams, its IP address, i.e., the host integer of its TCP endpoint 672 changes. In order to support TCP applications properly, HMMP shall 673 spoof constant TCP endpoints despite changes in their host integers 674 (i.e., IP addresses) due to roaming of the mobiles. The spoofing 675 process is akin to mobile IP with route optimization [17, 18], and 676 its underlying idea is that 678 - the mobile informs the corresponding TCP endpoints about its new 679 address, 680 - the corresponding host(s) binds (bind) the initial IP address of the 681 mobile with its new temporary (i.e., care of address) IP address, 682 and 683 - the corresponding host(s) uses (use) encapsulation to send the TCP 684 packets bearing the initial source and destination addresses to the 685 current location/address of the mobile. 687 In order to support TCP applications on HMMP without modifying TCP, 688 the SIP user agent SHALL be augmented with a SIP_EYE agent that 689 tracks TCP connection set-ups and releases within the mobile. The 690 SIP_EYE agent enables the SIP user agent to maintain a record of 691 mobile's ongoing TCP connections, and their identifiers. SIP_EYE 692 operates as follows: 694 i. It examines headers of TCP packets to monitor the birth and death 695 of TCP connections as well as identify their endpoints, i.e., the 696 source and destination IP addresses and port numbers of these 697 connections. 698 ii. It maintains a current record of the mobile's ongoing TCP 699 connections' identifiers, and the address of the current and last 700 (i.e., most recent) MSCs (i.e., default gateways) within the 701 mobile's SIP user agent. 702 iii. SIP_EYE records a state comprising four integers, , per TCP 705 connection. The original MS IP address is the IP address of 706 the mobile at the beginning of the TCP session, previous mobile 707 IP address is the last IP address of the mobile just before its 708 current one, and current MS IP address is the current IP 709 address of the mobile. The original corresponding IP address is 710 the IP address of the corresponding host at the beginning of the 711 TCP session. 712 iv. Upon a mobile station's successful registration with the visiting 713 network, its SIP user agent sends 714 (a) an INFO message (messages) to the SIP user agent(s) of 715 corresponding host(s) to request binding of the original 716 address of the mobile with its current one, and 717 (b) also sends a INFO message to last MSC for binding the 718 previous host address to the new one so that a short-lived 719 tunnel is created for forwarding transient data to the 720 mobile's location. 721 v. The corresponding host and the MSC use IP encapsulation (either 722 within IP [19] or minimal [20]) to forward the TCP information to 723 the mobile's current location. 725 The key advantage of this approach is that TCP stays as is; though 726 the required IP encapsulation reduces the bandwidth efficiency of the 727 channel. 729 Since the DHCP interacts with DNS to dynamically update the name to 730 address and address to name mappings, new TCP connections will be 731 established using the current address of the mobile. Another 732 alternative for name to address mapping and vice-versa is that 733 instead of a dynamic DNS, one develops a new protocol that allows 734 applications to use SIP registrar for name to address and address to 735 name mappings. The specifications of this alternative and its 736 comparison with a dynamic DNS scheme require further study, and is 737 beyond the scope of this docuement. 739 4. HMMP on SIP 741 SIP supports personal mobility function. HMMP builds upon the 742 personal mobility feature of SIP to enable users to access the 743 network from any location using their own mobile terminal. The two 744 main functions of HMMP are registration, and mobility support. The 745 registration involves assigning new address to a roaming mobile and 746 authenticating it whenever necessary; while the mobility support 747 comprises re-invitation, and/or tunneling via address binding. Let us 748 explain how one can utilize and extend SIP to perform these 749 functions. 751 4.1 Registration 753 SIP REGISTER method allows users to register with the network and 754 enable them to access the network from any terminal on the network. 755 HMMP utilizes SIP to register and configure mobile terminals. There 756 are two ways to use SIP for mobile registration. The first approach 757 requires no extension/modifications of SIP, while the second requires 758 certain modifications and extensions of SIP. 760 4.1.1 Registration: Approach 1 762 The first registration approach utilizes the dynamic host 763 configuration protocol (DHCP) [11], and SIP REGISTER and recently 764 proposed INFO method [12] to perform the registration. It operates 765 as follows. 767 + The mobile station (MS) requests a new address from DHCP. 768 + DHCP assigns a temporary address to the MS. 769 + The MS uses SIP REGISTER method with its temporary IP address as 770 CONTACT in the REGISTER method. Note that if this registration is 771 trigrred by the roaming of the MS in the middle of an ongoing 772 session (i.e., re-registration), then the visiting registrar (VR) 773 shall authenticate it with the home registrar (HR). 775 The signaling flow for the registration is depicted in Figure 6. The 776 MS broadcasts a DHCPDISCOVER message to the DHCP servers. Several 777 servers offer a new address to MS via DHCPOFFER; the MS selects one 778 and sends a DHCPREQUEST to the corresponding DHCP server. The DHCP 779 server send a DHCPACK to confirm the assignment of the address to the 780 MS. Simultaneously, the DHCP SHALL update the DNS address to name 781 and name to address mappings. For instance, the DHCP can use the 782 Dynamic DNS updates mechanism [RFC 2136] to perform the DNS mapping 783 update [15]. Figure 6, does not show the DNS update in detail. The 784 MS sends a SIP REGISTER message whose CONTACT is set to the MS's new 785 address to the visiting registrar (VR) that contains the service 786 profile of the MS. The VR uses the SIP INFO method to send MS's 787 profile to the HR for authentication. The HR responds to the VR with 788 a SIP OK if authentication is successful, otherwise, HR responds with 789 a "603 Decline" response. Then, the VR sends a SIP OK to the MS to 790 confirm its registration with the visiting network. Therefore, 791 additional requirements for supporting this registration approach are 792 the followings. 794 - The DHCP SHALL interact with the DNS and update it dynamically. 795 - The SIP INFO method SHALL be able to convey the question "Is profile 796 [....] valid? " to the HR in the method message body. 798 MS DHCP (several servers) VR HR 799 | DHCP DISCOVER | | | 800 |---------------------->| | | 801 | DHCP OFFER | | | 802 |<----------------------| | | 803 | DHCP REQUEST | | | 804 |---------------------->| | | 805 | DHCP ACK | DNS Update | | 806 |<----------------------|------------> | | 807 | | | | 808 | SIP REGISTER | | | 809 |-----------------------|------------------->| | 810 | | | SIP INFO | 811 | | |----------------->| 812 | | | SIP OK | 813 | | |<-----------------| 814 | | SIP OK | | 815 |<----------------------|--------------------| | 816 | | | | 818 Figure 6. The signaling flow for the registration: Approach 1 820 Assuming that the processing time is negligible, the maximum 821 registration time using this approach equal to sum of the round trip 822 (MS-DHCP-MS), the round trip (MS-VR-MS), and the round trip (VR-HR- 823 VR) delays. The first term represents the time it takes to get a new 824 address, the second and third is the registration time. The 825 registration time comprises the time for mobile's interaction with 826 the SIP registrar as well as the time it takes the VR to communicate 827 with the HR in order to authenticate the mobile. 829 In order to reduce the impact of roaming on the performance of 830 interactive real-time services, it is essential to minimize the 831 registration time of a mobile in a visiting network. As Figure 6 832 indicates this goal can be achieved through minimizing the mobile 833 authentication time as well address acquisition time. The mobile 834 authentication can be expedited through replicating a mobile's 835 profile in networks that are most likely to be visited by the mobile 836 [13]. This profile replication reduces the registration time by a 837 VR-HR-VR round trip, though it increases the control load due to 838 profile administration, and its effective realization requires 839 continuous monitoring of user's mobility patterns. An approach that 840 augments the SIP registrar with DHCP functions and reduces the 841 address acquisition time is described in Section 4.1.2. 843 4.1.2 Registration: Approach 2 845 In a nutshell, this approach equips the SIP registrar with DHCP 846 functions so that the address acquisition time is reduced. 847 Realization of this approach requires the modification of SIP 848 REGISTER method so that if the CONTACT field is set to a default 849 registration/hand-off (i.e., "RHO") value , the SIP registrar (i.e., 850 registration server) shall also ask for a temporary address for the 851 mobile. The registrars shall be equipped with a DHCP client as well 852 as shall be co-located with a DHCP server that allows it to assign IP 853 addresses to the mobiles. This registration algorithm operates as 854 follows: 856 + The mobile uses a SIP REGISTER method with CONTACT = "RHO" to 857 re-register as well as get it a new address. When the visiting 858 registrar (VR) receives this message 859 - the VR assigns a new temporary address to the mobile, i.e., its DHCP 860 client ask for an address from its DHCP server, 861 - the VR and HR interact to authenticate the mobile, if the 862 authentication fails, VR sends a 603 Decline message to the mobile, 863 otherwise, 864 * the VR DHCP server updates the DNS, and 865 * the VR send the temporary address to the mobile in the 200 866 response as Contact header field. 868 Assuming negligible processing time, the maximum registration time 869 equals the sum of the round trip (MS-VR-MS), and round trip round 870 trip (VR-HR-VR) delays. Like approach 1, a profile replication method 871 may be used to eliminate the round trip delay (VR-HR-VR) involved in 872 authentication, and minimize the registration time. The key 873 advantages of this scheme (compared to approach 1) are that it 875 a. reduces the address acquistion time becuase the registrar itself 876 can assign new address, and 877 b. protects network resources against fraud because the registrar 878 authenticates the MS before sending the MS its new assigned 879 address. 881 The signaling flow of this registration procedure is shown in Figure 882 7. Note that Figure 7 does not depict DNS update process in detail. 884 MS VR HR 885 | | | 886 | SIP REGISTER | | 887 | CONTACT="RHO" | | 888 |------------------------------>| | 889 | | SIP INFO | 890 | |------------------------------>| 891 | | SIP OK | 892 | |<------------------------------| 893 | | | 894 | SIP OK | DNSUpdate | 895 |<------------------------------|----------> | 896 | | | 897 | | | 899 Figure 7. The signaling flow for registration: Approach 2 901 The followings are additional requirements for supporting this 902 registration approach with SIP. 904 ** The SIP REGISTER method SHALL designate a "RHO" CONTACT that allows 905 the registrar to obtain a new address from the DHCP on behalf of 906 the mobile. 907 ** The DHCP sever of VR SHALL either update the DNS dynamically or a 908 new protocol be developed to allow applications to use SIP 909 registrar for name to address and address to name mappings. 911 An interesting question is how does the SIP registrar inform the 912 mobile about its new address? The answer is exactly the way DHCP 913 does it. The TCP(UDP)/IP software should accept and forward to the IP 914 layer any IP packets delivered to the mobile's hardware address 915 before its IP address is configured. The SIP registrar may use the 916 limited broadcast IP address to force the IP layer to broadcast the 917 registrar's response on the subnet so that it is delivered to the 918 mobile's hardware address before the TCP(UDP)/IP software of the 919 mobile is configured. If mobiles can accept hardware unicast 920 datagrams before their TCP(UDP)/IP software are configured, the 921 registrar may use this capability to deliver the mobile's 922 new/temporary address. 924 I believe the fact that VR is equipped with DHCP client and server 925 capabilities is consistent with RFC 2543 requirement that explicitly 926 states a SIP registrar cannot act as a SIP client. However, this 927 point should be examined further. 929 4.2 Mobility Support 931 The mobility support comprises two functions, i): location service, 932 i.e., locating mobile users in response to new incoming session 933 requests, and ii): hand-off, i.e., ensuring soft hand-off as the 934 mobile user roams across subnets and/or domains. What follows 935 describes how HMMP uses SIP to support these functions. 937 4.2.1 Location Service 939 The mobile has moved to a new location when a corresponding host 940 initiates a session. In this case, HMMP sets up the session as 941 follows: 942 - The corresponding host invites the mobile station (i.e., MS), 943 - A SIP redirect server (SIP-RS) answers that the mobile is moved to a 944 new location (i.e., temporary address), 945 - The corresponding host re-invites the mobile at the temporary 946 address, and 947 - a session is set up between the corresponding and mobile hosts, and 948 the data transfer begins. 950 Figure 8 depicts the signaling flow for location service. 952 CH SIP-RS MS 953 | | | 954 | SIP INVITE | | 955 |------------------------------>| | 956 | 302: Moved Temporarily | | 957 |<------------------------------| | 958 | SIP INVITE | | 959 |-------------------------------|----------------------------->| 960 | | SIP OK | 961 |<------------------------------|------------------------------| 962 | User Data | | 963 |-------------------------------|----------------------------->| 964 | | | 966 Figure 8. The signaling flow for location service 968 The corresponding host sends a SIP INVITE message to the mobile 969 station. A redirect server that has intercepted the INVITE message 970 sends a 302 (i.e., moved temporarily) redirection message to the 971 corresponding host with the mobile's new/temporary address as its 972 Contact header field. The corresponding host sends a SIP INVITE 973 message to the new address, the mobile responds with a SIP OK, and 974 the data transfer begins. Since the DHCP dynamically updates the DNS 975 mappings, new TCP connections are established using the most recent 976 IP address of the mobile. 978 4.2.2 Hand-off 980 To ensure soft hand-off, HMMP should re-establish a new session 981 between the corresponding host and the mobile station (MS) at its new 982 location, and create a short-lived tunnel for forwarding the 983 transient data of the session to the mobile station's new location. 984 When the MS moves to a new location during the session, The MS re- 985 registers (using either of registration methods described in Section 986 4.1) and obtains a new address. Then, HMMP provides means of hand-off 987 as follows: 989 + A new session with the same session ID is created between 990 corresponding host (CH) and the mobile. In order to create a new 991 session, the MS (or SIP server) re-invites the corresponding host to 992 the new address of the MS. 993 + The MS or SIP server uses the SIP INFO method to create a 994 short-lived tunnel between the previous MSC and the new MSC to 995 reduce the loss of session transient data. In order to create the 996 tunnel 997 - The MS or SIP server sends an INFO message to the previous MSC 998 (P-MSC) which is the same as the default gateway of the MS before 999 getting its new address, and 1001 - binds the old address of the mobile with its new one, so that 1002 transient messages are forwarded to the new address of the MS, and 1003 packet loss is reduced. The expire filed of the INFO method is used 1004 to specify the tunnel lifetime (i.e., a time-out period after which 1005 the tunnel is discontinued). The exact algorithm for determining the 1006 tunnel lifetime requires further study. 1007 + The MS SIP user agent also sends an INFO message to the SIP user 1008 agent of any corresponding host whose address is in the MS's SIP-EYE 1009 record of ongoing TCP connections so that each corresponding host 1010 binds the original IP address of the MS to its current (i.e., new) 1011 IP address. 1013 Note that the P-MSC uses IP encapsulation [19, 20] to create a tunnel 1014 for forwarding the transient packets to the mobile's new location. 1015 The key requirement for the realization of the tunneling process is 1016 that each MSC SHALL have a SIP user agent. The signaling flow for 1017 hand-off is shown in Figure 9. 1019 MS has already registered as shown in Figures 6 or 7. 1020 MS CH P-MSC 1021 | | | 1022 | SIP INVITE | | 1023 |-------------------------------->| | 1024 | | SIP INFO | 1025 |---------------------------------|----------------------------->| 1026 | SIP INFO | | 1027 |-------------------------------->| | 1028 | SIP OK | | 1029 |<--------------------------------| | 1030 | | SIP OK | 1031 |<--------------------------------|------------------------------| 1032 | User Data | | 1033 |-------------------------------->| | 1034 | | | 1036 Figure 9. The signaling flow for hand-off 1038 It is worth noting that Figure 9 shows an instance of the signaling 1039 flow for hand-off. The exact sequence of SIP OK responses from the 1040 P-MSC and CH SIP user agent to the MS SIP user agent depends on the 1041 round trip delay between these entities as well as the network 1042 traffic these messages encounter as they traverse the network. In 1043 summary, additional requirements for supporting hand-off are the 1044 following. 1046 - The SIP user agent SHALL be equipped with a SIP_EYE agent that 1047 tracks TCP connections in the MS. - The SIP_EYE agent SHALL 1048 maintain a state comprising the per TCP connection within the SIP 1051 user agent of the MS. - The SIP user agent SHALL keep the address 1052 of the last default 1053 gateway (i.e., previous MSC) before hand-off). - The SIP user 1054 agent SHALL understand address binding INFO messages 1055 and take necessary actions. - The SIP INFO method SHALL support 1056 address bindings, i.e., understand 1057 a "Bind [address 1] to [address 2] " instruction in the method 1058 message body. 1060 5. The SIP_EYE Agent 1062 The whole premise of the SIP_EYE agent is to ensure that HMMP 1063 supports TCP as is without any modifications to TCP. SIP_EYE SHALL be 1064 a simple TCP tacking/monitoring agent with small footprint residing 1065 within the SIP user agents of mobile stations (MSs) and corresponding 1066 hosts (CHs). Its functions are to 1068 a) identify and track ongoing TCP connections of a mobile station, and 1069 b) maintain a list of ongoing TCP connection identifiersand their 1070 respective corresponding hosts so that the SIP user agent of the 1071 mobile sends them INFO messages to bind the original IP address of 1072 the mobile with its current one. 1074 The SIP_EYE agent tracks both the transmitted and received TCP 1075 packets concurrently to create and update the list of ongoing TCP 1076 connections in the MS. It runs two concurrent monitoring and updating 1077 processes, one for tracks the transmitted packets, and the other 1078 received ones. The role of SIP_EYE in hand-off of TCP connections has 1079 already been discussed in detail. The following pseudo-code describes 1080 the basic TCP tracking operation of the SIP_EYE agent for the 1081 simplest case. 1083 // SA: Source address of a packet. 1084 // DA: Destination address of a packet. 1085 // SYN: Synchronization code bit 1086 // ACKB: Acknowledgment code bit 1087 // FIN: Sender end of byte stream code bit 1088 // SEQ: Sequence number 1089 // ACKN: Acknowledgement number 1091 // Auxiliary variables 1092 // CL_ID: Connection Label ID 1093 // STAT: Connection Status 1094 // STATUS takes values, Setup_Req, Setup_Prog, Established, 1095 // Release_Req, Release Ack, Release Accpet, Disconnect) 1096 // 1097 // The TX SIP_EYE Entity. 1099 for (;;) { 1100 Capture the header of transmitted TCP packets; 1101 if (SYN = 1 & ACKB = 0) { 1102 Add a TCP entry as follows to the temporary list of connections 1103 < original MS IP address = SA; 1104 previous MS IP address = SA; 1105 current MS IP address = SA; 1106 original corresponding IP address = DA; 1107 CL_ID = SEQ; 1108 STAT = Setup_Req; > 1109 } 1110 else if (ACKB = 1 & SYN =0) { 1111 Get the STAT of the TCP entry, 1112 < original MS IP address = SA; 1113 previous MS IP address = SA; 1114 current MS IP address = SA; 1115 original corresponding IP address = DA; 1116 CL_ID = ACKN-1; 1117 STAT = **; > 1118 if ( STAT = Setup Prog ) Set STAT = Established; 1120 // A TCP connection is added to the table of ongoing connections. 1121 if else (STAT = Release_Ack) { 1122 Set STAT = Disconnect; 1123 Remove the TCP entry from the table of ongoing connections. 1124 } 1125 else 1126 Error!; 1127 } 1128 else if { ACKB =1 & FIN = 1 ) { 1129 Reset the CL_ID and STAT of the ongoing TCP entry, 1130 < original MS IP address = SA; 1131 previous MS IP address = previous MS IP address; 1132 current MS IP address = current IP address of the mobile; 1133 original corresponding IP address = DA; 1134 CL_ID = ** ; 1135 STAT = Established; > 1136 to 1137 CL_ID = SEQ; 1138 STAT = Release_Req; 1139 } 1140 } 1141 // The RX SIP_EYE Entity. It is similar to TX entity and they 1142 // both run concurrently to manage a single TCP connection list. 1144 for(;;) { 1145 Capture the header of received TCP packets; 1146 if (SYN = 1 & ACKB = 1) { 1147 Reset the STAT of the TCP entry ; 1148 < original MS IP address = DA; 1149 previous MS IP address = DA; 1150 current MS IP address = DA; 1151 original corresponding IP address = SA; 1152 CL_ID = ACKN-1; 1153 STAT = Setup_Req; > 1154 to 1155 STAT = Setup_prog; 1156 } 1157 else if (SYN = 0 & ACKB =1) { 1158 Reset the STAT of TCP_entry; 1159 < original MS IP address = DA; 1160 previous MS IP address = DA; 1161 current MS IP address = DA; 1162 original corresponding IP address = SA; 1163 CL_ID = ACKN-1; 1164 STAT = Release_Req; > 1165 to 1166 STAT = Release_Ack; 1167 } 1168 else if { ACKB =1 & FIN = 1) { 1169 Reset the STAT of TCP entry 1170 < original MS IP address = DA; 1171 previous MS IP address = previous MS IP address; 1172 current MS IP address = current IP address of the mobile; 1173 original corresponding IP address = SA; 1174 CL_ID = ACKN-1; 1175 STAT = Release_Ack; > 1176 to 1177 STAT = Release_ACK; 1178 } 1180 } 1182 // Update of ongoing TCP connection list upon hand-off. 1183 // new MS IP address: The new address that has been assigned to the 1184 // mobile upon hand-off. 1186 if (hand-off) { 1187 while (!eof ongoing list) { 1188 < original MS IP address = original MS IP address; 1189 previous MS IP address = current MS IP address; 1190 current MS IP address = new MS IP address; 1191 original corresponding IP address = original corresponding IP address; 1192 CL_ID = **; 1193 STAT = Established; 1194 } 1196 The preceding pseudo-code describes the basic operation of SIP_EYE in 1197 an environment whose packet error or loss ratio is negligible and no 1198 connection set-up message of TCP is lost or corrupted. It shall be 1199 refined further so that it becomes robust enough for use in a 1200 wireless environment that has relatively (compared to wireline 1201 networks) high packt loss and error and TCP set up messages may be 1202 lost or corrupted. Furthermore, the interactions of the SIP_EYE 1203 agent with the entities of current SIP user agent as well as its 1204 integration within the SIP user agent require further study. 1206 6. Impact of Mobility on SIP Specifications 1208 Having described HMMP, let us summarize requirements for supporting 1209 mobility on SIP via HMMP or other protocols. The requirements are the 1210 following. 1212 ** The SIP INFO method SHALL be able to convey the question, "Is the 1213 profile [....] valid? ", to the HR in the message body of INFO 1214 method. 1215 ** The SIP INFO method SHALL support address bindings, i.e., 1216 understand a "Bind [address 1] to [address 2] " instruction in the 1217 message body of the INFO method. 1218 ** The SIP REGISTER method SHALL designate a "RHO" CONTACT that 1219 allows the registrar to obtain a new address from the DHCP on 1220 behalf of the mobile. 1221 ** The SIP user agent SHALL be equipped with a SIP_EYE agent that 1222 tracks TCP connection. 1223 ** The SIP_EYE agent SHALL maintain a state comprising the per TCP connection. 1226 ** The SIP user agent SHALL keep the address of the last default 1227 gateway (i.e., previous MSC) before hand-off). 1228 ** The SIP user agent SHALL understand address binding INFO messages 1229 and take necessary actions. 1230 ** The DHCP sever of VR SHALL either update the DNS dynamically or a 1231 new protocol be developed to allow applications to use SIP 1232 registrar for name to address and address to name mappings. 1234 Except for the interaction between DHCP and DNS, SIP specifications 1235 SHALL support other functions/requirements so that SIP can support 1236 signaling needs of roaming users in 3G-IP networks. 1238 7. Summary and Open Issues 1240 This document has presented the preliminary specifications of HMMP, 1241 and identified the impact of mobility on SIP and proposed necessary 1242 extensions to ensure that SIP can support roaming users adequately. 1243 HMMP is a protocol that supports real-time and non-real-time 1244 multimedia applications on mobile terminals of 3G-IP networks. HMMP 1245 utilizes as well as extends session initiation protocol (SIP) to 1246 provide means of domain hand-off (i.e., roaming), and subnet-off 1247 (i.e., macro mobility) so that users can access the network from any 1248 location using their own mobile terminal. HMMP can spoof constant 1249 endpoints for mobile TCP connections and supports mobile TCP 1250 applications without any changes to the TCP. Among the open issues 1251 that may influence SIP specifications and require further study are: 1253 -- the specifications of a resource reservation mechanism for 1254 supporting real-time multimedia applications of roaming users in a 1255 3G-IP network whose signaling system is built on SIP, 1256 -- the extension of the SIP_EYE specifications so that it is able 1257 to account for error in and loss of the TCP connection set-up 1258 packets, and to interact and co-operate with the current SIP user 1259 agent as defined in RFC 2543, 1260 -- the specifications of AAA entity, and 1261 -- interworking with the PSTN. 1263 8. Acknowledgments 1265 The authors wish to acknowledge the contributions of other members of 1266 the ITSUMO(TM) team from Telcordia (P. Agrawal, , S. Das, D. 1267 Famolari, A. McAuley, P. Ramanathan, and R. Wolff) and Toshiba 1268 America Research Incorporated (T. Kodama). 1270 (TM): ITSUMO (Internet Technology Supporting Universal Mobile 1271 Operation) is a trademark of Telcordia. It is a joint research 1272 project of Telcordia Technologies and Toshiba America Research Inc. 1273 (TARI). It envisions an end-to-end wireless/wireline IP platform for 1274 supporting real-time and non-real-time multimedia services in the 1275 future. Its goal is to use IP and third generation wireless 1276 technologies to design a wireless platform that allows mobile users 1277 to access multimedia services on a next generation Internet. In 1278 Japanese, ITSUMO means anytime, always. 1280 9. References 1282 1. D. Barboza, "Motorola and Sun to Build Joint System for Net 1283 Access", The New York Times, June 10, 1999. 1285 2. Cnnfn Industry Watch, "NOKIA: Industry leaders for focus group to 1286 promote third generation wireless IP Technology", June 11, 1999. 1288 3. Telcordia Technologies, "Voice Over Packet in Next Generation 1289 Networks: An Architectural Framework", Bellcore SR-4717, Issue1, 1290 January 1999. 1292 4. ITU-R Rec. M.687-2, "International Mobile Telecommunications-2000 1293 (IMT-2000)", 1997. 1295 5. ITU-R Rec. M.817, "International Mobile Telecommunications-2000 1296 (IMT-2000)", Network Architectures", 1992. 1298 6. ITSUMO Group, "Evolution of Wireless Telephony towards Voice over 1299 3G-IP", 3GPP2- P00-19990824-010, August 23, 1999. 1301 7. ITSUMO Group, "A Service Profile for 3G-IP Wireless Networks", 1302 3GPP2-P00-19990927-009, September 27, 1999. 1304 8. ITU-R Rec. M.816-1, "Framework for Services Supported on 1305 International Mobile Telecommunications-2000 (IMT-2000)", 1992. 1307 9. IETF, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 1309 10. IETF, "SDP: Session Description Protocol", RFC 2327, April 1998. 1311 11. IETF, "Dynamic Host Reconfiguration Protocol", RFC 2131, March 1312 1997. 1314 12. S. Donavon, "The SIP INFO Method", 1315 , work in progress, 1316 June 1999. 1318 13. D. Lam, Y. Cui, D.C. Cox, and J. Widom, "A Location Management 1319 Technique To Support Lifelong Numbering in Personal 1320 Communications", January 1998. 1322 14. A. McAuley, S. Das, and S. Baba, Y. Shobatake, "Dynamic 1323 Registration and Configuration Protocol for Mobile Hosts", 1324 , work in progresss, October 1999. 1326 15. Y. Rekhter, and M. Stapp, "Interaction between DHCP and DNS", 1327 , work in progress, June 1999. 1329 16. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP", ACM 1330 Multimedia Workshop, Seattle, August 1999. 1332 17. IETF, "IP Mobility Support", RFC 2002, October 1996. 1334 18. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP", 1335 , February 25, 1999. 1337 19. IETF, "IP Encapsulation within IP", RFC 2003, October 1996. 1339 20. IETF, "Minimal Encapsulation within IP", RFC 2004, October 1996. 1341 21. IETF, "Resource reSerVation Protocol (RSVP) -- Version 1 1342 Functional Specification", RFC 2205, September 1997. 1343 22. DCS Group, "Integration of Resource Management and Call 1344 Signaling for IP Telephony", , work in progress, August 1999. 1347 10. Authors' Addresses 1349 Faramak Vakil 1350 farm@research.telcordia.com 1351 Telcordia Technologies, Rm 1C-135B, 1352 445 South Street, Morristown, NJ 07960-6438. 1354 Ashutosh Dutta, 1355 adutta@research.telcordia.com 1356 Telcordia Technologies, Rm 1B-217B 1357 445 South Street, Morristown, NJ 07960-6438. 1359 Jyh-Cheng Chen, 1360 jcchen@research.telcordia.com 1361 Telcordia Technologies, Rm 1G-236B, 1362 445 South Street, Morristown, NJ 07960-6438. 1364 Shinichi Baba 1365 sbaba@tari.toshiba.com 1366 Toshiba Research America Inc. (TARI) 1367 P. O. Box 136 1368 Convent Station, NJ 07961-0136 1370 Yasuro Shobatake 1371 yasuro.shobatake@toshiba.co.jp 1372 Toshiba Research America Inc. (TARI) 1373 P. O. Box 136 1374 Convent Station, NJ 07961-0136