Internet DRAFT - draft-roberts-inband-qos-ipv6

draft-roberts-inband-qos-ipv6



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.