INTERNET-DRAFT L. Roberts Intended Status: Standard Anagran Inc. Expires: January 19, 2006 J. Harford Blue Wave Labs July 19, 2005 In-Band QoS Signaling for IPv6 draft-roberts-inband-qos-ipv6-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 January 13, 2006 Copyright Notice Copyright(C) The Internet Society (2005). Abstract This specification describes the basic requirements for In-Band QoS Signaling in IPv6. The context is where a QoS requirement is passed across the network and some of the routers need to modify the request to modify the request if the requested QoS is not available at that node, indicating what QoS is available. 1. Introduction There are some applications for IPv6 where it would be of great value for the user to request a specific level of QoS and have the routers along the data path agree on the or adjust downward the request to permit the user to know exactly what QoS was available. An example of this is to agree on the maximum rate that a TCP flow can be permitted at this time. The benefits of such network wide agreement particularly important for operation over high delay paths like satellites or high noise paths like radio links as are common in military or civilian emergency forward areas. Here determining the TCP rate, by rate feedback can greatly improve the performance. There are also many other application areas such as video conferencing where confirming the available rate (capacity), jitter and precedence can be very important at the start of a call. 2. Discussion To accomplish this requires an in-band signaling capability and in many of these cases, more information than the 6 bits in Diffserv are required. The only possible way to add more information to a packet stream in-band for IPv6 is to use a hop-by-hop option field. All other optional fields are encrypted and thus are not available to the routers. In the past it has been very hard for routers to take the time to modify a packet in-flight. However, advances in electronics hardware now permits much more extensible packet processing that could look at a QoS request, determine the available resources, and to modify the packet accordingly. Given that this capability is either now available or soon will become available, it is important to make provision in the IPv6 protocol for such in-band QoS options to be possible and tested. One particular reason for approving the basic option structure now is that new satellites with onboard routing are now being designed and this design needs to be frozen soon, even though their launch is several years away. 3. Basic Requirement If in-band QoS Signaling of any format is to be used with IPv6, it is essential that a hop-by-hop option code for QoS signaling be assigned. It should have a version field so that various designs can be designed and tested. The main requirement for routers to process the option is at choke points in the network. Since the option in many cases need not be processed by over-capacity core routers or in MPLS tunnels, the option code should be one that is ignored by routers if they do not understand the code. It also should be one where fragments do not replicate the option and one where it can be modified. Thus the option code must be of the form 001xxxx. None of this type has ever been assigned due to the past difficulty of modifying packet in flight. 4. Interest This RFC is being distributed to members of the Internet community in order to solicit their reaction to this proposal. The TIA has already approved a protocol to improve satellite operation where such an option assignment is required. The ITU has in progress proposals similar to the TIA protocol. The IETF may well design its own protocol for in-band QoS Signaling in the future. Since there is only one possible way to accomplish this, by using a hop-by-hop option, there is considerable reason to consider assigning such a code now and allowing the other standard bodies to proceed where they have identified a critical requirement. If the IETF chooses never to use this code, it cannot hurt the network since it will be ignored by the routers and they will discard any packets that exceed their capacity. If they do decide to use the code, a separate version code can be used. However, where such a protocol is used in certain critical areas like over satellites, or in noisy radio domains, it can be of critical benefit to specific users and it is important to permit other standard groups like the TIA to address their problem using compatable IP. 5. Status Report In response to the need for maintenance of current information about the status and progress of various projects in the Internet community, this RFC is issued for the benefit of community members. The information contained in this document is accurate as of the date of publication, but is subject to change. Subsequent RFCs will reflect such changes. 6. Normative References [RFC2640] Internet Protocol, Version 6 (IPv6) Specification, S. Deering, R. Hinden, RFC 2460, December 1998 6.1 Informative References [TIA1039] Revised to RFC Format, QoS Signaling 7. Security Considerations There are no security issues in assigning a option code. There may be various security considerations in any particular protocol using the option code such as authentication and authorization. However, for IPv6, these security issues have already been addressed. If new issues are created by a particular protocol, those issues should be addressed for that protocol. 8. IANA Considerations The request is for IANA to assign a hop-by-hop option code of the form 001xxxx for the type of usage, QoS Signaling. The request is for IANA to assign a hop- by-hop option code of the form 001xxxx for the type of usage, QoS Signaling. A Version Field can be located starting at byte 25 for 12 bits. This would be desirable to maintain correspondence with the TIA and the ITU specifications and permit multiple protocol versions. 9. IETF Consensus In order for IANA to assign an IPv6 hop-by-hop option code, either IESG agreement or IETF Consensus is required. This ID need not be approved, just the code for general use. Since all IPv6 protocols that attempt in-band QoS Signaling must use an IPv6 hop-by-hop option code of this type to allow over-capacity routers to ignore this option and to avoid encryption, the assignment is of general use as we move IPv6 into areas where low error rate, low delay fiber does not exist. 10. Authors Addresses Lawrence Roberts Anagran Inc. 2055 Woodside Road #200 Redwood City, CA 94061 Email: lroberts@anagran.com Jim Harford Blue Wave Labs P.O. Box 10 Rougemont, NC 27572 Email: harford@bluewavelabs.com Full Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.