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.

. 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.

. 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.

. 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.

. 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.

. 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.

. 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

. 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.

.  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.

. 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.

. Authors Addresses

Lawrence Roberts
Anagran Inc.
 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.