Internet DRAFT - draft-watari-nemo-nested-cn

draft-watari-nemo-nested-cn





NEMO Working Group                                             M. Watari
Internet-Draft                                                  T. Ernst
Expires: August 19, 2005                         WIDE at Keio University
                                                       February 18, 2005


           Route Optimization with Nested Correspondent Nodes
                     draft-watari-nemo-nested-cn-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 19, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document aims at assisting the problem statement of route
   optimization in nested mobile networks.  We describe the paths
   packets would take using existing Mobile IPv6 and NEMO Basic Support
   mechanisms when one or both end nodes of a communication flow are
   located in a nested NEMO.  One of both of the end nodes may
   themselves be either mobile nodes performing Mobile IPv6, or standard
   IPv6 nodes performing no mobility function at all.  The path can



Watari & Ernst          Expires August 19, 2005                 [Page 1]

Internet-Draft             RO with Nested CN               February 2005


   become extremely suboptimal if no optimization is provided.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  CN located in the fixed infrastructure . . . . . . . . . . . .  4
     2.1   Case A: LFN and standard IPv6 CN . . . . . . . . . . . . .  4
     2.2   Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . . .  5
     2.3   Case C: VMN and standard IPv6 CN . . . . . . . . . . . . .  5

   3.  CN located in distinct nested NEMOs  . . . . . . . . . . . . .  7
     3.1   Case D: LFN and standard IPv6 CN . . . . . . . . . . . . .  7
     3.2   Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . . .  8
     3.3   Case F: VMN and standard IPv6 CN . . . . . . . . . . . . .  8

   4.  CN and MNN located in the same nested NEMO . . . . . . . . . . 10
     4.1   Case G: LFN and standard IPv6 CN . . . . . . . . . . . . . 10
     4.2   Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 11
     4.3   Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 11

   5.  CN located behind the same nested MR . . . . . . . . . . . . . 13
     5.1   Case H: LFN and standard IPv6 CN . . . . . . . . . . . . . 13
     5.2   Case I: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 14
     5.3   Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 14

   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16

   7.  Changes from draft-watari-nemo-nested-cn-00  . . . . . . . . . 17

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18

       Intellectual Property and Copyright Statements . . . . . . . . 20














Watari & Ernst          Expires August 19, 2005                 [Page 2]

Internet-Draft             RO with Nested CN               February 2005


1.  Introduction

   This document assumes the reader is familiar with the NEMO Basic
   Support protocol defined in [1], and with Mobile IPv6 defined in [4].
   The reader should also be familiar with the NEMO Terminology defined
   in [2].

   The NEMO Basic Support protocol uses a bi-directional tunnel
   established between the mobile router and its home agents for all
   communications.  Such communication path brings many problems such as
   delay, packet loss, less MTU and so on as described in [3].  The
   values become even more crucial under a nested mobile network, and
   brings the need for route optimization.

   As the solutions to provide such route optimization are proposed, in
   this document, we try to describe some different communication models
   which involves a nested mobile network, and to clarify the issues for
   each cases.  We focus on the different cases involving nested
   correspondent nodes, from the NEMO Basic Support perspective.  A
   nested correspondent node is a correspondent node which itself is
   also a mobile network node.

   In the following sections, we illustrate the path followed by packets
   if we assume nodes only performing Mobile IPv6 and NEMO Basic Support
   mechanisms.  There are different cases to consider since a CN may
   either be located in the fixed infrastructure, in a nested NEMO, or
   in the same nested NEMO as the MNN.  Also, we have to consider the
   cases where CNs and MNNs are either standard IPv6 nodes or MIPv6
   nodes.  As defined in [2], standard IPv6 nodes are nodes with no
   mobility functions whatsoever, i.e.  they are not MIPv6-enabled nor
   NEMO-enabled (this does not only mean they cannot move around keeping
   open connections, but also that they can't process BUs sent by
   MIPv6-enabled peers).


















Watari & Ernst          Expires August 19, 2005                 [Page 3]

Internet-Draft             RO with Nested CN               February 2005


2.  CN located in the fixed infrastructure

   The most typical configuration is the case where a MNN communicates
   with a Correspondent Node (CN) attached in the fixed infrastructure.
   Figure 1 below shows an example of such topology.


                    +--------+  +--------+  +--------+
                    | MR1_HA |  | MR2_HA |  | MR3_HA |
                    +---+----+  +---+----+  +---+----+
                        |           |           |
                       +-------------------------+
                       |        Internet         |----+ CN
                       +-------------------------+
                               |               |
                           +---+---+        +--+-----+
                 root-MR   |  MR1  |        | VMN_HA |
                           +---+---+        +--------+
                               |
                           +---+---+
                  sub-MR   |  MR2  |
                           +---+---+
                               |
                           +---+---+
                  sub-MR   |  MR3  |
                           +---+---+
                               |
                           ----+----
                              MNN


               Figure 1: CN located at the infrastructure


2.1  Case A: LFN and standard IPv6 CN

   The simplest case is where both MNN and CN are fixed nodes with no
   mobility functions.  That is, MNN is a LFN, and CN is a standard IPv6
   node.  Packets are encapsulated between each MR and its respective
   HA.  As shown in Figure 2, in such case, the path between the two
   nodes would go through:










Watari & Ernst          Expires August 19, 2005                 [Page 4]

Internet-Draft             RO with Nested CN               February 2005


        1       2       3       4          3          2          1
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
   LFN                                                         IPv6 Node

             The digits represent the number of IPv6 headers.


              Figure 2: MNN and CN are standard IPv6 nodes


2.2  Case B: VMN and MIPv6 CN

   In this second case, both end nodes are MIPv6-enabled mobile nodes,
   that is, MNN is a VMN.  MIPv6 route optimization may thus be
   initiated between the two and packets wouldn't go through the HA of
   the VMN nor the HA of the CN (not shown in the figure).  However,
   packets will still be tunneled between each MR and its respective HA,
   in both directions.  As shown in Figure 3, the path between VMN and
   CN would go through:


        1       2       3       4          3          2          1
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
   VMN                                                             MIPv6


              Figure 3: MMN and CN are MIPv6 mobile nodes


2.3  Case C: VMN and standard IPv6 CN

   When the communication involves a MIPv6 node either as a MNN or as a
   CN, MIPv6 route optimization can not be performed because the
   standard IPv6 CN cannot process MIPv6 signaling.  Therefore, VMN
   would establish a bi-directional tunnel with its HA, which causes the
   flow to go out the nested NEMO.  Packets between MNN and CN would
   thus go through VMN's own HA (VMN_HA).  The path would therefore be
   as shown on Figure 4:













Watari & Ernst          Expires August 19, 2005                 [Page 5]

Internet-Draft             RO with Nested CN               February 2005


        2       3       4       5          4          3          2
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
   VMN                                                                |
                                                                      | 1
                                                                      |
                                                                      CN
                                                                  IPv6 Node


  Figure 4: MNN is a MIPv6 mobile node and CN is a standard IPv6 node

   Providing route optimization involving a MIPv6 node may require
   optimization among the MRs and the MIPv6 node.






































Watari & Ernst          Expires August 19, 2005                 [Page 6]

Internet-Draft             RO with Nested CN               February 2005


3.  CN located in distinct nested NEMOs

   The CN may be located in another nested NEMO, different from the one
   MNN is attached to, as shown on Figure 5.  We define such
   configuration as ``distinct nested NEMOs.''


              +--------+  +--------+  +--------+  +--------+
              | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
              +------+-+  +---+----+  +---+----+  +-+------+
                      \       |           |        /
         +--------+    +-------------------------+    +--------+
         | MR1_HA |----|        Internet         |----| VMN_HA |
         +--------+    +-------------------------+    +--------+
                          |                   |
                      +---+---+           +---+---+
            root-MR   |  MR1  |           |  MR4  |
                      +---+---+           +---+---+
                          |                   |
                      +---+---+           +---+---+
             sub-MR   |  MR2  |           |  MR5  |
                      +---+---+           +---+---+
                          |                   |
                      +---+---+           ----+----
             sub-MR   |  MR3  |              CN
                      +---+---+
                          |
                      ----+----
                         MNN


         Figure 5: MNN and CN located in distinct nested NEMOs


3.1  Case D: LFN and standard IPv6 CN

   Similar with Case A, we start off with the case where both end nodes
   do not have any mobility functions.  Packets are encapsulated at
   every mobile router on the way out the nested NEMO, decapsulated by
   the HAs and then encapsulated again on its way down the nested NEMO.











Watari & Ernst          Expires August 19, 2005                 [Page 7]

Internet-Draft             RO with Nested CN               February 2005


        1       2       3       4          3          2          1
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
   LFN                                                                |
                                                                      | 2
                                                 1       2       3    |
                                             CN --- MR5 --- MR4 --- MR4_HA
                                         IPv6 Node


              Figure 6: MNN and CN are standard IPv6 nodes


3.2  Case E: VMN and MIPv6 CN

   Similar with Case B, when both end nodes are MIPv6 nodes, the two
   nodes may initiate MIPv6 route optimization.  Again, packets will not
   go through the HA of the VMN nor the HA of the MIPv6 CN (not shown in
   the figure).  However, packets will still be tunneled for each MR to
   its HA and vise versa.  Therefore, the path between MNN and CN would
   go through:


        1       2       3       4          3          2          1
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
   VMN                                                                |
                                                                      | 2
                                                 1       2       3    |
                                             CN --- MR5 --- MR4 --- MR4_HA
                                            MIPv6


              Figure 7: MNN and CN are MIPv6 mobile nodes


3.3  Case F: VMN and standard IPv6 CN

   Similar to Case C, when the communication involves a MIPv6 node
   either as a MNN or as a CN, MIPv6 route optimization can not be
   performed because the standard IPv6 CN cannot process MIPv6
   signaling.  VMN would therefore establish a bi-directional tunnel
   with its HA.  Packets between MNN and CN would thus go through VMN's
   own HA as shown on figure Figure 8:









Watari & Ernst          Expires August 19, 2005                 [Page 8]

Internet-Draft             RO with Nested CN               February 2005


        2       3       4       5          4          3          2
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
   VMN                                                                |
                                                                      | 1
                                     1       2       3           2    |
                                 CN --- MR5 --- MR4 --- MR4_HA  --- MR5_HA
                              IPv6 Node


  Figure 8: MNN is a MIPv6 mobile node and CN is a standard IPv6 node









































Watari & Ernst          Expires August 19, 2005                 [Page 9]

Internet-Draft             RO with Nested CN               February 2005


4.  CN and MNN located in the same nested NEMO

   Figure 9 below shows the case where the two communicating nodes are
   connected behind a different MR, but the MRs are connected in the
   same nested NEMO, and thus behind the same root-MR.  Route
   optimization can avoid packets being tunneled outside the nested
   NEMO.


              +--------+  +--------+  +--------+  +--------+
              | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
              +------+-+  +---+----+  +---+----+  +-+------+
                      \       |           |        /
         +--------+    +-------------------------+    +--------+
         | MR1_HA |----|        Internet         |----| VMN_HA |
         +--------+    +-------------------------+    +--------+
                                    |
                                +---+---+
                      root-MR   |  MR1  |
                                +-------+
                                 |     |
                          +-------+   +-------+
                 sub-MR   |  MR2  |   |  MR4  |
                          +---+---+   +---+---+
                              |           |
                          +---+---+   +---+---+
                 sub-MR   |  MR3  |   |  MR5  |
                          +---+---+   +---+---+
                              |           |
                          ----+----   ----+----
                             MNN          CN


          Figure 9: CN and MNN located in the same nested NEMO


4.1  Case G: LFN and standard IPv6 CN

   Again, we start off with the case where both end nodes do not have
   any mobility functions.  Packets are encapsulated at every mobile
   router on the way out the nested NEMO via the root-MR, decapsulated
   and encapsulated by the HAs and then make their way back to the
   nested NEMO through the same root-MR.  Therefore, the path between
   MNN and CN would go through:







Watari & Ernst          Expires August 19, 2005                [Page 10]

Internet-Draft             RO with Nested CN               February 2005


        1       2       3       4          3          2          1
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
   LFN                                                                |
                                                                      | 2
                              1       2       3       4          3    |
                          CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA
                       IPv6 Node


             Figure 10: MNN and CN are standard IPv6 nodes


4.2  Case H: VMN and MIPv6 CN

   Similar with Case B and E, when both end nodes are MIPv6 nodes, the
   two nodes may initiate MIPv6 route optimization which will avoid the
   packets to go through the HA of the VMN nor the HA of the MIPv6 CN
   (not shown in the figure).  However, packets will still be tunneled
   between each MR and its respective HA in both directions.  Therefore,
   the path would be the same with Case G and go through:


        1       2       3       4          3          2          1
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
   VMN                                                                |
                                                                      | 2
                              1       2       3       4          3    |
                          CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA
                      MIPv6 Node


              Figure 11: MNN and CN are MIPv6 mobile nodes


4.3  Case I: VMN and standard IPv6 CN

   As for Case C and Case F, when the communication involves a MIPv6
   node either as a MNN or as a CN, MIPv6 route optimization can not be
   performed.  Therefore, VMN will establish a bi-directional tunnel
   with its HA.  Packets between MNN and CN would thus go through VMN's
   own HA.  The path would therefore be as shown on Figure 12:










Watari & Ernst          Expires August 19, 2005                [Page 11]

Internet-Draft             RO with Nested CN               February 2005


        2       3       4       5          4          3          2
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
   VMN                                                                |
                                                                      | 1
                   1       2       3       4          3          2    |
               CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
            IPv6 Node


  Figure 12: MNN is a MIPv6 mobile node and CN is a standard IPv6 node









































Watari & Ernst          Expires August 19, 2005                [Page 12]

Internet-Draft             RO with Nested CN               February 2005


5.  CN located behind the same nested MR

   Figure 13 below shows the case where the two communicating nodes are
   connected behind the same nested MR.  The optimization is required
   when the communication involves MIPv6-enabled nodes.


              +--------+  +--------+  +--------+  +--------+
              | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
              +------+-+  +---+----+  +---+----+  +-+------+
                      \       |           |        /
         +--------+    +-------------------------+    +--------+
         | MR1_HA |----|        Internet         |----| VMN_HA |
         +--------+    +-------------------------+    +--------+
                                    |
                                +---+---+
                      root-MR   |  MR1  |
                                +---+---+
                                    |
                                +-------+
                       sub-MR   |  MR2  |
                                +---+---+
                                    |
                                +---+---+
                       sub-MR   |  MR3  |
                                +---+---+
                                    |
                                -+--+--+-
                                MNN    CN


        Figure 13: MNN and CN located behind the same nested MR


5.1  Case H: LFN and standard IPv6 CN

   If both end nodes are LFNs, no special function is necessary for
   optimization of their communication.  The path between the two nodes
   would go through:












Watari & Ernst          Expires August 19, 2005                [Page 13]

Internet-Draft             RO with Nested CN               February 2005


                                  1
                             MNN --- CN
                             LFN   IPv6 Node


             Figure 14: MNN and CN are standard IPv6 nodes


5.2  Case I: VMN and MIPv6 CN

   Similar with Case H, when both end nodes are MIPv6 nodes, the two
   nodes may initiate MIPv6 route optimization.  Although few packets
   would go out the nested NEMO for the Return Routability
   initialization, however, unlike Case B and Case E, packets will not
   get tunneled outside the nested NEMO.  Therefore, packets between MNN
   and CN would eventually go through:


                                  1
                             MNN --- CN
                             VMN   MIPv6 Node


              Figure 15: MNN and CN are MIPv6 mobile nodes

   If the root-MR is disconnected while the nodes exchange keys for the
   RR procedure, they may not communicate even though they are connected
   on the same link.

5.3  Case I: VMN and standard IPv6 CN

   When the communication involves a MIPv6 node either as a MNN or as a
   CN, MIPv6 route optimization can not be performed.  Therefore, even
   though the two nodes are on the same link, VMN will establish a
   bi-directional tunnel with it's HA, which causes the flow to go out
   the nested NEMO.  Path between MNN and CN would require another HA
   (VMN_HA) to go through for this MIPv6 node:














Watari & Ernst          Expires August 19, 2005                [Page 14]

Internet-Draft             RO with Nested CN               February 2005


        2       3       4       5          4          3          2
   MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
   VMN                                                                |
                                                                      | 1
                   1       2       3       4          3          2    |
               CN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
            IPv6 Node


  Figure 16: MNN is a MIPv6 mobile node and CN is a standard IPv6 node









































Watari & Ernst          Expires August 19, 2005                [Page 15]

Internet-Draft             RO with Nested CN               February 2005


6.  Conclusion

   This document described the paths packets would take using existing
   Mobile IPv6 and NEMO Basic Support mechanisms when one or both end
   nodes of a communication flow are located in a nested NEMO.  One of
   both of the end nodes may themselves be either mobile nodes
   performing Mobile IPv6, or standard IPv6 nodes performing no mobility
   function at all.

   This draft aims at helping the definition of the problem statement
   for route optimization when one or both end nodes are located in a
   nested NEMO.  As emphasized on our figures, the path can become
   extremely un-optimal if no optimization is provided besides the sole
   opetation of existing Mobile IPv6 by some end nodes and NEMO Basic
   Support by the MR.  The generic solution to come up should cover all
   cases, providing certain level of optimization for each case.



































Watari & Ernst          Expires August 19, 2005                [Page 16]

Internet-Draft             RO with Nested CN               February 2005


7.  Changes from draft-watari-nemo-nested-cn-00

   - Removed paragraphs which mentioned solutions

   - Fixed figures

   - Updated references












































Watari & Ernst          Expires August 19, 2005                [Page 17]

Internet-Draft             RO with Nested CN               February 2005


8.  Acknowledgements

   The authors would like express their appreciation to people who have
   given valuable comments on the mailing list.

9  References

   [1]  Devarapalli, V., Wakikawa, R., Pestrescu, A. and P. Thubert,
        "Network Mobility (NEMO) Basic Support Protocol", RFC: 3963,
        February 2005.

   [2]  Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology",
        Internet Draft: draft-ietf-nemo-terminology-02.txt, Work In
        Progress, October 2005.

   [3]  Ng, C-W., Thubert, P., Ohnishi, H. and E. Paik, "Taxonomy of
        Route Optimization models in the Nemo Context", Internet Draft:
        draft-thubert-nemo-ro-taxonomy-03.txt, Work In Progress, October
        2005.

   [4]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", RFC: 3775, June 2004.


Authors' Addresses

   Masafumi Watari
   WIDE at Keio University
   Jun Murai Lab., Keio University.
   Shonan Fujisawa Campus, 5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Phone: +81-466-49-1394
   Fax:   +81-466-49-1395
   EMail: watari@sfc.wide.ad.jp















Watari & Ernst          Expires August 19, 2005                [Page 18]

Internet-Draft             RO with Nested CN               February 2005


   Thierry Ernst
   WIDE at Keio University
   Jun Murai Lab., Keio University.
   K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
   Kawasaki, Kanagawa  212-0054
   Japan

   Phone: +81-44-580-1600
   Fax:   +81-44-580-1437
   EMail: ernst@sfc.wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~ernst/








































Watari & Ernst          Expires August 19, 2005                [Page 19]

Internet-Draft             RO with Nested CN               February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Watari & Ernst          Expires August 19, 2005                [Page 20]