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]