Network Working Group                                  L. Roberts

Internet Draft                                       Anagran Inc.

Category: Informational                             July 25, 2005

 

QoS Signaling for IP QoS Support

 

Status of This Memo

 

This document specifies an Informational specification for

the general information of the Internet community. Distribution of this memo is unlimited. The specification has the same content as TIA 1039 (July 2005) and the May 2005 specification being worked on in SG13 of the ITU.

 

Copyright Notice

 

Copyright(C) The Internet Society (2005).

 

Abstract

 

This document provides a Quality of Service (QoS) signaling proposal for use within IPv4 and IPv6 network-layer protocols.  This mechanism will allow the necessary resources to be allocated to a flow (or group of flows) as they traverse the network.  This signaling scheme is designed to work "in-band", and requires hardware or microcode support in the participating network elements (i.e. routers). Thus, the QoS is setup in real time across the network without a separate, out-of-band, software signaling structure like Reservation Protocol (RSVP). The resource "request" and (when needed) the "response" messages are incorporated into the user data packets themselves, allowing the QoS requirements to be setup during the initial network traversal from sender to receiver (and back if needed). This signaling scheme can be used to set the rate, burst tolerance, preemption priority, delay priority and charging direction for a flow.

 

 

Table of Contents

 

1    Overview  

1.1  Scope

1.2  Objectives

2    System Architecture 

2.1  Satellite and Radio Links 

2.2  Network Architecture Satellite Networks   

2.3  QoS Service Goals  

2.4  QoS Signaling Model for Available Rate    

2.5  QoS Signaling Model for Maximum Rate

3    Limitations in current QoS Techniques

3.1  Introduction   

3.2  Diffserv Limitations

3.3  IntServ Limitations 

3.4  TCP Limitations

3.5  QoS Feature Summary 

3.5.1 Maximum Rate   

3.5.2 AR Rate Feedback    

3.5.3 Preemption Priority

3.5.4 Charging Direction 

3.6  Router Operation    

4    Procedures for Signaling QoS   

4.1  Authentication 

4.2  Standard IP Case    

4.3  QoS Signaling Operation   

4.3.1 QoS Structure  

4.3.2 Request Procedure   

4.3.3 Response Procedure (at Destination) 

4.3.4 Response Receipt (Back at Source)   

4.3.5 Renegotiate Every 128 Packets  

4.3.6 Sender Rules   

4.3.7 Router Rate Negotiation   

4.3.8 Mobility in IPv4    

4.3.9 Non-Compliant Routers & Receivers   

5    QoS SPECIFICATION PACKET FORMAT AND FIELDS

5.1  IPv4 Packet Format for the QoS Structure  

5.1.1 AR and GR - Encoding Floating Point 

5.1.2 IPV4 Response Packet

5.1.3 IPv4 Confirmation and Close Packets 

5.1.4 IPv4 Renegotiate Packet   

5.1.5 Router Generated Start Packets 

5.1.6 IPv4 and IPSEC  34

5.2  IPv6 Packet Format for the QoS Structure  

5.2.1 IPv6 Response Packet

5.2.2 IPv6 Confirmation and Close Packets 

5.2.3 IPv6 Renegotiate Packet   

6.1 Abbreviations  

6.2  Definitions    

6.3  Informative References    

6.4  Normative References

 

1 OVERVIEW

1.1   Scope

 

The signaling strategy for IPv4 and IPv6 uses the same QoS Structure but due to the protocol differences, is transported in slightly different ways. For IPv4, the document specifies a QoS Structure to be added to the first data packet or "Start Packet" of a flow, requiring a unique Diffserv code-point. An additional QoS Structure can also be sent in this manner, whenever the rate needs to be changed. For IPv6, the same QoS information is added as a hop-by-hop option so that it is not encrypted. Each network router in the path examines the QoS Structure and agrees to or adjusts the rates requested to the rates it can support. If any of the rate parameters have been changed, by the network elements in the flow path, this is communicated back to the sender by the receiver.

The QoS defined within this signaling structure can support four general types of service.  The first is a fully guaranteed rate flow, which implies no oversubscription of network resources. The second is a maximum rate flow, which allows some oversubscription but virtually no packet loss.  The third is a variable rate flow, where available rate is combined with a minimum rate guarantee.  The fourth is an available rate flow, one that can jumpstart the Transmission Control Protocol (TCP) to the highest rate the network can support, eliminating slow-start problems. In the available rate case the capacity available based on network congestion is fed back to the sender very rapidly at all times. This will help to differentiate congestion problems from channel errors (measured in bit error rates), permitting the sender to then optimize his packet error control without confusing it with congestion. For premium services like voice and video maximum rate service sets up a low delay, low loss path with a minimal of effort.

 

1.2 Objectives 

 

This document is a complete specification of the requirements for this QoS Extension Header. It specifies the protocol structure, the router responsibilities, and the actions required of the sender and receiver. It supports, in both IPv4 and IPv6, guaranteed and maximum rate flows with preemption, variable rate and available rate flow setup allowing TCP speedup independent of network delay and slowstart, and specifies charging direction.

 

 

2 SYSTEM ARCHITECTURE

 

This specification applies to any IP network of routers. All the routers in the network need not support this QoS procedure.  Those that do support the procedure should have information typically exchanged via a routing protocol that identifies the adjacent network elements that can also support the proposed protocol. These QoS capable routers can then either pass flows that have the QoS Structure to other routers with same capability, pass the flow to over-capacity routers, pass the flow through MPLS tunnels, or mark the QoS Structure as unsupported. The protocol is designed so that a router that cannot support the QoS procedure can ignore it without any repercussions and that in a typical overcapacity IP network, only the choke points (typically edge routers) need to support the protocol.

 

2.1 Satellite and Radio Links

 

This protocol has particular value in networks where there are either high delay links, paths that may have higher than normal error rates, or bandwidth variability. Satellite paths have some or all of these characteristics as do radio links.

TCP over Satellite or Radio: TCP, as structured today, was designed for 50 kilobit per second paths with very low error rates. If either the Round Trip Time (RTT) or the error rate exceed that of ground fiber, the TCP throughput and efficiency can become intolerability low. When the RTT is high as in a satellite network, this protocol permits one to maximize throughput over the path, by telling TCP the highest possible rate. This will allow the sender to proceed at this rate independent of slow-start. Currently, when there is a high error rate or fading on a link, TCP quickly slows down assuming it is congestion. Instead, this protocol keeps the throughput at the maximum permitted based on congestion and therefore allows TCP to proceed at the full goodput of the channel even in the face of packet errors or losses due to channel noise or fading. The user can continue to move packets at the maximum rate possible but may want to institute additional measures such as forward error correction, and/or better retransmission techniques to compensate for the errors. As a result, TCP will operate far better over these types of channels.

 

TCP/IP Software:  In order for a terminal or server to support the QoS improvement specified in this document, the TCP/IP driver must be updated to support the QoS Structure and feedback specified in this protocol. This is a minor addition to TCP/IP that could be made available as a download from a server. The change is for the sender to signal the TCP rate desired across the network and proceed with normal TCP/IP procedures like slow-start until a response packet is received. Then the rate should jump to the approved rate, which is the available rate plus a guaranteed rate (if needed). The transfer should be kept at this rate until an adjustment becomes necessary. This can occur if the network has a problem or when the available rate is re-negotiated every 128 packets. This is a similar procedure to that used and proven [ExplicitRateFC] in Available Bit Rate (ABR) in ATM.

 

TCP Spoofing at a Satellite Gateway: With IPv4 satellite systems were capable of looking into TCP packets and spoofing TCP at a gateway so as to provide reasonable TCP throughput even with the high delay. With IPv6 and IPv4 using IPSEC, spoofing is not possible due to the encryption of the TCP information and thus IPv6 must have a protocol improvement of this type to operate over satellites. Spoofing depends upon looking inside the TCP section to find ACK's and other protocol marking. This cannot be done if the TCP section is encrypted. This protocol procedure proposed in this document permits very high TCP throughput (the maximum possible) on any path, including satellite links for unencrypted IPv4 or encrypted IPv6 traffic without the necessity of spoofing. When IPv4 uses IPSEC, the protocol may not be possible, but if the start packets (marked with a unique Diffserv code) are not encrypted, the protocol will work.

 

User Datagram Protocol (UDP):  Streaming data like voice and video are typically sent with UDP. UDP has no provision for determining if it is exceeding the network capability. Thus, packets will normally be discarded if the stream exceeds the current capacity in the network. Since UDP is not retransmitted, the discards create holes in the data stream. This QoS procedure allows the user to request the rate they require or a variable rate up to a maximum rate specified. If all network nodes accept this maximum rate, no response is necessary. Should any node downgrade the rate then the receiver returns the QoS Structure received from the network back to the sender. If the rate is downgraded, the lower rate is returned as part of the QoS Structure to the sender. The sender may then proceed at the agreed rate or try again later. If the QoS Structure is returned without change, or with a lower rate, the user is assured of a guaranteed rate stream where packets will not be discarded due to congestion. In an emergency there may still be interruption of the service by a user with higher preemption priority.  However, outside of such a scenario, the stream should be nearly lossless. If service is affected by preemption, the user is informed of the new rate available across the network. In an extreme case of high channel noise, packets may be lost or received with errors but the guaranteed rate agreement insures that the cause is known to be channel problems and not congestion.  The former can be addressed with retransmission or forward error correction.

 

TCP Operation: For TCP, the sender uses a QoS Structure specifying the maximum available rate the sender would like to use. Often this will be the speed of its network adaptor or access link. Each network element (i.e. router) along the flow path can reduce this rate if necessary.  Should the router determine that no QoS capable path is available, this is also marked down (as unsupported). When the receiver gets the QoS Structure, if there is a confirmed available rate, it should return said Structure back to the sender in order to take advantage of the rate agreement. The sender may then jumpstart TCP slow-start to the agreed available rate and proceed to send at this rate until a change is received. If the receiver is told in the QoS Structure that the path does not support this QoS procedure, then it need not respond and the sender will proceed with slow-start as normal.

 

2.2           Network Architecture Satellite Networks

 

 

In a satellite network the source is a server sending a stream or file to a terminal. The source adds the QoS option to request the QoS desired with user selected guaranteed rate and/or network determined available rate. The packet travels across the user's local network (Area 1). There may then be an encryption device to separate Area 1 from the general network. There are two QoS-capable options at the encryption device:

1. A new IP packet header is added with the source address of the Encryptor, the destination address of the Decryptor, a new flow label (either the original one or a translation of the original one), a QoS option field (either the original one or a masked subset of the original one), and the encrypted original packet.

2. A new IPv6 packet header is added with the source address of the Encryptor, the destination address of the Decryptor, a new flow label that stands for a group of incoming flows, a QoS option field that reflects the combined requirements of the combined flows, and the encrypted original packet.

In case one, the flow will retain its individual QoS across the entire network.

 

This will provide the maximum capability to the end user and the maximum efficiency of the network.

In case two, security may dictate that many flows be combined into one stream. This will impact network efficiency and may be difficult to administer due to the necessity of allocating bandwidth at the Encryptor. Of course, the Encryptor could eliminate the QoS option altogether, but then no QoS will be able to be setup across the network. At the Decryptor the individual flows are all give the same QoS structure, however as these are routed to the receivers the routers may reduce the rates based on local conditions. The result is that the network between the encryption devices supports only one QoS but the tail ends of each flow may adjust each imbedded flow to lower values of GR, AR, PP, BT and higher values of DP based on the local path and user authorization. The composite path is set to the sum of all the rates and the most strict other QoS conditions.

 

After encryption, the packet traverses routers in Area 2, perhaps a satellite network link, routers in Area 3, and arrive at a second Encryptor for decryption. Here the original packet is decrypted with its original flow label and QoS request and is passed on through Area 4 to the destination. The QoS request will have been processed by all the routers in the path to determine what available rate can be assigned fairly to the flow and if the requested guaranteed rate is available. The destination will receive the QoS request modified to what is available. It returns a packet to the source with this information (perhaps by a separate path). This allows all the routers in the forward path to release any resources reserved. The source then proceeds to send at the agreed rate for up to 128 packets. Then it must re-request its available rate so the network can adjust quickly to load or capacity changes.

 

The entire process allows the establishment of flows at the maximum rate the network can support without congestion packet losses. There may still be satellite channel noise errors in packets, but an optimal system would control the channel bandwidth and forward error correction to minimize this failure mode. If this is done, the flows should be nearly lossless for both TCP and UDP.

 

 

2.3           QoS Service Goals

 

     The goal is to support several new IP capabilities:

 

1.   GR- Guaranteed Rate (optional)

 

This service specifies a reserved rate and is intended for those cases where bandwidth must be reserved by the network, even when it is unused. The network should not oversubscribe the allocations for any given preemption level. It requires a confirm message and a close message, which are only used with the Guaranteed Rate service. The codes for this service are included herein, but it is expected that most interactive services like video or voice will use maximum rate, not guaranteed rate.

 

2.   MR- Maximum Rate (mandatory)

 

This service is a type of guaranteed rate service with no fixed reservation. It specifies the maximum rate the flow might use and makes every attempt to assure no packet loss if the flow remains under this rate. The flow may be variable in rate and therefore flows must be rejected if the observed traffic exceeds a threshold. It is however a statistical guarantee, not an absolute guarantee. The flow is dropped if no traffic is seen for a preset period and so no close is required. No confirm message is required, since there is no fixed reservation to release. The service should be used for individual video, voice or streaming media flows where very low loss and/or low delay jitter is required. The setup message is accommodated in hardware by the network, at wire speed.

 

3.   VR- Variable Rate (optional)

 

This service is similar to ATM VBR. Some applications require a variable rate flow approach, where part of the rate is guaranteed and part is determined by network capacity (available rate). This is typically the case, when streaming media cannot function below a base rate but can take advantage of additional capacity if it is available. This capability is signaled as a maximum rate plus an available rate. Traffic up to the maximum rate plus the available rate will be supported. The available rate may be changed from time to time as the network capacity changes whereas the maximum rate is fixed for the duration of the flow (unless preempted). 

 

4. AR- Available Rate (mandatory)

 

This service is where the network determines the available rate for the flow based on its current loading. Today, the problem with TCP data transfers is that the end-to-end delays and the line error rates severely reduce the maximum TCP rate.  This in turn greatly increases the time to deliver a data block, as in a typical WWW transaction. It has been shown previously [ExplicitRateTCP] that network computed rate feedback is by far the most efficient method of improving TCP (available rate) throughput and block delay. Given the basic capability required for end-to-end network determination of guaranteed rates, the same capability can be used for available rate flows, except that the rate must be allowed to change from time to time as the network load changes. Thus, TCP slow-start can be jump-started to the network available rate and adjusted over time to allow for network load changes. This improves WWW access times by a factor of 10:1 [BestEffort], allows multi gigabit flow rates when capacity is available, avoids slow down for line bit errors, and allows the network to recover faster from trunk failures.

 

5.   PP- Preemption Priority (mandatory)

 

This indicates which flows should survive when the network capacity is insufficient to support the required quality of all the flows. Preemption is a critical addition to IP given the addition of GR, MR and VR services where specific bandwidth is required for useful operation. It was not required when the only services were best effort services. It is necessary to support civilian emergency services, military services, and will also be important in both the office and the home.

 

6.   BT- Burst Tolerance (mandatory)

 

This specifies how much the actual rate may exceed the stated rate before policing is enforced. This not only applies to rate bursts the user may introduce at the source but is necessary to allow for bunching the network routers may introduce.

 

7.   DP- Delay Priority (mandatory)

 

This provides a wider range of delay priority options than are currently available in Diffserv.

 

8.   CH- Charge Direction (mandatory)

 

This specifies who is paying for this flow, the sender or the receiver. This allows IP to provide 800 type services like the PSTN and allows for peering between networks of different sizes with fair charging.

 

The measurement and definition of rates is discussed in 5.1.1. The granularity of the rates is also defined in 5.1.1 given the 9-bit mantissa of the floating-point rate representation. All routers in the forward path and the receiver are permitted to change GR, AR, PP and BT downward and increase DP as necessary to make the flow conform to whatever resources are available and to conform to the users authorization.

 

These improvements in Internet Protocol operation are required if the IP network is going to successfully replace the TDM and ATM networks, and still remain fully compatible with IP operation and principles. All services are available for both TCP and UDP traffic. The enhancements will require hardware or microcode additions to process the QoS Structure by the network elements at wire speed. However, given today's ASIC technology and NPU capability, this kind of support for the proposed QoS Structure is completely feasible. Since these hardware-driven QoS operations are typically only executed one or a few times per flow, the processing power required is far less than today's per packet routing. This was certainly not true at the inception of Internet Protocol, but today the routing of flows with QoS support requires far less processing power than routing every packet. Adding a signaling mechanism that permits these improvements will allow critical QoS improvements to be introduced over time, with great potential for cost reduction.

 

 

 

2.4           QoS Signaling Model for Available Rate

 

The signaling exchanges taking place in the QoS signaling for Available Rate is as follows:

 

     First Packet

      ++++++++++

      + SENDER + -->AR=100

      ++++++++++           V

                        +++++++++

                        + Router+  --> AR=35

                        +++++++++          V

                                        +++++++++

                                        + Router+ --> AR=30

                                        +++++++++         V

                                                      ++++++++++

                                                      +RECEIVER+

                                                      ++++++++++

     Response                                             V

                                        +++++++++

                                        + Router+ <-- AR=30

                                        +++++++++

                                            V

                        +++++++++

                        + Router+ <-- AR=30

                        +++++++++

                            V

     Confirmation <----------

     ++++++++++

     + SENDER

     ++++++++++

                     

                     Figure 2.4-1 - Packet Flow Example - AR

 

In Figure 2.4-1, the source (Sender) sends the first packet with the requested QoS.  This packet includes the following QoS parameter:

* Available Rate (AR)

The routers reduce the rates as necessary to provide a congestion free path. The final approved request arrives at the destination (Receiver). The Receiver then returns the approved QoS Structure to the Sender via a response packet. The sender may then send at the agreed rate, unless a revised AR is received from the network. In that case, the sender must adjust to the new revised rate. After 128 packets the Sender may also send a new request for a higher AR (available rate).

 

2.5           QoS Signaling Model for Maximum Rate

 

The signaling exchanges in the QoS signaling for Maximum Rate is as follows:

 

First Packet

      ++++++++++

      + SENDER + -->GR=12

      ++++++++++           V

                        +++++++++

                        + Router+  --> GR=12

                        +++++++++          V

                                        +++++++++

                                        + Router+ --> GR=12

                                        +++++++++         V

                                                      ++++++++++

                                                      +RECEIVER+

                                                      ++++++++++

 

Figure 2.5-1 - Packet Flow Example - Maximum Rate

 

In Figure 2.5-1, the source (Sender) sends the first packet with the requested QoS.  This packet includes the following QoS parameter:

 

·         Maximum Rate (GR)

 

The GR field is used for maximum rate and for guaranteed rate requests. Looking at the example is figure 2.5.1, the sender indicated maximum rate and set the rate to 12 Mbps. Should the destination receive the QoS structure with the change field (see 5.1, M, page 31) unmarked, it indicates that the routers along the flow path have all accepted the rate and were willing to commit to it. Thus, the receiver is not required to send a response. The sender starts to send at the 12 Mbps rate right away and continues until completed, or until a response is received indicating that the rate must be lowered.  It is normally expected that no change of the maximum rate will be indicated by the nodes along the flow path. Thus, for voice or video, typically the response is not required. However, if the rate had not been accepted, the receiver should send a response with the accepted rate.

 

2.6           QoS Signaling Model for Guaranteed Rate

 

The operation of Guaranteed Rate is the same as Maximum rate except that it uses a different TP code and requires a response, confirm and close packet. The receiver generates the response the same as if the MR had been changed in-route. Then the sender must send a confirm packet to inform all the routers of the final parameters so no over reservation is created. Then when the transmission is complete, the sender must wend a close packet to insure the recourses are returned to the pool. If the sender does not use the guaranteed bandwidth, the routers can fill it with other traffic, but must insure that the bandwidth is available whenever the guaranteed rate user sends a packet.

 

 

3                    LIMITATIONS IN CURRENT QOS TECHNIQUES

 

3.1 Introduction

 

This section discusses the limitation of the current methods and further highlights the need for a signaling protocol to accommodate a TDM/ATM level of QoS across a network with TCP rate feedback to the source.

 

3.2 Diffserv Limitations

 

Diffserv provides a Class of Service (COS) marking in 6 bits in the IP header. Only a subset of these are defined. Due to the low number of options, there is no way to have worldwide unified definitions of the meaning of the COS codes. Also there are too few bits to specify a rate for either guaranteed rate flows or for available rate feedback. This limits the utility of Diffserv to a few delay categories and some local link-by-link agreements. In turn this limits IP to a best efforts service with a few classes of service. As we move into video and streaming media as well as improving TCP performance, Diffserv provides insufficient flexibility.

 

3.3 IntServ Limitations

 

The current proposals for IntServ type QoS support (as opposed to CoS support via Diffserv) revolve around a round trip call setup request using complex protocols like RSVP.  These protocols require far more processing than can be done in hardware and are thus relegated to slow software processes. This limits the total end-to-end call processing that can be made to very large flows or composite (VPN) flows since processor speeds fallen well behind the speed required for processing all IP flows.  

 

What is desirable is a protocol that permits the router to process QoS requests for each individual flow, including parameters such as bandwidth, delay priority, preemption priority, burst tolerance, and charging direction. Many common flows like file transfers may not require all this information.  However, increasingly flows are becoming voice, video, gaming, or streaming media where such requirements are needed.

 

Also, as the IP takes over all of the world's voice and emergency communications, the need for call rejection and preemption priority become life and death issues.  These capabilities must therefore be incorporated into the IP protocol for both TCP and UDP. Thus, the requirement is for a hardware based QoS flow setup with many of the properties of Asynchronous Transfer Mode (ATM) or RSVP-IntServ plus some new ones like preemption.

 

3.4   TCP Limitations

 

TCP slow-start has worked well over the past 20 years when the individual flows were generally in the kilobits/second. However, as wideband corporate access and broadband residential access have proliferated, the desired flow rate has increased into the megabits/second up to several gigabits/second. TCP was not designed for these rates at any significant distance.

TCP depends on detecting packet loss to adjust its rate; any packet loss at high rates over long distances creates a major slow down of the flow. Even at normal cross-country distances, maximum TCP throughput is limited to megabits/second rather than gigabits/second.

 

TCP's use over satellites is so deficient that for IPv4 intermediate TCP "spoofing" devices are generally used at either end of any satellite link. However, this will not work when the data is encrypted as in IPv6, in IPv4 with IPSEC or in either with HAPIE encryptors inserted. However since the hop-by-hp option field in IPv6 should not be encrypted, it provides a solution to passing QoS information to the routers.

The second problem with using packet loss as a rate control mechanism is that the typical method of dealing with congestion is to discard random packets, even if the flow in question is not yet up to the speed of other flows. This is usually done using Random Early Detection (RED) or Weighted Random Early Detection (WRED). This procedure slows down the TCP rate so that it does not get up to the maximum network speed as fast as possible. This problem has been magnified as the network speeds have increased such that an average 120 K byte web page transfer over a 10 Mbps access line can take many seconds rather than the fraction of a second actually required.

 

The TCP situation is improved [RFC3168] by marking packets for congestion, using Explicit Congestion Notification (ECN) before discarding becomes necessary. ECN avoids discarding the packet, but the search for the rate the network can support is still a binary search that leads to significant loss of throughput that does not improve the slow-start problem. Marking packets in this way, also presumes that the network has sufficient storage to signal congestion well before the problem becomes critical. This obviously leads to either additional network delays due to long queue traversals, or to lower network utilization (already a problem).

When the concept of marking packets is coupled with the feedback of the maximum rate the network could support, it is feasible for the TCP source to avoid slow-start and achieve extremely high-speed throughput. Instead of marking or discarding packets when congestion occurs, the network can inform all TCP sources as soon as possible of the rate that they can operate at safely. As conditions change, additional feedback is required. This concept was simulated and tested extensively [ExplcitRateFC] with (ABR) in ATM systems. It was found to dramatically decrease the time to transfer a web page and significantly decrease the buffering required in the network. The QoS Signaling protocol specified in this document brings this concept to the IP world.

 

3.5 QoS Feature Summary 

 

We've established that there are four main areas that need to be supported, in order to improve the services available over IP:

1. Maximum rate accommodation for streaming media flows.

2.  TCP rate feedback to eliminate the low throughput encountered due to any significant delay in the flow path.

3. Preemption to support emergency services.

4.   Identifying the direction of charging to permit 800 type services and more flexible peering.

 

3.5.1 Maximum Rate

 

The QoS parameters in [RFC1633] [RFC2212] [RFC2215] [RFC2998] [RFC2474] are somewhat similar, but not necessarily compatible, with those used in IntServ (RFC 1633, 2212, 2215, 2998, 2474) and ATM.  The call setup speed (calls per second) will also need to be much faster than the two latter schemes.  Thus, the need for hardware support and a forward path setup have become necessary. The QoS features important to setting up an interactive voice, video, or streaming media flow, not supported in Diffserv, include the maximum rate requested, the burst tolerance required, the delay priority, and the multi-level preemption priority (PP). With the ability to specify these parameters, IP can be used to deliver the same high quality voice and video as the TDM network but at much lower cost and with much higher line utilization particularly for variable bandwidth streams. These services are moving to IP due to consolidation and cost and it is important to provide the best quality and efficiency possible. As this occurs, preemption priority must be included so that emergency situations can be supported.

 

3.5.2 AR Rate Feedback

 

The concept of Available Rate is the basis of the Internet's current stability. Today, TCP is the primary protocol in use, and it accepts whatever Available Rate the network can support. This concept is needed to allow data traffic, to adjust to, and be limited by, the network's capacity.

 

However the current feedback method, leads to very poor results at high speed. This is especially true in the presence of noise errors or long delay paths. Except for a few lost packets, the current discard based binary feedback is similar to concepts in [RFC3168] on Explicit Congestion Notification (ECN). The proposed Rate Feedback procedure introduced in this memo, determines the maximum Available Rate the network can accommodate, by the collection of said information (AR) across the forward path and its return to the source.  This has proven to be as much as 100 times better than simple binary congestion feedback methods like ECN or the discarding used today. A complete analysis is given in [ExplicitRateTCP].

Currently when encountering long delays or radio noise, TCP sessions cannot support large throughputs, have major delays in face of packet loss, and are treated very unfairly versus competing TCP connections with only short fiber connections. This will be dramatically improved when the network can feed back the maximum rate it could support to the source using this protocol. When the rate feedback is received by the sender, it can adjust its TCP rate to the network-supported rate. If the network capacity changes, the network will send a new rate. Thus the user can continue to send at the agreed rate in the face of packet loss and just retransmit the lost packets without slowing down. This allows users to operate over extremely noisy links with only a linier loss of throughput. Without this capability, if TCP performance cannot be improved, users will convert to UDP and the stability of the whole network will be at risk.

 

3.5.3      Preemption Priority

 

The PSTN currently supports several types of emergency services, not only the user dialed emergency request calls but also code systems for officials to get calls through in the face of massive network overload when disasters occur. The military has its own Multi-Level-Preemption-priority (MLPP) system to allow for high priority messages to get through in the face of limited network capacity. Similarly corporations would find it valuable for the CEO to have priority for his critical video calls in the face of heavy routine network activity. Also, with the very limited bandwidth available over DSL today, home use of IP for video on demand will soon need the ability to prioritize the needs of each family member.

 

3.5.4      Charging Direction

 

Today IP is typically charged at a flat rate. However, as the local link bandwidth increases it will become necessary to put limits on the type and volume of traffic allowed for a given flat rate. This has already occurred in many localities. Also, for certain types of high quality and high bandwidth flows, it may become important to charge per flow (e.g. HDTV for a major sporting event). When either volume limits or per flow charging is in effect, there will be services that wish to offer their service free as is now common with 800 services in the PSTN. This is currently impossible because the carrier does not have a way to mark a flow as to the direction of charging. Also, since flows generally occur in both directions but are decoupled, it is also not feasible to mark them properly as to the real originator. With a bit available to indicate which end is the one responsible, it becomes possible to set volume limits and have 800 type services with total knowledge of the responsible party.

 

This has been an issue in peering between networks since the start of the commercial Internet. Large ISP's have a disincentive to peer with small ISP's because there is no way to determine how to charge each other for traffic imbalance. The direction of the flow has no meaning since either end could have requested the flow. Thus there is no viable technique to have a payment settlement system like we have always had for the PSTN and the Teletype networks. With a charging direction mark, peering between ISP's of all sizes would become easy and straightforward.

Security is important with this charging direction mark. The routers are not allowed to change this mark. The receiver can reject "receiver pays" by reversing the bit. To enforce this the sender should insure it is "receiver pays" (1) if that is what he sent. If not he must resend using "sender pays". It he sends "Sender pays" he must see the same value in the response. Detection of users violating these rules is a process that the first router at either end point should detect and report.

 

3.6 Router Operation

 

The routers are allowed to adjust the available rate (AR) or if necessary the guaranteed rate (GR) at any time they need to as conditions change so as to minimize the probability of loss. The most common case will be the increase of the available rate traffic such that all flows must be slowed down. Short lived flows like web accesses may finish before any action is required but long lived flows like file transfers may need to be adjusted in the middle of the flow. More severe problems like a trunk failing and more traffic being routed over the remaining trunks require instant action and GR may also need to be adjusted or GR/MR flows dropped. The method to be used is for each router to monitor its load and mark the CD field (as described in Section 5) of the first packet of any flow that needs to be adjusted as renegotiate with new rates. If a route changes, the router changing the route of a flow must mark the next packet of each flow as renegotiate even if it does not itself need to reduce the rates since later routers in the path will need to record the QoS and decide if they can support the rates. This way the destination sees a renegotiate packet as soon as possible and sends a response to the source with the new rates. The source would then reduce the rates within about 75% of a RTT and the routers buffer requirement for no loss is reduced very significantly. For details of the buffer size effects see [ExplicitRateFC] and [ExplicitRateTCP].

 

The second issue routers must contend with is the existence of non-compliant routers in the network. A simple effective solution when the core network supports MPLS is to set up a guaranteed rate tunnel mesh between the compliant edge routers. Then the higher than best efforts traffic can be sent through the tunnels and the best effort over the remaining core. If this is not possible the operator should make a decision if the over-capacity routers in his network should be considered compliant or non-compliant depending on their over-capacity. Then the decision of each router is to route flows that require better than best effort QoS over a compliant route if possible or to clear the signaling (set CD=0, see Section 5) if it is going to a non-compliant router. The routing decision is best made using near-equal-cost routing decisions with TE extensions to the routing protocol. If this is not available, neighbor protocol exchange would identify compliant routers if a viable route exists through one of them. If this is unavailable manual marking of neighbors could identify possible compliant routes. If no compliant route exists then the signaling should be cleared (CD=0). The normal case will be that only edge routers and choke-point routers (like at satellite nodes) need actually be compliant, the remainder are typically over-capacity.

 

 

4 PROCEDURES FOR SIGNALING QoS

 

4.1 Authentication

 

The first router in each AS to receive a start packet must determine if the user is authorized to receive the QoS Parameters (GR, MR, PP, BT, DP, and CH) requested. If the prior router was a different AS then it may elect to accept the prior networks authorization or not. If the user is not authorized for the QoS requested, the QoS request should be downgraded before forwarding. Since the first node does user authentication in IPv6 and many IPv4 cases, the authorization process can be made to support automatic flow parameter authentication.

 

4.2 Standard IP Case

 

In the case where no QoS beyond Class of Service (Diffserv) is required or TCP is operating at lower rates without any rate feedback, there will be no QoS Structure and the traffic class will determine the CoS. Typically this will be appropriate for TCP traffic where delay and throughput are not an issue. This is IP as it stands.

 

4.3 QoS Signaling Operation

 

4.3.1 QoS Structure

 

The critical part of the QoS Signaling Protocol consists of a single QoS Structure being sent at the start of the normal data stream with the format as specified in Section 5. The use of the QoS Structure is as follows:

 

Traveling in the first packet, the QoS Structure is examined by each router (in hardware or NPU) to determine if the QoS request can be supported. If it can be supported the packet proceeds to the next router without change. If the router cannot provide the rates or delay requested, it reduces the request in the QoS Structure to what it can support. It then forwards the packet. 

The QoS request will be provided in the first packet using a 16-byte QoS Structure Request. It should not be encrypted even when the remaining data information is encrypted. In this way the routers can process flows quickly and efficiently with the correct QoS.

 

When the QoS Structure gets to the receiver, if the M field in the QoS Structure indicates that no change was made along the path and it is a maximum rate request, then no response is necessary. The sender can continue sending at the specified rate since all the routers have agreed. This will be the normal case for VoIP and streaming video.

 

If the QoS Structure has changed or it contains an Available Rate, Variable Rate, or Guaranteed Rate, the receiver returns the revised QoS Structure back to the sender (it may be over a different path). If the sender is using TCP, slowstart can be reset to proceed at the approved rate. For Guaranteed Rate, the sender then needs to send a confirmation with the revised QoS Structure across the forward path to allow all the routers to discard over commitments. This third handshake or confirmation is not necessary except for Guaranteed Rate where actual bandwidth is being reserved. For Maximum Rate, Variable Rate, and Available Rate no confirmation is necessary because one router (call it the pinch-point) will police the flow to the rate agreed even if other routers will not police as tightly. The sender is therefore forced by the pinch-point router to not exceed the agreed rates and all routers policing at this same rate becomes unnecessary.

 

If any router finds it cannot continue to accept the rates it has approved, it may forward a new QoS Structure to the receiver, indicating the new rates. The receiver sends this new rate back to the sender and the sender must immediately adjust to these new rates. This ensures the network can adjust very quickly to any load change or trunk failure, usually without losing any packets (given a fixed pre-determined buffer size in the network nodes). The router will need to adjust the Available Rate of long duration flows as load builds up. It should not accept too many Maximum Rate flows if it does not have the capacity.  Thus, the primary reason for a reduction in Maximum Rate, once accepted, would be due to new higher preemption flows or massive trunk failures.

In order for a sender to increase the Available Rate during a long flow like a file transfer, new QoS Structure requests can be made during a flow every 128 packets. The only change should be to the Available Rate to see if a higher throughput is available. If the source receives a response from the destination that allows a higher rate, it may then proceed at the new rate. 

 

4.3.2 Request Procedure

 

The sender adds a QoS structure to the first packet sent in a flow specifying all of the QoS parameters as specified in section 5; (GR, AR, PP, BT, DP, and CH) and sets M=0, CD=1. TP is set as follows (see section 5 for definitions of M, CD, and TP) :

 

* TP =0: If the flow is a TCP (available rate) flow, the originator of the packet sets the AR field in the QoS Structure to the maximum rate that the sender can support, GR=0 and Type=0 for available rate.

 

·         TP=1: If a variable rate flow is desired (available rate with a minimum rate base), the originator of the packet sets the AR field in the QoS Structure to the maximum rate that the sender can support, GR to the minimum rate acceptable and TP =1.

 

* TP=2: If a maximum rate flow is desired (variable or fixed rate real time flow where low loss is important), GR is set to the maximum rate possible (typically the maximum codecs rate), AR=0, and TP=2.

 

·         TP=3: When a firm guaranteed rate is needed and the user is willing to pay for its availability independent of use, generally for a VPN, GR is set to the guaranteed rate, AR=0 and TP=3.

 

The first router in the AS should adjust the Preemption Priority, PP, down to the maximum the user is authorized for. The packet loss priority of the flows is based on TP where TP=3 has the highest priority and TP=0 the lowest priority. Delay priority is based on DP and the flow acceptance priority is based on PP.

 

Each router in the forward path should reduce the QoS rate parameters (AR, GR) to the best they can support. They should also adjust BT and DP to the best they can support if they cannot support the requested value.

 

If any router changes any parameter, it should set M=1 indicating a change has occurred.

 

Upon later update requests (CD=5), the routers may not reduce GR below the originally agreed value unless there is preemption of the flow or a major network capacity loss.

 

4.3.3 Response Procedure (at Destination)

 

When any request packet reaches the destination (either a start packet or a renegotiate packet), the receiver must return a response packet (CD=2) with the format specified in Section 2, unless it is a Maximum Rate request with no change (M=0) and mobility is not required.  The use of the response packet is as follows:

 

·         The receiver sets the QoS Structure to specify response (CD=2).

 

·         AR and GR should be reduced to the minimum of the rate received from the forward packet or the maximum rate the receiver can support and PP, BT, DP, CH, and M set to that received.

 

 

·         This response packet is sent on a reverse path and for IPv6 should include a Reverse Flow Label, that is, the Flow Label received on the forward path. In IPv4, the addresses, ports and protocol identify already the flow. In either case the forward flow has been identified to the sender.

 

·         In IPv4, to support mobility, the receiver should also set the Source address and Source port fields of the QoS header to those received in the packet.

 

 

4.3.4 Response Receipt (Back at Source)

 

When the source receives a response packet it proceeds as follows:

·         The source (sender) sets its rate for the flow identified by the Response (addresses reversed, ports reversed, and protocol for IPv4; addresses reversed and reverse flow label for IPv6) to the specified AR+GR rate and continues to send packets.

 

·         If the flow is a TCP flow, the source may set the TCP rate to the agreed rate (AR+GR) and ignore reducing the rate due to lost packets. It must however, reduce this rate if a response is received with a lower rate.

 

 

·         If the flow is a UDP flow, the source should control the sending rate to the accepted rate.

 

·         If the request and response were for a Guaranteed Rate, then a confirmation packet needs to be sent by the sender with the agreed QoS Structure (AR, GR, PP, BT, DP, CH) set to that received in the response packet.  The confirmation is not required for the other services.

 

 

·         In the Guaranteed Rate case, the confirmation packet allows the routers on the forward path to release any excess bandwidth reservation made previously and record the agreed settings for the flow. Also, in this case, when the flow is completed, the sender must send a close (CD=7) to indicate that all reservations may be dropped. It is due to these additional complications that Maximum Rate will be the normal case for voice or video, and Guaranteed Rate the exceptional case where a customer is willing to pay for unused bandwidth to obtain absolutely assured availability.

 

4.3.5 Renegotiate Every 128 Packets

 

Every 128 packets the sender is allowed to renegotiate the available rate  (request an increase to the available rate) by sending a new QoS Structure. This packet cannot change anything in the QoS Structure except the Available Rate and the sender should set DiffServ=”QoSSignal” and set CD=5. The Available Rate can be re-requested at the maximum rate. The sender cannot change the current rate until a response is received with a new rate.

 

4.3.6 Sender Rules

 

The rules used by the sender are:

 

·         The sender must send packets based on the standard TCP slow start provisions until it receives the first response packet. For UDP it may continue to send packets at the requested rate unless it receives a response packet with a lower rate.

 

·         It must then send at the specified AR+GR rate until it receives new rates in a new response packet (CD=2).

 

 

·         For Guaranteed Rate, it must return a confirmation packet whenever it receives a response packet, with the agreed parameters.

 

·         Every 128 packets (if AR>0) it may send a renegotiate packet and make a new request. It may set AR to the maximum rate it can support. This permits AR to be re-determined (higher or lower) every 128 packets.

 

·         The sender must not increase its sending rate until it receives a response packet with a new higher rate (GR+AR).

 

·         Any of the network elements along the flow path may initiate a lower AR rate whenever it needs to, and when the sender receives a response with this lower AR, it must adjust its rate.

 

·         It is not allowed to change PP, BT or DP for the duration of a flow or the routers may have problems keeping packets in order.

 

·         Every packet that contains a QoS structure should use the “QoSSignal” Diffserv code. All other data packets should use the “QoSFlow” Diffserv code to indicate the flow is part of a QoS signaled flow. This allows for missed Start packets to be detected and resent.

·          

 

4.3.7 Router Rate Negotiation

 

Routers in the forward path should reduce the rate in the forward AR field to the maximum rate they can fairly support for start packets. If the router cannot support the rate previously agreed to, it should normally create a new start packet with DiffServ set to "QoSMark" and the QoS Structure set to the rates it can support. However, in some cases, it may be able to modify an existing start packet. Either option is acceptable. The routers should not lower GR, once agreed to, unless preemption of that flow occurs or major network capacity failures occur. If a router changes any field, it must set the M field to one indicating a change has been made.

4.3.8                       DiffServ Marking

For all flows that use this QoS Signaling, each packet with a QoS Structure should set DiffServ=”QoSSignal” and all other packets in the flow should set Diffserv=”QoSFlow”.

4.3.9     Router Discovery of Missed Start Packet

When a router sees a packet with DiffServ=QoSFlow” and it has not seen a Start Packet, it should generate a packet in the forward path that has DiffServ=”QoSFlow” and marked “Missed Start Packet” (CD=4). The other QoS fields should be zero. When the destination receives a packet marked “Missed Start Packet” (CD=4) it should return to the sender a packet marked “Resend Start Packet” (CD=6). Again, the other QoS fields should be set to zero but the Source Address and Source Port (IPv4) or the Source Flow Label (IPv6) should be filled in just as in a normal response packet.

 

4.3.8 Mobility in IPv4

 

In order to support the source or destination moving while maintaining the flow, mobility of the flow is important. In IPv6, mobility has already been specified with appropriate security. However, for IPv4, the mobility can be supported by a simple addition to the protocol.

 

The situation is simple when NAT is not involved, but typically each user is behind a NAT device. The NAT device changes its address and port from a real world IPv4 address to a local address and a new port. The technique needed is to record the real world IPv4 address and port at the destination and include the real address and port of the source in the response. The response packet has a place for the source address and port.  hen the source can record the real address and port for use when he moves. When the source moves, he realizes that his address has changed and therefore makes a new request to the destination for the QoS required. The first request when he was at A' provides him with his real address and port from B in the response. When he makes a new request from location C', he includes the original address and port (A, Ap) in the request. The routers treat this as a new request, and assign the best QoS possible. The old flows are timed out. The destination at C' recognizes the flow as the original flow because it is still to C', C'p and says its original address and port were A, Ap. This matches the original flow and the destination responds with the new real address C, Cp to make ready for the next move. The destination also matches it up with the old flow so no data is missed. Note that if mobility is desired in IPv4, the destination must send a response packet even if M=0 indicating no change. This is because the source will not know its real address when it moves without a response.

 

This process works both ways if both the source and the destination are creating one-way flows as is done in TCP. The exchange occurs on both flows and either end can move. This IPv4 mobility technique has no inherent security and the edge routers that authorize the move to the new address C should undertake whatever security checks are appropriate upon the move.

 

When an IPv4 host that supports this protocol moves, it must add a new Start Packet if it wants to continue a flow. It can recognize that it has moved if it keeps its own NAT address in its flow table. When the sub-layer sees a packet to be sent and the flow table has not been updated to reflect its current source address, it should first send a Start Packet with the new address plus the old address from its flow table and then update its flow table with its current source address. An IPv6 host always includes the QoS Structure in every packet, thus it only needs to ensure the flow label is the same. The addresses are updated by the normal IPv6 mobility process.

 

4.3.9 Non-Compliant Routers & Receivers

 

Routers supporting this QoS procedure should also support QoS based routing that selects, if possible, a path through QoS capable routers. If a router knows that the next router is not capable of supporting this procedure, it may change the packet to a null packet so that no response will occur and the sender will never receive a response. The choice of setting the packet to null when there are only QoS unaware routers is an operator network-wide choice based on the degree of over-capacity the QoS unaware routers are experiencing. With sufficient over-capacity, the current core routers may support the desired QoS effectively and the operator may want to permit the QoS to be controlled at the choke points where there are QoS aware routers. The method of distributing QoS compliance information between routers can be configured manually, exchanged between adjacent routers, or added to the routing protocol being used. If a router in the path does not understand this procedure, or is not capable of supporting this procedure, it should just forward the packet with no action. If the receiver does not support the QoS flow setup procedure, it should ignore the process and thus no response will occur. If the sender does not receive a response, it should continue to operate according to standard IP rules for the protocol involved, which is slow start for TCP. Thus, if a path exists across the network that supports this procedure, the sender will receive a response and the QoS will be supported. If there is no path, where all the routers and the receiver support the procedure, then the sender will not receive a response and normal IP rules will apply. The only exception to this is with maximum rate only. Then if the receiver does not support the procedure, there will be no response even if the rate has been reduced. This is the normal UDP case and the sender proceeds to send at the requested rate. The routers who have not agreed to this rate may discard packets. This is exactly the same case as UDP today. Thus it requires the sender, the routers, and the receiver to support the proposed signaling scheme to obtain a true rate guarantee.

 

5 QoS SPECIFICATION PACKET FORMAT AND FIELDS

 

5.1 IPv4 Packet Format for the QoS Structure

 

For IPv4 [RFC791], a "Start Packet" is sent at the start of the flow. It contains the QoS Structure in the data section and must have the same source address, destination address, protocol, source port, and destination port as the remainder of the flow. This makes it part of the flow. The Diffserv code will be set to "QoSSignal". This tells the routers and the receiver that it is a Start Packet. It should not contain any additional data except the 16-byte QoS Structure(s).

 

If the flow is TCP, then the QoS Structure will appear in the TCP data section. The Forward QoS Structure will typically be sent in the SYN packet. The QoS sub-layer inserts the Forward QoS Structure in the first packet of a flow and sets Diffserv to "QoSSignal" to indicate the presence of a QoS Structure, modified based on a QoS request from an application. The TCP sequence and acknowledgement numbers are not modified. The QoS capable routers in the flow path can modify the QoS parameters as required, except CH. When the destination receives the Start Packet request in a SYN packet, it responds with a SYN/ACK packet with two QoS Structures. The first 16 byte QoS Structure is the Response to the forward path request and the second QoS Structure is the Reverse path QoS request. Then the sender responds with an ACK packet as in the normal 3-way TCP handshake, including the QoS structure of the reverse path response. Thus the normal 3-way TCP handshake includes all the QoS requests and responses for both the forward and reverse paths without using any extra packets. In this TCP exchange, if the forward path response is not required due to an unmodified maximum rate request, the QoS field should be included anyway since the field position is necessary.

 

Mid flow updates (AR or GR Rate reductions) are accomplished by QoS capable routers by simply modifying a TCP packet setting Diffserv set to "QoSSignal" and inserting a QoS Structure. The QoS Structures are removed by the QoS sub-layer before the packets are passed to the IP stack. If the flow is a UDP flow, then the QoS Structure will appear in the UDP data section. The QoS sub-layer can simply insert a packet containing a QoS Structure at any point in a UDP flow. These "Start Packets" will be removed from the flow by the QoS sub-layer at the receiver.

 

 

   -----------------------------------------------------------

   | Ver. | IHL | Type of Ser.   |      Total Length          |

   ------------------------------------------------------------ 

   |      Identification         |Flg.|    Fragment Offset    |

   ------------------------------------------------------------ 

   |    TTL     |      Protocol  |      Header Checksum       |

   ------------------------------------------------------------ 

   |                    Source Address                        | IPv4

   ----------------------------------------------------------- Header

   |                 Destination Address                      |

---------------------------------------------------------------------

   |          Source Port        |      Destination Port      |

   ------------------------------------------------------------ 

   |                       Sequence Number                    |

   ------------------------------------------------------------ 

   |                    Acknowledgement Number                |

   ------------------------------------------------------------ 

   |Offset |Rsv  |ECN |Cont. Bits|           Window           | TCP

   ----------------------------------------------------------- Header

   |         Checksum            |     Urgent Pointer         |

---------------------------------------------------------------------       |                    Source Address                        | 

   ------------------------------------------------------------ 

   |    Available Rate (AR)      |     Guaranteed Rate (GR)   |  QoS

   ------------------------------------------------------------Field

   |      PP     |       DP      |  CD  |  TP  | CH   |  BT   | 

   ------------------------------------------------------------  

   |      QoS Version   |   M    |         Source Port        | 

   ------------------------------------------------------------  

 

Figure 5.1-1 - IPv4 TCP Request/Response Packet Format

 

Note that in the case of a SYN/ACK response the packet can have two QoS Structures, one for each direction.

 

Note also that there may be IP options before the TCP header and there may be TCP options before the QoS Structure. Also, the TCP checksum needs to include the QoS structure.

 

   ------------------------------------------------------------

   | Ver. | IHL | Type of Ser.   |      Total Length          |

   ------------------------------------------------------------ 

   |      Identification         |Flg.|    Fragment Offset    |

   ------------------------------------------------------------ 

   |    TTL     |      Protocol  |      Header Checksum       |

   ------------------------------------------------------------ 

   |                    Source Address                        | IPv4

   ------------------------------------------------------------Header

   |                 Destination Address                      |

-------------------------------------------------------------------- 

   |          Source Port        |      Destination Port      |

   ------------------------------------------------------------ UDP

   |        Length               |       Checksum             |Header

---------------------------------------------------------------------     |                    Source Address                        | 

   ------------------------------------------------------------ 

   |    Available Rate (AR)      |     Guaranteed Rate (GR)   |  QoS

   ------------------------------------------------------------ Field

   |      PP     |     Delay     |  CD  |  TP  | CH   |  BT   |

   ------------------------------------------------------------  

   |      QoS Version   |   M    |         Source Port        | 

   ------------------------------------------------------------  

 

Figure 5.1-2 - IPv4 UDP Request/Response Format

 

 

The IPv4 Request/Response QoS Structure is 16-bytes with 12 fields as follows:

 

·         Source Address: (32 bits) Set to 0 on original request. Set to the prior real source address to re-start a flow after a move or in a response (see section 6).

 

·         AR: (16 bits) Available Rate - floating point rate for network assigned rates e.g. as used for TCP traffic. 15 lower bits used as described in section 5.1.1.

 

·         GR: (16 bits) Guaranteed Rate -floating point rate for requested guaranteed rate e.g. as used in ATM CBR. 15 lower bits used as described in section 5.1.1.

 

·         PP: (8 bits) Preemption Priority - indicates the override or preemption priority of the flow - 64 levels - 0=lowest, 63=highest in the high order 6 bits.  The two low order bits are reserved.

 

·         DP: (8 bits) Delay Priority in 64 levels. - 0=lowest priority, 63=highest priority. The highest level gets priority in transmission, reducing delay variation.

 

§         CD: (4 bits) Change/Direction field – 0=Forward no action required, 1=Start of forward flow to negotiate the QoS parameters, 2=Reverse response returning agreed parameters to the sender, 3=Forward as a confirmation of the negotiated parameters, 4=Missed Start Packet notification inserted by a router in the forward path. 5=Sender request to renegotiate rates on the continuation of a flow once every 128 packets. 6=Resend Start Packet response from destination to sender after receiving #4. 7=Close for a Guaranteed Rate flow. No other values are specified at this time.

 

·         TP: (4 bits) Type of flow - 0=Available Rate (TCP), 1=Composite Rate (like ATM VBR) where GR is requested and AR is assigned by the network, 2=Maximum Rate (Used for UDP where the rate is unknown but the flow should be lossless), 3=Guaranteed Rate as specified in the GR field. No other values are specified at this time.

 

·         CH: (4 bits) Charging information. - 0 = Forward charging (paid by sender), 1 = Reverse charging (paid by receiver). No other values are specified at this time.

 

·         BT: (4 bits) Burst Tolerance - the time (at approved rate) a flow is permitted to exceed its rate (GR+AR) before packets are discarded. Time=2^ (-BT-1) seconds (15 microseconds to 500 ms).

 

·         QoS Version: (12 bits) QoS Protocol Version Field - (initially set to 1)

 

·         M: (4 bits) Modified marker. Set to 0 by sender on request. Set to 1 by routers if any field changed during a request or renegotiate. Set to 0 and not changed on Response.

 

·         Source Port (16 bits) Set to 0 on original request set to the real source port when re-starting a flow after a move or in a response (see section 6).

 

5.1.1 AR and GR - Encoding Floating Point

 

AR and GR fields are encoded according to the following rules:

 

·         The most significant bit of AR and GR is zero and reserved.

 

·         The next bit is nz where nz=1 indicates if the number non-zero and nz=0 means the number is zero.

 

·         The next 5 bits of AR and GR are the exponent E,

 

·         The next 9 bits are the mantissa M.

 

·         The rates AR or GR= (1+M/512)*2^E kilobits per second.

 

·         All zero is interpreted as zero.

 

·         Since E can be as large as 31 and M 511, the maximum rate is 4.291 Tbps. The lowest positive rate would be 1 kbps since 0 is zero.

 

·         This is the same type of floating point number used in ATM except that in ATM its units are cells per second. Since there are no cells in IP, the units are kilobits per second. A benefit of using kilobits/sec as the units is that 64 kilobits per second is represented exactly, as are 2^n multiples of 64 kb.

 

·         Rates are to be measured for TCP over the round trip time (RTT) if possible so as to determine the current TCP average rate. Since TCP sends a burst and then waits for the ACK the RTT can be deduced from the longest inter-packet gap. If the RTT cannot be determined and for UDP where there is no gap, the default rate measurement time is the value of a exponential delay filter with a half life of 500 ms (satellite RTT).

 

§         The rate is measured using all the bytes in the IP packet. The rate on a given trunk would include in some cases the Ethernet or MPLS headers. This overhead must be accounted for at each interface so as to compute the trunk load correctly. However, the IP byte count is a usually constant so the user will know what is being asked for and supported. One exception is when fragmentation occurs and in this case those routers before the fragmentation will have set their rates based on the whole packet, the same as the sender. Later routers will may see increased traffic due to the fragmentation and thus lower the rate. The lower rate will be enforced. A second case exists if the sender uses header compression. If so, it is the compressed packet size that determines the rate since this is the trunk load incurred across the network. Another case is when header compression is used mid-path to reduce the load on a particular link. Here, the rate marked in the QoS Structure should be computed based on the uncompressed header, but the link rate required may be less. Since the average packet size is important to compute the ratio, the first estimate should be based on the routers best guess assuming large packets, and as the flow proceeds if the packet size is smaller, the extra link capacity can be assigned to other flows.

 

5.1.2 IPV4 Response Packet

 

When a Start Packet arrives at the destination address the destination QoS sub layer may accept the QoS if the M field is still set to zero, TP=2, the protocol is UDP, and the AR field is set to zero. This is the simple Maximum Rate case where all the routers have agreed with the QoS parameters and the sender may continue to send at this rate so long as no response is received. However, if the QoS parameters have been changed by the routers (M=1), the protocol is not UDP, the Available Rate is not zero or the Type is not Maximum Rate, then a response packet is required. Since the protocol is UDP, the sender will continue to send at the agreed rate.

 

In the TCP case where the Start Packet used the first TCP SYN to contain the QoS Structure, the response can be included in the TCP SYN-ACK packet. The destination address and source addresses, protocol, and ports need not be reproduced since they are already in the SYN/ACK response, but exchanged. This permits the sender to match up the response with the original flow and record the modified parameters. The other QoS parameters are as received in the Start Packet should be returned as received except that the receiver may reduce the rates if they exceed the maximum that the receiver can support. The format of the IPv4 response packet the same as the request packet for TCP and UDP in IPv4 except that CD is set to 2. Also, the Source Address and Source Port fields should be filled in a response with the actual Source Address and Source Port received from the sender.

 

5.1.3 IPv4 Confirmation and Close Packets 

 

If the request was Guaranteed Rate, when a response is received, the sender should set its rates, delay, BT and PP as specified to confirm the response. For TCP it would be a data packet with the same sequence number as the last TCP packet and Diffserv set to "QoSSignal". For UDP it would be a data packet with Diffserv set to "QoSSignal". The contents of the QoS Structure would be the same as received in the response. The intent is to notify the routers along the forward path of the final agreed upon QoS parameters, so that all the routers can release their unused guarantees. The format of the packet is identical to the request packet except that CD is set to 3. When a Guaranteed Rate flow is closed, a close packet with CD=7 must be sent. The format is otherwise the same as the confirmation packet.

 

5.1.4 IPv4 Renegotiate Packet

 

The format of the IPv4 renegotiation packet is identical to the IPv4 request packet except for the CD field. CD is set to 5. All the QoS parameters received in the response are forwarded as received with no change except the available rate (AR) and CD. This allows the sender to request an increased rate or a router to reduce a rate.

 

 

5.1.5 Router Generated Start Packets

 

When a router on the path determines that it cannot maintain the rates it has agreed to, it may generate a new request packet with the rate changes. It may adjust the Available Rate downward anytime it needs to, due to new network conditions. It must not ever change DP, PP or the BT. It should not change GR except under major overload when trunks fail or higher preemption priority traffic preempts the current flow. In this case it may suggest a lower GR or reduce GR to zero and set AR to whatever value it can support. These packets are sent with CD=5, M=1 and Diffserv set to "QoSSignal". If it is TCP, it should set the sequence number to the last number sent. When the destination receives such a packet it should send a response packet. Upon receipt of the response, the sender should reduce its rate accordingly.

 

If a router sees a packet with DiffServ set to “QoSFow” and it has never seen a start packet for this flow, it should send a packet marked as “Missed Start Packet” (CD=4) toward the destination. This packet should be have DiffServ=”QoSSignal”. All of the other QoS fields in the QoS structure should be zero.

 

 

5.1.6 IPv4 and IPSEC

 

If IPSEC is used with this signaling protocol in IPv4, there is no way for the routers to recognize the flow since the ports and protocol are hidden unless the IPSEC is adjusted not to encrypt the start packets marked with their unique Diffserv code. Thus with unmodified IPSEC, the protocol cannot be used and only Diffserv is available. IPSEC can be used as specified with IPv6 and the protocol.

 

5.2 IPv6 Packet Format for the QoS Structure

 

For IPv6 [RFC2460] where everything after the hop-by-hop options is encrypted, the QoS Structure must be in a hop-by-hop option since it must be seen by the routers. It cannot be in a separate Start Packet as with IPv4.  The IPv6 header will have the Next Protocol Field set to zero to indicate there is a hop-by-hop option next. The QoS option need not be the first hop-by-hop option. Hop-by-hop options in IPv6 have a standard format and the first 4 bytes are needed to describe the length, the next protocol field, the option type (QoS) and the Option Length. Then the QoS fields are in the next 8 bytes and the last four bytes are used for the QoS Version, M, and a reserved space. In the response message, the reserved space is used for the flow label of the forward flow. The request and confirmation format is below:

 

   -----------------------------------------------------------

   | Version | Traffic Class |          Flow Label            |

   ------------------------------------------------------------ 

   |      Payload Length           | Next Header | Hop Limit  | 

   ------------------------------------------------------------   |                                                          | IPv6

   |                                                          |Header

   |                    Source Address                        |

   |                                                          | 

   ------------------------------------------------------------ 

   |                                                          |

   |                                                          |

   |                 Destination Address                      |

   |                                                          | 

   ------------------------------------------------------------ 

   | Next Header |    H.E. Len   | Opt. Type   | Option Len   | 

   ------------------------------------------------------------ 

   |    Available Rate (AR)      |     Guaranteed Rate (GR)   |  QoS

   ------------------------------------------------------------ Field

   |      PP     |       DP      |  CD  |  TP  | CH   |  BT   |

   ------------------------------------------------------------  

   |      QoS Version   |   M    |         Reserved           | 

   ------------------------------------------------------------  

 

Figure 5.2-1 - IPv6 Request Packet Format

 

The IPv6 QoS Request Option Field is 16-bytes with 15 fields as follows:

 

·         Next Header: (8 bits) Identifies the type of header immediately following this option

 

·         Header Extension Length: (8 bits) Header Extension Length is set to 1 to indicate that the QoS extension field since it is exactly 16 bytes long (8-bytes plus 1 additional 8-byte segment).

 

·         Option Type: (8 bits) Option Type indicates the QoS code to be selected. It must start with '001' since it of type "skip if not recognized" and subject to "change each hop". No options are currently assigned with the 001 header. Thus, until such time that IANA formally assigns an option code, the default code for experimental use is selected as 00100000 or in decimal, 32.

 

·         Option Length:  (8 bits) Option Length is set to 12 (12 more bytes).

 

·         AR: (16 bits) Available Rate - floating point rate for network assigned rates e.g. as used for TCP traffic. 15 lower bits used as described in 5.1.1.

 

·         GR: (16 bits) Guaranteed Rate -floating point rate for requested guaranteed rate e.g. as used in ATM CBR. 15 lower bits used as described in 5.1.1.

 

·         PP: (8 bits) Preemption Priority - indicates the override or preemption priority of the flow - 64 levels - 0=lowest, 63=highest in the high order 6 bits.  The two low order bits are reserved.

 

·         DP: (8 bits) Delay Priority in 64 levels. - 0=lowest priority, 63=highest priority. The highest level gets priority in transmission, reducing delay variation.

 

§         CD: (4 bits) Change/Direction field – 0=Forward no action required, 1=Start of forward flow to negotiate the QoS parameters, 2=Reverse response returning agreed parameters to the sender, 3=Forward as a confirmation of the negotiated parameters, 4=Missed Start Packet notification inserted by a router in the forward path. 5=Sender request to renegotiate rates on the continuation of a flow once every 128 packets. 6=Resend Start Packet response from destination to sender after receiving #4. 7=Close for a Guaranteed Rate flow. No other values are specified at this time.

 

·         TP: (4 bits) Type of flow - 0=Available Rate (TCP), 1=Composite Rate (like ATM VBR) where GR is requested and AR is assigned by the network, 2=Maximum Rate (Used where the rate has maximum but the flow should be near lossless), 3=Guaranteed Rate as specified in the GR field. No other values are specified at this time.

 

·         CH: (4 bits) Charging information. - 0 = Forward charging (paid by sender), 1 = Reverse charging (paid by receiver). No other values are specified at this time.

 

·         BT: (4 bits) Burst Tolerance - the time (at approved rate) a flow is permitted to exceed its rate (GR+AR) before packets are discarded. Time=2^ (-Burst T-1) seconds (15 microseconds to 500 ms).

 

·         QoS Version: (12 bits) QoS Protocol Version Field - (initially set to 1)

 

·         M: (4 bits) Modified marker. Set to 0 by sender. Set to 1 if any field changed by a router.

 

·         Reserved (16 bits) Set to 0

 

5.2.1 IPv6 Response Packet

 

As with IPv4, the destination should respond to the QoS Request Packet with a response packet unless M=0, TP=2, and AR=0. In that case the sender and the routers all know the maximum rate. Otherwise, the agreed rates must be sent back to the sender in a response. The response and (when required) the confirmation are sent as QoS hop-by-hop Option Fields as in the request. This avoids encryption and lets the routers process them. The IPv6 response packet format is as follows:

 

   -----------------------------------------------------------

   | Version | Traffic Class |          Flow Label            |

   ------------------------------------------------------------ 

   |      Payload Length           | Next Header | Hop Limit  | 

   ------------------------------------------------------------           |                                                          | IPv6

   |                                                          |Header

   |                    Source Address                        |

   |                                                          |

   ------------------------------------------------------------ 

   |                                                          | 

   |                                                          |

   |                 Destination Address                      |

   |                                                          |

-------------------------------------------------------------------- 

   | Next Header |    H.E. Len   | Opt. Type   | Option Len   | 

   ------------------------------------------------------------ 

   |    Available Rate (AR)      |     Guaranteed Rate (GR)   |  QoS

   ------------------------------------------------------------Field

   |      PP     |       DP      |  CD  |  TP  | CH   |  BT   | 

   ------------------------------------------------------------  

   |      QoS Version   |      Source Flow Label              | 

   ------------------------------------------------------------  

 

 

Figure 5.2-2 IPv6 QoS Response Packet Format

 

The IPv6 QoS Structure Response is 16-bytes with 14 fields as follows:

 

·         Next Header: (8 bits) Identifies the type of header immediately following this option

 

·         Header Extension Length: (8 bits) Header Extension Length is set to 1 to indicate that the QoS extension field since it is exactly 16 bytes long (8-bytes plus 1 additional 8-byte segment).

 

·         Option Type: (8 bits) Option Type indicates the QoS code to be selected. It must start with '001' since it of type "skip if not recognized" and subject to "change each hop".

 

·         Option Length:  (8 bits) Option Length is set to 12 (12 more bytes).

 

·         AR: (16 bits) Available Rate - floating point rate for network assigned rates e.g. as used for TCP traffic. 15 lower bits used.

 

·         GR: (16 bits) Guaranteed Rate -floating point rate for requested guaranteed rate e.g. as used in ATM CBR. 15 lower bits used.

 

·         PP: (8 bits) Preemption Priority - indicates the override or preemption priority of the flow - 64 levels - 0=lowest, 63=highest in the high order 6 bits.  The two low order bits are reserved.

 

·         DP: (8 bits) Delay Priority in 64 levels. - 0=lowest priority, 63=highest priority. The highest level gets priority in transmission, reducing delay variation.

 

§         CD: (4 bits) Change/Direction field – 0=Forward no action required, 1=Start of forward flow to negotiate the QoS parameters, 2=Reverse response returning agreed parameters to the sender, 3=Forward as a confirmation of the negotiated parameters, 4=Missed Start Packet notification inserted by a router in the forward path. 5=Sender request to renegotiate rates on the continuation of a flow once every 128 packets. 6=Resend Start Packet response from destination to sender after receiving #4. 7=Close for a Guaranteed Rate flow. No other values are specified at this time.

 

·         TP: (4 bits) Type of flow - 0=Available Rate (TCP), 1=Composite Rate (like ATM VBR) where GR is requested and AR is assigned by the network, 2=Maximum Rate (Used where the rate has maximum but the flow should be near lossless), 3=Guaranteed Rate as specified in the GR field. No other values are specified at this time.

 

·         CH: (4 bits) Charging information. - 0 = Forward charging (paid by sender), 1 = Reverse charging (paid by receiver). No other values are specified at this time.

 

·         BT: (4 bits) Burst Tolerance - the time (at approved rate) a flow is permitted to exceed its rate (GR+AR) before packets are discarded. Time=2^ (-Burst T-1) seconds (15 microseconds to 500 ms).

 

·         QoS Version: (12 bits) QoS Protocol Version Field - (initially set to 1)

 

·         Source Flow Label: (20 bits) - Set to the Flow Label of the forward flow.

 

5.2.2 IPv6 Confirmation and Close Packets

 

For Guaranteed Rate flows, the format of the IPv6 confirmation packet is identical to the IPv6 request packet except for the CD field. CD is set to 3. All the QoS parameters received in the response are forwarded as received with no change. This allows all the routers to drop excess capacity reservations. The close packet is also the same except CD=7.

 

5.2.3 IPv6 Renegotiate Packet

 

The format of the IPv6 renegotiate packet is identical to the IPv6 request packet except for the CD field. CD is set to 5. All the QoS parameters received in the response are forwarded as received with no change except the available rate (AR) and CD. This allows the sender to request an increased rate or a router to reduce a rate.

5.2.4   DiffServ Marking

All packets containing a QoS Structure should be marked with DiffServ=”QoSSignal” and the other packets in these flows marketed with DiffServ=”QoSFlow”. This allows the routers to easily separate the QoS signaled flows and recognize missed Start Packets.

 

 

 

6.1 Abbreviations

 

ABR  Available Bit Rate

 

AR   Available Rate

 

ATM  Asynchronous Transfer Mode

 

BT   Burst Tolerance

 

CH   Charging Information

 

DIFFSERV   Differentiated Services

 

DP   Delay Priority

 

ECN  Explicit Congestion Notification

 

GR   Guaranteed Rate

 

ICMP Internet Control Message Protocol

 

ID   Identifier

 

IETF Internet Engineering Task Force

 

IntServ    Integrated Services

 

IP   Internet Protocol

 

IPv4 Internet Protocol Version 4

 

IPv6 Internet Protocol Version 6

 

LDP  Label Distribution Protocol

 

NAT  Network Address Translation

 

PP   Preemption Priority

 

MTU  Maximum Transmission Unit in IPv4 and IPv6

 

QoS  Quality of Service

 

RED  Random Early Detection

 

RFC  Request for Comments

 

RSVP Reservation Protocol

 

RTT  Round Trip Time

 

TCP  Transmission Control Protocol

 

TDM  Time Division Multiplexing

 

TP   Type Field

 

UDP  User Datagram Protocol

 

VBR  Variable Bit Rate

 

WRED Weighted Random Early Detection

 

6.2  Definitions

 

bps: Bits per second

 

Flow:      A flow is defined herein to mean a unidirectional set of data-grams that carry information between one user application and another. In the IPv4 world, a flow is defined by the source and destination addresses, the protocol, and the transport layer (i.e. TCP or UDP) source and destination ports.

 

CoS: Class of Service is defined herein to mean a process within IP routers where a large group of flows, not all moving from the same source or to the same destination, are associated with certain performance parameters such as different discard or scheduling priority. In IPv4 the Diffserv Codings define the Class of Service, and thus put an inherent limit of 64 classes or priorities. Flows within a single traffic class will all be subject to the same discard procedure and the same scheduling process.  Thus, if the total set of flows in one class exceeds the capacity of a port, they all will suffer from the same discard process, typically random discards.

 

PP   Preemption Priority is the QoS parameter used herein for preemption, the priority a user has to override other users in the case of limited resources. This capability is typically used for guaranteed rate flows so as to allow emergency services to get through during a communication overload. 

 

QoS: QoS is described herein as a set of parameters used to define the quality and quantity of resources a flow requires, as it traverses a network.  Specifically in this context, they are defined as Guaranteed rate, Available Rate, Delay, Preemption, Priority and Burst Tolerance.

 

QoSSignal  QoSSignal is a unique Diffserv code that is defined herein to identify QoS Signaling Packets in IPv4.  The default value for QoSSignal is the 000011 code from pool 2 (Experimental / Local Usage) as described in [RFC2474]. IPv4 implementations must support configuration of the QoSSignal value to comply with [RFC2474]. QoS capable routers should support remarking (translation) of QoSSignal values. This tells the routers and the receiver that it is a Start Packet.

 

QoSFlow    QoSFlow is a second unique Diffserv code that is defined herein to identify all the packets on a flow that are not QoS Signaling Packets. The default value for QoSFlow is 000111 again from the pool 2 (Experimental / Local Usage) as described in [RFC2474]. The use of this code allows routers to detect the loss of a QoS Signaling Packet and thus to generate a request for a QoS Signaling Packet.

 

QoS Structure   A block of 16 bytes is used to specify the QoS parameters. In the QoS Structure the available rate, guaranteed rate, delay priority, preemption priority, burst tolerance, and charging direction for the flow are specified.

 

RSVP Reservation Protocol defined by the IETF for providing QoS in IP networks.  RSVP is an "out-of-band" software signaling process for IP traffic.

 

Start Packet    A packet marked with the Diffserv code "QoSSignal" which conveys the QoS Structure.

 

 

6.3  Informative References

 

1.   [ExplicitRateFC] - Explicit Rate Flow Control, Lawrence Roberts, April 1997  http://www.packet.cc/files/Ex-Rate-Fl-Con.htm

 

2.   [RFC3168] - The Addition of Explicit Congestion Notification (ECN) to IP, K. Ramakrishnan, S. Floyd, D. Black, RFC 3168, September 2001

 

3.   [RFC1633] - Integrated Services in the Internet Architecture: an Overview, R. Braden, D. Clark, S. Shenker, RFC 1633, June 1994

 

4.   [RFC2212] - Specification of Guaranteed Quality of Service, S. Shenker, C. Partridge, R. Guerin, RFC 2212, September 1997

 

5.   [RFC2215] - General Characterization Parameters for Integrated Service Network Elements, S. Shenker, J. Wroclawski, RFC 2215, September 1997

 

6.   [RFC2998] - A Framework for Integrated Services Operation over Diffserv Networks, Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden. B. Davie, J. Wroclawski, E. Felstaine, RFC 2998, November 2000

 

7.   [RFC2474] - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv4 Headers, k. Nichols, S. Blake, f. Baker, D. Black, RFC 2474, December 1998

 

8.   [ExplicitRateTCP] Flow Control - Explicit Rate vs TCP, L. Roberts, http://www.packet.cc/files/ERvsTCP.html

 

9.   [RFC1981] - Path MTU Discovery for IP version 6, J. McCann, S. Deering, J. Mogul, RFC 1981, August 1996

 

10. [BestEffort] Is Best Effort IP Really Economic? –L. Roberts, IPv6 Newsletter, 6/ 2004, http://www.packet.cc/larry-news/Is Best Effort IP Really Economic2.htm

 

 

 

6.4           Normative References

 

11. [RFC791] - Internet Protocol IPv4, j. Postel, RFC 791, Sept 1981,

12. [RFC2460] - Internet Protocol, Version 6 (IPv6) Specification, S. Deering, R. Hinden, RFC 2460, December 1998

 

7. Security Considerations 
 
For routers that ignore the option, no security considerations exist. The main security issue for edge routers using the protocol is the authentication and authorization of the user at the first network router. In IPv6 this is well defined. In IPv4 the same type of process is required and could either be the normal Radius process or the IPv6 process. The issue here is to ensure the user has the right to the preemption priority used and has paid for the delay and rates requested. This is part of the authorization. Also, if a guaranteed rate is permitted, it must be authorized. Aside from that, these routers discard the flow if the user stops sending packets. Thus it operates just like the current Internet. 
 
7.1                 IANA Considerations
 
The document would require IANA to assign a hop-by-hop option code of the form 001xxxx for the type of usage, QoS Signaling. A QoS Version # starting in byte 25 for 12 bits would allow many protocols or variations thereof, to use the same option code. No option codes are assigned of this type at this time so any code from 32 to 63 would work. 
 
7.2    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. 
 
8. Authors Addresses
 
Lawrence Roberts
Anagran Inc.
2055 Woodside Road #200
Redwood City, CA 94061
Email: lroberts@anagran.com
 
9. Full Copyright Statement
 
Copyright (C) The Internet Society (2005).
 
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.