connectivity and routing because their location,

IP-based Protocols for Mobile Internetworking John Ioannidis, Dan Duchamp, Gerald Q. Maguire Jr. [email protected] edu, [email protected],columbia .edu, [email protected] .edu Department of Computer Science Columbia University Abstract We consider the problem of providing network access to hosts whose physical location clianges with time. Such hosts cannot depend on traditional forms of network connectivity and routing because their location, and hence the route to reach them, cannot be deduced from their network address. In this paper, we explore the concept of providing continuous network access to mobile computers, and present a set of IP-based protocols that achieve that goal. They are primarily targeted at supporting a campus environment with mobile computers, but also extend gracefully to accommodate hosts moving between different networks. The key feature is the dependence on ancillary machines, the Mobile Support Stations (MSSS), to track the location of the Mobile Hosts. Using a combination of caching, forwarding pointers, and timeouts, a minimal amount of state is kept in each MSS. The state information is kept in a distributed fashion; the system scales well, reacts quickly to changing topologies, and does not place an overwhelming burden on the network. 1 Motivation In recent years we have observed a proliferation of portable computers, and a trend toward the production of smaller and more powerful such units. A serious drawback of current portable computers is that their users have no accessto their everyday work environment from their portable the users have to useawkward file transfer mechanisms to upload and download any files they may need while away from their office. There is a strong desire, not only among computerliterate users, to have the same environment and access to the same data both in the workplace and away from it. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. a 1991 ACM 0.89J9J.444.9/9j /0008 /0235…$ 1.SO While modem portable computers are capable of providing this functionality, they are hindered by the lack of continuous network connectivity. The logical step is the addition of highly available, highbandwidth mobile networking capabilities to portable computers. The technology to support this concept is appearing, Beyond the near-ubiquitous LAN in business environments, high-speed wireless interfaces are starting to appear at speedsof up to 16Mbps, using radio frequency (RF) or infrared (IR) technology [Dav9 1]. Moreover, there hasbeen a significant increase in the availability of alternate long-haul networking resources, such as dial-up IP services, companies and universities offering SLIP connections to their employees and students, and so on. AH these activities suggest, among other things, a user base eager to have high-bandwidth access to computation and information resources. In this paper, we explore the concept of providing continuous network access to mobile computers, and present a set of IF’-based protocols that achieve that goal. A combination of software on the portables themselves as well as on infrastructure machines ensures continuous addressability. Our protocols work within the Intemet suite of protocols, and provide mobile hosts with IP-level connectivity. Protocols above the network (IP) layer are shielded from this mobility; protocols at the transport layer and above need no modification; they continue to operate as if they were on ordinary, static hosts. Finally, no changes are needed to the software of non-participating hosts or gateways. 2 Mobile Internetworking Protocols 2.1 The Model In this paper, the term ‘mobile’ implies ‘able to move while retaining its network connections’. Thus, we shall call a host that can move while retaining its network connections a mobile host, or MH for short. The infrastructure machines that support the MHs we shall call Mobile Support Sta- 235 tions, MSS for short. A logical or geographical segment of the campus supported by an MSS is called a cell. Our protocols distinguish between ‘local’ and ‘remote’ networks. This is a result of the standard partitioning of the 32-bit IP address into a “network” part and a “host-within-network” part. We catl host mobility within the realm of one network number (i.e., within a single campus or organization) intracampus mobility, and mobility betwwm networks (i.e., between different campuses) intercampus mobility. The functionality needed for the two cases is largely the same. The MH always retains one IP address, called its home address, regardless of where it is on the network. Ancillary machines (the MSSS) assure its addressability, Failure to maintain such a single address would be both inconvenient and inefficient – higher-level software may have to be modified to deal with changing addresses; network users often associate other users with particular machine names; name servers may not respond quickty enough to changes in name/address mappings, etc. The MH may have more than one network interfac~ in this case, it may use as its home address the address of one of its interfaces, or use a totatly unrelated address. Furthermore, it may be convenient to consider that the home addresses of MHs are on separate subnet numbers, as this facilitates the immediate recognition of a host as an MH. If the organization IP address space is heavily populated, it is also possible for the MHs to have their own network number. Either of these casesis au optimization, and is not required. A key issue in developing protocols for mobile intemetworking is which network layer(s) should provide transparent mobility. Our primary objective is to hide mobility from applications that do not wish to know about it, hence nothing above the transport layer should be changed. The choices are therefore transport, networldintemetwork, datalink (or some combination). We believe that this functionality belongs to the network and intemetwork (D?) layer. The reasoning is simplex the purpose of the network layer is to provide uniform access to network interfaces, and to handle routing and intemetworking. It hides the different hardware addresses of the dat.slink layer, or the exact location of a host on an intemetwork, and provides the abstraction of a network address to the layers above it. The problem with this approach is how to change the location of a host in an environment that depends on network and subnetwork addresses for routing and still maintain addressability. This paper addresses exactly this problem, and our solution is the dependence on the MSSS, and added functionality in the IP layer. Another approach would be to dynamically change the logical (network) address of an M H to au address local to the segment of the network to which it moved. l%is creates a variety of problems. First, such transient IP addresses would have to be dynamically assigned and reclaimed. Next, name servers would have to be updated to reflect the change of IP addresses (assuming we want to preserve at least the host name of the machine network users associate people with particular machines). In addition, transport-layer and higher protocols would have to be informed of this address change. While it may be sufficient for connection-oriented protocols, such as TCP pos81b], to inform only the transport-layer code, other protocols that do not keep the address of their peer or peers aspart of their state, would fail. Every higher-level application would have to be notified every time an MH changes location. The network address of a host is used in too many places to make it easy to modify it without affecting almost every networked application. Conversely, one could descend the network hierarchy
instead of climbing it, and attempt to have the data-link layer handle moving hosts. Regardless of how this is implemented, when two MHs that are not on the same connected network, some form of encapsulation will have to be used in order to deliver packets (as the data link layer cannot interact with routing). Furthermore, the agents responsible for handling mobility would have to exchange information on the location of each MH, and that, too, cannot be done at the data-link layer if the agents are not on the same connected network. To exchange M H or other routing information, a data-link driver would have to use network-level packets to route its requests to the remote driver. In other words, some of the functionality will still be in the network layer. Finatly, a new driver would have to be written for every different network interface to support mobility. In conclusion, it is evident that functionality pertaining to mobility should be added at the network layer. As it turns out, from an implementation point of view, some modifications may be needed in the data-link layer to deal with address-resolution* issues. More about this in Section 2.4.1. Lastly, our design philosophy is that the burden of providing mobile intemetworking should fall mainly on its users, and that hosts not using these features should continue running with their ordinary software. Thus, atthough it may be desirable in order to enhance performance, it is not necessary to run special routing code on gateways and bridges. 2.2 overview of the Protocols Let us now consider the infrastructure necessary to support intracarnpus mobility, All the hosts in the campus maybe on the same connected network2 or there may be subnets lmappirrg logicat (network) addressesto physical (data-tink) addresses. 2f&nnected Network: A network to which a host is interfacedis Ofien known as the “local network” or the “suhnetwork” relative to that host. 236 connected to each other with level-2 bridges or level-3 gateways. For each such section of the network to which MHs attach, we need to have at least one MSS. Figure 1 shows a prototypical campus. The backbone is on subnet nO, and there are four more subnets, nl through n4 connected with gateways gwl, gw2 and gw3. All MHs are on subnet n 9. MSSS s 1 through s 4 define the four (wireless) cells cl through c4. s 5 is technically in cl and links n2 to the rest of the campus network. MHs ml through m6 are in the pictured cells, with m4 being in the wired cell supported by s 2. Regular hosts and gateways have MSSS as their gateways to subnet n 9. Note that MSSS have their regular IP address on the wired network, a mobile IP address for their wireless interface (if any), and a second, mobile IP address for their wired interface. ……. s? ““” ““ ““” nO .$+/$ ijik?$f .*A ::::::.,.23 ~ .,.:..::.,.:.:…. nl 2 .. … 2 …C.1. ,., ,.. . Flqr“ / campus gw .C2 S2 h3 : $$$ m4 d ………….,. rn5 ,:>::::::::::,\. ,/…..~<.j:;,;,;.’ n3 . . .. . I . . . . . . . . Figure 1: Prototypical campus environment Given the above prototypical campus, let us see how communication takes place. Suppose a wandering MH, m5, moves intos 2‘s cell. The MSS of the cell periodically broadcasts a beacon, so m5 receives S2’s beacon, realizes that it is in c2, sets S2 as its default gateway, and identifies itself. If it were previously in another cell, say c 4, it will also tell S2 that its previous MSS was S4. S2 will then notify s 4 of m5’s migration. S2 must acknowledge m5’s greeting. m5 will continue trying to identify itself to S2 until it receives the acknowledgement. s 2 will also expect an acknowledgment for the forwarding pointer it sent tos 4. It may not get this acknowledgement immediately because of anetwork partition, so the MSS should function correctly even before receiving the forwarding acknowledgement. Retransmissions should follow a bounded binary or linear exponential backoff so asnot to adversely affect the network in the case of such a partition. However, these terms can cause confusion, and therefore we use the term “connected network in this document. (Quoted from RFC1 122 [Bra89]) MHs are always configured to have the MSS of the cell they are in act as their default gateway. Other hosts are configured to gateway traffic destined for the MH subnet (or the range of addresses)through the MSS on their connected network. If no MSS exists on a particular segment, the default routes through that segment’s gateway will eventually lead to some MSS. There are four distinct scenarios involving MHs. First, an MH may send a datagram to another MH in the same cell. Next, an MH may send a datagram to a ‘regular’ host. Further, a regular host may send a datagram to an MH. Finally, an MH may send a datagram to an MH in a different cell. To illustrate these four cases, consider the following examples. We shatl refer to Figure 1 again. 1. 2. 3. 4. When ml sends a datagram to m2 (an MH in the same cell), the normal address resolution mechanism (e.g., ARP)will deliver the datagram to its destination. The MSS is not involved. When an MH sendsa datagram to a regular host, (e.g., m2 to h3), it automatically gateways through its MSS. Normal P routing will deliver the packet to its destination. When a regular host, h3, wants to talk to an MH, m3, its route for the MH subnet, n 9, will be through the locat MSS, s 23. The first time this happens, S2 will query the other MSSs in order to locate the one responsible for the m3. This query may be multicast, sent individually to all MSSS, or flooded from MSS to MSS. s 1 will respond to this query, and S2 will cache the information. Then s 2 will encapsulate the datagram in a special packet and send it directty to s 1. Upon receipt, the latter will unpack the original datagram and deliver it to m3. When an MH sends a datagram to another MH which is not in its cell (e.g., mq to m6), the MSS, S2, will ‘prOxy-ARP’ for m6, discover s 3 as in the previous case, and deliver the datagram. We call the protocol that does the encapsulation IPIP (’<ip-within-ip”), and=”” the=”” protocol=”” used=”” to=”” exchange=”” information=”” among=”” msss,=”” micp=”” (“mobile=”” intemetworking=”” control=”” protocol”).=”” they=”” are=”” both=”” described=”” in=”” detail=”” following=”” sections.=”” another=”” mode=”” of=”” operation=”” is=”” when=”” an=”” mh=”” not=”” only=”” changes=”” cell,=”” but=”” also=”” switches=”” interface.=”” this=”” qmemis=”” ~sofie=”” ~asev&.re=”” ahost=”” on=”” a=”” segment=”” with=”” no=”” m~s;=”” that=”” case,=”” string=”” gateways=”” witl=”” eventually=”” deliver=”” datagrsm=”” mss,=”” then=”” process=”” wilt=”” continue.=”” 237=”” can=”” happen=”” when,=”” e.g.,=”” moves=”” tlom=”” wireless=”” cell=”” location=”” ethernet,=”” wants=”” take=”” advantage=”” higher=”” bandwidth.=”” will=”” now=”” receive=”” mss’s=”” beacon=”” over=”” different=”” interfacq=”” it=”” respond=”” apacket=”” having=”” addressof=”” new=”” interface=”” as=”” its=”” source=”” ip=”” address,=”” giving=”” mh’s=”” home=”” address=”” packet.=”” difference=”” between=”” set-up=”” previous=”” cases=”” mss=”” uses=”” communicating=”” mh;=”” far=”” rest=”” network=”” concerned,=”” still=”” has=”” address.=”” finally,=”” there=”” interesting=”” special=”” case=”” considen=”” ‘island’=”” network,=”” n2,=”” may=”” exist,=”” which=”” ‘extension’=”” subnet=”” campus=”” (in=”” sense=”” same=”” number).=”” particular=”” example,=”” connected=”” link.=”” hosts=”” n2=”” considered=”” mhs=”” by=”” s=”” 5=”” 1.=”” traftic=”” them=”” reaches=”” nl=”” through=”” normal=”” routing=”” mechanisms,=”” picked=”” up=”” 1,=”” tunneled=”” finally=”” delivered.=”” traffic=”” from=”” tirst=”” go=”” thes=”” 5-s=”” 1=”” pair,=”” be=”” routed=”” network.=”” feature=”” useful=”” setting=”” temporary=”” networks=”” (e.g.=”” moving=”” number=”” machines=”” for=”” demonstration),=”” or=”” more=”” permanent=”” caseswhen=”” part=”” organization=”” geograph
ical=”” area=”” desirable=”” ail=”” appear=”” going=”” main=”” location.=”” lntercampus=”” mobility=”” assumed=”” unusual,=”” handled=”” variation=”” intracampus=”” case.=”” needed=”” any=”” remote=”” support=”” intercmnpus=”” mobility.=”” some=”” msss=”” should=”” able=”” collaborate=”” msss:=”” gateway(s)=”” have=”” route=”” one=”” so=”” incoming=”” packets=”” destined=”” properly.=”” referring=”” once=”” again=”” figure=”” directly=”” n=”” o;=”” if=”” 4,=”” 9=”” gateway=”” gw3,=”” n9=”” gw3=”” s4.=”” upon=”” entering=”” foreign=”” campus,=”” realize=”” ask=”” local=”” transient=”” ii?=”” use=”” addressing.=”” address;=”” using=”” delivery=”” mss.=”” now,=”” all=”” leaving=”” encapsulated=”” ipip=”” packet=”” addressedeither=”” handles=”” such=”” traffic.=”” specified=”” configuration=”” command,=”” well-known=”” send=”” greet=”” notice=”” comes=”” claims=”” deduce=”” needs=”” tunneling=”” service.=”” on,=”” handle=”” mh.=”” 2.3=”” hardware=”” requirements=”” our=”” protocols=”” affected=”” nature=”” physical=”” iayeu=”” requirement=”” link-level=”” broadcasts=”” supported=”” order=”” received=”” cell.=”” is,=”” course,=”” irrelevant=”” point-to-point=”” links=”” slip=”” @om88]=”” ppp=”” per90].=”” wired=”” defined=”” reach=”” cable=”” (coaxial,=”” twisted-pair,=”” fiber)=”” to.=”” presence=”” strictly=”” function=”” whether=”” physically=”” attached=”” cable.=”” conversely,=”” around=”” propagation=”” characteristics=”” electromagnetic=”” waves=”” at=”” operating=”” frequency.=”” infrared=”” communications,=”” stop=”” walls=”” room,=”” while=”” radio-frequency=”” communications=”” (typically=”” ighz=”” band=”” 1991)=”” much=”” complicated=”” characteristics.=”” latter=”” than=”” rf=”” cells=”” present,=”” almost=”” impossible=”” overlapping=”” continuous=”” coverage=”” achieved.=”” there,=”” ability=”” detect=”” signal=”” strength=”” report=”” device=”” driver=”” helpful=”” realizing=”” host=”” outer=”” radio=”” try=”” switch=”” one.=”” addition,=”” spread-spectrum=”” multi-channel=”” multiple=”” ‘channels’=”” highly=”” (so=”” areas=”” where=”” overlap=”” stronger=”” another).=”” 2.4=”” data=”” link=”” layer=”” ‘iwo=”” kinds=”” interactions=”” place=”” data-link=”” interest=”” us:=”” mapping=”” logical=”” addresses=”” addresses,and=”” dynamically=”” acquiring=”” campus.=”” example=”” resolution=”” protocol,=”” arp=”” li%j82].=”” extensions=”” requird,=”” however,=”” modifications=”” made=”” code=”” properly=”” mobile=”” hosts.=”” second=”” migrates=”” acquire=”” 2.4.1=”” algorithm=”” find=”” broadcast=”” medium=”” request=”” target=”” broadcas~=”” requested=”” 238=”” respond,=”” unless=”” “published”=”” entry=”” cache,=”” too=”” respond.=”” context=”” networking,=”” we=”” faced=”” followingproblern=”” communicate=”” mh,=”” two=”” ad&esses=”” subnet,=”” first=”” second,=”” since=”” thinks=”” indeed=”” request.=”” not,=”” ‘proxy-arp’=”” other=”” happens,=”” encapsulate=”” artipipdatagram,=”” handling=”” mtftic.=”” 2=”” shows=”” pseudo-code=”” reply=”” regular=”” codq=”” else=”” unknown=”” drop=”” packe~=”” attempt=”” locate=”” ic=”” proxy-arp=”” 2:=”” modified=”” it.=”” ‘attempt=”” it’=”” step=”” explaining.=”” section=”” 2.7.2,=”” contact=”” sent=”” continue=”” arping=”” until=”” gets=”” exists,=”” arrivq=”” next=”” request,=”” proxy-arp.=”” does=”” exist=”” unreachable,=”” behavior=”” system=”” trying=”” non-existent=”” 2.4.2=”” dynamic=”” ip-address=”” assignment=”” into=”” requests=”” tatk=”” ipippackets=”” maintain=”” open=”” connections=”” knows=”” moved=”” portion=”” own.4=”” 41f=”” fie=”” mh~=”” *=”” ~ampus=”” ~dy=”” their=”” own=”” networtrnurn~r.=”” msssare=”” addresseson=”” az=”” transmit=”” beacons=”” mhs.=”” llnrs,=”” own.=”” implemented=”” variety=”” ways,=”” involve=”” identifier=”” uniquely=”” associated=”” (e.g.,=”” ethernet=”” (or=”” network)=”” address)=”” protocols,=”” rarp=”” llwfmt84]=”” bootp=”” [cg85]=”” provide=”” physical-to-logical=”” mappings=”” functionality,=”” easily=”” extended=”” assign=”” addresses.=”” exact=”” algorithms=”” assigning=”” addressesare=”” beyond=”” scope=”” paper.=”” existing=”” under-development=”” [dro91]=”” maybe=”” used.=”” 2.5=”” 2.2=”” sketched=”” how=”” datagrams=”” delivered=”” cells,=”” merely=”” table=”” default=”” program=”” listening=”” that.=”” must=”” decide=”” &tagram.=”” kept=”” kernel=”” each=”” about.=”” key=”” field=”” additional=”” fields=”” include=”” mhs,=”” p=”” (if=”” address);=”” traffiq=”” timer=”” field,=”” reset=”” every=”” time=”” accessed,that=”” expire=”” entries=”” been=”” recently.=”” output=”” routine=”” modifi~,=”” includes=”” logic:=”” locally=”” appropriate=”” interfac%=”” known=”” corresponding=”” mss;=”” packec=”” 3:=”” ipip,=”” encapsulation,=”” micp,=”” again,=”” note=”” 239=”” contact;=”” cannot=”” found,=”” originated=”” communication=”” give=”” up.=”” similar=”” above.=”” 2.6=”” ipip:=”” ip-within-ip=”” ‘tunnel’=”” another,=”” essentially=”” virtuat=”” connections,=”” already=”” shown=”” 3.=”” problem=”” solve=”” here=”” datagram=”” (the=”” mh)=”” whose=”” deduced=”” summary,=”” obvious=”” possible=”” solutions:=”” l=”” change=”” moves.=”” why=”” undesirable.=”” per-host,=”” rather=”” per-subnet,=”” routers,=”” updating=”” move.=”” prohibitively=”” expensive,=”” terms=”” messagesand=”” bandwidth=”” propagate=”” routes,=”” storage=”” routers=”” themselves.=”” source-route=”” ros81a]=”” router=”” central=”” machine=”” registering=”” keeping=”” track=”” mh‘s=”” (some=”” kind=”” ‘network=”” identifier’=”” cell),=”” set=”” mss-likemachines=”” explicitly=”” define=”” asdescribed=”” section,=”” keep=”” tunnel=”” either=”” (loose)=”” encapsulation.=”” sense,=”” encapsulation=”” equivalent=”” loose=”” routing.=”” difference’=”” sourcerouting=”” depends=”” option=”” being=”” along=”” path,=”” whereas=”” module=”” endpoints=”” tunnel.=”” given=”” environment=”” targetting=”” (both=”” intra-=”” inter-campus=”” large=”” vendors,=”” control),=”” chose=”” last=”” solution.=”” layer,=”” tables=”” consulted.=”” 3,=”” destination=”” (with=”” mss),=”” type=”” ipproto_ipip,=”” protocolnumber=”” 94=”” ~ey91],=”” thus,=”” addressesof=”” receipt=”” hands=”” module.=”” strips=”” header=”” and,=”” after=”” decrementing=”” time-to-live=”” feeds=”” (which=”” real=”” addresses)back=”” queue=”” checks=”” was=”” these=”” detailed=”” 2.7.2.=”” 2.7=”” micp:=”” internetworking=”” intemetworkingcontrolprotocol=”” information,=”” signat=”” changed=”” cells.=”” ipproto_micp,=”” 95=”” lj?ey91].=”” three=”” classes=”” traffic;=”” mh-mss=”” handshakes,=”” mss-mss=”” exchanges=”” distribute=”” exchanges.=”” 2.7.1=”” mh-to-mss=”” handshaking=”” know=”” establish=”” alternatives=”” identification=”” are(a)=”” periodically=”” identity,=”” (b)=”” newcomer=”” m=”” h=”” former=”” because=”” way=”” hs=”” atready=”” tell=”” within=”” realm=”” conceivable=”” ffom=”” time.=”” usuatly=”” adjacent=”” overlap.=”” gives=”” indication=”” strength,=”” want=”” strongest=”” signal.=”” otherwise,=”” wait=”” longer=”” receives=”” before=”” yet=”” investigated.=”” mi=”” cp.beacon,=”” containing=”” primary=”” mask=”” current=”” (i.e,=”” cells),=”” responds=”” cp-greet.=”” contains=”” zero=”” entering),=”” 240=”” timestamp,=”” greeting=”” packet,=”” cp.grack=”” (greeting=”” acknowledge).=”” updates=”” relevant=”” structures=”” indicate=”” local,=”” records=”” supplied=”” sends=”” forwarding=”” pointer=”” previously=”” got=”” considers=”” often=”” enough=”” missing=”” cause=”” assume=”” lost,=”” it,=”” greeting.=”” acknowledgement=”” acknowledgement.=”” samecell,=”” effects=”” types=”” idempotenc=”” successful=”” [email protected]=”” handshake,=”” duplicate=”” ignored.=”” greetings=”” overwrite=”” acknowledgements=”” effect=”” coming=”” 2.7.2=”” dissemination=”” greeting,=”” micp_fwdptr=”” (forwarding=”” pointer)=”” originating=”” segment(s)=”” on.=”” retransmitting=”” cp.fwdack=”” acknowledgement).=”” make=”” certain=”” serves.=”” away=”” receiving=”” ipip-encapsulated=”” msss.=”” migrated,=”” informs=”” those=”” fact=”” sending=”” cp.redirect.=”” serves,=”” cache=”” currently=”” serving=”” redirect=””
sender.=”” avoid=”” rely=”” timeouts=”” higher-level=”” gone.=”” had=”” ‘courtesy’=”” result=”” sent.=”” eventually,=”” involved=”” converge=”” point=”” expire.=”” assuming=”” faster=”” travel,=”” times.=”” danger=”” lost=”” informed=”” movement.=”” problems;=”” received,=”” offending=”” hence,=”” explicit=”” needed.=”” handle,=”” notifies=”” sender=”” cp_expired.=”” subsequently=”” peer=”” discovery=”” next.=”” loss=”” scenario=”” redirec~=”” asked=”” about,=”” discover=”” responsible=”” drops=”” (again,=”” higherlevel=”” timeout=”” retransmit=”” it)=”” cp.whohas=”” asking=”” cp.jhave.=”” on-demand=”” allows=”” involvedin=”” mhs’=”” alternative=”” would=”” notify=”” others=”” unacceptably=”” high=”” cp-whohas=”” reply,=”” claiming=”” wrong=”” selected,=”” micp-redirect=”” extra=”” traftic,=”” cp_ihave=”” timestamp=”” cp-greet=”” message.=”” timestzt!npis=”” saved,sentwith=”” messages,=”” compared=”” against=”” messages.=”” timestamps=”” itself.=”” reference=”” base,=”” hence=”” issue=”” clocks=”” synchronized=”” arise.=”” required=”” increase=”” time,=”” maximum=”” vatue=”” wrap-arounds=”” occur=”” use,=”” granularity=”” small=”” likely=”” value=”” remains=””> </ip-within-ip”),>

Leave a Reply

Your email address will not be published. Required fields are marked *