Monami6 Working Group C. Park Internet-Draft N. Choi Expires: January 8, 2008 J. Ryu T. Kwon Seoul National University E. Paik KT July 7, 2007 Interface selection for a multihomed mobile router draft-park-mis-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 January 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract In this draft, we discuss how to make use of multiple interfaces in a single mobile router. We will focus on the scenario in which each interface is attached to different access network. Especially, we propose how a mobile router selects proper interfaces to provide Park, et al. Expires January 8, 2008 [Page 1] Internet-Draft Multiple interface selection July 2007 services to different traffic flows. We suggest a new option carried in IPv6 hop-by-hop options header to maintain and advertise the flow requirment and characteristics. New option contains a service type value and a preference value. A servie type value is used for traffic classification, and a preference value enables mobile router to control the traffic in detail. The propsed multiple interface selection mechanism in a multihomed mobile router (MMR) chooses an appropriate interface for each flow, depending on traffic requirements and access network characteristics. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Policy Format . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Multiple Interface Selection Protocol Operation . . . . . . . 6 4.1. Flowbase Searching . . . . . . . . . . . . . . . . . . . . 6 4.2. Multiple Interface Selection . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Traffic Classification . . . . . . . . . . . . . . . 9 Appendix B. Case Study . . . . . . . . . . . . . . . . . . . . . 9 B.1. Maximize Throughput . . . . . . . . . . . . . . . . . . . 10 B.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 10 B.3. QoS Support with Load Balancing . . . . . . . . . . . . . 10 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Park, et al. Expires January 8, 2008 [Page 2] Internet-Draft Multiple interface selection July 2007 1. Introduction Every access network has its own characteristics, like QoS support, bandwidth, charging policy, etc. Such various network characteristics can provide a wide sprectrum of network services to users. A multihomed mobile router(MMR) has multiple kinds of wireless interfaces, each of which is attached to different access networks. We focus on the way how to select an interface to forward the traffic to exploit the various characteristics of wireless network. So each traffic flow would specify its requirements such as QoS level, latency, etc. In this way, users can be provided differentiated and customized services. And network operators can control MMR in detail with policies. The requirement of each flow can be included in the IPv6 hop-by-hop options header[2]. We suggest a new option that contains two values, a service type value and a preference value. The classified flow will be forwarded to an appropriate access network, which is determined by the multiple interface selection mechanism that orders several access networks depending on the flow requirements and predefined policies. The flow information and forwarding interface information will be stored in a flowbase, so that the subsequent packets in the same flow will be forwarded directly without any repeating steps. 2. Terminology Flow A flow is a sequence of packets sent from a particular source to a particular unicast/anycast/multicast destination that the source desires to label. Flowbase A flowbase keeps information about all flows through MMR. Each flowbase tuple consists of a source address, a destination address and a forwarding interface for each packet to be forwarded by the multihomed mobile router. Multihomed mobile router Park, et al. Expires January 8, 2008 [Page 3] Internet-Draft Multiple interface selection July 2007 A multihomed mobile router (MMR) is a mobile router that has two or more interfaces, each of which provides connectivity to different access network. Metric vector A metric vector is a vector which contains normalized values of traffic characteristics. Metric function A metric function computes a single metric value by inner- producting two metric vectors. Policy A policy is a set of rules that determines what a metric vector looks like. 3. Policy Format To indicate the preference of interface selection, Traffic Control Option is suggested to be carried in the IPv6 hop-by-hop options 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt.Value Len.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service type | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Traffic control option Option type Option type value will have value 001xxxxx, of which the 5 lowest bits will be assigned by IANA. Option value length = 3 Park, et al. Expires January 8, 2008 [Page 4] Internet-Draft Multiple interface selection July 2007 The traffic control option requires 3 octets, except option type field and option length field. Service type The 8-bit service type field in the traffic control option will carry the value which represents the traffic class of the packet. A service type value and and its matching traffic class are described below: 0 : The packet belongs to data traffic 1 : The packet belongs to control messages 2 : The packet belongs to VoIP traffic 3 : The packet belongs to Video traffic 4 ~ 255 : Reserved The service type value is assumed to be passed from the application. Preference The preference value is assumed to be passed from the application, just like the service type value. An application sets the preference value to represent the service preference that the application requires. The value determines what the metric vector looks like. Surely, a MMR should keep a set of predefined policies in its non-volatile storage, that matches preference values. Hereby we illustrate some example values for how the preference values can be used: 0 : No policy 1 : Maximize throughput 2 : Support QoS 3 : Perform load balancing 4 - 65535 : Reserved Park, et al. Expires January 8, 2008 [Page 5] Internet-Draft Multiple interface selection July 2007 4. Multiple Interface Selection Protocol Operation The general framework for multiple interface selection is as shown in Figure 2. Multiple Interface Selection is composed of two steps: Flowbase searching step and Interface selection step. | packet | v +-----------------+---------------+ | | | | v | | +---------+----------+ | | +---+ Flowbase searching | | | | +---------+----------+ | | | v | | | +----------+-----------+ | | | | Interface Selection + | | v +----------+-----------+ | | | | | | | | | | +--------->---+ | | | | +-----------------+---------------+ | | interface v Figure 2. Multiple interface selection framework 4.1. Flowbase Searching A flowbase tuple consists of packet flow information, specifically, source/destination address and port. Additional to those information, a flowbase tuple should keep the interface to which network the framework had forwarded the packet. When a packet from a mobile node attached to a MMR arrives at the MMR, MIS framework should extract source/destination address and port information from the packet. These information are compared to the flowbase tuples. When any tuple that matches those information found, then the framework will forward the packet directly to the network which had been selected. Hashing can be used to implement the flowbase, to reduce searching time for matching flowbase tuple. If any matching tuple are not found, the packet will move on to interface selection step. Park, et al. Expires January 8, 2008 [Page 6] Internet-Draft Multiple interface selection July 2007 4.2. Multiple Interface Selection In interface selection step, multiple interface selection (MIS) mechanism for outgoing traffic will be executed. The mechanism need to compare the characteristics of an access network, like traffic amount, bandwidth, etc. to the requirments of the traffic. The parameters are to be assumed that they are already known to the MIS framework in the heuristic way. Based on the information, MIS mechanism can select an appropriate outgoing interface (and access network which connected to) that satisfies the flow's requirement. As a packet arrives at interface selection step, MIS mechanism looks at the traffic class information and the preference value of the packet from the traffic control option in IPv6 hop-by-hop options header. Based on the information, a metric function will be generated. And then MIS will compute a single metric value from the function to choose the best interface to service the packet. Then MIS can select a proper access network and interface to transmit the packet through, and the packet will be forwarded to the selected access network. Note that if the traffic class field in the IPv6 main header has some meaningful value, then the MIS will take it into account when it selects an appropriate metric function. The metric function should make a metric value from two vectors: an access network characteristic vetcor and a traffic flow requirement vector. MIS should compute metric value for every access networks as the first packet of a flow enters MIS. For example, the metric function will look like this: F = V_n X V_t The metric function computes an inner product of two vectors. V_n is a subset of access network characteristics, and V_t is a subset of traffic flow requirements. Some elements of a vector should be normalized between 0 and 1, because what the metric function has to do is to make a relative ordering among the access networks, not to make absolute preference values for the access networks. And the other elements would have a binary value indicating whether the network satisfies a condition or not. The details of a metric function can be various due to policies, so we do not describe the details of a metric function. Instead, we'll show a situation with some particular policies in Sec. 5. Some example characteristics of the access networks and their interface are listed as follows. Some of them are quoted from [3]. Park, et al. Expires January 8, 2008 [Page 7] Internet-Draft Multiple interface selection July 2007 Queueing delay A mean queueing delay in the interface. Loss rate A mean packet loss rate in the access network. Jitter The variation in latency. Bandwidth Maximum bandwidth provided by the access network. QoS support Whether the QoS is supported by the access network or not. Security support Whether the security protection is supported by the access network or not. Power consumption Some particular MMR may not be mains-powered. Power consumption of interface would be a metric for choosing access network. Charging policy A network provider has many charging policies for customers, like a flat rate or a meter rate. 5. Security Considerations We do not consider any security issues in this draft. 6. References [1] Seitz, N., "A Basis for IP Network QoS Control and Traffic Management", ITU-T Recommendations Y.1541, October 2003. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Park, et al. Expires January 8, 2008 [Page 8] Internet-Draft Multiple interface selection July 2007 [3] Microsoft, "What is QoS?", Windows Server Techcenter QoS Technical Reference, March 2003. Appendix A. Traffic Classification ITU presented a guidance of traffic classification in [1]. And we modified the traffic classification into 4 classes of traffic. Here is the description about each traffic class. VoIP traffic VoIP traffic is for transmission of voice call over IP. VoIP traffic consists of same small size packets, and it is delay- sensitive. So VoIP traffic should be able to be serviced with small latency, small jitter, or large bandwidth. Video traffic Like VoIP traffic, video traffic is also delay-sensitive. And video traffic packets are VBR in nature. Large bandwidth would be helpful for transmitting video traffic. Data The other packets for user applications are classified into this class. Data traffic is typically insensitive of QoS parameters such as latency, jitter. Data traffic even does not need to be guaranteed to get a certain level of bandwidth. Control Small packet size, delay-sensitive control traffic is used for IP- level control message, such as ICMPv6 message. Control traffic does not need large bandwidth, nor high-level QoS suppport. Appendix B. Case Study Hereby we describe some examples of policies and metric vectors for a metric function that corresponds a preference value. Metric vectors, preference values and all the other required parameters are assumed to be set in MIS framework a priori. The parameter values can be predetermined in a heuristic way, by network service providers or operators. Park, et al. Expires January 8, 2008 [Page 9] Internet-Draft Multiple interface selection July 2007 B.1. Maximize Throughput V_n = ( Bandwidth, Loss rate ) V_t = ( PacketSize, v ) In this case, let us assume that the throughput means the "goodput". So if we want to maximize the gootput, a packet loss should be considered. And the bandwidth is properly provided according to the mean packet size of the traffic. The variable v is a coordination value about the effect of packet loss factor in maximizing goodput. And the parameter "PacketSize" will have a value by a rule, for example: 0.1 for Control message 0.5 for VoIP traffic 1.0 for Video/Data traffic B.2. Load Balancing V_n = ( Queueing delay ) V_t = ( 1 ) In this case, only the load of each interface is considered. So only the queueing delay of each interface is considered, and the traffic flow parameter is ignored. B.3. QoS Support with Load Balancing V_n = ( QoS support, Queueing delay ) V_t = ( Service type, 1 ) The QoS support parameter represents whether an access network support QoS by nature or not. So basically it can have only the binary value 1 or 0, and if there are many networks support QoS in various level, the parameter can have a value between 1 and 0. The service type parameter represents whether the traffic should be served QoS support. So, it will have a value of 1 for the QoS-needed traffic, and 0 for the other traffic. For example, the rules for the metric value will look like this: Park, et al. Expires January 8, 2008 [Page 10] Internet-Draft Multiple interface selection July 2007 0 for control message and data packets 1 for video and VoIP traffic Like case 5.2, the queueing delay parameter will be used alone for load balancing without the traffic flow requirement parameter. Appendix C. Change Log Changes from draft-park-mis-01 to draft-park-mis-02: * Section 3 Moved to Appendix A * Section 5 Moved to Appendix B * Removed Section 6 * Modified some expressions Changes from draft-park-mis-00 to draft-park-mis-01: * Modifications to Section 2: - Removed flow label term + Modified some expresions * Modifications to Section 2: - Removed Section 4.1 Flow label term + The framework picture has been simplified + Description about traffic class and preference has been moved * Added new Section 6 Implementation Park, et al. Expires January 8, 2008 [Page 11] Internet-Draft Multiple interface selection July 2007 Authors' Addresses Chulhyun Park Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-876-7170 Fax: +82-2-876-7170 Email: chpark@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~chpark/ Nakjung Choi Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-876-7170 Fax: +82-2-876-7170 Email: fomula@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~fomula/ Jiho Ryu Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-876-7170 Fax: +82-2-876-7170 Email: jhryu@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~jhryu/ Park, et al. Expires January 8, 2008 [Page 12] Internet-Draft Multiple interface selection July 2007 Taekyoung Kwon Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9105 Fax: +82-2-872-2045 Email: tk@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~tk/ Eunkyoung Paik KT Future Technology Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5759 Email: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/ Park, et al. Expires January 8, 2008 [Page 13] Internet-Draft Multiple interface selection July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Park, et al. Expires January 8, 2008 [Page 14]