[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         M. Bagnulo
Internet-Draft                                                      UC3M
Expires: May 21, 2005                                  November 20, 2004


                Application of a multi6 protocol to nemo
                      draft-bagnulo-nemo-multi6-00

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 May 21, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   The goal of this note is to analyze the possible application of a
   multi6 protocol to provide nemo multihoming support.  We will first
   state the basic assumptions behind a multi6 protocol design and then
   we will analyze each of the multihoming configurations for nemo
   described in [1] in order to determine if the multi6 can provide the
   support required.





Bagnulo                   Expires May 21, 2005                  [Page 1]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Multi6 basics  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Application of multi6 to a multihomed nemo with basic
       support  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   The (*,*,1) cases  . . . . . . . . . . . . . . . . . . . .  6
     3.2   The (*,1,N) cases  . . . . . . . . . . . . . . . . . . . .  6
     3.3   The (*,N,N) cases  . . . . . . . . . . . . . . . . . . . .  7
   4.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 10
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 11





































Bagnulo                   Expires May 21, 2005                  [Page 2]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


1.  Introduction

   The goal of this note is to analyze the possible application of a
   multi6 protocol to provide nemo multihoming support.  We will first
   state the basic assumptions behind a multi6 protocol design and then
   we will analyze each of the multihoming configurations for nemo
   described in [1] in order to determine if the multi6 can provide the
   support required.  It should be noted that in this note we will only
   consider nemo basic support protocol and that route optimization
   considerations are considered out of the scope of this work.









































Bagnulo                   Expires May 21, 2005                  [Page 3]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


2.  Multi6 basics

   A multi6 solution is far from being defined, but there seems to be
   some consensus about some of its main characteristics.  In this
   section we will state the fundamental assumptions that are being made
   in the design of the multi6 solution that in our opinion are relevant
   when evaluating the application of a multi6 solution to nemo
   multihoming.

   The multi6 solution is designed to provide site multihoming support.
   The considered scenario is the following: a site S obtains internet
   connectivity through n providers i.e.  ISP1, ISP2,..., ISPn.  In
   order to preserve routing system scalability, the site's prefix will
   not be announced separately in the inter-domain routing system.
   Instead, the multihomed site will obtain one prefix from each of the
   ISPs that it is multihomed to, and each of the ISP prefixes will be
   announced in the global routing system.  The resulting configuration
   is the following:




        +------+     +------+          +------+
        | ISP1 |     | ISP2 |   ...    | ISPn |
        | P1   |     | P2   |          | Pn   |
        +------+     +------+          +------+
           |            |                 |
            \           |                /
             \          |               /
           +------------------------------+
           | multihomed site S            |
           | P1:S1::/l1                   |
           | P2:S2::/l2                   |
           |    ...                       |
           | Pn:Sn::/ln                   |
           +------------------------------+


   Since each ISP assigns a prefix to the multihomed site, then hosts
   within the multihomed site that want to benefit from multihoming have
   to configure multiple addresses, one per prefix assigned to the site.
   Because each ISP will only announce its own prefix in the
   inter-domain routing, a node will receive packets through ISPi only
   if the destination address contained in the packets contain the
   prefix delegated by ISPi to the site i.e.  Pi:Si::/li.  So, this mean
   that depending the address used to communicate with a host within the
   multihomed site, packets will flow through different ISPs.  In other
   words, in order to change the ISP through which packets are flowing



Bagnulo                   Expires May 21, 2005                  [Page 4]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


   to a host within the multihomed site, it is required to change the
   address of the host used to send packets.  So far we have considered
   packets flowing from the internet to the multihomed site, and we have
   concluded that in the configuration considered by multi6, the ISP
   used to carry packets is determined by the address of the multihomed
   host used in the communication.  We will next consider packets
   flowing from the multihomed site to the Internet.  In this case, it
   is assumed that ingress filtering can be deployed in some scenarios.
   This basically means, that the source address of the packet has to
   correspond to the prefix delegated by the ISP through which the
   packet is routed.  If this is not the case, the packet will be
   discarded.  In order to support ingress filtering, the packet is
   routed through the ISP that correspond s to the prefix included in
   the source address selected by the host.  This basically implies that
   the exit ISP will be determined by the source address selected by the
   host.

   Summarizing, multi6 protocol assumes that a multihomed site will
   obtain multiple prefixes and that hosts within the multihomed site
   that want to benefit from multihoming will configure multiple
   addresses, one per prefix available.  Moreover, both the incoming and
   the outgoing paths will be determined by the address of the
   multihomed host included in the packets implying that changing the
   address used results in a change in the ISP that is used to carry
   packets.  Then, the mechanism used by multi6 to re-home a
   communication when an outage occurs is to change the address used in
   the communication, causing a change in the ISP used.
























Bagnulo                   Expires May 21, 2005                  [Page 5]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


3.  Application of multi6 to a multihomed nemo with basic support

   In this section we will analyze if the multi6 solution can provide
   the multihoming support required in nemo.  We will analyze each of
   the configurations presented in [1] and we will determine if a multi6
   solution can provide the expected capabilities.

   The different configuration for nemo multihoming are classified in
   [1] according to 3 parameters: number of mobile routers (MR), number
   of home agents (HA) and number of mobile network prefixes (MNP).  The
   simplified terminology proposed in [1] is (# MR, # HA, # MNP) where
   each of the parameters can be 1 or N.

3.1  The (*,*,1) cases

   In these cases, there is only one prefix announced in the multihomed
   nemo.  Since a basic assumption of a multi6 solution is that multiple
   prefixes will be available and that the rehoming procedure relies on
   changing the prefix used for exchanging packet, then a multi6
   solution will not naturally provide multihoming support in these
   cases, since there is only one prefix available in the nemo.

   It would be possible then to artificially create additional prefixes
   in the nemo, so that each of the multiple paths available between the
   MR(s) and the HA(s) are associated with a different prefix,
   simulating the multi6 scenario.  If this option is adopted, then
   multi6 mechanisms could be used to select among the multiple
   available paths between the MR(s) and the HA(s).  However, we may
   consider that the scope of the multi6 solution is probably much
   broader than this particular problem.  That is, the multi6 solution
   involves both endpoints of the communication and deals with any kind
   of failure mode in the path between them.  On the other hand, in the
   (*,*,1) configurations what is needed is a mechanism to support
   multiple paths between the nemo and its home network.  This is much
   more localized problem than can be solved by mechanisms local to the
   home network without involving the endpoints, as presented in [1].
   Moreover, it should be noted that a multi6 solution requires
   upgrading both nodes of the communication to be supported, so its
   deployment will take some time, while the localized approach only
   requires support from HA(s) and MR(s) which makes its deployment
   simpler.

3.2  The (*,1,N) cases

   In this case, there are one or more MRs, one HA and multiple
   prefixes.  Since there is only one HA, this means that there is only
   one home network, so the presence of multiple prefixes means that
   probably the home network itself is multihomed to multiple ISP, each



Bagnulo                   Expires May 21, 2005                  [Page 6]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


   one of which has delegated one prefix to the home network, therefore
   to the nemo.  In this case, MNN will need to support multi6 to
   benefit from the multihoming capabilities of the home network.  The
   question is if this is enough to support the nemo multihoming, i.e.
   the multiple paths between the HA and the MR(s).  It is clear that by
   default, the HA and the MR(s) should be able to route packets coming
   from and going to any of the prefixes available in the home network.
   This means that naturally, the selection of the prefix used will not
   determine the path between the MR(s) and HA used to route the packet.
   This basically means that multi6 does not provides nemo multihoming
   by default (i.e.  without additional considerations)

   It would be possible to associate each of the different prefixes to a
   different path between the nemo and the home network.  This however,
   is not such a good idea, since the fault tolerance capabilities of
   the resulting solution would be reduced, since a given MNP will only
   reachable if the corresponding ISP of the home network is available
   and also the path between the home network and the nemo associated
   with the prefix is also available.

   In order to preserve the fault tolerance capabilities of the
   configuration, it is possible to create additional artificial
   prefixes for the nemo.  This means that per each prefix delegated by
   an ISP, one artificial MNPs has to be created and assigned to each
   available path between the nemo and its home network.  In this way,
   there will be one prefix per each combination of ISP/home
   network-nemo path, so that changing the MNP used will imply changing
   any part of the path.  In such configuration, the multi6 solution can
   be used to provide full multihoming support for the nemo.  The
   drawbacks of this configuration are similar to the ones discussed in
   the previous section: the expected time of deployment and the
   additional complexity imposed by this solution.  It should be noted
   that in this case, the MNN will need to implement multi6 anyway, in
   order to benefit from the multihoming capabilities of the home
   network.  Ubiquity support capabilities provided by the multiple
   paths between home network and the nemo seem important enough to
   justify specific mechanisms that are easier to deploy, like the one
   presented in [1].  In other words, the usage of local mechanisms that
   only involve the MR(s) and the HA can be justified because the
   ubiquity support that they provide without imposing wide scale
   deployment effort (as the one imposed by a multi6 solution)

3.3  The (*,N,N) cases

   In this case we have one or more MRs, multiple HAs and multiple MNPs.

   In order to analyze these cases, we need to introduce an additional
   classification of the configurations.  We will divide the cases



Bagnulo                   Expires May 21, 2005                  [Page 7]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


   depending on the location of the HAs.  The first group contains the
   configurations where all the HAs are located in the same home network
   i.e.  all the HAs can route packets from and to all the MNPs.  The
   second group contains the configurations where each HA is located in
   a different home network i.e.  each HA receives only the packets
   addressed to a disjoint set of MNPs.  The third group is an hybrid of
   the the two first groups and it contains the configurations where
   there are multiple home networks, but some of them contain more than
   one HA.

   The first group present similar characteristics than the (*,1,N)
   cases studied earlier, since all the HAs can forward packets
   addressed to any of the MNPs.  Basically, the multiple HAs act a
   single HA distributed along the Home network.  So the same reasons
   apply on this case, with the additional configuration that a HA-HA
   protocol may be required to provide synchronization between the
   different HAs.

   The second group contain the configurations that are most similar to
   the multi6 scenario, since each home network act as ISP and each HA
   as an ISP's border router.  In this case, the selection of the MNP
   prefix used influences the HA (and the home network) used to route
   the packets.  It should be noted that it may be possible that one
   home network has delegated more than one MNP, so that changing
   between those MNP will not affect the HA used to exchange packets,
   but in any case, changing to the other prefixes will alter the path
   of the packets.  In addition, it should also be noted that it would
   be possible even in this case to use a local solution that only
   involves the HAs and the MRs.  However, since the different HAs are
   in different home networks, implying that they are likely in
   different administrative domains, it may not be simple to achieve the
   required cooperation between the different HAs.  So, in this case, it
   seems that a multi6 solution would provide the required features.

   The third group is an hybrid group, that contain a mix of the
   characteristics of the first two groups.  It is then possible to
   consider that a local mechanism can be used among the different HAs
   that are located within the same home network and that the multi6
   mechanism can be used to re-home communication between HAs that are
   located in different home networks.











Bagnulo                   Expires May 21, 2005                  [Page 8]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


4.  Summary

   The result of the analysis is that the only case that is susceptible
   to a direct application of the multi6 protocol is the (*,N,N) where
   the HAs are located in different home networks.  In the remaining it
   would be possible to use the multi6 solution to provide nemo
   multihoming support, but this imposes the creation of artificial MNP.
   Besides, in those cases, it seems possible to use a local mechanism
   [1] that only involves the HAs and the MRs to obtain similar
   benefits.  The major benefit of such approach is that the reduced
   deployment effort, which would result in a faster adoption.








































Bagnulo                   Expires May 21, 2005                  [Page 9]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


5.  Security considerations

   TBD

6  Informative References

   [1]  Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in
        Network Mobility Support", draft-ietf-nemo-multihoming-issues-01
        (work in progress), October 2004.


Author's Address

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   EMail: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es





























Bagnulo                   Expires May 21, 2005                 [Page 10]


Internet-Draft    Application of a multi6 protocol to nemo November 2004


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 (2004).  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.




Bagnulo                   Expires May 21, 2005                 [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/