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 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]