idnits 2.17.1 draft-ernst-nemo-terminology-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard 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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (October 2002) is 7863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Perkins' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC2002' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'Ernst01' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC1726' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'Solomon' is defined on line 622, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Perkins' ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ernst01' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-18 == Outdated reference: A later version (-07) exists of draft-ietf-multi6-multihoming-requirements-03 ** Downref: Normative reference to an Informational draft: draft-ietf-multi6-multihoming-requirements (ref. 'MULTI6') == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-node-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ipv6-node-requirements (ref. 'IPv6-NODE') ** Downref: Normative reference to an Informational RFC: RFC 1726 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'Solomon' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tanenbaum' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF INTERNET-DRAFT Thierry Ernst, WIDE and INRIA 3 Hong-Yon Lach, Motorola Labs Paris 4 October 2002 6 Network Mobility Support Terminology 7 draft-ernst-nemo-terminology-00.txt 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document proposes a terminology for defining network mobility 32 problems and solution requirements. Network mobility occurs when an 33 entire network changes its point of attachment to the Internet and 34 thus its reachability in the topology, which is referred to as a 35 mobile network. 37 Contents 39 Status of This Memo 41 Abstract 43 1. Introduction 45 2. Applications 47 3. Terminology 48 3.1. Architecture Components 49 Mobile Network 50 Mobile Network Node (MNN) 51 Mobile Router (MR) 52 Fixed Node (FN) 53 Mobile Node (MN) 54 Node behind the MR 55 Correspondent Node (CN) 56 Access Router (AR) 57 Egress Interface of a MR 58 Ingress Interface of a MR 59 Home subnet prefix 60 Foreign subnet prefix 61 Mobile Network Prefix 62 3.2. Functional Terms 63 Local Fixed Node (LFN) 64 Local Mobile Node (LMN) 65 Visiting Mobile Node (VMN) 66 NEMO-enabled (NEMO-node) 67 MIPv6-enabled (MIPv6-node) 68 3.3. Nested Mobility 69 root-NEMO 70 parent-NEMO 71 sub-NEMO 72 Top-Level Mobile Router (TLMR) 73 3.4. Multihomed mobile network 74 3.5. Miscellaneous Terms 75 NEMO support 76 intra-domain mobility 77 inter-domain mobility 78 Idle MNN 79 Idle Mobile Network 81 Acknowledgments 83 References 84 1. Introduction 86 A mobile network is an entire network, moving as a unit, which 87 changes its point of attachment to the Internet and thus its 88 reachability in the topology. A mobile network may be composed by one 89 or more IP-subnets and is connected to the global Internet via one or 90 more Mobile Routers (MR). Nodes behind the MR primarily comprise 91 fixed nodes (nodes unable to change their point of attachment while 92 maintaining ongoing sessions), and additionally mobile nodes (nodes 93 able to change their point of attachment while maintaining ongoing 94 sessions). The internal configuration of the mobile network is 95 assumed to be relatively stable with respect to the MR. 97 If network mobility is not explicitly supported by some mechanisms 98 once a MR changes its point of attachment, existing sessions between 99 CNs and nodes behind the MR are broken, and connectivity to the 100 global Internet is lost. In addition, fixed nodes behind the MR are 101 faced with sub-optimal routing with their correspondents in the 102 global Internet, whereas multiple levels of mobility may cause 103 extremely sub-optimal routing. 105 Traditional work on mobility support as conducted in the Mobile IP 106 working group is to provide continuous Internet connectivity to 107 mobile hosts only (host mobility support) and are unable to support 108 network mobility. The NEMO working group has therefore been created 109 to specify solutions specific for network mobility support. 111 To describe the problems and to define the requirements that will 112 have to be met by the solutions, a new terminology is needed, which 113 is the object of the present document. This terminology is supposed 114 to serve as the base document produced by the NEMO WG and shall be 115 refined once we agree on the requirements. 117 2. Applications 119 Cases of mobile networks include networks attached to people 120 (Personal Area Network or PAN, i.e. a network composed by all 121 Internet appliances carried by people, like a PDA, a mobile phone, a 122 digital camera, a laptop, etc.) and networks of sensors deployed in 123 aircrafts, boats, busses, cars, trains, etc. An airline company that 124 provides permanent on-board Internet access is an example of a mobile 125 network. This allows passengers to use their laptops (this scenario 126 is mentioned in [Tanenbaum] under section 1.2.4 and section 5.5.8; 127 [Perkins] under section 5.12; [Solomon] under section 11.2; and 128 [RFC2002] section 4.5), PDA, or mobile phone to connect to remote 129 hosts, download music or video, browse the web. Passengers could 130 themselves carry a network with them (a PAN). At the same time, air 131 control traffic could be exchanged between the aircraft and air 132 traffic control stations (this scenario has already been investigated 133 by Eurocontrol, the European Organization for the safety of air 134 navigation. During a transatlantic flight, the aircraft changes its 135 point of attachment to the Internet and may be reachable by distinct 136 Internet Service Providers (ISPs). Over the oceans, the aircraft gets 137 connected to the Internet through a geostationary satellite; over the 138 ground, it's through a radio link. Handoffs do typically not occur 139 very often (a radio link may cover 400-500 kilometers). Another 140 similar scenario mentioning ships and aircrafts can be found in 141 [RFC1726, section 5.15]. Similarly, a bus, the metropolitan public 142 transport, or the taxi company could allow passengers to connect 143 their PAN to the Internet via the embarked network, therefore 144 ensuring, while on-board, an alternative to the metropolitan cellular 145 network, in terms of price or available bandwidth, access control, 146 etc. Meanwhile, a number of Internet appliances deployed in the 147 mobile network are used to collect traffic and navigation data from 148 the Internet while sensors within the mobile network collect and 149 transmit to the Internet live information, like the current number of 150 passengers, expected time to arrival, the amount of petrol left in 151 the tank, etc. For a number of reasons (network management, security, 152 performance,...), it is desirable to interconnect the Internet 153 appliances deployed in cars, trains, busses by means of, for 154 instance, an Ethernet cable, instead of connecting them individually 155 and directly to the Internet, therefore exhibiting the need to 156 displace an entire network. 158 3. Terminology 160 Terms introduced in this draft comply with the terminology already 161 defined in the IPv6 [RFC2460] and Mobile IPv6 [MIPv6] specifications. 162 Our terminology is primarily targeted toward IPv6 but is not 163 necessarily limited to it. Some terms will only be useful for the 164 purpose of defining the problem scope and functional requirements of 165 network mobility support and shall be removed or refined once we 166 agree on the requirements. 168 The first section introduces terms to define the architecture 169 components; the second introduces terms to discuss the requirements, 170 the third, terms to discuss nested mobility; the forth defines 171 multihoming, and the last, miscellaneous terms which do not fit in 172 either sections. The terminology summarized in fig.1 to 5. Fig.1 173 shows a single mobile subnetwork. Fig.2. shows a larger mobile 174 network comprising several subnetworks, attached on a foreign link. 175 Fig.3 illustrates a node changing its point of attachment within the 176 mobile network. Fig.4 and 5 illustrate nested mobility. 178 3.1. Architecture Components 179 Mobile Network 181 An entire network, moving as a unit, which dynamically changes its 182 point of attachment to the Internet and thus its reachability in 183 the topology. The mobile network is connected to the global 184 Internet via one or more mobile router(s) (MRs). From the fixed 185 Internet, the mobile network is a cloud. The internal 186 configuration of the mobile network is assumed to be relatively 187 stable with respect to the MR and is not a matter of concern. The 188 internal of the mobile network will therefore not affect network 189 mobility support protocols. 191 Mobile Network Node (MNN) 193 Any host or router located within the mobile network, either 194 permanently or temporarily. A MNN could be any of a MR, LFN, VMN, 195 or LMN. The distinction between LFN, LMN and VMN is necessary to 196 discuss issues related to mobility management and access control, 197 but does not preclude that mobility should be handled differently. 198 Nodes are classified according to their function and capabilities. 200 ____ 201 | | 202 | CN | 203 |____| 204 ___|____________________ 205 | | 206 | | 207 | Internet | 208 | | 209 |________________________| 210 __|_ __|_ 211 | | Access | | 212 | AR | Router | AR | 213 |____| |____| 214 ______|__ foreign __|_____________ home 215 link __|_ link 216 | | 217 | MR | Mobile Router 218 |____| 219 _________|_______ internal 220 __|__ __|__ link 221 | | | | 222 | MNN | | MNN | Mobile Network Nodes 223 |_____| |_____| 225 Figure 1: Architecture Components 227 Mobile Router (MR) 229 A router which changes its point of attachment to the Internet. 230 The MR has one or more egress interface(s) and one or more ingress 231 interface(s) and acts as a gateway between the mobile network and 232 the rest of the Internet. The MR thus maintains the Internet 233 connectivity for the entire mobile network. When forwarding a 234 packet to the Internet (i.e. upstream), the packet transmitted 235 through one MR's egress interface; when forwarding a packet to the 236 mobile network (i.e. downstream), the packet is transmitted 237 through one of the MR's ingress interface. 239 Fixed Node (FN) 241 A node, either a host or a router, unable to change its point of 242 attachment and its IP address without breaking open sessions. FNs 243 are standard IPv6 nodes as defined in [IPv6-NODE] which do not 244 support the MN functionality defined in [MIPv6] section 8.5 nor 245 any other form of mobility support (also see [IPv6-NODE] section 7 246 "Mobility"). 248 Mobile Node (MN) 250 A node, either a host or a router, which is able to change its 251 point of attachment and maintain continuous sessions. 253 Node behind the MR 255 Any MNN in a mobile network, beside the MRs connecting the mobile 256 network to the Internet. 258 Correspondent Node (CN) 260 Any node that is communicating with one or more MNNs. A CN could 261 itself be located within the mobile network. 263 Access Router (AR) 265 Any subsequent point of attachment of the MR at the network layer. 266 Basically, a router on the home link or the foreign link. An AR 267 may itself be located in a mobile network and provide access to 268 mobile nodes. 270 Egress Interface of a MR 272 The interface attached to the home link if the MR is at home, or 273 attached to a foreign link if the MR is in a foreign network. 275 Ingress Interface of a MR 277 The interface attached to a link inside the mobile network. This 278 interface is configured with the Mobile Network Prefix. 280 ________________________ 281 | | 282 | | 283 | Internet | 284 | | 285 |________________________| 286 __|_ 287 Access | | 288 Router | AR | 289 |____| 290 foreign _____|_____________ 291 link | 292 | egress interface 293 __|__ 294 | | | 295 ingress |____| MR | Mobile Router 296 interface | |____| 297 | | 298 | | ingress interface 299 | ____|________________ internal 300 | __|__ __|__ link 1 301 _____ | | | | | 302 | |__| | LFN | | LMN | 303 | LFN | | |_____| |_____| 304 |_____| | 305 | internal 306 link 2 308 Figure 2: Larger Mobile Network with 2 subnets 310 Home subnet prefix 312 A bit string that consists of some number of initial bits of an IP 313 address which identifies the MR's home link within the Internet 314 topology (i.e. the IP subnet prefix corresponding to the mobile 315 node's home address, as defined in [MIPv6]). 317 Foreign subnet prefix 319 A bit string that consists of some number of initial bits of an IP 320 address which identifies the MR's foreign link within the Internet 321 topology. 323 Mobile Network Prefix 325 A bit string that consists of some number of initial bits of an IP 326 address which identifies the entire mobile network within the 327 Internet topology. All MNNs necessarily have an address named 328 after this prefix. 330 3.2. Functional Terms 332 The distinction between LFN, LMN, and VMN as defined below it is a 333 property of how different types of nodes can move in the topology. 334 The rationale here is that nodes with different properties (may) have 335 different requirements. This distinction may not be useful once we 336 agree on the requirements. They are listed here as a means to ease 337 and clarify the requirement discussion. 339 Local Fixed Node (LFN) 341 A fixed node (FN) that belongs to the mobile network and which 342 doesn't move topologically with respect to the MR. 344 Local Mobile Node (LMN) 346 A mobile node (MN) or a mobile router (MR) that belongs to the 347 mobile network (i.e. its home link is within the mobile network). 348 It can move topologically with respect to the MR. 350 Visiting Mobile Node (VMN) 352 A mobile node (MN) or a mobile router (MR) that doesn't belong to 353 the mobile network (i.e. its home link is not within the mobile 354 network). A VMN that gets attached to a link within the mobile 355 network obtains an address on that link and can move topologically 356 with respect to the MR. 358 NEMO-enabled (NEMO-node) 360 A node that has been extended with network mobility support 361 capabilities and that may take special actions based on that. 362 (details of the capabilities are not known yet, but it may be 363 implementing some sort of Route Optimization). 365 MIPv6-enabled (MIPv6-node) 367 A mobile node (MN) which is able to change its point of attachment 368 and maintains continuous sessions thanks to the MN functionality 369 as defined in [MIPv6] section 8.5. 371 ________________________ 372 | | 373 | | 374 | Internet | 375 | | 376 |________________________| 377 __|_ __|_ 378 | | Access | | 379 | AR | Router | AR | 380 |____| |____| 381 __|_ _____|_____________ foreign 382 | | _|__ link 383 | MN | | | | 384 |____| _____ |__| MR | Mobile Router 385 | |__| |____| 386 |--> | LMN | | __|_____________ internal 387 | |_____| | __|__ | link 1 388 | _____ | | | 389 | | |__| | LFN | 390 | | LFN | | |_____| | 391 | |_____| | | 392 | | internal | 393 | link 2 | 394 |------------------------------| 396 Figure 3: LMN changing subnet 398 3.3. Nested Mobility 400 Nested mobility occurs when there are more than one level of 401 mobility. A MNN acts as an Access Router and allows visiting nodes to 402 get attached to it. There are two cases of nested mobility: 404 - when the attaching node is a single node: VMN (see figure 4). 405 For instance, when a passenger carrying a mobile phone gets 406 Internet access from the public access network deployed into a 407 bus. 409 - when the attaching node is a router with nodes behind it, 410 i.e.a mobile network (see figure 5). For instance, when a 411 passenger carrying a PAN gets Internet access from the public 412 access network deployed in the bus. 414 ________________________ 415 | | 416 | | 417 | Internet | 418 | | 419 |________________________| 420 __|_ __|_ 421 | | Access | | 422 | AR | Router | AR | 423 |____| |____| 424 _____|_____________ home 425 | _|__ link 426 | | | | 427 | _____ |__| MR | Mobile Router 428 | | |__| |____| 429 ----------> | VMN | | __|_____________ internal 430 |_____| | __|__ __|__ link 1 431 _____ | | | | | 432 | |__| | LFN | | LMN | 433 | LFN | | |_____| |_____| 434 |_____| | 435 | internal link 2 437 Figure 4: Nested Mobility: single VMN attached to a mobile network 439 In the second case, a mobile network is getting attached to a 440 larger mobile network and the aggregated hierarchy of mobile 441 networks becomes a single nested mobile network. In this case, we 442 use the following terms: 444 - root-NEMO: the mobile network at the top of the nested 445 hierarchy. 447 - parent-NEMO: the upstream-NEMO providing access to a mobile 448 network down the hierarchy 450 - sub-NEMO: the downstream-NEMO attached to a mobile network up 451 the hierarchy. It becomes a subservient of the parent-NEMO. 453 - Top-Level Mobile Router (TLMR): the MR(s) of the root-NEMO 454 which are used to connect the nested mobile network to the 455 fixed Internet. 457 ________________________ 458 | | 459 | | 460 | Internet | 461 | | 462 |________________________| 463 __|_ __|_ 464 | | Access | | 465 | AR | Router | AR | 466 |____| |____| 467 _____|_____________ foreign 468 _|__ link 469 | | | 470 | ____ |__| MR | Mobile Router (TLMR) 471 |_| |__| |____| 472 | | MR | | __|_____________ internal 473 | |____| | __|__ __|__ link 1 474 _____ | | | | | | 475 | | | | | LFN | | LMN | 476 | LFN |__| | |_____| |_____| 477 |_____| | | 478 | | internal 479 link 2 480 <-----------------> <---------------------------> 481 sub-NEMO root-NEMO 483 Figure 5: Nested Mobility: sub-NEMO attached to a larger mobile network 485 3.4. Multihomed mobile network 487 Multihoming, as currently defined by the IETF, covers site- 488 multihoming [MULTI6] and host multihoming. Within host-multihoming, a 489 host may be either: 491 - multi-addressed: multiple source addresses to choose between on 492 a given interface; all IPv6 nodes are multi-addressed due to the 493 presence of link-local addresses on all interfaces. 495 - multi-interfaced: multiple interfaces according to [RFC2460] 496 definition. 498 - multi-linked: just like multi-interfaced but all interfaces are 499 NOT connected to the same link. 501 - multi-sited: when using IPv6 site-local address and attached to 502 different sites 504 So, a mobile network is multihomed when either: 506 - a MR has multiple egress interfaces on the same foreign link 508 - a MR has multiple egress interfaces on distinct foreign link 510 - there are more than one MR in the mobile network 512 3.5. Miscellaneous Terms 514 Host mobility support 516 Host Mobility Support allows mobile nodes to maintain session 517 continuity. In IPv6, it is achieved by Mobile IPv6 519 NEMO support 521 Network mobility support allows mobile networks to maintain 522 session continuity. Solutions developped to support NEtwork 523 MObility will be referred to as "NEMO support". 525 In Basic support, each Mobile Router has a Home Agent, and uses 526 bidirectional tunneling between the MR and HA to preserve session 527 continuity while the MR moves. The MR will acquire a Care-of- 528 address from its attachment point much like what is done for 529 Mobile Nodes using Mobile IP. This approach allows nesting of 530 Nemos, since each MR will appear to its attachment point as a 531 single node. 533 In Extended support, we will seek to optimize routing between MNNs 534 and arbitrary CNs by some means which details are not known yet. 536 intra-domain mobility 538 Mobility within a single administrative domain, i.e. between 539 subnetworks topologically close in the IP hierarchy. As an 540 instance, the displacement of a node within a limited vicinity of 541 adjacent subnetworks, like in a campus, that belong to the same 542 organization or between ARs that belong to the same ISP. In the 543 literature, and depending on the definition of ``closeness'', this 544 is also termed intra-site mobility, local mobility or micro- 545 mobility. 547 inter-domain mobility 549 Mobility across administrative domain boundaries, i.e. between 550 subnetworks topologically distant in the IP hierarchy. As an 551 instance of Wide-Area Mobility, displacement of a node between 552 distinct ISPs or organizations, or between widely separated sites 553 of a single organization. In the literature, and depending on the 554 definition of ``remoteness'', this is also termed inter-site 555 mobility, global mobility, or macro-mobility. 557 Idle MNN 559 A MNN that does not engage in any communication. 561 Idle Mobile Network 563 A mobile network that does not engage in any communication outside 564 the network may be considered idle from the global Internet. This 565 doesn't preclude that MNNs are themselves idle. Internal traffic 566 between any two MNNs located in the same mobile network is not 567 concerned by this statement. 569 Acknowledgments 571 The material presented in this document takes most of the text from 572 our former internet-drafts submitted to MobileIP WG and to the former 573 MONET BOF, which where themselves based on original text from 574 [Ernst01]. Authors would therefore like to thank both Motorola Labs 575 Paris and INRIA (PLANETE team, Grenoble, France), for the opportunity 576 to bring this topic to the IETF since 2000, and particularly Claude 577 Castelluccia (INRIA) for its advices, suggestions, and direction. We 578 also acknowledge Alexandru Petrescu (Motorola), Christophe Janneteau 579 (Motorola), Hesham Soliman (Ericsson) and Mattias Petterson 580 (Ericsson) and all the people on the NEMO (formerly MONET) mailing 581 list which helped to improve this draft. 583 References 585 [Ernst01] Thierry Ernst 586 Network Mobility Support in IPv6", PhD Thesis, 587 University Joseph Fourier Grenoble, France. 588 October 2001. http://www.inria.fr/rrrt/tu-0714.html 590 [MIPv6] David B. Johnson and C. Perkins. 591 "Mobility Support in IPv6". 592 Internet Draft draft-ietf-mobileip-ipv6-18.txt, 593 July 2002. Work in progress. 595 [MULTI6] B. Black, V. Gill and J. Abley 596 "Requirements for IPv6 Site-Multihoming Architectures" 597 draft-ietf-multi6-multihoming-requirements-03 598 May 2002. Work in progress 600 [IPv6-NODE] John Loughney 601 "IPv6 Node Requirements" 602 draft-ietf-ipv6-node-requirements-01.txt 603 July 2002, Work in progress. 605 [Perkins] C. E. Perkins. 606 "Mobile IP, Design Principles and Practices." 607 Wireless Communications Series. 608 Addison-Wesley, 1998. ISBN 0-201-63469-4. 610 [RFC1726] C. Partridge 611 "Technical Criteria for Choosing IP the Next Generation", 612 IETF RFC 1726 section 5.15, December 1994. 614 [RFC2460] S. Deering and R. Hinden. 615 "Internet Protocol Version 6 (IPv6) Specification". 616 IETF RFC 2460, December 1998. 618 [RFC2002] C. Perkins (Editor). 619 "IP Mobility Support". 620 IETF RFC 2002,October 1996. 622 [Solomon] J. D. Solomon. 623 "Mobile IP, The Internet Unplugged". 624 Prentice Hall Series in Computer Networking 625 and Distributed Systems. 626 Prentice Hall PTR, 1998. ISBN 0-13-856246-6. 628 [Tanenbaum] Andrew Tanenbaum 629 "Computer Networks", 630 Prentice-Hall, Third Edition. 1996 632 Author's Addresses 634 Questions about this document can be directed to the authors: 636 Thierry Ernst, 637 INRIA, visiting researcher at WIDE 638 Jun Murai lab. Faculty of Environmental Information, 639 Keio University. 640 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. 641 Phone : +81-466-49-1100 642 Fax : +81-466-49-1395 643 E-mail: ernst@sfc.wide.ad.jp 644 Web: http://www.sfc.wide.ad.jp/~ernst/ 646 Hong-Yon Lach 647 Motorola Labs Paris, Lab Manager, 648 Networking and Applications Lab (NAL) 649 Espace Technologique - Saint Aubin 650 91193 Gif-sur-Yvette Cedex, France 651 Phone: +33-169-35-25-36 652 Email: Hong-Yon.Lach@crm.mot.com