One document matched: draft-jaehwoon-netext-flowmob-01.txt
Differences from draft-jaehwoon-netext-flowmob-00.txt
netext Working Group Jaehwoon Lee
Internet-Draft Dongguk University
Intended status: Informational Yoonyoung An
Expires: August 27, 2011 Byungjun Ahn
ETRI
Febraury 28, 2011
Flow-based mobility support in Proxy Mobile IPv6
draft-jaehwoon-netext-flowmob-01.txt
Abstract
IN Proxy Mobile IPv6 (PMIPv6), a multi-homed MN can connect to the
PMIPv6 domain by using only one interface even though it has multiple
interfaces. It would be efficient when such a multi-homed MN connect
to the PMIPv6 domain by using all of its interfaces. If such a
multi-homed MN utilizes all of its interfaces, flow mobility can
be provided that the MN handovers one or more flows from one
interface to another without re-establishing sessions. This document
specifies the layer-3 based flow mobility mechanism by considering
the intention of the MN. Here, a MN chooses the interface for sending
the service traffic and transmits the traffic by using the chosen
interface. The PMIPv6 domain can know the intention of the MN when a
MAG receives a service flow via a specific network.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 27, 2011.
Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 1]
Internet-Draft Flow-based mobility support Feb. 28, 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................4
3. Protocol operation............................................4
4. Security Considerations.......................................6
5. IANA Considerations...........................................6
References.......................................................7
Author's Addresses...............................................7
Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 2]
Internet-Draft Flow-based mobility support Feb. 28, 2011
1. Introduction
The Proxy Mobile IPv6 (PMIPv6) is considered as the network-based
mobility management mechanism that the access network within the
PMIPv6 domain supports the mobility of the mobile node (MN) on
behalf of the MN itself [1]. In PMIPv6, the Mobile Access Gateway
(MAG) is defined to support the mobility of an MN. The MAG acts as
the default gateway of the access link to which an MN is connected.
Also, the Localized Mobility Anchor (LMA) is defined as the Home
Agent within the PMIPv6 domain.
In PMIPv6, a multi-homed MN can connect to the PMIPv6 domain by using
only one interface even though it has multiple interfaces. It would
be efficient when such a multi-homed MN can connect to the PMIPv6
domain by using all of its interfaces. If such a multi-homed MN can
utilize all of its interfaces, flow mobility can be provided that the
MN handovers one or more flows from one interface to another without
re-establishing session.
However, as described before, the PMIPv6 is the network-based
mobility management protocol, and PMIPv6 domain cannot know the
intention of the MN. Therefore, it does not reflect the intention
of the MN for the PMIPv6 domain to statically assign the interface
for a specific flow. For example, assume that a MN connects both to
3GPP network via an interface and Wireless LAN via another interface
and exchange the VoIP traffic with the host resided in the Internet.
Then some users prefer to utilize the 3GPP network that satisfies
the QoS requirement of the VoIP traffic. On the other hand, other
users prefer to utilize the Wireless LAN due to its high speed and
low cost.
This document specifies the layer-3 based flow mobility mechanism by
considering the intention of the MN. In this document, the service
flow is defined by using the 5-tuple composed of source IP address,
destination IP address, protocol ID of the transport layer protocol,
source port number and destination port number. Here, a MN chooses
the interface for sending the service traffic and transmits the
traffic by using the chosen interface. The PMIPv6 domain can know the
intention of the MN when a MAG receives a service flow via a specific
network.
Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 3]
Internet-Draft Flow-based mobility support Feb. 28, 2011
2. Terminology
Flow Mapping Table Entry (FMTE)
The entry that support the flow handover. The 5-tuple information
identifying the service flow is included in the entry. The tunnel
end-point address for the service flow is also included.
Service Flow (SF)
The flow that is exchanged between two end hosts. The SF is
identified by using the 5-tuple information including source IP
address, destination IP address, protocol ID of the transport
layer protocol, source port number and destination port number.
3. Protocol Operation
MN-IF1 MN-IF2 MAG1 MAG2 LMA (Internet) CN
| | | | | |
|----------------->| | | |
| L2 attachment |---------- PBU ------------>| |
| | |<------ PBAck(HNP1) --------| |
|<--- RA(HNP1) ----| | |
| | | | |
(Configure HoA1 to IF1) | | | |
|<~~~~~~~~~~~~~~~~>|<~~~~~~~~~~ SF ~~~~~~~~~~~~>|<~~~~~~~~~~~>|
| |----------------->| | |
| | L2 Attachment |------ PBU ------>| |
| | | |<-----------------| |
| |<-----------------| PBAck(HNP2,HNP1) | |
| | RA(HNP2,HNP1) | | |
| (Configure HoA2 to IF2) | | |
| | |<---------------------------| |
|<-----------------| PBAck(HNP1,HNP2) | |
| RA(HNP1,HNP2) | | | |
(To activate logical interface | | |
and assign VLL-ID and IP| | | |
address(MN-HoA1) to logical | | |
interface) | | | | |
|----------------->| | | |
|NA(MN-HoA1,VLL-ID)| | | |
|--------------------------->| | |
| NA(MN-HoA1,VLL-ID) | | |
(Flow mobility from IF1 to IF2) | | |
| |~~~~~~ SF ~~~~~~~>| | |
| | | |~~~~~~ SF ~~~~~~~>| |
| | | | (create FMTE) |
| | | | |~~~~ SF ~~~~>|
| |<~~~~~ SF ~~~~~~~>|<~~~~~ SF ~~~~~~~>|<~~~ SF ~~~~>|
Figure 1: Message exchange scenario
Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 4]
Internet-Draft Flow-based mobility support Feb. 28, 2011
In this document, MN is assumed to follow the weak host model [2].
Figure 1 shows the message exchange scenario considered in this
document. It is assumed that a MN is equipped with two interfaces
and can simultaneouly connect to two access networks each having
different access technology within the PMIPv6 domain. In reality,
the MN can be equipped with N interfaces.
When a MN enters a PMIPv6 domain and connects to a MAG (say, MAG1)
with one of its interfaces (say, IF1), MAG1 transmits the Proxy
Binding Update (PBU) message having the MN-ID to LMA as described
in the PMIPv6 protocol. LMA assigns a network prefix (say, HNP1)
for the MN and creates the binding cache entry for the MN. The
HNP1 and Proxy-CoA1 information is included in the binding cache
entry, where the Proxy-CoA1 is the IP address of the MAG1. And then,
the LMA sends the Proxy Binding Acknowledgement (PBAck) message
having HNP1 to MAG1. MAG1 having received the PBAck message announces
the Router Advertisement (RA) message to the MN. The HNP1 information
is included in the RA message. MN assigns one IPv6 address
(say, MN-HoA1) that belongs to the HNP1. From now on, MN can
communicate with a host resided in the Internet. Assume that the MN
establishes a VoIP session with a correspondent node (CN) in the
Internet by using the IF1 and exchanges the service flow (SF).
The SF can be classified with 5-tuple information having MN-HoA1,
the IP address of CN, protocol ID of the transport layer protocol,
source port number and destination port number. While exchanging SF
by using IF1, if the MN connects to another MAG (say, MAG2) within
the same PMIPv6 domain by using another interface (say, IF2), MAG2
sends the PBU message having the MN-ID to the LMA. The LMA checks
if there exists the binding cache entry for the MN. If it exists,
the LMA checks the access technology type (ATT) that is included in
the PBU message. If the value of the ATT is different, the LMA
considers that the MN wants to connect to the PMIPv6 domain by using
both two interfaces (by using two different networks). The LMA
assigns another network prefix (say, HNP2) for the MN and adds
HNP2 and Proxy-CoA2 information in the binding cache entry for the MN
where Proxy-CoA2 is the IP address of the MAG2. And then, the LMA
sends the PBAck message having HNP2 and HNP1 to MAG2. The LMA also
sends the PBAck message having HNP1 and HNP2 to MAG1.
MAG2 having received the PBAck message can know that the MN wants to
connect to the PMIPv6 domain via multiple access networks by using
the number of network prefixes within the message. MAG2 transmits the
RA message having HNP2 and HNP1 to the MN. MAG1 having received the
PBAck message can also konw that the MN wants to connect to the
PMIPv6 domain via multiple access networks by using the number of
network prefixes within the message. MAG1 transmits the RA message
having HNP1 and HNP2 to the MN.
Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 5]
Internet-Draft Flow-based mobility support Feb. 28, 2011
The MN having received RA messages having the identical network
prefixes from two different network interfaces knows that a
multi-homed connection is established between itself and the PMIPv6
domain. The MN activates the logical interface and configures one of
the IPv6 address belonging to HNP1 or HNP2 to the logical interface.
Here, how the MN decides which network prefix to choose among HNP1
and HNP2 is out of scope of this document. One method is to use the
IP address assigned to the first interface that the MN connects to
the PMIPv6 domain. In this document, MN-HoA1 is assumed to be
configured to the logical interface. Moreover, the MN configures the
virtual link-layer identifier (VLL-ID) to the logical interface as
the layer two address. How VLL-ID is configured for the
logical interface is out of scope of this document. See [3] for
logical interface link layer configuration. Once the MN configures
the MN-HoA1 and VLL-ID to the logical interface, it broadcasts
the unsolicited Neighbor Advertisement (NA) message having MN-HoA1
and VLL-ID via both IF1 and IF2. MAG1 and MAG2 having received the
NA message store the MN-HoA1 and VLL-ID information in each of
their binding update list entries associated to the MN. From now on,
the MN can exchange traffic via any of two interfaces.
After having configured the IP address to the logical interface, if
the MN decides to handover the VoIP traffic exchanged with the CN
from IF1 to IF2, it transmits the traffic (that is, SF) via IF2. How
the MN decides to handover is out of scope of this document. The MAG2
having received the SF sends the SF to LMA via the tunnel
established between the LMA and the MAG2. The LMA having received the
SF identifies that the MN wants the flow handover for the flow.
The LMA creates the FMTE for the MN that includes 5-tuple information
for SF and the IP address of the MAG2 (that is, Proxy-CoA2). And
then the LMA transmits the SF to the CN. When the LMA receives the
SF transmitted by the CN, it checks the FMTE. If the LMA finds the
entry matching the same 5-tuple information with the SF, it transmits
the SF to the MAG2 via the tunnel. MAG2 also sends the SF to the MN.
4. Security Consideration
TBD.
5. IANA Considerations
TBD.
Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 6]
Internet-Draft Flow-based mobility support Feb. 28, 2011
References
[1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and
B. Patil, "Proxy Mobile IPv6", RFC 5213, Aug. 2008.
[2] R. Braden, "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, Oct. 1989.
[3] T. Melia and S. Gundavelli, "Logical Interface Support for
multi-mode IP hosts", draft-ietf-netext-interface-support-01
(work in progress), Oct. 2010.
Author's Addresses
Jaehwoon Lee
Dongguk University
26, 3-ga Pil-dong, Chung-gu
Seoul 100-715, KOREA
Email: jaehwoon@dongguk.edu
Yoon-Young An
Network Research Division, ETRI
Jeonmin-Dong, Yusung-Gu
Daejeon, Chungnam, Korea
Email: yyahn@etri.re.kr
Byung-Jun Ahn
Network Research Division, ETRI
Jeonmin-Dong, Yusung-Gu
Daejeon, Chungnam, Korea
Email: bjahn@etri.re.kr
Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:11 |