File: rfc2103.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (955 lines) | stat: -rw-r--r-- 41,352 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955






Network Working Group                                      R. Ramanathan
Request for Comments: 2103                  BBN Systems and Technologies
Category: Informational                                    February 1997


   Mobility Support for Nimrod :  Challenges and Solution Approaches

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   We discuss the issue of mobility in Nimrod.  While a mobility
   solution is not part of the Nimrod architecture, Nimrod does require
   that the solution have certain characteristics.  We identify the
   requirements that Nimrod has of any solution for mobility support.
   We also classify and compare existing approaches for supporting
   mobility within an internetwork and discuss their advantages and
   disadvantages.  Finally, as an example, we outline the mechanisms to
   support mobility in Nimrod using the scheme currently being developed
   within the IETF - namely, the Mobile-IP protocol.

Table of Contents

   1  Introduction...................................................  1
   2  Mobility :  A Modular Perspective..............................  2
   3  Effects of Mobility............................................  4
   4  Approaches.....................................................  6
   5  Solution using IETF Mobile-IP.................................. 10
      5.1 Overview .................................................. 10
      5.2 Protocol Details........................................... 11
   6  Security Considerations........................................ 15
   7  Summary........................................................ 16
   8  Acknowledgements............................................... 16
   9  Author's Address............................................... 17

1  Introduction

   The nature of emerging applications makes the support for mobility
   essential for any future routing architecture.  It is the intent of
   Nimrod to allow physical devices as well as networks to be mobile.

   Nimrod, as a routing and addressing architecture, does not directly
   concern itself with mobility.  That is, Nimrod does not propose a
   solution for the mobility problem.  There are two chief reasons for



Ramanathan                   Informational                      [Page 1]

RFC 2103                Nimrod Mobility Support            February 1997


   this.  First, mobility is a non-trivial problem whose implications
   and requirements are still not well understood and will perhaps be
   understood only when a mobile internetwork is deployed on a large
   scale.  Second, a number of groups (for instance the Mobile-IP
   working group of the IETF) are studying the problem by itself and it
   is not our intention to duplicate those efforts.

   This attitude towards mobility is consistent with Nimrod's general
   philosophy of flexibility, adaptability and incremental change.

   While a mobility solution is not part of the "core" Nimrod
   architecture, Nimrod does require that the solution have certain
   characteristics.  It is the purpose of this document to discuss some
   of these requirements and evaluate approaches towards meeting them.

   We begin by identifying the precise nature of the functionality
   needed to accommodate mobile entities (section 2).  Following that,
   we discuss the effects of mobility on Nimrod (section 3).  Next, we
   classify current and possible approaches to a solution for mobility
   (section 4) and finally (in section 5) we describe how mobility can
   be implemented using the IETF's Mobile-IP protocol.

   This document uses many terms and concepts from the Nimrod
   Architecture document [CCS96] and some terms and concepts (in section
   5) from the Nimrod Functionality document [RS96].  Much of the
   discussion assumes that you have read at least the Nimrod
   Architecture document [CCS96].

2  Mobility :  A Modular Perspective

   Nimrod has a basic feature that helps accommodate mobility in a
   graceful and natural manner, namely, the separation of the endpoint
   naming space from the locator space.  The Nimrod architecture [CCS96]
   associates an endpoint with a globally unique endpoint identifier
   (EID) and an endpoint label (EL). The location of the endpoint within
   the Internetwork topology is given by its locator.  When an endpoint
   moves, its EID and EL remain the same, but its locator might change.
   Nimrod can route a packet to the endpoint after the move, provided it
   is able to obtain its new locator.












Ramanathan                   Informational                      [Page 2]

RFC 2103                Nimrod Mobility Support            February 1997


   Thus, providing a solution to mobility in the context of Nimrod may
   be perceived as one of maintaining a dynamic association between the
   endpoints and the locators.  Extending this viewpoint further, one
   can think of mobility-capable Nimrod as essentially consisting of two
   "modules":  the Nimrod routing module and the dynamic association
   module (DAM). The DAM is an abstraction, embodying the functionality
   pertinent to maintaining the dynamic association.  This is a valuable
   paradigm because it facilitates the comparison of various mobility
   schemes from a common viewpoint.  Our discussion will be structured
   based on the DAM abstraction and will be in two parts, the themes of
   which are :

   o What constitutes mobility for the DAM and Nimrod?  Is the
     realization of mobility as a mobility "module" that interacts
     with Nimrod viable? What then are the interactions between
     Nimrod and such a module?  These points will be discussed in
     section 3.

   o What are some of the approaches one can take in engineering the DAM
     functionality?  We classify some approaches and compare them in
     section 4.

   A word of caution:  the DAM should not be thought of as something
   equivalent to the current day Domain Name Service (DNS) - the DAM is
   a more general concept than that.  For instance, consider a mobility
   solution for Nimrod similar to the scheme described in [Sim94].  Very
   roughly, this approach is as follows:  Every endpoint is associated
   with a "home" locator.  If the endpoint moves, it tells a "home
   representative" about its new locator.  Packets destined for the
   endpoint sent to the old locator are picked up by the home
   representative and sent to the new locator.  In this scheme, the DAM
   embodies the functionalities implemented by all of the home
   representatives in regard to tracking the mobile hosts.  The point is
   that the association maintenance, while required in some form or
   other, may not be an explicitly distinct part, but implicit in the
   way mobility is handled.

   Thus, the DAM is merely an abstraction useful to our discussion and
   should not be construed as dictating a design.

   In summary, we view the Nimrod architecture as carrying a functional
   "stub" for mobility, the details of the stub being deferred for
   later.  The stub will be elaborated when a solution that meets the
   requirements of Nimrod becomes available (for instance from the IETF
   Mobile-IP research).  We do not, however, preclude the modification
   of any such solutions to meet the Nimrod requirements or preclude the
   development of an independent solution within Nimrod.




Ramanathan                   Informational                      [Page 3]

RFC 2103                Nimrod Mobility Support            February 1997


3  Effects of Mobility

   One consequence of mobility is the change in the locator of an
   endpoint.  However, not all instances of mobility result in a locator
   change (for instance, there is no locator change if a host moves
   within a LAN) and a change in the locator is not the only possible
   effect of mobility.  Mobility might also cause a change in the
   topology map.  This typically happens when entire networks move
   (e.g., an organization relocates, a wireless network in a train or
   plane moves between cells, etc.).  If the network is a Nimrod
   network, we might have a change in the connectivity of the node
   representing the network and hence a change in the map.

   In this section, we consider the effects of mobility on the two
   "modules" identified above:  Nimrod, which provides routing to a
   locator, and a hypothetical instantiation of the DAM, which provides
   a dynamic endpoint-locator association, for use by Nimrod.  We
   consider four scenarios based on whether or not the topology and an
   endpoint's locator changes and comment on the effect of the scenarios
   on Nimrod and the DAM.

   Scenario 1.  Neither the locator nor the topology changes.  This
       is the trivial case and affects neither the DAM nor Nimrod.  An
       example of this scenario is when a workstation is moved to a new
       interface on the same local area network(This is not true for all
       LANs, only those in which all interfaces are part of the same
       Nimrod node) or when mobility is handled transparently
       (by lower layers).

   Scenario 2.  The locator changes but the topology remains the same.
       This is the case when an endpoint moves from one node to another,
       thereby changing its locator.  The DAM is affected in this case,
       since it has to note the new endpoint-locator association and
       indicate this to Nimrod if necessary.  The effect on Nimrod is
       related to obtaining this change from the DAM. For instance,
       Nimrod may be informed of this change or ask for the association
       if and when it finds out that the mobile host cannot be reached.

   Scenario 3.  The locator does not change but the topology changes.
       One way this could happen is if a network node moves and changes
       its neighbors (topology change) but remains within the same
       enclosing node.  The DAM is not affected because the
       endpoint-locator association has not changed.  Nimrod is affected
       in the sense that the topology map would now have to be updated.







Ramanathan                   Informational                      [Page 4]

RFC 2103                Nimrod Mobility Support            February 1997


   Scenario 4.  Both the locator and the topology change.  If a network
       node moves out of its enclosing node, we have a change both in
       the map and in the locators of the devices in the network.  In
       this case, both Nimrod and the DAM are affected.

   In scenarios 3 and 4, it may not be sufficient to simply let Nimrod
   handle the topological change using the update mechanisms described
   in [RS96].  These mechanisms are likely to be optimized for
   relatively slow changes.

   Mobile wireless networks (in trains and cars for instance) are likely
   to produce more frequent changes in topology.  Therefore, it might be
   necessary that topological updates caused by mobility be handled
   using additional mechanisms.  For instance, one might send specific
   updates to appropriate node representatives, so that packets entering
   that node can be routed using the new topology.  We observe that
   accommodating mobility of networks, especially the fast moving ones,
   might require a closer interaction between Nimrod and the DAM than
   required for endpoint mobility.  It is beyond the scope of this
   document to specify the nature of this interaction; however, we note
   that a solution to mobility should handle the case when a network as
   a whole moves.  Current trends [WJ92] indicate that such situations
   are likely to be common in future when wireless networks will be
   present in trains, airplanes, cars, ships, etc.

   In summary, if we discount the movement of networks, i.e., assume no
   topology changes, it appears that the mobility solution can be kept
   fairly independent of Nimrod and in fact can be accommodated by an
   implementation of the DAM. However, to accommodate network mobility
   (scenarios 3 and 4), it might be necessary for Nimrod routing/routers
   to get involved with mobility.

   Beyond the constraints imposed by the interaction with Nimrod, it is
   desirable that the mobility solution have some general features.  By
   general, we mean that these are not Nimrod specific.  However, their
   paramount importance in future applications makes them worth
   mentioning in this document.  The desirable features are :

   o Support of both off-line and on-line mobility.  Off-line mobility
     (or portability) refers to the situation in which a session is
     torn down during the move, while on-line mobility refers to the
     situation in which the session stays up during the move.  While
     currently much of the mobility is off-line, trends indicate that
     a large part of mobility in the future is likely to be on-line.  A
     solution that only supports off-line mobility would probably have
     limited applications in future.





Ramanathan                   Informational                      [Page 5]

RFC 2103                Nimrod Mobility Support            February 1997


   o Scalability.  One of the primary goals of Nimrod is scalability,
     and it would be contrary to our design goals if the mobility
     solution does not scale.  The Internet is rapidly growing and with
     the advent of Personal Communication Systems (PCS) [WJ92], the
     number and rapidity of mobile components in the Internet is also
     likely to increase.  Thus, there are three directions in which
     scalability is important :  size of the network, number of mobile
     entities and the frequency of movement of the mobile entities.

     Note that for any given system with minimum response time (to a
     move) of o seconds, if the mobile entity changes attachment points
     faster than 1=o changes per second, the system will fail to track
     the entity.  Augmenting traditional location tracking mechanisms
     with special techniques such as predictive routing might be
     necessary in this case.  Hooks in the mobility solution for such
     augmentation is a desirable feature.

   o Security.  It is likely that in the future, there will be increased
     demand for secure communications.  Apart from the non-mobility
     specific security mechanisms, the solution should address the
     following :

-  Authentication.  The information sent by a mobile host about its
   location should be authenticated to prevent impersonation.
   Additionally, there should be mechanisms to decide if a mobile user
   who wishes to join a network has the privileges to do so or not.

-  Denial of service.  The schemes employed for handling mobility in
   general could be a drain on the resources if not controlled
   carefully.  Specifically, the resource intensive portions of the
   protocol should be guarded so that inappropriate use of them does
   not cause excessive load on the network.

4  Approaches

   As discussed in section 2, the problem of mobility in the context of
   Nimrod may be viewed as one of maintaining a dynamic association
   (DAM) and communicating this association and changes therein to
   Nimrod.  Approaches to mobility may be classified based on how
   different aspects of the DAM are addressed.











Ramanathan                   Informational                      [Page 6]

RFC 2103                Nimrod Mobility Support            February 1997


   Our classification identifies two aspects to the mobility solution :

   1. How and where to maintain the dynamic association between
      endpoints and locators?  This may be perceived as a problem of
      database maintenance. The database may be maintained in a
      centralized fashion, wherein a single entity maintains the
      association and updates are sent to it by the mobile host or in
      a distributed fashion, wherein there are a number of entities
      that store the associations.

      A (distributed) database that stores the endpoint-locator
      mapping is required by Nimrod even in the absence of mobility.  If
      this service can accommodate dynamic update and retrieval requests
      at the rate produced by mobility, this service is a candidate for a
      solution. However, we note that the availability of such a system
      should not be a requirement for the mobility solution.

   2. Where to do the remapping between the endpoint and locator, in
      case of a change in association?  By remapping, we mean associate
      a new locator with the endpoint.  Some candidates are :  the
      source, the "home" location of the host that has moved and any
      router (say, between the source and the destination) in the network.

   Many of the existing approaches and perhaps some new approaches to
   the problem of mobile internetworking may be seen to be
   instantiations of a combination of a dynamic association method and a
   remapping method.  We

                         (Re-mapping location)
                                   |
                                   v
          -----------------------------------------
          |            |Source |  Home  | Routers |
          -----------------------------------------
 (Assoc.  |Centralized |  A1   |   X    |    X    |
  maint)-> ----------------------------------------
          |Distributed |  X    |   A2   |   A3    |
          ----------------------------------------

Table 1 : Classification of approaches based on how the association
          is maintained and where the remapping is done.










Ramanathan                   Informational                      [Page 7]

RFC 2103                Nimrod Mobility Support            February 1997


   consider some combinations as illustrated in Table 1.  We discuss
   three combinations (marked A1 - A3 in the table) and examine their
   advantages and disadvantages in the context of our requirements.  The
   other combinations (marked X in the table) are possible, but do not
   represent a substantially different class of solutions from the ones
   discussed and hence are not considered here.

   Note that this is but one classsification of mobility schemes and
   that the remapping and endpoint-locator maintenance strategies
   mentioned in the table are not exhaustive.  The main intention is to
   help understand better the kinds of approaches that would be most
   suitable for Nimrod.

   In the following, we use the term source to refer to the endpoint
   that is attempting to communicate with or sending packets to a mobile
   endpoint.  The source could be static or mobile.  We use the term
   mobile destination to refer to the endpoint that is the intended
   destination of the source's packets.

A1.  In this approach, all endpoint-locator mappings are maintained
    at a centralized location.  The source queries the database to
    get the locator of the mobile destination.  Alternatively, the
    database can send updates to the source when the mobile
    destination moves. The main advantage of this scheme is its
    simplicity.  Also, no modification to routers is required, and the
    route from the source to a mobile destination is direct.

    The main disadvantage of this scheme is vulnerability - if the
    centralized location goes down, all information is lost.  While
    this scheme may be sufficient for small networks with low
    mobility, it does not scale adequately to be a long term solution
    for Nimrod.

A2.  This approach uses distributed association maintenance with
    remapping done at the home.  This is the approach that is being
    used by the Mobile-IP working group of the IETF for the draft
    proposal and by the Cellular Digital Packet Data (CDPD)
    consortium.  In this approach, every mobile endpoint is associated
    with a "home" and a "home representative" keeps track of the
    location of every mobile endpoint associated with it.  A protocol
    between a mobile endpoint and the home representative is used to
    keep the information up-to-date.  The source sends the packet
    using the home locator of the mobile destination, and the home
    representative forwards the packet to the mobile destination. The
    advantage of this scheme is that it is fairly simple and does not
    involve either the source or the routers in the network.
    Furthermore, the mobile destination can keep its location secret
    (known only to the home representative) - this is likely to be a



Ramanathan                   Informational                      [Page 8]

RFC 2103                Nimrod Mobility Support            February 1997


    desirable feature for mobile hosts in some applications.  Finally,
    most of the control information is confined to the node containing
    the home representative and the mobile host and this is a plus for
    scalability. The main disadvantage is a problem often referred to
    as triangular routing.  That is, the packets have to go from the
    source to the home representative first before going to the mobile
    destination.  This is especially inefficient if, for instance,
    both the source and mobile destination are in, say, England and
    the home representative is in, say, Australia.  Also, there is
    still some vulnerability, since if the home representative becomes
    unreachable, the location of all of the mobile hosts it tracks is
    lost and communication from most sources to the mobile host is
    cut-off.  It is also not clear how well this scheme will scale to
    mobile internetworks of the future.

    Nevertheless, we feel that this approach or a modification thereof
    might be a viable first-cut mobility solution for Nimrod.

A3.  In each of the previous cases, the routers in the network were
    not involved in tracking the location of the mobile host.  In
    this approach, state is maintained in the routers.  An example
    is the approach proposed in [TYT91] wherein the packets sent by
    a mobile host are snooped and state is created.  The packets
    contain the mobile host's home location and its new location.
    This mapping is maintained at some routers in the network.  When
    a packet intended for the mobile host addressed to its home
    location enters such a router, a translation is made and the
    packet is redirected to the new location.

    An alternate mechanism is to maintain the mapping in all of the
    border routers (e.g., forwarding agents) in the node within which
    the movement took place.  A packet from outside the node intended
    for a destination within the node would typically enter the node
    through one of the border routers.  Using the mapping, the border
    router could figure out the most recent locator of the mobile
    destination and send the packet directly to that locator.  If most
    of the movements are within low level nodes, this would scale to
    large numbers of movements. Furthermore, the packet takes an
    optimal path (or as optimal as one can get with a hierarchical
    network) to the new location within the time it takes for the node
    representative to get the new information, which is typically
    quite small for low-level nodes.









Ramanathan                   Informational                      [Page 9]

RFC 2103                Nimrod Mobility Support            February 1997


    The main disadvantage of this scheme is that routers have to be
    involved.  However, future requirements in regard to scalability and
    response time might necessitate such an approach.  Furthermore, this
    solution has closer ties with Nimrod routing and is better suited to
    handling scenarios 3 and 4 where the topology changes as a result of
    mobility.

   All of these approaches seem potentially capable of handling
   scenarios 1 and 2 of the previous section.  Scenarios 3 and 4 are
   best handled by an approach similar to A3.  However, approaches like
   A3 are more complex and involve more Nimrod entities (e.g., routers)
   than may be desirable.

   We have tried to bring out the various issues governing mobility in
   Nimrod.  In the final analysis, the tradeoffs between the various
   options will have to be examined vis-a-vis our particular
   requirements (for instance, the need to support network mobility) in
   adopting a solution.  It is likely that general requirements such as
   scalability and security will also influence the direction of the
   approach to mobility in Nimrod.

5  A Solution using IETF Mobile-IP

   The Mobile-IP Working Group of the IETF is in the process of
   standardizing a protocol that allows an IPv4 capable network to
   support mobile hosts.  In this section, we outline how mobility can
   be implemented within Nimrod using the same mechanism and indeed, the
   same protocol headers defined in [Sim94].  Not all functionality
   described in [Sim94] are covered - only those that form the "core" of
   mobility support.

   In order to follow this section, the reader is required to have some
   familiarity with the IETF Mobile-IP protocol (see [Sim94]).

5.1  Overview

   The general scheme employed by the IETF Mobile-IP protocol is as
   follows.  A Mobile Host (MH) has a predefined Home Agent (HA) that is
   responsible for the MH's whereabouts.  Typically, the MH spends most
   of its time in the network containing the HA. Let us assume that the
   MH wanders to a new network.  The MH then contacts a Foreign Agent
   (FA) at the new network that will act on its behalf and sends a
   registration request to the HA via the FA. This serves the purpose of
   informing the HA of the MH's new whereabouts and also is a means of
   verification of the MH's authenticity.  It also contains the address
   of the FA as the new Care-of-Address.  A correspondent host (CH)
   wishing to send a message to the MH uses the MH's Home IP address.
   This message is captured by the HA and tunnelled using encapsulation



Ramanathan                   Informational                     [Page 10]

RFC 2103                Nimrod Mobility Support            February 1997


   to the FA whereupon the FA decapsulates and sends the original
   message to the MH.

   If the MH can get itself a new transient address then there is no
   need for a Foreign Agent.  The transient address will be sent as the
   Care-of-Address.  The packets will be tunnelled directly to this
   address by the Home Agent.  Note, however, that some networks may
   require that a mobile host go through a Foreign Agent.

   A fundamental difference between IP and Nimrod is that in the latter
   an endpoint has both a (topologically sensitive) locator and a
   (topologically insensitive) endpoint-id (EID). In IP, the IP address
   serves as both the EID and the locator.  Thus, it should be possible
   to use the Mobile-IP protocol for providing mobility support in
   Nimrod by simply using the EID of the MH wherever its Home IP Address
   was being used and by appropriately using the EID and locator of the
   FA and HA in place of their IP addresses (An issue is the format and
   length compatibility between EIDs and IP addresses.  For the
   discussion here, we assume that an EID can fit into an IP (v4 or v6)
   address given in Figure 1).  We give below the details of the
   protocol fields and the actions taken by the MH, FA and HA to show
   that this is possible and that it is quite simple.

5.2  Protocol Details

   There are two kinds of protocol headers relevant to our discussion -
   the Mobile-IP Protocol (MIPP headers) and the headers for data
   packets transported by Nimrod (NP headers).  It is our intent that
   Nimrod use, as much as possible, the next generation IP (IPv6)
   header.  The NP header contains as a subset fields that would
   eventually be present in the IPv6 header.

   In the scheme given below, the MIPP header is enclosed within the NP
   packet (i.e., MIPP operates over NP). The details of the fields
   constituting the NP header are beyond the scope of this document.
   However, without venturing into bit lengths, etc., we identify below
   a few fields that are relevant to our discussion:

   o Source EID (S-EID) : The endpoint ID of the source entity
     originating the packet.

   o Destination EID (D-EID) : The endpoint ID of the destination.

   o Source locator (S-LOC) : Locator of the entity originating the
     packet.

   o Destination locator (D-LOC) : Locator of the destination.




Ramanathan                   Informational                     [Page 11]

RFC 2103                Nimrod Mobility Support            February 1997


   The MIPP header fields are described in [Sim94].

   In what follows, we describe the values that must be assigned to the
   relevant NP and MIPP fields in order for Nimrod to work with Mobile-
   IP.  There are three phases we must consider : agent discovery,
   registration and forwarding [Sim94].  A pictorial summary of the
   control and data packets is given in Figure 1.

   Agent Discovery: In this phase, the MH discovers the foreign agent,
   if any, that will act on its behalf.  In MIPP, this is done using the
   ICMP Router Discovery messages.

   When an MH attaches to a Nimrod network (node), foreign agent
   discovery is done as follows.  We assume that a link-level connection
   is established between the MH and a node N belonging to the network.
   For instance, this node could be a wireless equipped base station
   that establishes a signalling channel for communication with the MH.

   If the MH is itself a node then N and the MH execute an arc formation
   procedure between themselves as described in [RS96].  This results in
   a locator being assigned to the MH and to the arcs between N and MH.

   If the MH is not a node but only an endpoint, then MH initiates
   locator acquisition procedure as described in [RS96].  This results
   in a locator being assigned to the MH.

   The MH then sends a Foreign Agent Request message to N. This message
   contains, amongst other information, the EID and locator of the MH.
   If N is not itself the foreign agent, then we assume that it knows of
   and has the ability to reach a foreign agent.

   The foreign agent (FA) notes the EID of the MH in its Visitor List
   and sends a Foreign Agent Reply to the MH. This contains the EID and
   the locator of the FA and will be used as the "Care-of-Address" (COA)
   of the MH for a prespecified period.

   Registration: In the registration phase, infomation is exchanged
   between the MH and the Home Agent (HA). The HA could, for instance,
   be the endpoint representative of the endpoint in its home location.
   The registration procedure is used to create a mobility binding which
   the HA uses to forward data packets intended for the MH. Another
   purpose of registration is to verify the authenticity of the MH.

   There are four parts to the registration.  We describe the values
   assigned to the relevant fields.  Recall that there are two headers
   we must create - the Nimrod Protocol (NP) header and the Mobile-IP
   Protocol (MIPP) header.  The NP fields are as described above and the
   MIPP fields are as in [Sim94].  The fields mh-eid(mh-loc), fa-



Ramanathan                   Informational                     [Page 12]

RFC 2103                Nimrod Mobility Support            February 1997


   eid(fa-loc), ha-eid(ha-loc) are used to refer to the EID (locator) of
   the mobile host, foreign agent and home agent respectively.

   1. The MH sends a Registration Request to the prospective Foreign
      Agent to begin the registration process.

   o NP fields :  S-EID = mh-eid; D-EID = fa-eid; S-LOC = mh-loc ; D-LOC
     = fa-loc.

   o MIPP fields :  Home Agent = ha-eid; Home Address = mh-eid;
     Care-of-Address = fa-eid.

   Note that the mh-loc is known to the MH by virtue of the locator
   acquisition (see paragraph on "Agent Discovery") and that the fa-eid
   is known to the MH from the Foreign Agent Reply.  The FA caches the
   mh-eid for future reference.

   2. The Foreign Agent relays the request by sending a Registration
      Request to the Home Agent, to ask the Home Agent to provide the
      requested service.

   o NP fields :  S-EID = fa-eid; D-EID = ha-eid; S-LOC = fa-loc; D-LOC
     = ha-loc.

   o MIPP fields :  Same as in (copied from) (1) above.

   The HA caches the (Home Address, Care-of-Address) as a mobility
   binding.  Optionally, for efficiency, it may also cache fa-loc.

   3. The Home Agent sends a Registration Reply to the Foreign Agent to
      grant or deny service.

   o NP fields :  S-EID = ha-eid; D-EID = fa-eid; S-LOC = ha-loc; D-LOC
     = fa-loc.

   o MIPP fields :  Home Address = mh-eid; code = as in [Sim94].

   The S-EID and D-EID fields are taken from the Request and swapped, as
   are the S-LOC and D-LOC fields.  The Home Address in the MIPP is the
   same as the Home Address in the Request.  The code indicates whether
   or not permission was granted by the Home Agent.

   4. The Foreign Agent sends a copy of the Registration Reply to the MH
      to inform it of the disposition of its request.

   o NP fields :  S-EID = fa-eid; D-EID = mh-eid; S-LOC = fa-loc; D-LOC
     = mh-loc.




Ramanathan                   Informational                     [Page 13]

RFC 2103                Nimrod Mobility Support            February 1997


   o MIPP fields :  Same as (copied from) (3) above.

   At this point the MH is registered with the HA (provided the
   registration request is approved by the HA) and packets can be
   forwarded to the MH.

  +--------+
  |  CH    |
  +--------+
      V
      V
  #--------------#
  |mh-eid | data | = P(orig)
  #--------------#
      V
  +--------+  *----------------*   +--------+ *--------------* +------+
  |        |  |fa-eid | mh-eid |   |        | | ha-eid|mh-eid| |      |
  |        |  *----------------*   |        | *--------------* |      |
  |  HA    |------<-REG REQ-<------|  FA    |----<-REG REQ-<---| MH   |
  |        |   2                   |        |  1               |      |
  | mh-eid |                    3  | mh-eid |                4 |      |
  |   |    |------>-REG REPL->-----|   |    |---->-REG REPL->--|      |
  |   v    |  *----------------*   |   v    | *--------------* |      |
  | fa-eid |  |mh-eid | yes/no |   | mh-loc | |mh-eid|yes/no | |      |
  |        |  *----------------*   |        | *--------------* |      |
  |        |  #------------------# |        | #---------#      |      |
  |        |>>|       #--------# |>|        |>| P (orig)|>>>>> |      |
  +--------+5 |fa-eid | P(orig)| | +--------+ #---------#  6   +------+
              |       #--------# |
              #------------------#

Figure 1 : The control and data packets for mobility handling using
           the Mobile-IP protocol. The packets bordered as # denote
           data packets and those bordered * denote control packets.
           Only the crucial information conveyed in each message is
           shown (i.e., locators and EIDs in packet headers are not
           shown. The associations maintained at HA and FA are shown.

   Forwarding Data: We describe the manner in which a packet from the
   correspondent host (CH) intended for the MH is encapsulated and
   forwarded by the HA.

o At HA : Suppose that a packet P intended for MH arrives at HA. For
  instance, P first comes to the router for the local network and the
  router finds that MH is unreachable.  The router then forwards P to the
  HA for possible redirection.





Ramanathan                   Informational                     [Page 14]

RFC 2103                Nimrod Mobility Support            February 1997


   The HA extracts the destination EID from the NP header for P. If no
   match is found in its mobility binding, then the MH is deemed as
   unreachable.  If a match is found, the corresponding fa-eid is
   extracted.  A new header is prepended to P. For this header, S-EID =
   ha-eid, D-EID = fa-eid, S-LOC = ha-loc and D-LOC = fa-loc.  The fa-
   loc may be obtained from the Association Database [CCS96].
   Alternatively, if it was cached in (2) above, it could be obtained
   from the cache.

o At FA: By looking at the next header field in the Nimrod Protocol
  packet header, the FA knows that the packet is an encapsulated one.
  It removes the wrapping and looks at the EID in P. If that EID is
  found in the Visitor List then the FA knows the locator of the MH
  and can deliver the packet to the MH. Otherwise, the packet is
  discarded and an error message is returned to HA.

   Other Issues: We have not addressed a number of issues such as
   deregistration, authentication, etc.  The mobility specific portion
   of authentication can be adapted from the specification in [Sim94];
   deregistration can be done in a manner similar to registration.

   The protocol in [Sim94] describes a registration scheme without the
   involvement of the Foreign Agent.  This is done when the MH obtains a
   transient IP address using some link-level protocol (e.g.  PPP). A
   similar scheme can be given in the context of Nimrod.  In this case,
   the MH obtains its locator (typically inherited from the node to
   which it attaches) and sends this locator as its Care-of-Address in
   the Registration Request.  The HA, while forwarding, uses this as the
   locator in the outer NP header and thus the encapsulated packet is
   delivered directly to the MH which then decapsulates it.  No Foreign
   Agent Discovery is needed.  Apart from this, the fields used are as
   described for the scheme with the FA.

   We note however that many networks may require that the registration
   be through a Foreign Agent, for purposes of security, billing etc.

6  Security Considerations

   The registration protocol between a mobile host and the network (for
   instance, in the mobile-ip protocol, the MH and the HA) contains
   security mechanisms to validate access, prevent impersonation etc.

   This document is not a protocol specification and therefore does not
   contain a description of security mechanisms for Nimrod.







Ramanathan                   Informational                     [Page 15]

RFC 2103                Nimrod Mobility Support            February 1997


7  Summary

o Nimrod permits physical devices to be mobile, but does not specify a
  particular solution for routing in the face of mobility.

o The fact that the endpoint naming (EID) space and the locator space are
  separated in Nimrod helps in accommodating mobility in a graceful and
  natural manner.  Mobility may be percieved, essentially, as dynamism in
  the endpoint - locator association.

o Nimrod allows two kinds of mobility:

   -  Endpoint mobility.  For example, when a host in a network moves.
      This might cause a change in the locator associated with the host,
      but does not cause a change in the topology map for Nimrod.

   -  Network mobility.  For example, when a router or an entire network
      moves.  This might cause a change in the topology in addition to
      the locator.

o Endpoint mobility may be handled by maintaining a dynamic association
  between endpoints and locators.  However, network mobility requires
  addressing the topology change problem as well.

o Apart from the ability to handle network mobility, it is desirable that
  the mobility solution be scalable to large networks and large numbers
  of mobile devices and provide security mechanisms.

o There are a number of existing and emerging solutions to mobility.  In
  particular, adaptation of solutions developed by the IETF is a first
  cut possibility for Nimrod.  As the description given in section 5
  shows, it is relatively easy to implement the scheme being designed by
  the Mobile-IP working group in the context of Nimrod.

8  Acknowledgements

   We thank Isidro Castineyra (BBN), Charles Lynn (BBN), Martha
   Steenstrup (BBN) and other members of the Nimrod Working Group for
   their comments and suggestions on this memo.












Ramanathan                   Informational                     [Page 16]

RFC 2103                Nimrod Mobility Support            February 1997


9  Author's Address

   Ram Ramanathan
   BBN Systems and Technologies
   10 Moulton Street
   Cambridge, MA 02138

   Phone :  (617) 873-2736
   Email :  ramanath@bbn.com

References

[CCS96] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod
        Routing Architecture", RFC 1992, August 1996.

[RS96]  Ramanathan, S., and M. Steenstrup.  Nimrod functional and
        protocol specifications, Work in Progress.

[Sim94] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

[TYT91] F. Teraoka, Y. Yokote, and M. Tokoro.  A network architecture
        providing host migration transparency.  In Proceedings of ACM
        SIGCOMM, 1991.

[WJ92]  K. A. Wimmer and J. B. Jones.  Global development of pcs. IEEE
        Communications Magazine, pages 22--27, Jun 1992.

























Ramanathan                   Informational                     [Page 17]