MONAMI6 R. Jaksa Internet-Draft C. Williams Intended status: Informational B. Sarikaya Expires: April 19, 2007 Huawei USA October 16, 2006 Method to specify optimal specification of service ports for flow bindings draft-jaksa-monami6-flowserv-00.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 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This method introduces a specification in the Mobile IPv6 MONAMI6 work that allow nodes to bind a particular flow based on the service port to a care-of address. This method is different and more flexible than a current solution in the Internet community in that multiple ranges of ports and individual specific ports not in any defined range may be specified within a single flow identification Jaksa, et al. Expires April 19, 2007 [Page 1] Internet-Draft Flow Service Selection October 2006 message. This is an idea that may be adopted or incorporated into currently proposed MONAMI6 flow redirection proposals. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network port specification for multiple ranges and individual ports . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Example of how to incorporate this (port, len) 2-tuple into flow ID extension . . . . . . . . . . . . . . . . . . . . 4 5. Network Port Selection Requirements . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative references . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Jaksa, et al. Expires April 19, 2007 [Page 2] Internet-Draft Flow Service Selection October 2006 1. Introduction A mobile node will have in the future multiple network interfaces, and the best decision to select an interface and an access network from other possible combinations has to be taken. This decision will depend on several things such as: user preferences, requirements from applications, device capabilities, available network interface cards and their performances, available access networks and their capabilities, etc. [5] Using MONAMI6 [3] technologies a multi-homed Mobile IPv6 Node [1] is able to use multiple interfaces at the same time, according to some preference settings. This will allow the MN to achieve load sharing, load balancing and aggregated bandwidth when sessions are initiated by the MN. TCP and UDP ports are network ports. IANA is responsible for assigning TCP and UDP port numbers to specific uses. The port numbers are divided into three ranges: the Well Known Ports, the Registered Ports, and the Dynamic and/or Private Ports. 1. The Ports that are popular are those in the range 0 thru 1023. On Unix OSs, opening a port in this range to receive incoming connections requires administrative privileges, although this all might change. 2. The Registered Ports are those in the range 1024 thru 49151. 3. The Dynamic and/or Private Ports are those in the range 49152 thru 65535. Using MONAMI6 technologies a multi-homed Mobile IPv6 Node is able to use multiple interfaces at the same time, according to some preference settings. A type of preference setting that is most common is for the Mobile Node to indicate to the CNs that based on the specific service or application that those flows should be directed to a specific interface associated with a given CoA. The way in which to determine a service or application is via the network ports. In this write-up we wish to highlight the need for the ability to specify multiple network port ranges as well as individual ports that may not be in a range. 2. Terminology See [2] for mobility terminology used in this document. 3. Network port specification for multiple ranges and individual ports The goal of the specification is to add the ability to be able to Jaksa, et al. Expires April 19, 2007 [Page 3] Internet-Draft Flow Service Selection October 2006 specify individual ports as well as port ranges that a particular flow may be bind on to a specific care-of address. The method also does this in a optimized fashion in terms of the number of messages and bytes that may be used in representing the port numbers. Groups of 2-tuples of starting port and length may be specified as which flow traffic may be binded to a specific CoA. An illustration is provided below. These groups may be variable length (1 or more). 1. 3401, 5; 3407, 2 : This specification illustrates that port number 3401, 3402, 3403, 3404, 3405, 3407, 3408 will all be specified as part of the binding in a single flow identification type message. 2. 1099, 4; 3001, 1; 3023, 2; 6500, 7 : This specification illustrates that port number 1099, 1100, 1101, 1102, 3001, 3023, 3024, 6500, 6501, 6502, 6503, 6504, 6505, 6506 will all be specified as part of the binding in a single flow identification type message. 3. 4001, 1 : This specification illustrates that only port number 4001 will used for flow binding to a particular CoA. 4. Example of how to incorporate this (port, len) 2-tuple into flow ID extension Draft [4] is one example proposal to define flows and associated bindings to CoAs. One can use the above syntax to specify either source ports or destination ports for flow-CoA bindings. An example of how the packet format might look based on the current flow identification message in draft [4] is illustrated. Jaksa, et al. Expires April 19, 2007 [Page 4] Internet-Draft Flow Service Selection October 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Type | Option Len |S|E|F|L|O|W|T|I|R|H| PRI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | Action | Status | PRO | CLS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Other data fields that makeup the flow Identification option. An example may be The current flow identification option or Could be some other yet to be defined Flow identification option. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Number of 2-tuples | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start source port | Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start source port | Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Incorporation into Flow Identificaiton Message The same specification can be used for flow bindings on destination port(s) (which is not shown). In the extension above a new filed of number of 2-tuples for source ports is specified. A dynamic number of 2-tuples of (port, len) then are provided. 5. Network Port Selection Requirements As a side to the central focus of this draft we wish to provide some input into requirements for any solution that may be developed to aid in the CNs decision to choose the "best" MN address or interface in which to initiate a connection to. Mobile Nodes may indicate which source or destination networking ports that they wish to bind flows from CNs to itself. We feel that a flexible specification that allows multiple port ranges and individual ports to be specified all in a single flow identification message will meet key requirements for the overall mechanisms. We see those key requirements as: Jaksa, et al. Expires April 19, 2007 [Page 5] Internet-Draft Flow Service Selection October 2006 1. The mechanism MUST periodically re-evaluate the mappings between flows and interfaces to take into account the quality changes on the different interfaces (or addresses). 2. The mechanism MUST be Dynamic Adaptive in that after re- evaluation of the mappings and update is done so that flows are adjusted immediately or that new initiated connections reflect the current preference settings of the MONAMI6 MN. 3. The mechanisms SHOULD provide various granularity in its mappings. Such granularities examples include mappings of service to addresses (interfaces), mappings of source address to destination addresses (interfaces), and load balancing mappings from the context of the MN. 4. The mechanism MUST provide rapid reaction to topology changes. 5. The mechanisms MUST provide a secured way for the MN to update the mappings. 6. Security Considerations Security considerations for the overall mechanism is specified in the individual solution draft. The proposed specification of allowing multiple 2-tuples of (port, len) introduces no new security threats. 7. Conclusion We anticipate the need to specify multiple port ranges as well as individual port numbers in the MONAMI6 flow bindings associated with individual CoAs associated with the same MN Home Address when basing such flows on the service network ports. This document attempts to provide a flexible manner in which to allow for this kind of flexible specification. We proposed the use of a 2-tuple (port, len) that may be variable numbers for either the source or destination port. It is not the goal of this draft to propose an entirely new method for flow identification and filtering but only that when specification for defining flows on network ports that a greater granularity might be achieved. 8. References 8.1. Normative references [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. Jaksa, et al. Expires April 19, 2007 [Page 6] Internet-Draft Flow Service Selection October 2006 [3] Montavont, N., Wakikawa, R., and T. Ernst, "Analysis of Multihoming in Mobile IPv6", Work In Progress draft-ietf-monami6-mipv6-analysis-00.txt, February 2006. [4] Soliman, H., Montavont, N., and N. Fikouras, "Flow Bindings in Mobile IPv6", Work In Progress draft-soliman-monami6-flow-binding-02.txt, September 2006. 8.2. Informative References [5] Andre, F. and J. Bonnin, "Optimized Support of Multiple Wireless Interfaces within an IPv6 End-Terminal", Smart Object Conference 2003, Proceedings of SOC, November 2003. Authors' Addresses Robert Jaksa Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: rjaksa@futurewei.com Carl Williams Huawei USA Consultant, Palo Alto, CA 94306 USA Phone: +1.650.279.5903 Email: carlw@mcsr-labs.org Bechet Sarikaya Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: bsarikaya@huawei.com Jaksa, et al. Expires April 19, 2007 [Page 7] Internet-Draft Flow Service Selection October 2006 Full 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. 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. 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). Jaksa, et al. Expires April 19, 2007 [Page 8]