home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-ruth-cdpd-networks-00.txt < prev    next >
Text File  |  1996-08-07  |  28KB  |  617 lines
  1.  
  2. Internet Engineering Task Force                   G. Ruth, R. Yuan
  3. INTERNET DRAFT                                    GTE Laboratories
  4.                                                      6 August 1996
  5.  
  6.  
  7.          Interworking Between CDPD and Mobile IP Networks
  8.                 draft-ruth-cdpd-networks-00.txt
  9.  
  10. Abstract
  11.  
  12. Two protocols, CDPD (Cellular Digital Packet Data) and Mobile-IP
  13. have been developed by the CDPD Forum and IETF (Internet
  14. Engineering Task Force) respectively to address the issue of
  15. providing seamless network access to mobile data devices. In this
  16. memo a scheme is proposed for the two networks to interwork
  17. together and to support seamless migration of mobile data devices
  18. between the networks.
  19.  
  20.  
  21. Status of this Memo
  22.  
  23. This document is an Internet-Draft. Internet-Drafts are working
  24. documents of the Internet Engineering Task Force (IETF), its
  25. areas, and its working groups. Note that other groups may also
  26. distribute working documents as Internet-Drafts.
  27.  
  28. Internet-Drafts are draft documents valid for a maximum of six
  29. months and may be updated, replaced, or obsoleted by other
  30. documents at any time. It is inappropriate to use Internet-Drafts
  31. as reference material or to cite them other than as ``work in
  32. progress.''
  33.  
  34. To learn the current status of any Internet-Draft, please check
  35. the ``1id-abstracts.txt'' listing contained in the Internet-
  36. Drafts Shadow Directories on ds.internic.net (US East Coast),
  37. nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  38. munnari.oz.au (Pacific Rim).
  39.  
  40.  
  41. 1. Introduction
  42.  
  43. Two protocols, CDPD and Mobile IP, have been developed in the past
  44. few years to address the issue of network layer mobility support
  45. for the general purpose data network. Both protocols enable a
  46. mobile terminal to migrate seamlessly from one local area network
  47. to another.
  48.  
  49. The CDPD (Cellular Digital Packet Data) standard was developed by
  50. the CDPD Forum (an industrial association of cellular carriers,
  51. equipment vendors and application developers) to provide packet
  52. data services through the cellular telephony network. It specifies
  53. a set of mobility enabling protocols for use in the CDPD networks.
  54. CDPD networks is being deployed nationwide by the cellular
  55. carriers. The latest specification CDPD Specification, version 1.1
  56. was published in January 1995 [1].
  57.  
  58. The Mobile-IP protocol has been developed by the IETF to provide
  59. mobility support in the current TCP/IP Internet. Mobile-IP is
  60. designed to support transparent host migration among a variety of
  61. IP subnetworks.
  62.  
  63. The concepts and principles for mobility management in both
  64. protocols are the same and many of mobility support functions are
  65. similar. However, while CDPD is designed to be a tariffed, carrier
  66. operated service with uniform link layer infrastructure (it has
  67. been widely deployed by many cellular carrier), Mobile IP is
  68. designed to support a variety of heterogeneous subnetworks. Thus,
  69. many differences exist between the two protocols. Currently, if a
  70. Mobile IP host migrates into a CDPD coverage area (or vice versa),
  71. its network connection will be terminated even with a CDPD
  72. wireless modem. This is because the network layer protocols for
  73. mobility support of the two networks cannot interoperable with
  74. each other. Therefore, to enable universal network connectivity
  75. for mobile hosts, it is necessary to provide methods for the two
  76. networks to internetwork with each other.
  77.  
  78. This memo compares the mobility management functions for CDPD and
  79. Mobile IP networks and suggests ways to support internetworking
  80. between the two networks.
  81.  
  82.  
  83. 2. Mobility Support in CDPD Networks
  84.  
  85. CDPD is designed to exploit the unused capacity of the cellular
  86. telephone network for packetized data delivery. It leverages the
  87. existing cellular infrastructure by adding CDPD specific equipment
  88. to the existing cell sites. The CDPD network architecture makes
  89. use of three distinctive devices:
  90.  
  91.    o  MES: Mobile End System -- A mobile terminal with a wireless
  92.       modem that accesses the CDPD network through an airlink.
  93.       Each MES may have one or more Network Entity Identifiers
  94.       (NEIs) which are IP or CLNP addresses. The CDPD modem also
  95.       has a 48-bit CDPD equipment identifier assigned by the
  96.       manufacturer.
  97.  
  98.    o  MDBS: Mobile Data Base Station -- provides the mobile
  99.       data link relay function for the MES over the radio channel.
  100.       It performs part of the radio resource management function
  101.       to ensure that the data user doesn't interfere with the
  102.       regular voice users.
  103.  
  104.    o  MDIS: Mobile Data Intermediate System -- controls mobility,
  105.       performs registration, authentication and routing functions.
  106.       It also controls the MDBS for radio resource management. The
  107.       MDIS is a full-fledged network router.
  108.  
  109. Additionally, the CDPD architecture uses the term "Fixed End
  110. System" (FES) to denote an ordinary hardwired network end system.
  111.  
  112. The logical CDPD network architecture is shown in Figure 1:.
  113.  
  114.                           +------------------+
  115.                           |                  |
  116.    MES....MDBS-----MDIS---| IP/CLNP Backbone |---Router--FES
  117.                           |                  |
  118.                           +------------------+
  119.  
  120.           Figure 1: Logical CDPD Network Architecture
  121.  
  122.  
  123. In a CDPD network, each wireless local network (termed as AREA)
  124. consists of one MDIS and up to 200 base stations (MDBSs). The
  125. mobile end system (MES) uses a multiple access scheme (Digital
  126. Sensing Multiple Access: DSMA) that gives packet data lower
  127. priority than voice traffic to access the cellular network.
  128. Because the MDBS is only involved in the data link relay function,
  129. the MES can roam transparently within the AREA using the different
  130. MDBSs for the data relay service, while maintaining the same data
  131. link connection between the MDIS and MES. Thus the AREA can be
  132. treated as a single network segment (e.g. Ethernet). Because there
  133. is one and only one MDIS within one AREA, the MDIS serves as the
  134. default gateway to/from the local network. It advertises the
  135. reachability of this network segment to other routers in the
  136. IP/CLNP backbone network.
  137.  
  138. The CDPD Forum has obtained several Class B IP addresses with
  139. prefix 166 from IANA. Thus, all the CDPD network AREAs use 166 as
  140. the network prefix.
  141.  
  142. If the MES roams from one AREA to another, the MES recognizes that
  143. it is in a new AREA during the cell transfer by listening to the
  144. channel identification message broadcasted from the base station
  145. during the channel acquisition time. It then initiates a new
  146. registration process using the MNRP (Mobile Network Registration
  147. Protocol) with the new MDIS. The serving MDIS handles the
  148. registration for the MES.  It also communicate with the home MDIS
  149. of the MES so that appropriate authentication can be performed,
  150. and an appropriate routing entry can be set up at the home MDIS to
  151. forward packets destined to the mobile end system to the new
  152. foreign area. Figure 2 depicts the information flow for such an
  153. inter-AREA migration
  154.  
  155.  
  156.                   old serving       new serving            home
  157.  MES                  MDIS              MDIS               MDIS
  158.  
  159.  |--cell exit decision--|                 |                  |
  160.  |                      |                 |                  |
  161.  |--cell selection & entry decision ------|                  |
  162.  |                      |                 |                  |
  163.  |--data link establishment---------------|                  |
  164.  |                      |                 |                  |
  165.  |--end system hello ---+---------------->|                  |
  166.  |                      |                 |                  |
  167.  |                      |                 |---redirect req-->|
  168.  |                      |                 |                  |
  169.  |                      |                 |<--redirect con --|
  170.  |                      |                 |                  |
  171.  |<--intermediate system confirm (ISC)----|                  |
  172.  |                      |                 |                  |
  173.  |                      |<--------redirect flush (RDF)-------|
  174.  
  175.       Figure 2: Information Flow for Inter-AREA Migration
  176.  
  177. One key aspect of an MES migrating into a new area is the
  178. associated authentication to verify the identity of the MES. In
  179. the CDPD network, airlink security is accomplished by exchanging
  180. secret keys between the serving MDIS and the visiting MES using a
  181. Diffie-Hellman key exchange scheme. After the MES obtains the key
  182. from the MDIS, it sends the authentication information tuple <NEI,
  183. ARN, ASN> (where ARN = Authentication Sequence Number and ASN =
  184. Authentication Sequence Number) to the serving MDIS in the End
  185. System Hello message. This information is relayed to the home MDIS
  186. for authentication in cleartext through the wired network.
  187.  
  188. After authenticating the MES, the home MDIS returns a success
  189. message and assigns a new <authentication random number,
  190. authentication sequence number> to the serving MDIS in the
  191. Redirect Confirm message; the information is relayed to the MES
  192. and can be used for authentication in the next registration.
  193.  
  194. The data packet forwarding from the home MDIS to the serving MDIS
  195. is done by encapsulating each IP/CLNP packet into a new CLNP
  196. packet. The destination address of the new CLNP packet is the
  197. serving MDIS. When the serving MDIS receives the encapsulated CLNP
  198. packet, it decapsulates the packet and delivers to the MES using
  199. the established data link channel. This triangular routing scheme
  200. (shown in Figure 3) is similar to Mobile IP triangular routing. As
  201. with Mobile IP, the CDPD MES keeps its IP address at all times.
  202.  
  203.  
  204.                          serving               home
  205.          MES<...>MDBS<--->MDIS<================MDIS
  206.                               \                 /\
  207.                                \                |
  208.                                 \               |
  209.                                  \              |
  210.                                   ------------>host
  211.  
  212.            === indicates an encapsulated flow
  213.  
  214.         Figure 3: Packet Forwarding in a CDPD Network
  215.  
  216.  
  217. 3. Mobility Support in Mobile IP networks
  218.  
  219. Mobile IP is designed to support host mobility in the current
  220. Internet Protocol (IPv4). Therefore, any internet host with an
  221. arbitrary IP address can be a mobile host migrating into a foreign
  222. network. In addition, a local network segment may have multiple
  223. routers attached, so that the routing path to/from the local
  224. network is not unique. To address these issues, the basic
  225. architecture of Mobile IP defines two entities: Home Agent (HA)
  226. and Foreign Agent (FA). The FA is located in the serving (foreign)
  227. network and provides direct network access to the mobile host (MH)
  228. when needed. The HA is responsible for intercepting IP packets
  229. destined to the mobile host and forwarding them to the serving FA
  230. of the mobile host. Because the mobile host may not be able to
  231. detect a subnet change through the link layer protocol, the FA/HA
  232. explicitly advertise their presence using Agent Advertisement
  233. messages (an extension of the ICMP router advertisement message, a
  234. network layer service).
  235.  
  236. When a mobile host migrates into a new local area it recognizes the
  237. new network from the Agent Advertisement message broadcasted
  238. periodically from the FA. The network layer broadcast of the agent
  239. advertisement message is necessary because there may not be a data
  240. link layer mechanism to detect the network segment change. The Agent
  241. Advertisement message includes one or more Care-of-Addresses (COAs)
  242. from the FA, encapsulation type(s) supported by the FA, registration
  243. lifetime and advertisement sequence number. The MH then initiates a
  244. registration process with the home agent using UDP messages with
  245. destination port 434. The registration message is relayed through
  246. the serving FA in the foreign network. The registration process
  247. enables the HA to update its mobility binding <MH, COA, last message
  248. ID, registration lifetime> for the migrated mobile host so that
  249. packets can be forwarded to the new location (COA).
  250.  
  251. To address the authentication and security concerns, Mobile IP
  252. defines flexible authentication extensions that can be added to
  253. the registration message using keyed-MD5. Both mobile-HA and
  254. mobile-FA authenticators can be attached to the registration
  255. message for proper authentication. While different authentication
  256. schemes can be employed by the MH, FA and HA through service
  257. agreement in advance, the Mobile IP standard specifies a default
  258. authentication method using the MD5 algorithm (RFC 1321). The
  259. algorithm computes a one-way hash function that produces a 128-bit
  260. "message digest" for an arbitrary long registration message. The
  261. shared secret key is pre-configured for the MH - HA
  262. authentication. For MH-FA authentication, the key can either be
  263. distributed manually, or using public key. The information flow of
  264. the registration messages is depicted in Figure 4.
  265.  
  266. MH                  new FA            old FA                HA
  267.  
  268.  |--Registration Req-->|                 |                   |
  269.  |                     |                 |                   |
  270.  |                     |-----------Registration Req--------->|
  271.  |                     |                 |                   |
  272.  |                     |<---------Registration Reply---------|
  273.  |                     |                 |                   |
  274.  |<-Registration Reply-|                 |                   |
  275.  
  276.    Figure 4: Information Flow for MobileIP Registration Messages
  277.  
  278. The Mobile IP protocol also defines an option for the MH to act as
  279. its own FA, if the foreign network has no FA and the MH can obtain
  280. a local address from the DHCP server (e.g. using anycast
  281. mechanism). In this case, the Care-of-Address is the newly
  282. obtained the local IP address from DHCP server.
  283.  
  284. It is also noted that there is no registration cancellation
  285. message sent to the old FA when registration at the new FA becomes
  286. active. Because IP provides best effort datagram delivery, the
  287. packets in transit will simply be dropped and the old registration
  288. will expire after the validation period.
  289.  
  290. Similar to the CDPD approach, the packet forwarding in Mobile IP
  291. is carried out using encapsulation/decapsulation. The HA
  292. intercepts each packet destined to the MH and then encapsulate the
  293. packet using the COA in the mobility binding of the MH. Upon
  294. receiving the encapsulated packet, the FA decapsulates the packet
  295. and sends it directly to the MH using its own link layer protocol.
  296. Figure 5 shows the packet forwarding in Mobile IP.
  297.  
  298.             MH<----FA<=========================HA
  299.                \                               /\
  300.                 \                              |
  301.                  \                             |
  302.                   \                            |
  303.                     ------------------------->host
  304.  
  305.             === indicates an encapsulated flow
  306.  
  307.       Figure 5: Packet Forwarding in a Mobile IP Network
  308.  
  309. Two encapsulation methods are defined in the Mobile IP standard:
  310. Minimum encapsulation and IP within IP (IPIP). IPIP encapsulation
  311. is the recommended encapsulation method. The IPIP method handles
  312. packet fragmentation easily but adds more overhead to the
  313. encapsulated packet.
  314.  
  315.  
  316. 4. Comparison between CDPD and Mobile IP
  317.  
  318. CDPD and Mobile IP are designed to support general purpose network
  319. layer mobility for packet data networks. In particular, both are
  320. designed to support network layer mobility in the IP network, thus
  321. enabling mobile host migration in the Internet. The basic mobility
  322. management functions for CDPD and Mobile IP networks are based on
  323. the same concepts and principles (e.g. packet encapsulation and
  324. forwarding).
  325.  
  326. Although many of the mobility management concepts and functions in
  327. CDPD and Mobile IP are similar, the detailed message formats
  328. differs from each other. In addition, there are several notable
  329. difference in the protocol:
  330.  
  331.    o  In CDPD, the MES can detect the network segment change from
  332.       the link layer support, while in mobile IP, the explicit
  333.       Agent Advertisement message is necessary for the mobile host
  334.       to detect network change.
  335.  
  336.    o  In CDPD, the registration process is separated into two
  337.       stages. First, the MES registers with the serving MDIS
  338.       using the MNRP, where no authentication is required.
  339.       Second, the serving MDIS uses a separate protocol, MNLP,
  340.       to update the location information to the home MDIS and
  341.       forward the authentication information from the MES to
  342.       the home MDIS for authorization. In Mobile IP, the mobile
  343.       host registers directly with the HA, while the FA provides
  344.       the relay service to the registration services.
  345.  
  346.    o  In CDPD, the home MDIS informs the previous serving MDIS
  347.       to flush the MES's registration record, while in Mobile IP,
  348.       multiple simultaneous registration records with different
  349.       FAs for a mobile host are permitted.
  350.  
  351.    o  Because of the uniqueness of the MDIS, it is guaranteed
  352.       that the home MDIS can intercept the packet destined to
  353.       the MES, while in mobile IP, the HA needs to use the proxy
  354.       ARP protocol to advertise the mobile host reachability in
  355.       order to intercept the packet.
  356.  
  357.    o  CDPD defines a single encapsulation method between the
  358.       home MDIS and the serving MDIS. All the packets forwarded
  359.       to the serving MDIS are encapsulated using a CLNP packet
  360.       with minimum encapsulation header to increase efficiency.
  361.       In Mobile IP, two encapsulation methods are defined with
  362.       IP within IP as the recommended method.
  363.  
  364. The protocol architecture for registration in CDPD and Mobile IP
  365. differ as follows. The CDPD registration procedure is separated
  366. into two phases (MNRP and MNLP), different from the one phase
  367. approach of Mobile IP. In addition, the CDPD's MNLP defines
  368. several message to allow the MDISs to exchange location update
  369. information without the involvement of MES. Furthermore, the
  370. registration message contents of CDPD and Mobile IP is different.
  371. The information fields contained in these messages are listed in
  372. Table 1.
  373.  
  374.                        CDPD                   MobileIP
  375.  
  376.    Parameter      Field Name     M/O     Field Name       M/O
  377.  
  378. Permanent addr.   Source addr     M      Home addr         M
  379. of mobile
  380.  
  381. Registration      Regist. seq     M      Registration      M
  382. seq. control      Count                  identification
  383.  
  384. Authentication    Authentication  M      Mobile-home       M
  385. (home-mobile)     parameter              auth. extension
  386.  
  387. Home agent id     NR                     Home Agent        M
  388.  
  389. Registration      NR                     Lifetime          M
  390. lifetime
  391.  
  392. Forwarding        Forwarding net  M      Care-of-Address   M
  393. address           address
  394.  
  395. Multiple regist.  NR                     Code              M
  396. req.
  397.  
  398. Authentication    NR                     Mobile-foreign    O
  399. (foreign-mobile)                         auth. extension
  400.  
  401. Encapsulation     NR                     Minimum encaps.   O
  402. method                                   extension
  403.  
  404. Carrier identi-    Location info   O      NR
  405. fication
  406.  
  407.    M=Mandatory, O=Optional, NR=Not Relevant
  408.  
  409.       Table 1:  Information fields in registration messages
  410.  
  411.  
  412. In a CDPD network, no authentication is required between the MES
  413. and the serving MDIS. although an encryption key is exchanged
  414. between the two entities using Diffie-Hellman algorithm. The MES
  415. then authenticates itself within its home MDIS using the <NEI,
  416. <ARN, ASN>> tuple; the serving MDIS will only issue an ISC message
  417. to the MES if proper authorization from the home MDIS is obtained.
  418. In a Mobile IP network, the registration message from the mobile
  419. host can contain the FA-mobile host authentication extension to
  420. allow the FA and the MH to authenticate each other.
  421.  
  422. When the mobile host/end system is roaming, the home network
  423. should forward the packets to the serving/foreign network. In
  424. CDPD, this task is being performed by the home MDIS. Since all
  425. packets destined into the MES's home network go through the MDIS,
  426. there is no need for the MDIS to make extra efforts to intercept
  427. the packets. In Mobile IP, a subnet may have multiple paths for
  428. packets to be routed to/from the subnet, and the mobile host's HA
  429. may not be the gateway router. Thus the HA uses gratuitous ARP to
  430. advertise the reachability of the mobile host once it receives the
  431. mobile's registration from a foreign network (impersonating the
  432. mobile host). When the MH returns to the home network and
  433. deregisters from the HA, the normal packet delivery is resumed.
  434.  
  435.  
  436. 5. Internetworking between CDPD and Mobile IP
  437.  
  438. Due to the differences mentioned in Section 3, CDPD and Mobile IP
  439. cannot interwork without any modifications. However, since many of
  440. the mobility management concepts and functions are derived from
  441. the same principles, CDPD and Mobile IP can support each other's
  442. operation without major modification of the specification. This
  443. section discusses how a CDPD network can support a Mobile IP user
  444. through the use of middleware software that interfaces the CDPD
  445. and Mobile IP networks. (A similar method can be used to enable
  446. CDPD terminal support from a Mobile IP network.)
  447.  
  448. Suppose a Mobile IP host enters a CDPD domain and wants to
  449. establish network access through the CDPD network. The MH can use
  450. a CDPD docking station and/or a CDPD modem to access the CDPD
  451. network. Following the CDPD network operation convention, the CDPD
  452. modem must have a valid network address (IP address) registered
  453. with the network operator. The CDPD network address uses prefix
  454. 166 and is different from the original IP address of the mobile
  455. host.
  456.  
  457. To obtain network service from the CDPD network and maintain a
  458. Mobile IP connection, the MH must register with both the CDPD
  459. network and its HA. Following the CDPD protocol, the CDPD modem
  460. performs the CDPD registration with the serving MDIS using its
  461. CDPD recognized IP address with prefix 166. From the CDPD
  462. network's perspective, the MH is a valid CDPD MES with a valid
  463. CDPD address, thus the Mobile IP aspect of the MH is completely
  464. transparent from the CDPD network. The MH can then use the
  465. standard Mobile IP protocol to register with its HA, using the
  466. CDPD network address as the COA. In this case, the FA and the MH
  467. are collocated and MH acts as its own agent. The CDPD network
  468. address (NEI) is easily accessible from the modem memory/registers
  469. using the standard AT command.
  470.  
  471. Upon completion of the registration process, the MH can continue
  472. to send out IP packets to the network using the serving MDIS as
  473. its default router. The CDPD network treats the MH as a
  474. conventional MES with a valid CDPD address. The packets destined
  475. to the MH will be encapsulated by the HA and forwarded to the MH
  476. using the CDPD network address as the COA. The scenario is the
  477. same as an IP-based FES communicating with an MES. The routing
  478. scenario is depicted below in Figure 6. (The CDPD network
  479. encapsulation is not shown.)
  480.  
  481.                   +---------+    +--------------+
  482.       MH/MES/FA<==|  CDPD   |<===|              |<===HA
  483.            \      |         |    |              |    /\
  484.             \     | Network |    |   INTERNET   |    |
  485.              ---->|         |--->|              |-->host
  486.                   +---------+    +--------------+
  487.  
  488.             === indicates an encapsulated flow
  489.  
  490.      Figure 6: Supporting Mobile IP host in a CDPD Network:
  491.                One-directional Encapsulation Approach
  492.  
  493. Refinement
  494.  
  495. The one directional encapsulation approach described above may
  496. create an accounting problem for the CDPD network. As dictated by
  497. some CDPD network operators, any packet originated from the CDPD
  498. network must have a valid CDPD network address (with prefix 166)
  499. as its source address. Such networks use the source to create
  500. accounting data for billing purposes. The one way encapsulation
  501. approach allows a packet originating from the MH to use its home
  502. address as the source address, which cannot be properly accounted
  503. by the account meter in the MDIS. Therefore, for accounting
  504. purposes, every packet originating from the MH should be
  505. encapsulated using the CDPD network address as the source address.
  506. However, this creates another problem for the corresponding host
  507. for the MH, since the corresponding host may not have the
  508. capability to decapsulate the packet.
  509.  
  510. A bidirectional encapsulation approach is proposed to solve the
  511. accounting problem and keep the corresponding host transparent at
  512. the same time. The MH encapsulates outgoing packets using the HA's
  513. address as the destination address and the CDPD NEI as the source
  514. address. Upon receiving the encapsulated packets, the HA
  515. decapsulates and forwards them to the correct destination.
  516. Therefore, to support the migration of a mobile host into a CDPD
  517. network, the HA must also provide a decapsulation function. This
  518. is relatively simple because the HA already has the encapsulation
  519. capability. The bidirectional encapsulation tunnel established
  520. between the MH and HA serves as a virtual private network (VPN)
  521. connection for the MH and its home network.
  522.  
  523. The bidirectional encapsulation method is depicted in Figure 7.
  524.  
  525.                 +---------+    +--------------+
  526.                 | CDPD    |    |              |
  527.    MH/MES/FA<==>| Network |<==>|   INTERNET   |<===>HA<--->host
  528.                 |         |    |              |
  529.                 +---------+    +--------------+
  530.  
  531.  
  532.             === indicates an encapsulated flow
  533.  
  534.      Figure 7: Supporting Mobile IP host in a CDPD Network:
  535.                Bi-directional Encapsulation Approach
  536.  
  537. Note that in the initial approach, the only interaction between
  538. the Mobile IP software and the CDPD network is for the Mobile IP
  539. software to retrieve the CDPD network address associated with the
  540. CDPD modem. No modification on the part of CDPD network
  541. infrastructure is needed. For the one directional encapsulation
  542. approach, no change on the Mobile IP HA is required. On the other
  543. hand, for the VPN approach, the Mobile IP software on the MH and
  544. its HA should be enhanced so that a bidirectional encapsulation
  545. tunnel can be established between the two entities.
  546.  
  547. If the MH/MES roams into a new serving MDIS, both the registration
  548. and packet forwarding will be performed by the CDPD network
  549. without impact on the Mobile IP protocol.
  550.  
  551.  
  552. 6. Summary
  553.  
  554. This memo has investigated the mobility management functions for
  555. the two prominent technologies being developed and deployed in the
  556. communication industry: CDPD and Mobile IP. While these two are
  557. based on the same principles and concepts, they can not interwork
  558. with each other due to the differences in their approaches in the
  559. registration protocol, encapsulation method, and security
  560. extensions. Historically, the two protocols have different design
  561. goals in terms of uniformity/heterogeneity, tariff and security
  562. concerns.
  563.  
  564. An approach was identified for interworking between CDPD and
  565. Mobile IP networks while keeping the existing protocols unchanged.
  566. The scheme calls for adding relative simple middleware to the
  567. mobile host software to enable its usage of CDPD network as a
  568. Mobile IP subnet.
  569.  
  570. With a large deployed base of CDPD networks and the ubiquity of
  571. the IP based Internet it is important to explore schemes that
  572. allow the two networks to interconnect with each other and provide
  573. mobility services to the ever increasing population of mobile
  574. computing devices.
  575.  
  576.  
  577. 7. Security Considerations
  578.  
  579. Security considerations are not discussed in this memo.
  580.  
  581.  
  582. 8. References
  583.  
  584. [1] CDPD Forum, "Cellular Digital Packet Data System
  585. Specification", Release 1.1, January 19, 1995.
  586.  
  587. [2] IETF Mobile IP working group, "IP Mobility Support - Draft-
  588. IETF-Mobileip-Protocol-17", May 31, 1996.
  589.  
  590.  
  591. 9. Authors' Addresses
  592.  
  593. Greg Ruth
  594. GTE Laboratories, Inc.
  595. 40 Sylvan Street
  596. Waltham, MA  02254
  597. gruth@gte.com
  598. 617 466 2448
  599.  
  600. Ruixi Yuan
  601. GTE Laboratories, Inc.
  602. 40 Sylvan Street
  603. Waltham, MA  02254
  604. ry00@gte.com
  605. 617 466 2050
  606.  
  607. Internet Draft    CDPD-MobileIP Interoperability    6 August 1996
  608.  
  609.  
  610.  
  611.  
  612. Ruth & Yuan              Expires Nov 1996              [Page 12]
  613.  
  614. Internet Draft       CDPD-MobileIP Interoperability        31 July
  615. 1996
  616.  
  617.