MONAMI6 R. Jaksa Internet-Draft C. Williams Intended status: Informational B. Sarikaya Expires: September 6, 2007 Huawei USA March 5, 2007 Method to specify optimal specificaiton of service ports for flow bindings draft-jaksa-monami6-flowserv-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 September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 September 6, 2007 [Page 1] Internet-Draft Flow Service Selection March 2007 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. Binding service flows . . . . . . . . . . . . . . . . . . . . . 3 4. Network port specification for multiple ranges and indivdual ports . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Example of how to incorporate this (port, len) 2-tuple into flow ID extension . . . . . . . . . . . . . . . . . . . . 5 6. Network Port Selection Requirements . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative references . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Jaksa, et al. Expires September 6, 2007 [Page 2] Internet-Draft Flow Service Selection March 2007 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 writeup 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. Binding service flows Binding service flows through Mobile IPv6 provides a seamless, Jaksa, et al. Expires September 6, 2007 [Page 3] Internet-Draft Flow Service Selection March 2007 integrated framework for composition preferences by a multi-interface MN of binding services to a particular destination or source interface. Mobile IPv6 ensures correct routing of packets to a mobile node when the mobile node changes its point of attachment with the IPv6 network. However, it is also required to provide proper preference mappings of a particular service over a particular type of link type. There may be serveral flows between a given MN and the respective CN. Here also the MN may also want to change a service flow binding on a distant CN at any point of time, even if it does not get a new CoA. For example, its internal policies may change, or a new flow is initiated between the MN and the CN we will want to include the new service to CoA mapping. The flow discriminant can be one, several or all fields of the service with respect to the source/destination ports numbers. For example, it can be just a destination port. The priority field is used to set a priority on the different entries and helps if conflicts (two different mapping with the same CN). The protocol details and format must be able to allow the mapping of many different flows to varying CoAs in a single message update (i.e., Binding Update with the respective filters). Below the protocol message is detailed. 4. Network port specification for multiple ranges and indivdual ports The goal of the specification is to add the ability to be able to 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. Jaksa, et al. Expires September 6, 2007 [Page 4] Internet-Draft Flow Service Selection March 2007 5. 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. 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. Jaksa, et al. Expires September 6, 2007 [Page 5] Internet-Draft Flow Service Selection March 2007 6. 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 indiciate which source or destination networking ports that they wish to bind flows from CNs to itself. We feel that a flexiable 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: 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. 7. 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. 8. Conclusion The service flow to CoA mapping specify default behavior for all Internet Protocol version 6 (IPv6) implementations. However, they do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. 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 flexiable manner in which to allow for this kind of Jaksa, et al. Expires September 6, 2007 [Page 6] Internet-Draft Flow Service Selection March 2007 flexiable specification. We prposed 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. 9. References 9.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. [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. 9.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 Jaksa, et al. Expires September 6, 2007 [Page 7] Internet-Draft Flow Service Selection March 2007 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 September 6, 2007 [Page 8] Internet-Draft Flow Service Selection March 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). Jaksa, et al. Expires September 6, 2007 [Page 9]