Monami6 Working Group C. Park Internet-Draft N. Choi Expires: April 22, 2007 J. Ryu T. Kwon Seoul National University E. Paik KT Oct 19, 2006 Interface selection for a multihomed mobile network draft-park-mis-01.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 April 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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 April 22, 2007 [Page 1] Internet-Draft Multiple interface selection Oct 2006 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. Traffic classification . . . . . . . . . . . . . . . . . . . . 4 4. Multiple interface selection framework overview . . . . . . . 5 4.1. Flowbase searching . . . . . . . . . . . . . . . . . . . . 5 4.2. Traffic control option . . . . . . . . . . . . . . . . . . 6 4.3. Multiple interface selection . . . . . . . . . . . . . . . 7 5. Case study . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Maximize Throughput . . . . . . . . . . . . . . . . . . . 9 5.2. Load balancing . . . . . . . . . . . . . . . . . . . . . . 10 5.3. QoS support with load balancing . . . . . . . . . . . . . 10 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Machine setting . . . . . . . . . . . . . . . . . . . . . 10 6.2. Test sceanario . . . . . . . . . . . . . . . . . . . . . . 11 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Park, et al. Expires April 22, 2007 [Page 2] Internet-Draft Multiple interface selection Oct 2006 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 April 22, 2007 [Page 3] Internet-Draft Multiple interface selection Oct 2006 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. Traffic classification ITU presented a guidance of traffic classification in [1]. And we modified the traffic classification into has 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. Park, et al. Expires April 22, 2007 [Page 4] Internet-Draft Multiple interface selection Oct 2006 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. 4. Multiple interface selection framework overview Our general framework looks like this: | packet | v +-----------------+---------------+ | | | | v | | +---------+----------+ | | +---+ Flowbase searching | | | | +---------+----------+ | | | v | | | +----------+-----------+ | | | | Interface Selection + | | v +----------+-----------+ | | | | | | | | | | +--------->---+ | | | | +-----------------+---------------+ | | interface v Figure 1. 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 Park, et al. Expires April 22, 2007 [Page 5] Internet-Draft Multiple interface selection Oct 2006 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. 4.2. Traffic control option We suggest an option 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 2. 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 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 Park, et al. Expires April 22, 2007 [Page 6] Internet-Draft Multiple interface selection Oct 2006 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 4.3. 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 Park, et al. Expires April 22, 2007 [Page 7] Internet-Draft Multiple interface selection Oct 2006 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. We list some example characteristics of the access networks and their interface. Some of them are quoted from [3]. 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 Park, et al. Expires April 22, 2007 [Page 8] Internet-Draft Multiple interface selection Oct 2006 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. 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. 5.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 Park, et al. Expires April 22, 2007 [Page 9] Internet-Draft Multiple interface selection Oct 2006 5.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. 5.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: 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. 6. Implementation 6.1. Machine setting We implemented MIS on our testbed machines. There are 6 machines, one correspondent node, two access routers which show different network characteristics, one MMR and one mobile node. The machines are organized as follow: Park, et al. Expires April 22, 2007 [Page 10] Internet-Draft Multiple interface selection Oct 2006 +-----+ +-----+ CN +-----+ | +-----+ | | | ~ ~ | | +---+---+ +---+---+ | AR1 | | AR2 | +---+---+ +---+---+ | | +------+ +------+ | | +--+---+--+ | MMR | +----+----+ | +--+--+ | MN | +-----+ Figure 3. Testbed machine organization All machine have Intel Pentium4 2.8Ghz CPU, 512MB RAM. They all use Fedora core 4 for operating system, and ARs and MMR upgraded its kernel version to 2.6.15. Other machines uses kernel version 2.6.9. Since there is no application programming interface to manipluate hop-by-hop option at application layer, we attached the option to the packet by following methods. First, we caputred all packets going outside from mobile node. This is done by using ip6tables. Second, all capture packets are sended to ip6_queue by libipq library. And the hop-by-hop options are attached to packet and it forwarded to the MMR. At MMR, the packet is examined whether it includes traffic class option in its hop-by-hop extension header. If not, the packet is forwarded to the interface by linux kernel routing. If it has the option, then MIS module running in MMR checks its traffic control option, select a interface to forward the packet, and forward the packet through the interface. 6.2. Test sceanario We run IPv6 video streaming server on MN, and make an access to the streaming from CN. The hop-by-hop option is attached at MN, and the option express that this traffic is video traffic. And we runs another application which is simple IPv6 echo server on MN and echo Park, et al. Expires April 22, 2007 [Page 11] Internet-Draft Multiple interface selection Oct 2006 client on CN. We checked that video traffic is forwarded to AR1 by MMR while echo data is forwarded to AR2, when all applications work correctly. 7. Security We do not consider any security issues in this draft. 8. 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. [3] Microsoft, "What is QoS?", Windows Server Techcenter QoS Technical Reference, March 2003. Appendix A. Change Log This draft is an update of draft-park-mis-00.txt Changes from draft-park-mis-00 to draft-park-monami6-mis-01: * Modifications to Section 2: - Removed flow label term + Modified some expressions * Modifications to Section 4: - Removed Section 4.1 Flow label"> + The framework picture has been simplified + Description about traffic class and preference has been moved * Added new Section 6 Implementation Park, et al. Expires April 22, 2007 [Page 12] Internet-Draft Multiple interface selection Oct 2006 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 April 22, 2007 [Page 13] Internet-Draft Multiple interface selection Oct 2006 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 Advanced 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 April 22, 2007 [Page 14] Internet-Draft Multiple interface selection Oct 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Park, et al. Expires April 22, 2007 [Page 15]