Mobile IP Working Group Hesham Soliman, Ericsson
INTERNET-DRAFT Karim El Malki, Ericsson
Expires: January 2003 Claude Castelluccia, INRIA
July,2002
Per-flow movement in MIPv6
<draft-soliman-mobileip-flow-move-02.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
The aim of this draft is to introduce a new extension to MIPv6 to
allow hosts to direct inbound flows individually to certain preferred
interfaces. This extension to MIPv6 allows multi-homed hosts to take
full advantage of the diverse access technologies that they may be
connected to and direct their traffic according to internal policies
specified by the users or applications.
Soliman, ElMalki, Castelluccia [Page 1]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
1. Introduction
The current MIPv6 specification [MIPv6] allows a MN to manage its CoA
by sending BUs to its HA and other CNs when applicable. The semantics
of the BUs in MIPv6 are limited to host movement. I.e. The current
MIPv6 specification does not allow a MN to split its inbound
connections to different addresses. In this draft, the splitting of
inbound traffic to be received on different addresses is referred to
as `Per-flow movement'.
In the context of this proposal, a flow can be 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. Alternatively a flow can be identified in a simpler
manner using the flow label field in the IPv6 header [IPv6].
Per-flow movement can be a useful feature in cases where the MN is
connected to different access technologies with different
characteristics. When using the flow movement sub-options below, a MN
would be able to `move' one flow to another AR/interface while
maintaining the reception of other flows on the current interface.
requesting the flow movement can be decided based on some local
policies within the MN and based on the link characteristics and the
types of applications running at the time.
It should be noted that the flow movement sub-option can be
associated with any BU, whether it is sent to a CN, HA or MAP
[HMIPv6]. A Similar mechanism for Mobile IPv4 is described in
[FNS01].
2. Flow movement sub-option
The Flow movement sub-options are included within the BU and BA
options. The sub-options contain information that allows the receiver
of a BU to identify a traffic flow and route it to a given address.
Multiple sub-options may exist within a BU. These sub-options may
contain the same source IPv6 address or different addresses. Only one
source address is allowed in each sub-option. A traffic flow may be
identified by using the flow label in IPv6 or by combining the
source/destination addresses, transport protocol number and
source/destination port numbers.
Two different types of sub-options are defined in this memo, one
identifies a flow based on the source/destination addresses, protocol
number, source/destination port numbers quintuplet, and the other
identifies the connection based on the flow label combined with the
CN's source address.
Soliman, El-Malki, Castelluccia [Page 2]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
A MN can include several flow movement sub-options within the BU
option. For instance, an MN could move a number of connections to
another interface. In the absence of a defined mechanism for flow
label usage the MN would include a number of flow movement sub-
options, each identifying one connection based on the
source/destination addresses, source/destination port numbers and the
protocol number quintuplet.
It should be noted that per-packet load balancing has negative
impacts on TCP congestion avoidance mechanisms as it is desirable to
maintain order between packets belonging to the same TCP connection.
This behaviour is specified in [TRAFF]. Other negative impacts are
also foreseen for other types of real time connections due to the
potential variations in RTT between packets. Hence per-packet load
balancing is not allowed in this extension. However, the MN can still
request per-flow load balancing provided that the entire flow is
moved to the new address.
2.1 Sub-option format for flow classification based on port numbers
Figure 1 shows the sub-option format used when using the
addresses/protocol number/ port numbers quintuplet to classify a
flow. The MN's destination address, to which the flow is being moved,
is assumed to be the source address in the IP header. Hence, when
using this mechanism, the MN MUST use the appropriate source address
in the IP header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination port | Protocol num | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type TBD
Sub-Option Len Length of sub-option
Source port The port number for the CN
Soliman, El-Malki, Castelluccia [Page 3]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
Destination port The port number for the MN
Protocol num A 16-bit unsigned integer representing
value of the transport protocol number
associated with the port numbers.
Status An unsigned 8 bit integer indicating the
success or failure for this sub-option.
Values lower than 128 are reserved for
successful registrations. Failure
values are 128 and above. This field is
used to indicate the success or failure
of the operation when the sub-option is
part of the BA. It is also used in
the BU to indicate whether the sup-
option should be added to, or deleted
from, the binding cache. When set to
Zero, it indicates addition, and a value
Of 0xFF indicates a request for
deletion (deregistration).
The following values are reserved for the status field within the
flow movement sub-option:
0 Indicates a successful registration.
128 Flow movement rejected, reason unspecified.
129 Flow movement option poorly formed.
130 Flow identification by port numbers is not Supported.
Source Address A 128-bit field representing the source
Address of the CN.
The alignment requirement for this sub-option is 8n.
2.2 Sub-option format for flow classification based on the Flow label
Figure 2 shows the sub-option format for flow splitting based on the
Flow label and the source address. The MN MUST set the source address
as the source address of the correspondent's traffic flow which will
be moved. As mentioned above, the source address in the IP header of
the MN's BU is the destination address to which the flow is being
moved.
Soliman, El-Malki, Castelluccia [Page 4]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
0 1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow label | Status | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type TBD
Sub-Option Len Length of sub-option
Status An unsigned 8 bit integer indicating the
success or failure for this sub-option.
Values lower than 128 are reserved for
successful registrations. Failure
values are 128 and above. This field is
only used when the sub-option is part of
the BA to indicate the operation's
success or failure. It is also used in
the BU to indicate whether the sup-
option should be added to, or deleted
from, the binding cache. When set to
Zero, it indicates addition, and a value
Of 0xFF indicates a request for
deletion (deregistration).
The following values are reserved for the status field within the
flow movement sub-option:
0 Indicates a successful registration.
128 Flow movement rejected, reason unspecified.
129 Flow movement option poorly formed.
130 Flow identification by flow label is not Supported.
Res A 4-bit reserved field, MUST be set to
Zero
Source Address A 128-bit field representing the source
Address of the CN.
Soliman, El-Malki, Castelluccia [Page 5]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
3. Sending rules for the MN
For this mechanism to be useful, the MN MUST ensure that the
appropriate Source address (for the CN) is used in the sub-option.
This is clear when sending the BU directly to the CN, as both ends
possess the necessary information required to identify the
connection.
However, when the BU is sent to an intermediate router, like the HA
or MAP, careful selection of the CN's source address is required. The
reason for this is that the CN may also be a MN. The remaining part
of this section will consider the case where the MN is sending BUs to
an intermediate router, like a HA or MAP.
If packets sent by the CN to the MN do not contain a Home Address
option (i.e. CN is not a MN), the source address in the flow movement
sub-option MUST be the address of the CN. This implies that the
source address field in the flow-movement sub-option is the same
address that the MN uses as part of the quintuple identifying the
connection (i.e. the destination address for the connection, seen by
the MN).
However, if the CN has sent a BU to the MN and packets sent by the CN
to the MN contain a Home Address option (i.e. the CN is itself a MN),
two cases need to be considered:
1) The CN sends data packets to the MN using its CoA as the source
address
2) The CN sends data packets to the MN using a source address other
than its CoA sent to the MN in the BU (i.e. the CN is using an
alternate-CoA )
In both cases the MN MUST use the source address of packets it
receives from the CN as the source address field in the Flow-movement
sub-option. For case 2) above, the MN MUST store the source address
as well as the CoA in the alternate-CoA sub-option when receiving a
BU from the CN. Further explanation is in Appendix A.
4. Deregistering the Flow-movement sub-option
A MN may, at some point in time, decide to deregister the Flow-
movement sub-option due to connection termination or a change in its
IP layer access point. This can be achieved by resending the BU with
the Flow movement sub-option status field set to 0xFF.
5. Acknowledging the Flow movement sub-option
The receiver of the Flow movement sub-option MUST acknowledge it in a
way that allows the sender to maintain the sub-option in its BU list.
Soliman, El-Malki, Castelluccia [Page 6]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
If one or more sub-options are accepted, the CN MUST include all the
sub-options with the appropriate Status values in the BA.
The acceptance of each flow movement sub-option is independent from
the acceptance of the CoA in the BU option as well as other sub-
options. In other words, the acceptance of the new CoA in a BU does
not imply an acceptance of every flow movement sub-option. Hence, the
receiver of the BU MUST include all the flow movement sub-options in
the BA with an appropriate status value to indicate the acceptance or
rejection of each one. This will ensure consistency in the Binding
Cache of the receiver and the BU list of the sender.
5.1 Additional Binding Acknowledgement status values
A new BA status value is introduced to support the flow movement
feature. The new value is shown below:
1 Binding Update accepted, flow movement is not supported.
This implies the rejection of all the Flow-movement sub-options. If
this code is used, the CN SHOULD NOT include any of the Flow-movement
sub-options in the reply.
6. Notice regarding Intellectual Property Rights
see http://www.ietf.org/ietf/IPR/ERICSSON-General
7. Acknowledgements
A Special acknowledgement goes to Wolfgang Hansmann for his careful
reviews and suggestions to improve this draft. Thanks to Conny
Larsson for his review of the draft and helpful comments, and to:
Simon Aladdin, Tomas Goransson as well as other members of the DRiVE
project for their useful input towards this draft.
8. References
[FNS01] X.Zhao, C.Castelluccia and M.Baker. "Flexible Network
Support for Mobile Hosts", ACM MONET, April 2001.
[HMIPv6] H. Soliman, C. Castelluccia, K. ElMalki and L. Bellier
"Hierarchical MIPv6 mobility management".
draft-ietf-mobileip-hmipv6-06.txt
[MIPv6] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-13.txt, February 2000.
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6)
specification". RFC 2460.
Soliman, El-Malki, Castelluccia [Page 7]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
[TRAFF] D. Awduche et al, "Requirements for traffic engineering over
MPLS". RFC 2702.
9. Authors' addresses
Hesham Soliman
Ericsson Radio Systems, AB.
Torshamnsgatan 23,
Kista, Stockhom,
SWEDEN
Phone: +46 8 4046619
Fax: +46 8 4047020
E-mail: Hesham.Soliman@era.ericsson.se
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
Claude Castelluccia
INRIA /Planete
ZIRST- 655 Avenue de l'Europe
38334 Saint Ismier Cedex
France
Soliman, El-Malki, Castelluccia [Page 8]
INTERNET-DRAFT Per-flow movement in MIPv6 July,2002
APPENDIX A - Choosing the right address in the source address field
of the sub-option, when sending it to the HA/MAP.
This appendix clarifies the reasons behind the selection of the CN
source address when sending the flow-movement sub-option to the
HA/MAP.
Two cases are considered below.
A.1 Case A: The CN's CoA is obtained from the source address in the IP
header containing the BU
In this case, the MN would store the CoA received in its binding
cache as specified by [MIPv6]. When sending a BU to the HA/MAP,
containing a Flow-movement sub-option, the CoA stored in the Binding
Cache MUST be used in the source address field within the Flow-
movement sub-option.
A.2 Case B: The CN's CoA is obtained from the alternate-CoA sub-option
In this case, the MN MUST use the source address included in the IP
header, when receiving BUs from the CN.
This memo assumes that the alternate-CoA included in the BU is an
RCoA, since, so far, this has been the only specified use for an
alternate-CoA sub-option. However, it may be useful to have an
explicit indication in the BU to indicate whether the alternate-CoA
is in fact an RCoA. Future revisions of [HMIPv6] should consider
adding such explicit indication in the BU (e.g. a new flag).
Based on the assumption that an alternate-CoA represents the RCoA for
the CN, upon reception of a BU, the MN MUST store the source address
field, as well as, the CoA in the alternate-CoA sub-option.
When sending the Flow-movement sub-option to the HA/MAP,
Soliman, El-Malki, Castelluccia [Page 9]