idnits 2.17.1 draft-subbarao-mobileip-resource-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 571 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 80 instances of lines with control characters in the document. ** 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 128: '...gement extension MAY be attached to an...' RFC 2119 keyword, line 158: '...for future use. MUST be set to 0 on s...' RFC 2119 keyword, line 159: '... MUST be ignored on receiving....' RFC 2119 keyword, line 165: '...gement Extension MUST be protected by ...' RFC 2119 keyword, line 214: '... This bit MUST be set if the target m...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Individual submission Kent Leung', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-10 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-05 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-08) exists of draft-ietf-mobileip-rfc2002-bis-01 -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Rajesh Bhalla 2 Category: Individual submission Kent Leung 3 Title: draft-subbarao-mobileip-resource-00.txt Alpesh Patel 4 Expires September 2001 Madhavi Subbarao 5 Mobile IP Working Group Cisco Systems 7 Releasing Resources in Mobile IP 8 draft-subbarao-mobileip-resource-00.txt 10 Status of this Memo 12 This document is an Internet Draft and is in full compliance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that 17 other groups may also distribute working documents as Internet 18 Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is inappropriate to use Internet 23 Drafts as reference material or to cite them other than as "work in 24 progress". 26 The list of current Internet Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Currently, in Mobile IP when an MN moves from one FA to another 35 FA/CoA, relevant resources at the previous FA are consumed until 36 its visitor entry for the MN expires. The Resource Release Message 37 and Resource Management Extension described in this draft will 38 facilitate the release of these valuable resources at the previous FA 39 as the MN moves to a new location. The HA notifies the previous FA of 40 any changes in the CoA for an MN, thereby allowing the FA to release 41 its resources. Similary, when used in the opposite direction, 42 valuable resources at an HA can be released for an MN if there is 43 early termination on the FA side. Use of the Resource Release Messages 44 and Resource Management Extension will lead to increased network 45 efficiency and system capacity. 47 1. Introduction 49 Currently, in Mobile IP when a Mobile Node (MN) moves from one Foreign 50 Agent (FA) to another FA/Care-of-Address (CoA), relevant resources at 51 the previous FA are consumed until its visitor entry for the MN 52 expires. Similary, if there is early termination of an MN on the FA 53 side relevant resources at the HA remained consumed until the mobility 54 binding for the MN expires. This leads to inefficient use of network 55 resources which directly affects the efficiency of a Mobile IP network 56 deployment. 58 For example, consider a cdma2000 network deployment using Mobile IP. 59 The Wireless IP Network Standard (IS-835) defines FA/Packet Data 60 Servicing Node (PDSN) procedures for managing the PPP session for a 61 MN, i.e., when the Radio Network opens an R-P session for an MN, the 62 FA/PDSN initiates establishment of a PPP session [1]. As an MN moves 63 from one foreign domain serviced by an FA/PDSN (source PDSN) to 64 another PDSN (target PDSN) during an inter-PDSN handoff, a Mobile IP 65 registration is sent to the Home Agent (HA) and a new PPP session is 66 established at the target PDSN. The PPP session at the source PDSN 67 remains exhausted until the PPP inactivity timer expires. Maintaining 68 these PPP sessions consumes valuable resources at the source PDSN that 69 could otherwise be used to support additional MNs. Thus, it is 70 desirable and more efficient to release the idle PPP session at the 71 source PDSN as soon as possible. The Mobile IP infrastructure should 72 allow for intelligent signaling which would trigger release of the 73 resources at the PDSN/FA. 75 A possible solution is to utilize the Previous Foreign Agent 76 Notification extension offered by Route Optimization in Mobile IP 77 [2]. This extension triggers the new FA to send a Binding Update (BU) 78 to the previous FA to inform it that the MN has moved. As a result, 79 if the previous FA supports resource management, it releases the 80 resources that it was using for the MN. The Previous Foreign Agent 81 Notification extension, however, must be initiated by the MN, i.e., 82 the MN must include the extension in a Registration Request (RRQ) to 83 the new FA to instruct the new FA to send a BU to the previous FA. 84 Although this is possible, it may not be a practical or viable 85 solution since it requires modification to all mobile devices to 86 include the Previous Foreign Agent Notification extension. Moreover, 87 the BU is sent by the new FA regardless of the resource management 88 capabilities of the previous FA. If the previous FA cannot support 89 resource management or understand the messaging, extra signaling and 90 processing has unnecessarily occurred. Note that this solution is 91 dependent on Route Optimization [2] being employed in the network and 92 does not support releasing resources at the HA. 94 Although intended for a different purpose, a Registration Revocation 95 message as specified in [6] can be sent by the HA to the previous FA 96 upon an MN's movement to a new FA/Care-of-Address (CoA). The result 97 of this message is that resources at the previous FA will be 98 released. Similary, an HA can be informed of termination of an MN on 99 the FA side and thus, release its resources. Currently, the 100 functionality in [6] is subject to denial-of-service attacks since the 101 Registration Revocation beacon, i.e., agent advertisement with 102 sequence number reset, is not authenticated and can be spoofed 103 (communication to the MN). The Registration Revocation message is also 104 sent to the previous FA or HA regardless of their resource management 105 capabilities. 107 This draft proposes a Mobile IP Resource Management Extension that 108 may be appended to an RRQ by an FA that supports resource management, 109 and appended to a Registration Reply (RPY) by an HA that supports 110 resource management. When an HA receives an authenticated RRQ from an 111 MN with a Resource Management Extension, it records the capability of 112 the FA. The HA then uses the Resource Release Message defined in 113 this draft to notify the FA regarding a change in the CoA for the MN . 114 As a result, the FA deletes the visitor entry for the MN and releases 115 the resources being used to support the MN. 117 Similarly, when an FA receives an authenticated RPY from an HA with a 118 Resource Management Extension, it records the capability of the HA. 119 The FA uses the Resource Release Message to notify the HA if there is 120 early termination of an MN on the FA side. The HA then deletes the 121 mobility binding for the MN and releases relevant resources for the MN. 123 Acknowledgement signaling may be used to ensure earnest effort to 124 release resources. 126 2. Mobile IP Resource Management Extension 128 The Mobile IP Resource Management extension MAY be attached to an 129 RRQ by an FA or an RPY by an HA. It is based on the Short Extension 130 Format given in [3] and is defined as follows: 132 0 1 2 3 133 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Type | Length | Subtype |A| Reserved | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Mobile Node Home Address | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Type 141 Skippable (TBD) 143 Length 144 Length (in bytes). Does NOT include Type and Length. 146 Subtype 147 1 (Resource Management Extension) 149 'A' Bit 150 When this bit is set, the mobility agent is specifying 151 that it will send an Acknowledgement in receipt of a 152 Resource Release Message. If an Acknowledgement is 153 not received, the Resource Release Message should be 154 retransmitted. This will ensure an earnest attempt to 155 release resources. 157 Reserved 158 Reserved for future use. MUST be set to 0 on sending, 159 MUST be ignored on receiving. 161 Mobile Node Home Address 162 The home IP address of the Mobile Node to which the 163 extension refers. 165 The Mobile IP Resource Management Extension MUST be protected by a 166 FA-HA Authentication Extension (FHAE) as defined in [4]. 168 3. Resource Release Message 170 The Resource Release Message is used between mobility agents to notify 171 one another that resources for an MN or group of MNs may be released. 173 IP layer fields of the message: 175 Source Address: 176 IP address of the mobility agent initiating the 177 message. If the HA is initiating the message, 178 the address is the IP address of the HA. If the FA is 179 initiating the message, the address is the IP address of the FA. 181 Destination Address: 182 IP address of the target mobility agent for the message. If 183 the HA is initiating the message, the destination address is 184 the IP address of the FA. If the FA is initiating the 185 message, the destination address is the IP address of the HA. 187 UDP fields of the message: 189 Source Port 434 190 Destination Port 434 192 Mobile IP fields of the message: 194 0 1 2 3 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type | Subtype |A| Reserved | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Mobile Node Home Address | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | HA/FA Address | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 + Identification + 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Type TBD 210 Subtype 211 1 Enable release of resources 213 'A' bit 214 This bit MUST be set if the target mobility agent 215 set the 'A' bit in its Resource Management Extension. 217 Reserved 218 Reserved for future use. MUST be set to 0 on sending 219 and ignored on receiving. 221 Mobile Node Home Address 222 The Home IP address of the MN whose resources 223 should be released. MAY be set to zero to denote a 224 group of MNs (see Sections 6 and 7). 226 HA/FA Address 227 The IP address of the mobility agent initiating the 228 message. 230 Identification 231 A 64-bit number used for protecting against replay 232 attacks as defined in [4]. Used in a similar manner as 233 described in [4]. 235 The Mobile IP Resource Release Message MUST be protected by the FHAE. 237 4. Resource Release Acknowledgement Message 239 The Resource Release Acknowledgement Message is sent by a mobility agent 240 that set the 'A' bit in its Resource Management Extension upon the 241 receipt of a Resource Release Message. 243 IP layer fields of the message: 245 Source Address: 246 IP address of the mobility agent initiating the acknowledgement 247 message. If the HA is initiating the message, 248 the address is the IP address of the HA. If the FA is 249 initiating the message, the address is the IP address of the FA. 251 Destination Address: 252 IP address of the target mobility agent for the 253 acknowledgement message. If the HA is initiating the message, 254 the destination address is the IP address of the FA. If the 255 FA is initiating the message, the destination address is the 256 IP address of the HA. 258 UDP fields of the message: 260 Source Port 434 261 Destination Port 434 263 Mobile IP fields of the message: 265 0 1 2 3 266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Reserved | Status | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Mobile Node Home Address | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 + Identification + 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Type TBD 279 Reserved 280 Reserved for future use. MUST be set to 0 on sending 281 and ignored on receiving. 283 Status 284 If the Resource Release Message was received without 285 error, this field is set to zero. However, if there 286 is an error in reception, the field is nonzero with 287 the following allowable codes defined in [4]: 289 128 reason unspecified 290 129 administratively prohibited 291 130 insufficient resources 292 131 sending node failed authentication 293 133 identification mismatch 294 TBD poorly formed Resource Release Message (see 295 Section 8) 297 Mobile Node Home Address 298 Copied from the Resource Release Message being 299 acknowledged. 301 Identification 302 Copied from the Resource Release Message being 303 acknowledged. 305 The Resource Release Acknowledgement Message MUST be protected by the 306 FHAE as defined in [4]. 308 5. Mobile Node Considerations 310 There are no modifications in behavior required by the MN. 312 6. Foreign Agent Considerations 314 If an FA is capable of resource management, understands the Resource 315 Release Message, and shares a security association with the HA, it 316 SHOULD append the Mobile IP Resource Management Extension to an RRQ 317 received from an MN. The FA MAY set the 'A' bit in the extension to 318 indicate that it will acknowledge the received Resource Release 319 Messages. The FA MUST protect this extension with an FHAE. By 320 appending this extension, the FA informs the HA that it is capable of 321 managing network resources and should be notified of a change in this 322 MN's CoA. 324 Upon receipt of a Resource Release Message from an HA, the FA MUST 325 check for proper authentication and identification of the message as 326 defined in [4]. If the FHAE or Identification is not valid, the FA 327 MUST silently discard the message. If the Resource Release Message is 328 properly authenticated and the MN home address and HA address in the 329 message match an entry in its visitor table, the FA SHOULD delete the 330 visitor entry and release relevant resources for the MN. (For 331 example, see [5] for resource releasing behavior of a PDSN in a 332 cdma2000 network.) If the MN address field in the message is set to 333 zero, the FA SHOULD delete all entries in its visitor table that match 334 the HA address field in the message, i.e., all MNs that are serviced 335 by the HA specified in the Resource Release Message. Furthermore, the 336 FA SHOULD release all relevant resources for the MNs. If the 'A' bit 337 is set in the Resource Release Message (which means that it was set in 338 the Resource Management Extension sent by the FA), the FA MUST send a 339 Resource Release Acknowledgement Message back to the HA. 341 If the FA is releasing resources of MN(s) as a result of a received 342 Resource Release Message from the HA, the FA MUST NOT send a Resource 343 Release Messsage back to the HA. 345 If the FA receives an authenticated RPY with a Resource Management 346 Extension appended, the FA MUST ensure that the FHAE is valid. If the 347 FA-HA authentication fails, the HA must proceed as outlined in [4] and 348 reject the RPY. If the HA does not support the Resource Management 349 Extension, it should simply ignore the extension. 351 After authenticating the FHAE, the FA should record the capability of 352 the HA, e.g., set a Resource Management Flag and an Acknowledgement 353 Flag (if necessary) in the visitor entry information for the MN. If 354 there is an early termination on the FA side for the MN, the FA SHOULD 355 send a Resource Release Message to the HA. The FA should set the MN 356 address field to the home IP address of the MN, the HA/FA address to 357 its own IP address, and the Identification field and 'A' bit 358 appropriately. The FA MUST include the FHAE. 360 If the FA wishes to notify the HA that all MNs serviced by the FA 361 should be released, the FA sends the Resource Release Message with the 362 MN address set to zero, HA/FA address set to its own IP address, 363 and Identification field and 'A' bit set appropriately. The FA MUST 364 include the FHAE. 366 Upon sending a Resource Release Message with the 'A' bit set, if the 367 FA does not receive an Resource Release Acknowledgement Message from 368 the HA, it SHOULD retransmit the message. 370 7. Home Agent Considerations 372 If an HA shares a security association with an FA, understands the 373 Resource Release Message, and supports resource management, the HA 374 SHOULD append the Resource Management Extension to an RPY. The HA MAY 375 set the 'A' bit in the extension to indicate that it will acknowledge 376 the received Resource Release Message. The HA must protect the 377 extension with the FHAE. By including this extension, the HA informs 378 the FA that it wishes to be notified of termination of the visitor 379 entry for the MN. 381 Upon receipt of a Resource Release Message from an FA, the HA MUST 382 check for proper authentication and identification of the message as 383 defined in [4]. If the FHAE or Identification is not valid, the HA 384 MUST silently discard the message. If the Resource Release Message is 385 properly authenticated and the MN home address and FA address in the 386 message match an entry in its mobility binding table, the HA SHOULD 387 delete the mobility binding and release relevant resources for the 388 MN. If the MN address field in the message is set to zero, the HA 389 SHOULD delete all mobility bindings with CoA matching the FA address 390 field in the message, i.e., all MNs that are serviced by the FA 391 specified in the Resource Release Message. Furthermore, the HA SHOULD 392 release all relevant resources for the MNs. If the 'A' bit is set in 393 the Resource Release Message (which means that it was set in the 394 Resource Management Extension sent by the HA), the HA MUST send a 395 Resource Release Acknowledgement Message back to the FA. 397 If the HA is releasing resources for MN(s) as a result of a received 398 Resource Release Message from the FA, the HA MUST NOT send a Resource 399 Release Messsage back to the FA. 401 If an HA receives an RRQ from an MN with a valid MN-HA Authentication 402 Extension and a Resource Management Extension, it MUST ensure that the 403 FHAE is valid. If the FA-HA authentication fails, the HA must proceed 404 as outlined in [4] and reject the RRQ. If the HA does not support the 405 Resource Management Extension, it should simply ignore the extension. 407 After authenticating the FHAE, the HA should record the capability of 408 the FA, e.g., set a Resource Management Flag and Acknowledgement Flag 409 (if necessary) in the mobility binding information for the MN. When 410 the HA receives an RRQ from the MN via a new FA (or different CoA) or 411 a deregistration, and if the HA is aware that the previous FA supports 412 resource management, e.g., a Resource Management Flag in the mobility 413 binding is set, the HA SHOULD send a Resource Release Message to the 414 previous FA notifying the FA of the change in CoA. The HA sets the MN 415 address field in the message to the home address of the MN, the HA/FA 416 address field to its own IP address, the 'A' bit appropriately, and 417 the Identification field similar to that specified in [4]. The HA 418 MUST include the FHAE. 420 If the HA wishes to notify an FA that supports resource management 421 that all MNs serviced by the HA should be released, the HA sends the 422 Resource Release Message with the MN address set to zero, HA/FA 423 address set to its own IP address, and Identification field and 'A' 424 bit set appropriately. The HA MUST include the FHAE. 426 Upon sending a Resource Release Message with the 'A' bit set, if the 427 HA does not receive an Resource Release Acknowledgement Message from 428 the FA, it SHOULD retransmit the message. 430 8. Error Code 432 The error code "poorly formed Resource Release Message" was introduced in 433 Section 4 and may be returned in a Resource Release Acknowledgement Message. 434 This error code conveys that the Resource Release Message was not 435 properly formed and could not be parsed by the receiving mobility agent. 437 9. IANA Considerations 439 The Mobile IP Resource Management Extension defined in Section 2 is a 440 Mobile IP registration extension as defined in RFC 2002 [4]. IANA should 441 assign a Type value consistent with this number space. The Mobile IP 442 Resource Release Message defined in Section 3 and Resource Release 443 Acknowledgement Message defined in Section 4 should be assigned Type 444 values consistent with the number space defined in [4]. The Code value 445 in Section 8 is an error code as defined in RFC 2002 [4]. IANA should 446 assign a value to the code consistent with this number space. 448 10. Security Considerations 450 Mobile IP registration messages are authenticated, and the 451 authentication verified by the recipient. The Mobile IP Resource 452 Management Extension, Resource Release Message, and Resource Release 453 Acknowledgement Message are protected by the FHAE [4]. 455 Appendix A: 457 If Route Optimization [2] is used in the network, Binding Updates 458 can be used for signaling between the HA and FA to notify the FA to 459 release its resources. In order to support BU signaling from an FA to 460 an HA, the Route Optimization draft [2] needs to be modified to allow 461 for a BU to be sent from an FA to an HA, and for the HA to be able to 462 process a BU. Note, however, that the generic feature of releasing a 463 group of MNs (MN address of zero in the Resource Release Message) can 464 not be achieved with Binding Updates. 466 11. References 468 [1] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000. 470 [2] C. Perkins and D. Johnson, Route Optimization in Mobile IP, 471 Internet Draft, Internet Engineering Task Force, 472 draft-ietf-mobileip-optim-10.txt, Work in progress, November 2000. 474 [3] M. Khalil, et. al., Mobile IP Extensions Rationalization (MIER), 475 Internet Draft, Internet Engineering Task Force, 476 draft-ietf-mobileip-mier-05.txt, Work in progress, May 2000. 478 [4] C. Perkins, IP Mobility Support for IPv4, revised, Internet 479 Draft, Internet Engineering Task Force, 480 draft-ietf-mobileip-rfc2002-bis-01.txt, Work in progress, January 2000. 482 [5] Rajesh Bhalla, "PPP Resource Management at the 483 PDSN". 3Gpp2-P00-20010115-011, Cisco Systems, January 2001. 485 [6] S. Glass, Registration Revocation for Mobile IP, Internet Draft, 486 Internet Engineering Task Force. draft-glass-mobileip-reg-revok-00.txt, 487 Work in progress, July 2000. 489 Author's Addresses 491 Questions about this memo can be directed to: 493 Rajesh Bhalla 494 Cisco Systems, Inc. 495 170 West Tasman Drive 496 San Jose, CA 95134 497 USA 498 email: rabhalla@cisco.com 499 phone: +1 408 853 9265 500 fax: +1 408 502 Kent Leung 503 Cisco Systems, Inc. 504 170 West Tasman Drive 505 San Jose, CA 95134 506 USA 507 email: kleung@cisco.com 508 phone: +1 408 526 5030 509 fax: +1 408 526 4952 511 Alpesh Patel 512 Cisco Systems, Inc. 513 170 West Tasman Drive 514 San Jose, CA 95134 515 USA 516 email: alpesh@cisco.com 517 phone: +1 408 853 9580 518 fax: +1 408 526 4952 520 Madhavi Subbarao 521 Cisco Systems, Inc. 522 7025 Kit Creek Road 523 Research Triangle Park, NC 27709 524 USA 525 email: msubbara@cisco.com 526 phone: +1 919 392 8387 528 Expires September 2001