Internet DRAFT - draft-bagnulo-shim6-mip
draft-bagnulo-shim6-mip
Network Working Group M. Bagnulo
Internet-Draft UC3M
Expires: January 12, 2006 E. Nordmark
Sun Microsystems
July 11, 2005
SHIM - MIPv6 Interaction
draft-bagnulo-shim6-mip-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In this note, we explore the interaction between the SHIM protocol
and MIPv6 protocol, identifying potential benefits and difficulties.
The analysis will consider the two modes of operation of MIPv6: the
Bidirectional Tunnel (BT) mode where the communication is routed
through the Home Agent and the Route Optimization (RO) mode, where
the communication flows directly between the Correspondent node and
the mobile node.
Bagnulo & Nordmark Expires January 12, 2006 [Page 1]
Internet-Draft SHIM & MIP July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Bidirectional Tunnel (BT) Mode . . . . . . . . . . . . . . . . 4
2.1 Communication between the MN and the CN . . . . . . . . . 4
3. RO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security considerations . . . . . . . . . . . . . . . . . . . 7
5. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Bagnulo & Nordmark Expires January 12, 2006 [Page 2]
Internet-Draft SHIM & MIP July 2005
1. Introduction
SHIM [1] is a host-based mechanism to provide site-multihoming
support. In this note, we explore the interaction between the SHIM
protocol and MIPv6 protocol, identifying potential benefits and
difficulties.
The analysis contained in this document considers the most general
case of shim and MIPv6 interaction, where the mobile node has both
multiple Care-of-Addresses as well as multiple Home Addresses. The
MN can have multiple addresses for any number of reasons. For
example, the MN can have multiple CoAs due to the MN having multiple
interfaces (connecting to different providers), or the MN visiting a
link which has multiple address prefixes due to the visited site
being multihomed. Also, the MN can have multiple HoAs for different
reasons, including having a home link which has multiple address
prefixes due to being in a multihomed site, to having multiple,
independent Home Agents that each provide it with a Home Address.
Without loss of generality the analysis uses a single IP address for
the correspondent node.
The analysis will consider the two modes of operation of MIPv6: the
Bidirectional Tunnel (BT) mode where the communication is routed
through the Home Agent and the Route Optimization (RO) mode, where
the communication flows directly between the Correspondent Node and
the Mobile Node.
Bagnulo & Nordmark Expires January 12, 2006 [Page 3]
Internet-Draft SHIM & MIP July 2005
2. Bidirectional Tunnel (BT) Mode
2.1 Communication between the MN and the CN
In this case, we have a MN with multiple CoAs (CoA1,..., CoAj) and
multiple HoAs (HoA1,..., HoAm) communicating with a Cn with address
IPCN.
We assume that the SHIM is layered above MIPv6.
In this scenario, suppose that an application located above the SHIM
layer, establishes a communication using one of the available HoAs,
e.g. HoAl and the address of the CN, IPCN, as ULIDs. Because the
SHIM is located above MIPv6, packets will be tunneled through the HA,
i.e. packets will be encapsulated with an additional header that will
contain IPHA and CoAj as addresses.
At some point during the lifetime of the communication, a SHIM
context is established. Such context will contain:
o HoAl and IPCN as ULIDs
o HoA1,..., HoAm, as locator set for the MN. (Optionally, the MN
could choose not to provide the CoAs to the CN in the shim6
signaling.)
o IPCN as locator set for the CN
We will next consider the response in case of an outage:
Suppose that an outage occurs and the communication path becomes
unavailable. If there is an outage affecting the path between the CN
and the MN, then the SHIM layer will detect it, and will retry with
an alternative locator.
When an alternative HoA is used as alternative locator, packets will
be tunneled through the HA associated with the new HoA, and will be
received through the CoA associated with the new HoA. In case that
there is at least one HA and one CoA that are not affected by the
outage, the communication will be preserved. In this case, the
communication will still flow in BT mode, but it will be routed
through an alternative tunnel associated with the new HoA.
If an alternative CoA is used as alternative locator, then the
communication will run directly between the MN and the CN in a kind
of SHIM based RO mode, recovering from the outage. However, in this
case, care must be taken because the alternative CoA may become
unavailable after movement.
Bagnulo & Nordmark Expires January 12, 2006 [Page 4]
Internet-Draft SHIM & MIP July 2005
3. RO mode
We assume that the SHIM is layered above MIPv6.
In this case, we have a MN with multiple CoAs (CoA1,..., CoAj) and
multiple HoAs (HoA1,..., HoAm) communicating with a CN with address
IPCN.
Suppose that a communication is established between the MN and the CN
using HoAl and IPCN. In addition, through MIPv6 protocol, a Binding
Cache Entry (BCE) is created in the CN associating the HoAl with one
of the CoAs, CoAp. So, packets associated with the communication are
flowing directly between the CN and the MN carrying CoAp and IPCN in
the source and destination address fields.
Later on, at some point in time, a SHIM context is established
between the MN and the CN. In this case the SHIM context established
contain the following information:
o ULIDs: HoAl and IPCN
o Locator set for MN: HoA1,...,HoAm, CoA1,..., CoAj. (Optionally,
the MN could choose not to provide the CoAs to the CN in the shim6
signaling.)
o IPCN as locator set for the CN
We will next analyze how this configuration reacts to different
failure modes:
o The path between IPCN and CoAp fails. The SHIM will detect the
outage and will try with alternative locators available for the
ULIDs of the session. If an alternative HoA is used by the SHIM
as alternative locator, when the SHIM passes the packet with an
alternative HoA to the MIP layer, the MIP layer will route through
the corresponding CoA available in the BCE associated with the new
HoA, possibly falling back to BT mode but potentially recovering
the failure. If an alternative CoA is used by the SHIM as
alternative locator, the MIP layer wonOt affect the packet
carrying the alternative CoA, and packets will be routed directly
between the MN and the CN, in a kind of SHIM-based RO mode.
o The path between the MN and the CN through the HA fails. While
data traffic is not routed through the HA, HoTI/HoT packets are
exchanged through the HA. If the path between the MN and the CN
through the Ha fails, then HoTI/HoT exchange will fail. A few
minutes later, the corresponding BCE will expire, and the
communication will fallback to the BT mode through the HA.
Bagnulo & Nordmark Expires January 12, 2006 [Page 5]
Internet-Draft SHIM & MIP July 2005
However, because we are considering the case where the path
through the HA is down, the communication will fail. At this
point, the SHIM will detect the outage and use an alternative
locator pair. Analogously to the previous case, the SHIM can try
with an alternative CoA or an alternative HoA as alternative
locators for the communication. In any case, similar
considerations to the ones described above apply and the
communications will be restored, whether in BT mode (alternative
HoA) or in a SHIM-based RO mode (alternative CoA used).
In any case, the presented setup seems to allow the preservation of
the established communication through different failure modes. It
should be noted, that if CoAs are included as alternative locators
for the SHIM, those will be short lived locators, and they may become
unavailable sooner than the HoAs.
Bagnulo & Nordmark Expires January 12, 2006 [Page 6]
Internet-Draft SHIM & MIP July 2005
4. Security considerations
TBD
5. Normative References
[1] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
draft-ietf-shim6-l3shim-00 (work in progress), October 2004.
Authors' Addresses
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
Erik Normark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA
USA
Phone: +1 650 786 2921
Email: erik.nordmark@sun.com
Bagnulo & Nordmark Expires January 12, 2006 [Page 7]
Internet-Draft SHIM & MIP July 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.
Bagnulo & Nordmark Expires January 12, 2006 [Page 8]
