Network Working Group F. Xia
Internet-Draft Huawei Technologies
Expires: August 22, 2009 February 18, 2009
Flow Binding in Proxy Mobile IPv6
draft-xia-netext-flow-binding-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 22, 2009.
Copyright Notice
Copyright (c) 2009 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.
Xia Expires August 22, 2009 [Page 1]
Internet-Draft Flow Binding in PMIPv6 February 2009
Abstract
This document introduces extensions to Proxy Mobile IPv6 that allows
networks dynamically binding IP flows to different interfaces of a
mobile node.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 5
5. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . 7
6. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . 7
7. MN Operation . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Message formats . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Alternative Interface Indicator . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
12.2. Informative references . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Xia Expires August 22, 2009 [Page 2]
Internet-Draft Flow Binding in PMIPv6 February 2009
1. Introduction
Assume a mobile node equipped with two interfaces namely IF1(e.g.
3GPP) and IF2 (e.g WiFi), and IF1 is active while IF2 is not
activated. There are two flows running on IF1, that is, VoIP and
file downloading. At some time, e.g., the mobile node moves into a
WiFi hotspot, IF2 becomes active, and the file downloading flow is
then offloaded to IF2 while VoIP flow remains on IF1. When the
mobile node moves out of the hotspot, the file downloading flow is
moved back to IF1 again.
In this document, a flow is defined as one or more connections that
are identified by a flow identifier. A single connection is
typically identified by the source and destination IP addresses,
transport protocol number and the source and destination port
numbers.
[I-D.ietf-mext-flow-binding] allows a mobile node to bind a
particular flow to a care-of address without affecting other flows
using the same home address. Flow Identification option is defined
and included in Binding Update (BU) / Binding Acknowledgement(BA)
messages. However, the mechanism specified in the document can't be
directly applied to Proxy Mobile IPv6 in which the mobile node is not
involved in mobility management. A Mobile Access Gateway (MAG) is
then introduced to take on mobility management on behalf of the
mobile node.
This document introduces extensions to Proxy Mobile IPv6 that allows
networks dynamically binding IP flows to different interfaces of a
mobile node. In the aforementioned scenario, the IF1 attaches to a
mobile access gateway forwarding VoIP and file downloading flows at
the beginning. When the mobile node moves into a WiFi hotspot, IF2
becomes active and connects to another mobile access gateway which
then takes over file downloading flow. Based on operator policy or
the mobile node profile, the mobile access gateways may signal a
Local Mobility Anchor (LMA) to redirect flows from one to another.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology in this document is based on the definitions in
[RFC5213],in addition to the ones specified in this section.
Xia Expires August 22, 2009 [Page 3]
Internet-Draft Flow Binding in PMIPv6 February 2009
Serving Interface: a mobile node's interface on which some
application flows are running. Based on the MN's profile,
operator's policy, or other reasons, some of the flows are
supposed to be offloaded to the other interfaces of the mobile
node when they become available.
Target Interface: a mobile node's interface which is taking over
some application flows from a serving interface of the mobile
node.
Serving IP Address (SIP): an IPv4 or IPv6 address configured on a
serving interface.
Target IP Address (TIP): an IPv4 or IPv6 address configured on a
target interface.
Serving Mobile Access Gateway(SMAG): A mobile access gateway which a
serving interface attaches to.
Target Mobile Access Gateway(TMAG): A mobile access gateway which a
target interface attaches to.
3. Use Cases
Michael is using 3GPP access to different services with different
characteristics in terms of QoS requirements and bandwidth:
o a VoIP call.
o a non-conversational video streaming, e.g.IPTV.
o a p2p download.
When Michael gets into his home where WiFi access is available,
Michael prefers running the p2p download and IPTV through the WiFi
network, and leaving the VoIP call still on 3GPP networks.
At some time, Michael's device starts ftp file synchronization with a
backup server. Due to the synchronization, the WiFi access becomes
congested and the IPTV flow is then moved back to 3GPP access.
After a while, Michael moves out of his home and loses the WiFi
connectivity. Triggered by this event, all the IP flows through the
WiFi access need to be moved to the 3GPP access which is the only
access available.
Xia Expires August 22, 2009 [Page 4]
Internet-Draft Flow Binding in PMIPv6 February 2009
4. Protocol Operation
+--------+ +------+ +------+ +------+
| MN | | SMAG | | TMAG | | LMA |
+--------+ +------+ +------+ +------+
IF1 IF2 | | |
| | | | |
| 1 Attachment | | |
|<-------------->| 2 PBU&PBA |
| 3 Addr Cfg |<-------------------------->|
|<-------------->| | |
Running | | | |
Applications | | |
| | 4 Attachment/PBU&PBA/Addr Cfg |
| |<------------------------>|<----------->|
| | | 5 Notification Exchange |
| | |<-------------------------->|
| | | 6 PBU(Flow Binding) |
| | |--------------------------->|
| | | | 7 Request |
| | | |<------------|
| | | | 8 Ack |
| | | |------------>|
| | | 9 PBA(Flow Binding) |
| | |<---------------------------|
| | | | 10 Packets |
| | 11 Packets |<============|
| |<=========================| |
| | | | |
Figure 1: Protocol Operation
1. A mobile node has two interfaces, IF1 and IF2. At the
beginning, only IF1 is activated and attachment procedure is
triggered.
2. On receiving attachment signalling from the mobile node, a
mobile access gateway, herein acting as SMAG, sends a PBU to a
LMA. Access Technology Type Option is carried in PBU. The LMA
assigns a unique prefix for the mobile node through PBA message
to SMAG.
3. SMAG extracts the prefix, and advertises it to the mobile node
through Router Advertisement message. The mobile configure its
address, herein acting as a SIP, through stateless address
configuration procedure specified in [RFC4862]. Then, MN runs
applications using this address, such as, VoIP,IPTV, and p2p
Xia Expires August 22, 2009 [Page 5]
Internet-Draft Flow Binding in PMIPv6 February 2009
downloading.
4. When the mobile node moves into some other places where IF2 is
activated, the mobile node follows similar steps to 1,2,3 to
configure IP address for IF2, herein acting as TIP. According
to Proxy Mobile IPv6 specification [RFC5213], the SIP is
different from TIP.
5. The LMA notifies SMAG about IF2's presence through Generic
Signaling Request / Generic Signaling Acknowledgement message
exchanges specified in
[I-D.ietf-mext-generic-signaling-message]. Alternative
Interface Indicator option defined in Section 8.1 is included in
the message from the LMA to the SMAG. Through this message
exchange, the SMAG has an idea of availability of other
interfaces of the mobile node, and the address of the TMAG.
6. Based on the mobile node's profile, or operator's policy, the
SMAG decides to offload some traffic flows from IF1 to IF2.
SMAG then sends PBU with Flow Identification option defined in
[I-D.ietf-mext-flow-binding]. This message indicates the LMA to
change the direction of the requested flows from the SMAG to the
TMAG. The LMA makes a decision if offloading request is granted
or not. The LMA may decide based on local information, such as,
access technology types, bandwidth, service types, and so on.
The LMA may also inquire the TMAG through step 7 and 8 the
acceptability of the offloading request. Step 7 and 8 are
skipped if the LMA makes decision locally.
7. The LMA sends Generic Signaling Request message to the TMAG for
inquiring if the offloading is allowed. Flow Identification
option is included in the message.
8. The TMAG responses with Generic Signaling Acknowledgment
message. If the TMAG accepts the flows, the Status field of the
message SHOULD be set to 0, otherwise, the field is set to 130
which means insufficient resources.
9. The LMA sends a PBA to indicate the operation result of the flow
binding request.
10. All the offloaded packets with SIP as destination address are
encapsulated with an additional outer header which destination
address is TIP. Then the LMA processes the encapsulated packets
as specified in [RFC5213], that is, the LMA forwards the packet
through the bi-directional tunnel set up for IF2 of the mobile
node. The redirected packets from the LMA to the TMAG have have
two layer encapsulations.
11. The TMAG strips the outer layer encapsulation, and forwards the
packets to the mobile node's IF2. The mobile node strips
remaining encapsulation, and then processes the packets with SIP
as the destination address.
Xia Expires August 22, 2009 [Page 6]
Internet-Draft Flow Binding in PMIPv6 February 2009
5. MAG Operation
Flow binding is always initiated by a SMAG, that is, the SMAG wants
to offload its traffic flow to other MAGs. There are several reasons
triggering flow binding.
o The SMAG is notified by a LMA the availability of other MAGs which
the same mobile node currently attaches to.
o Congestion occurs in the SMAG which knows there are other MAGs
connecting to the same mobile node.
o The SMAG detects the serving interface of the mobile node is out
of service.
o ... ...
As to Flow Identification option used in this document, there are two
fields needing special consideration, that is, Flow ID(FID) and
Binding Identification number(BID). FID and BID are mainly defined
for mutiple-interfaced mobile nodes with Mobile IPv6 functionalities.
The BID is an identification number used to distinguish multiple
bindings registered by the mobile node. Each BID is generated and
managed by a mobile node in Mobile IPv6. In Proxy Mobile IPv6,
mobility management of mobile nodes with multiple interfaces is run
in different independent MAGs, and BID loses its meaning. The same
situation applies to FID. All BID and FID fields in Flow
Identification option SHOULD be set to 0.
6. LMA Operation
The LMA is the center of the flow binding processing. It has
following functionalities:
o Advertising the availability of a new interface of a mobile node.
When an interface of the mobile node becomes active, a
corresponding MAG SHOULD sends a PBU to the LMA. Triggered by the
PBU, the LMA then notifies all the other MAGs which the mobile is
attaching to. Generic Signalling Request with Access Technology
Type Option is used for this notification.
o Deciding if an offloading request is acceptable. On receiving PBU
from a SMAG with a flow binding request, the LMA makes a decision
based on operator's local policy, mobile node's preference,
bandwidth of the flow, and so on.
o Inquiring a TMAG for acceptability of the offloaded flows. If the
LMA can't decide if accepting offloading request, the LMA SHOULD
inquire other MAGs using Generic Signaling Request message.
o Encapsulating downstream packets. Packets destining serving IP
address SHOULD be encapsulated with an outer IP header which a
target IP address and the LMA are the destination and source
address respectively. The LMA then processes these encapsulated
packets as specified in [RFC5213].
Xia Expires August 22, 2009 [Page 7]
Internet-Draft Flow Binding in PMIPv6 February 2009
o Redirecting upstream packets. When the LMA receives packets
belonging to a offloaded flow from a serving MAG, the LMA forwards
the packets and the sends ICMP messages which destination address
is the target address of the mobile node. The ICMP message serves
as a notification so that the mobile node sends upstream packets
of the offloaded flow through the target interface. When the
target address is IPv4, the Type field of the ICMPv4 [RFC0792]
SHOULD be set 3 (Destination Unreachable Message), and Code field
SHOULD be set 5 (source route failed); When the target address is
IPv6, the Type field of the ICMPv6 [RFC4443] SHOULD be set to 1
(Destination Unreachable Message), and Code field SHOULD be set to
6 (Reject route to destination).
7. MN Operation
In this document, it is assumed that different interfaces are
assigned different prefixes, and the same interface is configured
with the same IP address even after resetting of the interface. Once
one interface becomes inactive, the software SHOULD map the address
to another interface, or to a virtual interface,so that ongoing
sessions with the address can survive. When the interface becomes
active again, and receive the same prefix from a LMA, the address
SHOULD be moved back to the interface.
However, the mechanism described in this document is also applicable
to the cast that different interfaces share an IP address. Thus,
only one layer encapsulation is needed when the LMA process packets.
When the mobile node receives a ICMP message from a target interface,
the mobile node SHOULD use the target interface to send packets
belonging to a flow which is described in the ICMP message.
8. Message formats
8.1. Alternative Interface Indicator
A new option, Alternative Interface Indicator, is defined for use in
Generic Signaling Request and Generic Signaling Acknowledgement
messages exchanged between a local mobility anchor and a mobile
access gateway. This option is used for advertising the availability
of a new interface of a mobile node.
Xia Expires August 22, 2009 [Page 8]
Internet-Draft Flow Binding in PMIPv6 February 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) | ATT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proxy CoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field
MUST be set to 6 if Proxy CoA is IPv4, or 18 if Proxy CoA is
IPv6.
Reserved (R)
This 8-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
Access Technology Type (ATT)
An 8-bit field that specifies the access technology through
which the mobile node is connected to the access link on the
mobile access gateway. This field has the same meaning as the
definition in Access Technology Type in RFC5213.
Proxy CoA
An IP address of a MAG to which a new interface is attaching.
9. Security Considerations
This specification allows a mobile access gateway to offload traffic
to other mobile access gateway. This mechanism facilitate a serving
mobile access gateway to launch DoS attacks to a target mobile access
gateway. However, a local mobility anchor finally decides
acceptability of an offloading request, as mitigates DoS attacks
threat.
Xia Expires August 22, 2009 [Page 9]
Internet-Draft Flow Binding in PMIPv6 February 2009
10. IANA considerations
A new mobile option, Alternative Interface Indicator, is defined.
Option type SHOULD be assigned by IANA.
11. Acknowledgements
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
12.2. Informative references
[I-D.ietf-mext-flow-binding]
Soliman, H., Montavont, N., Fikouras, N., and K.
Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic
Support", draft-ietf-mext-flow-binding-01 (work in
progress), February 2009.
[I-D.ietf-mext-generic-signaling-message]
Haley, B. and S. Gundavelli, "Mobile IPv6 Generic
Signaling Message",
draft-ietf-mext-generic-signaling-message-00 (work in
progress), August 2008.
Xia Expires August 22, 2009 [Page 10]
Internet-Draft Flow Binding in PMIPv6 February 2009
Author's Address
Frank Xia
Huawei Technologies
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Xia Expires August 22, 2009 [Page 11]