Mobile IP Working Group Hesham Soliman, Ericsson INTERNET-DRAFT Karim El Malki, Ericsson Expires: May 2002 Claude Castelluccia, INRIA November, 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 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 November, 2001 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 November, 2001 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 November, 2001 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 November, 2001 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 November, 2001 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 November, 2001 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-05.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 November, 2001 [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 November, 2001 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]