Mobile IP Working Group Hesham Soliman, Ericsson
INTERNET-DRAFT Karim ElMalki, Ericsson
Expires: Feruary 2002 Claude Castelluccia, INRIA
July, 2001
Per-flow movement in MIPv6
<draft-soliman-mobileip-flow-move-00.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 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 August, 2000
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. Ie. 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 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-option 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 suboption 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 suboption
The Flow movement suboption is included within the BU and BA options.
The suboption contains information that allows the receiver of a BU
to identify a traffic flow and route it to a given address. Multiple
suboptions may exist within a BU. These suboptions may contain the
same destination IPv6 address or different addresses. Only one
destination address is allowed in each suboption.
A traffic flow may be identified by using the flow label in IPv6 or
by combining the destination address, transport protocol number and
port number. The message format for the flow identification suboption
is shown below.
Soliman, El-Malki, Castelluccia [Page 2]
INTERNET-DRAFT Per-flow movement in MIPv6 August, 2000
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|P|D| Flow label | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination-port | Prot number | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type TBD
Sub-Option Len Length of suboption
F When set, indicates that the Flow label
MUST be used to identify a flow. It MUST
NOT be set when P is set.
P When set, indicates that the port number
and IP address MUST be used to identify
a flow. It MUST NOT be set when F is
set.
D When set the MN is requesting the
deletion of this suboption from the
Binding Cache of the receivnig node.
This flag MUST NOT be set if the F or P
flags are set.
Prot number A value corresponding to the transport
protocol number associated with the port
numbers.
This field is only relevant when the P
flag is set.
Status An 8 bit field indicating the success or
failure for this suboption. Values lower
Soliman, El-Malki, Castelluccia [Page 3]
INTERNET-DRAFT Per-flow movement in MIPv6 August, 2000
than 128 are reserved for successful
registrations. Failure values are 128
and above. This field is only used when
the suboption is part of the BA.
The following values are reserved for the status field within the
flow movement suboption:
0 Indicates a successful registration.
128 Flow movement rejected, reason unspecified.
130 Flow movement option poorly formed.
131 Flow movement rejected. Flow label capability not supported.
132 Flow identification by port numbers is not Supported.
The alignment requirement for this suboption is 8n+6.
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.
When requesting load balancing, the MN can set the `flow identifiers'
using the F (flow label) or P (address and port number) flags.
A MN can include several load balancing suboptions 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
suboptions, each identifying one connection.
The MN MUST NOT include conflicting flags in the suboption. Ie. the
MN MUST NOT set both the F and P flags in the same suboption.
3. Acknowledging the Flow movement suboption
The receiver of the Flow movement suboption MUST acknowledge it in a
way that allows the sender to maintain the suboption in its BU list.
The acceptance of each flow movement suboption is independent from
the acceptance of the CoA in the BU option as well as other
subtoptions. In other words, the acceptance of the new CoA in a BU
does not imply an acceptance of every flow movement suboption. Hence,
the receiver of the BU MUST include all the flow movement suboptions
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.
Soliman, El-Malki, Castelluccia [Page 4]
INTERNET-DRAFT Per-flow movement in MIPv6 August, 2000
3.1 Additional Binding Acknowledgement status values
A New BA status vaule will need to be introduced to support the flow
movement feature. The new value is shown below:
1 Binding Update accepted, flow movement is not supported.
4. Notice regarding Intellectual Property Rights
see http://www.ietf.org/ietf/IPR/ERICSSON-General
5. Acknowledgements
Thanks to Conny Larsson for his review of the draft and helpful
comments.
6. 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-03.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.
[TRAFF] D. Awduche et al, "Requirements for traffic engineering over
MPLS". RFC 2702.
6.Authors' addresses
Hesham Soliman
Ericsson Australia
61 Rigall St., Broadmeadows
Melbourne, Victoria 3047
AUSTRALIA
Phone: +61 3 93012049
Fax: +61 3 93014280
E-mail: Hesham.Soliman@ericsson.com.au
Karim El Malki
Ericsson Radio Systems AB
Soliman, El-Malki, Castelluccia [Page 5]
INTERNET-DRAFT Per-flow movement in MIPv6 August, 2000
Access Networks Research
SE-164 80 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
E-mail: Claude.Castelluccia@inrialpes.fr
Appendix A: Future additions
- Modification of the Binding Cache and Binding Update list
structures
- Additional notes on suboption processing.
Soliman, El-Malki, Castelluccia [Page 6]